From 647b8663d1aa21243169f7ac7eda77daf5eeaf8d Mon Sep 17 00:00:00 2001 From: Jonathan Turner Date: Wed, 17 Jan 2018 13:13:13 +1300 Subject: [PATCH 0001/1812] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index d41418f2f..b8929c1e3 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,3 @@ -An attempt to docuemnt how the compiler works. The intention is to +An attempt to document how the compiler works. The intention is to bootstrap this "in repo" and eventually move the text over into the main rustc repo. From 11b19a4f4b6c78f10572c7cab8b5bb527a8f699b Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 17 Jan 2018 12:30:45 +0800 Subject: [PATCH 0002/1812] Created a couple basic CI scripts --- .travis.yml | 17 +++++++++++++++++ ci/github_pages.sh | 10 ++++++++++ ci/install.sh | 6 ++++++ 3 files changed, 33 insertions(+) create mode 100644 .travis.yml create mode 100644 ci/github_pages.sh create mode 100644 ci/install.sh diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 000000000..e1fcfa9bf --- /dev/null +++ b/.travis.yml @@ -0,0 +1,17 @@ +language: rust + +cache: pip + +install: + - bash ci/install.sh + - source ~/.cargo/env || true + +script: + - true + +after_success: + - bash ci/github_pages.sh + +notifications: + email: + on_success: never \ No newline at end of file diff --git a/ci/github_pages.sh b/ci/github_pages.sh new file mode 100644 index 000000000..603b280f9 --- /dev/null +++ b/ci/github_pages.sh @@ -0,0 +1,10 @@ +#!/bin/bash +set -ex + +BOOK_DIR=book + +# Only upload the built book to github pages if it's a commit to master +if [ "$TRAVIS_BRANCH" = master -a "$TRAVIS_PULL_REQUEST" = false ]; then + mdbook build + ghp-import $BOOK_DIR +fi \ No newline at end of file diff --git a/ci/install.sh b/ci/install.sh new file mode 100644 index 000000000..d9cb369e5 --- /dev/null +++ b/ci/install.sh @@ -0,0 +1,6 @@ +#!/bin/bash +set -ex + +if command -v ghp-import >/dev/null 2>&1; then + pip install ghp-import +fi \ No newline at end of file From 78960d989abc2ebfd55f1fda18338bec652c47ee Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 17 Jan 2018 09:19:24 -0500 Subject: [PATCH 0003/1812] improve the README --- README.md | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index b8929c1e3..beb2507cd 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,25 @@ -An attempt to document how the compiler works. The intention is to -bootstrap this "in repo" and eventually move the text over into the -main rustc repo. +This is a collaborate effort to build a guide that explains how rustc +works. The aim of the guide is to help new contributors get oriented +to rustc, as well as to help more experienced folks in figuring out +some new part of the compiler that they haven't worked on before. + +The guide can be useful today, but it has a lot of work still go. +Once it gets more complete, the plan is probably to move it into the +[main Rust repository](https://github.com/rust-lang/rust/). + +### Contributing to the guide + +If you'd like to help finish the guide, we'd love to have you! The +main tracking issue for the guide +[can be found here](https://github.com/rust-lang-nursery/rustc-guide/issues/6). From +there, you can find a list of all the planned chapters and subsections +-- if you think something is missing, please open an issue about it! +Otherwise, find a chapter that sounds interesting to you and then go +to its associated issue. There should be a list of things to do. + +**In general, if you don't know how the compiler works, that is not a +problem!** In that case, what we will do is to schedule a bit of time +for you to talk with someone who **does** know the code, or who wants +to pair with you and figure it out. Then you can work on writing up +what you learned. + From 5e297beb81bab07acfd8f2b0d94335e4744a38b7 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 17 Jan 2018 09:25:59 -0500 Subject: [PATCH 0004/1812] remove `src/src` directory that somehow got created --- src/{src => }/SUMMARY.md | 0 src/{src => }/chap-010-how-to-build-and-run.md | 0 src/{src => }/chap-020-running-tests.md | 0 src/{src => }/chap-030-walkthrough.md | 0 src/{src => }/chap-040-compiler-conventions.md | 0 src/{src => }/chap-050-the-parser.md | 0 src/{src => }/chap-060-macro-expansion.md | 0 src/{src => }/chap-070-name-resolution.md | 0 src/{src => }/chap-080-hir-lowering.md | 0 src/{src => }/chap-090-ty.md | 0 src/{src => }/chap-100-type-inference.md | 0 src/{src => }/chap-110-trait-resolution.md | 0 src/{src => }/chap-120-type-checking.md | 0 src/{src => }/chap-130-mir-construction.md | 0 src/{src => }/chap-140-mir-borrowck.md | 0 src/{src => }/chap-150-mir-optimizations.md | 0 src/{src => }/chap-160-trans.md | 0 src/{src => }/glossary.md | 0 18 files changed, 0 insertions(+), 0 deletions(-) rename src/{src => }/SUMMARY.md (100%) rename src/{src => }/chap-010-how-to-build-and-run.md (100%) rename src/{src => }/chap-020-running-tests.md (100%) rename src/{src => }/chap-030-walkthrough.md (100%) rename src/{src => }/chap-040-compiler-conventions.md (100%) rename src/{src => }/chap-050-the-parser.md (100%) rename src/{src => }/chap-060-macro-expansion.md (100%) rename src/{src => }/chap-070-name-resolution.md (100%) rename src/{src => }/chap-080-hir-lowering.md (100%) rename src/{src => }/chap-090-ty.md (100%) rename src/{src => }/chap-100-type-inference.md (100%) rename src/{src => }/chap-110-trait-resolution.md (100%) rename src/{src => }/chap-120-type-checking.md (100%) rename src/{src => }/chap-130-mir-construction.md (100%) rename src/{src => }/chap-140-mir-borrowck.md (100%) rename src/{src => }/chap-150-mir-optimizations.md (100%) rename src/{src => }/chap-160-trans.md (100%) rename src/{src => }/glossary.md (100%) diff --git a/src/src/SUMMARY.md b/src/SUMMARY.md similarity index 100% rename from src/src/SUMMARY.md rename to src/SUMMARY.md diff --git a/src/src/chap-010-how-to-build-and-run.md b/src/chap-010-how-to-build-and-run.md similarity index 100% rename from src/src/chap-010-how-to-build-and-run.md rename to src/chap-010-how-to-build-and-run.md diff --git a/src/src/chap-020-running-tests.md b/src/chap-020-running-tests.md similarity index 100% rename from src/src/chap-020-running-tests.md rename to src/chap-020-running-tests.md diff --git a/src/src/chap-030-walkthrough.md b/src/chap-030-walkthrough.md similarity index 100% rename from src/src/chap-030-walkthrough.md rename to src/chap-030-walkthrough.md diff --git a/src/src/chap-040-compiler-conventions.md b/src/chap-040-compiler-conventions.md similarity index 100% rename from src/src/chap-040-compiler-conventions.md rename to src/chap-040-compiler-conventions.md diff --git a/src/src/chap-050-the-parser.md b/src/chap-050-the-parser.md similarity index 100% rename from src/src/chap-050-the-parser.md rename to src/chap-050-the-parser.md diff --git a/src/src/chap-060-macro-expansion.md b/src/chap-060-macro-expansion.md similarity index 100% rename from src/src/chap-060-macro-expansion.md rename to src/chap-060-macro-expansion.md diff --git a/src/src/chap-070-name-resolution.md b/src/chap-070-name-resolution.md similarity index 100% rename from src/src/chap-070-name-resolution.md rename to src/chap-070-name-resolution.md diff --git a/src/src/chap-080-hir-lowering.md b/src/chap-080-hir-lowering.md similarity index 100% rename from src/src/chap-080-hir-lowering.md rename to src/chap-080-hir-lowering.md diff --git a/src/src/chap-090-ty.md b/src/chap-090-ty.md similarity index 100% rename from src/src/chap-090-ty.md rename to src/chap-090-ty.md diff --git a/src/src/chap-100-type-inference.md b/src/chap-100-type-inference.md similarity index 100% rename from src/src/chap-100-type-inference.md rename to src/chap-100-type-inference.md diff --git a/src/src/chap-110-trait-resolution.md b/src/chap-110-trait-resolution.md similarity index 100% rename from src/src/chap-110-trait-resolution.md rename to src/chap-110-trait-resolution.md diff --git a/src/src/chap-120-type-checking.md b/src/chap-120-type-checking.md similarity index 100% rename from src/src/chap-120-type-checking.md rename to src/chap-120-type-checking.md diff --git a/src/src/chap-130-mir-construction.md b/src/chap-130-mir-construction.md similarity index 100% rename from src/src/chap-130-mir-construction.md rename to src/chap-130-mir-construction.md diff --git a/src/src/chap-140-mir-borrowck.md b/src/chap-140-mir-borrowck.md similarity index 100% rename from src/src/chap-140-mir-borrowck.md rename to src/chap-140-mir-borrowck.md diff --git a/src/src/chap-150-mir-optimizations.md b/src/chap-150-mir-optimizations.md similarity index 100% rename from src/src/chap-150-mir-optimizations.md rename to src/chap-150-mir-optimizations.md diff --git a/src/src/chap-160-trans.md b/src/chap-160-trans.md similarity index 100% rename from src/src/chap-160-trans.md rename to src/chap-160-trans.md diff --git a/src/src/glossary.md b/src/glossary.md similarity index 100% rename from src/src/glossary.md rename to src/glossary.md From 54145323f8aafad125f60b8cc44ddf7a5bf0408a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 17 Jan 2018 09:53:45 -0500 Subject: [PATCH 0005/1812] add link to gh-pages --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index beb2507cd..5ff51de2b 100644 --- a/README.md +++ b/README.md @@ -3,6 +3,8 @@ works. The aim of the guide is to help new contributors get oriented to rustc, as well as to help more experienced folks in figuring out some new part of the compiler that they haven't worked on before. +[You can read the latest version of the guide here.](https://rust-lang-nursery.github.io/rustc-guide/) + The guide can be useful today, but it has a lot of work still go. Once it gets more complete, the plan is probably to move it into the [main Rust repository](https://github.com/rust-lang/rust/). From ae4b5503b2a7178873838e737c88eb8a4889c698 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:38:33 -0500 Subject: [PATCH 0006/1812] add an "about this guide" section --- src/SUMMARY.md | 1 + src/chap-000-about-this-guide.md | 14 ++++++++++++++ 2 files changed, 15 insertions(+) create mode 100644 src/chap-000-about-this-guide.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 21c871885..30dde6fb9 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -1,5 +1,6 @@ # Summary +- [About this guide](./chap-000-about-this-guide.md) - [How to build the compiler and run what you built](./chap-010-how-to-build-and-run.md) - [Using the compiler testing framework](./chap-020-running-tests.md) - [Walkthrough: a typical contribution](./chap-030-walkthrough.md) diff --git a/src/chap-000-about-this-guide.md b/src/chap-000-about-this-guide.md new file mode 100644 index 000000000..ea840177b --- /dev/null +++ b/src/chap-000-about-this-guide.md @@ -0,0 +1,14 @@ +# About this guide + +This guide is meant to help document how rustc -- the Rust compiler -- +works, as well as to help new contributors get involved in rustc +development. It is not meant to replace code documentation -- each +chapter gives only high-level details, the kinds of things that +(ideally) don't change frequently. + +The guide itself is of course open source as well, and the sources can +be found at [the GitHub repository]. If you find any mistakes in the +guide, please file an issue about it -- or, even better, open a PR +with a correction! + +[the GitHub repository]: https://github.com/rust-lang-nursery/rustc-guide/ From 6cafcbb06f85b95a99d8f44b554a6150c2fce5b0 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:38:40 -0500 Subject: [PATCH 0007/1812] replace "conventions" with "high-level overview" Also bring in material from the librustc README.md --- src/SUMMARY.md | 2 +- src/chap-040-compiler-conventions.md | 1 - src/chap-040-high-level-overview.md | 141 +++++++++++++++++++++++++++ 3 files changed, 142 insertions(+), 2 deletions(-) delete mode 100644 src/chap-040-compiler-conventions.md create mode 100644 src/chap-040-high-level-overview.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 30dde6fb9..1c87e26ce 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -4,7 +4,7 @@ - [How to build the compiler and run what you built](./chap-010-how-to-build-and-run.md) - [Using the compiler testing framework](./chap-020-running-tests.md) - [Walkthrough: a typical contribution](./chap-030-walkthrough.md) -- [Conventions used in the compiler](./chap-040-compiler-conventions.md) +- [High-level overview of the compiler source](./chap-040-high-level-overview.md) - [The parser](./chap-050-the-parser.md) - [Macro expansion](./chap-060-macro-expansion.md) - [Name resolution](./chap-070-name-resolution.md) diff --git a/src/chap-040-compiler-conventions.md b/src/chap-040-compiler-conventions.md deleted file mode 100644 index 314221fa0..000000000 --- a/src/chap-040-compiler-conventions.md +++ /dev/null @@ -1 +0,0 @@ -# Conventions used in the compiler diff --git a/src/chap-040-high-level-overview.md b/src/chap-040-high-level-overview.md new file mode 100644 index 000000000..b8d75bff6 --- /dev/null +++ b/src/chap-040-high-level-overview.md @@ -0,0 +1,141 @@ +# High-level overview of the compiler source + +## Crate structure + +The main Rust repository consists of a `src` directory, under which +there live many crates. These crates contain the sources for the +standard library and the compiler. This document, of course, focuses +on the latter. + +Rustc consists of a number of crates, including `syntax`, +`rustc`, `rustc_back`, `rustc_trans`, `rustc_driver`, and +many more. The source for each crate can be found in a directory +like `src/libXXX`, where `XXX` is the crate name. + +(NB. The names and divisions of these crates are not set in +stone and may change over time -- for the time being, we tend towards +a finer-grained division to help with compilation time, though as +incremental improves that may change.) + +The dependency structure of these crates is roughly a diamond: + +``` + rustc_driver + / | \ + / | \ + / | \ + / v \ +rustc_trans rustc_borrowck ... rustc_metadata + \ | / + \ | / + \ | / + \ v / + rustc + | + v + syntax + / \ + / \ + syntax_pos syntax_ext +``` + +The `rustc_driver` crate, at the top of this lattice, is effectively +the "main" function for the rust compiler. It doesn't have much "real +code", but instead ties together all of the code defined in the other +crates and defines the overall flow of execution. (As we transition +more and more to the [query model](ty/maps/README.md), however, the +"flow" of compilation is becoming less centrally defined.) + +At the other extreme, the `rustc` crate defines the common and +pervasive data structures that all the rest of the compiler uses +(e.g., how to represent types, traits, and the program itself). It +also contains some amount of the compiler itself, although that is +relatively limited. + +Finally, all the crates in the bulge in the middle define the bulk of +the compiler -- they all depend on `rustc`, so that they can make use +of the various types defined there, and they export public routines +that `rustc_driver` will invoke as needed (more and more, what these +crates export are "query definitions", but those are covered later +on). + +Below `rustc` lie various crates that make up the parser and error +reporting mechanism. For historical reasons, these crates do not have +the `rustc_` prefix, but they are really just as much an internal part +of the compiler and not intended to be stable (though they do wind up +getting used by some crates in the wild; a practice we hope to +gradually phase out). + +Each crate has a `README.md` file that describes, at a high-level, +what it contains, and tries to give some kind of explanation (some +better than others). + +## The main stages of compilation + +The Rust compiler is in a bit of transition right now. It used to be a +purely "pass-based" compiler, where we ran a number of passes over the +entire program, and each did a particular check of transformation. We +are gradually replacing this pass-based code with an alternative setup +based on on-demand **queries**. In the query-model, we work backwards, +executing a *query* that expresses our ultimate goal (e.g., "compile +this crate"). This query in turn may make other queries (e.g., "get me +a list of all modules in the crate"). Those queries make other queries +that ultimately bottom out in the base operations, like parsing the +input, running the type-checker, and so forth. This on-demand model +permits us to do exciting things like only do the minimal amount of +work needed to type-check a single function. It also helps with +incremental compilation. (For details on defining queries, check out +`src/librustc/ty/maps/README.md`.) + +Regardless of the general setup, the basic operations that the +compiler must perform are the same. The only thing that changes is +whether these operations are invoked front-to-back, or on demand. In +order to compile a Rust crate, these are the general steps that we +take: + +1. **Parsing input** + - this processes the `.rs` files and produces the AST ("abstract syntax tree") + - the AST is defined in `syntax/ast.rs`. It is intended to match the lexical + syntax of the Rust language quite closely. +2. **Name resolution, macro expansion, and configuration** + - once parsing is complete, we process the AST recursively, resolving paths + and expanding macros. This same process also processes `#[cfg]` nodes, and hence + may strip things out of the AST as well. +3. **Lowering to HIR** + - Once name resolution completes, we convert the AST into the HIR, + or "high-level IR". The HIR is defined in `src/librustc/hir/`; that module also includes + the lowering code. + - The HIR is a lightly desugared variant of the AST. It is more processed than the + AST and more suitable for the analyses that follow. It is **not** required to match + the syntax of the Rust language. + - As a simple example, in the **AST**, we preserve the parentheses + that the user wrote, so `((1 + 2) + 3)` and `1 + 2 + 3` parse + into distinct trees, even though they are equivalent. In the + HIR, however, parentheses nodes are removed, and those two + expressions are represented in the same way. +3. **Type-checking and subsequent analyses** + - An important step in processing the HIR is to perform type + checking. This process assigns types to every HIR expression, + for example, and also is responsible for resolving some + "type-dependent" paths, such as field accesses (`x.f` -- we + can't know what field `f` is being accessed until we know the + type of `x`) and associated type references (`T::Item` -- we + can't know what type `Item` is until we know what `T` is). + - Type checking creates "side-tables" (`TypeckTables`) that include + the types of expressions, the way to resolve methods, and so forth. + - After type-checking, we can do other analyses, such as privacy checking. +4. **Lowering to MIR and post-processing** + - Once type-checking is done, we can lower the HIR into MIR ("middle IR"), which + is a **very** desugared version of Rust, well suited to the borrowck but also + certain high-level optimizations. +5. **Translation to LLVM and LLVM optimizations** + - From MIR, we can produce LLVM IR. + - LLVM then runs its various optimizations, which produces a number of `.o` files + (one for each "codegen unit"). +6. **Linking** + - Finally, those `.o` files are linked together. + + + + +The first thing you may wonder if From 3492c534fe72cb0964382b6d3fe933e69f3d7221 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:42:50 -0500 Subject: [PATCH 0008/1812] remove the `chap-NNN-` convention from file names I don't want those showing up in the URLs. --- src/SUMMARY.md | 34 +++++++++---------- ...bout-this-guide.md => about-this-guide.md} | 0 ...vel-overview.md => high-level-overview.md} | 0 ...ap-080-hir-lowering.md => hir-lowering.md} | 0 ...ild-and-run.md => how-to-build-and-run.md} | 0 ...-macro-expansion.md => macro-expansion.md} | 0 ...ap-140-mir-borrowck.md => mir-borrowck.md} | 0 ...ir-construction.md => mir-construction.md} | 0 ...-optimizations.md => mir-optimizations.md} | 0 ...-name-resolution.md => name-resolution.md} | 0 ...-020-running-tests.md => running-tests.md} | 0 src/{chap-050-the-parser.md => the-parser.md} | 0 ...rait-resolution.md => trait-resolution.md} | 0 src/{chap-160-trans.md => trans.md} | 0 src/{chap-090-ty.md => ty.md} | 0 ...-120-type-checking.md => type-checking.md} | 0 ...00-type-inference.md => type-inference.md} | 0 ...chap-030-walkthrough.md => walkthrough.md} | 0 18 files changed, 17 insertions(+), 17 deletions(-) rename src/{chap-000-about-this-guide.md => about-this-guide.md} (100%) rename src/{chap-040-high-level-overview.md => high-level-overview.md} (100%) rename src/{chap-080-hir-lowering.md => hir-lowering.md} (100%) rename src/{chap-010-how-to-build-and-run.md => how-to-build-and-run.md} (100%) rename src/{chap-060-macro-expansion.md => macro-expansion.md} (100%) rename src/{chap-140-mir-borrowck.md => mir-borrowck.md} (100%) rename src/{chap-130-mir-construction.md => mir-construction.md} (100%) rename src/{chap-150-mir-optimizations.md => mir-optimizations.md} (100%) rename src/{chap-070-name-resolution.md => name-resolution.md} (100%) rename src/{chap-020-running-tests.md => running-tests.md} (100%) rename src/{chap-050-the-parser.md => the-parser.md} (100%) rename src/{chap-110-trait-resolution.md => trait-resolution.md} (100%) rename src/{chap-160-trans.md => trans.md} (100%) rename src/{chap-090-ty.md => ty.md} (100%) rename src/{chap-120-type-checking.md => type-checking.md} (100%) rename src/{chap-100-type-inference.md => type-inference.md} (100%) rename src/{chap-030-walkthrough.md => walkthrough.md} (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 1c87e26ce..b1dfa440d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -1,20 +1,20 @@ # Summary -- [About this guide](./chap-000-about-this-guide.md) -- [How to build the compiler and run what you built](./chap-010-how-to-build-and-run.md) -- [Using the compiler testing framework](./chap-020-running-tests.md) -- [Walkthrough: a typical contribution](./chap-030-walkthrough.md) -- [High-level overview of the compiler source](./chap-040-high-level-overview.md) -- [The parser](./chap-050-the-parser.md) -- [Macro expansion](./chap-060-macro-expansion.md) -- [Name resolution](./chap-070-name-resolution.md) -- [HIR lowering](./chap-080-hir-lowering.md) -- [Representing types (`ty` module in depth)](./chap-090-ty.md) -- [Type inference](./chap-100-type-inference.md) -- [Trait resolution](./chap-110-trait-resolution.md) -- [Type checking](./chap-120-type-checking.md) -- [MIR construction](./chap-130-mir-construction.md) -- [MIR borrowck](./chap-140-mir-borrowck.md) -- [MIR optimizations](./chap-150-mir-optimizations.md) -- [trans: generating LLVM IR](./chap-160-trans.md) +- [About this guide](./about-this-guide.md) +- [How to build the compiler and run what you built](./how-to-build-and-run.md) +- [Using the compiler testing framework](./running-tests.md) +- [Walkthrough: a typical contribution](./walkthrough.md) +- [High-level overview of the compiler source](./high-level-overview.md) +- [The parser](./the-parser.md) +- [Macro expansion](./macro-expansion.md) +- [Name resolution](./name-resolution.md) +- [HIR lowering](./hir-lowering.md) +- [Representing types (`ty` module in depth)](./ty.md) +- [Type inference](./type-inference.md) +- [Trait resolution](./trait-resolution.md) +- [Type checking](./type-checking.md) +- [MIR construction](./mir-construction.md) +- [MIR borrowck](./mir-borrowck.md) +- [MIR optimizations](./mir-optimizations.md) +- [trans: generating LLVM IR](./trans.md) - [Glossary](./glossary.md) diff --git a/src/chap-000-about-this-guide.md b/src/about-this-guide.md similarity index 100% rename from src/chap-000-about-this-guide.md rename to src/about-this-guide.md diff --git a/src/chap-040-high-level-overview.md b/src/high-level-overview.md similarity index 100% rename from src/chap-040-high-level-overview.md rename to src/high-level-overview.md diff --git a/src/chap-080-hir-lowering.md b/src/hir-lowering.md similarity index 100% rename from src/chap-080-hir-lowering.md rename to src/hir-lowering.md diff --git a/src/chap-010-how-to-build-and-run.md b/src/how-to-build-and-run.md similarity index 100% rename from src/chap-010-how-to-build-and-run.md rename to src/how-to-build-and-run.md diff --git a/src/chap-060-macro-expansion.md b/src/macro-expansion.md similarity index 100% rename from src/chap-060-macro-expansion.md rename to src/macro-expansion.md diff --git a/src/chap-140-mir-borrowck.md b/src/mir-borrowck.md similarity index 100% rename from src/chap-140-mir-borrowck.md rename to src/mir-borrowck.md diff --git a/src/chap-130-mir-construction.md b/src/mir-construction.md similarity index 100% rename from src/chap-130-mir-construction.md rename to src/mir-construction.md diff --git a/src/chap-150-mir-optimizations.md b/src/mir-optimizations.md similarity index 100% rename from src/chap-150-mir-optimizations.md rename to src/mir-optimizations.md diff --git a/src/chap-070-name-resolution.md b/src/name-resolution.md similarity index 100% rename from src/chap-070-name-resolution.md rename to src/name-resolution.md diff --git a/src/chap-020-running-tests.md b/src/running-tests.md similarity index 100% rename from src/chap-020-running-tests.md rename to src/running-tests.md diff --git a/src/chap-050-the-parser.md b/src/the-parser.md similarity index 100% rename from src/chap-050-the-parser.md rename to src/the-parser.md diff --git a/src/chap-110-trait-resolution.md b/src/trait-resolution.md similarity index 100% rename from src/chap-110-trait-resolution.md rename to src/trait-resolution.md diff --git a/src/chap-160-trans.md b/src/trans.md similarity index 100% rename from src/chap-160-trans.md rename to src/trans.md diff --git a/src/chap-090-ty.md b/src/ty.md similarity index 100% rename from src/chap-090-ty.md rename to src/ty.md diff --git a/src/chap-120-type-checking.md b/src/type-checking.md similarity index 100% rename from src/chap-120-type-checking.md rename to src/type-checking.md diff --git a/src/chap-100-type-inference.md b/src/type-inference.md similarity index 100% rename from src/chap-100-type-inference.md rename to src/type-inference.md diff --git a/src/chap-030-walkthrough.md b/src/walkthrough.md similarity index 100% rename from src/chap-030-walkthrough.md rename to src/walkthrough.md From dfa328fc39a7724803e6f26518609e5b497529ef Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:43:10 -0500 Subject: [PATCH 0009/1812] add in the trait resolution README from rustc --- src/trait-resolution.md | 484 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 484 insertions(+) diff --git a/src/trait-resolution.md b/src/trait-resolution.md index dd16aac62..58efbd050 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -1 +1,485 @@ # Trait resolution + +This document describes the general process and points out some non-obvious +things. + +**WARNING:** This material was moved verbatim from a rustc README, so +it may not "fit" the style of the guide until it is adapted. + +## Major concepts + +Trait resolution is the process of pairing up an impl with each +reference to a trait. So, for example, if there is a generic function like: + +```rust +fn clone_slice(x: &[T]) -> Vec { /*...*/ } +``` + +and then a call to that function: + +```rust +let v: Vec = clone_slice(&[1, 2, 3]) +``` + +it is the job of trait resolution to figure out (in which case) +whether there exists an impl of `isize : Clone` + +Note that in some cases, like generic functions, we may not be able to +find a specific impl, but we can figure out that the caller must +provide an impl. To see what I mean, consider the body of `clone_slice`: + +```rust +fn clone_slice(x: &[T]) -> Vec { + let mut v = Vec::new(); + for e in &x { + v.push((*e).clone()); // (*) + } +} +``` + +The line marked `(*)` is only legal if `T` (the type of `*e`) +implements the `Clone` trait. Naturally, since we don't know what `T` +is, we can't find the specific impl; but based on the bound `T:Clone`, +we can say that there exists an impl which the caller must provide. + +We use the term *obligation* to refer to a trait reference in need of +an impl. + +## Overview + +Trait resolution consists of three major parts: + +- SELECTION: Deciding how to resolve a specific obligation. For + example, selection might decide that a specific obligation can be + resolved by employing an impl which matches the self type, or by + using a parameter bound. In the case of an impl, Selecting one + obligation can create *nested obligations* because of where clauses + on the impl itself. It may also require evaluating those nested + obligations to resolve ambiguities. + +- FULFILLMENT: The fulfillment code is what tracks that obligations + are completely fulfilled. Basically it is a worklist of obligations + to be selected: once selection is successful, the obligation is + removed from the worklist and any nested obligations are enqueued. + +- COHERENCE: The coherence checks are intended to ensure that there + are never overlapping impls, where two impls could be used with + equal precedence. + +## Selection + +Selection is the process of deciding whether an obligation can be +resolved and, if so, how it is to be resolved (via impl, where clause, etc). +The main interface is the `select()` function, which takes an obligation +and returns a `SelectionResult`. There are three possible outcomes: + +- `Ok(Some(selection))` -- yes, the obligation can be resolved, and + `selection` indicates how. If the impl was resolved via an impl, + then `selection` may also indicate nested obligations that are required + by the impl. + +- `Ok(None)` -- we are not yet sure whether the obligation can be + resolved or not. This happens most commonly when the obligation + contains unbound type variables. + +- `Err(err)` -- the obligation definitely cannot be resolved due to a + type error, or because there are no impls that could possibly apply, + etc. + +The basic algorithm for selection is broken into two big phases: +candidate assembly and confirmation. + +### Candidate assembly + +Searches for impls/where-clauses/etc that might +possibly be used to satisfy the obligation. Each of those is called +a candidate. To avoid ambiguity, we want to find exactly one +candidate that is definitively applicable. In some cases, we may not +know whether an impl/where-clause applies or not -- this occurs when +the obligation contains unbound inference variables. + +The basic idea for candidate assembly is to do a first pass in which +we identify all possible candidates. During this pass, all that we do +is try and unify the type parameters. (In particular, we ignore any +nested where clauses.) Presuming that this unification succeeds, the +impl is added as a candidate. + +Once this first pass is done, we can examine the set of candidates. If +it is a singleton set, then we are done: this is the only impl in +scope that could possibly apply. Otherwise, we can winnow down the set +of candidates by using where clauses and other conditions. If this +reduced set yields a single, unambiguous entry, we're good to go, +otherwise the result is considered ambiguous. + +#### The basic process: Inferring based on the impls we see + +This process is easier if we work through some examples. Consider +the following trait: + +```rust +trait Convert { + fn convert(&self) -> Target; +} +``` + +This trait just has one method. It's about as simple as it gets. It +converts from the (implicit) `Self` type to the `Target` type. If we +wanted to permit conversion between `isize` and `usize`, we might +implement `Convert` like so: + +```rust +impl Convert for isize { /*...*/ } // isize -> usize +impl Convert for usize { /*...*/ } // usize -> isize +``` + +Now imagine there is some code like the following: + +```rust +let x: isize = ...; +let y = x.convert(); +``` + +The call to convert will generate a trait reference `Convert<$Y> for +isize`, where `$Y` is the type variable representing the type of +`y`. When we match this against the two impls we can see, we will find +that only one remains: `Convert for isize`. Therefore, we can +select this impl, which will cause the type of `$Y` to be unified to +`usize`. (Note that while assembling candidates, we do the initial +unifications in a transaction, so that they don't affect one another.) + +There are tests to this effect in src/test/run-pass: + + traits-multidispatch-infer-convert-source-and-target.rs + traits-multidispatch-infer-convert-target.rs + +#### Winnowing: Resolving ambiguities + +But what happens if there are multiple impls where all the types +unify? Consider this example: + +```rust +trait Get { + fn get(&self) -> Self; +} + +impl Get for T { + fn get(&self) -> T { *self } +} + +impl Get for Box { + fn get(&self) -> Box { box get_it(&**self) } +} +``` + +What happens when we invoke `get_it(&box 1_u16)`, for example? In this +case, the `Self` type is `Box` -- that unifies with both impls, +because the first applies to all types, and the second to all +boxes. In the olden days we'd have called this ambiguous. But what we +do now is do a second *winnowing* pass that considers where clauses +and attempts to remove candidates -- in this case, the first impl only +applies if `Box : Copy`, which doesn't hold. After winnowing, +then, we are left with just one candidate, so we can proceed. There is +a test of this in `src/test/run-pass/traits-conditional-dispatch.rs`. + +#### Matching + +The subroutines that decide whether a particular impl/where-clause/etc +applies to a particular obligation. At the moment, this amounts to +unifying the self types, but in the future we may also recursively +consider some of the nested obligations, in the case of an impl. + +#### Lifetimes and selection + +Because of how that lifetime inference works, it is not possible to +give back immediate feedback as to whether a unification or subtype +relationship between lifetimes holds or not. Therefore, lifetime +matching is *not* considered during selection. This is reflected in +the fact that subregion assignment is infallible. This may yield +lifetime constraints that will later be found to be in error (in +contrast, the non-lifetime-constraints have already been checked +during selection and can never cause an error, though naturally they +may lead to other errors downstream). + +#### Where clauses + +Besides an impl, the other major way to resolve an obligation is via a +where clause. The selection process is always given a *parameter +environment* which contains a list of where clauses, which are +basically obligations that can assume are satisfiable. We will iterate +over that list and check whether our current obligation can be found +in that list, and if so it is considered satisfied. More precisely, we +want to check whether there is a where-clause obligation that is for +the same trait (or some subtrait) and for which the self types match, +using the definition of *matching* given above. + +Consider this simple example: + +```rust +trait A1 { /*...*/ } +trait A2 : A1 { /*...*/ } + +trait B { /*...*/ } + +fn foo { /*...*/ } +``` + +Clearly we can use methods offered by `A1`, `A2`, or `B` within the +body of `foo`. In each case, that will incur an obligation like `X : +A1` or `X : A2`. The parameter environment will contain two +where-clauses, `X : A2` and `X : B`. For each obligation, then, we +search this list of where-clauses. To resolve an obligation `X:A1`, +we would note that `X:A2` implies that `X:A1`. + +### Confirmation + +Confirmation unifies the output type parameters of the trait with the +values found in the obligation, possibly yielding a type error. If we +return to our example of the `Convert` trait from the previous +section, confirmation is where an error would be reported, because the +impl specified that `T` would be `usize`, but the obligation reported +`char`. Hence the result of selection would be an error. + +### Selection during translation + +During type checking, we do not store the results of trait selection. +We simply wish to verify that trait selection will succeed. Then +later, at trans time, when we have all concrete types available, we +can repeat the trait selection. In this case, we do not consider any +where-clauses to be in scope. We know that therefore each resolution +will resolve to a particular impl. + +One interesting twist has to do with nested obligations. In general, in trans, +we only need to do a "shallow" selection for an obligation. That is, we wish to +identify which impl applies, but we do not (yet) need to decide how to select +any nested obligations. Nonetheless, we *do* currently do a complete resolution, +and that is because it can sometimes inform the results of type inference. That is, +we do not have the full substitutions in terms of the type variables of the impl available +to us, so we must run trait selection to figure everything out. + +Here is an example: + +```rust +trait Foo { /*...*/ } +impl> Foo for Vec { /*...*/ } + +impl Bar for isize { /*...*/ } +``` + +After one shallow round of selection for an obligation like `Vec +: Foo`, we would know which impl we want, and we would know that +`T=isize`, but we do not know the type of `U`. We must select the +nested obligation `isize : Bar` to find out that `U=usize`. + +It would be good to only do *just as much* nested resolution as +necessary. Currently, though, we just do a full resolution. + +# Higher-ranked trait bounds + +One of the more subtle concepts at work are *higher-ranked trait +bounds*. An example of such a bound is `for<'a> MyTrait<&'a isize>`. +Let's walk through how selection on higher-ranked trait references +works. + +## Basic matching and skolemization leaks + +Let's walk through the test `compile-fail/hrtb-just-for-static.rs` to see +how it works. The test starts with the trait `Foo`: + +```rust +trait Foo { + fn foo(&self, x: X) { } +} +``` + +Let's say we have a function `want_hrtb` that wants a type which +implements `Foo<&'a isize>` for any `'a`: + +```rust +fn want_hrtb() where T : for<'a> Foo<&'a isize> { ... } +``` + +Now we have a struct `AnyInt` that implements `Foo<&'a isize>` for any +`'a`: + +```rust +struct AnyInt; +impl<'a> Foo<&'a isize> for AnyInt { } +``` + +And the question is, does `AnyInt : for<'a> Foo<&'a isize>`? We want the +answer to be yes. The algorithm for figuring it out is closely related +to the subtyping for higher-ranked types (which is described in +`middle::infer::higher_ranked::doc`, but also in a [paper by SPJ] that +I recommend you read). + +1. Skolemize the obligation. +2. Match the impl against the skolemized obligation. +3. Check for skolemization leaks. + +[paper by SPJ]: http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ + +So let's work through our example. The first thing we would do is to +skolemize the obligation, yielding `AnyInt : Foo<&'0 isize>` (here `'0` +represents skolemized region #0). Note that now have no quantifiers; +in terms of the compiler type, this changes from a `ty::PolyTraitRef` +to a `TraitRef`. We would then create the `TraitRef` from the impl, +using fresh variables for it's bound regions (and thus getting +`Foo<&'$a isize>`, where `'$a` is the inference variable for `'a`). Next +we relate the two trait refs, yielding a graph with the constraint +that `'0 == '$a`. Finally, we check for skolemization "leaks" -- a +leak is basically any attempt to relate a skolemized region to another +skolemized region, or to any region that pre-existed the impl match. +The leak check is done by searching from the skolemized region to find +the set of regions that it is related to in any way. This is called +the "taint" set. To pass the check, that set must consist *solely* of +itself and region variables from the impl. If the taint set includes +any other region, then the match is a failure. In this case, the taint +set for `'0` is `{'0, '$a}`, and hence the check will succeed. + +Let's consider a failure case. Imagine we also have a struct + +```rust +struct StaticInt; +impl Foo<&'static isize> for StaticInt; +``` + +We want the obligation `StaticInt : for<'a> Foo<&'a isize>` to be +considered unsatisfied. The check begins just as before. `'a` is +skolemized to `'0` and the impl trait reference is instantiated to +`Foo<&'static isize>`. When we relate those two, we get a constraint +like `'static == '0`. This means that the taint set for `'0` is `{'0, +'static}`, which fails the leak check. + +## Higher-ranked trait obligations + +Once the basic matching is done, we get to another interesting topic: +how to deal with impl obligations. I'll work through a simple example +here. Imagine we have the traits `Foo` and `Bar` and an associated impl: + +```rust +trait Foo { + fn foo(&self, x: X) { } +} + +trait Bar { + fn bar(&self, x: X) { } +} + +impl Foo for F + where F : Bar +{ +} +``` + +Now let's say we have a obligation `for<'a> Foo<&'a isize>` and we match +this impl. What obligation is generated as a result? We want to get +`for<'a> Bar<&'a isize>`, but how does that happen? + +After the matching, we are in a position where we have a skolemized +substitution like `X => &'0 isize`. If we apply this substitution to the +impl obligations, we get `F : Bar<&'0 isize>`. Obviously this is not +directly usable because the skolemized region `'0` cannot leak out of +our computation. + +What we do is to create an inverse mapping from the taint set of `'0` +back to the original bound region (`'a`, here) that `'0` resulted +from. (This is done in `higher_ranked::plug_leaks`). We know that the +leak check passed, so this taint set consists solely of the skolemized +region itself plus various intermediate region variables. We then walk +the trait-reference and convert every region in that taint set back to +a late-bound region, so in this case we'd wind up with `for<'a> F : +Bar<&'a isize>`. + +# Caching and subtle considerations therewith + +In general we attempt to cache the results of trait selection. This +is a somewhat complex process. Part of the reason for this is that we +want to be able to cache results even when all the types in the trait +reference are not fully known. In that case, it may happen that the +trait selection process is also influencing type variables, so we have +to be able to not only cache the *result* of the selection process, +but *replay* its effects on the type variables. + +## An example + +The high-level idea of how the cache works is that we first replace +all unbound inference variables with skolemized versions. Therefore, +if we had a trait reference `usize : Foo<$1>`, where `$n` is an unbound +inference variable, we might replace it with `usize : Foo<%0>`, where +`%n` is a skolemized type. We would then look this up in the cache. +If we found a hit, the hit would tell us the immediate next step to +take in the selection process: i.e., apply impl #22, or apply where +clause `X : Foo`. Let's say in this case there is no hit. +Therefore, we search through impls and where clauses and so forth, and +we come to the conclusion that the only possible impl is this one, +with def-id 22: + +```rust +impl Foo for usize { ... } // Impl #22 +``` + +We would then record in the cache `usize : Foo<%0> ==> +ImplCandidate(22)`. Next we would confirm `ImplCandidate(22)`, which +would (as a side-effect) unify `$1` with `isize`. + +Now, at some later time, we might come along and see a `usize : +Foo<$3>`. When skolemized, this would yield `usize : Foo<%0>`, just as +before, and hence the cache lookup would succeed, yielding +`ImplCandidate(22)`. We would confirm `ImplCandidate(22)` which would +(as a side-effect) unify `$3` with `isize`. + +## Where clauses and the local vs global cache + +One subtle interaction is that the results of trait lookup will vary +depending on what where clauses are in scope. Therefore, we actually +have *two* caches, a local and a global cache. The local cache is +attached to the `ParamEnv` and the global cache attached to the +`tcx`. We use the local cache whenever the result might depend on the +where clauses that are in scope. The determination of which cache to +use is done by the method `pick_candidate_cache` in `select.rs`. At +the moment, we use a very simple, conservative rule: if there are any +where-clauses in scope, then we use the local cache. We used to try +and draw finer-grained distinctions, but that led to a serious of +annoying and weird bugs like #22019 and #18290. This simple rule seems +to be pretty clearly safe and also still retains a very high hit rate +(~95% when compiling rustc). + +# Specialization + +Defined in the `specialize` module. + +The basic strategy is to build up a *specialization graph* during +coherence checking. Insertion into the graph locates the right place +to put an impl in the specialization hierarchy; if there is no right +place (due to partial overlap but no containment), you get an overlap +error. Specialization is consulted when selecting an impl (of course), +and the graph is consulted when propagating defaults down the +specialization hierarchy. + +You might expect that the specialization graph would be used during +selection -- i.e., when actually performing specialization. This is +not done for two reasons: + +- It's merely an optimization: given a set of candidates that apply, + we can determine the most specialized one by comparing them directly + for specialization, rather than consulting the graph. Given that we + also cache the results of selection, the benefit of this + optimization is questionable. + +- To build the specialization graph in the first place, we need to use + selection (because we need to determine whether one impl specializes + another). Dealing with this reentrancy would require some additional + mode switch for selection. Given that there seems to be no strong + reason to use the graph anyway, we stick with a simpler approach in + selection, and use the graph only for propagating default + implementations. + +Trait impl selection can succeed even when multiple impls can apply, +as long as they are part of the same specialization family. In that +case, it returns a *single* impl on success -- this is the most +specialized impl *known* to apply. However, if there are any inference +variables in play, the returned impl may not be the actual impl we +will use at trans time. Thus, we take special care to avoid projecting +associated types unless either (1) the associated type does not use +`default` and thus cannot be overridden or (2) all input types are +known concretely. From 761119ef83bd3a4340948bb67bfeb64e1ac486e5 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 06:51:14 -0500 Subject: [PATCH 0010/1812] move over the `ty` README --- src/SUMMARY.md | 2 +- src/ty.md | 166 ++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 166 insertions(+), 2 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b1dfa440d..f8b1f1d6e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -9,7 +9,7 @@ - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) - [HIR lowering](./hir-lowering.md) -- [Representing types (`ty` module in depth)](./ty.md) +- [The `ty` module: representing types](./ty.md) - [Type inference](./type-inference.md) - [Trait resolution](./trait-resolution.md) - [Type checking](./type-checking.md) diff --git a/src/ty.md b/src/ty.md index 1762ce037..8debb71c7 100644 --- a/src/ty.md +++ b/src/ty.md @@ -1 +1,165 @@ -# Representing types (`ty` module in depth) +# The `ty` module: representing types + +The `ty` module defines how the Rust compiler represents types +internally. It also defines the *typing context* (`tcx` or `TyCtxt`), +which is the central data structure in the compiler. + +## The tcx and how it uses lifetimes + +The `tcx` ("typing context") is the central data structure in the +compiler. It is the context that you use to perform all manner of +queries. The struct `TyCtxt` defines a reference to this shared context: + +```rust +tcx: TyCtxt<'a, 'gcx, 'tcx> +// -- ---- ---- +// | | | +// | | innermost arena lifetime (if any) +// | "global arena" lifetime +// lifetime of this reference +``` + +As you can see, the `TyCtxt` type takes three lifetime parameters. +These lifetimes are perhaps the most complex thing to understand about +the tcx. During Rust compilation, we allocate most of our memory in +**arenas**, which are basically pools of memory that get freed all at +once. When you see a reference with a lifetime like `'tcx` or `'gcx`, +you know that it refers to arena-allocated data (or data that lives as +long as the arenas, anyhow). + +We use two distinct levels of arenas. The outer level is the "global +arena". This arena lasts for the entire compilation: so anything you +allocate in there is only freed once compilation is basically over +(actually, when we shift to executing LLVM). + +To reduce peak memory usage, when we do type inference, we also use an +inner level of arena. These arenas get thrown away once type inference +is over. This is done because type inference generates a lot of +"throw-away" types that are not particularly interesting after type +inference completes, so keeping around those allocations would be +wasteful. + +Often, we wish to write code that explicitly asserts that it is not +taking place during inference. In that case, there is no "local" +arena, and all the types that you can access are allocated in the +global arena. To express this, the idea is to use the same lifetime +for the `'gcx` and `'tcx` parameters of `TyCtxt`. Just to be a touch +confusing, we tend to use the name `'tcx` in such contexts. Here is an +example: + +```rust +fn not_in_inference<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) { + // ---- ---- + // Using the same lifetime here asserts + // that the innermost arena accessible through + // this reference *is* the global arena. +} +``` + +In contrast, if we want to code that can be usable during type inference, then you +need to declare a distinct `'gcx` and `'tcx` lifetime parameter: + +```rust +fn maybe_in_inference<'a, 'gcx, 'tcx>(tcx: TyCtxt<'a, 'gcx, 'tcx>, def_id: DefId) { + // ---- ---- + // Using different lifetimes here means that + // the innermost arena *may* be distinct + // from the global arena (but doesn't have to be). +} +``` + +### Allocating and working with types + +Rust types are represented using the `Ty<'tcx>` defined in the `ty` +module (not to be confused with the `Ty` struct from [the HIR]). This +is in fact a simple type alias for a reference with `'tcx` lifetime: + +```rust +pub type Ty<'tcx> = &'tcx TyS<'tcx>; +``` + +[the HIR]: ../hir/README.md + +You can basically ignore the `TyS` struct -- you will basically never +access it explicitly. We always pass it by reference using the +`Ty<'tcx>` alias -- the only exception I think is to define inherent +methods on types. Instances of `TyS` are only ever allocated in one of +the rustc arenas (never e.g. on the stack). + +One common operation on types is to **match** and see what kinds of +types they are. This is done by doing `match ty.sty`, sort of like this: + +```rust +fn test_type<'tcx>(ty: Ty<'tcx>) { + match ty.sty { + ty::TyArray(elem_ty, len) => { ... } + ... + } +} +``` + +The `sty` field (the origin of this name is unclear to me; perhaps +structural type?) is of type `TypeVariants<'tcx>`, which is an enum +defining all of the different kinds of types in the compiler. + +> NB: inspecting the `sty` field on types during type inference can be +> risky, as there may be inference variables and other things to +> consider, or sometimes types are not yet known that will become +> known later.). + +To allocate a new type, you can use the various `mk_` methods defined +on the `tcx`. These have names that correpond mostly to the various kinds +of type variants. For example: + +```rust +let array_ty = tcx.mk_array(elem_ty, len * 2); +``` + +These methods all return a `Ty<'tcx>` -- note that the lifetime you +get back is the lifetime of the innermost arena that this `tcx` has +access to. In fact, types are always canonicalized and interned (so we +never allocate exactly the same type twice) and are always allocated +in the outermost arena where they can be (so, if they do not contain +any inference variables or other "temporary" types, they will be +allocated in the global arena). However, the lifetime `'tcx` is always +a safe approximation, so that is what you get back. + +> NB. Because types are interned, it is possible to compare them for +> equality efficiently using `==` -- however, this is almost never what +> you want to do unless you happen to be hashing and looking for +> duplicates. This is because often in Rust there are multiple ways to +> represent the same type, particularly once inference is involved. If +> you are going to be testing for type equality, you probably need to +> start looking into the inference code to do it right. + +You can also find various common types in the `tcx` itself by accessing +`tcx.types.bool`, `tcx.types.char`, etc (see `CommonTypes` for more). + +### Beyond types: Other kinds of arena-allocated data structures + +In addition to types, there are a number of other arena-allocated data +structures that you can allocate, and which are found in this +module. Here are a few examples: + +- `Substs`, allocated with `mk_substs` -- this will intern a slice of types, often used to + specify the values to be substituted for generics (e.g., `HashMap` + would be represented as a slice `&'tcx [tcx.types.i32, tcx.types.u32]`). +- `TraitRef`, typically passed by value -- a **trait reference** + consists of a reference to a trait along with its various type + parameters (including `Self`), like `i32: Display` (here, the def-id + would reference the `Display` trait, and the substs would contain + `i32`). +- `Predicate` defines something the trait system has to prove (see `traits` module). + +### Import conventions + +Although there is no hard and fast rule, the `ty` module tends to be used like so: + +```rust +use ty::{self, Ty, TyCtxt}; +``` + +In particular, since they are so common, the `Ty` and `TyCtxt` types +are imported directly. Other types are often referenced with an +explicit `ty::` prefix (e.g., `ty::TraitRef<'tcx>`). But some modules +choose to import a larger or smaller set of names explicitly. From 74916aa83dea2a22593bfd12d870143614151854 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 07:28:19 -0500 Subject: [PATCH 0011/1812] invoke `cargo` to install mdbook --- .travis.yml | 2 +- ci/install.sh | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index e1fcfa9bf..5978c61d8 100644 --- a/.travis.yml +++ b/.travis.yml @@ -3,8 +3,8 @@ language: rust cache: pip install: - - bash ci/install.sh - source ~/.cargo/env || true + - bash ci/install.sh script: - true diff --git a/ci/install.sh b/ci/install.sh index d9cb369e5..dd96daf17 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -1,6 +1,8 @@ #!/bin/bash set -ex +cargo install cargo install mdbook --vers "0.0.28" + if command -v ghp-import >/dev/null 2>&1; then pip install ghp-import -fi \ No newline at end of file +fi From 15ff0b7ef1f318fd49904aedf6f4b531612ed59b Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 19 Jan 2018 14:48:35 -0500 Subject: [PATCH 0012/1812] improvements to travis setup -- cache, use command -v --- .travis.yml | 4 +++- ci/install.sh | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index 5978c61d8..36c3719f0 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,6 +1,8 @@ language: rust -cache: pip +cache: +- pip +- cargo install: - source ~/.cargo/env || true diff --git a/ci/install.sh b/ci/install.sh index dd96daf17..fac6488b6 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -1,7 +1,9 @@ #!/bin/bash set -ex -cargo install cargo install mdbook --vers "0.0.28" +if command -v mdbook >/dev/null 2>&1; then + cargo install mdbook --vers "0.0.28" +fi if command -v ghp-import >/dev/null 2>&1; then pip install ghp-import From 3c98b0f1894e4423d986ae9762c66dc015aa420a Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 20 Jan 2018 22:13:39 +0800 Subject: [PATCH 0013/1812] Started working on the parser chapter --- src/the-parser.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/src/the-parser.md b/src/the-parser.md index ab756895a..a43ae3398 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -1 +1,14 @@ -# The parser +# The Parser + +The parser is responsible for converting raw Rust source code into a structured +form which is easier for the compiler to work with, usually called an *Abstract +Syntax Tree*. The bulk of the parser lives in the [libsyntax] crate. + +The parsing process is made up of roughly 3 stages, + +- lexical analysis - turn a stream of characters into a stream of token trees +- macro expansion - run `proc-macros` and expand `macro_rules` macros +- parsing - turn the token trees into an AST + + +[libsyntax]: https://github.com/rust-lang/rust/tree/master/src/libsyntax From a86602e8f2cbc54946d19f99c9332bc85b068dea Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 10:46:33 -0500 Subject: [PATCH 0014/1812] add an encrypted auth token --- .travis.yml | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/.travis.yml b/.travis.yml index 36c3719f0..4a2381fa7 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,19 +1,17 @@ language: rust - cache: - pip - cargo - install: - - source ~/.cargo/env || true - - bash ci/install.sh - +- source ~/.cargo/env || true +- bash ci/install.sh script: - - true - +- true after_success: - - bash ci/github_pages.sh - +- bash ci/github_pages.sh notifications: email: - on_success: never \ No newline at end of file + on_success: never +env: + global: + secure: EzIPKgJnOk8W0CPK2r6xQv02mV0L2NZJsoWlf3KEHs/ZSskzQEcN18V05/N6H6D4RazRu/UqtWqATV96vZHlmevWkU4PVYz/0UvHfPnu/TbEKBxY/BdJdLIuaNwXVIQ8EnRqVFcRUo/M9xlKk/8mlwVzhPRot8oJQmWDrOqZQgoABFFiU1/OktBz3BtTneR66hqs0rC1tNJyzNh+y2b0qn9Su+N3bp5AXDx5FvDyAKWUfPwP1sRh3xM7oF+0XCnjKKeMYENx7ZltKVQeYSCIHZjBnDIfKX2V1bwKHHrUMrQosJf4lmKsrvdP3sEYUQIIXtY80lA+18yDBhQCKIjh4JyuEisYDMYeYJc2WhUjYaS14WuqnyzRgMMf1EAIwBZgmcsLE2S31csHXXgTWSwwEPzC07erqEsc3nldSQWUbvV9EkFQRXNqMkvyXNt8BQDgSifVw+v0AUBIAr462YlbAN+dk/Ldnd++JPQ6kdrOmegE5B/Ukv+LwFzr9oog2V66TL2STMk8o5ffYWrFGijUfSbMLXIoPRxNj+jFMfAW346tyNCCVKqCexNZV4yUID0f+/zCzcL+DAK1c2hlO4vMQ2fIu2McNKk8RMrMwVsYZhr5jOIvRAkAuaOKZIY+RAsE1VF+G4iGY+UtT89hergHWAdDeFZB+z8OHr1uvaaTQC0= From 33c2b4c5f4621dbce5993b503df21ab67558ffa4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 10:50:15 -0500 Subject: [PATCH 0015/1812] make `github_pages.sh` more chatty --- ci/github_pages.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ci/github_pages.sh b/ci/github_pages.sh index 603b280f9..f5dd7898b 100644 --- a/ci/github_pages.sh +++ b/ci/github_pages.sh @@ -7,4 +7,6 @@ BOOK_DIR=book if [ "$TRAVIS_BRANCH" = master -a "$TRAVIS_PULL_REQUEST" = false ]; then mdbook build ghp-import $BOOK_DIR -fi \ No newline at end of file +else + echo Skipping 'mdbook build' because this is not master or this is just a PR. +fi From a396e910dd694c47b5f0ea44f946c6136e69d9bb Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 10:55:16 -0500 Subject: [PATCH 0016/1812] make install.sh tell us what it is installing and why --- ci/install.sh | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ci/install.sh b/ci/install.sh index fac6488b6..6cef274f8 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -2,9 +2,15 @@ set -ex if command -v mdbook >/dev/null 2>&1; then + echo "installing mdbook" cargo install mdbook --vers "0.0.28" +else + echo "mdbook already installed at $(which mdbook)" fi if command -v ghp-import >/dev/null 2>&1; then + echo "installing ghp-import" pip install ghp-import +else + echo "ghp-import already installed at $(which ghp-import)" fi From cce6a2808165fd28ed55cfaa6f73003d3b4fabe5 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 10:58:54 -0500 Subject: [PATCH 0017/1812] invert the sense of `command -v` --- ci/install.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ci/install.sh b/ci/install.sh index 6cef274f8..49a251d44 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -2,15 +2,15 @@ set -ex if command -v mdbook >/dev/null 2>&1; then + echo "mdbook already installed at $(command -v mdbook)" +else echo "installing mdbook" cargo install mdbook --vers "0.0.28" -else - echo "mdbook already installed at $(which mdbook)" fi if command -v ghp-import >/dev/null 2>&1; then + echo "ghp-import already installed at $(which ghp-import)" +else echo "installing ghp-import" pip install ghp-import -else - echo "ghp-import already installed at $(which ghp-import)" fi From 11bb542a9c205ec00f9e86bab352b5bb803130be Mon Sep 17 00:00:00 2001 From: Phil Ellison Date: Tue, 23 Jan 2018 20:04:27 +0000 Subject: [PATCH 0018/1812] Copy contents of README.md from librustc/hir --- src/hir-lowering.md | 118 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) diff --git a/src/hir-lowering.md b/src/hir-lowering.md index b2b6a7cdf..e28bb4cd4 100644 --- a/src/hir-lowering.md +++ b/src/hir-lowering.md @@ -1 +1,119 @@ # HIR lowering + +The HIR -- "High-level IR" -- is the primary IR used in most of +rustc. It is a desugared version of the "abstract syntax tree" (AST) +that is generated after parsing, macro expansion, and name resolution +have completed. Many parts of HIR resemble Rust surface syntax quite +closely, with the exception that some of Rust's expression forms have +been desugared away (as an example, `for` loops are converted into a +`loop` and do not appear in the HIR). + +This chapter covers the main concepts of the HIR. + +### Out-of-band storage and the `Crate` type + +The top-level data-structure in the HIR is the `Crate`, which stores +the contents of the crate currently being compiled (we only ever +construct HIR for the current crate). Whereas in the AST the crate +data structure basically just contains the root module, the HIR +`Crate` structure contains a number of maps and other things that +serve to organize the content of the crate for easier access. + +For example, the contents of individual items (e.g., modules, +functions, traits, impls, etc) in the HIR are not immediately +accessible in the parents. So, for example, if had a module item `foo` +containing a function `bar()`: + +``` +mod foo { + fn bar() { } +} +``` + +Then in the HIR the representation of module `foo` (the `Mod` +stuct) would have only the **`ItemId`** `I` of `bar()`. To get the +details of the function `bar()`, we would lookup `I` in the +`items` map. + +One nice result from this representation is that one can iterate +over all items in the crate by iterating over the key-value pairs +in these maps (without the need to trawl through the IR in total). +There are similar maps for things like trait items and impl items, +as well as "bodies" (explained below). + +The other reason to setup the representation this way is for better +integration with incremental compilation. This way, if you gain access +to a `&hir::Item` (e.g. for the mod `foo`), you do not immediately +gain access to the contents of the function `bar()`. Instead, you only +gain access to the **id** for `bar()`, and you must invoke some +function to lookup the contents of `bar()` given its id; this gives us +a chance to observe that you accessed the data for `bar()` and record +the dependency. + +### Identifiers in the HIR + +Most of the code that has to deal with things in HIR tends not to +carry around references into the HIR, but rather to carry around +*identifier numbers* (or just "ids"). Right now, you will find four +sorts of identifiers in active use: + +- `DefId`, which primarily names "definitions" or top-level items. + - You can think of a `DefId` as being shorthand for a very explicit + and complete path, like `std::collections::HashMap`. However, + these paths are able to name things that are not nameable in + normal Rust (e.g., impls), and they also include extra information + about the crate (such as its version number, as two versions of + the same crate can co-exist). + - A `DefId` really consists of two parts, a `CrateNum` (which + identifies the crate) and a `DefIndex` (which indixes into a list + of items that is maintained per crate). +- `HirId`, which combines the index of a particular item with an + offset within that item. + - the key point of a `HirId` is that it is *relative* to some item (which is named + via a `DefId`). +- `BodyId`, this is an absolute identifier that refers to a specific + body (definition of a function or constant) in the crate. It is currently + effectively a "newtype'd" `NodeId`. +- `NodeId`, which is an absolute id that identifies a single node in the HIR tree. + - While these are still in common use, **they are being slowly phased out**. + - Since they are absolute within the crate, adding a new node + anywhere in the tree causes the node-ids of all subsequent code in + the crate to change. This is terrible for incremental compilation, + as you can perhaps imagine. + +### HIR Map + +Most of the time when you are working with the HIR, you will do so via +the **HIR Map**, accessible in the tcx via `tcx.hir` (and defined in +the `hir::map` module). The HIR map contains a number of methods to +convert between ids of various kinds and to lookup data associated +with a HIR node. + +For example, if you have a `DefId`, and you would like to convert it +to a `NodeId`, you can use `tcx.hir.as_local_node_id(def_id)`. This +returns an `Option` -- this will be `None` if the def-id +refers to something outside of the current crate (since then it has no +HIR node), but otherwise returns `Some(n)` where `n` is the node-id of +the definition. + +Similarly, you can use `tcx.hir.find(n)` to lookup the node for a +`NodeId`. This returns a `Option>`, where `Node` is an enum +defined in the map; by matching on this you can find out what sort of +node the node-id referred to and also get a pointer to the data +itself. Often, you know what sort of node `n` is -- e.g., if you know +that `n` must be some HIR expression, you can do +`tcx.hir.expect_expr(n)`, which will extract and return the +`&hir::Expr`, panicking if `n` is not in fact an expression. + +Finally, you can use the HIR map to find the parents of nodes, via +calls like `tcx.hir.get_parent_node(n)`. + +### HIR Bodies + +A **body** represents some kind of executable code, such as the body +of a function/closure or the definition of a constant. Bodies are +associated with an **owner**, which is typically some kind of item +(e.g., a `fn()` or `const`), but could also be a closure expression +(e.g., `|x, y| x + y`). You can use the HIR map to find the body +associated with a given def-id (`maybe_body_owned_by()`) or to find +the owner of a body (`body_owner_def_id()`). \ No newline at end of file From 952ab0e050146b25e2c0f109a5e8330074ec6cf4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 16:36:56 -0500 Subject: [PATCH 0019/1812] try pip install --user --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index 49a251d44..2d32caaa9 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -12,5 +12,5 @@ if command -v ghp-import >/dev/null 2>&1; then echo "ghp-import already installed at $(which ghp-import)" else echo "installing ghp-import" - pip install ghp-import + pip install --user ghp-import fi From 3a583ec819d9fcfd13106433ecc4daf71cd381f2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 17:12:26 -0500 Subject: [PATCH 0020/1812] add `-p` flag to `ghp-import` so that it pushes --- ci/github_pages.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/github_pages.sh b/ci/github_pages.sh index f5dd7898b..b0dc26902 100644 --- a/ci/github_pages.sh +++ b/ci/github_pages.sh @@ -6,7 +6,7 @@ BOOK_DIR=book # Only upload the built book to github pages if it's a commit to master if [ "$TRAVIS_BRANCH" = master -a "$TRAVIS_PULL_REQUEST" = false ]; then mdbook build - ghp-import $BOOK_DIR + ghp-import -p $BOOK_DIR else echo Skipping 'mdbook build' because this is not master or this is just a PR. fi From 1e6fdb45a247910c04ed9d574a4f4dde5b932b2d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 23 Jan 2018 21:45:25 -0500 Subject: [PATCH 0021/1812] try to use travis's builtin deploy workflow --- .travis.yml | 7 +++++++ ci/github_pages.sh | 1 - 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 4a2381fa7..7ecd57fd0 100644 --- a/.travis.yml +++ b/.travis.yml @@ -15,3 +15,10 @@ notifications: env: global: secure: EzIPKgJnOk8W0CPK2r6xQv02mV0L2NZJsoWlf3KEHs/ZSskzQEcN18V05/N6H6D4RazRu/UqtWqATV96vZHlmevWkU4PVYz/0UvHfPnu/TbEKBxY/BdJdLIuaNwXVIQ8EnRqVFcRUo/M9xlKk/8mlwVzhPRot8oJQmWDrOqZQgoABFFiU1/OktBz3BtTneR66hqs0rC1tNJyzNh+y2b0qn9Su+N3bp5AXDx5FvDyAKWUfPwP1sRh3xM7oF+0XCnjKKeMYENx7ZltKVQeYSCIHZjBnDIfKX2V1bwKHHrUMrQosJf4lmKsrvdP3sEYUQIIXtY80lA+18yDBhQCKIjh4JyuEisYDMYeYJc2WhUjYaS14WuqnyzRgMMf1EAIwBZgmcsLE2S31csHXXgTWSwwEPzC07erqEsc3nldSQWUbvV9EkFQRXNqMkvyXNt8BQDgSifVw+v0AUBIAr462YlbAN+dk/Ldnd++JPQ6kdrOmegE5B/Ukv+LwFzr9oog2V66TL2STMk8o5ffYWrFGijUfSbMLXIoPRxNj+jFMfAW346tyNCCVKqCexNZV4yUID0f+/zCzcL+DAK1c2hlO4vMQ2fIu2McNKk8RMrMwVsYZhr5jOIvRAkAuaOKZIY+RAsE1VF+G4iGY+UtT89hergHWAdDeFZB+z8OHr1uvaaTQC0= +deploy: + provider: pages + skip-cleanup: true + github-token: $GITHUB_TOKEN + local-dir: book + on: + branch: master \ No newline at end of file diff --git a/ci/github_pages.sh b/ci/github_pages.sh index b0dc26902..ffd89ad52 100644 --- a/ci/github_pages.sh +++ b/ci/github_pages.sh @@ -6,7 +6,6 @@ BOOK_DIR=book # Only upload the built book to github pages if it's a commit to master if [ "$TRAVIS_BRANCH" = master -a "$TRAVIS_PULL_REQUEST" = false ]; then mdbook build - ghp-import -p $BOOK_DIR else echo Skipping 'mdbook build' because this is not master or this is just a PR. fi From 67da39e4b354cc5f2f367d730e90df6efa502aca Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 24 Jan 2018 04:17:48 -0500 Subject: [PATCH 0022/1812] try adjusting secure password again --- .travis.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index 7ecd57fd0..2d107794f 100644 --- a/.travis.yml +++ b/.travis.yml @@ -14,11 +14,11 @@ notifications: on_success: never env: global: - secure: EzIPKgJnOk8W0CPK2r6xQv02mV0L2NZJsoWlf3KEHs/ZSskzQEcN18V05/N6H6D4RazRu/UqtWqATV96vZHlmevWkU4PVYz/0UvHfPnu/TbEKBxY/BdJdLIuaNwXVIQ8EnRqVFcRUo/M9xlKk/8mlwVzhPRot8oJQmWDrOqZQgoABFFiU1/OktBz3BtTneR66hqs0rC1tNJyzNh+y2b0qn9Su+N3bp5AXDx5FvDyAKWUfPwP1sRh3xM7oF+0XCnjKKeMYENx7ZltKVQeYSCIHZjBnDIfKX2V1bwKHHrUMrQosJf4lmKsrvdP3sEYUQIIXtY80lA+18yDBhQCKIjh4JyuEisYDMYeYJc2WhUjYaS14WuqnyzRgMMf1EAIwBZgmcsLE2S31csHXXgTWSwwEPzC07erqEsc3nldSQWUbvV9EkFQRXNqMkvyXNt8BQDgSifVw+v0AUBIAr462YlbAN+dk/Ldnd++JPQ6kdrOmegE5B/Ukv+LwFzr9oog2V66TL2STMk8o5ffYWrFGijUfSbMLXIoPRxNj+jFMfAW346tyNCCVKqCexNZV4yUID0f+/zCzcL+DAK1c2hlO4vMQ2fIu2McNKk8RMrMwVsYZhr5jOIvRAkAuaOKZIY+RAsE1VF+G4iGY+UtT89hergHWAdDeFZB+z8OHr1uvaaTQC0= + secure: YQX/AWq5KsvAFYqcCK6c1DmOZX9EMrecBM5qnc4uE2HvEBS+x0l8xatI2Nv8U9eiasZYfsqmHn0ANvxu6e4oqL15m4cVsdliCzdkrPsDapxTnwwJvMQg+yHZiEd5BPlaDQt/wYvP8QBXgQsXoAJKrfAS+BFsowBFHt/LOFOunbAQrtQZqwqrnI6+xh+2TRMckws/VcTLRqwl3pyEyfacJhbbv1V3gJh7Y17hELsgsP7+7cMXT0bK6dtf7a9vne9Hsm5fw7VeMKBn1/dJ82fyEK6HHjkjdw1/OoY35YVyNZ/9ZxP2u1ClEXzCRJQ2CvKr8Tuoh/AuoL0pwrfhOTaOuWU0QZT4QBqjTimsgBLqiJicMiSndgsXinLWvlDqrMS1XfleqCKqAQy9AJTCR1LnwR90/HRxfE5YDAL/mbc0Su4jj+l5Zv3UE8vUqFE34E/jzip17JkDT5aMkl4bgW65lqJE7SLWl7gXT7eYbPEtQZoucR1hkSsBu/4YTvcxSlD98spWZ68mWwYyjLJSQDES+GefUnHJ/RbBVl9pW+sL7jXJ+kZ/NBCtCIgrkGchudEMDEvS6rcOzwCejxqL1of0jYHGopkBXSVHOPneWIdNeKXwBZA9hp0yKh0sWwrKHrA3wYhS/kF9uO19l/RnSTXAfApYR/yJUbYliuMJYCgNeKE= deploy: provider: pages skip-cleanup: true github-token: $GITHUB_TOKEN local-dir: book on: - branch: master \ No newline at end of file + branch: master From c44964bd148d23a68f560a07c6d88117c564546a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 24 Jan 2018 09:11:24 -0500 Subject: [PATCH 0023/1812] how to build and run compiler, first shot --- src/how-to-build-and-run.md | 117 ++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 505836094..de8a93bdd 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -1 +1,118 @@ # How to build the compiler and run what you built + +The compiler is built using a tool called `x.py`. You will need to +have Python installed to run it. But before we get to that, if you're going to +be hacking on rustc, you'll want to tweak the configuration of the compiler. The default +configuration is oriented towards running the compiler as a user, not a developer. + +### Create a config.toml + +To start, copy [`config.toml.example`] to `config.toml`: + +[`config.toml.example`]: https://github.com/rust-lang/rust/blob/master/config.toml.example + +```bash +> cd $RUST_CHECKOUT +> cp config.toml.example config.toml +``` + +Then you will want to open up the file and change the following +settings (and possibly others, such as `llvm.ccache`): + +``` +[llvm] +# Enables LLVM assertions, which will check that the LLVM bitcode generated +# by the compiler is internally consistent. These are particularly helpful +# if you edit `trans`. +assertions = true + +[rust] +# This enables some assertions, but more importantly it enables the `debug!` logging +# macros that are essential for debugging rustc. +debug-assertions = true + +# This will make your build more parallel; it costs a bit of runtime +# performance perhaps (less inlining) but it's worth it. +codegen-units = 0 + +# I always enable full debuginfo, though debuginfo-lines is more important. +debuginfo = true + +# Gives you line numbers for backtraces. +debuginfo-lines = true + +# Using the system allocator (instead of jemalloc) means that tools +# like valgrind and memcache work better. +use-jemalloc = false +``` + +### Running x.py and building a stage1 compiler + +Once you've created a config.toml, you are now ready to run +`x.py`. There are a lot of options here, but let's start with what is +probably the best "go to" command for building a local rust: + +``` +./x.py build --incremental --stage 1 src/libstd +``` + +What this command will do is the following: + +- Using the beta compiler (also called stage 0), it will build the + standard library and rustc from the `src` directory. The resulting + compiler is called the "stage 1" compiler. + - During this build, the `--incremental` switch enables incremental + compilation, so that if you later rebuild after editing things in + `src`, you can save a bit of time. +- Using this stage 1 compiler, it will build the standard library. + (this is what the `src/libstd`) means. + +This is just a subset of the full rustc build. The **full** rustc build (what you +get if you just say `./x.py build`) has quite a few more steps: + +- Build stage1 rustc with stage0 compiler +- Build libstd with stage1 compiler (up to here is the same) +- Build stage2 rustc with stage1 compiler (this part is new) +- Build libstd with stage2 compiler +- Build librustdoc and a bunch of other things + +### Creating a rustup toolchain + +Once you have successfully built rustc, you will have created a bunch +of files in your `build` directory. In order to actually run the +resulting rustc, we recommend creating rustup toolchains. The first +one will run the stage1 compiler (which we built above). The second +will execute the stage2 compiler (which we did not build, but which +you will likely build at some point). + +``` +> rustup toolchain link stage1 build//stage1 +> rustup toolchain link stage2 build//stage2 +``` + +Now you can run the rustc you built with. If you run with `-vV`, you +should see a version number ending in `-dev`, indicating a build from +your local environment: + +``` +> rustc +stage1 -vV +rustc 1.25.0-dev +binary: rustc +commit-hash: unknown +commit-date: unknown +host: x86_64-unknown-linux-gnu +release: 1.25.0-dev +LLVM version: 4.0 +``` + +### Other x.py commands + +Here are a few other useful x.py commands. We'll cover some of them in detail in other sections: + +- Building things: + - `./x.py clean` -- clean up the build directory (`rm -rf build` works too, but then you have to rebuild LLVM) + - `./x.py build --stage 1` -- builds everything using the stage 1 compiler, not just up to libstd + - `./x.py build` -- builds the stage2 compiler +- Running tests (see the section [running tests](./running-tests.html) for more details): + - `./x.py test --stage 1 src/libstd` -- runs the `#[test]` tests from libstd + - `./x.py test --stage 1 src/test/run-pass` -- runs the `run-pass` test suite From b2a850faf0fd2e5b246ea2b7938ea288bfbca2a5 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Thu, 25 Jan 2018 00:30:52 +0800 Subject: [PATCH 0024/1812] Mentioned the main players in the parser --- src/the-parser.md | 36 ++++++++++++++++++++++++++++++++---- 1 file changed, 32 insertions(+), 4 deletions(-) diff --git a/src/the-parser.md b/src/the-parser.md index a43ae3398..9a01d8a36 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -1,14 +1,42 @@ # The Parser The parser is responsible for converting raw Rust source code into a structured -form which is easier for the compiler to work with, usually called an *Abstract -Syntax Tree*. The bulk of the parser lives in the [libsyntax] crate. +form which is easier for the compiler to work with, usually called an [*Abstract +Syntax Tree*][ast]. An AST mirrors the structure of a Rust program in memory, +using a `Span` to link a particular AST node back to its source text. -The parsing process is made up of roughly 3 stages, +The bulk of the parser lives in the [libsyntax] crate. + +Like most parsers, the parsing process is composed of two main steps, - lexical analysis - turn a stream of characters into a stream of token trees -- macro expansion - run `proc-macros` and expand `macro_rules` macros - parsing - turn the token trees into an AST +The `syntax` crate contains several main players, + +- a [`CodeMap`] for mapping AST nodes to their source code +- the [ast module] contains types corresponding to each AST node +- a [`StringReader`] for lexing source code into tokens +- the [parser module] and [`Parser`] struct are in charge of actually parsing + tokens into AST nodes, +- and a [visit module] for walking the AST and inspecting or mutating the AST + nodes. + +The main entrypoint to the parser is via the various `parse_*` functions +in the [parser module]. They let you do things like turn a filemap into a +token stream, create a parser from the token stream, and then execute the +parser to get a `Crate` (the root AST node). + +To minimise the amount of copying that is done, both the `StringReader` and +`Parser` have lifetimes which bind them to the parent `ParseSess`. This contains +all the information needed while parsing, as well as the `CodeMap` itself. [libsyntax]: https://github.com/rust-lang/rust/tree/master/src/libsyntax +[rustc_errors]: https://github.com/rust-lang/rust/tree/master/src/librustc_errors +[ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree +[`CodeMap`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs +[ast module]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast.rs +[parser module]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/parse +[`Parser`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/parser.rs +[`StringReader`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs +[visit module]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/visit.rs \ No newline at end of file From 3b142e54c23bf615eda3de5d1cd42289f86bcab0 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 25 Jan 2018 09:40:07 -0500 Subject: [PATCH 0025/1812] fix nits --- src/how-to-build-and-run.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index de8a93bdd..f685f569c 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -19,7 +19,7 @@ To start, copy [`config.toml.example`] to `config.toml`: Then you will want to open up the file and change the following settings (and possibly others, such as `llvm.ccache`): -``` +```toml [llvm] # Enables LLVM assertions, which will check that the LLVM bitcode generated # by the compiler is internally consistent. These are particularly helpful @@ -53,7 +53,7 @@ Once you've created a config.toml, you are now ready to run probably the best "go to" command for building a local rust: ``` -./x.py build --incremental --stage 1 src/libstd +./x.py build -i --stage 1 src/libstd ``` What this command will do is the following: @@ -61,7 +61,7 @@ What this command will do is the following: - Using the beta compiler (also called stage 0), it will build the standard library and rustc from the `src` directory. The resulting compiler is called the "stage 1" compiler. - - During this build, the `--incremental` switch enables incremental + - During this build, the `-i` (or `--incremental`) switch enables incremental compilation, so that if you later rebuild after editing things in `src`, you can save a bit of time. - Using this stage 1 compiler, it will build the standard library. @@ -72,7 +72,8 @@ get if you just say `./x.py build`) has quite a few more steps: - Build stage1 rustc with stage0 compiler - Build libstd with stage1 compiler (up to here is the same) -- Build stage2 rustc with stage1 compiler (this part is new) +- Build rustc from `src` again, this time with the stage1 compiler (this part is new) + - The resulting compiler here is called the "stage2" compiler - Build libstd with stage2 compiler - Build librustdoc and a bunch of other things @@ -83,7 +84,8 @@ of files in your `build` directory. In order to actually run the resulting rustc, we recommend creating rustup toolchains. The first one will run the stage1 compiler (which we built above). The second will execute the stage2 compiler (which we did not build, but which -you will likely build at some point). +you will likely need to build at some point; for example, if you want +to run the entire test suite). ``` > rustup toolchain link stage1 build//stage1 From 1627505cab834ed269b8b28a5772731b21067a91 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 25 Jan 2018 15:56:06 -0600 Subject: [PATCH 0026/1812] Start macro expansion chapter --- src/macro-expansion.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 12b95cb6c..7ab1c35bc 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -1 +1,12 @@ # Macro expansion + +Macro expansion happens during parsing. `rustc` has two parsers, in fact: the +normal Rust parser, and the macro parser. During the parsing phase, the normal +Rust parser will call into the macro parser when it encounters a macro. The +macro parser, in turn, may call back out to the Rust parser when it needs to +bind a metavariable (e.g. `$expr`). There are a few aspects of this system to be +explained. The code for macro expansion is in `src/libsyntax/ext/tt/`. + +TODO: explain parsing of macro definitions + +TODO: explain parsing of macro invokations + macro expansion From 4992b476289894fcd4de62a957bf52ea35af5491 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 25 Jan 2018 17:56:33 -0600 Subject: [PATCH 0027/1812] Add a bit about macro expansion --- src/src/chap-060-macro-expansion.md | 66 +++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 src/src/chap-060-macro-expansion.md diff --git a/src/src/chap-060-macro-expansion.md b/src/src/chap-060-macro-expansion.md new file mode 100644 index 000000000..77f764d6a --- /dev/null +++ b/src/src/chap-060-macro-expansion.md @@ -0,0 +1,66 @@ +# Macro expansion + +Macro expansion happens during parsing. `rustc` has two parsers, in fact: the +normal Rust parser, and the macro parser. During the parsing phase, the normal +Rust parser will call into the macro parser when it encounters a macro. The +macro parser, in turn, may call back out to the Rust parser when it needs to +bind a metavariable (e.g. `$my_expr`). There are a few aspects of this system to +be explained. The code for macro expansion is in `src/libsyntax/ext/tt/`. + +### The macro parser + +Basically, the macro parser is like an NFA-based regex parser. It uses an +algorithm similar in spirit to the [Earley parsing +algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is +defined in `src/libsyntax/ext/tt/macro_parser.rs`. + +In a traditional NFA-based parser, one common approach is to have some pattern +which we are trying to match an input against. Moreover, we may try to capture +some portion of the input and bind it to variable in the pattern. For example: +suppose we have a pattern (borrowing Rust macro syntax) such as `a $b:ident a` +-- that is, an `a` token followed by an `ident` token followed by another `a` +token. Given an input `a foo a`, the _metavariable_ `$b` would bind to the +`ident` `foo`. On the other hand, an input `a foo b` would be rejected as a +parse failure because the pattern `a a` cannot match `a foo b` (or as +the compiler would put it, "no rules expected token `b`"). + +The macro parser does pretty much exactly that with one exception: in order to +parse different types of metavariables, such as `ident`, `block`, `expr`, etc., +the macro parser must sometimes call back to the normal Rust parser. + +Interestingly, both definitions and invokations of macros are parsed using the +macro parser. This is extremely non-intuitive and self-referential. The code to +parse macro _definitions_ is in `src/libsyntax/ext/tt/macro_rules.rs`. It +defines the pattern for matching for a macro definition as `$( $lhs:tt => +$rhs:tt );+`. In other words, a `macro_rules` defintion should have in its body +at least one occurence of a token tree followed by `=>` followed by another +token tree. When the compiler comes to a `macro_rules` definition, it uses this +pattern to match the two token trees per rule in the definition of the macro +_using the macro parser itself_. + +When the compiler comes to a macro invokation, it needs to parse that +invokation. This is also known as _macro expansion_. The same NFA-based macro +parser is used that is described above. Notably, the "pattern" (or _matcher_) +used is the first token tree extracted from the rules of the macro _definition_. +In other words, given some pattern described by the _definition_ of the macro, +we want to match the contents of the _invokation_ of the macro. + +The algorithm is exactly the same, but when the macro parser comes to a place in +the current matcher where it needs to match a _non-terminal_ (i.e. a +metavariable), it calls back to the normal Rust parser to get the contents of +that non-terminal. Then, the macro parser proceeds in parsing as normal. + +For more information about the macro parser's implementation, see the comments +in `src/libsyntax/ext/tt/macro_parser.rs`. + +### Hygiene + +TODO + +### Procedural Macros + +TODO + +### Custom Derive + +TODO From ba3dd183e615682ab515c57de91cf3d32e891fe1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 25 Jan 2018 17:58:04 -0600 Subject: [PATCH 0028/1812] Oops rename --- src/macro-expansion.md | 62 +++++++++++++++++++++++++-- src/src/chap-060-macro-expansion.md | 66 ----------------------------- 2 files changed, 58 insertions(+), 70 deletions(-) delete mode 100644 src/src/chap-060-macro-expansion.md diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 7ab1c35bc..77f764d6a 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -4,9 +4,63 @@ Macro expansion happens during parsing. `rustc` has two parsers, in fact: the normal Rust parser, and the macro parser. During the parsing phase, the normal Rust parser will call into the macro parser when it encounters a macro. The macro parser, in turn, may call back out to the Rust parser when it needs to -bind a metavariable (e.g. `$expr`). There are a few aspects of this system to be -explained. The code for macro expansion is in `src/libsyntax/ext/tt/`. +bind a metavariable (e.g. `$my_expr`). There are a few aspects of this system to +be explained. The code for macro expansion is in `src/libsyntax/ext/tt/`. -TODO: explain parsing of macro definitions +### The macro parser -TODO: explain parsing of macro invokations + macro expansion +Basically, the macro parser is like an NFA-based regex parser. It uses an +algorithm similar in spirit to the [Earley parsing +algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is +defined in `src/libsyntax/ext/tt/macro_parser.rs`. + +In a traditional NFA-based parser, one common approach is to have some pattern +which we are trying to match an input against. Moreover, we may try to capture +some portion of the input and bind it to variable in the pattern. For example: +suppose we have a pattern (borrowing Rust macro syntax) such as `a $b:ident a` +-- that is, an `a` token followed by an `ident` token followed by another `a` +token. Given an input `a foo a`, the _metavariable_ `$b` would bind to the +`ident` `foo`. On the other hand, an input `a foo b` would be rejected as a +parse failure because the pattern `a a` cannot match `a foo b` (or as +the compiler would put it, "no rules expected token `b`"). + +The macro parser does pretty much exactly that with one exception: in order to +parse different types of metavariables, such as `ident`, `block`, `expr`, etc., +the macro parser must sometimes call back to the normal Rust parser. + +Interestingly, both definitions and invokations of macros are parsed using the +macro parser. This is extremely non-intuitive and self-referential. The code to +parse macro _definitions_ is in `src/libsyntax/ext/tt/macro_rules.rs`. It +defines the pattern for matching for a macro definition as `$( $lhs:tt => +$rhs:tt );+`. In other words, a `macro_rules` defintion should have in its body +at least one occurence of a token tree followed by `=>` followed by another +token tree. When the compiler comes to a `macro_rules` definition, it uses this +pattern to match the two token trees per rule in the definition of the macro +_using the macro parser itself_. + +When the compiler comes to a macro invokation, it needs to parse that +invokation. This is also known as _macro expansion_. The same NFA-based macro +parser is used that is described above. Notably, the "pattern" (or _matcher_) +used is the first token tree extracted from the rules of the macro _definition_. +In other words, given some pattern described by the _definition_ of the macro, +we want to match the contents of the _invokation_ of the macro. + +The algorithm is exactly the same, but when the macro parser comes to a place in +the current matcher where it needs to match a _non-terminal_ (i.e. a +metavariable), it calls back to the normal Rust parser to get the contents of +that non-terminal. Then, the macro parser proceeds in parsing as normal. + +For more information about the macro parser's implementation, see the comments +in `src/libsyntax/ext/tt/macro_parser.rs`. + +### Hygiene + +TODO + +### Procedural Macros + +TODO + +### Custom Derive + +TODO diff --git a/src/src/chap-060-macro-expansion.md b/src/src/chap-060-macro-expansion.md deleted file mode 100644 index 77f764d6a..000000000 --- a/src/src/chap-060-macro-expansion.md +++ /dev/null @@ -1,66 +0,0 @@ -# Macro expansion - -Macro expansion happens during parsing. `rustc` has two parsers, in fact: the -normal Rust parser, and the macro parser. During the parsing phase, the normal -Rust parser will call into the macro parser when it encounters a macro. The -macro parser, in turn, may call back out to the Rust parser when it needs to -bind a metavariable (e.g. `$my_expr`). There are a few aspects of this system to -be explained. The code for macro expansion is in `src/libsyntax/ext/tt/`. - -### The macro parser - -Basically, the macro parser is like an NFA-based regex parser. It uses an -algorithm similar in spirit to the [Earley parsing -algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is -defined in `src/libsyntax/ext/tt/macro_parser.rs`. - -In a traditional NFA-based parser, one common approach is to have some pattern -which we are trying to match an input against. Moreover, we may try to capture -some portion of the input and bind it to variable in the pattern. For example: -suppose we have a pattern (borrowing Rust macro syntax) such as `a $b:ident a` --- that is, an `a` token followed by an `ident` token followed by another `a` -token. Given an input `a foo a`, the _metavariable_ `$b` would bind to the -`ident` `foo`. On the other hand, an input `a foo b` would be rejected as a -parse failure because the pattern `a a` cannot match `a foo b` (or as -the compiler would put it, "no rules expected token `b`"). - -The macro parser does pretty much exactly that with one exception: in order to -parse different types of metavariables, such as `ident`, `block`, `expr`, etc., -the macro parser must sometimes call back to the normal Rust parser. - -Interestingly, both definitions and invokations of macros are parsed using the -macro parser. This is extremely non-intuitive and self-referential. The code to -parse macro _definitions_ is in `src/libsyntax/ext/tt/macro_rules.rs`. It -defines the pattern for matching for a macro definition as `$( $lhs:tt => -$rhs:tt );+`. In other words, a `macro_rules` defintion should have in its body -at least one occurence of a token tree followed by `=>` followed by another -token tree. When the compiler comes to a `macro_rules` definition, it uses this -pattern to match the two token trees per rule in the definition of the macro -_using the macro parser itself_. - -When the compiler comes to a macro invokation, it needs to parse that -invokation. This is also known as _macro expansion_. The same NFA-based macro -parser is used that is described above. Notably, the "pattern" (or _matcher_) -used is the first token tree extracted from the rules of the macro _definition_. -In other words, given some pattern described by the _definition_ of the macro, -we want to match the contents of the _invokation_ of the macro. - -The algorithm is exactly the same, but when the macro parser comes to a place in -the current matcher where it needs to match a _non-terminal_ (i.e. a -metavariable), it calls back to the normal Rust parser to get the contents of -that non-terminal. Then, the macro parser proceeds in parsing as normal. - -For more information about the macro parser's implementation, see the comments -in `src/libsyntax/ext/tt/macro_parser.rs`. - -### Hygiene - -TODO - -### Procedural Macros - -TODO - -### Custom Derive - -TODO From 458685bbb802c2df00a8422f756c64059885f875 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 26 Jan 2018 09:11:52 -0500 Subject: [PATCH 0029/1812] rename the hir chapter to The HIR --- src/SUMMARY.md | 2 +- src/{hir-lowering.md => hir.md} | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) rename src/{hir-lowering.md => hir.md} (98%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f8b1f1d6e..2e3b34386 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -8,7 +8,7 @@ - [The parser](./the-parser.md) - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) -- [HIR lowering](./hir-lowering.md) +- [The HIR (High-level IR)](./hir.md) - [The `ty` module: representing types](./ty.md) - [Type inference](./type-inference.md) - [Trait resolution](./trait-resolution.md) diff --git a/src/hir-lowering.md b/src/hir.md similarity index 98% rename from src/hir-lowering.md rename to src/hir.md index e28bb4cd4..5d5e273c4 100644 --- a/src/hir-lowering.md +++ b/src/hir.md @@ -1,4 +1,4 @@ -# HIR lowering +# The HIR The HIR -- "High-level IR" -- is the primary IR used in most of rustc. It is a desugared version of the "abstract syntax tree" (AST) @@ -116,4 +116,4 @@ associated with an **owner**, which is typically some kind of item (e.g., a `fn()` or `const`), but could also be a closure expression (e.g., `|x, y| x + y`). You can use the HIR map to find the body associated with a given def-id (`maybe_body_owned_by()`) or to find -the owner of a body (`body_owner_def_id()`). \ No newline at end of file +the owner of a body (`body_owner_def_id()`). From 40daff36d4d8ac58b1ff7842abff7ece1477be8e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 26 Jan 2018 09:20:01 -0500 Subject: [PATCH 0030/1812] move over the query chapter from src/librustc/ty/maps --- src/SUMMARY.md | 2 + src/query.md | 314 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 316 insertions(+) create mode 100644 src/query.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 2e3b34386..e4bc24283 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -5,6 +5,8 @@ - [Using the compiler testing framework](./running-tests.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [High-level overview of the compiler source](./high-level-overview.md) +- [Queries: demand-driven compilation](./query.md) + - [Incremental compilation](./incremental-compilation.md) - [The parser](./the-parser.md) - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) diff --git a/src/query.md b/src/query.md new file mode 100644 index 000000000..65d651307 --- /dev/null +++ b/src/query.md @@ -0,0 +1,314 @@ +# Queries: demand-driven compilation + +As described in [the high-level overview of the compiler][hl], the +Rust compiler is current transitioning from a traditional "pass-based" +setup to a "demand-driven" system. **The Compiler Query System is the +key to our new demand-driven organization.** The idea is pretty +simple. You have various queries that compute things about the input +-- for example, there is a query called `type_of(def_id)` that, given +the def-id of some item, will compute the type of that item and return +it to you. + +[hl]: high-level-overview.html + +Query execution is **memoized** -- so the first time you invoke a +query, it will go do the computation, but the next time, the result is +returned from a hashtable. Moreover, query execution fits nicely into +**incremental computation**; the idea is roughly that, when you do a +query, the result **may** be returned to you by loading stored data +from disk (but that's a separate topic we won't discuss further here). + +The overall vision is that, eventually, the entire compiler +control-flow will be query driven. There will effectively be one +top-level query ("compile") that will run compilation on a crate; this +will in turn demand information about that crate, starting from the +*end*. For example: + +- This "compile" query might demand to get a list of codegen-units + (i.e., modules that need to be compiled by LLVM). +- But computing the list of codegen-units would invoke some subquery + that returns the list of all modules defined in the Rust source. +- That query in turn would invoke something asking for the HIR. +- This keeps going further and further back until we wind up doing the + actual parsing. + +However, that vision is not fully realized. Still, big chunks of the +compiler (for example, generating MIR) work exactly like this. + +### Invoking queries + +To invoke a query is simple. The tcx ("type context") offers a method +for each defined query. So, for example, to invoke the `type_of` +query, you would just do this: + +```rust +let ty = tcx.type_of(some_def_id); +``` + +### Cycles between queries + +Currently, cycles during query execution should always result in a +compilation error. Typically, they arise because of illegal programs +that contain cyclic references they shouldn't (though sometimes they +arise because of compiler bugs, in which case we need to factor our +queries in a more fine-grained fashion to avoid them). + +However, it is nonetheless often useful to *recover* from a cycle +(after reporting an error, say) and try to soldier on, so as to give a +better user experience. In order to recover from a cycle, you don't +get to use the nice method-call-style syntax. Instead, you invoke +using the `try_get` method, which looks roughly like this: + +```rust +use ty::maps::queries; +... +match queries::type_of::try_get(tcx, DUMMY_SP, self.did) { + Ok(result) => { + // no cycle occurred! You can use `result` + } + Err(err) => { + // A cycle occurred! The error value `err` is a `DiagnosticBuilder`, + // meaning essentially an "in-progress", not-yet-reported error message. + // See below for more details on what to do here. + } +} +``` + +So, if you get back an `Err` from `try_get`, then a cycle *did* occur. This means that +you must ensure that a compiler error message is reported. You can do that in two ways: + +The simplest is to invoke `err.emit()`. This will emit the cycle error to the user. + +However, often cycles happen because of an illegal program, and you +know at that point that an error either already has been reported or +will be reported due to this cycle by some other bit of code. In that +case, you can invoke `err.cancel()` to not emit any error. It is +traditional to then invoke: + +``` +tcx.sess.delay_span_bug(some_span, "some message") +``` + +`delay_span_bug()` is a helper that says: we expect a compilation +error to have happened or to happen in the future; so, if compilation +ultimately succeeds, make an ICE with the message `"some +message"`. This is basically just a precaution in case you are wrong. + +### How the compiler executes a query + +So you may be wondering what happens when you invoke a query +method. The answer is that, for each query, the compiler maintains a +cache -- if your query has already been executed, then, the answer is +simple: we clone the return value out of the cache and return it +(therefore, you should try to ensure that the return types of queries +are cheaply cloneable; insert a `Rc` if necessary). + +#### Providers + +If, however, the query is *not* in the cache, then the compiler will +try to find a suitable **provider**. A provider is a function that has +been defined and linked into the compiler somewhere that contains the +code to compute the result of the query. + +**Providers are defined per-crate.** The compiler maintains, +internally, a table of providers for every crate, at least +conceptually. Right now, there are really two sets: the providers for +queries about the **local crate** (that is, the one being compiled) +and providers for queries about **external crates** (that is, +dependencies of the local crate). Note that what determines the crate +that a query is targeting is not the *kind* of query, but the *key*. +For example, when you invoke `tcx.type_of(def_id)`, that could be a +local query or an external query, depending on what crate the `def_id` +is referring to (see the `self::keys::Key` trait for more information +on how that works). + +Providers always have the same signature: + +```rust +fn provider<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx, 'tcx>, + key: QUERY_KEY) + -> QUERY_RESULT +{ + ... +} +``` + +Providers take two arguments: the `tcx` and the query key. Note also +that they take the *global* tcx (i.e., they use the `'tcx` lifetime +twice), rather than taking a tcx with some active inference context. +They return the result of the query. + +#### How providers are setup + +When the tcx is created, it is given the providers by its creator using +the `Providers` struct. This struct is generate by the macros here, but it +is basically a big list of function pointers: + +```rust +struct Providers { + type_of: for<'cx, 'tcx> fn(TyCtxt<'cx, 'tcx, 'tcx>, DefId) -> Ty<'tcx>, + ... +} +``` + +At present, we have one copy of the struct for local crates, and one +for external crates, though the plan is that we may eventually have +one per crate. + +These `Provider` structs are ultimately created and populated by +`librustc_driver`, but it does this by distributing the work +throughout the other `rustc_*` crates. This is done by invoking +various `provide` functions. These functions tend to look something +like this: + +```rust +pub fn provide(providers: &mut Providers) { + *providers = Providers { + type_of, + ..*providers + }; +} +``` + +That is, they take an `&mut Providers` and mutate it in place. Usually +we use the formulation above just because it looks nice, but you could +as well do `providers.type_of = type_of`, which would be equivalent. +(Here, `type_of` would be a top-level function, defined as we saw +before.) So, if we want to add a provider for some other query, +let's call it `fubar`, into the crate above, we might modify the `provide()` +function like so: + +```rust +pub fn provide(providers: &mut Providers) { + *providers = Providers { + type_of, + fubar, + ..*providers + }; +} + +fn fubar<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx>, key: DefId) -> Fubar<'tcx> { .. } +``` + +NB. Most of the `rustc_*` crates only provide **local +providers**. Almost all **extern providers** wind up going through the +[`rustc_metadata` crate][rustc_metadata], which loads the information from the crate +metadata. But in some cases there are crates that provide queries for +*both* local and external crates, in which case they define both a +`provide` and a `provide_extern` function that `rustc_driver` can +invoke. + +[rustc_metadata]: https://github.com/rust-lang/rust/tree/master/src/librustc_metadata + +### Adding a new kind of query + +So suppose you want to add a new kind of query, how do you do so? +Well, defining a query takes place in two steps: + +1. first, you have to specify the query name and arguments; and then, +2. you have to supply query providers where needed. + +To specify the query name and arguments, you simply add an entry to +the big macro invocation in +[`src/librustc/ty/maps/mod.rs`][maps-mod]. This will probably have +changed by the time you read this README, but at present it looks +something like: + +[maps-mod]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/maps/mod.rs + +``` +define_maps! { <'tcx> + /// Records the type of every item. + [] fn type_of: TypeOfItem(DefId) -> Ty<'tcx>, + + ... +} +``` + +Each line of the macro defines one query. The name is broken up like this: + +``` +[] fn type_of: TypeOfItem(DefId) -> Ty<'tcx>, +^^ ^^^^^^^ ^^^^^^^^^^ ^^^^^ ^^^^^^^^ +| | | | | +| | | | result type of query +| | | query key type +| | dep-node constructor +| name of query +query flags +``` + +Let's go over them one by one: + +- **Query flags:** these are largely unused right now, but the intention + is that we'll be able to customize various aspects of how the query is + processed. +- **Name of query:** the name of the query method + (`tcx.type_of(..)`). Also used as the name of a struct + (`ty::maps::queries::type_of`) that will be generated to represent + this query. +- **Dep-node constructor:** indicates the constructor function that + connects this query to incremental compilation. Typically, this is a + `DepNode` variant, which can be added by modifying the + `define_dep_nodes!` macro invocation in + [`librustc/dep_graph/dep_node.rs`][dep-node]. + - However, sometimes we use a custom function, in which case the + name will be in snake case and the function will be defined at the + bottom of the file. This is typically used when the query key is + not a def-id, or just not the type that the dep-node expects. +- **Query key type:** the type of the argument to this query. + This type must implement the `ty::maps::keys::Key` trait, which + defines (for example) how to map it to a crate, and so forth. +- **Result type of query:** the type produced by this query. This type + should (a) not use `RefCell` or other interior mutability and (b) be + cheaply cloneable. Interning or using `Rc` or `Arc` is recommended for + non-trivial data types. + - The one exception to those rules is the `ty::steal::Steal` type, + which is used to cheaply modify MIR in place. See the definition + of `Steal` for more details. New uses of `Steal` should **not** be + added without alerting `@rust-lang/compiler`. + +[dep-node]: https://github.com/rust-lang/rust/blob/master/src/librustc/dep_graph/dep_node.rs + +So, to add a query: + +- Add an entry to `define_maps!` using the format above. +- Possibly add a corresponding entry to the dep-node macro. +- Link the provider by modifying the appropriate `provide` method; + or add a new one if needed and ensure that `rustc_driver` is invoking it. + +#### Query structs and descriptions + +For each kind, the `define_maps` macro will generate a "query struct" +named after the query. This struct is a kind of a place-holder +describing the query. Each such struct implements the +`self::config::QueryConfig` trait, which has associated types for the +key/value of that particular query. Basically the code generated looks something +like this: + +```rust +// Dummy struct representing a particular kind of query: +pub struct type_of<'tcx> { phantom: PhantomData<&'tcx ()> } + +impl<'tcx> QueryConfig for type_of<'tcx> { + type Key = DefId; + type Value = Ty<'tcx>; +} +``` + +There is an additional trait that you may wish to implement called +`self::config::QueryDescription`. This trait is used during cycle +errors to give a "human readable" name for the query, so that we can +summarize what was happening when the cycle occurred. Implementing +this trait is optional if the query key is `DefId`, but if you *don't* +implement it, you get a pretty generic error ("processing `foo`..."). +You can put new impls into the `config` module. They look something like this: + +```rust +impl<'tcx> QueryDescription for queries::type_of<'tcx> { + fn describe(tcx: TyCtxt, key: DefId) -> String { + format!("computing the type of `{}`", tcx.item_path_str(key)) + } +} +``` + From 858dfdf054c898b3966c6360a3db05428e01f304 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 26 Jan 2018 14:41:56 -0600 Subject: [PATCH 0031/1812] Updated macros to address Niko's comments --- src/macro-expansion.md | 172 +++++++++++++++++++++++++++++++---------- 1 file changed, 130 insertions(+), 42 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 77f764d6a..dd735ed23 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -2,56 +2,136 @@ Macro expansion happens during parsing. `rustc` has two parsers, in fact: the normal Rust parser, and the macro parser. During the parsing phase, the normal -Rust parser will call into the macro parser when it encounters a macro. The -macro parser, in turn, may call back out to the Rust parser when it needs to -bind a metavariable (e.g. `$my_expr`). There are a few aspects of this system to -be explained. The code for macro expansion is in `src/libsyntax/ext/tt/`. +Rust parser will call into the macro parser when it encounters a macro +definition or macro invocation (TODO: verify). The macro parser, in turn, may +call back out to the Rust parser when it needs to bind a metavariable (e.g. +`$my_expr`) while parsing the contents of a macro invocation. The code for macro +expansion is in [`src/libsyntax/ext/tt/`][code_dir]. This chapter aims to +explain how macro expansion works. + +### Example + +It's helpful to have an example to refer to. For the remainder of this chapter, +whenever we refer to the "example _definition_", we mean the following: + +```rust +macro_rules! printer { + (print $mvar:ident) => { + println!("{}", $mvar); + } + (print twice $mvar:ident) => { + println!("{}", $mvar); + println!("{}", $mvar); + } +} +``` + +`$mvar` is called a _metavariable_. Unlike normal variables, rather than binding +to a value in a computation, a metavariable binds _at compile time_ to a tree of +_tokens_. A _token_ zero or more symbols that together have some meaning. For +example, in our example definition, `print`, `$mvar`, `=>`, `{` are all tokens +(though that's not an exhaustive list). There are also other special tokens, +such as `EOF`, which indicates that there are no more tokens. The process of +producing a stream of tokens from the raw bytes of the source file is called +_lexing_. For more information about _lexing_, see the [Parsing +chapter][parsing] of this book. + +Whenever we refer to the "example _invocation_", we mean the following snippet: + +```rust +printer!(print foo); // Assume `foo` is a variable defined somewhere else... +``` + +The process of expanding the macro invocation into the syntax tree +`println!("{}", foo)` and then expanding that into a call to `Display::fmt` is +called _macro expansion_, it is the topic of this chapter. ### The macro parser +There are two parts to macro expansion: parsing the definition and parsing the +invocations. Interestingly, both are done by the macro parser. + Basically, the macro parser is like an NFA-based regex parser. It uses an algorithm similar in spirit to the [Earley parsing algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is -defined in `src/libsyntax/ext/tt/macro_parser.rs`. - -In a traditional NFA-based parser, one common approach is to have some pattern -which we are trying to match an input against. Moreover, we may try to capture -some portion of the input and bind it to variable in the pattern. For example: -suppose we have a pattern (borrowing Rust macro syntax) such as `a $b:ident a` --- that is, an `a` token followed by an `ident` token followed by another `a` -token. Given an input `a foo a`, the _metavariable_ `$b` would bind to the -`ident` `foo`. On the other hand, an input `a foo b` would be rejected as a -parse failure because the pattern `a a` cannot match `a foo b` (or as -the compiler would put it, "no rules expected token `b`"). - -The macro parser does pretty much exactly that with one exception: in order to -parse different types of metavariables, such as `ident`, `block`, `expr`, etc., -the macro parser must sometimes call back to the normal Rust parser. - -Interestingly, both definitions and invokations of macros are parsed using the -macro parser. This is extremely non-intuitive and self-referential. The code to -parse macro _definitions_ is in `src/libsyntax/ext/tt/macro_rules.rs`. It -defines the pattern for matching for a macro definition as `$( $lhs:tt => -$rhs:tt );+`. In other words, a `macro_rules` defintion should have in its body -at least one occurence of a token tree followed by `=>` followed by another -token tree. When the compiler comes to a `macro_rules` definition, it uses this -pattern to match the two token trees per rule in the definition of the macro -_using the macro parser itself_. - -When the compiler comes to a macro invokation, it needs to parse that -invokation. This is also known as _macro expansion_. The same NFA-based macro -parser is used that is described above. Notably, the "pattern" (or _matcher_) -used is the first token tree extracted from the rules of the macro _definition_. -In other words, given some pattern described by the _definition_ of the macro, -we want to match the contents of the _invokation_ of the macro. - -The algorithm is exactly the same, but when the macro parser comes to a place in -the current matcher where it needs to match a _non-terminal_ (i.e. a -metavariable), it calls back to the normal Rust parser to get the contents of -that non-terminal. Then, the macro parser proceeds in parsing as normal. +defined in [`src/libsyntax/ext/tt/macro_parser.rs`][code_mp]. + +The interface of the macro parser is as follows (this is slightly simplified): + +```rust +fn parse( + sess: ParserSession, + tts: TokenStream, + ms: &[TokenTree] +) -> NamedParseResult +``` + +In this interface: + +- `sess` is a "parsing session", which keeps track of some metadata. Most + notably, this is used to keep track of errors that are generated so they can + be reported to the user. +- `tts` is a stream of tokens. The macro parser's job is to consume the raw + stream of tokens and output a binding of metavariables to corresponding token + trees. +- `ms` a _matcher_. This is a sequence of token trees that we want to match + `tts` against. + +In the analogy of a regex parser, `tts` is the input and we are matching it +against the pattern `ms`. Using our examples, `tts` could be the stream of +tokens containing the inside of the example invocation `print foo`, while `ms` +might be the sequence of token (trees) `print $mvar:ident`. + +The output of the parser is a `NamedParserResult`, which indicates which of +three cases has occured: + +- Success: `tts` matches the given matcher `ms`, and we have produced a binding + from metavariables to the corresponding token trees. +- Failure: `tts` does not match `ms`. This results in an error message such as + "No rule expected token _blah_". +- Error: some fatal error has occured _in the parser_. For example, this happens + if there are more than one pattern match, since that indicates the macro is + ambiguous. + +The full interface is defined [here][code_parse_int]. + +The macro parser does pretty much exactly the same as a normal regex parser with +one exception: in order to parse different types of metavariables, such as +`ident`, `block`, `expr`, etc., the macro parser must sometimes call back to the +normal Rust parser. + +As mentioned above, both definitions and invocations of macros are parsed using +the macro parser. This is extremely non-intuitive and self-referential. The code +to parse macro _definitions_ is in +[`src/libsyntax/ext/tt/macro_rules.rs`][code_mr]. It defines the pattern for +matching for a macro definition as `$( $lhs:tt => $rhs:tt );+`. In other words, +a `macro_rules` defintion should have in its body at least one occurence of a +token tree followed by `=>` followed by another token tree. When the compiler +comes to a `macro_rules` definition, it uses this pattern to match the two token +trees per rule in the definition of the macro _using the macro parser itself_. +In our example definition, the metavariable `$lhs` would match the patterns of +both arms: `(print $mvar:ident)` and `(print twice $mvar:ident)`. And `$rhs` +would match the bodies of both arms: `{ println!("{}", $mvar); }` and `{ +println!("{}", $mvar); println!("{}", $mvar); }`. The parser would keep this +knowledge around for when it needs to expand a macro invocation. + +When the compiler comes to a macro invocation, it parses that invocation using +the same NFA-based macro parser that is described above. However, the matcher +used is the first token tree (`$lhs`) extracted from the arms of the macro +_definition_. Using our example, we would try to match the token stream `print +foo` from the invocation against the matchers `print $mvar:ident` and `print +twice $mvar:ident` that we previously extracted from the definition. The +algorithm is exactly the same, but when the macro parser comes to a place in the +current matcher where it needs to match a _non-terminal_ (e.g. `$mvar:ident`), +it calls back to the normal Rust parser to get the contents of that +non-terminal. In this case, the Rust parser would look for an `ident` token, +which it finds (`foo`) and returns to the macro parser. Then, the macro parser +proceeds in parsing as normal. Also, note that exactly one of the matchers from +the various arms should match the invocation (otherwise, the macro is +ambiguous). For more information about the macro parser's implementation, see the comments -in `src/libsyntax/ext/tt/macro_parser.rs`. +in [`src/libsyntax/ext/tt/macro_parser.rs`][code_mp]. ### Hygiene @@ -64,3 +144,11 @@ TODO ### Custom Derive TODO + + + +[code_dir]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt +[code_mp]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt/macro_parser.rs +[code_mp]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt/macro_rules.rs +[code_parse_int]: https://github.com/rust-lang/rust/blob/a97cd17f5d71fb4ec362f4fbd79373a6e7ed7b82/src/libsyntax/ext/tt/macro_parser.rs#L421 +[parsing]: ./the-parser.md From 65263b6752355e52e616e90ac2d7d8f31e327a93 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 29 Jan 2018 09:59:47 -0500 Subject: [PATCH 0032/1812] breakup the MIR section and add an incremental compilation section --- src/SUMMARY.md | 9 ++- src/incremental-compilation.md | 139 +++++++++++++++++++++++++++++++++ src/mir.md | 1 + 3 files changed, 145 insertions(+), 4 deletions(-) create mode 100644 src/incremental-compilation.md create mode 100644 src/mir.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index e4bc24283..8e18969a1 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -6,7 +6,7 @@ - [Walkthrough: a typical contribution](./walkthrough.md) - [High-level overview of the compiler source](./high-level-overview.md) - [Queries: demand-driven compilation](./query.md) - - [Incremental compilation](./incremental-compilation.md) + - [Incremental compilation](./incremental-compilation.md) - [The parser](./the-parser.md) - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) @@ -15,8 +15,9 @@ - [Type inference](./type-inference.md) - [Trait resolution](./trait-resolution.md) - [Type checking](./type-checking.md) -- [MIR construction](./mir-construction.md) -- [MIR borrowck](./mir-borrowck.md) -- [MIR optimizations](./mir-optimizations.md) +- [The MIR (Mid-level IR)](./mir.md) + - [MIR construction](./mir-construction.md) + - [MIR borrowck](./mir-borrowck.md) + - [MIR optimizations](./mir-optimizations.md) - [trans: generating LLVM IR](./trans.md) - [Glossary](./glossary.md) diff --git a/src/incremental-compilation.md b/src/incremental-compilation.md new file mode 100644 index 000000000..23910c5b3 --- /dev/null +++ b/src/incremental-compilation.md @@ -0,0 +1,139 @@ +# Incremental compilation + +The incremental compilation scheme is, in essence, a surprisingly +simple extension to the overall query system. We'll start by describing +a slightly simplified variant of the real thing, the "basic algorithm", and then describe +some possible improvements. + +## The basic algorithm + +The basic algorithm is +called the **red-green** algorithm[^salsa]. The high-level idea is +that, after each run of the compiler, we will save the results of all +the queries that we do, as well as the **query DAG**. The +**query DAG** is a [DAG] that indices which queries executed which +other queries. So for example there would be an edge from a query Q1 +to another query Q2 if computing Q1 required computing Q2 (note that +because queries cannot depend on themselves, this results in a DAG and +not a general graph). + +[DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph + +On the next run of the compiler, then, we can sometimes reuse these +query results to avoid re-executing a query. We do this by assigning +every query a **color**: + +- If a query is colored **red**, that means that its result during + this compilation has **changed** from the previous compilation. +- If a query is colored **green**, that means that its result is + the **same** as the previous compilation. + +There are two key insights here: + +- First, if all the inputs to query Q are colored green, then the + query Q **must** result in the same value as last time and hence + need not be re-executed (or else the compiler is not deterministic). +- Second, even if some inputs to a query changes, it may be that it + **still** produces the same result as the previous compilation. In + particular, the query may only use part of its input. + - Therefore, after executing a query, we always check whether it + produced the same result as the previous time. **If it did,** we + can still mark the query as green, and hence avoid re-executing + dependent queries. + +### The try-mark-green algorithm + +The core of the incremental compilation is an algorithm called +"try-mark-green". It has the job of determining the color of a given +query Q (which must not yet have been executed). In cases where Q has +red inputs, determining Q's color may involve re-executing Q so that +we can compare its output; but if all of Q's inputs are green, then we +can determine that Q must be green without re-executing it or inspect +its value what-so-ever. In the compiler, this allows us to avoid +deserializing the result from disk when we don't need it, and -- in +fact -- enables us to sometimes skip *serializing* the result as well +(see the refinements section below). + +Try-mark-green works as follows: + +- First check if there is the query Q was executed during the previous + compilation. + - If not, we can just re-execute the query as normal, and assign it the + color of red. +- If yes, then load the 'dependent queries' that Q +- If there is a saved result, then we load the `reads(Q)` vector from the + query DAG. The "reads" is the set of queries that Q executed during + its execution. + - For each query R that in `reads(Q)`, we recursively demand the color + of R using try-mark-green. + - Note: it is important that we visit each node in `reads(Q)` in same order + as they occurred in the original compilation. See [the section on the query DAG below](#dag). + - If **any** of the nodes in `reads(Q)` wind up colored **red**, then Q is dirty. + - We re-execute Q and compare the hash of its result to the hash of the result + from the previous compilation. + - If the hash has not changed, we can mark Q as **green** and return. + - Otherwise, **all** of the nodes in `reads(Q)` must be **green**. In that case, + we can color Q as **green** and return. + + + +### The query DAG + +The query DAG code is stored in +[`src/librustc/dep_graph`][dep_graph]. Construction of the DAG is done +by instrumenting the query execution. + +One key point is that the query DAG also tracks ordering; that is, for +each query Q, we noy only track the queries that Q reads, we track the +**order** in which they were read. This allows try-mark-green to walk +those queries back in the same order. This is important because once a subquery comes back as red, +we can no longer be sure that Q will continue along the same path as before. +That is, imagine a query like this: + +```rust,ignore +fn main_query(tcx) { + if tcx.subquery1() { + tcx.subquery2() + } else { + tcx.subquery3() + } +} +``` + +Now imagine that in the first compilation, `main_query` starts by +executing `subquery1`, and this returns true. In that case, the next +query `main_query` executes will be `subquery2`, and `subquery3` will +not be executed at all. + +But now imagine that in the **next** compilation, the input has +changed such that `subquery` returns **false**. In this case, `subquery2` would never +execute. If try-mark-green were to visit `reads(main_query)` out of order, +however, it might have visited `subquery2` before `subquery1`, and hence executed it. +This can lead to ICEs and other problems in the compiler. + +[dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc/dep_graph + +## Improvements to the basic algorithm + +In the description basic algorithm, we said that at the end of +compilation we would save the results of all the queries that were +performed. In practice, this can be quite wasteful -- many of those +results are very cheap to recompute, and serializing + deserializing +them is not a particular win. In practice, what we would do is to save +**the hashes** of all the subqueries that we performed. Then, in select cases, +we **also** save the results. + +This is why the incremental algorithm separates computing the +**color** of a node, which often does not require its value, from +computing the **result** of a node. Computing the result is done via a simple algorithm +like so: + +- Check if a saved result for Q is available. If so, compute the color of Q. + If Q is green, deserialize and return the saved result. +- Otherwise, execute Q. + - We can then compare the hash of the result and color Q as green if + it did not change. + +# Footnotes + +[^salsa]: I have long wanted to rename it to the Salsa algorithm, but it never caught on. -@nikomatsakis diff --git a/src/mir.md b/src/mir.md new file mode 100644 index 000000000..2be6a2e1a --- /dev/null +++ b/src/mir.md @@ -0,0 +1 @@ +# The MIR (Mid-level IR) From 0414ffee78512cb31082e979f4a53aa38ff22de4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 29 Jan 2018 10:25:44 -0500 Subject: [PATCH 0033/1812] create links in the glossary --- src/glossary.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/src/glossary.md b/src/glossary.md index b66e17ea3..338c9e93f 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -9,23 +9,24 @@ AST | the abstract syntax tree produced by the syntax crate codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. -HIR | the High-level IR, created by lowering and desugaring the AST. See `librustc/hir`. +HIR | the High-level IR, created by lowering and desugaring the AST ([see more](hir.html)) HirId | identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". -'gcx | the lifetime of the global arena (see `librustc/ty`). +'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item ICE | internal compiler error. When the compiler crashes. infcx | the inference context (see `librustc/infer`) MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans. Defined in the `src/librustc/mir/` module, but much of the code that manipulates it is found in `src/librustc_mir`. -obligation | something that must be proven by the trait system; see `librustc/traits`. +obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) local crate | the crate currently being compiled. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. -query | perhaps some sub-computation during compilation; see `librustc/maps`. -provider | the function that executes a query; see `librustc/maps`. +query | perhaps some sub-computation during compilation ([see more](query.html)) +provider | the function that executes a query ([see more](query.html)) sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g., the `i32`, `u32` in `HashMap`) -tcx | the "typing context", main data structure of the compiler (see `librustc/ty`). +tcx | the "typing context", main data structure of the compiler ([see more](ty.html)) +'tcx | the lifetime of the currently active inference context ([see more](ty.html)) trans | the code to translate MIR into LLVM IR. -trait reference | a trait and values for its type parameters (see `librustc/ty`). -ty | the internal representation of a type (see `librustc/ty`). +trait reference | a trait and values for its type parameters ([see more](ty.html)). +ty | the internal representation of a type ([see more](ty.html)). From bf775929af659d3e25dd0458b8d8465db8378b8f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 29 Jan 2018 10:26:35 -0500 Subject: [PATCH 0034/1812] link glossary to mir --- src/glossary.md | 2 +- src/mir.md | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/src/glossary.md b/src/glossary.md index 338c9e93f..3202e5f4c 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -15,7 +15,7 @@ HirId | identifies a particular node in the HIR by combining generics | the set of generic type parameters defined on a type or item ICE | internal compiler error. When the compiler crashes. infcx | the inference context (see `librustc/infer`) -MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans. Defined in the `src/librustc/mir/` module, but much of the code that manipulates it is found in `src/librustc_mir`. +MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) local crate | the crate currently being compiled. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. diff --git a/src/mir.md b/src/mir.md index 2be6a2e1a..eeba68472 100644 --- a/src/mir.md +++ b/src/mir.md @@ -1 +1,6 @@ # The MIR (Mid-level IR) + +TODO + +Defined in the `src/librustc/mir/` module, but much of the code that +manipulates it is found in `src/librustc_mir`. From dee42c16732550a81cc7aa287b2404afd8cfa8b3 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 29 Jan 2018 11:20:46 -0600 Subject: [PATCH 0035/1812] Rewrite 'tokens' para... --- src/macro-expansion.md | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index dd735ed23..da4615128 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -26,15 +26,21 @@ macro_rules! printer { } ``` -`$mvar` is called a _metavariable_. Unlike normal variables, rather than binding -to a value in a computation, a metavariable binds _at compile time_ to a tree of -_tokens_. A _token_ zero or more symbols that together have some meaning. For -example, in our example definition, `print`, `$mvar`, `=>`, `{` are all tokens -(though that's not an exhaustive list). There are also other special tokens, -such as `EOF`, which indicates that there are no more tokens. The process of -producing a stream of tokens from the raw bytes of the source file is called -_lexing_. For more information about _lexing_, see the [Parsing -chapter][parsing] of this book. +`$mvar` is called a _metavariable_. Unlike normal variables, rather than +binding to a value in a computation, a metavariable binds _at compile time_ to +a tree of _tokens_. A _token_ is a single "unit" of the grammar, such as an +identifier (e.g., `foo`) or punctuation (e.g., `=>`). There are also other +special tokens, such as `EOF`, which indicates that there are no more tokens. +Token trees resulting from paired parentheses-like characters (`(`...`)`, +`[`...`]`, and `{`...`}`) -- they include the open and close and all the tokens +in between (we do require that parentheses-like characters be balanced). Having +macro expansion operate on token streams rather than the raw bytes of a source +file abstracts away a lot of complexity. The macro expander (and much of the +rest of the compiler) doesn't really care that much about the exact line and +column of some syntactic construct in the code; it cares about what constructs +are used in the code. Using tokens allows us to care about _what_ without +worrying about _where_. For more information about tokens, see the +[Parsing][parsing] chapter of this book. Whenever we refer to the "example _invocation_", we mean the following snippet: @@ -44,7 +50,7 @@ printer!(print foo); // Assume `foo` is a variable defined somewhere else... The process of expanding the macro invocation into the syntax tree `println!("{}", foo)` and then expanding that into a call to `Display::fmt` is -called _macro expansion_, it is the topic of this chapter. +called _macro expansion_, and it is the topic of this chapter. ### The macro parser From ed50f8d5d7e4ee786578de54a49868edfbbe8c97 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 29 Jan 2018 11:37:40 -0600 Subject: [PATCH 0036/1812] I'm guessing this was a typo? --- src/high-level-overview.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index b8d75bff6..55b596a2a 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -134,8 +134,3 @@ take: (one for each "codegen unit"). 6. **Linking** - Finally, those `.o` files are linked together. - - - - -The first thing you may wonder if From 82da67a7519723b5cf3e071f6cdfca0c6114bc83 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 29 Jan 2018 11:50:34 -0600 Subject: [PATCH 0037/1812] Corrected relationship of macro and rust parsers --- src/macro-expansion.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index da4615128..a7777e80c 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -2,12 +2,13 @@ Macro expansion happens during parsing. `rustc` has two parsers, in fact: the normal Rust parser, and the macro parser. During the parsing phase, the normal -Rust parser will call into the macro parser when it encounters a macro -definition or macro invocation (TODO: verify). The macro parser, in turn, may -call back out to the Rust parser when it needs to bind a metavariable (e.g. -`$my_expr`) while parsing the contents of a macro invocation. The code for macro -expansion is in [`src/libsyntax/ext/tt/`][code_dir]. This chapter aims to -explain how macro expansion works. +Rust parser will set aside the contents of macros and their invokations. Later, +before name resolution, macros are expanded using these portions of the code. +The macro parser, in turn, may call the normal Rust parser when it needs to +bind a metavariable (e.g. `$my_expr`) while parsing the contents of a macro +invocation. The code for macro expansion is in +[`src/libsyntax/ext/tt/`][code_dir]. This chapter aims to explain how macro +expansion works. ### Example From f47633dd334d53dd09a8fe66866eb9e7ae81f06e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 29 Jan 2018 13:12:28 -0600 Subject: [PATCH 0038/1812] copy type inference readme --- src/type-inference.md | 226 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 226 insertions(+) diff --git a/src/type-inference.md b/src/type-inference.md index 0fc99252a..6e2032fee 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -1 +1,227 @@ # Type inference + +The type inference is based on standard HM-type inference, but +extended in various way to accommodate subtyping, region inference, +and higher-ranked types. + +## A note on terminology + +We use the notation `?T` to refer to inference variables, also called +existential variables. + +We use the term "region" and "lifetime" interchangeably. Both refer to +the `'a` in `&'a T`. + +The term "bound region" refers to regions bound in a function +signature, such as the `'a` in `for<'a> fn(&'a u32)`. A region is +"free" if it is not bound. + +## Creating an inference context + +You create and "enter" an inference context by doing something like +the following: + +```rust +tcx.infer_ctxt().enter(|infcx| { + // use the inference context `infcx` in here +}) +``` + +Each inference context creates a short-lived type arena to store the +fresh types and things that it will create, as described in +[the README in the ty module][ty-readme]. This arena is created by the `enter` +function and disposed after it returns. + +[ty-readme]: src/librustc/ty/README.md + +Within the closure, the infcx will have the type `InferCtxt<'cx, 'gcx, +'tcx>` for some fresh `'cx` and `'tcx` -- the latter corresponds to +the lifetime of this temporary arena, and the `'cx` is the lifetime of +the `InferCtxt` itself. (Again, see [that ty README][ty-readme] for +more details on this setup.) + +The `tcx.infer_ctxt` method actually returns a build, which means +there are some kinds of configuration you can do before the `infcx` is +created. See `InferCtxtBuilder` for more information. + +## Inference variables + +The main purpose of the inference context is to house a bunch of +**inference variables** -- these represent types or regions whose precise +value is not yet known, but will be uncovered as we perform type-checking. + +If you're familiar with the basic ideas of unification from H-M type +systems, or logic languages like Prolog, this is the same concept. If +you're not, you might want to read a tutorial on how H-M type +inference works, or perhaps this blog post on +[unification in the Chalk project]. + +[Unification in the Chalk project]: http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/ + +All told, the inference context stores four kinds of inference variables as of this +writing: + +- Type variables, which come in three varieties: + - General type variables (the most common). These can be unified with any type. + - Integral type variables, which can only be unified with an integral type, and + arise from an integer literal expression like `22`. + - Float type variables, which can only be unified with a float type, and + arise from a float literal expression like `22.0`. +- Region variables, which represent lifetimes, and arise all over the dang place. + +All the type variables work in much the same way: you can create a new +type variable, and what you get is `Ty<'tcx>` representing an +unresolved type `?T`. Then later you can apply the various operations +that the inferencer supports, such as equality or subtyping, and it +will possibly **instantiate** (or **bind**) that `?T` to a specific +value as a result. + +The region variables work somewhat differently, and are described +below in a separate section. + +## Enforcing equality / subtyping + +The most basic operations you can perform in the type inferencer is +**equality**, which forces two types `T` and `U` to be the same. The +recommended way to add an equality constraint is using the `at` +method, roughly like so: + +``` +infcx.at(...).eq(t, u); +``` + +The first `at()` call provides a bit of context, i.e., why you are +doing this unification, and in what environment, and the `eq` method +performs the actual equality constraint. + +When you equate things, you force them to be precisely equal. Equating +returns a `InferResult` -- if it returns `Err(err)`, then equating +failed, and the enclosing `TypeError` will tell you what went wrong. + +The success case is perhaps more interesting. The "primary" return +type of `eq` is `()` -- that is, when it succeeds, it doesn't return a +value of any particular interest. Rather, it is executed for its +side-effects of constraining type variables and so forth. However, the +actual return type is not `()`, but rather `InferOk<()>`. The +`InferOk` type is used to carry extra trait obligations -- your job is +to ensure that these are fulfilled (typically by enrolling them in a +fulfillment context). See the [trait README] for more background here. + +[trait README]: ../traits/README.md + +You can also enforce subtyping through `infcx.at(..).sub(..)`. The same +basic concepts apply as above. + +## "Trying" equality + +Sometimes you would like to know if it is *possible* to equate two +types without error. You can test that with `infcx.can_eq` (or +`infcx.can_sub` for subtyping). If this returns `Ok`, then equality +is possible -- but in all cases, any side-effects are reversed. + +Be aware though that the success or failure of these methods is always +**modulo regions**. That is, two types `&'a u32` and `&'b u32` will +return `Ok` for `can_eq`, even if `'a != 'b`. This falls out from the +"two-phase" nature of how we solve region constraints. + +## Snapshots + +As described in the previous section on `can_eq`, often it is useful +to be able to do a series of operations and then roll back their +side-effects. This is done for various reasons: one of them is to be +able to backtrack, trying out multiple possibilities before settling +on which path to take. Another is in order to ensure that a series of +smaller changes take place atomically or not at all. + +To allow for this, the inference context supports a `snapshot` method. +When you call it, it will start recording changes that occur from the +operations you perform. When you are done, you can either invoke +`rollback_to`, which will undo those changes, or else `confirm`, which +will make the permanent. Snapshots can be nested as long as you follow +a stack-like discipline. + +Rather than use snapshots directly, it is often helpful to use the +methods like `commit_if_ok` or `probe` that encapsulate higher-level +patterns. + +## Subtyping obligations + +One thing worth discussing are subtyping obligations. When you force +two types to be a subtype, like `?T <: i32`, we can often convert those +into equality constraints. This follows from Rust's rather limited notion +of subtyping: so, in the above case, `?T <: i32` is equivalent to `?T = i32`. + +However, in some cases we have to be more careful. For example, when +regions are involved. So if you have `?T <: &'a i32`, what we would do +is to first "generalize" `&'a i32` into a type with a region variable: +`&'?b i32`, and then unify `?T` with that (`?T = &'?b i32`). We then +relate this new variable with the original bound: + + &'?b i32 <: &'a i32 + +This will result in a region constraint (see below) of `'?b: 'a`. + +One final interesting case is relating two unbound type variables, +like `?T <: ?U`. In that case, we can't make progress, so we enqueue +an obligation `Subtype(?T, ?U)` and return it via the `InferOk` +mechanism. You'll have to try again when more details about `?T` or +`?U` are known. + +## Region constraints + +Regions are inferred somewhat differently from types. Rather than +eagerly unifying things, we simply collect constraints as we go, but +make (almost) no attempt to solve regions. These constraints have the +form of an outlives constraint: + + 'a: 'b + +Actually the code tends to view them as a subregion relation, but it's the same +idea: + + 'b <= 'a + +(There are various other kinds of constriants, such as "verifys"; see +the `region_constraints` module for details.) + +There is one case where we do some amount of eager unification. If you have an equality constraint +between two regions + + 'a = 'b + +we will record that fact in a unification table. You can then use +`opportunistic_resolve_var` to convert `'b` to `'a` (or vice +versa). This is sometimes needed to ensure termination of fixed-point +algorithms. + +## Extracting region constraints + +Ultimately, region constraints are only solved at the very end of +type-checking, once all other constraints are known. There are two +ways to solve region constraints right now: lexical and +non-lexical. Eventually there will only be one. + +To solve **lexical** region constraints, you invoke +`resolve_regions_and_report_errors`. This will "close" the region +constraint process and invoke the `lexical_region_resolve` code. Once +this is done, any further attempt to equate or create a subtyping +relationship will yield an ICE. + +Non-lexical region constraints are not handled within the inference +context. Instead, the NLL solver (actually, the MIR type-checker) +invokes `take_and_reset_region_constraints` periodically. This +extracts all of the outlives constraints from the region solver, but +leaves the set of variables intact. This is used to get *just* the +region constraints that resulted from some particular point in the +program, since the NLL solver needs to know not just *what* regions +were subregions but *where*. Finally, the NLL solver invokes +`take_region_var_origins`, which "closes" the region constraint +process in the same way as normal solving. + +## Lexical region resolution + +Lexical region resolution is done by initially assigning each region +variable to an empty value. We then process each outlives constraint +repeatedly, growing region variables until a fixed-point is reached. +Region variables can be grown using a least-upper-bound relation on +the region lattice in a fairly straight-forward fashion. From 066a32c961682259aef620ba73cc9274da98d39a Mon Sep 17 00:00:00 2001 From: Michal 'vorner' Vaner Date: Mon, 29 Jan 2018 22:18:35 +0100 Subject: [PATCH 0039/1812] The first approximation of name resolution (#22) * The first approximation of name resolution The first attempt to write something useful about the name resolution. As the TODO section says, his is not finished thing, but it might hopefully be useful to someone already. --- src/name-resolution.md | 106 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) diff --git a/src/name-resolution.md b/src/name-resolution.md index 487a31d2c..25ce3e29e 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -1 +1,107 @@ # Name resolution + +The name resolution is a separate pass in the compiler. Its input is the syntax +tree, produced by parsing input files. It produces links from all the names in +the source to relevant places where the name was introduced. It also generates +helpful error messages, like typo suggestions or traits to import. + +The name resolution lives in the `librustc_resolve` crate, with the meat in +`lib.rs` and some helpers or symbol-type specific logic in the other modules. + +## Namespaces + +Different kind of symbols live in different namespaces ‒ eg. types don't +clash with variables. This usually doesn't happen, because variables start with +lower-case letter while types with upper case one, but this is only a +convention. This is legal Rust code that'll compile (with warnings): + +```rust +type x = u32; +let x: x = 1; +let y: x = 2; // See? x is still a type here. +``` + +To cope with this, and with slightly different scoping rules for these +namespaces, the resolver keeps them separated and builds separate structures for +them. + +In other words, when the code talks about namespaces, it doesn't mean the module +hierarchy, it's types vs. values vs. macros. + +## Scopes and ribs + +A name is visible only in certain area in the source code. This forms a +hierarchical structure, but not necessarily a simple one ‒ if one scope is part +of another, it doesn't mean the name visible in the outer one is also visible in +the inner one, or that it refers to the same thing. + +To cope with that, the compiler introduces the concept of Ribs. This is +abstraction of a scope. Every time the set of visible names potentially changes, +a new rib is pushed onto a stack. The places where this can happen includes for +example: + +* The obvious places ‒ curly braces enclosing a block, function boundaries, + modules. +* Introducing a let binding ‒ this can shadow another binding with the same + name. +* Macro expansion border ‒ to cope with macro hygiene. + +When searching for a name, the stack of ribs is traversed from the innermost +outwards. This helps to find the closest meaning of the name (the one not +shadowed by anything else). The transition to outer rib may also change the +rules what names are usable ‒ if there are nested functions (not closures), the +inner one can't access parameters and local bindings of the outer one, even +though they should be visible by ordinary scoping rules. An example: + +```rust +fn do_something(val: T) { // <- New rib in both types and values (1) + // `val` is accessible, as is the helper function + // `T` is accessible + let helper = || { // New rib on `helper` (2) and another on the block (3) + // `val` is accessible here + }; // End of (3) + // `val` is accessible, `helper` variable shadows `helper` function + fn helper() { // <- New rib in both types and values (4) + // `val` is not accessible here, (4) is not transparent for locals) + // `T` is not accessible here + } // End of (4) + let val = T::default(); // New rib (5) + // `val` is the variable, not the parameter here +} // End of (5), (2) and (1) +``` + +Because the rules for different namespaces are a bit different, each namespace +has its own independent rib stack that is constructed in parallel to the others. + +## Overall strategy + +To perform the name resolution of the whole crate, the syntax tree is traversed +top-down and every encountered name is resolved. This works for most kinds of +names, because at the point of use of a name it is already introduced in the Rib +hierarchy. + +There are some exceptions to this. Items are bit tricky, because they can be +used even before encountered ‒ therefore every block needs to be first scanned +for items to fill in its Rib. + +Other, even more problematic ones, are imports which need recursive fixed-point +resolution and macros, that need to be resolved and expanded before the rest of +the code can be processed. + +Therefore, the resolution is performed in multiple stages. + +## TODO: + +This is a result of the first pass of learning the code. It is definitely +incomplete and not detailed enough. It also might be inaccurate in places. +Still, it probably provides useful first guidepost to what happens in there. + +* What exactly does it link to and how is that published and consumed by + following stages of compilation? +* Who calls it and how it is actually used. +* Is it a pass and then the result is only used, or can it be computed + incrementally (eg. for RLS)? +* The overall strategy description is a bit vague. +* Where does the name `Rib` come from? +* Does this thing have its own tests, or is it tested only as part of some e2e + testing? From 150db58b61a0d67c596af234e2e47ab635cc3a52 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 30 Jan 2018 11:38:37 -0600 Subject: [PATCH 0040/1812] Fix minor typos --- src/incremental-compilation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/incremental-compilation.md b/src/incremental-compilation.md index 23910c5b3..df88125e1 100644 --- a/src/incremental-compilation.md +++ b/src/incremental-compilation.md @@ -64,7 +64,7 @@ Try-mark-green works as follows: - If there is a saved result, then we load the `reads(Q)` vector from the query DAG. The "reads" is the set of queries that Q executed during its execution. - - For each query R that in `reads(Q)`, we recursively demand the color + - For each query R in `reads(Q)`, we recursively demand the color of R using try-mark-green. - Note: it is important that we visit each node in `reads(Q)` in same order as they occurred in the original compilation. See [the section on the query DAG below](#dag). @@ -84,7 +84,7 @@ The query DAG code is stored in by instrumenting the query execution. One key point is that the query DAG also tracks ordering; that is, for -each query Q, we noy only track the queries that Q reads, we track the +each query Q, we not only track the queries that Q reads, we track the **order** in which they were read. This allows try-mark-green to walk those queries back in the same order. This is important because once a subquery comes back as red, we can no longer be sure that Q will continue along the same path as before. From 4f983ebe1462ca0ce821647dc8476feb184c4ca4 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 30 Jan 2018 16:29:16 -0600 Subject: [PATCH 0041/1812] Add a para about bootstrapping --- src/how-to-build-and-run.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index f685f569c..24cfbfad7 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -1,7 +1,7 @@ # How to build the compiler and run what you built The compiler is built using a tool called `x.py`. You will need to -have Python installed to run it. But before we get to that, if you're going to +have Python installed to run it. But before we get to that, if you're going to be hacking on rustc, you'll want to tweak the configuration of the compiler. The default configuration is oriented towards running the compiler as a user, not a developer. @@ -48,6 +48,19 @@ use-jemalloc = false ### Running x.py and building a stage1 compiler +One thing to keep in mind is that `rustc` is a _bootstrapping_ compiler. That +is, since `rustc` is written in Rust, we need to use an older version of the +compiler to compile the newer version. In particular, the newer version of the +compiler, `libstd`, and other tooling may use some unstable features +internally. The result is the compiling `rustc` is done in stages. + +- Stage 0: the current _beta_ compiler is compiled using the current _stable_ compiler. +- Stage 1: the code in your clone is then compiled with the stage 0 compiler. +- Stage 2: the code in your clone is then compiled with the stage 1 compiler (i.e. it builds itself). + +For hacking, often building the stage 1 compiler is enough, but for testing and +release, the stage 2 compiler is used. + Once you've created a config.toml, you are now ready to run `x.py`. There are a lot of options here, but let's start with what is probably the best "go to" command for building a local rust: @@ -117,4 +130,4 @@ Here are a few other useful x.py commands. We'll cover some of them in detail in - `./x.py build` -- builds the stage2 compiler - Running tests (see the section [running tests](./running-tests.html) for more details): - `./x.py test --stage 1 src/libstd` -- runs the `#[test]` tests from libstd - - `./x.py test --stage 1 src/test/run-pass` -- runs the `run-pass` test suite + - `./x.py test --stage 1 src/test/run-pass` -- runs the `run-pass` test suite From c3eb273f8eb6a77bc808e6692017b2e20ab91391 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 01:20:07 +0000 Subject: [PATCH 0042/1812] improved grammar use en-dashes instead of `--` --- src/about-this-guide.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index ea840177b..79106736f 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -1,14 +1,14 @@ # About this guide -This guide is meant to help document how rustc -- the Rust compiler -- +This guide is meant to help document how rustc – the Rust compiler – works, as well as to help new contributors get involved in rustc -development. It is not meant to replace code documentation -- each -chapter gives only high-level details, the kinds of things that +development. It is not meant to replace code documentation – each +chapter gives only high-level details – the kinds of things that (ideally) don't change frequently. -The guide itself is of course open source as well, and the sources can -be found at [the GitHub repository]. If you find any mistakes in the -guide, please file an issue about it -- or, even better, open a PR +The guide itself is of course open-source as well, and the sources can +be found at the [GitHub repository]. If you find any mistakes in the +guide, please file an issue about it, or even better, open a PR with a correction! -[the GitHub repository]: https://github.com/rust-lang-nursery/rustc-guide/ +[GitHub repository]: https://github.com/rust-lang-nursery/rustc-guide/ From d15c82a6c5a76f4ce7458a24b05d32516848c204 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 01:32:49 +0000 Subject: [PATCH 0043/1812] improved grammar and fixed small errors --- src/incremental-compilation.md | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/src/incremental-compilation.md b/src/incremental-compilation.md index df88125e1..5cee70dbd 100644 --- a/src/incremental-compilation.md +++ b/src/incremental-compilation.md @@ -2,7 +2,7 @@ The incremental compilation scheme is, in essence, a surprisingly simple extension to the overall query system. We'll start by describing -a slightly simplified variant of the real thing, the "basic algorithm", and then describe +a slightly simplified variant of the real thing – the "basic algorithm" – and then describe some possible improvements. ## The basic algorithm @@ -11,8 +11,8 @@ The basic algorithm is called the **red-green** algorithm[^salsa]. The high-level idea is that, after each run of the compiler, we will save the results of all the queries that we do, as well as the **query DAG**. The -**query DAG** is a [DAG] that indices which queries executed which -other queries. So for example there would be an edge from a query Q1 +**query DAG** is a [DAG] that indexes which queries executed which +other queries. So, for example, there would be an edge from a query Q1 to another query Q2 if computing Q1 required computing Q2 (note that because queries cannot depend on themselves, this results in a DAG and not a general graph). @@ -43,24 +43,23 @@ There are two key insights here: ### The try-mark-green algorithm -The core of the incremental compilation is an algorithm called +At the core of incremental compilation is an algorithm called "try-mark-green". It has the job of determining the color of a given -query Q (which must not yet have been executed). In cases where Q has +query Q (which must not have yet been executed). In cases where Q has red inputs, determining Q's color may involve re-executing Q so that -we can compare its output; but if all of Q's inputs are green, then we -can determine that Q must be green without re-executing it or inspect -its value what-so-ever. In the compiler, this allows us to avoid -deserializing the result from disk when we don't need it, and -- in -fact -- enables us to sometimes skip *serializing* the result as well +we can compare its output, but if all of Q's inputs are green, then we +can conclude that Q must be green without re-executing it or inspecting +its value, regardless. In the compiler, this allows us to avoid +deserializing the result from disk when we don't need it, and in fact +enables us to sometimes skip *serializing* the result as well (see the refinements section below). Try-mark-green works as follows: -- First check if there is the query Q was executed during the previous - compilation. +- First check if the query Q was executed during the previous compilation. - If not, we can just re-execute the query as normal, and assign it the color of red. -- If yes, then load the 'dependent queries' that Q +- If yes, then load the 'dependent queries' of Q. - If there is a saved result, then we load the `reads(Q)` vector from the query DAG. The "reads" is the set of queries that Q executed during its execution. @@ -106,9 +105,9 @@ query `main_query` executes will be `subquery2`, and `subquery3` will not be executed at all. But now imagine that in the **next** compilation, the input has -changed such that `subquery` returns **false**. In this case, `subquery2` would never +changed such that `subquery1` returns **false**. In this case, `subquery2` would never execute. If try-mark-green were to visit `reads(main_query)` out of order, -however, it might have visited `subquery2` before `subquery1`, and hence executed it. +however, it visit `subquery2` before `subquery1`, and hence execute it. This can lead to ICEs and other problems in the compiler. [dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc/dep_graph @@ -117,8 +116,8 @@ This can lead to ICEs and other problems in the compiler. In the description basic algorithm, we said that at the end of compilation we would save the results of all the queries that were -performed. In practice, this can be quite wasteful -- many of those -results are very cheap to recompute, and serializing + deserializing +performed. In practice, this can be quite wasteful – many of those +results are very cheap to recompute, and serializing and deserializing them is not a particular win. In practice, what we would do is to save **the hashes** of all the subqueries that we performed. Then, in select cases, we **also** save the results. From 2ee639a7aa9b698f4cf2988e2bc13ce070df272a Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 02:08:14 +0000 Subject: [PATCH 0044/1812] fixed grammatical oversight --- src/incremental-compilation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/incremental-compilation.md b/src/incremental-compilation.md index 5cee70dbd..2ab053e17 100644 --- a/src/incremental-compilation.md +++ b/src/incremental-compilation.md @@ -107,7 +107,7 @@ not be executed at all. But now imagine that in the **next** compilation, the input has changed such that `subquery1` returns **false**. In this case, `subquery2` would never execute. If try-mark-green were to visit `reads(main_query)` out of order, -however, it visit `subquery2` before `subquery1`, and hence execute it. +however, it might visit `subquery2` before `subquery1`, and hence execute it. This can lead to ICEs and other problems in the compiler. [dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc/dep_graph From 606fe051146540222f224418731ae78eab28e840 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 02:09:24 +0000 Subject: [PATCH 0045/1812] minor clarification --- src/incremental-compilation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/incremental-compilation.md b/src/incremental-compilation.md index 2ab053e17..dc4d06c6c 100644 --- a/src/incremental-compilation.md +++ b/src/incremental-compilation.md @@ -49,7 +49,7 @@ query Q (which must not have yet been executed). In cases where Q has red inputs, determining Q's color may involve re-executing Q so that we can compare its output, but if all of Q's inputs are green, then we can conclude that Q must be green without re-executing it or inspecting -its value, regardless. In the compiler, this allows us to avoid +its value at all. In the compiler, this allows us to avoid deserializing the result from disk when we don't need it, and in fact enables us to sometimes skip *serializing* the result as well (see the refinements section below). From ed1e1f24dea07fef6f5a6138045cedaefbe8e32d Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Wed, 31 Jan 2018 02:09:59 +0000 Subject: [PATCH 0046/1812] changed hyphens to en-dashes --- src/the-parser.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/the-parser.md b/src/the-parser.md index 9a01d8a36..456f0a9ea 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -9,8 +9,8 @@ The bulk of the parser lives in the [libsyntax] crate. Like most parsers, the parsing process is composed of two main steps, -- lexical analysis - turn a stream of characters into a stream of token trees -- parsing - turn the token trees into an AST +- lexical analysis – turn a stream of characters into a stream of token trees +- parsing – turn the token trees into an AST The `syntax` crate contains several main players, @@ -39,4 +39,4 @@ all the information needed while parsing, as well as the `CodeMap` itself. [parser module]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/parse [`Parser`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/parser.rs [`StringReader`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs -[visit module]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/visit.rs \ No newline at end of file +[visit module]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/visit.rs From 239e2c600aa0ac538bcbef209942b8c543ff564c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 31 Jan 2018 12:22:42 -0600 Subject: [PATCH 0047/1812] copy MIR readme --- src/mir.md | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 102 insertions(+), 3 deletions(-) diff --git a/src/mir.md b/src/mir.md index eeba68472..dbac8eb53 100644 --- a/src/mir.md +++ b/src/mir.md @@ -1,6 +1,105 @@ # The MIR (Mid-level IR) -TODO +MIR is Rust's _Mid-level Intermediate Representation_. It is constructed from +HIR (described in an earlier chapter). -Defined in the `src/librustc/mir/` module, but much of the code that -manipulates it is found in `src/librustc_mir`. +MIR is defined in the [`src/librustc/mir/`][mir] module, but much of the code +that manipulates it is found in [`src/librustc_mir`][mirmanip]. + + +_NOTE: copy/pasted from README... needs editing_ + +# MIR definition and pass system + +This file contains the definition of the MIR datatypes along with the +various types for the "MIR Pass" system, which lets you easily +register and define new MIR transformations and analyses. + +Most of the code that operates on MIR can be found in the +`librustc_mir` crate or other crates. The code found here in +`librustc` is just the datatype definitions, along with the functions +which operate on MIR to be placed everywhere else. + +## MIR Data Types and visitor + +The main MIR data type is `rustc::mir::Mir`, defined in `mod.rs`. +There is also the MIR visitor (in `visit.rs`) which allows you to walk +the MIR and override what actions will be taken at various points (you +can visit in either shared or mutable mode; the latter allows changing +the MIR in place). Finally `traverse.rs` contains various traversal +routines for visiting the MIR CFG in [different standard orders][traversal] +(e.g. pre-order, reverse post-order, and so forth). + +[traversal]: https://en.wikipedia.org/wiki/Tree_traversal + +## MIR pass suites and their integration into the query system + +As a MIR *consumer*, you are expected to use one of the queries that +returns a "final MIR". As of the time of this writing, there is only +one: `optimized_mir(def_id)`, but more are expected to come in the +future. For foreign def-ids, we simply read the MIR from the other +crate's metadata. But for local def-ids, the query will construct the +MIR and then iteratively optimize it by putting it through various +pipeline stages. This section describes those pipeline stages and how +you can extend them. + +To produce the `optimized_mir(D)` for a given def-id `D`, the MIR +passes through several suites of optimizations, each represented by a +query. Each suite consists of multiple optimizations and +transformations. These suites represent useful intermediate points +where we want to access the MIR for type checking or other purposes: + +- `mir_build(D)` -- not a query, but this constructs the initial MIR +- `mir_const(D)` -- applies some simple transformations to make MIR ready for constant evaluation; +- `mir_validated(D)` -- applies some more transformations, making MIR ready for borrow checking; +- `optimized_mir(D)` -- the final state, after all optimizations have been performed. + +### Stealing + +The intermediate queries `mir_const()` and `mir_validated()` yield up +a `&'tcx Steal>`, allocated using +`tcx.alloc_steal_mir()`. This indicates that the result may be +**stolen** by the next suite of optimizations -- this is an +optimization to avoid cloning the MIR. Attempting to use a stolen +result will cause a panic in the compiler. Therefore, it is important +that you do not read directly from these intermediate queries except as +part of the MIR processing pipeline. + +Because of this stealing mechanism, some care must also be taken to +ensure that, before the MIR at a particular phase in the processing +pipeline is stolen, anyone who may want to read from it has already +done so. Concretely, this means that if you have some query `foo(D)` +that wants to access the result of `mir_const(D)` or +`mir_validated(D)`, you need to have the successor pass "force" +`foo(D)` using `ty::queries::foo::force(...)`. This will force a query +to execute even though you don't directly require its result. + +As an example, consider MIR const qualification. It wants to read the +result produced by the `mir_const()` suite. However, that result will +be **stolen** by the `mir_validated()` suite. If nothing was done, +then `mir_const_qualif(D)` would succeed if it came before +`mir_validated(D)`, but fail otherwise. Therefore, `mir_validated(D)` +will **force** `mir_const_qualif` before it actually steals, thus +ensuring that the reads have already happened: + +``` +mir_const(D) --read-by--> mir_const_qualif(D) + | ^ + stolen-by | + | (forces) + v | +mir_validated(D) ------------+ +``` + +### Implementing and registering a pass + +To create a new MIR pass, you simply implement the `MirPass` trait for +some fresh singleton type `Foo`. Once you have implemented a trait for +your type `Foo`, you then have to insert `Foo` into one of the suites; +this is done in `librustc_driver/driver.rs` by invoking `push_pass(S, +Foo)` with the appropriate suite substituted for `S`. + + +[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir +[mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir +[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir From d39ba39a24feecad5d2fba6a1bf49310a316f2a1 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:30:07 +0800 Subject: [PATCH 0048/1812] Added the mdbook-linkcheck backend --- book.toml | 3 +++ src/high-level-overview.md | 4 +++- src/ty.md | 2 +- 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/book.toml b/book.toml index 485a12ca3..3c4c537e8 100644 --- a/book.toml +++ b/book.toml @@ -3,3 +3,6 @@ title = "Guide to Rustc Development" author = "Rustc developers" description = "A guide to developing rustc " +[output.html] + +[output.linkcheck] diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 55b596a2a..7da9b8ca1 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -43,7 +43,7 @@ The `rustc_driver` crate, at the top of this lattice, is effectively the "main" function for the rust compiler. It doesn't have much "real code", but instead ties together all of the code defined in the other crates and defines the overall flow of execution. (As we transition -more and more to the [query model](ty/maps/README.md), however, the +more and more to the [query model], however, the "flow" of compilation is becoming less centrally defined.) At the other extreme, the `rustc` crate defines the common and @@ -134,3 +134,5 @@ take: (one for each "codegen unit"). 6. **Linking** - Finally, those `.o` files are linked together. + +[query model]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/maps/README.md diff --git a/src/ty.md b/src/ty.md index 8debb71c7..906e99e71 100644 --- a/src/ty.md +++ b/src/ty.md @@ -78,7 +78,7 @@ is in fact a simple type alias for a reference with `'tcx` lifetime: pub type Ty<'tcx> = &'tcx TyS<'tcx>; ``` -[the HIR]: ../hir/README.md +[the HIR]: https://github.com/rust-lang/rust/blob/master/src/librustc/hir/README.md You can basically ignore the `TyS` struct -- you will basically never access it explicitly. We always pass it by reference using the From 8b47122474ab912abca3fcb5acc8bd4cf3266e33 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:36:23 +0800 Subject: [PATCH 0049/1812] Updated CI to install and use mdbook-linkcheck --- ci/install.sh | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/ci/install.sh b/ci/install.sh index 2d32caaa9..81cbd8fb7 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -1,12 +1,20 @@ #!/bin/bash set -ex -if command -v mdbook >/dev/null 2>&1; then - echo "mdbook already installed at $(command -v mdbook)" -else - echo "installing mdbook" - cargo install mdbook --vers "0.0.28" -fi +function cargo_install() { + local name=$1 + local version=$2 + + if command -v $name >/dev/null 2>&1; then + echo "$name is already installed at $(command -v $name)" + else + echo "Installing $name" + cargo install $name --version $version + fi +} + +cargo_install mdbook 0.1.1 +cargo_install mdbook-linkcheck 0.1.0 if command -v ghp-import >/dev/null 2>&1; then echo "ghp-import already installed at $(which ghp-import)" From acf36f823e2b7eb6605dffcde973f17c35662e6e Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:41:40 +0800 Subject: [PATCH 0050/1812] Removed ghp-import and run mdbook build unconditionally --- .travis.yml | 5 +---- ci/github_pages.sh | 11 ----------- ci/install.sh | 7 ------- 3 files changed, 1 insertion(+), 22 deletions(-) delete mode 100644 ci/github_pages.sh diff --git a/.travis.yml b/.travis.yml index 2d107794f..0862ff9bb 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,14 +1,11 @@ language: rust cache: -- pip - cargo install: - source ~/.cargo/env || true - bash ci/install.sh script: -- true -after_success: -- bash ci/github_pages.sh +- RUST_LOG=debug mdbook build notifications: email: on_success: never diff --git a/ci/github_pages.sh b/ci/github_pages.sh deleted file mode 100644 index ffd89ad52..000000000 --- a/ci/github_pages.sh +++ /dev/null @@ -1,11 +0,0 @@ -#!/bin/bash -set -ex - -BOOK_DIR=book - -# Only upload the built book to github pages if it's a commit to master -if [ "$TRAVIS_BRANCH" = master -a "$TRAVIS_PULL_REQUEST" = false ]; then - mdbook build -else - echo Skipping 'mdbook build' because this is not master or this is just a PR. -fi diff --git a/ci/install.sh b/ci/install.sh index 81cbd8fb7..99c85986c 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -15,10 +15,3 @@ function cargo_install() { cargo_install mdbook 0.1.1 cargo_install mdbook-linkcheck 0.1.0 - -if command -v ghp-import >/dev/null 2>&1; then - echo "ghp-import already installed at $(which ghp-import)" -else - echo "installing ghp-import" - pip install --user ghp-import -fi From 79052b4acaf14d45f00440e10fd2658b30c7bb55 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:53:46 +0800 Subject: [PATCH 0051/1812] Added a note about how to use mdbook-linkcheck --- README.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/README.md b/README.md index 5ff51de2b..352c4ce0b 100644 --- a/README.md +++ b/README.md @@ -25,3 +25,11 @@ for you to talk with someone who **does** know the code, or who wants to pair with you and figure it out. Then you can work on writing up what you learned. +To help prevent accidentally introducing broken links, we use the +`mdbook-linkcheck`. If installed on your machine `mdbook` will automatically +invoke this link checker, otherwise it will emit a warning saying it couldn't +be found. + +``` +$ cargo install mdbook-linkcheck +``` From 66d2008ac082049f6214eb50af45a15b994762a0 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Sat, 27 Jan 2018 14:54:56 +0800 Subject: [PATCH 0052/1812] Toned down the log verbosity --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 0862ff9bb..f17a947d4 100644 --- a/.travis.yml +++ b/.travis.yml @@ -5,7 +5,7 @@ install: - source ~/.cargo/env || true - bash ci/install.sh script: -- RUST_LOG=debug mdbook build +- mdbook build notifications: email: on_success: never From 046dc79b9de938b5007544b2d3fb61a6f3e7b7f6 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 31 Jan 2018 11:30:17 -0500 Subject: [PATCH 0053/1812] update to link within the book --- src/high-level-overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 7da9b8ca1..519d822e2 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -135,4 +135,5 @@ take: 6. **Linking** - Finally, those `.o` files are linked together. -[query model]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/maps/README.md + +[query model]: query.html From 0cedd25595e5fd7e531b6ed9035a6b60d55e240a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 31 Jan 2018 11:31:43 -0500 Subject: [PATCH 0054/1812] Update link to hir --- src/ty.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ty.md b/src/ty.md index 906e99e71..e29ecb5e3 100644 --- a/src/ty.md +++ b/src/ty.md @@ -78,7 +78,7 @@ is in fact a simple type alias for a reference with `'tcx` lifetime: pub type Ty<'tcx> = &'tcx TyS<'tcx>; ``` -[the HIR]: https://github.com/rust-lang/rust/blob/master/src/librustc/hir/README.md +[the HIR]: ./hir.html You can basically ignore the `TyS` struct -- you will basically never access it explicitly. We always pass it by reference using the From 04cee3e1be2c2151524441bd13ea4009f54fb566 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 31 Jan 2018 14:13:49 -0500 Subject: [PATCH 0055/1812] fix some broken links --- src/macro-expansion.md | 2 +- src/type-inference.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index a7777e80c..ee4bd322c 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -158,4 +158,4 @@ TODO [code_mp]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt/macro_parser.rs [code_mp]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt/macro_rules.rs [code_parse_int]: https://github.com/rust-lang/rust/blob/a97cd17f5d71fb4ec362f4fbd79373a6e7ed7b82/src/libsyntax/ext/tt/macro_parser.rs#L421 -[parsing]: ./the-parser.md +[parsing]: ./the-parser.html diff --git a/src/type-inference.md b/src/type-inference.md index 6e2032fee..feb694196 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -32,7 +32,7 @@ fresh types and things that it will create, as described in [the README in the ty module][ty-readme]. This arena is created by the `enter` function and disposed after it returns. -[ty-readme]: src/librustc/ty/README.md +[ty-readme]: ty.html Within the closure, the infcx will have the type `InferCtxt<'cx, 'gcx, 'tcx>` for some fresh `'cx` and `'tcx` -- the latter corresponds to @@ -107,7 +107,7 @@ actual return type is not `()`, but rather `InferOk<()>`. The to ensure that these are fulfilled (typically by enrolling them in a fulfillment context). See the [trait README] for more background here. -[trait README]: ../traits/README.md +[trait README]: trait-resolution.html You can also enforce subtyping through `infcx.at(..).sub(..)`. The same basic concepts apply as above. From 4066211f4714aa4d41ccb03fcec550dfba2a0ce1 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 31 Jan 2018 14:18:51 -0500 Subject: [PATCH 0056/1812] update wording to be a bit more clear --- src/how-to-build-and-run.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 24cfbfad7..7992dc987 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -54,12 +54,16 @@ compiler to compile the newer version. In particular, the newer version of the compiler, `libstd`, and other tooling may use some unstable features internally. The result is the compiling `rustc` is done in stages. -- Stage 0: the current _beta_ compiler is compiled using the current _stable_ compiler. -- Stage 1: the code in your clone is then compiled with the stage 0 compiler. -- Stage 2: the code in your clone is then compiled with the stage 1 compiler (i.e. it builds itself). - -For hacking, often building the stage 1 compiler is enough, but for testing and -release, the stage 2 compiler is used. +- **Stage 0:** the stage0 compiler is the current _beta_ compiler; we + download this binary from the internet. +- **Stage 1:** the code in your clone is then compiled with the stage + 0 compiler to produce the stage 1 compiler. +- **Stage 2:** the code in your clone is then compiled with the stage + 1 compiler *again* to produce the stage 2 compiler (i.e. it builds + itself). + +For hacking, often building the stage 1 compiler is enough, but for +final testing and release, the stage 2 compiler is used. Once you've created a config.toml, you are now ready to run `x.py`. There are a lot of options here, but let's start with what is From ddad2c3e95fa4e8d15867a6192ab6052527aba59 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 1 Feb 2018 03:47:39 +0000 Subject: [PATCH 0057/1812] fixed definition of code_mr hyperlink --- src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index ee4bd322c..8f94d6a0a 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -156,6 +156,6 @@ TODO [code_dir]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt [code_mp]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt/macro_parser.rs -[code_mp]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt/macro_rules.rs +[code_mr]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt/macro_rules.rs [code_parse_int]: https://github.com/rust-lang/rust/blob/a97cd17f5d71fb4ec362f4fbd79373a6e7ed7b82/src/libsyntax/ext/tt/macro_parser.rs#L421 [parsing]: ./the-parser.html From 9ad3a69332a24e4c98a1c978ba539f921d52d8bf Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 1 Feb 2018 03:50:28 +0000 Subject: [PATCH 0058/1812] replaced all instances of `--` (double hyphen) with `-` (en-dash) --- src/high-level-overview.md | 8 ++++---- src/hir.md | 6 +++--- src/how-to-build-and-run.md | 10 +++++----- src/macro-expansion.md | 2 +- src/mir.md | 10 +++++----- src/query.md | 4 ++-- src/trait-resolution.md | 18 +++++++++--------- src/ty.md | 12 ++++++------ src/type-inference.md | 12 ++++++------ 9 files changed, 41 insertions(+), 41 deletions(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 519d822e2..50ed072b8 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -13,7 +13,7 @@ many more. The source for each crate can be found in a directory like `src/libXXX`, where `XXX` is the crate name. (NB. The names and divisions of these crates are not set in -stone and may change over time -- for the time being, we tend towards +stone and may change over time – for the time being, we tend towards a finer-grained division to help with compilation time, though as incremental improves that may change.) @@ -53,7 +53,7 @@ also contains some amount of the compiler itself, although that is relatively limited. Finally, all the crates in the bulge in the middle define the bulk of -the compiler -- they all depend on `rustc`, so that they can make use +the compiler – they all depend on `rustc`, so that they can make use of the various types defined there, and they export public routines that `rustc_driver` will invoke as needed (more and more, what these crates export are "query definitions", but those are covered later @@ -117,9 +117,9 @@ take: - An important step in processing the HIR is to perform type checking. This process assigns types to every HIR expression, for example, and also is responsible for resolving some - "type-dependent" paths, such as field accesses (`x.f` -- we + "type-dependent" paths, such as field accesses (`x.f` – we can't know what field `f` is being accessed until we know the - type of `x`) and associated type references (`T::Item` -- we + type of `x`) and associated type references (`T::Item` – we can't know what type `Item` is until we know what `T` is). - Type checking creates "side-tables" (`TypeckTables`) that include the types of expressions, the way to resolve methods, and so forth. diff --git a/src/hir.md b/src/hir.md index 5d5e273c4..52fda69a6 100644 --- a/src/hir.md +++ b/src/hir.md @@ -1,6 +1,6 @@ # The HIR -The HIR -- "High-level IR" -- is the primary IR used in most of +The HIR – "High-level IR" – is the primary IR used in most of rustc. It is a desugared version of the "abstract syntax tree" (AST) that is generated after parsing, macro expansion, and name resolution have completed. Many parts of HIR resemble Rust surface syntax quite @@ -91,7 +91,7 @@ with a HIR node. For example, if you have a `DefId`, and you would like to convert it to a `NodeId`, you can use `tcx.hir.as_local_node_id(def_id)`. This -returns an `Option` -- this will be `None` if the def-id +returns an `Option` – this will be `None` if the def-id refers to something outside of the current crate (since then it has no HIR node), but otherwise returns `Some(n)` where `n` is the node-id of the definition. @@ -100,7 +100,7 @@ Similarly, you can use `tcx.hir.find(n)` to lookup the node for a `NodeId`. This returns a `Option>`, where `Node` is an enum defined in the map; by matching on this you can find out what sort of node the node-id referred to and also get a pointer to the data -itself. Often, you know what sort of node `n` is -- e.g., if you know +itself. Often, you know what sort of node `n` is – e.g., if you know that `n` must be some HIR expression, you can do `tcx.hir.expect_expr(n)`, which will extract and return the `&hir::Expr`, panicking if `n` is not in fact an expression. diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 7992dc987..2657da84c 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -129,9 +129,9 @@ LLVM version: 4.0 Here are a few other useful x.py commands. We'll cover some of them in detail in other sections: - Building things: - - `./x.py clean` -- clean up the build directory (`rm -rf build` works too, but then you have to rebuild LLVM) - - `./x.py build --stage 1` -- builds everything using the stage 1 compiler, not just up to libstd - - `./x.py build` -- builds the stage2 compiler + - `./x.py clean` – clean up the build directory (`rm -rf build` works too, but then you have to rebuild LLVM) + - `./x.py build --stage 1` – builds everything using the stage 1 compiler, not just up to libstd + - `./x.py build` – builds the stage2 compiler - Running tests (see the section [running tests](./running-tests.html) for more details): - - `./x.py test --stage 1 src/libstd` -- runs the `#[test]` tests from libstd - - `./x.py test --stage 1 src/test/run-pass` -- runs the `run-pass` test suite + - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd + - `./x.py test --stage 1 src/test/run-pass` – runs the `run-pass` test suite diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 8f94d6a0a..55a550b56 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -33,7 +33,7 @@ a tree of _tokens_. A _token_ is a single "unit" of the grammar, such as an identifier (e.g., `foo`) or punctuation (e.g., `=>`). There are also other special tokens, such as `EOF`, which indicates that there are no more tokens. Token trees resulting from paired parentheses-like characters (`(`...`)`, -`[`...`]`, and `{`...`}`) -- they include the open and close and all the tokens +`[`...`]`, and `{`...`}`) – they include the open and close and all the tokens in between (we do require that parentheses-like characters be balanced). Having macro expansion operate on token streams rather than the raw bytes of a source file abstracts away a lot of complexity. The macro expander (and much of the diff --git a/src/mir.md b/src/mir.md index dbac8eb53..34f6bbb8f 100644 --- a/src/mir.md +++ b/src/mir.md @@ -49,17 +49,17 @@ query. Each suite consists of multiple optimizations and transformations. These suites represent useful intermediate points where we want to access the MIR for type checking or other purposes: -- `mir_build(D)` -- not a query, but this constructs the initial MIR -- `mir_const(D)` -- applies some simple transformations to make MIR ready for constant evaluation; -- `mir_validated(D)` -- applies some more transformations, making MIR ready for borrow checking; -- `optimized_mir(D)` -- the final state, after all optimizations have been performed. +- `mir_build(D)` – not a query, but this constructs the initial MIR +- `mir_const(D)` – applies some simple transformations to make MIR ready for constant evaluation; +- `mir_validated(D)` – applies some more transformations, making MIR ready for borrow checking; +- `optimized_mir(D)` – the final state, after all optimizations have been performed. ### Stealing The intermediate queries `mir_const()` and `mir_validated()` yield up a `&'tcx Steal>`, allocated using `tcx.alloc_steal_mir()`. This indicates that the result may be -**stolen** by the next suite of optimizations -- this is an +**stolen** by the next suite of optimizations – this is an optimization to avoid cloning the MIR. Attempting to use a stolen result will cause a panic in the compiler. Therefore, it is important that you do not read directly from these intermediate queries except as diff --git a/src/query.md b/src/query.md index 65d651307..fa17a3850 100644 --- a/src/query.md +++ b/src/query.md @@ -11,7 +11,7 @@ it to you. [hl]: high-level-overview.html -Query execution is **memoized** -- so the first time you invoke a +Query execution is **memoized** – so the first time you invoke a query, it will go do the computation, but the next time, the result is returned from a hashtable. Moreover, query execution fits nicely into **incremental computation**; the idea is roughly that, when you do a @@ -98,7 +98,7 @@ message"`. This is basically just a precaution in case you are wrong. So you may be wondering what happens when you invoke a query method. The answer is that, for each query, the compiler maintains a -cache -- if your query has already been executed, then, the answer is +cache – if your query has already been executed, then, the answer is simple: we clone the return value out of the cache and return it (therefore, you should try to ensure that the return types of queries are cheaply cloneable; insert a `Rc` if necessary). diff --git a/src/trait-resolution.md b/src/trait-resolution.md index 58efbd050..63f72b014 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -73,16 +73,16 @@ resolved and, if so, how it is to be resolved (via impl, where clause, etc). The main interface is the `select()` function, which takes an obligation and returns a `SelectionResult`. There are three possible outcomes: -- `Ok(Some(selection))` -- yes, the obligation can be resolved, and +- `Ok(Some(selection))` – yes, the obligation can be resolved, and `selection` indicates how. If the impl was resolved via an impl, then `selection` may also indicate nested obligations that are required by the impl. -- `Ok(None)` -- we are not yet sure whether the obligation can be +- `Ok(None)` – we are not yet sure whether the obligation can be resolved or not. This happens most commonly when the obligation contains unbound type variables. -- `Err(err)` -- the obligation definitely cannot be resolved due to a +- `Err(err)` – the obligation definitely cannot be resolved due to a type error, or because there are no impls that could possibly apply, etc. @@ -95,7 +95,7 @@ Searches for impls/where-clauses/etc that might possibly be used to satisfy the obligation. Each of those is called a candidate. To avoid ambiguity, we want to find exactly one candidate that is definitively applicable. In some cases, we may not -know whether an impl/where-clause applies or not -- this occurs when +know whether an impl/where-clause applies or not – this occurs when the obligation contains unbound inference variables. The basic idea for candidate assembly is to do a first pass in which @@ -172,11 +172,11 @@ impl Get for Box { ``` What happens when we invoke `get_it(&box 1_u16)`, for example? In this -case, the `Self` type is `Box` -- that unifies with both impls, +case, the `Self` type is `Box` – that unifies with both impls, because the first applies to all types, and the second to all boxes. In the olden days we'd have called this ambiguous. But what we do now is do a second *winnowing* pass that considers where clauses -and attempts to remove candidates -- in this case, the first impl only +and attempts to remove candidates – in this case, the first impl only applies if `Box : Copy`, which doesn't hold. After winnowing, then, we are left with just one candidate, so we can proceed. There is a test of this in `src/test/run-pass/traits-conditional-dispatch.rs`. @@ -326,7 +326,7 @@ to a `TraitRef`. We would then create the `TraitRef` from the impl, using fresh variables for it's bound regions (and thus getting `Foo<&'$a isize>`, where `'$a` is the inference variable for `'a`). Next we relate the two trait refs, yielding a graph with the constraint -that `'0 == '$a`. Finally, we check for skolemization "leaks" -- a +that `'0 == '$a`. Finally, we check for skolemization "leaks" – a leak is basically any attempt to relate a skolemized region to another skolemized region, or to any region that pre-existed the impl match. The leak check is done by searching from the skolemized region to find @@ -457,7 +457,7 @@ and the graph is consulted when propagating defaults down the specialization hierarchy. You might expect that the specialization graph would be used during -selection -- i.e., when actually performing specialization. This is +selection – i.e., when actually performing specialization. This is not done for two reasons: - It's merely an optimization: given a set of candidates that apply, @@ -476,7 +476,7 @@ not done for two reasons: Trait impl selection can succeed even when multiple impls can apply, as long as they are part of the same specialization family. In that -case, it returns a *single* impl on success -- this is the most +case, it returns a *single* impl on success – this is the most specialized impl *known* to apply. However, if there are any inference variables in play, the returned impl may not be the actual impl we will use at trans time. Thus, we take special care to avoid projecting diff --git a/src/ty.md b/src/ty.md index e29ecb5e3..0732e88bd 100644 --- a/src/ty.md +++ b/src/ty.md @@ -80,9 +80,9 @@ pub type Ty<'tcx> = &'tcx TyS<'tcx>; [the HIR]: ./hir.html -You can basically ignore the `TyS` struct -- you will basically never +You can basically ignore the `TyS` struct – you will basically never access it explicitly. We always pass it by reference using the -`Ty<'tcx>` alias -- the only exception I think is to define inherent +`Ty<'tcx>` alias – the only exception I think is to define inherent methods on types. Instances of `TyS` are only ever allocated in one of the rustc arenas (never e.g. on the stack). @@ -115,7 +115,7 @@ of type variants. For example: let array_ty = tcx.mk_array(elem_ty, len * 2); ``` -These methods all return a `Ty<'tcx>` -- note that the lifetime you +These methods all return a `Ty<'tcx>` – note that the lifetime you get back is the lifetime of the innermost arena that this `tcx` has access to. In fact, types are always canonicalized and interned (so we never allocate exactly the same type twice) and are always allocated @@ -125,7 +125,7 @@ allocated in the global arena). However, the lifetime `'tcx` is always a safe approximation, so that is what you get back. > NB. Because types are interned, it is possible to compare them for -> equality efficiently using `==` -- however, this is almost never what +> equality efficiently using `==` – however, this is almost never what > you want to do unless you happen to be hashing and looking for > duplicates. This is because often in Rust there are multiple ways to > represent the same type, particularly once inference is involved. If @@ -141,10 +141,10 @@ In addition to types, there are a number of other arena-allocated data structures that you can allocate, and which are found in this module. Here are a few examples: -- `Substs`, allocated with `mk_substs` -- this will intern a slice of types, often used to +- `Substs`, allocated with `mk_substs` – this will intern a slice of types, often used to specify the values to be substituted for generics (e.g., `HashMap` would be represented as a slice `&'tcx [tcx.types.i32, tcx.types.u32]`). -- `TraitRef`, typically passed by value -- a **trait reference** +- `TraitRef`, typically passed by value – a **trait reference** consists of a reference to a trait along with its various type parameters (including `Self`), like `i32: Display` (here, the def-id would reference the `Display` trait, and the substs would contain diff --git a/src/type-inference.md b/src/type-inference.md index feb694196..070b7bb4c 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -35,7 +35,7 @@ function and disposed after it returns. [ty-readme]: ty.html Within the closure, the infcx will have the type `InferCtxt<'cx, 'gcx, -'tcx>` for some fresh `'cx` and `'tcx` -- the latter corresponds to +'tcx>` for some fresh `'cx` and `'tcx` – the latter corresponds to the lifetime of this temporary arena, and the `'cx` is the lifetime of the `InferCtxt` itself. (Again, see [that ty README][ty-readme] for more details on this setup.) @@ -47,7 +47,7 @@ created. See `InferCtxtBuilder` for more information. ## Inference variables The main purpose of the inference context is to house a bunch of -**inference variables** -- these represent types or regions whose precise +**inference variables** – these represent types or regions whose precise value is not yet known, but will be uncovered as we perform type-checking. If you're familiar with the basic ideas of unification from H-M type @@ -95,15 +95,15 @@ doing this unification, and in what environment, and the `eq` method performs the actual equality constraint. When you equate things, you force them to be precisely equal. Equating -returns a `InferResult` -- if it returns `Err(err)`, then equating +returns a `InferResult` – if it returns `Err(err)`, then equating failed, and the enclosing `TypeError` will tell you what went wrong. The success case is perhaps more interesting. The "primary" return -type of `eq` is `()` -- that is, when it succeeds, it doesn't return a +type of `eq` is `()` – that is, when it succeeds, it doesn't return a value of any particular interest. Rather, it is executed for its side-effects of constraining type variables and so forth. However, the actual return type is not `()`, but rather `InferOk<()>`. The -`InferOk` type is used to carry extra trait obligations -- your job is +`InferOk` type is used to carry extra trait obligations – your job is to ensure that these are fulfilled (typically by enrolling them in a fulfillment context). See the [trait README] for more background here. @@ -117,7 +117,7 @@ basic concepts apply as above. Sometimes you would like to know if it is *possible* to equate two types without error. You can test that with `infcx.can_eq` (or `infcx.can_sub` for subtyping). If this returns `Ok`, then equality -is possible -- but in all cases, any side-effects are reversed. +is possible – but in all cases, any side-effects are reversed. Be aware though that the success or failure of these methods is always **modulo regions**. That is, two types `&'a u32` and `&'b u32` will From 96d3038965af3259d09576c8feb2dd3294b19d78 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 1 Feb 2018 03:57:51 +0000 Subject: [PATCH 0059/1812] minor grammatical fixes --- src/macro-expansion.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 55a550b56..a43c09394 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -134,8 +134,9 @@ it calls back to the normal Rust parser to get the contents of that non-terminal. In this case, the Rust parser would look for an `ident` token, which it finds (`foo`) and returns to the macro parser. Then, the macro parser proceeds in parsing as normal. Also, note that exactly one of the matchers from -the various arms should match the invocation (otherwise, the macro is -ambiguous). +the various arms should match the invocation; if there is more than one match, +the parse is ambiguous, while if there are no matches at all, there is a syntax +error. For more information about the macro parser's implementation, see the comments in [`src/libsyntax/ext/tt/macro_parser.rs`][code_mp]. From e022bcd2141ba47394c12980a0fef1f67091221c Mon Sep 17 00:00:00 2001 From: avborhanian Date: Sat, 3 Feb 2018 00:51:25 -0500 Subject: [PATCH 0060/1812] Adding ICH to the glossary. --- src/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glossary.md b/src/glossary.md index 3202e5f4c..186e1a4c7 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -14,6 +14,7 @@ HirId | identifies a particular node in the HIR by combining 'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item ICE | internal compiler error. When the compiler crashes. +ICH | incremental compilation hash. infcx | the inference context (see `librustc/infer`) MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) From 4a72994f113b8fbd65343150e55ba33db3bd92aa Mon Sep 17 00:00:00 2001 From: avborhanian Date: Sun, 4 Feb 2018 13:46:29 -0500 Subject: [PATCH 0061/1812] Update glossary.md --- src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glossary.md b/src/glossary.md index 186e1a4c7..ee27362af 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -14,7 +14,7 @@ HirId | identifies a particular node in the HIR by combining 'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item ICE | internal compiler error. When the compiler crashes. -ICH | incremental compilation hash. +ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. infcx | the inference context (see `librustc/infer`) MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) From 1d9eeb079f46753ed451d174a554456f50c40d41 Mon Sep 17 00:00:00 2001 From: avborhanian Date: Sun, 4 Feb 2018 13:54:45 -0500 Subject: [PATCH 0062/1812] Update glossary.md --- src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glossary.md b/src/glossary.md index ee27362af..10c2d4535 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -14,7 +14,7 @@ HirId | identifies a particular node in the HIR by combining 'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item ICE | internal compiler error. When the compiler crashes. -ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. +ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. infcx | the inference context (see `librustc/infer`) MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) From dc037e216bf4cb9daf588d131b5abc854e538d17 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 4 Feb 2018 16:11:19 -0600 Subject: [PATCH 0063/1812] Update README.md --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 352c4ce0b..7e468fbb0 100644 --- a/README.md +++ b/README.md @@ -33,3 +33,5 @@ be found. ``` $ cargo install mdbook-linkcheck ``` +You will need `mdbook` version `>= 0.1`. `linkcheck` will be run automatically +when you run `mdbook build`. From c32587aaed2086e49ca58b1ef9372b2c83e84f8e Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 18:37:37 +0000 Subject: [PATCH 0064/1812] Renamed `trans: generating LLVM IR` section. --- src/SUMMARY.md | 2 +- src/trans.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 8e18969a1..8f128f648 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -19,5 +19,5 @@ - [MIR construction](./mir-construction.md) - [MIR borrowck](./mir-borrowck.md) - [MIR optimizations](./mir-optimizations.md) -- [trans: generating LLVM IR](./trans.md) +- [The `trans` crate: generating LLVM IR](./trans.md) - [Glossary](./glossary.md) diff --git a/src/trans.md b/src/trans.md index 7092b7a0b..efff52ef9 100644 --- a/src/trans.md +++ b/src/trans.md @@ -1 +1 @@ -# trans: generating LLVM IR +# The `trans` crate: generating LLVM IR From 1a399f5ea3c861b7ae3d282f621eabad59e34c19 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 18:48:38 +0000 Subject: [PATCH 0065/1812] Improved grammar of HIR section. --- src/hir.md | 89 ++++++++++++++++++++++++++---------------------------- 1 file changed, 43 insertions(+), 46 deletions(-) diff --git a/src/hir.md b/src/hir.md index 52fda69a6..ac7690bd5 100644 --- a/src/hir.md +++ b/src/hir.md @@ -1,12 +1,11 @@ # The HIR -The HIR – "High-level IR" – is the primary IR used in most of -rustc. It is a desugared version of the "abstract syntax tree" (AST) -that is generated after parsing, macro expansion, and name resolution -have completed. Many parts of HIR resemble Rust surface syntax quite -closely, with the exception that some of Rust's expression forms have -been desugared away (as an example, `for` loops are converted into a -`loop` and do not appear in the HIR). +The HIR – "High-level IR" – is the primary IR used in most of rustc. +It is a desugared version of the "abstract syntax tree" (AST) that is generated +after parsing, macro expansion, and name resolution have completed. Many parts +of HIR resemble Rust surface syntax quite closely, with the exception that some +of Rust's expression forms have been desugared away (as an example, `for` loops +are converted into a `loop` and do not appear in the HIR). This chapter covers the main concepts of the HIR. @@ -21,8 +20,8 @@ serve to organize the content of the crate for easier access. For example, the contents of individual items (e.g., modules, functions, traits, impls, etc) in the HIR are not immediately -accessible in the parents. So, for example, if had a module item `foo` -containing a function `bar()`: +accessible in the parents. So, for example, if there is a module item +`foo` containing a function `bar()`: ``` mod foo { @@ -30,25 +29,25 @@ mod foo { } ``` -Then in the HIR the representation of module `foo` (the `Mod` -stuct) would have only the **`ItemId`** `I` of `bar()`. To get the +then in the HIR the representation of module `foo` (the `Mod` +stuct) would only have the **`ItemId`** `I` of `bar()`. To get the details of the function `bar()`, we would lookup `I` in the `items` map. One nice result from this representation is that one can iterate over all items in the crate by iterating over the key-value pairs -in these maps (without the need to trawl through the IR in total). +in these maps (without the need to trawl through the whole HIR). There are similar maps for things like trait items and impl items, as well as "bodies" (explained below). -The other reason to setup the representation this way is for better +The other reason to set up the representation this way is for better integration with incremental compilation. This way, if you gain access -to a `&hir::Item` (e.g. for the mod `foo`), you do not immediately +to an `&hir::Item` (e.g. for the mod `foo`), you do not immediately gain access to the contents of the function `bar()`. Instead, you only gain access to the **id** for `bar()`, and you must invoke some -function to lookup the contents of `bar()` given its id; this gives us -a chance to observe that you accessed the data for `bar()` and record -the dependency. +function to lookup the contents of `bar()` given its id; this gives the +compiler a chance to observe that you accessed the data for `bar()`, +and then record the dependency. ### Identifiers in the HIR @@ -57,37 +56,35 @@ carry around references into the HIR, but rather to carry around *identifier numbers* (or just "ids"). Right now, you will find four sorts of identifiers in active use: -- `DefId`, which primarily names "definitions" or top-level items. - - You can think of a `DefId` as being shorthand for a very explicit - and complete path, like `std::collections::HashMap`. However, - these paths are able to name things that are not nameable in - normal Rust (e.g., impls), and they also include extra information - about the crate (such as its version number, as two versions of - the same crate can co-exist). - - A `DefId` really consists of two parts, a `CrateNum` (which - identifies the crate) and a `DefIndex` (which indixes into a list - of items that is maintained per crate). -- `HirId`, which combines the index of a particular item with an - offset within that item. - - the key point of a `HirId` is that it is *relative* to some item (which is named - via a `DefId`). -- `BodyId`, this is an absolute identifier that refers to a specific - body (definition of a function or constant) in the crate. It is currently - effectively a "newtype'd" `NodeId`. -- `NodeId`, which is an absolute id that identifies a single node in the HIR tree. +- `DefId` – primarily names "definitions" or top-level items. + - You can think of a `DefId` as shorthand for a very explicit and complete + path, like `std::collections::HashMap`. However, these paths are able to + name things that are not nameable in normal Rust (e.g. impls), and they also + include extra information about the crate (such as its version number, since + two versions of the same crate can co-exist). + - A `DefId` really consists of two parts, a `CrateNum` (which identifies the + crate) and a `DefIndex` (which indexes into a list of items that is + maintained per crate). +- `HirId` – combines the index of a particular item with an offset within + that item. + - The key point of an `HirId` is that it is *relative* to some item (which is + named via a `DefId`). +- `BodyId` – an absolute identifier that refers to a specific body (definition + of a function or constant) in the crate. It is currently effectively a + "newtype'd" `NodeId`. +- `NodeId` – an absolute ID that identifies a single node in the HIR tree. - While these are still in common use, **they are being slowly phased out**. - - Since they are absolute within the crate, adding a new node - anywhere in the tree causes the node-ids of all subsequent code in - the crate to change. This is terrible for incremental compilation, - as you can perhaps imagine. + - Since they are absolute within the crate, adding a new node anywhere in the + tree causes the `NodeId`s of all subsequent code in the crate to change. + This is terrible for incremental compilation, as you can perhaps imagine. -### HIR Map +### The HIR Map Most of the time when you are working with the HIR, you will do so via the **HIR Map**, accessible in the tcx via `tcx.hir` (and defined in the `hir::map` module). The HIR map contains a number of methods to -convert between ids of various kinds and to lookup data associated -with a HIR node. +convert between IDs of various kinds and to lookup data associated +with an HIR node. For example, if you have a `DefId`, and you would like to convert it to a `NodeId`, you can use `tcx.hir.as_local_node_id(def_id)`. This @@ -100,7 +97,7 @@ Similarly, you can use `tcx.hir.find(n)` to lookup the node for a `NodeId`. This returns a `Option>`, where `Node` is an enum defined in the map; by matching on this you can find out what sort of node the node-id referred to and also get a pointer to the data -itself. Often, you know what sort of node `n` is – e.g., if you know +itself. Often, you know what sort of node `n` is – e.g. if you know that `n` must be some HIR expression, you can do `tcx.hir.expect_expr(n)`, which will extract and return the `&hir::Expr`, panicking if `n` is not in fact an expression. @@ -113,7 +110,7 @@ calls like `tcx.hir.get_parent_node(n)`. A **body** represents some kind of executable code, such as the body of a function/closure or the definition of a constant. Bodies are associated with an **owner**, which is typically some kind of item -(e.g., a `fn()` or `const`), but could also be a closure expression -(e.g., `|x, y| x + y`). You can use the HIR map to find the body -associated with a given def-id (`maybe_body_owned_by()`) or to find +(e.g. an `fn()` or `const`), but could also be a closure expression +(e.g. `|x, y| x + y`). You can use the HIR map to find the body +associated with a given `DefId` (`maybe_body_owned_by()`) or to find the owner of a body (`body_owner_def_id()`). From 7d7d9171b8be728783453c02b98a5b2a11fdfd7f Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 18:49:41 +0000 Subject: [PATCH 0066/1812] Changed all instances of `e.g.,` to `e.g.`, and similar. --- CODE_OF_CONDUCT.md | 4 ++-- src/glossary.md | 2 +- src/high-level-overview.md | 6 +++--- src/hir.md | 2 +- src/macro-expansion.md | 2 +- src/query.md | 4 ++-- src/trait-resolution.md | 2 +- src/type-inference.md | 2 +- 8 files changed, 12 insertions(+), 12 deletions(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index d42476bc4..89a9cdfcc 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -23,8 +23,8 @@ These are the policies for upholding our community's standards of conduct. If yo 1. Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.) 2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed. 3. Moderators will first respond to such remarks with a warning. -4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of the communication channel to cool off. -5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely excluded. +4. If the warning is unheeded, the user will be "kicked," i.e. kicked out of the communication channel to cool off. +5. If the user comes back and continues to make trouble, they will be banned, i.e. indefinitely excluded. 6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology. 7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed. 8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others. diff --git a/src/glossary.md b/src/glossary.md index 10c2d4535..91af4c7da 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -25,7 +25,7 @@ provider | the function that executes a query ([see more](query. sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. -substs | the substitutions for a given generic type or item (e.g., the `i32`, `u32` in `HashMap`) +substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) tcx | the "typing context", main data structure of the compiler ([see more](ty.html)) 'tcx | the lifetime of the currently active inference context ([see more](ty.html)) trans | the code to translate MIR into LLVM IR. diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 50ed072b8..0d3ad8be5 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -48,7 +48,7 @@ more and more to the [query model], however, the At the other extreme, the `rustc` crate defines the common and pervasive data structures that all the rest of the compiler uses -(e.g., how to represent types, traits, and the program itself). It +(e.g. how to represent types, traits, and the program itself). It also contains some amount of the compiler itself, although that is relatively limited. @@ -77,8 +77,8 @@ purely "pass-based" compiler, where we ran a number of passes over the entire program, and each did a particular check of transformation. We are gradually replacing this pass-based code with an alternative setup based on on-demand **queries**. In the query-model, we work backwards, -executing a *query* that expresses our ultimate goal (e.g., "compile -this crate"). This query in turn may make other queries (e.g., "get me +executing a *query* that expresses our ultimate goal (e.g. "compile +this crate"). This query in turn may make other queries (e.g. "get me a list of all modules in the crate"). Those queries make other queries that ultimately bottom out in the base operations, like parsing the input, running the type-checker, and so forth. This on-demand model diff --git a/src/hir.md b/src/hir.md index ac7690bd5..d7eff5cd9 100644 --- a/src/hir.md +++ b/src/hir.md @@ -18,7 +18,7 @@ data structure basically just contains the root module, the HIR `Crate` structure contains a number of maps and other things that serve to organize the content of the crate for easier access. -For example, the contents of individual items (e.g., modules, +For example, the contents of individual items (e.g. modules, functions, traits, impls, etc) in the HIR are not immediately accessible in the parents. So, for example, if there is a module item `foo` containing a function `bar()`: diff --git a/src/macro-expansion.md b/src/macro-expansion.md index a43c09394..95ea64f19 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -30,7 +30,7 @@ macro_rules! printer { `$mvar` is called a _metavariable_. Unlike normal variables, rather than binding to a value in a computation, a metavariable binds _at compile time_ to a tree of _tokens_. A _token_ is a single "unit" of the grammar, such as an -identifier (e.g., `foo`) or punctuation (e.g., `=>`). There are also other +identifier (e.g. `foo`) or punctuation (e.g. `=>`). There are also other special tokens, such as `EOF`, which indicates that there are no more tokens. Token trees resulting from paired parentheses-like characters (`(`...`)`, `[`...`]`, and `{`...`}`) – they include the open and close and all the tokens diff --git a/src/query.md b/src/query.md index fa17a3850..d119c16f3 100644 --- a/src/query.md +++ b/src/query.md @@ -25,7 +25,7 @@ will in turn demand information about that crate, starting from the *end*. For example: - This "compile" query might demand to get a list of codegen-units - (i.e., modules that need to be compiled by LLVM). + (i.e. modules that need to be compiled by LLVM). - But computing the list of codegen-units would invoke some subquery that returns the list of all modules defined in the Rust source. - That query in turn would invoke something asking for the HIR. @@ -134,7 +134,7 @@ fn provider<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx, 'tcx>, ``` Providers take two arguments: the `tcx` and the query key. Note also -that they take the *global* tcx (i.e., they use the `'tcx` lifetime +that they take the *global* tcx (i.e. they use the `'tcx` lifetime twice), rather than taking a tcx with some active inference context. They return the result of the query. diff --git a/src/trait-resolution.md b/src/trait-resolution.md index 63f72b014..1c7f09e9b 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -408,7 +408,7 @@ if we had a trait reference `usize : Foo<$1>`, where `$n` is an unbound inference variable, we might replace it with `usize : Foo<%0>`, where `%n` is a skolemized type. We would then look this up in the cache. If we found a hit, the hit would tell us the immediate next step to -take in the selection process: i.e., apply impl #22, or apply where +take in the selection process: i.e. apply impl #22, or apply where clause `X : Foo`. Let's say in this case there is no hit. Therefore, we search through impls and where clauses and so forth, and we come to the conclusion that the only possible impl is this one, diff --git a/src/type-inference.md b/src/type-inference.md index 070b7bb4c..8155829fe 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -90,7 +90,7 @@ method, roughly like so: infcx.at(...).eq(t, u); ``` -The first `at()` call provides a bit of context, i.e., why you are +The first `at()` call provides a bit of context, i.e. why you are doing this unification, and in what environment, and the `eq` method performs the actual equality constraint. From 8a0935c485cea82fbf48feb84ba635214ac8f30e Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 21:15:46 +0000 Subject: [PATCH 0067/1812] Normalized instances of `N.B.`. --- src/query.md | 2 +- src/ty.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/query.md b/src/query.md index d119c16f3..481b4fed3 100644 --- a/src/query.md +++ b/src/query.md @@ -190,7 +190,7 @@ pub fn provide(providers: &mut Providers) { fn fubar<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx>, key: DefId) -> Fubar<'tcx> { .. } ``` -NB. Most of the `rustc_*` crates only provide **local +N.B. Most of the `rustc_*` crates only provide **local providers**. Almost all **extern providers** wind up going through the [`rustc_metadata` crate][rustc_metadata], which loads the information from the crate metadata. But in some cases there are crates that provide queries for diff --git a/src/ty.md b/src/ty.md index 0732e88bd..8b72d440f 100644 --- a/src/ty.md +++ b/src/ty.md @@ -102,7 +102,7 @@ The `sty` field (the origin of this name is unclear to me; perhaps structural type?) is of type `TypeVariants<'tcx>`, which is an enum defining all of the different kinds of types in the compiler. -> NB: inspecting the `sty` field on types during type inference can be +> N.B. inspecting the `sty` field on types during type inference can be > risky, as there may be inference variables and other things to > consider, or sometimes types are not yet known that will become > known later.). From 6bacd33a0b3a27df64593f9d95a3ced8a4b57092 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 21:24:50 +0000 Subject: [PATCH 0068/1812] Very minor grammatical fixes. --- src/ty.md | 2 +- src/type-inference.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/ty.md b/src/ty.md index 8b72d440f..1da70d916 100644 --- a/src/ty.md +++ b/src/ty.md @@ -135,7 +135,7 @@ a safe approximation, so that is what you get back. You can also find various common types in the `tcx` itself by accessing `tcx.types.bool`, `tcx.types.char`, etc (see `CommonTypes` for more). -### Beyond types: Other kinds of arena-allocated data structures +### Beyond types: other kinds of arena-allocated data structures In addition to types, there are a number of other arena-allocated data structures that you can allocate, and which are found in this diff --git a/src/type-inference.md b/src/type-inference.md index 8155829fe..ef97e59d8 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -9,10 +9,10 @@ and higher-ranked types. We use the notation `?T` to refer to inference variables, also called existential variables. -We use the term "region" and "lifetime" interchangeably. Both refer to +We use the terms "region" and "lifetime" interchangeably. Both refer to the `'a` in `&'a T`. -The term "bound region" refers to regions bound in a function +The term "bound region" refers to a region bound in a function signature, such as the `'a` in `for<'a> fn(&'a u32)`. A region is "free" if it is not bound. @@ -158,7 +158,7 @@ is to first "generalize" `&'a i32` into a type with a region variable: relate this new variable with the original bound: &'?b i32 <: &'a i32 - + This will result in a region constraint (see below) of `'?b: 'a`. One final interesting case is relating two unbound type variables, @@ -175,7 +175,7 @@ make (almost) no attempt to solve regions. These constraints have the form of an outlives constraint: 'a: 'b - + Actually the code tends to view them as a subregion relation, but it's the same idea: @@ -188,7 +188,7 @@ There is one case where we do some amount of eager unification. If you have an e between two regions 'a = 'b - + we will record that fact in a unification table. You can then use `opportunistic_resolve_var` to convert `'b` to `'a` (or vice versa). This is sometimes needed to ensure termination of fixed-point From 61d67c582ccd38f0fd2b2bf5fe952515c0eed8eb Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 21:28:29 +0000 Subject: [PATCH 0069/1812] Explained what HM type inference is. --- src/type-inference.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/type-inference.md b/src/type-inference.md index ef97e59d8..2cc922c76 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -1,7 +1,7 @@ # Type inference -The type inference is based on standard HM-type inference, but -extended in various way to accommodate subtyping, region inference, +The type inference is based on the standard Hindley–Milner (HM) system, +but extended in various way to accommodate subtyping, region inference, and higher-ranked types. ## A note on terminology From fde99687ab455fafb522775985932a221d9ed908 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sun, 4 Feb 2018 21:41:49 +0000 Subject: [PATCH 0070/1812] Cleaned up section on type inference. --- src/type-inference.md | 43 +++++++++++++++++++++---------------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/src/type-inference.md b/src/type-inference.md index 2cc922c76..b867c99e2 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -23,22 +23,21 @@ the following: ```rust tcx.infer_ctxt().enter(|infcx| { - // use the inference context `infcx` in here + // Use the inference context `infcx` here. }) ``` Each inference context creates a short-lived type arena to store the -fresh types and things that it will create, as described in -[the README in the ty module][ty-readme]. This arena is created by the `enter` -function and disposed after it returns. +fresh types and things that it will create, as described in the +[README in the `ty` module][ty-readme]. This arena is created by the `enter` +function and disposed of after it returns. [ty-readme]: ty.html -Within the closure, the infcx will have the type `InferCtxt<'cx, 'gcx, -'tcx>` for some fresh `'cx` and `'tcx` – the latter corresponds to -the lifetime of this temporary arena, and the `'cx` is the lifetime of -the `InferCtxt` itself. (Again, see [that ty README][ty-readme] for -more details on this setup.) +Within the closure, `infcx` has the type `InferCtxt<'cx, 'gcx, 'tcx>` +for some fresh `'cx` and `'tcx` – the latter corresponds to the lifetime of +this temporary arena, and the `'cx` is the lifetime of the `InferCtxt` itself. +(Again, see the [`ty` README][ty-readme] for more details on this setup.) The `tcx.infer_ctxt` method actually returns a build, which means there are some kinds of configuration you can do before the `infcx` is @@ -58,7 +57,7 @@ inference works, or perhaps this blog post on [Unification in the Chalk project]: http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/ -All told, the inference context stores four kinds of inference variables as of this +All said, the inference context stores four kinds of inference variables as of writing: - Type variables, which come in three varieties: @@ -67,7 +66,7 @@ writing: arise from an integer literal expression like `22`. - Float type variables, which can only be unified with a float type, and arise from a float literal expression like `22.0`. -- Region variables, which represent lifetimes, and arise all over the dang place. +- Region variables, which represent lifetimes, and arise all over the place. All the type variables work in much the same way: you can create a new type variable, and what you get is `Ty<'tcx>` representing an @@ -86,7 +85,7 @@ The most basic operations you can perform in the type inferencer is recommended way to add an equality constraint is using the `at` method, roughly like so: -``` +```rust infcx.at(...).eq(t, u); ``` @@ -95,7 +94,7 @@ doing this unification, and in what environment, and the `eq` method performs the actual equality constraint. When you equate things, you force them to be precisely equal. Equating -returns a `InferResult` – if it returns `Err(err)`, then equating +returns an `InferResult` – if it returns `Err(err)`, then equating failed, and the enclosing `TypeError` will tell you what went wrong. The success case is perhaps more interesting. The "primary" return @@ -105,12 +104,12 @@ side-effects of constraining type variables and so forth. However, the actual return type is not `()`, but rather `InferOk<()>`. The `InferOk` type is used to carry extra trait obligations – your job is to ensure that these are fulfilled (typically by enrolling them in a -fulfillment context). See the [trait README] for more background here. +fulfillment context). See the [trait README] for more background on that. [trait README]: trait-resolution.html -You can also enforce subtyping through `infcx.at(..).sub(..)`. The same -basic concepts apply as above. +You can similarly enforce subtyping through `infcx.at(..).sub(..)`. The same +basic concepts as above apply. ## "Trying" equality @@ -119,7 +118,7 @@ types without error. You can test that with `infcx.can_eq` (or `infcx.can_sub` for subtyping). If this returns `Ok`, then equality is possible – but in all cases, any side-effects are reversed. -Be aware though that the success or failure of these methods is always +Be aware, though, that the success or failure of these methods is always **modulo regions**. That is, two types `&'a u32` and `&'b u32` will return `Ok` for `can_eq`, even if `'a != 'b`. This falls out from the "two-phase" nature of how we solve region constraints. @@ -146,7 +145,7 @@ patterns. ## Subtyping obligations -One thing worth discussing are subtyping obligations. When you force +One thing worth discussing is subtyping obligations. When you force two types to be a subtype, like `?T <: i32`, we can often convert those into equality constraints. This follows from Rust's rather limited notion of subtyping: so, in the above case, `?T <: i32` is equivalent to `?T = i32`. @@ -172,11 +171,11 @@ mechanism. You'll have to try again when more details about `?T` or Regions are inferred somewhat differently from types. Rather than eagerly unifying things, we simply collect constraints as we go, but make (almost) no attempt to solve regions. These constraints have the -form of an outlives constraint: +form of an "outlives" constraint: 'a: 'b -Actually the code tends to view them as a subregion relation, but it's the same +Actually, the code tends to view them as a subregion relation, but it's the same idea: 'b <= 'a @@ -202,7 +201,7 @@ ways to solve region constraints right now: lexical and non-lexical. Eventually there will only be one. To solve **lexical** region constraints, you invoke -`resolve_regions_and_report_errors`. This will "close" the region +`resolve_regions_and_report_errors`. This "closes" the region constraint process and invoke the `lexical_region_resolve` code. Once this is done, any further attempt to equate or create a subtyping relationship will yield an ICE. @@ -224,4 +223,4 @@ Lexical region resolution is done by initially assigning each region variable to an empty value. We then process each outlives constraint repeatedly, growing region variables until a fixed-point is reached. Region variables can be grown using a least-upper-bound relation on -the region lattice in a fairly straight-forward fashion. +the region lattice in a fairly straightforward fashion. From 606e39a58b1bc17cdfccb664f076b750b6d85291 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Mon, 5 Feb 2018 02:30:32 +0000 Subject: [PATCH 0071/1812] More minor fixes. --- src/hir.md | 4 ++-- src/trait-resolution.md | 2 +- src/ty.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/hir.md b/src/hir.md index d7eff5cd9..504f04b24 100644 --- a/src/hir.md +++ b/src/hir.md @@ -23,9 +23,9 @@ functions, traits, impls, etc) in the HIR are not immediately accessible in the parents. So, for example, if there is a module item `foo` containing a function `bar()`: -``` +```rust mod foo { - fn bar() { } + fn bar() { } } ``` diff --git a/src/trait-resolution.md b/src/trait-resolution.md index 1c7f09e9b..f12ce3b4b 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -457,7 +457,7 @@ and the graph is consulted when propagating defaults down the specialization hierarchy. You might expect that the specialization graph would be used during -selection – i.e., when actually performing specialization. This is +selection – i.e. when actually performing specialization. This is not done for two reasons: - It's merely an optimization: given a set of candidates that apply, diff --git a/src/ty.md b/src/ty.md index 1da70d916..26b8c1ca8 100644 --- a/src/ty.md +++ b/src/ty.md @@ -142,7 +142,7 @@ structures that you can allocate, and which are found in this module. Here are a few examples: - `Substs`, allocated with `mk_substs` – this will intern a slice of types, often used to - specify the values to be substituted for generics (e.g., `HashMap` + specify the values to be substituted for generics (e.g. `HashMap` would be represented as a slice `&'tcx [tcx.types.i32, tcx.types.u32]`). - `TraitRef`, typically passed by value – a **trait reference** consists of a reference to a trait along with its various type @@ -161,5 +161,5 @@ use ty::{self, Ty, TyCtxt}; In particular, since they are so common, the `Ty` and `TyCtxt` types are imported directly. Other types are often referenced with an -explicit `ty::` prefix (e.g., `ty::TraitRef<'tcx>`). But some modules +explicit `ty::` prefix (e.g. `ty::TraitRef<'tcx>`). But some modules choose to import a larger or smaller set of names explicitly. From 733663967129a40a8e4c65a2b250b591f1dd94f7 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Mon, 5 Feb 2018 02:15:36 +0000 Subject: [PATCH 0072/1812] Fixed issues mentioned by @mark-i-m in review. --- src/SUMMARY.md | 2 +- src/high-level-overview.md | 12 ++++++------ src/hir.md | 6 +++--- src/trans.md | 2 +- src/type-inference.md | 8 ++++---- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 8f128f648..a2f40ed35 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -19,5 +19,5 @@ - [MIR construction](./mir-construction.md) - [MIR borrowck](./mir-borrowck.md) - [MIR optimizations](./mir-optimizations.md) -- [The `trans` crate: generating LLVM IR](./trans.md) +- [Generating LLVM IR](./trans.md) - [Glossary](./glossary.md) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 0d3ad8be5..493656713 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -12,10 +12,10 @@ Rustc consists of a number of crates, including `syntax`, many more. The source for each crate can be found in a directory like `src/libXXX`, where `XXX` is the crate name. -(NB. The names and divisions of these crates are not set in -stone and may change over time – for the time being, we tend towards -a finer-grained division to help with compilation time, though as -incremental improves that may change.) +(N.B. The names and divisions of these crates are not set in +stone and may change over time. For the time being, we tend towards a +finer-grained division to help with compilation time, though as incremental +compilation improves, that may change.) The dependency structure of these crates is roughly a diamond: @@ -37,7 +37,7 @@ rustc_trans rustc_borrowck ... rustc_metadata / \ / \ syntax_pos syntax_ext -``` +``` The `rustc_driver` crate, at the top of this lattice, is effectively the "main" function for the rust compiler. It doesn't have much "real @@ -127,7 +127,7 @@ take: 4. **Lowering to MIR and post-processing** - Once type-checking is done, we can lower the HIR into MIR ("middle IR"), which is a **very** desugared version of Rust, well suited to the borrowck but also - certain high-level optimizations. + certain high-level optimizations. 5. **Translation to LLVM and LLVM optimizations** - From MIR, we can produce LLVM IR. - LLVM then runs its various optimizations, which produces a number of `.o` files diff --git a/src/hir.md b/src/hir.md index 504f04b24..f78d2add2 100644 --- a/src/hir.md +++ b/src/hir.md @@ -59,9 +59,9 @@ sorts of identifiers in active use: - `DefId` – primarily names "definitions" or top-level items. - You can think of a `DefId` as shorthand for a very explicit and complete path, like `std::collections::HashMap`. However, these paths are able to - name things that are not nameable in normal Rust (e.g. impls), and they also - include extra information about the crate (such as its version number, since - two versions of the same crate can co-exist). + name things that are not nameable in normal Rust (e.g. `impl`s), and they + also include extra information about the crate (such as its version number, + since two versions of the same crate can co-exist). - A `DefId` really consists of two parts, a `CrateNum` (which identifies the crate) and a `DefIndex` (which indexes into a list of items that is maintained per crate). diff --git a/src/trans.md b/src/trans.md index efff52ef9..f5894baa7 100644 --- a/src/trans.md +++ b/src/trans.md @@ -1 +1 @@ -# The `trans` crate: generating LLVM IR +# Generating LLVM IR diff --git a/src/type-inference.md b/src/type-inference.md index b867c99e2..5e51c7358 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -1,8 +1,8 @@ # Type inference -The type inference is based on the standard Hindley–Milner (HM) system, -but extended in various way to accommodate subtyping, region inference, -and higher-ranked types. +The type inference is based on the standard Hindley-Milner (HM) type inference +algorithm, but extended in various way to accommodate subtyping, region +inference, and higher-ranked types. ## A note on terminology @@ -12,7 +12,7 @@ existential variables. We use the terms "region" and "lifetime" interchangeably. Both refer to the `'a` in `&'a T`. -The term "bound region" refers to a region bound in a function +The term "bound region" refers to a region that is a bound in a function signature, such as the `'a` in `for<'a> fn(&'a u32)`. A region is "free" if it is not bound. From 2b9828a566573c2d54e9b12dbee26263292a10dc Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Mon, 5 Feb 2018 03:43:46 +0000 Subject: [PATCH 0073/1812] Removed spurious `a`. --- src/type-inference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/type-inference.md b/src/type-inference.md index 5e51c7358..327bd530a 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -12,7 +12,7 @@ existential variables. We use the terms "region" and "lifetime" interchangeably. Both refer to the `'a` in `&'a T`. -The term "bound region" refers to a region that is a bound in a function +The term "bound region" refers to a region that is bound in a function signature, such as the `'a` in `for<'a> fn(&'a u32)`. A region is "free" if it is not bound. From 45db49d4de1773cc31113c49a6e23976809ae064 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 4 Feb 2018 21:51:10 -0600 Subject: [PATCH 0074/1812] Update link text --- src/type-inference.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/type-inference.md b/src/type-inference.md index 327bd530a..c4307ce7f 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -29,15 +29,15 @@ tcx.infer_ctxt().enter(|infcx| { Each inference context creates a short-lived type arena to store the fresh types and things that it will create, as described in the -[README in the `ty` module][ty-readme]. This arena is created by the `enter` +[chapter on the `ty` module][ty-ch]. This arena is created by the `enter` function and disposed of after it returns. -[ty-readme]: ty.html +[ty-ch]: ty.html Within the closure, `infcx` has the type `InferCtxt<'cx, 'gcx, 'tcx>` for some fresh `'cx` and `'tcx` – the latter corresponds to the lifetime of this temporary arena, and the `'cx` is the lifetime of the `InferCtxt` itself. -(Again, see the [`ty` README][ty-readme] for more details on this setup.) +(Again, see the [`ty` chapter][ty-ch] for more details on this setup.) The `tcx.infer_ctxt` method actually returns a build, which means there are some kinds of configuration you can do before the `infcx` is @@ -104,9 +104,9 @@ side-effects of constraining type variables and so forth. However, the actual return type is not `()`, but rather `InferOk<()>`. The `InferOk` type is used to carry extra trait obligations – your job is to ensure that these are fulfilled (typically by enrolling them in a -fulfillment context). See the [trait README] for more background on that. +fulfillment context). See the [trait chapter] for more background on that. -[trait README]: trait-resolution.html +[trait chapter]: trait-resolution.html You can similarly enforce subtyping through `infcx.at(..).sub(..)`. The same basic concepts as above apply. From 7d8cdcbb531601f52348e26c5eea64d2bd2e39f4 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Mon, 5 Feb 2018 20:39:35 +0100 Subject: [PATCH 0075/1812] Add DAG to glossary --- src/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glossary.md b/src/glossary.md index 91af4c7da..de1390d53 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -6,6 +6,7 @@ The compiler uses a number of...idiosyncratic abbreviations and things. This glo Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. +DAG | a directed acyclic graph is used during compilation to index which queries execute which other queries. ([see more](incremental-compilation.html)) codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. From 6ebe10d55aa0b3bf080150fa056e6a49888b3a3a Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 6 Feb 2018 07:54:03 +0100 Subject: [PATCH 0076/1812] Order alphabetically, improve explanation of DAG --- src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glossary.md b/src/glossary.md index de1390d53..119e73255 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -6,9 +6,9 @@ The compiler uses a number of...idiosyncratic abbreviations and things. This glo Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. -DAG | a directed acyclic graph is used during compilation to index which queries execute which other queries. ([see more](incremental-compilation.html)) codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. +DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. HIR | the High-level IR, created by lowering and desugaring the AST ([see more](hir.html)) HirId | identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". From a2d2cfa89afb9aa2aa87452e0ee414e488731b4e Mon Sep 17 00:00:00 2001 From: Phil Ellison Date: Wed, 7 Feb 2018 07:08:58 +0000 Subject: [PATCH 0077/1812] Explain how to dump HIR --- src/hir.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/hir.md b/src/hir.md index 52fda69a6..129336874 100644 --- a/src/hir.md +++ b/src/hir.md @@ -10,6 +10,14 @@ been desugared away (as an example, `for` loops are converted into a This chapter covers the main concepts of the HIR. +You can view the HIR representation of your code by passing the +`-Zunpretty=hir-tree` flag to rustc, for example by setting the `RUSTFLAGS` +environment variable: + +``` +RUSTFLAGS=-Zunpretty=hir-tree cargo build +``` + ### Out-of-band storage and the `Crate` type The top-level data-structure in the HIR is the `Crate`, which stores From 5ba0d6bc04309dc01913e6b9590efb30641276ea Mon Sep 17 00:00:00 2001 From: Phil Ellison Date: Wed, 7 Feb 2018 19:14:58 +0000 Subject: [PATCH 0078/1812] Use cargo rustc instead of setting RUSTFLAGS --- src/hir.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/hir.md b/src/hir.md index 129336874..f3145925c 100644 --- a/src/hir.md +++ b/src/hir.md @@ -11,11 +11,10 @@ been desugared away (as an example, `for` loops are converted into a This chapter covers the main concepts of the HIR. You can view the HIR representation of your code by passing the -`-Zunpretty=hir-tree` flag to rustc, for example by setting the `RUSTFLAGS` -environment variable: +`-Zunpretty=hir-tree` flag to rustc: ``` -RUSTFLAGS=-Zunpretty=hir-tree cargo build +cargo rustc -- -Zunpretty=hir-tree ``` ### Out-of-band storage and the `Crate` type From 4b7bdec2e3111f8a55e541099b3341ab1e6c38a5 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 11 Feb 2018 15:46:36 -0600 Subject: [PATCH 0079/1812] alphabetize glossary --- src/glossary.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/glossary.md b/src/glossary.md index 119e73255..b7282c3eb 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -17,12 +17,12 @@ generics | the set of generic type parameters defined on a type ICE | internal compiler error. When the compiler crashes. ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. infcx | the inference context (see `librustc/infer`) -MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) -obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) local crate | the crate currently being compiled. +MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. -query | perhaps some sub-computation during compilation ([see more](query.html)) +obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) provider | the function that executes a query ([see more](query.html)) +query | perhaps some sub-computation during compilation ([see more](query.html)) sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. From f79e0d0cb1c5db336c43438567a3ca16efd444ff Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 13 Feb 2018 05:53:35 -0800 Subject: [PATCH 0080/1812] created compiletest.md describe the steps required to add a test and a header command to compiletest --- src/compiletest.md | 183 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 183 insertions(+) create mode 100644 src/compiletest.md diff --git a/src/compiletest.md b/src/compiletest.md new file mode 100644 index 000000000..a8942efba --- /dev/null +++ b/src/compiletest.md @@ -0,0 +1,183 @@ +# `compiletest` +## Introduction +`compiletest` is the main test harness of the Rust test suite. It allows test authors to organize large numbers of tests (the +Rust compiler has many thousands), efficient test execution (parallel execution is supported), and allows the test author to +configure behavior and expected results of both individual and groups of tests. + +`compiletest` tests may check test code for success, for failure or in some cases, even failure to compile. Tests are +typically organized as a Rust source file with annotations in comments before and/or within the test code, which serve to +direct `compiletest` on if or how to run the test, what behavior to expect, and more. + +The tests themselves are typically (but not always) organized into "suites"--for example, `run-pass`, a folder +representing tests that should succeed, `run-fail`, a folder holding tests that should compile successfully, but return +a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various +suites are defined in `src/tools/compiletest/src/common.rs` in the `pub struct Config` declaration. And a very good +introduction to the different suites of compiler tests along with details about them can be found +[here, at Brian Anderson's blog](https://brson.github.io/2017/07/10/how-rust-is-tested#s-ct). + +## Adding a new test file +Simply create your new test in the appropriate location under `/src/test`. No registration of test files is necessary as +`compiletest` will scan the `src/test` subfolder recursively, and will execute any Rust source files it finds as tests. + +## Header Commands +Source file annotations which appear in comments near the top of the source file *before* any test code are known as header +commands. These commands can instruct `compiletest` to ignore this test, set expectations on whether it is expected to +succeed at compiling, or what the test's return code is expected to be. Header commands (and their inline counterparts, +Error Info commands) are described more fully +[here](https://github.com/rust-lang/rust/blob/master/src/test/COMPILER_TESTS.md). + +### Adding a new header command +Header commands are defined in `src/tools/compiletest/src/header.rs`. At a high level, dozens of test properties are defined +in the `TestProps` struct. These are all set to default values in the struct's `impl` block and any test can override this +default value by specifying the property as header command as a comment (`//`) in the test source file, before any source +code. + +#### Using a header command +Here is an example, specifying the `must-compile-successfully` header command, which takes no arguments, followed by the +`failure-status` header command, which takes a single argument (which, in this case is a value of 1). `failure-status` is +instructing `compiletest` to expect a failure status of 1 (rather than the current Rust default of 101 at the time of this +writing). The header command and the argument list (if present) are typically separated by a colon: +``` +// Copyright 2018 The Rust Project Developers. See the COPYRIGHT +// file at the top-level directory of this distribution and at +// http://rust-lang.org/COPYRIGHT. +// +// Licensed under the Apache License, Version 2.0 or the MIT license +// , at your +// option. This file may not be copied, modified, or distributed +// except according to those terms. + +// must-compile-successfully +// failure-status: 1 + +#![feature(termination_trait)] + +use std::io::{Error, ErrorKind}; + +fn main() -> Result<(), Box> { + Err(Box::new(Error::new(ErrorKind::Other, "returned Box from main()"))) +} +``` + +#### Adding a new header command property +One would add a new header command if there is a need to define some test property or behavior on an individual, test-by-test +basis. A header command property serves as the header command's backing store (holds the command's current value) at +runtime. + +To add a new header command property: + 1. Look for the `pub struct TestProps` declaration in `src/tools/compiletest/src/header.rs` and add +the new public property to the end of the declaration. + 2. Look for the `impl TestProps` implementation block immediately following the struct declaration and initialize the new +property to its default value. + +#### Adding a new header command parser +When `compiletest` encounters a test file, it parses the file a line at a time by calling every parsers defined in the +`Config` struct's implementation block, also in `src/tools/compiletest/src/header.rs` (note the `Config` struct's declaration +block is found in `src/tools/compiletest/src/common.rs`). `TestProps`'s `load_from()` method will try passing the current +line of text to each parser, which, in turn typically checks to see if the line begins with a particular commented (`//`) +header command such as `// must-compile-successfully` or `// failure-status`. Whitespace after the comment marker is +optional. + +Parsers will override a given header command property's default value merely by being specified in the test file as a header +command or by having a parameter value specified in the test file, depending on the header command. + +Parsers defined in `impl Config` are typically named `parse_` (note kebab-case `` transformed +to snake-case ``). `impl Config` also defines several 'low-level' parsers which make it simple to parse +common patterns like simple presence or not (`parse_name_directive()`), header-command:parameter(s) +(`parse_name_value_directive()`), optional parsing only if a particular `cfg` attribute is defined (`has_cfg_prefix()`) and +many more. The low-level parsers are found near the end of the `impl Config` block--be sure to look through them and their +associated parsers immediately above to see how they are used to avoid writing additional parsing code unneccessarily. + +As a concrete example, here is the implementation for the `parse_failure_status()` parser, in +`src/tools/compiletest/src/header.rs`: +```diff +@@ -232,6 +232,7 @@ pub struct TestProps { + // customized normalization rules + pub normalize_stdout: Vec<(String, String)>, + pub normalize_stderr: Vec<(String, String)>, ++ pub failure_status: i32, + } + + impl TestProps { +@@ -260,6 +261,7 @@ impl TestProps { + run_pass: false, + normalize_stdout: vec![], + normalize_stderr: vec![], ++ failure_status: 101, + } + } + +@@ -383,6 +385,10 @@ impl TestProps { + if let Some(rule) = config.parse_custom_normalization(ln, "normalize-stderr") { + self.normalize_stderr.push(rule); + } ++ ++ if let Some(code) = config.parse_failure_status(ln) { ++ self.failure_status = code; ++ } + }); + + for key in &["RUST_TEST_NOCAPTURE", "RUST_TEST_THREADS"] { +@@ -488,6 +494,13 @@ impl Config { + self.parse_name_directive(line, "pretty-compare-only") + } + ++ fn parse_failure_status(&self, line: &str) -> Option { ++ match self.parse_name_value_directive(line, "failure-status") { ++ Some(code) => code.trim().parse::().ok(), ++ _ => None, ++ } ++ } +``` + +## Implementing the behavior change +When a test invokes a particular header command, it is expected that some behavior will change as a result. What behavior, +obviously, will depend on the purpose of the header command. In the case of `failure-status`, the behavior that changes +is that `compiletest` expects the failure code defined by the header command invoked in the test, rather than the default +value. + +Although specific to `failure-status` (as every header ommand will have a different implementation in order to invoke +behavior change) perhaps it is helpful to see the behavior hange implementation of one case, simply as an example. To +implement `failure-status`, the `check_correct_failure_status()` function found in the `TestCx` implementation block, located +in `src/tools/compiletest/src/runtest.rs`, was modified as per below: +```diff +@@ -295,11 +295,14 @@ impl<'test> TestCx<'test> { + } + + fn check_correct_failure_status(&self, proc_res: &ProcRes) { +- // The value the rust runtime returns on failure +- const RUST_ERR: i32 = 101; +- if proc_res.status.code() != Some(RUST_ERR) { ++ let expected_status = Some(self.props.failure_status); ++ let received_status = proc_res.status.code(); ++ ++ if expected_status != received_status { + self.fatal_proc_rec( +- &format!("failure produced the wrong error: {}", proc_res.status), ++ &format!("Error: expected failure status ({:?}) but received status {:?}.", ++ expected_status, ++ received_status), + proc_res, + ); + } +@@ -320,7 +323,6 @@ impl<'test> TestCx<'test> { + ); + + let proc_res = self.exec_compiled_test(); +- + if !proc_res.status.success() { + self.fatal_proc_rec("test run failed!", &proc_res); + } +@@ -499,7 +501,6 @@ impl<'test> TestCx<'test> { + expected, + actual + ); +- panic!(); + } + } +``` +Note the use of `self.props.failure_status` to access the header command property. In tests which do not specify the failure +status header command, `self.props.failure_status` will evaluate to the default value of 101 at the time of this writing. +But for a test which specifies a header command of, for example, `// failure-status: 1`, `self.props.failure_status` will +evaluate to 1, as `parse_failure_status()` will have overridden the `TestProps` default value, for that test specifically. From 59485d219af70485f6e9ec406fc68c963e9831b8 Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 13 Feb 2018 09:22:33 -0800 Subject: [PATCH 0081/1812] Update compiletest.md changed file references to GitHub links directly to files --- src/compiletest.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index a8942efba..aa4558514 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -11,13 +11,13 @@ direct `compiletest` on if or how to run the test, what behavior to expect, and The tests themselves are typically (but not always) organized into "suites"--for example, `run-pass`, a folder representing tests that should succeed, `run-fail`, a folder holding tests that should compile successfully, but return a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various -suites are defined in `src/tools/compiletest/src/common.rs` in the `pub struct Config` declaration. And a very good +suites are defined in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs) in the `pub struct Config` declaration. And a very good introduction to the different suites of compiler tests along with details about them can be found [here, at Brian Anderson's blog](https://brson.github.io/2017/07/10/how-rust-is-tested#s-ct). ## Adding a new test file -Simply create your new test in the appropriate location under `/src/test`. No registration of test files is necessary as -`compiletest` will scan the `src/test` subfolder recursively, and will execute any Rust source files it finds as tests. +Simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test). No registration of test files is necessary as +`compiletest` will scan the [src/test](https://github.com/rust-lang/rust/tree/master/src/test) subfolder recursively, and will execute any Rust source files it finds as tests. ## Header Commands Source file annotations which appear in comments near the top of the source file *before* any test code are known as header @@ -27,7 +27,7 @@ Error Info commands) are described more fully [here](https://github.com/rust-lang/rust/blob/master/src/test/COMPILER_TESTS.md). ### Adding a new header command -Header commands are defined in `src/tools/compiletest/src/header.rs`. At a high level, dozens of test properties are defined +Header commands are defined in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs). At a high level, dozens of test properties are defined in the `TestProps` struct. These are all set to default values in the struct's `impl` block and any test can override this default value by specifying the property as header command as a comment (`//`) in the test source file, before any source code. @@ -66,15 +66,15 @@ basis. A header command property serves as the header command's backing store ( runtime. To add a new header command property: - 1. Look for the `pub struct TestProps` declaration in `src/tools/compiletest/src/header.rs` and add + 1. Look for the `pub struct TestProps` declaration in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs) and add the new public property to the end of the declaration. 2. Look for the `impl TestProps` implementation block immediately following the struct declaration and initialize the new property to its default value. #### Adding a new header command parser When `compiletest` encounters a test file, it parses the file a line at a time by calling every parsers defined in the -`Config` struct's implementation block, also in `src/tools/compiletest/src/header.rs` (note the `Config` struct's declaration -block is found in `src/tools/compiletest/src/common.rs`). `TestProps`'s `load_from()` method will try passing the current +`Config` struct's implementation block, also in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs) (note the `Config` struct's declaration +block is found in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs). `TestProps`'s `load_from()` method will try passing the current line of text to each parser, which, in turn typically checks to see if the line begins with a particular commented (`//`) header command such as `// must-compile-successfully` or `// failure-status`. Whitespace after the comment marker is optional. @@ -90,7 +90,7 @@ many more. The low-level parsers are found near the end of the `impl Config` bl associated parsers immediately above to see how they are used to avoid writing additional parsing code unneccessarily. As a concrete example, here is the implementation for the `parse_failure_status()` parser, in -`src/tools/compiletest/src/header.rs`: +[src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs): ```diff @@ -232,6 +232,7 @@ pub struct TestProps { // customized normalization rules @@ -140,7 +140,7 @@ value. Although specific to `failure-status` (as every header ommand will have a different implementation in order to invoke behavior change) perhaps it is helpful to see the behavior hange implementation of one case, simply as an example. To implement `failure-status`, the `check_correct_failure_status()` function found in the `TestCx` implementation block, located -in `src/tools/compiletest/src/runtest.rs`, was modified as per below: +in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs), was modified as per below: ```diff @@ -295,11 +295,14 @@ impl<'test> TestCx<'test> { } From 5723bce6f1e531a922878ad3b847a5c478b7110b Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 13 Feb 2018 09:45:26 -0800 Subject: [PATCH 0082/1812] fixed typos --- src/compiletest.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index aa4558514..0b10cfbb7 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -72,7 +72,7 @@ the new public property to the end of the declaration. property to its default value. #### Adding a new header command parser -When `compiletest` encounters a test file, it parses the file a line at a time by calling every parsers defined in the +When `compiletest` encounters a test file, it parses the file a line at a time by calling every parser defined in the `Config` struct's implementation block, also in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs) (note the `Config` struct's declaration block is found in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs). `TestProps`'s `load_from()` method will try passing the current line of text to each parser, which, in turn typically checks to see if the line begins with a particular commented (`//`) @@ -86,7 +86,7 @@ Parsers defined in `impl Config` are typically named `parse_` (n to snake-case ``). `impl Config` also defines several 'low-level' parsers which make it simple to parse common patterns like simple presence or not (`parse_name_directive()`), header-command:parameter(s) (`parse_name_value_directive()`), optional parsing only if a particular `cfg` attribute is defined (`has_cfg_prefix()`) and -many more. The low-level parsers are found near the end of the `impl Config` block--be sure to look through them and their +many more. The low-level parsers are found near the end of the `impl Config` block; be sure to look through them and their associated parsers immediately above to see how they are used to avoid writing additional parsing code unneccessarily. As a concrete example, here is the implementation for the `parse_failure_status()` parser, in @@ -137,10 +137,9 @@ obviously, will depend on the purpose of the header command. In the case of `fa is that `compiletest` expects the failure code defined by the header command invoked in the test, rather than the default value. -Although specific to `failure-status` (as every header ommand will have a different implementation in order to invoke -behavior change) perhaps it is helpful to see the behavior hange implementation of one case, simply as an example. To -implement `failure-status`, the `check_correct_failure_status()` function found in the `TestCx` implementation block, located -in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs), was modified as per below: +Although specific to `failure-status` (as every header command will have a different implementation in order to invoke +behavior change) perhaps it is helpful to see the behavior hange implementation of one case, simply as an example. To implement `failure-status`, the `check_correct_failure_status()` function found in the `TestCx` implementation block, +located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs), was modified as per below: ```diff @@ -295,11 +295,14 @@ impl<'test> TestCx<'test> { } From fc83b6fe198525d7680d4b416afb555501c9edd9 Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 13 Feb 2018 09:53:45 -0800 Subject: [PATCH 0083/1812] Added 'How to add header commands to `compiletest`' --- src/SUMMARY.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a2f40ed35..6a3907551 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -3,6 +3,7 @@ - [About this guide](./about-this-guide.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) - [Using the compiler testing framework](./running-tests.md) +- [How to add new header commands to `compiletest`](./compiletest.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [High-level overview of the compiler source](./high-level-overview.md) - [Queries: demand-driven compilation](./query.md) From 6ae355c18ddebde72f139607363cec968c4e33fb Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 13 Feb 2018 11:00:42 -0600 Subject: [PATCH 0084/1812] add soundness and completeness to glossary --- src/glossary.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/glossary.md b/src/glossary.md index b7282c3eb..cb3437f1d 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -7,6 +7,7 @@ Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. +completeness | soundness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. @@ -25,6 +26,7 @@ provider | the function that executes a query ([see more](query. query | perhaps some sub-computation during compilation ([see more](query.html)) sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. +soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) tcx | the "typing context", main data structure of the compiler ([see more](ty.html)) From 4357cf5c8ee1aa3bea59a57ef6819dc1ca4fbfe6 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 13 Feb 2018 11:20:19 -0600 Subject: [PATCH 0085/1812] Update glossary.md --- src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glossary.md b/src/glossary.md index cb3437f1d..a22c49632 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -7,7 +7,7 @@ Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. -completeness | soundness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). +completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. From 169cdeb78ffc5a22f0dc22454dc036493e93bce7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 15 Feb 2018 12:53:49 -0600 Subject: [PATCH 0086/1812] Add a few more terms to the glossary --- src/glossary.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/glossary.md b/src/glossary.md index a22c49632..f252e6956 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -24,13 +24,16 @@ node-id or NodeId | an index identifying a particular node in the AST or obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) provider | the function that executes a query ([see more](query.html)) query | perhaps some sub-computation during compilation ([see more](query.html)) +region | another term for "lifetime" often used in the literature and in the borrow checker. sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. +sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) tcx | the "typing context", main data structure of the compiler ([see more](ty.html)) 'tcx | the lifetime of the currently active inference context ([see more](ty.html)) +token | the smallest unit of parsing. Tokens are produced after lexing ([see more](the-parser.html)). trans | the code to translate MIR into LLVM IR. trait reference | a trait and values for its type parameters ([see more](ty.html)). ty | the internal representation of a type ([see more](ty.html)). From 58b67c21d6139034477ad6f00ba5f533d88316ee Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 7 Feb 2018 09:47:02 -0500 Subject: [PATCH 0087/1812] document the test infrastructure --- src/SUMMARY.md | 4 +- src/running-tests.md | 1 - src/tests/adding.md | 273 +++++++++++++++++++++++++++++++++++++++++++ src/tests/intro.md | 48 ++++++++ src/tests/running.md | 65 +++++++++++ 5 files changed, 389 insertions(+), 2 deletions(-) delete mode 100644 src/running-tests.md create mode 100644 src/tests/adding.md create mode 100644 src/tests/intro.md create mode 100644 src/tests/running.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a2f40ed35..21976fbf7 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -2,7 +2,9 @@ - [About this guide](./about-this-guide.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) -- [Using the compiler testing framework](./running-tests.md) +- [The compiler testing framework](./tests/intro.md) + - [Running tests](./tests/running.md) + - [Adding new tests](./tests/adding.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [High-level overview of the compiler source](./high-level-overview.md) - [Queries: demand-driven compilation](./query.md) diff --git a/src/running-tests.md b/src/running-tests.md deleted file mode 100644 index 02c9de840..000000000 --- a/src/running-tests.md +++ /dev/null @@ -1 +0,0 @@ -# Using the compiler testing framework diff --git a/src/tests/adding.md b/src/tests/adding.md new file mode 100644 index 000000000..9ce8318db --- /dev/null +++ b/src/tests/adding.md @@ -0,0 +1,273 @@ +# Adding new tests + +**In general, we expect every PR that fixes a bug in rustc to come +accompanied with a regression test of some kind.** This test should +fail in master but pass after the PR. These tests are really useful +for preventing us from repeating the mistakes of the past. + +To add a new test, the first thing you generally do is to create a +file, typically a Rust source file. Test files have a particular +structure: + +- They always begin with the copyright notice; +- then they should have some kind of + [comment explaining what the test is about](#explanatory_comment); +- next, they can have one or more [header commands](#header_commands), which are special + comments that the test interpreter knows how to interpret. +- finally, they have the Rust source. This may have various [error + annotations](#error_annotations) which indicate expected compilation errors or + warnings. + +Depending on the test suite, there may be some other details to be aware of: + - For [the `ui` test suite](#ui), you need to generate reference output files. + +## Naming your test + +We have not traditionally had a lot of structure in the names of +tests. Moreover, for a long time, the rustc test runner did not +support subdirectories (it now does), so test suites like +`src/test/run-pass` have a huge mess of files in them. This is not +considered an ideal setup. + +For regression tests -- basically, some random snippet of code that +came in from the internet -- we often just name the test after the +issue. For example, `src/test/run-pass/issue-1234.rs`. If possible, +though, it is better if you can put the test into a directory that +helps identify what piece of code is being tested here (e.g., +`borrowck/issue-12345.rs` is much better), or perhaps give it a more +meaningful name. Still, **do include the issue number somewhere**. + +When writing a new feature, **create a subdirectory to store your +tests**. For example, if you are implementing RFC 1234 ("Widgets"), +then it might make sense to put the tests in directories like: + +- `src/test/ui/rfc1234-widgets/` +- `src/test/run-pass/rfc1234-widgets/` +- etc + +In other cases, there may already be a suitable directory. (The proper +directory structure to use is actually an area of active debate.) + + + +## Comment explaining what the test is about + +When you create a test file, **include a comment summarizing the point +of the test immediately after the copyright notice**. This should +highlight which parts of the test are more important, and what the bug +was that the test is fixing. Citing an issue number is often very +helpful. + +This comment doesn't have to be super extensive. Just something like +"Regression test for #18060: match arms were matching in the wrong +order." might already be enough. + +These comments are very useful to others later on when your test +breaks, since they often can highlight what the problem is. They are +also useful if for some reason the tests need to be refactored, since +they let others know which parts of the test were important (often a +test must be rewritten because it no longer tests what is was meant to +test, and then it's useful to know what it *was* meant to test +exactly). + + + +## Header commands: configuring rustc + +Header commands are special comments that the test runner knows how to +interpret. They must appear before the Rust source in the test. They +are normally put after the short comment that explains the point of +this test. For example, this test uses the `// compile-flags` command +to specify a custom flag to give to rustc when the test is compiled: + +```rust +// Copyright 2017 The Rust Project Developers. blah blah blah. +// ... +// except according to those terms. + +// Test the behavior of `0 - 1` when overflow checks are disabled. + +// compile-flags: -Coverflow-checks=off + +fn main() { + let x = 0 - 1; + ... +} +``` + +### Ignoring tests + +These are used to ignore the test in some situations, which means the test won't +be compiled or run. + +* `ignore-X` where `X` is a target detail or stage will ignore the test accordingly (see below) +* `ignore-pretty` will not compile the pretty-printed test (this is done to test the pretty-printer, but might not always work) +* `ignore-test` always ignores the test +* `ignore-lldb` and `ignore-gdb` will skip a debuginfo test on that debugger. + +Some examples of `X` in `ignore-X`: + +* Architecture: `aarch64`, `arm`, `asmjs`, `mips`, `wasm32`, `x86_64`, `x86`, ... +* OS: `android`, `emscripten`, `freebsd`, `ios`, `linux`, `macos`, `windows`, ... +* Environment (fourth word of the target triple): `gnu`, `msvc`, `musl`. +* Pointer width: `32bit`, `64bit`. +* Stage: `stage0`, `stage1`, `stage2`. + +### Other Header Commands + +Here is a list of other header commands. This list is not +exhaustive. Header commands can generally be found by browsing the +`TestProps` structure found in [`header.rs`] from the compiletest +source. + +* `min-{gdb,lldb}-version` +* `min-llvm-version` +* `must-compile-successfully` for UI tests, indicates that the test is supposed + to compile, as opposed to the default where the test is supposed to error out. +* `compile-flags` passes extra command-line args to the compiler, + e.g. `compile-flags -g` which forces debuginfo to be enabled. +* `should-fail` indicates that the test should fail; used for "meta testing", + where we test the compiletest program itself to check that it will generate + errors in appropriate scenarios. This header is ignored for pretty-printer tests. +* `gate-test-X` where `X` is a feature marks the test as "gate test" for feature X. + Such tests are supposed to ensure that the compiler errors when usage of a gated + feature is attempted without the proper `#![feature(X)]` tag. + Each unstable lang feature is required to have a gate test. + +[`header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs + + + +## Error annotations + +Error annotations specify the errors that the compiler is expected to +emit. They are "attached" to the line in source where the error is +located. + +* `~`: Associates the following error level and message with the + current line +* `~|`: Associates the following error level and message with the same + line as the previous comment +* `~^`: Associates the following error level and message with the + previous line. Each caret (`^`) that you add adds a line to this, so + `~^^^^^^^` is seven lines up. + +The error levels that you can have are: + +1. `ERROR` +2. `WARNING` +3. `NOTE` +4. `HELP` and `SUGGESTION`* + +\* **Note**: `SUGGESTION` must follow immediately after `HELP`. + +## Revisions + +Certain classes of tests support "revisions" (as of the time of this +writing, this includes run-pass, compile-fail, run-fail, and +incremental, though incremental tests are somewhat +different). Revisions allow a single test file to be used for multiple +tests. This is done by adding a special header at the top of the file: + +``` +// revisions: foo bar baz +``` + +This will result in the test being compiled (and tested) three times, +once with `--cfg foo`, once with `--cfg bar`, and once with `--cfg +baz`. You can therefore use `#[cfg(foo)]` etc within the test to tweak +each of these results. + +You can also customize headers and expected error messages to a particular +revision. To do this, add `[foo]` (or `bar`, `baz`, etc) after the `//` +comment, like so: + +``` +// A flag to pass in only for cfg `foo`: +//[foo]compile-flags: -Z verbose + +#[cfg(foo)] +fn test_foo() { + let x: usize = 32_u32; //[foo]~ ERROR mismatched types +} +``` + +Note that not all headers have meaning when customized to a revision. +For example, the `ignore-test` header (and all "ignore" headers) +currently only apply to the test as a whole, not to particular +revisions. The only headers that are intended to really work when +customized to a revision are error patterns and compiler flags. + + + +## Guide to the UI tests + +The UI tests are intended to capture the compiler's complete output, +so that we can test all aspects of the presentation. They work by +compiling a file (e.g., `ui/hello_world/main.rs`), capturing the output, +and then applying some normalization (see below). This normalized +result is then compared against reference files named +`ui/hello_world/main.stderr` and `ui/hello_world/main.stdout`. If either of +those files doesn't exist, the output must be empty. If the test run +fails, we will print out the current output, but it is also saved in +`build//test/ui/hello_world/main.stdout` (this path is +printed as part of the test failure message), so you can run `diff` and +so forth. + +Normally, the test-runner checks that UI tests fail compilation. If you want +to do a UI test for code that *compiles* (e.g. to test warnings, or if you +have a collection of tests, only some of which error out), you can use the +`// must-compile-successfully` header command to have the test runner instead +check that the test compiles successfully. + +### Editing and updating the reference files + +If you have changed the compiler's output intentionally, or you are +making a new test, you can use the script `ui/update-references.sh` to +update the references. When you run the test framework, it will report +various errors: in those errors is a command you can use to run the +`ui/update-references.sh` script, which will then copy over the files +from the build directory and use them as the new reference. You can +also just run `ui/update-all-references.sh`. In both cases, you can run +the script with `--help` to get a help message. + +### Normalization + +The normalization applied is aimed at eliminating output difference +between platforms, mainly about filenames: + +- the test directory is replaced with `$DIR` +- all backslashes (`\`) are converted to forward slashes (`/`) (for Windows) +- all CR LF newlines are converted to LF + +Sometimes these built-in normalizations are not enough. In such cases, you +may provide custom normalization rules using the header commands, e.g. + +``` +// normalize-stdout-test: "foo" -> "bar" +// normalize-stderr-32bit: "fn\(\) \(32 bits\)" -> "fn\(\) \($$PTR bits\)" +// normalize-stderr-64bit: "fn\(\) \(64 bits\)" -> "fn\(\) \($$PTR bits\)" +``` + +This tells the test, on 32-bit platforms, whenever the compiler writes +`fn() (32 bits)` to stderr, it should be normalized to read `fn() ($PTR bits)` +instead. Similar for 64-bit. The replacement is performed by regexes using +default regex flavor provided by `regex` crate. + +The corresponding reference file will use the normalized output to test both +32-bit and 64-bit platforms: + +``` +... + | + = note: source type: fn() ($PTR bits) + = note: target type: u16 (16 bits) +... +``` + +Please see `ui/transmute/main.rs` and `.stderr` for a concrete usage example. + +Besides `normalize-stderr-32bit` and `-64bit`, one may use any target +information or stage supported by `ignore-X` here as well (e.g. +`normalize-stderr-windows` or simply `normalize-stderr-test` for unconditional +replacement). diff --git a/src/tests/intro.md b/src/tests/intro.md new file mode 100644 index 000000000..c22916dca --- /dev/null +++ b/src/tests/intro.md @@ -0,0 +1,48 @@ +# Using the compiler testing framework + +The compiler has an extensive testing framework, masterminded by the +compiletest tool (sources in the [`src/tools/compiletest`]). This +section gives a brief overview of how the testing framework is setup, +and then gets into some of the details on +[how to run tests](running.html) as well as +[how to add new tests](adding.html). + +[`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest + +## Test suites + +The tests are located in the tree in the [`src/test`] +directory. Immediately within you will see a series of subdirectories +(e.g. `ui`, `run-make`, and so forth). Each of those directories is +called a **test suite** -- they house a group of tests that are run in +a distinct mode. + +[`src/test`]: https://github.com/rust-lang/rust/tree/master/src/test + +Here is a brief summary of the test suites as of this writing and what +they mean. In some cases, the test suites are linked to parts of the manual +that give more details. + +- [`ui`](ui.html) -- tests that check the exact stdout/stderr from compilation + and/or running the test +- `run-pass` -- tests that are expected to compile and execute successfully (no panics) + - `run-pass-valgrind` -- tests that ought to run with valrind +- `run-fail` -- tests that are expected to compile but then panic during execution +- `compile-fail` -- tests that are expected to fail compilation. +- `parse-fail` -- tests that are expected to fail to parse +- `pretty` -- tests targeting the Rust "pretty printer", which + generates valid Rust code from the AST +- `debuginfo` -- tests that run in gdb or lldb and query the debug info +- `codegen` -- tests that compile and then test the generated LLVM + code to make sure that optimizing we want are kicking in etc +- `mir-opt` -- tests that check parts of the generated MIR to make sure we are optimizing + etc. +- `incremental` -- tests for incremental compilation, checking that + when certain modifications are performed, we are able to reuse the + results from previous compilations. +- `run-make` -- tests that basically just execute a `Makefile`; the ultimate in flexibility + but annoying as all get out to write. +- `rustdoc` -- tests for rustdoc, making sure that the generated files contain + documentation for various entities etc +- `*-fulldeps` -- same as above, but indicates that the test depends on things other + than `libstd` (and hence those things must be built) diff --git a/src/tests/running.md b/src/tests/running.md new file mode 100644 index 000000000..8813862d8 --- /dev/null +++ b/src/tests/running.md @@ -0,0 +1,65 @@ +# Running tests + +You can run the tests using `x.py`. The most basic command -- which +you will almost never want to use! -- is as follows: + +``` +./x.py test +``` + +This will build the full stage 2 compiler and then run the whole test +suite. You probably don't want to do this very often, because it takes +a very long time, and anyway bors / travis will do it for you. (Often, +I will run this command in the background after opening a PR that I +think is done, but rarely otherwise. -nmatsakis) + +## Running a subset of the test suites + +When working on a specific PR, you will usually want to run a smaller +set of tests, and with a stage 1 build. For example, a good "smoke +test" that can be used after modifying rustc to see if things are +generally working correctly would be the following: + +```bash +./x.py test --stage 1 src/test/{ui,compile-fail,run-pass} +``` + +This will run the `ui`, `compile-fail`, and `run-pass` test suites, and +only with the stage 1 build. Of course, the choice of test suites is somewhat +arbitrary, and may not suit the task you are doing. For example, if you are hacking +on debuginfo, you may be better off with the debuginfo test suite: + +```bash +./x.py test --stage 1 src/test/debuginfo +``` + +**Warning:** Note that bors only runs the tests with the full stage 2 +build; therefore, while the tests **usually** work fine with stage 1, +there are some limitations. In particular, `./x.py test --stage 1` +(ie., + +## Running an individual test + +Another common thing that people want to do is to run an **individual +test**, often the test they are trying to fix. One way to do this is +to invoke `x.py` with the `--test-args` option: + +``` +./x.py test --stage 1 src/test/ui --test-args issue-1234 +``` + +Under the hood, the test runner invokes the standard rust test runner +(the same one you get with `#[test]`), so this command would wind up +filtering for tests that include "issue-1234" in the name. + +Often, though, it's easier to just run the test by hand. More tests are +just `rs` files, so you can do something like + +``` +rustc +stage1 src/test/ui/issue-1234.rs +``` + +This is much faster, but doesn't always work. For example, some tests +include directives that specify specific compiler flags, or which rely +on other crates, and they may not run the same without those options. + From 8c657b1f88ffbeacdc537debb3ef01186df74049 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 09:41:13 -0500 Subject: [PATCH 0088/1812] add some notes on coding conventions and link to copyright notice --- src/SUMMARY.md | 1 + src/conventions.md | 63 +++++++++++++++++++++++++++++++++++++++++++++ src/tests/adding.md | 2 +- 3 files changed, 65 insertions(+), 1 deletion(-) create mode 100644 src/conventions.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 21976fbf7..981eb22c9 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -2,6 +2,7 @@ - [About this guide](./about-this-guide.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) +- [Coding conventions](./conventions.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) - [Adding new tests](./tests/adding.md) diff --git a/src/conventions.md b/src/conventions.md new file mode 100644 index 000000000..14ef7119a --- /dev/null +++ b/src/conventions.md @@ -0,0 +1,63 @@ +rustc is slowly moving towards the [Rust standard coding style][fmt]; +at the moment, however, it follows a rather more *chaotic* +style. There are a few things that are always true. + +[fmt]: https://github.com/rust-lang-nursery/fmt-rfcs + +# The tidy script + +Running `./x.py test` begins with a "tidy" step. This tidy step checks +that your source files meet some basic conventions. + + + +## Copyright notice + +All files must begin with the following copyright notice: + +``` +// Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT +// file at the top-level directory of this distribution and at +// http://rust-lang.org/COPYRIGHT. +// +// Licensed under the Apache License, Version 2.0 or the MIT license +// , at your +// option. This file may not be copied, modified, or distributed +// except according to those terms. +``` + +The year at the top is not meaningful: copyright protections are in +fact automatic from the moment of authorship. We do not typically edit +the years on existing files. When creating a new file, you can use the +current year if you like, but you don't have to. + +## Line length + +Lines should be at most 100 characters. It's even better if you can +keep things to 80. + +**Ignoring the line length limit.** Sometimes -- in particular for +tests -- it can be necessary to exempt yourself from this limit. In +that case, you can add a comment towards the top of the file (after +the copyright notice) like so: + +``` +// ignore-tidy-linelength +``` + +## Tabs vs spaces + +Prefer 4-space indent. + +# Warnings and lints + +In general, Rust crates + +# Policy on using crates from crates.io + +It is allowed to use crates from crates.io, though external +dependencies should not be added gratuitously. All such crates must +have a suitably permissive license. There is an automatic check which +inspects the Cargo metadata to ensure this. + diff --git a/src/tests/adding.md b/src/tests/adding.md index 9ce8318db..ae247010d 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -9,7 +9,7 @@ To add a new test, the first thing you generally do is to create a file, typically a Rust source file. Test files have a particular structure: -- They always begin with the copyright notice; +- They always begin with the [copyright notice](../conventions.html#copyright); - then they should have some kind of [comment explaining what the test is about](#explanatory_comment); - next, they can have one or more [header commands](#header_commands), which are special From 14f74dff9154b6b64b0581283b0b4e0ac94860fc Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 09:59:50 -0500 Subject: [PATCH 0089/1812] add some more conventions --- src/conventions.md | 106 ++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 95 insertions(+), 11 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index 14ef7119a..93a07ad43 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -1,17 +1,24 @@ -rustc is slowly moving towards the [Rust standard coding style][fmt]; -at the moment, however, it follows a rather more *chaotic* -style. There are a few things that are always true. +This file offers some tips on the coding conventions for rustc. This +chapter covers [formatting](#f), [coding for correctness](#cc), +[using crates from crates.io](#cio), and some tips on +[structuring your PR for easy review](#er). -[fmt]: https://github.com/rust-lang-nursery/fmt-rfcs + -# The tidy script +# Formatting and the tidy script -Running `./x.py test` begins with a "tidy" step. This tidy step checks -that your source files meet some basic conventions. +rustc is slowly moving towards the [Rust standard coding style][fmt]; +at the moment, however, it follows a rather more *chaotic* style. We +do have some mandatory formatting conventions, which are automatically +enforced by a script we affectionately[^not_true] call the "tidy" +script. The tidy script runs automatically when you do `./x.py test`. + +[^not_true]: Secretly, I hate tidy. -nmatsakis +[fmt]: https://github.com/rust-lang-nursery/fmt-rfcs -## Copyright notice +### Copyright notice All files must begin with the following copyright notice: @@ -50,14 +57,91 @@ the copyright notice) like so: Prefer 4-space indent. -# Warnings and lints + + +# Coding for correctness + +Beyond formatting, there are a few other tips that are worth +following. + +## Prefer exhaustive matches + +Using `_` in a match is convenient, but it means that when new +variants are added to the enum, they may not get handled correctly. +Ask yourself: if a new variant were added to this enum, what's the +chance that it would want to use the `_` code, versus having some +other treatment? Unless the answer is "low", then prefer an +exhaustive match. (The same advice applies to `if let` and `while +let`, which are effectively tests for a single variant.) -In general, Rust crates +## Use "TODO" comments for things you don't want to forget -# Policy on using crates from crates.io +As a useful tool to yourself, you can insert a `// TODO` comment +for something that you want to get back to before you land your PR: + +```rust,ignore +fn do_something() { + if something_else { + unimplemented!(): // TODO write this + } +} +``` + +The tidy script will report an error for a `// TODO` comment, so this +code would not be able to land until the TODO is fixed (or removed). + +This can also be useful in a PR as a way to signal from one commit that you are +leaving a bug that a later commit will fix: + +```rust,ignore +if foo { + return true; // TODO wrong, but will be fixed in a later commit +} +``` + + + +# Using crates from crates.io It is allowed to use crates from crates.io, though external dependencies should not be added gratuitously. All such crates must have a suitably permissive license. There is an automatic check which inspects the Cargo metadata to ensure this. + + +# How to structure your PR + +How you prepare the commits in your PR can make a big difference for the reviewer. +Here are some tips. + +**Isolate "pure refactorings" into their own commit.** For example, if +you rename a method, then put that rename into its own commit, along +with the renames of all the uses. + +**More commits is usually better.** If you are doing a large change, +it's almost always better to break it up into smaller steps that can +be independently understood. The one thing to be aware of is that if +you introduce some code following one strategy, then change it +dramatically (versus adding to it) in a later commit, that +'back-and-forth' can be confusing. + +**If you run rustfmt and the file was not already formatted, isolate +that into its own commit.** This is really the same as the previous +rule, but it's worth highlighting. It's ok to rustfmt files, but since +we do not currently run rustfmt all the time, that can introduce a lot +of noise into your commit. Please isolate that into its own +commit. This also makes rebases a lot less painful, since rustfmt +tends to cause a lot of merge conflicts, and having those isolated +into their own commit makes htem easier to resolve. + +**No merges.** We do not allow merge commits into our history, other +than those by bors. If you get a merge conflict, rebase instead via a +command like `git rebase -i rust-lang/master` (presuming you use the +name `rust-lang` for your remote). + +**Individual commits do not have to build (but it's nice).** We do not +require that every intermediate commit successfully builds -- we only +expect to be able to bisect at a PR level. However, if you *can* make +individual commits build, that is always helpful. + From 346cbab485283a23f3ce3004e2f15d14fd302eaf Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:17:23 -0500 Subject: [PATCH 0090/1812] give some advice about which test suite to use --- src/tests/adding.md | 71 ++++++++++++++++++++++++++++++++------------- src/tests/intro.md | 15 +++++----- 2 files changed, 59 insertions(+), 27 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index ae247010d..c2a5ef43f 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -1,9 +1,9 @@ # Adding new tests **In general, we expect every PR that fixes a bug in rustc to come -accompanied with a regression test of some kind.** This test should -fail in master but pass after the PR. These tests are really useful -for preventing us from repeating the mistakes of the past. +accompanied by a regression test of some kind.** This test should fail +in master but pass after the PR. These tests are really useful for +preventing us from repeating the mistakes of the past. To add a new test, the first thing you generally do is to create a file, typically a Rust source file. Test files have a particular @@ -20,18 +20,36 @@ structure: Depending on the test suite, there may be some other details to be aware of: - For [the `ui` test suite](#ui), you need to generate reference output files. - + +## What kind of test should I add? + +It can be difficult to know what kind of test to use. Here are some +rough heuristics: + +- Some tests have specialized needs: + - need to run gdb or lldb? use the `debuginfo` test suite + - need to inspect LLVM IR or MIR IR? use the `codegen` or `mir-opt` test suites + - need to run rustdoc? Prefer a `rustdoc` test + - need to inspect the resulting binary in some way? Then use `run-make` +- For most other things, [a `ui` (or `ui-fulldeps`) test](#ui) is to be preferred: + - `ui` tests subsume both run-pass, compile-fail, and parse-fail tests + - in the case of warnings or errors, `ui` tests capture the full output, + which makes it easier to review but also helps prevent "hidden" regressions + in the output + ## Naming your test We have not traditionally had a lot of structure in the names of tests. Moreover, for a long time, the rustc test runner did not support subdirectories (it now does), so test suites like -`src/test/run-pass` have a huge mess of files in them. This is not +[`src/test/run-pass`] have a huge mess of files in them. This is not considered an ideal setup. +[`src/test/run-pass`]: https://github.com/rust-lang/rust/tree/master/src/test/run-pass/ + For regression tests -- basically, some random snippet of code that came in from the internet -- we often just name the test after the -issue. For example, `src/test/run-pass/issue-1234.rs`. If possible, +issue. For example, `src/test/run-pass/issue-12345.rs`. If possible, though, it is better if you can put the test into a directory that helps identify what piece of code is being tested here (e.g., `borrowck/issue-12345.rs` is much better), or perhaps give it a more @@ -204,21 +222,31 @@ customized to a revision are error patterns and compiler flags. The UI tests are intended to capture the compiler's complete output, so that we can test all aspects of the presentation. They work by -compiling a file (e.g., `ui/hello_world/main.rs`), capturing the output, -and then applying some normalization (see below). This normalized -result is then compared against reference files named -`ui/hello_world/main.stderr` and `ui/hello_world/main.stdout`. If either of -those files doesn't exist, the output must be empty. If the test run -fails, we will print out the current output, but it is also saved in +compiling a file (e.g., [`ui/hello_world/main.rs`][hw-main]), +capturing the output, and then applying some normalization (see +below). This normalized result is then compared against reference +files named `ui/hello_world/main.stderr` and +`ui/hello_world/main.stdout`. If either of those files doesn't exist, +the output must be empty (that is actually the case for +[this particular test][hw]). If the test run fails, we will print out +the current output, but it is also saved in `build//test/ui/hello_world/main.stdout` (this path is -printed as part of the test failure message), so you can run `diff` and -so forth. +printed as part of the test failure message), so you can run `diff` +and so forth. -Normally, the test-runner checks that UI tests fail compilation. If you want -to do a UI test for code that *compiles* (e.g. to test warnings, or if you -have a collection of tests, only some of which error out), you can use the -`// must-compile-successfully` header command to have the test runner instead -check that the test compiles successfully. +[hw-main]: https://github.com/rust-lang/rust/blob/master/src/test/ui/hello_world/main.rs +[hw]: https://github.com/rust-lang/rust/blob/master/src/test/ui/hello_world/ + +### Tests that do not result in compile errors + +By default, a UI test is expected **not to compile** (in which case, +it should contain at least one `//~ ERROR` annotation). However, you +can also make UI tests where compilation is expected to succeed, and +you can even run the resulting program. Just add one of the following +[header commands](#header_commands): + +- `// must-compile-successfully` -- compilation should succeed but do not run the resulting binary +- `// run-pass` -- compilation should succeed and we should run the resulting binary ### Editing and updating the reference files @@ -265,7 +293,10 @@ The corresponding reference file will use the normalized output to test both ... ``` -Please see `ui/transmute/main.rs` and `.stderr` for a concrete usage example. +Please see [`ui/transmute/main.rs`][mrs] and [`main.stderr`][] for a concrete usage example. + +[mrs]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.rs +[`main.stderr`]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.stderr Besides `normalize-stderr-32bit` and `-64bit`, one may use any target information or stage supported by `ignore-X` here as well (e.g. diff --git a/src/tests/intro.md b/src/tests/intro.md index c22916dca..334042a41 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -23,7 +23,7 @@ Here is a brief summary of the test suites as of this writing and what they mean. In some cases, the test suites are linked to parts of the manual that give more details. -- [`ui`](ui.html) -- tests that check the exact stdout/stderr from compilation +- [`ui`](adding.html#) -- tests that check the exact stdout/stderr from compilation and/or running the test - `run-pass` -- tests that are expected to compile and execute successfully (no panics) - `run-pass-valgrind` -- tests that ought to run with valrind @@ -34,15 +34,16 @@ that give more details. generates valid Rust code from the AST - `debuginfo` -- tests that run in gdb or lldb and query the debug info - `codegen` -- tests that compile and then test the generated LLVM - code to make sure that optimizing we want are kicking in etc -- `mir-opt` -- tests that check parts of the generated MIR to make sure we are optimizing - etc. + code to make sure that the optimizations we want are taking effect. +- `mir-opt` -- tests that check parts of the generated MIR to make + sure we are building things correctly or doing the optimizations we + expect. - `incremental` -- tests for incremental compilation, checking that when certain modifications are performed, we are able to reuse the results from previous compilations. -- `run-make` -- tests that basically just execute a `Makefile`; the ultimate in flexibility - but annoying as all get out to write. +- `run-make` -- tests that basically just execute a `Makefile`; the + ultimate in flexibility but quite annoying to write. - `rustdoc` -- tests for rustdoc, making sure that the generated files contain - documentation for various entities etc + the expected documentation. - `*-fulldeps` -- same as above, but indicates that the test depends on things other than `libstd` (and hence those things must be built) From a8bdd52e56e18d95cb9da083571fa9c4f2bc7ad8 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:18:27 -0500 Subject: [PATCH 0091/1812] complete sentence --- src/tests/running.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index 8813862d8..59a615dab 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -35,8 +35,8 @@ on debuginfo, you may be better off with the debuginfo test suite: **Warning:** Note that bors only runs the tests with the full stage 2 build; therefore, while the tests **usually** work fine with stage 1, -there are some limitations. In particular, `./x.py test --stage 1` -(ie., +there are some limitations. In particular, the stage1 compiler doesn't +work well with procedural macros or custom derive tests. ## Running an individual test From 2e04d6444a6606b46437adeb6dc66cf6f3b61608 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:21:27 -0500 Subject: [PATCH 0092/1812] link to brson's blog post --- src/tests/intro.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/tests/intro.md b/src/tests/intro.md index 334042a41..1e4a2bed3 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -47,3 +47,11 @@ that give more details. the expected documentation. - `*-fulldeps` -- same as above, but indicates that the test depends on things other than `libstd` (and hence those things must be built) + +## Further reading + +The following blog posts may also be of interest: + +- brson's classic ["How Rust is tested"][howtest] + +[howtest]: https://brson.github.io/2017/07/10/how-rust-is-tested From b502a6a3fca9dc8161e858a42d7a2f7fa3af2ef4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:21:32 -0500 Subject: [PATCH 0093/1812] fix typo --- src/tests/running.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/running.md b/src/tests/running.md index 59a615dab..98d590671 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -52,7 +52,7 @@ Under the hood, the test runner invokes the standard rust test runner (the same one you get with `#[test]`), so this command would wind up filtering for tests that include "issue-1234" in the name. -Often, though, it's easier to just run the test by hand. More tests are +Often, though, it's easier to just run the test by hand. Most tests are just `rs` files, so you can do something like ``` From caea7ae5adfa6edf9292505fc0c912265441698d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:27:57 -0500 Subject: [PATCH 0094/1812] mention tidy --- src/conventions.md | 4 ++-- src/tests/running.md | 7 +++++++ 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index 93a07ad43..3ed58bf49 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -1,9 +1,9 @@ This file offers some tips on the coding conventions for rustc. This -chapter covers [formatting](#f), [coding for correctness](#cc), +chapter covers [formatting](#formatting), [coding for correctness](#cc), [using crates from crates.io](#cio), and some tips on [structuring your PR for easy review](#er). - + # Formatting and the tidy script diff --git a/src/tests/running.md b/src/tests/running.md index 98d590671..dc9de0019 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -13,6 +13,13 @@ a very long time, and anyway bors / travis will do it for you. (Often, I will run this command in the background after opening a PR that I think is done, but rarely otherwise. -nmatsakis) +## Tidy + +When you run the full suite of tests via `./x.py test`, the first +thing that executes is a "tidy suite" that checks for long lines and +other formatting conventions. There is more information in the +[section on coding conventions](../conventions.html#formatting). + ## Running a subset of the test suites When working on a specific PR, you will usually want to run a smaller From 7f8364d6f92aacd657867599cab4724c3ef385aa Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:31:48 -0500 Subject: [PATCH 0095/1812] correct links (mdbook seems to want them relative to the book root) --- src/how-to-build-and-run.md | 2 +- src/tests/adding.md | 2 +- src/tests/intro.md | 6 +++--- src/tests/running.md | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 2657da84c..7b6088c7c 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -132,6 +132,6 @@ Here are a few other useful x.py commands. We'll cover some of them in detail in - `./x.py clean` – clean up the build directory (`rm -rf build` works too, but then you have to rebuild LLVM) - `./x.py build --stage 1` – builds everything using the stage 1 compiler, not just up to libstd - `./x.py build` – builds the stage2 compiler -- Running tests (see the section [running tests](./running-tests.html) for more details): +- Running tests (see the [section on running tests](./tests/running.html) for more details): - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd - `./x.py test --stage 1 src/test/run-pass` – runs the `run-pass` test suite diff --git a/src/tests/adding.md b/src/tests/adding.md index c2a5ef43f..276189f59 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -9,7 +9,7 @@ To add a new test, the first thing you generally do is to create a file, typically a Rust source file. Test files have a particular structure: -- They always begin with the [copyright notice](../conventions.html#copyright); +- They always begin with the [copyright notice](./conventions.html#copyright); - then they should have some kind of [comment explaining what the test is about](#explanatory_comment); - next, they can have one or more [header commands](#header_commands), which are special diff --git a/src/tests/intro.md b/src/tests/intro.md index 1e4a2bed3..615673206 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -4,8 +4,8 @@ The compiler has an extensive testing framework, masterminded by the compiletest tool (sources in the [`src/tools/compiletest`]). This section gives a brief overview of how the testing framework is setup, and then gets into some of the details on -[how to run tests](running.html) as well as -[how to add new tests](adding.html). +[how to run tests](./tests/running.html#ui) as well as +[how to add new tests](./tests/adding.html). [`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest @@ -23,7 +23,7 @@ Here is a brief summary of the test suites as of this writing and what they mean. In some cases, the test suites are linked to parts of the manual that give more details. -- [`ui`](adding.html#) -- tests that check the exact stdout/stderr from compilation +- [`ui`](./tests/adding.html#ui) -- tests that check the exact stdout/stderr from compilation and/or running the test - `run-pass` -- tests that are expected to compile and execute successfully (no panics) - `run-pass-valgrind` -- tests that ought to run with valrind diff --git a/src/tests/running.md b/src/tests/running.md index dc9de0019..602aa51d9 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -18,7 +18,7 @@ think is done, but rarely otherwise. -nmatsakis) When you run the full suite of tests via `./x.py test`, the first thing that executes is a "tidy suite" that checks for long lines and other formatting conventions. There is more information in the -[section on coding conventions](../conventions.html#formatting). +[section on coding conventions](./conventions.html#formatting). ## Running a subset of the test suites From c7c80abb0be383c449ab2304613ba1c5f2d50e50 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 17 Feb 2018 10:32:35 -0500 Subject: [PATCH 0096/1812] remove humorous footnote which is not supported --- src/conventions.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index 3ed58bf49..f7ef86f11 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -10,10 +10,9 @@ chapter covers [formatting](#formatting), [coding for correctness](#cc), rustc is slowly moving towards the [Rust standard coding style][fmt]; at the moment, however, it follows a rather more *chaotic* style. We do have some mandatory formatting conventions, which are automatically -enforced by a script we affectionately[^not_true] call the "tidy" -script. The tidy script runs automatically when you do `./x.py test`. +enforced by a script we affectionately call the "tidy" script. The +tidy script runs automatically when you do `./x.py test`. -[^not_true]: Secretly, I hate tidy. -nmatsakis [fmt]: https://github.com/rust-lang-nursery/fmt-rfcs From 4af21aad8960a7126fc5bbc03084475d2eb90d0b Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 17 Feb 2018 20:24:48 -0800 Subject: [PATCH 0097/1812] Force mdbook update on CI if there is a version mismatch. Fixes #58. --- ci/install.sh | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/ci/install.sh b/ci/install.sh index 99c85986c..a5d87a6bc 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -6,9 +6,15 @@ function cargo_install() { local version=$2 if command -v $name >/dev/null 2>&1; then - echo "$name is already installed at $(command -v $name)" + local installed_version=`$name --version | sed -E 's/[a-zA-Z_-]+ v?//g'` + if [ "$installed_version" == "$version" ]; then + echo "$name $version is already installed at $(command -v $name)" + else + echo "Forcing install $name $version" + cargo install $name --version $version --force + fi else - echo "Installing $name" + echo "Installing $name $version" cargo install $name --version $version fi } From b9bc44dc5c891df210923fc6133478be8bc0b3e7 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 17 Feb 2018 20:35:57 -0800 Subject: [PATCH 0098/1812] Fix Github Pages path. The newer version of mdBook uses a different path for the html output. --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index f17a947d4..5ca97ba79 100644 --- a/.travis.yml +++ b/.travis.yml @@ -16,6 +16,6 @@ deploy: provider: pages skip-cleanup: true github-token: $GITHUB_TOKEN - local-dir: book + local-dir: book/html on: branch: master From 84c2cd5f605caa55792101a85e00537d48077468 Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Tue, 20 Feb 2018 15:32:17 -0800 Subject: [PATCH 0099/1812] added compiletest to summary.md; linked to existing resources for additional information --- src/SUMMARY.md | 1 + src/compiletest.md | 6 ++++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 6a3907551..1926a58cf 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -2,6 +2,7 @@ - [About this guide](./about-this-guide.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) + - [Using `compiletest` + commands to control test execution](./compiletest.md) - [Using the compiler testing framework](./running-tests.md) - [How to add new header commands to `compiletest`](./compiletest.md) - [Walkthrough: a typical contribution](./walkthrough.md) diff --git a/src/compiletest.md b/src/compiletest.md index 0b10cfbb7..e080e6ce7 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -6,7 +6,8 @@ configure behavior and expected results of both individual and groups of tests. `compiletest` tests may check test code for success, for failure or in some cases, even failure to compile. Tests are typically organized as a Rust source file with annotations in comments before and/or within the test code, which serve to -direct `compiletest` on if or how to run the test, what behavior to expect, and more. +direct `compiletest` on if or how to run the test, what behavior to expect, and more. If you are unfamiliar with the compiler +testing framework, see [`this chapter`](https://github.com/rust-lang-nursery/rustc-guide/blob/master/src/tests/intro.md) for additional background. The tests themselves are typically (but not always) organized into "suites"--for example, `run-pass`, a folder representing tests that should succeed, `run-fail`, a folder holding tests that should compile successfully, but return @@ -16,8 +17,9 @@ introduction to the different suites of compiler tests along with details about [here, at Brian Anderson's blog](https://brson.github.io/2017/07/10/how-rust-is-tested#s-ct). ## Adding a new test file -Simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test). No registration of test files is necessary as +Briefly, simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test). No registration of test files is necessary as `compiletest` will scan the [src/test](https://github.com/rust-lang/rust/tree/master/src/test) subfolder recursively, and will execute any Rust source files it finds as tests. +See [`Adding new tests`](https://github.com/rust-lang-nursery/rustc-guide/blob/master/src/tests/adding.md) for a complete guide on how to adding new tests. ## Header Commands Source file annotations which appear in comments near the top of the source file *before* any test code are known as header From 572eaa6e5dffabe6712787676f57563b0f4aa29e Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Wed, 21 Feb 2018 07:44:07 -0800 Subject: [PATCH 0100/1812] cleaned up some stragglers --- src/compiletest.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index e080e6ce7..854796adb 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -14,7 +14,7 @@ representing tests that should succeed, `run-fail`, a folder holding tests that a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various suites are defined in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs) in the `pub struct Config` declaration. And a very good introduction to the different suites of compiler tests along with details about them can be found -[here, at Brian Anderson's blog](https://brson.github.io/2017/07/10/how-rust-is-tested#s-ct). +in [`Adding new tests`](https://github.com/rust-lang-nursery/rustc-guide/blob/master/src/tests/adding.md). ## Adding a new test file Briefly, simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test). No registration of test files is necessary as @@ -25,14 +25,11 @@ See [`Adding new tests`](https://github.com/rust-lang-nursery/rustc-guide/blob/m Source file annotations which appear in comments near the top of the source file *before* any test code are known as header commands. These commands can instruct `compiletest` to ignore this test, set expectations on whether it is expected to succeed at compiling, or what the test's return code is expected to be. Header commands (and their inline counterparts, -Error Info commands) are described more fully -[here](https://github.com/rust-lang/rust/blob/master/src/test/COMPILER_TESTS.md). +Error Info commands) are described more fully [here](https://github.com/rust-lang-nursery/rustc-guide/blob/master/src/tests/adding.md#header-commands-configuring-rustc). ### Adding a new header command -Header commands are defined in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs). At a high level, dozens of test properties are defined -in the `TestProps` struct. These are all set to default values in the struct's `impl` block and any test can override this -default value by specifying the property as header command as a comment (`//`) in the test source file, before any source -code. +Header commands are defined in the `TestProps` struct in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs). At a high level, there are dozens of test properties are defined here, all set to default values in the `TestProp` struct's `impl` block. Any test can override this +default value by specifying the property in question as header command as a comment (`//`) in the test source file, before any source code. #### Using a header command Here is an example, specifying the `must-compile-successfully` header command, which takes no arguments, followed by the @@ -140,7 +137,7 @@ is that `compiletest` expects the failure code defined by the header command inv value. Although specific to `failure-status` (as every header command will have a different implementation in order to invoke -behavior change) perhaps it is helpful to see the behavior hange implementation of one case, simply as an example. To implement `failure-status`, the `check_correct_failure_status()` function found in the `TestCx` implementation block, +behavior change) perhaps it is helpful to see the behavior change implementation of one case, simply as an example. To implement `failure-status`, the `check_correct_failure_status()` function found in the `TestCx` implementation block, located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs), was modified as per below: ```diff @@ -295,11 +295,14 @@ impl<'test> TestCx<'test> { From b1c4662b011da780b9028e78016296b183ddc8fd Mon Sep 17 00:00:00 2001 From: Brad Gibson Date: Wed, 21 Feb 2018 10:44:23 -0800 Subject: [PATCH 0101/1812] changed to relative links, where possible --- src/compiletest.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index 854796adb..f07d3065a 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -7,28 +7,27 @@ configure behavior and expected results of both individual and groups of tests. `compiletest` tests may check test code for success, for failure or in some cases, even failure to compile. Tests are typically organized as a Rust source file with annotations in comments before and/or within the test code, which serve to direct `compiletest` on if or how to run the test, what behavior to expect, and more. If you are unfamiliar with the compiler -testing framework, see [`this chapter`](https://github.com/rust-lang-nursery/rustc-guide/blob/master/src/tests/intro.md) for additional background. +testing framework, see [`this chapter`](./tests/intro.html) for additional background. The tests themselves are typically (but not always) organized into "suites"--for example, `run-pass`, a folder representing tests that should succeed, `run-fail`, a folder holding tests that should compile successfully, but return a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various suites are defined in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs) in the `pub struct Config` declaration. And a very good -introduction to the different suites of compiler tests along with details about them can be found -in [`Adding new tests`](https://github.com/rust-lang-nursery/rustc-guide/blob/master/src/tests/adding.md). +introduction to the different suites of compiler tests along with details about them can be found in [`Adding new tests`](./tests/adding.html). ## Adding a new test file Briefly, simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test). No registration of test files is necessary as `compiletest` will scan the [src/test](https://github.com/rust-lang/rust/tree/master/src/test) subfolder recursively, and will execute any Rust source files it finds as tests. -See [`Adding new tests`](https://github.com/rust-lang-nursery/rustc-guide/blob/master/src/tests/adding.md) for a complete guide on how to adding new tests. +See [`Adding new tests`](./tests/adding.html) for a complete guide on how to adding new tests. ## Header Commands Source file annotations which appear in comments near the top of the source file *before* any test code are known as header commands. These commands can instruct `compiletest` to ignore this test, set expectations on whether it is expected to succeed at compiling, or what the test's return code is expected to be. Header commands (and their inline counterparts, -Error Info commands) are described more fully [here](https://github.com/rust-lang-nursery/rustc-guide/blob/master/src/tests/adding.md#header-commands-configuring-rustc). +Error Info commands) are described more fully [here](./tests/adding.html#header-commands-configuring-rustc). ### Adding a new header command -Header commands are defined in the `TestProps` struct in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs). At a high level, there are dozens of test properties are defined here, all set to default values in the `TestProp` struct's `impl` block. Any test can override this +Header commands are defined in the `TestProps` struct in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs). At a high level, there are dozens of test properties defined here, all set to default values in the `TestProp` struct's `impl` block. Any test can override this default value by specifying the property in question as header command as a comment (`//`) in the test source file, before any source code. #### Using a header command From 6e1eccd30c7d28ae07d264c9ed2aa1139b40c0fe Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Tue, 6 Feb 2018 19:10:04 +0100 Subject: [PATCH 0102/1812] Add some documentation for const eval and related topics --- src/SUMMARY.md | 3 + src/const-eval.md | 37 +++++++++++ src/glossary.md | 3 + src/miri.md | 142 ++++++++++++++++++++++++++++++++++++++++ src/param_env.md | 30 +++++++++ src/trait-resolution.md | 2 +- 6 files changed, 216 insertions(+), 1 deletion(-) create mode 100644 src/const-eval.md create mode 100644 src/miri.md create mode 100644 src/param_env.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index cb15c2c71..ea2a6cd98 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -23,5 +23,8 @@ - [MIR construction](./mir-construction.md) - [MIR borrowck](./mir-borrowck.md) - [MIR optimizations](./mir-optimizations.md) +- [Constant evaluation](./const-eval.md) + - [miri const evaluator](./miri.md) +- [Parameter Environments](./param_env.md) - [Generating LLVM IR](./trans.md) - [Glossary](./glossary.md) diff --git a/src/const-eval.md b/src/const-eval.md new file mode 100644 index 000000000..3fb65216a --- /dev/null +++ b/src/const-eval.md @@ -0,0 +1,37 @@ +# Constant Evaluation + +Constant evaluation is the process of computing values at compile time. For a +specific item (constant/static/array length) this happens after the MIR for the +item is borrow-checked and optimized. In many cases trying to const evaluate an +item will trigger the computation of its MIR for the first time. + +Prominent examples are + +* The initializer of a `static` +* Array length + * needs to be known to reserve stack or heap space +* Enum variant discriminants + * needs to be known to prevent two variants from having the same discriminant +* Patterns + * need to be known to check for overlapping patterns + +Additionally constant evaluation can be used to reduce the workload or binary +size at runtime by precomputing complex operations at compiletime and only +storing the result. + +Constant evaluation can be done by calling the `const_eval` query of `TyCtxt`. + +The `const_eval` query takes a [`ParamEnv`](./param_env.html) of environment in +which the constant is evaluated (e.g. the function within which the constant is +used) and a `GlobalId`. The `GlobalId` is made up of an +`Instance` referring to a constant or static or of an +`Instance` of a function and an index into the function's `Promoted` table. + +Constant evaluation returns a `Result` with either the error, or the simplest +representation of the constant. "simplest" meaning if it is representable as an +integer or fat pointer, it will directly yield the value (via `Value::ByVal` or +`Value::ByValPair`), instead of referring to the [`miri`](./miri.html) virtual +memory allocation (via `Value::ByRef`). This means that the `const_eval` +function cannot be used to create miri-pointers to the evaluated constant or +static. If you need that, you need to directly work with the functions in +[src/librustc_mir/interpret/const_eval.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/const_eval.rs). diff --git a/src/glossary.md b/src/glossary.md index a22c49632..34b4bd446 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -18,6 +18,9 @@ generics | the set of generic type parameters defined on a type ICE | internal compiler error. When the compiler crashes. ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. infcx | the inference context (see `librustc/infer`) +MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) +miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) +obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) local crate | the crate currently being compiled. MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. diff --git a/src/miri.md b/src/miri.md new file mode 100644 index 000000000..4b0a600be --- /dev/null +++ b/src/miri.md @@ -0,0 +1,142 @@ +# Miri + +Miri (**MIR** **I**nterpreter) is a virtual machine for executing MIR without +compiling to machine code. It is usually invoked via `tcx.const_eval`. + +If you start out with a constant + +```rust +const FOO: usize = 1 << 12; +``` + +rustc doesn't actually invoke anything until the constant is either used or +placed into metadata. + +Once you have a use-site like + +```rust +type Foo = [u8; FOO - 42]; +``` + +The compiler needs to figure out the length of the array before being able to +create items that use the type (locals, constants, function arguments, ...). + +To obtain the (in this case empty) parameter environment, one can call +`let param_env = tcx.param_env(length_def_id);`. The `GlobalId` needed is + +```rust +let gid = GlobalId { + promoted: None, + instance: Instance::mono(length_def_id), +}; +``` + +Invoking `tcx.const_eval(param_env.and(gid))` will now trigger the creation of +the MIR of the array length expression. The MIR will look something like this: + +```mir +const Foo::{{initializer}}: usize = { + let mut _0: usize; // return pointer + let mut _1: (usize, bool); + + bb0: { + _1 = CheckedSub(const Unevaluated(FOO, Slice([])), const 42usize); + assert(!(_1.1: bool), "attempt to subtract with overflow") -> bb1; + } + + bb1: { + _0 = (_1.0: usize); + return; + } +} +``` + +Before the evaluation, a virtual memory location (in this case essentially a +`vec![u8; 4]` or `vec![u8; 8]`) is created for storing the evaluation result. + +At the start of the evaluation, `_0` and `_1` are +`Value::ByVal(PrimVal::Undef)`. When the initialization of `_1` is invoked, the +value of the `FOO` constant is required, and triggers another call to +`tcx.const_eval`, which will not be shown here. If the evaluation of FOO is +successful, 42 will be subtracted by its value `4096` and the result stored in +`_1` as `Value::ByValPair(PrimVal::Bytes(4054), PrimVal::Bytes(0))`. The first +part of the pair is the computed value, the second part is a bool that's true if +an overflow happened. + +The next statement asserts that said boolean is `0`. In case the assertion +fails, its error message is used for reporting a compile-time error. + +Since it does not fail, `Value::ByVal(PrimVal::Bytes(4054))` is stored in the +virtual memory was allocated before the evaluation. `_0` always refers to that +location directly. + +After the evaluation is done, the virtual memory allocation is interned into the +`TyCtxt`. Future evaluations of the same constants will not actually invoke +miri, but just extract the value from the interned allocation. + +The `tcx.const_eval` function has one additional feature: it will not return a +`ByRef(interned_allocation_id)`, but a `ByVal(computed_value)` if possible. This +makes using the result much more convenient, as no further queries need to be +executed in order to get at something as simple as a `usize`. + +## Datastructures + +Miri's core datastructures can be found in +[librustc/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc/mir/interpret). +This is mainly the error enum and the `Value` and `PrimVal` types. A `Value` can +be either `ByVal` (a single `PrimVal`), `ByValPair` (two `PrimVal`s, usually fat +pointers or two element tuples) or `ByRef`, which is used for anything else and +refers to a virtual allocation. These allocations can be accessed via the +methods on `tcx.interpret_interner`. + +If you are expecting a numeric result, you can use `unwrap_u64` (panics on +anything that can't be representad as a `u64`) or `to_raw_bits` which results +in an `Option` yielding the `ByVal` if possible. + +## Allocations + +A miri allocation is either a byte sequence of the memory or an `Instance` in +the case of function pointers. Byte sequences can additionally contain +relocations that mark a group of bytes as a pointer to another allocation. The +actual bytes at the relocation refer to the offset inside the other allocation. + +These allocations exist so that references and raw pointers have something to +point to. There is no global linear heap in which things are allocated, but each +allocation (be it for a local variable, a static or a (future) heap allocation) +gets its own little memory with exactly the required size. So if you have a +pointer to an allocation for a local variable `a`, there is no possible (no +matter how unsafe) operation that you can do that would ever change said pointer +to a pointer to `b`. + +## Interpretation + +Although the main entry point to constant evaluation is the `tcx.const_eval` +query, there are additional functions in +[librustc_mir/interpret/const_eval.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/const_eval.rs) +that allow accessing the fields of a `Value` (`ByRef` or otherwise). You should +never have to access an `Allocation` directly except for translating it to the +compilation target (at the moment just LLVM). + +Miri starts by creating a virtual stack frame for the current constant that is +being evaluated. There's essentially no difference between a constant and a +function with no arguments, except that constants do not allow local (named) +variables at the time of writing this guide. + +A stack frame is defined by the `Frame` type in +[librustc_mir/interpret/eval_context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/eval_context.rs) +and contains all the local +variables memory (`None` at the start of evaluation). Each frame refers to the +evaluation of either the root constant or subsequent calls to `const fn`. The +evaluation of another constant simply calls `tcx.const_eval`, which produces an +entirely new and independent stack frame. + +The frames are just a `Vec`, there's no way to actually refer to a +`Frame`'s memory even if horrible shenigans are done via unsafe code. The only +memory that can be referred to are `Allocation`s. + +Miri now calls the `step` method (in +[librustc_mir/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/step.rs) +) until it either returns an error or has no further statements to execute. Each +statement will now initialize or modify the locals or the virtual memory +referred to by a local. This might require evaluating other constants or +statics, which just recursively invokes `tcx.const_eval`. diff --git a/src/param_env.md b/src/param_env.md new file mode 100644 index 000000000..2474886ef --- /dev/null +++ b/src/param_env.md @@ -0,0 +1,30 @@ +# Parameter Environment + +When working with associated and/or or generic items (types, constants, +functions/methods) it is often relevant to have more information about the +`Self` or generic parameters. Trait bounds and similar information is encoded in +the `ParamEnv`. Often this is not enough information to obtain things like the +type's `Layout`, but you can do all kinds of other checks on it (e.g. whether a +type implements `Copy`) or you can evaluate an associated constant whose value +does not depend on anything from the parameter environment. + +For example if you have a function + +```rust +fn foo(t: T) { +} +``` + +the parameter environment for that function is `[T: Copy]`. This means any +evaluation within this function will, when accessing the type `T`, know about +its `Copy` bound via the parameter environment. + +Although you can obtain a valid `ParamEnv` for any item via +`tcx.param_env(def_id)`, this `ParamEnv` can be too generic for your use case. +Using the `ParamEnv` from the surrounding context can allow you to evaluate more +things. + +Another great thing about `ParamEnv` is that you can use it to bundle the thing +depending on generic parameters (e.g. a `Ty`) by calling `param_env.and(ty)`. +This will produce a `ParamEnvAnd`, making clear that you should probably not +be using the inner value without taking care to also use the `ParamEnv`. diff --git a/src/trait-resolution.md b/src/trait-resolution.md index f12ce3b4b..10a5539e4 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -433,7 +433,7 @@ before, and hence the cache lookup would succeed, yielding One subtle interaction is that the results of trait lookup will vary depending on what where clauses are in scope. Therefore, we actually have *two* caches, a local and a global cache. The local cache is -attached to the `ParamEnv` and the global cache attached to the +attached to the [`ParamEnv`](./param_env.html) and the global cache attached to the `tcx`. We use the local cache whenever the result might depend on the where clauses that are in scope. The determination of which cache to use is done by the method `pick_candidate_cache` in `select.rs`. At From 2f04df39d1f6010d015c02dfbb1801d3aeb9113c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Feb 2018 15:22:38 -0600 Subject: [PATCH 0103/1812] Clean up and reorganize traits chapter --- src/SUMMARY.md | 3 + src/trait-caching.md | 54 +++++ src/trait-hrtb.md | 116 +++++++++++ src/trait-resolution.md | 402 ++++++++++-------------------------- src/trait-specialization.md | 39 ++++ 5 files changed, 322 insertions(+), 292 deletions(-) create mode 100644 src/trait-caching.md create mode 100644 src/trait-hrtb.md create mode 100644 src/trait-specialization.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ea2a6cd98..af7dfbd66 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -18,6 +18,9 @@ - [The `ty` module: representing types](./ty.md) - [Type inference](./type-inference.md) - [Trait resolution](./trait-resolution.md) + - [Higher-ranked trait bounds](./trait-hrtb.md) + - [Caching subtleties](./trait-caching.md) + - [Speciailization](./trait-specialization.md) - [Type checking](./type-checking.md) - [The MIR (Mid-level IR)](./mir.md) - [MIR construction](./mir-construction.md) diff --git a/src/trait-caching.md b/src/trait-caching.md new file mode 100644 index 000000000..6a0e55b27 --- /dev/null +++ b/src/trait-caching.md @@ -0,0 +1,54 @@ +# Caching and subtle considerations therewith + +In general we attempt to cache the results of trait selection. This +is a somewhat complex process. Part of the reason for this is that we +want to be able to cache results even when all the types in the trait +reference are not fully known. In that case, it may happen that the +trait selection process is also influencing type variables, so we have +to be able to not only cache the *result* of the selection process, +but *replay* its effects on the type variables. + +## An example + +The high-level idea of how the cache works is that we first replace +all unbound inference variables with skolemized versions. Therefore, +if we had a trait reference `usize : Foo<$1>`, where `$n` is an unbound +inference variable, we might replace it with `usize : Foo<%0>`, where +`%n` is a skolemized type. We would then look this up in the cache. +If we found a hit, the hit would tell us the immediate next step to +take in the selection process: i.e. apply impl #22, or apply where +clause `X : Foo`. Let's say in this case there is no hit. +Therefore, we search through impls and where clauses and so forth, and +we come to the conclusion that the only possible impl is this one, +with def-id 22: + +```rust +impl Foo for usize { ... } // Impl #22 +``` + +We would then record in the cache `usize : Foo<%0> ==> +ImplCandidate(22)`. Next we would confirm `ImplCandidate(22)`, which +would (as a side-effect) unify `$1` with `isize`. + +Now, at some later time, we might come along and see a `usize : +Foo<$3>`. When skolemized, this would yield `usize : Foo<%0>`, just as +before, and hence the cache lookup would succeed, yielding +`ImplCandidate(22)`. We would confirm `ImplCandidate(22)` which would +(as a side-effect) unify `$3` with `isize`. + +## Where clauses and the local vs global cache + +One subtle interaction is that the results of trait lookup will vary +depending on what where clauses are in scope. Therefore, we actually +have *two* caches, a local and a global cache. The local cache is +attached to the `ParamEnv` and the global cache attached to the +`tcx`. We use the local cache whenever the result might depend on the +where clauses that are in scope. The determination of which cache to +use is done by the method `pick_candidate_cache` in `select.rs`. At +the moment, we use a very simple, conservative rule: if there are any +where-clauses in scope, then we use the local cache. We used to try +and draw finer-grained distinctions, but that led to a serious of +annoying and weird bugs like #22019 and #18290. This simple rule seems +to be pretty clearly safe and also still retains a very high hit rate +(~95% when compiling rustc). + diff --git a/src/trait-hrtb.md b/src/trait-hrtb.md new file mode 100644 index 000000000..f0c47d942 --- /dev/null +++ b/src/trait-hrtb.md @@ -0,0 +1,116 @@ +# Higher-ranked trait bounds + +One of the more subtle concepts at work are *higher-ranked trait +bounds*. An example of such a bound is `for<'a> MyTrait<&'a isize>`. +Let's walk through how selection on higher-ranked trait references +works. + +## Basic matching and skolemization leaks + +Let's walk through the test `compile-fail/hrtb-just-for-static.rs` to see +how it works. The test starts with the trait `Foo`: + +```rust +trait Foo { + fn foo(&self, x: X) { } +} +``` + +Let's say we have a function `want_hrtb` that wants a type which +implements `Foo<&'a isize>` for any `'a`: + +```rust +fn want_hrtb() where T : for<'a> Foo<&'a isize> { ... } +``` + +Now we have a struct `AnyInt` that implements `Foo<&'a isize>` for any +`'a`: + +```rust +struct AnyInt; +impl<'a> Foo<&'a isize> for AnyInt { } +``` + +And the question is, does `AnyInt : for<'a> Foo<&'a isize>`? We want the +answer to be yes. The algorithm for figuring it out is closely related +to the subtyping for higher-ranked types (which is described in +`middle::infer::higher_ranked::doc`, but also in a [paper by SPJ] that +I recommend you read). + +1. Skolemize the obligation. +2. Match the impl against the skolemized obligation. +3. Check for skolemization leaks. + +[paper by SPJ]: http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ + +So let's work through our example. The first thing we would do is to +skolemize the obligation, yielding `AnyInt : Foo<&'0 isize>` (here `'0` +represents skolemized region #0). Note that now have no quantifiers; +in terms of the compiler type, this changes from a `ty::PolyTraitRef` +to a `TraitRef`. We would then create the `TraitRef` from the impl, +using fresh variables for it's bound regions (and thus getting +`Foo<&'$a isize>`, where `'$a` is the inference variable for `'a`). Next +we relate the two trait refs, yielding a graph with the constraint +that `'0 == '$a`. Finally, we check for skolemization "leaks" – a +leak is basically any attempt to relate a skolemized region to another +skolemized region, or to any region that pre-existed the impl match. +The leak check is done by searching from the skolemized region to find +the set of regions that it is related to in any way. This is called +the "taint" set. To pass the check, that set must consist *solely* of +itself and region variables from the impl. If the taint set includes +any other region, then the match is a failure. In this case, the taint +set for `'0` is `{'0, '$a}`, and hence the check will succeed. + +Let's consider a failure case. Imagine we also have a struct + +```rust +struct StaticInt; +impl Foo<&'static isize> for StaticInt; +``` + +We want the obligation `StaticInt : for<'a> Foo<&'a isize>` to be +considered unsatisfied. The check begins just as before. `'a` is +skolemized to `'0` and the impl trait reference is instantiated to +`Foo<&'static isize>`. When we relate those two, we get a constraint +like `'static == '0`. This means that the taint set for `'0` is `{'0, +'static}`, which fails the leak check. + +## Higher-ranked trait obligations + +Once the basic matching is done, we get to another interesting topic: +how to deal with impl obligations. I'll work through a simple example +here. Imagine we have the traits `Foo` and `Bar` and an associated impl: + +```rust +trait Foo { + fn foo(&self, x: X) { } +} + +trait Bar { + fn bar(&self, x: X) { } +} + +impl Foo for F + where F : Bar +{ +} +``` + +Now let's say we have a obligation `for<'a> Foo<&'a isize>` and we match +this impl. What obligation is generated as a result? We want to get +`for<'a> Bar<&'a isize>`, but how does that happen? + +After the matching, we are in a position where we have a skolemized +substitution like `X => &'0 isize`. If we apply this substitution to the +impl obligations, we get `F : Bar<&'0 isize>`. Obviously this is not +directly usable because the skolemized region `'0` cannot leak out of +our computation. + +What we do is to create an inverse mapping from the taint set of `'0` +back to the original bound region (`'a`, here) that `'0` resulted +from. (This is done in `higher_ranked::plug_leaks`). We know that the +leak check passed, so this taint set consists solely of the skolemized +region itself plus various intermediate region variables. We then walk +the trait-reference and convert every region in that taint set back to +a late-bound region, so in this case we'd wind up with `for<'a> F : +Bar<&'a isize>`. diff --git a/src/trait-resolution.md b/src/trait-resolution.md index 10a5539e4..1cad488ac 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -1,10 +1,7 @@ # Trait resolution -This document describes the general process and points out some non-obvious -things. - -**WARNING:** This material was moved verbatim from a rustc README, so -it may not "fit" the style of the guide until it is adapted. +This chapter describes the general process of _trait resolution_ and points out +some non-obvious things. ## Major concepts @@ -21,12 +18,12 @@ and then a call to that function: let v: Vec = clone_slice(&[1, 2, 3]) ``` -it is the job of trait resolution to figure out (in which case) -whether there exists an impl of `isize : Clone` +it is the job of trait resolution to figure out whether there exists an impl of +(in this case) `isize : Clone`. Note that in some cases, like generic functions, we may not be able to find a specific impl, but we can figure out that the caller must -provide an impl. To see what I mean, consider the body of `clone_slice`: +provide an impl. For example, consider the body of `clone_slice`: ```rust fn clone_slice(x: &[T]) -> Vec { @@ -43,26 +40,33 @@ is, we can't find the specific impl; but based on the bound `T:Clone`, we can say that there exists an impl which the caller must provide. We use the term *obligation* to refer to a trait reference in need of -an impl. +an impl. Basically, the trait resolution system resolves an obligation +by proving that an appropriate impl does exist. + +During type checking, we do not store the results of trait selection. +We simply wish to verify that trait selection will succeed. Then +later, at trans time, when we have all concrete types available, we +can repeat the trait selection to choose an actual implementation, which +will then be generated in the output binary. ## Overview Trait resolution consists of three major parts: -- SELECTION: Deciding how to resolve a specific obligation. For +- **Selection** is deciding how to resolve a specific obligation. For example, selection might decide that a specific obligation can be - resolved by employing an impl which matches the self type, or by - using a parameter bound. In the case of an impl, Selecting one + resolved by employing an impl which matches the `Self` type, or by + using a parameter bound (e.g. `T: Trait`). In the case of an impl, selecting one obligation can create *nested obligations* because of where clauses on the impl itself. It may also require evaluating those nested obligations to resolve ambiguities. -- FULFILLMENT: The fulfillment code is what tracks that obligations - are completely fulfilled. Basically it is a worklist of obligations +- **Fulfillment** is keeping track of which obligations + are completely fulfilled. Basically, it is a worklist of obligations to be selected: once selection is successful, the obligation is removed from the worklist and any nested obligations are enqueued. -- COHERENCE: The coherence checks are intended to ensure that there +- **Coherence** checks are intended to ensure that there are never overlapping impls, where two impls could be used with equal precedence. @@ -83,12 +87,21 @@ and returns a `SelectionResult`. There are three possible outcomes: contains unbound type variables. - `Err(err)` – the obligation definitely cannot be resolved due to a - type error, or because there are no impls that could possibly apply, - etc. + type error or because there are no impls that could possibly apply. The basic algorithm for selection is broken into two big phases: candidate assembly and confirmation. +Note that because of how lifetime inference works, it is not possible to +give back immediate feedback as to whether a unification or subtype +relationship between lifetimes holds or not. Therefore, lifetime +matching is *not* considered during selection. This is reflected in +the fact that subregion assignment is infallible. This may yield +lifetime constraints that will later be found to be in error (in +contrast, the non-lifetime-constraints have already been checked +during selection and can never cause an error, though naturally they +may lead to other errors downstream). + ### Candidate assembly Searches for impls/where-clauses/etc that might @@ -98,6 +111,15 @@ candidate that is definitively applicable. In some cases, we may not know whether an impl/where-clause applies or not – this occurs when the obligation contains unbound inference variables. +The subroutines that decide whether a particular impl/where-clause/etc +applies to a particular obligation are collectively refered to as the +process of _matching_. At the moment, this amounts to +unifying the `Self` types, but in the future we may also recursively +consider some of the nested obligations, in the case of an impl. + +**TODO**: what does "unifying the `Self` types" mean? The `Self` of the +obligation with that of an impl? + The basic idea for candidate assembly is to do a first pass in which we identify all possible candidates. During this pass, all that we do is try and unify the type parameters. (In particular, we ignore any @@ -141,16 +163,14 @@ let y = x.convert(); The call to convert will generate a trait reference `Convert<$Y> for isize`, where `$Y` is the type variable representing the type of -`y`. When we match this against the two impls we can see, we will find -that only one remains: `Convert for isize`. Therefore, we can +`y`. Of the two impls we can see, the only one that matches is +`Convert for isize`. Therefore, we can select this impl, which will cause the type of `$Y` to be unified to `usize`. (Note that while assembling candidates, we do the initial unifications in a transaction, so that they don't affect one another.) -There are tests to this effect in src/test/run-pass: - - traits-multidispatch-infer-convert-source-and-target.rs - traits-multidispatch-infer-convert-target.rs +**TODO**: The example says we can "select" the impl, but this section is talking specifically about candidate assembly. Does this mean we can sometimes skip confirmation? Or is this poor wording? +**TODO**: Is the unification of `$Y` part of trait resolution or type inference? Or is this not the same type of "inference variable" as in type inference? #### Winnowing: Resolving ambiguities @@ -167,94 +187,103 @@ impl Get for T { } impl Get for Box { - fn get(&self) -> Box { box get_it(&**self) } + fn get(&self) -> Box { Box::new(get_it(&**self)) } } ``` -What happens when we invoke `get_it(&box 1_u16)`, for example? In this +What happens when we invoke `get_it(&Box::new(1_u16))`, for example? In this case, the `Self` type is `Box` – that unifies with both impls, because the first applies to all types, and the second to all -boxes. In the olden days we'd have called this ambiguous. But what we -do now is do a second *winnowing* pass that considers where clauses -and attempts to remove candidates – in this case, the first impl only +boxes. In order for this to be unambiguous, the compiler does a *winnowing* +pass that considers `where` clauses +and attempts to remove candidates. In this case, the first impl only applies if `Box : Copy`, which doesn't hold. After winnowing, -then, we are left with just one candidate, so we can proceed. There is -a test of this in `src/test/run-pass/traits-conditional-dispatch.rs`. - -#### Matching - -The subroutines that decide whether a particular impl/where-clause/etc -applies to a particular obligation. At the moment, this amounts to -unifying the self types, but in the future we may also recursively -consider some of the nested obligations, in the case of an impl. +then, we are left with just one candidate, so we can proceed. -#### Lifetimes and selection - -Because of how that lifetime inference works, it is not possible to -give back immediate feedback as to whether a unification or subtype -relationship between lifetimes holds or not. Therefore, lifetime -matching is *not* considered during selection. This is reflected in -the fact that subregion assignment is infallible. This may yield -lifetime constraints that will later be found to be in error (in -contrast, the non-lifetime-constraints have already been checked -during selection and can never cause an error, though naturally they -may lead to other errors downstream). - -#### Where clauses +#### `where` clauses Besides an impl, the other major way to resolve an obligation is via a -where clause. The selection process is always given a *parameter -environment* which contains a list of where clauses, which are -basically obligations that can assume are satisfiable. We will iterate +where clause. The selection process is always given a [parameter +environment] which contains a list of where clauses, which are +basically obligations that we can assume are satisfiable. We will iterate over that list and check whether our current obligation can be found -in that list, and if so it is considered satisfied. More precisely, we +in that list. If so, it is considered satisfied. More precisely, we want to check whether there is a where-clause obligation that is for -the same trait (or some subtrait) and for which the self types match, -using the definition of *matching* given above. +the same trait (or some subtrait) and which can match against the obligation. + +[parameter environment]: ./param_env.html Consider this simple example: ```rust -trait A1 { /*...*/ } +trait A1 { + fn do_a1(&self); +} trait A2 : A1 { /*...*/ } -trait B { /*...*/ } +trait B { + fn do_b(&self); +} -fn foo { /*...*/ } +fn foo(x: X) { + x.do_a1(); // (*) + x.do_b(); // (#) +} ``` -Clearly we can use methods offered by `A1`, `A2`, or `B` within the -body of `foo`. In each case, that will incur an obligation like `X : -A1` or `X : A2`. The parameter environment will contain two -where-clauses, `X : A2` and `X : B`. For each obligation, then, we -search this list of where-clauses. To resolve an obligation `X:A1`, -we would note that `X:A2` implies that `X:A1`. +In the body of `foo`, clearly we can use methods of `A1`, `A2`, or `B` +on variable `x`. The line marked `(*)` will incur an obligation `X: A1`, +which the line marked `(#)` will incur an obligation `X: B`. Meanwhile, +the parameter environment will contain two where-clauses: `X : A2` and `X : B`. +For each obligation, then, we search this list of where-clauses. The +obligation `X: B` trivially matches against the where-clause `X: B`. +To resolve an obligation `X:A1`, we would note that `X:A2` implies that `X:A1`. ### Confirmation -Confirmation unifies the output type parameters of the trait with the -values found in the obligation, possibly yielding a type error. If we -return to our example of the `Convert` trait from the previous -section, confirmation is where an error would be reported, because the -impl specified that `T` would be `usize`, but the obligation reported -`char`. Hence the result of selection would be an error. +_Confirmation_ unifies the output type parameters of the trait with the +values found in the obligation, possibly yielding a type error. + +Suppose we have the following variation of the `Convert` example in the +previous section: + +```rust +trait Convert { + fn convert(&self) -> Target; +} + +impl Convert for isize { /*...*/ } // isize -> usize +impl Convert for usize { /*...*/ } // usize -> isize + +let x: isize = ...; +let y: char = x.convert(); // NOTE: `y: char` now! +``` + +Confirmation is where an error would be reported because the impl specified +that `Target` would be `usize`, but the obligation reported `char`. Hence the +result of selection would be an error. + +Note that the candidate impl is chosen base on the `Self` type, but +confirmation is done based on (in this case) the `Target` type parameter. ### Selection during translation -During type checking, we do not store the results of trait selection. -We simply wish to verify that trait selection will succeed. Then -later, at trans time, when we have all concrete types available, we -can repeat the trait selection. In this case, we do not consider any -where-clauses to be in scope. We know that therefore each resolution -will resolve to a particular impl. +As mentioned above, during type checking, we do not store the results of trait +selection. At trans time, repeat the trait selection to choose a particular +impl for each method call. In this second selection, we do not consider any +where-clauses to be in scope because we know that each resolution will resolve +to a particular impl. One interesting twist has to do with nested obligations. In general, in trans, we only need to do a "shallow" selection for an obligation. That is, we wish to identify which impl applies, but we do not (yet) need to decide how to select -any nested obligations. Nonetheless, we *do* currently do a complete resolution, -and that is because it can sometimes inform the results of type inference. That is, -we do not have the full substitutions in terms of the type variables of the impl available -to us, so we must run trait selection to figure everything out. +any nested obligations. Nonetheless, we *do* currently do a complete +resolution, and that is because it can sometimes inform the results of type +inference. That is, we do not have the full substitutions for the type +variables of the impl available to us, so we must run trait selection to figure +everything out. + +**TODO**: is this still talking about trans? Here is an example: @@ -272,214 +301,3 @@ nested obligation `isize : Bar` to find out that `U=usize`. It would be good to only do *just as much* nested resolution as necessary. Currently, though, we just do a full resolution. - -# Higher-ranked trait bounds - -One of the more subtle concepts at work are *higher-ranked trait -bounds*. An example of such a bound is `for<'a> MyTrait<&'a isize>`. -Let's walk through how selection on higher-ranked trait references -works. - -## Basic matching and skolemization leaks - -Let's walk through the test `compile-fail/hrtb-just-for-static.rs` to see -how it works. The test starts with the trait `Foo`: - -```rust -trait Foo { - fn foo(&self, x: X) { } -} -``` - -Let's say we have a function `want_hrtb` that wants a type which -implements `Foo<&'a isize>` for any `'a`: - -```rust -fn want_hrtb() where T : for<'a> Foo<&'a isize> { ... } -``` - -Now we have a struct `AnyInt` that implements `Foo<&'a isize>` for any -`'a`: - -```rust -struct AnyInt; -impl<'a> Foo<&'a isize> for AnyInt { } -``` - -And the question is, does `AnyInt : for<'a> Foo<&'a isize>`? We want the -answer to be yes. The algorithm for figuring it out is closely related -to the subtyping for higher-ranked types (which is described in -`middle::infer::higher_ranked::doc`, but also in a [paper by SPJ] that -I recommend you read). - -1. Skolemize the obligation. -2. Match the impl against the skolemized obligation. -3. Check for skolemization leaks. - -[paper by SPJ]: http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ - -So let's work through our example. The first thing we would do is to -skolemize the obligation, yielding `AnyInt : Foo<&'0 isize>` (here `'0` -represents skolemized region #0). Note that now have no quantifiers; -in terms of the compiler type, this changes from a `ty::PolyTraitRef` -to a `TraitRef`. We would then create the `TraitRef` from the impl, -using fresh variables for it's bound regions (and thus getting -`Foo<&'$a isize>`, where `'$a` is the inference variable for `'a`). Next -we relate the two trait refs, yielding a graph with the constraint -that `'0 == '$a`. Finally, we check for skolemization "leaks" – a -leak is basically any attempt to relate a skolemized region to another -skolemized region, or to any region that pre-existed the impl match. -The leak check is done by searching from the skolemized region to find -the set of regions that it is related to in any way. This is called -the "taint" set. To pass the check, that set must consist *solely* of -itself and region variables from the impl. If the taint set includes -any other region, then the match is a failure. In this case, the taint -set for `'0` is `{'0, '$a}`, and hence the check will succeed. - -Let's consider a failure case. Imagine we also have a struct - -```rust -struct StaticInt; -impl Foo<&'static isize> for StaticInt; -``` - -We want the obligation `StaticInt : for<'a> Foo<&'a isize>` to be -considered unsatisfied. The check begins just as before. `'a` is -skolemized to `'0` and the impl trait reference is instantiated to -`Foo<&'static isize>`. When we relate those two, we get a constraint -like `'static == '0`. This means that the taint set for `'0` is `{'0, -'static}`, which fails the leak check. - -## Higher-ranked trait obligations - -Once the basic matching is done, we get to another interesting topic: -how to deal with impl obligations. I'll work through a simple example -here. Imagine we have the traits `Foo` and `Bar` and an associated impl: - -```rust -trait Foo { - fn foo(&self, x: X) { } -} - -trait Bar { - fn bar(&self, x: X) { } -} - -impl Foo for F - where F : Bar -{ -} -``` - -Now let's say we have a obligation `for<'a> Foo<&'a isize>` and we match -this impl. What obligation is generated as a result? We want to get -`for<'a> Bar<&'a isize>`, but how does that happen? - -After the matching, we are in a position where we have a skolemized -substitution like `X => &'0 isize`. If we apply this substitution to the -impl obligations, we get `F : Bar<&'0 isize>`. Obviously this is not -directly usable because the skolemized region `'0` cannot leak out of -our computation. - -What we do is to create an inverse mapping from the taint set of `'0` -back to the original bound region (`'a`, here) that `'0` resulted -from. (This is done in `higher_ranked::plug_leaks`). We know that the -leak check passed, so this taint set consists solely of the skolemized -region itself plus various intermediate region variables. We then walk -the trait-reference and convert every region in that taint set back to -a late-bound region, so in this case we'd wind up with `for<'a> F : -Bar<&'a isize>`. - -# Caching and subtle considerations therewith - -In general we attempt to cache the results of trait selection. This -is a somewhat complex process. Part of the reason for this is that we -want to be able to cache results even when all the types in the trait -reference are not fully known. In that case, it may happen that the -trait selection process is also influencing type variables, so we have -to be able to not only cache the *result* of the selection process, -but *replay* its effects on the type variables. - -## An example - -The high-level idea of how the cache works is that we first replace -all unbound inference variables with skolemized versions. Therefore, -if we had a trait reference `usize : Foo<$1>`, where `$n` is an unbound -inference variable, we might replace it with `usize : Foo<%0>`, where -`%n` is a skolemized type. We would then look this up in the cache. -If we found a hit, the hit would tell us the immediate next step to -take in the selection process: i.e. apply impl #22, or apply where -clause `X : Foo`. Let's say in this case there is no hit. -Therefore, we search through impls and where clauses and so forth, and -we come to the conclusion that the only possible impl is this one, -with def-id 22: - -```rust -impl Foo for usize { ... } // Impl #22 -``` - -We would then record in the cache `usize : Foo<%0> ==> -ImplCandidate(22)`. Next we would confirm `ImplCandidate(22)`, which -would (as a side-effect) unify `$1` with `isize`. - -Now, at some later time, we might come along and see a `usize : -Foo<$3>`. When skolemized, this would yield `usize : Foo<%0>`, just as -before, and hence the cache lookup would succeed, yielding -`ImplCandidate(22)`. We would confirm `ImplCandidate(22)` which would -(as a side-effect) unify `$3` with `isize`. - -## Where clauses and the local vs global cache - -One subtle interaction is that the results of trait lookup will vary -depending on what where clauses are in scope. Therefore, we actually -have *two* caches, a local and a global cache. The local cache is -attached to the [`ParamEnv`](./param_env.html) and the global cache attached to the -`tcx`. We use the local cache whenever the result might depend on the -where clauses that are in scope. The determination of which cache to -use is done by the method `pick_candidate_cache` in `select.rs`. At -the moment, we use a very simple, conservative rule: if there are any -where-clauses in scope, then we use the local cache. We used to try -and draw finer-grained distinctions, but that led to a serious of -annoying and weird bugs like #22019 and #18290. This simple rule seems -to be pretty clearly safe and also still retains a very high hit rate -(~95% when compiling rustc). - -# Specialization - -Defined in the `specialize` module. - -The basic strategy is to build up a *specialization graph* during -coherence checking. Insertion into the graph locates the right place -to put an impl in the specialization hierarchy; if there is no right -place (due to partial overlap but no containment), you get an overlap -error. Specialization is consulted when selecting an impl (of course), -and the graph is consulted when propagating defaults down the -specialization hierarchy. - -You might expect that the specialization graph would be used during -selection – i.e. when actually performing specialization. This is -not done for two reasons: - -- It's merely an optimization: given a set of candidates that apply, - we can determine the most specialized one by comparing them directly - for specialization, rather than consulting the graph. Given that we - also cache the results of selection, the benefit of this - optimization is questionable. - -- To build the specialization graph in the first place, we need to use - selection (because we need to determine whether one impl specializes - another). Dealing with this reentrancy would require some additional - mode switch for selection. Given that there seems to be no strong - reason to use the graph anyway, we stick with a simpler approach in - selection, and use the graph only for propagating default - implementations. - -Trait impl selection can succeed even when multiple impls can apply, -as long as they are part of the same specialization family. In that -case, it returns a *single* impl on success – this is the most -specialized impl *known* to apply. However, if there are any inference -variables in play, the returned impl may not be the actual impl we -will use at trans time. Thus, we take special care to avoid projecting -associated types unless either (1) the associated type does not use -`default` and thus cannot be overridden or (2) all input types are -known concretely. diff --git a/src/trait-specialization.md b/src/trait-specialization.md new file mode 100644 index 000000000..6b8bc64dd --- /dev/null +++ b/src/trait-specialization.md @@ -0,0 +1,39 @@ +# Specialization + +Defined in the `specialize` module. + +The basic strategy is to build up a *specialization graph* during +coherence checking. Insertion into the graph locates the right place +to put an impl in the specialization hierarchy; if there is no right +place (due to partial overlap but no containment), you get an overlap +error. Specialization is consulted when selecting an impl (of course), +and the graph is consulted when propagating defaults down the +specialization hierarchy. + +You might expect that the specialization graph would be used during +selection – i.e. when actually performing specialization. This is +not done for two reasons: + +- It's merely an optimization: given a set of candidates that apply, + we can determine the most specialized one by comparing them directly + for specialization, rather than consulting the graph. Given that we + also cache the results of selection, the benefit of this + optimization is questionable. + +- To build the specialization graph in the first place, we need to use + selection (because we need to determine whether one impl specializes + another). Dealing with this reentrancy would require some additional + mode switch for selection. Given that there seems to be no strong + reason to use the graph anyway, we stick with a simpler approach in + selection, and use the graph only for propagating default + implementations. + +Trait impl selection can succeed even when multiple impls can apply, +as long as they are part of the same specialization family. In that +case, it returns a *single* impl on success – this is the most +specialized impl *known* to apply. However, if there are any inference +variables in play, the returned impl may not be the actual impl we +will use at trans time. Thus, we take special care to avoid projecting +associated types unless either (1) the associated type does not use +`default` and thus cannot be overridden or (2) all input types are +known concretely. From 93958df2e771476fbf999460a9273a23d54dcd2d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Feb 2018 17:22:23 -0600 Subject: [PATCH 0104/1812] Clarifications and edits to hrtb chapter --- src/trait-caching.md | 1 - src/trait-hrtb.md | 41 +++++++++++++++++++++++++---------------- 2 files changed, 25 insertions(+), 17 deletions(-) diff --git a/src/trait-caching.md b/src/trait-caching.md index 6a0e55b27..31f398ff5 100644 --- a/src/trait-caching.md +++ b/src/trait-caching.md @@ -51,4 +51,3 @@ and draw finer-grained distinctions, but that led to a serious of annoying and weird bugs like #22019 and #18290. This simple rule seems to be pretty clearly safe and also still retains a very high hit rate (~95% when compiling rustc). - diff --git a/src/trait-hrtb.md b/src/trait-hrtb.md index f0c47d942..8c3a6f4e9 100644 --- a/src/trait-hrtb.md +++ b/src/trait-hrtb.md @@ -1,14 +1,13 @@ # Higher-ranked trait bounds -One of the more subtle concepts at work are *higher-ranked trait +One of the more subtle concepts in trait resolution is *higher-ranked trait bounds*. An example of such a bound is `for<'a> MyTrait<&'a isize>`. Let's walk through how selection on higher-ranked trait references works. ## Basic matching and skolemization leaks -Let's walk through the test `compile-fail/hrtb-just-for-static.rs` to see -how it works. The test starts with the trait `Foo`: +Suppose we have a trait `Foo`: ```rust trait Foo { @@ -33,25 +32,34 @@ impl<'a> Foo<&'a isize> for AnyInt { } And the question is, does `AnyInt : for<'a> Foo<&'a isize>`? We want the answer to be yes. The algorithm for figuring it out is closely related -to the subtyping for higher-ranked types (which is described in -`middle::infer::higher_ranked::doc`, but also in a [paper by SPJ] that -I recommend you read). +to the subtyping for higher-ranked types (which is described in [here][hrsubtype] +and also in a [paper by SPJ]. If you wish to understand higher-ranked +subtyping, we recommend you read the paper). There are a few parts: -1. Skolemize the obligation. +**TODO**: We should define _skolemize_. + +1. _Skolemize_ the obligation. 2. Match the impl against the skolemized obligation. -3. Check for skolemization leaks. +3. Check for _skolemization leaks_. +[hrsubtype]: https://github.com/rust-lang/rust/tree/master/src/librustc/infer/higher_ranked/README.md [paper by SPJ]: http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ -So let's work through our example. The first thing we would do is to +So let's work through our example. + +1. The first thing we would do is to skolemize the obligation, yielding `AnyInt : Foo<&'0 isize>` (here `'0` -represents skolemized region #0). Note that now have no quantifiers; +represents skolemized region #0). Note that we now have no quantifiers; in terms of the compiler type, this changes from a `ty::PolyTraitRef` to a `TraitRef`. We would then create the `TraitRef` from the impl, using fresh variables for it's bound regions (and thus getting -`Foo<&'$a isize>`, where `'$a` is the inference variable for `'a`). Next +`Foo<&'$a isize>`, where `'$a` is the inference variable for `'a`). + +2. Next we relate the two trait refs, yielding a graph with the constraint -that `'0 == '$a`. Finally, we check for skolemization "leaks" – a +that `'0 == '$a`. + +3. Finally, we check for skolemization "leaks" – a leak is basically any attempt to relate a skolemized region to another skolemized region, or to any region that pre-existed the impl match. The leak check is done by searching from the skolemized region to find @@ -75,6 +83,8 @@ skolemized to `'0` and the impl trait reference is instantiated to like `'static == '0`. This means that the taint set for `'0` is `{'0, 'static}`, which fails the leak check. +**TODO**: This is because `'static` is not a region variable but is in the taint set, right? + ## Higher-ranked trait obligations Once the basic matching is done, we get to another interesting topic: @@ -96,9 +106,9 @@ impl Foo for F } ``` -Now let's say we have a obligation `for<'a> Foo<&'a isize>` and we match +Now let's say we have a obligation `Baz: for<'a> Foo<&'a isize>` and we match this impl. What obligation is generated as a result? We want to get -`for<'a> Bar<&'a isize>`, but how does that happen? +`Baz: for<'a> Bar<&'a isize>`, but how does that happen? After the matching, we are in a position where we have a skolemized substitution like `X => &'0 isize`. If we apply this substitution to the @@ -112,5 +122,4 @@ from. (This is done in `higher_ranked::plug_leaks`). We know that the leak check passed, so this taint set consists solely of the skolemized region itself plus various intermediate region variables. We then walk the trait-reference and convert every region in that taint set back to -a late-bound region, so in this case we'd wind up with `for<'a> F : -Bar<&'a isize>`. +a late-bound region, so in this case we'd wind up with `Baz: for<'a> Bar<&'a isize>`. From 0236316fb29925fd51d8666a487e74333b9f03c2 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Feb 2018 17:49:56 -0600 Subject: [PATCH 0105/1812] Edits and cleanup in trait-caching subchapter --- src/trait-caching.md | 44 ++++++++++++++++++++++++++++---------------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/src/trait-caching.md b/src/trait-caching.md index 31f398ff5..ee92814cd 100644 --- a/src/trait-caching.md +++ b/src/trait-caching.md @@ -1,6 +1,6 @@ # Caching and subtle considerations therewith -In general we attempt to cache the results of trait selection. This +In general, we attempt to cache the results of trait selection. This is a somewhat complex process. Part of the reason for this is that we want to be able to cache results even when all the types in the trait reference are not fully known. In that case, it may happen that the @@ -12,37 +12,43 @@ but *replay* its effects on the type variables. The high-level idea of how the cache works is that we first replace all unbound inference variables with skolemized versions. Therefore, -if we had a trait reference `usize : Foo<$1>`, where `$n` is an unbound -inference variable, we might replace it with `usize : Foo<%0>`, where -`%n` is a skolemized type. We would then look this up in the cache. +if we had a trait reference `usize : Foo<$t>`, where `$t` is an unbound +inference variable, we might replace it with `usize : Foo<$0>`, where +`$0` is a skolemized type. We would then look this up in the cache. + If we found a hit, the hit would tell us the immediate next step to -take in the selection process: i.e. apply impl #22, or apply where -clause `X : Foo`. Let's say in this case there is no hit. -Therefore, we search through impls and where clauses and so forth, and -we come to the conclusion that the only possible impl is this one, -with def-id 22: +take in the selection process (e.g. apply impl #22, or apply where +clause `X : Foo`). + +On the other hand, if there is no hit, we need to go through the [selection +process] from scratch. Suppose, we come to the conclusion that the only +possible impl is this one, with def-id 22: + +[selection process]: ./trait-resolution.html#selection ```rust impl Foo for usize { ... } // Impl #22 ``` -We would then record in the cache `usize : Foo<%0> ==> -ImplCandidate(22)`. Next we would confirm `ImplCandidate(22)`, which -would (as a side-effect) unify `$1` with `isize`. +We would then record in the cache `usize : Foo<$0> => ImplCandidate(22)`. Next +we would [confirm] `ImplCandidate(22)`, which would (as a side-effect) unify +`$t` with `isize`. + +[confirm]: ./trait-resolution.html#confirmation Now, at some later time, we might come along and see a `usize : -Foo<$3>`. When skolemized, this would yield `usize : Foo<%0>`, just as +Foo<$u>`. When skolemized, this would yield `usize : Foo<$0>`, just as before, and hence the cache lookup would succeed, yielding `ImplCandidate(22)`. We would confirm `ImplCandidate(22)` which would -(as a side-effect) unify `$3` with `isize`. +(as a side-effect) unify `$u` with `isize`. ## Where clauses and the local vs global cache One subtle interaction is that the results of trait lookup will vary depending on what where clauses are in scope. Therefore, we actually have *two* caches, a local and a global cache. The local cache is -attached to the `ParamEnv` and the global cache attached to the -`tcx`. We use the local cache whenever the result might depend on the +attached to the [`ParamEnv`], and the global cache attached to the +[`tcx`]. We use the local cache whenever the result might depend on the where clauses that are in scope. The determination of which cache to use is done by the method `pick_candidate_cache` in `select.rs`. At the moment, we use a very simple, conservative rule: if there are any @@ -51,3 +57,9 @@ and draw finer-grained distinctions, but that led to a serious of annoying and weird bugs like #22019 and #18290. This simple rule seems to be pretty clearly safe and also still retains a very high hit rate (~95% when compiling rustc). + +**TODO**: it looks like `pick_candidate_cache` no longer exists. In +general, is this section still accurate at all? + +[`ParamEnv`]: ./param_env.html +[`tcx`]: ./ty.html From a0ddc8aa8aa250580acfd9218022f3f95ec6284f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Feb 2018 17:55:06 -0600 Subject: [PATCH 0106/1812] Minor updates to specialization subchapter --- src/trait-specialization.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/trait-specialization.md b/src/trait-specialization.md index 6b8bc64dd..671e5e016 100644 --- a/src/trait-specialization.md +++ b/src/trait-specialization.md @@ -1,9 +1,12 @@ # Specialization +**TODO**: where does Chalk fit in? Should we mention/discuss it here? + Defined in the `specialize` module. The basic strategy is to build up a *specialization graph* during -coherence checking. Insertion into the graph locates the right place +coherence checking (recall that coherence checking looks for overlapping +impls). Insertion into the graph locates the right place to put an impl in the specialization hierarchy; if there is no right place (due to partial overlap but no containment), you get an overlap error. Specialization is consulted when selecting an impl (of course), From bfcdce6604b3ddc3f97146cbb8fbbce1588b2de1 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 23 Feb 2018 10:18:16 -0800 Subject: [PATCH 0107/1812] Add some more information about the various tests that get run. CC #10 --- src/tests/intro.md | 74 ++++++++++++++++++++++++++++++++++++++------ src/tests/running.md | 7 ----- 2 files changed, 65 insertions(+), 16 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index 615673206..2388e4308 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -1,17 +1,18 @@ -# Using the compiler testing framework +# The compiler testing framework -The compiler has an extensive testing framework, masterminded by the -compiletest tool (sources in the [`src/tools/compiletest`]). This -section gives a brief overview of how the testing framework is setup, -and then gets into some of the details on -[how to run tests](./tests/running.html#ui) as well as -[how to add new tests](./tests/adding.html). +The Rust project runs a wide variety of different tests, orchestrated by the +build system (`x.py test`). The main test harness for testing the compiler +itself is a tool called compiletest (sources in the +[`src/tools/compiletest`]). This section gives a brief overview of how the +testing framework is setup, and then gets into some of the details on [how to +run tests](./tests/running.html#ui) as well as [how to add new +tests](./tests/adding.html). [`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest -## Test suites +## Compiletest test suites -The tests are located in the tree in the [`src/test`] +The compiletest tests are located in the tree in the [`src/test`] directory. Immediately within you will see a series of subdirectories (e.g. `ui`, `run-make`, and so forth). Each of those directories is called a **test suite** -- they house a group of tests that are run in @@ -48,6 +49,61 @@ that give more details. - `*-fulldeps` -- same as above, but indicates that the test depends on things other than `libstd` (and hence those things must be built) +## Other Tests + +The Rust build system handles running tests for various other things, +including: + +- **Tidy** -- This is a custom tool used for validating source code style and + formatting conventions, such as rejecting long lines. There is more + information in the [section on coding conventions](./conventions.html#formatting). + + Example: `./x.py test src/tools/tidy` + +- **Unittests** -- The Rust standard library and many of the Rust packages + include typical Rust `#[test]` unittests. Under the hood, `x.py` will run + `cargo test` on each package to run all the tests. + + Example: `./x.py test src/libstd` + +- **Doctests** -- Example code embedded within Rust documentation is executed + via `rustdoc --test`. Examples: + + `./x.py test src/doc` -- Runs `rustdoc --test` for all documentation in + `src/doc`. + + `./x.py test --doc src/libstd` -- Runs `rustdoc --test` on the standard + library. + +- **Linkchecker** -- A small tool for verifying `href` links within + documentation. + + Example: `./x.py test src/tools/linkchecker` + +- **Distcheck** -- This verifies that the source distribution tarball created + by the build system will unpack, build, and run all tests. + + Example: `./x.py test distcheck` + +- **Tool tests** -- Packages that are included with Rust have all of their + tests run as well (typically by running `cargo test` within their + directory). This includes things such as cargo, clippy, rustfmt, rls, miri, + bootstrap (testing the Rust build system itself), etc. + +- **Cargotest** -- This is a small tool which runs `cargo test` on a few + significant projects (such as `servo`, `ripgrep`, `tokei`, etc.) just to + ensure there aren't any significant regressions. + + Example: `./x.py test src/tools/cargotest` + +## Testing infrastructure + +TODO - bors, platforms, etc. + +## Crater + +TODO + ## Further reading The following blog posts may also be of interest: diff --git a/src/tests/running.md b/src/tests/running.md index 602aa51d9..98d590671 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -13,13 +13,6 @@ a very long time, and anyway bors / travis will do it for you. (Often, I will run this command in the background after opening a PR that I think is done, but rarely otherwise. -nmatsakis) -## Tidy - -When you run the full suite of tests via `./x.py test`, the first -thing that executes is a "tidy suite" that checks for long lines and -other formatting conventions. There is more information in the -[section on coding conventions](./conventions.html#formatting). - ## Running a subset of the test suites When working on a specific PR, you will usually want to run a smaller From b35bd94e82a8fa093f76cf8f697e1671b9a9bf00 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 13 Feb 2018 11:17:45 -0600 Subject: [PATCH 0108/1812] Start a code index --- src/SUMMARY.md | 1 + src/code-index.md | 9 +++++++++ 2 files changed, 10 insertions(+) create mode 100644 src/code-index.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ea2a6cd98..04904bce7 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -28,3 +28,4 @@ - [Parameter Environments](./param_env.md) - [Generating LLVM IR](./trans.md) - [Glossary](./glossary.md) +- [Code Index](./code-index.md) diff --git a/src/code-index.md b/src/code-index.md new file mode 100644 index 000000000..5b452ef0f --- /dev/null +++ b/src/code-index.md @@ -0,0 +1,9 @@ +# Code Index + +rustc has a lot of important data structures. This is an attempt to give some +guidance on where to learn more about some of the key data structures of the +compiler. + +Item | Kind | Short description | Chapter | Declaration +----------------|----------|-----------------------------|--------------------|------------------- +`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) From 9f0be41a06a0d8f9afbf3db5eff6213c2e2a15da Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Feb 2018 13:17:29 -0600 Subject: [PATCH 0109/1812] Add HIR MAP to glossary --- src/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/glossary.md b/src/glossary.md index 34b4bd446..13567a428 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -13,6 +13,7 @@ DAG | a directed acyclic graph is used during compilation t DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. HIR | the High-level IR, created by lowering and desugaring the AST ([see more](hir.html)) HirId | identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". +HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. 'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item ICE | internal compiler error. When the compiler crashes. From 18e8e255518a543fabd3c49de125311877f8cf58 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 15 Feb 2018 12:46:42 -0600 Subject: [PATCH 0110/1812] Add some codegen related terminology to glossary --- src/glossary.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/src/glossary.md b/src/glossary.md index a770bdf8e..5d76cf3cf 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -11,19 +11,20 @@ completeness | completeness is a technical term in type theory. Comp cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. +'gcx | the lifetime of the global arena ([see more](ty.html)) +generics | the set of generic type parameters defined on a type or item HIR | the High-level IR, created by lowering and desugaring the AST ([see more](hir.html)) HirId | identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. -'gcx | the lifetime of the global arena ([see more](ty.html)) -generics | the set of generic type parameters defined on a type or item ICE | internal compiler error. When the compiler crashes. ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. infcx | the inference context (see `librustc/infer`) -MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) -miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) -obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) +IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. local crate | the crate currently being compiled. +LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optmizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] +[LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) +miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) provider | the function that executes a query ([see more](query.html)) @@ -38,6 +39,12 @@ substs | the substitutions for a given generic type or item (e tcx | the "typing context", main data structure of the compiler ([see more](ty.html)) 'tcx | the lifetime of the currently active inference context ([see more](ty.html)) token | the smallest unit of parsing. Tokens are produced after lexing ([see more](the-parser.html)). +[TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. trans | the code to translate MIR into LLVM IR. trait reference | a trait and values for its type parameters ([see more](ty.html)). ty | the internal representation of a type ([see more](ty.html)). + +[LLVM]: https://llvm.org/ +[lto]: https://llvm.org/docs/LinkTimeOptimization.html +[thinlto]: https://clang.llvm.org/docs/ThinLTO.html +[TLS]: https://llvm.org/docs/LangRef.html#thread-local-storage-models From ae39f92b66c8d7e4513f8340c857c67d1e283613 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 24 Feb 2018 12:50:48 -0800 Subject: [PATCH 0111/1812] Start documentation for test infrastructure. CC #10 --- src/tests/intro.md | 67 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index 2388e4308..8ad2492b7 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -98,7 +98,72 @@ including: ## Testing infrastructure -TODO - bors, platforms, etc. +When a Pull Request is opened on Github, [Travis] will automatically launch a +build that will run all tests on a single configuration (x86-64 linux). In +essence, it runs `./x.py test` after building. + +The integration bot [bors] is used for coordinating merges to the master +branch. When a PR is approved, it goes into a [queue] where merges are tested +one at a time on a wide set of platforms using Travis and [Appveyor] +(currently over 50 different configurations). Most platforms only run the +build steps, some run a restricted set of tests, only a subset run the full +suite of tests (see Rust's [platform tiers]). + +[Travis]: https://travis-ci.org/rust-lang/rust +[bors]: https://github.com/servo/homu +[queue]: https://buildbot2.rust-lang.org/homu/queue/rust +[Appveyor]: https://ci.appveyor.com/project/rust-lang/rust +[platform tiers]: https://forge.rust-lang.org/platform-support.html + +## Testing with Docker images + +The Rust tree includes [Docker] image definitions for the platforms used on +Travis in [src/ci/docker]. The script [src/ci/docker/run.sh] is used to build +the Docker image, run it, build Rust within the image, and run the tests. + +> TODO: What is a typical workflow for testing/debugging on a platform that +> you don't have easy access to? Do people build Docker images and enter them +> to test things out? + +[Docker]: https://www.docker.com/ +[src/ci/docker]: https://github.com/rust-lang/rust/tree/master/src/ci/docker +[src/ci/docker/run.sh]: https://github.com/rust-lang/rust/blob/master/src/ci/docker/run.sh + +## Testing on emulators + +Some platforms are tested via an emulator for architectures that aren't +readily available. There is a set of tools for orchestrating running the +tests within the emulator. Platforms such as `arm-android` and +`arm-unknown-linux-gnueabihf` are set up to automatically run the tests under +emulation on Travis. The following will take a look at how a target's tests +are run under emulation. + +The Docker image for [armhf-gnu] includes [QEMU] to emulate the ARM CPU +architecture. Included in the Rust tree are the tools [remote-test-client] +and [remote-test-server] which are programs for sending test programs and +libraries to the emulator, and running the tests within the emulator, and +reading the results. The Docker image is set up to launch +`remote-test-server` and the build tools use `remote-test-client` to +communicate with the server to coordinate running tests (see +[src/bootstrap/test.rs]). + +> TODO: What are the steps for manually running tests within an emulator? +> `./src/ci/docker/run.sh armhf-gnu` will do everything, but takes hours to +> run and doesn't offer much help with interacting within the emulator. +> +> Is there any support for emulating other (non-Android) platforms, such as +> running on an iOS emulator? +> +> Is there anything else interesting that can be said here about running tests +> remotely on real hardware? +> +> It's also unclear to me how the wasm or asm.js tests are run. + +[armhf-gnu]: https://github.com/rust-lang/rust/tree/master/src/ci/docker/armhf-gnu +[QEMU]: https://www.qemu.org/ +[remote-test-client]: https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-client +[remote-test-server]: https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-server +[src/bootstrap/test.rs]: https://github.com/rust-lang/rust/tree/master/src/bootstrap/test.rs ## Crater From 54873601a80b829ccee7a8f05c84a057842de89b Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 24 Feb 2018 17:14:56 -0500 Subject: [PATCH 0112/1812] rework the MIR intro section, breaking out passes and visitors --- src/SUMMARY.md | 4 + src/background.md | 122 ++++++++++++++ src/glossary.md | 2 + src/mir-background.md | 122 ++++++++++++++ src/mir-borrowck.md | 57 ++++++- src/mir-passes.md | 169 +++++++++++++++++++ src/mir-regionck.md | 376 ++++++++++++++++++++++++++++++++++++++++++ src/mir-visitor.md | 45 +++++ src/mir.md | 303 +++++++++++++++++++++++++--------- 9 files changed, 1121 insertions(+), 79 deletions(-) create mode 100644 src/background.md create mode 100644 src/mir-background.md create mode 100644 src/mir-passes.md create mode 100644 src/mir-regionck.md create mode 100644 src/mir-visitor.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4ead05705..29ad79998 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -24,11 +24,15 @@ - [Type checking](./type-checking.md) - [The MIR (Mid-level IR)](./mir.md) - [MIR construction](./mir-construction.md) + - [MIR visitor](./mir-visitor.md) + - [MIR passes: getting the MIR for a function](./mir-passes.md) - [MIR borrowck](./mir-borrowck.md) + - [MIR-based region checking (NLL)](./mir-regionck.md) - [MIR optimizations](./mir-optimizations.md) - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) - [Generating LLVM IR](./trans.md) +- [Background material](./background.md) - [Glossary](./glossary.md) - [Code Index](./code-index.md) diff --git a/src/background.md b/src/background.md new file mode 100644 index 000000000..92ae6507a --- /dev/null +++ b/src/background.md @@ -0,0 +1,122 @@ +# Background topics + +This section covers a numbers of common compiler terms that arise in +this guide. We try to give the general definition while providing some +Rust-specific context. + + + +## What is a control-flow graph? + +A control-flow graph is a common term from compilers. If you've ever +used a flow-chart, then the concept of a control-flow graph will be +pretty familiar to you. It's a representation of your program that +exposes the underlying control flow in a very clear way. + +A control-flow graph is structured as a set of **basic blocks** +connected by edges. The key idea of a basic block is that it is a set +of statements that execute "together" -- that is, whenever you branch +to a basic block, you start at the first statement and then execute +all the remainder. Only at the end of the is there the possibility of +branching to more than one place (in MIR, we call that final statement +the **terminator**): + +``` +bb0: { + statement0; + statement1; + statement2; + ... + terminator; +} +``` + +Many expressions that you are used to in Rust compile down to multiple +basic blocks. For example, consider an if statement: + +```rust +a = 1; +if some_variable { + b = 1; +} else { + c = 1; +} +d = 1; +``` + +This would compile into four basic blocks: + +``` +BB0: { + a = 1; + if some_variable { goto BB1 } else { goto BB2 } +} + +BB1: { + b = 1; + goto BB3; +} + +BB2: { + c = 1; + goto BB3; +} + +BB3: { + d = 1; + ...; +} +``` + +When using a control-flow graph, a loop simply appears as a cycle in +the graph, and the `break` keyword translates into a path out of that +cycle. + + + +## What is a dataflow analysis? + +*to be written* + + + +## What is "universally quantified"? What about "existentially quantified"? + +*to be written* + + + +## What is co- and contra-variance? + +*to be written* + + + +## What is a "free region" or a "free variable"? What about "bound region"? + +Let's describe the concepts of free vs bound in terms of program +variables, since that's the thing we're most familiar with. + +- Consider this expression: `a + b`. In this expression, `a` and `b` + refer to local variables that are defined *outside* of the + expression. We say that those variables **appear free** in the + expression. To see why this term makes sense, consider the next + example. +- In contrast, consider this expression, which creates a closure: `|a, + b| a + b`. Here, the `a` and `b` in `a + b` refer to the arguments + that the closure will be given when it is called. We say that the + `a` and `b` there are **bound** to the closure, and that the closure + signature `|a, b|` is a **binder** for the names `a` and `b` + (because any references to `a` or `b` within refer to the variables + that it introduces). + +So there you have it: a variable "appears free" in some +expression/statement/whatever if it refers to something defined +outside of that expressions/statement/whatever. Equivalently, we can +then refer to the "free variables" of an expression -- which is just +the set of variables that "appear free". + +So what does this have to do with regions? Well, we can apply the +analogous concept to type and regions. For example, in the type `&'a +u32`, `'a` appears free. But in the type `for<'a> fn(&'a u32)`, it +does not. diff --git a/src/glossary.md b/src/glossary.md index 5d76cf3cf..2aa9b52f1 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -18,6 +18,7 @@ HirId | identifies a particular node in the HIR by combining HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. ICE | internal compiler error. When the compiler crashes. ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. +inference variable | when doing type or region inference, an "inference variable" is a kind of special type/region that represents value you are trying to find. Think of `X` in algebra. infcx | the inference context (see `librustc/infer`) IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. local crate | the crate currently being compiled. @@ -25,6 +26,7 @@ LTO | Link-Time Optimizations. A set of optimizations offer [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) +newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) provider | the function that executes a query ([see more](query.html)) diff --git a/src/mir-background.md b/src/mir-background.md new file mode 100644 index 000000000..38fba5d16 --- /dev/null +++ b/src/mir-background.md @@ -0,0 +1,122 @@ +# MIR Background topics + +This section covers a numbers of common compiler terms that arise when +talking about MIR and optimizations. We try to give the general +definition while providing some Rust-specific context. + + + +## What is a control-flow graph? + +A control-flow graph is a common term from compilers. If you've ever +used a flow-chart, then the concept of a control-flow graph will be +pretty familiar to you. It's a representation of your program that +exposes the underlying control flow in a very clear way. + +A control-flow graph is structured as a set of **basic blocks** +connected by edges. The key idea of a basic block is that it is a set +of statements that execute "together" -- that is, whenever you branch +to a basic block, you start at the first statement and then execute +all the remainder. Only at the end of the is there the possibility of +branching to more than one place (in MIR, we call that final statement +the **terminator**): + +``` +bb0: { + statement0; + statement1; + statement2; + ... + terminator; +} +``` + +Many expressions that you are used to in Rust compile down to multiple +basic blocks. For example, consider an if statement: + +```rust +a = 1; +if some_variable { + b = 1; +} else { + c = 1; +} +d = 1; +``` + +This would compile into four basic blocks: + +``` +BB0: { + a = 1; + if some_variable { goto BB1 } else { goto BB2 } +} + +BB1: { + b = 1; + goto BB3; +} + +BB2: { + c = 1; + goto BB3; +} + +BB3: { + d = 1; + ...; +} +``` + +When using a control-flow graph, a loop simply appears as a cycle in +the graph, and the `break` keyword translates into a path out of that +cycle. + + + +## What is a dataflow analysis? + +*to be written* + + + +## What is "universally quantified"? What about "existentially quantified"? + +*to be written* + + + +## What is co- and contra-variance? + +*to be written* + + + +## What is a "free region" or a "free variable"? What about "bound region"? + +Let's describe the concepts of free vs bound in terms of program +variables, since that's the thing we're most familiar with. + +- Consider this expression: `a + b`. In this expression, `a` and `b` + refer to local variables that are defined *outside* of the + expression. We say that those variables **appear free** in the + expression. To see why this term makes sense, consider the next + example. +- In contrast, consider this expression, which creates a closure: `|a, + b| a + b`. Here, the `a` and `b` in `a + b` refer to the arguments + that the closure will be given when it is called. We say that the + `a` and `b` there are **bound** to the closure, and that the closure + signature `|a, b|` is a **binder** for the names `a` and `b` + (because any references to `a` or `b` within refer to the variables + that it introduces). + +So there you have it: a variable "appears free" in some +expression/statement/whatever if it refers to something defined +outside of that expressions/statement/whatever. Equivalently, we can +then refer to the "free variables" of an expression -- which is just +the set of variables that "appear free". + +So what does this have to do with regions? Well, we can apply the +analogous concept to type and regions. For example, in the type `&'a +u32`, `'a` appears free. But in the type `for<'a> fn(&'a u32)`, it +does not. diff --git a/src/mir-borrowck.md b/src/mir-borrowck.md index 55bc9fc98..b632addc2 100644 --- a/src/mir-borrowck.md +++ b/src/mir-borrowck.md @@ -1 +1,56 @@ -# MIR borrowck +# MIR borrow check + +The borrow check is Rust's "secret sauce" -- it is tasked with +enforcing a number of properties: + +- That all variables are initialized before they are used. +- That you can't move the same value twice. +- That you can't move a value while it is borrowed. +- That you can't access a place while it is mutably borrowed (except through the reference). +- That you can't mutate a place while it is shared borrowed. +- etc + +At the time of this writing, the code is in a state of transition. The +"main" borrow checker still works by processing [the HIR](hir.html), +but that is being phased out in favor of the MIR-based borrow checker. +Doing borrow checking on MIR has two key advantages: + +- The MIR is *far* less complex than the HIR; the radical desugaring + helps prevent bugs in the borrow checker. (If you're curious, you + can see + [a list of bugs that the MIR-based borrow checker fixes here][47366].) +- Even more importantly, using the MIR enables ["non-lexical lifetimes"][nll], + which are regions derived from the control-flow graph. + +[47366]: https://github.com/rust-lang/rust/issues/47366 +[nll]: http://rust-lang.github.io/rfcs/2094-nll.html + +### Major phases of the borrow checker + +The borrow checker source is found in +[the `rustc_mir::borrow_check` module][b_c]. The main entry point is +the `mir_borrowck` query. At the time of this writing, MIR borrowck can operate +in several modes, but this text will describe only the mode when NLL is enabled +(what you get with `#![feature(nll)]`). + +[b_c]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check + +The overall flow of the borrow checker is as follows: + +- We first create a **local copy** C of the MIR. We will be modifying + this copy in place to modify the types and things to include + references to the new regions that we are computing. +- We then invoke `nll::replace_regions_in_mir` to modify this copy C. + Among other things, this function will replace all of the regions in + the MIR with fresh [inference variables](glossary.html). + - (More details can be found in [the regionck section](./mir-regionck.html).) +- Next, we perform a number of [dataflow analyses](./background.html#dataflow) + that compute what data is moved and when. The results of these analyses + are needed to do both borrow checking and region inference. +- Using the move data, we can then compute the values of all the regions in the MIR. + - (More details can be found in [the NLL section](./mir-regionck.html).) +- Finally, the borrow checker itself runs, taking as input (a) the + results of move analysis and (b) the regions computed by the region + checker. This allows is to figure out which loans are still in scope + at any particular point. + diff --git a/src/mir-passes.md b/src/mir-passes.md new file mode 100644 index 000000000..2fe471385 --- /dev/null +++ b/src/mir-passes.md @@ -0,0 +1,169 @@ +# MIR passes + +If you would like to get the MIR for a function (or constant, etc), +you can use the `optimized_mir(def_id)` query. This will give you back +the final, optimized MIR. For foreign def-ids, we simply read the MIR +from the other crate's metadata. But for local def-ids, the query will +construct the MIR and then iteratively optimize it by putting it +through various pipeline stages. This section describes those pipeline +stages and how you can extend them. + +To produce the `optimized_mir(D)` for a given def-id `D`, the MIR +passes through several suites of optimizations, each represented by a +query. Each suite consists of multiple optimizations and +transformations. These suites represent useful intermediate points +where we want to access the MIR for type checking or other purposes: + +- `mir_build(D)` – not a query, but this constructs the initial MIR +- `mir_const(D)` – applies some simple transformations to make MIR ready for constant evaluation; +- `mir_validated(D)` – applies some more transformations, making MIR ready for borrow checking; +- `optimized_mir(D)` – the final state, after all optimizations have been performed. + +### Seeing how the MIR changes as the compiler executes + +`-Zdump-mir=F` is a handy compiler options that will let you view the MIR +for each function at each stage of compilation. `-Zdump-mir` takes a **filter** +`F` which allows you to control which functions and which passes you are interesting +in. For example: + +```bash +> rustc -Zdump-mir=foo ... +``` + +This will dump the MIR for any function whose name contains `foo`; it +will dump the MIR both before and after every pass. Those files will +be created in the `mir_dump` directory. There will likely be quite a +lot of them! + +```bash +> cat > foo.rs +fn main() { + println!("Hello, world!"); +} +^D +> rustc -Zdump-mir=main foo.rs +> ls mir_dump/* | wc -l + 161 +``` + +The files have names like `rustc.main.000-000.CleanEndRegions.after.mir`. These +names have a number of parts: + +``` +rustc.main.000-000.CleanEndRegions.after.mir + ---- --- --- --------------- ----- either before or after + | | | name of the pass + | | index of dump within the pass (usually 0, but some passes dump intermediate states) + | index of the pass + def-path to the function etc being dumped +``` + +You can also make more selective filters. For example, `main & CleanEndRegions` will select +for things that reference *both* `main` and the pass `CleanEndRegions`: + +```bash +> rustc -Zdump-mir='main & CleanEndRegions' foo.rs +> ls mir_dump +rustc.main.000-000.CleanEndRegions.after.mir rustc.main.000-000.CleanEndRegions.before.mir +``` + +Filters can also have `|` parts to combine multiple sets of +`&`-filters. For example `main & CleanEndRegions | main & +NoLandingPads` will select *either* `main` and `CleanEndRegions` *or* +`main` and `NoLandingPads`: + +```bash +> rustc -Zdump-mir='main & CleanEndRegions | main & NoLandingPads' foo.rs +> ls mir_dump +rustc.main-promoted[0].002-000.NoLandingPads.after.mir +rustc.main-promoted[0].002-000.NoLandingPads.before.mir +rustc.main-promoted[0].002-006.NoLandingPads.after.mir +rustc.main-promoted[0].002-006.NoLandingPads.before.mir +rustc.main-promoted[1].002-000.NoLandingPads.after.mir +rustc.main-promoted[1].002-000.NoLandingPads.before.mir +rustc.main-promoted[1].002-006.NoLandingPads.after.mir +rustc.main-promoted[1].002-006.NoLandingPads.before.mir +rustc.main.000-000.CleanEndRegions.after.mir +rustc.main.000-000.CleanEndRegions.before.mir +rustc.main.002-000.NoLandingPads.after.mir +rustc.main.002-000.NoLandingPads.before.mir +rustc.main.002-006.NoLandingPads.after.mir +rustc.main.002-006.NoLandingPads.before.mir +``` + +(Here, the `main-promoted[0]` files refer to the MIR for "promoted constants" +that appeared within the `main` function.) + +### Implementing and registering a pass + +A `MirPass` is some bit of code that processes the MIR, typically -- +but not always -- transforming it along the way in some way. For +example, it might perform an optimization. The `MirPass` trait itself +is found in in [the `rustc_mir::transform` module][mirtransform], and +it basically consists of one method, `run_pass`, that simply gets an +`&mut Mir` (along with the tcx and some information about where it +came from). + +A good example of a basic MIR pass is [`NoLandingPads`], which walks the +MIR and removes all edges that are due to unwinding -- this is used +with when configured with `panic=abort`, which never unwinds. As you can see +from its source, a MIR pass is defined by first defining a dummy type, a struct +with no fields, something like: + +```rust +struct MyPass; +``` + +for which you then implement the `MirPass` trait. You can then insert +this pass into the appropriate list of passes found in a query like +`optimized_mir`, `mir_validated`, etc. (If this is an optimization, it +should go into the `optimized_mir` list.) + +If you are writing a pass, there's a good chance that you are going to +want to use a [MIR visitor] too -- those are a handy visitor that +walks the MIR for you and lets you make small edits here and there. + +### Stealing + +The intermediate queries `mir_const()` and `mir_validated()` yield up +a `&'tcx Steal>`, allocated using +`tcx.alloc_steal_mir()`. This indicates that the result may be +**stolen** by the next suite of optimizations – this is an +optimization to avoid cloning the MIR. Attempting to use a stolen +result will cause a panic in the compiler. Therefore, it is important +that you do not read directly from these intermediate queries except as +part of the MIR processing pipeline. + +Because of this stealing mechanism, some care must also be taken to +ensure that, before the MIR at a particular phase in the processing +pipeline is stolen, anyone who may want to read from it has already +done so. Concretely, this means that if you have some query `foo(D)` +that wants to access the result of `mir_const(D)` or +`mir_validated(D)`, you need to have the successor pass "force" +`foo(D)` using `ty::queries::foo::force(...)`. This will force a query +to execute even though you don't directly require its result. + +As an example, consider MIR const qualification. It wants to read the +result produced by the `mir_const()` suite. However, that result will +be **stolen** by the `mir_validated()` suite. If nothing was done, +then `mir_const_qualif(D)` would succeed if it came before +`mir_validated(D)`, but fail otherwise. Therefore, `mir_validated(D)` +will **force** `mir_const_qualif` before it actually steals, thus +ensuring that the reads have already happened: + +``` +mir_const(D) --read-by--> mir_const_qualif(D) + | ^ + stolen-by | + | (forces) + v | +mir_validated(D) ------------+ +``` + +This mechanism is a bit dodgy. There is a discussion of more elegant +alternatives in [rust-lang/rust#41710]. + +[rust-lang/rust#41710]: https://github.com/rust-lang/rust/issues/41710 +[mirtransform]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/transform/mod.rs +[`NoLandingPads`]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/transform/no_landing_pads.rs +[MIR visitor]: mir-visitor.html diff --git a/src/mir-regionck.md b/src/mir-regionck.md new file mode 100644 index 000000000..8be4fc8b9 --- /dev/null +++ b/src/mir-regionck.md @@ -0,0 +1,376 @@ +# MIR-based region checking (NLL) + +The MIR-based region checking code is located in +[the `rustc_mir::borrow_check::nll` module][nll]. (NLL, of course, +stands for "non-lexical lifetimes", a term that will hopefully be +deprecated once they become the standard kind of lifetime.) + +[nll]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check/nll + +The MIR-based region analysis consists of two major functions: + +- `replace_regions_in_mir`, invoked first, has two jobs: + - First, it analyzes the signature of the MIR and finds the set of + regions that appear in the MIR signature (e.g., `'a` in `fn + foo<'a>(&'a u32) { ... }`. These are called the "universal" or + "free" regions -- in particular, they are the regions that + [appear free][fvb] in the function body. + - Second, it replaces all the regions from the function body with + fresh inference variables. This is because (presently) those + regions are the results of lexical region inference and hence are + not of much interest. The intention is that -- eventually -- they + will be "erased regions" (i.e., no information at all), since we + don't be doing lexical region inference at all. +- `compute_regions`, invoked second: this is given as argument the + results of move analysis. It has the job of computing values for all + the inference variabes that `replace_regions_in_mir` introduced. + - To do that, it first runs the [MIR type checker](#mirtypeck). This + is basically a normal type-checker but specialized to MIR, which + is much simpler than full Rust of course. Running the MIR type + checker will however create **outlives constraints** between + region variables (e.g., that one variable must outlive another + one) to reflect the subtyping relationships that arise. + - It also adds **liveness constraints** that arise from where variables + are used. + - More details to come, though the [NLL RFC] also includes fairly thorough + (and hopefully readable) coverage. + +[fvb]: background.html#free-vs-bound +[NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html + +## Universal regions + +*to be written* -- explain the `UniversalRegions` type + +## Region variables and constraints + +*to be written* -- describe the `RegionInferenceContext` and +the role of `liveness_constraints` vs other `constraints`, plus + +## Closures + + + +## The MIR type-check + +## Representing the "values" of a region variable + +The value of a region can be thought of as a **set**; we call the +domain of this set a `RegionElement`. In the code, the value for all +regions is maintained in +[the `rustc_mir::borrow_check::nll::region_infer` module][ri]. For +each region we maintain a set storing what elements are present in its +value (to make this efficient, we give each kind of element an index, +the `RegionElementIndex`, and use sparse bitsets). + +[ri]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check/nll/region_infer/ + +The kinds of region elements are as follows: + +- Each **location** in the MIR control-flow graph: a location is just + the pair of a basic block and an index. This identifies the point + **on entry** to the statement with that index (or the terminator, if + the index is equal to `statements.len()`). +- There is an element `end('a)` for each universal region `'a`, + corresponding to some portion of the caller's (or caller's caller, + etc) control-flow graph. +- Similarly, there is an element denoted `end('static)` corresponding + to the remainder of program execution after this function returns. +- There is an element `!1` for each skolemized region `!1`. This + corresponds (intuitively) to some unknown set of other elements -- + for details on skolemization, see the section + [skolemization and universes](#skol). + +## Causal tracking + +*to be written* -- describe how we can extend the values of a variable + with causal tracking etc + + + +## Skolemization and universes + +(This section describes ongoing work that hasn't landed yet.) + +From time to time we have to reason about regions that we can't +concretely know. For example, consider this program: + +```rust +// A function that needs a static reference +fn foo(x: &'static u32) { } + +fn bar(f: for<'a> fn(&'a u32)) { + // ^^^^^^^^^^^^^^^^^^^ a function that can accept **any** reference + let x = 22; + f(&x); +} + +fn main() { + bar(foo); +} +``` + +This program ought not to type-check: `foo` needs a static reference +for its argument, and `bar` wants to be given a function that that +accepts **any** reference (so it can call it with something on its +stack, for example). But *how* do we reject it and *why*? + +### Subtyping and skolemization + +When we type-check `main`, and in particular the call `bar(foo)`, we +are going to wind up with a subtyping relationship like this one: + + fn(&'static u32) <: for<'a> fn(&'a u32) + ---------------- ------------------- + the type of `foo` the type `bar` expects + +We handle this sort of subtyping by taking the variables that are +bound in the supertype and **skolemizing** them: this means that we +replace them with +[universally quantified](background.html#quantified) +representatives, written like `!1`. We call these regions "skolemized +regions" -- they represent, basically, "some unknown region". + +Once we've done that replacement, we have the following types: + + fn(&'static u32) <: fn(&'!1 u32) + +The key idea here is that this unknown region `'!1` is not related to +any other regions. So if we can prove that the subtyping relationship +is true for `'!1`, then it ought to be true for any region, which is +what we wanted. (This number `!1` is called a "universe", for reasons +we'll get into later.) + +So let's work through what happens next. To check if two functions are +subtypes, we check if their arguments have the desired relationship +(fn arguments are [contravariant](./background.html#variance), so +we swap the left and right here): + + &'!1 u32 <: &'static u32 + +According to the basic subtyping rules for a reference, this will be +true if `'!1: 'static`. That is -- if "some unknown region `!1`" lives +outlives `'static`. Now, this *might* be true -- after all, `'!1` +could be `'static` -- but we don't *know* that it's true. So this +should yield up an error (eventually). + +### Universes and skolemized region elements + +But where does that error come from? The way it happens is like this. +When we are constructing the region inference context, we can tell +from the type inference context how many skolemized variables exist +(the `InferCtxt` has an internal counter). For each of those, we +create a corresponding universal region variable `!n` and a "region +element" `skol(n)`. This corresponds to "some unknown set of other +elements". The value of `!n` is `{skol(n)}`. + +At the same time, we also give each existential variable a +**universe** (also taken from the `InferCtxt`). This universe +determines which skolemized elements may appear in its value: For +example, a variable in universe U3 may name `skol(1)`, `skol(2)`, and +`skol(3)`, but not `skol(4)`. Note that the universe of an inference +variable controls what region elements **can** appear in its value; it +does not say region elements **will** appear. + +### Skolemization and outlives constraints + +In the region inference engine, outlives constraints have the form: + + V1: V2 @ P + +where `V1` and `V2` are region indices, and hence map to some region +variable (which may be universally or existentially quantified). This +variable will have a universe, so let's call those universes `U(V1)` +and `U(V2)` respectively. (Actually, the only one we are going to care +about is `U(V1)`.) + +When we encounter this constraint, the ordinary procedure is to start +a DFS from `P`. We keep walking so long as the nodes we are walking +are present in `value(V2)` and we add those nodes to `value(V1)`. If +we reach a return point, we add in any `end(X)` elements. That part +remains unchanged. + +But then *after that* we want to iterate over the skolemized `skol(u)` +elements in V2 (each of those must be visible to `U(V2)`, but we +should be able to just assume that is true, we don't have to check +it). We have to ensure that `value(V1)` outlives each of those +skolemized elements. + +Now there are two ways that could happen. First, if `U(V1)` can see +the universe `u` (i.e., `u <= U(V1)`), then we can just add `skol(u1)` +to `value(V1)` and be done. But if not, then we have to approximate: +we may not know what set of elements `skol(u1)` represents, but we +should be able to compute some sort of **upper bound** for it -- +something that it is smaller than. For now, we'll just use `'static` +for that (since it is bigger than everything) -- in the future, we can +sometimes be smarter here (and in fact we have code for doing this +already in other contexts). Moreover, since `'static` is in U0, we +know that all variables can see it -- so basically if we find a that +`value(V2)` contains `skol(u)` for some universe `u` that `V1` can't +see, then we force `V1` to `'static`. + +### Extending the "universal regions" check + +After all constraints have been propagated, the NLL region inference +has one final check, where it goes over the values that wound up being +computed for each universal region and checks that they did not get +'too large'. In our case, we will go through each skolemized region +and check that it contains *only* the `skol(u)` element it is known to +outlive. (Later, we might be able to know that there are relationships +between two skolemized regions and take those into account, as we do +for universal regions from the fn signature.) + +Put another way, the "universal regions" check can be considered to be +checking constraints like: + + {skol(1)}: V1 + +where `{skol(1)}` is like a constant set, and V1 is the variable we +made to represent the `!1` region. + +## Back to our example + +OK, so far so good. Now let's walk through what would happen with our +first example: + + fn(&'static u32) <: fn(&'!1 u32) @ P // this point P is not imp't here + +The region inference engine will create a region element domain like this: + + { CFG; end('static); skol(1) } + --- ------------ ------- from the universe `!1` + | 'static is always in scope + all points in the CFG; not especially relevant here + +It will always create two universal variables, one representing +`'static` and one representing `'!1`. Let's call them Vs and V1. They +will have initial values like so: + + Vs = { CFG; end('static) } // it is in U0, so can't name anything else + V1 = { skol(1) } + +From the subtyping constraint above, we would have an outlives constraint like + + '!1: 'static @ P + +To process this, we would grow the value of V1 to include all of Vs: + + Vs = { CFG; end('static) } + V1 = { CFG; end('static), skol(1) } + +At that point, constraint propagation is done, because all the +outlives relationships are satisfied. Then we would go to the "check +universal regions" portion of the code, which would test that no +universal region grew too large. + +In this case, `V1` *did* grow too large -- it is not known to outlive +`end('static)`, nor any of the CFG -- so we would report an error. + +## Another example + +What about this subtyping relationship? + + for<'a> fn(&'a u32, &'a u32) + <: + for<'b, 'c> fn(&'b u32, &'c u32) + +Here we would skolemize the supertype, as before, yielding: + + for<'a> fn(&'a u32, &'a u32) + <: + fn(&'!1 u32, &'!2 u32) + +then we instantiate the variable on the left-hand side with an existential +in universe U2, yielding: + + fn(&'?3 u32, &'?3 u32) + <: + fn(&'!1 u32, &'!2 u32) + +Then we break this down further: + + &'!1 u32 <: &'?3 u32 + &'!2 u32 <: &'?3 u32 + +and even further, yield up our region constraints: + + '!1: '?3 + '!2: '?3 + +Note that, in this case, both `'!1` and `'!2` have to outlive the +variable `'?3`, but the variable `'?3` is not forced to outlive +anything else. Therefore, it simply starts and ends as the empty set +of elements, and hence the type-check succeeds here. + +(This should surprise you a little. It surprised me when I first +realized it. We are saying that if we are a fn that **needs both of +its arguments to have the same region**, we can accept being called +with **arguments with two distinct regions**. That seems intuitively +unsound. But in fact, it's fine, as I +[tried to explain in this issue on the Rust issue tracker long ago][ohdeargoditsallbroken]. +The reason is that even if we get called with arguments of two +distinct lifetimes, those two lifetimes have some intersection (the +call itself), and that intersection can be our value of `'a` that we +use as the common lifetime of our arguments. -nmatsakis) + +[ohdeargoditsallbroken]: https://github.com/rust-lang/rust/issues/32330#issuecomment-202536977 + +## Final example + +Let's look at one last example. We'll extend the previous one to have +a return type: + + for<'a> fn(&'a u32, &'a u32) -> &'a u32 + <: + for<'b, 'c> fn(&'b u32, &'c u32) -> &'b u32 + +Despite seeming very similar to the previous example, this case is +going to get an error. That's good: the problem is that we've gone +from a fn that promises to return one of its two arguments, to a fn +that is promising to return the first one. That is unsound. Let's see how it plays out. + +First, we skolemize the supertype: + + for<'a> fn(&'a u32, &'a u32) -> &'a u32 + <: + fn(&'!1 u32, &'!2 u32) -> &'!1 u32 + +Then we instantiate the subtype with existentials (in U2): + + fn(&'?3 u32, &'?3 u32) -> &'?3 u32 + <: + fn(&'!1 u32, &'!2 u32) -> &'!1 u32 + +And now we create the subtyping relationships: + + &'!1 u32 <: &'?3 u32 // arg 1 + &'!2 u32 <: &'?3 u32 // arg 2 + &'?3 u32 <: &'!1 u32 // return type + +And finally the outlives relationships. Here, let V1, V2, and V3 be the variables +we assign to `!1`, `!2`, and `?3` respectively: + + V1: V3 + V2: V3 + V3: V1 + +Those variables will have these initial values: + + V1 in U1 = {skol(1)} + V2 in U2 = {skol(2)} + V3 in U2 = {} + +Now because of the `V3: V1` constraint, we have to add `skol(1)` into `V3` (and indeed +it is visible from `V3`), so we get: + + V3 in U2 = {skol(1)} + +then we have this constraint `V2: V3`, so we wind up having to enlarge +`V2` to include `skol(1)` (which it can also see): + + V2 in U2 = {skol(1), skol(2)} + +Now contraint propagation is done, but when we check the outlives +relationships, we find that `V2` includes this new element `skol(1)`, +so we report an error. + diff --git a/src/mir-visitor.md b/src/mir-visitor.md new file mode 100644 index 000000000..824ddd5b2 --- /dev/null +++ b/src/mir-visitor.md @@ -0,0 +1,45 @@ +# MIR visitor + +The MIR visitor is a convenient tool for traversing the MIR and either +looking for things or making changes to it. The visitor traits are +defined in [the `rustc::mir::visit` module][m-v] -- there are two of +them, generated via a single macro: `Visitor` (which operates on a +`&Mir` and gives back shared references) and `MutVisitor` (which +operates on a `&mut Mir` and gives back mutable references). + +[m-v]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir/visit.rs + +To implement a visitor, you have to create a type that represents +your visitor. Typically, this type wants to "hang on" to whatever +state you will need while processing MIR: + +```rust +struct MyVisitor<...> { + tcx: TyCtxt<'cx, 'tcx, 'tcx>, + ... +} +``` + +and you then implement the `Visitor` or `MutVisitor` trait for that type: + +```rust +impl<'tcx> MutVisitor<'tcx> for NoLandingPads { + fn visit_foo(&mut self, ...) { + // ... + self.super_foo(...); + } +} +``` + +As shown above, within the impl, you can override any of the +`visit_foo` methods (e.g., `visit_terminator`) in order to write some +code that will execute whenever a `foo` is found. If you want to +recursively walk the contents of the `foo`, you then invoke the +`super_foo` method. (NB. You never want to override `super_foo`.) + +A very simple example of a visitor can be found in [`NoLandingPads`]. +That visitor doesn't even require any state: it just visits all +terminators and removes their `unwind` successors. + +[`NoLandingPads`]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/transform/no_landing_pads.rs + diff --git a/src/mir.md b/src/mir.md index 34f6bbb8f..262082ed7 100644 --- a/src/mir.md +++ b/src/mir.md @@ -1,26 +1,229 @@ # The MIR (Mid-level IR) -MIR is Rust's _Mid-level Intermediate Representation_. It is constructed from -HIR (described in an earlier chapter). +MIR is Rust's _Mid-level Intermediate Representation_. It is +constructed from HIR (described in an earlier chapter). MIR was +introduced in [RFC 1211]. It is a radically simplified form of Rust +that is used for certain flow-sensitive safety checks -- notably the +borrow checker! -- and also for optimization and code generation. + +If you'd like a very high-level introduction to MIR, as well as some +of the compiler concepts that it relies on (such as control-flow +graphs and desugaring), you may enjoy the +[rust-lang blog post that introduced MIR][blog]. + +[blog]: https://blog.rust-lang.org/2016/04/19/MIR.html + +## Introduction to MIR MIR is defined in the [`src/librustc/mir/`][mir] module, but much of the code that manipulates it is found in [`src/librustc_mir`][mirmanip]. +[RFC 1211]: http://rust-lang.github.io/rfcs/1211-mir.html + +Some of the key characteristics of MIR are: + +- It is based on a [control-flow graph][cfg]. +- It does not have nested expressions. +- All types in MIR are fully explicit. + +[cfg]: ./background.html#cfg + +## Key MIR vocabulary + +This section introduces the key concepts of MIR, summarized here: + +- **Basic blocks**: units of the control-flow graph, consisting of: + - **statements:** actions with one successor + - **terminators:** actions with potentially multiple successors; always at the end of a block + - (if you're not familiar with the term basic block, see the [MIR background chapter][bg]) +- **Locals:** Memory locations alloated on the stack (conceptually, at + least), such as function arguments, local variables, and + temporaries. These are identified by an index, written with a + leading underscore, like `_1`. There is also a special "local" + (`_0`) allocated to store the return value. +- **Places:** expressions that identify a location in memory, like `_1` or `_1.f`. +- **Rvalues:** expressions that product a value. The "R" stands for + the fact that these are the "right-hand side" of an assignment. + - **Operands:** the arguments to an rvalue, which can either be a + constant (like `22`) or a place (like `_1`). + +You can get a feeling for how MIR is structed by translating simple +programs into MIR and ready the pretty printed output. In fact, the +playground makes this easy, since it supplies a MIR button that will +show you the MIR for your program. Try putting this program into play +(or [clicking on this link][sample-play]), and then clicking the "MIR" +button on the top: + +[sample-play]: https://play.rust-lang.org/?gist=30074856e62e74e91f06abd19bd72ece&version=stable + +```rust +fn main() { + let mut vec = Vec::new(); + vec.push(1); + vec.push(2); +} +``` + +You should see something like: + +``` +// WARNING: This output format is intended for human consumers only +// and is subject to change without notice. Knock yourself out. +fn main() -> () { + ... +} +``` + +This is the MIR format for the `main` function. + +**Variable declarations.** If we drill in a bit, we'll see it begins +with a bunch of variable declarations. They look like this: + +``` +let mut _0: (); // return place +scope 1 { + let mut _1: std::vec::Vec; // "vec" in scope 1 at src/main.rs:2:9: 2:16 +} +scope 2 { +} +let mut _2: (); +let mut _3: &mut std::vec::Vec; +let mut _4: (); +let mut _5: &mut std::vec::Vec; +``` + +You can see that variables in MIR don't have names, they have indices, +like `_0` or `_1`. We also intermingle the user's variables (e.g., +`_1`) with temporary values (e.g., `_2` or `_3`). You can tell the +difference between user-defined variables have a comment that gives +you their original name (`// "vec" in scope 1...`). + +**Basic blocks.** Reading further, we see our first **basic block** (naturally it may look +slightly different when you view it, and I am ignoring some of the comments): + +``` +bb0: { + StorageLive(_1); + _1 = const >::new() -> bb2; +} +``` + +A basic block is defined by a series of **statements** and a final **terminator**. +In this case, there is one statement: + +``` +StorageLive(_1); +``` + +This statement indicates that the variable `_1` is "live", meaning +that it may be used later -- this will persist until we encounter a +`StorageDead(_1)` statement, which indicates that the variable `_1` is +done being used. These "storage statements" are used by LLVM to +allocate stack space. -_NOTE: copy/pasted from README... needs editing_ +The **terminator** of the block `bb0` is the call to `Vec::new`: -# MIR definition and pass system +``` +_1 = const >::new() -> bb2; +``` + +Terminators are different from statements because they can have more +than one successor -- that is, control may flow to different +places. Function calls like the call to `Vec::new` are always +terminators because of the possibility of unwinding, although in the +case of `Vec::new` we are able to see that indeed unwinding is not +possible, and hence we list only one succssor block, `bb2`. + +If we look ahead to `bb2`, we will see it looks like this: + +``` +bb2: { + StorageLive(_3); + _3 = &mut _1; + _2 = const >::push(move _3, const 1i32) -> [return: bb3, unwind: bb4]; +} +``` + +Here there are two statements: another `StorageLive`, introducing the `_3` temporary, +and then an assignment: -This file contains the definition of the MIR datatypes along with the -various types for the "MIR Pass" system, which lets you easily -register and define new MIR transformations and analyses. +``` +_3 = &mut _1; +``` -Most of the code that operates on MIR can be found in the -`librustc_mir` crate or other crates. The code found here in -`librustc` is just the datatype definitions, along with the functions -which operate on MIR to be placed everywhere else. +Assignments in general have the form: -## MIR Data Types and visitor +``` + = +``` + +A place is an expression like `_3`, `_3.f` or `*_3` -- it denotes a +location in memory. An **Rvalue** is an expression that creates a +value: in this case, the rvalue is a mutable borrow expression, which +looks like `&mut `. So we can kind of define a grammar for +rvalues like so: + +``` + = & (mut)? + | + + | - + | ... + + = Constant + | copy Place + | move Place +``` + +As you can see from this grammar, rvalues cannot be nested -- they can +only reference places and constants. Moreover, when you use a place, +we indicate whether we are **copying it** (which requires that the +place have a type `T` where `T: Copy`) or **moving it** (which works +for a place of any type). So, for example, if we had the expression `x += a + b + c` in Rust, that would get compile to two statements and a +temporary: + +``` +TMP1 = a + b +x = TMP1 + c +``` + +([Try it and see, though you may want to do release mode to skip over the overflow checks.][play-abc]) + +[play-abc]: https://play.rust-lang.org/?gist=1751196d63b2a71f8208119e59d8a5b6&version=stable + +## MIR data types + +The MIR data types are defined in the [`src/librustc/mir/`][mir] +module. Each of the key concepts mentioned in the previous section +maps in a fairly straightforward way to a Rust type. + +The main MIR data type is `Mir`. It contains the data for a single +function (along with sub-instances of Mir for "promoted constants", +but [you can read about those below](#promoted)). + +- **Basic blocks**: The basic blocks are stored in the field + `basic_blocks`; this is a vector of `BasicBlockData` + structures. Nobody ever references a basic block directly: instead, + we pass around `BasicBlock` values, which are + [newtype'd] indices into this vector. +- **Statements** are represented by the type `Statement`. +- **Terminators** are represented by the `Terminator`. +- **Locals** are represented by a [newtype'd] index type `Local`. The + data for a local variable is found in the `Mir` (the `local_decls` + vector). There is also a special constant `RETURN_PLACE` identifying + the special "local" representing the return value. +- **Places** are identified by the enum `Place`. There are a few variants: + - Local variables like `_1` + - Static variables `FOO` + - **Projections**, which are fields or other things that "project + out" from a base place. So e.g. the place `_1.f` is a projection, + with `f` being the "projection element and `_1` being the base + path. `*_1` is also a projection, with the `*` being represented + by the `ProjectionElem::Deref` element. +- **Rvalues** are represented by the enum `Rvalue`. +- **Operands** are represented by the enum `Operand`. + +## MIR Visitor The main MIR data type is `rustc::mir::Mir`, defined in `mod.rs`. There is also the MIR visitor (in `visit.rs`) which allows you to walk @@ -32,74 +235,18 @@ routines for visiting the MIR CFG in [different standard orders][traversal] [traversal]: https://en.wikipedia.org/wiki/Tree_traversal -## MIR pass suites and their integration into the query system - -As a MIR *consumer*, you are expected to use one of the queries that -returns a "final MIR". As of the time of this writing, there is only -one: `optimized_mir(def_id)`, but more are expected to come in the -future. For foreign def-ids, we simply read the MIR from the other -crate's metadata. But for local def-ids, the query will construct the -MIR and then iteratively optimize it by putting it through various -pipeline stages. This section describes those pipeline stages and how -you can extend them. - -To produce the `optimized_mir(D)` for a given def-id `D`, the MIR -passes through several suites of optimizations, each represented by a -query. Each suite consists of multiple optimizations and -transformations. These suites represent useful intermediate points -where we want to access the MIR for type checking or other purposes: - -- `mir_build(D)` – not a query, but this constructs the initial MIR -- `mir_const(D)` – applies some simple transformations to make MIR ready for constant evaluation; -- `mir_validated(D)` – applies some more transformations, making MIR ready for borrow checking; -- `optimized_mir(D)` – the final state, after all optimizations have been performed. - -### Stealing - -The intermediate queries `mir_const()` and `mir_validated()` yield up -a `&'tcx Steal>`, allocated using -`tcx.alloc_steal_mir()`. This indicates that the result may be -**stolen** by the next suite of optimizations – this is an -optimization to avoid cloning the MIR. Attempting to use a stolen -result will cause a panic in the compiler. Therefore, it is important -that you do not read directly from these intermediate queries except as -part of the MIR processing pipeline. - -Because of this stealing mechanism, some care must also be taken to -ensure that, before the MIR at a particular phase in the processing -pipeline is stolen, anyone who may want to read from it has already -done so. Concretely, this means that if you have some query `foo(D)` -that wants to access the result of `mir_const(D)` or -`mir_validated(D)`, you need to have the successor pass "force" -`foo(D)` using `ty::queries::foo::force(...)`. This will force a query -to execute even though you don't directly require its result. - -As an example, consider MIR const qualification. It wants to read the -result produced by the `mir_const()` suite. However, that result will -be **stolen** by the `mir_validated()` suite. If nothing was done, -then `mir_const_qualif(D)` would succeed if it came before -`mir_validated(D)`, but fail otherwise. Therefore, `mir_validated(D)` -will **force** `mir_const_qualif` before it actually steals, thus -ensuring that the reads have already happened: - -``` -mir_const(D) --read-by--> mir_const_qualif(D) - | ^ - stolen-by | - | (forces) - v | -mir_validated(D) ------------+ -``` - -### Implementing and registering a pass - -To create a new MIR pass, you simply implement the `MirPass` trait for -some fresh singleton type `Foo`. Once you have implemented a trait for -your type `Foo`, you then have to insert `Foo` into one of the suites; -this is done in `librustc_driver/driver.rs` by invoking `push_pass(S, -Foo)` with the appropriate suite substituted for `S`. +## Representing constants + +TBD + + + +### Promoted constants + +TBD [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir [mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir +[newtype'd]: glossary.html From 906746500b74cf023ec576df749982415ff39776 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sun, 25 Feb 2018 20:55:56 -0500 Subject: [PATCH 0113/1812] apply mark-i-m's suggestions --- src/SUMMARY.md | 2 +- src/background.md | 20 ++--- src/glossary.md | 12 ++- src/mir-background.md | 122 ------------------------------ src/mir-borrowck.md | 8 +- src/mir-passes.md | 36 +++++---- src/mir-regionck.md | 167 +++++++++++++++++++++++++++++++++++------- src/mir-visitor.md | 10 +++ src/mir.md | 34 +++------ 9 files changed, 209 insertions(+), 202 deletions(-) delete mode 100644 src/mir-background.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 29ad79998..ab9da7295 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -24,7 +24,7 @@ - [Type checking](./type-checking.md) - [The MIR (Mid-level IR)](./mir.md) - [MIR construction](./mir-construction.md) - - [MIR visitor](./mir-visitor.md) + - [MIR visitor and traversal](./mir-visitor.md) - [MIR passes: getting the MIR for a function](./mir-passes.md) - [MIR borrowck](./mir-borrowck.md) - [MIR-based region checking (NLL)](./mir-regionck.md) diff --git a/src/background.md b/src/background.md index 92ae6507a..50c247774 100644 --- a/src/background.md +++ b/src/background.md @@ -17,9 +17,9 @@ A control-flow graph is structured as a set of **basic blocks** connected by edges. The key idea of a basic block is that it is a set of statements that execute "together" -- that is, whenever you branch to a basic block, you start at the first statement and then execute -all the remainder. Only at the end of the is there the possibility of -branching to more than one place (in MIR, we call that final statement -the **terminator**): +all the remainder. Only at the end of the block is there the +possibility of branching to more than one place (in MIR, we call that +final statement the **terminator**): ``` bb0: { @@ -88,7 +88,8 @@ cycle. ## What is co- and contra-variance? -*to be written* +Check out the subtyping chapter from the +[Rust Nomicon](https://doc.rust-lang.org/nomicon/subtyping.html). @@ -97,18 +98,17 @@ cycle. Let's describe the concepts of free vs bound in terms of program variables, since that's the thing we're most familiar with. -- Consider this expression: `a + b`. In this expression, `a` and `b` - refer to local variables that are defined *outside* of the - expression. We say that those variables **appear free** in the - expression. To see why this term makes sense, consider the next - example. -- In contrast, consider this expression, which creates a closure: `|a, +- Consider this expression, which creates a closure: `|a, b| a + b`. Here, the `a` and `b` in `a + b` refer to the arguments that the closure will be given when it is called. We say that the `a` and `b` there are **bound** to the closure, and that the closure signature `|a, b|` is a **binder** for the names `a` and `b` (because any references to `a` or `b` within refer to the variables that it introduces). +- Consider this expression: `a + b`. In this expression, `a` and `b` + refer to local variables that are defined *outside* of the + expression. We say that those variables **appear free** in the + expression (i.e., they are **free**, not **bound** (tied up)). So there you have it: a variable "appears free" in some expression/statement/whatever if it refers to something defined diff --git a/src/glossary.md b/src/glossary.md index 2aa9b52f1..81eb62bc9 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -6,11 +6,16 @@ The compiler uses a number of...idiosyncratic abbreviations and things. This glo Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. +binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and `|a| ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) +bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession `|a| a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). +control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) +data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. +free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) 'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item HIR | the High-level IR, created by lowering and desugaring the AST ([see more](hir.html)) @@ -18,7 +23,7 @@ HirId | identifies a particular node in the HIR by combining HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. ICE | internal compiler error. When the compiler crashes. ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. -inference variable | when doing type or region inference, an "inference variable" is a kind of special type/region that represents value you are trying to find. Think of `X` in algebra. +inference variable | when doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. infcx | the inference context (see `librustc/infer`) IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. local crate | the crate currently being compiled. @@ -27,14 +32,18 @@ LTO | Link-Time Optimizations. A set of optimizations offer MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. +NLL | [non-lexical lifetimes](./mir-regionck.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) +promoted constants | constants extracted from a function and lifted to static scope; see [this section](./mir.html#promoted) for more details. provider | the function that executes a query ([see more](query.html)) +quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified) query | perhaps some sub-computation during compilation ([see more](query.html)) region | another term for "lifetime" often used in the literature and in the borrow checker. sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. +skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)` as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir-regionck.html#skol) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) @@ -45,6 +54,7 @@ token | the smallest unit of parsing. Tokens are produced aft trans | the code to translate MIR into LLVM IR. trait reference | a trait and values for its type parameters ([see more](ty.html)). ty | the internal representation of a type ([see more](ty.html)). +variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter for more](./background.html#variance). [LLVM]: https://llvm.org/ [lto]: https://llvm.org/docs/LinkTimeOptimization.html diff --git a/src/mir-background.md b/src/mir-background.md deleted file mode 100644 index 38fba5d16..000000000 --- a/src/mir-background.md +++ /dev/null @@ -1,122 +0,0 @@ -# MIR Background topics - -This section covers a numbers of common compiler terms that arise when -talking about MIR and optimizations. We try to give the general -definition while providing some Rust-specific context. - - - -## What is a control-flow graph? - -A control-flow graph is a common term from compilers. If you've ever -used a flow-chart, then the concept of a control-flow graph will be -pretty familiar to you. It's a representation of your program that -exposes the underlying control flow in a very clear way. - -A control-flow graph is structured as a set of **basic blocks** -connected by edges. The key idea of a basic block is that it is a set -of statements that execute "together" -- that is, whenever you branch -to a basic block, you start at the first statement and then execute -all the remainder. Only at the end of the is there the possibility of -branching to more than one place (in MIR, we call that final statement -the **terminator**): - -``` -bb0: { - statement0; - statement1; - statement2; - ... - terminator; -} -``` - -Many expressions that you are used to in Rust compile down to multiple -basic blocks. For example, consider an if statement: - -```rust -a = 1; -if some_variable { - b = 1; -} else { - c = 1; -} -d = 1; -``` - -This would compile into four basic blocks: - -``` -BB0: { - a = 1; - if some_variable { goto BB1 } else { goto BB2 } -} - -BB1: { - b = 1; - goto BB3; -} - -BB2: { - c = 1; - goto BB3; -} - -BB3: { - d = 1; - ...; -} -``` - -When using a control-flow graph, a loop simply appears as a cycle in -the graph, and the `break` keyword translates into a path out of that -cycle. - - - -## What is a dataflow analysis? - -*to be written* - - - -## What is "universally quantified"? What about "existentially quantified"? - -*to be written* - - - -## What is co- and contra-variance? - -*to be written* - - - -## What is a "free region" or a "free variable"? What about "bound region"? - -Let's describe the concepts of free vs bound in terms of program -variables, since that's the thing we're most familiar with. - -- Consider this expression: `a + b`. In this expression, `a` and `b` - refer to local variables that are defined *outside* of the - expression. We say that those variables **appear free** in the - expression. To see why this term makes sense, consider the next - example. -- In contrast, consider this expression, which creates a closure: `|a, - b| a + b`. Here, the `a` and `b` in `a + b` refer to the arguments - that the closure will be given when it is called. We say that the - `a` and `b` there are **bound** to the closure, and that the closure - signature `|a, b|` is a **binder** for the names `a` and `b` - (because any references to `a` or `b` within refer to the variables - that it introduces). - -So there you have it: a variable "appears free" in some -expression/statement/whatever if it refers to something defined -outside of that expressions/statement/whatever. Equivalently, we can -then refer to the "free variables" of an expression -- which is just -the set of variables that "appear free". - -So what does this have to do with regions? Well, we can apply the -analogous concept to type and regions. For example, in the type `&'a -u32`, `'a` appears free. But in the type `for<'a> fn(&'a u32)`, it -does not. diff --git a/src/mir-borrowck.md b/src/mir-borrowck.md index b632addc2..3c10191d4 100644 --- a/src/mir-borrowck.md +++ b/src/mir-borrowck.md @@ -37,9 +37,9 @@ in several modes, but this text will describe only the mode when NLL is enabled The overall flow of the borrow checker is as follows: -- We first create a **local copy** C of the MIR. We will be modifying - this copy in place to modify the types and things to include - references to the new regions that we are computing. +- We first create a **local copy** C of the MIR. In the coming steps, + we will modify this copy in place to modify the types and things to + include references to the new regions that we are computing. - We then invoke `nll::replace_regions_in_mir` to modify this copy C. Among other things, this function will replace all of the regions in the MIR with fresh [inference variables](glossary.html). @@ -51,6 +51,6 @@ The overall flow of the borrow checker is as follows: - (More details can be found in [the NLL section](./mir-regionck.html).) - Finally, the borrow checker itself runs, taking as input (a) the results of move analysis and (b) the regions computed by the region - checker. This allows is to figure out which loans are still in scope + checker. This allows us to figure out which loans are still in scope at any particular point. diff --git a/src/mir-passes.md b/src/mir-passes.md index 2fe471385..6d657ae70 100644 --- a/src/mir-passes.md +++ b/src/mir-passes.md @@ -4,9 +4,9 @@ If you would like to get the MIR for a function (or constant, etc), you can use the `optimized_mir(def_id)` query. This will give you back the final, optimized MIR. For foreign def-ids, we simply read the MIR from the other crate's metadata. But for local def-ids, the query will -construct the MIR and then iteratively optimize it by putting it -through various pipeline stages. This section describes those pipeline -stages and how you can extend them. +construct the MIR and then iteratively optimize it by applying a +series of passes. This section describes how those passes work and how +you can extend them. To produce the `optimized_mir(D)` for a given def-id `D`, the MIR passes through several suites of optimizations, each represented by a @@ -97,18 +97,19 @@ that appeared within the `main` function.) ### Implementing and registering a pass A `MirPass` is some bit of code that processes the MIR, typically -- -but not always -- transforming it along the way in some way. For -example, it might perform an optimization. The `MirPass` trait itself -is found in in [the `rustc_mir::transform` module][mirtransform], and -it basically consists of one method, `run_pass`, that simply gets an +but not always -- transforming it along the way somehow. For example, +it might perform an optimization. The `MirPass` trait itself is found +in in [the `rustc_mir::transform` module][mirtransform], and it +basically consists of one method, `run_pass`, that simply gets an `&mut Mir` (along with the tcx and some information about where it -came from). +came from). The MIR is therefore modified in place (which helps to +keep things efficient). -A good example of a basic MIR pass is [`NoLandingPads`], which walks the -MIR and removes all edges that are due to unwinding -- this is used -with when configured with `panic=abort`, which never unwinds. As you can see -from its source, a MIR pass is defined by first defining a dummy type, a struct -with no fields, something like: +A good example of a basic MIR pass is [`NoLandingPads`], which walks +the MIR and removes all edges that are due to unwinding -- this is +used when configured with `panic=abort`, which never unwinds. As you +can see from its source, a MIR pass is defined by first defining a +dummy type, a struct with no fields, something like: ```rust struct MyPass; @@ -120,8 +121,9 @@ this pass into the appropriate list of passes found in a query like should go into the `optimized_mir` list.) If you are writing a pass, there's a good chance that you are going to -want to use a [MIR visitor] too -- those are a handy visitor that -walks the MIR for you and lets you make small edits here and there. +want to use a [MIR visitor]. MIR visitors are a handy way to walk all +the parts of the MIR, either to search for something or to make small +edits. ### Stealing @@ -149,7 +151,9 @@ be **stolen** by the `mir_validated()` suite. If nothing was done, then `mir_const_qualif(D)` would succeed if it came before `mir_validated(D)`, but fail otherwise. Therefore, `mir_validated(D)` will **force** `mir_const_qualif` before it actually steals, thus -ensuring that the reads have already happened: +ensuring that the reads have already happened (remember that +[queries are memoized](./query.html), so executing a query twice +simply loads from a cache the second time): ``` mir_const(D) --read-by--> mir_const_qualif(D) diff --git a/src/mir-regionck.md b/src/mir-regionck.md index 8be4fc8b9..d9d854081 100644 --- a/src/mir-regionck.md +++ b/src/mir-regionck.md @@ -10,11 +10,11 @@ deprecated once they become the standard kind of lifetime.) The MIR-based region analysis consists of two major functions: - `replace_regions_in_mir`, invoked first, has two jobs: - - First, it analyzes the signature of the MIR and finds the set of - regions that appear in the MIR signature (e.g., `'a` in `fn - foo<'a>(&'a u32) { ... }`. These are called the "universal" or - "free" regions -- in particular, they are the regions that - [appear free][fvb] in the function body. + - First, it finds the set of regions that appear within the + signature of the function (e.g., `'a` in `fn foo<'a>(&'a u32) { + ... }`. These are called the "universal" or "free" regions -- in + particular, they are the regions that [appear free][fvb] in the + function body. - Second, it replaces all the regions from the function body with fresh inference variables. This is because (presently) those regions are the results of lexical region inference and hence are @@ -49,6 +49,8 @@ the role of `liveness_constraints` vs other `constraints`, plus ## Closures +*to be written* + ## The MIR type-check @@ -131,15 +133,14 @@ replace them with representatives, written like `!1`. We call these regions "skolemized regions" -- they represent, basically, "some unknown region". -Once we've done that replacement, we have the following types: +Once we've done that replacement, we have the following relation: fn(&'static u32) <: fn(&'!1 u32) The key idea here is that this unknown region `'!1` is not related to any other regions. So if we can prove that the subtyping relationship is true for `'!1`, then it ought to be true for any region, which is -what we wanted. (This number `!1` is called a "universe", for reasons -we'll get into later.) +what we wanted. So let's work through what happens next. To check if two functions are subtypes, we check if their arguments have the desired relationship @@ -154,6 +155,118 @@ outlives `'static`. Now, this *might* be true -- after all, `'!1` could be `'static` -- but we don't *know* that it's true. So this should yield up an error (eventually). +### What is a universe + +In the previous section, we introduced the idea of a skolemized +region, and we denoted it `!1`. We call this number `1` the **universe +index**. The idea of a "universe" is that it is a set of names that +are in scope within some type or at some point. Universes are formed +into a tree, where each child extends its parents with some new names. +So the **root universe** conceptually contains global names, such as +the the lifetime `'static` or the type `i32`. In the compiler, we also +put generic type parameters into this root universe. So consider +this function `bar`: + +```rust +struct Foo { } + +fn bar<'a, T>(t: &'a T) { + ... +} +``` + +Here, the root universe would consider of the lifetimes `'static` and +`'a`. In fact, although we're focused on lifetimes here, we can apply +the same concept to types, in which case the types `Foo` and `T` would +be in the root universe (along with other global types, like `i32`). +Basically, the root universe contains all the names that +[appear free](./background.html#free-vs-bound) in the body of `bar`. + +Now let's extend `bar` a bit by adding a variable `x`: + +```rust +fn bar<'a, T>(t: &'a T) { + let x: for<'b> fn(&'b u32) = ...; +} +``` + +Here, the name `'b` is not part of the root universe. Instead, when we +"enter" into this `for<'b>` (e.g., by skolemizing it), we will create +a child universe of the root, let's call it U1: + +``` +U0 (root universe) +│ +└─ U1 (child universe) +``` + +The idea is that this child universe U1 extends the root universe U0 +with a new name, which we are identifying by its universe number: +`!1`. + +Now let's extend `bar` a bit by adding one more variable, `y`: + +```rust +fn bar<'a, T>(t: &'a T) { + let x: for<'b> fn(&'b u32) = ...; + let y: for<'c> fn(&'b u32) = ...; +} +``` + +When we enter *this* type, we will again create a new universe, which +let's call `U2`. It's parent will be the root universe, and U1 will be +its sibling: + +``` +U0 (root universe) +│ +├─ U1 (child universe) +│ +└─ U2 (child universe) +``` + +This implies that, while in U2, we can name things from U0 or U2, but +not U1. + +**Giving existential variables a universe.** Now that we have this +notion of universes, we can use it to extend our type-checker and +things to prevent illegal names from leaking out. The idea is that we +give each inference (existential) variable -- whether it be a type or +a lifetime -- a universe. That variable's value can then only +reference names visible from that universe. So for example is a +lifetime variable is created in U0, then it cannot be assigned a value +of `!1` or `!2`, because those names are not visible from the universe +U0. + +**Representing universes with just a counter.** You might be surprised +to see that the compiler doesn't keep track of a full tree of +universes. Instead, it just keeps a counter -- and, to determine if +one universe can see another one, it just checks if the index is +greater. For example, U2 can see U0 because 2 >= 0. But U0 cannot see +U2, because 0 >= 2 is false. + +How can we get away with this? Doesn't this mean that we would allow +U2 to also see U1? The answer is that, yes, we would, **if that +question ever arose**. But because of the structure of our type +checker etc, there is no way for that to happen. In order for +something happening in the universe U1 to "communicate" with something +happening in U2, they would have to have a shared inference variable X +in common. And because everything in U1 is scoped to just U1 and its +children, that inference variable X would have to be in U0. And since +X is in U0, it cannot name anything from U1 (or U2). This is perhaps easiest +to see by using a kind of generic "logic" example: + +``` +exists { + forall { ... /* Y is in U1 ... */ } + forall { ... /* Z is in U2 ... */ } +} +``` + +Here, the only way for the two foralls to interact would be through X, +but neither Y nor Z are in scope when X is declared, so its value +cannot reference either of them. + ### Universes and skolemized region elements But where does that error come from? The way it happens is like this. @@ -179,10 +292,11 @@ In the region inference engine, outlives constraints have the form: V1: V2 @ P where `V1` and `V2` are region indices, and hence map to some region -variable (which may be universally or existentially quantified). This -variable will have a universe, so let's call those universes `U(V1)` -and `U(V2)` respectively. (Actually, the only one we are going to care -about is `U(V1)`.) +variable (which may be universally or existentially quantified). The +`P` here is a "point" in the control-flow graph; it's not important +for this section. This variable will have a universe, so let's call +those universes `U(V1)` and `U(V2)` respectively. (Actually, the only +one we are going to care about is `U(V1)`.) When we encounter this constraint, the ordinary procedure is to start a DFS from `P`. We keep walking so long as the nodes we are walking @@ -190,24 +304,24 @@ are present in `value(V2)` and we add those nodes to `value(V1)`. If we reach a return point, we add in any `end(X)` elements. That part remains unchanged. -But then *after that* we want to iterate over the skolemized `skol(u)` +But then *after that* we want to iterate over the skolemized `skol(x)` elements in V2 (each of those must be visible to `U(V2)`, but we should be able to just assume that is true, we don't have to check it). We have to ensure that `value(V1)` outlives each of those skolemized elements. Now there are two ways that could happen. First, if `U(V1)` can see -the universe `u` (i.e., `u <= U(V1)`), then we can just add `skol(u1)` +the universe `x` (i.e., `x <= U(V1)`), then we can just add `skol(x)` to `value(V1)` and be done. But if not, then we have to approximate: -we may not know what set of elements `skol(u1)` represents, but we -should be able to compute some sort of **upper bound** for it -- -something that it is smaller than. For now, we'll just use `'static` -for that (since it is bigger than everything) -- in the future, we can -sometimes be smarter here (and in fact we have code for doing this -already in other contexts). Moreover, since `'static` is in U0, we -know that all variables can see it -- so basically if we find a that -`value(V2)` contains `skol(u)` for some universe `u` that `V1` can't -see, then we force `V1` to `'static`. +we may not know what set of elements `skol(x)` represents, but we +should be able to compute some sort of **upper bound** B for it -- +some region B that outlives `skol(x)`. For now, we'll just use +`'static` for that (since it outlives everything) -- in the future, we +can sometimes be smarter here (and in fact we have code for doing this +already in other contexts). Moreover, since `'static` is in the root +universe U0, we know that all variables can see it -- so basically if +we find that `value(V2)` contains `skol(x)` for some universe `x` +that `V1` can't see, then we force `V1` to `'static`. ### Extending the "universal regions" check @@ -258,7 +372,7 @@ To process this, we would grow the value of V1 to include all of Vs: Vs = { CFG; end('static) } V1 = { CFG; end('static), skol(1) } -At that point, constraint propagation is done, because all the +At that point, constraint propagation is complete, because all the outlives relationships are satisfied. Then we would go to the "check universal regions" portion of the code, which would test that no universal region grew too large. @@ -280,8 +394,9 @@ Here we would skolemize the supertype, as before, yielding: <: fn(&'!1 u32, &'!2 u32) -then we instantiate the variable on the left-hand side with an existential -in universe U2, yielding: +then we instantiate the variable on the left-hand side with an +existential in universe U2, yielding the following (`?n` is a notation +for an existential variable): fn(&'?3 u32, &'?3 u32) <: diff --git a/src/mir-visitor.md b/src/mir-visitor.md index 824ddd5b2..3a8b06c54 100644 --- a/src/mir-visitor.md +++ b/src/mir-visitor.md @@ -43,3 +43,13 @@ terminators and removes their `unwind` successors. [`NoLandingPads`]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/transform/no_landing_pads.rs +## Traversal + +In addition the visitor, [the `rustc::mir::traversal` module][t] +contains useful functions for walking the MIR CFG in +[different standard orders][traversal] (e.g. pre-order, reverse +post-order, and so forth). + +[t]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir/traversal.rs +[traversal]: https://en.wikipedia.org/wiki/Tree_traversal + diff --git a/src/mir.md b/src/mir.md index 262082ed7..6e7ac0691 100644 --- a/src/mir.md +++ b/src/mir.md @@ -1,10 +1,10 @@ # The MIR (Mid-level IR) MIR is Rust's _Mid-level Intermediate Representation_. It is -constructed from HIR (described in an earlier chapter). MIR was -introduced in [RFC 1211]. It is a radically simplified form of Rust -that is used for certain flow-sensitive safety checks -- notably the -borrow checker! -- and also for optimization and code generation. +constructed from [HIR](./hir.html). MIR was introduced in +[RFC 1211]. It is a radically simplified form of Rust that is used for +certain flow-sensitive safety checks -- notably the borrow checker! -- +and also for optimization and code generation. If you'd like a very high-level introduction to MIR, as well as some of the compiler concepts that it relies on (such as control-flow @@ -35,20 +35,20 @@ This section introduces the key concepts of MIR, summarized here: - **Basic blocks**: units of the control-flow graph, consisting of: - **statements:** actions with one successor - **terminators:** actions with potentially multiple successors; always at the end of a block - - (if you're not familiar with the term basic block, see the [MIR background chapter][bg]) + - (if you're not familiar with the term *basic block*, see the [background chapter][cfg]) - **Locals:** Memory locations alloated on the stack (conceptually, at least), such as function arguments, local variables, and temporaries. These are identified by an index, written with a leading underscore, like `_1`. There is also a special "local" (`_0`) allocated to store the return value. - **Places:** expressions that identify a location in memory, like `_1` or `_1.f`. -- **Rvalues:** expressions that product a value. The "R" stands for +- **Rvalues:** expressions that produce a value. The "R" stands for the fact that these are the "right-hand side" of an assignment. - **Operands:** the arguments to an rvalue, which can either be a constant (like `22`) or a place (like `_1`). You can get a feeling for how MIR is structed by translating simple -programs into MIR and ready the pretty printed output. In fact, the +programs into MIR and reading the pretty printed output. In fact, the playground makes this easy, since it supplies a MIR button that will show you the MIR for your program. Try putting this program into play (or [clicking on this link][sample-play]), and then clicking the "MIR" @@ -96,7 +96,9 @@ You can see that variables in MIR don't have names, they have indices, like `_0` or `_1`. We also intermingle the user's variables (e.g., `_1`) with temporary values (e.g., `_2` or `_3`). You can tell the difference between user-defined variables have a comment that gives -you their original name (`// "vec" in scope 1...`). +you their original name (`// "vec" in scope 1...`). The "scope" blocks +(e.g., `scope 1 { .. }`) describe the lexical structure of the source +program (which names were in scope when). **Basic blocks.** Reading further, we see our first **basic block** (naturally it may look slightly different when you view it, and I am ignoring some of the comments): @@ -223,27 +225,15 @@ but [you can read about those below](#promoted)). - **Rvalues** are represented by the enum `Rvalue`. - **Operands** are represented by the enum `Operand`. -## MIR Visitor - -The main MIR data type is `rustc::mir::Mir`, defined in `mod.rs`. -There is also the MIR visitor (in `visit.rs`) which allows you to walk -the MIR and override what actions will be taken at various points (you -can visit in either shared or mutable mode; the latter allows changing -the MIR in place). Finally `traverse.rs` contains various traversal -routines for visiting the MIR CFG in [different standard orders][traversal] -(e.g. pre-order, reverse post-order, and so forth). - -[traversal]: https://en.wikipedia.org/wiki/Tree_traversal - ## Representing constants -TBD +*to be written* ### Promoted constants -TBD +*to be written* [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir From 64963f85af1723d9632ef69245e030c2487e7511 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 27 Feb 2018 14:16:18 -0500 Subject: [PATCH 0114/1812] fix typo --- src/mir-regionck.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir-regionck.md b/src/mir-regionck.md index d9d854081..571d7c673 100644 --- a/src/mir-regionck.md +++ b/src/mir-regionck.md @@ -20,7 +20,7 @@ The MIR-based region analysis consists of two major functions: regions are the results of lexical region inference and hence are not of much interest. The intention is that -- eventually -- they will be "erased regions" (i.e., no information at all), since we - don't be doing lexical region inference at all. + won't be doing lexical region inference at all. - `compute_regions`, invoked second: this is given as argument the results of move analysis. It has the job of computing values for all the inference variabes that `replace_regions_in_mir` introduced. From 03044a350e5cd5f4a1fc7dcc454fd9c4ecaade33 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 28 Feb 2018 15:28:57 -0500 Subject: [PATCH 0115/1812] address nits --- src/glossary.md | 2 +- src/mir-regionck.md | 9 +++++---- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/src/glossary.md b/src/glossary.md index 81eb62bc9..bff2a6557 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -43,7 +43,7 @@ region | another term for "lifetime" often used in the literat sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)` as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir-regionck.html#skol) for more details. +skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir-regionck.html#skol) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) diff --git a/src/mir-regionck.md b/src/mir-regionck.md index 571d7c673..e7b12405a 100644 --- a/src/mir-regionck.md +++ b/src/mir-regionck.md @@ -12,7 +12,7 @@ The MIR-based region analysis consists of two major functions: - `replace_regions_in_mir`, invoked first, has two jobs: - First, it finds the set of regions that appear within the signature of the function (e.g., `'a` in `fn foo<'a>(&'a u32) { - ... }`. These are called the "universal" or "free" regions -- in + ... }`). These are called the "universal" or "free" regions -- in particular, they are the regions that [appear free][fvb] in the function body. - Second, it replaces all the regions from the function body with @@ -164,7 +164,8 @@ are in scope within some type or at some point. Universes are formed into a tree, where each child extends its parents with some new names. So the **root universe** conceptually contains global names, such as the the lifetime `'static` or the type `i32`. In the compiler, we also -put generic type parameters into this root universe. So consider +put generic type parameters into this root universe (in this sense, +there is not just one root universe, but one per item). So consider this function `bar`: ```rust @@ -175,7 +176,7 @@ fn bar<'a, T>(t: &'a T) { } ``` -Here, the root universe would consider of the lifetimes `'static` and +Here, the root universe would consist of the lifetimes `'static` and `'a`. In fact, although we're focused on lifetimes here, we can apply the same concept to types, in which case the types `Foo` and `T` would be in the root universe (along with other global types, like `i32`). @@ -214,7 +215,7 @@ fn bar<'a, T>(t: &'a T) { ``` When we enter *this* type, we will again create a new universe, which -let's call `U2`. It's parent will be the root universe, and U1 will be +we'll call `U2`. Its parent will be the root universe, and U1 will be its sibling: ``` From 3025c38976a88b5606e24a0ead66ff78d21658c6 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 28 Feb 2018 14:40:18 -0600 Subject: [PATCH 0116/1812] Fix funny glossary formatting --- src/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glossary.md b/src/glossary.md index bff2a6557..187460f03 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -6,7 +6,7 @@ The compiler uses a number of...idiosyncratic abbreviations and things. This glo Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. -binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and `|a| ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) +binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and `\|a\| ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession `|a| a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). From a797e14afaf6db2b23ee8a13fecaf61279160b9a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 28 Feb 2018 14:45:51 -0600 Subject: [PATCH 0117/1812] fix table --- src/glossary.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glossary.md b/src/glossary.md index 187460f03..9c4b66d66 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -6,8 +6,8 @@ The compiler uses a number of...idiosyncratic abbreviations and things. This glo Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. -binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and `\|a\| ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) -bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession `|a| a * 2`. See [the background chapter for more](./background.html#free-vs-bound) +binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and `|a| ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) +bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession `|a| a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) From 017796049dbaa091909406646eed568ae4a50645 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 28 Feb 2018 14:58:24 -0600 Subject: [PATCH 0118/1812] actually fix table with hack --- src/glossary.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/glossary.md b/src/glossary.md index 9c4b66d66..7152cba36 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -6,8 +6,8 @@ The compiler uses a number of...idiosyncratic abbreviations and things. This glo Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. -binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and `|a| ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) -bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession `|a| a * 2`. See [the background chapter for more](./background.html#free-vs-bound) +binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) +bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) From 12e382d2d5d8e3f3fe2c845e3134084126204438 Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Thu, 1 Mar 2018 10:04:23 +0530 Subject: [PATCH 0119/1812] Add info about ParseSess for code index #50 --- src/code-index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/code-index.md b/src/code-index.md index 5b452ef0f..73e23d824 100644 --- a/src/code-index.md +++ b/src/code-index.md @@ -7,3 +7,4 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) +`ParseSess` | struct | This struct contains information about a parsing session | [The parser](the-parser.html) | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) From 7fa92ec4a528833984dce289ef4bcbe887b433c4 Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Fri, 2 Mar 2018 09:22:41 +0530 Subject: [PATCH 0120/1812] Add info about CodeMap for #50 --- src/code-index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/code-index.md b/src/code-index.md index 73e23d824..bbfc233e8 100644 --- a/src/code-index.md +++ b/src/code-index.md @@ -8,3 +8,4 @@ Item | Kind | Short description | Chapter | ----------------|----------|-----------------------------|--------------------|------------------- `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) `ParseSess` | struct | This struct contains information about a parsing session | [The parser](the-parser.html) | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) +`CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser](the-parser.html) | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) \ No newline at end of file From f1bda065d8ad9cbf0d328ffed1a48acaf48718dc Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Fri, 2 Mar 2018 11:03:20 +0530 Subject: [PATCH 0121/1812] Add info about TraitDef for #50 --- src/code-index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/code-index.md b/src/code-index.md index bbfc233e8..07aad732c 100644 --- a/src/code-index.md +++ b/src/code-index.md @@ -8,4 +8,5 @@ Item | Kind | Short description | Chapter | ----------------|----------|-----------------------------|--------------------|------------------- `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) `ParseSess` | struct | This struct contains information about a parsing session | [The parser](the-parser.html) | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) -`CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser](the-parser.html) | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) \ No newline at end of file +`CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser](the-parser.html) | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) +`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules](ty.html) | [src/librustc/ty/trait_def.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/trait_def.rs) From fd0223e50b6feaf1fa821c915adef6e651951c43 Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Fri, 2 Mar 2018 19:42:26 +0530 Subject: [PATCH 0122/1812] keep alphabetical order --- src/code-index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/code-index.md b/src/code-index.md index 07aad732c..b1eb3546a 100644 --- a/src/code-index.md +++ b/src/code-index.md @@ -6,7 +6,7 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- -`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) -`ParseSess` | struct | This struct contains information about a parsing session | [The parser](the-parser.html) | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) `CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser](the-parser.html) | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) +`ParseSess` | struct | This struct contains information about a parsing session | [The parser](the-parser.html) | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules](ty.html) | [src/librustc/ty/trait_def.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/trait_def.rs) +`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) From 23b3e84c1136eaa010b62cdee584edb413690c87 Mon Sep 17 00:00:00 2001 From: Michal 'vorner' Vaner Date: Sun, 18 Feb 2018 18:03:46 +0100 Subject: [PATCH 0123/1812] Second pass of name resolution Just small little tweaks --- src/name-resolution.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/name-resolution.md b/src/name-resolution.md index 25ce3e29e..5095b750a 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -3,7 +3,12 @@ The name resolution is a separate pass in the compiler. Its input is the syntax tree, produced by parsing input files. It produces links from all the names in the source to relevant places where the name was introduced. It also generates -helpful error messages, like typo suggestions or traits to import. +helpful error messages, like typo suggestions, traits to import or lints about +unused items. + +A successful run of the name resolution (`Resolver::resolve_crate`) creates kind +of an index the rest of the compilation may use to ask about the present names +(through the `hir::lowering::Resolver` interface). The name resolution lives in the `librustc_resolve` crate, with the meat in `lib.rs` and some helpers or symbol-type specific logic in the other modules. @@ -72,6 +77,8 @@ fn do_something(val: T) { // <- New rib in both types and values (1) Because the rules for different namespaces are a bit different, each namespace has its own independent rib stack that is constructed in parallel to the others. +In addition, there's also a rib stack for local labels (eg. names of loops or +blocks), which isn't a full namespace in its own right. ## Overall strategy From 8a005f5dac2743212ec045e2116a95e67f78ea7c Mon Sep 17 00:00:00 2001 From: Phlosioneer Date: Tue, 6 Mar 2018 20:01:09 -0500 Subject: [PATCH 0124/1812] Fix typo in conventions.md --- src/conventions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conventions.md b/src/conventions.md index f7ef86f11..db531c58c 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -132,7 +132,7 @@ we do not currently run rustfmt all the time, that can introduce a lot of noise into your commit. Please isolate that into its own commit. This also makes rebases a lot less painful, since rustfmt tends to cause a lot of merge conflicts, and having those isolated -into their own commit makes htem easier to resolve. +into their own commit makes them easier to resolve. **No merges.** We do not allow merge commits into our history, other than those by bors. If you get a merge conflict, rebase instead via a From 6660e4466a0263aadf04f754b1ec85d49ccd2825 Mon Sep 17 00:00:00 2001 From: "Adam C. Foltzer" Date: Mon, 5 Mar 2018 12:18:33 -0800 Subject: [PATCH 0125/1812] Fix typos --- src/incremental-compilation.md | 2 +- src/query.md | 2 +- src/trait-resolution.md | 4 ++-- src/type-inference.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/incremental-compilation.md b/src/incremental-compilation.md index dc4d06c6c..6f5b48cca 100644 --- a/src/incremental-compilation.md +++ b/src/incremental-compilation.md @@ -114,7 +114,7 @@ This can lead to ICEs and other problems in the compiler. ## Improvements to the basic algorithm -In the description basic algorithm, we said that at the end of +In the description of the basic algorithm, we said that at the end of compilation we would save the results of all the queries that were performed. In practice, this can be quite wasteful – many of those results are very cheap to recompute, and serializing and deserializing diff --git a/src/query.md b/src/query.md index 481b4fed3..33d2b3bac 100644 --- a/src/query.md +++ b/src/query.md @@ -141,7 +141,7 @@ They return the result of the query. #### How providers are setup When the tcx is created, it is given the providers by its creator using -the `Providers` struct. This struct is generate by the macros here, but it +the `Providers` struct. This struct is generated by the macros here, but it is basically a big list of function pointers: ```rust diff --git a/src/trait-resolution.md b/src/trait-resolution.md index 1cad488ac..28176d740 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -263,13 +263,13 @@ Confirmation is where an error would be reported because the impl specified that `Target` would be `usize`, but the obligation reported `char`. Hence the result of selection would be an error. -Note that the candidate impl is chosen base on the `Self` type, but +Note that the candidate impl is chosen based on the `Self` type, but confirmation is done based on (in this case) the `Target` type parameter. ### Selection during translation As mentioned above, during type checking, we do not store the results of trait -selection. At trans time, repeat the trait selection to choose a particular +selection. At trans time, we repeat the trait selection to choose a particular impl for each method call. In this second selection, we do not consider any where-clauses to be in scope because we know that each resolution will resolve to a particular impl. diff --git a/src/type-inference.md b/src/type-inference.md index c4307ce7f..8812d34d7 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -39,7 +39,7 @@ for some fresh `'cx` and `'tcx` – the latter corresponds to the lifetime of this temporary arena, and the `'cx` is the lifetime of the `InferCtxt` itself. (Again, see the [`ty` chapter][ty-ch] for more details on this setup.) -The `tcx.infer_ctxt` method actually returns a build, which means +The `tcx.infer_ctxt` method actually returns a builder, which means there are some kinds of configuration you can do before the `infcx` is created. See `InferCtxtBuilder` for more information. From f04757a901faa72f6ce3711e87ce3c323ec91885 Mon Sep 17 00:00:00 2001 From: vishalsodani Date: Sat, 3 Mar 2018 09:58:45 +0530 Subject: [PATCH 0126/1812] Add info about StringReader for #50 --- src/code-index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/code-index.md b/src/code-index.md index b1eb3546a..2395feaf6 100644 --- a/src/code-index.md +++ b/src/code-index.md @@ -8,5 +8,6 @@ Item | Kind | Short description | Chapter | ----------------|----------|-----------------------------|--------------------|------------------- `CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser](the-parser.html) | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) `ParseSess` | struct | This struct contains information about a parsing session | [The parser](the-parser.html) | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) +`StringReader` | struct | This struct helps in lexing source code into tokens | [The parser](the-parser.html) | [src/libsyntax/parse/lexer/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules](ty.html) | [src/librustc/ty/trait_def.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/trait_def.rs) `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) From 86c5f6c9b4cc70fefa87b40c91b431e3a31b4949 Mon Sep 17 00:00:00 2001 From: Vishal Sodani Date: Fri, 9 Mar 2018 13:52:57 +0530 Subject: [PATCH 0127/1812] Better explanation for StringReader --- src/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/code-index.md b/src/code-index.md index 2395feaf6..6a500abba 100644 --- a/src/code-index.md +++ b/src/code-index.md @@ -8,6 +8,6 @@ Item | Kind | Short description | Chapter | ----------------|----------|-----------------------------|--------------------|------------------- `CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser](the-parser.html) | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) `ParseSess` | struct | This struct contains information about a parsing session | [The parser](the-parser.html) | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) -`StringReader` | struct | This struct helps in lexing source code into tokens | [The parser](the-parser.html) | [src/libsyntax/parse/lexer/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs) +`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser](the-parser.html) | [src/libsyntax/parse/lexer/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules](ty.html) | [src/librustc/ty/trait_def.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/trait_def.rs) `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) From 479d914ff009a0372427b42f3796f5937297644f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 27 Feb 2018 05:50:43 -0500 Subject: [PATCH 0128/1812] work on traits chapters --- src/SUMMARY.md | 13 +- src/trait-resolution.md | 7 +- src/traits-associated-types.md | 143 +++++++++++++++++ src/traits-bibliography.md | 28 ++++ src/traits-canonicalization.md | 93 +++++++++++ src/traits-goals-and-clauses.md | 148 ++++++++++++++++++ src/traits-lowering-rules.md | 267 ++++++++++++++++++++++++++++++++ src/traits-lowering-to-logic.md | 182 ++++++++++++++++++++++ src/traits-regions.md | 3 + src/traits-wf.md | 11 ++ src/traits.md | 18 +++ src/type-inference.md | 2 + 12 files changed, 912 insertions(+), 3 deletions(-) create mode 100644 src/traits-associated-types.md create mode 100644 src/traits-bibliography.md create mode 100644 src/traits-canonicalization.md create mode 100644 src/traits-goals-and-clauses.md create mode 100644 src/traits-lowering-rules.md create mode 100644 src/traits-lowering-to-logic.md create mode 100644 src/traits-regions.md create mode 100644 src/traits-wf.md create mode 100644 src/traits.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ab9da7295..1c5bc284d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -17,10 +17,19 @@ - [The HIR (High-level IR)](./hir.md) - [The `ty` module: representing types](./ty.md) - [Type inference](./type-inference.md) -- [Trait resolution](./trait-resolution.md) +- [Trait solving (old-style)](./trait-resolution.md) - [Higher-ranked trait bounds](./trait-hrtb.md) - [Caching subtleties](./trait-caching.md) - - [Speciailization](./trait-specialization.md) + - [Specialization](./trait-specialization.md) +- [Trait solving (new-style)](./traits.md) + - [Canonicalization](./traits-canonicalization.md) + - [Lowering to logic](./traits-lowering-to-logic.md) + - [Goals and clauses](./traits-goals-and-clauses.md) + - [Lowering rules](./traits-lowering-rules.md) + - [Equality and associated types](./traits-associated-types.md) + - [Region constraints](./traits-regions.md) + - [Well-formedness checking](./traits-wf.md) + - [Bibliography](./traits-bibliography.md) - [Type checking](./type-checking.md) - [The MIR (Mid-level IR)](./mir.md) - [MIR construction](./mir-construction.md) diff --git a/src/trait-resolution.md b/src/trait-resolution.md index 28176d740..cccfcd54b 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -1,8 +1,13 @@ -# Trait resolution +# Trait resolution (old-style) This chapter describes the general process of _trait resolution_ and points out some non-obvious things. +**Note:** This chapter (and its subchapters) describe how the trait +solver **currently** works. However, we are in the process of +designing a new trait solver. If you'd prefer to read about *that*, +see [the traits chapter](./traits.html). + ## Major concepts Trait resolution is the process of pairing up an impl with each diff --git a/src/traits-associated-types.md b/src/traits-associated-types.md new file mode 100644 index 000000000..a640bf032 --- /dev/null +++ b/src/traits-associated-types.md @@ -0,0 +1,143 @@ +# Equality and associated types + +This section covers how the trait system handles equality between +associated types. The full system consists of several moving parts, +which we will introduce one by one: + +- Projection and the `Normalize` predicate +- Skolemization +- The `ProjectionEq` predicate +- Integration with unification + +## Associated type projection and normalization + +When a trait defines an associated type (e.g., +[the `Item` type in the `IntoIterator` trait][intoiter-item]), that +type can be referenced by the user using an **associated type +projection** like ` as IntoIterator>::Item`. (Often, +though, people will use the shorthand syntax `T::Item` -- presently, +that syntax is expanded during +["type collection"](./type-checking.html) into the explicit form, +though that is something we may want to change in the future.) + +In some cases, associated type projections can be **normalized** -- +that is, simplified -- based on the types given in an impl. So, to +continue with our example, the impl of `IntoIterator` for `Option` +declares (among other things) that `Item = T`: + +```rust +impl IntoIterator for Option { + type Item = T; + .. +} +``` + +This means we can normalize the projection ` as +IntoIterator>::Item` to just `u32`. + +In this case, the projection was a "monomorphic" one -- that is, it +did not have any type parameters. Monomorphic projections are special +because they can **always** be fully normalized -- but often we can +normalize other associated type projections as well. For example, +` as IntoIterator>::Item` (where `?T` is an inference +variable) can be normalized to just `?T`. + +In our logic, normalization is defined by a predicate +`Normalize`. The `Normalize` clauses arise only from +impls. For example, the `impl` of `IntoIterator` for `Option` that +we saw above would be lowered to a program clause like so: + + forall { + Normalize( as IntoIterator>::Item -> T) + } + +(An aside: since we do not permit quantification over traits, this is +really more like a family of predicates, one for each associated +type.) + +We could apply that rule to normalize either of the examples that +we've seen so far. + +## Skolemized associated types + +Sometimes however we want to work with associated types that cannot be +normalized. For example, consider this function: + +```rust +fn foo(...) { ... } +``` + +In this context, how would we normalize the type `T::Item`? Without +knowing what `T` is, we can't really do so. To represent this case, we +introduce a type called a **skolemized associated type +projection**. This is written like so `(IntoIterator::Item)`. You +may note that it looks a lot like a regular type (e.g., `Option`), +except that the "name" of the type is `(IntoIterator::Item)`. This is +not an accident: skolemized associated type projections work just like +ordinary types like `Vec` when it comes to unification. That is, +they are only considered equal if (a) they are both references to the +same associated type, like `IntoIterator::Item` and (b) their type +arguments are equal. + +Skolemized associated types are never written directly by the user. +They are used internally by the trait system only, as we will see +shortly. + +## Projection equality + +So far we have seen two ways to answer the question of "When can we +consider an associated type projection equal to another type?": + +- the `Normalize` predicate could be used to transform associated type + projections when we knew which impl was applicable; +- **skolemized** associated types can be used when we don't. + +We now introduce the `ProjectionEq` predicate to bring those two cases +together. The `ProjectionEq` predicate looks like so: + + ProjectionEq(::Item = U) + +and we will see that it can be proven *either* via normalization or +skolemization. As part of lowering an associated type declaration from +some trait, we create two program clauses for `ProjectionEq`: + + forall { + ProjectionEq(::Item = U) :- + Normalize(::Item -> U) + } + + forall { + ProjectionEq(::Item = (IntoIterator::Item)) + } + +These are the only two `ProjectionEq` program clauses we ever make for +any given associated item. + +## Integration with unification + +Now we are ready to discuss how associated type equality integrates +with unification. As described in the +[type inference](./type-inference.html) section, unification is +basically a procedure with a signature like this: + + Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution> + +In other words, we try to unify two things A and B. That procedure +might just fail, in which case we get back `Err(NoSolution)`. This +would happen, for example, if we tried to unify `u32` and `i32`. + +The key point is that, on success, unification can also give back to +us a set of subgoals that still remain to be proven (it can also give +back region constraints, but those are not relevant here). + +Whenever unification encounters an (unskolemized!) associated type +projection P being equated with some other type T, it always succeeds, +but it produces a subgoal `ProjectionEq(P = T)` that is propagated +back up. Thus it falls to the ordinary workings of the trait system +to process that constraint. + +(If we unify two projections P1 and P2, then unification produces a +variable X and asks us to prove that `ProjectionEq(P1 = X)` and +`ProjectionEq(P2 = X)`. That used to be needed in an older system to +prevent cycles; I rather doubt it still is. -nmatsakis) + diff --git a/src/traits-bibliography.md b/src/traits-bibliography.md new file mode 100644 index 000000000..d9ff912c7 --- /dev/null +++ b/src/traits-bibliography.md @@ -0,0 +1,28 @@ +# Bibliography + +If you'd like to read more background material, here are some +recommended texts and papers: + +[Programming with Higher-order Logic][phl], by Dale Miller and Gopalan +Nadathur, covers the key concepts of Lambda prolog. Although it's a +slim little volume, it's the kind of book where you learn something +new every time you open it. + +[phl]: https://www.amazon.com/Programming-Higher-Order-Logic-Dale-Miller/dp/052187940X + + + +["A proof procedure for the logic of Hereditary Harrop formulas"][pphhf], +by Gopalan Nadathur. This paper covers the basics of universes, +environments, and Lambda Prolog-style proof search. Quite readable. + +[pphhf]: https://dl.acm.org/citation.cfm?id=868380 + + + +["A new formulation of tabled resolution with delay"][nftrd], by +[Theresa Swift]. This paper gives a kind of abstract treatment of the +SLG formulation that is the basis for our on-demand solver. + +[nftrd]: https://dl.acm.org/citation.cfm?id=651202 +[ts]: http://www3.cs.stonybrook.edu/~tswift/ diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md new file mode 100644 index 000000000..35352d605 --- /dev/null +++ b/src/traits-canonicalization.md @@ -0,0 +1,93 @@ +# Canonicalization + +Canonicalization is the process of **isolating** an inference value +from its context. It is really based on a very simple concept: every +[inference variable](./type-inference.html#vars) is always in one of two +states: either it is **unbound**, in which case we don't know yet what +type it is, or it is **bound**, in which case we do. So to isolate +some thing T from its environment, we just walk down and find the +unbound variables that appear in T; those variables get renumbered in +a canonical order (left to right, for the most part, but really it +doesn't matter as long as it is consistent). + +So, for example, if we have the type `X = (?T, ?U)`, where `?T` and +`?U` are distinct, unbound inference variables, then the canonical +form of `X` would be `(?0, ?1)`, where `?0` and `?1` represent these +**canonical placeholders**. Note that the type `Y = (?U, ?T)` also +canonicalizes to `(?0, ?1)`. But the type `Z = (?T, ?T)` would +canonicalize to `(?0, ?0)` (as would `(?U, ?U)`). In other words, the +exact identity of the inference variables is not important -- unless +they are repeated. + +We use this to improve caching as well as to detect cycles and other +things during trait resolution. Roughly speaking, the idea is that if +two trait queries have the same canonicalize form, then they will get +the same answer -- modulo the precise identities of the variables +involved. + +To see how it works, imagine that we are asking to solve the following +trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound. +This query contains two unbound variables, but it also contains the +lifetime `'static`. The trait system generally ignores all lifetimes +and treats them equally, so when canonicalizing, we will *also* +replace any [free lifetime](./background.html#free-vs-bound) with a +canonical variable. Therefore, we get the following result: + + ?0: Foo<'?1, ?2> + +Sometimes we write this differently, like so: + + for { ?0: Foo<'?1, ?2> } + +This `for<>` gives some information about each of the canonical +variables within. In this case, I am saying that `?0` is a type +(`T`), `?1` is a lifetime (`L`), and `?2` is also a type (`T`). The +`canonicalize` method *also* gives back a `CanonicalVarValues` array +with the "original values" for each canonicalized variable: + + [?A, 'static, ?B] + +Now we do the query and get back some result R. As part of that +result, we'll have an array of values for the canonical inputs. For +example, the canonical result might be: + +``` +for<2> { + values = [ Vec, '1, ?0 ] + ^^ ^^ ^^ these are variables in the result! + ... +} +``` + +Note that this result is itself canonical and may include some +variables (in this case, `?0`). + +What we want to do conceptually is to (a) instantiate each of the +canonical variables in the result with a fresh inference variable +and then (b) unify the values in the result with the original values. +Doing step (a) would yield a result of + +``` +{ + values = [ Vec, '?X, ?C ] + ^^ ^^^ fresh inference variables in `self` + .. +} +``` + +Step (b) would then unify: + +``` +?A with Vec +'static with '?X +?B with ?C +``` + +(What we actually do is a mildly optimized variant of that: Rather +than eagerly instantiating all of the canonical values in the result +with variables, we instead walk the vector of values, looking for +cases where the value is just a canonical variable. In our example, +`values[2]` is `?C`, so that we means we can deduce that `?C := ?B and +`'?X := 'static`. This gives us a partial set of values. Anything for +which we do not find a value, we create an inference variable.) + diff --git a/src/traits-goals-and-clauses.md b/src/traits-goals-and-clauses.md new file mode 100644 index 000000000..ad1655726 --- /dev/null +++ b/src/traits-goals-and-clauses.md @@ -0,0 +1,148 @@ +# Goals and clauses + +In logic programming terms, a **goal** is something that you must +prove and a **clause** is something that you know is true. As +described in the [lowering to logic](./traits-lowering-to-logic.html) +chapter, Rust's trait solver is based on an extension of hereditary +harrop (HH) clauses, which extend traditional Prolog Horn clauses with +a few new superpowers. + +## Goals and clauses meta structure + +In Rust's solver, **goals** and **clauses** have the following forms +(note that the two definitions reference one another): + + Goal = DomainGoal + | Goal && Goal + | Goal || Goal + | exists { Goal } // existential quantification + | forall { Goal } // universal quantification + | if (Clause) { Goal } // implication + + Clause = DomainGoal + | Clause :- Goal // if can prove Goal, then Clause is true + | Clause && Clause + | forall { Clause } + + K = // a "kind" + | + +The proof procedure for these sorts of goals is actually quite +straightforward. Essentially, it's a form of depth-first search. The +paper +["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] +gives the details. + +[pphhf]: ./traits-bibliography.html#pphhf + + + +## Domain goals + +To define the set of *domain goals* in our system, we need to first +introduce a few simple formulations. A **trait reference** consists of +the name of a trait allow with a suitable set of inputs P0..Pn: + + TraitRef = P0: TraitName + +So, for example, `u32: Display` is a trait reference, as is `Vec: +IntoIterator`. Note that Rust surface syntax also permits some extra +things, like associated type bindings (`Vec: IntoIterator`), that are not part of a trait reference. + +A **projection** consists of a an associated item reference along with +its inputs P0..Pm: + + Projection = >::AssocItem + +Given that, we can define a `DomainGoal` as follows: + + DomainGoal = Implemented(TraitRef) + | ProjectionEq(Projection = Type) + | Normalize(Projection -> Type) + | FromEnv(TraitRef) + | FromEnv(Projection = Type) + | WellFormed(Type) + | WellFormed(TraitRef) + | WellFormed(Projection = Type) + | Outlives(Type, Region) + | Outlives(Region, Region) + +- `Implemented(TraitRef)` -- true if the given trait is + implemented for the given input types and lifetimes +- `FromEnv(TraitEnv)` -- true if the given trait is *assumed* to be implemented; + that is, if it can be derived from the in-scope where clauses + - as we'll see in the section on lowering, `FromEnv(X)` implies + `Implemented(X)` but not vice versa. This distinction is crucial + to [implied bounds]. +- `ProjectionEq(Projection = Type)` -- the given associated type `Projection` is equal + to `Type`; see [the section on associated types](./traits-associated-types.html) +- `Normalize(Projection -> Type)` -- the given associated type `Projection` can be normalized + to `Type` + - as discussed in [the section on associated types](./traits-associated-types.html), + `Normalize` implies `ProjectionEq` but not vice versa +- `WellFormed(..)` -- these goals imply that the given item is + *well-formed* + - well-formedness is important to [implied bounds]. + + + +## Coinductive goals + +Most goals in our system are "inductive". In an inductive goal, +circular reasoning is disallowed. Consider this example clause: + + Implemented(Foo: Bar) :- + Implemented(Foo: Bar). + +Considered inductively, this clause is useless: if we are trying to +prove `Implemented(Foo: Bar)`, we would then recursively have to prove +`Implemented(Foo: Bar)`, and that cycle would continue ad infinitum +(the trait solver will terminate here, it would just consider that +`Implemented(Foo: Bar)` is not known to be true). + +However, some goals are *co-inductive*. Simply put, this means that +cycles are OK. So, if `Bar` were a co-inductive trait, then the rule +above would be perfectly valid, and it would indicate that +`Implemented(Foo: Bar)` is true. + +*Auto traits* are one example in Rust where co-inductive goals are used. +Consider the `Send` trait, and imagine that we have this struct: + +```rust +struct Foo { + next: Option> +} +``` + +The default rules for auto traits say that `Foo` is `Send` if the +types of its fields are `Send`. Therefore, we would have a rule like + + Implemented(Foo: Send) :- + Implemented(Option>: Send). + +As you can probably imagine, proving that `Option>: Send` is +going to wind up circularly requiring us to prove that `Foo: Send` +again. So this would be an example where we wind up in a cycle -- but +that's ok, we *do* consider `Foo: Send` to hold, even though it +references itself. + +In general, co-inductive traits are used in Rust trait solving when we +want to enumerate a fixed set of possibilities. In the case of auto +traits, we are enumerating the set of reachable types from a given +starting point (i.e., `Foo` can reach values of type +`Option>`, which implies it can reach values of type +`Box`, and then of type `Foo`, and then the cycle is complete). + +In addition to auto traits, `WellFormed` predicates are co-inductive. +These are used to achieve a similar "enumerate all the cases" pattern, +as described in the section on [implied bounds]. + +[implied bounds]: ./traits-lowering-rules.html#implied-bounds + +## Incomplete chapter + +Some topics yet to be written: + +- Elaborate on the proof procedure +- SLG solving -- introduce negative reasoning diff --git a/src/traits-lowering-rules.md b/src/traits-lowering-rules.md new file mode 100644 index 000000000..d096b4364 --- /dev/null +++ b/src/traits-lowering-rules.md @@ -0,0 +1,267 @@ +# Lowering rules + +This section gives the complete lowering rules for Rust traits into +[program clauses][pc]. These rules reference the [domain goals][dg] defined in +an earlier section. + +[pc]: ./traits-goals-and-clauses.html +[dg]: ./traits-goals-and-clauses.html#domain-goals + +## Notation + +The nonterminal `Pi` is used to mean some generic *parameter*, either a +named lifetime like `'a` or a type paramter like `A`. + +The nonterminal `Ai` is used to mean some generic *argument*, which +might be a lifetime like `'a` or a type like `Vec`. + +When defining the lowering rules, we will give goals and clauses in +the [notation given in this section](./traits-goals-and-clauses.html). +We sometimes insert "macros" like `LowerWhereClause!` into these +definitions; these macros reference other sections within this chapter. + +## Lowering where clauses + +When used in a goal position, where clauses can be mapped directly +[domain goals][dg], as follows: + +- `A0: Foo` maps to `Implemented(A0: Foo)`. +- `A0: Foo` maps to `ProjectionEq(>::Item = T)` +- `T: 'r` maps to `Outlives(T, 'r)` +- `'a: 'b` maps to `Outlives('a, 'b)` + +In the rules below, we will use `WC` to indicate where clauses that +appear in Rust syntax; we will then use the same `WC` to indicate +where those where clauses appear as goals in the program clauses that +we are producing. In that case, the mapping above is used to convert +from the Rust syntax into goals. + +### Transforming the lowered where clauses + +In addition, in the rules below, we sometimes do some transformations +on the lowered where clauses, as defined here: + +- `FromEnv(WC)` -- this indicates that: + - `Implemented(TraitRef)` becomes `FromEnv(TraitRef)` + - `ProjectionEq(Projection = Ty)` becomes `FromEnv(Projection = Ty)` + - other where-clauses are left intact +- `WellFormed(WC)` -- this indicates that: + - `Implemented(TraitRef)` becomes `WellFormed(TraitRef)` + - `ProjectionEq(Projection = Ty)` becomes `WellFormed(Projection = Ty)` + +*TODO*: I suspect that we want to alter the outlives relations too, +but Chalk isn't modeling those right now. + +## Lowering traits + +Given a trait definition + +```rust +trait Trait // P0 == Self +where WC +{ + // trait items +} +``` + +we will produce a number of declarations. This section is focused on +the program clauses for the trait header (i.e., the stuff outside the +`{}`); the [section on trait items](#trait-items) covers the stuff +inside the `{}`. + +### Trait header + +From the trait itself we mostly make "meta" rules that setup the +relationships between different kinds of domain goals. The first dush +rule from the trait header creates the mapping between the `FromEnv` +and `Implemented` predicates: + + forall { + Implemented(Self: Trait) :- FromEnv(Self: Trait + +#### Implied bounds + +The next few clauses have to do with implied bounds (see also +[RFC 2089]). For each trait, we produce two clauses: + +[RFC 2089]: https://rust-lang.github.io/rfcs/2089-implied-bounds.html + + // For each where clause WC: + forall { + FromEnv(WC) :- FromEnv(Self: Trait { + WellFormed(Self: Trait) :- Implemented(Self: Trait), WellFormed(WC) + } + +This `WellFormed` rule states that `T: Trait` is well-formed if (a) +`T: Trait` is implemented and (b) all the where-clauses declared on +`Trait` are well-formed (and hence they are implemented). Remember +that the `WellFormed` predicate is +[coinductive](./traits-goals-and-clauses.html#coinductive); in this +case, it is serving as a kind of "carrier" that allows us to enumerate +all the where clauses that are transitively implied by `T: Trait`. + +An example: + +```rust +trait Foo: A + Bar { } +trait Bar: B + Foo { } +trait A { } +trait B { } +``` + +Here, the transitive set of implications for `T: Foo` are `T: A`, `T: Bar`, and `T: B`. +And indeed if we were to try to prove `WellFormed(T: Foo)`, we would have to prove each +one of those: + +- `WellFormed(T: Foo)` + - `Implemented(T: Foo)` + - `WellFormed(T: A)` + - `Implemented(T: A)` + - `WellFormed(T: Bar)` + - `Implemented(T: Bar)` + - `WellFormed(T: B)` + - `Implemented(T: Bar)` + - `WellFormed(T: Foo)` -- cycle, true coinductively + +This `WellFormed` predicate is only used when proving that impls are +well-formed -- basically, for each impl of some trait ref `TraitRef`, +we must that `WellFormed(TraitRef)`. This in turn justifies the +implied bounds rules that allow us to extend the set of `FromEnv` +items. + + + +## Lowering trait items + +### Associated type declarations + +Given a trait that declares a (possibly generic) associated type: + +```rust +trait Trait // P0 == Self +where WC +{ + type AssocType: Bounds where WC1; +} +``` + +We will produce a number of program clases. The first two define +the rules by which `ProjectionEq` can succeed; these two clauses are discussed +in detail in the [section on associated types](./traits-associated-types.html). + + // ProjectionEq can succeed by normalizing: + forall { + ProjectionEq(>::AssocType = U) :- + Normalize(>::AssocType -> U) + } + + // ProjectionEq can succeed by skolemizing: + forall { + ProjectionEq( + >::AssocType = + (Trait::AssocType) + ) :- + // But only if the trait is implemented, and the conditions from + // the associated type are met as well: + Implemented(Self: Trait), + WC1 + } + +The next rule covers implied bounds for the projection. In particular, +the `Bounds` declared on the associated type must be proven to hold to +show that the impl is well-formed, and hence we can rely on them from +elsewhere. + + // XXX how exactly should we set this up? Have to be careful; + // presumably this has to be a kind of `FromEnv` setup. + +### Lowering function and constant declarations + +Chalk didn't model functions and constants, but I would eventually +like to treat them exactly like normalization. See [the section on function/constant +values below](#constant-vals) for more details. + +## Lowering impls + +Given an impl of a trait: + +```rust +impl Trait for A0 +where WC +{ + // zero or more impl items +} +``` + +Let `TraitRef` be the trait reference `A0: Trait`. Then we +will create the following rules: + + forall { + Implemented(TraitRef) :- WC + } + +In addition, we will lower all of the *impl items*. + +## Lowering impl items + +### Associated type values + +Given an impl that contains: + +```rust +impl Trait for A0 +where WC +{ + type AssocType: Bounds where WC1 = T; +} +``` + +We produce the following rule: + + forall { + forall { + Normalize(>::AssocType -> T) :- + WC, WC1 + } + } + +Note that `WC` and `WC1` both encode where-clauses that the impl can +rely on, whereas the bounds `Bounds` on the associated type are things +that the impl must prove (see the well-formedness checking). + + + +### Function and constant values + +Chalk didn't model functions and constants, but I would eventually +like to treat them exactly like normalization. This presumably +involves adding a new kind of parameter (constant), and then having a +`NormalizeValue` domain goal. This is *to be written* because the +details are a bit up in the air. + + diff --git a/src/traits-lowering-to-logic.md b/src/traits-lowering-to-logic.md new file mode 100644 index 000000000..7b1c2ed6b --- /dev/null +++ b/src/traits-lowering-to-logic.md @@ -0,0 +1,182 @@ +# Lowering to logic + +The key observation here is that the Rust trait system is basically a +kind of logic, and it can be mapped onto standard logical inference +rules. We can then look for solutions to those inference rules in a +very similar fashion to how e.g. a [Prolog] solver works. It turns out +that we can't *quite* use Prolog rules (also called Horn clauses) but +rather need a somewhat more expressive variant. + +[Prolog]: https://en.wikipedia.org/wiki/Prolog + +## Rust traits and logic + +One of the first observations is that the Rust trait system is +basically a kind of logic. As such, we can map our struct, trait, and +impl declarations into logical inference rules. For the most part, +these are basically Horn clauses, though we'll see that to capture the +full richness of Rust -- and in particular to support generic +programming -- we have to go a bit further than standard Horn clauses. + +To see how this mapping works, let's start with an example. Imagine +we declare a trait and a few impls, like so: + +```rust +trait Clone { } +impl Clone for usize { } +impl Clone for Vec where T: Clone { } +``` + +We could map these declarations to some Horn clauses, written in a +Prolog-like notation, as follows: + +``` +Clone(usize). +Clone(Vec) :- Clone(?T). +``` + +In Prolog terms, we might say that `Clone(Foo)` -- where `Foo` is some +Rust type -- is a *predicate* that represents the idea that the type +`Foo` implements `Clone`. These rules are **program clauses**; they +state the conditions under which that predicate can be proven (i.e., +considered true). So the first rule just says "Clone is implemented +for `usize`". The next rule says "for any type `?T`, Clone is +implemented for `Vec` if clone is implemented for `?T`". So +e.g. if we wanted to prove that `Clone(Vec>)`, we would do +so by applying the rules recursively: + +- `Clone(Vec>)` is provable if: + - `Clone(Vec)` is provable if: + - `Clone(usize)` is provable. (Which is is, so we're all good.) + +But now suppose we tried to prove that `Clone(Vec)`. This would +fail (after all, I didn't give an impl of `Clone` for `Bar`): + +- `Clone(Vec)` is provable if: + - `Clone(Bar)` is provable. (But it is not, as there are no applicable rules.) + +We can easily extend the example above to cover generic traits with +more than one input type. So imagine the `Eq` trait, which declares +that `Self` is equatable with a value of type `T`: + +```rust +trait Eq { ... } +impl Eq for usize { } +impl> Eq> for Vec { } +``` + +That could be mapped as follows: + +``` +Eq(usize, usize). +Eq(Vec, Vec) :- Eq(?T, ?U). +``` + +So far so good. + +## Type-checking normal functions + +OK, now that we have defined some logical rules that are able to +express when traits are implemented and to handle associated types, +let's turn our focus a bit towards **type-checking**. Type-checking is +interesting because it is what gives us the goals that we need to +prove. That is, everything we've seen so far has been about how we +derive the rules by which we can prove goals from the traits and impls +in the program; but we are also interesting in how derive the goals +that we need to prove, and those come from type-checking. + +Consider type-checking the function `foo()` here: + +```rust +fn foo() { bar::() } +fn bar() { } +``` + +This function is very simple, of course: all it does is to call +`bar::()`. Now, looking at the definition of `bar()`, we can see +that it has one where-clause `U: Eq`. So, that means that `foo()` will +have to prove that `usize: Eq` in order to show that it can call `bar()` +with `usize` as the type argument. + +If we wanted, we could write a Prolog predicate that defines the +conditions under which `bar()` can be called. We'll say that those +conditions are called being "well-formed": + +``` +barWellFormed(?U) :- Eq(?U). +``` + +Then we can say that `foo()` type-checks if the reference to +`bar::` (that is, `bar()` applied to the type `usize`) is +well-formed: + +``` +fooTypeChecks :- barWellFormed(usize). +``` + +If we try to prove the goal `fooTypeChecks`, it will succeed: + +- `fooTypeChecks` is provable if: + - `barWellFormed(usize)`, which is provable if: + - `Eq(usize)`, which is provable because of an impl. + +Ok, so far so good. Let's move on to type-checking a more complex function. + +## Type-checking generic functions: beyond Horn clauses + +In the last section, we used standard Prolog horn-clauses (augmented with Rust's +notion of type equality) to type-check some simple Rust functions. But that only +works when we are type-checking non-generic functions. If we want to type-check +a generic function, it turns out we need a stronger notion of goal than Prolog +can be provide. To see what I'm talking about, let's revamp our previous +example to make `foo` generic: + +```rust +fn foo() { bar::() } +fn bar() { } +``` + +To type-check the body of `foo`, we need to be able to hold the type +`T` "abstract". That is, we need to check that the body of `foo` is +type-safe *for all types `T`*, not just for some specific type. We might express +this like so: + +``` +fooTypeChecks :- + // for all types T... + forall { + // ...if we assume that Eq(T) is provable... + if (Eq(T)) { + // ...then we can prove that `barWellFormed(T)` holds. + barWellFormed(T) + } + }. +``` + +This notation I'm using here is the notation I've been using in my +prototype implementation; it's similar to standard mathematical +notation but a bit Rustified. Anyway, the problem is that standard +Horn clauses don't allow universal quantification (`forall`) or +implication (`if`) in goals (though many Prolog engines do support +them, as an extension). For this reason, we need to accept something +called "first-order hereditary harrop" (FOHH) clauses -- this long +name basically means "standard Horn clauses with `forall` and `if` in +the body". But it's nice to know the proper name, because there is a +lot of work describing how to efficiently handle FOHH clauses; see for +example Gopalan Nadathur's excellent +["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] +in [the bibliography]. + +[the bibliography]: ./traits-bibliography.html +[pphhf]: ./traits-bibliography.html#pphhf + +It turns out that supporting FOHH is not really all that hard. And +once we are able to do that, we can easily describe the type-checking +rule for generic functions like `foo` in our logic. + +## Source + +This page is a lightly adapted version of a +[blog post by Nicholas Matsakis][lrtl]. + +[lrtl]: http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/ diff --git a/src/traits-regions.md b/src/traits-regions.md new file mode 100644 index 000000000..baa3582b6 --- /dev/null +++ b/src/traits-regions.md @@ -0,0 +1,3 @@ +# Region constraints + +*to be written* diff --git a/src/traits-wf.md b/src/traits-wf.md new file mode 100644 index 000000000..c002b8cc1 --- /dev/null +++ b/src/traits-wf.md @@ -0,0 +1,11 @@ +# Well-formedness checking + +This chapter is mostly *to be written*. WF checking, in short, has the +job of checking that the various declarations in a Rust program are +well-formed. This is the basis for implied bounds, and partly for that +reason, this checking can be surprisingly subtle! (For example, we +have to be sure that each impl proves the WF conditions declared on +the trait.) + + + diff --git a/src/traits.md b/src/traits.md new file mode 100644 index 000000000..28e27e82e --- /dev/null +++ b/src/traits.md @@ -0,0 +1,18 @@ +# Trait solving (new-style) + +🚧 This chapter describes "new-style" trait solving. This is still in +the process of being implemented; this chapter serves as a kind of +in-progress design document. If you would prefer to read about how the +current trait solver works, check out +[this chapter](./trait-resolution.html).🚧 + +Trait solving is based around a few key ideas: + +- [Canonicalization](./traits-canonicalization.html), which allows us to + extract types that contain inference variables in them from their + inference context, work with them, and then bring the results back + into the original context. +- [Lowering to logic](./traits-lowering-to-logic.html), which expresses + Rust traits in terms of standard logical terms. + +*more to come* diff --git a/src/type-inference.md b/src/type-inference.md index 8812d34d7..3795ea70e 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -43,6 +43,8 @@ The `tcx.infer_ctxt` method actually returns a builder, which means there are some kinds of configuration you can do before the `infcx` is created. See `InferCtxtBuilder` for more information. + + ## Inference variables The main purpose of the inference context is to house a bunch of From e4aaa9c7f9e23d24e8f5d566143c232631970014 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 9 Mar 2018 04:14:18 -0500 Subject: [PATCH 0129/1812] clarify how there are two traits chapters --- src/trait-resolution.md | 2 +- src/traits.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/trait-resolution.md b/src/trait-resolution.md index cccfcd54b..d6edcf68a 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -6,7 +6,7 @@ some non-obvious things. **Note:** This chapter (and its subchapters) describe how the trait solver **currently** works. However, we are in the process of designing a new trait solver. If you'd prefer to read about *that*, -see [the traits chapter](./traits.html). +see [*this* traits chapter](./traits.html). ## Major concepts diff --git a/src/traits.md b/src/traits.md index 28e27e82e..0098704d8 100644 --- a/src/traits.md +++ b/src/traits.md @@ -4,7 +4,7 @@ the process of being implemented; this chapter serves as a kind of in-progress design document. If you would prefer to read about how the current trait solver works, check out -[this chapter](./trait-resolution.html).🚧 +[this other chapter](./trait-resolution.html).🚧 Trait solving is based around a few key ideas: From 6f99f12c2acbceae307c43e53a05071aa434380b Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 9 Mar 2018 04:16:34 -0500 Subject: [PATCH 0130/1812] link to traits working group tracking issue --- src/traits.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/src/traits.md b/src/traits.md index 0098704d8..f0e67ffd4 100644 --- a/src/traits.md +++ b/src/traits.md @@ -1,10 +1,15 @@ # Trait solving (new-style) -🚧 This chapter describes "new-style" trait solving. This is still in -the process of being implemented; this chapter serves as a kind of +🚧 This chapter describes "new-style" trait solving. This is still in the +[process of being implemented][wg]; this chapter serves as a kind of in-progress design document. If you would prefer to read about how the current trait solver works, check out -[this other chapter](./trait-resolution.html).🚧 +[this other chapter](./trait-resolution.html). (By the way, if you +would like to help in hacking on the new solver, you will find +instructions for getting involved in the +[Traits Working Group tracking issue][wg].) 🚧 + +[wg]: https://github.com/rust-lang/rust/issues/48416 Trait solving is based around a few key ideas: From fd92491375f30b89050ebe51130112d1cee8896e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 9 Mar 2018 04:19:36 -0500 Subject: [PATCH 0131/1812] don't say 'thing' --- src/traits-canonicalization.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index 35352d605..8ab73a7ff 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -2,13 +2,15 @@ Canonicalization is the process of **isolating** an inference value from its context. It is really based on a very simple concept: every -[inference variable](./type-inference.html#vars) is always in one of two -states: either it is **unbound**, in which case we don't know yet what -type it is, or it is **bound**, in which case we do. So to isolate -some thing T from its environment, we just walk down and find the -unbound variables that appear in T; those variables get renumbered in -a canonical order (left to right, for the most part, but really it -doesn't matter as long as it is consistent). +[inference variable](./type-inference.html#vars) is always in one of +two states: either it is **unbound**, in which case we don't know yet +what type it is, or it is **bound**, in which case we do. So to +isolate some data-structure T that contains types/regions from its +environment, we just walk down and find the unbound variables that +appear in T; those variables get replaced with "canonical variables", +starting from zero and numbered in a fixed order (left to right, for +the most part, but really it doesn't matter as long as it is +consistent). So, for example, if we have the type `X = (?T, ?U)`, where `?T` and `?U` are distinct, unbound inference variables, then the canonical From 3c8a827a37a5c48661fdaf4e5b34806f528bffd9 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 9 Mar 2018 04:30:48 -0500 Subject: [PATCH 0132/1812] expand reorder topic list slightly --- src/SUMMARY.md | 2 +- src/traits-canonicalization.md | 5 +++-- src/traits.md | 22 ++++++++++++++++------ 3 files changed, 20 insertions(+), 9 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 1c5bc284d..9c1920d32 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -22,8 +22,8 @@ - [Caching subtleties](./trait-caching.md) - [Specialization](./trait-specialization.md) - [Trait solving (new-style)](./traits.md) - - [Canonicalization](./traits-canonicalization.md) - [Lowering to logic](./traits-lowering-to-logic.md) + - [Canonical queries](./traits-canonicalization.md) - [Goals and clauses](./traits-goals-and-clauses.md) - [Lowering rules](./traits-lowering-rules.md) - [Equality and associated types](./traits-associated-types.md) diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index 8ab73a7ff..9b71c8470 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -24,8 +24,9 @@ they are repeated. We use this to improve caching as well as to detect cycles and other things during trait resolution. Roughly speaking, the idea is that if two trait queries have the same canonicalize form, then they will get -the same answer -- modulo the precise identities of the variables -involved. +the same answer. That answer will be expressed in terms of the +canonical variables (`?0`, `?1`), which we can then map back to the +original variables (`?T`, `?U`). To see how it works, imagine that we are asking to solve the following trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound. diff --git a/src/traits.md b/src/traits.md index f0e67ffd4..18cb0c649 100644 --- a/src/traits.md +++ b/src/traits.md @@ -13,11 +13,21 @@ instructions for getting involved in the Trait solving is based around a few key ideas: -- [Canonicalization](./traits-canonicalization.html), which allows us to - extract types that contain inference variables in them from their - inference context, work with them, and then bring the results back - into the original context. - [Lowering to logic](./traits-lowering-to-logic.html), which expresses Rust traits in terms of standard logical terms. - -*more to come* + - The [goals and clauses](./traits-goals-and-clauses.html) chapter + describes the precise lowering rules we use. +- [Canonical queries](./traits-canonicalization.html), which allow us + to solve trait problems (like "is `Foo` implemented for the type + `Bar`?") once, and then apply that same result independently in many + different inference contexts. +- [Lazy normalization](./traits-associated-types.html), which is the + technique we use to accommodate associated types when figuring out + whether types are equal. +- [Region constraints](./traits-regions.md), which are accumulated + during trait solving but mostly ignored. This means that trait + solving effectively ignores the precise regions involved, always -- + but we still remember the constraints on them so that those + constraints can be checked by thet type checker. + +Note: this is not a complete list of topics. See the sidebar for more. From c3a35021d6e607ecc7b05573875b49d476ded8f6 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 05:32:47 -0500 Subject: [PATCH 0133/1812] add background material on trait queries --- src/SUMMARY.md | 8 +- src/traits-canonical-queries.md | 228 ++++++++++++++++++++++++++++++++ src/traits-canonicalization.md | 7 +- src/traits-slg.md | 1 + src/traits.md | 2 +- 5 files changed, 241 insertions(+), 5 deletions(-) create mode 100644 src/traits-canonical-queries.md create mode 100644 src/traits-slg.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 9c1920d32..95a5ee577 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -23,12 +23,14 @@ - [Specialization](./trait-specialization.md) - [Trait solving (new-style)](./traits.md) - [Lowering to logic](./traits-lowering-to-logic.md) - - [Canonical queries](./traits-canonicalization.md) - - [Goals and clauses](./traits-goals-and-clauses.md) - - [Lowering rules](./traits-lowering-rules.md) + - [Goals and clauses](./traits-goals-and-clauses.md) + - [Lowering rules](./traits-lowering-rules.md) + - [Canonical queries](./traits-canonical-queries.md) + - [Canonicalization](./traits-canonicalization.md) - [Equality and associated types](./traits-associated-types.md) - [Region constraints](./traits-regions.md) - [Well-formedness checking](./traits-wf.md) + - [The SLG solver](./traits-slg.md) - [Bibliography](./traits-bibliography.md) - [Type checking](./type-checking.md) - [The MIR (Mid-level IR)](./mir.md) diff --git a/src/traits-canonical-queries.md b/src/traits-canonical-queries.md new file mode 100644 index 000000000..ec861eb47 --- /dev/null +++ b/src/traits-canonical-queries.md @@ -0,0 +1,228 @@ +# Canonical queries + +The "start" of the trait system is the **canonical query** (these are +both queries in the more general sense of the word -- something you +would like to know the answer to -- and in the +[rustc-specific sense](./query.html)). The idea is that the type +checker or other parts of the system, may in the course of doing their +thing want to know whether some trait is implemented for some type +(e.g., is `u32: Debug` true?). Or they may want to +[normalize some associated type](./traits-associated-types.html). + +This section covers queries at a fairly high level of abstraction. The +subsections look a bit more closely at how these ideas are implemented +in rustc. + +## The traditional, interactive Prolog query + +In a traditional Prolog system, when you start a query, the solver +will run off and start supplying you with every possible answer it can +find. So given something like this: + + ?- Vec: AsRef + +The solver might answer: + + Vec: AsRef<[i32]> + continue? (y/n) + +This `continue` bit is interesting. The idea in Prolog is that the +solver is finding **all possible** instantiations of your query that +are true. In this case, if we instantiate `?U = [i32]`, then the query +is true (note that a traditional Prolog interface does not, directly, +tell us a value for `?U`, but we can infer one by unifying the +response with our original query -- Rust's solver gives back a +substitution instead). If we were to hit `y`, the solver might then +give us another possible answer: + + Vec: AsRef> + continue? (y/n) + +This answer derives from the fact that there is a reflexive impl +(`impl AsRef for T`) for `AsRef`. If were to hit `y` again, +then we might get back a negative response: + + no + +Naturally, in some cases, there may be no possible answers, and hence +the solver will just give me back `no` right away: + + ?- Box: Copy + no + +In some cases, there might be an infinite number of responses. So for +example if I gave this query, and I kept hitting `y`, then the solver +would never stop giving me back answers: + + ?- Vec: Clone + Vec: Clone + continue? (y/n) + Vec>: Clone + continue? (y/n) + Vec>>: Clone + continue? (y/n) + Vec>>>: Clone + continue? (y/n) + +As you can imagine, the solver will gleefully keep adding another +layer of `Box` until we ask it to stop, or it runs out of memory. + +Another interesting thing is that queries might still have variables +in them. For example: + + ?- Rc: Clone + +might produce the answer: + + Rc: Clone + continue? (y/n) + +After all, `Rc` is true **no matter what type `?T` is**. + +## A trait query in rustc + +The trait queries in rustc work somewhat differently. Instead of +trying to enumerate **all possible** answers for you, they are looking +for an **unambiguous** answer. In particular, when they tells you the +value for a type variable, that means that this is the **only possible +instantiation** that you could use, given the current set of impls and +where-clauses, that would be provable. (Internally within the solver, +though, they can potentially enumerate all possible answers. See +[the description of the SLG solver](./traits-slg.html) for details.) + +The response to a trait query in rustc is typically a +`Result, NoSolution>` (where the `T` will vary a bit +depending on the query itself). The `Err(NoSolution)` case indicates +that the query was false and had no answers (e.g., `Box: Copy`). +Otherwise, the `QueryResult` gives back information about the possible answer(s) +we did find. It consists of four parts: + +- **Certainty:** tells you how sure we are of this answer. It can have two values: + - `Proven` means that the result is known to be true. + - This might be the result for trying to prove `Vec: Clone`, + say, or `Rc: Clone`. + - `Ambiguous` means that there were things we could not yet prove to + be either true *or* false, typically because more type information + was needed. (We'll see an example shortly.) + - This might be the result for trying to prove `Vec: Clone`. +- **Var values:** Values for each of the unbound inference variables + (like `?T`) that appeared in your original query. (Remember that in Prolog, + we had to infer these.) + - As we'll see in the example below, we can get back var values even + for `Ambiguous` cases. +- **Region constraints:** these are relations that must hold between + the lifetimes that you supplied as inputs. We'll ignore these here, + but see the + [section on handling regions in traits](./traits-regions.html) for + more details. +- **Value:** The query result also comes with a value of type `T`. For + some specialized queries -- like normalizing associated types -- + this is used to carry back an extra result, but it's often just + `()`. + +### Examples + +Let's work through an example query to see what all the parts mean. +Consider [the `Borrow` trait][borrow]. This trait has a number of +impls; among them, there are these two (for clarify, I've written the +`Sized` bounds explicitly): + +[borrow]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html + +```rust +impl Borrow for T where T: ?Sized +impl Borrow<[T]> for Vec where T: Sized +``` + +**Example 1.** Imagine we are type-checking this (rather artificial) +bit of code: + +```rust +fn foo(a: A, vec_b: Option) where A: Borrow { } + +fn main() { + let mut t: Vec<_> = vec![]; // Type: Vec + let mut u: Option<_> = None; // Type: Option + foo(t, u); // Example 1: requires `Vec: Borrow` + ... +} +``` + +As the comments indicate, we first create two variables `t` and `u`; +`t` is an empty vector and `u` is a `None` option. Both of these +variables have unbound inference variables in their type: `?T` +represents the elements in the vector `t` and `?U` represents the +value stored in the option `u`. Next, we invoke `foo`; comparing the +signature of `foo` to its arguments, we wind up with `A = Vec` and +`B = ?U`.Therefore, the where clause on `foo` requires that `Vec: +Borrow`. This is thus our first example trait query. + +There are many possible solutions to the query `Vec: Borrow`; +for example: + +- `?U = Vec`, +- `?U = [?T]`, +- `?T = u32, ?U = [u32]` +- and so forth. + +Therefore, the result we get back would be as follows (I'm going to +ignore region constraints and the "value"): + +- Certainty: `Ambiguous` -- we're not sure yet if this holds +- Var values: `[?T = ?T, ?U = ?U]` -- we learned nothing about the values of the variables + +In short, the query result says that it is too soon to say much about +whether this trait is proven. During type-checking, this is not an +immediate error: instead, the type checker would hold on to this +requirement (`Vec: Borrow`) and wait. As we'll see in the next +example, it may happen that `?T` and `?U` wind up constrained from +other sources, in which case we can try the trait query again. + +**Example 2.** We can now extend our previous example a bit, +and assign a value to `u`: + +```rust +fn foo(a: A, vec_b: Option) where A: Borrow { } + +fn main() { + // What we saw before: + let mut t: Vec<_> = vec![]; // Type: Vec + let mut u: Option<_> = None; // Type: Option + foo(t, u); // `Vec: Borrow` => ambiguous + + // New stuff: + u = Some(vec![]); // ?U = Vec +} +``` + +As a result of this assignment, the type of `u` is forced to be +`Option>`, where `?V` represents the element type of the +vector. This in turn implies that `?U` is [unified] to `Vec`. + +[unified]: ./type-checking.html + +Let's suppose that the type checker decides to revisit the +"as-yet-unproven" trait obligation we saw before, `Vec: +Borrow`. `?U` is no longer an unbound inference variable; it now +has a value, &. So, if we "refresh" the query with that value, we get: + + Vec: Borrow> + +This time, there is only one impl that applies, the reflexive impl: + + impl Borrow for T where T: ?Sized + +Therefore, the trait checker will answer: + +- Certainty: `Proven` +- Var values: `[?T = ?T, ?V = ?T]` + +Here, it is saying that we have indeed proven that the obligation +holds, and we also know that `?T` and `?V` are the same type (but we +don't know what that type is yet!). + +(In fact, as the function ends here, the type checker would give an +error at this point, since the element types of `t` and `u` are still +not yet known, even though they are known to be the same.) + + diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index 9b71c8470..94b1d6b85 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -1,7 +1,10 @@ # Canonicalization Canonicalization is the process of **isolating** an inference value -from its context. It is really based on a very simple concept: every +from its context. It is a key part of implementing +[canonical queries][cq]. + +Canonicalization is really based on a very simple concept: every [inference variable](./type-inference.html#vars) is always in one of two states: either it is **unbound**, in which case we don't know yet what type it is, or it is **bound**, in which case we do. So to @@ -12,6 +15,8 @@ starting from zero and numbered in a fixed order (left to right, for the most part, but really it doesn't matter as long as it is consistent). +[cq]: ./traits-canonical-queries.html + So, for example, if we have the type `X = (?T, ?U)`, where `?T` and `?U` are distinct, unbound inference variables, then the canonical form of `X` would be `(?0, ?1)`, where `?0` and `?1` represent these diff --git a/src/traits-slg.md b/src/traits-slg.md new file mode 100644 index 000000000..cdd52ece9 --- /dev/null +++ b/src/traits-slg.md @@ -0,0 +1 @@ +# The SLG solver diff --git a/src/traits.md b/src/traits.md index 18cb0c649..6994f33d2 100644 --- a/src/traits.md +++ b/src/traits.md @@ -24,7 +24,7 @@ Trait solving is based around a few key ideas: - [Lazy normalization](./traits-associated-types.html), which is the technique we use to accommodate associated types when figuring out whether types are equal. -- [Region constraints](./traits-regions.md), which are accumulated +- [Region constraints](./traits-regions.html), which are accumulated during trait solving but mostly ignored. This means that trait solving effectively ignores the precise regions involved, always -- but we still remember the constraints on them so that those From 22b5ec479684ad8349b2173d784b9588f4512b84 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 05:45:36 -0500 Subject: [PATCH 0134/1812] update for notation --- src/traits-canonicalization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index 94b1d6b85..db2f939f6 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -60,7 +60,7 @@ result, we'll have an array of values for the canonical inputs. For example, the canonical result might be: ``` -for<2> { +for { values = [ Vec, '1, ?0 ] ^^ ^^ ^^ these are variables in the result! ... From 53115310f72cf5fdf46a607e79aa9819957fcf34 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 06:44:29 -0500 Subject: [PATCH 0135/1812] rework canon section substantially to spell out steps more clearly --- src/traits-canonical-queries.md | 2 + src/traits-canonicalization.md | 175 +++++++++++++++++++++++++++----- 2 files changed, 151 insertions(+), 26 deletions(-) diff --git a/src/traits-canonical-queries.md b/src/traits-canonical-queries.md index ec861eb47..ee66a73db 100644 --- a/src/traits-canonical-queries.md +++ b/src/traits-canonical-queries.md @@ -90,6 +90,8 @@ where-clauses, that would be provable. (Internally within the solver, though, they can potentially enumerate all possible answers. See [the description of the SLG solver](./traits-slg.html) for details.) + + The response to a trait query in rustc is typically a `Result, NoSolution>` (where the `T` will vary a bit depending on the query itself). The `Err(NoSolution)` case indicates diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index db2f939f6..fc55fac0d 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -2,7 +2,8 @@ Canonicalization is the process of **isolating** an inference value from its context. It is a key part of implementing -[canonical queries][cq]. +[canonical queries][cq], and you may wish to read the parent chapter +to get more context. Canonicalization is really based on a very simple concept: every [inference variable](./type-inference.html#vars) is always in one of @@ -33,6 +34,8 @@ the same answer. That answer will be expressed in terms of the canonical variables (`?0`, `?1`), which we can then map back to the original variables (`?T`, `?U`). +## Canonicalizing the query + To see how it works, imagine that we are asking to solve the following trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound. This query contains two unbound variables, but it also contains the @@ -48,54 +51,174 @@ Sometimes we write this differently, like so: for { ?0: Foo<'?1, ?2> } This `for<>` gives some information about each of the canonical -variables within. In this case, I am saying that `?0` is a type -(`T`), `?1` is a lifetime (`L`), and `?2` is also a type (`T`). The -`canonicalize` method *also* gives back a `CanonicalVarValues` array -with the "original values" for each canonicalized variable: +variables within. In this case, each `T` indicates a type variable, +so `?0` and `?2` are types; the `L` indicates a lifetime varibale, so +`?1` is a lifetime. The `canonicalize` method *also* gives back a +`CanonicalVarValues` array OV with the "original values" for each +canonicalized variable: [?A, 'static, ?B] + +We'll need this vector OV later, when we process the query response. + +## Executing the query + +Once we've constructed the canonical query, we can try to solve it. +To do so, we will wind up creating a fresh inference context and +**instantiating** the canonical query in that context. The idea is that +we create a substitution S from the canonical form containing a fresh +inference variable (of suitable kind) for each canonical variable. +So, for our example query: -Now we do the query and get back some result R. As part of that -result, we'll have an array of values for the canonical inputs. For -example, the canonical result might be: + for { ?0: Foo<'?1, ?2> } + +the substitution S might be: + + S = [?A, '?B, ?C] + +We can then replace the bound canonical variables (`?0`, etc) with +these inference variables, yielding the following fully instantiated +query: + + ?A: Foo<'?B, ?C> + +Remember that substitution S though! We're going to need it later. + +OK, now that we have a fresh inference context and an instantiated +query, we can go ahead and try to solve it. The trait solver itself is +explained in more detail in [another section](./traits-slg.html), but +suffice to say that it will compute a [certainty value][cqqr] (`Proven` or +`Ambiguous`) and have side-effects on the inference variables we've +created. For example, if there were only one impl of `Foo`, like so: + +[cqqr]: ./traits-canonical-queries.html#query-response ``` -for { - values = [ Vec, '1, ?0 ] - ^^ ^^ ^^ these are variables in the result! - ... -} +impl<'a, X> Foo<'a, X> for Vec +where X: 'a +{ ... } ``` -Note that this result is itself canonical and may include some -variables (in this case, `?0`). +then we might wind up with a certainty value of `Proven`, as well as +creating fresh inference variables `'?D` and `?E` (to represent the +parameters on the impl) and unifying as follows: + +- `'?B = '?D` +- `?A = Vec` +- `?C = ?E` + +We would also accumulate the region constraint `?E: '?D`, due to the +where clause. + +In order to create our final query result, we have to "lift" these +values out of the query's inference context and into something that +can be reapplied in our original inference context. We do that by +**re-applying canonicalization**, but to the **query result**. -What we want to do conceptually is to (a) instantiate each of the -canonical variables in the result with a fresh inference variable -and then (b) unify the values in the result with the original values. -Doing step (a) would yield a result of +## Canonicalizing the query result + +As discussed in [the parent section][cqqr], most trait queries wind up +with a result that brings together a "certainty value" `certainty`, a +result substitution `var_values`, and some region constraints. To +create this, we wind up re-using the substitution S that we created +when first instantiating our query. To refresh your memory, we had a query + + for { ?0: Foo<'?1, ?2> } + +for which we made a substutition S: + + S = [?A, '?B, ?C] + +We then did some work which unified some of those variables with other things. If we +"refresh" S with the latest results, we get: + + S = [Vec, '?D, ?E] + +These are precisely the new values for the three input variables from +our original query. Note though that they include some new variables +(like `?E`). We can make those go away by canonicalizing again! We don't +just canonicalize S, though, we canonicalize the whole query response QR: + + QR = { + certainty: Proven, // or whatever + var_values: [Vec, '?D, ?E] // this is S + region_constraints: [?E: '?D], // from the impl + value: (), // for our purposes, just (), but + // in some cases this might have + // a type or other info + } + +The result would be as follows: + + Canonical(QR) = for { + certainty: Proven, + var_values: [Vec, '?1, ?2] + region_constraints: [?2: '?1], + value: (), + } + +(One subtle point: when we canonicalize the query **result**, we do not +use any special treatment for free lifetimes. Note that both +references to `'?D`, for example, were converted into the same +canonical variable (`?1`). This is in contrast to the original query, +where we canonicalized every free lifetime into a fresh canonical +variable.) + +Now, this result must be reapplied in each context where needed. + +## Processing the canonicalized query result + +In the previous section we produced a canonical query result. We now have +to apply that result in our original context. If you recall, way back in the +beginning, we were trying to prove this query: + + ?A: Foo<'static, ?B> + +We canonicalized that into this: + + for { ?0: Foo<'?1, ?2> } + +and now we got back a canonical response: + + for { + certainty: Proven, + var_values: [Vec, '?1, ?2] + region_constraints: [?2: '?1], + value: (), + } + +We now want to apply that response to our context. Conceptually, how +we do that is to (a) instantiate each of the canonical variables in +the result with a fresh inference variable, (b) unify the values in +the result with the original values, and then (c) record the region +constraints for later. Doing step (a) would yield a result of ``` { - values = [ Vec, '?X, ?C ] - ^^ ^^^ fresh inference variables in `self` - .. -} + certainty: Proven, + var_values: [Vec, '?D, ?C] + ^^ ^^^ fresh inference variables + region_constraints: [?C: '?D], + value: (), +} ``` Step (b) would then unify: ``` ?A with Vec -'static with '?X +'static with '?D ?B with ?C ``` -(What we actually do is a mildly optimized variant of that: Rather +And finally the region constraint of `?C: 'static` would be recorded +for later verification. + +(What we *actually* do is a mildly optimized variant of that: Rather than eagerly instantiating all of the canonical values in the result with variables, we instead walk the vector of values, looking for cases where the value is just a canonical variable. In our example, `values[2]` is `?C`, so that we means we can deduce that `?C := ?B and -`'?X := 'static`. This gives us a partial set of values. Anything for +`'?D := 'static`. This gives us a partial set of values. Anything for which we do not find a value, we create an inference variable.) From 95f99572771272df3a196662211a8d95b6ca21ef Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:04:16 -0500 Subject: [PATCH 0136/1812] numerous edits --- src/SUMMARY.md | 6 +++--- src/glossary.md | 3 +++ src/traits-associated-types.md | 2 ++ src/traits-goals-and-clauses.md | 18 +++++++++++++---- src/traits-lowering-rules.md | 35 +++++++++++++++++---------------- src/traits-lowering-to-logic.md | 23 ++++++++++++---------- 6 files changed, 53 insertions(+), 34 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 95a5ee577..6612372be 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -24,11 +24,11 @@ - [Trait solving (new-style)](./traits.md) - [Lowering to logic](./traits-lowering-to-logic.md) - [Goals and clauses](./traits-goals-and-clauses.md) - - [Lowering rules](./traits-lowering-rules.md) + - [Equality and associated types](./traits-associated-types.md) + - [Region constraints](./traits-regions.md) - [Canonical queries](./traits-canonical-queries.md) - [Canonicalization](./traits-canonicalization.md) - - [Equality and associated types](./traits-associated-types.md) - - [Region constraints](./traits-regions.md) + - [Lowering rules](./traits-lowering-rules.md) - [Well-formedness checking](./traits-wf.md) - [The SLG solver](./traits-slg.md) - [Bibliography](./traits-bibliography.md) diff --git a/src/glossary.md b/src/glossary.md index 7152cba36..e542d4e35 100644 --- a/src/glossary.md +++ b/src/glossary.md @@ -31,10 +31,12 @@ LTO | Link-Time Optimizations. A set of optimizations offer [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) +normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](./traits-associated-types.html#normalize) newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. NLL | [non-lexical lifetimes](./mir-regionck.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) +projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](./traits-goals-and-clauses.html#trait-ref) promoted constants | constants extracted from a function and lifted to static scope; see [this section](./mir.html#promoted) for more details. provider | the function that executes a query ([see more](query.html)) quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified) @@ -49,6 +51,7 @@ span | a location in the user's source code, used for error substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) tcx | the "typing context", main data structure of the compiler ([see more](ty.html)) 'tcx | the lifetime of the currently active inference context ([see more](ty.html)) +trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](./traits-goals-and-clauses.html#trait-ref)) token | the smallest unit of parsing. Tokens are produced after lexing ([see more](the-parser.html)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. trans | the code to translate MIR into LLVM IR. diff --git a/src/traits-associated-types.md b/src/traits-associated-types.md index a640bf032..6ac3fc512 100644 --- a/src/traits-associated-types.md +++ b/src/traits-associated-types.md @@ -20,6 +20,8 @@ that syntax is expanded during ["type collection"](./type-checking.html) into the explicit form, though that is something we may want to change in the future.) + + In some cases, associated type projections can be **normalized** -- that is, simplified -- based on the types given in an impl. So, to continue with our example, the impl of `IntoIterator` for `Option` diff --git a/src/traits-goals-and-clauses.md b/src/traits-goals-and-clauses.md index ad1655726..92e1b67d9 100644 --- a/src/traits-goals-and-clauses.md +++ b/src/traits-goals-and-clauses.md @@ -12,12 +12,14 @@ a few new superpowers. In Rust's solver, **goals** and **clauses** have the following forms (note that the two definitions reference one another): - Goal = DomainGoal + Goal = DomainGoal // defined in the section below | Goal && Goal | Goal || Goal | exists { Goal } // existential quantification | forall { Goal } // universal quantification | if (Clause) { Goal } // implication + | true // something that's trivially true + | ambiguous // something that's never provable Clause = DomainGoal | Clause :- Goal // if can prove Goal, then Clause is true @@ -39,9 +41,11 @@ gives the details. ## Domain goals + + To define the set of *domain goals* in our system, we need to first introduce a few simple formulations. A **trait reference** consists of -the name of a trait allow with a suitable set of inputs P0..Pn: +the name of a trait along with a suitable set of inputs P0..Pn: TraitRef = P0: TraitName @@ -50,7 +54,9 @@ IntoIterator`. Note that Rust surface syntax also permits some extra things, like associated type bindings (`Vec: IntoIterator`), that are not part of a trait reference. -A **projection** consists of a an associated item reference along with + + +A **projection** consists of an associated item reference along with its inputs P0..Pm: Projection = >::AssocItem @@ -77,7 +83,9 @@ Given that, we can define a `DomainGoal` as follows: to [implied bounds]. - `ProjectionEq(Projection = Type)` -- the given associated type `Projection` is equal to `Type`; see [the section on associated types](./traits-associated-types.html) -- `Normalize(Projection -> Type)` -- the given associated type `Projection` can be normalized + - in general, proving `ProjectionEq(TraitRef::Item = Type)` also + requires proving `Implemented(TraitRef)` +- `Normalize(Projection -> Type)` -- the given associated type `Projection` can be [normalized][n] to `Type` - as discussed in [the section on associated types](./traits-associated-types.html), `Normalize` implies `ProjectionEq` but not vice versa @@ -85,6 +93,8 @@ Given that, we can define a `DomainGoal` as follows: *well-formed* - well-formedness is important to [implied bounds]. +[n]: ./traits-associated-types.html#normalize + ## Coinductive goals diff --git a/src/traits-lowering-rules.md b/src/traits-lowering-rules.md index d096b4364..46827dce5 100644 --- a/src/traits-lowering-rules.md +++ b/src/traits-lowering-rules.md @@ -1,8 +1,8 @@ # Lowering rules This section gives the complete lowering rules for Rust traits into -[program clauses][pc]. These rules reference the [domain goals][dg] defined in -an earlier section. +[program clauses][pc]. It is a kind of reference. These rules +reference the [domain goals][dg] defined in an earlier section. [pc]: ./traits-goals-and-clauses.html [dg]: ./traits-goals-and-clauses.html#domain-goals @@ -22,7 +22,7 @@ definitions; these macros reference other sections within this chapter. ## Lowering where clauses -When used in a goal position, where clauses can be mapped directly +When used in a goal position, where clauses can be mapped directly to [domain goals][dg], as follows: - `A0: Foo` maps to `Implemented(A0: Foo)`. @@ -72,12 +72,12 @@ inside the `{}`. ### Trait header From the trait itself we mostly make "meta" rules that setup the -relationships between different kinds of domain goals. The first dush +relationships between different kinds of domain goals. The first such rule from the trait header creates the mapping between the `FromEnv` and `Implemented` predicates: forall { - Implemented(Self: Trait) :- FromEnv(Self: Trait) :- FromEnv(Self: Trait) } @@ -114,7 +114,7 @@ to be **well-formed**: // For each where clause WC: forall { - WellFormed(Self: Trait) :- Implemented(Self: Trait), WellFormed(WC) + WellFormed(Self: Trait) :- Implemented(Self: Trait) && WellFormed(WC) } This `WellFormed` rule states that `T: Trait` is well-formed if (a) @@ -150,7 +150,7 @@ one of those: This `WellFormed` predicate is only used when proving that impls are well-formed -- basically, for each impl of some trait ref `TraitRef`, -we must that `WellFormed(TraitRef)`. This in turn justifies the +we must show that `WellFormed(TraitRef)`. This in turn justifies the implied bounds rules that allow us to extend the set of `FromEnv` items. @@ -170,9 +170,10 @@ where WC } ``` -We will produce a number of program clases. The first two define +We will produce a number of program clauses. The first two define the rules by which `ProjectionEq` can succeed; these two clauses are discussed -in detail in the [section on associated types](./traits-associated-types.html). +in detail in the [section on associated types](./traits-associated-types.html),, +but reproduced here for reference: // ProjectionEq can succeed by normalizing: forall { @@ -180,7 +181,8 @@ in detail in the [section on associated types](./traits-associated-types.html). Normalize(>::AssocType -> U) } - // ProjectionEq can succeed by skolemizing: + // ProjectionEq can succeed by skolemizing, see "associated type" + // chapter for more: forall { ProjectionEq( >::AssocType = @@ -188,13 +190,13 @@ in detail in the [section on associated types](./traits-associated-types.html). ) :- // But only if the trait is implemented, and the conditions from // the associated type are met as well: - Implemented(Self: Trait), - WC1 + Implemented(Self: Trait) + && WC1 } The next rule covers implied bounds for the projection. In particular, the `Bounds` declared on the associated type must be proven to hold to -show that the impl is well-formed, and hence we can rely on them from +show that the impl is well-formed, and hence we can rely on them elsewhere. // XXX how exactly should we set this up? Have to be careful; @@ -237,7 +239,7 @@ Given an impl that contains: impl Trait for A0 where WC { - type AssocType: Bounds where WC1 = T; + type AssocType where WC1 = T; } ``` @@ -246,13 +248,12 @@ We produce the following rule: forall { forall { Normalize(>::AssocType -> T) :- - WC, WC1 + WC && WC1 } } Note that `WC` and `WC1` both encode where-clauses that the impl can -rely on, whereas the bounds `Bounds` on the associated type are things -that the impl must prove (see the well-formedness checking). +rely on. diff --git a/src/traits-lowering-to-logic.md b/src/traits-lowering-to-logic.md index 7b1c2ed6b..4e4e7cae9 100644 --- a/src/traits-lowering-to-logic.md +++ b/src/traits-lowering-to-logic.md @@ -33,6 +33,9 @@ Prolog-like notation, as follows: ``` Clone(usize). Clone(Vec) :- Clone(?T). + +// The notation `A :- B` means "A is true if B is true". +// Or, put another way, B implies A. ``` In Prolog terms, we might say that `Clone(Foo)` -- where `Foo` is some @@ -82,20 +85,20 @@ let's turn our focus a bit towards **type-checking**. Type-checking is interesting because it is what gives us the goals that we need to prove. That is, everything we've seen so far has been about how we derive the rules by which we can prove goals from the traits and impls -in the program; but we are also interesting in how derive the goals +in the program; but we are also interested in how to derive the goals that we need to prove, and those come from type-checking. Consider type-checking the function `foo()` here: ```rust fn foo() { bar::() } -fn bar() { } +fn bar>() { } ``` This function is very simple, of course: all it does is to call `bar::()`. Now, looking at the definition of `bar()`, we can see -that it has one where-clause `U: Eq`. So, that means that `foo()` will -have to prove that `usize: Eq` in order to show that it can call `bar()` +that it has one where-clause `U: Eq`. So, that means that `foo()` will +have to prove that `usize: Eq` in order to show that it can call `bar()` with `usize` as the type argument. If we wanted, we could write a Prolog predicate that defines the @@ -103,7 +106,7 @@ conditions under which `bar()` can be called. We'll say that those conditions are called being "well-formed": ``` -barWellFormed(?U) :- Eq(?U). +barWellFormed(?U) :- Eq(?U, ?U). ``` Then we can say that `foo()` type-checks if the reference to @@ -118,7 +121,7 @@ If we try to prove the goal `fooTypeChecks`, it will succeed: - `fooTypeChecks` is provable if: - `barWellFormed(usize)`, which is provable if: - - `Eq(usize)`, which is provable because of an impl. + - `Eq(usize, usize)`, which is provable because of an impl. Ok, so far so good. Let's move on to type-checking a more complex function. @@ -132,8 +135,8 @@ can be provide. To see what I'm talking about, let's revamp our previous example to make `foo` generic: ```rust -fn foo() { bar::() } -fn bar() { } +fn foo>() { bar::() } +fn bar>() { } ``` To type-check the body of `foo`, we need to be able to hold the type @@ -145,8 +148,8 @@ this like so: fooTypeChecks :- // for all types T... forall { - // ...if we assume that Eq(T) is provable... - if (Eq(T)) { + // ...if we assume that Eq(T, T) is provable... + if (Eq(T, T)) { // ...then we can prove that `barWellFormed(T)` holds. barWellFormed(T) } From 7a78a998cea262950d04f291618ba7ea7540d517 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:06:36 -0500 Subject: [PATCH 0137/1812] add implied bounds placeholder --- src/SUMMARY.md | 1 + src/traits-implied-bounds.md | 9 +++++++++ 2 files changed, 10 insertions(+) create mode 100644 src/traits-implied-bounds.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 6612372be..8aa450b7b 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -25,6 +25,7 @@ - [Lowering to logic](./traits-lowering-to-logic.md) - [Goals and clauses](./traits-goals-and-clauses.md) - [Equality and associated types](./traits-associated-types.md) + - [Implied bounds](./traits-implied-bounds.md) - [Region constraints](./traits-regions.md) - [Canonical queries](./traits-canonical-queries.md) - [Canonicalization](./traits-canonicalization.md) diff --git a/src/traits-implied-bounds.md b/src/traits-implied-bounds.md new file mode 100644 index 000000000..26a63bf32 --- /dev/null +++ b/src/traits-implied-bounds.md @@ -0,0 +1,9 @@ +# Implied Bounds + +*to be written* + +Cover: + +- Why the `FromEnv` setup etc is the way it is +- Perhaps move some of the material from 'lowering rules' in to here +- Show various examples where you could go wrong From 994a38b19802a8982f413ba6c769c4ccecb80888 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:09:25 -0500 Subject: [PATCH 0138/1812] update the summary landing page --- src/traits.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/traits.md b/src/traits.md index 6994f33d2..b75e7fec6 100644 --- a/src/traits.md +++ b/src/traits.md @@ -16,8 +16,10 @@ Trait solving is based around a few key ideas: - [Lowering to logic](./traits-lowering-to-logic.html), which expresses Rust traits in terms of standard logical terms. - The [goals and clauses](./traits-goals-and-clauses.html) chapter - describes the precise lowering rules we use. -- [Canonical queries](./traits-canonicalization.html), which allow us + describes the precise form of rules we use, and + [lowering rules](./lowering-rules.html) gives the complete set of + lowering rules in a more reference-like form. +- [Canonical queries](./traits-canonical-queries.html), which allow us to solve trait problems (like "is `Foo` implemented for the type `Bar`?") once, and then apply that same result independently in many different inference contexts. From d9f0a45a045c7901cf2c36b4134f5f96db5e959c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:10:44 -0500 Subject: [PATCH 0139/1812] fix link --- src/traits.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits.md b/src/traits.md index b75e7fec6..175e6418b 100644 --- a/src/traits.md +++ b/src/traits.md @@ -17,7 +17,7 @@ Trait solving is based around a few key ideas: Rust traits in terms of standard logical terms. - The [goals and clauses](./traits-goals-and-clauses.html) chapter describes the precise form of rules we use, and - [lowering rules](./lowering-rules.html) gives the complete set of + [lowering rules](./traits-lowering-rules.html) gives the complete set of lowering rules in a more reference-like form. - [Canonical queries](./traits-canonical-queries.html), which allow us to solve trait problems (like "is `Foo` implemented for the type From 49e8e092c12a6bf97ec240eb65f8d6713e4088a4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Sat, 10 Mar 2018 07:11:11 -0500 Subject: [PATCH 0140/1812] trailing whitespace --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 8aa450b7b..d4ee59abf 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -21,7 +21,7 @@ - [Higher-ranked trait bounds](./trait-hrtb.md) - [Caching subtleties](./trait-caching.md) - [Specialization](./trait-specialization.md) -- [Trait solving (new-style)](./traits.md) +- [Trait solving (new-style)](./traits.md) - [Lowering to logic](./traits-lowering-to-logic.md) - [Goals and clauses](./traits-goals-and-clauses.md) - [Equality and associated types](./traits-associated-types.md) From 5dfe4f26c5a4e2ad56ff4c52a9d3dadeef8a9430 Mon Sep 17 00:00:00 2001 From: Shanavas M Date: Sat, 10 Mar 2018 18:41:11 +0300 Subject: [PATCH 0141/1812] fix typo --- src/tests/intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index 8ad2492b7..eb7294c83 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -27,7 +27,7 @@ that give more details. - [`ui`](./tests/adding.html#ui) -- tests that check the exact stdout/stderr from compilation and/or running the test - `run-pass` -- tests that are expected to compile and execute successfully (no panics) - - `run-pass-valgrind` -- tests that ought to run with valrind + - `run-pass-valgrind` -- tests that ought to run with valgrind - `run-fail` -- tests that are expected to compile but then panic during execution - `compile-fail` -- tests that are expected to fail compilation. - `parse-fail` -- tests that are expected to fail to parse From ce45556483b70edf882417060f079f79e02309f9 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 11 Mar 2018 21:05:29 -0500 Subject: [PATCH 0142/1812] Fix a few typos --- src/traits-canonical-queries.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/traits-canonical-queries.md b/src/traits-canonical-queries.md index ee66a73db..3fea5fbd9 100644 --- a/src/traits-canonical-queries.md +++ b/src/traits-canonical-queries.md @@ -20,7 +20,7 @@ will run off and start supplying you with every possible answer it can find. So given something like this: ?- Vec: AsRef - + The solver might answer: Vec: AsRef<[i32]> @@ -71,27 +71,27 @@ Another interesting thing is that queries might still have variables in them. For example: ?- Rc: Clone - + might produce the answer: Rc: Clone continue? (y/n) - -After all, `Rc` is true **no matter what type `?T` is**. + +After all, `Rc` is true **no matter what type `?T` is**. + + ## A trait query in rustc The trait queries in rustc work somewhat differently. Instead of trying to enumerate **all possible** answers for you, they are looking -for an **unambiguous** answer. In particular, when they tells you the +for an **unambiguous** answer. In particular, when they tell you the value for a type variable, that means that this is the **only possible instantiation** that you could use, given the current set of impls and where-clauses, that would be provable. (Internally within the solver, though, they can potentially enumerate all possible answers. See [the description of the SLG solver](./traits-slg.html) for details.) - - The response to a trait query in rustc is typically a `Result, NoSolution>` (where the `T` will vary a bit depending on the query itself). The `Err(NoSolution)` case indicates @@ -191,7 +191,7 @@ fn main() { let mut t: Vec<_> = vec![]; // Type: Vec let mut u: Option<_> = None; // Type: Option foo(t, u); // `Vec: Borrow` => ambiguous - + // New stuff: u = Some(vec![]); // ?U = Vec } @@ -206,10 +206,10 @@ vector. This in turn implies that `?U` is [unified] to `Vec`. Let's suppose that the type checker decides to revisit the "as-yet-unproven" trait obligation we saw before, `Vec: Borrow`. `?U` is no longer an unbound inference variable; it now -has a value, &. So, if we "refresh" the query with that value, we get: +has a value, `Vec`. So, if we "refresh" the query with that value, we get: Vec: Borrow> - + This time, there is only one impl that applies, the reflexive impl: impl Borrow for T where T: ?Sized From 0da5774acb75498d34b0f7df0e489bd99f2e1ea7 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 7 Mar 2018 22:18:05 +0800 Subject: [PATCH 0143/1812] Added a very rough rustc-driver chapter --- src/SUMMARY.md | 1 + src/rustc-driver.md | 66 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+) create mode 100644 src/rustc-driver.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index d4ee59abf..841a9b491 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -9,6 +9,7 @@ - [Using `compiletest` + commands to control test execution](./compiletest.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [High-level overview of the compiler source](./high-level-overview.md) +- [The Rustc Driver](./rustc-driver.md) - [Queries: demand-driven compilation](./query.md) - [Incremental compilation](./incremental-compilation.md) - [The parser](./the-parser.md) diff --git a/src/rustc-driver.md b/src/rustc-driver.md new file mode 100644 index 000000000..b21cc3662 --- /dev/null +++ b/src/rustc-driver.md @@ -0,0 +1,66 @@ +# The Rustc Driver + +The [`rustc_driver`] is essentially `rustc`'s `main()` function. It acts as +the glue for running the various phases of the compiler in the correct order, +managing state such as the [`CodeMap`] \(maps AST nodes to source code), +[`Session`] \(general build context and error messaging) and the [`TyCtxt`] +\(the "typing context", allowing you to query the type system and other cool +stuff). The `rustc_driver` crate also provides external users with a method +for running code at particular times during the compilation process, allowing +third parties to effectively use `rustc`'s internals as a library for +analysing a crate. + +For those using `rustc` as a library, the `run_compiler()` function is the main +entrypoint to the compiler. Its main parameters are a list of command-line +arguments and a reference to something which implements the `CompilerCalls` +trait. A `CompilerCalls` creates the overall `CompileController`, letting it +govern which compiler passes are run and attach callbacks to be fired at the end +of each phase. + +From `rustc_driver`'s perspective, the main phases of the compiler are: + +1. *Parse Input:* Initial crate parsing +2. *Configure and Expand:* Resolve `#[cfg]` attributes and expand macros +3. *Run Analysis Passes:* Run the resolution, typechecking, region checking + and other miscellaneous analysis passes on the crate +4. *Translate to LLVM:* Turn the analysed program into executable code + +The `CompileController` then gives users the ability to inspect the ongoing +compilation process + +- after parsing +- after AST expansion +- after HIR lowering +- after analysis, and +- when compilation is done + +The `CompileState`'s various `state_after_*()` constructors can be inspected to +determine what bits of information are available to which callback. + +## A Note On Lifetimes + +The Rust compiler is a fairly large program containing lots of big data +structures (e.g. the AST, HIR, and the type system) and as such, arenas and +references are heavily relied upon to minimize unnecessary memory use. This +manifests itself in the way people can plug into the compiler, preferring a +"push"-style API (callbacks) instead of the more Rust-ic "pull" style (think +the `Iterator` trait). + +For example the [`CompileState`], the state passed to callbacks after each +phase, is essentially just a box of optional references to pieces inside the +compiler. The lifetime bound on the `CompilerCalls` trait then helps to ensure +compiler internals don't "escape" the compiler (e.g. if you tried to keep a +reference to the AST after the compiler is finished), while still letting users +record *some* state for use after the `run_compiler()` function finishes. + +Thread-local storage and interning are used a lot through the compiler to reduce +duplication while also preventing a lot of the ergonomic issues due to many +pervasive lifetimes. The `rustc::ty::tls` module is used to access these +thread-locals, although you should rarely need to touch it. + + +[`rustc_driver`]: https://github.com/rust-lang/rust/tree/master/src/librustc_driver +[`CompileState`]: https://github.com/rust-lang/rust/blob/master/src/librustc_driver/driver.rs +[`Session`]: https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs +[`TyCtxt`]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs +[`CodeMap`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs \ No newline at end of file From 121d05098c7f4f4fe0813b4f783747e4008c092a Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 7 Mar 2018 22:31:22 +0800 Subject: [PATCH 0144/1812] Renamed appendices and added @nrc's guide --- src/SUMMARY.md | 10 +- src/{background.md => appendix-background.md} | 2 +- src/{code-index.md => appendix-code-index.md} | 2 +- src/{glossary.md => appendix-glossary.md} | 17 +- src/appendix-stupid-stats.md | 396 ++++++++++++++++++ src/mir-borrowck.md | 2 +- src/mir-regionck.md | 8 +- src/mir.md | 2 +- 8 files changed, 419 insertions(+), 20 deletions(-) rename src/{background.md => appendix-background.md} (99%) rename src/{code-index.md => appendix-code-index.md} (98%) rename src/{glossary.md => appendix-glossary.md} (94%) create mode 100644 src/appendix-stupid-stats.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 841a9b491..eb889d36b 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -46,6 +46,10 @@ - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) - [Generating LLVM IR](./trans.md) -- [Background material](./background.md) -- [Glossary](./glossary.md) -- [Code Index](./code-index.md) + +--- + +- [Appendix A: Stupid Stats](./appendix-stupid-stats.md) +- [Appendix B: Background material](./appendix-background.md) +- [Appendix C: Glossary](./appendix-glossary.md) +- [Appendix D: Code Index](./appendix-code-index.md) diff --git a/src/background.md b/src/appendix-background.md similarity index 99% rename from src/background.md rename to src/appendix-background.md index 50c247774..c69e7d93d 100644 --- a/src/background.md +++ b/src/appendix-background.md @@ -1,4 +1,4 @@ -# Background topics +# Appendix B: Background topics This section covers a numbers of common compiler terms that arise in this guide. We try to give the general definition while providing some diff --git a/src/code-index.md b/src/appendix-code-index.md similarity index 98% rename from src/code-index.md rename to src/appendix-code-index.md index 6a500abba..64a40f74d 100644 --- a/src/code-index.md +++ b/src/appendix-code-index.md @@ -1,4 +1,4 @@ -# Code Index +# Appendix D: Code Index rustc has a lot of important data structures. This is an attempt to give some guidance on where to learn more about some of the key data structures of the diff --git a/src/glossary.md b/src/appendix-glossary.md similarity index 94% rename from src/glossary.md rename to src/appendix-glossary.md index e542d4e35..1914adec6 100644 --- a/src/glossary.md +++ b/src/appendix-glossary.md @@ -1,21 +1,20 @@ -Glossary --------- +# Appendix C: Glossary The compiler uses a number of...idiosyncratic abbreviations and things. This glossary attempts to list them and give you a few pointers for understanding them better. Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. -binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) -bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) +binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./appendix-background.html#free-vs-bound) +bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./appendix-background.html#free-vs-bound) codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). -control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) +control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./appendix-background.html#cfg) cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) -data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow) +data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./appendix-background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. -free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) +free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix-background.html#free-vs-bound) 'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item HIR | the High-level IR, created by lowering and desugaring the AST ([see more](hir.html)) @@ -39,7 +38,7 @@ obligation | something that must be proven by the trait system ([s projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](./traits-goals-and-clauses.html#trait-ref) promoted constants | constants extracted from a function and lifted to static scope; see [this section](./mir.html#promoted) for more details. provider | the function that executes a query ([see more](query.html)) -quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified) +quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./appendix-background.html#quantified) query | perhaps some sub-computation during compilation ([see more](query.html)) region | another term for "lifetime" often used in the literature and in the borrow checker. sess | the compiler session, which stores global data used throughout compilation @@ -57,7 +56,7 @@ token | the smallest unit of parsing. Tokens are produced aft trans | the code to translate MIR into LLVM IR. trait reference | a trait and values for its type parameters ([see more](ty.html)). ty | the internal representation of a type ([see more](ty.html)). -variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter for more](./background.html#variance). +variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter for more](./appendix-background.html#variance). [LLVM]: https://llvm.org/ [lto]: https://llvm.org/docs/LinkTimeOptimization.html diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md new file mode 100644 index 000000000..405577e3c --- /dev/null +++ b/src/appendix-stupid-stats.md @@ -0,0 +1,396 @@ +# Appendix A: A tutorial on creating a drop-in replacement for rustc + +Many tools benefit from being a drop-in replacement for a compiler. By this, I +mean that any user of the tool can use `mytool` in all the ways they would +normally use `rustc` - whether manually compiling a single file or as part of a +complex make project or Cargo build, etc. That could be a lot of work; +rustc, like most compilers, takes a large number of command line arguments which +can affect compilation in complex and interacting ways. Emulating all of this +behaviour in your tool is annoying at best, especically if you are making many +of the same calls into librustc that the compiler is. + +The kind of things I have in mind are tools like rustdoc or a future rustfmt. +These want to operate as closely as possible to real compilation, but have +totally different outputs (documentation and formatted source code, +respectively). Another use case is a customised compiler. Say you want to add a +custom code generation phase after macro expansion, then creating a new tool +should be easier than forking the compiler (and keeping it up to date as the +compiler evolves). + +I have gradually been trying to improve the API of librustc to make creating a +drop-in tool easier to produce (many others have also helped improve these +interfaces over the same time frame). It is now pretty simple to make a tool +which is as close to rustc as you want it to be. In this tutorial I'll show +how. + +Note/warning, everything I talk about in this tutorial is internal API for +rustc. It is all extremely unstable and likely to change often and in +unpredictable ways. Maintaining a tool which uses these APIs will be non- +trivial, although hopefully easier than maintaining one that does similar things +without using them. + +This tutorial starts with a very high level view of the rustc compilation +process and of some of the code that drives compilation. Then I'll describe how +that process can be customised. In the final section of the tutorial, I'll go +through an example - stupid-stats - which shows how to build a drop-in tool. + + +## Overview of the compilation process + +Compilation using rustc happens in several phases. We start with parsing, this +includes lexing. The output of this phase is an AST (abstract syntax tree). +There is a single AST for each crate (indeed, the entire compilation process +operates over a single crate). Parsing abstracts away details about individual +files which will all have been read in to the AST in this phase. At this stage +the AST includes all macro uses, attributes will still be present, and nothing +will have been eliminated due to `cfg`s. + +The next phase is configuration and macro expansion. This can be thought of as a +function over the AST. The unexpanded AST goes in and an expanded AST comes out. +Macros and syntax extensions are expanded, and `cfg` attributes will cause some +code to disappear. The resulting AST won't have any macros or macro uses left +in. + +The code for these first two phases is in [libsyntax](https://github.com/rust-lang/rust/tree/master/src/libsyntax). + +After this phase, the compiler allocates ids to each node in the AST +(technically not every node, but most of them). If we are writing out +dependencies, that happens now. + +The next big phase is analysis. This is the most complex phase and +uses the bulk of the code in rustc. This includes name resolution, type +checking, borrow checking, type and lifetime inference, trait selection, method +selection, linting, and so forth. Most error detection is done in this phase +(although parse errors are found during parsing). The 'output' of this phase is +a bunch of side tables containing semantic information about the source program. +The analysis code is in [librustc](https://github.com/rust-lang/rust/tree/master/src/librustc) +and a bunch of other crates with the 'librustc_' prefix. + +Next is translation, this translates the AST (and all those side tables) into +LLVM IR (intermediate representation). We do this by calling into the LLVM +libraries, rather than actually writing IR directly to a file. The code for this is in +[librustc_trans](https://github.com/rust-lang/rust/tree/master/src/librustc_trans). + +The next phase is running the LLVM backend. This runs LLVM's optimisation passes +on the generated IR and then generates machine code. The result is object files. +This phase is all done by LLVM, it is not really part of the rust compiler. The +interface between LLVM and rustc is in [librustc_llvm](https://github.com/rust-lang/rust/tree/master/src/librustc_llvm). + +Finally, we link the object files into an executable. Again we outsource this to +other programs and it's not really part of the rust compiler. The interface is +in [librustc_back](https://github.com/rust-lang/rust/tree/master/src/librustc_back) +(which also contains some things used primarily during translation). + +All these phases are coordinated by the driver. To see the exact sequence, look +at the `compile_input` function in [librustc_driver/driver.rs](https://github.com/rust-lang/rust/tree/master/src/librustc_driver/driver.rs). +The driver (which is found in [librust_driver](https://github.com/rust-lang/rust/tree/master/src/librustc_driver)) +handles all the highest level coordination of compilation - handling command +line arguments, maintaining compilation state (primarily in the `Session`), and +calling the appropriate code to run each phase of compilation. It also handles +high level coordination of pretty printing and testing. To create a drop-in +compiler replacement or a compiler replacement, we leave most of compilation +alone and customise the driver using its APIs. + + +## The driver customisation APIs + +There are two primary ways to customise compilation - high level control of the +driver using `CompilerCalls` and controlling each phase of compilation using a +`CompileController`. The former lets you customise handling of command line +arguments etc., the latter lets you stop compilation early or execute code +between phases. + + +### `CompilerCalls` + +`CompilerCalls` is a trait that you implement in your tool. It contains a fairly +ad-hoc set of methods to hook in to the process of processing command line +arguments and driving the compiler. For details, see the comments in +[librustc_driver/lib.rs](https://github.com/rust-lang/rust/tree/master/src/librustc_driver/lib.rs). +I'll summarise the methods here. + +`early_callback` and `late_callback` let you call arbitrary code at different +points - early is after command line arguments have been parsed, but before +anything is done with them; late is pretty much the last thing before +compilation starts, i.e., after all processing of command line arguments, etc. is +done. Currently, you get to choose whether compilation stops or continues at +each point, but you don't get to change anything the driver has done. You can +record some info for later, or perform other actions of your own. + +`some_input` and `no_input` give you an opportunity to modify the primary input +to the compiler (usually the input is a file containing the top module for a +crate, but it could also be a string). You could record the input or perform +other actions of your own. + +Ignore `parse_pretty`, it is unfortunate and hopefully will get improved. There +is a default implementation, so you can pretend it doesn't exist. + +`build_controller` returns a `CompileController` object for more fine-grained +control of compilation, it is described next. + +We might add more options in the future. + + +### `CompilerController` + +`CompilerController` is a struct consisting of `PhaseController`s and flags. +Currently, there is only flag, `make_glob_map` which signals whether to produce +a map of glob imports (used by save-analysis and potentially other tools). There +are probably flags in the session that should be moved here. + +There is a `PhaseController` for each of the phases described in the above +summary of compilation (and we could add more in the future for finer-grained +control). They are all `after_` a phase because they are checked at the end of a +phase (again, that might change), e.g., `CompilerController::after_parse` +controls what happens immediately after parsing (and before macro expansion). + +Each `PhaseController` contains a flag called `stop` which indicates whether +compilation should stop or continue, and a callback to be executed at the point +indicated by the phase. The callback is called whether or not compilation +continues. + +Information about the state of compilation is passed to these callbacks in a +`CompileState` object. This contains all the information the compiler has. Note +that this state information is immutable - your callback can only execute code +using the compiler state, it can't modify the state. (If there is demand, we +could change that). The state available to a callback depends on where during +compilation the callback is called. For example, after parsing there is an AST +but no semantic analysis (because the AST has not been analysed yet). After +translation, there is translation info, but no AST or analysis info (since these +have been consumed/forgotten). + + +## An example - stupid-stats + +Our example tool is very simple, it simply collects some simple and not very +useful statistics about a program; it is called stupid-stats. You can find +the (more heavily commented) complete source for the example on [Github](https://github.com/nick29581/stupid-stats/blob/master/src). +To build, just do `cargo build`. To run on a file `foo.rs`, do `cargo run +foo.rs` (assuming you have a Rust program called `foo.rs`. You can also pass any +command line arguments that you would normally pass to rustc). When you run it +you'll see output similar to + +``` +In crate: foo, + +Found 12 uses of `println!`; +The most common number of arguments is 1 (67% of all functions); +25% of functions have four or more arguments. +``` + +To make things easier, when we talk about functions, we're excluding methods and +closures. + +You can also use the executable as a drop-in replacement for rustc, because +after all, that is the whole point of this exercise. So, however you use rustc +in your makefile setup, you can use `target/stupid` (or whatever executable you +end up with) instead. That might mean setting an environment variable or it +might mean renaming your executable to `rustc` and setting your PATH. Similarly, +if you're using Cargo, you'll need to rename the executable to rustc and set the +PATH. Alternatively, you should be able to use +[multirust](https://github.com/brson/multirust) to get around all the PATH stuff +(although I haven't actually tried that). + +(Note that this example prints to stdout. I'm not entirely sure what Cargo does +with stdout from rustc under different circumstances. If you don't see any +output, try inserting a `panic!` after the `println!`s to error out, then Cargo +should dump stupid-stats' stdout to Cargo's stdout). + +Let's start with the `main` function for our tool, it is pretty simple: + +``` +fn main() { + let args: Vec<_> = std::env::args().collect(); + rustc_driver::run_compiler(&args, &mut StupidCalls::new()); + std::env::set_exit_status(0); +} +``` + +The first line grabs any command line arguments. The second line calls the +compiler driver with those arguments. The final line sets the exit code for the +program. + +The only interesting thing is the `StupidCalls` object we pass to the driver. +This is our implementation of the `CompilerCalls` trait and is what will make +this tool different from rustc. + +`StupidCalls` is a mostly empty struct: + +``` +struct StupidCalls { + default_calls: RustcDefaultCalls, +} +``` + +This tool is so simple that it doesn't need to store any data here, but usually +you would. We embed a `RustcDefaultCalls` object to delegate to in our impl when +we want exactly the same behaviour as the Rust compiler. Mostly you don't want +to do that (or at least don't need to) in a tool. However, Cargo calls rustc +with the `--print file-names`, so we delegate in `late_callback` and `no_input` +to keep Cargo happy. + +Most of the rest of the impl of `CompilerCalls` is trivial: + +``` +impl<'a> CompilerCalls<'a> for StupidCalls { + fn early_callback(&mut self, + _: &getopts::Matches, + _: &config::Options, + _: &diagnostics::registry::Registry, + _: ErrorOutputType) + -> Compilation { + Compilation::Continue + } + + fn late_callback(&mut self, + m: &getopts::Matches, + s: &Session, + i: &Input, + odir: &Option, + ofile: &Option) + -> Compilation { + self.default_calls.late_callback(m, s, i, odir, ofile); + Compilation::Continue + } + + fn some_input(&mut self, + input: Input, + input_path: Option) + -> (Input, Option) { + (input, input_path) + } + + fn no_input(&mut self, + m: &getopts::Matches, + o: &config::Options, + odir: &Option, + ofile: &Option, + r: &diagnostics::registry::Registry) + -> Option<(Input, Option)> { + self.default_calls.no_input(m, o, odir, ofile, r); + + // This is not optimal error handling. + panic!("No input supplied to stupid-stats"); + } + + fn build_controller(&mut self, _: &Session) -> driver::CompileController<'a> { + ... + } +} +``` + +We don't do anything for either of the callbacks, nor do we change the input if +the user supplies it. If they don't, we just `panic!`, this is the simplest way +to handle the error, but not very user-friendly, a real tool would give a +constructive message or perform a default action. + +In `build_controller` we construct our `CompileController`. We only want to +parse, and we want to inspect macros before expansion, so we make compilation +stop after the first phase (parsing). The callback after that phase is where the +tool does it's actual work by walking the AST. We do that by creating an AST +visitor and making it walk the AST from the top (the crate root). Once we've +walked the crate, we print the stats we've collected: + +``` +fn build_controller(&mut self, _: &Session) -> driver::CompileController<'a> { + // We mostly want to do what rustc does, which is what basic() will return. + let mut control = driver::CompileController::basic(); + // But we only need the AST, so we can stop compilation after parsing. + control.after_parse.stop = Compilation::Stop; + + // And when we stop after parsing we'll call this closure. + // Note that this will give us an AST before macro expansions, which is + // not usually what you want. + control.after_parse.callback = box |state| { + // Which extracts information about the compiled crate... + let krate = state.krate.unwrap(); + + // ...and walks the AST, collecting stats. + let mut visitor = StupidVisitor::new(); + visit::walk_crate(&mut visitor, krate); + + // And finally prints out the stupid stats that we collected. + let cratename = match attr::find_crate_name(&krate.attrs[]) { + Some(name) => name.to_string(), + None => String::from_str("unknown_crate"), + }; + println!("In crate: {},\n", cratename); + println!("Found {} uses of `println!`;", visitor.println_count); + + let (common, common_percent, four_percent) = visitor.compute_arg_stats(); + println!("The most common number of arguments is {} ({:.0}% of all functions);", + common, common_percent); + println!("{:.0}% of functions have four or more arguments.", four_percent); + }; + + control +} +``` + +That is all it takes to create your own drop-in compiler replacement or custom +compiler! For the sake of completeness I'll go over the rest of the stupid-stats +tool. + +``` +struct StupidVisitor { + println_count: usize, + arg_counts: Vec, +} +``` + +The `StupidVisitor` struct just keeps track of the number of `println!`s it has +seen and the count for each number of arguments. It implements +`syntax::visit::Visitor` to walk the AST. Mostly we just use the default +methods, these walk the AST taking no action. We override `visit_item` and +`visit_mac` to implement custom behaviour when we walk into items (items include +functions, modules, traits, structs, and so forth, we're only interested in +functions) and macros: + +``` +impl<'v> visit::Visitor<'v> for StupidVisitor { + fn visit_item(&mut self, i: &'v ast::Item) { + match i.node { + ast::Item_::ItemFn(ref decl, _, _, _, _) => { + // Record the number of args. + self.increment_args(decl.inputs.len()); + } + _ => {} + } + + // Keep walking. + visit::walk_item(self, i) + } + + fn visit_mac(&mut self, mac: &'v ast::Mac) { + // Find its name and check if it is "println". + let ast::Mac_::MacInvocTT(ref path, _, _) = mac.node; + if path_to_string(path) == "println" { + self.println_count += 1; + } + + // Keep walking. + visit::walk_mac(self, mac) + } +} +``` + +The `increment_args` method increments the correct count in +`StupidVisitor::arg_counts`. After we're done walking, `compute_arg_stats` does +some pretty basic maths to come up with the stats we want about arguments. + + +## What next? + +These APIs are pretty new and have a long way to go until they're really good. +If there are improvements you'd like to see or things you'd like to be able to +do, let me know in a comment or [GitHub issue](https://github.com/rust-lang/rust/issues). +In particular, it's not clear to me exactly what extra flexibility is required. +If you have an existing tool that would be suited to this setup, please try it +out and let me know if you have problems. + +It'd be great to see Rustdoc converted to using these APIs, if that is possible +(although long term, I'd prefer to see Rustdoc run on the output from save- +analysis, rather than doing its own analysis). Other parts of the compiler +(e.g., pretty printing, testing) could be refactored to use these APIs +internally (I already changed save-analysis to use `CompilerController`). I've +been experimenting with a prototype rustfmt which also uses these APIs. diff --git a/src/mir-borrowck.md b/src/mir-borrowck.md index 3c10191d4..ab99ac9dc 100644 --- a/src/mir-borrowck.md +++ b/src/mir-borrowck.md @@ -44,7 +44,7 @@ The overall flow of the borrow checker is as follows: Among other things, this function will replace all of the regions in the MIR with fresh [inference variables](glossary.html). - (More details can be found in [the regionck section](./mir-regionck.html).) -- Next, we perform a number of [dataflow analyses](./background.html#dataflow) +- Next, we perform a number of [dataflow analyses](./appendix-background.html#dataflow) that compute what data is moved and when. The results of these analyses are needed to do both borrow checking and region inference. - Using the move data, we can then compute the values of all the regions in the MIR. diff --git a/src/mir-regionck.md b/src/mir-regionck.md index e7b12405a..dbf740ea8 100644 --- a/src/mir-regionck.md +++ b/src/mir-regionck.md @@ -35,7 +35,7 @@ The MIR-based region analysis consists of two major functions: - More details to come, though the [NLL RFC] also includes fairly thorough (and hopefully readable) coverage. -[fvb]: background.html#free-vs-bound +[fvb]: appendix-background.html#free-vs-bound [NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html ## Universal regions @@ -129,7 +129,7 @@ are going to wind up with a subtyping relationship like this one: We handle this sort of subtyping by taking the variables that are bound in the supertype and **skolemizing** them: this means that we replace them with -[universally quantified](background.html#quantified) +[universally quantified](appendix-background.html#quantified) representatives, written like `!1`. We call these regions "skolemized regions" -- they represent, basically, "some unknown region". @@ -144,7 +144,7 @@ what we wanted. So let's work through what happens next. To check if two functions are subtypes, we check if their arguments have the desired relationship -(fn arguments are [contravariant](./background.html#variance), so +(fn arguments are [contravariant](./appendix-background.html#variance), so we swap the left and right here): &'!1 u32 <: &'static u32 @@ -181,7 +181,7 @@ Here, the root universe would consist of the lifetimes `'static` and the same concept to types, in which case the types `Foo` and `T` would be in the root universe (along with other global types, like `i32`). Basically, the root universe contains all the names that -[appear free](./background.html#free-vs-bound) in the body of `bar`. +[appear free](./appendix-background.html#free-vs-bound) in the body of `bar`. Now let's extend `bar` a bit by adding a variable `x`: diff --git a/src/mir.md b/src/mir.md index 6e7ac0691..5c4b16310 100644 --- a/src/mir.md +++ b/src/mir.md @@ -26,7 +26,7 @@ Some of the key characteristics of MIR are: - It does not have nested expressions. - All types in MIR are fully explicit. -[cfg]: ./background.html#cfg +[cfg]: ./appendix-background.html#cfg ## Key MIR vocabulary From 53aa601f7fede5d7910a0ffa675f36fba18a0d87 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 7 Mar 2018 22:32:45 +0800 Subject: [PATCH 0145/1812] Thank you link checker! --- src/mir-borrowck.md | 2 +- src/mir.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mir-borrowck.md b/src/mir-borrowck.md index ab99ac9dc..6c4c99d61 100644 --- a/src/mir-borrowck.md +++ b/src/mir-borrowck.md @@ -42,7 +42,7 @@ The overall flow of the borrow checker is as follows: include references to the new regions that we are computing. - We then invoke `nll::replace_regions_in_mir` to modify this copy C. Among other things, this function will replace all of the regions in - the MIR with fresh [inference variables](glossary.html). + the MIR with fresh [inference variables](./appendix-glossary.html). - (More details can be found in [the regionck section](./mir-regionck.html).) - Next, we perform a number of [dataflow analyses](./appendix-background.html#dataflow) that compute what data is moved and when. The results of these analyses diff --git a/src/mir.md b/src/mir.md index 5c4b16310..688a8750c 100644 --- a/src/mir.md +++ b/src/mir.md @@ -239,4 +239,4 @@ but [you can read about those below](#promoted)). [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir [mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir -[newtype'd]: glossary.html +[newtype'd]: appendix-glossary.html From d28ae97736d019dfdddff74dcc8db03a9f19fa67 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 7 Mar 2018 22:42:27 +0800 Subject: [PATCH 0146/1812] Added a couple definitions to the code index --- src/appendix-code-index.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/appendix-code-index.md b/src/appendix-code-index.md index 64a40f74d..2097d61ae 100644 --- a/src/appendix-code-index.md +++ b/src/appendix-code-index.md @@ -7,7 +7,11 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- `CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser](the-parser.html) | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) +`CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver](rustc-driver.html) | [src/librustc_driver/driver.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_driver/driver.rs) +`ast::Crate` | struct | Syntax-level representation of a parsed crate | | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast.rs) +`hir::Crate` | struct | Top-level data structure representing the crate being compiled | | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/hir/mod.rs) `ParseSess` | struct | This struct contains information about a parsing session | [The parser](the-parser.html) | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser](the-parser.html) | [src/libsyntax/parse/lexer/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs) +`Session` | struct | The data associated with a compilation session | [the Parser](the-parser.html), [The Rustc Driver](rustc-driver.html) | [src/librustc/session/mod.html](https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules](ty.html) | [src/librustc/ty/trait_def.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/trait_def.rs) `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) From 27225507d78c35f2b6d0a592bf617c6cb1e10e83 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 12 Mar 2018 18:51:08 +0800 Subject: [PATCH 0147/1812] Addressed some of @nrc and @mark-i-m's comments --- src/appendix-code-index.md | 23 ++++++++++++++--------- src/rustc-driver.md | 13 +++++++++---- 2 files changed, 23 insertions(+), 13 deletions(-) diff --git a/src/appendix-code-index.md b/src/appendix-code-index.md index 2097d61ae..f6dcb9c37 100644 --- a/src/appendix-code-index.md +++ b/src/appendix-code-index.md @@ -6,12 +6,17 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- -`CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser](the-parser.html) | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) -`CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver](rustc-driver.html) | [src/librustc_driver/driver.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_driver/driver.rs) -`ast::Crate` | struct | Syntax-level representation of a parsed crate | | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast.rs) -`hir::Crate` | struct | Top-level data structure representing the crate being compiled | | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/hir/mod.rs) -`ParseSess` | struct | This struct contains information about a parsing session | [The parser](the-parser.html) | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) -`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser](the-parser.html) | [src/libsyntax/parse/lexer/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs) -`Session` | struct | The data associated with a compilation session | [the Parser](the-parser.html), [The Rustc Driver](rustc-driver.html) | [src/librustc/session/mod.html](https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs) -`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules](ty.html) | [src/librustc/ty/trait_def.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/trait_def.rs) -`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules](ty.html) | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) +`CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser] | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) +`CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_driver/driver.rs) +`ast::Crate` | struct | Syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast.rs) +`hir::Crate` | struct | More abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/hir/mod.rs) +`ParseSess` | struct | This struct contains information about a parsing session | [the Parser] | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) +`Session` | struct | The data associated with a compilation session | [the Parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs) +`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs) +`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/trait_def.rs) +`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules] | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) + +[The HIR]: hir.html +[The parser]: the-parser.html +[The Rustc Driver]: rustc-driver.html +[The `ty` modules]: ty.html diff --git a/src/rustc-driver.md b/src/rustc-driver.md index b21cc3662..7e6eb7e2e 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -8,7 +8,7 @@ managing state such as the [`CodeMap`] \(maps AST nodes to source code), stuff). The `rustc_driver` crate also provides external users with a method for running code at particular times during the compilation process, allowing third parties to effectively use `rustc`'s internals as a library for -analysing a crate. +analysing a crate or emulating the compiler in-process (e.g. the RLS). For those using `rustc` as a library, the `run_compiler()` function is the main entrypoint to the compiler. Its main parameters are a list of command-line @@ -20,10 +20,12 @@ of each phase. From `rustc_driver`'s perspective, the main phases of the compiler are: 1. *Parse Input:* Initial crate parsing -2. *Configure and Expand:* Resolve `#[cfg]` attributes and expand macros -3. *Run Analysis Passes:* Run the resolution, typechecking, region checking +2. *Configure and Expand:* Resolve `#[cfg]` attributes, name resolution, and + expand macros +3. *Run Analysis Passes:* Run trait resolution, typechecking, region checking and other miscellaneous analysis passes on the crate -4. *Translate to LLVM:* Turn the analysed program into executable code +4. *Translate to LLVM:* Translate to the in-memory form of LLVM IR and turn it + into an executable/object files The `CompileController` then gives users the ability to inspect the ongoing compilation process @@ -37,6 +39,9 @@ compilation process The `CompileState`'s various `state_after_*()` constructors can be inspected to determine what bits of information are available to which callback. +> **Warning:** By its very nature, the internal compiler APIs are always going +> to be unstable. That said, we do try not to break things unnecessarily. + ## A Note On Lifetimes The Rust compiler is a fairly large program containing lots of big data From c919a89995e9bd46ebc08ae407ab498a3cde202c Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 12 Mar 2018 19:04:18 +0800 Subject: [PATCH 0148/1812] Updated stupid-stats cc: nrc/stupid-stats#8 --- src/appendix-stupid-stats.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md index 405577e3c..b1c9d2141 100644 --- a/src/appendix-stupid-stats.md +++ b/src/appendix-stupid-stats.md @@ -243,13 +243,15 @@ impl<'a> CompilerCalls<'a> for StupidCalls { } fn late_callback(&mut self, + t: &TransCrate, m: &getopts::Matches, s: &Session, + c: &CrateStore, i: &Input, - odir: &Option, - ofile: &Option) + odir: &Option, + ofile: &Option) -> Compilation { - self.default_calls.late_callback(m, s, i, odir, ofile); + self.default_calls.late_callback(t, m, s, c, i, odir, ofile); Compilation::Continue } @@ -393,4 +395,4 @@ It'd be great to see Rustdoc converted to using these APIs, if that is possible analysis, rather than doing its own analysis). Other parts of the compiler (e.g., pretty printing, testing) could be refactored to use these APIs internally (I already changed save-analysis to use `CompilerController`). I've -been experimenting with a prototype rustfmt which also uses these APIs. +been experimenting with a prototype rustfmt which also uses these APIs. \ No newline at end of file From 746753138a708ee0585018db13d8b2fb6e1f5e62 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 12 Mar 2018 19:15:06 +0800 Subject: [PATCH 0149/1812] Fixed a broken link --- src/traits-canonicalization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index fc55fac0d..6ff61fdda 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -41,7 +41,7 @@ trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound. This query contains two unbound variables, but it also contains the lifetime `'static`. The trait system generally ignores all lifetimes and treats them equally, so when canonicalizing, we will *also* -replace any [free lifetime](./background.html#free-vs-bound) with a +replace any [free lifetime](./appendix-background.html#free-vs-bound) with a canonical variable. Therefore, we get the following result: ?0: Foo<'?1, ?2> From 9874533b6e5a3b33b0d6205d62948a6c216d0014 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 12 Mar 2018 19:15:26 +0800 Subject: [PATCH 0150/1812] Added links back to nrc's stupid-stats --- src/appendix-stupid-stats.md | 9 ++++++++- src/rustc-driver.md | 7 ++++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md index b1c9d2141..20d5aaf9b 100644 --- a/src/appendix-stupid-stats.md +++ b/src/appendix-stupid-stats.md @@ -1,5 +1,10 @@ # Appendix A: A tutorial on creating a drop-in replacement for rustc +> **Note:** This is a copy of `@nrc`'s amazing [stupid-stats]. You should find +> a copy of the code on the GitHub repository although due to the compiler's +> constantly evolving nature, there is no guarantee it'll compile on the first +> go. + Many tools benefit from being a drop-in replacement for a compiler. By this, I mean that any user of the tool can use `mytool` in all the ways they would normally use `rustc` - whether manually compiling a single file or as part of a @@ -395,4 +400,6 @@ It'd be great to see Rustdoc converted to using these APIs, if that is possible analysis, rather than doing its own analysis). Other parts of the compiler (e.g., pretty printing, testing) could be refactored to use these APIs internally (I already changed save-analysis to use `CompilerController`). I've -been experimenting with a prototype rustfmt which also uses these APIs. \ No newline at end of file +been experimenting with a prototype rustfmt which also uses these APIs. + +[stupid-stats]: https://github.com/nrc/stupid-stats \ No newline at end of file diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 7e6eb7e2e..23a036e73 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -39,6 +39,9 @@ compilation process The `CompileState`'s various `state_after_*()` constructors can be inspected to determine what bits of information are available to which callback. +For a more detailed explanation on using `rustc_driver`, check out the +[stupid-stats] guide by `@nrc` (attached as [Appendix A]). + > **Warning:** By its very nature, the internal compiler APIs are always going > to be unstable. That said, we do try not to break things unnecessarily. @@ -68,4 +71,6 @@ thread-locals, although you should rarely need to touch it. [`CompileState`]: https://github.com/rust-lang/rust/blob/master/src/librustc_driver/driver.rs [`Session`]: https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs [`TyCtxt`]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs -[`CodeMap`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs \ No newline at end of file +[`CodeMap`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs +[stupid-stats]: https://github.com/nrc/stupid-stats +[Appendix A]: appendix-stupid-stats.html \ No newline at end of file From ed04741208d43863b8fc694a49f680fc473d15d9 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Mar 2018 12:54:19 -0500 Subject: [PATCH 0151/1812] fix typo --- src/traits-canonicalization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index 6ff61fdda..bef858af2 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -218,7 +218,7 @@ for later verification. than eagerly instantiating all of the canonical values in the result with variables, we instead walk the vector of values, looking for cases where the value is just a canonical variable. In our example, -`values[2]` is `?C`, so that we means we can deduce that `?C := ?B and +`values[2]` is `?C`, so that means we can deduce that `?C := ?B and `'?D := 'static`. This gives us a partial set of values. Anything for which we do not find a value, we create an inference variable.) From e74567479d6f3592ae322d418b8fa13e4dc7e593 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Mar 2018 19:39:56 -0500 Subject: [PATCH 0152/1812] Add the contents of the typeck READMEs --- src/SUMMARY.md | 2 + src/appendix-background.md | 3 + src/appendix-code-index.md | 2 + src/appendix-glossary.md | 3 +- src/method-lookup.md | 119 +++++++++++++++ src/type-checking.md | 43 ++++++ src/variance.md | 296 +++++++++++++++++++++++++++++++++++++ 7 files changed, 467 insertions(+), 1 deletion(-) create mode 100644 src/method-lookup.md create mode 100644 src/variance.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index eb889d36b..9215f8afa 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -35,6 +35,8 @@ - [The SLG solver](./traits-slg.md) - [Bibliography](./traits-bibliography.md) - [Type checking](./type-checking.md) + - [Method Lookup](./method-lookup.md) + - [Variance](./variance.md) - [The MIR (Mid-level IR)](./mir.md) - [MIR construction](./mir-construction.md) - [MIR visitor and traversal](./mir-visitor.md) diff --git a/src/appendix-background.md b/src/appendix-background.md index c69e7d93d..b49ad6d52 100644 --- a/src/appendix-background.md +++ b/src/appendix-background.md @@ -91,6 +91,9 @@ cycle. Check out the subtyping chapter from the [Rust Nomicon](https://doc.rust-lang.org/nomicon/subtyping.html). +See the [variance](./variance.html) chapter of this guide for more info on how +the type checker handles variance. + ## What is a "free region" or a "free variable"? What about "bound region"? diff --git a/src/appendix-code-index.md b/src/appendix-code-index.md index f6dcb9c37..3ca9bfb76 100644 --- a/src/appendix-code-index.md +++ b/src/appendix-code-index.md @@ -14,9 +14,11 @@ Item | Kind | Short description | Chapter | `Session` | struct | The data associated with a compilation session | [the Parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/trait_def.rs) +`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/mod.rs) `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules] | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) [The HIR]: hir.html [The parser]: the-parser.html [The Rustc Driver]: rustc-driver.html +[Type checking]: type-checking.html [The `ty` modules]: ty.html diff --git a/src/appendix-glossary.md b/src/appendix-glossary.md index 1914adec6..8a3df24e8 100644 --- a/src/appendix-glossary.md +++ b/src/appendix-glossary.md @@ -56,7 +56,8 @@ token | the smallest unit of parsing. Tokens are produced aft trans | the code to translate MIR into LLVM IR. trait reference | a trait and values for its type parameters ([see more](ty.html)). ty | the internal representation of a type ([see more](ty.html)). -variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter for more](./appendix-background.html#variance). +UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](type-checking.html)). +variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./appendix-background.html#variance) for a more general explanation. See the [variance chapter](./variance.html) for an explanation of how type checking handles variance. [LLVM]: https://llvm.org/ [lto]: https://llvm.org/docs/LinkTimeOptimization.html diff --git a/src/method-lookup.md b/src/method-lookup.md new file mode 100644 index 000000000..543428d62 --- /dev/null +++ b/src/method-lookup.md @@ -0,0 +1,119 @@ +# Method lookup + +Method lookup can be rather complex due to the interaction of a number +of factors, such as self types, autoderef, trait lookup, etc. This +file provides an overview of the process. More detailed notes are in +the code itself, naturally. + +One way to think of method lookup is that we convert an expression of +the form: + +```rust +receiver.method(...) +``` + +into a more explicit UFCS form: + +```rust +Trait::method(ADJ(receiver), ...) // for a trait call +ReceiverType::method(ADJ(receiver), ...) // for an inherent method call +``` + +Here `ADJ` is some kind of adjustment, which is typically a series of +autoderefs and then possibly an autoref (e.g., `&**receiver`). However +we sometimes do other adjustments and coercions along the way, in +particular unsizing (e.g., converting from `[T; n]` to `[T]`). + +Method lookup is divided into two major phases: + +1. Probing ([`probe.rs`][probe]). The probe phase is when we decide what method + to call and how to adjust the receiver. +2. Confirmation ([`confirm.rs`][confirm]). The confirmation phase "applies" + this selection, updating the side-tables, unifying type variables, and + otherwise doing side-effectful things. + +One reason for this division is to be more amenable to caching. The +probe phase produces a "pick" (`probe::Pick`), which is designed to be +cacheable across method-call sites. Therefore, it does not include +inference variables or other information. + +[probe]: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/method/probe.rs +[confirm]: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/method/confirm.rs + +## The Probe phase + +### Steps + +The first thing that the probe phase does is to create a series of +*steps*. This is done by progressively dereferencing the receiver type +until it cannot be deref'd anymore, as well as applying an optional +"unsize" step. So if the receiver has type `Rc>`, this +might yield: + +```rust +Rc> +Box<[T; 3]> +[T; 3] +[T] +``` + +### Candidate assembly + +We then search along those steps to create a list of *candidates*. A +`Candidate` is a method item that might plausibly be the method being +invoked. For each candidate, we'll derive a "transformed self type" +that takes into account explicit self. + +Candidates are grouped into two kinds, inherent and extension. + +**Inherent candidates** are those that are derived from the +type of the receiver itself. So, if you have a receiver of some +nominal type `Foo` (e.g., a struct), any methods defined within an +impl like `impl Foo` are inherent methods. Nothing needs to be +imported to use an inherent method, they are associated with the type +itself (note that inherent impls can only be defined in the same +module as the type itself). + +FIXME: Inherent candidates are not always derived from impls. If you +have a trait object, such as a value of type `Box`, then the +trait methods (`to_string()`, in this case) are inherently associated +with it. Another case is type parameters, in which case the methods of +their bounds are inherent. However, this part of the rules is subject +to change: when DST's "impl Trait for Trait" is complete, trait object +dispatch could be subsumed into trait matching, and the type parameter +behavior should be reconsidered in light of where clauses. + +TODO: Is this FIXME still accurate? + +**Extension candidates** are derived from imported traits. If I have +the trait `ToString` imported, and I call `to_string()` on a value of +type `T`, then we will go off to find out whether there is an impl of +`ToString` for `T`. These kinds of method calls are called "extension +methods". They can be defined in any module, not only the one that +defined `T`. Furthermore, you must import the trait to call such a +method. + +So, let's continue our example. Imagine that we were calling a method +`foo` with the receiver `Rc>` and there is a trait `Foo` +that defines it with `&self` for the type `Rc` as well as a method +on the type `Box` that defines `Foo` but with `&mut self`. Then we +might have two candidates: + + &Rc> from the impl of `Foo` for `Rc` where `U=Box + &mut Box<[T; 3]>> from the inherent impl on `Box` where `U=[T; 3]` + +### Candidate search + +Finally, to actually pick the method, we will search down the steps, +trying to match the receiver type against the candidate types. At +each step, we also consider an auto-ref and auto-mut-ref to see whether +that makes any of the candidates match. We pick the first step where +we find a match. + +In the case of our example, the first step is `Rc>`, +which does not itself match any candidate. But when we autoref it, we +get the type `&Rc>` which does match. We would then +recursively consider all where-clauses that appear on the impl: if +those match (or we cannot rule out that they do), then this is the +method we would pick. Otherwise, we would continue down the series of +steps. diff --git a/src/type-checking.md b/src/type-checking.md index c559c1283..8148ef627 100644 --- a/src/type-checking.md +++ b/src/type-checking.md @@ -1 +1,44 @@ # Type checking + +The [`rustc_typeck`][typeck] crate contains the source for "type collection" +and "type checking", as well as a few other bits of related functionality. (It +draws heavily on the [type inference] and [trait solving].) + +[typeck]: https://github.com/rust-lang/rust/tree/master/src/librustc_typeck +[type inference]: type-inference.html +[trait solving]: trait-resolution.html + +## Type collection + +Type "collection" is the process of converting the types found in the HIR +(`hir::Ty`), which represent the syntactic things that the user wrote, into the +**internal representation** used by the compiler (`Ty<'tcx>`) -- we also do +similar conversions for where-clauses and other bits of the function signature. + +To try and get a sense for the difference, consider this function: + +```rust +struct Foo { } +fn foo(x: Foo, y: self::Foo) { .. } +// ^^^ ^^^^^^^^^ +``` + +Those two parameters `x` and `y` each have the same type: but they will have +distinct `hir::Ty` nodes. Those nodes will have different spans, and of course +they encode the path somewhat differently. But once they are "collected" into +`Ty<'tcx>` nodes, they will be represented by the exact same internal type. + +Collection is defined as a bundle of [queries] for computing information about +the various functions, traits, and other items in the crate being compiled. +Note that each of these queries is concerned with *interprocedural* things -- +for example, for a function definition, collection will figure out the type and +signature of the function, but it will not visit the *body* of the function in +any way, nor examine type annotations on local variables (that's the job of +type *checking*). + +For more details, see the [`collect`][collect] module. + +[queries]: query.html +[collect]: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/collect.rs + +**TODO**: actually talk about type checking... diff --git a/src/variance.md b/src/variance.md new file mode 100644 index 000000000..16b4a7518 --- /dev/null +++ b/src/variance.md @@ -0,0 +1,296 @@ +# Variance of type and lifetime parameters + +For a more general background on variance, see the [background] appendix. + +[background]: ./appendix-background.html + +During type checking we must infer the variance of type and lifetime +parameters. The algorithm is taken from Section 4 of the paper ["Taming the +Wildcards: Combining Definition- and Use-Site Variance"][pldi11] published in +PLDI'11 and written by Altidor et al., and hereafter referred to as The Paper. + +[pldi11]: https://people.cs.umass.edu/~yannis/variance-extended2011.pdf + +This inference is explicitly designed *not* to consider the uses of +types within code. To determine the variance of type parameters +defined on type `X`, we only consider the definition of the type `X` +and the definitions of any types it references. + +We only infer variance for type parameters found on *data types* +like structs and enums. In these cases, there is a fairly straightforward +explanation for what variance means. The variance of the type +or lifetime parameters defines whether `T` is a subtype of `T` +(resp. `T<'a>` and `T<'b>`) based on the relationship of `A` and `B` +(resp. `'a` and `'b`). + +We do not infer variance for type parameters found on traits, functions, +or impls. Variance on trait parameters can indeed make sense +(and we used to compute it) but it is actually rather subtle in +meaning and not that useful in practice, so we removed it. See the +[addendum] for some details. Variances on function/impl parameters, on the +other hand, doesn't make sense because these parameters are instantiated and +then forgotten, they don't persist in types or compiled byproducts. + +[addendum]: #addendum + +> **Notation** +> +> We use the notation of The Paper throughout this chapter: +> +> - `+` is _covariance_. +> - `-` is _contravariance_. +> - `*` is _bivariance_. +> - `o` is _invariance_. + +## The algorithm + +The basic idea is quite straightforward. We iterate over the types +defined and, for each use of a type parameter `X`, accumulate a +constraint indicating that the variance of `X` must be valid for the +variance of that use site. We then iteratively refine the variance of +`X` until all constraints are met. There is *always* a solution, because at +the limit we can declare all type parameters to be invariant and all +constraints will be satisfied. + +As a simple example, consider: + +```rust +enum Option { Some(A), None } +enum OptionalFn { Some(|B|), None } +enum OptionalMap { Some(|C| -> C), None } +``` + +Here, we will generate the constraints: + + 1. V(A) <= + + 2. V(B) <= - + 3. V(C) <= + + 4. V(C) <= - + +These indicate that (1) the variance of A must be at most covariant; +(2) the variance of B must be at most contravariant; and (3, 4) the +variance of C must be at most covariant *and* contravariant. All of these +results are based on a variance lattice defined as follows: + + * Top (bivariant) + - + + o Bottom (invariant) + +Based on this lattice, the solution `V(A)=+`, `V(B)=-`, `V(C)=o` is the +optimal solution. Note that there is always a naive solution which +just declares all variables to be invariant. + +You may be wondering why fixed-point iteration is required. The reason +is that the variance of a use site may itself be a function of the +variance of other type parameters. In full generality, our constraints +take the form: + + V(X) <= Term + Term := + | - | * | o | V(X) | Term x Term + +Here the notation `V(X)` indicates the variance of a type/region +parameter `X` with respect to its defining class. `Term x Term` +represents the "variance transform" as defined in the paper: + +> If the variance of a type variable `X` in type expression `E` is `V2` + and the definition-site variance of the [corresponding] type parameter + of a class `C` is `V1`, then the variance of `X` in the type expression + `C` is `V3 = V1.xform(V2)`. + +## Constraints + +If I have a struct or enum with where clauses: + +```rust +struct Foo { ... } +``` + +you might wonder whether the variance of `T` with respect to `Bar` affects the +variance `T` with respect to `Foo`. I claim no. The reason: assume that `T` is +invariant with respect to `Bar` but covariant with respect to `Foo`. And then +we have a `Foo` that is upcast to `Foo`, where `X <: Y`. However, while +`X : Bar`, `Y : Bar` does not hold. In that case, the upcast will be illegal, +but not because of a variance failure, but rather because the target type +`Foo` is itself just not well-formed. Basically we get to assume +well-formedness of all types involved before considering variance. + +### Dependency graph management + +Because variance is a whole-crate inference, its dependency graph +can become quite muddled if we are not careful. To resolve this, we refactor +into two queries: + +- `crate_variances` computes the variance for all items in the current crate. +- `variances_of` accesses the variance for an individual reading; it + works by requesting `crate_variances` and extracting the relevant data. + +If you limit yourself to reading `variances_of`, your code will only +depend then on the inference of that particular item. + +Ultimately, this setup relies on the [red-green algorithm][rga]. In particular, +every variance query effectively depends on all type definitions in the entire +crate (through `crate_variances`), but since most changes will not result in a +change to the actual results from variance inference, the `variances_of` query +will wind up being considered green after it is re-evaluated. + +[rga]: ./incremental-compilation.html + + + +## Addendum: Variance on traits + +As mentioned above, we used to permit variance on traits. This was +computed based on the appearance of trait type parameters in +method signatures and was used to represent the compatibility of +vtables in trait objects (and also "virtual" vtables or dictionary +in trait bounds). One complication was that variance for +associated types is less obvious, since they can be projected out +and put to myriad uses, so it's not clear when it is safe to allow +`X::Bar` to vary (or indeed just what that means). Moreover (as +covered below) all inputs on any trait with an associated type had +to be invariant, limiting the applicability. Finally, the +annotations (`MarkerTrait`, `PhantomFn`) needed to ensure that all +trait type parameters had a variance were confusing and annoying +for little benefit. + +Just for historical reference, I am going to preserve some text indicating how +one could interpret variance and trait matching. + +### Variance and object types + +Just as with structs and enums, we can decide the subtyping +relationship between two object types `&Trait` and `&Trait` +based on the relationship of `A` and `B`. Note that for object +types we ignore the `Self` type parameter -- it is unknown, and +the nature of dynamic dispatch ensures that we will always call a +function that is expected the appropriate `Self` type. However, we +must be careful with the other type parameters, or else we could +end up calling a function that is expecting one type but provided +another. + +To see what I mean, consider a trait like so: + + trait ConvertTo { + fn convertTo(&self) -> A; + } + +Intuitively, If we had one object `O=&ConvertTo` and another +`S=&ConvertTo`, then `S <: O` because `String <: Object` +(presuming Java-like "string" and "object" types, my go to examples +for subtyping). The actual algorithm would be to compare the +(explicit) type parameters pairwise respecting their variance: here, +the type parameter A is covariant (it appears only in a return +position), and hence we require that `String <: Object`. + +You'll note though that we did not consider the binding for the +(implicit) `Self` type parameter: in fact, it is unknown, so that's +good. The reason we can ignore that parameter is precisely because we +don't need to know its value until a call occurs, and at that time (as +you said) the dynamic nature of virtual dispatch means the code we run +will be correct for whatever value `Self` happens to be bound to for +the particular object whose method we called. `Self` is thus different +from `A`, because the caller requires that `A` be known in order to +know the return type of the method `convertTo()`. (As an aside, we +have rules preventing methods where `Self` appears outside of the +receiver position from being called via an object.) + +### Trait variance and vtable resolution + +But traits aren't only used with objects. They're also used when +deciding whether a given impl satisfies a given trait bound. To set the +scene here, imagine I had a function: + + fn convertAll>(v: &[T]) { + ... + } + +Now imagine that I have an implementation of `ConvertTo` for `Object`: + + impl ConvertTo for Object { ... } + +And I want to call `convertAll` on an array of strings. Suppose +further that for whatever reason I specifically supply the value of +`String` for the type parameter `T`: + + let mut vector = vec!["string", ...]; + convertAll::(vector); + +Is this legal? To put another way, can we apply the `impl` for +`Object` to the type `String`? The answer is yes, but to see why +we have to expand out what will happen: + +- `convertAll` will create a pointer to one of the entries in the + vector, which will have type `&String` +- It will then call the impl of `convertTo()` that is intended + for use with objects. This has the type: + + fn(self: &Object) -> i32 + + It is ok to provide a value for `self` of type `&String` because + `&String <: &Object`. + +OK, so intuitively we want this to be legal, so let's bring this back +to variance and see whether we are computing the correct result. We +must first figure out how to phrase the question "is an impl for +`Object,i32` usable where an impl for `String,i32` is expected?" + +Maybe it's helpful to think of a dictionary-passing implementation of +type classes. In that case, `convertAll()` takes an implicit parameter +representing the impl. In short, we *have* an impl of type: + + V_O = ConvertTo for Object + +and the function prototype expects an impl of type: + + V_S = ConvertTo for String + +As with any argument, this is legal if the type of the value given +(`V_O`) is a subtype of the type expected (`V_S`). So is `V_O <: V_S`? +The answer will depend on the variance of the various parameters. In +this case, because the `Self` parameter is contravariant and `A` is +covariant, it means that: + + V_O <: V_S iff + i32 <: i32 + String <: Object + +These conditions are satisfied and so we are happy. + +### Variance and associated types + +Traits with associated types -- or at minimum projection +expressions -- must be invariant with respect to all of their +inputs. To see why this makes sense, consider what subtyping for a +trait reference means: + + <: + +means that if I know that `T as Trait`, I also know that `U as +Trait`. Moreover, if you think of it as dictionary passing style, +it means that a dictionary for `` is safe to use where +a dictionary for `` is expected. + +The problem is that when you can project types out from ``, the relationship to types projected out of `` +is completely unknown unless `T==U` (see #21726 for more +details). Making `Trait` invariant ensures that this is true. + +Another related reason is that if we didn't make traits with +associated types invariant, then projection is no longer a +function with a single result. Consider: + +``` +trait Identity { type Out; fn foo(&self); } +impl Identity for T { type Out = T; ... } +``` + +Now if I have `<&'static () as Identity>::Out`, this can be +validly derived as `&'a ()` for any `'a`: + + <&'a () as Identity> <: <&'static () as Identity> + if &'static () < : &'a () -- Identity is contravariant in Self + if 'static : 'a -- Subtyping rules for relations + +This change otoh means that `<'static () as Identity>::Out` is +always `&'static ()` (which might then be upcast to `'a ()`, +separately). This was helpful in solving #21750. From a19cdc7a7174fe00f308983673dce572cc1d02d7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 12 Mar 2018 19:50:43 -0500 Subject: [PATCH 0153/1812] Add the rustdoc readme --- src/SUMMARY.md | 1 + src/rustdoc.md | 177 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 178 insertions(+) create mode 100644 src/rustdoc.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 9215f8afa..3079c0b48 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -10,6 +10,7 @@ - [Walkthrough: a typical contribution](./walkthrough.md) - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver](./rustc-driver.md) + - [Rustdoc](./rustdoc.md) - [Queries: demand-driven compilation](./query.md) - [Incremental compilation](./incremental-compilation.md) - [The parser](./the-parser.md) diff --git a/src/rustdoc.md b/src/rustdoc.md new file mode 100644 index 000000000..4236ad6ff --- /dev/null +++ b/src/rustdoc.md @@ -0,0 +1,177 @@ +# The walking tour of rustdoc + +Rustdoc actually uses the rustc internals directly. It lives in-tree with the compiler and standard +library. This chapter is about how it works. (A new implementation is also [under way], though). + +[under way]: https://github.com/steveklabnik/rustdoc + +Rustdoc is implemented entirely within the crate `librustdoc`. After partially compiling a crate to +get its AST (technically the HIR map) from rustc, librustdoc performs two major steps past that to +render a set of documentation: + +* "Clean" the AST into a form that's more suited to creating documentation (and slightly more + resistant to churn in the compiler). +* Use this cleaned AST to render a crate's documentation, one page at a time. + +Naturally, there's more than just this, and those descriptions simplify out lots of details, but +that's the high-level overview. + +(Side note: this is a library crate! The `rustdoc` binary is crated using the project in +`src/tools/rustdoc`. Note that literally all that does is call the `main()` that's in this crate's +`lib.rs`, though.) + +## Cheat sheet + +* Use `x.py build --stage 1 src/libstd src/tools/rustdoc` to make a useable rustdoc you can run on + other projects. + * Add `src/libtest` to be able to use `rustdoc --test`. + * If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1` previously, then + after the previous build command, `cargo +local doc` will Just Work. +* Use `x.py doc --stage 1 src/libstd` to use this rustdoc to generate the standard library docs. + * The completed docs will be available in `build/$TARGET/doc/std`, though the bundle is meant to + be used as though you would copy out the `doc` folder to a web server, since that's where the + CSS/JS and landing page are. +* Most of the HTML printing code is in `html/format.rs` and `html/render.rs`. It's in a bunch of + `fmt::Display` implementations and supplementary functions. +* The types that got `Display` impls above are defined in `clean/mod.rs`, right next to the custom + `Clean` trait used to process them out of the rustc HIR. +* The bits specific to using rustdoc as a test harness are in `test.rs`. +* The Markdown renderer is loaded up in `html/markdown.rs`, including functions for extracting + doctests from a given block of Markdown. +* The tests on rustdoc *output* are located in `src/test/rustdoc`, where they're handled by the test + runner of rustbuild and the supplementary script `src/etc/htmldocck.py`. +* Tests on search index generation are located in `src/test/rustdoc-js`, as a series of JavaScript + files that encode queries on the standard library search index and expected results. + +## From crate to clean + +In `core.rs` are two central items: the `DocContext` struct, and the `run_core` function. The latter +is where rustdoc calls out to rustc to compile a crate to the point where rustdoc can take over. The +former is a state container used when crawling through a crate to gather its documentation. + +The main process of crate crawling is done in `clean/mod.rs` through several implementations of the +`Clean` trait defined within. This is a conversion trait, which defines one method: + +```rust +pub trait Clean { + fn clean(&self, cx: &DocContext) -> T; +} +``` + +`clean/mod.rs` also defines the types for the "cleaned" AST used later on to render documentation +pages. Each usually accompanies an implementation of `Clean` that takes some AST or HIR type from +rustc and converts it into the appropriate "cleaned" type. "Big" items like modules or associated +items may have some extra processing in its `Clean` implementation, but for the most part these +impls are straightforward conversions. The "entry point" to this module is the `impl Clean +for visit_ast::RustdocVisitor`, which is called by `run_core` above. + +You see, I actually lied a little earlier: There's another AST transformation that happens before +the events in `clean/mod.rs`. In `visit_ast.rs` is the type `RustdocVisitor`, which *actually* +crawls a `hir::Crate` to get the first intermediate representation, defined in `doctree.rs`. This +pass is mainly to get a few intermediate wrappers around the HIR types and to process visibility +and inlining. This is where `#[doc(inline)]`, `#[doc(no_inline)]`, and `#[doc(hidden)]` are +processed, as well as the logic for whether a `pub use` should get the full page or a "Reexport" +line in the module page. + +The other major thing that happens in `clean/mod.rs` is the collection of doc comments and +`#[doc=""]` attributes into a separate field of the Attributes struct, present on anything that gets +hand-written documentation. This makes it easier to collect this documentation later in the process. + +The primary output of this process is a clean::Crate with a tree of Items which describe the +publicly-documentable items in the target crate. + +### Hot potato + +Before moving on to the next major step, a few important "passes" occur over the documentation. +These do things like combine the separate "attributes" into a single string and strip leading +whitespace to make the document easier on the markdown parser, or drop items that are not public or +deliberately hidden with `#[doc(hidden)]`. These are all implemented in the `passes/` directory, one +file per pass. By default, all of these passes are run on a crate, but the ones regarding dropping +private/hidden items can be bypassed by passing `--document-private-items` to rustdoc. + +(Strictly speaking, you can fine-tune the passes run and even add your own, but [we're trying to +deprecate that][44136]. If you need finer-grain control over these passes, please let us know!) + +[44136]: https://github.com/rust-lang/rust/issues/44136 + +## From clean to crate + +This is where the "second phase" in rustdoc begins. This phase primarily lives in the `html/` +folder, and it all starts with `run()` in `html/render.rs`. This code is responsible for setting up +the `Context`, `SharedContext`, and `Cache` which are used during rendering, copying out the static +files which live in every rendered set of documentation (things like the fonts, CSS, and JavaScript +that live in `html/static/`), creating the search index, and printing out the source code rendering, +before beginning the process of rendering all the documentation for the crate. + +Several functions implemented directly on `Context` take the `clean::Crate` and set up some state +between rendering items or recursing on a module's child items. From here the "page rendering" +begins, via an enormous `write!()` call in `html/layout.rs`. The parts that actually generate HTML +from the items and documentation occurs within a series of `std::fmt::Display` implementations and +functions that pass around a `&mut std::fmt::Formatter`. The top-level implementation that writes +out the page body is the `impl<'a> fmt::Display for Item<'a>` in `html/render.rs`, which switches +out to one of several `item_*` functions based on the kind of `Item` being rendered. + +Depending on what kind of rendering code you're looking for, you'll probably find it either in +`html/render.rs` for major items like "what sections should I print for a struct page" or +`html/format.rs` for smaller component pieces like "how should I print a where clause as part of +some other item". + +Whenever rustdoc comes across an item that should print hand-written documentation alongside, it +calls out to `html/markdown.rs` which interfaces with the Markdown parser. This is exposed as a +series of types that wrap a string of Markdown, and implement `fmt::Display` to emit HTML text. It +takes special care to enable certain features like footnotes and tables and add syntax highlighting +to Rust code blocks (via `html/highlight.rs`) before running the Markdown parser. There's also a +function in here (`find_testable_code`) that specifically scans for Rust code blocks so the +test-runner code can find all the doctests in the crate. + +### From soup to nuts + +(alternate title: ["An unbroken thread that stretches from those first `Cell`s to us"][video]) + +[video]: https://www.youtube.com/watch?v=hOLAGYmUQV0 + +It's important to note that the AST cleaning can ask the compiler for information (crucially, +`DocContext` contains a `TyCtxt`), but page rendering cannot. The `clean::Crate` created within +`run_core` is passed outside the compiler context before being handed to `html::render::run`. This +means that a lot of the "supplementary data" that isn't immediately available inside an item's +definition, like which trait is the `Deref` trait used by the language, needs to be collected during +cleaning, stored in the `DocContext`, and passed along to the `SharedContext` during HTML rendering. +This manifests as a bunch of shared state, context variables, and `RefCell`s. + +Also of note is that some items that come from "asking the compiler" don't go directly into the +`DocContext` - for example, when loading items from a foreign crate, rustdoc will ask about trait +implementations and generate new `Item`s for the impls based on that information. This goes directly +into the returned `Crate` rather than roundabout through the `DocContext`. This way, these +implementations can be collected alongside the others, right before rendering the HTML. + +## Other tricks up its sleeve + +All this describes the process for generating HTML documentation from a Rust crate, but there are +couple other major modes that rustdoc runs in. It can also be run on a standalone Markdown file, or +it can run doctests on Rust code or standalone Markdown files. For the former, it shortcuts straight +to `html/markdown.rs`, optionally including a mode which inserts a Table of Contents to the output +HTML. + +For the latter, rustdoc runs a similar partial-compilation to get relevant documentation in +`test.rs`, but instead of going through the full clean and render process, it runs a much simpler +crate walk to grab *just* the hand-written documentation. Combined with the aforementioned +"`find_testable_code`" in `html/markdown.rs`, it builds up a collection of tests to run before +handing them off to the libtest test runner. One notable location in `test.rs` is the function +`make_test`, which is where hand-written doctests get transformed into something that can be +executed. + +## Dotting i's and crossing t's + +So that's rustdoc's code in a nutshell, but there's more things in the repo that deal with it. Since +we have the full `compiletest` suite at hand, there's a set of tests in `src/test/rustdoc` that make +sure the final HTML is what we expect in various situations. These tests also use a supplementary +script, `src/etc/htmldocck.py`, that allows it to look through the final HTML using XPath notation +to get a precise look at the output. The full description of all the commands available to rustdoc +tests is in `htmldocck.py`. + +In addition, there are separate tests for the search index and rustdoc's ability to query it. The +files in `src/test/rustdoc-js` each contain a different search query and the expected results, +broken out by search tab. These files are processed by a script in `src/tools/rustdoc-js` and the +Node.js runtime. These tests don't have as thorough of a writeup, but a broad example that features +results in all tabs can be found in `basic.js`. The basic idea is that you match a given `QUERY` +with a set of `EXPECTED` results, complete with the full item path of each item. From 21ed6e6ce41667034e25c7ffee04d628e510af40 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 14 Mar 2018 22:08:09 -0500 Subject: [PATCH 0154/1812] Address review comments --- src/appendix-code-index.md | 1 + src/rustdoc.md | 44 ++++++++++++++++++++++++++++++++------ 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/src/appendix-code-index.md b/src/appendix-code-index.md index 3ca9bfb76..c5be7e336 100644 --- a/src/appendix-code-index.md +++ b/src/appendix-code-index.md @@ -8,6 +8,7 @@ Item | Kind | Short description | Chapter | ----------------|----------|-----------------------------|--------------------|------------------- `CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser] | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) `CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_driver/driver.rs) +`DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) `ast::Crate` | struct | Syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast.rs) `hir::Crate` | struct | More abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/hir/mod.rs) `ParseSess` | struct | This struct contains information about a parsing session | [the Parser] | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) diff --git a/src/rustdoc.md b/src/rustdoc.md index 4236ad6ff..2cacc80fd 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -5,9 +5,17 @@ library. This chapter is about how it works. (A new implementation is also [unde [under way]: https://github.com/steveklabnik/rustdoc -Rustdoc is implemented entirely within the crate `librustdoc`. After partially compiling a crate to -get its AST (technically the HIR map) from rustc, librustdoc performs two major steps past that to -render a set of documentation: +Rustdoc is implemented entirely within the crate [`librustdoc`][rd]. It runs +the compiler up to the point where we have an internal representation of a +crate (HIR) and the ability to run some queries about the types of items. [HIR] +and [queries] are discussed in the linked chapters. + +[HIR]: ./hir.html +[queries]: ./query.html +[rd]: https://github.com/rust-lang/rust/tree/master/src/librustdoc + +`librustdoc` performs two major steps after that to render a set of +documentation: * "Clean" the AST into a form that's more suited to creating documentation (and slightly more resistant to churn in the compiler). @@ -16,10 +24,12 @@ render a set of documentation: Naturally, there's more than just this, and those descriptions simplify out lots of details, but that's the high-level overview. -(Side note: this is a library crate! The `rustdoc` binary is crated using the project in -`src/tools/rustdoc`. Note that literally all that does is call the `main()` that's in this crate's +(Side note: `librustdoc` is a library crate! The `rustdoc` binary is crated using the project in +[`src/tools/rustdoc`][bin]. Note that literally all that does is call the `main()` that's in this crate's `lib.rs`, though.) +[bin]: https://github.com/rust-lang/rust/tree/master/src/tools/rustdoc + ## Cheat sheet * Use `x.py build --stage 1 src/libstd src/tools/rustdoc` to make a useable rustdoc you can run on @@ -87,13 +97,32 @@ These do things like combine the separate "attributes" into a single string and whitespace to make the document easier on the markdown parser, or drop items that are not public or deliberately hidden with `#[doc(hidden)]`. These are all implemented in the `passes/` directory, one file per pass. By default, all of these passes are run on a crate, but the ones regarding dropping -private/hidden items can be bypassed by passing `--document-private-items` to rustdoc. +private/hidden items can be bypassed by passing `--document-private-items` to rustdoc. Note that +unlike the previous set of AST transformations, the passes happen on the _cleaned_ crate. (Strictly speaking, you can fine-tune the passes run and even add your own, but [we're trying to deprecate that][44136]. If you need finer-grain control over these passes, please let us know!) [44136]: https://github.com/rust-lang/rust/issues/44136 +Here is current (as of this writing) list of passes: + +- `collapse-docs` is necessary because each line of a doc comment is given as a + separate doc attribute, and this will combine them into a single string with + line breaks between each attribute. +- `unindent-comments` is necessary because the convention for writing + documentation is to provide a space between the `///` or `//!` marker and the + text, and stripping that leading space will make the text easier to parse by + the Markdown parser. (In my experience it's less necessary now that we have a + Commonmark-compliant parser, since it doesn't have a problem with headers + that have a space before the `##` that marks the heading.) +- `strip-priv-imports` is necessary because rustdoc will handle *public* + imports by either inlining the item's documentation to the module or creating + a "Reexports" section with the import in it. The pass ensures that all of + these imports are actually relevant to documentation. +- `strip-hidden` and `strip-private` also remove items that are not relevant + for public documentation. + ## From clean to crate This is where the "second phase" in rustdoc begins. This phase primarily lives in the `html/` @@ -160,6 +189,9 @@ handing them off to the libtest test runner. One notable location in `test.rs` i `make_test`, which is where hand-written doctests get transformed into something that can be executed. +Some extra reading about `make_test` can be found +[here](https://quietmisdreavus.net/code/2018/02/23/how-the-doctests-get-made/). + ## Dotting i's and crossing t's So that's rustdoc's code in a nutshell, but there's more things in the repo that deal with it. Since From 7c2af89682e0811ac7be825de128b220d389750a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 15 Mar 2018 09:38:50 -0500 Subject: [PATCH 0155/1812] address review comments --- src/appendix-code-index.md | 1 + src/rustdoc.md | 17 +++++++++++------ 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/src/appendix-code-index.md b/src/appendix-code-index.md index c5be7e336..49fe08ee3 100644 --- a/src/appendix-code-index.md +++ b/src/appendix-code-index.md @@ -23,3 +23,4 @@ Item | Kind | Short description | Chapter | [The Rustc Driver]: rustc-driver.html [Type checking]: type-checking.html [The `ty` modules]: ty.html +[Rustdoc]: rustdoc.html diff --git a/src/rustdoc.md b/src/rustdoc.md index 2cacc80fd..bb4122e8d 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -87,7 +87,7 @@ The other major thing that happens in `clean/mod.rs` is the collection of doc co `#[doc=""]` attributes into a separate field of the Attributes struct, present on anything that gets hand-written documentation. This makes it easier to collect this documentation later in the process. -The primary output of this process is a clean::Crate with a tree of Items which describe the +The primary output of this process is a `clean::Crate` with a tree of Items which describe the publicly-documentable items in the target crate. ### Hot potato @@ -107,21 +107,26 @@ deprecate that][44136]. If you need finer-grain control over these passes, pleas Here is current (as of this writing) list of passes: -- `collapse-docs` is necessary because each line of a doc comment is given as a +- `propagate-doc-cfg` - propagates `#[doc(cfg(...))]` to child items. +- `collapse-docs` concatenates all document attributes into one document + attribute. This is necessary because each line of a doc comment is given as a separate doc attribute, and this will combine them into a single string with line breaks between each attribute. -- `unindent-comments` is necessary because the convention for writing +- `unindent-comments` removes excess indentation on comments in order for + markdown to like it. This is necessary because the convention for writing documentation is to provide a space between the `///` or `//!` marker and the text, and stripping that leading space will make the text easier to parse by the Markdown parser. (In my experience it's less necessary now that we have a Commonmark-compliant parser, since it doesn't have a problem with headers that have a space before the `##` that marks the heading.) -- `strip-priv-imports` is necessary because rustdoc will handle *public* +- `strip-priv-imports` strips all private import statements (`use`, `extern + crate`) from a crate. This is necessary because rustdoc will handle *public* imports by either inlining the item's documentation to the module or creating a "Reexports" section with the import in it. The pass ensures that all of these imports are actually relevant to documentation. -- `strip-hidden` and `strip-private` also remove items that are not relevant - for public documentation. +- `strip-hidden` and `strip-private` strip all `doc(hidden)` and private items + from the output. `strip-private` implies `strip-priv-imports`. Basically, the + goal is to remove items that are not relevant for public documentation. ## From clean to crate From 81071c68384c3c49499ac37de214e6317551a86d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 15 Mar 2018 12:46:59 -0500 Subject: [PATCH 0156/1812] Updated parenthetical --- src/rustdoc.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/rustdoc.md b/src/rustdoc.md index bb4122e8d..ae640d110 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -116,9 +116,9 @@ Here is current (as of this writing) list of passes: markdown to like it. This is necessary because the convention for writing documentation is to provide a space between the `///` or `//!` marker and the text, and stripping that leading space will make the text easier to parse by - the Markdown parser. (In my experience it's less necessary now that we have a - Commonmark-compliant parser, since it doesn't have a problem with headers - that have a space before the `##` that marks the heading.) + the Markdown parser. (In the past, the markdown parser used was not Commonmark- + compliant, which caused annoyances with extra whitespace but this seems to be + less of an issue today.) - `strip-priv-imports` strips all private import statements (`use`, `extern crate`) from a crate. This is necessary because rustdoc will handle *public* imports by either inlining the item's documentation to the module or creating From 52787a6ec4f1ae782b459d9c1b9c71a134f8d851 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 15 Mar 2018 14:26:09 -0400 Subject: [PATCH 0157/1812] add names to the trait lowering rules This allows cross-references from the code. --- src/traits-lowering-rules.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/src/traits-lowering-rules.md b/src/traits-lowering-rules.md index 46827dce5..8de20f1d8 100644 --- a/src/traits-lowering-rules.md +++ b/src/traits-lowering-rules.md @@ -20,6 +20,16 @@ the [notation given in this section](./traits-goals-and-clauses.html). We sometimes insert "macros" like `LowerWhereClause!` into these definitions; these macros reference other sections within this chapter. +## Rule names and cross-references + +Each of these lowering rules is given a name, documented with a +comment like so: + + // Rule Foo-Bar-Baz + +you can also search through the `librustc_traits` crate in rustc +to find the corresponding rules from the implementation. + ## Lowering where clauses When used in a goal position, where clauses can be mapped directly to @@ -76,6 +86,7 @@ relationships between different kinds of domain goals. The first such rule from the trait header creates the mapping between the `FromEnv` and `Implemented` predicates: + // Rule Implemented-From-Env forall { Implemented(Self: Trait) :- FromEnv(Self: Trait) } @@ -89,6 +100,8 @@ The next few clauses have to do with implied bounds (see also [RFC 2089]: https://rust-lang.github.io/rfcs/2089-implied-bounds.html + // Rule Implied-Bound-From-Trait + // // For each where clause WC: forall { FromEnv(WC) :- FromEnv(Self: Trait { WellFormed(Self: Trait) :- Implemented(Self: Trait) && WellFormed(WC) @@ -175,12 +190,16 @@ the rules by which `ProjectionEq` can succeed; these two clauses are discussed in detail in the [section on associated types](./traits-associated-types.html),, but reproduced here for reference: + // Rule ProjectionEq-Normalize + // // ProjectionEq can succeed by normalizing: forall { ProjectionEq(>::AssocType = U) :- Normalize(>::AssocType -> U) } + // Rule ProjectionEq-Skolemize + // // ProjectionEq can succeed by skolemizing, see "associated type" // chapter for more: forall { @@ -223,6 +242,7 @@ where WC Let `TraitRef` be the trait reference `A0: Trait`. Then we will create the following rules: + // Rule Implemented-From-Impl forall { Implemented(TraitRef) :- WC } @@ -245,6 +265,7 @@ where WC We produce the following rule: + // Rule Normalize-From-Impl forall { forall { Normalize(>::AssocType -> T) :- From 1131ff4bbaa95bdb18a105cf4b79967766b982ae Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 16 Mar 2018 11:45:09 -0500 Subject: [PATCH 0158/1812] Add incremental compilation debugging subchapter --- src/SUMMARY.md | 1 + src/incrcomp-debugging.md | 113 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 114 insertions(+) create mode 100644 src/incrcomp-debugging.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 3079c0b48..47775e29c 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -13,6 +13,7 @@ - [Rustdoc](./rustdoc.md) - [Queries: demand-driven compilation](./query.md) - [Incremental compilation](./incremental-compilation.md) + - [Debugging and Testing](./incrcomp-debugging.md) - [The parser](./the-parser.md) - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) diff --git a/src/incrcomp-debugging.md b/src/incrcomp-debugging.md new file mode 100644 index 000000000..92a8e10ea --- /dev/null +++ b/src/incrcomp-debugging.md @@ -0,0 +1,113 @@ +# Debugging and Testing Dependencies + +## Testing the dependency graph + +There are various ways to write tests against the dependency graph. +The simplest mechanisms are the `#[rustc_if_this_changed]` and +`#[rustc_then_this_would_need]` annotations. These are used in compile-fail +tests to test whether the expected set of paths exist in the dependency graph. +As an example, see `src/test/compile-fail/dep-graph-caller-callee.rs`. + +The idea is that you can annotate a test like: + +```rust +#[rustc_if_this_changed] +fn foo() { } + +#[rustc_then_this_would_need(TypeckTables)] //~ ERROR OK +fn bar() { foo(); } + +#[rustc_then_this_would_need(TypeckTables)] //~ ERROR no path +fn baz() { } +``` + +This will check whether there is a path in the dependency graph from `Hir(foo)` +to `TypeckTables(bar)`. An error is reported for each +`#[rustc_then_this_would_need]` annotation that indicates whether a path +exists. `//~ ERROR` annotations can then be used to test if a path is found (as +demonstrated above). + +## Debugging the dependency graph + +### Dumping the graph + +The compiler is also capable of dumping the dependency graph for your +debugging pleasure. To do so, pass the `-Z dump-dep-graph` flag. The +graph will be dumped to `dep_graph.{txt,dot}` in the current +directory. You can override the filename with the `RUST_DEP_GRAPH` +environment variable. + +Frequently, though, the full dep graph is quite overwhelming and not +particularly helpful. Therefore, the compiler also allows you to filter +the graph. You can filter in three ways: + +1. All edges originating in a particular set of nodes (usually a single node). +2. All edges reaching a particular set of nodes. +3. All edges that lie between given start and end nodes. + +To filter, use the `RUST_DEP_GRAPH_FILTER` environment variable, which should +look like one of the following: + +``` +source_filter // nodes originating from source_filter +-> target_filter // nodes that can reach target_filter +source_filter -> target_filter // nodes in between source_filter and target_filter +``` + +`source_filter` and `target_filter` are a `&`-separated list of strings. +A node is considered to match a filter if all of those strings appear in its +label. So, for example: + +``` +RUST_DEP_GRAPH_FILTER='-> TypeckTables' +``` + +would select the predecessors of all `TypeckTables` nodes. Usually though you +want the `TypeckTables` node for some particular fn, so you might write: + +``` +RUST_DEP_GRAPH_FILTER='-> TypeckTables & bar' +``` + +This will select only the predecessors of `TypeckTables` nodes for functions with +`bar` in their name. + +Perhaps you are finding that when you change `foo` you need to re-type-check `bar`, +but you don't think you should have to. In that case, you might do: + +``` +RUST_DEP_GRAPH_FILTER='Hir & foo -> TypeckTables & bar' +``` + +This will dump out all the nodes that lead from `Hir(foo)` to +`TypeckTables(bar)`, from which you can (hopefully) see the source +of the erroneous edge. + +### Tracking down incorrect edges + +Sometimes, after you dump the dependency graph, you will find some +path that should not exist, but you will not be quite sure how it came +to be. **When the compiler is built with debug assertions,** it can +help you track that down. Simply set the `RUST_FORBID_DEP_GRAPH_EDGE` +environment variable to a filter. Every edge created in the dep-graph +will be tested against that filter -- if it matches, a `bug!` is +reported, so you can easily see the backtrace (`RUST_BACKTRACE=1`). + +The syntax for these filters is the same as described in the previous +section. However, note that this filter is applied to every **edge** +and doesn't handle longer paths in the graph, unlike the previous +section. + +Example: + +You find that there is a path from the `Hir` of `foo` to the type +check of `bar` and you don't think there should be. You dump the +dep-graph as described in the previous section and open `dep-graph.txt` +to see something like: + + Hir(foo) -> Collect(bar) + Collect(bar) -> TypeckTables(bar) + +That first edge looks suspicious to you. So you set +`RUST_FORBID_DEP_GRAPH_EDGE` to `Hir&foo -> Collect&bar`, re-run, and +then observe the backtrace. Voila, bug fixed! From 28da7a02acc591c65834232f1a86e82d8be6c711 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 19 Mar 2018 10:50:43 -0400 Subject: [PATCH 0159/1812] describe how the lowering code works --- src/SUMMARY.md | 1 + src/traits-lowering-module.md | 66 +++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+) create mode 100644 src/traits-lowering-module.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 47775e29c..da84350ea 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -33,6 +33,7 @@ - [Canonical queries](./traits-canonical-queries.md) - [Canonicalization](./traits-canonicalization.md) - [Lowering rules](./traits-lowering-rules.md) + - [The lowering module in rustc](./traits-lowering-module.md) - [Well-formedness checking](./traits-wf.md) - [The SLG solver](./traits-slg.md) - [Bibliography](./traits-bibliography.md) diff --git a/src/traits-lowering-module.md b/src/traits-lowering-module.md new file mode 100644 index 000000000..c47b8fbe8 --- /dev/null +++ b/src/traits-lowering-module.md @@ -0,0 +1,66 @@ +# The lowering module in rustc + +The program clauses described in the +[lowering rules](./traits-lowering-rules.html) section are actually +created in the [`rustc_traits::lowering`][lowering] module. + +[lowering]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits/lowering.rs + +## The `program_clauses_for` query + +The main entry point is the `program_clauses_for` [query], which -- +given a def-id -- produces a set of Chalk program clauses. These +queries are tested using a +[dedicated unit-testing mechanism, described below](#unit-tests). The +query is invoked on a `DefId` that identifies something like a trait, +an impl, or an associated item definition. It then produces and +returns a vector of program clauses. + +[query]: ./query.html + + + +## Unit tests + +Unit tests are located in [`src/test/ui/chalkify`][chalkify]. A good +example test is [the `lower_impl` test][lower_impl]. At the time of +this writing, it looked like this: + +```rust +#![feature(rustc_attrs)] + +trait Foo { } + +#[rustc_dump_program_clauses] //~ ERROR Implemented(T: Foo) :- +impl Foo for T where T: Iterator { } + +fn main() { + println!("hello"); +} +``` + +The `#[rustc_dump_program_clauses]` annotation can be attached to +anything with a def-id. (It requires the `rustc_attrs` feature.) The +compiler will then invoke the `program_clauses_for` query on that +item, and emit compiler errors that dump the clauses produced. These +errors just exist for unit-testing, as we can then leverage the +standard [ui test] mechanisms to check them. In this case, there is a +`//~ ERROR Implemented` annotation which is intentionally minimal (it +need only be a prefix of the error), but [the stderr file] contains +the full details: + +``` +error: Implemented(T: Foo) :- ProjectionEq(::Item == i32), TypeOutlives(T \ +: 'static), Implemented(T: std::iter::Iterator), Implemented(T: std::marker::Sized). + --> $DIR/lower_impl.rs:15:1 + | +LL | #[rustc_dump_program_clauses] //~ ERROR Implemented(T: Foo) :- + | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +error: aborting due to previous error +``` + +[chalkify]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify +[lower_impl]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify/lower_impl.rs +[the stderr file]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify/lower_impl.stderr +[ui test]: https://rust-lang-nursery.github.io/rustc-guide/tests/adding.html#guide-to-the-ui-tests From df5401ca7a0375aacb28d2f2822984f693f147c3 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 19 Mar 2018 10:56:51 -0400 Subject: [PATCH 0160/1812] bump mdbook to 0.1.5 --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index a5d87a6bc..0a36ff1f9 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -19,5 +19,5 @@ function cargo_install() { fi } -cargo_install mdbook 0.1.1 +cargo_install mdbook 0.1.5 cargo_install mdbook-linkcheck 0.1.0 From d16bde7fb85d254950b33e53bcb8882ea4a788d5 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 16 Mar 2018 10:39:12 -0700 Subject: [PATCH 0161/1812] Add mdbook search. --- book.toml | 2 ++ ci/install.sh | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/book.toml b/book.toml index 3c4c537e8..f3a192c67 100644 --- a/book.toml +++ b/book.toml @@ -6,3 +6,5 @@ description = "A guide to developing rustc " [output.html] [output.linkcheck] + +[output.html.search] diff --git a/ci/install.sh b/ci/install.sh index 0a36ff1f9..975857a95 100644 --- a/ci/install.sh +++ b/ci/install.sh @@ -20,4 +20,4 @@ function cargo_install() { } cargo_install mdbook 0.1.5 -cargo_install mdbook-linkcheck 0.1.0 +cargo_install mdbook-linkcheck 0.1.2 From 6136199bf5ec210c9c1aa21910a32ceaeac95171 Mon Sep 17 00:00:00 2001 From: Dan Robertson Date: Sun, 25 Mar 2018 13:50:58 +0000 Subject: [PATCH 0162/1812] Minor grammar and syntax fixes Minor grammar and syntax fixes found while reading. --- src/trait-caching.md | 4 +++- src/traits-associated-types.md | 10 ++++++---- src/type-inference.md | 2 +- 3 files changed, 10 insertions(+), 6 deletions(-) diff --git a/src/trait-caching.md b/src/trait-caching.md index ee92814cd..4c728d521 100644 --- a/src/trait-caching.md +++ b/src/trait-caching.md @@ -54,7 +54,7 @@ use is done by the method `pick_candidate_cache` in `select.rs`. At the moment, we use a very simple, conservative rule: if there are any where-clauses in scope, then we use the local cache. We used to try and draw finer-grained distinctions, but that led to a serious of -annoying and weird bugs like #22019 and #18290. This simple rule seems +annoying and weird bugs like [#22019] and [#18290]. This simple rule seems to be pretty clearly safe and also still retains a very high hit rate (~95% when compiling rustc). @@ -63,3 +63,5 @@ general, is this section still accurate at all? [`ParamEnv`]: ./param_env.html [`tcx`]: ./ty.html +[#18290]: https://github.com/rust-lang/rust/issues/18290 +[#22019]: https://github.com/rust-lang/rust/issues/22019 diff --git a/src/traits-associated-types.md b/src/traits-associated-types.md index 6ac3fc512..c91dc255f 100644 --- a/src/traits-associated-types.md +++ b/src/traits-associated-types.md @@ -20,6 +20,8 @@ that syntax is expanded during ["type collection"](./type-checking.html) into the explicit form, though that is something we may want to change in the future.) +[intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item + In some cases, associated type projections can be **normalized** -- @@ -51,8 +53,8 @@ we saw above would be lowered to a program clause like so: forall { Normalize( as IntoIterator>::Item -> T) - } - + } + (An aside: since we do not permit quantification over traits, this is really more like a family of predicates, one for each associated type.) @@ -98,7 +100,7 @@ We now introduce the `ProjectionEq` predicate to bring those two cases together. The `ProjectionEq` predicate looks like so: ProjectionEq(::Item = U) - + and we will see that it can be proven *either* via normalization or skolemization. As part of lowering an associated type declaration from some trait, we create two program clauses for `ProjectionEq`: @@ -123,7 +125,7 @@ with unification. As described in the basically a procedure with a signature like this: Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution> - + In other words, we try to unify two things A and B. That procedure might just fail, in which case we get back `Err(NoSolution)`. This would happen, for example, if we tried to unify `u32` and `i32`. diff --git a/src/type-inference.md b/src/type-inference.md index 3795ea70e..c7a9c2b63 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -84,7 +84,7 @@ below in a separate section. The most basic operations you can perform in the type inferencer is **equality**, which forces two types `T` and `U` to be the same. The -recommended way to add an equality constraint is using the `at` +recommended way to add an equality constraint is to use the `at` method, roughly like so: ```rust From dbc65d25202298984c42b575d37e10f6669bc927 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Fri, 23 Feb 2018 21:07:36 +0000 Subject: [PATCH 0163/1812] Added EditorConfig file for `src`. --- .editorconfig | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 .editorconfig diff --git a/.editorconfig b/.editorconfig new file mode 100644 index 000000000..cb3312517 --- /dev/null +++ b/.editorconfig @@ -0,0 +1,9 @@ +root = true + +[src/*] +end_of_line = lf +insert_final_newline = true + +[ci/*.sh] +indent_style = space +indent_size = 2 From 61a3f536d1f0e6793d1d9a984a79ac28a4b736f1 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Fri, 23 Feb 2018 21:51:29 +0000 Subject: [PATCH 0164/1812] Added check for all source files to ensure they have no lines longer than 80 chars. --- .travis.yml | 2 ++ ci/check_line_lengths.sh | 19 +++++++++++++++++++ ci/install.sh | 1 + 3 files changed, 22 insertions(+) create mode 100755 ci/check_line_lengths.sh mode change 100644 => 100755 ci/install.sh diff --git a/.travis.yml b/.travis.yml index 5ca97ba79..da9c1ed0a 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,6 +1,8 @@ language: rust cache: - cargo +before_install: +- MAX_LINE_LENGTH=80 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true - bash ci/install.sh diff --git a/ci/check_line_lengths.sh b/ci/check_line_lengths.sh new file mode 100755 index 000000000..8001ea9a7 --- /dev/null +++ b/ci/check_line_lengths.sh @@ -0,0 +1,19 @@ +#!/bin/bash + +echo "Checking line lengths in all source files <= $MAX_LINE_LENGTH chars..." + +echo "Offending files and lines:" +(( success = 1 )) +for file in "$@" ; do + echo "$file" + (( line_no = 0 )) + while IFS="" read -r line || [[ -n "$line" ]] ; do + (( line_no++ )) + if (( "${#line}" > $MAX_LINE_LENGTH )) ; then + (( success = 0 )) + echo -e "\t$line_no : $line" + fi + done < "$file" +done + +(( $success )) && echo "No offending lines found." diff --git a/ci/install.sh b/ci/install.sh old mode 100644 new mode 100755 index 975857a95..ea90e853d --- a/ci/install.sh +++ b/ci/install.sh @@ -1,4 +1,5 @@ #!/bin/bash + set -ex function cargo_install() { From ba057b34ad6ab2cdaae5dd72488b150b8888bc4b Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sat, 24 Feb 2018 01:43:36 +0000 Subject: [PATCH 0165/1812] Ignore line check on certain types of lines or in certain blocks. --- ci/check_line_lengths.sh | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/ci/check_line_lengths.sh b/ci/check_line_lengths.sh index 8001ea9a7..27711806a 100755 --- a/ci/check_line_lengths.sh +++ b/ci/check_line_lengths.sh @@ -3,17 +3,23 @@ echo "Checking line lengths in all source files <= $MAX_LINE_LENGTH chars..." echo "Offending files and lines:" -(( success = 1 )) +(( bad_lines = 0 )) +(( inside_block = 0 )) for file in "$@" ; do echo "$file" (( line_no = 0 )) while IFS="" read -r line || [[ -n "$line" ]] ; do (( line_no++ )) - if (( "${#line}" > $MAX_LINE_LENGTH )) ; then - (( success = 0 )) + if [[ "$line" =~ ^'```' ]] ; then + (( inside_block = !$inside_block )) + continue + fi + if ! (( $inside_block )) && ! [[ "$line" =~ " | "|"://"|\[\^[^\ ]+\]: ]] && (( "${#line}" > $MAX_LINE_LENGTH )) ; then + (( bad_lines++ )) echo -e "\t$line_no : $line" fi done < "$file" done -(( $success )) && echo "No offending lines found." +echo "$bad_lines offending lines found." +(( $bad_lines == 0 )) From e6acd30581b57c6e95579ce48c912dd889ee9353 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sat, 24 Feb 2018 01:43:53 +0000 Subject: [PATCH 0166/1812] Hard-wrapped lines that are too long. --- ci/check_line_lengths.sh | 2 +- src/SUMMARY.md | 3 +- src/compiletest.md | 30 ++++++++-------- src/high-level-overview.md | 29 ++++++++-------- src/hir.md | 38 +++++++++++---------- src/how-to-build-and-run.md | 34 +++++++++++-------- src/incremental-compilation.md | 39 +++++++++++---------- src/query.md | 12 ++++--- src/tests/adding.md | 62 +++++++++++++++++++++------------- src/tests/intro.md | 39 +++++++++++---------- src/tests/running.md | 9 ++--- src/trait-hrtb.md | 8 +++-- src/trait-resolution.md | 28 ++++++++------- src/ty.md | 17 ++++++---- src/type-inference.md | 17 +++++----- 15 files changed, 206 insertions(+), 161 deletions(-) diff --git a/ci/check_line_lengths.sh b/ci/check_line_lengths.sh index 27711806a..b32906da6 100755 --- a/ci/check_line_lengths.sh +++ b/ci/check_line_lengths.sh @@ -14,7 +14,7 @@ for file in "$@" ; do (( inside_block = !$inside_block )) continue fi - if ! (( $inside_block )) && ! [[ "$line" =~ " | "|"://"|\[\^[^\ ]+\]: ]] && (( "${#line}" > $MAX_LINE_LENGTH )) ; then + if ! (( $inside_block )) && ! [[ "$line" =~ " | "|"-|-"|"://"|\[\^[^\ ]+\]: ]] && (( "${#line}" > $MAX_LINE_LENGTH )) ; then (( bad_lines++ )) echo -e "\t$line_no : $line" fi diff --git a/src/SUMMARY.md b/src/SUMMARY.md index da84350ea..3460d949d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -6,7 +6,8 @@ - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) - [Adding new tests](./tests/adding.md) - - [Using `compiletest` + commands to control test execution](./compiletest.md) + - [Using `compiletest` + commands to control test + execution](./compiletest.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver](./rustc-driver.md) diff --git a/src/compiletest.md b/src/compiletest.md index f07d3065a..0cfc6b39d 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -1,8 +1,10 @@ # `compiletest` ## Introduction -`compiletest` is the main test harness of the Rust test suite. It allows test authors to organize large numbers of tests (the -Rust compiler has many thousands), efficient test execution (parallel execution is supported), and allows the test author to -configure behavior and expected results of both individual and groups of tests. +`compiletest` is the main test harness of the Rust test suite. It allows +test authors to organize large numbers of tests (the Rust compiler has many +thousands), efficient test execution (parallel execution is supported), and +allows the test author to configure behavior and expected results of both +individual and groups of tests. `compiletest` tests may check test code for success, for failure or in some cases, even failure to compile. Tests are typically organized as a Rust source file with annotations in comments before and/or within the test code, which serve to @@ -12,17 +14,17 @@ testing framework, see [`this chapter`](./tests/intro.html) for additional backg The tests themselves are typically (but not always) organized into "suites"--for example, `run-pass`, a folder representing tests that should succeed, `run-fail`, a folder holding tests that should compile successfully, but return a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various -suites are defined in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs) in the `pub struct Config` declaration. And a very good +suites are defined in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs) in the `pub struct Config` declaration. And a very good introduction to the different suites of compiler tests along with details about them can be found in [`Adding new tests`](./tests/adding.html). ## Adding a new test file -Briefly, simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test). No registration of test files is necessary as +Briefly, simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test). No registration of test files is necessary as `compiletest` will scan the [src/test](https://github.com/rust-lang/rust/tree/master/src/test) subfolder recursively, and will execute any Rust source files it finds as tests. -See [`Adding new tests`](./tests/adding.html) for a complete guide on how to adding new tests. +See [`Adding new tests`](./tests/adding.html) for a complete guide on how to adding new tests. ## Header Commands Source file annotations which appear in comments near the top of the source file *before* any test code are known as header -commands. These commands can instruct `compiletest` to ignore this test, set expectations on whether it is expected to +commands. These commands can instruct `compiletest` to ignore this test, set expectations on whether it is expected to succeed at compiling, or what the test's return code is expected to be. Header commands (and their inline counterparts, Error Info commands) are described more fully [here](./tests/adding.html#header-commands-configuring-rustc). @@ -96,7 +98,7 @@ As a concrete example, here is the implementation for the `parse_failure_status( pub normalize_stderr: Vec<(String, String)>, + pub failure_status: i32, } - + impl TestProps { @@ -260,6 +261,7 @@ impl TestProps { run_pass: false, @@ -105,7 +107,7 @@ As a concrete example, here is the implementation for the `parse_failure_status( + failure_status: 101, } } - + @@ -383,6 +385,10 @@ impl TestProps { if let Some(rule) = config.parse_custom_normalization(ln, "normalize-stderr") { self.normalize_stderr.push(rule); @@ -115,12 +117,12 @@ As a concrete example, here is the implementation for the `parse_failure_status( + self.failure_status = code; + } }); - + for key in &["RUST_TEST_NOCAPTURE", "RUST_TEST_THREADS"] { @@ -488,6 +494,13 @@ impl Config { self.parse_name_directive(line, "pretty-compare-only") } - + + fn parse_failure_status(&self, line: &str) -> Option { + match self.parse_name_value_directive(line, "failure-status") { + Some(code) => code.trim().parse::().ok(), @@ -141,7 +143,7 @@ located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/r ```diff @@ -295,11 +295,14 @@ impl<'test> TestCx<'test> { } - + fn check_correct_failure_status(&self, proc_res: &ProcRes) { - // The value the rust runtime returns on failure - const RUST_ERR: i32 = 101; @@ -160,7 +162,7 @@ located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/r } @@ -320,7 +323,6 @@ impl<'test> TestCx<'test> { ); - + let proc_res = self.exec_compiled_test(); - if !proc_res.status.success() { @@ -172,7 +174,7 @@ located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/r ); - panic!(); } - } + } ``` Note the use of `self.props.failure_status` to access the header command property. In tests which do not specify the failure status header command, `self.props.failure_status` will evaluate to the default value of 101 at the time of this writing. diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 493656713..041136548 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -94,20 +94,21 @@ order to compile a Rust crate, these are the general steps that we take: 1. **Parsing input** - - this processes the `.rs` files and produces the AST ("abstract syntax tree") + - this processes the `.rs` files and produces the AST + ("abstract syntax tree") - the AST is defined in `syntax/ast.rs`. It is intended to match the lexical syntax of the Rust language quite closely. 2. **Name resolution, macro expansion, and configuration** - - once parsing is complete, we process the AST recursively, resolving paths - and expanding macros. This same process also processes `#[cfg]` nodes, and hence - may strip things out of the AST as well. + - once parsing is complete, we process the AST recursively, resolving + paths and expanding macros. This same process also processes `#[cfg]` + nodes, and hence may strip things out of the AST as well. 3. **Lowering to HIR** - Once name resolution completes, we convert the AST into the HIR, - or "high-level IR". The HIR is defined in `src/librustc/hir/`; that module also includes - the lowering code. - - The HIR is a lightly desugared variant of the AST. It is more processed than the - AST and more suitable for the analyses that follow. It is **not** required to match - the syntax of the Rust language. + or "high-level IR". The HIR is defined in `src/librustc/hir/`; + that module also includes the lowering code. + - The HIR is a lightly desugared variant of the AST. It is more processed + than the AST and more suitable for the analyses that follow. + It is **not** required to match the syntax of the Rust language. - As a simple example, in the **AST**, we preserve the parentheses that the user wrote, so `((1 + 2) + 3)` and `1 + 2 + 3` parse into distinct trees, even though they are equivalent. In the @@ -125,13 +126,13 @@ take: the types of expressions, the way to resolve methods, and so forth. - After type-checking, we can do other analyses, such as privacy checking. 4. **Lowering to MIR and post-processing** - - Once type-checking is done, we can lower the HIR into MIR ("middle IR"), which - is a **very** desugared version of Rust, well suited to the borrowck but also - certain high-level optimizations. + - Once type-checking is done, we can lower the HIR into MIR ("middle IR"), + which is a **very** desugared version of Rust, well suited to borrowck + but also to certain high-level optimizations. 5. **Translation to LLVM and LLVM optimizations** - From MIR, we can produce LLVM IR. - - LLVM then runs its various optimizations, which produces a number of `.o` files - (one for each "codegen unit"). + - LLVM then runs its various optimizations, which produces a number of + `.o` files (one for each "codegen unit"). 6. **Linking** - Finally, those `.o` files are linked together. diff --git a/src/hir.md b/src/hir.md index 41ed0ab20..f66468ffc 100644 --- a/src/hir.md +++ b/src/hir.md @@ -63,23 +63,25 @@ carry around references into the HIR, but rather to carry around *identifier numbers* (or just "ids"). Right now, you will find four sorts of identifiers in active use: -- `DefId` – primarily names "definitions" or top-level items. - - You can think of a `DefId` as shorthand for a very explicit and complete - path, like `std::collections::HashMap`. However, these paths are able to - name things that are not nameable in normal Rust (e.g. `impl`s), and they - also include extra information about the crate (such as its version number, - since two versions of the same crate can co-exist). - - A `DefId` really consists of two parts, a `CrateNum` (which identifies the - crate) and a `DefIndex` (which indexes into a list of items that is - maintained per crate). -- `HirId` – combines the index of a particular item with an offset within - that item. - - The key point of an `HirId` is that it is *relative* to some item (which is - named via a `DefId`). -- `BodyId` – an absolute identifier that refers to a specific body (definition - of a function or constant) in the crate. It is currently effectively a - "newtype'd" `NodeId`. -- `NodeId` – an absolute ID that identifies a single node in the HIR tree. +- `DefId`, which primarily names "definitions" or top-level items. + - You can think of a `DefId` as being shorthand for a very explicit + and complete path, like `std::collections::HashMap`. However, + these paths are able to name things that are not nameable in + normal Rust (e.g. impls), and they also include extra information + about the crate (such as its version number, as two versions of + the same crate can co-exist). + - A `DefId` really consists of two parts, a `CrateNum` (which + identifies the crate) and a `DefIndex` (which indixes into a list + of items that is maintained per crate). +- `HirId`, which combines the index of a particular item with an + offset within that item. + - the key point of a `HirId` is that it is *relative* to some item + (which is named via a `DefId`). +- `BodyId`, this is an absolute identifier that refers to a specific + body (definition of a function or constant) in the crate. It is currently + effectively a "newtype'd" `NodeId`. +- `NodeId`, which is an absolute id that identifies a single node in the HIR + tree. - While these are still in common use, **they are being slowly phased out**. - Since they are absolute within the crate, adding a new node anywhere in the tree causes the `NodeId`s of all subsequent code in the crate to change. @@ -119,5 +121,5 @@ of a function/closure or the definition of a constant. Bodies are associated with an **owner**, which is typically some kind of item (e.g. an `fn()` or `const`), but could also be a closure expression (e.g. `|x, y| x + y`). You can use the HIR map to find the body -associated with a given `DefId` (`maybe_body_owned_by()`) or to find +associated with a given def-id (`maybe_body_owned_by()`) or to find the owner of a body (`body_owner_def_id()`). diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 7b6088c7c..6e292934b 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -2,8 +2,9 @@ The compiler is built using a tool called `x.py`. You will need to have Python installed to run it. But before we get to that, if you're going to -be hacking on rustc, you'll want to tweak the configuration of the compiler. The default -configuration is oriented towards running the compiler as a user, not a developer. +be hacking on rustc, you'll want to tweak the configuration of the compiler. +The default configuration is oriented towards running the compiler as a user, +not a developer. ### Create a config.toml @@ -84,15 +85,16 @@ What this command will do is the following: - Using this stage 1 compiler, it will build the standard library. (this is what the `src/libstd`) means. -This is just a subset of the full rustc build. The **full** rustc build (what you -get if you just say `./x.py build`) has quite a few more steps: +This is just a subset of the full rustc build. The **full** rustc build +(what you get if you just say `./x.py build`) has quite a few more steps: -- Build stage1 rustc with stage0 compiler -- Build libstd with stage1 compiler (up to here is the same) -- Build rustc from `src` again, this time with the stage1 compiler (this part is new) - - The resulting compiler here is called the "stage2" compiler -- Build libstd with stage2 compiler -- Build librustdoc and a bunch of other things +- Build stage1 rustc with stage0 compiler. +- Build libstd with stage1 compiler (up to here is the same). +- Build rustc from `src` again, this time with the stage1 compiler + (this part is new). + - The resulting compiler here is called the "stage2" compiler. +- Build libstd with stage2 compiler. +- Build librustdoc and a bunch of other things. ### Creating a rustup toolchain @@ -126,12 +128,16 @@ LLVM version: 4.0 ### Other x.py commands -Here are a few other useful x.py commands. We'll cover some of them in detail in other sections: +Here are a few other useful x.py commands. We'll cover some of them in detail +in other sections: - Building things: - - `./x.py clean` – clean up the build directory (`rm -rf build` works too, but then you have to rebuild LLVM) - - `./x.py build --stage 1` – builds everything using the stage 1 compiler, not just up to libstd + - `./x.py clean` – clean up the build directory (`rm -rf build` works too, + but then you have to rebuild LLVM) + - `./x.py build --stage 1` – builds everything using the stage 1 compiler, + not just up to libstd - `./x.py build` – builds the stage2 compiler -- Running tests (see the [section on running tests](./tests/running.html) for more details): +- Running tests (see the [section on running tests](./tests/running.html) for + more details): - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd - `./x.py test --stage 1 src/test/run-pass` – runs the `run-pass` test suite diff --git a/src/incremental-compilation.md b/src/incremental-compilation.md index 6f5b48cca..a209207fc 100644 --- a/src/incremental-compilation.md +++ b/src/incremental-compilation.md @@ -2,8 +2,8 @@ The incremental compilation scheme is, in essence, a surprisingly simple extension to the overall query system. We'll start by describing -a slightly simplified variant of the real thing – the "basic algorithm" – and then describe -some possible improvements. +a slightly simplified variant of the real thing – the "basic algorithm" – +and then describe some possible improvements. ## The basic algorithm @@ -40,7 +40,7 @@ There are two key insights here: produced the same result as the previous time. **If it did,** we can still mark the query as green, and hence avoid re-executing dependent queries. - + ### The try-mark-green algorithm At the core of incremental compilation is an algorithm called @@ -66,13 +66,15 @@ Try-mark-green works as follows: - For each query R in `reads(Q)`, we recursively demand the color of R using try-mark-green. - Note: it is important that we visit each node in `reads(Q)` in same order - as they occurred in the original compilation. See [the section on the query DAG below](#dag). - - If **any** of the nodes in `reads(Q)` wind up colored **red**, then Q is dirty. - - We re-execute Q and compare the hash of its result to the hash of the result - from the previous compilation. + as they occurred in the original compilation. See [the section on the + query DAG below](#dag). + - If **any** of the nodes in `reads(Q)` wind up colored **red**, then Q is + dirty. + - We re-execute Q and compare the hash of its result to the hash of the + result from the previous compilation. - If the hash has not changed, we can mark Q as **green** and return. - - Otherwise, **all** of the nodes in `reads(Q)` must be **green**. In that case, - we can color Q as **green** and return. + - Otherwise, **all** of the nodes in `reads(Q)` must be **green**. In that + case, we can color Q as **green** and return. @@ -80,14 +82,14 @@ Try-mark-green works as follows: The query DAG code is stored in [`src/librustc/dep_graph`][dep_graph]. Construction of the DAG is done -by instrumenting the query execution. +by instrumenting the query execution. One key point is that the query DAG also tracks ordering; that is, for each query Q, we not only track the queries that Q reads, we track the **order** in which they were read. This allows try-mark-green to walk -those queries back in the same order. This is important because once a subquery comes back as red, -we can no longer be sure that Q will continue along the same path as before. -That is, imagine a query like this: +those queries back in the same order. This is important because once a +subquery comes back as red, we can no longer be sure that Q will continue +along the same path as before. That is, imagine a query like this: ```rust,ignore fn main_query(tcx) { @@ -105,9 +107,10 @@ query `main_query` executes will be `subquery2`, and `subquery3` will not be executed at all. But now imagine that in the **next** compilation, the input has -changed such that `subquery1` returns **false**. In this case, `subquery2` would never -execute. If try-mark-green were to visit `reads(main_query)` out of order, -however, it might visit `subquery2` before `subquery1`, and hence execute it. +changed such that `subquery1` returns **false**. In this case, `subquery2` +would never execute. If try-mark-green were to visit `reads(main_query)` out +of order, however, it might visit `subquery2` before `subquery1`, and hence +execute it. This can lead to ICEs and other problems in the compiler. [dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc/dep_graph @@ -124,8 +127,8 @@ we **also** save the results. This is why the incremental algorithm separates computing the **color** of a node, which often does not require its value, from -computing the **result** of a node. Computing the result is done via a simple algorithm -like so: +computing the **result** of a node. Computing the result is done via a simple +algorithm like so: - Check if a saved result for Q is available. If so, compute the color of Q. If Q is green, deserialize and return the saved result. diff --git a/src/query.md b/src/query.md index 33d2b3bac..500b9dec8 100644 --- a/src/query.md +++ b/src/query.md @@ -74,10 +74,12 @@ match queries::type_of::try_get(tcx, DUMMY_SP, self.did) { } ``` -So, if you get back an `Err` from `try_get`, then a cycle *did* occur. This means that -you must ensure that a compiler error message is reported. You can do that in two ways: +So, if you get back an `Err` from `try_get`, then a cycle *did* occur. This +means that you must ensure that a compiler error message is reported. You can +do that in two ways: -The simplest is to invoke `err.emit()`. This will emit the cycle error to the user. +The simplest is to invoke `err.emit()`. This will emit the cycle error to the +user. However, often cycles happen because of an illegal program, and you know at that point that an error either already has been reported or @@ -192,8 +194,8 @@ fn fubar<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx>, key: DefId) -> Fubar<'tcx> { .. } N.B. Most of the `rustc_*` crates only provide **local providers**. Almost all **extern providers** wind up going through the -[`rustc_metadata` crate][rustc_metadata], which loads the information from the crate -metadata. But in some cases there are crates that provide queries for +[`rustc_metadata` crate][rustc_metadata], which loads the information from the +crate metadata. But in some cases there are crates that provide queries for *both* local and external crates, in which case they define both a `provide` and a `provide_extern` function that `rustc_driver` can invoke. diff --git a/src/tests/adding.md b/src/tests/adding.md index 276189f59..f777a458c 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -12,8 +12,8 @@ structure: - They always begin with the [copyright notice](./conventions.html#copyright); - then they should have some kind of [comment explaining what the test is about](#explanatory_comment); -- next, they can have one or more [header commands](#header_commands), which are special - comments that the test interpreter knows how to interpret. +- next, they can have one or more [header commands](#header_commands), which + are special comments that the test interpreter knows how to interpret. - finally, they have the Rust source. This may have various [error annotations](#error_annotations) which indicate expected compilation errors or warnings. @@ -28,10 +28,12 @@ rough heuristics: - Some tests have specialized needs: - need to run gdb or lldb? use the `debuginfo` test suite - - need to inspect LLVM IR or MIR IR? use the `codegen` or `mir-opt` test suites + - need to inspect LLVM IR or MIR IR? use the `codegen` or `mir-opt` test + suites - need to run rustdoc? Prefer a `rustdoc` test - need to inspect the resulting binary in some way? Then use `run-make` -- For most other things, [a `ui` (or `ui-fulldeps`) test](#ui) is to be preferred: +- For most other things, [a `ui` (or `ui-fulldeps`) test](#ui) is to be + preferred: - `ui` tests subsume both run-pass, compile-fail, and parse-fail tests - in the case of warnings or errors, `ui` tests capture the full output, which makes it easier to review but also helps prevent "hidden" regressions @@ -59,8 +61,8 @@ When writing a new feature, **create a subdirectory to store your tests**. For example, if you are implementing RFC 1234 ("Widgets"), then it might make sense to put the tests in directories like: -- `src/test/ui/rfc1234-widgets/` -- `src/test/run-pass/rfc1234-widgets/` +- `src/test/ui/rfc1234-widgets/` +- `src/test/run-pass/rfc1234-widgets/` - etc In other cases, there may already be a suitable directory. (The proper @@ -118,16 +120,22 @@ fn main() { These are used to ignore the test in some situations, which means the test won't be compiled or run. -* `ignore-X` where `X` is a target detail or stage will ignore the test accordingly (see below) -* `ignore-pretty` will not compile the pretty-printed test (this is done to test the pretty-printer, but might not always work) +* `ignore-X` where `X` is a target detail or stage will ignore the + test accordingly (see below) +* `ignore-pretty` will not compile the pretty-printed test (this is + done to test the pretty-printer, but might not always work) * `ignore-test` always ignores the test -* `ignore-lldb` and `ignore-gdb` will skip a debuginfo test on that debugger. +* `ignore-lldb` and `ignore-gdb` will skip a debuginfo test on that + debugger. Some examples of `X` in `ignore-X`: -* Architecture: `aarch64`, `arm`, `asmjs`, `mips`, `wasm32`, `x86_64`, `x86`, ... -* OS: `android`, `emscripten`, `freebsd`, `ios`, `linux`, `macos`, `windows`, ... -* Environment (fourth word of the target triple): `gnu`, `msvc`, `musl`. +* Architecture: `aarch64`, `arm`, `asmjs`, `mips`, `wasm32`, `x86_64`, + `x86`, ... +* OS: `android`, `emscripten`, `freebsd`, `ios`, `linux`, `macos`, + `windows`, ... +* Environment (fourth word of the target triple): `gnu`, `msvc`, + `musl`. * Pointer width: `32bit`, `64bit`. * Stage: `stage0`, `stage1`, `stage2`. @@ -140,17 +148,20 @@ source. * `min-{gdb,lldb}-version` * `min-llvm-version` -* `must-compile-successfully` for UI tests, indicates that the test is supposed - to compile, as opposed to the default where the test is supposed to error out. +* `must-compile-successfully` for UI tests, indicates that the test is + supposed to compile, as opposed to the default where the test is + supposed to error out. * `compile-flags` passes extra command-line args to the compiler, e.g. `compile-flags -g` which forces debuginfo to be enabled. -* `should-fail` indicates that the test should fail; used for "meta testing", - where we test the compiletest program itself to check that it will generate - errors in appropriate scenarios. This header is ignored for pretty-printer tests. -* `gate-test-X` where `X` is a feature marks the test as "gate test" for feature X. - Such tests are supposed to ensure that the compiler errors when usage of a gated - feature is attempted without the proper `#![feature(X)]` tag. - Each unstable lang feature is required to have a gate test. +* `should-fail` indicates that the test should fail; used for "meta + testing", where we test the compiletest program itself to check that + it will generate errors in appropriate scenarios. This header is + ignored for pretty-printer tests. +* `gate-test-X` where `X` is a feature marks the test as "gate test" + for feature X. Such tests are supposed to ensure that the compiler + errors when usage of a gated feature is attempted without the proper + `#![feature(X)]` tag. Each unstable lang feature is required to + have a gate test. [`header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs @@ -245,8 +256,10 @@ can also make UI tests where compilation is expected to succeed, and you can even run the resulting program. Just add one of the following [header commands](#header_commands): -- `// must-compile-successfully` -- compilation should succeed but do not run the resulting binary -- `// run-pass` -- compilation should succeed and we should run the resulting binary +- `// must-compile-successfully` -- compilation should succeed but do + not run the resulting binary +- `// run-pass` -- compilation should succeed and we should run the + resulting binary ### Editing and updating the reference files @@ -293,7 +306,8 @@ The corresponding reference file will use the normalized output to test both ... ``` -Please see [`ui/transmute/main.rs`][mrs] and [`main.stderr`][] for a concrete usage example. +Please see [`ui/transmute/main.rs`][mrs] and [`main.stderr`][] for a +concrete usage example. [mrs]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.rs [`main.stderr`]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.stderr diff --git a/src/tests/intro.md b/src/tests/intro.md index eb7294c83..e8cf34aff 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -1,12 +1,12 @@ # The compiler testing framework -The Rust project runs a wide variety of different tests, orchestrated by the -build system (`x.py test`). The main test harness for testing the compiler -itself is a tool called compiletest (sources in the -[`src/tools/compiletest`]). This section gives a brief overview of how the -testing framework is setup, and then gets into some of the details on [how to -run tests](./tests/running.html#ui) as well as [how to add new -tests](./tests/adding.html). +The Rust project runs a wide variety of different tests, orchestrated +by the build system (`x.py test`). The main test harness for testing +the compiler itself is a tool called compiletest (sources in the +[`src/tools/compiletest`]). This section gives a brief overview of how +the testing framework is setup, and then gets into some of the details +on [how to run tests](./tests/running.html#ui) as well as +[how to add new tests](./tests/adding.html). [`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest @@ -24,11 +24,13 @@ Here is a brief summary of the test suites as of this writing and what they mean. In some cases, the test suites are linked to parts of the manual that give more details. -- [`ui`](./tests/adding.html#ui) -- tests that check the exact stdout/stderr from compilation - and/or running the test -- `run-pass` -- tests that are expected to compile and execute successfully (no panics) +- [`ui`](./tests/adding.html#ui) -- tests that check the exact + stdout/stderr from compilation and/or running the test +- `run-pass` -- tests that are expected to compile and execute + successfully (no panics) - `run-pass-valgrind` -- tests that ought to run with valgrind -- `run-fail` -- tests that are expected to compile but then panic during execution +- `run-fail` -- tests that are expected to compile but then panic + during execution - `compile-fail` -- tests that are expected to fail compilation. - `parse-fail` -- tests that are expected to fail to parse - `pretty` -- tests targeting the Rust "pretty printer", which @@ -44,19 +46,20 @@ that give more details. results from previous compilations. - `run-make` -- tests that basically just execute a `Makefile`; the ultimate in flexibility but quite annoying to write. -- `rustdoc` -- tests for rustdoc, making sure that the generated files contain - the expected documentation. -- `*-fulldeps` -- same as above, but indicates that the test depends on things other - than `libstd` (and hence those things must be built) +- `rustdoc` -- tests for rustdoc, making sure that the generated files + contain the expected documentation. +- `*-fulldeps` -- same as above, but indicates that the test depends + on things other than `libstd` (and hence those things must be built) ## Other Tests The Rust build system handles running tests for various other things, including: -- **Tidy** -- This is a custom tool used for validating source code style and - formatting conventions, such as rejecting long lines. There is more - information in the [section on coding conventions](./conventions.html#formatting). +- **Tidy** -- This is a custom tool used for validating source code + style and formatting conventions, such as rejecting long lines. + There is more information in the + [section on coding conventions](./conventions.html#formatting). Example: `./x.py test src/tools/tidy` diff --git a/src/tests/running.md b/src/tests/running.md index 98d590671..6bac0121a 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -24,10 +24,11 @@ generally working correctly would be the following: ./x.py test --stage 1 src/test/{ui,compile-fail,run-pass} ``` -This will run the `ui`, `compile-fail`, and `run-pass` test suites, and -only with the stage 1 build. Of course, the choice of test suites is somewhat -arbitrary, and may not suit the task you are doing. For example, if you are hacking -on debuginfo, you may be better off with the debuginfo test suite: +This will run the `ui`, `compile-fail`, and `run-pass` test suites, +and only with the stage 1 build. Of course, the choice of test suites +is somewhat arbitrary, and may not suit the task you are doing. For +example, if you are hacking on debuginfo, you may be better off with +the debuginfo test suite: ```bash ./x.py test --stage 1 src/test/debuginfo diff --git a/src/trait-hrtb.md b/src/trait-hrtb.md index 8c3a6f4e9..d677db2c5 100644 --- a/src/trait-hrtb.md +++ b/src/trait-hrtb.md @@ -32,7 +32,7 @@ impl<'a> Foo<&'a isize> for AnyInt { } And the question is, does `AnyInt : for<'a> Foo<&'a isize>`? We want the answer to be yes. The algorithm for figuring it out is closely related -to the subtyping for higher-ranked types (which is described in [here][hrsubtype] +to the subtyping for higher-ranked types (which is described [here][hrsubtype] and also in a [paper by SPJ]. If you wish to understand higher-ranked subtyping, we recommend you read the paper). There are a few parts: @@ -83,7 +83,8 @@ skolemized to `'0` and the impl trait reference is instantiated to like `'static == '0`. This means that the taint set for `'0` is `{'0, 'static}`, which fails the leak check. -**TODO**: This is because `'static` is not a region variable but is in the taint set, right? +**TODO**: This is because `'static` is not a region variable but is in the +taint set, right? ## Higher-ranked trait obligations @@ -122,4 +123,5 @@ from. (This is done in `higher_ranked::plug_leaks`). We know that the leak check passed, so this taint set consists solely of the skolemized region itself plus various intermediate region variables. We then walk the trait-reference and convert every region in that taint set back to -a late-bound region, so in this case we'd wind up with `Baz: for<'a> Bar<&'a isize>`. +a late-bound region, so in this case we'd wind up with +`Baz: for<'a> Bar<&'a isize>`. diff --git a/src/trait-resolution.md b/src/trait-resolution.md index d6edcf68a..7494d969a 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -58,20 +58,20 @@ will then be generated in the output binary. Trait resolution consists of three major parts: -- **Selection** is deciding how to resolve a specific obligation. For +- **Selection**: Deciding how to resolve a specific obligation. For example, selection might decide that a specific obligation can be - resolved by employing an impl which matches the `Self` type, or by - using a parameter bound (e.g. `T: Trait`). In the case of an impl, selecting one + resolved by employing an impl which matches the `Self` type, or by using a + parameter bound (e.g. `T: Trait`). In the case of an impl, selecting one obligation can create *nested obligations* because of where clauses on the impl itself. It may also require evaluating those nested obligations to resolve ambiguities. -- **Fulfillment** is keeping track of which obligations - are completely fulfilled. Basically, it is a worklist of obligations +- **Fulfillment**: The fulfillment code is what tracks that obligations + are completely fulfilled. Basically it is a worklist of obligations to be selected: once selection is successful, the obligation is removed from the worklist and any nested obligations are enqueued. -- **Coherence** checks are intended to ensure that there +- **Coherence**: The coherence checks are intended to ensure that there are never overlapping impls, where two impls could be used with equal precedence. @@ -174,8 +174,12 @@ select this impl, which will cause the type of `$Y` to be unified to `usize`. (Note that while assembling candidates, we do the initial unifications in a transaction, so that they don't affect one another.) -**TODO**: The example says we can "select" the impl, but this section is talking specifically about candidate assembly. Does this mean we can sometimes skip confirmation? Or is this poor wording? -**TODO**: Is the unification of `$Y` part of trait resolution or type inference? Or is this not the same type of "inference variable" as in type inference? +**TODO**: The example says we can "select" the impl, but this section is +talking specifically about candidate assembly. Does this mean we can sometimes +skip confirmation? Or is this poor wording? +**TODO**: Is the unification of `$Y` part of trait resolution or type +inference? Or is this not the same type of "inference variable" as in type +inference? #### Winnowing: Resolving ambiguities @@ -282,10 +286,10 @@ to a particular impl. One interesting twist has to do with nested obligations. In general, in trans, we only need to do a "shallow" selection for an obligation. That is, we wish to identify which impl applies, but we do not (yet) need to decide how to select -any nested obligations. Nonetheless, we *do* currently do a complete -resolution, and that is because it can sometimes inform the results of type -inference. That is, we do not have the full substitutions for the type -variables of the impl available to us, so we must run trait selection to figure +any nested obligations. Nonetheless, we *do* currently do a complete resolution, +and that is because it can sometimes inform the results of type inference. +That is, we do not have the full substitutions in terms of the type variables +of the impl available to us, so we must run trait selection to figure everything out. **TODO**: is this still talking about trans? diff --git a/src/ty.md b/src/ty.md index 26b8c1ca8..1fd86a6bd 100644 --- a/src/ty.md +++ b/src/ty.md @@ -56,8 +56,8 @@ fn not_in_inference<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) { } ``` -In contrast, if we want to code that can be usable during type inference, then you -need to declare a distinct `'gcx` and `'tcx` lifetime parameter: +In contrast, if we want to code that can be usable during type inference, then +you need to declare a distinct `'gcx` and `'tcx` lifetime parameter: ```rust fn maybe_in_inference<'a, 'gcx, 'tcx>(tcx: TyCtxt<'a, 'gcx, 'tcx>, def_id: DefId) { @@ -141,19 +141,22 @@ In addition to types, there are a number of other arena-allocated data structures that you can allocate, and which are found in this module. Here are a few examples: -- `Substs`, allocated with `mk_substs` – this will intern a slice of types, often used to - specify the values to be substituted for generics (e.g. `HashMap` - would be represented as a slice `&'tcx [tcx.types.i32, tcx.types.u32]`). +- `Substs`, allocated with `mk_substs` – this will intern a slice of types, + often used to specify the values to be substituted for generics + (e.g. `HashMap` would be represented as a slice + `&'tcx [tcx.types.i32, tcx.types.u32]`). - `TraitRef`, typically passed by value – a **trait reference** consists of a reference to a trait along with its various type parameters (including `Self`), like `i32: Display` (here, the def-id would reference the `Display` trait, and the substs would contain `i32`). -- `Predicate` defines something the trait system has to prove (see `traits` module). +- `Predicate` defines something the trait system has to prove (see `traits` + module). ### Import conventions -Although there is no hard and fast rule, the `ty` module tends to be used like so: +Although there is no hard and fast rule, the `ty` module tends to be used like +so: ```rust use ty::{self, Ty, TyCtxt}; diff --git a/src/type-inference.md b/src/type-inference.md index c7a9c2b63..45f9df18a 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -59,13 +59,14 @@ inference works, or perhaps this blog post on [Unification in the Chalk project]: http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/ -All said, the inference context stores four kinds of inference variables as of -writing: +All told, the inference context stores four kinds of inference variables as of +this writing: - Type variables, which come in three varieties: - - General type variables (the most common). These can be unified with any type. - - Integral type variables, which can only be unified with an integral type, and - arise from an integer literal expression like `22`. + - General type variables (the most common). These can be unified with any + type. + - Integral type variables, which can only be unified with an integral type, + and arise from an integer literal expression like `22`. - Float type variables, which can only be unified with a float type, and arise from a float literal expression like `22.0`. - Region variables, which represent lifetimes, and arise all over the place. @@ -177,7 +178,7 @@ form of an "outlives" constraint: 'a: 'b -Actually, the code tends to view them as a subregion relation, but it's the same +Actually the code tends to view them as a subregion relation, but it's the same idea: 'b <= 'a @@ -185,8 +186,8 @@ idea: (There are various other kinds of constriants, such as "verifys"; see the `region_constraints` module for details.) -There is one case where we do some amount of eager unification. If you have an equality constraint -between two regions +There is one case where we do some amount of eager unification. If you have an +equality constraint between two regions 'a = 'b From aeef4cd9b33f5a948a3022266bee601923f93470 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 20 Mar 2018 09:48:17 -0400 Subject: [PATCH 0167/1812] make the script give more useful feedback --- ci/check_line_lengths.sh | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/ci/check_line_lengths.sh b/ci/check_line_lengths.sh index b32906da6..dc48091c8 100755 --- a/ci/check_line_lengths.sh +++ b/ci/check_line_lengths.sh @@ -1,5 +1,21 @@ #!/bin/bash +if [ "$1" == "--help" ]; then + echo 'Usage:' + echo ' MAX_LINE_LENGTH=80' "$0" 'src/**/*.md' + exit 1 +fi + +if [ "$MAX_LINE_LENGTH" == "" ]; then + echo '`MAX_LINE_LENGTH` environment variable not set. Try --help.' + exit 1 +fi + +if [ "$1" == "" ]; then + echo 'No files provided.' + exit 1 +fi + echo "Checking line lengths in all source files <= $MAX_LINE_LENGTH chars..." echo "Offending files and lines:" From 193a2bf42e1b872db09fd6d4f6c01c5b0195116c Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 22 Mar 2018 02:05:28 +0000 Subject: [PATCH 0168/1812] Travis CI script now sets `globstar` shell option. --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index da9c1ed0a..45ba4a890 100644 --- a/.travis.yml +++ b/.travis.yml @@ -2,6 +2,7 @@ language: rust cache: - cargo before_install: +- shopt -s globstar - MAX_LINE_LENGTH=80 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true From cd053f3cb405d6127833fc097d1a25cb54b85f2a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 20:56:05 -0500 Subject: [PATCH 0169/1812] Fix long lines in glossary --- src/appendix-glossary.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/appendix-glossary.md b/src/appendix-glossary.md index 8a3df24e8..1d82686ba 100644 --- a/src/appendix-glossary.md +++ b/src/appendix-glossary.md @@ -1,6 +1,8 @@ # Appendix C: Glossary -The compiler uses a number of...idiosyncratic abbreviations and things. This glossary attempts to list them and give you a few pointers for understanding them better. +The compiler uses a number of...idiosyncratic abbreviations and things. This +glossary attempts to list them and give you a few pointers for understanding +them better. Term | Meaning ------------------------|-------- From 8615d9e9b0f1997af4398fa6798c180886b18b60 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 20:57:17 -0500 Subject: [PATCH 0170/1812] Fix long lines in stupid stats appendix --- src/appendix-stupid-stats.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md index 20d5aaf9b..8e50b2c31 100644 --- a/src/appendix-stupid-stats.md +++ b/src/appendix-stupid-stats.md @@ -73,8 +73,8 @@ and a bunch of other crates with the 'librustc_' prefix. Next is translation, this translates the AST (and all those side tables) into LLVM IR (intermediate representation). We do this by calling into the LLVM -libraries, rather than actually writing IR directly to a file. The code for this is in -[librustc_trans](https://github.com/rust-lang/rust/tree/master/src/librustc_trans). +libraries, rather than actually writing IR directly to a file. The code for +this is in [librustc_trans](https://github.com/rust-lang/rust/tree/master/src/librustc_trans). The next phase is running the LLVM backend. This runs LLVM's optimisation passes on the generated IR and then generates machine code. The result is object files. @@ -117,8 +117,8 @@ I'll summarise the methods here. `early_callback` and `late_callback` let you call arbitrary code at different points - early is after command line arguments have been parsed, but before anything is done with them; late is pretty much the last thing before -compilation starts, i.e., after all processing of command line arguments, etc. is -done. Currently, you get to choose whether compilation stops or continues at +compilation starts, i.e., after all processing of command line arguments, etc. +is done. Currently, you get to choose whether compilation stops or continues at each point, but you don't get to change anything the driver has done. You can record some info for later, or perform other actions of your own. @@ -402,4 +402,4 @@ analysis, rather than doing its own analysis). Other parts of the compiler internally (I already changed save-analysis to use `CompilerController`). I've been experimenting with a prototype rustfmt which also uses these APIs. -[stupid-stats]: https://github.com/nrc/stupid-stats \ No newline at end of file +[stupid-stats]: https://github.com/nrc/stupid-stats From 94757096adefa565f96a9f8c02387ede917031c3 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 21:01:59 -0500 Subject: [PATCH 0171/1812] Fix long lines in compiletest --- src/compiletest.md | 175 +++++++++++++++++++++++++++++---------------- 1 file changed, 114 insertions(+), 61 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index 0cfc6b39d..011304d45 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -1,42 +1,66 @@ # `compiletest` + ## Introduction + `compiletest` is the main test harness of the Rust test suite. It allows test authors to organize large numbers of tests (the Rust compiler has many thousands), efficient test execution (parallel execution is supported), and allows the test author to configure behavior and expected results of both individual and groups of tests. -`compiletest` tests may check test code for success, for failure or in some cases, even failure to compile. Tests are -typically organized as a Rust source file with annotations in comments before and/or within the test code, which serve to -direct `compiletest` on if or how to run the test, what behavior to expect, and more. If you are unfamiliar with the compiler -testing framework, see [`this chapter`](./tests/intro.html) for additional background. - -The tests themselves are typically (but not always) organized into "suites"--for example, `run-pass`, a folder -representing tests that should succeed, `run-fail`, a folder holding tests that should compile successfully, but return -a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various -suites are defined in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs) in the `pub struct Config` declaration. And a very good -introduction to the different suites of compiler tests along with details about them can be found in [`Adding new tests`](./tests/adding.html). +`compiletest` tests may check test code for success, for failure or in some +cases, even failure to compile. Tests are typically organized as a Rust source +file with annotations in comments before and/or within the test code, which +serve to direct `compiletest` on if or how to run the test, what behavior to +expect, and more. If you are unfamiliar with the compiler testing framework, +see [`this chapter`](./tests/intro.html) for additional background. + +The tests themselves are typically (but not always) organized into +"suites"--for example, `run-pass`, a folder representing tests that should +succeed, `run-fail`, a folder holding tests that should compile successfully, +but return a failure (non-zero status), `compile-fail`, a folder holding tests +that should fail to compile, and many more. The various suites are defined in +[src/tools/compiletest/src/common.rs][common] in the `pub struct Config` +declaration. And a very good introduction to the different suites of compiler +tests along with details about them can be found in [`Adding new +tests`](./tests/adding.html). ## Adding a new test file -Briefly, simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test). No registration of test files is necessary as -`compiletest` will scan the [src/test](https://github.com/rust-lang/rust/tree/master/src/test) subfolder recursively, and will execute any Rust source files it finds as tests. -See [`Adding new tests`](./tests/adding.html) for a complete guide on how to adding new tests. + +Briefly, simply create your new test in the appropriate location under +[src/test][test]. No registration of test files is necessary as `compiletest` +will scan the [src/test][test] subfolder recursively, and will execute any Rust +source files it finds as tests. See [`Adding new tests`](./tests/adding.html) +for a complete guide on how to adding new tests. ## Header Commands -Source file annotations which appear in comments near the top of the source file *before* any test code are known as header -commands. These commands can instruct `compiletest` to ignore this test, set expectations on whether it is expected to -succeed at compiling, or what the test's return code is expected to be. Header commands (and their inline counterparts, -Error Info commands) are described more fully [here](./tests/adding.html#header-commands-configuring-rustc). + +Source file annotations which appear in comments near the top of the source +file *before* any test code are known as header commands. These commands can +instruct `compiletest` to ignore this test, set expectations on whether it is +expected to succeed at compiling, or what the test's return code is expected to +be. Header commands (and their inline counterparts, Error Info commands) are +described more fully +[here](./tests/adding.html#header-commands-configuring-rustc). ### Adding a new header command -Header commands are defined in the `TestProps` struct in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs). At a high level, there are dozens of test properties defined here, all set to default values in the `TestProp` struct's `impl` block. Any test can override this -default value by specifying the property in question as header command as a comment (`//`) in the test source file, before any source code. + +Header commands are defined in the `TestProps` struct in +[src/tools/compiletest/src/header.rs][header]. At a high level, there are +dozens of test properties defined here, all set to default values in the +`TestProp` struct's `impl` block. Any test can override this default value by +specifying the property in question as header command as a comment (`//`) in +the test source file, before any source code. #### Using a header command -Here is an example, specifying the `must-compile-successfully` header command, which takes no arguments, followed by the -`failure-status` header command, which takes a single argument (which, in this case is a value of 1). `failure-status` is -instructing `compiletest` to expect a failure status of 1 (rather than the current Rust default of 101 at the time of this -writing). The header command and the argument list (if present) are typically separated by a colon: + +Here is an example, specifying the `must-compile-successfully` header command, +which takes no arguments, followed by the `failure-status` header command, +which takes a single argument (which, in this case is a value of 1). +`failure-status` is instructing `compiletest` to expect a failure status of 1 +(rather than the current Rust default of 101 at the time of this writing). The +header command and the argument list (if present) are typically separated by a +colon: ``` // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at @@ -61,36 +85,51 @@ fn main() -> Result<(), Box> { ``` #### Adding a new header command property -One would add a new header command if there is a need to define some test property or behavior on an individual, test-by-test -basis. A header command property serves as the header command's backing store (holds the command's current value) at -runtime. + +One would add a new header command if there is a need to define some test +property or behavior on an individual, test-by-test basis. A header command +property serves as the header command's backing store (holds the command's +current value) at runtime. To add a new header command property: - 1. Look for the `pub struct TestProps` declaration in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs) and add -the new public property to the end of the declaration. - 2. Look for the `impl TestProps` implementation block immediately following the struct declaration and initialize the new -property to its default value. + 1. Look for the `pub struct TestProps` declaration in + [src/tools/compiletest/src/header.rs][header] and add the new public + property to the end of the declaration. + 2. Look for the `impl TestProps` implementation block immediately following + the struct declaration and initialize the new property to its default + value. #### Adding a new header command parser -When `compiletest` encounters a test file, it parses the file a line at a time by calling every parser defined in the -`Config` struct's implementation block, also in [src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs) (note the `Config` struct's declaration -block is found in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs). `TestProps`'s `load_from()` method will try passing the current -line of text to each parser, which, in turn typically checks to see if the line begins with a particular commented (`//`) -header command such as `// must-compile-successfully` or `// failure-status`. Whitespace after the comment marker is -optional. - -Parsers will override a given header command property's default value merely by being specified in the test file as a header -command or by having a parameter value specified in the test file, depending on the header command. - -Parsers defined in `impl Config` are typically named `parse_` (note kebab-case `` transformed -to snake-case ``). `impl Config` also defines several 'low-level' parsers which make it simple to parse -common patterns like simple presence or not (`parse_name_directive()`), header-command:parameter(s) -(`parse_name_value_directive()`), optional parsing only if a particular `cfg` attribute is defined (`has_cfg_prefix()`) and -many more. The low-level parsers are found near the end of the `impl Config` block; be sure to look through them and their -associated parsers immediately above to see how they are used to avoid writing additional parsing code unneccessarily. - -As a concrete example, here is the implementation for the `parse_failure_status()` parser, in -[src/tools/compiletest/src/header.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs): + +When `compiletest` encounters a test file, it parses the file a line at a time +by calling every parser defined in the `Config` struct's implementation block, +also in [src/tools/compiletest/src/header.rs][header] (note the `Config` +struct's declaration block is found in +[src/tools/compiletest/src/common.rs][common]. `TestProps`'s `load_from()` +method will try passing the current line of text to each parser, which, in turn +typically checks to see if the line begins with a particular commented (`//`) +header command such as `// must-compile-successfully` or `// failure-status`. +Whitespace after the comment marker is optional. + +Parsers will override a given header command property's default value merely by +being specified in the test file as a header command or by having a parameter +value specified in the test file, depending on the header command. + +Parsers defined in `impl Config` are typically named `parse_` +(note kebab-case `` transformed to snake-case +``). `impl Config` also defines several 'low-level' parsers +which make it simple to parse common patterns like simple presence or not +(`parse_name_directive()`), header-command:parameter(s) +(`parse_name_value_directive()`), optional parsing only if a particular `cfg` +attribute is defined (`has_cfg_prefix()`) and many more. The low-level parsers +are found near the end of the `impl Config` block; be sure to look through them +and their associated parsers immediately above to see how they are used to +avoid writing additional parsing code unneccessarily. + +As a concrete example, here is the implementation for the +`parse_failure_status()` parser, in +[src/tools/compiletest/src/header.rs][header]: + ```diff @@ -232,6 +232,7 @@ pub struct TestProps { // customized normalization rules @@ -132,14 +171,21 @@ As a concrete example, here is the implementation for the `parse_failure_status( ``` ## Implementing the behavior change -When a test invokes a particular header command, it is expected that some behavior will change as a result. What behavior, -obviously, will depend on the purpose of the header command. In the case of `failure-status`, the behavior that changes -is that `compiletest` expects the failure code defined by the header command invoked in the test, rather than the default -value. - -Although specific to `failure-status` (as every header command will have a different implementation in order to invoke -behavior change) perhaps it is helpful to see the behavior change implementation of one case, simply as an example. To implement `failure-status`, the `check_correct_failure_status()` function found in the `TestCx` implementation block, -located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs), was modified as per below: + +When a test invokes a particular header command, it is expected that some +behavior will change as a result. What behavior, obviously, will depend on the +purpose of the header command. In the case of `failure-status`, the behavior +that changes is that `compiletest` expects the failure code defined by the +header command invoked in the test, rather than the default value. + +Although specific to `failure-status` (as every header command will have a +different implementation in order to invoke behavior change) perhaps it is +helpful to see the behavior change implementation of one case, simply as an +example. To implement `failure-status`, the `check_correct_failure_status()` +function found in the `TestCx` implementation block, located in +[src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs), +was modified as per below: + ```diff @@ -295,11 +295,14 @@ impl<'test> TestCx<'test> { } @@ -176,7 +222,14 @@ located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/r } } ``` -Note the use of `self.props.failure_status` to access the header command property. In tests which do not specify the failure -status header command, `self.props.failure_status` will evaluate to the default value of 101 at the time of this writing. -But for a test which specifies a header command of, for example, `// failure-status: 1`, `self.props.failure_status` will -evaluate to 1, as `parse_failure_status()` will have overridden the `TestProps` default value, for that test specifically. +Note the use of `self.props.failure_status` to access the header command +property. In tests which do not specify the failure status header command, +`self.props.failure_status` will evaluate to the default value of 101 at the +time of this writing. But for a test which specifies a header command of, for +example, `// failure-status: 1`, `self.props.failure_status` will evaluate to +1, as `parse_failure_status()` will have overridden the `TestProps` default +value, for that test specifically. + +[test]: https://github.com/rust-lang/rust/tree/master/src/test +[header]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs +[common]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs From 80de3962fbc50f5030e9f68d6e2eabf51f850f12 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 21:02:33 -0500 Subject: [PATCH 0172/1812] Fix long lines in const-eval --- src/const-eval.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/const-eval.md b/src/const-eval.md index 3fb65216a..4a05255c6 100644 --- a/src/const-eval.md +++ b/src/const-eval.md @@ -11,7 +11,8 @@ Prominent examples are * Array length * needs to be known to reserve stack or heap space * Enum variant discriminants - * needs to be known to prevent two variants from having the same discriminant + * needs to be known to prevent two variants from having the same + discriminant * Patterns * need to be known to check for overlapping patterns From 42ef2ad0b8e1fe47e380b5cb8dbabc0d57aad4fc Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 23 Mar 2018 21:03:13 -0500 Subject: [PATCH 0173/1812] Fix long lines in conventions --- src/conventions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index db531c58c..96571301f 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -111,8 +111,8 @@ inspects the Cargo metadata to ensure this. # How to structure your PR -How you prepare the commits in your PR can make a big difference for the reviewer. -Here are some tips. +How you prepare the commits in your PR can make a big difference for the +reviewer. Here are some tips. **Isolate "pure refactorings" into their own commit.** For example, if you rename a method, then put that rename into its own commit, along From 2bb61a3f596b60460211d1d607bfdd63dd9dbb99 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 26 Mar 2018 10:41:14 -0500 Subject: [PATCH 0174/1812] More long lines --- src/incrcomp-debugging.md | 8 ++++---- src/mir-borrowck.md | 9 ++++++--- src/mir-passes.md | 22 +++++++++++++--------- src/mir-regionck.md | 35 +++++++++++++++++------------------ src/mir.md | 25 +++++++++++++++---------- 5 files changed, 55 insertions(+), 44 deletions(-) diff --git a/src/incrcomp-debugging.md b/src/incrcomp-debugging.md index 92a8e10ea..261b46eb0 100644 --- a/src/incrcomp-debugging.md +++ b/src/incrcomp-debugging.md @@ -69,11 +69,11 @@ want the `TypeckTables` node for some particular fn, so you might write: RUST_DEP_GRAPH_FILTER='-> TypeckTables & bar' ``` -This will select only the predecessors of `TypeckTables` nodes for functions with -`bar` in their name. +This will select only the predecessors of `TypeckTables` nodes for functions +with `bar` in their name. -Perhaps you are finding that when you change `foo` you need to re-type-check `bar`, -but you don't think you should have to. In that case, you might do: +Perhaps you are finding that when you change `foo` you need to re-type-check +`bar`, but you don't think you should have to. In that case, you might do: ``` RUST_DEP_GRAPH_FILTER='Hir & foo -> TypeckTables & bar' diff --git a/src/mir-borrowck.md b/src/mir-borrowck.md index 6c4c99d61..51a6c6cbf 100644 --- a/src/mir-borrowck.md +++ b/src/mir-borrowck.md @@ -6,7 +6,8 @@ enforcing a number of properties: - That all variables are initialized before they are used. - That you can't move the same value twice. - That you can't move a value while it is borrowed. -- That you can't access a place while it is mutably borrowed (except through the reference). +- That you can't access a place while it is mutably borrowed (except through + the reference). - That you can't mutate a place while it is shared borrowed. - etc @@ -44,10 +45,12 @@ The overall flow of the borrow checker is as follows: Among other things, this function will replace all of the regions in the MIR with fresh [inference variables](./appendix-glossary.html). - (More details can be found in [the regionck section](./mir-regionck.html).) -- Next, we perform a number of [dataflow analyses](./appendix-background.html#dataflow) +- Next, we perform a number of [dataflow + analyses](./appendix-background.html#dataflow) that compute what data is moved and when. The results of these analyses are needed to do both borrow checking and region inference. -- Using the move data, we can then compute the values of all the regions in the MIR. +- Using the move data, we can then compute the values of all the regions in the + MIR. - (More details can be found in [the NLL section](./mir-regionck.html).) - Finally, the borrow checker itself runs, taking as input (a) the results of move analysis and (b) the regions computed by the region diff --git a/src/mir-passes.md b/src/mir-passes.md index 6d657ae70..cd05edfb8 100644 --- a/src/mir-passes.md +++ b/src/mir-passes.md @@ -15,16 +15,19 @@ transformations. These suites represent useful intermediate points where we want to access the MIR for type checking or other purposes: - `mir_build(D)` – not a query, but this constructs the initial MIR -- `mir_const(D)` – applies some simple transformations to make MIR ready for constant evaluation; -- `mir_validated(D)` – applies some more transformations, making MIR ready for borrow checking; -- `optimized_mir(D)` – the final state, after all optimizations have been performed. +- `mir_const(D)` – applies some simple transformations to make MIR ready for + constant evaluation; +- `mir_validated(D)` – applies some more transformations, making MIR ready for + borrow checking; +- `optimized_mir(D)` – the final state, after all optimizations have been + performed. ### Seeing how the MIR changes as the compiler executes -`-Zdump-mir=F` is a handy compiler options that will let you view the MIR -for each function at each stage of compilation. `-Zdump-mir` takes a **filter** -`F` which allows you to control which functions and which passes you are interesting -in. For example: +`-Zdump-mir=F` is a handy compiler options that will let you view the MIR for +each function at each stage of compilation. `-Zdump-mir` takes a **filter** `F` +which allows you to control which functions and which passes you are +interesting in. For example: ```bash > rustc -Zdump-mir=foo ... @@ -58,8 +61,9 @@ rustc.main.000-000.CleanEndRegions.after.mir def-path to the function etc being dumped ``` -You can also make more selective filters. For example, `main & CleanEndRegions` will select -for things that reference *both* `main` and the pass `CleanEndRegions`: +You can also make more selective filters. For example, `main & CleanEndRegions` +will select for things that reference *both* `main` and the pass +`CleanEndRegions`: ```bash > rustc -Zdump-mir='main & CleanEndRegions' foo.rs diff --git a/src/mir-regionck.md b/src/mir-regionck.md index dbf740ea8..529b42395 100644 --- a/src/mir-regionck.md +++ b/src/mir-regionck.md @@ -418,16 +418,15 @@ variable `'?3`, but the variable `'?3` is not forced to outlive anything else. Therefore, it simply starts and ends as the empty set of elements, and hence the type-check succeeds here. -(This should surprise you a little. It surprised me when I first -realized it. We are saying that if we are a fn that **needs both of -its arguments to have the same region**, we can accept being called -with **arguments with two distinct regions**. That seems intuitively -unsound. But in fact, it's fine, as I -[tried to explain in this issue on the Rust issue tracker long ago][ohdeargoditsallbroken]. -The reason is that even if we get called with arguments of two -distinct lifetimes, those two lifetimes have some intersection (the -call itself), and that intersection can be our value of `'a` that we -use as the common lifetime of our arguments. -nmatsakis) +(This should surprise you a little. It surprised me when I first realized it. +We are saying that if we are a fn that **needs both of its arguments to have +the same region**, we can accept being called with **arguments with two +distinct regions**. That seems intuitively unsound. But in fact, it's fine, as +I tried to explain in [this issue][ohdeargoditsallbroken] on the Rust issue +tracker long ago. The reason is that even if we get called with arguments of +two distinct lifetimes, those two lifetimes have some intersection (the call +itself), and that intersection can be our value of `'a` that we use as the +common lifetime of our arguments. -nmatsakis) [ohdeargoditsallbroken]: https://github.com/rust-lang/rust/issues/32330#issuecomment-202536977 @@ -440,10 +439,10 @@ a return type: <: for<'b, 'c> fn(&'b u32, &'c u32) -> &'b u32 -Despite seeming very similar to the previous example, this case is -going to get an error. That's good: the problem is that we've gone -from a fn that promises to return one of its two arguments, to a fn -that is promising to return the first one. That is unsound. Let's see how it plays out. +Despite seeming very similar to the previous example, this case is going to get +an error. That's good: the problem is that we've gone from a fn that promises +to return one of its two arguments, to a fn that is promising to return the +first one. That is unsound. Let's see how it plays out. First, we skolemize the supertype: @@ -463,8 +462,8 @@ And now we create the subtyping relationships: &'!2 u32 <: &'?3 u32 // arg 2 &'?3 u32 <: &'!1 u32 // return type -And finally the outlives relationships. Here, let V1, V2, and V3 be the variables -we assign to `!1`, `!2`, and `?3` respectively: +And finally the outlives relationships. Here, let V1, V2, and V3 be the +variables we assign to `!1`, `!2`, and `?3` respectively: V1: V3 V2: V3 @@ -476,8 +475,8 @@ Those variables will have these initial values: V2 in U2 = {skol(2)} V3 in U2 = {} -Now because of the `V3: V1` constraint, we have to add `skol(1)` into `V3` (and indeed -it is visible from `V3`), so we get: +Now because of the `V3: V1` constraint, we have to add `skol(1)` into `V3` (and +indeed it is visible from `V3`), so we get: V3 in U2 = {skol(1)} diff --git a/src/mir.md b/src/mir.md index 688a8750c..58479cf96 100644 --- a/src/mir.md +++ b/src/mir.md @@ -34,14 +34,17 @@ This section introduces the key concepts of MIR, summarized here: - **Basic blocks**: units of the control-flow graph, consisting of: - **statements:** actions with one successor - - **terminators:** actions with potentially multiple successors; always at the end of a block - - (if you're not familiar with the term *basic block*, see the [background chapter][cfg]) + - **terminators:** actions with potentially multiple successors; always at + the end of a block + - (if you're not familiar with the term *basic block*, see the [background + chapter][cfg]) - **Locals:** Memory locations alloated on the stack (conceptually, at least), such as function arguments, local variables, and temporaries. These are identified by an index, written with a leading underscore, like `_1`. There is also a special "local" (`_0`) allocated to store the return value. -- **Places:** expressions that identify a location in memory, like `_1` or `_1.f`. +- **Places:** expressions that identify a location in memory, like `_1` or + `_1.f`. - **Rvalues:** expressions that produce a value. The "R" stands for the fact that these are the "right-hand side" of an assignment. - **Operands:** the arguments to an rvalue, which can either be a @@ -100,8 +103,9 @@ you their original name (`// "vec" in scope 1...`). The "scope" blocks (e.g., `scope 1 { .. }`) describe the lexical structure of the source program (which names were in scope when). -**Basic blocks.** Reading further, we see our first **basic block** (naturally it may look -slightly different when you view it, and I am ignoring some of the comments): +**Basic blocks.** Reading further, we see our first **basic block** (naturally +it may look slightly different when you view it, and I am ignoring some of the +comments): ``` bb0: { @@ -110,8 +114,8 @@ bb0: { } ``` -A basic block is defined by a series of **statements** and a final **terminator**. -In this case, there is one statement: +A basic block is defined by a series of **statements** and a final +**terminator**. In this case, there is one statement: ``` StorageLive(_1); @@ -146,8 +150,8 @@ bb2: { } ``` -Here there are two statements: another `StorageLive`, introducing the `_3` temporary, -and then an assignment: +Here there are two statements: another `StorageLive`, introducing the `_3` +temporary, and then an assignment: ``` _3 = &mut _1; @@ -189,7 +193,8 @@ TMP1 = a + b x = TMP1 + c ``` -([Try it and see, though you may want to do release mode to skip over the overflow checks.][play-abc]) +([Try it and see][play-abc], though you may want to do release mode to skip +over the overflow checks.) [play-abc]: https://play.rust-lang.org/?gist=1751196d63b2a71f8208119e59d8a5b6&version=stable From 9e6cdf3de3f6eb1db48ed13baacdcff867d09c01 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 26 Mar 2018 10:44:32 -0500 Subject: [PATCH 0175/1812] still more long lines --- src/traits-canonical-queries.md | 6 ++++-- src/traits-canonicalization.md | 4 ++-- src/traits-goals-and-clauses.md | 12 ++++++----- src/traits-lowering-rules.md | 37 ++++++++++++++++++--------------- 4 files changed, 33 insertions(+), 26 deletions(-) diff --git a/src/traits-canonical-queries.md b/src/traits-canonical-queries.md index 3fea5fbd9..b291a2898 100644 --- a/src/traits-canonical-queries.md +++ b/src/traits-canonical-queries.md @@ -99,7 +99,8 @@ that the query was false and had no answers (e.g., `Box: Copy`). Otherwise, the `QueryResult` gives back information about the possible answer(s) we did find. It consists of four parts: -- **Certainty:** tells you how sure we are of this answer. It can have two values: +- **Certainty:** tells you how sure we are of this answer. It can have two + values: - `Proven` means that the result is known to be true. - This might be the result for trying to prove `Vec: Clone`, say, or `Rc: Clone`. @@ -171,7 +172,8 @@ Therefore, the result we get back would be as follows (I'm going to ignore region constraints and the "value"): - Certainty: `Ambiguous` -- we're not sure yet if this holds -- Var values: `[?T = ?T, ?U = ?U]` -- we learned nothing about the values of the variables +- Var values: `[?T = ?T, ?U = ?U]` -- we learned nothing about the values of + the variables In short, the query result says that it is too soon to say much about whether this trait is proven. During type-checking, this is not an diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index bef858af2..9f3af36c9 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -129,8 +129,8 @@ for which we made a substutition S: S = [?A, '?B, ?C] -We then did some work which unified some of those variables with other things. If we -"refresh" S with the latest results, we get: +We then did some work which unified some of those variables with other things. +If we "refresh" S with the latest results, we get: S = [Vec, '?D, ?E] diff --git a/src/traits-goals-and-clauses.md b/src/traits-goals-and-clauses.md index 92e1b67d9..8e5e82d01 100644 --- a/src/traits-goals-and-clauses.md +++ b/src/traits-goals-and-clauses.md @@ -81,13 +81,15 @@ Given that, we can define a `DomainGoal` as follows: - as we'll see in the section on lowering, `FromEnv(X)` implies `Implemented(X)` but not vice versa. This distinction is crucial to [implied bounds]. -- `ProjectionEq(Projection = Type)` -- the given associated type `Projection` is equal - to `Type`; see [the section on associated types](./traits-associated-types.html) +- `ProjectionEq(Projection = Type)` -- the given associated type `Projection` + is equal to `Type`; see [the section on associated + types](./traits-associated-types.html) - in general, proving `ProjectionEq(TraitRef::Item = Type)` also requires proving `Implemented(TraitRef)` -- `Normalize(Projection -> Type)` -- the given associated type `Projection` can be [normalized][n] - to `Type` - - as discussed in [the section on associated types](./traits-associated-types.html), +- `Normalize(Projection -> Type)` -- the given associated type `Projection` can + be [normalized][n] to `Type` + - as discussed in [the section on associated + types](./traits-associated-types.html), `Normalize` implies `ProjectionEq` but not vice versa - `WellFormed(..)` -- these goals imply that the given item is *well-formed* diff --git a/src/traits-lowering-rules.md b/src/traits-lowering-rules.md index 8de20f1d8..544ae41b3 100644 --- a/src/traits-lowering-rules.md +++ b/src/traits-lowering-rules.md @@ -26,7 +26,7 @@ Each of these lowering rules is given a name, documented with a comment like so: // Rule Foo-Bar-Baz - + you can also search through the `librustc_traits` crate in rustc to find the corresponding rules from the implementation. @@ -36,7 +36,8 @@ When used in a goal position, where clauses can be mapped directly to [domain goals][dg], as follows: - `A0: Foo` maps to `Implemented(A0: Foo)`. -- `A0: Foo` maps to `ProjectionEq(>::Item = T)` +- `A0: Foo` maps to + `ProjectionEq(>::Item = T)` - `T: 'r` maps to `Outlives(T, 'r)` - `'a: 'b` maps to `Outlives('a, 'b)` @@ -58,7 +59,7 @@ on the lowered where clauses, as defined here: - `WellFormed(WC)` -- this indicates that: - `Implemented(TraitRef)` becomes `WellFormed(TraitRef)` - `ProjectionEq(Projection = Ty)` becomes `WellFormed(Projection = Ty)` - + *TODO*: I suspect that we want to alter the outlives relations too, but Chalk isn't modeling those right now. @@ -106,7 +107,7 @@ The next few clauses have to do with implied bounds (see also forall { FromEnv(WC) :- FromEnv(Self: Trait { - WellFormed(Self: Trait) :- Implemented(Self: Trait) && WellFormed(WC) - } +```txt +// Rule WellFormed-TraitRef +// +// For each where clause WC: +forall { + WellFormed(Self: Trait) :- Implemented(Self: Trait) && WellFormed(WC) +} +``` This `WellFormed` rule states that `T: Trait` is well-formed if (a) `T: Trait` is implemented and (b) all the where-clauses declared on @@ -149,9 +152,9 @@ trait A { } trait B { } ``` -Here, the transitive set of implications for `T: Foo` are `T: A`, `T: Bar`, and `T: B`. -And indeed if we were to try to prove `WellFormed(T: Foo)`, we would have to prove each -one of those: +Here, the transitive set of implications for `T: Foo` are `T: A`, `T: Bar`, and +`T: B`. And indeed if we were to try to prove `WellFormed(T: Foo)`, we would +have to prove each one of those: - `WellFormed(T: Foo)` - `Implemented(T: Foo)` @@ -212,7 +215,7 @@ but reproduced here for reference: Implemented(Self: Trait) && WC1 } - + The next rule covers implied bounds for the projection. In particular, the `Bounds` declared on the associated type must be proven to hold to show that the impl is well-formed, and hence we can rely on them @@ -223,8 +226,8 @@ elsewhere. ### Lowering function and constant declarations -Chalk didn't model functions and constants, but I would eventually -like to treat them exactly like normalization. See [the section on function/constant +Chalk didn't model functions and constants, but I would eventually like to +treat them exactly like normalization. See [the section on function/constant values below](#constant-vals) for more details. ## Lowering impls @@ -272,7 +275,7 @@ We produce the following rule: WC && WC1 } } - + Note that `WC` and `WC1` both encode where-clauses that the impl can rely on. From 066ba9ef8210703ddbe9c4b82caf3e1c8b912d35 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 26 Mar 2018 10:46:39 -0500 Subject: [PATCH 0176/1812] reformat basically the whole rustdoc.md --- src/rustdoc.md | 293 +++++++++++++++++++++++++++---------------------- 1 file changed, 162 insertions(+), 131 deletions(-) diff --git a/src/rustdoc.md b/src/rustdoc.md index ae640d110..7a9905d3b 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -1,7 +1,8 @@ # The walking tour of rustdoc -Rustdoc actually uses the rustc internals directly. It lives in-tree with the compiler and standard -library. This chapter is about how it works. (A new implementation is also [under way], though). +Rustdoc actually uses the rustc internals directly. It lives in-tree with the +compiler and standard library. This chapter is about how it works. (A new +implementation is also [under way], though). [under way]: https://github.com/steveklabnik/rustdoc @@ -17,50 +18,57 @@ and [queries] are discussed in the linked chapters. `librustdoc` performs two major steps after that to render a set of documentation: -* "Clean" the AST into a form that's more suited to creating documentation (and slightly more - resistant to churn in the compiler). +* "Clean" the AST into a form that's more suited to creating documentation (and + slightly more resistant to churn in the compiler). * Use this cleaned AST to render a crate's documentation, one page at a time. -Naturally, there's more than just this, and those descriptions simplify out lots of details, but -that's the high-level overview. +Naturally, there's more than just this, and those descriptions simplify out +lots of details, but that's the high-level overview. -(Side note: `librustdoc` is a library crate! The `rustdoc` binary is crated using the project in -[`src/tools/rustdoc`][bin]. Note that literally all that does is call the `main()` that's in this crate's -`lib.rs`, though.) +(Side note: `librustdoc` is a library crate! The `rustdoc` binary is crated +using the project in [`src/tools/rustdoc`][bin]. Note that literally all that +does is call the `main()` that's in this crate's `lib.rs`, though.) [bin]: https://github.com/rust-lang/rust/tree/master/src/tools/rustdoc ## Cheat sheet -* Use `x.py build --stage 1 src/libstd src/tools/rustdoc` to make a useable rustdoc you can run on - other projects. +* Use `x.py build --stage 1 src/libstd src/tools/rustdoc` to make a useable + rustdoc you can run on other projects. * Add `src/libtest` to be able to use `rustdoc --test`. - * If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1` previously, then - after the previous build command, `cargo +local doc` will Just Work. -* Use `x.py doc --stage 1 src/libstd` to use this rustdoc to generate the standard library docs. - * The completed docs will be available in `build/$TARGET/doc/std`, though the bundle is meant to - be used as though you would copy out the `doc` folder to a web server, since that's where the - CSS/JS and landing page are. -* Most of the HTML printing code is in `html/format.rs` and `html/render.rs`. It's in a bunch of - `fmt::Display` implementations and supplementary functions. -* The types that got `Display` impls above are defined in `clean/mod.rs`, right next to the custom - `Clean` trait used to process them out of the rustc HIR. + * If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1` + previously, then after the previous build command, `cargo +local doc` will + Just Work. +* Use `x.py doc --stage 1 src/libstd` to use this rustdoc to generate the + standard library docs. + * The completed docs will be available in `build/$TARGET/doc/std`, though the + bundle is meant to be used as though you would copy out the `doc` folder to + a web server, since that's where the CSS/JS and landing page are. +* Most of the HTML printing code is in `html/format.rs` and `html/render.rs`. + It's in a bunch of `fmt::Display` implementations and supplementary + functions. +* The types that got `Display` impls above are defined in `clean/mod.rs`, right + next to the custom `Clean` trait used to process them out of the rustc HIR. * The bits specific to using rustdoc as a test harness are in `test.rs`. -* The Markdown renderer is loaded up in `html/markdown.rs`, including functions for extracting - doctests from a given block of Markdown. -* The tests on rustdoc *output* are located in `src/test/rustdoc`, where they're handled by the test - runner of rustbuild and the supplementary script `src/etc/htmldocck.py`. -* Tests on search index generation are located in `src/test/rustdoc-js`, as a series of JavaScript - files that encode queries on the standard library search index and expected results. +* The Markdown renderer is loaded up in `html/markdown.rs`, including functions + for extracting doctests from a given block of Markdown. +* The tests on rustdoc *output* are located in `src/test/rustdoc`, where + they're handled by the test runner of rustbuild and the supplementary script + `src/etc/htmldocck.py`. +* Tests on search index generation are located in `src/test/rustdoc-js`, as a + series of JavaScript files that encode queries on the standard library search + index and expected results. ## From crate to clean -In `core.rs` are two central items: the `DocContext` struct, and the `run_core` function. The latter -is where rustdoc calls out to rustc to compile a crate to the point where rustdoc can take over. The -former is a state container used when crawling through a crate to gather its documentation. +In `core.rs` are two central items: the `DocContext` struct, and the `run_core` +function. The latter is where rustdoc calls out to rustc to compile a crate to +the point where rustdoc can take over. The former is a state container used +when crawling through a crate to gather its documentation. -The main process of crate crawling is done in `clean/mod.rs` through several implementations of the -`Clean` trait defined within. This is a conversion trait, which defines one method: +The main process of crate crawling is done in `clean/mod.rs` through several +implementations of the `Clean` trait defined within. This is a conversion +trait, which defines one method: ```rust pub trait Clean { @@ -68,40 +76,47 @@ pub trait Clean { } ``` -`clean/mod.rs` also defines the types for the "cleaned" AST used later on to render documentation -pages. Each usually accompanies an implementation of `Clean` that takes some AST or HIR type from -rustc and converts it into the appropriate "cleaned" type. "Big" items like modules or associated -items may have some extra processing in its `Clean` implementation, but for the most part these -impls are straightforward conversions. The "entry point" to this module is the `impl Clean -for visit_ast::RustdocVisitor`, which is called by `run_core` above. - -You see, I actually lied a little earlier: There's another AST transformation that happens before -the events in `clean/mod.rs`. In `visit_ast.rs` is the type `RustdocVisitor`, which *actually* -crawls a `hir::Crate` to get the first intermediate representation, defined in `doctree.rs`. This -pass is mainly to get a few intermediate wrappers around the HIR types and to process visibility -and inlining. This is where `#[doc(inline)]`, `#[doc(no_inline)]`, and `#[doc(hidden)]` are -processed, as well as the logic for whether a `pub use` should get the full page or a "Reexport" -line in the module page. - -The other major thing that happens in `clean/mod.rs` is the collection of doc comments and -`#[doc=""]` attributes into a separate field of the Attributes struct, present on anything that gets -hand-written documentation. This makes it easier to collect this documentation later in the process. - -The primary output of this process is a `clean::Crate` with a tree of Items which describe the -publicly-documentable items in the target crate. +`clean/mod.rs` also defines the types for the "cleaned" AST used later on to +render documentation pages. Each usually accompanies an implementation of +`Clean` that takes some AST or HIR type from rustc and converts it into the +appropriate "cleaned" type. "Big" items like modules or associated items may +have some extra processing in its `Clean` implementation, but for the most part +these impls are straightforward conversions. The "entry point" to this module +is the `impl Clean for visit_ast::RustdocVisitor`, which is called by +`run_core` above. + +You see, I actually lied a little earlier: There's another AST transformation +that happens before the events in `clean/mod.rs`. In `visit_ast.rs` is the +type `RustdocVisitor`, which *actually* crawls a `hir::Crate` to get the first +intermediate representation, defined in `doctree.rs`. This pass is mainly to +get a few intermediate wrappers around the HIR types and to process visibility +and inlining. This is where `#[doc(inline)]`, `#[doc(no_inline)]`, and +`#[doc(hidden)]` are processed, as well as the logic for whether a `pub use` +should get the full page or a "Reexport" line in the module page. + +The other major thing that happens in `clean/mod.rs` is the collection of doc +comments and `#[doc=""]` attributes into a separate field of the Attributes +struct, present on anything that gets hand-written documentation. This makes it +easier to collect this documentation later in the process. + +The primary output of this process is a `clean::Crate` with a tree of Items +which describe the publicly-documentable items in the target crate. ### Hot potato -Before moving on to the next major step, a few important "passes" occur over the documentation. -These do things like combine the separate "attributes" into a single string and strip leading -whitespace to make the document easier on the markdown parser, or drop items that are not public or -deliberately hidden with `#[doc(hidden)]`. These are all implemented in the `passes/` directory, one -file per pass. By default, all of these passes are run on a crate, but the ones regarding dropping -private/hidden items can be bypassed by passing `--document-private-items` to rustdoc. Note that -unlike the previous set of AST transformations, the passes happen on the _cleaned_ crate. +Before moving on to the next major step, a few important "passes" occur over +the documentation. These do things like combine the separate "attributes" into +a single string and strip leading whitespace to make the document easier on the +markdown parser, or drop items that are not public or deliberately hidden with +`#[doc(hidden)]`. These are all implemented in the `passes/` directory, one +file per pass. By default, all of these passes are run on a crate, but the ones +regarding dropping private/hidden items can be bypassed by passing +`--document-private-items` to rustdoc. Note that unlike the previous set of AST +transformations, the passes happen on the _cleaned_ crate. -(Strictly speaking, you can fine-tune the passes run and even add your own, but [we're trying to -deprecate that][44136]. If you need finer-grain control over these passes, please let us know!) +(Strictly speaking, you can fine-tune the passes run and even add your own, but +[we're trying to deprecate that][44136]. If you need finer-grain control over +these passes, please let us know!) [44136]: https://github.com/rust-lang/rust/issues/44136 @@ -116,9 +131,9 @@ Here is current (as of this writing) list of passes: markdown to like it. This is necessary because the convention for writing documentation is to provide a space between the `///` or `//!` marker and the text, and stripping that leading space will make the text easier to parse by - the Markdown parser. (In the past, the markdown parser used was not Commonmark- - compliant, which caused annoyances with extra whitespace but this seems to be - less of an issue today.) + the Markdown parser. (In the past, the markdown parser used was not + Commonmark- compliant, which caused annoyances with extra whitespace but this + seems to be less of an issue today.) - `strip-priv-imports` strips all private import statements (`use`, `extern crate`) from a crate. This is necessary because rustdoc will handle *public* imports by either inlining the item's documentation to the module or creating @@ -130,85 +145,101 @@ Here is current (as of this writing) list of passes: ## From clean to crate -This is where the "second phase" in rustdoc begins. This phase primarily lives in the `html/` -folder, and it all starts with `run()` in `html/render.rs`. This code is responsible for setting up -the `Context`, `SharedContext`, and `Cache` which are used during rendering, copying out the static -files which live in every rendered set of documentation (things like the fonts, CSS, and JavaScript -that live in `html/static/`), creating the search index, and printing out the source code rendering, -before beginning the process of rendering all the documentation for the crate. - -Several functions implemented directly on `Context` take the `clean::Crate` and set up some state -between rendering items or recursing on a module's child items. From here the "page rendering" -begins, via an enormous `write!()` call in `html/layout.rs`. The parts that actually generate HTML -from the items and documentation occurs within a series of `std::fmt::Display` implementations and -functions that pass around a `&mut std::fmt::Formatter`. The top-level implementation that writes -out the page body is the `impl<'a> fmt::Display for Item<'a>` in `html/render.rs`, which switches -out to one of several `item_*` functions based on the kind of `Item` being rendered. - -Depending on what kind of rendering code you're looking for, you'll probably find it either in -`html/render.rs` for major items like "what sections should I print for a struct page" or -`html/format.rs` for smaller component pieces like "how should I print a where clause as part of -some other item". - -Whenever rustdoc comes across an item that should print hand-written documentation alongside, it -calls out to `html/markdown.rs` which interfaces with the Markdown parser. This is exposed as a -series of types that wrap a string of Markdown, and implement `fmt::Display` to emit HTML text. It -takes special care to enable certain features like footnotes and tables and add syntax highlighting -to Rust code blocks (via `html/highlight.rs`) before running the Markdown parser. There's also a -function in here (`find_testable_code`) that specifically scans for Rust code blocks so the +This is where the "second phase" in rustdoc begins. This phase primarily lives +in the `html/` folder, and it all starts with `run()` in `html/render.rs`. This +code is responsible for setting up the `Context`, `SharedContext`, and `Cache` +which are used during rendering, copying out the static files which live in +every rendered set of documentation (things like the fonts, CSS, and JavaScript +that live in `html/static/`), creating the search index, and printing out the +source code rendering, before beginning the process of rendering all the +documentation for the crate. + +Several functions implemented directly on `Context` take the `clean::Crate` and +set up some state between rendering items or recursing on a module's child +items. From here the "page rendering" begins, via an enormous `write!()` call +in `html/layout.rs`. The parts that actually generate HTML from the items and +documentation occurs within a series of `std::fmt::Display` implementations and +functions that pass around a `&mut std::fmt::Formatter`. The top-level +implementation that writes out the page body is the `impl<'a> fmt::Display for +Item<'a>` in `html/render.rs`, which switches out to one of several `item_*` +functions based on the kind of `Item` being rendered. + +Depending on what kind of rendering code you're looking for, you'll probably +find it either in `html/render.rs` for major items like "what sections should I +print for a struct page" or `html/format.rs` for smaller component pieces like +"how should I print a where clause as part of some other item". + +Whenever rustdoc comes across an item that should print hand-written +documentation alongside, it calls out to `html/markdown.rs` which interfaces +with the Markdown parser. This is exposed as a series of types that wrap a +string of Markdown, and implement `fmt::Display` to emit HTML text. It takes +special care to enable certain features like footnotes and tables and add +syntax highlighting to Rust code blocks (via `html/highlight.rs`) before +running the Markdown parser. There's also a function in here +(`find_testable_code`) that specifically scans for Rust code blocks so the test-runner code can find all the doctests in the crate. ### From soup to nuts -(alternate title: ["An unbroken thread that stretches from those first `Cell`s to us"][video]) +(alternate title: ["An unbroken thread that stretches from those first `Cell`s +to us"][video]) [video]: https://www.youtube.com/watch?v=hOLAGYmUQV0 -It's important to note that the AST cleaning can ask the compiler for information (crucially, -`DocContext` contains a `TyCtxt`), but page rendering cannot. The `clean::Crate` created within -`run_core` is passed outside the compiler context before being handed to `html::render::run`. This -means that a lot of the "supplementary data" that isn't immediately available inside an item's -definition, like which trait is the `Deref` trait used by the language, needs to be collected during -cleaning, stored in the `DocContext`, and passed along to the `SharedContext` during HTML rendering. -This manifests as a bunch of shared state, context variables, and `RefCell`s. - -Also of note is that some items that come from "asking the compiler" don't go directly into the -`DocContext` - for example, when loading items from a foreign crate, rustdoc will ask about trait -implementations and generate new `Item`s for the impls based on that information. This goes directly -into the returned `Crate` rather than roundabout through the `DocContext`. This way, these -implementations can be collected alongside the others, right before rendering the HTML. +It's important to note that the AST cleaning can ask the compiler for +information (crucially, `DocContext` contains a `TyCtxt`), but page rendering +cannot. The `clean::Crate` created within `run_core` is passed outside the +compiler context before being handed to `html::render::run`. This means that a +lot of the "supplementary data" that isn't immediately available inside an +item's definition, like which trait is the `Deref` trait used by the language, +needs to be collected during cleaning, stored in the `DocContext`, and passed +along to the `SharedContext` during HTML rendering. This manifests as a bunch +of shared state, context variables, and `RefCell`s. + +Also of note is that some items that come from "asking the compiler" don't go +directly into the `DocContext` - for example, when loading items from a foreign +crate, rustdoc will ask about trait implementations and generate new `Item`s +for the impls based on that information. This goes directly into the returned +`Crate` rather than roundabout through the `DocContext`. This way, these +implementations can be collected alongside the others, right before rendering +the HTML. ## Other tricks up its sleeve -All this describes the process for generating HTML documentation from a Rust crate, but there are -couple other major modes that rustdoc runs in. It can also be run on a standalone Markdown file, or -it can run doctests on Rust code or standalone Markdown files. For the former, it shortcuts straight -to `html/markdown.rs`, optionally including a mode which inserts a Table of Contents to the output -HTML. - -For the latter, rustdoc runs a similar partial-compilation to get relevant documentation in -`test.rs`, but instead of going through the full clean and render process, it runs a much simpler -crate walk to grab *just* the hand-written documentation. Combined with the aforementioned -"`find_testable_code`" in `html/markdown.rs`, it builds up a collection of tests to run before -handing them off to the libtest test runner. One notable location in `test.rs` is the function -`make_test`, which is where hand-written doctests get transformed into something that can be -executed. +All this describes the process for generating HTML documentation from a Rust +crate, but there are couple other major modes that rustdoc runs in. It can also +be run on a standalone Markdown file, or it can run doctests on Rust code or +standalone Markdown files. For the former, it shortcuts straight to +`html/markdown.rs`, optionally including a mode which inserts a Table of +Contents to the output HTML. + +For the latter, rustdoc runs a similar partial-compilation to get relevant +documentation in `test.rs`, but instead of going through the full clean and +render process, it runs a much simpler crate walk to grab *just* the +hand-written documentation. Combined with the aforementioned +"`find_testable_code`" in `html/markdown.rs`, it builds up a collection of +tests to run before handing them off to the libtest test runner. One notable +location in `test.rs` is the function `make_test`, which is where hand-written +doctests get transformed into something that can be executed. Some extra reading about `make_test` can be found [here](https://quietmisdreavus.net/code/2018/02/23/how-the-doctests-get-made/). ## Dotting i's and crossing t's -So that's rustdoc's code in a nutshell, but there's more things in the repo that deal with it. Since -we have the full `compiletest` suite at hand, there's a set of tests in `src/test/rustdoc` that make -sure the final HTML is what we expect in various situations. These tests also use a supplementary -script, `src/etc/htmldocck.py`, that allows it to look through the final HTML using XPath notation -to get a precise look at the output. The full description of all the commands available to rustdoc -tests is in `htmldocck.py`. - -In addition, there are separate tests for the search index and rustdoc's ability to query it. The -files in `src/test/rustdoc-js` each contain a different search query and the expected results, -broken out by search tab. These files are processed by a script in `src/tools/rustdoc-js` and the -Node.js runtime. These tests don't have as thorough of a writeup, but a broad example that features -results in all tabs can be found in `basic.js`. The basic idea is that you match a given `QUERY` -with a set of `EXPECTED` results, complete with the full item path of each item. +So that's rustdoc's code in a nutshell, but there's more things in the repo +that deal with it. Since we have the full `compiletest` suite at hand, there's +a set of tests in `src/test/rustdoc` that make sure the final HTML is what we +expect in various situations. These tests also use a supplementary script, +`src/etc/htmldocck.py`, that allows it to look through the final HTML using +XPath notation to get a precise look at the output. The full description of all +the commands available to rustdoc tests is in `htmldocck.py`. + +In addition, there are separate tests for the search index and rustdoc's +ability to query it. The files in `src/test/rustdoc-js` each contain a +different search query and the expected results, broken out by search tab. +These files are processed by a script in `src/tools/rustdoc-js` and the Node.js +runtime. These tests don't have as thorough of a writeup, but a broad example +that features results in all tabs can be found in `basic.js`. The basic idea is +that you match a given `QUERY` with a set of `EXPECTED` results, complete with +the full item path of each item. From 36179fb7410cf28f89469bfc3badb01f67b34c41 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1=C5=A1=20Gaven=C4=8Diak?= Date: Tue, 27 Mar 2018 14:32:45 +0200 Subject: [PATCH 0177/1812] Add info on test result caching --- src/tests/running.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/tests/running.md b/src/tests/running.md index 6bac0121a..84cead4bf 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -13,6 +13,12 @@ a very long time, and anyway bors / travis will do it for you. (Often, I will run this command in the background after opening a PR that I think is done, but rarely otherwise. -nmatsakis) +The test results are cached and previously successfull tests are +`ignored` during testing. The stdout/stderr contents as well as a +timestamp file for every test can be found under `build/ARCH/test/`. +To force-rerun a test (e.g. in case the test runner fails to notice +a change) you can simply remove the timestamp file. + ## Running a subset of the test suites When working on a specific PR, you will usually want to run a smaller From 4d5ad15ad49afdc5f231dd57f2bc0906b2b45fff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1=C5=A1=20Gaven=C4=8Diak?= Date: Tue, 27 Mar 2018 20:03:56 +0200 Subject: [PATCH 0178/1812] Fix a typo --- src/tests/running.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/running.md b/src/tests/running.md index 84cead4bf..4e8c71590 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -13,7 +13,7 @@ a very long time, and anyway bors / travis will do it for you. (Often, I will run this command in the background after opening a PR that I think is done, but rarely otherwise. -nmatsakis) -The test results are cached and previously successfull tests are +The test results are cached and previously successful tests are `ignored` during testing. The stdout/stderr contents as well as a timestamp file for every test can be found under `build/ARCH/test/`. To force-rerun a test (e.g. in case the test runner fails to notice From 3d4332cd4fef33c6371907ffe15d34b496ca8a8b Mon Sep 17 00:00:00 2001 From: Dan Robertson Date: Wed, 28 Mar 2018 03:23:51 +0000 Subject: [PATCH 0179/1812] Update links Add missing link and add link for UFCS. --- src/method-lookup.md | 3 ++- src/traits-bibliography.md | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index 543428d62..ac0e427db 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -12,7 +12,7 @@ the form: receiver.method(...) ``` -into a more explicit UFCS form: +into a more explicit [UFCS] form: ```rust Trait::method(ADJ(receiver), ...) // for a trait call @@ -37,6 +37,7 @@ probe phase produces a "pick" (`probe::Pick`), which is designed to be cacheable across method-call sites. Therefore, it does not include inference variables or other information. +[UFCS]: https://github.com/rust-lang/rfcs/blob/master/text/0132-ufcs.md [probe]: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/method/probe.rs [confirm]: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/method/confirm.rs diff --git a/src/traits-bibliography.md b/src/traits-bibliography.md index d9ff912c7..02607b525 100644 --- a/src/traits-bibliography.md +++ b/src/traits-bibliography.md @@ -26,3 +26,4 @@ SLG formulation that is the basis for our on-demand solver. [nftrd]: https://dl.acm.org/citation.cfm?id=651202 [ts]: http://www3.cs.stonybrook.edu/~tswift/ +[Theresa Swift]: http://www3.cs.stonybrook.edu/~tswift/ From 3c189daf2c14bd2e3bfb51446c6564dcc0a01f12 Mon Sep 17 00:00:00 2001 From: Philip Munksgaard Date: Tue, 3 Apr 2018 16:27:29 +0200 Subject: [PATCH 0180/1812] Fix typo in rustdoc.md --- src/rustdoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustdoc.md b/src/rustdoc.md index 7a9905d3b..e075087fc 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -25,7 +25,7 @@ documentation: Naturally, there's more than just this, and those descriptions simplify out lots of details, but that's the high-level overview. -(Side note: `librustdoc` is a library crate! The `rustdoc` binary is crated +(Side note: `librustdoc` is a library crate! The `rustdoc` binary is created using the project in [`src/tools/rustdoc`][bin]. Note that literally all that does is call the `main()` that's in this crate's `lib.rs`, though.) From f5ff6d03be39a72bbca282fe866e481f24471139 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Wed, 4 Apr 2018 13:41:23 -0400 Subject: [PATCH 0181/1812] Link to internal rustdocs#100 --- src/appendix-stupid-stats.md | 2 +- src/macro-expansion.md | 6 +++--- src/mir-passes.md | 4 ++-- src/mir-visitor.md | 6 +++--- src/query.md | 4 ++-- src/rustc-driver.md | 10 +++++----- src/the-parser.md | 10 +++++----- src/traits-lowering-module.md | 2 +- 8 files changed, 22 insertions(+), 22 deletions(-) diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md index 8e50b2c31..7aef3a87b 100644 --- a/src/appendix-stupid-stats.md +++ b/src/appendix-stupid-stats.md @@ -87,7 +87,7 @@ in [librustc_back](https://github.com/rust-lang/rust/tree/master/src/librustc_ba (which also contains some things used primarily during translation). All these phases are coordinated by the driver. To see the exact sequence, look -at the `compile_input` function in [librustc_driver/driver.rs](https://github.com/rust-lang/rust/tree/master/src/librustc_driver/driver.rs). +at the `compile_input` function in [librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/). The driver (which is found in [librust_driver](https://github.com/rust-lang/rust/tree/master/src/librustc_driver)) handles all the highest level coordination of compilation - handling command line arguments, maintaining compilation state (primarily in the `Session`), and diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 95ea64f19..c55fdd136 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -156,7 +156,7 @@ TODO [code_dir]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt -[code_mp]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt/macro_parser.rs -[code_mr]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt/macro_rules.rs -[code_parse_int]: https://github.com/rust-lang/rust/blob/a97cd17f5d71fb4ec362f4fbd79373a6e7ed7b82/src/libsyntax/ext/tt/macro_parser.rs#L421 +[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/tt/macro_parser/ +[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/tt/macro_rules/ +[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/tt/macro_parser/fn.parse.html [parsing]: ./the-parser.html diff --git a/src/mir-passes.md b/src/mir-passes.md index cd05edfb8..1d1e27df4 100644 --- a/src/mir-passes.md +++ b/src/mir-passes.md @@ -172,6 +172,6 @@ This mechanism is a bit dodgy. There is a discussion of more elegant alternatives in [rust-lang/rust#41710]. [rust-lang/rust#41710]: https://github.com/rust-lang/rust/issues/41710 -[mirtransform]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/transform/mod.rs -[`NoLandingPads`]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/transform/no_landing_pads.rs +[mirtransform]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/ +[`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/no_landing_pads/struct.NoLandingPads.html [MIR visitor]: mir-visitor.html diff --git a/src/mir-visitor.md b/src/mir-visitor.md index 3a8b06c54..d8b3af497 100644 --- a/src/mir-visitor.md +++ b/src/mir-visitor.md @@ -7,7 +7,7 @@ them, generated via a single macro: `Visitor` (which operates on a `&Mir` and gives back shared references) and `MutVisitor` (which operates on a `&mut Mir` and gives back mutable references). -[m-v]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir/visit.rs +[m-v]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/visit/index.html To implement a visitor, you have to create a type that represents your visitor. Typically, this type wants to "hang on" to whatever @@ -41,7 +41,7 @@ A very simple example of a visitor can be found in [`NoLandingPads`]. That visitor doesn't even require any state: it just visits all terminators and removes their `unwind` successors. -[`NoLandingPads`]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/transform/no_landing_pads.rs +[`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/no_landing_pads/struct.NoLandingPads.html ## Traversal @@ -50,6 +50,6 @@ contains useful functions for walking the MIR CFG in [different standard orders][traversal] (e.g. pre-order, reverse post-order, and so forth). -[t]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir/traversal.rs +[t]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/traversal/index.html [traversal]: https://en.wikipedia.org/wiki/Tree_traversal diff --git a/src/query.md b/src/query.md index 500b9dec8..e3c554049 100644 --- a/src/query.md +++ b/src/query.md @@ -216,7 +216,7 @@ the big macro invocation in changed by the time you read this README, but at present it looks something like: -[maps-mod]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/maps/mod.rs +[maps-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/maps/index.html ``` define_maps! { <'tcx> @@ -270,7 +270,7 @@ Let's go over them one by one: of `Steal` for more details. New uses of `Steal` should **not** be added without alerting `@rust-lang/compiler`. -[dep-node]: https://github.com/rust-lang/rust/blob/master/src/librustc/dep_graph/dep_node.rs +[dep-node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/dep_graph/struct.DepNode.html So, to add a query: diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 23a036e73..af3c3c099 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -67,10 +67,10 @@ pervasive lifetimes. The `rustc::ty::tls` module is used to access these thread-locals, although you should rarely need to touch it. -[`rustc_driver`]: https://github.com/rust-lang/rust/tree/master/src/librustc_driver -[`CompileState`]: https://github.com/rust-lang/rust/blob/master/src/librustc_driver/driver.rs -[`Session`]: https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs -[`TyCtxt`]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs -[`CodeMap`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs +[`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/ +[`CompileState`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html +[`Session`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html +[`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html +[`CodeMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html [stupid-stats]: https://github.com/nrc/stupid-stats [Appendix A]: appendix-stupid-stats.html \ No newline at end of file diff --git a/src/the-parser.md b/src/the-parser.md index 456f0a9ea..623a38e67 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -34,9 +34,9 @@ all the information needed while parsing, as well as the `CodeMap` itself. [libsyntax]: https://github.com/rust-lang/rust/tree/master/src/libsyntax [rustc_errors]: https://github.com/rust-lang/rust/tree/master/src/librustc_errors [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree -[`CodeMap`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs -[ast module]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast.rs +[`CodeMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html +[ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/index.html [parser module]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/parse -[`Parser`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/parser.rs -[`StringReader`]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs -[visit module]: https://github.com/rust-lang/rust/blob/master/src/libsyntax/visit.rs +[`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/parser/struct.Parser.html +[`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html +[visit module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/visit/index.html diff --git a/src/traits-lowering-module.md b/src/traits-lowering-module.md index c47b8fbe8..27c4f29bc 100644 --- a/src/traits-lowering-module.md +++ b/src/traits-lowering-module.md @@ -4,7 +4,7 @@ The program clauses described in the [lowering rules](./traits-lowering-rules.html) section are actually created in the [`rustc_traits::lowering`][lowering] module. -[lowering]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits/lowering.rs +[lowering]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_traits/lowering/ ## The `program_clauses_for` query From 1aceb34508fd16e13fbb167e838d9952f902968e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 5 Apr 2018 08:52:55 -0400 Subject: [PATCH 0182/1812] link directly to the compile-input function --- src/appendix-stupid-stats.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md index 7aef3a87b..87e2ba6dc 100644 --- a/src/appendix-stupid-stats.md +++ b/src/appendix-stupid-stats.md @@ -87,15 +87,16 @@ in [librustc_back](https://github.com/rust-lang/rust/tree/master/src/librustc_ba (which also contains some things used primarily during translation). All these phases are coordinated by the driver. To see the exact sequence, look -at the `compile_input` function in [librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/). -The driver (which is found in [librust_driver](https://github.com/rust-lang/rust/tree/master/src/librustc_driver)) -handles all the highest level coordination of compilation - handling command -line arguments, maintaining compilation state (primarily in the `Session`), and -calling the appropriate code to run each phase of compilation. It also handles +at [the `compile_input` function in `librustc_driver`][compile-input]. +The driver handles all the highest level coordination of compilation - handling +command-line arguments, maintaining compilation state (primarily in the `Session`), +and calling the appropriate code to run each phase of compilation. It also handles high level coordination of pretty printing and testing. To create a drop-in compiler replacement or a compiler replacement, we leave most of compilation alone and customise the driver using its APIs. +[compile-input]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/fn.compile_input.html + ## The driver customisation APIs From f25f2989637c0df4985463aa83d41097340c8305 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 5 Apr 2018 15:24:38 -0400 Subject: [PATCH 0183/1812] Fixing the long lines in appendix-stupid-status#100 --- src/appendix-code-index.md | 20 ++++++++++---------- src/appendix-stupid-stats.md | 13 +++++++------ 2 files changed, 17 insertions(+), 16 deletions(-) diff --git a/src/appendix-code-index.md b/src/appendix-code-index.md index 49fe08ee3..62edd0f5b 100644 --- a/src/appendix-code-index.md +++ b/src/appendix-code-index.md @@ -6,17 +6,17 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- -`CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser] | [src/libsyntax/codemap.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/codemap.rs) -`CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_driver/driver.rs) +`CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser] | [src/libsyntax/codemap.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html) +`CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) -`ast::Crate` | struct | Syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/ast.rs) -`hir::Crate` | struct | More abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/hir/mod.rs) -`ParseSess` | struct | This struct contains information about a parsing session | [the Parser] | [src/libsyntax/parse/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/mod.rs) -`Session` | struct | The data associated with a compilation session | [the Parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs) -`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://github.com/rust-lang/rust/blob/master/src/libsyntax/parse/lexer/mod.rs) -`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/trait_def.rs) -`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/mod.rs) -`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules] | [src/librustc/ty/context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/context.rs) +`ast::Crate` | struct | Syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) +`hir::Crate` | struct | More abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) +`ParseSess` | struct | This struct contains information about a parsing session | [the Parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) +`Session` | struct | The data associated with a compilation session | [the Parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) +`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html) +`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) +`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) +`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) [The HIR]: hir.html [The parser]: the-parser.html diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md index 87e2ba6dc..91da6d2a8 100644 --- a/src/appendix-stupid-stats.md +++ b/src/appendix-stupid-stats.md @@ -88,12 +88,13 @@ in [librustc_back](https://github.com/rust-lang/rust/tree/master/src/librustc_ba All these phases are coordinated by the driver. To see the exact sequence, look at [the `compile_input` function in `librustc_driver`][compile-input]. -The driver handles all the highest level coordination of compilation - handling -command-line arguments, maintaining compilation state (primarily in the `Session`), -and calling the appropriate code to run each phase of compilation. It also handles -high level coordination of pretty printing and testing. To create a drop-in -compiler replacement or a compiler replacement, we leave most of compilation -alone and customise the driver using its APIs. +The driver handles all the highest level coordination of compilation - + 1. handling command-line arguments + 2. maintaining compilation state (primarily in the `Session`) + 3. calling the appropriate code to run each phase of compilation + 4. handles high level coordination of pretty printing and testing. +To create a drop-in compiler replacement or a compiler replacement, +we leave most of compilation alone and customise the driver using its APIs. [compile-input]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/fn.compile_input.html From 43341c8894d036a70ebcb782f93da124ba9ae525 Mon Sep 17 00:00:00 2001 From: varkor Date: Thu, 5 Apr 2018 13:24:08 +0100 Subject: [PATCH 0184/1812] Consolidate and fix code blocks --- README.md | 4 +- src/appendix-background.md | 6 +- src/appendix-stupid-stats.md | 16 +-- src/compiletest.md | 3 +- src/conventions.md | 6 +- src/high-level-overview.md | 2 +- src/hir.md | 4 +- src/how-to-build-and-run.md | 8 +- src/incrcomp-debugging.md | 16 +-- src/macro-expansion.md | 6 +- src/method-lookup.md | 15 +-- src/mir-passes.md | 6 +- src/mir-regionck.md | 206 +++++++++++++++++++------------- src/mir-visitor.md | 6 +- src/mir.md | 32 ++--- src/miri.md | 4 +- src/query.md | 24 ++-- src/rustdoc.md | 2 +- src/tests/adding.md | 10 +- src/tests/running.md | 18 +-- src/trait-caching.md | 2 +- src/trait-hrtb.md | 6 +- src/trait-resolution.md | 38 +++--- src/traits-associated-types.md | 38 +++--- src/traits-canonical-queries.md | 70 +++++++---- src/traits-canonicalization.md | 118 +++++++++++------- src/traits-goals-and-clauses.md | 76 +++++++----- src/traits-lowering-module.md | 2 +- src/traits-lowering-rules.md | 116 ++++++++++-------- src/traits-lowering-to-logic.md | 24 ++-- src/ty.md | 14 +-- src/type-checking.md | 4 +- src/type-inference.md | 20 +++- src/variance.md | 88 ++++++++------ 34 files changed, 584 insertions(+), 426 deletions(-) diff --git a/README.md b/README.md index 7e468fbb0..07d1749e8 100644 --- a/README.md +++ b/README.md @@ -30,8 +30,8 @@ To help prevent accidentally introducing broken links, we use the invoke this link checker, otherwise it will emit a warning saying it couldn't be found. -``` -$ cargo install mdbook-linkcheck +```bash +> cargo install mdbook-linkcheck ``` You will need `mdbook` version `>= 0.1`. `linkcheck` will be run automatically when you run `mdbook build`. diff --git a/src/appendix-background.md b/src/appendix-background.md index b49ad6d52..285d74477 100644 --- a/src/appendix-background.md +++ b/src/appendix-background.md @@ -21,7 +21,7 @@ all the remainder. Only at the end of the block is there the possibility of branching to more than one place (in MIR, we call that final statement the **terminator**): -``` +```mir bb0: { statement0; statement1; @@ -34,7 +34,7 @@ bb0: { Many expressions that you are used to in Rust compile down to multiple basic blocks. For example, consider an if statement: -```rust +```rust,ignore a = 1; if some_variable { b = 1; @@ -46,7 +46,7 @@ d = 1; This would compile into four basic blocks: -``` +```mir BB0: { a = 1; if some_variable { goto BB1 } else { goto BB2 } diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md index 91da6d2a8..0c4de5c7a 100644 --- a/src/appendix-stupid-stats.md +++ b/src/appendix-stupid-stats.md @@ -3,7 +3,7 @@ > **Note:** This is a copy of `@nrc`'s amazing [stupid-stats]. You should find > a copy of the code on the GitHub repository although due to the compiler's > constantly evolving nature, there is no guarantee it'll compile on the first -> go. +> go. Many tools benefit from being a drop-in replacement for a compiler. By this, I mean that any user of the tool can use `mytool` in all the ways they would @@ -177,7 +177,7 @@ foo.rs` (assuming you have a Rust program called `foo.rs`. You can also pass any command line arguments that you would normally pass to rustc). When you run it you'll see output similar to -``` +```txt In crate: foo, Found 12 uses of `println!`; @@ -205,7 +205,7 @@ should dump stupid-stats' stdout to Cargo's stdout). Let's start with the `main` function for our tool, it is pretty simple: -``` +```rust,ignore fn main() { let args: Vec<_> = std::env::args().collect(); rustc_driver::run_compiler(&args, &mut StupidCalls::new()); @@ -223,7 +223,7 @@ this tool different from rustc. `StupidCalls` is a mostly empty struct: -``` +```rust,ignore struct StupidCalls { default_calls: RustcDefaultCalls, } @@ -238,7 +238,7 @@ to keep Cargo happy. Most of the rest of the impl of `CompilerCalls` is trivial: -``` +```rust,ignore impl<'a> CompilerCalls<'a> for StupidCalls { fn early_callback(&mut self, _: &getopts::Matches, @@ -300,7 +300,7 @@ tool does it's actual work by walking the AST. We do that by creating an AST visitor and making it walk the AST from the top (the crate root). Once we've walked the crate, we print the stats we've collected: -``` +```rust,ignore fn build_controller(&mut self, _: &Session) -> driver::CompileController<'a> { // We mostly want to do what rustc does, which is what basic() will return. let mut control = driver::CompileController::basic(); @@ -340,7 +340,7 @@ That is all it takes to create your own drop-in compiler replacement or custom compiler! For the sake of completeness I'll go over the rest of the stupid-stats tool. -``` +```rust struct StupidVisitor { println_count: usize, arg_counts: Vec, @@ -355,7 +355,7 @@ methods, these walk the AST taking no action. We override `visit_item` and functions, modules, traits, structs, and so forth, we're only interested in functions) and macros: -``` +```rust,ignore impl<'v> visit::Visitor<'v> for StupidVisitor { fn visit_item(&mut self, i: &'v ast::Item) { match i.node { diff --git a/src/compiletest.md b/src/compiletest.md index 011304d45..363c12d3b 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -61,7 +61,8 @@ which takes a single argument (which, in this case is a value of 1). (rather than the current Rust default of 101 at the time of this writing). The header command and the argument list (if present) are typically separated by a colon: -``` + +```rust,ignore // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. diff --git a/src/conventions.md b/src/conventions.md index 96571301f..89a986789 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -21,7 +21,7 @@ tidy script runs automatically when you do `./x.py test`. All files must begin with the following copyright notice: -``` +```rust // Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. @@ -48,7 +48,7 @@ tests -- it can be necessary to exempt yourself from this limit. In that case, you can add a comment towards the top of the file (after the copyright notice) like so: -``` +```rust // ignore-tidy-linelength ``` @@ -61,7 +61,7 @@ Prefer 4-space indent. # Coding for correctness Beyond formatting, there are a few other tips that are worth -following. +following. ## Prefer exhaustive matches diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 041136548..e369db28c 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -19,7 +19,7 @@ compilation improves, that may change.) The dependency structure of these crates is roughly a diamond: -``` +```txt rustc_driver / | \ / | \ diff --git a/src/hir.md b/src/hir.md index f66468ffc..3d2fbede3 100644 --- a/src/hir.md +++ b/src/hir.md @@ -12,8 +12,8 @@ This chapter covers the main concepts of the HIR. You can view the HIR representation of your code by passing the `-Zunpretty=hir-tree` flag to rustc: -``` -cargo rustc -- -Zunpretty=hir-tree +```bash +> cargo rustc -- -Zunpretty=hir-tree ``` ### Out-of-band storage and the `Crate` type diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 6e292934b..535823dfd 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -70,8 +70,8 @@ Once you've created a config.toml, you are now ready to run `x.py`. There are a lot of options here, but let's start with what is probably the best "go to" command for building a local rust: -``` -./x.py build -i --stage 1 src/libstd +```bash +> ./x.py build -i --stage 1 src/libstd ``` What this command will do is the following: @@ -106,7 +106,7 @@ will execute the stage2 compiler (which we did not build, but which you will likely need to build at some point; for example, if you want to run the entire test suite). -``` +```bash > rustup toolchain link stage1 build//stage1 > rustup toolchain link stage2 build//stage2 ``` @@ -115,7 +115,7 @@ Now you can run the rustc you built with. If you run with `-vV`, you should see a version number ending in `-dev`, indicating a build from your local environment: -``` +```bash > rustc +stage1 -vV rustc 1.25.0-dev binary: rustc diff --git a/src/incrcomp-debugging.md b/src/incrcomp-debugging.md index 261b46eb0..3ad9f3a49 100644 --- a/src/incrcomp-debugging.md +++ b/src/incrcomp-debugging.md @@ -10,7 +10,7 @@ As an example, see `src/test/compile-fail/dep-graph-caller-callee.rs`. The idea is that you can annotate a test like: -```rust +```rust,ignore #[rustc_if_this_changed] fn foo() { } @@ -48,7 +48,7 @@ the graph. You can filter in three ways: To filter, use the `RUST_DEP_GRAPH_FILTER` environment variable, which should look like one of the following: -``` +```txt source_filter // nodes originating from source_filter -> target_filter // nodes that can reach target_filter source_filter -> target_filter // nodes in between source_filter and target_filter @@ -58,14 +58,14 @@ source_filter -> target_filter // nodes in between source_filter and target_filt A node is considered to match a filter if all of those strings appear in its label. So, for example: -``` +```txt RUST_DEP_GRAPH_FILTER='-> TypeckTables' ``` would select the predecessors of all `TypeckTables` nodes. Usually though you want the `TypeckTables` node for some particular fn, so you might write: -``` +```txt RUST_DEP_GRAPH_FILTER='-> TypeckTables & bar' ``` @@ -75,7 +75,7 @@ with `bar` in their name. Perhaps you are finding that when you change `foo` you need to re-type-check `bar`, but you don't think you should have to. In that case, you might do: -``` +```txt RUST_DEP_GRAPH_FILTER='Hir & foo -> TypeckTables & bar' ``` @@ -105,8 +105,10 @@ check of `bar` and you don't think there should be. You dump the dep-graph as described in the previous section and open `dep-graph.txt` to see something like: - Hir(foo) -> Collect(bar) - Collect(bar) -> TypeckTables(bar) +```txt +Hir(foo) -> Collect(bar) +Collect(bar) -> TypeckTables(bar) +``` That first edge looks suspicious to you. So you set `RUST_FORBID_DEP_GRAPH_EDGE` to `Hir&foo -> Collect&bar`, re-run, and diff --git a/src/macro-expansion.md b/src/macro-expansion.md index c55fdd136..ba807faf2 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -15,7 +15,7 @@ expansion works. It's helpful to have an example to refer to. For the remainder of this chapter, whenever we refer to the "example _definition_", we mean the following: -```rust +```rust,ignore macro_rules! printer { (print $mvar:ident) => { println!("{}", $mvar); @@ -45,7 +45,7 @@ worrying about _where_. For more information about tokens, see the Whenever we refer to the "example _invocation_", we mean the following snippet: -```rust +```rust,ignore printer!(print foo); // Assume `foo` is a variable defined somewhere else... ``` @@ -65,7 +65,7 @@ defined in [`src/libsyntax/ext/tt/macro_parser.rs`][code_mp]. The interface of the macro parser is as follows (this is slightly simplified): -```rust +```rust,ignore fn parse( sess: ParserSession, tts: TokenStream, diff --git a/src/method-lookup.md b/src/method-lookup.md index ac0e427db..dbbc62fa8 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -8,13 +8,13 @@ the code itself, naturally. One way to think of method lookup is that we convert an expression of the form: -```rust +```rust,ignore receiver.method(...) ``` into a more explicit [UFCS] form: -```rust +```rust,ignore Trait::method(ADJ(receiver), ...) // for a trait call ReceiverType::method(ADJ(receiver), ...) // for an inherent method call ``` @@ -24,7 +24,7 @@ autoderefs and then possibly an autoref (e.g., `&**receiver`). However we sometimes do other adjustments and coercions along the way, in particular unsizing (e.g., converting from `[T; n]` to `[T]`). -Method lookup is divided into two major phases: +Method lookup is divided into two major phases: 1. Probing ([`probe.rs`][probe]). The probe phase is when we decide what method to call and how to adjust the receiver. @@ -51,7 +51,7 @@ until it cannot be deref'd anymore, as well as applying an optional "unsize" step. So if the receiver has type `Rc>`, this might yield: -```rust +```rust,ignore Rc> Box<[T; 3]> [T; 3] @@ -99,9 +99,10 @@ So, let's continue our example. Imagine that we were calling a method that defines it with `&self` for the type `Rc` as well as a method on the type `Box` that defines `Foo` but with `&mut self`. Then we might have two candidates: - - &Rc> from the impl of `Foo` for `Rc` where `U=Box - &mut Box<[T; 3]>> from the inherent impl on `Box` where `U=[T; 3]` +```txt +&Rc> from the impl of `Foo` for `Rc` where `U=Box +&mut Box<[T; 3]>> from the inherent impl on `Box` where `U=[T; 3]` +``` ### Candidate search diff --git a/src/mir-passes.md b/src/mir-passes.md index 1d1e27df4..fd0c6cca1 100644 --- a/src/mir-passes.md +++ b/src/mir-passes.md @@ -52,13 +52,13 @@ fn main() { The files have names like `rustc.main.000-000.CleanEndRegions.after.mir`. These names have a number of parts: -``` +```txt rustc.main.000-000.CleanEndRegions.after.mir ---- --- --- --------------- ----- either before or after | | | name of the pass | | index of dump within the pass (usually 0, but some passes dump intermediate states) | index of the pass - def-path to the function etc being dumped + def-path to the function etc being dumped ``` You can also make more selective filters. For example, `main & CleanEndRegions` @@ -159,7 +159,7 @@ ensuring that the reads have already happened (remember that [queries are memoized](./query.html), so executing a query twice simply loads from a cache the second time): -``` +```txt mir_const(D) --read-by--> mir_const_qualif(D) | ^ stolen-by | diff --git a/src/mir-regionck.md b/src/mir-regionck.md index 529b42395..949b11d90 100644 --- a/src/mir-regionck.md +++ b/src/mir-regionck.md @@ -34,7 +34,7 @@ The MIR-based region analysis consists of two major functions: are used. - More details to come, though the [NLL RFC] also includes fairly thorough (and hopefully readable) coverage. - + [fvb]: appendix-background.html#free-vs-bound [NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html @@ -82,7 +82,7 @@ The kinds of region elements are as follows: corresponds (intuitively) to some unknown set of other elements -- for details on skolemization, see the section [skolemization and universes](#skol). - + ## Causal tracking *to be written* -- describe how we can extend the values of a variable @@ -97,7 +97,7 @@ The kinds of region elements are as follows: From time to time we have to reason about regions that we can't concretely know. For example, consider this program: -```rust +```rust,ignore // A function that needs a static reference fn foo(x: &'static u32) { } @@ -122,10 +122,12 @@ stack, for example). But *how* do we reject it and *why*? When we type-check `main`, and in particular the call `bar(foo)`, we are going to wind up with a subtyping relationship like this one: - fn(&'static u32) <: for<'a> fn(&'a u32) - ---------------- ------------------- - the type of `foo` the type `bar` expects - +```txt +fn(&'static u32) <: for<'a> fn(&'a u32) +---------------- ------------------- +the type of `foo` the type `bar` expects +``` + We handle this sort of subtyping by taking the variables that are bound in the supertype and **skolemizing** them: this means that we replace them with @@ -135,8 +137,10 @@ regions" -- they represent, basically, "some unknown region". Once we've done that replacement, we have the following relation: - fn(&'static u32) <: fn(&'!1 u32) - +```txt +fn(&'static u32) <: fn(&'!1 u32) +``` + The key idea here is that this unknown region `'!1` is not related to any other regions. So if we can prove that the subtyping relationship is true for `'!1`, then it ought to be true for any region, which is @@ -147,7 +151,9 @@ subtypes, we check if their arguments have the desired relationship (fn arguments are [contravariant](./appendix-background.html#variance), so we swap the left and right here): - &'!1 u32 <: &'static u32 +```txt +&'!1 u32 <: &'static u32 +``` According to the basic subtyping rules for a reference, this will be true if `'!1: 'static`. That is -- if "some unknown region `!1`" lives @@ -168,7 +174,7 @@ put generic type parameters into this root universe (in this sense, there is not just one root universe, but one per item). So consider this function `bar`: -```rust +```rust,ignore struct Foo { } fn bar<'a, T>(t: &'a T) { @@ -185,7 +191,7 @@ Basically, the root universe contains all the names that Now let's extend `bar` a bit by adding a variable `x`: -```rust +```rust,ignore fn bar<'a, T>(t: &'a T) { let x: for<'b> fn(&'b u32) = ...; } @@ -195,7 +201,7 @@ Here, the name `'b` is not part of the root universe. Instead, when we "enter" into this `for<'b>` (e.g., by skolemizing it), we will create a child universe of the root, let's call it U1: -``` +```txt U0 (root universe) │ └─ U1 (child universe) @@ -207,7 +213,7 @@ with a new name, which we are identifying by its universe number: Now let's extend `bar` a bit by adding one more variable, `y`: -```rust +```rust,ignore fn bar<'a, T>(t: &'a T) { let x: for<'b> fn(&'b u32) = ...; let y: for<'c> fn(&'b u32) = ...; @@ -218,7 +224,7 @@ When we enter *this* type, we will again create a new universe, which we'll call `U2`. Its parent will be the root universe, and U1 will be its sibling: -``` +```txt U0 (root universe) │ ├─ U1 (child universe) @@ -257,11 +263,11 @@ children, that inference variable X would have to be in U0. And since X is in U0, it cannot name anything from U1 (or U2). This is perhaps easiest to see by using a kind of generic "logic" example: -``` +```txt exists { forall { ... /* Y is in U1 ... */ } forall { ... /* Z is in U2 ... */ } -} +} ``` Here, the only way for the two foralls to interact would be through X, @@ -290,8 +296,10 @@ does not say region elements **will** appear. In the region inference engine, outlives constraints have the form: - V1: V2 @ P - +```txt +V1: V2 @ P +``` + where `V1` and `V2` are region indices, and hence map to some region variable (which may be universally or existentially quantified). The `P` here is a "point" in the control-flow graph; it's not important @@ -338,8 +346,10 @@ for universal regions from the fn signature.) Put another way, the "universal regions" check can be considered to be checking constraints like: - {skol(1)}: V1 - +```txt +{skol(1)}: V1 +``` + where `{skol(1)}` is like a constant set, and V1 is the variable we made to represent the `!1` region. @@ -348,30 +358,40 @@ made to represent the `!1` region. OK, so far so good. Now let's walk through what would happen with our first example: - fn(&'static u32) <: fn(&'!1 u32) @ P // this point P is not imp't here +```txt +fn(&'static u32) <: fn(&'!1 u32) @ P // this point P is not imp't here +``` The region inference engine will create a region element domain like this: - { CFG; end('static); skol(1) } - --- ------------ ------- from the universe `!1` - | 'static is always in scope - all points in the CFG; not especially relevant here +```txt +{ CFG; end('static); skol(1) } + --- ------------ ------- from the universe `!1` + | 'static is always in scope + all points in the CFG; not especially relevant here +``` It will always create two universal variables, one representing `'static` and one representing `'!1`. Let's call them Vs and V1. They will have initial values like so: - Vs = { CFG; end('static) } // it is in U0, so can't name anything else - V1 = { skol(1) } - +```txt +Vs = { CFG; end('static) } // it is in U0, so can't name anything else +V1 = { skol(1) } +``` + From the subtyping constraint above, we would have an outlives constraint like - '!1: 'static @ P +```txt +'!1: 'static @ P +``` To process this, we would grow the value of V1 to include all of Vs: - Vs = { CFG; end('static) } - V1 = { CFG; end('static), skol(1) } +```txt +Vs = { CFG; end('static) } +V1 = { CFG; end('static), skol(1) } +``` At that point, constraint propagation is complete, because all the outlives relationships are satisfied. Then we would go to the "check @@ -385,34 +405,44 @@ In this case, `V1` *did* grow too large -- it is not known to outlive What about this subtyping relationship? - for<'a> fn(&'a u32, &'a u32) - <: - for<'b, 'c> fn(&'b u32, &'c u32) - -Here we would skolemize the supertype, as before, yielding: +```txt +for<'a> fn(&'a u32, &'a u32) + <: +for<'b, 'c> fn(&'b u32, &'c u32) +``` + +Here we would skolemize the supertype, as before, yielding: + +```txt +for<'a> fn(&'a u32, &'a u32) + <: +fn(&'!1 u32, &'!2 u32) +``` - for<'a> fn(&'a u32, &'a u32) - <: - fn(&'!1 u32, &'!2 u32) - then we instantiate the variable on the left-hand side with an existential in universe U2, yielding the following (`?n` is a notation for an existential variable): - fn(&'?3 u32, &'?3 u32) - <: - fn(&'!1 u32, &'!2 u32) - +```txt +fn(&'?3 u32, &'?3 u32) + <: +fn(&'!1 u32, &'!2 u32) +``` + Then we break this down further: - &'!1 u32 <: &'?3 u32 - &'!2 u32 <: &'?3 u32 - +```txt +&'!1 u32 <: &'?3 u32 +&'!2 u32 <: &'?3 u32 +``` + and even further, yield up our region constraints: - '!1: '?3 - '!2: '?3 - +```txt +'!1: '?3 +'!2: '?3 +``` + Note that, in this case, both `'!1` and `'!2` have to outlive the variable `'?3`, but the variable `'?3` is not forced to outlive anything else. Therefore, it simply starts and ends as the empty set @@ -430,15 +460,17 @@ common lifetime of our arguments. -nmatsakis) [ohdeargoditsallbroken]: https://github.com/rust-lang/rust/issues/32330#issuecomment-202536977 -## Final example +## Final example Let's look at one last example. We'll extend the previous one to have a return type: - for<'a> fn(&'a u32, &'a u32) -> &'a u32 - <: - for<'b, 'c> fn(&'b u32, &'c u32) -> &'b u32 - +```txt +for<'a> fn(&'a u32, &'a u32) -> &'a u32 + <: +for<'b, 'c> fn(&'b u32, &'c u32) -> &'b u32 +``` + Despite seeming very similar to the previous example, this case is going to get an error. That's good: the problem is that we've gone from a fn that promises to return one of its two arguments, to a fn that is promising to return the @@ -446,45 +478,59 @@ first one. That is unsound. Let's see how it plays out. First, we skolemize the supertype: - for<'a> fn(&'a u32, &'a u32) -> &'a u32 - <: - fn(&'!1 u32, &'!2 u32) -> &'!1 u32 - +```txt +for<'a> fn(&'a u32, &'a u32) -> &'a u32 + <: +fn(&'!1 u32, &'!2 u32) -> &'!1 u32 +``` + Then we instantiate the subtype with existentials (in U2): - fn(&'?3 u32, &'?3 u32) -> &'?3 u32 - <: - fn(&'!1 u32, &'!2 u32) -> &'!1 u32 - +```txt +fn(&'?3 u32, &'?3 u32) -> &'?3 u32 + <: +fn(&'!1 u32, &'!2 u32) -> &'!1 u32 +``` + And now we create the subtyping relationships: - &'!1 u32 <: &'?3 u32 // arg 1 - &'!2 u32 <: &'?3 u32 // arg 2 - &'?3 u32 <: &'!1 u32 // return type - +```txt +&'!1 u32 <: &'?3 u32 // arg 1 +&'!2 u32 <: &'?3 u32 // arg 2 +&'?3 u32 <: &'!1 u32 // return type +``` + And finally the outlives relationships. Here, let V1, V2, and V3 be the variables we assign to `!1`, `!2`, and `?3` respectively: - V1: V3 - V2: V3 - V3: V1 - +```txt +V1: V3 +V2: V3 +V3: V1 +``` + Those variables will have these initial values: - V1 in U1 = {skol(1)} - V2 in U2 = {skol(2)} - V3 in U2 = {} - +```txt +V1 in U1 = {skol(1)} +V2 in U2 = {skol(2)} +V3 in U2 = {} +``` + Now because of the `V3: V1` constraint, we have to add `skol(1)` into `V3` (and indeed it is visible from `V3`), so we get: - V3 in U2 = {skol(1)} - +```txt +V3 in U2 = {skol(1)} +``` + then we have this constraint `V2: V3`, so we wind up having to enlarge `V2` to include `skol(1)` (which it can also see): - V2 in U2 = {skol(1), skol(2)} - +```txt +V2 in U2 = {skol(1), skol(2)} +``` + Now contraint propagation is done, but when we check the outlives relationships, we find that `V2` includes this new element `skol(1)`, so we report an error. diff --git a/src/mir-visitor.md b/src/mir-visitor.md index d8b3af497..265769b34 100644 --- a/src/mir-visitor.md +++ b/src/mir-visitor.md @@ -13,7 +13,7 @@ To implement a visitor, you have to create a type that represents your visitor. Typically, this type wants to "hang on" to whatever state you will need while processing MIR: -```rust +```rust,ignore struct MyVisitor<...> { tcx: TyCtxt<'cx, 'tcx, 'tcx>, ... @@ -22,10 +22,10 @@ struct MyVisitor<...> { and you then implement the `Visitor` or `MutVisitor` trait for that type: -```rust +```rust,ignore impl<'tcx> MutVisitor<'tcx> for NoLandingPads { fn visit_foo(&mut self, ...) { - // ... + ... self.super_foo(...); } } diff --git a/src/mir.md b/src/mir.md index 58479cf96..8e45a62bc 100644 --- a/src/mir.md +++ b/src/mir.md @@ -69,12 +69,12 @@ fn main() { You should see something like: -``` +```mir // WARNING: This output format is intended for human consumers only // and is subject to change without notice. Knock yourself out. fn main() -> () { ... -} +} ``` This is the MIR format for the `main` function. @@ -82,7 +82,7 @@ This is the MIR format for the `main` function. **Variable declarations.** If we drill in a bit, we'll see it begins with a bunch of variable declarations. They look like this: -``` +```mir let mut _0: (); // return place scope 1 { let mut _1: std::vec::Vec; // "vec" in scope 1 at src/main.rs:2:9: 2:16 @@ -107,8 +107,8 @@ program (which names were in scope when). it may look slightly different when you view it, and I am ignoring some of the comments): -``` -bb0: { +```mir +bb0: { StorageLive(_1); _1 = const >::new() -> bb2; } @@ -117,7 +117,7 @@ bb0: { A basic block is defined by a series of **statements** and a final **terminator**. In this case, there is one statement: -``` +```mir StorageLive(_1); ``` @@ -129,7 +129,7 @@ allocate stack space. The **terminator** of the block `bb0` is the call to `Vec::new`: -``` +```mir _1 = const >::new() -> bb2; ``` @@ -142,8 +142,8 @@ possible, and hence we list only one succssor block, `bb2`. If we look ahead to `bb2`, we will see it looks like this: -``` -bb2: { +```mir +bb2: { StorageLive(_3); _3 = &mut _1; _2 = const >::push(move _3, const 1i32) -> [return: bb3, unwind: bb4]; @@ -153,13 +153,13 @@ bb2: { Here there are two statements: another `StorageLive`, introducing the `_3` temporary, and then an assignment: -``` +```mir _3 = &mut _1; ``` Assignments in general have the form: -``` +```txt = ``` @@ -169,7 +169,7 @@ value: in this case, the rvalue is a mutable borrow expression, which looks like `&mut `. So we can kind of define a grammar for rvalues like so: -``` +```txt = & (mut)? | + | - @@ -178,7 +178,7 @@ rvalues like so: = Constant | copy Place | move Place -``` +``` As you can see from this grammar, rvalues cannot be nested -- they can only reference places and constants. Moreover, when you use a place, @@ -188,7 +188,7 @@ for a place of any type). So, for example, if we had the expression `x = a + b + c` in Rust, that would get compile to two statements and a temporary: -``` +```mir TMP1 = a + b x = TMP1 + c ``` @@ -214,14 +214,14 @@ but [you can read about those below](#promoted)). we pass around `BasicBlock` values, which are [newtype'd] indices into this vector. - **Statements** are represented by the type `Statement`. -- **Terminators** are represented by the `Terminator`. +- **Terminators** are represented by the `Terminator`. - **Locals** are represented by a [newtype'd] index type `Local`. The data for a local variable is found in the `Mir` (the `local_decls` vector). There is also a special constant `RETURN_PLACE` identifying the special "local" representing the return value. - **Places** are identified by the enum `Place`. There are a few variants: - Local variables like `_1` - - Static variables `FOO` + - Static variables `FOO` - **Projections**, which are fields or other things that "project out" from a base place. So e.g. the place `_1.f` is a projection, with `f` being the "projection element and `_1` being the base diff --git a/src/miri.md b/src/miri.md index 4b0a600be..fb6675f50 100644 --- a/src/miri.md +++ b/src/miri.md @@ -14,7 +14,7 @@ placed into metadata. Once you have a use-site like -```rust +```rust,ignore type Foo = [u8; FOO - 42]; ``` @@ -24,7 +24,7 @@ create items that use the type (locals, constants, function arguments, ...). To obtain the (in this case empty) parameter environment, one can call `let param_env = tcx.param_env(length_def_id);`. The `GlobalId` needed is -```rust +```rust,ignore let gid = GlobalId { promoted: None, instance: Instance::mono(length_def_id), diff --git a/src/query.md b/src/query.md index e3c554049..2c518ee55 100644 --- a/src/query.md +++ b/src/query.md @@ -41,7 +41,7 @@ To invoke a query is simple. The tcx ("type context") offers a method for each defined query. So, for example, to invoke the `type_of` query, you would just do this: -```rust +```rust,ignore let ty = tcx.type_of(some_def_id); ``` @@ -59,7 +59,7 @@ better user experience. In order to recover from a cycle, you don't get to use the nice method-call-style syntax. Instead, you invoke using the `try_get` method, which looks roughly like this: -```rust +```rust,ignore use ty::maps::queries; ... match queries::type_of::try_get(tcx, DUMMY_SP, self.did) { @@ -87,7 +87,7 @@ will be reported due to this cycle by some other bit of code. In that case, you can invoke `err.cancel()` to not emit any error. It is traditional to then invoke: -``` +```rust,ignore tcx.sess.delay_span_bug(some_span, "some message") ``` @@ -126,7 +126,7 @@ on how that works). Providers always have the same signature: -```rust +```rust,ignore fn provider<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx, 'tcx>, key: QUERY_KEY) -> QUERY_RESULT @@ -146,7 +146,7 @@ When the tcx is created, it is given the providers by its creator using the `Providers` struct. This struct is generated by the macros here, but it is basically a big list of function pointers: -```rust +```rust,ignore struct Providers { type_of: for<'cx, 'tcx> fn(TyCtxt<'cx, 'tcx, 'tcx>, DefId) -> Ty<'tcx>, ... @@ -163,7 +163,7 @@ throughout the other `rustc_*` crates. This is done by invoking various `provide` functions. These functions tend to look something like this: -```rust +```rust,ignore pub fn provide(providers: &mut Providers) { *providers = Providers { type_of, @@ -180,7 +180,7 @@ before.) So, if we want to add a provider for some other query, let's call it `fubar`, into the crate above, we might modify the `provide()` function like so: -```rust +```rust,ignore pub fn provide(providers: &mut Providers) { *providers = Providers { type_of, @@ -189,7 +189,7 @@ pub fn provide(providers: &mut Providers) { }; } -fn fubar<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx>, key: DefId) -> Fubar<'tcx> { .. } +fn fubar<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx>, key: DefId) -> Fubar<'tcx> { ... } ``` N.B. Most of the `rustc_*` crates only provide **local @@ -218,7 +218,7 @@ something like: [maps-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/maps/index.html -``` +```rust,ignore define_maps! { <'tcx> /// Records the type of every item. [] fn type_of: TypeOfItem(DefId) -> Ty<'tcx>, @@ -229,7 +229,7 @@ define_maps! { <'tcx> Each line of the macro defines one query. The name is broken up like this: -``` +```rust,ignore [] fn type_of: TypeOfItem(DefId) -> Ty<'tcx>, ^^ ^^^^^^^ ^^^^^^^^^^ ^^^^^ ^^^^^^^^ | | | | | @@ -288,7 +288,7 @@ describing the query. Each such struct implements the key/value of that particular query. Basically the code generated looks something like this: -```rust +```rust,ignore // Dummy struct representing a particular kind of query: pub struct type_of<'tcx> { phantom: PhantomData<&'tcx ()> } @@ -306,7 +306,7 @@ this trait is optional if the query key is `DefId`, but if you *don't* implement it, you get a pretty generic error ("processing `foo`..."). You can put new impls into the `config` module. They look something like this: -```rust +```rust,ignore impl<'tcx> QueryDescription for queries::type_of<'tcx> { fn describe(tcx: TyCtxt, key: DefId) -> String { format!("computing the type of `{}`", tcx.item_path_str(key)) diff --git a/src/rustdoc.md b/src/rustdoc.md index e075087fc..36195c3a5 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -70,7 +70,7 @@ The main process of crate crawling is done in `clean/mod.rs` through several implementations of the `Clean` trait defined within. This is a conversion trait, which defines one method: -```rust +```rust,ignore pub trait Clean { fn clean(&self, cx: &DocContext) -> T; } diff --git a/src/tests/adding.md b/src/tests/adding.md index f777a458c..f97f4a57e 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -100,7 +100,7 @@ are normally put after the short comment that explains the point of this test. For example, this test uses the `// compile-flags` command to specify a custom flag to give to rustc when the test is compiled: -```rust +```rust,ignore // Copyright 2017 The Rust Project Developers. blah blah blah. // ... // except according to those terms. @@ -198,7 +198,7 @@ incremental, though incremental tests are somewhat different). Revisions allow a single test file to be used for multiple tests. This is done by adding a special header at the top of the file: -``` +```rust // revisions: foo bar baz ``` @@ -211,7 +211,7 @@ You can also customize headers and expected error messages to a particular revision. To do this, add `[foo]` (or `bar`, `baz`, etc) after the `//` comment, like so: -``` +```rust // A flag to pass in only for cfg `foo`: //[foo]compile-flags: -Z verbose @@ -284,7 +284,7 @@ between platforms, mainly about filenames: Sometimes these built-in normalizations are not enough. In such cases, you may provide custom normalization rules using the header commands, e.g. -``` +```rust // normalize-stdout-test: "foo" -> "bar" // normalize-stderr-32bit: "fn\(\) \(32 bits\)" -> "fn\(\) \($$PTR bits\)" // normalize-stderr-64bit: "fn\(\) \(64 bits\)" -> "fn\(\) \($$PTR bits\)" @@ -298,7 +298,7 @@ default regex flavor provided by `regex` crate. The corresponding reference file will use the normalized output to test both 32-bit and 64-bit platforms: -``` +```txt ... | = note: source type: fn() ($PTR bits) diff --git a/src/tests/running.md b/src/tests/running.md index 4e8c71590..03eb8ccc4 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -3,8 +3,8 @@ You can run the tests using `x.py`. The most basic command -- which you will almost never want to use! -- is as follows: -``` -./x.py test +```bash +> ./x.py test ``` This will build the full stage 2 compiler and then run the whole test @@ -17,7 +17,7 @@ The test results are cached and previously successful tests are `ignored` during testing. The stdout/stderr contents as well as a timestamp file for every test can be found under `build/ARCH/test/`. To force-rerun a test (e.g. in case the test runner fails to notice -a change) you can simply remove the timestamp file. +a change) you can simply remove the timestamp file. ## Running a subset of the test suites @@ -27,7 +27,7 @@ test" that can be used after modifying rustc to see if things are generally working correctly would be the following: ```bash -./x.py test --stage 1 src/test/{ui,compile-fail,run-pass} +> ./x.py test --stage 1 src/test/{ui,compile-fail,run-pass} ``` This will run the `ui`, `compile-fail`, and `run-pass` test suites, @@ -37,7 +37,7 @@ example, if you are hacking on debuginfo, you may be better off with the debuginfo test suite: ```bash -./x.py test --stage 1 src/test/debuginfo +> ./x.py test --stage 1 src/test/debuginfo ``` **Warning:** Note that bors only runs the tests with the full stage 2 @@ -51,8 +51,8 @@ Another common thing that people want to do is to run an **individual test**, often the test they are trying to fix. One way to do this is to invoke `x.py` with the `--test-args` option: -``` -./x.py test --stage 1 src/test/ui --test-args issue-1234 +```bash +> ./x.py test --stage 1 src/test/ui --test-args issue-1234 ``` Under the hood, the test runner invokes the standard rust test runner @@ -62,8 +62,8 @@ filtering for tests that include "issue-1234" in the name. Often, though, it's easier to just run the test by hand. Most tests are just `rs` files, so you can do something like -``` -rustc +stage1 src/test/ui/issue-1234.rs +```bash +> rustc +stage1 src/test/ui/issue-1234.rs ``` This is much faster, but doesn't always work. For example, some tests diff --git a/src/trait-caching.md b/src/trait-caching.md index 4c728d521..4b7d7e096 100644 --- a/src/trait-caching.md +++ b/src/trait-caching.md @@ -26,7 +26,7 @@ possible impl is this one, with def-id 22: [selection process]: ./trait-resolution.html#selection -```rust +```rust,ignore impl Foo for usize { ... } // Impl #22 ``` diff --git a/src/trait-hrtb.md b/src/trait-hrtb.md index d677db2c5..7f77f274c 100644 --- a/src/trait-hrtb.md +++ b/src/trait-hrtb.md @@ -18,14 +18,14 @@ trait Foo { Let's say we have a function `want_hrtb` that wants a type which implements `Foo<&'a isize>` for any `'a`: -```rust +```rust,ignore fn want_hrtb() where T : for<'a> Foo<&'a isize> { ... } ``` Now we have a struct `AnyInt` that implements `Foo<&'a isize>` for any `'a`: -```rust +```rust,ignore struct AnyInt; impl<'a> Foo<&'a isize> for AnyInt { } ``` @@ -71,7 +71,7 @@ set for `'0` is `{'0, '$a}`, and hence the check will succeed. Let's consider a failure case. Imagine we also have a struct -```rust +```rust,ignore struct StaticInt; impl Foo<&'static isize> for StaticInt; ``` diff --git a/src/trait-resolution.md b/src/trait-resolution.md index 7494d969a..5bf8f8716 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -13,13 +13,13 @@ see [*this* traits chapter](./traits.html). Trait resolution is the process of pairing up an impl with each reference to a trait. So, for example, if there is a generic function like: -```rust -fn clone_slice(x: &[T]) -> Vec { /*...*/ } +```rust,ignore +fn clone_slice(x: &[T]) -> Vec { ... } ``` and then a call to that function: -```rust +```rust,ignore let v: Vec = clone_slice(&[1, 2, 3]) ``` @@ -30,7 +30,7 @@ Note that in some cases, like generic functions, we may not be able to find a specific impl, but we can figure out that the caller must provide an impl. For example, consider the body of `clone_slice`: -```rust +```rust,ignore fn clone_slice(x: &[T]) -> Vec { let mut v = Vec::new(); for e in &x { @@ -143,7 +143,7 @@ otherwise the result is considered ambiguous. This process is easier if we work through some examples. Consider the following trait: -```rust +```rust,ignore trait Convert { fn convert(&self) -> Target; } @@ -154,14 +154,14 @@ converts from the (implicit) `Self` type to the `Target` type. If we wanted to permit conversion between `isize` and `usize`, we might implement `Convert` like so: -```rust -impl Convert for isize { /*...*/ } // isize -> usize -impl Convert for usize { /*...*/ } // usize -> isize +```rust,ignore +impl Convert for isize { ... } // isize -> usize +impl Convert for usize { ... } // usize -> isize ``` Now imagine there is some code like the following: -```rust +```rust,ignore let x: isize = ...; let y = x.convert(); ``` @@ -186,7 +186,7 @@ inference? But what happens if there are multiple impls where all the types unify? Consider this example: -```rust +```rust,ignore trait Get { fn get(&self) -> Self; } @@ -224,11 +224,11 @@ the same trait (or some subtrait) and which can match against the obligation. Consider this simple example: -```rust +```rust,ignore trait A1 { fn do_a1(&self); } -trait A2 : A1 { /*...*/ } +trait A2 : A1 { ... } trait B { fn do_b(&self); @@ -256,13 +256,13 @@ values found in the obligation, possibly yielding a type error. Suppose we have the following variation of the `Convert` example in the previous section: -```rust +```rust,ignore trait Convert { fn convert(&self) -> Target; } -impl Convert for isize { /*...*/ } // isize -> usize -impl Convert for usize { /*...*/ } // usize -> isize +impl Convert for isize { ... } // isize -> usize +impl Convert for usize { ... } // usize -> isize let x: isize = ...; let y: char = x.convert(); // NOTE: `y: char` now! @@ -296,11 +296,11 @@ everything out. Here is an example: -```rust -trait Foo { /*...*/ } -impl> Foo for Vec { /*...*/ } +```rust,ignore +trait Foo { ... } +impl> Foo for Vec { ... } -impl Bar for isize { /*...*/ } +impl Bar for isize { ... } ``` After one shallow round of selection for an obligation like `Vec diff --git a/src/traits-associated-types.md b/src/traits-associated-types.md index c91dc255f..bcf6b48ea 100644 --- a/src/traits-associated-types.md +++ b/src/traits-associated-types.md @@ -29,10 +29,10 @@ that is, simplified -- based on the types given in an impl. So, to continue with our example, the impl of `IntoIterator` for `Option` declares (among other things) that `Item = T`: -```rust +```rust,ignore impl IntoIterator for Option { type Item = T; - .. + ... } ``` @@ -51,9 +51,11 @@ In our logic, normalization is defined by a predicate impls. For example, the `impl` of `IntoIterator` for `Option` that we saw above would be lowered to a program clause like so: - forall { - Normalize( as IntoIterator>::Item -> T) - } +```txt +forall { + Normalize( as IntoIterator>::Item -> T) +} +``` (An aside: since we do not permit quantification over traits, this is really more like a family of predicates, one for each associated @@ -67,7 +69,7 @@ we've seen so far. Sometimes however we want to work with associated types that cannot be normalized. For example, consider this function: -```rust +```rust,ignore fn foo(...) { ... } ``` @@ -99,20 +101,24 @@ consider an associated type projection equal to another type?": We now introduce the `ProjectionEq` predicate to bring those two cases together. The `ProjectionEq` predicate looks like so: - ProjectionEq(::Item = U) +```txt +ProjectionEq(::Item = U) +``` and we will see that it can be proven *either* via normalization or skolemization. As part of lowering an associated type declaration from some trait, we create two program clauses for `ProjectionEq`: - forall { - ProjectionEq(::Item = U) :- - Normalize(::Item -> U) - } +```txt +forall { + ProjectionEq(::Item = U) :- + Normalize(::Item -> U) +} - forall { - ProjectionEq(::Item = (IntoIterator::Item)) - } +forall { + ProjectionEq(::Item = (IntoIterator::Item)) +} +``` These are the only two `ProjectionEq` program clauses we ever make for any given associated item. @@ -124,7 +130,9 @@ with unification. As described in the [type inference](./type-inference.html) section, unification is basically a procedure with a signature like this: - Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution> +```txt +Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution> +``` In other words, we try to unify two things A and B. That procedure might just fail, in which case we get back `Err(NoSolution)`. This diff --git a/src/traits-canonical-queries.md b/src/traits-canonical-queries.md index b291a2898..99916267d 100644 --- a/src/traits-canonical-queries.md +++ b/src/traits-canonical-queries.md @@ -19,12 +19,16 @@ In a traditional Prolog system, when you start a query, the solver will run off and start supplying you with every possible answer it can find. So given something like this: - ?- Vec: AsRef +```txt +?- Vec: AsRef +``` The solver might answer: - Vec: AsRef<[i32]> - continue? (y/n) +```txt +Vec: AsRef<[i32]> + continue? (y/n) +``` This `continue` bit is interesting. The idea in Prolog is that the solver is finding **all possible** instantiations of your query that @@ -35,34 +39,42 @@ response with our original query -- Rust's solver gives back a substitution instead). If we were to hit `y`, the solver might then give us another possible answer: - Vec: AsRef> - continue? (y/n) +```txt +Vec: AsRef> + continue? (y/n) +``` This answer derives from the fact that there is a reflexive impl (`impl AsRef for T`) for `AsRef`. If were to hit `y` again, then we might get back a negative response: - no +```txt +no +``` Naturally, in some cases, there may be no possible answers, and hence the solver will just give me back `no` right away: - ?- Box: Copy - no +```txt +?- Box: Copy + no +``` In some cases, there might be an infinite number of responses. So for example if I gave this query, and I kept hitting `y`, then the solver would never stop giving me back answers: - ?- Vec: Clone - Vec: Clone - continue? (y/n) - Vec>: Clone - continue? (y/n) - Vec>>: Clone - continue? (y/n) - Vec>>>: Clone - continue? (y/n) +```txt +?- Vec: Clone + Vec: Clone + continue? (y/n) + Vec>: Clone + continue? (y/n) + Vec>>: Clone + continue? (y/n) + Vec>>>: Clone + continue? (y/n) +``` As you can imagine, the solver will gleefully keep adding another layer of `Box` until we ask it to stop, or it runs out of memory. @@ -70,12 +82,16 @@ layer of `Box` until we ask it to stop, or it runs out of memory. Another interesting thing is that queries might still have variables in them. For example: - ?- Rc: Clone +```txt +?- Rc: Clone +``` might produce the answer: - Rc: Clone - continue? (y/n) +```txt +Rc: Clone + continue? (y/n) +``` After all, `Rc` is true **no matter what type `?T` is**. @@ -132,7 +148,7 @@ impls; among them, there are these two (for clarify, I've written the [borrow]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html -```rust +```rust,ignore impl Borrow for T where T: ?Sized impl Borrow<[T]> for Vec where T: Sized ``` @@ -140,7 +156,7 @@ impl Borrow<[T]> for Vec where T: Sized **Example 1.** Imagine we are type-checking this (rather artificial) bit of code: -```rust +```rust,ignore fn foo(a: A, vec_b: Option) where A: Borrow { } fn main() { @@ -185,7 +201,7 @@ other sources, in which case we can try the trait query again. **Example 2.** We can now extend our previous example a bit, and assign a value to `u`: -```rust +```rust,ignore fn foo(a: A, vec_b: Option) where A: Borrow { } fn main() { @@ -210,11 +226,15 @@ Let's suppose that the type checker decides to revisit the Borrow`. `?U` is no longer an unbound inference variable; it now has a value, `Vec`. So, if we "refresh" the query with that value, we get: - Vec: Borrow> +```txt +Vec: Borrow> +``` This time, there is only one impl that applies, the reflexive impl: - impl Borrow for T where T: ?Sized +```txt +impl Borrow for T where T: ?Sized +``` Therefore, the trait checker will answer: diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index 9f3af36c9..576ca2055 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -42,14 +42,18 @@ This query contains two unbound variables, but it also contains the lifetime `'static`. The trait system generally ignores all lifetimes and treats them equally, so when canonicalizing, we will *also* replace any [free lifetime](./appendix-background.html#free-vs-bound) with a -canonical variable. Therefore, we get the following result: +canonical variable. Therefore, we get the following result: - ?0: Foo<'?1, ?2> - -Sometimes we write this differently, like so: +```txt +?0: Foo<'?1, ?2> +``` + +Sometimes we write this differently, like so: + +```txt +for { ?0: Foo<'?1, ?2> } +``` - for { ?0: Foo<'?1, ?2> } - This `for<>` gives some information about each of the canonical variables within. In this case, each `T` indicates a type variable, so `?0` and `?2` are types; the `L` indicates a lifetime varibale, so @@ -57,8 +61,10 @@ so `?0` and `?2` are types; the `L` indicates a lifetime varibale, so `CanonicalVarValues` array OV with the "original values" for each canonicalized variable: - [?A, 'static, ?B] - +```txt +[?A, 'static, ?B] +``` + We'll need this vector OV later, when we process the query response. ## Executing the query @@ -70,18 +76,24 @@ we create a substitution S from the canonical form containing a fresh inference variable (of suitable kind) for each canonical variable. So, for our example query: - for { ?0: Foo<'?1, ?2> } +```txt +for { ?0: Foo<'?1, ?2> } +``` the substitution S might be: - S = [?A, '?B, ?C] - +```txt +S = [?A, '?B, ?C] +``` + We can then replace the bound canonical variables (`?0`, etc) with these inference variables, yielding the following fully instantiated query: - ?A: Foo<'?B, ?C> - +```txt +?A: Foo<'?B, ?C> +``` + Remember that substitution S though! We're going to need it later. OK, now that we have a fresh inference context and an instantiated @@ -93,7 +105,7 @@ created. For example, if there were only one impl of `Foo`, like so: [cqqr]: ./traits-canonical-queries.html#query-response -``` +```rust,ignore impl<'a, X> Foo<'a, X> for Vec where X: 'a { ... } @@ -123,39 +135,49 @@ result substitution `var_values`, and some region constraints. To create this, we wind up re-using the substitution S that we created when first instantiating our query. To refresh your memory, we had a query - for { ?0: Foo<'?1, ?2> } +```txt +for { ?0: Foo<'?1, ?2> } +``` for which we made a substutition S: - S = [?A, '?B, ?C] - +```txt +S = [?A, '?B, ?C] +``` + We then did some work which unified some of those variables with other things. If we "refresh" S with the latest results, we get: - S = [Vec, '?D, ?E] - +```txt +S = [Vec, '?D, ?E] +``` + These are precisely the new values for the three input variables from our original query. Note though that they include some new variables (like `?E`). We can make those go away by canonicalizing again! We don't just canonicalize S, though, we canonicalize the whole query response QR: - QR = { - certainty: Proven, // or whatever - var_values: [Vec, '?D, ?E] // this is S - region_constraints: [?E: '?D], // from the impl - value: (), // for our purposes, just (), but - // in some cases this might have - // a type or other info - } +```txt +QR = { + certainty: Proven, // or whatever + var_values: [Vec, '?D, ?E] // this is S + region_constraints: [?E: '?D], // from the impl + value: (), // for our purposes, just (), but + // in some cases this might have + // a type or other info +} +``` The result would be as follows: - Canonical(QR) = for { - certainty: Proven, - var_values: [Vec, '?1, ?2] - region_constraints: [?2: '?1], - value: (), - } +```txt +Canonical(QR) = for { + certainty: Proven, + var_values: [Vec, '?1, ?2] + region_constraints: [?2: '?1], + value: (), +} +``` (One subtle point: when we canonicalize the query **result**, we do not use any special treatment for free lifetimes. Note that both @@ -172,20 +194,26 @@ In the previous section we produced a canonical query result. We now have to apply that result in our original context. If you recall, way back in the beginning, we were trying to prove this query: - ?A: Foo<'static, ?B> - +```txt +?A: Foo<'static, ?B> +``` + We canonicalized that into this: - for { ?0: Foo<'?1, ?2> } +```txt +for { ?0: Foo<'?1, ?2> } +``` and now we got back a canonical response: - for { - certainty: Proven, - var_values: [Vec, '?1, ?2] - region_constraints: [?2: '?1], - value: (), - } +```txt +for { + certainty: Proven, + var_values: [Vec, '?1, ?2] + region_constraints: [?2: '?1], + value: (), +} +``` We now want to apply that response to our context. Conceptually, how we do that is to (a) instantiate each of the canonical variables in @@ -193,19 +221,19 @@ the result with a fresh inference variable, (b) unify the values in the result with the original values, and then (c) record the region constraints for later. Doing step (a) would yield a result of -``` +```txt { certainty: Proven, var_values: [Vec, '?D, ?C] ^^ ^^^ fresh inference variables region_constraints: [?C: '?D], value: (), -} +} ``` Step (b) would then unify: -``` +```txt ?A with Vec 'static with '?D ?B with ?C diff --git a/src/traits-goals-and-clauses.md b/src/traits-goals-and-clauses.md index 8e5e82d01..97532195e 100644 --- a/src/traits-goals-and-clauses.md +++ b/src/traits-goals-and-clauses.md @@ -12,22 +12,24 @@ a few new superpowers. In Rust's solver, **goals** and **clauses** have the following forms (note that the two definitions reference one another): - Goal = DomainGoal // defined in the section below - | Goal && Goal - | Goal || Goal - | exists { Goal } // existential quantification - | forall { Goal } // universal quantification - | if (Clause) { Goal } // implication - | true // something that's trivially true - | ambiguous // something that's never provable - - Clause = DomainGoal - | Clause :- Goal // if can prove Goal, then Clause is true - | Clause && Clause - | forall { Clause } - - K = // a "kind" - | +```txt +Goal = DomainGoal // defined in the section below + | Goal && Goal + | Goal || Goal + | exists { Goal } // existential quantification + | forall { Goal } // universal quantification + | if (Clause) { Goal } // implication + | true // something that's trivially true + | ambiguous // something that's never provable + +Clause = DomainGoal + | Clause :- Goal // if can prove Goal, then Clause is true + | Clause && Clause + | forall { Clause } + +K = // a "kind" + | +``` The proof procedure for these sorts of goals is actually quite straightforward. Essentially, it's a form of depth-first search. The @@ -47,8 +49,10 @@ To define the set of *domain goals* in our system, we need to first introduce a few simple formulations. A **trait reference** consists of the name of a trait along with a suitable set of inputs P0..Pn: - TraitRef = P0: TraitName - +```txt +TraitRef = P0: TraitName +``` + So, for example, `u32: Display` is a trait reference, as is `Vec: IntoIterator`. Note that Rust surface syntax also permits some extra things, like associated type bindings (`Vec: IntoIterator`), that are not part of a trait reference. A **projection** consists of an associated item reference along with its inputs P0..Pm: - Projection = >::AssocItem +```txt +Projection = >::AssocItem +``` Given that, we can define a `DomainGoal` as follows: - DomainGoal = Implemented(TraitRef) - | ProjectionEq(Projection = Type) - | Normalize(Projection -> Type) - | FromEnv(TraitRef) - | FromEnv(Projection = Type) - | WellFormed(Type) - | WellFormed(TraitRef) - | WellFormed(Projection = Type) - | Outlives(Type, Region) - | Outlives(Region, Region) +```txt +DomainGoal = Implemented(TraitRef) + | ProjectionEq(Projection = Type) + | Normalize(Projection -> Type) + | FromEnv(TraitRef) + | FromEnv(Projection = Type) + | WellFormed(Type) + | WellFormed(TraitRef) + | WellFormed(Projection = Type) + | Outlives(Type, Region) + | Outlives(Region, Region) +``` - `Implemented(TraitRef)` -- true if the given trait is implemented for the given input types and lifetimes @@ -104,9 +112,11 @@ Given that, we can define a `DomainGoal` as follows: Most goals in our system are "inductive". In an inductive goal, circular reasoning is disallowed. Consider this example clause: +```txt Implemented(Foo: Bar) :- Implemented(Foo: Bar). - +``` + Considered inductively, this clause is useless: if we are trying to prove `Implemented(Foo: Bar)`, we would then recursively have to prove `Implemented(Foo: Bar)`, and that cycle would continue ad infinitum @@ -130,8 +140,10 @@ struct Foo { The default rules for auto traits say that `Foo` is `Send` if the types of its fields are `Send`. Therefore, we would have a rule like - Implemented(Foo: Send) :- - Implemented(Option>: Send). +```txt +Implemented(Foo: Send) :- + Implemented(Option>: Send). +``` As you can probably imagine, proving that `Option>: Send` is going to wind up circularly requiring us to prove that `Foo: Send` diff --git a/src/traits-lowering-module.md b/src/traits-lowering-module.md index 27c4f29bc..fa068f86a 100644 --- a/src/traits-lowering-module.md +++ b/src/traits-lowering-module.md @@ -49,7 +49,7 @@ standard [ui test] mechanisms to check them. In this case, there is a need only be a prefix of the error), but [the stderr file] contains the full details: -``` +```txt error: Implemented(T: Foo) :- ProjectionEq(::Item == i32), TypeOutlives(T \ : 'static), Implemented(T: std::iter::Iterator), Implemented(T: std::marker::Sized). --> $DIR/lower_impl.rs:15:1 diff --git a/src/traits-lowering-rules.md b/src/traits-lowering-rules.md index 544ae41b3..1a9717f9f 100644 --- a/src/traits-lowering-rules.md +++ b/src/traits-lowering-rules.md @@ -67,7 +67,7 @@ but Chalk isn't modeling those right now. Given a trait definition -```rust +```rust,ignore trait Trait // P0 == Self where WC { @@ -87,10 +87,12 @@ relationships between different kinds of domain goals. The first such rule from the trait header creates the mapping between the `FromEnv` and `Implemented` predicates: - // Rule Implemented-From-Env - forall { - Implemented(Self: Trait) :- FromEnv(Self: Trait) - } +```txt +// Rule Implemented-From-Env +forall { + Implemented(Self: Trait) :- FromEnv(Self: Trait) +} +``` @@ -101,17 +103,19 @@ The next few clauses have to do with implied bounds (see also [RFC 2089]: https://rust-lang.github.io/rfcs/2089-implied-bounds.html - // Rule Implied-Bound-From-Trait - // - // For each where clause WC: - forall { - FromEnv(WC) :- FromEnv(Self: Trait { + FromEnv(WC) :- FromEnv(Self: Trait // P0 == Self where WC { @@ -190,39 +194,43 @@ where WC We will produce a number of program clauses. The first two define the rules by which `ProjectionEq` can succeed; these two clauses are discussed -in detail in the [section on associated types](./traits-associated-types.html),, +in detail in the [section on associated types](./traits-associated-types.html), but reproduced here for reference: - // Rule ProjectionEq-Normalize - // - // ProjectionEq can succeed by normalizing: - forall { - ProjectionEq(>::AssocType = U) :- - Normalize(>::AssocType -> U) - } - - // Rule ProjectionEq-Skolemize - // - // ProjectionEq can succeed by skolemizing, see "associated type" - // chapter for more: - forall { - ProjectionEq( - >::AssocType = - (Trait::AssocType) - ) :- - // But only if the trait is implemented, and the conditions from - // the associated type are met as well: - Implemented(Self: Trait) - && WC1 - } +```txt + // Rule ProjectionEq-Normalize + // + // ProjectionEq can succeed by normalizing: + forall { + ProjectionEq(>::AssocType = U) :- + Normalize(>::AssocType -> U) + } + + // Rule ProjectionEq-Skolemize + // + // ProjectionEq can succeed by skolemizing, see "associated type" + // chapter for more: + forall { + ProjectionEq( + >::AssocType = + (Trait::AssocType) + ) :- + // But only if the trait is implemented, and the conditions from + // the associated type are met as well: + Implemented(Self: Trait) + && WC1 + } +``` The next rule covers implied bounds for the projection. In particular, the `Bounds` declared on the associated type must be proven to hold to show that the impl is well-formed, and hence we can rely on them elsewhere. - // XXX how exactly should we set this up? Have to be careful; - // presumably this has to be a kind of `FromEnv` setup. +```txt +// XXX how exactly should we set this up? Have to be careful; +// presumably this has to be a kind of `FromEnv` setup. +``` ### Lowering function and constant declarations @@ -234,7 +242,7 @@ values below](#constant-vals) for more details. Given an impl of a trait: -```rust +```rust,ignore impl Trait for A0 where WC { @@ -245,10 +253,12 @@ where WC Let `TraitRef` be the trait reference `A0: Trait`. Then we will create the following rules: - // Rule Implemented-From-Impl - forall { - Implemented(TraitRef) :- WC - } +```txt +// Rule Implemented-From-Impl +forall { + Implemented(TraitRef) :- WC +} +``` In addition, we will lower all of the *impl items*. @@ -258,7 +268,7 @@ In addition, we will lower all of the *impl items*. Given an impl that contains: -```rust +```rust,ignore impl Trait for A0 where WC { @@ -268,13 +278,15 @@ where WC We produce the following rule: - // Rule Normalize-From-Impl - forall { - forall { - Normalize(>::AssocType -> T) :- - WC && WC1 - } - } +```txt +// Rule Normalize-From-Impl +forall { + forall { + Normalize(>::AssocType -> T) :- + WC && WC1 + } +} +``` Note that `WC` and `WC1` both encode where-clauses that the impl can rely on. diff --git a/src/traits-lowering-to-logic.md b/src/traits-lowering-to-logic.md index 4e4e7cae9..f36794d2c 100644 --- a/src/traits-lowering-to-logic.md +++ b/src/traits-lowering-to-logic.md @@ -30,7 +30,7 @@ impl Clone for Vec where T: Clone { } We could map these declarations to some Horn clauses, written in a Prolog-like notation, as follows: -``` +```txt Clone(usize). Clone(Vec) :- Clone(?T). @@ -51,18 +51,18 @@ so by applying the rules recursively: - `Clone(Vec>)` is provable if: - `Clone(Vec)` is provable if: - `Clone(usize)` is provable. (Which is is, so we're all good.) - + But now suppose we tried to prove that `Clone(Vec)`. This would fail (after all, I didn't give an impl of `Clone` for `Bar`): - `Clone(Vec)` is provable if: - `Clone(Bar)` is provable. (But it is not, as there are no applicable rules.) - + We can easily extend the example above to cover generic traits with more than one input type. So imagine the `Eq` trait, which declares that `Self` is equatable with a value of type `T`: -```rust +```rust,ignore trait Eq { ... } impl Eq for usize { } impl> Eq> for Vec { } @@ -70,12 +70,12 @@ impl> Eq> for Vec { } That could be mapped as follows: -``` +```txt Eq(usize, usize). Eq(Vec, Vec) :- Eq(?T, ?U). ``` -So far so good. +So far so good. ## Type-checking normal functions @@ -90,7 +90,7 @@ that we need to prove, and those come from type-checking. Consider type-checking the function `foo()` here: -```rust +```rust,ignore fn foo() { bar::() } fn bar>() { } ``` @@ -105,7 +105,7 @@ If we wanted, we could write a Prolog predicate that defines the conditions under which `bar()` can be called. We'll say that those conditions are called being "well-formed": -``` +```txt barWellFormed(?U) :- Eq(?U, ?U). ``` @@ -113,7 +113,7 @@ Then we can say that `foo()` type-checks if the reference to `bar::` (that is, `bar()` applied to the type `usize`) is well-formed: -``` +```txt fooTypeChecks :- barWellFormed(usize). ``` @@ -122,7 +122,7 @@ If we try to prove the goal `fooTypeChecks`, it will succeed: - `fooTypeChecks` is provable if: - `barWellFormed(usize)`, which is provable if: - `Eq(usize, usize)`, which is provable because of an impl. - + Ok, so far so good. Let's move on to type-checking a more complex function. ## Type-checking generic functions: beyond Horn clauses @@ -134,7 +134,7 @@ a generic function, it turns out we need a stronger notion of goal than Prolog can be provide. To see what I'm talking about, let's revamp our previous example to make `foo` generic: -```rust +```rust,ignore fn foo>() { bar::() } fn bar>() { } ``` @@ -144,7 +144,7 @@ To type-check the body of `foo`, we need to be able to hold the type type-safe *for all types `T`*, not just for some specific type. We might express this like so: -``` +```txt fooTypeChecks :- // for all types T... forall { diff --git a/src/ty.md b/src/ty.md index 1fd86a6bd..44017dd5b 100644 --- a/src/ty.md +++ b/src/ty.md @@ -10,7 +10,7 @@ The `tcx` ("typing context") is the central data structure in the compiler. It is the context that you use to perform all manner of queries. The struct `TyCtxt` defines a reference to this shared context: -```rust +```rust,ignore tcx: TyCtxt<'a, 'gcx, 'tcx> // -- ---- ---- // | | | @@ -47,7 +47,7 @@ for the `'gcx` and `'tcx` parameters of `TyCtxt`. Just to be a touch confusing, we tend to use the name `'tcx` in such contexts. Here is an example: -```rust +```rust,ignore fn not_in_inference<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) { // ---- ---- // Using the same lifetime here asserts @@ -59,7 +59,7 @@ fn not_in_inference<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) { In contrast, if we want to code that can be usable during type inference, then you need to declare a distinct `'gcx` and `'tcx` lifetime parameter: -```rust +```rust,ignore fn maybe_in_inference<'a, 'gcx, 'tcx>(tcx: TyCtxt<'a, 'gcx, 'tcx>, def_id: DefId) { // ---- ---- // Using different lifetimes here means that @@ -74,7 +74,7 @@ Rust types are represented using the `Ty<'tcx>` defined in the `ty` module (not to be confused with the `Ty` struct from [the HIR]). This is in fact a simple type alias for a reference with `'tcx` lifetime: -```rust +```rust,ignore pub type Ty<'tcx> = &'tcx TyS<'tcx>; ``` @@ -89,7 +89,7 @@ the rustc arenas (never e.g. on the stack). One common operation on types is to **match** and see what kinds of types they are. This is done by doing `match ty.sty`, sort of like this: -```rust +```rust,ignore fn test_type<'tcx>(ty: Ty<'tcx>) { match ty.sty { ty::TyArray(elem_ty, len) => { ... } @@ -111,7 +111,7 @@ To allocate a new type, you can use the various `mk_` methods defined on the `tcx`. These have names that correpond mostly to the various kinds of type variants. For example: -```rust +```rust,ignore let array_ty = tcx.mk_array(elem_ty, len * 2); ``` @@ -158,7 +158,7 @@ module. Here are a few examples: Although there is no hard and fast rule, the `ty` module tends to be used like so: -```rust +```rust,ignore use ty::{self, Ty, TyCtxt}; ``` diff --git a/src/type-checking.md b/src/type-checking.md index 8148ef627..cca032e30 100644 --- a/src/type-checking.md +++ b/src/type-checking.md @@ -17,9 +17,9 @@ similar conversions for where-clauses and other bits of the function signature. To try and get a sense for the difference, consider this function: -```rust +```rust,ignore struct Foo { } -fn foo(x: Foo, y: self::Foo) { .. } +fn foo(x: Foo, y: self::Foo) { ... } // ^^^ ^^^^^^^^^ ``` diff --git a/src/type-inference.md b/src/type-inference.md index 45f9df18a..ad399d47b 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -21,7 +21,7 @@ signature, such as the `'a` in `for<'a> fn(&'a u32)`. A region is You create and "enter" an inference context by doing something like the following: -```rust +```rust,ignore tcx.infer_ctxt().enter(|infcx| { // Use the inference context `infcx` here. }) @@ -88,7 +88,7 @@ The most basic operations you can perform in the type inferencer is recommended way to add an equality constraint is to use the `at` method, roughly like so: -```rust +```rust,ignore infcx.at(...).eq(t, u); ``` @@ -159,7 +159,9 @@ is to first "generalize" `&'a i32` into a type with a region variable: `&'?b i32`, and then unify `?T` with that (`?T = &'?b i32`). We then relate this new variable with the original bound: - &'?b i32 <: &'a i32 +```txt +&'?b i32 <: &'a i32 +``` This will result in a region constraint (see below) of `'?b: 'a`. @@ -176,12 +178,16 @@ eagerly unifying things, we simply collect constraints as we go, but make (almost) no attempt to solve regions. These constraints have the form of an "outlives" constraint: - 'a: 'b +```txt +'a: 'b +``` Actually the code tends to view them as a subregion relation, but it's the same idea: - 'b <= 'a +```txt +'b <= 'a +``` (There are various other kinds of constriants, such as "verifys"; see the `region_constraints` module for details.) @@ -189,7 +195,9 @@ the `region_constraints` module for details.) There is one case where we do some amount of eager unification. If you have an equality constraint between two regions - 'a = 'b +```txt +'a = 'b +``` we will record that fact in a unification table. You can then use `opportunistic_resolve_var` to convert `'b` to `'a` (or vice diff --git a/src/variance.md b/src/variance.md index 16b4a7518..ea575a595 100644 --- a/src/variance.md +++ b/src/variance.md @@ -54,7 +54,7 @@ constraints will be satisfied. As a simple example, consider: -```rust +```rust,ignore enum Option { Some(A), None } enum OptionalFn { Some(|B|), None } enum OptionalMap { Some(|C| -> C), None } @@ -62,19 +62,23 @@ enum OptionalMap { Some(|C| -> C), None } Here, we will generate the constraints: - 1. V(A) <= + - 2. V(B) <= - - 3. V(C) <= + - 4. V(C) <= - +```txt +1. V(A) <= + +2. V(B) <= - +3. V(C) <= + +4. V(C) <= - +``` These indicate that (1) the variance of A must be at most covariant; (2) the variance of B must be at most contravariant; and (3, 4) the variance of C must be at most covariant *and* contravariant. All of these results are based on a variance lattice defined as follows: - * Top (bivariant) - - + - o Bottom (invariant) +```txt + * Top (bivariant) +- + + o Bottom (invariant) +```txt Based on this lattice, the solution `V(A)=+`, `V(B)=-`, `V(C)=o` is the optimal solution. Note that there is always a naive solution which @@ -85,8 +89,10 @@ is that the variance of a use site may itself be a function of the variance of other type parameters. In full generality, our constraints take the form: - V(X) <= Term - Term := + | - | * | o | V(X) | Term x Term +```txt +V(X) <= Term +Term := + | - | * | o | V(X) | Term x Term +``` Here the notation `V(X)` indicates the variance of a type/region parameter `X` with respect to its defining class. `Term x Term` @@ -101,7 +107,7 @@ represents the "variance transform" as defined in the paper: If I have a struct or enum with where clauses: -```rust +```rust,ignore struct Foo { ... } ``` @@ -170,9 +176,11 @@ another. To see what I mean, consider a trait like so: - trait ConvertTo { - fn convertTo(&self) -> A; - } +```rust +trait ConvertTo { + fn convertTo(&self) -> A; +} +``` Intuitively, If we had one object `O=&ConvertTo` and another `S=&ConvertTo`, then `S <: O` because `String <: Object` @@ -200,20 +208,24 @@ But traits aren't only used with objects. They're also used when deciding whether a given impl satisfies a given trait bound. To set the scene here, imagine I had a function: - fn convertAll>(v: &[T]) { - ... - } +```rust,ignore +fn convertAll>(v: &[T]) { ... } +``` Now imagine that I have an implementation of `ConvertTo` for `Object`: - impl ConvertTo for Object { ... } +```rust,ignore +impl ConvertTo for Object { ... } +``` And I want to call `convertAll` on an array of strings. Suppose further that for whatever reason I specifically supply the value of `String` for the type parameter `T`: - let mut vector = vec!["string", ...]; - convertAll::(vector); +```rust,ignore +let mut vector = vec!["string", ...]; +convertAll::(vector); +``` Is this legal? To put another way, can we apply the `impl` for `Object` to the type `String`? The answer is yes, but to see why @@ -222,11 +234,9 @@ we have to expand out what will happen: - `convertAll` will create a pointer to one of the entries in the vector, which will have type `&String` - It will then call the impl of `convertTo()` that is intended - for use with objects. This has the type: - - fn(self: &Object) -> i32 + for use with objects. This has the type `fn(self: &Object) -> i32`. - It is ok to provide a value for `self` of type `&String` because + It is OK to provide a value for `self` of type `&String` because `&String <: &Object`. OK, so intuitively we want this to be legal, so let's bring this back @@ -238,11 +248,15 @@ Maybe it's helpful to think of a dictionary-passing implementation of type classes. In that case, `convertAll()` takes an implicit parameter representing the impl. In short, we *have* an impl of type: - V_O = ConvertTo for Object +```txt +V_O = ConvertTo for Object +``` and the function prototype expects an impl of type: - V_S = ConvertTo for String +```txt +V_S = ConvertTo for String +``` As with any argument, this is legal if the type of the value given (`V_O`) is a subtype of the type expected (`V_S`). So is `V_O <: V_S`? @@ -250,9 +264,11 @@ The answer will depend on the variance of the various parameters. In this case, because the `Self` parameter is contravariant and `A` is covariant, it means that: - V_O <: V_S iff - i32 <: i32 - String <: Object +```txt +V_O <: V_S iff + i32 <: i32 + String <: Object +``` These conditions are satisfied and so we are happy. @@ -263,7 +279,9 @@ expressions -- must be invariant with respect to all of their inputs. To see why this makes sense, consider what subtyping for a trait reference means: - <: +```txt + <: +``` means that if I know that `T as Trait`, I also know that `U as Trait`. Moreover, if you think of it as dictionary passing style, @@ -279,7 +297,7 @@ Another related reason is that if we didn't make traits with associated types invariant, then projection is no longer a function with a single result. Consider: -``` +```rust,ignore trait Identity { type Out; fn foo(&self); } impl Identity for T { type Out = T; ... } ``` @@ -287,9 +305,11 @@ impl Identity for T { type Out = T; ... } Now if I have `<&'static () as Identity>::Out`, this can be validly derived as `&'a ()` for any `'a`: - <&'a () as Identity> <: <&'static () as Identity> - if &'static () < : &'a () -- Identity is contravariant in Self - if 'static : 'a -- Subtyping rules for relations +```txt +<&'a () as Identity> <: <&'static () as Identity> +if &'static () < : &'a () -- Identity is contravariant in Self +if 'static : 'a -- Subtyping rules for relations +``` This change otoh means that `<'static () as Identity>::Out` is always `&'static ()` (which might then be upcast to `'a ()`, From 8889dcd15d7115bfafb708a9ba61af59d4208dbf Mon Sep 17 00:00:00 2001 From: varkor Date: Fri, 6 Apr 2018 19:35:21 +0100 Subject: [PATCH 0185/1812] Replace txt with text --- src/appendix-stupid-stats.md | 2 +- src/high-level-overview.md | 2 +- src/incrcomp-debugging.md | 10 +++---- src/method-lookup.md | 2 +- src/mir-passes.md | 4 +-- src/mir-regionck.md | 52 ++++++++++++++++----------------- src/mir.md | 4 +-- src/tests/adding.md | 2 +- src/traits-associated-types.md | 8 ++--- src/traits-canonical-queries.md | 20 ++++++------- src/traits-canonicalization.md | 32 ++++++++++---------- src/traits-goals-and-clauses.md | 12 ++++---- src/traits-lowering-module.md | 2 +- src/traits-lowering-rules.md | 14 ++++----- src/traits-lowering-to-logic.md | 10 +++---- src/type-inference.md | 8 ++--- src/variance.md | 18 ++++++------ 17 files changed, 101 insertions(+), 101 deletions(-) diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md index 0c4de5c7a..9b7d9812b 100644 --- a/src/appendix-stupid-stats.md +++ b/src/appendix-stupid-stats.md @@ -177,7 +177,7 @@ foo.rs` (assuming you have a Rust program called `foo.rs`. You can also pass any command line arguments that you would normally pass to rustc). When you run it you'll see output similar to -```txt +```text In crate: foo, Found 12 uses of `println!`; diff --git a/src/high-level-overview.md b/src/high-level-overview.md index e369db28c..9f3b63a54 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -19,7 +19,7 @@ compilation improves, that may change.) The dependency structure of these crates is roughly a diamond: -```txt +```text rustc_driver / | \ / | \ diff --git a/src/incrcomp-debugging.md b/src/incrcomp-debugging.md index 3ad9f3a49..2488aa320 100644 --- a/src/incrcomp-debugging.md +++ b/src/incrcomp-debugging.md @@ -48,7 +48,7 @@ the graph. You can filter in three ways: To filter, use the `RUST_DEP_GRAPH_FILTER` environment variable, which should look like one of the following: -```txt +```text source_filter // nodes originating from source_filter -> target_filter // nodes that can reach target_filter source_filter -> target_filter // nodes in between source_filter and target_filter @@ -58,14 +58,14 @@ source_filter -> target_filter // nodes in between source_filter and target_filt A node is considered to match a filter if all of those strings appear in its label. So, for example: -```txt +```text RUST_DEP_GRAPH_FILTER='-> TypeckTables' ``` would select the predecessors of all `TypeckTables` nodes. Usually though you want the `TypeckTables` node for some particular fn, so you might write: -```txt +```text RUST_DEP_GRAPH_FILTER='-> TypeckTables & bar' ``` @@ -75,7 +75,7 @@ with `bar` in their name. Perhaps you are finding that when you change `foo` you need to re-type-check `bar`, but you don't think you should have to. In that case, you might do: -```txt +```text RUST_DEP_GRAPH_FILTER='Hir & foo -> TypeckTables & bar' ``` @@ -105,7 +105,7 @@ check of `bar` and you don't think there should be. You dump the dep-graph as described in the previous section and open `dep-graph.txt` to see something like: -```txt +```text Hir(foo) -> Collect(bar) Collect(bar) -> TypeckTables(bar) ``` diff --git a/src/method-lookup.md b/src/method-lookup.md index dbbc62fa8..a3d8dca29 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -99,7 +99,7 @@ So, let's continue our example. Imagine that we were calling a method that defines it with `&self` for the type `Rc` as well as a method on the type `Box` that defines `Foo` but with `&mut self`. Then we might have two candidates: -```txt +```text &Rc> from the impl of `Foo` for `Rc` where `U=Box &mut Box<[T; 3]>> from the inherent impl on `Box` where `U=[T; 3]` ``` diff --git a/src/mir-passes.md b/src/mir-passes.md index fd0c6cca1..64e72f06e 100644 --- a/src/mir-passes.md +++ b/src/mir-passes.md @@ -52,7 +52,7 @@ fn main() { The files have names like `rustc.main.000-000.CleanEndRegions.after.mir`. These names have a number of parts: -```txt +```text rustc.main.000-000.CleanEndRegions.after.mir ---- --- --- --------------- ----- either before or after | | | name of the pass @@ -159,7 +159,7 @@ ensuring that the reads have already happened (remember that [queries are memoized](./query.html), so executing a query twice simply loads from a cache the second time): -```txt +```text mir_const(D) --read-by--> mir_const_qualif(D) | ^ stolen-by | diff --git a/src/mir-regionck.md b/src/mir-regionck.md index 949b11d90..4158b7d38 100644 --- a/src/mir-regionck.md +++ b/src/mir-regionck.md @@ -122,7 +122,7 @@ stack, for example). But *how* do we reject it and *why*? When we type-check `main`, and in particular the call `bar(foo)`, we are going to wind up with a subtyping relationship like this one: -```txt +```text fn(&'static u32) <: for<'a> fn(&'a u32) ---------------- ------------------- the type of `foo` the type `bar` expects @@ -137,7 +137,7 @@ regions" -- they represent, basically, "some unknown region". Once we've done that replacement, we have the following relation: -```txt +```text fn(&'static u32) <: fn(&'!1 u32) ``` @@ -151,7 +151,7 @@ subtypes, we check if their arguments have the desired relationship (fn arguments are [contravariant](./appendix-background.html#variance), so we swap the left and right here): -```txt +```text &'!1 u32 <: &'static u32 ``` @@ -201,7 +201,7 @@ Here, the name `'b` is not part of the root universe. Instead, when we "enter" into this `for<'b>` (e.g., by skolemizing it), we will create a child universe of the root, let's call it U1: -```txt +```text U0 (root universe) │ └─ U1 (child universe) @@ -224,7 +224,7 @@ When we enter *this* type, we will again create a new universe, which we'll call `U2`. Its parent will be the root universe, and U1 will be its sibling: -```txt +```text U0 (root universe) │ ├─ U1 (child universe) @@ -263,7 +263,7 @@ children, that inference variable X would have to be in U0. And since X is in U0, it cannot name anything from U1 (or U2). This is perhaps easiest to see by using a kind of generic "logic" example: -```txt +```text exists { forall { ... /* Y is in U1 ... */ } forall { ... /* Z is in U2 ... */ } @@ -296,7 +296,7 @@ does not say region elements **will** appear. In the region inference engine, outlives constraints have the form: -```txt +```text V1: V2 @ P ``` @@ -346,7 +346,7 @@ for universal regions from the fn signature.) Put another way, the "universal regions" check can be considered to be checking constraints like: -```txt +```text {skol(1)}: V1 ``` @@ -358,13 +358,13 @@ made to represent the `!1` region. OK, so far so good. Now let's walk through what would happen with our first example: -```txt +```text fn(&'static u32) <: fn(&'!1 u32) @ P // this point P is not imp't here ``` The region inference engine will create a region element domain like this: -```txt +```text { CFG; end('static); skol(1) } --- ------------ ------- from the universe `!1` | 'static is always in scope @@ -375,20 +375,20 @@ It will always create two universal variables, one representing `'static` and one representing `'!1`. Let's call them Vs and V1. They will have initial values like so: -```txt +```text Vs = { CFG; end('static) } // it is in U0, so can't name anything else V1 = { skol(1) } ``` From the subtyping constraint above, we would have an outlives constraint like -```txt +```text '!1: 'static @ P ``` To process this, we would grow the value of V1 to include all of Vs: -```txt +```text Vs = { CFG; end('static) } V1 = { CFG; end('static), skol(1) } ``` @@ -405,7 +405,7 @@ In this case, `V1` *did* grow too large -- it is not known to outlive What about this subtyping relationship? -```txt +```text for<'a> fn(&'a u32, &'a u32) <: for<'b, 'c> fn(&'b u32, &'c u32) @@ -413,7 +413,7 @@ for<'b, 'c> fn(&'b u32, &'c u32) Here we would skolemize the supertype, as before, yielding: -```txt +```text for<'a> fn(&'a u32, &'a u32) <: fn(&'!1 u32, &'!2 u32) @@ -423,7 +423,7 @@ then we instantiate the variable on the left-hand side with an existential in universe U2, yielding the following (`?n` is a notation for an existential variable): -```txt +```text fn(&'?3 u32, &'?3 u32) <: fn(&'!1 u32, &'!2 u32) @@ -431,14 +431,14 @@ fn(&'!1 u32, &'!2 u32) Then we break this down further: -```txt +```text &'!1 u32 <: &'?3 u32 &'!2 u32 <: &'?3 u32 ``` and even further, yield up our region constraints: -```txt +```text '!1: '?3 '!2: '?3 ``` @@ -465,7 +465,7 @@ common lifetime of our arguments. -nmatsakis) Let's look at one last example. We'll extend the previous one to have a return type: -```txt +```text for<'a> fn(&'a u32, &'a u32) -> &'a u32 <: for<'b, 'c> fn(&'b u32, &'c u32) -> &'b u32 @@ -478,7 +478,7 @@ first one. That is unsound. Let's see how it plays out. First, we skolemize the supertype: -```txt +```text for<'a> fn(&'a u32, &'a u32) -> &'a u32 <: fn(&'!1 u32, &'!2 u32) -> &'!1 u32 @@ -486,7 +486,7 @@ fn(&'!1 u32, &'!2 u32) -> &'!1 u32 Then we instantiate the subtype with existentials (in U2): -```txt +```text fn(&'?3 u32, &'?3 u32) -> &'?3 u32 <: fn(&'!1 u32, &'!2 u32) -> &'!1 u32 @@ -494,7 +494,7 @@ fn(&'!1 u32, &'!2 u32) -> &'!1 u32 And now we create the subtyping relationships: -```txt +```text &'!1 u32 <: &'?3 u32 // arg 1 &'!2 u32 <: &'?3 u32 // arg 2 &'?3 u32 <: &'!1 u32 // return type @@ -503,7 +503,7 @@ And now we create the subtyping relationships: And finally the outlives relationships. Here, let V1, V2, and V3 be the variables we assign to `!1`, `!2`, and `?3` respectively: -```txt +```text V1: V3 V2: V3 V3: V1 @@ -511,7 +511,7 @@ V3: V1 Those variables will have these initial values: -```txt +```text V1 in U1 = {skol(1)} V2 in U2 = {skol(2)} V3 in U2 = {} @@ -520,14 +520,14 @@ V3 in U2 = {} Now because of the `V3: V1` constraint, we have to add `skol(1)` into `V3` (and indeed it is visible from `V3`), so we get: -```txt +```text V3 in U2 = {skol(1)} ``` then we have this constraint `V2: V3`, so we wind up having to enlarge `V2` to include `skol(1)` (which it can also see): -```txt +```text V2 in U2 = {skol(1), skol(2)} ``` diff --git a/src/mir.md b/src/mir.md index 8e45a62bc..da468acf4 100644 --- a/src/mir.md +++ b/src/mir.md @@ -159,7 +159,7 @@ _3 = &mut _1; Assignments in general have the form: -```txt +```text = ``` @@ -169,7 +169,7 @@ value: in this case, the rvalue is a mutable borrow expression, which looks like `&mut `. So we can kind of define a grammar for rvalues like so: -```txt +```text = & (mut)? | + | - diff --git a/src/tests/adding.md b/src/tests/adding.md index f97f4a57e..ab5a0adc1 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -298,7 +298,7 @@ default regex flavor provided by `regex` crate. The corresponding reference file will use the normalized output to test both 32-bit and 64-bit platforms: -```txt +```text ... | = note: source type: fn() ($PTR bits) diff --git a/src/traits-associated-types.md b/src/traits-associated-types.md index bcf6b48ea..e2dd94d5a 100644 --- a/src/traits-associated-types.md +++ b/src/traits-associated-types.md @@ -51,7 +51,7 @@ In our logic, normalization is defined by a predicate impls. For example, the `impl` of `IntoIterator` for `Option` that we saw above would be lowered to a program clause like so: -```txt +```text forall { Normalize( as IntoIterator>::Item -> T) } @@ -101,7 +101,7 @@ consider an associated type projection equal to another type?": We now introduce the `ProjectionEq` predicate to bring those two cases together. The `ProjectionEq` predicate looks like so: -```txt +```text ProjectionEq(::Item = U) ``` @@ -109,7 +109,7 @@ and we will see that it can be proven *either* via normalization or skolemization. As part of lowering an associated type declaration from some trait, we create two program clauses for `ProjectionEq`: -```txt +```text forall { ProjectionEq(::Item = U) :- Normalize(::Item -> U) @@ -130,7 +130,7 @@ with unification. As described in the [type inference](./type-inference.html) section, unification is basically a procedure with a signature like this: -```txt +```text Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution> ``` diff --git a/src/traits-canonical-queries.md b/src/traits-canonical-queries.md index 99916267d..3c4bb1bfe 100644 --- a/src/traits-canonical-queries.md +++ b/src/traits-canonical-queries.md @@ -19,13 +19,13 @@ In a traditional Prolog system, when you start a query, the solver will run off and start supplying you with every possible answer it can find. So given something like this: -```txt +```text ?- Vec: AsRef ``` The solver might answer: -```txt +```text Vec: AsRef<[i32]> continue? (y/n) ``` @@ -39,7 +39,7 @@ response with our original query -- Rust's solver gives back a substitution instead). If we were to hit `y`, the solver might then give us another possible answer: -```txt +```text Vec: AsRef> continue? (y/n) ``` @@ -48,14 +48,14 @@ This answer derives from the fact that there is a reflexive impl (`impl AsRef for T`) for `AsRef`. If were to hit `y` again, then we might get back a negative response: -```txt +```text no ``` Naturally, in some cases, there may be no possible answers, and hence the solver will just give me back `no` right away: -```txt +```text ?- Box: Copy no ``` @@ -64,7 +64,7 @@ In some cases, there might be an infinite number of responses. So for example if I gave this query, and I kept hitting `y`, then the solver would never stop giving me back answers: -```txt +```text ?- Vec: Clone Vec: Clone continue? (y/n) @@ -82,13 +82,13 @@ layer of `Box` until we ask it to stop, or it runs out of memory. Another interesting thing is that queries might still have variables in them. For example: -```txt +```text ?- Rc: Clone ``` might produce the answer: -```txt +```text Rc: Clone continue? (y/n) ``` @@ -226,13 +226,13 @@ Let's suppose that the type checker decides to revisit the Borrow`. `?U` is no longer an unbound inference variable; it now has a value, `Vec`. So, if we "refresh" the query with that value, we get: -```txt +```text Vec: Borrow> ``` This time, there is only one impl that applies, the reflexive impl: -```txt +```text impl Borrow for T where T: ?Sized ``` diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index 576ca2055..cce91a388 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -44,13 +44,13 @@ and treats them equally, so when canonicalizing, we will *also* replace any [free lifetime](./appendix-background.html#free-vs-bound) with a canonical variable. Therefore, we get the following result: -```txt +```text ?0: Foo<'?1, ?2> ``` Sometimes we write this differently, like so: -```txt +```text for { ?0: Foo<'?1, ?2> } ``` @@ -61,7 +61,7 @@ so `?0` and `?2` are types; the `L` indicates a lifetime varibale, so `CanonicalVarValues` array OV with the "original values" for each canonicalized variable: -```txt +```text [?A, 'static, ?B] ``` @@ -76,13 +76,13 @@ we create a substitution S from the canonical form containing a fresh inference variable (of suitable kind) for each canonical variable. So, for our example query: -```txt +```text for { ?0: Foo<'?1, ?2> } ``` the substitution S might be: -```txt +```text S = [?A, '?B, ?C] ``` @@ -90,7 +90,7 @@ We can then replace the bound canonical variables (`?0`, etc) with these inference variables, yielding the following fully instantiated query: -```txt +```text ?A: Foo<'?B, ?C> ``` @@ -135,20 +135,20 @@ result substitution `var_values`, and some region constraints. To create this, we wind up re-using the substitution S that we created when first instantiating our query. To refresh your memory, we had a query -```txt +```text for { ?0: Foo<'?1, ?2> } ``` for which we made a substutition S: -```txt +```text S = [?A, '?B, ?C] ``` We then did some work which unified some of those variables with other things. If we "refresh" S with the latest results, we get: -```txt +```text S = [Vec, '?D, ?E] ``` @@ -157,7 +157,7 @@ our original query. Note though that they include some new variables (like `?E`). We can make those go away by canonicalizing again! We don't just canonicalize S, though, we canonicalize the whole query response QR: -```txt +```text QR = { certainty: Proven, // or whatever var_values: [Vec, '?D, ?E] // this is S @@ -170,7 +170,7 @@ QR = { The result would be as follows: -```txt +```text Canonical(QR) = for { certainty: Proven, var_values: [Vec, '?1, ?2] @@ -194,19 +194,19 @@ In the previous section we produced a canonical query result. We now have to apply that result in our original context. If you recall, way back in the beginning, we were trying to prove this query: -```txt +```text ?A: Foo<'static, ?B> ``` We canonicalized that into this: -```txt +```text for { ?0: Foo<'?1, ?2> } ``` and now we got back a canonical response: -```txt +```text for { certainty: Proven, var_values: [Vec, '?1, ?2] @@ -221,7 +221,7 @@ the result with a fresh inference variable, (b) unify the values in the result with the original values, and then (c) record the region constraints for later. Doing step (a) would yield a result of -```txt +```text { certainty: Proven, var_values: [Vec, '?D, ?C] @@ -233,7 +233,7 @@ constraints for later. Doing step (a) would yield a result of Step (b) would then unify: -```txt +```text ?A with Vec 'static with '?D ?B with ?C diff --git a/src/traits-goals-and-clauses.md b/src/traits-goals-and-clauses.md index 97532195e..5e8ee1469 100644 --- a/src/traits-goals-and-clauses.md +++ b/src/traits-goals-and-clauses.md @@ -12,7 +12,7 @@ a few new superpowers. In Rust's solver, **goals** and **clauses** have the following forms (note that the two definitions reference one another): -```txt +```text Goal = DomainGoal // defined in the section below | Goal && Goal | Goal || Goal @@ -49,7 +49,7 @@ To define the set of *domain goals* in our system, we need to first introduce a few simple formulations. A **trait reference** consists of the name of a trait along with a suitable set of inputs P0..Pn: -```txt +```text TraitRef = P0: TraitName ``` @@ -63,13 +63,13 @@ T>`), that are not part of a trait reference. A **projection** consists of an associated item reference along with its inputs P0..Pm: -```txt +```text Projection = >::AssocItem ``` Given that, we can define a `DomainGoal` as follows: -```txt +```text DomainGoal = Implemented(TraitRef) | ProjectionEq(Projection = Type) | Normalize(Projection -> Type) @@ -112,7 +112,7 @@ DomainGoal = Implemented(TraitRef) Most goals in our system are "inductive". In an inductive goal, circular reasoning is disallowed. Consider this example clause: -```txt +```text Implemented(Foo: Bar) :- Implemented(Foo: Bar). ``` @@ -140,7 +140,7 @@ struct Foo { The default rules for auto traits say that `Foo` is `Send` if the types of its fields are `Send`. Therefore, we would have a rule like -```txt +```text Implemented(Foo: Send) :- Implemented(Option>: Send). ``` diff --git a/src/traits-lowering-module.md b/src/traits-lowering-module.md index fa068f86a..cb3b4a5f7 100644 --- a/src/traits-lowering-module.md +++ b/src/traits-lowering-module.md @@ -49,7 +49,7 @@ standard [ui test] mechanisms to check them. In this case, there is a need only be a prefix of the error), but [the stderr file] contains the full details: -```txt +```text error: Implemented(T: Foo) :- ProjectionEq(::Item == i32), TypeOutlives(T \ : 'static), Implemented(T: std::iter::Iterator), Implemented(T: std::marker::Sized). --> $DIR/lower_impl.rs:15:1 diff --git a/src/traits-lowering-rules.md b/src/traits-lowering-rules.md index 1a9717f9f..f7433221e 100644 --- a/src/traits-lowering-rules.md +++ b/src/traits-lowering-rules.md @@ -87,7 +87,7 @@ relationships between different kinds of domain goals. The first such rule from the trait header creates the mapping between the `FromEnv` and `Implemented` predicates: -```txt +```text // Rule Implemented-From-Env forall { Implemented(Self: Trait) :- FromEnv(Self: Trait) @@ -103,7 +103,7 @@ The next few clauses have to do with implied bounds (see also [RFC 2089]: https://rust-lang.github.io/rfcs/2089-implied-bounds.html -```txt +```text // Rule Implied-Bound-From-Trait // // For each where clause WC: @@ -130,7 +130,7 @@ clauses** but also things that follow from them. The next rule is related; it defines what it means for a trait reference to be **well-formed**: -```txt +```text // Rule WellFormed-TraitRef // // For each where clause WC: @@ -197,7 +197,7 @@ the rules by which `ProjectionEq` can succeed; these two clauses are discussed in detail in the [section on associated types](./traits-associated-types.html), but reproduced here for reference: -```txt +```text // Rule ProjectionEq-Normalize // // ProjectionEq can succeed by normalizing: @@ -227,7 +227,7 @@ the `Bounds` declared on the associated type must be proven to hold to show that the impl is well-formed, and hence we can rely on them elsewhere. -```txt +```text // XXX how exactly should we set this up? Have to be careful; // presumably this has to be a kind of `FromEnv` setup. ``` @@ -253,7 +253,7 @@ where WC Let `TraitRef` be the trait reference `A0: Trait`. Then we will create the following rules: -```txt +```text // Rule Implemented-From-Impl forall { Implemented(TraitRef) :- WC @@ -278,7 +278,7 @@ where WC We produce the following rule: -```txt +```text // Rule Normalize-From-Impl forall { forall { diff --git a/src/traits-lowering-to-logic.md b/src/traits-lowering-to-logic.md index f36794d2c..54b3473d4 100644 --- a/src/traits-lowering-to-logic.md +++ b/src/traits-lowering-to-logic.md @@ -30,7 +30,7 @@ impl Clone for Vec where T: Clone { } We could map these declarations to some Horn clauses, written in a Prolog-like notation, as follows: -```txt +```text Clone(usize). Clone(Vec) :- Clone(?T). @@ -70,7 +70,7 @@ impl> Eq> for Vec { } That could be mapped as follows: -```txt +```text Eq(usize, usize). Eq(Vec, Vec) :- Eq(?T, ?U). ``` @@ -105,7 +105,7 @@ If we wanted, we could write a Prolog predicate that defines the conditions under which `bar()` can be called. We'll say that those conditions are called being "well-formed": -```txt +```text barWellFormed(?U) :- Eq(?U, ?U). ``` @@ -113,7 +113,7 @@ Then we can say that `foo()` type-checks if the reference to `bar::` (that is, `bar()` applied to the type `usize`) is well-formed: -```txt +```text fooTypeChecks :- barWellFormed(usize). ``` @@ -144,7 +144,7 @@ To type-check the body of `foo`, we need to be able to hold the type type-safe *for all types `T`*, not just for some specific type. We might express this like so: -```txt +```text fooTypeChecks :- // for all types T... forall { diff --git a/src/type-inference.md b/src/type-inference.md index ad399d47b..152bbd9da 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -159,7 +159,7 @@ is to first "generalize" `&'a i32` into a type with a region variable: `&'?b i32`, and then unify `?T` with that (`?T = &'?b i32`). We then relate this new variable with the original bound: -```txt +```text &'?b i32 <: &'a i32 ``` @@ -178,14 +178,14 @@ eagerly unifying things, we simply collect constraints as we go, but make (almost) no attempt to solve regions. These constraints have the form of an "outlives" constraint: -```txt +```text 'a: 'b ``` Actually the code tends to view them as a subregion relation, but it's the same idea: -```txt +```text 'b <= 'a ``` @@ -195,7 +195,7 @@ the `region_constraints` module for details.) There is one case where we do some amount of eager unification. If you have an equality constraint between two regions -```txt +```text 'a = 'b ``` diff --git a/src/variance.md b/src/variance.md index ea575a595..5fe84636f 100644 --- a/src/variance.md +++ b/src/variance.md @@ -62,7 +62,7 @@ enum OptionalMap { Some(|C| -> C), None } Here, we will generate the constraints: -```txt +```text 1. V(A) <= + 2. V(B) <= - 3. V(C) <= + @@ -74,11 +74,11 @@ These indicate that (1) the variance of A must be at most covariant; variance of C must be at most covariant *and* contravariant. All of these results are based on a variance lattice defined as follows: -```txt +```text * Top (bivariant) - + o Bottom (invariant) -```txt +```text Based on this lattice, the solution `V(A)=+`, `V(B)=-`, `V(C)=o` is the optimal solution. Note that there is always a naive solution which @@ -89,7 +89,7 @@ is that the variance of a use site may itself be a function of the variance of other type parameters. In full generality, our constraints take the form: -```txt +```text V(X) <= Term Term := + | - | * | o | V(X) | Term x Term ``` @@ -248,13 +248,13 @@ Maybe it's helpful to think of a dictionary-passing implementation of type classes. In that case, `convertAll()` takes an implicit parameter representing the impl. In short, we *have* an impl of type: -```txt +```text V_O = ConvertTo for Object ``` and the function prototype expects an impl of type: -```txt +```text V_S = ConvertTo for String ``` @@ -264,7 +264,7 @@ The answer will depend on the variance of the various parameters. In this case, because the `Self` parameter is contravariant and `A` is covariant, it means that: -```txt +```text V_O <: V_S iff i32 <: i32 String <: Object @@ -279,7 +279,7 @@ expressions -- must be invariant with respect to all of their inputs. To see why this makes sense, consider what subtyping for a trait reference means: -```txt +```text <: ``` @@ -305,7 +305,7 @@ impl Identity for T { type Out = T; ... } Now if I have `<&'static () as Identity>::Out`, this can be validly derived as `&'a ()` for any `'a`: -```txt +```text <&'a () as Identity> <: <&'static () as Identity> if &'static () < : &'a () -- Identity is contravariant in Self if 'static : 'a -- Subtyping rules for relations From 79eaa63c540f8872530ab01dfaf7166fc99703cf Mon Sep 17 00:00:00 2001 From: varkor Date: Fri, 6 Apr 2018 19:36:48 +0100 Subject: [PATCH 0186/1812] Fix spacing --- src/traits-canonicalization.md | 4 ++-- src/variance.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/traits-canonicalization.md b/src/traits-canonicalization.md index cce91a388..fa39151d7 100644 --- a/src/traits-canonicalization.md +++ b/src/traits-canonicalization.md @@ -163,8 +163,8 @@ QR = { var_values: [Vec, '?D, ?E] // this is S region_constraints: [?E: '?D], // from the impl value: (), // for our purposes, just (), but - // in some cases this might have - // a type or other info + // in some cases this might have + // a type or other info } ``` diff --git a/src/variance.md b/src/variance.md index 5fe84636f..527c2745c 100644 --- a/src/variance.md +++ b/src/variance.md @@ -75,10 +75,10 @@ variance of C must be at most covariant *and* contravariant. All of these results are based on a variance lattice defined as follows: ```text - * Top (bivariant) + * Top (bivariant) - + - o Bottom (invariant) -```text + o Bottom (invariant) +``` Based on this lattice, the solution `V(A)=+`, `V(B)=-`, `V(C)=o` is the optimal solution. Note that there is always a naive solution which From 6e4286d387509e698cec19a4327b199a32b128cf Mon Sep 17 00:00:00 2001 From: varkor Date: Fri, 6 Apr 2018 19:39:25 +0100 Subject: [PATCH 0187/1812] Add mdbook test to Travis --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index 45ba4a890..d7f8f8f42 100644 --- a/.travis.yml +++ b/.travis.yml @@ -9,6 +9,7 @@ install: - bash ci/install.sh script: - mdbook build +- mdbook test notifications: email: on_success: never From 46864ca9714707f18e658afba9d2ea62afbe2374 Mon Sep 17 00:00:00 2001 From: varkor Date: Fri, 6 Apr 2018 20:04:59 +0100 Subject: [PATCH 0188/1812] Fix unstable Rust code block issue --- src/traits-lowering-module.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits-lowering-module.md b/src/traits-lowering-module.md index cb3b4a5f7..fbf1d6425 100644 --- a/src/traits-lowering-module.md +++ b/src/traits-lowering-module.md @@ -26,7 +26,7 @@ Unit tests are located in [`src/test/ui/chalkify`][chalkify]. A good example test is [the `lower_impl` test][lower_impl]. At the time of this writing, it looked like this: -```rust +```rust,ignore #![feature(rustc_attrs)] trait Foo { } From ad77d418fabaa7bb6f1bc5bc3bba525304fdbfb9 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Fri, 6 Apr 2018 20:58:37 -0400 Subject: [PATCH 0189/1812] update nightly documention for issue#100-b --- src/appendix-stupid-stats.md | 2 +- src/const-eval.md | 2 +- src/method-lookup.md | 4 ++-- src/miri.md | 2 +- src/type-checking.md | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/appendix-stupid-stats.md b/src/appendix-stupid-stats.md index 9b7d9812b..842a2a328 100644 --- a/src/appendix-stupid-stats.md +++ b/src/appendix-stupid-stats.md @@ -113,7 +113,7 @@ between phases. `CompilerCalls` is a trait that you implement in your tool. It contains a fairly ad-hoc set of methods to hook in to the process of processing command line arguments and driving the compiler. For details, see the comments in -[librustc_driver/lib.rs](https://github.com/rust-lang/rust/tree/master/src/librustc_driver/lib.rs). +[librustc_driver/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/index.html). I'll summarise the methods here. `early_callback` and `late_callback` let you call arbitrary code at different diff --git a/src/const-eval.md b/src/const-eval.md index 4a05255c6..70c946f17 100644 --- a/src/const-eval.md +++ b/src/const-eval.md @@ -35,4 +35,4 @@ integer or fat pointer, it will directly yield the value (via `Value::ByVal` or memory allocation (via `Value::ByRef`). This means that the `const_eval` function cannot be used to create miri-pointers to the evaluated constant or static. If you need that, you need to directly work with the functions in -[src/librustc_mir/interpret/const_eval.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/const_eval.rs). +[src/librustc_mir/interpret/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/const_eval/). diff --git a/src/method-lookup.md b/src/method-lookup.md index a3d8dca29..5aafb6abf 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -38,8 +38,8 @@ cacheable across method-call sites. Therefore, it does not include inference variables or other information. [UFCS]: https://github.com/rust-lang/rfcs/blob/master/text/0132-ufcs.md -[probe]: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/method/probe.rs -[confirm]: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/method/confirm.rs +[probe]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/method/probe/ +[confirm]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/method/confirm/ ## The Probe phase diff --git a/src/miri.md b/src/miri.md index fb6675f50..be9587408 100644 --- a/src/miri.md +++ b/src/miri.md @@ -112,7 +112,7 @@ to a pointer to `b`. Although the main entry point to constant evaluation is the `tcx.const_eval` query, there are additional functions in -[librustc_mir/interpret/const_eval.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/const_eval.rs) +[librustc_mir/interpret/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/const_eval/) that allow accessing the fields of a `Value` (`ByRef` or otherwise). You should never have to access an `Allocation` directly except for translating it to the compilation target (at the moment just LLVM). diff --git a/src/type-checking.md b/src/type-checking.md index cca032e30..cb6d346e4 100644 --- a/src/type-checking.md +++ b/src/type-checking.md @@ -39,6 +39,6 @@ type *checking*). For more details, see the [`collect`][collect] module. [queries]: query.html -[collect]: https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/collect.rs +[collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/collect/ **TODO**: actually talk about type checking... From df6b73fb99b5aaef51130de9d70a18d60f566ca4 Mon Sep 17 00:00:00 2001 From: QuietMisdreavus Date: Tue, 10 Apr 2018 19:45:46 -0500 Subject: [PATCH 0190/1812] talk about `only-X` in compiletest --- src/tests/adding.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index ab5a0adc1..1445981eb 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -122,6 +122,8 @@ be compiled or run. * `ignore-X` where `X` is a target detail or stage will ignore the test accordingly (see below) +* `only-X` is like `ignore-X`, but will *only* run the test on that + target or stage * `ignore-pretty` will not compile the pretty-printed test (this is done to test the pretty-printer, but might not always work) * `ignore-test` always ignores the test From 27a32adb7215f9248fef5d56927c02ecac712f6f Mon Sep 17 00:00:00 2001 From: Samuel Wilson Date: Sat, 7 Apr 2018 00:01:51 +1200 Subject: [PATCH 0191/1812] Add definition of a fat pointer Definition referenced from Programming Rust by Jim Blandy & Jason Orendorff, published by O'Reilly. Page 214: References to Slices and Trait Objects. --- src/appendix-glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix-glossary.md b/src/appendix-glossary.md index 1d82686ba..23de529f2 100644 --- a/src/appendix-glossary.md +++ b/src/appendix-glossary.md @@ -16,6 +16,7 @@ cx | we tend to use "cx" as an abbrevation for context. Se DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./appendix-background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. +Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. For example: a reference to a slice is a fat pointer, carrying the starting address of the slice and its length. free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix-background.html#free-vs-bound) 'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item From a87b323307a6d7ad0ba6c9f9b69280766a8a4637 Mon Sep 17 00:00:00 2001 From: Samuel Wilson Date: Sat, 7 Apr 2018 00:01:51 +1200 Subject: [PATCH 0192/1812] Add definition of a fat pointer, double pointer, and wide pointer Definition referenced from Programming Rust by Jim Blandy & Jason Orendorff, published by O'Reilly. Page 214: References to Slices and Trait Objects. Double pointer and wide pointer both refer to fat pointer for detail. --- src/appendix-glossary.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/appendix-glossary.md b/src/appendix-glossary.md index 23de529f2..a37f1b22f 100644 --- a/src/appendix-glossary.md +++ b/src/appendix-glossary.md @@ -16,7 +16,8 @@ cx | we tend to use "cx" as an abbrevation for context. Se DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./appendix-background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. -Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. For example: a reference to a slice is a fat pointer, carrying the starting address of the slice and its length. +Double pointer | a pointer with additional metadata. See "fat pointer" for more. +Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix-background.html#free-vs-bound) 'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item @@ -61,6 +62,7 @@ trait reference | a trait and values for its type parameters ([see more ty | the internal representation of a type ([see more](ty.html)). UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](type-checking.html)). variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./appendix-background.html#variance) for a more general explanation. See the [variance chapter](./variance.html) for an explanation of how type checking handles variance. +Wide pointer | a pointer with additional metadata. See "fat pointer" for more. [LLVM]: https://llvm.org/ [lto]: https://llvm.org/docs/LinkTimeOptimization.html From 81116ab9772ceca8f6b7a42c31b757193df476a3 Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Mon, 9 Apr 2018 21:57:57 +0530 Subject: [PATCH 0193/1812] Add: Added the instructions for debugging from rust-forge --- src/SUMMARY.md | 1 + src/debugging.md | 296 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 297 insertions(+) create mode 100644 src/debugging.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 3460d949d..bf770dbb8 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -52,6 +52,7 @@ - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) - [Generating LLVM IR](./trans.md) +- [Debugging](./debugging.md) --- diff --git a/src/debugging.md b/src/debugging.md new file mode 100644 index 000000000..622728d0d --- /dev/null +++ b/src/debugging.md @@ -0,0 +1,296 @@ +--- +layout: default +title: Debugging the Compiler +--- + +# Debugging the compiler +[debugging]: #debugging + +Here are a few tips to debug the compiler: + +## Getting a backtrace +[getting-a-backtrace]: #getting-a-backtrace + +When you have an ICE (panic in the compiler), you can set +`RUST_BACKTRACE=1` to get the stack trace of the `panic!` like in +normal Rust programs. IIRC backtraces **don't work** on Mac and on MinGW, +sorry. If you have trouble or the backtraces are full of `unknown`, +you might want to find some way to use Linux or MSVC on Windows. + +In the default configuration, you don't have line numbers enabled, so the backtrace looks like this: + ``` +stack backtrace: + 0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace + 1: std::sys_common::backtrace::_print + 2: std::panicking::default_hook::{{closure}} + 3: std::panicking::default_hook + 4: std::panicking::rust_panic_with_hook + 5: std::panicking::begin_panic + 6: rustc_typeck::check::cast::>::pointer_kind + (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~) + 32: rustc_typeck::check_crate + 33: >::with + 34: >::with + 35: rustc::ty::context::TyCtxt::create_and_enter + 36: rustc_driver::driver::compile_input + 37: rustc_driver::run_compiler + ``` + +If you want line numbers for the stack trace, you can enable `debuginfo-lines=true` or `debuginfo=true` in your config.toml and rebuild the compiler. Then the backtrace will look like this: +``` +stack backtrace: + (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~) + 6: rustc_typeck::check::cast::>::pointer_kind + at /home/user/rust/src/librustc_typeck/check/cast.rs:110 + 7: rustc_typeck::check::cast::CastCheck::check + at /home/user/rust/src/librustc_typeck/check/cast.rs:572 + at /home/user/rust/src/librustc_typeck/check/cast.rs:460 + at /home/user/rust/src/librustc_typeck/check/cast.rs:370 + (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~) + 33: rustc_driver::driver::compile_input + at /home/user/rust/src/librustc_driver/driver.rs:1010 + at /home/user/rust/src/librustc_driver/driver.rs:212 + 34: rustc_driver::run_compiler + at /home/user/rust/src/librustc_driver/lib.rs:253 +``` + +## Getting a backtrace for errors +[getting-a-backtrace-for-errors]: #getting-a-backtrace-for-errors + +If you want to get a backtrace to the point where the compiler emits +an error message, you can pass the `-Z treat-err-as-bug`, which +will make the compiler panic on the first error it sees. + +This can also help when debugging `delay_span_bug` calls - it will make +the first `delay_span_bug` call panic, which will give you a useful backtrace. + +For example: +``` +$ cat error.rs +fn main() { + 1 + (); +} +$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc error.rs +error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied + --> error.rs:2:7 + | +2 | 1 + (); + | ^ no implementation for `{integer} + ()` + | + = help: the trait `std::ops::Add<()>` is not implemented for `{integer}` + +error: aborting due to previous error + +$ # Now, where does the error above come from? +$ RUST_BACKTRACE=1 \ + ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc \ + error.rs \ + -Z treat-err-as-bug +error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied + --> error.rs:2:7 + | +2 | 1 + (); + | ^ no implementation for `{integer} + ()` + | + = help: the trait `std::ops::Add<()>` is not implemented for `{integer}` + +error: internal compiler error: unexpected panic + +note: the compiler unexpectedly panicked. this is a bug. + +note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports + +note: rustc 1.24.0-dev running on x86_64-unknown-linux-gnu + +note: run with `RUST_BACKTRACE=1` for a backtrace + +thread 'rustc' panicked at 'encountered error with `-Z treat_err_as_bug', /home/user/rust/src/librustc_errors/lib.rs:411:12 +note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. +stack backtrace: + (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) + 7: rustc::traits::error_reporting::>::report_selection_error + at /home/user/rust/src/librustc/traits/error_reporting.rs:823 + 8: rustc::traits::error_reporting::>::report_fulfillment_errors + at /home/user/rust/src/librustc/traits/error_reporting.rs:160 + at /home/user/rust/src/librustc/traits/error_reporting.rs:112 + 9: rustc_typeck::check::FnCtxt::select_obligations_where_possible + at /home/user/rust/src/librustc_typeck/check/mod.rs:2192 + (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) + 36: rustc_driver::run_compiler + at /home/user/rust/src/librustc_driver/lib.rs:253 +$ # Cool, now I have a backtrace for the error +``` + +## Getting logging output +[getting-logging-output]: #getting-logging-output + +The compiler has a lot of `debug!` calls, which print out logging information +at many points. These are very useful to at least narrow down the location of +a bug if not to find it entirely, or just to orient yourself to why a compiler +is doing a particular thing. + +To see the logs, you need to set the `RUST_LOG` environment variable to +your log filter, e.g. to get the logs for a specific module, you can run the +compiler as `RUST_LOG=module::path rustc my-file.rs`. The Rust logs are +powered by [env-logger], and you can look at the docs linked there to see +the full `RUST_LOG` syntax. All `debug!` output will then appear in +standard error. + +Note that unless you use a very strict filter, the logger will emit a *lot* +of output - so it's typically a good idea to pipe standard error to a file +and look at the log output with a text editor. + +So to put it together. +``` +# This puts the output of all debug calls in `librustc/traits` into +# standard error, which might fill your console backscroll. +$ RUST_LOG=rustc::traits rustc +local my-file.rs + +# This puts the output of all debug calls in `librustc/traits` in +# `traits-log`, so you can then see it with a text editor. +$ RUST_LOG=rustc::traits rustc +local my-file.rs 2>traits-log + +# Not recommended. This will show the output of all `debug!` calls +# in the Rust compiler, and there are a *lot* of them, so it will be +# hard to find anything. +$ RUST_LOG=debug rustc +local my-file.rs 2>all-log + +# This will show the output of all `info!` calls in `rustc_trans`. +# +# There's an `info!` statement in `trans_instance` that outputs +# every function that is translated. This is useful to find out +# which function triggers an LLVM assertion, and this is an `info!` +# log rather than a `debug!` log so it will work on the official +# compilers. +$ RUST_LOG=rustc_trans=info rustc +local my-file.rs +``` + +While calls to `info!` are included in every build of the compiler, +calls to `debug!` are only included in the program if the +`debug-assertions=yes` is turned on in config.toml (it is +turned off by default), so if you don't see `DEBUG` logs, especially +if you run the compiler with `RUST_LOG=rustc rustc some.rs` and only see +`INFO` logs, make sure that `debug-assertions=yes` is turned on in your +config.toml. + +I also think that in some cases just setting it will not trigger a rebuild, +so if you changed it and you already have a compiler built, you might +want to call `x.py clean` to force one. + +### Logging etiquette + +Because calls to `debug!` are removed by default, in most cases, don't worry +about adding "unnecessary" calls to `debug!` and leaving them in in code +you commit - they won't slow +down the performance of what we ship, and if they helped you pinning down +a bug, they will probably help someone else with a different one. + +However, there are still a few concerns that you might care about: + +### Expensive operations in logs + +A note of caution: the expressions *within* the `debug!` call are run +whenever RUST_LOG is set, even if the filter would exclude the log. This means that if in the module `rustc::foo` you have a statement + +```Rust +debug!("{:?}", random_operation(tcx)); +``` + +Then if someone runs a debug `rustc` with `RUST_LOG=rustc::bar`, then `random_operation()` will still run - even while it's output will never be needed! + +This means that you should not put anything too expensive or likely +to crash there - that would annoy anyone who wants to use logging for their own module. Note that if `RUST_LOG` is unset (the default), then the code will not run - this means that if your logging code panics, then no-one will know it until someone tries to use logging to find *another* bug. + +If you *need* to do an expensive operation in a log, be aware that while log expressions are *evaluated* even if logging is not enabled in your module, they are not *formatted* unless it *is*. This means you can put your expensive/crashy operations inside an `fmt::Debug` impl, and they will not be run unless your log is enabled: + +```Rust +use std::fmt; + +struct ExpensiveOperationContainer<'a, 'gcx, 'tcx> + where 'tcx: 'gcx, 'a: 'tcx +{ + tcx: TyCtxt<'a, 'gcx, 'tcx> +} + +impl<'a, 'gcx, 'tcx> fmt::Debug for ExpensiveOperationContainer<'a, 'gcx, 'tcx> { + fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { + let value = random_operation(tcx); + fmt::Debug::fmt(&value, fmt) + } +} + +debug!("{:?}", ExpensiveOperationContainer { tcx }); +``` + +## Formatting Graphviz output (.dot files) +[formatting-graphviz-output]: #formatting-graphviz-output + +Some compiler options for debugging specific features yield graphviz graphs - e.g. +the `#[rustc_mir(borrowck_graphviz_postflow="suffix.dot")]` attribute +dumps various borrow-checker dataflow graphs. + +These all produce `.dot` files. To view these files, install graphviz (e.g. +`apt-get install graphviz`) and then run the following commands: + +``` +$ dot -T pdf maybe_init_suffix.dot > maybe_init_suffix.pdf +$ firefox maybe_init_suffix.pdf # Or your favorite pdf viewer +``` + +## Debugging LLVM +[debugging-llvm]: #debugging-llvm + +LLVM is a big project on its own that probably needs to have its own debugging +document (not that I could find one). But here are some tips that are important +in a rustc context: + +The official compilers (including nightlies) have LLVM assertions disabled, +which means that LLVM assertion failures can show up as compiler crashes (not +ICEs but "real" crashes) and other sorts of weird behavior. If you are +encountering these, it is a good idea to try using a compiler with LLVM +assertions enabled - either an "alt" nightly or a compiler you build yourself +by setting `[llvm] assertions=true` in your config.toml - and +see whether anything turns up. + +The rustc build process builds the LLVM tools into `./build//llvm/bin`. They can be called directly. + +The default rustc compilation pipeline has multiple codegen units, which is hard +to replicate manually and means that LLVM is called multiple times in parallel. +If you can get away with it (i.e. if it doesn't make your bug disappear), +passing `-C codegen-units=1` to rustc will make debugging easier. + +If you want to play with the optimization pipeline, you can use the `opt` from +there on the IR rustc emits with `--emit=llvm-ir`. Note +that rustc emits different IR depending on whether `-O` is enabled, even without +LLVM's optimizations, so if you want to play with the IR rustc emits, you should: +``` +$ rustc +local my-file.rs --emit=llvm-ir -O -C no-prepopulate-passes \ + -C codegen-units=1 +$ OPT=./build/$TRIPLE/llvm/bin/opt +$ $OPT -S -O2 < my-file.ll > my +``` + +If you just want to get the LLVM IR during the LLVM pipeline, to e.g. see which +IR causes an optimization-time assertion to fail, or to see when +LLVM performs a particular optimization, you can pass the rustc flag +`-C llvm-args=-print-after-all`, and possibly add +`-C llvm-args='-filter-print-funcs=EXACT_FUNCTION_NAME` (e.g. +`-C llvm-args='-filter-print-funcs=_ZN11collections3str21_$LT$impl$u20$str$GT$7replace17hbe10ea2e7c809b0bE'`). + +That produces a lot of output into standard error, so you'll want to pipe +that to some file. Also, if you are using neither `-filter-print-funcs` nor +`-C codegen-units=1`, then, because the multiple codegen units run in parallel, +the printouts will mix together and you won't be able to read anything. + +If you want just the IR for a specific function (say, you want to see +why it causes an assertion or doesn't optimize correctly), you can use +`llvm-extract`, e.g. +``` +$ ./build/$TRIPLE/llvm/bin/llvm-extract \ + -func='_ZN11collections3str21_$LT$impl$u20$str$GT$7replace17hbe10ea2e7c809b0bE' \ + -S \ + < unextracted.ll \ + > extracted.ll +``` + +[env-logger]: https://docs.rs/env_logger/0.4.3/env_logger/ From 5653c13077706d8c88658bb261ff10056348ebf6 Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Mon, 9 Apr 2018 22:04:53 +0530 Subject: [PATCH 0194/1812] refactor: Change the name from debugging to compiler-debuggin.md --- src/SUMMARY.md | 2 +- src/{debugging.md => compiler-debugging.md} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename src/{debugging.md => compiler-debugging.md} (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index bf770dbb8..1b9670261 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -52,7 +52,7 @@ - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) - [Generating LLVM IR](./trans.md) -- [Debugging](./debugging.md) +- [Debugging the Compiler](./compiler-debugging.md) --- diff --git a/src/debugging.md b/src/compiler-debugging.md similarity index 100% rename from src/debugging.md rename to src/compiler-debugging.md From 8e02b3734980185e159ebd2983f5fa6e4964ec31 Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Mon, 9 Apr 2018 22:27:43 +0530 Subject: [PATCH 0195/1812] refactor: Fixed all the lines exceeding more than 80 characters --- src/compiler-debugging.md | 58 +++++++++++++++++++++++++++------------ 1 file changed, 41 insertions(+), 17 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 622728d0d..41b50b04a 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -17,7 +17,9 @@ normal Rust programs. IIRC backtraces **don't work** on Mac and on MinGW, sorry. If you have trouble or the backtraces are full of `unknown`, you might want to find some way to use Linux or MSVC on Windows. -In the default configuration, you don't have line numbers enabled, so the backtrace looks like this: +In the default configuration, you don't have line numbers enabled, so the +backtrace looks like this: + ``` stack backtrace: 0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace @@ -26,7 +28,8 @@ stack backtrace: 3: std::panicking::default_hook 4: std::panicking::rust_panic_with_hook 5: std::panicking::begin_panic - 6: rustc_typeck::check::cast::>::pointer_kind + 6: rustc_typeck::check::cast::>::pointer_kind (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~) 32: rustc_typeck::check_crate 33: >::with @@ -36,11 +39,15 @@ stack backtrace: 37: rustc_driver::run_compiler ``` -If you want line numbers for the stack trace, you can enable `debuginfo-lines=true` or `debuginfo=true` in your config.toml and rebuild the compiler. Then the backtrace will look like this: +If you want line numbers for the stack trace, you can enable +`debuginfo-lines=true` or `debuginfo=true` in your config.toml and rebuild the +compiler. Then the backtrace will look like this: + ``` stack backtrace: (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~) - 6: rustc_typeck::check::cast::>::pointer_kind + 6: rustc_typeck::check::cast::>::pointer_kind at /home/user/rust/src/librustc_typeck/check/cast.rs:110 7: rustc_typeck::check::cast::CastCheck::check at /home/user/rust/src/librustc_typeck/check/cast.rs:572 @@ -104,13 +111,17 @@ note: rustc 1.24.0-dev running on x86_64-unknown-linux-gnu note: run with `RUST_BACKTRACE=1` for a backtrace -thread 'rustc' panicked at 'encountered error with `-Z treat_err_as_bug', /home/user/rust/src/librustc_errors/lib.rs:411:12 -note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. +thread 'rustc' panicked at 'encountered error with `-Z treat_err_as_bug', +/home/user/rust/src/librustc_errors/lib.rs:411:12 +note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose +backtrace. stack backtrace: (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) - 7: rustc::traits::error_reporting::>::report_selection_error + 7: rustc::traits::error_reporting::>::report_selection_error at /home/user/rust/src/librustc/traits/error_reporting.rs:823 - 8: rustc::traits::error_reporting::>::report_fulfillment_errors + 8: rustc::traits::error_reporting::>::report_fulfillment_errors at /home/user/rust/src/librustc/traits/error_reporting.rs:160 at /home/user/rust/src/librustc/traits/error_reporting.rs:112 9: rustc_typeck::check::FnCtxt::select_obligations_where_possible @@ -190,18 +201,28 @@ However, there are still a few concerns that you might care about: ### Expensive operations in logs A note of caution: the expressions *within* the `debug!` call are run -whenever RUST_LOG is set, even if the filter would exclude the log. This means that if in the module `rustc::foo` you have a statement +whenever RUST_LOG is set, even if the filter would exclude the log. This means +that if in the module `rustc::foo` you have a statement ```Rust debug!("{:?}", random_operation(tcx)); ``` -Then if someone runs a debug `rustc` with `RUST_LOG=rustc::bar`, then `random_operation()` will still run - even while it's output will never be needed! +Then if someone runs a debug `rustc` with `RUST_LOG=rustc::bar`, then +`random_operation()` will still run - even while it's output will never be +needed! This means that you should not put anything too expensive or likely -to crash there - that would annoy anyone who wants to use logging for their own module. Note that if `RUST_LOG` is unset (the default), then the code will not run - this means that if your logging code panics, then no-one will know it until someone tries to use logging to find *another* bug. +to crash there - that would annoy anyone who wants to use logging for their own +module. Note that if `RUST_LOG` is unset (the default), then the code will not +run - this means that if your logging code panics, then no-one will know it +until someone tries to use logging to find *another* bug. -If you *need* to do an expensive operation in a log, be aware that while log expressions are *evaluated* even if logging is not enabled in your module, they are not *formatted* unless it *is*. This means you can put your expensive/crashy operations inside an `fmt::Debug` impl, and they will not be run unless your log is enabled: +If you *need* to do an expensive operation in a log, be aware that while log +expressions are *evaluated* even if logging is not enabled in your module, +they are not *formatted* unless it *is*. This means you can put your +expensive/crashy operations inside an `fmt::Debug` impl, and they will not be +run unless your log is enabled: ```Rust use std::fmt; @@ -225,8 +246,8 @@ debug!("{:?}", ExpensiveOperationContainer { tcx }); ## Formatting Graphviz output (.dot files) [formatting-graphviz-output]: #formatting-graphviz-output -Some compiler options for debugging specific features yield graphviz graphs - e.g. -the `#[rustc_mir(borrowck_graphviz_postflow="suffix.dot")]` attribute +Some compiler options for debugging specific features yield graphviz graphs - +e.g. the `#[rustc_mir(borrowck_graphviz_postflow="suffix.dot")]` attribute dumps various borrow-checker dataflow graphs. These all produce `.dot` files. To view these files, install graphviz (e.g. @@ -252,7 +273,8 @@ assertions enabled - either an "alt" nightly or a compiler you build yourself by setting `[llvm] assertions=true` in your config.toml - and see whether anything turns up. -The rustc build process builds the LLVM tools into `./build//llvm/bin`. They can be called directly. +The rustc build process builds the LLVM tools into +`./build//llvm/bin`. They can be called directly. The default rustc compilation pipeline has multiple codegen units, which is hard to replicate manually and means that LLVM is called multiple times in parallel. @@ -262,7 +284,8 @@ passing `-C codegen-units=1` to rustc will make debugging easier. If you want to play with the optimization pipeline, you can use the `opt` from there on the IR rustc emits with `--emit=llvm-ir`. Note that rustc emits different IR depending on whether `-O` is enabled, even without -LLVM's optimizations, so if you want to play with the IR rustc emits, you should: +LLVM's optimizations, so if you want to play with the IR rustc emits, +you should: ``` $ rustc +local my-file.rs --emit=llvm-ir -O -C no-prepopulate-passes \ -C codegen-units=1 @@ -275,7 +298,8 @@ IR causes an optimization-time assertion to fail, or to see when LLVM performs a particular optimization, you can pass the rustc flag `-C llvm-args=-print-after-all`, and possibly add `-C llvm-args='-filter-print-funcs=EXACT_FUNCTION_NAME` (e.g. -`-C llvm-args='-filter-print-funcs=_ZN11collections3str21_$LT$impl$u20$str$GT$7replace17hbe10ea2e7c809b0bE'`). +`-C llvm-args='-filter-print-funcs=_ZN11collections3str21_$LT$impl$u20$str$GT$\ + 7replace17hbe10ea2e7c809b0bE'`). That produces a lot of output into standard error, so you'll want to pipe that to some file. Also, if you are using neither `-filter-print-funcs` nor From 29572cd2e4918ad40f0a2028a21ee4e26ed2969e Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Tue, 10 Apr 2018 10:40:06 +0530 Subject: [PATCH 0196/1812] refactor: fixed typos, text formatting suggested in the review --- src/SUMMARY.md | 2 +- src/compiler-debugging.md | 47 +++++++++++++++++++++------------------ 2 files changed, 26 insertions(+), 23 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 1b9670261..1839f59cb 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -8,6 +8,7 @@ - [Adding new tests](./tests/adding.md) - [Using `compiletest` + commands to control test execution](./compiletest.md) +- [Debugging the Compiler](./compiler-debugging.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver](./rustc-driver.md) @@ -52,7 +53,6 @@ - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) - [Generating LLVM IR](./trans.md) -- [Debugging the Compiler](./compiler-debugging.md) --- diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 41b50b04a..fc74caa8f 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -20,7 +20,7 @@ you might want to find some way to use Linux or MSVC on Windows. In the default configuration, you don't have line numbers enabled, so the backtrace looks like this: - ``` +```text stack backtrace: 0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace 1: std::sys_common::backtrace::_print @@ -28,8 +28,6 @@ stack backtrace: 3: std::panicking::default_hook 4: std::panicking::rust_panic_with_hook 5: std::panicking::begin_panic - 6: rustc_typeck::check::cast::>::pointer_kind (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~) 32: rustc_typeck::check_crate 33: >::with @@ -37,17 +35,15 @@ stack backtrace: 35: rustc::ty::context::TyCtxt::create_and_enter 36: rustc_driver::driver::compile_input 37: rustc_driver::run_compiler - ``` +``` If you want line numbers for the stack trace, you can enable `debuginfo-lines=true` or `debuginfo=true` in your config.toml and rebuild the compiler. Then the backtrace will look like this: -``` +```text stack backtrace: (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~) - 6: rustc_typeck::check::cast::>::pointer_kind at /home/user/rust/src/librustc_typeck/check/cast.rs:110 7: rustc_typeck::check::cast::CastCheck::check at /home/user/rust/src/librustc_typeck/check/cast.rs:572 @@ -72,11 +68,15 @@ This can also help when debugging `delay_span_bug` calls - it will make the first `delay_span_bug` call panic, which will give you a useful backtrace. For example: -``` + +```rust $ cat error.rs fn main() { 1 + (); } +``` + +```bash $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc error.rs error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied --> error.rs:2:7 @@ -137,8 +137,8 @@ $ # Cool, now I have a backtrace for the error The compiler has a lot of `debug!` calls, which print out logging information at many points. These are very useful to at least narrow down the location of -a bug if not to find it entirely, or just to orient yourself to why a compiler -is doing a particular thing. +a bug if not to find it entirely, or just to orient yourself as to why the +compiler is doing a particular thing. To see the logs, you need to set the `RUST_LOG` environment variable to your log filter, e.g. to get the logs for a specific module, you can run the @@ -152,7 +152,8 @@ of output - so it's typically a good idea to pipe standard error to a file and look at the log output with a text editor. So to put it together. -``` + +```bash # This puts the output of all debug calls in `librustc/traits` into # standard error, which might fill your console backscroll. $ RUST_LOG=rustc::traits rustc +local my-file.rs @@ -191,10 +192,10 @@ want to call `x.py clean` to force one. ### Logging etiquette Because calls to `debug!` are removed by default, in most cases, don't worry -about adding "unnecessary" calls to `debug!` and leaving them in in code -you commit - they won't slow -down the performance of what we ship, and if they helped you pinning down -a bug, they will probably help someone else with a different one. +about adding "unnecessary" calls to `debug!` and leaving them in code you +commit - they won't slow down the performance of what we ship, and if they +helped you pinning down a bug, they will probably help someone else with a +different one. However, there are still a few concerns that you might care about: @@ -253,7 +254,7 @@ dumps various borrow-checker dataflow graphs. These all produce `.dot` files. To view these files, install graphviz (e.g. `apt-get install graphviz`) and then run the following commands: -``` +```bash $ dot -T pdf maybe_init_suffix.dot > maybe_init_suffix.pdf $ firefox maybe_init_suffix.pdf # Or your favorite pdf viewer ``` @@ -281,12 +282,13 @@ to replicate manually and means that LLVM is called multiple times in parallel. If you can get away with it (i.e. if it doesn't make your bug disappear), passing `-C codegen-units=1` to rustc will make debugging easier. -If you want to play with the optimization pipeline, you can use the `opt` from -there on the IR rustc emits with `--emit=llvm-ir`. Note -that rustc emits different IR depending on whether `-O` is enabled, even without -LLVM's optimizations, so if you want to play with the IR rustc emits, +If you want to play with the optimization pipeline, you can use the opt tool +from `./build//llvm/bin/` with the the LLVM IR emitted by rustc. +Note that rustc emits different IR depending on whether `-O` is enabled, even +without LLVM's optimizations, so if you want to play with the IR rustc emits, you should: -``` + +```bash $ rustc +local my-file.rs --emit=llvm-ir -O -C no-prepopulate-passes \ -C codegen-units=1 $ OPT=./build/$TRIPLE/llvm/bin/opt @@ -309,7 +311,8 @@ the printouts will mix together and you won't be able to read anything. If you want just the IR for a specific function (say, you want to see why it causes an assertion or doesn't optimize correctly), you can use `llvm-extract`, e.g. -``` + +```bash $ ./build/$TRIPLE/llvm/bin/llvm-extract \ -func='_ZN11collections3str21_$LT$impl$u20$str$GT$7replace17hbe10ea2e7c809b0bE' \ -S \ From b4228a73ce217866eb1714e50c6f8485a6754b04 Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Tue, 10 Apr 2018 10:43:09 +0530 Subject: [PATCH 0197/1812] fix: changed rust code to bash formatting --- src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index fc74caa8f..80cbf6735 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -69,7 +69,7 @@ the first `delay_span_bug` call panic, which will give you a useful backtrace. For example: -```rust +```bash $ cat error.rs fn main() { 1 + (); From eb396e7883e10fb4f338c881609a4f70b67bfacc Mon Sep 17 00:00:00 2001 From: cg-cnu Date: Sun, 15 Apr 2018 11:49:15 +0530 Subject: [PATCH 0198/1812] add: note about copy from rust-forge --- src/compiler-debugging.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 80cbf6735..4b445c924 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -3,6 +3,10 @@ layout: default title: Debugging the Compiler --- +**Note: This is copied from the +[rust-forge](https://github.com/rust-lang-nursery/rust-forge). If anything needs + updating, please open an issue or make a PR on the github repo.** + # Debugging the compiler [debugging]: #debugging From 30d20184b3d27f7ec044c6cfe210842a4ea10738 Mon Sep 17 00:00:00 2001 From: "Ehsan M.Kermani" Date: Sun, 22 Apr 2018 16:34:32 -0700 Subject: [PATCH 0199/1812] expand compilation stages --- src/how-to-build-and-run.md | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 535823dfd..dfaf8f79b 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -2,7 +2,7 @@ The compiler is built using a tool called `x.py`. You will need to have Python installed to run it. But before we get to that, if you're going to -be hacking on rustc, you'll want to tweak the configuration of the compiler. +be hacking on `rustc`, you'll want to tweak the configuration of the compiler. The default configuration is oriented towards running the compiler as a user, not a developer. @@ -55,13 +55,20 @@ compiler to compile the newer version. In particular, the newer version of the compiler, `libstd`, and other tooling may use some unstable features internally. The result is the compiling `rustc` is done in stages. -- **Stage 0:** the stage0 compiler is the current _beta_ compiler; we - download this binary from the internet. -- **Stage 1:** the code in your clone is then compiled with the stage - 0 compiler to produce the stage 1 compiler. -- **Stage 2:** the code in your clone is then compiled with the stage - 1 compiler *again* to produce the stage 2 compiler (i.e. it builds - itself). +- **Stage 0:** the stage0 compiler can be your existing (perhaps older version of) + Rust compiler, the current _beta_ compiler or you may download the binary + from the internet +- **Stage 1:** the code in your clone (for new version) + is then compiled with the stage0 + compiler to produce the stage1 compiler. + However, it was built with an older compiler (stage0), + so to optimize the stage1 compiler we go to next stage +- **Stage 2:** we rebuild our stage1 compiler with itself + to produce the stage2 compiler (i.e. it builds + itself) to have all the _latest optimizations_ +- _(Optional)_ **Stage 3**: to sanity check of our new compiler, we can build it again + with stage2 compiler which must be identical to itself, + unless something has broken For hacking, often building the stage 1 compiler is enough, but for final testing and release, the stage 2 compiler is used. From 9140b49321440ca4f275d4a7601768b7e1928c81 Mon Sep 17 00:00:00 2001 From: "Ehsan M.Kermani" Date: Sun, 22 Apr 2018 16:46:12 -0700 Subject: [PATCH 0200/1812] fix max line len --- src/how-to-build-and-run.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index dfaf8f79b..2d979c0d1 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -28,8 +28,8 @@ settings (and possibly others, such as `llvm.ccache`): assertions = true [rust] -# This enables some assertions, but more importantly it enables the `debug!` logging -# macros that are essential for debugging rustc. +# This enables some assertions, but more importantly it enables the `debug!` +# logging macros that are essential for debugging rustc. debug-assertions = true # This will make your build more parallel; it costs a bit of runtime @@ -55,7 +55,8 @@ compiler to compile the newer version. In particular, the newer version of the compiler, `libstd`, and other tooling may use some unstable features internally. The result is the compiling `rustc` is done in stages. -- **Stage 0:** the stage0 compiler can be your existing (perhaps older version of) +- **Stage 0:** the stage0 compiler can be your existing + (perhaps older version of) Rust compiler, the current _beta_ compiler or you may download the binary from the internet - **Stage 1:** the code in your clone (for new version) @@ -66,7 +67,8 @@ internally. The result is the compiling `rustc` is done in stages. - **Stage 2:** we rebuild our stage1 compiler with itself to produce the stage2 compiler (i.e. it builds itself) to have all the _latest optimizations_ -- _(Optional)_ **Stage 3**: to sanity check of our new compiler, we can build it again +- _(Optional)_ **Stage 3**: to sanity check of our new compiler, + we can build it again with stage2 compiler which must be identical to itself, unless something has broken From 7d4aee2431e6362d24ce1f530ae214ff72165100 Mon Sep 17 00:00:00 2001 From: "Ehsan M.Kermani" Date: Sat, 28 Apr 2018 10:40:06 -0700 Subject: [PATCH 0201/1812] lint add dots --- src/how-to-build-and-run.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 2d979c0d1..493f642a5 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -58,19 +58,19 @@ internally. The result is the compiling `rustc` is done in stages. - **Stage 0:** the stage0 compiler can be your existing (perhaps older version of) Rust compiler, the current _beta_ compiler or you may download the binary - from the internet + from the internet. - **Stage 1:** the code in your clone (for new version) is then compiled with the stage0 compiler to produce the stage1 compiler. However, it was built with an older compiler (stage0), - so to optimize the stage1 compiler we go to next stage + so to optimize the stage1 compiler we go to next stage. - **Stage 2:** we rebuild our stage1 compiler with itself to produce the stage2 compiler (i.e. it builds - itself) to have all the _latest optimizations_ + itself) to have all the _latest optimizations_. - _(Optional)_ **Stage 3**: to sanity check of our new compiler, we can build it again with stage2 compiler which must be identical to itself, - unless something has broken + unless something has broken. For hacking, often building the stage 1 compiler is enough, but for final testing and release, the stage 2 compiler is used. From 55ddb4df95b202eeb2490b13f0469fc391110328 Mon Sep 17 00:00:00 2001 From: Nick Fitzgerald Date: Wed, 25 Apr 2018 15:26:40 -0700 Subject: [PATCH 0202/1812] appendix-background: Link to *Static Program Analysis* A+++++ resource IMHO! --- src/appendix-background.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/appendix-background.md b/src/appendix-background.md index 285d74477..a0e298b05 100644 --- a/src/appendix-background.md +++ b/src/appendix-background.md @@ -76,6 +76,9 @@ cycle. ## What is a dataflow analysis? +[*Static Program Analysis*](https://cs.au.dk/~amoeller/spa/) by Anders Møller +and Michael I. Schwartzbach is an incredible resource! + *to be written* From e39ea751a08f135009aa7aaa07f68b4eabd05e1a Mon Sep 17 00:00:00 2001 From: gnzlbg Date: Tue, 8 May 2018 09:40:43 +0200 Subject: [PATCH 0203/1812] Add how to run tidy script in isolation to text This is already mentioned elsewhere, but important things are repeated twice. Closes #124 --- src/conventions.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/conventions.md b/src/conventions.md index 89a986789..7c2a958c0 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -11,7 +11,8 @@ rustc is slowly moving towards the [Rust standard coding style][fmt]; at the moment, however, it follows a rather more *chaotic* style. We do have some mandatory formatting conventions, which are automatically enforced by a script we affectionately call the "tidy" script. The -tidy script runs automatically when you do `./x.py test`. +tidy script runs automatically when you do `./x.py test` and can be run +in isolation with `./x.py test src/tools/tidy`. [fmt]: https://github.com/rust-lang-nursery/fmt-rfcs From e5bed1889527ee86ad6823d5bb61e266c7d8c306 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 8 May 2018 12:44:02 -0500 Subject: [PATCH 0204/1812] update to mdbook 0.1.7 --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index ea90e853d..69b96cc73 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -20,5 +20,5 @@ function cargo_install() { fi } -cargo_install mdbook 0.1.5 +cargo_install mdbook 0.1.7 cargo_install mdbook-linkcheck 0.1.2 From 1cea2615e16d6cf1b8e9a41bc26a1b403994a238 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 10 May 2018 08:09:56 -0400 Subject: [PATCH 0205/1812] Issue84 Add note about ./x.py build --- src/how-to-build-and-run.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 493f642a5..66c736548 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -75,6 +75,11 @@ internally. The result is the compiling `rustc` is done in stages. For hacking, often building the stage 1 compiler is enough, but for final testing and release, the stage 2 compiler is used. +`./x.py check` is really fast to build the rust compiler. +It is, in particular, very useful when you're doing some kind of +"type-based refactoring", like renaming a method, or changing the +signature of some function. + Once you've created a config.toml, you are now ready to run `x.py`. There are a lot of options here, but let's start with what is probably the best "go to" command for building a local rust: From 45cb1d368b060382b316a3befcc9019871d4fdd9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tom=C3=A1=C5=A1=20Gaven=C4=8Diak?= Date: Thu, 3 May 2018 00:25:31 +0200 Subject: [PATCH 0206/1812] Update adding.md Rename `must-compile-successfully` to `compile-pass` in ui test doc as per https://github.com/rust-lang/rust/issues/49568. --- src/tests/adding.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 1445981eb..5d4c383f2 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -150,7 +150,7 @@ source. * `min-{gdb,lldb}-version` * `min-llvm-version` -* `must-compile-successfully` for UI tests, indicates that the test is +* `compile-pass` for UI tests, indicates that the test is supposed to compile, as opposed to the default where the test is supposed to error out. * `compile-flags` passes extra command-line args to the compiler, @@ -258,7 +258,7 @@ can also make UI tests where compilation is expected to succeed, and you can even run the resulting program. Just add one of the following [header commands](#header_commands): -- `// must-compile-successfully` -- compilation should succeed but do +- `// compile-pass` -- compilation should succeed but do not run the resulting binary - `// run-pass` -- compilation should succeed and we should run the resulting binary From eeddfdaf703cb17c3824ca85dc1542fc2ee93329 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Wed, 9 May 2018 17:43:43 -0700 Subject: [PATCH 0207/1812] Deleted tag which was messing up the associated types page --- src/traits-associated-types.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/traits-associated-types.md b/src/traits-associated-types.md index e2dd94d5a..eaf497875 100644 --- a/src/traits-associated-types.md +++ b/src/traits-associated-types.md @@ -22,8 +22,6 @@ though that is something we may want to change in the future.) [intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item - - In some cases, associated type projections can be **normalized** -- that is, simplified -- based on the types given in an impl. So, to continue with our example, the impl of `IntoIterator` for `Option` @@ -152,4 +150,3 @@ to process that constraint. variable X and asks us to prove that `ProjectionEq(P1 = X)` and `ProjectionEq(P2 = X)`. That used to be needed in an older system to prevent cycles; I rather doubt it still is. -nmatsakis) - From 0dc0dddb7904516feaf1c9bd261596bf8ba526fe Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Thu, 10 May 2018 11:51:34 -0700 Subject: [PATCH 0208/1812] Closing all tags --- src/appendix-background.md | 10 +++++----- src/conventions.md | 10 +++++----- src/incremental-compilation.md | 2 +- src/mir-regionck.md | 4 ++-- src/mir.md | 2 +- src/tests/adding.md | 8 ++++---- src/traits-associated-types.md | 2 ++ src/traits-bibliography.md | 4 ++-- src/traits-canonical-queries.md | 2 +- src/traits-goals-and-clauses.md | 8 ++++---- src/traits-lowering-module.md | 2 +- src/traits-lowering-rules.md | 6 +++--- src/type-inference.md | 2 +- src/variance.md | 2 +- 14 files changed, 33 insertions(+), 31 deletions(-) diff --git a/src/appendix-background.md b/src/appendix-background.md index a0e298b05..069131947 100644 --- a/src/appendix-background.md +++ b/src/appendix-background.md @@ -4,7 +4,7 @@ This section covers a numbers of common compiler terms that arise in this guide. We try to give the general definition while providing some Rust-specific context. - + ## What is a control-flow graph? @@ -72,7 +72,7 @@ When using a control-flow graph, a loop simply appears as a cycle in the graph, and the `break` keyword translates into a path out of that cycle. - + ## What is a dataflow analysis? @@ -81,13 +81,13 @@ and Michael I. Schwartzbach is an incredible resource! *to be written* - + ## What is "universally quantified"? What about "existentially quantified"? *to be written* - + ## What is co- and contra-variance? @@ -97,7 +97,7 @@ Check out the subtyping chapter from the See the [variance](./variance.html) chapter of this guide for more info on how the type checker handles variance. - + ## What is a "free region" or a "free variable"? What about "bound region"? diff --git a/src/conventions.md b/src/conventions.md index 7c2a958c0..5b2b7b7f6 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -3,7 +3,7 @@ chapter covers [formatting](#formatting), [coding for correctness](#cc), [using crates from crates.io](#cio), and some tips on [structuring your PR for easy review](#er). - + # Formatting and the tidy script @@ -16,7 +16,7 @@ in isolation with `./x.py test src/tools/tidy`. [fmt]: https://github.com/rust-lang-nursery/fmt-rfcs - + ### Copyright notice @@ -57,7 +57,7 @@ the copyright notice) like so: Prefer 4-space indent. - + # Coding for correctness @@ -99,7 +99,7 @@ if foo { } ``` - + # Using crates from crates.io @@ -108,7 +108,7 @@ dependencies should not be added gratuitously. All such crates must have a suitably permissive license. There is an automatic check which inspects the Cargo metadata to ensure this. - + # How to structure your PR diff --git a/src/incremental-compilation.md b/src/incremental-compilation.md index a209207fc..0a25e1664 100644 --- a/src/incremental-compilation.md +++ b/src/incremental-compilation.md @@ -76,7 +76,7 @@ Try-mark-green works as follows: - Otherwise, **all** of the nodes in `reads(Q)` must be **green**. In that case, we can color Q as **green** and return. - + ### The query DAG diff --git a/src/mir-regionck.md b/src/mir-regionck.md index 4158b7d38..e67e91138 100644 --- a/src/mir-regionck.md +++ b/src/mir-regionck.md @@ -51,7 +51,7 @@ the role of `liveness_constraints` vs other `constraints`, plus *to be written* - + ## The MIR type-check @@ -88,7 +88,7 @@ The kinds of region elements are as follows: *to be written* -- describe how we can extend the values of a variable with causal tracking etc - + ## Skolemization and universes diff --git a/src/mir.md b/src/mir.md index da468acf4..81bbf6bd6 100644 --- a/src/mir.md +++ b/src/mir.md @@ -234,7 +234,7 @@ but [you can read about those below](#promoted)). *to be written* - + ### Promoted constants diff --git a/src/tests/adding.md b/src/tests/adding.md index 5d4c383f2..96fc0cf84 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -68,7 +68,7 @@ then it might make sense to put the tests in directories like: In other cases, there may already be a suitable directory. (The proper directory structure to use is actually an area of active debate.) - + ## Comment explaining what the test is about @@ -90,7 +90,7 @@ test must be rewritten because it no longer tests what is was meant to test, and then it's useful to know what it *was* meant to test exactly). - + ## Header commands: configuring rustc @@ -167,7 +167,7 @@ source. [`header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs - + ## Error annotations @@ -229,7 +229,7 @@ currently only apply to the test as a whole, not to particular revisions. The only headers that are intended to really work when customized to a revision are error patterns and compiler flags. - + ## Guide to the UI tests diff --git a/src/traits-associated-types.md b/src/traits-associated-types.md index eaf497875..51972c41e 100644 --- a/src/traits-associated-types.md +++ b/src/traits-associated-types.md @@ -22,6 +22,8 @@ though that is something we may want to change in the future.) [intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item + + In some cases, associated type projections can be **normalized** -- that is, simplified -- based on the types given in an impl. So, to continue with our example, the impl of `IntoIterator` for `Option` diff --git a/src/traits-bibliography.md b/src/traits-bibliography.md index 02607b525..b8f345d9d 100644 --- a/src/traits-bibliography.md +++ b/src/traits-bibliography.md @@ -10,7 +10,7 @@ new every time you open it. [phl]: https://www.amazon.com/Programming-Higher-Order-Logic-Dale-Miller/dp/052187940X - + ["A proof procedure for the logic of Hereditary Harrop formulas"][pphhf], by Gopalan Nadathur. This paper covers the basics of universes, @@ -18,7 +18,7 @@ environments, and Lambda Prolog-style proof search. Quite readable. [pphhf]: https://dl.acm.org/citation.cfm?id=868380 - + ["A new formulation of tabled resolution with delay"][nftrd], by [Theresa Swift]. This paper gives a kind of abstract treatment of the diff --git a/src/traits-canonical-queries.md b/src/traits-canonical-queries.md index 3c4bb1bfe..2737737bb 100644 --- a/src/traits-canonical-queries.md +++ b/src/traits-canonical-queries.md @@ -95,7 +95,7 @@ Rc: Clone After all, `Rc` is true **no matter what type `?T` is**. - + ## A trait query in rustc diff --git a/src/traits-goals-and-clauses.md b/src/traits-goals-and-clauses.md index 5e8ee1469..0cbdb7077 100644 --- a/src/traits-goals-and-clauses.md +++ b/src/traits-goals-and-clauses.md @@ -39,11 +39,11 @@ gives the details. [pphhf]: ./traits-bibliography.html#pphhf - + ## Domain goals - + To define the set of *domain goals* in our system, we need to first introduce a few simple formulations. A **trait reference** consists of @@ -58,7 +58,7 @@ IntoIterator`. Note that Rust surface syntax also permits some extra things, like associated type bindings (`Vec: IntoIterator`), that are not part of a trait reference. - + A **projection** consists of an associated item reference along with its inputs P0..Pm: @@ -105,7 +105,7 @@ DomainGoal = Implemented(TraitRef) [n]: ./traits-associated-types.html#normalize - + ## Coinductive goals diff --git a/src/traits-lowering-module.md b/src/traits-lowering-module.md index fbf1d6425..08e0b9523 100644 --- a/src/traits-lowering-module.md +++ b/src/traits-lowering-module.md @@ -18,7 +18,7 @@ returns a vector of program clauses. [query]: ./query.html - + ## Unit tests diff --git a/src/traits-lowering-rules.md b/src/traits-lowering-rules.md index f7433221e..73660c42c 100644 --- a/src/traits-lowering-rules.md +++ b/src/traits-lowering-rules.md @@ -94,7 +94,7 @@ forall { } ``` - + #### Implied bounds @@ -176,7 +176,7 @@ we must show that `WellFormed(TraitRef)`. This in turn justifies the implied bounds rules that allow us to extend the set of `FromEnv` items. - + ## Lowering trait items @@ -291,7 +291,7 @@ forall { Note that `WC` and `WC1` both encode where-clauses that the impl can rely on. - + ### Function and constant values diff --git a/src/type-inference.md b/src/type-inference.md index 152bbd9da..e480b2b56 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -43,7 +43,7 @@ The `tcx.infer_ctxt` method actually returns a builder, which means there are some kinds of configuration you can do before the `infcx` is created. See `InferCtxtBuilder` for more information. - + ## Inference variables diff --git a/src/variance.md b/src/variance.md index 527c2745c..08399b5b3 100644 --- a/src/variance.md +++ b/src/variance.md @@ -141,7 +141,7 @@ will wind up being considered green after it is re-evaluated. [rga]: ./incremental-compilation.html - + ## Addendum: Variance on traits From 8cfd5c5aede5fe17cc286c230ccd2eba4cc966bd Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Thu, 10 May 2018 15:22:12 -0700 Subject: [PATCH 0209/1812] Added an overview of chalk --- src/SUMMARY.md | 1 + src/chalk-overview.md | 140 ++++++++++++++++++++++++++++++++++++++++++ src/traits-slg.md | 2 + 3 files changed, 143 insertions(+) create mode 100644 src/chalk-overview.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 1839f59cb..4923d4972 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -38,6 +38,7 @@ - [The lowering module in rustc](./traits-lowering-module.md) - [Well-formedness checking](./traits-wf.md) - [The SLG solver](./traits-slg.md) + - [An Overview of Chalk](./chalk-overview.md) - [Bibliography](./traits-bibliography.md) - [Type checking](./type-checking.md) - [Method Lookup](./method-lookup.md) diff --git a/src/chalk-overview.md b/src/chalk-overview.md new file mode 100644 index 000000000..63757f7ba --- /dev/null +++ b/src/chalk-overview.md @@ -0,0 +1,140 @@ +# An Overview of Chalk + +> Chalk is under heavy development, so if any of these links are broken or if +> any of the information is inconsistent with the code or outdated, please open +> an issue so we can fix it. If you are able to fix the issue yourself, we would +> love your contribution! + +[Chalk][chalk] recasts Rust's trait system explicitly in terms of logic +programming by "lowering" Rust code into a kind of logic program we can then +execute queries against. Its goal is to be an executable, highly readable +specification of the Rust trait system.[^negativechalk] + +There are many expected benefits from this work. It will consolidate our +existing, somewhat ad-hoc implementation into something far more principled and +expressive, which should behave better in corner cases, and be much easier to +extend.[^negativechalk] + +## Resources + +* [Chalk Source Code](https://github.com/rust-lang-nursery/chalk) +* [Chalk Glossary](https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md) +* The traits section of the rustc guide (you are here) + +### Blog Posts + +* [Lowering Rust traits to logic](http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/) +* [Unification in Chalk, part 1](http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/) +* [Unification in Chalk, part 2](http://smallcultfollowing.com/babysteps/blog/2017/04/23/unification-in-chalk-part-2/) +* [Negative reasoning in Chalk](http://aturon.github.io/blog/2017/04/24/negative-chalk/) +* [Query structure in chalk](http://smallcultfollowing.com/babysteps/blog/2017/05/25/query-structure-in-chalk/) +* [Cyclic queries in chalk](http://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/) +* [An on-demand SLG solver for chalk](http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/) + +## Parsing + +Chalk is designed to be incorporated with the Rust compiler, so the syntax and +concepts it deals with heavily borrow from Rust. It is convenient for the sake +of testing to be able to run chalk on its own, so chalk includes a parser for a +Rust-like syntax. + +The parser takes that syntax and produces an [Abstract Syntax Tree (AST)][ast]. +You can find the [complete definition of the AST][chalk-ast] in the source code. + +The syntax contains things from Rust that we know and love for example traits, +impls, and struct definitions. Parsing is often the first "phase" of +transformation that a program goes through in order to become a format that +chalk can understand. + +## Lowering + +After parsing, there is a "lowering" phase. This aims to convert traits/impls +into "program clauses". A [`ProgramClause` (source code)][programclause] is +essentially one of the following: + +* A [clause] of the form `consequence :- conditions` where `:-` is read as + "if" and `conditions = cond1 && cond2 && ...` +* A universally quantified clause of the form `forall { consequence :- conditions }` + * `forall { ... }` is used to represent [universal quantification]. See the + section on [Lowering to logic][lowering-forall] for more information. + * A key thing to note about `forall` is that we don't allow you to "quantify" + over traits, only types and regions (lifetimes). That is, you can't make a + rule like `forall { u32: Trait }` which would say "`u32` implements + all traits". You can however say `forall { T: Trait }` meaning "`Trait` + is implemented by all types". + * `forall { ... }` is represented in the code using the [`Binders` + struct][binders-struct]. + +This is the phase where we encode the rules of the trait system into logic. For +example, if we have: + +```rust +impl Clone for Vec {} +``` + +We generate: + +```rust +forall { (Vec: Clone) :- (T: Clone) } +``` + +This rule dictates that `Vec: Clone` is only satisfied if `T: Clone` is also +satisfied (i.e. "provable"). + +### Well-formedness checks + +As part of lowering from the AST to the internal IR, we also do some "well +formedness" checks. See the [source code][well-formedness-checks] for where +those are done. The call to `record_specialization_priorities` checks +"coherence" which means that it ensures that two impls of the same trait for the +same type cannot exist. + +## Intermediate Representation (IR) + +The second intermediate representation in chalk is called, well, the "ir". :) +The [IR source code][ir-code] contains the complete definition. The +`ir::Program` struct contains some "rust things" but indexed and accessible in +a different way. This is sort of analogous to the [HIR] in Rust. + +For example, if you have a type like `Foo`, we would represent `Foo` as a +string in the AST but in `ir::Program`, we use numeric indices (`ItemId`). + +In addition to `ir::Program` which has "rust-like things", there is also +`ir::ProgramEnvironment` which is "pure logic". The main field in that is +`program_clauses` which contains the `ProgramClause`s that we generated +previously. + +## Rules + +The `rules` module works by iterating over every trait, impl, etc. and emitting +the rules that come from each one. The traits section of the rustc-guide (that +you are currently reading) contains the most up-to-date reference on that. + +The `ir::ProgramEnvironment` is created [in this module][rules-environment]. + +## Testing + +TODO: Basically, [there is a macro](https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/solve/test/mod.rs#L112-L148) +that will take syntax and run it through the full pipeline described above. +[This](https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/solve/test/mod.rs#L83-L110) +is the function that is ultimately called. + +## Solver + +See [The SLG Solver][slg]. + +[^negativechalk]: [*Negative reasoning in Chalk* by Aaron Turon](http://aturon.github.io/blog/2017/04/24/negative-chalk/) + +[chalk]: https://github.com/rust-lang-nursery/chalk +[ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree +[chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs +[universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification +[lowering-forall]: traits-lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses +[programclause]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/ir/mod.rs#L721 +[clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause +[well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/ir/lowering/mod.rs#L230-L232 +[ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/ir/mod.rs +[HIR]: hir.html +[binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/ir/mod.rs#L661 +[rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/rules/mod.rs#L9 +[slg]: traits-slg.html diff --git a/src/traits-slg.md b/src/traits-slg.md index cdd52ece9..1dc56e14c 100644 --- a/src/traits-slg.md +++ b/src/traits-slg.md @@ -1 +1,3 @@ # The SLG solver + +TODO: From 58ef5a78deb90d0e0306b85bb5ee70fd76eecf6a Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Thu, 10 May 2018 15:43:18 -0700 Subject: [PATCH 0210/1812] Lines must be <= 80 characters UNLESS there is a link --- src/chalk-overview.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/chalk-overview.md b/src/chalk-overview.md index 63757f7ba..8c5bc1594 100644 --- a/src/chalk-overview.md +++ b/src/chalk-overview.md @@ -54,7 +54,8 @@ essentially one of the following: * A [clause] of the form `consequence :- conditions` where `:-` is read as "if" and `conditions = cond1 && cond2 && ...` -* A universally quantified clause of the form `forall { consequence :- conditions }` +* A universally quantified clause of the form + `forall { consequence :- conditions }` * `forall { ... }` is used to represent [universal quantification]. See the section on [Lowering to logic][lowering-forall] for more information. * A key thing to note about `forall` is that we don't allow you to "quantify" @@ -129,7 +130,7 @@ See [The SLG Solver][slg]. [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification -[lowering-forall]: traits-lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses +[lowering-forall]: https://rust-lang-nursery.github.io/rustc-guide/traits-lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses [programclause]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/ir/mod.rs#L721 [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause [well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/ir/lowering/mod.rs#L230-L232 From b9eb2b6c1369fbaf4a5a845ab3a7dde050c71e23 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Thu, 10 May 2018 15:48:24 -0700 Subject: [PATCH 0211/1812] Ignoring code examples that aren't actually compile-able --- src/chalk-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/chalk-overview.md b/src/chalk-overview.md index 8c5bc1594..49f685149 100644 --- a/src/chalk-overview.md +++ b/src/chalk-overview.md @@ -69,13 +69,13 @@ essentially one of the following: This is the phase where we encode the rules of the trait system into logic. For example, if we have: -```rust +```rust,ignore impl Clone for Vec {} ``` We generate: -```rust +```rust,ignore forall { (Vec: Clone) :- (T: Clone) } ``` From c11f57a262f69c0dfce3310e0a70d3da0a3040a6 Mon Sep 17 00:00:00 2001 From: C Jones Date: Fri, 11 May 2018 18:16:15 -0400 Subject: [PATCH 0212/1812] Make chapter links in compiletest not be code mdBook doesn't display links inside code, so these links look very confusing. Additionally, these types of links don't seem to be code on other pages of the book. --- src/compiletest.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index 363c12d3b..cdcede33a 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -13,7 +13,7 @@ cases, even failure to compile. Tests are typically organized as a Rust source file with annotations in comments before and/or within the test code, which serve to direct `compiletest` on if or how to run the test, what behavior to expect, and more. If you are unfamiliar with the compiler testing framework, -see [`this chapter`](./tests/intro.html) for additional background. +see [this chapter](./tests/intro.html) for additional background. The tests themselves are typically (but not always) organized into "suites"--for example, `run-pass`, a folder representing tests that should @@ -22,8 +22,8 @@ but return a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various suites are defined in [src/tools/compiletest/src/common.rs][common] in the `pub struct Config` declaration. And a very good introduction to the different suites of compiler -tests along with details about them can be found in [`Adding new -tests`](./tests/adding.html). +tests along with details about them can be found in [Adding new +tests](./tests/adding.html). ## Adding a new test file From f601a3aacaa32b77325e051b9f644d85d0e650b0 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Fri, 11 May 2018 17:14:26 -0700 Subject: [PATCH 0213/1812] Updating links to match latest code --- src/chalk-overview.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/chalk-overview.md b/src/chalk-overview.md index 49f685149..7cea6acef 100644 --- a/src/chalk-overview.md +++ b/src/chalk-overview.md @@ -115,9 +115,9 @@ The `ir::ProgramEnvironment` is created [in this module][rules-environment]. ## Testing -TODO: Basically, [there is a macro](https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/solve/test/mod.rs#L112-L148) +TODO: Basically, [there is a macro](https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/solve/test.rs#L112-L148) that will take syntax and run it through the full pipeline described above. -[This](https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/solve/test/mod.rs#L83-L110) +[This](https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/solve/test.rs#L83-L110) is the function that is ultimately called. ## Solver @@ -131,11 +131,11 @@ See [The SLG Solver][slg]. [chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification [lowering-forall]: https://rust-lang-nursery.github.io/rustc-guide/traits-lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses -[programclause]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/ir/mod.rs#L721 +[programclause]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L721 [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause -[well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/ir/lowering/mod.rs#L230-L232 -[ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/ir/mod.rs +[well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir/lowering.rs#L230-L232 +[ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/ir.rs [HIR]: hir.html -[binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/ir/mod.rs#L661 -[rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/17abbabe53c2f78b04af04a9bc9e8a0e3fc676e3/src/rules/mod.rs#L9 +[binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 +[rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 [slg]: traits-slg.html From 359e814c8c46cb917e318b753b2ecfc0cb98f6cb Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 8 May 2018 12:40:43 -0500 Subject: [PATCH 0214/1812] reword HIR intro. Fix #116 --- src/hir.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/hir.md b/src/hir.md index 3d2fbede3..51296e55e 100644 --- a/src/hir.md +++ b/src/hir.md @@ -1,11 +1,12 @@ # The HIR -The HIR – "High-level IR" – is the primary IR used in most of rustc. -It is a desugared version of the "abstract syntax tree" (AST) that is generated -after parsing, macro expansion, and name resolution have completed. Many parts -of HIR resemble Rust surface syntax quite closely, with the exception that some -of Rust's expression forms have been desugared away (as an example, `for` loops -are converted into a `loop` and do not appear in the HIR). +The HIR – "High-level IR" – is the primary IR used in most of rustc. It is a +compiler-friendly representation of the abstract syntax tree (AST) that is +generated after parsing, macro expansion, and name resolution have completed. +Many parts of HIR resemble Rust surface syntax quite closely, with the +exception that some of Rust's expression forms have been desugared away. For +example, `for` loops are converted into a `loop` and do not appear in the HIR. +This makes HIR more amenable to analysis than a normal AST. This chapter covers the main concepts of the HIR. From b6f63df3eb956af20b00c520697301a75046285e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 12 May 2018 15:01:58 -0500 Subject: [PATCH 0215/1812] remove have completed --- src/hir.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hir.md b/src/hir.md index 51296e55e..06ee5e105 100644 --- a/src/hir.md +++ b/src/hir.md @@ -2,7 +2,7 @@ The HIR – "High-level IR" – is the primary IR used in most of rustc. It is a compiler-friendly representation of the abstract syntax tree (AST) that is -generated after parsing, macro expansion, and name resolution have completed. +generated after parsing, macro expansion, and name resolution. Many parts of HIR resemble Rust surface syntax quite closely, with the exception that some of Rust's expression forms have been desugared away. For example, `for` loops are converted into a `loop` and do not appear in the HIR. From 5f58b0dc98c78f31f8b692543f0c798995034b51 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Mon, 14 May 2018 10:52:21 -0700 Subject: [PATCH 0216/1812] Changes from review --- src/chalk-overview.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/src/chalk-overview.md b/src/chalk-overview.md index 7cea6acef..cd2c98b88 100644 --- a/src/chalk-overview.md +++ b/src/chalk-overview.md @@ -1,19 +1,20 @@ # An Overview of Chalk > Chalk is under heavy development, so if any of these links are broken or if -> any of the information is inconsistent with the code or outdated, please open -> an issue so we can fix it. If you are able to fix the issue yourself, we would +> any of the information is inconsistent with the code or outdated, please +> [open an issue][rustc-issues] so we can fix it. If you are able to fix the issue yourself, we would > love your contribution! [Chalk][chalk] recasts Rust's trait system explicitly in terms of logic programming by "lowering" Rust code into a kind of logic program we can then -execute queries against. Its goal is to be an executable, highly readable -specification of the Rust trait system.[^negativechalk] +execute queries against. (See [*Lowering to Logic*][lowering-to-logic] and +[*Lowering Rules*][lowering-rules]) Its goal is to be an executable, highly +readable specification of the Rust trait system. There are many expected benefits from this work. It will consolidate our existing, somewhat ad-hoc implementation into something far more principled and expressive, which should behave better in corner cases, and be much easier to -extend.[^negativechalk] +extend. ## Resources @@ -124,9 +125,10 @@ is the function that is ultimately called. See [The SLG Solver][slg]. -[^negativechalk]: [*Negative reasoning in Chalk* by Aaron Turon](http://aturon.github.io/blog/2017/04/24/negative-chalk/) - +[rustc-issues]: https://github.com/rust-lang-nursery/rustc-guide/issues [chalk]: https://github.com/rust-lang-nursery/chalk +[lowering-to-logic]: traits-lowering-to-logic.html +[lowering-rules]: traits-lowering-rules.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification From edddf9fa3b606526cf059e52e64c64f2ce23c590 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Mon, 14 May 2018 11:18:14 -0700 Subject: [PATCH 0217/1812] More review changes --- src/chalk-overview.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/src/chalk-overview.md b/src/chalk-overview.md index cd2c98b88..926c7f5ac 100644 --- a/src/chalk-overview.md +++ b/src/chalk-overview.md @@ -2,8 +2,8 @@ > Chalk is under heavy development, so if any of these links are broken or if > any of the information is inconsistent with the code or outdated, please -> [open an issue][rustc-issues] so we can fix it. If you are able to fix the issue yourself, we would -> love your contribution! +> [open an issue][rustc-issues] so we can fix it. If you are able to fix the +> issue yourself, we would love your contribution! [Chalk][chalk] recasts Rust's trait system explicitly in terms of logic programming by "lowering" Rust code into a kind of logic program we can then @@ -42,7 +42,7 @@ Rust-like syntax. The parser takes that syntax and produces an [Abstract Syntax Tree (AST)][ast]. You can find the [complete definition of the AST][chalk-ast] in the source code. -The syntax contains things from Rust that we know and love for example traits, +The syntax contains things from Rust that we know and love, for example: traits, impls, and struct definitions. Parsing is often the first "phase" of transformation that a program goes through in order to become a format that chalk can understand. @@ -67,14 +67,14 @@ essentially one of the following: * `forall { ... }` is represented in the code using the [`Binders` struct][binders-struct]. -This is the phase where we encode the rules of the trait system into logic. For -example, if we have: +Lowering is the phase where we encode the rules of the trait system into logic. +For example, if we have the following Rust: ```rust,ignore impl Clone for Vec {} ``` -We generate: +We generate the following program clause: ```rust,ignore forall { (Vec: Clone) :- (T: Clone) } @@ -102,22 +102,23 @@ For example, if you have a type like `Foo`, we would represent `Foo` as a string in the AST but in `ir::Program`, we use numeric indices (`ItemId`). In addition to `ir::Program` which has "rust-like things", there is also -`ir::ProgramEnvironment` which is "pure logic". The main field in that is +`ir::ProgramEnvironment` which is "pure logic". The main field in that struct is `program_clauses` which contains the `ProgramClause`s that we generated previously. ## Rules The `rules` module works by iterating over every trait, impl, etc. and emitting -the rules that come from each one. The traits section of the rustc-guide (that -you are currently reading) contains the most up-to-date reference on that. +the rules that come from each one. See [Lowering Rules][lowering-rules] for the +most up-to-date reference on that. The `ir::ProgramEnvironment` is created [in this module][rules-environment]. ## Testing TODO: Basically, [there is a macro](https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/solve/test.rs#L112-L148) -that will take syntax and run it through the full pipeline described above. +that will take chalk's Rust-like syntax and run it through the full pipeline +described above. [This](https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/solve/test.rs#L83-L110) is the function that is ultimately called. From 7f83d68118ee2b48768691fcb2bd0d3388b0c41a Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Mon, 14 May 2018 11:21:20 -0700 Subject: [PATCH 0218/1812] Even more review changes --- src/chalk-overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/chalk-overview.md b/src/chalk-overview.md index 926c7f5ac..02e094293 100644 --- a/src/chalk-overview.md +++ b/src/chalk-overview.md @@ -37,7 +37,8 @@ extend. Chalk is designed to be incorporated with the Rust compiler, so the syntax and concepts it deals with heavily borrow from Rust. It is convenient for the sake of testing to be able to run chalk on its own, so chalk includes a parser for a -Rust-like syntax. +Rust-like syntax. This syntax is orthogonal to the Rust AST and grammar. It is +not intended to look exactly like it or support the exact same syntax. The parser takes that syntax and produces an [Abstract Syntax Tree (AST)][ast]. You can find the [complete definition of the AST][chalk-ast] in the source code. From 389bd079a8c2c6032914b60790fbde220c93ebb4 Mon Sep 17 00:00:00 2001 From: Sunjay Varma Date: Mon, 14 May 2018 11:26:15 -0700 Subject: [PATCH 0219/1812] Missed a few things because of GitHub's UI --- src/chalk-overview.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/chalk-overview.md b/src/chalk-overview.md index 02e094293..76c119a5e 100644 --- a/src/chalk-overview.md +++ b/src/chalk-overview.md @@ -68,6 +68,8 @@ essentially one of the following: * `forall { ... }` is represented in the code using the [`Binders` struct][binders-struct]. +*See also: [Goals and Clauses][goals-and-clauses]* + Lowering is the phase where we encode the rules of the trait system into logic. For example, if we have the following Rust: @@ -137,6 +139,7 @@ See [The SLG Solver][slg]. [lowering-forall]: https://rust-lang-nursery.github.io/rustc-guide/traits-lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses [programclause]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L721 [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause +[goals-and-clauses]: traits-goals-and-clauses.html [well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir/lowering.rs#L230-L232 [ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/ir.rs [HIR]: hir.html From 2dc19d097a9f5a8ab0a72ba79b0440cf6baa706f Mon Sep 17 00:00:00 2001 From: Takanori Ishibashi Date: Tue, 15 May 2018 21:59:30 +0900 Subject: [PATCH 0220/1812] invokations -> invocations --- src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index ba807faf2..a90ad517b 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -2,7 +2,7 @@ Macro expansion happens during parsing. `rustc` has two parsers, in fact: the normal Rust parser, and the macro parser. During the parsing phase, the normal -Rust parser will set aside the contents of macros and their invokations. Later, +Rust parser will set aside the contents of macros and their invocations. Later, before name resolution, macros are expanded using these portions of the code. The macro parser, in turn, may call the normal Rust parser when it needs to bind a metavariable (e.g. `$my_expr`) while parsing the contents of a macro From 2bd5354411251de6512b025f8f24b56111b56719 Mon Sep 17 00:00:00 2001 From: Alex Kitchens Date: Thu, 17 May 2018 12:53:11 -0500 Subject: [PATCH 0221/1812] Define HIR more specifically IR is a foreign acronym to me, so having it fully expressed in the beginning as Intermediate Representation helps me comprehend the subject. --- src/high-level-overview.md | 5 +++-- src/hir.md | 10 +++++----- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 9f3b63a54..be396054b 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -104,8 +104,8 @@ take: nodes, and hence may strip things out of the AST as well. 3. **Lowering to HIR** - Once name resolution completes, we convert the AST into the HIR, - or "high-level IR". The HIR is defined in `src/librustc/hir/`; - that module also includes the lowering code. + or "[high-level intermediate representation]". The HIR is defined in + `src/librustc/hir/`; that module also includes the lowering code. - The HIR is a lightly desugared variant of the AST. It is more processed than the AST and more suitable for the analyses that follow. It is **not** required to match the syntax of the Rust language. @@ -138,3 +138,4 @@ take: [query model]: query.html +[high-level intermediate representation]: hir.html diff --git a/src/hir.md b/src/hir.md index 06ee5e105..44c4968b1 100644 --- a/src/hir.md +++ b/src/hir.md @@ -1,10 +1,10 @@ # The HIR -The HIR – "High-level IR" – is the primary IR used in most of rustc. It is a -compiler-friendly representation of the abstract syntax tree (AST) that is -generated after parsing, macro expansion, and name resolution. -Many parts of HIR resemble Rust surface syntax quite closely, with the -exception that some of Rust's expression forms have been desugared away. For +The HIR – "High-Level Intermediate Representation" – is the primary IR used in +most of rustc. It is a compiler-friendly representation of the abstract syntax +tree (AST) that is generated after parsing, macro expansion, and name +resolution. Many parts of HIR resemble Rust surface syntax quite closely, with +the exception that some of Rust's expression forms have been desugared away. For example, `for` loops are converted into a `loop` and do not appear in the HIR. This makes HIR more amenable to analysis than a normal AST. From f91de90ea2bf253765de82ebc233d048c592013a Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Mon, 21 May 2018 13:16:16 +0200 Subject: [PATCH 0222/1812] Add type inference example This should make the chapter a bit more approachable, as it doesn't start with a reference to the HM type inference algorithm. --- src/type-inference.md | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/src/type-inference.md b/src/type-inference.md index e480b2b56..4795e23c1 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -1,5 +1,21 @@ # Type inference +Type inference is the process of automatic detection of the type of an +expression. + +It is what allows Rust to work with fewer or no type annotations, +making things easier for users: + +```rust,ignore +fn main() { + let mut things = vec![]; + things.push("thing") +} +``` + +Here, `things` is *inferenced* to be `&str` because that's the value we push +into `things`. + The type inference is based on the standard Hindley-Milner (HM) type inference algorithm, but extended in various way to accommodate subtyping, region inference, and higher-ranked types. @@ -173,7 +189,7 @@ mechanism. You'll have to try again when more details about `?T` or ## Region constraints -Regions are inferred somewhat differently from types. Rather than +Regions are inferenced somewhat differently from types. Rather than eagerly unifying things, we simply collect constraints as we go, but make (almost) no attempt to solve regions. These constraints have the form of an "outlives" constraint: @@ -189,7 +205,7 @@ idea: 'b <= 'a ``` -(There are various other kinds of constriants, such as "verifys"; see +(There are various other kinds of constraints, such as "verifys"; see the `region_constraints` module for details.) There is one case where we do some amount of eager unification. If you have an From 6315267608a7a611228acb79a15dee214908de59 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Mon, 21 May 2018 19:44:07 +0200 Subject: [PATCH 0223/1812] The type is inferenced, not things itself. --- src/type-inference.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/type-inference.md b/src/type-inference.md index 4795e23c1..9ae88decd 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -13,8 +13,8 @@ fn main() { } ``` -Here, `things` is *inferenced* to be `&str` because that's the value we push -into `things`. +Here, the type of `things` is *inferenced* to be `&str` because that's the value +we push into `things`. The type inference is based on the standard Hindley-Milner (HM) type inference algorithm, but extended in various way to accommodate subtyping, region From 3b0d3f27a5548c4405d189fd4e54cd78bde5e0bc Mon Sep 17 00:00:00 2001 From: Alex Kitchens Date: Tue, 22 May 2018 16:30:05 -0500 Subject: [PATCH 0224/1812] Define a Cycle I wasn't clear on what a Cycle was when reading through the document. Defining it will be helpful for other readers not familiar with it as well. --- src/query.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/query.md b/src/query.md index 2c518ee55..d48b6e7e3 100644 --- a/src/query.md +++ b/src/query.md @@ -47,6 +47,9 @@ let ty = tcx.type_of(some_def_id); ### Cycles between queries +A cycle is when a query becomes stuck in a loop e.g. query A generates query B +which generates query A again. + Currently, cycles during query execution should always result in a compilation error. Typically, they arise because of illegal programs that contain cyclic references they shouldn't (though sometimes they From 3d48815cf4b899a48a70365de977721dbc30a51f Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Wed, 23 May 2018 11:55:16 +0200 Subject: [PATCH 0225/1812] Fixes #141 --- src/tests/adding.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 96fc0cf84..16e4982b0 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -266,13 +266,16 @@ you can even run the resulting program. Just add one of the following ### Editing and updating the reference files If you have changed the compiler's output intentionally, or you are -making a new test, you can use the script `ui/update-references.sh` to -update the references. When you run the test framework, it will report -various errors: in those errors is a command you can use to run the -`ui/update-references.sh` script, which will then copy over the files -from the build directory and use them as the new reference. You can -also just run `ui/update-all-references.sh`. In both cases, you can run -the script with `--help` to get a help message. +making a new test, you can pass `--bless` to the test subcommand. E.g. +if some tests in `src/test/ui` are failing, you can run + +``` +./x.py test --stage 1 src/test/ui --bless +``` + +to automatically adjust the `.stderr`, `.stdout` or `.fixed` files of +all tests. Of course you can also target just specific tests with the +`--test-args your_test_name` flag, just like when running the tests. ### Normalization From 50f44216f4082cb66c76cc636b400faa2dc212cf Mon Sep 17 00:00:00 2001 From: Takanori Ishibashi Date: Sat, 26 May 2018 16:36:27 +0900 Subject: [PATCH 0226/1812] Fix typo --- src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index a90ad517b..df0dc7b1d 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -89,7 +89,7 @@ against the pattern `ms`. Using our examples, `tts` could be the stream of tokens containing the inside of the example invocation `print foo`, while `ms` might be the sequence of token (trees) `print $mvar:ident`. -The output of the parser is a `NamedParserResult`, which indicates which of +The output of the parser is a `NamedParseResult`, which indicates which of three cases has occured: - Success: `tts` matches the given matcher `ms`, and we have produced a binding From 2debb43b5a8e8e1a3feec20d05b88b2de0210284 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Fri, 11 May 2018 21:06:21 -0500 Subject: [PATCH 0227/1812] Clarify language in Trait Resolution --- src/trait-resolution.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/trait-resolution.md b/src/trait-resolution.md index 5bf8f8716..b9fa81bd6 100644 --- a/src/trait-resolution.md +++ b/src/trait-resolution.md @@ -202,8 +202,8 @@ impl Get for Box { What happens when we invoke `get_it(&Box::new(1_u16))`, for example? In this case, the `Self` type is `Box` – that unifies with both impls, -because the first applies to all types, and the second to all -boxes. In order for this to be unambiguous, the compiler does a *winnowing* +because the first applies to all types `T`, and the second to all +`Box`. In order for this to be unambiguous, the compiler does a *winnowing* pass that considers `where` clauses and attempts to remove candidates. In this case, the first impl only applies if `Box : Copy`, which doesn't hold. After winnowing, @@ -242,7 +242,7 @@ fn foo(x: X) { In the body of `foo`, clearly we can use methods of `A1`, `A2`, or `B` on variable `x`. The line marked `(*)` will incur an obligation `X: A1`, -which the line marked `(#)` will incur an obligation `X: B`. Meanwhile, +while the line marked `(#)` will incur an obligation `X: B`. Meanwhile, the parameter environment will contain two where-clauses: `X : A2` and `X : B`. For each obligation, then, we search this list of where-clauses. The obligation `X: B` trivially matches against the where-clause `X: B`. From bb867865fe48a8ff2bcce9c1d85683f2836a71eb Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Fri, 25 May 2018 23:03:09 -0400 Subject: [PATCH 0228/1812] Trait logic: Explain what each domain goal means --- src/traits-goals-and-clauses.md | 95 +++++++++++++++++++++++++-------- src/traits-lowering-rules.md | 2 +- 2 files changed, 73 insertions(+), 24 deletions(-) diff --git a/src/traits-goals-and-clauses.md b/src/traits-goals-and-clauses.md index 0cbdb7077..882f86b8e 100644 --- a/src/traits-goals-and-clauses.md +++ b/src/traits-goals-and-clauses.md @@ -67,7 +67,7 @@ its inputs P0..Pm: Projection = >::AssocItem ``` -Given that, we can define a `DomainGoal` as follows: +Given these, we can define a `DomainGoal` as follows: ```text DomainGoal = Implemented(TraitRef) @@ -78,33 +78,82 @@ DomainGoal = Implemented(TraitRef) | WellFormed(Type) | WellFormed(TraitRef) | WellFormed(Projection = Type) - | Outlives(Type, Region) - | Outlives(Region, Region) + | Outlives(Type: Region) + | Outlives(Region: Region) ``` -- `Implemented(TraitRef)` -- true if the given trait is - implemented for the given input types and lifetimes -- `FromEnv(TraitEnv)` -- true if the given trait is *assumed* to be implemented; - that is, if it can be derived from the in-scope where clauses - - as we'll see in the section on lowering, `FromEnv(X)` implies - `Implemented(X)` but not vice versa. This distinction is crucial - to [implied bounds]. -- `ProjectionEq(Projection = Type)` -- the given associated type `Projection` - is equal to `Type`; see [the section on associated - types](./traits-associated-types.html) - - in general, proving `ProjectionEq(TraitRef::Item = Type)` also - requires proving `Implemented(TraitRef)` -- `Normalize(Projection -> Type)` -- the given associated type `Projection` can - be [normalized][n] to `Type` - - as discussed in [the section on associated - types](./traits-associated-types.html), - `Normalize` implies `ProjectionEq` but not vice versa -- `WellFormed(..)` -- these goals imply that the given item is - *well-formed* - - well-formedness is important to [implied bounds]. +Let's break down each one of these, one-by-one. + +#### Implemented(TraitRef) +e.g. `Implemented(i32: Copy)` + +True if the given trait is implemented for the given input types and lifetimes. + +#### ProjectionEq(Projection = Type) +e.g. `ProjectionEq::Item = u8` + +The given associated type `Projection` is equal to `Type`; this can be proved +with either normalization or using skolemized types. See [the section +on associated types](./traits-associated-types.html). + +#### Normalize(Projection -> Type) +e.g. `ProjectionEq::Item -> u8` + +The given associated type `Projection` can be [normalized][n] to `Type`. + +As discussed in [the section on associated +types](./traits-associated-types.html), `Normalize` implies `ProjectionEq`, +but not vice versa. In general, proving `Normalize(::Item -> U)` +also requires proving `Implemented(T: Trait)`. [n]: ./traits-associated-types.html#normalize +#### FromEnv(TraitRef), FromEnv(Projection = Type) +e.g. `FromEnv(Self: Add)` + +e.g. `FromEnv(::Item<'a> = &'a [u8])` + +True if the inner `TraitRef` or projection equality is *assumed* to be true; +that is, if it can be derived from the in-scope where clauses. + +For example, given the following function: + +```rust +fn loud_clone(stuff: &T) -> T { + println!("cloning!"); + stuff.clone() +} +``` + +Inside the body of our function, we would have `FromEnv(T: Clone)`. In-scope +where clauses nest, so a function body inside an impl body inherits the +impl body's where clauses, too. + +This and the next rule are used to implement [implied bounds]. As we'll see +in the section on lowering, `FromEnv(X)` implies `Implemented(X)`, but not +vice versa. This distinction is crucial to implied bounds. + +#### WellFormed(Item) +These goals imply that the given item is *well-formed*. + +We can talk about different types of items being well-formed: + +**Types**, like `WellFormed(Vec)`, which is true in Rust, or + `WellFormed(Vec)`, which is not (because `str` is not `Sized`.) + +**TraitRefs**, like `WellFormed(Vec: Clone)`. + +**Projections**, like `WellFormed(T: Iterator)`. + +Well-formedness is important to [implied bounds]. In particular, the reason +it is okay to assume `FromEnv(T: Clone)` in the example above is that we +_also_ verify `WellFormed(T: Clone)` for each call site of `loud_clone`. + +#### Outlives(Type: Region), Outlives(Region: Region) +e.g. `Outlives(&'a str: 'b)`, `Outlives('a: 'static)` + +True if the given type or region on the left outlives the right-hand region. + ## Coinductive goals diff --git a/src/traits-lowering-rules.md b/src/traits-lowering-rules.md index 73660c42c..80884cbdd 100644 --- a/src/traits-lowering-rules.md +++ b/src/traits-lowering-rules.md @@ -113,7 +113,7 @@ forall { ``` This clause says that if we are assuming that the trait holds, then we can also -assume that it's where-clauses hold. It's perhaps useful to see an example: +assume that its where-clauses hold. It's perhaps useful to see an example: ```rust,ignore trait Eq: PartialEq { ... } From 5106793010757c9fe7eae9a3b8ea8788bdaeb5f6 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 13:40:37 -0500 Subject: [PATCH 0229/1812] Add info about emitting lints and errors --- src/SUMMARY.md | 1 + src/appendix-code-index.md | 3 + src/diag.md | 176 +++++++++++++++++++++++++++++++++++++ 3 files changed, 180 insertions(+) create mode 100644 src/diag.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4923d4972..2db3e62c3 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -54,6 +54,7 @@ - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) - [Generating LLVM IR](./trans.md) +- [Emitting Diagnostics](./diag.md) --- diff --git a/src/appendix-code-index.md b/src/appendix-code-index.md index 62edd0f5b..915d00828 100644 --- a/src/appendix-code-index.md +++ b/src/appendix-code-index.md @@ -8,11 +8,13 @@ Item | Kind | Short description | Chapter | ----------------|----------|-----------------------------|--------------------|------------------- `CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser] | [src/libsyntax/codemap.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html) `CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html) +`DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) `ast::Crate` | struct | Syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) `hir::Crate` | struct | More abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) `ParseSess` | struct | This struct contains information about a parsing session | [the Parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) `Session` | struct | The data associated with a compilation session | [the Parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) +`Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) @@ -24,3 +26,4 @@ Item | Kind | Short description | Chapter | [Type checking]: type-checking.html [The `ty` modules]: ty.html [Rustdoc]: rustdoc.html +[Emitting Diagnostics]: diag.html diff --git a/src/diag.md b/src/diag.md new file mode 100644 index 000000000..25f45e002 --- /dev/null +++ b/src/diag.md @@ -0,0 +1,176 @@ +# Emitting Diagnostics + +A lot of effort has been put into making `rustc` have great error messages. +This chapter is about how to emit compile errors and lints from the compiler. + +## `Span` + +`Span` is the primary data structure in `rustc` used to represent a location in +the code being compiled. `Span`s are attached to most constructs in HIR and MIR, +allowing for easier error reporting whenever an error comes up. + +A `Span` can be looked up in a `CodeMap` to get a "snippet" useful for +displaying errors with [`span_to_snippet` and other similar methods][sptosnip] +on the `CodeMap`. + +[sptosnip]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html#method.span_to_snippet + +## Error messages + +The [`rustc_errors`][errors] crate defines most of the utilities used for +reporting errors. + +[errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html + +Most "session"-like types in the compiler (e.g. [`Session`][session]) have +methods (or fields with methods) that allow reporting errors. These methods +usually have names like `span_err` or `struct_span_err` or `span_warn`, etc... +There are lots of them; they emit different types of "errors", such as +warnings, errors, fatal errors, suggestions, etc. + +[session]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html + +In general, there are two class of such methods: ones that emit an error +directly and ones that allow finer control over what to emit. For example, +[`span_err`][spanerr] emits the given error message at the given `Span`, but +[`struct_span_err`][strspanerr] instead returns a [`DiagnosticBuilder`][diagbuild]. + +`DiagnosticBuilder` allows you to add related notes and suggestions to an error +before emitting it by calling the [`emit`][emit] method. See the +[docs][diagbuild] for more info on what you can do. + +[spanerr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html#method.span_err +[strspanerr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html#method.struct_span_err +[diagbuild]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html +[emit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html#method.emit + +For example, to add a help message to an error, one might do: + +```rust,ignore +let snip = sess.codemap().span_to_snippet(sp); + +sess.struct_span_err(sp, "oh no! this is an error!") + .span_suggestion(other_sp, "try using a qux here", format!("qux {}", snip)) + .emit(); +``` + +This might emit an error like + +```console +$ rustc mycode.rs +error[E0999]: oh no! this is an error! + --> mycode.rs:3:5 + | +3 | sad() + | ^ help: try using a qux here: `qux sad()` + +error: aborting due to previous error + +For more information about this error, try `rustc --explain E0999`. +``` + +## Lints + +The compiler linting infrastructure is defined in the [`rustc::lint`][rlint] +module. + +[rlint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/index.html + +### Declaring a lint + +The built-in compiler lints are defined in the [`rustc_lint`][builtin] +crate. + +[builtin]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/index.html + +Each lint is defined as a `struct` that implements the `LintPass` `trait`. The +trait implementation allows you to check certain syntactic constructs the +linter walks the source code. You can then choose to emit lints in a very +similar way to compile errors. Finally, you register the lint to actually get +it to be run by the compiler by using the `declare_lint!` macro. + +For example, the following lint checks for uses +of `while true { ... }` and suggests using `loop { ... }` instead. + +```rust,ignore +// Declare a lint called `WHILE_TRUE` +declare_lint! { + WHILE_TRUE, + + // warn-by-default + Warn, + + // This string is the lint description + "suggest using `loop { }` instead of `while true { }`" +} + +// Define a struct and `impl LintPass` for it. +#[derive(Copy, Clone)] +pub struct WhileTrue; + +impl LintPass for WhileTrue { + fn get_lints(&self) -> LintArray { + lint_array!(WHILE_TRUE) + } +} + +// LateLintPass has lots of methods. We only override the definition of +// `check_expr` for this lint because that's all we need, but you could +// override other methods for your own lint. See the rustc docs for a full +// list of methods. +impl<'a, 'tcx> LateLintPass<'a, 'tcx> for WhileTrue { + fn check_expr(&mut self, cx: &LateContext, e: &hir::Expr) { + if let hir::ExprWhile(ref cond, ..) = e.node { + if let hir::ExprLit(ref lit) = cond.node { + if let ast::LitKind::Bool(true) = lit.node { + if lit.span.ctxt() == SyntaxContext::empty() { + let msg = "denote infinite loops with `loop { ... }`"; + let condition_span = cx.tcx.sess.codemap().def_span(e.span); + let mut err = cx.struct_span_lint(WHILE_TRUE, condition_span, msg); + err.span_suggestion_short(condition_span, "use `loop`", "loop".to_owned()); + err.emit(); + } + } + } + } + } +} +``` + +### Edition Lints + +Sometimes we want to change the behavior of a lint in a new edition. To do this, +we just add the transition to our invocation of `declare_lint!`: + +```rust,ignore +declare_lint! { + pub ANONYMOUS_PARAMETERS, + Allow, + "detects anonymous parameters", + Edition::Edition2018 => Warn, +} +``` + +This makes the `ANONYMOUS_PARAMETERS` lint allow-by-default in the 2015 edition +but warn-by-default in the 2018 edition. + +### Lint Groups + +Lints can be turned on in groups. These groups are declared in the +[`register_builtins`][rbuiltins] function in [`rustc_lint::lib`][builtin]. The +`add_lint_group!` macro is used to declare a new group. + +[rbuiltins]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_builtins.html + +For example, + +```rust,ignore + add_lint_group!(sess, + "nonstandard_style", + NON_CAMEL_CASE_TYPES, + NON_SNAKE_CASE, + NON_UPPER_CASE_GLOBALS); +``` + +This defines the `nonstandard_style` group which turns on the listed lints. A user +can turn on these lints by using `!#[warn(nonstandard_style)]`. From c6ecc1f9b359623b18a57c8f6fe9f324295ad886 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 13:46:33 -0500 Subject: [PATCH 0230/1812] 80 chars --- src/diag.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/diag.md b/src/diag.md index 25f45e002..6679e4249 100644 --- a/src/diag.md +++ b/src/diag.md @@ -33,7 +33,8 @@ warnings, errors, fatal errors, suggestions, etc. In general, there are two class of such methods: ones that emit an error directly and ones that allow finer control over what to emit. For example, [`span_err`][spanerr] emits the given error message at the given `Span`, but -[`struct_span_err`][strspanerr] instead returns a [`DiagnosticBuilder`][diagbuild]. +[`struct_span_err`][strspanerr] instead returns a +[`DiagnosticBuilder`][diagbuild]. `DiagnosticBuilder` allows you to add related notes and suggestions to an error before emitting it by calling the [`emit`][emit] method. See the @@ -172,5 +173,5 @@ For example, NON_UPPER_CASE_GLOBALS); ``` -This defines the `nonstandard_style` group which turns on the listed lints. A user -can turn on these lints by using `!#[warn(nonstandard_style)]`. +This defines the `nonstandard_style` group which turns on the listed lints. A +user can turn on these lints by using `!#[warn(nonstandard_style)]`. From 8a79f8b881287c923341c4a57f5c8ff99cc36217 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 14:55:55 -0500 Subject: [PATCH 0231/1812] Address reviewers' comments --- src/diag.md | 86 +++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 77 insertions(+), 9 deletions(-) diff --git a/src/diag.md b/src/diag.md index 6679e4249..a2ec3bb7e 100644 --- a/src/diag.md +++ b/src/diag.md @@ -22,12 +22,13 @@ reporting errors. [errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html -Most "session"-like types in the compiler (e.g. [`Session`][session]) have +[`Session`][session] and [`ParseSess`][parsesses] have methods (or fields with methods) that allow reporting errors. These methods usually have names like `span_err` or `struct_span_err` or `span_warn`, etc... There are lots of them; they emit different types of "errors", such as warnings, errors, fatal errors, suggestions, etc. +[parsesses]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html [session]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html In general, there are two class of such methods: ones that emit an error @@ -45,20 +46,64 @@ before emitting it by calling the [`emit`][emit] method. See the [diagbuild]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html [emit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html#method.emit -For example, to add a help message to an error, one might do: +```rust,ignore +// Get a DiagnosticBuilder. This does _not_ emit an error yet. +let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); + +// In some cases, you might need to check if `sp` is generated by a macro to +// avoid printing weird errors about macro-generated code. + +if let Some(snippet) = sess.codemap().span_to_snippet(sp) { + // Use the snippet to generate a suggested fix + err.span_suggestion(suggestion_sp, "try using a qux here", format!("qux {}", snip)); +} else { + // If we weren't able to generate a snippet, then emit a "help" message + // instead of a concrete "suggestion". In practice this is unlikely to be + // reached. + err.span_help(suggestion_sp, "you could use a qux here instead"); +} + +// emit the error +err.emit(); +``` + +## Suggestions + +We would like to make edition transitions as smooth as possible. To that end, +`rustfix` can use compiler suggestions to automatically fix code. For example, +we could use `rustfix` to mechanically apply the `qux` suggestion from the +previous example. However, not all suggestions are mechanically applicable. We +use the [`span_suggestion_with_applicability`][sswa] method of +`DiagnosticBuilder` to inform the emitter of whether a suggestion is +mechanically applicable or not. This information, in turn, is outputed by +rustc when the error format is `json`, which is used by `rustfix`. + +[sswa]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html#method.span_suggestion_with_applicability + +For example, to make our `qux` suggestion machine-applicable, we would do: ```rust,ignore -let snip = sess.codemap().span_to_snippet(sp); +let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); + +if let Some(snippet) = sess.codemap().span_to_snippet(sp) { + // Add applicability info! + err.span_suggestion_with_applicability( + suggestion_sp, + "try using a qux here", + format!("qux {}", snip), + Applicability::MachineApplicable, + ); +} else { + err.span_help(suggestion_sp, "you could use a qux here instead"); +} -sess.struct_span_err(sp, "oh no! this is an error!") - .span_suggestion(other_sp, "try using a qux here", format!("qux {}", snip)) - .emit(); +err.emit(); ``` This might emit an error like ```console -$ rustc mycode.rs +$ rustc mycode.rs error[E0999]: oh no! this is an error! --> mycode.rs:3:5 | @@ -70,10 +115,29 @@ error: aborting due to previous error For more information about this error, try `rustc --explain E0999`. ``` +In some cases, like when the suggestion spans multiple lines or when there are +multiple suggestions, the suggestions are displayed on their own: + +```console +error[E0999]: oh no! this is an error! + --> mycode.rs:3:5 + | +3 | sad() + | ^ +help: try using a qux here: + | +3 | qux sad() + | ^^^ + +error: aborting due to previous error + +For more information about this error, try `rustc --explain E0999`. +``` + ## Lints The compiler linting infrastructure is defined in the [`rustc::lint`][rlint] -module. +module. [rlint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/index.html @@ -138,7 +202,7 @@ impl<'a, 'tcx> LateLintPass<'a, 'tcx> for WhileTrue { } ``` -### Edition Lints +### Edition-gated Lints Sometimes we want to change the behavior of a lint in a new edition. To do this, we just add the transition to our invocation of `declare_lint!`: @@ -155,6 +219,10 @@ declare_lint! { This makes the `ANONYMOUS_PARAMETERS` lint allow-by-default in the 2015 edition but warn-by-default in the 2018 edition. +Lints that represent an incompatibility (i.e. error) in the upcoming edition should +also be registered as `FutureIncompatibilityLint`s in +[`register_builtins`][rbuiltins] function in [`rustc_lint::lib`][builtin]. + ### Lint Groups Lints can be turned on in groups. These groups are declared in the From 1624ba9923ef4ea161c8d1f8c51f1486040b83fe Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 15:00:27 -0500 Subject: [PATCH 0232/1812] add more on applicabilities --- src/diag.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/diag.md b/src/diag.md index a2ec3bb7e..8b067fde7 100644 --- a/src/diag.md +++ b/src/diag.md @@ -134,6 +134,18 @@ error: aborting due to previous error For more information about this error, try `rustc --explain E0999`. ``` +There are a few other [`Applicability`][appl] possibilities: + +- `MachineApplicable`: Can be applied mechanically. +- `HasPlaceholders`: Cannot be applied mechanically and has placeholder text in + the suggestions. For example, "Try adding a type: \`let x: \`". +- `MaybeIncorrect`: Cannot be applied mechanically because the suggestion may + or may not be a good one. +- `Unspecified`: Cannot be applied mechanically because we don't know which + of the above cases it falls into. + +[appl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/enum.Applicability.html + ## Lints The compiler linting infrastructure is defined in the [`rustc::lint`][rlint] From 3ea3ff8c70d5329043f42387baed707de06b4bf8 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 15:01:04 -0500 Subject: [PATCH 0233/1812] line length --- src/diag.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/diag.md b/src/diag.md index 8b067fde7..af619ed83 100644 --- a/src/diag.md +++ b/src/diag.md @@ -231,8 +231,8 @@ declare_lint! { This makes the `ANONYMOUS_PARAMETERS` lint allow-by-default in the 2015 edition but warn-by-default in the 2018 edition. -Lints that represent an incompatibility (i.e. error) in the upcoming edition should -also be registered as `FutureIncompatibilityLint`s in +Lints that represent an incompatibility (i.e. error) in the upcoming edition +should also be registered as `FutureIncompatibilityLint`s in [`register_builtins`][rbuiltins] function in [`rustc_lint::lib`][builtin]. ### Lint Groups From dbac00dedacc2988bcb8c19a88bbaece4097c3bb Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 May 2018 15:05:57 -0500 Subject: [PATCH 0234/1812] fix typo --- src/diag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/diag.md b/src/diag.md index af619ed83..6043a79b7 100644 --- a/src/diag.md +++ b/src/diag.md @@ -138,7 +138,7 @@ There are a few other [`Applicability`][appl] possibilities: - `MachineApplicable`: Can be applied mechanically. - `HasPlaceholders`: Cannot be applied mechanically and has placeholder text in - the suggestions. For example, "Try adding a type: \`let x: \`". + the suggestions. For example, "Try adding a type: \`let x: \\`". - `MaybeIncorrect`: Cannot be applied mechanically because the suggestion may or may not be a good one. - `Unspecified`: Cannot be applied mechanically because we don't know which From 1a25691cb42005ce25c2b247fcbfe8d3e992c164 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Mon, 28 May 2018 13:08:15 +0200 Subject: [PATCH 0235/1812] Mention "run-rustfix" --- src/tests/adding.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index 16e4982b0..e8075e539 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -148,6 +148,9 @@ exhaustive. Header commands can generally be found by browsing the `TestProps` structure found in [`header.rs`] from the compiletest source. +* `run-rustfix` for UI tests, indicates that the test produces + structured suggestions, which are then applied and the final + source is compiled again. * `min-{gdb,lldb}-version` * `min-llvm-version` * `compile-pass` for UI tests, indicates that the test is From 79ea4eeb149f549e5afbedbd4b30e95b8362f1a4 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Tue, 29 May 2018 15:37:24 +0200 Subject: [PATCH 0236/1812] Explain .fixed files --- src/tests/adding.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index e8075e539..daaaace7e 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -150,7 +150,8 @@ source. * `run-rustfix` for UI tests, indicates that the test produces structured suggestions, which are then applied and the final - source is compiled again. + source is stored in a `.fixed` file and compiled again. The final + compilation is required to succeed. * `min-{gdb,lldb}-version` * `min-llvm-version` * `compile-pass` for UI tests, indicates that the test is From 2d387350e2bb2d22c7051965f466c915962e77d5 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Tue, 29 May 2018 16:31:32 +0200 Subject: [PATCH 0237/1812] Satisfy travis --- src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index daaaace7e..3788e7c41 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -273,7 +273,7 @@ If you have changed the compiler's output intentionally, or you are making a new test, you can pass `--bless` to the test subcommand. E.g. if some tests in `src/test/ui` are failing, you can run -``` +```text ./x.py test --stage 1 src/test/ui --bless ``` From 8a98e397505dcfe57590a6018085cc9905d86973 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 30 May 2018 22:57:34 -0500 Subject: [PATCH 0238/1812] Update lowering rules for GATs --- src/traits-associated-types.md | 7 ++- src/traits-lowering-rules.md | 106 +++++++++++++++++++++------------ 2 files changed, 74 insertions(+), 39 deletions(-) diff --git a/src/traits-associated-types.md b/src/traits-associated-types.md index 51972c41e..ec20985ff 100644 --- a/src/traits-associated-types.md +++ b/src/traits-associated-types.md @@ -53,12 +53,15 @@ we saw above would be lowered to a program clause like so: ```text forall { - Normalize( as IntoIterator>::Item -> T) + Normalize( as IntoIterator>::Item -> T) :- + Implemented(Option: IntoIterator) } ``` +where in this case, the one `Implemented` condition is always true. + (An aside: since we do not permit quantification over traits, this is -really more like a family of predicates, one for each associated +really more like a family of program clauses, one for each associated type.) We could apply that rule to normalize either of the examples that diff --git a/src/traits-lowering-rules.md b/src/traits-lowering-rules.md index 80884cbdd..06dc67401 100644 --- a/src/traits-lowering-rules.md +++ b/src/traits-lowering-rules.md @@ -132,8 +132,6 @@ to be **well-formed**: ```text // Rule WellFormed-TraitRef -// -// For each where clause WC: forall { WellFormed(Self: Trait) :- Implemented(Self: Trait) && WellFormed(WC) } @@ -198,38 +196,72 @@ in detail in the [section on associated types](./traits-associated-types.html), but reproduced here for reference: ```text - // Rule ProjectionEq-Normalize - // - // ProjectionEq can succeed by normalizing: - forall { - ProjectionEq(>::AssocType = U) :- - Normalize(>::AssocType -> U) - } +// Rule ProjectionEq-Normalize +// +// ProjectionEq can succeed by normalizing: +forall { + ProjectionEq(>::AssocType = U) :- + Normalize(>::AssocType -> U) +} +``` - // Rule ProjectionEq-Skolemize - // - // ProjectionEq can succeed by skolemizing, see "associated type" - // chapter for more: - forall { - ProjectionEq( - >::AssocType = - (Trait::AssocType) - ) :- - // But only if the trait is implemented, and the conditions from - // the associated type are met as well: - Implemented(Self: Trait) - && WC1 - } +```text +// Rule ProjectionEq-Skolemize +// +// ProjectionEq can succeed by skolemizing, see "associated type" +// chapter for more: +forall { + ProjectionEq( + >::AssocType = + (Trait::AssocType) + ) +} ``` The next rule covers implied bounds for the projection. In particular, -the `Bounds` declared on the associated type must be proven to hold to -show that the impl is well-formed, and hence we can rely on them +the `Bounds` declared on the associated type must have been proven to hold +to show that the impl is well-formed, and hence we can rely on them elsewhere. ```text -// XXX how exactly should we set this up? Have to be careful; -// presumably this has to be a kind of `FromEnv` setup. +// Rule Implied-Bound-From-AssocTy +// +// For each `Bound` in `Bounds`: +forall { + FromEnv(>::AssocType>: Bound) :- + FromEnv(Self: Trait) +} +``` + +Next, we define the requirements for an instantiation of our associated +type to be well-formed... + +```text +// Rule WellFormed-AssocTy +forall { + WellFormed((Trait::AssocType)) :- + WC1, Implemented(Self: Trait) +} +``` + +...along with the reverse implications, when we can assume that it is +well-formed. + +```text +// Rule Implied-WC-From-AssocTy +// +// For each where clause WC1: +forall { + FromEnv(WC1) :- FromEnv((Trait::AssocType)) +} +``` + +```text +// Rule Implied-Trait-From-AssocTy +forall { + FromEnv(Self: Trait) :- + FromEnv((Trait::AssocType)) +} ``` ### Lowering function and constant declarations @@ -269,27 +301,29 @@ In addition, we will lower all of the *impl items*. Given an impl that contains: ```rust,ignore -impl Trait for A0 -where WC +impl Trait for P0 +where WC_impl { - type AssocType where WC1 = T; + type AssocType = T; } ``` -We produce the following rule: +and our where clause `WC1` on the trait associated type from above, we +produce the following rule: ```text // Rule Normalize-From-Impl forall { forall { - Normalize(>::AssocType -> T) :- - WC && WC1 + Normalize(>::AssocType -> T) :- + Implemented(P0 as Trait) && WC1 } } ``` -Note that `WC` and `WC1` both encode where-clauses that the impl can -rely on. +Note that `WC_impl` and `WC1` both encode where-clauses that the impl can +rely on. (`WC_impl` is not used here, because it is implied by +`Implemented(P0 as Trait)`.) @@ -300,5 +334,3 @@ like to treat them exactly like normalization. This presumably involves adding a new kind of parameter (constant), and then having a `NormalizeValue` domain goal. This is *to be written* because the details are a bit up in the air. - - From dab4531fdc8707e563aa03bb2e0ceb70bf40d380 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 2 Jun 2018 16:06:00 -0500 Subject: [PATCH 0239/1812] clarify run-rustfix compiletest header --- src/tests/adding.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 3788e7c41..28f4c1140 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -149,9 +149,12 @@ exhaustive. Header commands can generally be found by browsing the source. * `run-rustfix` for UI tests, indicates that the test produces - structured suggestions, which are then applied and the final - source is stored in a `.fixed` file and compiled again. The final - compilation is required to succeed. + structured suggestions. The test writer should create a `.fixed` + file, which contains the source with the suggestions applied. + When the test is run, compiletest first checks that the correct + lint/warning is generated. Then, it applies the suggestion and + compares against `.fixed` (they must match). Finally, the fixed + source is compiled, and this compilation is required to succeed. * `min-{gdb,lldb}-version` * `min-llvm-version` * `compile-pass` for UI tests, indicates that the test is From 1af6fcfc67aa51a952f0dda23211396bb63859e4 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 11:46:47 -0500 Subject: [PATCH 0240/1812] move appendix --- src/{appendix-background.md => appendix/background.md} | 0 src/{appendix-code-index.md => appendix/code-index.md} | 0 src/{appendix-glossary.md => appendix/glossary.md} | 0 src/{appendix-stupid-stats.md => appendix/stupid-stats.md} | 0 4 files changed, 0 insertions(+), 0 deletions(-) rename src/{appendix-background.md => appendix/background.md} (100%) rename src/{appendix-code-index.md => appendix/code-index.md} (100%) rename src/{appendix-glossary.md => appendix/glossary.md} (100%) rename src/{appendix-stupid-stats.md => appendix/stupid-stats.md} (100%) diff --git a/src/appendix-background.md b/src/appendix/background.md similarity index 100% rename from src/appendix-background.md rename to src/appendix/background.md diff --git a/src/appendix-code-index.md b/src/appendix/code-index.md similarity index 100% rename from src/appendix-code-index.md rename to src/appendix/code-index.md diff --git a/src/appendix-glossary.md b/src/appendix/glossary.md similarity index 100% rename from src/appendix-glossary.md rename to src/appendix/glossary.md diff --git a/src/appendix-stupid-stats.md b/src/appendix/stupid-stats.md similarity index 100% rename from src/appendix-stupid-stats.md rename to src/appendix/stupid-stats.md From 1b0fe8995aae7c17da01eebf27869b6f632df0ed Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 11:49:24 -0500 Subject: [PATCH 0241/1812] move mir --- src/{mir-borrowck.md => mir/borrowck.md} | 0 src/{mir-construction.md => mir/construction.md} | 0 src/{mir.md => mir/index.md} | 0 src/{mir-optimizations.md => mir/optimizations.md} | 0 src/{mir-passes.md => mir/passes.md} | 0 src/{mir-regionck.md => mir/regionck.md} | 0 src/{mir-visitor.md => mir/visitor.md} | 0 7 files changed, 0 insertions(+), 0 deletions(-) rename src/{mir-borrowck.md => mir/borrowck.md} (100%) rename src/{mir-construction.md => mir/construction.md} (100%) rename src/{mir.md => mir/index.md} (100%) rename src/{mir-optimizations.md => mir/optimizations.md} (100%) rename src/{mir-passes.md => mir/passes.md} (100%) rename src/{mir-regionck.md => mir/regionck.md} (100%) rename src/{mir-visitor.md => mir/visitor.md} (100%) diff --git a/src/mir-borrowck.md b/src/mir/borrowck.md similarity index 100% rename from src/mir-borrowck.md rename to src/mir/borrowck.md diff --git a/src/mir-construction.md b/src/mir/construction.md similarity index 100% rename from src/mir-construction.md rename to src/mir/construction.md diff --git a/src/mir.md b/src/mir/index.md similarity index 100% rename from src/mir.md rename to src/mir/index.md diff --git a/src/mir-optimizations.md b/src/mir/optimizations.md similarity index 100% rename from src/mir-optimizations.md rename to src/mir/optimizations.md diff --git a/src/mir-passes.md b/src/mir/passes.md similarity index 100% rename from src/mir-passes.md rename to src/mir/passes.md diff --git a/src/mir-regionck.md b/src/mir/regionck.md similarity index 100% rename from src/mir-regionck.md rename to src/mir/regionck.md diff --git a/src/mir-visitor.md b/src/mir/visitor.md similarity index 100% rename from src/mir-visitor.md rename to src/mir/visitor.md From 13f38bebad77c79d1fcd03bed3e9802b821c7578 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 11:54:23 -0500 Subject: [PATCH 0242/1812] mv traits --- src/{traits-associated-types.md => traits/associated-types.md} | 0 src/{traits-bibliography.md => traits/bibliography.md} | 0 src/{trait-caching.md => traits/caching.md} | 0 src/{traits-canonical-queries.md => traits/canonical-queries.md} | 0 src/{traits-canonicalization.md => traits/canonicalization.md} | 0 src/{traits-goals-and-clauses.md => traits/goals-and-clauses.md} | 0 src/{trait-hrtb.md => traits/hrtb.md} | 0 src/{traits-implied-bounds.md => traits/implied-bounds.md} | 0 src/{traits.md => traits/index.md} | 0 src/{traits-lowering-module.md => traits/lowering-module.md} | 0 src/{traits-lowering-rules.md => traits/lowering-rules.md} | 0 src/{traits-lowering-to-logic.md => traits/lowering-to-logic.md} | 0 src/{traits-regions.md => traits/regions.md} | 0 src/{trait-resolution.md => traits/resolution.md} | 0 src/{traits-slg.md => traits/slg.md} | 0 src/{traits-wf.md => traits/wf.md} | 0 16 files changed, 0 insertions(+), 0 deletions(-) rename src/{traits-associated-types.md => traits/associated-types.md} (100%) rename src/{traits-bibliography.md => traits/bibliography.md} (100%) rename src/{trait-caching.md => traits/caching.md} (100%) rename src/{traits-canonical-queries.md => traits/canonical-queries.md} (100%) rename src/{traits-canonicalization.md => traits/canonicalization.md} (100%) rename src/{traits-goals-and-clauses.md => traits/goals-and-clauses.md} (100%) rename src/{trait-hrtb.md => traits/hrtb.md} (100%) rename src/{traits-implied-bounds.md => traits/implied-bounds.md} (100%) rename src/{traits.md => traits/index.md} (100%) rename src/{traits-lowering-module.md => traits/lowering-module.md} (100%) rename src/{traits-lowering-rules.md => traits/lowering-rules.md} (100%) rename src/{traits-lowering-to-logic.md => traits/lowering-to-logic.md} (100%) rename src/{traits-regions.md => traits/regions.md} (100%) rename src/{trait-resolution.md => traits/resolution.md} (100%) rename src/{traits-slg.md => traits/slg.md} (100%) rename src/{traits-wf.md => traits/wf.md} (100%) diff --git a/src/traits-associated-types.md b/src/traits/associated-types.md similarity index 100% rename from src/traits-associated-types.md rename to src/traits/associated-types.md diff --git a/src/traits-bibliography.md b/src/traits/bibliography.md similarity index 100% rename from src/traits-bibliography.md rename to src/traits/bibliography.md diff --git a/src/trait-caching.md b/src/traits/caching.md similarity index 100% rename from src/trait-caching.md rename to src/traits/caching.md diff --git a/src/traits-canonical-queries.md b/src/traits/canonical-queries.md similarity index 100% rename from src/traits-canonical-queries.md rename to src/traits/canonical-queries.md diff --git a/src/traits-canonicalization.md b/src/traits/canonicalization.md similarity index 100% rename from src/traits-canonicalization.md rename to src/traits/canonicalization.md diff --git a/src/traits-goals-and-clauses.md b/src/traits/goals-and-clauses.md similarity index 100% rename from src/traits-goals-and-clauses.md rename to src/traits/goals-and-clauses.md diff --git a/src/trait-hrtb.md b/src/traits/hrtb.md similarity index 100% rename from src/trait-hrtb.md rename to src/traits/hrtb.md diff --git a/src/traits-implied-bounds.md b/src/traits/implied-bounds.md similarity index 100% rename from src/traits-implied-bounds.md rename to src/traits/implied-bounds.md diff --git a/src/traits.md b/src/traits/index.md similarity index 100% rename from src/traits.md rename to src/traits/index.md diff --git a/src/traits-lowering-module.md b/src/traits/lowering-module.md similarity index 100% rename from src/traits-lowering-module.md rename to src/traits/lowering-module.md diff --git a/src/traits-lowering-rules.md b/src/traits/lowering-rules.md similarity index 100% rename from src/traits-lowering-rules.md rename to src/traits/lowering-rules.md diff --git a/src/traits-lowering-to-logic.md b/src/traits/lowering-to-logic.md similarity index 100% rename from src/traits-lowering-to-logic.md rename to src/traits/lowering-to-logic.md diff --git a/src/traits-regions.md b/src/traits/regions.md similarity index 100% rename from src/traits-regions.md rename to src/traits/regions.md diff --git a/src/trait-resolution.md b/src/traits/resolution.md similarity index 100% rename from src/trait-resolution.md rename to src/traits/resolution.md diff --git a/src/traits-slg.md b/src/traits/slg.md similarity index 100% rename from src/traits-slg.md rename to src/traits/slg.md diff --git a/src/traits-wf.md b/src/traits/wf.md similarity index 100% rename from src/traits-wf.md rename to src/traits/wf.md From 55883c4a7e96a0161aaba98991de2866367389b5 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 12:13:46 -0500 Subject: [PATCH 0243/1812] first round of link fixes --- src/SUMMARY.md | 52 ++++++++++++++++----------------- src/rustc-driver.md | 22 +++++++------- src/traits/caching.md | 4 +-- src/traits/canonical-queries.md | 6 ++-- src/traits/canonicalization.md | 6 ++-- src/traits/goals-and-clauses.md | 13 +++++---- src/traits/index.md | 12 ++++---- src/traits/lowering-module.md | 2 +- src/traits/lowering-rules.md | 10 +++---- src/traits/lowering-to-logic.md | 4 +-- src/traits/resolution.md | 2 +- src/type-inference.md | 2 +- 12 files changed, 68 insertions(+), 67 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 2db3e62c3..a2b7d3e13 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -22,34 +22,34 @@ - [The HIR (High-level IR)](./hir.md) - [The `ty` module: representing types](./ty.md) - [Type inference](./type-inference.md) -- [Trait solving (old-style)](./trait-resolution.md) - - [Higher-ranked trait bounds](./trait-hrtb.md) - - [Caching subtleties](./trait-caching.md) - - [Specialization](./trait-specialization.md) +- [Trait solving (old-style)](./traits/resolution.md) + - [Higher-ranked trait bounds](./traits/hrtb.md) + - [Caching subtleties](./traits/caching.md) + - [Specialization](./traits/specialization.md) - [Trait solving (new-style)](./traits.md) - - [Lowering to logic](./traits-lowering-to-logic.md) - - [Goals and clauses](./traits-goals-and-clauses.md) - - [Equality and associated types](./traits-associated-types.md) - - [Implied bounds](./traits-implied-bounds.md) - - [Region constraints](./traits-regions.md) - - [Canonical queries](./traits-canonical-queries.md) - - [Canonicalization](./traits-canonicalization.md) - - [Lowering rules](./traits-lowering-rules.md) - - [The lowering module in rustc](./traits-lowering-module.md) - - [Well-formedness checking](./traits-wf.md) - - [The SLG solver](./traits-slg.md) + - [Lowering to logic](./traits/lowering-to-logic.md) + - [Goals and clauses](./traits/goals-and-clauses.md) + - [Equality and associated types](./traits/associated-types.md) + - [Implied bounds](./traits/implied-bounds.md) + - [Region constraints](./traits/regions.md) + - [Canonical queries](./traits/canonical-queries.md) + - [Canonicalization](./traits/canonicalization.md) + - [Lowering rules](./traits/lowering-rules.md) + - [The lowering module in rustc](./traits/lowering-module.md) + - [Well-formedness checking](./traits/wf.md) + - [The SLG solver](./traits/slg.md) - [An Overview of Chalk](./chalk-overview.md) - - [Bibliography](./traits-bibliography.md) + - [Bibliography](./traits/bibliography.md) - [Type checking](./type-checking.md) - [Method Lookup](./method-lookup.md) - [Variance](./variance.md) - [The MIR (Mid-level IR)](./mir.md) - - [MIR construction](./mir-construction.md) - - [MIR visitor and traversal](./mir-visitor.md) - - [MIR passes: getting the MIR for a function](./mir-passes.md) - - [MIR borrowck](./mir-borrowck.md) - - [MIR-based region checking (NLL)](./mir-regionck.md) - - [MIR optimizations](./mir-optimizations.md) + - [MIR construction](./mir/construction.md) + - [MIR visitor and traversal](./mir/visitor.md) + - [MIR passes: getting the MIR for a function](./mir/passes.md) + - [MIR borrowck](./mir/borrowck.md) + - [MIR-based region checking (NLL)](./mir/regionck.md) + - [MIR optimizations](./mir/optimizations.md) - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) @@ -58,7 +58,7 @@ --- -- [Appendix A: Stupid Stats](./appendix-stupid-stats.md) -- [Appendix B: Background material](./appendix-background.md) -- [Appendix C: Glossary](./appendix-glossary.md) -- [Appendix D: Code Index](./appendix-code-index.md) +- [Appendix A: Stupid Stats](./appendix/stupid-stats.md) +- [Appendix B: Background material](./appendix/background.md) +- [Appendix C: Glossary](./appendix/glossary.md) +- [Appendix D: Code Index](./appendix/code-index.md) diff --git a/src/rustc-driver.md b/src/rustc-driver.md index af3c3c099..1550b14e9 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -20,14 +20,14 @@ of each phase. From `rustc_driver`'s perspective, the main phases of the compiler are: 1. *Parse Input:* Initial crate parsing -2. *Configure and Expand:* Resolve `#[cfg]` attributes, name resolution, and +2. *Configure and Expand:* Resolve `#[cfg]` attributes, name resolution, and expand macros 3. *Run Analysis Passes:* Run trait resolution, typechecking, region checking and other miscellaneous analysis passes on the crate -4. *Translate to LLVM:* Translate to the in-memory form of LLVM IR and turn it +4. *Translate to LLVM:* Translate to the in-memory form of LLVM IR and turn it into an executable/object files -The `CompileController` then gives users the ability to inspect the ongoing +The `CompileController` then gives users the ability to inspect the ongoing compilation process - after parsing @@ -39,7 +39,7 @@ compilation process The `CompileState`'s various `state_after_*()` constructors can be inspected to determine what bits of information are available to which callback. -For a more detailed explanation on using `rustc_driver`, check out the +For a more detailed explanation on using `rustc_driver`, check out the [stupid-stats] guide by `@nrc` (attached as [Appendix A]). > **Warning:** By its very nature, the internal compiler APIs are always going @@ -47,23 +47,23 @@ For a more detailed explanation on using `rustc_driver`, check out the ## A Note On Lifetimes -The Rust compiler is a fairly large program containing lots of big data +The Rust compiler is a fairly large program containing lots of big data structures (e.g. the AST, HIR, and the type system) and as such, arenas and -references are heavily relied upon to minimize unnecessary memory use. This +references are heavily relied upon to minimize unnecessary memory use. This manifests itself in the way people can plug into the compiler, preferring a "push"-style API (callbacks) instead of the more Rust-ic "pull" style (think the `Iterator` trait). -For example the [`CompileState`], the state passed to callbacks after each +For example the [`CompileState`], the state passed to callbacks after each phase, is essentially just a box of optional references to pieces inside the compiler. The lifetime bound on the `CompilerCalls` trait then helps to ensure -compiler internals don't "escape" the compiler (e.g. if you tried to keep a +compiler internals don't "escape" the compiler (e.g. if you tried to keep a reference to the AST after the compiler is finished), while still letting users record *some* state for use after the `run_compiler()` function finishes. Thread-local storage and interning are used a lot through the compiler to reduce -duplication while also preventing a lot of the ergonomic issues due to many -pervasive lifetimes. The `rustc::ty::tls` module is used to access these +duplication while also preventing a lot of the ergonomic issues due to many +pervasive lifetimes. The `rustc::ty::tls` module is used to access these thread-locals, although you should rarely need to touch it. @@ -73,4 +73,4 @@ thread-locals, although you should rarely need to touch it. [`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html [`CodeMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html [stupid-stats]: https://github.com/nrc/stupid-stats -[Appendix A]: appendix-stupid-stats.html \ No newline at end of file +[Appendix A]: appendix/stupid-stats.html diff --git a/src/traits/caching.md b/src/traits/caching.md index 4b7d7e096..228ff0917 100644 --- a/src/traits/caching.md +++ b/src/traits/caching.md @@ -24,7 +24,7 @@ On the other hand, if there is no hit, we need to go through the [selection process] from scratch. Suppose, we come to the conclusion that the only possible impl is this one, with def-id 22: -[selection process]: ./trait-resolution.html#selection +[selection process]: ./traits/resolution.html#selection ```rust,ignore impl Foo for usize { ... } // Impl #22 @@ -34,7 +34,7 @@ We would then record in the cache `usize : Foo<$0> => ImplCandidate(22)`. Next we would [confirm] `ImplCandidate(22)`, which would (as a side-effect) unify `$t` with `isize`. -[confirm]: ./trait-resolution.html#confirmation +[confirm]: ./traits/resolution.html#confirmation Now, at some later time, we might come along and see a `usize : Foo<$u>`. When skolemized, this would yield `usize : Foo<$0>`, just as diff --git a/src/traits/canonical-queries.md b/src/traits/canonical-queries.md index 2737737bb..56637dace 100644 --- a/src/traits/canonical-queries.md +++ b/src/traits/canonical-queries.md @@ -7,7 +7,7 @@ would like to know the answer to -- and in the checker or other parts of the system, may in the course of doing their thing want to know whether some trait is implemented for some type (e.g., is `u32: Debug` true?). Or they may want to -[normalize some associated type](./traits-associated-types.html). +[normalize some associated type](./traits/associated-types.html). This section covers queries at a fairly high level of abstraction. The subsections look a bit more closely at how these ideas are implemented @@ -106,7 +106,7 @@ value for a type variable, that means that this is the **only possible instantiation** that you could use, given the current set of impls and where-clauses, that would be provable. (Internally within the solver, though, they can potentially enumerate all possible answers. See -[the description of the SLG solver](./traits-slg.html) for details.) +[the description of the SLG solver](./traits/slg.html) for details.) The response to a trait query in rustc is typically a `Result, NoSolution>` (where the `T` will vary a bit @@ -132,7 +132,7 @@ we did find. It consists of four parts: - **Region constraints:** these are relations that must hold between the lifetimes that you supplied as inputs. We'll ignore these here, but see the - [section on handling regions in traits](./traits-regions.html) for + [section on handling regions in traits](./traits/regions.html) for more details. - **Value:** The query result also comes with a value of type `T`. For some specialized queries -- like normalizing associated types -- diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md index fa39151d7..37a59026b 100644 --- a/src/traits/canonicalization.md +++ b/src/traits/canonicalization.md @@ -16,7 +16,7 @@ starting from zero and numbered in a fixed order (left to right, for the most part, but really it doesn't matter as long as it is consistent). -[cq]: ./traits-canonical-queries.html +[cq]: ./traits/canonical-queries.html So, for example, if we have the type `X = (?T, ?U)`, where `?T` and `?U` are distinct, unbound inference variables, then the canonical @@ -98,12 +98,12 @@ Remember that substitution S though! We're going to need it later. OK, now that we have a fresh inference context and an instantiated query, we can go ahead and try to solve it. The trait solver itself is -explained in more detail in [another section](./traits-slg.html), but +explained in more detail in [another section](./traits/slg.html), but suffice to say that it will compute a [certainty value][cqqr] (`Proven` or `Ambiguous`) and have side-effects on the inference variables we've created. For example, if there were only one impl of `Foo`, like so: -[cqqr]: ./traits-canonical-queries.html#query-response +[cqqr]: ./traits/canonical-queries.html#query-response ```rust,ignore impl<'a, X> Foo<'a, X> for Vec diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index 882f86b8e..5844e8d45 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -2,7 +2,7 @@ In logic programming terms, a **goal** is something that you must prove and a **clause** is something that you know is true. As -described in the [lowering to logic](./traits-lowering-to-logic.html) +described in the [lowering to logic](./traits/lowering-to-logic.html) chapter, Rust's trait solver is based on an extension of hereditary harrop (HH) clauses, which extend traditional Prolog Horn clauses with a few new superpowers. @@ -37,7 +37,7 @@ paper ["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] gives the details. -[pphhf]: ./traits-bibliography.html#pphhf +[pphhf]: ./traits/bibliography.html#pphhf @@ -94,7 +94,7 @@ e.g. `ProjectionEq::Item = u8` The given associated type `Projection` is equal to `Type`; this can be proved with either normalization or using skolemized types. See [the section -on associated types](./traits-associated-types.html). +on associated types](./traits/associated-types.html). #### Normalize(Projection -> Type) e.g. `ProjectionEq::Item -> u8` @@ -102,11 +102,12 @@ e.g. `ProjectionEq::Item -> u8` The given associated type `Projection` can be [normalized][n] to `Type`. As discussed in [the section on associated -types](./traits-associated-types.html), `Normalize` implies `ProjectionEq`, +types](./traits/associated-types.html), `Normalize` implies `ProjectionEq`, but not vice versa. In general, proving `Normalize(::Item -> U)` also requires proving `Implemented(T: Trait)`. -[n]: ./traits-associated-types.html#normalize +[n]: ./traits/associated-types.html#normalize +[at]: ./traits/associated-types.html #### FromEnv(TraitRef), FromEnv(Projection = Type) e.g. `FromEnv(Self: Add)` @@ -211,7 +212,7 @@ In addition to auto traits, `WellFormed` predicates are co-inductive. These are used to achieve a similar "enumerate all the cases" pattern, as described in the section on [implied bounds]. -[implied bounds]: ./traits-lowering-rules.html#implied-bounds +[implied bounds]: ./traits/lowering-rules.html#implied-bounds ## Incomplete chapter diff --git a/src/traits/index.md b/src/traits/index.md index 175e6418b..6aad2474d 100644 --- a/src/traits/index.md +++ b/src/traits/index.md @@ -13,20 +13,20 @@ instructions for getting involved in the Trait solving is based around a few key ideas: -- [Lowering to logic](./traits-lowering-to-logic.html), which expresses +- [Lowering to logic](./traits/lowering-to-logic.html), which expresses Rust traits in terms of standard logical terms. - - The [goals and clauses](./traits-goals-and-clauses.html) chapter + - The [goals and clauses](./traits/goals-and-clauses.html) chapter describes the precise form of rules we use, and - [lowering rules](./traits-lowering-rules.html) gives the complete set of + [lowering rules](./traits/lowering-rules.html) gives the complete set of lowering rules in a more reference-like form. -- [Canonical queries](./traits-canonical-queries.html), which allow us +- [Canonical queries](./traits/canonical-queries.html), which allow us to solve trait problems (like "is `Foo` implemented for the type `Bar`?") once, and then apply that same result independently in many different inference contexts. -- [Lazy normalization](./traits-associated-types.html), which is the +- [Lazy normalization](./traits/associated-types.html), which is the technique we use to accommodate associated types when figuring out whether types are equal. -- [Region constraints](./traits-regions.html), which are accumulated +- [Region constraints](./traits/regions.html), which are accumulated during trait solving but mostly ignored. This means that trait solving effectively ignores the precise regions involved, always -- but we still remember the constraints on them so that those diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md index 08e0b9523..205e9a171 100644 --- a/src/traits/lowering-module.md +++ b/src/traits/lowering-module.md @@ -1,7 +1,7 @@ # The lowering module in rustc The program clauses described in the -[lowering rules](./traits-lowering-rules.html) section are actually +[lowering rules](./traits/lowering-rules.html) section are actually created in the [`rustc_traits::lowering`][lowering] module. [lowering]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_traits/lowering/ diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index 06dc67401..f635ee857 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -4,8 +4,8 @@ This section gives the complete lowering rules for Rust traits into [program clauses][pc]. It is a kind of reference. These rules reference the [domain goals][dg] defined in an earlier section. -[pc]: ./traits-goals-and-clauses.html -[dg]: ./traits-goals-and-clauses.html#domain-goals +[pc]: ./traits/goals-and-clauses.html +[dg]: ./traits/goals-and-clauses.html#domain-goals ## Notation @@ -16,7 +16,7 @@ The nonterminal `Ai` is used to mean some generic *argument*, which might be a lifetime like `'a` or a type like `Vec`. When defining the lowering rules, we will give goals and clauses in -the [notation given in this section](./traits-goals-and-clauses.html). +the [notation given in this section](./traits/goals-and-clauses.html). We sometimes insert "macros" like `LowerWhereClause!` into these definitions; these macros reference other sections within this chapter. @@ -141,7 +141,7 @@ This `WellFormed` rule states that `T: Trait` is well-formed if (a) `T: Trait` is implemented and (b) all the where-clauses declared on `Trait` are well-formed (and hence they are implemented). Remember that the `WellFormed` predicate is -[coinductive](./traits-goals-and-clauses.html#coinductive); in this +[coinductive](./traits/goals-and-clauses.html#coinductive); in this case, it is serving as a kind of "carrier" that allows us to enumerate all the where clauses that are transitively implied by `T: Trait`. @@ -192,7 +192,7 @@ where WC We will produce a number of program clauses. The first two define the rules by which `ProjectionEq` can succeed; these two clauses are discussed -in detail in the [section on associated types](./traits-associated-types.html), +in detail in the [section on associated types](./traits/associated-types.html), but reproduced here for reference: ```text diff --git a/src/traits/lowering-to-logic.md b/src/traits/lowering-to-logic.md index 54b3473d4..2de28ce4e 100644 --- a/src/traits/lowering-to-logic.md +++ b/src/traits/lowering-to-logic.md @@ -170,8 +170,8 @@ example Gopalan Nadathur's excellent ["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] in [the bibliography]. -[the bibliography]: ./traits-bibliography.html -[pphhf]: ./traits-bibliography.html#pphhf +[the bibliography]: ./traits/bibliography.html +[pphhf]: ./traits/bibliography.html#pphhf It turns out that supporting FOHH is not really all that hard. And once we are able to do that, we can easily describe the type-checking diff --git a/src/traits/resolution.md b/src/traits/resolution.md index b9fa81bd6..e33e0c8ec 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -6,7 +6,7 @@ some non-obvious things. **Note:** This chapter (and its subchapters) describe how the trait solver **currently** works. However, we are in the process of designing a new trait solver. If you'd prefer to read about *that*, -see [*this* traits chapter](./traits.html). +see [*this* traits chapter](./traits/index.html). ## Major concepts diff --git a/src/type-inference.md b/src/type-inference.md index 9ae88decd..a3d012b5d 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -125,7 +125,7 @@ actual return type is not `()`, but rather `InferOk<()>`. The to ensure that these are fulfilled (typically by enrolling them in a fulfillment context). See the [trait chapter] for more background on that. -[trait chapter]: trait-resolution.html +[trait chapter]: traits/resolution.html You can similarly enforce subtyping through `infcx.at(..).sub(..)`. The same basic concepts as above apply. From c0851bc66e0771869e76b17d301b6ec1d22c238c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 12:30:10 -0500 Subject: [PATCH 0244/1812] fix remaining links --- src/SUMMARY.md | 6 ++-- src/appendix/glossary.md | 30 +++++++++---------- src/mir/borrowck.md | 12 ++++---- src/mir/index.md | 4 +-- src/mir/passes.md | 2 +- src/mir/regionck.md | 8 ++--- src/traits/canonicalization.md | 2 +- src/{ => traits}/chalk-overview.md | 10 +++---- src/traits/index.md | 2 +- .../specialization.md} | 0 src/type-checking.md | 2 +- src/variance.md | 2 +- 12 files changed, 40 insertions(+), 40 deletions(-) rename src/{ => traits}/chalk-overview.md (95%) rename src/{trait-specialization.md => traits/specialization.md} (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a2b7d3e13..8efe304b7 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -26,7 +26,7 @@ - [Higher-ranked trait bounds](./traits/hrtb.md) - [Caching subtleties](./traits/caching.md) - [Specialization](./traits/specialization.md) -- [Trait solving (new-style)](./traits.md) +- [Trait solving (new-style)](./traits/index.md) - [Lowering to logic](./traits/lowering-to-logic.md) - [Goals and clauses](./traits/goals-and-clauses.md) - [Equality and associated types](./traits/associated-types.md) @@ -38,12 +38,12 @@ - [The lowering module in rustc](./traits/lowering-module.md) - [Well-formedness checking](./traits/wf.md) - [The SLG solver](./traits/slg.md) - - [An Overview of Chalk](./chalk-overview.md) + - [An Overview of Chalk](./traits/chalk-overview.md) - [Bibliography](./traits/bibliography.md) - [Type checking](./type-checking.md) - [Method Lookup](./method-lookup.md) - [Variance](./variance.md) -- [The MIR (Mid-level IR)](./mir.md) +- [The MIR (Mid-level IR)](./mir/index.md) - [MIR construction](./mir/construction.md) - [MIR visitor and traversal](./mir/visitor.md) - [MIR passes: getting the MIR for a function](./mir/passes.md) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index a37f1b22f..ad2604e63 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -7,18 +7,18 @@ them better. Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. -binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./appendix-background.html#free-vs-bound) -bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./appendix-background.html#free-vs-bound) +binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./appendix/background.html#free-vs-bound) +bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./appendix/background.html#free-vs-bound) codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). -control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./appendix-background.html#cfg) +control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./appendix/background.html#cfg) cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) -data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./appendix-background.html#dataflow) +data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./appendix/background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. Double pointer | a pointer with additional metadata. See "fat pointer" for more. Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". -free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix-background.html#free-vs-bound) +free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix/background.html#free-vs-bound) 'gcx | the lifetime of the global arena ([see more](ty.html)) generics | the set of generic type parameters defined on a type or item HIR | the High-level IR, created by lowering and desugaring the AST ([see more](hir.html)) @@ -32,36 +32,36 @@ IR | Intermediate Representation. A general term in compil local crate | the crate currently being compiled. LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optmizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. -MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir.html)) +MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir/index.html)) miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) -normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](./traits-associated-types.html#normalize) +normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](./traits/associated-types.html#normalize) newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -NLL | [non-lexical lifetimes](./mir-regionck.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. +NLL | [non-lexical lifetimes](./mir/regionck.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. -obligation | something that must be proven by the trait system ([see more](trait-resolution.html)) -projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](./traits-goals-and-clauses.html#trait-ref) -promoted constants | constants extracted from a function and lifted to static scope; see [this section](./mir.html#promoted) for more details. +obligation | something that must be proven by the trait system ([see more](traits/resolution.html)) +projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](./traits/goals-and-clauses.html#trait-ref) +promoted constants | constants extracted from a function and lifted to static scope; see [this section](./mir/index.html#promoted) for more details. provider | the function that executes a query ([see more](query.html)) -quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./appendix-background.html#quantified) +quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./appendix/background.html#quantified) query | perhaps some sub-computation during compilation ([see more](query.html)) region | another term for "lifetime" often used in the literature and in the borrow checker. sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir-regionck.html#skol) for more details. +skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir/regionck.html#skol) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) tcx | the "typing context", main data structure of the compiler ([see more](ty.html)) 'tcx | the lifetime of the currently active inference context ([see more](ty.html)) -trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](./traits-goals-and-clauses.html#trait-ref)) +trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](./traits/goals-and-clauses.html#trait-ref)) token | the smallest unit of parsing. Tokens are produced after lexing ([see more](the-parser.html)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. trans | the code to translate MIR into LLVM IR. trait reference | a trait and values for its type parameters ([see more](ty.html)). ty | the internal representation of a type ([see more](ty.html)). UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](type-checking.html)). -variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./appendix-background.html#variance) for a more general explanation. See the [variance chapter](./variance.html) for an explanation of how type checking handles variance. +variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./appendix/background.html#variance) for a more general explanation. See the [variance chapter](./variance.html) for an explanation of how type checking handles variance. Wide pointer | a pointer with additional metadata. See "fat pointer" for more. [LLVM]: https://llvm.org/ diff --git a/src/mir/borrowck.md b/src/mir/borrowck.md index 51a6c6cbf..cd83843f8 100644 --- a/src/mir/borrowck.md +++ b/src/mir/borrowck.md @@ -21,7 +21,7 @@ Doing borrow checking on MIR has two key advantages: can see [a list of bugs that the MIR-based borrow checker fixes here][47366].) - Even more importantly, using the MIR enables ["non-lexical lifetimes"][nll], - which are regions derived from the control-flow graph. + which are regions derived from the control-flow graph. [47366]: https://github.com/rust-lang/rust/issues/47366 [nll]: http://rust-lang.github.io/rfcs/2094-nll.html @@ -43,17 +43,17 @@ The overall flow of the borrow checker is as follows: include references to the new regions that we are computing. - We then invoke `nll::replace_regions_in_mir` to modify this copy C. Among other things, this function will replace all of the regions in - the MIR with fresh [inference variables](./appendix-glossary.html). - - (More details can be found in [the regionck section](./mir-regionck.html).) + the MIR with fresh [inference variables](./appendix/glossary.html). + - (More details can be found in [the regionck section](./mir/regionck.html).) - Next, we perform a number of [dataflow - analyses](./appendix-background.html#dataflow) + analyses](./appendix/background.html#dataflow) that compute what data is moved and when. The results of these analyses are needed to do both borrow checking and region inference. - Using the move data, we can then compute the values of all the regions in the MIR. - - (More details can be found in [the NLL section](./mir-regionck.html).) + - (More details can be found in [the NLL section](./mir/regionck.html).) - Finally, the borrow checker itself runs, taking as input (a) the results of move analysis and (b) the regions computed by the region checker. This allows us to figure out which loans are still in scope at any particular point. - + diff --git a/src/mir/index.md b/src/mir/index.md index 81bbf6bd6..838048b81 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -26,7 +26,7 @@ Some of the key characteristics of MIR are: - It does not have nested expressions. - All types in MIR are fully explicit. -[cfg]: ./appendix-background.html#cfg +[cfg]: ./appendix/background.html#cfg ## Key MIR vocabulary @@ -244,4 +244,4 @@ but [you can read about those below](#promoted)). [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir [mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir -[newtype'd]: appendix-glossary.html +[newtype'd]: appendix/glossary.html diff --git a/src/mir/passes.md b/src/mir/passes.md index 64e72f06e..a5b5df10a 100644 --- a/src/mir/passes.md +++ b/src/mir/passes.md @@ -174,4 +174,4 @@ alternatives in [rust-lang/rust#41710]. [rust-lang/rust#41710]: https://github.com/rust-lang/rust/issues/41710 [mirtransform]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/ [`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/no_landing_pads/struct.NoLandingPads.html -[MIR visitor]: mir-visitor.html +[MIR visitor]: mir/visitor.html diff --git a/src/mir/regionck.md b/src/mir/regionck.md index e67e91138..90f6fa274 100644 --- a/src/mir/regionck.md +++ b/src/mir/regionck.md @@ -35,7 +35,7 @@ The MIR-based region analysis consists of two major functions: - More details to come, though the [NLL RFC] also includes fairly thorough (and hopefully readable) coverage. -[fvb]: appendix-background.html#free-vs-bound +[fvb]: appendix/background.html#free-vs-bound [NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html ## Universal regions @@ -131,7 +131,7 @@ the type of `foo` the type `bar` expects We handle this sort of subtyping by taking the variables that are bound in the supertype and **skolemizing** them: this means that we replace them with -[universally quantified](appendix-background.html#quantified) +[universally quantified](appendix/background.html#quantified) representatives, written like `!1`. We call these regions "skolemized regions" -- they represent, basically, "some unknown region". @@ -148,7 +148,7 @@ what we wanted. So let's work through what happens next. To check if two functions are subtypes, we check if their arguments have the desired relationship -(fn arguments are [contravariant](./appendix-background.html#variance), so +(fn arguments are [contravariant](./appendix/background.html#variance), so we swap the left and right here): ```text @@ -187,7 +187,7 @@ Here, the root universe would consist of the lifetimes `'static` and the same concept to types, in which case the types `Foo` and `T` would be in the root universe (along with other global types, like `i32`). Basically, the root universe contains all the names that -[appear free](./appendix-background.html#free-vs-bound) in the body of `bar`. +[appear free](./appendix/background.html#free-vs-bound) in the body of `bar`. Now let's extend `bar` a bit by adding a variable `x`: diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md index 37a59026b..f87de5f81 100644 --- a/src/traits/canonicalization.md +++ b/src/traits/canonicalization.md @@ -41,7 +41,7 @@ trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound. This query contains two unbound variables, but it also contains the lifetime `'static`. The trait system generally ignores all lifetimes and treats them equally, so when canonicalizing, we will *also* -replace any [free lifetime](./appendix-background.html#free-vs-bound) with a +replace any [free lifetime](./appendix/background.html#free-vs-bound) with a canonical variable. Therefore, we get the following result: ```text diff --git a/src/chalk-overview.md b/src/traits/chalk-overview.md similarity index 95% rename from src/chalk-overview.md rename to src/traits/chalk-overview.md index 76c119a5e..e737edcd9 100644 --- a/src/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -131,18 +131,18 @@ See [The SLG Solver][slg]. [rustc-issues]: https://github.com/rust-lang-nursery/rustc-guide/issues [chalk]: https://github.com/rust-lang-nursery/chalk -[lowering-to-logic]: traits-lowering-to-logic.html -[lowering-rules]: traits-lowering-rules.html +[lowering-to-logic]: traits/lowering-to-logic.html +[lowering-rules]: traits/lowering-rules.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification -[lowering-forall]: https://rust-lang-nursery.github.io/rustc-guide/traits-lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses +[lowering-forall]: ./traits/lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses [programclause]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L721 [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause -[goals-and-clauses]: traits-goals-and-clauses.html +[goals-and-clauses]: ./traits/goals-and-clauses.html [well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir/lowering.rs#L230-L232 [ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/ir.rs [HIR]: hir.html [binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 [rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 -[slg]: traits-slg.html +[slg]: ./traits/slg.html diff --git a/src/traits/index.md b/src/traits/index.md index 6aad2474d..2dabd0b69 100644 --- a/src/traits/index.md +++ b/src/traits/index.md @@ -4,7 +4,7 @@ [process of being implemented][wg]; this chapter serves as a kind of in-progress design document. If you would prefer to read about how the current trait solver works, check out -[this other chapter](./trait-resolution.html). (By the way, if you +[this other chapter](./traits/resolution.html). (By the way, if you would like to help in hacking on the new solver, you will find instructions for getting involved in the [Traits Working Group tracking issue][wg].) 🚧 diff --git a/src/trait-specialization.md b/src/traits/specialization.md similarity index 100% rename from src/trait-specialization.md rename to src/traits/specialization.md diff --git a/src/type-checking.md b/src/type-checking.md index cb6d346e4..9a161abd2 100644 --- a/src/type-checking.md +++ b/src/type-checking.md @@ -6,7 +6,7 @@ draws heavily on the [type inference] and [trait solving].) [typeck]: https://github.com/rust-lang/rust/tree/master/src/librustc_typeck [type inference]: type-inference.html -[trait solving]: trait-resolution.html +[trait solving]: traits/resolution.html ## Type collection diff --git a/src/variance.md b/src/variance.md index 08399b5b3..05a286c07 100644 --- a/src/variance.md +++ b/src/variance.md @@ -2,7 +2,7 @@ For a more general background on variance, see the [background] appendix. -[background]: ./appendix-background.html +[background]: ./appendix/background.html During type checking we must infer the variance of type and lifetime parameters. The algorithm is taken from Section 4 of the paper ["Taming the From 37c68dbbdd9a1c38ecbba88d5cf5c30e4aba2fb1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 May 2018 12:38:46 -0500 Subject: [PATCH 0245/1812] allow long relative links --- ci/check_line_lengths.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/check_line_lengths.sh b/ci/check_line_lengths.sh index dc48091c8..91f199b7e 100755 --- a/ci/check_line_lengths.sh +++ b/ci/check_line_lengths.sh @@ -30,7 +30,7 @@ for file in "$@" ; do (( inside_block = !$inside_block )) continue fi - if ! (( $inside_block )) && ! [[ "$line" =~ " | "|"-|-"|"://"|\[\^[^\ ]+\]: ]] && (( "${#line}" > $MAX_LINE_LENGTH )) ; then + if ! (( $inside_block )) && ! [[ "$line" =~ " | "|"-|-"|"://"|"]:"|\[\^[^\ ]+\]: ]] && (( "${#line}" > $MAX_LINE_LENGTH )) ; then (( bad_lines++ )) echo -e "\t$line_no : $line" fi From 4a8412f3af6cdaa5a64781e2a1fdec54ad5fa181 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 19:42:16 -0500 Subject: [PATCH 0246/1812] add a bunch of type-related terms to glossary --- src/appendix/glossary.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index ad2604e63..a6f4e7b1c 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -12,11 +12,14 @@ bound variable | a "bound variable" is one that is declared within an codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./appendix/background.html#cfg) +CTFE | Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](./const-eval.html)) cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./appendix/background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. Double pointer | a pointer with additional metadata. See "fat pointer" for more. +DST | Dynamically-Sized Type. A type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). +empty type | see "uninhabited type". Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix/background.html#free-vs-bound) 'gcx | the lifetime of the global arena ([see more](ty.html)) @@ -45,6 +48,7 @@ provider | the function that executes a query ([see more](query. quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./appendix/background.html#quantified) query | perhaps some sub-computation during compilation ([see more](query.html)) region | another term for "lifetime" often used in the literature and in the borrow checker. +rib | a data structure in the name resolver that keeps track of a single scope for names. ([see more](./name-resolution.html)) sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. @@ -61,8 +65,11 @@ trans | the code to translate MIR into LLVM IR. trait reference | a trait and values for its type parameters ([see more](ty.html)). ty | the internal representation of a type ([see more](ty.html)). UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](type-checking.html)). +uninhabited type | a type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". +upvar | a variable captured by a closure from outside the closure. variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./appendix/background.html#variance) for a more general explanation. See the [variance chapter](./variance.html) for an explanation of how type checking handles variance. Wide pointer | a pointer with additional metadata. See "fat pointer" for more. +ZST | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. [LLVM]: https://llvm.org/ [lto]: https://llvm.org/docs/LinkTimeOptimization.html From 809ca6900136db5645fcdfbbf8dd95377230daab Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 20:26:40 -0500 Subject: [PATCH 0247/1812] A few more data structures to the code index --- src/appendix/code-index.md | 18 ++++++++++++++++-- src/hir.md | 2 ++ src/the-parser.md | 10 +++++----- 3 files changed, 23 insertions(+), 7 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 915d00828..62fa6bd93 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -6,24 +6,38 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- +`BodyId` | struct | One of four types of HIR node identifiers. | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html) `CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser] | [src/libsyntax/codemap.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html) `CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html) +`DefId` | struct | One of four types of HIR node identifiers. | [Identifiers in the HIR] | [src/librustc/hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html) `DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) `ast::Crate` | struct | Syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) +`HirId` | struct | One of four types of HIR node identifiers. | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html) `hir::Crate` | struct | More abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) -`ParseSess` | struct | This struct contains information about a parsing session | [the Parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) -`Session` | struct | The data associated with a compilation session | [the Parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) +`NodeId` | struct | One of four types of HIR node identifiers. Being phased out. | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) +`ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) +`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) +`Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Rib.html) +`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html) +`syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) +`TraitRef` | struct | Information about a trait reference (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) [The HIR]: hir.html +[Identifiers in the HIR]: hir.html#hir-id [The parser]: the-parser.html [The Rustc Driver]: rustc-driver.html [Type checking]: type-checking.html [The `ty` modules]: ty.html [Rustdoc]: rustdoc.html [Emitting Diagnostics]: diag.html +[Macro expansion]: macro-expansion.html +[Name resolution]: name-resolution.html +[Parameter Environment]: param_env.html +[Trait Solving: Goals and Clauses]: traits/goals-and-clauses.html#domain-goals +[Trait Solving: Lowering impls]: traits/lowering-rules.html#lowering-impls diff --git a/src/hir.md b/src/hir.md index 44c4968b1..2a11531ee 100644 --- a/src/hir.md +++ b/src/hir.md @@ -57,6 +57,8 @@ function to lookup the contents of `bar()` given its id; this gives the compiler a chance to observe that you accessed the data for `bar()`, and then record the dependency. + + ### Identifiers in the HIR Most of the code that has to deal with things in HIR tends not to diff --git a/src/the-parser.md b/src/the-parser.md index 623a38e67..dd451d24f 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -2,7 +2,7 @@ The parser is responsible for converting raw Rust source code into a structured form which is easier for the compiler to work with, usually called an [*Abstract -Syntax Tree*][ast]. An AST mirrors the structure of a Rust program in memory, +Syntax Tree*][ast]. An AST mirrors the structure of a Rust program in memory, using a `Span` to link a particular AST node back to its source text. The bulk of the parser lives in the [libsyntax] crate. @@ -27,16 +27,16 @@ in the [parser module]. They let you do things like turn a filemap into a token stream, create a parser from the token stream, and then execute the parser to get a `Crate` (the root AST node). -To minimise the amount of copying that is done, both the `StringReader` and +To minimise the amount of copying that is done, both the `StringReader` and `Parser` have lifetimes which bind them to the parent `ParseSess`. This contains all the information needed while parsing, as well as the `CodeMap` itself. -[libsyntax]: https://github.com/rust-lang/rust/tree/master/src/libsyntax -[rustc_errors]: https://github.com/rust-lang/rust/tree/master/src/librustc_errors +[libsyntax]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/index.html +[rustc_errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [`CodeMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html [ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/index.html -[parser module]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/parse +[parser module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/index.html [`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/parser/struct.Parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html [visit module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/visit/index.html From d0ad0c7bc11ed6969e59c5f7ab00c5309d04ef66 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 3 Jun 2018 22:09:21 -0500 Subject: [PATCH 0248/1812] add a bit about crater --- src/tests/intro.md | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index e8cf34aff..7c3832ed9 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -170,7 +170,38 @@ communicate with the server to coordinate running tests (see ## Crater -TODO +[Crater](https://github.com/rust-lang-nursery/crater) is a tool for compiling +and running tests for _every_ crate on [crates.io](https://crates.io/). It is +mainly used for checking for extent of breakage when implementing potentially +breaking changes. + +### When to run Crater + +You should request a crater run if your PR makes large changes to the compiler +or could cause breakage. If you are unsure, feel free to ask your PR's reviewer. + +### Requesting Crater Runs + +The rust team maintains a few machines that can be used for running crater runs +on the changes introduced by a PR. If your PR needs a crater run, leave a +comment for the triage team in the PR thread. Your will be enqueued by the +triage team and the results will be posted when they are ready. A crater run +usually takes a few days (as of this writing). + +While crater is really useful, it is also important to be aware of a few caveats: + +- Not all code is on crates.io! There is a lot of code in repos on GitHub and + elsewhere. Also, companies may not wish to publish their code. Thus, a + successful crater run is not a magically green light that there will be no + breakage; you still need to be careful. + +- Crater only runs Linux builds (on x86_64, I believe). Thus, other + architectures and platforms are not tested. Critically, this includes + Windows. + +- Many crates are not tested. This could be for a lot of reasons, including + that the crate doesn't compile any more (e.g. used old nightly features), + has broken or flaky tests, requires network access, or other reasons. ## Further reading From 8ee1d91c3824eb17eccd2b8d6ece9b3620d8f971 Mon Sep 17 00:00:00 2001 From: Mark Date: Sun, 3 Jun 2018 22:40:29 -0500 Subject: [PATCH 0249/1812] add more on crater + perf runs --- src/tests/intro.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/tests/intro.md b/src/tests/intro.md index 7c3832ed9..034b7aac1 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -203,6 +203,23 @@ While crater is really useful, it is also important to be aware of a few caveats that the crate doesn't compile any more (e.g. used old nightly features), has broken or flaky tests, requires network access, or other reasons. +- Before crater can be run, `@bors try` needs to suceed. This means that if + your code doesn't compile or fails tests, you cannot run crater. + +## Perf runs + +A lot of work is put into improving the performance of the compiler and +preventing performance regressions. A "perf run" is used to compare the +performance of the compiler in different configurations for a large collection +of popular crates. Different configurations include "fresh builds", builds +with incremental compilation, etc. + +The result of a perf run is a comparison between two versions of the +compiler (by their commit hashes). + +You should request a perf run if your PR may affect performance, especially +if it can affect performance adversely. + ## Further reading The following blog posts may also be of interest: From eaa2cc194626b7fa7c2ca778fba23ecc750976d3 Mon Sep 17 00:00:00 2001 From: Mark Date: Sun, 3 Jun 2018 22:46:11 -0500 Subject: [PATCH 0250/1812] Address review feedback --- src/tests/intro.md | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index 034b7aac1..f4164de5e 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -171,9 +171,10 @@ communicate with the server to coordinate running tests (see ## Crater [Crater](https://github.com/rust-lang-nursery/crater) is a tool for compiling -and running tests for _every_ crate on [crates.io](https://crates.io/). It is -mainly used for checking for extent of breakage when implementing potentially -breaking changes. +and running tests for _every_ crate on [crates.io](https://crates.io/) (and a +few on GitHub). It is mainly used for checking for extent of breakage when +implementing potentially breaking changes and ensuring lack of breakage by +running beta vs stable compiler versions. ### When to run Crater @@ -184,9 +185,16 @@ or could cause breakage. If you are unsure, feel free to ask your PR's reviewer. The rust team maintains a few machines that can be used for running crater runs on the changes introduced by a PR. If your PR needs a crater run, leave a -comment for the triage team in the PR thread. Your will be enqueued by the -triage team and the results will be posted when they are ready. A crater run -usually takes a few days (as of this writing). +comment for the triage team in the PR thread. Please inform the team whether +you require a "check-only" crater run, a "build only" crater run, or a +"build-and-test" crater run. The difference is primarily in time; the +conservative (if you're not sure) option is to go for the build-and-test run. +If making changes that will only have an effect at compile-time (e.g., +implementing a new trait) then you only need a check run. + +Your PR will be enqueued by the triage team and the results will be posted when +they are ready. Check runs will take around ~3-4 days, with the other two +taking 5-6 days on average. While crater is really useful, it is also important to be aware of a few caveats: @@ -195,9 +203,8 @@ While crater is really useful, it is also important to be aware of a few caveats successful crater run is not a magically green light that there will be no breakage; you still need to be careful. -- Crater only runs Linux builds (on x86_64, I believe). Thus, other - architectures and platforms are not tested. Critically, this includes - Windows. +- Crater only runs Linux builds on x86_64. Thus, other architectures and + platforms are not tested. Critically, this includes Windows. - Many crates are not tested. This could be for a lot of reasons, including that the crate doesn't compile any more (e.g. used old nightly features), From 35780c196e280e4a4a525a219c6a043b9f0aef28 Mon Sep 17 00:00:00 2001 From: Mark Date: Sun, 3 Jun 2018 22:48:03 -0500 Subject: [PATCH 0251/1812] long line --- src/tests/intro.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index f4164de5e..79aa0fd6a 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -196,7 +196,8 @@ Your PR will be enqueued by the triage team and the results will be posted when they are ready. Check runs will take around ~3-4 days, with the other two taking 5-6 days on average. -While crater is really useful, it is also important to be aware of a few caveats: +While crater is really useful, it is also important to be aware of a few +caveats: - Not all code is on crates.io! There is a lot of code in repos on GitHub and elsewhere. Also, companies may not wish to publish their code. Thus, a From 390068501f6b433c55136fc181edab40c6ae0da6 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 19:23:19 -0500 Subject: [PATCH 0252/1812] tests dont need to pass --- src/tests/intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index 79aa0fd6a..bd8a60a88 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -211,8 +211,8 @@ caveats: that the crate doesn't compile any more (e.g. used old nightly features), has broken or flaky tests, requires network access, or other reasons. -- Before crater can be run, `@bors try` needs to suceed. This means that if - your code doesn't compile or fails tests, you cannot run crater. +- Before crater can be run, `@bors try` needs to suceed in building artifacts. + This means that if your code doesn't compile, you cannot run crater. ## Perf runs From 63eaf6b11c343cf71ad01df4f96b28788ef8a229 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 19:46:05 -0500 Subject: [PATCH 0253/1812] fix typo --- src/tests/intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index bd8a60a88..bc84c9721 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -211,7 +211,7 @@ caveats: that the crate doesn't compile any more (e.g. used old nightly features), has broken or flaky tests, requires network access, or other reasons. -- Before crater can be run, `@bors try` needs to suceed in building artifacts. +- Before crater can be run, `@bors try` needs to succeed in building artifacts. This means that if your code doesn't compile, you cannot run crater. ## Perf runs From b859b33bbe0df3653e3be7a038752fb6b062783e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 20:40:23 -0500 Subject: [PATCH 0254/1812] Add bit about ctags; close #80 --- src/how-to-build-and-run.md | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 66c736548..54e60ddcb 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -75,9 +75,9 @@ internally. The result is the compiling `rustc` is done in stages. For hacking, often building the stage 1 compiler is enough, but for final testing and release, the stage 2 compiler is used. -`./x.py check` is really fast to build the rust compiler. -It is, in particular, very useful when you're doing some kind of -"type-based refactoring", like renaming a method, or changing the +`./x.py check` is really fast to build the rust compiler. +It is, in particular, very useful when you're doing some kind of +"type-based refactoring", like renaming a method, or changing the signature of some function. Once you've created a config.toml, you are now ready to run @@ -155,3 +155,21 @@ in other sections: more details): - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd - `./x.py test --stage 1 src/test/run-pass` – runs the `run-pass` test suite + +### ctags + +One of the challenges with rustc is that the RLS can't handle it, making code +navigation difficult. One solution is to use `ctags`. The following script can +be used to set it up: [https://github.com/nikomatsakis/rust-etags][etags]. + +CTAGS integrates into emacs and vim quite easily. The following can then be +used to build and generate tags: + +``` +rust-ctags src/lib* && ./x.py build +``` + +This allows you to do "jump-to-def" with whatever functions were around when +you last built, which is ridiculously useful. + +[etags]: https://github.com/nikomatsakis/rust-etags From b43d9881e2794b3bd18c5bfbd4d5f504e793a8d1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 4 Jun 2018 23:18:46 -0500 Subject: [PATCH 0255/1812] fix build --- src/how-to-build-and-run.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 54e60ddcb..557fc9148 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -165,8 +165,8 @@ be used to set it up: [https://github.com/nikomatsakis/rust-etags][etags]. CTAGS integrates into emacs and vim quite easily. The following can then be used to build and generate tags: -``` -rust-ctags src/lib* && ./x.py build +```console +$ rust-ctags src/lib* && ./x.py build ``` This allows you to do "jump-to-def" with whatever functions were around when From 7681b6ccc43863b9d627db5bc1ecc9ec48e9731b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 8 Jun 2018 20:32:04 -0500 Subject: [PATCH 0256/1812] mention bless --- src/tests/adding.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index 28f4c1140..fac13fcac 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -155,6 +155,8 @@ source. lint/warning is generated. Then, it applies the suggestion and compares against `.fixed` (they must match). Finally, the fixed source is compiled, and this compilation is required to succeed. + The `.fixed` file can also be generated automatically with the + `--bless` option, discussed [below](#bless). * `min-{gdb,lldb}-version` * `min-llvm-version` * `compile-pass` for UI tests, indicates that the test is @@ -270,6 +272,8 @@ you can even run the resulting program. Just add one of the following - `// run-pass` -- compilation should succeed and we should run the resulting binary + + ### Editing and updating the reference files If you have changed the compiler's output intentionally, or you are From 460342ca9b9cc0d0a27744af30983a68ab3990f7 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Sat, 9 Jun 2018 00:32:06 +0100 Subject: [PATCH 0257/1812] removed whitespace --- book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book.toml b/book.toml index f3a192c67..ecbe513b7 100644 --- a/book.toml +++ b/book.toml @@ -1,7 +1,7 @@ [book] title = "Guide to Rustc Development" author = "Rustc developers" -description = "A guide to developing rustc " +description = "A guide to developing rustc" [output.html] From 318057e479611b174a38a8d5453c7e71514945c6 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 8 Jun 2018 20:38:38 -0500 Subject: [PATCH 0258/1812] update trait ref --- src/appendix/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 62fa6bd93..ef7853fc6 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -24,7 +24,7 @@ Item | Kind | Short description | Chapter | `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html) `syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) -`TraitRef` | struct | Information about a trait reference (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) +`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) From 529a75575b84dcf95f4f27287fa63ff49012e160 Mon Sep 17 00:00:00 2001 From: scalexm Date: Thu, 7 Jun 2018 12:13:40 +0200 Subject: [PATCH 0259/1812] Add chalk rules for type defs --- src/traits/lowering-rules.md | 76 +++++++++++++++++++++++++++++++++++- 1 file changed, 75 insertions(+), 1 deletion(-) diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index f635ee857..e3febd9f2 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -174,6 +174,80 @@ we must show that `WellFormed(TraitRef)`. This in turn justifies the implied bounds rules that allow us to extend the set of `FromEnv` items. +## Lowering type definitions + +We also want to have some rules which define when a type is well-formed. +For example, given this type: + +```rust,ignore +struct Set where K: Hash { ... } +``` + +then `Set` is well-formed because `i32` implements `Hash`, but +`Set` would not be well-formed. Basically, a type is well-formed +if its parameters verify the where clauses written on the type definition. + +Hence, for every type definition: + +```rust, ignore +struct Type where WC { ... } +``` + +we produce the following rule: + +```text +// Rule WellFormed-Type +forall { + WellFormed(Type) :- WC +} +``` + +Note that we use `struct` for defining a type, but this should be understood +as a general type definition (it could be e.g. a generic `enum`). + +Conversely, we define rules which say that if we assume that a type is +well-formed, we can also assume that its where clauses hold. That is, +we produce the following family of rules: + +```text +// Rule FromEnv-Type +// +// For each where clause `WC` +forall { + FromEnv(WC) :- FromEnv(Type) +} +``` + +As for the implied bounds RFC, functions will *assume* that their arguments +are well-formed. For example, suppose we have the following bit of code: + +```rust,ignore +trait Hash: Eq { } +struct Set { ... } + +fn foo(collection: Set, x: K, y: K) { + // `x` and `y` can be equalized even if we did not explicitly write + // `where K: Eq` + if x == y { + ... + } +} +``` + +in the `foo` function, we assume that `Set` is well-formed, i.e. we have +`FromEnv(Set)` in our environment. Because of the previous rule, we get + `FromEnv(K: Hash)` without needing an explicit where clause. And because +of the `Hash` trait definition, there also exists a rule which says: + +```text +forall { + FromEnv(K: Eq) :- FromEnv(K: Hash) +} +``` + +which means that we finally get `FromEnv(K: Eq)` and then can compare `x` +and `y` without needing an explicit where clause. + ## Lowering trait items @@ -333,4 +407,4 @@ Chalk didn't model functions and constants, but I would eventually like to treat them exactly like normalization. This presumably involves adding a new kind of parameter (constant), and then having a `NormalizeValue` domain goal. This is *to be written* because the -details are a bit up in the air. +details are a bit up in the air. \ No newline at end of file From 7139188c0780612aefb7b2a114ea32c02ec0a44a Mon Sep 17 00:00:00 2001 From: scalexm Date: Tue, 12 Jun 2018 19:27:04 +0200 Subject: [PATCH 0260/1812] Capitalize a word --- src/traits/lowering-rules.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index e3febd9f2..d8b739890 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -234,7 +234,7 @@ fn foo(collection: Set, x: K, y: K) { } ``` -in the `foo` function, we assume that `Set` is well-formed, i.e. we have +In the `foo` function, we assume that `Set` is well-formed, i.e. we have `FromEnv(Set)` in our environment. Because of the previous rule, we get `FromEnv(K: Hash)` without needing an explicit where clause. And because of the `Hash` trait definition, there also exists a rule which says: @@ -407,4 +407,4 @@ Chalk didn't model functions and constants, but I would eventually like to treat them exactly like normalization. This presumably involves adding a new kind of parameter (constant), and then having a `NormalizeValue` domain goal. This is *to be written* because the -details are a bit up in the air. \ No newline at end of file +details are a bit up in the air. From c98cd5a6a843cbbc36f5e2db9fb94fa0fb9efcd2 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 2 Jun 2018 21:58:53 -0700 Subject: [PATCH 0261/1812] include `./` in example x.py commands for smoother copy-paste experience The current directory is typically not on the user's $PATH. --- src/rustdoc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rustdoc.md b/src/rustdoc.md index 36195c3a5..5bdfbeb6a 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -33,13 +33,13 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) ## Cheat sheet -* Use `x.py build --stage 1 src/libstd src/tools/rustdoc` to make a useable +* Use `./x.py build --stage 1 src/libstd src/tools/rustdoc` to make a useable rustdoc you can run on other projects. * Add `src/libtest` to be able to use `rustdoc --test`. * If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1` previously, then after the previous build command, `cargo +local doc` will Just Work. -* Use `x.py doc --stage 1 src/libstd` to use this rustdoc to generate the +* Use `./x.py doc --stage 1 src/libstd` to use this rustdoc to generate the standard library docs. * The completed docs will be available in `build/$TARGET/doc/std`, though the bundle is meant to be used as though you would copy out the `doc` folder to From addc94950a3d70c5d0e96cd7238567fc1f834a5b Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sun, 24 Jun 2018 19:08:02 -0700 Subject: [PATCH 0262/1812] don't mention new rustdoc Steve says it's not ready (https://github.com/rust-lang-nursery/rustc-guide/pull/150#issuecomment-395783504). --- src/rustdoc.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/rustdoc.md b/src/rustdoc.md index 5bdfbeb6a..76a8b28ce 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -1,10 +1,7 @@ # The walking tour of rustdoc Rustdoc actually uses the rustc internals directly. It lives in-tree with the -compiler and standard library. This chapter is about how it works. (A new -implementation is also [under way], though). - -[under way]: https://github.com/steveklabnik/rustdoc +compiler and standard library. This chapter is about how it works. Rustdoc is implemented entirely within the crate [`librustdoc`][rd]. It runs the compiler up to the point where we have an internal representation of a From 85d30364b066a198d038ec7c02ecc42fe2f830db Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Thu, 14 Jun 2018 20:35:35 +0300 Subject: [PATCH 0263/1812] rustc: rename ty::maps to ty::query. --- src/high-level-overview.md | 2 +- src/query.md | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index be396054b..dce6b4c41 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -85,7 +85,7 @@ input, running the type-checker, and so forth. This on-demand model permits us to do exciting things like only do the minimal amount of work needed to type-check a single function. It also helps with incremental compilation. (For details on defining queries, check out -`src/librustc/ty/maps/README.md`.) +`src/librustc/ty/query/README.md`.) Regardless of the general setup, the basic operations that the compiler must perform are the same. The only thing that changes is diff --git a/src/query.md b/src/query.md index d48b6e7e3..62a627135 100644 --- a/src/query.md +++ b/src/query.md @@ -63,7 +63,7 @@ get to use the nice method-call-style syntax. Instead, you invoke using the `try_get` method, which looks roughly like this: ```rust,ignore -use ty::maps::queries; +use ty::queries; ... match queries::type_of::try_get(tcx, DUMMY_SP, self.did) { Ok(result) => { @@ -215,14 +215,14 @@ Well, defining a query takes place in two steps: To specify the query name and arguments, you simply add an entry to the big macro invocation in -[`src/librustc/ty/maps/mod.rs`][maps-mod]. This will probably have +[`src/librustc/ty/query/mod.rs`][query-mod]. This will probably have changed by the time you read this README, but at present it looks something like: -[maps-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/maps/index.html +[query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/index.html ```rust,ignore -define_maps! { <'tcx> +define_queries! { <'tcx> /// Records the type of every item. [] fn type_of: TypeOfItem(DefId) -> Ty<'tcx>, @@ -250,7 +250,7 @@ Let's go over them one by one: processed. - **Name of query:** the name of the query method (`tcx.type_of(..)`). Also used as the name of a struct - (`ty::maps::queries::type_of`) that will be generated to represent + (`ty::queries::type_of`) that will be generated to represent this query. - **Dep-node constructor:** indicates the constructor function that connects this query to incremental compilation. Typically, this is a @@ -262,7 +262,7 @@ Let's go over them one by one: bottom of the file. This is typically used when the query key is not a def-id, or just not the type that the dep-node expects. - **Query key type:** the type of the argument to this query. - This type must implement the `ty::maps::keys::Key` trait, which + This type must implement the `ty::query::keys::Key` trait, which defines (for example) how to map it to a crate, and so forth. - **Result type of query:** the type produced by this query. This type should (a) not use `RefCell` or other interior mutability and (b) be @@ -277,14 +277,14 @@ Let's go over them one by one: So, to add a query: -- Add an entry to `define_maps!` using the format above. +- Add an entry to `define_queries!` using the format above. - Possibly add a corresponding entry to the dep-node macro. - Link the provider by modifying the appropriate `provide` method; or add a new one if needed and ensure that `rustc_driver` is invoking it. #### Query structs and descriptions -For each kind, the `define_maps` macro will generate a "query struct" +For each kind, the `define_queries` macro will generate a "query struct" named after the query. This struct is a kind of a place-holder describing the query. Each such struct implements the `self::config::QueryConfig` trait, which has associated types for the From b1fa3579b8894dad4568148f2b79cb6e72dd5062 Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Mon, 25 Jun 2018 07:07:19 +0300 Subject: [PATCH 0264/1812] Update high-level-overview.md --- src/high-level-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index dce6b4c41..8e49afaa9 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -85,7 +85,7 @@ input, running the type-checker, and so forth. This on-demand model permits us to do exciting things like only do the minimal amount of work needed to type-check a single function. It also helps with incremental compilation. (For details on defining queries, check out -`src/librustc/ty/query/README.md`.) +the [query model].) Regardless of the general setup, the basic operations that the compiler must perform are the same. The only thing that changes is From 7bf9416221cc6ee2ccea4cb5c04dca1de9609666 Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Mon, 25 Jun 2018 07:09:22 +0300 Subject: [PATCH 0265/1812] Update query.md --- src/query.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/query.md b/src/query.md index 62a627135..7ed299b74 100644 --- a/src/query.md +++ b/src/query.md @@ -215,9 +215,7 @@ Well, defining a query takes place in two steps: To specify the query name and arguments, you simply add an entry to the big macro invocation in -[`src/librustc/ty/query/mod.rs`][query-mod]. This will probably have -changed by the time you read this README, but at present it looks -something like: +[`src/librustc/ty/query/mod.rs`][query-mod], which looks something like: [query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/index.html From ec8d0498d6105451623f493d30deb5f5260c612a Mon Sep 17 00:00:00 2001 From: Alex Kitchens Date: Sun, 24 Jun 2018 21:56:01 -0500 Subject: [PATCH 0266/1812] Rename trans to codegen This commit is a followup of changes from [b63d7e2b1c4019e40051036bcb1fd5f254a8f6e2](https://github.com/rust-lang/rust/commit/b63d7e2b1c4019e40051036bcb1fd5f254a8f6e2#diff-b433c87466d984aa7eeded378ea6c392) in the Rust source to rename trans to codegen. --- src/SUMMARY.md | 2 +- src/appendix/glossary.md | 4 ++-- src/{trans.md => codegen.md} | 0 src/high-level-overview.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) rename src/{trans.md => codegen.md} (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 8efe304b7..f60fee488 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -53,7 +53,7 @@ - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) -- [Generating LLVM IR](./trans.md) +- [Generating LLVM IR](./codegen.md) - [Emitting Diagnostics](./diag.md) --- diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index a6f4e7b1c..c2947090a 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -35,7 +35,7 @@ IR | Intermediate Representation. A general term in compil local crate | the crate currently being compiled. LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optmizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. -MIR | the Mid-level IR that is created after type-checking for use by borrowck and trans ([see more](./mir/index.html)) +MIR | the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](./mir/index.html)) miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](./traits/associated-types.html#normalize) newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. @@ -61,7 +61,7 @@ tcx | the "typing context", main data structure of the comp trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](./traits/goals-and-clauses.html#trait-ref)) token | the smallest unit of parsing. Tokens are produced after lexing ([see more](the-parser.html)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. -trans | the code to translate MIR into LLVM IR. +codegen | the code to translate MIR into LLVM IR. trait reference | a trait and values for its type parameters ([see more](ty.html)). ty | the internal representation of a type ([see more](ty.html)). UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](type-checking.html)). diff --git a/src/trans.md b/src/codegen.md similarity index 100% rename from src/trans.md rename to src/codegen.md diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 8e49afaa9..60b9e80ea 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -8,7 +8,7 @@ standard library and the compiler. This document, of course, focuses on the latter. Rustc consists of a number of crates, including `syntax`, -`rustc`, `rustc_back`, `rustc_trans`, `rustc_driver`, and +`rustc`, `rustc_back`, `rustc_codegen`, `rustc_driver`, and many more. The source for each crate can be found in a directory like `src/libXXX`, where `XXX` is the crate name. @@ -25,7 +25,7 @@ The dependency structure of these crates is roughly a diamond: / | \ / | \ / v \ -rustc_trans rustc_borrowck ... rustc_metadata +rustc_codegen rustc_borrowck ... rustc_metadata \ | / \ | / \ | / From 37872481acc1ee3212782fd54de913607709642c Mon Sep 17 00:00:00 2001 From: Alex Kitchens Date: Tue, 26 Jun 2018 11:28:30 -0500 Subject: [PATCH 0267/1812] Keep glossary definition of codegen --- src/appendix/glossary.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index c2947090a..bfc2c0d22 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -9,6 +9,7 @@ Term | Meaning AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./appendix/background.html#free-vs-bound) bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./appendix/background.html#free-vs-bound) +codegen | the code to translate MIR into LLVM IR. codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./appendix/background.html#cfg) @@ -61,7 +62,7 @@ tcx | the "typing context", main data structure of the comp trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](./traits/goals-and-clauses.html#trait-ref)) token | the smallest unit of parsing. Tokens are produced after lexing ([see more](the-parser.html)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. -codegen | the code to translate MIR into LLVM IR. +trans | the code to translate MIR into LLVM IR. Renamed to codegen. trait reference | a trait and values for its type parameters ([see more](ty.html)). ty | the internal representation of a type ([see more](ty.html)). UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](type-checking.html)). From 95bdeacaeaa73bb13deeaa25da90b6926fd57dc0 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 08:34:31 -0700 Subject: [PATCH 0268/1812] add links for `Span`, `CodeMap`, and `rustfix` It's unfortunate that `code-monospaced` links don't render with link colors (such that the reader needs to hover over them just to tell that it is a link), but that's presumably a bug in MdBook, and not something we need concern ourselves with here. --- src/diag.md | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/src/diag.md b/src/diag.md index 6043a79b7..389ba2bbc 100644 --- a/src/diag.md +++ b/src/diag.md @@ -5,14 +5,17 @@ This chapter is about how to emit compile errors and lints from the compiler. ## `Span` -`Span` is the primary data structure in `rustc` used to represent a location in -the code being compiled. `Span`s are attached to most constructs in HIR and MIR, -allowing for easier error reporting whenever an error comes up. +[`Span`][span] is the primary data structure in `rustc` used to represent a +location in the code being compiled. `Span`s are attached to most constructs in +HIR and MIR, allowing for easier error reporting whenever an error comes up. -A `Span` can be looked up in a `CodeMap` to get a "snippet" useful for -displaying errors with [`span_to_snippet` and other similar methods][sptosnip] -on the `CodeMap`. +[span]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.Span.html +A `Span` can be looked up in a [`CodeMap`][codemap] to get a "snippet" useful +for displaying errors with [`span_to_snippet`][sptosnip] and other similar +methods on the `CodeMap`. + +[codemap]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html [sptosnip]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html#method.span_to_snippet ## Error messages @@ -70,14 +73,16 @@ err.emit(); ## Suggestions We would like to make edition transitions as smooth as possible. To that end, -`rustfix` can use compiler suggestions to automatically fix code. For example, -we could use `rustfix` to mechanically apply the `qux` suggestion from the -previous example. However, not all suggestions are mechanically applicable. We -use the [`span_suggestion_with_applicability`][sswa] method of -`DiagnosticBuilder` to inform the emitter of whether a suggestion is -mechanically applicable or not. This information, in turn, is outputed by -rustc when the error format is `json`, which is used by `rustfix`. - +[`rustfix`][rustfix] can use compiler suggestions to automatically fix +code. For example, we could use `rustfix` to mechanically apply the `qux` +suggestion from the previous example. However, not all suggestions are +mechanically applicable. We use the +[`span_suggestion_with_applicability`][sswa] method of `DiagnosticBuilder` to +inform the emitter of whether a suggestion is mechanically applicable or not. +This information, in turn, is outputed by rustc when the error format is +`json`, which is used by `rustfix`. + +[rustfix]: https://github.com/rust-lang-nursery/rustfix/ [sswa]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html#method.span_suggestion_with_applicability For example, to make our `qux` suggestion machine-applicable, we would do: From 14ef432e4829f0bd47a44a6caf9552f50b763bb2 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 08:37:15 -0700 Subject: [PATCH 0269/1812] `span_to_snippet` return value is a `Result`, not an `Option` --- src/diag.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/diag.md b/src/diag.md index 389ba2bbc..5984e8621 100644 --- a/src/diag.md +++ b/src/diag.md @@ -56,7 +56,7 @@ let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); // In some cases, you might need to check if `sp` is generated by a macro to // avoid printing weird errors about macro-generated code. -if let Some(snippet) = sess.codemap().span_to_snippet(sp) { +if let Ok(snippet) = sess.codemap().span_to_snippet(sp) { // Use the snippet to generate a suggested fix err.span_suggestion(suggestion_sp, "try using a qux here", format!("qux {}", snip)); } else { @@ -90,7 +90,7 @@ For example, to make our `qux` suggestion machine-applicable, we would do: ```rust,ignore let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); -if let Some(snippet) = sess.codemap().span_to_snippet(sp) { +if let Ok(snippet) = sess.codemap().span_to_snippet(sp) { // Add applicability info! err.span_suggestion_with_applicability( suggestion_sp, From c345de354ca53d138d75d976c320dfde8151bde6 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 08:50:28 -0700 Subject: [PATCH 0270/1812] =?UTF-8?q?"easier"=20=E2=86=92=20"more=20inform?= =?UTF-8?q?ative";=20omit=20needless=20clause?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We don't want to leave the impression that spans are about making it easier for compiler developers to perform the arduous task of emitting an error; spans are about pointing to particular segments of code in the emitted error messages. Also, we don't need to say "whenever an error comes up"; that's implied by the phrase "error reporting." --- src/diag.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/diag.md b/src/diag.md index 5984e8621..0bef3e274 100644 --- a/src/diag.md +++ b/src/diag.md @@ -7,7 +7,7 @@ This chapter is about how to emit compile errors and lints from the compiler. [`Span`][span] is the primary data structure in `rustc` used to represent a location in the code being compiled. `Span`s are attached to most constructs in -HIR and MIR, allowing for easier error reporting whenever an error comes up. +HIR and MIR, allowing for more informative error reporting. [span]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.Span.html From 2cb56f31fef588e2d7fd5acbbe8b3de6edc48385 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 08:55:04 -0700 Subject: [PATCH 0271/1812] cautionary parenthetical about failing to emit a `DiagnosticBuilder` --- src/diag.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/diag.md b/src/diag.md index 0bef3e274..26fc200af 100644 --- a/src/diag.md +++ b/src/diag.md @@ -41,13 +41,15 @@ directly and ones that allow finer control over what to emit. For example, [`DiagnosticBuilder`][diagbuild]. `DiagnosticBuilder` allows you to add related notes and suggestions to an error -before emitting it by calling the [`emit`][emit] method. See the +before emitting it by calling the [`emit`][emit] method. (Failing to either +emit or [cancel][cancel] a `DiagnosticBuilder` will result in an ICE.) See the [docs][diagbuild] for more info on what you can do. [spanerr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html#method.span_err [strspanerr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html#method.struct_span_err [diagbuild]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html [emit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html#method.emit +[cancel]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Diagnostic.html#method.cancel ```rust,ignore // Get a DiagnosticBuilder. This does _not_ emit an error yet. From 85645644db2461375a9239f0fd9a392c54353e26 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 09:03:00 -0700 Subject: [PATCH 0272/1812] mention lint-level command line flags as well as attributes --- src/diag.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/diag.md b/src/diag.md index 26fc200af..e4c257fd8 100644 --- a/src/diag.md +++ b/src/diag.md @@ -261,4 +261,5 @@ For example, ``` This defines the `nonstandard_style` group which turns on the listed lints. A -user can turn on these lints by using `!#[warn(nonstandard_style)]`. +user can turn on these lints with a `!#[warn(nonstandard_style)]` attribute in +the source code, or by passing `-W nonstandard-style` on the command line. From 196d10ea87c55bda3e5d22313bf62e81b6ad0cfe Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 16:55:13 -0700 Subject: [PATCH 0273/1812] rewrite suggestions intro to be less bizarrely edition/rustfix centric The suggestions API was introduced in April 2015 (rust-lang/rust@906a9728ff), long predating rustfix (initial commit July 2016) or editions (RFC 2052 approved September 2017). --- src/diag.md | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/src/diag.md b/src/diag.md index e4c257fd8..a0e755718 100644 --- a/src/diag.md +++ b/src/diag.md @@ -74,17 +74,21 @@ err.emit(); ## Suggestions -We would like to make edition transitions as smooth as possible. To that end, -[`rustfix`][rustfix] can use compiler suggestions to automatically fix -code. For example, we could use `rustfix` to mechanically apply the `qux` -suggestion from the previous example. However, not all suggestions are -mechanically applicable. We use the +In addition to telling the user exactly _why_ their code is wrong, it's +oftentimes furthermore possible to tell them how to fix it. To this end, +`DiagnosticBuilder` offers a structured suggestions API, which formats code +suggestions pleasingly in the terminal, or (when the `--error-format json` flag +is passed) as JSON for consumption by tools, most notably the [Rust Language +Server][rls] and [`rustfix`][rustfix]. + +[rls]: https://github.com/rust-lang-nursery/rls +[rustfix]: https://github.com/rust-lang-nursery/rustfix + +Not all suggestions should be applied mechanically. Use the [`span_suggestion_with_applicability`][sswa] method of `DiagnosticBuilder` to -inform the emitter of whether a suggestion is mechanically applicable or not. -This information, in turn, is outputed by rustc when the error format is -`json`, which is used by `rustfix`. +make a suggestion while providing a hint to tools whether the suggestion is +mechanically applicable or not. -[rustfix]: https://github.com/rust-lang-nursery/rustfix/ [sswa]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html#method.span_suggestion_with_applicability For example, to make our `qux` suggestion machine-applicable, we would do: From 79ebdb7b53a21cdc237159e9a9f856ee2b629c5d Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Sat, 30 Jun 2018 17:03:08 -0700 Subject: [PATCH 0274/1812] =?UTF-8?q?"and=20has"=20=E2=86=92=20"because=20?= =?UTF-8?q?it=20has"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/diag.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/diag.md b/src/diag.md index a0e755718..67bd4829c 100644 --- a/src/diag.md +++ b/src/diag.md @@ -148,8 +148,9 @@ For more information about this error, try `rustc --explain E0999`. There are a few other [`Applicability`][appl] possibilities: - `MachineApplicable`: Can be applied mechanically. -- `HasPlaceholders`: Cannot be applied mechanically and has placeholder text in - the suggestions. For example, "Try adding a type: \`let x: \\`". +- `HasPlaceholders`: Cannot be applied mechanically because it has placeholder + text in the suggestions. For example, "Try adding a type: \`let x: + \\`". - `MaybeIncorrect`: Cannot be applied mechanically because the suggestion may or may not be a good one. - `Unspecified`: Cannot be applied mechanically because we don't know which From 7fe7f7401c7653b6cdd02a74d967d0745fbbcfee Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 4 Jul 2018 17:17:20 -0500 Subject: [PATCH 0275/1812] add a link to the rustc docs --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index 07d1749e8..5dc64ed4d 100644 --- a/README.md +++ b/README.md @@ -5,6 +5,10 @@ some new part of the compiler that they haven't worked on before. [You can read the latest version of the guide here.](https://rust-lang-nursery.github.io/rustc-guide/) +You may also find the rustdocs [for the compiler itself][rustdocs] useful. + +[rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ + The guide can be useful today, but it has a lot of work still go. Once it gets more complete, the plan is probably to move it into the [main Rust repository](https://github.com/rust-lang/rust/). From f394cd109c99f62304766a7895ce79d9334c1fe5 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Fri, 1 Jun 2018 17:34:45 +0200 Subject: [PATCH 0276/1812] Add some explanation of lowering ids --- src/high-level-overview.md | 3 ++- src/lowering.md | 35 +++++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 1 deletion(-) create mode 100644 src/lowering.md diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 60b9e80ea..733c523c9 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -105,7 +105,7 @@ take: 3. **Lowering to HIR** - Once name resolution completes, we convert the AST into the HIR, or "[high-level intermediate representation]". The HIR is defined in - `src/librustc/hir/`; that module also includes the lowering code. + `src/librustc/hir/`; that module also includes the [lowering] code. - The HIR is a lightly desugared variant of the AST. It is more processed than the AST and more suitable for the analyses that follow. It is **not** required to match the syntax of the Rust language. @@ -139,3 +139,4 @@ take: [query model]: query.html [high-level intermediate representation]: hir.html +[lowering]: lowering.html \ No newline at end of file diff --git a/src/lowering.md b/src/lowering.md new file mode 100644 index 000000000..335513342 --- /dev/null +++ b/src/lowering.md @@ -0,0 +1,35 @@ +# Lowering + +The lowering step converts AST to [HIR](hir.html). +This means many structures are removed if they are irrelevant +for type analysis or similar syntax agnostic analyses. Examples +of such structures include but are not limited to + +* Parenthesis + * Removed without replacement, the tree structure makes order explicit +* `for` loops and `while (let)` loops + * Converted to `loop` + `match` and some `let` bindings +* `if let` + * Converted to `match` +* Universal `impl Trait` + * Converted to generic arguments (but with some flags, to know that the user didn't write them) +* Existential `impl Trait` + * Converted to a virtual `existential type` declaration + +Lowering needs to uphold several invariants in order to not trigger the +sanity checks in `src/librustc/hir/map/hir_id_validator.rs`: + +1. A `HirId` must be used if created. So if you use the `lower_node_id`, + you *must* use the resulting `NodeId` or `HirId` (either is fine, since + any `NodeId`s in the `HIR` are checked for existing `HirId`s) +2. Lowering a `HirId` must be done in the scope of the *owning* item. + This means you need to use `with_hir_id_owner` if you are creating parts + of another item than the one being currently lowered. This happens for + example during the lowering of existential `impl Trait` +3. A `NodeId` that will be placed into a HIR structure must be lowered, + even if its `HirId` is unused. Calling + `let _ = self.lower_node_id(node_id);` is perfectly legitimate. +4. If you are creating new nodes that didn't exist in the `AST`, you *must* + create new ids for them. This is done by calling the `next_id` method, + which produces both a new `NodeId` as well as automatically lowering it + for you so you also get the `HirId`. \ No newline at end of file From e8a0108259409b2f4513f9a3b68f5acd18ede4b3 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Thu, 5 Jul 2018 09:30:05 +0200 Subject: [PATCH 0277/1812] Address review --- src/SUMMARY.md | 1 + src/hir.md | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f60fee488..a41f78a1a 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -20,6 +20,7 @@ - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) - [The HIR (High-level IR)](./hir.md) + - [Lowering AST to HIR](./lowering.md) - [The `ty` module: representing types](./ty.md) - [Type inference](./type-inference.md) - [Trait solving (old-style)](./traits/resolution.md) diff --git a/src/hir.md b/src/hir.md index 2a11531ee..0d6a6fbff 100644 --- a/src/hir.md +++ b/src/hir.md @@ -3,7 +3,8 @@ The HIR – "High-Level Intermediate Representation" – is the primary IR used in most of rustc. It is a compiler-friendly representation of the abstract syntax tree (AST) that is generated after parsing, macro expansion, and name -resolution. Many parts of HIR resemble Rust surface syntax quite closely, with +resolution (see [Lowering](./lowering.md) for how the HIR is created). +Many parts of HIR resemble Rust surface syntax quite closely, with the exception that some of Rust's expression forms have been desugared away. For example, `for` loops are converted into a `loop` and do not appear in the HIR. This makes HIR more amenable to analysis than a normal AST. From f2e7ef167512f496cce7d30953a629e563a4ccde Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Thu, 5 Jul 2018 09:34:37 +0200 Subject: [PATCH 0278/1812] Add some details about `DefId` creation --- src/lowering.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/src/lowering.md b/src/lowering.md index 335513342..cc2a7b384 100644 --- a/src/lowering.md +++ b/src/lowering.md @@ -32,4 +32,16 @@ sanity checks in `src/librustc/hir/map/hir_id_validator.rs`: 4. If you are creating new nodes that didn't exist in the `AST`, you *must* create new ids for them. This is done by calling the `next_id` method, which produces both a new `NodeId` as well as automatically lowering it - for you so you also get the `HirId`. \ No newline at end of file + for you so you also get the `HirId`. + +If you are creating new `DefId`s, since each `DefId` needs to have a corresponding +`NodeId`, it is adviseable to add these `NodeId`s to the `AST` so you don't have +to generate new ones during lowering. This has the advantage of creating a +way to find the `DefId` of something via its `NodeId`. If lowering needs this +`DefId` in multiple places, you can't generate a new `NodeId` in all those places +because you'd also get a new `DefId` then. With a `NodeId` from the `AST` this is +not an issue. + +Having the `NodeId` also allows the `DefCollector` to generate the `DefId`s instead +of lowering having to do it on the fly. Centralizing the `DefId` generation in one +place makes it easier to refactor and reason about. \ No newline at end of file From 928470c8cc1b0ef15552deeca46e45f5a508abb7 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Fri, 6 Jul 2018 14:25:34 +0200 Subject: [PATCH 0279/1812] Satisfy tidy checks --- src/hir.md | 12 ++++++------ src/lowering.md | 23 ++++++++++++----------- src/name-resolution.md | 12 ++++++------ 3 files changed, 24 insertions(+), 23 deletions(-) diff --git a/src/hir.md b/src/hir.md index 0d6a6fbff..0fd2fcff5 100644 --- a/src/hir.md +++ b/src/hir.md @@ -1,13 +1,13 @@ # The HIR -The HIR – "High-Level Intermediate Representation" – is the primary IR used in -most of rustc. It is a compiler-friendly representation of the abstract syntax -tree (AST) that is generated after parsing, macro expansion, and name +The HIR – "High-Level Intermediate Representation" – is the primary IR used +in most of rustc. It is a compiler-friendly representation of the abstract +syntax tree (AST) that is generated after parsing, macro expansion, and name resolution (see [Lowering](./lowering.md) for how the HIR is created). Many parts of HIR resemble Rust surface syntax quite closely, with -the exception that some of Rust's expression forms have been desugared away. For -example, `for` loops are converted into a `loop` and do not appear in the HIR. -This makes HIR more amenable to analysis than a normal AST. +the exception that some of Rust's expression forms have been desugared away. +For example, `for` loops are converted into a `loop` and do not appear in +the HIR. This makes HIR more amenable to analysis than a normal AST. This chapter covers the main concepts of the HIR. diff --git a/src/lowering.md b/src/lowering.md index cc2a7b384..eddc00af9 100644 --- a/src/lowering.md +++ b/src/lowering.md @@ -12,7 +12,8 @@ of such structures include but are not limited to * `if let` * Converted to `match` * Universal `impl Trait` - * Converted to generic arguments (but with some flags, to know that the user didn't write them) + * Converted to generic arguments + (but with some flags, to know that the user didn't write them) * Existential `impl Trait` * Converted to a virtual `existential type` declaration @@ -34,14 +35,14 @@ sanity checks in `src/librustc/hir/map/hir_id_validator.rs`: which produces both a new `NodeId` as well as automatically lowering it for you so you also get the `HirId`. -If you are creating new `DefId`s, since each `DefId` needs to have a corresponding -`NodeId`, it is adviseable to add these `NodeId`s to the `AST` so you don't have -to generate new ones during lowering. This has the advantage of creating a -way to find the `DefId` of something via its `NodeId`. If lowering needs this -`DefId` in multiple places, you can't generate a new `NodeId` in all those places -because you'd also get a new `DefId` then. With a `NodeId` from the `AST` this is -not an issue. +If you are creating new `DefId`s, since each `DefId` needs to have a +corresponding `NodeId`, it is adviseable to add these `NodeId`s to the +`AST` so you don't have to generate new ones during lowering. This has +the advantage of creating a way to find the `DefId` of something via its +`NodeId`. If lowering needs this `DefId` in multiple places, you can't +generate a new `NodeId` in all those places because you'd also get a new +`DefId` then. With a `NodeId` from the `AST` this is not an issue. -Having the `NodeId` also allows the `DefCollector` to generate the `DefId`s instead -of lowering having to do it on the fly. Centralizing the `DefId` generation in one -place makes it easier to refactor and reason about. \ No newline at end of file +Having the `NodeId` also allows the `DefCollector` to generate the `DefId`s +instead of lowering having to do it on the fly. Centralizing the `DefId` +generation in one place makes it easier to refactor and reason about. \ No newline at end of file diff --git a/src/name-resolution.md b/src/name-resolution.md index 5095b750a..bba3142fc 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -36,9 +36,9 @@ hierarchy, it's types vs. values vs. macros. ## Scopes and ribs A name is visible only in certain area in the source code. This forms a -hierarchical structure, but not necessarily a simple one ‒ if one scope is part -of another, it doesn't mean the name visible in the outer one is also visible in -the inner one, or that it refers to the same thing. +hierarchical structure, but not necessarily a simple one ‒ if one scope is +part of another, it doesn't mean the name visible in the outer one is also +visible in the inner one, or that it refers to the same thing. To cope with that, the compiler introduces the concept of Ribs. This is abstraction of a scope. Every time the set of visible names potentially changes, @@ -54,9 +54,9 @@ example: When searching for a name, the stack of ribs is traversed from the innermost outwards. This helps to find the closest meaning of the name (the one not shadowed by anything else). The transition to outer rib may also change the -rules what names are usable ‒ if there are nested functions (not closures), the -inner one can't access parameters and local bindings of the outer one, even -though they should be visible by ordinary scoping rules. An example: +rules what names are usable ‒ if there are nested functions (not closures), +the inner one can't access parameters and local bindings of the outer one, +even though they should be visible by ordinary scoping rules. An example: ```rust fn do_something(val: T) { // <- New rib in both types and values (1) From c52d026a1f0d6c599be89ef0244dbb70016688b3 Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Fri, 6 Jul 2018 14:39:24 +0200 Subject: [PATCH 0280/1812] md -> html --- src/hir.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hir.md b/src/hir.md index 0fd2fcff5..40a14dc25 100644 --- a/src/hir.md +++ b/src/hir.md @@ -3,7 +3,7 @@ The HIR – "High-Level Intermediate Representation" – is the primary IR used in most of rustc. It is a compiler-friendly representation of the abstract syntax tree (AST) that is generated after parsing, macro expansion, and name -resolution (see [Lowering](./lowering.md) for how the HIR is created). +resolution (see [Lowering](./lowering.html) for how the HIR is created). Many parts of HIR resemble Rust surface syntax quite closely, with the exception that some of Rust's expression forms have been desugared away. For example, `for` loops are converted into a `loop` and do not appear in From bf2f7c85b55715ef034eff2741719b8413a875cf Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 8 Jul 2018 18:34:25 -0500 Subject: [PATCH 0281/1812] Quick fix: copy/paste error --- src/compiler-debugging.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 4b445c924..c8fb6dd08 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -1,8 +1,3 @@ ---- -layout: default -title: Debugging the Compiler ---- - **Note: This is copied from the [rust-forge](https://github.com/rust-lang-nursery/rust-forge). If anything needs updating, please open an issue or make a PR on the github repo.** From 911231180313389f7552cd80d521b74c939c0b9e Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 9 Jul 2018 13:28:29 -0500 Subject: [PATCH 0282/1812] Add the small amount i know about hygiene (#167) * add the small amount i know about hygiene * use en-dash --- src/macro-expansion.md | 50 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index df0dc7b1d..bb3116d40 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -143,6 +143,55 @@ in [`src/libsyntax/ext/tt/macro_parser.rs`][code_mp]. ### Hygiene +If you have ever used C/C++ preprocessor macros, you know that there are some +annoying and hard-to-debug gotchas! For example, consider the following C code: + +```c +#define DEFINE_FOO struct Bar {int x;}; struct Foo {Bar bar;}; + +// Then, somewhere else +struct Bar { + ... +}; + +DEFINE_FOO +``` + +Most people avoid writing C like this – and for good reason: it doesn't +compile. The `struct Bar` defined by the macro clashes names with the `struct +Bar` defined in the code. Consider also the following example: + +```c +#define DO_FOO(x) {\ + int y = 0;\ + foo(x, y);\ + } + +// Then elsewhere +int y = 22; +DO_FOO(y); +``` + +Do you see the problem? We wanted to generate a call `foo(22, 0)`, but instead +we got `foo(0, 0)` because the macro defined its own `y`! + +These are both examples of _macro hygiene_ issues. _Hygiene_ relates to how to +handle names defined _within a macro_. In particular, a hygienic macro system +prevents errors due to names introduced within a macro. Rust macros are hygienic +in that they do not allow one to write the sorts of bugs above. + +At a high level, hygiene within the rust compiler is accomplished by keeping +track of the context where a name is introduced and used. We can then +disambiguate names based on that context. Future iterations of the macro system +will allow greater control to the macro author to use that context. For example, +a macro author may want to introduce a new name to the context where the macro +was called. Alternately, the macro author may be defining a variable for use +only within the macro (i.e. it should not be visible outside the macro). + +In rustc, this "context" is tracked via `Span`s. + +TODO: what is call-site hygiene? what is def-site hygiene? + TODO ### Procedural Macros @@ -153,6 +202,7 @@ TODO TODO +TODO: maybe something about macros 2.0? [code_dir]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt From a154eb95492aa5218f947cb2099fed2a67f66716 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Mon, 9 Jul 2018 05:10:27 -0700 Subject: [PATCH 0283/1812] Update mdbook Closes #138 Closes #160 --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index 69b96cc73..29e3a2f9b 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -20,5 +20,5 @@ function cargo_install() { fi } -cargo_install mdbook 0.1.7 +cargo_install mdbook 0.1.8 cargo_install mdbook-linkcheck 0.1.2 From 37a202cdba5bc9023d7bbe53628126fb0f2eec06 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 19:49:34 -0500 Subject: [PATCH 0284/1812] fix all the not-en-dashes --- README.md | 4 +-- src/appendix/background.md | 4 +-- src/compiletest.md | 2 +- src/conventions.md | 6 ++--- src/incrcomp-debugging.md | 2 +- src/mir/borrowck.md | 2 +- src/mir/index.md | 10 +++---- src/mir/passes.md | 6 ++--- src/mir/regionck.md | 36 ++++++++++++------------- src/mir/visitor.md | 2 +- src/query.md | 2 +- src/tests/adding.md | 8 +++--- src/tests/intro.md | 48 ++++++++++++++++----------------- src/tests/running.md | 4 +-- src/traits/associated-types.md | 10 +++---- src/traits/canonical-queries.md | 12 ++++----- src/traits/canonicalization.md | 2 +- src/traits/goals-and-clauses.md | 4 +-- src/traits/index.md | 2 +- src/traits/lowering-module.md | 4 +-- src/traits/lowering-rules.md | 10 +++---- src/traits/lowering-to-logic.md | 10 +++---- src/type-checking.md | 4 +-- src/variance.md | 6 ++--- 24 files changed, 100 insertions(+), 100 deletions(-) diff --git a/README.md b/README.md index 5dc64ed4d..a01758d48 100644 --- a/README.md +++ b/README.md @@ -18,8 +18,8 @@ Once it gets more complete, the plan is probably to move it into the If you'd like to help finish the guide, we'd love to have you! The main tracking issue for the guide [can be found here](https://github.com/rust-lang-nursery/rustc-guide/issues/6). From -there, you can find a list of all the planned chapters and subsections --- if you think something is missing, please open an issue about it! +there, you can find a list of all the planned chapters and subsections. +If you think something is missing, please open an issue about it! Otherwise, find a chapter that sounds interesting to you and then go to its associated issue. There should be a list of things to do. diff --git a/src/appendix/background.md b/src/appendix/background.md index 069131947..efdce4f2a 100644 --- a/src/appendix/background.md +++ b/src/appendix/background.md @@ -15,7 +15,7 @@ exposes the underlying control flow in a very clear way. A control-flow graph is structured as a set of **basic blocks** connected by edges. The key idea of a basic block is that it is a set -of statements that execute "together" -- that is, whenever you branch +of statements that execute "together" – that is, whenever you branch to a basic block, you start at the first statement and then execute all the remainder. Only at the end of the block is there the possibility of branching to more than one place (in MIR, we call that @@ -119,7 +119,7 @@ variables, since that's the thing we're most familiar with. So there you have it: a variable "appears free" in some expression/statement/whatever if it refers to something defined outside of that expressions/statement/whatever. Equivalently, we can -then refer to the "free variables" of an expression -- which is just +then refer to the "free variables" of an expression – which is just the set of variables that "appear free". So what does this have to do with regions? Well, we can apply the diff --git a/src/compiletest.md b/src/compiletest.md index cdcede33a..0837fb819 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -16,7 +16,7 @@ expect, and more. If you are unfamiliar with the compiler testing framework, see [this chapter](./tests/intro.html) for additional background. The tests themselves are typically (but not always) organized into -"suites"--for example, `run-pass`, a folder representing tests that should +"suites" – for example, `run-pass`, a folder representing tests that should succeed, `run-fail`, a folder holding tests that should compile successfully, but return a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various suites are defined in diff --git a/src/conventions.md b/src/conventions.md index 5b2b7b7f6..3f30dac73 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -44,8 +44,8 @@ current year if you like, but you don't have to. Lines should be at most 100 characters. It's even better if you can keep things to 80. -**Ignoring the line length limit.** Sometimes -- in particular for -tests -- it can be necessary to exempt yourself from this limit. In +**Ignoring the line length limit.** Sometimes – in particular for +tests – it can be necessary to exempt yourself from this limit. In that case, you can add a comment towards the top of the file (after the copyright notice) like so: @@ -141,7 +141,7 @@ command like `git rebase -i rust-lang/master` (presuming you use the name `rust-lang` for your remote). **Individual commits do not have to build (but it's nice).** We do not -require that every intermediate commit successfully builds -- we only +require that every intermediate commit successfully builds – we only expect to be able to bisect at a PR level. However, if you *can* make individual commits build, that is always helpful. diff --git a/src/incrcomp-debugging.md b/src/incrcomp-debugging.md index 2488aa320..ecb29d544 100644 --- a/src/incrcomp-debugging.md +++ b/src/incrcomp-debugging.md @@ -90,7 +90,7 @@ path that should not exist, but you will not be quite sure how it came to be. **When the compiler is built with debug assertions,** it can help you track that down. Simply set the `RUST_FORBID_DEP_GRAPH_EDGE` environment variable to a filter. Every edge created in the dep-graph -will be tested against that filter -- if it matches, a `bug!` is +will be tested against that filter – if it matches, a `bug!` is reported, so you can easily see the backtrace (`RUST_BACKTRACE=1`). The syntax for these filters is the same as described in the previous diff --git a/src/mir/borrowck.md b/src/mir/borrowck.md index cd83843f8..d5fea6184 100644 --- a/src/mir/borrowck.md +++ b/src/mir/borrowck.md @@ -1,6 +1,6 @@ # MIR borrow check -The borrow check is Rust's "secret sauce" -- it is tasked with +The borrow check is Rust's "secret sauce" – it is tasked with enforcing a number of properties: - That all variables are initialized before they are used. diff --git a/src/mir/index.md b/src/mir/index.md index 838048b81..ea72decdc 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -3,7 +3,7 @@ MIR is Rust's _Mid-level Intermediate Representation_. It is constructed from [HIR](./hir.html). MIR was introduced in [RFC 1211]. It is a radically simplified form of Rust that is used for -certain flow-sensitive safety checks -- notably the borrow checker! -- +certain flow-sensitive safety checks – notably the borrow checker! – and also for optimization and code generation. If you'd like a very high-level introduction to MIR, as well as some @@ -122,7 +122,7 @@ StorageLive(_1); ``` This statement indicates that the variable `_1` is "live", meaning -that it may be used later -- this will persist until we encounter a +that it may be used later – this will persist until we encounter a `StorageDead(_1)` statement, which indicates that the variable `_1` is done being used. These "storage statements" are used by LLVM to allocate stack space. @@ -134,7 +134,7 @@ _1 = const >::new() -> bb2; ``` Terminators are different from statements because they can have more -than one successor -- that is, control may flow to different +than one successor – that is, control may flow to different places. Function calls like the call to `Vec::new` are always terminators because of the possibility of unwinding, although in the case of `Vec::new` we are able to see that indeed unwinding is not @@ -163,7 +163,7 @@ Assignments in general have the form: = ``` -A place is an expression like `_3`, `_3.f` or `*_3` -- it denotes a +A place is an expression like `_3`, `_3.f` or `*_3` – it denotes a location in memory. An **Rvalue** is an expression that creates a value: in this case, the rvalue is a mutable borrow expression, which looks like `&mut `. So we can kind of define a grammar for @@ -180,7 +180,7 @@ rvalues like so: | move Place ``` -As you can see from this grammar, rvalues cannot be nested -- they can +As you can see from this grammar, rvalues cannot be nested – they can only reference places and constants. Moreover, when you use a place, we indicate whether we are **copying it** (which requires that the place have a type `T` where `T: Copy`) or **moving it** (which works diff --git a/src/mir/passes.md b/src/mir/passes.md index a5b5df10a..c48ef4576 100644 --- a/src/mir/passes.md +++ b/src/mir/passes.md @@ -100,8 +100,8 @@ that appeared within the `main` function.) ### Implementing and registering a pass -A `MirPass` is some bit of code that processes the MIR, typically -- -but not always -- transforming it along the way somehow. For example, +A `MirPass` is some bit of code that processes the MIR, typically – +but not always – transforming it along the way somehow. For example, it might perform an optimization. The `MirPass` trait itself is found in in [the `rustc_mir::transform` module][mirtransform], and it basically consists of one method, `run_pass`, that simply gets an @@ -110,7 +110,7 @@ came from). The MIR is therefore modified in place (which helps to keep things efficient). A good example of a basic MIR pass is [`NoLandingPads`], which walks -the MIR and removes all edges that are due to unwinding -- this is +the MIR and removes all edges that are due to unwinding – this is used when configured with `panic=abort`, which never unwinds. As you can see from its source, a MIR pass is defined by first defining a dummy type, a struct with no fields, something like: diff --git a/src/mir/regionck.md b/src/mir/regionck.md index 90f6fa274..9034af8a8 100644 --- a/src/mir/regionck.md +++ b/src/mir/regionck.md @@ -12,13 +12,13 @@ The MIR-based region analysis consists of two major functions: - `replace_regions_in_mir`, invoked first, has two jobs: - First, it finds the set of regions that appear within the signature of the function (e.g., `'a` in `fn foo<'a>(&'a u32) { - ... }`). These are called the "universal" or "free" regions -- in + ... }`). These are called the "universal" or "free" regions – in particular, they are the regions that [appear free][fvb] in the function body. - Second, it replaces all the regions from the function body with fresh inference variables. This is because (presently) those regions are the results of lexical region inference and hence are - not of much interest. The intention is that -- eventually -- they + not of much interest. The intention is that – eventually – they will be "erased regions" (i.e., no information at all), since we won't be doing lexical region inference at all. - `compute_regions`, invoked second: this is given as argument the @@ -40,11 +40,11 @@ The MIR-based region analysis consists of two major functions: ## Universal regions -*to be written* -- explain the `UniversalRegions` type +*to be written* – explain the `UniversalRegions` type ## Region variables and constraints -*to be written* -- describe the `RegionInferenceContext` and +*to be written* – describe the `RegionInferenceContext` and the role of `liveness_constraints` vs other `constraints`, plus ## Closures @@ -79,13 +79,13 @@ The kinds of region elements are as follows: - Similarly, there is an element denoted `end('static)` corresponding to the remainder of program execution after this function returns. - There is an element `!1` for each skolemized region `!1`. This - corresponds (intuitively) to some unknown set of other elements -- + corresponds (intuitively) to some unknown set of other elements – for details on skolemization, see the section [skolemization and universes](#skol). ## Causal tracking -*to be written* -- describe how we can extend the values of a variable +*to be written* – describe how we can extend the values of a variable with causal tracking etc @@ -133,7 +133,7 @@ bound in the supertype and **skolemizing** them: this means that we replace them with [universally quantified](appendix/background.html#quantified) representatives, written like `!1`. We call these regions "skolemized -regions" -- they represent, basically, "some unknown region". +regions" – they represent, basically, "some unknown region". Once we've done that replacement, we have the following relation: @@ -156,9 +156,9 @@ we swap the left and right here): ``` According to the basic subtyping rules for a reference, this will be -true if `'!1: 'static`. That is -- if "some unknown region `!1`" lives -outlives `'static`. Now, this *might* be true -- after all, `'!1` -could be `'static` -- but we don't *know* that it's true. So this +true if `'!1: 'static`. That is – if "some unknown region `!1`" lives +outlives `'static`. Now, this *might* be true – after all, `'!1` +could be `'static` – but we don't *know* that it's true. So this should yield up an error (eventually). ### What is a universe @@ -238,8 +238,8 @@ not U1. **Giving existential variables a universe.** Now that we have this notion of universes, we can use it to extend our type-checker and things to prevent illegal names from leaking out. The idea is that we -give each inference (existential) variable -- whether it be a type or -a lifetime -- a universe. That variable's value can then only +give each inference (existential) variable – whether it be a type or +a lifetime – a universe. That variable's value can then only reference names visible from that universe. So for example is a lifetime variable is created in U0, then it cannot be assigned a value of `!1` or `!2`, because those names are not visible from the universe @@ -247,7 +247,7 @@ U0. **Representing universes with just a counter.** You might be surprised to see that the compiler doesn't keep track of a full tree of -universes. Instead, it just keeps a counter -- and, to determine if +universes. Instead, it just keeps a counter – and, to determine if one universe can see another one, it just checks if the index is greater. For example, U2 can see U0 because 2 >= 0. But U0 cannot see U2, because 0 >= 2 is false. @@ -323,12 +323,12 @@ Now there are two ways that could happen. First, if `U(V1)` can see the universe `x` (i.e., `x <= U(V1)`), then we can just add `skol(x)` to `value(V1)` and be done. But if not, then we have to approximate: we may not know what set of elements `skol(x)` represents, but we -should be able to compute some sort of **upper bound** B for it -- +should be able to compute some sort of **upper bound** B for it – some region B that outlives `skol(x)`. For now, we'll just use -`'static` for that (since it outlives everything) -- in the future, we +`'static` for that (since it outlives everything) – in the future, we can sometimes be smarter here (and in fact we have code for doing this already in other contexts). Moreover, since `'static` is in the root -universe U0, we know that all variables can see it -- so basically if +universe U0, we know that all variables can see it – so basically if we find that `value(V2)` contains `skol(x)` for some universe `x` that `V1` can't see, then we force `V1` to `'static`. @@ -398,8 +398,8 @@ outlives relationships are satisfied. Then we would go to the "check universal regions" portion of the code, which would test that no universal region grew too large. -In this case, `V1` *did* grow too large -- it is not known to outlive -`end('static)`, nor any of the CFG -- so we would report an error. +In this case, `V1` *did* grow too large – it is not known to outlive +`end('static)`, nor any of the CFG – so we would report an error. ## Another example diff --git a/src/mir/visitor.md b/src/mir/visitor.md index 265769b34..ad00bc3f1 100644 --- a/src/mir/visitor.md +++ b/src/mir/visitor.md @@ -2,7 +2,7 @@ The MIR visitor is a convenient tool for traversing the MIR and either looking for things or making changes to it. The visitor traits are -defined in [the `rustc::mir::visit` module][m-v] -- there are two of +defined in [the `rustc::mir::visit` module][m-v] – there are two of them, generated via a single macro: `Visitor` (which operates on a `&Mir` and gives back shared references) and `MutVisitor` (which operates on a `&mut Mir` and gives back mutable references). diff --git a/src/query.md b/src/query.md index 7ed299b74..a0c0d6282 100644 --- a/src/query.md +++ b/src/query.md @@ -5,7 +5,7 @@ Rust compiler is current transitioning from a traditional "pass-based" setup to a "demand-driven" system. **The Compiler Query System is the key to our new demand-driven organization.** The idea is pretty simple. You have various queries that compute things about the input --- for example, there is a query called `type_of(def_id)` that, given +– for example, there is a query called `type_of(def_id)` that, given the def-id of some item, will compute the type of that item and return it to you. diff --git a/src/tests/adding.md b/src/tests/adding.md index fac13fcac..a9400c591 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -49,8 +49,8 @@ considered an ideal setup. [`src/test/run-pass`]: https://github.com/rust-lang/rust/tree/master/src/test/run-pass/ -For regression tests -- basically, some random snippet of code that -came in from the internet -- we often just name the test after the +For regression tests – basically, some random snippet of code that +came in from the internet – we often just name the test after the issue. For example, `src/test/run-pass/issue-12345.rs`. If possible, though, it is better if you can put the test into a directory that helps identify what piece of code is being tested here (e.g., @@ -267,9 +267,9 @@ can also make UI tests where compilation is expected to succeed, and you can even run the resulting program. Just add one of the following [header commands](#header_commands): -- `// compile-pass` -- compilation should succeed but do +- `// compile-pass` – compilation should succeed but do not run the resulting binary -- `// run-pass` -- compilation should succeed and we should run the +- `// run-pass` – compilation should succeed and we should run the resulting binary diff --git a/src/tests/intro.md b/src/tests/intro.md index bc84c9721..69d9ed057 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -15,7 +15,7 @@ on [how to run tests](./tests/running.html#ui) as well as The compiletest tests are located in the tree in the [`src/test`] directory. Immediately within you will see a series of subdirectories (e.g. `ui`, `run-make`, and so forth). Each of those directories is -called a **test suite** -- they house a group of tests that are run in +called a **test suite** – they house a group of tests that are run in a distinct mode. [`src/test`]: https://github.com/rust-lang/rust/tree/master/src/test @@ -24,31 +24,31 @@ Here is a brief summary of the test suites as of this writing and what they mean. In some cases, the test suites are linked to parts of the manual that give more details. -- [`ui`](./tests/adding.html#ui) -- tests that check the exact +- [`ui`](./tests/adding.html#ui) – tests that check the exact stdout/stderr from compilation and/or running the test -- `run-pass` -- tests that are expected to compile and execute +- `run-pass` – tests that are expected to compile and execute successfully (no panics) - - `run-pass-valgrind` -- tests that ought to run with valgrind -- `run-fail` -- tests that are expected to compile but then panic + - `run-pass-valgrind` – tests that ought to run with valgrind +- `run-fail` – tests that are expected to compile but then panic during execution -- `compile-fail` -- tests that are expected to fail compilation. -- `parse-fail` -- tests that are expected to fail to parse -- `pretty` -- tests targeting the Rust "pretty printer", which +- `compile-fail` – tests that are expected to fail compilation. +- `parse-fail` – tests that are expected to fail to parse +- `pretty` – tests targeting the Rust "pretty printer", which generates valid Rust code from the AST -- `debuginfo` -- tests that run in gdb or lldb and query the debug info -- `codegen` -- tests that compile and then test the generated LLVM +- `debuginfo` – tests that run in gdb or lldb and query the debug info +- `codegen` – tests that compile and then test the generated LLVM code to make sure that the optimizations we want are taking effect. -- `mir-opt` -- tests that check parts of the generated MIR to make +- `mir-opt` – tests that check parts of the generated MIR to make sure we are building things correctly or doing the optimizations we expect. -- `incremental` -- tests for incremental compilation, checking that +- `incremental` – tests for incremental compilation, checking that when certain modifications are performed, we are able to reuse the results from previous compilations. -- `run-make` -- tests that basically just execute a `Makefile`; the +- `run-make` – tests that basically just execute a `Makefile`; the ultimate in flexibility but quite annoying to write. -- `rustdoc` -- tests for rustdoc, making sure that the generated files +- `rustdoc` – tests for rustdoc, making sure that the generated files contain the expected documentation. -- `*-fulldeps` -- same as above, but indicates that the test depends +- `*-fulldeps` – same as above, but indicates that the test depends on things other than `libstd` (and hence those things must be built) ## Other Tests @@ -56,44 +56,44 @@ that give more details. The Rust build system handles running tests for various other things, including: -- **Tidy** -- This is a custom tool used for validating source code +- **Tidy** – This is a custom tool used for validating source code style and formatting conventions, such as rejecting long lines. There is more information in the [section on coding conventions](./conventions.html#formatting). Example: `./x.py test src/tools/tidy` -- **Unittests** -- The Rust standard library and many of the Rust packages +- **Unittests** – The Rust standard library and many of the Rust packages include typical Rust `#[test]` unittests. Under the hood, `x.py` will run `cargo test` on each package to run all the tests. Example: `./x.py test src/libstd` -- **Doctests** -- Example code embedded within Rust documentation is executed +- **Doctests** – Example code embedded within Rust documentation is executed via `rustdoc --test`. Examples: - `./x.py test src/doc` -- Runs `rustdoc --test` for all documentation in + `./x.py test src/doc` – Runs `rustdoc --test` for all documentation in `src/doc`. - `./x.py test --doc src/libstd` -- Runs `rustdoc --test` on the standard + `./x.py test --doc src/libstd` – Runs `rustdoc --test` on the standard library. -- **Linkchecker** -- A small tool for verifying `href` links within +- **Linkchecker** – A small tool for verifying `href` links within documentation. Example: `./x.py test src/tools/linkchecker` -- **Distcheck** -- This verifies that the source distribution tarball created +- **Distcheck** – This verifies that the source distribution tarball created by the build system will unpack, build, and run all tests. Example: `./x.py test distcheck` -- **Tool tests** -- Packages that are included with Rust have all of their +- **Tool tests** – Packages that are included with Rust have all of their tests run as well (typically by running `cargo test` within their directory). This includes things such as cargo, clippy, rustfmt, rls, miri, bootstrap (testing the Rust build system itself), etc. -- **Cargotest** -- This is a small tool which runs `cargo test` on a few +- **Cargotest** – This is a small tool which runs `cargo test` on a few significant projects (such as `servo`, `ripgrep`, `tokei`, etc.) just to ensure there aren't any significant regressions. diff --git a/src/tests/running.md b/src/tests/running.md index 03eb8ccc4..e55b6ec7d 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -1,7 +1,7 @@ # Running tests -You can run the tests using `x.py`. The most basic command -- which -you will almost never want to use! -- is as follows: +You can run the tests using `x.py`. The most basic command – which +you will almost never want to use! – is as follows: ```bash > ./x.py test diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md index ec20985ff..1972a70e6 100644 --- a/src/traits/associated-types.md +++ b/src/traits/associated-types.md @@ -15,7 +15,7 @@ When a trait defines an associated type (e.g., [the `Item` type in the `IntoIterator` trait][intoiter-item]), that type can be referenced by the user using an **associated type projection** like ` as IntoIterator>::Item`. (Often, -though, people will use the shorthand syntax `T::Item` -- presently, +though, people will use the shorthand syntax `T::Item` – presently, that syntax is expanded during ["type collection"](./type-checking.html) into the explicit form, though that is something we may want to change in the future.) @@ -24,8 +24,8 @@ though that is something we may want to change in the future.) -In some cases, associated type projections can be **normalized** -- -that is, simplified -- based on the types given in an impl. So, to +In some cases, associated type projections can be **normalized** – +that is, simplified – based on the types given in an impl. So, to continue with our example, the impl of `IntoIterator` for `Option` declares (among other things) that `Item = T`: @@ -39,9 +39,9 @@ impl IntoIterator for Option { This means we can normalize the projection ` as IntoIterator>::Item` to just `u32`. -In this case, the projection was a "monomorphic" one -- that is, it +In this case, the projection was a "monomorphic" one – that is, it did not have any type parameters. Monomorphic projections are special -because they can **always** be fully normalized -- but often we can +because they can **always** be fully normalized – but often we can normalize other associated type projections as well. For example, ` as IntoIterator>::Item` (where `?T` is an inference variable) can be normalized to just `?T`. diff --git a/src/traits/canonical-queries.md b/src/traits/canonical-queries.md index 56637dace..c58fe3696 100644 --- a/src/traits/canonical-queries.md +++ b/src/traits/canonical-queries.md @@ -1,8 +1,8 @@ # Canonical queries The "start" of the trait system is the **canonical query** (these are -both queries in the more general sense of the word -- something you -would like to know the answer to -- and in the +both queries in the more general sense of the word – something you +would like to know the answer to – and in the [rustc-specific sense](./query.html)). The idea is that the type checker or other parts of the system, may in the course of doing their thing want to know whether some trait is implemented for some type @@ -35,7 +35,7 @@ solver is finding **all possible** instantiations of your query that are true. In this case, if we instantiate `?U = [i32]`, then the query is true (note that a traditional Prolog interface does not, directly, tell us a value for `?U`, but we can infer one by unifying the -response with our original query -- Rust's solver gives back a +response with our original query – Rust's solver gives back a substitution instead). If we were to hit `y`, the solver might then give us another possible answer: @@ -135,7 +135,7 @@ we did find. It consists of four parts: [section on handling regions in traits](./traits/regions.html) for more details. - **Value:** The query result also comes with a value of type `T`. For - some specialized queries -- like normalizing associated types -- + some specialized queries – like normalizing associated types – this is used to carry back an extra result, but it's often just `()`. @@ -187,8 +187,8 @@ for example: Therefore, the result we get back would be as follows (I'm going to ignore region constraints and the "value"): -- Certainty: `Ambiguous` -- we're not sure yet if this holds -- Var values: `[?T = ?T, ?U = ?U]` -- we learned nothing about the values of +- Certainty: `Ambiguous` – we're not sure yet if this holds +- Var values: `[?T = ?T, ?U = ?U]` – we learned nothing about the values of the variables In short, the query result says that it is too soon to say much about diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md index f87de5f81..1ef1da717 100644 --- a/src/traits/canonicalization.md +++ b/src/traits/canonicalization.md @@ -24,7 +24,7 @@ form of `X` would be `(?0, ?1)`, where `?0` and `?1` represent these **canonical placeholders**. Note that the type `Y = (?U, ?T)` also canonicalizes to `(?0, ?1)`. But the type `Z = (?T, ?T)` would canonicalize to `(?0, ?0)` (as would `(?U, ?U)`). In other words, the -exact identity of the inference variables is not important -- unless +exact identity of the inference variables is not important – unless they are repeated. We use this to improve caching as well as to detect cycles and other diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index 5844e8d45..93bafe33f 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -197,7 +197,7 @@ Implemented(Foo: Send) :- As you can probably imagine, proving that `Option>: Send` is going to wind up circularly requiring us to prove that `Foo: Send` -again. So this would be an example where we wind up in a cycle -- but +again. So this would be an example where we wind up in a cycle – but that's ok, we *do* consider `Foo: Send` to hold, even though it references itself. @@ -219,4 +219,4 @@ as described in the section on [implied bounds]. Some topics yet to be written: - Elaborate on the proof procedure -- SLG solving -- introduce negative reasoning +- SLG solving – introduce negative reasoning diff --git a/src/traits/index.md b/src/traits/index.md index 2dabd0b69..c070d1b88 100644 --- a/src/traits/index.md +++ b/src/traits/index.md @@ -28,7 +28,7 @@ Trait solving is based around a few key ideas: whether types are equal. - [Region constraints](./traits/regions.html), which are accumulated during trait solving but mostly ignored. This means that trait - solving effectively ignores the precise regions involved, always -- + solving effectively ignores the precise regions involved, always – but we still remember the constraints on them so that those constraints can be checked by thet type checker. diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md index 205e9a171..030e19860 100644 --- a/src/traits/lowering-module.md +++ b/src/traits/lowering-module.md @@ -8,8 +8,8 @@ created in the [`rustc_traits::lowering`][lowering] module. ## The `program_clauses_for` query -The main entry point is the `program_clauses_for` [query], which -- -given a def-id -- produces a set of Chalk program clauses. These +The main entry point is the `program_clauses_for` [query], which – +given a def-id – produces a set of Chalk program clauses. These queries are tested using a [dedicated unit-testing mechanism, described below](#unit-tests). The query is invoked on a `DefId` that identifies something like a trait, diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index d8b739890..e37999e57 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -52,11 +52,11 @@ from the Rust syntax into goals. In addition, in the rules below, we sometimes do some transformations on the lowered where clauses, as defined here: -- `FromEnv(WC)` -- this indicates that: +- `FromEnv(WC)` – this indicates that: - `Implemented(TraitRef)` becomes `FromEnv(TraitRef)` - `ProjectionEq(Projection = Ty)` becomes `FromEnv(Projection = Ty)` - other where-clauses are left intact -- `WellFormed(WC)` -- this indicates that: +- `WellFormed(WC)` – this indicates that: - `Implemented(TraitRef)` becomes `WellFormed(TraitRef)` - `ProjectionEq(Projection = Ty)` becomes `WellFormed(Projection = Ty)` @@ -121,8 +121,8 @@ trait Eq: PartialEq { ... } In this case, the `PartialEq` supertrait is equivalent to a `where Self: PartialEq` where clause, in our simplified model. The program -clause above therefore states that if we can prove `FromEnv(T: Eq)` -- -e.g., if we are in some function with `T: Eq` in its where clauses -- +clause above therefore states that if we can prove `FromEnv(T: Eq)` – +e.g., if we are in some function with `T: Eq` in its where clauses – then we also know that `FromEnv(T: PartialEq)`. Thus the set of things that follow from the environment are not only the **direct where clauses** but also things that follow from them. @@ -169,7 +169,7 @@ have to prove each one of those: - `WellFormed(T: Foo)` -- cycle, true coinductively This `WellFormed` predicate is only used when proving that impls are -well-formed -- basically, for each impl of some trait ref `TraitRef`, +well-formed – basically, for each impl of some trait ref `TraitRef`, we must show that `WellFormed(TraitRef)`. This in turn justifies the implied bounds rules that allow us to extend the set of `FromEnv` items. diff --git a/src/traits/lowering-to-logic.md b/src/traits/lowering-to-logic.md index 2de28ce4e..cf8c1c25a 100644 --- a/src/traits/lowering-to-logic.md +++ b/src/traits/lowering-to-logic.md @@ -15,8 +15,8 @@ One of the first observations is that the Rust trait system is basically a kind of logic. As such, we can map our struct, trait, and impl declarations into logical inference rules. For the most part, these are basically Horn clauses, though we'll see that to capture the -full richness of Rust -- and in particular to support generic -programming -- we have to go a bit further than standard Horn clauses. +full richness of Rust – and in particular to support generic +programming – we have to go a bit further than standard Horn clauses. To see how this mapping works, let's start with an example. Imagine we declare a trait and a few impls, like so: @@ -38,8 +38,8 @@ Clone(Vec) :- Clone(?T). // Or, put another way, B implies A. ``` -In Prolog terms, we might say that `Clone(Foo)` -- where `Foo` is some -Rust type -- is a *predicate* that represents the idea that the type +In Prolog terms, we might say that `Clone(Foo)` – where `Foo` is some +Rust type – is a *predicate* that represents the idea that the type `Foo` implements `Clone`. These rules are **program clauses**; they state the conditions under which that predicate can be proven (i.e., considered true). So the first rule just says "Clone is implemented @@ -162,7 +162,7 @@ notation but a bit Rustified. Anyway, the problem is that standard Horn clauses don't allow universal quantification (`forall`) or implication (`if`) in goals (though many Prolog engines do support them, as an extension). For this reason, we need to accept something -called "first-order hereditary harrop" (FOHH) clauses -- this long +called "first-order hereditary harrop" (FOHH) clauses – this long name basically means "standard Horn clauses with `forall` and `if` in the body". But it's nice to know the proper name, because there is a lot of work describing how to efficiently handle FOHH clauses; see for diff --git a/src/type-checking.md b/src/type-checking.md index 9a161abd2..d4f4bf110 100644 --- a/src/type-checking.md +++ b/src/type-checking.md @@ -12,7 +12,7 @@ draws heavily on the [type inference] and [trait solving].) Type "collection" is the process of converting the types found in the HIR (`hir::Ty`), which represent the syntactic things that the user wrote, into the -**internal representation** used by the compiler (`Ty<'tcx>`) -- we also do +**internal representation** used by the compiler (`Ty<'tcx>`) – we also do similar conversions for where-clauses and other bits of the function signature. To try and get a sense for the difference, consider this function: @@ -30,7 +30,7 @@ they encode the path somewhat differently. But once they are "collected" into Collection is defined as a bundle of [queries] for computing information about the various functions, traits, and other items in the crate being compiled. -Note that each of these queries is concerned with *interprocedural* things -- +Note that each of these queries is concerned with *interprocedural* things – for example, for a function definition, collection will figure out the type and signature of the function, but it will not visit the *body* of the function in any way, nor examine type annotations on local variables (that's the job of diff --git a/src/variance.md b/src/variance.md index 05a286c07..9fe98b4a1 100644 --- a/src/variance.md +++ b/src/variance.md @@ -167,7 +167,7 @@ one could interpret variance and trait matching. Just as with structs and enums, we can decide the subtyping relationship between two object types `&Trait` and `&Trait` based on the relationship of `A` and `B`. Note that for object -types we ignore the `Self` type parameter -- it is unknown, and +types we ignore the `Self` type parameter – it is unknown, and the nature of dynamic dispatch ensures that we will always call a function that is expected the appropriate `Self` type. However, we must be careful with the other type parameters, or else we could @@ -274,8 +274,8 @@ These conditions are satisfied and so we are happy. ### Variance and associated types -Traits with associated types -- or at minimum projection -expressions -- must be invariant with respect to all of their +Traits with associated types – or at minimum projection +expressions – must be invariant with respect to all of their inputs. To see why this makes sense, consider what subtyping for a trait reference means: From 337c64e4d2d7f7ccb7c817e28d3d5d47e8d99442 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 20:24:09 -0500 Subject: [PATCH 0285/1812] fix lacking spaces --- src/tests/intro.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index 69d9ed057..bfe084618 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -63,13 +63,13 @@ including: Example: `./x.py test src/tools/tidy` -- **Unittests** – The Rust standard library and many of the Rust packages +- **Unit tests** – The Rust standard library and many of the Rust packages include typical Rust `#[test]` unittests. Under the hood, `x.py` will run `cargo test` on each package to run all the tests. Example: `./x.py test src/libstd` -- **Doctests** – Example code embedded within Rust documentation is executed +- **Doc tests** – Example code embedded within Rust documentation is executed via `rustdoc --test`. Examples: `./x.py test src/doc` – Runs `rustdoc --test` for all documentation in @@ -78,12 +78,12 @@ including: `./x.py test --doc src/libstd` – Runs `rustdoc --test` on the standard library. -- **Linkchecker** – A small tool for verifying `href` links within +- **Link checker** – A small tool for verifying `href` links within documentation. Example: `./x.py test src/tools/linkchecker` -- **Distcheck** – This verifies that the source distribution tarball created +- **Dist check** – This verifies that the source distribution tarball created by the build system will unpack, build, and run all tests. Example: `./x.py test distcheck` @@ -93,7 +93,7 @@ including: directory). This includes things such as cargo, clippy, rustfmt, rls, miri, bootstrap (testing the Rust build system itself), etc. -- **Cargotest** – This is a small tool which runs `cargo test` on a few +- **Cargo test** – This is a small tool which runs `cargo test` on a few significant projects (such as `servo`, `ripgrep`, `tokei`, etc.) just to ensure there aren't any significant regressions. From bdcd161d200b8f2103dad541850597c0b4e2ae06 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 18:44:04 -0500 Subject: [PATCH 0286/1812] define FileMap; fix #35 --- src/appendix/code-index.md | 5 +++-- src/the-parser.md | 9 +++++---- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index ef7853fc6..d47cde8cd 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -9,12 +9,13 @@ Item | Kind | Short description | Chapter | `BodyId` | struct | One of four types of HIR node identifiers. | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html) `CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser] | [src/libsyntax/codemap.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html) `CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html) +`ast::Crate` | struct | Syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) +`hir::Crate` | struct | More abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) `DefId` | struct | One of four types of HIR node identifiers. | [Identifiers in the HIR] | [src/librustc/hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html) `DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) -`ast::Crate` | struct | Syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) +`FileMap` | struct | A single source within a `CodeMap` (e.g. the source code within a single file). | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.FileMap.html) `HirId` | struct | One of four types of HIR node identifiers. | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html) -`hir::Crate` | struct | More abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) `NodeId` | struct | One of four types of HIR node identifiers. Being phased out. | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) diff --git a/src/the-parser.md b/src/the-parser.md index dd451d24f..e89c09e9e 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -22,10 +22,10 @@ The `syntax` crate contains several main players, - and a [visit module] for walking the AST and inspecting or mutating the AST nodes. -The main entrypoint to the parser is via the various `parse_*` functions -in the [parser module]. They let you do things like turn a filemap into a -token stream, create a parser from the token stream, and then execute the -parser to get a `Crate` (the root AST node). +The main entrypoint to the parser is via the various `parse_*` functions in the +[parser module]. They let you do things like turn a [`FileMap`][filemap] (e.g. +the source in a single file) into a token stream, create a parser from the +token stream, and then execute the parser to get a `Crate` (the root AST node). To minimise the amount of copying that is done, both the `StringReader` and `Parser` have lifetimes which bind them to the parent `ParseSess`. This contains @@ -40,3 +40,4 @@ all the information needed while parsing, as well as the `CodeMap` itself. [`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/parser/struct.Parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html [visit module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/visit/index.html +[filemap]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.FileMap.html From d234211ca1904c1468601c9a547a0f80b8f29288 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 20:29:58 -0500 Subject: [PATCH 0287/1812] Attempt to address review comments --- src/appendix/code-index.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index d47cde8cd..1dbbec646 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -6,17 +6,17 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- -`BodyId` | struct | One of four types of HIR node identifiers. | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html) +`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html) `CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser] | [src/libsyntax/codemap.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html) `CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html) -`ast::Crate` | struct | Syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) -`hir::Crate` | struct | More abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) -`DefId` | struct | One of four types of HIR node identifiers. | [Identifiers in the HIR] | [src/librustc/hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html) +`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) +`hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) +`DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html) `DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) -`FileMap` | struct | A single source within a `CodeMap` (e.g. the source code within a single file). | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.FileMap.html) -`HirId` | struct | One of four types of HIR node identifiers. | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html) -`NodeId` | struct | One of four types of HIR node identifiers. Being phased out. | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) +`FileMap` | struct | Part of the `CodeMap`, mapping a single source file | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.FileMap.html) +`HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html) +`NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Rib.html) @@ -27,7 +27,7 @@ Item | Kind | Short description | Chapter | `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) -`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries. | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) +`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) [The HIR]: hir.html [Identifiers in the HIR]: hir.html#hir-id From 1a696569a846692c171549537b4726e9fd9fe238 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 10 Jul 2018 20:52:47 -0500 Subject: [PATCH 0288/1812] update definitions --- src/appendix/code-index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 1dbbec646..b6986c5c0 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -7,14 +7,14 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- `BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html) -`CodeMap` | struct | The CodeMap maps the AST nodes to their source code | [The parser] | [src/libsyntax/codemap.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html) +`CodeMap` | struct | Maps AST nodes to their source code. It is composed of `FileMap`s | [The parser] | [src/libsyntax/codemap.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html) `CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html) `ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) `hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) `DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html) `DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) -`FileMap` | struct | Part of the `CodeMap`, mapping a single source file | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.FileMap.html) +`FileMap` | struct | Part of the `CodeMap`. Maps AST nodes to their source code for a single source file | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.FileMap.html) `HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html) `NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) From 315ae44507f5a2691083be9f40b28945cffa7762 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 14 Jul 2018 15:58:17 -0500 Subject: [PATCH 0289/1812] add a bit about buffered lints --- src/diag.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/src/diag.md b/src/diag.md index 67bd4829c..3690d6152 100644 --- a/src/diag.md +++ b/src/diag.md @@ -268,3 +268,41 @@ For example, This defines the `nonstandard_style` group which turns on the listed lints. A user can turn on these lints with a `!#[warn(nonstandard_style)]` attribute in the source code, or by passing `-W nonstandard-style` on the command line. + +### Linting early in the compiler + +On occasion, you may need to define a lint that runs before the linting system +has been initialized (e.g. during parsing or macro expansion). This is +problematic because we need to have computed lint levels to know whether we +should emit a warning or an error or nothing at all. + +To solve this problem, we buffer the lints until the linting system is +processed. [`Session`][sessbl] and [`ParseSess`][parsebl] both have +`buffer_lint` methods that allow you to buffer a lint for later. The linting +system automatically takes care of handling buffered lints later. + +[sessbl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html#method.buffer_lint +[parsebl]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html#method.buffer_lint + +Thus, to define a lint that runs early in the compilation, one defines a lint +like normal but invokes the lint with `buffer_lint`. + +#### Linting even earlier in the compiler + +The parser (`libsyntax`) is interesting in that it cannot have dependencies on +any of the other `librustc*` crates. In particular, it cannot depend on +`librustc::lint` or `librustc_lint`, where all of the compiler linting +infrastructure is defined. That's troublesome! + +To solve this, `libsyntax` defines its own buffered lint type, which +`ParseSess::buffer_lint` uses. After macro expansion, these buffered lints are +then dumped into the `Session::buffered_lints` used by the rest of the compiler. + +Usage for buffered lints in `libsyntax` is pretty much the same as the rest of +the compiler with one exception because we cannot import the `LintId`s for +lints we want to emit. Instead, the [`BufferedEarlyLintId`] type is used. If you +are defining a new lint, you will want to add an entry to this enum. Then, add +an appropriate mapping to the body of [`Lint::from_parser_lint_id`][fplid]. + +[`BufferedEarlyLintId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/early_buffered_lints/struct.BufferedEarlyLintId.html +[fplid]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.Lint.html#from_parser_lint_id From 57c8403c88fd40053ba4dadc4ec213748786e527 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 18:28:51 -0500 Subject: [PATCH 0290/1812] add a bit on llvm --- src/codegen.md | 49 ++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/src/codegen.md b/src/codegen.md index f5894baa7..279875995 100644 --- a/src/codegen.md +++ b/src/codegen.md @@ -1 +1,48 @@ -# Generating LLVM IR +# Code generation + +Code generation or "codegen" is the part of the compiler that actually generates +an executable binary. rustc uses LLVM for code generation. + +## What is LLVM? + +All of the preceeding chapters of this guide have one thing in common: we never +generated any executable machine code at all! With this chapter, all of that +changes. + +Like most compilers, rustc is composed of a "frontend" and a "backend". The +"frontend" is responsible for taking raw source code, checking it for +correctness, and getting it into a format `X` from which we can generate +executable machine code. The "backend" then takes that format `X` and produces +(possibly optimized) executable machine code for some platform. All of the +previous chapters deal with rustc's frontend. + +rustc's backend is [LLVM](https://llvm.org), "a collection of modular and +reusable compiler and toolchain technologies". In particular, the LLVM project +contains a pluggable compiler backend (also called "LLVM"), which is used by +many compiler projects, including the `clang` C compiler and our beloved +`rustc`. + +LLVM's "format `X`" is called LLVM IR. It is basically assembly code with +additional low-level types and annotations added. These annotations are helpful +for doing optimizations on the LLVM IR and outputed machine code. The end result +of all this is (at long last) something executable (e.g. an ELF object or wasm). + +There are a few benefits to using LLVM: + +- We don't have to write a whole compiler backend. This reduces implementation + and maintainance burden. +- We benefit from the large suite of advanced optimizations that the LLVM + project has been collecting. +- We automatically can compile Rust to any of the platforms for which LLVM has + support. For example, as soon as LLVM added support for wasm, voila! rustc, + clang, and a bunch of other languages were able to compile to wasm! (Well, + there was some extra stuff to be done, but we were 90% there anyway). +- We and other compiler projects benefit from each other. For example, when the + [Spectre and Meltdown security vulnerabilities][spectre] were discovered, only LLVM + needed to be patched. + +[spectre]: https://meltdownattack.com/ + +## Generating LLVM IR + +TODO From 894893860dd717d6e81b900c6f196f6c1670098b Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 8 Jul 2018 18:31:56 -0500 Subject: [PATCH 0291/1812] line length --- src/codegen.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/codegen.md b/src/codegen.md index 279875995..cb99e4d38 100644 --- a/src/codegen.md +++ b/src/codegen.md @@ -1,7 +1,7 @@ # Code generation -Code generation or "codegen" is the part of the compiler that actually generates -an executable binary. rustc uses LLVM for code generation. +Code generation or "codegen" is the part of the compiler that actually +generates an executable binary. rustc uses LLVM for code generation. ## What is LLVM? @@ -24,8 +24,9 @@ many compiler projects, including the `clang` C compiler and our beloved LLVM's "format `X`" is called LLVM IR. It is basically assembly code with additional low-level types and annotations added. These annotations are helpful -for doing optimizations on the LLVM IR and outputed machine code. The end result -of all this is (at long last) something executable (e.g. an ELF object or wasm). +for doing optimizations on the LLVM IR and outputed machine code. The end +result of all this is (at long last) something executable (e.g. an ELF object +or wasm). There are a few benefits to using LLVM: @@ -38,8 +39,8 @@ There are a few benefits to using LLVM: clang, and a bunch of other languages were able to compile to wasm! (Well, there was some extra stuff to be done, but we were 90% there anyway). - We and other compiler projects benefit from each other. For example, when the - [Spectre and Meltdown security vulnerabilities][spectre] were discovered, only LLVM - needed to be patched. + [Spectre and Meltdown security vulnerabilities][spectre] were discovered, + only LLVM needed to be patched. [spectre]: https://meltdownattack.com/ From e0d07aad5f6af37df34816fa7f4da057fa5d2bef Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 15 Jul 2018 18:49:03 -0500 Subject: [PATCH 0292/1812] add notes about generating llvm ir --- src/compiler-debugging.md | 170 ++++++++++++++++++++++++++------------ 1 file changed, 117 insertions(+), 53 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index c8fb6dd08..d1171e0e0 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -1,4 +1,4 @@ -**Note: This is copied from the +**Note: This is copied from the [rust-forge](https://github.com/rust-lang-nursery/rust-forge). If anything needs updating, please open an issue or make a PR on the github repo.** @@ -16,7 +16,7 @@ normal Rust programs. IIRC backtraces **don't work** on Mac and on MinGW, sorry. If you have trouble or the backtraces are full of `unknown`, you might want to find some way to use Linux or MSVC on Windows. -In the default configuration, you don't have line numbers enabled, so the +In the default configuration, you don't have line numbers enabled, so the backtrace looks like this: ```text @@ -36,8 +36,8 @@ stack backtrace: 37: rustc_driver::run_compiler ``` -If you want line numbers for the stack trace, you can enable -`debuginfo-lines=true` or `debuginfo=true` in your config.toml and rebuild the +If you want line numbers for the stack trace, you can enable +`debuginfo-lines=true` or `debuginfo=true` in your config.toml and rebuild the compiler. Then the backtrace will look like this: ```text @@ -110,16 +110,16 @@ note: rustc 1.24.0-dev running on x86_64-unknown-linux-gnu note: run with `RUST_BACKTRACE=1` for a backtrace -thread 'rustc' panicked at 'encountered error with `-Z treat_err_as_bug', +thread 'rustc' panicked at 'encountered error with `-Z treat_err_as_bug', /home/user/rust/src/librustc_errors/lib.rs:411:12 -note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose +note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. stack backtrace: (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) - 7: rustc::traits::error_reporting::>::report_selection_error at /home/user/rust/src/librustc/traits/error_reporting.rs:823 - 8: rustc::traits::error_reporting::>::report_fulfillment_errors at /home/user/rust/src/librustc/traits/error_reporting.rs:160 at /home/user/rust/src/librustc/traits/error_reporting.rs:112 @@ -136,7 +136,7 @@ $ # Cool, now I have a backtrace for the error The compiler has a lot of `debug!` calls, which print out logging information at many points. These are very useful to at least narrow down the location of -a bug if not to find it entirely, or just to orient yourself as to why the +a bug if not to find it entirely, or just to orient yourself as to why the compiler is doing a particular thing. To see the logs, you need to set the `RUST_LOG` environment variable to @@ -191,9 +191,9 @@ want to call `x.py clean` to force one. ### Logging etiquette Because calls to `debug!` are removed by default, in most cases, don't worry -about adding "unnecessary" calls to `debug!` and leaving them in code you -commit - they won't slow down the performance of what we ship, and if they -helped you pinning down a bug, they will probably help someone else with a +about adding "unnecessary" calls to `debug!` and leaving them in code you +commit - they won't slow down the performance of what we ship, and if they +helped you pinning down a bug, they will probably help someone else with a different one. However, there are still a few concerns that you might care about: @@ -201,27 +201,27 @@ However, there are still a few concerns that you might care about: ### Expensive operations in logs A note of caution: the expressions *within* the `debug!` call are run -whenever RUST_LOG is set, even if the filter would exclude the log. This means +whenever RUST_LOG is set, even if the filter would exclude the log. This means that if in the module `rustc::foo` you have a statement ```Rust debug!("{:?}", random_operation(tcx)); ``` -Then if someone runs a debug `rustc` with `RUST_LOG=rustc::bar`, then -`random_operation()` will still run - even while it's output will never be +Then if someone runs a debug `rustc` with `RUST_LOG=rustc::bar`, then +`random_operation()` will still run - even while it's output will never be needed! This means that you should not put anything too expensive or likely -to crash there - that would annoy anyone who wants to use logging for their own -module. Note that if `RUST_LOG` is unset (the default), then the code will not -run - this means that if your logging code panics, then no-one will know it +to crash there - that would annoy anyone who wants to use logging for their own +module. Note that if `RUST_LOG` is unset (the default), then the code will not +run - this means that if your logging code panics, then no-one will know it until someone tries to use logging to find *another* bug. -If you *need* to do an expensive operation in a log, be aware that while log -expressions are *evaluated* even if logging is not enabled in your module, -they are not *formatted* unless it *is*. This means you can put your -expensive/crashy operations inside an `fmt::Debug` impl, and they will not be +If you *need* to do an expensive operation in a log, be aware that while log +expressions are *evaluated* even if logging is not enabled in your module, +they are not *formatted* unless it *is*. This means you can put your +expensive/crashy operations inside an `fmt::Debug` impl, and they will not be run unless your log is enabled: ```Rust @@ -246,7 +246,7 @@ debug!("{:?}", ExpensiveOperationContainer { tcx }); ## Formatting Graphviz output (.dot files) [formatting-graphviz-output]: #formatting-graphviz-output -Some compiler options for debugging specific features yield graphviz graphs - +Some compiler options for debugging specific features yield graphviz graphs - e.g. the `#[rustc_mir(borrowck_graphviz_postflow="suffix.dot")]` attribute dumps various borrow-checker dataflow graphs. @@ -261,30 +261,66 @@ $ firefox maybe_init_suffix.pdf # Or your favorite pdf viewer ## Debugging LLVM [debugging-llvm]: #debugging-llvm -LLVM is a big project on its own that probably needs to have its own debugging -document (not that I could find one). But here are some tips that are important -in a rustc context: +> NOTE: If you are looking for info about code generation, please see [this +> chapter][codegen] instead. + +[codegen]: codegen.html + +This section is about debugging compiler bugs in code generation (e.g. why the +compiler generated some piece of code or crashed in LLVM). LLVM is a big +project on its own that probably needs to have its own debugging document (not +that I could find one). But here are some tips that are important in a rustc +context: + +As a general rule, compilers generate lots of information from analyzing code. +Thus, a useful first step is usually to find a minimal example. One way to do +this is to + +1. create a new crate that reproduces the issue (e.g. adding whatever crate is +at fault as a dependency, and using it from there) + +2. minimize the crate by removing external dependencies; that is, moving +everything relevant to the new crate + +3. further minimize the issue by making the code shorter (there are tools that +help with this like `creduce`) The official compilers (including nightlies) have LLVM assertions disabled, which means that LLVM assertion failures can show up as compiler crashes (not ICEs but "real" crashes) and other sorts of weird behavior. If you are encountering these, it is a good idea to try using a compiler with LLVM assertions enabled - either an "alt" nightly or a compiler you build yourself -by setting `[llvm] assertions=true` in your config.toml - and -see whether anything turns up. +by setting `[llvm] assertions=true` in your config.toml - and see whether +anything turns up. -The rustc build process builds the LLVM tools into +The rustc build process builds the LLVM tools into `./build//llvm/bin`. They can be called directly. -The default rustc compilation pipeline has multiple codegen units, which is hard -to replicate manually and means that LLVM is called multiple times in parallel. -If you can get away with it (i.e. if it doesn't make your bug disappear), -passing `-C codegen-units=1` to rustc will make debugging easier. - -If you want to play with the optimization pipeline, you can use the opt tool -from `./build//llvm/bin/` with the the LLVM IR emitted by rustc. -Note that rustc emits different IR depending on whether `-O` is enabled, even -without LLVM's optimizations, so if you want to play with the IR rustc emits, +The default rustc compilation pipeline has multiple codegen units, which is +hard to replicate manually and means that LLVM is called multiple times in +parallel. If you can get away with it (i.e. if it doesn't make your bug +disappear), passing `-C codegen-units=1` to rustc will make debugging easier. + +To rustc to generate LLVM IR, you need to pass the `--emit=llvm-ir` flag. If +you are building via cargo, use the `RUSTFLAGS` environment variable (e.g. +`RUSTFLAGS='--emit=llvm-ir'`). This causes rustc to spit out LLVM IR into the +target directory. + +`cargo llvm-ir [options] path` spits out the LLVM IR for a particular function +at `path`. (`cargo install cargo-asm` installs `cargo asm` and `cargo +llvm-ir`). `--build-type=debug` emits code for debug builds. There are also +other useful options. Also, debug info in LLVM IR can clutter the output a lot: +`RUSTFLAGS="-C debuginfo=0"` is really useful. + +`RUSTFLAGS="-C save-temps"` outputs LLVM bitcode (not the same as IR) at +different stages during compilation, which is sometimes useful. One just needs +to convert the bitcode files to `.ll` files using `llvm-dis` which should be in +the target local compilation of rustc. + +If you want to play with the optimization pipeline, you can use the `opt` tool +from `./build//llvm/bin/` with the LLVM IR emitted by rustc. Note +that rustc emits different IR depending on whether `-O` is enabled, even +without LLVM's optimizations, so if you want to play with the IR rustc emits, you should: ```bash @@ -295,21 +331,21 @@ $ $OPT -S -O2 < my-file.ll > my ``` If you just want to get the LLVM IR during the LLVM pipeline, to e.g. see which -IR causes an optimization-time assertion to fail, or to see when -LLVM performs a particular optimization, you can pass the rustc flag -`-C llvm-args=-print-after-all`, and possibly add -`-C llvm-args='-filter-print-funcs=EXACT_FUNCTION_NAME` (e.g. -`-C llvm-args='-filter-print-funcs=_ZN11collections3str21_$LT$impl$u20$str$GT$\ - 7replace17hbe10ea2e7c809b0bE'`). - -That produces a lot of output into standard error, so you'll want to pipe -that to some file. Also, if you are using neither `-filter-print-funcs` nor -`-C codegen-units=1`, then, because the multiple codegen units run in parallel, -the printouts will mix together and you won't be able to read anything. - -If you want just the IR for a specific function (say, you want to see -why it causes an assertion or doesn't optimize correctly), you can use -`llvm-extract`, e.g. +IR causes an optimization-time assertion to fail, or to see when LLVM performs +a particular optimization, you can pass the rustc flag `-C +llvm-args=-print-after-all`, and possibly add `-C +llvm-args='-filter-print-funcs=EXACT_FUNCTION_NAME` (e.g. `-C +llvm-args='-filter-print-funcs=_ZN11collections3str21_$LT$impl$u20$str$GT$\ +7replace17hbe10ea2e7c809b0bE'`). + +That produces a lot of output into standard error, so you'll want to pipe that +to some file. Also, if you are using neither `-filter-print-funcs` nor `-C +codegen-units=1`, then, because the multiple codegen units run in parallel, the +printouts will mix together and you won't be able to read anything. + +If you want just the IR for a specific function (say, you want to see why it +causes an assertion or doesn't optimize correctly), you can use `llvm-extract`, +e.g. ```bash $ ./build/$TRIPLE/llvm/bin/llvm-extract \ @@ -319,4 +355,32 @@ $ ./build/$TRIPLE/llvm/bin/llvm-extract \ > extracted.ll ``` +### Filing LLVM bug reports + +When filing an LLVM bug report, you will probably want some sort of minimal +working example that demonstrates the problem. The Godbolt compiler explorer is +really helpful for this. + +1. Once you have some LLVM IR for the problematic code (see above), you can +create a minimal working example with Godbolt. Go to +[gcc.godbolt.org](https://gcc.godbolt.org). + +2. Choose `LLVM-IR` as programming language. + +3. Use `llc` to compile the IR to a particular target as is: + - There are some useful flags: `-mattr` enables target features, `-march=` + selects the target, `-mcpu=` selects the CPU, etc. + - Commands like `llc -march=help` output all architectures available, which + is useful because sometimes the Rust arch names and the LLVM names do not + match. + - If you have compiled rustc yourself somewhere, in the target directory + you have binaries for `llc`, `opt`, etc. + +4. If you want to optimize the LLVM-IR, you can use `opt` to see how the LLVM + optimizations transform it. + +5. Once you have a godbolt link demonstrating the issue, it is pretty easy to + fill in an LLVM bug. + + [env-logger]: https://docs.rs/env_logger/0.4.3/env_logger/ From 2a1387faae2ec30e5261f0afe7c5474fb462a6fb Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 15 Jul 2018 18:51:41 -0500 Subject: [PATCH 0293/1812] minor improvements --- src/SUMMARY.md | 2 +- src/codegen.md | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a41f78a1a..206bf5d36 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -54,7 +54,7 @@ - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) -- [Generating LLVM IR](./codegen.md) +- [Code Generation](./codegen.md) - [Emitting Diagnostics](./diag.md) --- diff --git a/src/codegen.md b/src/codegen.md index cb99e4d38..6e68db6ea 100644 --- a/src/codegen.md +++ b/src/codegen.md @@ -3,6 +3,11 @@ Code generation or "codegen" is the part of the compiler that actually generates an executable binary. rustc uses LLVM for code generation. +> NOTE: If you are looking for hints on how to debug code generation bugs, +> please see [this section of the debugging chapter][debug]. + +[debug]: compiler-debugging.html#debugging-llvm + ## What is LLVM? All of the preceeding chapters of this guide have one thing in common: we never From 37141c0825b130cf30524d40a8cea20097fb64a4 Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Thu, 9 Aug 2018 09:05:36 -0600 Subject: [PATCH 0294/1812] Update compiler test documentation Update the compiler test documentation to document ignore-gdb-version and min-system-llvm-version; and expand the min-gdb-version, min-lldb-version, and min-llvm-version documentation a little. --- src/tests/adding.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index a9400c591..7469755f7 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -129,6 +129,8 @@ be compiled or run. * `ignore-test` always ignores the test * `ignore-lldb` and `ignore-gdb` will skip a debuginfo test on that debugger. +* `ignore-gdb-version` can be used to ignore the test when certain gdb + versions are used Some examples of `X` in `ignore-X`: @@ -157,8 +159,16 @@ source. source is compiled, and this compilation is required to succeed. The `.fixed` file can also be generated automatically with the `--bless` option, discussed [below](#bless). -* `min-{gdb,lldb}-version` -* `min-llvm-version` +* `min-gdb-version` specifies the minimum gdb version required for + this test; see also `ignore-gdb-version` +* `min-lldb-version` specifies the minimum lldb version required for + this test +* `min-llvm-version` specifies the minimum llvm version required for + this test +* `min-system-llvm-version` specifies the minimum system llvm version + required for this test; the test is ignored if the system llvm is in + use and it doesn't meet the minimum version. This is useful when an + llvm feature has been backported to rust-llvm * `compile-pass` for UI tests, indicates that the test is supposed to compile, as opposed to the default where the test is supposed to error out. From c13c5a019faab37ee03b259688bf89e73a2ce4d9 Mon Sep 17 00:00:00 2001 From: John Renner Date: Tue, 24 Jul 2018 08:58:25 -0700 Subject: [PATCH 0295/1812] Add testing chapter --- src/SUMMARY.md | 1 + src/testing.md | 145 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 146 insertions(+) create mode 100644 src/testing.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 206bf5d36..27a6e38f2 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -17,6 +17,7 @@ - [Incremental compilation](./incremental-compilation.md) - [Debugging and Testing](./incrcomp-debugging.md) - [The parser](./the-parser.md) +- [Testing](./testing.md) - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) - [The HIR (High-level IR)](./hir.md) diff --git a/src/testing.md b/src/testing.md new file mode 100644 index 000000000..abe6849a7 --- /dev/null +++ b/src/testing.md @@ -0,0 +1,145 @@ +### The `#[test]` attribute +Today, rust programmers rely on a built in attribute called `#[test]`. +All you have to do is mark a function as a test and include some asserts like so: + +```rust,ignore +#[test] +fn my_test() { + assert!(2+2 == 4); +} +``` + +When this program is compiled using `rustc --test` or `cargo test`, it will +produce an executable that can run this, and any other test function. This +method of testing allows tests to live alongside code in an organic way. You +can even put tests inside private modules: + +```rust,ignore +mod my_priv_mod { + fn my_priv_func() -> bool {} + + #[test] + fn test_priv_func() { + assert!(my_priv_func()); + } +} +``` +Private items can thus be easily tested without worrying about how to expose +the them to any sort of external testing apparatus. This is key to the +ergonomics of testing in Rust. Semantically, however, it's rather odd. +How does any sort of `main` function invoke these tests if they're not visible? +What exactly is `rustc --test` doing? + +`#[test]` is implemented as a syntactic transformation inside the compiler's +[`libsyntax` crate][libsyntax]. Essentially, it's a fancy macro, that +rewrites the crate in 3 steps: + +#### Step 1: Re-Exporting + +As mentioned earlier, tests can exist inside private modules, so we need a way of +exposing them to the main function, without breaking any existing code. To that end, +`libsyntax` will create local modules called `__test_reexports` that recursively reexport tests. +This expansion translates the above example into: + +```rust,ignore +mod my_priv_mod { + fn my_priv_func() -> bool {} + + pub fn test_priv_func() { + assert!(my_priv_func()); + } + + pub mod __test_reexports { + pub use super::test_priv_func; + } +} +``` + +Now, our test can be accessed as +`my_priv_mod::__test_reexports::test_priv_func`. For deeper module +structures, `__test_reexports` will reexport modules that contain tests, so a +test at `a::b::my_test` becomes +`a::__test_reexports::b::__test_reexports::my_test`. While this process seems +pretty safe, what happens if there is an existing `__test_reexports` module? +The answer: nothing. + +To explain, we need to understand [how the AST represents +identifiers][Ident]. The name of every function, variable, module, etc. is +not stored as a string, but rather as an opaque [Symbol][Symbol] which is +essentially an ID number for each identifier. The compiler keeps a separate +hashtable that allows us to recover the human-readable name of a Symbol when +necessary (such as when printing a syntax error). When the compiler generates +the `__test_reexports` module, it generates a new Symbol for the identifier, +so while the compiler-generated `__test_reexports` may share a name with your +hand-written one, it will not share a Symbol. This technique prevents name +collision during code generation and is the foundation of Rust's macro +hygiene. + +#### Step 2: Harness Generation +Now that our tests are accessible from the root of our crate, we need to do something with them. +`libsyntax` generates a module like so: + +```rust,ignore +pub mod __test { + extern crate test; + const TESTS: &'static [self::test::TestDescAndFn] = &[/*...*/]; + + #[main] + pub fn main() { + self::test::test_static_main(TESTS); + } +} +``` + +While this transformation is simple, it gives us a lot of insight into how tests are actually run. +The tests are aggregated into an array and passed to a test runner called `test_static_main`. +We'll come back to exactly what `TestDescAndFn` is, but for now, the key takeaway is that there is a crate +called [`test`][test] that is part of Rust core, that implements all of the runtime for testing. `test`'s interface is unstable, +so the only stable way to interact with it is through the `#[test]` macro. + +#### Step 3: Test Object Generation +If you've written tests in Rust before, you may be familiar with some of the optional attributes available on test functions. +For example, a test can be annotated with `#[should_panic]` if we expect the test to cause a panic. It looks something like this: + +```rust,ignore +#[test] +#[should_panic] +fn foo() { + panic!("intentional"); +} +``` + +This means our tests are more than just simple functions, they have configuration information as well. `test` encodes this configuration +data into a struct called [`TestDesc`][TestDesc]. For each test function in a crate, `libsyntax` will parse its attributes and generate a `TestDesc` instance. +It then combines the `TestDesc` and test function into the predictably named `TestDescAndFn` struct, that `test_static_main` operates on. +For a given test, the generated `TestDescAndFn` instance looks like so: + +```rust,ignore +self::test::TestDescAndFn{ + desc: self::test::TestDesc{ + name: self::test::StaticTestName("foo"), + ignore: false, + should_panic: self::test::ShouldPanic::Yes, + allow_fail: false, + }, + testfn: self::test::StaticTestFn(|| + self::test::assert_test_result(::crate::__test_reexports::foo())), +} +``` + +Once we've constructed an array of these test objects, they're passed to the +test runner via the harness generated in step 2. + +### Inspecting the generated code +On nightly rust, there's an unstable flag called `unpretty` that you can use to print out the module source after macro expansion: + +```bash +$ rustc my_mod.rs -Z unpretty=hir +``` + +[test]: https://doc.rust-lang.org/test/index.html +[TestDesc]: https://doc.rust-lang.org/test/struct.TestDesc.html +[Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Ident.html +[Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Ident.html +[eRFC]: https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md +[libsyntax]: https://github.com/rust-lang/rust/tree/master/src/libsyntax \ No newline at end of file From 61adf4cb4b90ec74fdddccf425dde4eff88461ac Mon Sep 17 00:00:00 2001 From: John Renner Date: Tue, 24 Jul 2018 10:41:01 -0700 Subject: [PATCH 0296/1812] Shorten line length --- src/testing.md | 49 +++++++++++++++++++++++++++++-------------------- 1 file changed, 29 insertions(+), 20 deletions(-) diff --git a/src/testing.md b/src/testing.md index abe6849a7..3c93ad619 100644 --- a/src/testing.md +++ b/src/testing.md @@ -1,6 +1,6 @@ ### The `#[test]` attribute -Today, rust programmers rely on a built in attribute called `#[test]`. -All you have to do is mark a function as a test and include some asserts like so: +Today, rust programmers rely on a built in attribute called `#[test]`. All +you have to do is mark a function as a test and include some asserts like so: ```rust,ignore #[test] @@ -36,10 +36,11 @@ rewrites the crate in 3 steps: #### Step 1: Re-Exporting -As mentioned earlier, tests can exist inside private modules, so we need a way of -exposing them to the main function, without breaking any existing code. To that end, -`libsyntax` will create local modules called `__test_reexports` that recursively reexport tests. -This expansion translates the above example into: +As mentioned earlier, tests can exist inside private modules, so we need a +way of exposing them to the main function, without breaking any existing +code. To that end, `libsyntax` will create local modules called +`__test_reexports` that recursively reexport tests. This expansion translates +the above example into: ```rust,ignore mod my_priv_mod { @@ -76,8 +77,8 @@ collision during code generation and is the foundation of Rust's macro hygiene. #### Step 2: Harness Generation -Now that our tests are accessible from the root of our crate, we need to do something with them. -`libsyntax` generates a module like so: +Now that our tests are accessible from the root of our crate, we need to do +something with them. `libsyntax` generates a module like so: ```rust,ignore pub mod __test { @@ -91,15 +92,19 @@ pub mod __test { } ``` -While this transformation is simple, it gives us a lot of insight into how tests are actually run. -The tests are aggregated into an array and passed to a test runner called `test_static_main`. -We'll come back to exactly what `TestDescAndFn` is, but for now, the key takeaway is that there is a crate -called [`test`][test] that is part of Rust core, that implements all of the runtime for testing. `test`'s interface is unstable, -so the only stable way to interact with it is through the `#[test]` macro. +While this transformation is simple, it gives us a lot of insight into how +tests are actually run. The tests are aggregated into an array and passed to +a test runner called `test_static_main`. We'll come back to exactly what +`TestDescAndFn` is, but for now, the key takeaway is that there is a crate +called [`test`][test] that is part of Rust core, that implements all of the +runtime for testing. `test`'s interface is unstable, so the only stable way +to interact with it is through the `#[test]` macro. #### Step 3: Test Object Generation -If you've written tests in Rust before, you may be familiar with some of the optional attributes available on test functions. -For example, a test can be annotated with `#[should_panic]` if we expect the test to cause a panic. It looks something like this: +If you've written tests in Rust before, you may be familiar with some of the +optional attributes available on test functions. For example, a test can be +annotated with `#[should_panic]` if we expect the test to cause a panic. It +looks something like this: ```rust,ignore #[test] @@ -109,10 +114,13 @@ fn foo() { } ``` -This means our tests are more than just simple functions, they have configuration information as well. `test` encodes this configuration -data into a struct called [`TestDesc`][TestDesc]. For each test function in a crate, `libsyntax` will parse its attributes and generate a `TestDesc` instance. -It then combines the `TestDesc` and test function into the predictably named `TestDescAndFn` struct, that `test_static_main` operates on. -For a given test, the generated `TestDescAndFn` instance looks like so: +This means our tests are more than just simple functions, they have +configuration information as well. `test` encodes this configuration data +into a struct called [`TestDesc`][TestDesc]. For each test function in a +crate, `libsyntax` will parse its attributes and generate a `TestDesc` +instance. It then combines the `TestDesc` and test function into the +predictably named `TestDescAndFn` struct, that `test_static_main` operates +on. For a given test, the generated `TestDescAndFn` instance looks like so: ```rust,ignore self::test::TestDescAndFn{ @@ -131,7 +139,8 @@ Once we've constructed an array of these test objects, they're passed to the test runner via the harness generated in step 2. ### Inspecting the generated code -On nightly rust, there's an unstable flag called `unpretty` that you can use to print out the module source after macro expansion: +On nightly rust, there's an unstable flag called `unpretty` that you can use +to print out the module source after macro expansion: ```bash $ rustc my_mod.rs -Z unpretty=hir From 656831723492b241004dcd06df6f2dd619d2e4f3 Mon Sep 17 00:00:00 2001 From: John Renner Date: Tue, 7 Aug 2018 10:59:52 -0700 Subject: [PATCH 0297/1812] More descriptive name for #[test] implementation --- src/SUMMARY.md | 2 +- src/{testing.md => test-implementation.md} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename src/{testing.md => test-implementation.md} (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 27a6e38f2..ca3b4c020 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -17,7 +17,7 @@ - [Incremental compilation](./incremental-compilation.md) - [Debugging and Testing](./incrcomp-debugging.md) - [The parser](./the-parser.md) -- [Testing](./testing.md) +- [`#[test]` Implementation](./test-implementation.md) - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) - [The HIR (High-level IR)](./hir.md) diff --git a/src/testing.md b/src/test-implementation.md similarity index 100% rename from src/testing.md rename to src/test-implementation.md From 1f8e11729293468e206b193f8962eca6d2a0c4ce Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 18 Aug 2018 12:54:42 -0700 Subject: [PATCH 0298/1812] Update copyright guidance to omit notices for new files. Previously approved in https://github.com/rust-lang/rust/pull/43498 ; update the guide to match. --- src/compiletest.md | 10 ---------- src/conventions.md | 23 +++++------------------ src/tests/adding.md | 4 ---- 3 files changed, 5 insertions(+), 32 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index 0837fb819..40d06136e 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -63,16 +63,6 @@ header command and the argument list (if present) are typically separated by a colon: ```rust,ignore -// Copyright 2018 The Rust Project Developers. See the COPYRIGHT -// file at the top-level directory of this distribution and at -// http://rust-lang.org/COPYRIGHT. -// -// Licensed under the Apache License, Version 2.0 or the MIT license -// , at your -// option. This file may not be copied, modified, or distributed -// except according to those terms. - // must-compile-successfully // failure-status: 1 diff --git a/src/conventions.md b/src/conventions.md index 3f30dac73..93c5c44be 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -20,24 +20,11 @@ in isolation with `./x.py test src/tools/tidy`. ### Copyright notice -All files must begin with the following copyright notice: - -```rust -// Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT -// file at the top-level directory of this distribution and at -// http://rust-lang.org/COPYRIGHT. -// -// Licensed under the Apache License, Version 2.0 or the MIT license -// , at your -// option. This file may not be copied, modified, or distributed -// except according to those terms. -``` - -The year at the top is not meaningful: copyright protections are in -fact automatic from the moment of authorship. We do not typically edit -the years on existing files. When creating a new file, you can use the -current year if you like, but you don't have to. +Some existing files begin with a copyright and license notice. Please omit this +notice for new files licensed under the standard terms (dual MIT/Apache-2.0). +For existing files, the year at the top is not meaningful: copyright +protections are in fact automatic from the moment of authorship. We do not +typically edit the years on existing files. ## Line length diff --git a/src/tests/adding.md b/src/tests/adding.md index 7469755f7..ee264747a 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -101,10 +101,6 @@ this test. For example, this test uses the `// compile-flags` command to specify a custom flag to give to rustc when the test is compiled: ```rust,ignore -// Copyright 2017 The Rust Project Developers. blah blah blah. -// ... -// except according to those terms. - // Test the behavior of `0 - 1` when overflow checks are disabled. // compile-flags: -Coverflow-checks=off From 9efa9f13466dc73ac9152ab44ffeeebd930030fb Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Fri, 6 Jul 2018 14:53:53 +0200 Subject: [PATCH 0299/1812] Explain existential types --- src/SUMMARY.md | 1 + src/existential-types.md | 48 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+) create mode 100644 src/existential-types.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ca3b4c020..981da5c1e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -45,6 +45,7 @@ - [Type checking](./type-checking.md) - [Method Lookup](./method-lookup.md) - [Variance](./variance.md) + - [Existential Types](./existential-types.md) - [The MIR (Mid-level IR)](./mir/index.md) - [MIR construction](./mir/construction.md) - [MIR visitor and traversal](./mir/visitor.md) diff --git a/src/existential-types.md b/src/existential-types.md new file mode 100644 index 000000000..4c5ebb75c --- /dev/null +++ b/src/existential-types.md @@ -0,0 +1,48 @@ +# Existential Types + +Existential types are essentially strong type aliases which only expose +a specific set of traits as their interface and the concrete type in the +background is inferred from a certain set of use sites of the existential +type. + +In the language they are expressed via + +```rust +existential type Foo: Bar; +``` + +This is in existential type named `Foo` which can be interacted with via +the `Bar` trait's interface. + +Since there needs to be a concrete background type, you can currently +express that type by using the existential type in a "defining use site". + +```rust +struct Struct; +impl Bar for Struct { /* stuff */ } +fn foo() -> Foo { + Struct +} +``` + +Any other "defining use site" needs to produce the exact same type. + +## Defining use site(s) + +Currently only the return value of a function inside can +be a defining use site of an existential type (and only if the return +type of that function contains the existential type). + +The defining use of an existential type can be any code *within* the parent +of the existential type definition. This includes any siblings of the +existential type and all children of the siblings. + +The initiative for *"not causing fatal brain damage to developers due to +accidentally running infinite loops in their brain while trying to +comprehend what the type system is doing"* has decided to disallow children +of existential types to be defining use sites. + +### Associated existential types + +Associated existential types can be defined by any other associated item +on the same trait `impl` or a child of these associated items. \ No newline at end of file From 6533ccebba453402192d82af9b44b62de4054e7f Mon Sep 17 00:00:00 2001 From: Oliver Schneider Date: Wed, 1 Aug 2018 18:35:17 +0200 Subject: [PATCH 0300/1812] Update existential-types.md --- src/existential-types.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/existential-types.md b/src/existential-types.md index 4c5ebb75c..3e4a49210 100644 --- a/src/existential-types.md +++ b/src/existential-types.md @@ -7,7 +7,7 @@ type. In the language they are expressed via -```rust +``` existential type Foo: Bar; ``` @@ -17,7 +17,7 @@ the `Bar` trait's interface. Since there needs to be a concrete background type, you can currently express that type by using the existential type in a "defining use site". -```rust +``` struct Struct; impl Bar for Struct { /* stuff */ } fn foo() -> Foo { @@ -45,4 +45,4 @@ of existential types to be defining use sites. ### Associated existential types Associated existential types can be defined by any other associated item -on the same trait `impl` or a child of these associated items. \ No newline at end of file +on the same trait `impl` or a child of these associated items. From 7836a59e48f33c9f45e93a594ca6c165a78df4c2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 7 Aug 2018 08:38:21 -0400 Subject: [PATCH 0301/1812] add rust,ignore to code snippets --- src/existential-types.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/existential-types.md b/src/existential-types.md index 3e4a49210..ef20167c1 100644 --- a/src/existential-types.md +++ b/src/existential-types.md @@ -7,7 +7,7 @@ type. In the language they are expressed via -``` +```rust,ignore existential type Foo: Bar; ``` @@ -17,7 +17,7 @@ the `Bar` trait's interface. Since there needs to be a concrete background type, you can currently express that type by using the existential type in a "defining use site". -``` +```rust,ignore struct Struct; impl Bar for Struct { /* stuff */ } fn foo() -> Foo { From 3aa13477d1b8efab7f46374697231ea523d7965d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Duquette?= Date: Thu, 23 Aug 2018 00:13:02 -0400 Subject: [PATCH 0302/1812] Rename CodeMap and FileMap to SourceMap and SourceFile. Those types were renamed in https://github.com/rust-lang/rust/pull/52953 --- src/appendix/code-index.md | 4 ++-- src/diag.md | 16 ++++++++-------- src/rustc-driver.md | 4 ++-- src/the-parser.md | 10 +++++----- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index b6986c5c0..140b182b1 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -7,20 +7,20 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- `BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html) -`CodeMap` | struct | Maps AST nodes to their source code. It is composed of `FileMap`s | [The parser] | [src/libsyntax/codemap.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html) `CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html) `ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) `hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) `DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html) `DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) -`FileMap` | struct | Part of the `CodeMap`. Maps AST nodes to their source code for a single source file | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.FileMap.html) `HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html) `NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Rib.html) `Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) +`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) +`SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html) `syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) diff --git a/src/diag.md b/src/diag.md index 3690d6152..3d9a6fc37 100644 --- a/src/diag.md +++ b/src/diag.md @@ -9,14 +9,14 @@ This chapter is about how to emit compile errors and lints from the compiler. location in the code being compiled. `Span`s are attached to most constructs in HIR and MIR, allowing for more informative error reporting. -[span]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.Span.html +[span]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.Span.html -A `Span` can be looked up in a [`CodeMap`][codemap] to get a "snippet" useful +A `Span` can be looked up in a [`SourceMap`][sourcemap] to get a "snippet" useful for displaying errors with [`span_to_snippet`][sptosnip] and other similar -methods on the `CodeMap`. +methods on the `SourceMap`. -[codemap]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html -[sptosnip]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html#method.span_to_snippet +[sourcemap]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html +[sptosnip]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html#method.span_to_snippet ## Error messages @@ -58,7 +58,7 @@ let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); // In some cases, you might need to check if `sp` is generated by a macro to // avoid printing weird errors about macro-generated code. -if let Ok(snippet) = sess.codemap().span_to_snippet(sp) { +if let Ok(snippet) = sess.source_map().span_to_snippet(sp) { // Use the snippet to generate a suggested fix err.span_suggestion(suggestion_sp, "try using a qux here", format!("qux {}", snip)); } else { @@ -96,7 +96,7 @@ For example, to make our `qux` suggestion machine-applicable, we would do: ```rust,ignore let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); -if let Ok(snippet) = sess.codemap().span_to_snippet(sp) { +if let Ok(snippet) = sess.source_map().span_to_snippet(sp) { // Add applicability info! err.span_suggestion_with_applicability( suggestion_sp, @@ -214,7 +214,7 @@ impl<'a, 'tcx> LateLintPass<'a, 'tcx> for WhileTrue { if let ast::LitKind::Bool(true) = lit.node { if lit.span.ctxt() == SyntaxContext::empty() { let msg = "denote infinite loops with `loop { ... }`"; - let condition_span = cx.tcx.sess.codemap().def_span(e.span); + let condition_span = cx.tcx.sess.source_map().def_span(e.span); let mut err = cx.struct_span_lint(WHILE_TRUE, condition_span, msg); err.span_suggestion_short(condition_span, "use `loop`", "loop".to_owned()); err.emit(); diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 1550b14e9..397949836 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -2,7 +2,7 @@ The [`rustc_driver`] is essentially `rustc`'s `main()` function. It acts as the glue for running the various phases of the compiler in the correct order, -managing state such as the [`CodeMap`] \(maps AST nodes to source code), +managing state such as the [`SourceMap`] \(maps AST nodes to source code), [`Session`] \(general build context and error messaging) and the [`TyCtxt`] \(the "typing context", allowing you to query the type system and other cool stuff). The `rustc_driver` crate also provides external users with a method @@ -71,6 +71,6 @@ thread-locals, although you should rarely need to touch it. [`CompileState`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html [`Session`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html [`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html -[`CodeMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html +[`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html [stupid-stats]: https://github.com/nrc/stupid-stats [Appendix A]: appendix/stupid-stats.html diff --git a/src/the-parser.md b/src/the-parser.md index e89c09e9e..62b43c0ee 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -14,7 +14,7 @@ Like most parsers, the parsing process is composed of two main steps, The `syntax` crate contains several main players, -- a [`CodeMap`] for mapping AST nodes to their source code +- a [`SourceMap`] for mapping AST nodes to their source code - the [ast module] contains types corresponding to each AST node - a [`StringReader`] for lexing source code into tokens - the [parser module] and [`Parser`] struct are in charge of actually parsing @@ -23,21 +23,21 @@ The `syntax` crate contains several main players, nodes. The main entrypoint to the parser is via the various `parse_*` functions in the -[parser module]. They let you do things like turn a [`FileMap`][filemap] (e.g. +[parser module]. They let you do things like turn a [`SourceFile`][sourcefile] (e.g. the source in a single file) into a token stream, create a parser from the token stream, and then execute the parser to get a `Crate` (the root AST node). To minimise the amount of copying that is done, both the `StringReader` and `Parser` have lifetimes which bind them to the parent `ParseSess`. This contains -all the information needed while parsing, as well as the `CodeMap` itself. +all the information needed while parsing, as well as the `SourceMap` itself. [libsyntax]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/index.html [rustc_errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree -[`CodeMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.CodeMap.html +[`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html [ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/index.html [parser module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/index.html [`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/parser/struct.Parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html [visit module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/visit/index.html -[filemap]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/codemap/struct.FileMap.html +[sourcefile]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html From a28a4cf252e5dfa273f1af1608ea954d6a5711c3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Duquette?= Date: Thu, 23 Aug 2018 00:23:03 -0400 Subject: [PATCH 0303/1812] Fix lines over 80 columns. --- src/diag.md | 6 +++--- src/the-parser.md | 7 ++++--- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/src/diag.md b/src/diag.md index 3d9a6fc37..b30ec2eca 100644 --- a/src/diag.md +++ b/src/diag.md @@ -11,9 +11,9 @@ HIR and MIR, allowing for more informative error reporting. [span]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.Span.html -A `Span` can be looked up in a [`SourceMap`][sourcemap] to get a "snippet" useful -for displaying errors with [`span_to_snippet`][sptosnip] and other similar -methods on the `SourceMap`. +A `Span` can be looked up in a [`SourceMap`][sourcemap] to get a "snippet" +useful for displaying errors with [`span_to_snippet`][sptosnip] and other +similar methods on the `SourceMap`. [sourcemap]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html [sptosnip]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html#method.span_to_snippet diff --git a/src/the-parser.md b/src/the-parser.md index 62b43c0ee..ac902d915 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -23,9 +23,10 @@ The `syntax` crate contains several main players, nodes. The main entrypoint to the parser is via the various `parse_*` functions in the -[parser module]. They let you do things like turn a [`SourceFile`][sourcefile] (e.g. -the source in a single file) into a token stream, create a parser from the -token stream, and then execute the parser to get a `Crate` (the root AST node). +[parser module]. They let you do things like turn a [`SourceFile`][sourcefile] +(e.g. the source in a single file) into a token stream, create a parser from +the token stream, and then execute the parser to get a `Crate` (the root AST +node). To minimise the amount of copying that is done, both the `StringReader` and `Parser` have lifetimes which bind them to the parent `ParseSess`. This contains From 581b5fc9cfb3674e9474abb6a6513320722dda01 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Duquette?= Date: Thu, 23 Aug 2018 21:29:01 -0400 Subject: [PATCH 0304/1812] address review comment --- src/appendix/code-index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 140b182b1..75d35c6c5 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -19,8 +19,8 @@ Item | Kind | Short description | Chapter | `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Rib.html) `Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) -`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) -`SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) +`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) +`SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html) `syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) From f893fe80190fc0fd3fdd66ba683959fe56182c4e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 09:23:14 -0400 Subject: [PATCH 0305/1812] sprinkle links to rustdoc through the HIR explanation --- src/hir.md | 87 ++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 58 insertions(+), 29 deletions(-) diff --git a/src/hir.md b/src/hir.md index 40a14dc25..171319011 100644 --- a/src/hir.md +++ b/src/hir.md @@ -20,13 +20,15 @@ You can view the HIR representation of your code by passing the ### Out-of-band storage and the `Crate` type -The top-level data-structure in the HIR is the `Crate`, which stores +The top-level data-structure in the HIR is the [`Crate`], which stores the contents of the crate currently being compiled (we only ever construct HIR for the current crate). Whereas in the AST the crate data structure basically just contains the root module, the HIR `Crate` structure contains a number of maps and other things that serve to organize the content of the crate for easier access. +[`Crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html + For example, the contents of individual items (e.g. modules, functions, traits, impls, etc) in the HIR are not immediately accessible in the parents. So, for example, if there is a module item @@ -38,11 +40,13 @@ mod foo { } ``` -then in the HIR the representation of module `foo` (the `Mod` -stuct) would only have the **`ItemId`** `I` of `bar()`. To get the +then in the HIR the representation of module `foo` (the [`Mod`] +struct) would only have the **`ItemId`** `I` of `bar()`. To get the details of the function `bar()`, we would lookup `I` in the `items` map. +[`Mod`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Mod.html + One nice result from this representation is that one can iterate over all items in the crate by iterating over the key-value pairs in these maps (without the need to trawl through the whole HIR). @@ -51,12 +55,14 @@ as well as "bodies" (explained below). The other reason to set up the representation this way is for better integration with incremental compilation. This way, if you gain access -to an `&hir::Item` (e.g. for the mod `foo`), you do not immediately +to an [`&hir::Item`] (e.g. for the mod `foo`), you do not immediately gain access to the contents of the function `bar()`. Instead, you only gain access to the **id** for `bar()`, and you must invoke some -function to lookup the contents of `bar()` given its id; this gives the -compiler a chance to observe that you accessed the data for `bar()`, -and then record the dependency. +function to lookup the contents of `bar()` given its id; this gives +the compiler a chance to observe that you accessed the data for +`bar()`, and then record the dependency. + +[`&hir::Item`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Item.html @@ -67,63 +73,86 @@ carry around references into the HIR, but rather to carry around *identifier numbers* (or just "ids"). Right now, you will find four sorts of identifiers in active use: -- `DefId`, which primarily names "definitions" or top-level items. - - You can think of a `DefId` as being shorthand for a very explicit +- [`DefId`], which primarily names "definitions" or top-level items. + - You can think of a [`DefId`] as being shorthand for a very explicit and complete path, like `std::collections::HashMap`. However, these paths are able to name things that are not nameable in normal Rust (e.g. impls), and they also include extra information about the crate (such as its version number, as two versions of the same crate can co-exist). - - A `DefId` really consists of two parts, a `CrateNum` (which + - A [`DefId`] really consists of two parts, a `CrateNum` (which identifies the crate) and a `DefIndex` (which indixes into a list of items that is maintained per crate). -- `HirId`, which combines the index of a particular item with an +- [`HirId`], which combines the index of a particular item with an offset within that item. - - the key point of a `HirId` is that it is *relative* to some item - (which is named via a `DefId`). -- `BodyId`, this is an absolute identifier that refers to a specific + - the key point of a [`HirId`] is that it is *relative* to some item + (which is named via a [`DefId`]). +- [`BodyId`], this is an absolute identifier that refers to a specific body (definition of a function or constant) in the crate. It is currently - effectively a "newtype'd" `NodeId`. -- `NodeId`, which is an absolute id that identifies a single node in the HIR + effectively a "newtype'd" [`NodeId`]. +- [`NodeId`], which is an absolute id that identifies a single node in the HIR tree. - While these are still in common use, **they are being slowly phased out**. - Since they are absolute within the crate, adding a new node anywhere in the - tree causes the `NodeId`s of all subsequent code in the crate to change. + tree causes the [`NodeId`]s of all subsequent code in the crate to change. This is terrible for incremental compilation, as you can perhaps imagine. +[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html +[`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html +[`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html +[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html + ### The HIR Map Most of the time when you are working with the HIR, you will do so via -the **HIR Map**, accessible in the tcx via `tcx.hir` (and defined in -the `hir::map` module). The HIR map contains a number of methods to +the **HIR Map**, accessible in the tcx via [`tcx.hir`] (and defined in +the [`hir::map`] module). The [HIR map] contains a [number of methods] to convert between IDs of various kinds and to lookup data associated with an HIR node. -For example, if you have a `DefId`, and you would like to convert it -to a `NodeId`, you can use `tcx.hir.as_local_node_id(def_id)`. This +[`tcx.hir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.GlobalCtxt.html#structfield.hir +[`hir::map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/index.html +[HIR map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html +[number of methods]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#methods + +For example, if you have a [`DefId`], and you would like to convert it +to a [`NodeId`], you can use [`tcx.hir.as_local_node_id(def_id)`][as_local_node_id]. This returns an `Option` – this will be `None` if the def-id refers to something outside of the current crate (since then it has no HIR node), but otherwise returns `Some(n)` where `n` is the node-id of the definition. -Similarly, you can use `tcx.hir.find(n)` to lookup the node for a -`NodeId`. This returns a `Option>`, where `Node` is an enum +[as_local_node_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.as_local_node_id + +Similarly, you can use [`tcx.hir.find(n)`][find] to lookup the node for a +[`NodeId`]. This returns a `Option>`, where [`Node`] is an enum defined in the map; by matching on this you can find out what sort of node the node-id referred to and also get a pointer to the data itself. Often, you know what sort of node `n` is – e.g. if you know that `n` must be some HIR expression, you can do -`tcx.hir.expect_expr(n)`, which will extract and return the -`&hir::Expr`, panicking if `n` is not in fact an expression. +[`tcx.hir.expect_expr(n)`][expect_expr], which will extract and return the +[`&hir::Expr`][Expr], panicking if `n` is not in fact an expression. + +[find]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.find +[`Node`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/enum.Node.html +[expect_expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.expect_expr +[Expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Expr.html Finally, you can use the HIR map to find the parents of nodes, via -calls like `tcx.hir.get_parent_node(n)`. +calls like [`tcx.hir.get_parent_node(n)`][get_parent_node]. + +[get_parent_node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.get_parent_node ### HIR Bodies -A **body** represents some kind of executable code, such as the body +A [`hir::Body`] represents some kind of executable code, such as the body of a function/closure or the definition of a constant. Bodies are associated with an **owner**, which is typically some kind of item (e.g. an `fn()` or `const`), but could also be a closure expression (e.g. `|x, y| x + y`). You can use the HIR map to find the body -associated with a given def-id (`maybe_body_owned_by()`) or to find -the owner of a body (`body_owner_def_id()`). +associated with a given def-id ([`maybe_body_owned_by`]) or to find +the owner of a body ([`body_owner_def_id`]). + +[`hir::Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Body.html +[`maybe_body_owned_by`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.maybe_body_owned_by +[`body_owner_def_id`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.body_owner_def_id From 5321d0059f97fd964d8b6aac3ce3dadab2e7f5cf Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 09:58:32 -0400 Subject: [PATCH 0306/1812] tweak long line --- src/hir.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/hir.md b/src/hir.md index 171319011..a5e99e8b3 100644 --- a/src/hir.md +++ b/src/hir.md @@ -116,11 +116,12 @@ with an HIR node. [number of methods]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#methods For example, if you have a [`DefId`], and you would like to convert it -to a [`NodeId`], you can use [`tcx.hir.as_local_node_id(def_id)`][as_local_node_id]. This -returns an `Option` – this will be `None` if the def-id -refers to something outside of the current crate (since then it has no -HIR node), but otherwise returns `Some(n)` where `n` is the node-id of -the definition. +to a [`NodeId`], you can use +[`tcx.hir.as_local_node_id(def_id)`][as_local_node_id]. This returns +an `Option` – this will be `None` if the def-id refers to +something outside of the current crate (since then it has no HIR +node), but otherwise returns `Some(n)` where `n` is the node-id of the +definition. [as_local_node_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.as_local_node_id From 3d094aa310cc4764a25acf4f95e9d6c4db0a5314 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:00:31 -0400 Subject: [PATCH 0307/1812] add a section about the compiler team --- src/SUMMARY.md | 1 + src/compiler-team.md | 100 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 101 insertions(+) create mode 100644 src/compiler-team.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 981da5c1e..8de0e71ca 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -3,6 +3,7 @@ - [About this guide](./about-this-guide.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) - [Coding conventions](./conventions.md) +- [About the compiler team](./compiler-team.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) - [Adding new tests](./tests/adding.md) diff --git a/src/compiler-team.md b/src/compiler-team.md new file mode 100644 index 000000000..89e95e2c3 --- /dev/null +++ b/src/compiler-team.md @@ -0,0 +1,100 @@ +# About the compiler team + +rustc is maintained by the +[Rust compiler team](https://www.rust-lang.org/en-US/team.html). The +people who belong to this team collectively work to track regressions +and implement new features. Members of the Rust compiler team are +people who have made significant contributions to rustc and its +design. + +## Rust compiler meeting + +The compiler team has a weekly meeting where we do triage and try to generally +stay on top of new bugs, regressions, and other things. This general plan for +this meeting can be found in [the rust-compiler-meeting etherpad][etherpad]. It works +roughly as follows: + +- **Review P-high bugs:** P-high bugs are those that are sufficiently important for us + to actively track progress. P-high bugs should ideally always have an assignee. +- **Look over new regressions:** we then look for new cases where the + compiler broke previously working code in the wild. Regressions are + almost always marked as P-high; the major exception would be bug + fixes (though even there we often + [aim to give warnings first][procedure]). +- **Check I-nominated issues:** These are issues where feedback from the team is desired. +- **Check for beta nominations:** These are nominations of things to backport to beta. + +The meeting currently takes place on Thursdays at 10am Boston time +(UTC-4 typically, but daylight savings time sometimes makes things +complicated). + +The meeting is held over a "chat medium" -- it used to be IRC, but we +are currently in the process of evaluating other alternatives. Check +[the etherpad] to find the current home (and see +[this internals thread][thread] for some ongoing discussion). + +[etherpad]: https://public.etherpad-mozilla.org/p/rust-compiler-meeting +[thread]: https://internals.rust-lang.org/t/where-should-the-compiler-team-and-perhaps-working-groups-chat/7894 +[procedure]: https://forge.rust-lang.org/rustc-bug-fix-procedure.html + +## Team membership + +Membership in the Rust team is typically offered when someone has been +making significant contributions to the compiler for some +time. Membership is both a recognition but also an obligation: +compiler team members are generally expected to help with upkeep as +well as doing reviews and other work. + +If you are interested in becoming a compiler team member, the first +thing to do is to start fixing some bugs, or get involved in a working +group. + +### r+ rights + +Once you have made a number of individual PRs to rustc, we will often +offer r+ privileges. This means that you have the right to instruct +"bors" (the robot that manages which PRs get landed into rustc) to +merge a PR +([here are some instructions for how to talk to bors][homu-guide]). + +[homu-guide]: https://buildbot2.rust-lang.org/homu/ + +The guidelines for reviewers are as follows: + +- You are always welcome to review any PR, regardless of who it is assigned to. + However, do not r+ PRs unless: + - You are confident in that part of the code. + - You are confident that nobody else wants to review it first. + - For example, sometimes people will express a desire to review a PR before it lands, + perhaps because it touches a particularly sensitive part of the code. +- Always be polite when reviewing: you are a representative of the Rust project, + so it is expected that you will go above and beyond when it comes to the [Code of Conduct]. + +[Code of Conduct]: https://www.rust-lang.org/en-US/conduct.html + +### high-five + +Once you have r+ rights, you can also be added to the high-five +rotation. high-five is the bot that assigns incoming PRs to +reviewers. If you are added, you will be randomly selected to review +PRs. If you find you are assigned a PR that you don't feel comfortable +reviewing, you can also leave a comment like `r? @so-and-so` to assign +to someone else -- if you don't know who to request, just write `r? +@nikomatsakis for reassignment` and @nikomatsakis will pick someone +for you. + +[hi5]: https://github.com/rust-highfive + +Getting on the high-five list is much appreciated as it lowers the +review burden for all of us! However, if you don't have time to give +people timely feedback on their PRs, it may be better that you don't +get on the list. + +### Team membership + +Full team membership is typically extended once someone made many +contributions to the Rust compiler over time, ideally (but not +necessarily) to multiple areas. Sometimes this might be implementing a +new feature, but it is also important -- perhaps more important! -- to +have time and willingness to help out with general upkeep such as +bugfixes, tracking regressions, and other less glamorous work. From 7c200dffd7adcd4c8b870e0378d00d260b1d1f35 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:59:29 -0400 Subject: [PATCH 0308/1812] adjust long lines --- src/compiler-team.md | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index 89e95e2c3..d7ee98d30 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -9,20 +9,24 @@ design. ## Rust compiler meeting -The compiler team has a weekly meeting where we do triage and try to generally -stay on top of new bugs, regressions, and other things. This general plan for -this meeting can be found in [the rust-compiler-meeting etherpad][etherpad]. It works -roughly as follows: - -- **Review P-high bugs:** P-high bugs are those that are sufficiently important for us - to actively track progress. P-high bugs should ideally always have an assignee. +The compiler team has a weekly meeting where we do triage and try to +generally stay on top of new bugs, regressions, and other things. This +general plan for this meeting can be found in +[the rust-compiler-meeting etherpad][etherpad]. It works roughly as +follows: + +- **Review P-high bugs:** P-high bugs are those that are sufficiently + important for us to actively track progress. P-high bugs should + ideally always have an assignee. - **Look over new regressions:** we then look for new cases where the compiler broke previously working code in the wild. Regressions are almost always marked as P-high; the major exception would be bug fixes (though even there we often [aim to give warnings first][procedure]). -- **Check I-nominated issues:** These are issues where feedback from the team is desired. -- **Check for beta nominations:** These are nominations of things to backport to beta. +- **Check I-nominated issues:** These are issues where feedback from + the team is desired. +- **Check for beta nominations:** These are nominations of things to + backport to beta. The meeting currently takes place on Thursdays at 10am Boston time (UTC-4 typically, but daylight savings time sometimes makes things @@ -61,14 +65,16 @@ merge a PR The guidelines for reviewers are as follows: -- You are always welcome to review any PR, regardless of who it is assigned to. - However, do not r+ PRs unless: +- You are always welcome to review any PR, regardless of who it is + assigned to. However, do not r+ PRs unless: - You are confident in that part of the code. - You are confident that nobody else wants to review it first. - - For example, sometimes people will express a desire to review a PR before it lands, - perhaps because it touches a particularly sensitive part of the code. -- Always be polite when reviewing: you are a representative of the Rust project, - so it is expected that you will go above and beyond when it comes to the [Code of Conduct]. + - For example, sometimes people will express a desire to review a + PR before it lands, perhaps because it touches a particularly + sensitive part of the code. +- Always be polite when reviewing: you are a representative of the + Rust project, so it is expected that you will go above and beyond + when it comes to the [Code of Conduct]. [Code of Conduct]: https://www.rust-lang.org/en-US/conduct.html From 207e669c1f7e45a8cc2fd761567d9b6f24e49d3a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 14:46:03 -0400 Subject: [PATCH 0309/1812] fix various minor points --- src/SUMMARY.md | 2 +- src/compiler-team.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 8de0e71ca..1cb9ea599 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -1,9 +1,9 @@ # Summary - [About this guide](./about-this-guide.md) +- [About the compiler team](./compiler-team.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) - [Coding conventions](./conventions.md) -- [About the compiler team](./compiler-team.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) - [Adding new tests](./tests/adding.md) diff --git a/src/compiler-team.md b/src/compiler-team.md index d7ee98d30..ad8ac292f 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -32,9 +32,9 @@ The meeting currently takes place on Thursdays at 10am Boston time (UTC-4 typically, but daylight savings time sometimes makes things complicated). -The meeting is held over a "chat medium" -- it used to be IRC, but we +The meeting is held over a "chat medium" — it used to be IRC, but we are currently in the process of evaluating other alternatives. Check -[the etherpad] to find the current home (and see +the [etherpad] to find the current home (and see [this internals thread][thread] for some ongoing discussion). [etherpad]: https://public.etherpad-mozilla.org/p/rust-compiler-meeting @@ -85,7 +85,7 @@ rotation. high-five is the bot that assigns incoming PRs to reviewers. If you are added, you will be randomly selected to review PRs. If you find you are assigned a PR that you don't feel comfortable reviewing, you can also leave a comment like `r? @so-and-so` to assign -to someone else -- if you don't know who to request, just write `r? +to someone else — if you don't know who to request, just write `r? @nikomatsakis for reassignment` and @nikomatsakis will pick someone for you. @@ -96,11 +96,11 @@ review burden for all of us! However, if you don't have time to give people timely feedback on their PRs, it may be better that you don't get on the list. -### Team membership +### Full team membership Full team membership is typically extended once someone made many contributions to the Rust compiler over time, ideally (but not necessarily) to multiple areas. Sometimes this might be implementing a -new feature, but it is also important -- perhaps more important! -- to +new feature, but it is also important — perhaps more important! — to have time and willingness to help out with general upkeep such as bugfixes, tracking regressions, and other less glamorous work. From e295ad412e02c6770bbacdd153fef379f1d12efc Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 14:48:16 -0400 Subject: [PATCH 0310/1812] includ some notes on finding bugs --- src/compiler-team.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index ad8ac292f..45883e9d1 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -51,7 +51,10 @@ well as doing reviews and other work. If you are interested in becoming a compiler team member, the first thing to do is to start fixing some bugs, or get involved in a working -group. +group. One good way to find bugs is to look for +[open issues tagged with E-easy](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy) +or +[E-mentor](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-mentor). ### r+ rights From 81fd1c02f2e7db7570b87e4dff2270f25339ba7b Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 14:50:29 -0400 Subject: [PATCH 0311/1812] note about discussion channels --- src/compiler-team.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/compiler-team.md b/src/compiler-team.md index 45883e9d1..a6328198c 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -7,6 +7,16 @@ and implement new features. Members of the Rust compiler team are people who have made significant contributions to rustc and its design. +## Discussion + +Currently the compiler team chats in a number of places. There is an +ongoing [thread] on the internals board about trying to find a permanent +home. In any case, you can find people in one of three places at the moment: + +- The `#rustc` channel on mozilla's IRC (`irc.mozilla.org`) +- The `t-compiler` stream on [the Zulip instance](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler) +- The `compiler` channel on the [rust-lang discord](https://discord.gg/rust-lang) + ## Rust compiler meeting The compiler team has a weekly meeting where we do triage and try to From e731de57556dadd62b3148aaad5d83652a86eff7 Mon Sep 17 00:00:00 2001 From: Dale Wijnand <344610+dwijnand@users.noreply.github.com> Date: Fri, 7 Sep 2018 11:46:53 +0100 Subject: [PATCH 0312/1812] No copyright notices on new tests --- src/tests/adding.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index ee264747a..dca224fff 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -9,7 +9,6 @@ To add a new test, the first thing you generally do is to create a file, typically a Rust source file. Test files have a particular structure: -- They always begin with the [copyright notice](./conventions.html#copyright); - then they should have some kind of [comment explaining what the test is about](#explanatory_comment); - next, they can have one or more [header commands](#header_commands), which From ad03ec4ee8e1f1579018f5ed879e06d881b2ea31 Mon Sep 17 00:00:00 2001 From: Dale Wijnand <344610+dwijnand@users.noreply.github.com> Date: Fri, 7 Sep 2018 11:47:56 +0100 Subject: [PATCH 0313/1812] Write in English --- src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index dca224fff..b9f05b9dd 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -9,7 +9,7 @@ To add a new test, the first thing you generally do is to create a file, typically a Rust source file. Test files have a particular structure: -- then they should have some kind of +- They should have some kind of [comment explaining what the test is about](#explanatory_comment); - next, they can have one or more [header commands](#header_commands), which are special comments that the test interpreter knows how to interpret. From 44c05c72be6f4a5f6bf6295fc7f6ece9566c7f2e Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:57:51 -0400 Subject: [PATCH 0314/1812] add a section about profiling with perf --- src/SUMMARY.md | 4 +- src/profiling.md | 9 ++ src/profiling/with_perf.md | 294 +++++++++++++++++++++++++++++++++++++ 3 files changed, 306 insertions(+), 1 deletion(-) create mode 100644 src/profiling.md create mode 100644 src/profiling/with_perf.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 1cb9ea599..ad8a82623 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -4,13 +4,15 @@ - [About the compiler team](./compiler-team.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) - [Coding conventions](./conventions.md) +- [Walkthrough: a typical contribution](./walkthrough.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) - [Adding new tests](./tests/adding.md) - [Using `compiletest` + commands to control test execution](./compiletest.md) - [Debugging the Compiler](./compiler-debugging.md) -- [Walkthrough: a typical contribution](./walkthrough.md) +- [Profiling the compiler](./profiling.md) + - [with the linux perf tool](./profiling/with_perf.md) - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver](./rustc-driver.md) - [Rustdoc](./rustdoc.md) diff --git a/src/profiling.md b/src/profiling.md new file mode 100644 index 000000000..f6771b07b --- /dev/null +++ b/src/profiling.md @@ -0,0 +1,9 @@ +# Profiling the compiler + +This discussion talks about how profile the compiler and find out +where it spends its time. If you just want to get a general overview, +it is often a good idea to just add `-Zself-profile` option to the +rustc command line. This will break down time spent into various +categories. But if you want a more detailed look, you probably want +to break out a custom profiler. + diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md new file mode 100644 index 000000000..dc767c9a5 --- /dev/null +++ b/src/profiling/with_perf.md @@ -0,0 +1,294 @@ +# Profiling with perf + +sThis is a guide for how to profile rustc with perf. + +## Initial steps + +- Get a clean checkout of rust-lang/master, or whatever it is you want to profile. +- Set the following settings in your `config.toml`: + - `debuginfo-lines = true` + - `use-jemalloc = false` -- lets you do memory use profiling with valgrind + - leave everything else the defaults +- Run `./x.py build` to get a full build +- Make a rustup toolchain (let's call it `rust-prof`) pointing to that result + - `rustup toolchain link` XXX + +## Gathering a perf profile + +perf is an excellent tool on linux that can be used to gather and +analyze all kinds of information. Mostly it is used to figure out +where a program spends its time. It can also be used for other sorts +of events, though, like cache misses and so forth. + +### The basics + +The basic `perf` command is this: + +``` +perf record -F99 --call-graph dwarf XXX +``` + +The `-F99` tells perf to sample at 99 Hz, which avoids generating too +much data for longer runs. The `--call-graph dwarf` tells perf to get +call-graph information from debuginfo, which is accurate. The `XXX` is +the command you want to profile. So, for example, you might do: + +``` +perf record -F99 --call-graph dwarf cargo +rust-prof rustc +``` + +to run `cargo`. But there are some things to be aware of: + +- You probably don't want to profile the time spend building + dependencies. So something like `cargo build; cargo clean -p $C` may + be helpful (where `$C` is the crate name) +- You probably don't want incremental messing about with your + profile. So something like `CARGO_INCREMENTAL=0` can be helpful. + +### Gathering a perf profile from a `perf.rust-lang.org` test + +Often we want to analyze a specific test from `perf.rust-lang.org`. To +do that, the first step is to clone +[the rustc-perf repository][rustc-perf-gh]: + +```bash +> git clone https://github.com/rust-lang-nursery/rustc-perf +``` + +[rustc-perf-gh]: https://github.com/rust-lang-nursery/rustc-perf + +This repo contains a bunch of stuff, but the sources for the tests are +found in [the `collector/benchmarks` directory][dir]. So let's go into +the directory of a specific test; we'll use `clap-rs` as an example: + +[dir]: https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector/benchmarks + +```bash +cd collector/benchmarks/clap-rs +``` + +In this case, let's say we want to profile the `cargo check` +performance. In that case, I would first run some basic commands to +build the dependencies: + +```bash +# Setup: first clean out any old results and build the dependencies: +cargo +rust-prof clean +CARGO_INCREMENTAL=0 cargo +rust-prof check +``` + +Next: we want record the execution time for *just* the clap-rs crate, +running cargo check. I tend to use `cargo rustc` for this, since it +also allows me to add explicit flags, which we'll do later on. + +```bash +touch src/lib.rs +CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib +``` + +Note that final command: it's a doozy! It uses the `cargo rustc` +command, which executes rustc with (potentially) additional options; +the `--profile check` and `--lib` options specify that we are doing a +`cargo check` execution, and that this is a library (not an +execution). + +At this point, we can use `perf` tooling to analyze the results. For example: + +```bash +> perf report +``` + +will open up an interactive TUI program. In simple cases, that can be +helpful. For more detailed examination, the [`perf-focus` tool][pf] +can be helpful; it is covered below. + +**A note of caution.** Each of the rustc-perf tests is its own special + snowflake. In particular, some of them are not libraries, in which + case you would want to do `touch src/main.rs` and avoid passing + `--lib`. I'm not sure how best to tell which test is which to be + honest. + +### Gathering NLL data + +If you want to profile an NLL run, you can just pass extra options to the `cargo rustc` command. The actual perf site just uses `-Zborrowck=mir`, which we can simulate like so: + +```bash +touch src/lib.rs +CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib -- -Zborrowck=mir +``` + +[pf]: https://github.com/nikomatsakis/perf-focus + +## Analyzing a perf profile with `perf focus` + +Once you've gathered a perf profile, we want to get some information +about it. For this, I personally use [perf focus][pf]. It's a kind of +simple but useful tool that lets you answer queries like: + +- "how much time was spent in function F" (no matter where it was called from) +- "how much time was spent in function F when it was called from G" +- "how much time was spent in function F *excluding* time spent in G" +- "what fns does F call and how much time does it spend in them" + +To understand how it works, you have to know just a bit about +perf. Basically, perf works by *sampling* your process on a regular +basis (or whenever some event occurs). For each sample, perf gathers a +backtrace. `perf focus` lets you write a regular expression that tests +which fns appear in that backtrace, and then tells you which +percentage of samples had a backtrace that met the regular +expression. It's probably easiest to explain by walking through how I +would analyze NLL performance. + +## Installing `perf-focus` + +You can install perf-focus using `cargo install`: + +``` +cargo install perf-focus +``` + +## Example: How much time is spent in MIR borrowck? + +Let's say we've gathered the NLL data for a test. We'd like to know +how much time it is spending in the MIR borrow-checker. The "main" +function of the MIR borrowck is called `do_mir_borrowck`, so we can do +this command: + +```bash +> perf focus '{do_mir_borrowck}' +Matcher : {do_mir_borrowck} +Matches : 228 +Not Matches: 542 +Percentage : 29% +``` + +The `'{do_mir_borrowck}'` argument is called the **matcher**. It +specifies the test to be applied on the backtrace. In this case, the +`{X}` indicates that there must be *some* function on the backtrace +that meets the regular expression `X`. In this case, that regex is +just the name of the fn we want (in fact, it's a subset of the name; +the full name includes a bunch of other stuff, like the module +path). In this mode, perf-focus just prints out the percentage of +samples where `do_mir_borrowck` was on the stack: in this case, 29%. + +**A note about c++filt.** To get the data from `perf`, `perf focus` + currently executes `perf script` (perhaps there is a better + way...). I've sometimes found that `perf script` outputs C++ mangled + names. This is annoying. You can tell by running `perf script | + head` yourself -- if you see named like `5rustc6middle` instead of + `rustc::middle`, then you have the same problem. You can solve this + by doing: + +```bash +> perf script | c++filt | perf focus --from-stdin ... +``` + +This will pipe the output from `perf script` through `c++filt` and +should mostly convert those names into a more friendly format. The +`--from-stdin` flag to `perf focus` tells it to get its data from +stdin, rather than executing `perf focus`. We should make this more +convenient (at worst, maybe add a `c++filt` option to `perf focus`, or +just always use it -- it's pretty harmless). + +## Example: How much time does MIR borrowck spend solving traits? + +Perhaps we'd like to know how much time MIR borrowck spends in the +trait checker. We can ask this using a more complex regex: + +```bash +> perf focus '{do_mir_borrowck}..{^rustc::traits}' +Matcher : {do_mir_borrowck},..{^rustc::traits} +Matches : 12 +Not Matches: 1311 +Percentage : 0% +``` + +Here we used the `..` operator to ask "how often do we have +`do_mir_borrowck` on the stack and then, later, some fn whose name +begins with `rusc::traits`?" (basically, code in that module). It +turns out the answer is "almost never" -- only 12 samples fit that +description (if you ever see *no* samples, that often indicates your +query is messed up). + +If you're curious, you can find out exactly which samples by using the +`--print-match` option. This will print out the full backtrace for +each sample. The `|` at the front of the line indicates the part that +the regular expression matched. + +## Example: Where does MIR borrowck spend its time? + +Often we want to do a more "explorational" queries. Like, we know that +MIR borrowck is 29% of the time, but where does that time get spent? +For that, the `--tree-callees` option is often the best tool. You +usually also want to give `--tree-min-percent` or +`--tree-max-depth`. The result looks like this: + +```bash +> perf focus '{do_mir_borrowck}' --tree-callees --tree-min-percent 3 +Matcher : {do_mir_borrowck} +Matches : 577 +Not Matches: 746 +Percentage : 43% + +Tree +| matched `{do_mir_borrowck}` (43% total, 0% self) +: | rustc_mir::borrow_check::nll::compute_regions (20% total, 0% self) +: : | rustc_mir::borrow_check::nll::type_check::type_check_internal (13% total, 0% self) +: : : | core::ops::function::FnOnce::call_once (5% total, 0% self) +: : : : | rustc_mir::borrow_check::nll::type_check::liveness::generate (5% total, 3% self) +: : : | as rustc::mir::visit::Visitor<'tcx>>::visit_mir (3% total, 0% self) +: | rustc::mir::visit::Visitor::visit_mir (8% total, 6% self) +: | as rustc_mir::dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (5% total, 0% self) +: | rustc_mir::dataflow::do_dataflow (3% total, 0% self) +``` + +What happens with `--tree-callees` is that + +- we find each sample matching the regular expression +- we look at the code that is occurs *after* the regex match and try to build up a call tree + +The `--tree-min-percent 3` option says "only show me things that take +more than 3% of the time. Without this, the tree often gets really +noisy and includes random stuff like the innards of +malloc. `--tree-max-depth` can be useful too, it just limits how many +levels we print. + +For each line, we display the percent of time in that function +altogether ("total") and the percent of time spent in **just that +function and not some callee of that function** (self). Usually +"total" is the more interesting number, but not always. + +### Absolute vs relative percentages + +By default, all in perf-focus are relative to the **total program +execution**. This is useful to help you keep perspective -- often as +we drill down to find hot spots, we can lose sight of the fact that, +in terms of overall program execution, this "hot spot" is actually not +important. It also ensures that percentages between different queries +are easily compared against one another. + +That said, sometimes it's useful to get relative percentages, so `perf +focus` offers a `--relative` option. In this case, the percentages are +listed only for samples that match (vs all samples). So for example we +could find out get our percentages relative to the borrowck itself +like so: + +```bash +> perf focus '{do_mir_borrowck}' --tree-callees --relative --tree-max-depth 1 --tree-min-percent 5 +Matcher : {do_mir_borrowck} +Matches : 577 +Not Matches: 746 +Percentage : 100% + +Tree +| matched `{do_mir_borrowck}` (100% total, 0% self) +: | rustc_mir::borrow_check::nll::compute_regions (47% total, 0% self) [...] +: | rustc::mir::visit::Visitor::visit_mir (19% total, 15% self) [...] +: | as rustc_mir::dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (13% total, 0% self) [...] +: | rustc_mir::dataflow::do_dataflow (8% total, 1% self) [...] +``` + +Here you see that `compute_regions` came up as "47% total" -- that +means that 47% of `do_mir_borrowck` is spent in that function. Before, +we saw 20% -- that's because `do_mir_borrowck` itself is only 43% of +the total time (and `.47 * .43 = .20`). From 5571290aac90206fbcec777a02cf2c273f6024f7 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 13:46:13 -0400 Subject: [PATCH 0315/1812] various nits from mark-i-m --- src/profiling/with_perf.md | 38 ++++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index dc767c9a5..94ce6f92f 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -1,6 +1,6 @@ # Profiling with perf -sThis is a guide for how to profile rustc with perf. +This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.org/index.php/Main_Page). ## Initial steps @@ -11,7 +11,7 @@ sThis is a guide for how to profile rustc with perf. - leave everything else the defaults - Run `./x.py build` to get a full build - Make a rustup toolchain (let's call it `rust-prof`) pointing to that result - - `rustup toolchain link` XXX + - `rustup toolchain link ` ## Gathering a perf profile @@ -29,9 +29,11 @@ perf record -F99 --call-graph dwarf XXX ``` The `-F99` tells perf to sample at 99 Hz, which avoids generating too -much data for longer runs. The `--call-graph dwarf` tells perf to get -call-graph information from debuginfo, which is accurate. The `XXX` is -the command you want to profile. So, for example, you might do: +much data for longer runs (why 99 Hz you ask? No particular reason, it +just seems to work well for me). The `--call-graph dwarf` tells perf +to get call-graph information from debuginfo, which is accurate. The +`XXX` is the command you want to profile. So, for example, you might +do: ``` perf record -F99 --call-graph dwarf cargo +rust-prof rustc @@ -42,6 +44,7 @@ to run `cargo`. But there are some things to be aware of: - You probably don't want to profile the time spend building dependencies. So something like `cargo build; cargo clean -p $C` may be helpful (where `$C` is the crate name) + - Though usually I just do `touch src/lib.rs` and rebuild instead. =) - You probably don't want incremental messing about with your profile. So something like `CARGO_INCREMENTAL=0` can be helpful. @@ -89,8 +92,7 @@ CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile ch Note that final command: it's a doozy! It uses the `cargo rustc` command, which executes rustc with (potentially) additional options; the `--profile check` and `--lib` options specify that we are doing a -`cargo check` execution, and that this is a library (not an -execution). +`cargo check` execution, and that this is a library (not a binary). At this point, we can use `perf` tooling to analyze the results. For example: @@ -110,7 +112,8 @@ can be helpful; it is covered below. ### Gathering NLL data -If you want to profile an NLL run, you can just pass extra options to the `cargo rustc` command. The actual perf site just uses `-Zborrowck=mir`, which we can simulate like so: +If you want to profile an NLL run, you can just pass extra options to +the `cargo rustc` command, like so: ```bash touch src/lib.rs @@ -128,18 +131,18 @@ simple but useful tool that lets you answer queries like: - "how much time was spent in function F" (no matter where it was called from) - "how much time was spent in function F when it was called from G" - "how much time was spent in function F *excluding* time spent in G" -- "what fns does F call and how much time does it spend in them" +- "what functions does F call and how much time does it spend in them" To understand how it works, you have to know just a bit about perf. Basically, perf works by *sampling* your process on a regular basis (or whenever some event occurs). For each sample, perf gathers a backtrace. `perf focus` lets you write a regular expression that tests -which fns appear in that backtrace, and then tells you which +which functions appear in that backtrace, and then tells you which percentage of samples had a backtrace that met the regular expression. It's probably easiest to explain by walking through how I would analyze NLL performance. -## Installing `perf-focus` +### Installing `perf-focus` You can install perf-focus using `cargo install`: @@ -147,7 +150,7 @@ You can install perf-focus using `cargo install`: cargo install perf-focus ``` -## Example: How much time is spent in MIR borrowck? +### Example: How much time is spent in MIR borrowck? Let's say we've gathered the NLL data for a test. We'd like to know how much time it is spending in the MIR borrow-checker. The "main" @@ -175,7 +178,7 @@ samples where `do_mir_borrowck` was on the stack: in this case, 29%. currently executes `perf script` (perhaps there is a better way...). I've sometimes found that `perf script` outputs C++ mangled names. This is annoying. You can tell by running `perf script | - head` yourself -- if you see named like `5rustc6middle` instead of + head` yourself -- if you see names like `5rustc6middle` instead of `rustc::middle`, then you have the same problem. You can solve this by doing: @@ -190,7 +193,7 @@ stdin, rather than executing `perf focus`. We should make this more convenient (at worst, maybe add a `c++filt` option to `perf focus`, or just always use it -- it's pretty harmless). -## Example: How much time does MIR borrowck spend solving traits? +### Example: How much time does MIR borrowck spend solving traits? Perhaps we'd like to know how much time MIR borrowck spends in the trait checker. We can ask this using a more complex regex: @@ -215,7 +218,7 @@ If you're curious, you can find out exactly which samples by using the each sample. The `|` at the front of the line indicates the part that the regular expression matched. -## Example: Where does MIR borrowck spend its time? +### Example: Where does MIR borrowck spend its time? Often we want to do a more "explorational" queries. Like, we know that MIR borrowck is 29% of the time, but where does that time get spent? @@ -258,7 +261,7 @@ altogether ("total") and the percent of time spent in **just that function and not some callee of that function** (self). Usually "total" is the more interesting number, but not always. -### Absolute vs relative percentages +### Relative percentages By default, all in perf-focus are relative to the **total program execution**. This is useful to help you keep perspective -- often as @@ -270,8 +273,7 @@ are easily compared against one another. That said, sometimes it's useful to get relative percentages, so `perf focus` offers a `--relative` option. In this case, the percentages are listed only for samples that match (vs all samples). So for example we -could find out get our percentages relative to the borrowck itself -like so: +could get our percentages relative to the borrowck itself like so: ```bash > perf focus '{do_mir_borrowck}' --tree-callees --relative --tree-max-depth 1 --tree-min-percent 5 From f1e087db37d38534ee751f3e9fe19b46c50526ee Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 13:49:29 -0400 Subject: [PATCH 0316/1812] switch to em-dash --- src/profiling/with_perf.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 94ce6f92f..9f0554e5e 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -7,7 +7,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or - Get a clean checkout of rust-lang/master, or whatever it is you want to profile. - Set the following settings in your `config.toml`: - `debuginfo-lines = true` - - `use-jemalloc = false` -- lets you do memory use profiling with valgrind + - `use-jemalloc = false` — lets you do memory use profiling with valgrind - leave everything else the defaults - Run `./x.py build` to get a full build - Make a rustup toolchain (let's call it `rust-prof`) pointing to that result @@ -117,7 +117,7 @@ the `cargo rustc` command, like so: ```bash touch src/lib.rs -CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib -- -Zborrowck=mir +CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib — -Zborrowck=mir ``` [pf]: https://github.com/nikomatsakis/perf-focus @@ -178,7 +178,7 @@ samples where `do_mir_borrowck` was on the stack: in this case, 29%. currently executes `perf script` (perhaps there is a better way...). I've sometimes found that `perf script` outputs C++ mangled names. This is annoying. You can tell by running `perf script | - head` yourself -- if you see names like `5rustc6middle` instead of + head` yourself — if you see names like `5rustc6middle` instead of `rustc::middle`, then you have the same problem. You can solve this by doing: @@ -191,7 +191,7 @@ should mostly convert those names into a more friendly format. The `--from-stdin` flag to `perf focus` tells it to get its data from stdin, rather than executing `perf focus`. We should make this more convenient (at worst, maybe add a `c++filt` option to `perf focus`, or -just always use it -- it's pretty harmless). +just always use it — it's pretty harmless). ### Example: How much time does MIR borrowck spend solving traits? @@ -209,7 +209,7 @@ Percentage : 0% Here we used the `..` operator to ask "how often do we have `do_mir_borrowck` on the stack and then, later, some fn whose name begins with `rusc::traits`?" (basically, code in that module). It -turns out the answer is "almost never" -- only 12 samples fit that +turns out the answer is "almost never" — only 12 samples fit that description (if you ever see *no* samples, that often indicates your query is messed up). @@ -264,7 +264,7 @@ function and not some callee of that function** (self). Usually ### Relative percentages By default, all in perf-focus are relative to the **total program -execution**. This is useful to help you keep perspective -- often as +execution**. This is useful to help you keep perspective — often as we drill down to find hot spots, we can lose sight of the fact that, in terms of overall program execution, this "hot spot" is actually not important. It also ensures that percentages between different queries @@ -273,7 +273,8 @@ are easily compared against one another. That said, sometimes it's useful to get relative percentages, so `perf focus` offers a `--relative` option. In this case, the percentages are listed only for samples that match (vs all samples). So for example we -could get our percentages relative to the borrowck itself like so: +could get our percentages relative to the borrowck itself +like so: ```bash > perf focus '{do_mir_borrowck}' --tree-callees --relative --tree-max-depth 1 --tree-min-percent 5 @@ -290,7 +291,7 @@ Tree : | rustc_mir::dataflow::do_dataflow (8% total, 1% self) [...] ``` -Here you see that `compute_regions` came up as "47% total" -- that +Here you see that `compute_regions` came up as "47% total" — that means that 47% of `do_mir_borrowck` is spent in that function. Before, -we saw 20% -- that's because `do_mir_borrowck` itself is only 43% of +we saw 20% — that's because `do_mir_borrowck` itself is only 43% of the total time (and `.47 * .43 = .20`). From 4e5ab2ac25c023dbc38c748fd953fb11a2c0b4d1 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 13:50:06 -0400 Subject: [PATCH 0317/1812] fix long lines --- src/profiling/with_perf.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 9f0554e5e..85dc8efd6 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -4,7 +4,8 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or ## Initial steps -- Get a clean checkout of rust-lang/master, or whatever it is you want to profile. +- Get a clean checkout of rust-lang/master, or whatever it is you want + to profile. - Set the following settings in your `config.toml`: - `debuginfo-lines = true` - `use-jemalloc = false` — lets you do memory use profiling with valgrind @@ -248,7 +249,8 @@ Tree What happens with `--tree-callees` is that - we find each sample matching the regular expression -- we look at the code that is occurs *after* the regex match and try to build up a call tree +- we look at the code that is occurs *after* the regex match and try + to build up a call tree The `--tree-min-percent 3` option says "only show me things that take more than 3% of the time. Without this, the tree often gets really From fb59bf5383e5c5f4e596f50f6056d4e9b08a1201 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 10:03:56 -0400 Subject: [PATCH 0318/1812] be consistent about bash snippets --- src/profiling/with_perf.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 85dc8efd6..61720c3b4 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -68,7 +68,7 @@ the directory of a specific test; we'll use `clap-rs` as an example: [dir]: https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector/benchmarks ```bash -cd collector/benchmarks/clap-rs +> cd collector/benchmarks/clap-rs ``` In this case, let's say we want to profile the `cargo check` @@ -77,8 +77,8 @@ build the dependencies: ```bash # Setup: first clean out any old results and build the dependencies: -cargo +rust-prof clean -CARGO_INCREMENTAL=0 cargo +rust-prof check +> cargo +rust-prof clean +> CARGO_INCREMENTAL=0 cargo +rust-prof check ``` Next: we want record the execution time for *just* the clap-rs crate, @@ -86,8 +86,8 @@ running cargo check. I tend to use `cargo rustc` for this, since it also allows me to add explicit flags, which we'll do later on. ```bash -touch src/lib.rs -CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib +> touch src/lib.rs +> CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib ``` Note that final command: it's a doozy! It uses the `cargo rustc` @@ -117,8 +117,8 @@ If you want to profile an NLL run, you can just pass extra options to the `cargo rustc` command, like so: ```bash -touch src/lib.rs -CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib — -Zborrowck=mir +> touch src/lib.rs +> CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib — -Zborrowck=mir ``` [pf]: https://github.com/nikomatsakis/perf-focus From cdc688451e4196ee426f939e69a27828a4bad645 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 10:55:46 -0400 Subject: [PATCH 0319/1812] say function, not fn --- src/profiling/with_perf.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 61720c3b4..f0f6aada9 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -170,7 +170,7 @@ The `'{do_mir_borrowck}'` argument is called the **matcher**. It specifies the test to be applied on the backtrace. In this case, the `{X}` indicates that there must be *some* function on the backtrace that meets the regular expression `X`. In this case, that regex is -just the name of the fn we want (in fact, it's a subset of the name; +just the name of the function we want (in fact, it's a subset of the name; the full name includes a bunch of other stuff, like the module path). In this mode, perf-focus just prints out the percentage of samples where `do_mir_borrowck` was on the stack: in this case, 29%. @@ -208,8 +208,8 @@ Percentage : 0% ``` Here we used the `..` operator to ask "how often do we have -`do_mir_borrowck` on the stack and then, later, some fn whose name -begins with `rusc::traits`?" (basically, code in that module). It +`do_mir_borrowck` on the stack and then, later, some function whose +name begins with `rusc::traits`?" (basically, code in that module). It turns out the answer is "almost never" — only 12 samples fit that description (if you ever see *no* samples, that often indicates your query is messed up). From 37aa15e93fab0c65e3d37282e838dbc93072d8d9 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 10:59:05 -0400 Subject: [PATCH 0320/1812] link to build-and-run, fix em-dash --- src/how-to-build-and-run.md | 8 ++++++++ src/profiling/with_perf.md | 4 ++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 557fc9148..3ad9a52ae 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -110,6 +110,8 @@ This is just a subset of the full rustc build. The **full** rustc build - Build libstd with stage2 compiler. - Build librustdoc and a bunch of other things. + + ### Creating a rustup toolchain Once you have successfully built rustc, you will have created a bunch @@ -125,6 +127,12 @@ to run the entire test suite). > rustup toolchain link stage2 build//stage2 ``` +The `` would typically be one of the following: + +- Linux: `x86_64-unknown-linux-gnu` +- Mac: `x86_64-apple-darwin` +- Windows: `x86_64-pc-windows-msvc` + Now you can run the rustc you built with. If you run with `-vV`, you should see a version number ending in `-dev`, indicating a build from your local environment: diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index f0f6aada9..740b0a263 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -12,7 +12,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or - leave everything else the defaults - Run `./x.py build` to get a full build - Make a rustup toolchain (let's call it `rust-prof`) pointing to that result - - `rustup toolchain link ` + - see [the "build and run" section for instructions](../how-to-build-and-run.html#toolchain) ## Gathering a perf profile @@ -118,7 +118,7 @@ the `cargo rustc` command, like so: ```bash > touch src/lib.rs -> CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib — -Zborrowck=mir +> CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib -- -Zborrowck=mir ``` [pf]: https://github.com/nikomatsakis/perf-focus From 9a463df8332c8b4f4afa269d1d16edd63c0ec3ce Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:00:09 -0400 Subject: [PATCH 0321/1812] don't write `rust-prof` bur rather ` --- src/profiling/with_perf.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 740b0a263..683b61d2e 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -11,7 +11,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or - `use-jemalloc = false` — lets you do memory use profiling with valgrind - leave everything else the defaults - Run `./x.py build` to get a full build -- Make a rustup toolchain (let's call it `rust-prof`) pointing to that result +- Make a rustup toolchain pointing to that result - see [the "build and run" section for instructions](../how-to-build-and-run.html#toolchain) ## Gathering a perf profile @@ -37,10 +37,11 @@ to get call-graph information from debuginfo, which is accurate. The do: ``` -perf record -F99 --call-graph dwarf cargo +rust-prof rustc +perf record -F99 --call-graph dwarf cargo + rustc ``` -to run `cargo`. But there are some things to be aware of: +to run `cargo` -- here `` should be the name of the toolchain +you made in the beginning. But there are some things to be aware of: - You probably don't want to profile the time spend building dependencies. So something like `cargo build; cargo clean -p $C` may @@ -77,10 +78,13 @@ build the dependencies: ```bash # Setup: first clean out any old results and build the dependencies: -> cargo +rust-prof clean -> CARGO_INCREMENTAL=0 cargo +rust-prof check +> cargo + clean +> CARGO_INCREMENTAL=0 cargo + check ``` +(Again, `` should be replaced with the name of the +toolchain we made in the first step.) + Next: we want record the execution time for *just* the clap-rs crate, running cargo check. I tend to use `cargo rustc` for this, since it also allows me to add explicit flags, which we'll do later on. From 85ed2e32de2151adae306651757c544ca41482b6 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:01:29 -0400 Subject: [PATCH 0322/1812] update with njn's insight --- src/profiling/with_perf.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 683b61d2e..cec17d344 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -30,11 +30,11 @@ perf record -F99 --call-graph dwarf XXX ``` The `-F99` tells perf to sample at 99 Hz, which avoids generating too -much data for longer runs (why 99 Hz you ask? No particular reason, it -just seems to work well for me). The `--call-graph dwarf` tells perf -to get call-graph information from debuginfo, which is accurate. The -`XXX` is the command you want to profile. So, for example, you might -do: +much data for longer runs (why 99 Hz you ask? It is often chosen +because it is unlikely to be in lockstep with other periodic +activity). The `--call-graph dwarf` tells perf to get call-graph +information from debuginfo, which is accurate. The `XXX` is the +command you want to profile. So, for example, you might do: ``` perf record -F99 --call-graph dwarf cargo + rustc From fcbd9b907e37065c8b8f7d5ded1005b29295d149 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:07:56 -0400 Subject: [PATCH 0323/1812] add a note about the collector executable --- src/profiling/with_perf.md | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index cec17d344..498dc1396 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -62,9 +62,35 @@ do that, the first step is to clone [rustc-perf-gh]: https://github.com/rust-lang-nursery/rustc-perf -This repo contains a bunch of stuff, but the sources for the tests are -found in [the `collector/benchmarks` directory][dir]. So let's go into -the directory of a specific test; we'll use `clap-rs` as an example: +#### Doing it the easy way + +Once you've cloned the repo, you can use the `collector` executable to +do profiling for you! You can find +[instructions in the rustc-perf readme][rustc-perf-readme]. + +[rustc-perf-readme]: https://github.com/rust-lang-nursery/rustc-perf/blob/master/collector/README.md#profiling + +For example, to measure the clap-rs test, you might do: + +``` +> ./target/release/collector \ + --output-repo /path/to/place/output \ + profile perf-record + --rustc /path/to/rustc/executable/from/your/build/directory + --cargo `which cargo` + --filter clap-rs + --builds Check +``` + +You can also use that same command to use cachegrind or other profiling tools. + +#### Doing it the hard way + +If you prefer to run things manually, that is also possible. You first +need to find the source for the test you want. Sources for the tests +are found in [the `collector/benchmarks` directory][dir]. So let's go +into the directory of a specific test; we'll use `clap-rs` as an +example: [dir]: https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector/benchmarks From 694a90c19de298bbd7188a2502bac966f7d27f6d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:29:45 -0400 Subject: [PATCH 0324/1812] fix link --- src/profiling/with_perf.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 498dc1396..be6a8a477 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -12,7 +12,9 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or - leave everything else the defaults - Run `./x.py build` to get a full build - Make a rustup toolchain pointing to that result - - see [the "build and run" section for instructions](../how-to-build-and-run.html#toolchain) + - see [the "build and run" section for instructions][b-a-r] + +[b-a-r]: ../how-to-build-and-run.html#toolchain ## Gathering a perf profile From 5665ed6a7ac8f860908c54478c5ac26854365f53 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 17:21:35 -0400 Subject: [PATCH 0325/1812] links are always relative to root or what? --- src/profiling/with_perf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index be6a8a477..c851d1a23 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -14,7 +14,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or - Make a rustup toolchain pointing to that result - see [the "build and run" section for instructions][b-a-r] -[b-a-r]: ../how-to-build-and-run.html#toolchain +[b-a-r]: ./how-to-build-and-run.html#toolchain ## Gathering a perf profile From f72ba710ab0ad5a4eed18ec2c5a56405b7f19e1c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 10 Sep 2018 14:38:11 -0400 Subject: [PATCH 0326/1812] fix various bash snippets --- src/profiling/with_perf.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index c851d1a23..7d8276ced 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -27,8 +27,8 @@ of events, though, like cache misses and so forth. The basic `perf` command is this: -``` -perf record -F99 --call-graph dwarf XXX +```bash +> perf record -F99 --call-graph dwarf XXX ``` The `-F99` tells perf to sample at 99 Hz, which avoids generating too @@ -38,8 +38,8 @@ activity). The `--call-graph dwarf` tells perf to get call-graph information from debuginfo, which is accurate. The `XXX` is the command you want to profile. So, for example, you might do: -``` -perf record -F99 --call-graph dwarf cargo + rustc +```bash +> perf record -F99 --call-graph dwarf cargo + rustc ``` to run `cargo` -- here `` should be the name of the toolchain @@ -74,9 +74,9 @@ do profiling for you! You can find For example, to measure the clap-rs test, you might do: -``` -> ./target/release/collector \ - --output-repo /path/to/place/output \ +```bash +> ./target/release/collector + --output-repo /path/to/place/output profile perf-record --rustc /path/to/rustc/executable/from/your/build/directory --cargo `which cargo` @@ -179,8 +179,8 @@ would analyze NLL performance. You can install perf-focus using `cargo install`: -``` -cargo install perf-focus +```bash +> cargo install perf-focus ``` ### Example: How much time is spent in MIR borrowck? From 732dc4782ed8d9bd771744688fe0da584cf5a6e7 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Mon, 10 Sep 2018 23:43:51 +0200 Subject: [PATCH 0327/1812] Mention incremental compilation in testing chapter The `--incremental` flag was only mentioned in [how_to_build_and_run] so far. Faster testing means faster iteration and perhaps even more added tests. [how_to_build_and_run]: https://rust-lang-nursery.github.io/rustc-guide/how-to-build-and-run.html --- src/tests/running.md | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/src/tests/running.md b/src/tests/running.md index e55b6ec7d..fdc603a54 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -59,7 +59,27 @@ Under the hood, the test runner invokes the standard rust test runner (the same one you get with `#[test]`), so this command would wind up filtering for tests that include "issue-1234" in the name. -Often, though, it's easier to just run the test by hand. Most tests are +## Using incremental compilation + +You can further enable the `--incremental` flag to save additional time in subsequent rebuilds: + +```bash +> ./x.py test --stage 1 src/test/ui --incremental --test-args issue-1234 +``` + +If you don't want to include the flag with every command, you can enable it in the `config.toml`, too: + +```toml +# Whether to always use incremental compilation when building rustc +incremental = true +``` + +Note that incremental compilation will use more disk space than usual. If disk space is a +concern for you, you might want to check the size of the `build` directory from time to time. + +## Running tests manually + +Sometimes it's easier and faster to just run the test by hand. Most tests are just `rs` files, so you can do something like ```bash From a2ad0a8eb276916b0760243a7e2a88c0c8b3e0fb Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 11:35:37 -0400 Subject: [PATCH 0328/1812] document keep-stage1 --- src/how-to-build-and-run.md | 134 +++++++++++++++++++++++++++--------- 1 file changed, 100 insertions(+), 34 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 3ad9a52ae..749340d7b 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -53,24 +53,21 @@ One thing to keep in mind is that `rustc` is a _bootstrapping_ compiler. That is, since `rustc` is written in Rust, we need to use an older version of the compiler to compile the newer version. In particular, the newer version of the compiler, `libstd`, and other tooling may use some unstable features -internally. The result is the compiling `rustc` is done in stages. - -- **Stage 0:** the stage0 compiler can be your existing - (perhaps older version of) - Rust compiler, the current _beta_ compiler or you may download the binary - from the internet. -- **Stage 1:** the code in your clone (for new version) - is then compiled with the stage0 - compiler to produce the stage1 compiler. - However, it was built with an older compiler (stage0), - so to optimize the stage1 compiler we go to next stage. -- **Stage 2:** we rebuild our stage1 compiler with itself - to produce the stage2 compiler (i.e. it builds - itself) to have all the _latest optimizations_. -- _(Optional)_ **Stage 3**: to sanity check of our new compiler, - we can build it again - with stage2 compiler which must be identical to itself, - unless something has broken. +internally. The result is the compiling `rustc` is done in stages: + +- **Stage 0:** the stage0 compiler is usually the current _beta_ compiler + (`x.py` will download it for you); you can configure `x.py` to use something + else, though. +- **Stage 1:** the code in your clone (for new version) is then + compiled with the stage0 compiler to produce the stage1 compiler. + However, it was built with an older compiler (stage0), so to + optimize the stage1 compiler we go to next stage. +- **Stage 2:** we rebuild our stage1 compiler with itself to produce + the stage2 compiler (i.e. it builds itself) to have all the _latest + optimizations_. +- _(Optional)_ **Stage 3**: to sanity check of our new compiler, we + can build it again with stage2 compiler which must be identical to + itself, unless something has broken. For hacking, often building the stage 1 compiler is enough, but for final testing and release, the stage 2 compiler is used. @@ -80,6 +77,8 @@ It is, in particular, very useful when you're doing some kind of "type-based refactoring", like renaming a method, or changing the signature of some function. + + Once you've created a config.toml, you are now ready to run `x.py`. There are a lot of options here, but let's start with what is probably the best "go to" command for building a local rust: @@ -88,27 +87,39 @@ probably the best "go to" command for building a local rust: > ./x.py build -i --stage 1 src/libstd ``` -What this command will do is the following: +This may *look* like it only builds libstd, but that is not the case. +What this command does is the following: + +- Build libstd using the stage0 compiler (using incremental) +- Build librustc using the stage0 compiler (using incremental) + - This produces the stage1 compiler +- Build libstd using the stage1 compiler (cannot use incremental) + +This final product (stage1 compiler + libs build using that compiler) +is what you need to build other rust programs. -- Using the beta compiler (also called stage 0), it will build the - standard library and rustc from the `src` directory. The resulting - compiler is called the "stage 1" compiler. - - During this build, the `-i` (or `--incremental`) switch enables incremental - compilation, so that if you later rebuild after editing things in - `src`, you can save a bit of time. -- Using this stage 1 compiler, it will build the standard library. - (this is what the `src/libstd`) means. +Note that the command includes the `-i` switch. This enables incremental +compilation. This will be used to speed up the first two steps of the process: +in particular, if you make a small change, we ought to be able to use your old +results to make producing the stage1 **compiler** faster. -This is just a subset of the full rustc build. The **full** rustc build -(what you get if you just say `./x.py build`) has quite a few more steps: +Unfortunately, incremental cannot be used to speed up making the +stage1 libraries. This is because incremental only works when you run +the *same compiler* twice in a row. In this case, we are building a +*new stage1 compiler* every time. Therefore, the old incremental +results may not apply. **As a result, you will probably find that +building the stage1 libstd is a bottleneck for you** -- but fear not, +there is a (hacky) workaround. See [the section on "recommended +workflows"](#workflow) below. -- Build stage1 rustc with stage0 compiler. -- Build libstd with stage1 compiler (up to here is the same). -- Build rustc from `src` again, this time with the stage1 compiler - (this part is new). +Note that this whole command just gives you a subset of the full rustc +build. The **full** rustc build (what you get if you just say `./x.py +build`) has quite a few more steps: + +- Build librustc rustc with the stage1 compiler. - The resulting compiler here is called the "stage2" compiler. - Build libstd with stage2 compiler. -- Build librustdoc and a bunch of other things. +- Build librustdoc and a bunch of other things with the stage2 compiler. @@ -148,6 +159,61 @@ release: 1.25.0-dev LLVM version: 4.0 ``` + + +### Suggested workflows for faster builds of the compiler + +There are two workflows that are useful for faster builders of the +compiler. + +**Check, check, and check again.** The first workflow, which is useful when doing +simple refactorings, is to run `./x.py check` continuously. Here you +are just checking that the compiler can **build**, but often that is +all you need (e.g., when renaming a method). You can then run `./x.py build` +when you acqtually need to run tests. + +In fact, it is eomtimes useful to put off tests even when you are not +100% sure the code will work. You can then keep building up +refactoring commits and only run the tests at some later time. You can +then use `git bisect` to track down **precisely** which commit caused +the problem. A nice side-effect of this style is that you are left +with a fairly fine-grained set of commits at the end, all of which +build and pass testes. This often helps reviewing. + +**Incremental builds with `--keep-stage`.** Sometimes just checking +whether the compiler builds is not enough. A common example is that +you need to add a `debug!` statement to inspect the value of some +state or better understand the problem. In that case, you really need +a full build. By leveraging incremental, though, you can often get +these builds to complete very fast (e.g., around 30 seconds): the only +catch is this requires a bit of fudging and may produce compilers that +don't work (but that is easily detected and fixed). + +The sequence of commands you want is as follows: + +- Initial build: `./x.py build -i --stage 1 src/libstd` + - As [documented above](#command), this will build a functional stage1 compiler +- Subsequent builds: `./x.py build -i --stage 1 src/libstd --keep-stage 1` + - Note that we added the `--keep-stage 1` flag here + +The effect of `--keep-stage1` is that we just *assume* that the old +standard library can be re-used. If you are editing the compiler, this +is almost always true: you haven't changed the standard library, after +all. But sometimes, it's not true: for example, if you are editing +the "metadata" part of the compiler, which controls how the compiler +encodes types and other states into the `rlib` files, or if you are editing +things that wind up in the metadata (such as the definition of the MIR). + +**The TL;DR is that you might get weird behavior from a compile when +using `--keep-stage 1`** -- for example, strange ICEs or other +panics. In that case, you should simply remove the `--keep-stage 1` +from the command and rebuild. That ought to fix the problem. + +Note: you can also use `--keep-stage 1` when running tests. Something like this: + +- Initial test run: `./x.py test -i --stage 1 src/test/ui` +- Subsequent test run: `./x.py test -i --stage 1 src/test/ui --keep-stage 1` + ### Other x.py commands Here are a few other useful x.py commands. We'll cover some of them in detail From 7d87e3cab294d564c26386bb5e579444c7369dc9 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:46:10 -0400 Subject: [PATCH 0329/1812] wrap long lines --- src/how-to-build-and-run.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 749340d7b..59c31491e 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -166,11 +166,12 @@ LLVM version: 4.0 There are two workflows that are useful for faster builders of the compiler. -**Check, check, and check again.** The first workflow, which is useful when doing -simple refactorings, is to run `./x.py check` continuously. Here you -are just checking that the compiler can **build**, but often that is -all you need (e.g., when renaming a method). You can then run `./x.py build` -when you acqtually need to run tests. +**Check, check, and check again.** The first workflow, which is useful +when doing simple refactorings, is to run `./x.py check` +continuously. Here you are just checking that the compiler can +**build**, but often that is all you need (e.g., when renaming a +method). You can then run `./x.py build` when you acqtually need to +run tests. In fact, it is eomtimes useful to put off tests even when you are not 100% sure the code will work. You can then keep building up @@ -192,7 +193,8 @@ don't work (but that is easily detected and fixed). The sequence of commands you want is as follows: - Initial build: `./x.py build -i --stage 1 src/libstd` - - As [documented above](#command), this will build a functional stage1 compiler + - As [documented above](#command), this will build a functional + stage1 compiler - Subsequent builds: `./x.py build -i --stage 1 src/libstd --keep-stage 1` - Note that we added the `--keep-stage 1` flag here From 4ab5fec4c65a4ac832b3baa541e3ef8c71d81d11 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:48:54 -0400 Subject: [PATCH 0330/1812] note about why stage1/stage2 are different --- src/how-to-build-and-run.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 59c31491e..f6c26ddf1 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -62,6 +62,15 @@ internally. The result is the compiling `rustc` is done in stages: compiled with the stage0 compiler to produce the stage1 compiler. However, it was built with an older compiler (stage0), so to optimize the stage1 compiler we go to next stage. + - (In theory, the stage1 compiler is functionally identical to the + stage2 compiler, but in practice there are subtle differences. In + particular, the stage1 compiler itself was built by stage0 and + hence not by the source in your working directory: this means that + the symbol names used in the compiler source may not match the + symbol names that would have been made by the stage1 compiler. + This can be important when using dynamic linking (e.g., with + derives. Sometimes this means that some tests don't work when run + with stage1.) - **Stage 2:** we rebuild our stage1 compiler with itself to produce the stage2 compiler (i.e. it builds itself) to have all the _latest optimizations_. From 4a6c34a1689d481c248b910141d2a3dfbd8730a2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 12:49:16 -0400 Subject: [PATCH 0331/1812] fix typos --- src/how-to-build-and-run.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index f6c26ddf1..aef5b66b8 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -179,10 +179,10 @@ compiler. when doing simple refactorings, is to run `./x.py check` continuously. Here you are just checking that the compiler can **build**, but often that is all you need (e.g., when renaming a -method). You can then run `./x.py build` when you acqtually need to +method). You can then run `./x.py build` when you actually need to run tests. -In fact, it is eomtimes useful to put off tests even when you are not +In fact, it is sometimes useful to put off tests even when you are not 100% sure the code will work. You can then keep building up refactoring commits and only run the tests at some later time. You can then use `git bisect` to track down **precisely** which commit caused From 8cbf9d0b01e57689489c4641865ea27ab9e14b07 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:13:59 -0400 Subject: [PATCH 0332/1812] fix typo, add link --- src/how-to-build-and-run.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index aef5b66b8..2285b2685 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -49,11 +49,12 @@ use-jemalloc = false ### Running x.py and building a stage1 compiler -One thing to keep in mind is that `rustc` is a _bootstrapping_ compiler. That -is, since `rustc` is written in Rust, we need to use an older version of the -compiler to compile the newer version. In particular, the newer version of the -compiler, `libstd`, and other tooling may use some unstable features -internally. The result is the compiling `rustc` is done in stages: +One thing to keep in mind is that `rustc` is a _bootstrapping_ +compiler. That is, since `rustc` is written in Rust, we need to use an +older version of the compiler to compile the newer version. In +particular, the newer version of the compiler, `libstd`, and other +tooling may use some unstable features internally. The result is that +compiling `rustc` is done in stages: - **Stage 0:** the stage0 compiler is usually the current _beta_ compiler (`x.py` will download it for you); you can configure `x.py` to use something @@ -73,10 +74,11 @@ internally. The result is the compiling `rustc` is done in stages: with stage1.) - **Stage 2:** we rebuild our stage1 compiler with itself to produce the stage2 compiler (i.e. it builds itself) to have all the _latest - optimizations_. + optimizations_. (By default, we copy the stage1 libraries for use by + the stage2 compiler, since they ought to be identical.) - _(Optional)_ **Stage 3**: to sanity check of our new compiler, we - can build it again with stage2 compiler which must be identical to - itself, unless something has broken. + can build the libraries with the stage2 compiler. The result ought + to be identical to before, unless something has broken. For hacking, often building the stage 1 compiler is enough, but for final testing and release, the stage 2 compiler is used. @@ -86,7 +88,7 @@ It is, in particular, very useful when you're doing some kind of "type-based refactoring", like renaming a method, or changing the signature of some function. - + Once you've created a config.toml, you are now ready to run `x.py`. There are a lot of options here, but let's start with what is @@ -104,8 +106,8 @@ What this command does is the following: - This produces the stage1 compiler - Build libstd using the stage1 compiler (cannot use incremental) -This final product (stage1 compiler + libs build using that compiler) -is what you need to build other rust programs. +This final product (stage1 compiler + libs built using that compiler) +is what you need to build other rust programs. Note that the command includes the `-i` switch. This enables incremental compilation. This will be used to speed up the first two steps of the process: @@ -125,7 +127,7 @@ Note that this whole command just gives you a subset of the full rustc build. The **full** rustc build (what you get if you just say `./x.py build`) has quite a few more steps: -- Build librustc rustc with the stage1 compiler. +- Build librustc and rustc with the stage1 compiler. - The resulting compiler here is called the "stage2" compiler. - Build libstd with stage2 compiler. - Build librustdoc and a bunch of other things with the stage2 compiler. @@ -168,7 +170,7 @@ release: 1.25.0-dev LLVM version: 4.0 ``` - + ### Suggested workflows for faster builds of the compiler @@ -188,7 +190,7 @@ refactoring commits and only run the tests at some later time. You can then use `git bisect` to track down **precisely** which commit caused the problem. A nice side-effect of this style is that you are left with a fairly fine-grained set of commits at the end, all of which -build and pass testes. This often helps reviewing. +build and pass tests. This often helps reviewing. **Incremental builds with `--keep-stage`.** Sometimes just checking whether the compiler builds is not enough. A common example is that @@ -216,7 +218,7 @@ encodes types and other states into the `rlib` files, or if you are editing things that wind up in the metadata (such as the definition of the MIR). **The TL;DR is that you might get weird behavior from a compile when -using `--keep-stage 1`** -- for example, strange ICEs or other +using `--keep-stage 1`** -- for example, strange [ICEs](appendix/glossary.html) or other panics. In that case, you should simply remove the `--keep-stage 1` from the command and rebuild. That ought to fix the problem. From 576581da0dd81b6d8e6e3996bc98dba455a97040 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:15:17 -0400 Subject: [PATCH 0333/1812] fix some more typos --- src/how-to-build-and-run.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 2285b2685..17c883ffc 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -209,13 +209,14 @@ The sequence of commands you want is as follows: - Subsequent builds: `./x.py build -i --stage 1 src/libstd --keep-stage 1` - Note that we added the `--keep-stage 1` flag here -The effect of `--keep-stage1` is that we just *assume* that the old +The effect of `--keep-stage 1` is that we just *assume* that the old standard library can be re-used. If you are editing the compiler, this is almost always true: you haven't changed the standard library, after all. But sometimes, it's not true: for example, if you are editing the "metadata" part of the compiler, which controls how the compiler -encodes types and other states into the `rlib` files, or if you are editing -things that wind up in the metadata (such as the definition of the MIR). +encodes types and other states into the `rlib` files, or if you are +editing things that wind up in the metadata (such as the definition of +the MIR). **The TL;DR is that you might get weird behavior from a compile when using `--keep-stage 1`** -- for example, strange [ICEs](appendix/glossary.html) or other From 4490acdbe6eeda52ae6148631798c79caa4fa20d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:16:20 -0400 Subject: [PATCH 0334/1812] remove silly `note:` --- src/how-to-build-and-run.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 17c883ffc..a4e6cc0f0 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -223,7 +223,8 @@ using `--keep-stage 1`** -- for example, strange [ICEs](appendix/glossary.html) panics. In that case, you should simply remove the `--keep-stage 1` from the command and rebuild. That ought to fix the problem. -Note: you can also use `--keep-stage 1` when running tests. Something like this: +You can also use `--keep-stage 1` when running tests. Something like +this: - Initial test run: `./x.py test -i --stage 1 src/test/ui` - Subsequent test run: `./x.py test -i --stage 1 src/test/ui --keep-stage 1` From 69cdc0a77e0d1fa6c436b5173d68c05a76ab6572 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 11 Sep 2018 12:02:46 -0400 Subject: [PATCH 0335/1812] wrap long lines --- src/how-to-build-and-run.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index a4e6cc0f0..66ba8efda 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -219,9 +219,10 @@ editing things that wind up in the metadata (such as the definition of the MIR). **The TL;DR is that you might get weird behavior from a compile when -using `--keep-stage 1`** -- for example, strange [ICEs](appendix/glossary.html) or other -panics. In that case, you should simply remove the `--keep-stage 1` -from the command and rebuild. That ought to fix the problem. +using `--keep-stage 1`** -- for example, strange +[ICEs](appendix/glossary.html) or other panics. In that case, you +should simply remove the `--keep-stage 1` from the command and +rebuild. That ought to fix the problem. You can also use `--keep-stage 1` when running tests. Something like this: From b655878d2ca05c95fe2b9b49279f4f33a1bd2214 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 11 Sep 2018 16:22:15 -0400 Subject: [PATCH 0336/1812] wrap lines in `running.md` --- src/tests/running.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index fdc603a54..d410b79c3 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -61,21 +61,24 @@ filtering for tests that include "issue-1234" in the name. ## Using incremental compilation -You can further enable the `--incremental` flag to save additional time in subsequent rebuilds: +You can further enable the `--incremental` flag to save additional +time in subsequent rebuilds: ```bash > ./x.py test --stage 1 src/test/ui --incremental --test-args issue-1234 ``` -If you don't want to include the flag with every command, you can enable it in the `config.toml`, too: +If you don't want to include the flag with every command, you can +enable it in the `config.toml`, too: ```toml # Whether to always use incremental compilation when building rustc incremental = true ``` -Note that incremental compilation will use more disk space than usual. If disk space is a -concern for you, you might want to check the size of the `build` directory from time to time. +Note that incremental compilation will use more disk space than +usual. If disk space is a concern for you, you might want to check the +size of the `build` directory from time to time. ## Running tests manually From 0ab21a2aa5bb9789ed21801026806e1a01bc3ee6 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 09:29:38 -0400 Subject: [PATCH 0337/1812] rearrange to promote the borrow checker into its own section --- src/SUMMARY.md | 4 ++-- src/{mir/borrowck.md => borrow_check.md} | 0 src/{mir/regionck.md => borrow_check/region_inference.md} | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename src/{mir/borrowck.md => borrow_check.md} (100%) rename src/{mir/regionck.md => borrow_check/region_inference.md} (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ad8a82623..e9e2ffaea 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -53,9 +53,9 @@ - [MIR construction](./mir/construction.md) - [MIR visitor and traversal](./mir/visitor.md) - [MIR passes: getting the MIR for a function](./mir/passes.md) - - [MIR borrowck](./mir/borrowck.md) - - [MIR-based region checking (NLL)](./mir/regionck.md) - [MIR optimizations](./mir/optimizations.md) +- [The borrow checker](./borrow_check.md) + - [Region inference](./borrow_check/region_inference.md) - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) diff --git a/src/mir/borrowck.md b/src/borrow_check.md similarity index 100% rename from src/mir/borrowck.md rename to src/borrow_check.md diff --git a/src/mir/regionck.md b/src/borrow_check/region_inference.md similarity index 100% rename from src/mir/regionck.md rename to src/borrow_check/region_inference.md From d453faee7a05fb4b8ea18842cbd520abcfb46dce Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 31 Aug 2018 09:57:35 -0400 Subject: [PATCH 0338/1812] add content --- src/SUMMARY.md | 3 + src/borrow_check.md | 48 ++++--- src/borrow_check/moves_and_initialization.md | 50 +++++++ .../moves_and_initialization/move_paths.md | 126 ++++++++++++++++++ src/borrow_check/region_inference.md | 4 +- src/borrow_check/type_check.md | 11 ++ 6 files changed, 218 insertions(+), 24 deletions(-) create mode 100644 src/borrow_check/moves_and_initialization.md create mode 100644 src/borrow_check/moves_and_initialization/move_paths.md create mode 100644 src/borrow_check/type_check.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index e9e2ffaea..338cb7fe1 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -55,6 +55,9 @@ - [MIR passes: getting the MIR for a function](./mir/passes.md) - [MIR optimizations](./mir/optimizations.md) - [The borrow checker](./borrow_check.md) + - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) + - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) + - [MIR type checker](./borrow_check/type_check.md) - [Region inference](./borrow_check/region_inference.md) - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) diff --git a/src/borrow_check.md b/src/borrow_check.md index d5fea6184..07095f20a 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -14,7 +14,10 @@ enforcing a number of properties: At the time of this writing, the code is in a state of transition. The "main" borrow checker still works by processing [the HIR](hir.html), but that is being phased out in favor of the MIR-based borrow checker. -Doing borrow checking on MIR has two key advantages: +Accordingly, this documentation focuses on the new, MIR-based borrow +checker. + +Doing borrow checking on MIR has several advantages: - The MIR is *far* less complex than the HIR; the radical desugaring helps prevent bugs in the borrow checker. (If you're curious, you @@ -30,30 +33,31 @@ Doing borrow checking on MIR has two key advantages: The borrow checker source is found in [the `rustc_mir::borrow_check` module][b_c]. The main entry point is -the `mir_borrowck` query. At the time of this writing, MIR borrowck can operate -in several modes, but this text will describe only the mode when NLL is enabled -(what you get with `#![feature(nll)]`). - -[b_c]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check +the [`mir_borrowck`] query. -The overall flow of the borrow checker is as follows: +[b_c]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html +[`mir_borrowck`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/fn.mir_borrowck.html - We first create a **local copy** C of the MIR. In the coming steps, we will modify this copy in place to modify the types and things to include references to the new regions that we are computing. -- We then invoke `nll::replace_regions_in_mir` to modify this copy C. - Among other things, this function will replace all of the regions in +- We then invoke [`replace_regions_in_mir`] to modify this copy C. + Among other things, this function will replace all of the [regions](./appendix/glossary.html) in the MIR with fresh [inference variables](./appendix/glossary.html). - - (More details can be found in [the regionck section](./mir/regionck.html).) -- Next, we perform a number of [dataflow - analyses](./appendix/background.html#dataflow) - that compute what data is moved and when. The results of these analyses - are needed to do both borrow checking and region inference. -- Using the move data, we can then compute the values of all the regions in the - MIR. - - (More details can be found in [the NLL section](./mir/regionck.html).) -- Finally, the borrow checker itself runs, taking as input (a) the - results of move analysis and (b) the regions computed by the region - checker. This allows us to figure out which loans are still in scope - at any particular point. - +- Next, we perform a number of + [dataflow analyses](./appendix/background.html#dataflow) that + compute what data is moved and when. +- We then do a [second type check](borrow_check/type_check.html) across the MIR: + the purpose of this type check is to determine all of the constraints between + different regions. +- Next, we do [region inference](borrow_check/region_inference.html), which computes + the values of each region -- basically, points in the control-flow graph. +- At this point, we can compute the "borrows in scope" at each point. +- Finally, we do a second walk over the MIR, looking at the actions it + does and reporting errors. For example, if we see a statement like + `*a + 1`, then we would check that the variable `a` is initialized + and that it is not mutably borrowed, as either of those would + require an error to be reported. + - Doing this check requires the results of all the previous analyses. + +[`replace_regions_in_mir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.replace_regions_in_mir.html diff --git a/src/borrow_check/moves_and_initialization.md b/src/borrow_check/moves_and_initialization.md new file mode 100644 index 000000000..6bc8cc476 --- /dev/null +++ b/src/borrow_check/moves_and_initialization.md @@ -0,0 +1,50 @@ +# Tracking moves and initialization + +Part of the borrow checker's job is to track which variables are +"initialized" at any given point in time -- this also requires +figuring out where moves occur and tracking those. + +## Initialization and moves + +From a user's perspective, initialization -- giving a variable some +value -- and moves -- transfering ownership to another place -- might +seem like distinct topics. Indeed, our borrow checker error messages +often talk about them differently. But **within the borrow checker**, +they are not nearly as separate. Roughly speaking, the borrow checker +tracks the set of "initialized places" at any point in time. Assigning +to a previously uninitialized local variable adds it to that set; +moving from a local variable removes it from that set. + +Consider this example: + +```rust +fn foo() { + let a: Vec; + + // a is not initialized yet + + a = vec![22]; + + // a is initialized here + + std::mem::drop(a); // a is moved here + + // a is no longer initialized here + + let l = a.len(); //~ ERROR +} +``` + +Here you can see that `a` starts off as uninitialized; once it is +assigned, it becomes initialized. But when `drop(a)` is called, it +becomes uninitialized again. + +## Subsections + +To make it easier to peruse, this section is broken into a number of +subsections: + +- [Move paths](./moves_and_initialization/move_paths.html the + *move path* concept that we use to track which local variables (or parts of + local variables, in some cases) are initialized. +- *Rest not yet written* =) diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md new file mode 100644 index 000000000..9d5dc3ed9 --- /dev/null +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -0,0 +1,126 @@ +# Move paths + +In reality, it's not enough to track initialization at the granularity +of local variables. Sometimes we need to track, e.g., individual fields: + +```rust +fn foo() { + let a: (Vec, Vec) = (vec![22], vec![44]); + + // a.0 and a.1 are both initialized + + let b = a.0; // moves a.0 + + // a.0 is not initializd, but a.1 still is + + let c = a.0; // ERROR + let d = a.1; // OK +} +``` + +To handle this, we track initialization at the granularity of a **move +path**. A [`MovePath`] represents some location that the user can +initialize, move, etc. So e.g. there is a move-path representing the +local variable `a`, and there is a move-path representing `a.0`. Move +paths roughly correspond to the concept of a [`Place`] from MIR, but +they are indexed in ways that enable us to do move analysis more +efficiently. + +[`MovePath`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePath.html +[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.Place.html + +## Move path indices + +Although there is a [`MovePath`] data structure, they are never +referenced directly. Instead, all the code passes around *indices* of +type +[`MovePathIndex`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/indexes/struct.MovePathIndex.html). If +you need to get information about a move path, you use this index with +the [`move_paths` field of the `MoveData`][move_paths]. For example, +to convert a [`MovePathIndex`] `mpi` into a MIR [`Place`], you might +access the [`MovePath::place`] field like so: + +```rust +move_data.move_paths[mpi].place +``` + +[move_paths]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#structfield.move_paths +[`MovePath::place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePath.html#structfield.place + +## Building move paths + +One of the first things we do in the MIR borrow check is to construct +the set of move paths. This is done as part of the +[`MoveData::gather_moves`] function. This function uses a MIR visitor +called [`Gatherer`] to walk the MIR and look at how each [`Place`] +within is accessed. For each such [`Place`], it constructs a +corresponding [`MovePathIndex`]. It also records when/where that +particular move path is moved/initialized, but we'll get to that in a +later section. + +[`Gatherer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/builder/struct.Gatherer.html +[`MoveData::gather_moves`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#method.gather_moves + +### Illegal move paths + +We don't actually move-paths for **every** [`Place`] that gets used. +In particular, if it is illegal to move from a [`Place`], then there +is no need for a [`MovePathIndex`]. Some examples: + +- You cannot move from a static variable, so we do not create a [`MovePathIndex`] + for static variables. +- You cannot move an individual element of an array, so if we have e.g. `foo: [String; 3]`, + there would be no move-path for `foo[1]`. +- You cannot move from inside of a borrowed reference, so if we have e.g. `foo: &String`, + there would be no move-path for `*foo`. + +These rules are enforced by the [`move_path_for`] function, which +converts a [`Place`] into a [`MovePathIndex`] -- in error cases like +those just discussed, the function returns an `Err`. This in turn +means we don't have to bother tracking whether those places are +initialized (which lowers overhead). + +[`move_path_for`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/builder/struct.Gatherer.html#method.move_path_for + +## Looking up a move-path + +If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], you +can do that using the [`MovePathLookup`] structure found in the [`rev_lookup`] field +of [`MoveData`]. There are two different methods: + +[`MovePathLookup`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html +[`rev_lookup`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#structfield.rev_lookup + +- [`find_local`], which takes a [`mir::Local`] representing a local + variable. This is the easier method, because we **always** create a + [`MovePathIndex`] for every local variable. +- [`find`], which takes an arbitrary [`Place`]. This method is a bit + more annoying to use, precisely because we don't have a + [`MovePathIndex`] for **every** [`Place`] (as we just discussed in + the "illegal move paths" section). Therefore, [`find`] returns a + [`LookupResult`] indicating the closest path it was able to find + that exists (e.g., for `foo[1]`, it might return just the path for + `foo`). + +[`find`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find +[`find_local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find_local +[`mir::Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Local.html +[`LookupResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/enum.LookupResult.html + +## Cross-references + +As we noted above, move-paths are stored in a big vector and +referenced via their [`MovePathIndex`]. However, within this vector, +they are also structured into a tree. So for example if you have the +[`MovePathIndex`] for `a.b.c`, you can go to its parent move-path +`a.b`. You can also iterate over all children paths: so, from `a.b`, +you might iterate to find the path `a.b.c` (here you are iterating +just over the paths that the user **actually referenced**, not all +**possible** paths the user could have done). These references are +used for example in the [`has_any_child_of`] function, which checks +whether the dataflow results contain a value for the given move-path +(e.g., `a.b`) or any child of that move-path (e.g., `a.b.c`). + +[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.Place.html +[`has_any_child_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/at_location/struct.FlowAtLocation.html#method.has_any_child_of + diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 9034af8a8..47b21b0d2 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -1,11 +1,11 @@ -# MIR-based region checking (NLL) +# Region inference (NLL) The MIR-based region checking code is located in [the `rustc_mir::borrow_check::nll` module][nll]. (NLL, of course, stands for "non-lexical lifetimes", a term that will hopefully be deprecated once they become the standard kind of lifetime.) -[nll]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check/nll +[nll]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/index.html The MIR-based region analysis consists of two major functions: diff --git a/src/borrow_check/type_check.md b/src/borrow_check/type_check.md new file mode 100644 index 000000000..10d961554 --- /dev/null +++ b/src/borrow_check/type_check.md @@ -0,0 +1,11 @@ +# The MIR type-check + +A key component of the borrow check is the +[MIR type-check](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/type_check/index.html). +This check walks the MIR and does a complete "type check" -- the same +kind you might find in any other language. In the process of doing +this type-check, we also uncover the region constraints that apply to +the program. + + + From 87382baca61ac42528a0d475b45fb700eee6378f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 11:24:24 -0400 Subject: [PATCH 0339/1812] address nits --- src/borrow_check.md | 6 +++--- src/borrow_check/moves_and_initialization.md | 12 +++++------ .../moves_and_initialization/move_paths.md | 20 ++++++++++--------- src/borrow_check/type_check.md | 3 +-- 4 files changed, 21 insertions(+), 20 deletions(-) diff --git a/src/borrow_check.md b/src/borrow_check.md index 07095f20a..40858b1b4 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -38,10 +38,10 @@ the [`mir_borrowck`] query. [b_c]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html [`mir_borrowck`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/fn.mir_borrowck.html -- We first create a **local copy** C of the MIR. In the coming steps, +- We first create a **local copy** of the MIR. In the coming steps, we will modify this copy in place to modify the types and things to include references to the new regions that we are computing. -- We then invoke [`replace_regions_in_mir`] to modify this copy C. +- We then invoke [`replace_regions_in_mir`] to modify our local MIR. Among other things, this function will replace all of the [regions](./appendix/glossary.html) in the MIR with fresh [inference variables](./appendix/glossary.html). - Next, we perform a number of @@ -51,7 +51,7 @@ the [`mir_borrowck`] query. the purpose of this type check is to determine all of the constraints between different regions. - Next, we do [region inference](borrow_check/region_inference.html), which computes - the values of each region -- basically, points in the control-flow graph. + the values of each region — basically, points in the control-flow graph. - At this point, we can compute the "borrows in scope" at each point. - Finally, we do a second walk over the MIR, looking at the actions it does and reporting errors. For example, if we see a statement like diff --git a/src/borrow_check/moves_and_initialization.md b/src/borrow_check/moves_and_initialization.md index 6bc8cc476..3801a5b8c 100644 --- a/src/borrow_check/moves_and_initialization.md +++ b/src/borrow_check/moves_and_initialization.md @@ -11,9 +11,9 @@ value -- and moves -- transfering ownership to another place -- might seem like distinct topics. Indeed, our borrow checker error messages often talk about them differently. But **within the borrow checker**, they are not nearly as separate. Roughly speaking, the borrow checker -tracks the set of "initialized places" at any point in time. Assigning -to a previously uninitialized local variable adds it to that set; -moving from a local variable removes it from that set. +tracks the set of "initialized places" at any point in the source +code. Assigning to a previously uninitialized local variable adds it +to that set; moving from a local variable removes it from that set. Consider this example: @@ -36,8 +36,8 @@ fn foo() { ``` Here you can see that `a` starts off as uninitialized; once it is -assigned, it becomes initialized. But when `drop(a)` is called, it -becomes uninitialized again. +assigned, it becomes initialized. But when `drop(a)` is called, that +moves `a` into the call, and hence it becomes uninitialized again. ## Subsections @@ -47,4 +47,4 @@ subsections: - [Move paths](./moves_and_initialization/move_paths.html the *move path* concept that we use to track which local variables (or parts of local variables, in some cases) are initialized. -- *Rest not yet written* =) +- TODO *Rest not yet written* =) diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index 9d5dc3ed9..7a1239db1 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -1,7 +1,8 @@ # Move paths In reality, it's not enough to track initialization at the granularity -of local variables. Sometimes we need to track, e.g., individual fields: +of local variables. Rust also allows us to do moves and initialization +at the field granularity: ```rust fn foo() { @@ -63,9 +64,9 @@ later section. ### Illegal move paths -We don't actually move-paths for **every** [`Place`] that gets used. -In particular, if it is illegal to move from a [`Place`], then there -is no need for a [`MovePathIndex`]. Some examples: +We don't actually create a move-path for **every** [`Place`] that gets +used. In particular, if it is illegal to move from a [`Place`], then +there is no need for a [`MovePathIndex`]. Some examples: - You cannot move from a static variable, so we do not create a [`MovePathIndex`] for static variables. @@ -115,11 +116,12 @@ they are also structured into a tree. So for example if you have the [`MovePathIndex`] for `a.b.c`, you can go to its parent move-path `a.b`. You can also iterate over all children paths: so, from `a.b`, you might iterate to find the path `a.b.c` (here you are iterating -just over the paths that the user **actually referenced**, not all -**possible** paths the user could have done). These references are -used for example in the [`has_any_child_of`] function, which checks -whether the dataflow results contain a value for the given move-path -(e.g., `a.b`) or any child of that move-path (e.g., `a.b.c`). +just over the paths that are **actually referenced** in the source, +not all **possible** paths that could have been referenced). These +references are used for example in the [`has_any_child_of`] function, +which checks whether the dataflow results contain a value for the +given move-path (e.g., `a.b`) or any child of that move-path (e.g., +`a.b.c`). [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.Place.html [`has_any_child_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/at_location/struct.FlowAtLocation.html#method.has_any_child_of diff --git a/src/borrow_check/type_check.md b/src/borrow_check/type_check.md index 10d961554..ee955d971 100644 --- a/src/borrow_check/type_check.md +++ b/src/borrow_check/type_check.md @@ -7,5 +7,4 @@ kind you might find in any other language. In the process of doing this type-check, we also uncover the region constraints that apply to the program. - - +TODO -- elaborate further? Maybe? :) From d2cecbf3cd162fbc842dc3c66c8bec702f2f648f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Fri, 7 Sep 2018 17:23:47 -0400 Subject: [PATCH 0340/1812] fix glossary links --- src/appendix/glossary.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index bfc2c0d22..42315536a 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -40,7 +40,7 @@ MIR | the Mid-level IR that is created after type-checking miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](./traits/associated-types.html#normalize) newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -NLL | [non-lexical lifetimes](./mir/regionck.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. +NLL | [non-lexical lifetimes](./borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. obligation | something that must be proven by the trait system ([see more](traits/resolution.html)) projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](./traits/goals-and-clauses.html#trait-ref) @@ -53,7 +53,7 @@ rib | a data structure in the name resolver that keeps trac sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir/regionck.html#skol) for more details. +skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./borrow_check/region_inference.html#skol) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) From a72a0687227651f8eb90e4c996535e90f849ebd2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 10 Sep 2018 14:34:48 -0400 Subject: [PATCH 0341/1812] bump max line length to 100 otherwise our summary.md doesn't fit --- .travis.yml | 2 +- ci/check_line_lengths.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index d7f8f8f42..55ea20587 100644 --- a/.travis.yml +++ b/.travis.yml @@ -3,7 +3,7 @@ cache: - cargo before_install: - shopt -s globstar -- MAX_LINE_LENGTH=80 bash ci/check_line_lengths.sh src/**/*.md +- MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true - bash ci/install.sh diff --git a/ci/check_line_lengths.sh b/ci/check_line_lengths.sh index 91f199b7e..5b7b12d3e 100755 --- a/ci/check_line_lengths.sh +++ b/ci/check_line_lengths.sh @@ -2,7 +2,7 @@ if [ "$1" == "--help" ]; then echo 'Usage:' - echo ' MAX_LINE_LENGTH=80' "$0" 'src/**/*.md' + echo ' MAX_LINE_LENGTH=100' "$0" 'src/**/*.md' exit 1 fi From a6284183f8b69094513da8ac7528268b4eb8255d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 11 Sep 2018 16:43:36 -0400 Subject: [PATCH 0342/1812] ignore various sample tests --- src/borrow_check/moves_and_initialization.md | 2 +- src/borrow_check/moves_and_initialization/move_paths.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/borrow_check/moves_and_initialization.md b/src/borrow_check/moves_and_initialization.md index 3801a5b8c..d1cd41e0f 100644 --- a/src/borrow_check/moves_and_initialization.md +++ b/src/borrow_check/moves_and_initialization.md @@ -17,7 +17,7 @@ to that set; moving from a local variable removes it from that set. Consider this example: -```rust +```rust,ignore fn foo() { let a: Vec; diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index 7a1239db1..c9e22a81c 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -4,7 +4,7 @@ In reality, it's not enough to track initialization at the granularity of local variables. Rust also allows us to do moves and initialization at the field granularity: -```rust +```rust,ignore fn foo() { let a: (Vec, Vec) = (vec![22], vec![44]); @@ -41,7 +41,7 @@ the [`move_paths` field of the `MoveData`][move_paths]. For example, to convert a [`MovePathIndex`] `mpi` into a MIR [`Place`], you might access the [`MovePath::place`] field like so: -```rust +```rust,ignore move_data.move_paths[mpi].place ``` From c4ac71e1d057ee6f65484aa516e4b9ddf59e3f9a Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 11 Sep 2018 07:36:49 +0200 Subject: [PATCH 0343/1812] Fix typos These were fixed using [codespell](https://github.com/codespell-project/codespell). --- src/appendix/glossary.md | 4 ++-- src/borrow_check/region_inference.md | 4 ++-- src/codegen.md | 6 +++--- src/compiletest.md | 2 +- src/lowering.md | 2 +- src/macro-expansion.md | 6 +++--- src/rustdoc.md | 2 +- src/traits/canonicalization.md | 2 +- src/traits/lowering-rules.md | 2 +- src/traits/resolution.md | 2 +- 10 files changed, 16 insertions(+), 16 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 42315536a..44ac26ca3 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -14,7 +14,7 @@ codegen unit | when we produce LLVM IR, we group the Rust code into completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./appendix/background.html#cfg) CTFE | Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](./const-eval.html)) -cx | we tend to use "cx" as an abbrevation for context. See also `tcx`, `infcx`, etc. +cx | we tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./appendix/background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. @@ -34,7 +34,7 @@ inference variable | when doing type or region inference, an "inference va infcx | the inference context (see `librustc/infer`) IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. local crate | the crate currently being compiled. -LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optmizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] +LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. MIR | the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](./mir/index.html)) miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 47b21b0d2..2cd6066ec 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -23,7 +23,7 @@ The MIR-based region analysis consists of two major functions: won't be doing lexical region inference at all. - `compute_regions`, invoked second: this is given as argument the results of move analysis. It has the job of computing values for all - the inference variabes that `replace_regions_in_mir` introduced. + the inference variables that `replace_regions_in_mir` introduced. - To do that, it first runs the [MIR type checker](#mirtypeck). This is basically a normal type-checker but specialized to MIR, which is much simpler than full Rust of course. Running the MIR type @@ -531,7 +531,7 @@ then we have this constraint `V2: V3`, so we wind up having to enlarge V2 in U2 = {skol(1), skol(2)} ``` -Now contraint propagation is done, but when we check the outlives +Now constraint propagation is done, but when we check the outlives relationships, we find that `V2` includes this new element `skol(1)`, so we report an error. diff --git a/src/codegen.md b/src/codegen.md index 6e68db6ea..766dfff59 100644 --- a/src/codegen.md +++ b/src/codegen.md @@ -10,7 +10,7 @@ generates an executable binary. rustc uses LLVM for code generation. ## What is LLVM? -All of the preceeding chapters of this guide have one thing in common: we never +All of the preceding chapters of this guide have one thing in common: we never generated any executable machine code at all! With this chapter, all of that changes. @@ -29,14 +29,14 @@ many compiler projects, including the `clang` C compiler and our beloved LLVM's "format `X`" is called LLVM IR. It is basically assembly code with additional low-level types and annotations added. These annotations are helpful -for doing optimizations on the LLVM IR and outputed machine code. The end +for doing optimizations on the LLVM IR and outputted machine code. The end result of all this is (at long last) something executable (e.g. an ELF object or wasm). There are a few benefits to using LLVM: - We don't have to write a whole compiler backend. This reduces implementation - and maintainance burden. + and maintenance burden. - We benefit from the large suite of advanced optimizations that the LLVM project has been collecting. - We automatically can compile Rust to any of the platforms for which LLVM has diff --git a/src/compiletest.md b/src/compiletest.md index 40d06136e..3cfb943b0 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -115,7 +115,7 @@ which make it simple to parse common patterns like simple presence or not attribute is defined (`has_cfg_prefix()`) and many more. The low-level parsers are found near the end of the `impl Config` block; be sure to look through them and their associated parsers immediately above to see how they are used to -avoid writing additional parsing code unneccessarily. +avoid writing additional parsing code unnecessarily. As a concrete example, here is the implementation for the `parse_failure_status()` parser, in diff --git a/src/lowering.md b/src/lowering.md index eddc00af9..2504ed491 100644 --- a/src/lowering.md +++ b/src/lowering.md @@ -36,7 +36,7 @@ sanity checks in `src/librustc/hir/map/hir_id_validator.rs`: for you so you also get the `HirId`. If you are creating new `DefId`s, since each `DefId` needs to have a -corresponding `NodeId`, it is adviseable to add these `NodeId`s to the +corresponding `NodeId`, it is advisable to add these `NodeId`s to the `AST` so you don't have to generate new ones during lowering. This has the advantage of creating a way to find the `DefId` of something via its `NodeId`. If lowering needs this `DefId` in multiple places, you can't diff --git a/src/macro-expansion.md b/src/macro-expansion.md index bb3116d40..b03a218c2 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -90,13 +90,13 @@ tokens containing the inside of the example invocation `print foo`, while `ms` might be the sequence of token (trees) `print $mvar:ident`. The output of the parser is a `NamedParseResult`, which indicates which of -three cases has occured: +three cases has occurred: - Success: `tts` matches the given matcher `ms`, and we have produced a binding from metavariables to the corresponding token trees. - Failure: `tts` does not match `ms`. This results in an error message such as "No rule expected token _blah_". -- Error: some fatal error has occured _in the parser_. For example, this happens +- Error: some fatal error has occurred _in the parser_. For example, this happens if there are more than one pattern match, since that indicates the macro is ambiguous. @@ -112,7 +112,7 @@ the macro parser. This is extremely non-intuitive and self-referential. The code to parse macro _definitions_ is in [`src/libsyntax/ext/tt/macro_rules.rs`][code_mr]. It defines the pattern for matching for a macro definition as `$( $lhs:tt => $rhs:tt );+`. In other words, -a `macro_rules` defintion should have in its body at least one occurence of a +a `macro_rules` definition should have in its body at least one occurrence of a token tree followed by `=>` followed by another token tree. When the compiler comes to a `macro_rules` definition, it uses this pattern to match the two token trees per rule in the definition of the macro _using the macro parser itself_. diff --git a/src/rustdoc.md b/src/rustdoc.md index 76a8b28ce..318a8e2e1 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -30,7 +30,7 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) ## Cheat sheet -* Use `./x.py build --stage 1 src/libstd src/tools/rustdoc` to make a useable +* Use `./x.py build --stage 1 src/libstd src/tools/rustdoc` to make a usable rustdoc you can run on other projects. * Add `src/libtest` to be able to use `rustdoc --test`. * If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1` diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md index 1ef1da717..2cc35d899 100644 --- a/src/traits/canonicalization.md +++ b/src/traits/canonicalization.md @@ -56,7 +56,7 @@ for { ?0: Foo<'?1, ?2> } This `for<>` gives some information about each of the canonical variables within. In this case, each `T` indicates a type variable, -so `?0` and `?2` are types; the `L` indicates a lifetime varibale, so +so `?0` and `?2` are types; the `L` indicates a lifetime variable, so `?1` is a lifetime. The `canonicalize` method *also* gives back a `CanonicalVarValues` array OV with the "original values" for each canonicalized variable: diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index e37999e57..41c9625f6 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -10,7 +10,7 @@ reference the [domain goals][dg] defined in an earlier section. ## Notation The nonterminal `Pi` is used to mean some generic *parameter*, either a -named lifetime like `'a` or a type paramter like `A`. +named lifetime like `'a` or a type parameter like `A`. The nonterminal `Ai` is used to mean some generic *argument*, which might be a lifetime like `'a` or a type like `Vec`. diff --git a/src/traits/resolution.md b/src/traits/resolution.md index e33e0c8ec..987d9a28d 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -117,7 +117,7 @@ know whether an impl/where-clause applies or not – this occurs when the obligation contains unbound inference variables. The subroutines that decide whether a particular impl/where-clause/etc -applies to a particular obligation are collectively refered to as the +applies to a particular obligation are collectively referred to as the process of _matching_. At the moment, this amounts to unifying the `Self` types, but in the future we may also recursively consider some of the nested obligations, in the case of an impl. From 5ec3e1a6206fefba98139ca069435ff4b759d045 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 11 Sep 2018 07:47:13 +0200 Subject: [PATCH 0344/1812] Fix line lengths --- src/macro-expansion.md | 6 +++--- src/tests/running.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index b03a218c2..c62301247 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -96,9 +96,9 @@ three cases has occurred: from metavariables to the corresponding token trees. - Failure: `tts` does not match `ms`. This results in an error message such as "No rule expected token _blah_". -- Error: some fatal error has occurred _in the parser_. For example, this happens - if there are more than one pattern match, since that indicates the macro is - ambiguous. +- Error: some fatal error has occurred _in the parser_. For example, this + happens if there are more than one pattern match, since that indicates + the macro is ambiguous. The full interface is defined [here][code_parse_int]. diff --git a/src/tests/running.md b/src/tests/running.md index d410b79c3..778fd00ec 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -76,9 +76,9 @@ enable it in the `config.toml`, too: incremental = true ``` -Note that incremental compilation will use more disk space than -usual. If disk space is a concern for you, you might want to check the -size of the `build` directory from time to time. +Note that incremental compilation will use more disk space than usual. +If disk space is a concern for you, you might want to check the size +of the `build` directory from time to time. ## Running tests manually From 6e7e4d2d35e871e538152b2dfde2265dd662d1a9 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 20 Aug 2018 11:15:35 -0500 Subject: [PATCH 0345/1812] use mdbook 0.2 --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index 29e3a2f9b..dc413f68c 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -20,5 +20,5 @@ function cargo_install() { fi } -cargo_install mdbook 0.1.8 +cargo_install mdbook 0.2 cargo_install mdbook-linkcheck 0.1.2 From 5e7d9f6b4226c1b13d6b1bbc1b4585b3cce7e173 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 20 Aug 2018 11:19:02 -0500 Subject: [PATCH 0346/1812] update readme with mdbook version --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a01758d48..57b3a0ea4 100644 --- a/README.md +++ b/README.md @@ -38,4 +38,4 @@ be found. > cargo install mdbook-linkcheck ``` You will need `mdbook` version `>= 0.1`. `linkcheck` will be run automatically -when you run `mdbook build`. +when you run `mdbook build`. We are currently using `mdbook 0.2`. From 5ca9b3b3260a33b784eab6d299b8a864620ab5e1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 8 Sep 2018 21:35:59 -0500 Subject: [PATCH 0347/1812] Fix all the links to be relative for mdbook 2 --- src/appendix/background.md | 2 +- src/appendix/code-index.md | 26 ++++++------- src/appendix/glossary.md | 58 ++++++++++++++-------------- src/borrow_check/region_inference.md | 8 ++-- src/mir/index.md | 6 +-- src/mir/passes.md | 4 +- src/tests/intro.md | 8 ++-- src/traits/associated-types.md | 4 +- src/traits/caching.md | 8 ++-- src/traits/canonical-queries.md | 10 ++--- src/traits/canonicalization.md | 10 ++--- src/traits/chalk-overview.md | 12 +++--- src/traits/goals-and-clauses.md | 14 +++---- src/traits/index.md | 14 +++---- src/traits/lowering-module.md | 4 +- src/traits/lowering-rules.md | 10 ++--- src/traits/lowering-to-logic.md | 4 +- src/traits/resolution.md | 4 +- 18 files changed, 103 insertions(+), 103 deletions(-) diff --git a/src/appendix/background.md b/src/appendix/background.md index efdce4f2a..dbfe6a3db 100644 --- a/src/appendix/background.md +++ b/src/appendix/background.md @@ -94,7 +94,7 @@ and Michael I. Schwartzbach is an incredible resource! Check out the subtyping chapter from the [Rust Nomicon](https://doc.rust-lang.org/nomicon/subtyping.html). -See the [variance](./variance.html) chapter of this guide for more info on how +See the [variance](../variance.html) chapter of this guide for more info on how the type checker handles variance. diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 75d35c6c5..e1bde6863 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -29,16 +29,16 @@ Item | Kind | Short description | Chapter | `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) -[The HIR]: hir.html -[Identifiers in the HIR]: hir.html#hir-id -[The parser]: the-parser.html -[The Rustc Driver]: rustc-driver.html -[Type checking]: type-checking.html -[The `ty` modules]: ty.html -[Rustdoc]: rustdoc.html -[Emitting Diagnostics]: diag.html -[Macro expansion]: macro-expansion.html -[Name resolution]: name-resolution.html -[Parameter Environment]: param_env.html -[Trait Solving: Goals and Clauses]: traits/goals-and-clauses.html#domain-goals -[Trait Solving: Lowering impls]: traits/lowering-rules.html#lowering-impls +[The HIR]: ../hir.html +[Identifiers in the HIR]: ../hir.html#hir-id +[The parser]: ../the-parser.html +[The Rustc Driver]: ../rustc-driver.html +[Type checking]: ../type-checking.html +[The `ty` modules]: ../ty.html +[Rustdoc]: ../rustdoc.html +[Emitting Diagnostics]: ../diag.html +[Macro expansion]: ../macro-expansion.html +[Name resolution]: ../name-resolution.html +[Parameter Environment]: ../param_env.html +[Trait Solving: Goals and Clauses]: ../traits/goals-and-clauses.html#domain-goals +[Trait Solving: Lowering impls]: ../traits/lowering-rules.html#lowering-impls diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 44ac26ca3..5c7d82741 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -7,25 +7,25 @@ them better. Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. -binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./appendix/background.html#free-vs-bound) -bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./appendix/background.html#free-vs-bound) +binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) +bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen | the code to translate MIR into LLVM IR. codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). -control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./appendix/background.html#cfg) -CTFE | Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](./const-eval.html)) +control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) +CTFE | Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) cx | we tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. -DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](incremental-compilation.html)) -data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./appendix/background.html#dataflow) +DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../incremental-compilation.html)) +data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. Double pointer | a pointer with additional metadata. See "fat pointer" for more. DST | Dynamically-Sized Type. A type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). empty type | see "uninhabited type". Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". -free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./appendix/background.html#free-vs-bound) -'gcx | the lifetime of the global arena ([see more](ty.html)) +free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) +'gcx | the lifetime of the global arena ([see more](../ty.html)) generics | the set of generic type parameters defined on a type or item -HIR | the High-level IR, created by lowering and desugaring the AST ([see more](hir.html)) +HIR | the High-level IR, created by lowering and desugaring the AST ([see more](../hir.html)) HirId | identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. ICE | internal compiler error. When the compiler crashes. @@ -36,39 +36,39 @@ IR | Intermediate Representation. A general term in compil local crate | the crate currently being compiled. LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. -MIR | the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](./mir/index.html)) -miri | an interpreter for MIR used for constant evaluation ([see more](./miri.html)) -normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](./traits/associated-types.html#normalize) +MIR | the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](../mir/index.html)) +miri | an interpreter for MIR used for constant evaluation ([see more](../miri.html)) +normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize) newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -NLL | [non-lexical lifetimes](./borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. +NLL | [non-lexical lifetimes](../borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. -obligation | something that must be proven by the trait system ([see more](traits/resolution.html)) -projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](./traits/goals-and-clauses.html#trait-ref) -promoted constants | constants extracted from a function and lifted to static scope; see [this section](./mir/index.html#promoted) for more details. -provider | the function that executes a query ([see more](query.html)) -quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./appendix/background.html#quantified) -query | perhaps some sub-computation during compilation ([see more](query.html)) +obligation | something that must be proven by the trait system ([see more](../traits/resolution.html)) +projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref) +promoted constants | constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. +provider | the function that executes a query ([see more](../query.html)) +quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified) +query | perhaps some sub-computation during compilation ([see more](../query.html)) region | another term for "lifetime" often used in the literature and in the borrow checker. -rib | a data structure in the name resolver that keeps track of a single scope for names. ([see more](./name-resolution.html)) +rib | a data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./borrow_check/region_inference.html#skol) for more details. +skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](../borrow_check/region_inference.html#skol) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) -tcx | the "typing context", main data structure of the compiler ([see more](ty.html)) -'tcx | the lifetime of the currently active inference context ([see more](ty.html)) -trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](./traits/goals-and-clauses.html#trait-ref)) -token | the smallest unit of parsing. Tokens are produced after lexing ([see more](the-parser.html)). +tcx | the "typing context", main data structure of the compiler ([see more](../ty.html)) +'tcx | the lifetime of the currently active inference context ([see more](../ty.html)) +trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](../traits/goals-and-clauses.html#trait-ref)) +token | the smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. trans | the code to translate MIR into LLVM IR. Renamed to codegen. -trait reference | a trait and values for its type parameters ([see more](ty.html)). -ty | the internal representation of a type ([see more](ty.html)). -UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](type-checking.html)). +trait reference | a trait and values for its type parameters ([see more](../ty.html)). +ty | the internal representation of a type ([see more](../ty.html)). +UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](../type-checking.html)). uninhabited type | a type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". upvar | a variable captured by a closure from outside the closure. -variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./appendix/background.html#variance) for a more general explanation. See the [variance chapter](./variance.html) for an explanation of how type checking handles variance. +variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance. Wide pointer | a pointer with additional metadata. See "fat pointer" for more. ZST | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 2cd6066ec..5a09f0bb0 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -35,7 +35,7 @@ The MIR-based region analysis consists of two major functions: - More details to come, though the [NLL RFC] also includes fairly thorough (and hopefully readable) coverage. -[fvb]: appendix/background.html#free-vs-bound +[fvb]: ../appendix/background.html#free-vs-bound [NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html ## Universal regions @@ -131,7 +131,7 @@ the type of `foo` the type `bar` expects We handle this sort of subtyping by taking the variables that are bound in the supertype and **skolemizing** them: this means that we replace them with -[universally quantified](appendix/background.html#quantified) +[universally quantified](../appendix/background.html#quantified) representatives, written like `!1`. We call these regions "skolemized regions" – they represent, basically, "some unknown region". @@ -148,7 +148,7 @@ what we wanted. So let's work through what happens next. To check if two functions are subtypes, we check if their arguments have the desired relationship -(fn arguments are [contravariant](./appendix/background.html#variance), so +(fn arguments are [contravariant](../appendix/background.html#variance), so we swap the left and right here): ```text @@ -187,7 +187,7 @@ Here, the root universe would consist of the lifetimes `'static` and the same concept to types, in which case the types `Foo` and `T` would be in the root universe (along with other global types, like `i32`). Basically, the root universe contains all the names that -[appear free](./appendix/background.html#free-vs-bound) in the body of `bar`. +[appear free](../appendix/background.html#free-vs-bound) in the body of `bar`. Now let's extend `bar` a bit by adding a variable `x`: diff --git a/src/mir/index.md b/src/mir/index.md index ea72decdc..d69606d66 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -1,7 +1,7 @@ # The MIR (Mid-level IR) MIR is Rust's _Mid-level Intermediate Representation_. It is -constructed from [HIR](./hir.html). MIR was introduced in +constructed from [HIR](../hir.html). MIR was introduced in [RFC 1211]. It is a radically simplified form of Rust that is used for certain flow-sensitive safety checks – notably the borrow checker! – and also for optimization and code generation. @@ -26,7 +26,7 @@ Some of the key characteristics of MIR are: - It does not have nested expressions. - All types in MIR are fully explicit. -[cfg]: ./appendix/background.html#cfg +[cfg]: ../appendix/background.html#cfg ## Key MIR vocabulary @@ -244,4 +244,4 @@ but [you can read about those below](#promoted)). [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir [mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir -[newtype'd]: appendix/glossary.html +[newtype'd]: ../appendix/glossary.html diff --git a/src/mir/passes.md b/src/mir/passes.md index c48ef4576..7dc1249a0 100644 --- a/src/mir/passes.md +++ b/src/mir/passes.md @@ -156,7 +156,7 @@ then `mir_const_qualif(D)` would succeed if it came before `mir_validated(D)`, but fail otherwise. Therefore, `mir_validated(D)` will **force** `mir_const_qualif` before it actually steals, thus ensuring that the reads have already happened (remember that -[queries are memoized](./query.html), so executing a query twice +[queries are memoized](../query.html), so executing a query twice simply loads from a cache the second time): ```text @@ -174,4 +174,4 @@ alternatives in [rust-lang/rust#41710]. [rust-lang/rust#41710]: https://github.com/rust-lang/rust/issues/41710 [mirtransform]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/ [`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/no_landing_pads/struct.NoLandingPads.html -[MIR visitor]: mir/visitor.html +[MIR visitor]: ./visitor.html diff --git a/src/tests/intro.md b/src/tests/intro.md index bfe084618..8b2937f9f 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -5,8 +5,8 @@ by the build system (`x.py test`). The main test harness for testing the compiler itself is a tool called compiletest (sources in the [`src/tools/compiletest`]). This section gives a brief overview of how the testing framework is setup, and then gets into some of the details -on [how to run tests](./tests/running.html#ui) as well as -[how to add new tests](./tests/adding.html). +on [how to run tests](./running.html#ui) as well as +[how to add new tests](./adding.html). [`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest @@ -24,7 +24,7 @@ Here is a brief summary of the test suites as of this writing and what they mean. In some cases, the test suites are linked to parts of the manual that give more details. -- [`ui`](./tests/adding.html#ui) – tests that check the exact +- [`ui`](./adding.html#ui) – tests that check the exact stdout/stderr from compilation and/or running the test - `run-pass` – tests that are expected to compile and execute successfully (no panics) @@ -59,7 +59,7 @@ including: - **Tidy** – This is a custom tool used for validating source code style and formatting conventions, such as rejecting long lines. There is more information in the - [section on coding conventions](./conventions.html#formatting). + [section on coding conventions](../conventions.html#formatting). Example: `./x.py test src/tools/tidy` diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md index 1972a70e6..b8ac7f8b9 100644 --- a/src/traits/associated-types.md +++ b/src/traits/associated-types.md @@ -17,7 +17,7 @@ type can be referenced by the user using an **associated type projection** like ` as IntoIterator>::Item`. (Often, though, people will use the shorthand syntax `T::Item` – presently, that syntax is expanded during -["type collection"](./type-checking.html) into the explicit form, +["type collection"](../type-checking.html) into the explicit form, though that is something we may want to change in the future.) [intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item @@ -130,7 +130,7 @@ any given associated item. Now we are ready to discuss how associated type equality integrates with unification. As described in the -[type inference](./type-inference.html) section, unification is +[type inference](../type-inference.html) section, unification is basically a procedure with a signature like this: ```text diff --git a/src/traits/caching.md b/src/traits/caching.md index 228ff0917..f84539509 100644 --- a/src/traits/caching.md +++ b/src/traits/caching.md @@ -24,7 +24,7 @@ On the other hand, if there is no hit, we need to go through the [selection process] from scratch. Suppose, we come to the conclusion that the only possible impl is this one, with def-id 22: -[selection process]: ./traits/resolution.html#selection +[selection process]: ./resolution.html#selection ```rust,ignore impl Foo for usize { ... } // Impl #22 @@ -34,7 +34,7 @@ We would then record in the cache `usize : Foo<$0> => ImplCandidate(22)`. Next we would [confirm] `ImplCandidate(22)`, which would (as a side-effect) unify `$t` with `isize`. -[confirm]: ./traits/resolution.html#confirmation +[confirm]: ./resolution.html#confirmation Now, at some later time, we might come along and see a `usize : Foo<$u>`. When skolemized, this would yield `usize : Foo<$0>`, just as @@ -61,7 +61,7 @@ to be pretty clearly safe and also still retains a very high hit rate **TODO**: it looks like `pick_candidate_cache` no longer exists. In general, is this section still accurate at all? -[`ParamEnv`]: ./param_env.html -[`tcx`]: ./ty.html +[`ParamEnv`]: ../param_env.html +[`tcx`]: ../ty.html [#18290]: https://github.com/rust-lang/rust/issues/18290 [#22019]: https://github.com/rust-lang/rust/issues/22019 diff --git a/src/traits/canonical-queries.md b/src/traits/canonical-queries.md index c58fe3696..876c5d8a6 100644 --- a/src/traits/canonical-queries.md +++ b/src/traits/canonical-queries.md @@ -3,11 +3,11 @@ The "start" of the trait system is the **canonical query** (these are both queries in the more general sense of the word – something you would like to know the answer to – and in the -[rustc-specific sense](./query.html)). The idea is that the type +[rustc-specific sense](../query.html)). The idea is that the type checker or other parts of the system, may in the course of doing their thing want to know whether some trait is implemented for some type (e.g., is `u32: Debug` true?). Or they may want to -[normalize some associated type](./traits/associated-types.html). +[normalize some associated type](./associated-types.html). This section covers queries at a fairly high level of abstraction. The subsections look a bit more closely at how these ideas are implemented @@ -106,7 +106,7 @@ value for a type variable, that means that this is the **only possible instantiation** that you could use, given the current set of impls and where-clauses, that would be provable. (Internally within the solver, though, they can potentially enumerate all possible answers. See -[the description of the SLG solver](./traits/slg.html) for details.) +[the description of the SLG solver](./slg.html) for details.) The response to a trait query in rustc is typically a `Result, NoSolution>` (where the `T` will vary a bit @@ -132,7 +132,7 @@ we did find. It consists of four parts: - **Region constraints:** these are relations that must hold between the lifetimes that you supplied as inputs. We'll ignore these here, but see the - [section on handling regions in traits](./traits/regions.html) for + [section on handling regions in traits](./regions.html) for more details. - **Value:** The query result also comes with a value of type `T`. For some specialized queries – like normalizing associated types – @@ -219,7 +219,7 @@ As a result of this assignment, the type of `u` is forced to be `Option>`, where `?V` represents the element type of the vector. This in turn implies that `?U` is [unified] to `Vec`. -[unified]: ./type-checking.html +[unified]: ../type-checking.html Let's suppose that the type checker decides to revisit the "as-yet-unproven" trait obligation we saw before, `Vec: diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md index 2cc35d899..df0c4a2b9 100644 --- a/src/traits/canonicalization.md +++ b/src/traits/canonicalization.md @@ -6,7 +6,7 @@ from its context. It is a key part of implementing to get more context. Canonicalization is really based on a very simple concept: every -[inference variable](./type-inference.html#vars) is always in one of +[inference variable](../type-inference.html#vars) is always in one of two states: either it is **unbound**, in which case we don't know yet what type it is, or it is **bound**, in which case we do. So to isolate some data-structure T that contains types/regions from its @@ -16,7 +16,7 @@ starting from zero and numbered in a fixed order (left to right, for the most part, but really it doesn't matter as long as it is consistent). -[cq]: ./traits/canonical-queries.html +[cq]: ./canonical-queries.html So, for example, if we have the type `X = (?T, ?U)`, where `?T` and `?U` are distinct, unbound inference variables, then the canonical @@ -41,7 +41,7 @@ trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound. This query contains two unbound variables, but it also contains the lifetime `'static`. The trait system generally ignores all lifetimes and treats them equally, so when canonicalizing, we will *also* -replace any [free lifetime](./appendix/background.html#free-vs-bound) with a +replace any [free lifetime](../appendix/background.html#free-vs-bound) with a canonical variable. Therefore, we get the following result: ```text @@ -98,12 +98,12 @@ Remember that substitution S though! We're going to need it later. OK, now that we have a fresh inference context and an instantiated query, we can go ahead and try to solve it. The trait solver itself is -explained in more detail in [another section](./traits/slg.html), but +explained in more detail in [another section](./slg.html), but suffice to say that it will compute a [certainty value][cqqr] (`Proven` or `Ambiguous`) and have side-effects on the inference variables we've created. For example, if there were only one impl of `Foo`, like so: -[cqqr]: ./traits/canonical-queries.html#query-response +[cqqr]: ./canonical-queries.html#query-response ```rust,ignore impl<'a, X> Foo<'a, X> for Vec diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index e737edcd9..818e1dc4d 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -131,18 +131,18 @@ See [The SLG Solver][slg]. [rustc-issues]: https://github.com/rust-lang-nursery/rustc-guide/issues [chalk]: https://github.com/rust-lang-nursery/chalk -[lowering-to-logic]: traits/lowering-to-logic.html -[lowering-rules]: traits/lowering-rules.html +[lowering-to-logic]: ./lowering-to-logic.html +[lowering-rules]: ./lowering-rules.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification -[lowering-forall]: ./traits/lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses +[lowering-forall]: ./lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses [programclause]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L721 [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause -[goals-and-clauses]: ./traits/goals-and-clauses.html +[goals-and-clauses]: ./goals-and-clauses.html [well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir/lowering.rs#L230-L232 [ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/ir.rs -[HIR]: hir.html +[HIR]: ../hir.html [binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 [rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 -[slg]: ./traits/slg.html +[slg]: ./slg.html diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index 93bafe33f..5aa3755ad 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -2,7 +2,7 @@ In logic programming terms, a **goal** is something that you must prove and a **clause** is something that you know is true. As -described in the [lowering to logic](./traits/lowering-to-logic.html) +described in the [lowering to logic](./lowering-to-logic.html) chapter, Rust's trait solver is based on an extension of hereditary harrop (HH) clauses, which extend traditional Prolog Horn clauses with a few new superpowers. @@ -37,7 +37,7 @@ paper ["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] gives the details. -[pphhf]: ./traits/bibliography.html#pphhf +[pphhf]: ./bibliography.html#pphhf @@ -94,7 +94,7 @@ e.g. `ProjectionEq::Item = u8` The given associated type `Projection` is equal to `Type`; this can be proved with either normalization or using skolemized types. See [the section -on associated types](./traits/associated-types.html). +on associated types](./associated-types.html). #### Normalize(Projection -> Type) e.g. `ProjectionEq::Item -> u8` @@ -102,12 +102,12 @@ e.g. `ProjectionEq::Item -> u8` The given associated type `Projection` can be [normalized][n] to `Type`. As discussed in [the section on associated -types](./traits/associated-types.html), `Normalize` implies `ProjectionEq`, +types](./associated-types.html), `Normalize` implies `ProjectionEq`, but not vice versa. In general, proving `Normalize(::Item -> U)` also requires proving `Implemented(T: Trait)`. -[n]: ./traits/associated-types.html#normalize -[at]: ./traits/associated-types.html +[n]: ./associated-types.html#normalize +[at]: ./associated-types.html #### FromEnv(TraitRef), FromEnv(Projection = Type) e.g. `FromEnv(Self: Add)` @@ -212,7 +212,7 @@ In addition to auto traits, `WellFormed` predicates are co-inductive. These are used to achieve a similar "enumerate all the cases" pattern, as described in the section on [implied bounds]. -[implied bounds]: ./traits/lowering-rules.html#implied-bounds +[implied bounds]: ./lowering-rules.html#implied-bounds ## Incomplete chapter diff --git a/src/traits/index.md b/src/traits/index.md index c070d1b88..c5afb280b 100644 --- a/src/traits/index.md +++ b/src/traits/index.md @@ -4,7 +4,7 @@ [process of being implemented][wg]; this chapter serves as a kind of in-progress design document. If you would prefer to read about how the current trait solver works, check out -[this other chapter](./traits/resolution.html). (By the way, if you +[this other chapter](./resolution.html). (By the way, if you would like to help in hacking on the new solver, you will find instructions for getting involved in the [Traits Working Group tracking issue][wg].) 🚧 @@ -13,20 +13,20 @@ instructions for getting involved in the Trait solving is based around a few key ideas: -- [Lowering to logic](./traits/lowering-to-logic.html), which expresses +- [Lowering to logic](./lowering-to-logic.html), which expresses Rust traits in terms of standard logical terms. - - The [goals and clauses](./traits/goals-and-clauses.html) chapter + - The [goals and clauses](./goals-and-clauses.html) chapter describes the precise form of rules we use, and - [lowering rules](./traits/lowering-rules.html) gives the complete set of + [lowering rules](./lowering-rules.html) gives the complete set of lowering rules in a more reference-like form. -- [Canonical queries](./traits/canonical-queries.html), which allow us +- [Canonical queries](./canonical-queries.html), which allow us to solve trait problems (like "is `Foo` implemented for the type `Bar`?") once, and then apply that same result independently in many different inference contexts. -- [Lazy normalization](./traits/associated-types.html), which is the +- [Lazy normalization](./associated-types.html), which is the technique we use to accommodate associated types when figuring out whether types are equal. -- [Region constraints](./traits/regions.html), which are accumulated +- [Region constraints](./regions.html), which are accumulated during trait solving but mostly ignored. This means that trait solving effectively ignores the precise regions involved, always – but we still remember the constraints on them so that those diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md index 030e19860..c9c4accc1 100644 --- a/src/traits/lowering-module.md +++ b/src/traits/lowering-module.md @@ -1,7 +1,7 @@ # The lowering module in rustc The program clauses described in the -[lowering rules](./traits/lowering-rules.html) section are actually +[lowering rules](./lowering-rules.html) section are actually created in the [`rustc_traits::lowering`][lowering] module. [lowering]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_traits/lowering/ @@ -16,7 +16,7 @@ query is invoked on a `DefId` that identifies something like a trait, an impl, or an associated item definition. It then produces and returns a vector of program clauses. -[query]: ./query.html +[query]: ../query.html diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index 41c9625f6..218164c0f 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -4,8 +4,8 @@ This section gives the complete lowering rules for Rust traits into [program clauses][pc]. It is a kind of reference. These rules reference the [domain goals][dg] defined in an earlier section. -[pc]: ./traits/goals-and-clauses.html -[dg]: ./traits/goals-and-clauses.html#domain-goals +[pc]: ./goals-and-clauses.html +[dg]: ./goals-and-clauses.html#domain-goals ## Notation @@ -16,7 +16,7 @@ The nonterminal `Ai` is used to mean some generic *argument*, which might be a lifetime like `'a` or a type like `Vec`. When defining the lowering rules, we will give goals and clauses in -the [notation given in this section](./traits/goals-and-clauses.html). +the [notation given in this section](./goals-and-clauses.html). We sometimes insert "macros" like `LowerWhereClause!` into these definitions; these macros reference other sections within this chapter. @@ -141,7 +141,7 @@ This `WellFormed` rule states that `T: Trait` is well-formed if (a) `T: Trait` is implemented and (b) all the where-clauses declared on `Trait` are well-formed (and hence they are implemented). Remember that the `WellFormed` predicate is -[coinductive](./traits/goals-and-clauses.html#coinductive); in this +[coinductive](./goals-and-clauses.html#coinductive); in this case, it is serving as a kind of "carrier" that allows us to enumerate all the where clauses that are transitively implied by `T: Trait`. @@ -266,7 +266,7 @@ where WC We will produce a number of program clauses. The first two define the rules by which `ProjectionEq` can succeed; these two clauses are discussed -in detail in the [section on associated types](./traits/associated-types.html), +in detail in the [section on associated types](./associated-types.html), but reproduced here for reference: ```text diff --git a/src/traits/lowering-to-logic.md b/src/traits/lowering-to-logic.md index cf8c1c25a..a0490adf3 100644 --- a/src/traits/lowering-to-logic.md +++ b/src/traits/lowering-to-logic.md @@ -170,8 +170,8 @@ example Gopalan Nadathur's excellent ["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] in [the bibliography]. -[the bibliography]: ./traits/bibliography.html -[pphhf]: ./traits/bibliography.html#pphhf +[the bibliography]: ./bibliography.html +[pphhf]: ./bibliography.html#pphhf It turns out that supporting FOHH is not really all that hard. And once we are able to do that, we can easily describe the type-checking diff --git a/src/traits/resolution.md b/src/traits/resolution.md index 987d9a28d..2ba451677 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -6,7 +6,7 @@ some non-obvious things. **Note:** This chapter (and its subchapters) describe how the trait solver **currently** works. However, we are in the process of designing a new trait solver. If you'd prefer to read about *that*, -see [*this* traits chapter](./traits/index.html). +see [*this* traits chapter](./index.html). ## Major concepts @@ -220,7 +220,7 @@ in that list. If so, it is considered satisfied. More precisely, we want to check whether there is a where-clause obligation that is for the same trait (or some subtrait) and which can match against the obligation. -[parameter environment]: ./param_env.html +[parameter environment]: ../param_env.html Consider this simple example: From ba5c94015df6c8c7d746e0a2121fc303ec0e2b2e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 8 Sep 2018 21:37:07 -0500 Subject: [PATCH 0348/1812] use new mdbook-linkcheck version --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index dc413f68c..eca1b5cdf 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -21,4 +21,4 @@ function cargo_install() { } cargo_install mdbook 0.2 -cargo_install mdbook-linkcheck 0.1.2 +cargo_install mdbook-linkcheck 0.2.1 From f013b867c5eafab3ebee94da59ffee9cbcade232 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 8 Sep 2018 21:38:07 -0500 Subject: [PATCH 0349/1812] update readme --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 57b3a0ea4..2a59a40bb 100644 --- a/README.md +++ b/README.md @@ -37,5 +37,6 @@ be found. ```bash > cargo install mdbook-linkcheck ``` -You will need `mdbook` version `>= 0.1`. `linkcheck` will be run automatically -when you run `mdbook build`. We are currently using `mdbook 0.2`. + +You will need `mdbook` version `>= 0.2`. `linkcheck` will be run automatically +when you run `mdbook build`. From 32c6280c71f58f5628d0b0f98aa8b74d9a883f85 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 12 Sep 2018 21:55:06 -0500 Subject: [PATCH 0350/1812] check web links --- book.toml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/book.toml b/book.toml index ecbe513b7..8c13fa1aa 100644 --- a/book.toml +++ b/book.toml @@ -5,6 +5,7 @@ description = "A guide to developing rustc" [output.html] -[output.linkcheck] - [output.html.search] + +[output.linkcheck] +follow-web-links = true From d36f89182d79055ae268f8bfdcb98cb9995f95c7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 12 Sep 2018 22:01:44 -0500 Subject: [PATCH 0351/1812] fix the last link --- src/profiling/with_perf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 7d8276ced..258899400 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -14,7 +14,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or - Make a rustup toolchain pointing to that result - see [the "build and run" section for instructions][b-a-r] -[b-a-r]: ./how-to-build-and-run.html#toolchain +[b-a-r]: ../how-to-build-and-run.html#toolchain ## Gathering a perf profile From ac194d428aa55d4f8289890b08f66b0968b41b9f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 21 Sep 2018 14:36:11 -0500 Subject: [PATCH 0352/1812] don't check crates.io links --- book.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/book.toml b/book.toml index 8c13fa1aa..93e40ef50 100644 --- a/book.toml +++ b/book.toml @@ -9,3 +9,4 @@ description = "A guide to developing rustc" [output.linkcheck] follow-web-links = true +exclude = [ "crates\\.io" ] From 9297caaac337c49f2c3903c255171469f37155ed Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 21 Sep 2018 15:09:45 -0500 Subject: [PATCH 0353/1812] Fix all the links! --- book.toml | 2 +- src/appendix/stupid-stats.md | 17 +++++++++++------ src/const-eval.md | 2 +- src/diag.md | 2 +- src/miri.md | 2 +- src/tests/intro.md | 2 +- src/traits/chalk-overview.md | 2 +- 7 files changed, 17 insertions(+), 12 deletions(-) diff --git a/book.toml b/book.toml index 93e40ef50..b9092a969 100644 --- a/book.toml +++ b/book.toml @@ -9,4 +9,4 @@ description = "A guide to developing rustc" [output.linkcheck] follow-web-links = true -exclude = [ "crates\\.io" ] +exclude = [ "crates\\.io", "gcc\\.godbolt\\.org" ] diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md index 842a2a328..a36cac42b 100644 --- a/src/appendix/stupid-stats.md +++ b/src/appendix/stupid-stats.md @@ -74,7 +74,7 @@ and a bunch of other crates with the 'librustc_' prefix. Next is translation, this translates the AST (and all those side tables) into LLVM IR (intermediate representation). We do this by calling into the LLVM libraries, rather than actually writing IR directly to a file. The code for -this is in [librustc_trans](https://github.com/rust-lang/rust/tree/master/src/librustc_trans). +this is in librustc_trans. The next phase is running the LLVM backend. This runs LLVM's optimisation passes on the generated IR and then generates machine code. The result is object files. @@ -83,17 +83,22 @@ interface between LLVM and rustc is in [librustc_llvm](https://github.com/rust-l Finally, we link the object files into an executable. Again we outsource this to other programs and it's not really part of the rust compiler. The interface is -in [librustc_back](https://github.com/rust-lang/rust/tree/master/src/librustc_back) -(which also contains some things used primarily during translation). +in librustc_back (which also contains some things used primarily during +translation). + +> NOTE: `librustc_trans` and `librustc_back` no longer exist, and we don't +> translate AST or HIR directly to LLVM IR anymore. Instead, see +> [`librustc_codegen_llvm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/index.html) +> and [`librustc_codegen_utils`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_utils/index.html). All these phases are coordinated by the driver. To see the exact sequence, look at [the `compile_input` function in `librustc_driver`][compile-input]. -The driver handles all the highest level coordination of compilation - - 1. handling command-line arguments +The driver handles all the highest level coordination of compilation - + 1. handling command-line arguments 2. maintaining compilation state (primarily in the `Session`) 3. calling the appropriate code to run each phase of compilation 4. handles high level coordination of pretty printing and testing. -To create a drop-in compiler replacement or a compiler replacement, +To create a drop-in compiler replacement or a compiler replacement, we leave most of compilation alone and customise the driver using its APIs. [compile-input]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/fn.compile_input.html diff --git a/src/const-eval.md b/src/const-eval.md index 70c946f17..1f801fb22 100644 --- a/src/const-eval.md +++ b/src/const-eval.md @@ -35,4 +35,4 @@ integer or fat pointer, it will directly yield the value (via `Value::ByVal` or memory allocation (via `Value::ByRef`). This means that the `const_eval` function cannot be used to create miri-pointers to the evaluated constant or static. If you need that, you need to directly work with the functions in -[src/librustc_mir/interpret/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/const_eval/). +[src/librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html). diff --git a/src/diag.md b/src/diag.md index b30ec2eca..936420ab6 100644 --- a/src/diag.md +++ b/src/diag.md @@ -304,5 +304,5 @@ lints we want to emit. Instead, the [`BufferedEarlyLintId`] type is used. If you are defining a new lint, you will want to add an entry to this enum. Then, add an appropriate mapping to the body of [`Lint::from_parser_lint_id`][fplid]. -[`BufferedEarlyLintId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/early_buffered_lints/struct.BufferedEarlyLintId.html +[`BufferedEarlyLintId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/early_buffered_lints/enum.BufferedEarlyLintId.html [fplid]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.Lint.html#from_parser_lint_id diff --git a/src/miri.md b/src/miri.md index be9587408..a3c7b3ff4 100644 --- a/src/miri.md +++ b/src/miri.md @@ -112,7 +112,7 @@ to a pointer to `b`. Although the main entry point to constant evaluation is the `tcx.const_eval` query, there are additional functions in -[librustc_mir/interpret/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/const_eval/) +[librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html) that allow accessing the fields of a `Value` (`ByRef` or otherwise). You should never have to access an `Allocation` directly except for translating it to the compilation target (at the moment just LLVM). diff --git a/src/tests/intro.md b/src/tests/intro.md index 8b2937f9f..4d509f3a8 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -171,7 +171,7 @@ communicate with the server to coordinate running tests (see ## Crater [Crater](https://github.com/rust-lang-nursery/crater) is a tool for compiling -and running tests for _every_ crate on [crates.io](https://crates.io/) (and a +and running tests for _every_ crate on [crates.io](https://crates.io) (and a few on GitHub). It is mainly used for checking for extent of breakage when implementing potentially breaking changes and ensuring lack of breakage by running beta vs stable compiler versions. diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 818e1dc4d..3473a0764 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -141,7 +141,7 @@ See [The SLG Solver][slg]. [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause [goals-and-clauses]: ./goals-and-clauses.html [well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir/lowering.rs#L230-L232 -[ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/ir.rs +[ir-code]: https://github.com/rust-lang-nursery/chalk/tree/master/chalk-ir [HIR]: ../hir.html [binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 [rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 From 766a5e354dd6bf5a50fe67dbcadff8814284ea1a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 21 Sep 2018 15:28:41 -0500 Subject: [PATCH 0354/1812] use the right version of mdbook linkcheck --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index eca1b5cdf..80f8de4e8 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -21,4 +21,4 @@ function cargo_install() { } cargo_install mdbook 0.2 -cargo_install mdbook-linkcheck 0.2.1 +cargo_install mdbook-linkcheck 0.2 From 8871bd77b9169b09e0da7dd598e259b53c79e1a6 Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Thu, 27 Sep 2018 09:27:30 -0600 Subject: [PATCH 0355/1812] Document no-system-llvm --- src/tests/adding.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index b9f05b9dd..1120315b9 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -158,6 +158,7 @@ source. this test; see also `ignore-gdb-version` * `min-lldb-version` specifies the minimum lldb version required for this test +* `no-system-llvm` causes the test to be ignored if the system llvm is used * `min-llvm-version` specifies the minimum llvm version required for this test * `min-system-llvm-version` specifies the minimum system llvm version From 946e11a5787f34cdf26699b31be0badae4a71179 Mon Sep 17 00:00:00 2001 From: Alcaro Date: Sat, 29 Sep 2018 00:03:40 +0200 Subject: [PATCH 0356/1812] conventions: Fix semicolon/colon typo --- src/conventions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conventions.md b/src/conventions.md index 93c5c44be..d392ebd57 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -69,7 +69,7 @@ for something that you want to get back to before you land your PR: ```rust,ignore fn do_something() { if something_else { - unimplemented!(): // TODO write this + unimplemented!(); // TODO write this } } ``` From d3b0eaed0114bfc76e72882b46dd0c4035b61977 Mon Sep 17 00:00:00 2001 From: David Sanders Date: Fri, 28 Sep 2018 18:47:52 -0700 Subject: [PATCH 0357/1812] Typo nits #181 (#205) --- src/hir.md | 2 +- src/lowering.md | 4 ++-- src/traits/canonical-queries.md | 2 +- src/traits/canonicalization.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/hir.md b/src/hir.md index a5e99e8b3..e6bca7f37 100644 --- a/src/hir.md +++ b/src/hir.md @@ -81,7 +81,7 @@ sorts of identifiers in active use: about the crate (such as its version number, as two versions of the same crate can co-exist). - A [`DefId`] really consists of two parts, a `CrateNum` (which - identifies the crate) and a `DefIndex` (which indixes into a list + identifies the crate) and a `DefIndex` (which indexes into a list of items that is maintained per crate). - [`HirId`], which combines the index of a particular item with an offset within that item. diff --git a/src/lowering.md b/src/lowering.md index 2504ed491..c3a1a96cc 100644 --- a/src/lowering.md +++ b/src/lowering.md @@ -25,7 +25,7 @@ sanity checks in `src/librustc/hir/map/hir_id_validator.rs`: any `NodeId`s in the `HIR` are checked for existing `HirId`s) 2. Lowering a `HirId` must be done in the scope of the *owning* item. This means you need to use `with_hir_id_owner` if you are creating parts - of another item than the one being currently lowered. This happens for + of an item other than the one being currently lowered. This happens for example during the lowering of existential `impl Trait` 3. A `NodeId` that will be placed into a HIR structure must be lowered, even if its `HirId` is unused. Calling @@ -45,4 +45,4 @@ generate a new `NodeId` in all those places because you'd also get a new Having the `NodeId` also allows the `DefCollector` to generate the `DefId`s instead of lowering having to do it on the fly. Centralizing the `DefId` -generation in one place makes it easier to refactor and reason about. \ No newline at end of file +generation in one place makes it easier to refactor and reason about. diff --git a/src/traits/canonical-queries.md b/src/traits/canonical-queries.md index 876c5d8a6..cbf7d880d 100644 --- a/src/traits/canonical-queries.md +++ b/src/traits/canonical-queries.md @@ -143,7 +143,7 @@ we did find. It consists of four parts: Let's work through an example query to see what all the parts mean. Consider [the `Borrow` trait][borrow]. This trait has a number of -impls; among them, there are these two (for clarify, I've written the +impls; among them, there are these two (for clarity, I've written the `Sized` bounds explicitly): [borrow]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md index df0c4a2b9..62c4d9f74 100644 --- a/src/traits/canonicalization.md +++ b/src/traits/canonicalization.md @@ -29,7 +29,7 @@ they are repeated. We use this to improve caching as well as to detect cycles and other things during trait resolution. Roughly speaking, the idea is that if -two trait queries have the same canonicalize form, then they will get +two trait queries have the same canonical form, then they will get the same answer. That answer will be expressed in terms of the canonical variables (`?0`, `?1`), which we can then map back to the original variables (`?T`, `?U`). From 0f65024f26eab7607ef7f4f51da8354fc15ac5e7 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 6 Sep 2018 20:13:36 -0400 Subject: [PATCH 0358/1812] issue-130 copy contents related x.py from rust-forge --- src/build-install-distribution-artifacts.md | 27 +++++++++++ src/compiler-benchmarking.md | 11 +++++ src/compiler-documenting.md | 49 ++++++++++++++++++++ src/how-to-build-and-run.md | 51 ++++++++++++++++++++- src/tests/running.md | 23 ++++++++++ src/what-is-x-py.md | 42 +++++++++++++++++ 6 files changed, 201 insertions(+), 2 deletions(-) create mode 100644 src/build-install-distribution-artifacts.md create mode 100644 src/compiler-benchmarking.md create mode 100644 src/compiler-documenting.md create mode 100644 src/what-is-x-py.md diff --git a/src/build-install-distribution-artifacts.md b/src/build-install-distribution-artifacts.md new file mode 100644 index 000000000..472c074a3 --- /dev/null +++ b/src/build-install-distribution-artifacts.md @@ -0,0 +1,27 @@ +# Build distribution artifacts + +You might want to build and package up the compiler for distribution. +You’ll want to run this command to do it: + + `./x.py dist` + +Other Flags + +The same flags from build are available here. +You might want to consider adding on the -j flag for faster builds +when building a distribution artifact. + +``` +-j, --jobs JOBS number of jobs to run in parallel +``` + + +# Install distribution artifacts + +If you’ve built a distribution artifact you might want to install it and +test that it works on your target system. You’ll want to run this command: + + `./x.py install` + +Other Flags +The same flags from build are available \ No newline at end of file diff --git a/src/compiler-benchmarking.md b/src/compiler-benchmarking.md new file mode 100644 index 000000000..1ce1e05ac --- /dev/null +++ b/src/compiler-benchmarking.md @@ -0,0 +1,11 @@ +# Benchmarking rustc + +This one is a easier compared to the others. +All you’re doing is running benchmarks of the compiler itself +so it’ll build it and run the one set of benchmarks available to it. +The command is: + + `./x.py bench` + +Benchmarking lacks `--no-fail-fast` flag that `test` command has. + \ No newline at end of file diff --git a/src/compiler-documenting.md b/src/compiler-documenting.md new file mode 100644 index 000000000..919914e98 --- /dev/null +++ b/src/compiler-documenting.md @@ -0,0 +1,49 @@ +# Documenting rustc + +You might want to build documentation of the various components +available like the standard library. There’s two ways to go about this. + You can run rustdoc directly on the file to make sure the HTML is + correct which is fast or you can build the documentation as part of the + build process through x.py. Both are viable methods since documentation + is more about the content. + +## Document everything + + `./x.py doc` + +## If you want to avoid the whole Stage 2 build + + `./x.py doc --stage 1` + +First the compiler and rustdoc get built to make sure everything is okay +and then it documents the files. + +## Document specific components + +```bash + ./x.py doc src/doc/book + ./x.py doc src/doc/nomicon + ./x.py doc src/doc/book src/libstd +``` + +Much like individual tests or building certain components you can build only + the documentation you want. + +## Document internal rustc items +By default rustc does not build the compiler docs for its internal items. +Mostly because this is useless for the average user. However, you might need +to have it available so you can understand the types. Here’s how you can +compile it yourself. From the top level directory where x.py is located run: + + cp config.toml.example config.toml + +Next open up config.toml and make sure these two lines are set to true: + +docs = true +compiler-docs = true +When you want to build the compiler docs as well run this command: + + `./x.py doc` + +This will see that the docs and compiler-docs options are set to true +and build the normally hidden compiler docs! \ No newline at end of file diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 66ba8efda..07a5eeb4d 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -134,6 +134,44 @@ build`) has quite a few more steps: +### Build different stages + + `./x.py build --stage 0` + + # Stage 1 is typically enough to test out all of your changes + # to the compiler + + `./x.py build --stage 1` + + # Equivalent to ./x.py build + + `./x.py build --stage 2` + +You can pass the --stage flag with what stage you want to build to. +It is recommended that you build to Stage 1 as this is enough to know +your changes can successfully compile and should let you run tests +with your changes. + +### Build specific components + + Build only the libcore library + + `./x.py build src/libcore` + + Build the libcore and libproc_macro library only + + `./x.py build src/libcore src/libproc_macro` + + Build only libcore up to Stage 1 + + `./x.py build src/libcore --stage 1` + +Sometimes you might just want to test if the part you’re working on can +compile. Using these commands you can test that it compiles before doing +a bigger build to make sure it works with the compiler. As shown before +you can also pass flags at the end such as --stage. + + ### Creating a rustup toolchain Once you have successfully built rustc, you will have created a bunch @@ -145,8 +183,8 @@ you will likely need to build at some point; for example, if you want to run the entire test suite). ```bash -> rustup toolchain link stage1 build//stage1 -> rustup toolchain link stage2 build//stage2 + rustup toolchain link stage1 build//stage1 + rustup toolchain link stage2 build//stage2 ``` The `` would typically be one of the following: @@ -263,3 +301,12 @@ This allows you to do "jump-to-def" with whatever functions were around when you last built, which is ridiculously useful. [etags]: https://github.com/nikomatsakis/rust-etags + +### Cleaning out build directories + +Sometimes you need to start fresh, but this is normally not the case. +If you need to run this then rustbuild is most likely not acting right and +you should file a bug as to what is going wrong. If you do need to clean +everything up then you only need to run one command! + + `./x.py clean` \ No newline at end of file diff --git a/src/tests/running.md b/src/tests/running.md index 778fd00ec..970829cce 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -93,3 +93,26 @@ This is much faster, but doesn't always work. For example, some tests include directives that specify specific compiler flags, or which rely on other crates, and they may not run the same without those options. +### Run specific tests + +# Run only the tidy script +```bash +> ./x.py test src/tools/tidy +``` +# Run tests on the standard library +```bash +> ./x.py test src/libstd +``` + +# Run tests on the standard library and run the tidy script +```bash +> ./x.py test src/libstd src/tools/tidy +``` + +# Run tests on the standard library using a stage 1 compiler +```bash +> ./x.py test src/libstd --stage 1 +``` + +By listing which test suites you want to run you avoid having to run tests for +components you did not change at all. diff --git a/src/what-is-x-py.md b/src/what-is-x-py.md new file mode 100644 index 000000000..315a3f821 --- /dev/null +++ b/src/what-is-x-py.md @@ -0,0 +1,42 @@ +# what is x.py? + +x.py is the script used to orchestrate the tooling in the rustc repository. +It is the script that can build docs, run tests, and compile rustc. +It is the now preferred way to build rustc and it replaces the old makefiles +from before. Below are the different ways to utilize x.py in order to +effectively deal with the repo for various common tasks. + +### Build Flags + +There are other flags you can pass to the build portion of x.py that can be +beneficial to cutting down compile times or fitting other things you might +need to change. They are: + +``` +Options: + -v, --verbose use verbose output (-vv for very verbose) + -i, --incremental use incremental compilation + --config FILE TOML configuration file for build + --build BUILD build target of the stage0 compiler + --host HOST host targets to build + --target TARGET target targets to build + --on-fail CMD command to run on failure + --stage N stage to build + --keep-stage N stage to keep without recompiling + --src DIR path to the root of the rust checkout + -j, --jobs JOBS number of jobs to run in parallel + -h, --help print this help message +``` + +Note that the options --incremental, --keep-stage 0 and --jobs JOBS can be +used in tandem with --stage to help reduce build times significantly by +reusing already built components, reusing the first bootstrapped stage, and +running compilation in parallel. To test changes you could run something like: + +```bash + ./x.py build --stage 1 --keep-stage 0 -j 4 -i +``` + +Please follow the links to build, document, test, benchmark and install +distribution + artifacts for rustc respectively. From 062e158a676fa751d4c42b27b2485e68c169df60 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Tue, 18 Sep 2018 17:29:59 -0400 Subject: [PATCH 0359/1812] issue-130 incorporate the review comments --- src/SUMMARY.md | 2 + src/build-install-distribution-artifacts.md | 15 ++-- src/compiler-documenting.md | 25 ++++-- src/how-to-build-and-run.md | 92 +++++++++++++++------ src/tests/running.md | 10 +-- src/what-is-x-py.md | 42 ---------- 6 files changed, 100 insertions(+), 86 deletions(-) delete mode 100644 src/what-is-x-py.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 338cb7fe1..213a645ab 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -3,6 +3,8 @@ - [About this guide](./about-this-guide.md) - [About the compiler team](./compiler-team.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) + - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) + - [Documenting Compiler](./compiler-documenting.md) - [Coding conventions](./conventions.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [The compiler testing framework](./tests/intro.md) diff --git a/src/build-install-distribution-artifacts.md b/src/build-install-distribution-artifacts.md index 472c074a3..89b1422a0 100644 --- a/src/build-install-distribution-artifacts.md +++ b/src/build-install-distribution-artifacts.md @@ -3,15 +3,17 @@ You might want to build and package up the compiler for distribution. You’ll want to run this command to do it: - `./x.py dist` + ```bash + ./x.py dist + ``` -Other Flags +## Other Flags The same flags from build are available here. You might want to consider adding on the -j flag for faster builds when building a distribution artifact. -``` +```bash -j, --jobs JOBS number of jobs to run in parallel ``` @@ -21,7 +23,6 @@ when building a distribution artifact. If you’ve built a distribution artifact you might want to install it and test that it works on your target system. You’ll want to run this command: - `./x.py install` - -Other Flags -The same flags from build are available \ No newline at end of file + ```bash + ./x.py install + ``` \ No newline at end of file diff --git a/src/compiler-documenting.md b/src/compiler-documenting.md index 919914e98..61d65f376 100644 --- a/src/compiler-documenting.md +++ b/src/compiler-documenting.md @@ -3,17 +3,21 @@ You might want to build documentation of the various components available like the standard library. There’s two ways to go about this. You can run rustdoc directly on the file to make sure the HTML is - correct which is fast or you can build the documentation as part of the - build process through x.py. Both are viable methods since documentation - is more about the content. + correct, which is fast. Alternatively, you can build the documentation + as part of the build process through x.py. Both are viable methods + since documentation is more about the content. ## Document everything - `./x.py doc` + ```bash + ./x.py doc + ``` ## If you want to avoid the whole Stage 2 build - `./x.py doc --stage 1` +```bash +./x.py doc --stage 1 +``` First the compiler and rustdoc get built to make sure everything is okay and then it documents the files. @@ -35,15 +39,22 @@ Mostly because this is useless for the average user. However, you might need to have it available so you can understand the types. Here’s how you can compile it yourself. From the top level directory where x.py is located run: - cp config.toml.example config.toml +```bash +cp config.toml.example config.toml +``` Next open up config.toml and make sure these two lines are set to true: +```bash docs = true compiler-docs = true +``` + When you want to build the compiler docs as well run this command: - `./x.py doc` +```bash +./x.py doc +``` This will see that the docs and compiler-docs options are set to true and build the normally hidden compiler docs! \ No newline at end of file diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 07a5eeb4d..c11d269bd 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -47,6 +47,14 @@ debuginfo-lines = true use-jemalloc = false ``` +### what is x.py? + +x.py is the script used to orchestrate the tooling in the rustc repository. +It is the script that can build docs, run tests, and compile rustc. +It is the now preferred way to build rustc and it replaces the old makefiles +from before. Below are the different ways to utilize x.py in order to +effectively deal with the repo for various common tasks. + ### Running x.py and building a stage1 compiler One thing to keep in mind is that `rustc` is a _bootstrapping_ @@ -80,6 +88,52 @@ compiling `rustc` is done in stages: can build the libraries with the stage2 compiler. The result ought to be identical to before, unless something has broken. + +#### Build Flags + +There are other flags you can pass to the build portion of x.py that can be +beneficial to cutting down compile times or fitting other things you might +need to change. They are: + +```bash +Options: + -v, --verbose use verbose output (-vv for very verbose) + -i, --incremental use incremental compilation + --config FILE TOML configuration file for build + --build BUILD build target of the stage0 compiler + --host HOST host targets to build + --target TARGET target targets to build + --on-fail CMD command to run on failure + --stage N stage to build + --keep-stage N stage to keep without recompiling + --src DIR path to the root of the rust checkout + -j, --jobs JOBS number of jobs to run in parallel + -h, --help print this help message +``` + +One thing to keep in mind is that `rustc` is a _bootstrapping_ compiler. That +is, since `rustc` is written in Rust, we need to use an older version of the +compiler to compile the newer version. In particular, the newer version of the +compiler, `libstd`, and other tooling may use some unstable features +internally. The result is the compiling `rustc` is done in stages. + +- **Stage 0:** the stage0 compiler can be your existing + (perhaps older version of) + Rust compiler, the current _beta_ compiler or you may download the binary + from the internet. +- **Stage 1:** the code in your clone (for new version) + is then compiled with the stage0 + compiler to produce the stage1 compiler. + However, it was built with an older compiler (stage0), + so to optimize the stage1 compiler we go to next stage. +- **Stage 2:** we rebuild our stage1 compiler with itself + to produce the stage2 compiler (i.e. it builds + itself) to have all the _latest optimizations_. +- _(Optional)_ **Stage 3**: to sanity check of our new compiler, + we can build it again + with stage2 compiler which must be identical to itself, + unless something has broken. + For hacking, often building the stage 1 compiler is enough, but for final testing and release, the stage 2 compiler is used. @@ -134,37 +188,25 @@ build`) has quite a few more steps: -### Build different stages - - `./x.py build --stage 0` - - # Stage 1 is typically enough to test out all of your changes - # to the compiler - - `./x.py build --stage 1` - - # Equivalent to ./x.py build - - `./x.py build --stage 2` - -You can pass the --stage flag with what stage you want to build to. -It is recommended that you build to Stage 1 as this is enough to know -your changes can successfully compile and should let you run tests -with your changes. - ### Build specific components Build only the libcore library - `./x.py build src/libcore` +```bash +> ./x.py build src/libcore +``` Build the libcore and libproc_macro library only - `./x.py build src/libcore src/libproc_macro` +```bash +> ./x.py build src/libcore src/libproc_macro +``` Build only libcore up to Stage 1 - `./x.py build src/libcore --stage 1` +```bash +> ./x.py build src/libcore --stage 1 +``` Sometimes you might just want to test if the part you’re working on can compile. Using these commands you can test that it compiles before doing @@ -183,8 +225,8 @@ you will likely need to build at some point; for example, if you want to run the entire test suite). ```bash - rustup toolchain link stage1 build//stage1 - rustup toolchain link stage2 build//stage2 +> rustup toolchain link stage1 build//stage1 +> rustup toolchain link stage2 build//stage2 ``` The `` would typically be one of the following: @@ -309,4 +351,6 @@ If you need to run this then rustbuild is most likely not acting right and you should file a bug as to what is going wrong. If you do need to clean everything up then you only need to run one command! - `./x.py clean` \ No newline at end of file + ```bash + > ./x.py clean + ``` diff --git a/src/tests/running.md b/src/tests/running.md index 970829cce..07030c799 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -93,23 +93,21 @@ This is much faster, but doesn't always work. For example, some tests include directives that specify specific compiler flags, or which rely on other crates, and they may not run the same without those options. -### Run specific tests - -# Run only the tidy script +### Run only the tidy script ```bash > ./x.py test src/tools/tidy ``` -# Run tests on the standard library +### Run tests on the standard library ```bash > ./x.py test src/libstd ``` -# Run tests on the standard library and run the tidy script +### Run tests on the standard library and run the tidy script ```bash > ./x.py test src/libstd src/tools/tidy ``` -# Run tests on the standard library using a stage 1 compiler +### Run tests on the standard library using a stage 1 compiler ```bash > ./x.py test src/libstd --stage 1 ``` diff --git a/src/what-is-x-py.md b/src/what-is-x-py.md deleted file mode 100644 index 315a3f821..000000000 --- a/src/what-is-x-py.md +++ /dev/null @@ -1,42 +0,0 @@ -# what is x.py? - -x.py is the script used to orchestrate the tooling in the rustc repository. -It is the script that can build docs, run tests, and compile rustc. -It is the now preferred way to build rustc and it replaces the old makefiles -from before. Below are the different ways to utilize x.py in order to -effectively deal with the repo for various common tasks. - -### Build Flags - -There are other flags you can pass to the build portion of x.py that can be -beneficial to cutting down compile times or fitting other things you might -need to change. They are: - -``` -Options: - -v, --verbose use verbose output (-vv for very verbose) - -i, --incremental use incremental compilation - --config FILE TOML configuration file for build - --build BUILD build target of the stage0 compiler - --host HOST host targets to build - --target TARGET target targets to build - --on-fail CMD command to run on failure - --stage N stage to build - --keep-stage N stage to keep without recompiling - --src DIR path to the root of the rust checkout - -j, --jobs JOBS number of jobs to run in parallel - -h, --help print this help message -``` - -Note that the options --incremental, --keep-stage 0 and --jobs JOBS can be -used in tandem with --stage to help reduce build times significantly by -reusing already built components, reusing the first bootstrapped stage, and -running compilation in parallel. To test changes you could run something like: - -```bash - ./x.py build --stage 1 --keep-stage 0 -j 4 -i -``` - -Please follow the links to build, document, test, benchmark and install -distribution - artifacts for rustc respectively. From 61cadd2097a40a6ade9b75e1b09460d9819ee24b Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Wed, 26 Sep 2018 10:32:50 -0400 Subject: [PATCH 0360/1812] issue-130 updated the review comments --- src/build-install-distribution-artifacts.md | 20 +++------ src/compiler-benchmarking.md | 11 ----- src/compiler-documenting.md | 9 +--- src/how-to-build-and-run.md | 26 +---------- src/tests/running.md | 49 ++++++++++++--------- 5 files changed, 37 insertions(+), 78 deletions(-) delete mode 100644 src/compiler-benchmarking.md diff --git a/src/build-install-distribution-artifacts.md b/src/build-install-distribution-artifacts.md index 89b1422a0..521c441a2 100644 --- a/src/build-install-distribution-artifacts.md +++ b/src/build-install-distribution-artifacts.md @@ -7,22 +7,16 @@ You’ll want to run this command to do it: ./x.py dist ``` -## Other Flags - -The same flags from build are available here. -You might want to consider adding on the -j flag for faster builds -when building a distribution artifact. - -```bash --j, --jobs JOBS number of jobs to run in parallel -``` - - # Install distribution artifacts -If you’ve built a distribution artifact you might want to install it and +If you’ve built a distribution artifact you might want to install it and test that it works on your target system. You’ll want to run this command: ```bash ./x.py install - ``` \ No newline at end of file + ``` + + Note: If you are testing out a modification to a compiler, you might want to use it to compile some project. + Usually, you do not want to use ./x.py install for testing. + Rather, you should create a toolchain as discussed in how-to-build-and-run.html#creating-a-rustup-toolchain. + For example, if the toolchain you created is called foo, you would then invoke it with rustc +foo ... (where ... represents the rest of the arguments). \ No newline at end of file diff --git a/src/compiler-benchmarking.md b/src/compiler-benchmarking.md deleted file mode 100644 index 1ce1e05ac..000000000 --- a/src/compiler-benchmarking.md +++ /dev/null @@ -1,11 +0,0 @@ -# Benchmarking rustc - -This one is a easier compared to the others. -All you’re doing is running benchmarks of the compiler itself -so it’ll build it and run the one set of benchmarks available to it. -The command is: - - `./x.py bench` - -Benchmarking lacks `--no-fail-fast` flag that `test` command has. - \ No newline at end of file diff --git a/src/compiler-documenting.md b/src/compiler-documenting.md index 61d65f376..fceb73c91 100644 --- a/src/compiler-documenting.md +++ b/src/compiler-documenting.md @@ -34,14 +34,9 @@ Much like individual tests or building certain components you can build only the documentation you want. ## Document internal rustc items -By default rustc does not build the compiler docs for its internal items. -Mostly because this is useless for the average user. However, you might need -to have it available so you can understand the types. Here’s how you can -compile it yourself. From the top level directory where x.py is located run: -```bash -cp config.toml.example config.toml -``` +Compiler documentation is not built by default - there's a flag in config.toml for achieving the same. +But, when enabled, compiler documentation does include internal items. Next open up config.toml and make sure these two lines are set to true: diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index c11d269bd..eb2f8a663 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -47,7 +47,7 @@ debuginfo-lines = true use-jemalloc = false ``` -### what is x.py? +### What is x.py? x.py is the script used to orchestrate the tooling in the rustc repository. It is the script that can build docs, run tests, and compile rustc. @@ -88,7 +88,6 @@ compiling `rustc` is done in stages: can build the libraries with the stage2 compiler. The result ought to be identical to before, unless something has broken. - #### Build Flags There are other flags you can pass to the build portion of x.py that can be @@ -111,29 +110,6 @@ Options: -h, --help print this help message ``` -One thing to keep in mind is that `rustc` is a _bootstrapping_ compiler. That -is, since `rustc` is written in Rust, we need to use an older version of the -compiler to compile the newer version. In particular, the newer version of the -compiler, `libstd`, and other tooling may use some unstable features -internally. The result is the compiling `rustc` is done in stages. - -- **Stage 0:** the stage0 compiler can be your existing - (perhaps older version of) - Rust compiler, the current _beta_ compiler or you may download the binary - from the internet. -- **Stage 1:** the code in your clone (for new version) - is then compiled with the stage0 - compiler to produce the stage1 compiler. - However, it was built with an older compiler (stage0), - so to optimize the stage1 compiler we go to next stage. -- **Stage 2:** we rebuild our stage1 compiler with itself - to produce the stage2 compiler (i.e. it builds - itself) to have all the _latest optimizations_. -- _(Optional)_ **Stage 3**: to sanity check of our new compiler, - we can build it again - with stage2 compiler which must be identical to itself, - unless something has broken. - For hacking, often building the stage 1 compiler is enough, but for final testing and release, the stage 2 compiler is used. diff --git a/src/tests/running.md b/src/tests/running.md index 07030c799..f8889c8a4 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -40,6 +40,33 @@ the debuginfo test suite: > ./x.py test --stage 1 src/test/debuginfo ``` +### Run only the tidy script + +```bash +> ./x.py test src/tools/tidy +``` + +### Run tests on the standard library + +```bash +> ./x.py test src/libstd +``` + +### Run tests on the standard library and run the tidy script + +```bash +> ./x.py test src/libstd src/tools/tidy +``` + +### Run tests on the standard library using a stage 1 compiler + +```bash +> ./x.py test src/libstd --stage 1 +``` + +By listing which test suites you want to run you avoid having to run +tests for components you did not change at all. + **Warning:** Note that bors only runs the tests with the full stage 2 build; therefore, while the tests **usually** work fine with stage 1, there are some limitations. In particular, the stage1 compiler doesn't @@ -92,25 +119,3 @@ just `rs` files, so you can do something like This is much faster, but doesn't always work. For example, some tests include directives that specify specific compiler flags, or which rely on other crates, and they may not run the same without those options. - -### Run only the tidy script -```bash -> ./x.py test src/tools/tidy -``` -### Run tests on the standard library -```bash -> ./x.py test src/libstd -``` - -### Run tests on the standard library and run the tidy script -```bash -> ./x.py test src/libstd src/tools/tidy -``` - -### Run tests on the standard library using a stage 1 compiler -```bash -> ./x.py test src/libstd --stage 1 -``` - -By listing which test suites you want to run you avoid having to run tests for -components you did not change at all. From ceff08f6b3f9666489be7ecd417b066e117aa474 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Fri, 28 Sep 2018 23:01:47 -0400 Subject: [PATCH 0361/1812] updated with review comments --- src/build-install-distribution-artifacts.md | 13 ++++++++++--- src/compiler-documenting.md | 3 ++- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/src/build-install-distribution-artifacts.md b/src/build-install-distribution-artifacts.md index 521c441a2..7430ffb9b 100644 --- a/src/build-install-distribution-artifacts.md +++ b/src/build-install-distribution-artifacts.md @@ -16,7 +16,14 @@ test that it works on your target system. You’ll want to run this command: ./x.py install ``` - Note: If you are testing out a modification to a compiler, you might want to use it to compile some project. + Note: If you are testing out a modification to a compiler, you + might want to use it to compile some project. Usually, you do not want to use ./x.py install for testing. - Rather, you should create a toolchain as discussed in how-to-build-and-run.html#creating-a-rustup-toolchain. - For example, if the toolchain you created is called foo, you would then invoke it with rustc +foo ... (where ... represents the rest of the arguments). \ No newline at end of file + Rather, you should create a toolchain as discussed in + [here][create-rustup-toolchain]. + + For example, if the toolchain you created is called foo, you + would then invoke it with `rustc +foo ...` (where ... represents + the rest of the arguments). + +[create-rustup-toolchain]: ./how-to-build-and-run.md#creating-a-rustup-toolchain \ No newline at end of file diff --git a/src/compiler-documenting.md b/src/compiler-documenting.md index fceb73c91..bf63c0120 100644 --- a/src/compiler-documenting.md +++ b/src/compiler-documenting.md @@ -35,7 +35,8 @@ Much like individual tests or building certain components you can build only ## Document internal rustc items -Compiler documentation is not built by default - there's a flag in config.toml for achieving the same. +Compiler documentation is not built by default. There's a flag in +config.toml for achieving the same. But, when enabled, compiler documentation does include internal items. Next open up config.toml and make sure these two lines are set to true: From 7cf032f9ec4506cdb821d9b4023490feac6c22bb Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 13 Oct 2018 11:35:53 -0500 Subject: [PATCH 0362/1812] Update a few parts of the readme --- README.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 2a59a40bb..45c7503fe 100644 --- a/README.md +++ b/README.md @@ -10,18 +10,15 @@ You may also find the rustdocs [for the compiler itself][rustdocs] useful. [rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ The guide can be useful today, but it has a lot of work still go. -Once it gets more complete, the plan is probably to move it into the -[main Rust repository](https://github.com/rust-lang/rust/). ### Contributing to the guide -If you'd like to help finish the guide, we'd love to have you! The -main tracking issue for the guide -[can be found here](https://github.com/rust-lang-nursery/rustc-guide/issues/6). From -there, you can find a list of all the planned chapters and subsections. -If you think something is missing, please open an issue about it! -Otherwise, find a chapter that sounds interesting to you and then go -to its associated issue. There should be a list of things to do. +If you'd like to help improve the guide, we'd love to have you! You can find +plenty of issues on the [issue +tracker](https://github.com/rust-lang-nursery/rustc-guide/issue). Just post a +comment on the issue you would like to work on to make sure that we don't +accidentally duplicate work. If you think something is missing, please open an +issue about it! **In general, if you don't know how the compiler works, that is not a problem!** In that case, what we will do is to schedule a bit of time @@ -29,6 +26,10 @@ for you to talk with someone who **does** know the code, or who wants to pair with you and figure it out. Then you can work on writing up what you learned. +In general, when writing about a particular part of the compiler's code, we +recommend that you link to the relevant parts of the [rustc +rustdocs][rustdocs]. + To help prevent accidentally introducing broken links, we use the `mdbook-linkcheck`. If installed on your machine `mdbook` will automatically invoke this link checker, otherwise it will emit a warning saying it couldn't From a01aa11b7be1df9b4ce7a4c98ef41d60ea40628b Mon Sep 17 00:00:00 2001 From: Collins Abitekaniza Date: Sat, 20 Oct 2018 01:19:52 +0300 Subject: [PATCH 0363/1812] fix typo in build instructions --- src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index eb2f8a663..4315cd708 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -230,7 +230,7 @@ LLVM version: 4.0 ### Suggested workflows for faster builds of the compiler -There are two workflows that are useful for faster builders of the +There are two workflows that are useful for faster builds of the compiler. **Check, check, and check again.** The first workflow, which is useful From 4aeae78bdb078e10aee219938788ec9e0ed7936a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 19 Oct 2018 16:19:27 -0500 Subject: [PATCH 0364/1812] Fix typo --- src/borrow_check/moves_and_initialization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/moves_and_initialization.md b/src/borrow_check/moves_and_initialization.md index d1cd41e0f..d1530d6c0 100644 --- a/src/borrow_check/moves_and_initialization.md +++ b/src/borrow_check/moves_and_initialization.md @@ -44,7 +44,7 @@ moves `a` into the call, and hence it becomes uninitialized again. To make it easier to peruse, this section is broken into a number of subsections: -- [Move paths](./moves_and_initialization/move_paths.html the +- [Move paths](./moves_and_initialization/move_paths.html) the *move path* concept that we use to track which local variables (or parts of local variables, in some cases) are initialized. - TODO *Rest not yet written* =) From 3db38fe7f30c1b8bde710495d38fe74dc1b870fa Mon Sep 17 00:00:00 2001 From: scalexm Date: Tue, 16 Oct 2018 14:55:03 +0200 Subject: [PATCH 0365/1812] Polish lowering chapters and update rules --- src/traits/associated-types.md | 21 ++++++--- src/traits/goals-and-clauses.md | 84 ++++++++++++++++++++++++++------- src/traits/index.md | 14 ++++++ src/traits/lowering-rules.md | 36 ++++++++------ 4 files changed, 116 insertions(+), 39 deletions(-) diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md index b8ac7f8b9..3330ce809 100644 --- a/src/traits/associated-types.md +++ b/src/traits/associated-types.md @@ -67,7 +67,7 @@ type.) We could apply that rule to normalize either of the examples that we've seen so far. -## Skolemized associated types +## Placeholder associated types Sometimes however we want to work with associated types that cannot be normalized. For example, consider this function: @@ -78,20 +78,29 @@ fn foo(...) { ... } In this context, how would we normalize the type `T::Item`? Without knowing what `T` is, we can't really do so. To represent this case, we -introduce a type called a **skolemized associated type +introduce a type called a **placeholder associated type projection**. This is written like so `(IntoIterator::Item)`. You may note that it looks a lot like a regular type (e.g., `Option`), except that the "name" of the type is `(IntoIterator::Item)`. This is -not an accident: skolemized associated type projections work just like +not an accident: placeholder associated type projections work just like ordinary types like `Vec` when it comes to unification. That is, they are only considered equal if (a) they are both references to the same associated type, like `IntoIterator::Item` and (b) their type arguments are equal. -Skolemized associated types are never written directly by the user. +Placeholder associated types are never written directly by the user. They are used internally by the trait system only, as we will see shortly. +In rustc, they correspond to the `TyKind::UnnormalizedProjectionTy` enum +variant, declared in [`librustc/ty/sty.rs`][sty]. In chalk, we use an +`ApplicationTy` with a name living in a special namespace dedicated to +placeholder associated types (see the `TypeName` enum declared in +[`chalk-ir/src/lib.rs`][chalk_type_name]). + +[sty]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/sty.rs +[chalk_type_name]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-ir/src/lib.rs + ## Projection equality So far we have seen two ways to answer the question of "When can we @@ -99,7 +108,7 @@ consider an associated type projection equal to another type?": - the `Normalize` predicate could be used to transform associated type projections when we knew which impl was applicable; -- **skolemized** associated types can be used when we don't. +- **placeholder** associated types can be used when we don't. We now introduce the `ProjectionEq` predicate to bring those two cases together. The `ProjectionEq` predicate looks like so: @@ -109,7 +118,7 @@ ProjectionEq(::Item = U) ``` and we will see that it can be proven *either* via normalization or -skolemization. As part of lowering an associated type declaration from +via the placeholder type. As part of lowering an associated type declaration from some trait, we create two program clauses for `ProjectionEq`: ```text diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index 5aa3755ad..8cc1bc7fd 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -37,15 +37,33 @@ paper ["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] gives the details. +In terms of code, these types are defined in +[`librustc/traits/mod.rs`][traits_mod] in rustc, and in +[`chalk-ir/src/lib.rs`][chalk_ir] in chalk. + [pphhf]: ./bibliography.html#pphhf +[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc/traits/mod.rs +[chalk_ir]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-ir/src/lib.rs ## Domain goals +*Domain goals* are the atoms of the trait logic. As can be seen in the +definitions given above, general goals basically consist in a combination of +domain goals. + +Moreover, flattenning a bit the definition of clauses given previously, one can +see that clauses are always of the form: +```text +forall { DomainGoal :- Goal } +``` +hence domain goals are in fact clauses LHS. That is, at the most granular level, +domain goals are what the trait solver will end up trying to prove. + -To define the set of *domain goals* in our system, we need to first +To define the set of domain goals in our system, we need to first introduce a few simple formulations. A **trait reference** consists of the name of a trait along with a suitable set of inputs P0..Pn: @@ -70,18 +88,24 @@ Projection = >::AssocItem Given these, we can define a `DomainGoal` as follows: ```text -DomainGoal = Implemented(TraitRef) - | ProjectionEq(Projection = Type) - | Normalize(Projection -> Type) +DomainGoal = Holds(WhereClause) | FromEnv(TraitRef) - | FromEnv(Projection = Type) - | WellFormed(Type) + | FromEnv(Type) | WellFormed(TraitRef) - | WellFormed(Projection = Type) + | WellFormed(Type) + | Normalize(Projection -> Type) + +WhereClause = Implemented(TraitRef) + | ProjectionEq(Projection = Type) | Outlives(Type: Region) | Outlives(Region: Region) ``` +`WhereClause` refers to a `where` clause that a Rust user would actually be able +to write in a Rust program. This abstraction exists only as a convenience as we +sometimes want to only coope with domain goals that are effectively writable in +Rust. + Let's break down each one of these, one-by-one. #### Implemented(TraitRef) @@ -109,12 +133,10 @@ also requires proving `Implemented(T: Trait)`. [n]: ./associated-types.html#normalize [at]: ./associated-types.html -#### FromEnv(TraitRef), FromEnv(Projection = Type) +#### FromEnv(TraitRef) e.g. `FromEnv(Self: Add)` -e.g. `FromEnv(::Item<'a> = &'a [u8])` - -True if the inner `TraitRef` or projection equality is *assumed* to be true; +True if the inner `TraitRef` is *assumed* to be true, that is, if it can be derived from the in-scope where clauses. For example, given the following function: @@ -131,24 +153,50 @@ where clauses nest, so a function body inside an impl body inherits the impl body's where clauses, too. This and the next rule are used to implement [implied bounds]. As we'll see -in the section on lowering, `FromEnv(X)` implies `Implemented(X)`, but not -vice versa. This distinction is crucial to implied bounds. +in the section on lowering, `FromEnv(TraitRef)` implies `Implemented(TraitRef)`, +but not vice versa. This distinction is crucial to implied bounds. + +#### FromEnv(Type) +e.g. `FromEnv(HashSet)` + +True if the inner `Type` is *assumed* to be well-formed, that is, if it is an +input type of a function or an impl. + +For example, given the following code: + +```rust,ignore +struct HashSet where K: Hash { ... } + +fn loud_insert(set: &mut HashSet, item: K) { + println!("inserting!"); + set.insert(item); +} +``` + +`HashSet` is an input type of the `loud_insert` function. Hence, we assume it +to be well-formed, so we would have `FromEnv(HashSet)` inside the body or our +function. As we'll see in the section on lowering, `FromEnv(HashSet)` implies +`Implemented(K: Hash)` because the +`HashSet` declaration was written with a `K: Hash` where clause. Hence, we don't +need to repeat that bound on the `loud_insert` function: we rather automatically +assume that it is true. #### WellFormed(Item) These goals imply that the given item is *well-formed*. We can talk about different types of items being well-formed: -**Types**, like `WellFormed(Vec)`, which is true in Rust, or +* *Types*, like `WellFormed(Vec)`, which is true in Rust, or `WellFormed(Vec)`, which is not (because `str` is not `Sized`.) -**TraitRefs**, like `WellFormed(Vec: Clone)`. - -**Projections**, like `WellFormed(T: Iterator)`. +* *TraitRefs*, like `WellFormed(Vec: Clone)`. Well-formedness is important to [implied bounds]. In particular, the reason -it is okay to assume `FromEnv(T: Clone)` in the example above is that we +it is okay to assume `FromEnv(T: Clone)` in the `loud_clone` example is that we _also_ verify `WellFormed(T: Clone)` for each call site of `loud_clone`. +Similarly, it is okay to assume `FromEnv(HashSet)` in the `loud_insert` +example because we will verify `WellFormed(HashSet)` for each call site of +`loud_insert`. #### Outlives(Type: Region), Outlives(Region: Region) e.g. `Outlives(&'a str: 'b)`, `Outlives('a: 'static)` diff --git a/src/traits/index.md b/src/traits/index.md index c5afb280b..053a26bab 100644 --- a/src/traits/index.md +++ b/src/traits/index.md @@ -33,3 +33,17 @@ Trait solving is based around a few key ideas: constraints can be checked by thet type checker. Note: this is not a complete list of topics. See the sidebar for more. + +The design of the new-style trait solving currently happens in two places: +* The [chalk][chalk] repository is where we experiment with new ideas and + designs for the trait system. It basically consists of a unit testing framework + for the correctness and feasibility of the logical rules defining the new-style + trait system. It also provides the [`chalk_engine`][chalk_engine] crate, which + defines the new-style trait solver used both in the unit testing framework and + in rustc. +* Once we are happy with the logical rules, we proceed to implementing them in + rustc. This mainly happens in [`librustc_traits`][librustc_traits]. + +[chalk]: https://github.com/rust-lang-nursery/chalk +[chalk_engine]: https://github.com/rust-lang-nursery/chalk/tree/master/chalk-engine +[librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index 218164c0f..88a61ac4f 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -27,19 +27,24 @@ comment like so: // Rule Foo-Bar-Baz -you can also search through the `librustc_traits` crate in rustc -to find the corresponding rules from the implementation. +The reference implementation of these rules is to be found in +[`chalk/src/rules.rs`][chalk_rules]. They are also ported in rustc in the +[`librustc_traits`][librustc_traits] crate. + +[chalk_rules]: https://github.com/rust-lang-nursery/chalk/blob/master/src/rules.rs +[librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits ## Lowering where clauses When used in a goal position, where clauses can be mapped directly to -[domain goals][dg], as follows: +the `Holds` variant of [domain goals][dg], as follows: -- `A0: Foo` maps to `Implemented(A0: Foo)`. -- `A0: Foo` maps to - `ProjectionEq(>::Item = T)` +- `A0: Foo` maps to `Implemented(A0: Foo)` - `T: 'r` maps to `Outlives(T, 'r)` - `'a: 'b` maps to `Outlives('a, 'b)` +- `A0: Foo` is a bit special and expands to two distinct + goals, namely `Implemented(A0: Foo)` and + `ProjectionEq(>::Item = T)` In the rules below, we will use `WC` to indicate where clauses that appear in Rust syntax; we will then use the same `WC` to indicate @@ -54,11 +59,10 @@ on the lowered where clauses, as defined here: - `FromEnv(WC)` – this indicates that: - `Implemented(TraitRef)` becomes `FromEnv(TraitRef)` - - `ProjectionEq(Projection = Ty)` becomes `FromEnv(Projection = Ty)` - other where-clauses are left intact - `WellFormed(WC)` – this indicates that: - `Implemented(TraitRef)` becomes `WellFormed(TraitRef)` - - `ProjectionEq(Projection = Ty)` becomes `WellFormed(Projection = Ty)` + - other where-clauses are left intact *TODO*: I suspect that we want to alter the outlives relations too, but Chalk isn't modeling those right now. @@ -99,9 +103,11 @@ forall { #### Implied bounds The next few clauses have to do with implied bounds (see also -[RFC 2089]). For each trait, we produce two clauses: +[RFC 2089] and the [implied bounds][implied_bounds] chapter for a more in depth +cover). For each trait, we produce two clauses: [RFC 2089]: https://rust-lang.github.io/rfcs/2089-implied-bounds.html +[implied_bounds]: ./implied-bounds.md ```text // Rule Implied-Bound-From-Trait @@ -210,7 +216,7 @@ well-formed, we can also assume that its where clauses hold. That is, we produce the following family of rules: ```text -// Rule FromEnv-Type +// Rule Implied-Bound-From-Type // // For each where clause `WC` forall { @@ -280,10 +286,10 @@ forall { ``` ```text -// Rule ProjectionEq-Skolemize +// Rule ProjectionEq-Placeholder // -// ProjectionEq can succeed by skolemizing, see "associated type" -// chapter for more: +// ProjectionEq can succeed through the placeholder associated type, +// see "associated type" chapter for more: forall { ProjectionEq( >::AssocType = @@ -303,7 +309,7 @@ elsewhere. // For each `Bound` in `Bounds`: forall { FromEnv(>::AssocType>: Bound) :- - FromEnv(Self: Trait) + FromEnv(Self: Trait) && WC1 } ``` @@ -314,7 +320,7 @@ type to be well-formed... // Rule WellFormed-AssocTy forall { WellFormed((Trait::AssocType)) :- - WC1, Implemented(Self: Trait) + Implemented(Self: Trait) && WC1 } ``` From 07bf5e332ba6b39e7c94e694a46a89f9e104e869 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 21 Oct 2018 18:05:32 +0200 Subject: [PATCH 0366/1812] Add an apostrophe Co-Authored-By: scalexm --- src/traits/goals-and-clauses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index 8cc1bc7fd..494ec5b85 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -58,7 +58,7 @@ see that clauses are always of the form: ```text forall { DomainGoal :- Goal } ``` -hence domain goals are in fact clauses LHS. That is, at the most granular level, +hence domain goals are in fact clauses' LHS. That is, at the most granular level, domain goals are what the trait solver will end up trying to prove. From ab89ea2446c4fb4f7fc7affdc5c900cb4667ec62 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 21 Oct 2018 18:05:51 +0200 Subject: [PATCH 0367/1812] Fix typo Co-Authored-By: scalexm --- src/traits/goals-and-clauses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index 494ec5b85..fb12c5a41 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -174,7 +174,7 @@ fn loud_insert(set: &mut HashSet, item: K) { ``` `HashSet` is an input type of the `loud_insert` function. Hence, we assume it -to be well-formed, so we would have `FromEnv(HashSet)` inside the body or our +to be well-formed, so we would have `FromEnv(HashSet)` inside the body of our function. As we'll see in the section on lowering, `FromEnv(HashSet)` implies `Implemented(K: Hash)` because the `HashSet` declaration was written with a `K: Hash` where clause. Hence, we don't From dfa38e973e5a45ec907bce1c9ca8a5a3a6971c4c Mon Sep 17 00:00:00 2001 From: scalexm Date: Sun, 21 Oct 2018 18:07:25 +0200 Subject: [PATCH 0368/1812] Change wording --- src/traits/goals-and-clauses.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index fb12c5a41..8f1ffa488 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -103,7 +103,7 @@ WhereClause = Implemented(TraitRef) `WhereClause` refers to a `where` clause that a Rust user would actually be able to write in a Rust program. This abstraction exists only as a convenience as we -sometimes want to only coope with domain goals that are effectively writable in +sometimes want to only deal with domain goals that are effectively writable in Rust. Let's break down each one of these, one-by-one. @@ -117,8 +117,8 @@ True if the given trait is implemented for the given input types and lifetimes. e.g. `ProjectionEq::Item = u8` The given associated type `Projection` is equal to `Type`; this can be proved -with either normalization or using skolemized types. See [the section -on associated types](./associated-types.html). +with either normalization or using placeholder associated types. See +[the section on associated types](./associated-types.html). #### Normalize(Projection -> Type) e.g. `ProjectionEq::Item -> u8` From 2df0fcfdfb1fdeb8cf124fa317b7aeaaf453bd0c Mon Sep 17 00:00:00 2001 From: scalexm Date: Fri, 19 Oct 2018 15:20:41 +0200 Subject: [PATCH 0369/1812] Write implied bounds chapter --- src/traits/implied-bounds.md | 501 ++++++++++++++++++++++++++++++++++- 1 file changed, 496 insertions(+), 5 deletions(-) diff --git a/src/traits/implied-bounds.md b/src/traits/implied-bounds.md index 26a63bf32..1feb84e3b 100644 --- a/src/traits/implied-bounds.md +++ b/src/traits/implied-bounds.md @@ -1,9 +1,500 @@ # Implied Bounds -*to be written* +Implied bounds remove the need to repeat where clauses written on +a type declaration or a trait declaration. For example, say we have the +following type declaration: +```rust,ignore +struct HashSet { + ... +} +``` -Cover: +then everywhere we use `HashSet` as an "input" type, that is appearing in +the receiver type of an `impl` or in the arguments of a function, we don't +want to have to repeat the `where K: Hash` bound, as in: -- Why the `FromEnv` setup etc is the way it is -- Perhaps move some of the material from 'lowering rules' in to here -- Show various examples where you could go wrong +```rust,ignore +// I don't want to have to repeat `where K: Hash` here. +impl HashSet { + ... +} + +// Same here. +fn loud_insert(set: &mut HashSet, item: K) { + println!("inserting!"); + set.insert(item); +} +``` + +Note that in the `loud_insert` example, `HashSet` is not the type of an +argument of the `loud_insert` function, it only *appears* in the argument type +`&mut HashSet`. + +The rationale for applying implied bounds to input types is that, for example, +in order to call the `loud_insert` function above, the programmer must have +*produced* the type `HashSet` already, hence the compiler already verified +that `HashSet` was well-formed, i.e. that `K` effectively implemented +`Hash`, as in the following example: + +```rust,ignore +fn main() { + // I am producing a value of type `HashSet`. + // If `i32` was not `Hash`, the compiler would report an error here. + let set: HashSet = HashSet::new(); + loud_insert(&mut set, 5); +} +``` + +hence we don't want to repeat where clauses for input types because that would +sort of duplicate the work of the programmer, having to verify that their types +are well-formed both when calling the function and when using them in the +arguments of their function. The same reasoning applies when using an `impl`. + +Similarly, given the following trait declaration: +```rust,ignore +trait Copy where Self: Clone { + ... +} +``` + +then everywhere we bound over `SomeType: Copy`, we would like to be able to +use the fact that `SomeType: Clone` without having to write it explicitly, +as in: +```rust,ignore +fn loud_clone(x: T) { + println!("cloning!"); + x.clone(); +} + +fn fun_with_copy(x: T) { + println!("will clone a `Copy` type soon..."); + + // I'm using `loud_clone` with `T: Copy`, I know this + // implies `T: Clone` so I don't want to have to write it explicitly. + loud_clone(x); +} +``` + +The rationale for implied bounds for traits is that if a type implement `Copy`, +that is if there exists an `impl Copy` for that type, there *ought* to exist +an `impl Clone` for that type, otherwise the compiler would have reported an +error in the first place. So again, if we were forced to repeat the additionnal +`where SomeType: Clone` everywhere whereas we already know that +`SomeType: Copy` hold, we would kind of duplicate the verification work. + +Implied bounds are not yet completely enforced in rustc, at the moment it only +works for outlive requirements, super trait bounds and bounds on associated +types. The full RFC can be found [here][RFC]. We'll give here a brief view +of how implied bounds work and why we chose to implement it that way. The +complete set of lowering rules can be found in the corresponding +[chapter](./lowering-rules.md). + +[RFC]: https://github.com/rust-lang/rfcs/blob/master/text/2089-implied-bounds.md + +## Implied bounds and lowering rules + +Now we need to express implied bounds in terms of logical rules. We will start +with exposing a naive way to do it. Suppose that we have the following traits: +```rust,ignore +trait Foo { + ... +} + +trait Bar where Self: Foo { } { + ... +} +``` + +So we would like to say that if a type implements `Bar`, then necessarily +it must also implement `Foo`. We might think that a clause like this would +work: +```text +forall { + Implemented(Type: Foo) :- Implemented(Type: Bar). +} +``` + +Now suppose that we just write this impl: +```rust,ignore +struct X; + +impl Bar for X { } +``` + +Clearly this should not be allowed: indeed, we wrote a `Bar` impl for `X`, but +the `Bar` trait requires that we also implement `Foo` for `X`, which we never +did. In terms of what the compiler does, this would look like this: +```rust,ignore +struct X; + +impl Bar for X { + // We are in a `Bar` impl for the type `X`. + // There is a `where Self: Foo` bound on the `Bar` trait declaration. + // Hence I need to prove that `X` also implements `Foo` for that impl + // to be legal. +} +``` +So the compiler would try to prove `Implemented(X: Foo)`. Of course it will +not find any `impl Foo for X` since we did not write any. However, it +will see our implied bound clause: +```text +forall { + Implemented(Type: Foo) :- Implemented(Type: Bar). +} +``` + +so that it may be able to prove `Implemented(X: Foo)` if `Implemented(X: Bar)` +holds. And it turns out that `Implemented(X: Bar)` does hold since we wrote +a `Bar` impl for `X`! Hence the compiler will accept the `Bar` impl while it +should not. + +## Implied bounds coming from the environment + +So the naive approach does not work. What we need to do is to somehow decouple +implied bounds from impls. Suppose we know that a type `SomeType<...>` +implements `Bar` and we want to deduce that `SomeType<...>` must also implement +`Foo`. + +There are two possibilities: first one, we have enough information about +`SomeType<...>` to see that there exists a `Bar` impl in the program which +covers `SomeType<...>`, for example a plain `impl<...> Bar for SomeType<...>`. +Then if the compiler has done its job correctly, there *must* exist a `Foo` +impl which covers `SomeType<...>`, e.g. another plain +`impl<...> Foo for SomeType<...>`. In that case then, we can just use this +impl and we do not need implied bounds at all. + +Second possibility: we do not know enough about `SomeType<...>` in order to +find a `Bar` impl which covers it, for example if `SomeType<...>` is just +a type parameter in a function: +```rust,ignore +fn foo() { + // We'd like to deduce `Implemented(T: Foo)`. +} +``` + +that is, the information that `T` implements `Bar` here comes from the +*environment*. The environment is the set of things that we assume to be true +when we type check some Rust declaration. In that case, what we assume is that +`T: Bar`. Then at that point, we might authorize ourselves to have some kind +of "local" implied bound reasoning which would say +`Implemented(T: Foo) :- Implemented(T: Bar)`. This reasoning would +only be done within our `foo` function in order to avoid the earlier +problem where we had a global clause. + +We can apply these local reasonings everywhere we can have an environment +-- i.e. when we can write where clauses -- that is inside impls, +trait declarations and type declarations. + +## Computing implied bounds with `FromEnv` + +The previous subsection showed that it was only useful to compute implied +bounds for facts coming from the environment. +We talked about "local" rules, but there are multiple possible strategies to +indeed implement the locality of implied bounds. + +In rustc, the current strategy is to *elaborate* bounds: that is, each time +we have a fact in the environment, we recursively derive all the other things +that are implied by this fact until we reach a fixed point. For example, if +we have the following declarations: +```rust,ignore +trait A { } +trait B where Self: A { } +trait C where Self: B { } + +fn foo() { + ... +} +``` +then inside the `foo` function, we start with an environment containing only +`Implemented(T: C)`. Then because of implied bounds for the `C` trait, we +elaborate `Implemented(T: B)` and add it to our environment. Because of +implied bounds for the `B` trait, we elaborate `Implemented(T: A)`and add it +to our environment as well. We cannot elaborate anything else, so we conclude +that our final environment consists of `Implemented(T: A + B + C)`. + +In the new-style trait system, we like to encode as many things as possible +with logical rules. So rather than "elaborating", we have a set of *global* +program clauses defined like so: +```text +forall { Implemented(T: A) :- FromEnv(T: A). } + +forall { Implemented(T: B) :- FromEnv(T: B). } +forall { FromEnv(T: A) :- FromEnv(T: B). } + +forall { Implemented(T: C) :- FromEnv(T: C). } +forall { FromEnv(T: C) :- FromEnv(T: C). } +``` +So these clauses are defined globally (that is they are available from +everywhere in the program) but they cannot be used because the hypothesis +is always of the form `FromEnv(...)` which is a bit special. Indeed, as +indicated by the name, `FromEnv(...)` facts can **only** come from the +environment. +How it works is that in the `foo` function, instead of having an environment +containing `Implemented(T: C)`, we replace this environment with +`FromEnv(T: C)`. From here and thanks to the above clauses, we see that we +are able to reach any of `Implemented(T: A)`, `Implemented(T: B)` or +`Implemented(T: C)`, which is what we wanted. + +## Implied bounds and well-formedness checking + +Implied bounds are tightly related with well-formedness checking. +Well-formedness checking is the process of checking that the impls the +programmer wrote are legal, what we referred to earlier as "the compiler doing +its job correctly". + +We already saw examples of illegal and legal impls: +```rust,ignore +trait Foo { } +trait Bar where Self: Foo { } + +struct X; +struct Y; + +impl Bar for X { + // This impl is not legal: the `Bar` trait requires that we also + // implement `Foo`, and we didn't. +} + +impl Foo for Y { + // This impl is legal: there is nothing to check as there are no where + // clauses on the `Foo` trait. +} + +impl Bar for Y { + // This impl is legal: we have a `Foo` impl for `Y`. +} +``` +We must define what "legal" and "illegal" mean. For this, we introduce another +predicate: `WellFormed(Type: Trait)`. We say that the trait reference +`Type: Trait` is well-formed is `Type` meets the bounds written on the +`Trait` declaration. For each impl we write, assuming that the where clauses +declared on the impl hold, the compiler tries to prove that the corresponding +trait reference is well-formed. The impl is legal if the compiler manages to do +so. + +Coming to the definition of `WellFormed(Type: Trait)`, it would be tempting +to define it as: +```rust,ignore +trait Trait where WC1, WC2, ..., WCn { + ... +} +``` + +```text +forall { + WellFormed(Type: Trait) :- WC1 && WC2 && .. && WCn. +} +``` +and indeed this was basically what was done in rustc until it was noticed that +this mixed badly with implied bounds. The key thing is that implied bounds +allows someone to derive all bounds implied by a fact in the environment, and +this *transitively* as we've seen with the `A + B + C` traits example. +However, the `WellFormed` predicate as defined above only checks that the +*direct* superbounds hold. That is, if we come back to our `A + B + C` +example: +```rust,ignore +trait A { } +// No where clauses, always well-formed. +// forall { WellFormed(Type: A). } + +trait B where Self: A { } +// We only check the direct superbound `Self: A`. +// forall { WellFormed(Type: B) :- Implemented(Type: A). } + +trait C where Self: B { } +// We only check the direct superbound `Self: B`. We do not check +// the `Self: A` implied bound coming from the `Self: B` superbound. +// forall { WellFormed(Type: C) :- Implemented(Type: B). } +``` +There is an asymmetry between the recursive power of implied bounds and +the shallow checking of `WellFormed`. It turns out that this asymmetry +can be [exploited][bug]. Indeed, suppose that we define the following +traits: +```rust,ignore +trait Partial where Self: Copy { } +// WellFormed(Self: Partial) :- Implemented(Self: Copy). + +trait Complete where Self: Partial { } +// WellFormed(Self: Complete) :- Implemented(Self: Partial). + +impl Partial for T where T: Complete { } + +impl Complete for T { } +``` + +For the `Partial` impl, what the compiler must prove is: +```text +forall { + if (T: Complete) { // assume that the where clauses hold + WellFormed(T: Partial) // show that the trait reference is well-formed + } +} +``` +Proving `WellFormed(T: Partial)` amounts to proving `Implemented(T: Copy)`. +However, we have `Implemented(T: Complete)` in our environment: thanks to +implied bounds, we can deduce `Implemented(T: Partial)`. Using implied bounds +one level deeper, we can deduce `Implemented(T: Copy)`. Finally, the `Partial` +impl is legal. + +For the `Complete` impl, what the compiler must prove is: +```text +forall { + WellFormed(T: Complete) // show that the trait reference is well-formed +} +``` +Proving `WellFormed(T: Complete)` amounts to proving `Implemented(T: Partial)`. +We see that the `impl Partial for T` applies if we can prove +`Implemented(T: Complete)`, and it turns out we can prove this fact since our +`impl Complete for T` is a blanket impl without any where clauses. + +So both impls are legal and the compiler accepts the program. Moreover, thanks +to the `Complete` blanket impl, all types implement `Complete`. So we could +now use this impl like so: +```rust,ignore +fn eat(x: T) { } + +fn copy_everything(x: T) { + eat(x); + eat(x); +} + +fn main() { + let not_copiable = vec![1, 2, 3, 4]; + copy_everything(not_copiable); +} +``` +In this program, we use the fact that `Vec` implements `Complete`, as any +other type. Hence we can call `copy_everything` with an argument of type +`Vec`. Inside the `copy_everything` function, we have the +`Implemented(T: Complete)` bound in our environment. Thanks to implied bounds, +we can deduce `Implemented(T: Partial)`. Using implied bounds again, we deduce +`Implemented(T: Copy)` and we can indeed call the `eat` function which moves +the argument twice since its argument is `Copy`. Problem: the `T` type was +in fact `Vec` which is not copy at all, hence we will double-free the +underlying vec storage so we have a memory unsoundness in safe Rust. + +Of course, disregarding the asymmetry between `WellFormed` and implied bounds, +this bug was possible only because we had some kind of self-referencing impls. +But self-referencing impls are very useful in practice and are not the real +culprits in this affair. + +[bug]: https://github.com/rust-lang/rust/pull/43786 + +## Co-inductiveness of `WellFormed` + +So the solution is to fix this asymmetry between `WellFormed` and implied +bounds. For that, we need for the `WellFormed` predicate to not only require +that the direct superbounds hold, but also all the bounds transitively implied +by the superbounds. What we can do is to have the following rules for the +`WellFormed` predicate: +```rust,ignore +trait A { } +// WellFormed(Self: A) :- Implemented(Self: A). + +trait B where Self: A { } +// WellFormed(Self: B) :- Implemented(Self: B) && WellFormed(Self: A). + +trait C where Self: B { } +// WellFormed(Self: C) :- Implemented(Self: C) && WellFormed(Self: B). +``` + +Notice that we are now also requiring `Implemented(Self: Trait)` for +`WellFormed(Self: Trait)` to be true: this is to simplify the process of +traversing all the implied bounds transitively. This does not change anything +when checking whether impls are legal, because since we assume +that the where clauses hold inside the impl, we know that the corresponding +trait reference do hold. Thanks to this setup, you can see that we indeed +require to prove the set of all bounds transitively implied by the where +clauses. + +However there is still a catch. Suppose that we have the following trait +definition: +```rust,ignore +trait Foo where ::Item: Foo { + type Item; +} +``` + +so this definition is a bit more involved than the ones we've seen already +because it defines an associated item. However, the well-formedness rule +would not be more complicated: +```text +WellFormed(Self: Foo) :- + Implemented(Self: Foo) && + WellFormed(::Item: Foo). +``` + +Now we would like to write the following impl: +```rust,ignore +impl Foo for i32 { + type Item = i32; +} +``` +The `Foo` trait definition and the `impl Foo for i32` are perfectly valid +Rust: we're kind of recursively using our `Foo` impl in order to show that +the associated value indeed implements `Foo`, but that's ok. But if we +translates this to our well-formedness setting, the compiler proof process +inside the `Foo` impl is the following: it starts with proving that the +well-formedness goal `WellFormed(i32: Foo)` is true. In order to do that, +it must prove the following goals: `Implemented(i32: Foo)` and +`WellFormed(::Item: Foo)`. `Implemented(i32: Foo)` holds because +there is our impl and there are no where clauses on it so it's always true. +However, because of the associated type value we used, +`WellFormed(::Item: Foo)` simplifies to just +`WellFormed(i32: Foo)`. So in order to prove its original goal +`WellFormed(i32: Foo)`, the compiler needs to prove `WellFormed(i32: Foo)`: +this clearly is a cycle and cycles are usually rejected by the trait solver, +unless... if the `WellFormed` predicate was made to be co-inductive. + +A co-inductive predicate, as discussed in the chapter on +[goals and clauses](./goals-and-clauses.md#coinductive-goals), are predicates +for which the +trait solver accepts cycles. In our setting, this would be a valid thing to do: +indeed, the `WellFormed` predicate just serves as a way of enumerating all +the implied bounds. Hence, it's like a fixed point algorithm: it tries to grow +the set of implied bounds until there is nothing more to add. Here, a cycle +in the chain of `WellFormed` predicates just means that there is no more bounds +to add in that direction, so we can just accept this cycle and focus on other +directions. It's easy to prove that under these co-inductive semantics, we +are effectively visiting all the transitive implied bounds, and only these. + +## Implied bounds on types + +We mainly talked about implied bounds for traits because this was the most +subtle regarding implementation. Implied bounds on types are simpler, +especially because if we assume that a type is well-formed, we don't use that +fact to deduce that other types are well-formed, we only use it to deduce +that e.g. some trait bounds hold. + +For types, we just use rules like these ones: +```rust,ignore +struct Type<...> where WC1, ..., WCn { + ... +} +``` + +```text +forall<...> { + WellFormed(Type<...>) :- WC1, ..., WCn. +} + +forall<...> { + FromEnv(WC1) :- FromEnv(Type<...>). + ... + FromEnv(WCn) :- FromEnv(Type<...>). +} +``` +We can see that we have this asymmetry between well-formedness check, +which only verifies that the direct superbounds hold, and implied bounds which +gives access to all bounds transitively implied by the where clauses. In that +case this is ok because as we said, we don't use `FromEnv(Type<...>)` to deduce +other `FromEnv(OtherType<...>)` things, nor do we use `FromEnv(Type: Trait)` to +deduce `FromEnv(OtherType<...>)` things. So in that sense type definitions are +"less recursive" than traits, and we saw in a previous subsection that +it was the combination of asymmetry and recursive trait / impls that led to +unsoundness. As such, the `WellFormed(Type<...>)` predicate does not need +to be co-inductive. + +This asymmetry optimization is useful because in a real Rust program, we have +to check the well-formedness of types very often (e.g. for each type which +appears in the body of a function). From 2b8f3d40e1fe4923c3bfe19ce0cb5be00a7824d2 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 21 Oct 2018 18:09:00 +0200 Subject: [PATCH 0370/1812] Fix typos and punctuation Co-Authored-By: scalexm --- src/traits/implied-bounds.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/src/traits/implied-bounds.md b/src/traits/implied-bounds.md index 1feb84e3b..6f033e1b1 100644 --- a/src/traits/implied-bounds.md +++ b/src/traits/implied-bounds.md @@ -45,7 +45,7 @@ fn main() { } ``` -hence we don't want to repeat where clauses for input types because that would +Hence, we don't want to repeat where clauses for input types because that would sort of duplicate the work of the programmer, having to verify that their types are well-formed both when calling the function and when using them in the arguments of their function. The same reasoning applies when using an `impl`. @@ -75,15 +75,15 @@ fn fun_with_copy(x: T) { } ``` -The rationale for implied bounds for traits is that if a type implement `Copy`, -that is if there exists an `impl Copy` for that type, there *ought* to exist +The rationale for implied bounds for traits is that if a type implements `Copy`, +that is, if there exists an `impl Copy` for that type, there *ought* to exist an `impl Clone` for that type, otherwise the compiler would have reported an error in the first place. So again, if we were forced to repeat the additionnal `where SomeType: Clone` everywhere whereas we already know that `SomeType: Copy` hold, we would kind of duplicate the verification work. Implied bounds are not yet completely enforced in rustc, at the moment it only -works for outlive requirements, super trait bounds and bounds on associated +works for outlive requirements, super trait bounds, and bounds on associated types. The full RFC can be found [here][RFC]. We'll give here a brief view of how implied bounds work and why we chose to implement it that way. The complete set of lowering rules can be found in the corresponding @@ -155,7 +155,7 @@ implied bounds from impls. Suppose we know that a type `SomeType<...>` implements `Bar` and we want to deduce that `SomeType<...>` must also implement `Foo`. -There are two possibilities: first one, we have enough information about +There are two possibilities: first, we have enough information about `SomeType<...>` to see that there exists a `Bar` impl in the program which covers `SomeType<...>`, for example a plain `impl<...> Bar for SomeType<...>`. Then if the compiler has done its job correctly, there *must* exist a `Foo` @@ -172,7 +172,7 @@ fn foo() { } ``` -that is, the information that `T` implements `Bar` here comes from the +That is, the information that `T` implements `Bar` here comes from the *environment*. The environment is the set of things that we assume to be true when we type check some Rust declaration. In that case, what we assume is that `T: Bar`. Then at that point, we might authorize ourselves to have some kind @@ -182,8 +182,8 @@ only be done within our `foo` function in order to avoid the earlier problem where we had a global clause. We can apply these local reasonings everywhere we can have an environment --- i.e. when we can write where clauses -- that is inside impls, -trait declarations and type declarations. +-- i.e. when we can write where clauses -- that is, inside impls, +trait declarations, and type declarations. ## Computing implied bounds with `FromEnv` @@ -224,7 +224,7 @@ forall { FromEnv(T: A) :- FromEnv(T: B). } forall { Implemented(T: C) :- FromEnv(T: C). } forall { FromEnv(T: C) :- FromEnv(T: C). } ``` -So these clauses are defined globally (that is they are available from +So these clauses are defined globally (that is, they are available from everywhere in the program) but they cannot be used because the hypothesis is always of the form `FromEnv(...)` which is a bit special. Indeed, as indicated by the name, `FromEnv(...)` facts can **only** come from the @@ -266,7 +266,7 @@ impl Bar for Y { ``` We must define what "legal" and "illegal" mean. For this, we introduce another predicate: `WellFormed(Type: Trait)`. We say that the trait reference -`Type: Trait` is well-formed is `Type` meets the bounds written on the +`Type: Trait` is well-formed if `Type` meets the bounds written on the `Trait` declaration. For each impl we write, assuming that the where clauses declared on the impl hold, the compiler tries to prove that the corresponding trait reference is well-formed. The impl is legal if the compiler manages to do @@ -433,7 +433,7 @@ impl Foo for i32 { The `Foo` trait definition and the `impl Foo for i32` are perfectly valid Rust: we're kind of recursively using our `Foo` impl in order to show that the associated value indeed implements `Foo`, but that's ok. But if we -translates this to our well-formedness setting, the compiler proof process +translate this to our well-formedness setting, the compiler proof process inside the `Foo` impl is the following: it starts with proving that the well-formedness goal `WellFormed(i32: Foo)` is true. In order to do that, it must prove the following goals: `Implemented(i32: Foo)` and From 39cdd4f9206349c21b019ba4246d4920b4c94204 Mon Sep 17 00:00:00 2001 From: scalexm Date: Sun, 21 Oct 2018 18:30:07 +0200 Subject: [PATCH 0371/1812] Clarify wording --- src/traits/implied-bounds.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/src/traits/implied-bounds.md b/src/traits/implied-bounds.md index 6f033e1b1..f32c9d0cb 100644 --- a/src/traits/implied-bounds.md +++ b/src/traits/implied-bounds.md @@ -26,9 +26,11 @@ fn loud_insert(set: &mut HashSet, item: K) { } ``` -Note that in the `loud_insert` example, `HashSet` is not the type of an -argument of the `loud_insert` function, it only *appears* in the argument type -`&mut HashSet`. +Note that in the `loud_insert` example, `HashSet` is not the type +of the `set` argument of `loud_insert`, it only *appears* in the +argument type `&mut HashSet`: we care about every type appearing +in the function's header (the header is the signature without the return type), +not only types of the function's arguments. The rationale for applying implied bounds to input types is that, for example, in order to call the `loud_insert` function above, the programmer must have @@ -52,7 +54,7 @@ arguments of their function. The same reasoning applies when using an `impl`. Similarly, given the following trait declaration: ```rust,ignore -trait Copy where Self: Clone { +trait Copy where Self: Clone { // desugared version of `Copy: Clone` ... } ``` @@ -75,11 +77,11 @@ fn fun_with_copy(x: T) { } ``` -The rationale for implied bounds for traits is that if a type implements `Copy`, -that is, if there exists an `impl Copy` for that type, there *ought* to exist -an `impl Clone` for that type, otherwise the compiler would have reported an -error in the first place. So again, if we were forced to repeat the additionnal -`where SomeType: Clone` everywhere whereas we already know that +The rationale for implied bounds for traits is that if a type implements +`Copy`, that is, if there exists an `impl Copy` for that type, there *ought* +to exist an `impl Clone` for that type, otherwise the compiler would have +reported an error in the first place. So again, if we were forced to repeat the +additionnal `where SomeType: Clone` everywhere whereas we already know that `SomeType: Copy` hold, we would kind of duplicate the verification work. Implied bounds are not yet completely enforced in rustc, at the moment it only From 2fd124856dc3a17184a57837c8710b184fbb879d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 22 Oct 2018 12:48:58 -0500 Subject: [PATCH 0372/1812] Add a note on bisecting --- src/compiler-debugging.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index d1171e0e0..aca7f7424 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -384,3 +384,7 @@ create a minimal working example with Godbolt. Go to [env-logger]: https://docs.rs/env_logger/0.4.3/env_logger/ + +## Narrowing (Bisecting) Regressions + +The [cargo-bisect-rustc](https://github.com/rust-lang-nursery/cargo-bisect-rustc) tool can be used as a quick and easy way to find exactly which PR caused a change in `rustc` behavior. It automatically downloads `rustc` PR artifacts and tests them against a project you provide until it finds the regression. You can then look at the PR to get more context on *why* it was changed. See [this tutorial](https://github.com/rust-lang-nursery/cargo-bisect-rustc/blob/master/TUTORIAL.md) on how to use it. From 607a58f8d2f56068ac1cf60c550d54f3ee6d90c6 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Wed, 24 Oct 2018 15:16:12 -0400 Subject: [PATCH 0373/1812] issue_100_4 Updated the rustc documentation location --- src/compiler-documenting.md | 12 +++++++++--- src/how-to-build-and-run.md | 6 ++++++ 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/src/compiler-documenting.md b/src/compiler-documenting.md index bf63c0120..97636fad5 100644 --- a/src/compiler-documenting.md +++ b/src/compiler-documenting.md @@ -19,7 +19,7 @@ available like the standard library. There’s two ways to go about this. ./x.py doc --stage 1 ``` -First the compiler and rustdoc get built to make sure everything is okay +First the compiler and rustdoc get built to make sure everything is okay and then it documents the files. ## Document specific components @@ -52,5 +52,11 @@ When you want to build the compiler docs as well run this command: ./x.py doc ``` -This will see that the docs and compiler-docs options are set to true -and build the normally hidden compiler docs! \ No newline at end of file +This will see that the docs and compiler-docs options are set to true +and build the normally hidden compiler docs! + +### Compiler Documentation + +The documentation for the rust components are found at [rustc doc]. + +[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ \ No newline at end of file diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 4315cd708..62461d3ef 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -330,3 +330,9 @@ everything up then you only need to run one command! ```bash > ./x.py clean ``` + +### Compiler Documentation + +The documentation for the rust components are found at [rustc doc]. + +[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ \ No newline at end of file From 875905587687c5582399cd9fbeacc5f8e1cb56c9 Mon Sep 17 00:00:00 2001 From: csmoe <35686186+csmoe@users.noreply.github.com> Date: Wed, 24 Oct 2018 14:37:33 +0800 Subject: [PATCH 0374/1812] clean up skolemiza in glossary --- src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 5c7d82741..04d35777f 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -53,7 +53,7 @@ rib | a data structure in the name resolver that keeps trac sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -skolemization | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](../borrow_check/region_inference.html#skol) for more details. +placeholder | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference.html#placeholder) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) From a07a6de51d2eb14f068ad0a5792385627a1cd505 Mon Sep 17 00:00:00 2001 From: csmoe <35686186+csmoe@users.noreply.github.com> Date: Wed, 24 Oct 2018 14:43:38 +0800 Subject: [PATCH 0375/1812] clean up skolemiza in borrow_ck --- src/borrow_check/region_inference.md | 82 ++++++++++++++-------------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 5a09f0bb0..617133000 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -78,19 +78,19 @@ The kinds of region elements are as follows: etc) control-flow graph. - Similarly, there is an element denoted `end('static)` corresponding to the remainder of program execution after this function returns. -- There is an element `!1` for each skolemized region `!1`. This +- There is an element `!1` for each placeholder region `!1`. This corresponds (intuitively) to some unknown set of other elements – - for details on skolemization, see the section - [skolemization and universes](#skol). + for details on placeholder, see the section + [placeholder and universes](#placeholder). ## Causal tracking *to be written* – describe how we can extend the values of a variable with causal tracking etc - + -## Skolemization and universes +## Placeholders and universes (This section describes ongoing work that hasn't landed yet.) @@ -117,7 +117,7 @@ for its argument, and `bar` wants to be given a function that that accepts **any** reference (so it can call it with something on its stack, for example). But *how* do we reject it and *why*? -### Subtyping and skolemization +### Subtyping and Placeholder When we type-check `main`, and in particular the call `bar(foo)`, we are going to wind up with a subtyping relationship like this one: @@ -129,10 +129,10 @@ the type of `foo` the type `bar` expects ``` We handle this sort of subtyping by taking the variables that are -bound in the supertype and **skolemizing** them: this means that we +bound in the supertype and **placeholder** them: this means that we replace them with [universally quantified](../appendix/background.html#quantified) -representatives, written like `!1`. We call these regions "skolemized +representatives, written like `!1`. We call these regions "placeholder regions" – they represent, basically, "some unknown region". Once we've done that replacement, we have the following relation: @@ -163,7 +163,7 @@ should yield up an error (eventually). ### What is a universe -In the previous section, we introduced the idea of a skolemized +In the previous section, we introduced the idea of a placeholder region, and we denoted it `!1`. We call this number `1` the **universe index**. The idea of a "universe" is that it is a set of names that are in scope within some type or at some point. Universes are formed @@ -198,7 +198,7 @@ fn bar<'a, T>(t: &'a T) { ``` Here, the name `'b` is not part of the root universe. Instead, when we -"enter" into this `for<'b>` (e.g., by skolemizing it), we will create +"enter" into this `for<'b>` (e.g., by placeholder it), we will create a child universe of the root, let's call it U1: ```text @@ -274,25 +274,25 @@ Here, the only way for the two foralls to interact would be through X, but neither Y nor Z are in scope when X is declared, so its value cannot reference either of them. -### Universes and skolemized region elements +### Universes and placeholder region elements But where does that error come from? The way it happens is like this. When we are constructing the region inference context, we can tell -from the type inference context how many skolemized variables exist +from the type inference context how many placeholder variables exist (the `InferCtxt` has an internal counter). For each of those, we create a corresponding universal region variable `!n` and a "region -element" `skol(n)`. This corresponds to "some unknown set of other -elements". The value of `!n` is `{skol(n)}`. +element" `placeholder(n)`. This corresponds to "some unknown set of other +elements". The value of `!n` is `{placeholder(n)}`. At the same time, we also give each existential variable a **universe** (also taken from the `InferCtxt`). This universe -determines which skolemized elements may appear in its value: For -example, a variable in universe U3 may name `skol(1)`, `skol(2)`, and -`skol(3)`, but not `skol(4)`. Note that the universe of an inference +determines which placeholder elements may appear in its value: For +example, a variable in universe U3 may name `placeholder(1)`, `placeholder(2)`, and +`placeholder(3)`, but not `placeholder(4)`. Note that the universe of an inference variable controls what region elements **can** appear in its value; it does not say region elements **will** appear. -### Skolemization and outlives constraints +### Placeholders and outlives constraints In the region inference engine, outlives constraints have the form: @@ -313,23 +313,23 @@ are present in `value(V2)` and we add those nodes to `value(V1)`. If we reach a return point, we add in any `end(X)` elements. That part remains unchanged. -But then *after that* we want to iterate over the skolemized `skol(x)` +But then *after that* we want to iterate over the placeholder `placeholder(x)` elements in V2 (each of those must be visible to `U(V2)`, but we should be able to just assume that is true, we don't have to check it). We have to ensure that `value(V1)` outlives each of those -skolemized elements. +placeholder elements. Now there are two ways that could happen. First, if `U(V1)` can see -the universe `x` (i.e., `x <= U(V1)`), then we can just add `skol(x)` +the universe `x` (i.e., `x <= U(V1)`), then we can just add `placeholder(x)` to `value(V1)` and be done. But if not, then we have to approximate: -we may not know what set of elements `skol(x)` represents, but we +we may not know what set of elements `placeholder(x)` represents, but we should be able to compute some sort of **upper bound** B for it – -some region B that outlives `skol(x)`. For now, we'll just use +some region B that outlives `placeholder(x)`. For now, we'll just use `'static` for that (since it outlives everything) – in the future, we can sometimes be smarter here (and in fact we have code for doing this already in other contexts). Moreover, since `'static` is in the root universe U0, we know that all variables can see it – so basically if -we find that `value(V2)` contains `skol(x)` for some universe `x` +we find that `value(V2)` contains `placeholder(x)` for some universe `x` that `V1` can't see, then we force `V1` to `'static`. ### Extending the "universal regions" check @@ -337,20 +337,20 @@ that `V1` can't see, then we force `V1` to `'static`. After all constraints have been propagated, the NLL region inference has one final check, where it goes over the values that wound up being computed for each universal region and checks that they did not get -'too large'. In our case, we will go through each skolemized region -and check that it contains *only* the `skol(u)` element it is known to +'too large'. In our case, we will go through each placeholder region +and check that it contains *only* the `placeholder(u)` element it is known to outlive. (Later, we might be able to know that there are relationships -between two skolemized regions and take those into account, as we do +between two placeholder regions and take those into account, as we do for universal regions from the fn signature.) Put another way, the "universal regions" check can be considered to be checking constraints like: ```text -{skol(1)}: V1 +{placeholder(1)}: V1 ``` -where `{skol(1)}` is like a constant set, and V1 is the variable we +where `{placeholder(1)}` is like a constant set, and V1 is the variable we made to represent the `!1` region. ## Back to our example @@ -365,7 +365,7 @@ fn(&'static u32) <: fn(&'!1 u32) @ P // this point P is not imp't here The region inference engine will create a region element domain like this: ```text -{ CFG; end('static); skol(1) } +{ CFG; end('static); placeholder(1) } --- ------------ ------- from the universe `!1` | 'static is always in scope all points in the CFG; not especially relevant here @@ -377,7 +377,7 @@ will have initial values like so: ```text Vs = { CFG; end('static) } // it is in U0, so can't name anything else -V1 = { skol(1) } +V1 = { placeholder(1) } ``` From the subtyping constraint above, we would have an outlives constraint like @@ -390,7 +390,7 @@ To process this, we would grow the value of V1 to include all of Vs: ```text Vs = { CFG; end('static) } -V1 = { CFG; end('static), skol(1) } +V1 = { CFG; end('static), placeholder(1) } ``` At that point, constraint propagation is complete, because all the @@ -411,7 +411,7 @@ for<'a> fn(&'a u32, &'a u32) for<'b, 'c> fn(&'b u32, &'c u32) ``` -Here we would skolemize the supertype, as before, yielding: +Here we would placeholer the supertype, as before, yielding: ```text for<'a> fn(&'a u32, &'a u32) @@ -476,7 +476,7 @@ an error. That's good: the problem is that we've gone from a fn that promises to return one of its two arguments, to a fn that is promising to return the first one. That is unsound. Let's see how it plays out. -First, we skolemize the supertype: +First, we placeholder the supertype: ```text for<'a> fn(&'a u32, &'a u32) -> &'a u32 @@ -512,26 +512,26 @@ V3: V1 Those variables will have these initial values: ```text -V1 in U1 = {skol(1)} -V2 in U2 = {skol(2)} +V1 in U1 = {placeholder(1)} +V2 in U2 = {placeholder(2)} V3 in U2 = {} ``` -Now because of the `V3: V1` constraint, we have to add `skol(1)` into `V3` (and +Now because of the `V3: V1` constraint, we have to add `placeholder(1)` into `V3` (and indeed it is visible from `V3`), so we get: ```text -V3 in U2 = {skol(1)} +V3 in U2 = {placeholder(1)} ``` then we have this constraint `V2: V3`, so we wind up having to enlarge -`V2` to include `skol(1)` (which it can also see): +`V2` to include `placeholder(1)` (which it can also see): ```text -V2 in U2 = {skol(1), skol(2)} +V2 in U2 = {placeholder(1), placeholder(2)} ``` Now constraint propagation is done, but when we check the outlives -relationships, we find that `V2` includes this new element `skol(1)`, +relationships, we find that `V2` includes this new element `placeholder(1)`, so we report an error. From 294fcd31acab74f30172cff042745138f014811c Mon Sep 17 00:00:00 2001 From: csmoe <35686186+csmoe@users.noreply.github.com> Date: Wed, 24 Oct 2018 14:46:43 +0800 Subject: [PATCH 0376/1812] clean up skolemiza in traits --- src/traits/associated-types.md | 2 +- src/traits/caching.md | 6 +++--- src/traits/hrtb.md | 28 ++++++++++++++-------------- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md index 3330ce809..1fffa3ff8 100644 --- a/src/traits/associated-types.md +++ b/src/traits/associated-types.md @@ -154,7 +154,7 @@ The key point is that, on success, unification can also give back to us a set of subgoals that still remain to be proven (it can also give back region constraints, but those are not relevant here). -Whenever unification encounters an (unskolemized!) associated type +Whenever unification encounters an (un-placeholder!) associated type projection P being equated with some other type T, it always succeeds, but it produces a subgoal `ProjectionEq(P = T)` that is propagated back up. Thus it falls to the ordinary workings of the trait system diff --git a/src/traits/caching.md b/src/traits/caching.md index f84539509..7978306d1 100644 --- a/src/traits/caching.md +++ b/src/traits/caching.md @@ -11,10 +11,10 @@ but *replay* its effects on the type variables. ## An example The high-level idea of how the cache works is that we first replace -all unbound inference variables with skolemized versions. Therefore, +all unbound inference variables with placeholder versions. Therefore, if we had a trait reference `usize : Foo<$t>`, where `$t` is an unbound inference variable, we might replace it with `usize : Foo<$0>`, where -`$0` is a skolemized type. We would then look this up in the cache. +`$0` is a placeholder type. We would then look this up in the cache. If we found a hit, the hit would tell us the immediate next step to take in the selection process (e.g. apply impl #22, or apply where @@ -37,7 +37,7 @@ we would [confirm] `ImplCandidate(22)`, which would (as a side-effect) unify [confirm]: ./resolution.html#confirmation Now, at some later time, we might come along and see a `usize : -Foo<$u>`. When skolemized, this would yield `usize : Foo<$0>`, just as +Foo<$u>`. When placeholder, this would yield `usize : Foo<$0>`, just as before, and hence the cache lookup would succeed, yielding `ImplCandidate(22)`. We would confirm `ImplCandidate(22)` which would (as a side-effect) unify `$u` with `isize`. diff --git a/src/traits/hrtb.md b/src/traits/hrtb.md index 7f77f274c..9986bbb16 100644 --- a/src/traits/hrtb.md +++ b/src/traits/hrtb.md @@ -5,7 +5,7 @@ bounds*. An example of such a bound is `for<'a> MyTrait<&'a isize>`. Let's walk through how selection on higher-ranked trait references works. -## Basic matching and skolemization leaks +## Basic matching and placeholder leaks Suppose we have a trait `Foo`: @@ -36,11 +36,11 @@ to the subtyping for higher-ranked types (which is described [here][hrsubtype] and also in a [paper by SPJ]. If you wish to understand higher-ranked subtyping, we recommend you read the paper). There are a few parts: -**TODO**: We should define _skolemize_. +**TODO**: We should define _placeholder_. 1. _Skolemize_ the obligation. -2. Match the impl against the skolemized obligation. -3. Check for _skolemization leaks_. +2. Match the impl against the placeholder obligation. +3. Check for _placeholder leaks_. [hrsubtype]: https://github.com/rust-lang/rust/tree/master/src/librustc/infer/higher_ranked/README.md [paper by SPJ]: http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ @@ -48,8 +48,8 @@ subtyping, we recommend you read the paper). There are a few parts: So let's work through our example. 1. The first thing we would do is to -skolemize the obligation, yielding `AnyInt : Foo<&'0 isize>` (here `'0` -represents skolemized region #0). Note that we now have no quantifiers; +placeholder the obligation, yielding `AnyInt : Foo<&'0 isize>` (here `'0` +represents placeholder region #0). Note that we now have no quantifiers; in terms of the compiler type, this changes from a `ty::PolyTraitRef` to a `TraitRef`. We would then create the `TraitRef` from the impl, using fresh variables for it's bound regions (and thus getting @@ -59,10 +59,10 @@ using fresh variables for it's bound regions (and thus getting we relate the two trait refs, yielding a graph with the constraint that `'0 == '$a`. -3. Finally, we check for skolemization "leaks" – a -leak is basically any attempt to relate a skolemized region to another -skolemized region, or to any region that pre-existed the impl match. -The leak check is done by searching from the skolemized region to find +3. Finally, we check for placeholder "leaks" – a +leak is basically any attempt to relate a placeholder region to another +placeholder region, or to any region that pre-existed the impl match. +The leak check is done by searching from the placeholder region to find the set of regions that it is related to in any way. This is called the "taint" set. To pass the check, that set must consist *solely* of itself and region variables from the impl. If the taint set includes @@ -78,7 +78,7 @@ impl Foo<&'static isize> for StaticInt; We want the obligation `StaticInt : for<'a> Foo<&'a isize>` to be considered unsatisfied. The check begins just as before. `'a` is -skolemized to `'0` and the impl trait reference is instantiated to +placeholder to `'0` and the impl trait reference is instantiated to `Foo<&'static isize>`. When we relate those two, we get a constraint like `'static == '0`. This means that the taint set for `'0` is `{'0, 'static}`, which fails the leak check. @@ -111,16 +111,16 @@ Now let's say we have a obligation `Baz: for<'a> Foo<&'a isize>` and we match this impl. What obligation is generated as a result? We want to get `Baz: for<'a> Bar<&'a isize>`, but how does that happen? -After the matching, we are in a position where we have a skolemized +After the matching, we are in a position where we have a placeholder substitution like `X => &'0 isize`. If we apply this substitution to the impl obligations, we get `F : Bar<&'0 isize>`. Obviously this is not -directly usable because the skolemized region `'0` cannot leak out of +directly usable because the placeholder region `'0` cannot leak out of our computation. What we do is to create an inverse mapping from the taint set of `'0` back to the original bound region (`'a`, here) that `'0` resulted from. (This is done in `higher_ranked::plug_leaks`). We know that the -leak check passed, so this taint set consists solely of the skolemized +leak check passed, so this taint set consists solely of the placeholder region itself plus various intermediate region variables. We then walk the trait-reference and convert every region in that taint set back to a late-bound region, so in this case we'd wind up with From 695728741e87065800dd03eff3b398040cfc8aa9 Mon Sep 17 00:00:00 2001 From: csmoe Date: Thu, 25 Oct 2018 11:01:08 +0800 Subject: [PATCH 0377/1812] replace bound region with placeholder --- src/appendix/glossary.md | 2 +- src/borrow_check/region_inference.md | 15 +++++++-------- src/traits/hrtb.md | 14 +++++++------- 3 files changed, 15 insertions(+), 16 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 04d35777f..82d6f9a21 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -53,7 +53,7 @@ rib | a data structure in the name resolver that keeps trac sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -placeholder | a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference.html#placeholder) for more details. +placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference.html#placeholder) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 617133000..c754a5000 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -80,8 +80,8 @@ The kinds of region elements are as follows: to the remainder of program execution after this function returns. - There is an element `!1` for each placeholder region `!1`. This corresponds (intuitively) to some unknown set of other elements – - for details on placeholder, see the section - [placeholder and universes](#placeholder). + for details on placeholders, see the section + [placeholders and universes](#placeholder). ## Causal tracking @@ -117,7 +117,7 @@ for its argument, and `bar` wants to be given a function that that accepts **any** reference (so it can call it with something on its stack, for example). But *how* do we reject it and *why*? -### Subtyping and Placeholder +### Subtyping and Placeholders When we type-check `main`, and in particular the call `bar(foo)`, we are going to wind up with a subtyping relationship like this one: @@ -129,8 +129,7 @@ the type of `foo` the type `bar` expects ``` We handle this sort of subtyping by taking the variables that are -bound in the supertype and **placeholder** them: this means that we -replace them with +bound in the supertype and replace them with [universally quantified](../appendix/background.html#quantified) representatives, written like `!1`. We call these regions "placeholder regions" – they represent, basically, "some unknown region". @@ -198,7 +197,7 @@ fn bar<'a, T>(t: &'a T) { ``` Here, the name `'b` is not part of the root universe. Instead, when we -"enter" into this `for<'b>` (e.g., by placeholder it), we will create +"enter" into this `for<'b>` (e.g., by replace it with a placeholder), we will create a child universe of the root, let's call it U1: ```text @@ -411,7 +410,7 @@ for<'a> fn(&'a u32, &'a u32) for<'b, 'c> fn(&'b u32, &'c u32) ``` -Here we would placeholer the supertype, as before, yielding: +Here we would replace the bound region in the supertype with a placeholder, as before, yielding: ```text for<'a> fn(&'a u32, &'a u32) @@ -476,7 +475,7 @@ an error. That's good: the problem is that we've gone from a fn that promises to return one of its two arguments, to a fn that is promising to return the first one. That is unsound. Let's see how it plays out. -First, we placeholder the supertype: +First, we replace the bound region in the supertype with a placeholder: ```text for<'a> fn(&'a u32, &'a u32) -> &'a u32 diff --git a/src/traits/hrtb.md b/src/traits/hrtb.md index 9986bbb16..b56275881 100644 --- a/src/traits/hrtb.md +++ b/src/traits/hrtb.md @@ -36,20 +36,20 @@ to the subtyping for higher-ranked types (which is described [here][hrsubtype] and also in a [paper by SPJ]. If you wish to understand higher-ranked subtyping, we recommend you read the paper). There are a few parts: -**TODO**: We should define _placeholder_. - -1. _Skolemize_ the obligation. -2. Match the impl against the placeholder obligation. +1. replace bound regions in the obligation with placeholders. +2. Match the impl against the [placeholder] obligation. 3. Check for _placeholder leaks_. +[placeholder]: ../appendix/glossary.html#appendix-c-glossary [hrsubtype]: https://github.com/rust-lang/rust/tree/master/src/librustc/infer/higher_ranked/README.md [paper by SPJ]: http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ So let's work through our example. 1. The first thing we would do is to -placeholder the obligation, yielding `AnyInt : Foo<&'0 isize>` (here `'0` -represents placeholder region #0). Note that we now have no quantifiers; +replace the bound region in the obligation with a placeholder, yielding +`AnyInt : Foo<&'0 isize>` (here `'0` represents placeholder region #0). +Note that we now have no quantifiers; in terms of the compiler type, this changes from a `ty::PolyTraitRef` to a `TraitRef`. We would then create the `TraitRef` from the impl, using fresh variables for it's bound regions (and thus getting @@ -78,7 +78,7 @@ impl Foo<&'static isize> for StaticInt; We want the obligation `StaticInt : for<'a> Foo<&'a isize>` to be considered unsatisfied. The check begins just as before. `'a` is -placeholder to `'0` and the impl trait reference is instantiated to +replaced with a placeholder `'0` and the impl trait reference is instantiated to `Foo<&'static isize>`. When we relate those two, we get a constraint like `'static == '0`. This means that the taint set for `'0` is `{'0, 'static}`, which fails the leak check. From 8cbf135744e84a84d7e4c8f0e6d20fce7cce85e0 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 25 Oct 2018 11:33:30 +0800 Subject: [PATCH 0378/1812] Update src/borrow_check/region_inference.md Co-Authored-By: csmoe --- src/borrow_check/region_inference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index c754a5000..0484b14d6 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -129,7 +129,7 @@ the type of `foo` the type `bar` expects ``` We handle this sort of subtyping by taking the variables that are -bound in the supertype and replace them with +bound in the supertype and replacing them with [universally quantified](../appendix/background.html#quantified) representatives, written like `!1`. We call these regions "placeholder regions" – they represent, basically, "some unknown region". From bd8d3f5f30676af7b3513416b1b5cd9bfb7fc1a3 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 25 Oct 2018 11:33:33 +0800 Subject: [PATCH 0379/1812] Update src/borrow_check/region_inference.md Co-Authored-By: csmoe --- src/borrow_check/region_inference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 0484b14d6..95c2bc804 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -197,7 +197,7 @@ fn bar<'a, T>(t: &'a T) { ``` Here, the name `'b` is not part of the root universe. Instead, when we -"enter" into this `for<'b>` (e.g., by replace it with a placeholder), we will create +"enter" into this `for<'b>` (e.g., by replacing it with a placeholder), we will create a child universe of the root, let's call it U1: ```text From e35e081b521209148ac833af02b543fb5c7da344 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 25 Oct 2018 11:33:38 +0800 Subject: [PATCH 0380/1812] Update src/traits/hrtb.md Co-Authored-By: csmoe --- src/traits/hrtb.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/hrtb.md b/src/traits/hrtb.md index b56275881..8b3a9f649 100644 --- a/src/traits/hrtb.md +++ b/src/traits/hrtb.md @@ -36,7 +36,7 @@ to the subtyping for higher-ranked types (which is described [here][hrsubtype] and also in a [paper by SPJ]. If you wish to understand higher-ranked subtyping, we recommend you read the paper). There are a few parts: -1. replace bound regions in the obligation with placeholders. +1. Replace bound regions in the obligation with placeholders. 2. Match the impl against the [placeholder] obligation. 3. Check for _placeholder leaks_. From 4196710286c120e1ba9f3e3fcbabdf96307b11b0 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 25 Oct 2018 11:33:44 +0800 Subject: [PATCH 0381/1812] Update src/traits/caching.md Co-Authored-By: csmoe --- src/traits/caching.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/caching.md b/src/traits/caching.md index 7978306d1..c963aafc4 100644 --- a/src/traits/caching.md +++ b/src/traits/caching.md @@ -37,7 +37,7 @@ we would [confirm] `ImplCandidate(22)`, which would (as a side-effect) unify [confirm]: ./resolution.html#confirmation Now, at some later time, we might come along and see a `usize : -Foo<$u>`. When placeholder, this would yield `usize : Foo<$0>`, just as +Foo<$u>`. When replaced with a placeholder, this would yield `usize : Foo<$0>`, just as before, and hence the cache lookup would succeed, yielding `ImplCandidate(22)`. We would confirm `ImplCandidate(22)` which would (as a side-effect) unify `$u` with `isize`. From 34c9d3fc773c47ac90191ba66c692fb9991c9bec Mon Sep 17 00:00:00 2001 From: Nikita Popov Date: Fri, 26 Oct 2018 14:34:09 +0200 Subject: [PATCH 0382/1812] Update TypeVariants to TyKind This has been renamed in https://github.com/rust-lang/rust/pull/53581. --- src/ty.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ty.md b/src/ty.md index 44017dd5b..fea9afbeb 100644 --- a/src/ty.md +++ b/src/ty.md @@ -99,7 +99,7 @@ fn test_type<'tcx>(ty: Ty<'tcx>) { ``` The `sty` field (the origin of this name is unclear to me; perhaps -structural type?) is of type `TypeVariants<'tcx>`, which is an enum +structural type?) is of type `TyKind<'tcx>`, which is an enum defining all of the different kinds of types in the compiler. > N.B. inspecting the `sty` field on types during type inference can be From 5c67241e1ab4383035cec2a0faa17c97ae51c007 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:15:11 -0500 Subject: [PATCH 0383/1812] Group logic-related things under one section I found the layout to be a bit inconsistent before. This groups anything that touches logic rules under "Lowering to logic". This might be crowding too many things under that section, but it makes more sense to me overall. --- src/SUMMARY.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 213a645ab..9308b7d51 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -38,12 +38,12 @@ - [Goals and clauses](./traits/goals-and-clauses.md) - [Equality and associated types](./traits/associated-types.md) - [Implied bounds](./traits/implied-bounds.md) + - [Well-formedness checking](./traits/wf.md) - [Region constraints](./traits/regions.md) + - [The lowering module in rustc](./traits/lowering-module.md) + - [Lowering rules](./traits/lowering-rules.md) - [Canonical queries](./traits/canonical-queries.md) - [Canonicalization](./traits/canonicalization.md) - - [Lowering rules](./traits/lowering-rules.md) - - [The lowering module in rustc](./traits/lowering-module.md) - - [Well-formedness checking](./traits/wf.md) - [The SLG solver](./traits/slg.md) - [An Overview of Chalk](./traits/chalk-overview.md) - [Bibliography](./traits/bibliography.md) From 9ae8422607397558bd3d397ac3c01a915db24c56 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:22:32 -0500 Subject: [PATCH 0384/1812] Reflect traits chapter structure in index key ideas --- src/traits/index.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/traits/index.md b/src/traits/index.md index 053a26bab..6a0e560a2 100644 --- a/src/traits/index.md +++ b/src/traits/index.md @@ -19,18 +19,18 @@ Trait solving is based around a few key ideas: describes the precise form of rules we use, and [lowering rules](./lowering-rules.html) gives the complete set of lowering rules in a more reference-like form. + - [Lazy normalization](./associated-types.html), which is the + technique we use to accommodate associated types when figuring out + whether types are equal. + - [Region constraints](./regions.html), which are accumulated + during trait solving but mostly ignored. This means that trait + solving effectively ignores the precise regions involved, always – + but we still remember the constraints on them so that those + constraints can be checked by the type checker. - [Canonical queries](./canonical-queries.html), which allow us to solve trait problems (like "is `Foo` implemented for the type `Bar`?") once, and then apply that same result independently in many different inference contexts. -- [Lazy normalization](./associated-types.html), which is the - technique we use to accommodate associated types when figuring out - whether types are equal. -- [Region constraints](./regions.html), which are accumulated - during trait solving but mostly ignored. This means that trait - solving effectively ignores the precise regions involved, always – - but we still remember the constraints on them so that those - constraints can be checked by thet type checker. Note: this is not a complete list of topics. See the sidebar for more. From c4708f8039f325b2f22cb4cc94744615e4529418 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:22:57 -0500 Subject: [PATCH 0385/1812] Traits: Improve index layout, add chalk blurb --- src/traits/index.md | 51 +++++++++++++++++++++++++++++---------------- 1 file changed, 33 insertions(+), 18 deletions(-) diff --git a/src/traits/index.md b/src/traits/index.md index 6a0e560a2..2e3e6715c 100644 --- a/src/traits/index.md +++ b/src/traits/index.md @@ -1,17 +1,26 @@ # Trait solving (new-style) -🚧 This chapter describes "new-style" trait solving. This is still in the -[process of being implemented][wg]; this chapter serves as a kind of -in-progress design document. If you would prefer to read about how the -current trait solver works, check out -[this other chapter](./resolution.html). (By the way, if you -would like to help in hacking on the new solver, you will find -instructions for getting involved in the -[Traits Working Group tracking issue][wg].) 🚧 +> 🚧 This chapter describes "new-style" trait solving. This is still in the +> [process of being implemented][wg]; this chapter serves as a kind of +> in-progress design document. If you would prefer to read about how the +> current trait solver works, check out +> [this other chapter](./resolution.html). 🚧 +> +> By the way, if you would like to help in hacking on the new solver, you will +> find instructions for getting involved in the +> [Traits Working Group tracking issue][wg]. [wg]: https://github.com/rust-lang/rust/issues/48416 -Trait solving is based around a few key ideas: +The new-style trait solver is based on the work done in [chalk][chalk]. Chalk +recasts Rust's trait system explicitly in terms of logic programming. It does +this by "lowering" Rust code into a kind of logic program we can then execute +queries against. + +You can read more about chalk itself in the +[Overview of Chalk](./chalk-overview.md) section. + +Trait solving in rustc is based around a few key ideas: - [Lowering to logic](./lowering-to-logic.html), which expresses Rust traits in terms of standard logical terms. @@ -32,17 +41,23 @@ Trait solving is based around a few key ideas: `Bar`?") once, and then apply that same result independently in many different inference contexts. -Note: this is not a complete list of topics. See the sidebar for more. +> This is not a complete list of topics. See the sidebar for more. +## Ongoing work The design of the new-style trait solving currently happens in two places: -* The [chalk][chalk] repository is where we experiment with new ideas and - designs for the trait system. It basically consists of a unit testing framework - for the correctness and feasibility of the logical rules defining the new-style - trait system. It also provides the [`chalk_engine`][chalk_engine] crate, which - defines the new-style trait solver used both in the unit testing framework and - in rustc. -* Once we are happy with the logical rules, we proceed to implementing them in - rustc. This mainly happens in [`librustc_traits`][librustc_traits]. + +**chalk**. The [chalk][chalk] repository is where we experiment with new ideas +and designs for the trait system. It primarily consists of two parts: +* a unit testing framework + for the correctness and feasibility of the logical rules defining the + new-style trait system. +* the [`chalk_engine`][chalk_engine] crate, which + defines the new-style trait solver used both in the unit testing framework + and in rustc. + +**rustc**. Once we are happy with the logical rules, we proceed to +implementing them in rustc. This mainly happens in +[`librustc_traits`][librustc_traits]. [chalk]: https://github.com/rust-lang-nursery/chalk [chalk_engine]: https://github.com/rust-lang-nursery/chalk/tree/master/chalk-engine From 99a23f84a7b1276ecc280da4ae4aba11f73f5edf Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:31:53 -0500 Subject: [PATCH 0386/1812] Associated types: Mention "lazy normalization" somewhere --- src/traits/associated-types.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md index 1fffa3ff8..23da15228 100644 --- a/src/traits/associated-types.md +++ b/src/traits/associated-types.md @@ -5,7 +5,7 @@ associated types. The full system consists of several moving parts, which we will introduce one by one: - Projection and the `Normalize` predicate -- Skolemization +- Placeholder associated type projections - The `ProjectionEq` predicate - Integration with unification @@ -106,9 +106,10 @@ placeholder associated types (see the `TypeName` enum declared in So far we have seen two ways to answer the question of "When can we consider an associated type projection equal to another type?": -- the `Normalize` predicate could be used to transform associated type - projections when we knew which impl was applicable; -- **placeholder** associated types can be used when we don't. +- the `Normalize` predicate could be used to transform projections when we + knew which impl applied; +- **placeholder** associated types can be used when we don't. This is also + known as **lazy normalization**. We now introduce the `ProjectionEq` predicate to bring those two cases together. The `ProjectionEq` predicate looks like so: From fbb3ec6744e3a010f37e88c260949de6485575b8 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:32:04 -0500 Subject: [PATCH 0387/1812] Associated types: Break up text for readability --- src/traits/associated-types.md | 59 +++++++++++++++++----------------- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md index 23da15228..d35fb71e1 100644 --- a/src/traits/associated-types.md +++ b/src/traits/associated-types.md @@ -14,11 +14,11 @@ which we will introduce one by one: When a trait defines an associated type (e.g., [the `Item` type in the `IntoIterator` trait][intoiter-item]), that type can be referenced by the user using an **associated type -projection** like ` as IntoIterator>::Item`. (Often, -though, people will use the shorthand syntax `T::Item` – presently, -that syntax is expanded during -["type collection"](../type-checking.html) into the explicit form, -though that is something we may want to change in the future.) +projection** like ` as IntoIterator>::Item`. + +> Often, people will use the shorthand syntax `T::Item`. Presently, that +> syntax is expanded during ["type collection"](../type-checking.html) into the +> explicit form, though that is something we may want to change in the future. [intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item @@ -41,10 +41,11 @@ IntoIterator>::Item` to just `u32`. In this case, the projection was a "monomorphic" one – that is, it did not have any type parameters. Monomorphic projections are special -because they can **always** be fully normalized – but often we can -normalize other associated type projections as well. For example, -` as IntoIterator>::Item` (where `?T` is an inference -variable) can be normalized to just `?T`. +because they can **always** be fully normalized. + +Often, we can normalize other associated type projections as well. For +example, ` as IntoIterator>::Item`, where `?T` is an inference +variable, can be normalized to just `?T`. In our logic, normalization is defined by a predicate `Normalize`. The `Normalize` clauses arise only from @@ -60,9 +61,8 @@ forall { where in this case, the one `Implemented` condition is always true. -(An aside: since we do not permit quantification over traits, this is -really more like a family of program clauses, one for each associated -type.) +> Since we do not permit quantification over traits, this is really more like +> a family of program clauses, one for each associated type. We could apply that rule to normalize either of the examples that we've seen so far. @@ -76,17 +76,18 @@ normalized. For example, consider this function: fn foo(...) { ... } ``` -In this context, how would we normalize the type `T::Item`? Without -knowing what `T` is, we can't really do so. To represent this case, we -introduce a type called a **placeholder associated type -projection**. This is written like so `(IntoIterator::Item)`. You -may note that it looks a lot like a regular type (e.g., `Option`), -except that the "name" of the type is `(IntoIterator::Item)`. This is -not an accident: placeholder associated type projections work just like -ordinary types like `Vec` when it comes to unification. That is, -they are only considered equal if (a) they are both references to the -same associated type, like `IntoIterator::Item` and (b) their type -arguments are equal. +In this context, how would we normalize the type `T::Item`? + +Without knowing what `T` is, we can't really do so. To represent this case, +we introduce a type called a **placeholder associated type projection**. This +is written like so: `(IntoIterator::Item)`. + +You may note that it looks a lot like a regular type (e.g., `Option`), +except that the "name" of the type is `(IntoIterator::Item)`. This is not an +accident: placeholder associated type projections work just like ordinary +types like `Vec` when it comes to unification. That is, they are only +considered equal if (a) they are both references to the same associated type, +like `IntoIterator::Item` and (b) their type arguments are equal. Placeholder associated types are never written directly by the user. They are used internally by the trait system only, as we will see @@ -152,16 +153,16 @@ might just fail, in which case we get back `Err(NoSolution)`. This would happen, for example, if we tried to unify `u32` and `i32`. The key point is that, on success, unification can also give back to -us a set of subgoals that still remain to be proven (it can also give +us a set of subgoals that still remain to be proven. (It can also give back region constraints, but those are not relevant here). -Whenever unification encounters an (un-placeholder!) associated type +Whenever unification encounters a non-placeholder associated type projection P being equated with some other type T, it always succeeds, but it produces a subgoal `ProjectionEq(P = T)` that is propagated back up. Thus it falls to the ordinary workings of the trait system to process that constraint. -(If we unify two projections P1 and P2, then unification produces a -variable X and asks us to prove that `ProjectionEq(P1 = X)` and -`ProjectionEq(P2 = X)`. That used to be needed in an older system to -prevent cycles; I rather doubt it still is. -nmatsakis) +> If we unify two projections P1 and P2, then unification produces a +> variable X and asks us to prove that `ProjectionEq(P1 = X)` and +> `ProjectionEq(P2 = X)`. (That used to be needed in an older system to +> prevent cycles; I rather doubt it still is. -nmatsakis) From c41019addab167642d743eebca4ce4a4a0865451 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:24:53 -0500 Subject: [PATCH 0388/1812] Add status of regions --- src/traits/regions.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/traits/regions.md b/src/traits/regions.md index baa3582b6..4657529dc 100644 --- a/src/traits/regions.md +++ b/src/traits/regions.md @@ -1,3 +1,9 @@ # Region constraints -*to be written* +*To be written.* + +Chalk does not have the concept of region constraints, and as of this +writing, work on rustc was not far enough to worry about them. + +In the meantime, you can read about region constraints in the +[type inference](../type-inference.html#region-constraints) section. From 2de4dc7a12c2945454d958672c908b68d3495a75 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 24 Oct 2018 21:30:33 -0500 Subject: [PATCH 0389/1812] Get excited --- src/traits/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/index.md b/src/traits/index.md index 2e3e6715c..84f812394 100644 --- a/src/traits/index.md +++ b/src/traits/index.md @@ -8,7 +8,7 @@ > > By the way, if you would like to help in hacking on the new solver, you will > find instructions for getting involved in the -> [Traits Working Group tracking issue][wg]. +> [Traits Working Group tracking issue][wg]! [wg]: https://github.com/rust-lang/rust/issues/48416 From 74e2af231be0f1ff3350271b3624568c4244ef2d Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Fri, 26 Oct 2018 13:42:14 -0500 Subject: [PATCH 0390/1812] Put "well-formedness checking" under "lowering rules" This was also intended to be a reference chapter, according to @scalexm. --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 9308b7d51..efe963c3f 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -38,10 +38,10 @@ - [Goals and clauses](./traits/goals-and-clauses.md) - [Equality and associated types](./traits/associated-types.md) - [Implied bounds](./traits/implied-bounds.md) - - [Well-formedness checking](./traits/wf.md) - [Region constraints](./traits/regions.md) - [The lowering module in rustc](./traits/lowering-module.md) - [Lowering rules](./traits/lowering-rules.md) + - [Well-formedness checking](./traits/wf.md) - [Canonical queries](./traits/canonical-queries.md) - [Canonicalization](./traits/canonicalization.md) - [The SLG solver](./traits/slg.md) From 34af41dddb22bcdb594de0ccb9296ac459398b78 Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Fri, 26 Oct 2018 12:16:25 -0600 Subject: [PATCH 0391/1812] Document the rust-lldb directive Commit ac33b2e578de58016271012452e4f1be6af9d516 added a `rust-lldb` directive to restrict the lldb part of a debuginfo test to only versions of lldb that include the Rust plugin. --- src/tests/adding.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index 1120315b9..580741ccf 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -158,6 +158,8 @@ source. this test; see also `ignore-gdb-version` * `min-lldb-version` specifies the minimum lldb version required for this test +* `rust-lldb` causes the lldb part of the test to only be run if the + lldb in use contains the Rust plugin * `no-system-llvm` causes the test to be ignored if the system llvm is used * `min-llvm-version` specifies the minimum llvm version required for this test From 462b7c3558c3ba85dd001e8c1239cfdcd4165b42 Mon Sep 17 00:00:00 2001 From: scalexm Date: Wed, 17 Oct 2018 20:15:19 +0200 Subject: [PATCH 0392/1812] Write well-formedness checking chapter --- src/traits/wf.md | 268 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 263 insertions(+), 5 deletions(-) diff --git a/src/traits/wf.md b/src/traits/wf.md index c002b8cc1..cd0fb5564 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -1,11 +1,269 @@ # Well-formedness checking -This chapter is mostly *to be written*. WF checking, in short, has the -job of checking that the various declarations in a Rust program are -well-formed. This is the basis for implied bounds, and partly for that -reason, this checking can be surprisingly subtle! (For example, we +WF checking has the job of checking that the various declarations in a Rust +program are well-formed. This is the basis for implied bounds, and partly for +that reason, this checking can be surprisingly subtle! For example, we have to be sure that each impl proves the WF conditions declared on -the trait.) +the trait. +For each declaration in a Rust program, we will generate a logical goal and try +to prove it using the lowered rules we described in the +[lowering rules](./lowering-rules.md) chapter. If we are able to prove it, we +say that the construct is well-formed. If not, we report an error to the user. +Well-formedness checking happens in the [`src/rules/wf.rs`][wf] module in +chalk. After you have read this chapter, you may find useful to see an +extended set of examples in the [`src/rules/wf/test.rs`][wf_test] submodule. +The new-style WF checking has not been implemented in rustc yet. + +[wf]: https://github.com/rust-lang-nursery/chalk/blob/master/src/rules/wf.rs +[wf_test]: https://github.com/rust-lang-nursery/chalk/blob/master/src/rules/wf/test.rs + +We give here a complete reference of the generated goals for each Rust +declaration. + +In addition with the notations introduced in the chapter about +lowering rules, we'll introduce another notation: when WF checking a +declaration, we'll often have to prove that all types that appear are +well-formed, except type parameters that we always assume to be WF. Hence, +we'll use the following notation: for a type `SomeType<...>`, we denote +`InputTypes(SomeType<...>)` the set of all non-parameter types appearing in +`SomeType<...>`, including `SomeType<...>` itself. + +Examples: +* `InputTypes((u32, f32)) = [u32, f32, (u32, f32)]` +* `InputTypes(Box) = [Box]` +* `InputTypes(Box>) = [Box, Box>]` + +We may naturally extend the `InputTypes` notation to where clauses, for example +`InputTypes(A0: Trait)` is the union of `InputTypes(A0)`, +`InputTypes(A1)`, ..., `InputTypes(An)`. + +# Type definitions + +Given a general type definition: +```rust,ignore +struct Type where WC_type { + field1: A1, + ... + fieldn: An, +} +``` + +we generate the following goal: +``` +forall { + if (FromEnv(WC_type)) { + WellFormed(InputTypes(WC_type)) && + WellFormed(InputTypes(A1)) && + ... + WellFormed(InputTypes(An)) + } +} +``` + +which in English gives: assuming that the where clauses defined on the type +hold, prove that every type appearing in the type definition is well-formed. + +Some examples: +```rust,ignore +struct OnlyClone where T: Clone { + clonable: T, +} +// The only types appearing are type parameters: we have nothing to check, +// the type definition is well-formed. + +struct Foo where T: Clone { + foo: OnlyClone, +} +// The only non-parameter type which appears in this definition is +// `OnlyClone`. The generated goal is the following: +// ``` +// forall { +// if (FromEnv(T: Clone)) { +// WellFormed(OnlyClone) +// } +// } +// ``` +// which is provable. + +struct Bar where OnlyClone: Debug { + bar: i32, +} +// The only non-parameter type which appears in this definition is +// `OnlyClone`. The generated goal is the following: +// ``` +// forall { +// if (FromEnv(OnlyClone: Debug)) { +// WellFormed(OnlyClone) +// } +// } +// ``` +// which is not provable since `WellFormed(OnlyClone)` requires proving +// `Implemented(T: Clone)`, and we are unable to prove that for an unknown `T`. +// Hence, this type definition is considered illegal. An additional +// `where T: Clone` would make it legal. +``` + +# Trait definitions + +Given a general trait definition: +```rust,ignore +trait Trait where WC_trait { + type Assoc: Bounds_assoc where WC_assoc; +} +``` + +we generate the following goal: +```text +forall { + if (FromEnv(WC_trait)) { + WellFormed(InputTypes(WC_trait)) && + + forall { + if (FromEnv(WC_assoc)) { + WellFormed(InputTypes(Bounds_assoc)) && + WellFormed(InputTypes(WC_assoc)) + } + } + } +} +``` + +There is not much to verify in a trait definition. We just want +to prove that the types appearing in the trait definition are well-formed, +under the assumption that the different where clauses hold. + +Some examples: +```rust,ignore +struct OnlyClone { ... } + +trait Foo where T: Clone, OnlyClone: Debug { + ... +} +// The only non-parameter type which appears in this definition is +// `OnlyClone`. The generated goal is the following: +// ``` +// forall { +// if (FromEnv(T: Clone), FromEnv(OnlyClone: Debug)) { +// WellFormed(OnlyClone) +// } +// } +// ``` +// which is provable thanks to the `FromEnv(T: Clone)` assumption. + +trait Bar { + type Assoc: From>; +} +// The only non-parameter type which appears in this definition is +// `OnlyClone`. The generated goal is the following: +// forall { +// WellFormed(OnlyClone) +// } +// which is not provable, hence the trait definition is considered illegal. + +trait Baz { + type Assoc: From> where T: Clone; +} +// The generated goal is now: +// forall { +// if (FromEnv(T: Clone)) { +// WellFormed(OnlyClone) +// } +// } +// which is now provable. +``` + +# Impls + +Now we give ourselves a general impl for the trait defined above: +```rust,ignore +impl Trait for SomeType where WC_impl { + type Assoc = SomeValue where WC_assoc; +} +``` + +Note that here, `WC_assoc` are the same where clauses as those defined on the +associated type definition in the trait declaration, *except* that type +parameters from the trait are substituted with values provided by the impl +(see example below). You cannot add new where clauses. You may omit to write +the where clauses if you want to emphasize the fact that you are actually not +relying on them. + +Some examples to illustrate that: +```rust,ignore +trait Foo { + type Assoc where T: Clone; +} + +struct OnlyClone { ... } + +impl Foo> for () { + // We substitute type parameters from the trait by the ones provided + // by the impl, that is instead of having a `T: Clone` where clause, + // we have an `Option: Clone` one. + type Assoc = OnlyClone> where Option: Clone; +} + +impl Foo for i32 { + // I'm not using the `T: Clone` where clause from the trait, so I can + // omit it. + type Assoc = u32; +} + +impl Foo for f32 { + type Assoc = OnlyClone> where Option: Clone; + // ^^^^^^^^^^^^^^^^^^^^^^ + // this where clause does not exist + // on the original trait decl: illegal +} +``` + +So where clauses on associated types work *exactly* like where clauses on +trait methods: in an impl, we must substitute the parameters from the traits +with values provided by the impl, we may omit them if we don't need them, and +we cannot add new where clauses. + +Now let's see the generated goal for this general impl: +``` +forall { + if (FromEnv(WC_impl), FromEnv(InputTypes(SomeType))) { + WellFormed(SomeType: Trait) && + WellFormed(InputTypes(WC_impl)) && + + forall { + if (FromEnv(WC_assoc)) { + WellFormed(SomeValue: Bounds_assoc) && + WellFormed(InputTypes(SomeValue)) + } + } + } +} +``` + +Here is the most complex goal. As always, a first thing is that assuming that +the various where clauses hold, we prove that every type appearing in the impl +is well-formed, ***except*** types appearing in the receiver type +`SomeType`. Instead, we *assume* that those types are well-formed +(hence the `if (FromEnv(InputTypes(SomeType)))` condition). This is +part of the implied bounds proposal, so that we can rely on the bounds +written on the definition of the `SomeType` type (and that we don't +need to repeat those bounds). + +Next, assuming that the where clauses on the impl `WC_impl` hold and that the +input types of `SomeType` are well-formed, we prove that +`WellFormed(SomeType: Trait)` hold. That is, we want to prove +that `SomeType` verify all the where clauses that might transitively +come from the `Trait` definition (see +[this subsection](./implied-bounds#co-inductiveness-of-wellformed)). + +Lastly, assuming that the where clauses on the associated type `WC_assoc` hold, +we prove that `WellFormed(SomeValue: Bounds_assoc)` hold. Again, we are +not only proving `Implemented(SomeValue: Bounds_assoc)`, but also +all the facts that might transitively come from `Bounds_assoc`. This is because +we allow the use of implied bounds on associated types: if we have +`FromEnv(SomeType: Trait)` in our environment, the lowering rules +chapter indicates that we are able to deduce +`FromEnv(::Assoc: Bounds_assoc)` without knowing what the +precise value of `::Assoc` is. From b5dff2ed5fc7ba2d7966ffd3c9275fd690a50236 Mon Sep 17 00:00:00 2001 From: scalexm Date: Mon, 29 Oct 2018 15:54:37 +0100 Subject: [PATCH 0393/1812] Add some examples for impls --- src/traits/wf.md | 213 ++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 192 insertions(+), 21 deletions(-) diff --git a/src/traits/wf.md b/src/traits/wf.md index cd0fb5564..bd1188d87 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -73,7 +73,9 @@ struct OnlyClone where T: Clone { } // The only types appearing are type parameters: we have nothing to check, // the type definition is well-formed. +``` +```rust,ignore struct Foo where T: Clone { foo: OnlyClone, } @@ -87,23 +89,28 @@ struct Foo where T: Clone { // } // ``` // which is provable. +``` -struct Bar where OnlyClone: Debug { +```rust,ignore +struct Bar where ::Item: Debug { bar: i32, } -// The only non-parameter type which appears in this definition is -// `OnlyClone`. The generated goal is the following: +// The only non-parameter types which appear in this definition are +// `::Item` and `i32`. The generated goal is the following: // ``` // forall { -// if (FromEnv(OnlyClone: Debug)) { -// WellFormed(OnlyClone) +// if (FromEnv(::Item: Debug)) { +// WellFormed(::Item) && +// WellFormed(i32) // } // } // ``` -// which is not provable since `WellFormed(OnlyClone)` requires proving -// `Implemented(T: Clone)`, and we are unable to prove that for an unknown `T`. +// which is not provable since `WellFormed(::Item)` requires +// proving `Implemented(T: Iterator)`, and we are unable to prove that for an +// unknown `T`. +// // Hence, this type definition is considered illegal. An additional -// `where T: Clone` would make it legal. +// `where T: Iterator` would make it legal. ``` # Trait definitions @@ -137,41 +144,47 @@ under the assumption that the different where clauses hold. Some examples: ```rust,ignore -struct OnlyClone { ... } - -trait Foo where T: Clone, OnlyClone: Debug { +trait Foo where T: Iterator, ::Item: Debug { ... } // The only non-parameter type which appears in this definition is -// `OnlyClone`. The generated goal is the following: +// `::Item`. The generated goal is the following: // ``` // forall { -// if (FromEnv(T: Clone), FromEnv(OnlyClone: Debug)) { -// WellFormed(OnlyClone) +// if (FromEnv(T: Iterator), FromEnv(::Item: Debug)) { +// WellFormed(::Item) // } // } // ``` -// which is provable thanks to the `FromEnv(T: Clone)` assumption. +// which is provable thanks to the `FromEnv(T: Iterator)` assumption. +``` +```rust,ignore trait Bar { - type Assoc: From>; + type Assoc: From<::Item>; } // The only non-parameter type which appears in this definition is -// `OnlyClone`. The generated goal is the following: +// `::Item`. The generated goal is the following: +// ``` // forall { -// WellFormed(OnlyClone) +// WellFormed(::Item) // } +// ``` // which is not provable, hence the trait definition is considered illegal. +``` +```rust,ignore trait Baz { - type Assoc: From> where T: Clone; + type Assoc: From<::Item> where T: Iterator; } // The generated goal is now: +// ``` // forall { -// if (FromEnv(T: Clone)) { -// WellFormed(OnlyClone) +// if (FromEnv(T: Iterator)) { +// WellFormed(::Item) // } // } +// ``` // which is now provable. ``` @@ -267,3 +280,161 @@ we allow the use of implied bounds on associated types: if we have chapter indicates that we are able to deduce `FromEnv(::Assoc: Bounds_assoc)` without knowing what the precise value of `::Assoc` is. + +Some examples for the generated goal: +```rust,ignore +trait Copy { } +// `WellFormed(Self: Copy) :- Implemented(Self: Copy).` + +trait Partial where Self: Copy { } +// ``` +// WellFormed(Self: Partial) :- +// Implemented(Self: Partial) && +// WellFormed(Self: Copy). +// ``` + +trait Complete where Self: Partial { } +// ``` +// WellFormed(Self: Complete) :- +// Implemented(Self: Complete) && +// WellFormed(Self: Partial). +// ``` + +impl Partial for T where T: Complete { } +// The generated goal is: +// ``` +// forall { +// if (FromEnv(T: Complete)) { +// WellFormed(T: Partial) +// } +// } +// ``` +// Then proving `WellFormed(T: Partial)` amounts to proving +// `Implemented(T: Partial)` and `Implemented(T: Copy)`. +// Both those facts can be deduced from the `FromEnv(T: Complete)` in our +// environment: this impl is legal. + +impl Complete for T { } +// The generated goal is: +// ``` +// forall { +// WellFormed(T: Complete) +// } +// ``` +// Then proving `WellFormed(T: Complete)` amounts to proving +// `Implemented(T: Complete)`, `Implemented(T: Partial)` and +// `Implemented(T: Copy)`. +// +// `Implemented(T: Complete)` can be proved thanks to the +// `impl Complete for T` blanket impl. +// +// `Implemented(T: Partial)` can be proved thanks to the +// `impl Partial for T where T: Complete` impl and because we know +// `T: Complete` holds. + +// However, `Implemented(T: Copy)` cannot be proved: the impl is illegal. +// An additional `where T: Copy` bound would be sufficient to make that impl +// legal. +``` + +```rust,ignore +trait Bar { } + +impl Bar for T where ::Item: Bar { } +// We have a non-parameter type appearing in the where clauses: +// `::Item`. The generated goal is: +// ``` +// forall { +// if (FromEnv(::Item: Bar)) { +// WellFormed(T: Bar) && +// WellFormed(::Item: Bar) +// } +// } +// ``` +// And `WellFormed(::Item: Bar)` is not provable: we'd need +// an additional `where T: Iterator` for example. +``` + +```rust,ignore +trait Foo { } + +trait Bar { + type Item: Foo; +} + +struct Stuff { } + +impl Bar for Stuff where T: Foo { + type Item = T; +} +// The generated goal is: +// ``` +// forall { +// if (FromEnv(T: Foo)) { +// WellFormed(T: Foo). +// } +// } +// ``` +// which is provable. +``` + +```rust,ignore +trait Debug { ... } +// `WellFormed(Self: Debug) :- Implemented(Self: Debug).` + +struct Box { ... } +impl Debug for Box where T: Debug { ... } + +trait PointerFamily { + type Pointer: Debug where T: Debug; +} +// `WellFormed(Self: PointerFamily) :- Implemented(Self: PointerFamily).` + +struct BoxFamily; + +impl PointerFamily for CowFamily { + type Pointer = Box where T: Debug; +} +// The generated goal is: +// ``` +// forall { +// WellFormed(CowFamily: PointerFamily) && +// +// if (FromEnv(T: Debug)) { +// WellFormed(Box: Debug) && +// WellFormed(Box) +// } +// } +// ``` +// `WellFormed(CowFamily: PointerFamily)` amounts to proving +// `Implemented(CowFamily: PointerFamily)`, which is ok thanks to our impl. +// +// `WellFormed(Box)` is always true (there are no where clauses on the +// `Box` type definition). +// +// Moreover, we have an `impl Debug for Box`, hence +// we can prove `WellFormed(Box: Debug)` and the impl is indeed legal. +``` + +```rust,ignore +trait Foo { + type Assoc; +} + +struct OnlyClone { ... } + +impl Foo for i32 { + type Assoc = OnlyClone; +} +// The generated goal is: +// ``` +// forall { +// WellFormed(i32: Foo) && +// WellFormed(OnlyClone) +// } +// ``` +// however `WellFormed(OnlyClone)` is not provable because it requires +// `Implemented(T: Clone)`. It would be tempting to just add a `where T: Clone` +// bound inside the `impl Foo for i32` block, however we saw that it was +// illegal to add where clauses that didn't come from the trait definition. +``` From 83652097f3f39c007318939355bf45b3fc6671de Mon Sep 17 00:00:00 2001 From: scalexm Date: Mon, 29 Oct 2018 18:58:13 +0100 Subject: [PATCH 0394/1812] Fix code blocks --- src/traits/wf.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/traits/wf.md b/src/traits/wf.md index bd1188d87..4cef9ec84 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -52,7 +52,7 @@ struct Type where WC_type { ``` we generate the following goal: -``` +```text forall { if (FromEnv(WC_type)) { WellFormed(InputTypes(WC_type)) && @@ -239,7 +239,7 @@ with values provided by the impl, we may omit them if we don't need them, and we cannot add new where clauses. Now let's see the generated goal for this general impl: -``` +```text forall { if (FromEnv(WC_impl), FromEnv(InputTypes(SomeType))) { WellFormed(SomeType: Trait) && From e20f283a1e44d3616f80dea2fa5a67282664ed72 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 29 Oct 2018 22:20:26 +0100 Subject: [PATCH 0395/1812] Fix a few things Co-Authored-By: scalexm --- src/traits/wf.md | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/src/traits/wf.md b/src/traits/wf.md index 4cef9ec84..ec391924a 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -23,8 +23,8 @@ The new-style WF checking has not been implemented in rustc yet. We give here a complete reference of the generated goals for each Rust declaration. -In addition with the notations introduced in the chapter about -lowering rules, we'll introduce another notation: when WF checking a +In addition to the notations introduced in the chapter about +lowering rules, we'll introduce another notation: when checking WF of a declaration, we'll often have to prove that all types that appear are well-formed, except type parameters that we always assume to be WF. Hence, we'll use the following notation: for a type `SomeType<...>`, we denote @@ -212,11 +212,11 @@ trait Foo { struct OnlyClone { ... } -impl Foo> for () { +impl Foo> for () { // We substitute type parameters from the trait by the ones provided // by the impl, that is instead of having a `T: Clone` where clause, - // we have an `Option: Clone` one. - type Assoc = OnlyClone> where Option: Clone; + // we have an `Option: Clone` one. + type Assoc = OnlyClone> where Option: Clone; } impl Foo for i32 { @@ -235,7 +235,7 @@ impl Foo for f32 { So where clauses on associated types work *exactly* like where clauses on trait methods: in an impl, we must substitute the parameters from the traits -with values provided by the impl, we may omit them if we don't need them, and +with values provided by the impl, we may omit them if we don't need them, but we cannot add new where clauses. Now let's see the generated goal for this general impl: @@ -255,7 +255,7 @@ forall { } ``` -Here is the most complex goal. As always, a first thing is that assuming that +Here is the most complex goal. As always, first, assuming that the various where clauses hold, we prove that every type appearing in the impl is well-formed, ***except*** types appearing in the receiver type `SomeType`. Instead, we *assume* that those types are well-formed @@ -269,7 +269,7 @@ input types of `SomeType` are well-formed, we prove that `WellFormed(SomeType: Trait)` hold. That is, we want to prove that `SomeType` verify all the where clauses that might transitively come from the `Trait` definition (see -[this subsection](./implied-bounds#co-inductiveness-of-wellformed)). +[this subsection](./implied-bounds.md#co-inductiveness-of-wellformed)). Lastly, assuming that the where clauses on the associated type `WC_assoc` hold, we prove that `WellFormed(SomeValue: Bounds_assoc)` hold. Again, we are @@ -284,6 +284,10 @@ precise value of `::Assoc` is. Some examples for the generated goal: ```rust,ignore trait Copy { } +// This is a program clause that comes from the trait definition above +// and that the trait solver can use for its reasonings. I'm just restating +// it here (and also the few other ones coming just after) so that we have +// them in mind. // `WellFormed(Self: Copy) :- Implemented(Self: Copy).` trait Partial where Self: Copy { } @@ -392,13 +396,13 @@ trait PointerFamily { struct BoxFamily; -impl PointerFamily for CowFamily { +impl PointerFamily for BoxFamily { type Pointer = Box where T: Debug; } // The generated goal is: // ``` // forall { -// WellFormed(CowFamily: PointerFamily) && +// WellFormed(BoxFamily: PointerFamily) && // // if (FromEnv(T: Debug)) { // WellFormed(Box: Debug) && @@ -406,8 +410,8 @@ impl PointerFamily for CowFamily { // } // } // ``` -// `WellFormed(CowFamily: PointerFamily)` amounts to proving -// `Implemented(CowFamily: PointerFamily)`, which is ok thanks to our impl. +// `WellFormed(BoxFamily: PointerFamily)` amounts to proving +// `Implemented(BoxFamily: PointerFamily)`, which is ok thanks to our impl. // // `WellFormed(Box)` is always true (there are no where clauses on the // `Box` type definition). From 90716dc9da1a4d72507d3dea24caab286657df32 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 29 Oct 2018 21:59:17 -0500 Subject: [PATCH 0396/1812] Add section on chalk structure --- src/traits/chalk-overview.md | 65 ++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 3473a0764..029b1460e 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -16,6 +16,71 @@ existing, somewhat ad-hoc implementation into something far more principled and expressive, which should behave better in corner cases, and be much easier to extend. +## Chalk Structure +Chalk has two main "products". The first of these is the +[`chalk_engine`][doc-chalk-engine] crate, which defines the core [SLG +solver][slg]. This is the part rustc uses. + +The rest of chalk can be considered an elaborate testing harness. Chalk is +capable of parsing Rust-like "programs", lowering them to logic, and +performing queries on them. + +Here's a sample session in the chalk repl, chalki. After feeding it our +program, we perform some queries on it. + +```rust,ignore +?- program +Enter a program; press Ctrl-D when finished +| struct Foo { } +| struct Bar { } +| struct Vec { } +| trait Clone { } +| impl Clone for Vec where T: Clone { } +| impl Clone for Foo { } + +?- Vec: Clone +Unique; substitution [], lifetime constraints [] + +?- Vec: Clone +No possible solution. + +?- exists { Vec: Clone } +Ambiguous; no inference guidance +``` + +You can see more examples of programs and queries in the [unit tests][chalk-tests]. + +[chalk-tests]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 + +### Crates +- [**chalk_engine**][doc-chalk-engine]: Defines the core [SLG solver][slg]. +- [**chalk_ir**][doc-chalk-ir]: Defines chalk's internal representation of + types, lifetimes, and goals. +- [**chalk_solve**][doc-chalk-solve]: Combines `chalk_ir` and `chalk_engine`, + effectively. + - [`chalk_engine::context`][engine-context] provides the necessary hooks. +- [**chalk_parse**][doc-chalk-parse]: Defines the raw AST and a parser. +- [**chalk**][doc-chalk]: Brings everything together. Defines the following + modules: + - [`rust_ir`][doc-chalk-rust-ir], containing the "HIR-like" form of the AST + - `rust_ir::lowering`, which converts AST to `rust_ir` + - `rules`, which implements logic rules + converting `rust_ir` to `chalk_ir` + - `coherence`, which implements coherence rules + - Also includes [chalki][doc-chalki], chalk's REPL. + +[Browse source on GitHub](https://github.com/rust-lang-nursery/chalk) + +[engine-context]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/context/index.html + +[doc-chalk-engine]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/index.html +[doc-chalk-ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/index.html +[doc-chalk-solve]: https://rust-lang-nursery.github.io/chalk/doc/chalk_solve/index.html +[doc-chalk-parse]: https://rust-lang-nursery.github.io/chalk/doc/chalk_parse/index.html +[doc-chalk]: https://rust-lang-nursery.github.io/chalk/doc/chalk/index.html +[doc-chalk-rust-ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rules/index.html +[doc-chalki]: https://rust-lang-nursery.github.io/chalk/doc/chalki/index.html + ## Resources * [Chalk Source Code](https://github.com/rust-lang-nursery/chalk) From b62fe76a354ec60835d6e83d6a6ff70b17515fc3 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 29 Oct 2018 22:19:58 -0500 Subject: [PATCH 0397/1812] Move Resources to bottom --- src/traits/chalk-overview.md | 34 +++++++++++++++------------------- 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 029b1460e..20a71ef87 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -50,7 +50,7 @@ Ambiguous; no inference guidance You can see more examples of programs and queries in the [unit tests][chalk-tests]. -[chalk-tests]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 +Next we'll go through each stage required to produce the output above. ### Crates - [**chalk_engine**][doc-chalk-engine]: Defines the core [SLG solver][slg]. @@ -80,22 +80,7 @@ You can see more examples of programs and queries in the [unit tests][chalk-test [doc-chalk]: https://rust-lang-nursery.github.io/chalk/doc/chalk/index.html [doc-chalk-rust-ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rules/index.html [doc-chalki]: https://rust-lang-nursery.github.io/chalk/doc/chalki/index.html - -## Resources - -* [Chalk Source Code](https://github.com/rust-lang-nursery/chalk) -* [Chalk Glossary](https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md) -* The traits section of the rustc guide (you are here) - -### Blog Posts - -* [Lowering Rust traits to logic](http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/) -* [Unification in Chalk, part 1](http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/) -* [Unification in Chalk, part 2](http://smallcultfollowing.com/babysteps/blog/2017/04/23/unification-in-chalk-part-2/) -* [Negative reasoning in Chalk](http://aturon.github.io/blog/2017/04/24/negative-chalk/) -* [Query structure in chalk](http://smallcultfollowing.com/babysteps/blog/2017/05/25/query-structure-in-chalk/) -* [Cyclic queries in chalk](http://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/) -* [An on-demand SLG solver for chalk](http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/) +[chalk-tests]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 ## Parsing @@ -190,9 +175,20 @@ described above. [This](https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/solve/test.rs#L83-L110) is the function that is ultimately called. -## Solver +## More Resources + +* [Chalk Source Code](https://github.com/rust-lang-nursery/chalk) +* [Chalk Glossary](https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md) + +### Blog Posts -See [The SLG Solver][slg]. +* [Lowering Rust traits to logic](http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/) +* [Unification in Chalk, part 1](http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/) +* [Unification in Chalk, part 2](http://smallcultfollowing.com/babysteps/blog/2017/04/23/unification-in-chalk-part-2/) +* [Negative reasoning in Chalk](http://aturon.github.io/blog/2017/04/24/negative-chalk/) +* [Query structure in chalk](http://smallcultfollowing.com/babysteps/blog/2017/05/25/query-structure-in-chalk/) +* [Cyclic queries in chalk](http://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/) +* [An on-demand SLG solver for chalk](http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/) [rustc-issues]: https://github.com/rust-lang-nursery/rustc-guide/issues [chalk]: https://github.com/rust-lang-nursery/chalk From d2238c30b7837ec1bd6411b5a01ef3c8e2807604 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 29 Oct 2018 22:22:14 -0500 Subject: [PATCH 0398/1812] Move Crates section down Nest existing content under Chalk Structure. I think it reads better this way. --- src/traits/chalk-overview.md | 73 ++++++++++++++++++++---------------- 1 file changed, 40 insertions(+), 33 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 20a71ef87..4abe0ac02 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -17,6 +17,7 @@ expressive, which should behave better in corner cases, and be much easier to extend. ## Chalk Structure + Chalk has two main "products". The first of these is the [`chalk_engine`][doc-chalk-engine] crate, which defines the core [SLG solver][slg]. This is the part rustc uses. @@ -52,37 +53,9 @@ You can see more examples of programs and queries in the [unit tests][chalk-test Next we'll go through each stage required to produce the output above. -### Crates -- [**chalk_engine**][doc-chalk-engine]: Defines the core [SLG solver][slg]. -- [**chalk_ir**][doc-chalk-ir]: Defines chalk's internal representation of - types, lifetimes, and goals. -- [**chalk_solve**][doc-chalk-solve]: Combines `chalk_ir` and `chalk_engine`, - effectively. - - [`chalk_engine::context`][engine-context] provides the necessary hooks. -- [**chalk_parse**][doc-chalk-parse]: Defines the raw AST and a parser. -- [**chalk**][doc-chalk]: Brings everything together. Defines the following - modules: - - [`rust_ir`][doc-chalk-rust-ir], containing the "HIR-like" form of the AST - - `rust_ir::lowering`, which converts AST to `rust_ir` - - `rules`, which implements logic rules - converting `rust_ir` to `chalk_ir` - - `coherence`, which implements coherence rules - - Also includes [chalki][doc-chalki], chalk's REPL. - -[Browse source on GitHub](https://github.com/rust-lang-nursery/chalk) - -[engine-context]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/context/index.html - -[doc-chalk-engine]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/index.html -[doc-chalk-ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/index.html -[doc-chalk-solve]: https://rust-lang-nursery.github.io/chalk/doc/chalk_solve/index.html -[doc-chalk-parse]: https://rust-lang-nursery.github.io/chalk/doc/chalk_parse/index.html -[doc-chalk]: https://rust-lang-nursery.github.io/chalk/doc/chalk/index.html -[doc-chalk-rust-ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rules/index.html -[doc-chalki]: https://rust-lang-nursery.github.io/chalk/doc/chalki/index.html [chalk-tests]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 -## Parsing +### Parsing Chalk is designed to be incorporated with the Rust compiler, so the syntax and concepts it deals with heavily borrow from Rust. It is convenient for the sake @@ -98,7 +71,7 @@ impls, and struct definitions. Parsing is often the first "phase" of transformation that a program goes through in order to become a format that chalk can understand. -## Lowering +### Lowering After parsing, there is a "lowering" phase. This aims to convert traits/impls into "program clauses". A [`ProgramClause` (source code)][programclause] is @@ -136,7 +109,7 @@ forall { (Vec: Clone) :- (T: Clone) } This rule dictates that `Vec: Clone` is only satisfied if `T: Clone` is also satisfied (i.e. "provable"). -### Well-formedness checks +#### Well-formedness checks As part of lowering from the AST to the internal IR, we also do some "well formedness" checks. See the [source code][well-formedness-checks] for where @@ -144,7 +117,7 @@ those are done. The call to `record_specialization_priorities` checks "coherence" which means that it ensures that two impls of the same trait for the same type cannot exist. -## Intermediate Representation (IR) +### Intermediate Representation (IR) The second intermediate representation in chalk is called, well, the "ir". :) The [IR source code][ir-code] contains the complete definition. The @@ -159,7 +132,7 @@ In addition to `ir::Program` which has "rust-like things", there is also `program_clauses` which contains the `ProgramClause`s that we generated previously. -## Rules +### Rules The `rules` module works by iterating over every trait, impl, etc. and emitting the rules that come from each one. See [Lowering Rules][lowering-rules] for the @@ -167,6 +140,40 @@ most up-to-date reference on that. The `ir::ProgramEnvironment` is created [in this module][rules-environment]. +### Solver + +See [The SLG Solver][slg]. + +## Crates + +Chalk's functionality is broken up into the following crates: +- [**chalk_engine**][doc-chalk-engine]: Defines the core [SLG solver][slg]. +- [**chalk_ir**][doc-chalk-ir]: Defines chalk's internal representation of + types, lifetimes, and goals. +- [**chalk_solve**][doc-chalk-solve]: Combines `chalk_ir` and `chalk_engine`, + effectively. + - [`chalk_engine::context`][engine-context] provides the necessary hooks. +- [**chalk_parse**][doc-chalk-parse]: Defines the raw AST and a parser. +- [**chalk**][doc-chalk]: Brings everything together. Defines the following + modules: + - [`rust_ir`][doc-chalk-rust-ir], containing the "HIR-like" form of the AST + - `rust_ir::lowering`, which converts AST to `rust_ir` + - `rules`, which implements logic rules converting `rust_ir` to `chalk_ir` + - `coherence`, which implements coherence rules + - Also includes [chalki][doc-chalki], chalk's REPL. + +[Browse source on GitHub](https://github.com/rust-lang-nursery/chalk) + +[engine-context]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/context/index.html + +[doc-chalk-engine]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/index.html +[doc-chalk-ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/index.html +[doc-chalk-solve]: https://rust-lang-nursery.github.io/chalk/doc/chalk_solve/index.html +[doc-chalk-parse]: https://rust-lang-nursery.github.io/chalk/doc/chalk_parse/index.html +[doc-chalk]: https://rust-lang-nursery.github.io/chalk/doc/chalk/index.html +[doc-chalk-rust-ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rules/index.html +[doc-chalki]: https://rust-lang-nursery.github.io/chalk/doc/chalki/index.html + ## Testing TODO: Basically, [there is a macro](https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/solve/test.rs#L112-L148) From fe9dc61b8935742d40727af66e2ae110701f84fd Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Tue, 30 Oct 2018 21:06:07 +0100 Subject: [PATCH 0399/1812] Fix a few more things Co-Authored-By: scalexm --- src/traits/wf.md | 59 ++++++++++++++++++++++++++++++++++-------------- 1 file changed, 42 insertions(+), 17 deletions(-) diff --git a/src/traits/wf.md b/src/traits/wf.md index ec391924a..8c4938d33 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -233,49 +233,66 @@ impl Foo for f32 { } ``` -So where clauses on associated types work *exactly* like where clauses on -trait methods: in an impl, we must substitute the parameters from the traits -with values provided by the impl, we may omit them if we don't need them, but -we cannot add new where clauses. +> So in Rust, where clauses on associated types work *exactly* like where +> clauses on trait methods: in an impl, we must substitute the parameters from +> the traits with values provided by the impl, we may omit them if we don't +> need them, but we cannot add new where clauses. Now let's see the generated goal for this general impl: ```text forall { - if (FromEnv(WC_impl), FromEnv(InputTypes(SomeType))) { - WellFormed(SomeType: Trait) && - WellFormed(InputTypes(WC_impl)) && + // Well-formedness of types appearing in the impl + if (FromEnv(WC_impl), FromEnv(InputTypes(SomeType: Trait))) { + WellFormed(InputTypes(WC_impl)) && forall { if (FromEnv(WC_assoc)) { - WellFormed(SomeValue: Bounds_assoc) && WellFormed(InputTypes(SomeValue)) } } } + + // Implied bounds checking + if (FromEnv(WC_impl), FromEnv(InputTypes(SomeType: Trait))) { + WellFormed(SomeType: Trait) && + + forall { + if (FromEnv(WC_assoc)) { + WellFormed(SomeValue: Bounds_assoc) + } + } + } } ``` Here is the most complex goal. As always, first, assuming that the various where clauses hold, we prove that every type appearing in the impl -is well-formed, ***except*** types appearing in the receiver type -`SomeType`. Instead, we *assume* that those types are well-formed -(hence the `if (FromEnv(InputTypes(SomeType)))` condition). This is +is well-formed, ***except*** types appearing in the impl header +`SomeType: Trait`. Instead, we *assume* that those types are +well-formed +(hence the `if (FromEnv(InputTypes(SomeType: Trait)))` +conditions). This is part of the implied bounds proposal, so that we can rely on the bounds -written on the definition of the `SomeType` type (and that we don't +written on the definition of e.g. the `SomeType` type (and that we don't need to repeat those bounds). +> Note that we don't need to check well-formedness of types appearing in +> `WC_assoc` because we already did that in the trait decl (they are just +> repeated with some substitutions of values which we already assume to be +> well-formed) -Next, assuming that the where clauses on the impl `WC_impl` hold and that the -input types of `SomeType` are well-formed, we prove that +Next, still assuming that the where clauses on the impl `WC_impl` hold and that +the input types of `SomeType` are well-formed, we prove that `WellFormed(SomeType: Trait)` hold. That is, we want to prove that `SomeType` verify all the where clauses that might transitively come from the `Trait` definition (see [this subsection](./implied-bounds.md#co-inductiveness-of-wellformed)). -Lastly, assuming that the where clauses on the associated type `WC_assoc` hold, +Lastly, assuming in addition that the where clauses on the associated type +`WC_assoc` hold, we prove that `WellFormed(SomeValue: Bounds_assoc)` hold. Again, we are not only proving `Implemented(SomeValue: Bounds_assoc)`, but also -all the facts that might transitively come from `Bounds_assoc`. This is because -we allow the use of implied bounds on associated types: if we have +all the facts that might transitively come from `Bounds_assoc`. We must do this +because we allow the use of implied bounds on associated types: if we have `FromEnv(SomeType: Trait)` in our environment, the lowering rules chapter indicates that we are able to deduce `FromEnv(::Assoc: Bounds_assoc)` without knowing what the @@ -283,6 +300,12 @@ precise value of `::Assoc` is. Some examples for the generated goal: ```rust,ignore +// Trait Program Clauses + +// These are program clauses that come from the trait definitions below +// and that the trait solver can use for its reasonings. I'm just restating +// them here so that we have them in mind. + trait Copy { } // This is a program clause that comes from the trait definition above // and that the trait solver can use for its reasonings. I'm just restating @@ -304,6 +327,8 @@ trait Complete where Self: Partial { } // WellFormed(Self: Partial). // ``` +// Impl WF Goals + impl Partial for T where T: Complete { } // The generated goal is: // ``` From b5024c3a7328eecdccb37edbfe376c6ac99f2004 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 29 Oct 2018 22:31:59 -0500 Subject: [PATCH 0400/1812] Chalk Overview: Update old content --- src/traits/chalk-overview.md | 99 +++++++++++++++++++++--------------- 1 file changed, 59 insertions(+), 40 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 4abe0ac02..5e0f147ca 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -55,7 +55,7 @@ Next we'll go through each stage required to produce the output above. [chalk-tests]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 -### Parsing +### Parsing ([chalk_parse]) Chalk is designed to be incorporated with the Rust compiler, so the syntax and concepts it deals with heavily borrow from Rust. It is convenient for the sake @@ -71,11 +71,23 @@ impls, and struct definitions. Parsing is often the first "phase" of transformation that a program goes through in order to become a format that chalk can understand. -### Lowering +### Rust Intermediate Representation ([rust_ir]) -After parsing, there is a "lowering" phase. This aims to convert traits/impls -into "program clauses". A [`ProgramClause` (source code)][programclause] is -essentially one of the following: +After getting the AST we convert it to a more convenient intermediate +representation called [`rust_ir`][rust_ir]. This is sort of analogous to the +[HIR] in Rust. The process of converting to IR is called *lowering*. + +The [`rust_ir::Program`][rust_ir-program] struct contains some "rust things" +but indexed and accessible in a different way. For example, if you have a +type like `Foo`, we would represent `Foo` as a string in the AST but in +`rust_ir::Program`, we use numeric indices (`ItemId`). + +The [IR source code][ir-code] contains the complete definition. + +### Chalk Intermediate Representation ([chalk_ir]) + +Once we have Rust IR it is time to convert it to "program clauses". A +[`ProgramClause`] is essentially one of the following: * A [clause] of the form `consequence :- conditions` where `:-` is read as "if" and `conditions = cond1 && cond2 && ...` @@ -93,8 +105,8 @@ essentially one of the following: *See also: [Goals and Clauses][goals-and-clauses]* -Lowering is the phase where we encode the rules of the trait system into logic. -For example, if we have the following Rust: +This is where we encode the rules of the trait system into logic. For +example, if we have the following Rust: ```rust,ignore impl Clone for Vec {} @@ -109,54 +121,61 @@ forall { (Vec: Clone) :- (T: Clone) } This rule dictates that `Vec: Clone` is only satisfied if `T: Clone` is also satisfied (i.e. "provable"). -#### Well-formedness checks +Similar to [`rust_ir::Program`][rust_ir-program] which has "rust-like +things", chalk_ir defines [`ProgramEnvironment`] which which is "pure logic". +The main field in that struct is `program_clauses`, which contains the +[`ProgramClause`]s generated by the rules module. -As part of lowering from the AST to the internal IR, we also do some "well -formedness" checks. See the [source code][well-formedness-checks] for where -those are done. The call to `record_specialization_priorities` checks -"coherence" which means that it ensures that two impls of the same trait for the -same type cannot exist. +#### Rules + +The `rules` module ([source code][rules-src]) defines the logic rules we use +for each item in the Rust IR. It works by iterating over every trait, impl, +etc. and emitting the rules that come from each one. + +*See also: [Lowering Rules][lowering-rules]* + +[`ProgramEnvironment`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/struct.ProgramEnvironment.html +[`ProgramClause`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/enum.ProgramClause.html +[rules-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules.rs + +#### Well-formedness checks -### Intermediate Representation (IR) +As part of lowering to logic, we also do some "well formedness" checks. See +the [`rules::wf` source code][rules-wf-src] for where those are done. -The second intermediate representation in chalk is called, well, the "ir". :) -The [IR source code][ir-code] contains the complete definition. The -`ir::Program` struct contains some "rust things" but indexed and accessible in -a different way. This is sort of analogous to the [HIR] in Rust. +*See also: [Well-formedness checking][wf-checking]* -For example, if you have a type like `Foo`, we would represent `Foo` as a -string in the AST but in `ir::Program`, we use numeric indices (`ItemId`). +[rules-wf-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf.rs -In addition to `ir::Program` which has "rust-like things", there is also -`ir::ProgramEnvironment` which is "pure logic". The main field in that struct is -`program_clauses` which contains the `ProgramClause`s that we generated -previously. +#### Coherence -### Rules +The function `record_specialization_priorities` in the `coherence` module +([source code][coherence-src]) checks "coherence", which means that it +ensures that two impls of the same trait for the same type cannot exist. -The `rules` module works by iterating over every trait, impl, etc. and emitting -the rules that come from each one. See [Lowering Rules][lowering-rules] for the -most up-to-date reference on that. +[coherence-src]: https://github.com/rust-lang-nursery/chalk/blob/master/src/coherence.rs -The `ir::ProgramEnvironment` is created [in this module][rules-environment]. +### Solver ([chalk_solve]) -### Solver +Finally, when we've collected all the program clauses we care about, we want +to perform queries on it. The component that finds the answer to these +queries is called the *solver*. -See [The SLG Solver][slg]. +*See also: [The SLG Solver][slg]* ## Crates Chalk's functionality is broken up into the following crates: - [**chalk_engine**][doc-chalk-engine]: Defines the core [SLG solver][slg]. -- [**chalk_ir**][doc-chalk-ir]: Defines chalk's internal representation of +- [**chalk_ir**][chalk_ir]: Defines chalk's internal representation of types, lifetimes, and goals. - [**chalk_solve**][doc-chalk-solve]: Combines `chalk_ir` and `chalk_engine`, effectively. - [`chalk_engine::context`][engine-context] provides the necessary hooks. -- [**chalk_parse**][doc-chalk-parse]: Defines the raw AST and a parser. +- [**chalk_parse**][chalk_parse]: Defines the raw AST and a parser. - [**chalk**][doc-chalk]: Brings everything together. Defines the following modules: - - [`rust_ir`][doc-chalk-rust-ir], containing the "HIR-like" form of the AST + - [`rust_ir`][rust_ir], containing the "HIR-like" form of the AST - `rust_ir::lowering`, which converts AST to `rust_ir` - `rules`, which implements logic rules converting `rust_ir` to `chalk_ir` - `coherence`, which implements coherence rules @@ -167,11 +186,12 @@ Chalk's functionality is broken up into the following crates: [engine-context]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/context/index.html [doc-chalk-engine]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/index.html -[doc-chalk-ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/index.html +[chalk_ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/index.html [doc-chalk-solve]: https://rust-lang-nursery.github.io/chalk/doc/chalk_solve/index.html -[doc-chalk-parse]: https://rust-lang-nursery.github.io/chalk/doc/chalk_parse/index.html +[chalk_parse]: https://rust-lang-nursery.github.io/chalk/doc/chalk_parse/index.html [doc-chalk]: https://rust-lang-nursery.github.io/chalk/doc/chalk/index.html -[doc-chalk-rust-ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rules/index.html +[rust_ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rust_ir/index.html +[rust_ir-program]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rust_ir/struct.Program.html [doc-chalki]: https://rust-lang-nursery.github.io/chalk/doc/chalki/index.html ## Testing @@ -201,15 +221,14 @@ is the function that is ultimately called. [chalk]: https://github.com/rust-lang-nursery/chalk [lowering-to-logic]: ./lowering-to-logic.html [lowering-rules]: ./lowering-rules.html +[wf-checking]: ./wf.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification [lowering-forall]: ./lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses -[programclause]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L721 [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause [goals-and-clauses]: ./goals-and-clauses.html -[well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir/lowering.rs#L230-L232 -[ir-code]: https://github.com/rust-lang-nursery/chalk/tree/master/chalk-ir +[ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/rust_ir.rs [HIR]: ../hir.html [binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 [rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 From 7f14c8254e501a418836f8c1fe979d746e847df2 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Tue, 30 Oct 2018 17:20:29 -0500 Subject: [PATCH 0401/1812] Chalk Overview: Organize and sort links --- src/traits/chalk-overview.md | 67 +++++++++++++++++------------------- 1 file changed, 32 insertions(+), 35 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 5e0f147ca..1a6e72bec 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -19,7 +19,7 @@ extend. ## Chalk Structure Chalk has two main "products". The first of these is the -[`chalk_engine`][doc-chalk-engine] crate, which defines the core [SLG +[`chalk_engine`][chalk_engine] crate, which defines the core [SLG solver][slg]. This is the part rustc uses. The rest of chalk can be considered an elaborate testing harness. Chalk is @@ -53,8 +53,6 @@ You can see more examples of programs and queries in the [unit tests][chalk-test Next we'll go through each stage required to produce the output above. -[chalk-tests]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 - ### Parsing ([chalk_parse]) Chalk is designed to be incorporated with the Rust compiler, so the syntax and @@ -134,10 +132,6 @@ etc. and emitting the rules that come from each one. *See also: [Lowering Rules][lowering-rules]* -[`ProgramEnvironment`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/struct.ProgramEnvironment.html -[`ProgramClause`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/enum.ProgramClause.html -[rules-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules.rs - #### Well-formedness checks As part of lowering to logic, we also do some "well formedness" checks. See @@ -145,16 +139,12 @@ the [`rules::wf` source code][rules-wf-src] for where those are done. *See also: [Well-formedness checking][wf-checking]* -[rules-wf-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf.rs - #### Coherence The function `record_specialization_priorities` in the `coherence` module ([source code][coherence-src]) checks "coherence", which means that it ensures that two impls of the same trait for the same type cannot exist. -[coherence-src]: https://github.com/rust-lang-nursery/chalk/blob/master/src/coherence.rs - ### Solver ([chalk_solve]) Finally, when we've collected all the program clauses we care about, we want @@ -166,10 +156,10 @@ queries is called the *solver*. ## Crates Chalk's functionality is broken up into the following crates: -- [**chalk_engine**][doc-chalk-engine]: Defines the core [SLG solver][slg]. +- [**chalk_engine**][chalk_engine]: Defines the core [SLG solver][slg]. - [**chalk_ir**][chalk_ir]: Defines chalk's internal representation of types, lifetimes, and goals. -- [**chalk_solve**][doc-chalk-solve]: Combines `chalk_ir` and `chalk_engine`, +- [**chalk_solve**][chalk_solve]: Combines `chalk_ir` and `chalk_engine`, effectively. - [`chalk_engine::context`][engine-context] provides the necessary hooks. - [**chalk_parse**][chalk_parse]: Defines the raw AST and a parser. @@ -179,20 +169,9 @@ Chalk's functionality is broken up into the following crates: - `rust_ir::lowering`, which converts AST to `rust_ir` - `rules`, which implements logic rules converting `rust_ir` to `chalk_ir` - `coherence`, which implements coherence rules - - Also includes [chalki][doc-chalki], chalk's REPL. - -[Browse source on GitHub](https://github.com/rust-lang-nursery/chalk) - -[engine-context]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/context/index.html + - Also includes [chalki][chalki], chalk's REPL. -[doc-chalk-engine]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/index.html -[chalk_ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/index.html -[doc-chalk-solve]: https://rust-lang-nursery.github.io/chalk/doc/chalk_solve/index.html -[chalk_parse]: https://rust-lang-nursery.github.io/chalk/doc/chalk_parse/index.html -[doc-chalk]: https://rust-lang-nursery.github.io/chalk/doc/chalk/index.html -[rust_ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rust_ir/index.html -[rust_ir-program]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rust_ir/struct.Program.html -[doc-chalki]: https://rust-lang-nursery.github.io/chalk/doc/chalki/index.html +[Browse source code on GitHub](https://github.com/rust-lang-nursery/chalk) ## Testing @@ -217,19 +196,37 @@ is the function that is ultimately called. * [Cyclic queries in chalk](http://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/) * [An on-demand SLG solver for chalk](http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/) -[rustc-issues]: https://github.com/rust-lang-nursery/rustc-guide/issues -[chalk]: https://github.com/rust-lang-nursery/chalk -[lowering-to-logic]: ./lowering-to-logic.html +[goals-and-clauses]: ./goals-and-clauses.html +[HIR]: ../hir.html +[lowering-forall]: ./lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses [lowering-rules]: ./lowering-rules.html +[lowering-to-logic]: ./lowering-to-logic.html +[slg]: ./slg.html [wf-checking]: ./wf.html + [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree -[chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs +[chalk]: https://github.com/rust-lang-nursery/chalk +[rustc-issues]: https://github.com/rust-lang-nursery/rustc-guide/issues [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification -[lowering-forall]: ./lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses + +[`ProgramClause`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/enum.ProgramClause.html +[`ProgramEnvironment`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/struct.ProgramEnvironment.html +[chalk_engine]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/index.html +[chalk_ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/index.html +[chalk_parse]: https://rust-lang-nursery.github.io/chalk/doc/chalk_parse/index.html +[chalk_solve]: https://rust-lang-nursery.github.io/chalk/doc/chalk_solve/index.html +[doc-chalk]: https://rust-lang-nursery.github.io/chalk/doc/chalk/index.html +[engine-context]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/context/index.html +[rust_ir-program]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rust_ir/struct.Program.html +[rust_ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rust_ir/index.html + +[binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 +[chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs +[chalk-tests]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 +[chalki]: https://rust-lang-nursery.github.io/chalk/doc/chalki/index.html [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause -[goals-and-clauses]: ./goals-and-clauses.html +[coherence-src]: https://github.com/rust-lang-nursery/chalk/blob/master/src/coherence.rs [ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/rust_ir.rs -[HIR]: ../hir.html -[binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 [rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 -[slg]: ./slg.html +[rules-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules.rs +[rules-wf-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf.rs From cf2682ae86e6f026395e7bdfc3ed1bf3a34e6d5b Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Tue, 30 Oct 2018 18:03:42 -0500 Subject: [PATCH 0402/1812] Chalk Overview: Fill in testing section --- src/traits/chalk-overview.md | 39 +++++++++++++++++++++++++++++------- 1 file changed, 32 insertions(+), 7 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 1a6e72bec..59572479d 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -49,7 +49,8 @@ No possible solution. Ambiguous; no inference guidance ``` -You can see more examples of programs and queries in the [unit tests][chalk-tests]. +You can see more examples of programs and queries in the [unit +tests][chalk-test-example]. Next we'll go through each stage required to produce the output above. @@ -175,11 +176,29 @@ Chalk's functionality is broken up into the following crates: ## Testing -TODO: Basically, [there is a macro](https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/solve/test.rs#L112-L148) -that will take chalk's Rust-like syntax and run it through the full pipeline -described above. -[This](https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/solve/test.rs#L83-L110) -is the function that is ultimately called. +chalk has a test framework for lowering programs to logic, checking the +lowered logic, and performing queries on it. This is how we test the +implementation of chalk itself, and the viability of the [lowering +rules][lowering-rules]. + +The main kind of tests in chalk are **goal tests**. They contain a program, +which is expected to lower to logic successfully, and a set of queries +(goals) along with the expected output. Here's an +[example][chalk-test-example]. Since chalk's output can be quite long, goal +tests support specifying only a prefix of the output. + +**Lowering tests** check the stages that occur before we can issue queries +to the solver: the [lowering to rust_ir][chalk-test-lowering], and the +[well-formedness checks][chalk-test-wf] that occur after that. + +### Testing internals + +Goal tests use a [`test!` macro][test-macro] that takes chalk's Rust-like +syntax and runs it through the full pipeline described above. The macro +ultimately calls the [`solve_goal` function][solve_goal]. + +Likewise, lowering tests use the [`lowering_success!` and +`lowering_error!` macros][test-lowering-macros]. ## More Resources @@ -222,7 +241,10 @@ is the function that is ultimately called. [binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 [chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs -[chalk-tests]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 +[chalk-test-example]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 +[chalk-test-lowering-example]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs#L8-L31 +[chalk-test-lowering]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs +[chalk-test-wf]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf/test.rs#L1 [chalki]: https://rust-lang-nursery.github.io/chalk/doc/chalki/index.html [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause [coherence-src]: https://github.com/rust-lang-nursery/chalk/blob/master/src/coherence.rs @@ -230,3 +252,6 @@ is the function that is ultimately called. [rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 [rules-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules.rs [rules-wf-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf.rs +[solve_goal]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L85 +[test-lowering-macros]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test_util.rs#L21-L54 +[test-macro]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L33 From 66e831eeb0de5ca3cea50c12255a09278e7920c8 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 31 Oct 2018 15:33:20 -0500 Subject: [PATCH 0403/1812] Missing link --- src/borrow_check/moves_and_initialization/move_paths.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index c9e22a81c..8fd7b3f19 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -47,6 +47,7 @@ move_data.move_paths[mpi].place [move_paths]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#structfield.move_paths [`MovePath::place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePath.html#structfield.place +[`MovePathIndex`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/indexes/struct.MovePathIndex.html ## Building move paths From 9805434b94e175beca3d384540714469d3431127 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 22 Oct 2018 12:37:13 -0500 Subject: [PATCH 0404/1812] Clarify why 'static is free --- src/traits/canonicalization.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md index 62c4d9f74..ca81d6fd1 100644 --- a/src/traits/canonicalization.md +++ b/src/traits/canonicalization.md @@ -42,7 +42,11 @@ This query contains two unbound variables, but it also contains the lifetime `'static`. The trait system generally ignores all lifetimes and treats them equally, so when canonicalizing, we will *also* replace any [free lifetime](../appendix/background.html#free-vs-bound) with a -canonical variable. Therefore, we get the following result: +canonical variable (Note that `'static` is actually a _free_ lifetime +variable here. We are not considering it in the typing context of the whole +program but only in the context of this trait reference. Mathematically, we +are not quantifying over the whole program, but only this obligation). +Therefore, we get the following result: ```text ?0: Foo<'?1, ?2> From cbb021e93f31d2b4c7f153232df03a7dd2859c14 Mon Sep 17 00:00:00 2001 From: scalexm Date: Fri, 2 Nov 2018 21:50:36 +0100 Subject: [PATCH 0405/1812] Fix nits --- src/traits/wf.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/traits/wf.md b/src/traits/wf.md index 8c4938d33..f0cb03caa 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -27,18 +27,18 @@ In addition to the notations introduced in the chapter about lowering rules, we'll introduce another notation: when checking WF of a declaration, we'll often have to prove that all types that appear are well-formed, except type parameters that we always assume to be WF. Hence, -we'll use the following notation: for a type `SomeType<...>`, we denote -`InputTypes(SomeType<...>)` the set of all non-parameter types appearing in -`SomeType<...>`, including `SomeType<...>` itself. +we'll use the following notation: for a type `SomeType<...>`, we define +`InputTypes(SomeType<...>)` to be the set of all non-parameter types appearing +in `SomeType<...>`, including `SomeType<...>` itself. Examples: * `InputTypes((u32, f32)) = [u32, f32, (u32, f32)]` -* `InputTypes(Box) = [Box]` +* `InputTypes(Box) = [Box]` (assuming that `T` is a type parameter) * `InputTypes(Box>) = [Box, Box>]` -We may naturally extend the `InputTypes` notation to where clauses, for example -`InputTypes(A0: Trait)` is the union of `InputTypes(A0)`, -`InputTypes(A1)`, ..., `InputTypes(An)`. +We also extend the `InputTypes` notation to where clauses in the natural way. +So, for example `InputTypes(A0: Trait)` is the union of +`InputTypes(A0)`, `InputTypes(A1)`, ..., `InputTypes(An)`. # Type definitions @@ -51,7 +51,7 @@ struct Type where WC_type { } ``` -we generate the following goal: +we generate the following goal, which represents its well-formedness condition: ```text forall { if (FromEnv(WC_type)) { @@ -63,7 +63,7 @@ forall { } ``` -which in English gives: assuming that the where clauses defined on the type +which in English states: assuming that the where clauses defined on the type hold, prove that every type appearing in the type definition is well-formed. Some examples: @@ -284,7 +284,7 @@ Next, still assuming that the where clauses on the impl `WC_impl` hold and that the input types of `SomeType` are well-formed, we prove that `WellFormed(SomeType: Trait)` hold. That is, we want to prove that `SomeType` verify all the where clauses that might transitively -come from the `Trait` definition (see +be required by the `Trait` definition (see [this subsection](./implied-bounds.md#co-inductiveness-of-wellformed)). Lastly, assuming in addition that the where clauses on the associated type From 76a2c5eb86f0db7217a6b94d04ac3f082c8ebd4e Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Fri, 2 Nov 2018 15:42:21 -0500 Subject: [PATCH 0406/1812] Copy chalk_engine README --- src/traits/slg.md | 279 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 277 insertions(+), 2 deletions(-) diff --git a/src/traits/slg.md b/src/traits/slg.md index 1dc56e14c..8e4e451c4 100644 --- a/src/traits/slg.md +++ b/src/traits/slg.md @@ -1,3 +1,278 @@ -# The SLG solver +# The On-Demand SLG solver -TODO: +## Description of how it works + +The basis of the solver is the `Forest` type. A *forest* stores a +collection of *tables* as well as a *stack*. Each *table* represents +the stored results of a particular query that is being performed, as +well as the various *strands*, which are basically suspended +computations that may be used to find more answers. Tables are +interdependent: solving one query may require solving others. + +### Walkthrough + +Perhaps the easiest way to explain how the solver works is to walk +through an example. Let's imagine that we have the following program: + +```rust +trait Debug { } + +struct u32 { } +impl Debug for u32 { } + +struct Rc { } +impl Debug for Rc { } + +struct Vec { } +impl Debug for Vec { } +``` + +Now imagine that we want to find answers for the query `exists { +Rc: Debug }`. The first step would be to u-canonicalize this query; this +is the act of giving canonical names to all the unbound inference variables based on the +order of their left-most appearance, as well as canonicalizing the universes of any +universally bound names (e.g., the `T` in `forall { ... }`). In this case, there are no +universally bound names, but the canonical form Q of the query might look something like: + + Rc: Debug + +where `?0` is a variable in the root universe U0. We would then go and +look for a table with this as the key: since the forest is empty, this +lookup will fail, and we will create a new table T0, corresponding to +the u-canonical goal Q. + +**Ignoring negative reasoning and regions.** To start, we'll ignore +the possibility of negative goals like `not { Foo }`. We'll phase them +in later, as they bring several complications. + +**Creating a table.** When we first create a table, we also initialize +it with a set of *initial strands*. A "strand" is kind of like a +"thread" for the solver: it contains a particular way to produce an +answer. The initial set of strands for a goal like `Rc: Debug` +(i.e., a "domain goal") is determined by looking for *clauses* in the +environment. In Rust, these clauses derive from impls, but also from +where-clauses that are in scope. In the case of our example, there +would be three clauses, each coming from the program. Using a +Prolog-like notation, these look like: + +``` +(u32: Debug). +(Rc: Debug) :- (T: Debug). +(Vec: Debug) :- (T: Debug). +``` + +To create our initial strands, then, we will try to apply each of +these clauses to our goal of `Rc: Debug`. The first and third +clauses are inapplicable because `u32` and `Vec` cannot be unified +with `Rc`. The second clause, however, will work. + +**What is a strand?** Let's talk a bit more about what a strand *is*. In the code, a strand +is the combination of an inference table, an X-clause, and (possibly) +a selected subgoal from that X-clause. But what is an X-clause +(`ExClause`, in the code)? An X-clause pulls together a few things: + +- The current state of the goal we are trying to prove; +- A set of subgoals that have yet to be proven; +- There are also a few things we're ignoring for now: + - delayed literals, region constraints + +The general form of an X-clause is written much like a Prolog clause, +but with somewhat different semantics. Since we're ignoring delayed +literals and region constraints, an X-clause just looks like this: + + G :- L + +where G is a goal and L is a set of subgoals that must be proven. +(The L stands for *literal* -- when we address negative reasoning, a +literal will be either a positive or negative subgoal.) The idea is +that if we are able to prove L then the goal G can be considered true. + +In the case of our example, we would wind up creating one strand, with +an X-clause like so: + + (Rc: Debug) :- (?T: Debug) + +Here, the `?T` refers to one of the inference variables created in the +inference table that accompanies the strand. (I'll use named variables +to refer to inference variables, and numbered variables like `?0` to +refer to variables in a canonicalized goal; in the code, however, they +are both represented with an index.) + +For each strand, we also optionally store a *selected subgoal*. This +is the subgoal after the turnstile (`:-`) that we are currently trying +to prove in this strand. Initally, when a strand is first created, +there is no selected subgoal. + +**Activating a strand.** Now that we have created the table T0 and +initialized it with strands, we have to actually try and produce an +answer. We do this by invoking the `ensure_answer` operation on the +table: specifically, we say `ensure_answer(T0, A0)`, meaning "ensure +that there is a 0th answer". + +Remember that tables store not only strands, but also a vector of +cached answers. The first thing that `ensure_answer` does is to check +whether answer 0 is in this vector. If so, we can just return +immediately. In this case, the vector will be empty, and hence that +does not apply (this becomes important for cyclic checks later on). + +When there is no cached answer, `ensure_answer` will try to produce +one. It does this by selecting a strand from the set of active +strands -- the strands are stored in a `VecDeque` and hence processed +in a round-robin fashion. Right now, we have only one strand, storing +the following X-clause with no selected subgoal: + + (Rc: Debug) :- (?T: Debug) + +When we activate the strand, we see that we have no selected subgoal, +and so we first pick one of the subgoals to process. Here, there is only +one (`?T: Debug`), so that becomes the selected subgoal, changing +the state of the strand to: + + (Rc: Debug) :- selected(?T: Debug, A0) + +Here, we write `selected(L, An)` to indicate that (a) the literal `L` +is the selected subgoal and (b) which answer `An` we are looking for. We +start out looking for `A0`. + +**Processing the selected subgoal.** Next, we have to try and find an +answer to this selected goal. To do that, we will u-canonicalize it +and try to find an associated table. In this case, the u-canonical +form of the subgoal is `?0: Debug`: we don't have a table yet for +that, so we can create a new one, T1. As before, we'll initialize T1 +with strands. In this case, there will be three strands, because all +the program clauses are potentially applicable. Those three strands +will be: + +- `(u32: Debug) :-`, derived from the program clause `(u32: Debug).`. + - Note: This strand has no subgoals. +- `(Vec: Debug) :- (?U: Debug)`, derived from the `Vec` impl. +- `(Rc: Debug) :- (?U: Debug)`, derived from the `Rc` impl. + +We can thus summarize the state of the whole forest at this point as +follows: + +``` +Table T0 [Rc: Debug] + Strands: + (Rc: Debug) :- selected(?T: Debug, A0) + +Table T1 [?0: Debug] + Strands: + (u32: Debug) :- + (Vec: Debug) :- (?U: Debug) + (Rc: Debug) :- (?V: Debug) +``` + +**Delegation between tables.** Now that the active strand from T0 has +created the table T1, it can try to extract an answer. It does this +via that same `ensure_answer` operation we saw before. In this case, +the strand would invoke `ensure_answer(T1, A0)`, since we will start +with the first answer. This will cause T1 to activate its first +strand, `u32: Debug :-`. + +This strand is somewhat special: it has no subgoals at all. This means +that the goal is proven. We can therefore add `u32: Debug` to the set +of *answers* for our table, calling it answer A0 (it is the first +answer). The strand is then removed from the list of strands. + +The state of table T1 is therefore: + +``` +Table T1 [?0: Debug] + Answers: + A0 = [?0 = u32] + Strand: + (Vec: Debug) :- (?U: Debug) + (Rc: Debug) :- (?V: Debug) +``` + +Note that I am writing out the answer A0 as a substitution that can be +applied to the table goal; actually, in the code, the goals for each +X-clause are also represented as substitutions, but in this exposition +I've chosen to write them as full goals, following NFTD. + +Since we now have an answer, `ensure_answer(T1, A0)` will return `Ok` +to the table T0, indicating that answer A0 is available. T0 now has +the job of incorporating that result into its active strand. It does +this in two ways. First, it creates a new strand that is looking for +the next possible answer of T1. Next, it incorpoates the answer from +A0 and removes the subgoal. The resulting state of table T0 is: + +``` +Table T0 [Rc: Debug] + Strands: + (Rc: Debug) :- selected(?T: Debug, A1) + (Rc: Debug) :- +``` + +We then immediately activate the strand that incorporated the answer +(the `Rc: Debug` one). In this case, that strand has no further +subgoals, so it becomes an answer to the table T0. This answer can +then be returned up to our caller, and the whole forest goes quiescent +at this point (remember, we only do enough work to generate *one* +answer). The ending state of the forest at this point will be: + +``` +Table T0 [Rc: Debug] + Answer: + A0 = [?0 = u32] + Strands: + (Rc: Debug) :- selected(?T: Debug, A1) + +Table T1 [?0: Debug] + Answers: + A0 = [?0 = u32] + Strand: + (Vec: Debug) :- (?U: Debug) + (Rc: Debug) :- (?V: Debug) +``` + +Here you can see how the forest captures both the answers we have +created thus far *and* the strands that will let us try to produce +more answers later on. + +## Heritage and acroynms + +This solver implements the SLG solving technique, though extended to +accommodate hereditary harrop (HH) predicates, as well as the needs of +lazy normalization. + +Its design is kind of a fusion of [MiniKanren] and the following +papers, which I will refer to as EWFS and NTFD respectively: + +> Efficient Top-Down Computation of Queries Under the Well-formed Semantics +> (Chen, Swift, and Warren; Journal of Logic Programming '95) + +> A New Formulation of Tabled resolution With Delay +> (Swift; EPIA '99) + +[MiniKanren]: http://minikanren.org/ + +In addition, I incorporated extensions from the following papers, +which I will refer to as SA and RR respectively, that describes how to +do introduce approximation when processing subgoals and so forth: + +> Terminating Evaluation of Logic Programs with Finite Three-Valued Models +> Riguzzi and Swift; ACM Transactions on Computational Logic 2013 +> (Introduces "subgoal abstraction", hence the name SA) +> +> Radial Restraint +> Grosof and Swift; 2013 + +Another useful paper that gives a kind of high-level overview of +concepts at play is the following: + +> XSB: Extending Prolog with Tabled Logic Programming +> (Swift and Warren; Theory and Practice of Logic Programming '10) + +There are a places where I intentionally diverged from the semantics +as described in the papers -- e.g. by more aggressively approximating +-- which I marked them with a comment DIVERGENCE. Those places may +want to be evaluated in the future. + +A few other acronyms that I use: + +- WAM: Warren abstract machine, an efficient way to evaluate Prolog programs. + See . +- HH: Hereditary harrop predicates. What Chalk deals in. + Popularized by Lambda Prolog. From 69d42aa4ce7ff9be6edb760dd436d06967fb6838 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Sun, 4 Nov 2018 09:38:56 -0600 Subject: [PATCH 0407/1812] SLG: Add intro --- src/traits/slg.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/src/traits/slg.md b/src/traits/slg.md index 8e4e451c4..d151377c5 100644 --- a/src/traits/slg.md +++ b/src/traits/slg.md @@ -1,5 +1,43 @@ # The On-Demand SLG solver +Given a set of program clauses (provided by our [lowering rules][lowering]) +and a query, we need to return the result of the query and the value of any +type variables we can determine. This is the job of the solver. + +For example, `exists { Vec: FromIterator }` has one solution, so +its result is `Unique; substitution [?T := u32]`. A solution also comes with +a set of region constraints, which we'll ignore in this introduction. + +[lowering]: ./lowering-rules.html + +## Goals of the Solver + +### On demand + +There are often many, or even infinitely many, solutions to a query. For +example, say we want to prove that `exists { Vec: Debug }` for _some_ +type `?T`. Our solver should be capable of iterating over each answer one at +a time, say `?T = u32`, then `?T = i32`, and so on, rather than iterating +over every type in the type system. If we need more answers, we can request +more until we are done. This is similar to how Prolog works. + +*See also: [The traditional, interactive Prolog query][pq]* + +[pq]: ./canonical-queries.html#the-traditional-interactive-prolog-query + +### Breadth-first + +`Vec: Debug` is true if `?T: Debug`. This leads to a cycle: `[Vec , +Vec>, Vec>>]`, and so on all implement `Debug`. Our +solver ought to be breadth first and consider answers like `[Vec: Debug, +Vec: Debug, ...]` before it recurses, or we may never find the answer +we're looking for. + +### Cache friendly + +To speed up compilation, we need to cache results, including partial results +left over from past solver queries. + ## Description of how it works The basis of the solver is the `Forest` type. A *forest* stores a From 62c8d0465b77b8580fe3cc048cac9a89268720ac Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Sun, 4 Nov 2018 09:39:31 -0600 Subject: [PATCH 0408/1812] SLG: Replace heritage section with links to it elsewhere Maybe we want to include this in the bibliography or something, though. --- src/traits/slg.md | 57 ++++++++++------------------------------------- 1 file changed, 12 insertions(+), 45 deletions(-) diff --git a/src/traits/slg.md b/src/traits/slg.md index d151377c5..812afd1ec 100644 --- a/src/traits/slg.md +++ b/src/traits/slg.md @@ -269,48 +269,15 @@ Here you can see how the forest captures both the answers we have created thus far *and* the strands that will let us try to produce more answers later on. -## Heritage and acroynms - -This solver implements the SLG solving technique, though extended to -accommodate hereditary harrop (HH) predicates, as well as the needs of -lazy normalization. - -Its design is kind of a fusion of [MiniKanren] and the following -papers, which I will refer to as EWFS and NTFD respectively: - -> Efficient Top-Down Computation of Queries Under the Well-formed Semantics -> (Chen, Swift, and Warren; Journal of Logic Programming '95) - -> A New Formulation of Tabled resolution With Delay -> (Swift; EPIA '99) - -[MiniKanren]: http://minikanren.org/ - -In addition, I incorporated extensions from the following papers, -which I will refer to as SA and RR respectively, that describes how to -do introduce approximation when processing subgoals and so forth: - -> Terminating Evaluation of Logic Programs with Finite Three-Valued Models -> Riguzzi and Swift; ACM Transactions on Computational Logic 2013 -> (Introduces "subgoal abstraction", hence the name SA) -> -> Radial Restraint -> Grosof and Swift; 2013 - -Another useful paper that gives a kind of high-level overview of -concepts at play is the following: - -> XSB: Extending Prolog with Tabled Logic Programming -> (Swift and Warren; Theory and Practice of Logic Programming '10) - -There are a places where I intentionally diverged from the semantics -as described in the papers -- e.g. by more aggressively approximating --- which I marked them with a comment DIVERGENCE. Those places may -want to be evaluated in the future. - -A few other acronyms that I use: - -- WAM: Warren abstract machine, an efficient way to evaluate Prolog programs. - See . -- HH: Hereditary harrop predicates. What Chalk deals in. - Popularized by Lambda Prolog. +## See also + +- [chalk_solve README][readme], which contains links to papers used and + acronyms referenced in the code +- This section is a lightly adapted version of the blog post [An on-demand + SLG solver for chalk][slg-blog] +- [Negative Reasoning in Chalk][negative-reasoning-blog] explains the need + for negative reasoning, but not how the SLG solver does it + +[readme]: https://github.com/rust-lang-nursery/chalk/blob/239e4ae4e69b2785b5f99e0f2b41fc16b0b4e65e/chalk-engine/src/README.md +[slg-blog]: http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/ +[negative-reasoning-blog]: http://aturon.github.io/blog/2017/04/24/negative-chalk/ From 351f75b4eb7eada41426dcc7a81cb73745154792 Mon Sep 17 00:00:00 2001 From: Tom Tromey Date: Tue, 6 Nov 2018 14:47:56 -0700 Subject: [PATCH 0409/1812] Document ignore-llvm-version This documents the ignore-llvm-version directive. --- src/tests/adding.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index 580741ccf..418287355 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -167,6 +167,11 @@ source. required for this test; the test is ignored if the system llvm is in use and it doesn't meet the minimum version. This is useful when an llvm feature has been backported to rust-llvm +* `ignore-llvm-version` can be used to skip the test when certain LLVM + versions are used. This takes one or two arguments; the first + argument is the first version to ignore. If no second argument is + given, all subsequent versions are ignored; otherwise, the second + argument is the last version to ignore. * `compile-pass` for UI tests, indicates that the test is supposed to compile, as opposed to the default where the test is supposed to error out. From 253affdfc5532258b2180d8f60b985ba08676093 Mon Sep 17 00:00:00 2001 From: kenta7777 Date: Tue, 6 Nov 2018 14:49:01 +0900 Subject: [PATCH 0410/1812] revised a jemalloc statement in how-to-build-and-run.md --- src/how-to-build-and-run.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 62461d3ef..863536a06 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -42,9 +42,9 @@ debuginfo = true # Gives you line numbers for backtraces. debuginfo-lines = true -# Using the system allocator (instead of jemalloc) means that tools -# like valgrind and memcache work better. -use-jemalloc = false +# Link the compiler against `jemalloc`, where on Linux and OSX it should +# override the default allocator for rustc and LLVM. +jemalloc = false ``` ### What is x.py? @@ -335,4 +335,4 @@ everything up then you only need to run one command! The documentation for the rust components are found at [rustc doc]. -[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ \ No newline at end of file +[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ From dc9ceca1036650e1f7518e87b1197287bcdb336d Mon Sep 17 00:00:00 2001 From: kenta7777 Date: Wed, 7 Nov 2018 08:58:21 +0900 Subject: [PATCH 0411/1812] removed jemalloc statements. --- src/how-to-build-and-run.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 863536a06..d89457257 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -41,10 +41,6 @@ debuginfo = true # Gives you line numbers for backtraces. debuginfo-lines = true - -# Link the compiler against `jemalloc`, where on Linux and OSX it should -# override the default allocator for rustc and LLVM. -jemalloc = false ``` ### What is x.py? From 6d01e7ceb2df04cad9bd6e85663dbdd1eb17e03b Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Thu, 8 Nov 2018 13:42:44 +0300 Subject: [PATCH 0412/1812] Rename trans to codegen --- src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index d89457257..89ad47199 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -24,7 +24,7 @@ settings (and possibly others, such as `llvm.ccache`): [llvm] # Enables LLVM assertions, which will check that the LLVM bitcode generated # by the compiler is internally consistent. These are particularly helpful -# if you edit `trans`. +# if you edit `codegen`. assertions = true [rust] From 76be9f99d706d7ac4d10104f44483dd78d6d947a Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Thu, 8 Nov 2018 15:29:17 +0300 Subject: [PATCH 0413/1812] Remove reference to copyright comment We don't need them anymore --- src/tests/adding.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 418287355..5b8674814 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -72,10 +72,9 @@ directory structure to use is actually an area of active debate.) ## Comment explaining what the test is about When you create a test file, **include a comment summarizing the point -of the test immediately after the copyright notice**. This should -highlight which parts of the test are more important, and what the bug -was that the test is fixing. Citing an issue number is often very -helpful. +of the test at the start of the file**. This should highlight which +parts of the test are more important, and what the bug was that the +test is fixing. Citing an issue number is often very helpful. This comment doesn't have to be super extensive. Just something like "Regression test for #18060: match arms were matching in the wrong From 97e853022f2e6be88443e1bbb93942aa3a16c813 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 8 Nov 2018 20:29:45 -0600 Subject: [PATCH 0414/1812] minor improvements --- src/borrow_check.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/borrow_check.md b/src/borrow_check.md index 40858b1b4..b3eeaa387 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -51,13 +51,14 @@ the [`mir_borrowck`] query. the purpose of this type check is to determine all of the constraints between different regions. - Next, we do [region inference](borrow_check/region_inference.html), which computes - the values of each region — basically, points in the control-flow graph. + the values of each region — basically, the points in the control-flow graph where + each lifetime must be valid according to the constraints we collected. - At this point, we can compute the "borrows in scope" at each point. - Finally, we do a second walk over the MIR, looking at the actions it does and reporting errors. For example, if we see a statement like `*a + 1`, then we would check that the variable `a` is initialized and that it is not mutably borrowed, as either of those would - require an error to be reported. - - Doing this check requires the results of all the previous analyses. + require an error to be reported. Doing this check requires the results of all + the previous analyses. [`replace_regions_in_mir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.replace_regions_in_mir.html From 5194978cc7bea075583e75a77ac3d730ffda86f1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 8 Nov 2018 20:38:14 -0600 Subject: [PATCH 0415/1812] add a few links to rustdocs --- src/borrow_check/region_inference.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 95c2bc804..e35849ef6 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -9,7 +9,7 @@ deprecated once they become the standard kind of lifetime.) The MIR-based region analysis consists of two major functions: -- `replace_regions_in_mir`, invoked first, has two jobs: +- [`replace_regions_in_mir`], invoked first, has two jobs: - First, it finds the set of regions that appear within the signature of the function (e.g., `'a` in `fn foo<'a>(&'a u32) { ... }`). These are called the "universal" or "free" regions – in @@ -21,21 +21,28 @@ The MIR-based region analysis consists of two major functions: not of much interest. The intention is that – eventually – they will be "erased regions" (i.e., no information at all), since we won't be doing lexical region inference at all. -- `compute_regions`, invoked second: this is given as argument the +- [`compute_regions`], invoked second: this is given as argument the results of move analysis. It has the job of computing values for all the inference variables that `replace_regions_in_mir` introduced. - To do that, it first runs the [MIR type checker](#mirtypeck). This is basically a normal type-checker but specialized to MIR, which - is much simpler than full Rust of course. Running the MIR type + is much simpler than full Rust, of course. Running the MIR type checker will however create **outlives constraints** between region variables (e.g., that one variable must outlive another one) to reflect the subtyping relationships that arise. - It also adds **liveness constraints** that arise from where variables are used. - - More details to come, though the [NLL RFC] also includes fairly thorough - (and hopefully readable) coverage. + - After this, we create a [`RegionInferenceContext`] with the constraints we + have computed and the inference variables we introduced and use the + [`solve`] method to infer values for all region inference varaibles. + - The [NLL RFC] also includes fairly thorough (and hopefully readable) + coverage. [fvb]: ../appendix/background.html#free-vs-bound +[`replace_regions_in_mir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.replace_regions_in_mir.html +[`compute_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.compute_regions.html +[`RegionInferenceContext`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html +[`solve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.solve [NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html ## Universal regions From 9f435099c106c7c26a9b9ed2007b4a7a0ea9c708 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 8 Nov 2018 21:34:17 -0600 Subject: [PATCH 0416/1812] fill out the borrowck chapter a bit more --- src/borrow_check/region_inference.md | 109 ++++++++++++++++++++++----- 1 file changed, 92 insertions(+), 17 deletions(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index e35849ef6..d08e06a80 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -24,7 +24,7 @@ The MIR-based region analysis consists of two major functions: - [`compute_regions`], invoked second: this is given as argument the results of move analysis. It has the job of computing values for all the inference variables that `replace_regions_in_mir` introduced. - - To do that, it first runs the [MIR type checker](#mirtypeck). This + - To do that, it first runs the [MIR type checker]. This is basically a normal type-checker but specialized to MIR, which is much simpler than full Rust, of course. Running the MIR type checker will however create **outlives constraints** between @@ -44,29 +44,26 @@ The MIR-based region analysis consists of two major functions: [`RegionInferenceContext`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html [`solve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.solve [NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html +[MIR type checker]: ./type_check.md ## Universal regions -*to be written* – explain the `UniversalRegions` type +The [`UnversalRegions`] type represents a collection of _unversal_ regions +corresponding to some MIR `DefId`. It is constructed in +[`replace_regions_in_mir`] when we replace all regions with fresh inference +variables. [`UniversalRegions`] contains indices for all the free regions in +the given MIR along with any relationships that are _known_ to hold between +them (e.g. implied bounds, where clauses, etc.). -## Region variables and constraints +TODO: is there more to write here? -*to be written* – describe the `RegionInferenceContext` and -the role of `liveness_constraints` vs other `constraints`, plus +[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/universal_regions/struct.UniversalRegions.html -## Closures - -*to be written* - - +## Region variables -## The MIR type-check - -## Representing the "values" of a region variable - -The value of a region can be thought of as a **set**; we call the -domain of this set a `RegionElement`. In the code, the value for all -regions is maintained in +The value of a region can be thought of as a **set** of points in the MIR where +the region is valid; we call the domain of this set a `RegionElement`. In the +code, the value for all regions is maintained in [the `rustc_mir::borrow_check::nll::region_infer` module][ri]. For each region we maintain a set storing what elements are present in its value (to make this efficient, we give each kind of element an index, @@ -90,11 +87,86 @@ The kinds of region elements are as follows: for details on placeholders, see the section [placeholders and universes](#placeholder). +## Constraints + +Before we can infer the value of regions, we need to collect constraints on the +regions. There are two primary types of constraints. + +1. Outlives constraints. These are constraints that one region outlives another + (e.g. `'a: 'b`). Outlives constraints are generated by the [MIR type + checker]. +2. Liveness constraints. Each region needs to be live at points where it can be + used. These constraints are collected by [`generate_constraints`]. + +[`generate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraint_generation/fn.generate_constraints.html + +## Inference Overview + +So how do we compute the contents of a region? This process is called _region +inference_. The high-level idea is pretty simple, but there are some details we +need to take care of. + +The [`RegionInferenceContext`] type contains all of the information needed to +do inference, including the universal regions from `replace_regions_in_mir` and +the constraints computed for each region. It is constructed just after we +compute the liveness constraints. + +Here are some of the fields of the struct: + +- `constraints`: contains all the outlives constraints. +- `liveness_constraints`: contains all the liveness constraints. +- `universal_regions`: contains the `UniversalRegions` returned by + `replace_regions_in_mir`. +- `universal_region_relations`: contains relations known to be true about + universal regions. For example, if we have a where clause that `'a: 'b`, that + relation is assumed to be true while borrow checking the implementation (it + is checked at the caller), so `universal_region_relations` would contain `'a: + 'b`. +- `type_tests`: contains some constraints on types that we must check after + inference (e.g. `T: 'a`). +- `closure_bounds_mapping`: used for propagating region constraints from + closures back out to the creater of the closure. + +TODO: should we discuss any of the others fields? What about the SCCs? + +Ok, now that we have constructed a `RegionInferenceContext`, we can do +inference. This is done by calling the [`solve`] method on the context. + +We will start off the value of each region with the liveness constraints (the +places we already know must be in the region). We will then use the outlives +constraints to widen each region until all constraints are met. This is done in +[`propagate_constraints`]. For each region, if `'a: 'b`, we add all elements of +`'b` to `'a`. + +Then, we will check for errors. We first check that type tests are satisfied by +calling [`check_type_tests`]. This checks constraints like `T: 'a`. Second, we +check that universal regions are not "too big". This is done by calling +[`check_universal_regions`]. This checks that for each region `'a` if `'a` +contains the element `end('b)`, then we must already know that `'a: 'b` holds +(e.g. from a where clause). If we don't already know this, that is an error... +well, almost. + +[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints +[`check_type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_type_tests +[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions + +## Closures + +When we are checking the type tests and universal regions, we may come across a +constraint that we can't prove yet if we are in a closure body! However, the +necessary constraints may actually hold (we just don't know it yet). Thus, if +we are inside a closure, we just collect all the constraints we can't prove yet +and return them. Later, when we are borrow check the MIR node that created the +closure, we can also check that these constraints hold. At that time, if we +can't prove they hold, we report an error. + ## Causal tracking *to be written* – describe how we can extend the values of a variable with causal tracking etc +TODO: is this what I described above or something else? + ## Placeholders and universes @@ -541,3 +613,6 @@ Now constraint propagation is done, but when we check the outlives relationships, we find that `V2` includes this new element `placeholder(1)`, so we report an error. +## Borrow Checker Errors + +TODO: we should discuss how to generate errors from the results of these analyses. From 9d2e781896af6a86b28e5c1a464d4c6872fc7146 Mon Sep 17 00:00:00 2001 From: Gareth Ellis Date: Thu, 8 Nov 2018 19:55:46 -0800 Subject: [PATCH 0417/1812] Fixed Spelling Mistake In MIR/index.md - "alloated" --- src/mir/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/index.md b/src/mir/index.md index d69606d66..baaf23c36 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -38,7 +38,7 @@ This section introduces the key concepts of MIR, summarized here: the end of a block - (if you're not familiar with the term *basic block*, see the [background chapter][cfg]) -- **Locals:** Memory locations alloated on the stack (conceptually, at +- **Locals:** Memory locations allocated on the stack (conceptually, at least), such as function arguments, local variables, and temporaries. These are identified by an index, written with a leading underscore, like `_1`. There is also a special "local" From bed7044bbd774bbf0d9d3c6193298489c1810192 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Thu, 8 Nov 2018 16:46:39 +0300 Subject: [PATCH 0418/1812] document the interaction between macros and nameres "The name resolution is a separate pass" is a wishful thinking :( --- src/name-resolution.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/name-resolution.md b/src/name-resolution.md index bba3142fc..3117217e5 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -1,12 +1,17 @@ # Name resolution -The name resolution is a separate pass in the compiler. Its input is the syntax -tree, produced by parsing input files. It produces links from all the names in -the source to relevant places where the name was introduced. It also generates +The name resolution is a two-phase process. In the first phase, which runs +during macro expansion, we build a tree of modules and resolve imports. Macro +expansion and name resolution communicate with each other via the `Resolver` +trait, defined in `libsyntax`. + +The input to the second phase is the syntax tree, produced by parsing input +files and expanding macros. This phase produces links from all the names in the +source to relevant places where the name was introduced. It also generates helpful error messages, like typo suggestions, traits to import or lints about unused items. -A successful run of the name resolution (`Resolver::resolve_crate`) creates kind +A successful run of the second phase (`Resolver::resolve_crate`) creates kind of an index the rest of the compilation may use to ask about the present names (through the `hir::lowering::Resolver` interface). From 80b656fa7c2e2c813a63884d6f3b4d5d073456c2 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Fri, 2 Nov 2018 12:43:36 +0100 Subject: [PATCH 0419/1812] Document MIR building somewhat --- src/mir/construction.md | 110 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) diff --git a/src/mir/construction.md b/src/mir/construction.md index 898fcd529..606301fdb 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -1 +1,111 @@ # MIR construction + +The lowering of [HIR] to [MIR] occurs for the following (probably incomplete) +list of items: + +* Function and Closure bodies +* Initializers of `static` and `const` items +* Initializers of enum discriminants +* Glue and Shims of any kind + * Tuple struct initializer functions + * Drop code (the `Drop::drop` function is not called directly) + * Drop implementations of types without an explicit `Drop` implementation + +The lowering is triggered by calling the `mir_built` query. The entire lowering +code lives in `src/librustc_mir/build`. There is an intermediate representation +between [HIR] and [MIR] called the `HAIR` that is only used during the lowering. +The `HAIR` has datatypes that mirror the [HIR] datatypes, but instead of e.g. `-x` +being a `hair::ExprKind::Neg(hair::Expr)` it is a `hair::ExprKind::Neg(hir::Expr)`. + +This shallowness enables the `HAIR` to represent all datatypes that [HIR] has, but +without having to create an in-memory copy of the entire [HIR]. The `HAIR` also +does a few simplifications, e.g. method calls and function calls have been merged +into a single variant. + +The lowering creates local variables for every argument as specified in the signature. +Next it creates local variables for every binding specified (e.g. `(a, b): (i32, String)`) +produces 3 bindings, one for the argument, and two for the bindings. Next it generates +field accesses that read the fields from the argument and writes the value to the binding +variable. + +With this initialization out of the way, the lowering triggers a recursive call +to a function that generates the MIR for the body (a `Block` expression) and +writes the result into the `RETURN_PLACE`. + +## `unpack!` all the things + +One important thing of note is the `unpack!` macro, which accompanies all recursive +calls. The macro ensures, that you get the result of the recursive call while updating +the basic block that you are now in. As an example: lowering `a + b` will need to do +three somewhat independent things: + +* give you an `Rvalue` referring to the result of the operation +* insert an assertion ensuring that the operation does not overflow +* tell you in which basic block you should write further operations into, because + the basic block has changed due to the inserted assertion (assertions terminate + blocks and jump either to a panic block or a newly created block, the latter being + the one you get back). + +The `unpack!` macro will call the recursive function you pass it, return the `Rvalue` +and update the basic block by mutating the basic block variable you pass to it. + +## Lowering expressions into the desired MIR + +There are essentially four kinds of representations one might want of a value: + +* `Place` refers to a (or a part of) preexisting memory location (local, static, promoted) +* `Rvalue` is something that can be assigned to a `Place` +* `Operand` is an argument to e.g. a `+` operation or a function call +* a temporary variable containing a copy of the value + +Since we start out with lowering the function body to an `Rvalue` so we can create an +assignment to `RETURN_PLACE`, that `Rvalue` lowering will in turn trigger lowering to +`Operand` for its arguments (if any). `Operand` lowering either produces a `const` +operand, or moves/copies out of a `Place`, thus triggering a `Place` lowering. An +expression being lowered to a `Place` can in turn trigger a temporary to be created +if the expression being lowered contains operations. This is where the snake bites its +own tail and we need to trigger an `Rvalue` lowering for the expression to be written +into the local. + +## Operator lowering + +Operators on builtin types are not lowered to function calls (which would end up being +infinite recursion calls, because the trait impls just contain the operation itself +again). Instead there are `Rvalue`s for binary and unary operators and index operations. +These `Rvalue`s later get codegened to llvm primitive operations or llvm intrinsics. + +Operators on all other types get lowered to a function call to their `impl` of the +Operator's corresponding trait. + +Irrelevant of the lowering kind, the arguments to the operator are lowered to `Operand`s. +This means all arguments are either constants, or refer to an already existing value +somewhere in a local or static. + +## Method call lowering + +Method calls are lowered to the same `TerminatorKind` that function calls are. +In [MIR] there is no difference between method calls and function calls anymore. + +## Conditions + +`if` conditions and `match` statements for `enum`s without variants with fields are +lowered to `TerminatorKind::SwitchInt`. Each possible value (so `0` and `1` for `if` +conditions) has a corresponding `BasicBlock` to which the code continues. +The argument being branched on is again an `Operand`. + +### Pattern matching + +`match` statements for `enum`s with variants that have fields are lowered to +`TerminatorKind::SwitchInt`, too, but the `Operand` refers to a `Place` where the +discriminant of the value can be found. This often involves reading the discriminant +to a new temporary variable. + +## Aggregate construction + +Aggregate values of any kind are built via `Rvalue::Aggregate`. All fields are +lowered to `Operator`s. This is essentially equivalent to one assignment +statement per aggregate field plus an assignment to the discriminant in the +case of `enum`s. + +[MIR]: ./index.html +[HIR]: ../hir.html \ No newline at end of file From a7c23651b71f2799d0aba15721e3cae717b80f64 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 5 Nov 2018 07:37:14 +0100 Subject: [PATCH 0420/1812] Link to docs and address some review comments --- src/mir/construction.md | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 606301fdb..d329da3c1 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -11,16 +11,22 @@ list of items: * Drop code (the `Drop::drop` function is not called directly) * Drop implementations of types without an explicit `Drop` implementation -The lowering is triggered by calling the `mir_built` query. The entire lowering -code lives in `src/librustc_mir/build`. There is an intermediate representation -between [HIR] and [MIR] called the `HAIR` that is only used during the lowering. -The `HAIR` has datatypes that mirror the [HIR] datatypes, but instead of e.g. `-x` +The lowering is triggered by calling the [`mir_built`] query. +There is an intermediate representation +between [HIR] and [MIR] called the [HAIR] that is only used during the lowering. +The [HAIR]'s most important feature is that the various adjustments that happen +without explicit syntax (coercion, autoderef, autoref, ...) have become explicit +casts, deref operations or reference expressions. + +The [HAIR] has datatypes that mirror the [HIR] datatypes, but instead of e.g. `-x` being a `hair::ExprKind::Neg(hair::Expr)` it is a `hair::ExprKind::Neg(hir::Expr)`. - This shallowness enables the `HAIR` to represent all datatypes that [HIR] has, but -without having to create an in-memory copy of the entire [HIR]. The `HAIR` also +without having to create an in-memory copy of the entire [HIR]. The [HAIR] also does a few simplifications, e.g. method calls and function calls have been merged -into a single variant. +into a single variant. [MIR] lowering will first convert the topmost expression from +[HIR] to [HAIR] (in +[https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/cx/expr/index.html]) +and then process the [HAIR] expressions recursively. The lowering creates local variables for every argument as specified in the signature. Next it creates local variables for every binding specified (e.g. `(a, b): (i32, String)`) @@ -35,7 +41,7 @@ writes the result into the `RETURN_PLACE`. ## `unpack!` all the things One important thing of note is the `unpack!` macro, which accompanies all recursive -calls. The macro ensures, that you get the result of the recursive call while updating +calls. The macro ensures that you get the result of the recursive call while updating the basic block that you are now in. As an example: lowering `a + b` will need to do three somewhat independent things: @@ -108,4 +114,6 @@ statement per aggregate field plus an assignment to the discriminant in the case of `enum`s. [MIR]: ./index.html -[HIR]: ../hir.html \ No newline at end of file +[HIR]: ../hir.html +[HAIR]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/index.html +[`mir_built`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.mir_built.html From 02ce4af2b066033eef6887d4072d1e7aa15a00fd Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 5 Nov 2018 07:39:18 +0100 Subject: [PATCH 0421/1812] Split overcomplicated sentence into two --- src/mir/construction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index d329da3c1..a82a5e3a4 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -64,8 +64,8 @@ There are essentially four kinds of representations one might want of a value: * `Operand` is an argument to e.g. a `+` operation or a function call * a temporary variable containing a copy of the value -Since we start out with lowering the function body to an `Rvalue` so we can create an -assignment to `RETURN_PLACE`, that `Rvalue` lowering will in turn trigger lowering to +We start out with lowering the function body to an `Rvalue` so we can create an +assignment to `RETURN_PLACE`, This `Rvalue` lowering will in turn trigger lowering to `Operand` for its arguments (if any). `Operand` lowering either produces a `const` operand, or moves/copies out of a `Place`, thus triggering a `Place` lowering. An expression being lowered to a `Place` can in turn trigger a temporary to be created From 9660fbada5cd180aa13d424fcc6b82f948f56587 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 5 Nov 2018 07:46:24 +0100 Subject: [PATCH 0422/1812] Explain the unpack! macro --- src/mir/construction.md | 56 ++++++++++++++++++++++++++++++----------- 1 file changed, 42 insertions(+), 14 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index a82a5e3a4..3e300d43d 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -40,20 +40,48 @@ writes the result into the `RETURN_PLACE`. ## `unpack!` all the things -One important thing of note is the `unpack!` macro, which accompanies all recursive -calls. The macro ensures that you get the result of the recursive call while updating -the basic block that you are now in. As an example: lowering `a + b` will need to do -three somewhat independent things: - -* give you an `Rvalue` referring to the result of the operation -* insert an assertion ensuring that the operation does not overflow -* tell you in which basic block you should write further operations into, because - the basic block has changed due to the inserted assertion (assertions terminate - blocks and jump either to a panic block or a newly created block, the latter being - the one you get back). - -The `unpack!` macro will call the recursive function you pass it, return the `Rvalue` -and update the basic block by mutating the basic block variable you pass to it. +Functions that generate MIR tend to fall into one of two patterns. +First, if the function generates only statements, then it will take a +basic block as argument onto which those statements should be appended. +It can then return a result as normal: + +```rust +fn generate_some_mir(&mut self, block: BasicBlock) -> ResultType { + ... +} +``` + +But there are other functions that may generate new basic blocks as well. +For example, lowering an expression like `if foo { 22 } else { 44 }` +requires generating a small "diamond-shaped graph". +In this case, the functions take a basic block where their code starts +and return a (potentially) new basic block where the code generation ends. +The `BlockAnd` type is used to represent this: + +```rust +fn generate_more_mir(&mut self, block: BasicBlock) -> BlockAnd { + ... +} +``` + +When you invoke these functions, it is common to have a local variable `block` that is effectively a "cursor". It represents the point at which we are adding new MIR. When you invoke `generate_more_mir`, you want to update this cursor. You can do this manually, but it's tedious: + +```rust +let mut block; +let v = match self.generate_more_mir(..) { + BlockAnd { block: new_block, value: v } => { + block = new_block; + v + } +}; +``` + +For this reason, we offer a macro that lets you write +`let v = unpack!(block = self.generate_more_mir(...))`. +It simply extracts the new block and overwrites the +variable `block` that you named in the `unpack!`. +MIR functions that generate statements always take as argument a +basic block onto which the statements should be appended. ## Lowering expressions into the desired MIR From 1dd32368273fe67b74715a192e2867245fcb1e00 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 5 Nov 2018 07:52:09 +0100 Subject: [PATCH 0423/1812] Address most other review comments --- src/mir/construction.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 3e300d43d..b7bd6bec6 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -14,16 +14,16 @@ list of items: The lowering is triggered by calling the [`mir_built`] query. There is an intermediate representation between [HIR] and [MIR] called the [HAIR] that is only used during the lowering. -The [HAIR]'s most important feature is that the various adjustments that happen -without explicit syntax (coercion, autoderef, autoref, ...) have become explicit -casts, deref operations or reference expressions. +The [HAIR]'s most important feature is that the various adjustments (which happen +without explicit syntax) like coercions, autoderef, autoref and overloaded method +calls have become explicit casts, deref operations, reference expressions or +concrete function calls. The [HAIR] has datatypes that mirror the [HIR] datatypes, but instead of e.g. `-x` being a `hair::ExprKind::Neg(hair::Expr)` it is a `hair::ExprKind::Neg(hir::Expr)`. This shallowness enables the `HAIR` to represent all datatypes that [HIR] has, but -without having to create an in-memory copy of the entire [HIR]. The [HAIR] also -does a few simplifications, e.g. method calls and function calls have been merged -into a single variant. [MIR] lowering will first convert the topmost expression from +without having to create an in-memory copy of the entire [HIR]. +[MIR] lowering will first convert the topmost expression from [HIR] to [HAIR] (in [https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/cx/expr/index.html]) and then process the [HAIR] expressions recursively. @@ -85,7 +85,7 @@ basic block onto which the statements should be appended. ## Lowering expressions into the desired MIR -There are essentially four kinds of representations one might want of a value: +There are essentially four kinds of representations one might want of an expression: * `Place` refers to a (or a part of) preexisting memory location (local, static, promoted) * `Rvalue` is something that can be assigned to a `Place` From 8e708929c3bfe98ca3e1c103192fdba7c08f7818 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 5 Nov 2018 12:59:19 +0100 Subject: [PATCH 0424/1812] Fix tidy --- src/mir/construction.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index b7bd6bec6..fec1df677 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -64,7 +64,10 @@ fn generate_more_mir(&mut self, block: BasicBlock) -> BlockAnd { } ``` -When you invoke these functions, it is common to have a local variable `block` that is effectively a "cursor". It represents the point at which we are adding new MIR. When you invoke `generate_more_mir`, you want to update this cursor. You can do this manually, but it's tedious: +When you invoke these functions, it is common to have a local variable `block` +that is effectively a "cursor". It represents the point at which we are adding new MIR. +When you invoke `generate_more_mir`, you want to update this cursor. +You can do this manually, but it's tedious: ```rust let mut block; From 38947d5d2f8028db3d87e787a281da3b2e7c1328 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 18:58:29 +0100 Subject: [PATCH 0425/1812] Grammar nit Co-Authored-By: oli-obk --- src/mir/construction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index fec1df677..3c0fbd11a 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -90,7 +90,7 @@ basic block onto which the statements should be appended. There are essentially four kinds of representations one might want of an expression: -* `Place` refers to a (or a part of) preexisting memory location (local, static, promoted) +* `Place` refers to a (or part of a) preexisting memory location (local, static, promoted) * `Rvalue` is something that can be assigned to a `Place` * `Operand` is an argument to e.g. a `+` operation or a function call * a temporary variable containing a copy of the value From 9681f2cb88c1050b4670304c979039fef382eb29 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 19:01:59 +0100 Subject: [PATCH 0426/1812] caps nit Co-Authored-By: oli-obk --- src/mir/construction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 3c0fbd11a..b22b67a36 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -112,7 +112,7 @@ again). Instead there are `Rvalue`s for binary and unary operators and index ope These `Rvalue`s later get codegened to llvm primitive operations or llvm intrinsics. Operators on all other types get lowered to a function call to their `impl` of the -Operator's corresponding trait. +operator's corresponding trait. Irrelevant of the lowering kind, the arguments to the operator are lowered to `Operand`s. This means all arguments are either constants, or refer to an already existing value From 33558bdac6cfb0a4fa4a0504f154b74e778012db Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 19:02:14 +0100 Subject: [PATCH 0427/1812] english is hard Co-Authored-By: oli-obk --- src/mir/construction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index b22b67a36..4217a58a2 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -114,7 +114,7 @@ These `Rvalue`s later get codegened to llvm primitive operations or llvm intrins Operators on all other types get lowered to a function call to their `impl` of the operator's corresponding trait. -Irrelevant of the lowering kind, the arguments to the operator are lowered to `Operand`s. +Regardless of the lowering kind, the arguments to the operator are lowered to `Operand`s. This means all arguments are either constants, or refer to an already existing value somewhere in a local or static. From 030670699a10be13910d66d978f50ced08256681 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 19:02:49 +0100 Subject: [PATCH 0428/1812] Missing connection between two consecutive sentences Co-Authored-By: oli-obk --- src/mir/construction.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 4217a58a2..5f54e2180 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -128,7 +128,8 @@ In [MIR] there is no difference between method calls and function calls anymore. `if` conditions and `match` statements for `enum`s without variants with fields are lowered to `TerminatorKind::SwitchInt`. Each possible value (so `0` and `1` for `if` conditions) has a corresponding `BasicBlock` to which the code continues. -The argument being branched on is again an `Operand`. +The argument being branched on is (again) an `Operand` representing the value of +the if condition. ### Pattern matching From f4978b56469382f37e8717f58069634267b2371b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Nov 2018 19:03:29 +0100 Subject: [PATCH 0429/1812] Clarify aggregates Co-Authored-By: oli-obk --- src/mir/construction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 5f54e2180..d2ce16449 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -140,7 +140,7 @@ to a new temporary variable. ## Aggregate construction -Aggregate values of any kind are built via `Rvalue::Aggregate`. All fields are +Aggregate values of any kind (e.g. structs or tuples) are built via `Rvalue::Aggregate`. All fields are lowered to `Operator`s. This is essentially equivalent to one assignment statement per aggregate field plus an assignment to the discriminant in the case of `enum`s. From 21beb7738a0fd2e1870e0925f04c91144b76d94c Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Thu, 8 Nov 2018 18:57:59 +0100 Subject: [PATCH 0430/1812] Remove a sentence from the end of a chapter because it also appears right at the start of the chapter --- src/mir/construction.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index d2ce16449..1e52730a2 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -83,8 +83,6 @@ For this reason, we offer a macro that lets you write `let v = unpack!(block = self.generate_more_mir(...))`. It simply extracts the new block and overwrites the variable `block` that you named in the `unpack!`. -MIR functions that generate statements always take as argument a -basic block onto which the statements should be appended. ## Lowering expressions into the desired MIR From ce79098344fa85a5d02a2adbcac983cb282559dd Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Thu, 8 Nov 2018 19:29:37 +0100 Subject: [PATCH 0431/1812] Line length checks --- src/mir/construction.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 1e52730a2..314e0daa1 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -126,7 +126,7 @@ In [MIR] there is no difference between method calls and function calls anymore. `if` conditions and `match` statements for `enum`s without variants with fields are lowered to `TerminatorKind::SwitchInt`. Each possible value (so `0` and `1` for `if` conditions) has a corresponding `BasicBlock` to which the code continues. -The argument being branched on is (again) an `Operand` representing the value of +The argument being branched on is (again) an `Operand` representing the value of the if condition. ### Pattern matching @@ -138,7 +138,8 @@ to a new temporary variable. ## Aggregate construction -Aggregate values of any kind (e.g. structs or tuples) are built via `Rvalue::Aggregate`. All fields are +Aggregate values of any kind (e.g. structs or tuples) are built via `Rvalue::Aggregate`. +All fields are lowered to `Operator`s. This is essentially equivalent to one assignment statement per aggregate field plus an assignment to the discriminant in the case of `enum`s. From 6569862a802ade528727fbc473ba721f2b91360c Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Fri, 9 Nov 2018 10:29:56 +0100 Subject: [PATCH 0432/1812] Don't try to build some example code snippets --- src/mir/construction.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 314e0daa1..03e220cb4 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -45,7 +45,7 @@ First, if the function generates only statements, then it will take a basic block as argument onto which those statements should be appended. It can then return a result as normal: -```rust +```rust,ignore fn generate_some_mir(&mut self, block: BasicBlock) -> ResultType { ... } @@ -58,7 +58,7 @@ In this case, the functions take a basic block where their code starts and return a (potentially) new basic block where the code generation ends. The `BlockAnd` type is used to represent this: -```rust +```rust,ignore fn generate_more_mir(&mut self, block: BasicBlock) -> BlockAnd { ... } @@ -69,7 +69,7 @@ that is effectively a "cursor". It represents the point at which we are adding n When you invoke `generate_more_mir`, you want to update this cursor. You can do this manually, but it's tedious: -```rust +```rust,ignore let mut block; let v = match self.generate_more_mir(..) { BlockAnd { block: new_block, value: v } => { From ade4a4ec4715fcf35ffe1d87c6c246147f2657f2 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 9 Nov 2018 19:31:47 -0600 Subject: [PATCH 0433/1812] Don't keep recompiling! --- ci/install.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ci/install.sh b/ci/install.sh index 80f8de4e8..947d751b4 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -20,5 +20,5 @@ function cargo_install() { fi } -cargo_install mdbook 0.2 -cargo_install mdbook-linkcheck 0.2 +cargo_install mdbook 0.2.2 +cargo_install mdbook-linkcheck 0.2.3 From 07eb29fb1e78942981bcae5ca2730d86299e40f2 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 10 Nov 2018 22:06:15 -0600 Subject: [PATCH 0434/1812] start on walkthrough --- src/walkthrough.md | 147 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 147 insertions(+) diff --git a/src/walkthrough.md b/src/walkthrough.md index ab158177a..680f2b831 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -1 +1,148 @@ # Walkthrough: a typical contribution + +There are _a lot_ of ways to contribute to the rust compiler, including fixing +bugs, improving performance, helping design features, providing feedback on +existing features, etc. This chapter does not claim to scratch the surface. +Instead, it walks through the design and implementation of a new feature. Not +all of the steps and processes described here are needed for every +contribution, and I will try to point those out as they arise. + +In general, if you are interested in making a contribution and aren't sure +where to start, please feel free to ask! + +## Overview + +The feature I will discuss in this chapter is the `?` Kleene operator for +macros. Basically, we want to be able to write something like this: + +```rust +macro_rules! foo { + ($arg:ident $(, $optional_arg:ident)?) => { + println!("{}", $arg); + + $( + println!("{}", $optional_arg); + )? + } +} + +fn main() { + let x = 0; + foo!(x); // ok! prints "0" + foo!(x, x); // ok! prints "0 0" +} +``` + +So basically, the `$(pat)?` matcher in the macro means "this pattern can occur +0 or 1 times", similar to other regex syntaxes. + +There were a number of steps to go from an idea to stable rust feature. Here is +a quick list. We will go through each of these in order below. As I mentioned +before, not all of these are needed for every type of contribution. + +- **Idea discussion/Pre-RFC** A Pre-RFC is an early draft or design discussion + of a feature. This stage is intended to flesh out the design space a bit and + get a grasp on the different merits and problems with an idea. It's a great + way to get early feedback on your idea before presenting it the wider + audience. You can find the original discussion [here][prerfc]. +- **RFC** This is when you formally present your idea to the community for + consideration. You can find the RFC [here][rfc]. +- **Implementation** Implement your idea unstabley in the compiler. You can + find the original implementation [here][impl1]. +- **Possibly iterate/refine** As the community gets experience with your + feature on the nightly compiler and in `libstd`, there may be additional + feedback about design choice that might be adjusted. This particular feature + went [through][impl2] a [number][impl3] of [iterations][impl4]. +- **Stabilization** When your feature has baked enough, a rust team member may + [propose to stabilize it][merge]. If there is consensus, this is done. +- **Relax** Your feature is now a stable rust feature! + +[prerfc]: https://internals.rust-lang.org/t/pre-rfc-at-most-one-repetition-macro-patterns/6557 +[rfc]: https://github.com/rust-lang/rfcs/pull/2298 +[impl1]: https://github.com/rust-lang/rust/pull/47752 +[impl2]: https://github.com/rust-lang/rust/pull/49719 +[impl3]: https://github.com/rust-lang/rust/pull/51336 +[impl4]: https://github.com/rust-lang/rust/pull/51587 +[merge]: https://github.com/rust-lang/rust/issues/48075#issuecomment-433177613 + +## Pre-RFC and RFC + +> NOTE: In general, if you are not proposing a _new_ feature or substantial +> change to rust or the ecosystem, you don't need to follow the RFC process. +> Instead, you can just jump to [implementation](#impl). +> +> You can find the official guidelines for when to open an RFC [here][rfcwhen]. + +[rfcwhen]: https://github.com/rust-lang/rfcs#when-you-need-to-follow-this-process + +An RFC is a document that describes the feature or change you are proposing in +detail. Anyone can write an RFC; the process is the same for everyone, +including rust team members. + +To open an RFC, open a PR on the +[rust-lang/rfcs](https://github.com/rust-lang/rfcs) repo on GitHub. You can +find detailed instructions in the +[README](https://github.com/rust-lang/rfcs#what-the-process-is). + +Before opening an RFC, you should do the research to "flesh out" your idea. +Hastily-proposed RFCs tend not to be accepted. You should generally have a good +description of the motivation, impact, disadvantages, and potential +interactions with other features. + +If that sounds like a lot of work, it's because it is. But no fear! Even if +you're not a compiler hacker, you can get great feedback by doing a _pre-RFC_. +This is an _informal_ discussion of the idea. The best place to do this is +internals.rust-lang.org. Your post doesn't have to follow any particular +structure. It doesn't even need to be a cohesive idea. Generally, you will get +tons of feedback that you can integrate back to produce a good RFC. + +(Another pro-tip: try searching the RFCs repo and internals for prior related +ideas. A lot of times an idea has already been considered and was either +rejected or postponed to be tried again later. This can save you and everybody +else some time) + +In the case of our example, a participant in the pre-RFC thread pointed out a +syntax ambiguity and a potential resolution. Also, the overall feedback seemed +positive. In this case, the discussion converged pretty quickly, but for some +ideas, a lot more discussion can happen (e.g. see [this RFC][nonascii] which +received a whopping 684 comments!). If that happens, don't be discouraged; it +means the community is interested in your idea, but it perhaps needs some +adjustments. + +[nonascii]: https://github.com/rust-lang/rfcs/pull/2457 + +The RFC for our `?` macro feature did receive some discussion on the RFC thread +too. As with most RFCs, there were a few questions that we couldn't answer by +discussion: we needed experience using the feature to decide. Such questions +are listed in the "Unresolved Questions" section of the RFC. Also, over the +course of the RFC discussion, you will probably want to update the RFC document +itself to reflect the course of the discussion (e.g. new alternatives or prior +work may be added or you may decide to change parts of the proposal itself). + +In the end, when the discussion seems to reach a consensus and die down a bit, +a rust team member may propose [to merge the RFC][rfcmerge]. This means that +they want the other members of the appropriate teams to review and comment on +the RFC. More changes may be proposed. At some point, when everyone is +satisfied, the RFC enters the "final comment period" (FCP), which is the last +chance for people to bring up objections. When the FCP is over, the RFC is +"merged" (or accepted). + +[rfcmerge]: https://github.com/rust-lang/rfcs/pull/2298#issuecomment-360582667 + +Some other possible outcomes might be for a team member to propose to + +- _Close_: this feature in its current form is not a good fit for rust. Don't + be discouraged if this happens to your RFC, and don't take it personally. + This is not a reflection on you, but rather a community decision that rust + will go a different direction. +- _Postpone_: there is interest in going this direction but not at the moment. + This happens most often because the appropriate rust team doesn't have the + bandwidth to shepherd the feature through the process to stabilization. Often + this is the case when the feature doesn't fit into the team's roadmap. + Postponed ideas may be revisited later. + + + +## Implementation + +TODO From a5b158f044cac668197588da5fb4694c2f8c38c3 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 10 Nov 2018 22:41:27 -0600 Subject: [PATCH 0435/1812] add a bit more --- src/walkthrough.md | 67 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index 680f2b831..738828bbe 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -15,7 +15,7 @@ where to start, please feel free to ask! The feature I will discuss in this chapter is the `?` Kleene operator for macros. Basically, we want to be able to write something like this: -```rust +```rust,ignore macro_rules! foo { ($arg:ident $(, $optional_arg:ident)?) => { println!("{}", $arg); @@ -145,4 +145,69 @@ Some other possible outcomes might be for a team member to propose to ## Implementation +To make a change to the compiler, open a PR against the [rust-lang/rust] repo. + +[rust-lang/rust]: https://github.com/rust-lang/rust + +Depending on the feature/change/bug fix/improvement, implementation may be +relatively-straightforward or it may be a major undertaking. You can always ask +for help or mentorship from more experienced compiler devs. Also, you don't +have to be the one to implement your feature; but keep in mind that if you +don't it might be a while before someone else does. + +For the `?` macro feature, I needed to go understand the relevant parts of +macro expansion in the compiler. Personally, I find that [improving the +comments][comments] in the code is a helpful way of making sure I understand +it, but you don't have to do that if you don't want to. + +[comments]: https://github.com/rust-lang/rust/pull/47732 + +I then [implemented][impl1] the original feature, as described in the RFC. When +a new feature is implemented, it goes behind a _feature gate_, which means that +you have to use `#![feature(my_feature_name)]` to use the feature. The feature +gate is removed when the feature is stabilized. + +**Most bug fixes and improvements** don't require a feature gate. You can just +make your changes/improvements. + +When you open a PR on the [rust-lang/rust], a bot will assign your PR to a +review. If there is a particular rust team member you are working with, you can +request that reviewer by leaving a comment on the thread with `r? +@reviewer-github-id` (e.g. `r? @eddyb`). If you don't know who to request, +don't request anyone; the bot will assign someone automatically. + +The reviewer may request changes before they approve your PR. Feel free to ask +questions or discuss things you don't understand or disagree with. However, +recognize that the PR won't be merged unless someone on the rust team approves +it. + +When your review approves the PR, it will go into a queue for yet another bot +called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches +the head of the `@bors` queue, `@bors` will test out the merge by running all +tests against your PR on Travis CI. This takes about 2 hours as of this +writing. If all tests pass, the PR is merged and becomes part of the next +nightly compiler! + +There are a couple of things that may happen for some PRs during the review process + +- If the change is substantial enough, the reviewer may request an FCP on + the PR. This gives all members of the appropriate team a chance to review the + changes. +- If the change may cause breakage, the reviewer may request a [crater] run. + This compiles the compiler with your changes and then attempts to compile all + crates on crates.io with your modified compiler. This is a great smoke test + to check if you introduced a change to compiler behavior that affects a large + portion of the ecosystem. +- If the diff of your PR is large or the reviewer is busy, your PR may have + some merge conflicts with other PRs. You should fix these merge conflicts + using the normal git procedures. + +[crater]: ./tests/intro.html#crater + +## Refining your implementation + +TODO + +## Stabilization + TODO From 0f3cb5ef9849f29166e8053052d16d112871c3a5 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 11 Nov 2018 16:32:11 -0600 Subject: [PATCH 0436/1812] add a bit more --- src/walkthrough.md | 45 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 34 insertions(+), 11 deletions(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index 738828bbe..8cd511d92 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -120,17 +120,16 @@ itself to reflect the course of the discussion (e.g. new alternatives or prior work may be added or you may decide to change parts of the proposal itself). In the end, when the discussion seems to reach a consensus and die down a bit, -a rust team member may propose [to merge the RFC][rfcmerge]. This means that -they want the other members of the appropriate teams to review and comment on -the RFC. More changes may be proposed. At some point, when everyone is +a rust team member may propose to move to FCP with one of three possible dispositions. +This means that they want the other members of the appropriate teams to review +and comment on the RFC. More discussion may ensue, which may result in more changes +or unresolved questions being added. At some point, when everyone is satisfied, the RFC enters the "final comment period" (FCP), which is the last -chance for people to bring up objections. When the FCP is over, the RFC is -"merged" (or accepted). - -[rfcmerge]: https://github.com/rust-lang/rfcs/pull/2298#issuecomment-360582667 - -Some other possible outcomes might be for a team member to propose to +chance for people to bring up objections. When the FCP is over, the disposition is +adopted. Here are the three possible dispositions: +- _Merge_: accept the feature. Here is the proposal to merge for our [`?` macro + feature][rfcmerge]. - _Close_: this feature in its current form is not a good fit for rust. Don't be discouraged if this happens to your RFC, and don't take it personally. This is not a reflection on you, but rather a community decision that rust @@ -141,6 +140,15 @@ Some other possible outcomes might be for a team member to propose to this is the case when the feature doesn't fit into the team's roadmap. Postponed ideas may be revisited later. +[rfcmerge]: https://github.com/rust-lang/rfcs/pull/2298#issuecomment-360582667 + +When an RFC is merged, the PR is merged into the RFCs repo. A new _tracking +issue_ is created in the [rust-lang/rust] repo to track progress on the feature +and discuss unresolved questions, implementation progress and blockers, etc. +Here is the tracking issue on for our [`?` macro feature][tracking]. + +[tracking]: https://github.com/rust-lang/rust/issues/48075 + ## Implementation @@ -199,15 +207,30 @@ There are a couple of things that may happen for some PRs during the review proc to check if you introduced a change to compiler behavior that affects a large portion of the ecosystem. - If the diff of your PR is large or the reviewer is busy, your PR may have - some merge conflicts with other PRs. You should fix these merge conflicts - using the normal git procedures. + some merge conflicts with other PRs that happen to get merged first. You + should fix these merge conflicts using the normal git procedures. [crater]: ./tests/intro.html#crater +If you are not doing a new feature or something like that (e.g. if you are +fixing a bug), then that's it! Thanks for your contribution :) + ## Refining your implementation +As people get experience with your new feature on nightly, slight changes may +be proposed and unresolved questions may become resolved. Updates/changes go +through the same process for implementing any other changes, as described +above (i.e. submit a PR, go through review, wait for `@bors`, etc). + +Some changes may be major enough to require an FCP and some review by rust team +members. + +For the `?` macro feature, we went through a few different iterations after the +original implementation: [1][impl2], [2][impl3], [3][impl4]. + TODO + ## Stabilization TODO From a2404ba0716fe22a4d3c362f868ba0992e5a00ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?F=C3=A9lix=20Fischer?= Date: Thu, 15 Nov 2018 00:46:25 -0300 Subject: [PATCH 0437/1812] Fix typo (#238) "is is" ~> "it is" --- src/traits/lowering-to-logic.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/traits/lowering-to-logic.md b/src/traits/lowering-to-logic.md index a0490adf3..e1a6c1361 100644 --- a/src/traits/lowering-to-logic.md +++ b/src/traits/lowering-to-logic.md @@ -50,7 +50,7 @@ so by applying the rules recursively: - `Clone(Vec>)` is provable if: - `Clone(Vec)` is provable if: - - `Clone(usize)` is provable. (Which is is, so we're all good.) + - `Clone(usize)` is provable. (Which it is, so we're all good.) But now suppose we tried to prove that `Clone(Vec)`. This would fail (after all, I didn't give an impl of `Clone` for `Bar`): @@ -130,8 +130,8 @@ Ok, so far so good. Let's move on to type-checking a more complex function. In the last section, we used standard Prolog horn-clauses (augmented with Rust's notion of type equality) to type-check some simple Rust functions. But that only works when we are type-checking non-generic functions. If we want to type-check -a generic function, it turns out we need a stronger notion of goal than Prolog -can be provide. To see what I'm talking about, let's revamp our previous +a generic function, it turns out we need a stronger notion of goal than what Prolog +can provide. To see what I'm talking about, let's revamp our previous example to make `foo` generic: ```rust,ignore From ad8ebf263ce6d42c05c7dbb7be05e01cb3887ef3 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 19 Nov 2018 15:34:02 -0600 Subject: [PATCH 0438/1812] finish walkthrough --- src/walkthrough.md | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index 8cd511d92..4eae1397d 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -228,9 +228,34 @@ members. For the `?` macro feature, we went through a few different iterations after the original implementation: [1][impl2], [2][impl3], [3][impl4]. -TODO - +Along the way, we decided that `?` should not take a separator, which was +previously an unresolved question listed in the RFC. We also changed the +disambiguation strategy: we decided to remove the ability to use `?` as a +separator token for other repetition operators (e.g. `+` or `*`). However, +since this was a breaking change, we decided to do it over an edition boundary. +Thus, the new feature can be enabled only in edition 2018. These deviations +from the original RFC required [another +FCP](https://github.com/rust-lang/rust/issues/51934). ## Stabilization -TODO +Finally, after the feature had baked for a while on nightly, a language team member +[moved to stabilize it][stabilizefcp]. + +[stabilizefcp]: https://github.com/rust-lang/rust/issues/48075#issuecomment-433177613 + +A _stabilization report_ needs to be written that includes + +- brief description of the behavior and any deviations from the RFC +- which edition(s) are affected and how +- links to a few tests to show the interesting aspects + +The stabilization report for our feature is [here][stabrep]. + +[stabrep]: https://github.com/rust-lang/rust/issues/48075#issuecomment-433243048 + +After this, a PR is made to remove the feature gate, enabling the feature by +default (on the 2018 edition). A note is added to the [Release notes][relnotes] +about the feature. + +[relnotes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md From 9b6d561a33d08b546e2e981aa72983343964cdb6 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Mon, 19 Nov 2018 18:28:10 -0600 Subject: [PATCH 0439/1812] SLG: Add links and mark-i-m's suggestions --- src/traits/slg.md | 117 +++++++++++++++++++++++++++------------------- 1 file changed, 68 insertions(+), 49 deletions(-) diff --git a/src/traits/slg.md b/src/traits/slg.md index 812afd1ec..dcddd01f5 100644 --- a/src/traits/slg.md +++ b/src/traits/slg.md @@ -16,10 +16,10 @@ a set of region constraints, which we'll ignore in this introduction. There are often many, or even infinitely many, solutions to a query. For example, say we want to prove that `exists { Vec: Debug }` for _some_ -type `?T`. Our solver should be capable of iterating over each answer one at -a time, say `?T = u32`, then `?T = i32`, and so on, rather than iterating -over every type in the type system. If we need more answers, we can request -more until we are done. This is similar to how Prolog works. +type `?T`. Our solver should be capable of yielding one answer at a time, say +`?T = u32`, then `?T = i32`, and so on, rather than iterating over every type +in the type system. If we need more answers, we can request more until we are +done. This is similar to how Prolog works. *See also: [The traditional, interactive Prolog query][pq]* @@ -27,32 +27,34 @@ more until we are done. This is similar to how Prolog works. ### Breadth-first -`Vec: Debug` is true if `?T: Debug`. This leads to a cycle: `[Vec , +`Vec: Debug` is true if `?T: Debug`. This leads to a cycle: `[Vec, Vec>, Vec>>]`, and so on all implement `Debug`. Our solver ought to be breadth first and consider answers like `[Vec: Debug, Vec: Debug, ...]` before it recurses, or we may never find the answer we're looking for. -### Cache friendly +### Cachable To speed up compilation, we need to cache results, including partial results left over from past solver queries. ## Description of how it works -The basis of the solver is the `Forest` type. A *forest* stores a +The basis of the solver is the [`Forest`] type. A *forest* stores a collection of *tables* as well as a *stack*. Each *table* represents the stored results of a particular query that is being performed, as well as the various *strands*, which are basically suspended computations that may be used to find more answers. Tables are interdependent: solving one query may require solving others. +[`Forest`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/forest/struct.Forest.html + ### Walkthrough Perhaps the easiest way to explain how the solver works is to walk through an example. Let's imagine that we have the following program: -```rust +```rust,ignore trait Debug { } struct u32 { } @@ -65,19 +67,22 @@ struct Vec { } impl Debug for Vec { } ``` -Now imagine that we want to find answers for the query `exists { -Rc: Debug }`. The first step would be to u-canonicalize this query; this -is the act of giving canonical names to all the unbound inference variables based on the -order of their left-most appearance, as well as canonicalizing the universes of any -universally bound names (e.g., the `T` in `forall { ... }`). In this case, there are no -universally bound names, but the canonical form Q of the query might look something like: +Now imagine that we want to find answers for the query `exists { Rc: +Debug }`. The first step would be to u-canonicalize this query; this is the +act of giving canonical names to all the unbound inference variables based on +the order of their left-most appearance, as well as canonicalizing the +universes of any universally bound names (e.g., the `T` in `forall { ... +}`). In this case, there are no universally bound names, but the canonical +form Q of the query might look something like: + +```text +Rc: Debug +``` - Rc: Debug - where `?0` is a variable in the root universe U0. We would then go and -look for a table with this as the key: since the forest is empty, this -lookup will fail, and we will create a new table T0, corresponding to -the u-canonical goal Q. +look for a table with this canonical query as the key: since the forest is +empty, this lookup will fail, and we will create a new table T0, +corresponding to the u-canonical goal Q. **Ignoring negative reasoning and regions.** To start, we'll ignore the possibility of negative goals like `not { Foo }`. We'll phase them @@ -93,7 +98,7 @@ where-clauses that are in scope. In the case of our example, there would be three clauses, each coming from the program. Using a Prolog-like notation, these look like: -``` +```text (u32: Debug). (Rc: Debug) :- (T: Debug). (Vec: Debug) :- (T: Debug). @@ -105,9 +110,9 @@ clauses are inapplicable because `u32` and `Vec` cannot be unified with `Rc`. The second clause, however, will work. **What is a strand?** Let's talk a bit more about what a strand *is*. In the code, a strand -is the combination of an inference table, an X-clause, and (possibly) +is the combination of an inference table, an _X-clause_, and (possibly) a selected subgoal from that X-clause. But what is an X-clause -(`ExClause`, in the code)? An X-clause pulls together a few things: +([`ExClause`], in the code)? An X-clause pulls together a few things: - The current state of the goal we are trying to prove; - A set of subgoals that have yet to be proven; @@ -118,7 +123,9 @@ The general form of an X-clause is written much like a Prolog clause, but with somewhat different semantics. Since we're ignoring delayed literals and region constraints, an X-clause just looks like this: - G :- L +```text +G :- L +``` where G is a goal and L is a set of subgoals that must be proven. (The L stands for *literal* -- when we address negative reasoning, a @@ -128,7 +135,9 @@ that if we are able to prove L then the goal G can be considered true. In the case of our example, we would wind up creating one strand, with an X-clause like so: - (Rc: Debug) :- (?T: Debug) +```text +(Rc: Debug) :- (?T: Debug) +``` Here, the `?T` refers to one of the inference variables created in the inference table that accompanies the strand. (I'll use named variables @@ -141,37 +150,45 @@ is the subgoal after the turnstile (`:-`) that we are currently trying to prove in this strand. Initally, when a strand is first created, there is no selected subgoal. -**Activating a strand.** Now that we have created the table T0 and -initialized it with strands, we have to actually try and produce an -answer. We do this by invoking the `ensure_answer` operation on the -table: specifically, we say `ensure_answer(T0, A0)`, meaning "ensure -that there is a 0th answer". - -Remember that tables store not only strands, but also a vector of -cached answers. The first thing that `ensure_answer` does is to check -whether answer 0 is in this vector. If so, we can just return -immediately. In this case, the vector will be empty, and hence that -does not apply (this becomes important for cyclic checks later on). +[`ExClause`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/struct.ExClause.html -When there is no cached answer, `ensure_answer` will try to produce -one. It does this by selecting a strand from the set of active -strands -- the strands are stored in a `VecDeque` and hence processed -in a round-robin fashion. Right now, we have only one strand, storing -the following X-clause with no selected subgoal: - - (Rc: Debug) :- (?T: Debug) +**Activating a strand.** Now that we have created the table T0 and +initialized it with strands, we have to actually try and produce an answer. +We do this by invoking the [`ensure_root_answer`] operation on the table: +specifically, we say `ensure_root_answer(T0, A0)`, meaning "ensure that there +is a 0th answer A0 to query T0". + +Remember that tables store not only strands, but also a vector of cached +answers. The first thing that [`ensure_root_answer`] does is to check whether +answer A0 is in this vector. If so, we can just return immediately. In this +case, the vector will be empty, and hence that does not apply (this becomes +important for cyclic checks later on). + +When there is no cached answer, [`ensure_root_answer`] will try to produce one. +It does this by selecting a strand from the set of active strands -- the +strands are stored in a `VecDeque` and hence processed in a round-robin +fashion. Right now, we have only one strand, storing the following X-clause +with no selected subgoal: + +```text +(Rc: Debug) :- (?T: Debug) +``` When we activate the strand, we see that we have no selected subgoal, and so we first pick one of the subgoals to process. Here, there is only one (`?T: Debug`), so that becomes the selected subgoal, changing the state of the strand to: - (Rc: Debug) :- selected(?T: Debug, A0) +```text +(Rc: Debug) :- selected(?T: Debug, A0) +``` Here, we write `selected(L, An)` to indicate that (a) the literal `L` is the selected subgoal and (b) which answer `An` we are looking for. We start out looking for `A0`. +[`ensure_root_answer`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/forest/struct.Forest.html#method.ensure_root_answer + **Processing the selected subgoal.** Next, we have to try and find an answer to this selected goal. To do that, we will u-canonicalize it and try to find an associated table. In this case, the u-canonical @@ -189,7 +206,7 @@ will be: We can thus summarize the state of the whole forest at this point as follows: -``` +```text Table T0 [Rc: Debug] Strands: (Rc: Debug) :- selected(?T: Debug, A0) @@ -215,7 +232,7 @@ answer). The strand is then removed from the list of strands. The state of table T1 is therefore: -``` +```text Table T1 [?0: Debug] Answers: A0 = [?0 = u32] @@ -227,8 +244,10 @@ Table T1 [?0: Debug] Note that I am writing out the answer A0 as a substitution that can be applied to the table goal; actually, in the code, the goals for each X-clause are also represented as substitutions, but in this exposition -I've chosen to write them as full goals, following NFTD. - +I've chosen to write them as full goals, following [NFTD]. + +[NFTD]: ./bibliography.html#slg + Since we now have an answer, `ensure_answer(T1, A0)` will return `Ok` to the table T0, indicating that answer A0 is available. T0 now has the job of incorporating that result into its active strand. It does @@ -236,7 +255,7 @@ this in two ways. First, it creates a new strand that is looking for the next possible answer of T1. Next, it incorpoates the answer from A0 and removes the subgoal. The resulting state of table T0 is: -``` +```text Table T0 [Rc: Debug] Strands: (Rc: Debug) :- selected(?T: Debug, A1) @@ -250,7 +269,7 @@ then be returned up to our caller, and the whole forest goes quiescent at this point (remember, we only do enough work to generate *one* answer). The ending state of the forest at this point will be: -``` +```text Table T0 [Rc: Debug] Answer: A0 = [?0 = u32] From 49c3d4a36eebab51f5c767f4798daed72e780b56 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 26 Nov 2018 11:06:41 -0600 Subject: [PATCH 0440/1812] add link to stabilization pr --- src/walkthrough.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index 4eae1397d..e77a0f690 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -254,8 +254,16 @@ The stabilization report for our feature is [here][stabrep]. [stabrep]: https://github.com/rust-lang/rust/issues/48075#issuecomment-433243048 -After this, a PR is made to remove the feature gate, enabling the feature by +After this, [a PR is made][stab] to remove the feature gate, enabling the feature by default (on the 2018 edition). A note is added to the [Release notes][relnotes] about the feature. +[stab]: https://github.com/rust-lang/rust/pull/56245 + +TODO: currently, we have a [forge article][feature-stab] about stabilization, but +we really ought to move that to the guide (in fact, we probably should have a whole +chapter about feature gates and stabilization). + +[feature-stab]: https://forge.rust-lang.org/stabilization-guide.html + [relnotes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md From 3a804956e3c28d7e44e38804207a00013594e1d3 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 26 Nov 2018 11:13:21 -0600 Subject: [PATCH 0441/1812] make the line-length script respect 100 char limit XD (#240) :rofl: :rofl: :rofl: --- ci/check_line_lengths.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ci/check_line_lengths.sh b/ci/check_line_lengths.sh index 5b7b12d3e..32bf739e4 100755 --- a/ci/check_line_lengths.sh +++ b/ci/check_line_lengths.sh @@ -30,7 +30,9 @@ for file in "$@" ; do (( inside_block = !$inside_block )) continue fi - if ! (( $inside_block )) && ! [[ "$line" =~ " | "|"-|-"|"://"|"]:"|\[\^[^\ ]+\]: ]] && (( "${#line}" > $MAX_LINE_LENGTH )) ; then + if ! (( $inside_block )) \ + && ! [[ "$line" =~ " | "|"-|-"|"://"|"]:"|\[\^[^\ ]+\]: ]] \ + && (( "${#line}" > $MAX_LINE_LENGTH )) ; then (( bad_lines++ )) echo -e "\t$line_no : $line" fi From 3940e94a5e24e454f662ba5c13c1dceed50ff6a4 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 26 Nov 2018 15:24:39 -0600 Subject: [PATCH 0442/1812] fix relative link (#242) --- src/traits/lowering-module.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md index c9c4accc1..939484051 100644 --- a/src/traits/lowering-module.md +++ b/src/traits/lowering-module.md @@ -63,4 +63,4 @@ error: aborting due to previous error [chalkify]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify [lower_impl]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify/lower_impl.rs [the stderr file]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify/lower_impl.stderr -[ui test]: https://rust-lang-nursery.github.io/rustc-guide/tests/adding.html#guide-to-the-ui-tests +[ui test]: ../tests/adding.html#guide-to-the-ui-tests From 2f4e10ce5bf34bc2832b60f5ae4ff344333c3110 Mon Sep 17 00:00:00 2001 From: Vadim Petrochenkov Date: Sun, 2 Dec 2018 01:10:43 +0400 Subject: [PATCH 0443/1812] Fix failing tidy (line endings on Windows) (#246) This happens every time a new doc submodule is added to https://github.com/rust-lang/rust. cc https://github.com/rust-lang/book/pull/549 https://github.com/rust-lang-nursery/reference/pull/36 https://github.com/rust-lang/rust-by-example/pull/1018 --- .gitattributes | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 .gitattributes diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 000000000..d56abbf30 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,2 @@ +# Set the default behavior, in case people don't have core.autocrlf set. +* text=auto eol=lf From 344c4e437ba4cfa5c14db643ec4d6b68dcd164c5 Mon Sep 17 00:00:00 2001 From: yui-knk Date: Sat, 1 Dec 2018 22:11:05 +0900 Subject: [PATCH 0444/1812] Fix the file path where AST is defined --- src/high-level-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 733c523c9..93b5592c3 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -96,7 +96,7 @@ take: 1. **Parsing input** - this processes the `.rs` files and produces the AST ("abstract syntax tree") - - the AST is defined in `syntax/ast.rs`. It is intended to match the lexical + - the AST is defined in `src/libsyntax/ast.rs`. It is intended to match the lexical syntax of the Rust language quite closely. 2. **Name resolution, macro expansion, and configuration** - once parsing is complete, we process the AST recursively, resolving From a18f366010ecc30920f75e2c12da70d5d38d4ec6 Mon Sep 17 00:00:00 2001 From: Andy Wortman Date: Sat, 1 Dec 2018 11:30:26 -0800 Subject: [PATCH 0445/1812] fix some linkrotted links --- README.md | 2 +- src/about-this-guide.md | 2 +- src/diag.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 45c7503fe..af23454ba 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ The guide can be useful today, but it has a lot of work still go. If you'd like to help improve the guide, we'd love to have you! You can find plenty of issues on the [issue -tracker](https://github.com/rust-lang-nursery/rustc-guide/issue). Just post a +tracker](https://github.com/rust-lang/rustc-guide/issue). Just post a comment on the issue you would like to work on to make sure that we don't accidentally duplicate work. If you think something is missing, please open an issue about it! diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 79106736f..56f0b7538 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -11,4 +11,4 @@ be found at the [GitHub repository]. If you find any mistakes in the guide, please file an issue about it, or even better, open a PR with a correction! -[GitHub repository]: https://github.com/rust-lang-nursery/rustc-guide/ +[GitHub repository]: https://github.com/rust-lang/rustc-guide/ diff --git a/src/diag.md b/src/diag.md index 936420ab6..00bb23b4c 100644 --- a/src/diag.md +++ b/src/diag.md @@ -81,7 +81,7 @@ suggestions pleasingly in the terminal, or (when the `--error-format json` flag is passed) as JSON for consumption by tools, most notably the [Rust Language Server][rls] and [`rustfix`][rustfix]. -[rls]: https://github.com/rust-lang-nursery/rls +[rls]: https://github.com/rust-lang/rls [rustfix]: https://github.com/rust-lang-nursery/rustfix Not all suggestions should be applied mechanically. Use the From 0f5df93b1314e2761ac497614138bae5dbfa8b47 Mon Sep 17 00:00:00 2001 From: Edd Barrett Date: Tue, 27 Nov 2018 13:31:38 +0000 Subject: [PATCH 0446/1812] Mention that tests need a Python-enabled gdb. --- src/tests/running.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/tests/running.md b/src/tests/running.md index f8889c8a4..ceabe3a69 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -19,6 +19,10 @@ timestamp file for every test can be found under `build/ARCH/test/`. To force-rerun a test (e.g. in case the test runner fails to notice a change) you can simply remove the timestamp file. +Note that some tests require a Python-enabled gdb. If you are building +gdb from source, you need to configure with +`--with-python=`. + ## Running a subset of the test suites When working on a specific PR, you will usually want to run a smaller From 8f0eaf39613172e080bc21bda3f3567da0d03632 Mon Sep 17 00:00:00 2001 From: Edd Barrett Date: Mon, 3 Dec 2018 15:46:55 +0000 Subject: [PATCH 0447/1812] Explain how to check if gdb supports Python. --- src/tests/running.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index ceabe3a69..62f3ea4d7 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -19,8 +19,10 @@ timestamp file for every test can be found under `build/ARCH/test/`. To force-rerun a test (e.g. in case the test runner fails to notice a change) you can simply remove the timestamp file. -Note that some tests require a Python-enabled gdb. If you are building -gdb from source, you need to configure with +Note that some tests require a Python-enabled gdb. You can test if +your gdb install supports Python by using the `python` command from +within gdb (type some Python code followed by `CTRL+D` to execute it). +If you are building gdb from source, you need to configure with `--with-python=`. ## Running a subset of the test suites From 87830ff034d89b7e1e370c949aa8085b37bf68ed Mon Sep 17 00:00:00 2001 From: Edd Barrett Date: Mon, 3 Dec 2018 17:27:14 +0000 Subject: [PATCH 0448/1812] Provide a Python example. --- src/tests/running.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index 62f3ea4d7..1250fa77b 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -21,8 +21,9 @@ a change) you can simply remove the timestamp file. Note that some tests require a Python-enabled gdb. You can test if your gdb install supports Python by using the `python` command from -within gdb (type some Python code followed by `CTRL+D` to execute it). -If you are building gdb from source, you need to configure with +within gdb. Once invoked you can type some Python code (e.g. +`print("hi")`) followed by return and then `CTRL+D` to execute it. +If you are building gdb from source, you will need to configure with `--with-python=`. ## Running a subset of the test suites From 022d3f4b56c7c203a1b4ceab961fe5c3e45a993f Mon Sep 17 00:00:00 2001 From: Avelino Date: Wed, 5 Dec 2018 18:12:35 -0200 Subject: [PATCH 0449/1812] fixed typo issues link --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index af23454ba..ba5b1cde4 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ The guide can be useful today, but it has a lot of work still go. If you'd like to help improve the guide, we'd love to have you! You can find plenty of issues on the [issue -tracker](https://github.com/rust-lang/rustc-guide/issue). Just post a +tracker](https://github.com/rust-lang/rustc-guide/issues). Just post a comment on the issue you would like to work on to make sure that we don't accidentally duplicate work. If you think something is missing, please open an issue about it! From f1caa8dd77bcdc3b31532aeecaf6dc06c049e2ff Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Wed, 5 Dec 2018 07:38:34 -0800 Subject: [PATCH 0450/1812] Add some documentation about updating LLVM --- src/SUMMARY.md | 1 + src/codegen/updating-llvm.md | 149 +++++++++++++++++++++++++++++++++++ 2 files changed, 150 insertions(+) create mode 100644 src/codegen/updating-llvm.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index efe963c3f..bfb112ce6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -65,6 +65,7 @@ - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) - [Code Generation](./codegen.md) + - [Updating LLVM](./codegen/updating-llvm.md) - [Emitting Diagnostics](./diag.md) --- diff --git a/src/codegen/updating-llvm.md b/src/codegen/updating-llvm.md new file mode 100644 index 000000000..e29e041b2 --- /dev/null +++ b/src/codegen/updating-llvm.md @@ -0,0 +1,149 @@ +# Updating LLVM + +The Rust compiler uses LLVM as its primary codegen backend today, and naturally +we want to at least occasionally update this dependency! Currently we do not +have a strict policy about when to update LLVM or what it can be updated to, but +a few guidelines are applied: + +* We try to always support the latest released version of LLVM +* We try to support the "last few" versions of LLVM (how many is changing over + time) +* We allow moving to arbitrary commits during development. +* Strongly prefer to upstream all patches to LLVM before including them in + rustc. + +This policy may change over time (or may actually start to exist as a formal +policy!), but for now these are rough guidelines! + +## Why update LLVM? + +There are two primary reasons nowadays that we want to update LLVM in one way or +another: + +* First, a bug could have been fixed! Often we find bugs in the compiler and fix + them upstream in LLVM. We'll want to pull fixes back to the compiler itself as + they're merged upstream. + +* Second, a new feature may be avaiable in LLVM that we want to use in rustc, + but we don't want to wait for a full LLVM release to test it out. + +Each of these reasons has a different strategy for updating LLVM, and we'll go +over both in detail here. + +## Bugfix Updates + +For updates of LLVM that typically just update a bug, we cherry-pick the bugfix +to the branch we're already using. The steps for this are: + +1. Make sure the bugfix is in upstream LLVM. +2. Identify the branch that rustc is currently using. The `src/llvm` submodule + is always pinned to a branch of the + [rust-lang/llvm](https://github.com/rust-lang/llvm) repository. +3. Fork the rust-lang/llvm repository +4. Check out the appropriate branch (typically named `rust-llvm-release-*`) +5. Cherry-pick the upstream commit onto the branch +6. Push this branch to your fork +7. Send a Pull Request to rust-lang/llvm to the same branch as before +8. Wait for the PR to be merged +9. Send a PR to rust-lang/rust updating the `src/llvm` submodule with your bugfix +10. Wait for PR to be merged + +The tl;dr; is that we can cherry-pick bugfixes at any time and pull them back +into the rust-lang/llvm branch that we're using, and getting it into the +compiler is just updating the submodule via a PR! + +Example PRs look like: +[#56313](https://github.com/rust-lang/rust/pull/56313) + +## Feature updates + +> Note that this is all information as applies to the current day in age. This +> process for updating LLVM changes with practically all LLVM updates, so this +> may be out of date! + +Unlike bugfixes, updating to pick up a new feature of LLVM typically requires a +lot more work. This is where we can't reasonably cherry-pick commits backwards +so we need to do a full update. There's a lot of stuff to do here, so let's go +through each in detail. + +1. Create new branches in all repositories for this update. Branches should be + named `rust-llvm-release-X-Y-Z-vA` where `X.Y.Z` is the LLVM version and `A` + is just increasing based on if there's previous branches of this name. All + repositories here should be branched at the same time from the upstream LLVM + projects, we currently use https://github.com/llvm-mirror repositories. The + list of repositories that need a new branch are: + + * rust-lang/llvm + * rust-lang/compiler-rt + * rust-lang/lld + * rust-lang-nursery/lldb + * rust-lang-nursery/clang + +2. Apply Rust-specific patches to LLVM repositories. All features and bugfixes + are upstream, but there's often some weird build-related patches that don't + make sense to upstream which we have on our repositories. These patches are + typically the latest patches on the branch. All repositories, except `clang`, + currently have Rust-specific patches. + +3. Update the `compiler-rt` submodule in the + `rust-lang-nursery/compiler-builtins` repository. Push this update to a + `rust-llvm-release-*` branch of the `compiler-builtins` repository. + +4. Prepare a commit to rust-lang/rust + + * Update `src/llvm` + * Update `src/tools/lld` + * Update `src/tools/lldb` + * Update `src/tools/clang` + * Update `src/libcompiler_builtins + * Edit `src/rustllvm/llvm-rebuild-trigger` to update its contents + +5. Build your commit. Make sure you've committed the previous changes to ensure + submodule updates aren't reverted. Some commands you should execute are: + + * `./x.py build src/llvm` - test that LLVM still builds + * `./x.py build src/tools/lld` - same for LLD + * `./x.py build` - build the rest of rustc + + You'll likely need to update `src/rustllvm/*.cpp` to compile with updated + LLVM bindings. Note that you should use `#ifdef` and such to ensure that the + bindings still compile on older LLVM versions. + +6. Test for regressions across other platforms. LLVM often has at least one bug + for non-tier-1 architectures, so it's good to do some more testing before + sending this to bors! If you're low on resources you can send the PR as-is + now to bors, though, and it'll get tested anyway. + + Ideally, build LLVM and test it on a few platforms: + + * Linux + * OSX + * Windows + + and afterwards run some docker containers that CI also does: + + * `./src/ci/docker/run.sh wasm32-unknown` + * `./src/ci/docker/run.sh arm-android` + * `./src/ci/docker/run.sh dist-various-1` + * `./src/ci/docker/run.sh dist-various-2` + * `./src/ci/docker/run.sh armhf-gnu` + +7. Send a PR! Hopefully it's smooth sailing from here :). + +For prior art, previous LLVM updates look like +[#55835](https://github.com/rust-lang/rust/pull/55835) +[#47828](https://github.com/rust-lang/rust/pull/47828) + +### Caveats and gotchas + +Ideally the above instructions are pretty smooth, but here's some caveats to +keep in mind while going through them: + +* LLVM bugs are hard to find, don't hesitate to ask for help! Bisection is + definitely your friend here (yes LLVM takes forever to build, yet bisection is + still your friend) +* Updating LLDB has some Rust-specific patches currently that aren't upstream. + If you have difficulty @tromey can likely help out. +* If you've got general questions, @alexcrichton can help you out. +* Creating branches is a privileged operation on GitHub, so you'll need someone + with write access to create the branches for you most likely. From 7acbc48d17c9274934c6f5fdae7da203269a9b85 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 11 Dec 2018 14:46:35 -0600 Subject: [PATCH 0451/1812] a few updates --- src/borrow_check/region_inference.md | 32 ++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index d08e06a80..762a84477 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -48,26 +48,40 @@ The MIR-based region analysis consists of two major functions: ## Universal regions -The [`UnversalRegions`] type represents a collection of _unversal_ regions +The [`UnversalRegions`] type represents a collection of _universal_ regions corresponding to some MIR `DefId`. It is constructed in [`replace_regions_in_mir`] when we replace all regions with fresh inference variables. [`UniversalRegions`] contains indices for all the free regions in the given MIR along with any relationships that are _known_ to hold between them (e.g. implied bounds, where clauses, etc.). -TODO: is there more to write here? +For example, given the MIR for the following function: + +```rust +fn foo<'a>(x: &'a u32) { + // ... +} +``` + +we would create a universal region for `'a` and one for `'static`. There may +also be some complications for handling closures, but we will ignore those for +the moment. + +TODO: write about _how_ these regions are computed. [`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/universal_regions/struct.UniversalRegions.html ## Region variables -The value of a region can be thought of as a **set** of points in the MIR where -the region is valid; we call the domain of this set a `RegionElement`. In the -code, the value for all regions is maintained in -[the `rustc_mir::borrow_check::nll::region_infer` module][ri]. For -each region we maintain a set storing what elements are present in its -value (to make this efficient, we give each kind of element an index, -the `RegionElementIndex`, and use sparse bitsets). +The value of a region can be thought of as a **set**. This set contains all +points in the MIR where the region is valid along with any regions that are +outlived by this region (e.g. if `'a: 'b`, then `end('b)` is in the set for +`'a`); we call the domain of this set a `RegionElement`. In the code, the value +for all regions is maintained in [the +`rustc_mir::borrow_check::nll::region_infer` module][ri]. For each region we +maintain a set storing what elements are present in its value (to make this +efficient, we give each kind of element an index, the `RegionElementIndex`, and +use sparse bitsets). [ri]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check/nll/region_infer/ From a69982d7f5b74d743158f5170e27e60811cde6cc Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 11 Dec 2018 15:22:17 -0600 Subject: [PATCH 0452/1812] added example, reworked inference section --- src/borrow_check/region_inference.md | 125 ++++++++++++++++++++------- 1 file changed, 93 insertions(+), 32 deletions(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 762a84477..7fe50b870 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -120,45 +120,115 @@ So how do we compute the contents of a region? This process is called _region inference_. The high-level idea is pretty simple, but there are some details we need to take care of. +Here is the high-level idea: we start off each region with the MIR locations we +know must be in it from the liveness constraints. From there, we use all of the +outlives constraints computed from the type checker to _propagate_ the +constraints: for each region `'a`, if `'a: 'b`, then we add all elements of +`'b` to `'a`, including `end('b)`. This all happens in +[`propagate_constraints`]. + +Then, we will check for errors. We first check that type tests are satisfied by +calling [`check_type_tests`]. This checks constraints like `T: 'a`. Second, we +check that universal regions are not "too big". This is done by calling +[`check_universal_regions`]. This checks that for each region `'a` if `'a` +contains the element `end('b)`, then we must already know that `'a: 'b` holds +(e.g. from a where clause). If we don't already know this, that is an error... +well, almost. There is some special handling for closures that we will discuss +later. + +### Example + +Consider the following example: + +```rust,ignore +fn foo<'a, 'b>(x: &'a usize) -> &'b usize { + x +} +``` + +Clearly, this should not compile because we don't know if `'a` outlives `'b` +(if it doesn't then the return value could be a dangling reference). + +Let's back up a bit. We need to introduce some free inference variables (as is +done in [`replace_regions_in_mir`]). This example doesn't use the exact regions +produced, but it (hopefully) is enough to get the idea across. + +```rust,ignore +fn foo<'a, 'b>(x: &'a /* '#1 */ usize) -> &'b /* '#3 */ usize { + x // '#2, location L1 +} +``` + +Some notation: `'#1`, `'#3`, and `'#2` represent the universal regions for the +argument, return value, and the expression `x`, respectively. Additionally, I +will call the location of the expression `x` `L1`. + +So now we can use the liveness constraints to get the following starting points: + +Region | Contents +--------|---------- +'#1 | +'#2 | `L1` +'#3 | `L1` + +Now we use the outlives constraints to expand each region. Specifically, we +know that `'#2: '#3` ... + +Region | Contents +--------|---------- +'#1 | `L1` +'#2 | `L1, end('#3) // add contents of '#3 and end('#3)` +'#3 | `L1` + +... and `'#1: '#2`, so ... + +Region | Contents +--------|---------- +'#1 | `L1, end('#2), end('#3) // add contents of '#2 and end('#2)` +'#2 | `L1, end('#3)` +'#3 | `L1` + +Now, we need to check that no regions were too big (we don't have any type +tests to check in this case). Notice that `'#1` now contains `end('#3)`, but +we have no `where` clause or implied bound to say that `'a: 'b`... that's an +error! + +### Some details + The [`RegionInferenceContext`] type contains all of the information needed to -do inference, including the universal regions from `replace_regions_in_mir` and +do inference, including the universal regions from [`replace_regions_in_mir`] and the constraints computed for each region. It is constructed just after we compute the liveness constraints. Here are some of the fields of the struct: -- `constraints`: contains all the outlives constraints. -- `liveness_constraints`: contains all the liveness constraints. -- `universal_regions`: contains the `UniversalRegions` returned by - `replace_regions_in_mir`. -- `universal_region_relations`: contains relations known to be true about +- [`constraints`]: contains all the outlives constraints. +- [`liveness_constraints`]: contains all the liveness constraints. +- [`universal_regions`]: contains the `UniversalRegions` returned by + [`replace_regions_in_mir`]. +- [`universal_region_relations`]: contains relations known to be true about universal regions. For example, if we have a where clause that `'a: 'b`, that relation is assumed to be true while borrow checking the implementation (it is checked at the caller), so `universal_region_relations` would contain `'a: 'b`. -- `type_tests`: contains some constraints on types that we must check after +- [`type_tests`]: contains some constraints on types that we must check after inference (e.g. `T: 'a`). -- `closure_bounds_mapping`: used for propagating region constraints from +- [`closure_bounds_mapping`]: used for propagating region constraints from closures back out to the creater of the closure. +[`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.constraints +[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints +[`universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.universal_regions +[`universal_region_relations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.universal_region_relations +[`type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.type_tests +[`closure_bounds_mapping`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.closure_bounds_mapping + TODO: should we discuss any of the others fields? What about the SCCs? Ok, now that we have constructed a `RegionInferenceContext`, we can do -inference. This is done by calling the [`solve`] method on the context. - -We will start off the value of each region with the liveness constraints (the -places we already know must be in the region). We will then use the outlives -constraints to widen each region until all constraints are met. This is done in -[`propagate_constraints`]. For each region, if `'a: 'b`, we add all elements of -`'b` to `'a`. - -Then, we will check for errors. We first check that type tests are satisfied by -calling [`check_type_tests`]. This checks constraints like `T: 'a`. Second, we -check that universal regions are not "too big". This is done by calling -[`check_universal_regions`]. This checks that for each region `'a` if `'a` -contains the element `end('b)`, then we must already know that `'a: 'b` holds -(e.g. from a where clause). If we don't already know this, that is an error... -well, almost. +inference. This is done by calling the [`solve`] method on the context. This +is where we call [`propagate_constraints`] and then check the resulting type +tests and universal regions, as discussed above. [`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints [`check_type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_type_tests @@ -174,15 +244,6 @@ and return them. Later, when we are borrow check the MIR node that created the closure, we can also check that these constraints hold. At that time, if we can't prove they hold, we report an error. -## Causal tracking - -*to be written* – describe how we can extend the values of a variable - with causal tracking etc - -TODO: is this what I described above or something else? - - - ## Placeholders and universes (This section describes ongoing work that hasn't landed yet.) From 2dfa301deb5fe48a2afc2c2c9dc4218cd91b37a7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 11 Dec 2018 15:25:03 -0600 Subject: [PATCH 0453/1812] update a couple of links --- src/compiler-team.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index a6328198c..728325687 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -1,11 +1,11 @@ # About the compiler team -rustc is maintained by the -[Rust compiler team](https://www.rust-lang.org/en-US/team.html). The -people who belong to this team collectively work to track regressions -and implement new features. Members of the Rust compiler team are -people who have made significant contributions to rustc and its -design. +rustc is maintained by the [Rust compiler team][team]. The people who belong to +this team collectively work to track regressions and implement new features. +Members of the Rust compiler team are people who have made significant +contributions to rustc and its design. + +[team]: https://www.rust-lang.org/governance/teams/language-and-compiler ## Discussion @@ -89,7 +89,7 @@ The guidelines for reviewers are as follows: Rust project, so it is expected that you will go above and beyond when it comes to the [Code of Conduct]. -[Code of Conduct]: https://www.rust-lang.org/en-US/conduct.html +[Code of Conduct]: https://www.rust-lang.org/policies/code-of-conduct ### high-five From 81b0c84f416930ded5c4817240a779e789964982 Mon Sep 17 00:00:00 2001 From: Dan Robertson Date: Wed, 12 Dec 2018 02:08:40 +0000 Subject: [PATCH 0454/1812] Fix link to rustc_mir::hair::cx::expr --- src/mir/construction.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 03e220cb4..f0e3cf76a 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -24,9 +24,8 @@ being a `hair::ExprKind::Neg(hair::Expr)` it is a `hair::ExprKind::Neg(hir::Expr This shallowness enables the `HAIR` to represent all datatypes that [HIR] has, but without having to create an in-memory copy of the entire [HIR]. [MIR] lowering will first convert the topmost expression from -[HIR] to [HAIR] (in -[https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/cx/expr/index.html]) -and then process the [HAIR] expressions recursively. +[HIR] to [HAIR] (in [rustc_mir::hair::cx::expr]) and then process +the [HAIR] expressions recursively. The lowering creates local variables for every argument as specified in the signature. Next it creates local variables for every binding specified (e.g. `(a, b): (i32, String)`) @@ -147,4 +146,6 @@ case of `enum`s. [MIR]: ./index.html [HIR]: ../hir.html [HAIR]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/index.html + +[rustc_mir::hair::cx::expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/cx/expr/index.html [`mir_built`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.mir_built.html From aee77489fed126f2b4317a79c037c8c52f8a98c4 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Fri, 14 Dec 2018 16:58:19 +0100 Subject: [PATCH 0455/1812] Add graphs that I forgot to push in the original PR --- src/mir/construction.md | 7 + src/mir/mir_detailed.dot | 27 ++++ src/mir/mir_detailed.svg | 300 +++++++++++++++++++++++++++++++++++++++ src/mir/mir_overview.dot | 10 ++ src/mir/mir_overview.svg | 103 ++++++++++++++ 5 files changed, 447 insertions(+) create mode 100644 src/mir/mir_detailed.dot create mode 100644 src/mir/mir_detailed.svg create mode 100644 src/mir/mir_overview.dot create mode 100644 src/mir/mir_overview.svg diff --git a/src/mir/construction.md b/src/mir/construction.md index f0e3cf76a..0e0bf35e7 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -92,6 +92,13 @@ There are essentially four kinds of representations one might want of an express * `Operand` is an argument to e.g. a `+` operation or a function call * a temporary variable containing a copy of the value +These following image depicts a general overview of the interactions between the +representations: + + + +[Click here for a more detailed view](mir_detailed.svg) + We start out with lowering the function body to an `Rvalue` so we can create an assignment to `RETURN_PLACE`, This `Rvalue` lowering will in turn trigger lowering to `Operand` for its arguments (if any). `Operand` lowering either produces a `const` diff --git a/src/mir/mir_detailed.dot b/src/mir/mir_detailed.dot new file mode 100644 index 000000000..1494f4f0b --- /dev/null +++ b/src/mir/mir_detailed.dot @@ -0,0 +1,27 @@ +digraph G { + Operand -> Constant + Operand -> Place [taillabel="read"] + Place -> Projection + Projection -> Place + Place -> LocalId + Rvalue -> "Rvalue\nAggregate" + Rvalue -> "Rvalue\nBinaryOp" + Rvalue -> "Rvalue\nUnaryOp" + Rvalue -> "Rvalue\n..." + "Rvalue\nAggregate" -> Operand [headlabel="*"] + "Rvalue\nBinaryOp" -> Operand [headlabel="2"] + "Rvalue\nUnaryOp" -> Operand + "Statement\nAssignment" -> Place [taillabel="write"] + "Statement\nAssignment" -> Rvalue + Statement -> "Statement\nAssignment" + Statement -> "Statement\n..." + Block -> Statement [headlabel="*"] + Block -> Terminator + Terminator -> "Terminator\nSwitchInt" + "Terminator\nSwitchInt" -> Operand + "Terminator\nSwitchInt" -> Constant [headlabel="*"] + "Terminator\nSwitchInt" -> BlockId [headlabel="*"] + Terminator -> "Terminator\n..." + Mir -> Block [headlabel="*"] + Mir -> Local [headlabel="*"] +} \ No newline at end of file diff --git a/src/mir/mir_detailed.svg b/src/mir/mir_detailed.svg new file mode 100644 index 000000000..771e9e5dc --- /dev/null +++ b/src/mir/mir_detailed.svg @@ -0,0 +1,300 @@ + + + + + + +G + + + +Operand + +Operand + + + +Constant + +Constant + + + +Operand->Constant + + + + + +Place + +Place + + + +Operand->Place + + +read + + + +Projection + +Projection + + + +Place->Projection + + + + + +LocalId + +LocalId + + + +Place->LocalId + + + + + +Projection->Place + + + + + +Rvalue + +Rvalue + + + +Rvalue\nAggregate + +Rvalue +Aggregate + + + +Rvalue->Rvalue\nAggregate + + + + + +Rvalue\nBinaryOp + +Rvalue +BinaryOp + + + +Rvalue->Rvalue\nBinaryOp + + + + + +Rvalue\nUnaryOp + +Rvalue +UnaryOp + + + +Rvalue->Rvalue\nUnaryOp + + + + + +Rvalue\n... + +Rvalue +... + + + +Rvalue->Rvalue\n... + + + + + +Rvalue\nAggregate->Operand + + +* + + + +Rvalue\nBinaryOp->Operand + + +2 + + + +Rvalue\nUnaryOp->Operand + + + + + +Statement\nAssignment + +Statement +Assignment + + + +Statement\nAssignment->Place + + +write + + + +Statement\nAssignment->Rvalue + + + + + +Statement + +Statement + + + +Statement->Statement\nAssignment + + + + + +Statement\n... + +Statement +... + + + +Statement->Statement\n... + + + + + +Block + +Block + + + +Block->Statement + + +* + + + +Terminator + +Terminator + + + +Block->Terminator + + + + + +Terminator\nSwitchInt + +Terminator +SwitchInt + + + +Terminator->Terminator\nSwitchInt + + + + + +Terminator\n... + +Terminator +... + + + +Terminator->Terminator\n... + + + + + +Terminator\nSwitchInt->Operand + + + + + +Terminator\nSwitchInt->Constant + + +* + + + +BlockId + +BlockId + + + +Terminator\nSwitchInt->BlockId + + +* + + + +Mir + +Mir + + + +Mir->Block + + +* + + + +Local + +Local + + + +Mir->Local + + +* + + + diff --git a/src/mir/mir_overview.dot b/src/mir/mir_overview.dot new file mode 100644 index 000000000..c0b51674d --- /dev/null +++ b/src/mir/mir_overview.dot @@ -0,0 +1,10 @@ +digraph G { + Operand -> Constant + Operand -> Place + Place -> Projection + Projection -> Place + Place -> Local + Rvalue -> Operand + Assignment -> Place + Assignment -> Operand +} \ No newline at end of file diff --git a/src/mir/mir_overview.svg b/src/mir/mir_overview.svg new file mode 100644 index 000000000..b8f092cd2 --- /dev/null +++ b/src/mir/mir_overview.svg @@ -0,0 +1,103 @@ + + + + + + +G + + + +Operand + +Operand + + + +Constant + +Constant + + + +Operand->Constant + + + + + +Place + +Place + + + +Operand->Place + + + + + +Projection + +Projection + + + +Place->Projection + + + + + +Local + +Local + + + +Place->Local + + + + + +Projection->Place + + + + + +Rvalue + +Rvalue + + + +Rvalue->Operand + + + + + +Assignment + +Assignment + + + +Assignment->Operand + + + + + +Assignment->Place + + + + + From 28f67849e16323a80b3f8efd3f8963179db85f04 Mon Sep 17 00:00:00 2001 From: Roberto Vidal Date: Fri, 14 Dec 2018 10:11:27 +0100 Subject: [PATCH 0456/1812] Fixes broken links --- src/diag.md | 2 +- src/hir.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/diag.md b/src/diag.md index 00bb23b4c..9a8020314 100644 --- a/src/diag.md +++ b/src/diag.md @@ -305,4 +305,4 @@ are defining a new lint, you will want to add an entry to this enum. Then, add an appropriate mapping to the body of [`Lint::from_parser_lint_id`][fplid]. [`BufferedEarlyLintId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/early_buffered_lints/enum.BufferedEarlyLintId.html -[fplid]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.Lint.html#from_parser_lint_id +[fplid]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.Lint.html#method.from_parser_lint_id diff --git a/src/hir.md b/src/hir.md index e6bca7f37..34e478ee4 100644 --- a/src/hir.md +++ b/src/hir.md @@ -105,12 +105,12 @@ sorts of identifiers in active use: ### The HIR Map Most of the time when you are working with the HIR, you will do so via -the **HIR Map**, accessible in the tcx via [`tcx.hir`] (and defined in +the **HIR Map**, accessible in the tcx via [`tcx.hir_map`] (and defined in the [`hir::map`] module). The [HIR map] contains a [number of methods] to convert between IDs of various kinds and to lookup data associated with an HIR node. -[`tcx.hir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.GlobalCtxt.html#structfield.hir +[`tcx.hir_map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.GlobalCtxt.html#structfield.hir_map [`hir::map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/index.html [HIR map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html [number of methods]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#methods From 451f00936a3319ffd94b03cc811d1a4521c507b7 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 23 Dec 2018 10:11:26 -0600 Subject: [PATCH 0457/1812] Fix link --- src/appendix/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index e1bde6863..546e9f9b7 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -23,7 +23,7 @@ Item | Kind | Short description | Chapter | `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html) -`syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) +`syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/enum.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) From b85fc377539931211544d905da6d454c7f921155 Mon Sep 17 00:00:00 2001 From: ednix Date: Sat, 22 Dec 2018 23:49:31 +0530 Subject: [PATCH 0458/1812] Clarify line about RLS being unable to handle rustc I based this clarification on this [answer](https://www.reddit.com/r/rust/comments/a8mk33/question_about_a_line_from_the_rust_compiler_book/ecbx1ma/) to my question on Reddit. --- src/how-to-build-and-run.md | 30 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 89ad47199..cc1a5f9c0 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -45,10 +45,10 @@ debuginfo-lines = true ### What is x.py? -x.py is the script used to orchestrate the tooling in the rustc repository. -It is the script that can build docs, run tests, and compile rustc. -It is the now preferred way to build rustc and it replaces the old makefiles -from before. Below are the different ways to utilize x.py in order to +x.py is the script used to orchestrate the tooling in the rustc repository. +It is the script that can build docs, run tests, and compile rustc. +It is the now preferred way to build rustc and it replaces the old makefiles +from before. Below are the different ways to utilize x.py in order to effectively deal with the repo for various common tasks. ### Running x.py and building a stage1 compiler @@ -86,8 +86,8 @@ compiling `rustc` is done in stages: #### Build Flags -There are other flags you can pass to the build portion of x.py that can be -beneficial to cutting down compile times or fitting other things you might +There are other flags you can pass to the build portion of x.py that can be +beneficial to cutting down compile times or fitting other things you might need to change. They are: ```bash @@ -180,9 +180,9 @@ build`) has quite a few more steps: > ./x.py build src/libcore --stage 1 ``` -Sometimes you might just want to test if the part you’re working on can -compile. Using these commands you can test that it compiles before doing -a bigger build to make sure it works with the compiler. As shown before +Sometimes you might just want to test if the part you’re working on can +compile. Using these commands you can test that it compiles before doing +a bigger build to make sure it works with the compiler. As shown before you can also pass flags at the end such as --stage. @@ -260,7 +260,7 @@ The sequence of commands you want is as follows: stage1 compiler - Subsequent builds: `./x.py build -i --stage 1 src/libstd --keep-stage 1` - Note that we added the `--keep-stage 1` flag here - + The effect of `--keep-stage 1` is that we just *assume* that the old standard library can be re-used. If you are editing the compiler, this is almost always true: you haven't changed the standard library, after @@ -300,9 +300,7 @@ in other sections: ### ctags -One of the challenges with rustc is that the RLS can't handle it, making code -navigation difficult. One solution is to use `ctags`. The following script can -be used to set it up: [https://github.com/nikomatsakis/rust-etags][etags]. +One of the challenges with rustc is that the RLS can't handle it, making code navigation difficult. One solution is to use ctags. The following script can be used to set it up: https://github.com/nikomatsakis/rust-etags. CTAGS integrates into emacs and vim quite easily. The following can then be used to build and generate tags: @@ -318,9 +316,9 @@ you last built, which is ridiculously useful. ### Cleaning out build directories -Sometimes you need to start fresh, but this is normally not the case. -If you need to run this then rustbuild is most likely not acting right and -you should file a bug as to what is going wrong. If you do need to clean +Sometimes you need to start fresh, but this is normally not the case. +If you need to run this then rustbuild is most likely not acting right and +you should file a bug as to what is going wrong. If you do need to clean everything up then you only need to run one command! ```bash From 1b760946bd734a2f623b6d3661fe508d965a7e87 Mon Sep 17 00:00:00 2001 From: ednix Date: Sat, 22 Dec 2018 23:54:05 +0530 Subject: [PATCH 0459/1812] Do what the last commit said it did --- src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index cc1a5f9c0..077ea39f9 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -300,7 +300,7 @@ in other sections: ### ctags -One of the challenges with rustc is that the RLS can't handle it, making code navigation difficult. One solution is to use ctags. The following script can be used to set it up: https://github.com/nikomatsakis/rust-etags. +One of the challenges with rustc is that the RLS can't handle it, since it's a bootstrapping compiler. This makes code navigation difficult. One solution is to use ctags. The following script can be used to set it up: https://github.com/nikomatsakis/rust-etags. CTAGS integrates into emacs and vim quite easily. The following can then be used to build and generate tags: From 5daaa543311e6b4993abdf9ae71ed290962c2a12 Mon Sep 17 00:00:00 2001 From: ednix Date: Sun, 23 Dec 2018 13:18:56 +0530 Subject: [PATCH 0460/1812] Fix formatting, follow 100 char line length limit No idea why the Markdown stuff got dropped last time. Hopefully everything is fine now. --- src/how-to-build-and-run.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 077ea39f9..241852b19 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -300,7 +300,9 @@ in other sections: ### ctags -One of the challenges with rustc is that the RLS can't handle it, since it's a bootstrapping compiler. This makes code navigation difficult. One solution is to use ctags. The following script can be used to set it up: https://github.com/nikomatsakis/rust-etags. +One of the challenges with rustc is that the RLS can't handle it, since it's a bootstrapping +compiler. This makes code navigation difficult. One solution is to use `ctags`. The following +script can be used to set it up: [https://github.com/nikomatsakis/rust-etags][etags]. CTAGS integrates into emacs and vim quite easily. The following can then be used to build and generate tags: From 615cf17b6ffdeec711b09bef523e6dc99140c1ed Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 1 Jan 2019 11:26:10 +0100 Subject: [PATCH 0461/1812] Add IRLO to glossary Someone was asking on Discord what it stands for. It's sometimes used in GitHub issues, Twitter and other places. --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 82d6f9a21..0e697aeea 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -33,6 +33,7 @@ ICH | incremental compilation hash. ICHs are used as finger inference variable | when doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. infcx | the inference context (see `librustc/infer`) IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. +IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). local crate | the crate currently being compiled. LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. From 134d2ba510c33da75033baa634279305dd297c40 Mon Sep 17 00:00:00 2001 From: Igor Matuszewski Date: Fri, 4 Jan 2019 15:23:15 +0100 Subject: [PATCH 0462/1812] Mention old incr. comp. design doc --- src/incremental-compilation.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/incremental-compilation.md b/src/incremental-compilation.md index 0a25e1664..bed21f115 100644 --- a/src/incremental-compilation.md +++ b/src/incremental-compilation.md @@ -136,6 +136,9 @@ algorithm like so: - We can then compare the hash of the result and color Q as green if it did not change. +## Resources +The initial design document can be found at https://github.com/nikomatsakis/rustc-on-demand-incremental-design-doc/blob/master/0000-rustc-on-demand-and-incremental.md, which expands on the memoization details, provides more high-level overview and motivation for this system. + # Footnotes [^salsa]: I have long wanted to rename it to the Salsa algorithm, but it never caught on. -@nikomatsakis From 1590387f778eb58e5969f88134833442e9a7ea92 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Tue, 15 Jan 2019 17:07:06 -0500 Subject: [PATCH 0463/1812] issue_130_stabilization_guide --- src/SUMMARY.md | 1 + src/stabilization_guide.md | 181 +++++++++++++++++++++++++++++++++++++ 2 files changed, 182 insertions(+) create mode 100644 src/stabilization_guide.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index bfb112ce6..9bdf89278 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -6,6 +6,7 @@ - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) - [Documenting Compiler](./compiler-documenting.md) - [Coding conventions](./conventions.md) +- [Stabilizing Features](./stabilization_guide.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md new file mode 100644 index 000000000..af86b450e --- /dev/null +++ b/src/stabilization_guide.md @@ -0,0 +1,181 @@ + +# Request for stabilization + + Once an unstable feature has been well-tested with no outstanding + concern, anyone may push for its stabilization. It involves the + following steps. + + - Documentation PRs + - Write a stabilization report + - FCP + - Stabilization PR + +## Documentation PRs + + Prepare PRs to update documentations involing this new feature. + You need to submit PRs for repositories The Reference, The Book + and Rust by Example. + Maintainers of these repositories will keep these PRs open until + the whole stabilization process has completed. Meanwhile, we can + proceed to the next step. + +## Write a stabilization report + + Find the tracking issue of the feature, and create a short + stabilization report. Essentially this would be a brief summary + of the feature plus some links to test cases showing it works + as expected, along with a list of edge cases that came up and + and were considered. This is a minimal "due diligence" that + we do before stabilizing. + + The report should contain: + + - A summary, showing examples (e.g. code snippets) what is + enabled by this feature. + - Links to test cases in our test suite regarding this feature + and describe the feature's behavior on encountering edge cases. + - Links to the documentations (the PRs we have made in the + previous steps). + - Any other relevant information(Examples of such reports can + be found in rust-lang/rust#44494 and rust-lang/rust#28237). + +## FCP + +If any member of the team responsible for tracking this +feature agrees with stabilizing this feature, they will +start the FCP (final-comment-period) process by +commenting + + ```bash + @rfcbot fcp merge + ``` + +The rest of the team members will review the proposal. If the final +decision is to stabilize, we proceed to do the actual code modification. + +## Stabilization PR + +Once we have decided to stabilize a feature, we need to have a PR that +actually makes that stabilization happen. These kinds of PRs are a +great way to get involved in Rust, as they take you on a little tour +through the source code. + +Here is a general guide to how to stabilize a feature -- every feature +is different, of course, so some features may require steps beyond +what this guide talks about. + +Note: Before we stabilize any feature, it is rule that it should appear +in the documentation. + +### Updating the feature-gate listing + +There is a central listing of feature-gates in +`src/libsyntax/feature_gate.rs`. Search for the `declare_features!` +macro. There should be an entry for the feature you are aiming to +stabilize, something like (this example is taken from +[rust-lang/rust#32409]: + + ``` + // pub(restricted) visibilities (RFC 1422) + (active, pub_restricted, "1.9.0", Some(32409)), + ``` +The above line should be moved down to the area for "accepted" +features, declared below in a separate call to `declare_features!`. +When it is done, it should look like: + + ``` + // pub(restricted) visibilities (RFC 1422) + (accepted, pub_restricted, "1.31.0", Some(32409)), + // ^^^^^^ note that we changed this + ``` + +Note that, the version number is updated to be the version number +of the stable release where this feature will appear. This can be +found by consulting https://forge.rust-lang.org/, which will guide +you the next stable release number. You want to add 1 to that, +because the code that lands today will become go into beta on that +date, and then become stable after that. So, at the time of this +writing, the next stable release (what is currently beta, iow) was +1.30.0, hence I wrote 1.31.0 above. + +### Removing existing uses of the feature-gate + +Next search for the feature string (in this case, pub_restricted) +in the codebase to find where it appears. Change uses of +`#![feature(XXX)]` from the stdlib and rustc crates to be +`#![cfg_attr(stage0, feature(XXX))]`. This includes the feature-gate +only for stage0, which is built using the current beta (this is +needed because the feature is still unstable in the current beta). + +Also, remove those strings from any tests. If there are tests +specifically targeting the feature-gate (i.e., testing that the +feature-gate is required to use the feature, but nothing else), +simply remove the test. + +### Do not require the feature-gate to use the feature + +Most importantly, remove the code which flags an error if the +feature-gate is not present (since the feature is now considered +stable). If the feature can be detected because it employs some +new syntax, then a common place for that code to be is in the +same `feature_gate.rs`. For example, you might see code like this: + + ``` + gate_feature_post!(&self, pub_restricted, span, + "`pub(restricted)` syntax is experimental"); + ``` + +This `gate_feature_post!` macro prints an error if the +`pub_restricted` feature is not enabled. It is not needed +now that `#[pub_restricted]` is stable. + +For more subtle features, you may find code like this: + + ``` + if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ } + ``` + +This `pub_restricted` field (obviously named after the feature) +would ordinarily be false if the feature flag is not present +and true if it is. So transform the code to assume that the field +is true. In this case, that would mean removing the `if` and +leaving just the `/* XXX */`. + + ``` + if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ } + = becomes ==> + /* XXX */ + + if self.tcx.sess.features.borrow().pub_restricted && something { /* XXX */ } + = becomes ==> + if something { /* XXX */ } + ``` + +## Updating documentation + +If any documentation for this feature exists, it should be +in the `Unstable Book`, located at `src/doc/unstable-book`. +Regardless of its existence, the page for the feature gate +should be removed. + +If there was documentation there, integrating it into the +existing documentation is needed. + +If there wasn't documentation there, it needs to be added. + +Places that may need updated documentation: + + [The Reference]: this must be updated, in full detail. + [The Book]: this may or may not need updating, depending. + If you're not sure, please open an issue on this repository + and it can be discussed. + standard library documentation: as needed. Language features + often don't need this, but if it's a feature that changes + how good examples are written, such as when `?` was added + to the language, updating examples is important. + [Rust by Example]: as needed. + +[rust-lang/rust#32409]:https://github.com/rust-lang/rust/issues/32409 +[The Reference]: https://github.com/rust-lang-nursery/reference +[The Book]: https://github.com/rust-lang/book +[Rust by Example]: https://github.com/rust-lang/rust-by-example \ No newline at end of file From afc027f7c574f4f8ec403cfa532f38af1fd59579 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:00:36 -0500 Subject: [PATCH 0464/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index af86b450e..db8b5c3f4 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -64,7 +64,7 @@ Here is a general guide to how to stabilize a feature -- every feature is different, of course, so some features may require steps beyond what this guide talks about. -Note: Before we stabilize any feature, it is rule that it should appear +Note: Before we stabilize any feature, it's the rule that it should appear in the documentation. ### Updating the feature-gate listing @@ -178,4 +178,4 @@ Places that may need updated documentation: [rust-lang/rust#32409]:https://github.com/rust-lang/rust/issues/32409 [The Reference]: https://github.com/rust-lang-nursery/reference [The Book]: https://github.com/rust-lang/book -[Rust by Example]: https://github.com/rust-lang/rust-by-example \ No newline at end of file +[Rust by Example]: https://github.com/rust-lang/rust-by-example From dd43338012e2ad8cc872fdd8757737c1e75b6747 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:02:20 -0500 Subject: [PATCH 0465/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index db8b5c3f4..22ec49f8a 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -91,7 +91,7 @@ When it is done, it should look like: Note that, the version number is updated to be the version number of the stable release where this feature will appear. This can be -found by consulting https://forge.rust-lang.org/, which will guide +found by consulting [the forge](https://forge.rust-lang.org/), which will guide you the next stable release number. You want to add 1 to that, because the code that lands today will become go into beta on that date, and then become stable after that. So, at the time of this From ea37742d2c670257efbe525338098ac9f641e3cc Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:02:36 -0500 Subject: [PATCH 0466/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 22ec49f8a..3af4aff73 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -147,7 +147,9 @@ leaving just the `/* XXX */`. /* XXX */ if self.tcx.sess.features.borrow().pub_restricted && something { /* XXX */ } - = becomes ==> + ``` +becomes +```rust if something { /* XXX */ } ``` From 8823da540fb2e953140c07e4eaae7c73486c5282 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:02:51 -0500 Subject: [PATCH 0467/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 3af4aff73..d21fbb174 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -157,7 +157,7 @@ becomes If any documentation for this feature exists, it should be in the `Unstable Book`, located at `src/doc/unstable-book`. -Regardless of its existence, the page for the feature gate +If it exists, the page for the feature gate should be removed. If there was documentation there, integrating it into the From 0f82f1c5a175b2229a4da57dad2d2395c58ab421 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:03:13 -0500 Subject: [PATCH 0468/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index d21fbb174..a245d170b 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -100,7 +100,7 @@ writing, the next stable release (what is currently beta, iow) was ### Removing existing uses of the feature-gate -Next search for the feature string (in this case, pub_restricted) +Next search for the feature string (in this case, `pub_restricted`) in the codebase to find where it appears. Change uses of `#![feature(XXX)]` from the stdlib and rustc crates to be `#![cfg_attr(stage0, feature(XXX))]`. This includes the feature-gate From e680f28d059b8e3ca0a5404de3dcbd55735aacf1 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 15 Jan 2019 21:10:56 -0500 Subject: [PATCH 0469/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index a245d170b..d73e96d8c 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -143,7 +143,9 @@ leaving just the `/* XXX */`. ``` if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ } - = becomes ==> + ``` +becomes +```rust /* XXX */ if self.tcx.sess.features.borrow().pub_restricted && something { /* XXX */ } From ca9e6be0c6563131fbbfdd7ddb2ef07fff7dc2e4 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Tue, 15 Jan 2019 22:22:36 -0500 Subject: [PATCH 0470/1812] issue_180 incorporated the review comments --- src/stabilization_guide.md | 157 +++++++++++++++++-------------------- 1 file changed, 74 insertions(+), 83 deletions(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index d73e96d8c..2974f6314 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -1,43 +1,61 @@ - # Request for stabilization - Once an unstable feature has been well-tested with no outstanding - concern, anyone may push for its stabilization. It involves the - following steps. +Once an unstable feature has been well-tested with no outstanding +concern, anyone may push for its stabilization. It involves the +following steps. - - Documentation PRs - - Write a stabilization report - - FCP - - Stabilization PR +- Documentation PRs +- Write a stabilization report +- FCP +- Stabilization PR ## Documentation PRs - Prepare PRs to update documentations involing this new feature. - You need to submit PRs for repositories The Reference, The Book - and Rust by Example. - Maintainers of these repositories will keep these PRs open until - the whole stabilization process has completed. Meanwhile, we can - proceed to the next step. +If any documentation for this feature exists, it should be +in the `Unstable Book`, located at `src/doc/unstable-book`. +If it exists, the page for the feature gate should be removed. + +If there was documentation there, integrating it into the +existing documentation is needed. + +If there wasn't documentation there, it needs to be added. + +Places that may need updated documentation: + + [The Reference]: This must be updated, in full detail. + [The Book]: This may or may not need updating, depends. + If you're not sure, please open an issue on this repository + and it can be discussed. + standard library documentation: As needed. Language features + often don't need this, but if it's a feature that changes + how good examples are written, such as when `?` was added + to the language, updating examples is important. + [Rust by Example]: As needed. + +Prepare PRs to update documentations invovling this new feature +for repositories mentioned above.Maintainers of these repositories +will keep these PRs open until the whole stabilization process +has completed. Meanwhile, we can proceed to the next step. ## Write a stabilization report - Find the tracking issue of the feature, and create a short - stabilization report. Essentially this would be a brief summary - of the feature plus some links to test cases showing it works - as expected, along with a list of edge cases that came up and - and were considered. This is a minimal "due diligence" that - we do before stabilizing. +Find the tracking issue of the feature, and create a short +stabilization report. Essentially this would be a brief summary +of the feature plus some links to test cases showing it works +as expected, along with a list of edge cases that came up and +and were considered. This is a minimal "due diligence" that +we do before stabilizing. - The report should contain: +The report should contain: - - A summary, showing examples (e.g. code snippets) what is - enabled by this feature. - - Links to test cases in our test suite regarding this feature - and describe the feature's behavior on encountering edge cases. - - Links to the documentations (the PRs we have made in the - previous steps). - - Any other relevant information(Examples of such reports can - be found in rust-lang/rust#44494 and rust-lang/rust#28237). +- A summary, showing examples (e.g. code snippets) what is + enabled by this feature. +- Links to test cases in our test suite regarding this feature + and describe the feature's behavior on encountering edge cases. +- Links to the documentations (the PRs we have made in the + previous steps). +- Any other relevant information(Examples of such reports can + be found in rust-lang/rust#44494 and rust-lang/rust#28237). ## FCP @@ -46,9 +64,9 @@ feature agrees with stabilizing this feature, they will start the FCP (final-comment-period) process by commenting - ```bash - @rfcbot fcp merge - ``` +```bash +@rfcbot fcp merge +``` The rest of the team members will review the proposal. If the final decision is to stabilize, we proceed to do the actual code modification. @@ -75,19 +93,20 @@ macro. There should be an entry for the feature you are aiming to stabilize, something like (this example is taken from [rust-lang/rust#32409]: - ``` - // pub(restricted) visibilities (RFC 1422) - (active, pub_restricted, "1.9.0", Some(32409)), - ``` +```rust,ignore +// pub(restricted) visibilities (RFC 1422) +(active, pub_restricted, "1.9.0", Some(32409)), +``` + The above line should be moved down to the area for "accepted" features, declared below in a separate call to `declare_features!`. When it is done, it should look like: - ``` - // pub(restricted) visibilities (RFC 1422) - (accepted, pub_restricted, "1.31.0", Some(32409)), - // ^^^^^^ note that we changed this - ``` +```rust,ignore +// pub(restricted) visibilities (RFC 1422) +(accepted, pub_restricted, "1.31.0", Some(32409)), +// note that we changed this +``` Note that, the version number is updated to be the version number of the stable release where this feature will appear. This can be @@ -120,10 +139,10 @@ stable). If the feature can be detected because it employs some new syntax, then a common place for that code to be is in the same `feature_gate.rs`. For example, you might see code like this: - ``` - gate_feature_post!(&self, pub_restricted, span, - "`pub(restricted)` syntax is experimental"); - ``` +```rust,ignore +gate_feature_post!(&self, pub_restricted, span, + "`pub(restricted)` syntax is experimental"); +``` This `gate_feature_post!` macro prints an error if the `pub_restricted` feature is not enabled. It is not needed @@ -131,9 +150,9 @@ now that `#[pub_restricted]` is stable. For more subtle features, you may find code like this: - ``` - if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ } - ``` +```rust,ignore +if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ } +``` This `pub_restricted` field (obviously named after the feature) would ordinarily be false if the feature flag is not present @@ -141,43 +160,15 @@ and true if it is. So transform the code to assume that the field is true. In this case, that would mean removing the `if` and leaving just the `/* XXX */`. - ``` - if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ } - ``` +```rust,ignore +if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ } becomes -```rust - /* XXX */ +/* XXX */ - if self.tcx.sess.features.borrow().pub_restricted && something { /* XXX */ } - ``` -becomes -```rust - if something { /* XXX */ } - ``` - -## Updating documentation - -If any documentation for this feature exists, it should be -in the `Unstable Book`, located at `src/doc/unstable-book`. -If it exists, the page for the feature gate -should be removed. - -If there was documentation there, integrating it into the -existing documentation is needed. - -If there wasn't documentation there, it needs to be added. - -Places that may need updated documentation: - - [The Reference]: this must be updated, in full detail. - [The Book]: this may or may not need updating, depending. - If you're not sure, please open an issue on this repository - and it can be discussed. - standard library documentation: as needed. Language features - often don't need this, but if it's a feature that changes - how good examples are written, such as when `?` was added - to the language, updating examples is important. - [Rust by Example]: as needed. +if self.tcx.sess.features.borrow().pub_restricted && something { /* XXX */ } + becomes +if something { /* XXX */ } +``` [rust-lang/rust#32409]:https://github.com/rust-lang/rust/issues/32409 [The Reference]: https://github.com/rust-lang-nursery/reference From d3e8792c2cd2ce7e66e28240ecde4fb20c126f21 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 14:04:50 -0500 Subject: [PATCH 0471/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 2974f6314..a17eff162 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -114,7 +114,7 @@ found by consulting [the forge](https://forge.rust-lang.org/), which will guide you the next stable release number. You want to add 1 to that, because the code that lands today will become go into beta on that date, and then become stable after that. So, at the time of this -writing, the next stable release (what is currently beta, iow) was +writing, the next stable release (i.e. what is currently beta) was 1.30.0, hence I wrote 1.31.0 above. ### Removing existing uses of the feature-gate From 74fd971003d9ea38e55b3fc6e3eeaabcc4d9f1c4 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 14:05:13 -0500 Subject: [PATCH 0472/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index a17eff162..89407308d 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -121,7 +121,7 @@ writing, the next stable release (i.e. what is currently beta) was Next search for the feature string (in this case, `pub_restricted`) in the codebase to find where it appears. Change uses of -`#![feature(XXX)]` from the stdlib and rustc crates to be +`#![feature(XXX)]` from the `libstd` and any rustc crates to be `#![cfg_attr(stage0, feature(XXX))]`. This includes the feature-gate only for stage0, which is built using the current beta (this is needed because the feature is still unstable in the current beta). From c36a489d97caa449f926b449d070c9de31dcb1bc Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 17 Jan 2019 14:09:41 -0500 Subject: [PATCH 0473/1812] issue 130 stabilization guide --- src/stabilization_guide.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 89407308d..e56313bb0 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -22,15 +22,15 @@ If there wasn't documentation there, it needs to be added. Places that may need updated documentation: - [The Reference]: This must be updated, in full detail. - [The Book]: This may or may not need updating, depends. +- [The Reference]: This must be updated, in full detail. +- [The Book]: This may or may not need updating, depends. If you're not sure, please open an issue on this repository and it can be discussed. - standard library documentation: As needed. Language features +- standard library documentation: As needed. Language features often don't need this, but if it's a feature that changes how good examples are written, such as when `?` was added to the language, updating examples is important. - [Rust by Example]: As needed. +- [Rust by Example]: As needed. Prepare PRs to update documentations invovling this new feature for repositories mentioned above.Maintainers of these repositories From a230029888ab3b66ef18e4a86aa18c643996849c Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 17 Jan 2019 14:20:24 -0500 Subject: [PATCH 0474/1812] issue 130 stabilization guide --- src/stabilization_guide.md | 5 ++++- src/walkthrough.md | 4 ---- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index e56313bb0..7f3c7321a 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -56,6 +56,8 @@ The report should contain: previous steps). - Any other relevant information(Examples of such reports can be found in rust-lang/rust#44494 and rust-lang/rust#28237). +- The resolutions of any unresolved questions if the stabilization + is for an RFC. ## FCP @@ -88,7 +90,7 @@ in the documentation. ### Updating the feature-gate listing There is a central listing of feature-gates in -`src/libsyntax/feature_gate.rs`. Search for the `declare_features!` +`[src/libsyntax/feature_gate.rs]`. Search for the `declare_features!` macro. There should be an entry for the feature you are aiming to stabilize, something like (this example is taken from [rust-lang/rust#32409]: @@ -171,6 +173,7 @@ if something { /* XXX */ } ``` [rust-lang/rust#32409]:https://github.com/rust-lang/rust/issues/32409 +[src/libsyntax/feature_gate.rs]:https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/index.html [The Reference]: https://github.com/rust-lang-nursery/reference [The Book]: https://github.com/rust-lang/book [Rust by Example]: https://github.com/rust-lang/rust-by-example diff --git a/src/walkthrough.md b/src/walkthrough.md index e77a0f690..fa259de99 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -260,10 +260,6 @@ about the feature. [stab]: https://github.com/rust-lang/rust/pull/56245 -TODO: currently, we have a [forge article][feature-stab] about stabilization, but -we really ought to move that to the guide (in fact, we probably should have a whole -chapter about feature gates and stabilization). - [feature-stab]: https://forge.rust-lang.org/stabilization-guide.html [relnotes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md From 996d9493a23da668f4992be47f764a23d9908c63 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 16:40:07 -0500 Subject: [PATCH 0475/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 7f3c7321a..c217c2251 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -33,7 +33,7 @@ Places that may need updated documentation: - [Rust by Example]: As needed. Prepare PRs to update documentations invovling this new feature -for repositories mentioned above.Maintainers of these repositories +for repositories mentioned above. Maintainers of these repositories will keep these PRs open until the whole stabilization process has completed. Meanwhile, we can proceed to the next step. From fe1c4b73a1a203ff8ad65a47928f23b2e0227468 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 16:40:18 -0500 Subject: [PATCH 0476/1812] Update src/stabilization_guide.md Co-Authored-By: rajcspsg --- src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index c217c2251..6296aaa01 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -90,7 +90,7 @@ in the documentation. ### Updating the feature-gate listing There is a central listing of feature-gates in -`[src/libsyntax/feature_gate.rs]`. Search for the `declare_features!` +[`src/libsyntax/feature_gate.rs`]. Search for the `declare_features!` macro. There should be an entry for the feature you are aiming to stabilize, something like (this example is taken from [rust-lang/rust#32409]: From 72237edfa4d4f2ce90dcb178671e030079c0f2b6 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 17 Jan 2019 17:04:03 -0500 Subject: [PATCH 0477/1812] issue 130 stabilization guide --- src/stabilization_guide.md | 29 +++++++++++++++-------------- src/walkthrough.md | 4 +--- 2 files changed, 16 insertions(+), 17 deletions(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 6296aaa01..eb2c64298 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -12,7 +12,7 @@ following steps. ## Documentation PRs If any documentation for this feature exists, it should be -in the `Unstable Book`, located at `src/doc/unstable-book`. +in the [`Unstable Book`], located at [`src/doc/unstable-book`]. If it exists, the page for the feature gate should be removed. If there was documentation there, integrating it into the @@ -63,8 +63,7 @@ The report should contain: If any member of the team responsible for tracking this feature agrees with stabilizing this feature, they will -start the FCP (final-comment-period) process by -commenting +start the FCP (final-comment-period) process by commenting ```bash @rfcbot fcp merge @@ -75,24 +74,24 @@ decision is to stabilize, we proceed to do the actual code modification. ## Stabilization PR -Once we have decided to stabilize a feature, we need to have a PR that -actually makes that stabilization happen. These kinds of PRs are a -great way to get involved in Rust, as they take you on a little tour -through the source code. +Once we have decided to stabilize a feature, we need to have +a PR that actually makes that stabilization happen. These kinds +of PRs are a great way to get involved in Rust, as they take +you on a little tour through the source code. -Here is a general guide to how to stabilize a feature -- every feature -is different, of course, so some features may require steps beyond -what this guide talks about. +Here is a general guide to how to stabilize a feature -- +every feature is different, of course, so some features may +require steps beyond what this guide talks about. -Note: Before we stabilize any feature, it's the rule that it should appear -in the documentation. +Note: Before we stabilize any feature, it's the rule that it +should appear in the documentation. ### Updating the feature-gate listing There is a central listing of feature-gates in [`src/libsyntax/feature_gate.rs`]. Search for the `declare_features!` -macro. There should be an entry for the feature you are aiming to -stabilize, something like (this example is taken from +macro. There should be an entry for the feature you are aiming +to stabilize, something like (this example is taken from [rust-lang/rust#32409]: ```rust,ignore @@ -177,3 +176,5 @@ if something { /* XXX */ } [The Reference]: https://github.com/rust-lang-nursery/reference [The Book]: https://github.com/rust-lang/book [Rust by Example]: https://github.com/rust-lang/rust-by-example +[`Unstable Book`]: https://doc.rust-lang.org/unstable-book/index.html +[`src/doc/unstable-book`]: https://github.com/rust-lang/rust/tree/master/src/doc/unstable-book \ No newline at end of file diff --git a/src/walkthrough.md b/src/walkthrough.md index fa259de99..2823426be 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -258,8 +258,6 @@ After this, [a PR is made][stab] to remove the feature gate, enabling the featur default (on the 2018 edition). A note is added to the [Release notes][relnotes] about the feature. -[stab]: https://github.com/rust-lang/rust/pull/56245 - -[feature-stab]: https://forge.rust-lang.org/stabilization-guide.html +Steps to stabilize the feature can be found at [Stabilizing Features](./stabilization_guide.md). [relnotes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md From 1aadda5c5e1b8c1ce8a558891f346362d16edbd7 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 17 Jan 2019 18:57:05 -0600 Subject: [PATCH 0478/1812] Update stabilization_guide.md --- src/stabilization_guide.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index eb2c64298..ab5340c95 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -172,9 +172,9 @@ if something { /* XXX */ } ``` [rust-lang/rust#32409]:https://github.com/rust-lang/rust/issues/32409 -[src/libsyntax/feature_gate.rs]:https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/index.html +[`src/libsyntax/feature_gate.rs`]:https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/index.html [The Reference]: https://github.com/rust-lang-nursery/reference [The Book]: https://github.com/rust-lang/book [Rust by Example]: https://github.com/rust-lang/rust-by-example [`Unstable Book`]: https://doc.rust-lang.org/unstable-book/index.html -[`src/doc/unstable-book`]: https://github.com/rust-lang/rust/tree/master/src/doc/unstable-book \ No newline at end of file +[`src/doc/unstable-book`]: https://github.com/rust-lang/rust/tree/master/src/doc/unstable-book From be6722764c701acb698ff697ec45dcd9fc1995aa Mon Sep 17 00:00:00 2001 From: king6cong Date: Fri, 18 Jan 2019 00:06:00 +0800 Subject: [PATCH 0479/1812] Update the doc related to complier logging --- src/compiler-debugging.md | 59 ++++++++++----------------------------- 1 file changed, 15 insertions(+), 44 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index aca7f7424..19c939d6d 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -1,7 +1,3 @@ -**Note: This is copied from the -[rust-forge](https://github.com/rust-lang-nursery/rust-forge). If anything needs - updating, please open an issue or make a PR on the github repo.** - # Debugging the compiler [debugging]: #debugging @@ -134,6 +130,11 @@ $ # Cool, now I have a backtrace for the error ## Getting logging output [getting-logging-output]: #getting-logging-output +These crates are used in compiler for logging: + +* [log] +* [env-logger]: check the link to see the full `RUST_LOG` syntax + The compiler has a lot of `debug!` calls, which print out logging information at many points. These are very useful to at least narrow down the location of a bug if not to find it entirely, or just to orient yourself as to why the @@ -141,10 +142,8 @@ compiler is doing a particular thing. To see the logs, you need to set the `RUST_LOG` environment variable to your log filter, e.g. to get the logs for a specific module, you can run the -compiler as `RUST_LOG=module::path rustc my-file.rs`. The Rust logs are -powered by [env-logger], and you can look at the docs linked there to see -the full `RUST_LOG` syntax. All `debug!` output will then appear in -standard error. +compiler as `RUST_LOG=module::path rustc my-file.rs`. All `debug!` output will +then appear in standard error. Note that unless you use a very strict filter, the logger will emit a *lot* of output - so it's typically a good idea to pipe standard error to a file @@ -176,8 +175,10 @@ $ RUST_LOG=debug rustc +local my-file.rs 2>all-log $ RUST_LOG=rustc_trans=info rustc +local my-file.rs ``` -While calls to `info!` are included in every build of the compiler, -calls to `debug!` are only included in the program if the +### How to keep or remove `debug!` and `trace!` calls from the resulting binary + +While calls to `error!`, `warn!` and `info!` are included in every build of the compiler, +calls to `debug!` and `trace!` are only included in the program if `debug-assertions=yes` is turned on in config.toml (it is turned off by default), so if you don't see `DEBUG` logs, especially if you run the compiler with `RUST_LOG=rustc rustc some.rs` and only see @@ -200,48 +201,18 @@ However, there are still a few concerns that you might care about: ### Expensive operations in logs -A note of caution: the expressions *within* the `debug!` call are run -whenever RUST_LOG is set, even if the filter would exclude the log. This means -that if in the module `rustc::foo` you have a statement +If in the module `rustc::foo` you have a statement ```Rust debug!("{:?}", random_operation(tcx)); ``` Then if someone runs a debug `rustc` with `RUST_LOG=rustc::bar`, then -`random_operation()` will still run - even while it's output will never be -needed! +`random_operation()` will run. This means that you should not put anything too expensive or likely to crash there - that would annoy anyone who wants to use logging for their own -module. Note that if `RUST_LOG` is unset (the default), then the code will not -run - this means that if your logging code panics, then no-one will know it -until someone tries to use logging to find *another* bug. - -If you *need* to do an expensive operation in a log, be aware that while log -expressions are *evaluated* even if logging is not enabled in your module, -they are not *formatted* unless it *is*. This means you can put your -expensive/crashy operations inside an `fmt::Debug` impl, and they will not be -run unless your log is enabled: - -```Rust -use std::fmt; - -struct ExpensiveOperationContainer<'a, 'gcx, 'tcx> - where 'tcx: 'gcx, 'a: 'tcx -{ - tcx: TyCtxt<'a, 'gcx, 'tcx> -} - -impl<'a, 'gcx, 'tcx> fmt::Debug for ExpensiveOperationContainer<'a, 'gcx, 'tcx> { - fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { - let value = random_operation(tcx); - fmt::Debug::fmt(&value, fmt) - } -} - -debug!("{:?}", ExpensiveOperationContainer { tcx }); -``` +module. No-one will know it until someone tries to use logging to find *another* bug. ## Formatting Graphviz output (.dot files) [formatting-graphviz-output]: #formatting-graphviz-output @@ -382,7 +353,7 @@ create a minimal working example with Godbolt. Go to 5. Once you have a godbolt link demonstrating the issue, it is pretty easy to fill in an LLVM bug. - +[log]: https://docs.rs/log/0.4.6/log/index.html [env-logger]: https://docs.rs/env_logger/0.4.3/env_logger/ ## Narrowing (Bisecting) Regressions From ae6381c6d76ecbfb5aea676f73cba87815464745 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 18 Jan 2019 14:09:30 -0600 Subject: [PATCH 0480/1812] Fix relative link --- src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 0e697aeea..af099d09a 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -54,7 +54,7 @@ rib | a data structure in the name resolver that keeps trac sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference.html#placeholder) for more details. +placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference.html#placeholders-and-universes) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) From e900144d759fdf0245c2365e36016281106f252d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 18 Jan 2019 14:36:52 -0600 Subject: [PATCH 0481/1812] Typo + minor edits --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index ba5b1cde4..e6230439e 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -This is a collaborate effort to build a guide that explains how rustc +This is a collaborative effort to build a guide that explains how rustc works. The aim of the guide is to help new contributors get oriented to rustc, as well as to help more experienced folks in figuring out some new part of the compiler that they haven't worked on before. @@ -9,10 +9,10 @@ You may also find the rustdocs [for the compiler itself][rustdocs] useful. [rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ -The guide can be useful today, but it has a lot of work still go. - ### Contributing to the guide +The guide is useful today, but it has a lot of work still go. + If you'd like to help improve the guide, we'd love to have you! You can find plenty of issues on the [issue tracker](https://github.com/rust-lang/rustc-guide/issues). Just post a From 8375007aa8b428f3973b208b9c6bbc91c903c35d Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 18 Jan 2019 15:16:13 -0600 Subject: [PATCH 0482/1812] Reorganize the book into 3 parts --- src/SUMMARY.md | 27 +++++++++++++++++---------- src/about-this-guide.md | 5 +++++ src/part-1-intro.md | 7 +++++++ src/part-2-intro.md | 12 ++++++++++++ 4 files changed, 41 insertions(+), 10 deletions(-) create mode 100644 src/part-1-intro.md create mode 100644 src/part-2-intro.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 9bdf89278..a17a3c6a0 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -1,21 +1,28 @@ # Summary -- [About this guide](./about-this-guide.md) +[About this guide](./about-this-guide.md) + +--- + +- [Part 1 Intro](./part-1-intro.md) - [About the compiler team](./compiler-team.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) - [Documenting Compiler](./compiler-documenting.md) -- [Coding conventions](./conventions.md) -- [Stabilizing Features](./stabilization_guide.md) -- [Walkthrough: a typical contribution](./walkthrough.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) - [Adding new tests](./tests/adding.md) - - [Using `compiletest` + commands to control test - execution](./compiletest.md) + - [Using `compiletest` + commands to control test execution](./compiletest.md) +- [Walkthrough: a typical contribution](./walkthrough.md) +- [Stabilizing Features](./stabilization_guide.md) - [Debugging the Compiler](./compiler-debugging.md) - [Profiling the compiler](./profiling.md) - [with the linux perf tool](./profiling/with_perf.md) +- [Coding conventions](./conventions.md) + +--- + +- [Part 2 Intro](./part-2-intro.md) - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver](./rustc-driver.md) - [Rustdoc](./rustdoc.md) @@ -71,7 +78,7 @@ --- -- [Appendix A: Stupid Stats](./appendix/stupid-stats.md) -- [Appendix B: Background material](./appendix/background.md) -- [Appendix C: Glossary](./appendix/glossary.md) -- [Appendix D: Code Index](./appendix/code-index.md) +[Appendix A: Stupid Stats](./appendix/stupid-stats.md) +[Appendix B: Background material](./appendix/background.md) +[Appendix C: Glossary](./appendix/glossary.md) +[Appendix D: Code Index](./appendix/code-index.md) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 56f0b7538..30a3b8870 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -6,6 +6,11 @@ development. It is not meant to replace code documentation – each chapter gives only high-level details – the kinds of things that (ideally) don't change frequently. +There are three parts to this guide. Part 1 contains information that should +be useful no matter how you are contributing. Part 2 contains information +about how the compiler works. Finally, there are some appendices at the +end with useful reference information. + The guide itself is of course open-source as well, and the sources can be found at the [GitHub repository]. If you find any mistakes in the guide, please file an issue about it, or even better, open a PR diff --git a/src/part-1-intro.md b/src/part-1-intro.md new file mode 100644 index 000000000..c829f8c3b --- /dev/null +++ b/src/part-1-intro.md @@ -0,0 +1,7 @@ +# Part 1: General Knowledge + +This section of the rustc-guide contains knowledge that should be useful to you +regardless of what part of the compiler you are working on. This includes both +technical info and tips (e.g. how to compile and debug the compiler) and info +about processes in the Rust project (e.g. stabilization and info about the +compiler team). diff --git a/src/part-2-intro.md b/src/part-2-intro.md new file mode 100644 index 000000000..6dd26f44c --- /dev/null +++ b/src/part-2-intro.md @@ -0,0 +1,12 @@ +# Part 2: How rustc works + +This part of the guide describes how the compiler works. It goes through +everything from high-level structure of the compiler to how each stage of +compilation works. + +This section should be friendly to both readers interested in the end-to-end +process of compilation _and_ readers interested in learning about a specific +system they wish to contribute to. If anything is unclear, feel free to file +an issue on the [rustc-guide repo](https://github.com/rust-lang/rustc-guide) +or contact the compiler team, as detailed in [this chapter from Part +1](./compiler-team.md). From 2c5ff5503a620c555a87bc5743e3dbbdbec6a94e Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 18 Jan 2019 15:32:17 -0600 Subject: [PATCH 0483/1812] better titles a la Niko --- src/SUMMARY.md | 4 ++-- src/part-1-intro.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a17a3c6a0..4df03dc7a 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -4,7 +4,7 @@ --- -- [Part 1 Intro](./part-1-intro.md) +- [Part 1: Building, debugging, and contributing to Rustc](./part-1-intro.md) - [About the compiler team](./compiler-team.md) - [How to build the compiler and run what you built](./how-to-build-and-run.md) - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) @@ -22,7 +22,7 @@ --- -- [Part 2 Intro](./part-2-intro.md) +- [Part 2: How rustc works](./part-2-intro.md) - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver](./rustc-driver.md) - [Rustdoc](./rustdoc.md) diff --git a/src/part-1-intro.md b/src/part-1-intro.md index c829f8c3b..65cb1ae48 100644 --- a/src/part-1-intro.md +++ b/src/part-1-intro.md @@ -1,4 +1,4 @@ -# Part 1: General Knowledge +# Part 1: Building, debugging, and contributing to Rustc This section of the rustc-guide contains knowledge that should be useful to you regardless of what part of the compiler you are working on. This includes both From 3a79ba54320110f88096c747935172f86f8dec00 Mon Sep 17 00:00:00 2001 From: rchaser53 Date: Sat, 19 Jan 2019 23:48:13 +0900 Subject: [PATCH 0484/1812] fix related miri variables rename variables like below - Value => ConstValue - PrimVal => Scalar - Value::ByVal => ConstValue::Scalar - Value::ByValPair => ConstValue::ScalarPair --- src/const-eval.md | 6 +++--- src/miri.md | 16 ++++++++-------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/const-eval.md b/src/const-eval.md index 1f801fb22..aaa2ed2d6 100644 --- a/src/const-eval.md +++ b/src/const-eval.md @@ -30,9 +30,9 @@ used) and a `GlobalId`. The `GlobalId` is made up of an Constant evaluation returns a `Result` with either the error, or the simplest representation of the constant. "simplest" meaning if it is representable as an -integer or fat pointer, it will directly yield the value (via `Value::ByVal` or -`Value::ByValPair`), instead of referring to the [`miri`](./miri.html) virtual -memory allocation (via `Value::ByRef`). This means that the `const_eval` +integer or fat pointer, it will directly yield the value (via `ConstValue::Scalar` or +`ConstValue::ScalarPair`), instead of referring to the [`miri`](./miri.html) virtual +memory allocation (via `ConstValue::ByRef`). This means that the `const_eval` function cannot be used to create miri-pointers to the evaluated constant or static. If you need that, you need to directly work with the functions in [src/librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html). diff --git a/src/miri.md b/src/miri.md index a3c7b3ff4..cbed690eb 100644 --- a/src/miri.md +++ b/src/miri.md @@ -55,18 +55,18 @@ Before the evaluation, a virtual memory location (in this case essentially a `vec![u8; 4]` or `vec![u8; 8]`) is created for storing the evaluation result. At the start of the evaluation, `_0` and `_1` are -`Value::ByVal(PrimVal::Undef)`. When the initialization of `_1` is invoked, the +`ConstValue::Scalar(Scalar::Undef)`. When the initialization of `_1` is invoked, the value of the `FOO` constant is required, and triggers another call to `tcx.const_eval`, which will not be shown here. If the evaluation of FOO is successful, 42 will be subtracted by its value `4096` and the result stored in -`_1` as `Value::ByValPair(PrimVal::Bytes(4054), PrimVal::Bytes(0))`. The first +`_1` as `ConstValue::ScalarPair(Scalar::Bytes(4054), Scalar::Bytes(0))`. The first part of the pair is the computed value, the second part is a bool that's true if an overflow happened. The next statement asserts that said boolean is `0`. In case the assertion fails, its error message is used for reporting a compile-time error. -Since it does not fail, `Value::ByVal(PrimVal::Bytes(4054))` is stored in the +Since it does not fail, `ConstValue::Scalar(Scalar::Bytes(4054))` is stored in the virtual memory was allocated before the evaluation. `_0` always refers to that location directly. @@ -75,7 +75,7 @@ After the evaluation is done, the virtual memory allocation is interned into the miri, but just extract the value from the interned allocation. The `tcx.const_eval` function has one additional feature: it will not return a -`ByRef(interned_allocation_id)`, but a `ByVal(computed_value)` if possible. This +`ByRef(interned_allocation_id)`, but a `Scalar(computed_value)` if possible. This makes using the result much more convenient, as no further queries need to be executed in order to get at something as simple as a `usize`. @@ -83,15 +83,15 @@ executed in order to get at something as simple as a `usize`. Miri's core datastructures can be found in [librustc/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc/mir/interpret). -This is mainly the error enum and the `Value` and `PrimVal` types. A `Value` can -be either `ByVal` (a single `PrimVal`), `ByValPair` (two `PrimVal`s, usually fat +This is mainly the error enum and the `ConstValue` and `Scalar` types. A `ConstValue` can +be either `Scalar` (a single `Scalar`), `ScalarPair` (two `Scalar`s, usually fat pointers or two element tuples) or `ByRef`, which is used for anything else and refers to a virtual allocation. These allocations can be accessed via the methods on `tcx.interpret_interner`. If you are expecting a numeric result, you can use `unwrap_u64` (panics on anything that can't be representad as a `u64`) or `to_raw_bits` which results -in an `Option` yielding the `ByVal` if possible. +in an `Option` yielding the `Scalar` if possible. ## Allocations @@ -113,7 +113,7 @@ to a pointer to `b`. Although the main entry point to constant evaluation is the `tcx.const_eval` query, there are additional functions in [librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html) -that allow accessing the fields of a `Value` (`ByRef` or otherwise). You should +that allow accessing the fields of a `ConstValue` (`ByRef` or otherwise). You should never have to access an `Allocation` directly except for translating it to the compilation target (at the moment just LLVM). From 4f0d4744b82a14a443ed793c48cab1d4b0b5fa5f Mon Sep 17 00:00:00 2001 From: rchaser53 Date: Tue, 22 Jan 2019 00:24:36 +0900 Subject: [PATCH 0485/1812] fix unwrap_u64 and to_raw_bits --- src/miri.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/miri.md b/src/miri.md index cbed690eb..d361103f2 100644 --- a/src/miri.md +++ b/src/miri.md @@ -89,8 +89,8 @@ pointers or two element tuples) or `ByRef`, which is used for anything else and refers to a virtual allocation. These allocations can be accessed via the methods on `tcx.interpret_interner`. -If you are expecting a numeric result, you can use `unwrap_u64` (panics on -anything that can't be representad as a `u64`) or `to_raw_bits` which results +If you are expecting a numeric result, you can use `unwrap_usize` (panics on +anything that can't be representad as a `u64`) or `assert_usize` which results in an `Option` yielding the `Scalar` if possible. ## Allocations From 3a1620143f2b87ca67096431267bca0915705a54 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Mon, 21 Jan 2019 16:45:09 +0100 Subject: [PATCH 0486/1812] Fix TokenStream link --- src/appendix/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 546e9f9b7..e1bde6863 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -23,7 +23,7 @@ Item | Kind | Short description | Chapter | `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html) -`syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/enum.TokenStream.html) +`syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) From 54bf20498bbdc7f5b97e076ceb386ff703b0d59c Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Tue, 22 Jan 2019 15:26:01 +0100 Subject: [PATCH 0487/1812] Add "The Query Evaluation Model in Detail" Chapter. --- src/SUMMARY.md | 1 + .../query-evaluation-model-in-detail.md | 236 ++++++++++++++++++ src/query.md | 60 +---- 3 files changed, 243 insertions(+), 54 deletions(-) create mode 100644 src/queries/query-evaluation-model-in-detail.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 9bdf89278..4d6136702 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -20,6 +20,7 @@ - [The Rustc Driver](./rustc-driver.md) - [Rustdoc](./rustdoc.md) - [Queries: demand-driven compilation](./query.md) + - [The Query Evaluation Model in Detail](./query-evaluation-model-in-detail.md) - [Incremental compilation](./incremental-compilation.md) - [Debugging and Testing](./incrcomp-debugging.md) - [The parser](./the-parser.md) diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md new file mode 100644 index 000000000..d2dc10479 --- /dev/null +++ b/src/queries/query-evaluation-model-in-detail.md @@ -0,0 +1,236 @@ + + +# The Query Evaluation Model in Detail + +This chapter provides a deeper dive into the abstract model queries are built on. +It does not go into implementation details but tries to explain +the underlying logic. The examples here, therefore, have been stripped down and +simplified and don't directly reflect the compilers internal APIs. + +## What is a query? + +Abstractly we view the compiler's knowledge about a given crate as a "database" +and queries are the way of asking the compiler questions about it, i.e. +we "query" the compiler's "database" for facts. + +However, there's something special to this compiler database: It starts out empty +and is filled on-demand when queries are executed. Consequently, a query must +know how to compute its result if the database does not contain it yet. For +doing so, it can access other queries and certain input values that the database +is pre-filled with on creation. + +A query thus consists of the following things: + + - A name that identifies the query + - A "key" that specifies what we want to look up + - A result type that specifies what kind of result it yields + - A "provider" which is a function that specifies how the result is to be + computed if it isn't already present in the database. + +As an example, the name of the `type_of` query is `type_of`, its query key is a +`DefId` identifying the item we want to know the type of, the result type is +`Ty<'tcx>`, and the provider is a function that, given the query key and access +to the rest of the database, can compute the type of the item identified by the +key. + +So in some sense a query is just a function that maps the query key to the +corresponding result. However, we have to apply some restrictions in order for +this to be sound: + + - The key and result must be immutable values. + - The provider function must be a pure function, that is, for the same key it + must always yield the same result. + - The only parameters a provider function takes are the key and a reference to + the "query context" (which provides access to rest of the "database"). + +The database is built up lazily by invoking queries. The query providers will +invoke other queries, for which the result is either already cached or computed +by calling another query provider. These query provider invocations +conceptually form a directed acyclic graph (DAG) at the leaves of which are +input values that are already known when the query context is created. + + + +## Caching/Memoization + +Results of query invocations are "memoized" which means that the query context +will cache the result in an internal table and, when the query is invoked with +the same query key again, will return the result from the cache instead of +running the provider again. + +This caching is crucial for making the query engine efficient. Without +memoization the system would still be sound (that is, it would yield the same +results) but the same computations would be done over and over again. + +Memoization is one of the main reasons why query providers have to be pure +functions. If calling a provider function could yield different results for +each invocation (because it accesses some global mutable state) then we could +not memoize the result. + + + +## Input data + +When the query context is created, it is still empty: No queries have been +executed, no results are cached. But the context already provides access to +"input" data, i.e. pieces of immutable data that where computed before the +context was created and that queries can access to do their computations. +Currently this input data consists mainly of the HIR map and the command-line +options the compiler was invoked with. In the future, inputs will just consist +of command-line options and a list of source files -- the HIR map will itself +be provided by a query which processes these source files. + +Without inputs, queries would live in a void without anything to compute their +result from (remember, query providers only have access to other queries and +the context but not any other outside state or information). + +For a query provider, input data and results of other queries look exactly the +same: It just tells the context "give me the value of X". Because input data +is immutable, the provider can rely on it being the same across +different query invocations, just as is the case for query results. + + + +## An example execution trace of some queries + +How does this DAG of query invocations come into existence? At some point +the compiler driver will create the, as yet empty, query context. It will then, +from outside of the query system, invoke the queries it needs to perform its +task. This looks something like the following: + +```rust,ignore +fn compile_crate() {} + let cli_options = ...; + let hir_map = ...; + + // Create the query context `tcx` + let tcx = TyCtxt::new(cli_options, hir_map); + + // Do type checking by invoking the type check query + tcx.type_check_crate(); +} +``` + +The `type_check_crate` query provider would look something like the following: + +```rust,ignore +fn type_check_crate_provider(tcx, _key: ()) { + let list_of_items = tcx.hir_map.list_of_items(); + + for item_def_id in list_of_hir_items { + tcx.type_check_item(item_def_id); + } +} +``` + +We see that the `type_check_crate` query accesses input data (`tcx.hir_map`) +and invokes other queries (`type_check_item`). The `type_check_item` +invocations will themselves access input data and/or invoke other queries, +so that in the end the DAG of query invocations will be built up backwards +from the node that was initially executed: + +``` + (1) + hir_map <--------------------------------------------------- type_check_crate() + ^ | + | (4) (3) (2) | + +-- Hir(foo) <--- type_of(foo) <--- type_check_item(foo) <-------+ + | | | + | +-----------------+ | + | | | + | (6) v (5) (7) | + +-- Hir(bar) <--- type_of(bar) <--- type_check_item(bar) <-------+ + +// (x) denotes invocation order +``` + +We also see that often a query result can be read from the cache: +`type_of(bar)` was computed for `type_check_item(foo)` so when +`type_check_item(bar)` needs it, it is already in the cache. + +Query results stay cached in the query context as long as the context lives. +So if the compiler driver invoked another query later on, the above graph +would still exist and already executed queries would not have to be re-done. + + + +## Cycles + +Earlier we stated that query invocations form a DAG. However, it would be easy +form a cyclic graph by, for example, having a query provider like the following: + +```rust,ignore +fn cyclic_query_provider(tcx, key) -> u32 { + // Invoke the same query with the same key again + tcx.cyclic_query(key) +} +``` + +Since query providers are regular functions, this would behave much as expected: +Evaluation would get stuck in an infinite recursion. A query like this would not +be very useful either. However, sometimes certain kinds of invalid user input +can result in queries being called in a cyclic way. The query engine includes +a check for cyclic invocations and, because cycles are an irrecoverable error, +will abort execution with a "cycle error" messages that tries to be human +readable. + +At some point the compiler had a notion of "cycle recovery", that is, one could +"try" to execute a query and if it ended up causing a cycle, proceed in some +other fashion. However, this was later removed because it is not entirely +clear what the theoretical consequences of this are, especially regarding +incremental compilation. + + +## "Steal" Queries + +Some queries have their result wrapped in a `Steal` struct. These queries +behave exactly the same as regular with one exception: Their result is expected +to be "stolen" out of the cache at some point, meaning some other part of the +program is taking ownership of it and the result cannot be accessed anymore. + +This stealing mechanism exists purely as a performance optimization because some +result values are too costly to clone (e.g. the MIR of a function). It seems +like result stealing would violate the condition that query results must be +immutable (after all we are moving the result value out of the cache) but it is +OK as long as the mutation is not observable. This is achieved by two things: + +- Before a result is stolen, we make sure to eagerly run all queries that + might ever need to read that result. This has to be done manually by calling + those queries. +- Whenever a query tries to access a stolen result, we make the compiler ICE so + that such a condition cannot go unnoticed. + +This is not an ideal setup because of the manual intervention needed, so it +should be used sparingly and only when it is well known which queries might +access a given result. In practice, however, stealing has not turned out to be +much of a maintainance burden. + +To summarize: "Steal queries" break some of the rules in a controlled way. +There are checks in place that make sure that nothing can go silently wrong. + + +## Parallel Query Execution + +The query model has some properties that make it actually feasible to evaluate +multiple queries in parallel without too much of an effort: + +- All data a query provider can access is accessed via the query context, so + the query context can take care of synchronizing access. +- Query results are required to be immutable so they can safely be used by + different threads concurrently. + +The nightly compiler already implements parallel query evaluation as follows: + +When a query `foo` is evaluated, the cache table for `foo` is locked. + +- If there already is a result, we can clone it,release the lock and + we are done. +- If there is no cache entry and no other active query invocation computing the + same result, we mark the key as being "in progress", release the lock and + start evaluating. +- If there *is* another query invocation for the same key in progress, we + release the lock, and just block the thread until the other invocation has + computed the result we are waiting for. This cannot deadlock because, as + mentioned before, query invocations form a DAG. Some thread will always make + progress. + diff --git a/src/query.md b/src/query.md index a0c0d6282..ee7d60e4b 100644 --- a/src/query.md +++ b/src/query.md @@ -35,6 +35,12 @@ will in turn demand information about that crate, starting from the However, that vision is not fully realized. Still, big chunks of the compiler (for example, generating MIR) work exactly like this. +### The Query Evaluation Model in Detail + +The [Query Evaluation Model in Detail](query-evaluation-model-in-detail.html) +chapter gives a more in-depth description of what queries are and how they work. +If you intend to write a query of your own, this is a good read. + ### Invoking queries To invoke a query is simple. The tcx ("type context") offers a method @@ -45,60 +51,6 @@ query, you would just do this: let ty = tcx.type_of(some_def_id); ``` -### Cycles between queries - -A cycle is when a query becomes stuck in a loop e.g. query A generates query B -which generates query A again. - -Currently, cycles during query execution should always result in a -compilation error. Typically, they arise because of illegal programs -that contain cyclic references they shouldn't (though sometimes they -arise because of compiler bugs, in which case we need to factor our -queries in a more fine-grained fashion to avoid them). - -However, it is nonetheless often useful to *recover* from a cycle -(after reporting an error, say) and try to soldier on, so as to give a -better user experience. In order to recover from a cycle, you don't -get to use the nice method-call-style syntax. Instead, you invoke -using the `try_get` method, which looks roughly like this: - -```rust,ignore -use ty::queries; -... -match queries::type_of::try_get(tcx, DUMMY_SP, self.did) { - Ok(result) => { - // no cycle occurred! You can use `result` - } - Err(err) => { - // A cycle occurred! The error value `err` is a `DiagnosticBuilder`, - // meaning essentially an "in-progress", not-yet-reported error message. - // See below for more details on what to do here. - } -} -``` - -So, if you get back an `Err` from `try_get`, then a cycle *did* occur. This -means that you must ensure that a compiler error message is reported. You can -do that in two ways: - -The simplest is to invoke `err.emit()`. This will emit the cycle error to the -user. - -However, often cycles happen because of an illegal program, and you -know at that point that an error either already has been reported or -will be reported due to this cycle by some other bit of code. In that -case, you can invoke `err.cancel()` to not emit any error. It is -traditional to then invoke: - -```rust,ignore -tcx.sess.delay_span_bug(some_span, "some message") -``` - -`delay_span_bug()` is a helper that says: we expect a compilation -error to have happened or to happen in the future; so, if compilation -ultimately succeeds, make an ICE with the message `"some -message"`. This is basically just a precaution in case you are wrong. - ### How the compiler executes a query So you may be wondering what happens when you invoke a query From 952f9366b2ab1158953dd3e5f060da3f3eb93a7b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 12:41:18 -0600 Subject: [PATCH 0488/1812] update text about copyright headers --- src/conventions.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index d392ebd57..385658dac 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -20,11 +20,12 @@ in isolation with `./x.py test src/tools/tidy`. ### Copyright notice -Some existing files begin with a copyright and license notice. Please omit this -notice for new files licensed under the standard terms (dual MIT/Apache-2.0). -For existing files, the year at the top is not meaningful: copyright -protections are in fact automatic from the moment of authorship. We do not -typically edit the years on existing files. +In the past, files begin with a copyright and license notice. Please **omit** +this notice for new files licensed under the standard terms (dual +MIT/Apache-2.0). + +All of the copyright notices should be gone by now, but if you come across one +in the rust-lang/rust repo, feel free to open a PR to remove it. ## Line length From bb3392e7d70d72a77ed6c324933072a1d34434a5 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 12:56:40 -0600 Subject: [PATCH 0489/1812] update conventions --- src/SUMMARY.md | 1 + src/conventions.md | 17 ++++++++++++++++- src/crates-io.md | 23 +++++++++++++++++++++++ 3 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 src/crates-io.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4df03dc7a..f472bfaab 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -19,6 +19,7 @@ - [Profiling the compiler](./profiling.md) - [with the linux perf tool](./profiling/with_perf.md) - [Coding conventions](./conventions.md) +- [crates.io Dependencies](./crates-io.md) --- diff --git a/src/conventions.md b/src/conventions.md index 385658dac..d9f462a05 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -11,7 +11,7 @@ rustc is slowly moving towards the [Rust standard coding style][fmt]; at the moment, however, it follows a rather more *chaotic* style. We do have some mandatory formatting conventions, which are automatically enforced by a script we affectionately call the "tidy" script. The -tidy script runs automatically when you do `./x.py test` and can be run +tidy script runs automatically when you do `./x.py test` and can be run in isolation with `./x.py test src/tools/tidy`. [fmt]: https://github.com/rust-lang-nursery/fmt-rfcs @@ -133,3 +133,18 @@ require that every intermediate commit successfully builds – we only expect to be able to bisect at a PR level. However, if you *can* make individual commits build, that is always helpful. +# Naming conventions + +Apart from normal Rust style/naming conventions, there are also some specific +to the compiler. + +- `cx` tends to be short for "context" and is often used as a suffix. For + example, `tcx` is a common name for the [Typing Context][tcx]. + +- [`'tcx` and `'gcx`][tcx] are used as the lifetime names for the Typing + Context. + +- Because `crate` is a keyword, if you need a variable to represent something + crate-related, often the spelling is changed to `krate`. + +[tcx]: ./ty.md diff --git a/src/crates-io.md b/src/crates-io.md new file mode 100644 index 000000000..21dd00afe --- /dev/null +++ b/src/crates-io.md @@ -0,0 +1,23 @@ +# crates.io Dependencies + +The rust compiler supports building with some dependencies from `crates.io`. +For example, `log` and `env_logger` come from `crates.io`. + +In general, you should avoid adding dependencies to the compiler for several +reasons: + +- The dependency may not be high quality or well-maintained, whereas we want + the compiler to be high-quality. +- The dependency may not be using a compatible license. +- The dependency may have transitive dependencies that have one of the above + problems. + +TODO: what is the vetting process? + +## Whitelist + +The `tidy` tool has a [whitelist] of crates that are allowed. To add a +dependency that is not already in the compiler, you will need to add it to this +whitelist. + +[whitelist]: https://github.com/rust-lang/rust/blob/659994627234ce7d95a1a52ad8756ce661059adf/src/tools/tidy/src/deps.rs#L56 From 658ce409c4994ade842b193d3e498134907812e7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 21:55:52 -0600 Subject: [PATCH 0490/1812] fix #182 --- src/appendix/code-index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index e1bde6863..c0a1d03a9 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -15,6 +15,7 @@ Item | Kind | Short description | Chapter | `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) `HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html) `NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) +`P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [src/syntax/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ptr/struct.P.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Rib.html) @@ -27,7 +28,7 @@ Item | Kind | Short description | Chapter | `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) -`TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) +`TyCtxt<'cx, 'tcx, 'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) [The HIR]: ../hir.html [Identifiers in the HIR]: ../hir.html#hir-id From b83f584379a10064118bbd9fb131ea692b1c2b0d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 13:15:12 -0600 Subject: [PATCH 0491/1812] add link to sunjay talk --- src/traits/specialization.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/traits/specialization.md b/src/traits/specialization.md index 671e5e016..13edceca1 100644 --- a/src/traits/specialization.md +++ b/src/traits/specialization.md @@ -40,3 +40,9 @@ will use at trans time. Thus, we take special care to avoid projecting associated types unless either (1) the associated type does not use `default` and thus cannot be overridden or (2) all input types are known concretely. + +## Additional Resources + +[This talk][talk] by @sunjay may be useful. + +[talk]: https://www.youtube.com/watch?v=rZqS4bLPL24 From e7d7e38e95f964f85aa37c0ee9d337875d093e63 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 19:31:49 -0600 Subject: [PATCH 0492/1812] add comments from sunjay --- src/traits/specialization.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/traits/specialization.md b/src/traits/specialization.md index 13edceca1..7a30314b4 100644 --- a/src/traits/specialization.md +++ b/src/traits/specialization.md @@ -43,6 +43,9 @@ known concretely. ## Additional Resources -[This talk][talk] by @sunjay may be useful. +[This talk][talk] by @sunjay may be useful. Keep in mind that the talk only +gives a broad overview of the problem and the solution (it was presented about +halfway through @sunjay's work). Also, it was given in June 2018, and some +things may have changed by the time you watch it. [talk]: https://www.youtube.com/watch?v=rZqS4bLPL24 From 9600742738cf5b40f549be00be3ae099c9a5f5c1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 Jan 2019 15:02:36 -0600 Subject: [PATCH 0493/1812] fix updating-docs link, add regression test --- src/SUMMARY.md | 1 + src/important-links.md | 12 ++++++++++++ src/stabilization_guide.md | 2 ++ 3 files changed, 15 insertions(+) create mode 100644 src/important-links.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4df03dc7a..2d8c17024 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -82,3 +82,4 @@ [Appendix B: Background material](./appendix/background.md) [Appendix C: Glossary](./appendix/glossary.md) [Appendix D: Code Index](./appendix/code-index.md) +[](./important-links.md) diff --git a/src/important-links.md b/src/important-links.md new file mode 100644 index 000000000..2dc759bf6 --- /dev/null +++ b/src/important-links.md @@ -0,0 +1,12 @@ +# Ignore me + +This file is a collection of links that are not link-checked by anyone else, +but we want them to work. For example, the stabilization guide link is often +posted to tracking issues on GitHub, which might break later if the guide is +changed. + +[Skip this file. Or read it; I'm book, not a cop.](https://imgur.com/gallery/mSHi8) + +[1](https://forge.rust-lang.org/stabilization-guide.html) +[2](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#documentation-prs) +[3](https://forge.rust-lang.org/stabilization-guide.html#updating-documentation) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index ab5340c95..56da5cdaf 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -11,6 +11,8 @@ following steps. ## Documentation PRs + + If any documentation for this feature exists, it should be in the [`Unstable Book`], located at [`src/doc/unstable-book`]. If it exists, the page for the feature gate should be removed. From 1a98854e47e1ca490b453535db9e4a39754a9db0 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Tue, 22 Jan 2019 16:00:24 -0600 Subject: [PATCH 0494/1812] Typo Co-Authored-By: mark-i-m --- src/important-links.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/important-links.md b/src/important-links.md index 2dc759bf6..480be1bdb 100644 --- a/src/important-links.md +++ b/src/important-links.md @@ -5,7 +5,7 @@ but we want them to work. For example, the stabilization guide link is often posted to tracking issues on GitHub, which might break later if the guide is changed. -[Skip this file. Or read it; I'm book, not a cop.](https://imgur.com/gallery/mSHi8) +[Skip this file. Or read it; I'm a book, not a cop.](https://imgur.com/gallery/mSHi8) [1](https://forge.rust-lang.org/stabilization-guide.html) [2](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#documentation-prs) From c7cdf9fe3ecdad3ba5465ea79a77d507d6c96fe0 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 22 Jan 2019 16:02:53 -0600 Subject: [PATCH 0495/1812] better grouping, more links --- src/important-links.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/important-links.md b/src/important-links.md index 480be1bdb..367532519 100644 --- a/src/important-links.md +++ b/src/important-links.md @@ -7,6 +7,10 @@ changed. [Skip this file. Or read it; I'm a book, not a cop.](https://imgur.com/gallery/mSHi8) -[1](https://forge.rust-lang.org/stabilization-guide.html) -[2](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#documentation-prs) -[3](https://forge.rust-lang.org/stabilization-guide.html#updating-documentation) +[link](https://forge.rust-lang.org/stabilization-guide.html) +[link](https://forge.rust-lang.org/stabilization-guide.html#updating-documentation) +[link](https://forge.rust-lang.org/stabilization-guide.html#documentation-prs) + +[link](https://rust-lang.github.io/rustc-guide/stabilization_guide.html) +[link](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#updating-documentation) +[link](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#documentation-prs) From 3dadf436ad960c34445c6617fa919fe5a48a3f43 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 29 Jan 2019 10:55:57 -0600 Subject: [PATCH 0496/1812] add blurb about downloading artifacts; fix #77x --- src/compiler-debugging.md | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 19c939d6d..31f221057 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -358,4 +358,23 @@ create a minimal working example with Godbolt. Go to ## Narrowing (Bisecting) Regressions -The [cargo-bisect-rustc](https://github.com/rust-lang-nursery/cargo-bisect-rustc) tool can be used as a quick and easy way to find exactly which PR caused a change in `rustc` behavior. It automatically downloads `rustc` PR artifacts and tests them against a project you provide until it finds the regression. You can then look at the PR to get more context on *why* it was changed. See [this tutorial](https://github.com/rust-lang-nursery/cargo-bisect-rustc/blob/master/TUTORIAL.md) on how to use it. +The [cargo-bisect-rustc][bisect] tool can be used as a quick and easy way to +find exactly which PR caused a change in `rustc` behavior. It automatically +downloads `rustc` PR artifacts and tests them against a project you provide +until it finds the regression. You can then look at the PR to get more context +on *why* it was changed. See [this tutorial][bisect-tutorial] on how to use +it. + +[bisect]: https://github.com/rust-lang-nursery/cargo-bisect-rustc +[bisect-tutorial]: https://github.com/rust-lang-nursery/cargo-bisect-rustc/blob/master/TUTORIAL.md + +## Downloading Artifacts from Rust's CI + +The [rustup-toolchain-install-master][rtim] tool by kennytm can be used to +download the artifacts produced by Rust's CI for a specific SHA1 -- this +basically corresponds to the successful landing of some PR -- and then sets +them up for your local use. This also works for artifacts produced by `@bors +try`. This is helpful when you want to examine the resulting build of a PR +without doing the build yourself. + +[rtim]: https://github.com/kennytm/rustup-toolchain-install-master From 808a9a17565555682731d702555e43875a1c18e3 Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Fri, 25 Jan 2019 16:50:22 +0100 Subject: [PATCH 0497/1812] Add a more detailed description of how incremental compilation works. --- src/SUMMARY.md | 5 +- src/appendix/glossary.md | 2 +- .../incremental-compilation-in-detail.md | 354 ++++++++++++++++++ src/{ => queries}/incremental-compilation.md | 0 .../query-evaluation-model-in-detail.md | 27 +- src/query.md | 5 +- src/variance.md | 2 +- 7 files changed, 376 insertions(+), 19 deletions(-) create mode 100644 src/queries/incremental-compilation-in-detail.md rename src/{ => queries}/incremental-compilation.md (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4d6136702..cd3c9d331 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -20,8 +20,9 @@ - [The Rustc Driver](./rustc-driver.md) - [Rustdoc](./rustdoc.md) - [Queries: demand-driven compilation](./query.md) - - [The Query Evaluation Model in Detail](./query-evaluation-model-in-detail.md) - - [Incremental compilation](./incremental-compilation.md) + - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) + - [Incremental compilation](./queries/incremental-compilation.md) + - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) - [Debugging and Testing](./incrcomp-debugging.md) - [The parser](./the-parser.md) - [`#[test]` Implementation](./test-implementation.md) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 0e697aeea..decfb4426 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -15,7 +15,7 @@ completeness | completeness is a technical term in type theory. Comp control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) CTFE | Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) cx | we tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. -DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../incremental-compilation.html)) +DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. Double pointer | a pointer with additional metadata. See "fat pointer" for more. diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md new file mode 100644 index 000000000..fbe226e90 --- /dev/null +++ b/src/queries/incremental-compilation-in-detail.md @@ -0,0 +1,354 @@ +# Incremental Compilation In Detail + +The incremental compilation scheme is, in essence, a surprisingly +simple extension to the overall query system. It relies on the fact that: + + 1. queries are pure functions -- given the same inputs, a query will always + yield the same result, and + 2. the query model structures compilation in an acyclic graph that makes + dependencies between individual computations explicit. + +This chapter will explain how we can use these properties for making things +incremental and then goes on to discuss version implementation issues. + +# A Basic Algorithm For Incremental Query Evaluation + +As explained in the [query evaluation model primer][query-model], query +invocations form a directed-acyclic graph. Here's the example from the +previous chapter again: + +```ignore + list_of_all_hir_items <----------------------------- type_check_crate() + | + | + Hir(foo) <--- type_of(foo) <--- type_check_item(foo) <-------+ + | | + +-----------------+ | + | | + v | + Hir(bar) <--- type_of(bar) <--- type_check_item(bar) <-------+ +``` + +Since every access from one query to another has to go through the query +context, we can record these accesses and thus actually build this dependency +graph in memory. With dependency tracking enabled, when compilation is done, +we know which queries were invoked (the nodes of the graph) and for each +invocation, which other queries or input has gone into computing the query's +result (the edges of the graph). + +Now suppose, we change the source code of our program so that +HIR of `bar` looks different than before. Our goal is to only recompute +those queries that are actually affected by the change while just re-using +the cached results of all the other queries. Given the dependency graph we can +do exactly that. For a given query invocation, the graph tells us exactly +what data has gone into computing its results, we just have to follow the +edges until we reach something that has changed. If we don't encounter +anything that has changed, we know that the query still would evaluate to +the same result we already have in our cache. + +Taking the `type_of(foo)` invocation from above as example, we can check +whether the cached result is still valid by following the edges to its +inputs. The only edge leads to `Hir(foo)`, an input that has not been affected +by the change. So we know that the cached result for `type_of(foo)` is still +valid. + +The story is a bit different for `type_check_item(foo)`: We again walk the +edges and already know that `type_of(foo)` is fine. Then we get to +`type_of(bar)` which we have not checked yet, so we walk the edges of +`type_of(bar)` and encounter `Hir(bar)` which *has* changed. Consequently +the result of `type_of(bar)` might yield a different same result than what we +have in the cache and, transitively, the result of `type_check_item(foo)` +might have changed too. We thus re-run `type_check_item(foo)`, which in +turn will re-run `type_of(bar)`, which will yield an up-to-date result +because it reads the up-to-date version of `Hir(bar)`. + + +# The Problem With The Basic Algorithm: False Positives + +If you read the previous paragraph carefully, you'll notice that it says that +`type_of(bar)` *might* have changed because one of its inputs has changed. +There's also the possibility that it might still yield exactly the same +result *even though* its input has changed. Consider an example with a +simple query that just computes the sign of an integer: + +```ignore + IntValue(x) <---- sign_of(x) <--- some_other_query(x) +``` + +Let's say that `IntValue(x)` starts out as `1000` and then is set to `2000`. +Even though `IntValue(x)` is different in the two cases, `sign_of(x)` yields +the result `+` in both cases. + +If we follow the basic algorithm, however, `some_other_query(x)` would have to +(unnecessarily) be re-evaluated because it transitively depends on a changed +input. Change detection yields a "false positive" in this case because it has +to conservatively assume that `some_other_query(x)` might be affected by that +changed input. + +Unfortunately it turns out that the actual queries in the compiler are full +of examples like this and small changes to the input often potentially affect +very large parts of the output binaries. As a consequence, we had to make the +change detection system smarter and more accurate. + +# Improving Accuracy: The red-green Algorithm + +The "false positives" problem can be solved by interleaving change detection +and query re-evaluation. Instead of walking the graph all the way to the +inputs when trying to find out if some cached result is still valid, we can +check if a result has *actually* changed after we were forced to re-evaluate +it. + +We call this algorithm, for better or worse, the red-green algorithm because nodes +in the dependency graph are assigned the color green if we were able to prove +that its cached result is still valid and the color red if the result has +turned out to be different after re-evaluating it. + +The meat of red-green change tracking is implemented in the try-mark-green +algorithm, that, you've guessed it, tries to mark a given node as green: + +```rust,ignore +fn try_mark_green(tcx, current_node) -> bool { + + // Fetch the inputs to `current_node`, i.e. get the nodes that the direct + // edges from `node` lead to. + let dependencies = tcx.dep_graph.get_dependencies_of(current_node); + + // Now check all the inputs for changes + for dependency in dependencies { + + match tcx.dep_graph.get_node_color(dependency) { + Green => { + // This input has already been checked before and it has not + // changed; so we can go on to check the next one + } + Red => { + // We found an input that has changed. We cannot mark + // `current_node` as green without re-running the + // corresponding query. + return false + } + Unknown => { + // This is the first time we are look at this node. Let's try + // to mark it green by calling try_mark_green() recursively. + if try_mark_green(tcx, dependency) { + // We successfully marked the input as green, on to the + // next. + } else { + // We could *not* mark the input as green. This means we + // don't know if its value has changed. In order to find + // out, we re-run the corresponding query now! + tcx.run_query_for(dependency); + + // Fetch and check the node color again. Running the query + // has forced it to either red (if it yielded a different + // result than we have in the cache) or green (if it + // yielded the same result). + match tcx.dep_graph.get_node_color(dependency) { + Red => { + // The input turned out to be red, so we cannot + // mark `current_node` as green. + return false + } + Green => { + // Re-running the query paid off! The result is the + // same as before, so this particular input does + // not invalidate `current_node`. + } + Unknown => { + // There is no way a node has no color after + // re-running the query. + panic!("unreachable") + } + } + } + } + } + } + + // If we have gotten through the entire loop, it means that all inputs + // have turned out to be green. If all inputs are unchanged, it means + // that the query result corresponding to `current_node` cannot have + // changed either. + tcx.dep_graph.mark_green(current_node); + + true +} + +// Note: The actual implementation can be found in +// src/librustc/dep_graph/graph.rs +``` + +By using red-green marking we can avoid the devastating cumulative effect of +having false positives during change detection. Whenever a query is executed +in incremental mode, we first check if its already green. If not, we run +`try_mark_green()` on it. If it still isn't green after that, then we actually +invoke the query provider to re-compute the result. + + + +# The Real World: How Persistence Makes Everything Complicated + +The sections above described the underlying algorithm for incremental +compilation but because the compiler process exits after being finished and +takes the query context with its result cache with it into oblivion, we have +persist data to disk, so the next compilation session can make use of it. +This comes with a whole new set of implementation challenges: + +- The query results cache is stored to disk, so they are not readily available + for change comparison. +- A subsequent compilation session will start off with new version of the code + that has arbitrary changes applied to it. All kinds of IDs and indices that + are generated from a global, sequential counter (e.g. `NodeId`, `DefId`, etc) + might have shifted, making the persisted results on disk not immediately + usable anymore because the same numeric IDs and indices might refer to + completely new things in the new compilation session. +- Persisting things to disk comes at a cost, so not every tiny piece of + information should be actually cached in between compilation sessions. + Fixed-sized, plain-old-data is preferred to complex things that need to run + branching code during (de-)serialization. + +The following sections describe how the compiler currently solves these issues. + +## A Question Of Stability: Bridging The Gap Between Compilation Sessions + +As noted before, various IDs (like `DefId`) are generated by the compiler in a +way that depends on the contents of the source code being compiled. ID assignment +is usually deterministic, that is, if the exact same code is compiled twice, +the same things will end up with the same IDs. However, if something +changes, e.g. a function is added in the middle of a file, there is no +guarantee that anything will have the same ID as it had before. + +As a consequence we cannot represent the data in our on-disk cache the same +way it is represented in memory. For example, if we just stored a piece +of type information like `TyKind::FnDef(DefId, &'tcx Substs<'tcx>)` (as we do +in memory) and then the contained `DefId` points to a different function in +a new compilation session we'd be in trouble. + +The solution to this problem is to find "stable" forms for IDs which remain +valid in between compilation sessions. For the most important case, `DefId`s, +these are the so-called `DefPath`s. Each `DefId` has a +corresponding `DefPath` but in place of a numeric ID, a `DefPath` is based on +the path to the identified item, e.g. `std::collections::HashMap`. The +advantage of an ID like this is that it is not affected by unrelated changes. +For example, one can add a new function to `std::collections` but +`std::collections::HashMap` would still be `std::collections::HashMap`. A +`DefPath` is "stable" across changes made to the source code while a `DefId` +isn't. + +There is also the `DefPathHash` which is just a 128-bit hash value of the +`DefPath`. The two contain the same information and we mostly use the +`DefPathHash` because it simpler to handle, being `Copy` and self-contained. + +This principle of stable identifiers is used to make the data in the on-disk +cache resilient to source code changes. Instead of storing a `DefId`, we store +the `DefPathHash` and when we deserialize something from the cache, we map the +`DefPathHash` to the corresponding `DefId` in the *current* compilation session +(which is just a simple hash table lookup). + +The `HirId`, used for identifying HIR components that don't have their own +`DefId`, is another such stable ID. It is (conceptually) a pair of a `DefPath` +and a `LocalId`, where the `LocalId` identifies something (e.g. a `hir::Expr`) +locally within its "owner" (e.g. a `hir::Item`). If the owner is moved around, +the `LocalId`s within it are still the same. + + + +## Checking Query Results For Changes: StableHash And Fingerprints + +In order to do red-green-marking we often need to check if the result of a +query has changed compared to the result it had during the previous +compilation session. There are two performance problems with this though: + +- We'd like to avoid having to load the previous result from disk just for + doing the comparison. We already computed the new result and will use that. + Also loading a result from disk will "pollute" the interners with data that + is unlikely to ever be used. +- We don't want to store each and every result in the on-disk cache. For + example, it would be wasted effort to persist things to disk that are + already available in upstream crates. + +The compiler avoids these problems by using so-called `Fingerprint`s. Each time +a new query result is computed, the query engine will compute a 128 bit hash +value of the result. We call this hash value "the `Fingerprint` of the query +result". The hashing is (and has to be) done "in a stable way". This means +that whenever something is hashed that might change in between compilation +sessions (e.g. a `DefId`), we instead hash its stable equivalent +(e.g. the corresponding `DefPath`). That's what the whole `StableHash` +infrastructure is for. This way `Fingerprint`s computed in two +different compilation sessions are still comparable. + +The next step is to store these fingerprints along with the dependency graph. +This is cheap since fingerprints are just bytes to be copied. It's also cheap to +load the entire set of fingerprints together with the dependency graph. + +Now, when red-green-marking reaches the point where it needs to check if a +result has changed, it can just compare the (already loaded) previous +fingerprint to the fingerprint of the new result. + +This approach works rather well but it's not without flaws: + +- There is a small possibility of hash collisions. That is, two different + results could have the same fingerprint and the system would erroneously + assume that the result hasn't changed, leading to a missed update. + + We mitigate this risk by using a high-quality hash function and a 128 bit + wide hash value. Due to these measures the practical risk of a hash + collision is negligible. + +- Computing fingerprints is quite costly. It is the main reason why incremental + compilation can be slower than non-incremental compilation. We are forced to + use a good and thus expensive hash function, and we have to map things to + their stable equivalents while doing the hashing. + +In the future we might want to explore different approaches to this problem. +For now it's `StableHash` and `Fingerprint`. + + + +## A Tale Of Two DepGraphs: The Old And The New + +The initial description of dependency tracking glosses over a few details +that quickly become a head scratcher when actually trying to implement things. +In particular it's easy to overlook that we are actually dealing with *two* +dependency graphs: The one we built during the previous compilation session and +the one that we are building for the current compilation session. + +When a compilation session starts, the compiler loads the previous dependency +graph into memory as an immutable piece of data. Then, when a query is invoked, +it will first try to mark the corresponding node in the graph as green. This +means really that we are trying to mark the node in the *previous* dep-graph +as green that corresponds to the query key in the *current* session. How do we +do this mapping between current query key and previous `DepNode`? The answer +is again `Fingerprint`s: Nodes in the dependency graph are identified by a +fingerprint of the query key. Since fingerprints are stable across compilation +sessions, computing one in the current session allows us to find a node +in the dependency graph from the previous session. If we don't find a node with +the given fingerprint, it means that the query key refers to something that +did not yet exist in the previous session. + +So, having found the dep-node in the previous dependency graph, we can look +up its dependencies (also dep-nodes in the previous graph) and continue with +the rest of the try-mark-green algorithm. The next interesting thing happens +when we successfully marked the node as green. At that point we copy the node +and the edges to its dependencies from the old graph into the new graph. We +have to do this because the new dep-graph cannot not acquire the +node and edges via the regular dependency tracking. The tracking system can +only record edges while actually running a query -- but running the query, +although we have the result already cached, is exactly what we want to avoid. + +Once the compilation session has finished, all the unchanged parts have been +copied over from the old into the new dependency graph, while the changed parts +have been added to the new graph by the tracking system. At this point, the +new graph is serialized out to disk, alongside the query result cache, and can +act as the previous dep-graph in a subsequent compilation session. + + +## Didn't You Forget Something?: Cache Promotion +TODO + + +# The Future: Shortcomings Of The Current System and Possible Solutions +TODO + + +[query-model]: ./query-evaluation-model-in-detail.html diff --git a/src/incremental-compilation.md b/src/queries/incremental-compilation.md similarity index 100% rename from src/incremental-compilation.md rename to src/queries/incremental-compilation.md diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index d2dc10479..41789637d 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -123,23 +123,24 @@ fn type_check_crate_provider(tcx, _key: ()) { } ``` -We see that the `type_check_crate` query accesses input data (`tcx.hir_map`) -and invokes other queries (`type_check_item`). The `type_check_item` +We see that the `type_check_crate` query accesses input data +(`tcx.hir_map.list_of_items()`) and invokes other queries +(`type_check_item`). The `type_check_item` invocations will themselves access input data and/or invoke other queries, so that in the end the DAG of query invocations will be built up backwards from the node that was initially executed: -``` - (1) - hir_map <--------------------------------------------------- type_check_crate() - ^ | - | (4) (3) (2) | - +-- Hir(foo) <--- type_of(foo) <--- type_check_item(foo) <-------+ - | | | - | +-----------------+ | - | | | - | (6) v (5) (7) | - +-- Hir(bar) <--- type_of(bar) <--- type_check_item(bar) <-------+ +```ignore + (2) (1) + list_of_all_hir_items <----------------------------- type_check_crate() + | + (5) (4) (3) | + Hir(foo) <--- type_of(foo) <--- type_check_item(foo) <-------+ + | | + +-----------------+ | + | | + (7) v (6) (8) | + Hir(bar) <--- type_of(bar) <--- type_check_item(bar) <-------+ // (x) denotes invocation order ``` diff --git a/src/query.md b/src/query.md index ee7d60e4b..703c560e0 100644 --- a/src/query.md +++ b/src/query.md @@ -37,8 +37,8 @@ compiler (for example, generating MIR) work exactly like this. ### The Query Evaluation Model in Detail -The [Query Evaluation Model in Detail](query-evaluation-model-in-detail.html) -chapter gives a more in-depth description of what queries are and how they work. +The [Query Evaluation Model in Detail][query-model] chapter gives a more +in-depth description of what queries are and how they work. If you intend to write a query of your own, this is a good read. ### Invoking queries @@ -267,3 +267,4 @@ impl<'tcx> QueryDescription for queries::type_of<'tcx> { } ``` +[query-model]: queries/query-evaluation-model-in-detail.html diff --git a/src/variance.md b/src/variance.md index 9fe98b4a1..c6a1a320b 100644 --- a/src/variance.md +++ b/src/variance.md @@ -139,7 +139,7 @@ crate (through `crate_variances`), but since most changes will not result in a change to the actual results from variance inference, the `variances_of` query will wind up being considered green after it is re-evaluated. -[rga]: ./incremental-compilation.html +[rga]: ./queries/incremental-compilation.html From 50c84d1a879d92fea22fd483666777da05abc8a2 Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Tue, 5 Feb 2019 22:46:53 -0800 Subject: [PATCH 0498/1812] `_with_applicability` methods are gone The simpler `span_suggestion` method name now takes the applicability argument, thanks to Andy Russell (rust-lang/rust@0897ffc28f6). --- src/diag.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/src/diag.md b/src/diag.md index 9a8020314..cfdd82aa2 100644 --- a/src/diag.md +++ b/src/diag.md @@ -85,11 +85,11 @@ Server][rls] and [`rustfix`][rustfix]. [rustfix]: https://github.com/rust-lang-nursery/rustfix Not all suggestions should be applied mechanically. Use the -[`span_suggestion_with_applicability`][sswa] method of `DiagnosticBuilder` to -make a suggestion while providing a hint to tools whether the suggestion is -mechanically applicable or not. +[`span_suggestion`][span_suggestion] method of `DiagnosticBuilder` to +make a suggestion. The last argument provides a hint to tools whether +the suggestion is mechanically applicable or not. -[sswa]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html#method.span_suggestion_with_applicability +[span_suggestion]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html#method.span_suggestion For example, to make our `qux` suggestion machine-applicable, we would do: @@ -97,8 +97,7 @@ For example, to make our `qux` suggestion machine-applicable, we would do: let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); if let Ok(snippet) = sess.source_map().span_to_snippet(sp) { - // Add applicability info! - err.span_suggestion_with_applicability( + err.span_suggestion( suggestion_sp, "try using a qux here", format!("qux {}", snip), @@ -145,7 +144,7 @@ error: aborting due to previous error For more information about this error, try `rustc --explain E0999`. ``` -There are a few other [`Applicability`][appl] possibilities: +The possible values of [`Applicability`][appl] are: - `MachineApplicable`: Can be applied mechanically. - `HasPlaceholders`: Cannot be applied mechanically because it has placeholder From d94a06dd52760b83ec98ff3ba86fa8c47a062d5f Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 13:56:40 +0000 Subject: [PATCH 0499/1812] Add "lang item" to glossary --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index a35008053..a2effc7fc 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -34,6 +34,7 @@ inference variable | when doing type or region inference, an "inference va infcx | the inference context (see `librustc/infer`) IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). +lang item | items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) local crate | the crate currently being compiled. LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. From 7ef92b9bb658819e50feb79e3d586e3d0f87bcc7 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 13:59:59 +0000 Subject: [PATCH 0500/1812] Add "item" to glossary --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index a2effc7fc..3ceef9344 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -34,6 +34,7 @@ inference variable | when doing type or region inference, an "inference va infcx | the inference context (see `librustc/infer`) IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). +item | a kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. lang item | items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) local crate | the crate currently being compiled. LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] From ee661e8d61dbcc5065ed59eabfab0154c00c1f06 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:03:39 +0000 Subject: [PATCH 0501/1812] Add "early-bound lifetime" and "late-bound lifetime" to the glossary --- src/appendix/glossary.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 3ceef9344..3b4df535d 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -20,6 +20,7 @@ data-flow analysis | a static analysis that figures out what properties ar DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. Double pointer | a pointer with additional metadata. See "fat pointer" for more. DST | Dynamically-Sized Type. A type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). +early-bound lifetime | a lifetime region, which is bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) empty type | see "uninhabited type". Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) @@ -36,6 +37,7 @@ IR | Intermediate Representation. A general term in compil IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). item | a kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. lang item | items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) +late-bound lifetime | a lifetime region, which is bound in a HRTB and substituted with specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) local crate | the crate currently being compiled. LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. From 50bcd366db07b54f20cef36fb9e40654d5033a41 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:09:49 +0000 Subject: [PATCH 0502/1812] Add "intern" to the glossary --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 3b4df535d..32171a374 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -33,6 +33,7 @@ ICE | internal compiler error. When the compiler crashes. ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. inference variable | when doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. infcx | the inference context (see `librustc/infer`) +intern | interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage. IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). item | a kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. From f420e427c7b31364b01226fa768e12d8b741bd53 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:11:56 +0000 Subject: [PATCH 0503/1812] Add "memoise" to the glossary --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 32171a374..3f10d731d 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -42,6 +42,7 @@ late-bound lifetime | a lifetime region, which is bound in a HRTB and subst local crate | the crate currently being compiled. LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. +memoise | memoisation is the process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is generally a trade-off between execution speed and memory usage. MIR | the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](../mir/index.html)) miri | an interpreter for MIR used for constant evaluation ([see more](../miri.html)) normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize) From de2ab38ddbf6572befebc22ce240cc72216698c9 Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:15:41 +0000 Subject: [PATCH 0504/1812] Add "drop glue" to the glossary --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 3f10d731d..86a128efb 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -19,6 +19,7 @@ DAG | a directed acyclic graph is used during compilation t data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow) DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. Double pointer | a pointer with additional metadata. See "fat pointer" for more. +drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. DST | Dynamically-Sized Type. A type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). early-bound lifetime | a lifetime region, which is bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) empty type | see "uninhabited type". From 7cc2afab20d1d729fa95cb62eb585b99153ff59b Mon Sep 17 00:00:00 2001 From: varkor Date: Thu, 5 Apr 2018 11:49:38 +0100 Subject: [PATCH 0505/1812] Add preliminary chapter on kinds --- src/SUMMARY.md | 1 + src/kinds.md | 31 +++++++++++++++++++++++++++++++ src/ty.md | 6 ++++-- 3 files changed, 36 insertions(+), 2 deletions(-) create mode 100644 src/kinds.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 091860e9a..b27114f1e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -38,6 +38,7 @@ - [The HIR (High-level IR)](./hir.md) - [Lowering AST to HIR](./lowering.md) - [The `ty` module: representing types](./ty.md) +- [Kinds](./kinds.md) - [Type inference](./type-inference.md) - [Trait solving (old-style)](./traits/resolution.md) - [Higher-ranked trait bounds](./traits/hrtb.md) diff --git a/src/kinds.md b/src/kinds.md new file mode 100644 index 000000000..d811423a8 --- /dev/null +++ b/src/kinds.md @@ -0,0 +1,31 @@ +# Kinds +A `ty::subst::Kind<'tcx>` represents some entity in the type system: currently +either a type (`Ty<'tcx>`) or a lifetime (`ty::Region<'tcx>`), though in the +future this will also include constants (`ty::Const<'tcx>`) to facilitate the +use of const generics. `Kind` is used for type and lifetime substitution (from +abstract type and lifetime parameters to concrete types and lifetimes). + +## `UnpackedKind` +As `Kind` itself is not type-safe (see [`Kind`](#kind)), the `UnpackedKind` enum +provides a more convenient and safe interface for dealing with kinds. To +convert from an `UnpackedKind` to a `Kind`, you can call `Kind::from` (or +`.into`). It should not be necessary to convert a `Kind` to an `UnpackedKind`: +instead, you should prefer to deal with `UnpackedKind`, converting it only when +passing it to `Subst` methods. + +## `Kind` +The actual `Kind` struct is optimised for space, storing the type or lifetime +as an interned pointer containing a mask identifying its kind (in the lowest +2 bits). + +## `Subst` +`ty::subst::Subst<'tcx>` is simply defined as a slice of `Kind<'tcx>`s +and acts as an ordered list of substitutions from kind parameters (i.e. +type and lifetime parameters) to kinds. + +For example, given a `HashMap` with two type parameters, `K` and `V`, an +instantiation of the parameters, for example `HashMap`, would be +represented by the substitution `&'tcx [tcx.types.i32, tcx.types.u32]`. + +`Subst` provides various convenience methods to instantiant substitutions +given item definitions. diff --git a/src/ty.md b/src/ty.md index fea9afbeb..d9979bc0b 100644 --- a/src/ty.md +++ b/src/ty.md @@ -141,8 +141,8 @@ In addition to types, there are a number of other arena-allocated data structures that you can allocate, and which are found in this module. Here are a few examples: -- `Substs`, allocated with `mk_substs` – this will intern a slice of types, - often used to specify the values to be substituted for generics +- [`Substs`][subst], allocated with `mk_substs` – this will intern a slice of + types, often used to specify the values to be substituted for generics (e.g. `HashMap` would be represented as a slice `&'tcx [tcx.types.i32, tcx.types.u32]`). - `TraitRef`, typically passed by value – a **trait reference** @@ -153,6 +153,8 @@ module. Here are a few examples: - `Predicate` defines something the trait system has to prove (see `traits` module). +[subst]: ./kinds.html#subst + ### Import conventions Although there is no hard and fast rule, the `ty` module tends to be used like From 99d47b84c6841c43559f4d47d485eeceabe0ebdd Mon Sep 17 00:00:00 2001 From: varkor Date: Sat, 16 Feb 2019 14:38:15 +0000 Subject: [PATCH 0506/1812] Add more information and an example to Kind chapter --- src/kinds.md | 62 +++++++++++++++++++++++++++++++++------------------- 1 file changed, 40 insertions(+), 22 deletions(-) diff --git a/src/kinds.md b/src/kinds.md index d811423a8..bd483c868 100644 --- a/src/kinds.md +++ b/src/kinds.md @@ -1,31 +1,49 @@ # Kinds -A `ty::subst::Kind<'tcx>` represents some entity in the type system: currently -either a type (`Ty<'tcx>`) or a lifetime (`ty::Region<'tcx>`), though in the -future this will also include constants (`ty::Const<'tcx>`) to facilitate the -use of const generics. `Kind` is used for type and lifetime substitution (from -abstract type and lifetime parameters to concrete types and lifetimes). - -## `UnpackedKind` -As `Kind` itself is not type-safe (see [`Kind`](#kind)), the `UnpackedKind` enum -provides a more convenient and safe interface for dealing with kinds. To -convert from an `UnpackedKind` to a `Kind`, you can call `Kind::from` (or -`.into`). It should not be necessary to convert a `Kind` to an `UnpackedKind`: -instead, you should prefer to deal with `UnpackedKind`, converting it only when -passing it to `Subst` methods. - -## `Kind` -The actual `Kind` struct is optimised for space, storing the type or lifetime -as an interned pointer containing a mask identifying its kind (in the lowest -2 bits). +A `ty::subst::Kind<'tcx>` represents some entity in the type system: a type +(`Ty<'tcx>`), lifetime (`ty::Region<'tcx>`) or constant (`ty::Const<'tcx>`). +`Kind` is used to perform substitutions of generic parameters for concrete +arguments, such as when calling a function with generic parameters explicitly +with type arguments. Substitutions are represented using the +[`Subst` type](#subst) as described below. ## `Subst` -`ty::subst::Subst<'tcx>` is simply defined as a slice of `Kind<'tcx>`s -and acts as an ordered list of substitutions from kind parameters (i.e. -type and lifetime parameters) to kinds. +`ty::subst::Subst<'tcx>` is intuitively simply a slice of `Kind<'tcx>`s, +acting as an ordered list of substitutions from generic parameters to +concrete arguments (such as types, lifetimes and consts). For example, given a `HashMap` with two type parameters, `K` and `V`, an instantiation of the parameters, for example `HashMap`, would be represented by the substitution `&'tcx [tcx.types.i32, tcx.types.u32]`. `Subst` provides various convenience methods to instantiant substitutions -given item definitions. +given item definitions, which should generally be used rather than explicitly +constructing such substitution slices. + +## `Kind` +The actual `Kind` struct is optimised for space, storing the type, lifetime or +const as an interned pointer containing a mask identifying its kind (in the +lowest 2 bits). Unless you are working with the `Subst` implementation +specifically, you should generally not have to deal with `Kind` and instead +make use of the safe [`UnpackedKind`](#unpackedkind) abstraction. + +## `UnpackedKind` +As `Kind` itself is not type-safe, the `UnpackedKind` enum provides a more +convenient and safe interface for dealing with kinds. An `UnpackedKind` can +be converted to a raw `Kind` using `Kind::from()` (or simply `.into()` when +the context is clear). As mentioned earlier, substition lists store raw +`Kind`s, so before dealing with them, it is preferable to convert them to +`UnpackedKind`s first. This is done by calling the `.unpack()` method. + +```rust +// An example of unpacking and packing a kind. +fn deal_with_kind<'tcx>(kind: Kind<'tcx>) -> Kind<'tcx> { + // Unpack a raw `Kind` to deal with it safely. + let new_kind: UnpackedKind<'tcx> = match kind.unpack() { + UnpackedKind::Type(ty) => { /* ... */ } + UnpackedKind::Lifetime(lt) => { /* ... */ } + UnpackedKind::Const(ct) => { /* ... */ } + }; + // Pack the `UnpackedKind` to store it in a substitution list. + new_kind.into() +} +``` From d911ba15a245da5dbe855b84707a40f4326af949 Mon Sep 17 00:00:00 2001 From: varkor Date: Mon, 18 Feb 2019 22:57:57 +0000 Subject: [PATCH 0507/1812] Ignore Rust snippet --- src/kinds.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/kinds.md b/src/kinds.md index bd483c868..d5e218c31 100644 --- a/src/kinds.md +++ b/src/kinds.md @@ -34,7 +34,7 @@ the context is clear). As mentioned earlier, substition lists store raw `Kind`s, so before dealing with them, it is preferable to convert them to `UnpackedKind`s first. This is done by calling the `.unpack()` method. -```rust +```rust,ignore // An example of unpacking and packing a kind. fn deal_with_kind<'tcx>(kind: Kind<'tcx>) -> Kind<'tcx> { // Unpack a raw `Kind` to deal with it safely. From 10fb45ee27437b326d04019398fa4add01f4d15d Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Tue, 19 Feb 2019 00:15:07 +0000 Subject: [PATCH 0508/1812] Small clarifications to glossary definitions --- src/appendix/glossary.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 86a128efb..a5d5bf56a 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -21,7 +21,7 @@ DefId | an index identifying a definition (see `librustc/hir/ Double pointer | a pointer with additional metadata. See "fat pointer" for more. drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. DST | Dynamically-Sized Type. A type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). -early-bound lifetime | a lifetime region, which is bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) +early-bound lifetime | a lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) empty type | see "uninhabited type". Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) @@ -39,11 +39,11 @@ IR | Intermediate Representation. A general term in compil IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). item | a kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. lang item | items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) -late-bound lifetime | a lifetime region, which is bound in a HRTB and substituted with specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) +late-bound lifetime | a lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) local crate | the crate currently being compiled. LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. -memoise | memoisation is the process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is generally a trade-off between execution speed and memory usage. +memoize | memoization is the process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. MIR | the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](../mir/index.html)) miri | an interpreter for MIR used for constant evaluation ([see more](../miri.html)) normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize) From f59ed9dbc52f118199704f320c98fd53271d2e04 Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Thu, 7 Feb 2019 22:45:01 -0500 Subject: [PATCH 0509/1812] issue_130_7 implementing new features --- src/SUMMARY.md | 1 + src/implementing_new_feature.md | 135 ++++++++++++++++++++++++++++++++ 2 files changed, 136 insertions(+) create mode 100644 src/implementing_new_feature.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b27114f1e..723608da9 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -14,6 +14,7 @@ - [Adding new tests](./tests/adding.md) - [Using `compiletest` + commands to control test execution](./compiletest.md) - [Walkthrough: a typical contribution](./walkthrough.md) +- [Implementing new feature](./implementing_new_feature.md) - [Stabilizing Features](./stabilization_guide.md) - [Debugging the Compiler](./compiler-debugging.md) - [Profiling the compiler](./profiling.md) diff --git a/src/implementing_new_feature.md b/src/implementing_new_feature.md new file mode 100644 index 000000000..2bc65e145 --- /dev/null +++ b/src/implementing_new_feature.md @@ -0,0 +1,135 @@ +# Implement New Feature + +When you want to implement a new significant feature in the compiler, you need to go through this process to make sure everything goes smoothly. + +## The @rfcbot (p)FCP process + +When the change is small and uncontroversial, then it can be done +with just writing a PR and getting r+ from someone who knows that part of the code. However, if the change is potentially controversial, it would be a bad idea to push it without onsensus from the rest of the team (both in the "distributed system" sense to make sure you don't break anything you don't know about, and in the social sense to avoid PR fights). + +If such a change seems to small to require a full formal RFC process (e.g. a big refactoring of the code, or a "technically-breaking" change, or a "big bugfix" that basically amounts to a small feature) but is still too controversial or big to get by with a single r+, you can start a pFCP (or, if you don't have r+ rights, ask someone who has them to start one - and unless they have a concern themselves, they should). + +Again, the pFCP process is only needed if you need consensus - if you don't think anyone would have a problem with your change, it's ok to get by with only an r+. For example, it is OK to add or modify unstable command-line flags or attributes without an pFCP for compiler development or standard library use, as long as you don't expect them to be in wide use in the nightly ecosystem. + +Rust community is trying to find a better process for iterating on features on nightly, but if you are trying to write a feature that is not too bikesheddy, you could try to ask for an pFCP to land it on nightly under a feature gate. That might work out. However, some team-member might still tell you to go write an actual RFC (however, someone still needs to write an RFC before that feature is stabilized). + +You don't have to have the implementation fully ready for r+ to ask for a pFCP, but it is generally a good idea to have at least a proof of concept so that people can see what you are talking about. + +That starts a "proposed final comment period" (pFCP), which requires all members of the team to sign off the FCP. After they all do so, there's a week long "final comment period" where everybody can comment, and if no new concerns are raised, the PR/issue gets FCP approval. + +After an PR/issue had got FCP approval, team-members should help along attempts to implement it, and not block r+ on the controversy that prompted the FCP. If significant new issues arise after FCP approval, then it is ok to re-block the PR until these are resolved. + +For teams and team members: Even if someone is trying to paint the bikeshed your least favorite color, teams and team members should help them move along. Don't be a slow reviewer. + +## A few etiquette notes about (p)FCPs + +FCPs are a place where people unfamiliar with the Rust teams and process interact with the design process. This means that it is extra important for communication to be clear there. Don't assume the PR's writer knows when the next lang team meeting is. + +pFCP checkbox ticking is not supposed to be a place where PRs stall due to low priority - it is supposed to quickly either reach consensus or find a concern. If there is no real obstacle to consensus on the issue, the relevant team should sign off the PFCP reasonably quickly (a week or two). + +Teams: please review pFCP items during the team meetings to make sure this happens. If you find a real concern, please post a summary on the issue, even if you already discussed it on the team IRC channel, or worse, at a late-hours in-person meeting. + +If you think a pFCP item requires further design work which you are too busy to do right now, please say so on the issue/PR thread. This might appear rude, but it's less rude than leaving a PR accumulating bitrot for 2 months because you have no idea what to do with it. + +## How to technically run a pFCP + +pFCPs are run using the @rfcbot bot. For more details about how to correctly use rfcbot, see [the rfcbot guide], but the gist of it is that someone with privileges first tags your issue with a list of teams, and then someone writes this command in a comment in the issue thread: + +```rust, ignore + @rfcbot fcp merge +``` + +or + +```rust, ignore + @rfcbot fcp close +``` + +That will cause rfcbot to comment its ticky-box comment. + +## The logistics of writing features + +There are a few "logistic" hoops you might need to go through in order to implement a feature in a working way. +The more boring details are listed in the Rust repository's [CONTRIBUTING.md], so I'll just link to it here. You should try to at least skim it fully - it contains a bunch of nice tips. + +### Warning Cycles + +In some cases, a feature or bugfix might break some existing programs in some edge cases. In that case, you might want to do a crater run to assess the impact and possibly add a warning cycle, following the [rustc bug-fix procedure]. + +### Stability + +We [value the stability of Rust]. Code that works and runs on stable should (mostly) not break. Because of that, we don't want to release a feature to the world with only team consensus and code review - we want to gain real-world experience on using that feature on nightly, and we might want to change the feature based on that experience. + +To allow for that, we must make sure users don't accidentally depend on that new feature - otherwise, especially if experimentation takes time or is delayed and the feature takes the trains to stable, it would end up de facto stable and we'll not be able to make changes in it without breaking people's code. + +The way we do that is that we make sure all new features are feature gated - they can't be used without a enabling a feature gate (#[feature(foo)]), which can't be done in a stable/beta compiler. See the [stability in code] section for the technical details. + +Eventually, after we gain enough experience using the feature, make the necessary changes, and are satisfied, we expose it to the world using the stabilization process described [here]. Until then, the feature is not set in stone: every part of the feature can be changed, or the feature might be completely rewritten or removed. Features are not supposed to gain tenure by being unstable and unchanged for a year. + +### Tracking Issues + +To keep track of the status of an unstable feature, the experience we get while using it on nightly, and of the concerns that block its stabilization, every feature-gate needs a tracking issue. + +General discussions about the feature should be done on the tracking issue. + +For features that have an RFC, you should use the RFC's tracking issue for the feature. + +For other features, you'll have to make a tracking issue for that feature. The issue title should be "Tracking issue for YOUR FEATURE" and it should have the `B-unstable` & `C-tracking-issue` tags, along with the tag for your subteam (e.g. `T-compiler` if this is a compiler feature). + +For tracking issues for features (as opposed to future-compat warnings), I don't think the description has to contain anything specific. Generally we put the list of items required for stabilization using a github list, e.g. + +```bash, ignore + **Steps:** + + - [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?) + - [ ] Adjust documentation ([see instructions on forge][doc-guide]) + - Note: no stabilization step here. +``` + +## Stability in code + +The below steps needs to be followed in order to implement a new unstable feature: + +1. Open a [tracking issue] - if you have an RFC, you can use the tracking issue for the RFC. + +2. Pick a name for the feature gate (for RFCs, use the name in the RFC). + +3. Add a feature gate declaration to `libsyntax/feature_gate.rs` In the active `declare_features` block: + +```rust,ignore + // description of feature + (active, $feature_name, "$current_nightly_version", Some($tracking_issue_number), $edition) +``` + +where `$edition` has the type `Option`, and is typically just `None`. +For example: + +```rust,ignore + // allow '|' at beginning of match arms (RFC 1925) +( active, match_beginning_vert, "1.21.0", Some(44101), None), +``` + +The current version is not actually important – the important version is when you are stabilizing a feature. + +4. Prevent usage of the new feature unless the feature gate is set. + +You can check it in most places in the compiler using the expression `tcx.features().$feature_name` (or `sess.features_untracked().borrow().$feature_name` if the tcx is unavailable) + +If the feature gate is not set, you should either maintain the pre-feature behavior or raise an error, depending on what makes sense. + +5. Add a test to ensure the feature cannot be used without a feature gate, by creating `feature-gate-$feature_name.rs` and `feature-gate-$feature_name.stderr` files under the `src/test/ui/feature-gates` directory. + +6. Add a section to the unstable book, in `src/doc/unstable-book/src/language-features/$feature_name.md`. + +7. Write a lots of tests for the new feature. PRs without tests will not be accepted! + +8. Get your PR reviewed and land it. You have now successfully implemented a feature in Rust! + +[the rfcbot guide]: https://github.com/anp/rfcbot-rs/blob/master/CONDUCT.md +[CONTRIBUTING.md]: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md +[rustc bug-fix procedure]: +https://github.com/rust-lang/rust-forge/blob/master/rustc-bug-fix-procedure.md +[value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md +[stability in code]: +[here]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html +[tracking issue]: \ No newline at end of file From 08522e27ec3a6395968f4172872d628e3444ff88 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:55:34 -0500 Subject: [PATCH 0510/1812] Update src/SUMMARY.md Co-Authored-By: rajcspsg --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 723608da9..0761e734d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -14,7 +14,7 @@ - [Adding new tests](./tests/adding.md) - [Using `compiletest` + commands to control test execution](./compiletest.md) - [Walkthrough: a typical contribution](./walkthrough.md) -- [Implementing new feature](./implementing_new_feature.md) +- [Implementing new features](./implementing_new_feature.md) - [Stabilizing Features](./stabilization_guide.md) - [Debugging the Compiler](./compiler-debugging.md) - [Profiling the compiler](./profiling.md) From c9df17bd536699ea10d20321e647bceff8ddf4f2 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:57:01 -0500 Subject: [PATCH 0511/1812] Update src/implementing_new_feature.md Co-Authored-By: rajcspsg --- src/implementing_new_feature.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/implementing_new_feature.md b/src/implementing_new_feature.md index 2bc65e145..d787954da 100644 --- a/src/implementing_new_feature.md +++ b/src/implementing_new_feature.md @@ -78,7 +78,7 @@ For other features, you'll have to make a tracking issue for that feature. The i For tracking issues for features (as opposed to future-compat warnings), I don't think the description has to contain anything specific. Generally we put the list of items required for stabilization using a github list, e.g. -```bash, ignore +```txt **Steps:** - [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?) @@ -132,4 +132,4 @@ https://github.com/rust-lang/rust-forge/blob/master/rustc-bug-fix-procedure.md [value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md [stability in code]: [here]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html -[tracking issue]: \ No newline at end of file +[tracking issue]: From 04995a5ad0888b69df998308ba61c4b5e5b99b26 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:57:26 -0500 Subject: [PATCH 0512/1812] Update src/implementing_new_feature.md Co-Authored-By: rajcspsg --- src/implementing_new_feature.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/implementing_new_feature.md b/src/implementing_new_feature.md index d787954da..20c250527 100644 --- a/src/implementing_new_feature.md +++ b/src/implementing_new_feature.md @@ -113,7 +113,7 @@ The current version is not actually important – the important version is when 4. Prevent usage of the new feature unless the feature gate is set. -You can check it in most places in the compiler using the expression `tcx.features().$feature_name` (or `sess.features_untracked().borrow().$feature_name` if the tcx is unavailable) + You can check it in most places in the compiler using the expression `tcx.features().$feature_name` (or `sess.features_untracked().borrow().$feature_name` if the tcx is unavailable) If the feature gate is not set, you should either maintain the pre-feature behavior or raise an error, depending on what makes sense. From 4a53240fb4d18231486fa409fd089367b8a6d242 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:58:01 -0500 Subject: [PATCH 0513/1812] Update src/implementing_new_feature.md Co-Authored-By: rajcspsg --- src/implementing_new_feature.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/implementing_new_feature.md b/src/implementing_new_feature.md index 20c250527..2344ab6f9 100644 --- a/src/implementing_new_feature.md +++ b/src/implementing_new_feature.md @@ -115,7 +115,7 @@ The current version is not actually important – the important version is when You can check it in most places in the compiler using the expression `tcx.features().$feature_name` (or `sess.features_untracked().borrow().$feature_name` if the tcx is unavailable) -If the feature gate is not set, you should either maintain the pre-feature behavior or raise an error, depending on what makes sense. + If the feature gate is not set, you should either maintain the pre-feature behavior or raise an error, depending on what makes sense. 5. Add a test to ensure the feature cannot be used without a feature gate, by creating `feature-gate-$feature_name.rs` and `feature-gate-$feature_name.stderr` files under the `src/test/ui/feature-gates` directory. From e15b26b349f436c5390ee0616caa85cf1f44c9f7 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 12:58:38 -0500 Subject: [PATCH 0514/1812] Update src/implementing_new_feature.md Co-Authored-By: rajcspsg --- src/implementing_new_feature.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/implementing_new_feature.md b/src/implementing_new_feature.md index 2344ab6f9..ff26b8550 100644 --- a/src/implementing_new_feature.md +++ b/src/implementing_new_feature.md @@ -54,7 +54,7 @@ The more boring details are listed in the Rust repository's [CONTRIBUTING.md], s ### Warning Cycles -In some cases, a feature or bugfix might break some existing programs in some edge cases. In that case, you might want to do a crater run to assess the impact and possibly add a warning cycle, following the [rustc bug-fix procedure]. +In some cases, a feature or bugfix might break some existing programs in some edge cases. In that case, you might want to do a crater run to assess the impact and possibly add a future-compatibility lint, similar to those used for [edition-gated lints](./diag.md#edition-gated-lints). ### Stability From c0a6e0b49b0027a7f6148ff9fc72f09d45dcba0f Mon Sep 17 00:00:00 2001 From: Rajkumar Natarajan Date: Wed, 20 Feb 2019 15:04:32 -0500 Subject: [PATCH 0515/1812] issue_130_7 updated with review comments --- src/SUMMARY.md | 2 +- src/implementing_new_feature.md | 135 ------------------------ src/implementing_new_features.md | 171 +++++++++++++++++++++++++++++++ 3 files changed, 172 insertions(+), 136 deletions(-) delete mode 100644 src/implementing_new_feature.md create mode 100644 src/implementing_new_features.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 0761e734d..3ce74a4e5 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -14,7 +14,7 @@ - [Adding new tests](./tests/adding.md) - [Using `compiletest` + commands to control test execution](./compiletest.md) - [Walkthrough: a typical contribution](./walkthrough.md) -- [Implementing new features](./implementing_new_feature.md) +- [Implementing new features](./implementing_new_features.md) - [Stabilizing Features](./stabilization_guide.md) - [Debugging the Compiler](./compiler-debugging.md) - [Profiling the compiler](./profiling.md) diff --git a/src/implementing_new_feature.md b/src/implementing_new_feature.md deleted file mode 100644 index ff26b8550..000000000 --- a/src/implementing_new_feature.md +++ /dev/null @@ -1,135 +0,0 @@ -# Implement New Feature - -When you want to implement a new significant feature in the compiler, you need to go through this process to make sure everything goes smoothly. - -## The @rfcbot (p)FCP process - -When the change is small and uncontroversial, then it can be done -with just writing a PR and getting r+ from someone who knows that part of the code. However, if the change is potentially controversial, it would be a bad idea to push it without onsensus from the rest of the team (both in the "distributed system" sense to make sure you don't break anything you don't know about, and in the social sense to avoid PR fights). - -If such a change seems to small to require a full formal RFC process (e.g. a big refactoring of the code, or a "technically-breaking" change, or a "big bugfix" that basically amounts to a small feature) but is still too controversial or big to get by with a single r+, you can start a pFCP (or, if you don't have r+ rights, ask someone who has them to start one - and unless they have a concern themselves, they should). - -Again, the pFCP process is only needed if you need consensus - if you don't think anyone would have a problem with your change, it's ok to get by with only an r+. For example, it is OK to add or modify unstable command-line flags or attributes without an pFCP for compiler development or standard library use, as long as you don't expect them to be in wide use in the nightly ecosystem. - -Rust community is trying to find a better process for iterating on features on nightly, but if you are trying to write a feature that is not too bikesheddy, you could try to ask for an pFCP to land it on nightly under a feature gate. That might work out. However, some team-member might still tell you to go write an actual RFC (however, someone still needs to write an RFC before that feature is stabilized). - -You don't have to have the implementation fully ready for r+ to ask for a pFCP, but it is generally a good idea to have at least a proof of concept so that people can see what you are talking about. - -That starts a "proposed final comment period" (pFCP), which requires all members of the team to sign off the FCP. After they all do so, there's a week long "final comment period" where everybody can comment, and if no new concerns are raised, the PR/issue gets FCP approval. - -After an PR/issue had got FCP approval, team-members should help along attempts to implement it, and not block r+ on the controversy that prompted the FCP. If significant new issues arise after FCP approval, then it is ok to re-block the PR until these are resolved. - -For teams and team members: Even if someone is trying to paint the bikeshed your least favorite color, teams and team members should help them move along. Don't be a slow reviewer. - -## A few etiquette notes about (p)FCPs - -FCPs are a place where people unfamiliar with the Rust teams and process interact with the design process. This means that it is extra important for communication to be clear there. Don't assume the PR's writer knows when the next lang team meeting is. - -pFCP checkbox ticking is not supposed to be a place where PRs stall due to low priority - it is supposed to quickly either reach consensus or find a concern. If there is no real obstacle to consensus on the issue, the relevant team should sign off the PFCP reasonably quickly (a week or two). - -Teams: please review pFCP items during the team meetings to make sure this happens. If you find a real concern, please post a summary on the issue, even if you already discussed it on the team IRC channel, or worse, at a late-hours in-person meeting. - -If you think a pFCP item requires further design work which you are too busy to do right now, please say so on the issue/PR thread. This might appear rude, but it's less rude than leaving a PR accumulating bitrot for 2 months because you have no idea what to do with it. - -## How to technically run a pFCP - -pFCPs are run using the @rfcbot bot. For more details about how to correctly use rfcbot, see [the rfcbot guide], but the gist of it is that someone with privileges first tags your issue with a list of teams, and then someone writes this command in a comment in the issue thread: - -```rust, ignore - @rfcbot fcp merge -``` - -or - -```rust, ignore - @rfcbot fcp close -``` - -That will cause rfcbot to comment its ticky-box comment. - -## The logistics of writing features - -There are a few "logistic" hoops you might need to go through in order to implement a feature in a working way. -The more boring details are listed in the Rust repository's [CONTRIBUTING.md], so I'll just link to it here. You should try to at least skim it fully - it contains a bunch of nice tips. - -### Warning Cycles - -In some cases, a feature or bugfix might break some existing programs in some edge cases. In that case, you might want to do a crater run to assess the impact and possibly add a future-compatibility lint, similar to those used for [edition-gated lints](./diag.md#edition-gated-lints). - -### Stability - -We [value the stability of Rust]. Code that works and runs on stable should (mostly) not break. Because of that, we don't want to release a feature to the world with only team consensus and code review - we want to gain real-world experience on using that feature on nightly, and we might want to change the feature based on that experience. - -To allow for that, we must make sure users don't accidentally depend on that new feature - otherwise, especially if experimentation takes time or is delayed and the feature takes the trains to stable, it would end up de facto stable and we'll not be able to make changes in it without breaking people's code. - -The way we do that is that we make sure all new features are feature gated - they can't be used without a enabling a feature gate (#[feature(foo)]), which can't be done in a stable/beta compiler. See the [stability in code] section for the technical details. - -Eventually, after we gain enough experience using the feature, make the necessary changes, and are satisfied, we expose it to the world using the stabilization process described [here]. Until then, the feature is not set in stone: every part of the feature can be changed, or the feature might be completely rewritten or removed. Features are not supposed to gain tenure by being unstable and unchanged for a year. - -### Tracking Issues - -To keep track of the status of an unstable feature, the experience we get while using it on nightly, and of the concerns that block its stabilization, every feature-gate needs a tracking issue. - -General discussions about the feature should be done on the tracking issue. - -For features that have an RFC, you should use the RFC's tracking issue for the feature. - -For other features, you'll have to make a tracking issue for that feature. The issue title should be "Tracking issue for YOUR FEATURE" and it should have the `B-unstable` & `C-tracking-issue` tags, along with the tag for your subteam (e.g. `T-compiler` if this is a compiler feature). - -For tracking issues for features (as opposed to future-compat warnings), I don't think the description has to contain anything specific. Generally we put the list of items required for stabilization using a github list, e.g. - -```txt - **Steps:** - - - [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?) - - [ ] Adjust documentation ([see instructions on forge][doc-guide]) - - Note: no stabilization step here. -``` - -## Stability in code - -The below steps needs to be followed in order to implement a new unstable feature: - -1. Open a [tracking issue] - if you have an RFC, you can use the tracking issue for the RFC. - -2. Pick a name for the feature gate (for RFCs, use the name in the RFC). - -3. Add a feature gate declaration to `libsyntax/feature_gate.rs` In the active `declare_features` block: - -```rust,ignore - // description of feature - (active, $feature_name, "$current_nightly_version", Some($tracking_issue_number), $edition) -``` - -where `$edition` has the type `Option`, and is typically just `None`. -For example: - -```rust,ignore - // allow '|' at beginning of match arms (RFC 1925) -( active, match_beginning_vert, "1.21.0", Some(44101), None), -``` - -The current version is not actually important – the important version is when you are stabilizing a feature. - -4. Prevent usage of the new feature unless the feature gate is set. - - You can check it in most places in the compiler using the expression `tcx.features().$feature_name` (or `sess.features_untracked().borrow().$feature_name` if the tcx is unavailable) - - If the feature gate is not set, you should either maintain the pre-feature behavior or raise an error, depending on what makes sense. - -5. Add a test to ensure the feature cannot be used without a feature gate, by creating `feature-gate-$feature_name.rs` and `feature-gate-$feature_name.stderr` files under the `src/test/ui/feature-gates` directory. - -6. Add a section to the unstable book, in `src/doc/unstable-book/src/language-features/$feature_name.md`. - -7. Write a lots of tests for the new feature. PRs without tests will not be accepted! - -8. Get your PR reviewed and land it. You have now successfully implemented a feature in Rust! - -[the rfcbot guide]: https://github.com/anp/rfcbot-rs/blob/master/CONDUCT.md -[CONTRIBUTING.md]: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md -[rustc bug-fix procedure]: -https://github.com/rust-lang/rust-forge/blob/master/rustc-bug-fix-procedure.md -[value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md -[stability in code]: -[here]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html -[tracking issue]: diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md new file mode 100644 index 000000000..f1d501ce2 --- /dev/null +++ b/src/implementing_new_features.md @@ -0,0 +1,171 @@ +# Implement New Feature + +When you want to implement a new significant feature in the compiler, +you need to go through this process to make sure everything goes +smoothly. + +## The @rfcbot (p)FCP process + +When the change is small and uncontroversial, then it can be done +with just writing a PR and getting r+ from someone who knows that +part of the code. However, if the change is potentially controversial, +it would be a bad idea to push it without consensus from the rest +of the team (both in the "distributed system" sense to make sure +you don't break anything you don't know about, and in the social +sense to avoid PR fights). + +If such a change seems to be too small to require a full formal RFC +process (e.g. a big refactoring of the code, or a +"technically-breaking" change, or a "big bugfix" that basically +amounts to a small feature) but is still too controversial or +big to get by with a single r+, you can start a pFCP (or, if you +don't have r+ rights, ask someone who has them to start one - and +unless they have a concern themselves, they should). + +Again, the pFCP process is only needed if you need consensus - if you +don't think anyone would have a problem with your change, it's ok to +get by with only an r+. For example, it is OK to add or modify +unstable command-line flags or attributes without an pFCP for +compiler development or standard library use, as long as you don't +expect them to be in wide use in the nightly ecosystem. + +You don't need to have the implementation fully ready for r+ to ask +for a pFCP, but it is generally a good idea to have at least a proof +of concept so that people can see what you are talking about. + +That starts a "proposed final comment period" (pFCP), which requires +all members of the team to sign off the FCP. After they all do so, +there's a week long "final comment period" where everybody can comment, +and if no new concerns are raised, the PR/issue gets FCP approval. + +## The logistics of writing features + +There are a few "logistic" hoops you might need to go through in +order to implement a feature in a working way. + +### Warning Cycles + +In some cases, a feature or bugfix might break some existing programs +in some edge cases. In that case, you might want to do a crater run +to assess the impact and possibly add a future-compatibility lint, +similar to those used for +[edition-gated lints](./diag.md#edition-gated-lints). + +### Stability + +We [value the stability of Rust]. Code that works and runs on stable +should (mostly) not break. Because of that, we don't want to release +a feature to the world with only team consensus and code review - +we want to gain real-world experience on using that feature on nightly, +and we might want to change the feature based on that experience. + +To allow for that, we must make sure users don't accidentally depend +on that new feature - otherwise, especially if experimentation takes +time or is delayed and the feature takes the trains to stable, +it would end up de facto stable and we'll not be able to make changes +in it without breaking people's code. + +The way we do that is that we make sure all new features are feature +gated - they can't be used without a enabling a feature gate +`(#[feature(foo)])`, which can't be done in a stable/beta compiler. +See the [stability in code] section for the technical details. + +Eventually, after we gain enough experience using the feature, +make the necessary changes, and are satisfied, we expose it to +the world using the stabilization process described [here]. +Until then, the feature is not set in stone: every part of the +feature can be changed, or the feature might be completely +rewritten or removed. Features are not supposed to gain tenure +by being unstable and unchanged for a year. + +### Tracking Issues + +To keep track of the status of an unstable feature, the +experience we get while using it on nightly, and of the +concerns that block its stabilization, every feature-gate +needs a tracking issue. + +General discussions about the feature should be done on +the tracking issue. + +For features that have an RFC, you should use the RFC's +tracking issue for the feature. + +For other features, you'll have to make a tracking issue +for that feature. The issue title should be "Tracking issue +for YOUR FEATURE". + +For tracking issues for features (as opposed to future-compat +warnings), I don't think the description has to contain +anything specific. Generally we put the list of items required +for stabilization using a github list, e.g. + +```txt + **Steps:** + + - [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write + up mentoring instructions?) + - [ ] Adjust documentation ([see instructions on forge][doc-guide]) + - Note: no stabilization step here. +``` + +## Stability in code + +The below steps needs to be followed in order to implement +a new unstable feature: + +1. Open a [tracking issue] - + if you have an RFC, you can use the tracking issue for the RFC. + +2. Pick a name for the feature gate (for RFCs, use the name + in the RFC). + +3. Add a feature gate declaration to `libsyntax/feature_gate.rs` + in the active `declare_features` block: + +```rust,ignore + // description of feature + (active, $feature_name, "$current_nightly_version", Some($tracking_issue_number), $edition) +``` + +where `$edition` has the type `Option`, and is typically +just `None`. + +For example: + +```rust,ignore + // allow '|' at beginning of match arms (RFC 1925) +( active, match_beginning_vert, "1.21.0", Some(44101), None), +``` + +The current version is not actually important – the important +version is when you are stabilizing a feature. + +4. Prevent usage of the new feature unless the feature gate is set. + You can check it in most places in the compiler using the + expression `tcx.features().$feature_name` (or + `sess.features_untracked().borrow().$feature_name` if the + tcx is unavailable) + + If the feature gate is not set, you should either maintain + the pre-feature behavior or raise an error, depending on + what makes sense. + +5. Add a test to ensure the feature cannot be used without + a feature gate, by creating `feature-gate-$feature_name.rs` + and `feature-gate-$feature_name.stderr` files under the + `src/test/ui/feature-gates` directory. + +6. Add a section to the unstable book, in + `src/doc/unstable-book/src/language-features/$feature_name.md`. + +7. Write a lots of tests for the new feature. + PRs without tests will not be accepted! + +8. Get your PR reviewed and land it. You have now successfully + implemented a feature in Rust! + +[value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md +[stability in code]: #stability-in-code +[here]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html +[tracking issue]: #tracking-issue From 46d99ee25ae6fe1ca6a6866ac9fa262ca5e94873 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 18:02:35 -0500 Subject: [PATCH 0516/1812] Update src/implementing_new_features.md Co-Authored-By: rajcspsg --- src/implementing_new_features.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index f1d501ce2..975d10ef8 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -78,7 +78,8 @@ feature can be changed, or the feature might be completely rewritten or removed. Features are not supposed to gain tenure by being unstable and unchanged for a year. -### Tracking Issues + +### Tracking Issues To keep track of the status of an unstable feature, the experience we get while using it on nightly, and of the From 41dee19fd3c42e11224928e8db18da6f24893cf9 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 18:02:51 -0500 Subject: [PATCH 0517/1812] Update src/implementing_new_features.md Co-Authored-By: rajcspsg --- src/implementing_new_features.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 975d10ef8..44c1ce510 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -110,7 +110,8 @@ for stabilization using a github list, e.g. - Note: no stabilization step here. ``` -## Stability in code + +## Stability in code The below steps needs to be followed in order to implement a new unstable feature: From ed6f17eb43a8552526f23d01fd2a489d6943f1b3 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 20 Feb 2019 18:03:01 -0500 Subject: [PATCH 0518/1812] Update src/implementing_new_features.md Co-Authored-By: rajcspsg --- src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 44c1ce510..650d9915c 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -67,7 +67,7 @@ in it without breaking people's code. The way we do that is that we make sure all new features are feature gated - they can't be used without a enabling a feature gate -`(#[feature(foo)])`, which can't be done in a stable/beta compiler. +(`#[feature(foo)]`), which can't be done in a stable/beta compiler. See the [stability in code] section for the technical details. Eventually, after we gain enough experience using the feature, From 2ebab6532b9f5c3522d907a853672b2442d23502 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 12:35:21 -0600 Subject: [PATCH 0519/1812] Organize and finish debugging chapters --- src/SUMMARY.md | 3 + src/codegen/debugging.md | 122 +++++++++++++++++++++++++++++ src/compiler-debugging.md | 161 +++++++------------------------------- src/hir-debugging.md | 8 ++ src/mir/debugging.md | 81 +++++++++++++++++++ src/mir/passes.md | 76 ------------------ 6 files changed, 241 insertions(+), 210 deletions(-) create mode 100644 src/codegen/debugging.md create mode 100644 src/hir-debugging.md create mode 100644 src/mir/debugging.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 3ce74a4e5..dc2f46bd9 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -38,6 +38,7 @@ - [Name resolution](./name-resolution.md) - [The HIR (High-level IR)](./hir.md) - [Lowering AST to HIR](./lowering.md) + - [Debugging](./hir-debugging.md) - [The `ty` module: representing types](./ty.md) - [Kinds](./kinds.md) - [Type inference](./type-inference.md) @@ -68,6 +69,7 @@ - [MIR visitor and traversal](./mir/visitor.md) - [MIR passes: getting the MIR for a function](./mir/passes.md) - [MIR optimizations](./mir/optimizations.md) + - [Debugging](./mir/debugging.md) - [The borrow checker](./borrow_check.md) - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) @@ -78,6 +80,7 @@ - [Parameter Environments](./param_env.md) - [Code Generation](./codegen.md) - [Updating LLVM](./codegen/updating-llvm.md) + - [Debugging LLVM](./codegen/debugging.md) - [Emitting Diagnostics](./diag.md) --- diff --git a/src/codegen/debugging.md b/src/codegen/debugging.md new file mode 100644 index 000000000..acf917bd0 --- /dev/null +++ b/src/codegen/debugging.md @@ -0,0 +1,122 @@ +## Debugging LLVM + +> NOTE: If you are looking for info about code generation, please see [this +> chapter][codegen] instead. + +[codegen]: codegen.html + +This section is about debugging compiler bugs in code generation (e.g. why the +compiler generated some piece of code or crashed in LLVM). LLVM is a big +project on its own that probably needs to have its own debugging document (not +that I could find one). But here are some tips that are important in a rustc +context: + +As a general rule, compilers generate lots of information from analyzing code. +Thus, a useful first step is usually to find a minimal example. One way to do +this is to + +1. create a new crate that reproduces the issue (e.g. adding whatever crate is +at fault as a dependency, and using it from there) + +2. minimize the crate by removing external dependencies; that is, moving +everything relevant to the new crate + +3. further minimize the issue by making the code shorter (there are tools that +help with this like `creduce`) + +The official compilers (including nightlies) have LLVM assertions disabled, +which means that LLVM assertion failures can show up as compiler crashes (not +ICEs but "real" crashes) and other sorts of weird behavior. If you are +encountering these, it is a good idea to try using a compiler with LLVM +assertions enabled - either an "alt" nightly or a compiler you build yourself +by setting `[llvm] assertions=true` in your config.toml - and see whether +anything turns up. + +The rustc build process builds the LLVM tools into +`./build//llvm/bin`. They can be called directly. + +The default rustc compilation pipeline has multiple codegen units, which is +hard to replicate manually and means that LLVM is called multiple times in +parallel. If you can get away with it (i.e. if it doesn't make your bug +disappear), passing `-C codegen-units=1` to rustc will make debugging easier. + +To rustc to generate LLVM IR, you need to pass the `--emit=llvm-ir` flag. If +you are building via cargo, use the `RUSTFLAGS` environment variable (e.g. +`RUSTFLAGS='--emit=llvm-ir'`). This causes rustc to spit out LLVM IR into the +target directory. + +`cargo llvm-ir [options] path` spits out the LLVM IR for a particular function +at `path`. (`cargo install cargo-asm` installs `cargo asm` and `cargo +llvm-ir`). `--build-type=debug` emits code for debug builds. There are also +other useful options. Also, debug info in LLVM IR can clutter the output a lot: +`RUSTFLAGS="-C debuginfo=0"` is really useful. + +`RUSTFLAGS="-C save-temps"` outputs LLVM bitcode (not the same as IR) at +different stages during compilation, which is sometimes useful. One just needs +to convert the bitcode files to `.ll` files using `llvm-dis` which should be in +the target local compilation of rustc. + +If you want to play with the optimization pipeline, you can use the `opt` tool +from `./build//llvm/bin/` with the LLVM IR emitted by rustc. Note +that rustc emits different IR depending on whether `-O` is enabled, even +without LLVM's optimizations, so if you want to play with the IR rustc emits, +you should: + +```bash +$ rustc +local my-file.rs --emit=llvm-ir -O -C no-prepopulate-passes \ + -C codegen-units=1 +$ OPT=./build/$TRIPLE/llvm/bin/opt +$ $OPT -S -O2 < my-file.ll > my +``` + +If you just want to get the LLVM IR during the LLVM pipeline, to e.g. see which +IR causes an optimization-time assertion to fail, or to see when LLVM performs +a particular optimization, you can pass the rustc flag `-C +llvm-args=-print-after-all`, and possibly add `-C +llvm-args='-filter-print-funcs=EXACT_FUNCTION_NAME` (e.g. `-C +llvm-args='-filter-print-funcs=_ZN11collections3str21_$LT$impl$u20$str$GT$\ +7replace17hbe10ea2e7c809b0bE'`). + +That produces a lot of output into standard error, so you'll want to pipe that +to some file. Also, if you are using neither `-filter-print-funcs` nor `-C +codegen-units=1`, then, because the multiple codegen units run in parallel, the +printouts will mix together and you won't be able to read anything. + +If you want just the IR for a specific function (say, you want to see why it +causes an assertion or doesn't optimize correctly), you can use `llvm-extract`, +e.g. + +```bash +$ ./build/$TRIPLE/llvm/bin/llvm-extract \ + -func='_ZN11collections3str21_$LT$impl$u20$str$GT$7replace17hbe10ea2e7c809b0bE' \ + -S \ + < unextracted.ll \ + > extracted.ll +``` + +### Filing LLVM bug reports + +When filing an LLVM bug report, you will probably want some sort of minimal +working example that demonstrates the problem. The Godbolt compiler explorer is +really helpful for this. + +1. Once you have some LLVM IR for the problematic code (see above), you can +create a minimal working example with Godbolt. Go to +[gcc.godbolt.org](https://gcc.godbolt.org). + +2. Choose `LLVM-IR` as programming language. + +3. Use `llc` to compile the IR to a particular target as is: + - There are some useful flags: `-mattr` enables target features, `-march=` + selects the target, `-mcpu=` selects the CPU, etc. + - Commands like `llc -march=help` output all architectures available, which + is useful because sometimes the Rust arch names and the LLVM names do not + match. + - If you have compiled rustc yourself somewhere, in the target directory + you have binaries for `llc`, `opt`, etc. + +4. If you want to optimize the LLVM-IR, you can use `opt` to see how the LLVM + optimizations transform it. + +5. Once you have a godbolt link demonstrating the issue, it is pretty easy to + fill in an LLVM bug. diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 31f221057..714385ca0 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -1,7 +1,21 @@ # Debugging the compiler [debugging]: #debugging -Here are a few tips to debug the compiler: +This chapter contains a few tips to debug the compiler. These tips aim to be +useful no matter what you are working on. Some of the other chapters have +advice about specific parts of the compiler (e.g. the [Queries Debugging and +Testing +chapter](./incrcomp-debugging.html) or +the [LLVM Debugging chapter](./codegen/debugging.md)). + +## `-Z` flags + +The compiler has a bunch of `-Z` flags. These are unstable flags that are only +enabled on nightly. Many of them are useful for debugging. To get a full listing +of `-Z` flags, use `-Z help`. + +One useful flag is `-Z verbose`, which generally enables printing more info that +could be useful for debugging. ## Getting a backtrace [getting-a-backtrace]: #getting-a-backtrace @@ -135,6 +149,9 @@ These crates are used in compiler for logging: * [log] * [env-logger]: check the link to see the full `RUST_LOG` syntax +[log]: https://docs.rs/log/0.4.6/log/index.html +[env-logger]: https://docs.rs/env_logger/0.4.3/env_logger/ + The compiler has a lot of `debug!` calls, which print out logging information at many points. These are very useful to at least narrow down the location of a bug if not to find it entirely, or just to orient yourself as to why the @@ -189,7 +206,7 @@ I also think that in some cases just setting it will not trigger a rebuild, so if you changed it and you already have a compiler built, you might want to call `x.py clean` to force one. -### Logging etiquette +### Logging etiquette and conventions Because calls to `debug!` are removed by default, in most cases, don't worry about adding "unnecessary" calls to `debug!` and leaving them in code you @@ -197,9 +214,12 @@ commit - they won't slow down the performance of what we ship, and if they helped you pinning down a bug, they will probably help someone else with a different one. -However, there are still a few concerns that you might care about: +A loosely followed convention is to use `debug!("foo(...)")` at the _start_ of +a function `foo` and `debug!("foo: ...")` _within_ the function. Another +loosely followed convention is to use the `{:?}` format specifier for debug +logs. -### Expensive operations in logs +One thing to be **careful** of is **expensive** operations in logs. If in the module `rustc::foo` you have a statement @@ -210,9 +230,9 @@ debug!("{:?}", random_operation(tcx)); Then if someone runs a debug `rustc` with `RUST_LOG=rustc::bar`, then `random_operation()` will run. -This means that you should not put anything too expensive or likely -to crash there - that would annoy anyone who wants to use logging for their own -module. No-one will know it until someone tries to use logging to find *another* bug. +This means that you should not put anything too expensive or likely to crash +there - that would annoy anyone who wants to use logging for their own module. +No-one will know it until someone tries to use logging to find *another* bug. ## Formatting Graphviz output (.dot files) [formatting-graphviz-output]: #formatting-graphviz-output @@ -229,133 +249,6 @@ $ dot -T pdf maybe_init_suffix.dot > maybe_init_suffix.pdf $ firefox maybe_init_suffix.pdf # Or your favorite pdf viewer ``` -## Debugging LLVM -[debugging-llvm]: #debugging-llvm - -> NOTE: If you are looking for info about code generation, please see [this -> chapter][codegen] instead. - -[codegen]: codegen.html - -This section is about debugging compiler bugs in code generation (e.g. why the -compiler generated some piece of code or crashed in LLVM). LLVM is a big -project on its own that probably needs to have its own debugging document (not -that I could find one). But here are some tips that are important in a rustc -context: - -As a general rule, compilers generate lots of information from analyzing code. -Thus, a useful first step is usually to find a minimal example. One way to do -this is to - -1. create a new crate that reproduces the issue (e.g. adding whatever crate is -at fault as a dependency, and using it from there) - -2. minimize the crate by removing external dependencies; that is, moving -everything relevant to the new crate - -3. further minimize the issue by making the code shorter (there are tools that -help with this like `creduce`) - -The official compilers (including nightlies) have LLVM assertions disabled, -which means that LLVM assertion failures can show up as compiler crashes (not -ICEs but "real" crashes) and other sorts of weird behavior. If you are -encountering these, it is a good idea to try using a compiler with LLVM -assertions enabled - either an "alt" nightly or a compiler you build yourself -by setting `[llvm] assertions=true` in your config.toml - and see whether -anything turns up. - -The rustc build process builds the LLVM tools into -`./build//llvm/bin`. They can be called directly. - -The default rustc compilation pipeline has multiple codegen units, which is -hard to replicate manually and means that LLVM is called multiple times in -parallel. If you can get away with it (i.e. if it doesn't make your bug -disappear), passing `-C codegen-units=1` to rustc will make debugging easier. - -To rustc to generate LLVM IR, you need to pass the `--emit=llvm-ir` flag. If -you are building via cargo, use the `RUSTFLAGS` environment variable (e.g. -`RUSTFLAGS='--emit=llvm-ir'`). This causes rustc to spit out LLVM IR into the -target directory. - -`cargo llvm-ir [options] path` spits out the LLVM IR for a particular function -at `path`. (`cargo install cargo-asm` installs `cargo asm` and `cargo -llvm-ir`). `--build-type=debug` emits code for debug builds. There are also -other useful options. Also, debug info in LLVM IR can clutter the output a lot: -`RUSTFLAGS="-C debuginfo=0"` is really useful. - -`RUSTFLAGS="-C save-temps"` outputs LLVM bitcode (not the same as IR) at -different stages during compilation, which is sometimes useful. One just needs -to convert the bitcode files to `.ll` files using `llvm-dis` which should be in -the target local compilation of rustc. - -If you want to play with the optimization pipeline, you can use the `opt` tool -from `./build//llvm/bin/` with the LLVM IR emitted by rustc. Note -that rustc emits different IR depending on whether `-O` is enabled, even -without LLVM's optimizations, so if you want to play with the IR rustc emits, -you should: - -```bash -$ rustc +local my-file.rs --emit=llvm-ir -O -C no-prepopulate-passes \ - -C codegen-units=1 -$ OPT=./build/$TRIPLE/llvm/bin/opt -$ $OPT -S -O2 < my-file.ll > my -``` - -If you just want to get the LLVM IR during the LLVM pipeline, to e.g. see which -IR causes an optimization-time assertion to fail, or to see when LLVM performs -a particular optimization, you can pass the rustc flag `-C -llvm-args=-print-after-all`, and possibly add `-C -llvm-args='-filter-print-funcs=EXACT_FUNCTION_NAME` (e.g. `-C -llvm-args='-filter-print-funcs=_ZN11collections3str21_$LT$impl$u20$str$GT$\ -7replace17hbe10ea2e7c809b0bE'`). - -That produces a lot of output into standard error, so you'll want to pipe that -to some file. Also, if you are using neither `-filter-print-funcs` nor `-C -codegen-units=1`, then, because the multiple codegen units run in parallel, the -printouts will mix together and you won't be able to read anything. - -If you want just the IR for a specific function (say, you want to see why it -causes an assertion or doesn't optimize correctly), you can use `llvm-extract`, -e.g. - -```bash -$ ./build/$TRIPLE/llvm/bin/llvm-extract \ - -func='_ZN11collections3str21_$LT$impl$u20$str$GT$7replace17hbe10ea2e7c809b0bE' \ - -S \ - < unextracted.ll \ - > extracted.ll -``` - -### Filing LLVM bug reports - -When filing an LLVM bug report, you will probably want some sort of minimal -working example that demonstrates the problem. The Godbolt compiler explorer is -really helpful for this. - -1. Once you have some LLVM IR for the problematic code (see above), you can -create a minimal working example with Godbolt. Go to -[gcc.godbolt.org](https://gcc.godbolt.org). - -2. Choose `LLVM-IR` as programming language. - -3. Use `llc` to compile the IR to a particular target as is: - - There are some useful flags: `-mattr` enables target features, `-march=` - selects the target, `-mcpu=` selects the CPU, etc. - - Commands like `llc -march=help` output all architectures available, which - is useful because sometimes the Rust arch names and the LLVM names do not - match. - - If you have compiled rustc yourself somewhere, in the target directory - you have binaries for `llc`, `opt`, etc. - -4. If you want to optimize the LLVM-IR, you can use `opt` to see how the LLVM - optimizations transform it. - -5. Once you have a godbolt link demonstrating the issue, it is pretty easy to - fill in an LLVM bug. - -[log]: https://docs.rs/log/0.4.6/log/index.html -[env-logger]: https://docs.rs/env_logger/0.4.3/env_logger/ - ## Narrowing (Bisecting) Regressions The [cargo-bisect-rustc][bisect] tool can be used as a quick and easy way to diff --git a/src/hir-debugging.md b/src/hir-debugging.md new file mode 100644 index 000000000..bb7f541fd --- /dev/null +++ b/src/hir-debugging.md @@ -0,0 +1,8 @@ +# HIR Debugging + +The `-Zunpretty=hir-tree` flag will dump out the HIR. + +If you are trying to correlate `NodeId`s or `DefId`s with source code, the +`--pretty expanded,identified` flag may be useful. + +TODO: anything else? diff --git a/src/mir/debugging.md b/src/mir/debugging.md new file mode 100644 index 000000000..93a79076c --- /dev/null +++ b/src/mir/debugging.md @@ -0,0 +1,81 @@ +# MIR Debugging + +The `-Zdump-mir` flag can be used to dump a text representation of the MIR. The +`-Zdump-mir-graphviz` flag can be used to dump a `.dot` file that represents +MIR as a control-flow graph. + +`-Zdump-mir=F` is a handy compiler options that will let you view the MIR for +each function at each stage of compilation. `-Zdump-mir` takes a **filter** `F` +which allows you to control which functions and which passes you are +interesting in. For example: + +```bash +> rustc -Zdump-mir=foo ... +``` + +This will dump the MIR for any function whose name contains `foo`; it +will dump the MIR both before and after every pass. Those files will +be created in the `mir_dump` directory. There will likely be quite a +lot of them! + +```bash +> cat > foo.rs +fn main() { + println!("Hello, world!"); +} +^D +> rustc -Zdump-mir=main foo.rs +> ls mir_dump/* | wc -l + 161 +``` + +The files have names like `rustc.main.000-000.CleanEndRegions.after.mir`. These +names have a number of parts: + +```text +rustc.main.000-000.CleanEndRegions.after.mir + ---- --- --- --------------- ----- either before or after + | | | name of the pass + | | index of dump within the pass (usually 0, but some passes dump intermediate states) + | index of the pass + def-path to the function etc being dumped +``` + +You can also make more selective filters. For example, `main & CleanEndRegions` +will select for things that reference *both* `main` and the pass +`CleanEndRegions`: + +```bash +> rustc -Zdump-mir='main & CleanEndRegions' foo.rs +> ls mir_dump +rustc.main.000-000.CleanEndRegions.after.mir rustc.main.000-000.CleanEndRegions.before.mir +``` + +Filters can also have `|` parts to combine multiple sets of +`&`-filters. For example `main & CleanEndRegions | main & +NoLandingPads` will select *either* `main` and `CleanEndRegions` *or* +`main` and `NoLandingPads`: + +```bash +> rustc -Zdump-mir='main & CleanEndRegions | main & NoLandingPads' foo.rs +> ls mir_dump +rustc.main-promoted[0].002-000.NoLandingPads.after.mir +rustc.main-promoted[0].002-000.NoLandingPads.before.mir +rustc.main-promoted[0].002-006.NoLandingPads.after.mir +rustc.main-promoted[0].002-006.NoLandingPads.before.mir +rustc.main-promoted[1].002-000.NoLandingPads.after.mir +rustc.main-promoted[1].002-000.NoLandingPads.before.mir +rustc.main-promoted[1].002-006.NoLandingPads.after.mir +rustc.main-promoted[1].002-006.NoLandingPads.before.mir +rustc.main.000-000.CleanEndRegions.after.mir +rustc.main.000-000.CleanEndRegions.before.mir +rustc.main.002-000.NoLandingPads.after.mir +rustc.main.002-000.NoLandingPads.before.mir +rustc.main.002-006.NoLandingPads.after.mir +rustc.main.002-006.NoLandingPads.before.mir +``` + +(Here, the `main-promoted[0]` files refer to the MIR for "promoted constants" +that appeared within the `main` function.) + +TODO: anything else? diff --git a/src/mir/passes.md b/src/mir/passes.md index 7dc1249a0..a0de3ae0e 100644 --- a/src/mir/passes.md +++ b/src/mir/passes.md @@ -22,82 +22,6 @@ where we want to access the MIR for type checking or other purposes: - `optimized_mir(D)` – the final state, after all optimizations have been performed. -### Seeing how the MIR changes as the compiler executes - -`-Zdump-mir=F` is a handy compiler options that will let you view the MIR for -each function at each stage of compilation. `-Zdump-mir` takes a **filter** `F` -which allows you to control which functions and which passes you are -interesting in. For example: - -```bash -> rustc -Zdump-mir=foo ... -``` - -This will dump the MIR for any function whose name contains `foo`; it -will dump the MIR both before and after every pass. Those files will -be created in the `mir_dump` directory. There will likely be quite a -lot of them! - -```bash -> cat > foo.rs -fn main() { - println!("Hello, world!"); -} -^D -> rustc -Zdump-mir=main foo.rs -> ls mir_dump/* | wc -l - 161 -``` - -The files have names like `rustc.main.000-000.CleanEndRegions.after.mir`. These -names have a number of parts: - -```text -rustc.main.000-000.CleanEndRegions.after.mir - ---- --- --- --------------- ----- either before or after - | | | name of the pass - | | index of dump within the pass (usually 0, but some passes dump intermediate states) - | index of the pass - def-path to the function etc being dumped -``` - -You can also make more selective filters. For example, `main & CleanEndRegions` -will select for things that reference *both* `main` and the pass -`CleanEndRegions`: - -```bash -> rustc -Zdump-mir='main & CleanEndRegions' foo.rs -> ls mir_dump -rustc.main.000-000.CleanEndRegions.after.mir rustc.main.000-000.CleanEndRegions.before.mir -``` - -Filters can also have `|` parts to combine multiple sets of -`&`-filters. For example `main & CleanEndRegions | main & -NoLandingPads` will select *either* `main` and `CleanEndRegions` *or* -`main` and `NoLandingPads`: - -```bash -> rustc -Zdump-mir='main & CleanEndRegions | main & NoLandingPads' foo.rs -> ls mir_dump -rustc.main-promoted[0].002-000.NoLandingPads.after.mir -rustc.main-promoted[0].002-000.NoLandingPads.before.mir -rustc.main-promoted[0].002-006.NoLandingPads.after.mir -rustc.main-promoted[0].002-006.NoLandingPads.before.mir -rustc.main-promoted[1].002-000.NoLandingPads.after.mir -rustc.main-promoted[1].002-000.NoLandingPads.before.mir -rustc.main-promoted[1].002-006.NoLandingPads.after.mir -rustc.main-promoted[1].002-006.NoLandingPads.before.mir -rustc.main.000-000.CleanEndRegions.after.mir -rustc.main.000-000.CleanEndRegions.before.mir -rustc.main.002-000.NoLandingPads.after.mir -rustc.main.002-000.NoLandingPads.before.mir -rustc.main.002-006.NoLandingPads.after.mir -rustc.main.002-006.NoLandingPads.before.mir -``` - -(Here, the `main-promoted[0]` files refer to the MIR for "promoted constants" -that appeared within the `main` function.) - ### Implementing and registering a pass A `MirPass` is some bit of code that processes the MIR, typically – From fea9c2361fa7b25a9da9cb5030539e7ecf5abf66 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 23 Jan 2019 12:59:34 -0600 Subject: [PATCH 0520/1812] fix link --- src/codegen/debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/codegen/debugging.md b/src/codegen/debugging.md index acf917bd0..51d5a3b2c 100644 --- a/src/codegen/debugging.md +++ b/src/codegen/debugging.md @@ -3,7 +3,7 @@ > NOTE: If you are looking for info about code generation, please see [this > chapter][codegen] instead. -[codegen]: codegen.html +[codegen]: ../codegen.md This section is about debugging compiler bugs in code generation (e.g. why the compiler generated some piece of code or crashed in LLVM). LLVM is a big From 0456aaa9e197e6d3f8349bca6299becb836e4070 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 1 Mar 2019 17:02:54 -0600 Subject: [PATCH 0521/1812] update mdbook --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index 947d751b4..835f23192 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -20,5 +20,5 @@ function cargo_install() { fi } -cargo_install mdbook 0.2.2 +cargo_install mdbook 0.2.3 cargo_install mdbook-linkcheck 0.2.3 From 4013f453e51a6cf4bf83531f583f048c9cc7e6dc Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 15 Mar 2019 17:24:46 -0500 Subject: [PATCH 0522/1812] chalk has moved to rust-lang --- src/traits/chalk-overview.md | 64 ++++++++++++++++++------------------ src/traits/slg.md | 8 ++--- 2 files changed, 36 insertions(+), 36 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 59572479d..54046b22e 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -172,7 +172,7 @@ Chalk's functionality is broken up into the following crates: - `coherence`, which implements coherence rules - Also includes [chalki][chalki], chalk's REPL. -[Browse source code on GitHub](https://github.com/rust-lang-nursery/chalk) +[Browse source code on GitHub](https://github.com/rust-lang/chalk) ## Testing @@ -202,8 +202,8 @@ Likewise, lowering tests use the [`lowering_success!` and ## More Resources -* [Chalk Source Code](https://github.com/rust-lang-nursery/chalk) -* [Chalk Glossary](https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md) +* [Chalk Source Code](https://github.com/rust-lang/chalk) +* [Chalk Glossary](https://github.com/rust-lang/chalk/blob/master/GLOSSARY.md) ### Blog Posts @@ -224,34 +224,34 @@ Likewise, lowering tests use the [`lowering_success!` and [wf-checking]: ./wf.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree -[chalk]: https://github.com/rust-lang-nursery/chalk -[rustc-issues]: https://github.com/rust-lang-nursery/rustc-guide/issues +[chalk]: https://github.com/rust-lang/chalk +[rustc-issues]: https://github.com/rust-lang/rustc-guide/issues [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification -[`ProgramClause`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/enum.ProgramClause.html -[`ProgramEnvironment`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/struct.ProgramEnvironment.html -[chalk_engine]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/index.html -[chalk_ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk_ir/index.html -[chalk_parse]: https://rust-lang-nursery.github.io/chalk/doc/chalk_parse/index.html -[chalk_solve]: https://rust-lang-nursery.github.io/chalk/doc/chalk_solve/index.html -[doc-chalk]: https://rust-lang-nursery.github.io/chalk/doc/chalk/index.html -[engine-context]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/context/index.html -[rust_ir-program]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rust_ir/struct.Program.html -[rust_ir]: https://rust-lang-nursery.github.io/chalk/doc/chalk/rust_ir/index.html - -[binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 -[chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs -[chalk-test-example]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 -[chalk-test-lowering-example]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs#L8-L31 -[chalk-test-lowering]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs -[chalk-test-wf]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf/test.rs#L1 -[chalki]: https://rust-lang-nursery.github.io/chalk/doc/chalki/index.html -[clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause -[coherence-src]: https://github.com/rust-lang-nursery/chalk/blob/master/src/coherence.rs -[ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/rust_ir.rs -[rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 -[rules-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules.rs -[rules-wf-src]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf.rs -[solve_goal]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L85 -[test-lowering-macros]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test_util.rs#L21-L54 -[test-macro]: https://github.com/rust-lang-nursery/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L33 +[`ProgramClause`]: https://rust-lang.github.io/chalk/doc/chalk_ir/enum.ProgramClause.html +[`ProgramEnvironment`]: https://rust-lang.github.io/chalk/doc/chalk_ir/struct.ProgramEnvironment.html +[chalk_engine]: https://rust-lang.github.io/chalk/doc/chalk_engine/index.html +[chalk_ir]: https://rust-lang.github.io/chalk/doc/chalk_ir/index.html +[chalk_parse]: https://rust-lang.github.io/chalk/doc/chalk_parse/index.html +[chalk_solve]: https://rust-lang.github.io/chalk/doc/chalk_solve/index.html +[doc-chalk]: https://rust-lang.github.io/chalk/doc/chalk/index.html +[engine-context]: https://rust-lang.github.io/chalk/doc/chalk_engine/context/index.html +[rust_ir-program]: https://rust-lang.github.io/chalk/doc/chalk/rust_ir/struct.Program.html +[rust_ir]: https://rust-lang.github.io/chalk/doc/chalk/rust_ir/index.html + +[binders-struct]: https://github.com/rust-lang/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 +[chalk-ast]: https://github.com/rust-lang/chalk/blob/master/chalk-parse/src/ast.rs +[chalk-test-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 +[chalk-test-lowering-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs#L8-L31 +[chalk-test-lowering]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs +[chalk-test-wf]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf/test.rs#L1 +[chalki]: https://rust-lang.github.io/chalk/doc/chalki/index.html +[clause]: https://github.com/rust-lang/chalk/blob/master/GLOSSARY.md#clause +[coherence-src]: https://github.com/rust-lang/chalk/blob/master/src/coherence.rs +[ir-code]: https://github.com/rust-lang/chalk/blob/master/src/rust_ir.rs +[rules-environment]: https://github.com/rust-lang/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 +[rules-src]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules.rs +[rules-wf-src]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf.rs +[solve_goal]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L85 +[test-lowering-macros]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test_util.rs#L21-L54 +[test-macro]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L33 diff --git a/src/traits/slg.md b/src/traits/slg.md index dcddd01f5..98547575d 100644 --- a/src/traits/slg.md +++ b/src/traits/slg.md @@ -47,7 +47,7 @@ well as the various *strands*, which are basically suspended computations that may be used to find more answers. Tables are interdependent: solving one query may require solving others. -[`Forest`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/forest/struct.Forest.html +[`Forest`]: https://rust-lang.github.io/chalk/doc/chalk_engine/forest/struct.Forest.html ### Walkthrough @@ -150,7 +150,7 @@ is the subgoal after the turnstile (`:-`) that we are currently trying to prove in this strand. Initally, when a strand is first created, there is no selected subgoal. -[`ExClause`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/struct.ExClause.html +[`ExClause`]: https://rust-lang.github.io/chalk/doc/chalk_engine/struct.ExClause.html **Activating a strand.** Now that we have created the table T0 and initialized it with strands, we have to actually try and produce an answer. @@ -187,7 +187,7 @@ Here, we write `selected(L, An)` to indicate that (a) the literal `L` is the selected subgoal and (b) which answer `An` we are looking for. We start out looking for `A0`. -[`ensure_root_answer`]: https://rust-lang-nursery.github.io/chalk/doc/chalk_engine/forest/struct.Forest.html#method.ensure_root_answer +[`ensure_root_answer`]: https://rust-lang.github.io/chalk/doc/chalk_engine/forest/struct.Forest.html#method.ensure_root_answer **Processing the selected subgoal.** Next, we have to try and find an answer to this selected goal. To do that, we will u-canonicalize it @@ -297,6 +297,6 @@ more answers later on. - [Negative Reasoning in Chalk][negative-reasoning-blog] explains the need for negative reasoning, but not how the SLG solver does it -[readme]: https://github.com/rust-lang-nursery/chalk/blob/239e4ae4e69b2785b5f99e0f2b41fc16b0b4e65e/chalk-engine/src/README.md +[readme]: https://github.com/rust-lang/chalk/blob/239e4ae4e69b2785b5f99e0f2b41fc16b0b4e65e/chalk-engine/src/README.md [slg-blog]: http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/ [negative-reasoning-blog]: http://aturon.github.io/blog/2017/04/24/negative-chalk/ From e8370fda838fc29feed244d44e887b0fb613db85 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 15 Mar 2019 17:25:12 -0500 Subject: [PATCH 0523/1812] update rustc driver chapters --- src/SUMMARY.md | 2 +- src/appendix/code-index.md | 7 ++-- src/appendix/stupid-stats.md | 16 +++++---- src/rustc-driver.md | 63 +++++++++++------------------------- 4 files changed, 32 insertions(+), 56 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 6cd75c588..d3cef1a25 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -26,7 +26,7 @@ - [Part 2: How rustc works](./part-2-intro.md) - [High-level overview of the compiler source](./high-level-overview.md) -- [The Rustc Driver](./rustc-driver.md) +- [The Rustc Driver and Interface](./rustc-driver.md) - [Rustdoc](./rustdoc.md) - [Queries: demand-driven compilation](./query.md) - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index c0a1d03a9..3c71d6bba 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -7,7 +7,7 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- `BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html) -`CompileState` | struct | State that is passed to a callback at each compiler pass | [The Rustc Driver] | [src/librustc_driver/driver.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html) +`Compiler` | struct | Represents a compiler session and can be used to drive a compilation. | [The Rustc Driver and Interface] | [src/librustc_interface/interface.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html) `ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) `hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) `DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html) @@ -18,8 +18,9 @@ Item | Kind | Short description | Chapter | `P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [src/syntax/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ptr/struct.P.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) +`Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Rib.html) -`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) +`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) `SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) @@ -33,7 +34,7 @@ Item | Kind | Short description | Chapter | [The HIR]: ../hir.html [Identifiers in the HIR]: ../hir.html#hir-id [The parser]: ../the-parser.html -[The Rustc Driver]: ../rustc-driver.html +[The Rustc Driver and Interface]: ../rustc-driver.html [Type checking]: ../type-checking.html [The `ty` modules]: ../ty.html [Rustdoc]: ../rustdoc.html diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md index a36cac42b..5066973a9 100644 --- a/src/appendix/stupid-stats.md +++ b/src/appendix/stupid-stats.md @@ -1,9 +1,12 @@ # Appendix A: A tutorial on creating a drop-in replacement for rustc > **Note:** This is a copy of `@nrc`'s amazing [stupid-stats]. You should find -> a copy of the code on the GitHub repository although due to the compiler's -> constantly evolving nature, there is no guarantee it'll compile on the first -> go. +> a copy of the code on the GitHub repository. +> +> Due to the compiler's constantly evolving nature, the `rustc_driver` +> mechanisms described in this chapter have been replaced by a new +> [`rustc_interface`] crate. See [The Rustc Driver and Interface] for more +> information. Many tools benefit from being a drop-in replacement for a compiler. By this, I mean that any user of the tool can use `mytool` in all the ways they would @@ -92,7 +95,7 @@ translation). > and [`librustc_codegen_utils`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_utils/index.html). All these phases are coordinated by the driver. To see the exact sequence, look -at [the `compile_input` function in `librustc_driver`][compile-input]. +at the `compile_input` function in `librustc_driver`. The driver handles all the highest level coordination of compilation - 1. handling command-line arguments 2. maintaining compilation state (primarily in the `Session`) @@ -101,9 +104,6 @@ The driver handles all the highest level coordination of compilation - To create a drop-in compiler replacement or a compiler replacement, we leave most of compilation alone and customise the driver using its APIs. -[compile-input]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/fn.compile_input.html - - ## The driver customisation APIs There are two primary ways to customise compilation - high level control of the @@ -410,3 +410,5 @@ internally (I already changed save-analysis to use `CompilerController`). I've been experimenting with a prototype rustfmt which also uses these APIs. [stupid-stats]: https://github.com/nrc/stupid-stats +[`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html +[The Rustc Driver and Interface]: ../rustc-driver.html diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 397949836..92754f675 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -1,46 +1,25 @@ -# The Rustc Driver +# The Rustc Driver and Interface The [`rustc_driver`] is essentially `rustc`'s `main()` function. It acts as the glue for running the various phases of the compiler in the correct order, -managing state such as the [`SourceMap`] \(maps AST nodes to source code), -[`Session`] \(general build context and error messaging) and the [`TyCtxt`] -\(the "typing context", allowing you to query the type system and other cool -stuff). The `rustc_driver` crate also provides external users with a method +using the interface defined in the [`rustc_interface`] crate. + +The `rustc_interface` crate provides external users with an (unstable) API for running code at particular times during the compilation process, allowing third parties to effectively use `rustc`'s internals as a library for -analysing a crate or emulating the compiler in-process (e.g. the RLS). - -For those using `rustc` as a library, the `run_compiler()` function is the main -entrypoint to the compiler. Its main parameters are a list of command-line -arguments and a reference to something which implements the `CompilerCalls` -trait. A `CompilerCalls` creates the overall `CompileController`, letting it -govern which compiler passes are run and attach callbacks to be fired at the end -of each phase. - -From `rustc_driver`'s perspective, the main phases of the compiler are: - -1. *Parse Input:* Initial crate parsing -2. *Configure and Expand:* Resolve `#[cfg]` attributes, name resolution, and - expand macros -3. *Run Analysis Passes:* Run trait resolution, typechecking, region checking - and other miscellaneous analysis passes on the crate -4. *Translate to LLVM:* Translate to the in-memory form of LLVM IR and turn it - into an executable/object files +analysing a crate or emulating the compiler in-process (e.g. the RLS or rustdoc). -The `CompileController` then gives users the ability to inspect the ongoing -compilation process +For those using `rustc` as a library, the `interface::run_compiler()` function is the main +entrypoint to the compiler. It takes a configuration for the compiler and a closure that +takes a [`Compiler`]. `run_compiler` creates a `Compiler` from the configuration and passes +it to the closure. Inside the closure, you can use the `Compiler` to drive queries to compile +a crate and get the results. This is what the `rustc_driver` does too. -- after parsing -- after AST expansion -- after HIR lowering -- after analysis, and -- when compilation is done - -The `CompileState`'s various `state_after_*()` constructors can be inspected to -determine what bits of information are available to which callback. - -For a more detailed explanation on using `rustc_driver`, check out the -[stupid-stats] guide by `@nrc` (attached as [Appendix A]). +You can see what queries are currently available through the rustdocs for [`Compiler`]. +You can see an example of how to use them by looking at the `rustc_driver` implementation, +specifically the [`rustc_driver::run_compiler` function][rd_rc] (not to be confused with +`interface::run_compiler`). The `rustc_driver::run_compiler` function takes a bunch of +command-line args and some other configurations and drives the compilation to completion. > **Warning:** By its very nature, the internal compiler APIs are always going > to be unstable. That said, we do try not to break things unnecessarily. @@ -54,21 +33,15 @@ manifests itself in the way people can plug into the compiler, preferring a "push"-style API (callbacks) instead of the more Rust-ic "pull" style (think the `Iterator` trait). -For example the [`CompileState`], the state passed to callbacks after each -phase, is essentially just a box of optional references to pieces inside the -compiler. The lifetime bound on the `CompilerCalls` trait then helps to ensure -compiler internals don't "escape" the compiler (e.g. if you tried to keep a -reference to the AST after the compiler is finished), while still letting users -record *some* state for use after the `run_compiler()` function finishes. - Thread-local storage and interning are used a lot through the compiler to reduce duplication while also preventing a lot of the ergonomic issues due to many pervasive lifetimes. The `rustc::ty::tls` module is used to access these thread-locals, although you should rarely need to touch it. - +[rd_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.run_compiler.html +[`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/ -[`CompileState`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/driver/struct.CompileState.html +[`Compiler`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html [`Session`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html [`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html [`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html From 960ddd62214bc2dc2a6a3b77b3d8c8e9c3ad1a35 Mon Sep 17 00:00:00 2001 From: varkor Date: Thu, 14 Mar 2019 13:17:20 +0000 Subject: [PATCH 0524/1812] Fix mask -> tag terminology --- src/kinds.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/kinds.md b/src/kinds.md index d5e218c31..ac6a2d35b 100644 --- a/src/kinds.md +++ b/src/kinds.md @@ -21,7 +21,7 @@ constructing such substitution slices. ## `Kind` The actual `Kind` struct is optimised for space, storing the type, lifetime or -const as an interned pointer containing a mask identifying its kind (in the +const as an interned pointer containing a tag identifying its kind (in the lowest 2 bits). Unless you are working with the `Subst` implementation specifically, you should generally not have to deal with `Kind` and instead make use of the safe [`UnpackedKind`](#unpackedkind) abstraction. From e627f5031a4b82e52d341a07b40a4d6360c48b9b Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 12 Mar 2019 13:54:50 -0300 Subject: [PATCH 0525/1812] Add experts map section to compiler team page --- src/compiler-team.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/compiler-team.md b/src/compiler-team.md index 728325687..b837c038c 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -17,6 +17,14 @@ home. In any case, you can find people in one of three places at the moment: - The `t-compiler` stream on [the Zulip instance](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler) - The `compiler` channel on the [rust-lang discord](https://discord.gg/rust-lang) +## Expert map + +If you're interested in figuring out who can answer questions about a +particular part of the compiler, or you'd just like to know who works on what, +check out our [experts directory](https://github.com/rust-lang/compiler-team/blob/master/experts/MAP.md). +It contains a listing of the various parts of the compiler and a list of people +who are experts on each one. + ## Rust compiler meeting The compiler team has a weekly meeting where we do triage and try to From 5c827ef97b91f3bd90cfae9438abf1cc261bb188 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 19 Mar 2019 19:02:59 -0500 Subject: [PATCH 0526/1812] address Zoxc's comments --- src/appendix/stupid-stats.md | 5 ++++- src/rustc-driver.md | 8 ++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md index 5066973a9..6ed7d1cbd 100644 --- a/src/appendix/stupid-stats.md +++ b/src/appendix/stupid-stats.md @@ -4,7 +4,9 @@ > a copy of the code on the GitHub repository. > > Due to the compiler's constantly evolving nature, the `rustc_driver` -> mechanisms described in this chapter have been replaced by a new +> mechanisms described in this chapter have changed. In particular, the +> `CompilerCalls` and `CompileController` types have been replaced by +> [`Callbacks`][cb]. Also, there is a new query-based interface in the > [`rustc_interface`] crate. See [The Rustc Driver and Interface] for more > information. @@ -409,6 +411,7 @@ analysis, rather than doing its own analysis). Other parts of the compiler internally (I already changed save-analysis to use `CompilerController`). I've been experimenting with a prototype rustfmt which also uses these APIs. +[cb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/trait.Callbacks.html [stupid-stats]: https://github.com/nrc/stupid-stats [`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html [The Rustc Driver and Interface]: ../rustc-driver.html diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 92754f675..715e6295d 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -21,6 +21,13 @@ specifically the [`rustc_driver::run_compiler` function][rd_rc] (not to be confu `interface::run_compiler`). The `rustc_driver::run_compiler` function takes a bunch of command-line args and some other configurations and drives the compilation to completion. +`rustc_driver::run_compiler` also takes a [`Callbacks`][cb]. In the past, when +the `rustc_driver::run_compiler` was the primary way to use the compiler as a +library, these callbacks were used to have some custom code run after different +phases of the compilation. If you read [Appendix A], you may notice the use of the +types `CompilerCalls` and `CompileController`, which no longer exist. `Callbacks` +replaces this functionality. + > **Warning:** By its very nature, the internal compiler APIs are always going > to be unstable. That said, we do try not to break things unnecessarily. @@ -38,6 +45,7 @@ duplication while also preventing a lot of the ergonomic issues due to many pervasive lifetimes. The `rustc::ty::tls` module is used to access these thread-locals, although you should rarely need to touch it. +[cb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/trait.Callbacks.html [rd_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.run_compiler.html [`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/ From c7d4e2fde216ead53fb88b6cd70376359455517f Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Thu, 21 Mar 2019 23:29:17 +0000 Subject: [PATCH 0527/1812] Small fix to code for checking feature gate --- src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 650d9915c..8105e1474 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -146,7 +146,7 @@ version is when you are stabilizing a feature. 4. Prevent usage of the new feature unless the feature gate is set. You can check it in most places in the compiler using the expression `tcx.features().$feature_name` (or - `sess.features_untracked().borrow().$feature_name` if the + `sess.features_untracked().$feature_name` if the tcx is unavailable) If the feature gate is not set, you should either maintain From 67ec74d6296e54424c4efa142e3346df0036decc Mon Sep 17 00:00:00 2001 From: Dan Robertson Date: Wed, 20 Mar 2019 14:03:54 +0000 Subject: [PATCH 0528/1812] Update link to debugging codegen --- src/codegen.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/codegen.md b/src/codegen.md index 766dfff59..c8d51f318 100644 --- a/src/codegen.md +++ b/src/codegen.md @@ -4,9 +4,9 @@ Code generation or "codegen" is the part of the compiler that actually generates an executable binary. rustc uses LLVM for code generation. > NOTE: If you are looking for hints on how to debug code generation bugs, -> please see [this section of the debugging chapter][debug]. +> please see [this section of the debugging chapter][debugging]. -[debug]: compiler-debugging.html#debugging-llvm +[debugging]: codegen/debugging.html ## What is LLVM? From 9df878f4b860c4c03d1659a46b4100445dd9d085 Mon Sep 17 00:00:00 2001 From: Denys Zariaiev Date: Sat, 16 Mar 2019 23:33:43 +0100 Subject: [PATCH 0529/1812] Add a note about `assembly` test suite. --- src/tests/intro.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/tests/intro.md b/src/tests/intro.md index 4d509f3a8..c043da429 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -38,6 +38,8 @@ that give more details. - `debuginfo` – tests that run in gdb or lldb and query the debug info - `codegen` – tests that compile and then test the generated LLVM code to make sure that the optimizations we want are taking effect. +- `assembly` – similar to `codegen` tests, but verifies assembly output + to make sure LLVM target backend can handle provided code. - `mir-opt` – tests that check parts of the generated MIR to make sure we are building things correctly or doing the optimizations we expect. From 9b06a122e4ea11d5830402c9f3c752a16eb6ef68 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 19 Mar 2019 18:50:01 -0500 Subject: [PATCH 0530/1812] Use eddyb's suggestion from #11 about logging --- src/compiler-debugging.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 714385ca0..6747fd31c 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -162,9 +162,10 @@ your log filter, e.g. to get the logs for a specific module, you can run the compiler as `RUST_LOG=module::path rustc my-file.rs`. All `debug!` output will then appear in standard error. -Note that unless you use a very strict filter, the logger will emit a *lot* -of output - so it's typically a good idea to pipe standard error to a file -and look at the log output with a text editor. +**Note that unless you use a very strict filter, the logger will emit a lot of +output, so use the most specific module(s) you can (comma-separated if +multiple)**. It's typically a good idea to pipe standard error to a file and +look at the log output with a text editor. You should also . So to put it together. From 464cb5b166378dff64619081dd4c42533a1eb989 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 23 Mar 2019 18:12:37 -0500 Subject: [PATCH 0531/1812] oops --- src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 6747fd31c..bce5959dc 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -165,7 +165,7 @@ then appear in standard error. **Note that unless you use a very strict filter, the logger will emit a lot of output, so use the most specific module(s) you can (comma-separated if multiple)**. It's typically a good idea to pipe standard error to a file and -look at the log output with a text editor. You should also . +look at the log output with a text editor. So to put it together. From d78594637392eb26bf747be9befc94ee7e6eb475 Mon Sep 17 00:00:00 2001 From: Krishna Sannasi Date: Thu, 11 Apr 2019 17:04:02 -0700 Subject: [PATCH 0532/1812] Update query-evaluation-model-in-detail.md Fix typo in the example --- src/queries/query-evaluation-model-in-detail.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 41789637d..47412acef 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -99,7 +99,7 @@ from outside of the query system, invoke the queries it needs to perform its task. This looks something like the following: ```rust,ignore -fn compile_crate() {} +fn compile_crate() { let cli_options = ...; let hir_map = ...; From 07d1d3c83b200208d8bac28af65271d628c3a3ee Mon Sep 17 00:00:00 2001 From: "Zack M. Davis" Date: Tue, 5 Feb 2019 22:36:35 -0800 Subject: [PATCH 0533/1812] subchapter with information about `--error-format json` --- src/SUMMARY.md | 1 + src/diag/json-format.md | 36 ++++++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+) create mode 100644 src/diag/json-format.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index d3cef1a25..099c65a73 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -83,6 +83,7 @@ - [Updating LLVM](./codegen/updating-llvm.md) - [Debugging LLVM](./codegen/debugging.md) - [Emitting Diagnostics](./diag.md) + - [JSON diagnostic format](./diag/json-format.md) --- diff --git a/src/diag/json-format.md b/src/diag/json-format.md new file mode 100644 index 000000000..6ba555b1d --- /dev/null +++ b/src/diag/json-format.md @@ -0,0 +1,36 @@ +# JSON diagnostic output + +The compiler accepts an `--error-format json` flag to output +diagnostics as JSON objects (for the benefit of tools such as `cargo +fix` or the RLS). It looks like this— + +```ignore +$ rustc json_error_demo.rs --error-format json +{"message":"cannot add `&str` to `{integer}`","code":{"code":"E0277","explanation":"\nYou tried to use a type which doesn't implement some trait in a place which\nexpected that trait. Erroneous code example:\n\n```compile_fail,E0277\n// here we declare the Foo trait with a bar method\ntrait Foo {\n fn bar(&self);\n}\n\n// we now declare a function which takes an object implementing the Foo trait\nfn some_func(foo: T) {\n foo.bar();\n}\n\nfn main() {\n // we now call the method with the i32 type, which doesn't implement\n // the Foo trait\n some_func(5i32); // error: the trait bound `i32 : Foo` is not satisfied\n}\n```\n\nIn order to fix this error, verify that the type you're using does implement\nthe trait. Example:\n\n```\ntrait Foo {\n fn bar(&self);\n}\n\nfn some_func(foo: T) {\n foo.bar(); // we can now use this method since i32 implements the\n // Foo trait\n}\n\n// we implement the trait on the i32 type\nimpl Foo for i32 {\n fn bar(&self) {}\n}\n\nfn main() {\n some_func(5i32); // ok!\n}\n```\n\nOr in a generic context, an erroneous code example would look like:\n\n```compile_fail,E0277\nfn some_func(foo: T) {\n println!(\"{:?}\", foo); // error: the trait `core::fmt::Debug` is not\n // implemented for the type `T`\n}\n\nfn main() {\n // We now call the method with the i32 type,\n // which *does* implement the Debug trait.\n some_func(5i32);\n}\n```\n\nNote that the error here is in the definition of the generic function: Although\nwe only call it with a parameter that does implement `Debug`, the compiler\nstill rejects the function: It must work with all possible input types. In\norder to make this example compile, we need to restrict the generic type we're\naccepting:\n\n```\nuse std::fmt;\n\n// Restrict the input type to types that implement Debug.\nfn some_func(foo: T) {\n println!(\"{:?}\", foo);\n}\n\nfn main() {\n // Calling the method is still fine, as i32 implements Debug.\n some_func(5i32);\n\n // This would fail to compile now:\n // struct WithoutDebug;\n // some_func(WithoutDebug);\n}\n```\n\nRust only looks at the signature of the called function, as such it must\nalready specify all requirements that will be used for every type parameter.\n"},"level":"error","spans":[{"file_name":"json_error_demo.rs","byte_start":50,"byte_end":51,"line_start":4,"line_end":4,"column_start":7,"column_end":8,"is_primary":true,"text":[{"text":" a + b","highlight_start":7,"highlight_end":8}],"label":"no implementation for `{integer} + &str`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"the trait `std::ops::Add<&str>` is not implemented for `{integer}`","code":null,"level":"help","spans":[],"children":[],"rendered":null}],"rendered":"error[E0277]: cannot add `&str` to `{integer}`\n --> json_error_demo.rs:4:7\n |\n4 | a + b\n | ^ no implementation for `{integer} + &str`\n |\n = help: the trait `std::ops::Add<&str>` is not implemented for `{integer}`\n\n"} +{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to previous error\n\n"} +{"message":"For more information about this error, try `rustc --explain E0277`.","code":null,"level":"","spans":[],"children":[],"rendered":"For more information about this error, try `rustc --explain E0277`.\n"} +``` + +Note that the output is a series of lines, each of which is a JSON +object, but the series of lines taken together is, unfortunately, not +valid JSON, thwarting tools and tricks (such as [piping to `python3 -m +json.tool`](https://docs.python.org/3/library/json.html#module-json.tool)) +that require such. (One speculates that this was intentional for LSP +performance purposes, so that each line/object can be sent to RLS as +it is flushed?) + +Also note the "rendered" field, which contains the "human" output as a +string; this was introduced so that UI tests could both make use of +the structured JSON and see the "human" output (well, _sans_ colors) +without having to compile everything twice. + +The JSON emitter currently lives in libsyntax/json.rs. (But arguably +it should live in librustc_errors along with the "human" emitter? It's +not obvious to the present author why it wasn't moved from libsyntax +to librustc_errors at the same [time the "human" emitter was +moved](https://github.com/rust-lang/rust/commit/6ae3502134).) + +The JSON emitter defines [its own `Diagnostic` +struct](https://github.com/rust-lang/rust/blob/b2c6b8c29f13f8d1f242da89e587960b95337819/src/libsyntax/json.rs#L85-L99) +(and sub-structs) for the JSON serialization. Don't confuse this with +[`errors::Diagnostic`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Diagnostic.html)! From 7503057194de61550ba8387b2c7ff04526e5f56c Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Tue, 16 Apr 2019 00:52:08 +0300 Subject: [PATCH 0534/1812] Update query chapter for the query macro rewrite There was a big macro rewrite in these pull requests: https://github.com/rust-lang/rust/pull/56462 https://github.com/rust-lang/rust/pull/59517 Update the query chapter to describe the new macro usage. --- src/query.md | 76 ++++++++++++++++++++++++++++++---------------------- 1 file changed, 44 insertions(+), 32 deletions(-) diff --git a/src/query.md b/src/query.md index 703c560e0..4d80187aa 100644 --- a/src/query.md +++ b/src/query.md @@ -167,50 +167,45 @@ Well, defining a query takes place in two steps: To specify the query name and arguments, you simply add an entry to the big macro invocation in -[`src/librustc/ty/query/mod.rs`][query-mod], which looks something like: +[`src/librustc/query/mod.rs`][query-mod], which looks something like: -[query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/index.html +[query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/query/index.html ```rust,ignore -define_queries! { <'tcx> - /// Records the type of every item. - [] fn type_of: TypeOfItem(DefId) -> Ty<'tcx>, +rustc_queries! { + Other { + /// Records the type of every item. + query type_of(key: DefId) -> Ty<'tcx> { + cache { key.is_local() } + } + } ... } ``` -Each line of the macro defines one query. The name is broken up like this: +Queries are grouped into categories (`Other`, `Codegen`, `TypeChecking`, etc.). +Each group contains one or more queries. Each query definition is broken up like +this: ```rust,ignore -[] fn type_of: TypeOfItem(DefId) -> Ty<'tcx>, -^^ ^^^^^^^ ^^^^^^^^^^ ^^^^^ ^^^^^^^^ -| | | | | -| | | | result type of query -| | | query key type -| | dep-node constructor +query type_of(key: DefId) -> Ty<'tcx> { ... } +^^ ^^^^^^^ ^^^^^ ^^^^^^^^ ^^^ +| | | | | +| | | | query modifiers +| | | result type of query +| | query key type | name of query -query flags +query keyword ``` Let's go over them one by one: -- **Query flags:** these are largely unused right now, but the intention - is that we'll be able to customize various aspects of how the query is - processed. +- **Query keyword:** indicates a start of a query definition. - **Name of query:** the name of the query method (`tcx.type_of(..)`). Also used as the name of a struct (`ty::queries::type_of`) that will be generated to represent this query. -- **Dep-node constructor:** indicates the constructor function that - connects this query to incremental compilation. Typically, this is a - `DepNode` variant, which can be added by modifying the - `define_dep_nodes!` macro invocation in - [`librustc/dep_graph/dep_node.rs`][dep-node]. - - However, sometimes we use a custom function, in which case the - name will be in snake case and the function will be defined at the - bottom of the file. This is typically used when the query key is - not a def-id, or just not the type that the dep-node expects. - **Query key type:** the type of the argument to this query. This type must implement the `ty::query::keys::Key` trait, which defines (for example) how to map it to a crate, and so forth. @@ -222,19 +217,18 @@ Let's go over them one by one: which is used to cheaply modify MIR in place. See the definition of `Steal` for more details. New uses of `Steal` should **not** be added without alerting `@rust-lang/compiler`. - -[dep-node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/dep_graph/struct.DepNode.html +- **Query modifiers:** various flags and options that customize how the + query is processed. So, to add a query: -- Add an entry to `define_queries!` using the format above. -- Possibly add a corresponding entry to the dep-node macro. +- Add an entry to `rustc_queries!` using the format above. - Link the provider by modifying the appropriate `provide` method; or add a new one if needed and ensure that `rustc_driver` is invoking it. #### Query structs and descriptions -For each kind, the `define_queries` macro will generate a "query struct" +For each kind, the `rustc_queries` macro will generate a "query struct" named after the query. This struct is a kind of a place-holder describing the query. Each such struct implements the `self::config::QueryConfig` trait, which has associated types for the @@ -243,11 +237,14 @@ like this: ```rust,ignore // Dummy struct representing a particular kind of query: -pub struct type_of<'tcx> { phantom: PhantomData<&'tcx ()> } +pub struct type_of<'tcx> { data: PhantomData<&'tcx ()> } impl<'tcx> QueryConfig for type_of<'tcx> { type Key = DefId; type Value = Ty<'tcx>; + + const NAME: QueryName = QueryName::type_of; + const CATEGORY: ProfileCategory = ProfileCategory::Other; } ``` @@ -262,9 +259,24 @@ You can put new impls into the `config` module. They look something like this: ```rust,ignore impl<'tcx> QueryDescription for queries::type_of<'tcx> { fn describe(tcx: TyCtxt, key: DefId) -> String { - format!("computing the type of `{}`", tcx.item_path_str(key)) + format!("computing the type of `{}`", tcx.def_path_str(key)) + } +} +``` + +Another option is to add `desc` modifier: + +```rust,ignore +rustc_queries! { + Other { + /// Records the type of every item. + query type_of(key: DefId) -> Ty<'tcx> { + desc { |tcx| "computing the type of `{}`", tcx.def_path_str(key) } + } } } ``` +`rustc_queries` macro will generate an appropriate `impl` automatically. + [query-model]: queries/query-evaluation-model-in-detail.html From b95f3493890c017b70b8442c38e7ef2f9334731a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 16 Apr 2019 15:29:25 -0500 Subject: [PATCH 0535/1812] fix MovePathIndex link --- .../moves_and_initialization/move_paths.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index 8fd7b3f19..4d4db4116 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -32,13 +32,11 @@ efficiently. ## Move path indices -Although there is a [`MovePath`] data structure, they are never -referenced directly. Instead, all the code passes around *indices* of -type -[`MovePathIndex`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/indexes/struct.MovePathIndex.html). If -you need to get information about a move path, you use this index with -the [`move_paths` field of the `MoveData`][move_paths]. For example, -to convert a [`MovePathIndex`] `mpi` into a MIR [`Place`], you might +Although there is a [`MovePath`] data structure, they are never referenced +directly. Instead, all the code passes around *indices* of type +[`MovePathIndex`]. If you need to get information about a move path, you use +this index with the [`move_paths` field of the `MoveData`][move_paths]. For +example, to convert a [`MovePathIndex`] `mpi` into a MIR [`Place`], you might access the [`MovePath::place`] field like so: ```rust,ignore @@ -47,7 +45,7 @@ move_data.move_paths[mpi].place [move_paths]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#structfield.move_paths [`MovePath::place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePath.html#structfield.place -[`MovePathIndex`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/indexes/struct.MovePathIndex.html +[`MovePathIndex`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathIndex.html ## Building move paths From 2ef961e45465a5edfbd3d5c49e4a16cee356b44b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 16 Apr 2019 14:13:38 -0500 Subject: [PATCH 0536/1812] move to subsection --- src/diag.md | 37 +++++++++++++++++++++++++++++++++++++ src/diag/json-format.md | 36 ------------------------------------ 2 files changed, 37 insertions(+), 36 deletions(-) diff --git a/src/diag.md b/src/diag.md index cfdd82aa2..31268e9f6 100644 --- a/src/diag.md +++ b/src/diag.md @@ -305,3 +305,40 @@ an appropriate mapping to the body of [`Lint::from_parser_lint_id`][fplid]. [`BufferedEarlyLintId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/early_buffered_lints/enum.BufferedEarlyLintId.html [fplid]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.Lint.html#method.from_parser_lint_id + +## JSON diagnostic output + +The compiler accepts an `--error-format json` flag to output +diagnostics as JSON objects (for the benefit of tools such as `cargo +fix` or the RLS). It looks like this— + +```console +$ rustc json_error_demo.rs --error-format json +{"message":"cannot add `&str` to `{integer}`","code":{"code":"E0277","explanation":"\nYou tried to use a type which doesn't implement some trait in a place which\nexpected that trait. Erroneous code example:\n\n```compile_fail,E0277\n// here we declare the Foo trait with a bar method\ntrait Foo {\n fn bar(&self);\n}\n\n// we now declare a function which takes an object implementing the Foo trait\nfn some_func(foo: T) {\n foo.bar();\n}\n\nfn main() {\n // we now call the method with the i32 type, which doesn't implement\n // the Foo trait\n some_func(5i32); // error: the trait bound `i32 : Foo` is not satisfied\n}\n```\n\nIn order to fix this error, verify that the type you're using does implement\nthe trait. Example:\n\n```\ntrait Foo {\n fn bar(&self);\n}\n\nfn some_func(foo: T) {\n foo.bar(); // we can now use this method since i32 implements the\n // Foo trait\n}\n\n// we implement the trait on the i32 type\nimpl Foo for i32 {\n fn bar(&self) {}\n}\n\nfn main() {\n some_func(5i32); // ok!\n}\n```\n\nOr in a generic context, an erroneous code example would look like:\n\n```compile_fail,E0277\nfn some_func(foo: T) {\n println!(\"{:?}\", foo); // error: the trait `core::fmt::Debug` is not\n // implemented for the type `T`\n}\n\nfn main() {\n // We now call the method with the i32 type,\n // which *does* implement the Debug trait.\n some_func(5i32);\n}\n```\n\nNote that the error here is in the definition of the generic function: Although\nwe only call it with a parameter that does implement `Debug`, the compiler\nstill rejects the function: It must work with all possible input types. In\norder to make this example compile, we need to restrict the generic type we're\naccepting:\n\n```\nuse std::fmt;\n\n// Restrict the input type to types that implement Debug.\nfn some_func(foo: T) {\n println!(\"{:?}\", foo);\n}\n\nfn main() {\n // Calling the method is still fine, as i32 implements Debug.\n some_func(5i32);\n\n // This would fail to compile now:\n // struct WithoutDebug;\n // some_func(WithoutDebug);\n}\n```\n\nRust only looks at the signature of the called function, as such it must\nalready specify all requirements that will be used for every type parameter.\n"},"level":"error","spans":[{"file_name":"json_error_demo.rs","byte_start":50,"byte_end":51,"line_start":4,"line_end":4,"column_start":7,"column_end":8,"is_primary":true,"text":[{"text":" a + b","highlight_start":7,"highlight_end":8}],"label":"no implementation for `{integer} + &str`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"the trait `std::ops::Add<&str>` is not implemented for `{integer}`","code":null,"level":"help","spans":[],"children":[],"rendered":null}],"rendered":"error[E0277]: cannot add `&str` to `{integer}`\n --> json_error_demo.rs:4:7\n |\n4 | a + b\n | ^ no implementation for `{integer} + &str`\n |\n = help: the trait `std::ops::Add<&str>` is not implemented for `{integer}`\n\n"} +{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to previous error\n\n"} +{"message":"For more information about this error, try `rustc --explain E0277`.","code":null,"level":"","spans":[],"children":[],"rendered":"For more information about this error, try `rustc --explain E0277`.\n"} +``` + +Note that the output is a series of lines, each of which is a JSON +object, but the series of lines taken together is, unfortunately, not +valid JSON, thwarting tools and tricks (such as [piping to `python3 -m +json.tool`](https://docs.python.org/3/library/json.html#module-json.tool)) +that require such. (One speculates that this was intentional for LSP +performance purposes, so that each line/object can be sent to RLS as +it is flushed?) + +Also note the "rendered" field, which contains the "human" output as a +string; this was introduced so that UI tests could both make use of +the structured JSON and see the "human" output (well, _sans_ colors) +without having to compile everything twice. + +The JSON emitter currently lives in libsyntax/json.rs. (But arguably +it should live in librustc_errors along with the "human" emitter? It's +not obvious to the present author why it wasn't moved from libsyntax +to librustc_errors at the same [time the "human" emitter was +moved](https://github.com/rust-lang/rust/commit/6ae3502134).) + +The JSON emitter defines [its own `Diagnostic` +struct](https://github.com/rust-lang/rust/blob/b2c6b8c29f13f8d1f242da89e587960b95337819/src/libsyntax/json.rs#L85-L99) +(and sub-structs) for the JSON serialization. Don't confuse this with +[`errors::Diagnostic`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Diagnostic.html)! diff --git a/src/diag/json-format.md b/src/diag/json-format.md index 6ba555b1d..e69de29bb 100644 --- a/src/diag/json-format.md +++ b/src/diag/json-format.md @@ -1,36 +0,0 @@ -# JSON diagnostic output - -The compiler accepts an `--error-format json` flag to output -diagnostics as JSON objects (for the benefit of tools such as `cargo -fix` or the RLS). It looks like this— - -```ignore -$ rustc json_error_demo.rs --error-format json -{"message":"cannot add `&str` to `{integer}`","code":{"code":"E0277","explanation":"\nYou tried to use a type which doesn't implement some trait in a place which\nexpected that trait. Erroneous code example:\n\n```compile_fail,E0277\n// here we declare the Foo trait with a bar method\ntrait Foo {\n fn bar(&self);\n}\n\n// we now declare a function which takes an object implementing the Foo trait\nfn some_func(foo: T) {\n foo.bar();\n}\n\nfn main() {\n // we now call the method with the i32 type, which doesn't implement\n // the Foo trait\n some_func(5i32); // error: the trait bound `i32 : Foo` is not satisfied\n}\n```\n\nIn order to fix this error, verify that the type you're using does implement\nthe trait. Example:\n\n```\ntrait Foo {\n fn bar(&self);\n}\n\nfn some_func(foo: T) {\n foo.bar(); // we can now use this method since i32 implements the\n // Foo trait\n}\n\n// we implement the trait on the i32 type\nimpl Foo for i32 {\n fn bar(&self) {}\n}\n\nfn main() {\n some_func(5i32); // ok!\n}\n```\n\nOr in a generic context, an erroneous code example would look like:\n\n```compile_fail,E0277\nfn some_func(foo: T) {\n println!(\"{:?}\", foo); // error: the trait `core::fmt::Debug` is not\n // implemented for the type `T`\n}\n\nfn main() {\n // We now call the method with the i32 type,\n // which *does* implement the Debug trait.\n some_func(5i32);\n}\n```\n\nNote that the error here is in the definition of the generic function: Although\nwe only call it with a parameter that does implement `Debug`, the compiler\nstill rejects the function: It must work with all possible input types. In\norder to make this example compile, we need to restrict the generic type we're\naccepting:\n\n```\nuse std::fmt;\n\n// Restrict the input type to types that implement Debug.\nfn some_func(foo: T) {\n println!(\"{:?}\", foo);\n}\n\nfn main() {\n // Calling the method is still fine, as i32 implements Debug.\n some_func(5i32);\n\n // This would fail to compile now:\n // struct WithoutDebug;\n // some_func(WithoutDebug);\n}\n```\n\nRust only looks at the signature of the called function, as such it must\nalready specify all requirements that will be used for every type parameter.\n"},"level":"error","spans":[{"file_name":"json_error_demo.rs","byte_start":50,"byte_end":51,"line_start":4,"line_end":4,"column_start":7,"column_end":8,"is_primary":true,"text":[{"text":" a + b","highlight_start":7,"highlight_end":8}],"label":"no implementation for `{integer} + &str`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"the trait `std::ops::Add<&str>` is not implemented for `{integer}`","code":null,"level":"help","spans":[],"children":[],"rendered":null}],"rendered":"error[E0277]: cannot add `&str` to `{integer}`\n --> json_error_demo.rs:4:7\n |\n4 | a + b\n | ^ no implementation for `{integer} + &str`\n |\n = help: the trait `std::ops::Add<&str>` is not implemented for `{integer}`\n\n"} -{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to previous error\n\n"} -{"message":"For more information about this error, try `rustc --explain E0277`.","code":null,"level":"","spans":[],"children":[],"rendered":"For more information about this error, try `rustc --explain E0277`.\n"} -``` - -Note that the output is a series of lines, each of which is a JSON -object, but the series of lines taken together is, unfortunately, not -valid JSON, thwarting tools and tricks (such as [piping to `python3 -m -json.tool`](https://docs.python.org/3/library/json.html#module-json.tool)) -that require such. (One speculates that this was intentional for LSP -performance purposes, so that each line/object can be sent to RLS as -it is flushed?) - -Also note the "rendered" field, which contains the "human" output as a -string; this was introduced so that UI tests could both make use of -the structured JSON and see the "human" output (well, _sans_ colors) -without having to compile everything twice. - -The JSON emitter currently lives in libsyntax/json.rs. (But arguably -it should live in librustc_errors along with the "human" emitter? It's -not obvious to the present author why it wasn't moved from libsyntax -to librustc_errors at the same [time the "human" emitter was -moved](https://github.com/rust-lang/rust/commit/6ae3502134).) - -The JSON emitter defines [its own `Diagnostic` -struct](https://github.com/rust-lang/rust/blob/b2c6b8c29f13f8d1f242da89e587960b95337819/src/libsyntax/json.rs#L85-L99) -(and sub-structs) for the JSON serialization. Don't confuse this with -[`errors::Diagnostic`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Diagnostic.html)! From aa7bb2bc5d6ae2688589ff066426eb5ad0ac24a0 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 16 Apr 2019 15:18:55 -0500 Subject: [PATCH 0537/1812] update chalk with new organization --- src/traits/chalk-overview.md | 51 ++++++++++++++++++------------------ src/traits/lowering-rules.md | 6 ++--- src/traits/wf.md | 10 +++---- 3 files changed, 34 insertions(+), 33 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 54046b22e..4d1260ddc 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -70,16 +70,17 @@ impls, and struct definitions. Parsing is often the first "phase" of transformation that a program goes through in order to become a format that chalk can understand. -### Rust Intermediate Representation ([rust_ir]) +### Rust Intermediate Representation ([chalk_rust_ir]) After getting the AST we convert it to a more convenient intermediate -representation called [`rust_ir`][rust_ir]. This is sort of analogous to the -[HIR] in Rust. The process of converting to IR is called *lowering*. +representation called [`chalk_rust_ir`][chalk_rust_ir]. This is sort of +analogous to the [HIR] in Rust. The process of converting to IR is called +*lowering*. -The [`rust_ir::Program`][rust_ir-program] struct contains some "rust things" +The [`chalk::program::Program`][chalk-program] struct contains some "rust things" but indexed and accessible in a different way. For example, if you have a type like `Foo`, we would represent `Foo` as a string in the AST but in -`rust_ir::Program`, we use numeric indices (`ItemId`). +`chalk::program::Program`, we use numeric indices (`ItemId`). The [IR source code][ir-code] contains the complete definition. @@ -120,14 +121,14 @@ forall { (Vec: Clone) :- (T: Clone) } This rule dictates that `Vec: Clone` is only satisfied if `T: Clone` is also satisfied (i.e. "provable"). -Similar to [`rust_ir::Program`][rust_ir-program] which has "rust-like +Similar to [`chalk::program::Program`][chalk-program] which has "rust-like things", chalk_ir defines [`ProgramEnvironment`] which which is "pure logic". The main field in that struct is `program_clauses`, which contains the [`ProgramClause`]s generated by the rules module. -#### Rules +### Rules ([chalk_rules]) -The `rules` module ([source code][rules-src]) defines the logic rules we use +The `chalk_rules` crate ([source code][chalk_rules]) defines the logic rules we use for each item in the Rust IR. It works by iterating over every trait, impl, etc. and emitting the rules that come from each one. @@ -136,13 +137,13 @@ etc. and emitting the rules that come from each one. #### Well-formedness checks As part of lowering to logic, we also do some "well formedness" checks. See -the [`rules::wf` source code][rules-wf-src] for where those are done. +the [`chalk_rules::wf` source code][rules-wf-src] for where those are done. *See also: [Well-formedness checking][wf-checking]* #### Coherence -The function `record_specialization_priorities` in the `coherence` module +The method `CoherenceSolver::specialization_priorities` in the `coherence` module ([source code][coherence-src]) checks "coherence", which means that it ensures that two impls of the same trait for the same type cannot exist. @@ -158,18 +159,19 @@ queries is called the *solver*. Chalk's functionality is broken up into the following crates: - [**chalk_engine**][chalk_engine]: Defines the core [SLG solver][slg]. +- [**chalk_rust_ir**][chalk_rust_ir], containing the "HIR-like" form of the AST - [**chalk_ir**][chalk_ir]: Defines chalk's internal representation of types, lifetimes, and goals. - [**chalk_solve**][chalk_solve]: Combines `chalk_ir` and `chalk_engine`, effectively. - [`chalk_engine::context`][engine-context] provides the necessary hooks. - [**chalk_parse**][chalk_parse]: Defines the raw AST and a parser. +- [**chalk_rules**][chalk_rules]: which implements logic rules converting + `chalk_rust_ir` to `chalk_ir` + - Defines the `coherence` module, which implements coherence rules - [**chalk**][doc-chalk]: Brings everything together. Defines the following modules: - - [`rust_ir`][rust_ir], containing the "HIR-like" form of the AST - - `rust_ir::lowering`, which converts AST to `rust_ir` - - `rules`, which implements logic rules converting `rust_ir` to `chalk_ir` - - `coherence`, which implements coherence rules + - `chalk::lowering`, which converts AST to `chalk_rust_ir` - Also includes [chalki][chalki], chalk's REPL. [Browse source code on GitHub](https://github.com/rust-lang/chalk) @@ -188,7 +190,7 @@ which is expected to lower to logic successfully, and a set of queries tests support specifying only a prefix of the output. **Lowering tests** check the stages that occur before we can issue queries -to the solver: the [lowering to rust_ir][chalk-test-lowering], and the +to the solver: the [lowering to chalk_rust_ir][chalk-test-lowering], and the [well-formedness checks][chalk-test-wf] that occur after that. ### Testing internals @@ -229,29 +231,28 @@ Likewise, lowering tests use the [`lowering_success!` and [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification [`ProgramClause`]: https://rust-lang.github.io/chalk/doc/chalk_ir/enum.ProgramClause.html -[`ProgramEnvironment`]: https://rust-lang.github.io/chalk/doc/chalk_ir/struct.ProgramEnvironment.html +[`ProgramEnvironment`]: http://rust-lang.github.io/chalk/doc/chalk/program_environment/struct.ProgramEnvironment.html [chalk_engine]: https://rust-lang.github.io/chalk/doc/chalk_engine/index.html [chalk_ir]: https://rust-lang.github.io/chalk/doc/chalk_ir/index.html [chalk_parse]: https://rust-lang.github.io/chalk/doc/chalk_parse/index.html [chalk_solve]: https://rust-lang.github.io/chalk/doc/chalk_solve/index.html +[chalk_rules]: https://rust-lang.github.io/chalk/doc/chalk_rules/index.html +[chalk_rust_ir]: https://rust-lang.github.io/chalk/doc/chalk_rust_ir/index.html [doc-chalk]: https://rust-lang.github.io/chalk/doc/chalk/index.html [engine-context]: https://rust-lang.github.io/chalk/doc/chalk_engine/context/index.html -[rust_ir-program]: https://rust-lang.github.io/chalk/doc/chalk/rust_ir/struct.Program.html -[rust_ir]: https://rust-lang.github.io/chalk/doc/chalk/rust_ir/index.html +[chalk-program]: http://rust-lang.github.io/chalk/doc/chalk/program/struct.Program.html -[binders-struct]: https://github.com/rust-lang/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661 -[chalk-ast]: https://github.com/rust-lang/chalk/blob/master/chalk-parse/src/ast.rs +[binders-struct]: http://rust-lang.github.io/chalk/doc/chalk_ir/struct.Binders.html +[chalk-ast]: http://rust-lang.github.io/chalk/doc/chalk_parse/ast/index.html [chalk-test-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 [chalk-test-lowering-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs#L8-L31 [chalk-test-lowering]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs [chalk-test-wf]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf/test.rs#L1 [chalki]: https://rust-lang.github.io/chalk/doc/chalki/index.html [clause]: https://github.com/rust-lang/chalk/blob/master/GLOSSARY.md#clause -[coherence-src]: https://github.com/rust-lang/chalk/blob/master/src/coherence.rs -[ir-code]: https://github.com/rust-lang/chalk/blob/master/src/rust_ir.rs -[rules-environment]: https://github.com/rust-lang/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9 -[rules-src]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules.rs -[rules-wf-src]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf.rs +[coherence-src]: http://rust-lang.github.io/chalk/doc/chalk_rules/coherence/index.html +[ir-code]: http://rust-lang.github.io/chalk/doc/chalk_rust_ir/ +[rules-wf-src]: http://rust-lang.github.io/chalk/doc/chalk_rules/wf/index.html [solve_goal]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L85 [test-lowering-macros]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test_util.rs#L21-L54 [test-macro]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L33 diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index 88a61ac4f..7f46e5738 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -28,10 +28,10 @@ comment like so: // Rule Foo-Bar-Baz The reference implementation of these rules is to be found in -[`chalk/src/rules.rs`][chalk_rules]. They are also ported in rustc in the -[`librustc_traits`][librustc_traits] crate. +[`chalk/chalk-rules/src/clauses.rs`][chalk_rules]. They are also ported in +rustc in the [`librustc_traits`][librustc_traits] crate. -[chalk_rules]: https://github.com/rust-lang-nursery/chalk/blob/master/src/rules.rs +[chalk_rules]: https://github.com/rust-lang/chalk/blob/master/chalk-rules/src/clauses.rs [librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits ## Lowering where clauses diff --git a/src/traits/wf.md b/src/traits/wf.md index f0cb03caa..e2d15f1db 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -11,14 +11,14 @@ to prove it using the lowered rules we described in the [lowering rules](./lowering-rules.md) chapter. If we are able to prove it, we say that the construct is well-formed. If not, we report an error to the user. -Well-formedness checking happens in the [`src/rules/wf.rs`][wf] module in -chalk. After you have read this chapter, you may find useful to see an -extended set of examples in the [`src/rules/wf/test.rs`][wf_test] submodule. +Well-formedness checking happens in the [`chalk/chalk-rules/src/wf.rs`][wf] +module in chalk. After you have read this chapter, you may find useful to see +an extended set of examples in the [`chalk/src/test/wf.rs`][wf_test] submodule. The new-style WF checking has not been implemented in rustc yet. -[wf]: https://github.com/rust-lang-nursery/chalk/blob/master/src/rules/wf.rs -[wf_test]: https://github.com/rust-lang-nursery/chalk/blob/master/src/rules/wf/test.rs +[wf]: https://github.com/rust-lang/chalk/blob/master/chalk-rules/src/wf.rs +[wf_test]: https://github.com/rust-lang/chalk/blob/master/src/test/wf.rs We give here a complete reference of the generated goals for each Rust declaration. From 813cdf613e24313c61f4cdb05518a75d99d21c8f Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Wed, 17 Apr 2019 11:55:14 +0300 Subject: [PATCH 0538/1812] Update test-implementation chapter to current code `test_main_static` is now used instead of `test_static_main`. The libsyntax no longer generates a `TESTS` constant but rather passes all test cases directly into `test_main_static` as a slice. Update the guide accordingly. --- src/test-implementation.md | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/src/test-implementation.md b/src/test-implementation.md index 3c93ad619..969d6d2e4 100644 --- a/src/test-implementation.md +++ b/src/test-implementation.md @@ -81,20 +81,18 @@ Now that our tests are accessible from the root of our crate, we need to do something with them. `libsyntax` generates a module like so: ```rust,ignore -pub mod __test { +#[main] +pub fn main() { extern crate test; - const TESTS: &'static [self::test::TestDescAndFn] = &[/*...*/]; - - #[main] - pub fn main() { - self::test::test_static_main(TESTS); - } + test::test_main_static(&[&path::to::test1, /*...*/]); } ``` +where `path::to::test1` is a constant of type `test::TestDescAndFn`. + While this transformation is simple, it gives us a lot of insight into how tests are actually run. The tests are aggregated into an array and passed to -a test runner called `test_static_main`. We'll come back to exactly what +a test runner called `test_main_static`. We'll come back to exactly what `TestDescAndFn` is, but for now, the key takeaway is that there is a crate called [`test`][test] that is part of Rust core, that implements all of the runtime for testing. `test`'s interface is unstable, so the only stable way @@ -119,7 +117,7 @@ configuration information as well. `test` encodes this configuration data into a struct called [`TestDesc`][TestDesc]. For each test function in a crate, `libsyntax` will parse its attributes and generate a `TestDesc` instance. It then combines the `TestDesc` and test function into the -predictably named `TestDescAndFn` struct, that `test_static_main` operates +predictably named `TestDescAndFn` struct, that `test_main_static` operates on. For a given test, the generated `TestDescAndFn` instance looks like so: ```rust,ignore @@ -151,4 +149,4 @@ $ rustc my_mod.rs -Z unpretty=hir [Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Ident.html [Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Ident.html [eRFC]: https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md -[libsyntax]: https://github.com/rust-lang/rust/tree/master/src/libsyntax \ No newline at end of file +[libsyntax]: https://github.com/rust-lang/rust/tree/master/src/libsyntax From 99e1b1d53656be08654df399fc200584aebb50e4 Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Thu, 18 Apr 2019 16:51:47 +0300 Subject: [PATCH 0539/1812] Update BodyId description It is now a newtype'd HirId, not NodeId. See https://github.com/rust-lang/rust/pull/58167. --- src/hir.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/hir.md b/src/hir.md index 34e478ee4..b10042270 100644 --- a/src/hir.md +++ b/src/hir.md @@ -87,9 +87,9 @@ sorts of identifiers in active use: offset within that item. - the key point of a [`HirId`] is that it is *relative* to some item (which is named via a [`DefId`]). -- [`BodyId`], this is an absolute identifier that refers to a specific +- [`BodyId`], this is an identifier that refers to a specific body (definition of a function or constant) in the crate. It is currently - effectively a "newtype'd" [`NodeId`]. + effectively a "newtype'd" [`HirId`]. - [`NodeId`], which is an absolute id that identifies a single node in the HIR tree. - While these are still in common use, **they are being slowly phased out**. From a0ab5fac4b09b765478fa2a1a3de390ca60c3d61 Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Sat, 20 Apr 2019 23:00:13 +0300 Subject: [PATCH 0540/1812] [canonicalization] fix result canonicalization example --- src/traits/canonical-queries.md | 2 +- src/traits/canonicalization.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/traits/canonical-queries.md b/src/traits/canonical-queries.md index cbf7d880d..e15bdaae2 100644 --- a/src/traits/canonical-queries.md +++ b/src/traits/canonical-queries.md @@ -173,7 +173,7 @@ variables have unbound inference variables in their type: `?T` represents the elements in the vector `t` and `?U` represents the value stored in the option `u`. Next, we invoke `foo`; comparing the signature of `foo` to its arguments, we wind up with `A = Vec` and -`B = ?U`.Therefore, the where clause on `foo` requires that `Vec: +`B = ?U`. Therefore, the where clause on `foo` requires that `Vec: Borrow`. This is thus our first example trait query. There are many possible solutions to the query `Vec: Borrow`; diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md index ca81d6fd1..d6d57d785 100644 --- a/src/traits/canonicalization.md +++ b/src/traits/canonicalization.md @@ -177,8 +177,8 @@ The result would be as follows: ```text Canonical(QR) = for { certainty: Proven, - var_values: [Vec, '?1, ?2] - region_constraints: [?2: '?1], + var_values: [Vec, '?1, ?0] + region_constraints: [?0: '?1], value: (), } ``` @@ -213,8 +213,8 @@ and now we got back a canonical response: ```text for { certainty: Proven, - var_values: [Vec, '?1, ?2] - region_constraints: [?2: '?1], + var_values: [Vec, '?1, ?0] + region_constraints: [?0: '?1], value: (), } ``` @@ -250,7 +250,7 @@ for later verification. than eagerly instantiating all of the canonical values in the result with variables, we instead walk the vector of values, looking for cases where the value is just a canonical variable. In our example, -`values[2]` is `?C`, so that means we can deduce that `?C := ?B and +`values[2]` is `?C`, so that means we can deduce that `?C := ?B` and `'?D := 'static`. This gives us a partial set of values. Anything for which we do not find a value, we create an inference variable.) From 92219f29bb3666a605d71de394c9401b28a62c6a Mon Sep 17 00:00:00 2001 From: Alexey Shmalko Date: Sat, 20 Apr 2019 20:08:00 +0300 Subject: [PATCH 0541/1812] Update lowering-module test case --- src/traits/lowering-module.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md index 939484051..3f1515ef8 100644 --- a/src/traits/lowering-module.md +++ b/src/traits/lowering-module.md @@ -31,7 +31,7 @@ this writing, it looked like this: trait Foo { } -#[rustc_dump_program_clauses] //~ ERROR Implemented(T: Foo) :- +#[rustc_dump_program_clauses] //~ ERROR program clause dump impl Foo for T where T: Iterator { } fn main() { @@ -45,19 +45,18 @@ compiler will then invoke the `program_clauses_for` query on that item, and emit compiler errors that dump the clauses produced. These errors just exist for unit-testing, as we can then leverage the standard [ui test] mechanisms to check them. In this case, there is a -`//~ ERROR Implemented` annotation which is intentionally minimal (it -need only be a prefix of the error), but [the stderr file] contains +`//~ ERROR program clause dump` annotation which is always the same for +`#[rustc_dump_program_clauses]`, but [the stderr file] contains the full details: ```text -error: Implemented(T: Foo) :- ProjectionEq(::Item == i32), TypeOutlives(T \ -: 'static), Implemented(T: std::iter::Iterator), Implemented(T: std::marker::Sized). - --> $DIR/lower_impl.rs:15:1 +error: program clause dump + --> $DIR/lower_impl.rs:5:1 | -LL | #[rustc_dump_program_clauses] //~ ERROR Implemented(T: Foo) :- +LL | #[rustc_dump_program_clauses] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -error: aborting due to previous error + | + = note: forall { Implemented(T: Foo) :- ProjectionEq(::Item == i32), TypeOutlives(T: 'static), Implemented(T: std::iter::Iterator), Implemented(T: std::marker::Sized). } ``` [chalkify]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify From ad07f7fac5a68007f8f7d87f70ebc9bf60293909 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 24 Apr 2019 15:57:47 +0200 Subject: [PATCH 0542/1812] Explain new powers of the `treat-err-as-bug` flag --- src/compiler-debugging.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index bce5959dc..2e45e5f02 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -70,8 +70,10 @@ stack backtrace: [getting-a-backtrace-for-errors]: #getting-a-backtrace-for-errors If you want to get a backtrace to the point where the compiler emits -an error message, you can pass the `-Z treat-err-as-bug`, which -will make the compiler panic on the first error it sees. +an error message, you can pass the `-Z treat-err-as-bug=n`, which +will make the compiler skip `n` errors or `delay_span_bug` calls and then +panic on the next one. If you leave off `=n`, the compiler will assume `0` for +`n` and thus panic on the first error it encounters. This can also help when debugging `delay_span_bug` calls - it will make the first `delay_span_bug` call panic, which will give you a useful backtrace. From dca6649b722260351a49e2e39dce05b5da56a230 Mon Sep 17 00:00:00 2001 From: Matthew Jasper Date: Wed, 24 Apr 2019 20:53:08 +0100 Subject: [PATCH 0543/1812] Add documentation for two-phase borrows --- src/SUMMARY.md | 1 + src/borrow_check/two_phase_borrows.md | 100 ++++++++++++++++++++++++++ 2 files changed, 101 insertions(+) create mode 100644 src/borrow_check/two_phase_borrows.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 099c65a73..477b9a707 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -76,6 +76,7 @@ - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) - [MIR type checker](./borrow_check/type_check.md) - [Region inference](./borrow_check/region_inference.md) + - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) diff --git a/src/borrow_check/two_phase_borrows.md b/src/borrow_check/two_phase_borrows.md new file mode 100644 index 000000000..753ffa5b2 --- /dev/null +++ b/src/borrow_check/two_phase_borrows.md @@ -0,0 +1,100 @@ +# Two-phase borrows + +Two-phase borrows are a more permissive version of mutable borrows that allow +nested method calls such as `vec.push(vec.len())`. Such borrows first act as +shared borrows in a "reservation" phase and can later be "activated" into a +full mutable borrow. + +Only certain implicit mutable borrows can be two-phase, any `&mut` or `ref mut` +in the source code is never a two-phase borrow. The cases where we generate a +two-phase borrow are: + +1. The autoref borrow when calling a method with a mutable reference receiver. +2. A mutable reborrow in function arguments. +3. The implicit mutable borrow in an overloaded compound assignment operator. + +To give some examples: + +```rust +// In the source code + +// Case 1: +let mut v = Vec::new(); +v.push(v.len()); +let r = &mut Vec::new(); +r.push(r.len()); + +// Case 2: +std::mem::replace(r, vec![1, r.len()]); + +// Case 3: +let mut x = std::num::Wrapping(2); +x += x; +``` + +Expanding these enough to show the two-phase borrows: + +```rust,ignore +// Case 1: +let mut v = Vec::new(); +let temp1 = &two_phase v; +let temp2 = v.len(); +Vec::push(temp1, temp2); +let r = &mut Vec::new(); +let temp3 = &two_phase *r; +let temp4 = r.len(); +Vec::push(temp3, temp4); + +// Case 2: +let temp5 = &two_phase *r; +let temp6 = vec![1, r.len()]; +std::mem::replace(temp5, temp6); + +// Case 3: +let mut x = std::num::Wrapping(2); +let temp7 = &two_phase x; +let temp8 = x; +std::ops::AddAssign::add_assign(temp7, temp8); +``` + +Whether a borrow can be two-phase is tracked by a flag on the [`AutoBorrow`] +after type checking, which is then [converted] to a [`BorrowKind`] during MIR +construction. + +Each two-phase borrow is assigned to a temporary that is only used once. As +such we can define: + +* The point where the temporary is assigned to is called the *reservation* + point of the two-phase borrow. +* The point where the temporary is used, which is effectively always a + function call, is called the *activation* point. + +The activation points are found using the [`GatherBorrows`] visitor. The +[`BorrowData`] then holds both the reservation and activation points for the +borrow. + +[`AutoBorrow`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/adjustment/enum.AutoBorrow.html +[converted]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/cx/expr/trait.ToBorrowKind.html#method.to_borrow_kind +[`BorrowKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.BorrowKind.html +[`GatherBorrows`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/visit/trait.Visitor.html#method.visit_local +[`BorrowData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/borrow_set/struct.BorrowData.html + +## Checking two-phase borrows + +Two-phase borrows are treated as if they were mutable borrows with the +following exceptions: + +1. At every location in the MIR we [check] if any two-phase borrows are + activated at this location. If a live two phase borrow is activated at a + location, then we check that there are no borrows that conflict with the + two-phase borrow. +2. At the reservation point we error if there are conflicting live *mutable* + borrows. And lint if there are any conflicting shared borrows. +3. Between the reservation and the activation point, the two-phase borrow acts + as a shared borrow. We determine (in [`is_active`]) if we're at such a point + by using the [`Dominators`] for the MIR graph. +4. After the activation point, the two-phase borrow acts as a mutable borrow. + +[check]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/struct.MirBorrowckCtxt.html#method.check_activations +[`Dominators`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/graph/dominators/struct.Dominators.html +[`is_active`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/path_utils/fn.is_active.html From e905e3aa17f64686a9da9dba5415e1571ba81ed8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1aki=20Garay?= Date: Thu, 25 Apr 2019 19:24:36 -0300 Subject: [PATCH 0544/1812] Fixed broken chalk links --- src/traits/lowering-rules.md | 4 ++-- src/traits/wf.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index 7f46e5738..bbebf1450 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -28,10 +28,10 @@ comment like so: // Rule Foo-Bar-Baz The reference implementation of these rules is to be found in -[`chalk/chalk-rules/src/clauses.rs`][chalk_rules]. They are also ported in +[`chalk/chalk-solve/src/clauses.rs`][chalk_rules]. They are also ported in rustc in the [`librustc_traits`][librustc_traits] crate. -[chalk_rules]: https://github.com/rust-lang/chalk/blob/master/chalk-rules/src/clauses.rs +[chalk_rules]: https://github.com/rust-lang/chalk/blob/master/chalk-solve/src/clauses.rs [librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits ## Lowering where clauses diff --git a/src/traits/wf.md b/src/traits/wf.md index e2d15f1db..0ced345a1 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -11,13 +11,13 @@ to prove it using the lowered rules we described in the [lowering rules](./lowering-rules.md) chapter. If we are able to prove it, we say that the construct is well-formed. If not, we report an error to the user. -Well-formedness checking happens in the [`chalk/chalk-rules/src/wf.rs`][wf] +Well-formedness checking happens in the [`chalk/chalk-solve/src/wf.rs`][wf] module in chalk. After you have read this chapter, you may find useful to see an extended set of examples in the [`chalk/src/test/wf.rs`][wf_test] submodule. The new-style WF checking has not been implemented in rustc yet. -[wf]: https://github.com/rust-lang/chalk/blob/master/chalk-rules/src/wf.rs +[wf]: https://github.com/rust-lang/chalk/blob/master/chalk-solve/src/wf.rs [wf_test]: https://github.com/rust-lang/chalk/blob/master/src/test/wf.rs We give here a complete reference of the generated goals for each Rust From 1ff2ac0c2aa4fc0a8fe31acdfdee4a4b9c9ec127 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 25 Apr 2019 20:18:55 -0500 Subject: [PATCH 0545/1812] use nightly rust for ci --- .travis.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.travis.yml b/.travis.yml index 55ea20587..fc6f4f05e 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,4 +1,6 @@ language: rust +rust: +- nightly cache: - cargo before_install: From b68e57b705f4799b7f06467a92b0c080982bd80c Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Mon, 29 Apr 2019 07:26:21 -0700 Subject: [PATCH 0546/1812] Bring the updating LLVM guide up to date --- src/codegen/updating-llvm.md | 62 ++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 35 deletions(-) diff --git a/src/codegen/updating-llvm.md b/src/codegen/updating-llvm.md index e29e041b2..b26c475f7 100644 --- a/src/codegen/updating-llvm.md +++ b/src/codegen/updating-llvm.md @@ -36,24 +36,25 @@ For updates of LLVM that typically just update a bug, we cherry-pick the bugfix to the branch we're already using. The steps for this are: 1. Make sure the bugfix is in upstream LLVM. -2. Identify the branch that rustc is currently using. The `src/llvm` submodule - is always pinned to a branch of the - [rust-lang/llvm](https://github.com/rust-lang/llvm) repository. -3. Fork the rust-lang/llvm repository -4. Check out the appropriate branch (typically named `rust-llvm-release-*`) +2. Identify the branch that rustc is currently using. The `src/llvm-project` + submodule is always pinned to a branch of the + [rust-lang/llvm-project](https://github.com/rust-lang/llvm-project) repository. +3. Fork the rust-lang/llvm-project repository +4. Check out the appropriate branch (typically named `rustc/a.b-yyyy-mm-dd`) 5. Cherry-pick the upstream commit onto the branch 6. Push this branch to your fork -7. Send a Pull Request to rust-lang/llvm to the same branch as before +7. Send a Pull Request to rust-lang/llvm-project to the same branch as before 8. Wait for the PR to be merged -9. Send a PR to rust-lang/rust updating the `src/llvm` submodule with your bugfix +9. Send a PR to rust-lang/rust updating the `src/llvm-project` submodule with + your bugfix 10. Wait for PR to be merged The tl;dr; is that we can cherry-pick bugfixes at any time and pull them back -into the rust-lang/llvm branch that we're using, and getting it into the +into the rust-lang/llvm-project branch that we're using, and getting it into the compiler is just updating the submodule via a PR! Example PRs look like: -[#56313](https://github.com/rust-lang/rust/pull/56313) +[#59089](https://github.com/rust-lang/rust/pull/59089) ## Feature updates @@ -66,37 +67,28 @@ lot more work. This is where we can't reasonably cherry-pick commits backwards so we need to do a full update. There's a lot of stuff to do here, so let's go through each in detail. -1. Create new branches in all repositories for this update. Branches should be - named `rust-llvm-release-X-Y-Z-vA` where `X.Y.Z` is the LLVM version and `A` - is just increasing based on if there's previous branches of this name. All - repositories here should be branched at the same time from the upstream LLVM - projects, we currently use https://github.com/llvm-mirror repositories. The - list of repositories that need a new branch are: - - * rust-lang/llvm - * rust-lang/compiler-rt - * rust-lang/lld - * rust-lang-nursery/lldb - * rust-lang-nursery/clang - -2. Apply Rust-specific patches to LLVM repositories. All features and bugfixes - are upstream, but there's often some weird build-related patches that don't - make sense to upstream which we have on our repositories. These patches are - typically the latest patches on the branch. All repositories, except `clang`, - currently have Rust-specific patches. +1. Create a new branch in the rust-lang/llvm-project repository. This branch + should be named `rustc/a.b-yyyy-mm-dd` where `a.b` is the current version + number of LLVM in-tree at the time of the branch and the remaining part is + today's date. + +2. Apply Rust-specific patches to the llvm-project repository. All features and + bugfixes are upstream, but there's often some weird build-related patches + that don't make sense to upstream which we have on our repositories. These + patches are around the latest patches in the rust-lang/llvm-project branch + that rustc is currently using. 3. Update the `compiler-rt` submodule in the - `rust-lang-nursery/compiler-builtins` repository. Push this update to a - `rust-llvm-release-*` branch of the `compiler-builtins` repository. + `rust-lang-nursery/compiler-builtins` repository. Push this update to the + same branch name of the `llvm-project` submodule to the + of the `rust-lang/compiler-rt` repository. Then push this update to a branch + of `compiler-builtins` with the same-named branch. Note that this step is + frequently optional since we may not need to update `compiler-rt`. 4. Prepare a commit to rust-lang/rust - * Update `src/llvm` - * Update `src/tools/lld` - * Update `src/tools/lldb` - * Update `src/tools/clang` - * Update `src/libcompiler_builtins - * Edit `src/rustllvm/llvm-rebuild-trigger` to update its contents + * Update `src/llvm-project` + * Update `compiler-builtins` crate in `Cargo.lock` (if necessary) 5. Build your commit. Make sure you've committed the previous changes to ensure submodule updates aren't reverted. Some commands you should execute are: From 786d85c10e602effdc7439bb2e5def811ba5d086 Mon Sep 17 00:00:00 2001 From: Nicolas Date: Wed, 1 May 2019 03:58:22 -0300 Subject: [PATCH 0547/1812] Remove IRC from discussion chats --- src/compiler-team.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index b837c038c..0f0808b79 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -9,12 +9,9 @@ contributions to rustc and its design. ## Discussion -Currently the compiler team chats in a number of places. There is an -ongoing [thread] on the internals board about trying to find a permanent -home. In any case, you can find people in one of three places at the moment: +Currently the compiler team chats in 2 places: -- The `#rustc` channel on mozilla's IRC (`irc.mozilla.org`) -- The `t-compiler` stream on [the Zulip instance](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler) +- The `t-compiler` stream on [the Zulip instance][zulip] - The `compiler` channel on the [rust-lang discord](https://discord.gg/rust-lang) ## Expert map @@ -50,14 +47,11 @@ The meeting currently takes place on Thursdays at 10am Boston time (UTC-4 typically, but daylight savings time sometimes makes things complicated). -The meeting is held over a "chat medium" — it used to be IRC, but we -are currently in the process of evaluating other alternatives. Check -the [etherpad] to find the current home (and see -[this internals thread][thread] for some ongoing discussion). +The meeting is held over a "chat medium", currently on [zulip]. [etherpad]: https://public.etherpad-mozilla.org/p/rust-compiler-meeting -[thread]: https://internals.rust-lang.org/t/where-should-the-compiler-team-and-perhaps-working-groups-chat/7894 [procedure]: https://forge.rust-lang.org/rustc-bug-fix-procedure.html +[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler ## Team membership From b05cfab80bdffd50da2390a45e1f4424a62d0f61 Mon Sep 17 00:00:00 2001 From: guilherme Date: Fri, 26 Apr 2019 23:47:16 +0100 Subject: [PATCH 0548/1812] Fix link in walkthrough --- src/walkthrough.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/walkthrough.md b/src/walkthrough.md index 2823426be..e2e96fced 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -258,6 +258,8 @@ After this, [a PR is made][stab] to remove the feature gate, enabling the featur default (on the 2018 edition). A note is added to the [Release notes][relnotes] about the feature. +[stab]: https://github.com/rust-lang/rust/pull/56245 + Steps to stabilize the feature can be found at [Stabilizing Features](./stabilization_guide.md). [relnotes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md From 2ecb52cb2dd088b994c03cf44cf2aa3a8095f70d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1aki=20Garay?= Date: Fri, 3 May 2019 12:37:09 -0300 Subject: [PATCH 0549/1812] Added mention of universal ctags --- src/how-to-build-and-run.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 241852b19..6d5bcb916 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -300,11 +300,19 @@ in other sections: ### ctags -One of the challenges with rustc is that the RLS can't handle it, since it's a bootstrapping -compiler. This makes code navigation difficult. One solution is to use `ctags`. The following -script can be used to set it up: [https://github.com/nikomatsakis/rust-etags][etags]. +One of the challenges with rustc is that the RLS can't handle it, since it's a +bootstrapping compiler. This makes code navigation difficult. One solution is to +use `ctags`. -CTAGS integrates into emacs and vim quite easily. The following can then be +`ctags` has a long history and several variants. Exhuberant CTags seems to be +quite commonly distributed but it does not have out-of-box Rust support. Some +distributions seem to use [Universal Ctags][utags], which is a maintained fork +and does have built-in Rust support. + +The following script can be used to set up Exhuberant Ctags: +[https://github.com/nikomatsakis/rust-etags][etags]. + +`ctags` integrates into emacs and vim quite easily. The following can then be used to build and generate tags: ```console @@ -315,6 +323,7 @@ This allows you to do "jump-to-def" with whatever functions were around when you last built, which is ridiculously useful. [etags]: https://github.com/nikomatsakis/rust-etags +[utags]: https://github.com/universal-ctags/ctags ### Cleaning out build directories From 2b8280f113c6715f047c6550f530c4064f796027 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 3 May 2019 15:45:04 +0900 Subject: [PATCH 0550/1812] Rename to RUSTC_LOG --- src/compiler-debugging.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 2e45e5f02..db7f08e46 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -149,7 +149,7 @@ $ # Cool, now I have a backtrace for the error These crates are used in compiler for logging: * [log] -* [env-logger]: check the link to see the full `RUST_LOG` syntax +* [env-logger]: check the link to see the full `RUSTC_LOG` syntax [log]: https://docs.rs/log/0.4.6/log/index.html [env-logger]: https://docs.rs/env_logger/0.4.3/env_logger/ @@ -159,9 +159,9 @@ at many points. These are very useful to at least narrow down the location of a bug if not to find it entirely, or just to orient yourself as to why the compiler is doing a particular thing. -To see the logs, you need to set the `RUST_LOG` environment variable to +To see the logs, you need to set the `RUSTC_LOG` environment variable to your log filter, e.g. to get the logs for a specific module, you can run the -compiler as `RUST_LOG=module::path rustc my-file.rs`. All `debug!` output will +compiler as `RUSTC_LOG=module::path rustc my-file.rs`. All `debug!` output will then appear in standard error. **Note that unless you use a very strict filter, the logger will emit a lot of @@ -174,16 +174,16 @@ So to put it together. ```bash # This puts the output of all debug calls in `librustc/traits` into # standard error, which might fill your console backscroll. -$ RUST_LOG=rustc::traits rustc +local my-file.rs +$ RUSTC_LOG=rustc::traits rustc +local my-file.rs # This puts the output of all debug calls in `librustc/traits` in # `traits-log`, so you can then see it with a text editor. -$ RUST_LOG=rustc::traits rustc +local my-file.rs 2>traits-log +$ RUSTC_LOG=rustc::traits rustc +local my-file.rs 2>traits-log # Not recommended. This will show the output of all `debug!` calls # in the Rust compiler, and there are a *lot* of them, so it will be # hard to find anything. -$ RUST_LOG=debug rustc +local my-file.rs 2>all-log +$ RUSTC_LOG=debug rustc +local my-file.rs 2>all-log # This will show the output of all `info!` calls in `rustc_trans`. # @@ -192,7 +192,7 @@ $ RUST_LOG=debug rustc +local my-file.rs 2>all-log # which function triggers an LLVM assertion, and this is an `info!` # log rather than a `debug!` log so it will work on the official # compilers. -$ RUST_LOG=rustc_trans=info rustc +local my-file.rs +$ RUSTC_LOG=rustc_trans=info rustc +local my-file.rs ``` ### How to keep or remove `debug!` and `trace!` calls from the resulting binary @@ -201,7 +201,7 @@ While calls to `error!`, `warn!` and `info!` are included in every build of the calls to `debug!` and `trace!` are only included in the program if `debug-assertions=yes` is turned on in config.toml (it is turned off by default), so if you don't see `DEBUG` logs, especially -if you run the compiler with `RUST_LOG=rustc rustc some.rs` and only see +if you run the compiler with `RUSTC_LOG=rustc rustc some.rs` and only see `INFO` logs, make sure that `debug-assertions=yes` is turned on in your config.toml. @@ -230,7 +230,7 @@ If in the module `rustc::foo` you have a statement debug!("{:?}", random_operation(tcx)); ``` -Then if someone runs a debug `rustc` with `RUST_LOG=rustc::bar`, then +Then if someone runs a debug `rustc` with `RUSTC_LOG=rustc::bar`, then `random_operation()` will run. This means that you should not put anything too expensive or likely to crash From 3cb727b62b953d59b4360d39aa68b6dc8f157655 Mon Sep 17 00:00:00 2001 From: Tom Mulvaney Date: Wed, 17 Apr 2019 18:29:11 +0100 Subject: [PATCH 0551/1812] Fix typo, 'which' repeated twice --- src/traits/chalk-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 4d1260ddc..54f6c3394 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -122,7 +122,7 @@ This rule dictates that `Vec: Clone` is only satisfied if `T: Clone` is also satisfied (i.e. "provable"). Similar to [`chalk::program::Program`][chalk-program] which has "rust-like -things", chalk_ir defines [`ProgramEnvironment`] which which is "pure logic". +things", chalk_ir defines [`ProgramEnvironment`] which is "pure logic". The main field in that struct is `program_clauses`, which contains the [`ProgramClause`]s generated by the rules module. From 243863e48700f35641d3f39b0a9f666e9bbd2444 Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Tue, 14 May 2019 13:10:04 +0200 Subject: [PATCH 0552/1812] Add documentation about profile-guided optimization. --- src/SUMMARY.md | 1 + src/profile-guided-optimization.md | 132 +++++++++++++++++++++++++++++ 2 files changed, 133 insertions(+) create mode 100644 src/profile-guided-optimization.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 477b9a707..c33d15f3c 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -85,6 +85,7 @@ - [Debugging LLVM](./codegen/debugging.md) - [Emitting Diagnostics](./diag.md) - [JSON diagnostic format](./diag/json-format.md) +- [Profile-guided Optimization](./profile-guided-optimization.md) --- diff --git a/src/profile-guided-optimization.md b/src/profile-guided-optimization.md new file mode 100644 index 000000000..fb897e901 --- /dev/null +++ b/src/profile-guided-optimization.md @@ -0,0 +1,132 @@ +# Profile Guided Optimization + +`rustc` supports doing profile-guided optimization (PGO). +This chapter describes what PGO is and how the support for it is +implemented in `rustc`. + +## What Is Profiled-Guided Optimization? + +The basic concept of PGO is to collect data about the typical execution of +a program (e.g. which branches it is likely to take) and then use this data +to inform optimizations such as inlining, machine-code layout, +register allocation, etc. + +There are different ways of collecting data about a program's execution. +One is to run the program inside a profiler (such as `perf`) and another +is to create an instrumented binary, that is, a binary that has data +collection built into it, and run that. +The latter usually provides more accurate data. + +## How is PGO implemented in `rustc`? + +`rustc` current PGO implementation relies entirely on LLVM. +LLVM actually [supports multiple forms][clang-pgo] of PGO: + +[clang-pgo]: https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization + +- Sampling-based PGO where an external profiling tool like `perf` is used + to collect data about a program's execution. +- GCOV-based profiling, where code coverage infrastructure is used to collect + profiling information. +- Front-end based instrumentation, where the compiler front-end (e.g. Clang) + inserts instrumentation intrinsics into the LLVM IR it generates. +- IR-level instrumentation, where LLVM inserts the instrumentation intrinsics + itself during optimization passes. + +`rustc` supports only the last approach, IR-level instrumentation, mainly +because it is almost exclusively implemented in LLVM and needs little +maintenance on the Rust side. Fortunately, it is also the most modern approach, +yielding the best results. + +So, we are dealing with an instrumentation-based approach, i.e. profiling data +is generated by a specially instrumented version of the program that's being +optimized. Instrumentation-based PGO has two components: a compile-time +component and run-time component, and one needs to understand the overall +workflow to see how they interact. + +### Overall Workflow + +Generating a PGO-optimized program involves the following four steps: + +1. Compile the program with instrumentation enabled (e.g. `rustc -Cprofile-generate main.rs`) +2. Run the instrumented program (e.g. `./main`) which generates a `default-.profraw` file +3. Convert the `.profraw` file into a `.profdata` file using LLVM's `llvm-profdata` tool. +4. Compile the program again, this time making use of the profiling data + (e.g. `rustc -Cprofile-use=merged.profdata main.rs`) + +### Compile-Time Aspects + +Depending on which step in the above workflow we are in, two different things +can happen at compile time: + +#### Create Binaries with Instrumentation + +As mentioned above, the profiling instrumentation is added by LLVM. +`rustc` instructs LLVM to do so [by setting the appropriate][pgo-gen-passmanager] +flags when creating LLVM `PassManager`s: + +```C + // `PMBR` is an `LLVMPassManagerBuilderRef` + unwrap(PMBR)->EnablePGOInstrGen = true; + // Instrumented binaries have a default output path for the `.profraw` file + // hard-coded into them: + unwrap(PMBR)->PGOInstrGen = PGOGenPath; +``` + +`rustc` also has to make sure that some of the symbols from LLVM's profiling +runtime are not removed [by marking the with the right export level][pgo-gen-symbols]. + +[pgo-gen-passmanager]: https://github.com/rust-lang/rust/blob/1.34.1/src/rustllvm/PassWrapper.cpp#L412-L416 +[pgo-gen-symbols]:https://github.com/rust-lang/rust/blob/1.34.1/src/librustc_codegen_ssa/back/symbol_export.rs#L212-L225 + + +#### Compile Binaries Where Optimizations Make Use Of Profiling Data + +In the final step of the workflow described above, the program is compiled +again, with the compiler using the gathered profiling data in order to drive +optimization decisions. `rustc` again leaves most of the work to LLVM here, +basically [just telling][pgo-use-passmanager] the LLVM `PassManagerBuilder` +where the profiling data can be found: + +```C + unwrap(PMBR)->PGOInstrUse = PGOUsePath; +``` + +[pgo-use-passmanager]: https://github.com/rust-lang/rust/blob/1.34.1/src/rustllvm/PassWrapper.cpp#L417-L420 + +LLVM does the rest (e.g. setting branch weights, marking functions with +`cold` or `inlinehint`, etc). + + +### Runtime Aspects + +Instrumentation-based approaches always also have a runtime component, i.e. +once we have an instrumented program, that program needs to be run in order +to generate profiling data, and collecting and persisting this profiling +data needs some infrastructure in place. + +In the case of LLVM, these runtime components are implemented in +[compiler-rt][compiler-rt-profile] and statically linked into any instrumented +binaries. +The `rustc` version of this can be found in `src/libprofiler_builtins` which +basically packs the C code from `compiler-rt` into a Rust crate. + +In order for `libprofiler_builtins` to be built, `profiler = true` must be set +in `rustc`'s `config.toml`. + +[compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/master/compiler-rt/lib/profile + +## Testing PGO + +Since the PGO workflow spans multiple compiler invocations most testing happens +in [run-make tests][rmake-tests] (the relevant tests have `pgo` in their name). +There is also a [codegen test][codegen-test] that checks that some expected +instrumentation artifacts show up in LLVM IR. + +[rmake-tests]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps +[codegen-test]: https://github.com/rust-lang/rust/blob/master/src/test/codegen/pgo-instrumentation.rs + +## Additional Information + +Clang's documentation contains a good overview on PGO in LLVM here: +https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization From 2972cf43a871c6df1b5c4c2efb5f27e7a9dfcb15 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1aki=20Garay?= Date: Wed, 15 May 2019 11:21:26 -0300 Subject: [PATCH 0553/1812] Fixed links broken by merging chalks rules and solve --- src/traits/chalk-overview.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 54f6c3394..0a95585f6 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -126,10 +126,10 @@ things", chalk_ir defines [`ProgramEnvironment`] which is "pure logic". The main field in that struct is `program_clauses`, which contains the [`ProgramClause`]s generated by the rules module. -### Rules ([chalk_rules]) +### Rules ([chalk_solve]) -The `chalk_rules` crate ([source code][chalk_rules]) defines the logic rules we use -for each item in the Rust IR. It works by iterating over every trait, impl, +The `chalk_solve` crate ([source code][chalk_solve]) defines the logic rules we +use for each item in the Rust IR. It works by iterating over every trait, impl, etc. and emitting the rules that come from each one. *See also: [Lowering Rules][lowering-rules]* @@ -137,7 +137,7 @@ etc. and emitting the rules that come from each one. #### Well-formedness checks As part of lowering to logic, we also do some "well formedness" checks. See -the [`chalk_rules::wf` source code][rules-wf-src] for where those are done. +the [`chalk_solve::wf` source code][solve-wf-src] for where those are done. *See also: [Well-formedness checking][wf-checking]* @@ -163,12 +163,11 @@ Chalk's functionality is broken up into the following crates: - [**chalk_ir**][chalk_ir]: Defines chalk's internal representation of types, lifetimes, and goals. - [**chalk_solve**][chalk_solve]: Combines `chalk_ir` and `chalk_engine`, - effectively. + effectively, which implements logic rules converting `chalk_rust_ir` to + `chalk_ir` + - Defines the `coherence` module, which implements coherence rules - [`chalk_engine::context`][engine-context] provides the necessary hooks. - [**chalk_parse**][chalk_parse]: Defines the raw AST and a parser. -- [**chalk_rules**][chalk_rules]: which implements logic rules converting - `chalk_rust_ir` to `chalk_ir` - - Defines the `coherence` module, which implements coherence rules - [**chalk**][doc-chalk]: Brings everything together. Defines the following modules: - `chalk::lowering`, which converts AST to `chalk_rust_ir` @@ -236,7 +235,6 @@ Likewise, lowering tests use the [`lowering_success!` and [chalk_ir]: https://rust-lang.github.io/chalk/doc/chalk_ir/index.html [chalk_parse]: https://rust-lang.github.io/chalk/doc/chalk_parse/index.html [chalk_solve]: https://rust-lang.github.io/chalk/doc/chalk_solve/index.html -[chalk_rules]: https://rust-lang.github.io/chalk/doc/chalk_rules/index.html [chalk_rust_ir]: https://rust-lang.github.io/chalk/doc/chalk_rust_ir/index.html [doc-chalk]: https://rust-lang.github.io/chalk/doc/chalk/index.html [engine-context]: https://rust-lang.github.io/chalk/doc/chalk_engine/context/index.html @@ -250,9 +248,9 @@ Likewise, lowering tests use the [`lowering_success!` and [chalk-test-wf]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf/test.rs#L1 [chalki]: https://rust-lang.github.io/chalk/doc/chalki/index.html [clause]: https://github.com/rust-lang/chalk/blob/master/GLOSSARY.md#clause -[coherence-src]: http://rust-lang.github.io/chalk/doc/chalk_rules/coherence/index.html +[coherence-src]: http://rust-lang.github.io/chalk/doc/chalk_solve/coherence/index.html [ir-code]: http://rust-lang.github.io/chalk/doc/chalk_rust_ir/ -[rules-wf-src]: http://rust-lang.github.io/chalk/doc/chalk_rules/wf/index.html +[solve-wf-src]: http://rust-lang.github.io/chalk/doc/chalk_solve/wf/index.html [solve_goal]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L85 [test-lowering-macros]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test_util.rs#L21-L54 [test-macro]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L33 From 72bafaca4f1b958a471d178c0483e7390e63384e Mon Sep 17 00:00:00 2001 From: varkor Date: Wed, 15 May 2019 08:58:20 +0100 Subject: [PATCH 0554/1812] Mention running tests for subdirectories --- src/how-to-build-and-run.md | 4 ++++ src/tests/running.md | 21 ++++++++++++++++++--- 2 files changed, 22 insertions(+), 3 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 6d5bcb916..9b205c7b1 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -297,6 +297,10 @@ in other sections: more details): - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd - `./x.py test --stage 1 src/test/run-pass` – runs the `run-pass` test suite + - `./x.py test --stage 1 src/test/ui/const-generics` - runs all the tests in + the `const-generics/` subdirectory of the `ui` test suite + - `./x.py test --stage 1 src/test/ui/const-generics/const-types.rs` - runs + the single test `const-types.rs` from the `ui` test suite ### ctags diff --git a/src/tests/running.md b/src/tests/running.md index 1250fa77b..5a05c156f 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -47,6 +47,19 @@ the debuginfo test suite: > ./x.py test --stage 1 src/test/debuginfo ``` +If you only need to test a specific subdirectory of tests for any +given test suite, you can pass that directory to `x.py test`: + +```bash +> ./x.py test --stage 1 src/test/ui/const-generics +``` + +Likewise, you can test a single file by passing its path: + +```bash +> ./x.py test --stage 1 src/test/ui/const-generics/const-test.rs +``` + ### Run only the tidy script ```bash @@ -82,8 +95,9 @@ work well with procedural macros or custom derive tests. ## Running an individual test Another common thing that people want to do is to run an **individual -test**, often the test they are trying to fix. One way to do this is -to invoke `x.py` with the `--test-args` option: +test**, often the test they are trying to fix. As mentioned earlier, +you may pass the full file path to achieve this, or alternatively one +may invoke `x.py` with the `--test-args` option: ```bash > ./x.py test --stage 1 src/test/ui --test-args issue-1234 @@ -91,7 +105,8 @@ to invoke `x.py` with the `--test-args` option: Under the hood, the test runner invokes the standard rust test runner (the same one you get with `#[test]`), so this command would wind up -filtering for tests that include "issue-1234" in the name. +filtering for tests that include "issue-1234" in the name. (Thus +`--test-args` is a good way to run a collection of related tests.) ## Using incremental compilation From 673b4a4b4ca04d9ec1ec57222da82189dad7ffaa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1aki=20Garay?= Date: Wed, 17 Apr 2019 10:44:59 -0300 Subject: [PATCH 0555/1812] Added rustc phases diagram and explanation Added rustc build phase diagram and explanation --- src/SUMMARY.md | 2 +- src/how-to-build-and-run.md | 270 ++++++++++++++++++++++++++++++------ src/img/rustc_stages.svg | 2 + 3 files changed, 230 insertions(+), 44 deletions(-) create mode 100644 src/img/rustc_stages.svg diff --git a/src/SUMMARY.md b/src/SUMMARY.md index c33d15f3c..ca8f4adaa 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -6,7 +6,7 @@ - [Part 1: Building, debugging, and contributing to Rustc](./part-1-intro.md) - [About the compiler team](./compiler-team.md) -- [How to build the compiler and run what you built](./how-to-build-and-run.md) +- [How to Build and Run the Compiler](./how-to-build-and-run.md) - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) - [Documenting Compiler](./compiler-documenting.md) - [The compiler testing framework](./tests/intro.md) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 9b205c7b1..4eb4023c4 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -1,4 +1,4 @@ -# How to build the compiler and run what you built +# How to Build and Run the Compiler The compiler is built using a tool called `x.py`. You will need to have Python installed to run it. But before we get to that, if you're going to @@ -29,7 +29,7 @@ assertions = true [rust] # This enables some assertions, but more importantly it enables the `debug!` -# logging macros that are essential for debugging rustc. +# logging macros that are essential for debugging `rustc`. debug-assertions = true # This will make your build more parallel; it costs a bit of runtime @@ -43,31 +43,39 @@ debuginfo = true debuginfo-lines = true ``` -### What is x.py? +### What is `x.py`? -x.py is the script used to orchestrate the tooling in the rustc repository. -It is the script that can build docs, run tests, and compile rustc. -It is the now preferred way to build rustc and it replaces the old makefiles -from before. Below are the different ways to utilize x.py in order to +`x.py` is the script used to orchestrate the tooling in the `rustc` repository. +It is the script that can build docs, run tests, and compile `rustc`. +It is the now preferred way to build `rustc` and it replaces the old makefiles +from before. Below are the different ways to utilize `x.py` in order to effectively deal with the repo for various common tasks. -### Running x.py and building a stage1 compiler +### Running `x.py` and building a stage1 compiler One thing to keep in mind is that `rustc` is a _bootstrapping_ compiler. That is, since `rustc` is written in Rust, we need to use an older version of the compiler to compile the newer version. In -particular, the newer version of the compiler, `libstd`, and other -tooling may use some unstable features internally. The result is that -compiling `rustc` is done in stages: - -- **Stage 0:** the stage0 compiler is usually the current _beta_ compiler - (`x.py` will download it for you); you can configure `x.py` to use something - else, though. +particular, the newer version of the compiler and some of the artifacts needed +to build it, such as `libstd` and other tooling, may use some unstable features +internally, requiring a specific version which understands these unstable +features. + +The result is that compiling `rustc` is done in stages: + +- **Stage 0:** the stage0 compiler is usually (you can configure `x.py` to use + something else) the current _beta_ `rustc` compiler and its associated dynamic + libraries (which `x.py` will download for you). This stage0 compiler is then + used only to compile `rustbuild`, `std`, `test`, and `rustc`. When compiling + `test` and `rustc`, this stage0 compiler uses the freshly compiled `std`. + There are two concepts at play here: a compiler (with its set of dependencies) + and its 'target' or 'object' libraries (`std`, `test`, and `rustc`). + Both are staged, but in a staggered manner. - **Stage 1:** the code in your clone (for new version) is then compiled with the stage0 compiler to produce the stage1 compiler. However, it was built with an older compiler (stage0), so to - optimize the stage1 compiler we go to next stage. - - (In theory, the stage1 compiler is functionally identical to the + optimize the stage1 compiler we go to next the stage. + - In theory, the stage1 compiler is functionally identical to the stage2 compiler, but in practice there are subtle differences. In particular, the stage1 compiler itself was built by stage0 and hence not by the source in your working directory: this means that @@ -75,22 +83,197 @@ compiling `rustc` is done in stages: symbol names that would have been made by the stage1 compiler. This can be important when using dynamic linking (e.g., with derives. Sometimes this means that some tests don't work when run - with stage1.) + with stage1. - **Stage 2:** we rebuild our stage1 compiler with itself to produce the stage2 compiler (i.e. it builds itself) to have all the _latest optimizations_. (By default, we copy the stage1 libraries for use by the stage2 compiler, since they ought to be identical.) -- _(Optional)_ **Stage 3**: to sanity check of our new compiler, we +- _(Optional)_ **Stage 3**: to sanity check our new compiler, we can build the libraries with the stage2 compiler. The result ought to be identical to before, unless something has broken. +#### A note on stage meanings + +When running `x.py` you will see output such as: + +```txt +Building stage0 std artifacts +Copying stage0 std from stage0 +Building stage0 test artifacts +Copying stage0 test from stage0 +Building stage0 compiler artifacts +Copying stage0 rustc from stage0 +Building LLVM for x86_64-apple-darwin +Building stage0 codegen artifacts +Assembling stage1 compiler +Building stage1 std artifacts +Copying stage1 std from stage1 +Building stage1 test artifacts +Copying stage1 test from stage1 +Building stage1 compiler artifacts +Copying stage1 rustc from stage1 +Building stage1 codegen artifacts +Assembling stage2 compiler +Uplifting stage1 std +Copying stage2 std from stage1 +Generating unstable book md files +Building stage0 tool unstable-book-gen +Building stage0 tool rustbook +Documenting standalone +Building rustdoc for stage2 +Documenting book redirect pages +Documenting stage2 std +Building rustdoc for stage1 +Documenting stage2 test +Documenting stage2 whitelisted compiler +Documenting stage2 compiler +Documenting stage2 rustdoc +Documenting error index +Uplifting stage1 test +Copying stage2 test from stage1 +Uplifting stage1 rustc +Copying stage2 rustc from stage1 +Building stage2 tool error_index_generator +``` + +A deeper look into `x.py`'s phases can be seen here: + +A diagram of the rustc compilation phases + +Keep in mind this diagram is a simplification, i.e. `rustdoc` can be built at +different stages, the process is a bit different when passing flags such as +`--keep-stage`, or if there are non-host targets. + +The following tables indicate the outputs of various stage actions: + +| Stage 0 Action | Output | +|-----------------------------------------------------------|----------------------------------------------| +| `beta` extracted | `build/HOST/stage0` | +| `stage0` builds `bootstrap` | `build/bootstrap` | +| `stage0` builds `libstd` | `build/HOST/stage0-std/TARGET` | +| copy `stage0-std` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | +| `stage0` builds `libtest` with `stage0-sysroot` | `build/HOST/stage0-test/TARGET` | +| copy `stage0-test` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | +| `stage0` builds `rustc` with `stage0-sysroot` | `build/HOST/stage0-rustc/HOST` | +| copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | +| build `llvm` | `build/HOST/llvm` | +| `stage0` builds `codegen` with `stage0-sysroot` | `build/HOST/stage0-codgen/HOST` | +| `stage0` builds `rustdoc` with `stage0-sysroot` | `build/HOST/stage0-tools/HOST` | + +`--stage=0` stops here. + +| Stage 1 Action | Output | +|-----------------------------------------------------|---------------------------------------| +| copy (uplift) `stage0-rustc` executable to `stage1` | `build/HOST/stage1/bin` | +| copy (uplift) `stage0-codegen` to `stage1` | `build/HOST/stage1/lib` | +| copy (uplift) `stage0-sysroot` to `stage1` | `build/HOST/stage1/lib` | +| `stage1` builds `libstd` | `build/HOST/stage1-std/TARGET` | +| copy `stage1-std` (HOST only) | `build/HOST/stage1/lib/rustlib/HOST` | +| `stage1` builds `libtest` | `build/HOST/stage1-test/TARGET` | +| copy `stage1-test` (HOST only) | `build/HOST/stage1/lib/rustlib/HOST` | +| `stage1` builds `rustc` | `build/HOST/stage1-rustc/HOST` | +| copy `stage1-rustc` (except executable) | `build/HOST/stage1/lib/rustlib/HOST` | +| `stage1` builds `codegen` | `build/HOST/stage1-codegen/HOST` | + +`--stage=1` stops here. + +| Stage 2 Action | Output | +|-------------------------------------------|-----------------------------------------------------------------| +| copy (uplift) `stage1-rustc` executable | `build/HOST/stage2/bin` | +| copy (uplift) `stage1-sysroot` | `build/HOST/stage2/lib and build/HOST/stage2/lib/rustlib/HOST` | +| `stage2` builds `libstd` (except HOST?) | `build/HOST/stage2-std/TARGET` | +| copy `stage2-std` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | +| `stage2` builds `libtest` (except HOST?) | `build/HOST/stage2-test/TARGET` | +| copy `stage2-test` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | +| `stage2` builds `rustdoc` | `build/HOST/stage2-tools/HOST` | +| copy `rustdoc` | `build/HOST/stage2/bin` | + +`--stage=2` stops here. + +Note that the convention `x.py` uses is that: +- A "stage N artifact" is an artifact that is _produced_ by the stage N compiler. +- The "stage (N+1) compiler" is assembled from "stage N artifacts". +- A `--stage N` flag means build _with_ stage N. + +In short, _stage 0 uses the stage0 compiler to create stage0 artifacts which +will later be uplifted to stage1_. + +Every time any of the main artifacts (`std`, `test`, `rustc`) are compiled, two +steps are performed. +When `std` is compiled by a stage N compiler, that `std` will be linked to +programs built by the stage N compiler (including test and `rustc` built later +on). It will also be used by the stage (N+1) compiler to link against itself. +This is somewhat intuitive if one thinks of the stage (N+1) compiler as "just" +another program we are building with the stage N compiler. In some ways, `rustc` +(the binary, not the `rustbuild` step) could be thought of as one of the few +`no_core` binaries out there. + +So "stage0 std artifacts" are in fact the output of the downloaded stage0 +compiler, and are going to be used for anything built by the stage0 compiler: +e.g. `rustc`, `test` artifacts. When it announces that it is "building stage1 +std artifacts" it has moved on to the next bootstrapping phase. This pattern +continues in latter stages. + +Also note that building host `std` and target `std` are different based on the +stage (e.g. see in the table how stage2 only builds non-host `std` targets. +This is because during stage2, the host `std` is uplifted from the "stage 1" +`std` -- specifically, when "Building stage 1 artifacts" is announced, it is +later copied into stage2 as well (both the compiler's `libdir` and the +`sysroot`). + +This `std` is pretty much necessary for any useful work with the compiler. +Specifically, it's used as the `std` for programs compiled by the newly compiled +compiler (so when you compile `fn main() { }` it is linked to the last `std` +compiled with `x.py build --stage 1 src/libstd`). + +The `rustc` generated by the stage0 compiler is linked to the freshly-built +`libstd`, which means that for the most part only `std` needs to be cfg-gated, +so that `rustc` can use featured added to std immediately after their addition, +without need for them to get into the downloaded beta. The `libstd` built by the +`stage1/bin/rustc` compiler, also known as "stage1 std artifacts", is not +necessarily ABI-compatible with that compiler. +That is, the `rustc` binary most likely could not use this `std` itself. +It is however ABI-compatible with any programs that the `stage1/bin/rustc` +binary builds (including itself), so in that sense they're paired. + +This is also where `--keep-stage 1 src/libstd` comes into play. Since most +changes to the compiler don't actually change the ABI, once you've produced a +`libstd` in stage 1, you can probably just reuse it with a different compiler. +If the ABI hasn't changed, you're good to go, no need to spend the time +recompiling that `std`. +`--keep-stage` simply assumes the previous compile is fine and copies those +artifacts into the appropriate place, skipping the cargo invocation. + +The reason we first build `std`, then `test`, then `rustc`, is largely just +because we want to minimize `cfg(stage0)` in the code for `rustc`. +Currently `rustc` is always linked against a "new" `std`/`test` so it doesn't +ever need to be concerned with differences in std; it can assume that the std is +as fresh as possible. + +The reason we need to build it twice is because of ABI compatibility. +The beta compiler has it's own ABI, and then the `stage1/bin/rustc` compiler +will produce programs/libraries with the new ABI. +We used to build three times, but because we assume that the ABI is constant +within a codebase, we presume that the libraries produced by the "stage2" +compiler (produced by the `stage1/bin/rustc` compiler) is ABI-compatible with +the `stage1/bin/rustc` compiler's produced libraries. +What this means is that we can skip that final compilation -- and simply use the +same libraries as the `stage2/bin/rustc` compiler uses itself for programs it +links against. + +This `stage2/bin/rustc` compiler is shipped to end-users, along with the +`stage 1 {std,test,rustc}` artifacts. + +If you want to learn more about `x.py`, read its README.md +[here](https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md). + #### Build Flags -There are other flags you can pass to the build portion of x.py that can be +There are other flags you can pass to the build command of `x.py` that can be beneficial to cutting down compile times or fitting other things you might need to change. They are: -```bash +```txt Options: -v, --verbose use verbose output (-vv for very verbose) -i, --incremental use incremental compilation @@ -127,16 +310,17 @@ probably the best "go to" command for building a local rust: This may *look* like it only builds libstd, but that is not the case. What this command does is the following: -- Build libstd using the stage0 compiler (using incremental) -- Build librustc using the stage0 compiler (using incremental) +- Build `libstd` using the stage0 compiler (using incremental) +- Build `librustc` using the stage0 compiler (using incremental) - This produces the stage1 compiler - Build libstd using the stage1 compiler (cannot use incremental) This final product (stage1 compiler + libs built using that compiler) -is what you need to build other rust programs. +is what you need to build other rust programs (unless you use `#![no_std]` or +`#![no_core]`). -Note that the command includes the `-i` switch. This enables incremental -compilation. This will be used to speed up the first two steps of the process: +The command includes the `-i` switch which enables incremental compilation. +This will be used to speed up the first two steps of the process: in particular, if you make a small change, we ought to be able to use your old results to make producing the stage1 **compiler** faster. @@ -145,15 +329,15 @@ stage1 libraries. This is because incremental only works when you run the *same compiler* twice in a row. In this case, we are building a *new stage1 compiler* every time. Therefore, the old incremental results may not apply. **As a result, you will probably find that -building the stage1 libstd is a bottleneck for you** -- but fear not, +building the stage1 `libstd` is a bottleneck for you** -- but fear not, there is a (hacky) workaround. See [the section on "recommended workflows"](#workflow) below. -Note that this whole command just gives you a subset of the full rustc -build. The **full** rustc build (what you get if you just say `./x.py +Note that this whole command just gives you a subset of the full `rustc` +build. The **full** `rustc` build (what you get if you just say `./x.py build`) has quite a few more steps: -- Build librustc and rustc with the stage1 compiler. +- Build `librustc` and `rustc` with the stage1 compiler. - The resulting compiler here is called the "stage2" compiler. - Build libstd with stage2 compiler. - Build librustdoc and a bunch of other things with the stage2 compiler. @@ -185,12 +369,11 @@ compile. Using these commands you can test that it compiles before doing a bigger build to make sure it works with the compiler. As shown before you can also pass flags at the end such as --stage. - ### Creating a rustup toolchain -Once you have successfully built rustc, you will have created a bunch +Once you have successfully built `rustc`, you will have created a bunch of files in your `build` directory. In order to actually run the -resulting rustc, we recommend creating rustup toolchains. The first +resulting `rustc`, we recommend creating rustup toolchains. The first one will run the stage1 compiler (which we built above). The second will execute the stage2 compiler (which we did not build, but which you will likely need to build at some point; for example, if you want @@ -207,7 +390,7 @@ The `` would typically be one of the following: - Mac: `x86_64-apple-darwin` - Windows: `x86_64-pc-windows-msvc` -Now you can run the rustc you built with. If you run with `-vV`, you +Now you can run the `rustc` you built with. If you run with `-vV`, you should see a version number ending in `-dev`, indicating a build from your local environment: @@ -226,8 +409,7 @@ LLVM version: 4.0 ### Suggested workflows for faster builds of the compiler -There are two workflows that are useful for faster builds of the -compiler. +There are two workflows that are useful for faster builds of the compiler. **Check, check, and check again.** The first workflow, which is useful when doing simple refactorings, is to run `./x.py check` @@ -257,12 +439,15 @@ The sequence of commands you want is as follows: - Initial build: `./x.py build -i --stage 1 src/libstd` - As [documented above](#command), this will build a functional - stage1 compiler + stage1 compiler as part of running all stage0 commands (which include + building a `libstd` compatible with the stage1 compiler) as well as the + first few steps of the "stage 1 actions" up to "stage1 (sysroot stage1) + builds libstd". - Subsequent builds: `./x.py build -i --stage 1 src/libstd --keep-stage 1` - Note that we added the `--keep-stage 1` flag here -The effect of `--keep-stage 1` is that we just *assume* that the old -standard library can be re-used. If you are editing the compiler, this +As mentioned, the effect of `--keep-stage 1` is that we just *assume* that the +old standard library can be re-used. If you are editing the compiler, this is almost always true: you haven't changed the standard library, after all. But sometimes, it's not true: for example, if you are editing the "metadata" part of the compiler, which controls how the compiler @@ -276,15 +461,14 @@ using `--keep-stage 1`** -- for example, strange should simply remove the `--keep-stage 1` from the command and rebuild. That ought to fix the problem. -You can also use `--keep-stage 1` when running tests. Something like -this: +You can also use `--keep-stage 1` when running tests. Something like this: - Initial test run: `./x.py test -i --stage 1 src/test/ui` - Subsequent test run: `./x.py test -i --stage 1 src/test/ui --keep-stage 1` -### Other x.py commands +### Other `x.py` commands -Here are a few other useful x.py commands. We'll cover some of them in detail +Here are a few other useful `x.py` commands. We'll cover some of them in detail in other sections: - Building things: diff --git a/src/img/rustc_stages.svg b/src/img/rustc_stages.svg new file mode 100644 index 000000000..b6671aa7c --- /dev/null +++ b/src/img/rustc_stages.svg @@ -0,0 +1,2 @@ + +
Download
Download
beta
beta
stage0
stage0
Builds
Builds
stage0
stage0
Outputs
Outputs
libstd
libstd
Copy
Copy
stage0-std
stage0-std
stage0-sysroot
stage0-sysroot
Builds
Builds
stage0
stage0
Outputs
Outputs
libtest
libtest
Copy
Copy
stage0-test
stage0-test
stage0-sysroot
stage0-sysroot
Builds
Builds
stage0
stage0
Outputs
Outputs
rustc
rustc
Copy
Copy
stage0-rustc
stage0-rustc
stage0-sysroot
stage0-sysroot
llvm
llvm
Builds
Builds
stage0
stage0
Outputs
Outputs
codegen
codegen
stage0-codegen
stage0-codegen
Stage 0
Stage 0
Copy
Copy
stage0-rustc
stage0-codegen
stage0-sysroot
[Not supported by viewer]
stage1
stage1
Builds
Builds
stage1
stage1
Outputs
Outputs
libstd
libstd
Copy
Copy
stage1-std
stage1-std
stage1/lib/rustlib
stage1/lib/rustlib
Builds
Builds
stage1
stage1
Outputs
Outputs
libtest
libtest
Copy
Copy
stage1-test
stage1-test
stage1/lib/rustlib
stage1/lib/rustlib
Builds
Builds
stage1
stage1
Outputs
Outputs
rustc
rustc
Copy
Copy
stage1-rustc
stage1-rustc
stage1/lib/rustlib
stage1/lib/rustlib
Builds
Builds
stage1
stage1
Outputs
Outputs
codegen
codegen
stage1-codegen
stage1-codegen
Stage 1
[Not supported by viewer]
Copy
Copy
stage1-rustc
stage1-codegen
stage1/lib/rustlib
[Not supported by viewer]
stage2
stage2
Builds
Builds
stage2
stage2
Outputs
Outputs
rustdoc
rustdoc
Copy
[Not supported by viewer]
stage2-tools
stage2-tools
Builds
Builds
stage0
stage0
bootstrap
bootstrap
llvm
llvm
stage2
stage2
Stage 2
[Not supported by viewer] \ No newline at end of file From 14b243de252da65e26dc3f60676d288f8c2af8b6 Mon Sep 17 00:00:00 2001 From: Julian Wollersberger Date: Fri, 17 May 2019 17:38:29 +0200 Subject: [PATCH 0556/1812] Renamed the file and title of the diagnostics chapter. When I recently searched for infos in this guide on how to create a warning, I couldn't find any. Later I found it through #14. The reason was that I didn't know the term 'diagnostics' and that it is the collective term for errors, warnings and lints. Renaming the chapter to include the word 'error' should help. I think also including 'warning' in the title shouldn't be neccessary, because it's close enought. --- src/SUMMARY.md | 4 ++-- src/appendix/code-index.md | 2 +- src/{diag.md => diagnostics.md} | 2 +- src/{diag => diagnostics}/json-format.md | 0 src/implementing_new_features.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) rename src/{diag.md => diagnostics.md} (99%) rename src/{diag => diagnostics}/json-format.md (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ca8f4adaa..3d5dd44b6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -21,6 +21,8 @@ - [with the linux perf tool](./profiling/with_perf.md) - [Coding conventions](./conventions.md) - [crates.io Dependencies](./crates-io.md) +- [Emitting Errors and other Diagnostics](diagnostics.md) + - [JSON diagnostic format](diagnostics/json-format.md) --- @@ -83,8 +85,6 @@ - [Code Generation](./codegen.md) - [Updating LLVM](./codegen/updating-llvm.md) - [Debugging LLVM](./codegen/debugging.md) -- [Emitting Diagnostics](./diag.md) - - [JSON diagnostic format](./diag/json-format.md) - [Profile-guided Optimization](./profile-guided-optimization.md) --- diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 3c71d6bba..222c9b2db 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -38,7 +38,7 @@ Item | Kind | Short description | Chapter | [Type checking]: ../type-checking.html [The `ty` modules]: ../ty.html [Rustdoc]: ../rustdoc.html -[Emitting Diagnostics]: ../diag.html +[Emitting Diagnostics]: ../diagnostics.html [Macro expansion]: ../macro-expansion.html [Name resolution]: ../name-resolution.html [Parameter Environment]: ../param_env.html diff --git a/src/diag.md b/src/diagnostics.md similarity index 99% rename from src/diag.md rename to src/diagnostics.md index 31268e9f6..f3d518764 100644 --- a/src/diag.md +++ b/src/diagnostics.md @@ -1,4 +1,4 @@ -# Emitting Diagnostics +# Emitting Errors and other Diagnostics A lot of effort has been put into making `rustc` have great error messages. This chapter is about how to emit compile errors and lints from the compiler. diff --git a/src/diag/json-format.md b/src/diagnostics/json-format.md similarity index 100% rename from src/diag/json-format.md rename to src/diagnostics/json-format.md diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 8105e1474..6d1327fab 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -49,7 +49,7 @@ In some cases, a feature or bugfix might break some existing programs in some edge cases. In that case, you might want to do a crater run to assess the impact and possibly add a future-compatibility lint, similar to those used for -[edition-gated lints](./diag.md#edition-gated-lints). +[edition-gated lints](diagnostics.md#edition-gated-lints). ### Stability From 2755796a2926bb946fe794b42ea65bf664c5e9e2 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 28 May 2019 17:13:08 -0300 Subject: [PATCH 0557/1812] Add more info subsection with links to forge and rustc api docs --- src/about-this-guide.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 30a3b8870..8376fb2a3 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -16,4 +16,15 @@ be found at the [GitHub repository]. If you find any mistakes in the guide, please file an issue about it, or even better, open a PR with a correction! +## Other places to find information + +You might also find the following sites useful: + +- [Rustc API docs] -- rustdoc documentation for the compiler +- [Forge] -- contains documentation about rust infrastructure, team procedures, and more +- [compiler-team] -- the home-base for the rust compiler team, with description of the team procedures, active working groups, and the team calendar. + [GitHub repository]: https://github.com/rust-lang/rustc-guide/ +[Rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ +[Forge]: https://forge.rust-lang.org/ +[compiler-team]: https://github.com/rust-lang/compiler-team/ From c2ced29a082e201fe51e974c62ff6ddb862ffb11 Mon Sep 17 00:00:00 2001 From: Vallentin Date: Thu, 30 May 2019 21:09:46 +0200 Subject: [PATCH 0558/1812] Fixed misspelling --- src/borrow_check/moves_and_initialization.md | 2 +- src/queries/query-evaluation-model-in-detail.md | 2 +- src/traits/slg.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/borrow_check/moves_and_initialization.md b/src/borrow_check/moves_and_initialization.md index d1530d6c0..043db2f53 100644 --- a/src/borrow_check/moves_and_initialization.md +++ b/src/borrow_check/moves_and_initialization.md @@ -7,7 +7,7 @@ figuring out where moves occur and tracking those. ## Initialization and moves From a user's perspective, initialization -- giving a variable some -value -- and moves -- transfering ownership to another place -- might +value -- and moves -- transferring ownership to another place -- might seem like distinct topics. Indeed, our borrow checker error messages often talk about them differently. But **within the borrow checker**, they are not nearly as separate. Roughly speaking, the borrow checker diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 47412acef..7772f36be 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -204,7 +204,7 @@ OK as long as the mutation is not observable. This is achieved by two things: This is not an ideal setup because of the manual intervention needed, so it should be used sparingly and only when it is well known which queries might access a given result. In practice, however, stealing has not turned out to be -much of a maintainance burden. +much of a maintenance burden. To summarize: "Steal queries" break some of the rules in a controlled way. There are checks in place that make sure that nothing can go silently wrong. diff --git a/src/traits/slg.md b/src/traits/slg.md index 98547575d..948d3fc8a 100644 --- a/src/traits/slg.md +++ b/src/traits/slg.md @@ -147,7 +147,7 @@ are both represented with an index.) For each strand, we also optionally store a *selected subgoal*. This is the subgoal after the turnstile (`:-`) that we are currently trying -to prove in this strand. Initally, when a strand is first created, +to prove in this strand. Initially, when a strand is first created, there is no selected subgoal. [`ExClause`]: https://rust-lang.github.io/chalk/doc/chalk_engine/struct.ExClause.html From 52d423e1b3fe7e59d4a4fc910bbaee3b794114dd Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 2 Jun 2019 19:28:14 -0500 Subject: [PATCH 0559/1812] fix long line --- src/about-this-guide.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 8376fb2a3..df060a208 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -22,7 +22,8 @@ You might also find the following sites useful: - [Rustc API docs] -- rustdoc documentation for the compiler - [Forge] -- contains documentation about rust infrastructure, team procedures, and more -- [compiler-team] -- the home-base for the rust compiler team, with description of the team procedures, active working groups, and the team calendar. +- [compiler-team] -- the home-base for the rust compiler team, with description + of the team procedures, active working groups, and the team calendar. [GitHub repository]: https://github.com/rust-lang/rustc-guide/ [Rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ From 3ac9cfc9c9ab2e366feebf18718112737f572352 Mon Sep 17 00:00:00 2001 From: Vadim Petrochenkov Date: Fri, 31 May 2019 13:54:39 +0400 Subject: [PATCH 0560/1812] Update information about debuginfo configuration --- src/compiler-debugging.md | 2 +- src/how-to-build-and-run.md | 8 +++----- src/profiling/with_perf.md | 8 ++++---- 3 files changed, 8 insertions(+), 10 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index db7f08e46..304f75d80 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -47,7 +47,7 @@ stack backtrace: ``` If you want line numbers for the stack trace, you can enable -`debuginfo-lines=true` or `debuginfo=true` in your config.toml and rebuild the +`debuginfo-level = 1` or `debuginfo-level = 2` in your config.toml and rebuild the compiler. Then the backtrace will look like this: ```text diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 4eb4023c4..d0ba0ea57 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -36,11 +36,9 @@ debug-assertions = true # performance perhaps (less inlining) but it's worth it. codegen-units = 0 -# I always enable full debuginfo, though debuginfo-lines is more important. -debuginfo = true - -# Gives you line numbers for backtraces. -debuginfo-lines = true +# I always enable full debuginfo, however the line debuginfo (which is a more important part +# and enables e.g. line numbers in backtraces) is enabled by `debuginfo-level = 1` too. +debuginfo-level = 2 ``` ### What is `x.py`? diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 258899400..2634cc260 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -7,15 +7,15 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or - Get a clean checkout of rust-lang/master, or whatever it is you want to profile. - Set the following settings in your `config.toml`: - - `debuginfo-lines = true` - - `use-jemalloc = false` — lets you do memory use profiling with valgrind + - `debuginfo-level = 1` - enables line debuginfo + - `use-jemalloc = false` - lets you do memory use profiling with valgrind - leave everything else the defaults - Run `./x.py build` to get a full build - Make a rustup toolchain pointing to that result - see [the "build and run" section for instructions][b-a-r] [b-a-r]: ../how-to-build-and-run.html#toolchain - + ## Gathering a perf profile perf is an excellent tool on linux that can be used to gather and @@ -295,7 +295,7 @@ altogether ("total") and the percent of time spent in **just that function and not some callee of that function** (self). Usually "total" is the more interesting number, but not always. -### Relative percentages +### Relative percentages By default, all in perf-focus are relative to the **total program execution**. This is useful to help you keep perspective — often as From 2290cd10370f071582cba5fe771e69dbe44ab0a5 Mon Sep 17 00:00:00 2001 From: mdsimmo Date: Tue, 4 Jun 2019 13:44:58 +1000 Subject: [PATCH 0561/1812] correct indentation Indentation consistently 4 spaces and Part 1/Part2 contain everything else --- src/SUMMARY.md | 157 ++++++++++++++++++++++++------------------------- 1 file changed, 77 insertions(+), 80 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 3d5dd44b6..2b519da75 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -5,87 +5,84 @@ --- - [Part 1: Building, debugging, and contributing to Rustc](./part-1-intro.md) -- [About the compiler team](./compiler-team.md) -- [How to Build and Run the Compiler](./how-to-build-and-run.md) - - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) - - [Documenting Compiler](./compiler-documenting.md) -- [The compiler testing framework](./tests/intro.md) - - [Running tests](./tests/running.md) - - [Adding new tests](./tests/adding.md) - - [Using `compiletest` + commands to control test execution](./compiletest.md) -- [Walkthrough: a typical contribution](./walkthrough.md) -- [Implementing new features](./implementing_new_features.md) -- [Stabilizing Features](./stabilization_guide.md) -- [Debugging the Compiler](./compiler-debugging.md) -- [Profiling the compiler](./profiling.md) - - [with the linux perf tool](./profiling/with_perf.md) -- [Coding conventions](./conventions.md) -- [crates.io Dependencies](./crates-io.md) -- [Emitting Errors and other Diagnostics](diagnostics.md) - - [JSON diagnostic format](diagnostics/json-format.md) - ---- - + - [About the compiler team](./compiler-team.md) + - [How to Build and Run the Compiler](./how-to-build-and-run.md) + - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) + - [Documenting Compiler](./compiler-documenting.md) + - [The compiler testing framework](./tests/intro.md) + - [Running tests](./tests/running.md) + - [Adding new tests](./tests/adding.md) + - [Using `compiletest` + commands to control test execution](./compiletest.md) + - [Walkthrough: a typical contribution](./walkthrough.md) + - [Implementing new features](./implementing_new_features.md) + - [Stabilizing Features](./stabilization_guide.md) + - [Debugging the Compiler](./compiler-debugging.md) + - [Profiling the compiler](./profiling.md) + - [with the linux perf tool](./profiling/with_perf.md) + - [Coding conventions](./conventions.md) + - [crates.io Dependencies](./crates-io.md) + - [Emitting Errors and other Diagnostics](diagnostics.md) + - [JSON diagnostic format](diagnostics/json-format.md) - [Part 2: How rustc works](./part-2-intro.md) -- [High-level overview of the compiler source](./high-level-overview.md) -- [The Rustc Driver and Interface](./rustc-driver.md) - - [Rustdoc](./rustdoc.md) -- [Queries: demand-driven compilation](./query.md) - - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) - - [Incremental compilation](./queries/incremental-compilation.md) - - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) - - [Debugging and Testing](./incrcomp-debugging.md) -- [The parser](./the-parser.md) -- [`#[test]` Implementation](./test-implementation.md) -- [Macro expansion](./macro-expansion.md) -- [Name resolution](./name-resolution.md) -- [The HIR (High-level IR)](./hir.md) - - [Lowering AST to HIR](./lowering.md) - - [Debugging](./hir-debugging.md) -- [The `ty` module: representing types](./ty.md) -- [Kinds](./kinds.md) -- [Type inference](./type-inference.md) -- [Trait solving (old-style)](./traits/resolution.md) - - [Higher-ranked trait bounds](./traits/hrtb.md) - - [Caching subtleties](./traits/caching.md) - - [Specialization](./traits/specialization.md) -- [Trait solving (new-style)](./traits/index.md) - - [Lowering to logic](./traits/lowering-to-logic.md) - - [Goals and clauses](./traits/goals-and-clauses.md) - - [Equality and associated types](./traits/associated-types.md) - - [Implied bounds](./traits/implied-bounds.md) - - [Region constraints](./traits/regions.md) - - [The lowering module in rustc](./traits/lowering-module.md) - - [Lowering rules](./traits/lowering-rules.md) - - [Well-formedness checking](./traits/wf.md) - - [Canonical queries](./traits/canonical-queries.md) - - [Canonicalization](./traits/canonicalization.md) - - [The SLG solver](./traits/slg.md) - - [An Overview of Chalk](./traits/chalk-overview.md) - - [Bibliography](./traits/bibliography.md) -- [Type checking](./type-checking.md) - - [Method Lookup](./method-lookup.md) - - [Variance](./variance.md) - - [Existential Types](./existential-types.md) -- [The MIR (Mid-level IR)](./mir/index.md) - - [MIR construction](./mir/construction.md) - - [MIR visitor and traversal](./mir/visitor.md) - - [MIR passes: getting the MIR for a function](./mir/passes.md) - - [MIR optimizations](./mir/optimizations.md) - - [Debugging](./mir/debugging.md) -- [The borrow checker](./borrow_check.md) - - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) - - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) - - [MIR type checker](./borrow_check/type_check.md) - - [Region inference](./borrow_check/region_inference.md) - - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) -- [Constant evaluation](./const-eval.md) - - [miri const evaluator](./miri.md) -- [Parameter Environments](./param_env.md) -- [Code Generation](./codegen.md) - - [Updating LLVM](./codegen/updating-llvm.md) - - [Debugging LLVM](./codegen/debugging.md) -- [Profile-guided Optimization](./profile-guided-optimization.md) + - [High-level overview of the compiler source](./high-level-overview.md) + - [The Rustc Driver and Interface](./rustc-driver.md) + - [Rustdoc](./rustdoc.md) + - [Queries: demand-driven compilation](./query.md) + - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) + - [Incremental compilation](./queries/incremental-compilation.md) + - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) + - [Debugging and Testing](./incrcomp-debugging.md) + - [The parser](./the-parser.md) + - [`#[test]` Implementation](./test-implementation.md) + - [Macro expansion](./macro-expansion.md) + - [Name resolution](./name-resolution.md) + - [The HIR (High-level IR)](./hir.md) + - [Lowering AST to HIR](./lowering.md) + - [Debugging](./hir-debugging.md) + - [The `ty` module: representing types](./ty.md) + - [Kinds](./kinds.md) + - [Type inference](./type-inference.md) + - [Trait solving (old-style)](./traits/resolution.md) + - [Higher-ranked trait bounds](./traits/hrtb.md) + - [Caching subtleties](./traits/caching.md) + - [Specialization](./traits/specialization.md) + - [Trait solving (new-style)](./traits/index.md) + - [Lowering to logic](./traits/lowering-to-logic.md) + - [Goals and clauses](./traits/goals-and-clauses.md) + - [Equality and associated types](./traits/associated-types.md) + - [Implied bounds](./traits/implied-bounds.md) + - [Region constraints](./traits/regions.md) + - [The lowering module in rustc](./traits/lowering-module.md) + - [Lowering rules](./traits/lowering-rules.md) + - [Well-formedness checking](./traits/wf.md) + - [Canonical queries](./traits/canonical-queries.md) + - [Canonicalization](./traits/canonicalization.md) + - [The SLG solver](./traits/slg.md) + - [An Overview of Chalk](./traits/chalk-overview.md) + - [Bibliography](./traits/bibliography.md) + - [Type checking](./type-checking.md) + - [Method Lookup](./method-lookup.md) + - [Variance](./variance.md) + - [Existential Types](./existential-types.md) + - [The MIR (Mid-level IR)](./mir/index.md) + - [MIR construction](./mir/construction.md) + - [MIR visitor and traversal](./mir/visitor.md) + - [MIR passes: getting the MIR for a function](./mir/passes.md) + - [MIR optimizations](./mir/optimizations.md) + - [Debugging](./mir/debugging.md) + - [The borrow checker](./borrow_check.md) + - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) + - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) + - [MIR type checker](./borrow_check/type_check.md) + - [Region inference](./borrow_check/region_inference.md) + - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) + - [Constant evaluation](./const-eval.md) + - [miri const evaluator](./miri.md) + - [Parameter Environments](./param_env.md) + - [Code Generation](./codegen.md) + - [Updating LLVM](./codegen/updating-llvm.md) + - [Debugging LLVM](./codegen/debugging.md) + - [Profile-guided Optimization](./profile-guided-optimization.md) --- From 9015f537ab88bd8db00bfdc3144b452409d8d915 Mon Sep 17 00:00:00 2001 From: mdsimmo Date: Tue, 4 Jun 2019 14:11:06 +1000 Subject: [PATCH 0562/1812] Replaced tabs with spaces --- src/SUMMARY.md | 154 ++++++++++++++++++++++++------------------------- 1 file changed, 77 insertions(+), 77 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 2b519da75..e83898520 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -5,84 +5,84 @@ --- - [Part 1: Building, debugging, and contributing to Rustc](./part-1-intro.md) - - [About the compiler team](./compiler-team.md) - - [How to Build and Run the Compiler](./how-to-build-and-run.md) - - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) - - [Documenting Compiler](./compiler-documenting.md) - - [The compiler testing framework](./tests/intro.md) - - [Running tests](./tests/running.md) - - [Adding new tests](./tests/adding.md) - - [Using `compiletest` + commands to control test execution](./compiletest.md) - - [Walkthrough: a typical contribution](./walkthrough.md) - - [Implementing new features](./implementing_new_features.md) - - [Stabilizing Features](./stabilization_guide.md) - - [Debugging the Compiler](./compiler-debugging.md) - - [Profiling the compiler](./profiling.md) - - [with the linux perf tool](./profiling/with_perf.md) - - [Coding conventions](./conventions.md) - - [crates.io Dependencies](./crates-io.md) - - [Emitting Errors and other Diagnostics](diagnostics.md) - - [JSON diagnostic format](diagnostics/json-format.md) + - [About the compiler team](./compiler-team.md) + - [How to Build and Run the Compiler](./how-to-build-and-run.md) + - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) + - [Documenting Compiler](./compiler-documenting.md) + - [The compiler testing framework](./tests/intro.md) + - [Running tests](./tests/running.md) + - [Adding new tests](./tests/adding.md) + - [Using `compiletest` + commands to control test execution](./compiletest.md) + - [Walkthrough: a typical contribution](./walkthrough.md) + - [Implementing new features](./implementing_new_features.md) + - [Stabilizing Features](./stabilization_guide.md) + - [Debugging the Compiler](./compiler-debugging.md) + - [Profiling the compiler](./profiling.md) + - [with the linux perf tool](./profiling/with_perf.md) + - [Coding conventions](./conventions.md) + - [crates.io Dependencies](./crates-io.md) + - [Emitting Errors and other Diagnostics](diagnostics.md) + - [JSON diagnostic format](diagnostics/json-format.md) - [Part 2: How rustc works](./part-2-intro.md) - - [High-level overview of the compiler source](./high-level-overview.md) - - [The Rustc Driver and Interface](./rustc-driver.md) - - [Rustdoc](./rustdoc.md) - - [Queries: demand-driven compilation](./query.md) - - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) - - [Incremental compilation](./queries/incremental-compilation.md) - - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) - - [Debugging and Testing](./incrcomp-debugging.md) - - [The parser](./the-parser.md) - - [`#[test]` Implementation](./test-implementation.md) - - [Macro expansion](./macro-expansion.md) - - [Name resolution](./name-resolution.md) - - [The HIR (High-level IR)](./hir.md) - - [Lowering AST to HIR](./lowering.md) - - [Debugging](./hir-debugging.md) - - [The `ty` module: representing types](./ty.md) - - [Kinds](./kinds.md) - - [Type inference](./type-inference.md) - - [Trait solving (old-style)](./traits/resolution.md) - - [Higher-ranked trait bounds](./traits/hrtb.md) - - [Caching subtleties](./traits/caching.md) - - [Specialization](./traits/specialization.md) - - [Trait solving (new-style)](./traits/index.md) - - [Lowering to logic](./traits/lowering-to-logic.md) - - [Goals and clauses](./traits/goals-and-clauses.md) - - [Equality and associated types](./traits/associated-types.md) - - [Implied bounds](./traits/implied-bounds.md) - - [Region constraints](./traits/regions.md) - - [The lowering module in rustc](./traits/lowering-module.md) - - [Lowering rules](./traits/lowering-rules.md) - - [Well-formedness checking](./traits/wf.md) - - [Canonical queries](./traits/canonical-queries.md) - - [Canonicalization](./traits/canonicalization.md) - - [The SLG solver](./traits/slg.md) - - [An Overview of Chalk](./traits/chalk-overview.md) - - [Bibliography](./traits/bibliography.md) - - [Type checking](./type-checking.md) - - [Method Lookup](./method-lookup.md) - - [Variance](./variance.md) - - [Existential Types](./existential-types.md) - - [The MIR (Mid-level IR)](./mir/index.md) - - [MIR construction](./mir/construction.md) - - [MIR visitor and traversal](./mir/visitor.md) - - [MIR passes: getting the MIR for a function](./mir/passes.md) - - [MIR optimizations](./mir/optimizations.md) - - [Debugging](./mir/debugging.md) - - [The borrow checker](./borrow_check.md) - - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) - - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) - - [MIR type checker](./borrow_check/type_check.md) - - [Region inference](./borrow_check/region_inference.md) - - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) - - [Constant evaluation](./const-eval.md) - - [miri const evaluator](./miri.md) - - [Parameter Environments](./param_env.md) - - [Code Generation](./codegen.md) - - [Updating LLVM](./codegen/updating-llvm.md) - - [Debugging LLVM](./codegen/debugging.md) - - [Profile-guided Optimization](./profile-guided-optimization.md) + - [High-level overview of the compiler source](./high-level-overview.md) + - [The Rustc Driver and Interface](./rustc-driver.md) + - [Rustdoc](./rustdoc.md) + - [Queries: demand-driven compilation](./query.md) + - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) + - [Incremental compilation](./queries/incremental-compilation.md) + - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) + - [Debugging and Testing](./incrcomp-debugging.md) + - [The parser](./the-parser.md) + - [`#[test]` Implementation](./test-implementation.md) + - [Macro expansion](./macro-expansion.md) + - [Name resolution](./name-resolution.md) + - [The HIR (High-level IR)](./hir.md) + - [Lowering AST to HIR](./lowering.md) + - [Debugging](./hir-debugging.md) + - [The `ty` module: representing types](./ty.md) + - [Kinds](./kinds.md) + - [Type inference](./type-inference.md) + - [Trait solving (old-style)](./traits/resolution.md) + - [Higher-ranked trait bounds](./traits/hrtb.md) + - [Caching subtleties](./traits/caching.md) + - [Specialization](./traits/specialization.md) + - [Trait solving (new-style)](./traits/index.md) + - [Lowering to logic](./traits/lowering-to-logic.md) + - [Goals and clauses](./traits/goals-and-clauses.md) + - [Equality and associated types](./traits/associated-types.md) + - [Implied bounds](./traits/implied-bounds.md) + - [Region constraints](./traits/regions.md) + - [The lowering module in rustc](./traits/lowering-module.md) + - [Lowering rules](./traits/lowering-rules.md) + - [Well-formedness checking](./traits/wf.md) + - [Canonical queries](./traits/canonical-queries.md) + - [Canonicalization](./traits/canonicalization.md) + - [The SLG solver](./traits/slg.md) + - [An Overview of Chalk](./traits/chalk-overview.md) + - [Bibliography](./traits/bibliography.md) + - [Type checking](./type-checking.md) + - [Method Lookup](./method-lookup.md) + - [Variance](./variance.md) + - [Existential Types](./existential-types.md) + - [The MIR (Mid-level IR)](./mir/index.md) + - [MIR construction](./mir/construction.md) + - [MIR visitor and traversal](./mir/visitor.md) + - [MIR passes: getting the MIR for a function](./mir/passes.md) + - [MIR optimizations](./mir/optimizations.md) + - [Debugging](./mir/debugging.md) + - [The borrow checker](./borrow_check.md) + - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) + - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) + - [MIR type checker](./borrow_check/type_check.md) + - [Region inference](./borrow_check/region_inference.md) + - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) + - [Constant evaluation](./const-eval.md) + - [miri const evaluator](./miri.md) + - [Parameter Environments](./param_env.md) + - [Code Generation](./codegen.md) + - [Updating LLVM](./codegen/updating-llvm.md) + - [Debugging LLVM](./codegen/debugging.md) + - [Profile-guided Optimization](./profile-guided-optimization.md) --- From af46ee444949b1826d2ba413cdb5025aa91adfba Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 7 Jun 2019 15:34:08 -0500 Subject: [PATCH 0563/1812] use debug instead of debuginfo-level --- src/how-to-build-and-run.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index d0ba0ea57..ca9065ced 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -36,9 +36,10 @@ debug-assertions = true # performance perhaps (less inlining) but it's worth it. codegen-units = 0 -# I always enable full debuginfo, however the line debuginfo (which is a more important part -# and enables e.g. line numbers in backtraces) is enabled by `debuginfo-level = 1` too. -debuginfo-level = 2 +# This enables full debuginfo (`debuginfo-level = 2`). The line debuginfo (which is a +# more important part and enables e.g. line numbers in backtraces) is also enabled by +# `debuginfo-level = 1`. +debug = true ``` ### What is `x.py`? From 53961054c84be0f5e6189aafcf30d0996d1bff40 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 7 Jun 2019 15:51:16 -0500 Subject: [PATCH 0564/1812] Update compiler-debugging.md --- src/compiler-debugging.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 304f75d80..0126c2503 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -46,9 +46,10 @@ stack backtrace: 37: rustc_driver::run_compiler ``` -If you want line numbers for the stack trace, you can enable -`debuginfo-level = 1` or `debuginfo-level = 2` in your config.toml and rebuild the -compiler. Then the backtrace will look like this: +If you want line numbers for the stack trace, you can enable `debug = true` in +your config.toml and rebuild the compiler (`debuginfo-level = 1` will also add +line numbers, but `debug = true` gives full debuginfo). Then the backtrace will +look like this: ```text stack backtrace: From 14f353e9d810897138c62020363a0a7f71902f43 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 7 Jun 2019 16:06:09 -0500 Subject: [PATCH 0565/1812] Update how-to-build-and-run.md --- src/how-to-build-and-run.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index ca9065ced..e0ce70111 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -28,17 +28,15 @@ settings (and possibly others, such as `llvm.ccache`): assertions = true [rust] -# This enables some assertions, but more importantly it enables the `debug!` -# logging macros that are essential for debugging `rustc`. -debug-assertions = true - # This will make your build more parallel; it costs a bit of runtime # performance perhaps (less inlining) but it's worth it. codegen-units = 0 -# This enables full debuginfo (`debuginfo-level = 2`). The line debuginfo (which is a -# more important part and enables e.g. line numbers in backtraces) is also enabled by -# `debuginfo-level = 1`. +# This enables full debuginfo and debug assertions. The line debuginfo is also +# enabled by `debuginfo-level = 1`. Full debuginfo is also enabled by +# `debuginfo-level = 2`. Debug assertions can also be enabled with +# `debug-assertions = true`. Note that `debug = true` will make your build +# slower, so you may want to try individually enabling debuginfo and assertions. debug = true ``` From eda82ca8c9554a27bb24e4e2ca5a3ed67ffa5f16 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 7 Jun 2019 16:07:45 -0500 Subject: [PATCH 0566/1812] Update how-to-build-and-run.md --- src/how-to-build-and-run.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index e0ce70111..f44179bc9 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -36,7 +36,8 @@ codegen-units = 0 # enabled by `debuginfo-level = 1`. Full debuginfo is also enabled by # `debuginfo-level = 2`. Debug assertions can also be enabled with # `debug-assertions = true`. Note that `debug = true` will make your build -# slower, so you may want to try individually enabling debuginfo and assertions. +# slower, so you may want to try individually enabling debuginfo and assertions +# or enable only line debuginfo which is basically free. debug = true ``` From caee05203e8bb65bb9005d13fb25316f80c331b7 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 12 Jun 2019 17:00:07 -0300 Subject: [PATCH 0567/1812] Add triagebot --- triagebot.toml | 1 + 1 file changed, 1 insertion(+) create mode 100644 triagebot.toml diff --git a/triagebot.toml b/triagebot.toml new file mode 100644 index 000000000..fa0824ac5 --- /dev/null +++ b/triagebot.toml @@ -0,0 +1 @@ +[assign] From d97d111c2e2ddcb2007c2211bbea60165785a473 Mon Sep 17 00:00:00 2001 From: Jonas Schievink Date: Wed, 12 Jun 2019 20:01:27 +0200 Subject: [PATCH 0568/1812] Fix a few typos in type inference chapter Also try to test the top example --- src/type-inference.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/type-inference.md b/src/type-inference.md index a3d012b5d..d94c06379 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -6,14 +6,14 @@ expression. It is what allows Rust to work with fewer or no type annotations, making things easier for users: -```rust,ignore +```rust fn main() { let mut things = vec![]; - things.push("thing") + things.push("thing"); } ``` -Here, the type of `things` is *inferenced* to be `&str` because that's the value +Here, the type of `things` is *inferred* to be `Vec<&str>` because of the value we push into `things`. The type inference is based on the standard Hindley-Milner (HM) type inference From 885ab7e860cf7c115f96e053f93fee0e9f25eadf Mon Sep 17 00:00:00 2001 From: Jonathan Behrens Date: Sat, 8 Jun 2019 19:11:04 -0400 Subject: [PATCH 0569/1812] Changes to config.toml require a clean --- src/how-to-build-and-run.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index f44179bc9..92fbcb0fd 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -41,6 +41,9 @@ codegen-units = 0 debug = true ``` +If you have already built `rustc`, then you may have to execute `rm -rf build` for subsequent +configuration changes to take effect. + ### What is `x.py`? `x.py` is the script used to orchestrate the tooling in the `rustc` repository. From 8dfb8c1f9ec7117f317374c5022ad44d83677055 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 15 Jun 2019 16:08:35 -0500 Subject: [PATCH 0570/1812] add note about rebuilding llvm --- src/how-to-build-and-run.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 92fbcb0fd..84efffc84 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -42,7 +42,9 @@ debug = true ``` If you have already built `rustc`, then you may have to execute `rm -rf build` for subsequent -configuration changes to take effect. +configuration changes to take effect. Note that `./x.py clean` will not cause a +rebuild of LLVM, so if your configuration change affects LLVM, you will need to +manually `rm -rf build/` before rebuilding. ### What is `x.py`? From ea6f6b516b24c70498863e74b47d6a7293764e73 Mon Sep 17 00:00:00 2001 From: Blitzerr Date: Thu, 1 Nov 2018 22:14:05 -0700 Subject: [PATCH 0571/1812] Notes about closure de-sugaring --- src/SUMMARY.md | 1 + src/closure.md | 159 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 160 insertions(+) create mode 100644 src/closure.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index e83898520..273b409ec 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -39,6 +39,7 @@ - [The HIR (High-level IR)](./hir.md) - [Lowering AST to HIR](./lowering.md) - [Debugging](./hir-debugging.md) + - [Closure expansion](./closure.md) - [The `ty` module: representing types](./ty.md) - [Kinds](./kinds.md) - [Type inference](./type-inference.md) diff --git a/src/closure.md b/src/closure.md new file mode 100644 index 000000000..3bf965983 --- /dev/null +++ b/src/closure.md @@ -0,0 +1,159 @@ +# Closure Expansion in rustc + +Let's start with a few examples + +### Example 1 +```rust +fn closure(f: impl Fn()) { + f(); +} + +fn main() { + let x: i32 = 10; + closure(|| println!("Hi {}", x)); // The closure just reads x. + println!("Value of x after return {}", x); +} +``` +Let's say the above is the content of a file called immut.rs. If we compile immut.rs using the command +``` +rustc +stage1 immut.rs -Zdump-mir=all +``` +we will see a newly generated directory in our current working directory called mir_dump, which will +contain several files. If we look at file `rustc.main.-------.mir_map.0.mir`, we will find, among +other things, it also contains this line: + +```rust,ignore +_4 = &_1; // bb0[6]: scope 1 at immut.rs:7:13: 7:36 +_3 = [closure@immut.rs:7:13: 7:36] { x: move _4 }; // bb0[7]: scope 1 at immut.rs:7:13: 7:36 +``` +Here in first line `_4 = &_1;`, the mir_dump tells us that x was borrowed as an immutable reference. +This is what we would hope as our closure just reads x. + +### Example 2 +```rust +fn closure(mut f: impl FnMut()) { + f(); +} + +fn main() { + let mut x: i32 = 10; + closure(|| { + x += 10; // The closure mutates the value of x + println!("Hi {}", x) + }); + println!("Value of x after return {}", x); +} +``` + +```rust,ignore +_4 = &mut _1; // bb0[6]: scope 1 at mut.rs:7:13: 10:6 +_3 = [closure@mut.rs:7:13: 10:6] { x: move _4 }; // bb0[7]: scope 1 at mut.rs:7:13: 10:6 +``` +This time along, in the line `_4 = &mut _1;`, we see that the borrow is changed to mutable borrow. +fair enough as the closure increments x by 10. + +### Example 3 +```rust +fn closure(f: impl FnOnce()) { + f(); +} + +fn main() { + let x = vec![21]; + closure(|| { + drop(x); // Makes x unusable after the fact. + }); + // println!("Value of x after return {:?}", x); +} +``` + +```rust,ignore +_6 = [closure@move.rs:7:13: 9:6] { x: move _1 }; // bb16[3]: scope 1 at move.rs:7:13: 9:6 +``` +Here, x is directly moved into the closure and the access to it will not be permitted after the +closure. + + +Now let's dive into rustc code and see how all these inferences are done by the compiler. + +Let's start with defining a term that we will be using quite a bit in the rest of the discussion - +*upvar*. An **upvar** is a variable that is local to the function, where the closure is defined. So, +in the above examples, **x** will be an upvar to the closure. They are also sometimes referred to as +the *free variables* meaning they are not bound to the context of the closure. +`src/librustc/ty/query/mod.rs` defines a query called *freevars* for this purpose. + +So, we know that other than lazy invocation, one other thing that the distinguishes a closure from a +normal function is that it can use the upvars. Because, it borrows these upvars from its surrounding +context, therfore the compiler has to determine the upvar's borrow type. The compiler starts with +assigning an immutable borrow type and lowers the restriction (that is, changes it from +**immutable** to **mutable** to **move**) as needed, based on the usage. In the Example 1 above, the +closure only uses the variable for printing but does not modify it in any way and therefore, in the +mir_dump, we find the borrow type for the upvar x to be immutable. In example 2, however the +closure modifies x and increments it by some value. Because of this mutation, the compiler, which +started off assigning x as an immutable reference type, has to adjust it as mutable reference. +Likewise in the third example, the closure drops the vector and therefore this requires the variable +x to be moved into the closure. Depending on the borrow kind, the closure has to implement the +appropriate trait. Fn trait for immutable borrow, FnMut for mutable borrow and FnOnce for move +semantics. + +Most of the code related to the closure is in the src/librustc_typeck/check/upvar.rs file and the +data structures are declared in the file src/librustc/ty/mod.rs. + +Before we go any further, let's discuss how we can examine the flow of coontrol through the rustc +codebase. For the closure part specifically, I would set the RUST_LOG as under and collect the +output in a file + +``` +RUST_LOG=rustc_typeck::check::upvar rustc +stage1 -Zdump-mir=all <.rs file to compile> 2> +``` + +This uses the stage1 compiler. + +The other option is to step through the code using lldb or gdb. + +``` +1. rust-lldb build/x86_64-apple-darwin/stage1/bin/rustc test.rs +2. b upvar.rs:134 // Setting the breakpoint on a certain line in the upvar.rs file +3. r // Run the program until it hits the breakpoint +``` + +Let's start with the file: `upvar.rs`. This file has something called the euv::ExprUseVisitor which +walks the source of the closure and it gets called back for each upvar that is borrowed, mutated or +moved. + +```rust +fn main() { + let x = vec![21]; + let _cl = || { + let y = x[0]; // 1. + x[0] += 1; // 2. + }; +} +``` + +In the above example, our visitor will be called twice, for the lines marked 1 and 2, once as a +shared borrow and another one as a mutable borrow. It will also tell as what was borrowed. The +callbacks get invoked at the delegate. The delegate is of type `struct InferBorrowKind` which has a +few fields but the one we are interested in is the `adjust_upvar_captures` which is of type +`FxHashMap>` which tells us for each upvar, which mode of borrow did we +require. The modes of borrow can be ByValue (moved) or ByRef (borrowed) and for ByRef borrows, it +can be one among shared, shallow, unique or mut as defined in the `src/librustc/mir/mod.rs` + +The method callbacks are the method implementations of the euv::Delegate trait for InferBorrowKind. +**consume** callback is for *move* of a variable, **borrow** callback if there is a *borrow* of some +kind, shared or mutable and **mutate** when we see an *assignment* of something. We will see that +all these callbacks have a common argument *cmt* which stands for category, Mutability and Type and +is defined in *src/librustc/middle/mem_categorization.rs*. Borrowing from the code comments *cmt *is +a complete categorization of a value indicating where it originated and how it is located, as well +as the mutability of the memory in which the value is stored.** Based on the callback (consume, +borrow etc.), we will call the relevant *adjust_upvar_borrow_kind_for_* and pass the cmt +along. Once the borrow type is adjusted, we store it in the table, which basically says for this +closure, these set of borrows were made. + +``` +self.tables + .borrow_mut() + .upvar_capture_map + .extend(delegate.adjust_upvar_captures); +``` From 9a4ff92b8e151590e98db4c4d9d1b0e8d085533d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 23 Mar 2019 13:47:03 -0500 Subject: [PATCH 0572/1812] Some edits to address review comments --- src/closure.md | 174 ++++++++++++++++++++++++++++++++----------------- 1 file changed, 114 insertions(+), 60 deletions(-) diff --git a/src/closure.md b/src/closure.md index 3bf965983..a31893b0a 100644 --- a/src/closure.md +++ b/src/closure.md @@ -1,8 +1,24 @@ # Closure Expansion in rustc -Let's start with a few examples +This section describes how rustc handles closures. Closures in Rust are +effectively "desugared" into structs that contain the values they use (or +references to the values they use) from their creator's stack frame. rustc has +the job of figuring out which values a closure uses and how, so it can decide +whether to capture a given variable by shared reference, mutable reference, or +by move. rustc also has to figure out which the closure traits ([`Fn`][fn], +[`FnMut`][fn_mut], or [`FnOnce`][fn_once]) a closure is capable of +implementing. + +[fn]: https://doc.rust-lang.org/std/ops/trait.Fn.html +[fn_mut]:https://doc.rust-lang.org/std/ops/trait.FnMut.html +[fn_once]: https://doc.rust-lang.org/std/ops/trait.FnOnce.html + +Let's start with a few examples: ### Example 1 + +To start, let's take a look at how the closure in the following example is desugared: + ```rust fn closure(f: impl Fn()) { f(); @@ -14,22 +30,37 @@ fn main() { println!("Value of x after return {}", x); } ``` -Let's say the above is the content of a file called immut.rs. If we compile immut.rs using the command -``` -rustc +stage1 immut.rs -Zdump-mir=all + +Let's say the above is the content of a file called `immut.rs`. If we compile +`immut.rs` using the following command. The [`-Zdump-mir=all`][dump-mir] flag will cause +`rustc` to generate and dump the [MIR][mir] to a directory called `mir_dump`. +```console +> rustc +stage1 immut.rs -Zdump-mir=all ``` -we will see a newly generated directory in our current working directory called mir_dump, which will -contain several files. If we look at file `rustc.main.-------.mir_map.0.mir`, we will find, among + +[mir]: ./mir/index.md +[dump-mir]: ./mir/passes.md + +After we run this command, we will see a newly generated directory in our +current working directory called `mir_dump`, which will contain several files. +If we look at file `rustc.main.-------.mir_map.0.mir`, we will find, among other things, it also contains this line: ```rust,ignore -_4 = &_1; // bb0[6]: scope 1 at immut.rs:7:13: 7:36 -_3 = [closure@immut.rs:7:13: 7:36] { x: move _4 }; // bb0[7]: scope 1 at immut.rs:7:13: 7:36 +_4 = &_1; +_3 = [closure@immut.rs:7:13: 7:36] { x: move _4 }; ``` -Here in first line `_4 = &_1;`, the mir_dump tells us that x was borrowed as an immutable reference. -This is what we would hope as our closure just reads x. + +Note that in the MIR examples in this chapter, `_1` is `x`. + +Here in first line `_4 = &_1;`, the `mir_dump` tells us that `x` was borrowed +as an immutable reference. This is what we would hope as our closure just +reads `x`. ### Example 2 + +Here is another example: + ```rust fn closure(mut f: impl FnMut()) { f(); @@ -46,13 +77,16 @@ fn main() { ``` ```rust,ignore -_4 = &mut _1; // bb0[6]: scope 1 at mut.rs:7:13: 10:6 -_3 = [closure@mut.rs:7:13: 10:6] { x: move _4 }; // bb0[7]: scope 1 at mut.rs:7:13: 10:6 +_4 = &mut _1; +_3 = [closure@mut.rs:7:13: 10:6] { x: move _4 }; ``` This time along, in the line `_4 = &mut _1;`, we see that the borrow is changed to mutable borrow. -fair enough as the closure increments x by 10. +Fair enough! The closure increments `x` by 10. ### Example 3 + +One more example: + ```rust fn closure(f: impl FnOnce()) { f(); @@ -70,57 +104,66 @@ fn main() { ```rust,ignore _6 = [closure@move.rs:7:13: 9:6] { x: move _1 }; // bb16[3]: scope 1 at move.rs:7:13: 9:6 ``` -Here, x is directly moved into the closure and the access to it will not be permitted after the +Here, `x` is directly moved into the closure and the access to it will not be permitted after the closure. +## Inferences in the compiler Now let's dive into rustc code and see how all these inferences are done by the compiler. Let's start with defining a term that we will be using quite a bit in the rest of the discussion - -*upvar*. An **upvar** is a variable that is local to the function, where the closure is defined. So, +*upvar*. An **upvar** is a variable that is local to the function where the closure is defined. So, in the above examples, **x** will be an upvar to the closure. They are also sometimes referred to as the *free variables* meaning they are not bound to the context of the closure. -`src/librustc/ty/query/mod.rs` defines a query called *freevars* for this purpose. +[`src/librustc/ty/query/mod.rs`][freevars] defines a query called *freevars* for this purpose. -So, we know that other than lazy invocation, one other thing that the distinguishes a closure from a -normal function is that it can use the upvars. Because, it borrows these upvars from its surrounding -context, therfore the compiler has to determine the upvar's borrow type. The compiler starts with +[freevars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/queries/struct.freevars.html + +Other than lazy invocation, one other thing that the distinguishes a closure from a +normal function is that it can use the upvars. It borrows these upvars from its surrounding +context; therfore the compiler has to determine the upvar's borrow type. The compiler starts with assigning an immutable borrow type and lowers the restriction (that is, changes it from **immutable** to **mutable** to **move**) as needed, based on the usage. In the Example 1 above, the closure only uses the variable for printing but does not modify it in any way and therefore, in the -mir_dump, we find the borrow type for the upvar x to be immutable. In example 2, however the -closure modifies x and increments it by some value. Because of this mutation, the compiler, which -started off assigning x as an immutable reference type, has to adjust it as mutable reference. +`mir_dump`, we find the borrow type for the upvar `x` to be immutable. In example 2, however, the +closure modifies `x` and increments it by some value. Because of this mutation, the compiler, which +started off assigning `x` as an immutable reference type, has to adjust it as a mutable reference. Likewise in the third example, the closure drops the vector and therefore this requires the variable -x to be moved into the closure. Depending on the borrow kind, the closure has to implement the -appropriate trait. Fn trait for immutable borrow, FnMut for mutable borrow and FnOnce for move -semantics. +`x` to be moved into the closure. Depending on the borrow kind, the closure has to implement the +appropriate trait: `Fn` trait for immutable borrow, `FnMut` for mutable borrow, +and `FnOnce` for move semantics. + +Most of the code related to the closure is in the +[`src/librustc_typeck/check/upvar.rs`][upvar] file and the data structures are +declared in the file [`src/librustc/ty/mod.rs`][ty]. -Most of the code related to the closure is in the src/librustc_typeck/check/upvar.rs file and the -data structures are declared in the file src/librustc/ty/mod.rs. +[upvar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/upvar/index.html +[ty]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/index.html Before we go any further, let's discuss how we can examine the flow of coontrol through the rustc -codebase. For the closure part specifically, I would set the RUST_LOG as under and collect the -output in a file +codebase. For closures specifically, set the `RUST_LOG` env variable as below and collect the +output in a file: -``` -RUST_LOG=rustc_typeck::check::upvar rustc +stage1 -Zdump-mir=all <.rs file to compile> 2> +```console +> RUST_LOG=rustc_typeck::check::upvar rustc +stage1 -Zdump-mir=all \ + <.rs file to compile> 2> ``` -This uses the stage1 compiler. +This uses the stage1 compiler and enables `debug!` logging for the +`rustc_typeck::check::upvar` module. The other option is to step through the code using lldb or gdb. -``` -1. rust-lldb build/x86_64-apple-darwin/stage1/bin/rustc test.rs -2. b upvar.rs:134 // Setting the breakpoint on a certain line in the upvar.rs file -3. r // Run the program until it hits the breakpoint -``` +1. `rust-lldb build/x86_64-apple-darwin/stage1/bin/rustc test.rs` +2. In lldb: + 1. `b upvar.rs:134` // Setting the breakpoint on a certain line in the upvar.rs file` + 2. `r` // Run the program until it hits the breakpoint + +Let's start with [`upvar.rs`][upvar]. This file has something called +the [`euv::ExprUseVisitor`][euv] which walks the source of the closure and +invokes a callbackfor each upvar that is borrowed, mutated, or moved. -Let's start with the file: `upvar.rs`. This file has something called the euv::ExprUseVisitor which -walks the source of the closure and it gets called back for each upvar that is borrowed, mutated or -moved. +[euv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/middle/expr_use_visitor/struct.ExprUseVisitor.html ```rust fn main() { @@ -132,28 +175,39 @@ fn main() { } ``` -In the above example, our visitor will be called twice, for the lines marked 1 and 2, once as a -shared borrow and another one as a mutable borrow. It will also tell as what was borrowed. The -callbacks get invoked at the delegate. The delegate is of type `struct InferBorrowKind` which has a -few fields but the one we are interested in is the `adjust_upvar_captures` which is of type -`FxHashMap>` which tells us for each upvar, which mode of borrow did we -require. The modes of borrow can be ByValue (moved) or ByRef (borrowed) and for ByRef borrows, it -can be one among shared, shallow, unique or mut as defined in the `src/librustc/mir/mod.rs` - -The method callbacks are the method implementations of the euv::Delegate trait for InferBorrowKind. -**consume** callback is for *move* of a variable, **borrow** callback if there is a *borrow* of some -kind, shared or mutable and **mutate** when we see an *assignment* of something. We will see that -all these callbacks have a common argument *cmt* which stands for category, Mutability and Type and -is defined in *src/librustc/middle/mem_categorization.rs*. Borrowing from the code comments *cmt *is -a complete categorization of a value indicating where it originated and how it is located, as well -as the mutability of the memory in which the value is stored.** Based on the callback (consume, -borrow etc.), we will call the relevant *adjust_upvar_borrow_kind_for_* and pass the cmt -along. Once the borrow type is adjusted, we store it in the table, which basically says for this -closure, these set of borrows were made. +In the above example, our visitor will be called twice, for the lines marked 1 and 2, once for a +shared borrow and another one for a mutable borrow. It will also tell us what was borrowed. -``` +The callbacks are defined by implementing the [`Delegate`][delegate] trait. The +[`InferBorrowKind`][ibk] type implements `Delegate` and keeps a map that +records for each upvar which mode of borrow was required. The modes of borrow +can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be +`shared`, `shallow`, `unique` or `mut` as defined in the +[`src/librustc/mir/mod.rs`][mir_mod]. + +[mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/index.html + +`Delegate` defines a few different methods (the different callbacks): +**consume**: for *move* of a variable, **borrow** for a *borrow* of some kind +(shared or mutable), and **mutate** when we see an *assignment* of something. + +All of these callbacks have a common argument *cmt* which stands for Category, +Mutability and Type and is defined in +[`src/librustc/middle/mem_categorization.rs`][cmt]. Borrowing from the code +comments, "`cmt` is a complete categorization of a value indicating where it +originated and how it is located, as well as the mutability of the memory in +which the value is stored". Based on the callback (consume, borrow etc.), we +will call the relevant *adjust_upvar_borrow_kind_for_* and pass the +`cmt` along. Once the borrow type is adjusted, we store it in the table, which +basically says what borrows were made for each closure. + +```rust,ignore self.tables .borrow_mut() .upvar_capture_map .extend(delegate.adjust_upvar_captures); ``` + +[delegate]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/middle/expr_use_visitor/trait.Delegate.html +[ibk]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/upvar/struct.InferBorrowKind.html +[cmt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/middle/mem_categorization/index.html From c15c60938a65d5a260b2dc14c58424278b59da39 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 15 Jun 2019 16:54:08 -0500 Subject: [PATCH 0573/1812] fix ci failures, typos, broken links --- src/borrow_check/two_phase_borrows.md | 2 +- src/closure.md | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/borrow_check/two_phase_borrows.md b/src/borrow_check/two_phase_borrows.md index 753ffa5b2..09e7fbefe 100644 --- a/src/borrow_check/two_phase_borrows.md +++ b/src/borrow_check/two_phase_borrows.md @@ -15,7 +15,7 @@ two-phase borrow are: To give some examples: -```rust +```rust2018 // In the source code // Case 1: diff --git a/src/closure.md b/src/closure.md index a31893b0a..77f2b42c3 100644 --- a/src/closure.md +++ b/src/closure.md @@ -115,9 +115,9 @@ Let's start with defining a term that we will be using quite a bit in the rest o *upvar*. An **upvar** is a variable that is local to the function where the closure is defined. So, in the above examples, **x** will be an upvar to the closure. They are also sometimes referred to as the *free variables* meaning they are not bound to the context of the closure. -[`src/librustc/ty/query/mod.rs`][freevars] defines a query called *freevars* for this purpose. +[`src/librustc/ty/query/mod.rs`][upvars] defines a query called *upvars* for this purpose. -[freevars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/queries/struct.freevars.html +[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/queries/struct.upvars.html Other than lazy invocation, one other thing that the distinguishes a closure from a normal function is that it can use the upvars. It borrows these upvars from its surrounding @@ -167,7 +167,7 @@ invokes a callbackfor each upvar that is borrowed, mutated, or moved. ```rust fn main() { - let x = vec![21]; + let mut x = vec![21]; let _cl = || { let y = x[0]; // 1. x[0] += 1; // 2. From f675e3694154c11b1ee18ecfb62c3e757c8fdaf2 Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Fri, 14 Jun 2019 19:17:23 +0300 Subject: [PATCH 0574/1812] Update for TyCtxt<'a, 'gcx, 'tcx> -> TyCtxt<'tcx>. --- src/appendix/code-index.md | 2 +- src/appendix/glossary.md | 1 - src/compiler-debugging.md | 10 +++---- src/conventions.md | 3 +- src/mir/visitor.md | 2 +- src/profiling/with_perf.md | 6 ++-- src/query.md | 16 +++++------ src/ty.md | 58 +++++--------------------------------- src/type-inference.md | 5 ++-- 9 files changed, 27 insertions(+), 76 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 222c9b2db..52a7f42d6 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -29,7 +29,7 @@ Item | Kind | Short description | Chapter | `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) -`TyCtxt<'cx, 'tcx, 'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) +`TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) [The HIR]: ../hir.html [Identifiers in the HIR]: ../hir.html#hir-id diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index a5d5bf56a..46c5c9f0f 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -25,7 +25,6 @@ early-bound lifetime | a lifetime region that is substituted at its definiti empty type | see "uninhabited type". Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) -'gcx | the lifetime of the global arena ([see more](../ty.html)) generics | the set of generic type parameters defined on a type or item HIR | the High-level IR, created by lowering and desugaring the AST ([see more](../hir.html)) HirId | identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 0126c2503..8f3a331aa 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -48,7 +48,7 @@ stack backtrace: If you want line numbers for the stack trace, you can enable `debug = true` in your config.toml and rebuild the compiler (`debuginfo-level = 1` will also add -line numbers, but `debug = true` gives full debuginfo). Then the backtrace will +line numbers, but `debug = true` gives full debuginfo). Then the backtrace will look like this: ```text @@ -129,11 +129,11 @@ note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. stack backtrace: (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) - 7: rustc::traits::error_reporting::>::report_selection_error + 7: rustc::traits::error_reporting::> + ::report_selection_error at /home/user/rust/src/librustc/traits/error_reporting.rs:823 - 8: rustc::traits::error_reporting::>::report_fulfillment_errors + 8: rustc::traits::error_reporting::> + ::report_fulfillment_errors at /home/user/rust/src/librustc/traits/error_reporting.rs:160 at /home/user/rust/src/librustc/traits/error_reporting.rs:112 9: rustc_typeck::check::FnCtxt::select_obligations_where_possible diff --git a/src/conventions.md b/src/conventions.md index d9f462a05..a941ebff9 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -141,8 +141,7 @@ to the compiler. - `cx` tends to be short for "context" and is often used as a suffix. For example, `tcx` is a common name for the [Typing Context][tcx]. -- [`'tcx` and `'gcx`][tcx] are used as the lifetime names for the Typing - Context. +- [`'tcx`][tcx] is used as the lifetim names for the Typing Context. - Because `crate` is a keyword, if you need a variable to represent something crate-related, often the spelling is changed to `krate`. diff --git a/src/mir/visitor.md b/src/mir/visitor.md index ad00bc3f1..a5e8e9a0b 100644 --- a/src/mir/visitor.md +++ b/src/mir/visitor.md @@ -15,7 +15,7 @@ state you will need while processing MIR: ```rust,ignore struct MyVisitor<...> { - tcx: TyCtxt<'cx, 'tcx, 'tcx>, + tcx: TyCtxt<'tcx>, ... } ``` diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 2634cc260..7582eece5 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -272,9 +272,9 @@ Tree : : | rustc_mir::borrow_check::nll::type_check::type_check_internal (13% total, 0% self) : : : | core::ops::function::FnOnce::call_once (5% total, 0% self) : : : : | rustc_mir::borrow_check::nll::type_check::liveness::generate (5% total, 3% self) -: : : | as rustc::mir::visit::Visitor<'tcx>>::visit_mir (3% total, 0% self) +: : : | as rustc::mir::visit::Visitor<'tcx>>::visit_mir (3% total, 0% self) : | rustc::mir::visit::Visitor::visit_mir (8% total, 6% self) -: | as rustc_mir::dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (5% total, 0% self) +: | as rustc_mir::dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (5% total, 0% self) : | rustc_mir::dataflow::do_dataflow (3% total, 0% self) ``` @@ -321,7 +321,7 @@ Tree | matched `{do_mir_borrowck}` (100% total, 0% self) : | rustc_mir::borrow_check::nll::compute_regions (47% total, 0% self) [...] : | rustc::mir::visit::Visitor::visit_mir (19% total, 15% self) [...] -: | as rustc_mir::dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (13% total, 0% self) [...] +: | as rustc_mir::dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (13% total, 0% self) [...] : | rustc_mir::dataflow::do_dataflow (8% total, 1% self) [...] ``` diff --git a/src/query.md b/src/query.md index 4d80187aa..4ab1d079e 100644 --- a/src/query.md +++ b/src/query.md @@ -82,17 +82,15 @@ on how that works). Providers always have the same signature: ```rust,ignore -fn provider<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx, 'tcx>, - key: QUERY_KEY) - -> QUERY_RESULT -{ +fn provider<'tcx>( + tcx: TyCtxt<'tcx>, + key: QUERY_KEY, +) -> QUERY_RESULT { ... } ``` -Providers take two arguments: the `tcx` and the query key. Note also -that they take the *global* tcx (i.e. they use the `'tcx` lifetime -twice), rather than taking a tcx with some active inference context. +Providers take two arguments: the `tcx` and the query key. They return the result of the query. #### How providers are setup @@ -103,7 +101,7 @@ is basically a big list of function pointers: ```rust,ignore struct Providers { - type_of: for<'cx, 'tcx> fn(TyCtxt<'cx, 'tcx, 'tcx>, DefId) -> Ty<'tcx>, + type_of: for<'tcx> fn(TyCtxt<'tcx>, DefId) -> Ty<'tcx>, ... } ``` @@ -144,7 +142,7 @@ pub fn provide(providers: &mut Providers) { }; } -fn fubar<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx>, key: DefId) -> Fubar<'tcx> { ... } +fn fubar<'tcx>(tcx: TyCtxt<'tcx>, key: DefId) -> Fubar<'tcx> { ... } ``` N.B. Most of the `rustc_*` crates only provide **local diff --git a/src/ty.md b/src/ty.md index d9979bc0b..72405d297 100644 --- a/src/ty.md +++ b/src/ty.md @@ -11,63 +11,19 @@ compiler. It is the context that you use to perform all manner of queries. The struct `TyCtxt` defines a reference to this shared context: ```rust,ignore -tcx: TyCtxt<'a, 'gcx, 'tcx> -// -- ---- ---- -// | | | -// | | innermost arena lifetime (if any) -// | "global arena" lifetime -// lifetime of this reference +tcx: TyCtxt<'tcx> +// ---- +// | +// arena lifetime ``` -As you can see, the `TyCtxt` type takes three lifetime parameters. -These lifetimes are perhaps the most complex thing to understand about -the tcx. During Rust compilation, we allocate most of our memory in +As you can see, the `TyCtxt` type takes a lifetime parameter. +During Rust compilation, we allocate most of our memory in **arenas**, which are basically pools of memory that get freed all at -once. When you see a reference with a lifetime like `'tcx` or `'gcx`, +once. When you see a reference with a lifetime like `'tcx`, you know that it refers to arena-allocated data (or data that lives as long as the arenas, anyhow). -We use two distinct levels of arenas. The outer level is the "global -arena". This arena lasts for the entire compilation: so anything you -allocate in there is only freed once compilation is basically over -(actually, when we shift to executing LLVM). - -To reduce peak memory usage, when we do type inference, we also use an -inner level of arena. These arenas get thrown away once type inference -is over. This is done because type inference generates a lot of -"throw-away" types that are not particularly interesting after type -inference completes, so keeping around those allocations would be -wasteful. - -Often, we wish to write code that explicitly asserts that it is not -taking place during inference. In that case, there is no "local" -arena, and all the types that you can access are allocated in the -global arena. To express this, the idea is to use the same lifetime -for the `'gcx` and `'tcx` parameters of `TyCtxt`. Just to be a touch -confusing, we tend to use the name `'tcx` in such contexts. Here is an -example: - -```rust,ignore -fn not_in_inference<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) { - // ---- ---- - // Using the same lifetime here asserts - // that the innermost arena accessible through - // this reference *is* the global arena. -} -``` - -In contrast, if we want to code that can be usable during type inference, then -you need to declare a distinct `'gcx` and `'tcx` lifetime parameter: - -```rust,ignore -fn maybe_in_inference<'a, 'gcx, 'tcx>(tcx: TyCtxt<'a, 'gcx, 'tcx>, def_id: DefId) { - // ---- ---- - // Using different lifetimes here means that - // the innermost arena *may* be distinct - // from the global arena (but doesn't have to be). -} -``` - ### Allocating and working with types Rust types are represented using the `Ty<'tcx>` defined in the `ty` diff --git a/src/type-inference.md b/src/type-inference.md index d94c06379..d4734525f 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -50,9 +50,8 @@ function and disposed of after it returns. [ty-ch]: ty.html -Within the closure, `infcx` has the type `InferCtxt<'cx, 'gcx, 'tcx>` -for some fresh `'cx` and `'tcx` – the latter corresponds to the lifetime of -this temporary arena, and the `'cx` is the lifetime of the `InferCtxt` itself. +Within the closure, `infcx` has the type `InferCtxt<'cx, 'tcx>` for some +fresh `'cx`, while `'tcx` is the same as outside the inference context. (Again, see the [`ty` chapter][ty-ch] for more details on this setup.) The `tcx.infer_ctxt` method actually returns a builder, which means From f55e97c145cf37fd664db2e0e2f2d05df328bf4f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 15 Jun 2019 17:00:21 -0500 Subject: [PATCH 0575/1812] fix typos --- src/appendix/glossary.md | 2 +- src/conventions.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 46c5c9f0f..3d77def91 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -65,7 +65,7 @@ soundness | soundness is a technical term in type theory. Roughly span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) tcx | the "typing context", main data structure of the compiler ([see more](../ty.html)) -'tcx | the lifetime of the currently active inference context ([see more](../ty.html)) +'tcx | the lifetime of the allocation arena ([see more](../ty.html)) trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](../traits/goals-and-clauses.html#trait-ref)) token | the smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. diff --git a/src/conventions.md b/src/conventions.md index a941ebff9..3660f3379 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -141,7 +141,7 @@ to the compiler. - `cx` tends to be short for "context" and is often used as a suffix. For example, `tcx` is a common name for the [Typing Context][tcx]. -- [`'tcx`][tcx] is used as the lifetim names for the Typing Context. +- [`'tcx`][tcx] is used as the lifetime name for the Typing Context. - Because `crate` is a keyword, if you need a variable to represent something crate-related, often the spelling is changed to `krate`. From 76a7f1085e9ec293da1b3bf58cfe105aec3b443f Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Sun, 5 May 2019 15:15:09 -0400 Subject: [PATCH 0576/1812] Added Rustc Debugger Support Chapter --- src/SUMMARY.md | 1 + src/debugging-support-in-rustc.md | 321 ++++++++++++++++++++++++++++++ 2 files changed, 322 insertions(+) create mode 100644 src/debugging-support-in-rustc.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 273b409ec..663357f00 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -84,6 +84,7 @@ - [Updating LLVM](./codegen/updating-llvm.md) - [Debugging LLVM](./codegen/debugging.md) - [Profile-guided Optimization](./profile-guided-optimization.md) + - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) --- diff --git a/src/debugging-support-in-rustc.md b/src/debugging-support-in-rustc.md new file mode 100644 index 000000000..1775b07af --- /dev/null +++ b/src/debugging-support-in-rustc.md @@ -0,0 +1,321 @@ +# Debugging support in the Rust compiler + +This document explains the state of debugging tools support in the Rust compiler (rustc). +The document gives an overview of debugging tools like GDB, LLDB etc. and infrastrcture +around Rust compiler to debug Rust code. If you want to learn how to debug the Rust compiler +itself, then you must see [Debugging the Compiler] page. + +The material is gathered from YouTube video [Tom Tromey discusses debugging support in rustc]. + +## Preliminaries + +### Debuggers + +According to Wikipedia + +> A [debugger or debugging tool] is a computer program that is used to test and debug +> other programs (the "target" program). + +Writing a debugger from scratch for a language requires a lot of work, especially if +debuggers have to be supported on various platforms. GDB and LLDB, however, can be +extended to support debugging a language. This is the path that Rust has chosen. +This document's main goal is to document the said debuggers support in Rust compiler. + +### DWARF + +According to the [DWARF] standard website + +> DWARF is a debugging file format used by many compilers and debuggers to support source level +> debugging. It addresses the requirements of a number of procedural languages, +> such as C, C++, and Fortran, and is designed to be extensible to other languages. +> DWARF is architecture independent and applicable to any processor or operating system. +> It is widely used on Unix, Linux and other operating systems, +> as well as in stand-alone environments. + +DWARF reader is a program that consumes the DWARF format and creates debugger compatible output. +This program may live in the compiler itself. DWARF uses a data structure called +Debugging Information Entry (DIE) which stores the information as "tags" to denote functions, +variables etc., e.g., `DW_TAG_variable`, `DW_TAG_pointer_type`, `DW_TAG_subprogram` etc. +You can also invent your own tags and attributes. + +## Supported debuggers + +### GDB + +We have our own fork of GDB - [https://github.com/rust-dev-tools/gdb] + +#### Rust expression parser + +To be able to show debug output we need an expression parser. +This (GDB) expression parser is written in [Bison] and is only a subset of Rust expressions. +This means that this parser can parse only a subset of Rust expressions. +GDB parser was written from scratch and has no relation to any other parser. +For example, this parser is not related to Rustc's parser. + +GDB has Rust like value and type output. It can print values and types in a way +that look like Rust syntax in the output. Or when you print a type as [ptype] in GDB, +it also looks like Rust source code. Checkout the documentation in the [manual for GDB/Rust]. + +#### Parser extensions + +Expression parser has a couple of extensions in it to facilitate features that you cannot do +with Rust. Some limitations are listed in the [manual for GDB/Rust]. There is some special +code in the DWARF reader in GDB to support the extensions. + +A couple of examples of DWARF reader support needed are as follows - + +1. Enum: Needed for support for enum types. The Rustc writes the information about enum into +DWARF and GDB reads the DWARF to understand where is the tag field or is there a tag +field or is the tag slot shared with non-zero optimization etc. + +2. Dissect trait objects: DWARF extension where the trait object's description in the DWARF +also points to a stub description of the corresponding vtable which in turn points to the +concrete type for which this trait object exists. This means that you can do a `print *object` +for that trait object, and GDB will understand how to find the correct type of the payload in +the trait object. + +**TODO**: Figure out if the following should be mentioned in the GDB-Rust document rather than +this guide page so there is no duplication. This is regarding the following comments: + +[This comment by Tom](https://github.com/rust-lang/rustc-guide/pull/316#discussion_r284027340) +> gdb's Rust extensions and limitations are documented in the gdb manual: +https://sourceware.org/gdb/onlinedocs/gdb/Rust.html -- however, this neglects to mention that +gdb convenience variables and registers follow the gdb $ convention, and that the Rust parser +implements the gdb @ extension. + +[This question by Aman](https://github.com/rust-lang/rustc-guide/pull/316#discussion_r285401353) +> @tromey do you think we should mention this part in the GDB-Rust document rather than this +document so there is no duplication etc.? + +#### Developer notes + +* This work is now upstream. Bugs can be reported in [GDB Bugzilla]. + +### LLDB + +We have our own fork of LLDB - [https://github.com/rust-lang/lldb] + +Fork of LLVM project - [https://github.com/rust-lang/llvm-project] + +LLDB currently only works on macOS because of a dependency issue. This issue was easier to +solve for macOS as compared to Linux. However, Tom has a possible solution which can enable +us to ship LLDB everywhere. + +#### Rust expression parser + +This expression parser is written in C++. It is a type of [Recursive Descent parser]. +Implements slightly less of the Rust language than GDB. LLDB has Rust like value and type output. + +#### Parser extensions + +There is some special code in the DWARF reader in LLDB to support the extensions. +A couple of examples of DWARF reader support needed are as follows - + +1. Enum: Needed for support for enum types. The Rustc writes the information about +enum into DWARF and LLDB reads the DWARF to understand where is the tag field or +is there a tag field or is the tag slot shared with non-zero optimization etc. +In other words, it has enum support as well. + +#### Developer notes + +* None of the LLDB work is upstream. This [rust-lang/lldb wiki page] explains a few details. +* The reason for forking LLDB is that LLDB recently removed all the other language plugins +due to lack of maintenance. +* LLDB has a plugin architecture but that does not work for language support. +* LLDB is available via Rust build (`rustup`). +* GDB generally works better on Linux. + +## DWARF and Rustc + +[DWARF] is the standard way compilers generate debugging information that debuggers read. +It is _the_ debugging format on macOS and Linux. It is a multi-language, extensible format +and is mostly good enough for Rust's purposes. Hence, the current implementation reuses DWARF's +concepts. This is true even if some of the concepts in DWARF do not align with Rust +semantically because generally there can be some kind of mapping between the two. + +We have some DWARF extensions that the Rust compiler emits and the debuggers understand that +are _not_ in the DWARF standard. + +* Rust compiler will emit DWARF for a virtual table, and this `vtable` object will have a + `DW_AT_containing_type` that points to the real type. This lets debuggers dissect a trait object + pointer to correctly find the payload. E.g., here's such a DIE, from a test case in the gdb + repository: + + ```asm + <1><1a9>: Abbrev Number: 3 (DW_TAG_structure_type) + <1aa> DW_AT_containing_type: <0x1b4> + <1ae> DW_AT_name : (indirect string, offset: 0x23d): vtable + <1b2> DW_AT_byte_size : 0 + <1b3> DW_AT_alignment : 8 + ``` + +* The other extension is that the Rust compiler can emit a tagless discriminated union. + See [DWARF feature request] for this item. + +### Current limitations of DWARF + +* Traits - require a bigger change than normal to DWARF, on how to represent Traits in DWARF. +* DWARF provides no way to differentiate between Structs and Tuples. Rust compiler emits +fields with `__0` and debuggers look for a sequence of such names to overcome this limitation. +For example, in this case the debugger would look at a field via `x.__0` instead of `x.0`. +This is resolved via the Rust parser in the debugger so now you can do `x.0`. + +DWARF relies on debuggers to know some information about platform ABI. +Rust does not do that all the time. + +## Developer notes + +This section is from the talk about certain aspects of development. + +## What is missing + +### Shipping GDB in Rustup + +Tracking issue: [https://github.com/rust-lang/rust/issues/34457] + +Shipping GDB requires change to Rustup delivery system. To manage Rustup build size and +times we need to build GDB separately, on its own and somehow provide the artifacts produced +to be included in the final build. However, if we can ship GDB with rustup, it will simplify +the development process by having compiler emit new debug info which can be readily consumed. + +Main issue in achieving this is setting up dependencies. One such dependency is Python. That +is why we have our own fork of GDB because one of the drivers is patched on Rust's side to +check the correct version of Python (Python 2.7 in this case. *Note: Python3 is not chosen +for this purpose because Python's stable ABI is limited and is not sufficient for GDB's needs. +See [https://docs.python.org/3/c-api/stable.html]*). + +This is to keep updates to debugger as fast as possible as we make changes to the debugging symbols. +In essence, to ship the debugger as soon as new debugging info is added. GDB only releases +every six months or so. However, the changes that are +not related to Rust itself should ideally be first merged to upstream eventually. + +### Code signing for LLDB debug server on macOS + +According to Wikipedia, [System Integrity Protection] is + +> System Integrity Protection (SIP, sometimes referred to as rootless) is a security feature +> of Apple's macOS operating system introduced in OS X El Capitan. It comprises a number of +> mechanisms that are enforced by the kernel. A centerpiece is the protection of system-owned +> files and directories against modifications by processes without a specific "entitlement", +> even when executed by the root user or a user with root privileges (sudo). + +It prevents processes using `ptrace` syscall. If a process wants to use `ptrace` it has to be +code signed. The certificate that signs it has to be trusted on your machine. + +See [Apple developer documentation for System Integrity Protection]. + +We may need to sign up with Apple and get the keys to do this signing. Tom has looked into if +Mozilla cannot do this because it is at the maximum number of +keys it is allowed to sign. Tom does not know if Mozilla could get more keys. + +Alternatively, Tom suggests that maybe a Rust legal entity is needed to get the keys via Apple. +This problem is not technical in nature. If we had such a key we could sign GDB as well and +ship that. + +### DWARF and Traits + +Rust traits are not emitted into DWARF at all. The impact of this is calling a method `x.method()` +does not work as is. The reason being that method is implemented by a trait, as opposed +to a type. That information is not present so finding trait methods is missing. + +DWARF has a notion of interface types (possibly added for Java). Tom's idea was to use this +interface type as traits. + +DWARF only deals with concrete names, not the reference types. So, a given implementation of a +trait for a type would be one of these interfaces (`DW_tag_interface` type). Also, the type for +which it is implemented would describe all the interfaces this type implements. This requires a +DWARF extension. + +Issue on Github: [https://github.com/rust-lang/rust/issues/33014] + +## Typical process for a Debug Info change (LLVM) + +LLVM has Debug Info (DI) builders. This is the primary thing that Rust calls into. +This is why we need to change LLVM first because that is emitted first and not DWARF directly. +This is a kind of metadata that you construct and hand-off to LLVM. For the Rustc/LLVM hand-off +some LLVM DI builder methods are called to construct representation of a type. + +The steps of this process are as follows - + +1. LLVM needs changing. + + LLVM does not emit Interface types at all, so this needs to be implemented in the LLVM first. + + Get sign off on LLVM maintainers that this is a good idea. + +2. Change the DWARF extension. + +3. Update the debuggers. + + Update DWARF readers, expression evaluators. + +4. Update Rust compiler. + + Change it to emit this new information. + +### Procedural macro stepping + +A deeply profound question is that how do you actually debug a procedural macro? +What is the location you emit for a macro expansion? Consider some of the following cases - + +* You can emit location of the invocation of the macro. +* You can emit the location of the definition of the macro. +* You can emit locations of the content of the macro. + +RFC: [https://github.com/rust-lang/rfcs/pull/2117] + +Focus is to let macros decide what to do. This can be achieved by having some kind of attribute +that lets the macro tell the compiler where the line marker should be. This affects where you +set the breakpoints and what happens when you step it. + +## Future work + +#### Name mangling changes + +* New demangler in `libiberty` (gcc source tree). +* New demangler in LLVM or LLDB. + +**TODO**: Check the location of the demangler source. +[Question on Github](https://github.com/rust-lang/rustc-guide/pull/316#discussion_r283062536). + +#### Reuse Rust compiler for expressions + +This is an important idea because debuggers by and large do not try to implement type +inference. You need to be much more explicit when you type into the debugger than your +actual source code. So, you cannot just copy and paste an expression from your source +code to debugger and expect the same answer but this would be nice. This can be helped +by using compiler. + +It is certainly doable but it is a large project. You certainly need a bridge to the +debugger because the debugger alone has access to the memory. Both GDB (gcc) and LLDB (clang) +have this feature. LLDB uses Clang to compile code to JIT and GDB can do the same with GCC. + +Both debuggers expression evaluation implement both a superset and a subset of Rust. +They implement just the expression language but they also add some extensions like GDB has +convenience variables. Therefore, if you are taking this route then you not only need +to do this bridge but may have to add some mode to let the compiler understand some extensions. + +#### Windows debugging (PDB) is missing + +This is a complete unknown. + +[Tom Tromey discusses debugging support in rustc]: https://www.youtube.com/watch?v=elBxMRSNYr4 +[Debugging the Compiler]: compiler-debugging.md +[debugger or debugging tool]: https://en.wikipedia.org/wiki/Debugger +[Bison]: https://www.gnu.org/software/bison/ +[ptype]: https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_109.html +[rust-lang/lldb wiki page]: https://github.com/rust-lang/lldb/wiki +[DWARF]: http://dwarfstd.org +[manual for GDB/Rust]: https://sourceware.org/gdb/onlinedocs/gdb/Rust.html +[GDB Bugzilla]: https://sourceware.org/bugzilla/ +[Recursive Descent parser]: https://en.wikipedia.org/wiki/Recursive_descent_parser +[System Integrity Protection]: https://en.wikipedia.org/wiki/System_Integrity_Protection +[https://github.com/rust-dev-tools/gdb]: https://github.com/rust-dev-tools/gdb +[DWARF feature request]: http://dwarfstd.org/ShowIssue.php?issue=180517.2 +[https://docs.python.org/3/c-api/stable.html]: https://docs.python.org/3/c-api/stable.html +[https://github.com/rust-lang/rfcs/pull/2117]: https://github.com/rust-lang/rfcs/pull/2117 +[https://github.com/rust-lang/rust/issues/33014]: https://github.com/rust-lang/rust/issues/33014 +[https://github.com/rust-lang/rust/issues/34457]: https://github.com/rust-lang/rust/issues/34457 +[Apple developer documentation for System Integrity Protection]: https://developer.apple.com/library/archive/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_11.html#//apple_ref/doc/uid/TP40016227-SW11 +[https://github.com/rust-lang/lldb]: https://github.com/rust-lang/lldb +[https://github.com/rust-lang/llvm-project]: https://github.com/rust-lang/llvm-project From 43ac5672c393b949cd7f765cc2b9a0725757cfab Mon Sep 17 00:00:00 2001 From: b41sh Date: Mon, 24 Jun 2019 21:43:27 +0800 Subject: [PATCH 0577/1812] fix compiler-team --- src/compiler-team.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index 0f0808b79..968e2f142 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -95,7 +95,7 @@ The guidelines for reviewers are as follows: ### high-five -Once you have r+ rights, you can also be added to the high-five +Once you have r+ rights, you can also be added to the [high-five][hi5] rotation. high-five is the bot that assigns incoming PRs to reviewers. If you are added, you will be randomly selected to review PRs. If you find you are assigned a PR that you don't feel comfortable From 6f50f15f7a33bbe6ce528a699b66ce22b5a1949c Mon Sep 17 00:00:00 2001 From: flip1995 Date: Mon, 24 Jun 2019 12:59:12 +0200 Subject: [PATCH 0578/1812] Change stage0 cfg_attr to bootstrap --- src/stabilization_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 56da5cdaf..76446150c 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -125,7 +125,7 @@ writing, the next stable release (i.e. what is currently beta) was Next search for the feature string (in this case, `pub_restricted`) in the codebase to find where it appears. Change uses of `#![feature(XXX)]` from the `libstd` and any rustc crates to be -`#![cfg_attr(stage0, feature(XXX))]`. This includes the feature-gate +`#![cfg_attr(bootstrap, feature(XXX))]`. This includes the feature-gate only for stage0, which is built using the current beta (this is needed because the feature is still unstable in the current beta). From 9f3678dece076f2f8bdb36a9e09a10333349028c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 19 Jun 2019 13:11:01 -0500 Subject: [PATCH 0579/1812] Update mdbook --- ci/install.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ci/install.sh b/ci/install.sh index 835f23192..d22d2c6c1 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -20,5 +20,5 @@ function cargo_install() { fi } -cargo_install mdbook 0.2.3 -cargo_install mdbook-linkcheck 0.2.3 +cargo_install mdbook 0.3.0 +cargo_install mdbook-linkcheck 0.2.4 From d16c32661a70cfe82806c887a3520e7517092302 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 21 Jun 2019 09:57:52 -0500 Subject: [PATCH 0580/1812] Update to mdbook-linkcheck 0.3.0 --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index d22d2c6c1..7c730cae3 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -21,4 +21,4 @@ function cargo_install() { } cargo_install mdbook 0.3.0 -cargo_install mdbook-linkcheck 0.2.4 +cargo_install mdbook-linkcheck 0.3.0 From bb872a6072981f1875c446ecf1c4b40734a9510d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 25 Jun 2019 15:16:30 -0500 Subject: [PATCH 0581/1812] add bibligraphy appendix --- src/SUMMARY.md | 1 + src/appendix/bibliography.md | 89 ++++++++++++++++++++++++++++++++++++ 2 files changed, 90 insertions(+) create mode 100644 src/appendix/bibliography.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 663357f00..45b05c0c9 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -92,4 +92,5 @@ [Appendix B: Background material](./appendix/background.md) [Appendix C: Glossary](./appendix/glossary.md) [Appendix D: Code Index](./appendix/code-index.md) +[Appendix E: Bibliography](./appendix/bibliography.md) [](./important-links.md) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md new file mode 100644 index 000000000..64e014f91 --- /dev/null +++ b/src/appendix/bibliography.md @@ -0,0 +1,89 @@ +# Rust Bibliography + +This is a reading list of material relevant to Rust. It includes prior +research that has - at one time or another - influenced the design of +Rust, as well as publications about Rust. + +## Type system + +* [Region based memory management in Cyclone](http://209.68.42.137/ucsd-pages/Courses/cse227.w03/handouts/cyclone-regions.pdf) +* [Safe manual memory management in Cyclone](http://www.cs.umd.edu/projects/PL/cyclone/scp.pdf) +* [Typeclasses: making ad-hoc polymorphism less ad hoc](http://www.ps.uni-sb.de/courses/typen-ws99/class.ps.gz) +* [Macros that work together](https://www.cs.utah.edu/plt/publications/jfp12-draft-fcdf.pdf) +* [Traits: composable units of behavior](http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf) +* [Alias burying](http://www.cs.uwm.edu/faculty/boyland/papers/unique-preprint.ps) - We tried something similar and abandoned it. +* [External uniqueness is unique enough](http://www.cs.uu.nl/research/techreps/UU-CS-2002-048.html) +* [Uniqueness and Reference Immutability for Safe Parallelism](https://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf) +* [Region Based Memory Management](http://www.cs.ucla.edu/~palsberg/tba/papers/tofte-talpin-iandc97.pdf) + +## Concurrency + +* [Singularity: rethinking the software stack](https://research.microsoft.com/pubs/69431/osr2007_rethinkingsoftwarestack.pdf) +* [Language support for fast and reliable message passing in singularity OS](https://research.microsoft.com/pubs/67482/singsharp.pdf) +* [Scheduling multithreaded computations by work stealing](http://supertech.csail.mit.edu/papers/steal.pdf) +* [Thread scheduling for multiprogramming multiprocessors](http://www.eecis.udel.edu/%7Ecavazos/cisc879-spring2008/papers/arora98thread.pdf) +* [The data locality of work stealing](http://www.aladdin.cs.cmu.edu/papers/pdfs/y2000/locality_spaa00.pdf) +* [Dynamic circular work stealing deque](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.1097&rep=rep1&type=pdf) - The Chase/Lev deque +* [Work-first and help-first scheduling policies for async-finish task parallelism](http://www.cs.rice.edu/%7Eyguo/pubs/PID824943.pdf) - More general than fully-strict work stealing +* [A Java fork/join calamity](http://www.coopsoft.com/ar/CalamityArticle.html) - critique of Java's fork/join library, particularly its application of work stealing to non-strict computation +* [Scheduling techniques for concurrent systems](http://www.stanford.edu/~ouster/cgi-bin/papers/coscheduling.pdf) +* [Contention aware scheduling](http://www.blagodurov.net/files/a8-blagodurov.pdf) +* [Balanced work stealing for time-sharing multicores](http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-12-1.pdf) +* [Three layer cake for shared-memory programming](http://dl.acm.org/citation.cfm?id=1953616&dl=ACM&coll=DL&CFID=524387192&CFTOKEN=44362705) +* [Non-blocking steal-half work queues](http://www.cs.bgu.ac.il/%7Ehendlerd/papers/p280-hendler.pdf) +* [Reagents: expressing and composing fine-grained concurrency](http://www.mpi-sws.org/~turon/reagents.pdf) +* [Algorithms for scalable synchronization of shared-memory multiprocessors](https://www.cs.rochester.edu/u/scott/papers/1991_TOCS_synch.pdf) +* [Epoch-based reclamation](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf). + +## Others + +* [Crash-only software](https://www.usenix.org/legacy/events/hotos03/tech/full_papers/candea/candea.pdf) +* [Composing High-Performance Memory Allocators](http://people.cs.umass.edu/~emery/pubs/berger-pldi2001.pdf) +* [Reconsidering Custom Memory Allocation](http://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf) + +## Papers *about* Rust + +* [GPU Programming in Rust: Implementing High Level Abstractions in a +Systems Level +Language](http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf). Early GPU work by Eric Holk. +* [Parallel closures: a new twist on an old + idea](https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea) + - not exactly about Rust, but by nmatsakis +* [Patina: A Formalization of the Rust Programming + Language](ftp://ftp.cs.washington.edu/tr/2015/03/UW-CSE-15-03-02.pdf). Early + formalization of a subset of the type system, by Eric Reed. +* [Experience Report: Developing the Servo Web Browser Engine using + Rust](http://arxiv.org/abs/1505.07383). By Lars Bergstrom. +* [Implementing a Generic Radix Trie in + Rust](https://michaelsproul.github.io/rust_radix_paper/rust-radix-sproul.pdf). Undergrad + paper by Michael Sproul. +* [Reenix: Implementing a Unix-Like Operating System in + Rust](http://scialex.github.io/reenix.pdf). Undergrad paper by Alex + Light. +* [Evaluation of performance and productivity metrics of potential programming languages in the HPC environment](http://octarineparrot.com/assets/mrfloya-thesis-ba.pdf). + Bachelor's thesis by Florian Wilkens. Compares C, Go and Rust. +* [Nom, a byte oriented, streaming, zero copy, parser combinators library + in Rust](http://spw15.langsec.org/papers/couprie-nom.pdf). By + Geoffroy Couprie, research for VLC. +* [Graph-Based Higher-Order Intermediate + Representation](http://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf). An + experimental IR implemented in Impala, a Rust-like language. +* [Code Refinement of Stencil + Codes](http://compilers.cs.uni-saarland.de/papers/ppl14_web.pdf). Another + paper using Impala. +* [Parallelization in Rust with fork-join and + friends](http://publications.lib.chalmers.se/records/fulltext/219016/219016.pdf). Linus + Farnstrand's master's thesis. +* [Session Types for + Rust](http://munksgaard.me/papers/laumann-munksgaard-larsen.pdf). Philip + Munksgaard's master's thesis. Research for Servo. +* [Ownership is Theft: Experiences Building an Embedded OS in Rust - Amit Levy, et. al.](http://amitlevy.com/papers/tock-plos2015.pdf) +* [You can't spell trust without Rust](https://raw.githubusercontent.com/Gankro/thesis/master/thesis.pdf). Alexis Beingessner's master's thesis. +* [Rust-Bio: a fast and safe bioinformatics library](http://bioinformatics.oxfordjournals.org/content/early/2015/10/06/bioinformatics.btv573). Johannes Köster +* [Safe, Correct, and Fast Low-Level Networking](https://octarineparrot.com/assets/msci_paper.pdf). Robert Clipsham's master's thesis. +* [Formalizing Rust traits](http://hdl.handle.net/2429/55609). Jonatan Milewski's master's thesis. +* [Rust as a Language for High Performance GC Implementation](http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rust-ismm-2016.pdf) +* [Simple Verification of Rust Programs via Functional Purification](https://github.com/Kha/electrolysis). Sebastian Ullrich's master's thesis. +* [Writing parsers like it is 2017](http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf) Pierre Chifflier and Geoffroy Couprie for the Langsec Workshop +* [The Case for Writing a Kernel in Rust](https://www.tockos.org/assets/papers/rust-kernel-apsys2017.pdf) +* [RustBelt: Securing the Foundations of the Rust Programming Language](https://plv.mpi-sws.org/rustbelt/popl18/) From 979387d4c23403dab9a9553557ecaf93045eb49d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 10:32:01 -0500 Subject: [PATCH 0582/1812] fix broken links --- src/appendix/bibliography.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index 64e014f91..a5bd84b25 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -6,7 +6,7 @@ Rust, as well as publications about Rust. ## Type system -* [Region based memory management in Cyclone](http://209.68.42.137/ucsd-pages/Courses/cse227.w03/handouts/cyclone-regions.pdf) +* [Region based memory management in Cyclone](https://www.cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf) * [Safe manual memory management in Cyclone](http://www.cs.umd.edu/projects/PL/cyclone/scp.pdf) * [Typeclasses: making ad-hoc polymorphism less ad hoc](http://www.ps.uni-sb.de/courses/typen-ws99/class.ps.gz) * [Macros that work together](https://www.cs.utah.edu/plt/publications/jfp12-draft-fcdf.pdf) @@ -31,7 +31,7 @@ Rust, as well as publications about Rust. * [Balanced work stealing for time-sharing multicores](http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-12-1.pdf) * [Three layer cake for shared-memory programming](http://dl.acm.org/citation.cfm?id=1953616&dl=ACM&coll=DL&CFID=524387192&CFTOKEN=44362705) * [Non-blocking steal-half work queues](http://www.cs.bgu.ac.il/%7Ehendlerd/papers/p280-hendler.pdf) -* [Reagents: expressing and composing fine-grained concurrency](http://www.mpi-sws.org/~turon/reagents.pdf) +* [Reagents: expressing and composing fine-grained concurrency](http://aturon.github.io/academic/reagents.pdf) * [Algorithms for scalable synchronization of shared-memory multiprocessors](https://www.cs.rochester.edu/u/scott/papers/1991_TOCS_synch.pdf) * [Epoch-based reclamation](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf). @@ -43,9 +43,10 @@ Rust, as well as publications about Rust. ## Papers *about* Rust -* [GPU Programming in Rust: Implementing High Level Abstractions in a -Systems Level -Language](http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf). Early GPU work by Eric Holk. +* [GPU Programming in Rust: Implementing High Level Abstractions in a Systems + Level + Language](https://www.cs.indiana.edu/~achauhan/Publications/Pubs/2013-hips-holk-rust.pdf). + Early GPU work by Eric Holk. * [Parallel closures: a new twist on an old idea](https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea) - not exactly about Rust, but by nmatsakis From 85c06162882ba42696a76f653badf39e26d494e7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 10:41:07 -0500 Subject: [PATCH 0583/1812] avoid ftp links --- src/appendix/bibliography.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index a5bd84b25..19a9217f7 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -51,8 +51,8 @@ Rust, as well as publications about Rust. idea](https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea) - not exactly about Rust, but by nmatsakis * [Patina: A Formalization of the Rust Programming - Language](ftp://ftp.cs.washington.edu/tr/2015/03/UW-CSE-15-03-02.pdf). Early - formalization of a subset of the type system, by Eric Reed. + Language](http://dada.cs.washington.edu/research/tr/2015/03/UW-CSE-15-03-02.pdf). + Early formalization of a subset of the type system, by Eric Reed. * [Experience Report: Developing the Servo Web Browser Engine using Rust](http://arxiv.org/abs/1505.07383). By Lars Bergstrom. * [Implementing a Generic Radix Trie in From 40e84619738ced662efc5aeaa076b4d8d415e989 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 18 Jun 2019 10:08:04 -0400 Subject: [PATCH 0584/1812] fix typo --- src/borrow_check/region_inference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 7fe50b870..fc3978436 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -48,7 +48,7 @@ The MIR-based region analysis consists of two major functions: ## Universal regions -The [`UnversalRegions`] type represents a collection of _universal_ regions +The [`UniversalRegions`] type represents a collection of _universal_ regions corresponding to some MIR `DefId`. It is constructed in [`replace_regions_in_mir`] when we replace all regions with fresh inference variables. [`UniversalRegions`] contains indices for all the free regions in From 83ab6e429644242e204b3de85d2dea7ba79509de Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 18 Jun 2019 10:17:36 -0400 Subject: [PATCH 0585/1812] break out parts of the region inference chapter into sub-chapters --- src/SUMMARY.md | 4 + src/borrow_check/region_inference.md | 457 ------------------ .../region_inference/closure_constraints.md | 10 + .../constraint_propagation.md | 3 + .../region_inference/error_reporting.md | 3 + .../placeholders_and_universes.md | 441 +++++++++++++++++ 6 files changed, 461 insertions(+), 457 deletions(-) create mode 100644 src/borrow_check/region_inference/closure_constraints.md create mode 100644 src/borrow_check/region_inference/constraint_propagation.md create mode 100644 src/borrow_check/region_inference/error_reporting.md create mode 100644 src/borrow_check/region_inference/placeholders_and_universes.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 45b05c0c9..7e9a9ee54 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -76,6 +76,10 @@ - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) - [MIR type checker](./borrow_check/type_check.md) - [Region inference](./borrow_check/region_inference.md) + - [Constraint propagation](./borrow_check/region_inference/constraint_propagation.md) + - [Placeholders and universes](./borrow_check/region_inference/placeholders_and_universes.md) + - [Closure constraints](./borrow_check/region_inference/closure_constraints.md) + - [Errror reporting](./borrow_check/region_inference/error_reporting.md) - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index fc3978436..5279d210b 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -234,460 +234,3 @@ tests and universal regions, as discussed above. [`check_type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_type_tests [`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions -## Closures - -When we are checking the type tests and universal regions, we may come across a -constraint that we can't prove yet if we are in a closure body! However, the -necessary constraints may actually hold (we just don't know it yet). Thus, if -we are inside a closure, we just collect all the constraints we can't prove yet -and return them. Later, when we are borrow check the MIR node that created the -closure, we can also check that these constraints hold. At that time, if we -can't prove they hold, we report an error. - -## Placeholders and universes - -(This section describes ongoing work that hasn't landed yet.) - -From time to time we have to reason about regions that we can't -concretely know. For example, consider this program: - -```rust,ignore -// A function that needs a static reference -fn foo(x: &'static u32) { } - -fn bar(f: for<'a> fn(&'a u32)) { - // ^^^^^^^^^^^^^^^^^^^ a function that can accept **any** reference - let x = 22; - f(&x); -} - -fn main() { - bar(foo); -} -``` - -This program ought not to type-check: `foo` needs a static reference -for its argument, and `bar` wants to be given a function that that -accepts **any** reference (so it can call it with something on its -stack, for example). But *how* do we reject it and *why*? - -### Subtyping and Placeholders - -When we type-check `main`, and in particular the call `bar(foo)`, we -are going to wind up with a subtyping relationship like this one: - -```text -fn(&'static u32) <: for<'a> fn(&'a u32) ----------------- ------------------- -the type of `foo` the type `bar` expects -``` - -We handle this sort of subtyping by taking the variables that are -bound in the supertype and replacing them with -[universally quantified](../appendix/background.html#quantified) -representatives, written like `!1`. We call these regions "placeholder -regions" – they represent, basically, "some unknown region". - -Once we've done that replacement, we have the following relation: - -```text -fn(&'static u32) <: fn(&'!1 u32) -``` - -The key idea here is that this unknown region `'!1` is not related to -any other regions. So if we can prove that the subtyping relationship -is true for `'!1`, then it ought to be true for any region, which is -what we wanted. - -So let's work through what happens next. To check if two functions are -subtypes, we check if their arguments have the desired relationship -(fn arguments are [contravariant](../appendix/background.html#variance), so -we swap the left and right here): - -```text -&'!1 u32 <: &'static u32 -``` - -According to the basic subtyping rules for a reference, this will be -true if `'!1: 'static`. That is – if "some unknown region `!1`" lives -outlives `'static`. Now, this *might* be true – after all, `'!1` -could be `'static` – but we don't *know* that it's true. So this -should yield up an error (eventually). - -### What is a universe - -In the previous section, we introduced the idea of a placeholder -region, and we denoted it `!1`. We call this number `1` the **universe -index**. The idea of a "universe" is that it is a set of names that -are in scope within some type or at some point. Universes are formed -into a tree, where each child extends its parents with some new names. -So the **root universe** conceptually contains global names, such as -the the lifetime `'static` or the type `i32`. In the compiler, we also -put generic type parameters into this root universe (in this sense, -there is not just one root universe, but one per item). So consider -this function `bar`: - -```rust,ignore -struct Foo { } - -fn bar<'a, T>(t: &'a T) { - ... -} -``` - -Here, the root universe would consist of the lifetimes `'static` and -`'a`. In fact, although we're focused on lifetimes here, we can apply -the same concept to types, in which case the types `Foo` and `T` would -be in the root universe (along with other global types, like `i32`). -Basically, the root universe contains all the names that -[appear free](../appendix/background.html#free-vs-bound) in the body of `bar`. - -Now let's extend `bar` a bit by adding a variable `x`: - -```rust,ignore -fn bar<'a, T>(t: &'a T) { - let x: for<'b> fn(&'b u32) = ...; -} -``` - -Here, the name `'b` is not part of the root universe. Instead, when we -"enter" into this `for<'b>` (e.g., by replacing it with a placeholder), we will create -a child universe of the root, let's call it U1: - -```text -U0 (root universe) -│ -└─ U1 (child universe) -``` - -The idea is that this child universe U1 extends the root universe U0 -with a new name, which we are identifying by its universe number: -`!1`. - -Now let's extend `bar` a bit by adding one more variable, `y`: - -```rust,ignore -fn bar<'a, T>(t: &'a T) { - let x: for<'b> fn(&'b u32) = ...; - let y: for<'c> fn(&'b u32) = ...; -} -``` - -When we enter *this* type, we will again create a new universe, which -we'll call `U2`. Its parent will be the root universe, and U1 will be -its sibling: - -```text -U0 (root universe) -│ -├─ U1 (child universe) -│ -└─ U2 (child universe) -``` - -This implies that, while in U2, we can name things from U0 or U2, but -not U1. - -**Giving existential variables a universe.** Now that we have this -notion of universes, we can use it to extend our type-checker and -things to prevent illegal names from leaking out. The idea is that we -give each inference (existential) variable – whether it be a type or -a lifetime – a universe. That variable's value can then only -reference names visible from that universe. So for example is a -lifetime variable is created in U0, then it cannot be assigned a value -of `!1` or `!2`, because those names are not visible from the universe -U0. - -**Representing universes with just a counter.** You might be surprised -to see that the compiler doesn't keep track of a full tree of -universes. Instead, it just keeps a counter – and, to determine if -one universe can see another one, it just checks if the index is -greater. For example, U2 can see U0 because 2 >= 0. But U0 cannot see -U2, because 0 >= 2 is false. - -How can we get away with this? Doesn't this mean that we would allow -U2 to also see U1? The answer is that, yes, we would, **if that -question ever arose**. But because of the structure of our type -checker etc, there is no way for that to happen. In order for -something happening in the universe U1 to "communicate" with something -happening in U2, they would have to have a shared inference variable X -in common. And because everything in U1 is scoped to just U1 and its -children, that inference variable X would have to be in U0. And since -X is in U0, it cannot name anything from U1 (or U2). This is perhaps easiest -to see by using a kind of generic "logic" example: - -```text -exists { - forall { ... /* Y is in U1 ... */ } - forall { ... /* Z is in U2 ... */ } -} -``` - -Here, the only way for the two foralls to interact would be through X, -but neither Y nor Z are in scope when X is declared, so its value -cannot reference either of them. - -### Universes and placeholder region elements - -But where does that error come from? The way it happens is like this. -When we are constructing the region inference context, we can tell -from the type inference context how many placeholder variables exist -(the `InferCtxt` has an internal counter). For each of those, we -create a corresponding universal region variable `!n` and a "region -element" `placeholder(n)`. This corresponds to "some unknown set of other -elements". The value of `!n` is `{placeholder(n)}`. - -At the same time, we also give each existential variable a -**universe** (also taken from the `InferCtxt`). This universe -determines which placeholder elements may appear in its value: For -example, a variable in universe U3 may name `placeholder(1)`, `placeholder(2)`, and -`placeholder(3)`, but not `placeholder(4)`. Note that the universe of an inference -variable controls what region elements **can** appear in its value; it -does not say region elements **will** appear. - -### Placeholders and outlives constraints - -In the region inference engine, outlives constraints have the form: - -```text -V1: V2 @ P -``` - -where `V1` and `V2` are region indices, and hence map to some region -variable (which may be universally or existentially quantified). The -`P` here is a "point" in the control-flow graph; it's not important -for this section. This variable will have a universe, so let's call -those universes `U(V1)` and `U(V2)` respectively. (Actually, the only -one we are going to care about is `U(V1)`.) - -When we encounter this constraint, the ordinary procedure is to start -a DFS from `P`. We keep walking so long as the nodes we are walking -are present in `value(V2)` and we add those nodes to `value(V1)`. If -we reach a return point, we add in any `end(X)` elements. That part -remains unchanged. - -But then *after that* we want to iterate over the placeholder `placeholder(x)` -elements in V2 (each of those must be visible to `U(V2)`, but we -should be able to just assume that is true, we don't have to check -it). We have to ensure that `value(V1)` outlives each of those -placeholder elements. - -Now there are two ways that could happen. First, if `U(V1)` can see -the universe `x` (i.e., `x <= U(V1)`), then we can just add `placeholder(x)` -to `value(V1)` and be done. But if not, then we have to approximate: -we may not know what set of elements `placeholder(x)` represents, but we -should be able to compute some sort of **upper bound** B for it – -some region B that outlives `placeholder(x)`. For now, we'll just use -`'static` for that (since it outlives everything) – in the future, we -can sometimes be smarter here (and in fact we have code for doing this -already in other contexts). Moreover, since `'static` is in the root -universe U0, we know that all variables can see it – so basically if -we find that `value(V2)` contains `placeholder(x)` for some universe `x` -that `V1` can't see, then we force `V1` to `'static`. - -### Extending the "universal regions" check - -After all constraints have been propagated, the NLL region inference -has one final check, where it goes over the values that wound up being -computed for each universal region and checks that they did not get -'too large'. In our case, we will go through each placeholder region -and check that it contains *only* the `placeholder(u)` element it is known to -outlive. (Later, we might be able to know that there are relationships -between two placeholder regions and take those into account, as we do -for universal regions from the fn signature.) - -Put another way, the "universal regions" check can be considered to be -checking constraints like: - -```text -{placeholder(1)}: V1 -``` - -where `{placeholder(1)}` is like a constant set, and V1 is the variable we -made to represent the `!1` region. - -## Back to our example - -OK, so far so good. Now let's walk through what would happen with our -first example: - -```text -fn(&'static u32) <: fn(&'!1 u32) @ P // this point P is not imp't here -``` - -The region inference engine will create a region element domain like this: - -```text -{ CFG; end('static); placeholder(1) } - --- ------------ ------- from the universe `!1` - | 'static is always in scope - all points in the CFG; not especially relevant here -``` - -It will always create two universal variables, one representing -`'static` and one representing `'!1`. Let's call them Vs and V1. They -will have initial values like so: - -```text -Vs = { CFG; end('static) } // it is in U0, so can't name anything else -V1 = { placeholder(1) } -``` - -From the subtyping constraint above, we would have an outlives constraint like - -```text -'!1: 'static @ P -``` - -To process this, we would grow the value of V1 to include all of Vs: - -```text -Vs = { CFG; end('static) } -V1 = { CFG; end('static), placeholder(1) } -``` - -At that point, constraint propagation is complete, because all the -outlives relationships are satisfied. Then we would go to the "check -universal regions" portion of the code, which would test that no -universal region grew too large. - -In this case, `V1` *did* grow too large – it is not known to outlive -`end('static)`, nor any of the CFG – so we would report an error. - -## Another example - -What about this subtyping relationship? - -```text -for<'a> fn(&'a u32, &'a u32) - <: -for<'b, 'c> fn(&'b u32, &'c u32) -``` - -Here we would replace the bound region in the supertype with a placeholder, as before, yielding: - -```text -for<'a> fn(&'a u32, &'a u32) - <: -fn(&'!1 u32, &'!2 u32) -``` - -then we instantiate the variable on the left-hand side with an -existential in universe U2, yielding the following (`?n` is a notation -for an existential variable): - -```text -fn(&'?3 u32, &'?3 u32) - <: -fn(&'!1 u32, &'!2 u32) -``` - -Then we break this down further: - -```text -&'!1 u32 <: &'?3 u32 -&'!2 u32 <: &'?3 u32 -``` - -and even further, yield up our region constraints: - -```text -'!1: '?3 -'!2: '?3 -``` - -Note that, in this case, both `'!1` and `'!2` have to outlive the -variable `'?3`, but the variable `'?3` is not forced to outlive -anything else. Therefore, it simply starts and ends as the empty set -of elements, and hence the type-check succeeds here. - -(This should surprise you a little. It surprised me when I first realized it. -We are saying that if we are a fn that **needs both of its arguments to have -the same region**, we can accept being called with **arguments with two -distinct regions**. That seems intuitively unsound. But in fact, it's fine, as -I tried to explain in [this issue][ohdeargoditsallbroken] on the Rust issue -tracker long ago. The reason is that even if we get called with arguments of -two distinct lifetimes, those two lifetimes have some intersection (the call -itself), and that intersection can be our value of `'a` that we use as the -common lifetime of our arguments. -nmatsakis) - -[ohdeargoditsallbroken]: https://github.com/rust-lang/rust/issues/32330#issuecomment-202536977 - -## Final example - -Let's look at one last example. We'll extend the previous one to have -a return type: - -```text -for<'a> fn(&'a u32, &'a u32) -> &'a u32 - <: -for<'b, 'c> fn(&'b u32, &'c u32) -> &'b u32 -``` - -Despite seeming very similar to the previous example, this case is going to get -an error. That's good: the problem is that we've gone from a fn that promises -to return one of its two arguments, to a fn that is promising to return the -first one. That is unsound. Let's see how it plays out. - -First, we replace the bound region in the supertype with a placeholder: - -```text -for<'a> fn(&'a u32, &'a u32) -> &'a u32 - <: -fn(&'!1 u32, &'!2 u32) -> &'!1 u32 -``` - -Then we instantiate the subtype with existentials (in U2): - -```text -fn(&'?3 u32, &'?3 u32) -> &'?3 u32 - <: -fn(&'!1 u32, &'!2 u32) -> &'!1 u32 -``` - -And now we create the subtyping relationships: - -```text -&'!1 u32 <: &'?3 u32 // arg 1 -&'!2 u32 <: &'?3 u32 // arg 2 -&'?3 u32 <: &'!1 u32 // return type -``` - -And finally the outlives relationships. Here, let V1, V2, and V3 be the -variables we assign to `!1`, `!2`, and `?3` respectively: - -```text -V1: V3 -V2: V3 -V3: V1 -``` - -Those variables will have these initial values: - -```text -V1 in U1 = {placeholder(1)} -V2 in U2 = {placeholder(2)} -V3 in U2 = {} -``` - -Now because of the `V3: V1` constraint, we have to add `placeholder(1)` into `V3` (and -indeed it is visible from `V3`), so we get: - -```text -V3 in U2 = {placeholder(1)} -``` - -then we have this constraint `V2: V3`, so we wind up having to enlarge -`V2` to include `placeholder(1)` (which it can also see): - -```text -V2 in U2 = {placeholder(1), placeholder(2)} -``` - -Now constraint propagation is done, but when we check the outlives -relationships, we find that `V2` includes this new element `placeholder(1)`, -so we report an error. - -## Borrow Checker Errors - -TODO: we should discuss how to generate errors from the results of these analyses. diff --git a/src/borrow_check/region_inference/closure_constraints.md b/src/borrow_check/region_inference/closure_constraints.md new file mode 100644 index 000000000..13230d037 --- /dev/null +++ b/src/borrow_check/region_inference/closure_constraints.md @@ -0,0 +1,10 @@ +# Propagating closure constraints + +When we are checking the type tests and universal regions, we may come +across a constraint that we can't prove yet if we are in a closure +body! However, the necessary constraints may actually hold (we just +don't know it yet). Thus, if we are inside a closure, we just collect +all the constraints we can't prove yet and return them. Later, when we +are borrow check the MIR node that created the closure, we can also +check that these constraints hold. At that time, if we can't prove +they hold, we report an error. diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md new file mode 100644 index 000000000..2e69629b1 --- /dev/null +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -0,0 +1,3 @@ +# Constraint propagation + +The main work of the region inference is **constraint propagation**. diff --git a/src/borrow_check/region_inference/error_reporting.md b/src/borrow_check/region_inference/error_reporting.md new file mode 100644 index 000000000..79b3e077c --- /dev/null +++ b/src/borrow_check/region_inference/error_reporting.md @@ -0,0 +1,3 @@ +# Reporting region errors + +TODO: we should discuss how to generate errors from the results of these analyses. diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md new file mode 100644 index 000000000..0d4068e00 --- /dev/null +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -0,0 +1,441 @@ +# Placeholders and universes + +From time to time we have to reason about regions that we can't +concretely know. For example, consider this program: + +```rust,ignore +// A function that needs a static reference +fn foo(x: &'static u32) { } + +fn bar(f: for<'a> fn(&'a u32)) { + // ^^^^^^^^^^^^^^^^^^^ a function that can accept **any** reference + let x = 22; + f(&x); +} + +fn main() { + bar(foo); +} +``` + +This program ought not to type-check: `foo` needs a static reference +for its argument, and `bar` wants to be given a function that that +accepts **any** reference (so it can call it with something on its +stack, for example). But *how* do we reject it and *why*? + +## Subtyping and Placeholders + +When we type-check `main`, and in particular the call `bar(foo)`, we +are going to wind up with a subtyping relationship like this one: + +```text +fn(&'static u32) <: for<'a> fn(&'a u32) +---------------- ------------------- +the type of `foo` the type `bar` expects +``` + +We handle this sort of subtyping by taking the variables that are +bound in the supertype and replacing them with +[universally quantified](../appendix/background.html#quantified) +representatives, written like `!1`. We call these regions "placeholder +regions" – they represent, basically, "some unknown region". + +Once we've done that replacement, we have the following relation: + +```text +fn(&'static u32) <: fn(&'!1 u32) +``` + +The key idea here is that this unknown region `'!1` is not related to +any other regions. So if we can prove that the subtyping relationship +is true for `'!1`, then it ought to be true for any region, which is +what we wanted. + +So let's work through what happens next. To check if two functions are +subtypes, we check if their arguments have the desired relationship +(fn arguments are [contravariant](../appendix/background.html#variance), so +we swap the left and right here): + +```text +&'!1 u32 <: &'static u32 +``` + +According to the basic subtyping rules for a reference, this will be +true if `'!1: 'static`. That is – if "some unknown region `!1`" lives +outlives `'static`. Now, this *might* be true – after all, `'!1` +could be `'static` – but we don't *know* that it's true. So this +should yield up an error (eventually). + +## What is a universe + +In the previous section, we introduced the idea of a placeholder +region, and we denoted it `!1`. We call this number `1` the **universe +index**. The idea of a "universe" is that it is a set of names that +are in scope within some type or at some point. Universes are formed +into a tree, where each child extends its parents with some new names. +So the **root universe** conceptually contains global names, such as +the the lifetime `'static` or the type `i32`. In the compiler, we also +put generic type parameters into this root universe (in this sense, +there is not just one root universe, but one per item). So consider +this function `bar`: + +```rust,ignore +struct Foo { } + +fn bar<'a, T>(t: &'a T) { + ... +} +``` + +Here, the root universe would consist of the lifetimes `'static` and +`'a`. In fact, although we're focused on lifetimes here, we can apply +the same concept to types, in which case the types `Foo` and `T` would +be in the root universe (along with other global types, like `i32`). +Basically, the root universe contains all the names that +[appear free](../appendix/background.html#free-vs-bound) in the body of `bar`. + +Now let's extend `bar` a bit by adding a variable `x`: + +```rust,ignore +fn bar<'a, T>(t: &'a T) { + let x: for<'b> fn(&'b u32) = ...; +} +``` + +Here, the name `'b` is not part of the root universe. Instead, when we +"enter" into this `for<'b>` (e.g., by replacing it with a placeholder), we will create +a child universe of the root, let's call it U1: + +```text +U0 (root universe) +│ +└─ U1 (child universe) +``` + +The idea is that this child universe U1 extends the root universe U0 +with a new name, which we are identifying by its universe number: +`!1`. + +Now let's extend `bar` a bit by adding one more variable, `y`: + +```rust,ignore +fn bar<'a, T>(t: &'a T) { + let x: for<'b> fn(&'b u32) = ...; + let y: for<'c> fn(&'b u32) = ...; +} +``` + +When we enter *this* type, we will again create a new universe, which +we'll call `U2`. Its parent will be the root universe, and U1 will be +its sibling: + +```text +U0 (root universe) +│ +├─ U1 (child universe) +│ +└─ U2 (child universe) +``` + +This implies that, while in U2, we can name things from U0 or U2, but +not U1. + +**Giving existential variables a universe.** Now that we have this +notion of universes, we can use it to extend our type-checker and +things to prevent illegal names from leaking out. The idea is that we +give each inference (existential) variable – whether it be a type or +a lifetime – a universe. That variable's value can then only +reference names visible from that universe. So for example is a +lifetime variable is created in U0, then it cannot be assigned a value +of `!1` or `!2`, because those names are not visible from the universe +U0. + +**Representing universes with just a counter.** You might be surprised +to see that the compiler doesn't keep track of a full tree of +universes. Instead, it just keeps a counter – and, to determine if +one universe can see another one, it just checks if the index is +greater. For example, U2 can see U0 because 2 >= 0. But U0 cannot see +U2, because 0 >= 2 is false. + +How can we get away with this? Doesn't this mean that we would allow +U2 to also see U1? The answer is that, yes, we would, **if that +question ever arose**. But because of the structure of our type +checker etc, there is no way for that to happen. In order for +something happening in the universe U1 to "communicate" with something +happening in U2, they would have to have a shared inference variable X +in common. And because everything in U1 is scoped to just U1 and its +children, that inference variable X would have to be in U0. And since +X is in U0, it cannot name anything from U1 (or U2). This is perhaps easiest +to see by using a kind of generic "logic" example: + +```text +exists { + forall { ... /* Y is in U1 ... */ } + forall { ... /* Z is in U2 ... */ } +} +``` + +Here, the only way for the two foralls to interact would be through X, +but neither Y nor Z are in scope when X is declared, so its value +cannot reference either of them. + +## Universes and placeholder region elements + +But where does that error come from? The way it happens is like this. +When we are constructing the region inference context, we can tell +from the type inference context how many placeholder variables exist +(the `InferCtxt` has an internal counter). For each of those, we +create a corresponding universal region variable `!n` and a "region +element" `placeholder(n)`. This corresponds to "some unknown set of other +elements". The value of `!n` is `{placeholder(n)}`. + +At the same time, we also give each existential variable a +**universe** (also taken from the `InferCtxt`). This universe +determines which placeholder elements may appear in its value: For +example, a variable in universe U3 may name `placeholder(1)`, `placeholder(2)`, and +`placeholder(3)`, but not `placeholder(4)`. Note that the universe of an inference +variable controls what region elements **can** appear in its value; it +does not say region elements **will** appear. + +## Placeholders and outlives constraints + +In the region inference engine, outlives constraints have the form: + +```text +V1: V2 @ P +``` + +where `V1` and `V2` are region indices, and hence map to some region +variable (which may be universally or existentially quantified). The +`P` here is a "point" in the control-flow graph; it's not important +for this section. This variable will have a universe, so let's call +those universes `U(V1)` and `U(V2)` respectively. (Actually, the only +one we are going to care about is `U(V1)`.) + +When we encounter this constraint, the ordinary procedure is to start +a DFS from `P`. We keep walking so long as the nodes we are walking +are present in `value(V2)` and we add those nodes to `value(V1)`. If +we reach a return point, we add in any `end(X)` elements. That part +remains unchanged. + +But then *after that* we want to iterate over the placeholder `placeholder(x)` +elements in V2 (each of those must be visible to `U(V2)`, but we +should be able to just assume that is true, we don't have to check +it). We have to ensure that `value(V1)` outlives each of those +placeholder elements. + +Now there are two ways that could happen. First, if `U(V1)` can see +the universe `x` (i.e., `x <= U(V1)`), then we can just add `placeholder(x)` +to `value(V1)` and be done. But if not, then we have to approximate: +we may not know what set of elements `placeholder(x)` represents, but we +should be able to compute some sort of **upper bound** B for it – +some region B that outlives `placeholder(x)`. For now, we'll just use +`'static` for that (since it outlives everything) – in the future, we +can sometimes be smarter here (and in fact we have code for doing this +already in other contexts). Moreover, since `'static` is in the root +universe U0, we know that all variables can see it – so basically if +we find that `value(V2)` contains `placeholder(x)` for some universe `x` +that `V1` can't see, then we force `V1` to `'static`. + +## Extending the "universal regions" check + +After all constraints have been propagated, the NLL region inference +has one final check, where it goes over the values that wound up being +computed for each universal region and checks that they did not get +'too large'. In our case, we will go through each placeholder region +and check that it contains *only* the `placeholder(u)` element it is known to +outlive. (Later, we might be able to know that there are relationships +between two placeholder regions and take those into account, as we do +for universal regions from the fn signature.) + +Put another way, the "universal regions" check can be considered to be +checking constraints like: + +```text +{placeholder(1)}: V1 +``` + +where `{placeholder(1)}` is like a constant set, and V1 is the variable we +made to represent the `!1` region. + +## Back to our example + +OK, so far so good. Now let's walk through what would happen with our +first example: + +```text +fn(&'static u32) <: fn(&'!1 u32) @ P // this point P is not imp't here +``` + +The region inference engine will create a region element domain like this: + +```text +{ CFG; end('static); placeholder(1) } + --- ------------ ------- from the universe `!1` + | 'static is always in scope + all points in the CFG; not especially relevant here +``` + +It will always create two universal variables, one representing +`'static` and one representing `'!1`. Let's call them Vs and V1. They +will have initial values like so: + +```text +Vs = { CFG; end('static) } // it is in U0, so can't name anything else +V1 = { placeholder(1) } +``` + +From the subtyping constraint above, we would have an outlives constraint like + +```text +'!1: 'static @ P +``` + +To process this, we would grow the value of V1 to include all of Vs: + +```text +Vs = { CFG; end('static) } +V1 = { CFG; end('static), placeholder(1) } +``` + +At that point, constraint propagation is complete, because all the +outlives relationships are satisfied. Then we would go to the "check +universal regions" portion of the code, which would test that no +universal region grew too large. + +In this case, `V1` *did* grow too large – it is not known to outlive +`end('static)`, nor any of the CFG – so we would report an error. + +## Another example + +What about this subtyping relationship? + +```text +for<'a> fn(&'a u32, &'a u32) + <: +for<'b, 'c> fn(&'b u32, &'c u32) +``` + +Here we would replace the bound region in the supertype with a placeholder, as before, yielding: + +```text +for<'a> fn(&'a u32, &'a u32) + <: +fn(&'!1 u32, &'!2 u32) +``` + +then we instantiate the variable on the left-hand side with an +existential in universe U2, yielding the following (`?n` is a notation +for an existential variable): + +```text +fn(&'?3 u32, &'?3 u32) + <: +fn(&'!1 u32, &'!2 u32) +``` + +Then we break this down further: + +```text +&'!1 u32 <: &'?3 u32 +&'!2 u32 <: &'?3 u32 +``` + +and even further, yield up our region constraints: + +```text +'!1: '?3 +'!2: '?3 +``` + +Note that, in this case, both `'!1` and `'!2` have to outlive the +variable `'?3`, but the variable `'?3` is not forced to outlive +anything else. Therefore, it simply starts and ends as the empty set +of elements, and hence the type-check succeeds here. + +(This should surprise you a little. It surprised me when I first realized it. +We are saying that if we are a fn that **needs both of its arguments to have +the same region**, we can accept being called with **arguments with two +distinct regions**. That seems intuitively unsound. But in fact, it's fine, as +I tried to explain in [this issue][ohdeargoditsallbroken] on the Rust issue +tracker long ago. The reason is that even if we get called with arguments of +two distinct lifetimes, those two lifetimes have some intersection (the call +itself), and that intersection can be our value of `'a` that we use as the +common lifetime of our arguments. -nmatsakis) + +[ohdeargoditsallbroken]: https://github.com/rust-lang/rust/issues/32330#issuecomment-202536977 + +## Final example + +Let's look at one last example. We'll extend the previous one to have +a return type: + +```text +for<'a> fn(&'a u32, &'a u32) -> &'a u32 + <: +for<'b, 'c> fn(&'b u32, &'c u32) -> &'b u32 +``` + +Despite seeming very similar to the previous example, this case is going to get +an error. That's good: the problem is that we've gone from a fn that promises +to return one of its two arguments, to a fn that is promising to return the +first one. That is unsound. Let's see how it plays out. + +First, we replace the bound region in the supertype with a placeholder: + +```text +for<'a> fn(&'a u32, &'a u32) -> &'a u32 + <: +fn(&'!1 u32, &'!2 u32) -> &'!1 u32 +``` + +Then we instantiate the subtype with existentials (in U2): + +```text +fn(&'?3 u32, &'?3 u32) -> &'?3 u32 + <: +fn(&'!1 u32, &'!2 u32) -> &'!1 u32 +``` + +And now we create the subtyping relationships: + +```text +&'!1 u32 <: &'?3 u32 // arg 1 +&'!2 u32 <: &'?3 u32 // arg 2 +&'?3 u32 <: &'!1 u32 // return type +``` + +And finally the outlives relationships. Here, let V1, V2, and V3 be the +variables we assign to `!1`, `!2`, and `?3` respectively: + +```text +V1: V3 +V2: V3 +V3: V1 +``` + +Those variables will have these initial values: + +```text +V1 in U1 = {placeholder(1)} +V2 in U2 = {placeholder(2)} +V3 in U2 = {} +``` + +Now because of the `V3: V1` constraint, we have to add `placeholder(1)` into `V3` (and +indeed it is visible from `V3`), so we get: + +```text +V3 in U2 = {placeholder(1)} +``` + +then we have this constraint `V2: V3`, so we wind up having to enlarge +`V2` to include `placeholder(1)` (which it can also see): + +```text +V2 in U2 = {placeholder(1), placeholder(2)} +``` + +Now constraint propagation is done, but when we check the outlives +relationships, we find that `V2` includes this new element `placeholder(1)`, +so we report an error. From 4615a9a1f7079d9ec6ce788a46967fb8666bfce1 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 18 Jun 2019 10:55:07 -0400 Subject: [PATCH 0586/1812] start filling out the constraint propagation chapter in more detail --- .../constraint_propagation.md | 145 +++++++++++++++++- 1 file changed, 144 insertions(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 2e69629b1..ce01764c4 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -1,3 +1,146 @@ # Constraint propagation -The main work of the region inference is **constraint propagation**. +The main work of the region inference is **constraint +propagation**. This means processing the set of constraints to compute +the final values for all the region variables. + +## Kinds of constraints + +Each kind of constraint is handled somewhat differently by the region inferencer. + +### Liveness constraints + +A **liveness constraint** arises when some variable whose type +includes a region R is live at some point P. This simply means that +the value of R must include the point P. Liveness constraints are +computed by the MIR type checker. + +We represent them by keeping a (sparse) bitset for each region +variable, which is the field [`liveness_constraints`], of type +[`LivenessValues`] + +[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints +[`LivenessValues`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/values/struct.LivenessValues.html + +### Outlives constraints + +An outlives constraint `'a: 'b` indicates that the value of `'a` must +be a **superset** of the value of `'b`. On creation, we are given a +set of outlives constraints in the form of a +[`ConstraintSet`]. However, to work more efficiently with outlives +constraints, they are [converted into the form of a graph][graph-fn], +where the nodes of the graph are region variables (`'a`, `'b`) and +each constraint `'a: 'b` induces an edge `'a -> 'b`. This conversion +happens in the [`RegionInferenceContext::new`] function that creates +the inference context. + +[`ConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.ConstraintSet.html +[graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.ConstraintSet.html#method.graph +[`RegionInferenceContext::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.new + +### Member constraints + +A member constraint `'m member of ['c_1..'c_N]` expresses that the +region `'m` must be *equal* to some **choice regions** `'c_i` (for +some `i`). These constraints cannot be expressed by users, but they arise +from `impl Trait` due to its lifetime capture rules. Consinder a function +such as the following: + +```rust +fn make(a: &'a u32, b: &'b u32) -> impl Trait<'a, 'b> { .. } +``` + +Here, the true return type (often called the "hidden type") is only +permitted to capture the lifeimes `'a` or `'b`. You can kind of see +this more clearly by desugaring that `impl Trait` return type into its +more explicit form: + +```rust +type MakeReturn<'x, 'y> = impl Trait<'x, 'y>; +fn make(a: &'a u32, b: &'b u32) -> MakeReturn<'a, 'b> { .. } +``` + +Here, the idea is that the hidden type must be some type that could +have been written in place of the `impl Trait<'x, 'y>` -- but clearly +such a type can only reference the regions `'x` or `'y` (or +`'static`!), as those are the only names in scope. This limitation is +then translated into a restriction to only access `'a` or `'b` because +we are returning `MakeReturn<'a, 'b>`, where `'x` and `'y` have been +replaced with `'a` and `'b` respectively. + +## SCCs in the outlives constraint graph + +The most common sort of constraint in practice are outlives +constraints like `'a: 'b`. Such a cosntraint means that `'a` is a +superset of `'b`. So what happens if we have two regions `'a` and `'b` +that mutually outlive one another, like so? + +``` +'a: 'b +'b: 'a +``` + +In this case, we can conclude that `'a` and `'b` must be equal +sets. In fact, it doesn't have to be just two regions. We could create +an extended "chain" of outlives constraints: + +``` +'a: 'b +'b: 'c +'c: 'd +'d: 'a +``` + +Here, we know that `'a..'d` are all equal to one another. + +As mentioned above, an outlives constraint like `'a: 'b` can be viewed +as an edge in a graph `'a -> 'b`. Cycles in this graph indicate regions +that mutually outlive one another and hence must be equal. + +Therefore, one of the first things that we do in propagating region +values is to compute the **strongly connected components** (SCCs) in +the constraint graph. The result is stored in the [`constraint_sccs`] +field. You can then easily find the SCC that a region `r` is a part of +by invoking `constraint_sccs.scc(r)`. + +Working in terms of SCCs allows us to be more efficient: if we have a +set of regions `'a...'d` that are part of a single SCC, we don't have +to compute/store their values separarely. We can just store one value +**for the SCC**, since they must all be equal. + +If you look over the region inference code, you will see that a number +of fields are defined in terms of SCCs. For example, the +[`scc_values`] field stores the values of each SCC. To get the value +of a specific region `'a` then, we first figure out the SCC that the +region is a part of, and then find the value of that SCC. + +[`constraint_sccs`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.constraint_sccs +[`scc_values`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.scc_values + +When we compute SCCs, we not only figure out which regions are a +member of each SCC, we also figure out the edges between them. So for example +consider this set of outlives constraints: + +``` +'a: 'b +'b: 'a + +'a: 'c + +'c: 'd +'d: 'c +``` + +Here we have two SCCs: S0 contains `'a` and `'b`, and S1 contains `'c` +and `'d`. But these SCCs are not independent: because `'a: 'c`, that +means that `S0: S1` as well. That is -- the value of `S0` must be a +superset of the value of `S1`. One crucial thing is that this graph of +SCCs is always a DAG -- that is, it never has cycles. This is because +all the cycles have been removed to form the SCCs themselves. + +## How constraint propagation works + +The main work of constraint propagation is done in the +`propagation_constraints` function. + +[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints From 472f4e83670fea495daa8cbc64e070cae70d3cc2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 20 Jun 2019 09:43:48 -0400 Subject: [PATCH 0587/1812] describe region inference and member constraints in some detail --- src/SUMMARY.md | 2 + src/borrow_check/region_inference.md | 2 + .../constraint_propagation.md | 212 ++++++++++++------ .../region_inference/lifetime_parameters.md | 125 +++++++++++ .../region_inference/member_constraints.md | 193 ++++++++++++++++ 5 files changed, 466 insertions(+), 68 deletions(-) create mode 100644 src/borrow_check/region_inference/lifetime_parameters.md create mode 100644 src/borrow_check/region_inference/member_constraints.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 7e9a9ee54..69e46b796 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -77,6 +77,8 @@ - [MIR type checker](./borrow_check/type_check.md) - [Region inference](./borrow_check/region_inference.md) - [Constraint propagation](./borrow_check/region_inference/constraint_propagation.md) + - [Lifetime parameters](./borrow_check/region_inference/lifetime_parameters.md) + - [Member constraints](./borrow_check/region_inference/member_constraints.md) - [Placeholders and universes](./borrow_check/region_inference/placeholders_and_universes.md) - [Closure constraints](./borrow_check/region_inference/closure_constraints.md) - [Errror reporting](./borrow_check/region_inference/error_reporting.md) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 5279d210b..e9f0e35e3 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -71,6 +71,8 @@ TODO: write about _how_ these regions are computed. [`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/universal_regions/struct.UniversalRegions.html + + ## Region variables The value of a region can be thought of as a **set**. This set contains all diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index ce01764c4..e2c36062f 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -1,88 +1,121 @@ # Constraint propagation -The main work of the region inference is **constraint -propagation**. This means processing the set of constraints to compute -the final values for all the region variables. +The main work of the region inference is **constraint propagation**, +which is done in the [`propagate_constraints`] function. There are +three sorts of constraints that are used in NLL, and we'll explain how +`propagate_constraints` works by "layering" those sorts of constraints +on one at a time (each of them is fairly independent from the others): -## Kinds of constraints +- liveness constraints (`R live at E`), which arise from liveness; +- outlives constraints (`R1: R2`), which arise from subtyping; +- [member constraints][m_c] (`member R_m of [R_c...]`), which arise from impl Trait. -Each kind of constraint is handled somewhat differently by the region inferencer. +[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints +[m_c]: ./member_constraints.html + +In this chapter, we'll explain the "heart" of constraint propagation, +covering both liveness and outlives constraints. + +## Notation and high-level concepts + +Conceptually, region inference is a "fixed-point" computation. It is +given some set of constraints `{C}` and it computes a set of values +`Values: R -> {E}` that maps each region `R` to a set of elements +`{E}` (see [here][riv] for more notes on region elements): + +- Initially, each region is mapped to an empty set, so `Values(R) = + {}` for all regions `R`. +- Next, we process the constraints repeatedly until a fixed-point is reached: + - For each constraint C: + - Update `Values` as needed to satisfy the constraint -### Liveness constraints +[riv]: ../region-inference.html#region-variables + +As a simple example, if we have a liveness constraint `R live at E`, +then we can apply `Values(R) = Values(R) union {E}` to make the +constraint be satisfied. Similarly, if we have an outlives constraints +`R1: R2`, we can apply `Values(R1) = Values(R1) union Values(R2)`. +(Member constraints are more complex and we discuss them below.) + +In practice, however, we are a bit more clever. Instead of applying +the constraints in a loop, we can analyze the constraints and figure +out the correct order to apply them, so that we only have to apply +each constraint once in order to find the final result. + +Similarly, in the implementation, the `Values` set is stored in the +`scc_values` field, but they are indexed not by a *region* but by a +*strongly connected component* (SCC). SCCs are an optimization that +avoids a lot of redundant storage and computation. They are explained +in the section on outlives constraints. + +## Liveness constraints A **liveness constraint** arises when some variable whose type includes a region R is live at some point P. This simply means that the value of R must include the point P. Liveness constraints are computed by the MIR type checker. -We represent them by keeping a (sparse) bitset for each region -variable, which is the field [`liveness_constraints`], of type -[`LivenessValues`] +A liveness constraint `R live at E` is satisfied if `E` is a member of +`Values(R)`. So to "apply" such a constraint to `Values`, we just have +to compute `Values(R) = Values(R) union {E}`. + +The liveness values are computed in the type-check and passes to the +region inference upon creation in the `liveness_constraints` argument. +These are not represented as individual constraints like `R live at E` +though; instead, we store a (sparse) bitset per region variable (of +type [`LivenessValues`]). This way we only need a single bit for each +liveness constraint. [`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints [`LivenessValues`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/values/struct.LivenessValues.html -### Outlives constraints +One thing that is worth mentioning: All lifetime parameters are always +considered to be live over the entire function body. This is because +they correspond to some portion of the *caller's* execution, and that +execution clearly includes the time spent in this function, since the +caller is waiting for us to return. -An outlives constraint `'a: 'b` indicates that the value of `'a` must -be a **superset** of the value of `'b`. On creation, we are given a -set of outlives constraints in the form of a -[`ConstraintSet`]. However, to work more efficiently with outlives -constraints, they are [converted into the form of a graph][graph-fn], -where the nodes of the graph are region variables (`'a`, `'b`) and -each constraint `'a: 'b` induces an edge `'a -> 'b`. This conversion -happens in the [`RegionInferenceContext::new`] function that creates -the inference context. - -[`ConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.ConstraintSet.html -[graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.ConstraintSet.html#method.graph -[`RegionInferenceContext::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.new +## Outlives constraints -### Member constraints +An outlives constraint `'a: 'b` indicates that the value of `'a` must +be a **superset** of the value of `'b`. That is, an outlives +constraint `R1: R2` is satisfied if `Values(R1)` is a superset of +`Values(R2)`. So to "apply" such a constraint to `Values`, we just +have to compute `Values(R1) = Values(R1) union Values(R2)`. -A member constraint `'m member of ['c_1..'c_N]` expresses that the -region `'m` must be *equal* to some **choice regions** `'c_i` (for -some `i`). These constraints cannot be expressed by users, but they arise -from `impl Trait` due to its lifetime capture rules. Consinder a function -such as the following: +One observation that follows from this is that if you have `R1: R2` +and `R2: R1`, then `R1 = R2` must be true. Similarly, if you have: -```rust -fn make(a: &'a u32, b: &'b u32) -> impl Trait<'a, 'b> { .. } ``` - -Here, the true return type (often called the "hidden type") is only -permitted to capture the lifeimes `'a` or `'b`. You can kind of see -this more clearly by desugaring that `impl Trait` return type into its -more explicit form: - -```rust -type MakeReturn<'x, 'y> = impl Trait<'x, 'y>; -fn make(a: &'a u32, b: &'b u32) -> MakeReturn<'a, 'b> { .. } +R1: R2 +R2: R3 +R3: R4 +R4: R1 ``` -Here, the idea is that the hidden type must be some type that could -have been written in place of the `impl Trait<'x, 'y>` -- but clearly -such a type can only reference the regions `'x` or `'y` (or -`'static`!), as those are the only names in scope. This limitation is -then translated into a restriction to only access `'a` or `'b` because -we are returning `MakeReturn<'a, 'b>`, where `'x` and `'y` have been -replaced with `'a` and `'b` respectively. +then `R1 = R2 = R3 = R4` follows. We take advantage of this to make things +much faster, as described shortly. -## SCCs in the outlives constraint graph +In the code, the set of outlives constraints is given to the region +inference context on creation in a parameter of type +[`ConstraintSet`]. The constraint set is basically just a list of `'a: +'b` constraints. -The most common sort of constraint in practice are outlives -constraints like `'a: 'b`. Such a cosntraint means that `'a` is a -superset of `'b`. So what happens if we have two regions `'a` and `'b` -that mutually outlive one another, like so? +### The outlives constraint graph and SCCs -``` -'a: 'b -'b: 'a -``` +In order to work more efficiently with outlives constraints, they are +[converted into the form of a graph][graph-fn], where the nodes of the +graph are region variables (`'a`, `'b`) and each constraint `'a: 'b` +induces an edge `'a -> 'b`. This conversion happens in the +[`RegionInferenceContext::new`] function that creates the inference +context. + +[`ConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.ConstraintSet.html +[graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.ConstraintSet.html#method.graph +[`RegionInferenceContext::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.new -In this case, we can conclude that `'a` and `'b` must be equal -sets. In fact, it doesn't have to be just two regions. We could create -an extended "chain" of outlives constraints: +When using a graph representation, we can detect regions that must be equal +by looking for cycles. That is, if you have a constraint like ``` 'a: 'b @@ -91,11 +124,8 @@ an extended "chain" of outlives constraints: 'd: 'a ``` -Here, we know that `'a..'d` are all equal to one another. - -As mentioned above, an outlives constraint like `'a: 'b` can be viewed -as an edge in a graph `'a -> 'b`. Cycles in this graph indicate regions -that mutually outlive one another and hence must be equal. +then this will correspond to a cycle in the graph containing the +elements `'a...'d`. Therefore, one of the first things that we do in propagating region values is to compute the **strongly connected components** (SCCs) in @@ -138,9 +168,55 @@ superset of the value of `S1`. One crucial thing is that this graph of SCCs is always a DAG -- that is, it never has cycles. This is because all the cycles have been removed to form the SCCs themselves. -## How constraint propagation works +### Applying liveness constraints to SCCs + +The liveness constraints that come in from the type-checker are +expressed in terms of regions -- that is, we have a map like +`Liveness: R -> {E}`. But we want our final result to be expressed +in terms of SCCs -- we can integrate these liveness constraints very +easily just by taking the union: + +``` +for each region R: + let S by the SCC that contains R + Values(S) = Values(S) union Liveness(R) +``` + +In the region inferencer, this step is done in [`RegionInferenceContext::new`]. + +### Applying outlives constraints + +Once we have computed the DAG of SCCs, we use that to structure out +entire computation. If we have an edge `S1 -> S2` between two SCCs, +that means that `Values(S1) >= Values(S2)` must hold. So, to compute +the value of `S1`, we first compute the values of each successor `S2`. +Then we simply union all of those values together. To use a +quasi-iterator-like notation: + +``` +Values(S1) = + s1.successors() + .map(|s2| Values(s2)) + .union() +``` + +In the code, this work starts in the [`propagate_constraints`] +function, which iterates over all the SCCs. For each SCC S1, we +compute its value by first computing the value of its +successors. Since SCCs form a DAG, we don't have to be conecrned about +cycles, though we do need to keep a set around to track whether we +have already processed a given SCC or not. For each successor S2, once +we have computed S2's value, we can union those elements into the +value for S1. (Although we have to be careful in this process to +properly handle [higher-ranked +placeholders](./placeholders_and_universes.html). Note that the value +for S1 already contains the liveness constraints, since they were +added in [`RegionInferenceContext::new`]. + +Once that process is done, we now have the "minimal value" for S1, +taking into account all of the liveness and outlives +constraints. However, in order to complete the process, we must also +consider [member constraints][m_c], which are described in [a later +section][m_c]. -The main work of constraint propagation is done in the -`propagation_constraints` function. -[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md new file mode 100644 index 000000000..10759ee56 --- /dev/null +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -0,0 +1,125 @@ +# Universal regions + +"Universal regions" is the name that the code uses to refer to "named +lifetimes" -- e.g., lifetime parameters and `'static`. The name +derives from the fact that such lifetimes are "universally quantified" +(i.e., we must make sure the code is true for all values of those +lifetimes). It is worth spending a bit of discussing how lifetime +parameters are handled during region inference. Consider this example: + +```rust +fn foo<'a, 'b>(x: &'a u32, y: &'b u32) -> &'b u32 { + x +} +``` + +This example is intended not to compile, because we are returning `x`, +which has type `&'a u32`, but our signature promises that we will +return a `&'b u32` value. But how are lifetimes like `'a` and `'b +integrated into region inference, and how this error wind up being +detected? + +## Universal regions and their relationships to one another + +Early on in region inference, one of the first things we do is to +construct a [`UniversalRegions`] struct. This struct tracks the +various universal regions in scope on a particular function. We also +create a [`UniversalRegionRelations`] struct, which tracks their +relationships to one another. So if you have e.g. `where 'a: 'b`, then +the [`UniversalRegionRelations`] struct would track that `'a: 'b` is +known to hold (which could be tested with the [`outlives`] function. + +[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/universal_regions/struct.UniversalRegions.html +[`UniversalRegionsRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/type_check/free_region_relations/struct.UniversalRegionRelations.html +[`outlives`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/type_check/free_region_relations/struct.UniversalRegionRelations.html#method.outlives + +## Everything is a region variable + +One important aspect of how NLL region inference works is that **all +lifetimes** are represented as numbered variables. This means that the +only variant of [`ty::RegionKind`] that we use is the [`ReVar`] +variant. These region variables are broken into two major categories, +based on their index: + +[`ty::RegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html +[`ReVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#variant.ReVar + +- 0..N: universal regions -- the ones we are discussing here. In this + case, the code must be correct with respect to any value of those + variables that meets the declared relationships. +- N..M: existential regions -- inference variables where the region + inferencer is tasked with finding *some* suitable value. + +In fact, the universal regions can be further subdivided based on +where they were brought into scope (see the [`RegionClassification`] +type). These subdivions are not important for the topics discussed +here, but become important when we consider [closure constraint +propagation](./closure_constraints.html), so we discuss them there. + +[`RegionClassification`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/universal_regions/enum.RegionClassification.html#variant.Local + +## Universal lifetimes as the elements of a region's value + +As noted previously, the value that we infer for each region is a set +`{E}`. The elements of this set can be points in the control-flow +graph, but they can also be an element `end('a)` corresponding to each +universal lifetime `'a`. If the value for some region `R0` includes +`end('a`), then this implies that R0 must extend until the end of `'a` +in the caller. + +## The "value" of a universal region + +During region inference, we compute a value for each universal region +in the same way as we compute values for other regions. This value +represents, effectively, the **lower bound** on that universal region +-- the things that it must outlive. We now describe how we use this +value to check for errors. + +## Liveness and universal regions + +All universal regions have an initial liveness constraint that +includes the entire function body. This is because lifetime parameters +are defined in the caller and must include the entirety of the +function call that invokes this particular function. In addition, each +universal region `'a` includes itself (that is, `end('a)`) in its +liveness constraint (i.e., `'a` must extend until the end of +itself). In the code, these liveness constraints are setup in +[`init_free_and_bound_regions`]. + +[`init_free_and_bound_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.init_free_and_bound_regions + +## Propagating outlives constraints for universal regions + +So, consider the first example of this section: + +```rust +fn foo<'a, 'b>(x: &'a u32, y: &'b u32) -> &'b u32 { + x +} +``` + +Here, returning `x` requires that `&'a u32 <: &'b u32`, which gives +rise to an outlives constraint `'a: 'b`. Combined with our default liveness +constraints we get: + +``` +'a live at {B, end('a)} // B represents the "bunction body" +'b live at {B, end('b)} +'a: 'b +``` + +When we process the `'a: 'b` constraint, therefore, we will add +`end('b)` into the value for `'a`, resulting in a final value of `{B, +end('a), end('b)}`. + +## Detecting errors + +Once we have finished constraint propagation, we then enforce a +constraint that if some universal region `'a` includes an element +`end('b)`, then `'a: 'b` must be declared in the function's bounds. If +not, as in our example, that is an error. This check is done in the +[`check_universal_regions`] function, which simply iterates over all +universal regions, inspects their final value, and tests against the +declared [`UniversalRegionRelations`]. + +[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md new file mode 100644 index 000000000..4d7312644 --- /dev/null +++ b/src/borrow_check/region_inference/member_constraints.md @@ -0,0 +1,193 @@ +# Member constraints + +A member constraint `'m member of ['c_1..'c_N]` expresses that the +region `'m` must be *equal* to some **choice regions** `'c_i` (for +some `i`). These constraints cannot be expressed by users, but they +arise from `impl Trait` due to its lifetime capture rules. Consinder a +function such as the following: + +```rust +fn make(a: &'a u32, b: &'b u32) -> impl Trait<'a, 'b> { .. } +``` + +Here, the true return type (often called the "hidden type") is only +permitted to capture the lifeimes `'a` or `'b`. You can kind of see +this more clearly by desugaring that `impl Trait` return type into its +more explicit form: + +```rust +type MakeReturn<'x, 'y> = impl Trait<'x, 'y>; +fn make(a: &'a u32, b: &'b u32) -> MakeReturn<'a, 'b> { .. } +``` + +Here, the idea is that the hidden type must be some type that could +have been written in place of the `impl Trait<'x, 'y>` -- but clearly +such a type can only reference the regions `'x` or `'y` (or +`'static`!), as those are the only names in scope. This limitation is +then translated into a restriction to only access `'a` or `'b` because +we are returning `MakeReturn<'a, 'b>`, where `'x` and `'y` have been +replaced with `'a` and `'b` respectively. + +## Detailed example + +To help us explain member constraints in more detail, let's spell out +the `make` example in a bit more detail. First off, let's assume that +you have some dummy trait: + +```rust +trait Trait<'a, 'b> { } +impl Trait<'_, '_> for T { } +``` + +and this is the `make` function (in desugared form): + +```rust +type MakeReturn<'x, 'y> = impl Trait<'x, 'y>; +fn make(a: &'a u32, b: &'b u32) -> MakeReturn<'a, 'b> { + (a, b) +} +``` + +What happens in this case is that the return type will be `(&'0 u32, &'1 u32)`, +where `'0` and `'1` are fresh region variables. We will have the following +region constraints: + +``` +'0 live at {L} +'1 live at {L} +'a: '0 +'b: '1 +'0 member of ['a, 'b, 'static] +'1 member of ['a, 'b, 'static] +``` + +Here the "liveness set" `{L}` corresponds to that subset of the body +where `'0` and `'1` are live -- basically the point from where the +return tuple is constructed to where it is returned (in fact, `'0` and +`'1` might have slightly different liveness sets, but that's not very +interesting to the point we are illustrating here). + +The `'a: '0` and `'b: '1` constraints arise from subtyping. When we +construct the `(a, b)` value, it will be assigned type `(&'0 u32, &'1 +u32)` -- the region variables reflect that the lifetime of this +references could be made smaller. For this value to be created from +`a` and `b`, however, we do require that: + +``` +(&'a u32, &'b u32) <: (&'0 u32, &'1 u32) +``` + +which means in turn that `&'a u32 <: &'0 u32` and hence that `'a: '0` +(and similarly that `&'b u32 <: &'1 u32`, `'b: '1`). + +Note that if we ignore member constraints, the value of `'0` would be +inferred to some subset of the function body (from the liveness +constraints, which we did not write explicitly). It would never become +`'a`, because there is no need for it too -- we have a constraint that +`'a: '0`, but that just puts a "cap" on how *large* `'0` can grow to +become. Since we compute the *minimal* value that we can, we are happy +to leave `'0` as being just equal to the liveness set. This is where +member constraints come in. + +## Choices are always lifetime parameters + +At present, the "choice" regions from a member constraint are always +lifetime parameters from the current function. This falls out from the +placement of impl Trait, though in the future it may not be the case. +We take some advantage of this fact, as it simplifies the current +code. In particular, we don't have to consider a case like `'0 member +of ['1, 'static]`, in which the value of both `'0` and `'1` are being +inferred and hence changing. See [rust-lang/rust#61773] for more +information. + +[#61773]: https://github.com/rust-lang/rust/issues/61773 + +## Applying member constraints + +Member constraints are a bit more complex than other forms of +constraints. This is because they have a "or" quality to them -- that +is, they describe multiple choices that we must select from. E.g., in +our example constraint `'0 member of ['a, 'b, 'static]`, it might be +that `'0` is equal to `'a`, `'b`, *or* `'static`. How can we pick the +correct one? What we currently do is to look for a *minimal choice* +-- if we find one, then we will grow `'0` to be equal to that minimal +choice. To find that minimal choice, we take two factors into +consideration: lower and upper bounds. + +### Lower bounds + +The *lower bounds* are those lifetimes that `'0` *must outlive* -- +i.e., that `'0` must be larger than. In fact, when it comes time to +apply member constraints, we've already *computed* the lower bounds of +`'0` because we computed its minimal value (or at least, the lower +bounds considering everything but member constraints). + +Let `LB` be the current value of `'0`. We know then that `'0: LB` must +hold, whatever the final value of `'0` is. Therefore, we can rule out +any choice where `'choice` where `'choice: LB` does not hold. + +Unfortunately, in our example, this is not very helpful. The lower +bound for `'0` will just be the liveness set `{L}`, and we know that +all the lifetime parameters outlive that set. So we are left with the +same set of choices here. (But in other examples, particularly those +with different variance, lower bound constraints may be relevant.) + +### Upper bounds + +The *upper bounds* are those lifetimes that *must outlive* `'0` -- +i.e., that `'0` must be *smaller* then. In our example, this would be +`'a`, because we have the constraint that `'a: '0`. In more complex +examples, the chain may be more indirect. + +We can use upper bounds to rule out members in a very similar way to +lower lower bounds. If UB is some upper bound, then we know that `UB: +'0` must hold, so we can rule out any choice `'choice` where `UB: +'choice` does not hold. + +In our example, we would be able to reduce our choice set from `['a, +'b, 'static]` to just `['a]`. This is because `'0` has an upper bound +of `'a`, and neither `'a: 'b` nor `'a: 'static` is known to hold. + +(For notes on how we collect upper bounds in the implementation, see +[the section below](#collecting).) + +### Minimal choice + +After applying lower and upper bounds, we can still sometimes have +multiple possibilities. For example, imagine a variant of our example +using types with the opposite variance. In that case, we would have +the constraint `'0: 'a` instead of `'a: '0`. Hence the current value +of `'0` would be `{L, 'a}`. Using this as a lower bound, we would be +able to narrow down the member choices to `['a, 'static]` because `'b: +'a` is not known to hold (but `'a: 'a` and `'static: 'a` do hold). We +would not have any upper bounds, so that would be our final set of choices. + +In that case, we apply the **minimal choice** rule -- basically, if +one of our choices if smaller than the others, we can use that. In +this case, we would opt for `'a` (and not `'static`). + +This choice is consistent with the general 'flow' of region +propagation, which always aims to compute a minimal value for the +region being inferred. However, it is somewhat arbitrary. + + + +### Collecting upper bounds in the implementation + +In practice, computing upper bounds is a bit inconvenient, because our +data structures are setup for the opposite. What we do is to compute +the **reverse SCC graph** (we do this lazilly and cache the result) -- +that is, a graph where `'a: 'b` induces an edge `SCC('b) -> +SCC('a)`. Like the normal SCC graph, this is a DAG. We can then do a +depth-first search starting from `SCC('0)` in this graph. This will +take us to all the SCCs that must outlive `'0`. + +One wrinkle is that, as we walk the "upper bound" SCCs, their values +will not yet have been fully computed. However, we **have** already +applied their liveness constraints, so we have some information about +their value. In particular, for any regions representing lifetime +parameters, their value will contain themselves (i.e., the initial +value for `'a` includes `'a` and the value for `'b` contains `'b`). So +we can collect all of the lifetime parameters that are reachable, +which is precisely what we are interested in. + From bd347df7514d8f0d5bf9631a4230c78940c4eede Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 20 Jun 2019 09:51:11 -0400 Subject: [PATCH 0588/1812] adjust overview slightly --- src/borrow_check/region_inference.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index e9f0e35e3..46caab567 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -24,20 +24,19 @@ The MIR-based region analysis consists of two major functions: - [`compute_regions`], invoked second: this is given as argument the results of move analysis. It has the job of computing values for all the inference variables that `replace_regions_in_mir` introduced. - - To do that, it first runs the [MIR type checker]. This - is basically a normal type-checker but specialized to MIR, which - is much simpler than full Rust, of course. Running the MIR type - checker will however create **outlives constraints** between - region variables (e.g., that one variable must outlive another - one) to reflect the subtyping relationships that arise. - - It also adds **liveness constraints** that arise from where variables - are used. - - After this, we create a [`RegionInferenceContext`] with the constraints we - have computed and the inference variables we introduced and use the - [`solve`] method to infer values for all region inference varaibles. + - To do that, it first runs the [MIR type checker]. This is + basically a normal type-checker but specialized to MIR, which is + much simpler than full Rust, of course. Running the MIR type + checker will however create various [constraints][cp] between region + variables, indicating their potential values and relationships to + one another. + - After this, we perform [constraint propagation][cp] by creating a + [`RegionInferenceContext`] and invoking its [`solve`] + method. - The [NLL RFC] also includes fairly thorough (and hopefully readable) coverage. +[cp]: ./region_inference/constraint_propagation.html [fvb]: ../appendix/background.html#free-vs-bound [`replace_regions_in_mir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.replace_regions_in_mir.html [`compute_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.compute_regions.html @@ -105,8 +104,10 @@ The kinds of region elements are as follows: ## Constraints -Before we can infer the value of regions, we need to collect constraints on the -regions. There are two primary types of constraints. +Before we can infer the value of regions, we need to collect +constraints on the regions. The full set of constraints is described +in [the section on constraint propagation][cp], but the two most +common sorts of constraints are: 1. Outlives constraints. These are constraints that one region outlives another (e.g. `'a: 'b`). Outlives constraints are generated by the [MIR type From 5c92fc254ea793df7a79c746bad5913925c41d82 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:32:53 -0400 Subject: [PATCH 0589/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: lqd --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index e2c36062f..385e04892 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -178,7 +178,7 @@ easily just by taking the union: ``` for each region R: - let S by the SCC that contains R + let S be the SCC that contains R Values(S) = Values(S) union Liveness(R) ``` From 989c943eb3e34ef34873c67eb2018cb37c4347a2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:02 -0400 Subject: [PATCH 0590/1812] Update src/borrow_check/region_inference/lifetime_parameters.md Co-Authored-By: lqd --- src/borrow_check/region_inference/lifetime_parameters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index 10759ee56..1a50f45f9 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -15,7 +15,7 @@ fn foo<'a, 'b>(x: &'a u32, y: &'b u32) -> &'b u32 { This example is intended not to compile, because we are returning `x`, which has type `&'a u32`, but our signature promises that we will -return a `&'b u32` value. But how are lifetimes like `'a` and `'b +return a `&'b u32` value. But how are lifetimes like `'a` and `'b` integrated into region inference, and how this error wind up being detected? From 13691d6372a6f330f76b3d4525564e8a479b2df6 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:15 -0400 Subject: [PATCH 0591/1812] Update src/borrow_check/region_inference/lifetime_parameters.md Co-Authored-By: lqd --- src/borrow_check/region_inference/lifetime_parameters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index 1a50f45f9..798af1337 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -103,7 +103,7 @@ rise to an outlives constraint `'a: 'b`. Combined with our default liveness constraints we get: ``` -'a live at {B, end('a)} // B represents the "bunction body" +'a live at {B, end('a)} // B represents the "function body" 'b live at {B, end('b)} 'a: 'b ``` From 3435363ef36fc804553a97734197678ccbe6c991 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:24 -0400 Subject: [PATCH 0592/1812] Update src/borrow_check/region_inference/lifetime_parameters.md Co-Authored-By: lqd --- src/borrow_check/region_inference/lifetime_parameters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index 798af1337..aa36d7dbb 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -30,7 +30,7 @@ the [`UniversalRegionRelations`] struct would track that `'a: 'b` is known to hold (which could be tested with the [`outlives`] function. [`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/universal_regions/struct.UniversalRegions.html -[`UniversalRegionsRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/type_check/free_region_relations/struct.UniversalRegionRelations.html +[`UniversalRegionRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/type_check/free_region_relations/struct.UniversalRegionRelations.html [`outlives`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/type_check/free_region_relations/struct.UniversalRegionRelations.html#method.outlives ## Everything is a region variable From 53f83a9b1ca0dad9642fa7d07fe275a196e592ea Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:33 -0400 Subject: [PATCH 0593/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: lqd --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 385e04892..88fb00a7d 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -201,7 +201,7 @@ Values(S1) = ``` In the code, this work starts in the [`propagate_constraints`] -function, which iterates over all the SCCs. For each SCC S1, we +function, which iterates over all the SCCs. For each SCC `S1`, we compute its value by first computing the value of its successors. Since SCCs form a DAG, we don't have to be conecrned about cycles, though we do need to keep a set around to track whether we From 6e64baba5e5e3900e01fcd80c3bd63cca1848eda Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:41 -0400 Subject: [PATCH 0594/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: lqd --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 88fb00a7d..87a72eb1d 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -205,7 +205,7 @@ function, which iterates over all the SCCs. For each SCC `S1`, we compute its value by first computing the value of its successors. Since SCCs form a DAG, we don't have to be conecrned about cycles, though we do need to keep a set around to track whether we -have already processed a given SCC or not. For each successor S2, once +have already processed a given SCC or not. For each successor `S2`, once we have computed S2's value, we can union those elements into the value for S1. (Although we have to be careful in this process to properly handle [higher-ranked From 8858bdf8d2cd0fb21e3a2ba42744871ba487e22f Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:49 -0400 Subject: [PATCH 0595/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: lqd --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 87a72eb1d..95266a486 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -203,7 +203,7 @@ Values(S1) = In the code, this work starts in the [`propagate_constraints`] function, which iterates over all the SCCs. For each SCC `S1`, we compute its value by first computing the value of its -successors. Since SCCs form a DAG, we don't have to be conecrned about +successors. Since SCCs form a DAG, we don't have to be concerned about cycles, though we do need to keep a set around to track whether we have already processed a given SCC or not. For each successor `S2`, once we have computed S2's value, we can union those elements into the From d4f8036b393c7d67c814bc0ebfef9cd1a7c17e75 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:33:57 -0400 Subject: [PATCH 0596/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: lqd --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 95266a486..3ec374b66 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -206,7 +206,7 @@ compute its value by first computing the value of its successors. Since SCCs form a DAG, we don't have to be concerned about cycles, though we do need to keep a set around to track whether we have already processed a given SCC or not. For each successor `S2`, once -we have computed S2's value, we can union those elements into the +we have computed `S2`'s value, we can union those elements into the value for S1. (Although we have to be careful in this process to properly handle [higher-ranked placeholders](./placeholders_and_universes.html). Note that the value From a90e3417f73e9ef1cf5b12b627e716c9edb14590 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:05 -0400 Subject: [PATCH 0597/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: lqd --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 3ec374b66..19af52ec4 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -207,7 +207,7 @@ successors. Since SCCs form a DAG, we don't have to be concerned about cycles, though we do need to keep a set around to track whether we have already processed a given SCC or not. For each successor `S2`, once we have computed `S2`'s value, we can union those elements into the -value for S1. (Although we have to be careful in this process to +value for `S1`. (Although we have to be careful in this process to properly handle [higher-ranked placeholders](./placeholders_and_universes.html). Note that the value for S1 already contains the liveness constraints, since they were From f540a0ba419131512858d0d05595030738c7c97c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:15 -0400 Subject: [PATCH 0598/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: lqd --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 19af52ec4..06cee8ad8 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -213,7 +213,7 @@ placeholders](./placeholders_and_universes.html). Note that the value for S1 already contains the liveness constraints, since they were added in [`RegionInferenceContext::new`]. -Once that process is done, we now have the "minimal value" for S1, +Once that process is done, we now have the "minimal value" for `S1`, taking into account all of the liveness and outlives constraints. However, in order to complete the process, we must also consider [member constraints][m_c], which are described in [a later From ae217e5775f924bd790066f7ced935f0cb1ec2c1 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:22 -0400 Subject: [PATCH 0599/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: lqd --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 06cee8ad8..e86d850fa 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -210,7 +210,7 @@ we have computed `S2`'s value, we can union those elements into the value for `S1`. (Although we have to be careful in this process to properly handle [higher-ranked placeholders](./placeholders_and_universes.html). Note that the value -for S1 already contains the liveness constraints, since they were +for `S1` already contains the liveness constraints, since they were added in [`RegionInferenceContext::new`]. Once that process is done, we now have the "minimal value" for `S1`, From b71caff4420e99affa4769fdee53b032cf739ec5 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:32 -0400 Subject: [PATCH 0600/1812] Update src/borrow_check/region_inference/member_constraints.md Co-Authored-By: lqd --- src/borrow_check/region_inference/member_constraints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 4d7312644..5e62d5125 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -3,7 +3,7 @@ A member constraint `'m member of ['c_1..'c_N]` expresses that the region `'m` must be *equal* to some **choice regions** `'c_i` (for some `i`). These constraints cannot be expressed by users, but they -arise from `impl Trait` due to its lifetime capture rules. Consinder a +arise from `impl Trait` due to its lifetime capture rules. Consider a function such as the following: ```rust From 32b57634c3d41821eb6e2a7d09c566cad60d91a4 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:34:40 -0400 Subject: [PATCH 0601/1812] Update src/borrow_check/region_inference/lifetime_parameters.md Co-Authored-By: lqd --- src/borrow_check/region_inference/lifetime_parameters.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index aa36d7dbb..ecd3a19a5 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -64,7 +64,7 @@ As noted previously, the value that we infer for each region is a set `{E}`. The elements of this set can be points in the control-flow graph, but they can also be an element `end('a)` corresponding to each universal lifetime `'a`. If the value for some region `R0` includes -`end('a`), then this implies that R0 must extend until the end of `'a` +`end('a`), then this implies that `R0` must extend until the end of `'a` in the caller. ## The "value" of a universal region From 8c78b7dd810b249457a5c7f272fbe8dc49ce7fba Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:04 -0400 Subject: [PATCH 0602/1812] Update src/borrow_check/region_inference/member_constraints.md Co-Authored-By: lqd --- src/borrow_check/region_inference/member_constraints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 5e62d5125..1d5fb1013 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -11,7 +11,7 @@ fn make(a: &'a u32, b: &'b u32) -> impl Trait<'a, 'b> { .. } ``` Here, the true return type (often called the "hidden type") is only -permitted to capture the lifeimes `'a` or `'b`. You can kind of see +permitted to capture the lifetimes `'a` or `'b`. You can kind of see this more clearly by desugaring that `impl Trait` return type into its more explicit form: From 16e49002c793e8fd18359b7e6eb169c0b0650af5 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:17 -0400 Subject: [PATCH 0603/1812] Update src/borrow_check/region_inference/member_constraints.md Co-Authored-By: lqd --- src/borrow_check/region_inference/member_constraints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 1d5fb1013..219296d0d 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -124,7 +124,7 @@ bounds considering everything but member constraints). Let `LB` be the current value of `'0`. We know then that `'0: LB` must hold, whatever the final value of `'0` is. Therefore, we can rule out -any choice where `'choice` where `'choice: LB` does not hold. +any choice `'choice` where `'choice: LB` does not hold. Unfortunately, in our example, this is not very helpful. The lower bound for `'0` will just be the liveness set `{L}`, and we know that From 1a66e0c6a9266669c5e7779d99f58eda514eb99a Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:37 -0400 Subject: [PATCH 0604/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: Who? Me?! --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index e86d850fa..c655df959 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -35,7 +35,7 @@ As a simple example, if we have a liveness constraint `R live at E`, then we can apply `Values(R) = Values(R) union {E}` to make the constraint be satisfied. Similarly, if we have an outlives constraints `R1: R2`, we can apply `Values(R1) = Values(R1) union Values(R2)`. -(Member constraints are more complex and we discuss them below.) +(Member constraints are more complex and we discuss them [in this section][m_c].) In practice, however, we are a bit more clever. Instead of applying the constraints in a loop, we can analyze the constraints and figure From 47dc406417759577f50d4a0433a47e8b6b48d6e0 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:48 -0400 Subject: [PATCH 0605/1812] Update src/borrow_check/region_inference/member_constraints.md Co-Authored-By: lqd --- src/borrow_check/region_inference/member_constraints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 219296d0d..48b24d215 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -135,7 +135,7 @@ with different variance, lower bound constraints may be relevant.) ### Upper bounds The *upper bounds* are those lifetimes that *must outlive* `'0` -- -i.e., that `'0` must be *smaller* then. In our example, this would be +i.e., that `'0` must be *smaller* than. In our example, this would be `'a`, because we have the constraint that `'a: '0`. In more complex examples, the chain may be more indirect. From 986780beef728cfb060b55a31419f57d5d6b1b33 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:35:59 -0400 Subject: [PATCH 0606/1812] Update src/borrow_check/region_inference/constraint_propagation.md Co-Authored-By: Who? Me?! --- src/borrow_check/region_inference/constraint_propagation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index c655df959..54f2c4cfd 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -59,7 +59,7 @@ A liveness constraint `R live at E` is satisfied if `E` is a member of `Values(R)`. So to "apply" such a constraint to `Values`, we just have to compute `Values(R) = Values(R) union {E}`. -The liveness values are computed in the type-check and passes to the +The liveness values are computed in the type-check and passed to the region inference upon creation in the `liveness_constraints` argument. These are not represented as individual constraints like `R live at E` though; instead, we store a (sparse) bitset per region variable (of From 0c6f78907a1a2fe4b4e462ce098e0e30d2ed247c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:36:59 -0400 Subject: [PATCH 0607/1812] Update src/borrow_check/region_inference/member_constraints.md Co-Authored-By: Who? Me?! --- src/borrow_check/region_inference/member_constraints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 48b24d215..3f934e864 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -69,7 +69,7 @@ interesting to the point we are illustrating here). The `'a: '0` and `'b: '1` constraints arise from subtyping. When we construct the `(a, b)` value, it will be assigned type `(&'0 u32, &'1 -u32)` -- the region variables reflect that the lifetime of this +u32)` -- the region variables reflect that the lifetimes of these references could be made smaller. For this value to be created from `a` and `b`, however, we do require that: From edeb237444ad379c58c877fa1d97bc54213e0fac Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:37:12 -0400 Subject: [PATCH 0608/1812] Update src/borrow_check/region_inference/placeholders_and_universes.md Co-Authored-By: Who? Me?! --- src/borrow_check/region_inference/placeholders_and_universes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index 0d4068e00..cc262ad3e 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -66,7 +66,7 @@ outlives `'static`. Now, this *might* be true – after all, `'!1` could be `'static` – but we don't *know* that it's true. So this should yield up an error (eventually). -## What is a universe +## What is a universe? In the previous section, we introduced the idea of a placeholder region, and we denoted it `!1`. We call this number `1` the **universe From 5bfca5a8711fa442487d7118e17444e3dfcac180 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:37:22 -0400 Subject: [PATCH 0609/1812] Update src/borrow_check/region_inference/placeholders_and_universes.md Co-Authored-By: Who? Me?! --- src/borrow_check/region_inference/placeholders_and_universes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index cc262ad3e..57fae404b 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -37,7 +37,7 @@ the type of `foo` the type `bar` expects We handle this sort of subtyping by taking the variables that are bound in the supertype and replacing them with [universally quantified](../appendix/background.html#quantified) -representatives, written like `!1`. We call these regions "placeholder +representatives, denoted like `!1` here. We call these regions "placeholder regions" – they represent, basically, "some unknown region". Once we've done that replacement, we have the following relation: From 364f0e4f8ad1a9d4e810be45683db3d8c4eefc03 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:37:30 -0400 Subject: [PATCH 0610/1812] Update src/borrow_check/region_inference/placeholders_and_universes.md Co-Authored-By: Who? Me?! --- src/borrow_check/region_inference/placeholders_and_universes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index 57fae404b..604c793d5 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -145,7 +145,7 @@ notion of universes, we can use it to extend our type-checker and things to prevent illegal names from leaking out. The idea is that we give each inference (existential) variable – whether it be a type or a lifetime – a universe. That variable's value can then only -reference names visible from that universe. So for example is a +reference names visible from that universe. So for example if a lifetime variable is created in U0, then it cannot be assigned a value of `!1` or `!2`, because those names are not visible from the universe U0. From a8de9a1a49d90c2616f72276d37e0c8a004a48ba Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:41:25 -0400 Subject: [PATCH 0611/1812] fix indentation --- .../region_inference/placeholders_and_universes.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index 604c793d5..e40ee11b1 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -271,9 +271,9 @@ The region inference engine will create a region element domain like this: ```text { CFG; end('static); placeholder(1) } - --- ------------ ------- from the universe `!1` - | 'static is always in scope - all points in the CFG; not especially relevant here + --- ------------ ------- from the universe `!1` + | 'static is always in scope + all points in the CFG; not especially relevant here ``` It will always create two universal variables, one representing From ed9535686880eb1ce470d2fe4ae27b93f3bd59d6 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 24 Jun 2019 14:44:13 -0400 Subject: [PATCH 0612/1812] add `point` to the glossary and link a use of it --- src/appendix/glossary.md | 1 + src/borrow_check/region_inference/constraint_propagation.md | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 3d77def91..007b1bb4c 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -50,6 +50,7 @@ newtype | a "newtype" is a wrapper around some other type (e.g. NLL | [non-lexical lifetimes](../borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. obligation | something that must be proven by the trait system ([see more](../traits/resolution.html)) +point | used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref) promoted constants | constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. provider | the function that executes a query ([see more](../query.html)) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 54f2c4cfd..7b9eeb13d 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -51,10 +51,12 @@ in the section on outlives constraints. ## Liveness constraints A **liveness constraint** arises when some variable whose type -includes a region R is live at some point P. This simply means that +includes a region R is live at some [point] P. This simply means that the value of R must include the point P. Liveness constraints are computed by the MIR type checker. +[point]: ../../appendix/glossary.html + A liveness constraint `R live at E` is satisfied if `E` is a member of `Values(R)`. So to "apply" such a constraint to `Values`, we just have to compute `Values(R) = Values(R) union {E}`. From abf512fc9cc969dcbea69aa15b44586bbeb13c2d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 11:03:43 -0500 Subject: [PATCH 0613/1812] fix long line --- src/SUMMARY.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 69e46b796..8c8890b79 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -79,7 +79,7 @@ - [Constraint propagation](./borrow_check/region_inference/constraint_propagation.md) - [Lifetime parameters](./borrow_check/region_inference/lifetime_parameters.md) - [Member constraints](./borrow_check/region_inference/member_constraints.md) - - [Placeholders and universes](./borrow_check/region_inference/placeholders_and_universes.md) + - [Placeholders and universes][pau] - [Closure constraints](./borrow_check/region_inference/closure_constraints.md) - [Errror reporting](./borrow_check/region_inference/error_reporting.md) - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) @@ -100,3 +100,5 @@ [Appendix D: Code Index](./appendix/code-index.md) [Appendix E: Bibliography](./appendix/bibliography.md) [](./important-links.md) + +[pau]: ./borrow_check/region_inference/placeholders_and_universes.md From 87e355245c6b4d0e8b2877acf07627afc0d07493 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 14:26:14 -0500 Subject: [PATCH 0614/1812] fix links --- src/borrow_check/region_inference/constraint_propagation.md | 6 +++--- .../region_inference/placeholders_and_universes.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 7b9eeb13d..daa52393a 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -11,7 +11,7 @@ on one at a time (each of them is fairly independent from the others): - [member constraints][m_c] (`member R_m of [R_c...]`), which arise from impl Trait. [`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints -[m_c]: ./member_constraints.html +[m_c]: ./member_constraints.md In this chapter, we'll explain the "heart" of constraint propagation, covering both liveness and outlives constraints. @@ -29,7 +29,7 @@ given some set of constraints `{C}` and it computes a set of values - For each constraint C: - Update `Values` as needed to satisfy the constraint -[riv]: ../region-inference.html#region-variables +[riv]: ../region_inference.md#region-variables As a simple example, if we have a liveness constraint `R live at E`, then we can apply `Values(R) = Values(R) union {E}` to make the @@ -55,7 +55,7 @@ includes a region R is live at some [point] P. This simply means that the value of R must include the point P. Liveness constraints are computed by the MIR type checker. -[point]: ../../appendix/glossary.html +[point]: ../../appendix/glossary.md A liveness constraint `R live at E` is satisfied if `E` is a member of `Values(R)`. So to "apply" such a constraint to `Values`, we just have diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index e40ee11b1..eda8e6ff1 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -36,7 +36,7 @@ the type of `foo` the type `bar` expects We handle this sort of subtyping by taking the variables that are bound in the supertype and replacing them with -[universally quantified](../appendix/background.html#quantified) +[universally quantified](../../appendix/background.md#quantified) representatives, denoted like `!1` here. We call these regions "placeholder regions" – they represent, basically, "some unknown region". @@ -53,7 +53,7 @@ what we wanted. So let's work through what happens next. To check if two functions are subtypes, we check if their arguments have the desired relationship -(fn arguments are [contravariant](../appendix/background.html#variance), so +(fn arguments are [contravariant](../../appendix/background.md#variance), so we swap the left and right here): ```text @@ -92,7 +92,7 @@ Here, the root universe would consist of the lifetimes `'static` and the same concept to types, in which case the types `Foo` and `T` would be in the root universe (along with other global types, like `i32`). Basically, the root universe contains all the names that -[appear free](../appendix/background.html#free-vs-bound) in the body of `bar`. +[appear free](../../appendix/background.md#free-vs-bound) in the body of `bar`. Now let's extend `bar` a bit by adding a variable `x`: From c6d994370b604a0b0aa01a83d4ee7a49ac3e7cb4 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 14:34:56 -0500 Subject: [PATCH 0615/1812] fix mdbook test --- .../region_inference/constraint_propagation.md | 10 +++++----- .../region_inference/lifetime_parameters.md | 6 +++--- .../region_inference/member_constraints.md | 12 ++++++------ 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index daa52393a..a8e44629e 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -88,7 +88,7 @@ have to compute `Values(R1) = Values(R1) union Values(R2)`. One observation that follows from this is that if you have `R1: R2` and `R2: R1`, then `R1 = R2` must be true. Similarly, if you have: -``` +```txt R1: R2 R2: R3 R3: R4 @@ -119,7 +119,7 @@ context. When using a graph representation, we can detect regions that must be equal by looking for cycles. That is, if you have a constraint like -``` +```txt 'a: 'b 'b: 'c 'c: 'd @@ -153,7 +153,7 @@ When we compute SCCs, we not only figure out which regions are a member of each SCC, we also figure out the edges between them. So for example consider this set of outlives constraints: -``` +```txt 'a: 'b 'b: 'a @@ -178,7 +178,7 @@ expressed in terms of regions -- that is, we have a map like in terms of SCCs -- we can integrate these liveness constraints very easily just by taking the union: -``` +```txt for each region R: let S be the SCC that contains R Values(S) = Values(S) union Liveness(R) @@ -195,7 +195,7 @@ the value of `S1`, we first compute the values of each successor `S2`. Then we simply union all of those values together. To use a quasi-iterator-like notation: -``` +```txt Values(S1) = s1.successors() .map(|s2| Values(s2)) diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index ecd3a19a5..87e9d53ed 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -7,7 +7,7 @@ derives from the fact that such lifetimes are "universally quantified" lifetimes). It is worth spending a bit of discussing how lifetime parameters are handled during region inference. Consider this example: -```rust +```rust,ignore fn foo<'a, 'b>(x: &'a u32, y: &'b u32) -> &'b u32 { x } @@ -92,7 +92,7 @@ itself). In the code, these liveness constraints are setup in So, consider the first example of this section: -```rust +```rust,ignore fn foo<'a, 'b>(x: &'a u32, y: &'b u32) -> &'b u32 { x } @@ -102,7 +102,7 @@ Here, returning `x` requires that `&'a u32 <: &'b u32`, which gives rise to an outlives constraint `'a: 'b`. Combined with our default liveness constraints we get: -``` +```txt 'a live at {B, end('a)} // B represents the "function body" 'b live at {B, end('b)} 'a: 'b diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 3f934e864..d69c95511 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -6,7 +6,7 @@ some `i`). These constraints cannot be expressed by users, but they arise from `impl Trait` due to its lifetime capture rules. Consider a function such as the following: -```rust +```rust,ignore fn make(a: &'a u32, b: &'b u32) -> impl Trait<'a, 'b> { .. } ``` @@ -15,7 +15,7 @@ permitted to capture the lifetimes `'a` or `'b`. You can kind of see this more clearly by desugaring that `impl Trait` return type into its more explicit form: -```rust +```rust,ignore type MakeReturn<'x, 'y> = impl Trait<'x, 'y>; fn make(a: &'a u32, b: &'b u32) -> MakeReturn<'a, 'b> { .. } ``` @@ -34,14 +34,14 @@ To help us explain member constraints in more detail, let's spell out the `make` example in a bit more detail. First off, let's assume that you have some dummy trait: -```rust +```rust,ignore trait Trait<'a, 'b> { } impl Trait<'_, '_> for T { } ``` and this is the `make` function (in desugared form): -```rust +```rust,ignore type MakeReturn<'x, 'y> = impl Trait<'x, 'y>; fn make(a: &'a u32, b: &'b u32) -> MakeReturn<'a, 'b> { (a, b) @@ -52,7 +52,7 @@ What happens in this case is that the return type will be `(&'0 u32, &'1 u32)`, where `'0` and `'1` are fresh region variables. We will have the following region constraints: -``` +```txt '0 live at {L} '1 live at {L} 'a: '0 @@ -73,7 +73,7 @@ u32)` -- the region variables reflect that the lifetimes of these references could be made smaller. For this value to be created from `a` and `b`, however, we do require that: -``` +```txt (&'a u32, &'b u32) <: (&'0 u32, &'1 u32) ``` From 7f47c496c272a00c76a733bbf71c89e606210605 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 27 Jun 2019 05:45:00 +0900 Subject: [PATCH 0616/1812] Fix typo --- src/mir/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/index.md b/src/mir/index.md index baaf23c36..9e9f933fe 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -138,7 +138,7 @@ than one successor – that is, control may flow to different places. Function calls like the call to `Vec::new` are always terminators because of the possibility of unwinding, although in the case of `Vec::new` we are able to see that indeed unwinding is not -possible, and hence we list only one succssor block, `bb2`. +possible, and hence we list only one successor block, `bb2`. If we look ahead to `bb2`, we will see it looks like this: From 92f3f8e3b8c0a2dd29cc4603b9cc7591bf6edfb4 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 4 Jul 2019 20:39:45 +0900 Subject: [PATCH 0617/1812] Update pass modes for ui tests (#380) --- src/tests/adding.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 5b8674814..d88b7cf57 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -171,8 +171,8 @@ source. argument is the first version to ignore. If no second argument is given, all subsequent versions are ignored; otherwise, the second argument is the last version to ignore. -* `compile-pass` for UI tests, indicates that the test is - supposed to compile, as opposed to the default where the test is +* `build-pass` for UI tests, indicates that the test is supposed to + successfully compile and link, as opposed to the default where the test is supposed to error out. * `compile-flags` passes extra command-line args to the compiler, e.g. `compile-flags -g` which forces debuginfo to be enabled. @@ -279,7 +279,9 @@ can also make UI tests where compilation is expected to succeed, and you can even run the resulting program. Just add one of the following [header commands](#header_commands): -- `// compile-pass` – compilation should succeed but do +- `// check-pass` - compilation should succeed but skip codegen + (which is expensive and isn't supposed to fail in most cases) +- `// build-pass` – compilation and linking should succeed but do not run the resulting binary - `// run-pass` – compilation should succeed and we should run the resulting binary From b5a2b9353c661000378415ecfeb757eb7df42d66 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 4 Jul 2019 20:41:50 +0900 Subject: [PATCH 0618/1812] Fix broken links (#382) --- src/borrow_check/region_inference/constraint_propagation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index a8e44629e..7ec46b90f 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -112,8 +112,8 @@ induces an edge `'a -> 'b`. This conversion happens in the [`RegionInferenceContext::new`] function that creates the inference context. -[`ConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.ConstraintSet.html -[graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.ConstraintSet.html#method.graph +[`ConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.OutlivesConstraintSet.html +[graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.OutlivesConstraintSet.html#method.graph [`RegionInferenceContext::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.new When using a graph representation, we can detect regions that must be equal From 4936b7cbd53b477a3389c5bb655e92c5f3a2ff0c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 26 Jun 2019 10:58:05 -0500 Subject: [PATCH 0619/1812] add humor appendix; closes #163 --- src/SUMMARY.md | 5 +++++ src/appendix/humorust.md | 10 ++++++++++ 2 files changed, 15 insertions(+) create mode 100644 src/appendix/humorust.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 8c8890b79..e321f6633 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -99,6 +99,11 @@ [Appendix C: Glossary](./appendix/glossary.md) [Appendix D: Code Index](./appendix/code-index.md) [Appendix E: Bibliography](./appendix/bibliography.md) + +[Appendix Z HumorRust](./appendix/humorust.md) + +--- + [](./important-links.md) [pau]: ./borrow_check/region_inference/placeholders_and_universes.md diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md new file mode 100644 index 000000000..e217ab65f --- /dev/null +++ b/src/appendix/humorust.md @@ -0,0 +1,10 @@ +# Humor in Rust + +What's a project without a sense of humor? And frankly some of these are +enlightening? + +- [Weird exprs test](https://github.com/rust-lang/rust/blob/master/src/test/run-pass/weird-exprs.rs) +- [Ferris Rap](http://fitzgeraldnick.com/2018/12/13/rust-raps.html) +- [The Genesis of Generic Germination](https://github.com/rust-lang/rust/pull/53645#issue-210543221) +- [The Bastion of the Turbofish test](https://github.com/rust-lang/rust/blob/79d8a0fcefa5134db2a94739b1d18daa01fc6e9f/src/test/ui/bastion-of-the-turbofish.rs) +- [Rust Koans](https://users.rust-lang.org/t/rust-koans/2408/4) From 06837ee64b2d4b9e08e1303b22f9aba7a9ff59cd Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 17 Jul 2019 22:02:05 +0900 Subject: [PATCH 0620/1812] Update experts' link --- src/compiler-team.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index 968e2f142..f01b4a8d5 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -18,10 +18,12 @@ Currently the compiler team chats in 2 places: If you're interested in figuring out who can answer questions about a particular part of the compiler, or you'd just like to know who works on what, -check out our [experts directory](https://github.com/rust-lang/compiler-team/blob/master/experts/MAP.md). +check out our [experts directory][experts]. It contains a listing of the various parts of the compiler and a list of people who are experts on each one. +[experts]: https://github.com/rust-lang/compiler-team/blob/master/content/docs/experts/map.toml + ## Rust compiler meeting The compiler team has a weekly meeting where we do triage and try to From 596e952f649e0aa8ef1f393d85b0df4bda4df4fe Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 17 Jul 2019 10:10:43 -0500 Subject: [PATCH 0621/1812] blacklist some commonly problematic links --- book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book.toml b/book.toml index b9092a969..856ef2eba 100644 --- a/book.toml +++ b/book.toml @@ -9,4 +9,4 @@ description = "A guide to developing rustc" [output.linkcheck] follow-web-links = true -exclude = [ "crates\\.io", "gcc\\.godbolt\\.org" ] +exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "dl\\.acm\\.org" ] From fc18a79ef688ee47ece5c736218d92537cf3bf63 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Jul 2019 11:44:03 +0900 Subject: [PATCH 0622/1812] Document `--pass $mode` --- src/tests/running.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/tests/running.md b/src/tests/running.md index 5a05c156f..01d308f0b 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -108,6 +108,23 @@ Under the hood, the test runner invokes the standard rust test runner filtering for tests that include "issue-1234" in the name. (Thus `--test-args` is a good way to run a collection of related tests.) +## Passing `--pass $mode` + +Pass UI tests now have three modes, `check-pass`, `build-pass` and +`run-pass`. When `--pass $mode` is passed, these tests will be forced +to run under the given `$mode` unless the directive `// ignore-pass` +exists in the test file. For example, you can run all the tests in +`src/test/run-pass` as `check-pass`: + +```bash +> ./x.py test --stage 1 src/test/run-pass --pass check +``` + +By passing `--pass $mode`, you can reduce the testing time. For each +mode, please see [here][mode]. + +[mode]: https://rust-lang.github.io/rustc-guide/tests/adding.html#tests-that-do-not-result-in-compile-errors + ## Using incremental compilation You can further enable the `--incremental` flag to save additional From 1774649715ec84b80d8c887d913c91b83be56197 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Jul 2019 11:02:45 +0900 Subject: [PATCH 0623/1812] Minor fix in borrow_check Fixes as follows: - fixes spelling - removes unnecessary white spaces and blank lines --- src/borrow_check/moves_and_initialization/move_paths.md | 5 ++--- src/borrow_check/region_inference.md | 1 - src/borrow_check/region_inference/constraint_propagation.md | 4 +--- src/borrow_check/region_inference/lifetime_parameters.md | 2 +- src/borrow_check/region_inference/member_constraints.md | 5 ++--- 5 files changed, 6 insertions(+), 11 deletions(-) diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index 4d4db4116..d733e8ac7 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -12,7 +12,7 @@ fn foo() { let b = a.0; // moves a.0 - // a.0 is not initializd, but a.1 still is + // a.0 is not initialized, but a.1 still is let c = a.0; // ERROR let d = a.1; // OK @@ -84,7 +84,7 @@ initialized (which lowers overhead). ## Looking up a move-path -If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], you +If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], you can do that using the [`MovePathLookup`] structure found in the [`rev_lookup`] field of [`MoveData`]. There are two different methods: @@ -124,4 +124,3 @@ given move-path (e.g., `a.b`) or any child of that move-path (e.g., [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.Place.html [`has_any_child_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/at_location/struct.FlowAtLocation.html#method.has_any_child_of - diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 46caab567..52659e93c 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -236,4 +236,3 @@ tests and universal regions, as discussed above. [`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints [`check_type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_type_tests [`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions - diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 7ec46b90f..5f3b29c6d 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -137,7 +137,7 @@ by invoking `constraint_sccs.scc(r)`. Working in terms of SCCs allows us to be more efficient: if we have a set of regions `'a...'d` that are part of a single SCC, we don't have -to compute/store their values separarely. We can just store one value +to compute/store their values separately. We can just store one value **for the SCC**, since they must all be equal. If you look over the region inference code, you will see that a number @@ -220,5 +220,3 @@ taking into account all of the liveness and outlives constraints. However, in order to complete the process, we must also consider [member constraints][m_c], which are described in [a later section][m_c]. - - diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index 87e9d53ed..0d5219aa9 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -52,7 +52,7 @@ based on their index: In fact, the universal regions can be further subdivided based on where they were brought into scope (see the [`RegionClassification`] -type). These subdivions are not important for the topics discussed +type). These subdivisions are not important for the topics discussed here, but become important when we consider [closure constraint propagation](./closure_constraints.html), so we discuss them there. diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index d69c95511..7e254f0a2 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -176,11 +176,11 @@ region being inferred. However, it is somewhat arbitrary. In practice, computing upper bounds is a bit inconvenient, because our data structures are setup for the opposite. What we do is to compute -the **reverse SCC graph** (we do this lazilly and cache the result) -- +the **reverse SCC graph** (we do this lazily and cache the result) -- that is, a graph where `'a: 'b` induces an edge `SCC('b) -> SCC('a)`. Like the normal SCC graph, this is a DAG. We can then do a depth-first search starting from `SCC('0)` in this graph. This will -take us to all the SCCs that must outlive `'0`. +take us to all the SCCs that must outlive `'0`. One wrinkle is that, as we walk the "upper bound" SCCs, their values will not yet have been fully computed. However, we **have** already @@ -190,4 +190,3 @@ parameters, their value will contain themselves (i.e., the initial value for `'a` includes `'a` and the value for `'b` contains `'b`). So we can collect all of the lifetime parameters that are reachable, which is precisely what we are interested in. - From fb3bf19590bf7dd24af507180bca6f5bf0c27d80 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Jul 2019 11:58:41 +0900 Subject: [PATCH 0624/1812] Move into rust-lang --- README.md | 2 +- src/traits/index.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index e6230439e..064f80c6e 100644 --- a/README.md +++ b/README.md @@ -3,7 +3,7 @@ works. The aim of the guide is to help new contributors get oriented to rustc, as well as to help more experienced folks in figuring out some new part of the compiler that they haven't worked on before. -[You can read the latest version of the guide here.](https://rust-lang-nursery.github.io/rustc-guide/) +[You can read the latest version of the guide here.](https://rust-lang.github.io/rustc-guide/) You may also find the rustdocs [for the compiler itself][rustdocs] useful. diff --git a/src/traits/index.md b/src/traits/index.md index 84f812394..5544ce513 100644 --- a/src/traits/index.md +++ b/src/traits/index.md @@ -59,6 +59,6 @@ and designs for the trait system. It primarily consists of two parts: implementing them in rustc. This mainly happens in [`librustc_traits`][librustc_traits]. -[chalk]: https://github.com/rust-lang-nursery/chalk -[chalk_engine]: https://github.com/rust-lang-nursery/chalk/tree/master/chalk-engine +[chalk]: https://github.com/rust-lang/chalk +[chalk_engine]: https://github.com/rust-lang/chalk/tree/master/chalk-engine [librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits From 7b106f95466f1040e0c8b4af512ace2d9f2cd7b4 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Jul 2019 12:00:12 +0900 Subject: [PATCH 0625/1812] Add colon --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index e321f6633..60aa8766d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -100,7 +100,7 @@ [Appendix D: Code Index](./appendix/code-index.md) [Appendix E: Bibliography](./appendix/bibliography.md) -[Appendix Z HumorRust](./appendix/humorust.md) +[Appendix Z: HumorRust](./appendix/humorust.md) --- From ef9bc9d610cad6dbe903a23bccf0447dd2a411c5 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 17 Jul 2019 12:01:32 -0500 Subject: [PATCH 0626/1812] break rust --- src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index e217ab65f..f044a50c0 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -8,3 +8,4 @@ enlightening? - [The Genesis of Generic Germination](https://github.com/rust-lang/rust/pull/53645#issue-210543221) - [The Bastion of the Turbofish test](https://github.com/rust-lang/rust/blob/79d8a0fcefa5134db2a94739b1d18daa01fc6e9f/src/test/ui/bastion-of-the-turbofish.rs) - [Rust Koans](https://users.rust-lang.org/t/rust-koans/2408/4) +- [`break rust;`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0ab2bd6a9d722e0f05a95e2a5dcf89cc) From 248d8af35e9423b92760d7fc2603d4df8a78345c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 17 Jul 2019 12:04:18 -0500 Subject: [PATCH 0627/1812] add nomicon intro too --- src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index f044a50c0..36c25c890 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -9,3 +9,4 @@ enlightening? - [The Bastion of the Turbofish test](https://github.com/rust-lang/rust/blob/79d8a0fcefa5134db2a94739b1d18daa01fc6e9f/src/test/ui/bastion-of-the-turbofish.rs) - [Rust Koans](https://users.rust-lang.org/t/rust-koans/2408/4) - [`break rust;`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0ab2bd6a9d722e0f05a95e2a5dcf89cc) +- [The Nomicon Intro](https://doc.rust-lang.org/stable/nomicon/) From 382f1c4867da6791a0b1cb28bbc54b3d22cf56cd Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 19 Jul 2019 11:09:23 -0500 Subject: [PATCH 0628/1812] Update mdbook --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index 7c730cae3..be64d1ee8 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -21,4 +21,4 @@ function cargo_install() { } cargo_install mdbook 0.3.0 -cargo_install mdbook-linkcheck 0.3.0 +cargo_install mdbook-linkcheck 0.3.1 From 7f7d1d8eaebeed349a8796441897271c84fa4b90 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 19 Jul 2019 11:23:56 -0500 Subject: [PATCH 0629/1812] Update install.sh --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index be64d1ee8..48df957f9 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -20,5 +20,5 @@ function cargo_install() { fi } -cargo_install mdbook 0.3.0 +cargo_install mdbook 0.3.1 cargo_install mdbook-linkcheck 0.3.1 From c20647e97819a8000129b9ef395658493d74278c Mon Sep 17 00:00:00 2001 From: Ilija Tovilo Date: Sat, 20 Jul 2019 20:12:03 +0200 Subject: [PATCH 0630/1812] Fix typo --- src/queries/query-evaluation-model-in-detail.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 7772f36be..a1fbed2e5 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -73,7 +73,7 @@ not memoize the result. When the query context is created, it is still empty: No queries have been executed, no results are cached. But the context already provides access to -"input" data, i.e. pieces of immutable data that where computed before the +"input" data, i.e. pieces of immutable data that were computed before the context was created and that queries can access to do their computations. Currently this input data consists mainly of the HIR map and the command-line options the compiler was invoked with. In the future, inputs will just consist From 18c466252e3b321ca5bc35ff92440e65c476e12b Mon Sep 17 00:00:00 2001 From: Ilija Tovilo Date: Sun, 21 Jul 2019 23:47:05 +0200 Subject: [PATCH 0631/1812] Fix typo --- src/closure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/closure.md b/src/closure.md index 77f2b42c3..e73f2e168 100644 --- a/src/closure.md +++ b/src/closure.md @@ -140,7 +140,7 @@ declared in the file [`src/librustc/ty/mod.rs`][ty]. [upvar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/upvar/index.html [ty]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/index.html -Before we go any further, let's discuss how we can examine the flow of coontrol through the rustc +Before we go any further, let's discuss how we can examine the flow of control through the rustc codebase. For closures specifically, set the `RUST_LOG` env variable as below and collect the output in a file: From 831a469050c23aaa1e578db5356dd46063f04f11 Mon Sep 17 00:00:00 2001 From: Ilija Tovilo Date: Sun, 21 Jul 2019 12:37:42 +0200 Subject: [PATCH 0632/1812] Fix macro syntax error --- src/macro-expansion.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index c62301247..bb429282f 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -19,11 +19,11 @@ whenever we refer to the "example _definition_", we mean the following: macro_rules! printer { (print $mvar:ident) => { println!("{}", $mvar); - } + }; (print twice $mvar:ident) => { println!("{}", $mvar); println!("{}", $mvar); - } + }; } ``` From d8af1f7fff3881eef5b2e4e29995073a85b67b5d Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Sun, 21 Jul 2019 14:33:57 +0300 Subject: [PATCH 0633/1812] write a short paragraph about the new lexer --- src/the-parser.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/the-parser.md b/src/the-parser.md index ac902d915..5796ae40e 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -32,6 +32,19 @@ To minimise the amount of copying that is done, both the `StringReader` and `Parser` have lifetimes which bind them to the parent `ParseSess`. This contains all the information needed while parsing, as well as the `SourceMap` itself. +## More on Lexical Analysis + +Code for lexical analysis is split between two crates: + +- `rustc_lexer` crate is responsible for breaking a `&str` into chunks + constituting tokens. Although it is popular to implement lexers as generated + finite state machines, the lexer in `rustc_lexer` is hand-written. + +- [`StringReader`] from [libsyntax] integrates `rustc_lexer` with `rustc` + specific data structures. Specifically, it adds `Span` information to tokens + returned by `rustc_lexer` and interns identifiers. + + [libsyntax]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/index.html [rustc_errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree From 093e1f0169855043f3cf2bc45dfba066dd9e0ffe Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 24 Jul 2019 18:03:40 -0300 Subject: [PATCH 0634/1812] Place is now a struct on nightly --- src/borrow_check/moves_and_initialization/move_paths.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index d733e8ac7..157a9eaf3 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -28,7 +28,7 @@ they are indexed in ways that enable us to do move analysis more efficiently. [`MovePath`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePath.html -[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.Place.html +[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Place.html ## Move path indices @@ -122,5 +122,5 @@ which checks whether the dataflow results contain a value for the given move-path (e.g., `a.b`) or any child of that move-path (e.g., `a.b.c`). -[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.Place.html +[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Place.html [`has_any_child_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/at_location/struct.FlowAtLocation.html#method.has_any_child_of From b4b7dca0d244f4496256d13566d972dd69e92e5f Mon Sep 17 00:00:00 2001 From: Brian Foley Date: Thu, 25 Jul 2019 15:25:26 -0700 Subject: [PATCH 0635/1812] Fix miscellaneous spelling typos. (#397) --- src/SUMMARY.md | 2 +- src/appendix/glossary.md | 2 +- src/borrow_check/region_inference.md | 2 +- src/closure.md | 2 +- src/codegen/updating-llvm.md | 2 +- src/how-to-build-and-run.md | 4 ++-- src/kinds.md | 2 +- src/traits/goals-and-clauses.md | 2 +- src/traits/implied-bounds.md | 2 +- 9 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 60aa8766d..75e1fcdc2 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -81,7 +81,7 @@ - [Member constraints](./borrow_check/region_inference/member_constraints.md) - [Placeholders and universes][pau] - [Closure constraints](./borrow_check/region_inference/closure_constraints.md) - - [Errror reporting](./borrow_check/region_inference/error_reporting.md) + - [Error reporting](./borrow_check/region_inference/error_reporting.md) - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 007b1bb4c..3375d035f 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -8,7 +8,7 @@ Term | Meaning ------------------------|-------- AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) -bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expession \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) +bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen | the code to translate MIR into LLVM IR. codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 52659e93c..216128ffb 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -217,7 +217,7 @@ Here are some of the fields of the struct: - [`type_tests`]: contains some constraints on types that we must check after inference (e.g. `T: 'a`). - [`closure_bounds_mapping`]: used for propagating region constraints from - closures back out to the creater of the closure. + closures back out to the creator of the closure. [`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.constraints [`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints diff --git a/src/closure.md b/src/closure.md index e73f2e168..c47ad9bc8 100644 --- a/src/closure.md +++ b/src/closure.md @@ -121,7 +121,7 @@ the *free variables* meaning they are not bound to the context of the closure. Other than lazy invocation, one other thing that the distinguishes a closure from a normal function is that it can use the upvars. It borrows these upvars from its surrounding -context; therfore the compiler has to determine the upvar's borrow type. The compiler starts with +context; therefore the compiler has to determine the upvar's borrow type. The compiler starts with assigning an immutable borrow type and lowers the restriction (that is, changes it from **immutable** to **mutable** to **move**) as needed, based on the usage. In the Example 1 above, the closure only uses the variable for printing but does not modify it in any way and therefore, in the diff --git a/src/codegen/updating-llvm.md b/src/codegen/updating-llvm.md index b26c475f7..50dc94962 100644 --- a/src/codegen/updating-llvm.md +++ b/src/codegen/updating-llvm.md @@ -24,7 +24,7 @@ another: them upstream in LLVM. We'll want to pull fixes back to the compiler itself as they're merged upstream. -* Second, a new feature may be avaiable in LLVM that we want to use in rustc, +* Second, a new feature may be available in LLVM that we want to use in rustc, but we don't want to wait for a full LLVM release to test it out. Each of these reasons has a different strategy for updating LLVM, and we'll go diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 84efffc84..c3968b591 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -495,12 +495,12 @@ One of the challenges with rustc is that the RLS can't handle it, since it's a bootstrapping compiler. This makes code navigation difficult. One solution is to use `ctags`. -`ctags` has a long history and several variants. Exhuberant CTags seems to be +`ctags` has a long history and several variants. Exuberant Ctags seems to be quite commonly distributed but it does not have out-of-box Rust support. Some distributions seem to use [Universal Ctags][utags], which is a maintained fork and does have built-in Rust support. -The following script can be used to set up Exhuberant Ctags: +The following script can be used to set up Exuberant Ctags: [https://github.com/nikomatsakis/rust-etags][etags]. `ctags` integrates into emacs and vim quite easily. The following can then be diff --git a/src/kinds.md b/src/kinds.md index ac6a2d35b..e4ba72995 100644 --- a/src/kinds.md +++ b/src/kinds.md @@ -30,7 +30,7 @@ make use of the safe [`UnpackedKind`](#unpackedkind) abstraction. As `Kind` itself is not type-safe, the `UnpackedKind` enum provides a more convenient and safe interface for dealing with kinds. An `UnpackedKind` can be converted to a raw `Kind` using `Kind::from()` (or simply `.into()` when -the context is clear). As mentioned earlier, substition lists store raw +the context is clear). As mentioned earlier, substitution lists store raw `Kind`s, so before dealing with them, it is preferable to convert them to `UnpackedKind`s first. This is done by calling the `.unpack()` method. diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index 8f1ffa488..a653528f4 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -53,7 +53,7 @@ In terms of code, these types are defined in definitions given above, general goals basically consist in a combination of domain goals. -Moreover, flattenning a bit the definition of clauses given previously, one can +Moreover, flattening a bit the definition of clauses given previously, one can see that clauses are always of the form: ```text forall { DomainGoal :- Goal } diff --git a/src/traits/implied-bounds.md b/src/traits/implied-bounds.md index f32c9d0cb..5876f3b62 100644 --- a/src/traits/implied-bounds.md +++ b/src/traits/implied-bounds.md @@ -81,7 +81,7 @@ The rationale for implied bounds for traits is that if a type implements `Copy`, that is, if there exists an `impl Copy` for that type, there *ought* to exist an `impl Clone` for that type, otherwise the compiler would have reported an error in the first place. So again, if we were forced to repeat the -additionnal `where SomeType: Clone` everywhere whereas we already know that +additional `where SomeType: Clone` everywhere whereas we already know that `SomeType: Copy` hold, we would kind of duplicate the verification work. Implied bounds are not yet completely enforced in rustc, at the moment it only From 588af16689f4b54c0160b24ee31ebd6e94ed5267 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 1 Aug 2019 15:30:45 -0300 Subject: [PATCH 0636/1812] Fix experts map link --- src/compiler-team.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index f01b4a8d5..1dbeeb422 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -22,7 +22,7 @@ check out our [experts directory][experts]. It contains a listing of the various parts of the compiler and a list of people who are experts on each one. -[experts]: https://github.com/rust-lang/compiler-team/blob/master/content/docs/experts/map.toml +[experts]: https://github.com/rust-lang/compiler-team/blob/master/content/experts/map.toml ## Rust compiler meeting From 69c17d9a5edbfb2362bdc1ed1c9829f76a00097e Mon Sep 17 00:00:00 2001 From: Bruce Mitchener Date: Fri, 2 Aug 2019 01:47:43 +0700 Subject: [PATCH 0637/1812] Fix broken links. --- src/appendix/humorust.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index 36c25c890..ef926c1c6 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -3,7 +3,7 @@ What's a project without a sense of humor? And frankly some of these are enlightening? -- [Weird exprs test](https://github.com/rust-lang/rust/blob/master/src/test/run-pass/weird-exprs.rs) +- [Weird exprs test](https://github.com/rust-lang/rust/blob/master/src/test/ui/weird-exprs.rs) - [Ferris Rap](http://fitzgeraldnick.com/2018/12/13/rust-raps.html) - [The Genesis of Generic Germination](https://github.com/rust-lang/rust/pull/53645#issue-210543221) - [The Bastion of the Turbofish test](https://github.com/rust-lang/rust/blob/79d8a0fcefa5134db2a94739b1d18daa01fc6e9f/src/test/ui/bastion-of-the-turbofish.rs) From 442aed9afe80511685cab6259b5a7aad43f78a49 Mon Sep 17 00:00:00 2001 From: Bruce Mitchener Date: Fri, 2 Aug 2019 01:16:56 +0700 Subject: [PATCH 0638/1812] Fix typos. --- src/debugging-support-in-rustc.md | 2 +- src/kinds.md | 2 +- src/miri.md | 2 +- src/stabilization_guide.md | 6 +++--- src/ty.md | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/debugging-support-in-rustc.md b/src/debugging-support-in-rustc.md index 1775b07af..3d08cc825 100644 --- a/src/debugging-support-in-rustc.md +++ b/src/debugging-support-in-rustc.md @@ -1,7 +1,7 @@ # Debugging support in the Rust compiler This document explains the state of debugging tools support in the Rust compiler (rustc). -The document gives an overview of debugging tools like GDB, LLDB etc. and infrastrcture +The document gives an overview of debugging tools like GDB, LLDB etc. and infrastructure around Rust compiler to debug Rust code. If you want to learn how to debug the Rust compiler itself, then you must see [Debugging the Compiler] page. diff --git a/src/kinds.md b/src/kinds.md index e4ba72995..194d2ee2f 100644 --- a/src/kinds.md +++ b/src/kinds.md @@ -15,7 +15,7 @@ For example, given a `HashMap` with two type parameters, `K` and `V`, an instantiation of the parameters, for example `HashMap`, would be represented by the substitution `&'tcx [tcx.types.i32, tcx.types.u32]`. -`Subst` provides various convenience methods to instantiant substitutions +`Subst` provides various convenience methods to instantiate substitutions given item definitions, which should generally be used rather than explicitly constructing such substitution slices. diff --git a/src/miri.md b/src/miri.md index d361103f2..aee2376f1 100644 --- a/src/miri.md +++ b/src/miri.md @@ -131,7 +131,7 @@ evaluation of another constant simply calls `tcx.const_eval`, which produces an entirely new and independent stack frame. The frames are just a `Vec`, there's no way to actually refer to a -`Frame`'s memory even if horrible shenigans are done via unsafe code. The only +`Frame`'s memory even if horrible shenanigans are done via unsafe code. The only memory that can be referred to are `Allocation`s. Miri now calls the `step` method (in diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 76446150c..302be41d0 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -34,8 +34,8 @@ Places that may need updated documentation: to the language, updating examples is important. - [Rust by Example]: As needed. -Prepare PRs to update documentations invovling this new feature -for repositories mentioned above. Maintainers of these repositories +Prepare PRs to update documentation involving this new feature +for repositories mentioned above. Maintainers of these repositories will keep these PRs open until the whole stabilization process has completed. Meanwhile, we can proceed to the next step. @@ -44,7 +44,7 @@ has completed. Meanwhile, we can proceed to the next step. Find the tracking issue of the feature, and create a short stabilization report. Essentially this would be a brief summary of the feature plus some links to test cases showing it works -as expected, along with a list of edge cases that came up and +as expected, along with a list of edge cases that came up and were considered. This is a minimal "due diligence" that we do before stabilizing. diff --git a/src/ty.md b/src/ty.md index 72405d297..811f473c9 100644 --- a/src/ty.md +++ b/src/ty.md @@ -64,7 +64,7 @@ defining all of the different kinds of types in the compiler. > known later.). To allocate a new type, you can use the various `mk_` methods defined -on the `tcx`. These have names that correpond mostly to the various kinds +on the `tcx`. These have names that correspond mostly to the various kinds of type variants. For example: ```rust,ignore From bfe0a08ea4648a08cbc9cf61458d920c90826424 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 2 Aug 2019 04:25:07 +0200 Subject: [PATCH 0639/1812] run-pass dir is gone (#409) Fixes #405 --- src/compiletest.md | 4 ++-- src/how-to-build-and-run.md | 2 +- src/tests/adding.md | 15 ++++++--------- src/tests/running.md | 8 ++++---- 4 files changed, 13 insertions(+), 16 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index 3cfb943b0..1b424e1a2 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -16,8 +16,8 @@ expect, and more. If you are unfamiliar with the compiler testing framework, see [this chapter](./tests/intro.html) for additional background. The tests themselves are typically (but not always) organized into -"suites" – for example, `run-pass`, a folder representing tests that should -succeed, `run-fail`, a folder holding tests that should compile successfully, +"suites" – for example, `run-fail`, +a folder holding tests that should compile successfully, but return a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various suites are defined in [src/tools/compiletest/src/common.rs][common] in the `pub struct Config` diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index c3968b591..0a746177b 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -483,7 +483,7 @@ in other sections: - Running tests (see the [section on running tests](./tests/running.html) for more details): - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd - - `./x.py test --stage 1 src/test/run-pass` – runs the `run-pass` test suite + - `./x.py test --stage 1 src/test/ui` – runs the `ui` test suite - `./x.py test --stage 1 src/test/ui/const-generics` - runs all the tests in the `const-generics/` subdirectory of the `ui` test suite - `./x.py test --stage 1 src/test/ui/const-generics/const-types.rs` - runs diff --git a/src/tests/adding.md b/src/tests/adding.md index d88b7cf57..a660d26b5 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -43,14 +43,14 @@ rough heuristics: We have not traditionally had a lot of structure in the names of tests. Moreover, for a long time, the rustc test runner did not support subdirectories (it now does), so test suites like -[`src/test/run-pass`] have a huge mess of files in them. This is not +[`src/test/ui`] have a huge mess of files in them. This is not considered an ideal setup. -[`src/test/run-pass`]: https://github.com/rust-lang/rust/tree/master/src/test/run-pass/ +[`src/test/ui`]: https://github.com/rust-lang/rust/tree/master/src/test/ui/ For regression tests – basically, some random snippet of code that came in from the internet – we often just name the test after the -issue. For example, `src/test/run-pass/issue-12345.rs`. If possible, +issue. For example, `src/test/ui/issue-12345.rs`. If possible, though, it is better if you can put the test into a directory that helps identify what piece of code is being tested here (e.g., `borrowck/issue-12345.rs` is much better), or perhaps give it a more @@ -58,11 +58,8 @@ meaningful name. Still, **do include the issue number somewhere**. When writing a new feature, **create a subdirectory to store your tests**. For example, if you are implementing RFC 1234 ("Widgets"), -then it might make sense to put the tests in directories like: - -- `src/test/ui/rfc1234-widgets/` -- `src/test/run-pass/rfc1234-widgets/` -- etc +then it might make sense to put the tests in a directory like +`src/test/ui/rfc1234-widgets/`. In other cases, there may already be a suitable directory. (The proper directory structure to use is actually an area of active debate.) @@ -216,7 +213,7 @@ The error levels that you can have are: ## Revisions Certain classes of tests support "revisions" (as of the time of this -writing, this includes run-pass, compile-fail, run-fail, and +writing, this includes compile-fail, run-fail, and incremental, though incremental tests are somewhat different). Revisions allow a single test file to be used for multiple tests. This is done by adding a special header at the top of the file: diff --git a/src/tests/running.md b/src/tests/running.md index 01d308f0b..ef3227f9a 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -34,10 +34,10 @@ test" that can be used after modifying rustc to see if things are generally working correctly would be the following: ```bash -> ./x.py test --stage 1 src/test/{ui,compile-fail,run-pass} +> ./x.py test --stage 1 src/test/{ui,compile-fail} ``` -This will run the `ui`, `compile-fail`, and `run-pass` test suites, +This will run the `ui` and `compile-fail` test suites, and only with the stage 1 build. Of course, the choice of test suites is somewhat arbitrary, and may not suit the task you are doing. For example, if you are hacking on debuginfo, you may be better off with @@ -114,10 +114,10 @@ Pass UI tests now have three modes, `check-pass`, `build-pass` and `run-pass`. When `--pass $mode` is passed, these tests will be forced to run under the given `$mode` unless the directive `// ignore-pass` exists in the test file. For example, you can run all the tests in -`src/test/run-pass` as `check-pass`: +`src/test/ui` as `check-pass`: ```bash -> ./x.py test --stage 1 src/test/run-pass --pass check +> ./x.py test --stage 1 src/test/ui --pass check ``` By passing `--pass $mode`, you can reduce the testing time. For each From d420542602d623497778880ec63561b477dc0756 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 5 Aug 2019 15:57:25 -0500 Subject: [PATCH 0640/1812] hack around timeouts (#416) --- .travis.yml | 4 ++-- ci/build-ignore-timeouts.sh | 23 +++++++++++++++++++++++ 2 files changed, 25 insertions(+), 2 deletions(-) create mode 100644 ci/build-ignore-timeouts.sh diff --git a/.travis.yml b/.travis.yml index fc6f4f05e..bd72a03fc 100644 --- a/.travis.yml +++ b/.travis.yml @@ -8,9 +8,9 @@ before_install: - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true -- bash ci/install.sh +- bash -x ci/install.sh script: -- mdbook build +- bash -x ci/build-ignore-timeouts.sh - mdbook test notifications: email: diff --git a/ci/build-ignore-timeouts.sh b/ci/build-ignore-timeouts.sh new file mode 100644 index 000000000..b21ce24e8 --- /dev/null +++ b/ci/build-ignore-timeouts.sh @@ -0,0 +1,23 @@ + +output=$(mktemp) + +RUST_LOG=mdbook_linkcheck=debug mdbook build 2>&1 | tee $output + +result=${PIPESTATUS[0]} + +# if passed, great! +if [ "$result" -eq "0" ] ; then + exit 0 ; +fi + +errors=$(cat $output | sed -n 's/There \(was\|were\) \([0-9]\+\).*$/\2/p') +timeouts=$(cat $output | grep "error while fetching" | wc -l) + +# if all errors are timeouts, ignore them... +if [ "$errors" -eq "$timeouts" ] ; then + echo "Ignoring $timeouts timeouts"; + exit 0; +else + echo "Non-timeout errors found"; + exit 1; +fi From 84aa3362e6271b996fd557d5a2755b371e38b6cf Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 5 Aug 2019 23:03:34 +0200 Subject: [PATCH 0641/1812] a colon there is unusual (#415) --- src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 0a746177b..eb14e8fad 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -434,7 +434,7 @@ whether the compiler builds is not enough. A common example is that you need to add a `debug!` statement to inspect the value of some state or better understand the problem. In that case, you really need a full build. By leveraging incremental, though, you can often get -these builds to complete very fast (e.g., around 30 seconds): the only +these builds to complete very fast (e.g., around 30 seconds). The only catch is this requires a bit of fudging and may produce compilers that don't work (but that is easily detected and fixed). From b94deb1afea33a15d79cf2944ba7458ce9c42926 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 5 Aug 2019 23:06:51 +0200 Subject: [PATCH 0642/1812] fix typo (#412) --- src/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index eb14e8fad..8a803e66c 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -160,7 +160,7 @@ The following tables indicate the outputs of various stage actions: | `stage0` builds `rustc` with `stage0-sysroot` | `build/HOST/stage0-rustc/HOST` | | copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | | build `llvm` | `build/HOST/llvm` | -| `stage0` builds `codegen` with `stage0-sysroot` | `build/HOST/stage0-codgen/HOST` | +| `stage0` builds `codegen` with `stage0-sysroot` | `build/HOST/stage0-codegen/HOST` | | `stage0` builds `rustdoc` with `stage0-sysroot` | `build/HOST/stage0-tools/HOST` | `--stage=0` stops here. From 4ee7cdaea47119f7d53f10df7a4be273f51dea2c Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 5 Aug 2019 23:07:05 +0200 Subject: [PATCH 0643/1812] update link (#411) --- src/compiler-team.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index 1dbeeb422..d61137682 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -5,7 +5,7 @@ this team collectively work to track regressions and implement new features. Members of the Rust compiler team are people who have made significant contributions to rustc and its design. -[team]: https://www.rust-lang.org/governance/teams/language-and-compiler +[team]: https://www.rust-lang.org/governance/teams/compiler ## Discussion From 07dbcdec1888b2a5e9e78f4828c52417c49e0398 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 5 Aug 2019 23:07:17 +0200 Subject: [PATCH 0644/1812] fix awkward sentence structure (#410) --- src/about-this-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index df060a208..48ea4dce6 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -3,7 +3,7 @@ This guide is meant to help document how rustc – the Rust compiler – works, as well as to help new contributors get involved in rustc development. It is not meant to replace code documentation – each -chapter gives only high-level details – the kinds of things that +chapter gives only high-level details, the kinds of things that (ideally) don't change frequently. There are three parts to this guide. Part 1 contains information that should From 6f4ba673ff9d4613e98415bc095347a6a0031e9c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 6 Aug 2019 16:49:01 -0500 Subject: [PATCH 0645/1812] Remove leading new line --- ci/build-ignore-timeouts.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/ci/build-ignore-timeouts.sh b/ci/build-ignore-timeouts.sh index b21ce24e8..e777f349a 100644 --- a/ci/build-ignore-timeouts.sh +++ b/ci/build-ignore-timeouts.sh @@ -1,3 +1,4 @@ +#!/bin/bash -x output=$(mktemp) From b7f24940c06fff812c89198844335d6d9a65eabc Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 13 Aug 2019 09:56:02 -0500 Subject: [PATCH 0646/1812] fix broken link (#421) --- ci/build-ignore-timeouts.sh | 0 src/appendix/code-index.md | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 ci/build-ignore-timeouts.sh diff --git a/ci/build-ignore-timeouts.sh b/ci/build-ignore-timeouts.sh old mode 100644 new mode 100755 diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 52a7f42d6..267a3a3ea 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -19,7 +19,7 @@ Item | Kind | Short description | Chapter | `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) -`Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Rib.html) +`Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) `Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) `SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) From 6b6e6cc3bfb312e39661db026343ee0be03cf26f Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Tue, 13 Aug 2019 18:20:22 +0300 Subject: [PATCH 0647/1812] document how to use system llvm --- src/how-to-build-and-run.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 8a803e66c..2c4d2a979 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -469,6 +469,18 @@ You can also use `--keep-stage 1` when running tests. Something like this: - Initial test run: `./x.py test -i --stage 1 src/test/ui` - Subsequent test run: `./x.py test -i --stage 1 src/test/ui --keep-stage 1` +### Building with system LLVM + +By default, LLVM is built from source, and that can take significant amount of time. +An alternative is to use LLVM already installed on your computer. + +This is specified in the `target` section of `config.toml`: + +```toml +[target.x86_64-unknown-linux-gnu] +llvm-config = "/path/to/llvm/llvm-7.0.1/bin/llvm-config" +``` + ### Other `x.py` commands Here are a few other useful `x.py` commands. We'll cover some of them in detail From 5919642a096a474f426214efaf65ee996df4f08a Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Sat, 17 Aug 2019 13:19:10 -0400 Subject: [PATCH 0648/1812] Fix a typo in the implied bounds section of traits/lowering-rules --- src/traits/lowering-rules.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md index bbebf1450..c780e7cf5 100644 --- a/src/traits/lowering-rules.md +++ b/src/traits/lowering-rules.md @@ -114,7 +114,7 @@ cover). For each trait, we produce two clauses: // // For each where clause WC: forall { - FromEnv(WC) :- FromEnv(Self: Trait) } ``` From 6e25a3d0d3573eb42b2e2339f1219e969d1b3dee Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Wed, 21 Aug 2019 10:23:43 -0500 Subject: [PATCH 0649/1812] fix links --- src/appendix/bibliography.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index 19a9217f7..03ba3a41c 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -61,7 +61,7 @@ Rust, as well as publications about Rust. * [Reenix: Implementing a Unix-Like Operating System in Rust](http://scialex.github.io/reenix.pdf). Undergrad paper by Alex Light. -* [Evaluation of performance and productivity metrics of potential programming languages in the HPC environment](http://octarineparrot.com/assets/mrfloya-thesis-ba.pdf). +* [Evaluation of performance and productivity metrics of potential programming languages in the HPC environment](https://github.com/1wilkens/thesis-ba). Bachelor's thesis by Florian Wilkens. Compares C, Go and Rust. * [Nom, a byte oriented, streaming, zero copy, parser combinators library in Rust](http://spw15.langsec.org/papers/couprie-nom.pdf). By @@ -81,7 +81,7 @@ Rust, as well as publications about Rust. * [Ownership is Theft: Experiences Building an Embedded OS in Rust - Amit Levy, et. al.](http://amitlevy.com/papers/tock-plos2015.pdf) * [You can't spell trust without Rust](https://raw.githubusercontent.com/Gankro/thesis/master/thesis.pdf). Alexis Beingessner's master's thesis. * [Rust-Bio: a fast and safe bioinformatics library](http://bioinformatics.oxfordjournals.org/content/early/2015/10/06/bioinformatics.btv573). Johannes Köster -* [Safe, Correct, and Fast Low-Level Networking](https://octarineparrot.com/assets/msci_paper.pdf). Robert Clipsham's master's thesis. +* [Safe, Correct, and Fast Low-Level Networking](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.704.1768). Robert Clipsham's master's thesis. * [Formalizing Rust traits](http://hdl.handle.net/2429/55609). Jonatan Milewski's master's thesis. * [Rust as a Language for High Performance GC Implementation](http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rust-ismm-2016.pdf) * [Simple Verification of Rust Programs via Functional Purification](https://github.com/Kha/electrolysis). Sebastian Ullrich's master's thesis. From 263b2a208a1d54439afdb261cb7befa545f06f66 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 24 Aug 2019 21:44:12 -0500 Subject: [PATCH 0650/1812] remove flaky link --- src/traits/bibliography.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/traits/bibliography.md b/src/traits/bibliography.md index b8f345d9d..a0242d4c4 100644 --- a/src/traits/bibliography.md +++ b/src/traits/bibliography.md @@ -21,9 +21,7 @@ environments, and Lambda Prolog-style proof search. Quite readable. ["A new formulation of tabled resolution with delay"][nftrd], by -[Theresa Swift]. This paper gives a kind of abstract treatment of the +Theresa Swift. This paper gives a kind of abstract treatment of the SLG formulation that is the basis for our on-demand solver. [nftrd]: https://dl.acm.org/citation.cfm?id=651202 -[ts]: http://www3.cs.stonybrook.edu/~tswift/ -[Theresa Swift]: http://www3.cs.stonybrook.edu/~tswift/ From 0fa1588dd2d0b0e324931c77228e1903f7638434 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 16:20:09 +0200 Subject: [PATCH 0651/1812] Explain our stability attributes --- src/SUMMARY.md | 1 + src/stability.md | 35 +++++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 src/stability.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 75e1fcdc2..cc2696b1f 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -15,6 +15,7 @@ - [Using `compiletest` + commands to control test execution](./compiletest.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [Implementing new features](./implementing_new_features.md) + - [Stability attributes](./stability.md) - [Stabilizing Features](./stabilization_guide.md) - [Debugging the Compiler](./compiler-debugging.md) - [Profiling the compiler](./profiling.md) diff --git a/src/stability.md b/src/stability.md new file mode 100644 index 000000000..34e0db952 --- /dev/null +++ b/src/stability.md @@ -0,0 +1,35 @@ +# Stability + +This section is about the stability attributes and schemes that allow stable APIs to use unstable +APIs internally in the rustc standard library. + +For instructions on stabilizing a feature see [Stabilizing Features](./stabilization_guide.md). + +# unstable + +The `#[unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` attribute explicitly +marks an item as unstable. This infects all sub-items, where the attribute doesn't have to be +reapplied. So if you apply this to a module, all items in the module will be unstable. + +# stable + +The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks an item as +stabilized. In order to do this follow the instructions in +[Stabilizing Features](./stabilization_guide.md). + +Note that stable functions may use unstable things in their body. + +# allow_internal_unstable + +Macros, compiler desugarings and `const fn`s expose their bodies to the call site. In order to +work around not being able to use unstable things in the standard libraries macros, there's the +`#[allow_internal_unstable(feature1, feature2)]` attribute that whitelists the given features for +usage in stable macros or `const fn`s. + +Note that `const fn`s are even more special in this regard. You can't just whitelist any feature, +the features need an implementation in `qualify_min_const_fn.rs`. For example the `const_fn_union` +feature gate allows accessing fields of unions inside stable `const fn`s. The rules for when it's +ok to use such a feature gate are that behavior matches the runtime behavior of the same code +(see also https://www.ralfj.de/blog/2018/07/19/const.html). This means that you may not create a +`const fn` that e.g. transmutes a memory address to an integer, because the addresses of things +are nondeterministic and often unknown at compile-time. From 4f479f5bd57be6b72968ba1de8d3693081a5964d Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 16:32:12 +0200 Subject: [PATCH 0652/1812] Update src/stability.md Co-Authored-By: Jake Goulding --- src/stability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stability.md b/src/stability.md index 34e0db952..42eb7a9a7 100644 --- a/src/stability.md +++ b/src/stability.md @@ -22,7 +22,7 @@ Note that stable functions may use unstable things in their body. # allow_internal_unstable Macros, compiler desugarings and `const fn`s expose their bodies to the call site. In order to -work around not being able to use unstable things in the standard libraries macros, there's the +work around not being able to use unstable things in the standard library's macros, there's the `#[allow_internal_unstable(feature1, feature2)]` attribute that whitelists the given features for usage in stable macros or `const fn`s. From 80ede1ce13e63531a66f98821df0de12779b790f Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 17:01:40 +0200 Subject: [PATCH 0653/1812] Apply suggestions from code review Co-Authored-By: Mazdak Farrokhzad --- src/stability.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/stability.md b/src/stability.md index 42eb7a9a7..30f328b7c 100644 --- a/src/stability.md +++ b/src/stability.md @@ -1,9 +1,9 @@ -# Stability +# Stability attributes This section is about the stability attributes and schemes that allow stable APIs to use unstable APIs internally in the rustc standard library. -For instructions on stabilizing a feature see [Stabilizing Features](./stabilization_guide.md). +For instructions on stabilizing a language feature see [Stabilizing Features](./stabilization_guide.md). # unstable @@ -14,14 +14,14 @@ reapplied. So if you apply this to a module, all items in the module will be uns # stable The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks an item as -stabilized. In order to do this follow the instructions in +stabilized. To do this, follow the instructions in [Stabilizing Features](./stabilization_guide.md). Note that stable functions may use unstable things in their body. # allow_internal_unstable -Macros, compiler desugarings and `const fn`s expose their bodies to the call site. In order to +Macros, compiler desugarings and `const fn`s expose their bodies to the call site. To work around not being able to use unstable things in the standard library's macros, there's the `#[allow_internal_unstable(feature1, feature2)]` attribute that whitelists the given features for usage in stable macros or `const fn`s. From c6f3317a60026c4c049a974c5ff7247f87a00041 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 17:06:05 +0200 Subject: [PATCH 0654/1812] Update stability.md --- src/stability.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/stability.md b/src/stability.md index 30f328b7c..061ee2871 100644 --- a/src/stability.md +++ b/src/stability.md @@ -11,6 +11,10 @@ The `#[unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` attri marks an item as unstable. This infects all sub-items, where the attribute doesn't have to be reapplied. So if you apply this to a module, all items in the module will be unstable. +You can make specific sub-items stable by using the `#[stable]` attribute on them. +The stability scheme works similarly to how `pub` works. You can have public functions of +nonpublic modules and you can have stable functions in unstable modules or vice versa. + # stable The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks an item as From 3f0eadeff23c5f2bc7c9002f69201776bc2e65e4 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Wed, 21 Aug 2019 17:31:08 +0200 Subject: [PATCH 0655/1812] Update stability.md --- src/stability.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/stability.md b/src/stability.md index 061ee2871..5af80932f 100644 --- a/src/stability.md +++ b/src/stability.md @@ -37,3 +37,6 @@ ok to use such a feature gate are that behavior matches the runtime behavior of (see also https://www.ralfj.de/blog/2018/07/19/const.html). This means that you may not create a `const fn` that e.g. transmutes a memory address to an integer, because the addresses of things are nondeterministic and often unknown at compile-time. + +Always ping @oli-obk, @RalfJung, and @Centril if you are adding more `allow_internal_unstable` +attributes to any `const fn` From 3c0ddd7bf9240c7875cd2adbf617acfb26167098 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 24 Aug 2019 21:57:17 -0500 Subject: [PATCH 0656/1812] minor fixes --- src/stability.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/stability.md b/src/stability.md index 5af80932f..f35b1c08b 100644 --- a/src/stability.md +++ b/src/stability.md @@ -3,7 +3,8 @@ This section is about the stability attributes and schemes that allow stable APIs to use unstable APIs internally in the rustc standard library. -For instructions on stabilizing a language feature see [Stabilizing Features](./stabilization_guide.md). +For instructions on stabilizing a language feature see +[Stabilizing Features](./stabilization_guide.md). # unstable @@ -34,9 +35,11 @@ Note that `const fn`s are even more special in this regard. You can't just white the features need an implementation in `qualify_min_const_fn.rs`. For example the `const_fn_union` feature gate allows accessing fields of unions inside stable `const fn`s. The rules for when it's ok to use such a feature gate are that behavior matches the runtime behavior of the same code -(see also https://www.ralfj.de/blog/2018/07/19/const.html). This means that you may not create a +(see also [this blog post][blog]). This means that you may not create a `const fn` that e.g. transmutes a memory address to an integer, because the addresses of things are nondeterministic and often unknown at compile-time. Always ping @oli-obk, @RalfJung, and @Centril if you are adding more `allow_internal_unstable` attributes to any `const fn` + +[blog]: https://www.ralfj.de/blog/2018/07/19/const.html From ba26418f5e16771681129a28c9308af9b10e8de6 Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Sun, 25 Aug 2019 12:14:21 -0400 Subject: [PATCH 0657/1812] Improve "Profiling the compiler" docs Add mentions and links to `rustc-perf` and `measureme`. --- src/profiling.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/src/profiling.md b/src/profiling.md index f6771b07b..b7cc72258 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -1,9 +1,16 @@ # Profiling the compiler -This discussion talks about how profile the compiler and find out -where it spends its time. If you just want to get a general overview, -it is often a good idea to just add `-Zself-profile` option to the -rustc command line. This will break down time spent into various -categories. But if you want a more detailed look, you probably want -to break out a custom profiler. +This section talks about how to profile the compiler and find out where it spends its time. + +Depending on what you're trying to measure, there are several different approaches: + +- If you want to see if a PR improves or regresses compiler performance: + - The [rustc-perf](https://github.com/rust-lang-nursery/rustc-perf) project makes this easy and can be triggered to run on a PR via the `@rustc-perf` bot. + +- If you want a medium-to-high level overview of where `rustc` is spending its time: + - The `-Zself-profile` flag and [measureme](https://github.com/rust-lang/measureme) tools offer a query-based approach to profiling. + See [their docs](https://github.com/rust-lang/measureme/blob/master/summarize/Readme.md) for more information. + +- If you want function level performance data or even just more details than the above approaches: + - Consider using a native code profiler such as [perf](profiling/with_perf.html). From 78b63d19e57cfe3b309d6bf394640dfc193f403e Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sun, 25 Aug 2019 10:22:14 +0200 Subject: [PATCH 0658/1812] mention stable-in-unstable issue --- src/stability.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/stability.md b/src/stability.md index f35b1c08b..46f62e520 100644 --- a/src/stability.md +++ b/src/stability.md @@ -16,6 +16,13 @@ You can make specific sub-items stable by using the `#[stable]` attribute on the The stability scheme works similarly to how `pub` works. You can have public functions of nonpublic modules and you can have stable functions in unstable modules or vice versa. +Note, however, that due to a [rustc bug], stable items inside unstable modules +*are* available to stable code in that location! So, for example, stable code +can import `core::intrinsics::transmute` even though `intrinsics` is an unstable +module. Thus, this kind of nesting should be avoided when possible. + +[rustc bug]: https://github.com/rust-lang/rust/issues/15702 + # stable The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks an item as From 41b8b221be0796a8a614574a7098657bdb2f5a37 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 27 Aug 2019 00:54:11 +0200 Subject: [PATCH 0659/1812] 'or' skipped --- src/borrow_check.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check.md b/src/borrow_check.md index b3eeaa387..76f182083 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -8,7 +8,7 @@ enforcing a number of properties: - That you can't move a value while it is borrowed. - That you can't access a place while it is mutably borrowed (except through the reference). -- That you can't mutate a place while it is shared borrowed. +- That you can't mutate a place while it is shared or borrowed. - etc At the time of this writing, the code is in a state of transition. The From 1c16c51dc5ddb3930d49236432604572c34f1a03 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 27 Aug 2019 14:44:07 +0200 Subject: [PATCH 0660/1812] immutable was meant here (#435) --- src/borrow_check.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check.md b/src/borrow_check.md index 76f182083..b3864aac4 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -8,7 +8,7 @@ enforcing a number of properties: - That you can't move a value while it is borrowed. - That you can't access a place while it is mutably borrowed (except through the reference). -- That you can't mutate a place while it is shared or borrowed. +- That you can't mutate a place while it is immutably borrowed. - etc At the time of this writing, the code is in a state of transition. The From 9c6beb5bdd956ab33b24eb53f9e66c10e93d6a52 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 27 Aug 2019 14:44:58 +0200 Subject: [PATCH 0661/1812] merge libtest build step with libstd (#434) Partially handles #431 --- src/how-to-build-and-run.md | 31 +++++++++---------------------- 1 file changed, 9 insertions(+), 22 deletions(-) diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md index 2c4d2a979..aac0f211c 100644 --- a/src/how-to-build-and-run.md +++ b/src/how-to-build-and-run.md @@ -69,10 +69,10 @@ The result is that compiling `rustc` is done in stages: - **Stage 0:** the stage0 compiler is usually (you can configure `x.py` to use something else) the current _beta_ `rustc` compiler and its associated dynamic libraries (which `x.py` will download for you). This stage0 compiler is then - used only to compile `rustbuild`, `std`, `test`, and `rustc`. When compiling - `test` and `rustc`, this stage0 compiler uses the freshly compiled `std`. + used only to compile `rustbuild`, `std`, and `rustc`. When compiling + `rustc`, this stage0 compiler uses the freshly compiled `std`. There are two concepts at play here: a compiler (with its set of dependencies) - and its 'target' or 'object' libraries (`std`, `test`, and `rustc`). + and its 'target' or 'object' libraries (`std` and `rustc`). Both are staged, but in a staggered manner. - **Stage 1:** the code in your clone (for new version) is then compiled with the stage0 compiler to produce the stage1 compiler. @@ -102,8 +102,6 @@ When running `x.py` you will see output such as: ```txt Building stage0 std artifacts Copying stage0 std from stage0 -Building stage0 test artifacts -Copying stage0 test from stage0 Building stage0 compiler artifacts Copying stage0 rustc from stage0 Building LLVM for x86_64-apple-darwin @@ -111,8 +109,6 @@ Building stage0 codegen artifacts Assembling stage1 compiler Building stage1 std artifacts Copying stage1 std from stage1 -Building stage1 test artifacts -Copying stage1 test from stage1 Building stage1 compiler artifacts Copying stage1 rustc from stage1 Building stage1 codegen artifacts @@ -127,13 +123,10 @@ Building rustdoc for stage2 Documenting book redirect pages Documenting stage2 std Building rustdoc for stage1 -Documenting stage2 test Documenting stage2 whitelisted compiler Documenting stage2 compiler Documenting stage2 rustdoc Documenting error index -Uplifting stage1 test -Copying stage2 test from stage1 Uplifting stage1 rustc Copying stage2 rustc from stage1 Building stage2 tool error_index_generator @@ -155,8 +148,6 @@ The following tables indicate the outputs of various stage actions: | `stage0` builds `bootstrap` | `build/bootstrap` | | `stage0` builds `libstd` | `build/HOST/stage0-std/TARGET` | | copy `stage0-std` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | -| `stage0` builds `libtest` with `stage0-sysroot` | `build/HOST/stage0-test/TARGET` | -| copy `stage0-test` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | | `stage0` builds `rustc` with `stage0-sysroot` | `build/HOST/stage0-rustc/HOST` | | copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | | build `llvm` | `build/HOST/llvm` | @@ -172,8 +163,6 @@ The following tables indicate the outputs of various stage actions: | copy (uplift) `stage0-sysroot` to `stage1` | `build/HOST/stage1/lib` | | `stage1` builds `libstd` | `build/HOST/stage1-std/TARGET` | | copy `stage1-std` (HOST only) | `build/HOST/stage1/lib/rustlib/HOST` | -| `stage1` builds `libtest` | `build/HOST/stage1-test/TARGET` | -| copy `stage1-test` (HOST only) | `build/HOST/stage1/lib/rustlib/HOST` | | `stage1` builds `rustc` | `build/HOST/stage1-rustc/HOST` | | copy `stage1-rustc` (except executable) | `build/HOST/stage1/lib/rustlib/HOST` | | `stage1` builds `codegen` | `build/HOST/stage1-codegen/HOST` | @@ -186,8 +175,6 @@ The following tables indicate the outputs of various stage actions: | copy (uplift) `stage1-sysroot` | `build/HOST/stage2/lib and build/HOST/stage2/lib/rustlib/HOST` | | `stage2` builds `libstd` (except HOST?) | `build/HOST/stage2-std/TARGET` | | copy `stage2-std` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | -| `stage2` builds `libtest` (except HOST?) | `build/HOST/stage2-test/TARGET` | -| copy `stage2-test` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | | `stage2` builds `rustdoc` | `build/HOST/stage2-tools/HOST` | | copy `rustdoc` | `build/HOST/stage2/bin` | @@ -201,10 +188,10 @@ Note that the convention `x.py` uses is that: In short, _stage 0 uses the stage0 compiler to create stage0 artifacts which will later be uplifted to stage1_. -Every time any of the main artifacts (`std`, `test`, `rustc`) are compiled, two +Every time any of the main artifacts (`std` and `rustc`) are compiled, two steps are performed. When `std` is compiled by a stage N compiler, that `std` will be linked to -programs built by the stage N compiler (including test and `rustc` built later +programs built by the stage N compiler (including `rustc` built later on). It will also be used by the stage (N+1) compiler to link against itself. This is somewhat intuitive if one thinks of the stage (N+1) compiler as "just" another program we are building with the stage N compiler. In some ways, `rustc` @@ -213,7 +200,7 @@ another program we are building with the stage N compiler. In some ways, `rustc` So "stage0 std artifacts" are in fact the output of the downloaded stage0 compiler, and are going to be used for anything built by the stage0 compiler: -e.g. `rustc`, `test` artifacts. When it announces that it is "building stage1 +e.g. `rustc` artifacts. When it announces that it is "building stage1 std artifacts" it has moved on to the next bootstrapping phase. This pattern continues in latter stages. @@ -247,9 +234,9 @@ recompiling that `std`. `--keep-stage` simply assumes the previous compile is fine and copies those artifacts into the appropriate place, skipping the cargo invocation. -The reason we first build `std`, then `test`, then `rustc`, is largely just +The reason we first build `std`, then `rustc`, is largely just because we want to minimize `cfg(stage0)` in the code for `rustc`. -Currently `rustc` is always linked against a "new" `std`/`test` so it doesn't +Currently `rustc` is always linked against a "new" `std` so it doesn't ever need to be concerned with differences in std; it can assume that the std is as fresh as possible. @@ -265,7 +252,7 @@ same libraries as the `stage2/bin/rustc` compiler uses itself for programs it links against. This `stage2/bin/rustc` compiler is shipped to end-users, along with the -`stage 1 {std,test,rustc}` artifacts. +`stage 1 {std,rustc}` artifacts. If you want to learn more about `x.py`, read its README.md [here](https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md). From 20d27f2dda3e401379388ad2b3ed4074428eff6e Mon Sep 17 00:00:00 2001 From: varkor Date: Thu, 1 Aug 2019 00:44:51 +0100 Subject: [PATCH 0662/1812] Update section on "existential type" to "opaque type" --- src/existential-types.md | 48 ------------------ src/opaque-types-type-alias-impl-trait.md | 62 +++++++++++++++++++++++ 2 files changed, 62 insertions(+), 48 deletions(-) delete mode 100644 src/existential-types.md create mode 100644 src/opaque-types-type-alias-impl-trait.md diff --git a/src/existential-types.md b/src/existential-types.md deleted file mode 100644 index ef20167c1..000000000 --- a/src/existential-types.md +++ /dev/null @@ -1,48 +0,0 @@ -# Existential Types - -Existential types are essentially strong type aliases which only expose -a specific set of traits as their interface and the concrete type in the -background is inferred from a certain set of use sites of the existential -type. - -In the language they are expressed via - -```rust,ignore -existential type Foo: Bar; -``` - -This is in existential type named `Foo` which can be interacted with via -the `Bar` trait's interface. - -Since there needs to be a concrete background type, you can currently -express that type by using the existential type in a "defining use site". - -```rust,ignore -struct Struct; -impl Bar for Struct { /* stuff */ } -fn foo() -> Foo { - Struct -} -``` - -Any other "defining use site" needs to produce the exact same type. - -## Defining use site(s) - -Currently only the return value of a function inside can -be a defining use site of an existential type (and only if the return -type of that function contains the existential type). - -The defining use of an existential type can be any code *within* the parent -of the existential type definition. This includes any siblings of the -existential type and all children of the siblings. - -The initiative for *"not causing fatal brain damage to developers due to -accidentally running infinite loops in their brain while trying to -comprehend what the type system is doing"* has decided to disallow children -of existential types to be defining use sites. - -### Associated existential types - -Associated existential types can be defined by any other associated item -on the same trait `impl` or a child of these associated items. diff --git a/src/opaque-types-type-alias-impl-trait.md b/src/opaque-types-type-alias-impl-trait.md new file mode 100644 index 000000000..e78d3c75d --- /dev/null +++ b/src/opaque-types-type-alias-impl-trait.md @@ -0,0 +1,62 @@ +# Opaque types (type alias `impl Trait`) + +Opaque types are syntax to declare an opaque type alias that only +exposes a specific set of traits as their interface; the concrete type in the +background is inferred from a certain set of use sites of the opaque type. + +This is expressed by using `impl Trait` within type aliases, for example: + +```rust,ignore +type Foo = impl Bar; +``` + +This declares an opaque type named `Foo`, of which the only information is that +it implements `Bar`. Therefore, any of `Bar`'s interface can be used on a `Foo`, +but nothing else (regardless of whether it implements any other traits). + +Since there needs to be a concrete background type, you can currently +express that type by using the opaque type in a "defining use site". + +```rust,ignore +struct Struct; +impl Bar for Struct { /* stuff */ } +fn foo() -> Foo { + Struct +} +``` + +Any other "defining use site" needs to produce the exact same type. + +## Defining use site(s) + +Currently only the return value of a function can be a defining use site +of an opaque type (and only if the return type of that function contains +the opaque type). + +The defining use of an opaque type can be any code *within* the parent +of the opaque type definition. This includes any siblings of the +opaque type and all children of the siblings. + +The initiative for *"not causing fatal brain damage to developers due to +accidentally running infinite loops in their brain while trying to +comprehend what the type system is doing"* has decided to disallow children +of opaque types to be defining use sites. + +### Associated opaque types + +Associated opaque types can be defined by any other associated item +on the same trait `impl` or a child of these associated items. For instance: + +```rust,ignore +trait Baz { + type Foo; + fn foo() -> Self::Foo; +} + +struct Quux; + +impl Baz for Quux { + type Foo = impl Bar; + fn foo() -> Self::Foo { ... } +} +``` From 44b5ce2f1fa766f7b85f11d2cc0b50f4831072b1 Mon Sep 17 00:00:00 2001 From: Edd Barrett Date: Mon, 2 Sep 2019 11:56:43 +0100 Subject: [PATCH 0663/1812] Fix a link in the query docs. --- src/query.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/query.md b/src/query.md index 4ab1d079e..f5961f6ba 100644 --- a/src/query.md +++ b/src/query.md @@ -35,9 +35,9 @@ will in turn demand information about that crate, starting from the However, that vision is not fully realized. Still, big chunks of the compiler (for example, generating MIR) work exactly like this. -### The Query Evaluation Model in Detail +### Incremental Compilation in Detail -The [Query Evaluation Model in Detail][query-model] chapter gives a more +The [Incremental Compilation in Detail][query-model] chapter gives a more in-depth description of what queries are and how they work. If you intend to write a query of your own, this is a good read. @@ -277,4 +277,4 @@ rustc_queries! { `rustc_queries` macro will generate an appropriate `impl` automatically. -[query-model]: queries/query-evaluation-model-in-detail.html +[query-model]: queries/incremental-compilation-in-detail.md From a0c08c27e60e52b72244c5241ed494a197bebf28 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 5 Sep 2019 16:51:34 -0500 Subject: [PATCH 0664/1812] fix broken link --- src/compiler-team.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index d61137682..42f6cc0ac 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -27,10 +27,8 @@ who are experts on each one. ## Rust compiler meeting The compiler team has a weekly meeting where we do triage and try to -generally stay on top of new bugs, regressions, and other things. This -general plan for this meeting can be found in -[the rust-compiler-meeting etherpad][etherpad]. It works roughly as -follows: +generally stay on top of new bugs, regressions, and other things. +They are held on [Zulip][zulip]. It works roughly as follows: - **Review P-high bugs:** P-high bugs are those that are sufficiently important for us to actively track progress. P-high bugs should @@ -44,6 +42,8 @@ follows: the team is desired. - **Check for beta nominations:** These are nominations of things to backport to beta. +- **Possibly WG checking:** A WG may give an update at this point, if there is + time. The meeting currently takes place on Thursdays at 10am Boston time (UTC-4 typically, but daylight savings time sometimes makes things From 5959ff2655b9ce3f843434a6a6570179f6f98284 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Mon, 26 Aug 2019 18:53:45 +0800 Subject: [PATCH 0665/1812] Updated the mdbook-linkcheck version --- ci/install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/install.sh b/ci/install.sh index 48df957f9..a81e21c56 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -21,4 +21,4 @@ function cargo_install() { } cargo_install mdbook 0.3.1 -cargo_install mdbook-linkcheck 0.3.1 +cargo_install mdbook-linkcheck 0.4.0 From 1952189e86da69a548b86d81be6a37c02ffb243e Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Tue, 27 Aug 2019 14:21:22 +0800 Subject: [PATCH 0666/1812] Made sure travis caches mdbook-linkcheck's cache file --- .travis.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.travis.yml b/.travis.yml index bd72a03fc..8fa2f0c1d 100644 --- a/.travis.yml +++ b/.travis.yml @@ -3,6 +3,8 @@ rust: - nightly cache: - cargo +- directories: + - book/linkcheck/ before_install: - shopt -s globstar - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md From 941968db2fd9c85788a4f971c8e425d46b4cb734 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 5 Sep 2019 18:58:16 -0500 Subject: [PATCH 0667/1812] hack + drive-by-fix --- .travis.yml | 2 +- book.toml | 4 ++++ ci/build-ignore-timeouts.sh | 7 ++++++- src/SUMMARY.md | 2 +- 4 files changed, 12 insertions(+), 3 deletions(-) diff --git a/.travis.yml b/.travis.yml index 8fa2f0c1d..c33c38b84 100644 --- a/.travis.yml +++ b/.travis.yml @@ -4,7 +4,7 @@ rust: cache: - cargo - directories: - - book/linkcheck/ + - $HOME/linkcheck/ before_install: - shopt -s globstar - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md diff --git a/book.toml b/book.toml index 856ef2eba..1d207bf22 100644 --- a/book.toml +++ b/book.toml @@ -3,10 +3,14 @@ title = "Guide to Rustc Development" author = "Rustc developers" description = "A guide to developing rustc" +[build] +create-missing = false + [output.html] [output.html.search] [output.linkcheck] +command = "sed 's/.*//'" # tell mdbook not to run, since we want to run it manually follow-web-links = true exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "dl\\.acm\\.org" ] diff --git a/ci/build-ignore-timeouts.sh b/ci/build-ignore-timeouts.sh index e777f349a..3ec81f624 100755 --- a/ci/build-ignore-timeouts.sh +++ b/ci/build-ignore-timeouts.sh @@ -2,7 +2,12 @@ output=$(mktemp) -RUST_LOG=mdbook_linkcheck=debug mdbook build 2>&1 | tee $output +mkdir -p book/ +cp -r $HOME/linkcheck/ book/ +RUST_LOG=mdbook_linkcheck=debug mdbook-linkcheck -s 2>&1 | tee -a $output +cp -r book/linkcheck $HOME/ + +mdbook build result=${PIPESTATUS[0]} diff --git a/src/SUMMARY.md b/src/SUMMARY.md index cc2696b1f..f672df510 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -65,7 +65,7 @@ - [Type checking](./type-checking.md) - [Method Lookup](./method-lookup.md) - [Variance](./variance.md) - - [Existential Types](./existential-types.md) + - [Opaque Types](./opaque-types-type-alias-impl-trait.md) - [The MIR (Mid-level IR)](./mir/index.md) - [MIR construction](./mir/construction.md) - [MIR visitor and traversal](./mir/visitor.md) From 079a0dd092fa329b678a065ffff17478140893bc Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sun, 8 Sep 2019 07:05:22 +0200 Subject: [PATCH 0668/1812] typo (#441) --- src/codegen/debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/codegen/debugging.md b/src/codegen/debugging.md index 51d5a3b2c..a6ad91dd1 100644 --- a/src/codegen/debugging.md +++ b/src/codegen/debugging.md @@ -40,7 +40,7 @@ hard to replicate manually and means that LLVM is called multiple times in parallel. If you can get away with it (i.e. if it doesn't make your bug disappear), passing `-C codegen-units=1` to rustc will make debugging easier. -To rustc to generate LLVM IR, you need to pass the `--emit=llvm-ir` flag. If +For rustc to generate LLVM IR, you need to pass the `--emit=llvm-ir` flag. If you are building via cargo, use the `RUSTFLAGS` environment variable (e.g. `RUSTFLAGS='--emit=llvm-ir'`). This causes rustc to spit out LLVM IR into the target directory. From 58f3730c0ee8ef193c023f20a9a7786aea062b4a Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Mon, 16 Sep 2019 09:37:02 -0400 Subject: [PATCH 0669/1812] typo fix (#444) that would get compile to => that would get compiled to --- src/mir/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/index.md b/src/mir/index.md index 9e9f933fe..da221a0d8 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -185,7 +185,7 @@ only reference places and constants. Moreover, when you use a place, we indicate whether we are **copying it** (which requires that the place have a type `T` where `T: Copy`) or **moving it** (which works for a place of any type). So, for example, if we had the expression `x -= a + b + c` in Rust, that would get compile to two statements and a += a + b + c` in Rust, that would get compiled to two statements and a temporary: ```mir From 74d3b788ee51467b47bee2f99b167b4beb760c5a Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Mon, 16 Sep 2019 16:34:03 -0400 Subject: [PATCH 0670/1812] minor typo fixes (#445) * typo fix how to expose the them to any sort of external testing apparatus => how to expose them to any sort of external testing apparatus * typo fix These following image depicts => The following image depicts * typo fix trait itself is found in in => trait itself is found in * Update src/mir/passes.md following JohnTitor's suggestion Co-Authored-By: Yuki Okushi * Update src/test-implementation.md Also following JohnTitor's suggestion Co-Authored-By: Yuki Okushi --- src/mir/construction.md | 2 +- src/mir/passes.md | 2 +- src/test-implementation.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 0e0bf35e7..35d68ad73 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -92,7 +92,7 @@ There are essentially four kinds of representations one might want of an express * `Operand` is an argument to e.g. a `+` operation or a function call * a temporary variable containing a copy of the value -These following image depicts a general overview of the interactions between the +The following image depicts a general overview of the interactions between the representations: diff --git a/src/mir/passes.md b/src/mir/passes.md index a0de3ae0e..b847584b1 100644 --- a/src/mir/passes.md +++ b/src/mir/passes.md @@ -27,7 +27,7 @@ where we want to access the MIR for type checking or other purposes: A `MirPass` is some bit of code that processes the MIR, typically – but not always – transforming it along the way somehow. For example, it might perform an optimization. The `MirPass` trait itself is found -in in [the `rustc_mir::transform` module][mirtransform], and it +in [the `rustc_mir::transform` module][mirtransform], and it basically consists of one method, `run_pass`, that simply gets an `&mut Mir` (along with the tcx and some information about where it came from). The MIR is therefore modified in place (which helps to diff --git a/src/test-implementation.md b/src/test-implementation.md index 969d6d2e4..59cc7c5bd 100644 --- a/src/test-implementation.md +++ b/src/test-implementation.md @@ -25,7 +25,7 @@ mod my_priv_mod { } ``` Private items can thus be easily tested without worrying about how to expose -the them to any sort of external testing apparatus. This is key to the +them to any sort of external testing apparatus. This is key to the ergonomics of testing in Rust. Semantically, however, it's rather odd. How does any sort of `main` function invoke these tests if they're not visible? What exactly is `rustc --test` doing? From 733c435f169ddf10f7aea62f85b34004a1f805ec Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 18 Sep 2019 07:50:39 -0500 Subject: [PATCH 0671/1812] add some instructions to fix toolstate (#446) --- README.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/README.md b/README.md index 064f80c6e..fc9a06a8c 100644 --- a/README.md +++ b/README.md @@ -41,3 +41,31 @@ be found. You will need `mdbook` version `>= 0.2`. `linkcheck` will be run automatically when you run `mdbook build`. + +## How to fix toolstate failures + +1. You will get a ping from the toolstate commit. e.g. https://github.com/rust-lang-nursery/rust-toolstate/commit/8ffa0e4c30ac9ba8546b7046e5c4ccc2b96ebdd4 + +2. The commit contains a link to the PR that caused the breakage. e.g. https://github.com/rust-lang/rust/pull/64321 + +3. If you go to that PR's thread, there is a post from bors with a link to the CI status: https://github.com/rust-lang/rust/pull/64321#issuecomment-529763807 + +4. Follow the check-azure link to get to the Azure website for that build: https://dev.azure.com/rust-lang/e71b0ddf-dd27-435a-873c-e30f86eea377/_build/results?buildId=7780 + +5. There will be approximately 1 billion different jobs for the build. They are for different configurations and platforms. The rustc-guide build only runs on the Linux x86_64-gnu-tools job. So click on that job in the list, which is about 60% down in the list. + +6. Click the Run build step in the job to get the console log for the step. + +7. Click on the log and Ctrl-f to get a search box in the log + +8. Search for rustc-guide. This gets you to the place where the links are checked. It is usually ~11K lines into the log + +9. Look at the links in the log near that point in the log + +10. Fix those links in the rustc-guide (by making a PR in the rustc-guide repo) + +11. Make a PR on the rust-lang/rust repo to update the rustc-guide git submodule in src/docs/rustc-guide + +12. Wait for PR to merge + +Voila! From 2d5a47f2cd450892682d50a86b2416f43c90e2a5 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 19 Sep 2019 00:14:59 +0900 Subject: [PATCH 0672/1812] Add guidance for making a PR fixes toolstate --- README.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index fc9a06a8c..42e7e44a4 100644 --- a/README.md +++ b/README.md @@ -64,7 +64,17 @@ when you run `mdbook build`. 10. Fix those links in the rustc-guide (by making a PR in the rustc-guide repo) -11. Make a PR on the rust-lang/rust repo to update the rustc-guide git submodule in src/docs/rustc-guide +11. Make a PR on the rust-lang/rust repo to update the rustc-guide git submodule in src/docs/rustc-guide. +To make a PR, the following steps are useful. + +```bash +# Assuming you already cloned the rust-lang/rust repo and you're in the correct directory +git submodule update --remote src/doc/rustc-guide +git add -u +git commit -m "Update rustc-guide" +./x.py test -i --stage 1 src/doc/rustc-guide # This is optional and should succeed anyway +# Open a PR in rust-lang/rust +``` 12. Wait for PR to merge From cc34e4a4c9fbaf2ca0d501e87c84c31943539362 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Fri, 20 Sep 2019 14:08:46 -0500 Subject: [PATCH 0673/1812] Update the "Updating LLVM" documentation (#451) Make sure existing sections are up-to-date and then also add some words about the recent convention we developed for updating LLVM versions with respect to branch naming as well. --- src/codegen/updating-llvm.md | 90 +++++++++++++++++++++++++----------- 1 file changed, 63 insertions(+), 27 deletions(-) diff --git a/src/codegen/updating-llvm.md b/src/codegen/updating-llvm.md index 50dc94962..015514bab 100644 --- a/src/codegen/updating-llvm.md +++ b/src/codegen/updating-llvm.md @@ -17,23 +17,26 @@ policy!), but for now these are rough guidelines! ## Why update LLVM? -There are two primary reasons nowadays that we want to update LLVM in one way or +There are a few reasons nowadays that we want to update LLVM in one way or another: -* First, a bug could have been fixed! Often we find bugs in the compiler and fix +* A bug could have been fixed! Often we find bugs in the compiler and fix them upstream in LLVM. We'll want to pull fixes back to the compiler itself as they're merged upstream. -* Second, a new feature may be available in LLVM that we want to use in rustc, +* A new feature may be available in LLVM that we want to use in rustc, but we don't want to wait for a full LLVM release to test it out. +* LLVM itself may have a new release and we'd like to update to this LLVM + release. + Each of these reasons has a different strategy for updating LLVM, and we'll go -over both in detail here. +over them in detail here. ## Bugfix Updates -For updates of LLVM that typically just update a bug, we cherry-pick the bugfix -to the branch we're already using. The steps for this are: +For updates of LLVM that are to fix a small bug, we cherry-pick the bugfix to +the branch we're already using. The steps for this are: 1. Make sure the bugfix is in upstream LLVM. 2. Identify the branch that rustc is currently using. The `src/llvm-project` @@ -43,10 +46,13 @@ to the branch we're already using. The steps for this are: 4. Check out the appropriate branch (typically named `rustc/a.b-yyyy-mm-dd`) 5. Cherry-pick the upstream commit onto the branch 6. Push this branch to your fork -7. Send a Pull Request to rust-lang/llvm-project to the same branch as before +7. Send a Pull Request to rust-lang/llvm-project to the same branch as before. + Be sure to reference the Rust and/or LLVM issue that you're fixing in the PR + description. 8. Wait for the PR to be merged 9. Send a PR to rust-lang/rust updating the `src/llvm-project` submodule with - your bugfix + your bugfix. This can be done locally with `git submodule update --remote + src/llvm-project` typically. 10. Wait for PR to be merged The tl;dr; is that we can cherry-pick bugfixes at any time and pull them back @@ -70,7 +76,8 @@ through each in detail. 1. Create a new branch in the rust-lang/llvm-project repository. This branch should be named `rustc/a.b-yyyy-mm-dd` where `a.b` is the current version number of LLVM in-tree at the time of the branch and the remaining part is - today's date. + today's date. Move this branch to the commit in LLVM that you'd like, which + for this is probably the current LLVM HEAD. 2. Apply Rust-specific patches to the llvm-project repository. All features and bugfixes are upstream, but there's often some weird build-related patches @@ -78,20 +85,12 @@ through each in detail. patches are around the latest patches in the rust-lang/llvm-project branch that rustc is currently using. -3. Update the `compiler-rt` submodule in the - `rust-lang-nursery/compiler-builtins` repository. Push this update to the - same branch name of the `llvm-project` submodule to the - of the `rust-lang/compiler-rt` repository. Then push this update to a branch - of `compiler-builtins` with the same-named branch. Note that this step is - frequently optional since we may not need to update `compiler-rt`. - -4. Prepare a commit to rust-lang/rust - - * Update `src/llvm-project` - * Update `compiler-builtins` crate in `Cargo.lock` (if necessary) - -5. Build your commit. Make sure you've committed the previous changes to ensure - submodule updates aren't reverted. Some commands you should execute are: +3. Build the new LLVM in the `rust` repository. To do this you'll want to update + the `src/llvm-project` repository to your branch and the revision you've + created. It's also typically a good idea to update `.gitmodules` with the new + branch name of the LLVM submodule. Make sure you've committed changes to + `src/llvm-project` to ensure submodule updates aren't reverted. Some commands + you should execute are: * `./x.py build src/llvm` - test that LLVM still builds * `./x.py build src/tools/lld` - same for LLD @@ -101,7 +100,7 @@ through each in detail. LLVM bindings. Note that you should use `#ifdef` and such to ensure that the bindings still compile on older LLVM versions. -6. Test for regressions across other platforms. LLVM often has at least one bug +4. Test for regressions across other platforms. LLVM often has at least one bug for non-tier-1 architectures, so it's good to do some more testing before sending this to bors! If you're low on resources you can send the PR as-is now to bors, though, and it'll get tested anyway. @@ -120,11 +119,20 @@ through each in detail. * `./src/ci/docker/run.sh dist-various-2` * `./src/ci/docker/run.sh armhf-gnu` -7. Send a PR! Hopefully it's smooth sailing from here :). +5. Prepare a PR to `rust-lang/rust`. Work with maintainers of + `rust-lang/llvm-project` to get your commit in a branch of that repository, + and then you can send a PR to `rust-lang/rust`. You'll change at least + `src/llvm-project` and will likely also change `src/rustllvm/*` as well. For prior art, previous LLVM updates look like [#55835](https://github.com/rust-lang/rust/pull/55835) [#47828](https://github.com/rust-lang/rust/pull/47828) +[#62474](https://github.com/rust-lang/rust/pull/62474) +[#62592](https://github.com/rust-lang/rust/pull/62592). Note that sometimes it's +easiest to land `src/rustllvm/*` compatibility as a PR before actually updating +`src/llvm-project`. This way while you're working through LLVM issues others +interested in trying out the new LLVM can benefit from work you've done to +update the C++ bindings. ### Caveats and gotchas @@ -134,8 +142,36 @@ keep in mind while going through them: * LLVM bugs are hard to find, don't hesitate to ask for help! Bisection is definitely your friend here (yes LLVM takes forever to build, yet bisection is still your friend) -* Updating LLDB has some Rust-specific patches currently that aren't upstream. - If you have difficulty @tromey can likely help out. * If you've got general questions, @alexcrichton can help you out. * Creating branches is a privileged operation on GitHub, so you'll need someone with write access to create the branches for you most likely. + +## New LLVM Release Updates + +Updating to a new release of LLVM is very similar to the "feature updates" +section above. The release process for LLVM is often months-long though and we +like to ensure compatibility ASAP. The main tweaks to the "feature updates" +section above is generally around branch naming. The sequence of events +typically looks like: + +1. LLVM announces that its latest release version has branched. This will show + up as a branch in https://github.com/llvm/llvm-project typically named + `release/$N.x` where `$N` is the version of LLVM that's being released. + +2. We then follow the "feature updates" section above to create a new branch of + LLVM in our rust-lang/llvm-project repository. This follows the same naming + convention of branches as usual, except that `a.b` is the new version. This + update is eventually landed in the rust-lang/rust repository. + +3. Over the next few months, LLVM will continually push commits to its + `release/a.b` branch. Often those are bug fixes we'd like to have as well. + The merge process for that is to use `git merge` itself to merge LLVM's + `release/a.b` branch with the branch created in step 2. This is typically + done multiple times when necessary while LLVM's release branch is baking. + +4. LLVM then announces the release of version `a.b`. + +5. After LLVM's official release, we follow the "feature update" section again + to create a new branch in the rust-lang/llvm-project repository, this time + with a new date. The commit history should look much cleaner as just a few + Rust-specific commits stacked on top of stock LLVM's release branch. From 7bed7de9188c281f3d3a929d8ede88a491122f7e Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 25 Sep 2019 21:29:26 +0200 Subject: [PATCH 0674/1812] file has since been removed from content (#453) Should of been part of 2ef961e45465a5edfbd3d5c49e4a16cee356b44b --- src/SUMMARY.md | 1 - src/diagnostics/json-format.md | 0 2 files changed, 1 deletion(-) delete mode 100644 src/diagnostics/json-format.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f672df510..b5f1bba25 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -23,7 +23,6 @@ - [Coding conventions](./conventions.md) - [crates.io Dependencies](./crates-io.md) - [Emitting Errors and other Diagnostics](diagnostics.md) - - [JSON diagnostic format](diagnostics/json-format.md) - [Part 2: How rustc works](./part-2-intro.md) - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver and Interface](./rustc-driver.md) diff --git a/src/diagnostics/json-format.md b/src/diagnostics/json-format.md deleted file mode 100644 index e69de29bb..000000000 From 9d1ffd3a0eb58d7f70c876503c3e22d8381131ac Mon Sep 17 00:00:00 2001 From: lzutao Date: Mon, 30 Sep 2019 21:26:27 +0700 Subject: [PATCH 0675/1812] Prefer https in GitHub pages urls (#454) --- src/appendix/bibliography.md | 4 ++-- src/borrow_check.md | 2 +- src/borrow_check/region_inference.md | 2 +- src/mir/index.md | 2 +- src/traits/chalk-overview.md | 16 ++++++++-------- src/traits/slg.md | 2 +- 6 files changed, 14 insertions(+), 14 deletions(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index 03ba3a41c..c3d0446c7 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -31,7 +31,7 @@ Rust, as well as publications about Rust. * [Balanced work stealing for time-sharing multicores](http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-12-1.pdf) * [Three layer cake for shared-memory programming](http://dl.acm.org/citation.cfm?id=1953616&dl=ACM&coll=DL&CFID=524387192&CFTOKEN=44362705) * [Non-blocking steal-half work queues](http://www.cs.bgu.ac.il/%7Ehendlerd/papers/p280-hendler.pdf) -* [Reagents: expressing and composing fine-grained concurrency](http://aturon.github.io/academic/reagents.pdf) +* [Reagents: expressing and composing fine-grained concurrency](https://aturon.github.io/academic/reagents.pdf) * [Algorithms for scalable synchronization of shared-memory multiprocessors](https://www.cs.rochester.edu/u/scott/papers/1991_TOCS_synch.pdf) * [Epoch-based reclamation](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf). @@ -59,7 +59,7 @@ Rust, as well as publications about Rust. Rust](https://michaelsproul.github.io/rust_radix_paper/rust-radix-sproul.pdf). Undergrad paper by Michael Sproul. * [Reenix: Implementing a Unix-Like Operating System in - Rust](http://scialex.github.io/reenix.pdf). Undergrad paper by Alex + Rust](https://scialex.github.io/reenix.pdf). Undergrad paper by Alex Light. * [Evaluation of performance and productivity metrics of potential programming languages in the HPC environment](https://github.com/1wilkens/thesis-ba). Bachelor's thesis by Florian Wilkens. Compares C, Go and Rust. diff --git a/src/borrow_check.md b/src/borrow_check.md index b3864aac4..0ceb21d72 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -27,7 +27,7 @@ Doing borrow checking on MIR has several advantages: which are regions derived from the control-flow graph. [47366]: https://github.com/rust-lang/rust/issues/47366 -[nll]: http://rust-lang.github.io/rfcs/2094-nll.html +[nll]: https://rust-lang.github.io/rfcs/2094-nll.html ### Major phases of the borrow checker diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 216128ffb..a524fe0f0 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -42,7 +42,7 @@ The MIR-based region analysis consists of two major functions: [`compute_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.compute_regions.html [`RegionInferenceContext`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html [`solve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.solve -[NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html +[NLL RFC]: https://rust-lang.github.io/rfcs/2094-nll.html [MIR type checker]: ./type_check.md ## Universal regions diff --git a/src/mir/index.md b/src/mir/index.md index da221a0d8..c02b86e9a 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -18,7 +18,7 @@ graphs and desugaring), you may enjoy the MIR is defined in the [`src/librustc/mir/`][mir] module, but much of the code that manipulates it is found in [`src/librustc_mir`][mirmanip]. -[RFC 1211]: http://rust-lang.github.io/rfcs/1211-mir.html +[RFC 1211]: https://rust-lang.github.io/rfcs/1211-mir.html Some of the key characteristics of MIR are: diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 0a95585f6..7eb648043 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -211,7 +211,7 @@ Likewise, lowering tests use the [`lowering_success!` and * [Lowering Rust traits to logic](http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/) * [Unification in Chalk, part 1](http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/) * [Unification in Chalk, part 2](http://smallcultfollowing.com/babysteps/blog/2017/04/23/unification-in-chalk-part-2/) -* [Negative reasoning in Chalk](http://aturon.github.io/blog/2017/04/24/negative-chalk/) +* [Negative reasoning in Chalk](https://aturon.github.io/blog/2017/04/24/negative-chalk/) * [Query structure in chalk](http://smallcultfollowing.com/babysteps/blog/2017/05/25/query-structure-in-chalk/) * [Cyclic queries in chalk](http://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/) * [An on-demand SLG solver for chalk](http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/) @@ -230,7 +230,7 @@ Likewise, lowering tests use the [`lowering_success!` and [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification [`ProgramClause`]: https://rust-lang.github.io/chalk/doc/chalk_ir/enum.ProgramClause.html -[`ProgramEnvironment`]: http://rust-lang.github.io/chalk/doc/chalk/program_environment/struct.ProgramEnvironment.html +[`ProgramEnvironment`]: https://rust-lang.github.io/chalk/doc/chalk/program_environment/struct.ProgramEnvironment.html [chalk_engine]: https://rust-lang.github.io/chalk/doc/chalk_engine/index.html [chalk_ir]: https://rust-lang.github.io/chalk/doc/chalk_ir/index.html [chalk_parse]: https://rust-lang.github.io/chalk/doc/chalk_parse/index.html @@ -238,19 +238,19 @@ Likewise, lowering tests use the [`lowering_success!` and [chalk_rust_ir]: https://rust-lang.github.io/chalk/doc/chalk_rust_ir/index.html [doc-chalk]: https://rust-lang.github.io/chalk/doc/chalk/index.html [engine-context]: https://rust-lang.github.io/chalk/doc/chalk_engine/context/index.html -[chalk-program]: http://rust-lang.github.io/chalk/doc/chalk/program/struct.Program.html +[chalk-program]: https://rust-lang.github.io/chalk/doc/chalk/program/struct.Program.html -[binders-struct]: http://rust-lang.github.io/chalk/doc/chalk_ir/struct.Binders.html -[chalk-ast]: http://rust-lang.github.io/chalk/doc/chalk_parse/ast/index.html +[binders-struct]: https://rust-lang.github.io/chalk/doc/chalk_ir/struct.Binders.html +[chalk-ast]: https://rust-lang.github.io/chalk/doc/chalk_parse/ast/index.html [chalk-test-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 [chalk-test-lowering-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs#L8-L31 [chalk-test-lowering]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs [chalk-test-wf]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf/test.rs#L1 [chalki]: https://rust-lang.github.io/chalk/doc/chalki/index.html [clause]: https://github.com/rust-lang/chalk/blob/master/GLOSSARY.md#clause -[coherence-src]: http://rust-lang.github.io/chalk/doc/chalk_solve/coherence/index.html -[ir-code]: http://rust-lang.github.io/chalk/doc/chalk_rust_ir/ -[solve-wf-src]: http://rust-lang.github.io/chalk/doc/chalk_solve/wf/index.html +[coherence-src]: https://rust-lang.github.io/chalk/doc/chalk_solve/coherence/index.html +[ir-code]: https://rust-lang.github.io/chalk/doc/chalk_rust_ir/ +[solve-wf-src]: https://rust-lang.github.io/chalk/doc/chalk_solve/wf/index.html [solve_goal]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L85 [test-lowering-macros]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test_util.rs#L21-L54 [test-macro]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L33 diff --git a/src/traits/slg.md b/src/traits/slg.md index 948d3fc8a..6fec79fde 100644 --- a/src/traits/slg.md +++ b/src/traits/slg.md @@ -299,4 +299,4 @@ more answers later on. [readme]: https://github.com/rust-lang/chalk/blob/239e4ae4e69b2785b5f99e0f2b41fc16b0b4e65e/chalk-engine/src/README.md [slg-blog]: http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/ -[negative-reasoning-blog]: http://aturon.github.io/blog/2017/04/24/negative-chalk/ +[negative-reasoning-blog]: https://aturon.github.io/blog/2017/04/24/negative-chalk/ From 02d96fdcd8c8bff5371827b20a30dcd3dd47bbbe Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Tue, 1 Oct 2019 13:39:49 +0200 Subject: [PATCH 0676/1812] issues/issue-12345.rs is an anti-pattern (#456) --- src/tests/adding.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index a660d26b5..8492cbbcc 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -49,12 +49,13 @@ considered an ideal setup. [`src/test/ui`]: https://github.com/rust-lang/rust/tree/master/src/test/ui/ For regression tests – basically, some random snippet of code that -came in from the internet – we often just name the test after the -issue. For example, `src/test/ui/issue-12345.rs`. If possible, -though, it is better if you can put the test into a directory that -helps identify what piece of code is being tested here (e.g., -`borrowck/issue-12345.rs` is much better), or perhaps give it a more -meaningful name. Still, **do include the issue number somewhere**. +came in from the internet – we often name the test after the issue +plus a short description. Ideally, the test should be added to a +directory that helps identify what piece of code is being tested here +(e.g., `src/test/ui/borrowck/issue-54597-reject-move-out-of-borrow-via-pat.rs`) +If you've tried and cannot find a more relevant place, +the test may be added to `src/test/ui/issues/`. +Still, **do include the issue number somewhere**. When writing a new feature, **create a subdirectory to store your tests**. For example, if you are implementing RFC 1234 ("Widgets"), From 7f27d2150e2600e1f2a6da7a44d3e2827af3ed59 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Tue, 1 Oct 2019 13:40:58 +0200 Subject: [PATCH 0677/1812] Update feature gating docs to fit reality (#455) --- src/implementing_new_features.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 6d1327fab..0051dadcf 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -35,7 +35,7 @@ of concept so that people can see what you are talking about. That starts a "proposed final comment period" (pFCP), which requires all members of the team to sign off the FCP. After they all do so, -there's a week long "final comment period" where everybody can comment, +there's a 10 day long "final comment period" where everybody can comment, and if no new concerns are raised, the PR/issue gets FCP approval. ## The logistics of writing features @@ -119,10 +119,13 @@ a new unstable feature: 1. Open a [tracking issue] - if you have an RFC, you can use the tracking issue for the RFC. + The tracking issue should be labeled with at least `C-tracking-issue`. + For a language feature, a label `F-feature_name` should be added as well. + 2. Pick a name for the feature gate (for RFCs, use the name in the RFC). -3. Add a feature gate declaration to `libsyntax/feature_gate.rs` +3. Add a feature gate declaration to `libsyntax/active.rs` in the active `declare_features` block: ```rust,ignore @@ -140,8 +143,8 @@ For example: ( active, match_beginning_vert, "1.21.0", Some(44101), None), ``` -The current version is not actually important – the important -version is when you are stabilizing a feature. +When added, the current version should be the one for the current nightly. +Once the feature is moved to `accepted.rs`, the version is changed to that nightly version. 4. Prevent usage of the new feature unless the feature gate is set. You can check it in most places in the compiler using the @@ -153,10 +156,14 @@ version is when you are stabilizing a feature. the pre-feature behavior or raise an error, depending on what makes sense. + For features introducing new syntax, pre-expansion gating should be used instead. + To do so, extend the [`GatedSpans`] struct, add spans to it during parsing, + and then finally feature-gate all the spans in [`feature_gate::check::check_crate`]. + 5. Add a test to ensure the feature cannot be used without a feature gate, by creating `feature-gate-$feature_name.rs` and `feature-gate-$feature_name.stderr` files under the - `src/test/ui/feature-gates` directory. + directory where the other tests for your feature reside. 6. Add a section to the unstable book, in `src/doc/unstable-book/src/language-features/$feature_name.md`. @@ -167,6 +174,8 @@ version is when you are stabilizing a feature. 8. Get your PR reviewed and land it. You have now successfully implemented a feature in Rust! +[`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.GatedSpans.html +[`feature_gate::check::check_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/check/fn.check_crate.html [value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md [stability in code]: #stability-in-code [here]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html From fbe1a9a0c26fe94273361031b8cc0801d4bfa5ab Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 2 Oct 2019 18:25:14 +0200 Subject: [PATCH 0678/1812] codegen unit is aka CGU (#459) --- src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 3375d035f..d9867023e 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -10,7 +10,7 @@ AST | the abstract syntax tree produced by the syntax crate binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen | the code to translate MIR into LLVM IR. -codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units. Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. +codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) CTFE | Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) From 37b288edd9e3d37626d0423994d2bb8bcf399540 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 2 Oct 2019 18:25:56 +0200 Subject: [PATCH 0679/1812] fix chalk links (#457) * whitespace * update links --- src/macro-expansion.md | 8 ++++---- src/traits/chalk-overview.md | 34 +++++++++++++++++----------------- src/traits/slg.md | 14 +++++++------- 3 files changed, 28 insertions(+), 28 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index bb429282f..f6a9b3b1f 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -205,8 +205,8 @@ TODO TODO: maybe something about macros 2.0? -[code_dir]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/tt -[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/tt/macro_parser/ -[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/tt/macro_rules/ -[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/tt/macro_parser/fn.parse.html +[code_dir]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/mbe +[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/mbe/macro_parser +[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/mbe/macro_rules +[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/mbe/macro_parser/fn.parse.html [parsing]: ./the-parser.html diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 7eb648043..a29939919 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -229,28 +229,28 @@ Likewise, lowering tests use the [`lowering_success!` and [rustc-issues]: https://github.com/rust-lang/rustc-guide/issues [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification -[`ProgramClause`]: https://rust-lang.github.io/chalk/doc/chalk_ir/enum.ProgramClause.html -[`ProgramEnvironment`]: https://rust-lang.github.io/chalk/doc/chalk/program_environment/struct.ProgramEnvironment.html -[chalk_engine]: https://rust-lang.github.io/chalk/doc/chalk_engine/index.html -[chalk_ir]: https://rust-lang.github.io/chalk/doc/chalk_ir/index.html -[chalk_parse]: https://rust-lang.github.io/chalk/doc/chalk_parse/index.html -[chalk_solve]: https://rust-lang.github.io/chalk/doc/chalk_solve/index.html -[chalk_rust_ir]: https://rust-lang.github.io/chalk/doc/chalk_rust_ir/index.html -[doc-chalk]: https://rust-lang.github.io/chalk/doc/chalk/index.html -[engine-context]: https://rust-lang.github.io/chalk/doc/chalk_engine/context/index.html -[chalk-program]: https://rust-lang.github.io/chalk/doc/chalk/program/struct.Program.html - -[binders-struct]: https://rust-lang.github.io/chalk/doc/chalk_ir/struct.Binders.html -[chalk-ast]: https://rust-lang.github.io/chalk/doc/chalk_parse/ast/index.html +[`ProgramClause`]: https://rust-lang.github.io/chalk/chalk_ir/enum.ProgramClause.html +[`ProgramEnvironment`]: https://rust-lang.github.io/chalk/chalk/program_environment/struct.ProgramEnvironment.html +[chalk_engine]: https://rust-lang.github.io/chalk/chalk_engine +[chalk_ir]: https://rust-lang.github.io/chalk/chalk_ir/index.html +[chalk_parse]: https://rust-lang.github.io/chalk/chalk_parse/index.html +[chalk_solve]: https://rust-lang.github.io/chalk/chalk_solve/index.html +[chalk_rust_ir]: https://rust-lang.github.io/chalk/chalk_rust_ir/index.html +[doc-chalk]: https://rust-lang.github.io/chalk/chalk/index.html +[engine-context]: https://rust-lang.github.io/chalk/chalk_engine/context/index.html +[chalk-program]: https://rust-lang.github.io/chalk/chalk/program/struct.Program.html + +[binders-struct]: https://rust-lang.github.io/chalk/chalk_ir/struct.Binders.html +[chalk-ast]: https://rust-lang.github.io/chalk/chalk_parse/ast/index.html [chalk-test-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 [chalk-test-lowering-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs#L8-L31 [chalk-test-lowering]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs [chalk-test-wf]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf/test.rs#L1 -[chalki]: https://rust-lang.github.io/chalk/doc/chalki/index.html +[chalki]: https://rust-lang.github.io/chalk/chalki/index.html [clause]: https://github.com/rust-lang/chalk/blob/master/GLOSSARY.md#clause -[coherence-src]: https://rust-lang.github.io/chalk/doc/chalk_solve/coherence/index.html -[ir-code]: https://rust-lang.github.io/chalk/doc/chalk_rust_ir/ -[solve-wf-src]: https://rust-lang.github.io/chalk/doc/chalk_solve/wf/index.html +[coherence-src]: https://rust-lang.github.io/chalk/chalk_solve/coherence/index.html +[ir-code]: https://rust-lang.github.io/chalk/chalk_rust_ir/ +[solve-wf-src]: https://rust-lang.github.io/chalk/chalk_solve/wf/index.html [solve_goal]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L85 [test-lowering-macros]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test_util.rs#L21-L54 [test-macro]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L33 diff --git a/src/traits/slg.md b/src/traits/slg.md index 6fec79fde..74ec89fa0 100644 --- a/src/traits/slg.md +++ b/src/traits/slg.md @@ -47,7 +47,7 @@ well as the various *strands*, which are basically suspended computations that may be used to find more answers. Tables are interdependent: solving one query may require solving others. -[`Forest`]: https://rust-lang.github.io/chalk/doc/chalk_engine/forest/struct.Forest.html +[`Forest`]: https://rust-lang.github.io/chalk/chalk_engine/forest/struct.Forest.html ### Walkthrough @@ -126,7 +126,7 @@ literals and region constraints, an X-clause just looks like this: ```text G :- L ``` - + where G is a goal and L is a set of subgoals that must be proven. (The L stands for *literal* -- when we address negative reasoning, a literal will be either a positive or negative subgoal.) The idea is @@ -150,7 +150,7 @@ is the subgoal after the turnstile (`:-`) that we are currently trying to prove in this strand. Initially, when a strand is first created, there is no selected subgoal. -[`ExClause`]: https://rust-lang.github.io/chalk/doc/chalk_engine/struct.ExClause.html +[`ExClause`]: https://rust-lang.github.io/chalk/chalk_engine/struct.ExClause.html **Activating a strand.** Now that we have created the table T0 and initialized it with strands, we have to actually try and produce an answer. @@ -182,12 +182,12 @@ the state of the strand to: ```text (Rc: Debug) :- selected(?T: Debug, A0) ``` - + Here, we write `selected(L, An)` to indicate that (a) the literal `L` is the selected subgoal and (b) which answer `An` we are looking for. We start out looking for `A0`. -[`ensure_root_answer`]: https://rust-lang.github.io/chalk/doc/chalk_engine/forest/struct.Forest.html#method.ensure_root_answer +[`ensure_root_answer`]: https://rust-lang.github.io/chalk/chalk_engine/forest/struct.Forest.html#method.ensure_root_answer **Processing the selected subgoal.** Next, we have to try and find an answer to this selected goal. To do that, we will u-canonicalize it @@ -210,14 +210,14 @@ follows: Table T0 [Rc: Debug] Strands: (Rc: Debug) :- selected(?T: Debug, A0) - + Table T1 [?0: Debug] Strands: (u32: Debug) :- (Vec: Debug) :- (?U: Debug) (Rc: Debug) :- (?V: Debug) ``` - + **Delegation between tables.** Now that the active strand from T0 has created the table T1, it can try to extract an answer. It does this via that same `ensure_answer` operation we saw before. In this case, From b71b2a552f6746c8408832e2356e9fb94badc4c2 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 2 Oct 2019 16:18:28 -0400 Subject: [PATCH 0680/1812] create guide to ICE-breaker groups and specifically advice for LLVM (#452) --- src/SUMMARY.md | 2 ++ src/codegen/debugging.md | 46 +++++++++++++++++++++++++++++++++++++++- src/ice-breaker/about.md | 37 ++++++++++++++++++++++++++++++++ src/ice-breaker/llvm.md | 31 +++++++++++++++++++++++++++ 4 files changed, 115 insertions(+), 1 deletion(-) create mode 100644 src/ice-breaker/about.md create mode 100644 src/ice-breaker/llvm.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b5f1bba25..b65ba4c74 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -23,6 +23,8 @@ - [Coding conventions](./conventions.md) - [crates.io Dependencies](./crates-io.md) - [Emitting Errors and other Diagnostics](diagnostics.md) + - [ICE-breaker teams](ice-breaker/about.md) + - [LLVM ICE-breakers](ice-breaker/llvm.md) - [Part 2: How rustc works](./part-2-intro.md) - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver and Interface](./rustc-driver.md) diff --git a/src/codegen/debugging.md b/src/codegen/debugging.md index a6ad91dd1..1f38c9eee 100644 --- a/src/codegen/debugging.md +++ b/src/codegen/debugging.md @@ -94,6 +94,36 @@ $ ./build/$TRIPLE/llvm/bin/llvm-extract \ > extracted.ll ``` +### Getting help and asking questions + +If you have some questions, head over to the [rust-lang Zulip] and +specifically the `#t-compiler/wg-llvm` stream. + +[rust-lang Zulip]: https://rust-lang.zulipchat.com/ + +### Compiler options to know and love + +The `-Chelp` and `-Zhelp` compiler switches will list out a variety +of interesting options you may find useful. Here are a few of the most +common that pertain to LLVM development (some of them are employed in the +tutorial above): + +- The `--emit llvm-ir` option emits a `.ll` file with LLVM IR in textual format + - The `--emit llvm-bc` option emits in bytecode format (`.bc`) +- Passing `-Cllvm-arg=` allows passing pretty much all the + options that tools like llc and opt would accept; + e.g. `-Cllvm-arg=-print-before-all` to print IR before every LLVM + pass. +- The `-Cno-prepopulate-passes` will avoid pre-populate the LLVM pass + manager with a list of passes. This will allow you to view the LLVM + IR that rustc generates, not the LLVM IR after optimizations. +- The `-Cpasses=val` option allows you to supply a (space seprated) list of extra LLVM passes to run +- The `-Csave-temps` option saves all temporary output files during compilation +- The `-Zprint-llvm-passes` option will print out LLVM optimization passes being run +- The `-Ztime-llvm-passes` option measures the time of each LLVM pass +- The `-Zverify-llvm-ir` option will verify the LLVM IR for correctness +- The `-Zno-parallel-llvm` will disable parallel compilation of distinct compilation units + ### Filing LLVM bug reports When filing an LLVM bug report, you will probably want some sort of minimal @@ -119,4 +149,18 @@ create a minimal working example with Godbolt. Go to optimizations transform it. 5. Once you have a godbolt link demonstrating the issue, it is pretty easy to - fill in an LLVM bug. + fill in an LLVM bug. Just visit [bugs.llvm.org](https://bugs.llvm.org/). + +### Porting bug fixes from LLVM + +Once you've identified the bug as an LLVM bug, you will sometimes +find that it has already been reported and fixed in LLVM, but we haven't +gotten the fix yet (or perhaps you are familiar enough with LLVM to fix it yourself). + +In that case, we can sometimes opt to port the fix for the bug +directly to our own LLVM fork, so that rustc can use it more easily. +Our fork of LLVM is maintained in [rust-lang/llvm-project]. Once +you've landed the fix there, you'll also need to land a PR modifying +our submodule commits -- ask around on Zulip for help. + +[rust-lang/llvm-project]: https://github.com/rust-lang/llvm-project/ diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md new file mode 100644 index 000000000..ab9c66789 --- /dev/null +++ b/src/ice-breaker/about.md @@ -0,0 +1,37 @@ +# ICE-breakers + +The **ICE-breaker groups** are an easy way to help out with rustc in a +"piece-meal" fashion, without committing to a larger project. +ICE-breaker groups are **[easy to join](#join)** (just submit a PR!) +and joining does not entail any particular commitment. + +Once you [join an ICE ICE-breaker group](#join), you will be added to +a list that receives pings on github whenever a new issue is found +that fits the ICE-breaker group's criteria. If you are interested, you +can then [claim the issue] and start working on it. + +Of course, you don't have to wait for new issues to be tagged! If you +prefer, you can use the Github label for an ICE-breaker group to +search for existing issues that haven't been claimed yet. + +## What issues are a good fit for ICE-breaker groups? + +"ICE-breaker issues" are intended to be **isolated** bugs of **middle +priority**: + +- By **isolated**, we mean that we do not expect large-scale refactoring + to be required to fix the bug. +- By **middle priority**, we mean that we'd like to see the bug fixed, + but it's not such a burning problem that we are dropping everything + else to fix it. The danger with such bugs, of course, is that they + can accumulate over time, and the role of the ICE-breaker groups is + to try and stop that from happening! + + + +## Joining an ICE-breaker group + +TBD -- we are building this mechanism right now! In the meantime, drop +in on Zulip and leave your github name in [this topic][topic]. + +[topic]: https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/llvm.20ice-breaker.20registration diff --git a/src/ice-breaker/llvm.md b/src/ice-breaker/llvm.md new file mode 100644 index 000000000..e0c90fdaf --- /dev/null +++ b/src/ice-breaker/llvm.md @@ -0,0 +1,31 @@ +# LLVM ICE-breakers + +**Github Label:** [ICEBreaker-LLVM] + +[ICEBreaker-LLVM]: https://github.com/rust-lang/rust/labels/ICEBreaker-LLVM + +The "LLVM ICE-breakers" are focused on bugs that center around LLVM. +These bugs often arise because of LLVM optimizations gone awry, or as +the result of an LLVM upgrade. The goal here is: + +- to determine whether the bug is a result of us generating invalid LLVM IR, + or LLVM misoptimizing; +- if the former, to fix our IR; +- if the latter, to try and file a bug on LLVM (or identify an existing bug). + +## Helpful tips and options + +The ["Debugging LLVM"][d] section of the +rustc-guide gives a step-by-step process for how to help debug bugs +caused by LLVM. In particular, it discusses how to emit LLVM IR, run +the LLVM IR optimization pipeliness, and so forth. You may also find +it useful to look at the various codegen options listed under `-Chelp` +and the internal options under `-Zhelp` -- there are a number that +pertain to LLVM (just search for LLVM). + +[d]: ../codegen/debugging.md + +## If you do narrow to an LLVM bug + +The ["Debugging LLVM"][d] section also describes what to do once +you've identified the bug. From fc8ea86c61f4e21289e9f5fc5359c6fafd7d6ae9 Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Tue, 1 Oct 2019 21:24:16 -0400 Subject: [PATCH 0681/1812] Removes timeout script so CI does not have false positives --- ci/build-ignore-timeouts.sh | 29 ----------------------------- 1 file changed, 29 deletions(-) delete mode 100755 ci/build-ignore-timeouts.sh diff --git a/ci/build-ignore-timeouts.sh b/ci/build-ignore-timeouts.sh deleted file mode 100755 index 3ec81f624..000000000 --- a/ci/build-ignore-timeouts.sh +++ /dev/null @@ -1,29 +0,0 @@ -#!/bin/bash -x - -output=$(mktemp) - -mkdir -p book/ -cp -r $HOME/linkcheck/ book/ -RUST_LOG=mdbook_linkcheck=debug mdbook-linkcheck -s 2>&1 | tee -a $output -cp -r book/linkcheck $HOME/ - -mdbook build - -result=${PIPESTATUS[0]} - -# if passed, great! -if [ "$result" -eq "0" ] ; then - exit 0 ; -fi - -errors=$(cat $output | sed -n 's/There \(was\|were\) \([0-9]\+\).*$/\2/p') -timeouts=$(cat $output | grep "error while fetching" | wc -l) - -# if all errors are timeouts, ignore them... -if [ "$errors" -eq "$timeouts" ] ; then - echo "Ignoring $timeouts timeouts"; - exit 0; -else - echo "Non-timeout errors found"; - exit 1; -fi From 4a25cfa4abacac033719b8f3d8109e5a1ff94d1e Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Tue, 1 Oct 2019 21:28:34 -0400 Subject: [PATCH 0682/1812] Removes timeout script call so CI does not have false pasitives --- .travis.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index c33c38b84..985ed093f 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,7 +12,6 @@ install: - source ~/.cargo/env || true - bash -x ci/install.sh script: -- bash -x ci/build-ignore-timeouts.sh - mdbook test notifications: email: From dbe31d4a337a17b3224d608ba10607446845adee Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 11:47:41 -0400 Subject: [PATCH 0683/1812] Revert "Removes timeout script call so CI does not have false pasitives" This reverts commit 5aa733097afa7d4b3ec67e4fb09b76c761f18d17. --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index 985ed093f..c33c38b84 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,6 +12,7 @@ install: - source ~/.cargo/env || true - bash -x ci/install.sh script: +- bash -x ci/build-ignore-timeouts.sh - mdbook test notifications: email: From 7b699b91a6a5b27ba05158128efeae1c6513d9ae Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 11:48:20 -0400 Subject: [PATCH 0684/1812] Revert "Removes timeout script so CI does not have false positives" This reverts commit c3ed0a1ef9013f2821eed24efcd9954600ce2b41. --- ci/build-ignore-timeouts.sh | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100755 ci/build-ignore-timeouts.sh diff --git a/ci/build-ignore-timeouts.sh b/ci/build-ignore-timeouts.sh new file mode 100755 index 000000000..3ec81f624 --- /dev/null +++ b/ci/build-ignore-timeouts.sh @@ -0,0 +1,29 @@ +#!/bin/bash -x + +output=$(mktemp) + +mkdir -p book/ +cp -r $HOME/linkcheck/ book/ +RUST_LOG=mdbook_linkcheck=debug mdbook-linkcheck -s 2>&1 | tee -a $output +cp -r book/linkcheck $HOME/ + +mdbook build + +result=${PIPESTATUS[0]} + +# if passed, great! +if [ "$result" -eq "0" ] ; then + exit 0 ; +fi + +errors=$(cat $output | sed -n 's/There \(was\|were\) \([0-9]\+\).*$/\2/p') +timeouts=$(cat $output | grep "error while fetching" | wc -l) + +# if all errors are timeouts, ignore them... +if [ "$errors" -eq "$timeouts" ] ; then + echo "Ignoring $timeouts timeouts"; + exit 0; +else + echo "Non-timeout errors found"; + exit 1; +fi From feb3229dbf724b5b55ea4b632e6e56531c96c147 Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 15:36:42 -0400 Subject: [PATCH 0685/1812] Fix (build CI script): * Removes timeout hack because it is not needed because we have upgraded mdbook_linkcheck * Renamed build script because it is no longer ignoring timeouts --- .travis.yml | 2 +- ci/build-ignore-timeouts.sh | 29 ----------------------------- ci/build.sh | 17 +++++++++++++++++ 3 files changed, 18 insertions(+), 30 deletions(-) delete mode 100755 ci/build-ignore-timeouts.sh create mode 100755 ci/build.sh diff --git a/.travis.yml b/.travis.yml index c33c38b84..dedec4568 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,7 +12,7 @@ install: - source ~/.cargo/env || true - bash -x ci/install.sh script: -- bash -x ci/build-ignore-timeouts.sh +- bash -x ci/build.sh - mdbook test notifications: email: diff --git a/ci/build-ignore-timeouts.sh b/ci/build-ignore-timeouts.sh deleted file mode 100755 index 3ec81f624..000000000 --- a/ci/build-ignore-timeouts.sh +++ /dev/null @@ -1,29 +0,0 @@ -#!/bin/bash -x - -output=$(mktemp) - -mkdir -p book/ -cp -r $HOME/linkcheck/ book/ -RUST_LOG=mdbook_linkcheck=debug mdbook-linkcheck -s 2>&1 | tee -a $output -cp -r book/linkcheck $HOME/ - -mdbook build - -result=${PIPESTATUS[0]} - -# if passed, great! -if [ "$result" -eq "0" ] ; then - exit 0 ; -fi - -errors=$(cat $output | sed -n 's/There \(was\|were\) \([0-9]\+\).*$/\2/p') -timeouts=$(cat $output | grep "error while fetching" | wc -l) - -# if all errors are timeouts, ignore them... -if [ "$errors" -eq "$timeouts" ] ; then - echo "Ignoring $timeouts timeouts"; - exit 0; -else - echo "Non-timeout errors found"; - exit 1; -fi diff --git a/ci/build.sh b/ci/build.sh new file mode 100755 index 000000000..b0fae1240 --- /dev/null +++ b/ci/build.sh @@ -0,0 +1,17 @@ +#!/bin/bash -x + +output=$(mktemp) + +mkdir -p book/ +cp -r $HOME/linkcheck/ book/ +RUST_LOG=mdbook_linkcheck=debug mdbook-linkcheck -s 2>&1 | tee -a $output +cp -r book/linkcheck $HOME/ + +mdbook build + +result=${PIPESTATUS[0]} + +# if passed, great! +if [ "$result" -eq "0" ] ; then + exit 0 ; +fi From 171f7f785a3a12c4beb9466987aec7b7cb83e2a7 Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 18:06:30 -0400 Subject: [PATCH 0686/1812] Fix (build CI script): fails early if linkcheck fails --- ci/build.sh | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/ci/build.sh b/ci/build.sh index b0fae1240..395484841 100755 --- a/ci/build.sh +++ b/ci/build.sh @@ -1,17 +1,22 @@ #!/bin/bash -x +set -o pipefail + output=$(mktemp) mkdir -p book/ cp -r $HOME/linkcheck/ book/ RUST_LOG=mdbook_linkcheck=debug mdbook-linkcheck -s 2>&1 | tee -a $output +result=${PIPESTATUS[0]} cp -r book/linkcheck $HOME/ mdbook build -result=${PIPESTATUS[0]} - # if passed, great! if [ "$result" -eq "0" ] ; then + echo "Linkchecks passed" exit 0 ; +else + echo "Linkchecks failed" + exit 1 ; fi From 522bcb43c63bcede89cd809fa405e7733f0831b9 Mon Sep 17 00:00:00 2001 From: Amanjeev Sethi Date: Wed, 2 Oct 2019 20:12:26 -0400 Subject: [PATCH 0687/1812] Refactor (build CI script): minimizes the script, thanks to mark-i-m --- ci/build.sh | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/ci/build.sh b/ci/build.sh index 395484841..504957b3f 100755 --- a/ci/build.sh +++ b/ci/build.sh @@ -1,22 +1,10 @@ #!/bin/bash -x -set -o pipefail - -output=$(mktemp) +set -e mkdir -p book/ cp -r $HOME/linkcheck/ book/ -RUST_LOG=mdbook_linkcheck=debug mdbook-linkcheck -s 2>&1 | tee -a $output -result=${PIPESTATUS[0]} +RUST_LOG=mdbook_linkcheck=debug mdbook-linkcheck -s cp -r book/linkcheck $HOME/ mdbook build - -# if passed, great! -if [ "$result" -eq "0" ] ; then - echo "Linkchecks passed" - exit 0 ; -else - echo "Linkchecks failed" - exit 1 ; -fi From ddd3d6abb72107319865233d9a50eb0b45f5a370 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 10 Oct 2019 14:28:49 -0400 Subject: [PATCH 0688/1812] reference the new PR mechanism (#463) * reference the new PR mechanism * wrap lines --- src/ice-breaker/about.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md index ab9c66789..733011d39 100644 --- a/src/ice-breaker/about.md +++ b/src/ice-breaker/about.md @@ -31,7 +31,19 @@ priority**: ## Joining an ICE-breaker group -TBD -- we are building this mechanism right now! In the meantime, drop -in on Zulip and leave your github name in [this topic][topic]. +To join an ICE-breaker group, you just have to open a PR adding your +Github username to the appropriate file in the Rust team repository. +See the "example PRs" below to get a precise idea and to identify the +file to edit. -[topic]: https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/llvm.20ice-breaker.20registration +Also, if you are not already a member of a Rust team then -- in addition +to adding your name to the file -- you have to checkout the repository and +run the following command: + +```bash +cargo run add-person $your_user_name +``` + +Example PRs: + +* [Example of adding yourself to the LLVM ICE-breakers.](https://github.com/rust-lang/team/pull/140) From e6f625f96ed9d47a041cf93e899fca87f80dfa21 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 9 Oct 2019 09:50:07 -0700 Subject: [PATCH 0689/1812] Expand on stability documentation. --- src/stability.md | 83 +++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 78 insertions(+), 5 deletions(-) diff --git a/src/stability.md b/src/stability.md index 46f62e520..6b32dff2d 100644 --- a/src/stability.md +++ b/src/stability.md @@ -3,13 +3,18 @@ This section is about the stability attributes and schemes that allow stable APIs to use unstable APIs internally in the rustc standard library. -For instructions on stabilizing a language feature see +For instructions on stabilizing a language feature see [Stabilizing Features](./stabilization_guide.md). -# unstable +## unstable The `#[unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` attribute explicitly -marks an item as unstable. This infects all sub-items, where the attribute doesn't have to be +marks an item as unstable. Items that are marked as "unstable" cannot be used +without a corresponding `#![feature]` attribute on the crate, even on a +nightly compiler. This restriction only applies across crate boundaries, unstable +items may be used within the crate they are defined. + +The `unstable` attribute infects all sub-items, where the attribute doesn't have to be reapplied. So if you apply this to a module, all items in the module will be unstable. You can make specific sub-items stable by using the `#[stable]` attribute on them. @@ -21,9 +26,14 @@ Note, however, that due to a [rustc bug], stable items inside unstable modules can import `core::intrinsics::transmute` even though `intrinsics` is an unstable module. Thus, this kind of nesting should be avoided when possible. +The `unstable` attribute may also have the `soft` value, which makes it a +future-incompatible deny-by-default lint instead of a hard error. This is used +by the `bench` attribute which was accidentally accepted in the past. This +prevents breaking dependencies by leveraging Cargo's lint capping. + [rustc bug]: https://github.com/rust-lang/rust/issues/15702 -# stable +## stable The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks an item as stabilized. To do this, follow the instructions in @@ -31,7 +41,7 @@ stabilized. To do this, follow the instructions in Note that stable functions may use unstable things in their body. -# allow_internal_unstable +## allow_internal_unstable Macros, compiler desugarings and `const fn`s expose their bodies to the call site. To work around not being able to use unstable things in the standard library's macros, there's the @@ -49,4 +59,67 @@ are nondeterministic and often unknown at compile-time. Always ping @oli-obk, @RalfJung, and @Centril if you are adding more `allow_internal_unstable` attributes to any `const fn` +## staged_api + +Any crate that uses the `stable`, `unstable`, or `rustc_deprecated` attributes +must include the `#![feature(staged_api)]` attribute on the crate. + +## rustc_deprecated + +The deprecation system shares the same infrastructure as the stable/unstable +attributes. The `rustc_deprecated` attribute is similar to the [`deprecated` +attribute]. It was previously called `deprecated`, but was split off when +`deprecated` was stabilized. The `deprecated` attribute cannot be used in a +`staged_api` crate, `rustc_deprecated` must be used instead. The deprecated +item must also have a `stable` or `unstable` attribute. + +`rustc_deprecated` has the following form: + +```rust,ignore +#[rustc_deprecated( + since = "1.38.0", + reason = "explanation for deprecation", + suggestion = "other_function" +)] +``` + +The `suggestion` field is optional. If given, it should be a string that can +be used as a machine-applicable suggestion to correct the warning. This is +typically used when the identifier is renamed, but no other significant +changes are necessary. + +Another difference from the `deprecated` attribute is that the `since` field +is actually checked against the current version of `rustc`. If `since` is in a +future version, then the `deprecated_in_future` lint is triggered which is +default `allow`, but most of the standard library raises it to a warning with +`#![warn(deprecated_in_future)]`. + +[`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute + +## -Zforce-unstable-if-unmarked + +The `-Zforce-unstable-if-unmarked` flag has a variety of purposes to help +enforce that the correct crates are marked as unstable, but can still use +private crates without special attributes. It was introduced primarily to +allow rustc and the standard library to link to arbitrary crates on crates.io +which do not themselves use `staged_api`. `rustc` also relies on this flag to +mark all of its crates as unstable with the `rustc_private` feature so that +each crate does not need to be carefully marked with `unstable`. + +This flag is automatically applied to all of `rustc` and the standard library +by the bootstrap scripts. This is needed because the compiler and all of its +dependencies are shipped in the sysroot to all users. + +This flag has the following effects: + +- Marks the crate as "unstable" with the `rustc_private` feature if it is not + itself marked as stable or unstable. +- Allows these crates to access other forced-unstable crates without any need + for attributes. + +Code which does not use `-Zforce-unstable-if-unmarked` should include the +`#![feature(rustc_private)]` crate attribute to access these force-unstable +crates. This is needed for things that link `rustc`, such as `miri`, `rls`, or +`clippy`. + [blog]: https://www.ralfj.de/blog/2018/07/19/const.html From 799082b3405bbfee40e9e64d5cdefa9d93262ad1 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 10 Oct 2019 14:16:29 -0700 Subject: [PATCH 0690/1812] Try to clarify how crates are able to access force-unstable dependencies without a feature attribute. --- src/stability.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/src/stability.md b/src/stability.md index 6b32dff2d..1db738cb2 100644 --- a/src/stability.md +++ b/src/stability.md @@ -99,12 +99,12 @@ default `allow`, but most of the standard library raises it to a warning with ## -Zforce-unstable-if-unmarked The `-Zforce-unstable-if-unmarked` flag has a variety of purposes to help -enforce that the correct crates are marked as unstable, but can still use -private crates without special attributes. It was introduced primarily to -allow rustc and the standard library to link to arbitrary crates on crates.io -which do not themselves use `staged_api`. `rustc` also relies on this flag to -mark all of its crates as unstable with the `rustc_private` feature so that -each crate does not need to be carefully marked with `unstable`. +enforce that the correct crates are marked as unstable. It was introduced +primarily to allow rustc and the standard library to link to arbitrary crates +on crates.io which do not themselves use `staged_api`. `rustc` also relies on +this flag to mark all of its crates as unstable with the `rustc_private` +feature so that each crate does not need to be carefully marked with +`unstable`. This flag is automatically applied to all of `rustc` and the standard library by the bootstrap scripts. This is needed because the compiler and all of its @@ -115,7 +115,11 @@ This flag has the following effects: - Marks the crate as "unstable" with the `rustc_private` feature if it is not itself marked as stable or unstable. - Allows these crates to access other forced-unstable crates without any need - for attributes. + for attributes. Normally a crate would need a `#![feature(rustc_private)]` + attribute to use other unstable crates. However, that would make it + impossible for a crate from crates.io to access its own dependencies since + that crate won't have a `feature(rustc_private)` attribute, but *everything* + is compiled with `-Zforce-unstable-if-unmarked`. Code which does not use `-Zforce-unstable-if-unmarked` should include the `#![feature(rustc_private)]` crate attribute to access these force-unstable From 4a85f36f1c5f7cc9ac82df31ac906f3068ff9d5e Mon Sep 17 00:00:00 2001 From: Diogo Sousa Date: Sat, 12 Oct 2019 00:20:36 +0100 Subject: [PATCH 0691/1812] Updated kinds that were renamed to generic arguments. This change happened in commit bea3d67c77dd643ef1f89c8bd6562e90b373cec4 on rust-lang/rust. --- src/SUMMARY.md | 2 +- src/generic_arguments.md | 50 ++++++++++++++++++++++++++++++++++++++++ src/kinds.md | 49 --------------------------------------- src/ty.md | 2 +- 4 files changed, 52 insertions(+), 51 deletions(-) create mode 100644 src/generic_arguments.md delete mode 100644 src/kinds.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b65ba4c74..fc866f7b0 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -43,7 +43,7 @@ - [Debugging](./hir-debugging.md) - [Closure expansion](./closure.md) - [The `ty` module: representing types](./ty.md) - - [Kinds](./kinds.md) + - [Generic arguments](./generic_arguments.md) - [Type inference](./type-inference.md) - [Trait solving (old-style)](./traits/resolution.md) - [Higher-ranked trait bounds](./traits/hrtb.md) diff --git a/src/generic_arguments.md b/src/generic_arguments.md new file mode 100644 index 000000000..c9911acf5 --- /dev/null +++ b/src/generic_arguments.md @@ -0,0 +1,50 @@ +# Generic arguments +A `ty::subst::GenericArg<'tcx>` represents some entity in the type system: a type +(`Ty<'tcx>`), lifetime (`ty::Region<'tcx>`) or constant (`ty::Const<'tcx>`). +`GenericArg` is used to perform substitutions of generic parameters for concrete +arguments, such as when calling a function with generic parameters explicitly +with type arguments. Substitutions are represented using the +[`Subst` type](#subst) as described below. + +## `Subst` +`ty::subst::Subst<'tcx>` is intuitively simply a slice of `GenericArg<'tcx>`s, +acting as an ordered list of substitutions from generic parameters to +concrete arguments (such as types, lifetimes and consts). + +For example, given a `HashMap` with two type parameters, `K` and `V`, an +instantiation of the parameters, for example `HashMap`, would be +represented by the substitution `&'tcx [tcx.types.i32, tcx.types.u32]`. + +`Subst` provides various convenience methods to instantiate substitutions +given item definitions, which should generally be used rather than explicitly +constructing such substitution slices. + +## `GenericArg` +The actual `GenericArg` struct is optimised for space, storing the type, lifetime or +const as an interned pointer containing a tag identifying its kind (in the +lowest 2 bits). Unless you are working with the `Subst` implementation +specifically, you should generally not have to deal with `GenericArg` and instead +make use of the safe [`GenericArgKind`](#genericargkind) abstraction. + +## `GenericArgKind` +As `GenericArg` itself is not type-safe, the `GenericArgKind` enum provides a more +convenient and safe interface for dealing with generic arguments. An +`GenericArgKind` can be converted to a raw `GenericArg` using `GenericArg::from()` +(or simply `.into()` when the context is clear). As mentioned earlier, substitution +lists store raw `GenericArg`s, so before dealing with them, it is preferable to +convert them to `GenericArgKind`s first. This is done by calling the `.unpack()` +method. + +```rust,ignore +// An example of unpacking and packing a generic argument. +fn deal_with_generic_arg<'tcx>(generic_arg: GenericArg<'tcx>) -> GenericArg<'tcx> { + // Unpack a raw `GenericArg` to deal with it safely. + let new_generic_arg: GenericArgKind<'tcx> = match generic_arg.unpack() { + GenericArgKind::Type(ty) => { /* ... */ } + GenericArgKind::Lifetime(lt) => { /* ... */ } + GenericArgKind::Const(ct) => { /* ... */ } + }; + // Pack the `GenericArgKind` to store it in a substitution list. + new_generic_arg.into() +} +``` diff --git a/src/kinds.md b/src/kinds.md deleted file mode 100644 index 194d2ee2f..000000000 --- a/src/kinds.md +++ /dev/null @@ -1,49 +0,0 @@ -# Kinds -A `ty::subst::Kind<'tcx>` represents some entity in the type system: a type -(`Ty<'tcx>`), lifetime (`ty::Region<'tcx>`) or constant (`ty::Const<'tcx>`). -`Kind` is used to perform substitutions of generic parameters for concrete -arguments, such as when calling a function with generic parameters explicitly -with type arguments. Substitutions are represented using the -[`Subst` type](#subst) as described below. - -## `Subst` -`ty::subst::Subst<'tcx>` is intuitively simply a slice of `Kind<'tcx>`s, -acting as an ordered list of substitutions from generic parameters to -concrete arguments (such as types, lifetimes and consts). - -For example, given a `HashMap` with two type parameters, `K` and `V`, an -instantiation of the parameters, for example `HashMap`, would be -represented by the substitution `&'tcx [tcx.types.i32, tcx.types.u32]`. - -`Subst` provides various convenience methods to instantiate substitutions -given item definitions, which should generally be used rather than explicitly -constructing such substitution slices. - -## `Kind` -The actual `Kind` struct is optimised for space, storing the type, lifetime or -const as an interned pointer containing a tag identifying its kind (in the -lowest 2 bits). Unless you are working with the `Subst` implementation -specifically, you should generally not have to deal with `Kind` and instead -make use of the safe [`UnpackedKind`](#unpackedkind) abstraction. - -## `UnpackedKind` -As `Kind` itself is not type-safe, the `UnpackedKind` enum provides a more -convenient and safe interface for dealing with kinds. An `UnpackedKind` can -be converted to a raw `Kind` using `Kind::from()` (or simply `.into()` when -the context is clear). As mentioned earlier, substitution lists store raw -`Kind`s, so before dealing with them, it is preferable to convert them to -`UnpackedKind`s first. This is done by calling the `.unpack()` method. - -```rust,ignore -// An example of unpacking and packing a kind. -fn deal_with_kind<'tcx>(kind: Kind<'tcx>) -> Kind<'tcx> { - // Unpack a raw `Kind` to deal with it safely. - let new_kind: UnpackedKind<'tcx> = match kind.unpack() { - UnpackedKind::Type(ty) => { /* ... */ } - UnpackedKind::Lifetime(lt) => { /* ... */ } - UnpackedKind::Const(ct) => { /* ... */ } - }; - // Pack the `UnpackedKind` to store it in a substitution list. - new_kind.into() -} -``` diff --git a/src/ty.md b/src/ty.md index 811f473c9..6a1cf4444 100644 --- a/src/ty.md +++ b/src/ty.md @@ -109,7 +109,7 @@ module. Here are a few examples: - `Predicate` defines something the trait system has to prove (see `traits` module). -[subst]: ./kinds.html#subst +[subst]: ./generic_arguments.html#subst ### Import conventions From 300412da9e883817a84cf7b5009fea7ac0f386c7 Mon Sep 17 00:00:00 2001 From: Chris Emerson Date: Sat, 12 Oct 2019 23:11:52 +0100 Subject: [PATCH 0692/1812] Fix some paths: tt -> mbe (#465) --- src/macro-expansion.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index f6a9b3b1f..01a533ad6 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -7,7 +7,7 @@ before name resolution, macros are expanded using these portions of the code. The macro parser, in turn, may call the normal Rust parser when it needs to bind a metavariable (e.g. `$my_expr`) while parsing the contents of a macro invocation. The code for macro expansion is in -[`src/libsyntax/ext/tt/`][code_dir]. This chapter aims to explain how macro +[`src/libsyntax/ext/mbe/`][code_dir]. This chapter aims to explain how macro expansion works. ### Example @@ -61,7 +61,7 @@ invocations. Interestingly, both are done by the macro parser. Basically, the macro parser is like an NFA-based regex parser. It uses an algorithm similar in spirit to the [Earley parsing algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is -defined in [`src/libsyntax/ext/tt/macro_parser.rs`][code_mp]. +defined in [`src/libsyntax/ext/mbe/macro_parser.rs`][code_mp]. The interface of the macro parser is as follows (this is slightly simplified): @@ -110,7 +110,7 @@ normal Rust parser. As mentioned above, both definitions and invocations of macros are parsed using the macro parser. This is extremely non-intuitive and self-referential. The code to parse macro _definitions_ is in -[`src/libsyntax/ext/tt/macro_rules.rs`][code_mr]. It defines the pattern for +[`src/libsyntax/ext/mbe/macro_rules.rs`][code_mr]. It defines the pattern for matching for a macro definition as `$( $lhs:tt => $rhs:tt );+`. In other words, a `macro_rules` definition should have in its body at least one occurrence of a token tree followed by `=>` followed by another token tree. When the compiler @@ -139,7 +139,7 @@ the parse is ambiguous, while if there are no matches at all, there is a syntax error. For more information about the macro parser's implementation, see the comments -in [`src/libsyntax/ext/tt/macro_parser.rs`][code_mp]. +in [`src/libsyntax/ext/mbe/macro_parser.rs`][code_mp]. ### Hygiene From 81fc310fda2566542b988a05d4c425b04a582f29 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 15 Oct 2019 22:26:17 +0200 Subject: [PATCH 0693/1812] update link --- src/traits/wf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/wf.md b/src/traits/wf.md index 0ced345a1..a6981bf4c 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -18,7 +18,7 @@ an extended set of examples in the [`chalk/src/test/wf.rs`][wf_test] submodule. The new-style WF checking has not been implemented in rustc yet. [wf]: https://github.com/rust-lang/chalk/blob/master/chalk-solve/src/wf.rs -[wf_test]: https://github.com/rust-lang/chalk/blob/master/src/test/wf.rs +[wf_test]: https://github.com/rust-lang/chalk/blob/master/src/test/wf_lowering.rs We give here a complete reference of the generated goals for each Rust declaration. From 4e87eb2fb8ea8986d3b018bbd3b02ae45ad012ca Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 17 Oct 2019 09:40:38 +0200 Subject: [PATCH 0694/1812] fix links (#469) --- src/appendix/code-index.md | 2 +- src/diagnostics.md | 4 ++-- src/implementing_new_features.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 267a3a3ea..d58c4ea1b 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -17,7 +17,7 @@ Item | Kind | Short description | Chapter | `NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) `P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [src/syntax/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ptr/struct.P.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) -`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html) +`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html) `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) `Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) diff --git a/src/diagnostics.md b/src/diagnostics.md index f3d518764..0a21c91dc 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -31,7 +31,7 @@ usually have names like `span_err` or `struct_span_err` or `span_warn`, etc... There are lots of them; they emit different types of "errors", such as warnings, errors, fatal errors, suggestions, etc. -[parsesses]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html +[parsesses]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html [session]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html In general, there are two class of such methods: ones that emit an error @@ -281,7 +281,7 @@ processed. [`Session`][sessbl] and [`ParseSess`][parsebl] both have system automatically takes care of handling buffered lints later. [sessbl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html#method.buffer_lint -[parsebl]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.ParseSess.html#method.buffer_lint +[parsebl]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html#method.buffer_lint Thus, to define a lint that runs early in the compilation, one defines a lint like normal but invokes the lint with `buffer_lint`. diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 0051dadcf..2958f294a 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -174,7 +174,7 @@ Once the feature is moved to `accepted.rs`, the version is changed to that night 8. Get your PR reviewed and land it. You have now successfully implemented a feature in Rust! -[`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/struct.GatedSpans.html +[`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.GatedSpans.html [`feature_gate::check::check_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/check/fn.check_crate.html [value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md [stability in code]: #stability-in-code From 232b35d75eb9e813be469f0dabf37c1c58ec5049 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 18 Oct 2019 02:03:46 +0200 Subject: [PATCH 0695/1812] format examples better (#471) --- src/implementing_new_features.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 2958f294a..3055bf97a 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -125,26 +125,26 @@ a new unstable feature: 2. Pick a name for the feature gate (for RFCs, use the name in the RFC). -3. Add a feature gate declaration to `libsyntax/active.rs` +3. Add a feature gate declaration to `libsyntax/feature_gate/active.rs` in the active `declare_features` block: -```rust,ignore - // description of feature - (active, $feature_name, "$current_nightly_version", Some($tracking_issue_number), $edition) -``` + ```rust,ignore + // description of feature + (active, $feature_name, "$current_nightly_version", Some($tracking_issue_number), $edition) + ``` -where `$edition` has the type `Option`, and is typically -just `None`. + where `$edition` has the type `Option`, and is typically + just `None`. -For example: + For example: -```rust,ignore - // allow '|' at beginning of match arms (RFC 1925) -( active, match_beginning_vert, "1.21.0", Some(44101), None), -``` + ```rust,ignore + /// Allows defining identifiers beyond ASCII. + (active, non_ascii_idents, "1.0.0", Some(55467), None), + ``` -When added, the current version should be the one for the current nightly. -Once the feature is moved to `accepted.rs`, the version is changed to that nightly version. + When added, the current version should be the one for the current nightly. + Once the feature is moved to `accepted.rs`, the version is changed to that nightly version. 4. Prevent usage of the new feature unless the feature gate is set. You can check it in most places in the compiler using the From fa3a3e4d5d3578f51eaf66d111b9b832332fe2d1 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Tue, 15 Oct 2019 22:13:15 +0200 Subject: [PATCH 0696/1812] I prefers long options in documentation --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 42e7e44a4..a5481e82c 100644 --- a/README.md +++ b/README.md @@ -72,7 +72,8 @@ To make a PR, the following steps are useful. git submodule update --remote src/doc/rustc-guide git add -u git commit -m "Update rustc-guide" -./x.py test -i --stage 1 src/doc/rustc-guide # This is optional and should succeed anyway +# Note that you can use -i, which is short for --incremental, in the following command +./x.py test --incremental --stage 1 src/doc/rustc-guide # This is optional and should succeed anyway # Open a PR in rust-lang/rust ``` From 187765fba56b590ddcc92ac2549fbe9b29f9594b Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 18 Oct 2019 16:22:17 +0900 Subject: [PATCH 0697/1812] Update links (#472) --- src/macro-expansion.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 01a533ad6..4a0eaeb48 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -7,7 +7,7 @@ before name resolution, macros are expanded using these portions of the code. The macro parser, in turn, may call the normal Rust parser when it needs to bind a metavariable (e.g. `$my_expr`) while parsing the contents of a macro invocation. The code for macro expansion is in -[`src/libsyntax/ext/mbe/`][code_dir]. This chapter aims to explain how macro +[`src/libsyntax_expand/mbe/`][code_dir]. This chapter aims to explain how macro expansion works. ### Example @@ -61,7 +61,7 @@ invocations. Interestingly, both are done by the macro parser. Basically, the macro parser is like an NFA-based regex parser. It uses an algorithm similar in spirit to the [Earley parsing algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is -defined in [`src/libsyntax/ext/mbe/macro_parser.rs`][code_mp]. +defined in [`src/libsyntax_expand/mbe/macro_parser.rs`][code_mp]. The interface of the macro parser is as follows (this is slightly simplified): @@ -110,7 +110,7 @@ normal Rust parser. As mentioned above, both definitions and invocations of macros are parsed using the macro parser. This is extremely non-intuitive and self-referential. The code to parse macro _definitions_ is in -[`src/libsyntax/ext/mbe/macro_rules.rs`][code_mr]. It defines the pattern for +[`src/libsyntax_expand/mbe/macro_rules.rs`][code_mr]. It defines the pattern for matching for a macro definition as `$( $lhs:tt => $rhs:tt );+`. In other words, a `macro_rules` definition should have in its body at least one occurrence of a token tree followed by `=>` followed by another token tree. When the compiler @@ -139,7 +139,7 @@ the parse is ambiguous, while if there are no matches at all, there is a syntax error. For more information about the macro parser's implementation, see the comments -in [`src/libsyntax/ext/mbe/macro_parser.rs`][code_mp]. +in [`src/libsyntax_expand/mbe/macro_parser.rs`][code_mp]. ### Hygiene @@ -205,8 +205,8 @@ TODO TODO: maybe something about macros 2.0? -[code_dir]: https://github.com/rust-lang/rust/tree/master/src/libsyntax/ext/mbe -[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/mbe/macro_parser -[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/mbe/macro_rules -[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ext/mbe/macro_parser/fn.parse.html +[code_dir]: https://github.com/rust-lang/rust/tree/master/src/libsyntax_expand/mbe +[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax_expand/mbe/macro_parser +[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax_expand/mbe/macro_rules +[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax_expand/mbe/macro_parser/fn.parse.html [parsing]: ./the-parser.html From b7d9cee9470b080bd5d20b3a808a133c89af370d Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 22 Oct 2019 16:11:52 -0400 Subject: [PATCH 0698/1812] give instructions for how to ping the ICE-breaker teams (#475) * give instructions for how to ping the ICE-breaker teams * Update src/ice-breaker/about.md Co-Authored-By: Yuki Okushi * add links --- src/ice-breaker/about.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md index 733011d39..1b59fc23f 100644 --- a/src/ice-breaker/about.md +++ b/src/ice-breaker/about.md @@ -47,3 +47,20 @@ cargo run add-person $your_user_name Example PRs: * [Example of adding yourself to the LLVM ICE-breakers.](https://github.com/rust-lang/team/pull/140) + +## Tagging an issue for an ICE-breaker group + +To tag an issue as appropriate for an ICE-breaker group, you give +[rustbot] a [`ping`] command with the name of the ICE-breakers +team. For example: + +```text +@rustbot ping icebreakers-llvm +``` + +**Note though that this should only be done by compiler team members +or contributors, and is typically done as part of compiler team +triage.** + +[rustbot]: https://github.com/rust-lang/triagebot/ +[`ping`]: https://github.com/rust-lang/triagebot/wiki/Pinging From 518606ba212ae8b8c7ddfba59dcee38176d63229 Mon Sep 17 00:00:00 2001 From: CreepySkeleton Date: Wed, 23 Oct 2019 20:42:52 +0300 Subject: [PATCH 0699/1812] Fix a typo (#477) --- src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index e2e96fced..93fcd556a 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -47,7 +47,7 @@ before, not all of these are needed for every type of contribution. audience. You can find the original discussion [here][prerfc]. - **RFC** This is when you formally present your idea to the community for consideration. You can find the RFC [here][rfc]. -- **Implementation** Implement your idea unstabley in the compiler. You can +- **Implementation** Implement your idea unstably in the compiler. You can find the original implementation [here][impl1]. - **Possibly iterate/refine** As the community gets experience with your feature on the nightly compiler and in `libstd`, there may be additional From 6fd627d6b89b9ee65a3186e3a3018b4614967a60 Mon Sep 17 00:00:00 2001 From: CreepySkeleton Date: Thu, 24 Oct 2019 21:54:40 +0300 Subject: [PATCH 0700/1812] Fix missing link (#480) --- src/ice-breaker/about.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md index 1b59fc23f..7869bdbce 100644 --- a/src/ice-breaker/about.md +++ b/src/ice-breaker/about.md @@ -14,6 +14,8 @@ Of course, you don't have to wait for new issues to be tagged! If you prefer, you can use the Github label for an ICE-breaker group to search for existing issues that haven't been claimed yet. +[claim the issue]: https://github.com/rust-lang/triagebot/wiki/Assignment + ## What issues are a good fit for ICE-breaker groups? "ICE-breaker issues" are intended to be **isolated** bugs of **middle From 51a4a7251636594a21f8b63ab9f795b6f87498cb Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 24 Oct 2019 14:30:01 -0500 Subject: [PATCH 0701/1812] move readme to guide (#481) --- src/SUMMARY.md | 1 + src/codegen/backend-agnostic.md | 203 ++++++++++++++++++++++++++++++++ 2 files changed, 204 insertions(+) create mode 100644 src/codegen/backend-agnostic.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index fc866f7b0..fdec4ffde 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -91,6 +91,7 @@ - [Code Generation](./codegen.md) - [Updating LLVM](./codegen/updating-llvm.md) - [Debugging LLVM](./codegen/debugging.md) + - [Backend Agnostic Codegen](./codegen/backend-agnostic.md) - [Profile-guided Optimization](./profile-guided-optimization.md) - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) diff --git a/src/codegen/backend-agnostic.md b/src/codegen/backend-agnostic.md new file mode 100644 index 000000000..b6436b679 --- /dev/null +++ b/src/codegen/backend-agnostic.md @@ -0,0 +1,203 @@ +# Backend Agnostic Codegen + +In the future, it would be nice to allow other codegen backends (e.g. +[Cranelift][cranelift]). To this end, `librustc_codegen_ssa` provides an +abstract interface for all backends to implenent. + +> The following is a copy/paste of a README from the rust-lang/rust repo. +> Please submit a PR if it needs updating. + +# Refactoring of `rustc_codegen_llvm` +by Denis Merigoux, October 23rd 2018 + +## State of the code before the refactoring + +All the code related to the compilation of MIR into LLVM IR was contained +inside the `rustc_codegen_llvm` crate. Here is the breakdown of the most +important elements: +* the `back` folder (7,800 LOC) implements the mechanisms for creating the + different object files and archive through LLVM, but also the communication + mechanisms for parallel code generation; +* the `debuginfo` (3,200 LOC) folder contains all code that passes debug + information down to LLVM; +* the `llvm` (2,200 LOC) folder defines the FFI necessary to communicate with + LLVM using the C++ API; +* the `mir` (4,300 LOC) folder implements the actual lowering from MIR to LLVM + IR; +* the `base.rs` (1,300 LOC) file contains some helper functions but also the + high-level code that launches the code generation and distributes the work. +* the `builder.rs` (1,200 LOC) file contains all the functions generating + individual LLVM IR instructions inside a basic block; +* the `common.rs` (450 LOC) contains various helper functions and all the + functions generating LLVM static values; +* the `type_.rs` (300 LOC) defines most of the type translations to LLVM IR. + +The goal of this refactoring is to separate inside this crate code that is +specific to the LLVM from code that can be reused for other rustc backends. For +instance, the `mir` folder is almost entirely backend-specific but it relies +heavily on other parts of the crate. The separation of the code must not affect +the logic of the code nor its performance. + +For these reasons, the separation process involves two transformations that +have to be done at the same time for the resulting code to compile : + +1. replace all the LLVM-specific types by generics inside function signatures + and structure definitions; +2. encapsulate all functions calling the LLVM FFI inside a set of traits that + will define the interface between backend-agnostic code and the backend. + +While the LLVM-specific code will be left in `rustc_codegen_llvm`, all the new +traits and backend-agnostic code will be moved in `rustc_codegen_ssa` (name +suggestion by @eddyb). + +## Generic types and structures + +@irinagpopa started to parametrize the types of `rustc_codegen_llvm` by a +generic `Value` type, implemented in LLVM by a reference `&'ll Value`. This +work has been extended to all structures inside the `mir` folder and elsewhere, +as well as for LLVM's `BasicBlock` and `Type` types. + +The two most important structures for the LLVM codegen are `CodegenCx` and +`Builder`. They are parametrized by multiple lifetime parameters and the type +for `Value`. + +```rust,ignore +struct CodegenCx<'ll, 'tcx> { + /* ... */ +} + +struct Builder<'a, 'll, 'tcx> { + cx: &'a CodegenCx<'ll, 'tcx>, + /* ... */ +} +``` + +`CodegenCx` is used to compile one codegen-unit that can contain multiple +functions, whereas `Builder` is created to compile one basic block. + +The code in `rustc_codegen_llvm` has to deal with multiple explicit lifetime +parameters, that correspond to the following: +* `'tcx` is the longest lifetime, that corresponds to the original `TyCtxt` + containing the program's information; +* `'a` is a short-lived reference of a `CodegenCx` or another object inside a + struct; +* `'ll` is the lifetime of references to LLVM objects such as `Value` or + `Type`. + +Although there are already many lifetime parameters in the code, making it +generic uncovered situations where the borrow-checker was passing only due to +the special nature of the LLVM objects manipulated (they are extern pointers). +For instance, a additional lifetime parameter had to be added to +`LocalAnalyser` in `analyse.rs`, leading to the definition: + +```rust,ignore +struct LocalAnalyzer<'mir, 'a, 'tcx> { + /* ... */ +} +``` + +However, the two most important structures `CodegenCx` and `Builder` are not +defined in the backend-agnostic code. Indeed, their content is highly specific +of the backend and it makes more sense to leave their definition to the backend +implementor than to allow just a narrow spot via a generic field for the +backend's context. + +## Traits and interface + +Because they have to be defined by the backend, `CodegenCx` and `Builder` will +be the structures implementing all the traits defining the backend's interface. +These traits are defined in the folder `rustc_codegen_ssa/traits` and all the +backend-agnostic code is parametrized by them. For instance, let us explain how +a function in `base.rs` is parametrized: + +```rust,ignore +pub fn codegen_instance<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>>( + cx: &'a Bx::CodegenCx, + instance: Instance<'tcx> +) { + /* ... */ +} +``` + +In this signature, we have the two lifetime parameters explained earlier and +the master type `Bx` which satisfies the trait `BuilderMethods` corresponding +to the interface satisfied by the `Builder` struct. The `BuilderMethods` +defines an associated type `Bx::CodegenCx` that itself satisfies the +`CodegenMethods` traits implemented by the struct `CodegenCx`. + +On the trait side, here is an example with part of the definition of +`BuilderMethods` in `traits/builder.rs`: + +```rust,ignore +pub trait BuilderMethods<'a, 'tcx>: + HasCodegen<'tcx> + + DebugInfoBuilderMethods<'tcx> + + ArgTypeMethods<'tcx> + + AbiBuilderMethods<'tcx> + + IntrinsicCallMethods<'tcx> + + AsmBuilderMethods<'tcx> +{ + fn new_block<'b>( + cx: &'a Self::CodegenCx, + llfn: Self::Function, + name: &'b str + ) -> Self; + /* ... */ + fn cond_br( + &mut self, + cond: Self::Value, + then_llbb: Self::BasicBlock, + else_llbb: Self::BasicBlock, + ); + /* ... */ +} +``` + +Finally, a master structure implementing the `ExtraBackendMethods` trait is +used for high-level codegen-driving functions like `codegen_crate` in +`base.rs`. For LLVM, it is the empty `LlvmCodegenBackend`. +`ExtraBackendMethods` should be implemented by the same structure that +implements the `CodegenBackend` defined in +`rustc_codegen_utils/codegen_backend.rs`. + +During the traitification process, certain functions have been converted from +methods of a local structure to methods of `CodegenCx` or `Builder` and a +corresponding `self` parameter has been added. Indeed, LLVM stores information +internally that it can access when called through its API. This information +does not show up in a Rust data structure carried around when these methods are +called. However, when implementing a Rust backend for `rustc`, these methods +will need information from `CodegenCx`, hence the additional parameter (unused +in the LLVM implementation of the trait). + +## State of the code after the refactoring + +The traits offer an API which is very similar to the API of LLVM. This is not +the best solution since LLVM has a very special way of doing things: when +addding another backend, the traits definition might be changed in order to +offer more flexibility. + +However, the current separation between backend-agnostic and LLVM-specific code +has allows the reuse of a significant part of the old `rustc_codegen_llvm`. +Here is the new LOC breakdown between backend-agnostic (BA) and LLVM for the +most important elements: + +* `back` folder: 3,800 (BA) vs 4,100 (LLVM); +* `mir` folder: 4,400 (BA) vs 0 (LLVM); +* `base.rs`: 1,100 (BA) vs 250 (LLVM); +* `builder.rs`: 1,400 (BA) vs 0 (LLVM); +* `common.rs`: 350 (BA) vs 350 (LLVM); + +The `debuginfo` folder has been left almost untouched by the splitting and is +specific to LLVM. Only its high-level features have been traitified. + +The new `traits` folder has 1500 LOC only for trait definitions. Overall, the +27,000 LOC-sized old `rustc_codegen_llvm` code has been split into the new +18,500 LOC-sized new `rustc_codegen_llvm` and the 12,000 LOC-sized +`rustc_codegen_ssa`. We can say that this refactoring allowed the reuse of +approximately 10,000 LOC that would otherwise have had to be duplicated between +the multiple backends of `rustc`. + +The refactored version of `rustc`'s backend introduced no regression over the +test suite nor in performance benchmark, which is in coherence with the nature +of the refactoring that used only compile-time parametricity (no trait +objects). From 6dc2f38cd1ccda33b7b8301e88ffd0992cc6aa75 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Sun, 27 Oct 2019 20:29:02 +0100 Subject: [PATCH 0702/1812] Explain `rustc_on_unimplemented` --- src/diagnostics.md | 147 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 147 insertions(+) diff --git a/src/diagnostics.md b/src/diagnostics.md index 0a21c91dc..b096d6a54 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -342,3 +342,150 @@ The JSON emitter defines [its own `Diagnostic` struct](https://github.com/rust-lang/rust/blob/b2c6b8c29f13f8d1f242da89e587960b95337819/src/libsyntax/json.rs#L85-L99) (and sub-structs) for the JSON serialization. Don't confuse this with [`errors::Diagnostic`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Diagnostic.html)! + +## `#[rustc_on_unimplemented(...)]` + +The `#[rustc_on_unimplemented]` attribute allows trait definitions to add specialized +notes to error messages when an implementation was expected but not found. +You can refer to the trait's generic arguments by name and to the resolved type using `Self`. + +For example: + +```rust,ignore +#![feature(rustc_attrs)] + +#[rustc_on_unimplemented="an iterator over elements of type `{A}` \ + cannot be built from a collection of type `{Self}`"] +trait MyIterator { + fn next(&mut self) -> A; +} + +fn iterate_chars>(i: I) { + // ... +} + +fn main() { + iterate_chars(&[1, 2, 3][..]); +} +``` + +When the user compiles this, they will see the following; + +```txt +error[E0277]: the trait bound `&[{integer}]: MyIterator` is not satisfied + --> :14:5 + | +14 | iterate_chars(&[1, 2, 3][..]); + | ^^^^^^^^^^^^^ an iterator over elements of type `char` cannot be built from a collection of type `&[{integer}]` + | + = help: the trait `MyIterator` is not implemented for `&[{integer}]` + = note: required by `iterate_chars` +``` + +`rustc_on_unimplemented` also supports advanced filtering for better targeting +of messages, as well as modifying specific parts of the error message. You +target the text of: + + - the main error message (`message`) + - the label (`label`) + - an extra note (`note`) + +For example, the following attribute + +```rust,ignore +#[rustc_on_unimplemented( + message="message", + label="label", + note="note" +)] +trait MyIterator { + fn next(&mut self) -> A; +} +``` + +Would generate the following output: + +```text +error[E0277]: message + --> :14:5 + | +14 | iterate_chars(&[1, 2, 3][..]); + | ^^^^^^^^^^^^^ label + | + = note: note + = help: the trait `MyIterator` is not implemented for `&[{integer}]` + = note: required by `iterate_chars` +``` + +To allow more targeted error messages, it is possible to filter the +application of these fields based on a variety of attributes when using +`on`: + + - `crate_local`: whether the code causing the trait bound to not be + fulfilled is part of the user's crate. This is used to avoid suggesting + code changes that would require modifying a dependency. + - Any of the generic arguments that can be substituted in the text can be + referred by name as well for filtering, like `Rhs="i32"`, except for + `Self`. + - `_Self`: to filter only on a particular calculated trait resolution, like + `Self="std::iter::Iterator"`. This is needed because `Self` is a + keyword which cannot appear in attributes. + - `direct`: user-specified rather than derived obligation. + - `from_method`: usable both as boolean (whether the flag is present, like + `crate_local`) or matching against a particular method. Currently used + for `try`. + - `from_desugaring`: usable both as boolean (whether the flag is present) + or matching against a particular desugaring. The desugaring is identified + with its variant name in the `DesugaringKind` enum. + +For example, the `Iterator` trait can be annotated in the following way: + +```rust,ignore +#[rustc_on_unimplemented( + on( + _Self="&str", + note="call `.chars()` or `.as_bytes()` on `{Self}" + ), + message="`{Self}` is not an iterator", + label="`{Self}` is not an iterator", + note="maybe try calling `.iter()` or a similar method" +)] +pub trait Iterator {} +``` + +Which would produce the following outputs: + +```text +error[E0277]: `Foo` is not an iterator + --> src/main.rs:4:16 + | +4 | for foo in Foo {} + | ^^^ `Foo` is not an iterator + | + = note: maybe try calling `.iter()` or a similar method + = help: the trait `std::iter::Iterator` is not implemented for `Foo` + = note: required by `std::iter::IntoIterator::into_iter` + +error[E0277]: `&str` is not an iterator + --> src/main.rs:5:16 + | +5 | for foo in "" {} + | ^^ `&str` is not an iterator + | + = note: call `.chars()` or `.bytes() on `&str` + = help: the trait `std::iter::Iterator` is not implemented for `&str` + = note: required by `std::iter::IntoIterator::into_iter` +``` + +If you need to filter on multiple attributes, you can use `all`, `any` or +`not` in the following way: + +```rust,ignore +#[rustc_on_unimplemented( + on( + all(_Self="&str", T="std::string::String"), + note="you can coerce a `{T}` into a `{Self}` by writing `&*variable`" + ) +)] +pub trait From: Sized { /* ... */ } +``` From 6f66e0573f8f3edab721ef0f3a59061049ef3772 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 28 Oct 2019 08:06:57 +0200 Subject: [PATCH 0703/1812] fix some whitespace issues (#483) Also, those are not sh scripts --- src/compiler-documenting.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/src/compiler-documenting.md b/src/compiler-documenting.md index 97636fad5..5c80c3d1c 100644 --- a/src/compiler-documenting.md +++ b/src/compiler-documenting.md @@ -1,21 +1,21 @@ # Documenting rustc -You might want to build documentation of the various components +You might want to build documentation of the various components available like the standard library. There’s two ways to go about this. - You can run rustdoc directly on the file to make sure the HTML is - correct, which is fast. Alternatively, you can build the documentation - as part of the build process through x.py. Both are viable methods + You can run rustdoc directly on the file to make sure the HTML is + correct, which is fast. Alternatively, you can build the documentation + as part of the build process through x.py. Both are viable methods since documentation is more about the content. ## Document everything - ```bash - ./x.py doc - ``` +```ignore +./x.py doc +``` ## If you want to avoid the whole Stage 2 build -```bash +```ignore ./x.py doc --stage 1 ``` @@ -24,10 +24,10 @@ and then it documents the files. ## Document specific components -```bash - ./x.py doc src/doc/book - ./x.py doc src/doc/nomicon - ./x.py doc src/doc/book src/libstd +```ignore +./x.py doc src/doc/book +./x.py doc src/doc/nomicon +./x.py doc src/doc/book src/libstd ``` Much like individual tests or building certain components you can build only @@ -41,14 +41,14 @@ But, when enabled, compiler documentation does include internal items. Next open up config.toml and make sure these two lines are set to true: -```bash +```toml docs = true compiler-docs = true ``` When you want to build the compiler docs as well run this command: -```bash +```ignore ./x.py doc ``` @@ -59,4 +59,4 @@ and build the normally hidden compiler docs! The documentation for the rust components are found at [rustc doc]. -[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ \ No newline at end of file +[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ From f668658233c1c604212fe1cd6bec42771d53bb04 Mon Sep 17 00:00:00 2001 From: Mark Rousskov Date: Tue, 29 Oct 2019 17:09:10 -0400 Subject: [PATCH 0704/1812] Add some docs around the lint store (#476) * Add some docs around the lint store * Update src/diagnostics.md Co-Authored-By: Niko Matsakis * restructure --- src/SUMMARY.md | 1 + src/diagnostics.md | 51 ++++++++++++----- src/diagnostics/lintstore.md | 105 +++++++++++++++++++++++++++++++++++ 3 files changed, 144 insertions(+), 13 deletions(-) create mode 100644 src/diagnostics/lintstore.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index fdec4ffde..770686f01 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -23,6 +23,7 @@ - [Coding conventions](./conventions.md) - [crates.io Dependencies](./crates-io.md) - [Emitting Errors and other Diagnostics](diagnostics.md) + - [`LintStore`](./diagnostics/lintstore.md) - [ICE-breaker teams](ice-breaker/about.md) - [LLVM ICE-breakers](ice-breaker/llvm.md) - [Part 2: How rustc works](./part-2-intro.md) diff --git a/src/diagnostics.md b/src/diagnostics.md index b096d6a54..62baa7b60 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -171,11 +171,17 @@ crate. [builtin]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/index.html -Each lint is defined as a `struct` that implements the `LintPass` `trait`. The -trait implementation allows you to check certain syntactic constructs the -linter walks the source code. You can then choose to emit lints in a very -similar way to compile errors. Finally, you register the lint to actually get -it to be run by the compiler by using the `declare_lint!` macro. +Every lint is implemented via a `struct` that implements the `LintPass` `trait` +(you also implement one of the more specific lint pass traits, either +`EarlyLintPass` or `LateLintPass`). The trait implementation allows you to +check certain syntactic constructs as the linter walks the source code. You can +then choose to emit lints in a very similar way to compile errors. + +You also declare the metadata of a particular lint via the `declare_lint!` +macro. This includes the name, the default level, a short description, and some +more details. + +Note that the lint and the lint pass must be registered with the compiler. For example, the following lint checks for uses of `while true { ... }` and suggests using `loop { ... }` instead. @@ -196,11 +202,15 @@ declare_lint! { #[derive(Copy, Clone)] pub struct WhileTrue; -impl LintPass for WhileTrue { - fn get_lints(&self) -> LintArray { - lint_array!(WHILE_TRUE) - } -} +// This declares a lint pass, providing a list of associated lints. The +// compiler currently doesn't use the associated lints directly (e.g., to not +// run the pass or otherwise check that the pass emits the appropriate set of +// lints). However, it's good to be accurate here as it's possible that we're +// going to register the lints via the get_lints method on our lint pass (that +// this macro generates). +impl_lint_pass!( + WhileTrue => [WHILE_TRUE], +); // LateLintPass has lots of methods. We only override the definition of // `check_expr` for this lint because that's all we need, but you could @@ -242,9 +252,24 @@ declare_lint! { This makes the `ANONYMOUS_PARAMETERS` lint allow-by-default in the 2015 edition but warn-by-default in the 2018 edition. -Lints that represent an incompatibility (i.e. error) in the upcoming edition -should also be registered as `FutureIncompatibilityLint`s in -[`register_builtins`][rbuiltins] function in [`rustc_lint::lib`][builtin]. +A future-incompatible lint should be declared with the `@future_incompatible` +additional "field": + +```rust,ignore +declare_lint! { + pub ANONYMOUS_PARAMETERS, + Allow, + "detects anonymous parameters", + @future_incompatible = FutureIncompatibleInfo { + reference: "issue #41686 ", + edition: Some(Edition::Edition2018), + }; +} +``` + +If you need a combination of options that's not supported by the +`declare_lint!` macro, you can always define your own static with a type of +`&Lint` but this is currently linted against in the compiler tree. ### Lint Groups diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md new file mode 100644 index 000000000..50538c2b5 --- /dev/null +++ b/src/diagnostics/lintstore.md @@ -0,0 +1,105 @@ +# Lints + +This page documents some of the machinery around lint registration and how we +run lints in the compiler. + +The `LintStore` is the central piece of infrastructure, around which everything +rotates. It's not available during the early parts of compilation (i.e., before +TyCtxt) in most code, as we need to fill it in with all of the lints, which can only happen after +plugin registration. + +## Lints vs. lint passes + +There are two parts to the linting mechanism within the compiler: lints and lint passes. +Unfortunately, a lot of the documentation we have refers to both of these as just "lints." + +First, we have the lint declarations themselves: this is where the name and default lint level and +other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which +boils down to a static with type `&rustc::lint::Lint`. We lint against direct declarations without +the use of the macro today (though this may change in the future, as the macro is somewhat unwieldy +to add new fields to, like all macros by example). + +Lint declarations don't carry any "state" - they are merely global identifers and descriptions of +lints. We assert at runtime that they are not registered twice (by lint name). + +Lint passes are the meat of any lint. Notably, there is not a one-to-one relationship between +lints and lint passes; a lint might not have any lint pass that emits it, it could have many, or +just one -- the compiler doesn't track whether a pass is in any way associated with a particular +lint, and frequently lints are emitted as part of other work (e.g., type checking, etc.). + +## Registration + +### High-level overview + +The lint store is created and all lints are registered during plugin registration, in +[`rustc_interface::register_plugins`]. There are three 'sources' of lint: the internal lints, plugin +lints, and `rustc_interface::Config` `register_lints`. All are registered here, in +`register_plugins`. + +Once the registration is complete, we "freeze" the lint store by placing it in an `Lrc`. Later in +the driver, it's passed into the `GlobalCtxt` constructor where it lives in an immutable form from +then on. + +Lints are registered via the [`LintStore::register_lint`] function. This should +happen just once for any lint, or an ICE will occur. + +Lint passes are registered separately into one of the categories (pre-expansion, +early, late, late module). Passes are registered as a closure -- i.e., `impl +Fn() -> Box`, where `dyn X` is either an early or late lint pass trait +object. When we run the lint passes, we run the closure and then invoke the lint +pass methods, which take `&mut self` -- lint passes can keep track of state +internally. + +#### Internal lints + +Note, these include both rustc-internal lints, and the traditional lints, like, for example the dead +code lint. + +These are primarily described in two places: `rustc::lint::builtin` and `rustc_lint::builtin`. The +first provides the definitions for the lints themselves, and the latter provides the lint pass +definitions (and implementations). + +The internal lint registration happens in the [`rustc_lint::register_builtins`] function, along with +the [`rustc_lint::register_internals`] function. More generally, the LintStore "constructor" +function which is *the* way to get a `LintStore` in the compiler (you should not construct it +directly) is [`rustc_lint::new_lint_store`]; it calls the registration functions. + +#### Plugin lints + +This is one of the primary use cases remaining for plugins/drivers. Plugins are given access to the +mutable `LintStore` during registration to call any functions they need on the `LintStore`, just +like rustc code. Plugins are intended to declare lints with the `plugin` field set to true (e.g., by +way of the [`declare_tool_lint!`] macro), but this is purely for diagnostics and help text; +otherwise plugin lints are mostly just as first class as rustc builtin lints. + +#### Driver lints + +These are the lints provided by drivers via the `rustc_interface::Config` [`register_lints`] field, +which is a callback. Drivers should, if finding it already set, call the function currently set +within the callback they add. The best way for drivers to get access to this is by overriding the +`Callbacks::config` function which gives them direct access to the `Config` structure. + +## Compiler lint passes are combined into one pass + +Within the compiler, for performance reasons, we usually do not register dozens +of lint passes. Instead, we have a single lint pass of each variety +(e.g. `BuiltinCombinedModuleLateLintPass`) which will internally call all of the +individual lint passes; this is because then we get the benefits of static over +dynamic dispatch for each of the (often empty) trait methods. + +Ideally, we'd not have to do this, since it certainly adds to the complexity of +understanding the code. However, with the current type-erased lint store +approach, it is beneficial to do so for performance reasons. + +New lints being added likely want to join one of the existing declarations like +`late_lint_mod_passes` in `librustc_lint/lib.rs`, which would then +auto-propagate into the other. + +[`LintStore::register_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.LintStore.html#method.register_lints +[`rustc_interface::register_plugins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.register_plugins.html) +[`rustc_lint::register_builtins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_builtins.html +[`rustc_lint::register_internals`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_internals.html +[`rustc_lint::new_lint_store`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.new_lint_store.html +[`rustc::declare_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/macro.declare_lint.html +[`rustc::declare_tool_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/macro.declare_tool_lint.html +[`register_lints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Config.html#structfield.register_lints From 8b86a6ee91d9ab6cfeefaa9f5cbcef13beb8fe73 Mon Sep 17 00:00:00 2001 From: Mark Rousskov Date: Wed, 30 Oct 2019 09:32:16 -0400 Subject: [PATCH 0705/1812] Fixup links in lintstore docs (#487) --- src/diagnostics/lintstore.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index 50538c2b5..5ce13f967 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -33,7 +33,7 @@ lint, and frequently lints are emitted as part of other work (e.g., type checkin The lint store is created and all lints are registered during plugin registration, in [`rustc_interface::register_plugins`]. There are three 'sources' of lint: the internal lints, plugin -lints, and `rustc_interface::Config` `register_lints`. All are registered here, in +lints, and `rustc_interface::Config` [`register_lints`]. All are registered here, in `register_plugins`. Once the registration is complete, we "freeze" the lint store by placing it in an `Lrc`. Later in @@ -96,10 +96,10 @@ New lints being added likely want to join one of the existing declarations like auto-propagate into the other. [`LintStore::register_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.LintStore.html#method.register_lints -[`rustc_interface::register_plugins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.register_plugins.html) +[`rustc_interface::register_plugins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.register_plugins.html [`rustc_lint::register_builtins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_builtins.html [`rustc_lint::register_internals`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_internals.html [`rustc_lint::new_lint_store`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.new_lint_store.html -[`rustc::declare_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/macro.declare_lint.html -[`rustc::declare_tool_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/macro.declare_tool_lint.html +[`declare_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/macro.declare_lint.html +[`declare_tool_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/macro.declare_tool_lint.html [`register_lints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Config.html#structfield.register_lints From a448c07a56f04c1b00c3196d6058dd6451f34557 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Fri, 1 Nov 2019 17:36:47 +0000 Subject: [PATCH 0706/1812] Updated instructions for tracking issue (#488) * Updated instructions for tracking issue Removed link to Forge instructions for documentation since they no longer seem to exist. * Improved links and wording --- src/implementing_new_features.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 3055bf97a..73a6a40a0 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -99,15 +99,15 @@ for YOUR FEATURE". For tracking issues for features (as opposed to future-compat warnings), I don't think the description has to contain anything specific. Generally we put the list of items required -for stabilization using a github list, e.g. +for stabilization in a checklist, e.g., ```txt - **Steps:** +**Steps:** - - [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write - up mentoring instructions?) - - [ ] Adjust documentation ([see instructions on forge][doc-guide]) - - Note: no stabilization step here. +- [ ] Implement the RFC. (CC @rust-lang/compiler -- can anyone write + up mentoring instructions?) +- [ ] Adjust the documentation. ([See instructions on rustc-guide.](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#documentation-prs)) +- [ ] Stabilize the feature. ([See instructions on rustc-guide.](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#stabilization-pr)) ``` From 06908de77f28d447f8dda25a3f2b06dc2821533c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomasz=20Mi=C4=85sko?= Date: Fri, 18 Oct 2019 00:00:00 +0000 Subject: [PATCH 0707/1812] Sanitizers implementation in rustc --- src/SUMMARY.md | 1 + src/sanitizers.md | 68 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 69 insertions(+) create mode 100644 src/sanitizers.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 770686f01..453493d9a 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -94,6 +94,7 @@ - [Debugging LLVM](./codegen/debugging.md) - [Backend Agnostic Codegen](./codegen/backend-agnostic.md) - [Profile-guided Optimization](./profile-guided-optimization.md) + - [Sanitizers Support](./sanitizers.md) - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) --- diff --git a/src/sanitizers.md b/src/sanitizers.md new file mode 100644 index 000000000..6205433e5 --- /dev/null +++ b/src/sanitizers.md @@ -0,0 +1,68 @@ +# Sanitizers Support + +The rustc compiler contains basic support for following sanitizers: + +* [AddressSanitizer][clang-asan] a faster memory error detector. Can + detect out-of-bounds access to heap, stack, and globals, use after free, use + after return, double free, invalid free, memory leaks. +* [LeakSanitizer][clang-lsan] a run-time memory leak detector. +* [MemorySanitizer][clang-msan] a detector of uninitialized reads. +* [ThreadSanitizer][clang-tsan] a fast data race detector. + +## How to use the sanitizers? + +To enable a sanitizer compile with `-Zsanitizer=...` option, where value is one +of `address`, `leak`, `memory` or `thread`. For more details how to use +sanitizers please refer to [the unstable book](https://doc.rust-lang.org/unstable-book/). + +## How are sanitizers implemented in rustc? + +The implementation of sanitizers relies entirely on LLVM. It consists of +compile time instrumentation passes and runtime libraries. The role rustc plays +in the implementation is limited to the execution of the following steps: + +1. The sanitizer runtime libraries are part of the [compiler-rt] project, and + [will be built as an LLVM subproject][sanitizer-build] when enabled in + `config.toml`: + + ```toml + [build] + sanitizers = true + ``` + + The runtimes are [placed into target libdir][sanitizer-copy]. + +2. During LLVM code generation, the functions intended for instrumentation are + [marked][sanitizer-attribute] with `SanitizeAddress`, `SanitizeMemory`, or + `SanitizeThread` attribute. Currently those attributes are applied in + indiscriminate manner. but in principle they could be used to perform + instrumentation selectively. + +3. The LLVM IR generated by rustc is instrumented by [dedicated LLVM + passes][sanitizer-pass], different for each sanitizer. Instrumentation + passes are invoked after optimization passes. + +4. When producing an executable, the sanitizer specific runtime library is + [linked in][sanitizer-link]. The libraries are searched for in target libdir + relative to default system root, so that this process is not affected + by sysroot overrides used for example by cargo `-Zbuild-std` functionality. + +[compiler-rt]: https://github.com/llvm/llvm-project/tree/master/compiler-rt +[sanitizer-build]: https://github.com/rust-lang/rust/blob/87c3eedffba64830b67e54e75dd479f9fd83cc7d/src/bootstrap/native.rs#L220-L225 +[sanitizer-copy]: https://github.com/rust-lang/rust/blob/87c3eedffba64830b67e54e75dd479f9fd83cc7d/src/bootstrap/compile.rs#L269-L321 +[sanitizer-attribute]: https://github.com/rust-lang/rust/blob/1.38.0/src/librustc_codegen_llvm/declare.rs#L53-L66 +[sanitizer-pass]: https://github.com/rust-lang/rust/blob/1.38.0/src/librustc_codegen_ssa/back/write.rs#L406-L420 +[sanitizer-link]: https://github.com/rust-lang/rust/blob/87c3eedffba64830b67e54e75dd479f9fd83cc7d/src/librustc_codegen_ssa/back/link.rs#L729-L770 + +## Additional Information + +* [Sanitizers project page](https://github.com/google/sanitizers/wiki/) +* [AddressSanitizer in Clang][clang-asan] +* [LeakSanitizer in Clang][clang-lsan] +* [MemorySanitizer in Clang][clang-msan] +* [ThreadSanitizer in Clang][clang-tsan] + +[clang-asan]: https://clang.llvm.org/docs/AddressSanitizer.html +[clang-lsan]: https://clang.llvm.org/docs/LeakSanitizer.html +[clang-msan]: https://clang.llvm.org/docs/MemorySanitizer.html +[clang-tsan]: https://clang.llvm.org/docs/ThreadSanitizer.html From 2dd722b1736e0ca800c5a7a83b4efb84de4a2749 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Sun, 27 Oct 2019 23:10:32 +0100 Subject: [PATCH 0708/1812] Please don't rustfmt. --- src/conventions.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index 3660f3379..76933d574 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -114,14 +114,12 @@ you introduce some code following one strategy, then change it dramatically (versus adding to it) in a later commit, that 'back-and-forth' can be confusing. -**If you run rustfmt and the file was not already formatted, isolate -that into its own commit.** This is really the same as the previous -rule, but it's worth highlighting. It's ok to rustfmt files, but since -we do not currently run rustfmt all the time, that can introduce a lot -of noise into your commit. Please isolate that into its own -commit. This also makes rebases a lot less painful, since rustfmt -tends to cause a lot of merge conflicts, and having those isolated -into their own commit makes them easier to resolve. +**Only run rustfmt on new content.** One day, we might enforce formatting +for the rust-lang/rust repo. Meanwhile, we prefer that rustfmt not be run +on existing code as that will generate large diffs and will make git blame +harder to sift through. However, running `rustfmt` on new content, e.g. a +new file or a largely new part of a file is ok. Small formatting adjustments +nearby code you are already changing for other purposes are also ok. **No merges.** We do not allow merge commits into our history, other than those by bors. If you get a merge conflict, rebase instead via a From d3bfd4ad13e0f0dcba16e75499720e752251c2bf Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 5 Nov 2019 09:20:45 -0800 Subject: [PATCH 0709/1812] Fix some broken fragment links. --- src/appendix/glossary.md | 2 +- src/borrow_check/region_inference.md | 2 +- src/tests/intro.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index d9867023e..5b0f7cfa2 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -61,7 +61,7 @@ rib | a data structure in the name resolver that keeps trac sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference.html#placeholders-and-universes) for more details. +placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index a524fe0f0..5ae096574 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -100,7 +100,7 @@ The kinds of region elements are as follows: - There is an element `!1` for each placeholder region `!1`. This corresponds (intuitively) to some unknown set of other elements – for details on placeholders, see the section - [placeholders and universes](#placeholder). + [placeholders and universes](region_inference/placeholders_and_universes.md). ## Constraints diff --git a/src/tests/intro.md b/src/tests/intro.md index c043da429..f818fc240 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -5,7 +5,7 @@ by the build system (`x.py test`). The main test harness for testing the compiler itself is a tool called compiletest (sources in the [`src/tools/compiletest`]). This section gives a brief overview of how the testing framework is setup, and then gets into some of the details -on [how to run tests](./running.html#ui) as well as +on [how to run tests](./running.html) as well as [how to add new tests](./adding.html). [`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest From dcd2b0c5d751acfaa2cb34774675e55b5a7ac02b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 10:51:36 -0600 Subject: [PATCH 0710/1812] add guidelines for future-incompat lints --- src/diagnostics.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/diagnostics.md b/src/diagnostics.md index 62baa7b60..9cfd5a3e1 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -271,6 +271,15 @@ If you need a combination of options that's not supported by the `declare_lint!` macro, you can always define your own static with a type of `&Lint` but this is currently linted against in the compiler tree. +#### Guidelines for creating a future incompatibility lint + +- Create a lint defaulting to warn as normal, with ideally the same error + message you would normally give. +- Add a suitable reference, typically an RFC or tracking issue. Go ahead + and include the full URL, sort items in ascending order of issue numbers. +- Later, change lint to error. +- Eventually, remove lint. + ### Lint Groups Lints can be turned on in groups. These groups are declared in the From 694d870cdcf82c0c6de1744c9e663e5b05944553 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 10:47:16 -0600 Subject: [PATCH 0711/1812] add discussion transcript so we don't lose it --- src/macro-expansion.md | 703 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 703 insertions(+) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 4a0eaeb48..d1f74ed8b 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -210,3 +210,706 @@ TODO: maybe something about macros 2.0? [code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax_expand/mbe/macro_rules [code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax_expand/mbe/macro_parser/fn.parse.html [parsing]: ./the-parser.html + + +# Discussion about hygiene + +The rest of this chapter is a dump of a discussion between `mark-i-m` and +`petrochenkov` about Macro Expansion and Hygiene. I am pasting it here so that +it never gets lost until we can make it into a proper chapter. + +```txt +mark-i-m: @Vadim Petrochenkov Hi :wave: +I was wondering if you would have a chance sometime in the next month or so to +just have a zulip discussion where you tell us (WG-learning) everything you +know about macros/expansion/hygiene. We were thinking this could be less formal +(and less work for you) than compiler lecture series lecture... thoughts? + +mark-i-m: The goal is to fill out that long-standing gap in the rustc-guide + +Vadim Petrochenkov: Ok, I'm at UTC+03:00 and generally available in the +evenings (or weekends). + +mark-i-m: @Vadim Petrochenkov Either of those works for me (your evenings are +about lunch time for me :) ) Is there a particular date that would work best +for you? + +mark-i-m: @WG-learning Does anyone else have a preferred date? + + Vadim Petrochenkov: + + Is there a particular date that would work best for you? + +Nah, not much difference. (If something changes for a specific day, I'll +notify.) + +Santiago Pastorino: week days are better, but I'd say let's wait for @Vadim +Petrochenkov to say when they are ready for it and we can set a date + +Santiago Pastorino: also, we should record this so ... I guess it doesn't +matter that much when :) + + mark-i-m: + + also, we should record this so ... I guess it doesn't matter that much when + :) + +@Santiago Pastorino My thinking was to just use zulip, so we would have the log + +mark-i-m: @Vadim Petrochenkov @WG-learning How about 2 weeks from now: July 24 +at 5pm UTC time (if I did the math right, that should be evening for Vadim) + +Amanjeev Sethi: i can try and do this but I am starting a new job that week so +cannot promise. + + Santiago Pastorino: + + Vadim Petrochenkov @WG-learning How about 2 weeks from now: July 24 at 5pm + UTC time (if I did the math right, that should be evening for Vadim) + +works perfect for me + +Santiago Pastorino: @mark-i-m I have access to the compiler calendar so I can +add something there + +Santiago Pastorino: let me know if you want to add an event to the calendar, I +can do that + +Santiago Pastorino: how long it would be? + + mark-i-m: + + let me know if you want to add an event to the calendar, I can do that + +mark-i-m: That could be good :+1: + + mark-i-m: + + how long it would be? + +Let's start with 30 minutes, and if we need to schedule another we cna + + Vadim Petrochenkov: + + 5pm UTC + +1-2 hours later would be better, 5pm UTC is not evening enough. + +Vadim Petrochenkov: How exactly do you plan the meeting to go (aka how much do +I need to prepare)? + + Santiago Pastorino: + + 5pm UTC + + 1-2 hours later would be better, 5pm UTC is not evening enough. + +Scheduled for 7pm UTC then + + Santiago Pastorino: + + How exactly do you plan the meeting to go (aka how much do I need to + prepare)? + +/cc @mark-i-m + +mark-i-m: @Vadim Petrochenkov + + How exactly do you plan the meeting to go (aka how much do I need to + prepare)? + +My hope was that this could be less formal than for a compiler lecture series, +but it would be nice if you could have in your mind a tour of the design and +the code + +That is, imagine that a new person was joining the compiler team and needed to +get up to speed about macros/expansion/hygiene. What would you tell such a +person? + +mark-i-m: @Vadim Petrochenkov Are we still on for tomorrow at 7pm UTC? + +Vadim Petrochenkov: Yes. + +Santiago Pastorino: @Vadim Petrochenkov @mark-i-m I've added an event on rust +compiler team calendar + +mark-i-m: @WG-learning @Vadim Petrochenkov Hello! + +mark-i-m: We will be starting in ~7 minutes + +mark-i-m: :wave: + +Vadim Petrochenkov: I'm here. + +mark-i-m: Cool :) + +Santiago Pastorino: hello @Vadim Petrochenkov + +mark-i-m: Shall we start? + +mark-i-m: First off, @Vadim Petrochenkov Thanks for doing this! + +Vadim Petrochenkov: Here's some preliminary data I prepared. + +Vadim Petrochenkov: Below I'll assume #62771 and #62086 has landed. + +Vadim Petrochenkov: Where to find the code: libsyntax_pos/hygiene.rs - +structures related to hygiene and expansion that are kept in global data (can +be accessed from any Ident without any context) libsyntax_pos/lib.rs - some +secondary methods like macro backtrace using primary methods from hygiene.rs +libsyntax_ext - implementations of built-in macros (including macro attributes +and derives) and some other early code generation facilities like injection of +standard library imports or generation of test harness. libsyntax/config.rs - +implementation of cfg/cfg_attr (they treated specially from other macros), +should probably be moved into libsyntax/ext. libsyntax/tokenstream.rs + +libsyntax/parse/token.rs - structures for compiler-side tokens, token trees, +and token streams. libsyntax/ext - various expansion-related stuff +libsyntax/ext/base.rs - basic structures used by expansion +libsyntax/ext/expand.rs - some expansion structures and the bulk of expansion +infrastructure code - collecting macro invocations, calling into resolve for +them, calling their expanding functions, and integrating the results back into +AST libsyntax/ext/placeholder.rs - the part of expand.rs responsible for +"integrating the results back into AST" basicallly, "placeholder" is a +temporary AST node replaced with macro expansion result nodes +libsyntax/ext/builer.rs - helper functions for building AST for built-in macros +in libsyntax_ext (and user-defined syntactic plugins previously), can probably +be moved into libsyntax_ext these days libsyntax/ext/proc_macro.rs + +libsyntax/ext/proc_macro_server.rs - interfaces between the compiler and the +stable proc_macro library, converting tokens and token streams between the two +representations and sending them through C ABI libsyntax/ext/tt - +implementation of macro_rules, turns macro_rules DSL into something with +signature Fn(TokenStream) -> TokenStream that can eat and produce tokens, +@mark-i-m knows more about this librustc_resolve/macros.rs - resolving macro +paths, validating those resolutions, reporting various "not found"/"found, but +it's unstable"/"expected x, found y" errors librustc/hir/map/def_collector.rs + +librustc_resolve/build_reduced_graph.rs - integrate an AST fragment freshly +expanded from a macro into various parent/child structures like module +hierarchy or "definition paths" + +Primary structures: HygieneData - global piece of data containing hygiene and +expansion info that can be accessed from any Ident without any context ExpnId - +ID of a macro call or desugaring (and also expansion of that call/desugaring, +depending on context) ExpnInfo/InternalExpnData - a subset of properties from +both macro definition and macro call available through global data +SyntaxContext - ID of a chain of nested macro definitions (identified by +ExpnIds) SyntaxContextData - data associated with the given SyntaxContext, +mostly a cache for results of filtering that chain in different ways Span - a +code location + SyntaxContext Ident - interned string (Symbol) + Span, i.e. a +string with attached hygiene data TokenStream - a collection of TokenTrees +TokenTree - a token (punctuation, identifier, or literal) or a delimited group +(anything inside ()/[]/{}) SyntaxExtension - a lowered macro representation, +contains its expander function transforming a tokenstream or AST into +tokenstream or AST + some additional data like stability, or a list of unstable +features allowed inside the macro. SyntaxExtensionKind - expander functions +may have several different signatures (take one token stream, or two, or a +piece of AST, etc), this is an enum that lists them +ProcMacro/TTMacroExpander/AttrProcMacro/MultiItemModifier - traits representing +the expander signatures (TODO: change and rename the signatures into something +more consistent) trait Resolver - a trait used to break crate dependencies (so +resolver services can be used in libsyntax, despite librustc_resolve and pretty +much everything else depending on libsyntax) ExtCtxt/ExpansionData - various +intermediate data kept and used by expansion infra in the process of its work +AstFragment - a piece of AST that can be produced by a macro (may include +multiple homogeneous AST nodes, like e.g. a list of items) Annotatable - a +piece of AST that can be an attribute target, almost same thing as AstFragment +except for types and patterns that can be produced by macros but cannot be +annotated with attributes (TODO: Merge into AstFragment) trait MacResult - a +"polymorphic" AST fragment, something that can turn into a different +AstFragment depending on its context (aka AstFragmentKind - item, or +expression, or pattern etc.) Invocation/InvocationKind - a structure describing +a macro call, these structures are collected by the expansion infra +(InvocationCollector), queued, resolved, expanded when resolved, etc. + +Primary algorithms / actions: TODO + +mark-i-m: Very useful :+1: + +mark-i-m: @Vadim Petrochenkov Zulip doesn't have an indication of typing, so +I'm not sure if you are waiting for me or not + +Vadim Petrochenkov: The TODO part should be about how a crate transitions from +the state "macros exist as written in source" to "all macros are expanded", but +I didn't write it yet. + +Vadim Petrochenkov: (That should probably better happen off-line.) + +Vadim Petrochenkov: Now, if you have any questions? + +mark-i-m: Thanks :) + +mark-i-m: /me is still reading :P + +mark-i-m: Ok + +mark-i-m: So I guess my first question is about hygiene, since that remains the +most mysterious to me... My understanding is that the parser outputs AST nodes, +where each node has a Span + +mark-i-m: In the absence of macros and desugaring, what does the syntax context +of an AST node look like? + +mark-i-m: @Vadim Petrochenkov + +Vadim Petrochenkov: Not each node, but many of them. When a node is not +macro-expanded, its context is 0. + +Vadim Petrochenkov: aka SyntaxContext::empty() + +Vadim Petrochenkov: it's a chain that consists of one expansion - expansion 0 +aka ExpnId::root. + +mark-i-m: Do all expansions start at root? + +Vadim Petrochenkov: Also, SyntaxContext:empty() is its own father. + +mark-i-m: Is this actually stored somewhere or is it a logical value? + +Vadim Petrochenkov: All expansion hyerarchies (there are several of them) start +at ExpnId::root. + +Vadim Petrochenkov: Vectors in HygieneData has entries for both ctxt == 0 and +expn_id == 0. + +Vadim Petrochenkov: I don't think anyone looks into them much though. + +mark-i-m: Ok + +Vadim Petrochenkov: Speaking of multiple hierarchies... + +mark-i-m: Go ahead :) + +Vadim Petrochenkov: One is parent (expn_id1) -> parent(expn_id2) -> ... + +Vadim Petrochenkov: This is the order in which macros are expanded. + +Vadim Petrochenkov: Well. + +Vadim Petrochenkov: When we are expanding one macro another macro is revealed +in its output. + +Vadim Petrochenkov: That's the parent-child relation in this hierarchy. + +Vadim Petrochenkov: InternalExpnData::parent is the child->parent link. + +mark-i-m: So in the above chain expn_id1 is the child? + +Vadim Petrochenkov: Yes. + +Vadim Petrochenkov: The second one is parent (SyntaxContext1) -> +parent(SyntaxContext2) -> ... + +Vadim Petrochenkov: This is about nested macro definitions. When we are +expanding one macro another macro definition is revealed in its output. + +Vadim Petrochenkov: SyntaxContextData::parent is the child->parent link here. + +Vadim Petrochenkov: So, SyntaxContext is the whole chain in this hierarchy, and +outer_expns are individual elements in the chain. + +mark-i-m: So for example, suppose I have the following: + +macro_rules! foo { () => { println!(); } } + +fn main() { foo!(); } + +Then AST nodes that are finally generated would have parent(expn_id_println) -> +parent(expn_id_foo), right? + +Vadim Petrochenkov: Pretty common construction (at least it was, before +refactorings) is SyntaxContext::empty().apply_mark(expn_id), which means... + + Vadim Petrochenkov: + + Then AST nodes that are finally generated would have + parent(expn_id_println) -> parent(expn_id_foo), right? + +Yes. + + mark-i-m: + + and outer_expns are individual elements in the chain. + +Sorry, what is outer_expns? + +Vadim Petrochenkov: SyntaxContextData::outer_expn + +mark-i-m: Thanks :) Please continue + +Vadim Petrochenkov: ...which means a token produced by a built-in macro (which +is defined in the root effectively). + +mark-i-m: Where does the expn_id come from? + +Vadim Petrochenkov: Or a stable proc macro, which are always considered to be +defined in the root because they are always cross-crate, and we don't have the +cross-crate hygiene implemented, ha-ha. + + Vadim Petrochenkov: + + Where does the expn_id come from? + +Vadim Petrochenkov: ID of the built-in macro call like line!(). + +Vadim Petrochenkov: Assigned continuously from 0 to N as soon as we discover +new macro calls. + +mark-i-m: Sorry, I didn't quite understand. Do you mean that only built-in +macros receive continuous IDs? + +Vadim Petrochenkov: So, the second hierarchy has a catch - the context +transplantation hack - +https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732. + + Vadim Petrochenkov: + + Do you mean that only built-in macros receive continuous IDs? + +Vadim Petrochenkov: No, all macro calls receive ID. + +Vadim Petrochenkov: Built-ins have the typical pattern +SyntaxContext::empty().apply_mark(expn_id) for syntax contexts produced by +them. + +mark-i-m: I see, but this pattern is only used for built-ins, right? + +Vadim Petrochenkov: And also all stable proc macros, see the comments above. + +mark-i-m: Got it + +Vadim Petrochenkov: The third hierarchy is call-site hierarchy. + +Vadim Petrochenkov: If foo!(bar!(ident)) expands into ident + +Vadim Petrochenkov: then hierarchy 1 is root -> foo -> bar -> ident + +Vadim Petrochenkov: but hierarchy 3 is root -> ident + +Vadim Petrochenkov: ExpnInfo::call_site is the child-parent link in this case. + +mark-i-m: When we expand, do we expand foo first or bar? Why is there a +hierarchy 1 here? Is that foo expands first and it expands to something that +contains bar!(ident)? + +Vadim Petrochenkov: Ah, yes, let's assume both foo and bar are identity macros. + +Vadim Petrochenkov: Then foo!(bar!(ident)) -> expand -> bar!(ident) -> expand +-> ident + +Vadim Petrochenkov: If bar were expanded first, that would be eager expansion - +https://github.com/rust-lang/rfcs/pull/2320. + +mark-i-m: And after we expand only foo! presumably whatever intermediate state +has heirarchy 1 of root->foo->(bar_ident), right? + +Vadim Petrochenkov: (We have it hacked into some built-in macros, but not +generally.) + + Vadim Petrochenkov: + + And after we expand only foo! presumably whatever intermediate state has + heirarchy 1 of root->foo->(bar_ident), right? + +Vadim Petrochenkov: Yes. + +mark-i-m: Got it :) + +mark-i-m: It looks like we have ~5 minutes left. This has been very helpful +already, but I also have more questions. Shall we try to schedule another +meeting in the future? + +Vadim Petrochenkov: Sure, why not. + +Vadim Petrochenkov: A thread for offline questions-answers would be good too. + + mark-i-m: + + A thread for offline questions-answers would be good too. + +I don't mind using this thread, since it already has a lot of info in it. We +also plan to summarize the info from this thread into the rustc-guide. + + Sure, why not. + +Unfortunately, I'm unavailable for a few weeks. Would August 21-ish work for +you (and @WG-learning )? + +mark-i-m: @Vadim Petrochenkov Thanks very much for your time and knowledge! + +mark-i-m: One last question: are there more hierarchies? + +Vadim Petrochenkov: Not that I know of. Three + the context transplantation +hack is already more complex than I'd like. + +mark-i-m: Yes, one wonders what it would be like if one also had to think about +eager expansion... + +Santiago Pastorino: sorry but I couldn't follow that much today, will read it +when I have some time later + +Santiago Pastorino: btw https://github.com/rust-lang/rustc-guide/issues/398 + +mark-i-m: @Vadim Petrochenkov Would 7pm UTC on August 21 work for a followup? + +Vadim Petrochenkov: Tentatively yes. + +mark-i-m: @Vadim Petrochenkov @WG-learning Does this still work for everyone? + +Vadim Petrochenkov: August 21 is still ok. + +mark-i-m: @WG-learning @Vadim Petrochenkov We will start in ~30min + +Vadim Petrochenkov: Oh. Thanks for the reminder, I forgot about this entirely. + +mark-i-m: Hello! + +Vadim Petrochenkov: (I'll be here in a couple of minutes.) + +Vadim Petrochenkov: Ok, I'm here. + +mark-i-m: Hi :) + +Vadim Petrochenkov: Hi. + +mark-i-m: so last time, we talked about the 3 context heirarchies + +Vadim Petrochenkov: Right. + +mark-i-m: Was there anything you wanted to add to that? If not, I think it +would be good to get a big-picture... Given some piece of rust code, how do we +get to the point where things are expanded and hygiene context is computed? + +mark-i-m: (I'm assuming that hygiene info is computed as we expand stuff, since +I don't think you can discover it beforehand) + +Vadim Petrochenkov: Ok, let's move from hygiene to expansion. + +Vadim Petrochenkov: Especially given that I don't remember the specific hygiene +algorithms like adjust in detail. + + Vadim Petrochenkov: + + Given some piece of rust code, how do we get to the point where things are + expanded + +So, first of all, the "some piece of rust code" is the whole crate. + +mark-i-m: Just to confirm, the algorithms are well-encapsulated, right? Like a +function or a struct as opposed to a bunch of conventions distributed across +the codebase? + +Vadim Petrochenkov: We run fully_expand_fragment in it. + + Vadim Petrochenkov: + + Just to confirm, the algorithms are well-encapsulated, right? + +Yes, the algorithmic parts are entirely inside hygiene.rs. + +Vadim Petrochenkov: Ok, some are in fn resolve_crate_root, but those are hacks. + +Vadim Petrochenkov: (Continuing about expansion.) If fully_expand_fragment is +run not on a whole crate, it means that we are performing eager expansion. + +Vadim Petrochenkov: Eager expansion is done for arguments of some built-in +macros that expect literals. + +Vadim Petrochenkov: It generally performs a subset of actions performed by the +non-eager expansion. + +Vadim Petrochenkov: So, I'll talk about non-eager expansion for now. + +mark-i-m: Eager expansion is not exposed as a language feature, right? i.e. it +is not possible for me to write an eager macro? + +Vadim Petrochenkov: +https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049 (vvv The +link is explained below vvv ) + + Vadim Petrochenkov: + + Eager expansion is not exposed as a language feature, right? i.e. it is not + possible for me to write an eager macro? + +Yes, it's entirely an ability of some built-in macros. + +Vadim Petrochenkov: Not exposed for general use. + +Vadim Petrochenkov: fully_expand_fragment works in iterations. + +Vadim Petrochenkov: Iterations looks roughly like this: +- Resolve imports in our partially built crate as much as possible. +- Collect as many macro invocations as possible from our partially built crate + (fn-like, attributes, derives) from the crate and add them to the queue. + + Vadim Petrochenkov: Take a macro from the queue, and attempt to resolve it. + + Vadim Petrochenkov: If it's resolved - run its expander function that + consumes tokens or AST and produces tokens or AST (depending on the macro + kind). + + Vadim Petrochenkov: (If it's not resolved, then put it back into the + queue.) + +Vadim Petrochenkov: ^^^ That's where we fill in the hygiene data associated +with ExpnIds. + +mark-i-m: When we put it back in the queue? + +mark-i-m: or do you mean the collect step in general? + +Vadim Petrochenkov: Once we resolved the macro call to the macro definition we +know everything about the macro and can call set_expn_data to fill in its +properties in the global data. + +Vadim Petrochenkov: I mean, immediately after successful resolution. + +Vadim Petrochenkov: That's the first part of hygiene data, the second one is +associated with SyntaxContext rather than with ExpnId, it's filled in later +during expansion. + +Vadim Petrochenkov: So, after we run the macro's expander function and got a +piece of AST (or got tokens and parsed them into a piece of AST) we need to +integrate that piece of AST into the big existing partially built AST. + +Vadim Petrochenkov: This integration is a really important step where the next +things happen: +- NodeIds are assigned. + + Vadim Petrochenkov: "def paths"s and their IDs (DefIds) are created + + Vadim Petrochenkov: Names are put into modules from the resolver point of + view. + +Vadim Petrochenkov: So, we are basically turning some vague token-like mass +into proper set in stone hierarhical AST and side tables. + +Vadim Petrochenkov: Where exactly this happens - NodeIds are assigned by +InvocationCollector (which also collects new macro calls from this new AST +piece and adds them to the queue), DefIds are created by DefCollector, and +modules are filled by BuildReducedGraphVisitor. + +Vadim Petrochenkov: These three passes run one after another on every AST +fragment freshly expanded from a macro. + +Vadim Petrochenkov: After expanding a single macro and integrating its output +we again try to resolve all imports in the crate, and then return to the big +queue processing loop and pick up the next macro. + +Vadim Petrochenkov: Repeat until there's no more macros. Vadim Petrochenkov: + +mark-i-m: The integration step is where we would get parser errors too right? + +mark-i-m: Also, when do we know definitively that resolution has failed for +particular ident? + + Vadim Petrochenkov: + + The integration step is where we would get parser errors too right? + +Yes, if the macro produced tokens (rather than AST directly) and we had to +parse them. + + Vadim Petrochenkov: + + when do we know definitively that resolution has failed for particular + ident? + +So, ident is looked up in a number of scopes during resolution. From closest +like the current block or module, to far away like preludes or built-in types. + +Vadim Petrochenkov: If lookup is certainly failed in all of the scopes, then +it's certainly failed. + +mark-i-m: This is after all expansions and integrations are done, right? + +Vadim Petrochenkov: "Certainly" is determined differently for different scopes, +e.g. for a module scope it means no unexpanded macros and no unresolved glob +imports in that module. + + Vadim Petrochenkov: + + This is after all expansions and integrations are done, right? + +For macro and import names this happens during expansions and integrations. + +mark-i-m: Makes sense + +Vadim Petrochenkov: For all other names we certainly know whether a name is +resolved successfully or not on the first attempt, because no new names can +appear. + +Vadim Petrochenkov: (They are resolved in a later pass, see +librustc_resolve/late.rs.) + +mark-i-m: And if at the end of the iteration, there are still things in the +queue that can't be resolve, this represents an error, right? + +mark-i-m: i.e. an undefined macro? + +Vadim Petrochenkov: Yes, if we make no progress during an iteration, then we +are stuck and that state represent an error. + +Vadim Petrochenkov: We attempt to recover though, using dummies expanding into +nothing or ExprKind::Err or something like that for unresolved macros. + +mark-i-m: This is for the purposes of diagnostics, though, right? + +Vadim Petrochenkov: But if we are going through recovery, then compilation must +result in an error anyway. + +Vadim Petrochenkov: Yes, that's for diagnostics, without recovery we would +stuck at the first unresolved macro or import. Vadim Petrochenkov: + +So, about the SyntaxContext hygiene... + +Vadim Petrochenkov: New syntax contexts are created during macro expansion. + +Vadim Petrochenkov: If the token had context X before being produced by a +macro, e.g. here ident has context SyntaxContext::root(): Vadim Petrochenkov: + +macro m() { ident } + +Vadim Petrochenkov: , then after being produced by the macro it has context X +-> macro_id. + +Vadim Petrochenkov: I.e. our ident has context ROOT -> id(m) after it's +produced by m. + +Vadim Petrochenkov: The "chaining operator" -> is apply_mark in compiler code. +Vadim Petrochenkov: + +macro m() { macro n() { ident } } + +Vadim Petrochenkov: In this example the ident has context ROOT originally, then +ROOT -> id(m), then ROOT -> id(m) -> id(n). + +Vadim Petrochenkov: Note that these chains are not entirely determined by their +last element, in other words ExpnId is not isomorphic to SyntaxCtxt. + +Vadim Petrochenkov: Couterexample: Vadim Petrochenkov: + +macro m($i: ident) { macro n() { ($i, bar) } } + +m!(foo); + +Vadim Petrochenkov: foo has context ROOT -> id(n) and bar has context ROOT -> +id(m) -> id(n) after all the expansions. + +mark-i-m: Cool :) + +mark-i-m: It looks like we are out of time + +mark-i-m: Is there anything you wanted to add? + +mark-i-m: We can schedule another meeting if you would like + +Vadim Petrochenkov: Yep, 23.06 already. No, I think this is an ok point to +stop. + +mark-i-m: :+1: + +mark-i-m: Thanks @Vadim Petrochenkov ! This was very helpful + +Vadim Petrochenkov: Yeah, we can schedule another one. So far it's been like 1 +hour of meetings per month? Certainly not a big burden. +``` From 73f6cdfe3e9027cdad2f7ce7252d7eda663b8492 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 11:18:49 -0600 Subject: [PATCH 0712/1812] remove all the hacks, add some improvements --- .travis.yml | 4 ++-- book.toml | 3 ++- ci/build.sh | 10 ---------- ci/install.sh | 4 ++-- 4 files changed, 6 insertions(+), 15 deletions(-) delete mode 100755 ci/build.sh diff --git a/.travis.yml b/.travis.yml index dedec4568..50b7d6b95 100644 --- a/.travis.yml +++ b/.travis.yml @@ -4,7 +4,7 @@ rust: cache: - cargo - directories: - - $HOME/linkcheck/ + - book/linkcheck/ before_install: - shopt -s globstar - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md @@ -12,7 +12,7 @@ install: - source ~/.cargo/env || true - bash -x ci/install.sh script: -- bash -x ci/build.sh +- mdbook build - mdbook test notifications: email: diff --git a/book.toml b/book.toml index 1d207bf22..b5bced996 100644 --- a/book.toml +++ b/book.toml @@ -11,6 +11,7 @@ create-missing = false [output.html.search] [output.linkcheck] -command = "sed 's/.*//'" # tell mdbook not to run, since we want to run it manually follow-web-links = true exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "dl\\.acm\\.org" ] +cache-timeout = 172800 +warning-policy = "error" diff --git a/ci/build.sh b/ci/build.sh deleted file mode 100755 index 504957b3f..000000000 --- a/ci/build.sh +++ /dev/null @@ -1,10 +0,0 @@ -#!/bin/bash -x - -set -e - -mkdir -p book/ -cp -r $HOME/linkcheck/ book/ -RUST_LOG=mdbook_linkcheck=debug mdbook-linkcheck -s -cp -r book/linkcheck $HOME/ - -mdbook build diff --git a/ci/install.sh b/ci/install.sh index a81e21c56..5cb2f41fc 100755 --- a/ci/install.sh +++ b/ci/install.sh @@ -20,5 +20,5 @@ function cargo_install() { fi } -cargo_install mdbook 0.3.1 -cargo_install mdbook-linkcheck 0.4.0 +cargo_install mdbook 0.3.4 +cargo_install mdbook-linkcheck 0.5.0 From e44ca1f9d1bb7899eb848cdb782238b1365442a9 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 11:29:51 -0600 Subject: [PATCH 0713/1812] fix broken links --- src/borrow_check/moves_and_initialization/move_paths.md | 1 + src/borrow_check/region_inference/member_constraints.md | 2 +- src/codegen/backend-agnostic.md | 2 ++ src/variance.md | 2 +- 4 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index 157a9eaf3..9b8cbd47a 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -88,6 +88,7 @@ If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], can do that using the [`MovePathLookup`] structure found in the [`rev_lookup`] field of [`MoveData`]. There are two different methods: +[`MoveData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html [`MovePathLookup`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html [`rev_lookup`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#structfield.rev_lookup diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 7e254f0a2..0435ff8c8 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -97,7 +97,7 @@ placement of impl Trait, though in the future it may not be the case. We take some advantage of this fact, as it simplifies the current code. In particular, we don't have to consider a case like `'0 member of ['1, 'static]`, in which the value of both `'0` and `'1` are being -inferred and hence changing. See [rust-lang/rust#61773] for more +inferred and hence changing. See [rust-lang/rust#61773][#61773] for more information. [#61773]: https://github.com/rust-lang/rust/issues/61773 diff --git a/src/codegen/backend-agnostic.md b/src/codegen/backend-agnostic.md index b6436b679..3bf1bde83 100644 --- a/src/codegen/backend-agnostic.md +++ b/src/codegen/backend-agnostic.md @@ -4,6 +4,8 @@ In the future, it would be nice to allow other codegen backends (e.g. [Cranelift][cranelift]). To this end, `librustc_codegen_ssa` provides an abstract interface for all backends to implenent. +[cranelift]: https://github.com/CraneStation/cranelift + > The following is a copy/paste of a README from the rust-lang/rust repo. > Please submit a PR if it needs updating. diff --git a/src/variance.md b/src/variance.md index c6a1a320b..af23330e8 100644 --- a/src/variance.md +++ b/src/variance.md @@ -99,7 +99,7 @@ parameter `X` with respect to its defining class. `Term x Term` represents the "variance transform" as defined in the paper: > If the variance of a type variable `X` in type expression `E` is `V2` - and the definition-site variance of the [corresponding] type parameter + and the definition-site variance of the corresponding type parameter of a class `C` is `V1`, then the variance of `X` in the type expression `C` is `V3 = V1.xform(V2)`. From 4729cfe4856c2f25d1f2defc419d636552ea25e5 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 5 Nov 2019 11:32:44 -0600 Subject: [PATCH 0714/1812] Add travis badge to README --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index a5481e82c..12d46b4e5 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,6 @@ +![Travis CI badge](https://api.travis-ci.com/rust-lang/rustc-guide.svg?branch=master) + + This is a collaborative effort to build a guide that explains how rustc works. The aim of the guide is to help new contributors get oriented to rustc, as well as to help more experienced folks in figuring out From b69fcafb513d8fa1cb02ea8f771c80b1c1aec626 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sun, 3 Nov 2019 21:50:07 +0100 Subject: [PATCH 0715/1812] expand and update Miri description --- src/miri.md | 107 ++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 82 insertions(+), 25 deletions(-) diff --git a/src/miri.md b/src/miri.md index aee2376f1..77ae8f93d 100644 --- a/src/miri.md +++ b/src/miri.md @@ -55,50 +55,72 @@ Before the evaluation, a virtual memory location (in this case essentially a `vec![u8; 4]` or `vec![u8; 8]`) is created for storing the evaluation result. At the start of the evaluation, `_0` and `_1` are -`ConstValue::Scalar(Scalar::Undef)`. When the initialization of `_1` is invoked, the +`Operand::Immediate(Immediate::Scalar(ScalarMaybeUndef::Undef))`. +This is quite a mouthful: [`Operand`] can represent either data stored somewhere in the [interpreter memory](#memory) (`Operand::Indirect`), or (as an optimization) immediate data stored in-line. +And [`Immediate`] can either be a single (potentially uninitialized) [scalar value][`Scalar`] (integer or thin pointer), or a pair of two of them. +In our case, the single scalar value is *not* (yet) initialized. + +When the initialization of `_1` is invoked, the value of the `FOO` constant is required, and triggers another call to `tcx.const_eval`, which will not be shown here. If the evaluation of FOO is -successful, 42 will be subtracted by its value `4096` and the result stored in -`_1` as `ConstValue::ScalarPair(Scalar::Bytes(4054), Scalar::Bytes(0))`. The first +successful, `42` will be subtracted from its value `4096` and the result stored in +`_1` as `Operand::Immediate(Immediate::ScalarPair(Scalar::Raw { data: 4054, .. }, Scalar::Raw { data: 0, .. })`. The first part of the pair is the computed value, the second part is a bool that's true if -an overflow happened. +an overflow happened. A `Scalar::Raw` also stores the size (in bytes) of this scalar value; we are eliding that here. The next statement asserts that said boolean is `0`. In case the assertion fails, its error message is used for reporting a compile-time error. -Since it does not fail, `ConstValue::Scalar(Scalar::Bytes(4054))` is stored in the +Since it does not fail, `Operand::Immediate(Immediate::Scalar(Scalar::Raw { data: 4054, .. }))` is stored in the virtual memory was allocated before the evaluation. `_0` always refers to that location directly. -After the evaluation is done, the virtual memory allocation is interned into the -`TyCtxt`. Future evaluations of the same constants will not actually invoke -miri, but just extract the value from the interned allocation. - -The `tcx.const_eval` function has one additional feature: it will not return a -`ByRef(interned_allocation_id)`, but a `Scalar(computed_value)` if possible. This -makes using the result much more convenient, as no further queries need to be +After the evaluation is done, the return value is converted from [`Operand`] to [`ConstValue`] by [`op_to_const`]: +the former representation is geared towards what is needed *during* cost evaluation, while [`ConstValue`] +is shaped by the needs of the remaining parts of the compiler that consume the results of const evaluation. +As part of this conversion, for types with scalar values, even if +the resulting [`Operand`] is `Indirect`, it will return an immediate `ConstValue::Scalar(computed_value)` (instead of the usual `ConstValue::ByRef`). +This makes using the result much more efficient and also more convenient, as no further queries need to be executed in order to get at something as simple as a `usize`. +Future evaluations of the same constants will not actually invoke +Miri, but just use the cached result. + +[`Operand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.Operand.html +[`Immediate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.Immediate.html +[`ConstValue`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.ConstValue.html +[`Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.Scalar.html +[`op_to_const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/fn.op_to_const.html + ## Datastructures -Miri's core datastructures can be found in +Miri's outside-facing datastructures can be found in [librustc/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc/mir/interpret). -This is mainly the error enum and the `ConstValue` and `Scalar` types. A `ConstValue` can -be either `Scalar` (a single `Scalar`), `ScalarPair` (two `Scalar`s, usually fat -pointers or two element tuples) or `ByRef`, which is used for anything else and +This is mainly the error enum and the [`ConstValue`] and [`Scalar`] types. A `ConstValue` can +be either `Scalar` (a single `Scalar`, i.e., integer or thin pointer), +`Slice` (to represent byte slices and strings, as needed for pattern matching) or `ByRef`, which is used for anything else and refers to a virtual allocation. These allocations can be accessed via the methods on `tcx.interpret_interner`. +A `Scalar` is either some `Raw` integer or a pointer; see [the next section](#memory) for more on that. -If you are expecting a numeric result, you can use `unwrap_usize` (panics on -anything that can't be representad as a `u64`) or `assert_usize` which results -in an `Option` yielding the `Scalar` if possible. +If you are expecting a numeric result, you can use `eval_usize` (panics on +anything that can't be representad as a `u64`) or `try_eval_usize` which results +in an `Option` yielding the `Scalar` if possible. -## Allocations +## Memory -A miri allocation is either a byte sequence of the memory or an `Instance` in -the case of function pointers. Byte sequences can additionally contain -relocations that mark a group of bytes as a pointer to another allocation. The -actual bytes at the relocation refer to the offset inside the other allocation. +To support any kind of pointers, Miri needs to have a "virtual memory" that the pointers can point to. +This is implemented in the [`Memory`] type. +In the simplest model, every global variable, stack variable and every dynamic allocation corresponds to an [`Allocation`] in that memory. +(Actually using an allocation for every MIR stack variable would be very inefficient; that's why we have `Operand::Immediate` for stack variables that are both small and never have their address taken. +But that is purely an optimization.) + +Such an `Allocation` is basically just a sequence of `u8` storing the value of each byte in this allocation. +(Plus some extra data, see below.) +Every `Allocation` has a globally unique `AllocId` assigned in `Memory`. +With that, a [`Pointer`] consists of a pair of an `AllocId` (indicating the allocation) and an offset into the allocation (indicating which byte of the allocation the pointer points to). +It may seem odd that a `Pointer` is not just an integer address, but remember that during const evaluation, we cannot know at which actual integer address the allocation will end up -- so we use `AllocId` as symbolic base addresses, which means we need a separate offset. +(As an aside, it turns out that pointers at run-time are [more than just integers, too](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#pointer-provenance).) These allocations exist so that references and raw pointers have something to point to. There is no global linear heap in which things are allocated, but each @@ -106,7 +128,42 @@ allocation (be it for a local variable, a static or a (future) heap allocation) gets its own little memory with exactly the required size. So if you have a pointer to an allocation for a local variable `a`, there is no possible (no matter how unsafe) operation that you can do that would ever change said pointer -to a pointer to `b`. +to a pointer to a different local variable `b`. +Pointer arithmetic on `a` will only ever change its offset; the `AllocId` stays the same. + +This, however, causes a problem when we want to store a `Pointer` into an `Allocation`: we cannot turn it into a sequence of `u8` of the right length! +`AllocId` and offset together are twice as big as a pointer "seems" to be. +This is what the `relocation` field of `Allocation` is for: the byte offset of the `Pointer` gets stored as a bunch of `u8`, while its `AllocId` gets stored out-of-band. +The two are reassembled when the `Pointer` is read from memory. +The other bit of extra data an `Allocation` needs is `undef_mask` for keeping track of which of its bytes are initialized. + +### Global memory and exotic allocations + +`Memory` exists only during the Miri evaluation; it gets destroyed when the final value of the constant is computed. +In case that constant contains any pointers, those get "interned" and moved to a global "const eval memory" that is part of `TyCtxt`. +These allocations stay around for the remaining computation and get serialized into the final output (so that dependent crates can use them). + +Moreover, to also support function pointers, the global memory in `TyCtxt` can also contain "virtual allocations": instead of an `Allocation`, these contain an `Instance`. +That allows a `Pointer` to point to either normal data or a function, which is needed to be able to evaluate casts from function pointers to raw pointers. + +Finally, the [`GlobalAlloc`] type used in the global memory also contains a variant `Static` that points to a particular `const` or `static` item. +This is needed to support circular statics, where we need to have a `Pointer` to a `static` for which we cannot yet have an `Allocation` as we do not know the bytes of its value. + +[`Memory`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Memory.html +[`Allocation`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/struct.Allocation.html +[`Pointer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/struct.Pointer.html +[`GlobalAlloc`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.GlobalAlloc.html + +### Pointer values vs Pointer types + +One common cause of confusion in Miri is that being a pointer *value* and having a pointer *type* are entirely independent properties. +By "pointer value", we refer to a `Scalar::Ptr` containing a `Pointer` and thus pointing somewhere into Miri's virtual memory. +This is in contrast to `Scalar::Raw`, which is just some concrete integer. + +However, a variable of pointer or reference *type*, such as `*const T` or `&T`, does not have to have a pointer *value*: +it could be obtaining by casting or transmuting an integer to a pointer (currently that is hard to do in const eval, but eventually `transmute` will be stable as a `const fn`). +And similarly, when casting or transmuting a reference to some actual allocation to an integer, we end up with a pointer *value* (`Scalar::Ptr`) at integer *type* (`usize`). +This is a problem because we cannot meaningfully perform integer operations such as division on pointer values. ## Interpretation From f07e1f9adf5ba631c9d2d0f62ee24029b9c61fad Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Tue, 5 Nov 2019 16:57:35 +0100 Subject: [PATCH 0716/1812] apply linebreaks --- src/miri.md | 159 +++++++++++++++++++++++++++++++--------------------- 1 file changed, 96 insertions(+), 63 deletions(-) diff --git a/src/miri.md b/src/miri.md index 77ae8f93d..09c31e0a5 100644 --- a/src/miri.md +++ b/src/miri.md @@ -55,33 +55,40 @@ Before the evaluation, a virtual memory location (in this case essentially a `vec![u8; 4]` or `vec![u8; 8]`) is created for storing the evaluation result. At the start of the evaluation, `_0` and `_1` are -`Operand::Immediate(Immediate::Scalar(ScalarMaybeUndef::Undef))`. -This is quite a mouthful: [`Operand`] can represent either data stored somewhere in the [interpreter memory](#memory) (`Operand::Indirect`), or (as an optimization) immediate data stored in-line. -And [`Immediate`] can either be a single (potentially uninitialized) [scalar value][`Scalar`] (integer or thin pointer), or a pair of two of them. -In our case, the single scalar value is *not* (yet) initialized. - -When the initialization of `_1` is invoked, the -value of the `FOO` constant is required, and triggers another call to -`tcx.const_eval`, which will not be shown here. If the evaluation of FOO is -successful, `42` will be subtracted from its value `4096` and the result stored in -`_1` as `Operand::Immediate(Immediate::ScalarPair(Scalar::Raw { data: 4054, .. }, Scalar::Raw { data: 0, .. })`. The first -part of the pair is the computed value, the second part is a bool that's true if -an overflow happened. A `Scalar::Raw` also stores the size (in bytes) of this scalar value; we are eliding that here. +`Operand::Immediate(Immediate::Scalar(ScalarMaybeUndef::Undef))`. This is quite +a mouthful: [`Operand`] can represent either data stored somewhere in the +[interpreter memory](#memory) (`Operand::Indirect`), or (as an optimization) +immediate data stored in-line. And [`Immediate`] can either be a single +(potentially uninitialized) [scalar value][`Scalar`] (integer or thin pointer), +or a pair of two of them. In our case, the single scalar value is *not* (yet) +initialized. + +When the initialization of `_1` is invoked, the value of the `FOO` constant is +required, and triggers another call to `tcx.const_eval`, which will not be shown +here. If the evaluation of FOO is successful, `42` will be subtracted from its +value `4096` and the result stored in `_1` as +`Operand::Immediate(Immediate::ScalarPair(Scalar::Raw { data: 4054, .. }, +Scalar::Raw { data: 0, .. })`. The first part of the pair is the computed value, +the second part is a bool that's true if an overflow happened. A `Scalar::Raw` +also stores the size (in bytes) of this scalar value; we are eliding that here. The next statement asserts that said boolean is `0`. In case the assertion fails, its error message is used for reporting a compile-time error. -Since it does not fail, `Operand::Immediate(Immediate::Scalar(Scalar::Raw { data: 4054, .. }))` is stored in the -virtual memory was allocated before the evaluation. `_0` always refers to that -location directly. - -After the evaluation is done, the return value is converted from [`Operand`] to [`ConstValue`] by [`op_to_const`]: -the former representation is geared towards what is needed *during* cost evaluation, while [`ConstValue`] -is shaped by the needs of the remaining parts of the compiler that consume the results of const evaluation. -As part of this conversion, for types with scalar values, even if -the resulting [`Operand`] is `Indirect`, it will return an immediate `ConstValue::Scalar(computed_value)` (instead of the usual `ConstValue::ByRef`). -This makes using the result much more efficient and also more convenient, as no further queries need to be -executed in order to get at something as simple as a `usize`. +Since it does not fail, `Operand::Immediate(Immediate::Scalar(Scalar::Raw { +data: 4054, .. }))` is stored in the virtual memory was allocated before the +evaluation. `_0` always refers to that location directly. + +After the evaluation is done, the return value is converted from [`Operand`] to +[`ConstValue`] by [`op_to_const`]: the former representation is geared towards +what is needed *during* cost evaluation, while [`ConstValue`] is shaped by the +needs of the remaining parts of the compiler that consume the results of const +evaluation. As part of this conversion, for types with scalar values, even if +the resulting [`Operand`] is `Indirect`, it will return an immediate +`ConstValue::Scalar(computed_value)` (instead of the usual `ConstValue::ByRef`). +This makes using the result much more efficient and also more convenient, as no +further queries need to be executed in order to get at something as simple as a +`usize`. Future evaluations of the same constants will not actually invoke Miri, but just use the cached result. @@ -96,12 +103,13 @@ Miri, but just use the cached result. Miri's outside-facing datastructures can be found in [librustc/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc/mir/interpret). -This is mainly the error enum and the [`ConstValue`] and [`Scalar`] types. A `ConstValue` can -be either `Scalar` (a single `Scalar`, i.e., integer or thin pointer), -`Slice` (to represent byte slices and strings, as needed for pattern matching) or `ByRef`, which is used for anything else and -refers to a virtual allocation. These allocations can be accessed via the -methods on `tcx.interpret_interner`. -A `Scalar` is either some `Raw` integer or a pointer; see [the next section](#memory) for more on that. +This is mainly the error enum and the [`ConstValue`] and [`Scalar`] types. A +`ConstValue` can be either `Scalar` (a single `Scalar`, i.e., integer or thin +pointer), `Slice` (to represent byte slices and strings, as needed for pattern +matching) or `ByRef`, which is used for anything else and refers to a virtual +allocation. These allocations can be accessed via the methods on +`tcx.interpret_interner`. A `Scalar` is either some `Raw` integer or a pointer; +see [the next section](#memory) for more on that. If you are expecting a numeric result, you can use `eval_usize` (panics on anything that can't be representad as a `u64`) or `try_eval_usize` which results @@ -109,18 +117,25 @@ in an `Option` yielding the `Scalar` if possible. ## Memory -To support any kind of pointers, Miri needs to have a "virtual memory" that the pointers can point to. -This is implemented in the [`Memory`] type. -In the simplest model, every global variable, stack variable and every dynamic allocation corresponds to an [`Allocation`] in that memory. -(Actually using an allocation for every MIR stack variable would be very inefficient; that's why we have `Operand::Immediate` for stack variables that are both small and never have their address taken. -But that is purely an optimization.) - -Such an `Allocation` is basically just a sequence of `u8` storing the value of each byte in this allocation. -(Plus some extra data, see below.) -Every `Allocation` has a globally unique `AllocId` assigned in `Memory`. -With that, a [`Pointer`] consists of a pair of an `AllocId` (indicating the allocation) and an offset into the allocation (indicating which byte of the allocation the pointer points to). -It may seem odd that a `Pointer` is not just an integer address, but remember that during const evaluation, we cannot know at which actual integer address the allocation will end up -- so we use `AllocId` as symbolic base addresses, which means we need a separate offset. -(As an aside, it turns out that pointers at run-time are [more than just integers, too](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#pointer-provenance).) +To support any kind of pointers, Miri needs to have a "virtual memory" that the +pointers can point to. This is implemented in the [`Memory`] type. In the +simplest model, every global variable, stack variable and every dynamic +allocation corresponds to an [`Allocation`] in that memory. (Actually using an +allocation for every MIR stack variable would be very inefficient; that's why we +have `Operand::Immediate` for stack variables that are both small and never have +their address taken. But that is purely an optimization.) + +Such an `Allocation` is basically just a sequence of `u8` storing the value of +each byte in this allocation. (Plus some extra data, see below.) Every +`Allocation` has a globally unique `AllocId` assigned in `Memory`. With that, a +[`Pointer`] consists of a pair of an `AllocId` (indicating the allocation) and +an offset into the allocation (indicating which byte of the allocation the +pointer points to). It may seem odd that a `Pointer` is not just an integer +address, but remember that during const evaluation, we cannot know at which +actual integer address the allocation will end up -- so we use `AllocId` as +symbolic base addresses, which means we need a separate offset. (As an aside, +it turns out that pointers at run-time are +[more than just integers, too](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#pointer-provenance).) These allocations exist so that references and raw pointers have something to point to. There is no global linear heap in which things are allocated, but each @@ -131,23 +146,35 @@ matter how unsafe) operation that you can do that would ever change said pointer to a pointer to a different local variable `b`. Pointer arithmetic on `a` will only ever change its offset; the `AllocId` stays the same. -This, however, causes a problem when we want to store a `Pointer` into an `Allocation`: we cannot turn it into a sequence of `u8` of the right length! -`AllocId` and offset together are twice as big as a pointer "seems" to be. -This is what the `relocation` field of `Allocation` is for: the byte offset of the `Pointer` gets stored as a bunch of `u8`, while its `AllocId` gets stored out-of-band. -The two are reassembled when the `Pointer` is read from memory. -The other bit of extra data an `Allocation` needs is `undef_mask` for keeping track of which of its bytes are initialized. +This, however, causes a problem when we want to store a `Pointer` into an +`Allocation`: we cannot turn it into a sequence of `u8` of the right length! +`AllocId` and offset together are twice as big as a pointer "seems" to be. This +is what the `relocation` field of `Allocation` is for: the byte offset of the +`Pointer` gets stored as a bunch of `u8`, while its `AllocId` gets stored +out-of-band. The two are reassembled when the `Pointer` is read from memory. +The other bit of extra data an `Allocation` needs is `undef_mask` for keeping +track of which of its bytes are initialized. ### Global memory and exotic allocations -`Memory` exists only during the Miri evaluation; it gets destroyed when the final value of the constant is computed. -In case that constant contains any pointers, those get "interned" and moved to a global "const eval memory" that is part of `TyCtxt`. -These allocations stay around for the remaining computation and get serialized into the final output (so that dependent crates can use them). - -Moreover, to also support function pointers, the global memory in `TyCtxt` can also contain "virtual allocations": instead of an `Allocation`, these contain an `Instance`. -That allows a `Pointer` to point to either normal data or a function, which is needed to be able to evaluate casts from function pointers to raw pointers. - -Finally, the [`GlobalAlloc`] type used in the global memory also contains a variant `Static` that points to a particular `const` or `static` item. -This is needed to support circular statics, where we need to have a `Pointer` to a `static` for which we cannot yet have an `Allocation` as we do not know the bytes of its value. +`Memory` exists only during the Miri evaluation; it gets destroyed when the +final value of the constant is computed. In case that constant contains any +pointers, those get "interned" and moved to a global "const eval memory" that is +part of `TyCtxt`. These allocations stay around for the remaining computation +and get serialized into the final output (so that dependent crates can use +them). + +Moreover, to also support function pointers, the global memory in `TyCtxt` can +also contain "virtual allocations": instead of an `Allocation`, these contain an +`Instance`. That allows a `Pointer` to point to either normal data or a +function, which is needed to be able to evaluate casts from function pointers to +raw pointers. + +Finally, the [`GlobalAlloc`] type used in the global memory also contains a +variant `Static` that points to a particular `const` or `static` item. This is +needed to support circular statics, where we need to have a `Pointer` to a +`static` for which we cannot yet have an `Allocation` as we do not know the +bytes of its value. [`Memory`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Memory.html [`Allocation`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/struct.Allocation.html @@ -156,14 +183,20 @@ This is needed to support circular statics, where we need to have a `Pointer` to ### Pointer values vs Pointer types -One common cause of confusion in Miri is that being a pointer *value* and having a pointer *type* are entirely independent properties. -By "pointer value", we refer to a `Scalar::Ptr` containing a `Pointer` and thus pointing somewhere into Miri's virtual memory. -This is in contrast to `Scalar::Raw`, which is just some concrete integer. - -However, a variable of pointer or reference *type*, such as `*const T` or `&T`, does not have to have a pointer *value*: -it could be obtaining by casting or transmuting an integer to a pointer (currently that is hard to do in const eval, but eventually `transmute` will be stable as a `const fn`). -And similarly, when casting or transmuting a reference to some actual allocation to an integer, we end up with a pointer *value* (`Scalar::Ptr`) at integer *type* (`usize`). -This is a problem because we cannot meaningfully perform integer operations such as division on pointer values. +One common cause of confusion in Miri is that being a pointer *value* and having +a pointer *type* are entirely independent properties. By "pointer value", we +refer to a `Scalar::Ptr` containing a `Pointer` and thus pointing somewhere into +Miri's virtual memory. This is in contrast to `Scalar::Raw`, which is just some +concrete integer. + +However, a variable of pointer or reference *type*, such as `*const T` or `&T`, +does not have to have a pointer *value*: it could be obtaining by casting or +transmuting an integer to a pointer (currently that is hard to do in const eval, +but eventually `transmute` will be stable as a `const fn`). And similarly, when +casting or transmuting a reference to some actual allocation to an integer, we +end up with a pointer *value* (`Scalar::Ptr`) at integer *type* (`usize`). This +is a problem because we cannot meaningfully perform integer operations such as +division on pointer values. ## Interpretation From 46ce39e67ecd40e37c09000708aa8be9588294fe Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 10:42:53 -0600 Subject: [PATCH 0717/1812] add compiler lecture series appendix --- src/SUMMARY.md | 3 +- src/appendix/compiler-lecture.md | 51 ++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+), 1 deletion(-) create mode 100644 src/appendix/compiler-lecture.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 453493d9a..99f724614 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -103,7 +103,8 @@ [Appendix B: Background material](./appendix/background.md) [Appendix C: Glossary](./appendix/glossary.md) [Appendix D: Code Index](./appendix/code-index.md) -[Appendix E: Bibliography](./appendix/bibliography.md) +[Appendix E: Compiler Lecture Series](./appendix/compiler-lecture.md) +[Appendix F: Bibliography](./appendix/bibliography.md) [Appendix Z: HumorRust](./appendix/humorust.md) diff --git a/src/appendix/compiler-lecture.md b/src/appendix/compiler-lecture.md new file mode 100644 index 000000000..3912bab76 --- /dev/null +++ b/src/appendix/compiler-lecture.md @@ -0,0 +1,51 @@ +# Compiler Lecture Series + +These are videos where various experts explain different parts of the compiler: + +- Tom Tromey discusses debugging support in rustc + - Video: https://www.youtube.com/watch?v=elBxMRSNYr4 +- How Salsa Works (2019.01) + - Video: https://www.youtube.com/watch?v=_muY4HjSqVw +- Salsa In More Depth (2019.01) + - Video: https://www.youtube.com/watch?v=i_IhACacPRY +- RLS 2.0, Salsa, and Name Resolution + - Video: https://www.youtube.com/watch?v=Xr-rBqLr-G4 +- Cranelift + - Video: https://www.youtube.com/watch?v=9OIA7DTFQWU +- Rust analyzer guide + - Video: https://www.youtube.com/watch?v=ANKBNiSWyfc +- Rust analyzer syntax trees + - Video: https://www.youtube.com/watch?v=DGAuLWdCCAI +- rust-analyzer type-checker overview by flodiebold + - Video: https://www.youtube.com/watch?v=Lmp3P9WNL8o +- oli-obk on miri and constant evaluation + - Video: https://www.youtube.com/watch?v=5Pm2C1YXrvM +- Polonius-rustc walkthrough + - Video: https://www.youtube.com/watch?v=i5KdU0ieb_A +- rustc-chalk integration overview + - Video: https://www.youtube.com/watch?v=MBWtbDifPeU +- Coherence in Chalk by Sunjay Varma - Bay Area Rust Meetup + - assigned to @juanbono + - Video: https://www.youtube.com/watch?v=rZqS4bLPL24 +- How the chalk-engine crate works + - Video: https://www.youtube.com/watch?v=Ny2928cGDoM +- How the chalk-engine crate works 2 + - Video: https://www.youtube.com/watch?v=hmV66tB79LM +- RFC #2229 Disjoint Field Capture plan + - Video: https://www.youtube.com/watch?v=UTXOptVMuIc +- closures and upvar capture + - Video: https://www.youtube.com/watch?v=fMopdkn5-Xw +- blitzerr closure upvar tys + - Video: https://www.youtube.com/watch?v=pLmVhSB-z4s +- Convert Closure Upvar Representation to Tuples with blitzerr + - Video: https://www.youtube.com/watch?v=2QCuNtISoYc +- async-await implementation plans + - Video: https://www.youtube.com/watch?v=xe2_whJWBC0 +- async-await region inferencer + - Video: https://www.youtube.com/watch?v=hlOxfkUDLPQ +- Universes and Lifetimes + - Video: https://www.youtube.com/watch?v=iV1Z0xYXkck +- Representing types in rustc + - Video: https://www.youtube.com/watch?v=c01TsOsr3-c +- Polonius WG: Initialization and move tracking + - Video: https://www.youtube.com/watch?v=ilv9V-328HI From b73c24b5e1034cd020f78cf05c3ec552f63fa77d Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 13:35:47 -0600 Subject: [PATCH 0718/1812] fold subchapters --- book.toml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/book.toml b/book.toml index b5bced996..82a6b59b0 100644 --- a/book.toml +++ b/book.toml @@ -8,7 +8,9 @@ create-missing = false [output.html] -[output.html.search] +[output.html.fold] +enable = true +level = 1 [output.linkcheck] follow-web-links = true From 6d15cb5b8e6a6cb0ca304c5fe660ecdeceeede69 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 10:27:07 -0600 Subject: [PATCH 0719/1812] breakup the building chapter --- src/SUMMARY.md | 9 +- src/building/bootstrapping.md | 161 ++++++ .../build-install-distribution-artifacts.md | 0 src/{ => building}/compiler-documenting.md | 0 src/building/ctags.md | 26 + src/building/how-to-build-and-run.md | 277 +++++++++ src/building/suggested.md | 78 +++ src/how-to-build-and-run.md | 533 ------------------ 8 files changed, 548 insertions(+), 536 deletions(-) create mode 100644 src/building/bootstrapping.md rename src/{ => building}/build-install-distribution-artifacts.md (100%) rename src/{ => building}/compiler-documenting.md (100%) create mode 100644 src/building/ctags.md create mode 100644 src/building/how-to-build-and-run.md create mode 100644 src/building/suggested.md delete mode 100644 src/how-to-build-and-run.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 99f724614..b264f8df4 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -6,9 +6,12 @@ - [Part 1: Building, debugging, and contributing to Rustc](./part-1-intro.md) - [About the compiler team](./compiler-team.md) - - [How to Build and Run the Compiler](./how-to-build-and-run.md) - - [Build and Install distribution artifacts](./build-install-distribution-artifacts.md) - - [Documenting Compiler](./compiler-documenting.md) + - [How to Build and Run the Compiler](./building/how-to-build-and-run.md) + - [Suggested Workflows](./building/suggested.md) + - [Bootstrapping](./building/bootstrapping.md) + - [Distribution artifacts](./building/build-install-distribution-artifacts.md) + - [Documenting Compiler](./building/compiler-documenting.md) + - [ctags](./building/ctags.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) - [Adding new tests](./tests/adding.md) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md new file mode 100644 index 000000000..fd54c80cf --- /dev/null +++ b/src/building/bootstrapping.md @@ -0,0 +1,161 @@ +# Bootstrapping the Compiler + +This subchapter is about the bootstrapping process. + +When running `x.py` you will see output such as: + +```txt +Building stage0 std artifacts +Copying stage0 std from stage0 +Building stage0 compiler artifacts +Copying stage0 rustc from stage0 +Building LLVM for x86_64-apple-darwin +Building stage0 codegen artifacts +Assembling stage1 compiler +Building stage1 std artifacts +Copying stage1 std from stage1 +Building stage1 compiler artifacts +Copying stage1 rustc from stage1 +Building stage1 codegen artifacts +Assembling stage2 compiler +Uplifting stage1 std +Copying stage2 std from stage1 +Generating unstable book md files +Building stage0 tool unstable-book-gen +Building stage0 tool rustbook +Documenting standalone +Building rustdoc for stage2 +Documenting book redirect pages +Documenting stage2 std +Building rustdoc for stage1 +Documenting stage2 whitelisted compiler +Documenting stage2 compiler +Documenting stage2 rustdoc +Documenting error index +Uplifting stage1 rustc +Copying stage2 rustc from stage1 +Building stage2 tool error_index_generator +``` + +A deeper look into `x.py`'s phases can be seen here: + +A diagram of the rustc compilation phases + +Keep in mind this diagram is a simplification, i.e. `rustdoc` can be built at +different stages, the process is a bit different when passing flags such as +`--keep-stage`, or if there are non-host targets. + +The following tables indicate the outputs of various stage actions: + +| Stage 0 Action | Output | +|-----------------------------------------------------------|----------------------------------------------| +| `beta` extracted | `build/HOST/stage0` | +| `stage0` builds `bootstrap` | `build/bootstrap` | +| `stage0` builds `libstd` | `build/HOST/stage0-std/TARGET` | +| copy `stage0-std` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | +| `stage0` builds `rustc` with `stage0-sysroot` | `build/HOST/stage0-rustc/HOST` | +| copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | +| build `llvm` | `build/HOST/llvm` | +| `stage0` builds `codegen` with `stage0-sysroot` | `build/HOST/stage0-codegen/HOST` | +| `stage0` builds `rustdoc` with `stage0-sysroot` | `build/HOST/stage0-tools/HOST` | + +`--stage=0` stops here. + +| Stage 1 Action | Output | +|-----------------------------------------------------|---------------------------------------| +| copy (uplift) `stage0-rustc` executable to `stage1` | `build/HOST/stage1/bin` | +| copy (uplift) `stage0-codegen` to `stage1` | `build/HOST/stage1/lib` | +| copy (uplift) `stage0-sysroot` to `stage1` | `build/HOST/stage1/lib` | +| `stage1` builds `libstd` | `build/HOST/stage1-std/TARGET` | +| copy `stage1-std` (HOST only) | `build/HOST/stage1/lib/rustlib/HOST` | +| `stage1` builds `rustc` | `build/HOST/stage1-rustc/HOST` | +| copy `stage1-rustc` (except executable) | `build/HOST/stage1/lib/rustlib/HOST` | +| `stage1` builds `codegen` | `build/HOST/stage1-codegen/HOST` | + +`--stage=1` stops here. + +| Stage 2 Action | Output | +|-------------------------------------------|-----------------------------------------------------------------| +| copy (uplift) `stage1-rustc` executable | `build/HOST/stage2/bin` | +| copy (uplift) `stage1-sysroot` | `build/HOST/stage2/lib and build/HOST/stage2/lib/rustlib/HOST` | +| `stage2` builds `libstd` (except HOST?) | `build/HOST/stage2-std/TARGET` | +| copy `stage2-std` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | +| `stage2` builds `rustdoc` | `build/HOST/stage2-tools/HOST` | +| copy `rustdoc` | `build/HOST/stage2/bin` | + +`--stage=2` stops here. + +Note that the convention `x.py` uses is that: +- A "stage N artifact" is an artifact that is _produced_ by the stage N compiler. +- The "stage (N+1) compiler" is assembled from "stage N artifacts". +- A `--stage N` flag means build _with_ stage N. + +In short, _stage 0 uses the stage0 compiler to create stage0 artifacts which +will later be uplifted to stage1_. + +Every time any of the main artifacts (`std` and `rustc`) are compiled, two +steps are performed. +When `std` is compiled by a stage N compiler, that `std` will be linked to +programs built by the stage N compiler (including `rustc` built later +on). It will also be used by the stage (N+1) compiler to link against itself. +This is somewhat intuitive if one thinks of the stage (N+1) compiler as "just" +another program we are building with the stage N compiler. In some ways, `rustc` +(the binary, not the `rustbuild` step) could be thought of as one of the few +`no_core` binaries out there. + +So "stage0 std artifacts" are in fact the output of the downloaded stage0 +compiler, and are going to be used for anything built by the stage0 compiler: +e.g. `rustc` artifacts. When it announces that it is "building stage1 +std artifacts" it has moved on to the next bootstrapping phase. This pattern +continues in latter stages. + +Also note that building host `std` and target `std` are different based on the +stage (e.g. see in the table how stage2 only builds non-host `std` targets. +This is because during stage2, the host `std` is uplifted from the "stage 1" +`std` -- specifically, when "Building stage 1 artifacts" is announced, it is +later copied into stage2 as well (both the compiler's `libdir` and the +`sysroot`). + +This `std` is pretty much necessary for any useful work with the compiler. +Specifically, it's used as the `std` for programs compiled by the newly compiled +compiler (so when you compile `fn main() { }` it is linked to the last `std` +compiled with `x.py build --stage 1 src/libstd`). + +The `rustc` generated by the stage0 compiler is linked to the freshly-built +`libstd`, which means that for the most part only `std` needs to be cfg-gated, +so that `rustc` can use featured added to std immediately after their addition, +without need for them to get into the downloaded beta. The `libstd` built by the +`stage1/bin/rustc` compiler, also known as "stage1 std artifacts", is not +necessarily ABI-compatible with that compiler. +That is, the `rustc` binary most likely could not use this `std` itself. +It is however ABI-compatible with any programs that the `stage1/bin/rustc` +binary builds (including itself), so in that sense they're paired. + +This is also where `--keep-stage 1 src/libstd` comes into play. Since most +changes to the compiler don't actually change the ABI, once you've produced a +`libstd` in stage 1, you can probably just reuse it with a different compiler. +If the ABI hasn't changed, you're good to go, no need to spend the time +recompiling that `std`. +`--keep-stage` simply assumes the previous compile is fine and copies those +artifacts into the appropriate place, skipping the cargo invocation. + +The reason we first build `std`, then `rustc`, is largely just +because we want to minimize `cfg(stage0)` in the code for `rustc`. +Currently `rustc` is always linked against a "new" `std` so it doesn't +ever need to be concerned with differences in std; it can assume that the std is +as fresh as possible. + +The reason we need to build it twice is because of ABI compatibility. +The beta compiler has it's own ABI, and then the `stage1/bin/rustc` compiler +will produce programs/libraries with the new ABI. +We used to build three times, but because we assume that the ABI is constant +within a codebase, we presume that the libraries produced by the "stage2" +compiler (produced by the `stage1/bin/rustc` compiler) is ABI-compatible with +the `stage1/bin/rustc` compiler's produced libraries. +What this means is that we can skip that final compilation -- and simply use the +same libraries as the `stage2/bin/rustc` compiler uses itself for programs it +links against. + +This `stage2/bin/rustc` compiler is shipped to end-users, along with the +`stage 1 {std,rustc}` artifacts. + diff --git a/src/build-install-distribution-artifacts.md b/src/building/build-install-distribution-artifacts.md similarity index 100% rename from src/build-install-distribution-artifacts.md rename to src/building/build-install-distribution-artifacts.md diff --git a/src/compiler-documenting.md b/src/building/compiler-documenting.md similarity index 100% rename from src/compiler-documenting.md rename to src/building/compiler-documenting.md diff --git a/src/building/ctags.md b/src/building/ctags.md new file mode 100644 index 000000000..9b6331457 --- /dev/null +++ b/src/building/ctags.md @@ -0,0 +1,26 @@ +# ctags + +One of the challenges with rustc is that the RLS can't handle it, since it's a +bootstrapping compiler. This makes code navigation difficult. One solution is to +use `ctags`. + +`ctags` has a long history and several variants. Exuberant Ctags seems to be +quite commonly distributed but it does not have out-of-box Rust support. Some +distributions seem to use [Universal Ctags][utags], which is a maintained fork +and does have built-in Rust support. + +The following script can be used to set up Exuberant Ctags: +[https://github.com/nikomatsakis/rust-etags][etags]. + +`ctags` integrates into emacs and vim quite easily. The following can then be +used to build and generate tags: + +```console +$ rust-ctags src/lib* && ./x.py build +``` + +This allows you to do "jump-to-def" with whatever functions were around when +you last built, which is ridiculously useful. + +[etags]: https://github.com/nikomatsakis/rust-etags +[utags]: https://github.com/universal-ctags/ctags diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md new file mode 100644 index 000000000..514250769 --- /dev/null +++ b/src/building/how-to-build-and-run.md @@ -0,0 +1,277 @@ +# How to Build and Run the Compiler + +The compiler is built using a tool called `x.py`. You will need to +have Python installed to run it. But before we get to that, if you're going to +be hacking on `rustc`, you'll want to tweak the configuration of the compiler. +The default configuration is oriented towards running the compiler as a user, +not a developer. + +## Create a config.toml + +To start, copy [`config.toml.example`] to `config.toml`: + +[`config.toml.example`]: https://github.com/rust-lang/rust/blob/master/config.toml.example + +```bash +> cd $RUST_CHECKOUT +> cp config.toml.example config.toml +``` + +Then you will want to open up the file and change the following +settings (and possibly others, such as `llvm.ccache`): + +```toml +[llvm] +# Enables LLVM assertions, which will check that the LLVM bitcode generated +# by the compiler is internally consistent. These are particularly helpful +# if you edit `codegen`. +assertions = true + +[rust] +# This will make your build more parallel; it costs a bit of runtime +# performance perhaps (less inlining) but it's worth it. +codegen-units = 0 + +# This enables full debuginfo and debug assertions. The line debuginfo is also +# enabled by `debuginfo-level = 1`. Full debuginfo is also enabled by +# `debuginfo-level = 2`. Debug assertions can also be enabled with +# `debug-assertions = true`. Note that `debug = true` will make your build +# slower, so you may want to try individually enabling debuginfo and assertions +# or enable only line debuginfo which is basically free. +debug = true +``` + +If you have already built `rustc`, then you may have to execute `rm -rf build` for subsequent +configuration changes to take effect. Note that `./x.py clean` will not cause a +rebuild of LLVM, so if your configuration change affects LLVM, you will need to +manually `rm -rf build/` before rebuilding. + +## What is `x.py`? + +`x.py` is the script used to orchestrate the tooling in the `rustc` repository. +It is the script that can build docs, run tests, and compile `rustc`. +It is the now preferred way to build `rustc` and it replaces the old makefiles +from before. Below are the different ways to utilize `x.py` in order to +effectively deal with the repo for various common tasks. + +This chapter focuses on the basics to be productive, but +if you want to learn more about `x.py`, read its README.md +[here](https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md). + +## Bootstrapping + +One thing to keep in mind is that `rustc` is a _bootstrapping_ +compiler. That is, since `rustc` is written in Rust, we need to use an +older version of the compiler to compile the newer version. In +particular, the newer version of the compiler and some of the artifacts needed +to build it, such as `libstd` and other tooling, may use some unstable features +internally, requiring a specific version which understands these unstable +features. + +The result is that compiling `rustc` is done in stages: + +- **Stage 0:** the stage0 compiler is usually (you can configure `x.py` to use + something else) the current _beta_ `rustc` compiler and its associated dynamic + libraries (which `x.py` will download for you). This stage0 compiler is then + used only to compile `rustbuild`, `std`, and `rustc`. When compiling + `rustc`, this stage0 compiler uses the freshly compiled `std`. + There are two concepts at play here: a compiler (with its set of dependencies) + and its 'target' or 'object' libraries (`std` and `rustc`). + Both are staged, but in a staggered manner. +- **Stage 1:** the code in your clone (for new version) is then + compiled with the stage0 compiler to produce the stage1 compiler. + However, it was built with an older compiler (stage0), so to + optimize the stage1 compiler we go to next the stage. + - In theory, the stage1 compiler is functionally identical to the + stage2 compiler, but in practice there are subtle differences. In + particular, the stage1 compiler itself was built by stage0 and + hence not by the source in your working directory: this means that + the symbol names used in the compiler source may not match the + symbol names that would have been made by the stage1 compiler. + This can be important when using dynamic linking (e.g., with + derives. Sometimes this means that some tests don't work when run + with stage1. +- **Stage 2:** we rebuild our stage1 compiler with itself to produce + the stage2 compiler (i.e. it builds itself) to have all the _latest + optimizations_. (By default, we copy the stage1 libraries for use by + the stage2 compiler, since they ought to be identical.) +- _(Optional)_ **Stage 3**: to sanity check our new compiler, we + can build the libraries with the stage2 compiler. The result ought + to be identical to before, unless something has broken. + +To read more about the bootstrap process, [read this chapter][bootstrap]. + +[bootstrap]: ./bootstrapping.md + +## Building the Compiler + +To build a compiler, run `./x.py build`. This will do the whole bootstrapping +process described above, producing a usable compiler toolchain from the source +code you have checked out. This takes a long time, so it is not usually what +you want to actually run (more on this later). + +There are many flags you can pass to the build command of `x.py` that can be +beneficial to cutting down compile times or fitting other things you might +need to change. They are: + +```txt +Options: + -v, --verbose use verbose output (-vv for very verbose) + -i, --incremental use incremental compilation + --config FILE TOML configuration file for build + --build BUILD build target of the stage0 compiler + --host HOST host targets to build + --target TARGET target targets to build + --on-fail CMD command to run on failure + --stage N stage to build + --keep-stage N stage to keep without recompiling + --src DIR path to the root of the rust checkout + -j, --jobs JOBS number of jobs to run in parallel + -h, --help print this help message +``` + +For hacking, often building the stage 1 compiler is enough, but for +final testing and release, the stage 2 compiler is used. + +`./x.py check` is really fast to build the rust compiler. +It is, in particular, very useful when you're doing some kind of +"type-based refactoring", like renaming a method, or changing the +signature of some function. + + + +Once you've created a config.toml, you are now ready to run +`x.py`. There are a lot of options here, but let's start with what is +probably the best "go to" command for building a local rust: + +```bash +> ./x.py build -i --stage 1 src/libstd +``` + +This may *look* like it only builds libstd, but that is not the case. +What this command does is the following: + +- Build `libstd` using the stage0 compiler (using incremental) +- Build `librustc` using the stage0 compiler (using incremental) + - This produces the stage1 compiler +- Build libstd using the stage1 compiler (cannot use incremental) + +This final product (stage1 compiler + libs built using that compiler) +is what you need to build other rust programs (unless you use `#![no_std]` or +`#![no_core]`). + +The command includes the `-i` switch which enables incremental compilation. +This will be used to speed up the first two steps of the process: +in particular, if you make a small change, we ought to be able to use your old +results to make producing the stage1 **compiler** faster. + +Unfortunately, incremental cannot be used to speed up making the +stage1 libraries. This is because incremental only works when you run +the *same compiler* twice in a row. In this case, we are building a +*new stage1 compiler* every time. Therefore, the old incremental +results may not apply. **As a result, you will probably find that +building the stage1 `libstd` is a bottleneck for you** -- but fear not, +there is a (hacky) workaround. See [the section on "recommended +workflows"](./suggested.md) below. + +Note that this whole command just gives you a subset of the full `rustc` +build. The **full** `rustc` build (what you get if you just say `./x.py +build`) has quite a few more steps: + +- Build `librustc` and `rustc` with the stage1 compiler. + - The resulting compiler here is called the "stage2" compiler. +- Build libstd with stage2 compiler. +- Build librustdoc and a bunch of other things with the stage2 compiler. + + + +## Build specific components + +Build only the libcore library + +```bash +> ./x.py build src/libcore +``` + +Build the libcore and libproc_macro library only + +```bash +> ./x.py build src/libcore src/libproc_macro +``` + +Build only libcore up to Stage 1 + +```bash +> ./x.py build src/libcore --stage 1 +``` + +Sometimes you might just want to test if the part you’re working on can +compile. Using these commands you can test that it compiles before doing +a bigger build to make sure it works with the compiler. As shown before +you can also pass flags at the end such as --stage. + +## Creating a rustup toolchain + +Once you have successfully built `rustc`, you will have created a bunch +of files in your `build` directory. In order to actually run the +resulting `rustc`, we recommend creating rustup toolchains. The first +one will run the stage1 compiler (which we built above). The second +will execute the stage2 compiler (which we did not build, but which +you will likely need to build at some point; for example, if you want +to run the entire test suite). + +```bash +> rustup toolchain link stage1 build//stage1 +> rustup toolchain link stage2 build//stage2 +``` + +The `` would typically be one of the following: + +- Linux: `x86_64-unknown-linux-gnu` +- Mac: `x86_64-apple-darwin` +- Windows: `x86_64-pc-windows-msvc` + +Now you can run the `rustc` you built with. If you run with `-vV`, you +should see a version number ending in `-dev`, indicating a build from +your local environment: + +```bash +> rustc +stage1 -vV +rustc 1.25.0-dev +binary: rustc +commit-hash: unknown +commit-date: unknown +host: x86_64-unknown-linux-gnu +release: 1.25.0-dev +LLVM version: 4.0 +``` +## Other `x.py` commands + +Here are a few other useful `x.py` commands. We'll cover some of them in detail +in other sections: + +- Building things: + - `./x.py clean` – clean up the build directory (`rm -rf build` works too, + but then you have to rebuild LLVM) + - `./x.py build --stage 1` – builds everything using the stage 1 compiler, + not just up to libstd + - `./x.py build` – builds the stage2 compiler +- Running tests (see the [section on running tests](./tests/running.html) for + more details): + - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd + - `./x.py test --stage 1 src/test/ui` – runs the `ui` test suite + - `./x.py test --stage 1 src/test/ui/const-generics` - runs all the tests in + the `const-generics/` subdirectory of the `ui` test suite + - `./x.py test --stage 1 src/test/ui/const-generics/const-types.rs` - runs + the single test `const-types.rs` from the `ui` test suite + +### Cleaning out build directories + +Sometimes you need to start fresh, but this is normally not the case. +If you need to run this then rustbuild is most likely not acting right and +you should file a bug as to what is going wrong. If you do need to clean +everything up then you only need to run one command! + + ```bash + > ./x.py clean + ``` diff --git a/src/building/suggested.md b/src/building/suggested.md new file mode 100644 index 000000000..427a44858 --- /dev/null +++ b/src/building/suggested.md @@ -0,0 +1,78 @@ +# Suggested Workflows + +The full bootstrapping process takes quite a while. Here are three suggestions +to make you're life easier. + +## Check, check, and check again + +The first workflow, which is useful +when doing simple refactorings, is to run `./x.py check` +continuously. Here you are just checking that the compiler can +**build**, but often that is all you need (e.g., when renaming a +method). You can then run `./x.py build` when you actually need to +run tests. + +In fact, it is sometimes useful to put off tests even when you are not +100% sure the code will work. You can then keep building up +refactoring commits and only run the tests at some later time. You can +then use `git bisect` to track down **precisely** which commit caused +the problem. A nice side-effect of this style is that you are left +with a fairly fine-grained set of commits at the end, all of which +build and pass tests. This often helps reviewing. + +## Incremental builds with `--keep-stage`. + +Sometimes just checking +whether the compiler builds is not enough. A common example is that +you need to add a `debug!` statement to inspect the value of some +state or better understand the problem. In that case, you really need +a full build. By leveraging incremental, though, you can often get +these builds to complete very fast (e.g., around 30 seconds). The only +catch is this requires a bit of fudging and may produce compilers that +don't work (but that is easily detected and fixed). + +The sequence of commands you want is as follows: + +- Initial build: `./x.py build -i --stage 1 src/libstd` + - As [documented above](#command), this will build a functional + stage1 compiler as part of running all stage0 commands (which include + building a `libstd` compatible with the stage1 compiler) as well as the + first few steps of the "stage 1 actions" up to "stage1 (sysroot stage1) + builds libstd". +- Subsequent builds: `./x.py build -i --stage 1 src/libstd --keep-stage 1` + - Note that we added the `--keep-stage 1` flag here + +As mentioned, the effect of `--keep-stage 1` is that we just *assume* that the +old standard library can be re-used. If you are editing the compiler, this +is almost always true: you haven't changed the standard library, after +all. But sometimes, it's not true: for example, if you are editing +the "metadata" part of the compiler, which controls how the compiler +encodes types and other states into the `rlib` files, or if you are +editing things that wind up in the metadata (such as the definition of +the MIR). + +**The TL;DR is that you might get weird behavior from a compile when +using `--keep-stage 1`** -- for example, strange +[ICEs](appendix/glossary.html) or other panics. In that case, you +should simply remove the `--keep-stage 1` from the command and +rebuild. That ought to fix the problem. + +You can also use `--keep-stage 1` when running tests. Something like this: + +- Initial test run: `./x.py test -i --stage 1 src/test/ui` +- Subsequent test run: `./x.py test -i --stage 1 src/test/ui --keep-stage 1` + +## Building with system LLVM + +By default, LLVM is built from source, and that can take significant amount of +time. An alternative is to use LLVM already installed on your computer. + +This is specified in the `target` section of `config.toml`: + +```toml +[target.x86_64-unknown-linux-gnu] +llvm-config = "/path/to/llvm/llvm-7.0.1/bin/llvm-config" +``` + +On my system, this path is `/usr/bin/llvm-config-7`, but this probably varies +by installation. diff --git a/src/how-to-build-and-run.md b/src/how-to-build-and-run.md deleted file mode 100644 index aac0f211c..000000000 --- a/src/how-to-build-and-run.md +++ /dev/null @@ -1,533 +0,0 @@ -# How to Build and Run the Compiler - -The compiler is built using a tool called `x.py`. You will need to -have Python installed to run it. But before we get to that, if you're going to -be hacking on `rustc`, you'll want to tweak the configuration of the compiler. -The default configuration is oriented towards running the compiler as a user, -not a developer. - -### Create a config.toml - -To start, copy [`config.toml.example`] to `config.toml`: - -[`config.toml.example`]: https://github.com/rust-lang/rust/blob/master/config.toml.example - -```bash -> cd $RUST_CHECKOUT -> cp config.toml.example config.toml -``` - -Then you will want to open up the file and change the following -settings (and possibly others, such as `llvm.ccache`): - -```toml -[llvm] -# Enables LLVM assertions, which will check that the LLVM bitcode generated -# by the compiler is internally consistent. These are particularly helpful -# if you edit `codegen`. -assertions = true - -[rust] -# This will make your build more parallel; it costs a bit of runtime -# performance perhaps (less inlining) but it's worth it. -codegen-units = 0 - -# This enables full debuginfo and debug assertions. The line debuginfo is also -# enabled by `debuginfo-level = 1`. Full debuginfo is also enabled by -# `debuginfo-level = 2`. Debug assertions can also be enabled with -# `debug-assertions = true`. Note that `debug = true` will make your build -# slower, so you may want to try individually enabling debuginfo and assertions -# or enable only line debuginfo which is basically free. -debug = true -``` - -If you have already built `rustc`, then you may have to execute `rm -rf build` for subsequent -configuration changes to take effect. Note that `./x.py clean` will not cause a -rebuild of LLVM, so if your configuration change affects LLVM, you will need to -manually `rm -rf build/` before rebuilding. - -### What is `x.py`? - -`x.py` is the script used to orchestrate the tooling in the `rustc` repository. -It is the script that can build docs, run tests, and compile `rustc`. -It is the now preferred way to build `rustc` and it replaces the old makefiles -from before. Below are the different ways to utilize `x.py` in order to -effectively deal with the repo for various common tasks. - -### Running `x.py` and building a stage1 compiler - -One thing to keep in mind is that `rustc` is a _bootstrapping_ -compiler. That is, since `rustc` is written in Rust, we need to use an -older version of the compiler to compile the newer version. In -particular, the newer version of the compiler and some of the artifacts needed -to build it, such as `libstd` and other tooling, may use some unstable features -internally, requiring a specific version which understands these unstable -features. - -The result is that compiling `rustc` is done in stages: - -- **Stage 0:** the stage0 compiler is usually (you can configure `x.py` to use - something else) the current _beta_ `rustc` compiler and its associated dynamic - libraries (which `x.py` will download for you). This stage0 compiler is then - used only to compile `rustbuild`, `std`, and `rustc`. When compiling - `rustc`, this stage0 compiler uses the freshly compiled `std`. - There are two concepts at play here: a compiler (with its set of dependencies) - and its 'target' or 'object' libraries (`std` and `rustc`). - Both are staged, but in a staggered manner. -- **Stage 1:** the code in your clone (for new version) is then - compiled with the stage0 compiler to produce the stage1 compiler. - However, it was built with an older compiler (stage0), so to - optimize the stage1 compiler we go to next the stage. - - In theory, the stage1 compiler is functionally identical to the - stage2 compiler, but in practice there are subtle differences. In - particular, the stage1 compiler itself was built by stage0 and - hence not by the source in your working directory: this means that - the symbol names used in the compiler source may not match the - symbol names that would have been made by the stage1 compiler. - This can be important when using dynamic linking (e.g., with - derives. Sometimes this means that some tests don't work when run - with stage1. -- **Stage 2:** we rebuild our stage1 compiler with itself to produce - the stage2 compiler (i.e. it builds itself) to have all the _latest - optimizations_. (By default, we copy the stage1 libraries for use by - the stage2 compiler, since they ought to be identical.) -- _(Optional)_ **Stage 3**: to sanity check our new compiler, we - can build the libraries with the stage2 compiler. The result ought - to be identical to before, unless something has broken. - -#### A note on stage meanings - -When running `x.py` you will see output such as: - -```txt -Building stage0 std artifacts -Copying stage0 std from stage0 -Building stage0 compiler artifacts -Copying stage0 rustc from stage0 -Building LLVM for x86_64-apple-darwin -Building stage0 codegen artifacts -Assembling stage1 compiler -Building stage1 std artifacts -Copying stage1 std from stage1 -Building stage1 compiler artifacts -Copying stage1 rustc from stage1 -Building stage1 codegen artifacts -Assembling stage2 compiler -Uplifting stage1 std -Copying stage2 std from stage1 -Generating unstable book md files -Building stage0 tool unstable-book-gen -Building stage0 tool rustbook -Documenting standalone -Building rustdoc for stage2 -Documenting book redirect pages -Documenting stage2 std -Building rustdoc for stage1 -Documenting stage2 whitelisted compiler -Documenting stage2 compiler -Documenting stage2 rustdoc -Documenting error index -Uplifting stage1 rustc -Copying stage2 rustc from stage1 -Building stage2 tool error_index_generator -``` - -A deeper look into `x.py`'s phases can be seen here: - -A diagram of the rustc compilation phases - -Keep in mind this diagram is a simplification, i.e. `rustdoc` can be built at -different stages, the process is a bit different when passing flags such as -`--keep-stage`, or if there are non-host targets. - -The following tables indicate the outputs of various stage actions: - -| Stage 0 Action | Output | -|-----------------------------------------------------------|----------------------------------------------| -| `beta` extracted | `build/HOST/stage0` | -| `stage0` builds `bootstrap` | `build/bootstrap` | -| `stage0` builds `libstd` | `build/HOST/stage0-std/TARGET` | -| copy `stage0-std` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | -| `stage0` builds `rustc` with `stage0-sysroot` | `build/HOST/stage0-rustc/HOST` | -| copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | -| build `llvm` | `build/HOST/llvm` | -| `stage0` builds `codegen` with `stage0-sysroot` | `build/HOST/stage0-codegen/HOST` | -| `stage0` builds `rustdoc` with `stage0-sysroot` | `build/HOST/stage0-tools/HOST` | - -`--stage=0` stops here. - -| Stage 1 Action | Output | -|-----------------------------------------------------|---------------------------------------| -| copy (uplift) `stage0-rustc` executable to `stage1` | `build/HOST/stage1/bin` | -| copy (uplift) `stage0-codegen` to `stage1` | `build/HOST/stage1/lib` | -| copy (uplift) `stage0-sysroot` to `stage1` | `build/HOST/stage1/lib` | -| `stage1` builds `libstd` | `build/HOST/stage1-std/TARGET` | -| copy `stage1-std` (HOST only) | `build/HOST/stage1/lib/rustlib/HOST` | -| `stage1` builds `rustc` | `build/HOST/stage1-rustc/HOST` | -| copy `stage1-rustc` (except executable) | `build/HOST/stage1/lib/rustlib/HOST` | -| `stage1` builds `codegen` | `build/HOST/stage1-codegen/HOST` | - -`--stage=1` stops here. - -| Stage 2 Action | Output | -|-------------------------------------------|-----------------------------------------------------------------| -| copy (uplift) `stage1-rustc` executable | `build/HOST/stage2/bin` | -| copy (uplift) `stage1-sysroot` | `build/HOST/stage2/lib and build/HOST/stage2/lib/rustlib/HOST` | -| `stage2` builds `libstd` (except HOST?) | `build/HOST/stage2-std/TARGET` | -| copy `stage2-std` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | -| `stage2` builds `rustdoc` | `build/HOST/stage2-tools/HOST` | -| copy `rustdoc` | `build/HOST/stage2/bin` | - -`--stage=2` stops here. - -Note that the convention `x.py` uses is that: -- A "stage N artifact" is an artifact that is _produced_ by the stage N compiler. -- The "stage (N+1) compiler" is assembled from "stage N artifacts". -- A `--stage N` flag means build _with_ stage N. - -In short, _stage 0 uses the stage0 compiler to create stage0 artifacts which -will later be uplifted to stage1_. - -Every time any of the main artifacts (`std` and `rustc`) are compiled, two -steps are performed. -When `std` is compiled by a stage N compiler, that `std` will be linked to -programs built by the stage N compiler (including `rustc` built later -on). It will also be used by the stage (N+1) compiler to link against itself. -This is somewhat intuitive if one thinks of the stage (N+1) compiler as "just" -another program we are building with the stage N compiler. In some ways, `rustc` -(the binary, not the `rustbuild` step) could be thought of as one of the few -`no_core` binaries out there. - -So "stage0 std artifacts" are in fact the output of the downloaded stage0 -compiler, and are going to be used for anything built by the stage0 compiler: -e.g. `rustc` artifacts. When it announces that it is "building stage1 -std artifacts" it has moved on to the next bootstrapping phase. This pattern -continues in latter stages. - -Also note that building host `std` and target `std` are different based on the -stage (e.g. see in the table how stage2 only builds non-host `std` targets. -This is because during stage2, the host `std` is uplifted from the "stage 1" -`std` -- specifically, when "Building stage 1 artifacts" is announced, it is -later copied into stage2 as well (both the compiler's `libdir` and the -`sysroot`). - -This `std` is pretty much necessary for any useful work with the compiler. -Specifically, it's used as the `std` for programs compiled by the newly compiled -compiler (so when you compile `fn main() { }` it is linked to the last `std` -compiled with `x.py build --stage 1 src/libstd`). - -The `rustc` generated by the stage0 compiler is linked to the freshly-built -`libstd`, which means that for the most part only `std` needs to be cfg-gated, -so that `rustc` can use featured added to std immediately after their addition, -without need for them to get into the downloaded beta. The `libstd` built by the -`stage1/bin/rustc` compiler, also known as "stage1 std artifacts", is not -necessarily ABI-compatible with that compiler. -That is, the `rustc` binary most likely could not use this `std` itself. -It is however ABI-compatible with any programs that the `stage1/bin/rustc` -binary builds (including itself), so in that sense they're paired. - -This is also where `--keep-stage 1 src/libstd` comes into play. Since most -changes to the compiler don't actually change the ABI, once you've produced a -`libstd` in stage 1, you can probably just reuse it with a different compiler. -If the ABI hasn't changed, you're good to go, no need to spend the time -recompiling that `std`. -`--keep-stage` simply assumes the previous compile is fine and copies those -artifacts into the appropriate place, skipping the cargo invocation. - -The reason we first build `std`, then `rustc`, is largely just -because we want to minimize `cfg(stage0)` in the code for `rustc`. -Currently `rustc` is always linked against a "new" `std` so it doesn't -ever need to be concerned with differences in std; it can assume that the std is -as fresh as possible. - -The reason we need to build it twice is because of ABI compatibility. -The beta compiler has it's own ABI, and then the `stage1/bin/rustc` compiler -will produce programs/libraries with the new ABI. -We used to build three times, but because we assume that the ABI is constant -within a codebase, we presume that the libraries produced by the "stage2" -compiler (produced by the `stage1/bin/rustc` compiler) is ABI-compatible with -the `stage1/bin/rustc` compiler's produced libraries. -What this means is that we can skip that final compilation -- and simply use the -same libraries as the `stage2/bin/rustc` compiler uses itself for programs it -links against. - -This `stage2/bin/rustc` compiler is shipped to end-users, along with the -`stage 1 {std,rustc}` artifacts. - -If you want to learn more about `x.py`, read its README.md -[here](https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md). - -#### Build Flags - -There are other flags you can pass to the build command of `x.py` that can be -beneficial to cutting down compile times or fitting other things you might -need to change. They are: - -```txt -Options: - -v, --verbose use verbose output (-vv for very verbose) - -i, --incremental use incremental compilation - --config FILE TOML configuration file for build - --build BUILD build target of the stage0 compiler - --host HOST host targets to build - --target TARGET target targets to build - --on-fail CMD command to run on failure - --stage N stage to build - --keep-stage N stage to keep without recompiling - --src DIR path to the root of the rust checkout - -j, --jobs JOBS number of jobs to run in parallel - -h, --help print this help message -``` - -For hacking, often building the stage 1 compiler is enough, but for -final testing and release, the stage 2 compiler is used. - -`./x.py check` is really fast to build the rust compiler. -It is, in particular, very useful when you're doing some kind of -"type-based refactoring", like renaming a method, or changing the -signature of some function. - - - -Once you've created a config.toml, you are now ready to run -`x.py`. There are a lot of options here, but let's start with what is -probably the best "go to" command for building a local rust: - -```bash -> ./x.py build -i --stage 1 src/libstd -``` - -This may *look* like it only builds libstd, but that is not the case. -What this command does is the following: - -- Build `libstd` using the stage0 compiler (using incremental) -- Build `librustc` using the stage0 compiler (using incremental) - - This produces the stage1 compiler -- Build libstd using the stage1 compiler (cannot use incremental) - -This final product (stage1 compiler + libs built using that compiler) -is what you need to build other rust programs (unless you use `#![no_std]` or -`#![no_core]`). - -The command includes the `-i` switch which enables incremental compilation. -This will be used to speed up the first two steps of the process: -in particular, if you make a small change, we ought to be able to use your old -results to make producing the stage1 **compiler** faster. - -Unfortunately, incremental cannot be used to speed up making the -stage1 libraries. This is because incremental only works when you run -the *same compiler* twice in a row. In this case, we are building a -*new stage1 compiler* every time. Therefore, the old incremental -results may not apply. **As a result, you will probably find that -building the stage1 `libstd` is a bottleneck for you** -- but fear not, -there is a (hacky) workaround. See [the section on "recommended -workflows"](#workflow) below. - -Note that this whole command just gives you a subset of the full `rustc` -build. The **full** `rustc` build (what you get if you just say `./x.py -build`) has quite a few more steps: - -- Build `librustc` and `rustc` with the stage1 compiler. - - The resulting compiler here is called the "stage2" compiler. -- Build libstd with stage2 compiler. -- Build librustdoc and a bunch of other things with the stage2 compiler. - - - -### Build specific components - - Build only the libcore library - -```bash -> ./x.py build src/libcore -``` - - Build the libcore and libproc_macro library only - -```bash -> ./x.py build src/libcore src/libproc_macro -``` - - Build only libcore up to Stage 1 - -```bash -> ./x.py build src/libcore --stage 1 -``` - -Sometimes you might just want to test if the part you’re working on can -compile. Using these commands you can test that it compiles before doing -a bigger build to make sure it works with the compiler. As shown before -you can also pass flags at the end such as --stage. - -### Creating a rustup toolchain - -Once you have successfully built `rustc`, you will have created a bunch -of files in your `build` directory. In order to actually run the -resulting `rustc`, we recommend creating rustup toolchains. The first -one will run the stage1 compiler (which we built above). The second -will execute the stage2 compiler (which we did not build, but which -you will likely need to build at some point; for example, if you want -to run the entire test suite). - -```bash -> rustup toolchain link stage1 build//stage1 -> rustup toolchain link stage2 build//stage2 -``` - -The `` would typically be one of the following: - -- Linux: `x86_64-unknown-linux-gnu` -- Mac: `x86_64-apple-darwin` -- Windows: `x86_64-pc-windows-msvc` - -Now you can run the `rustc` you built with. If you run with `-vV`, you -should see a version number ending in `-dev`, indicating a build from -your local environment: - -```bash -> rustc +stage1 -vV -rustc 1.25.0-dev -binary: rustc -commit-hash: unknown -commit-date: unknown -host: x86_64-unknown-linux-gnu -release: 1.25.0-dev -LLVM version: 4.0 -``` - - - -### Suggested workflows for faster builds of the compiler - -There are two workflows that are useful for faster builds of the compiler. - -**Check, check, and check again.** The first workflow, which is useful -when doing simple refactorings, is to run `./x.py check` -continuously. Here you are just checking that the compiler can -**build**, but often that is all you need (e.g., when renaming a -method). You can then run `./x.py build` when you actually need to -run tests. - -In fact, it is sometimes useful to put off tests even when you are not -100% sure the code will work. You can then keep building up -refactoring commits and only run the tests at some later time. You can -then use `git bisect` to track down **precisely** which commit caused -the problem. A nice side-effect of this style is that you are left -with a fairly fine-grained set of commits at the end, all of which -build and pass tests. This often helps reviewing. - -**Incremental builds with `--keep-stage`.** Sometimes just checking -whether the compiler builds is not enough. A common example is that -you need to add a `debug!` statement to inspect the value of some -state or better understand the problem. In that case, you really need -a full build. By leveraging incremental, though, you can often get -these builds to complete very fast (e.g., around 30 seconds). The only -catch is this requires a bit of fudging and may produce compilers that -don't work (but that is easily detected and fixed). - -The sequence of commands you want is as follows: - -- Initial build: `./x.py build -i --stage 1 src/libstd` - - As [documented above](#command), this will build a functional - stage1 compiler as part of running all stage0 commands (which include - building a `libstd` compatible with the stage1 compiler) as well as the - first few steps of the "stage 1 actions" up to "stage1 (sysroot stage1) - builds libstd". -- Subsequent builds: `./x.py build -i --stage 1 src/libstd --keep-stage 1` - - Note that we added the `--keep-stage 1` flag here - -As mentioned, the effect of `--keep-stage 1` is that we just *assume* that the -old standard library can be re-used. If you are editing the compiler, this -is almost always true: you haven't changed the standard library, after -all. But sometimes, it's not true: for example, if you are editing -the "metadata" part of the compiler, which controls how the compiler -encodes types and other states into the `rlib` files, or if you are -editing things that wind up in the metadata (such as the definition of -the MIR). - -**The TL;DR is that you might get weird behavior from a compile when -using `--keep-stage 1`** -- for example, strange -[ICEs](appendix/glossary.html) or other panics. In that case, you -should simply remove the `--keep-stage 1` from the command and -rebuild. That ought to fix the problem. - -You can also use `--keep-stage 1` when running tests. Something like this: - -- Initial test run: `./x.py test -i --stage 1 src/test/ui` -- Subsequent test run: `./x.py test -i --stage 1 src/test/ui --keep-stage 1` - -### Building with system LLVM - -By default, LLVM is built from source, and that can take significant amount of time. -An alternative is to use LLVM already installed on your computer. - -This is specified in the `target` section of `config.toml`: - -```toml -[target.x86_64-unknown-linux-gnu] -llvm-config = "/path/to/llvm/llvm-7.0.1/bin/llvm-config" -``` - -### Other `x.py` commands - -Here are a few other useful `x.py` commands. We'll cover some of them in detail -in other sections: - -- Building things: - - `./x.py clean` – clean up the build directory (`rm -rf build` works too, - but then you have to rebuild LLVM) - - `./x.py build --stage 1` – builds everything using the stage 1 compiler, - not just up to libstd - - `./x.py build` – builds the stage2 compiler -- Running tests (see the [section on running tests](./tests/running.html) for - more details): - - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd - - `./x.py test --stage 1 src/test/ui` – runs the `ui` test suite - - `./x.py test --stage 1 src/test/ui/const-generics` - runs all the tests in - the `const-generics/` subdirectory of the `ui` test suite - - `./x.py test --stage 1 src/test/ui/const-generics/const-types.rs` - runs - the single test `const-types.rs` from the `ui` test suite - -### ctags - -One of the challenges with rustc is that the RLS can't handle it, since it's a -bootstrapping compiler. This makes code navigation difficult. One solution is to -use `ctags`. - -`ctags` has a long history and several variants. Exuberant Ctags seems to be -quite commonly distributed but it does not have out-of-box Rust support. Some -distributions seem to use [Universal Ctags][utags], which is a maintained fork -and does have built-in Rust support. - -The following script can be used to set up Exuberant Ctags: -[https://github.com/nikomatsakis/rust-etags][etags]. - -`ctags` integrates into emacs and vim quite easily. The following can then be -used to build and generate tags: - -```console -$ rust-ctags src/lib* && ./x.py build -``` - -This allows you to do "jump-to-def" with whatever functions were around when -you last built, which is ridiculously useful. - -[etags]: https://github.com/nikomatsakis/rust-etags -[utags]: https://github.com/universal-ctags/ctags - -### Cleaning out build directories - -Sometimes you need to start fresh, but this is normally not the case. -If you need to run this then rustbuild is most likely not acting right and -you should file a bug as to what is going wrong. If you do need to clean -everything up then you only need to run one command! - - ```bash - > ./x.py clean - ``` - -### Compiler Documentation - -The documentation for the rust components are found at [rustc doc]. - -[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ From 16d731801a821363609e846afcc5a870ebf8da4a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 5 Nov 2019 11:11:45 -0600 Subject: [PATCH 0720/1812] fix links --- src/building/how-to-build-and-run.md | 2 +- src/building/suggested.md | 2 +- src/profiling/with_perf.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 514250769..5e049e39e 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -256,7 +256,7 @@ in other sections: - `./x.py build --stage 1` – builds everything using the stage 1 compiler, not just up to libstd - `./x.py build` – builds the stage2 compiler -- Running tests (see the [section on running tests](./tests/running.html) for +- Running tests (see the [section on running tests](../tests/running.html) for more details): - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd - `./x.py test --stage 1 src/test/ui` – runs the `ui` test suite diff --git a/src/building/suggested.md b/src/building/suggested.md index 427a44858..6b23f2a0d 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -53,7 +53,7 @@ the MIR). **The TL;DR is that you might get weird behavior from a compile when using `--keep-stage 1`** -- for example, strange -[ICEs](appendix/glossary.html) or other panics. In that case, you +[ICEs](../appendix/glossary.html) or other panics. In that case, you should simply remove the `--keep-stage 1` from the command and rebuild. That ought to fix the problem. diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 7582eece5..9615e9e2a 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -14,7 +14,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or - Make a rustup toolchain pointing to that result - see [the "build and run" section for instructions][b-a-r] -[b-a-r]: ../how-to-build-and-run.html#toolchain +[b-a-r]: ../building/how-to-build-and-run.html#toolchain ## Gathering a perf profile From ab4978cb3b20b7f48d3c18a941f158ba142e9668 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 5 Nov 2019 21:51:45 -0600 Subject: [PATCH 0721/1812] Fix diagram src --- src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index fd54c80cf..126509077 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -39,7 +39,7 @@ Building stage2 tool error_index_generator A deeper look into `x.py`'s phases can be seen here: -A diagram of the rustc compilation phases +A diagram of the rustc compilation phases Keep in mind this diagram is a simplification, i.e. `rustdoc` can be built at different stages, the process is a bit different when passing flags such as From dca6a075511981ab8ef7d4836e925a22aeab6df2 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 7 Nov 2019 08:51:31 +0900 Subject: [PATCH 0722/1812] Add link to git repository for book --- book.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/book.toml b/book.toml index 82a6b59b0..94b0e6d8c 100644 --- a/book.toml +++ b/book.toml @@ -7,6 +7,7 @@ description = "A guide to developing rustc" create-missing = false [output.html] +git-repository-url = "https://github.com/rust-lang/rustc-guide" [output.html.fold] enable = true From 3a4c193747bc451e58d0432fccc123aa44101a1b Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Fri, 8 Nov 2019 11:09:45 -0500 Subject: [PATCH 0723/1812] Clarify function name and add links (#506) * Clarify function name and add links rustc_interface::interface::run_compiler (https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/fn.run_compiler.html) --- src/rustc-driver.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 715e6295d..f2ed1bab8 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -9,17 +9,18 @@ for running code at particular times during the compilation process, allowing third parties to effectively use `rustc`'s internals as a library for analysing a crate or emulating the compiler in-process (e.g. the RLS or rustdoc). -For those using `rustc` as a library, the `interface::run_compiler()` function is the main -entrypoint to the compiler. It takes a configuration for the compiler and a closure that -takes a [`Compiler`]. `run_compiler` creates a `Compiler` from the configuration and passes -it to the closure. Inside the closure, you can use the `Compiler` to drive queries to compile -a crate and get the results. This is what the `rustc_driver` does too. +For those using `rustc` as a library, the [`rustc_interface::interface::run_compiler()`][i_rc] +function is the main entrypoint to the compiler. It takes a configuration for the compiler +and a closure that takes a [`Compiler`]. `run_compiler` creates a `Compiler` from the +configuration and passes it to the closure. Inside the closure, you can use the `Compiler` +to drive queries to compile a crate and get the results. This is what the `rustc_driver` does too. You can see what queries are currently available through the rustdocs for [`Compiler`]. You can see an example of how to use them by looking at the `rustc_driver` implementation, specifically the [`rustc_driver::run_compiler` function][rd_rc] (not to be confused with -`interface::run_compiler`). The `rustc_driver::run_compiler` function takes a bunch of -command-line args and some other configurations and drives the compilation to completion. +[`rustc_interface::interface::run_compiler`][i_rc]). The `rustc_driver::run_compiler` function +takes a bunch of command-line args and some other configurations and +drives the compilation to completion. `rustc_driver::run_compiler` also takes a [`Callbacks`][cb]. In the past, when the `rustc_driver::run_compiler` was the primary way to use the compiler as a @@ -47,6 +48,7 @@ thread-locals, although you should rarely need to touch it. [cb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/trait.Callbacks.html [rd_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.run_compiler.html +[i_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/fn.run_compiler.html [`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/ [`Compiler`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html From a7beb12a13f4450fa3c3f232fa2361a62aa664fc Mon Sep 17 00:00:00 2001 From: PotHix Date: Thu, 7 Nov 2019 22:26:47 -0300 Subject: [PATCH 0724/1812] Update the "Testing infrastructure" section The testing infrastructure was migrated from Travis and AppVeyor to Azure Pipelines some time ago. This commit updates the documentation to reflect this change. Fixes #500. --- src/tests/intro.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index f818fc240..e78e33475 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -103,27 +103,27 @@ including: ## Testing infrastructure -When a Pull Request is opened on Github, [Travis] will automatically launch a -build that will run all tests on a single configuration (x86-64 linux). In -essence, it runs `./x.py test` after building. +When a Pull Request is opened on Github, [Azure Pipelines] will automatically +launch a build that will run all tests on some configurations +(x86_64-gnu-llvm-6.0 linux. x86_64-gnu-tools linux, mingw-check linux). In +essence, it runs `./x.py test` after building for each of them. The integration bot [bors] is used for coordinating merges to the master branch. When a PR is approved, it goes into a [queue] where merges are tested -one at a time on a wide set of platforms using Travis and [Appveyor] -(currently over 50 different configurations). Most platforms only run the -build steps, some run a restricted set of tests, only a subset run the full -suite of tests (see Rust's [platform tiers]). +one at a time on a wide set of platforms using Azure Pipelines (currently over +50 different configurations). Most platforms only run the build steps, some run +a restricted set of tests, only a subset run the full suite of tests (see +Rust's [platform tiers]). -[Travis]: https://travis-ci.org/rust-lang/rust +[Azure Pipelines]: https://dev.azure.com/rust-lang/rust/ [bors]: https://github.com/servo/homu [queue]: https://buildbot2.rust-lang.org/homu/queue/rust -[Appveyor]: https://ci.appveyor.com/project/rust-lang/rust [platform tiers]: https://forge.rust-lang.org/platform-support.html ## Testing with Docker images The Rust tree includes [Docker] image definitions for the platforms used on -Travis in [src/ci/docker]. The script [src/ci/docker/run.sh] is used to build +Azure Pipelines in [src/ci/docker]. The script [src/ci/docker/run.sh] is used to build the Docker image, run it, build Rust within the image, and run the tests. > TODO: What is a typical workflow for testing/debugging on a platform that From afa31689216fbc6bf665ecd80054ffb8e18ab592 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 8 Nov 2019 00:50:26 +0200 Subject: [PATCH 0725/1812] fix typo --- src/building/suggested.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 6b23f2a0d..07f834eac 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -1,7 +1,7 @@ # Suggested Workflows The full bootstrapping process takes quite a while. Here are three suggestions -to make you're life easier. +to make your life easier. ## Check, check, and check again From 78609913b4332b175904bc86834063af554d664a Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 7 Nov 2019 23:24:38 +0200 Subject: [PATCH 0726/1812] rustc_back has long since been renamed to rustc_target --- src/high-level-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 93b5592c3..eedb3e632 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -8,7 +8,7 @@ standard library and the compiler. This document, of course, focuses on the latter. Rustc consists of a number of crates, including `syntax`, -`rustc`, `rustc_back`, `rustc_codegen`, `rustc_driver`, and +`rustc`, `rustc_target`, `rustc_codegen`, `rustc_driver`, and many more. The source for each crate can be found in a directory like `src/libXXX`, where `XXX` is the crate name. @@ -139,4 +139,4 @@ take: [query model]: query.html [high-level intermediate representation]: hir.html -[lowering]: lowering.html \ No newline at end of file +[lowering]: lowering.html From 81428c1c1e21e9a1cc9936343b6440369e00c2c7 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 7 Nov 2019 23:42:46 +0200 Subject: [PATCH 0727/1812] those are now documented in this guide --- src/high-level-overview.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index eedb3e632..625559034 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -66,10 +66,6 @@ of the compiler and not intended to be stable (though they do wind up getting used by some crates in the wild; a practice we hope to gradually phase out). -Each crate has a `README.md` file that describes, at a high-level, -what it contains, and tries to give some kind of explanation (some -better than others). - ## The main stages of compilation The Rust compiler is in a bit of transition right now. It used to be a From 399d543e38179b056a91a7c92a9ac67650556a6b Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 7 Nov 2019 22:10:49 +0200 Subject: [PATCH 0728/1812] whitespace --- src/building/compiler-documenting.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md index 5c80c3d1c..345a324bd 100644 --- a/src/building/compiler-documenting.md +++ b/src/building/compiler-documenting.md @@ -2,10 +2,10 @@ You might want to build documentation of the various components available like the standard library. There’s two ways to go about this. - You can run rustdoc directly on the file to make sure the HTML is - correct, which is fast. Alternatively, you can build the documentation - as part of the build process through x.py. Both are viable methods - since documentation is more about the content. +You can run rustdoc directly on the file to make sure the HTML is +correct, which is fast. Alternatively, you can build the documentation +as part of the build process through x.py. Both are viable methods +since documentation is more about the content. ## Document everything From 3e1213e728370d6d255bd3fb811c87a0413c9592 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 7 Nov 2019 22:12:50 +0200 Subject: [PATCH 0729/1812] trim down "Document rustc" --- src/building/compiler-documenting.md | 24 +++++++----------------- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md index 345a324bd..16df10f72 100644 --- a/src/building/compiler-documenting.md +++ b/src/building/compiler-documenting.md @@ -9,13 +9,13 @@ since documentation is more about the content. ## Document everything -```ignore +```bash ./x.py doc ``` ## If you want to avoid the whole Stage 2 build -```ignore +```bash ./x.py doc --stage 1 ``` @@ -24,7 +24,7 @@ and then it documents the files. ## Document specific components -```ignore +```bash ./x.py doc src/doc/book ./x.py doc src/doc/nomicon ./x.py doc src/doc/book src/libstd @@ -35,25 +35,15 @@ Much like individual tests or building certain components you can build only ## Document internal rustc items -Compiler documentation is not built by default. There's a flag in -config.toml for achieving the same. -But, when enabled, compiler documentation does include internal items. - -Next open up config.toml and make sure these two lines are set to true: +Compiler documentation is not built by default. To enable it, modify config.toml: ```toml -docs = true +[build] compiler-docs = true ``` -When you want to build the compiler docs as well run this command: - -```ignore -./x.py doc -``` - -This will see that the docs and compiler-docs options are set to true -and build the normally hidden compiler docs! +Note that when enabled, +documentation for internal compiler items will also be built. ### Compiler Documentation From 75a5f9236c689a547fe207a10854f0775bce7937 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 8 Nov 2019 10:31:12 -0600 Subject: [PATCH 0730/1812] Fix chalk links --- src/traits/chalk-overview.md | 6 +++--- src/traits/wf.md | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index a29939919..0f102d4d0 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -230,7 +230,7 @@ Likewise, lowering tests use the [`lowering_success!` and [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification [`ProgramClause`]: https://rust-lang.github.io/chalk/chalk_ir/enum.ProgramClause.html -[`ProgramEnvironment`]: https://rust-lang.github.io/chalk/chalk/program_environment/struct.ProgramEnvironment.html +[`ProgramEnvironment`]: https://rust-lang.github.io/chalk/chalk_integration/program_environment/struct.ProgramEnvironment.html [chalk_engine]: https://rust-lang.github.io/chalk/chalk_engine [chalk_ir]: https://rust-lang.github.io/chalk/chalk_ir/index.html [chalk_parse]: https://rust-lang.github.io/chalk/chalk_parse/index.html @@ -238,7 +238,7 @@ Likewise, lowering tests use the [`lowering_success!` and [chalk_rust_ir]: https://rust-lang.github.io/chalk/chalk_rust_ir/index.html [doc-chalk]: https://rust-lang.github.io/chalk/chalk/index.html [engine-context]: https://rust-lang.github.io/chalk/chalk_engine/context/index.html -[chalk-program]: https://rust-lang.github.io/chalk/chalk/program/struct.Program.html +[chalk-program]: https://rust-lang.github.io/chalk/chalk_integration/program/struct.Program.html [binders-struct]: https://rust-lang.github.io/chalk/chalk_ir/struct.Binders.html [chalk-ast]: https://rust-lang.github.io/chalk/chalk_parse/ast/index.html @@ -246,7 +246,7 @@ Likewise, lowering tests use the [`lowering_success!` and [chalk-test-lowering-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs#L8-L31 [chalk-test-lowering]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs [chalk-test-wf]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf/test.rs#L1 -[chalki]: https://rust-lang.github.io/chalk/chalki/index.html +[chalki]: https://github.com/rust-lang/chalk/blob/master/src/main.rs [clause]: https://github.com/rust-lang/chalk/blob/master/GLOSSARY.md#clause [coherence-src]: https://rust-lang.github.io/chalk/chalk_solve/coherence/index.html [ir-code]: https://rust-lang.github.io/chalk/chalk_rust_ir/ diff --git a/src/traits/wf.md b/src/traits/wf.md index a6981bf4c..aa17f8c2c 100644 --- a/src/traits/wf.md +++ b/src/traits/wf.md @@ -13,12 +13,12 @@ say that the construct is well-formed. If not, we report an error to the user. Well-formedness checking happens in the [`chalk/chalk-solve/src/wf.rs`][wf] module in chalk. After you have read this chapter, you may find useful to see -an extended set of examples in the [`chalk/src/test/wf.rs`][wf_test] submodule. +an extended set of examples in the [`chalk/tests/test/wf_lowering.rs`][wf_test] submodule. The new-style WF checking has not been implemented in rustc yet. [wf]: https://github.com/rust-lang/chalk/blob/master/chalk-solve/src/wf.rs -[wf_test]: https://github.com/rust-lang/chalk/blob/master/src/test/wf_lowering.rs +[wf_test]: https://github.com/rust-lang/chalk/blob/master/tests/test/wf_lowering.rs We give here a complete reference of the generated goals for each Rust declaration. From 934380b7cfceaaa4e1b9bb0de4a372f32725520b Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Mon, 11 Nov 2019 10:36:45 -0600 Subject: [PATCH 0731/1812] update parser chapter --- src/SUMMARY.md | 2 +- src/appendix/code-index.md | 2 +- src/macro-expansion.md | 3 +++ src/the-parser.md | 48 +++++++++++++++++++++----------------- 4 files changed, 32 insertions(+), 23 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b264f8df4..4a63b9282 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -38,7 +38,7 @@ - [Incremental compilation](./queries/incremental-compilation.md) - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) - [Debugging and Testing](./incrcomp-debugging.md) - - [The parser](./the-parser.md) + - [Lexing and Parsing](./the-parser.md) - [`#[test]` Implementation](./test-implementation.md) - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index d58c4ea1b..0f423c6a4 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -24,7 +24,7 @@ Item | Kind | Short description | Chapter | `SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) -`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/libsyntax/parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html) +`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html) `syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index d1f74ed8b..a3a3ae762 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -1,5 +1,8 @@ # Macro expansion +> `libsyntax`, `librustc_expand`, and `libsyntax_ext` are all undergoing +> refactoring, so some of the links in this chapter may be broken. + Macro expansion happens during parsing. `rustc` has two parsers, in fact: the normal Rust parser, and the macro parser. During the parsing phase, the normal Rust parser will set aside the contents of macros and their invocations. Later, diff --git a/src/the-parser.md b/src/the-parser.md index 5796ae40e..d089a8418 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -1,29 +1,35 @@ -# The Parser +# Lexing and Parsing -The parser is responsible for converting raw Rust source code into a structured -form which is easier for the compiler to work with, usually called an [*Abstract -Syntax Tree*][ast]. An AST mirrors the structure of a Rust program in memory, -using a `Span` to link a particular AST node back to its source text. +> The parser and lexer are currently undergoing a lot of refactoring, so parts +> of this chapter may be out of date. + +The very first thing the compiler does is take the program (in Unicode +characters) and turn it into something the compiler can work with more +conveniently than strings. This happens in two stages: Lexing and Parsing. -The bulk of the parser lives in the [libsyntax] crate. +Lexing takes strings and turns them into streams of tokens. For example, +`a.b + c` would be turned into the tokens `a`, `.`, `b`, `+`, and `c`. +The lexer lives in [`librustc_lexer`][lexer]. -Like most parsers, the parsing process is composed of two main steps, +[lexer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html -- lexical analysis – turn a stream of characters into a stream of token trees -- parsing – turn the token trees into an AST +Parsing then takes streams of tokens and turns them into a structured +form which is easier for the compiler to work with, usually called an [*Abstract +Syntax Tree*][ast] (AST). An AST mirrors the structure of a Rust program in memory, +using a `Span` to link a particular AST node back to its source text. -The `syntax` crate contains several main players, +The AST is defined in [`libsyntax`][libsyntax], along with some definitions for +tokens and token streams, data structures/traits for mutating ASTs, and shared +definitions for other AST-related parts of the compiler (like the lexer and +macro-expansion). -- a [`SourceMap`] for mapping AST nodes to their source code -- the [ast module] contains types corresponding to each AST node -- a [`StringReader`] for lexing source code into tokens -- the [parser module] and [`Parser`] struct are in charge of actually parsing - tokens into AST nodes, -- and a [visit module] for walking the AST and inspecting or mutating the AST - nodes. +The parser is defined in [`librustc_parse`][librustc_parse], along with a +high-level interface to the lexer and some validation routines that run after +macro expansion. In particular, the [`rustc_parser::parser`][parser] contains +the parser implementation. The main entrypoint to the parser is via the various `parse_*` functions in the -[parser module]. They let you do things like turn a [`SourceFile`][sourcefile] +[parser][parser]. They let you do things like turn a [`SourceFile`][sourcefile] (e.g. the source in a single file) into a token stream, create a parser from the token stream, and then execute the parser to get a `Crate` (the root AST node). @@ -44,14 +50,14 @@ Code for lexical analysis is split between two crates: specific data structures. Specifically, it adds `Span` information to tokens returned by `rustc_lexer` and interns identifiers. - [libsyntax]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/index.html [rustc_errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html [ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/index.html -[parser module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/index.html +[librustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html +[parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/index.html [`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/parser/struct.Parser.html -[`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/lexer/struct.StringReader.html +[`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html [visit module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/visit/index.html [sourcefile]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html From 6d07d62ad3cc1e517fa91fe00b1d454dfe169233 Mon Sep 17 00:00:00 2001 From: ksqsf Date: Tue, 12 Nov 2019 15:56:04 +0800 Subject: [PATCH 0732/1812] backtraces work on Mac --- src/compiler-debugging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 8f3a331aa..736de9771 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -22,9 +22,9 @@ could be useful for debugging. When you have an ICE (panic in the compiler), you can set `RUST_BACKTRACE=1` to get the stack trace of the `panic!` like in -normal Rust programs. IIRC backtraces **don't work** on Mac and on MinGW, +normal Rust programs. IIRC backtraces **don't work** on MinGW, sorry. If you have trouble or the backtraces are full of `unknown`, -you might want to find some way to use Linux or MSVC on Windows. +you might want to find some way to use Linux, Mac, or MSVC on Windows. In the default configuration, you don't have line numbers enabled, so the backtrace looks like this: From 9106ae1c3a9d45366e557902ac96bba383d8330c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 13 Nov 2019 09:51:01 -0600 Subject: [PATCH 0733/1812] add compilers biblio (#512) --- src/appendix/background.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/src/appendix/background.md b/src/appendix/background.md index dbfe6a3db..50a550dc8 100644 --- a/src/appendix/background.md +++ b/src/appendix/background.md @@ -126,3 +126,38 @@ So what does this have to do with regions? Well, we can apply the analogous concept to type and regions. For example, in the type `&'a u32`, `'a` appears free. But in the type `for<'a> fn(&'a u32)`, it does not. + +# Further Reading About Compilers + +> Thanks to `mem`, `scottmcm`, and `Levi` on the official Discord for the +> recommendations, and to `tinaun` for posting a link to a [twitter thread from +> Graydon Hoare](https://twitter.com/graydon_pub/status/1039615569132118016) +> which had some more recommendations! +> +> Other sources: https://gcc.gnu.org/wiki/ListOfCompilerBooks +> +> If you have other suggestions, please feel free to open an issue or PR. + +## Books +- [Types and Programming Languages](https://www.cis.upenn.edu/~bcpierce/tapl/) +- [Programming Language Pragmatics](https://www.cs.rochester.edu/~scott/pragmatics/) +- [Practical Foundations for Programming Languages](https://www.cs.cmu.edu/~rwh/pfpl/2nded.pdf) +- [Compilers: Principles, Techniques, and Tools, 2nd Edition](https://www.amazon.com/dp/9332518661/ref=cm_sw_r_other_apa_1tUSBb5VHAVA1) +- [Garbage Collection: Algorithms for Automatic Dynamic Memory Management](https://www.cs.kent.ac.uk/people/staff/rej/gcbook/) +- [Linkers and Loaders](https://linker.iecc.com/) +- [Advanced Compiler Design and Implementation](https://www.goodreads.com/book/show/887908.Advanced_Compiler_Design_and_Implementation) +- [Building an Optimizing Compiler](https://www.goodreads.com/book/show/2063103.Building_an_Optimizing_Compiler) +- [Crafting Interpreters](http://www.craftinginterpreters.com/) + +## Courses +- [University of Oregon Programming Languages Summer School archive](https://www.cs.uoregon.edu/research/summerschool/archives.html) + +## Wikis +- [Wikipedia](https://en.wikipedia.org/wiki/List_of_programming_languages_by_type) +- [Esoteric Programming Languages](https://esolangs.org/wiki/Main_Page) +- [Stanford Encyclopedia of Philosophy](https://plato.stanford.edu/index.html) +- [nLab](https://ncatlab.org/nlab/show/HomePage) + +## Misc Papers and Blog Posts +- [Programming in Martin-Löf's Type Theory](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.118.6683&rep=rep1&type=pdf) +- [Polymorphism, Subtyping, and Type Inference in MLsub](https://www.cl.cam.ac.uk/~sd601/papers/mlsub-preprint.pdf) From f4e7bbe47377b59f96cf943fe90686bc9dac1e05 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 12 Nov 2019 10:25:55 -0600 Subject: [PATCH 0734/1812] add something for mir opt --- src/mir/optimizations.md | 44 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index ddafa0c99..fb550af4c 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -1 +1,45 @@ # MIR optimizations + +MIR optimizations are optimizations run on the [MIR][mir] to produce better MIR +before codegen. This is important for two reasons: first, it make the final +generated executable code better, and second, it means that LLVM has less work +to do, so compilation is faster. + +[mir]: https://rust-lang.github.io/rustc-guide/mir/index.html + +MIR optimizations run after borrow checking. We run a series of optimization +passes over the MIR to improve it. Some passes are required to run on all code, +some passes don't actually do optimizations but only check stuff, and some +passes are only turned on in `release` mode. + +The [`optimized_mir`][optmir] [query] is called to produce the optimized MIR +for a given [`DefId`][defid]. This query makes sure that the borrow checker has +run and that some validation has occured. Then, it [steals][steal] the MIR +optimizes it, and returns the improved MIR. + +[optmir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html +[query]: https://rust-lang.github.io/rustc-guide/query.html +[defid]: https://rust-lang.github.io/rustc-guide/appendix/glossary.html?highlight=DefId#appendix-c-glossary +[steal]: https://rust-lang.github.io/rustc-guide/mir/passes.html?highlight=steal#stealing + +## Defining optimization passes + +The list of passes run and the order in which they are run is defined by the +[`run_optimization_passes`][rop] function. It contains an array of passes to +run. Each pass in the array is a struct that implements the [`MirPass`] trait. +The array is an array of `&dyn MirPass` trait objects. Typically, a pass is +implemented in its own submodule of the [`rustc_mir::transform`][trans] module. + +[rop]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.run_optimization_passes.html +[`MirPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/trait.MirPass.html +[trans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html + +Some examples of passes are: +- `CleanupNonCodegenStatements`: remove some of the info that is only need for + analyses, rather than codegen. +- `ConstProp`: Does [constant propagation][constprop] + +You can see the ["Implementors" section of the `MirPass` rustdocs][impl] for more examples. + +[impl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/trait.MirPass.html#implementors +[constprop]: https://en.wikipedia.org/wiki/Constant_folding#Constant_propagation From 692ac4df9fa1774320e0a34cd3139937179af421 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 12 Nov 2019 11:21:50 -0600 Subject: [PATCH 0735/1812] add oli note --- src/appendix/glossary.md | 1 + src/mir/optimizations.md | 6 +++++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 5b0f7cfa2..d737e037f 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -45,6 +45,7 @@ LTO | Link-Time Optimizations. A set of optimizations offer memoize | memoization is the process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. MIR | the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](../mir/index.html)) miri | an interpreter for MIR used for constant evaluation ([see more](../miri.html)) +monomorphize | Monomorphization is the process of taking generic implementations of types and functions and producing instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize) newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. NLL | [non-lexical lifetimes](../borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index fb550af4c..cb60af1af 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -3,9 +3,13 @@ MIR optimizations are optimizations run on the [MIR][mir] to produce better MIR before codegen. This is important for two reasons: first, it make the final generated executable code better, and second, it means that LLVM has less work -to do, so compilation is faster. +to do, so compilation is faster. Note that since MIR is generic (not +[monomorphized][monomorph] yet), these optimizations are particularly +effective; we can optimize the generic version, so all of the monomorphizations +are cheaper! [mir]: https://rust-lang.github.io/rustc-guide/mir/index.html +[monomorph]: https://rust-lang.github.io/rustc-guide/appendix/glossary.html?highlight=monomorphize#appendix-c-glossary MIR optimizations run after borrow checking. We run a series of optimization passes over the MIR to improve it. Some passes are required to run on all code, From be4bd173ef75ecacf1c81529926c976705dde172 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 12 Nov 2019 13:36:12 -0600 Subject: [PATCH 0736/1812] typo Co-Authored-By: Yuki Okushi --- src/mir/optimizations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index cb60af1af..d32f50813 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -1,7 +1,7 @@ # MIR optimizations MIR optimizations are optimizations run on the [MIR][mir] to produce better MIR -before codegen. This is important for two reasons: first, it make the final +before codegen. This is important for two reasons: first, it makes the final generated executable code better, and second, it means that LLVM has less work to do, so compilation is faster. Note that since MIR is generic (not [monomorphized][monomorph] yet), these optimizations are particularly From c1eea2169602bf13084c82dddecec3ea96311085 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 12 Nov 2019 13:36:39 -0600 Subject: [PATCH 0737/1812] typo Co-Authored-By: Yuki Okushi --- src/mir/optimizations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index d32f50813..cdbe7b4fa 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -18,7 +18,7 @@ passes are only turned on in `release` mode. The [`optimized_mir`][optmir] [query] is called to produce the optimized MIR for a given [`DefId`][defid]. This query makes sure that the borrow checker has -run and that some validation has occured. Then, it [steals][steal] the MIR +run and that some validation has occurred. Then, it [steals][steal] the MIR optimizes it, and returns the improved MIR. [optmir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html From fe8585a9b6ac5831d2e3b34a06c5441972a06ccf Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 14 Nov 2019 13:34:35 -0600 Subject: [PATCH 0738/1812] some cleanup --- src/SUMMARY.md | 2 -- src/implementing_new_features.md | 2 +- src/important-links.md | 16 ---------------- src/tests/running.md | 2 +- 4 files changed, 2 insertions(+), 20 deletions(-) delete mode 100644 src/important-links.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4a63b9282..2c29666a0 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -113,6 +113,4 @@ --- -[](./important-links.md) - [pau]: ./borrow_check/region_inference/placeholders_and_universes.md diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 73a6a40a0..4b2529fff 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -178,5 +178,5 @@ a new unstable feature: [`feature_gate::check::check_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/check/fn.check_crate.html [value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md [stability in code]: #stability-in-code -[here]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html +[here]: ./stabilization_guide.md [tracking issue]: #tracking-issue diff --git a/src/important-links.md b/src/important-links.md deleted file mode 100644 index 367532519..000000000 --- a/src/important-links.md +++ /dev/null @@ -1,16 +0,0 @@ -# Ignore me - -This file is a collection of links that are not link-checked by anyone else, -but we want them to work. For example, the stabilization guide link is often -posted to tracking issues on GitHub, which might break later if the guide is -changed. - -[Skip this file. Or read it; I'm a book, not a cop.](https://imgur.com/gallery/mSHi8) - -[link](https://forge.rust-lang.org/stabilization-guide.html) -[link](https://forge.rust-lang.org/stabilization-guide.html#updating-documentation) -[link](https://forge.rust-lang.org/stabilization-guide.html#documentation-prs) - -[link](https://rust-lang.github.io/rustc-guide/stabilization_guide.html) -[link](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#updating-documentation) -[link](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#documentation-prs) diff --git a/src/tests/running.md b/src/tests/running.md index ef3227f9a..af10b8551 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -123,7 +123,7 @@ exists in the test file. For example, you can run all the tests in By passing `--pass $mode`, you can reduce the testing time. For each mode, please see [here][mode]. -[mode]: https://rust-lang.github.io/rustc-guide/tests/adding.html#tests-that-do-not-result-in-compile-errors +[mode]: ./adding.md#tests-that-do-not-result-in-compile-errors ## Using incremental compilation From 3981656d4427f3b1c8a78d1719200d7f2383102f Mon Sep 17 00:00:00 2001 From: homersimpsons Date: Tue, 19 Nov 2019 23:28:35 +0100 Subject: [PATCH 0739/1812] ty.md: fix a typo --- src/ty.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/ty.md b/src/ty.md index 6a1cf4444..6295a0db1 100644 --- a/src/ty.md +++ b/src/ty.md @@ -60,8 +60,8 @@ defining all of the different kinds of types in the compiler. > N.B. inspecting the `sty` field on types during type inference can be > risky, as there may be inference variables and other things to -> consider, or sometimes types are not yet known that will become -> known later.). +> consider, or sometimes types are not yet known and will become +> known later. To allocate a new type, you can use the various `mk_` methods defined on the `tcx`. These have names that correspond mostly to the various kinds From b3aa636dc24907544f661135ac6f1b2a7138dcd8 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 20 Nov 2019 10:35:58 -0300 Subject: [PATCH 0740/1812] Minor mir chapter fixes --- src/appendix/glossary.md | 2 +- src/mir/optimizations.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index d737e037f..a773e3521 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -45,7 +45,7 @@ LTO | Link-Time Optimizations. A set of optimizations offer memoize | memoization is the process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. MIR | the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](../mir/index.html)) miri | an interpreter for MIR used for constant evaluation ([see more](../miri.html)) -monomorphize | Monomorphization is the process of taking generic implementations of types and functions and producing instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). +monomorphize | Monomorphization is the process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize) newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. NLL | [non-lexical lifetimes](../borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index cdbe7b4fa..f3fdd52f3 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -39,7 +39,7 @@ implemented in its own submodule of the [`rustc_mir::transform`][trans] module. [trans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html Some examples of passes are: -- `CleanupNonCodegenStatements`: remove some of the info that is only need for +- `CleanupNonCodegenStatements`: remove some of the info that is only needed for analyses, rather than codegen. - `ConstProp`: Does [constant propagation][constprop] From a839812326c8a41aed7bbab6aec516302e037342 Mon Sep 17 00:00:00 2001 From: Tyler Mandry Date: Wed, 20 Nov 2019 14:37:28 -0600 Subject: [PATCH 0741/1812] -Cllvm-arg is actually -Cllvm-args --- src/codegen/debugging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/codegen/debugging.md b/src/codegen/debugging.md index 1f38c9eee..4eab30606 100644 --- a/src/codegen/debugging.md +++ b/src/codegen/debugging.md @@ -110,9 +110,9 @@ tutorial above): - The `--emit llvm-ir` option emits a `.ll` file with LLVM IR in textual format - The `--emit llvm-bc` option emits in bytecode format (`.bc`) -- Passing `-Cllvm-arg=` allows passing pretty much all the +- Passing `-Cllvm-args=` allows passing pretty much all the options that tools like llc and opt would accept; - e.g. `-Cllvm-arg=-print-before-all` to print IR before every LLVM + e.g. `-Cllvm-args=-print-before-all` to print IR before every LLVM pass. - The `-Cno-prepopulate-passes` will avoid pre-populate the LLVM pass manager with a list of passes. This will allow you to view the LLVM From 0930e773f1123f9c118f81af3f00b09f1dafc17e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sun, 24 Nov 2019 18:32:18 -0600 Subject: [PATCH 0742/1812] website has disappeared --- src/rustdoc.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/rustdoc.md b/src/rustdoc.md index 318a8e2e1..072bf31c1 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -219,9 +219,6 @@ tests to run before handing them off to the libtest test runner. One notable location in `test.rs` is the function `make_test`, which is where hand-written doctests get transformed into something that can be executed. -Some extra reading about `make_test` can be found -[here](https://quietmisdreavus.net/code/2018/02/23/how-the-doctests-get-made/). - ## Dotting i's and crossing t's So that's rustdoc's code in a nutshell, but there's more things in the repo From 55e5a8a2fa08dc45cb9279772c0317289b2eccd4 Mon Sep 17 00:00:00 2001 From: Ivan Tham Date: Mon, 25 Nov 2019 08:14:10 +0800 Subject: [PATCH 0743/1812] Fix typo --- src/diagnostics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 9cfd5a3e1..040e7db01 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -60,7 +60,7 @@ let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); if let Ok(snippet) = sess.source_map().span_to_snippet(sp) { // Use the snippet to generate a suggested fix - err.span_suggestion(suggestion_sp, "try using a qux here", format!("qux {}", snip)); + err.span_suggestion(suggestion_sp, "try using a qux here", format!("qux {}", snippet)); } else { // If we weren't able to generate a snippet, then emit a "help" message // instead of a concrete "suggestion". In practice this is unlikely to be @@ -100,7 +100,7 @@ if let Ok(snippet) = sess.source_map().span_to_snippet(sp) { err.span_suggestion( suggestion_sp, "try using a qux here", - format!("qux {}", snip), + format!("qux {}", snippet), Applicability::MachineApplicable, ); } else { From d373bca885d852be409f2aaa1e69867f1fc1af5b Mon Sep 17 00:00:00 2001 From: Hanif Bin Ariffin Date: Thu, 21 Nov 2019 13:52:07 -0500 Subject: [PATCH 0744/1812] Couple of changes to code so that its safe Specifically, `> $1` causes it to write into the file $1 if it exist And `> ./x.py` is particularly bad because it overwrite the script with empty spaces... --- src/building/how-to-build-and-run.md | 20 ++++++------ src/diagnostics.md | 10 +++--- src/hir.md | 2 +- src/profiling/with_perf.md | 48 ++++++++++++++-------------- src/tests/running.md | 24 +++++++------- 5 files changed, 52 insertions(+), 52 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 5e049e39e..69c418c28 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -145,7 +145,7 @@ Once you've created a config.toml, you are now ready to run probably the best "go to" command for building a local rust: ```bash -> ./x.py build -i --stage 1 src/libstd +./x.py build -i --stage 1 src/libstd ``` This may *look* like it only builds libstd, but that is not the case. @@ -190,19 +190,19 @@ build`) has quite a few more steps: Build only the libcore library ```bash -> ./x.py build src/libcore +./x.py build src/libcore ``` Build the libcore and libproc_macro library only ```bash -> ./x.py build src/libcore src/libproc_macro +./x.py build src/libcore src/libproc_macro ``` Build only libcore up to Stage 1 ```bash -> ./x.py build src/libcore --stage 1 +./x.py build src/libcore --stage 1 ``` Sometimes you might just want to test if the part you’re working on can @@ -221,8 +221,8 @@ you will likely need to build at some point; for example, if you want to run the entire test suite). ```bash -> rustup toolchain link stage1 build//stage1 -> rustup toolchain link stage2 build//stage2 +rustup toolchain link stage1 build//stage1 +rustup toolchain link stage2 build//stage2 ``` The `` would typically be one of the following: @@ -236,7 +236,7 @@ should see a version number ending in `-dev`, indicating a build from your local environment: ```bash -> rustc +stage1 -vV +$ rustc +stage1 -vV rustc 1.25.0-dev binary: rustc commit-hash: unknown @@ -272,6 +272,6 @@ If you need to run this then rustbuild is most likely not acting right and you should file a bug as to what is going wrong. If you do need to clean everything up then you only need to run one command! - ```bash - > ./x.py clean - ``` +```bash +./x.py clean +``` diff --git a/src/diagnostics.md b/src/diagnostics.md index 040e7db01..a9a9221ab 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -291,11 +291,11 @@ Lints can be turned on in groups. These groups are declared in the For example, ```rust,ignore - add_lint_group!(sess, - "nonstandard_style", - NON_CAMEL_CASE_TYPES, - NON_SNAKE_CASE, - NON_UPPER_CASE_GLOBALS); +add_lint_group!(sess, + "nonstandard_style", + NON_CAMEL_CASE_TYPES, + NON_SNAKE_CASE, + NON_UPPER_CASE_GLOBALS); ``` This defines the `nonstandard_style` group which turns on the listed lints. A diff --git a/src/hir.md b/src/hir.md index b10042270..0a48d1123 100644 --- a/src/hir.md +++ b/src/hir.md @@ -15,7 +15,7 @@ You can view the HIR representation of your code by passing the `-Zunpretty=hir-tree` flag to rustc: ```bash -> cargo rustc -- -Zunpretty=hir-tree +cargo rustc -- -Zunpretty=hir-tree ``` ### Out-of-band storage and the `Crate` type diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 9615e9e2a..cca2d06d1 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -28,7 +28,7 @@ of events, though, like cache misses and so forth. The basic `perf` command is this: ```bash -> perf record -F99 --call-graph dwarf XXX +perf record -F99 --call-graph dwarf XXX ``` The `-F99` tells perf to sample at 99 Hz, which avoids generating too @@ -39,7 +39,7 @@ information from debuginfo, which is accurate. The `XXX` is the command you want to profile. So, for example, you might do: ```bash -> perf record -F99 --call-graph dwarf cargo + rustc +perf record -F99 --call-graph dwarf cargo + rustc ``` to run `cargo` -- here `` should be the name of the toolchain @@ -59,7 +59,7 @@ do that, the first step is to clone [the rustc-perf repository][rustc-perf-gh]: ```bash -> git clone https://github.com/rust-lang-nursery/rustc-perf +git clone https://github.com/rust-lang-nursery/rustc-perf ``` [rustc-perf-gh]: https://github.com/rust-lang-nursery/rustc-perf @@ -75,13 +75,13 @@ do profiling for you! You can find For example, to measure the clap-rs test, you might do: ```bash -> ./target/release/collector - --output-repo /path/to/place/output - profile perf-record - --rustc /path/to/rustc/executable/from/your/build/directory - --cargo `which cargo` - --filter clap-rs - --builds Check +./target/release/collector \ + --output-repo /path/to/place/output \ + profile perf-record \ + --rustc /path/to/rustc/executable/from/your/build/directory \ + --cargo `which cargo` \ + --filter clap-rs \ + --builds Check \ ``` You can also use that same command to use cachegrind or other profiling tools. @@ -97,7 +97,7 @@ example: [dir]: https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector/benchmarks ```bash -> cd collector/benchmarks/clap-rs +cd collector/benchmarks/clap-rs ``` In this case, let's say we want to profile the `cargo check` @@ -106,8 +106,8 @@ build the dependencies: ```bash # Setup: first clean out any old results and build the dependencies: -> cargo + clean -> CARGO_INCREMENTAL=0 cargo + check +cargo + clean +CARGO_INCREMENTAL=0 cargo + check ``` (Again, `` should be replaced with the name of the @@ -118,8 +118,8 @@ running cargo check. I tend to use `cargo rustc` for this, since it also allows me to add explicit flags, which we'll do later on. ```bash -> touch src/lib.rs -> CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib +touch src/lib.rs +CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib ``` Note that final command: it's a doozy! It uses the `cargo rustc` @@ -130,7 +130,7 @@ the `--profile check` and `--lib` options specify that we are doing a At this point, we can use `perf` tooling to analyze the results. For example: ```bash -> perf report +perf report ``` will open up an interactive TUI program. In simple cases, that can be @@ -149,8 +149,8 @@ If you want to profile an NLL run, you can just pass extra options to the `cargo rustc` command, like so: ```bash -> touch src/lib.rs -> CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib -- -Zborrowck=mir +touch src/lib.rs +CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib -- -Zborrowck=mir ``` [pf]: https://github.com/nikomatsakis/perf-focus @@ -180,7 +180,7 @@ would analyze NLL performance. You can install perf-focus using `cargo install`: ```bash -> cargo install perf-focus +cargo install perf-focus ``` ### Example: How much time is spent in MIR borrowck? @@ -191,7 +191,7 @@ function of the MIR borrowck is called `do_mir_borrowck`, so we can do this command: ```bash -> perf focus '{do_mir_borrowck}' +$ perf focus '{do_mir_borrowck}' Matcher : {do_mir_borrowck} Matches : 228 Not Matches: 542 @@ -216,7 +216,7 @@ samples where `do_mir_borrowck` was on the stack: in this case, 29%. by doing: ```bash -> perf script | c++filt | perf focus --from-stdin ... +perf script | c++filt | perf focus --from-stdin ... ``` This will pipe the output from `perf script` through `c++filt` and @@ -232,7 +232,7 @@ Perhaps we'd like to know how much time MIR borrowck spends in the trait checker. We can ask this using a more complex regex: ```bash -> perf focus '{do_mir_borrowck}..{^rustc::traits}' +$ perf focus '{do_mir_borrowck}..{^rustc::traits}' Matcher : {do_mir_borrowck},..{^rustc::traits} Matches : 12 Not Matches: 1311 @@ -260,7 +260,7 @@ usually also want to give `--tree-min-percent` or `--tree-max-depth`. The result looks like this: ```bash -> perf focus '{do_mir_borrowck}' --tree-callees --tree-min-percent 3 +$ perf focus '{do_mir_borrowck}' --tree-callees --tree-min-percent 3 Matcher : {do_mir_borrowck} Matches : 577 Not Matches: 746 @@ -311,7 +311,7 @@ could get our percentages relative to the borrowck itself like so: ```bash -> perf focus '{do_mir_borrowck}' --tree-callees --relative --tree-max-depth 1 --tree-min-percent 5 +$ perf focus '{do_mir_borrowck}' --tree-callees --relative --tree-max-depth 1 --tree-min-percent 5 Matcher : {do_mir_borrowck} Matches : 577 Not Matches: 746 diff --git a/src/tests/running.md b/src/tests/running.md index af10b8551..4a86d2cce 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -4,7 +4,7 @@ You can run the tests using `x.py`. The most basic command – which you will almost never want to use! – is as follows: ```bash -> ./x.py test +./x.py test ``` This will build the full stage 2 compiler and then run the whole test @@ -34,7 +34,7 @@ test" that can be used after modifying rustc to see if things are generally working correctly would be the following: ```bash -> ./x.py test --stage 1 src/test/{ui,compile-fail} +./x.py test --stage 1 src/test/{ui,compile-fail} ``` This will run the `ui` and `compile-fail` test suites, @@ -44,38 +44,38 @@ example, if you are hacking on debuginfo, you may be better off with the debuginfo test suite: ```bash -> ./x.py test --stage 1 src/test/debuginfo +./x.py test --stage 1 src/test/debuginfo ``` If you only need to test a specific subdirectory of tests for any given test suite, you can pass that directory to `x.py test`: ```bash -> ./x.py test --stage 1 src/test/ui/const-generics +./x.py test --stage 1 src/test/ui/const-generics ``` Likewise, you can test a single file by passing its path: ```bash -> ./x.py test --stage 1 src/test/ui/const-generics/const-test.rs +./x.py test --stage 1 src/test/ui/const-generics/const-test.rs ``` ### Run only the tidy script ```bash -> ./x.py test src/tools/tidy +./x.py test src/tools/tidy ``` ### Run tests on the standard library ```bash -> ./x.py test src/libstd +./x.py test src/libstd ``` ### Run tests on the standard library and run the tidy script ```bash -> ./x.py test src/libstd src/tools/tidy +./x.py test src/libstd src/tools/tidy ``` ### Run tests on the standard library using a stage 1 compiler @@ -100,7 +100,7 @@ you may pass the full file path to achieve this, or alternatively one may invoke `x.py` with the `--test-args` option: ```bash -> ./x.py test --stage 1 src/test/ui --test-args issue-1234 +./x.py test --stage 1 src/test/ui --test-args issue-1234 ``` Under the hood, the test runner invokes the standard rust test runner @@ -117,7 +117,7 @@ exists in the test file. For example, you can run all the tests in `src/test/ui` as `check-pass`: ```bash -> ./x.py test --stage 1 src/test/ui --pass check +./x.py test --stage 1 src/test/ui --pass check ``` By passing `--pass $mode`, you can reduce the testing time. For each @@ -131,7 +131,7 @@ You can further enable the `--incremental` flag to save additional time in subsequent rebuilds: ```bash -> ./x.py test --stage 1 src/test/ui --incremental --test-args issue-1234 +./x.py test --stage 1 src/test/ui --incremental --test-args issue-1234 ``` If you don't want to include the flag with every command, you can @@ -152,7 +152,7 @@ Sometimes it's easier and faster to just run the test by hand. Most tests are just `rs` files, so you can do something like ```bash -> rustc +stage1 src/test/ui/issue-1234.rs +rustc +stage1 src/test/ui/issue-1234.rs ``` This is much faster, but doesn't always work. For example, some tests From 0076be2fba27361725bae838a2826112969c5266 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 26 Nov 2019 17:09:44 -0600 Subject: [PATCH 0745/1812] Don't run mdbook test We don't want to test almost any of our code blocks... none of them are valid on their own... --- .travis.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 50b7d6b95..6ee759d4c 100644 --- a/.travis.yml +++ b/.travis.yml @@ -13,7 +13,6 @@ install: - bash -x ci/install.sh script: - mdbook build -- mdbook test notifications: email: on_success: never From efe3ab7ad1cb4b54ef76755c85ffcd2026d5d400 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 26 Nov 2019 17:06:43 -0600 Subject: [PATCH 0746/1812] Revert "website has disappeared" This reverts commit 0930e773f1123f9c118f81af3f00b09f1dafc17e. --- src/rustdoc.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/rustdoc.md b/src/rustdoc.md index 072bf31c1..318a8e2e1 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -219,6 +219,9 @@ tests to run before handing them off to the libtest test runner. One notable location in `test.rs` is the function `make_test`, which is where hand-written doctests get transformed into something that can be executed. +Some extra reading about `make_test` can be found +[here](https://quietmisdreavus.net/code/2018/02/23/how-the-doctests-get-made/). + ## Dotting i's and crossing t's So that's rustdoc's code in a nutshell, but there's more things in the repo From 4edb95271d1b20363c4c57bb50b59402e3b26a44 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 26 Nov 2019 17:24:19 -0600 Subject: [PATCH 0747/1812] Define FCP where first used --- src/walkthrough.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index 93fcd556a..9c4ba1533 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -120,13 +120,13 @@ itself to reflect the course of the discussion (e.g. new alternatives or prior work may be added or you may decide to change parts of the proposal itself). In the end, when the discussion seems to reach a consensus and die down a bit, -a rust team member may propose to move to FCP with one of three possible dispositions. -This means that they want the other members of the appropriate teams to review -and comment on the RFC. More discussion may ensue, which may result in more changes -or unresolved questions being added. At some point, when everyone is -satisfied, the RFC enters the "final comment period" (FCP), which is the last -chance for people to bring up objections. When the FCP is over, the disposition is -adopted. Here are the three possible dispositions: +a rust team member may propose to move to "final comment period" (FCP) with one +of three possible dispositions. This means that they want the other members of +the appropriate teams to review and comment on the RFC. More discussion may +ensue, which may result in more changes or unresolved questions being added. At +some point, when everyone is satisfied, the RFC enters the FCP, which is the +last chance for people to bring up objections. When the FCP is over, the +disposition is adopted. Here are the three possible dispositions: - _Merge_: accept the feature. Here is the proposal to merge for our [`?` macro feature][rfcmerge]. From 3984184a44244ef30d565886fc4b0d0f689b74bb Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 26 Nov 2019 20:59:34 -0600 Subject: [PATCH 0748/1812] Update src/walkthrough.md Co-Authored-By: Yuki Okushi --- src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index 9c4ba1533..5d54404ef 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -121,7 +121,7 @@ work may be added or you may decide to change parts of the proposal itself). In the end, when the discussion seems to reach a consensus and die down a bit, a rust team member may propose to move to "final comment period" (FCP) with one -of three possible dispositions. This means that they want the other members of +of three possible dispositions. This means that they want the other members of the appropriate teams to review and comment on the RFC. More discussion may ensue, which may result in more changes or unresolved questions being added. At some point, when everyone is satisfied, the RFC enters the FCP, which is the From 9e8af60434ce70be1bd47cc9d4c31e06e63ed0a8 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 27 Nov 2019 11:06:07 -0600 Subject: [PATCH 0749/1812] Add Karrq's salsa chapter (#529) * add Karrq's salsa chapter * add youtu.be short url --- book.toml | 2 +- src/SUMMARY.md | 1 + src/salsa.md | 214 +++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 216 insertions(+), 1 deletion(-) create mode 100644 src/salsa.md diff --git a/book.toml b/book.toml index 94b0e6d8c..bbba6d60c 100644 --- a/book.toml +++ b/book.toml @@ -15,6 +15,6 @@ level = 1 [output.linkcheck] follow-web-links = true -exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "dl\\.acm\\.org" ] +exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org" ] cache-timeout = 172800 warning-policy = "error" diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 2c29666a0..fe6584b55 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -38,6 +38,7 @@ - [Incremental compilation](./queries/incremental-compilation.md) - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) - [Debugging and Testing](./incrcomp-debugging.md) + - [Salsa](./salsa.md) - [Lexing and Parsing](./the-parser.md) - [`#[test]` Implementation](./test-implementation.md) - [Macro expansion](./macro-expansion.md) diff --git a/src/salsa.md b/src/salsa.md new file mode 100644 index 000000000..b34647ad1 --- /dev/null +++ b/src/salsa.md @@ -0,0 +1,214 @@ +# How Salsa works + +This chapter is based on the explanation given by Niko Matsakis in this +[video](https://www.youtube.com/watch?v=_muY4HjSqVw) about +[Salsa](https://github.com/salsa-rs/salsa). + +> Salsa is not used directly in rustc, but it is used extensively for +> rust-analyzer and may be integrated into the compiler in the future. + +## What is Salsa? + +Salsa is a library for incremental recomputation, this means reusing +computation that has already been done in the past to increase the efficiency +of future computations. + +The objectives of Salsa are: + * Provide that functionality in an automatic way, so reusing old computations + is done automatically by the library + * Doing so in a "sound", or "correct", way, therefore leading to the same + results as if it had been done from scratch + +Salsa's actual model is much richer, allowing many kinds of inputs and many +different outputs. +For example, integrating Salsa with an IDE could mean that the inputs could be +the manifest (`Cargo.toml`), entire source files (`foo.rs`), snippets and so +on; the outputs of such an integration could range from a binary executable, to +lints, types (for example, if a user selects a certain variable and wishes to +see its type), completions, etc. + +## How does it work? + +The first thing that Salsa has to do is identify the "base inputs" [^EN1]. + +Then Salsa has to also identify intermediate, "derived" values, which are +something that the library produces, but, for each derived value there's a +"pure" function that computes the derived value. + +For example, there might be a function `ast(x: Path) -> AST`. The produced +`AST` isn't a final value, it's an intermidiate value that the library would +use for the computation. + +This means that when you try to compute with the library, Salsa is going to +compute various derived values, and eventually read the input and produce the +result for the asked computation. + +In the course of computing, Salsa tracks which inputs were accessed and which +values are derived. This information is used to determine what's going to +happen when the inputs change: are the derived values still valid? + +This doesn't necessarily mean that each computation downstream from the input +is going to be checked, which could be costly. Salsa only needs to check each +downstream computation until it finds one that isn't changed. At that point, it +won't check other derived computations since they wouldn't need to change. + +It's is helpful to think about this as a graph with nodes. Each derived value +has a dependency on other values, which could themselves be either base or +derived. Base values don't have a dependency. + +```ignore +I <- A <- C ... + | +J <- B <--+ +``` + +When an input `I` changes, the derived value `A` could change. The derived +value `B` , which does not depend on `I`, `A`, or any value derived from `A` or +`I`, is not subject to change. Therefore, Salsa can reuse the computation done +for `B` in the past, without having to compute it again. + +The computation could also terminate early. Keeping the same graph as before, +say that input `I` has changed in some way (and input `J` hasn't) but, when +computing `A` again, it's found that `A` hasn't changed from the previous +computation. This leads to an "early termination", because there's no need to +check if `C` needs to change, since both `C` direct inputs, `A` and `B`, +haven't changed. + +## Key Salsa concepts + +### Query + +A query is some value that Salsa can access in the course of computation. Each +query can have a number of keys (from 0 to many), and all queries have a +result, akin to functions. 0-key queries are called "input" queries. + +### Database + +The database is basically the context for the entire computation, it's meant to +store Salsa's internal state, all intermediate values for each query, and +anything else that the computation might need. The database must know all the +queries that the library is going to do before it can be built, but they don't +need to be specified in the same place. + +After the database is formed, it can be accessed with queries that are very +similar to functions. Since each query's result is stored in the database, +when a query is invoked N times, it will return N **cloned** results, without +having to recompute the query (unless the input has changed in such a way that +it warrants recomputation). + +For each input query (0-key), a "set" method is generated, allowing the user to +change the output of such query, and trigger previous memoized values to be +potentially invalidated. + +### Query Groups + +A query group is a set of queries which have been defined together as a unit. +The database is formed by combining query groups. Query groups are akin to +"Salsa modules" [^EN2]. + +A set of queries in a query group are just a set of methods in a trait. + +To create a query group a trait annotated with a specific attribute +(`#[salsa::query_group(...)]`) has to be created. + +An argument must also be provided to said attribute as it will be used by Salsa +to create a struct to be used later when the database is created. + +Example input query group: + +```rust,ignore +/// This attribute will process this tree, produce this tree as output, and produce +/// a bunch of intermidiate stuff that Salsa also uses. One of these things is a +/// "StorageStruct", whose name we have specified in the attribute. +/// +/// This query group is a bunch of **input** queries, that do not rely on any +/// derived input. +#[salsa::query_group(InputsStorage)] +pub trait Inputs { + /// This attribute (`#[salsa::input]`) indicates that this query is a base + /// input, therefore `set_manifest` is going to be auto-generated + #[salsa::input] + fn manifest(&self) -> Manifest; + + #[salsa::input] + fn source_text(&self, name: String) -> String; +} +``` + +To create a **derived** query group, one must specify which other query groups +this one depends on by specifying them as supertraits, as seen in the following +example: + +```rust,ignore +/// This query group is going to contain queries that depend on derived values a +/// query group can access another query group's queries by specifying the +/// dependency as a super trait query groups can be stacked as much as needed using +/// that pattern. +#[salsa::query_group(ParserStorage)] +pub trait Parser: Inputs { + /// This query `ast` is not an input query, it's a derived query this means + /// that a definition is necessary. + fn ast(&self, name: String) -> String; +} +``` + +When creating a derived query the implementation of said query must be defined +outside the trait. The definition must take a database parameter as an `impl +Trait` (or `dyn Trait`), where `Trait` is the query group that the definition +belongs to, in addition to the other keys. + +```rust,ignore +///This is going to be the definition of the `ast` query in the `Parser` trait. +///So, when the query `ast` is invoked, and it needs to be recomputed, Salsa is going to call this function +///and it's is going to give it the database as `impl Parser`. +///The function doesn't need to be aware of all the queries of all the query groups +fn ast(db: &impl Parser, name: String) -> String { + //! Note, `impl Parser` is used here but `dyn Parser` works just as well + /* code */ + ///By passing an `impl Parser`, this is allowed + let source_text = db.input_file(name); + /* do the actual parsing */ + return ast; +} +``` + +Eventually, after all the query groups have been defined, the database can be +created by declaring a struct. + +To specify which query groups are going to be part of the database an attribute +(`#[salsa::database(...)]`) must be added. The argument of said attribute is a +list of identifiers, specifying the query groups **storages**. + +```rust,ignore +///This attribute specifies which query groups are going to be in the database +#[salsa::database(InputsStorage, ParserStorage)] +#[derive(Default)] //optional! +struct MyDatabase { + ///You also need this one field + runtime : salsa::Runtime, +} +///And this trait has to be implemented +impl salsa::Databse for MyDatabase { + fn salsa_runtime(&self) -> &salsa::Runtime { + &self.runtime + } +} +``` + +Example usage: + +```rust,ignore +fn main() { + let db = MyDatabase::default(); + db.set_manifest(...); + db.set_source_text(...); + loop { + db.ast(...); //will reuse results + db.set_source_text(...); + } +} +``` + +[^EN1]: "They are not something that you **inaubible** but something that you kinda get **inaudible** from the outside [3:23](https://youtu.be/_muY4HjSqVw?t=203). + +[^EN2]: What is a Salsa module? From 746f7e17992d0420d0fd034a5afcf31c94a83344 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 4 Dec 2019 01:37:34 +0200 Subject: [PATCH 0750/1812] fix links --- src/closure.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/closure.md b/src/closure.md index c47ad9bc8..deeed0722 100644 --- a/src/closure.md +++ b/src/closure.md @@ -160,10 +160,10 @@ The other option is to step through the code using lldb or gdb. 2. `r` // Run the program until it hits the breakpoint Let's start with [`upvar.rs`][upvar]. This file has something called -the [`euv::ExprUseVisitor`][euv] which walks the source of the closure and +the [`euv::ExprUseVisitor`] which walks the source of the closure and invokes a callbackfor each upvar that is borrowed, mutated, or moved. -[euv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/middle/expr_use_visitor/struct.ExprUseVisitor.html +[`euv::ExprUseVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/expr_use_visitor/struct.ExprUseVisitor.html ```rust fn main() { @@ -178,7 +178,7 @@ fn main() { In the above example, our visitor will be called twice, for the lines marked 1 and 2, once for a shared borrow and another one for a mutable borrow. It will also tell us what was borrowed. -The callbacks are defined by implementing the [`Delegate`][delegate] trait. The +The callbacks are defined by implementing the [`Delegate`] trait. The [`InferBorrowKind`][ibk] type implements `Delegate` and keeps a map that records for each upvar which mode of borrow was required. The modes of borrow can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be @@ -208,6 +208,6 @@ self.tables .extend(delegate.adjust_upvar_captures); ``` -[delegate]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/middle/expr_use_visitor/trait.Delegate.html +[`Delegate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/expr_use_visitor/trait.Delegate.html [ibk]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/upvar/struct.InferBorrowKind.html -[cmt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/middle/mem_categorization/index.html +[cmt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/mem_categorization/index.html From d0b93fd0150faf9cb35485eab20f65f9fdc4f75b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lauren=C8=9Biu=20Nicola?= Date: Tue, 3 Dec 2019 21:26:34 +0200 Subject: [PATCH 0751/1812] Remove reference to run-pass tests --- src/tests/intro.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index e78e33475..4572d23ca 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -26,9 +26,7 @@ that give more details. - [`ui`](./adding.html#ui) – tests that check the exact stdout/stderr from compilation and/or running the test -- `run-pass` – tests that are expected to compile and execute - successfully (no panics) - - `run-pass-valgrind` – tests that ought to run with valgrind +- `run-pass-valgrind` – tests that ought to run with valgrind - `run-fail` – tests that are expected to compile but then panic during execution - `compile-fail` – tests that are expected to fail compilation. From 7c56708aab7986ca390221e8e8902f7de7f9b076 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 6 Dec 2019 17:00:39 +0900 Subject: [PATCH 0752/1812] Fix links --- src/appendix/code-index.md | 2 +- src/diagnostics.md | 17 ++++------------- src/diagnostics/lintstore.md | 4 ++-- src/rustc-driver.md | 2 +- 4 files changed, 8 insertions(+), 17 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 0f423c6a4..1c8d1d707 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -20,7 +20,7 @@ Item | Kind | Short description | Chapter | `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html) `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) -`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html) +`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) `SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) diff --git a/src/diagnostics.md b/src/diagnostics.md index a9a9221ab..c6c8f4fba 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -32,7 +32,7 @@ There are lots of them; they emit different types of "errors", such as warnings, errors, fatal errors, suggestions, etc. [parsesses]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html -[session]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html +[session]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html In general, there are two class of such methods: ones that emit an error directly and ones that allow finer control over what to emit. For example, @@ -45,8 +45,8 @@ before emitting it by calling the [`emit`][emit] method. (Failing to either emit or [cancel][cancel] a `DiagnosticBuilder` will result in an ICE.) See the [docs][diagbuild] for more info on what you can do. -[spanerr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html#method.span_err -[strspanerr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html#method.struct_span_err +[spanerr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html#method.span_err +[strspanerr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html#method.struct_span_err [diagbuild]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html [emit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html#method.emit [cancel]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Diagnostic.html#method.cancel @@ -314,7 +314,7 @@ processed. [`Session`][sessbl] and [`ParseSess`][parsebl] both have `buffer_lint` methods that allow you to buffer a lint for later. The linting system automatically takes care of handling buffered lints later. -[sessbl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html#method.buffer_lint +[sessbl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html#method.buffer_lint [parsebl]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html#method.buffer_lint Thus, to define a lint that runs early in the compilation, one defines a lint @@ -331,15 +331,6 @@ To solve this, `libsyntax` defines its own buffered lint type, which `ParseSess::buffer_lint` uses. After macro expansion, these buffered lints are then dumped into the `Session::buffered_lints` used by the rest of the compiler. -Usage for buffered lints in `libsyntax` is pretty much the same as the rest of -the compiler with one exception because we cannot import the `LintId`s for -lints we want to emit. Instead, the [`BufferedEarlyLintId`] type is used. If you -are defining a new lint, you will want to add an entry to this enum. Then, add -an appropriate mapping to the body of [`Lint::from_parser_lint_id`][fplid]. - -[`BufferedEarlyLintId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/early_buffered_lints/enum.BufferedEarlyLintId.html -[fplid]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.Lint.html#method.from_parser_lint_id - ## JSON diagnostic output The compiler accepts an `--error-format json` flag to output diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index 5ce13f967..32e6ef8b8 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -100,6 +100,6 @@ auto-propagate into the other. [`rustc_lint::register_builtins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_builtins.html [`rustc_lint::register_internals`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_internals.html [`rustc_lint::new_lint_store`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.new_lint_store.html -[`declare_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/macro.declare_lint.html -[`declare_tool_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/macro.declare_tool_lint.html +[`declare_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/macro.declare_lint.html +[`declare_tool_lint!`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/macro.declare_tool_lint.html [`register_lints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Config.html#structfield.register_lints diff --git a/src/rustc-driver.md b/src/rustc-driver.md index f2ed1bab8..eb5390a92 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -52,7 +52,7 @@ thread-locals, although you should rarely need to touch it. [`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/ [`Compiler`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html -[`Session`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/session/struct.Session.html +[`Session`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html [`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html [`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html [stupid-stats]: https://github.com/nrc/stupid-stats From cd85fbd68beccaf70696705661a2b54b6fbacfc9 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 6 Dec 2019 11:06:38 -0600 Subject: [PATCH 0753/1812] move the last few things from the forge --- src/SUMMARY.md | 3 + src/bug-fix-procedure.md | 330 + src/diagnostics/diagnostic-codes.md | 75 + src/queries/example-0.counts.txt | 104 + src/queries/example-0.html | 313330 +++++++++++++++++++++++++ src/queries/example-0.png | Bin 0 -> 106577 bytes src/queries/profiling.md | 341 + 7 files changed, 314183 insertions(+) create mode 100644 src/bug-fix-procedure.md create mode 100644 src/diagnostics/diagnostic-codes.md create mode 100644 src/queries/example-0.counts.txt create mode 100644 src/queries/example-0.html create mode 100644 src/queries/example-0.png create mode 100644 src/queries/profiling.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index fe6584b55..7b334c36c 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -17,6 +17,7 @@ - [Adding new tests](./tests/adding.md) - [Using `compiletest` + commands to control test execution](./compiletest.md) - [Walkthrough: a typical contribution](./walkthrough.md) + - [Bug Fix Procedure](./bug-fix-procedure.md) - [Implementing new features](./implementing_new_features.md) - [Stability attributes](./stability.md) - [Stabilizing Features](./stabilization_guide.md) @@ -27,6 +28,7 @@ - [crates.io Dependencies](./crates-io.md) - [Emitting Errors and other Diagnostics](diagnostics.md) - [`LintStore`](./diagnostics/lintstore.md) + - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) - [ICE-breaker teams](ice-breaker/about.md) - [LLVM ICE-breakers](ice-breaker/llvm.md) - [Part 2: How rustc works](./part-2-intro.md) @@ -38,6 +40,7 @@ - [Incremental compilation](./queries/incremental-compilation.md) - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) - [Debugging and Testing](./incrcomp-debugging.md) + - [Profiling Queries](./queries/profiling.md) - [Salsa](./salsa.md) - [Lexing and Parsing](./the-parser.md) - [`#[test]` Implementation](./test-implementation.md) diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md new file mode 100644 index 000000000..0f6d6c973 --- /dev/null +++ b/src/bug-fix-procedure.md @@ -0,0 +1,330 @@ +# Rustc Bug Fix Procedure +This page defines the best practices procedure for making bug fixes or soundness +corrections in the compiler that can cause existing code to stop compiling. This +text is based on +[RFC 1589](https://github.com/rust-lang/rfcs/blob/master/text/1589-rustc-bug-fix-procedure.md). + +# Motivation + +[motivation]: #motivation + +From time to time, we encounter the need to make a bug fix, soundness +correction, or other change in the compiler which will cause existing code to +stop compiling. When this happens, it is important that we handle the change in +a way that gives users of Rust a smooth transition. What we want to avoid is +that existing programs suddenly stop compiling with opaque error messages: we +would prefer to have a gradual period of warnings, with clear guidance as to +what the problem is, how to fix it, and why the change was made. This RFC +describes the procedure that we have been developing for handling breaking +changes that aims to achieve that kind of smooth transition. + +One of the key points of this policy is that (a) warnings should be issued +initially rather than hard errors if at all possible and (b) every change that +causes existing code to stop compiling will have an associated tracking issue. +This issue provides a point to collect feedback on the results of that change. +Sometimes changes have unexpectedly large consequences or there may be a way to +avoid the change that was not considered. In those cases, we may decide to +change course and roll back the change, or find another solution (if warnings +are being used, this is particularly easy to do). + +### What qualifies as a bug fix? + +Note that this RFC does not try to define when a breaking change is permitted. +That is already covered under [RFC 1122][]. This document assumes that the +change being made is in accordance with those policies. Here is a summary of the +conditions from RFC 1122: + +- **Soundness changes:** Fixes to holes uncovered in the type system. +- **Compiler bugs:** Places where the compiler is not implementing the specified + semantics found in an RFC or lang-team decision. +- **Underspecified language semantics:** Clarifications to grey areas where the + compiler behaves inconsistently and no formal behavior had been previously + decided. + +Please see [the RFC][rfc 1122] for full details! + +# Detailed design + +[design]: #detailed-design + +The procedure for making a breaking change is as follows (each of these steps is +described in more detail below): + +0. Do a **crater run** to assess the impact of the change. +1. Make a **special tracking issue** dedicated to the change. +1. Do not report an error right away. Instead, **issue forwards-compatibility + lint warnings**. + - Sometimes this is not straightforward. See the text below for suggestions + on different techniques we have employed in the past. + - For cases where warnings are infeasible: + - Report errors, but make every effort to give a targeted error message + that directs users to the tracking issue + - Submit PRs to all known affected crates that fix the issue + - or, at minimum, alert the owners of those crates to the problem and + direct them to the tracking issue +1. Once the change has been in the wild for at least one cycle, we can + **stabilize the change**, converting those warnings into errors. + +Finally, for changes to libsyntax that will affect plugins, the general policy +is to batch these changes. That is discussed below in more detail. + +### Tracking issue + +Every breaking change should be accompanied by a **dedicated tracking issue** +for that change. The main text of this issue should describe the change being +made, with a focus on what users must do to fix their code. The issue should be +approachable and practical; it may make sense to direct users to an RFC or some +other issue for the full details. The issue also serves as a place where users +can comment with questions or other concerns. + +A template for these breaking-change tracking issues can be found below. An +example of how such an issue should look can be [found +here][breaking-change-issue]. + +The issue should be tagged with (at least) `B-unstable` and `T-compiler`. + +### Tracking issue template + +This is a template to use for tracking issues: + +``` +This is the **summary issue** for the `YOUR_LINT_NAME_HERE` +future-compatibility warning and other related errors. The goal of +this page is describe why this change was made and how you can fix +code that is affected by it. It also provides a place to ask questions +or register a complaint if you feel the change should not be made. For +more information on the policy around future-compatibility warnings, +see our [breaking change policy guidelines][guidelines]. + +[guidelines]: LINK_TO_THIS_RFC + +#### What is the warning for? + +*Describe the conditions that trigger the warning and how they can be +fixed. Also explain why the change was made.** + +#### When will this warning become a hard error? + +At the beginning of each 6-week release cycle, the Rust compiler team +will review the set of outstanding future compatibility warnings and +nominate some of them for **Final Comment Period**. Toward the end of +the cycle, we will review any comments and make a final determination +whether to convert the warning into a hard error or remove it +entirely. +``` + +### Issuing future compatibility warnings + +The best way to handle a breaking change is to begin by issuing +future-compatibility warnings. These are a special category of lint warning. +Adding a new future-compatibility warning can be done as follows. + +```rust +// 1. Define the lint in `src/librustc/lint/builtin.rs`: +declare_lint! { + pub YOUR_ERROR_HERE, + Warn, + "illegal use of foo bar baz" +} + +// 2. Add to the list of HardwiredLints in the same file: +impl LintPass for HardwiredLints { + fn get_lints(&self) -> LintArray { + lint_array!( + .., + YOUR_ERROR_HERE + ) + } +} + +// 3. Register the lint in `src/librustc_lint/lib.rs`: +store.register_future_incompatible(sess, vec![ + ..., + FutureIncompatibleInfo { + id: LintId::of(YOUR_ERROR_HERE), + reference: "issue #1234", // your tracking issue here! + }, +]); + +// 4. Report the lint: +tcx.lint_node( + lint::builtin::YOUR_ERROR_HERE, + path_id, + binding.span, + format!("some helper message here")); +``` + +#### Helpful techniques + +It can often be challenging to filter out new warnings from older, pre-existing +errors. One technique that has been used in the past is to run the older code +unchanged and collect the errors it would have reported. You can then issue +warnings for any errors you would give which do not appear in that original set. +Another option is to abort compilation after the original code completes if +errors are reported: then you know that your new code will only execute when +there were no errors before. + +#### Crater and crates.io + +We should always do a crater run to assess impact. It is polite and considerate +to at least notify the authors of affected crates the breaking change. If we can +submit PRs to fix the problem, so much the better. + +#### Is it ever acceptable to go directly to issuing errors? + +Changes that are believed to have negligible impact can go directly to issuing +an error. One rule of thumb would be to check against `crates.io`: if fewer than +10 **total** affected projects are found (**not** root errors), we can move +straight to an error. In such cases, we should still make the "breaking change" +page as before, and we should ensure that the error directs users to this page. +In other words, everything should be the same except that users are getting an +error, and not a warning. Moreover, we should submit PRs to the affected +projects (ideally before the PR implementing the change lands in rustc). + +If the impact is not believed to be negligible (e.g., more than 10 crates are +affected), then warnings are required (unless the compiler team agrees to grant +a special exemption in some particular case). If implementing warnings is not +feasible, then we should make an aggressive strategy of migrating crates before +we land the change so as to lower the number of affected crates. Here are some +techniques for approaching this scenario: + +1. Issue warnings for subparts of the problem, and reserve the new errors for + the smallest set of cases you can. +2. Try to give a very precise error message that suggests how to fix the problem + and directs users to the tracking issue. +3. It may also make sense to layer the fix: + - First, add warnings where possible and let those land before proceeding to + issue errors. + - Work with authors of affected crates to ensure that corrected versions are + available _before_ the fix lands, so that downstream users can use them. + +### Stabilization + +After a change is made, we will **stabilize** the change using the same process +that we use for unstable features: + +- After a new release is made, we will go through the outstanding tracking + issues corresponding to breaking changes and nominate some of them for **final + comment period** (FCP). +- The FCP for such issues lasts for one cycle. In the final week or two of the + cycle, we will review comments and make a final determination: + + - Convert to error: the change should be made into a hard error. + - Revert: we should remove the warning and continue to allow the older code to + compile. + - Defer: can't decide yet, wait longer, or try other strategies. + +Ideally, breaking changes should have landed on the **stable branch** of the +compiler before they are finalized. + + + +### Removing a lint + +Once we have decided to make a "future warning" into a hard error, we need a PR +that removes the custom lint. As an example, here are the steps required to +remove the `overlapping_inherent_impls` compatibility lint. First, convert the +name of the lint to uppercase (`OVERLAPPING_INHERENT_IMPLS`) ripgrep through the +source for that string. We will basically by converting each place where this +lint name is mentioned (in the compiler, we use the upper-case name, and a macro +automatically generates the lower-case string; so searching for +`overlapping_inherent_impls` would not find much). + +#### Remove the lint. + +The first reference you will likely find is the lint definition [in +`librustc/lint/builtin.rs` that resembles this][defsource]: + +[defsource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L171-L175 + +```rust +declare_lint! { + pub OVERLAPPING_INHERENT_IMPLS, + Deny, // this may also say Warning + "two overlapping inherent impls define an item with the same name were erroneously allowed" +} +``` + +This `declare_lint!` macro creates the relevant data structures. Remove it. You +will also find that there is a mention of `OVERLAPPING_INHERENT_IMPLS` later in +the file as [part of a `lint_array!`][lintarraysource]; remove it too, + +[lintarraysource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L252-L290 + +Next, you see see [a reference to `OVERLAPPING_INHERENT_IMPLS` in +`librustc_lint/lib.rs`][futuresource]. This defining the lint as a "future +compatibility lint": + +```rust +FutureIncompatibleInfo { + id: LintId::of(OVERLAPPING_INHERENT_IMPLS), + reference: "issue #36889 ", +}, +``` + +Remove this too. + +#### Add the lint to the list of removed lists. + +In `src/librustc_lint/lib.rs` there is a list of "renamed and removed lints". +You can add this lint to the list: + +```rust +store.register_removed("overlapping_inherent_impls", "converted into hard error, see #36889"); +``` + +where `#36889` is the tracking issue for your lint. + +#### Update the places that issue the lint + +Finally, the last class of references you will see are the places that actually +**trigger** the lint itself (i.e., what causes the warnings to appear). These +you do not want to delete. Instead, you want to convert them into errors. In +this case, the [`add_lint` call][addlintsource] looks like this: + +```rust +self.tcx.sess.add_lint(lint::builtin::OVERLAPPING_INHERENT_IMPLS, + node_id, + self.tcx.span_of_impl(item1).unwrap(), + msg); +``` + +We want to convert this into an error. In some cases, there may be an existing +error for this scenario. In others, we will need to allocate a fresh diagnostic +code. +[Instructions for allocating a fresh diagnostic code can be found here.](rustc-diagnostic-code.html) +You may want to mention in the extended description that the compiler behavior +changed on this point, and include a reference to the tracking issue for the +change. + +Let's say that we've adopted `E0592` as our code. Then we can change the +`add_lint()` call above to something like: + +```rust +struct_span_err!(self.tcx.sess, self.tcx.span_of_impl(item1).unwrap(), msg) + .emit(); +``` + +#### Update tests + +Finally, run the test suite. These should be some tests that used to reference +the `overlapping_inherent_impls` lint, those will need to be updated. In +general, if the test used to have `#[deny(overlapping_inherent_impls)]`, that +can just be removed. + +``` +./x.py test +``` + +#### All done! + +Open a PR. =) + +[addlintsource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc_typeck/coherence/inherent.rs#L300-L303 +[futuresource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc_lint/lib.rs#L202-L205 + + + +[rfc 1122]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md +[breaking-change-issue]: https://gist.github.com/nikomatsakis/631ec8b4af9a18b5d062d9d9b7d3d967 + diff --git a/src/diagnostics/diagnostic-codes.md b/src/diagnostics/diagnostic-codes.md new file mode 100644 index 000000000..22d9b12c3 --- /dev/null +++ b/src/diagnostics/diagnostic-codes.md @@ -0,0 +1,75 @@ +# Diagnostic Codes +We generally try assign each error message a unique code like `E0123`. These +codes are defined in the compiler in the `diagnostics.rs` files found in each +crate, which basically consist of macros. The codes come in two varieties: those +that have an extended write-up, and those that do not. Whenever possible, if you +are making a new code, you should write an extended write-up. + +### Allocating a fresh code + +If you want to create a new error, you first need to find the next available +code. This is a bit tricky since the codes are defined in various crates. To do +it, run this obscure command: + +``` +./x.py test --stage 0 src/tools/tidy +``` + +This will invoke the tidy script, which generally checks that your code obeys +our coding conventions. One of those jobs is to check that diagnostic codes are +indeed unique. Once it is finished with that, tidy will print out the lowest +unused code: + +``` +... +tidy check (x86_64-apple-darwin) +* 470 error codes +* highest error code: E0591 +... +``` + +Here we see the highest error code in use is `E0591`, so we _probably_ want +`E0592`. To be sure, run `rg E0592` and check, you should see no references. + +Next, open `src/{crate}/diagnostics.rs` within the crate where you wish to issue +the error (e.g., `src/librustc_typeck/diagnostics.rs`). Ideally, you will add +the code (in its proper numerical order) into the `register_long_diagnostics!` +macro, sort of like this: + +```rust +register_long_diagnostics! { + ... + E0592: r##" +Your extended error text goes here! +"##, +} +``` + +But you can also add it without an extended description: + +```rust +register_diagnostics! { + ... + E0592, // put a description here +} +``` + +To actually issue the error, you can use the `struct_span_err!` macro: + +```rust +struct_span_err!(self.tcx.sess, // some path to the session here + span, // whatever span in the source you want + E0592, // your new error code + &format!("text of the error")) + .emit() // actually issue the error +``` + +If you want to add notes or other snippets, you can invoke methods before you +call `.emit()`: + +```rust +struct_span_err!(...) + .span_label(another_span, "something to label in the source") + .span_note(another_span, "some separate note, probably avoid these") + .emit_() +``` diff --git a/src/queries/example-0.counts.txt b/src/queries/example-0.counts.txt new file mode 100644 index 000000000..e5b9c3f3d --- /dev/null +++ b/src/queries/example-0.counts.txt @@ -0,0 +1,104 @@ +translation,1,0.891 +symbol_name,2658,0.733 +def_symbol_name,2556,0.268 +item_attrs,5566,0.162 +type_of,6922,0.117 +generics_of,8020,0.084 +serialize dep graph,1,0.079 +relevant_trait_impls_for,50,0.063 +def_span,24875,0.061 +expansion,1,0.059 +const checking,1,0.055 +adt_def,1141,0.048 +trait_impls_of,32,0.045 +is_copy_raw,47,0.045 +is_foreign_item,2638,0.042 +fn_sig,2172,0.033 +adt_dtorck_constraint,2,0.023 +impl_trait_ref,2434,0.023 +typeck_tables_of,29,0.022 +item-bodies checking,1,0.017 +typeck_item_bodies,1,0.017 +is_default_impl,2320,0.017 +borrow checking,1,0.014 +borrowck,4,0.014 +mir_validated,4,0.013 +adt_destructor,10,0.012 +layout_raw,258,0.010 +load_dep_graph,1,0.007 +item-types checking,1,0.005 +mir_const,2,0.005 +name resolution,1,0.004 +is_object_safe,35,0.003 +is_sized_raw,89,0.003 +parsing,1,0.003 +is_freeze_raw,11,0.001 +privacy checking,1,0.001 +privacy_access_levels,5,0.001 +resolving dependency formats,1,0.001 +adt_sized_constraint,9,0.001 +wf checking,1,0.001 +liveness checking,1,0.001 +compute_incremental_hashes_map,1,0.001 +match checking,1,0.001 +type collecting,1,0.001 +param_env,31,0.000 +effect checking,1,0.000 +trait_def,140,0.000 +lowering ast -> hir,1,0.000 +predicates_of,70,0.000 +extern_crate,319,0.000 +lifetime resolution,1,0.000 +is_const_fn,6,0.000 +intrinsic checking,1,0.000 +translation item collection,1,0.000 +impl_polarity,15,0.000 +creating allocators,1,0.000 +language item collection,1,0.000 +crate injection,1,0.000 +early lint checks,1,0.000 +indexing hir,1,0.000 +maybe creating a macro crate,1,0.000 +coherence checking,1,0.000 +optimized_mir,6,0.000 +is_panic_runtime,33,0.000 +associated_item_def_ids,7,0.000 +needs_drop_raw,10,0.000 +lint checking,1,0.000 +complete gated feature checking,1,0.000 +stability index,1,0.000 +region_maps,11,0.000 +super_predicates_of,8,0.000 +coherent_trait,2,0.000 +AST validation,1,0.000 +loop checking,1,0.000 +static item recursion checking,1,0.000 +variances_of,11,0.000 +associated_item,5,0.000 +plugin loading,1,0.000 +looking for plugin registrar,1,0.000 +stability checking,1,0.000 +describe_def,15,0.000 +variance testing,1,0.000 +codegen unit partitioning,1,0.000 +looking for entry point,1,0.000 +checking for inline asm in case the target doesn't support it,1,0.000 +inherent_impls,1,0.000 +crate_inherent_impls,1,0.000 +trait_of_item,7,0.000 +crate_inherent_impls_overlap_check,1,0.000 +attribute checking,1,0.000 +internalize symbols,1,0.000 +impl wf inference,1,0.000 +death checking,1,0.000 +reachability checking,1,0.000 +reachable_set,1,0.000 +is_exported_symbol,3,0.000 +is_mir_available,2,0.000 +unused lib feature checking,1,0.000 +maybe building test harness,1,0.000 +recursion limit,1,0.000 +write allocator module,1,0.000 +assert dep graph,1,0.000 +plugin registration,1,0.000 +write metadata,1,0.000 diff --git a/src/queries/example-0.html b/src/queries/example-0.html new file mode 100644 index 000000000..b196aaa83 --- /dev/null +++ b/src/queries/example-0.html @@ -0,0 +1,313330 @@ + + + + + + +
+
parsing
+
0.003
+
0.2%
+
+
+
recursion limit
+
0.000
+
< 0.1%
+
+
+
crate injection
+
0.000
+
< 0.1%
+
+
+
plugin loading
+
0.000
+
< 0.1%
+
+
+
plugin registration
+
0.000
+
< 0.1%
+
+
+
expansion
+
0.059
+
5.2%
+
+
+
maybe building test harness
+
0.000
+
< 0.1%
+
+
+
maybe creating a macro crate
+
0.000
+
< 0.1%
+
+
+
creating allocators
+
0.000
+
< 0.1%
+
+
+
checking for inline asm in case the target doesn't support it
+
0.000
+
< 0.1%
+
+
+
early lint checks
+
0.000
+
< 0.1%
+
+
+
AST validation
+
0.000
+
< 0.1%
+
+
+
name resolution
+
0.004
+
0.3%
+
+
+
complete gated feature checking
+
0.000
+
< 0.1%
+
+
+
lowering ast -> hir
+
0.000
+
< 0.1%
+
+
+
indexing hir
+
0.000
+
< 0.1%
+
+
+
attribute checking
+
0.000
+
< 0.1%
+
+
+
language item collection
+
0.000
+
< 0.1%
+
+
+
lifetime resolution
+
0.000
+
< 0.1%
+
+
+
looking for entry point
+
0.000
+
< 0.1%
+
+
+
looking for plugin registrar
+
0.000
+
< 0.1%
+
+
+
loop checking
+
0.000
+
< 0.1%
+
+
+
static item recursion checking
+
0.000
+
< 0.1%
+
+
+
compute_incremental_hashes_map
+
0.001
+
< 0.1%
+
+
+
load_dep_graph
+
0.007
+
0.6%
+
+
+
stability index
+
0.000
+
< 0.1%
+
+
+
stability checking
+
0.000
+
< 0.1%
+
+
+
type collecting
+
0.001
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
impl wf inference
+
0.000
+
< 0.1%
+
+
+
coherence checking
+
0.000
+
< 0.1%
+
+
crate_inherent_impls
+
0.000
+
< 0.1%
+
+
+
crate_inherent_impls_overlap_check
+
0.000
+
< 0.1%
+
+
+
+
variance testing
+
0.000
+
< 0.1%
+
+
+
wf checking
+
0.001
+
< 0.1%
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item-types checking
+
0.005
+
0.4%
+
+
typeck_tables_of
+
0.005
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
relevant_trait_impls_for
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
super_predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
associated_item_def_ids
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
super_predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
super_predicates_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
associated_item_def_ids
+
0.000
+
< 0.1%
+
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
+
+
+
item-bodies checking
+
0.017
+
1.5%
+
+
typeck_item_bodies
+
0.017
+
1.5%
+
+
typeck_tables_of
+
0.017
+
1.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
inherent_impls
+
0.000
+
< 0.1%
+
+
+
associated_item_def_ids
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
associated_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
associated_item
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
adt_sized_constraint
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
+
adt_dtorck_constraint
+
0.012
+
1.1%
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
adt_dtorck_constraint
+
0.011
+
1.0%
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
adt_destructor
+
0.011
+
1.0%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
coherent_trait
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
relevant_trait_impls_for
+
0.011
+
1.0%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.010
+
0.9%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
adt_destructor
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
coherent_trait
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
const checking
+
0.055
+
4.8%
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.030
+
2.6%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
relevant_trait_impls_for
+
0.030
+
2.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.028
+
2.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.008
+
0.7%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.001
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
is_copy_raw
+
0.002
+
0.2%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.003
+
0.3%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
super_predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
associated_item_def_ids
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
super_predicates_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
associated_item_def_ids
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
+
is_const_fn
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
adt_destructor
+
0.000
+
< 0.1%
+
+
+
associated_item
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
+
is_const_fn
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
+
is_copy_raw
+
0.001
+
0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
+
privacy checking
+
0.001
+
0.1%
+
+
privacy_access_levels
+
0.001
+
0.1%
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
associated_item
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
associated_item
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
+
describe_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
intrinsic checking
+
0.000
+
< 0.1%
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
+
effect checking
+
0.000
+
< 0.1%
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
+
match checking
+
0.001
+
< 0.1%
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
+
liveness checking
+
0.001
+
< 0.1%
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
+
borrow checking
+
0.014
+
1.2%
+
+
borrowck
+
0.006
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
+
mir_validated
+
0.005
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
mir_const
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
adt_sized_constraint
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
variances_of
+
0.000
+
< 0.1%
+
+
+
+
is_const_fn
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
is_const_fn
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
is_const_fn
+
0.000
+
< 0.1%
+
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
+
borrowck
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
+
mir_validated
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
mir_const
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
region_maps
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
relevant_trait_impls_for
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.003
+
0.2%
+
+
def_span
+
0.003
+
0.2%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
is_object_safe
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
super_predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
associated_item_def_ids
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
super_predicates_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
associated_item_def_ids
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
+
+
reachability checking
+
0.000
+
< 0.1%
+
+
reachable_set
+
0.000
+
< 0.1%
+
+
privacy_access_levels
+
0.000
+
< 0.1%
+
+
+
+
+
death checking
+
0.000
+
< 0.1%
+
+
privacy_access_levels
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
+
unused lib feature checking
+
0.000
+
< 0.1%
+
+
privacy_access_levels
+
0.000
+
< 0.1%
+
+
+
+
lint checking
+
0.000
+
< 0.1%
+
+
privacy_access_levels
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
typeck_tables_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
+
resolving dependency formats
+
0.001
+
< 0.1%
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
+
translation
+
0.891
+
78.1%
+
+
write metadata
+
0.000
+
< 0.1%
+
+
+
translation item collection
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
optimized_mir
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
borrowck
+
0.000
+
< 0.1%
+
+
+
mir_validated
+
0.000
+
< 0.1%
+
+
+
param_env
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
is_copy_raw
+
0.000
+
< 0.1%
+
+
+
adt_destructor
+
0.000
+
< 0.1%
+
+
+
adt_destructor
+
0.000
+
< 0.1%
+
+
+
adt_destructor
+
0.000
+
< 0.1%
+
+
+
adt_destructor
+
0.000
+
< 0.1%
+
+
+
adt_destructor
+
0.000
+
< 0.1%
+
+
+
adt_destructor
+
0.000
+
< 0.1%
+
+
+
adt_destructor
+
0.000
+
< 0.1%
+
+
+
is_const_fn
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
trait_of_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
is_exported_symbol
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_mir_available
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_of_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
is_exported_symbol
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_exported_symbol
+
0.000
+
< 0.1%
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
+
is_mir_available
+
0.000
+
< 0.1%
+
+
+
optimized_mir
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
trait_of_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
needs_drop_raw
+
0.000
+
< 0.1%
+
+
+
optimized_mir
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
borrowck
+
0.000
+
< 0.1%
+
+
+
mir_validated
+
0.000
+
< 0.1%
+
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
codegen unit partitioning
+
0.000
+
< 0.1%
+
+
trait_of_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.001
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.001
+
< 0.1%
+
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.001
+
< 0.1%
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
adt_sized_constraint
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
adt_sized_constraint
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
adt_sized_constraint
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
adt_sized_constraint
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
adt_sized_constraint
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.001
+
< 0.1%
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
relevant_trait_impls_for
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
trait_impls_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_object_safe
+
0.000
+
< 0.1%
+
+
+
impl_polarity
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.002
+
0.2%
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.002
+
0.2%
+
+
param_env
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
super_predicates_of
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
adt_sized_constraint
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.002
+
0.2%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
optimized_mir
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
adt_sized_constraint
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
predicates_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
optimized_mir
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
trait_of_item
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
trait_of_item
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
extern_crate
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
trait_of_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
optimized_mir
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_freeze_raw
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
layout_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
is_sized_raw
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.001
+
< 0.1%
+
+
def_span
+
0.001
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.017
+
1.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.001
+
< 0.1%
+
+
def_span
+
0.001
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.025
+
2.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.012
+
1.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.012
+
1.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.010
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.010
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.020
+
1.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.006
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.006
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.005
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.005
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.005
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.005
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.005
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.005
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.005
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.005
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.005
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.012
+
1.0%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.012
+
1.0%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.005
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.010
+
0.9%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.006
+
0.5%
+
+
def_span
+
0.006
+
0.5%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.011
+
0.9%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.011
+
0.9%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.005
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.005
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.006
+
0.5%
+
+
def_span
+
0.006
+
0.5%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.006
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.005
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.006
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.006
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.003
+
0.2%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.002
+
0.2%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.010
+
0.9%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.010
+
0.9%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.001
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.005
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.003
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.001
+
< 0.1%
+
+
def_span
+
0.001
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.009
+
0.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.021
+
1.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.021
+
1.8%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.002
+
0.1%
+
+
def_span
+
0.002
+
0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.003
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.004
+
0.3%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.005
+
0.5%
+
+
def_span
+
0.005
+
0.5%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.007
+
0.6%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.008
+
0.7%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
trait_def
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.008
+
0.7%
+
+
def_span
+
0.008
+
0.7%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.005
+
0.4%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.024
+
2.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.024
+
2.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.006
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
is_panic_runtime
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.001
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.006
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.006
+
0.5%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.002
+
0.2%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.002
+
0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
adt_def
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
generics_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
is_foreign_item
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
fn_sig
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
def_symbol_name
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
is_default_impl
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
type_of
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
impl_trait_ref
+
0.000
+
< 0.1%
+
+
def_span
+
0.000
+
< 0.1%
+
+
+
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
internalize symbols
+
0.000
+
< 0.1%
+
+
generics_of
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
symbol_name
+
0.000
+
< 0.1%
+
+
+
item_attrs
+
0.000
+
< 0.1%
+
+
+
+
write allocator module
+
0.000
+
< 0.1%
+
+
+
+
assert dep graph
+
0.000
+
< 0.1%
+
+
+
serialize dep graph
+
0.079
+
6.9%
+
+ + diff --git a/src/queries/example-0.png b/src/queries/example-0.png new file mode 100644 index 0000000000000000000000000000000000000000..14b46c44f7d05cec9458aa56205f4b2982c72ee1 GIT binary patch literal 106577 zcmZU319WD~(snqpCUz#8*c02fZ98wQiEZ1QWMbR4ZQD-%oOADY@0|O;YrSjr?(VAY zYSezJo*g19EdmFP1q}oQ1ScjcC=Ub#GWq#mh5YhaGoBE100e|VZYCfgD<&X7AZu@9 zY-VW$1f&{};0mFLA~9?1_(0qp?I3JFu10*2?pF-U<|pt~QIMCoI2cTh7X^_IC7c*3 znjlm(Hk&LM1SB*R7!i2s%k0B@gS*qjJlovc*qKH{yN2VhQX2%Ibjke6N`hqgpPSK; z)#WiXSv6sl`0sF?pj5hG@<4>Hfk8*A8fl=luT38l)l9J2V=s&)QW_sGHy;)`57+Py zU_jNvRY59^CUl_}KtJ_vV2MP4ex3>MflMLkrMUq2NgBoz0I`me-mmprrY#y^OIRN* zt{ms6VgrHv2obyo|7je@q7z?4YaaAvFW3O`>KcJhX-BSgWF~4C97qJFln4_Cr#a+6 zj_UY|mZSZnr*J?gjX3r~r}b<^`P<=3P!M>G{yR_5&WDz-AK}Ms6=?aam!ZLmRMwOo zB?9b^mEKu0YuKyGT7G)aQ2Zx%t0S9jxeif-ppEC7%q_RWWMDKP-A$os76E$nP&GnO zT!5E>>sQxb)TIa-&mzf-AN_c{vMU?+TgA}?5;q%8@~^E@@0&2|TVI^K0Uob#QnKN~ zSRUW!C)Ul6q!7U1mT#q45=aZZFmj_)~~QbYS=#F zcOaU{Oe^b{QV}d8dENJ~SRt8Q*qYq%;Iy{h!PT=7Xs>^R?`ZmF3OHJRw@$-BGknv) zZ`#B)G;HA-AB?ypYvHkiAe;nR!GqYf0veiqcGi*5Lz=%|S*4?+gK*=;zw{BUb^9rc z2=wZ{Z*efCvmyfv3>ED|dnv54RKF_&Q&j%_+uoSbs= ze5NFzA0K|Bux;*n>sIzqPdhz4_mvlwZ;K6!-%i2q!EM15G?cw8&TeD~K7!crD}j)U zfAnmuyS}b)gwqYHL*<1{2|nem(oL-BFvyj|sJguCxc7J^Lnt7J3e>#AYg*^&&zV z{#(N72axrWn{aGiy;0f!)h&n*25)_XBNKnpu*N0&eXt@(88H7?7L9?OR!g9 zZ9yRZfJ%bbV3gd@!*9yLl-qvMF|5RJLqef36#2jz2PT7H3{hpewiv>&_`=W;QU>9m z{m3==$U$sAY*FL`v%1Ul6LdCoFv&Wqgo!YeK1u_rx*1jNi>8(g%;*|{ZDD7;3u8=9 zP(eLan}W6!hs}U4@J;w_=}l<6xkfZi9_z0S!2>%>S6^MET2V9oqdLFuOl(zbrCotO zn!O@`p!y^c$j}ite&vUR^4IKE;z!o|NhhFMke!E^D_c~Vdzl-YGnh?QV48hckX)!* zkY9w7Gn-#q1e?t%o+6?qw8ZxmdX0^WItNejg94kvyVRwWvlLq~s(4+tT$WKbOyNYX zMNULME4Q70jsMN}89PQ4h148bD+H-mp%+>o+b;dlFEB zwE8!7+~u~~s@kU71~YfFgCnv-|D)SOQGgxb32+A>0)*X$-`d|Q-*(-8KdhMMDa2`>o84WE%@B}F1dE(9tB6rM^o_OT6vJA^na+2ig~Y#r~b z@9u9gZ^Q3!53KcbP4sl-RsB$ds|lrv`(XV{r8d<=YfWNoB%Bx>Y{^s}@{I%&F5 zIsyle-Inc@bBRM=3wv{76U{mEVn&VoveXdul9fx;U?!+L-o@S`cJ0GE_p)ccXTw_6 zx%9cp+JdNZzW#J>P>6`nfNxRef!YLu_OkYpw!?brx=E{v2b1UcjTliAbW z^VrMDQ`W=BS6v)glu8^^R2LFkqCxUv_GH9UJWc#=#IG3Bc*DqU1hqVpgj8&n`W?^j z>2ENGjP`1*DDB@{X?&qP$BrUVA~?~WNX=Cgy=J3K2M$*t4iWru4kMAG#3E8ceuTGq zAUaIm=$?Fg7Z5>cV=Hrbl*d6iKw5AU+!URTIdaK+yv~ak0gd98ik4!HyX2Z8ulg3k zLC$SJTfYF00h56|a4Jll#$kkQ7cchXR9skhm$H zE54qklFPErY??tjZEZAh_>K-62)Ti|O7iNO3k>TFzj|L0Rg}aIcB{3zf zQsWZo4q$7+brB^#ABq-F)%q$_K6I7MWI8rc&S4!HyQ1sxmpjpghq z+lS2CHp+<5H~)&Rb*>GS|=K&P$Gzj>=CIPAm>LmNuBOe_U>+ zyw?Qzk^0F5QUyH+;Ra?!HAYBsKDcqe5FYj=O%+egC0$iiR!sLF_S+9M^@r(%wf)YN z&20P-{*ZdmXlbDR&h?!~GC-zW>U$ee`$)!CMoDr)mQ^}q`iXnT%iC>GCBm@-ufPakaG+cmpm5Ja4)8Ij^Sc&;N#kMQ zpG3rPouiPPtmbTuoSUUYJI^U0zQVN;y$sDKE89Iq%*0 zyPSe!Qj2owy;O#Z8zbPl%uaMjaA~j~5IV48uy-&u>lNbr zFyH;XBQYW^Ln)%h*%8r^QBLe9ccb_95?J?$%&*u*#=fS1ZHps}#FZH5)=stOs3R%o z@OQ2{z;@+a`f+XM2WlOhBf{|tmiqacMXP&9b4hMf ze!(T5w1xUg&izmLmZ0Gb%M8jWQoIKzE|2N?w@otx8Als!9hZ)EAiK?_npeK8Zv}d% zmxH2DH^u17d5u%jOzrX7W8p@T7U44O+-y1YS6fn38Y^Ok)o#Oj=0@x<8M`g}m@6qI zO9l=M4hk0|JpQAUqqJUS@4HVa?>B4UCjrhn@Sa9*&zBng579!?u?Scq3OpS11uV?< z`#M0)zz_u2gH-#Z%y5R^KzGdt;foQw4nFg{!|T(_<`b<=hslK@nfa_`Z|-c` z%5TMltUSa-Oy9y=HzLY#$FbY7=uup`DA<;Fe)5G|mTmH#3!Da}>>NgJMpE^4a4jd; zGSYu1e_qTqoY{FM-!I9p%{xkx;pAlVI#%f4KH3}YW8A1ltLE7sJ@8_G*}++Jt$U63 zt?tf*i4$@_FQRRu@sgX?c|NpPP}@oPeI2FpMERge+4!EDdK9=fh5~p{Z=%%NQA*Qc znf%#SwAgs@UR7AV-=A0rp`szvfNLFf9_*bwrS@37dlm3oL58s9EK~eW*G<^n=C0rY z0(Oy;5rYY%8uK0_#3S=|`|)rqiM!&qpS6E~;6w*M%hrqNF7fhy&2U9=>-ODwnQ@lU zuZF}yWc|haGWFpFVUd3k{d%F;hJGUt{Vgdx(Jaa4gYNOlu+MRCXQKVb@!eGU zQxecwH0CYNy|At57h#Z@u!z2)&Hc+HC@&NS6v}ulMWNX#K@BWdb*yEQX7pQXSk!Pe z$)FTZHA}T0OTCLJOAD;VY!Hp9jlW#PU2dN2pK6>9A&FsxpmrIr{m2IprEg3I8Em^Q4;`ZZK zaNycAJL);Po~gHUpm2St+^=q6cgRd+Y_7{tTteQi9toZOIQHx_>8L2ZNY$zF_W0>U z0BH%uj#Y;43v~p^g;t1sZ{SU`1kP1MNmxeMF0wCl7LFAa$6t6`qzVCyCqolMF`Z7mJi*&0`oWVXUf$zSQtkF7-&x#>wT``)1FbZ{9`gL>mL& zo2|Jq&$Ta*PS)0(>%Cu7UN?twWQd$5PDGw`_QQu-3tf@961cH%rmjz>L&x?%qglTd zDpn()>PgO-D`NEnpusYsn^AY5N_h}nDX>m$xXyuJK$eQ&*_{U769|w}oKU9YLm)0b z7_x$lQVyG;#$yn?6sdCBpi;U(t)Lc&pu}Iy@}Bfq0bj=;II_hse4q5R7Gby}ja@-6 zWdwn$c=coK4Z#FDiw%6~Ns`f3zm#F7#?);Qq%+gtErbqiOI;ORO+dZ+6Yz6^XLg6= zrf+{Q0N*1SHlmOywKs>YgK)%_3r-e)6*Q2U2{vX=0sOS)Swm@q@ucASx$*g@@WMF! z*u7SUI@fX@drh;%b0<*HxdWJiFH`_|9cCO`M?h{tfl{zzy;R;=E!Py^)KuS5<&991 z(*h<-DOa^S?gOqpEy*d$m`Wv?WmBR-{UfN5|N%3Hl!%i;&djo%cL&w@#pR_6t zgnL|gu5MJG^ymyjFUunrr&2@p0jLXwQOpX)EaQkh%iXIC6-v5}$_stTtG?+eN_kZD ziXmmG)mDIs4YiV|(oUvvi1Ipok4WFzY+LS|gkK6#F7309mW${8StrLsQ$iGMR)r_{ zhEdXNB8&30*L*qr?==nDC)E0!>N;;;jSUw|Pm)!0)orCH)+O z!DD?Szu}W1Q3T@g+UUVjfu!{qK60*p@fL1GWZXrRkC4=3rK?W{NJ5}>o9iR!U+68^ zsy7O*8gSySgL`9sBxDN=61L_|W)J2j7cmJQcti}R9K)wV#g#yWnD>S;DKbHr8k=gF zx*x(GsUJE|u`nLe1L&9OBXd%YWcFdv>=M71y)3CNnlD-{ZrJtOer1zrs%93*|@J8Zu+L&BHSqW@<111uiwCI+eNQwT`fMh~2As+)en|{7YzHsjzVWi{!Q>ZHi+mt*X5`rYc0P ziF*B-+6zvQE@rxb#lgdf-+C~+5gQfk1fAE`;HTWEZ| zTNqiq>jCa&KC?yOPQcikpzwa0wx9sN2SjjUU^QMtG6Zv<^&YB9ZXDpGt~^LCeP7~l z)PwB8pvYlnon?BCm1c`b=@{pq$<7WK9Z3R2ekeZ_bCiI1IwPPx#02g+F7qG95P}xl z9I0UHUdw3gEX^d(GqCcoGMEC%!IFEU&7&2n`l_y~?u*h@?zV^ap$_zR<@Qlmvsam0 zF#9YU-zYmtgON3no(W&ocGC`UZBiF|JX(pUr8s8Sv4&h_EIRjf2 zTVXuNUn9TBen|w=@b|4$w>JfoG1LGUhA(u<*cDvSiv%Ih$8H+<8#eDilW&#y9l?L! zmo7+89QTMxh|P<6A*tAYT?ZNNrWB$;zd*N0sMVaOJ)vm$jZs$HF|T5zs^zV4JHN!? z-x6doe=Lvfe{r`aW2$VOVnJ=%;1+z;`oQ`cBKV*<5x{)_TxbF+fJsz1!6IDIR*jYB ziOW{?&aC&>yU@o3dBcDkC*|XI=+a@7e=8|Yhp6MoTjSl!amxN`FLq;k+J5$W6`=vY zjna)WfhUBg#|yrUqI|#HON~*DQd>i-L8s##=4tQsWcf?&R;8Vz!+Vb>%5Fm>La;hI z(CK4;KZ_pFr3sMg#Ok6d_4=YJEni%O3Q#SW)kj5* z7)^jh>OK$R&oEd3s>`iFt+1S`<=@@7k7^pvcP&>F<1N2;|tsRK|rR4wg2pTyU z*qhk`%xtU){?ex<5rZ z|Egt|HFGhtR24L{GO~8~9D|#MfsXU<{{LUge@Fa7Qtb~(MutBn|7iKQBq!}(2K-^r zzgFw-+Rx?UhUTRG&(d>4cMU$00Riy>i3##4x&WWHA=oM`)P20{p_@=aHzfo27v?Wu zC~PEuF?YpkxMylreT~PAW4|yVz@+-l=@y}IUbl5^{uR&1_`HBLMRw-s=V}txOW{O` zpti<}v!tc*Y1JU@ktm#@p_d~C$!k??eMve5CL1^fJ!{Rz^1Ixwx#NdgU9%~ z`&r$?d%EYi+OqnKDLfD#HUw!WSTYc@E{Nn$C_3QJ2YG_a4f$xF#hUN6Vy8y8m$ZV!#heUr z6Aku=iO2>2S(=2*fAN?azIs=N%(tE)tsp7DJlv&VP5PHz|7YYX2Uy|aPcI_)CKoe# zDs8t`CMl!VRu{9QuwT!RjGQ$-rAwoq z0B)~cw{BujwR?69j3W`+`|~DXZglaG*9KU5+`{t*1eQxvxhSnvOTykuUNAJAbKR_m zAfCNbB~@SQD&%lGPkMS5Z|+wbZy!1+?cN9exzolVzzmsJ#|BYbFTYeM$6OC4y!$_l z>nP?OUL8G$G%{j1IlRst#WN*VXvZ_*Fej_|)bqBJwiW+*Vr&nfM6s2ZtEUSyB$MM2 zZrv4Uc52nMXmGea-5BodG5@Fc3Y6%I(sJc=VgmD-VRyc9wm098x8QoOWv485@B@>q zEeIi@$9t8I(9xIkG)ay|*guZu=N2ZTfh=^qe!Y0Rs|bDYXUg0=t*JHgW*=H6HR9DM zsn%a!FE|^hbyN^AG+_PvIRD?a)A^)`^J0yEa9B;dc%?C$%}A5x8}ds0(n?cHlwP#Y z*|aVl6I?+sd+|0K$&Ud2pHWM|@+WElE76P-saI518q}g`ED6!Ez|=*pbq!X7sNu^i z%!YmHdnJnf4F7kJ{xz^}A>!ovcut+ja%+iyytaXfdL4A)@UY@-)&Cln0A?Zb zR?uL3xx#F`hp{Ql_}7K}KMV3jdEGfgD7MMRcr8MAC7C*`1oFDv|L8#Hvm{Aye}+?X zPeKjKu2ewvKl^>I3_{*yyIP)c;6?wZVmcoHRQ@d*yws7i)JDJ+gmBsGz4&UDYe(Yf zKhy)0(w#uAHhO`guebd4(ShA`p5G`~eUH~-t!J|7dcf*Ps@6v{{Es8~d)_qxof<(K z`~&Ba@u_LCFhS|A#ye~znN+?1G3#@e=wP5kHB|myAz0I+`YxaUxv^tl@^!8X*FK5d z6ES)=L)x004)hEmQ7M1At>n%!!sw6B`^okuUOZOCY(qx0Pw?pg7Qy{2IR|8S$^P8Y z&N3oIi<$oA))4miSm2CeTZ*H^8<1`TF`?W0K@93k7#^xQ1qH3N6$HEY{dXzXjt4Z| zn}jc?*DSg-lUS0sb9^BOm}OkCm{UWryAScXuaZ!Sb3()mJhPvspPGZkX zIKttTz=ImGRq3>a92eP0TY+Tofth>=V^tui+b&dST@g^oA zAY(bYw?KL`F?Wn9m)HuGNJdcWg;ZQ+t$OP&`ON-R)U+& zAhUc&VEl5xuOcbc=ehSNz#I%r-2#s#TJeeEopv=0!!CKouzUxSTvp8h;pssE-Zt-@ z+1m{Q0<=WbvI;frb^0y>OE8yL9zhUnUDO=7e$pZlg*s#2OW7Xw-0N_pYu78R-t7gF zd+VOQls8F&C5lBUqYztx63$R?g}_Xo`+kqX&jFw)U_4OHFD|gFeFg-}!*7n_2kfu7 z-tyQS+WQ#lcv=C0HSrGzRKY|iRqsKh#p76bOru&pXv5WwbFRyN6%TqHQ~uN5IgdZ# z1A`nPTQ`Cd30Yu^EN$^uBBUSqEvc4)dITiso#`(H*~Z?#1j=?iL#c`-xzmr0AJ^#e z(EG!2+|~l0`9zS-0tdB3`nVAp4SMs_^=*KB-74#g9c=4l#1n0Wh|m*j`oPMi+|$nDk9T&MFtV!Ty*35YhXoK^ta@eX9)RI<@zVd8H|lozgpHv-x!YzAUByZl{5{1 z6hyr_?;?>$38eO$FRC`mvYBF&TCp=^8c8-FvY9)LegNTggp^-Y>3(R2UQxk3RtRIS zmByYtS^{wTnqB4C_d;F(tZ)twhirhE!a&zWVrbjrzM0~$y9l_CAPay#vL<`1Abi%o z_er^Yw(kG>DIZgixN9F}MME-DgZTQ+WF87UTuk4)e276cgqv{&BjYDJ%-X>DH`NbY zwAHmBxx6gDZS)^RjwtKD4C83vCkE%87U>yQp+LtFR=8maPNvkE5=~-ata{!Lhc_{a z3>1s}%=hJuGXgy7Gfd@;vq2%F&ll-b)C+d3nGVC`4Ag@hCvXKfc+u6>afTuM1K7S< znL0FXo_=H0NX${&edDnMy16s0l2aG&g1Nx>Vb^ZlsF0HuLy`Jh>+P#*Cc>Eic=2d~ z>(L3u3u{5B^;h*-oq$)l>!SAbFc3|D*K-TH6YsE-o3N_fXHq-q{{rjJ_hB#rohxYS zel!Bd?luSV7w>i-%MSX*cSbif)?B>3$~Rebu_M_=d58(#mhIzcWG1XO{M)W(L;Pi( zXvX1b+xsr3Kq^Uw#=UJG&pJ%0iA2IEO^*DKwO4F=x5>S4Htm27NLn&Q=$Vc;F6rm2 zpto9HS(%ZyF9^x9jhryrDd_}@YuXIKFmf*yMwNIF$KH#*XD?CajVkiuIyprEHFUwi{KOTV zfN>X<3+yGvCVl6pC+=Kh{GxxhsyKd@o{f0+6+#{-;Yr7avuw0_epSaWz;(Z=(wZrc^vy`^;v^VL8K}J(?wH-eTpVQ}0`&l)N#jEoWoq`zn;sR_ zT1F+Irz7>S>HM;%V#bv;8Agm=_OrN|@#>W|jHL+?!>%TC9kMzHQ4Oh`rcA}fFD5Le9}da^ukA#0#^#WEOA4uqHQr_tbP((orF4BGM{zOHk;dVT3Ls<@>Dig*s$Ckp~r( zZPNgAPLmoenPURFvv3c41(R{KkBcv7s*i*9E3+WK1OEVq56nJ87?bu;n#*0D{lE}y z*4=SVLnY*!H*T9xvPF;FloeBHSal6r5-*9UgHX4*g{_FLY{0ON`1vYpeKbL>XJgyY z|3Hwjh{?0C01AZ_vEyB;KVkJJKqZ1)t;akZTu)Ul??wm>y*#V%LQQ#CLr>`&_y^vf z;oW>r(%Ek7ct`DEbw^W9vcNLeO&Efd91ajrSk%;x?2r9QJ^T+;?X$wmE3N+fZFwQS zoRtH+MJA&euFf76%SWsOLVcXG=Bi9@m+Mb72@7l%CDsz&b4EmWg!u`Va{?BEf~pSA z8tjfPycc3!CjNVkK4&fkmguoZ>2g;!aQQa(D*-ECtN%C73>Zh`ve*Q#M3xD4sl!=$Ynj~KfHpvXYjv59j-c2e-4%YHZL~uQ#obd~(fR3$WQ49tDQl#G7SkQ{ zpGD&(1c|v<$=6C0&73KU?97Kd9AfTrs)o@5y&ppBXc#d%q;qD6%+F!j5oN1an(3a3 z%3yut1L{-Ks46j$OIJ41oyq};chBVKoA(>c*YQ&nU}k=>@w>{geBH@YGW5reDKRw6 zt9C=>K6+O~{>MTZ6Z??UXTt@ZUOowLUQbe$WMdk4AY?$miU+0P5?wZ(*=ofe(O9~u zBD@{*-)27aTwvzo4=DS2T@bt~j?2T%PRnS%yb{wou3h$+t)cra%rgsA(wtFq_DlJN zUwJ9#9dRlAhU|AmijZjmEm4=vB(|$#N^{?nP<)~{shsK;H%0jBA9W(#k|YiF>=CUL zG4v$OSELXppY_^*tw|hOOQYfh2FTv791adw88+6k7U`p`Hj>KBu`W_YY zkkj6uLRl3mqc26G{BHDriWUlw4xsdxVM6DN4*MAnx%B{T5~X(AboAINbb9hIB&bJU z>iEl^C>L)`F}9nehz{Qr&CgnGopxDteD*k=t(#?)aU2%A;Rvpw#Tn0n{!rfGSC3hP}EAh$}F=m3F0&|}Lj??Wh8g$11 z&2l6Fx*&vw_+;}*?v@#;TF{P=w}mG42zu!RtC4oSI>Lth>d zW%Ci**F{9w;a148;m^y2+*R;#4%$LrHSK|2a?_2aKn03* z-oUUjHGTx9FBL<8IdRnD!F%R>mWW zpF;dx_Vjvug4Ik7;A0g1Cf0nFCUE`l;3(6(n2bz35I+RjdDw1}Y|VMcX-qcTqr-$* zCGghJalyy6d$Da;v)vnUqG<319>$SXJ@TO+Jz2P2iSaFh!pY9`c@9-A6)=-j_CE5Z z;9Z-B49>(0dRk~!E#5N9zei8ZSaLZGt&AP~V8b8JXag%8{|ktFF+*A@ju|*} z@&-CcvaZ8&sHM6Voail9@%`ZEz#8nl7HG)Fcqx-+4f;}5A)i{rkesa}jqnO1t(w3( zS*?ePwqM?}m63r_Q2Q4auZZv8CVO@=m*?9`&fv)=`dIU1N;vP$u9Ks0E(qR=DNqc7 zsQ1zJ$-}O?^g(TW)qMp>Od2g*Rx3DeVVEnz%B{t6GT~H5>;3l2`3)sqYVx5_knBE` zLdR7YB9?b`Tw{Ht5b-eVHp^3hHFie3=<9Ypi30G%e3dJStp~X3HAebanSQiEGzY<& z65jhJ$9r)h!1R3W>`d-vbEvxS;x!&-`4+i-vlHVx6xFeK4e!PFKnEWOGte~h>yiiW z8K&92dTOy5s*m#KsAqt2kvl$36Y4-Z^d|uD{LL!JEbc(r`dYOxAS0X1KFQy`yrbr> z_R2N2+=Rxp<*AkQpr@%Ot#cN0vKEn=8LS^AYHe{>*8_4s4v)ZuYm{ST&=j{@@7nuE z?fJlSP|fB!cR1D?4oXKc=Fhy#X~{}!dd%uB*%iHk!OB}oZpf7&U_&nTu>NZ*Fz#Bt z4pJ0no9=Vmlb9dUj@&AKY!0D%L3*(Ne zCZ%1?0}Wkn-Crau7$pPZ-@DmS(y%7i&v*$a5ehR}kP8Q_%q??$*}ObEt#7p;35r^g zBBH(q)iCAB>>Y?>JFiB3@uWAGoRv=1I>$cbACV#AHbj|X0X8X96=8tmF$?l@+4nR7 zHUC9~ZHu}9DbUW%5ubbmiP^lfz*}T2pR+3p&dufZ)#v)hAO>#d1fC0AP*hW8b}{QQ z9IoD8wTL&2^|ecG^j|skVP@&1^Vz%MlWxMHrsgpM0h>ai_PZI}0 zes=4eAkzE1`BE;uy5{q|KqB1Rs zTUv3s2@Lu~bb&10_idS$-TBb3y@!7?mpi9|nUcGud!;0P2EQ^6?Z+a*q0*b&drOQL zeQMTicDAcJU(K30--qjTowF?4{qiV(lsY{buHVo|6Sth(WXGa&KmRqNl$QBRh6rr; zc24fBvwFJdSqZB2k&Kk5O#E*;vB}Q>2@v~i==zpJ2XPccJ#*ZGLTj~UnGg<_%Xp|_ zJ?}BQ_f&G8-!CWAa!+og=ow9MIOGExW0$RZWwO3UBRg#Ppcp)M zuFrSh{58qZr2m;$WOu7mz3M3GT&X07I#DHy)rSleO&O0V_|GQ)z5v)flAtIemkS50;A(mE~E*a*(v z9FLr44@|BRW(yj-+!+=&`{79%92G~mY`9A)J>T12c(1vImkq8y6Ou05J1*hdOHEh1 z`qQL=m@;;|P&2TmeIPLJ*he%>$Nl zRL9KG=FU%LBVGiLq~2nh5A%AWpMm+jvsJ9zWs#|;klWnh2<6a22e(4& zlV$CHfbq=wV|_hVP_5vbOq1&d0qpW@{PO4wwq5|yYpo6nU)$V3&C7nUB=fil8oF$g z!wem<#}o-CUP9Cs#Blp$v0=VaYB2g87-y2*4ekZpI`3ds8Qb(r9fTWal1sTSn!2YX zn!*+l@n}_7Tg?=3;I>6?381`a*`uwnXo$+5T!M8H7rMJoLt=2QMO&#J~a4E z%m_YIr`T~7a9G=%wHD4C01Pk2Pspe7!n`-)-}b37{al=^8C+9XzLW8`^!lKP7;$qQ zm`y^#6wG<-e8_6^s5p4Tp`BCb_5GwaUGNANkUzpXlW;OYpM-7z|Y6(Wkr29 zk$Gp)k%WcjrF)I2)o3Xy!mj7Knaa#^?BR8b57fBA8x0B@b50aSp|HgjWF#Gj^sL%u za>pTQnf&f`%w#WucS2A?BCx&X@tV9i7xElT-gl-**9)X6eY49W@Y}zdCVC;|0A1^r zhx?H`HA&nZY>a*Jt{nSY%TpHQ;u7>vN(Z3y*D7T12=r#^Ot?=+u?bcwG;2qPO6aiS zStdvINKreQ+hhwAtEb^YAyC7;Ciptu9!p0vQV6zvs228b8SPF51J~y^5Lw?{BaK7> zv}u?N3e7wB^Wzrmp3)-9_R=C=&4xwwxH0#O=_)!2!)*Ct1eqCWp`lPbDZMqLL_Al? z?7Og3ZO3Qup562~RS+g_p8U-uvPDB&hFKV#0um3~R&Q3w_i9si950M3%kCUY{>S3) zKjy~{sQ#Ysj@{oZpBAer##GZ}Jz8Iekk^>UP2<$`^cII!HKWO^hFIML@Bpeb4#ap6Hqa&bBrG$QlXue?GL$)tOO53798*!EcCsXA9Y z&Jq>wNLpVwb%GuNR)`JSIx`y)wAy>s;6k_-ChVw=OXJKG)%n-`XVq#}Sda*F>wT#$ zvBsI&GfW+gV+ctRP77@OB$xG6hUr z3tiPPj~+>u*9#-kv(8IxEAE`@Gda0sYVJl!Y*?}uc0CFyl3)*`De4FK$)?!}K-tB$ zn<->ac45XzQGa_skuY2+c#|3oskHk_cz?X)-`alr3~sIQfz1eJMiH^hW~|XKrmken z!ZhW0r&3;edO^ATF7^O8C}t%C0k>%Q)l7IC=Z zyxvGkN@oT#E!&PAu_wrTUiVJAO*b?1#5s1$$kcRy<(h%hpeQc3qqeN09_@q~wDMP6 zdHXMBaYLsK%YNsNr~{bP_617x?;!VbgH$77Zm)Z5rs%sy`p7>rs*=F}h=rGW*NUXO zo|a4=`Q(t=-{vX;J#uYyZkkB{h~`(_|3l?ja&EleWW@q|?mWYN(p}!gj!#j$JKHH? z;+mOE+;-oX{)~e@Lum;}(KKd;e^Y;+TWv68ni?3>55q?)`~&~&+6i|41!Q_(iX?v* zlCR$_L??3%b(w)}A9>&*I z6a0}!_)JGONp-1}jtfX?IS{=3ASfZne(E<()lkMC{Vs z!ce#w-bBp_&W2Ta#%OZe3Wlw>F`CbRX+V}5^@(ylkcO0>n!1x!Ee74{Pi`rQNHC*_ zASHi^GVU7MF`|5y)r9-N3e$MSZMLEr5hj>9 zFr~9Xz(}!XI5SPQ)mj=>n5L538jfr)Y|wq;J+k-GSpK4Vv%e-Ex+Rlku`&3h2oo$N zOC_?*Ja?TnIYVAHwmOgBNuHUBb5CB^IsQc;1a@m_Zsnp1gnMQ8ad=f#55$ana^d&j`SrsXg(TAJ_k%QD=z|zpD%C*Xf$ml5@q#a~N=<$rnW z{}p%l!l6qdhe=cE)ppXpRw@nz%Qqu#@84onnT4EFckWZdE$-QL7Uuj&K0FEhI>D&w zPRy7~jyZTiF7%Z0mFicR=x+_bvCL_xJE8c^9xyN}0dCe8YK+$i@H$-S;2b{HXO8cU z_1l!cxD0*vWUqfQRPV+|dN+q^dilgeEh|*9c@l9QIkYH5(-1hS#8m3>ae-Psv1phb#d}W zWoEO_^GB;in|br3hK3&t6V>?%ZG&q6eG*;nCqhamm)Kuq=F1xQZN{M=BYAazs*Y86 zpa^<@LUqO||H4l$>vh49k~yB3L|tyRggo+4Y4Ow8jOQir7I*oA?>d9YVdbemBk<*`{a?oY}VI}$hd2u_C}KQ_>>n%X|9;{74}%FOkJTe&DJ7)H-r491yDOH zVRr25?DUVpU?+Lf!97-kwksC06?GuP-79rEK+Z}ip~MoEQ*_;i5krdrbO}2=oB+a7 zr=IyWh%}<7HNxD^S)A*~EUd_x!hm+OoGWwHSbp#Zw~N-f>n_r9smWOl*F+N86n=Zs zVHqm{G5Ad!)`(wfeJ+LG$Y_1!DRK>v;9Pqy!>T_aYPyk$!=70T+_l)M(LabvGi`W< zex)`HDhK>%43_z_O}0b)>D&0hKEHmTeRcabtc>o9_h9Pevc+-XKO&JeZdNGvC^D&R z)tTL(GBn{{k3O!9JQUG+P~YPyHr!abrN?!f4=T*q>XjP6v6G9bIUHA`6j`qe`ggwS zxB&2(i^_LJRO2z-|K-fe-_M2NeE+-Td)dZ?Ll;h}oK~oDgYtS*7tvM77Rd5Vog}Y=%@tDS>Ims0?!V z(~NXplsxL*ax|e1{dU(^3zsV-#;gPAx>De3qV6MAPVF#jGG0j36IH}urZ^(uRY+;< z?PKsT&;?UX9$e4wujJr&*k-iJqo+n$!EO|@98<6Gk&61ZH zQ@^up;|lFx2Y&Hr#<}IsI{W=D68M6099DH~5y1Iw@NI0qvDHK;$Gx7&#XJAz^z;}u zO02o#9A=zqp&mZ)B0+w<8G+2a(7pA!EvsZgWCEs{g|xNk_>(aAz{jgf*^y6^d|D>j zsvk1p*En364#^^a)^!)L93zuFQv2fnn{S(LyYS%K+)}*d7w*NGaNH&`XY4#B zvLUR2PKS!EjPEi#4IDDl{=(eDpV>a*{M8JZoYHDA`$#s_VN=)2J0?(ZnE zdUY*oOiyxXeaT%~%!L%+1kB%lXEN&@sTc`2ALl(Am^)G!dG@q*OPYwpEgO zB6hp>=HJR3$GnAf^Ew%Mo|I-{QMlIw{@^%aG7&%^8z*!V5-*!4vG^soX`v z`#0C~v;>o%jk_rOpkrNC;t!&EVzuBGb2Mo}v(_?BG9-O~gvA!Boa<|CtUjtEE;ha= z+%^V*M=rn_?h%Uio;D}paftV!HqMP?)nwg1excW#W9h_C38y_ZJ-fJEs7#~fABXsO zC}{fmU+&n@=aMF$CJ;x;3iNLhgzw&I>Y?pRAn!Qx>U^iM1-;0uGK=#~_iZr(`~SKpaTQ<53SPy_XTDAx*!S>cyl zkI zv5)Y5u7-jkp54_B8Dg$bY!GM8LKu1z-P_Jh0V!U+THW5LF&7FNK8*^8fxubOhpW|)MrAg>kcgglk!oech zaE0!cEj7!_MW5!>8!FEyb+l968z-H7>=BIyw`S`tAJn=otjF2D@Fess93EiGBq`!P zI!HaKK>O=ejk+RoTa^ zNbaql;(p&6u67q}R*_mYp|tWZ2}$LT-U1LNerF7qTu3Jeq5;kyX;_^u1nKZB)O~GO zCh56*-@06Fo-fUFFPpz1CS49@sQu7&fO{?Y2tas-iX(Q)yEn!@Qkd;nOM+O@2h36_ zLp62tuWk_fl8jcvU1BosW>{Lxk&U4w%X`Q+Ggc+oq(}>&+P$d+S7o{F0D4U0)ma{z za6IQ9oMVsaT^K&}(rnUPV&;6e4wZePx4$!nMmgnvcm-HJ=fUjA>)#)nF~1)Dq-Rv> zvvM0H=|9P|q=;YjDxUF{JW%cdD&4%3p}&oKg^x2Rnl!8j-Y&@1>=wv0z1MZ%c&90_ zaIWn|y}i!wDKb9wjTs%jhScQ6bGA!r4xGf?n+~x_!-N=&O(|MU@Unn9f`7Glx}q}D zVp+Nq{Kcj!o!gGQw|dxQp+b~ybBBQ38RdjpJLVZg5h6&7;Pkuy$J}(#uPeG5qcrpZHSxxVj(#vJg z&R#ZtmRns8NM=`cNBu_@vO&Zaoxd}+!8p8~z2LLa5^gwa?Ui(hPDKCDd$Z4f0EX~P)P@cBpi97V6s3v&{P z^@n0KQ4}w(ScTqLMVWkuXOglt0X#0_<(P{SaP{M!9O9URu`Nx0x}iJ%{At%Z`gGp5 zr^6MBfL;=K%Z2)CkNvohy6H1P?wM`mtX>Z3n&0rq@I*W$XAYr%WE%48CAd9sFiyO1 zZWjHV?0a?XG8A2+UD>eL;}{w|0OQ+##aX~Od>9$4>hl@HkJsT4vwoYw4=AX*>PLLQ zEXk^&;li(Po*DffgQA-z{pgh?yNH~GkonYSm}bP!F6wT!eT?q3chvrqz4IDW<%(W( z><7diK)Uu)%nhwy!1{>!VkttiTkymgz1Vl_+d3{WEg9bawNuY%W}e2P90t!E?2(k2 z36E<%7)X-xmlHWdBUCDja+_?81e7mHOZ_xs3n zQ)Sb~8!(pX9_xw|w7w9ibf$8PzD~#6O7p;e8@AQ-Ren=dOVlsInLi0YO#-?_&9a=V0sdea}w^>efi_>;`2j`xJe zU3o?eqyrOAeu(Mi19ME-8(^?oZIq)v1&bf8RbTu3-AGd|vePq4?g4i8!M?=KcM;4- zjj+?=O#HKWy3X+?yd&eNlIAB`lWSY4XC0?3LL$*S(J`eeSCem?nLZo71F?#y~d%J`*Ep`h+t84NU z9153MYWZrx6D{l7gl(RM(QryP$-PPg9XqD6HK2`)t@Zo7+ptwKPpVv9@iE_C-3V&Y9s)I_vYLcv$+zJio^hGR{aeDrb{ZxntVx)b*^EB2I{@MH zXu^<`MkTnavmSvYGZCQB@Ww}mSlV|g?5?+uF@DccioqP$xk$LDY?O&kWsr$A@D<-N zVn_L$e2NCdN#eM#3BCC%F;tj^Sk2;hIu$Q|@nP4ZAharsiU?7w~*5%S~^8p-M*|3@g4#7>FH6^(e}nS0{BP8^}H(()^W z$_}P+%4sT%Jqbx*+3I`4NSg(!d)G_^wyJ?z#i%Z&&OoQli@OD}FFW0{kLWvD3Y^2& zA86D?)-Kgxut-?_3TT3*1U2a;ckU(C-tc~uv$*Xwk88~%B8I7VUtK3v_2&_B>|Stl z&IN;~jowQ-`4Inz%KkPJ9Ww#tUO~MO;9#>9$y=Ymr8MypA1-w-$9YTAnlIY8txdmk z!ua45$~XN=u`+d#ru5b=RKi>)ydew(`Gc)a)4skmv6)AF@054K$lB7bC9Tvl031~3 zwe_>z72Q5@hFh9%=QT2Fzmuo$$kdou8_&2Qn5Ng*d&3q&$*ut7O@REh z9X97GFLJa&R9HbFw(MCvYzv&&YU%yA1}*$qYfWXi94e2Pkc4f};0%WLs)F&eoE}t2 zx`MKJad!)?hGB&plB?G(^W!Q<8Xdx(IoghQPit(O7| z6b+S@k1#b_er-muwZi6#r4 zxK>{*oXYb&ZwQ)i$opCd>RpCIzK+gYE|c2D_Mk&qG&+AaKB#y|2u>57M`WCIM|{oL z^!(5G%thcMC;|g$aF+1YJW)e%^}#-DOx)G-)G*7R_iOF6opsx)B8gf8X;VnhlaFlz z(DS$1zd+o42@Wn3)W(s%c?+A&eG}Uzp6YVx?gO@cj*_reD(83_PMGgV6lSgP8?5Bn z>$%KBi(t>TLD>sw?8LtciS(u)e6^~ykV-!bb$MZ0@Y$l@bdg(Pt=;1Gc$sjg!D}@yD*v&)#qE#+q_vm_dX|r}&P)#p6uGI0B5=B2#kg)f zsQY-NZTH)#&JqikWose!E*Cy5&0Y^pT^+Qjv0@+$x~plpLZ^{U%o!#(@k}lO+AMS% zj9^D+Zj-VOuPDYS%Z;d;9$t}V>YL1X%Q56n=S&IC=B7s>6dEIGpA|Ey-XT)IFQ443 zlI)j5^An~fm_8g};d8N&`;L}5W~weWgd*Rn8Zh^LlF8Ygo9S-GC>1N@XOksXi0E34 zO-saBOyf87cvjw?8Zm66aiL$Wm4gDOs=!VoFUt+j6gxYyH{dyJPq;Jbj9D`D;sF-99RwdHu+ZA4`vaFftNw_1K16h?QoZ1f;mI|OS%XOrwhQ-p>GxrrkjPphFvVuB?%L{@ zsaWaycPzI(BdZ`HGa_^FtWVgOWm4OC1SmegZt09<*r{Ea_k9&(_+8v2hW+@xnEOv6 zEKgGU%(T_Y)2B!^UV>+o8@pDjoCPD*6kARpyCeN#Enxv8!tt8Fry|1jx)m{%EU8#z z!yF$=<}y9i%9^o~e4xlIz71uG6Dd}Gb6tvS#2LhqH&3-HOCr0&(>Avx#E3PJO13v&OWevv%2Krom`YPMI1?QJIF9nMw=8>)zP;LnUY?IF8OuzRGVgD9ykkn*Q<^6RE+)vhSS@X-$MFKfQBt~*=+Vln6J-+ zGz;x^dRte4efy^pTNm6obE20Q>4z-h^5K0po2E4i&NszwGwEV10W+2)2ks}(rvX7X z!`QvDwwhsU=|7vCDM$S)t`BP54zTkgc;H)ohS&IMyj5C1iXDvLt8-g)^~TGj zlcl%Ci7PO$PLggctiQr9ni_ZJj7x~6nw#E}iU1+f4&FODk-f*vs&m_a{TGTLuFvQ3^Zp2oKC{9P`sw~#`0+U>q zH_;yv4M%A~QNn(a=*Qo!ZD}VG^aZ}HJA43A$Z_xwnlEp#t5+J&-O-*r3KD3iLy>~O zR#J01uou8(2ppG4gPT6?G;4HzlLaL8zY#^A0x50|l(Eg$nLN9`<5s}{S67nvIW>Xj z5{#io|7GN1h~fd#=M0q_%YSxLfV{gEa2KF?s8oB6$sN5H52NyOi6UFWG=JwR4LV1Z z#{-8%QF_P^zrFgEdPe6@OOiLc1in6cIMs;id28?4$_1n?*eMsN4ewW=S*W>OcbV{a z*JizpDDr>2Ll0#fZwy(oHf95Ky};t>x74)Sn@1F~#%^i713WM0T}0(U&QR0uE{b;{ zaDT*_Yv*vdXW7*##(O7va2?M$CWlaQA(D9Qe_AIUC-{+*aMv%1cfz$hz($a?b@(rH z)X(tDdAhhVuDCzCEFC8VKm!=g5{7IsEZ_ZvP#Vr(4x%8`MEi>`^>~}l)7ShPw%ri2 za1gS6@2vs6=HDJq0;#LwbelcVv7S}6j|bB-2F>IizI=)wwIszr2Uh0cwJ#6}=%V0g z|EEq8*sN)W{x;|}8#$~FH~*KFsOJgVwudGnBC@?vHfF`t zAY2Zc*H9oI70r9{(gdvs4gRH;yejrLGdo>_+~Qxj?-MTWf6q)HJJ2tre?#sz`BF&S z|EElK`3Bqq7-M!Yc(eTNO&?nKUd~-1GZ6`<&Tzi3o%!Y_As3BUJs9~bj+-&%!q*kq zR`~Nf+`AK6A-K+PB+b;}L640kJ*l4$(bqhTB0?Hk+!$34B&sp3cn$;+>*p~_yHxOI zrUETPZBowZsx!q2qpbQ?>XVDCpw(v0aL|i1)k!X0=GRYZv~vT~fl|{s*XmVtZml2m ze-=enCF5uu#-LDJHne>y%Ky(EMLpd!<1Jy z@78+^20Dq{uQd(A0!InWyAFOF@LivJN!=7Ux6Vq?5mZ|=fH!glx^s$>(QWR3G*=** z5dumgD;%Y8p%o>QjVy5B@>G%Y`>spPzm{so)n5;JNKrH&`YmdhWg&Sq#ZABZn{ z#f^*}=#{9prjoNR{7;+=FBG#Zo_QBVQwZQcIsBqf~dO#S?WW-jGY$NAbl$ z+i1y=`}8cT@q86qshdcOvr388gS%sSl(-ytmG~bCWNh4mw1^En0k>0`&X}i=Da6hh zGQ_mO=W^2YoV&mg!(hQ6S9TovAc$VI%GB5XNQ8s183t(%7r7UgNf+XxfGZNu@C2Od zt$%4ES;8T|la>ChatwG8LJ@uQ8}0_dfkQm{;M9)THjA|#_5GLl&`tmS{TSW7KbEw@ z4EPX4ZB|(-Ma2b%7O-UMYyu7qoKfyph{~jtsm0h-xvl|%}}3>p%__^zEhToQMnZ*fj>-MLP_WPXcSNqA z64F9I+I<-O(^K@(x4hgpv}A@_u;aW6WpjtNqXU^<1r=;DOaf^5>6dogcw;@{wQbp8 z0Zo{i0$p+(ro}MT#w5_?q=oFWb2^eqGw(1XM7Ln{M-vST-;Icf zvZk`1oey*e13u6W^(=L)&V>9ZS>5lny8s&O>Fu44?R({Cn%Pp|>rEFb!?&xmkbTri zsr+D6lZi7dQuCxU#D4$TT(m&Lw>RL`N3%5{tald1&G`m)Sy3+35}`F{?mC@Frt{#p z(j1sUDc&zvA=)K$eJCL@c1Q@-_{(i{TX7vGPdV|f$)T*9O%{HZvkiV0<%^O^a<||X z_CZeA-5=!1Jj_y%LyMq6-4k;&Su12fgncJYKcBHZ{A)Iw2V3I&#`Fm@j4678X?;;R-eQfsZXrwb{r183VILki#MpwmzcSyQW+#s|vI2W+i z5_R>Jx{*Z_jLGwV(Hw@2`oY5X2ga>VF+)96Zd!JVb6Gr13^}8XDFYPSs$JB=gs7IYG8k;d*UP<{QsSkhpMCSuPL# z*vE^3Pde|-?hA2lwvlx)O?We(X^{Zo>H>Fs3>xmI@fc2TvfCa*fu*yY^Md8+6kH#T zdo==%x@o+2j-+ky!GOLbX=O&lIU2W|VPV5NIj!nu7Mm*0y1e~+?^@C^wg8JMCUBtv zuQ6p`pVsT(=1aHrLsHi0pOD71ZxrT;;LOgHQ-4~^wQi9=Okd}y9_!GUBYkRxQW<}W z0h)x8!bh)cAh4;DLXp^@?`V_`{UwzS zNrCW|Ew$)KYb?+s)bgdO2i4g(k0f8z>~n8+r_? zopU`7)a&7+s74Lot$w~;E`aOFO$#LyiZ*{wLjX58NrI}+tD|pfAoa!}eHb+advMmv zpfj=>n&6_3x`7C*9Bns+qLwU&Yi&%ZWua^Xz??G9?xHDJ77sD zigc;G`nTdOn{#`O-FjdV=gH{R<>PJk$)FBjE%*rTnNmc`=k0-~Q{Kt^1CiLW9aC2_ zVGH74wkF)$fLWWZ)0mnyImHOS^UR$DHBqOK%mQ5BJ`=jdS^!gdf8C6(K!P`Oopuje zV~h2r_CKPy^qT0uC2`4ni6|7YWdNI7R(iF}er_$%UilmqE`vXSpE!7nu<+}2p5Hv$gF~3|l=6rlVO1x0{#Q=Gc+}VXgx?S}feAcs z8p>t%+C_*tR->|BpZjt3j^_@)wQ!q;pM}FT%n&*WTMr-Jfc1!ydB!OZ4B?N=l<)(5 zlS;C=kPuj$bO6z3z~t4zN;~?P8eGqVRxmU+cOZ#Tv#Sqd)(#qi4V)k(Ywy1z@XIg! z-*&zV@v-a&H&3a*qC|TZ&Se_(H)xRm<&%E8>*$&CF4dWm%e~59z53=UIgFR}{`35} zBlUhNSbO7=UVHmpjBL}aS!;pHimjJ+TW_%H3->eG?tMM$-wwtb__slXsL_Q=kT5ha<3G9Bzc zHnm@0?Y+Raets}D?|vvJIwC&c$N$TDm4YmZrt?pb0H;s*f#;M`n6Jw50V~Z(bAH%z zL`2=OCCjbJwYRd*7iqtv;ji>M%mymfc8S{ZIInyEdN?Dxlsl3fOd%}FFh04b3~R<= zO7ve|tz_taXl>&qlTVYoGn1Pqvh*2*=x|t`w_LwuKNmG4>x{C+riY8>|0DjfOPKWg zz?|O~n2R?e^urRxCM-zIz!9@@r5(2U8GfEa&Bu8$9a+!JJ1@S~-Lwyr|e#rD40hCGMa3s9d`PIu(?waLXt>8k%lJsEiIVz1PnC zl!4QJwIUa3bxaj53Er4)3U2xrwA#lYY*XW!KaNhEEFHrq(PpIK(MRu{HT zO4P8+g9+j00NI;}gyH(*Y5Wf5tFIUSLQe90wXhMOkuOqRv~v$R4p=4dq0tEf=M{W+ z{u=cDS5a_U0sDFP0F_o{S~vQ-DK)D!mxg$?v{%G%$=g8tuE@p35###{3~G}ATS1s_ zyq-E=g9<#Tph0eE@yy2=2iaoTs0;Wz7~7+aqPZzDzLVRCz)^${E0I>9{NkHuWx1gM z8N*+-h+zR-sQHEi4on;pVV1%{gk}xuf!|KcqQV}M2~_S7PZ^Lny;1Q^`6awad8Ep6 z?9Y!y@`%UJ<}9LFbRIA&{owkOTAIhDwx-|Rp%1Hax8Fxf!@Jpgn>k2O@PQB4oJ*Ec zbb0BZK$MbpH~8dQ*x&9emkc@{1Nz?+3H~<5u4@3ml2R$|$Zp*?d65g{m;~IjL>O+1 z>_Ijj_KX-=g>CD(z!(`;U5#ELZ;l^wx z-iZBDQLnh~>uypvz~;VLTJLkh42gNN|FMmNFpG5_Z|(DpQym_GuSOg^)@&4{onflV zY{oRrQL#MB1NO)#3DIQVUi+4qI96{E9CF=Zw4GITJ<>BI)v;}gM|8UqRMnTTtciBz zkH`HV9!}MDnh8}is5MJ)=z}NA^fMj4UmNYk-3|NyGpFGkqXDXyC#N(ym@~Ew7RtD% z0X=igq!I3GIRd4oFUKX_E!=|sH|W=5QG{J;sV(o~HZ2Le@2nw zK5ULpH&lLwThNc(kV|KM8Ls_aE2w@Q^6ZQJ`g+PJ*Fz#R5F{n^qM7>L$t zh>zhEP^55=HpO(0>D9P;(G;g>VLQsP8Qsi2Cspv^x#1Q+yPy=b>Se_p?y4>;4+qo=~TK@ z|GVuTpKz}eK2KA`Z6^cJWYzSsX-ERQCVGQa6LG5E4#R$)Hm6YGHv3%T^OPeU=Jwxq zBrB4(%%5QI>lB6*ZmX!>j07t^a7=JD1I)SWx*W1_d_84KoG7Prjwr31Q;f(JP_Ts& zyM*xYuk8bP87>PUngh5Xr2u=v*9xCtr`yg6li1 zz2TIDBh;-r9H!CSVuap}qCn|hFKDszhh;42HO@;)nj5*)eRRIQg|UZZ6H*IO*?5J; z;i$oF#=Dsqt_2AjOV*+VHVm`tOu1{tB!^(2j4SmvE-9UUyn?T@R^lCL9A|a08ri9C zl10SKLdS1k%b_eD!p+ZZd_VZ~n89lb-c4+uqC+RLz==A4OifIgNLommAqm)9XR(KG zEPd#=q~hT{q7S0PMko<bO($?&6S?)bC%~rjo*+w>BJXT7QAUf>UC!W zxVg{LBb#k76UW#dvok0<^7hg@^P0qK?~32DxW!S#{1vjr(z%Z&&`| zH0X&c&AND)+1V9%<`E|KZB1zUdX&v%>PhGIXxG5bjqs`w$*j4w;W&FMD4;)nMUbz@2Mg`EDZ z`OLzw=SBBl;IQYvAg7rv5;}-mxNpK6Z*d-+_E-EUzF2%>0Vmu zU$)ur%{)L}7;g>qV)TOQk&?;Vg9L}f&c7Wwd<6HDY5r?WR`7%LDN7M+(4W{`s~5S! z9*m90eW>4e2YKWa24v$d^UmuFo;lB6q@;L0$Jzt$wAe=>2B9)1?fS;`e7iq!XO84y z%SN|WF{Lu%94fb(`cn=X<4tJC*XgA__K~ra@l$L2Pd?qo(D9E*?Us2lWS>_Djy|S0k`0P>Y(kds^&xd)n#5iRSJw zx_zm8qeK}~V`E&qCTxr}`gei=sXC>A4hWJ(|HaBz?OKf^FMu*4W<|Le-3rqCd#@&m zdCwYLWksBM%Xu8z$zJac`Tj8odNuY7VKrgm%k)7x6rZsm=`x=8QfaGR2YaslgJmeJG}#2uO+>xgf6B9p&FbN~E~w7#Gu5P-SBL7|uN zjo1PzH`8}$j-!xXx)m^RiG6Qh(17|*fP*C&f44Pa#j;mjhVXab&?hn2kjj(x{({_$ z9vs+q5d)idR6E5LC%G%6s*61StRr-9SCH3iyt2#>=KvukOk1+`sBqU9OWXDb-g&zRtprtJi6-MAHkr;c5{pl%xb4;YEChUm228 zqqe(Z0uEOkrRfvF+|9(_!#V~-2p!S%6E9VbGR5xefL&o>eoHPO9rODi!RF_!v-Ry! zXHo|YX$y*sXzYKd0zz-2Vyh}nj5~sBRcbve^6L7bIsAwkSO4QrrLV<@EvL&6CNk?q zCM>3)D!);m%`*`7IXC&SICX^+XM^O0lT^g+W}CN@bU$i?Ib?rmFcEgm1gWjk2oR?T z4fBKju~ny?U ziFp%&i|VWMfjHZJE*EN2Zp35(5Q$bNEP0>jOfb#$q%w@piV|DrVEOZSZ2siJf1n!L zDd=w_aCSmgpED;_+ZXrR-ODg0n|hGM?ski9ULyfk0%_{fAO$|bt4--)%ihgwPf@{765K* zQhgP(STq#iFsEpPfh&H7pO`-yw>zwHbn%2?SL1mHd&@V9;@oy&^=H{WL^4cmR1~zs zJY;W6y0fA~G`zoBp3|CrLz~+}*A=v~)>cwsH_7yEhhTP2q5KwaR>j5|@kempQF|BC z{R^r2JN}K-(omd#h|`MkS1yKj&p3DJv#a#)ilebX%PAY0WSKs$&| zhnw|AxG4J_>dQ43yzUqB!~Qj*b0jWK33*)7USdm#xCx)GD3ItOCEuHuMxu0YCQFQg z{WgEw_QtXr<(K+DrC8M?52R0T3$AY&1!XmBcSliolS1@gay9TJGz76poTf9IvlygM zC5=LsLo{p=jU*tx*~IYDb4!g)_XCEEp1UV<>=>DHX)T4ciF5g5Yz@9U>jv59nq3jg zM^1bc7YuM<3|@6aK2P|_BHC2idH7Va(we+7vMbEbY<%5Zasr%OYshJOGPVe4dpSQ| z5uTzooRdM?(aapvrG+;yvVAV3jDSS1Ej=6-Z7~~p)WLy{eD|Nti{Jwx2o+f`Hz|K| zJ3=v<(mIzy(4YgeLfh^~vea;x{1%aJW$)`(i)jlD==xC&!Pv0R4QH#3$fJ@u`W}9_ zXyH^32m7xLXcTKOH5?C7gMpA7c!i8%oJL1+KXTj{v1Mu}&vsSp?utEjyt~932^Lr8 z)z#ojnUPkDN?wdpLq~ij>m?z{ectXYErhmulKaV>FjXbnLj~iKjh5X+bLeQ9+!3lK z+d~ebT}u~gJ*h4CoN!fNRHYi6AlW3IK@^jrmPhQ-J6#UIsYC9CuJoS|wu+-SFX%Ot z81T}+q;>3Ne*EG6r6Z&_b-hkGl}%5tfvmt}Oly&IY3WdUA)00IN10g3a}Hzh-o4U2B^>qM9pt*z*T%QnNCiX4I1 z?orjv$sGnS!usrCTZKXZ`J)-7qu!osZ}7T9irJmd~kwVv+dWf`Iw=7 z;d)tZYH2l&!wBBT}f3YIM+8;Gt0NB#Jznm^a1c;^4{BxO+JfKJoj&EGA&pqh(;;!r|IGN=yfV=m)#2I&cd%8oHJ6pIP zaQ+Ek;6ZsP-xqkD2KV93p}DGHk&mT?`7O=2K&c3(k)`R<_eU0eS_|O@(TE{FRS4U}i`)qLoF$gmL@68*Ug!U;)xZ>_0|6(xuv&x!ibuYmW zLSjUuq7=hcDUKtee|`R*7`ni#Y%wo=9D|UzAmQy zM{`j`$FJNP(;wg2D{fQtupdFzQx|y8oeB4COm_CcG1XnZu$(RRBA@qXkZveMp zrRoxlp3gmBnP$TrmWY&z545@7(dN9pjn=mj{R)f{Q#BkF0Tn=d zJ*@qbnbk47Z`|d#%E6xlXf6J)OyQh*1FH~TLWCt7UJ!$ z6Zb-Bk0zmOaA0gZaQ=)Yj1Pg0UJ~^x+LZ>~bs13bVWsD}dOGq!U~OX5jPA?ON1Hm+ zxOVuQoG7!-m{N3_rlOD~lG_CAxqwpxbPoO$C9!sqx#RN+=5*3Y`jcF0W0*cEp5S+`PPE>sJoPdC;lPhdwJ zB$XzWsHuj4aiS>wVv%d*u&+VuZL3_hg+BnL@q(y^8%v#6Q%5r{nR}>|(M~VTZ{&2Y zVjbG;S6Gh~9|ZSKlunVX!%Q1kU8&Ptk&P&kG%5eg4Rj|v8)QmwNnn>`24H08>m(TdezP5_xH15phT5Xs4=*GxLlX>N30|dXubH@hQrP1jbn@7{?DG&igshy7 zb45lqVu4=gq8ao*9@kxk~&)#g10SMd5WVQ zH!{?iJWVv-4=piUJ>?=^lu@dXDF;(YKEtA=3pl`meEF~oA_T4R?ZQv}0dBMMt z{7$hT$QbC}EP@&CN$YZiQ$)7IdQE^)+0-mO#Y_|1G_(aSeCM|CZuXj3Xvr;*l6rCP z7yG#ishair9{O|I^-^yZr;#Pp{3B$f#dKYxKKUkjP?@Ipj8tFeUFnr zlpYRo8JUL%y?>=+B1DJ=KaLEz~ORGQkj|(_w;v&bR;=oTc#W;p{|CD^%4uXS5oQy&h^_k94vb?#Qc!b_`4ncc;b zeI!e*LQ8aB=H2NkSyp{3`oS-B`UV%gCqk>L{LoUsIYF>=Fn@ZxHJqFqE&a(v3HL+E z<#ea5x&T87DW?*c<^`lVcHJepb93OmQy1u6rKp*iqwbEW1g3gZ3ucbE+s6>EnUvzU zu0eQJ&c#z=!nZK0`AZ>?yfyRgsN;@qPqM_do@EGI$kr&`qD!sqJm+tGo$cFM{5C)3 z>HAybCAPYc$VgpeHLRJ>#8O++Ot2UHN4eA5XA#by7AP8$pi(p$z8Y#<8BYbaC5)juxyy1)37427~FNB zUIWfSYCPm{Sa1*fy@Smg&($rXFW@*K^|^Fau_&h=t!?)dGiN6(zO6ChxCcP?B?jDP z%P`AbFDRY%kJg8xF8>39yhS9nh)%Ga-EvUEl^rg>;)FdqiIU66e%2t- zd=#64H`z@PJd=_@t$7~P5lPOh;vxBdnu7Qfs_1>TI(v10eh8sCPrh|vVV^#7CeaK^ z_F7F(kDwZgm*gVAru*abJj?G3G7kU5p{kk}HrVkW5m24;oWkc~C;q^>92nrS8gfn6 zRX-X8GUONiH9Q>j|a zzw0*mQkRn0fA&b{vAYr&-wZ>W-!a^;#EfEkY9{d7xh=I5+U>BNuIcUfloxQg{RAyN zFaN!f@R5OWgZQ7b`vwXsx~U_yl{A^rA5>zzlCOb zE(CUUgJ^S3$$!sn2nJlrZ~iO42Jz#cf-Y8;L#(DD)Tr-Ay|2c5WuLQ}bcW>AScrQ` zgYB#Bw>WgHimE39EOZ%o9x+`zsf=5TnYG}M;`qnw&J9G;wAVu!B0%cQhpYEN9lm|K z2>{c?K*ktj!jx3h;_#qR@iCXu@HKU8$$YHyU-=*Kh{;PVaa-dT_W7X#Y^e0b$m0gb z?f#hc+4_p?0rHY^8$!@(yCR=GL<(pZx`ZRrK9IGwu5E)k(|^T1Q*Q~#g|N+4#!4HK z-5Q9!aGH=?^O8u1XyjfX;9fRkxiY|{k71Lh zFi)Zet;;$oxF?=oRS?nZf6YrWEaa?}Ze+Za6b(y_d32}J={9PLLMpL^2Z z%tFE~4R*2Tq1HSdP!dfr53rGLV8K*W zvntw+VlNq;My%wH>P_aO4)FS&Xy5--=Q&D9;ZBLD?Qu40AUd4b>m^?jEqM(Rd-`cv zDf)dbpDQ0sqZNd$(pm-bc+BEEyBvC(^lcUx+J)598k%;u=~3nW4dnGI#OqQWkGp-_ z^jV33Mz7EXB#Va-jM6qvKj=mNnTp8nX@ce?hAK)Eivh>4ovLek4C}LsI|^EEn)}^0_j)fy z-}qx9#Dk!7!_sOXcWQ#~UfOXFUfgoW@||MFx*PRwtZCkJ1aL-)4kn%McgpWS0En0% z_IR9BL$X!R$&`XsKgp3x*AxfyFH0YtRM3R7AV6WE1w=aT*(KZS+YVffeZcKV)NVjj zl6cxqq2Es|kgswG9Nc9Z2J*Yq>MHxcm%b>4o#!`=dfaz&OGGNLG@hes-ACO-6Emsk z^4$^!O+ILXPMP-<5bUp(zBNeAv7XjGsrqJ@>PWbPYz&w`J2^(XFh@eNBqa#9bnwtG zc(+@_6_BfQeE<<8fmf@WH$SXo(6_99Ij;3&?slK*XstB}^1SMRd9|kDdx|oWV66|E zrm5SP(nE3HwSh+%f{5Zz=bqrGgF`3l2tlZac!hd%p7s>6J?;4^p_fbWf)XDqFmE*W#iZ)Xxix%WkmOSkWF1Zw=e5^5HrasKkE%BwZ_oAAfAcy}2F zJXz`Cq4Nu3|g)|_x=d{0J)*jHQ$g$+%f^(V&FR=@o1Lr!}!DQC4i8SFy1M3 zYyZVxc(`b%4a?$G_!7WU=JuRCe6vrWNBF=f6WaU5sy57nE9(L$tQ5SV{RdoBnBIIqYut>9Sh+ zrA-ES5-VpVR-TosfQv-vx7kt;_oz|+r6P-*m&tCN%Mz^sO?;y|d))Fh&s^$pL*7)) z+h-i%p=Y7yBv_fJ2=6aNh*SDYn8qh}j*UgnUt%A|> zJf5j~uw zg;mv0v{$Gt?&UndHqAc7pNYX(`s#UZaMwMCgcA!-cc;4=7JH`3&X7FK1&$2up+6d) zRzGq=48T@o40XC3yM7BBVSqIDR&vb16@&a-TvJ+T3(a)vLy1Fr(%RhN{CInH z*B)I}dDJaopH3Cts&^2toR4xXGlD2e0VJIo3ULM)LG6~2F;73_2_wjfIc$(cHQj-| zd?|=^Nlm#Xk>%0^%n6jv%0n8D{P|niELJI(4aX-C^>=TlcTCWn(c7@M8{i~(6Pdb3_S)2mvgGDpxs{gu%SUUw_H%_gTZYTBpoGta;spIXsn?fKM z>bcEL+qgjEjJe{q`5KihLtgzJBfDPyWNU{VtNj8HAmGG!QBp0#r!sT!}-Ir-JBs~ zTXv;5HtxlvGZA`3k+gGP`S#QI`YfdQloEG_}#oVCo0^=%KgHN^O^ZM2hRPNI_W7HO^ zDZWsgj5&K}b(ju0cb9(uL7wEX#t`F&^;&Ti4J_pK5(_OkUQagV&n+9@G0;q4^*6#6oKUd6m^tjZ} zIEA0a50y1S&ln^#iBH>J1%v>BYi*{el=q$tps6?!O4YltzAIaR6eNb>uK)?F3RsUD?|Fpy= zv}H;&f9^$Exxs9=CW48$4aUpsbZvJ(G1*kX$fW{W%@JjeOPrF~*#K<_0HYk>3o ziS!%+!dBt0poe@4u@~PT%iEl{bIqZ>``Q<9IpkuyI$f2N=JMz_jI7Rwk{cDR4YebYA7ORjhAi;NH zO!%*u3UyXE&Ti()X6-XFLkSROyc;kwzu`ud1ZKihx|#fkR@4H?Sm!+!f<3aNCt|KT z;K^>^V4sWUdSv8nP3{`~Gg>MGEXU@mUmW%>n+V z#p3$cq3(C_dtX7b@jn!jj3n*f{ePsrWmFtl)HWI{KnM`rA-GF|I|=UY?hxGFLU4C? z2=4Cg4#C}}ad*BZlbK=ed*A#0xNG%~?pjsVr%vs&<=M~PXPbsK?>R$*KhO zT4>dao!gtq1~9_xT?q?wbgUcXt3tcWbBbe??SLVV<~4GArM%xb-lOHEju?PiQ$J_<+zq z2&f3&KL1`%zrvF&$J>V;+7_t#rTdFXy07nWR^R?v4@7T3Q08Qu`uCe9_S@5yXn<}@ ziqSYd1|kf!t1fsnjoh6St-w;=4DlTs4Z`k9RjqFKMwrRY6A)UL`p=?z1I>ph^(Qh) z!NFm%JX+M#Z9n}N(|!Xj_7NlpEyg_Al$Zv=2qNR`K)GtEDFAP4bM-!q6LlaU)zp(k z<2Cp?iy*~1N@2#!pGunLs6ez%k{)9NpDgc3!chuJiiewwzW@B+y8^xV51`0nNZ%7uUdOo{ zWWek3q7ycqULO^M0(rL!-99AoFOJ{|j*ASu9)3XVjN|oDk{>+S5VqCHZT}DNV{OE* z_w{+Wa-ddsBwvYDJiclDv`|FfzZf<$l}|D{*w8NwOEG!<{C*)k$pmAxiIxn7vIYj1 z26hdimAVFY<9AHw+6uX0-v2#0f+rdLqSHTeN9@(KoX~v$B41nv9V0~&2?H61uEf;M@NcP98MT|1{TTgW3PA7)aG6yu zZ;J~okPaQ9}OCJD_Lv!o~;-FDBF1$h7zT3g6e-BgRg%nJ1n!<6Jw z5>|lnd;cQ8gI4cT2OY~pduVrj&NJPQ@=SUT3}H*d+SM}aTM^r1ZQ|o?`kdC9#A4H$ zc^}Qui}WE)7BUtJZqpE(p!67R5ppxUf2VuhKb}1p^^ufW2`a1v=E*ivh;XVb7#(H- z-E!*Q45%M*MmODq3L#_~Em^07RzEbcHoxEozVU$kp$Q56#^z<@-umMG3%-aNAEw`k z>j|68puiElIf4dKCvvD|@8UnW)Nc$5GJ+=<{NfW5)Bl^LXMs!MxtR}+QO4OJPR4Qy z_mf!FZq^(cStv4Rk>H(60xl|k7d!zIi|Jft^(yzQYG%MB&`W3?pHI3p2IjX{j1GtI z7=T`ZMb(voTOx4nF{`*#at-fiUSbtDE2q6IX!)yC>dsC0w`bf$MK}X4u^B&VeJ#&1G@K5?%|k`Jm@m2LFP6l{W?^ zE!(`mc!J)w#|x(Z2Z;j*%4zDyu>;>%OLDdSBM-=<))3+7_g6=?z5~^-9!*b|D(RYyr^#|hQ|M>Z@L%tjeg!&`5*QD5%d%C*wp9ER!FpJPPKr)T^#IQ zOZoxbf0x-w*$1J(;Q)&9J6Uf^x5f^sTnho+!ugkwP&Je{jq{c2Th%80kOg%SM1noM zADy7wtekQ*aS#uDn=Qkx@l#gVY#^^r_5}Athc?P2`j4sd^ZrYMRQ?wUdNcFyz<5C0 z;;qw50HBNid>6oGkHYYv+rHrI&utf3N!62@IJ^?1|)VfwfVhA^(_XIl4qj(I=>1b6~= znkBhI6l1BzeXrI$9w48BCIf_u*(d6Hk-eV8U0j5C3PEGaM=n z00;iZ4N$t%#rlsl-Sj|{Q5XI`iD0ZC>wlv;npL_^oE5B&Io@Fb- zlaO4?gVE96*sZ}0`|q}|4I>X|IZ=8`FJE(@GWAsz!(l>8`3;`zJHJ2dcqkha!98nD53C`!f8aMnDY|#G^3B&}RO|*P6arRg=onUg%Vhzia&kz>AzV6N)Fb8Ol* z+Jsd;(){Z}-2<2#(prikD5|e`%m3|={8!Ckqns2swDR!|!SjRl5IM80Vhi%9!*=2w zy^>Ybt7Z660zBG(I!JnQ-!4lzOqj=ywFdmEp_2m1#&F)qSDp@ywpIB@eVtcq*i)dz z4)S`d!#rfQScOu!j(E>S^q!DJVj#wOtj_p%{`dqgl)=Utt);|c?d_&5$F-BN@-m_^ z4hKzq%M7qb@22wqEdPoR=&hbt{rM#NnMbjF4v+3P&73UtqG5vUmWxYBd2za&iX-V? zBgpeQs@c_ztnAt-FL8!TP9C%LEf3g2aZ7Jxxt_

HXvf-`OsnW@c$Oo_$|B*7TlP z@F@VT-f6?Y=wzI6pQGvShw*jiG?e-&_P)CYkiE^V#clZ!a7d87_IcUq0(^vXGMMl( zE`q@V0`;5Q`&qZAA?POdd(Ngfe9>+4#n?8Rm2LrsXEvOx3-@H_ZJY-ydzAS*LoMSB z?8VqH6mlFR*Q+Z}Bw)Lje??D>4Rix-Y@S>-JoOj!4zQ4>BT(K#PPdiAP-%-RU>%#1 zgY=u#suCp?40hf=2RXG&L_}oh;)CghhIQ6f1+DAz$g@wB1#;&L5{w2pc9#PYdPb4F zxcP;as?VK562QpJjD#x6hCRyanXI!pT+w!|jP-4?TB(|4th90t41fe@YB840?%INz z{=lNLtONmAQaG@b6A(-6@^f>@;6lrra9F3U^V8GgjKj{OyX6LSP%1^+qFjp7fE}i7 z6wpHZ2%eW;Twu;d-C5oKlG{913zdAnjJ|n+dH>P2@k8J`MCmT&q;?3?tqrK>9=pi6 z1eqT0=%L*NM%?*5nTE{iXE_|EMaSUVtWror{=24&{=uf~Ob^0*#mH{0jF&D1QEqu7 zn!t@yDI?;_rGM0S#d|0PM-?}>6`2N*SqN@Z6=QrhE7YPKnVhe4=Y(}CSP80DX$7Py z|L_%^=t+bwHPRjYetCjR8DGLI70$&3@*O@Hdo&g)XIsY4M7W1{NhsIDBX`G| z#$V?@51#C5h_sDhO(gp2suZ>XTW}1Xg)g^_8<+V9Ufy-Xu36HM-N1=acX!s>i` zjV_v*o5~qbRuhT!k!@D+%`=4WtCuj!gfHq#mvDl);A;|`8laSyA|)TU)Tod%)EN(P zg22C9y#ms4%dM6NIyW-tH^0}jrao=NQjtR?KF=bmBf>CGoPc& zc$F^XJdq87&9J!~d4`gV4;XPmTO4&B>M*++>vGZi&*cm9ISGeo8A;UZwObw(srxOgI4{hLRVc8e|r}m+5DcSqU&yQ z8*3iw?K3l^$vcCL(;dW+mSxKEZK_Qi@y=v*QT}KTAFk0=)cps~w1G1tAU0hvQq(m# zT|_(mTFa1uenK3J)Oqj*wxa=*ee;4i(v8WB&N~>GNhZjdlwONwHfEs=UtS5BAEsQJ zo-6dPC%L`M4xw-%>iF35c|G@$+YrXjo3sh@oexH9s z!g8TV0_XE@%#3N4TJg2@_J$IRz7?_S;^)z>Y%p@Y*=a)Z;tiXEmX;TjIEvV7Frt3cQD;7KzY+ z1ENKVNZN^>kE=1A(xH?|SDjZ%8R<&Oy$`Tmv5zd{6&fo^+BSC5w zZEtn}uwN^xyrIInzR5Hi;B~-?>@^E*bQX-@)plP1IYA#SGz}nV90Ocdg(%GlTy?tr ztCK&1q`ZNsk|4;K7C{HBJ7#-z587wDJ0<_C0&pcjKe_mytabHP{!1SKChumUx)?y! z8;lVCgu&>*DBo>X>CE+C{}LEl`?odUU!MYL3DbMW^Qgg)mU1* zYtP+RkOA-+biVLF*eY^7)z!>SPDnXjnNltGY;%rLoQa)cN8P3)y&Ad~%LgeHdE;rN z==lFzq8*4Uv3SjeaeV*VUAHv3|K z&%kODVLE7oNYXy&e4cVIeZgPM&tQ%)LpH=l>hnb;7k8G1Qv`p-)WsWt?mv{+4Pvcd zKLv)_a9dqNmK=9E`OFe_o<4{(Ny@wYBvf#+?h^hTz?`fi_zQ#IwRd*V2NJb$TniB_ zdW=DJQA!?t+2}g|%W(3TE_Zwhhvx#(9rojy@_i8Z|k(NOb6}kVKF5ze8;|zeJI@A6_ZuJ)^;$^^taK$Tv@^#$4C9;W*1gqYJsuP9 zk`YtkqQ*@#4&6D|WI`C8i-&K>a-8&7xWPINwCEB)Swm(l<9x;Tca|@?+x(-)ok7~ZY(ftzsIl%@I7ZEI$pyRA1kkLv&&mxek!!ca7h_T8PXhO zqgsmLc-VE=TK6eYLoYVKt|5GWct^E}#^geFK+&Pb*h+;Y(&lJ}ReB4J1J3?eFfHT= zx)Ses<@)Q#Pb6`pq>p@)1|TJ}utrAa7>gU!n&~5-%}ze)4p-AE zd*9AV5omJRG{f%D+-cD|V*r-ZSo^ZNBZK$I`-LPDLi2_D`&62sV9;FAQ2$G9wTAd& z75g`}^-Bv$g^tiN601M{-2gQO|DH`KerRZk^U-abbaa%@=z{7A+DfhTO^*Q8ioryU z7TY#1x6>apD*?juA#^2HY&y`$mn>@173S99*lhl<-^1wnl|C5zqCZg5Rr_X7o;e z4^`En=gU@zU~}q*vDitF0-vopeBZQ;`zz*+z8~b>$#Z8A)6Ufw%SyBbttc*es{=Mx zx}V#h5wgH?dVpI?XIG!PG)mPDzwK?IHzFTJ&Js&LFrLip*N23>liN{~E$RJlG^*_*?*S)?2L#=Fv+H}X7UY?Nv$pmnSTnG5f|-~R zc81iFHpd4IR+5>z*T-hWT4^KXMSL z0hy|jKi9r(up13=`c+~G>XAf-U&~B?1a1*h+y+C7s+G~ucX#g{_x(YCEx*1_Mbqc{ zvq#u9&2s0&_j;Xh-<>nru^Sn!R7h6ce*la&W{Hp6plnOue7X~17rx^%Fw}I!MFz+d z!`;x-k6l=i76k=KyNr2VT!<;{=<{^D7L#L?aYY0jM4Q(osh_;}%E_689Bkr{d;46a zE}aM&lmkh9d0*bT2m(-NF7U8=Q!@HSwI7b!taF!wkPs=MlE__6!!OFB=zH~wx9=Uv zO%d4HTumXY{_Wg}+k_`)t8K?*TIfVdwP$eQmP~0KfPau2W8-I3-rS~VP9sXSALf`z zzrb8+Sk_mn{r}Q_ajhBP1ZrY_9sv$vrk0JG-xKM-(0*ZXpv;J}PHOpuj?8-k;_k+d zn|!(a!`Ur*ttB&{j$f00tth6EDT`oC`wr}~)=WvMV63Ip!l5N?z*M-;@f*q7xVo_R z`oaMO_mK5v?t5MU!l+hI@Lm35h!zYf^ymbjx zBi0V3M;l$4`%Vp+)_X>}&4<1SKeQ6p-m1|j_OLa>-cM2l3O#84;evndu=7Ai6 z{f=7{U=nv1E-wS_!b|fGjdbH1U?<+@iIqs5!)tIDVaY1)Z>#uG`-SQbFx-Avb1kAC z;q4?wK<8psm{ZWXlvIKcl|L;hMQm}m6@p62(gaEW_n~dh*~y{@du>T$VhRm;kEi3VqahB{*(Owg2l-bq zKK0X*nXOK5M~l)P*Itz(jaZOeoe$)hFfAd+f#$7NPZnUj7v#bzKk~hMaOe`o%ifAo zKeANQ$KOo2qx6PWcT}+8Ne%<}H@1=D?aH8T>JXS?^|gH(-_*lKbXcS}o|^T$x{<=0 z;IQ+>57@fPz~0lFNLv-i+F)tnt>WzOID`Gvr|Q^OEaa7sz$!c^4y2tC?T(z9z1bI$ zV{+ak3_{_idjE?(+r8HW@X5o*n_;+X-rL!rKA5yK^wN5Gs^1TFs4}DKqq@plk+59M zAdMxkolm667G|EJ!+;f)vM0t{OFc5-EgN7jl|+y2mG5XG3R7-I{*}?;sbZXhF;Pp031b#{#a&UhDHmcM{QBHIj zr?%^_jFwgZk-xXwqxi*sO*}F}k!%kH(e3G?uPtJM*3I8Re_W(r#?)!u;^q-xJZoL| z;rbZ3TLLzF%Z@wz@vQlK2F&AF%x$}XCaecrC(ukT_P#z#vZ_58ccXXm@8`*U%u>aM zbC_7XdkcclGE{IG4{!YLCUaBbq5LB96JmeW~s;)Umw`cc^*(i+C3@-sL)V8LF#*;DsLdmA)bfRR-ohA=2`(WPh$VrtCZ_3AFzl3BwaD^6 zndi5Y&vg8gR;Yt*ot}|{g>i|sl;NC%e!iNfKime84?bjIp~}1u)E2K2e%B|E#K$SB zsFTCToJ8c4@xL(7qp)Y6xE5ij(3zMX4XF^V=CAx((J4BaqU5awH* zFL1C~CcH2RGDD6X(T#El+JTuBUO^wo12EP3WVk!2599)bsv!ogSnAeivC0_u8x>j9 zb@pq|UXoL}@9DaWj8&GMEson3eK7a1SkK}D&n1eYS?6yCRjLLwK|gy)1y@9-x2N0e z^7hWbiN6_DQu9^*}ZsM2^uSx%`zOS>BNJVa>@6Y3ow(qyP9NPB^kvCzA5FhW%1XglM^!+4cLmrIpP zvjC#}32Cug{Ekhy%plAJc{Cx-HoZ8N$GISTLq7%6I9N}@| z%tZ^@DX3Oreq^iL7xhPEdyYO8bZ1R2({`QXx(GFns#QwWSY&S0I#;QLOiS4p^R!%k z#uU9@1soxfiI!U?HLcTVW==aaif3kuym^p|6$H}66zonZJHd0kQyNy;Xiql5CK9~$ zBYQP`mT0#{mhY$;>T}#R$`wk9dJ}464tDt`4LB9dJ|7*(=gn5(FtRIV+*QNo-I0ZB zAXbRQJ?tlsrPf$YS%Jz&mOdOs7`W2h?m}$Q>J~m5D(!^ce3)?MU2ek1^Gv1ur9qmv zJxD|9sC*V55#{^6#7?Qj;vx;(W)ykS*|q(cvYX7pA{YD-Ps&6fmEEzOy159KUA-m|eI%3MC##^7Cg9-pkqT$5&|o z6_~`U{jLFsXg;|~Z$VSTI`~MAokejNa~7Unap(h(TAj&1S3=sn{mQb;0`|PO)OU1@ z0&V)`|EmN5;tX-^JoAb#s7k!oz824L898E_xO80WP#DJ$^H?QWrm) z*3FmWST473p@@TYaH?2a#5%+7tDJXGur-@Y0c>^4Zg`6s&u%2?> zG^0so@IMxNNCg-?WtPk1@V_LmR*5nCO)C1TOnwvY^e;C2M@p3~vW@}w6KXkT@27Iv zewr%%1u&4Hd69oshqXqZ5xKF8KB>FiMNp~qZL0D6BG2j&7^cBnF+K5O?#|Pp% z(T$L|u9*`5E`E?%XY2)1x^U~hyMu9gPKOnM_3{!%E-w7viXZMWjeh=B`tS>{x)lh% zmR5aD(TfxJ?Czxpr z4QA##b|;@Dd~YeU*jnoMOz#S_eJVjraa2&piQ>;OLk}tl@+cpmJe0wcuOP_mn~KMjLzGCss$A!&>Me4fZOGUb zYW{4snDdC+@~xGXi+LCbLS23M{fuuBUswQMS)U`_D)Ra&DZZ&rB>+tVAzQ0Kb4W`m zx2Vl!+p3gXf$o6sAK%Fu0a)B|=x)M!U?EQ9A7xX8(yk5g2vx}BDaCRX05X~Uo~C+U zQkgxa9Jr>OuEVKu3Ixs=98IHs$9Y_eSqZI1rYQY?86lrL^c=$yN`!*zp8^;f7lef8 zQn9?Z@-sCWzZfkv1XgA&y4od_QzP|Tsd{YkqaVZcfMoQ)QrBMn{HxsJC2Q7I<;3Yf zJVoZDf@t0ix!k-EPT&sQ?u^lW1a{vrlf<{}?$FY;W+egIgu7lis$f~ucs4js@8q*^ zn=SM)_7v48_vfdBP7`MUZ>NDa@bPdTOgUQW$wOb79P34=9sz&C{>A)g+aw6LMA+^3 zIbOp!1fpW)>!-cdNbY}#DY$x|`-x%v(h&xiBk|M~52NY4F*O+kqsXIQKB~PyhiycJ zJRqF?BnL^DC6!rVSHRs?fCXsMq{p(x^aFY4OMBJ~Z# z1v58flmU2*;b`XJw)mg&m~ttJi)>a9xM*-+{B-M7V6{phN3RSA{3J2_UofSZ43LHr zWxL*zuT81_#p+ai+_3c@Ts45l6CQ!2gUa&#KZk%{qI`MO2w#$@r=yQi+cK*>{{n(q z)=2SrwoP@=yN|cGuB)cjn%>x)uhL)?p!@8Uzf?PaWoo#mr>+DF28h1oP|wX^PvdFs zUgyZsVL@{EV@N`PXMn3T=X{}UZL|bY<-XBUTT#osUr+oyQu_@q`VypjkjFl`p@>BF zY-~YV1@IIqChz&IE0cawo?(iPWg!8qvYP*c%J})Wz0{0@*4~k0G3INa1=*~T@&ll20Wxqu1U+Rt=2_f|YRVwp5q-v(c{Xjt$a z!eFq*9KllIBoi`vPE0d>^7$rr$0f#bruVaPGa0=rzHB=QZLGn=FlA==sjZa=+~?+9 zY}YcuH-=&2qNlpY=Y14o>|$T1@9X=xTd{2hF4>ghXuHo->Iv^(SL?KSi?`)*h9ok? z8seaVaF&3ODASp#!DSjJ2g(!YkhxRX{Se5i4zjcb5E-WF;pq_2>dD^dRtg!;p|2{JriaH4qxOPfFLhy$Z=htLyC5I=Jy?I0lPGg(ST{igqN(R2Z zRDHaZiMtenQ6J$36ggK58O*iQ??&|H1&%nout^~yfLs;G(&m2^4CBl0?m0eePv}I9 z8lDRYW!F$+Z)OKKyuY965==rZF9xQ03lFN9)bkcl{i*)oO18FpPbC=w6Nn?WDSS1K z1Fok;^Kfy#uD%xUYZg|VVL4M#Z5L&90pb2m7$a)ZJ7^raB}}G@5!-VKWpk!|Pwnn% zCa^cOX8RE>oi21oIqsxbPNEgnRz5v$lyv6DF{s$woR*U@9W4nn55#g`O)-XK9Sldb*+ybFT-{sV#9>J?D{d zm23iubM)f*A`F;Svf-gJre$d!EKD|ezeK>c1c_s=j1Xx%-mpaf2-`$(cP8+4bMPj> z-DN*TTjc#*kt!M+yQbe@0~?5Xk#%~BR98%DP~{O?*g}MiJKQ@lX`+Q@<@Ud1xxE62 zKRAFCr%6l}PL>(XeVbJ%tTQCFH{90l+^$x79#r7zQaUXGsgHATZ1z`gt2UvYHeY_@ zqFqg5dmcEQc@^D99|UVM*q!c5Z5o-i`qT-s%FPEX@BgceU3y`TdR=njOLQ8~URTe1 z_Gz@8jH68KBtzbvLYFb(yAnVaXCBA;G%RHCb^Lrlt1(6ycO$~Hdkb{Q9cLNZOy*uR zR*Hy&iVPz+mpB_+`C2vV+*$kMwDYeT_O7XId}T3NV>pWZ8*@qpTIHYtMa9et>CoW;-W>diluxR}HhB}?`-U^Ry$GZd8t;F_ zKWheo4Htyb9FQ%0?)iM?=3>ScRnYx|@?a0Xpgf!Ip1p7S^@cR*aIQ-p&c~Q;hB~#`><3J8`a^@L$~YR>7B%h9+dL_fG6cz? zByz1}#&9MSQrgh|r}HyvmS{y^dk_N(0#~FEs0)7VGT6nY33svE@-S7=OTzyW;&Z;y z(V00$BF7}t2nbvVsu6uB_%Y|})LT8vF`i-r$n)@+RU9*E-6mYFBO1w%>};wtojRFL zPpYIuS4A@nZp3*EGp6r(9bSqWY zp;MgI`ItV#03z9B`AF*rLrrc!g4Rvmd-JSOo!&F{9n016${{}{sjYu1J$YQA#FW5Q z@LEU=?m1_TqKqu}M2ez!&7-o3&GPxPeQuT_?=x)(tt#Yh=UD77Lp%^F1 zhuFJSE!!febUh@<%cR;8QO@kAl@C_T&VKej59$TKGE4rrioba*==u-HS~boJAi_kdt`Nek^LM&o;iNG5TYU~9v`%O z^}FsLhXSTZrNr~g8HO{|irBCQ=L4ACm-CDRhC}CCNbyM2@+ESonTcx23Bis)RHvGc z_w^^H$8<^MM`RJ4rO4D2DVbW_--y13HJblog2XO}C~_|cRb4LWppax_5-JeRg<2m+ zLsMBg%h%HQG=eSXG?~M4UL&&f0zGs>;vxAlk38{zL(4p|O$?@n_1QXm3%8sS-cB3vdVxiL`ZE!Bv;A$Xyv7mY=|B!)1$YaI)24|L^i-W< zvN@8!oFbvtg~{vax>&YFzVqZQEEhbpD3%;>2_`1ib&+OrUPvjkfFmNW(=3G9#0U~9 zVn;Soq=W|-QNvtVa!+=W?NYCW;&S3CACNWdBW2=|eoV(w|4aki`phOCa)0Qc>S`bj zNxYcgW^&66hk`nXNVVarAIzh>?n-5v$M38?L-9um+i?RvVa}IxtzS-cv*r$Tiq7d^ zPQ?o(PRAE})MxD-kTb0c#(SvyRBn$N2i(&{nOsO62W63a z$p35fck8Pko5F+R+k-cgy^7i%r}|B023%Zb9A2ZBCS*fXLE0`}IF)Qj^shJtp3q+8 zGKNB!OyyE<|HS9a`;St(oxWL3p!JBDW{-K8G_q@iJrMe{Pe4*mT9pt3W3-#e31WEy zkPXoxchTol(zlk%NkGnJWOEJD8=5CMri zETBV4-bsPrT6{MBf%sfB$0CexwA0LNeFGZ#SH(w-_2 z)|TPGi$2hbOc z0vuT*h)hg@KvG}d2ZGVvrg{Z}@t#108e$PMWyW~_)cw~sHlr+gf;g3mv!%Pi`1ByzF@l~coFgEv)qzWZed%u`^omE#0}3ss_4Rky zwkF8Rdh?_khVQih3%sWz<6piCuv&r5%jNobV^q`C3s~mUIrquecKTE5>W|+6-E4*H zExKR7!Rug<=z|0ggx+gDN8Oj?D-t3fV7(4`>IQ?it>~*!q#KLpu##qq34yERnC)&k zpwVanAn{hGXEXuwf0G^lqD}Jr0yp43gSz5+WYAEq;4>*?*x}2zez|aq1Mm{rA+*>> zvuMGTuH*h2Uxv5Qfy?nI7>fcKv$+~*VV6ICH}a}QjZH7ffYS&2vL~IQxHoQchB7fD zMKb+Y!!GX3)uKiMP1Pl3W{PJ*j2PUb@F(D|CFuR1=Qs3?01>5l4yh3~GKOdx25jfR zh;6iN{QmPh%!v;8#DifYCGU`0g^$YI3Uo+U)2>A<%^xO#A>61XYGxl}uM|>}_${K{ zLnGBbW!IFVT91viTV9J?+9^$dyG8&9S17e5UhtN)xSst+{SM+|6QYwVHr8?O>7q-y zc@o)7)~CYuJXT$|76A_=g7gp^P`GH+m=1hRNF4FgKfDRqkXV$gx@<>(i!rQ|eYPo2 z-|bkhKy*{_s8T?vaeqI54azP@IoP?VNv9eq&QPx}qSMKlGuDXuMZ3nu=jmo{`XLh2 zTvu`pa+M!@bnn)M9J( zrB}@JT1dH4gZ6nZbMEBadJBo}oQThESZcgnKF$LeBj!SOG(<1XMK({ZOqvAd z%m_5Y%DEKjJ&-8V@l-=hiucb0`CyZrrOpjdN|yG%1{H#7wBiA4nx*V--a9uTvc|eS zb2k~;n9m&i;YcXe9=}%^pwFQ}B6XSf4dF6)=^17wCFN7X&S_)XQF1F6Bv(nC z;dL{%H&}y9p4*|T5)t@Pk2sopB5~!%QhUJ3;65Ez)UgFNuJ2vl6^YrL$jfnf4p}6hYjI0!lC&?IZh(|P%7Tr>M&2)O(iy0@0MA)sp7q24=@G`+e8tD zETEm*nXCXWp_=p87XC9&YY`PjB{O^m%&7~MjkSI(Y0HNP|F za?rb=(Y3q2tPpgL z3?OOXW*0~rKm%PKlBE4jIgr`Xq9`I)m~{__cF;v)yQeNgK_RRJ(hrc#Z;Iw-Pa7$Q zX?PDR&~h`^!Y@43?`Y>k=^IUb;r{J0p=;WJUdF0nP8YC9_0q8-Q2WxUim6yrWtFV7 zqhB1@zsmmGG$y=*q>?D{_j~92uXfBTv_TXj9kt>ULa5Ff?F0d%t@ovfS+(HnqmLsd zyPaQ=Q)+eV1-lqa*0vAo9gl?5%lTZp%N~SWAHT*%{HWZwZc0;`3dSTHEs&h5#pEp# z%}i4y2n*AN;T!C+ZYKHMc)F;PthQb$InhcEr+cm?zaO82J396AQ&d73s}>rY!MMN4V{F$pnJXH3WS zB9Gxkl@W;qlsV?j!0r@$Ju1h@_!h`>Z*AtNT)Oe44fbd~5SR{rcefZW-SCsoTg2Er zJ+GdXwqQy6Zn4pbnAq}?%^z`9QNxfmgq6!L-pq;|efZ(OZkS{x8)OJ}J>_*($YNiF z65D<2_)UWrNV#k)^5$>r4XG=qf}vc5=ri*d$Gy1DX`Cz=MHq18s)j>zQgAE$^j=YJ zg~CwfcHAw$VNK-knN+i|?uES*?H2;>v0FKLjJ7PPdmohaR7pAyAc!ap;KNO7&_Hr? z{T8fSpC-pH-!o}nbVv#&3oC*BoTLRpZTQ(mW!3gQ!I%Rxx|7-UpT1^Q^`lz%m@x&P z>aq)yA<6f=rt+R0(u$`{C#NLKo!>rZ3`*1A5?g%M*tKpVTebtIbOpX^OM2Ukm}#WjlJ9`wfl}-38%(aNwuX;rs_q&;+0mTBG1Ged-%ts{b)DIe-D9v?-kssvdlviBd+j^K8O$Y9?9KN)YC)%M@ogFCyuD& zBTUx=RQw$ZNTX$245Umd>;wsXCVmq7DJrg%j|h;}BpKLFd>Ty1szv02q*}&8oWPAM z-8a>0h@S66pxIzpt8;}Ywt2V2kUn2KayjpYey8d%!Y3={M0BtcusnHqXI8+ zp0_J}i=b{PLq7e;qY z&RkD{Mt1~>mBfD5HPI96>sGesQQQ;a3JJD#k*WLCImy#O7XS;3+>|CWyiON5{{ZLR z9o_xC2N3T=>hnB~XAYc#mM@)g<|h}Arit}lnpTQj-n)0i8k9JRUA1UVjf1uQRtz5X zv!wW8yvu1$&UhigD)nmH0lY^}v2&S&zV~a|+<#AIG_}(N+@<(gbg>arSCG`wxOv>T zCh0xoN>PYn?lt8|Zd@$=J<9=<7C&szx-=>VX zt3JH{X;&VftJt4E-|RB#!xYkKD?X!*^?+++23TwPkb!GvVx`CZL;5_S{bP#Ph=692 zw;Rk+P$T0^^=0Do3S(T)vGw$&L9&aos)tGWbLGU~Ql--9PEekgXz2D?(G2Qw|K(Q5 z&Y_C_VagsIq5N$eoonmLmtP6q`HR2)nGJ zt{zW@E(cmzn)_Ya@?0cp3_v-$KmJ zh!N;yNiRT(PE6oA&JNNDsa-43vb7+xqIC;=zLUTX6Yld{7W zvfzhvK;2CQIyF{4BW6hez--6ld4q5hibj{s7nb;lP4@E-hY60uV8G;0#aL-2pZbOY z*)T@EXDTXk3_iZj@G{&*&c07(G zA%|L~@tT?2kdN3L0OO_r_;s}VxU}QToO>QHvxO$|4;)FejDvUkmxEv0D-*YpHGSODP>Y*B&k#* zYL~!cHs;(Jf3VD`|i5J6Ovj}z&-?eQ)Nu7HZzCY@7M1*cR`Bg9%I)GvRUGb#RU|v>e2otYe zOz?qVmby%7)T6h>@_7$S&pJk_#Ia(sWR^|KhHJ;IUeivW)#n|ZiWiyf@A;W=m(e87 z1qsPQ0;&!8`jxW$ZmtM!v-=2=l>T$7*!aWdHJ!skyDsGe*b~SWmK#wyb(0Nn+0!8vA{K5*C$Dh@9K!1*_x7=XVHJA>OAd{1$|dxP zT2fr;N9p!Qoe9yqh%npY4J+go-5p%mv(9nf#NIgC0i6KzRo62OZ{#qed!wTD=1^8A zF_t;zJ+$0=QZ4~3!tox3iiUuF_K5r`C5Bj6s-qPh5TXx4iEa0$+S=F(n>&fQjxJ%$ zshrcAu)U4`!kf>b%*y;UN!WPn;z$;-cALemCY#Oc1CeSfl+ghkwo zJg}rivR=y+12#|N_iF?y;-0Q~1kb>4F(i2myq$33xY!?Pn|7Xux~FZUiU((eJ|j_+ zR;u^!9a>j-oKVwI6o)F3R>D*b+(k?-Z0S9(s%kZ@xxOnyFD4`n>$Ro(@+JjtpjH|O zv2Pw@C=^xX?|Bj|20q6!#WCa8`R!kudPgVJr_vjG_5rouY#A*Ke=2o+YS4wR_I?B9 z`S(W;9Rz#~V_Mr14V>rA-ybboXg$+6)Fx)PDQ#WH1XT~HkcAd*;cVG7`Si=1w$JNk zf_Z8+HI!8;`A_f7^GOotuIO+-H$D$F38p1V3)39i8|-h^u+P-`h@8`g+`wnQ8=rl5ksl%O zEfhFv3G>D%H__p~pcRoGh_SOx`n1|!$9u(PjwXK5eh%{dgdK_!p8ZI+opTZlFAvPtqVfwUakg`zwUW`A8HY6m7N&|#4GAo`>t;#o-!^r2lq&WW zjXZJ(YQ=VCb<>CjhYQ>Z>7-Yc;;$+2D0jbo!6ok&Nma{tfmFP(CuT8o z8V&tO;1*TFKmk(45iznOK8^g$Y4N*tp$5Ya%^GshG1>}+?Prr4ZT<46vr>HBE>+yy z(#alg$8W#K7*TF|0i1@<4L##)7pLLxeUgwuDDcsXv+-b>k&o!VZ z{vX=jIx5O8Y#*gj5l|4329c2NE~UG>lPe(6Hi?2 z`$fvGC@SOE*z}T{U$&)ErRqFMD?7^9Vi<{aA)=E%`f8iHq3B-v_xUzwN1-d*wX*eq z*nUrytkXIH3M)e=^E#32vY`l&_qnwdmpxxVi%ZRd&0LR;a1;?^&p7>j3Li1d*ke~$ zE__|lc$=`_YUp>9P*LBGTU$F`b0L%m>Dk+~P~VN#g;&3j8JjFSx841Arvbsf?6=Hk z!|-BHT_2-7q~tKVch4-5ikF@IrrVd1PO(;v4!yXksxM+A_ADY8dvj-t>O(wKH$?7K zw8<~ydgi0ewdodw?mCId;WZDqoFQ({^!Kc;%x1$l;#SRF*={uUf^w6Er5~Oel5C844 zUd6&efi8m`a{?gHQmAR_eL^7LD?+Iilub~GEiHHXzDiIfR`4La4;Q;5z#1)9HqX1T zByzjo=(iz_iL~D^_zJL+kZ00zWadoQG|iT;sqiYZ>+M-JEYw8TeWebIbQ9;rjT%uk ze52Gt;ckuXA`xya0KH@{PYWtYw<;b9p$c0mb^<-E6aS_gh3c?MaNWc@TbLL z)=p@>u!C9K``+3!VeD~+)x2?DRW2Q)18YamimXR|d`=^n9LzGSF}%bnYKcA_=mA<# z)oRQ~7tHm@*lr%Jop?z)7vps`1X0r?#Tcc znApz+b5ox^GM#x-3L>QoyXt>Cz-;;50M!ng7~_iJ)r4LwNvbo4!{dfy&OM4_HCGpm$YVMv+?^hN)|P8`{4NCQTgnB znGg8xH$R9vqsOi~N;OnN*N1@^rXgAmjsq2%k_VOFi}|5bucQoWV`|UcqNfIumt^%s zao;9f{_3HL-dHe2q*TpUJZ$CYZJrnZ=3hg zkdwU4iO8E)7bmAMwRR=~smgGb=|`9`XifIkwe20~;_=8RB@Ybv?Q!F8o&UOt;5FCc zYb$H@ViziH44WRTeg6zI;&>g+I=va7u<{?RHJ4_BxUd+{yE$VAh` z&k%X^^_^?u`VmLx3hbmF0h|TW+k72K(;+e0yDx0zP8p*X%ORE3y5+MeR@^@*q?sB{ zn29Tj1asK8#>UUVd;Q}*)~*${1ted}>BF|M!lw5Vq`R${%8Eu!{qMe<*KHWQ?Q80Z z18vHhWE#VDNXeZu#@$8s!p;~un^fp&Cympy``zy-f(W*w3o>+Ef}FjpmQ|UmcA=*^ z$7HR;mVzA7%sdsT;s~koC`+Ow8n?{Q&cRcn7MmBP1^fS#42zF8b z>;=%jQA5$!X>$V$x0l}3ke1h_u*{~JtgWzdJVVc%%2`|*mW5xt)O(Lin;0gHUA2L4 zDR?L=s&xY)3hr{7D@J$8yGh&nRQoCY13k?YbMZ6tHAXYp!rm$fW&nf4p*h3G9`69G zJwdMJm24C3iGIh}GKK=j<{`?1Us2IOY}1r|{a3?uLw4@oTnjBC{^GD)Op#b>2&|L5 zn-&dJzS(JSimv0HsWrM{Nt%nJOL7AL73}10U0XGLD}^M^9@9E)Xl}>Ucc50T87;Q! z=Uth0vLzk=V~EKAXG8p+Jf$u)3rom5P22T#*h|Xe&p6hwv%MtgzrQ>0l>M{|>YLoj znj)`=MmJb`ZXk$vBjS|umyrefKD$uNa*RZOKKeFY8?&8gcviCdcmq~*(;5HzCS@e^ zYR+Oj{8amOhoVy^1(l;?g{@d_r&kZkerJvG@lig~aGlIJHtK{(>UWn4-2~@2*|7DN zl{ihS0{H>HzVeF?aWLav>^R+xbD~5-e}>fcN{gvmy~#?;Fa7-_jA>m%#GTbp4`2Zq zwstC3d-54ukfW{)ix-~<%J8)iIIwV1T~PvGzfCIh1-&#mSX6wR9?C^<(Z&u-5ju@L z-9sp;=;JjU#@8QP*chZ!%7m(gBCX zSeLIt2Zp)Wb5D{7uP(ZjmIw#!C8&qQQ|9SwiPb??RHbK%Odn3i(sN3z9?_ zU8UW#MU_=FyWD=O(A)zGyftP$H=2zLDcyFYI;({Y6s#&Q1+GweVIFi@`Dnd^#LWf#UrwJLUu<)k-iD2xvb8OeQA;2z=;OHwrGwyp$D8u6xr z=FQ^waDvGvFvT_;l0$4NpgrS62V4Q_a+gs-<;er96nd#gy*Y^u74iFyWT3N7+PqnN z-jFW0gm&6^DVJWg*Q;++ce1+OYNyYKeXI`o*`sWwyx4wpXqz@V6p|=83s8GRPK!2} zcJ4UB(y4frYS~i{p7Vk*Rl`exLe}A3LahHvCRpuc^ukvWJ^h@ykkf57!4wEf$WVU+*&=&uD?5am=1ADQ#GY5aZMvJnDU` zZ#4fkuf4NkI&hpS!?`_5I>)#1}FBS%hTXM$8rtB&5>1~nH0!?GD!Kt^5*u$uQdeMimSL>NWh zY+^4nZjszXDeT*4vNORdw#8mJE#%-rjshSZ_qsGqT~U1{V2Jg4dxzi{SeVx_q5edP zv21Z9-nv`;m4np@#bNAwCvLrfGT=Qw(&B5~J*7~=z6F5Md`b))IT*KD2cf55Hh2d( zVIF1IU%};<-l;IP-T8_tGrO%V7dSy3t2kfFY_M9?DCEt5i z&JI@X1O7rFcs`FuEwt^to9e5QT(xrN4410^4CrFqT8%i73If~47I;t7i^wscIFLmQ zInb?VKp`_d&BmX+R}8DXm<(zKRM21>-hG2;O zF+-O1uQoSK_E~0P-h`xRAS(;onKXwTXAONy*KeHO(!Z4Oa8I+0VOK4WN_5`ppE!J>HY5vd*M>y!w2~>pHn{Rr*CZX zEeIMt@7y1jQ8-x{SvFv;XPhJtcJ$oBCOgq0 zH~-su(lv~gb=ExPu>UR7se?XiNhZ<87#v>DF7?<|{auP=skxQBe(y?zgWW=SU;cm`mDsSPS zb()nD9B&?EL-5ZeDBuIR$0A27P-Yj#gn8xD3r+I%RiGyTJ3`^kIdm@I2LicsMCjBGNOVa7y4f`h!9;!X7qgsuTb7mAZ~zTP%i?a~vmLWRx+iE*iew?Xu-GG`c)CvW6(EAk z&)rr;zF&`#Hm9A5Dh;Lv?eXWecm>U^__lLP^veoljV8)>S1w!e5K zUy(~mZ_0ZW%@S;=$#FEaqs{ z=e8;vqfdW)rSrKET#CIeivPQRsZ%&4v1mAit&!~T`iFxoVX(oF9Tu*q4}kvv6Z(DG zP=?Xx2a90tK8u33!k{atQMW?vCScMl=HU#vVuj?~38T|bMTJ$je@sT?VU%|_Vk36Ql}px(oeTYC!fGZ%i33IG1vc9Q}4AGHPP-LlMNM0MA(vP zL-2k$D%6^MKYT-3owOeKO|w}umBn1m1opsd63{CfMXnWirvF&5`0(13LW|cM1iekG z7%3g?ya(B|`bE`)7LPw8WzsOdNazh0S97{wMwS!d!yK!u4{w;}k;HC6RC~6|8*P*H z#k&=>ma@6cAu3zpH*Pnyi@6AzEgIdvIGT#puWjRtRR!NChJ-(KOp?zdz9}2X$A&N$ z^h$St;_$X=hf;Iyo%YrFe6i*mf}a3AFSWqWUv+$9&U^hu_K$@VASq;^7$~_X zQPVFJoV6pDnqAr#558P6fZjHpL#IUMMjlNgJ@lCHn#Xi~97Y>6rAwOBb1#L0?d|8~ zHghokhfAk|*N(Hxu7uA=d*H#~kVYk2C-Jtn{Yg5p!ko@1w|m_Yz)%aCop+hOe@`<4 z34RV?i)ekl%4IP5jgB7;4Dr@_s{Lj5h|Ju~23CT+H7a8l&qtv}U zE)7(8?yfZ*;eUO+1S34m&g%mNG&hiWZY}Ta7k9Rw^^554VS)7~UGG^LsDxn?-zz_f zR3`s#5DI-lvP$rco0=^6yrdbaaD`Q-O6L(_a%##;bYUXOzYJ>P^Kx&p!;t%~Z+6dnD++%Fi}0QX%4ITeZWB zO-m3~z5(deSa9%9=)W9E9qj~ZB84n&ztzR3}uJnTa(mS#ZMR6a`CQxr`X)j zs%a9%(iFQqytA)@Xu)Yv>9$zT{tR#TSigt<}`wj`tdZR`(Ap7 z?zaK0ha?U{`_q!=G3*?h0j* zW&r-vrzl3VXGj~rYKiyB!uNy4QhyQ`E>`$Kd73y1!_k!t$2C{*EgG1%EQ7`T7EmSW z`^~H{rziLj#~U*~cdN>yrX548%pA!l8Uid_sxRj#PdQ5s>LS=y2WS#SHo+wgVZ-1r zB~|CGfZhawaFdE=W?A>l7}F@mQElX|f}KD)=zw$=H&d!er9Lo1iYk2g=!@+LFZND> z<(f^RZjbaLXUtgR5x>(`U|EQX-9tb7%+F^J{$#D^ON=1!NoWq1g-6NPCyvkpa2_vs zT3m!el>nS>FZnLNvQ&%*x{cLKvOnR>)6$<6qJu<){v@C--&TJPrNcEJ;v zn@u2oE5!LW-h?k%s94h&gmLq{Z{_tuEnUMlW!k?W)~?W&kha zxa%MtGT^w?cIT38P4+NEXpnvIfRk+l4G*Q^OydjB@Jyw@>WCNpp()yby&S$0vjQ1uY+#DewJ>Q*d;# zo-?t)Tf?NPRtfix$!;v#nC(mo*V&s#M%m=Zij5H+%rhbp>=vg*jL&CfR>8QDy3460 zp$(LlnAM{nbIg-Dr{^CLT*&T=7o+B6<+x?WniDStTu&D!eR zeKmtVy?bguxMI%N)t~5c`S&$*mUOzRrGivWdZU*2Td9;*@t;)8FRhD<_ zfIqOtK6YxjmU1A_BiBOXnF5j-@G#D^VsTtx7Ir8D6(kJ zq9!)QscQ^u2@vnOAZ5%@d=faenIL^mBz^!AxWx}L)4Uxm;mENQNgj1QAC z;uc&iYZdD0yvtd<{5(5k_kkDiyn1iNx$j!Itz;-hk!*;kc87HcpmJh#VPVuHwV2kG zR*+L|J2{pKLeZ+r4uo=(#%H5;&R2lqP-v!yWp;Efp--!92j^+qy?NbHxxR1AT;Og- zB`tOe6;Q-dg|3bKfF1yvM0W4>&I`6y(ySA0O|? z)FrVy@J(y1wvUn4B?m`sZ7-^N+n*b__E)`N#0ejogzF4z>Q0SQR%~mWl?xnSC9-?z zS9Y>~o}Fw1UbCPJLr%=JgR`aGDQP-jx7U1I0Rct9-RV{Tu6%K-w7x6;`v#PvX4w8SjhSvgoP3 z?OHdzZ7WTTe$v)e*P#7;S${UME#QCF)$cfDv2$~mI$=@@fyOqNGH*5)A6bH{W^lK! zvEXM;XIFrAUP)v1J5})>rWb-kTRIzKnnkKL^Q%LcrFS%&$2`&LvXEahhlr7#Xdiy` z>xjdey%Y5Yj0yGRmzMr%YTH4S1nwA#m-w=RI-tg(U+b^WZ6Osdvo)gvMPA>+%^is& zka0ucVSm0OuMjiN2Q<uNkyFQSBkH7(ruKv6K_V)f|q3^ z%U|8pv*RVKFV>%m4qV%C9))d9381H^NqjHdgj%rd<2q2aXk*VlA)qGYN5UD=Frht^ z{_{>2jU-)GXR}irvNeiIG~RC8c9=_ft7w3&T2{F3Tz@Srbo)G=(|Ih$mQ(r54w)9D zjl;rYFrKKYp}mijIIo-@M@3t+bEoif0Kbg$SxcXvGHD$&%>n}Y`>B=%nb6E5&MlXqX9P2cB1b5U=j@i!@Zrcg#K@JHv7i%`90`KQ=<`7R$ zG7>7t4vzJA^Po-omyQf^O~P|GX?Fj{3)qKenDBFmTMAV5+Lz7_%|hyo1o}eA$c?RJ zY(81y{J3yoodY}NSf6~ z%Qr#1qNK%rom07|Q_E?Ef%W*PASpgvL~2i`CGZQ=QBuR*`}j786626ppEfVp&nxrk z$eAd6(BuyszZPFz2?^3n$fxDT0TRyR$=-EPniGmsr$cH?6JGJk9ZdW8N>Wb0nrf+x$ohnXhCJdch09ZA9c9EWd6_(`MK9h+;*Z3l?Rq* zKHM9J2IEv+Vs6l?HCmrEDZQjgDutUshjw<|g^|-tu?^=)z3AecfXCcc3Ds?VBjl(Y za~gxcBJ%)AllM}?JPlSl*8N?13UOe6r|@b1n@Z%V4Ri%bsyE;AB*8Kv6oj1%4ZXLu zakYz3h%w+xKcD!MRG@H21!Xn<@4R5sfUq@bgf5cNKqcK=M1m>O(9A@w8T#*vTxjFjcY2?fNDh8ovI34M zh1V}&}oCSC84&EU9&)XX)dD;yq}ds3&=?i%lxBf5gIB6 zO1x3@tizBE^jI&zKH)7n4l<(0f7gS9pL>*lXD4$*@&+q<_UJv@eW6?JOtb7wrt*fx zS^xb+A1%uS;No8f(~jWz56I~hw7tZlf|*hkP%u4*CDaGSj?E@J%I$O{9_7OfJ|wjjf+7Tf;)MVU?jo;s^}qS!zmcgv5jiQ0(;luXh131m)mSIxGYl?tIp ze2F|C5el3o&Xe7O^fXlEqA9Pb7>crb`9Z_b)H9kySzK_X8n$-#zhna(d@zy~W;!is zi*zWKczcU@EkQM0AX>AsC=>-?qGDpo@5ev>iUn~uQjD%FFZEq&qzT>ttAw?On_P_> z?WxYO!eU^_t%(iad>2Rk3Eo`i88IZFv6NM4fS{4JkCzA4?C?GA=~HSC;COc*)+|bx z(sOMZ&kbtly+F1DB8J+m%5W49-u%s=i^(?D4fb)Dce9(8V?wyrF$o)iUsRNo-ivxS z+?T~?Md9cU3ts1K7*Cp&MI23Wz+RU(%`2yKjv0O!sgJ74^Nh1f%dQ+V{Gp|n+byG_ z+US)fZS^YO!(sI^cXoJ`&Z*NOcZTrqs<{&OQiU#j^VGMDvc+Ejk@7xKZp&OnKpCx@ z*fe`|A#s8TE@qRcf3MtF&sz^LpMR&LHxqfk#(wni7T8pWO*s`qOw3FqzB^+kTsA8h zbsNn2r6qUK(<$1dA=kd=jeCVB9})DY|3{Yy`2Q%%z-Qn2eNvOtxcVn=ZOwe@YwVus>WQ?GR1Mdp)fKoJv8dYGjQX`-A6>@WeRzzc#8`*v zJZh&$HepqoaYjzW)_#iNJ^yac^u&CHl(CUywrvg4C7*Ha-;T3MSxx)_j!1IZsvp&imqma$U}w)GY9;*}M)gxh8x@ z?!Yc$H_gjruQ}XyIAmQ_WmZWnc5xslI3;atoK;?FP+WYA&m=AMyZyg>$33x!Xtq9A zK4A!67AMJz>M{mZrq#S0%!y^B&%qJgStHGlh_ib9*~9U?c$3tHw92sIpM(edyt~wLz}s2ND=W~A-%{>vLMlwLgmiiYiaj=#fbWx7c?&K ztSn{T5mh&S{XAZlG2?b(&deu|5fwBiwsYn}`}6w^hcb5!r^}OA0Y&jUmyK7|B-3I! z(urHsM>gB>ub74!=#0Lt`6a0}kNy;I8^3`*vEU(46D2j&SPSI4B`n?Kbu>5cp!A|% z`f%rmLZka5#v=TD2g{J^P;Qb*=ODYwls?C~2zR(%Scl^yLkVlYlY9d8SalRi!Ezu@ zm3diGnAh3>^WB^XuXaut{A`sGMQG95E#7`^kY@N;uDaSVB4f3kCK>%gj>$eEU&tFr zHP~C-jir~y*7W>Mp2V`R1mwG1IUV4xi_$4@xPwX3?VX|-Zo~Wx^r2$8adnszSm?1N z=65rWSC>CuhxZn3jGk8dZ+R0YNXZMZh_ob~;>q&zh3lC1niYl+Jm796J_$9JOJb=8 zY%`(jawbw|mo(0QEF!b)J$a2$1qJzLnAoW zW!r^5^KGS@TI?PayDJkbAS_nR>lZ8N7C~TGTVN)sjdgS+I&i+5$v+dcwyb$HS{T~+ zxve4ly+hN-@A5(}*ub3#iltD_!05O3CcoHI?Dtsa+)gZ-SlSoLUk_ChR7D*0mg)T{Tal^A4k67xx#6>O3@!_X#SLd zXbB#T)E`^Gom86eTO3|r)}dKA=6By5tKE8SlHGPlhWKwHBYbH(aU%B6 z%I*|FtF^MB%T4lqTapdMugY2nE*W}8d%)=vt?zaeb>UUY$Hb2>CP$d{w3zCW;}Q7c zLZjIRQOgNRyZ5M6qFb!bw^H`>(`rf=e{sGA$D5j>?oKPL^njT#_$TIi5bj zXU&b7t+NpJB(Q??ErpK=fHMkQeaqhU<9^3?a4LI>qX&sa$KNhwFyJVoOCR0lv4}FJ zyZoYZGs@!^YvzB$)`}?vSZ%7@u3!6H?oQzUwf`HnHfR2(Q8+Q&;*BmYzpF7b>i1}s zkB7IbJA8M^!mNE0bF2jMzfXCc~JUZ_$ zB}}LYtvBD9vb4a~bf&w~NGm!&Ikes3!*A)8jW4kVuMQv5%9TR$f#t}J?As|XSEzty}Y)LpHfE1ts}uBk`~LLZn- zf8p-Vrl(y3HpWeK);*fi$5gfCuVs_nUaqt925^OcsPk#wvP)q5m@ZpeKC(c;ZkdXP z%I?7K*ym}j&(Kx45V-?^7@&Og@&Inlsb^i8uN7Xk)$qEgI;QYe2^4H;p;jJWPRnA^x6V7lfaJF8r%ir!pY zGIiHfOuxf0!4)zww^G8ZPJ3<#E-{`}!8MP@V4S4DJs`+aJbE+0{#_>NSS;*aY8Bq* zG^j)>bg}w*4C7gEX~|Svog=rPy0)if)7fr9!YsdSjK#{&M*3w4;ZjAhC-CF^8%9md zk=ni*oQ6a4M#hrEO6iw3pS&V1!$KGMQL3|7zg*_TLDHCYO!aZd;M#f zKg_AWjC=0#+8@6fqKWK&ZOECn@T6q#lZcz|c(wc|bNvrH;8DM>5~@bunkf8T45U_( z>SodrTH1OX+bS@8p}tou!J#=JABU8k^`n=kKFVeOz!AiEUdI)41m6-7(c;jyJm#vh z7PgAS36|7DB(^PY_^;N`(t};i5DAN=l`yeQoWYH2WbfUOE{O<*)OVwV7A&=qhwJTc z!o@8;{QS%@oG$r?6E}6T)GF4^o{^03*Z;f{GT886!vl`^?bG_=i?kSq$7@oDOPrlt zt43Fivi5O>05y~LJn|uZWr+p+Mg9XIrmHWGtWAcU?8=y)MQ^^Dw2X6>f6Nv)e#h@&QBILk<&J9<0{R-#R%F_Wf*3Smy&r_q>=!s}by^YHjEa427a~SuM(`30}pbqv8}< z6okYRIWE(SjDuEW+DtbA!E<;yP^elb);5 zm4F{k>665hVJt08)%G$`w1O{LB^lxK*M?$VS*U&J5X=_?d~Y@NgoE9Hj#Mq|B9pJx z9T%EV=gBH4tYBJuNL%bRN_d3(NqD?lLdO$}fc7?-FUM|QQ`}BDL+LH@LJ6MaA3K{^ zP-^S^^z6M@7`!$?k9=F2<7dmTyiP^=Ys$m?XH@<7PuuJS;N?IOe)_p?>yaTQLleA? zI;Wv1&)y@QyuPwUrs#l_u7g10E;Ml)4XsT&Y0mv8<-kzEJ5`BP&#Kq3-g}TWZN;JR zBP1%?>)j}v@ZAdQ4uQ>2@5+*d*RRlitTvP8^rpFTOc@UV* z?Nk4(d{o0R!hvzJ@+4LCwm1o2L+_KRThY0^uJpcW+-TTW+_iu#2zX7FfG_tIK6^CSmHvk0PQr5*W&WO<70-f*HV>H0=bMdo(#J=As$lE0ou z-fJ#0^?zM;creTmHH6J#Vc0PJTS@;G5o9L|ZACpTN;BkUvykR8;Qs3HPf_-}iD&m3 zCRmZ%#kqhL>;Do#OBx7|(uwBS?VkP<6Jf%G)|+R%wzybLwK6|E zD;1Uy++Mq$ul#?fghL3U@PV5x*G265?*%Y8q+|&=_$q7jHPWI%XOgpmXe{BPMov9HVd$?)J<-rgZD#~-o`QcCzhQ3}dx@);Pp6IRL#h^lAM z&)p0T249_ncJ#5W#mPTlKY$w?jO97LC#6`9tze?B7;Cijjvrh$dB;kq{{!IBJ}}~C zbOvr5`2mFC5Wp}c7f(u+BJKmY3Uy+`q%=pm0Vw~znF#xkeJ`bP8Wq!h2v#E3sz7G{YK*d7il-ui1D75?^5y^$x9)xG*^+$N67z~s^d z(3`E9024^fnQ-(&mi%8oYveREj>9ef@?d#Km?J4wpg=b`7Zvu2T(_*#+%{93)-9_i zHGy9kePepjM6)5QkvO`4<&DF7Rg;X%v;VB8dq>3kNW!Wxs=c^C!f-m^WnV;%SChU` z|JmLP=;dNzkvZt*e21ll&oyi^ji=+?$&?on;ln5BBUJxb;;<2T>*;PYN!PUPdUrwv z<*ntVi$f2!HoQ!T`mL-vMIByAcVJOlr$&7sV1V;=g2`~$ao$o`rvIg@0jpdf59yT_mNy=GB2 zKJ(qf+jD`rTWc!aX_N=E>gItVwX#%tg!I4X4YM)~lr_-|R(~jifeH0$2CTlV8&{C@y8a>hQW7N< zg?B2P_a%BbuV;1~zAuo6uVl5%{};@%%wVqbo;|c!!Rv@&{H>%#PvJV(`HU;3qd{J9 z@03MJr4|C2Z+@->5Yr3q`|Dn=qt5RgSQqtQ&*y$ zute`pO;`4wK_9wWuXDT?++t+5ob~+=Cz~wxz{!?2UF8XmEY>Z&z~AYF@MiprQXhxc zYQ}$}6h7}+#5az}m|=V~S9#1mJ|IsdG#&8|kC!DUWS|*njxA|FAmm>LxJ{f);gi&j zXB<23=s3CYI5;f}lxu&y^~b{TSwMP|3;YYGs)xzliCaGq%nBq*0CCRb76X+k#Wb}I zKfh!Cah-xU>60R~Nm$37(JRpBA5Ysbm5*0Cj;8&dK0pwRU4P??BOcby&P_OlZJ2Chih+h8nhh9tcV-4&K!Cb`m2I3NK9#XrJ_4 zr77&pm7KK9-_bI(FqN+ULdtl7)ygGHCi4veo-(4F8`+LD;;HYCc)RNlU6@-f#W%25 zYms%INznS<)g60}HalNsP6pZ&;b1-)6M|c1Lyu7Guofjvb=P& z$Lch+>qZ&(s`p*1B9h5qiX{xXyxO**R)q83+2|8u(5dyl@4a(q1s4iTQT>R>GQ)60L)}a> zzf_TfHawU%e^xarR#rGmNu2bg@e#kRk~%h>uTQ*?4!o1r$GXIxEI>Y>u3C%0gFjo> z3`5<(BQY0zRtPKo%l+{IqEg4mp;cayj2T4xCbQ)PkMp=r5*1_$)iwc(I9V-+tG3|U>{ zZawy-)NRIK^P%*}RAF`UaM4irvp2I@o#h=jE`7y%((U4xJ(0;vcW#_yt*QqQEuG;6Y5U^+Z$!yMtN?%2#If8UxxG}-Pn74oybdUk@ z#Xa%(S&7JyXu*X!Fv|oM!J*$teyQSgo~qQ0+n<$S8^XG_C>x8Y`fjs28^WPNNG8vz>k6wY8d0f_BO3(<@^qb`Ss!Ui+~eYin!C124!HdH z0fv;Z=Yo=~#|K$D0`aF+A2CXR)_A~!W)HJLNM6DI{8N1|JXK))mUqj_kCAmpK53Wd zLpY0dZJP>9i96QEc7%p?#n}O6J2zDYYw#9Qk79eczeS`V#XdbxL85n?K!{iLOHi!G zRbYrs(~)$f#CEPu&E2`oIXMY5Hgc~it@k$}X2_$`Wd%21w;J{GQ>A9&s>P0FKfVhr z^wJTJ^=LFcuTmees+UNs#!n0ser8AQ`x#*?h?A$=F~^^$9`zJYH-Wx%Wz*id~2ig z1M<;3&-LN5WM0T;jrNc`c`j?847R&(*O&9^`(kAc`CdaC{UOq$!85%tZbx~z|j^Qybs>4^sryl=`9Nf<}dM%4jR!#@UpLi6XL zrRWO&2e+f-i`Syuc_$nfx39R{JxGGx=mVYh324|Fa1~;_a8>Vaf)2=lO+e4)vthMG z;PeNcT_)23Hkt!x8?6n(_tO`XI5-1dpT4E7Dt3n z1hgH^&J1BXJ70IG>~a~HlVl-#hVPxQr$6BD=A9Te7YckA)`i;ZRN29yyvE0(Dr(8% zO(a#yUFZLsaMWVvB5csT(2Xgr9+Q1|@McdWTH0)kky~i3>@2LgJ^Pqy=;;AZtB4PDtt{D&ATaAqRpHU4e-ml`lnbb-60GAVU`-)52-FFVoJ z8-u&a+Zw;VT!rP&?`afRRhv=d6O_6yIrDEMP|@u{hh0SDw@Ehm{e4+=!N8yXMPE1M zhO&MNA`juK9W49%bnJHBYiJp3-?ju;csmT6a;Hh_{f+ zgUpuB>38)x*ZDQxh2CT;%j)`1DUE#o$WzncJJ-kgQk|aY1bMAZ_(o-HbhG5Zk5cQf z7fv=oAc0bzSlV51?HKWwA2E+h`WLAGaelwLzTvr|7G%M5+uC`Ixx5D$A(%3^d(2|h zF)kfmSUjUmJo>jrrou1d1oytI_J0Umb*RmD4V(e<(H&!9v5C~eYb${ zr{LX9Cwne`n)BGPUF_fjHq+08BrSfuoI@FycXLM{H2t)+FxA;Ty4EBZs|mTp+AhBy z0%Wt9_1;_CPAYu7WvboadxK|#Qc?QIVN z{x_ZORih_ITbZ6V-pl0IKE11r>*qJ{-V=3w$@5p?M`g^x8XRd|#_c1buE)jp6yEC% zx9w;um)*PRsMzM*4evR>+H_~63heL=`HnrUXFP!~i6vR-w8~5ISf?cT7S}M}BWRJ@ z{H+&rD7Ql}d0@&{@R_x}BHmCA3H05t#K}a&3@qR~(?@*D<2$5nzC+XOph#T9~|FUA6wQz;Z)TUNkiP5HHauX z4*413MZa&kOzTnQNP(brz+NlFI8jE9O{sh*$yo=mTK9H+&hE7TXw>Rpcgd346#aCx zd{Rye>j)qJj{DWpS_uv89&$s{WQ;w%@t{AFcm`uc`0_p_t89Mya`j5IF-}C_JZI4C zyi>mn_|IMd2$z)XN-af}aKLf7{naLwi)U%8o{Q8c{C!B(;&&0k$_vJgI=1vB3#Tsz z0Mu@hG3U*8(aq5Dyt?z(DVx}CS~I|pxeSBu!8PHR+`w)kVlHj*{DV~jHbVeTY)y>f zx~n7DU~`l0v_CrLc;q=xIBZAXux>j_-_~z(tu2N{U8AcWf%ro`qk&$tT3qopM~WQ^ zsMSqcV$wA+5m!$cIkygSkS9xGUcP!Y`yAd#_W}AgGbTqKqWL*{Jx7>(pnP2lm2J_b6d+W3u zSX)IC0TX+t8~jMJFy)uC8Qf24l|QDqJmD0GjPv&Ni6dT`m}rp7x0EI0ACwje(%D_l zF|4Yxdh1*{KfLx%OIz=q_FdXX4A1FKke2&3ML9=nrSA^)9j{d=qtur^Or_P&p7>B8 z;*j2?J-1_oSzCmb-U{>w35{E*>l{r%_{?Gd!0>_VXdBuTII80IyE~8K*6VnC!s&jX z14FD_T6Q1s)}D%J@mv6SR?ocEor6kDD9$OkhlW(I@4nDYz_=7zQI8ib$Y*%eONM_p z`?`>hB%>5D^rQ>&VsGM`asIt|RlGfiG zIUN$dF6q&_*VljD4`)&{zBuj&{j@ywTx}9TN6S+nO7ovs2Oa+sloPPdcpJ_zakKZ) z8%>&c^Evfq$Fn^nxt-5rM}FCL@rUmuqWmjJhBE5bbJ!%m_8e}G1Gc!DTGmyB%ja@P&gS4xFl%^?(Qy) z%hx&QmvhuDBjM8_w4GIb5}L4D*V|@+Tvd?n>BhGl$S_=(EMM6eVu%y2AnBaIP`t! z?{?o($5b1f|t)71F5s*pqt%BW?+FuA@d) zB_kZX3?!lW-Ea1jxXt!3PHyhMU$TRbZ|&dosj8>%YcAS32;cMVyoGG^rE1eha=qk~ zM!fct@6bMtQSKAiuG%biV@jP|-oyp4_n|cD-%MQSf1U_qdZv*0Oxtr1F2?vP_ug|u zmYl7x)Y?vOU$cCy|2CJmC6~ufU35p)`QUOv_?kafrkLjzl@R9&tQz>fW+T@&*u#5J z1iTGBB7=j@5)!bphA%P1OI(2PqXi2FpbaZuSudhh&^#D-E46S*bGR$DHhG%!?eHj?qHmjA^Z3kc5 zr-PzX_57s-E~%@{!xKl&6=1D9-t(Z>P?8Z!yw%CH)CJM4-;!aTz5t5rc*1@Nr9e@J zN*fnd53DjK07xhHa#73biRg;0-S=sCkKi}CKFPr-dMne!XJP`y&fggk!2vxtzc^k^ zOT+nK)_*dSPx)ccywUDg^Byh4(Hx2cOoFiGwI{y|LSxU z+$p%d=SGAWJ-u=X=d{NYA8-2Na!FNMF0}=k=+~c&=~T*aK4ClQJTlp54Xh!%Qoiz7 z>dVCAVB}l9kh7um4J^hR0&oppXNteEI z)lB6)@5VG;xxRmsyaTZ|MZAO+&8AFWKO$5-Yy0N8xm~b(r$5|hHbCa~Z4YYSKXkF@ z@c}|~n1Lz&?nU6ZY8><{Q>Ip4M}?%n*F82}M;I}x-D8pTr}Kome$mP~=v!XFx$~G; zu7Xg+@^EMS#$000OO7`yt4zci;`axi?lZiJLO7sO%YBz4L9MWF2GQP2w^?1)tIVcv`!X?sg|sf()I#n4%Gp!oDhU4j_S&${rq={m=W)rth2IXy zk}me@7C-ZTz|vL0eheQ{cmr7|yslkd_PI)D`|fC&M=!IZz!QRDU310wslO|fleLXt~Pv`D-AxO;6t=)!BQX z-$C@IS>3oQthEJo@SLzA3y_}QhdPHRC=o@|T!NA)t*+-$T8koc4*(!nY zey(}cM0Xu)XzS4xVwZPEx*?tyDMmEaVaT)XG$}RpgL)2lq}zY6Yn< zP60Sd#B0(0*um&|ion#kgw91Av)Qk|x*mrz!RDIH*d1qf-rDXc2`dU|iS#<*=0r^B zVHCUz7)c_p^poq^H1#LGJTsBXVeKJK;4?Md@s{mnD)Se32T22;_dC0#VAB=I^pk=U zh%@tI!NB0e@XIf&R6p#l{AFH`)7It6bH_UecYL%^Hq7*MvL8VoKk9Y}76HK}OW48v zKo4_tdZ*y}N6^=Er%R?p~_kHabfWo{aJC(Fk8r3omeytwO9>h)4rj#5&(2EepLDm;tZRe9qJGQk*9A==$^fT z_qp6>`Jzpy^@2HVyUn%yH6;kxem>1@x+tw!&mz7GYC@nB?eb&6oSoLb*}DQZ_W-EI zNZD!NN#&hm<4dzq8R#4cS01KI@9jkQn%)@5aaoyHLA;q`fd7&wuKp0o({p9LsMq&x zFoAKb%^sP-t2%bpD~Dokqg>F8{}WC1mTMK&UBO|7NJ{0Mr1@RkLzU6*93Kt^+$&Wv zh#+OldTU6+2Q(nIQ*YVp8`HH98SSPVa67*fc_1WRuK~n18$Sy5x%9USJG_^oJadvG zWLU}%TIp*xm`C~B6Nw>+0CjzSwGmuHKGsrUu%6``0ubzOb52~eob<1Sq%cEjt!@wZ zh9jr397OM&4i&Cf%pdNVYQ0_rk&uYiCn=8BvDFn0-1s8+)Wl&&y1Xb}1)@MyDhkf? zbm*!K0bSE>$G5)(0YO7qv^x0ZQTkWdi^!9$_3cUa!Jo=sO3xJLa-A)HZknphb>-xo z?9J(wXV$*G4AKA&>tEb=gzwsnlH$roMR|-)Q2A}YfBA;i6IydAa_&AoL-zD#x-GrL z*D089+j247mEvADY3-o5py=`KmAo`|~Z4@+!VdS=NJ%=xStD1MymSydRz7 zIC=B^GUamz@|F0lKg08~`OuFisIx^M-lp(c%?DxQNwSKawOls4UDuJ?s-lNm6M*C4 z{>FKf*J5+>uHHsOu(-SIF>92?WT7a=iO!^}@l(QHMc*X23H3?eyhYbVj-0 zX$<9o(I8sI-Wv9kl|7x$&mMjUFlRYy&2&X4E&Ys6Rq*-BZSP*ZjeFbE7Wwr@{x7H$ z9p9jr^Hn5YoJ^6L08_T%K5O!Ez06^LYQPXy&6GO1cXw^hsQn^ManJ7KnxA(cM}MNv zo{EO*$eREhXg0>U_GdN3mtkqlyWvHmn6=X5smh5(#&djUq;hNhYQ3+8UBLLGN!UA8 z!o<7hAuXRh0fjF$TUKV{MAaT`z^^ZwQ+K+ZT7&quI`1Wdpn_IWy1*$y{m2;m;z3$h zv|kPD%&#-o@T)Jp3Kzt0R`y_fv=^3gRN+9L0M9n7LP!0=3w#7f&`M&v6x+&6HBpSY zkn5+4ZnKT;#e5L13Y+dQRZAs#tFHM#tyRn#ew8zrE}kEZ;^#ujx~t~rSM%YWgJe7u zS6^&O#PQ*^8-G{*)Q7nEpsk9>|LEm$cf$(gt*pL%^-{~E@ouAc0~-DG(cGH*1+%To z%J#K@VU?3Hey@?Wx{YBIE`O*uFmIP|lO;69*gCFf ztrMhfty{IrJ%_Wa?@F*GI25MncLcxXQDPai!V(%R4lqu!J@|1tg*@6;9k;Q5fvvR` zi|&MUPC-IGokg;tsp#)ZNZeosrLQ<$h8_=wf+`;WaD~ua7pQQWvcV^nRByE}qJc z?+4yM-?my2ds)4hYpmtj_bgp(QEf& z;i&oXxNYIZyGxeui^T1l1m;ibFMcVM(8-^F7Gn zX9v(150{lt+F*vtCq9&KlgOC~&|yk+!Vb5G8FVtIyGdve@tJ+uUtPJTBEAICTTOY@0?nUq7FU42H;uE% z^p!`swS2M0V*Nx=lZZn+)C{77O7}NLqwie|Gp-P6x)ol8u&BmT?XPH@$f`Bcus|Xu zOGTTygNd@w0c^^;4>!pV5}{m7$Wb$!N$^WcJNBR&gsXTamo9IPLwiTGXN$o}wT&C6 zwjN;&%}FMsQV?AZPuMQIbTd`9(&MC4t_{*ACFwDe;5BnzGqd$0Buzb;VuAQYcYAY_ z20xPMRi8I=Xzi6R%|rpp7#HJp9Nfx166cVu%juKxHzDKYS{c}A23=h=4E zb>Re$%QCWgRcMktwUL~9hsd}ht#MwNXt$m>XIK3Vvq-l`$9qffknRWsDtUuW!3=ei zaA%uPbtkB!*&%bleg9qz$ctTv@4lmk`kD)gfpe58u2N{UB>U3}cl_`Tse;HQU_0AZg3oO+y0EL=Lm(M1!5_Nl)nrH>GWOmdei;SQ=;d*%Np+&6+NOxX_?CGv zWs*{;YO8rwJMQfJL#$Hx%h}j+h;%8_eXK_qd^Bc&ik7t7n)##m%vy&R3d|7XTD@=B zaCr{w8Ee1<^k!R$&|Gi53<)3Pb_Xy3UIrObNDxbUCgoSj%CF~~o3#=K_jP^pwidXHs(1*Q)0P4V#_M7aw;|+|d1qJ&D>Rr2NPTO%^jKVYx*{&p8H7 z2?5b&F;)$GPFm-X5Ym_3(Ne z#&a$t@zAX=0v3>yHRThbQ=BCBMgL`Y`3 ziNK*aTmDc`sT#eXiAV1t%v2zTo0AeMs@mI)ucS|FWV~3p7}dKhT5_HVd^BiFs$~$wTC^4)Hx> zG^v`6@o5w~y?21p;daUX;*tLqw};0W_U807f`MLo`0rZLa|FIK5~waLQ2+Rzbxvpm z@mEh0-V)p$vnIQK78~oc{L>4v_u-=413fzn?K^Kt<(z+U$@8g48|&fW>VfJfNv&-Al{ z(LZYpZnYOXn6GR7ExRrdkJ?CNR>Do!TVu?MEci#crd<((>ju6*RYD{^Y8_jj0L^ zTA0s}Phw{Jbg_`8XR^%~R~pOoRD+K&6E`D_evT6X1r%2&aBdojf4?eS?$_FEQ#6z`9U=cYu7>!{?ex=7C z5lXv6G#W6xAG?C@H0B8b&U%NJLo)rge4EY_UG_Q04d03Q5iHJd< zYcwKO-gBD~F{)O00YqBnI%Bvs22HCB=cSGEo~R+OvtDBo8(l`C?IiG71Fmxj1LF*h zk#J|f8N1))SbQs=rxiB34r8Xk^b?IzST;3~`P-u@omH&M8!eIgNnksMoC-LsTUiSR(j^cg9Rh~dN4KYgoK13 z6VpoW9#A`t=euz<&2z=dRU%8BSrhKMdI^LuyICEEu{{PIi9Qx>3RW^nEm(evb2ICV zfD-S{Gwy-+nOKebBq4ly@XqAMhGeh7rnMP(iKNlxptnyU3J5^>G96R=B<A4)CVu36KFUnEaD#m zYCpA#DBp%fe%gPzhHgjp4X}?rxYQyZSW6J{+qqVMk*HNDM@m0%o;;_D==u^6*84@; z{nZD~sl_A-6P$1Snaz0P+xzt?#Aa+OV!cg5GUdi=n1 z7*XH+^~eX&J6_wK0@*Ci$yKVR2*4(n5~|0mc=|iAJATyNwD|XXZxD!zlMh*a7J?nS z_SQA6kIZnc*q}(>mS02gdkaa3)|qpBvj$S8Y#%ZWC0ZipLxZ%M*(FqOKsQB>@6wWfe0$e4y6hfw3c{mC@AJz@4QocE5gh9XFg|H3wC8=a@Um+TTgPy*K#+_D37F<{d zM1IY9f4a5nTzXDq>olSt^DC^o53ZJ?;QAca+v}0iti*g>yaweW_Fk%$)+iFY1+t!c zKnOQ>Sm~K-r#3I<)OedD`pnB>Jg+*MLow~#F}6ei@&DysV%vRa>YUxkV=GfkbcI(* z7{!`Jvpnq^06m%xRfCTc?F?zD?3PS;ZdJpc+7Pq+^_Vxi$kW6xeiMF~(_0}$=N0+q z7TBIZj`gt1i#La#rxO^sAwuAm1iv1p_s#fG;YN#z5-E}eUosS&`Ch{O9Jj;0GVs}f zS?D5T)-Qq%TWS?nEy+OlftR!%5%)YtmUuD@`5uJt0Gfw)Z&dGhs7C5}TK%+rGa2Ji zB!YN$kT1Bb_9VJ8;AUVtkcD$jC z^ed`(ccFY`$@*@t=4@gzV!DLQ|Csp5da9nyC+$ zG71&Vj3jr5WnkVHj3q`4J}aS1gC0KhUf;O`J|4=Ry*-2tKC`eL^WwT4jrfb8sC_P8 zffQSjM?ojT{D{yLpjm<+$GNy7)Qly66DBwt`$-7#Fb)fL8vk_tdns>na-dWOs%3p@ zzsG!uMt=|@L0fRi{fxWwl9$Ef6KyKMX7K7J+dU#RcYMB9-T18Faaq>jK+Hr9$DnLP zK<^fr|H)ji6v3#Wz$l~mf8ez zNe5J^5uhb{?1B;cBN?L;D)#^@%myDhIId*cX}J-rc`a3`3FL^=;ZZv5Q_5?qxk01I^HGcRqr z)7@FM3WtZ-)fF2#+7(PJ(hZ%r?K=%7Ysp!539EGM5x!*?-M+yVwTDIfwRqFM6SM?q z9`GLTQOqUUT0Tn^`&bHk>`AIc-afB1NEI24dnf_BKb&-?ZGFN5;UH_#*heIn)T>@4 z#zmNbj+32`fl5cYU5387E{w?10_UeIHJ#ss91tns(HkzsQ3Lq zclgwp<$b}7{E%Bjvi%s57BblF!abi|LxKEkYYJZ|3y(MMEIPw{LwC8^^i5KQuZES+ zG-i1{oh;UjH=Ql~p0~oL(qZBth@b$l?(al!p(Y_>p2UagHLG?%@@trtJ9yQrq!a7X zfLsT(s8h}gSV#|>FfpYEMT=T1Bj+Xfek>hPlve7}%B$mIHjiXn$KwYWHnH2Q7bI)c z8;CglT;QYnd3ixYrqZVKYN8@U)p%Sb0OvOwzAS&*6Q3U+u`CJwwr=Oa>Rvg*g|I*dw-|A_z7EL+%LmuYHL2YwN|} z9Zee}{Q=9JChzOF`p2-gFAsjw5%Oa@LVM_zWN~G4`lVdR*?tz?`7E+x3*;bmW1>6U z9C?H85qj}dH~OR4Qon?q^sj5Chpz0`1dp}2a>iJ{jd6|>Zv9RK2*~zxvFWg)*jvym ze+|_>ZO5DONSw=v@P)~B9KW5iH2jKIp&^T679uE8bqyL$*h{JGae zV@D8hFOnsJ?r~j1;Cl~wWqsj^+st)Q9+zv=K==H1Mc;=Q>UL|CU(JI&_f^1Sn8p6C zz4Xd$LE$A3-5yM5Xr1n?w;eOx|G=>#T_+^J<9k5%EGk>2i3| zw^9CHn|fU+&pD^su9j~{pa-O8Ops#nd_}o^1-0otLIR&SY>S)PX8!)99iqBM@D#!% zsE^>#%9t$(gTl7{e7`;hL8A93&D7ULl4p#*ka8@%A%i00 zGdXO2k$8iOyx9Wz=d9mg<}b|lF~E_k7vZ`!H!y%Gu72b*7-BJ7@5*o=ftLwv&Xhnud_5(xY86!jZ85{B+q!kJV4v5!huTSRs&-Q#T zT-W>}-O#IF8lZylrja7-FI_tG6nv z!&Cex9D^&Z1`M?8Awk^SXjcwozsCuNRn!)Cpm>p;~j2aJDtG42mAzW)F5EJ5JK@#dT`*r9RTOeH>rj9caxN~5F1zY z%N)M0yYJ|L=%5evI)4E>Ns-@>_B|*{)bxKLt+5aZC3Y;c6{3BUNum!!rtdiFo_XDKHjlgDs$oVAP5`Y2=I z^7c0!K@Y3~#34J>g#0sUz3!-}JzJZ%Sy14|$f;115W_S)gb~kjc%!n3{l43iPy3%! z{izXNO28{(0Jmxh*aerOI;-}NXuK`e7V79CM7m+lCs3nwR>W-9WH*a^{2%xl znj$PIAyV^5LtlT`povY=pAh3pHT6*(n-|y((MA~M%G^2rdrrY2`E}3I!`f8@IjM9X zG$nCBI>!FvT=jyKvKWX}r2h{RMYSZ4ZQqDldKQ7&cYTGrY{u*>lSZ7Yr4?stUXt}ue)R5-kjgD?Kt16NjQO><8mrYN z_9e3e`)A{GcT-JJM#x-XYNHiy96k)4WTc>M{KmBT)ttCftJk7py1qOBV6j%qT$k4c zgldsakhlC1TJsh1i{M!3ij^uVeT74qNoiaP^E&k4}~Fq#%R( zx>=%bcKmTg{8f_SD0w6%z@$-9E+OJF9ue-uMY_mSs@W<#$G22vt!#EmSspY^>$-ZF zdKmXr!cLJt_5?X;17yr-z&sq6T2<(Z=U^=CE-1}ofeKRCWWSh;#1$JJ0xJL1(pT?V`^_r6%>M(k@$qaCYS@dK9X; z7>`8d&kiXnm1EOuI4&+QKZ1Agfz{<@sGzE&CQQucgs2~A$OB0JfUx~h^c!aj(@u+;CGtf7!ISNk26 zL=WRk`1TL(xiXn zgUZ(0)Kh$#5*JmeDK;%C#WWoEQuhWhT9*Cfs*jiVOLK=ri%g9wbQr7Jy6-hbc0Nbp zW8NRFDU97dCM!ivGhPcQ)#xkR1GZljxTCy}6ArIz5m3@{!>SYzceGTUwkp90{LH30 z&K`=Uq>Hd9c`UNIwJkuUY)l8gN}wbv6D3jl<7lmVYtm*V($fPXhA6_BUNiq9*TfJE zZ$kXlm`|R!Np&j8T={ZudQ?U6O|0kr&^H@~WGzNi>BCB{u+*Tw}Y-v|t?3w5#`E;VUHwqo@r29C;tr(J@aoulC@0~pQmO5aea zTsN2O>&{XYS`dJt*p^eGoR>+Gi3hxqQzCVwqefHdSYPWKllG##{O%={!wDmiv%Yqj zq{8V}J)htCi^N!*y5?lqg_YNb6FK#^pkV@H@oq{gbmHf;JCnpr(`+7Nhl=cRL(fG| zW`|6LJ0S$xQPtiv2Z#?$UD0FY$kVn!p$&Xc69g1C;rufUZ&9h*qmFL(ubidGvx{So zZtD45YtbK#+cgQw(ME;t?rUM~>Yx1kUjU6E*DB`zrHq4L<~~5J@^JynJbG?~Kz29S zCA?8zbYQ9V)0p%HSO|j;)8OYszScen{2KWt3px^3lA~y|+_!K~y714+heHxi&XUv$ zP|d_3Ds=@ss|(D;_#q{DR1otx#uflfo#~j&E6kJu{xZt^HKjEQ>DktW)%m zn-mvq8{{y1UQoKApEfM*!;Vug@skLE96riiOcZz5x(tz2sJ;`R;+#+b zU7@rsuk>sVotgLyn!h^|(uf=h3FbHxAjZ2@DThf$X&?h%vNW~7PPw?s1G!h}2Kmbe z&KByDJF{7V%|Sf|D`*d|TX6?`MR}d`RhzPV90&Jyt=NIE{zlN;dqq!osO~Nwbk-@> zbMm<`_hD~S2?n9dVav)qSz*Rb-ygucJ$Ecefxk;m}M{S^;<3=n|yLwCn{ zO{f|`zR3e;WI--@R;_)-uC|RS^XLehmZuua$-5(jo4B(?d7o;Ye?5$7YC7Ahz^Uj^ zQ^4(EceunPd?d=0*dVR=paI!wE|EV=B|hKta8{In8*|>gp7|C_Lt;OWEVn`ra{H(< zg!hrc_+ms3H1PDiIjfMb$8-pRdk#M>!Oown*( z-O-f{me9(~R-d;Kvxrfpt^gYP9uRG%tnpt@T$yNPh9=vo`UIvTl-b~*Qra2_BH+`=du32vdv_-t*B>}2hCCX%nzrx z?JuZID1MTw;8_E2ijk}3b$C8VLa^kY?^zpCS?gVl7tdR)NF+V6D71Fr%)q%7?kV7M z5FaaH^uOL=$o&FmrbuZsBxgTa5sYBZPB2bGGgK?ih}?{~(MXVHS8vTxFy9`(qd95- z%_|~aR)-{|4l1i$_tGB9y?wMm_^iyAF%%kVJO<5^K@fclVgG+bm;!A*4@SR)Pp4aVGyF2|_7ccEI>ej6K}^X_&ocw!&YBamIp(^O8q-*ID68n}_-=1_q)QyxQ08>}}tPjF09JVb6Q;mbvJ{@@Y zURHJNwa7mCY%Anx6Kp+r_I6$L)iDA|5tKH~Klb6o8k07gKU6uuAn7L0P#;`E-FnCxi-odP$|%~h8-VqCcHdOCG?={OVNe+OeLSZlTnmW% zE5Mu+C#h1+O(dCC9><)}0yMaEN${q+f=6&I{v$zGjj>KHRrw zL@v(5qMxUQ91&_u@!-YR`L>d`bTr1ys5DsbAeUAP@-ksSX}l(Xk4fNjBL9U$XtI}e zsmfv+mP^h5A)gXaKwSiD^<`5I6SR*ikCbQ?9+LfOR39Fm%l9NSeT+OwpI816Pn%~l zV~m5ZAsibW1#2&45o|2+C^V%Y*`f$Qi$x(ET(>v)T@|I}*E0<{-kQ0QSj?_*3d7G_ z#CiAhjyD$S>TdX89{gTHv&4N5^2q}kC*DF0BVXZA#_g{gwVl)dBl{?j9Z~k%9~7y- z)ZIzO0ziBx!&LU(sWCDw_>$q5o_$V(S)wNwTLp;W=8JUd9&Q|=f6-o4_FWw2f zilvk69iSy$+e~vFUZF0ebYo(Rs^2{|P@5uL{ebXM{1v90t64zxM#<1O{@oHLMRO&Y z$|u7iq4s@qifrMNAxfEUQi8ti!iUI+Oxf&Si;{@sZpS3Md`xbY1q=P?1aKPjG@)oH zSiw;|5D7zyGpx6kb>h59TTA1zfe|5rP{;ME<)H>X5h=XB(=xrLvp+`m^)~6{A-t*# zi2+^yrGAWVo4B%ltK98rJAB8@d%tZe*KO6D4*(lDB;Z1lblRt^9v2UIPP}qyF&h0K zU8iwCT6WdXld4{@f2G|mUikA-QM|c5D@z3HIbZ5^zpjn=Io-zgDRpQi>2kg@|KeZe z1^gUSHGp?H)mJvN4iNR5u~Bquz1&h&yEg4yB$DiyQnh17K1hbKC1ad!ji#!lCjQ;K zaVMGfwTpOTrfK)>)`>Y9=Qb3b0^yu!>>OM5>TSRh9cayAif0hXkpUYE$@60JbNREy z`orktm`w1slULfb&sW_F1ijsup0Yk_gvr_%jh~ecgZEh+hL&o{@P_s8wPOgtbZ(A= z>%ll;h^B_YAmxo{cEVrLQQDuCHl>~_S^ahX9VgKi@RQ4OoZiaC2%u{xJ-TNrVOa9+ zOonmT=5z`t965ujb3giYY80W;#PJdRkzf*cidNVGcCf8z$Zw(tpM4epC7%Ilz{jf3o?% zd+DjluPbO6Hj_6eo*&wn?Z{~Cr^n1Bo;LE#j} zT;KoxK*ej&-+i)cY57{+0+tfF%ZYa?BkLDyHUzY^=^?tOg7J@`r!1UcGg1 z!y~?$W@j^}#Qae!L{ORkkCq}m7&^Fy&Sh0YNCu%v!z1YT0`M>A05;tiw9$-*u~Ob( zgDb)Rsa=H@xomRQ#j=*d#%n%Y0in^J(h`XQAna%YWMhg3@6PUgDEmtX8H? z01NduyB!+<#uepDect|8k+f$;Ij4#a7g9WdGCPfdH7>J#a{Ei~BE2gV$X# zaIvEBC?@kiHvFqW892x)0r{}T?>_(WT5v~k*ulkdcv3at|I;83ssW5APnPK^`TvZ( z3=Ld7t>7g3KMhU=yrG+z+MstP{+ILp-LhB=xVSJhk?wyT1sNJlBFCFAL?3RQIPkPj zxV9sLFuz_Tuyo-tAXBwVAeR=x3?6Ke!?yg_BnCu?^nOeTHq>N;q}1ThFi--@sRlu&4r8rnv?hXu3sbE8=5Nm<|E+E7XMCSD z-W=(8MgWDgIZV+?mk*}jzRP+N6_X*CEUXIFVICPGMF&xUp#x=2_WfI8GhO%;YYUwh zz=w=Ip?B4Sw{L3B@E1$-L#WLjtvXxR0=Z$Cc=UbYehQO1JAU}bQUR8N20EDgR%w}4 z8Sn`E5OA|V{is;W0A5e3E}q|(Lox6=5EW!<~2nJ!IdY;x8;8k5zI$P!-S^`~x9O)-pw)JJ{EFU2ntIFeG~ z`T7Tl@heR*U!?b7zG^$7#~Sy1E8pvek4E7c^ZpU(A!cQBj!;u~Ngxu2^7j-Ow4>pu zVL$2t2IUg~rGgp4)2>Sy77gt=3*7n9QuG)E3o&v`Dk0M_BO*>{FF zJ^9Zk5Ehjhos4mJ^IR9)lYu_nTe`0{yOv$jU*hbN9xYV6?_R(6iRgWPK8nvSTK?g4 zVMj++xfmdN|Hs98RX*e`a#4xR0nmk`E$IePUxq6bzBb{Hu?9jk5oLB-oG!OUcB~Gb z59LXCbqQ?t2}qx)gB9n-i}eKbvxPXFvC6}X>)x+Cbq>g>opo6F)s-79h(O_=OJBGg zj#+)m?{24%B)qwy7PK1@aGWin8c_CNw|ji=5wCwug% ziUkVY02`8L?fgQ&+PWFrePR9cuBKN&52*$qyU3DMhxGeUpl0_VvOntFs+QDS9aj{? z_e3{4T{8I|U>|uSod00TJfBRefV7nj*&*!#skgFu*X;`HfbK)r2JVfi9J=@4>wOqh zRqjWU#Fc3F4VAX7N66ommKV9PC+gn}k(7{0FZ2Kn=tOK7aIoxIEu3vmYrhi4s$)`s zVUXcU44Daoipq0U0eg|ar>5_hdsT(ig}216#`e2 z@d-sxCNkf4pHnof*$PVA-my0n7z*BlJsMFS#hxEee}(Q*LY>G~Tu%*Q7nmLMGUYnr z?$lC4w%CkSaAVFC+JBO3}pbF=on4P58pAf3mm-O@YbjixZB;%Ka3*YzRSLh z4ge~2NbNm#I+*#t_c|DW&%Ue*r+wvjBKq;_jtK-*EL0$+a}%WDOaY!8JZN2LJ8Ba4 zJ6O@5((Y#D{kD{IQWD)9#ukH3Yf3Q@+1nH&K0i$%>=_!rAaEb8H*;hyqIdEB{Pxd! zW59!Y{@T9Uvbw0yUOC;;7u>S|y$zOW5#KNzlZHfLj6Vq-`ws4E!x(j2ze$0s95pJT z13`7|xsYo8R5RL=>M}b8W+o>?Dtltt@Gl{$UqP5`!_chOCG_p5{V=*VQdVQOp~Iwt z^^=y-DZMwK)chW&rEurOJcebOCng;UV(r2E z*@9S3r21_-O*`HH11a&0erM_X7)+S?PI=|)tquLq3eKk|b)6c)Z>XHHMlK*#QtJZ+ z?r3L8SZjoe>Vf8JSh^hQNokt1r5pyai^fPuq%*D7dR$XXkBI}HZWbE4A4LVIufgT7AmAgk*yR#|f57>NKW71yjNudv*1FI$BsFZJh;2W&&NO5ev{wuc9Yfz37??^z)~g+PuH zrqJnXI#}aKT7B<54u5;gg8C@ry0g!#6`ibsgO?P4D~5R3lXIfZ6E?^%;oxXdEoN_R z-d1xPk#O+U^DI_?fS>|fXpV+A7#`b;1c<*9uPwi-tU|?kle&il>B@yMoU{UR} zlecrCM(gw;BZNIG7WA$ConI*}u)w^)z9C5b!N{hLcI-CWx%$rNot*|)Xp8)+@POiJ z>F$RI)`LowxKes(r`Ep{ACHv_(sRZJuM+82&_jlpu|zIDn}J8p*nu%_yt$v&dA0(B z^j6Vmp{apEdQNC0>X8Ay6h}8$U@rywFFSyNDZ*fJf)y5`vn)K){3Fch0O$1=Rr zamgYb?muw zH;liO0ddY4-p0N^_I-YHY|9A!ImM1ouSWfdfbUfx-^L;FJA~BJ`Wv2DLV?k*?~i#+ z!nT&1{mF)kvDjQxUsQJ%1njkvPZyaWP(k3L-D+wBRNnY(n{cdk?! zw!Y@D`hE5G4ytZ1d)40ul?i?6Y7>F}Y;&w5zt;GXCI-4lXT9{R(cDgn+JZiHpD@D4 zA^ArSF^AZ@LXloc$g|XYAya;Oy9biBI@*6+3T*~4p(g+&>xN<%(q81dQT!l zY3O0L!~HJH5`$sL9|!U8FgPj3e>MGcu8EuB5jw7u_6#EmnE1$;>|{)?iZCU#P{LZH zx<$MUnF%}Gn>|GC+IRP1m_5TiJXm)47Sy?8l{sW$QY3uiJd26EOi}C*KK@2iZ^gs| z)P@@`)IyVcsEAqAXLGVc4!)NaujR*(SvE}VF6wBGUWlGJjgpF@647|j7Xt23DFW)) za}>tuju7|9I!d_MB;TrSGXB(#f6a&NcYb4VdyF}M z6s4G@^d0kL{~<)wwIAYr1EOMzUT6d9~Ykl;`)DF&PuKjAB~7!05o3jg4zl+Mef zrJori`xr_IoTJQ)C<>^FA8VAT089pTo@8YDqmA}Gb5ya2pL7xQt$nSA9vr4GoAY)P z9c(vXraFqXxXhIExS`0R5#CA*p`M|i8M;qDla6jm!dM?-S+5II$Px9(aPY9>y!Woe zyI$TVJ+c`F>L-ndHt5XQYsOyoy~KI$XpY0R-c$_-5Z@L8v_EygQ_t(iHc&lPeC6j{ zvD2|3C;&uVzrPf1aX<9ognnQlUtLRyAXpj0( z81%kHR8<<2Wq?)VVY**B91gB2d@#=B6(P&5mFng3ZKj9U>pzNi{8$0U^#+mPI1+|O zFLjmaNErOJ$*E{TdDF)t9XH3DrroEeTSqxv)ctXx*403{wWS8;&R}9`Jr$u?r=Iv0 zgz^T(62bVrlzqJP7;*-x2mM61&ex$pwaNmHj-_B*u2h5J03R%k)Ss!@j*l7meHaDm z0sLjOK&x2NBS07pF8g9TJY_a$!K;mZU|YzKq2snWFPR>g!3MvkuJ-wS@BGY_aQT@3 z?cx+UXQJqeJb>CbE9?ssf5{bdcf{AULTabYYG0;-)3wfEJ2DCN4zvDMF* z#6N1ph874+YIO>Z=yVxZ>GlEB(53B7gkPtA3^8mk47ue^fB72LJ@*W8mrQQnz6OKmg zUO#Y4aZD+Fwk9r7C6S?NYRZ5g9feQt`G_lt$j)wOLHLasD$Ogf(0ll1tyMwYL@7nc za1?7+TomT?PRHI+l@cL!DVzFv&w8JG4rz~Sd&!y#k@?=s?VWIW#Zn`?0c3V@8II-} zr{SQ}A#t@-VphEWHk>j^?a*G5JBC}J&kugf7#;2vf@^onK~yB4c}1#J+;{3Jgg>KP zKh~+kKrxJinsF6pVmBXV&b42JO{qJ~alu8Y zKfk3*+`Y$R|E?Qgu7y(otUWT~KYUQKMygjf$Jp9O|_Dcz{_OzXrva;3#9~|Lf{21L9cLZ36@+*boQ~ z!Ciy9ySr;}cZU!lxJ$6X3GVJL!QI^l*Who+-sj$PAN-rHuCA`?uC8x=Ypwd9Bzb(8 zfQITS_Ck;ap=c*YNsm3j1LF%W_Ee*h_>2oqKd!z#-nQ}U0~Pa zoI3T^`^VMeQ`j#6a{5AIa3PIjl}1Z9l0{{vOmB$%flagUBkLZM8H~ezM8PN6`mYN> z+4iZh&apfBVgLdb(Ll{d8px39ijC4BY>$Y=Lnp-ZjE8@dF&row5GwH00cd@1#>vR+6GE1kZclYZRt|7>9f%u(;P za*KtK^!^L#q|Cf8_yMUKar(@56Y24CMNHeu+bx^Zgys@*YgFO^Ge?MXA?)V|rFc7h z$;{|?i-d8^;omQZ_0W!7=rJX2LXD$9kk7~YGik77n6TIyWg_i^F3>G2F=?s9qwPI5 z%h#+uqMVe7eA+*OISSFHDy^ zox=JXD1x9-Srt{IsAqVS!F?ChLgXTv;0djX=={f3w&pa;i_Ale_Q6L;P1W0o&0*vmsE9nBZ4XA=jL{Z8Tc9cCHpV#z5a4hx-1ZJ<;<0LPHZ68>R4$H#XjC}h#WB0{N~HLeCi)nli$nPaP^uvESbjV?4B zvmXue5>Xj29X>iu9fu58F2)6zhJQ8gk3dRj)eDJYsDNg(%~JnK81d4h|9lmhO7UH1 zO`4&JlE~DN;5z0>R>dinXz#jBbC829?pz-i1l(g@S(=m-7_JyYEPH$eB~+&l*Qa$ zjQ4!aoay=$o{M#wN$WUgrd@u?O`YqX+&(Tm5HS#!*m8#wb3&#QOWB8DQ z|8H4$ihB~3jvMH`iEyu835^Cb{IQPph)x;-b>g$Xm4V z%soYKu}*ZSW~1DCZ8(Z&R4<<4Jr%#F=h+qo;rMs+6*-djcAQU>wPrFu>V4gF4q}?Tm%W`%#GAAg*VgY0H;}2N7SA)d7Z2A*%Z<=G*=3JKh;-5F3wt;J zoqNCi2VYmk2?D*v67mqcnTJ-V@v*{Z{`0KroS?XZ)YTAsa27I;lC}N$hQp8D zdfhoo+BbIMU9+6RD=HT-hCwH#f&T;UgMRN=JcChBPYIN5XMo-A-r1kbsMRjQ@zuW4 z{NKS5CoRiz8>85ETe%E}1(I$R&Z~k~FiBGg3DbhJZf(vYsu?kX;+O{Ob_+X(HFjj zV@&#IJt`vnxWi9Dtz7%k7m_AnR#2C8BRzUw{3$Y{-uBwc6EJJ$O)0O&D5P#9=HdSv zzO2lrlGb_d@l%U?&pLGN?SNbx_{mlJ1GQ~g8o9HsS&Q?k+RzQ_Z1;euf9NBZ&CaM* zGpp`8{V)$vajbVRAHP>RqO>maE7=ZNjVG_keWk0zCD`35m(L67(R3gPQl8;?s1R2m z+d_$vUSIHtMK*=Zre^>9?PWS&!bm~d1cmg5n%zFvt&M1id)uM9E~Wcy;Ar0aZ7mu$ zvq=D@HjE_~ti)tZ7PD?S+X3P1U0~gHo;f>Jy>tAX#|P%jg@`S{@E0zxY&vV7B*23! zXu_#Eac!^(3){oRoL8`1drK?ZWlhirok7kKf9X5;WJ;1I0b6M`v1zY~$;E)S+7(k> zV;VfH2h;nnuNDlq^`Xzc$90KaAL$7*O8f=p_G;tRc>L@r^t{QiN&vR;Q!m867QTQC z?kA}-Vl(U}rq#au^*`I~AEPA?`pJ&wW0y8IqS#n{mcj`qi)p1>s9lCZUB^R&;Ze_hkVJ>TP} z8wL30bJ0ns1LfdoQZXY?rnhx2$B{o;uA?S>@%zz!1WUK;s#(#Ls=(IU{Q+Y-ccWbW z$?jEI>wGJ4KAyFFpE4}_`#&0P4Y8(jSV*unRmw|;%bEOTl-13& z#_eejr!ea@Eos0HS^+x?AD`0f8tM9{Pd`Y^j4|DdRe-z%8$J)cJ548mcDQp9&=~~_ z*GZ+f`$a4A2Xt`u#rxa|1VAN6N=Z8~JIIsiPxv`^RB}sjg-6|rsdN~QBuX-Z&_M<6 zi)b6k>+881TXpOn4^rQY52B28mZH+DxZm1B@)wqiR z!z0$Q+KCabWj-at^c#1+YTace#DwhEq@GJx%c(P1_MGtIRz85_o*Yz>rNT-jbRUGR z-Sgk8wSgoCwK(G5@-K`Ya1kYt_>3;W-u@*+CtW_jBX7e5`j~O#ynse!lb2*MQ%6mc zk+=OYway%q()1tYF5~C)(#m!L`~_*zlhHcHH4W1>x;1wEgd zJ5rx$B!|fL2f9Ocfg+-Ko{3F9gj9%%Li!5&qeeGq4^?(q?e)OZBp=F>L&eI6G*CsP z9=jeW$GcY$kz`ZFdcgAU~^TBbWcUK96%zt7g1tjZ;<(e%m9 zhYxBUHBjqW=3w<9QSsvi+zs0Ts5m_&m~@0e+8^>1C_2eAjdYxh+-Oycx0QUS_c*zk zM?i|_y`I)St8#!akiti2@Ww%~4^^}cX!b6HOp2g*P*#Jp?K)WQiG^%U6SL3bjP%0} z2YsF9R4hV5gIb-!NM)JRfU^}B_wZ0dei{N}!el>U-dU=CuzVQn3sCE3c8p%CJM?hyI^#mO;o^M+^hmz1rTywo%_;Uev zI>^q(Zp(UFZNbIaRAP{xE*fa(!wCXVj)Z*#Y zk#2@gsE3(tTP8hwPWC7e~u=`POI1UUdJWAI?QXU84bAmN+@sxBJ8?Pg!su>E0bYGk$F~Qvh~;N?S%l(;~CPqor~tUYRF z_{!?d)mD>2eskP+ymQZSZjrTASOU{+zKytMPtgBa+(0YKn%-I}d&tME{Jt2WVH^KI z@I%{(vC{-i&yAz|;lKjnV9sqDItOHev0rhkIG_wiUqAYOC~X6ESUd$a!!PBV)^#l8 z2>V$u$-!4a>02L9*og}@2(<-EZ^ak<=leSt#hd-OJIJw7|EFL4l;ScW!QY!8UNY3j z5M*hhD#t_JM$WRX(iNCLhk*9E6rVFt9H<75sHA*ov`L?L?Yy3Sf4wYBc-6vvV?grk zxH%bU6}Gy!RiJpzu(J*42)KLz$a0)(0h%jTks2o(S?u9$LW(akITgC1G=mwjPtIC) zK)xI4mm&qi?UT3Nlcl))&51hK>PGtfy36oiRbC4S(i$d}(HS%=P`HRQ@;D)aAr{BUOMMtFq=FFUd8{eca#^@5yy=&*KQ)2t1>2vmzdX^Jr(nYF99J zAHPmOJwBFISJdueose3Q$pk|6cK&E>099Q(^1~B7D26YhT?RQ~wAAdQbNQVUtg*&_ zY`kZ2oE;=G)v93&_nlM@#+PlhmFQ!+cHX>C2Ol&AqyhoMr!us@lpkr@E5_yf?VmRQ zs^$Sn-OHB;I;^ic*eLsVukt#~U$^c9<&ClL#n@kIA8v9~`~E6B0z%~sVBjf50ZL0v zELxbHK43Lke*yzX{3Z2~$q4yP(d+u*iML5p=;;WmPPk{fe$)dNTUYIm5w<)Nce|V1 z$1Am&)?(U|f<)@lte=6ey^XOr3LDNBYz}2 zFC>sh)DZWk(H-#360{H+lBb)Rg3E5BuZF2R|0vDHlz|zj2&_P5FfpP4 z3(Wl}n7>Cpr31bieD)pztNosd7*oL_xn}zn6pa;_f2joj@;5%ozHv0jWy{0=4@YAd z048G$1C36J04eV8PgmQph*XYJvn!&I2RmVvga3gZl?!rL(B7`e8qj(3tH4>k$qAez zlfi&|%bbC;K0uB~zUBSp{ft9Vfe7e-=9(cff4YhIlZdKT83P1V^GDTXj00#lLsqzR zjZYuKbYQ`)yGsLeJMPjr8s02Ve9d0*Uv4@(m_xxzu?R56&hZzrBFBYr-Au7Ii`X@V zRQ}#MS)F^}a@+l&Oq0Z4jko^uCWC5<rb^i~o1)c)`F-0ZsiT9{ZA$x?DIlFgjDv%8uR!qAtRz` zw%-WPYfF#UeK|6G)tKRCoAO^H5})KhK^#QSsb{!CJJD_PKianlT)*cM%zs|g|7GNK ziW^M2b%e7M`r$E@YLN}V>pHgTaQ4dvVDgP?8SHA3bOB`yuHnyl0w>Lezx)%sLk5KI z0KEC#;e<;ju)jcSRYg5I}6F`{R3g5prXy=|;`0fof$P zc5rvZB!|p!oby2aM>bf1{MHU0mtXyJfO>&}{!k~T07-FyGu-|wB=XfmNJ@Tu1KDT%f&uf!u)FN=2q-(o4=)|7=W-(9;bdE#&7f=jxH1zWeQJ_8Oma)iN8E1O z4LyNX?l=UCO|{u+?&)P$&IcpB>FAc2*E#U@K5rY*1{)aN7g$f2GR}H zsjKD8NT%Bt^r=qrGkg$0w^vX-?9?D${A)@xx!^jd-qQ7B zu{}_Mo6E!2IlHP1O_w+OvX5}yAt&|-l=JPXifKK#bzpBmf9O*pqf(n#E^y>HsK<&j zd@SE4T$KL!?Cksq$F_*95GZczNnM_K_#dn$J0mBgTx#7;szd_2R7rhi|M2+V*B^(?}L z?|LCdDD`#CijQJnJi(uml3ZMZYCRW1I+4Fv7Z){c*Ay>GI@tK_HR)ORywPiuXSpIT zcD5FjWvNVEobNekL^iC@T2saB|1%^?Xf93fBjvcfk^x(qp;F@Guvj5&vd&qV-b^v( z4z)P{3Re2TsrvG@f)-p!okc$Oo~l~yT|=h`a~{t!nuegUwHE>*3w5%3fOa} zVa1+nhIR6_AI5oIVcEegmnUy`EjX#hw(eC$KU#}$wUo8d`C>+{Dk?&~q2eSsL7G&n zvxY{cpzv zR#~D8slh8D0EePOd{$GR;ISPN4*BAXrG1qk5%pE@e#Yk`HEMaGEg@Zkl+SfXDGJTVyV+?jJR*4JZeQK)B zDp`+Qo0eO5Sp=C2wy>?8HceJar!U?!{$#1#dL;h=625fbK*NnRW7kc4j7-VkWOp!kq8V~^#=gC`gKbIsmz-%Z z4EW>+{V=XRc@b)~_EC*^0JuluVT)c}E&GXMUugcYgMu9v5#6>$;pzdxS%-8# zh24aN&yeu20SZomj&nMc%$$)4vU8TW^RX+67B{}a15N31LPr(e zSI$?61^%|+gkvFAJO=SUSD%Q&PCNbkZfSXZN-*+afns~Y0nsf1cBZ_bvH7KwPW-2f z72Of7X4+0sVHJ0`W%yRkZCP&-sp|13nS8JDRY6N%dS;xOO2b`R9Y>wMt!Zt8Kh@a# z6xlbNmkY85RaQcmyJC18QxLSQx#Db)MHMi2w85a$~6_qu&Z~cy0y96IPf>BSO|J$B-sfspZx$M&T={- zY|1ap7$#&ra_quXbEAK_ zIVKq*pKeXrJxL8T7}3UnhRt^%e)1xjZ|ZU{MIOe zrt{g68uG@qH+UINMzSPJW=!Ra_3+qM%$2u;Uq}(HUh9xGXia~ulI!?9DEzF()ONEL z>(WNP#~CYek4!MYDKWF$VPh-HzW6*(Lmf$Q{Mv|=cF1LoVS13dYOWV8%MXg##b94O zr{130E(t4NT^t&8uYOOjzw(Ul6v(|aac#lin@|Jsf8p1Vr;9Q${EB=&Fb_Z6@|R~O zDI#Dl+mSEp4FKyptWq&f?U@4+5H2;k&oBTKBuMNe4fP>B5?fU??IJu;AA2> zebjiIB=0TMZ9RfXTJ#~C`9VmextP?Xh@4KJDy|ky&e7%^w)*(F%yH*P#ZnGkm+)BG zhdrLi84c|t>flzAkj)+EVCt{nQF5i~E70apfqU|Km)f`edL=DC;hg+?KH7ZznQ&QOPk;^@A@TMyPrXHjn%I={?S`@-o zcGtI>-7uMvU*QOKePNTyTSYx(cdBR}{-_exvTWaKp7vd#APDX&iG*^;wohxpqY3WU z%Qi7b95vq26n@tIE|sca9vItycDi%(0{WqHB87982zIvjbDSeLMFP%6syYBLl(X9L zl$nQ_b;y4=aLkm06kL!zvwgP@l+LbFa+Ai*zQne~qJRA|wKHGAt=K{hOLlM3$Y~FY zU19Qh@{e@w$@x0o(fhr>>g0jKt~m6o?U7{Ap-QLp`c~S-jhuC%>}aTw88nrw`f5&n+oN&x zA*K-JxnXFDTixtLmqT0402U^=7-5qX7pEd2F)_-?)g&grbR+a;;ekujap*axSUG_R zm!s|kvH05-H}cxyVIg|n6Y0Ha85yDFzP$3TJIT-q;x(o2dwBtUpCUL4^_zii`JNv; zA+@bR2h9R61s^fVK1(bfHkIzo)6~^O&ahF@zZR*YU0fkIbGMj6yRS*n=rzU)BUl?9 zp#KN7w7EfoN}>Y>30B9T&`d;X*eWrk0`Wxl9Gf>9p3%=neF6GNV}bY3Wsw`HR+L)| zN94C8LGG7fo?D}@glGfhJdlZoM2H@;A7{%VL$jQU$RA68w;MY^;jzW6Uq?DN)3;Uf zHy{m{VJ6_pJBm{i>mR~Fh z5e!N9dJc90%K?swVNj74@gG0$xLNC~L^Z2_gdUafP2CiRL1>8YIO|$H;8YQ#$Ltm* zWgH1tv6JxN+OUs>tY<|zxfBt_U0TO1^mtds%}Qf!fLnz(%5L*nU(u1_KFpE77R@xe z>2UDdl)AYpI!LPz@{_da1CQC!Ch0B(l^J{S)hK1&3l^UgU-|1KJcSD}Sz+8(k$~?P z$7MqjQ|Hb}gpSBbApgu7nKVoBkp6ueiA|%WL{Qy<$8myQw{kg>utioZ7On3@!bsUG@XZzj( z_qz++3kL+o=ZMwbtbUl-JcCeHSP`g!txrKg3x#o!%92cD!(Bw2E;b6pAM1%}kO`-~ z_Kn?K!T(|{CAyM#4w+wX+q}+N&e-j~p0#_h5Z%2X$m9a+79VL8WbnBKK`DwUALbAH zC>_qFDyIlXvSAUlDcw8#Q7R^&g4c(8BGbYyun|UH?si0#d;011-P>jFJ$bMAk~PUF zs!PvQGF{|E30v@p#_gw}8d)+W*MUKatk) zb4=EA!}&vydA(j2d!7h9_NT;owo3FG<~!uyI70o>?W=<8M}-e217Um237FG*Z9 zlcxK(W8?=@atWQFuW_2ggr}{&;#PeL3o>~8*+YkdoYWbg=~F!lV80@MjSyaM3deL! zk3giTUP%Dln+$PX1-5NiK(==b{Jd)#q2`R8y^fz2zaY6j;Mg2#mfMLZOOx~M?U{xr zjBH)KIx%##!Z!u>U2HLz8~@yla~~C$DV>?2bakZV-t(;C#jsVA(=Tw7SFn5%%oVa* zS7=>cNtG`jl|sQf7;>xEFH@)YN-SGGpsT6PukcY#TGN+N;>(|eHtl&K5Efm2XdMm~ zqP!+BM?X|pQ9N$$c_L1eZj9WO8qloK1Wwi4G%dLbvoHD-Dqj73x@Z7&vk|G6G_MQEpnPU{zB}qu(>EMG-y8?HIQWT3aps(+qX;fX!fW&Z4T#xtu*Q4uDRK zl$UiTp6fpA|yf*+7y~ebKcEFIZ%WV-5 zMs+XOK;cPJg3=9 z_YYr34AYeyn#43`%fOp&zDgJ)2Q{(wt5JIN|EU;J#eA$~YA9aMUy+!vvR^-rMx-#7 zu%ghc&scC_yR{&f$zHeem1`Y0-CU`4Y^fgF+3ek)+!!$bR5De2;eN8*^=HQ`g zKNtW;wopfHs4%Rjo6J{X=Bs2X`8R>ackDVLHmNr`Cj*v1P{nkRIe=4 z!=AB)*UBhG6s^HsB)l80OZftQ&NiP@L^H8wa67EKdr(O6T8BG_krRJ{lrD&SZ-LE^oHC zgs%;BnMwObzA^KkpN|64inj;@oBcsQKY?2O+as}Z;lzq^?nLDCn)bsB+C^jMO56`& z#`)3!>njg=O#*L2OMScBGtTtz(}c+tx5Y=}hgih;oxw>eZS8alBSS)%J1w0j%R0P%_p`V;s zjeUg4%5K&PEKVX4-EIeh;+gX55@?s@j;kqdckivih8o5n(V+*ge_8&~loUN;Mro<0 zJ?llGsFw34_~6T7m@Grk(}z+5YU}U&WA*yvuw+JIoczuBW{itr8IGTXzo11Fr~(v+ zZ^yO0Ca#QJUH32b7%w%WM_FwEj8Cb{HRs78WRlzqRa7n;Jt$e*Oa}c17QaS;~ulrt(x@#|KK^?*#Z1>6-IzMW%*yI033P})yxVG;k<3oVpejicygmTpFoy|BbbQ9^wU0rIW|1vdO z!uX;+PX!?Fd|GcyZ8OhpsN3nZqL%_aFM+oYHRI_5T9gIB8NqV0-Qa*ys6F|?e1pGlsWvs-{uBv3U9F6vhS^U*BqUX zM-hsTPUfNo9&Aq2T&TdoK@bzYM}oxTnIFvvw_9-t(YhY?I@|m$>v}qgiy7?O@-sDE z+5_LzIQHE*kJGt#g5#H6jiFYIo-s$no=nYg%9^F6Dk_!zsvL>pzpep;50xNh)y7(dPapr zgF6>hr7uO>kf{3SB5(nMsGnHi@D%OcH}?aJ}TH4?vOgCQ_8%{ylPZa6?If;Gz`3s#?Zj_;b*91nDbomY`6* z5D^>1%h~>YI#b-e4)d@H&0Bv+K!e+D6(84Zo?a#T(pJvn$}$VSyJOmal_h9@xj=Y|w}ZxX z!z7xssgGOBPq|uY^yjnKIb{%C#3f5nv!E`g?VR_LHeO<}7_^0iOBu($YD#!FZ6x&8 zxs2wJ=mID>8I%YC*`F1V?;zQS3l+S~mM2!0BI<1)ZQMGRz9m7?9aL7JYhE7vt0gn> zRY#np+PdG?bxvoZj@PQ`PFEenA~NFpi7c1+brvGfoSWNK<%X zzAus$svBPT0DB@?q$-`4Nd~9=N)v30-$i*j^i8E=AiVYV_fGTAL=e~JTuW2)GXQ%V zfdNe*SNI6a5N{?7MwNPb*};7y;o3HjcB#T`cCH7MLL)Zs$&z(NOFrQTKX!nqsOVs! zL9@3quJ^N^Gv3*}Gv8^Kv~0-anXwP_^T1tkeGOkm^rG7i32=$y4LkKJ%qZN#~*h+yh62SY|!e zpu;dr`!<7KVaH3BoLR<68(!~JM$&lzn(+bYBQho?d$|X5zN}|f1D$z4Q#$hSpzORR zF0~k#`CCxAGik)-#$-&!Qo=6GS|%^l*qd9pz`oWNCe<%_7aV@|a11wWSx@yywP$Mq zd+V9%&qo&Jkkq&rQ-G^jk9^$G7H!5D3kq)-<|2ll4VZ>|_j0U+hob#u`5FhQp|+{K zcKn?FPteiI8<~McERKWxnWJOfGm@N?biW7g8-_aAKaWVY*a~D8LPqP9cahN0D4Z9C zHsUxlTKKweKwf(|>hPR<>Exht-}ySFj3OjYaJ3`5T-{D)Qn|E6D?=G8R@ERuhnxyu zEYNT`oC7Gms^8na>=;y*O3Jzhz0D&+2F_@oR3TW$x1WQV{hA#2d|GHYmGh>i8;zJ!8cjrPIuWjXtCU^_K z#4=G;iu6=kw6%Sk8@S!<%^T0ovF74(W#2$Cy;5-8{fPH8CW6t>qOdpABVuJrh2QmF z$)hd2(1s$UcO^OmuC)n zRm*z}pEf4g^nDe{k_UuyElTgEn!IJbM*Ep zh2&B`-TmOpk*7{ey&hIxbpYOqG6z&x1+0y(=LM&1l8l(_FvUVL+c9HlY&Wc)jT)z4 zx^3W5?JhNKUgEtuwzP&;T!?rv)-RN^wx(B6yr-o{!_Qh>WY-z(-?kjOHcvDzZ=ScY zNDdUL(8xZaYs(oBn$pSkZdrM7RNsEW)XBY>fFj&75@V9$;|ez8vp`<^V7f>iC=juk z6hR(n%_j@oQ`)QPd3wHh@3TjyQ9>myb#YKV>V89V|53}fRv2->{zo-~O6R6oyX9!^ z6UVMb1YRnp196sKJ!~Lx?0g(kpaYQy*Nw>o3GbC}t%-h;pXzwNH`ea+uR_Egamzg) z`faYHDygC=Q~fOqZBV$67!juH;=r~#PxIJgFV5{_B9G>%)Ad!l3=H$v1E2*9Utp4m z4)#PxsW~vv@NPcM!Q)fmWl1`7 z`o=SmhGz~^lNEWeg=1GAqIv*!(+l=im41dCA_x8EQ%lko6QZ5B2ZZDJgy)gdbZm(7 z0@tR8HQidEbbOdY_=~+^V{Dnqb#|r)zm`-IZNtyEwK(~7v_kpN#qY+iquF~LM90%C zXHJVc!?ebUBh8QCV8dL;e(zbM*_uJmhup|J_tH1d#CBi38MySRek!a_vt-}5nvVO~ zq(kF(R7LCq(XNoeFZevgccTGg4OIFSW^4P*B|9RR?kO^*xyQ;U&<$OtIs?pVRI1I# z(mXa+$KM{gRy?>s0Dv>ITpZbN--DtXQghSynC0B1?Mh>9hm0!?ko(Kp6M5l{z9Gi%wp=$Lm7gIHq(1$P_UU5q?9hpTT5qi2=Z&?B%G7gy0RP7G>h<#0W1q&8 zAaub+8HKh5&Z(1Zf4eG$zuWk(eFI4~sdICkOvXa`Esl>5_d2}bEcG9** zbBO2H9Js=_c?4a4dF+#>Q`Ht)g}(4S#qEq_M;w_|fjiu63nkGgl{gf1dt}LBKnKgo zuYxb#FCs3HDh**~q4J&z&nY1}2h$w#HBF+4+80|ZotLnBsfJqbWb}RaOuVNW^7J3r zMF&+xnXBw?v`V!!gQ$nEuB;TBGUsIE>ARDntp2!wsaX>}ekI}RIafst*+n28#}`k| z7tm5gl|9V3hcXW1aS2S%i%1D?Zp9F?^42$V*B1J%nfa)VeZWzr%QFGqBM=EgJ>id8 zn&$IxZrQ?}8lj_Zt=_|~X-eW`h)*;@uW0e3$QbL+o;M7Dq9!l4Tuf)0x6K%Wd7aN6 zfZ?5c^ZsSKPMOlz9y@8x4RLM7?cEvfZ!IL{BR0+L!BAb--nWn{{xAe#`FcQ-F#X(0!yj52d_=Si* zz)j#KlY&=k!C{?IAz@Y9n(T9GBarm&iY@t)cBxRtgg70SWVI`7xSCL_zt&GDkD7~_ zZWwSB)Y{KM&6dnsljM-Yzq z_+YPy;>^J7{mzA4uh_A*3oy*eh%RO@VcOQ0c*gI@jdZ$J_-DMS?c zHOoztvEhH7Mo{hK>5|sau@Xq5pE_SE*(bEn#w?<=N#o+jd_^`0;B}OzKNMG&wJ`gA zDKa|kn^|18rlJ;pWW-R0`H~VLMyDkvSKY>9x6W1=&#!e2t4TKKwq?+eKCinPZr=Qi zE-hGa->orUTKnaDdm&_(Q=`an91RAK_A}p)@}H#+JH7N?2O@l$)!?`9 znv&x%kfkHSYEDk6BzJ_Jkpm2xUbrFt)*usRpSt)_@cVXaGJ403lz+eIV-*K-d8UoH zQST_%g{q743tRvzQH&VNME`@_HYOVImzX9cRqjd@?Kxx-KRCWUzE@F(XuDA9cNs6< z-Skt+|DD-8?dq?aRS{4<;fsut3GsSz9r}3icGLOn$og#v+Z{xi%!ZI7uV1QOB__B` z#;pjPT_2^Vyb4P&?-FJT8ltH#z(``TM+A;(HZt~ZXwt50oau7tYVV(}{fO8%4Y`jk+02;J*bYLf{!Bu0tB($UT98f%~}$Z=YxIm(*{|f?LTCU6CMK|KfnW`!2iw z0=EIz$+lh7=GJT=I(P3t5k%zq3qSt$yFe;nW8*%=X@3jXZ6(|D0UXpD+A2@Sc#Q_U zRZf-G!Ov02C-oERP=bm;w;sE~m$XCZcckl|fDYk=I)8qZ;g|gjQm$xb*l}?xabuC$ zxbOZXkn=JQho4}p3N;zD0$r^OCXt+L%fVg+5Y=gy)WaP!qZf2!nI2ItoN|fuE!gtQ zrNB~*zfCRSAF2ftRIpB`pbkti;Ovt~!2zigUE?4QR#GgV_B zzuw&6vVA4vY{#Uz8GhuO`U(VQ;#6THWW_bVDZ{Xf&>=0P4QAd?c)$N6gatCfI+Vzl zV%O^+xuHPYEi#FNdkq;Di=PkAIkqmPrjpc(kJ2+sW@YHDM3o>2FpI{A0!kN26}7JQ zP1ghTglD4wKoK=K4YW_kZfgcNrQQ;n?`*7ee zeE`0lI=Tnbk9n*~EXYvu&UHYA-#JA6^QqfHM)wBi#Oe;mK^BNSfZA9N#tWg=u`k-#R)$lL=070I`hjp>b@MvgH`?ENq`d#XL z5Do+@Kamj+X&g1`R5|L85P=a22UrW8uPLzbax?!1X}y4r7Ud!-W2ITf@m^kGt0hwS zfK53fv@RCdVKtA&8noAc;tw!Z5crNCD|R?vmntpbYszdbeQn@e5MTO+OZE_lf{`-# zxc>+vMPTs)#y>MotOQX;X1IjKyHQy6xuB?CVtOC+zegb6qGkb4G>Kk(<6Lnn?QTO3 zBJH=|{suaK(G$jWIEi<>=}}34sQ>%t7)MAd{q9&t$gTe^3O=v%2Sv=_ev}D}XDW)r_|a!rl-U zjDX~?|EFXy1%zfd6Hj!SJKcXbaKm5V^LqEi>$5H9@93G6r+45#Nl`hGav_6n{|`;B Bng##> literal 0 HcmV?d00001 diff --git a/src/queries/profiling.md b/src/queries/profiling.md new file mode 100644 index 000000000..0b574cd06 --- /dev/null +++ b/src/queries/profiling.md @@ -0,0 +1,341 @@ +# Profiling Queries +In an effort to support _incremental compilation_, the latest design of the Rust +compiler consists of a _query-based_ model. + +The details of this model are (currently) outside the scope of this document, +however, we explain [some background of this model](#background), in an effort +to explain how we profile its performance. We intend this profiling effort to +address [issue 42678](https://github.com/rust-lang/rust/issues/42678). + +## Quick Start + +### 0. Enable debug assertions + +``` +./configure --enable-debug-assertions +``` + +### 1. Compile `rustc` + +Compile the compiler, up to at least stage 1: + +``` +python x.py --stage 1 +``` + +### 2. Run `rustc`, with flags + +Run the compiler on a source file, supplying two additional debugging flags with +`-Z`: + +``` +rustc -Z profile-queries -Z incremental=cache foo.rs +``` + +Regarding the two additional parameters: + +- `-Z profile-queries` tells the compiler to run a separate thread that profiles + the queries made by the main compiler thread(s). +- `-Z incremental=cache` tells the compiler to "cache" various files that + describe the compilation dependencies, in the subdirectory `cache`. + +This command will generate the following files: + +- `profile_queries.html` consists of an HTML-based representation of the + [trace of queries](#trace-of-queries). +- `profile_queries.counts.txt` consists of a histogram, where each histogram + "bucket" is a query provider. + +### 3. Run `rustc`, with `-Z time-passes`: + +- This additional flag will add all timed passes to the output files mentioned + above, in step 2. As described below, these passes appear visually distinct + from the queries in the HTML output (they currently appear as green boxes, via + CSS). + +### 4. Inspect the output + +- 4(a). Open the HTML file (`profile_queries.html`) with a browser. See + [this section](#interpret-the-html-output) for an explanation of this file. +- 4(b). Open the data file (`profile_queries.counts.txt`) with a text editor, or + spreadsheet. See [this section](#interpret-the-data-output) for an explanation + of this file. + +## Interpret the HTML Output + +### Example 0 + +The following image gives some example output, from tracing the queries of +`hello_world.rs` (a single `main` function, that prints `"hello world"` via the +macro `println!`). This image only shows a short prefix of the total output; the +_actual_ output is much longer. + +[![Example HTML output](./example-0.png)][profile-example-html] +[View full HTML output][profile-example-html]. Note; it could take up +to a second to properly render depending on your browser. + +[profile-example-html]: https://github.com/rust-lang/rustc-guide/tree/master/src/queries/example-0.html + +### Example 0 explanation + +The trace of the queries has a formal structure; see +[Trace of Queries](#trace-of-queries) for details. + +We style this formal structure as follows: + +- **Timed passes:** Green boxes, when present (via `-Z time-passes`), represent + _timed passes_ in the compiler. In future versions, these passes may be + replaced by queries, explained below. +- **Labels:** Some green and red boxes are labeled with text. Where they are + present, the labels give the following information: + - The [query's _provider_](#queries), sans its _key_ and its _result_, which + are often too long to include in these labels. + - The _duration_ of the provider, as a fraction of the total time (for the + entire trace). This fraction includes the query's entire extent (that is, + the sum total of all of its sub-queries). +- **Query hits:** Blue dots represent query hits. They consist of leaves in the + trace's tree. (CSS class: `hit`). +- **Query misses:** Red boxes represent query misses. They consist of internal + nodes in the trace's tree. (CSS class: `miss`). +- **Nesting structure:** Many red boxes contain _nested boxes and dots_. This + nesting structure reflects that some providers _depend on_ results from other + providers, which consist of their nested children. +- Some red boxes are _labeled_ with text, and have highlighted borders (light + red, and bolded). (See [heuristics](#heuristics) for details). + +## Heuristics + +Heuristics-based CSS Classes: + +- `important` -- Trace nodes are `important` if they have an extent of 6 (or + more), _or_ they have a duration fraction of one percent (or more). These + numbers are simple heuristics (currently hard-coded, but easy to modify). + Important nodes are styled with textual labels, and highlighted borders (light + red, and bolded). + +- `frac-50`, `-40`, ... -- Trace nodes whose total duration (self and children) + take a large fraction of the total duration, at or above 50%, 40%, and so on. + We style nodes these with larger font and padding. + +## Interpret the Data Output + +The file `profile_queries.counts.txt` contains a table of information about the +queries, organized around their providers. + +For each provider (or timed pass, when `-Z time-passes` is present), we produce: + +- A total **count** --- the total number of times this provider was queried + +- A total **duration** --- the total number of seconds spent running this + provider, _including_ all providers it may depend on. To get a sense of this + dependency structure, and inspect a more fine-grained view of these durations, + see [this section](#interpret-the-html-output). + +These rows are **sorted by total duration**, in descending order. + +### Counts: Example 0 + +The following example `profile_queries.counts.txt` file results from running on +a hello world program (a single main function that uses `println` to print +`"hellow world"). + +As explained above, the columns consist of `provider/pass`, `count`, `duration`: + +``` +translation,1,0.891 +symbol_name,2658,0.733 +def_symbol_name,2556,0.268 +item_attrs,5566,0.162 +type_of,6922,0.117 +generics_of,8020,0.084 +serialize dep graph,1,0.079 +relevant_trait_impls_for,50,0.063 +def_span,24875,0.061 +expansion,1,0.059 +const checking,1,0.055 +adt_def,1141,0.048 +trait_impls_of,32,0.045 +is_copy_raw,47,0.045 +is_foreign_item,2638,0.042 +fn_sig,2172,0.033 +adt_dtorck_constraint,2,0.023 +impl_trait_ref,2434,0.023 +typeck_tables_of,29,0.022 +item-bodies checking,1,0.017 +typeck_item_bodies,1,0.017 +is_default_impl,2320,0.017 +borrow checking,1,0.014 +borrowck,4,0.014 +mir_validated,4,0.013 +adt_destructor,10,0.012 +layout_raw,258,0.010 +load_dep_graph,1,0.007 +item-types checking,1,0.005 +mir_const,2,0.005 +name resolution,1,0.004 +is_object_safe,35,0.003 +is_sized_raw,89,0.003 +parsing,1,0.003 +is_freeze_raw,11,0.001 +privacy checking,1,0.001 +privacy_access_levels,5,0.001 +resolving dependency formats,1,0.001 +adt_sized_constraint,9,0.001 +wf checking,1,0.001 +liveness checking,1,0.001 +compute_incremental_hashes_map,1,0.001 +match checking,1,0.001 +type collecting,1,0.001 +param_env,31,0.000 +effect checking,1,0.000 +trait_def,140,0.000 +lowering ast -> hir,1,0.000 +predicates_of,70,0.000 +extern_crate,319,0.000 +lifetime resolution,1,0.000 +is_const_fn,6,0.000 +intrinsic checking,1,0.000 +translation item collection,1,0.000 +impl_polarity,15,0.000 +creating allocators,1,0.000 +language item collection,1,0.000 +crate injection,1,0.000 +early lint checks,1,0.000 +indexing hir,1,0.000 +maybe creating a macro crate,1,0.000 +coherence checking,1,0.000 +optimized_mir,6,0.000 +is_panic_runtime,33,0.000 +associated_item_def_ids,7,0.000 +needs_drop_raw,10,0.000 +lint checking,1,0.000 +complete gated feature checking,1,0.000 +stability index,1,0.000 +region_maps,11,0.000 +super_predicates_of,8,0.000 +coherent_trait,2,0.000 +AST validation,1,0.000 +loop checking,1,0.000 +static item recursion checking,1,0.000 +variances_of,11,0.000 +associated_item,5,0.000 +plugin loading,1,0.000 +looking for plugin registrar,1,0.000 +stability checking,1,0.000 +describe_def,15,0.000 +variance testing,1,0.000 +codegen unit partitioning,1,0.000 +looking for entry point,1,0.000 +checking for inline asm in case the target doesn't support it,1,0.000 +inherent_impls,1,0.000 +crate_inherent_impls,1,0.000 +trait_of_item,7,0.000 +crate_inherent_impls_overlap_check,1,0.000 +attribute checking,1,0.000 +internalize symbols,1,0.000 +impl wf inference,1,0.000 +death checking,1,0.000 +reachability checking,1,0.000 +reachable_set,1,0.000 +is_exported_symbol,3,0.000 +is_mir_available,2,0.000 +unused lib feature checking,1,0.000 +maybe building test harness,1,0.000 +recursion limit,1,0.000 +write allocator module,1,0.000 +assert dep graph,1,0.000 +plugin registration,1,0.000 +write metadata,1,0.000 +``` + +# Background + +We give some background about the query model of the Rust compiler. + +## Def IDs + +In the query model, many queries have a key that consists of a Def ID. The Rust +compiler uses Def IDs to distinguish definitions in the input Rust program. + +From the compiler source code (`src/librustc/hir/def_id.rs`): + +``` +/// A DefId identifies a particular *definition*, by combining a crate +/// index and a def index. +#[derive(Clone, Eq, Ord, PartialOrd, PartialEq, RustcEncodable, RustcDecodable, Hash, Copy)] +pub struct DefId { + pub krate: CrateNum, + pub index: DefIndex, +} +``` + +## Queries + +A query relates a _key_ to a _result_, either by invoking a _provider_ that +computes this result, or by reusing a cached result that was provided earlier. +We explain each term in more detail: + +- Query **Provider**: Each kind of query has a pre-defined _provider_, which + refers to the compiler behavior that provides an answer to the query. These + providers may nest; see [trace of queries](#trace-of-queries) for more + information about this nesting structure. + _Example providers:_ + - `typeck_tables_of` -- Typecheck a Def ID; produce "tables" of type + information. + - `borrowck` -- Borrow-check a Def ID. + - `optimized_mir` -- Generate an optimized MIR for a Def ID; produce MIR. + - For more examples, see [Example 0](#counts-example-0). +- Query **Key**: The input/arguments to the provider. Often, this consists of a + particular [Def ID](#def-ids). +- Query **Result**: The output of the provider. + +## Trace of Queries + +Formally, a _trace_ of the queries consists of a _tree_, where sub-trees +represent sub-traces. In particular, the nesting structure of the trace of +queries describes how the queries depend on one another. + +Even more precisely, this tree represents a directed acyclic graph (DAG), where +shared sub-graphs consist of tree nodes that occur multiple times in the tree, +first as "cache misses" and later as "cache hits". + +**Cache hits and misses.** The trace is a tree with the following possible tree +nodes: + +- Query, with cache **miss**: The query's result is **unknown**, and its + provider runs to compute it. In this case, the dynamic extent of the query's + trace consists of the traced behavior of its provider. +- Query, with cache **hit**: The query's result is **known**, and is reused; its + provider does not rerun. These nodes are leaves in the trace, since they have + no dynamic extent. These leaves also represent where the tree, represented as + a DAG, would _share_ a sub-graph (namely, the sub-graph of the query that was + reused from the cache). + +**Tree node metrics.** To help determine how to style this tree, we define the +following tree node metrics: + +- **Depth**: The number of **ancestors** of the node in its path from the tree + root. +- **Extent**: The number of **immediate children** of the node. + +Intuitively, a dependency tree is "good" for incremental caching when the depth +and extent of each node is relatively small. It is pathological when either of +these metrics grows too large. For instance, a tree node whose extent consists +of 1M immediate children means that if and when this node is re-computed, all 1M +children must be re-queried, at the very least (some may also require +recomputation, too). + +## External Links + +Related design ideas, and tracking issues: + +- Design document: + [On-demand Rustc incremental design doc](https://github.com/nikomatsakis/rustc-on-demand-incremental-design-doc/blob/master/0000-rustc-on-demand-and-incremental.md) +- Tracking Issue: + ["Red/Green" dependency tracking in compiler](https://github.com/rust-lang/rust/issues/42293) + +More discussion and issues: + +- [GitHub issue #42633](https://github.com/rust-lang/rust/issues/42633) +- [Incremental Compilation Beta](https://internals.rust-lang.org/t/incremental-compilation-beta/4721) +- [Incremental Compilation Announcement](https://blog.rust-lang.org/2016/09/08/incremental.html) From e30bc0fcef9ba22c99f4d75326c056ad4ebade90 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 6 Dec 2019 11:24:22 -0600 Subject: [PATCH 0754/1812] fix link --- src/queries/profiling.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 0b574cd06..156fd65a9 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -74,7 +74,9 @@ _actual_ output is much longer. [View full HTML output][profile-example-html]. Note; it could take up to a second to properly render depending on your browser. -[profile-example-html]: https://github.com/rust-lang/rustc-guide/tree/master/src/queries/example-0.html +Here is the corresponding text output](./example-0.counts.txt). + +[profile-example-html]: ./example-0.html ### Example 0 explanation From e695b6225012f8ad97bdb7eaea6f8f6c14d2acf0 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Fri, 13 Dec 2019 11:01:05 -0600 Subject: [PATCH 0755/1812] update NLL after refactorings --- src/borrow_check.md | 19 ++++----- src/borrow_check/region_inference.md | 40 +++++++++---------- .../constraint_propagation.md | 16 ++++---- .../region_inference/lifetime_parameters.md | 12 +++--- src/borrow_check/type_check.md | 2 +- 5 files changed, 41 insertions(+), 48 deletions(-) diff --git a/src/borrow_check.md b/src/borrow_check.md index 0ceb21d72..034c36253 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -11,13 +11,8 @@ enforcing a number of properties: - That you can't mutate a place while it is immutably borrowed. - etc -At the time of this writing, the code is in a state of transition. The -"main" borrow checker still works by processing [the HIR](hir.html), -but that is being phased out in favor of the MIR-based borrow checker. -Accordingly, this documentation focuses on the new, MIR-based borrow -checker. - -Doing borrow checking on MIR has several advantages: +The borrow checker operates on the MIR. An older implementation operated on the +HIR. Doing borrow checking on MIR has several advantages: - The MIR is *far* less complex than the HIR; the radical desugaring helps prevent bugs in the borrow checker. (If you're curious, you @@ -42,15 +37,15 @@ the [`mir_borrowck`] query. we will modify this copy in place to modify the types and things to include references to the new regions that we are computing. - We then invoke [`replace_regions_in_mir`] to modify our local MIR. - Among other things, this function will replace all of the [regions](./appendix/glossary.html) in - the MIR with fresh [inference variables](./appendix/glossary.html). + Among other things, this function will replace all of the [regions](./appendix/glossary.md) in + the MIR with fresh [inference variables](./appendix/glossary.md). - Next, we perform a number of - [dataflow analyses](./appendix/background.html#dataflow) that + [dataflow analyses](./appendix/background.md#dataflow) that compute what data is moved and when. -- We then do a [second type check](borrow_check/type_check.html) across the MIR: +- We then do a [second type check](borrow_check/type_check.md) across the MIR: the purpose of this type check is to determine all of the constraints between different regions. -- Next, we do [region inference](borrow_check/region_inference.html), which computes +- Next, we do [region inference](borrow_check/region_inference.md), which computes the values of each region — basically, the points in the control-flow graph where each lifetime must be valid according to the constraints we collected. - At this point, we can compute the "borrows in scope" at each point. diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 5ae096574..84d30bdb4 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -1,11 +1,9 @@ # Region inference (NLL) -The MIR-based region checking code is located in -[the `rustc_mir::borrow_check::nll` module][nll]. (NLL, of course, -stands for "non-lexical lifetimes", a term that will hopefully be -deprecated once they become the standard kind of lifetime.) +The MIR-based region checking code is located in [the `rustc_mir::borrow_check` +module][nll]. -[nll]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/index.html +[nll]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html The MIR-based region analysis consists of two major functions: @@ -36,12 +34,12 @@ The MIR-based region analysis consists of two major functions: - The [NLL RFC] also includes fairly thorough (and hopefully readable) coverage. -[cp]: ./region_inference/constraint_propagation.html -[fvb]: ../appendix/background.html#free-vs-bound +[cp]: ./region_inference/constraint_propagation.md +[fvb]: ../appendix/background.md#free-vs-bound [`replace_regions_in_mir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.replace_regions_in_mir.html [`compute_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.compute_regions.html -[`RegionInferenceContext`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html -[`solve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.solve +[`RegionInferenceContext`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html +[`solve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.solve [NLL RFC]: https://rust-lang.github.io/rfcs/2094-nll.html [MIR type checker]: ./type_check.md @@ -68,7 +66,7 @@ the moment. TODO: write about _how_ these regions are computed. -[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/universal_regions/struct.UniversalRegions.html +[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/universal_regions/struct.UniversalRegions.html @@ -84,7 +82,7 @@ maintain a set storing what elements are present in its value (to make this efficient, we give each kind of element an index, the `RegionElementIndex`, and use sparse bitsets). -[ri]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check/nll/region_infer/ +[ri]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check/region_infer/ The kinds of region elements are as follows: @@ -115,7 +113,7 @@ common sorts of constraints are: 2. Liveness constraints. Each region needs to be live at points where it can be used. These constraints are collected by [`generate_constraints`]. -[`generate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraint_generation/fn.generate_constraints.html +[`generate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/constraint_generation/fn.generate_constraints.html ## Inference Overview @@ -219,12 +217,12 @@ Here are some of the fields of the struct: - [`closure_bounds_mapping`]: used for propagating region constraints from closures back out to the creator of the closure. -[`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.constraints -[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints -[`universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.universal_regions -[`universal_region_relations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.universal_region_relations -[`type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.type_tests -[`closure_bounds_mapping`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.closure_bounds_mapping +[`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.constraints +[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints +[`universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_regions +[`universal_region_relations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_region_relations +[`type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.type_tests +[`closure_bounds_mapping`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.closure_bounds_mapping TODO: should we discuss any of the others fields? What about the SCCs? @@ -233,6 +231,6 @@ inference. This is done by calling the [`solve`] method on the context. This is where we call [`propagate_constraints`] and then check the resulting type tests and universal regions, as discussed above. -[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints -[`check_type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_type_tests -[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions +[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints +[`check_type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.check_type_tests +[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 5f3b29c6d..ee86ae148 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -10,7 +10,7 @@ on one at a time (each of them is fairly independent from the others): - outlives constraints (`R1: R2`), which arise from subtyping; - [member constraints][m_c] (`member R_m of [R_c...]`), which arise from impl Trait. -[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints +[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints [m_c]: ./member_constraints.md In this chapter, we'll explain the "heart" of constraint propagation, @@ -68,8 +68,8 @@ though; instead, we store a (sparse) bitset per region variable (of type [`LivenessValues`]). This way we only need a single bit for each liveness constraint. -[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints -[`LivenessValues`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/values/struct.LivenessValues.html +[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints +[`LivenessValues`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/values/struct.LivenessValues.html One thing that is worth mentioning: All lifetime parameters are always considered to be live over the entire function body. This is because @@ -112,9 +112,9 @@ induces an edge `'a -> 'b`. This conversion happens in the [`RegionInferenceContext::new`] function that creates the inference context. -[`ConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.OutlivesConstraintSet.html -[graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/constraints/struct.OutlivesConstraintSet.html#method.graph -[`RegionInferenceContext::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.new +[`ConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/constraints/struct.OutlivesConstraintSet.html +[graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/constraints/struct.OutlivesConstraintSet.html#method.graph +[`RegionInferenceContext::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.new When using a graph representation, we can detect regions that must be equal by looking for cycles. That is, if you have a constraint like @@ -146,8 +146,8 @@ of fields are defined in terms of SCCs. For example, the of a specific region `'a` then, we first figure out the SCC that the region is a part of, and then find the value of that SCC. -[`constraint_sccs`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.constraint_sccs -[`scc_values`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#structfield.scc_values +[`constraint_sccs`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.constraint_sccs +[`scc_values`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.scc_values When we compute SCCs, we not only figure out which regions are a member of each SCC, we also figure out the edges between them. So for example diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index 0d5219aa9..4086b71ef 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -29,9 +29,9 @@ relationships to one another. So if you have e.g. `where 'a: 'b`, then the [`UniversalRegionRelations`] struct would track that `'a: 'b` is known to hold (which could be tested with the [`outlives`] function. -[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/universal_regions/struct.UniversalRegions.html -[`UniversalRegionRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/type_check/free_region_relations/struct.UniversalRegionRelations.html -[`outlives`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/type_check/free_region_relations/struct.UniversalRegionRelations.html#method.outlives +[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/universal_regions/struct.UniversalRegions.html +[`UniversalRegionRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/type_check/free_region_relations/struct.UniversalRegionRelations.html +[`outlives`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/type_check/free_region_relations/struct.UniversalRegionRelations.html#method.outlives ## Everything is a region variable @@ -56,7 +56,7 @@ type). These subdivisions are not important for the topics discussed here, but become important when we consider [closure constraint propagation](./closure_constraints.html), so we discuss them there. -[`RegionClassification`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/universal_regions/enum.RegionClassification.html#variant.Local +[`RegionClassification`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/universal_regions/enum.RegionClassification.html#variant.Local ## Universal lifetimes as the elements of a region's value @@ -86,7 +86,7 @@ liveness constraint (i.e., `'a` must extend until the end of itself). In the code, these liveness constraints are setup in [`init_free_and_bound_regions`]. -[`init_free_and_bound_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.init_free_and_bound_regions +[`init_free_and_bound_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.init_free_and_bound_regions ## Propagating outlives constraints for universal regions @@ -122,4 +122,4 @@ not, as in our example, that is an error. This check is done in the universal regions, inspects their final value, and tests against the declared [`UniversalRegionRelations`]. -[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions +[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions diff --git a/src/borrow_check/type_check.md b/src/borrow_check/type_check.md index ee955d971..0db895619 100644 --- a/src/borrow_check/type_check.md +++ b/src/borrow_check/type_check.md @@ -1,7 +1,7 @@ # The MIR type-check A key component of the borrow check is the -[MIR type-check](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/type_check/index.html). +[MIR type-check](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/type_check/index.html). This check walks the MIR and does a complete "type check" -- the same kind you might find in any other language. In the process of doing this type-check, we also uncover the region constraints that apply to From 6dd78f5b15dbffb6bb90a4313173edc9ea9d9dcb Mon Sep 17 00:00:00 2001 From: Christoph Schmidler Date: Mon, 16 Dec 2019 10:25:00 +0100 Subject: [PATCH 0756/1812] Correct statement that wrongly claims the json emitter still lives in libsyntax crate --- src/diagnostics.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index c6c8f4fba..e4fb443c1 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -357,14 +357,12 @@ string; this was introduced so that UI tests could both make use of the structured JSON and see the "human" output (well, _sans_ colors) without having to compile everything twice. -The JSON emitter currently lives in libsyntax/json.rs. (But arguably -it should live in librustc_errors along with the "human" emitter? It's -not obvious to the present author why it wasn't moved from libsyntax -to librustc_errors at the same [time the "human" emitter was -moved](https://github.com/rust-lang/rust/commit/6ae3502134).) +The "human" readable and the json format emitter can be found under +librustc_errors, both were moved from the libsyntax crate to the +[librustc_errors crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html). The JSON emitter defines [its own `Diagnostic` -struct](https://github.com/rust-lang/rust/blob/b2c6b8c29f13f8d1f242da89e587960b95337819/src/libsyntax/json.rs#L85-L99) +struct](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/json/struct.Diagnostic.html) (and sub-structs) for the JSON serialization. Don't confuse this with [`errors::Diagnostic`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Diagnostic.html)! From bd77dc061af0ce43904eef7a4ef3453b2c24060e Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 20 Dec 2019 04:28:42 +0200 Subject: [PATCH 0757/1812] salsa: reduce overlong sentence --- src/salsa.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/salsa.md b/src/salsa.md index b34647ad1..68e92b29f 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -9,8 +9,8 @@ This chapter is based on the explanation given by Niko Matsakis in this ## What is Salsa? -Salsa is a library for incremental recomputation, this means reusing -computation that has already been done in the past to increase the efficiency +Salsa is a library for incremental recomputation. This means it allows reusing +computations that were already done in the past to increase the efficiency of future computations. The objectives of Salsa are: From a6cf2843b99c8cbff714ee876afcf193a37131af Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 20 Dec 2019 04:51:08 +0200 Subject: [PATCH 0758/1812] chalk: place brackets in usual positions --- src/traits/chalk-overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 0f102d4d0..a33cbcc63 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -7,8 +7,8 @@ [Chalk][chalk] recasts Rust's trait system explicitly in terms of logic programming by "lowering" Rust code into a kind of logic program we can then -execute queries against. (See [*Lowering to Logic*][lowering-to-logic] and -[*Lowering Rules*][lowering-rules]) Its goal is to be an executable, highly +execute queries against (see [*Lowering to Logic*][lowering-to-logic] and +[*Lowering Rules*][lowering-rules]). Its goal is to be an executable, highly readable specification of the Rust trait system. There are many expected benefits from this work. It will consolidate our From 3e7993aefead29c3c492a26978595132fc53462d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 21 Dec 2019 07:00:09 -0600 Subject: [PATCH 0759/1812] Document rustc internal env vars a little bit (#513) --- src/building/bootstrapping.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 126509077..5bdc8dc6f 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -159,3 +159,20 @@ links against. This `stage2/bin/rustc` compiler is shipped to end-users, along with the `stage 1 {std,rustc}` artifacts. +## Environment Variables + +During bootstrapping, there are a bunch of compiler-internal environment +variables that are used. If you are trying to run an intermediate version of +`rustc`, sometimes you may need to set some of these environment variables +manually. Otherwise, you get an error like the following: + +```text +thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', src/libcore/result.rs:1165:5 +``` + +If `./stageN/bin/rustc` gives an error about environment variables, that +usually means something is quite wrong -- or you're trying to compile e.g. +`librustc` or `libstd` or something that depends on environment variables. In +the unlikely case that you actually need to invoke rustc in such a situation, +you can find the environment variable values by adding the following flag to +your `x.py` command: `--on-fail=print-env`. From 6c09a68d97765f324afb06b1ec727bda0413013f Mon Sep 17 00:00:00 2001 From: Ross MacArthur Date: Sun, 22 Dec 2019 17:20:48 +0200 Subject: [PATCH 0760/1812] Rewrap stability.md to column 79 --- src/stability.md | 83 +++++++++++++++++++++++++----------------------- 1 file changed, 44 insertions(+), 39 deletions(-) diff --git a/src/stability.md b/src/stability.md index 1db738cb2..86d2a2e69 100644 --- a/src/stability.md +++ b/src/stability.md @@ -1,30 +1,32 @@ # Stability attributes -This section is about the stability attributes and schemes that allow stable APIs to use unstable -APIs internally in the rustc standard library. +This section is about the stability attributes and schemes that allow stable +APIs to use unstable APIs internally in the rustc standard library. -For instructions on stabilizing a language feature see -[Stabilizing Features](./stabilization_guide.md). +For instructions on stabilizing a language feature see [Stabilizing +Features](./stabilization_guide.md). ## unstable -The `#[unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` attribute explicitly -marks an item as unstable. Items that are marked as "unstable" cannot be used -without a corresponding `#![feature]` attribute on the crate, even on a -nightly compiler. This restriction only applies across crate boundaries, unstable -items may be used within the crate they are defined. +The `#[unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` +attribute explicitly marks an item as unstable. Items that are marked as +"unstable" cannot be used without a corresponding `#![feature]` attribute on +the crate, even on a nightly compiler. This restriction only applies across +crate boundaries, unstable items may be used within the crate they are defined. -The `unstable` attribute infects all sub-items, where the attribute doesn't have to be -reapplied. So if you apply this to a module, all items in the module will be unstable. +The `unstable` attribute infects all sub-items, where the attribute doesn't +have to be reapplied. So if you apply this to a module, all items in the module +will be unstable. -You can make specific sub-items stable by using the `#[stable]` attribute on them. -The stability scheme works similarly to how `pub` works. You can have public functions of -nonpublic modules and you can have stable functions in unstable modules or vice versa. +You can make specific sub-items stable by using the `#[stable]` attribute on +them. The stability scheme works similarly to how `pub` works. You can have +public functions of nonpublic modules and you can have stable functions in +unstable modules or vice versa. Note, however, that due to a [rustc bug], stable items inside unstable modules *are* available to stable code in that location! So, for example, stable code -can import `core::intrinsics::transmute` even though `intrinsics` is an unstable -module. Thus, this kind of nesting should be avoided when possible. +can import `core::intrinsics::transmute` even though `intrinsics` is an +unstable module. Thus, this kind of nesting should be avoided when possible. The `unstable` attribute may also have the `soft` value, which makes it a future-incompatible deny-by-default lint instead of a hard error. This is used @@ -35,29 +37,32 @@ prevents breaking dependencies by leveraging Cargo's lint capping. ## stable -The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks an item as -stabilized. To do this, follow the instructions in +The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly +marks an item as stabilized. To do this, follow the instructions in [Stabilizing Features](./stabilization_guide.md). Note that stable functions may use unstable things in their body. ## allow_internal_unstable -Macros, compiler desugarings and `const fn`s expose their bodies to the call site. To -work around not being able to use unstable things in the standard library's macros, there's the -`#[allow_internal_unstable(feature1, feature2)]` attribute that whitelists the given features for -usage in stable macros or `const fn`s. - -Note that `const fn`s are even more special in this regard. You can't just whitelist any feature, -the features need an implementation in `qualify_min_const_fn.rs`. For example the `const_fn_union` -feature gate allows accessing fields of unions inside stable `const fn`s. The rules for when it's -ok to use such a feature gate are that behavior matches the runtime behavior of the same code -(see also [this blog post][blog]). This means that you may not create a -`const fn` that e.g. transmutes a memory address to an integer, because the addresses of things -are nondeterministic and often unknown at compile-time. - -Always ping @oli-obk, @RalfJung, and @Centril if you are adding more `allow_internal_unstable` -attributes to any `const fn` +Macros, compiler desugarings and `const fn`s expose their bodies to the call +site. To work around not being able to use unstable things in the standard +library's macros, there's the `#[allow_internal_unstable(feature1, feature2)]` +attribute that whitelists the given features for usage in stable macros or +`const fn`s. + +Note that `const fn`s are even more special in this regard. You can't just +whitelist any feature, the features need an implementation in +`qualify_min_const_fn.rs`. For example the `const_fn_union` feature gate allows +accessing fields of unions inside stable `const fn`s. The rules for when it's +ok to use such a feature gate are that behavior matches the runtime behavior of +the same code (see also [this blog post][blog]). This means that you may not +create a `const fn` that e.g. transmutes a memory address to an integer, +because the addresses of things are nondeterministic and often unknown at +compile-time. + +Always ping @oli-obk, @RalfJung, and @Centril if you are adding more +`allow_internal_unstable` attributes to any `const fn` ## staged_api @@ -83,13 +88,13 @@ item must also have a `stable` or `unstable` attribute. )] ``` -The `suggestion` field is optional. If given, it should be a string that can -be used as a machine-applicable suggestion to correct the warning. This is -typically used when the identifier is renamed, but no other significant -changes are necessary. +The `suggestion` field is optional. If given, it should be a string that can be +used as a machine-applicable suggestion to correct the warning. This is +typically used when the identifier is renamed, but no other significant changes +are necessary. -Another difference from the `deprecated` attribute is that the `since` field -is actually checked against the current version of `rustc`. If `since` is in a +Another difference from the `deprecated` attribute is that the `since` field is +actually checked against the current version of `rustc`. If `since` is in a future version, then the `deprecated_in_future` lint is triggered which is default `allow`, but most of the standard library raises it to a warning with `#![warn(deprecated_in_future)]`. From 8a232d0d2f0198bc2a73376dee12a58cf8e89ad8 Mon Sep 17 00:00:00 2001 From: Ross MacArthur Date: Sun, 22 Dec 2019 17:21:02 +0200 Subject: [PATCH 0761/1812] Update stability documentation, mention `issue = "none"` --- src/stability.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/stability.md b/src/stability.md index 86d2a2e69..9e75495b1 100644 --- a/src/stability.md +++ b/src/stability.md @@ -14,6 +14,10 @@ attribute explicitly marks an item as unstable. Items that are marked as the crate, even on a nightly compiler. This restriction only applies across crate boundaries, unstable items may be used within the crate they are defined. +The `issue` field specifies the associated GitHub [issue number]. This field is +required and all unstable features should have an associated tracking issue. In +rare cases where there is no sensible value `issue = "none"` is used. + The `unstable` attribute infects all sub-items, where the attribute doesn't have to be reapplied. So if you apply this to a module, all items in the module will be unstable. @@ -33,6 +37,7 @@ future-incompatible deny-by-default lint instead of a hard error. This is used by the `bench` attribute which was accidentally accepted in the past. This prevents breaking dependencies by leveraging Cargo's lint capping. +[issue number]: https://github.com/rust-lang/rust/issues [rustc bug]: https://github.com/rust-lang/rust/issues/15702 ## stable From 846743c7139be4aeb4f406b02e3441ab16ac18ff Mon Sep 17 00:00:00 2001 From: Ross MacArthur Date: Sun, 22 Dec 2019 23:36:34 +0200 Subject: [PATCH 0762/1812] Minor update to stability.md --- src/stability.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/stability.md b/src/stability.md index 9e75495b1..292d88813 100644 --- a/src/stability.md +++ b/src/stability.md @@ -12,7 +12,8 @@ The `#[unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` attribute explicitly marks an item as unstable. Items that are marked as "unstable" cannot be used without a corresponding `#![feature]` attribute on the crate, even on a nightly compiler. This restriction only applies across -crate boundaries, unstable items may be used within the crate they are defined. +crate boundaries, unstable items may be used within the crate that defines +them. The `issue` field specifies the associated GitHub [issue number]. This field is required and all unstable features should have an associated tracking issue. In From c461c8597e831442b77e53c877e5f8d8166d6a1b Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Tue, 24 Dec 2019 01:16:23 +0100 Subject: [PATCH 0763/1812] Introduce `rustc_const_stable` and explain `rustc_const_unstable` (#542) --- src/stability.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/src/stability.md b/src/stability.md index 292d88813..f48c3d529 100644 --- a/src/stability.md +++ b/src/stability.md @@ -49,6 +49,28 @@ marks an item as stabilized. To do this, follow the instructions in Note that stable functions may use unstable things in their body. +## rustc_const_unstable + +The `#[rustc_const_unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` +has the same interface as the `unstable` attribute. It is used to mark +`const fn` as having their constness be unstable. This allows you to make a +function stable without stabilizing its constness or even just marking an existing +stable function as `const fn` without instantly stabilizing the `const fn`ness. + +Furthermore this attribute is needed to mark an intrinsic as `const fn`, because +there's no way to add `const` to functions in `extern` blocks for now. + +## rustc_const_stable + +The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks +a `const fn` as having its constness be `stable`. This attribute can make sense +even on an `unstable` function, if that function is called from another +`rustc_const_stable` function. + +Furthermore this attribute is needed to mark an intrinsic as callable from +`rustc_const_stable` functions. + + ## allow_internal_unstable Macros, compiler desugarings and `const fn`s expose their bodies to the call From ad604436f3a1331a59c7b01965be2f61e837f9fa Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 26 Dec 2019 13:47:36 +0900 Subject: [PATCH 0764/1812] Update link --- src/appendix/bibliography.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index c3d0446c7..7c27a3ed6 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -45,7 +45,7 @@ Rust, as well as publications about Rust. * [GPU Programming in Rust: Implementing High Level Abstractions in a Systems Level - Language](https://www.cs.indiana.edu/~achauhan/Publications/Pubs/2013-hips-holk-rust.pdf). + Language](https://ieeexplore.ieee.org/document/6650903). Early GPU work by Eric Holk. * [Parallel closures: a new twist on an old idea](https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea) From e997e06db1d79bc46298c1d345f6f4d3ddd80112 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 29 Dec 2019 06:44:47 +0900 Subject: [PATCH 0765/1812] Fix link --- src/miri.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/miri.md b/src/miri.md index 09c31e0a5..1f11633a7 100644 --- a/src/miri.md +++ b/src/miri.md @@ -97,7 +97,7 @@ Miri, but just use the cached result. [`Immediate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.Immediate.html [`ConstValue`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.ConstValue.html [`Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.Scalar.html -[`op_to_const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/fn.op_to_const.html +[`op_to_const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/eval_queries/fn.op_to_const.html ## Datastructures From 423808fb45aa1b15c796d0271778903119930510 Mon Sep 17 00:00:00 2001 From: YOUNGSUK KIM Date: Sat, 28 Dec 2019 16:26:14 -0500 Subject: [PATCH 0766/1812] minor grammar fixes --- src/codegen.md | 2 +- src/conventions.md | 2 +- src/diagnostics.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/codegen.md b/src/codegen.md index c8d51f318..c7d2fc071 100644 --- a/src/codegen.md +++ b/src/codegen.md @@ -39,7 +39,7 @@ There are a few benefits to using LLVM: and maintenance burden. - We benefit from the large suite of advanced optimizations that the LLVM project has been collecting. -- We automatically can compile Rust to any of the platforms for which LLVM has +- We can automatically compile Rust to any of the platforms for which LLVM has support. For example, as soon as LLVM added support for wasm, voila! rustc, clang, and a bunch of other languages were able to compile to wasm! (Well, there was some extra stuff to be done, but we were 90% there anyway). diff --git a/src/conventions.md b/src/conventions.md index 76933d574..7f7bf32e2 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -20,7 +20,7 @@ in isolation with `./x.py test src/tools/tidy`. ### Copyright notice -In the past, files begin with a copyright and license notice. Please **omit** +In the past, files began with a copyright and license notice. Please **omit** this notice for new files licensed under the standard terms (dual MIT/Apache-2.0). diff --git a/src/diagnostics.md b/src/diagnostics.md index e4fb443c1..f646d70a2 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -34,7 +34,7 @@ warnings, errors, fatal errors, suggestions, etc. [parsesses]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html [session]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html -In general, there are two class of such methods: ones that emit an error +In general, there are two classes of such methods: ones that emit an error directly and ones that allow finer control over what to emit. For example, [`span_err`][spanerr] emits the given error message at the given `Span`, but [`struct_span_err`][strspanerr] instead returns a From e668a1ff295cdb8ba389260e5423933e8ae6a0d9 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 31 Dec 2019 06:46:18 -0600 Subject: [PATCH 0767/1812] add a bit about def path (#548) --- src/hir.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/hir.md b/src/hir.md index 0a48d1123..67becec12 100644 --- a/src/hir.md +++ b/src/hir.md @@ -102,6 +102,12 @@ sorts of identifiers in active use: [`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html [`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html +We also have an internal map to go from `DefId` to what’s called "Def path". "Def path" is like a +module path but a bit more rich. For example, it may be `crate::foo::MyStruct` that identifies +this definition uniquely. It’s a bit different than a module path because it might include a type +parameter `T`, which you can't write in normal rust, like `crate::foo::MyStruct::T`. These are used +in incremental compilation. + ### The HIR Map Most of the time when you are working with the HIR, you will do so via From a59a6124510efbab4c02a323bbab570b867c15c9 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 31 Dec 2019 06:46:49 -0600 Subject: [PATCH 0768/1812] More info about using local LLVM (#547) * more info about llvm-config * typo Co-Authored-By: Santiago Pastorino Co-authored-by: Santiago Pastorino --- src/building/suggested.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 07f834eac..087e9dee8 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -74,5 +74,15 @@ This is specified in the `target` section of `config.toml`: llvm-config = "/path/to/llvm/llvm-7.0.1/bin/llvm-config" ``` -On my system, this path is `/usr/bin/llvm-config-7`, but this probably varies -by installation. +We have observed the following paths before, which may be different from your system: + +- `/usr/bin/llvm-config-8` +- `/usr/lib/llvm-8/bin/llvm-config` + +Note that you need to have the LLVM `FileCheck` tool installed, which is used +for codegen tests. This tool is normally built with LLVM, but if you use your +own preinstalled LLVM, you will need to provide `FileCheck` in some other way. +On Debian-based systems, you can install the `llvm-N-tools` package (where `N` +is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify +the path to `FileCheck` with the `llvm-filecheck` config item in `config.toml` +or you can disable codegen test with the `codegen-tests` item in `config.toml`. From b5c6babcdd4ce1fa90458b7827a5fde082e79e87 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 1 Jan 2020 03:45:01 +0900 Subject: [PATCH 0769/1812] Fix links (#549) --- src/appendix/code-index.md | 4 ++-- src/high-level-overview.md | 2 +- src/macro-expansion.md | 28 ++++++++++++++-------------- 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 1c8d1d707..062293f7e 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -21,9 +21,9 @@ Item | Kind | Short description | Chapter | `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) `Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) -`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/libsyntax_pos/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) +`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/librustc_span/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) -`Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/libsyntax_pos/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax_pos/struct.Span.html) +`Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/librustc_span/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html) `syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 625559034..e4b9ff372 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -36,7 +36,7 @@ rustc_codegen rustc_borrowck ... rustc_metadata syntax / \ / \ - syntax_pos syntax_ext + rustc_span rustc_builtin_macros ``` The `rustc_driver` crate, at the top of this lattice, is effectively diff --git a/src/macro-expansion.md b/src/macro-expansion.md index a3a3ae762..9280fa9bc 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -1,6 +1,6 @@ # Macro expansion -> `libsyntax`, `librustc_expand`, and `libsyntax_ext` are all undergoing +> `libsyntax`, `librustc_expand`, and `librustc_builtin_macros` are all undergoing > refactoring, so some of the links in this chapter may be broken. Macro expansion happens during parsing. `rustc` has two parsers, in fact: the @@ -10,7 +10,7 @@ before name resolution, macros are expanded using these portions of the code. The macro parser, in turn, may call the normal Rust parser when it needs to bind a metavariable (e.g. `$my_expr`) while parsing the contents of a macro invocation. The code for macro expansion is in -[`src/libsyntax_expand/mbe/`][code_dir]. This chapter aims to explain how macro +[`src/librustc_expand/mbe/`][code_dir]. This chapter aims to explain how macro expansion works. ### Example @@ -64,7 +64,7 @@ invocations. Interestingly, both are done by the macro parser. Basically, the macro parser is like an NFA-based regex parser. It uses an algorithm similar in spirit to the [Earley parsing algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is -defined in [`src/libsyntax_expand/mbe/macro_parser.rs`][code_mp]. +defined in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp]. The interface of the macro parser is as follows (this is slightly simplified): @@ -113,7 +113,7 @@ normal Rust parser. As mentioned above, both definitions and invocations of macros are parsed using the macro parser. This is extremely non-intuitive and self-referential. The code to parse macro _definitions_ is in -[`src/libsyntax_expand/mbe/macro_rules.rs`][code_mr]. It defines the pattern for +[`src/librustc_expand/mbe/macro_rules.rs`][code_mr]. It defines the pattern for matching for a macro definition as `$( $lhs:tt => $rhs:tt );+`. In other words, a `macro_rules` definition should have in its body at least one occurrence of a token tree followed by `=>` followed by another token tree. When the compiler @@ -142,7 +142,7 @@ the parse is ambiguous, while if there are no matches at all, there is a syntax error. For more information about the macro parser's implementation, see the comments -in [`src/libsyntax_expand/mbe/macro_parser.rs`][code_mp]. +in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp]. ### Hygiene @@ -208,10 +208,10 @@ TODO TODO: maybe something about macros 2.0? -[code_dir]: https://github.com/rust-lang/rust/tree/master/src/libsyntax_expand/mbe -[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax_expand/mbe/macro_parser -[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax_expand/mbe/macro_rules -[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax_expand/mbe/macro_parser/fn.parse.html +[code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe +[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser +[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules +[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse.html [parsing]: ./the-parser.html @@ -356,11 +356,11 @@ Vadim Petrochenkov: Here's some preliminary data I prepared. Vadim Petrochenkov: Below I'll assume #62771 and #62086 has landed. -Vadim Petrochenkov: Where to find the code: libsyntax_pos/hygiene.rs - +Vadim Petrochenkov: Where to find the code: librustc_span/hygiene.rs - structures related to hygiene and expansion that are kept in global data (can -be accessed from any Ident without any context) libsyntax_pos/lib.rs - some +be accessed from any Ident without any context) librustc_span/lib.rs - some secondary methods like macro backtrace using primary methods from hygiene.rs -libsyntax_ext - implementations of built-in macros (including macro attributes +librustc_builtin_macros - implementations of built-in macros (including macro attributes and derives) and some other early code generation facilities like injection of standard library imports or generation of test harness. libsyntax/config.rs - implementation of cfg/cfg_attr (they treated specially from other macros), @@ -375,8 +375,8 @@ AST libsyntax/ext/placeholder.rs - the part of expand.rs responsible for "integrating the results back into AST" basicallly, "placeholder" is a temporary AST node replaced with macro expansion result nodes libsyntax/ext/builer.rs - helper functions for building AST for built-in macros -in libsyntax_ext (and user-defined syntactic plugins previously), can probably -be moved into libsyntax_ext these days libsyntax/ext/proc_macro.rs + +in librustc_builtin_macros (and user-defined syntactic plugins previously), can probably +be moved into librustc_builtin_macros these days libsyntax/ext/proc_macro.rs + libsyntax/ext/proc_macro_server.rs - interfaces between the compiler and the stable proc_macro library, converting tokens and token streams between the two representations and sending them through C ABI libsyntax/ext/tt - From a675ddedef4c70961b8db3ea67158bd0e180cb02 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Tue, 29 Oct 2019 18:18:04 -0400 Subject: [PATCH 0770/1812] Add panic implementation docs --- src/SUMMARY.md | 1 + src/panic-implementation.md | 105 ++++++++++++++++++++++++++++++++++++ 2 files changed, 106 insertions(+) create mode 100644 src/panic-implementation.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 7b334c36c..125e20cf6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -44,6 +44,7 @@ - [Salsa](./salsa.md) - [Lexing and Parsing](./the-parser.md) - [`#[test]` Implementation](./test-implementation.md) + - [Panic Implementation](./panic-implementation.md) - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) - [The HIR (High-level IR)](./hir.md) diff --git a/src/panic-implementation.md b/src/panic-implementation.md new file mode 100644 index 000000000..d8bb4c315 --- /dev/null +++ b/src/panic-implementation.md @@ -0,0 +1,105 @@ +### Panicking in rust ### + +#### Step 1: Invocation of the `panic!` macro. + +There are actually two panic macros - one defined in `libcore`, and one defined in `libstd`. +This is due to the fact that code in `libcore` can panic. `libcore` is built before `libsd`, +but we want panics to use the same machinery at runtime, whether they originate in `libcore` or `libstd`. + +##### libcore definition of panic! + +The `libcore` `panic!` macro eventually makes the following call (in `src/libcore/panicking.rs`): + +```rust +// NOTE This function never crosses the FFI boundary; it's a Rust-to-Rust call +extern "Rust" { + #[lang = "panic_impl"] + fn panic_impl(pi: &PanicInfo<'_>) -> !; +} + +let pi = PanicInfo::internal_constructor(Some(&fmt), location); +unsafe { panic_impl(&pi) } +``` + +Actually resolving this goes through several layers of indirection: + +1. In `src/librustc/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item', + with the symbol `rust_begin_unwind`. This is used in `librustc_typeck/collect.rs` + to set the actual symbol name to `rust_begin_unwind`. + + Note that `panic_impl` is declared in an `extern "Rust"` block, + which means that libcore will attempt to call a foreign symbol called `rust_begin_unwind` + (to be resolved at link time) + +2. In `src/libstd/panicking.rs`, we have this definition: + +```rust +/// Entry point of panic from the libcore crate. +[cfg(not(test))] +[panic_handler] +[unwind(allowed)] +pub fn rust_begin_panic(info: &PanicInfo<'_>) -> ! { + continue_panic_fmt(&info) +} +``` + +The special `panic_handler` attribute is resolved via `src/librustc/middle/lang_items`. +The `extract` functions convers the `panic_handler` attribute to a `panic_impl` lang item. + +Now, we have a matching `panic_impl` lang item in the `libstd`. This function goes +through the same process as the `extern { fn panic_impl }` definition in `libcore`, ending +up with a symbol name of `rust_begin_unwind`. At link time, the symbol refernce in `libcore` +will be resolved to the definition of `libstd` (the function called `rust_begin_panic` in the +Rust source). + +Thus, control flow will pass from libcore to std at runtime. This allows panics from `libcore` +to go through the same infratructure that other panics use (panic hooks, unwinding, etc) + +##### libstd implementation of panic! + +This is where the actual panic-related logic begins. In `src/libstd/pancking.rs`, +control passes to `rust_panic_with_hook`. This method is responsible +for checking for invoking the global panic hook, and checking for double panics. Finally, +we call ```__rust_start_panic```, which is provided by the panic runtime. + +The call to ```__rust_start_panic``` is very weird - it is passed a ```*mut &mut dyn BoxMeUp```, +converted to an `usize`. Let's break this type down: + +1. `BoxMeUp` is an internal trait. It is implemented for `PanicPayload` (a wrapper around the user-supplied +payload type), and has a method ```fn box_me_up(&mut self) -> *mut (dyn Any + Send)```. +This method takes the user-provided payload (`T: Any + Send`), boxes it, and convertes the box to a raw pointer. + +2. When we call ```__rust_start_panic```, we have an `&mut dyn BoxMeUp`. However, this is a fat pointer +(twice the size of a `usize`). To pass this to the panic runtime across an FFI boundary, we take a mutable +reference *to this mutable reference* (`&mut &mut dyn BoxMeUp`), and convert it to a raw pointer +(`*mut &mut dyn BoxMeUp`). The outer raw pointer is a thin pointer, since it points to a `Sized` +type (a mutable reference). Therefore, we can convert this thin pointer into a `usize`, which +is suitable for passing across an FFI boundary. + +Finally, we call ```__rust_start_panic``` with this `usize`. We have now entered the panic runtime. + +#### Step 2: The panic runtime + +Rust provides two panic runtimes: `libpanic_abort` and `libpanic_unwind`. The user chooses +between them at build time via their `Cargo.toml` + +`libpanic_abort` is extremely simple: its implementation of ```__rust_start_panic``` just aborts, +as you would expect. + +`libpanic_unwind` is the more interesting case. + +In its implementation of ```__rust_start_panic```, we take the `usize`, convert +it back to a `*mut &mut dyn BoxMeUp`, dereference it, and call `box_me_up` +on the `&mut dyn BoxMeUp`. At this point, we have a raw pointer to the payload +itself (a `*mut (dyn Send + Any)`): that is, a raw pointer to the actual value +provided by the user who called `panic!`. + +At this point, the platform-independent code ends. We now call into +platform-specific unwinding logic (e.g `libunwind`). This code is +responsible for unwinding the stack, running any 'landing pads' associated +with each frame (currently, running destructors), and transferring control +to the `catch_unwind` frame. + +Note that all panics either abort the process or get caught by some call to `catch_unwind`: +in `src/libstd/rt.rs`, the call to the user-provided `main` function is wrapped in `catch_unwind + From 90af55903a19e5c5cbfab24de08c3a93f509dcbb Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:06:44 -0500 Subject: [PATCH 0771/1812] Apply some fixes Co-Authored-By: Who? Me?! --- src/panic-implementation.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/panic-implementation.md b/src/panic-implementation.md index d8bb4c315..41338ce0d 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -44,7 +44,7 @@ pub fn rust_begin_panic(info: &PanicInfo<'_>) -> ! { ``` The special `panic_handler` attribute is resolved via `src/librustc/middle/lang_items`. -The `extract` functions convers the `panic_handler` attribute to a `panic_impl` lang item. +The `extract` function converts the `panic_handler` attribute to a `panic_impl` lang item. Now, we have a matching `panic_impl` lang item in the `libstd`. This function goes through the same process as the `extern { fn panic_impl }` definition in `libcore`, ending @@ -59,7 +59,7 @@ to go through the same infratructure that other panics use (panic hooks, unwindi This is where the actual panic-related logic begins. In `src/libstd/pancking.rs`, control passes to `rust_panic_with_hook`. This method is responsible -for checking for invoking the global panic hook, and checking for double panics. Finally, +for invoking the global panic hook, and checking for double panics. Finally, we call ```__rust_start_panic```, which is provided by the panic runtime. The call to ```__rust_start_panic``` is very weird - it is passed a ```*mut &mut dyn BoxMeUp```, @@ -101,5 +101,4 @@ with each frame (currently, running destructors), and transferring control to the `catch_unwind` frame. Note that all panics either abort the process or get caught by some call to `catch_unwind`: -in `src/libstd/rt.rs`, the call to the user-provided `main` function is wrapped in `catch_unwind - +in `src/libstd/rt.rs`, the call to the user-provided `main` function is wrapped in `catch_unwind`. From 25c226cfa886f6489ba685953b28bf316cf122fd Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:03:27 -0500 Subject: [PATCH 0772/1812] Fix typo --- src/panic-implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 41338ce0d..7de4bc0a2 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -3,7 +3,7 @@ #### Step 1: Invocation of the `panic!` macro. There are actually two panic macros - one defined in `libcore`, and one defined in `libstd`. -This is due to the fact that code in `libcore` can panic. `libcore` is built before `libsd`, +This is due to the fact that code in `libcore` can panic. `libcore` is built before `libstd`, but we want panics to use the same machinery at runtime, whether they originate in `libcore` or `libstd`. ##### libcore definition of panic! From 6897e6b8cfe7fbd32b6bc0620b1f579f1c963320 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:10:02 -0500 Subject: [PATCH 0773/1812] Fix name of lang item --- src/panic-implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 7de4bc0a2..4dbc5e613 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -46,7 +46,7 @@ pub fn rust_begin_panic(info: &PanicInfo<'_>) -> ! { The special `panic_handler` attribute is resolved via `src/librustc/middle/lang_items`. The `extract` function converts the `panic_handler` attribute to a `panic_impl` lang item. -Now, we have a matching `panic_impl` lang item in the `libstd`. This function goes +Now, we have a matching `panic_handler` lang item in the `libstd`. This function goes through the same process as the `extern { fn panic_impl }` definition in `libcore`, ending up with a symbol name of `rust_begin_unwind`. At link time, the symbol refernce in `libcore` will be resolved to the definition of `libstd` (the function called `rust_begin_panic` in the From 7c078d35b4ce7a3151ea3730cccec47afa3a8f28 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:12:06 -0500 Subject: [PATCH 0774/1812] Update for method renames in libstd --- src/panic-implementation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 4dbc5e613..4f4fb1a98 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -38,8 +38,8 @@ Actually resolving this goes through several layers of indirection: [cfg(not(test))] [panic_handler] [unwind(allowed)] -pub fn rust_begin_panic(info: &PanicInfo<'_>) -> ! { - continue_panic_fmt(&info) +pub fn begin_panic_handler(info: &PanicInfo<'_>) -> ! { + ... } ``` @@ -49,7 +49,7 @@ The `extract` function converts the `panic_handler` attribute to a `panic_impl` Now, we have a matching `panic_handler` lang item in the `libstd`. This function goes through the same process as the `extern { fn panic_impl }` definition in `libcore`, ending up with a symbol name of `rust_begin_unwind`. At link time, the symbol refernce in `libcore` -will be resolved to the definition of `libstd` (the function called `rust_begin_panic` in the +will be resolved to the definition of `libstd` (the function called `begin_panic_handler` in the Rust source). Thus, control flow will pass from libcore to std at runtime. This allows panics from `libcore` From 01c0b04ee340c3ef6a19b27eea5b9000d0f8d6df Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Mon, 2 Dec 2019 13:19:19 -0500 Subject: [PATCH 0775/1812] Fix line lengths --- src/panic-implementation.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 4f4fb1a98..b62e26436 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -4,7 +4,8 @@ There are actually two panic macros - one defined in `libcore`, and one defined in `libstd`. This is due to the fact that code in `libcore` can panic. `libcore` is built before `libstd`, -but we want panics to use the same machinery at runtime, whether they originate in `libcore` or `libstd`. +but we want panics to use the same machinery at runtime, whether they originate in `libcore` +or `libstd`. ##### libcore definition of panic! @@ -65,12 +66,14 @@ we call ```__rust_start_panic```, which is provided by the panic runtime. The call to ```__rust_start_panic``` is very weird - it is passed a ```*mut &mut dyn BoxMeUp```, converted to an `usize`. Let's break this type down: -1. `BoxMeUp` is an internal trait. It is implemented for `PanicPayload` (a wrapper around the user-supplied -payload type), and has a method ```fn box_me_up(&mut self) -> *mut (dyn Any + Send)```. +1. `BoxMeUp` is an internal trait. It is implemented for `PanicPayload` +(a wrapper around the user-supplied payload type), and has a method +```fn box_me_up(&mut self) -> *mut (dyn Any + Send)```. This method takes the user-provided payload (`T: Any + Send`), boxes it, and convertes the box to a raw pointer. -2. When we call ```__rust_start_panic```, we have an `&mut dyn BoxMeUp`. However, this is a fat pointer -(twice the size of a `usize`). To pass this to the panic runtime across an FFI boundary, we take a mutable +2. When we call ```__rust_start_panic```, we have an `&mut dyn BoxMeUp`. +However, this is a fat pointer (twice the size of a `usize`). +To pass this to the panic runtime across an FFI boundary, we take a mutable reference *to this mutable reference* (`&mut &mut dyn BoxMeUp`), and convert it to a raw pointer (`*mut &mut dyn BoxMeUp`). The outer raw pointer is a thin pointer, since it points to a `Sized` type (a mutable reference). Therefore, we can convert this thin pointer into a `usize`, which From 97dfbc964ea8d44c9b453df08136b9435502dae7 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Thu, 2 Jan 2020 22:32:19 -0500 Subject: [PATCH 0776/1812] Apply fixes Co-Authored-By: Yuki Okushi --- src/panic-implementation.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/src/panic-implementation.md b/src/panic-implementation.md index b62e26436..4cb4ebb6f 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -49,29 +49,30 @@ The `extract` function converts the `panic_handler` attribute to a `panic_impl` Now, we have a matching `panic_handler` lang item in the `libstd`. This function goes through the same process as the `extern { fn panic_impl }` definition in `libcore`, ending -up with a symbol name of `rust_begin_unwind`. At link time, the symbol refernce in `libcore` +up with a symbol name of `rust_begin_unwind`. At link time, the symbol reference in `libcore` will be resolved to the definition of `libstd` (the function called `begin_panic_handler` in the Rust source). Thus, control flow will pass from libcore to std at runtime. This allows panics from `libcore` -to go through the same infratructure that other panics use (panic hooks, unwinding, etc) +to go through the same infrastructure that other panics use (panic hooks, unwinding, etc) ##### libstd implementation of panic! -This is where the actual panic-related logic begins. In `src/libstd/pancking.rs`, +This is where the actual panic-related logic begins. In `src/libstd/panicking.rs`, control passes to `rust_panic_with_hook`. This method is responsible for invoking the global panic hook, and checking for double panics. Finally, -we call ```__rust_start_panic```, which is provided by the panic runtime. +we call `__rust_start_panic`, which is provided by the panic runtime. -The call to ```__rust_start_panic``` is very weird - it is passed a ```*mut &mut dyn BoxMeUp```, +The call to `__rust_start_panic` is very weird - it is passed a `*mut &mut dyn BoxMeUp`, converted to an `usize`. Let's break this type down: 1. `BoxMeUp` is an internal trait. It is implemented for `PanicPayload` (a wrapper around the user-supplied payload type), and has a method -```fn box_me_up(&mut self) -> *mut (dyn Any + Send)```. -This method takes the user-provided payload (`T: Any + Send`), boxes it, and convertes the box to a raw pointer. +`fn box_me_up(&mut self) -> *mut (dyn Any + Send)`. +This method takes the user-provided payload (`T: Any + Send`), +boxes it, and converts the box to a raw pointer. -2. When we call ```__rust_start_panic```, we have an `&mut dyn BoxMeUp`. +2. When we call `__rust_start_panic`, we have an `&mut dyn BoxMeUp`. However, this is a fat pointer (twice the size of a `usize`). To pass this to the panic runtime across an FFI boundary, we take a mutable reference *to this mutable reference* (`&mut &mut dyn BoxMeUp`), and convert it to a raw pointer @@ -79,19 +80,19 @@ reference *to this mutable reference* (`&mut &mut dyn BoxMeUp`), and convert it type (a mutable reference). Therefore, we can convert this thin pointer into a `usize`, which is suitable for passing across an FFI boundary. -Finally, we call ```__rust_start_panic``` with this `usize`. We have now entered the panic runtime. +Finally, we call `__rust_start_panic` with this `usize`. We have now entered the panic runtime. #### Step 2: The panic runtime Rust provides two panic runtimes: `libpanic_abort` and `libpanic_unwind`. The user chooses between them at build time via their `Cargo.toml` -`libpanic_abort` is extremely simple: its implementation of ```__rust_start_panic``` just aborts, +`libpanic_abort` is extremely simple: its implementation of `__rust_start_panic` just aborts, as you would expect. `libpanic_unwind` is the more interesting case. -In its implementation of ```__rust_start_panic```, we take the `usize`, convert +In its implementation of `__rust_start_panic`, we take the `usize`, convert it back to a `*mut &mut dyn BoxMeUp`, dereference it, and call `box_me_up` on the `&mut dyn BoxMeUp`. At this point, we have a raw pointer to the payload itself (a `*mut (dyn Send + Any)`): that is, a raw pointer to the actual value From 629c135e0b07acc58b753796864b084a202c2762 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Thu, 2 Jan 2020 22:58:39 -0500 Subject: [PATCH 0777/1812] Add missing hash marks Fixes #550 I can no longer reproduce the issue --- src/panic-implementation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 4cb4ebb6f..497c81fd0 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -36,9 +36,9 @@ Actually resolving this goes through several layers of indirection: ```rust /// Entry point of panic from the libcore crate. -[cfg(not(test))] -[panic_handler] -[unwind(allowed)] +#[cfg(not(test))] +#[panic_handler] +#[unwind(allowed)] pub fn begin_panic_handler(info: &PanicInfo<'_>) -> ! { ... } From 2de64f7cafcceeecf80760ca1993e54c7afb3897 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 3 Jan 2020 11:12:37 -0300 Subject: [PATCH 0778/1812] Summarize the lecture of ty into a chapter (#530) * Summarize the lecture of ty into a chapter * Add note that def-id is explained later * Add mark-i-am fixes * Address some of Niko's comments * address last review comments * fix link Co-authored-by: Who? Me?! --- src/ty.md | 683 +++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 596 insertions(+), 87 deletions(-) diff --git a/src/ty.md b/src/ty.md index 6295a0db1..c9d2feba9 100644 --- a/src/ty.md +++ b/src/ty.md @@ -1,14 +1,226 @@ +--- +tags: rustc, ty +--- + # The `ty` module: representing types -The `ty` module defines how the Rust compiler represents types -internally. It also defines the *typing context* (`tcx` or `TyCtxt`), -which is the central data structure in the compiler. +The `ty` module defines how the Rust compiler represents types internally. It also defines the +*typing context* (`tcx` or `TyCtxt`), which is the central data structure in the compiler. + +## `ty::Ty` + +When we talk about how rustc represents types, we usually refer to a type called `Ty` . There are +quite a few modules and types for `Ty` in the compiler ([Ty documentation][ty]). + +[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/index.html + +The specific `Ty` we are referring to is [`rustc::ty::Ty`][ty_ty] (and not +[`rustc::hir::Ty`][hir_ty]). The distinction is important, so we will discuss it first before going +into the details of `ty::Ty`. + +[ty_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html +[hir_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Ty.html + +## `hir::Ty` vs `ty::Ty` + +The HIR in rustc can be thought of as the high-level intermediate representation. It is more or less +the AST (see [this chapter](hir.md)) as it represents the +syntax that the user wrote, and is obtained after parsing and some *desugaring*. It has a +representation of types, but in reality it reflects more of what the user wrote, that is, what they +wrote so as to represent that type. + +In contrast, `ty::Ty` represents the semantics of a type, that is, the *meaning* of what the user +wrote. For example, `hir::Ty` would record the fact that a user used the name `u32` twice in their +program, but the `ty::Ty` would record the fact that both usages refer to the same type. + +**Example: `fn foo(x: u32) → u32 { }`** In this function we see that `u32` appears twice. We know +that that is the same type, i.e. the function takes an argument and returns an argument of the same +type, but from the point of view of the HIR there would be two distinct type instances because these +are occurring in two different places in the program. That is, they have two +different [`Span`s][span] (locations). + +[span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html + +**Example: `fn foo(x: &u32) -> &u32)`** In addition, HIR might have information left out. This type +`&u32` is incomplete, since in the full rust type there is actually a lifetime, but we didn’t need +to write those lifetimes. There are also some elision rules that insert information. The result may +look like `fn foo<'a>(x: &'a u32) -> &'a u32)`. + +In the HIR level, these things are not spelled out and you can say the picture is rather incomplete. +However, at the `ty::Ty` level, these details are added and it is complete. Moreover, we will have +exactly one `ty::Ty` for a given type, like `u32`, and that `ty::Ty` is used for all `u32`s in the +whole program, not a specific usage, unlike `hir::Ty`. + +Here is a summary: + +| [`hir::Ty`][hir_ty] | [`ty::Ty`][ty_ty] | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Describe the *syntax* of a type: what the user wrote (with some desugaring). | Describe the *semantics* of a type: the meaning of what the user wrote. | +| Each `hir::Ty` has its own spans corresponding to the appropriate place in the program. | Doesn’t correspond to a single place in the user’s program. | +| `hir::Ty` has generics and lifetimes; however, some of those lifetimes are special markers like [`LifetimeName::Implicit`][implicit]. | `ty::Ty` has the full type, including generics and lifetimes, even if the user left them out | +| `fn foo(x: u32) → u32 { }` - Two `hir::Ty` representing each usage of `u32`. Each has its own `Span`s, etc.- `hir::Ty` doesn’t tell us that both are the same type | `fn foo(x: u32) → u32 { }` - One `ty::Ty` for all instances of `u32` throughout the program.- `ty::Ty` tells us that both usages of `u32` mean the same type. | +| `fn foo(x: &u32) -> &u32)`- Two `hir::Ty` again.- Lifetimes for the references show up in the `hir::Ty`s using a special marker, [`LifetimeName::Implicit`][implicit]. | `fn foo(x: &u32) -> &u32)`- A single `ty::Ty`.- The `ty::Ty` has the hidden lifetime param | + +[implicit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/enum.LifetimeName.html#variant.Implicit + +**Order** HIR is built directly from the AST, so it happens before any `ty::Ty` is produced. After +HIR is built, some basic type inference and type checking is done. During the type inference, we +figure out what the `ty::Ty` of everything is and we also check if the type of something is +ambiguous. The `ty::Ty` then, is used for type checking while making sure everything has the +expected type. The [`astconv` module][astconv], is where the code responsible for converting a +`hir::Ty` into a `ty::Ty` is located. This occurs during the type-checking phase, but also in other +parts of the compiler that want to ask questions like "what argument types does this function +expect"?. + +[astconv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/astconv/index.html + +**How semantics drive the two instances of `Ty`** You can think of HIR as the perspective +of the type information that assumes the least. We assume two things are distinct until they are +proven to be the same thing. In other words, we know less about them, so we should assume less about +them. + +They are syntactically two strings: `"u32"` at line N column 20 and `"u32"` at line N column 35. We +don’t know that they are the same yet. So, in the HIR we treat them as if they are different. Later, +we determine that they semantically are the same type and that’s the `ty::Ty` we use. + +Consider another example: `fn foo(x: T) -> u32` and suppose that someone invokes `foo::(0)`. +This means that `T` and `u32` (in this invocation) actually turns out to be the same type, so we +would eventually end up with the same `ty::Ty` in the end, but we have distinct `hir::Ty`. (This is +a bit over-simplified, though, since during type checking, we would check the function generically +and would still have a `T` distinct from `u32`. Later, when doing code generation, we would always +be handling "monomorphized" (fully substituted) versions of each function, and hence we would know +what `T` represents (and specifically that it is `u32`). + +Here is one more example: + +```rust +mod a { + type X = u32; + pub fn foo(x: X) -> i32 { 22 } +} +mod b { + type X = i32; + pub fn foo(x: X) -> i32 { x } +} +``` + +Here the type `X` will vary depending on context, clearly. If you look at the `hir::Ty`, you will +get back that `X` is an alias in both cases (though it will be mapped via name resolution to +distinct aliases). But if you look at the `ty::Ty` signature, it will be either `fn(u32) -> u32` or +`fn(i32) -> i32` (with type aliases fully expanded). + +## `ty::Ty` implementation + +[`rustc::ty::Ty`][ty_ty] is actually a type alias to [`&TyS`][tys] (more about that later). `TyS` +(Type Structure) is where the main functionality is located. You can ignore `TyS` struct in general; +you will basically never access it explicitly. We always pass it by reference using the `Ty` alias. +The only exception is to define inherent methods on types. In particular, `TyS` has a [`kind`][kind] +field of type [`TyKind`][tykind], which represents the key type information. `TyKind` is a big enum +which represents different kinds of types (e.g. primitives, references, abstract data types, +generics, lifetimes, etc). `TyS` also has 2 more fields, `flags` and `outer_exclusive_binder`. They +are convenient hacks for efficiency and summarize information about the type that we may want to +know, but they don’t come into the picture as much here. + +[tys]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html +[kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html#structfield.kind +[tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html + +Note: `TyKind` is **NOT** the functional programming concept of *Kind*. + +Whenever working with a `Ty` in the compiler, it is common to match on the kind of type: + +```rust,ignore +fn foo(x: Ty<'tcx>) { + match x.kind { + ... + } +} +``` + +The `kind` field is of type `TyKind<'tcx>`, which is an enum defining all of the different kinds of +types in the compiler. + +> N.B. inspecting the `kind` field on types during type inference can be risky, as there may be +> inference variables and other things to consider, or sometimes types are not yet known and will +> become known later. + +There are a lot of related types, and we’ll cover them in time (e.g regions/lifetimes, +“substitutions”, etc). + +## `ty::TyKind` Variants + +There are a bunch of variants on the `TyKind` enum, which you can see by looking at the rustdocs. +Here is a sampling: + +[**Algebraic Data Types (ADTs)**]() An [*algebraic Data Type*][wikiadt] is a `struct`, `enum` or +`union`. Under the hood, `struct`, `enum` and `union` are actually implemented the same way: they +are both [`ty::TyKind::Adt`][kindadt]. It’s basically a user defined type. We will talk more about +these later. + +[**Foreign**][kindforeign] Corresponds to `extern type T`. + +[**Str**][kindstr] Is the type str. When the user writes `&str`, `Str` is the how we represent the +`str` part of that type. + +[**Slice**][kindslice] Corresponds to `[T]`. + +[**Array**][kindarray] Corresponds to `[T; n]`. + +[**RawPtr**][kindrawptr] Corresponds to `*mut T` or `*const T` + +[**Ref**][kindref] `Ref` stands for safe references, `&'a mut T` or `&'a T`. `Ref` has some +associated parts, like `Ty<'tcx>` which is the type that the reference references, `Region<'tcx>` is +the lifetime or region of the reference and `Mutability` if the reference is mutable or not. + +[**Param**][kindparam] Represents a type parameter (e.g. the `T` in `Vec`). + +[**Error**][kinderr] Represents a type error somewhere so that we can print better diagnostics. We +will discuss this more later. + +[**And Many More**...][kindvars] + +[wikiadt]: https://en.wikipedia.org/wiki/Algebraic_data_type +[kindadt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Adt +[kindforeign]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Foreign +[kindstr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Str +[kindslice]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Slice +[kindarray]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Array +[kindrawptr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.RawPtr +[kindref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Ref +[kindparam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Param +[kinderr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Error +[kindvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variants + +## Interning + +We create a LOT of types during compilation. For performance reasons, we allocate them from a global +memory pool, they are each allocated once from a long-lived *arena*. This is called _arena +allocation_. This system reduces allocations/deallocations of memory. It also allows for easy +comparison of types for equality: we implemented [`PartialEq for TyS`][peqimpl], so we can just +compare pointers. The [`CtxtInterners`] type contains a bunch of maps of interned types and the +arena itself. + +[peqimpl]: https://github.com/rust-lang/rust/blob/3ee936378662bd2e74be951d6a7011a95a6bd84d/src/librustc/ty/mod.rs#L528-L534 +[`CtxtInterners`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.CtxtInterners.html#structfield.arena + +Each time we want to construct a type, the compiler doesn’t naively allocate from the buffer. +Instead, we check if that type was already constructed. If it was, we just get the same pointer we +had before, otherwise we make a fresh pointer. With this schema if we want to know if two types are +the same, all we need to do is compare the pointers which is efficient. `TyS` which represents types +is carefully setup so you never construct them on the stack. You always allocate them from this +arena and you always intern them so they are unique. + +At the beginning of the compilation we make a buffer and each time we need to allocate a type we use +some of this memory buffer. If we run out of space we get another one. The lifetime of that buffer +is `'tcx`. Our types are tied to that lifetime, so when compilation finishes all the memory related +to that buffer is freed and our `'tcx` references would be invalid. + ## The tcx and how it uses lifetimes -The `tcx` ("typing context") is the central data structure in the -compiler. It is the context that you use to perform all manner of -queries. The struct `TyCtxt` defines a reference to this shared context: +The `tcx` ("typing context") is the central data structure in the compiler. It is the context that +you use to perform all manner of queries. The struct `TyCtxt` defines a reference to this shared +context: ```rust,ignore tcx: TyCtxt<'tcx> @@ -17,110 +229,407 @@ tcx: TyCtxt<'tcx> // arena lifetime ``` -As you can see, the `TyCtxt` type takes a lifetime parameter. -During Rust compilation, we allocate most of our memory in -**arenas**, which are basically pools of memory that get freed all at -once. When you see a reference with a lifetime like `'tcx`, -you know that it refers to arena-allocated data (or data that lives as -long as the arenas, anyhow). +As you can see, the `TyCtxt` type takes a lifetime parameter. When you see a reference with a +lifetime like `'tcx`, you know that it refers to arena-allocated data (or data that lives as long as +the arenas, anyhow). -### Allocating and working with types +## Allocating and working with types -Rust types are represented using the `Ty<'tcx>` defined in the `ty` -module (not to be confused with the `Ty` struct from [the HIR]). This -is in fact a simple type alias for a reference with `'tcx` lifetime: +To allocate a new type, you can use the various `mk_` methods defined on the `tcx`. These have names +that correspond mostly to the various kinds of types. For example: ```rust,ignore -pub type Ty<'tcx> = &'tcx TyS<'tcx>; +let array_ty = tcx.mk_array(elem_ty, len * 2); ``` -[the HIR]: ./hir.html +These methods all return a `Ty<'tcx>` – note that the lifetime you get back is the lifetime of the +arena that this `tcx` has access to. Types are always canonicalized and interned (so we never +allocate exactly the same type twice). + +> NB. Because types are interned, it is possible to compare them for equality efficiently using `==` +> – however, this is almost never what you want to do unless you happen to be hashing and looking +> for duplicates. This is because often in Rust there are multiple ways to represent the same type, +> particularly once inference is involved. If you are going to be testing for type equality, you +> probably need to start looking into the inference code to do it right. + +You can also find various common types in the `tcx` itself by accessing `tcx.types.bool`, +`tcx.types.char`, etc (see [`CommonTypes`] for more). + +[`CommonTypes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.CommonTypes.html -You can basically ignore the `TyS` struct – you will basically never -access it explicitly. We always pass it by reference using the -`Ty<'tcx>` alias – the only exception I think is to define inherent -methods on types. Instances of `TyS` are only ever allocated in one of -the rustc arenas (never e.g. on the stack). +## Beyond types: other kinds of arena-allocated data structures -One common operation on types is to **match** and see what kinds of -types they are. This is done by doing `match ty.sty`, sort of like this: +In addition to types, there are a number of other arena-allocated data structures that you can +allocate, and which are found in this module. Here are a few examples: + +- [`Substs`][subst], allocated with `mk_substs` – this will intern a slice of types, often used to + specify the values to be substituted for generics (e.g. `HashMap` would be represented + as a slice `&'tcx [tcx.types.i32, tcx.types.u32]`). +- [`TraitRef`], typically passed by value – a **trait reference** consists of a reference to a trait + along with its various type parameters (including `Self`), like `i32: Display` (here, the def-id + would reference the `Display` trait, and the substs would contain `i32`). Note that `def-id` is + defined and discussed in depth in the `AdtDef and DefId` section. +- [`Predicate`] defines something the trait system has to prove (see `traits` module). + +[subst]: ./generic_arguments.html#subst +[`TraitRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html +[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.Predicate.html + +## Import conventions + +Although there is no hard and fast rule, the `ty` module tends to be used like so: ```rust,ignore -fn test_type<'tcx>(ty: Ty<'tcx>) { - match ty.sty { - ty::TyArray(elem_ty, len) => { ... } - ... - } +use ty::{self, Ty, TyCtxt}; +``` + +In particular, since they are so common, the `Ty` and `TyCtxt` types are imported directly. Other +types are often referenced with an explicit `ty::` prefix (e.g. `ty::TraitRef<'tcx>`). But some +modules choose to import a larger or smaller set of names explicitly. + +## ADTs Representation + +Let's consider the example of a type like `MyStruct`, where `MyStruct` is defined like so: + +```rust,ignore +struct MyStruct { x: u32, y: T } +``` + +The type `MyStruct` would be an instance of `TyKind::Adt`: + +```rust,ignore +Adt(&'tcx AdtDef, SubstsRef<'tcx>) +// ------------ --------------- +// (1) (2) +// +// (1) represents the `MyStruct` part +// (2) represents the ``, or "substitutions" / generic arguments +``` + +There are two parts: + +- The [`AdtDef`][adtdef] references the struct/enum/union but without the values for its type + parameters. In our example, this is the `MyStruct` part *without* the argument `u32`. + - Note that in the HIR, structs, enums and unions are represented differently, but in `ty::Ty`, + they are all represented using `TyKind::Adt`. +- The [`SubstsRef`][substsref] is an interned list of values that are to be substituted for the + generic parameters. In our example of `MyStruct`, we would end up with a list like `[u32]`. + We’ll dig more into generics and substitutions in a little bit. + +[adtdef]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.AdtDef.html +[substsref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/type.SubstsRef.html + +**`AdtDef` and `DefId`** + +For every type defined in the source code, there is a unique `DefId` (see [this +chapter](hir.md#identifiers-in-the-hir)). This includes ADTs and generics. In the `MyStruct` +definition we gave above, there are two `DefId`s: one for `MyStruct` and one for `T`. Notice that +the code above does not generate a new `DefId` for `u32` because it is not defined in that code (it +is only referenced). + +`AdtDef` is more or less a wrapper around `DefId` with lots of useful helper methods. There is +essentially a one-to-one relationship between `AdtDef` and `DefId`. You can get the `AdtDef` for a +`DefId` with the [`tcx.adt_def(def_id)` query][adtdefq]. The `AdtDef`s are all interned (as you can +see `'tcx` lifetime on it). + +[adtdefq]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html#method.adt_def + + +### Generics and substitutions + +Given a generic type `MyType`, we may want to swap out the generics `A, B, …` for some +other types (possibly other generics or concrete types). We do this a lot while doing type +inference, type checking, and trait solving. Conceptually, during these routines, we may find out +that one type is equal to another type and want to swap one out for the other and then swap that out +for another type and so on until we eventually get some concrete types (or an error). + +In rustc this is done using the `SubstsRef` that we mentioned above (“substs” = “substitutions”). +Conceptually, you can think of `SubstsRef` of a list of types that are to be substituted for the +generic type parameters of the ADT. + +`SubstsRef` is a type alias of `List>` (see [`List` rustdocs][list]). +[`GenericArg`] is essentially a space-efficient wrapper around [`GenericArgKind`], which is an enum +indicating what kind of generic the type parameter is (type, lifetime, or const). Thus, `SubstsRef` +is conceptually like a `&'tcx [GenericArgKind<'tcx>]` slice (but it is actually a `List`). + +[list]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.List.html +[`GenericArg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.GenericArg.html +[`GenericArgKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/enum.GenericArgKind.html + +So why do we use this `List` type instead of making it really a slice? It has the length "inline", +so `&List` is only 32 bits. As a consequence, it cannot be "subsliced" (that only works if the +length is out of line). + +This also implies that you can check two `List`s for equality via `==` (which would be not be +possible for ordinary slices). This is precisely because they never represent a "sub-list", only the +complete `List`, which has been hashed and interned. + +So pulling it all together, let’s go back to our example above: + +```rust,ignore +struct MyStruct +``` + +- There would be an `AdtDef` (and corresponding `DefId`) for `MyStruct`. +- There would be a `TyKind::Param` (and corresponding `DefId`) for `T` (more later). +- There would be a `SubstsRef` containing the list `[GenericArgKind::Type(Ty(T))]` + - The `Ty(T)` here is my shorthand for entire other `ty::Ty` that has `TyKind::Param`, which we + mentioned in the previous point. +- This is one `TyKind::Adt` containing the `AdtDef` of `MyStruct` with the `SubstsRef` above. + +Finally, we will quickly mention the +[`Generics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.Generics.html) type. It +is used to give information about the type parameters of a type. + +### Unsubstituted Generics + +So above, recall that in our example the `MyStruct` struct had a generic type `T`. When we are (for +example) type checking functions that use `MyStruct`, we will need to be able to refer to this type +`T` without actually knowing what it is. In general, this is true inside all generic definitions: we +need to be able to work with unknown types. This is done via `TyKind::Param` (which we mentioned in +the example above). + +Each `TyKind::Param` contains two things: the name and the index. In general, the index fully +defines the parameter and is used by most of the code. The name is included for debug print-outs. +There are two reasons for this. First, the index is convenient, it allows you to include into the +list of generic arguments when substituting. Second, the index is more robust. For example, you +could in principle have two distinct type parameters that use the same name, e.g. `impl Foo { +fn bar() { .. } }`, although the rules against shadowing make this difficult (but those language +rules could change in the future). + +The index of the type parameter is an integer indicating its order in the list of the type +parameters. Moreover, we consider the list to include all of the type parameters from outer scopes. +Consider the following example: + +```rust,ignore +struct Foo { + // A would have index 0 + // B would have index 1 + + .. // some fields +} +impl Foo { + fn method() { + // inside here, X, Y and Z are all in scope + // X has index 0 + // Y has index 1 + // Z has index 2 + } +} +``` + +When we are working inside the generic definition, we will use `TyKind::Param` just like any other +`TyKind`; it is just a type after all. However, if we want to use the generic type somewhere, then +we will need to do substitutions. + +For example suppose that the `Foo` type from the previous example has a field that is a +`Vec`. Observe that `Vec` is also a generic type. We want to tell the compiler that the type +parameter of `Vec` should be replaced with the `A` type parameter of `Foo`. We do that with +substitutions: + +```rust,ignore +struct Foo { // Adt(Foo, &[Param(0), Param(1)]) + x: Vec, // Adt(Vec, &[Param(0)]) + .. +} + +fn bar(foo: Foo) { // Adt(Foo, &[u32, f32]) + let y = foo.x; // Vec => Vec } ``` -The `sty` field (the origin of this name is unclear to me; perhaps -structural type?) is of type `TyKind<'tcx>`, which is an enum -defining all of the different kinds of types in the compiler. +This example has a few different substitutions: + +- In the definition of `Foo`, in the type of the field `x`, we replace `Vec`'s type parameter with + `Param(0)`, the first parameter of `Foo`, so that the type of `x` is `Vec`. +- In the function `bar`, we specify that we want a `Foo`. This means that we will + substitute `Param(0)` and `Param(1)` with `u32` and `f32`. +- In the body of `bar`, we access `foo.x`, which has type `Vec`, but `Param(0)` has been + substituted for `u32`, so `foo.x` has type `Vec`. + +Let’s look a bit more closely at that last substitution to see why we use indexes. If we want to +find the type of `foo.x`, we can get generic type of `x`, which is `Vec`. Now we can take +the index `0` and use it to find the right type substitution: looking at `Foo`'s `SubstsRef`, we +have the list `[u32, f32]` , since we want to replace index `0`, we take the 0-th index of this +list, which is `u32`. Voila! + +You may have a couple of followup questions… + + **`type_of`** How do we get the “generic type of `x`"? You can get the type of pretty much anything + with the `tcx.type_of(def_id)` query. In this case, we would pass the `DefId` of the field `x`. + The `type_of` query always returns the definition with the generics that are in scope of the + definition. For example, `tcx.type_of(def_id_of_my_struct)` would return the “self-view” of + `MyStruct`: `Adt(Foo, &[Param(0), Param(1)])`. + +**`subst`** How do we actually do the substitutions? There is a function for that too! You use +[`subst`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/trait.Subst.html) to +replace a `SubstRef` with another list of types. + +[Here is an example of actually using `subst` in the compiler][substex]. The exact details are not +too important, but in this piece of code, we happen to be converting from the `hir::Ty` to a real +`ty::Ty`. You can see that we first get some substitutions (`substs`). Then we call `type_of` to +get a type and call `ty.subst(substs)` to get a new version of `ty` with the substitutions made. -> N.B. inspecting the `sty` field on types during type inference can be -> risky, as there may be inference variables and other things to -> consider, or sometimes types are not yet known and will become -> known later. +[substex]: https://github.com/rust-lang/rust/blob/597f432489f12a3f33419daa039ccef11a12c4fd/src/librustc_typeck/astconv.rs#L942-L953 -To allocate a new type, you can use the various `mk_` methods defined -on the `tcx`. These have names that correspond mostly to the various kinds -of type variants. For example: +**Note on indices:** It is possible for the indices in `Param` to not match with what we expect. For +example, the index could be out of bounds or it could be the index of a lifetime when we were +expecting a type. These sorts of errors would be caught earlier in the compiler when translating +from a `hir::Ty` to a `ty::Ty`. If they occur later, that is a compiler bug. + +### `TypeFoldable` and `TypeFolder` + +How is this `subst` query actually implemented? As you can imagine, we might want to do +substitutions on a lot of different things. For example, we might want to do a substitution directly +on a type like we did with `Vec` above. But we might also have a more complex type with other types +nested inside that also need substitutions. + +The answer is a couple of traits: +[`TypeFoldable`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFoldable.html) +and +[`TypeFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html). + +- `TypeFoldable` is implemented by types that embed type information. It allows you to recursively + process the contents of the `TypeFoldable` and do stuff to them. +- `TypeFolder` defines what you want to do with the types you encounter while processing the + `TypeFoldable`. + +For example, the `TypeFolder` trait has a method +[`fold_ty`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html#method.fold_ty) +that takes a type as input a type and returns a new type as a result. `TypeFoldable` invokes the +`TypeFolder` `fold_foo` methods on itself, giving the `TypeFolder` access to its contents (the +types, regions, etc that are contained within). + +You can think of it with this analogy to the iterator combinators we have come to love in rust: ```rust,ignore -let array_ty = tcx.mk_array(elem_ty, len * 2); +vec.iter().map(|e1| foo(e2)).collect() +// ^^^^^^^^^^^^ analogous to `TypeFolder` +// ^^^ analogous to `Typefoldable` ``` -These methods all return a `Ty<'tcx>` – note that the lifetime you -get back is the lifetime of the innermost arena that this `tcx` has -access to. In fact, types are always canonicalized and interned (so we -never allocate exactly the same type twice) and are always allocated -in the outermost arena where they can be (so, if they do not contain -any inference variables or other "temporary" types, they will be -allocated in the global arena). However, the lifetime `'tcx` is always -a safe approximation, so that is what you get back. - -> NB. Because types are interned, it is possible to compare them for -> equality efficiently using `==` – however, this is almost never what -> you want to do unless you happen to be hashing and looking for -> duplicates. This is because often in Rust there are multiple ways to -> represent the same type, particularly once inference is involved. If -> you are going to be testing for type equality, you probably need to -> start looking into the inference code to do it right. - -You can also find various common types in the `tcx` itself by accessing -`tcx.types.bool`, `tcx.types.char`, etc (see `CommonTypes` for more). - -### Beyond types: other kinds of arena-allocated data structures - -In addition to types, there are a number of other arena-allocated data -structures that you can allocate, and which are found in this -module. Here are a few examples: - -- [`Substs`][subst], allocated with `mk_substs` – this will intern a slice of - types, often used to specify the values to be substituted for generics - (e.g. `HashMap` would be represented as a slice - `&'tcx [tcx.types.i32, tcx.types.u32]`). -- `TraitRef`, typically passed by value – a **trait reference** - consists of a reference to a trait along with its various type - parameters (including `Self`), like `i32: Display` (here, the def-id - would reference the `Display` trait, and the substs would contain - `i32`). -- `Predicate` defines something the trait system has to prove (see `traits` - module). +So to reiterate: -[subst]: ./generic_arguments.html#subst +- `TypeFolder` is a trait that defines a “map” operation. +- `TypeFoldable` is a trait that is implemented by things that embed types. -### Import conventions +In the case of `subst`, we can see that it is implemented as a `TypeFolder`: +[`SubstFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.SubstFolder.html). +Looking at its implementation, we see where the actual substitutions are happening. -Although there is no hard and fast rule, the `ty` module tends to be used like -so: +However, you might also notice that the implementation calls this `super_fold_with` method. What is +that? It is a method of `TypeFoldable`. Consider the following `TypeFoldable` type `MyFoldable`: ```rust,ignore -use ty::{self, Ty, TyCtxt}; +struct MyFoldable<'tcx> { + def_id: DefId, + ty: Ty<'tcx>, +} +``` + +The `TypeFolder` can call `super_fold_with` on `MyFoldable` if it just wants to replace some of the +fields of `MyFoldable` with new values. If it instead wants to replace the whole `MyFoldable` with a +different one, it would call `fold_with` instead (a different method on `TypeFoldable`). + +In almost all cases, we don’t want to replace the whole struct; we only want to replace `ty::Ty`s in +the struct, so usually we call `super_fold_with`. A typical implementation that `MyFoldable` could +have might do something like this: + +```rust,ignore +my_foldable: MyFoldable<'tcx> +my_foldable.subst(..., subst) + +impl TypeFoldable for MyFoldable { + fn super_fold_with(&self, folder: &mut impl TypeFolder<'tcx>) -> MyFoldable { + MyFoldable { + def_id: self.def_id.fold_with(folder), + ty: self.ty.fold_with(folder), + } + } + + fn super_visit_with(..) { } +} +``` + +Notice that here, we implement `super_fold_with` to go over the fields of `MyFoldable` and call +`fold_with` on *them*. That is, a folder may replace `def_id` and `ty`, but not the whole +`MyFoldable` struct. + +Here is another example to put things together: suppose we have a type like `Vec>`. The +`ty::Ty` would look like: `Adt(Vec, &[Adt(Vec, &[Param(X)])])`. If we want to do `subst(X => u32)`, +then we would first look at the overall type. We would see that there are no substitutions to be +made at the outer level, so we would descend one level and look at `Adt(Vec, &[Param(X)])`. There +are still no substitutions to be made here, so we would descend again. Now we are looking at +`Param(X)`, which can be substituted, so we replace it with `u32`. We can’t descend any more, so we +are done, and the overall result is `Adt(Vec, &[Adt(Vec, &[u32])])`. + +One last thing to mention: often when folding over a `TypeFoldable`, we don’t want to change most +things. We only want to do something when we reach a type. That means there may be a lot of +`TypeFoldable` types whose implementations basically just forward to their fields’ `TypeFoldable` +implementations. Such implementations of `TypeFoldable` tend to be pretty tedious to write by hand. +For this reason, there is a `derive` macro that allows you to `#![derive(TypeFoldable)]`. It is +defined +[here](https://github.com/rust-lang/rust/blob/master/src/librustc_macros/src/type_foldable.rs). + +**`subst`** In the case of substitutions the [actual +folder](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L467-L482) +is going to be doing the indexing we’ve already mentioned. There we define a `Folder` and call +`fold_with` on the `TypeFoldable` to process yourself. Then +[fold_ty](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L545-L573) +the method that process each type it looks for a `ty::Param` and for those it replaces it for +something from the list of substitutions, otherwise recursively process the type. To replace it, +calls +[ty_for_param](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L589-L624) +and all that does is index into the list of substitutions with the index of the `Param`. + +## Type errors + +There is a `TyKind::Error` that is produced when the user makes a type error. The idea is that +we would propagate this type and suppress other errors that come up due to it so as not to overwhelm +the user with cascading compiler error messages. + +There is an **important invariant** for `TyKind::Error`. You should **never** return the 'error +type' unless you **know** that an error has already been reported to the user. This is usually +because (a) you just reported it right there or (b) you are propagating an existing Error type (in +which case the error should've been reported when that error type was produced). + +It's important to maintain this invariant because the whole point of the `Error` type is to suppress +other errors -- i.e., we don't report them. If we were to produce an `Error` type without actually +emitting an error to the user, then this could cause later errors to be suppressed, and the +compilation might inadvertently succeed! + +Sometimes there is a third case. You believe that an error has been reported, but you believe it +would've been reported earlier in the compilation, not locally. In that case, you can invoke +[`delay_span_bug`] This will make a note that you expect compilation to yield an error -- if however +compilation should succeed, then it will trigger a compiler bug report. + +[`delay_span_bug`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html#method.delay_span_bug + +## Question: Why not substitute “inside” the `AdtDef`? + +Recall that we represent a generic struct with `(AdtDef, substs)`. So why bother with this scheme? + +Well, the alternate way we could have choosen to represent types would be to always create a new, +fully-substituted form of the `AdtDef` where all the types are already substituted. This seems like +less of a hassle. However, the `(AdtDef, substs)` scheme has some advantages over this. + +First, `(AdtDef, substs)` scheme has an efficiency win: + +```rust,ignore +struct MyStruct { + ... 100s of fields ... +} + +// Want to do: MyStruct ==> MyStruct ``` -In particular, since they are so common, the `Ty` and `TyCtxt` types -are imported directly. Other types are often referenced with an -explicit `ty::` prefix (e.g. `ty::TraitRef<'tcx>`). But some modules -choose to import a larger or smaller set of names explicitly. +in an example like this, we can subst from `MyStruct` to `MyStruct` (and so on) very cheaply, +by just replacing the one reference to `A` with `B`. But if we eagerly substituted all the fields, +that could be a lot more work because we might have to go through all of the fields in the `AdtDef` +and update all of their types. + +A bit more deeply, this corresponds to structs in Rust being [*nominal* types][nominal] — which +means that they are defined by their *name* (and that their contents are then indexed from the +definition of that name, and not carried along “within” the type itself). + +[nominal]: https://en.wikipedia.org/wiki/Nominal_type_system From 702f224bf6efb76b5a2a932a2c363ef00d7e6164 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 6 Jan 2020 05:47:43 +0900 Subject: [PATCH 0779/1812] Fix links --- src/appendix/code-index.md | 4 ++-- src/diagnostics.md | 6 +++--- src/rustc-driver.md | 2 +- src/the-parser.md | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 062293f7e..67030bee0 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -21,8 +21,8 @@ Item | Kind | Short description | Chapter | `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) `Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) -`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/librustc_span/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html) -`SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/libsyntax/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html) +`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/librustc_span/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html) +`SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/librustc_span/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/librustc_span/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html) `syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) diff --git a/src/diagnostics.md b/src/diagnostics.md index f646d70a2..0bf869ccd 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -9,14 +9,14 @@ This chapter is about how to emit compile errors and lints from the compiler. location in the code being compiled. `Span`s are attached to most constructs in HIR and MIR, allowing for more informative error reporting. -[span]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.Span.html +[span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html A `Span` can be looked up in a [`SourceMap`][sourcemap] to get a "snippet" useful for displaying errors with [`span_to_snippet`][sptosnip] and other similar methods on the `SourceMap`. -[sourcemap]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html -[sptosnip]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html#method.span_to_snippet +[sourcemap]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html +[sptosnip]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html#method.span_to_snippet ## Error messages diff --git a/src/rustc-driver.md b/src/rustc-driver.md index eb5390a92..50c7b2731 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -54,6 +54,6 @@ thread-locals, although you should rarely need to touch it. [`Compiler`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html [`Session`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html [`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html -[`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html +[`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html [stupid-stats]: https://github.com/nrc/stupid-stats [Appendix A]: appendix/stupid-stats.html diff --git a/src/the-parser.md b/src/the-parser.md index d089a8418..3584d73e4 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -53,11 +53,11 @@ Code for lexical analysis is split between two crates: [libsyntax]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/index.html [rustc_errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree -[`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceMap.html +[`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html [ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/index.html [librustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/index.html [`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/parser/struct.Parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html [visit module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/visit/index.html -[sourcefile]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/source_map/struct.SourceFile.html +[sourcefile]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html From 2ef6c927d1e51242849b679415da7ce64b66d712 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 9 Jan 2020 03:48:26 +0900 Subject: [PATCH 0780/1812] Fix links and paths --- src/appendix/code-index.md | 10 +++++----- src/hir.md | 22 +++++++++++----------- src/rustdoc.md | 2 +- src/ty.md | 32 ++++++++++++++++---------------- 4 files changed, 33 insertions(+), 33 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 67030bee0..39e16c1cb 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -6,14 +6,14 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- -`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html) +`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html) `Compiler` | struct | Represents a compiler session and can be used to drive a compilation. | [The Rustc Driver and Interface] | [src/librustc_interface/interface.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html) -`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) -`hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html) -`DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html) +`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) +`rustc_hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html) +`DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html) `DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) -`HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc/hir/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html) +`HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html) `NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) `P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [src/syntax/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ptr/struct.P.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) diff --git a/src/hir.md b/src/hir.md index 67becec12..60a3c3b8b 100644 --- a/src/hir.md +++ b/src/hir.md @@ -27,7 +27,7 @@ data structure basically just contains the root module, the HIR `Crate` structure contains a number of maps and other things that serve to organize the content of the crate for easier access. -[`Crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Crate.html +[`Crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html For example, the contents of individual items (e.g. modules, functions, traits, impls, etc) in the HIR are not immediately @@ -45,7 +45,7 @@ struct) would only have the **`ItemId`** `I` of `bar()`. To get the details of the function `bar()`, we would lookup `I` in the `items` map. -[`Mod`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Mod.html +[`Mod`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Mod.html One nice result from this representation is that one can iterate over all items in the crate by iterating over the key-value pairs @@ -55,14 +55,14 @@ as well as "bodies" (explained below). The other reason to set up the representation this way is for better integration with incremental compilation. This way, if you gain access -to an [`&hir::Item`] (e.g. for the mod `foo`), you do not immediately +to an [`&rustc_hir::Item`] (e.g. for the mod `foo`), you do not immediately gain access to the contents of the function `bar()`. Instead, you only gain access to the **id** for `bar()`, and you must invoke some function to lookup the contents of `bar()` given its id; this gives the compiler a chance to observe that you accessed the data for `bar()`, and then record the dependency. -[`&hir::Item`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Item.html +[`&rustc_hir::Item`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Item.html @@ -97,9 +97,9 @@ sorts of identifiers in active use: tree causes the [`NodeId`]s of all subsequent code in the crate to change. This is terrible for incremental compilation, as you can perhaps imagine. -[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/def_id/struct.DefId.html -[`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.HirId.html -[`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.BodyId.html +[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html +[`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html +[`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html [`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html We also have an internal map to go from `DefId` to what’s called "Def path". "Def path" is like a @@ -141,9 +141,9 @@ that `n` must be some HIR expression, you can do [`&hir::Expr`][Expr], panicking if `n` is not in fact an expression. [find]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.find -[`Node`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/enum.Node.html +[`Node`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/enum.Node.html [expect_expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.expect_expr -[Expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Expr.html +[Expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Expr.html Finally, you can use the HIR map to find the parents of nodes, via calls like [`tcx.hir.get_parent_node(n)`][get_parent_node]. @@ -152,7 +152,7 @@ calls like [`tcx.hir.get_parent_node(n)`][get_parent_node]. ### HIR Bodies -A [`hir::Body`] represents some kind of executable code, such as the body +A [`rustc_hir::Body`] represents some kind of executable code, such as the body of a function/closure or the definition of a constant. Bodies are associated with an **owner**, which is typically some kind of item (e.g. an `fn()` or `const`), but could also be a closure expression @@ -160,6 +160,6 @@ associated with an **owner**, which is typically some kind of item associated with a given def-id ([`maybe_body_owned_by`]) or to find the owner of a body ([`body_owner_def_id`]). -[`hir::Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Body.html +[`rustc_hir::Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Body.html [`maybe_body_owned_by`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.maybe_body_owned_by [`body_owner_def_id`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.body_owner_def_id diff --git a/src/rustdoc.md b/src/rustdoc.md index 318a8e2e1..fc964b18e 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -84,7 +84,7 @@ is the `impl Clean for visit_ast::RustdocVisitor`, which is called by You see, I actually lied a little earlier: There's another AST transformation that happens before the events in `clean/mod.rs`. In `visit_ast.rs` is the -type `RustdocVisitor`, which *actually* crawls a `hir::Crate` to get the first +type `RustdocVisitor`, which *actually* crawls a `rustc_hir::Crate` to get the first intermediate representation, defined in `doctree.rs`. This pass is mainly to get a few intermediate wrappers around the HIR types and to process visibility and inlining. This is where `#[doc(inline)]`, `#[doc(no_inline)]`, and diff --git a/src/ty.md b/src/ty.md index c9d2feba9..870e886d3 100644 --- a/src/ty.md +++ b/src/ty.md @@ -15,13 +15,13 @@ quite a few modules and types for `Ty` in the compiler ([Ty documentation][ty]). [ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/index.html The specific `Ty` we are referring to is [`rustc::ty::Ty`][ty_ty] (and not -[`rustc::hir::Ty`][hir_ty]). The distinction is important, so we will discuss it first before going +[`rustc_hir::Ty`][hir_ty]). The distinction is important, so we will discuss it first before going into the details of `ty::Ty`. [ty_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html -[hir_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/struct.Ty.html +[hir_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Ty.html -## `hir::Ty` vs `ty::Ty` +## `rustc_hir::Ty` vs `ty::Ty` The HIR in rustc can be thought of as the high-level intermediate representation. It is more or less the AST (see [this chapter](hir.md)) as it represents the @@ -30,7 +30,7 @@ representation of types, but in reality it reflects more of what the user wrote, wrote so as to represent that type. In contrast, `ty::Ty` represents the semantics of a type, that is, the *meaning* of what the user -wrote. For example, `hir::Ty` would record the fact that a user used the name `u32` twice in their +wrote. For example, `rustc_hir::Ty` would record the fact that a user used the name `u32` twice in their program, but the `ty::Ty` would record the fact that both usages refer to the same type. **Example: `fn foo(x: u32) → u32 { }`** In this function we see that `u32` appears twice. We know @@ -49,26 +49,26 @@ look like `fn foo<'a>(x: &'a u32) -> &'a u32)`. In the HIR level, these things are not spelled out and you can say the picture is rather incomplete. However, at the `ty::Ty` level, these details are added and it is complete. Moreover, we will have exactly one `ty::Ty` for a given type, like `u32`, and that `ty::Ty` is used for all `u32`s in the -whole program, not a specific usage, unlike `hir::Ty`. +whole program, not a specific usage, unlike `rustc_hir::Ty`. Here is a summary: -| [`hir::Ty`][hir_ty] | [`ty::Ty`][ty_ty] | +| [`rustc_hir::Ty`][hir_ty] | [`ty::Ty`][ty_ty] | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Describe the *syntax* of a type: what the user wrote (with some desugaring). | Describe the *semantics* of a type: the meaning of what the user wrote. | -| Each `hir::Ty` has its own spans corresponding to the appropriate place in the program. | Doesn’t correspond to a single place in the user’s program. | -| `hir::Ty` has generics and lifetimes; however, some of those lifetimes are special markers like [`LifetimeName::Implicit`][implicit]. | `ty::Ty` has the full type, including generics and lifetimes, even if the user left them out | -| `fn foo(x: u32) → u32 { }` - Two `hir::Ty` representing each usage of `u32`. Each has its own `Span`s, etc.- `hir::Ty` doesn’t tell us that both are the same type | `fn foo(x: u32) → u32 { }` - One `ty::Ty` for all instances of `u32` throughout the program.- `ty::Ty` tells us that both usages of `u32` mean the same type. | -| `fn foo(x: &u32) -> &u32)`- Two `hir::Ty` again.- Lifetimes for the references show up in the `hir::Ty`s using a special marker, [`LifetimeName::Implicit`][implicit]. | `fn foo(x: &u32) -> &u32)`- A single `ty::Ty`.- The `ty::Ty` has the hidden lifetime param | +| Each `rustc_hir::Ty` has its own spans corresponding to the appropriate place in the program. | Doesn’t correspond to a single place in the user’s program. | +| `rustc_hir::Ty` has generics and lifetimes; however, some of those lifetimes are special markers like [`LifetimeName::Implicit`][implicit]. | `ty::Ty` has the full type, including generics and lifetimes, even if the user left them out | +| `fn foo(x: u32) → u32 { }` - Two `rustc_hir::Ty` representing each usage of `u32`. Each has its own `Span`s, etc.- `rustc_hir::Ty` doesn’t tell us that both are the same type | `fn foo(x: u32) → u32 { }` - One `ty::Ty` for all instances of `u32` throughout the program.- `ty::Ty` tells us that both usages of `u32` mean the same type. | +| `fn foo(x: &u32) -> &u32)`- Two `rustc_hir::Ty` again.- Lifetimes for the references show up in the `rustc_hir::Ty`s using a special marker, [`LifetimeName::Implicit`][implicit]. | `fn foo(x: &u32) -> &u32)`- A single `ty::Ty`.- The `ty::Ty` has the hidden lifetime param | -[implicit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/enum.LifetimeName.html#variant.Implicit +[implicit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/enum.LifetimeName.html#variant.Implicit **Order** HIR is built directly from the AST, so it happens before any `ty::Ty` is produced. After HIR is built, some basic type inference and type checking is done. During the type inference, we figure out what the `ty::Ty` of everything is and we also check if the type of something is ambiguous. The `ty::Ty` then, is used for type checking while making sure everything has the expected type. The [`astconv` module][astconv], is where the code responsible for converting a -`hir::Ty` into a `ty::Ty` is located. This occurs during the type-checking phase, but also in other +`rustc_hir::Ty` into a `ty::Ty` is located. This occurs during the type-checking phase, but also in other parts of the compiler that want to ask questions like "what argument types does this function expect"?. @@ -85,7 +85,7 @@ we determine that they semantically are the same type and that’s the `ty::Ty` Consider another example: `fn foo(x: T) -> u32` and suppose that someone invokes `foo::(0)`. This means that `T` and `u32` (in this invocation) actually turns out to be the same type, so we -would eventually end up with the same `ty::Ty` in the end, but we have distinct `hir::Ty`. (This is +would eventually end up with the same `ty::Ty` in the end, but we have distinct `rustc_hir::Ty`. (This is a bit over-simplified, though, since during type checking, we would check the function generically and would still have a `T` distinct from `u32`. Later, when doing code generation, we would always be handling "monomorphized" (fully substituted) versions of each function, and hence we would know @@ -104,7 +104,7 @@ mod b { } ``` -Here the type `X` will vary depending on context, clearly. If you look at the `hir::Ty`, you will +Here the type `X` will vary depending on context, clearly. If you look at the `rustc_hir::Ty`, you will get back that `X` is an alias in both cases (though it will be mapped via name resolution to distinct aliases). But if you look at the `ty::Ty` signature, it will be either `fn(u32) -> u32` or `fn(i32) -> i32` (with type aliases fully expanded). @@ -466,7 +466,7 @@ You may have a couple of followup questions… replace a `SubstRef` with another list of types. [Here is an example of actually using `subst` in the compiler][substex]. The exact details are not -too important, but in this piece of code, we happen to be converting from the `hir::Ty` to a real +too important, but in this piece of code, we happen to be converting from the `rustc_hir::Ty` to a real `ty::Ty`. You can see that we first get some substitutions (`substs`). Then we call `type_of` to get a type and call `ty.subst(substs)` to get a new version of `ty` with the substitutions made. @@ -475,7 +475,7 @@ get a type and call `ty.subst(substs)` to get a new version of `ty` with the sub **Note on indices:** It is possible for the indices in `Param` to not match with what we expect. For example, the index could be out of bounds or it could be the index of a lifetime when we were expecting a type. These sorts of errors would be caught earlier in the compiler when translating -from a `hir::Ty` to a `ty::Ty`. If they occur later, that is a compiler bug. +from a `rustc_hir::Ty` to a `ty::Ty`. If they occur later, that is a compiler bug. ### `TypeFoldable` and `TypeFolder` From ba482526820476ddfb57162a36d33074fffeab09 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 9 Jan 2020 03:55:41 +0900 Subject: [PATCH 0781/1812] Fix line length --- src/ty.md | 35 ++++++++++++++++++----------------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/src/ty.md b/src/ty.md index 870e886d3..b665dadf1 100644 --- a/src/ty.md +++ b/src/ty.md @@ -30,8 +30,8 @@ representation of types, but in reality it reflects more of what the user wrote, wrote so as to represent that type. In contrast, `ty::Ty` represents the semantics of a type, that is, the *meaning* of what the user -wrote. For example, `rustc_hir::Ty` would record the fact that a user used the name `u32` twice in their -program, but the `ty::Ty` would record the fact that both usages refer to the same type. +wrote. For example, `rustc_hir::Ty` would record the fact that a user used the name `u32` twice +in their program, but the `ty::Ty` would record the fact that both usages refer to the same type. **Example: `fn foo(x: u32) → u32 { }`** In this function we see that `u32` appears twice. We know that that is the same type, i.e. the function takes an argument and returns an argument of the same @@ -68,9 +68,9 @@ HIR is built, some basic type inference and type checking is done. During the ty figure out what the `ty::Ty` of everything is and we also check if the type of something is ambiguous. The `ty::Ty` then, is used for type checking while making sure everything has the expected type. The [`astconv` module][astconv], is where the code responsible for converting a -`rustc_hir::Ty` into a `ty::Ty` is located. This occurs during the type-checking phase, but also in other -parts of the compiler that want to ask questions like "what argument types does this function -expect"?. +`rustc_hir::Ty` into a `ty::Ty` is located. This occurs during the type-checking phase, +but also in other parts of the compiler that want to ask questions like "what argument types does +this function expect"?. [astconv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/astconv/index.html @@ -85,11 +85,11 @@ we determine that they semantically are the same type and that’s the `ty::Ty` Consider another example: `fn foo(x: T) -> u32` and suppose that someone invokes `foo::(0)`. This means that `T` and `u32` (in this invocation) actually turns out to be the same type, so we -would eventually end up with the same `ty::Ty` in the end, but we have distinct `rustc_hir::Ty`. (This is -a bit over-simplified, though, since during type checking, we would check the function generically -and would still have a `T` distinct from `u32`. Later, when doing code generation, we would always -be handling "monomorphized" (fully substituted) versions of each function, and hence we would know -what `T` represents (and specifically that it is `u32`). +would eventually end up with the same `ty::Ty` in the end, but we have distinct `rustc_hir::Ty`. +(This is a bit over-simplified, though, since during type checking, we would check the function +generically and would still have a `T` distinct from `u32`. Later, when doing code generation, +we would always be handling "monomorphized" (fully substituted) versions of each function, +and hence we would know what `T` represents (and specifically that it is `u32`). Here is one more example: @@ -104,10 +104,10 @@ mod b { } ``` -Here the type `X` will vary depending on context, clearly. If you look at the `rustc_hir::Ty`, you will -get back that `X` is an alias in both cases (though it will be mapped via name resolution to -distinct aliases). But if you look at the `ty::Ty` signature, it will be either `fn(u32) -> u32` or -`fn(i32) -> i32` (with type aliases fully expanded). +Here the type `X` will vary depending on context, clearly. If you look at the `rustc_hir::Ty`, +you will get back that `X` is an alias in both cases (though it will be mapped via name resolution +to distinct aliases). But if you look at the `ty::Ty` signature, it will be either `fn(u32) -> u32` +or `fn(i32) -> i32` (with type aliases fully expanded). ## `ty::Ty` implementation @@ -466,9 +466,10 @@ You may have a couple of followup questions… replace a `SubstRef` with another list of types. [Here is an example of actually using `subst` in the compiler][substex]. The exact details are not -too important, but in this piece of code, we happen to be converting from the `rustc_hir::Ty` to a real -`ty::Ty`. You can see that we first get some substitutions (`substs`). Then we call `type_of` to -get a type and call `ty.subst(substs)` to get a new version of `ty` with the substitutions made. +too important, but in this piece of code, we happen to be converting from the `rustc_hir::Ty` to +a real `ty::Ty`. You can see that we first get some substitutions (`substs`). Then we call +`type_of` to get a type and call `ty.subst(substs)` to get a new version of `ty` with +the substitutions made. [substex]: https://github.com/rust-lang/rust/blob/597f432489f12a3f33419daa039ccef11a12c4fd/src/librustc_typeck/astconv.rs#L942-L953 From 97cab0192db75c2e4a0dbe2cdde44411dcef2707 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 13 Jan 2020 00:17:22 +0900 Subject: [PATCH 0782/1812] Fix links and paths --- src/appendix/bibliography.md | 2 +- src/implementing_new_features.md | 7 ++++--- src/stabilization_guide.md | 11 ++++++----- 3 files changed, 11 insertions(+), 9 deletions(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index 7c27a3ed6..dc06b63f5 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -28,7 +28,7 @@ Rust, as well as publications about Rust. * [A Java fork/join calamity](http://www.coopsoft.com/ar/CalamityArticle.html) - critique of Java's fork/join library, particularly its application of work stealing to non-strict computation * [Scheduling techniques for concurrent systems](http://www.stanford.edu/~ouster/cgi-bin/papers/coscheduling.pdf) * [Contention aware scheduling](http://www.blagodurov.net/files/a8-blagodurov.pdf) -* [Balanced work stealing for time-sharing multicores](http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-12-1.pdf) +* [Balanced work stealing for time-sharing multicores](https://web.njit.edu/~dingxn/papers/BWS.pdf) * [Three layer cake for shared-memory programming](http://dl.acm.org/citation.cfm?id=1953616&dl=ACM&coll=DL&CFID=524387192&CFTOKEN=44362705) * [Non-blocking steal-half work queues](http://www.cs.bgu.ac.il/%7Ehendlerd/papers/p280-hendler.pdf) * [Reagents: expressing and composing fine-grained concurrency](https://aturon.github.io/academic/reagents.pdf) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 4b2529fff..ff9a709e6 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -125,7 +125,7 @@ a new unstable feature: 2. Pick a name for the feature gate (for RFCs, use the name in the RFC). -3. Add a feature gate declaration to `libsyntax/feature_gate/active.rs` +3. Add a feature gate declaration to `librustc_feature/active.rs` in the active `declare_features` block: ```rust,ignore @@ -158,7 +158,8 @@ a new unstable feature: For features introducing new syntax, pre-expansion gating should be used instead. To do so, extend the [`GatedSpans`] struct, add spans to it during parsing, - and then finally feature-gate all the spans in [`feature_gate::check::check_crate`]. + and then finally feature-gate all the spans in + [`rustc_ast_passes::feature_gate::check_crate`]. 5. Add a test to ensure the feature cannot be used without a feature gate, by creating `feature-gate-$feature_name.rs` @@ -175,7 +176,7 @@ a new unstable feature: implemented a feature in Rust! [`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.GatedSpans.html -[`feature_gate::check::check_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/check/fn.check_crate.html +[`rustc_ast_passes::feature_gate::check_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_passes/feature_gate/fn.check_crate.html [value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md [stability in code]: #stability-in-code [here]: ./stabilization_guide.md diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 302be41d0..73edc3be5 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -91,7 +91,7 @@ should appear in the documentation. ### Updating the feature-gate listing There is a central listing of feature-gates in -[`src/libsyntax/feature_gate.rs`]. Search for the `declare_features!` +[`src/librustc_feature`]. Search for the `declare_features!` macro. There should be an entry for the feature you are aiming to stabilize, something like (this example is taken from [rust-lang/rust#32409]: @@ -140,7 +140,8 @@ Most importantly, remove the code which flags an error if the feature-gate is not present (since the feature is now considered stable). If the feature can be detected because it employs some new syntax, then a common place for that code to be is in the -same `feature_gate.rs`. For example, you might see code like this: +same `src/librustc_ast_passes/feature_gate.rs`. +For example, you might see code like this: ```rust,ignore gate_feature_post!(&self, pub_restricted, span, @@ -173,9 +174,9 @@ if self.tcx.sess.features.borrow().pub_restricted && something { /* XXX */ } if something { /* XXX */ } ``` -[rust-lang/rust#32409]:https://github.com/rust-lang/rust/issues/32409 -[`src/libsyntax/feature_gate.rs`]:https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/index.html -[The Reference]: https://github.com/rust-lang-nursery/reference +[rust-lang/rust#32409]: https://github.com/rust-lang/rust/issues/32409 +[`src/librustc_feature`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/index.html +[The Reference]: https://github.com/rust-lang/reference [The Book]: https://github.com/rust-lang/book [Rust by Example]: https://github.com/rust-lang/rust-by-example [`Unstable Book`]: https://doc.rust-lang.org/unstable-book/index.html From 41efacea44c3460d1c5400c68231387ebd607a03 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 14 Jan 2020 02:14:25 +0900 Subject: [PATCH 0783/1812] Fix links --- book.toml | 2 +- src/borrow_check/two_phase_borrows.md | 2 +- src/diagnostics/lintstore.md | 2 +- src/mir/construction.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/book.toml b/book.toml index bbba6d60c..3a5b1fd6d 100644 --- a/book.toml +++ b/book.toml @@ -15,6 +15,6 @@ level = 1 [output.linkcheck] follow-web-links = true -exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org" ] +exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il" ] cache-timeout = 172800 warning-policy = "error" diff --git a/src/borrow_check/two_phase_borrows.md b/src/borrow_check/two_phase_borrows.md index 09e7fbefe..f036c3a8c 100644 --- a/src/borrow_check/two_phase_borrows.md +++ b/src/borrow_check/two_phase_borrows.md @@ -74,7 +74,7 @@ The activation points are found using the [`GatherBorrows`] visitor. The borrow. [`AutoBorrow`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/adjustment/enum.AutoBorrow.html -[converted]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/cx/expr/trait.ToBorrowKind.html#method.to_borrow_kind +[converted]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/hair/cx/expr/trait.ToBorrowKind.html#method.to_borrow_kind [`BorrowKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.BorrowKind.html [`GatherBorrows`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/visit/trait.Visitor.html#method.visit_local [`BorrowData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/borrow_set/struct.BorrowData.html diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index 32e6ef8b8..b0ae9a328 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -95,7 +95,7 @@ New lints being added likely want to join one of the existing declarations like `late_lint_mod_passes` in `librustc_lint/lib.rs`, which would then auto-propagate into the other. -[`LintStore::register_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/struct.LintStore.html#method.register_lints +[`LintStore::register_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html#method.register_lints [`rustc_interface::register_plugins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.register_plugins.html [`rustc_lint::register_builtins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_builtins.html [`rustc_lint::register_internals`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_internals.html diff --git a/src/mir/construction.md b/src/mir/construction.md index 35d68ad73..bc0db84f9 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -152,7 +152,7 @@ case of `enum`s. [MIR]: ./index.html [HIR]: ../hir.html -[HAIR]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/index.html +[HAIR]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/hair/index.html [rustc_mir::hair::cx::expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/cx/expr/index.html -[`mir_built`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.mir_built.html +[`mir_built`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/build/fn.mir_built.html From cf6447aff01e4bcb1fdbc89d6f754451a157589e Mon Sep 17 00:00:00 2001 From: jethrogb Date: Mon, 13 Jan 2020 20:06:54 -0800 Subject: [PATCH 0784/1812] Update .gitattributes See https://github.com/rust-lang/rust/pull/57858 --- .gitattributes | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/.gitattributes b/.gitattributes index d56abbf30..fd394480f 100644 --- a/.gitattributes +++ b/.gitattributes @@ -1,2 +1,7 @@ # Set the default behavior, in case people don't have core.autocrlf set. * text=auto eol=lf + +# Older git versions try to fix line endings on images, this prevents it. +*.png binary +*.jpg binary +*.ico binary From 92baf7293dd2d418d2ac4b141b0faa822075d9f7 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 14 Jan 2020 13:47:41 +0900 Subject: [PATCH 0785/1812] Fix link --- src/mir/construction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index bc0db84f9..52d1f4609 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -24,7 +24,7 @@ being a `hair::ExprKind::Neg(hair::Expr)` it is a `hair::ExprKind::Neg(hir::Expr This shallowness enables the `HAIR` to represent all datatypes that [HIR] has, but without having to create an in-memory copy of the entire [HIR]. [MIR] lowering will first convert the topmost expression from -[HIR] to [HAIR] (in [rustc_mir::hair::cx::expr]) and then process +[HIR] to [HAIR] (in [`rustc_mir_build::hair::cx::expr`]) and then process the [HAIR] expressions recursively. The lowering creates local variables for every argument as specified in the signature. @@ -154,5 +154,5 @@ case of `enum`s. [HIR]: ../hir.html [HAIR]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/hair/index.html -[rustc_mir::hair::cx::expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/cx/expr/index.html +[`rustc_mir_build::hair::cx::expr`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/hair/cx/expr/index.html [`mir_built`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/build/fn.mir_built.html From a8b58d4c0d8d114222ad3e8e9c2150279de44afa Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Thu, 23 Jan 2020 14:18:51 -0500 Subject: [PATCH 0786/1812] add cleanup crew (#556) * add cleanup crew * update the text about carog-bisect-rustc etc * Update src/ice-breaker/cleanup-crew.md Co-Authored-By: lqd * finish the 3rd section * fix typo * clarify when you need to find PR range * add link to zulip stream Co-authored-by: lqd --- src/SUMMARY.md | 1 + src/ice-breaker/cleanup-crew.md | 114 ++++++++++++++++++++++++++++++++ 2 files changed, 115 insertions(+) create mode 100644 src/ice-breaker/cleanup-crew.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 125e20cf6..d88d23082 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -30,6 +30,7 @@ - [`LintStore`](./diagnostics/lintstore.md) - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) - [ICE-breaker teams](ice-breaker/about.md) + - ["Cleanup Crew" ICE-breakers](ice-breaker/cleanup-crew.md) - [LLVM ICE-breakers](ice-breaker/llvm.md) - [Part 2: How rustc works](./part-2-intro.md) - [High-level overview of the compiler source](./high-level-overview.md) diff --git a/src/ice-breaker/cleanup-crew.md b/src/ice-breaker/cleanup-crew.md new file mode 100644 index 000000000..436b51fd1 --- /dev/null +++ b/src/ice-breaker/cleanup-crew.md @@ -0,0 +1,114 @@ +# Cleanup Crew + +**Github Label:** [ICEBreaker-Cleanup-Crew] + +[ICEBreaker-Cleanup-Crew]: https://github.com/rust-lang/rust/labels/ICEBreaker-Cleanup-Crew + +The "Cleanup Crew" are focused on improving bug reports. Specifically, +the goal is to try to ensure that every bug report has all the +information that will be needed for someone to fix it: + +* a minimal, standalone example that shows the problem +* links to duplicates or related bugs +* if the bug is a regression (something that used to work, but no longer does), + then a bisection to the PR or nightly that caused the regression + +This kind of cleanup is invaluable in getting bugs fixed. Better +still, it can be done by anybody who knows Rust, without any +particularly deep knowledge of the compiler. + +Let's look a bit at the workflow for doing "cleanup crew" actions. + +## Finding a minimal, standalone example + +Here the ultimate goal is to produce an example that reproduces the same +problem but without relying on any external crates. Such a test ought to contain +as little code as possible, as well. This will make it much easier to isolate the problem. + +However, even if the "ultimate minimal test" cannot be achieved, it's +still useful to post incremental minimizations. For example, if you +can eliminate some of the external dependencies, that is helpful, and +so forth. + +It's particularly useful to reduce to an example that works +in the [Rust playground](https://play.rust-lang.org/), rather than +requiring people to checkout a cargo build. + +There are many resources for how to produce minimized test cases. Here +are a few: + +* The [rust-reduce](https://github.com/jethrogb/rust-reduce) tool can try to reduce + code automatically. + * The [C-reduce](https://embed.cs.utah.edu/creduce/) tool also works + on Rust code, though it requires that you start from a single + file. (XXX link to some post explaining how to do it?) +* pnkfelix's [Rust Bug Minimization Patterns] blog post + * This post focuses on "heavy bore" techniques, where you are + starting with a large, complex cargo project that you wish to + narrow down to something standalone. + +[Rust Bug Minimization Patterns]: http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/ + +## Links to duplicate or related bugs + +If you are on the "Cleanup Crew", you will sometimes see multiple bug +reports that seem very similar. You can link one to the other just by +mentioning the other bug number in a Github comment. Sometimes it is +useful to close duplicate bugs. But if you do so, you should always +copy any test case from the bug you are closing to the other bug that +remains open, as sometimes duplicate-looking bugs will expose +different facets of the same problem. + +## Bisecting regressions + +For regressions (something that used to work, but no longer does), it +is super useful if we can figure out precisely when the code stopped +working. The gold standard is to be able to identify the precise +**PR** that broke the code, so we can ping the author, but even +narrowing it down to a nightly build is helpful, especially as that +then gives us a range of PRs. (One other challenge is that we +sometimes land "rollup" PRs, which combine multiple PRs into one.) + +### cargo-bisect-rustc + +To help in figuring out the cause of a regression we have a tool +called [cargo-bisect-rustc]. It will automatically download and test +various builds of rustc. For recent regressions, it is even able to +use the builds from our CI to track down the regression to a specific +PR; for older regressions, it will simply identify a nightly. + +To learn to use [cargo-bisect-rustc], check out [this blog +post][learn], which gives a quick introduction to how it works. You +can also ask questions at the Zulip stream +[`#t-compiler/cargo-bisect-rustc`][zcbr], or help in improving the tool. + +[cargo-bisect-rustc]: https://github.com/rust-lang/cargo-bisect-rustc/ +[learn]: https://blog.rust-lang.org/inside-rust/2019/12/18/bisecting-rust-compiler.html +[zcbr]: https://rust-lang.zulipchat.com/#narrow/stream/217417-t-compiler.2Fcargo-bisect-rustc + +### identifying the range of PRs in a nightly + +If the regression occurred more than 90 days ago, then +cargo-bisect-rustc will not able to identify the particular PR that +caused the regression, just the nightly build. In that case, we can +identify the set of PRs that this corresponds to by using the git +history. + +The command `rustc +nightly -vV` will cause rustc to output a number +of useful bits of version info, including the `commit-hash`. Given the +commit-hash of two nightly versions, you can find all of PRs that have +landed in between by taking the following steps: + +1. Go to an update checkout of the [rust-lang/rust] repository +2. Execute the command `git log --author=bors --format=oneline SHA1..SHA2` + * This will list out all of the commits by bors, which is our merge bot + * Each commit corresponds to one PR, and information about the PR should be in the description +3. Copy and paste that information into the bug report + +Often, just eye-balling the PR descriptions (which are included in the +commit messages) will give you a good idea which one likely caused the +problem. But if you're unsure feel free to just ping the compiler team +(`@rust-lang/compiler`) or else to ping the authors of the PR +themselves. + +[rust-lang/rust]: https://github.com/rust-lang/rust/ From 0e32b4eeefe0c05278800b2ae8b387c67c2719f3 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 29 Jan 2020 18:11:45 +0100 Subject: [PATCH 0787/1812] Replaced simple comment with doc comment --- src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index ff9a709e6..9fb977761 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -129,7 +129,7 @@ a new unstable feature: in the active `declare_features` block: ```rust,ignore - // description of feature + /// description of feature (active, $feature_name, "$current_nightly_version", Some($tracking_issue_number), $edition) ``` From 7f19120125e7d19a5fd12a9d94b29f016450942c Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 27 Jan 2020 16:11:01 -0300 Subject: [PATCH 0788/1812] Add an example PR to join the Cleanup Crew ICE-Breakers --- src/ice-breaker/about.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md index 7869bdbce..6a82f7a00 100644 --- a/src/ice-breaker/about.md +++ b/src/ice-breaker/about.md @@ -49,6 +49,7 @@ cargo run add-person $your_user_name Example PRs: * [Example of adding yourself to the LLVM ICE-breakers.](https://github.com/rust-lang/team/pull/140) +* [Example of adding yourself to the Cleanup Crew ICE-breakers.](https://github.com/rust-lang/team/pull/221) ## Tagging an issue for an ICE-breaker group From a136b4b6c4008d7c6449ef2150600faa47d6960e Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 30 Jan 2020 14:01:42 -0600 Subject: [PATCH 0789/1812] use cargo install --- .travis.yml | 3 ++- ci/install.sh | 24 ------------------------ 2 files changed, 2 insertions(+), 25 deletions(-) delete mode 100755 ci/install.sh diff --git a/.travis.yml b/.travis.yml index 6ee759d4c..2c9aa573d 100644 --- a/.travis.yml +++ b/.travis.yml @@ -10,7 +10,8 @@ before_install: - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true -- bash -x ci/install.sh +- cargo install mdbook --version 0.3.4 +- cargo install mdbook-linkcheck --version 0.5.0 script: - mdbook build notifications: diff --git a/ci/install.sh b/ci/install.sh deleted file mode 100755 index 5cb2f41fc..000000000 --- a/ci/install.sh +++ /dev/null @@ -1,24 +0,0 @@ -#!/bin/bash - -set -ex - -function cargo_install() { - local name=$1 - local version=$2 - - if command -v $name >/dev/null 2>&1; then - local installed_version=`$name --version | sed -E 's/[a-zA-Z_-]+ v?//g'` - if [ "$installed_version" == "$version" ]; then - echo "$name $version is already installed at $(command -v $name)" - else - echo "Forcing install $name $version" - cargo install $name --version $version --force - fi - else - echo "Installing $name $version" - cargo install $name --version $version - fi -} - -cargo_install mdbook 0.3.4 -cargo_install mdbook-linkcheck 0.5.0 From f0a23c81ef5a801356b51ad4f404a144510aa92a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 2 Feb 2020 23:26:13 -0600 Subject: [PATCH 0790/1812] Fix broken links (#570) --- src/appendix/code-index.md | 4 ++-- src/diagnostics.md | 4 ++-- src/hir.md | 2 +- src/implementing_new_features.md | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 39e16c1cb..1b53e6426 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -14,10 +14,10 @@ Item | Kind | Short description | Chapter | `DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) `HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html) -`NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html) +`NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/node_id/struct.NodeId.html) `P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [src/syntax/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ptr/struct.P.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) -`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html) +`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html) `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) `Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) diff --git a/src/diagnostics.md b/src/diagnostics.md index 0bf869ccd..e65893cf5 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -31,7 +31,7 @@ usually have names like `span_err` or `struct_span_err` or `span_warn`, etc... There are lots of them; they emit different types of "errors", such as warnings, errors, fatal errors, suggestions, etc. -[parsesses]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html +[parsesses]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html [session]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html In general, there are two classes of such methods: ones that emit an error @@ -315,7 +315,7 @@ processed. [`Session`][sessbl] and [`ParseSess`][parsebl] both have system automatically takes care of handling buffered lints later. [sessbl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html#method.buffer_lint -[parsebl]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.ParseSess.html#method.buffer_lint +[parsebl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html#method.buffer_lint Thus, to define a lint that runs early in the compilation, one defines a lint like normal but invokes the lint with `buffer_lint`. diff --git a/src/hir.md b/src/hir.md index 60a3c3b8b..28cc83c58 100644 --- a/src/hir.md +++ b/src/hir.md @@ -100,7 +100,7 @@ sorts of identifiers in active use: [`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html [`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html [`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html -[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.NodeId.html +[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/node_id/struct.NodeId.html We also have an internal map to go from `DefId` to what’s called "Def path". "Def path" is like a module path but a bit more rich. For example, it may be `crate::foo::MyStruct` that identifies diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 9fb977761..27988056d 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -175,7 +175,7 @@ a new unstable feature: 8. Get your PR reviewed and land it. You have now successfully implemented a feature in Rust! -[`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/sess/struct.GatedSpans.html +[`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.GatedSpans.html [`rustc_ast_passes::feature_gate::check_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_passes/feature_gate/fn.check_crate.html [value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md [stability in code]: #stability-in-code From 0dde43f5798d6f6c0564d04d04d29ba9cab30a6e Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 2 Feb 2020 21:36:49 -0600 Subject: [PATCH 0791/1812] Update README --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 12d46b4e5..c2ac04052 100644 --- a/README.md +++ b/README.md @@ -42,8 +42,8 @@ be found. > cargo install mdbook-linkcheck ``` -You will need `mdbook` version `>= 0.2`. `linkcheck` will be run automatically -when you run `mdbook build`. +You will need `mdbook` version `>= 0.3.5` and `mdbook-linkcheck` version `>= 0.5`. +`linkcheck` will be run automatically when you run `mdbook build`. ## How to fix toolstate failures From 5bd60bc51efaec04e69e2e18b59678e2af066433 Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Sun, 2 Feb 2020 21:34:01 -0500 Subject: [PATCH 0792/1812] Add a mention of the new `-Zllvm-time-trace` flag --- src/codegen/debugging.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/codegen/debugging.md b/src/codegen/debugging.md index 4eab30606..0da29bfb9 100644 --- a/src/codegen/debugging.md +++ b/src/codegen/debugging.md @@ -123,6 +123,8 @@ tutorial above): - The `-Ztime-llvm-passes` option measures the time of each LLVM pass - The `-Zverify-llvm-ir` option will verify the LLVM IR for correctness - The `-Zno-parallel-llvm` will disable parallel compilation of distinct compilation units +- The `-Zllvm-time-trace` option will output a Chrome profiler compatible JSON file + which contains details and timings for LLVM passes. ### Filing LLVM bug reports From e69b9873578632b39f0f68bdd7b2ba7a21fbf2f1 Mon Sep 17 00:00:00 2001 From: Eduard-Mihai Burtescu Date: Thu, 6 Feb 2020 00:55:42 +0200 Subject: [PATCH 0793/1812] mir: begin documenting user variable debuginfo. (#571) --- src/mir/index.md | 32 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/src/mir/index.md b/src/mir/index.md index c02b86e9a..dbc2a316f 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -84,11 +84,7 @@ with a bunch of variable declarations. They look like this: ```mir let mut _0: (); // return place -scope 1 { - let mut _1: std::vec::Vec; // "vec" in scope 1 at src/main.rs:2:9: 2:16 -} -scope 2 { -} +let mut _1: std::vec::Vec; // in scope 0 at src/main.rs:2:9: 2:16 let mut _2: (); let mut _3: &mut std::vec::Vec; let mut _4: (); @@ -97,11 +93,27 @@ let mut _5: &mut std::vec::Vec; You can see that variables in MIR don't have names, they have indices, like `_0` or `_1`. We also intermingle the user's variables (e.g., -`_1`) with temporary values (e.g., `_2` or `_3`). You can tell the -difference between user-defined variables have a comment that gives -you their original name (`// "vec" in scope 1...`). The "scope" blocks -(e.g., `scope 1 { .. }`) describe the lexical structure of the source -program (which names were in scope when). +`_1`) with temporary values (e.g., `_2` or `_3`). You can tell apart +user-defined variables because they have debuginfo associated to them (see below). + +**User variable debuginfo.** Below the variable declarations, we find the only +hint that `_1` represents a user variable: +```mir +scope 1 { + debug vec => _1; // in scope 1 at src/main.rs:2:9: 2:16 +} +``` +Each `debug => ;` annotation describes a named user variable, +and where (i.e. the place) a debugger can find the data of that variable. +Here the mapping is trivial, but optimizations may complicate the place, +or lead to multiple user variables sharing the same place. +Additionally, closure captures are described using the same system, and so +they're complicated even without optimizations, e.g.: `debug x => (*((*_1).0: &T));`. + +The "scope" blocks (e.g., `scope 1 { .. }`) describe the lexical structure of +the source program (which names were in scope when), so any part of the program +annotated with `// in scope 0` would be missing `vec`, if you were stepping +through the code in a debugger, for example. **Basic blocks.** Reading further, we see our first **basic block** (naturally it may look slightly different when you view it, and I am ignoring some of the From d1ea643074707766807c17eeb53452ea4891c47c Mon Sep 17 00:00:00 2001 From: Felix S Klock II Date: Thu, 6 Feb 2020 14:38:42 -0500 Subject: [PATCH 0794/1812] Added example of icebreakers-cleanup-crew (I figure its low cost to just list all the possible pings, compared to the cost of people getting the command wrong or not even knowing the full set of teams possible.) --- src/ice-breaker/about.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md index 6a82f7a00..e71001e5b 100644 --- a/src/ice-breaker/about.md +++ b/src/ice-breaker/about.md @@ -59,6 +59,7 @@ team. For example: ```text @rustbot ping icebreakers-llvm +@rustbot ping icebreakers-cleanup-crew ``` **Note though that this should only be done by compiler team members From 693a92f2d20ed126a3661cd6975e35a5d99f9489 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomasz=20Mi=C4=85sko?= Date: Mon, 10 Feb 2020 16:53:59 +0100 Subject: [PATCH 0795/1812] Update sanitizers documentation (#562) --- src/sanitizers.md | 44 +++++++++++++++++++++++++------------------- 1 file changed, 25 insertions(+), 19 deletions(-) diff --git a/src/sanitizers.md b/src/sanitizers.md index 6205433e5..5e1f396f5 100644 --- a/src/sanitizers.md +++ b/src/sanitizers.md @@ -1,6 +1,6 @@ # Sanitizers Support -The rustc compiler contains basic support for following sanitizers: +The rustc compiler contains support for following sanitizers: * [AddressSanitizer][clang-asan] a faster memory error detector. Can detect out-of-bounds access to heap, stack, and globals, use after free, use @@ -17,13 +17,12 @@ sanitizers please refer to [the unstable book](https://doc.rust-lang.org/unstabl ## How are sanitizers implemented in rustc? -The implementation of sanitizers relies entirely on LLVM. It consists of -compile time instrumentation passes and runtime libraries. The role rustc plays -in the implementation is limited to the execution of the following steps: +The implementation of sanitizers relies almost entirely on LLVM. The rustc is +an integration point for LLVM compile time instrumentation passes and runtime +libraries. Highlight of the most important aspects of the implementation: -1. The sanitizer runtime libraries are part of the [compiler-rt] project, and - [will be built as an LLVM subproject][sanitizer-build] when enabled in - `config.toml`: +* The sanitizer runtime libraries are part of the [compiler-rt] project, and + [will be built on supported targets][sanitizer-build] when enabled in `config.toml`: ```toml [build] @@ -32,27 +31,34 @@ in the implementation is limited to the execution of the following steps: The runtimes are [placed into target libdir][sanitizer-copy]. -2. During LLVM code generation, the functions intended for instrumentation are - [marked][sanitizer-attribute] with `SanitizeAddress`, `SanitizeMemory`, or - `SanitizeThread` attribute. Currently those attributes are applied in - indiscriminate manner. but in principle they could be used to perform - instrumentation selectively. +* During LLVM code generation, the functions intended for instrumentation are + [marked][sanitizer-attribute] with appropriate LLVM attribute: + `SanitizeAddress`, `SanitizeMemory`, or `SanitizeThread`. By default all + functions are instrumented, but this behaviour can be changed with + `#[no_sanitize(...)]`. -3. The LLVM IR generated by rustc is instrumented by [dedicated LLVM +* The decision whether to perform instrumentation or not is possible only at a + function granularity. In the cases were those decision differ between + functions it might be necessary to inhibit inlining, both at [MIR + level][inline-mir] and [LLVM level][inline-llvm]. + +* The LLVM IR generated by rustc is instrumented by [dedicated LLVM passes][sanitizer-pass], different for each sanitizer. Instrumentation passes are invoked after optimization passes. -4. When producing an executable, the sanitizer specific runtime library is +* When producing an executable, the sanitizer specific runtime library is [linked in][sanitizer-link]. The libraries are searched for in target libdir relative to default system root, so that this process is not affected by sysroot overrides used for example by cargo `-Zbuild-std` functionality. [compiler-rt]: https://github.com/llvm/llvm-project/tree/master/compiler-rt -[sanitizer-build]: https://github.com/rust-lang/rust/blob/87c3eedffba64830b67e54e75dd479f9fd83cc7d/src/bootstrap/native.rs#L220-L225 -[sanitizer-copy]: https://github.com/rust-lang/rust/blob/87c3eedffba64830b67e54e75dd479f9fd83cc7d/src/bootstrap/compile.rs#L269-L321 -[sanitizer-attribute]: https://github.com/rust-lang/rust/blob/1.38.0/src/librustc_codegen_llvm/declare.rs#L53-L66 -[sanitizer-pass]: https://github.com/rust-lang/rust/blob/1.38.0/src/librustc_codegen_ssa/back/write.rs#L406-L420 -[sanitizer-link]: https://github.com/rust-lang/rust/blob/87c3eedffba64830b67e54e75dd479f9fd83cc7d/src/librustc_codegen_ssa/back/link.rs#L729-L770 +[sanitizer-build]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/bootstrap/native.rs#L566-L624 +[sanitizer-copy]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/bootstrap/compile.rs#L270-L304 +[sanitizer-attribute]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/librustc_codegen_llvm/attributes.rs#L49-L72 +[inline-mir]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/librustc_mir/transform/inline.rs#L232-L252 +[inline-llvm]: https://github.com/rust-lang/llvm-project/blob/9330ec5a4c1df5fc1fa62f993ed6a04da68cb040/llvm/include/llvm/IR/Attributes.td#L225-L241 +[sanitizer-pass]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/librustc_codegen_llvm/back/write.rs#L454-L475 +[sanitizer-link]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/librustc_codegen_ssa/back/link.rs#L748-L787 ## Additional Information From 2d834a7578fa2961cc141f0cc10436ed11e42216 Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Mon, 10 Feb 2020 16:32:36 -0500 Subject: [PATCH 0796/1812] minor typo fix --- src/codegen/backend-agnostic.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/codegen/backend-agnostic.md b/src/codegen/backend-agnostic.md index 3bf1bde83..cda841b2d 100644 --- a/src/codegen/backend-agnostic.md +++ b/src/codegen/backend-agnostic.md @@ -89,7 +89,7 @@ parameters, that correspond to the following: Although there are already many lifetime parameters in the code, making it generic uncovered situations where the borrow-checker was passing only due to the special nature of the LLVM objects manipulated (they are extern pointers). -For instance, a additional lifetime parameter had to be added to +For instance, an additional lifetime parameter had to be added to `LocalAnalyser` in `analyse.rs`, leading to the definition: ```rust,ignore From 6480932518ecc53aca2ca2fffcbdeec37b57e4ac Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Mon, 10 Feb 2020 19:10:41 -0500 Subject: [PATCH 0797/1812] minor typo fix --- src/codegen/backend-agnostic.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/codegen/backend-agnostic.md b/src/codegen/backend-agnostic.md index cda841b2d..0c501a2cc 100644 --- a/src/codegen/backend-agnostic.md +++ b/src/codegen/backend-agnostic.md @@ -179,7 +179,7 @@ addding another backend, the traits definition might be changed in order to offer more flexibility. However, the current separation between backend-agnostic and LLVM-specific code -has allows the reuse of a significant part of the old `rustc_codegen_llvm`. +has allowed the reuse of a significant part of the old `rustc_codegen_llvm`. Here is the new LOC breakdown between backend-agnostic (BA) and LLVM for the most important elements: From cb4c20039df67c6ef630b0a7229bb94b2392ff3d Mon Sep 17 00:00:00 2001 From: Loris-intergalactique Date: Wed, 12 Feb 2020 17:35:10 +0100 Subject: [PATCH 0798/1812] Minor typo correction --- src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/query.md b/src/query.md index f5961f6ba..aaf083178 100644 --- a/src/query.md +++ b/src/query.md @@ -1,7 +1,7 @@ # Queries: demand-driven compilation As described in [the high-level overview of the compiler][hl], the -Rust compiler is current transitioning from a traditional "pass-based" +Rust compiler is currently transitioning from a traditional "pass-based" setup to a "demand-driven" system. **The Compiler Query System is the key to our new demand-driven organization.** The idea is pretty simple. You have various queries that compute things about the input From df680be24bb9b29b858cc3e3f264975f8e083554 Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Wed, 12 Feb 2020 15:15:44 -0500 Subject: [PATCH 0799/1812] Correction of type name (#576) `ConstraintSet` => `OutlivesConstraintSet` --- src/borrow_check/region_inference/constraint_propagation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index ee86ae148..6d190ae1a 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -100,7 +100,7 @@ much faster, as described shortly. In the code, the set of outlives constraints is given to the region inference context on creation in a parameter of type -[`ConstraintSet`]. The constraint set is basically just a list of `'a: +[`OutlivesConstraintSet`]. The constraint set is basically just a list of `'a: 'b` constraints. ### The outlives constraint graph and SCCs @@ -112,7 +112,7 @@ induces an edge `'a -> 'b`. This conversion happens in the [`RegionInferenceContext::new`] function that creates the inference context. -[`ConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/constraints/struct.OutlivesConstraintSet.html +[`OutlivesConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/constraints/struct.OutlivesConstraintSet.html [graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/constraints/struct.OutlivesConstraintSet.html#method.graph [`RegionInferenceContext::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.new From d6a6122b951c475fb12f8c407016efa397460cfa Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Fri, 14 Feb 2020 09:56:21 -0500 Subject: [PATCH 0800/1812] Add link to `rustc::mir::Location` (#579) --- src/borrow_check/region_inference.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 84d30bdb4..d0da861db 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -86,7 +86,7 @@ use sparse bitsets). The kinds of region elements are as follows: -- Each **location** in the MIR control-flow graph: a location is just +- Each **[`location`]** in the MIR control-flow graph: a location is just the pair of a basic block and an index. This identifies the point **on entry** to the statement with that index (or the terminator, if the index is equal to `statements.len()`). @@ -219,6 +219,7 @@ Here are some of the fields of the struct: [`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.constraints [`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints +[`location`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Location.html [`universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_regions [`universal_region_relations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_region_relations [`type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.type_tests From f53a6596231068760c7c4b2ac00e5b0e8702f3a6 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 15 Feb 2020 07:01:35 +0900 Subject: [PATCH 0801/1812] Fix link --- src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 9280fa9bc..0c7a7a2e3 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -211,7 +211,7 @@ TODO: maybe something about macros 2.0? [code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe [code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser [code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules -[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse.html +[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html [parsing]: ./the-parser.html From 39dd586828a6ef747fb4b6207988094066a00685 Mon Sep 17 00:00:00 2001 From: LORIS INTERGALACTIQUE <51478929+loris-intergalactique@users.noreply.github.com> Date: Sat, 15 Feb 2020 01:35:11 +0100 Subject: [PATCH 0802/1812] Add links to the rustc docs (#578) --- src/query.md | 50 +++++++++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/src/query.md b/src/query.md index aaf083178..9ae6baa9e 100644 --- a/src/query.md +++ b/src/query.md @@ -76,8 +76,8 @@ dependencies of the local crate). Note that what determines the crate that a query is targeting is not the *kind* of query, but the *key*. For example, when you invoke `tcx.type_of(def_id)`, that could be a local query or an external query, depending on what crate the `def_id` -is referring to (see the `self::keys::Key` trait for more information -on how that works). +is referring to (see the [`self::keys::Key`][Key] trait for more +information on how that works). Providers always have the same signature: @@ -96,8 +96,10 @@ They return the result of the query. #### How providers are setup When the tcx is created, it is given the providers by its creator using -the `Providers` struct. This struct is generated by the macros here, but it -is basically a big list of function pointers: +the [`Providers`][providers_struct] struct. This struct is generated by +the macros here, but it is basically a big list of function pointers: + +[providers_struct]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/struct.Providers.html ```rust,ignore struct Providers { @@ -110,11 +112,13 @@ At present, we have one copy of the struct for local crates, and one for external crates, though the plan is that we may eventually have one per crate. -These `Provider` structs are ultimately created and populated by +These `Providers` structs are ultimately created and populated by `librustc_driver`, but it does this by distributing the work throughout the other `rustc_*` crates. This is done by invoking -various `provide` functions. These functions tend to look something -like this: +various [`provide`][provide_fn] functions. These functions tend to look +something like this: + +[provide_fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/fn.provide.html ```rust,ignore pub fn provide(providers: &mut Providers) { @@ -147,13 +151,16 @@ fn fubar<'tcx>(tcx: TyCtxt<'tcx>, key: DefId) -> Fubar<'tcx> { ... } N.B. Most of the `rustc_*` crates only provide **local providers**. Almost all **extern providers** wind up going through the -[`rustc_metadata` crate][rustc_metadata], which loads the information from the -crate metadata. But in some cases there are crates that provide queries for -*both* local and external crates, in which case they define both a -`provide` and a `provide_extern` function that `rustc_driver` can -invoke. +[`rustc_metadata` crate][rustc_metadata], which loads the information +from the crate metadata. But in some cases there are crates that +provide queries for *both* local and external crates, in which case +they define both a [`provide`][ext_provide] and a +[`provide_extern`][ext_provide_extern] function that `rustc_driver` +can invoke. [rustc_metadata]: https://github.com/rust-lang/rust/tree/master/src/librustc_metadata +[ext_provide]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide.html +[ext_provide_extern]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide_extern.html ### Adding a new kind of query @@ -205,7 +212,7 @@ Let's go over them one by one: (`ty::queries::type_of`) that will be generated to represent this query. - **Query key type:** the type of the argument to this query. - This type must implement the `ty::query::keys::Key` trait, which + This type must implement the [`ty::query::keys::Key`][Key] trait, which defines (for example) how to map it to a crate, and so forth. - **Result type of query:** the type produced by this query. This type should (a) not use `RefCell` or other interior mutability and (b) be @@ -218,6 +225,8 @@ Let's go over them one by one: - **Query modifiers:** various flags and options that customize how the query is processed. +[Key]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/keys/trait.Key.html + So, to add a query: - Add an entry to `rustc_queries!` using the format above. @@ -229,7 +238,7 @@ So, to add a query: For each kind, the `rustc_queries` macro will generate a "query struct" named after the query. This struct is a kind of a place-holder describing the query. Each such struct implements the -`self::config::QueryConfig` trait, which has associated types for the +[`self::config::QueryConfig`][QueryConfig] trait, which has associated types for the key/value of that particular query. Basically the code generated looks something like this: @@ -247,13 +256,16 @@ impl<'tcx> QueryConfig for type_of<'tcx> { ``` There is an additional trait that you may wish to implement called -`self::config::QueryDescription`. This trait is used during cycle -errors to give a "human readable" name for the query, so that we can -summarize what was happening when the cycle occurred. Implementing -this trait is optional if the query key is `DefId`, but if you *don't* -implement it, you get a pretty generic error ("processing `foo`..."). +[`self::config::QueryDescription`][QueryDescription]. This trait is +used during cycle errors to give a "human readable" name for the query, +so that we can summarize what was happening when the cycle occurred. +Implementing this trait is optional if the query key is `DefId`, but +if you *don't* implement it, you get a pretty generic error ("processing `foo`..."). You can put new impls into the `config` module. They look something like this: +[QueryConfig]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/trait.QueryConfig.html +[QueryDescription]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/config/trait.QueryDescription.html + ```rust,ignore impl<'tcx> QueryDescription for queries::type_of<'tcx> { fn describe(tcx: TyCtxt, key: DefId) -> String { From 84d2a48f81b1acffe744cb54dada157a7b376591 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 15 Feb 2020 07:45:22 +0900 Subject: [PATCH 0803/1812] Update section following current state --- src/macro-expansion.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 0c7a7a2e3..bc3b9dc5c 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -69,14 +69,13 @@ defined in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp]. The interface of the macro parser is as follows (this is slightly simplified): ```rust,ignore -fn parse( - sess: ParserSession, - tts: TokenStream, - ms: &[TokenTree] +fn parse_tt( + parser: &mut Cow, + ms: &[TokenTree], ) -> NamedParseResult ``` -In this interface: +We use these items in macro parser: - `sess` is a "parsing session", which keeps track of some metadata. Most notably, this is used to keep track of errors that are generated so they can From d2e17ebf9c68f1dd2c801e9578a94aff3307317c Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 18 Feb 2020 14:45:02 -0600 Subject: [PATCH 0804/1812] fix link --- src/traits/hrtb.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/hrtb.md b/src/traits/hrtb.md index 8b3a9f649..f41d43ffd 100644 --- a/src/traits/hrtb.md +++ b/src/traits/hrtb.md @@ -40,8 +40,8 @@ subtyping, we recommend you read the paper). There are a few parts: 2. Match the impl against the [placeholder] obligation. 3. Check for _placeholder leaks_. +[hrsubtype]: ./hrtb.md [placeholder]: ../appendix/glossary.html#appendix-c-glossary -[hrsubtype]: https://github.com/rust-lang/rust/tree/master/src/librustc/infer/higher_ranked/README.md [paper by SPJ]: http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ So let's work through our example. From 3dd93bf6b925cac28bd14650900b456e156e7951 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 19 Feb 2020 07:31:20 -0600 Subject: [PATCH 0805/1812] spit of type folder and generics subchapters (#586) --- src/SUMMARY.md | 2 + src/generics.md | 144 ++++++++++++++++++++++++++++ src/ty-fold.md | 105 ++++++++++++++++++++ src/ty.md | 248 ------------------------------------------------ 4 files changed, 251 insertions(+), 248 deletions(-) create mode 100644 src/generics.md create mode 100644 src/ty-fold.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index d88d23082..56adee7e9 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -53,6 +53,8 @@ - [Debugging](./hir-debugging.md) - [Closure expansion](./closure.md) - [The `ty` module: representing types](./ty.md) + - [Generics and substitutions](./generics.md) + - [`TypeFolder` and `TypeFoldable`](./ty-fold.md) - [Generic arguments](./generic_arguments.md) - [Type inference](./type-inference.md) - [Trait solving (old-style)](./traits/resolution.md) diff --git a/src/generics.md b/src/generics.md new file mode 100644 index 000000000..310b9cda6 --- /dev/null +++ b/src/generics.md @@ -0,0 +1,144 @@ +# Generics and substitutions + +Given a generic type `MyType`, we may want to swap out the generics `A, B, …` for some +other types (possibly other generics or concrete types). We do this a lot while doing type +inference, type checking, and trait solving. Conceptually, during these routines, we may find out +that one type is equal to another type and want to swap one out for the other and then swap that out +for another type and so on until we eventually get some concrete types (or an error). + +In rustc this is done using the `SubstsRef` that we mentioned above (“substs” = “substitutions”). +Conceptually, you can think of `SubstsRef` of a list of types that are to be substituted for the +generic type parameters of the ADT. + +`SubstsRef` is a type alias of `List>` (see [`List` rustdocs][list]). +[`GenericArg`] is essentially a space-efficient wrapper around [`GenericArgKind`], which is an enum +indicating what kind of generic the type parameter is (type, lifetime, or const). Thus, `SubstsRef` +is conceptually like a `&'tcx [GenericArgKind<'tcx>]` slice (but it is actually a `List`). + +[list]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.List.html +[`GenericArg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.GenericArg.html +[`GenericArgKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/enum.GenericArgKind.html + +So why do we use this `List` type instead of making it really a slice? It has the length "inline", +so `&List` is only 32 bits. As a consequence, it cannot be "subsliced" (that only works if the +length is out of line). + +This also implies that you can check two `List`s for equality via `==` (which would be not be +possible for ordinary slices). This is precisely because they never represent a "sub-list", only the +complete `List`, which has been hashed and interned. + +So pulling it all together, let’s go back to our example above: + +```rust,ignore +struct MyStruct +``` + +- There would be an `AdtDef` (and corresponding `DefId`) for `MyStruct`. +- There would be a `TyKind::Param` (and corresponding `DefId`) for `T` (more later). +- There would be a `SubstsRef` containing the list `[GenericArgKind::Type(Ty(T))]` + - The `Ty(T)` here is my shorthand for entire other `ty::Ty` that has `TyKind::Param`, which we + mentioned in the previous point. +- This is one `TyKind::Adt` containing the `AdtDef` of `MyStruct` with the `SubstsRef` above. + +Finally, we will quickly mention the +[`Generics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.Generics.html) type. It +is used to give information about the type parameters of a type. + +### Unsubstituted Generics + +So above, recall that in our example the `MyStruct` struct had a generic type `T`. When we are (for +example) type checking functions that use `MyStruct`, we will need to be able to refer to this type +`T` without actually knowing what it is. In general, this is true inside all generic definitions: we +need to be able to work with unknown types. This is done via `TyKind::Param` (which we mentioned in +the example above). + +Each `TyKind::Param` contains two things: the name and the index. In general, the index fully +defines the parameter and is used by most of the code. The name is included for debug print-outs. +There are two reasons for this. First, the index is convenient, it allows you to include into the +list of generic arguments when substituting. Second, the index is more robust. For example, you +could in principle have two distinct type parameters that use the same name, e.g. `impl Foo { +fn bar() { .. } }`, although the rules against shadowing make this difficult (but those language +rules could change in the future). + +The index of the type parameter is an integer indicating its order in the list of the type +parameters. Moreover, we consider the list to include all of the type parameters from outer scopes. +Consider the following example: + +```rust,ignore +struct Foo { + // A would have index 0 + // B would have index 1 + + .. // some fields +} +impl Foo { + fn method() { + // inside here, X, Y and Z are all in scope + // X has index 0 + // Y has index 1 + // Z has index 2 + } +} +``` + +When we are working inside the generic definition, we will use `TyKind::Param` just like any other +`TyKind`; it is just a type after all. However, if we want to use the generic type somewhere, then +we will need to do substitutions. + +For example suppose that the `Foo` type from the previous example has a field that is a +`Vec`. Observe that `Vec` is also a generic type. We want to tell the compiler that the type +parameter of `Vec` should be replaced with the `A` type parameter of `Foo`. We do that with +substitutions: + +```rust,ignore +struct Foo { // Adt(Foo, &[Param(0), Param(1)]) + x: Vec, // Adt(Vec, &[Param(0)]) + .. +} + +fn bar(foo: Foo) { // Adt(Foo, &[u32, f32]) + let y = foo.x; // Vec => Vec +} +``` + +This example has a few different substitutions: + +- In the definition of `Foo`, in the type of the field `x`, we replace `Vec`'s type parameter with + `Param(0)`, the first parameter of `Foo`, so that the type of `x` is `Vec`. +- In the function `bar`, we specify that we want a `Foo`. This means that we will + substitute `Param(0)` and `Param(1)` with `u32` and `f32`. +- In the body of `bar`, we access `foo.x`, which has type `Vec`, but `Param(0)` has been + substituted for `u32`, so `foo.x` has type `Vec`. + +Let’s look a bit more closely at that last substitution to see why we use indexes. If we want to +find the type of `foo.x`, we can get generic type of `x`, which is `Vec`. Now we can take +the index `0` and use it to find the right type substitution: looking at `Foo`'s `SubstsRef`, we +have the list `[u32, f32]` , since we want to replace index `0`, we take the 0-th index of this +list, which is `u32`. Voila! + +You may have a couple of followup questions… + + **`type_of`** How do we get the “generic type of `x`"? You can get the type of pretty much anything + with the `tcx.type_of(def_id)` query. In this case, we would pass the `DefId` of the field `x`. + The `type_of` query always returns the definition with the generics that are in scope of the + definition. For example, `tcx.type_of(def_id_of_my_struct)` would return the “self-view” of + `MyStruct`: `Adt(Foo, &[Param(0), Param(1)])`. + +**`subst`** How do we actually do the substitutions? There is a function for that too! You use +[`subst`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/trait.Subst.html) to +replace a `SubstRef` with another list of types. + +[Here is an example of actually using `subst` in the compiler][substex]. The exact details are not +too important, but in this piece of code, we happen to be converting from the `rustc_hir::Ty` to +a real `ty::Ty`. You can see that we first get some substitutions (`substs`). Then we call +`type_of` to get a type and call `ty.subst(substs)` to get a new version of `ty` with +the substitutions made. + +[substex]: https://github.com/rust-lang/rust/blob/597f432489f12a3f33419daa039ccef11a12c4fd/src/librustc_typeck/astconv.rs#L942-L953 + +**Note on indices:** It is possible for the indices in `Param` to not match with what we expect. For +example, the index could be out of bounds or it could be the index of a lifetime when we were +expecting a type. These sorts of errors would be caught earlier in the compiler when translating +from a `rustc_hir::Ty` to a `ty::Ty`. If they occur later, that is a compiler bug. + + diff --git a/src/ty-fold.md b/src/ty-fold.md new file mode 100644 index 000000000..e144767dc --- /dev/null +++ b/src/ty-fold.md @@ -0,0 +1,105 @@ +# `TypeFoldable` and `TypeFolder` + +How is this `subst` query actually implemented? As you can imagine, we might want to do +substitutions on a lot of different things. For example, we might want to do a substitution directly +on a type like we did with `Vec` above. But we might also have a more complex type with other types +nested inside that also need substitutions. + +The answer is a couple of traits: +[`TypeFoldable`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFoldable.html) +and +[`TypeFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html). + +- `TypeFoldable` is implemented by types that embed type information. It allows you to recursively + process the contents of the `TypeFoldable` and do stuff to them. +- `TypeFolder` defines what you want to do with the types you encounter while processing the + `TypeFoldable`. + +For example, the `TypeFolder` trait has a method +[`fold_ty`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html#method.fold_ty) +that takes a type as input a type and returns a new type as a result. `TypeFoldable` invokes the +`TypeFolder` `fold_foo` methods on itself, giving the `TypeFolder` access to its contents (the +types, regions, etc that are contained within). + +You can think of it with this analogy to the iterator combinators we have come to love in rust: + +```rust,ignore +vec.iter().map(|e1| foo(e2)).collect() +// ^^^^^^^^^^^^ analogous to `TypeFolder` +// ^^^ analogous to `TypeFoldable` +``` + +So to reiterate: + +- `TypeFolder` is a trait that defines a “map” operation. +- `TypeFoldable` is a trait that is implemented by things that embed types. + +In the case of `subst`, we can see that it is implemented as a `TypeFolder`: +[`SubstFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.SubstFolder.html). +Looking at its implementation, we see where the actual substitutions are happening. + +However, you might also notice that the implementation calls this `super_fold_with` method. What is +that? It is a method of `TypeFoldable`. Consider the following `TypeFoldable` type `MyFoldable`: + +```rust,ignore +struct MyFoldable<'tcx> { + def_id: DefId, + ty: Ty<'tcx>, +} +``` + +The `TypeFolder` can call `super_fold_with` on `MyFoldable` if it just wants to replace some of the +fields of `MyFoldable` with new values. If it instead wants to replace the whole `MyFoldable` with a +different one, it would call `fold_with` instead (a different method on `TypeFoldable`). + +In almost all cases, we don’t want to replace the whole struct; we only want to replace `ty::Ty`s in +the struct, so usually we call `super_fold_with`. A typical implementation that `MyFoldable` could +have might do something like this: + +```rust,ignore +my_foldable: MyFoldable<'tcx> +my_foldable.subst(..., subst) + +impl TypeFoldable for MyFoldable { + fn super_fold_with(&self, folder: &mut impl TypeFolder<'tcx>) -> MyFoldable { + MyFoldable { + def_id: self.def_id.fold_with(folder), + ty: self.ty.fold_with(folder), + } + } + + fn super_visit_with(..) { } +} +``` + +Notice that here, we implement `super_fold_with` to go over the fields of `MyFoldable` and call +`fold_with` on *them*. That is, a folder may replace `def_id` and `ty`, but not the whole +`MyFoldable` struct. + +Here is another example to put things together: suppose we have a type like `Vec>`. The +`ty::Ty` would look like: `Adt(Vec, &[Adt(Vec, &[Param(X)])])`. If we want to do `subst(X => u32)`, +then we would first look at the overall type. We would see that there are no substitutions to be +made at the outer level, so we would descend one level and look at `Adt(Vec, &[Param(X)])`. There +are still no substitutions to be made here, so we would descend again. Now we are looking at +`Param(X)`, which can be substituted, so we replace it with `u32`. We can’t descend any more, so we +are done, and the overall result is `Adt(Vec, &[Adt(Vec, &[u32])])`. + +One last thing to mention: often when folding over a `TypeFoldable`, we don’t want to change most +things. We only want to do something when we reach a type. That means there may be a lot of +`TypeFoldable` types whose implementations basically just forward to their fields’ `TypeFoldable` +implementations. Such implementations of `TypeFoldable` tend to be pretty tedious to write by hand. +For this reason, there is a `derive` macro that allows you to `#![derive(TypeFoldable)]`. It is +defined +[here](https://github.com/rust-lang/rust/blob/master/src/librustc_macros/src/type_foldable.rs). + +**`subst`** In the case of substitutions the [actual +folder](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L467-L482) +is going to be doing the indexing we’ve already mentioned. There we define a `Folder` and call +`fold_with` on the `TypeFoldable` to process yourself. Then +[fold_ty](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L545-L573) +the method that process each type it looks for a `ty::Param` and for those it replaces it for +something from the list of substitutions, otherwise recursively process the type. To replace it, +calls +[ty_for_param](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L589-L624) +and all that does is index into the list of substitutions with the index of the `Param`. + diff --git a/src/ty.md b/src/ty.md index b665dadf1..9fc34527b 100644 --- a/src/ty.md +++ b/src/ty.md @@ -335,254 +335,6 @@ see `'tcx` lifetime on it). [adtdefq]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html#method.adt_def -### Generics and substitutions - -Given a generic type `MyType`, we may want to swap out the generics `A, B, …` for some -other types (possibly other generics or concrete types). We do this a lot while doing type -inference, type checking, and trait solving. Conceptually, during these routines, we may find out -that one type is equal to another type and want to swap one out for the other and then swap that out -for another type and so on until we eventually get some concrete types (or an error). - -In rustc this is done using the `SubstsRef` that we mentioned above (“substs” = “substitutions”). -Conceptually, you can think of `SubstsRef` of a list of types that are to be substituted for the -generic type parameters of the ADT. - -`SubstsRef` is a type alias of `List>` (see [`List` rustdocs][list]). -[`GenericArg`] is essentially a space-efficient wrapper around [`GenericArgKind`], which is an enum -indicating what kind of generic the type parameter is (type, lifetime, or const). Thus, `SubstsRef` -is conceptually like a `&'tcx [GenericArgKind<'tcx>]` slice (but it is actually a `List`). - -[list]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.List.html -[`GenericArg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.GenericArg.html -[`GenericArgKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/enum.GenericArgKind.html - -So why do we use this `List` type instead of making it really a slice? It has the length "inline", -so `&List` is only 32 bits. As a consequence, it cannot be "subsliced" (that only works if the -length is out of line). - -This also implies that you can check two `List`s for equality via `==` (which would be not be -possible for ordinary slices). This is precisely because they never represent a "sub-list", only the -complete `List`, which has been hashed and interned. - -So pulling it all together, let’s go back to our example above: - -```rust,ignore -struct MyStruct -``` - -- There would be an `AdtDef` (and corresponding `DefId`) for `MyStruct`. -- There would be a `TyKind::Param` (and corresponding `DefId`) for `T` (more later). -- There would be a `SubstsRef` containing the list `[GenericArgKind::Type(Ty(T))]` - - The `Ty(T)` here is my shorthand for entire other `ty::Ty` that has `TyKind::Param`, which we - mentioned in the previous point. -- This is one `TyKind::Adt` containing the `AdtDef` of `MyStruct` with the `SubstsRef` above. - -Finally, we will quickly mention the -[`Generics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.Generics.html) type. It -is used to give information about the type parameters of a type. - -### Unsubstituted Generics - -So above, recall that in our example the `MyStruct` struct had a generic type `T`. When we are (for -example) type checking functions that use `MyStruct`, we will need to be able to refer to this type -`T` without actually knowing what it is. In general, this is true inside all generic definitions: we -need to be able to work with unknown types. This is done via `TyKind::Param` (which we mentioned in -the example above). - -Each `TyKind::Param` contains two things: the name and the index. In general, the index fully -defines the parameter and is used by most of the code. The name is included for debug print-outs. -There are two reasons for this. First, the index is convenient, it allows you to include into the -list of generic arguments when substituting. Second, the index is more robust. For example, you -could in principle have two distinct type parameters that use the same name, e.g. `impl Foo { -fn bar() { .. } }`, although the rules against shadowing make this difficult (but those language -rules could change in the future). - -The index of the type parameter is an integer indicating its order in the list of the type -parameters. Moreover, we consider the list to include all of the type parameters from outer scopes. -Consider the following example: - -```rust,ignore -struct Foo { - // A would have index 0 - // B would have index 1 - - .. // some fields -} -impl Foo { - fn method() { - // inside here, X, Y and Z are all in scope - // X has index 0 - // Y has index 1 - // Z has index 2 - } -} -``` - -When we are working inside the generic definition, we will use `TyKind::Param` just like any other -`TyKind`; it is just a type after all. However, if we want to use the generic type somewhere, then -we will need to do substitutions. - -For example suppose that the `Foo` type from the previous example has a field that is a -`Vec`. Observe that `Vec` is also a generic type. We want to tell the compiler that the type -parameter of `Vec` should be replaced with the `A` type parameter of `Foo`. We do that with -substitutions: - -```rust,ignore -struct Foo { // Adt(Foo, &[Param(0), Param(1)]) - x: Vec, // Adt(Vec, &[Param(0)]) - .. -} - -fn bar(foo: Foo) { // Adt(Foo, &[u32, f32]) - let y = foo.x; // Vec => Vec -} -``` - -This example has a few different substitutions: - -- In the definition of `Foo`, in the type of the field `x`, we replace `Vec`'s type parameter with - `Param(0)`, the first parameter of `Foo`, so that the type of `x` is `Vec`. -- In the function `bar`, we specify that we want a `Foo`. This means that we will - substitute `Param(0)` and `Param(1)` with `u32` and `f32`. -- In the body of `bar`, we access `foo.x`, which has type `Vec`, but `Param(0)` has been - substituted for `u32`, so `foo.x` has type `Vec`. - -Let’s look a bit more closely at that last substitution to see why we use indexes. If we want to -find the type of `foo.x`, we can get generic type of `x`, which is `Vec`. Now we can take -the index `0` and use it to find the right type substitution: looking at `Foo`'s `SubstsRef`, we -have the list `[u32, f32]` , since we want to replace index `0`, we take the 0-th index of this -list, which is `u32`. Voila! - -You may have a couple of followup questions… - - **`type_of`** How do we get the “generic type of `x`"? You can get the type of pretty much anything - with the `tcx.type_of(def_id)` query. In this case, we would pass the `DefId` of the field `x`. - The `type_of` query always returns the definition with the generics that are in scope of the - definition. For example, `tcx.type_of(def_id_of_my_struct)` would return the “self-view” of - `MyStruct`: `Adt(Foo, &[Param(0), Param(1)])`. - -**`subst`** How do we actually do the substitutions? There is a function for that too! You use -[`subst`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/trait.Subst.html) to -replace a `SubstRef` with another list of types. - -[Here is an example of actually using `subst` in the compiler][substex]. The exact details are not -too important, but in this piece of code, we happen to be converting from the `rustc_hir::Ty` to -a real `ty::Ty`. You can see that we first get some substitutions (`substs`). Then we call -`type_of` to get a type and call `ty.subst(substs)` to get a new version of `ty` with -the substitutions made. - -[substex]: https://github.com/rust-lang/rust/blob/597f432489f12a3f33419daa039ccef11a12c4fd/src/librustc_typeck/astconv.rs#L942-L953 - -**Note on indices:** It is possible for the indices in `Param` to not match with what we expect. For -example, the index could be out of bounds or it could be the index of a lifetime when we were -expecting a type. These sorts of errors would be caught earlier in the compiler when translating -from a `rustc_hir::Ty` to a `ty::Ty`. If they occur later, that is a compiler bug. - -### `TypeFoldable` and `TypeFolder` - -How is this `subst` query actually implemented? As you can imagine, we might want to do -substitutions on a lot of different things. For example, we might want to do a substitution directly -on a type like we did with `Vec` above. But we might also have a more complex type with other types -nested inside that also need substitutions. - -The answer is a couple of traits: -[`TypeFoldable`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFoldable.html) -and -[`TypeFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html). - -- `TypeFoldable` is implemented by types that embed type information. It allows you to recursively - process the contents of the `TypeFoldable` and do stuff to them. -- `TypeFolder` defines what you want to do with the types you encounter while processing the - `TypeFoldable`. - -For example, the `TypeFolder` trait has a method -[`fold_ty`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html#method.fold_ty) -that takes a type as input a type and returns a new type as a result. `TypeFoldable` invokes the -`TypeFolder` `fold_foo` methods on itself, giving the `TypeFolder` access to its contents (the -types, regions, etc that are contained within). - -You can think of it with this analogy to the iterator combinators we have come to love in rust: - -```rust,ignore -vec.iter().map(|e1| foo(e2)).collect() -// ^^^^^^^^^^^^ analogous to `TypeFolder` -// ^^^ analogous to `Typefoldable` -``` - -So to reiterate: - -- `TypeFolder` is a trait that defines a “map” operation. -- `TypeFoldable` is a trait that is implemented by things that embed types. - -In the case of `subst`, we can see that it is implemented as a `TypeFolder`: -[`SubstFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.SubstFolder.html). -Looking at its implementation, we see where the actual substitutions are happening. - -However, you might also notice that the implementation calls this `super_fold_with` method. What is -that? It is a method of `TypeFoldable`. Consider the following `TypeFoldable` type `MyFoldable`: - -```rust,ignore -struct MyFoldable<'tcx> { - def_id: DefId, - ty: Ty<'tcx>, -} -``` - -The `TypeFolder` can call `super_fold_with` on `MyFoldable` if it just wants to replace some of the -fields of `MyFoldable` with new values. If it instead wants to replace the whole `MyFoldable` with a -different one, it would call `fold_with` instead (a different method on `TypeFoldable`). - -In almost all cases, we don’t want to replace the whole struct; we only want to replace `ty::Ty`s in -the struct, so usually we call `super_fold_with`. A typical implementation that `MyFoldable` could -have might do something like this: - -```rust,ignore -my_foldable: MyFoldable<'tcx> -my_foldable.subst(..., subst) - -impl TypeFoldable for MyFoldable { - fn super_fold_with(&self, folder: &mut impl TypeFolder<'tcx>) -> MyFoldable { - MyFoldable { - def_id: self.def_id.fold_with(folder), - ty: self.ty.fold_with(folder), - } - } - - fn super_visit_with(..) { } -} -``` - -Notice that here, we implement `super_fold_with` to go over the fields of `MyFoldable` and call -`fold_with` on *them*. That is, a folder may replace `def_id` and `ty`, but not the whole -`MyFoldable` struct. - -Here is another example to put things together: suppose we have a type like `Vec>`. The -`ty::Ty` would look like: `Adt(Vec, &[Adt(Vec, &[Param(X)])])`. If we want to do `subst(X => u32)`, -then we would first look at the overall type. We would see that there are no substitutions to be -made at the outer level, so we would descend one level and look at `Adt(Vec, &[Param(X)])`. There -are still no substitutions to be made here, so we would descend again. Now we are looking at -`Param(X)`, which can be substituted, so we replace it with `u32`. We can’t descend any more, so we -are done, and the overall result is `Adt(Vec, &[Adt(Vec, &[u32])])`. - -One last thing to mention: often when folding over a `TypeFoldable`, we don’t want to change most -things. We only want to do something when we reach a type. That means there may be a lot of -`TypeFoldable` types whose implementations basically just forward to their fields’ `TypeFoldable` -implementations. Such implementations of `TypeFoldable` tend to be pretty tedious to write by hand. -For this reason, there is a `derive` macro that allows you to `#![derive(TypeFoldable)]`. It is -defined -[here](https://github.com/rust-lang/rust/blob/master/src/librustc_macros/src/type_foldable.rs). - -**`subst`** In the case of substitutions the [actual -folder](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L467-L482) -is going to be doing the indexing we’ve already mentioned. There we define a `Folder` and call -`fold_with` on the `TypeFoldable` to process yourself. Then -[fold_ty](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L545-L573) -the method that process each type it looks for a `ty::Param` and for those it replaces it for -something from the list of substitutions, otherwise recursively process the type. To replace it, -calls -[ty_for_param](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L589-L624) -and all that does is index into the list of substitutions with the index of the `Param`. - ## Type errors There is a `TyKind::Error` that is produced when the user makes a type error. The idea is that From 04832fa1bef12097adb3843e016609de535771bb Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 18 Feb 2020 11:36:57 -0600 Subject: [PATCH 0806/1812] document ./x.py fmt --- src/tests/intro.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/tests/intro.md b/src/tests/intro.md index 4572d23ca..eb8aec800 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -63,6 +63,15 @@ including: Example: `./x.py test src/tools/tidy` +- **Formatting** – Rustfmt is integrated with the build system to enforce + uniform style across the compiler. In the CI, we check that the formatting + is correct. + + Example: `./x.py fmt --check` checks formatting an exits with an error if + formatting is needed. + + Example: `./x.py fmt` runs rustfmt on the codebase. + - **Unit tests** – The Rust standard library and many of the Rust packages include typical Rust `#[test]` unittests. Under the hood, `x.py` will run `cargo test` on each package to run all the tests. From 1938249be057dd3669c5a664430750e9f5d711b8 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 20 Feb 2020 09:57:51 -0600 Subject: [PATCH 0807/1812] tidy runs rustfmt check --- src/tests/intro.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index eb8aec800..e5b7fcacc 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -65,7 +65,8 @@ including: - **Formatting** – Rustfmt is integrated with the build system to enforce uniform style across the compiler. In the CI, we check that the formatting - is correct. + is correct. The formatting check is also automatically run by the Tidy tool + mentioned above. Example: `./x.py fmt --check` checks formatting an exits with an error if formatting is needed. From 4b34444364d88d1eb82ded31afa0500a272cfb1f Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 20 Feb 2020 10:23:14 -0600 Subject: [PATCH 0808/1812] mention tidy bless --- src/tests/intro.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/tests/intro.md b/src/tests/intro.md index e5b7fcacc..6691f2d4e 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -73,6 +73,9 @@ including: Example: `./x.py fmt` runs rustfmt on the codebase. + Example: `./x.py test src/tools/tidy --bless` does formatting before doing + other tidy checks. + - **Unit tests** – The Rust standard library and many of the Rust packages include typical Rust `#[test]` unittests. Under the hood, `x.py` will run `cargo test` on each package to run all the tests. From f007762b9c5657f5cb5724abc46ca2c5f1f210a1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 18 Feb 2020 11:16:42 -0600 Subject: [PATCH 0809/1812] create a separate chapter on arenas/interning --- src/SUMMARY.md | 1 + src/memory.md | 88 +++++++++++++++++++++++++++++++ src/rustc-driver.md | 13 ----- src/ty.md | 117 +++++++++++------------------------------- src/type-inference.md | 7 --- 5 files changed, 119 insertions(+), 107 deletions(-) create mode 100644 src/memory.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 56adee7e9..ae1ea0b2e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -43,6 +43,7 @@ - [Debugging and Testing](./incrcomp-debugging.md) - [Profiling Queries](./queries/profiling.md) - [Salsa](./salsa.md) + - [Memory Management in Rustc](./memory.md) - [Lexing and Parsing](./the-parser.md) - [`#[test]` Implementation](./test-implementation.md) - [Panic Implementation](./panic-implementation.md) diff --git a/src/memory.md b/src/memory.md new file mode 100644 index 000000000..bfec4fe19 --- /dev/null +++ b/src/memory.md @@ -0,0 +1,88 @@ +# Memory Management in Rustc + +Rustc tries to be pretty careful how it manages memory. The compiler allocates +_a lot_ of data structures throughout compilation, and if we are not careful, +it will take a lot of time and space to do so. + +One of the main way the compiler manages this is using arenas and interning. + +## Arenas and Interning + +We create a LOT of data structures during compilation. For performance reasons, +we allocate them from a global memory pool; they are each allocated once from a +long-lived *arena*. This is called _arena allocation_. This system reduces +allocations/deallocations of memory. It also allows for easy comparison of +types for equality: for each interned type `X`, we implemented [`PartialEq for +X`][peqimpl], so we can just compare pointers. The [`CtxtInterners`] type +contains a bunch of maps of interned types and the arena itself. + +[peqimpl]: https://github.com/rust-lang/rust/blob/3ee936378662bd2e74be951d6a7011a95a6bd84d/src/librustc/ty/mod.rs#L528-L534 +[`CtxtInterners`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.CtxtInterners.html#structfield.arena + +### Example: `ty::TyS` + +Taking the example of [`ty::TyS`] which represents a type in the compiler (you +can read more [here](./ty.md)). Each time we want to construct a type, the +compiler doesn’t naively allocate from the buffer. Instead, we check if that +type was already constructed. If it was, we just get the same pointer we had +before, otherwise we make a fresh pointer. With this schema if we want to know +if two types are the same, all we need to do is compare the pointers which is +efficient. `TyS` is carefully setup so you never construct them on the stack. +You always allocate them from this arena and you always intern them so they are +unique. + +At the beginning of the compilation we make a buffer and each time we need to allocate a type we use +some of this memory buffer. If we run out of space we get another one. The lifetime of that buffer +is `'tcx`. Our types are tied to that lifetime, so when compilation finishes all the memory related +to that buffer is freed and our `'tcx` references would be invalid. + +In addition to types, there are a number of other arena-allocated data structures that you can +allocate, and which are found in this module. Here are a few examples: + +- [`Substs`][subst], allocated with `mk_substs` – this will intern a slice of types, often used to + specify the values to be substituted for generics (e.g. `HashMap` would be represented + as a slice `&'tcx [tcx.types.i32, tcx.types.u32]`). +- [`TraitRef`], typically passed by value – a **trait reference** consists of a reference to a trait + along with its various type parameters (including `Self`), like `i32: Display` (here, the def-id + would reference the `Display` trait, and the substs would contain `i32`). Note that `def-id` is + defined and discussed in depth in the `AdtDef and DefId` section. +- [`Predicate`] defines something the trait system has to prove (see `traits` module). + +[subst]: ./generic_arguments.html#subst +[`TraitRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html +[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.Predicate.html + +[`ty::TyS`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html + +## The tcx and how it uses lifetimes + +The `tcx` ("typing context") is the central data structure in the compiler. It is the context that +you use to perform all manner of queries. The struct `TyCtxt` defines a reference to this shared +context: + +```rust,ignore +tcx: TyCtxt<'tcx> +// ---- +// | +// arena lifetime +``` + +As you can see, the `TyCtxt` type takes a lifetime parameter. When you see a reference with a +lifetime like `'tcx`, you know that it refers to arena-allocated data (or data that lives as long as +the arenas, anyhow). + +### A Note On Lifetimes + +The Rust compiler is a fairly large program containing lots of big data +structures (e.g. the AST, HIR, and the type system) and as such, arenas and +references are heavily relied upon to minimize unnecessary memory use. This +manifests itself in the way people can plug into the compiler (i.e. the +[driver](./rustc-driver.md)), preferring a "push"-style API (callbacks) instead +of the more Rust-ic "pull" style (think the `Iterator` trait). + +Thread-local storage and interning are used a lot through the compiler to reduce +duplication while also preventing a lot of the ergonomic issues due to many +pervasive lifetimes. The [`rustc::ty::tls`][tls] module is used to access these +thread-locals, although you should rarely need to touch it. + +[tls]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/tls/index.html diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 50c7b2731..e240ea58b 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -32,19 +32,6 @@ replaces this functionality. > **Warning:** By its very nature, the internal compiler APIs are always going > to be unstable. That said, we do try not to break things unnecessarily. -## A Note On Lifetimes - -The Rust compiler is a fairly large program containing lots of big data -structures (e.g. the AST, HIR, and the type system) and as such, arenas and -references are heavily relied upon to minimize unnecessary memory use. This -manifests itself in the way people can plug into the compiler, preferring a -"push"-style API (callbacks) instead of the more Rust-ic "pull" style (think -the `Iterator` trait). - -Thread-local storage and interning are used a lot through the compiler to reduce -duplication while also preventing a lot of the ergonomic issues due to many -pervasive lifetimes. The `rustc::ty::tls` module is used to access these -thread-locals, although you should rarely need to touch it. [cb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/trait.Callbacks.html [rd_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.run_compiler.html diff --git a/src/ty.md b/src/ty.md index 9fc34527b..bb2c24b13 100644 --- a/src/ty.md +++ b/src/ty.md @@ -119,12 +119,41 @@ field of type [`TyKind`][tykind], which represents the key type information. `Ty which represents different kinds of types (e.g. primitives, references, abstract data types, generics, lifetimes, etc). `TyS` also has 2 more fields, `flags` and `outer_exclusive_binder`. They are convenient hacks for efficiency and summarize information about the type that we may want to -know, but they don’t come into the picture as much here. +know, but they don’t come into the picture as much here. Finally, `ty::TyS`s +are [interned](./memory.md), so that the `ty::Ty` can be a thin pointer-like +type. This allows us to do cheap comparisons for equality, along with the other +benefits of interning. [tys]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html [kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html#structfield.kind [tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html +## Allocating and working with types + +To allocate a new type, you can use the various `mk_` methods defined on the `tcx`. These have names +that correspond mostly to the various kinds of types. For example: + +```rust,ignore +let array_ty = tcx.mk_array(elem_ty, len * 2); +``` + +These methods all return a `Ty<'tcx>` – note that the lifetime you get back is the lifetime of the +arena that this `tcx` has access to. Types are always canonicalized and interned (so we never +allocate exactly the same type twice). + +> NB. Because types are interned, it is possible to compare them for equality efficiently using `==` +> – however, this is almost never what you want to do unless you happen to be hashing and looking +> for duplicates. This is because often in Rust there are multiple ways to represent the same type, +> particularly once inference is involved. If you are going to be testing for type equality, you +> probably need to start looking into the inference code to do it right. + +You can also find various common types in the `tcx` itself by accessing `tcx.types.bool`, +`tcx.types.char`, etc (see [`CommonTypes`] for more). + +[`CommonTypes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.CommonTypes.html + +## `ty::TyKind` Variants + Note: `TyKind` is **NOT** the functional programming concept of *Kind*. Whenever working with a `Ty` in the compiler, it is common to match on the kind of type: @@ -147,8 +176,6 @@ types in the compiler. There are a lot of related types, and we’ll cover them in time (e.g regions/lifetimes, “substitutions”, etc). -## `ty::TyKind` Variants - There are a bunch of variants on the `TyKind` enum, which you can see by looking at the rustdocs. Here is a sampling: @@ -191,90 +218,6 @@ will discuss this more later. [kinderr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Error [kindvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variants -## Interning - -We create a LOT of types during compilation. For performance reasons, we allocate them from a global -memory pool, they are each allocated once from a long-lived *arena*. This is called _arena -allocation_. This system reduces allocations/deallocations of memory. It also allows for easy -comparison of types for equality: we implemented [`PartialEq for TyS`][peqimpl], so we can just -compare pointers. The [`CtxtInterners`] type contains a bunch of maps of interned types and the -arena itself. - -[peqimpl]: https://github.com/rust-lang/rust/blob/3ee936378662bd2e74be951d6a7011a95a6bd84d/src/librustc/ty/mod.rs#L528-L534 -[`CtxtInterners`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.CtxtInterners.html#structfield.arena - -Each time we want to construct a type, the compiler doesn’t naively allocate from the buffer. -Instead, we check if that type was already constructed. If it was, we just get the same pointer we -had before, otherwise we make a fresh pointer. With this schema if we want to know if two types are -the same, all we need to do is compare the pointers which is efficient. `TyS` which represents types -is carefully setup so you never construct them on the stack. You always allocate them from this -arena and you always intern them so they are unique. - -At the beginning of the compilation we make a buffer and each time we need to allocate a type we use -some of this memory buffer. If we run out of space we get another one. The lifetime of that buffer -is `'tcx`. Our types are tied to that lifetime, so when compilation finishes all the memory related -to that buffer is freed and our `'tcx` references would be invalid. - - -## The tcx and how it uses lifetimes - -The `tcx` ("typing context") is the central data structure in the compiler. It is the context that -you use to perform all manner of queries. The struct `TyCtxt` defines a reference to this shared -context: - -```rust,ignore -tcx: TyCtxt<'tcx> -// ---- -// | -// arena lifetime -``` - -As you can see, the `TyCtxt` type takes a lifetime parameter. When you see a reference with a -lifetime like `'tcx`, you know that it refers to arena-allocated data (or data that lives as long as -the arenas, anyhow). - -## Allocating and working with types - -To allocate a new type, you can use the various `mk_` methods defined on the `tcx`. These have names -that correspond mostly to the various kinds of types. For example: - -```rust,ignore -let array_ty = tcx.mk_array(elem_ty, len * 2); -``` - -These methods all return a `Ty<'tcx>` – note that the lifetime you get back is the lifetime of the -arena that this `tcx` has access to. Types are always canonicalized and interned (so we never -allocate exactly the same type twice). - -> NB. Because types are interned, it is possible to compare them for equality efficiently using `==` -> – however, this is almost never what you want to do unless you happen to be hashing and looking -> for duplicates. This is because often in Rust there are multiple ways to represent the same type, -> particularly once inference is involved. If you are going to be testing for type equality, you -> probably need to start looking into the inference code to do it right. - -You can also find various common types in the `tcx` itself by accessing `tcx.types.bool`, -`tcx.types.char`, etc (see [`CommonTypes`] for more). - -[`CommonTypes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.CommonTypes.html - -## Beyond types: other kinds of arena-allocated data structures - -In addition to types, there are a number of other arena-allocated data structures that you can -allocate, and which are found in this module. Here are a few examples: - -- [`Substs`][subst], allocated with `mk_substs` – this will intern a slice of types, often used to - specify the values to be substituted for generics (e.g. `HashMap` would be represented - as a slice `&'tcx [tcx.types.i32, tcx.types.u32]`). -- [`TraitRef`], typically passed by value – a **trait reference** consists of a reference to a trait - along with its various type parameters (including `Self`), like `i32: Display` (here, the def-id - would reference the `Display` trait, and the substs would contain `i32`). Note that `def-id` is - defined and discussed in depth in the `AdtDef and DefId` section. -- [`Predicate`] defines something the trait system has to prove (see `traits` module). - -[subst]: ./generic_arguments.html#subst -[`TraitRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html -[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.Predicate.html - ## Import conventions Although there is no hard and fast rule, the `ty` module tends to be used like so: diff --git a/src/type-inference.md b/src/type-inference.md index d4734525f..a0ae13384 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -43,13 +43,6 @@ tcx.infer_ctxt().enter(|infcx| { }) ``` -Each inference context creates a short-lived type arena to store the -fresh types and things that it will create, as described in the -[chapter on the `ty` module][ty-ch]. This arena is created by the `enter` -function and disposed of after it returns. - -[ty-ch]: ty.html - Within the closure, `infcx` has the type `InferCtxt<'cx, 'tcx>` for some fresh `'cx`, while `'tcx` is the same as outside the inference context. (Again, see the [`ty` chapter][ty-ch] for more details on this setup.) From 31304c075f375bf561db90d82da8dcaaf1e20d80 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Tue, 18 Feb 2020 11:19:17 -0600 Subject: [PATCH 0810/1812] update glossary --- src/appendix/glossary.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index a773e3521..fbd76f25d 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -6,6 +6,7 @@ them better. Term | Meaning ------------------------|-------- +arena/arena allocation | an _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _area allocation_. See [this chapter](../memory.md) for more info. AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) @@ -33,7 +34,7 @@ ICE | internal compiler error. When the compiler crashes. ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. inference variable | when doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. infcx | the inference context (see `librustc/infer`) -intern | interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage. +intern | interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). item | a kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. From 69a36673350e19d5a4287f91a80f52dc0219c6b8 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Thu, 20 Feb 2020 09:55:33 -0600 Subject: [PATCH 0811/1812] add back link --- src/type-inference.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/type-inference.md b/src/type-inference.md index a0ae13384..dca93dbdf 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -47,6 +47,8 @@ Within the closure, `infcx` has the type `InferCtxt<'cx, 'tcx>` for some fresh `'cx`, while `'tcx` is the same as outside the inference context. (Again, see the [`ty` chapter][ty-ch] for more details on this setup.) +[ty-ch]: ty.html + The `tcx.infer_ctxt` method actually returns a builder, which means there are some kinds of configuration you can do before the `infcx` is created. See `InferCtxtBuilder` for more information. From 29b0d1ca816ddd4e17d50d65ddece19cf458562d Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 25 Feb 2020 07:05:37 +0100 Subject: [PATCH 0812/1812] Name resolution: Add intro section --- src/name-resolution.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/src/name-resolution.md b/src/name-resolution.md index 3117217e5..c7bf5d111 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -1,6 +1,23 @@ # Name resolution -The name resolution is a two-phase process. In the first phase, which runs +## Basics + +In our programs we can refer to variables, types, functions, etc, by giving them +a name. These names are not always unique. For example, take this valid Rust +program: + +```rust +type x = u32; +let x: x = 1; +let y: x = 2; +``` + +How do we know on line 3 whether `x` is a type (u32) or a value (1)? +These conflicts are resolved in `librustc_resolve`. +In this specific case, name resolution defines that type names and variable +names live in separate namespaces and therefore can co-exist. + +The name resolution in Rust is a two-phase process. In the first phase, which runs during macro expansion, we build a tree of modules and resolve imports. Macro expansion and name resolution communicate with each other via the `Resolver` trait, defined in `libsyntax`. From c28c5e8ef831f57feafc0fb30aa7974db300f7dd Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 25 Feb 2020 07:05:55 +0100 Subject: [PATCH 0813/1812] typo: eg. -> e.g. --- src/name-resolution.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/name-resolution.md b/src/name-resolution.md index c7bf5d111..3507d4d88 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -37,7 +37,7 @@ The name resolution lives in the `librustc_resolve` crate, with the meat in ## Namespaces -Different kind of symbols live in different namespaces ‒ eg. types don't +Different kind of symbols live in different namespaces ‒ e.g. types don't clash with variables. This usually doesn't happen, because variables start with lower-case letter while types with upper case one, but this is only a convention. This is legal Rust code that'll compile (with warnings): @@ -99,7 +99,7 @@ fn do_something(val: T) { // <- New rib in both types and values (1) Because the rules for different namespaces are a bit different, each namespace has its own independent rib stack that is constructed in parallel to the others. -In addition, there's also a rib stack for local labels (eg. names of loops or +In addition, there's also a rib stack for local labels (e.g. names of loops or blocks), which isn't a full namespace in its own right. ## Overall strategy @@ -129,7 +129,7 @@ Still, it probably provides useful first guidepost to what happens in there. following stages of compilation? * Who calls it and how it is actually used. * Is it a pass and then the result is only used, or can it be computed - incrementally (eg. for RLS)? + incrementally (e.g. for RLS)? * The overall strategy description is a bit vague. * Where does the name `Rib` come from? * Does this thing have its own tests, or is it tested only as part of some e2e From 9b3803d35d0e9ee80c0b42ee58ed472b16f06ea8 Mon Sep 17 00:00:00 2001 From: Philipp Hansch Date: Tue, 25 Feb 2020 07:48:13 +0100 Subject: [PATCH 0814/1812] Don't reference librustc_resolve just yet. It's mentioned further down with more details. --- src/name-resolution.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/name-resolution.md b/src/name-resolution.md index 3507d4d88..50820d97e 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -12,10 +12,10 @@ let x: x = 1; let y: x = 2; ``` -How do we know on line 3 whether `x` is a type (u32) or a value (1)? -These conflicts are resolved in `librustc_resolve`. -In this specific case, name resolution defines that type names and variable -names live in separate namespaces and therefore can co-exist. +How do we know on line 3 whether `x` is a type (u32) or a value (1)? These +conflicts are resolved during name resolution. In this specific case, name +resolution defines that type names and variable names live in separate +namespaces and therefore can co-exist. The name resolution in Rust is a two-phase process. In the first phase, which runs during macro expansion, we build a tree of modules and resolve imports. Macro From fa6c80ddb67b09abe476b984c3090f9831d6ad0c Mon Sep 17 00:00:00 2001 From: SarthakSingh31 <35749450+SarthakSingh31@users.noreply.github.com> Date: Wed, 26 Feb 2020 16:08:35 -0800 Subject: [PATCH 0815/1812] Fixed wrong variable name (#593) --- src/queries/query-evaluation-model-in-detail.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index a1fbed2e5..83c127550 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -115,7 +115,7 @@ The `type_check_crate` query provider would look something like the following: ```rust,ignore fn type_check_crate_provider(tcx, _key: ()) { - let list_of_items = tcx.hir_map.list_of_items(); + let list_of_hir_items = tcx.hir_map.list_of_items(); for item_def_id in list_of_hir_items { tcx.type_check_item(item_def_id); From 692f81f35d16ecd520280a19a859e111a1d63f60 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 27 Feb 2020 14:22:15 +0900 Subject: [PATCH 0816/1812] Move bless section to running chapter --- src/tests/adding.md | 19 ++----------------- src/tests/running.md | 14 ++++++++++++++ 2 files changed, 16 insertions(+), 17 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 8492cbbcc..d8cf8e884 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -150,7 +150,7 @@ source. compares against `.fixed` (they must match). Finally, the fixed source is compiled, and this compilation is required to succeed. The `.fixed` file can also be generated automatically with the - `--bless` option, discussed [below](#bless). + `--bless` option, discribed in [this section][bless]. * `min-gdb-version` specifies the minimum gdb version required for this test; see also `ignore-gdb-version` * `min-lldb-version` specifies the minimum lldb version required for @@ -185,6 +185,7 @@ source. have a gate test. [`header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs +[bless]: ./running.md#editing-and-updating-the-reference-files @@ -284,22 +285,6 @@ you can even run the resulting program. Just add one of the following - `// run-pass` – compilation should succeed and we should run the resulting binary - - -### Editing and updating the reference files - -If you have changed the compiler's output intentionally, or you are -making a new test, you can pass `--bless` to the test subcommand. E.g. -if some tests in `src/test/ui` are failing, you can run - -```text -./x.py test --stage 1 src/test/ui --bless -``` - -to automatically adjust the `.stderr`, `.stdout` or `.fixed` files of -all tests. Of course you can also target just specific tests with the -`--test-args your_test_name` flag, just like when running the tests. - ### Normalization The normalization applied is aimed at eliminating output difference diff --git a/src/tests/running.md b/src/tests/running.md index 4a86d2cce..f5d8cbdbd 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -108,6 +108,20 @@ Under the hood, the test runner invokes the standard rust test runner filtering for tests that include "issue-1234" in the name. (Thus `--test-args` is a good way to run a collection of related tests.) +## Editing and updating the reference files + +If you have changed the compiler's output intentionally, or you are +making a new test, you can pass `--bless` to the test subcommand. E.g. +if some tests in `src/test/ui` are failing, you can run + +```text +./x.py test --stage 1 src/test/ui --bless +``` + +to automatically adjust the `.stderr`, `.stdout` or `.fixed` files of +all tests. Of course you can also target just specific tests with the +`--test-args your_test_name` flag, just like when running the tests. + ## Passing `--pass $mode` Pass UI tests now have three modes, `check-pass`, `build-pass` and From d752bd35fac4681004bdfa438c3611d28e4a1d0c Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sun, 1 Mar 2020 23:19:30 +0100 Subject: [PATCH 0817/1812] Make all links in Appendix E active --- src/appendix/compiler-lecture.md | 70 +++++++++++--------------------- 1 file changed, 23 insertions(+), 47 deletions(-) diff --git a/src/appendix/compiler-lecture.md b/src/appendix/compiler-lecture.md index 3912bab76..bbeb52aa3 100644 --- a/src/appendix/compiler-lecture.md +++ b/src/appendix/compiler-lecture.md @@ -2,50 +2,26 @@ These are videos where various experts explain different parts of the compiler: -- Tom Tromey discusses debugging support in rustc - - Video: https://www.youtube.com/watch?v=elBxMRSNYr4 -- How Salsa Works (2019.01) - - Video: https://www.youtube.com/watch?v=_muY4HjSqVw -- Salsa In More Depth (2019.01) - - Video: https://www.youtube.com/watch?v=i_IhACacPRY -- RLS 2.0, Salsa, and Name Resolution - - Video: https://www.youtube.com/watch?v=Xr-rBqLr-G4 -- Cranelift - - Video: https://www.youtube.com/watch?v=9OIA7DTFQWU -- Rust analyzer guide - - Video: https://www.youtube.com/watch?v=ANKBNiSWyfc -- Rust analyzer syntax trees - - Video: https://www.youtube.com/watch?v=DGAuLWdCCAI -- rust-analyzer type-checker overview by flodiebold - - Video: https://www.youtube.com/watch?v=Lmp3P9WNL8o -- oli-obk on miri and constant evaluation - - Video: https://www.youtube.com/watch?v=5Pm2C1YXrvM -- Polonius-rustc walkthrough - - Video: https://www.youtube.com/watch?v=i5KdU0ieb_A -- rustc-chalk integration overview - - Video: https://www.youtube.com/watch?v=MBWtbDifPeU -- Coherence in Chalk by Sunjay Varma - Bay Area Rust Meetup - - assigned to @juanbono - - Video: https://www.youtube.com/watch?v=rZqS4bLPL24 -- How the chalk-engine crate works - - Video: https://www.youtube.com/watch?v=Ny2928cGDoM -- How the chalk-engine crate works 2 - - Video: https://www.youtube.com/watch?v=hmV66tB79LM -- RFC #2229 Disjoint Field Capture plan - - Video: https://www.youtube.com/watch?v=UTXOptVMuIc -- closures and upvar capture - - Video: https://www.youtube.com/watch?v=fMopdkn5-Xw -- blitzerr closure upvar tys - - Video: https://www.youtube.com/watch?v=pLmVhSB-z4s -- Convert Closure Upvar Representation to Tuples with blitzerr - - Video: https://www.youtube.com/watch?v=2QCuNtISoYc -- async-await implementation plans - - Video: https://www.youtube.com/watch?v=xe2_whJWBC0 -- async-await region inferencer - - Video: https://www.youtube.com/watch?v=hlOxfkUDLPQ -- Universes and Lifetimes - - Video: https://www.youtube.com/watch?v=iV1Z0xYXkck -- Representing types in rustc - - Video: https://www.youtube.com/watch?v=c01TsOsr3-c -- Polonius WG: Initialization and move tracking - - Video: https://www.youtube.com/watch?v=ilv9V-328HI +- [Tom Tromey discusses debugging support in rustc](https://www.youtube.com/watch?v=elBxMRSNYr4) +- [How Salsa Works (2019.01)](https://www.youtube.com/watch?v=_muY4HjSqVw) +- [Salsa In More Depth (2019.01)](https://www.youtube.com/watch?v=i_IhACacPRY) +- [RLS 2.0, Salsa, and Name Resolution](https://www.youtube.com/watch?v=Xr-rBqLr-G4) +- [Cranelift](https://www.youtube.com/watch?v=9OIA7DTFQWU) +- [Rust analyzer guide](https://www.youtube.com/watch?v=ANKBNiSWyfc) +- [Rust analyzer syntax trees](https://www.youtube.com/watch?v=DGAuLWdCCAI) +- [rust-analyzer type-checker overview by flodiebold](https://www.youtube.com/watch?v=Lmp3P9WNL8o) +- [oli-obk on miri and constant evaluation](https://www.youtube.com/watch?v=5Pm2C1YXrvM) +- [Polonius-rustc walkthrough](https://www.youtube.com/watch?v=i5KdU0ieb_A) +- [rustc-chalk integration overview](https://www.youtube.com/watch?v=MBWtbDifPeU) +- [Coherence in Chalk by Sunjay Varma - Bay Area Rust Meetup](https://www.youtube.com/watch?v=rZqS4bLPL24) +- [How the chalk-engine crate works](https://www.youtube.com/watch?v=Ny2928cGDoM) +- [How the chalk-engine crate works 2](https://www.youtube.com/watch?v=hmV66tB79LM) +- [RFC #2229 Disjoint Field Capture plan](https://www.youtube.com/watch?v=UTXOptVMuIc) +- [closures and upvar capture](https://www.youtube.com/watch?v=fMopdkn5-Xw) +- [blitzerr closure upvar tys](https://www.youtube.com/watch?v=pLmVhSB-z4s) +- [Convert Closure Upvar Representation to Tuples with blitzerr](https://www.youtube.com/watch?v=2QCuNtISoYc) +- [async-await implementation plans](https://www.youtube.com/watch?v=xe2_whJWBC0) +- [async-await region inferencer](https://www.youtube.com/watch?v=hlOxfkUDLPQ) +- [Universes and Lifetimes](https://www.youtube.com/watch?v=iV1Z0xYXkck) +- [Representing types in rustc](https://www.youtube.com/watch?v=c01TsOsr3-c) +- [Polonius WG: Initialization and move tracking](https://www.youtube.com/watch?v=ilv9V-328HI) From 37513502354ac816bd56c1891ec2d3637086e9e1 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Mon, 2 Mar 2020 20:41:41 +0100 Subject: [PATCH 0818/1812] Get rid of references to the refractored `libsyntax` crate (#598) * Get rid of references to the refractored `libsyntax` crate * Apply suggestions from code review Co-authored-by: Yuki Okushi --- src/appendix/code-index.md | 10 +++++----- src/appendix/glossary.md | 2 +- src/appendix/stupid-stats.md | 4 ++-- src/bug-fix-procedure.md | 2 +- src/diagnostics.md | 6 +++--- src/high-level-overview.md | 6 +++--- src/hir.md | 2 +- src/macro-expansion.md | 28 ++++++++++++++-------------- src/name-resolution.md | 2 +- src/test-implementation.md | 14 +++++++------- src/the-parser.md | 12 ++++++------ 11 files changed, 44 insertions(+), 44 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 1b53e6426..0321da195 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -8,16 +8,16 @@ Item | Kind | Short description | Chapter | ----------------|----------|-----------------------------|--------------------|------------------- `BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html) `Compiler` | struct | Represents a compiler session and can be used to drive a compilation. | [The Rustc Driver and Interface] | [src/librustc_interface/interface.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html) -`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Crate.html) +`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/librustc_ast/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Crate.html) `rustc_hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html) `DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html) `DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) `HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html) -`NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/libsyntax/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/node_id/struct.NodeId.html) -`P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [src/syntax/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ptr/struct.P.html) +`NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/librustc_ast/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html) +`P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [src/librustc_ast/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ptr/struct.P.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) -`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/libsyntax/parse/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html) +`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/librustc_session/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html) `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) `Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) @@ -25,7 +25,7 @@ Item | Kind | Short description | Chapter | `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/librustc_span/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/librustc_span/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html) -`syntax::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/libsyntax/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/tokenstream/struct.TokenStream.html) +`rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/librustc_ast/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index fbd76f25d..f5274a8fc 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -7,7 +7,7 @@ them better. Term | Meaning ------------------------|-------- arena/arena allocation | an _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _area allocation_. See [this chapter](../memory.md) for more info. -AST | the abstract syntax tree produced by the syntax crate; reflects user syntax very closely. +AST | the abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen | the code to translate MIR into LLVM IR. diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md index 6ed7d1cbd..ea9b6e0f0 100644 --- a/src/appendix/stupid-stats.md +++ b/src/appendix/stupid-stats.md @@ -61,7 +61,7 @@ Macros and syntax extensions are expanded, and `cfg` attributes will cause some code to disappear. The resulting AST won't have any macros or macro uses left in. -The code for these first two phases is in [libsyntax](https://github.com/rust-lang/rust/tree/master/src/libsyntax). +The code for these first two phases is in [librustc_ast](https://github.com/rust-lang/rust/tree/master/src/librustc_ast). After this phase, the compiler allocates ids to each node in the AST (technically not every node, but most of them). If we are writing out @@ -356,7 +356,7 @@ struct StupidVisitor { The `StupidVisitor` struct just keeps track of the number of `println!`s it has seen and the count for each number of arguments. It implements -`syntax::visit::Visitor` to walk the AST. Mostly we just use the default +`rustc_ast::visit::Visitor` to walk the AST. Mostly we just use the default methods, these walk the AST taking no action. We override `visit_item` and `visit_mac` to implement custom behaviour when we walk into items (items include functions, modules, traits, structs, and so forth, we're only interested in diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md index 0f6d6c973..90d8fb48b 100644 --- a/src/bug-fix-procedure.md +++ b/src/bug-fix-procedure.md @@ -65,7 +65,7 @@ described in more detail below): 1. Once the change has been in the wild for at least one cycle, we can **stabilize the change**, converting those warnings into errors. -Finally, for changes to libsyntax that will affect plugins, the general policy +Finally, for changes to `librustc_ast` that will affect plugins, the general policy is to batch these changes. That is discussed below in more detail. ### Tracking issue diff --git a/src/diagnostics.md b/src/diagnostics.md index e65893cf5..c112f3471 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -322,12 +322,12 @@ like normal but invokes the lint with `buffer_lint`. #### Linting even earlier in the compiler -The parser (`libsyntax`) is interesting in that it cannot have dependencies on +The parser (`librustc_ast`) is interesting in that it cannot have dependencies on any of the other `librustc*` crates. In particular, it cannot depend on `librustc::lint` or `librustc_lint`, where all of the compiler linting infrastructure is defined. That's troublesome! -To solve this, `libsyntax` defines its own buffered lint type, which +To solve this, `librustc_ast` defines its own buffered lint type, which `ParseSess::buffer_lint` uses. After macro expansion, these buffered lints are then dumped into the `Session::buffered_lints` used by the rest of the compiler. @@ -358,7 +358,7 @@ the structured JSON and see the "human" output (well, _sans_ colors) without having to compile everything twice. The "human" readable and the json format emitter can be found under -librustc_errors, both were moved from the libsyntax crate to the +librustc_errors, both were moved from the `librustc_ast` crate to the [librustc_errors crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html). The JSON emitter defines [its own `Diagnostic` diff --git a/src/high-level-overview.md b/src/high-level-overview.md index e4b9ff372..76f4bc955 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -7,7 +7,7 @@ there live many crates. These crates contain the sources for the standard library and the compiler. This document, of course, focuses on the latter. -Rustc consists of a number of crates, including `syntax`, +Rustc consists of a number of crates, including `rustc_ast`, `rustc`, `rustc_target`, `rustc_codegen`, `rustc_driver`, and many more. The source for each crate can be found in a directory like `src/libXXX`, where `XXX` is the crate name. @@ -33,7 +33,7 @@ rustc_codegen rustc_borrowck ... rustc_metadata rustc | v - syntax + rustc_ast / \ / \ rustc_span rustc_builtin_macros @@ -92,7 +92,7 @@ take: 1. **Parsing input** - this processes the `.rs` files and produces the AST ("abstract syntax tree") - - the AST is defined in `src/libsyntax/ast.rs`. It is intended to match the lexical + - the AST is defined in `src/librustc_ast/ast.rs`. It is intended to match the lexical syntax of the Rust language quite closely. 2. **Name resolution, macro expansion, and configuration** - once parsing is complete, we process the AST recursively, resolving diff --git a/src/hir.md b/src/hir.md index 28cc83c58..2c3e44a72 100644 --- a/src/hir.md +++ b/src/hir.md @@ -100,7 +100,7 @@ sorts of identifiers in active use: [`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html [`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html [`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html -[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/node_id/struct.NodeId.html +[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html We also have an internal map to go from `DefId` to what’s called "Def path". "Def path" is like a module path but a bit more rich. For example, it may be `crate::foo::MyStruct` that identifies diff --git a/src/macro-expansion.md b/src/macro-expansion.md index bc3b9dc5c..eb9800c65 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -1,6 +1,6 @@ # Macro expansion -> `libsyntax`, `librustc_expand`, and `librustc_builtin_macros` are all undergoing +> `librustc_ast`, `librustc_expand`, and `librustc_builtin_macros` are all undergoing > refactoring, so some of the links in this chapter may be broken. Macro expansion happens during parsing. `rustc` has two parsers, in fact: the @@ -361,24 +361,24 @@ be accessed from any Ident without any context) librustc_span/lib.rs - some secondary methods like macro backtrace using primary methods from hygiene.rs librustc_builtin_macros - implementations of built-in macros (including macro attributes and derives) and some other early code generation facilities like injection of -standard library imports or generation of test harness. libsyntax/config.rs - +standard library imports or generation of test harness. librustc_ast/config.rs - implementation of cfg/cfg_attr (they treated specially from other macros), -should probably be moved into libsyntax/ext. libsyntax/tokenstream.rs + -libsyntax/parse/token.rs - structures for compiler-side tokens, token trees, -and token streams. libsyntax/ext - various expansion-related stuff -libsyntax/ext/base.rs - basic structures used by expansion -libsyntax/ext/expand.rs - some expansion structures and the bulk of expansion +should probably be moved into librustc_ast/ext. librustc_ast/tokenstream.rs + +librustc_ast/parse/token.rs - structures for compiler-side tokens, token trees, +and token streams. librustc_ast/ext - various expansion-related stuff +librustc_ast/ext/base.rs - basic structures used by expansion +librustc_ast/ext/expand.rs - some expansion structures and the bulk of expansion infrastructure code - collecting macro invocations, calling into resolve for them, calling their expanding functions, and integrating the results back into -AST libsyntax/ext/placeholder.rs - the part of expand.rs responsible for +AST librustc_ast/ext/placeholder.rs - the part of expand.rs responsible for "integrating the results back into AST" basicallly, "placeholder" is a temporary AST node replaced with macro expansion result nodes -libsyntax/ext/builer.rs - helper functions for building AST for built-in macros +librustc_ast/ext/builer.rs - helper functions for building AST for built-in macros in librustc_builtin_macros (and user-defined syntactic plugins previously), can probably -be moved into librustc_builtin_macros these days libsyntax/ext/proc_macro.rs + -libsyntax/ext/proc_macro_server.rs - interfaces between the compiler and the +be moved into librustc_builtin_macros these days librustc_ast/ext/proc_macro.rs + +librustc_ast/ext/proc_macro_server.rs - interfaces between the compiler and the stable proc_macro library, converting tokens and token streams between the two -representations and sending them through C ABI libsyntax/ext/tt - +representations and sending them through C ABI librustc_ast/ext/tt - implementation of macro_rules, turns macro_rules DSL into something with signature Fn(TokenStream) -> TokenStream that can eat and produce tokens, @mark-i-m knows more about this librustc_resolve/macros.rs - resolving macro @@ -408,8 +408,8 @@ piece of AST, etc), this is an enum that lists them ProcMacro/TTMacroExpander/AttrProcMacro/MultiItemModifier - traits representing the expander signatures (TODO: change and rename the signatures into something more consistent) trait Resolver - a trait used to break crate dependencies (so -resolver services can be used in libsyntax, despite librustc_resolve and pretty -much everything else depending on libsyntax) ExtCtxt/ExpansionData - various +resolver services can be used in librustc_ast, despite librustc_resolve and pretty +much everything else depending on librustc_ast) ExtCtxt/ExpansionData - various intermediate data kept and used by expansion infra in the process of its work AstFragment - a piece of AST that can be produced by a macro (may include multiple homogeneous AST nodes, like e.g. a list of items) Annotatable - a diff --git a/src/name-resolution.md b/src/name-resolution.md index 50820d97e..6dfbd91a8 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -20,7 +20,7 @@ namespaces and therefore can co-exist. The name resolution in Rust is a two-phase process. In the first phase, which runs during macro expansion, we build a tree of modules and resolve imports. Macro expansion and name resolution communicate with each other via the `Resolver` -trait, defined in `libsyntax`. +trait, defined in `librustc_ast`. The input to the second phase is the syntax tree, produced by parsing input files and expanding macros. This phase produces links from all the names in the diff --git a/src/test-implementation.md b/src/test-implementation.md index 59cc7c5bd..e5bcedf13 100644 --- a/src/test-implementation.md +++ b/src/test-implementation.md @@ -31,14 +31,14 @@ How does any sort of `main` function invoke these tests if they're not visible? What exactly is `rustc --test` doing? `#[test]` is implemented as a syntactic transformation inside the compiler's -[`libsyntax` crate][libsyntax]. Essentially, it's a fancy macro, that +[`librustc_ast` crate][librustc_ast]. Essentially, it's a fancy macro, that rewrites the crate in 3 steps: #### Step 1: Re-Exporting As mentioned earlier, tests can exist inside private modules, so we need a way of exposing them to the main function, without breaking any existing -code. To that end, `libsyntax` will create local modules called +code. To that end, `librustc_ast` will create local modules called `__test_reexports` that recursively reexport tests. This expansion translates the above example into: @@ -78,7 +78,7 @@ hygiene. #### Step 2: Harness Generation Now that our tests are accessible from the root of our crate, we need to do -something with them. `libsyntax` generates a module like so: +something with them. `librustc_ast` generates a module like so: ```rust,ignore #[main] @@ -115,7 +115,7 @@ fn foo() { This means our tests are more than just simple functions, they have configuration information as well. `test` encodes this configuration data into a struct called [`TestDesc`][TestDesc]. For each test function in a -crate, `libsyntax` will parse its attributes and generate a `TestDesc` +crate, `librustc_ast` will parse its attributes and generate a `TestDesc` instance. It then combines the `TestDesc` and test function into the predictably named `TestDescAndFn` struct, that `test_main_static` operates on. For a given test, the generated `TestDescAndFn` instance looks like so: @@ -146,7 +146,7 @@ $ rustc my_mod.rs -Z unpretty=hir [test]: https://doc.rust-lang.org/test/index.html [TestDesc]: https://doc.rust-lang.org/test/struct.TestDesc.html -[Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Ident.html -[Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.Ident.html +[Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Ident.html +[Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Ident.html [eRFC]: https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md -[libsyntax]: https://github.com/rust-lang/rust/tree/master/src/libsyntax +[librustc_ast]: https://github.com/rust-lang/rust/tree/master/src/librustc_ast diff --git a/src/the-parser.md b/src/the-parser.md index 3584d73e4..8b8ef77cd 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -18,7 +18,7 @@ form which is easier for the compiler to work with, usually called an [*Abstract Syntax Tree*][ast] (AST). An AST mirrors the structure of a Rust program in memory, using a `Span` to link a particular AST node back to its source text. -The AST is defined in [`libsyntax`][libsyntax], along with some definitions for +The AST is defined in [`librustc_ast`][librustc_ast], along with some definitions for tokens and token streams, data structures/traits for mutating ASTs, and shared definitions for other AST-related parts of the compiler (like the lexer and macro-expansion). @@ -46,18 +46,18 @@ Code for lexical analysis is split between two crates: constituting tokens. Although it is popular to implement lexers as generated finite state machines, the lexer in `rustc_lexer` is hand-written. -- [`StringReader`] from [libsyntax] integrates `rustc_lexer` with `rustc` +- [`StringReader`] from [`librustc_ast`][librustc_ast] integrates `rustc_lexer` with `rustc` specific data structures. Specifically, it adds `Span` information to tokens returned by `rustc_lexer` and interns identifiers. -[libsyntax]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/index.html +[librustc_ast]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html [rustc_errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html -[ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/index.html +[ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html [librustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/index.html -[`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/parse/parser/struct.Parser.html +[`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/parse/parser/struct.Parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html -[visit module]: https://doc.rust-lang.org/nightly/nightly-rustc/syntax/visit/index.html +[visit module]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/visit/index.html [sourcefile]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html From c6211a375fa8de6d6d41a40eff5b986952e9437f Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Mon, 2 Mar 2020 22:00:05 +0100 Subject: [PATCH 0819/1812] =?UTF-8?q?Spell=20`Voil=C3=A0`=20properly=20in?= =?UTF-8?q?=20README.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c2ac04052..a0cd760a2 100644 --- a/README.md +++ b/README.md @@ -82,4 +82,4 @@ git commit -m "Update rustc-guide" 12. Wait for PR to merge -Voila! +Voilà! From cf476b2adcbe0315fb28dff1e2fbab9612b8687b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 3 Mar 2020 10:41:36 -0600 Subject: [PATCH 0820/1812] typo (#599) --- src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index d8cf8e884..dadd8e2c1 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -150,7 +150,7 @@ source. compares against `.fixed` (they must match). Finally, the fixed source is compiled, and this compilation is required to succeed. The `.fixed` file can also be generated automatically with the - `--bless` option, discribed in [this section][bless]. + `--bless` option, described in [this section][bless]. * `min-gdb-version` specifies the minimum gdb version required for this test; see also `ignore-gdb-version` * `min-lldb-version` specifies the minimum lldb version required for From b96bf135a62c975592c48ebd9f860d69a6225da1 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 8 Mar 2020 00:24:56 +0900 Subject: [PATCH 0821/1812] Remove references to chalkify tests (#604) --- src/traits/lowering-module.md | 25 ++++++++----------------- 1 file changed, 8 insertions(+), 17 deletions(-) diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md index 3f1515ef8..3c5bd7be5 100644 --- a/src/traits/lowering-module.md +++ b/src/traits/lowering-module.md @@ -9,21 +9,19 @@ created in the [`rustc_traits::lowering`][lowering] module. ## The `program_clauses_for` query The main entry point is the `program_clauses_for` [query], which – -given a def-id – produces a set of Chalk program clauses. These -queries are tested using a -[dedicated unit-testing mechanism, described below](#unit-tests). The +given a `DefId` – produces a set of Chalk program clauses. The query is invoked on a `DefId` that identifies something like a trait, an impl, or an associated item definition. It then produces and returns a vector of program clauses. [query]: ../query.html - - ## Unit tests -Unit tests are located in [`src/test/ui/chalkify`][chalkify]. A good -example test is [the `lower_impl` test][lower_impl]. At the time of +**Note: We've removed the Chalk unit tests in [rust-lang/rust#69247]. +They will come back once we're ready to integrate next Chalk into rustc.** + +Here's a good example test. At the time of this writing, it looked like this: ```rust,ignore @@ -40,14 +38,10 @@ fn main() { ``` The `#[rustc_dump_program_clauses]` annotation can be attached to -anything with a def-id. (It requires the `rustc_attrs` feature.) The +anything with a `DefId` (It requires the `rustc_attrs` feature). The compiler will then invoke the `program_clauses_for` query on that item, and emit compiler errors that dump the clauses produced. These -errors just exist for unit-testing, as we can then leverage the -standard [ui test] mechanisms to check them. In this case, there is a -`//~ ERROR program clause dump` annotation which is always the same for -`#[rustc_dump_program_clauses]`, but [the stderr file] contains -the full details: +errors just exist for unit-testing. The stderr will be: ```text error: program clause dump @@ -59,7 +53,4 @@ LL | #[rustc_dump_program_clauses] = note: forall { Implemented(T: Foo) :- ProjectionEq(::Item == i32), TypeOutlives(T: 'static), Implemented(T: std::iter::Iterator), Implemented(T: std::marker::Sized). } ``` -[chalkify]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify -[lower_impl]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify/lower_impl.rs -[the stderr file]: https://github.com/rust-lang/rust/tree/master/src/test/ui/chalkify/lower_impl.stderr -[ui test]: ../tests/adding.html#guide-to-the-ui-tests +[rust-lang/rust#69247]: https://github.com/rust-lang/rust/pull/69247 From 0e8bd00d9058c7882280ad162a6146bb2b06a99b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 7 Mar 2020 20:05:26 -0600 Subject: [PATCH 0822/1812] Just lol (#603) * Just lol * Update src/appendix/humorust.md Co-authored-by: Yuki Okushi --- src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index ef926c1c6..8bd9c48a6 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -10,3 +10,4 @@ enlightening? - [Rust Koans](https://users.rust-lang.org/t/rust-koans/2408/4) - [`break rust;`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0ab2bd6a9d722e0f05a95e2a5dcf89cc) - [The Nomicon Intro](https://doc.rust-lang.org/stable/nomicon/) +- [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20(was.3A.20design.20meeting.202.2E.2E.2E ) From 4ff25232a6f74fb70a192b5686c353861740377f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 9 Mar 2020 16:10:52 -0500 Subject: [PATCH 0823/1812] cname (#606) --- CNAME | 1 + 1 file changed, 1 insertion(+) create mode 100644 CNAME diff --git a/CNAME b/CNAME new file mode 100644 index 000000000..a59cd86cd --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +rustc-dev-guide.rust-lang.org From 56cff94ce790c13db8728efc36d75113e3a861f2 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Mon, 9 Mar 2020 23:02:24 -0400 Subject: [PATCH 0824/1812] Update ./x.py tidy testing documentation (#607) * update all docs to use ./x.py test tidy syntax --- src/conventions.md | 2 +- src/diagnostics/diagnostic-codes.md | 2 +- src/tests/intro.md | 4 ++-- src/tests/running.md | 6 +++--- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index 7f7bf32e2..303eedd4e 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -12,7 +12,7 @@ at the moment, however, it follows a rather more *chaotic* style. We do have some mandatory formatting conventions, which are automatically enforced by a script we affectionately call the "tidy" script. The tidy script runs automatically when you do `./x.py test` and can be run -in isolation with `./x.py test src/tools/tidy`. +in isolation with `./x.py test tidy`. [fmt]: https://github.com/rust-lang-nursery/fmt-rfcs diff --git a/src/diagnostics/diagnostic-codes.md b/src/diagnostics/diagnostic-codes.md index 22d9b12c3..0e923c5e1 100644 --- a/src/diagnostics/diagnostic-codes.md +++ b/src/diagnostics/diagnostic-codes.md @@ -12,7 +12,7 @@ code. This is a bit tricky since the codes are defined in various crates. To do it, run this obscure command: ``` -./x.py test --stage 0 src/tools/tidy +./x.py test --stage 0 tidy ``` This will invoke the tidy script, which generally checks that your code obeys diff --git a/src/tests/intro.md b/src/tests/intro.md index 6691f2d4e..6a528ae45 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -61,7 +61,7 @@ including: There is more information in the [section on coding conventions](../conventions.html#formatting). - Example: `./x.py test src/tools/tidy` + Example: `./x.py test tidy` - **Formatting** – Rustfmt is integrated with the build system to enforce uniform style across the compiler. In the CI, we check that the formatting @@ -73,7 +73,7 @@ including: Example: `./x.py fmt` runs rustfmt on the codebase. - Example: `./x.py test src/tools/tidy --bless` does formatting before doing + Example: `./x.py test tidy --bless` does formatting before doing other tidy checks. - **Unit tests** – The Rust standard library and many of the Rust packages diff --git a/src/tests/running.md b/src/tests/running.md index f5d8cbdbd..f5c9bdb72 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -63,7 +63,7 @@ Likewise, you can test a single file by passing its path: ### Run only the tidy script ```bash -./x.py test src/tools/tidy +./x.py test tidy ``` ### Run tests on the standard library @@ -72,10 +72,10 @@ Likewise, you can test a single file by passing its path: ./x.py test src/libstd ``` -### Run tests on the standard library and run the tidy script +### Run the tidy script and tests on the standard library ```bash -./x.py test src/libstd src/tools/tidy +./x.py test tidy src/libstd ``` ### Run tests on the standard library using a stage 1 compiler From cb00f3199da01f0b32f98f78d96e23e199ede86c Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 10 Mar 2020 22:02:55 +0900 Subject: [PATCH 0825/1812] Add travis config for custom domain (#608) --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index 2c9aa573d..e88ae40b2 100644 --- a/.travis.yml +++ b/.travis.yml @@ -25,5 +25,6 @@ deploy: skip-cleanup: true github-token: $GITHUB_TOKEN local-dir: book/html + fqdn: rustc-dev-guide.rust-lang.org on: branch: master From 66be765404efb82c6bc2735473cbd3472f777dc0 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 10 Mar 2020 11:01:43 -0300 Subject: [PATCH 0826/1812] Rename rustc-guide to rustc-dev-guide (#601) * Rename rustc-guide to rustc-dev-guide * rust-lang.github.io/rustc-dev-guide -> rustc-dev-guide.rust-lang.org --- README.md | 20 ++++++++++---------- book.toml | 2 +- src/about-this-guide.md | 2 +- src/debugging-support-in-rustc.md | 6 +++--- src/ice-breaker/llvm.md | 2 +- src/implementing_new_features.md | 4 ++-- src/macro-expansion.md | 6 +++--- src/mir/optimizations.md | 10 +++++----- src/part-1-intro.md | 2 +- src/part-2-intro.md | 2 +- src/traits/chalk-overview.md | 2 +- 11 files changed, 29 insertions(+), 29 deletions(-) diff --git a/README.md b/README.md index a0cd760a2..098971862 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -![Travis CI badge](https://api.travis-ci.com/rust-lang/rustc-guide.svg?branch=master) +![Travis CI badge](https://api.travis-ci.com/rust-lang/rustc-dev-guide.svg?branch=master) This is a collaborative effort to build a guide that explains how rustc @@ -6,7 +6,7 @@ works. The aim of the guide is to help new contributors get oriented to rustc, as well as to help more experienced folks in figuring out some new part of the compiler that they haven't worked on before. -[You can read the latest version of the guide here.](https://rust-lang.github.io/rustc-guide/) +[You can read the latest version of the guide here.](https://rustc-dev-guide.rust-lang.org/) You may also find the rustdocs [for the compiler itself][rustdocs] useful. @@ -18,7 +18,7 @@ The guide is useful today, but it has a lot of work still go. If you'd like to help improve the guide, we'd love to have you! You can find plenty of issues on the [issue -tracker](https://github.com/rust-lang/rustc-guide/issues). Just post a +tracker](https://github.com/rust-lang/rustc-dev-guide/issues). Just post a comment on the issue you would like to work on to make sure that we don't accidentally duplicate work. If you think something is missing, please open an issue about it! @@ -55,28 +55,28 @@ You will need `mdbook` version `>= 0.3.5` and `mdbook-linkcheck` version `>= 0.5 4. Follow the check-azure link to get to the Azure website for that build: https://dev.azure.com/rust-lang/e71b0ddf-dd27-435a-873c-e30f86eea377/_build/results?buildId=7780 -5. There will be approximately 1 billion different jobs for the build. They are for different configurations and platforms. The rustc-guide build only runs on the Linux x86_64-gnu-tools job. So click on that job in the list, which is about 60% down in the list. +5. There will be approximately 1 billion different jobs for the build. They are for different configurations and platforms. The rustc-dev-guide build only runs on the Linux x86_64-gnu-tools job. So click on that job in the list, which is about 60% down in the list. 6. Click the Run build step in the job to get the console log for the step. 7. Click on the log and Ctrl-f to get a search box in the log -8. Search for rustc-guide. This gets you to the place where the links are checked. It is usually ~11K lines into the log +8. Search for rustc-dev-guide. This gets you to the place where the links are checked. It is usually ~11K lines into the log 9. Look at the links in the log near that point in the log -10. Fix those links in the rustc-guide (by making a PR in the rustc-guide repo) +10. Fix those links in the rustc-dev-guide (by making a PR in the rustc-dev-guide repo) -11. Make a PR on the rust-lang/rust repo to update the rustc-guide git submodule in src/docs/rustc-guide. +11. Make a PR on the rust-lang/rust repo to update the rustc-dev-guide git submodule in src/docs/rustc-dev-guide. To make a PR, the following steps are useful. ```bash # Assuming you already cloned the rust-lang/rust repo and you're in the correct directory -git submodule update --remote src/doc/rustc-guide +git submodule update --remote src/doc/rustc-dev-guide git add -u -git commit -m "Update rustc-guide" +git commit -m "Update rustc-dev-guide" # Note that you can use -i, which is short for --incremental, in the following command -./x.py test --incremental --stage 1 src/doc/rustc-guide # This is optional and should succeed anyway +./x.py test --incremental --stage 1 src/doc/rustc-dev-guide # This is optional and should succeed anyway # Open a PR in rust-lang/rust ``` diff --git a/book.toml b/book.toml index 3a5b1fd6d..3d90479cb 100644 --- a/book.toml +++ b/book.toml @@ -7,7 +7,7 @@ description = "A guide to developing rustc" create-missing = false [output.html] -git-repository-url = "https://github.com/rust-lang/rustc-guide" +git-repository-url = "https://github.com/rust-lang/rustc-dev-guide" [output.html.fold] enable = true diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 48ea4dce6..0519099b3 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -25,7 +25,7 @@ You might also find the following sites useful: - [compiler-team] -- the home-base for the rust compiler team, with description of the team procedures, active working groups, and the team calendar. -[GitHub repository]: https://github.com/rust-lang/rustc-guide/ +[GitHub repository]: https://github.com/rust-lang/rustc-dev-guide/ [Rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ [Forge]: https://forge.rust-lang.org/ [compiler-team]: https://github.com/rust-lang/compiler-team/ diff --git a/src/debugging-support-in-rustc.md b/src/debugging-support-in-rustc.md index 3d08cc825..a11edba78 100644 --- a/src/debugging-support-in-rustc.md +++ b/src/debugging-support-in-rustc.md @@ -77,13 +77,13 @@ the trait object. **TODO**: Figure out if the following should be mentioned in the GDB-Rust document rather than this guide page so there is no duplication. This is regarding the following comments: -[This comment by Tom](https://github.com/rust-lang/rustc-guide/pull/316#discussion_r284027340) +[This comment by Tom](https://github.com/rust-lang/rustc-dev-guide/pull/316#discussion_r284027340) > gdb's Rust extensions and limitations are documented in the gdb manual: https://sourceware.org/gdb/onlinedocs/gdb/Rust.html -- however, this neglects to mention that gdb convenience variables and registers follow the gdb $ convention, and that the Rust parser implements the gdb @ extension. -[This question by Aman](https://github.com/rust-lang/rustc-guide/pull/316#discussion_r285401353) +[This question by Aman](https://github.com/rust-lang/rustc-dev-guide/pull/316#discussion_r285401353) > @tromey do you think we should mention this part in the GDB-Rust document rather than this document so there is no duplication etc.? @@ -276,7 +276,7 @@ set the breakpoints and what happens when you step it. * New demangler in LLVM or LLDB. **TODO**: Check the location of the demangler source. -[Question on Github](https://github.com/rust-lang/rustc-guide/pull/316#discussion_r283062536). +[Question on Github](https://github.com/rust-lang/rustc-dev-guide/pull/316#discussion_r283062536). #### Reuse Rust compiler for expressions diff --git a/src/ice-breaker/llvm.md b/src/ice-breaker/llvm.md index e0c90fdaf..8a8ef411b 100644 --- a/src/ice-breaker/llvm.md +++ b/src/ice-breaker/llvm.md @@ -16,7 +16,7 @@ the result of an LLVM upgrade. The goal here is: ## Helpful tips and options The ["Debugging LLVM"][d] section of the -rustc-guide gives a step-by-step process for how to help debug bugs +rustc-dev-guide gives a step-by-step process for how to help debug bugs caused by LLVM. In particular, it discusses how to emit LLVM IR, run the LLVM IR optimization pipeliness, and so forth. You may also find it useful to look at the various codegen options listed under `-Chelp` diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 27988056d..780950c71 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -106,8 +106,8 @@ for stabilization in a checklist, e.g., - [ ] Implement the RFC. (CC @rust-lang/compiler -- can anyone write up mentoring instructions?) -- [ ] Adjust the documentation. ([See instructions on rustc-guide.](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#documentation-prs)) -- [ ] Stabilize the feature. ([See instructions on rustc-guide.](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#stabilization-pr)) +- [ ] Adjust the documentation. ([See instructions on rustc-dev-guide.](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs)) +- [ ] Stabilize the feature. ([See instructions on rustc-dev-guide.](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr)) ``` diff --git a/src/macro-expansion.md b/src/macro-expansion.md index eb9800c65..db58733ad 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -227,7 +227,7 @@ just have a zulip discussion where you tell us (WG-learning) everything you know about macros/expansion/hygiene. We were thinking this could be less formal (and less work for you) than compiler lecture series lecture... thoughts? -mark-i-m: The goal is to fill out that long-standing gap in the rustc-guide +mark-i-m: The goal is to fill out that long-standing gap in the rustc-dev-guide Vadim Petrochenkov: Ok, I'm at UTC+03:00 and generally available in the evenings (or weekends). @@ -628,7 +628,7 @@ Vadim Petrochenkov: A thread for offline questions-answers would be good too. A thread for offline questions-answers would be good too. I don't mind using this thread, since it already has a lot of info in it. We -also plan to summarize the info from this thread into the rustc-guide. +also plan to summarize the info from this thread into the rustc-dev-guide. Sure, why not. @@ -648,7 +648,7 @@ eager expansion... Santiago Pastorino: sorry but I couldn't follow that much today, will read it when I have some time later -Santiago Pastorino: btw https://github.com/rust-lang/rustc-guide/issues/398 +Santiago Pastorino: btw https://github.com/rust-lang/rustc-dev-guide/issues/398 mark-i-m: @Vadim Petrochenkov Would 7pm UTC on August 21 work for a followup? diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index f3fdd52f3..03dc21953 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -8,8 +8,8 @@ to do, so compilation is faster. Note that since MIR is generic (not effective; we can optimize the generic version, so all of the monomorphizations are cheaper! -[mir]: https://rust-lang.github.io/rustc-guide/mir/index.html -[monomorph]: https://rust-lang.github.io/rustc-guide/appendix/glossary.html?highlight=monomorphize#appendix-c-glossary +[mir]: https://rustc-dev-guide.rust-lang.org/mir/index.html +[monomorph]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html?highlight=monomorphize#appendix-c-glossary MIR optimizations run after borrow checking. We run a series of optimization passes over the MIR to improve it. Some passes are required to run on all code, @@ -22,9 +22,9 @@ run and that some validation has occurred. Then, it [steals][steal] the MIR optimizes it, and returns the improved MIR. [optmir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html -[query]: https://rust-lang.github.io/rustc-guide/query.html -[defid]: https://rust-lang.github.io/rustc-guide/appendix/glossary.html?highlight=DefId#appendix-c-glossary -[steal]: https://rust-lang.github.io/rustc-guide/mir/passes.html?highlight=steal#stealing +[query]: https://rustc-dev-guide.rust-lang.org/query.html +[defid]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html?highlight=DefId#appendix-c-glossary +[steal]: https://rustc-dev-guide.rust-lang.org/mir/passes.html?highlight=steal#stealing ## Defining optimization passes diff --git a/src/part-1-intro.md b/src/part-1-intro.md index 65cb1ae48..7597c7128 100644 --- a/src/part-1-intro.md +++ b/src/part-1-intro.md @@ -1,6 +1,6 @@ # Part 1: Building, debugging, and contributing to Rustc -This section of the rustc-guide contains knowledge that should be useful to you +This section of the rustc-dev-guide contains knowledge that should be useful to you regardless of what part of the compiler you are working on. This includes both technical info and tips (e.g. how to compile and debug the compiler) and info about processes in the Rust project (e.g. stabilization and info about the diff --git a/src/part-2-intro.md b/src/part-2-intro.md index 6dd26f44c..1a47f21e5 100644 --- a/src/part-2-intro.md +++ b/src/part-2-intro.md @@ -7,6 +7,6 @@ compilation works. This section should be friendly to both readers interested in the end-to-end process of compilation _and_ readers interested in learning about a specific system they wish to contribute to. If anything is unclear, feel free to file -an issue on the [rustc-guide repo](https://github.com/rust-lang/rustc-guide) +an issue on the [rustc-dev-guide repo](https://github.com/rust-lang/rustc-dev-guide) or contact the compiler team, as detailed in [this chapter from Part 1](./compiler-team.md). diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index a33cbcc63..88ae7b5a2 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -226,7 +226,7 @@ Likewise, lowering tests use the [`lowering_success!` and [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [chalk]: https://github.com/rust-lang/chalk -[rustc-issues]: https://github.com/rust-lang/rustc-guide/issues +[rustc-issues]: https://github.com/rust-lang/rustc-dev-guide/issues [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification [`ProgramClause`]: https://rust-lang.github.io/chalk/chalk_ir/enum.ProgramClause.html From f4f5d4c151b2e668218f1879e32600d5e8fab075 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 7 Mar 2020 14:58:39 -0600 Subject: [PATCH 0827/1812] skeleton for backend chapters --- src/SUMMARY.md | 17 ++++++++++------- src/{codegen => backend}/backend-agnostic.md | 0 src/backend/backend.md | 1 + src/{ => backend}/codegen.md | 2 +- src/{codegen => backend}/debugging.md | 2 +- src/backend/lowering-mir.md | 0 src/backend/monomorph.md | 1 + src/{codegen => backend}/updating-llvm.md | 0 src/compiler-debugging.md | 5 ++--- src/ice-breaker/llvm.md | 2 +- 10 files changed, 17 insertions(+), 13 deletions(-) rename src/{codegen => backend}/backend-agnostic.md (100%) create mode 100644 src/backend/backend.md rename src/{ => backend}/codegen.md (98%) rename src/{codegen => backend}/debugging.md (99%) create mode 100644 src/backend/lowering-mir.md create mode 100644 src/backend/monomorph.md rename src/{codegen => backend}/updating-llvm.md (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ae1ea0b2e..7cc41e0b6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -101,13 +101,16 @@ - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) - [Parameter Environments](./param_env.md) - - [Code Generation](./codegen.md) - - [Updating LLVM](./codegen/updating-llvm.md) - - [Debugging LLVM](./codegen/debugging.md) - - [Backend Agnostic Codegen](./codegen/backend-agnostic.md) - - [Profile-guided Optimization](./profile-guided-optimization.md) - - [Sanitizers Support](./sanitizers.md) - - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) + - [Compiler Backend](./backend/backend.md) + - [Monomorphization](./backend/monomorph.md) + - [Lowering MIR](./backend/lowering-mir.md) + - [Code Generation](./backend/codegen.md) + - [Updating LLVM](./backend/updating-llvm.md) + - [Debugging LLVM](./backend/debugging.md) + - [Backend Agnostic Codegen](./backend/backend-agnostic.md) + - [Profile-guided Optimization](./profile-guided-optimization.md) + - [Sanitizers Support](./sanitizers.md) + - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) --- diff --git a/src/codegen/backend-agnostic.md b/src/backend/backend-agnostic.md similarity index 100% rename from src/codegen/backend-agnostic.md rename to src/backend/backend-agnostic.md diff --git a/src/backend/backend.md b/src/backend/backend.md new file mode 100644 index 000000000..167391a88 --- /dev/null +++ b/src/backend/backend.md @@ -0,0 +1 @@ +# The Compiler Backend diff --git a/src/codegen.md b/src/backend/codegen.md similarity index 98% rename from src/codegen.md rename to src/backend/codegen.md index c7d2fc071..02bb4d573 100644 --- a/src/codegen.md +++ b/src/backend/codegen.md @@ -6,7 +6,7 @@ generates an executable binary. rustc uses LLVM for code generation. > NOTE: If you are looking for hints on how to debug code generation bugs, > please see [this section of the debugging chapter][debugging]. -[debugging]: codegen/debugging.html +[debugging]: ./debugging.md ## What is LLVM? diff --git a/src/codegen/debugging.md b/src/backend/debugging.md similarity index 99% rename from src/codegen/debugging.md rename to src/backend/debugging.md index 0da29bfb9..06e62d9ec 100644 --- a/src/codegen/debugging.md +++ b/src/backend/debugging.md @@ -3,7 +3,7 @@ > NOTE: If you are looking for info about code generation, please see [this > chapter][codegen] instead. -[codegen]: ../codegen.md +[codegen]: ./codegen.md This section is about debugging compiler bugs in code generation (e.g. why the compiler generated some piece of code or crashed in LLVM). LLVM is a big diff --git a/src/backend/lowering-mir.md b/src/backend/lowering-mir.md new file mode 100644 index 000000000..e69de29bb diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md new file mode 100644 index 000000000..fc54886f9 --- /dev/null +++ b/src/backend/monomorph.md @@ -0,0 +1 @@ +# Monomorphization diff --git a/src/codegen/updating-llvm.md b/src/backend/updating-llvm.md similarity index 100% rename from src/codegen/updating-llvm.md rename to src/backend/updating-llvm.md diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 736de9771..08e9417b3 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -4,9 +4,8 @@ This chapter contains a few tips to debug the compiler. These tips aim to be useful no matter what you are working on. Some of the other chapters have advice about specific parts of the compiler (e.g. the [Queries Debugging and -Testing -chapter](./incrcomp-debugging.html) or -the [LLVM Debugging chapter](./codegen/debugging.md)). +Testing chapter](./incrcomp-debugging.html) or the [LLVM Debugging +chapter](./backend/debugging.md)). ## `-Z` flags diff --git a/src/ice-breaker/llvm.md b/src/ice-breaker/llvm.md index 8a8ef411b..a6291a8c2 100644 --- a/src/ice-breaker/llvm.md +++ b/src/ice-breaker/llvm.md @@ -23,7 +23,7 @@ it useful to look at the various codegen options listed under `-Chelp` and the internal options under `-Zhelp` -- there are a number that pertain to LLVM (just search for LLVM). -[d]: ../codegen/debugging.md +[d]: ../backend/debugging.md ## If you do narrow to an LLVM bug From 469c5af2557e8611b5abae9d6fb351f358d413a7 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 7 Mar 2020 15:10:13 -0600 Subject: [PATCH 0828/1812] add some placeholder text, short intro --- src/backend/backend.md | 16 ++++++++++++++++ src/backend/lowering-mir.md | 3 +++ src/backend/monomorph.md | 7 +++++++ 3 files changed, 26 insertions(+) diff --git a/src/backend/backend.md b/src/backend/backend.md index 167391a88..cc477b3e2 100644 --- a/src/backend/backend.md +++ b/src/backend/backend.md @@ -1 +1,17 @@ # The Compiler Backend + +The _compiler backend_ refers to the parts of the compiler that turn rustc's +MIR into actual executable code (e.g. an ELF or EXE binary) that can run on a +processor. This is the last stage of compilation, and it has a few important +parts: + +0. First, we need to collect the set of things to generate code for. In + particular, we need to find out which concrete types to substitute for + generic ones, since we need to generate code for the concrete types. + Generating code for the concrete types (i.e. emitting a copy of the code for + each concrete type) is called _monomorphization_, so the process of + collecting all the concrete types is called _monomorphization collection_. +1. Next, we need to actually lower the MIR (which is generic) to a codegen IR + (usually LLVM IR; which is not generic) for each concrete type we collected. +2. Finally, we need to invoke LLVM, which runs a bunch of optimization passes, + generates executable code, and links together an executable binary. diff --git a/src/backend/lowering-mir.md b/src/backend/lowering-mir.md index e69de29bb..e3c137956 100644 --- a/src/backend/lowering-mir.md +++ b/src/backend/lowering-mir.md @@ -0,0 +1,3 @@ +# Lowering MIR to a Codegen IR + +TODO diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index fc54886f9..eaf37f2e1 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -1 +1,8 @@ # Monomorphization + +TODO + + +## Polymorphization + +TODO From 1f4d07155eeeab447c68d06b6ec4ac611c1997d1 Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 7 Mar 2020 15:47:35 -0600 Subject: [PATCH 0829/1812] monomorphization chapter --- src/appendix/glossary.md | 3 +- src/backend/monomorph.md | 80 +++++++++++++++++++++++++++++++++++++++- 2 files changed, 80 insertions(+), 3 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index f5274a8fc..715928d21 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -52,7 +52,9 @@ newtype | a "newtype" is a wrapper around some other type (e.g. NLL | [non-lexical lifetimes](../borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. obligation | something that must be proven by the trait system ([see more](../traits/resolution.html)) +placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. point | used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. +polymorphize | An optimization that avoids unnecessary monomorphisation ([see more](../backend/monomorph.md#polymorphization)) projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref) promoted constants | constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. provider | the function that executes a query ([see more](../query.html)) @@ -63,7 +65,6 @@ rib | a data structure in the name resolver that keeps trac sess | the compiler session, which stores global data used throughout compilation side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index eaf37f2e1..e28eac8f7 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -1,8 +1,84 @@ # Monomorphization -TODO +As you probably know, rust has a very expressive type system that has extensive +support for generic types. But of course, assembly is not generic, so we need +to figure out the concrete types of all the generics before the code can +execute. +Different languages handle this problem differently. For example, in some +languages, such as Java, we may not know the most precise type of value until +runtime. In the case of Java, this is ok because (almost) all variables are +reference values anyway (i.e. pointers to a stack allocated object). This +flexibility comes at the cost of performance, since all accesses to an object +must dereference a pointer. + +Rust takes a different approach: it _monomorphizes_ all generic types. This +means that compiler stamps out a different copy of the code of a generic +function for each concrete type needed. For example, if I use a `Vec` and +a `Vec` in my code, then the generated binary will have two copies of +the generated code for `Vec`: one for `Vec` and another for `Vec`. +The result is fast programs, but it comes at the cost of compile time (creating +all those copies can take a while) and binary size (all those copies might take +a lot of space). + +Monomorphization is the first step in the backend of the rust compiler. + +## Collection + +First, we need to figure out what concrete types we need for all the generic +things in our program. This is called _collection_, and the code that does this +is called the _monomorphization collector_. + +Take this example: + +```rust +fn banana() { + peach::(); +} + +fn main() { + banana(); +} +``` + +The monomorphisation collector will give you a list of `[main, banana, +peach::]`. These are the functions that will have machine code generated +for them. Collector will also add things like statics to that list. + +See [the collector rustdocs][collect] for more info. + +[collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/collector/index.html ## Polymorphization -TODO +As mentioned above, monomorphisation produces fast code, but it comes at the +cost of compile time and binary size. [MIR +optimizations](../mir/optimizations.md) can help a bit with this. Another +optimization currently under development is called _polymorphization_. + +The general idea is that often we can share some code between monomorphized +copies of code. More precisely, if a MIR block is not dependent on a type +parameter, it may not need to be monomorphized into many copies. Consider the +following example: + +```rust +pub fn f() { + g::(); + g::(); +} + +fn g() -> usize { + let n = 1; + let closure = || n; + closure() +} +``` + +In this case, we would currently collect `[f, g::, g::, +g::::{{closure}}, g::::{{closure}}]`, but notice that the two +closures would be identical -- they don't depend on the type parameter `T` of +function `g`. So we only need to emit one copy of the closure. + +For more information, see [this thread on github][polymorph]. + +[polymorph]: https://github.com/rust-lang/rust/issues/46477 From 83f0ba422a72ef685574030d530df70ecc8a7d1a Mon Sep 17 00:00:00 2001 From: Mark Mansi Date: Sat, 7 Mar 2020 17:26:30 -0600 Subject: [PATCH 0830/1812] update backend chapters from nagisa's notes --- src/appendix/glossary.md | 2 +- src/backend/backend.md | 49 ++++++++++++++++++++++----- src/backend/codegen.md | 66 ++++++++++++++++++++++++------------- src/backend/lowering-mir.md | 57 +++++++++++++++++++++++++++++++- src/backend/monomorph.md | 9 +++++ 5 files changed, 151 insertions(+), 32 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 715928d21..0218d1a85 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -11,7 +11,7 @@ AST | the abstract syntax tree produced by the `rustc_ast` binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen | the code to translate MIR into LLVM IR. -codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. +codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) CTFE | Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) diff --git a/src/backend/backend.md b/src/backend/backend.md index cc477b3e2..9832abb1d 100644 --- a/src/backend/backend.md +++ b/src/backend/backend.md @@ -1,9 +1,19 @@ # The Compiler Backend -The _compiler backend_ refers to the parts of the compiler that turn rustc's -MIR into actual executable code (e.g. an ELF or EXE binary) that can run on a -processor. This is the last stage of compilation, and it has a few important -parts: +All of the preceding chapters of this guide have one thing in common: we never +generated any executable machine code at all! With this chapter, all of that +changes. + +It's often useful to think of compilers as being composed of a _frontend_ and a +_backend_ (though in rustc, there's not a sharp line between frontend and +backend). The _frontend_ is responsible for taking raw source code, checking it +for correctness, and getting it into a format usable by the backend. For rustc, +this format is the MIR. The _backend_ refers to the parts of the compiler that +turn rustc's MIR into actual executable code (e.g. an ELF or EXE binary) that +can run on a processor. All of the previous chapters deal with rustc's +frontend. + +rustc's backend does the following: 0. First, we need to collect the set of things to generate code for. In particular, we need to find out which concrete types to substitute for @@ -11,7 +21,30 @@ parts: Generating code for the concrete types (i.e. emitting a copy of the code for each concrete type) is called _monomorphization_, so the process of collecting all the concrete types is called _monomorphization collection_. -1. Next, we need to actually lower the MIR (which is generic) to a codegen IR - (usually LLVM IR; which is not generic) for each concrete type we collected. -2. Finally, we need to invoke LLVM, which runs a bunch of optimization passes, - generates executable code, and links together an executable binary. +1. Next, we need to actually lower the MIR to a codegen IR + (usually LLVM IR) for each concrete type we collected. +2. Finally, we need to invoke the codegen backend (e.g. LLVM or Cranelift), + which runs a bunch of optimization passes, generates executable code, and + links together an executable binary. + +[codegen1]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html + +The code for codegen is actually a bit complex due to a few factors: + +- Support for multiple backends (LLVM and Cranelift). We try to share as much + backend code between them as possible, so a lot of it is generic over the + codegen implementation. This means that there are often a lot of layers of + abstraction. +- Codegen happens asynchronously in another thread for performance. +- The actual codegen is done by a third-party library (either LLVM or Cranelift). + +Generally, the [`rustc_codegen_ssa`][ssa] crate contains backend-agnastic code +(i.e. independent of LLVM or Cranelift), while the [`rustc_codegen_llvm`][llvm] +crate contains code specific to LLVM codegen. + +[ssa]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/index.html +[llvm]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/index.html + +At a very high level, the entry point is +[`rustc_codegen_ssa::base::codegen_crate`][codegen1]. This function starts the +process discussed in the rest of this chapter. diff --git a/src/backend/codegen.md b/src/backend/codegen.md index 02bb4d573..8b005525d 100644 --- a/src/backend/codegen.md +++ b/src/backend/codegen.md @@ -1,7 +1,13 @@ # Code generation Code generation or "codegen" is the part of the compiler that actually -generates an executable binary. rustc uses LLVM for code generation. +generates an executable binary. Usually, rustc uses LLVM for code generation; +there is also support for [Cranelift]. The key is that rustc doesn't implement +codegen itself. It's worth noting, though, that in the rust source code, many +parts of the backend have `codegen` in their names (there are no hard +boundaries). + +[Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/master/cranelift > NOTE: If you are looking for hints on how to debug code generation bugs, > please see [this section of the debugging chapter][debugging]. @@ -10,28 +16,16 @@ generates an executable binary. rustc uses LLVM for code generation. ## What is LLVM? -All of the preceding chapters of this guide have one thing in common: we never -generated any executable machine code at all! With this chapter, all of that -changes. - -Like most compilers, rustc is composed of a "frontend" and a "backend". The -"frontend" is responsible for taking raw source code, checking it for -correctness, and getting it into a format `X` from which we can generate -executable machine code. The "backend" then takes that format `X` and produces -(possibly optimized) executable machine code for some platform. All of the -previous chapters deal with rustc's frontend. +[LLVM](https://llvm.org) is "a collection of modular and reusable compiler and +toolchain technologies". In particular, the LLVM project contains a pluggable +compiler backend (also called "LLVM"), which is used by many compiler projects, +including the `clang` C compiler and our beloved `rustc`. -rustc's backend is [LLVM](https://llvm.org), "a collection of modular and -reusable compiler and toolchain technologies". In particular, the LLVM project -contains a pluggable compiler backend (also called "LLVM"), which is used by -many compiler projects, including the `clang` C compiler and our beloved -`rustc`. - -LLVM's "format `X`" is called LLVM IR. It is basically assembly code with +LLVM takes input in the form of LLVM IR. It is basically assembly code with additional low-level types and annotations added. These annotations are helpful for doing optimizations on the LLVM IR and outputted machine code. The end -result of all this is (at long last) something executable (e.g. an ELF object -or wasm). +result of all this is (at long last) something executable (e.g. an ELF object, +an EXE, or wasm). There are a few benefits to using LLVM: @@ -49,6 +43,34 @@ There are a few benefits to using LLVM: [spectre]: https://meltdownattack.com/ -## Generating LLVM IR +## Running LLVM, linking, and metadata generation + +Once LLVM IR for all of the functions and statics, etc is built, it is time to +start running LLVM and its optimisation passes. LLVM IR is grouped into +"modules". Multiple "modules" can be codegened at the same time to aid in +multi-core utilisation. These "modules" are what we refer to as _codegen +units_. These units were established way back during monomorphisation +collection phase. + +Once LLVM produces objects from these modules, these objects are passed to the +linker along with, optionally, the metadata object and an archive or an +executable is produced. + +It is not necessarily the codegen phase described above that runs the +optimisations. With certain kinds of LTO, the optimisation might happen at the +linking time instead. It is also possible for some optimisations to happen +before objects are passed on to the linker and some to happen during the +linking. + +This all happens towards the very end of compilation. The code for this can be +found in [`librustc_codegen_ssa::back`][ssaback] and +[`librustc_codegen_llvm::back`][llvmback]. Sadly, this piece of code is not +really well-separated into LLVM-dependent code; the [`rustc_codegen_ssa`][ssa] +contains a fair amount of code specific to the LLVM backend. + +Once these components are done with their work you end up with a number of +files in your filesystem corresponding to the outputs you have requested. -TODO +[ssa]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/index.html +[ssaback]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/back/index.html +[llvmback]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/back/index.html diff --git a/src/backend/lowering-mir.md b/src/backend/lowering-mir.md index e3c137956..42536b955 100644 --- a/src/backend/lowering-mir.md +++ b/src/backend/lowering-mir.md @@ -1,3 +1,58 @@ # Lowering MIR to a Codegen IR -TODO +Now that we have a list of symbols to generate from the collector, we need to +generate some sort of codegen IR. In this chapter, we will assume LLVM IR, +since that's what rustc usually uses. The actual monomorphisation is performed +as we go, while we do the translation. + +Recall that the backend is started by +[`rustc_codegen_ssa::base::codegen_crate`][codegen1]. Eventually, this reaches +[`rustc_codegen_ssa::mir::codegen_mir`][codegen2], which does the lowering from +MIR to LLVM IR. + +[codegen1]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html +[codegen2]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/fn.codegen_mir.html + +The code is split into modules which handle particular MIR primitives: + +- [`librustc_codegen_ssa::mir::block`][mirblk] will deal with translating + blocks and their terminators. The most complicated and also the most + interesting thing this module does is generating code for function calls, + including the necessary unwinding handling IR. +- [`librustc_codegen_ssa::mir::statement`][mirst] translates MIR statements. +- [`librustc_codegen_ssa::mir::operand`][mirop] translates MIR operands. +- [`librustc_codegen_ssa::mir::place`][mirpl] translates MIR place references. +- [`librustc_codegen_ssa::mir::rvalue`][mirrv] translates MIR r-values. + +[mirblk]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/block/index.html +[mirst]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/statement/index.html +[mirop]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/operand/index.html +[mirpl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/index.html +[mirrv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/rvalue/index.html + +Before a function is translated a number of simple and primitive analysis +passes will run to help us generate simpler and more efficient LLVM IR. An +example of such an analysis pass would be figuring out which variables are +SSA-like, so that we can translate them to SSA directly rather than relying on +LLVM's `mem2reg` for those variables. The anayses can be found in +[`rustc_codegen_ssa::mir::analyze`][mirana]. + +[mirana]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/analyze/index.html + +Usually a single MIR basic block will map to a LLVM basic block, with very few +exceptions: intrinsic or function calls and less basic MIR statemenets like +`assert` can result in multiple basic blocks. This is a perfect lede into the +non-portable LLVM-specific part of the code generation. Intrinsic generation is +fairly easy to understand as it involves very few abstraction levels in between +and can be found in [`rustc_codegen_llvm::intrinsic`][llvmint]. + +[llvmint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/intrinsic/index.html + +Everything else will use the [builder interface][builder], this is the code that gets +called in [`librustc_codegen_ssa::mir::*`][ssamir] modules that was discussed +above. + +[builder]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/builder/index.html +[ssamir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/index.html + +> TODO: discuss how constants are generated diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index e28eac8f7..0d2de4d2d 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -49,6 +49,15 @@ See [the collector rustdocs][collect] for more info. [collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/collector/index.html +The monomorphisation collector is run just before MIR lowering and codegen. +[`rustc_codegen_ssa::base::codegen_crate`][codegen1] calls the +[`collect_and_partition_mono_items`][mono] query, which does monomorphisation +collection and then partitions them into [codegen +units](../appendix/glossary.md). + +[mono]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/partitioning/fn.collect_and_partition_mono_items.html +[codegen1]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html + ## Polymorphization As mentioned above, monomorphisation produces fast code, but it comes at the From 75f60ec24ef578f0fb9e2790a0dfe22dd0822f28 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 8 Mar 2020 21:19:44 -0500 Subject: [PATCH 0831/1812] Update src/backend/codegen.md Co-Authored-By: Yuki Okushi --- src/backend/codegen.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/codegen.md b/src/backend/codegen.md index 8b005525d..5e277fc3c 100644 --- a/src/backend/codegen.md +++ b/src/backend/codegen.md @@ -46,7 +46,7 @@ There are a few benefits to using LLVM: ## Running LLVM, linking, and metadata generation Once LLVM IR for all of the functions and statics, etc is built, it is time to -start running LLVM and its optimisation passes. LLVM IR is grouped into +start running LLVM and its optimization passes. LLVM IR is grouped into "modules". Multiple "modules" can be codegened at the same time to aid in multi-core utilisation. These "modules" are what we refer to as _codegen units_. These units were established way back during monomorphisation From 12900c8c466d40eb2bf7e81e808cfd4bc2d9b36c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 8 Mar 2020 21:21:33 -0500 Subject: [PATCH 0832/1812] Use common (American) spellings Co-Authored-By: Yuki Okushi --- src/backend/codegen.md | 8 ++++---- src/backend/lowering-mir.md | 6 +++--- src/backend/monomorph.md | 8 ++++---- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/backend/codegen.md b/src/backend/codegen.md index 5e277fc3c..d7bad9cfb 100644 --- a/src/backend/codegen.md +++ b/src/backend/codegen.md @@ -48,8 +48,8 @@ There are a few benefits to using LLVM: Once LLVM IR for all of the functions and statics, etc is built, it is time to start running LLVM and its optimization passes. LLVM IR is grouped into "modules". Multiple "modules" can be codegened at the same time to aid in -multi-core utilisation. These "modules" are what we refer to as _codegen -units_. These units were established way back during monomorphisation +multi-core utilization. These "modules" are what we refer to as _codegen +units_. These units were established way back during monomorphization collection phase. Once LLVM produces objects from these modules, these objects are passed to the @@ -57,8 +57,8 @@ linker along with, optionally, the metadata object and an archive or an executable is produced. It is not necessarily the codegen phase described above that runs the -optimisations. With certain kinds of LTO, the optimisation might happen at the -linking time instead. It is also possible for some optimisations to happen +optimizations. With certain kinds of LTO, the optimization might happen at the +linking time instead. It is also possible for some optimizations to happen before objects are passed on to the linker and some to happen during the linking. diff --git a/src/backend/lowering-mir.md b/src/backend/lowering-mir.md index 42536b955..ccc09bee6 100644 --- a/src/backend/lowering-mir.md +++ b/src/backend/lowering-mir.md @@ -2,7 +2,7 @@ Now that we have a list of symbols to generate from the collector, we need to generate some sort of codegen IR. In this chapter, we will assume LLVM IR, -since that's what rustc usually uses. The actual monomorphisation is performed +since that's what rustc usually uses. The actual monomorphization is performed as we go, while we do the translation. Recall that the backend is started by @@ -34,13 +34,13 @@ Before a function is translated a number of simple and primitive analysis passes will run to help us generate simpler and more efficient LLVM IR. An example of such an analysis pass would be figuring out which variables are SSA-like, so that we can translate them to SSA directly rather than relying on -LLVM's `mem2reg` for those variables. The anayses can be found in +LLVM's `mem2reg` for those variables. The analysis can be found in [`rustc_codegen_ssa::mir::analyze`][mirana]. [mirana]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/analyze/index.html Usually a single MIR basic block will map to a LLVM basic block, with very few -exceptions: intrinsic or function calls and less basic MIR statemenets like +exceptions: intrinsic or function calls and less basic MIR statements like `assert` can result in multiple basic blocks. This is a perfect lede into the non-portable LLVM-specific part of the code generation. Intrinsic generation is fairly easy to understand as it involves very few abstraction levels in between diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index 0d2de4d2d..5ea8ba4f0 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -41,7 +41,7 @@ fn main() { } ``` -The monomorphisation collector will give you a list of `[main, banana, +The monomorphization collector will give you a list of `[main, banana, peach::]`. These are the functions that will have machine code generated for them. Collector will also add things like statics to that list. @@ -49,9 +49,9 @@ See [the collector rustdocs][collect] for more info. [collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/collector/index.html -The monomorphisation collector is run just before MIR lowering and codegen. +The monomorphization collector is run just before MIR lowering and codegen. [`rustc_codegen_ssa::base::codegen_crate`][codegen1] calls the -[`collect_and_partition_mono_items`][mono] query, which does monomorphisation +[`collect_and_partition_mono_items`][mono] query, which does monomorphization collection and then partitions them into [codegen units](../appendix/glossary.md). @@ -60,7 +60,7 @@ units](../appendix/glossary.md). ## Polymorphization -As mentioned above, monomorphisation produces fast code, but it comes at the +As mentioned above, monomorphization produces fast code, but it comes at the cost of compile time and binary size. [MIR optimizations](../mir/optimizations.md) can help a bit with this. Another optimization currently under development is called _polymorphization_. From cf572f5e35645cfc2026b80af1ca261d6d339d90 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 8 Mar 2020 21:24:38 -0500 Subject: [PATCH 0833/1812] Fix sentence grammar --- src/backend/lowering-mir.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/backend/lowering-mir.md b/src/backend/lowering-mir.md index ccc09bee6..93516c5d8 100644 --- a/src/backend/lowering-mir.md +++ b/src/backend/lowering-mir.md @@ -48,9 +48,8 @@ and can be found in [`rustc_codegen_llvm::intrinsic`][llvmint]. [llvmint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/intrinsic/index.html -Everything else will use the [builder interface][builder], this is the code that gets -called in [`librustc_codegen_ssa::mir::*`][ssamir] modules that was discussed -above. +Everything else will use the [builder interface][builder]. This is the code that gets +called in the [`librustc_codegen_ssa::mir::*`][ssamir] modules discussed above. [builder]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/builder/index.html [ssamir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/index.html From 1f80effa08fc5245735eca93a4411b3726a29d5e Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 16 Mar 2020 02:37:54 +0900 Subject: [PATCH 0834/1812] Fix broken link --- src/appendix/bibliography.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index dc06b63f5..613ee1f4d 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -25,7 +25,7 @@ Rust, as well as publications about Rust. * [The data locality of work stealing](http://www.aladdin.cs.cmu.edu/papers/pdfs/y2000/locality_spaa00.pdf) * [Dynamic circular work stealing deque](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.1097&rep=rep1&type=pdf) - The Chase/Lev deque * [Work-first and help-first scheduling policies for async-finish task parallelism](http://www.cs.rice.edu/%7Eyguo/pubs/PID824943.pdf) - More general than fully-strict work stealing -* [A Java fork/join calamity](http://www.coopsoft.com/ar/CalamityArticle.html) - critique of Java's fork/join library, particularly its application of work stealing to non-strict computation +* [A Java fork/join calamity](https://web.archive.org/web/20190904045322/http://www.coopsoft.com/ar/CalamityArticle.html) - critique of Java's fork/join library, particularly its application of work stealing to non-strict computation * [Scheduling techniques for concurrent systems](http://www.stanford.edu/~ouster/cgi-bin/papers/coscheduling.pdf) * [Contention aware scheduling](http://www.blagodurov.net/files/a8-blagodurov.pdf) * [Balanced work stealing for time-sharing multicores](https://web.njit.edu/~dingxn/papers/BWS.pdf) From 601fee4da8db7e77408c1b01a352ecc539d6723e Mon Sep 17 00:00:00 2001 From: Youngsuk Kim Date: Tue, 18 Feb 2020 23:42:08 -0500 Subject: [PATCH 0835/1812] Clarify sentence meaning --- src/mir/optimizations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index 03dc21953..2af3d06ce 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -18,7 +18,7 @@ passes are only turned on in `release` mode. The [`optimized_mir`][optmir] [query] is called to produce the optimized MIR for a given [`DefId`][defid]. This query makes sure that the borrow checker has -run and that some validation has occurred. Then, it [steals][steal] the MIR +run and that some validation has occurred. Then, it [steals][steal] the MIR, optimizes it, and returns the improved MIR. [optmir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html From 14a92d3762ff3ebbed02e0ab9fcfcfca61bb6349 Mon Sep 17 00:00:00 2001 From: DillionMango Date: Mon, 16 Mar 2020 16:43:48 +0800 Subject: [PATCH 0836/1812] quote some commands by to make the style more consistent (#611) --- src/building/how-to-build-and-run.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 69c418c28..dbe1f4c7a 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -148,13 +148,13 @@ probably the best "go to" command for building a local rust: ./x.py build -i --stage 1 src/libstd ``` -This may *look* like it only builds libstd, but that is not the case. +This may *look* like it only builds `libstd`, but that is not the case. What this command does is the following: - Build `libstd` using the stage0 compiler (using incremental) - Build `librustc` using the stage0 compiler (using incremental) - This produces the stage1 compiler -- Build libstd using the stage1 compiler (cannot use incremental) +- Build `libstd` using the stage1 compiler (cannot use incremental) This final product (stage1 compiler + libs built using that compiler) is what you need to build other rust programs (unless you use `#![no_std]` or @@ -180,8 +180,8 @@ build`) has quite a few more steps: - Build `librustc` and `rustc` with the stage1 compiler. - The resulting compiler here is called the "stage2" compiler. -- Build libstd with stage2 compiler. -- Build librustdoc and a bunch of other things with the stage2 compiler. +- Build `libstd` with stage2 compiler. +- Build `librustdoc` and a bunch of other things with the stage2 compiler. @@ -254,11 +254,11 @@ in other sections: - `./x.py clean` – clean up the build directory (`rm -rf build` works too, but then you have to rebuild LLVM) - `./x.py build --stage 1` – builds everything using the stage 1 compiler, - not just up to libstd + not just up to `libstd` - `./x.py build` – builds the stage2 compiler - Running tests (see the [section on running tests](../tests/running.html) for more details): - - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd + - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from `libstd` - `./x.py test --stage 1 src/test/ui` – runs the `ui` test suite - `./x.py test --stage 1 src/test/ui/const-generics` - runs all the tests in the `const-generics/` subdirectory of the `ui` test suite @@ -268,7 +268,7 @@ in other sections: ### Cleaning out build directories Sometimes you need to start fresh, but this is normally not the case. -If you need to run this then rustbuild is most likely not acting right and +If you need to run this then `rustbuild` is most likely not acting right and you should file a bug as to what is going wrong. If you do need to clean everything up then you only need to run one command! From c2978595fc7668ae2158c8ec1b819525c773b21c Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 16 Mar 2020 18:20:38 -0500 Subject: [PATCH 0837/1812] Fix broken link (#612) --- src/appendix/bibliography.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index 613ee1f4d..ff09a26b0 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -8,7 +8,7 @@ Rust, as well as publications about Rust. * [Region based memory management in Cyclone](https://www.cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf) * [Safe manual memory management in Cyclone](http://www.cs.umd.edu/projects/PL/cyclone/scp.pdf) -* [Typeclasses: making ad-hoc polymorphism less ad hoc](http://www.ps.uni-sb.de/courses/typen-ws99/class.ps.gz) +* [Making ad-hoc polymorphism less ad hoc](https://dl.acm.org/doi/10.1145/75277.75283) * [Macros that work together](https://www.cs.utah.edu/plt/publications/jfp12-draft-fcdf.pdf) * [Traits: composable units of behavior](http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf) * [Alias burying](http://www.cs.uwm.edu/faculty/boyland/papers/unique-preprint.ps) - We tried something similar and abandoned it. From 84791e1c4435be56d5c51f49659bcd40b012de06 Mon Sep 17 00:00:00 2001 From: Solomon Ucko Date: Mon, 16 Mar 2020 21:54:15 -0400 Subject: [PATCH 0838/1812] Change Rust Koans link to point to first koan --- src/appendix/humorust.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index 8bd9c48a6..20a3d1ff1 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -7,7 +7,7 @@ enlightening? - [Ferris Rap](http://fitzgeraldnick.com/2018/12/13/rust-raps.html) - [The Genesis of Generic Germination](https://github.com/rust-lang/rust/pull/53645#issue-210543221) - [The Bastion of the Turbofish test](https://github.com/rust-lang/rust/blob/79d8a0fcefa5134db2a94739b1d18daa01fc6e9f/src/test/ui/bastion-of-the-turbofish.rs) -- [Rust Koans](https://users.rust-lang.org/t/rust-koans/2408/4) +- [Rust Koans](https://users.rust-lang.org/t/rust-koans/2408) - [`break rust;`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0ab2bd6a9d722e0f05a95e2a5dcf89cc) - [The Nomicon Intro](https://doc.rust-lang.org/stable/nomicon/) - [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20(was.3A.20design.20meeting.202.2E.2E.2E ) From acd39231b6dbe524b87a308c540817b7d8cb66fd Mon Sep 17 00:00:00 2001 From: Solomon Ucko Date: Mon, 16 Mar 2020 22:17:46 -0400 Subject: [PATCH 0839/1812] Changed rustc-ty link to go to first message --- src/appendix/humorust.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index 20a3d1ff1..3bbedf5bb 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -10,4 +10,4 @@ enlightening? - [Rust Koans](https://users.rust-lang.org/t/rust-koans/2408) - [`break rust;`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0ab2bd6a9d722e0f05a95e2a5dcf89cc) - [The Nomicon Intro](https://doc.rust-lang.org/stable/nomicon/) -- [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20(was.3A.20design.20meeting.202.2E.2E.2E ) +- [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20(was.3A.20design.20meeting.202.2E.2E.2E/near/189906455 ) From 13f86ff4723625c52065aacc47fe45adafbecdf9 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 17 Mar 2020 06:11:37 -0500 Subject: [PATCH 0840/1812] Add some more info to param_env (#610) * add some more info to param_env * Remove some trailing spaces Co-authored-by: Yuki Okushi --- src/param_env.md | 59 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 49 insertions(+), 10 deletions(-) diff --git a/src/param_env.md b/src/param_env.md index 2474886ef..9ca117b31 100644 --- a/src/param_env.md +++ b/src/param_env.md @@ -3,28 +3,67 @@ When working with associated and/or or generic items (types, constants, functions/methods) it is often relevant to have more information about the `Self` or generic parameters. Trait bounds and similar information is encoded in -the `ParamEnv`. Often this is not enough information to obtain things like the +the [`ParamEnv`][pe]. Often this is not enough information to obtain things like the type's `Layout`, but you can do all kinds of other checks on it (e.g. whether a type implements `Copy`) or you can evaluate an associated constant whose value does not depend on anything from the parameter environment. +[pe]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html + For example if you have a function ```rust -fn foo(t: T) { -} +fn foo(t: T) { ... } ``` the parameter environment for that function is `[T: Copy]`. This means any evaluation within this function will, when accessing the type `T`, know about its `Copy` bound via the parameter environment. -Although you can obtain a valid `ParamEnv` for any item via -`tcx.param_env(def_id)`, this `ParamEnv` can be too generic for your use case. -Using the `ParamEnv` from the surrounding context can allow you to evaluate more -things. +You can get the parameter environment for a `def_id` using the +[`param_env`][query] query. However, this `ParamEnv` can be too generic for +your use case. Using the `ParamEnv` from the surrounding context can allow you +to evaluate more things. For example, suppose we had something the following: + +[query]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ty/ty/fn.param_env.html + +```rust +trait Foo { + type Assoc; +} + +trait Bar { } + +trait Baz { + fn stuff() -> bool; +} + +fn foo(t: T) +where + T: Foo, + ::Assoc: Bar +{ + bar::() +} + +fn bar() { + if T::stuff() { mep() } else { mop() } +} +``` + +We may know some things inside `bar` that we wouldn't know if we just fetched +`bar`'s param env because of the `::Assoc: Bar` bound in `foo`. This +is a contrived example that makes no sense in our existing analyses, but we may +run into similar cases when doing analyses with associated constants on generic +traits or traits with assoc types. + +## Bundling Another great thing about `ParamEnv` is that you can use it to bundle the thing -depending on generic parameters (e.g. a `Ty`) by calling `param_env.and(ty)`. -This will produce a `ParamEnvAnd`, making clear that you should probably not -be using the inner value without taking care to also use the `ParamEnv`. +depending on generic parameters (e.g. a `Ty`) by calling the [`and`][and] +method. This will produce a [`ParamEnvAnd`][pea], making clear that you +should probably not be using the inner value without taking care to also use +the [`ParamEnv`][pe]. + +[and]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html#method.and +[pea]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnvAnd.html From 831a8709c9ef54f9334465fb02519df7e92d435a Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 13 Feb 2020 16:03:46 -0300 Subject: [PATCH 0841/1812] Rephrase where compiletest is located --- src/tests/intro.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index 6a528ae45..e0ccfdb44 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -2,10 +2,10 @@ The Rust project runs a wide variety of different tests, orchestrated by the build system (`x.py test`). The main test harness for testing -the compiler itself is a tool called compiletest (sources in the -[`src/tools/compiletest`]). This section gives a brief overview of how -the testing framework is setup, and then gets into some of the details -on [how to run tests](./running.html) as well as +the compiler itself is a tool called compiletest (located in the +[`src/tools/compiletest`] directory). This section gives a brief +overview of how the testing framework is setup, and then gets into some +of the details on [how to run tests](./running.html) as well as [how to add new tests](./adding.html). [`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest From 7afd3c3eb1a7a24526cac2408cad1dd8cd8b3e41 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 13 Feb 2020 16:04:28 -0300 Subject: [PATCH 0842/1812] Avoid as of this writing given that everything is as of this writing :) --- src/tests/intro.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index e0ccfdb44..cdb22a19c 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -20,9 +20,9 @@ a distinct mode. [`src/test`]: https://github.com/rust-lang/rust/tree/master/src/test -Here is a brief summary of the test suites as of this writing and what -they mean. In some cases, the test suites are linked to parts of the manual -that give more details. +Here is a brief summary of the test suites and what they mean. In some +cases, the test suites are linked to parts of the manual that give more +details. - [`ui`](./adding.html#ui) – tests that check the exact stdout/stderr from compilation and/or running the test From 4215ea9f251366050b81ae267ab4506f5abe2902 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 14 Feb 2020 09:50:03 -0300 Subject: [PATCH 0843/1812] This is no longer true since rust#49219 --- src/tests/running.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index f5c9bdb72..4126341aa 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -89,8 +89,7 @@ tests for components you did not change at all. **Warning:** Note that bors only runs the tests with the full stage 2 build; therefore, while the tests **usually** work fine with stage 1, -there are some limitations. In particular, the stage1 compiler doesn't -work well with procedural macros or custom derive tests. +there are some limitations. ## Running an individual test From 320624ae5554be8dbb356ee545860b055c942d44 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 17 Feb 2020 12:24:57 -0300 Subject: [PATCH 0844/1812] Suites are defined in enum Mode --- src/compiletest.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiletest.md b/src/compiletest.md index 1b424e1a2..8d6386d99 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -20,7 +20,7 @@ The tests themselves are typically (but not always) organized into a folder holding tests that should compile successfully, but return a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more. The various suites are defined in -[src/tools/compiletest/src/common.rs][common] in the `pub struct Config` +[src/tools/compiletest/src/common.rs][common] in the `pub enum Mode` declaration. And a very good introduction to the different suites of compiler tests along with details about them can be found in [Adding new tests](./tests/adding.html). From 89d3be47096a4f5f78bfb7c06a8d36ca82ba3c5c Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 17 Feb 2020 12:28:10 -0300 Subject: [PATCH 0845/1812] All the text is at the time of this writing --- src/compiletest.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index 8d6386d99..dbd6c4b6e 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -58,9 +58,8 @@ Here is an example, specifying the `must-compile-successfully` header command, which takes no arguments, followed by the `failure-status` header command, which takes a single argument (which, in this case is a value of 1). `failure-status` is instructing `compiletest` to expect a failure status of 1 -(rather than the current Rust default of 101 at the time of this writing). The -header command and the argument list (if present) are typically separated by a -colon: +(rather than the current Rust default of 101). The header command and +the argument list (if present) are typically separated by a colon: ```rust,ignore // must-compile-successfully From 8a848cecabc451e60062d4278c08bcd19e78b725 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 17 Feb 2020 16:58:21 -0300 Subject: [PATCH 0846/1812] It may Take a lot of time instead of 2 hours --- src/walkthrough.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index 5d54404ef..226391e6e 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -192,8 +192,8 @@ it. When your review approves the PR, it will go into a queue for yet another bot called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches the head of the `@bors` queue, `@bors` will test out the merge by running all -tests against your PR on Travis CI. This takes about 2 hours as of this -writing. If all tests pass, the PR is merged and becomes part of the next +tests against your PR on Travis CI. This takes may take a lot of time to +finish. If all tests pass, the PR is merged and becomes part of the next nightly compiler! There are a couple of things that may happen for some PRs during the review process From 6d6e8fa329c57cbe5fc0e73cdd1fe14fb108d423 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 18 Feb 2020 12:32:14 -0300 Subject: [PATCH 0847/1812] This page is diagnostics.html now --- src/bug-fix-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md index 90d8fb48b..9ad57be99 100644 --- a/src/bug-fix-procedure.md +++ b/src/bug-fix-procedure.md @@ -292,7 +292,7 @@ self.tcx.sess.add_lint(lint::builtin::OVERLAPPING_INHERENT_IMPLS, We want to convert this into an error. In some cases, there may be an existing error for this scenario. In others, we will need to allocate a fresh diagnostic code. -[Instructions for allocating a fresh diagnostic code can be found here.](rustc-diagnostic-code.html) +[Instructions for allocating a fresh diagnostic code can be found here.](diagnostics/diagnostic-codes.html) You may want to mention in the extended description that the compiler behavior changed on this point, and include a reference to the tracking issue for the change. From 8a934937df99474ea12cddb5ea95cd9a7d6e409e Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 18 Feb 2020 14:47:39 -0300 Subject: [PATCH 0848/1812] Remove typo --- src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 780950c71..686c9b270 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -66,7 +66,7 @@ it would end up de facto stable and we'll not be able to make changes in it without breaking people's code. The way we do that is that we make sure all new features are feature -gated - they can't be used without a enabling a feature gate +gated - they can't be used without enabling a feature gate (`#[feature(foo)]`), which can't be done in a stable/beta compiler. See the [stability in code] section for the technical details. From 9263df76682c158ad9e0a23d928820d3e8c17df5 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 16 Mar 2020 18:51:29 -0300 Subject: [PATCH 0849/1812] Fix line lengths --- src/bug-fix-procedure.md | 14 +++++++------- src/tests/intro.md | 10 +++++----- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md index 9ad57be99..9c711ae1c 100644 --- a/src/bug-fix-procedure.md +++ b/src/bug-fix-procedure.md @@ -289,13 +289,13 @@ self.tcx.sess.add_lint(lint::builtin::OVERLAPPING_INHERENT_IMPLS, msg); ``` -We want to convert this into an error. In some cases, there may be an existing -error for this scenario. In others, we will need to allocate a fresh diagnostic -code. -[Instructions for allocating a fresh diagnostic code can be found here.](diagnostics/diagnostic-codes.html) -You may want to mention in the extended description that the compiler behavior -changed on this point, and include a reference to the tracking issue for the -change. +We want to convert this into an error. In some cases, there may be an +existing error for this scenario. In others, we will need to allocate a +fresh diagnostic code. [Instructions for allocating a fresh diagnostic +code can be found here.](diagnostics/diagnostic-codes.html) You may want +to mention in the extended description that the compiler behavior +changed on this point, and include a reference to the tracking issue for +the change. Let's say that we've adopted `E0592` as our code. Then we can change the `add_lint()` call above to something like: diff --git a/src/tests/intro.md b/src/tests/intro.md index cdb22a19c..b70a23a6a 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -1,12 +1,12 @@ # The compiler testing framework -The Rust project runs a wide variety of different tests, orchestrated -by the build system (`x.py test`). The main test harness for testing -the compiler itself is a tool called compiletest (located in the +The Rust project runs a wide variety of different tests, orchestrated by +the build system (`x.py test`). The main test harness for testing the +compiler itself is a tool called compiletest (located in the [`src/tools/compiletest`] directory). This section gives a brief overview of how the testing framework is setup, and then gets into some -of the details on [how to run tests](./running.html) as well as -[how to add new tests](./adding.html). +of the details on [how to run tests](./running.html) as well as [how to +add new tests](./adding.html). [`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest From 769826dffc6656d5d490e1888da000e99e4325f2 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 16 Mar 2020 18:53:03 -0300 Subject: [PATCH 0850/1812] use-jemalloc -> jemalloc --- src/profiling/with_perf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index cca2d06d1..d22a3cf4b 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -8,7 +8,7 @@ This is a guide for how to profile rustc with [perf](https://perf.wiki.kernel.or to profile. - Set the following settings in your `config.toml`: - `debuginfo-level = 1` - enables line debuginfo - - `use-jemalloc = false` - lets you do memory use profiling with valgrind + - `jemalloc = false` - lets you do memory use profiling with valgrind - leave everything else the defaults - Run `./x.py build` to get a full build - Make a rustup toolchain pointing to that result From 39ebd5dea7e2f47c9e1a856da322a1eb04b708e1 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 17 Mar 2020 13:54:42 -0300 Subject: [PATCH 0851/1812] Update src/bug-fix-procedure.md Co-Authored-By: Who? Me?! --- src/bug-fix-procedure.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md index 9c711ae1c..55bc86859 100644 --- a/src/bug-fix-procedure.md +++ b/src/bug-fix-procedure.md @@ -292,7 +292,7 @@ self.tcx.sess.add_lint(lint::builtin::OVERLAPPING_INHERENT_IMPLS, We want to convert this into an error. In some cases, there may be an existing error for this scenario. In others, we will need to allocate a fresh diagnostic code. [Instructions for allocating a fresh diagnostic -code can be found here.](diagnostics/diagnostic-codes.html) You may want +code can be found here.](./diagnostics/diagnostic-codes.md) You may want to mention in the extended description that the compiler behavior changed on this point, and include a reference to the tracking issue for the change. @@ -327,4 +327,3 @@ Open a PR. =) [rfc 1122]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md [breaking-change-issue]: https://gist.github.com/nikomatsakis/631ec8b4af9a18b5d062d9d9b7d3d967 - From 0d631447bc38c229202f98bc4a41d1d8d332678a Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 17 Mar 2020 13:54:53 -0300 Subject: [PATCH 0852/1812] Update src/walkthrough.md Co-Authored-By: Who? Me?! --- src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index 226391e6e..c74f72cc5 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -192,7 +192,7 @@ it. When your review approves the PR, it will go into a queue for yet another bot called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches the head of the `@bors` queue, `@bors` will test out the merge by running all -tests against your PR on Travis CI. This takes may take a lot of time to +tests against your PR on Travis CI. This takes a lot of time to finish. If all tests pass, the PR is merged and becomes part of the next nightly compiler! From 77600c02049cd92fd2eca441bb61db244d3083b8 Mon Sep 17 00:00:00 2001 From: bjorn3 Date: Tue, 17 Mar 2020 20:14:48 +0100 Subject: [PATCH 0853/1812] Fix typo (#618) --- src/backend/backend.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/backend.md b/src/backend/backend.md index 9832abb1d..0eaa72036 100644 --- a/src/backend/backend.md +++ b/src/backend/backend.md @@ -38,7 +38,7 @@ The code for codegen is actually a bit complex due to a few factors: - Codegen happens asynchronously in another thread for performance. - The actual codegen is done by a third-party library (either LLVM or Cranelift). -Generally, the [`rustc_codegen_ssa`][ssa] crate contains backend-agnastic code +Generally, the [`rustc_codegen_ssa`][ssa] crate contains backend-agnostic code (i.e. independent of LLVM or Cranelift), while the [`rustc_codegen_llvm`][llvm] crate contains code specific to LLVM codegen. From 8c26c367b375530f0ea3686c01904227e4cfc64f Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Thu, 19 Mar 2020 19:57:12 +0100 Subject: [PATCH 0854/1812] words (#622) --- src/ty.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ty.md b/src/ty.md index bb2c24b13..a4274bc9f 100644 --- a/src/ty.md +++ b/src/ty.md @@ -181,7 +181,7 @@ Here is a sampling: [**Algebraic Data Types (ADTs)**]() An [*algebraic Data Type*][wikiadt] is a `struct`, `enum` or `union`. Under the hood, `struct`, `enum` and `union` are actually implemented the same way: they -are both [`ty::TyKind::Adt`][kindadt]. It’s basically a user defined type. We will talk more about +are all [`ty::TyKind::Adt`][kindadt]. It’s basically a user defined type. We will talk more about these later. [**Foreign**][kindforeign] Corresponds to `extern type T`. From 1ed6139b140cb062a32a6bcf69e09e50f6dc1074 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 20 Mar 2020 11:32:33 -0500 Subject: [PATCH 0855/1812] Move GenericArgs chapter under ty (#624) --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 7cc41e0b6..75a77d0ae 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -56,7 +56,7 @@ - [The `ty` module: representing types](./ty.md) - [Generics and substitutions](./generics.md) - [`TypeFolder` and `TypeFoldable`](./ty-fold.md) - - [Generic arguments](./generic_arguments.md) + - [Generic arguments](./generic_arguments.md) - [Type inference](./type-inference.md) - [Trait solving (old-style)](./traits/resolution.md) - [Higher-ranked trait bounds](./traits/hrtb.md) From e74b303fbbc38e1d67af954ef6da95d839c33ec6 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 21 Mar 2020 16:26:04 -0700 Subject: [PATCH 0856/1812] Example of rustc interface (#621) * Example of rustc interface (https://internals.rust-lang.org/t/using-the-rustc-interface-crate/11982) --- examples/rustc-driver-example.rs | 103 +++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 examples/rustc-driver-example.rs diff --git a/examples/rustc-driver-example.rs b/examples/rustc-driver-example.rs new file mode 100644 index 000000000..3c483e776 --- /dev/null +++ b/examples/rustc-driver-example.rs @@ -0,0 +1,103 @@ +#![feature(rustc_private)] + +extern crate rustc; +extern crate rustc_error_codes; +extern crate rustc_errors; +extern crate rustc_hash; +extern crate rustc_hir; +extern crate rustc_interface; +extern crate rustc_span; + +use rustc::session; +use rustc::session::config; +use rustc_errors::registry; +use rustc_hash::{FxHashMap, FxHashSet}; +use rustc_interface::interface; +use rustc_span::source_map; +use std::path; +use std::process; +use std::str; + +fn main() { + let out = process::Command::new("rustc") + .arg("--print=sysroot") + .current_dir(".") + .output() + .unwrap(); + let sysroot = str::from_utf8(&out.stdout).unwrap().trim(); + let filename = "main.rs"; + let contents = "static HELLO: &str = \"Hello, world!\"; fn main() { println!(\"{}\", HELLO); }"; + let errors = registry::Registry::new(&rustc_error_codes::DIAGNOSTICS); + let config = interface::Config { + // Command line options + opts: config::Options { + maybe_sysroot: Some(path::PathBuf::from(sysroot)), + ..config::Options::default() + }, + + // cfg! configuration in addition to the default ones + // FxHashSet<(String, Option)> + crate_cfg: FxHashSet::default(), + + input: config::Input::Str { + name: source_map::FileName::Custom(String::from(filename)), + input: String::from(contents), + }, + // Option + input_path: None, + // Option + output_dir: None, + // Option + output_file: None, + // Option> + file_loader: None, + diagnostic_output: session::DiagnosticOutput::Default, + + // Set to capture stderr output during compiler execution + // Option>>> + stderr: None, + + // Option + crate_name: None, + // FxHashMap + lint_caps: FxHashMap::default(), + + // This is a callback from the driver that is called when we're registering lints; + // it is called during plugin registration when we have the LintStore in a non-shared state. + // + // Note that if you find a Some here you probably want to call that function in the new + // function being registered. + // Option> + register_lints: None, + + // This is a callback from the driver that is called just after we have populated + // the list of queries. + // + // The second parameter is local providers and the third parameter is external providers. + // Option, &mut ty::query::Providers<'_>)> + override_queries: None, + + // Registry of diagnostics codes. + registry: errors, + }; + interface::run_compiler(config, |compiler| { + compiler.enter(|queries| { + // Parse the program and print the syntax tree. + let parse = queries.parse().unwrap().take(); + println!("{:#?}", parse); + // Analyze the program and inspect the types of definitions. + queries.global_ctxt().unwrap().take().enter(|tcx| { + for (_, item) in &tcx.hir().krate().items { + match item.kind { + rustc_hir::ItemKind::Static(_, _, _) | rustc_hir::ItemKind::Fn(_, _, _) => { + let name = item.ident; + let ty = tcx.type_of(tcx.hir().local_def_id(item.hir_id)); + println!("{:?}:\t{:?}", name, ty) + } + _ => (), + } + } + }) + }); + }); +} From 75f77eadfeb161739f6d96e90f6032f6ea4e3f7b Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 21 Mar 2020 17:18:41 -0700 Subject: [PATCH 0857/1812] Reference example from #621 --- src/rustc-driver.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/rustc-driver.md b/src/rustc-driver.md index e240ea58b..2f8f68ebb 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -14,6 +14,7 @@ function is the main entrypoint to the compiler. It takes a configuration for th and a closure that takes a [`Compiler`]. `run_compiler` creates a `Compiler` from the configuration and passes it to the closure. Inside the closure, you can use the `Compiler` to drive queries to compile a crate and get the results. This is what the `rustc_driver` does too. +You can see a minimal example of how to use `rustc_interface` [here][example]. You can see what queries are currently available through the rustdocs for [`Compiler`]. You can see an example of how to use them by looking at the `rustc_driver` implementation, @@ -36,6 +37,7 @@ replaces this functionality. [cb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/trait.Callbacks.html [rd_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.run_compiler.html [i_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/fn.run_compiler.html +[example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/src/rustc-driver-example.rs [`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/ [`Compiler`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html From 506d2d36a4b455a719d61873349886226d0a25ae Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 21 Mar 2020 17:43:46 -0700 Subject: [PATCH 0858/1812] Fix reference Co-Authored-By: Who? Me?! --- src/rustc-driver.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 2f8f68ebb..b50ee5b47 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -37,7 +37,7 @@ replaces this functionality. [cb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/trait.Callbacks.html [rd_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.run_compiler.html [i_rc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/fn.run_compiler.html -[example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/src/rustc-driver-example.rs +[example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-example.rs [`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/ [`Compiler`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html From 09ed54f557cbe7d0ad0f3d9ec4ec3008498fadb8 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sun, 22 Mar 2020 09:47:26 -0700 Subject: [PATCH 0859/1812] run_compiler is exported by rustc_interface --- examples/rustc-driver-example.rs | 5 ++--- src/rustc-driver.md | 4 ++-- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/examples/rustc-driver-example.rs b/examples/rustc-driver-example.rs index 3c483e776..62c80b4ae 100644 --- a/examples/rustc-driver-example.rs +++ b/examples/rustc-driver-example.rs @@ -12,7 +12,6 @@ use rustc::session; use rustc::session::config; use rustc_errors::registry; use rustc_hash::{FxHashMap, FxHashSet}; -use rustc_interface::interface; use rustc_span::source_map; use std::path; use std::process; @@ -28,7 +27,7 @@ fn main() { let filename = "main.rs"; let contents = "static HELLO: &str = \"Hello, world!\"; fn main() { println!(\"{}\", HELLO); }"; let errors = registry::Registry::new(&rustc_error_codes::DIAGNOSTICS); - let config = interface::Config { + let config = rustc_interface::Config { // Command line options opts: config::Options { maybe_sysroot: Some(path::PathBuf::from(sysroot)), @@ -80,7 +79,7 @@ fn main() { // Registry of diagnostics codes. registry: errors, }; - interface::run_compiler(config, |compiler| { + rustc_interface::run_compiler(config, |compiler| { compiler.enter(|queries| { // Parse the program and print the syntax tree. let parse = queries.parse().unwrap().take(); diff --git a/src/rustc-driver.md b/src/rustc-driver.md index b50ee5b47..90a88b3d6 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -9,7 +9,7 @@ for running code at particular times during the compilation process, allowing third parties to effectively use `rustc`'s internals as a library for analysing a crate or emulating the compiler in-process (e.g. the RLS or rustdoc). -For those using `rustc` as a library, the [`rustc_interface::interface::run_compiler()`][i_rc] +For those using `rustc` as a library, the [`rustc_interface::run_compiler()`][i_rc] function is the main entrypoint to the compiler. It takes a configuration for the compiler and a closure that takes a [`Compiler`]. `run_compiler` creates a `Compiler` from the configuration and passes it to the closure. Inside the closure, you can use the `Compiler` @@ -19,7 +19,7 @@ You can see a minimal example of how to use `rustc_interface` [here][example]. You can see what queries are currently available through the rustdocs for [`Compiler`]. You can see an example of how to use them by looking at the `rustc_driver` implementation, specifically the [`rustc_driver::run_compiler` function][rd_rc] (not to be confused with -[`rustc_interface::interface::run_compiler`][i_rc]). The `rustc_driver::run_compiler` function +[`rustc_interface::run_compiler`][i_rc]). The `rustc_driver::run_compiler` function takes a bunch of command-line args and some other configurations and drives the compilation to completion. From 0e1ad678edd4951e31f585cea07d222d1f07a405 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 18:43:02 -0400 Subject: [PATCH 0860/1812] [stupid-stats] replace removed rustc_codegen_utils with rustc_codegen_ssa --- src/appendix/stupid-stats.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md index ea9b6e0f0..7453f4424 100644 --- a/src/appendix/stupid-stats.md +++ b/src/appendix/stupid-stats.md @@ -94,7 +94,7 @@ translation). > NOTE: `librustc_trans` and `librustc_back` no longer exist, and we don't > translate AST or HIR directly to LLVM IR anymore. Instead, see > [`librustc_codegen_llvm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/index.html) -> and [`librustc_codegen_utils`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_utils/index.html). +> and [`librustc_codegen_ssa`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/index.html). All these phases are coordinated by the driver. To see the exact sequence, look at the `compile_input` function in `librustc_driver`. From d1cd418908a861c83091fabdfe27f9b831c49dbc Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 18:24:40 -0400 Subject: [PATCH 0861/1812] add rust-lang/rust license documentation --- src/SUMMARY.md | 1 + src/licenses.md | 5 +++++ 2 files changed, 6 insertions(+) create mode 100644 src/licenses.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 75a77d0ae..722bcedc6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -32,6 +32,7 @@ - [ICE-breaker teams](ice-breaker/about.md) - ["Cleanup Crew" ICE-breakers](ice-breaker/cleanup-crew.md) - [LLVM ICE-breakers](ice-breaker/llvm.md) + - [Licenses](./licenses.md) - [Part 2: How rustc works](./part-2-intro.md) - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver and Interface](./rustc-driver.md) diff --git a/src/licenses.md b/src/licenses.md new file mode 100644 index 000000000..2d282704d --- /dev/null +++ b/src/licenses.md @@ -0,0 +1,5 @@ +# Rustc Licenses + +The `rustc` compiler source is dual licensed under the [Apache License v2.0](https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE) and the [MIT License](https://github.com/rust-lang/rust/blob/master/LICENSE-MIT) unless otherwise specified. + +Detailed licensing information is available in the [COPYRIGHT document](https://github.com/rust-lang/rust/blob/master/COPYRIGHT) of the `rust-lang/rust` repository. From 5a9d784d9e68ee845f85113a68f64c355f9ebf50 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 19:34:32 -0400 Subject: [PATCH 0862/1812] Update src/licenses.md Co-Authored-By: Who? Me?! --- src/licenses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/licenses.md b/src/licenses.md index 2d282704d..e5f9e91bc 100644 --- a/src/licenses.md +++ b/src/licenses.md @@ -1,5 +1,5 @@ # Rustc Licenses -The `rustc` compiler source is dual licensed under the [Apache License v2.0](https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE) and the [MIT License](https://github.com/rust-lang/rust/blob/master/LICENSE-MIT) unless otherwise specified. +The `rustc` compiler source and standard library is dual licensed under the [Apache License v2.0](https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE) and the [MIT License](https://github.com/rust-lang/rust/blob/master/LICENSE-MIT) unless otherwise specified. Detailed licensing information is available in the [COPYRIGHT document](https://github.com/rust-lang/rust/blob/master/COPYRIGHT) of the `rust-lang/rust` repository. From cc7b8e9099a9f29e467e6f3ddfbb6a929deddc1a Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 19:34:55 -0400 Subject: [PATCH 0863/1812] change title Co-Authored-By: Who? Me?! --- src/licenses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/licenses.md b/src/licenses.md index e5f9e91bc..b7f17ed9e 100644 --- a/src/licenses.md +++ b/src/licenses.md @@ -1,4 +1,4 @@ -# Rustc Licenses +# `rust-lang/rust` Licenses The `rustc` compiler source and standard library is dual licensed under the [Apache License v2.0](https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE) and the [MIT License](https://github.com/rust-lang/rust/blob/master/LICENSE-MIT) unless otherwise specified. From ff0e4f098df8ef8ea6bbcca5552cae0608e696a7 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 22 Mar 2020 19:36:53 -0400 Subject: [PATCH 0864/1812] minor grammar edit --- src/licenses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/licenses.md b/src/licenses.md index b7f17ed9e..06cd8ae6b 100644 --- a/src/licenses.md +++ b/src/licenses.md @@ -1,5 +1,5 @@ # `rust-lang/rust` Licenses -The `rustc` compiler source and standard library is dual licensed under the [Apache License v2.0](https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE) and the [MIT License](https://github.com/rust-lang/rust/blob/master/LICENSE-MIT) unless otherwise specified. +The `rustc` compiler source and standard library are dual licensed under the [Apache License v2.0](https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE) and the [MIT License](https://github.com/rust-lang/rust/blob/master/LICENSE-MIT) unless otherwise specified. Detailed licensing information is available in the [COPYRIGHT document](https://github.com/rust-lang/rust/blob/master/COPYRIGHT) of the `rust-lang/rust` repository. From ed2ad0eccb2804d1ae7cf8aaf1e2490d283a281c Mon Sep 17 00:00:00 2001 From: Alex Aktsipetrov Date: Wed, 25 Mar 2020 20:14:48 +0100 Subject: [PATCH 0865/1812] Update high-level-overview.md Remove an obsolete clarification about libsyntax and co. --- src/high-level-overview.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 76f4bc955..276ff8bc1 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -60,8 +60,7 @@ crates export are "query definitions", but those are covered later on). Below `rustc` lie various crates that make up the parser and error -reporting mechanism. For historical reasons, these crates do not have -the `rustc_` prefix, but they are really just as much an internal part +reporting mechanism. They are also an internal part of the compiler and not intended to be stable (though they do wind up getting used by some crates in the wild; a practice we hope to gradually phase out). From 6b441177f323c877aa73d1523944c26d26c2748e Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Thu, 26 Mar 2020 17:22:46 +0100 Subject: [PATCH 0866/1812] Update description of incremental compilation. --- .../incremental-compilation-in-detail.md | 122 ++++++++++++++---- .../query-evaluation-model-in-detail.md | 3 +- 2 files changed, 98 insertions(+), 27 deletions(-) diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index fbe226e90..505dde1a8 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -11,7 +11,7 @@ simple extension to the overall query system. It relies on the fact that: This chapter will explain how we can use these properties for making things incremental and then goes on to discuss version implementation issues. -# A Basic Algorithm For Incremental Query Evaluation +## A Basic Algorithm For Incremental Query Evaluation As explained in the [query evaluation model primer][query-model], query invocations form a directed-acyclic graph. Here's the example from the @@ -36,9 +36,9 @@ we know which queries were invoked (the nodes of the graph) and for each invocation, which other queries or input has gone into computing the query's result (the edges of the graph). -Now suppose, we change the source code of our program so that +Now suppose we change the source code of our program so that HIR of `bar` looks different than before. Our goal is to only recompute -those queries that are actually affected by the change while just re-using +those queries that are actually affected by the change while re-using the cached results of all the other queries. Given the dependency graph we can do exactly that. For a given query invocation, the graph tells us exactly what data has gone into computing its results, we just have to follow the @@ -46,7 +46,7 @@ edges until we reach something that has changed. If we don't encounter anything that has changed, we know that the query still would evaluate to the same result we already have in our cache. -Taking the `type_of(foo)` invocation from above as example, we can check +Taking the `type_of(foo)` invocation from above as an example, we can check whether the cached result is still valid by following the edges to its inputs. The only edge leads to `Hir(foo)`, an input that has not been affected by the change. So we know that the cached result for `type_of(foo)` is still @@ -63,9 +63,9 @@ turn will re-run `type_of(bar)`, which will yield an up-to-date result because it reads the up-to-date version of `Hir(bar)`. -# The Problem With The Basic Algorithm: False Positives +## The Problem With The Basic Algorithm: False Positives -If you read the previous paragraph carefully, you'll notice that it says that +If you read the previous paragraph carefully you'll notice that it says that `type_of(bar)` *might* have changed because one of its inputs has changed. There's also the possibility that it might still yield exactly the same result *even though* its input has changed. Consider an example with a @@ -90,7 +90,7 @@ of examples like this and small changes to the input often potentially affect very large parts of the output binaries. As a consequence, we had to make the change detection system smarter and more accurate. -# Improving Accuracy: The red-green Algorithm +## Improving Accuracy: The red-green Algorithm The "false positives" problem can be solved by interleaving change detection and query re-evaluation. Instead of walking the graph all the way to the @@ -98,7 +98,7 @@ inputs when trying to find out if some cached result is still valid, we can check if a result has *actually* changed after we were forced to re-evaluate it. -We call this algorithm, for better or worse, the red-green algorithm because nodes +We call this algorithm the red-green algorithm because nodes in the dependency graph are assigned the color green if we were able to prove that its cached result is still valid and the color red if the result has turned out to be different after re-evaluating it. @@ -128,7 +128,7 @@ fn try_mark_green(tcx, current_node) -> bool { return false } Unknown => { - // This is the first time we are look at this node. Let's try + // This is the first time we look at this node. Let's try // to mark it green by calling try_mark_green() recursively. if try_mark_green(tcx, dependency) { // We successfully marked the input as green, on to the @@ -186,15 +186,15 @@ invoke the query provider to re-compute the result. -# The Real World: How Persistence Makes Everything Complicated +## The Real World: How Persistence Makes Everything Complicated The sections above described the underlying algorithm for incremental compilation but because the compiler process exits after being finished and -takes the query context with its result cache with it into oblivion, we have +takes the query context with its result cache with it into oblivion, we have to persist data to disk, so the next compilation session can make use of it. This comes with a whole new set of implementation challenges: -- The query results cache is stored to disk, so they are not readily available +- The query result cache is stored to disk, so they are not readily available for change comparison. - A subsequent compilation session will start off with new version of the code that has arbitrary changes applied to it. All kinds of IDs and indices that @@ -205,11 +205,11 @@ This comes with a whole new set of implementation challenges: - Persisting things to disk comes at a cost, so not every tiny piece of information should be actually cached in between compilation sessions. Fixed-sized, plain-old-data is preferred to complex things that need to run - branching code during (de-)serialization. + through an expensive (de-)serialization step. The following sections describe how the compiler currently solves these issues. -## A Question Of Stability: Bridging The Gap Between Compilation Sessions +### A Question Of Stability: Bridging The Gap Between Compilation Sessions As noted before, various IDs (like `DefId`) are generated by the compiler in a way that depends on the contents of the source code being compiled. ID assignment @@ -253,7 +253,7 @@ the `LocalId`s within it are still the same. -## Checking Query Results For Changes: StableHash And Fingerprints +### Checking Query Results For Changes: HashStable And Fingerprints In order to do red-green-marking we often need to check if the result of a query has changed compared to the result it had during the previous @@ -273,7 +273,7 @@ value of the result. We call this hash value "the `Fingerprint` of the query result". The hashing is (and has to be) done "in a stable way". This means that whenever something is hashed that might change in between compilation sessions (e.g. a `DefId`), we instead hash its stable equivalent -(e.g. the corresponding `DefPath`). That's what the whole `StableHash` +(e.g. the corresponding `DefPath`). That's what the whole `HashStable` infrastructure is for. This way `Fingerprint`s computed in two different compilation sessions are still comparable. @@ -300,12 +300,8 @@ This approach works rather well but it's not without flaws: use a good and thus expensive hash function, and we have to map things to their stable equivalents while doing the hashing. -In the future we might want to explore different approaches to this problem. -For now it's `StableHash` and `Fingerprint`. - - -## A Tale Of Two DepGraphs: The Old And The New +### A Tale Of Two DepGraphs: The Old And The New The initial description of dependency tracking glosses over a few details that quickly become a head scratcher when actually trying to implement things. @@ -327,7 +323,7 @@ the given fingerprint, it means that the query key refers to something that did not yet exist in the previous session. So, having found the dep-node in the previous dependency graph, we can look -up its dependencies (also dep-nodes in the previous graph) and continue with +up its dependencies (i.e. also dep-nodes in the previous graph) and continue with the rest of the try-mark-green algorithm. The next interesting thing happens when we successfully marked the node as green. At that point we copy the node and the edges to its dependencies from the old graph into the new graph. We @@ -343,12 +339,86 @@ new graph is serialized out to disk, alongside the query result cache, and can act as the previous dep-graph in a subsequent compilation session. -## Didn't You Forget Something?: Cache Promotion -TODO +### Didn't You Forget Something?: Cache Promotion + +The system described so far has a somewhat subtle property: If all inputs of a +dep-node are green then the dep-node itself can be marked as green without +computing or loading the corresponding query result. Applying this property +transitively often leads to the situation that some intermediate results are +never actually loaded from disk, as in the following example: + +```ignore + input(A) <-- intermediate_query(B) <-- leaf_query(C) +``` + +The compiler might need the value of `leaf_query(C)` in order to generate some +output artifact. If it can mark `leaf_query(C)` as green, it will load the +result from the on-disk cache. The result of `intermediate_query(B)` is never +loaded though. As a consequence, when the compiler persists the *new* result +cache by writing all in-memory query results to disk, `intermediate_query(B)` +will not be in memory and thus will be missing from the new result cache. + +If there subsequently is another compilation session that actually needs the +result of `intermediate_query(B)` it will have to be re-computed even though we +had a perfectly valid result for it in the cache just before. + +In order to prevent this from happening, the compiler does something called +"cache promotion": Before emitting the new result cache it will walk all green +dep-nodes and make sure that their query result is loaded into memory. That way +the result cache doesn't unnecessarily shrink again. + + + +# Incremental Compilation and the Compiler Backend + +The compiler backend, the part involving LLVM, is using the query system but +it is not implemented in terms of queries itself. As a consequence +it does not automatically partake in dependency tracking. However, the manual +integration with the tracking system is pretty straight-forward. The compiler +simply tracks what queries get invoked when generating the initial LLVM version +of each codegen unit, which results in a dep-node for each of them. In +subsequent compilation sessions it then tries to mark the dep-node for a CGU as +green. If it succeeds it knows that the corresponding object and bitcode files +on disk are still valid. If it doesn't succeed, the entire codegen unit has to +be recompiled. + +This is the same approach that is used for regular queries. The main differences +are: + + - that we cannot easily compute a fingerprint for LLVM modules (because + they are opaque C++ objects), + + - that the logic for dealing with cached values is rather different from + regular queries because here we have bitcode and object files instead of + serialized Rust values in the common result cache file, and + + - the operations around LLVM are so expensive in terms of computation time and + memory consumption that we need to have tight control over what is + executed when and what stays in memory for how long. + +The query system could probably be extended with general purpose mechanisms to +deal with all of the above but so far that seemed like more trouble than it +would save. + + +# Shortcomings of the Current System + +There are many things that still can be improved. + +## Incrementality of on-disk data structures + +The current system is not able to update on-disk caches and the dependency graph +in-place. Instead it has to rewrite each file entirely in each compilation +session. The overhead of doing so is a few percent of total compilation time. + +## Unnecessary data dependencies +Data structures used as query results could be factored in a way that removes +edges from the dependency graph. Especially "span" information is very volatile, +so including it in query result will increase the chance that that result won't +be reusable. See https://github.com/rust-lang/rust/issues/47389 for more +information. -# The Future: Shortcomings Of The Current System and Possible Solutions -TODO [query-model]: ./query-evaluation-model-in-detail.html diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 83c127550..5e94f2f03 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -75,7 +75,8 @@ When the query context is created, it is still empty: No queries have been executed, no results are cached. But the context already provides access to "input" data, i.e. pieces of immutable data that were computed before the context was created and that queries can access to do their computations. -Currently this input data consists mainly of the HIR map and the command-line +Currently this input data consists mainly of the HIR map, upstream crate +metadata, and the command-line options the compiler was invoked with. In the future, inputs will just consist of command-line options and a list of source files -- the HIR map will itself be provided by a query which processes these source files. From 3d3c26143f45198622b5a96f0806ba791a5e8706 Mon Sep 17 00:00:00 2001 From: Alex Aktsipetrov Date: Fri, 27 Mar 2020 11:42:53 +0100 Subject: [PATCH 0867/1812] Fix typo (#635) * Typo * Update src/queries/query-evaluation-model-in-detail.md Co-authored-by: Yuki Okushi --- src/queries/query-evaluation-model-in-detail.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 5e94f2f03..2d4214ef3 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -159,7 +159,8 @@ would still exist and already executed queries would not have to be re-done. ## Cycles Earlier we stated that query invocations form a DAG. However, it would be easy -form a cyclic graph by, for example, having a query provider like the following: +to form a cyclic graph by, for example, having a query provider like the +following: ```rust,ignore fn cyclic_query_provider(tcx, key) -> u32 { @@ -225,7 +226,7 @@ The nightly compiler already implements parallel query evaluation as follows: When a query `foo` is evaluated, the cache table for `foo` is locked. -- If there already is a result, we can clone it,release the lock and +- If there already is a result, we can clone it, release the lock and we are done. - If there is no cache entry and no other active query invocation computing the same result, we mark the key as being "in progress", release the lock and @@ -235,4 +236,3 @@ When a query `foo` is evaluated, the cache table for `foo` is locked. computed the result we are waiting for. This cannot deadlock because, as mentioned before, query invocations form a DAG. Some thread will always make progress. - From 3cc54f21942172218a503f60c44a987ba900c156 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 28 Mar 2020 21:29:57 +0200 Subject: [PATCH 0868/1812] glossary: misc improvements (#638) --- src/appendix/glossary.md | 138 +++++++++++++++++++-------------------- 1 file changed, 69 insertions(+), 69 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 0218d1a85..9b208b8c0 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -6,81 +6,81 @@ them better. Term | Meaning ------------------------|-------- -arena/arena allocation | an _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _area allocation_. See [this chapter](../memory.md) for more info. -AST | the abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. -binder | a "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound) -bound variable | a "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) -codegen | the code to translate MIR into LLVM IR. -codegen unit | when we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) -completeness | completeness is a technical term in type theory. Completeness means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). -control-flow graph | a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) -CTFE | Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) -cx | we tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. -DAG | a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) -data-flow analysis | a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow) -DefId | an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. -Double pointer | a pointer with additional metadata. See "fat pointer" for more. +arena/arena allocation | An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. +AST | The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. +binder | A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound). +bound variable | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) +codegen | The code to translate MIR into LLVM IR. +codegen unit | When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) +completeness | A technical term in type theory, it means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). +control-flow graph | A representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) +CTFE | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) +cx | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. +DAG | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) +data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). +DefId | An index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. +Double pointer | A pointer with additional metadata. See "fat pointer" for more. drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. -DST | Dynamically-Sized Type. A type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). -early-bound lifetime | a lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) +DST | Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). +early-bound lifetime | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) empty type | see "uninhabited type". -Fat pointer | a two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". -free variable | a "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) -generics | the set of generic type parameters defined on a type or item -HIR | the High-level IR, created by lowering and desugaring the AST ([see more](../hir.html)) -HirId | identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". +Fat pointer | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". +free variable | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) +generics | The set of generic type parameters defined on a type or item. +HIR | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.html)) +HirId | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. -ICE | internal compiler error. When the compiler crashes. -ICH | incremental compilation hash. ICHs are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. -inference variable | when doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. -infcx | the inference context (see `librustc/infer`) -intern | interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. -IR | Intermediate Representation. A general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. +ICE | Short for internal compiler error, this is when the compiler crashes. +ICH | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. +inference variable | When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. +infcx | The inference context (see `librustc/infer`) +intern | Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. +IR | Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). -item | a kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. -lang item | items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) -late-bound lifetime | a lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) -local crate | the crate currently being compiled. -LTO | Link-Time Optimizations. A set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto] -[LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that output LLVM IR and use LLVM to compile to all the platforms LLVM supports. -memoize | memoization is the process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. -MIR | the Mid-level IR that is created after type-checking for use by borrowck and codegen ([see more](../mir/index.html)) -miri | an interpreter for MIR used for constant evaluation ([see more](../miri.html)) -monomorphize | Monomorphization is the process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). -normalize | a general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize) -newtype | a "newtype" is a wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -NLL | [non-lexical lifetimes](../borrow_check/region_inference.html), an extension to Rust's borrowing system to make it be based on the control-flow graph. -node-id or NodeId | an index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. -obligation | something that must be proven by the trait system ([see more](../traits/resolution.html)) +item | A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. +lang item | Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) +late-bound lifetime | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) +local crate | The crate currently being compiled. +LTO | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. +[LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. +memoization | The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. +MIR | The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.html)) +miri | An interpreter for MIR used for constant evaluation. ([see more](../miri.html)) +monomorphization | The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). +normalize | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize). +newtype | A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. +NLL | Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. +node-id or NodeId | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. +obligation | Something that must be proven by the trait system. ([see more](../traits/resolution.html)) placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. -point | used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. -polymorphize | An optimization that avoids unnecessary monomorphisation ([see more](../backend/monomorph.md#polymorphization)) -projection | a general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref) -promoted constants | constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. -provider | the function that executes a query ([see more](../query.html)) -quantified | in math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified) -query | perhaps some sub-computation during compilation ([see more](../query.html)) -region | another term for "lifetime" often used in the literature and in the borrow checker. -rib | a data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) -sess | the compiler session, which stores global data used throughout compilation -side tables | because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. -sigil | like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -soundness | soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). -span | a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. -substs | the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`) -tcx | the "typing context", main data structure of the compiler ([see more](../ty.html)) -'tcx | the lifetime of the allocation arena ([see more](../ty.html)) -trait reference | the name of a trait along with a suitable set of input type/lifetimes ([see more](../traits/goals-and-clauses.html#trait-ref)) -token | the smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). +point | Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. +polymorphize | An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) +projection | A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref). +promoted constants | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. +provider | The function that executes a query. ([see more](../query.html)) +quantified | In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified). +query | Perhaps some sub-computation during compilation. ([see more](../query.html)) +region | Another term for "lifetime" often used in the literature and in the borrow checker. +rib | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) +sess | The compiler session, which stores global data used throughout compilation +side tables | Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. +sigil | Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. +soundness | A technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). +span | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. +substs | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). +tcx | The "typing context", main data structure of the compiler. ([see more](../ty.html)) +'tcx | The lifetime of the allocation arena. ([see more](../ty.html)) +trait reference | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) +token | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. -trans | the code to translate MIR into LLVM IR. Renamed to codegen. -trait reference | a trait and values for its type parameters ([see more](../ty.html)). -ty | the internal representation of a type ([see more](../ty.html)). -UFCS | Universal Function Call Syntax. An unambiguous syntax for calling a method ([see more](../type-checking.html)). -uninhabited type | a type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". -upvar | a variable captured by a closure from outside the closure. -variance | variance determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance. -Wide pointer | a pointer with additional metadata. See "fat pointer" for more. +trans | The code to translate MIR into LLVM IR. Renamed to codegen. +trait reference | A trait and values for its type parameters. ([see more](../ty.html)) +ty | The internal representation of a type. ([see more](../ty.html)) +UFCS | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) +uninhabited type | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". +upvar | A variable captured by a closure from outside the closure. +variance | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance. +Wide pointer | A pointer with additional metadata. See "fat pointer" for more. ZST | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. [LLVM]: https://llvm.org/ From 10ad00edc243fdb79ad44709b7d0818d85971a2a Mon Sep 17 00:00:00 2001 From: ecstatic-morse Date: Sat, 28 Mar 2020 21:23:19 -0700 Subject: [PATCH 0869/1812] Update reference to `has_any_child_of` in docs This function was obsoleted by `find_in_move_path_or_its_descendants`. --- .../moves_and_initialization/move_paths.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index 9b8cbd47a..9bc714649 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -118,10 +118,10 @@ they are also structured into a tree. So for example if you have the you might iterate to find the path `a.b.c` (here you are iterating just over the paths that are **actually referenced** in the source, not all **possible** paths that could have been referenced). These -references are used for example in the [`has_any_child_of`] function, -which checks whether the dataflow results contain a value for the -given move-path (e.g., `a.b`) or any child of that move-path (e.g., -`a.b.c`). +references are used for example in the +[`find_in_move_path_or_its_descendants`] function, which determines +whether a move-path (e.g., `a.b`) or any child of that move-path +(e.g.,`a.b.c`) matches a given predicate. [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Place.html -[`has_any_child_of`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/at_location/struct.FlowAtLocation.html#method.has_any_child_of +[`find_in_move_path_or_its_descendants`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#method.find_in_move_path_or_its_descendants From 83cd94ed2b9925b00cc85a0cb53d833093087d80 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Mon, 30 Mar 2020 14:04:25 +0200 Subject: [PATCH 0870/1812] Rename `librustc` to `librustc_middle` --- README.md | 2 +- src/about-this-guide.md | 2 +- src/appendix/code-index.md | 12 +++--- src/appendix/glossary.md | 8 ++-- .../moves_and_initialization/move_paths.md | 6 +-- src/borrow_check/region_inference.md | 2 +- .../region_inference/lifetime_parameters.md | 4 +- src/borrow_check/two_phase_borrows.md | 6 +-- src/bug-fix-procedure.md | 8 ++-- src/building/compiler-documenting.md | 2 +- src/closure.md | 14 +++---- src/compiler-debugging.md | 10 ++--- src/diagnostics.md | 4 +- src/generics.md | 10 ++--- src/high-level-overview.md | 2 +- src/hir.md | 20 +++++----- src/lowering.md | 2 +- src/macro-expansion.md | 2 +- src/memory.md | 12 +++--- src/mir/index.md | 8 ++-- src/mir/visitor.md | 4 +- src/miri.md | 12 +++--- src/panic-implementation.md | 4 +- src/param_env.md | 6 +-- .../incremental-compilation-in-detail.md | 2 +- src/queries/incremental-compilation.md | 4 +- src/queries/profiling.md | 2 +- src/query.md | 14 +++---- src/rustc-driver.md | 2 +- src/traits/associated-types.md | 4 +- src/traits/goals-and-clauses.md | 4 +- src/ty-fold.md | 14 +++---- src/ty.md | 38 +++++++++---------- 33 files changed, 123 insertions(+), 123 deletions(-) diff --git a/README.md b/README.md index 098971862..4a8c975fb 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ some new part of the compiler that they haven't worked on before. You may also find the rustdocs [for the compiler itself][rustdocs] useful. -[rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ +[rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ ### Contributing to the guide diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 0519099b3..0882c40c0 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -26,6 +26,6 @@ You might also find the following sites useful: of the team procedures, active working groups, and the team calendar. [GitHub repository]: https://github.com/rust-lang/rustc-dev-guide/ -[Rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ +[Rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ [Forge]: https://forge.rust-lang.org/ [compiler-team]: https://github.com/rust-lang/compiler-team/ diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 0321da195..a4b18ecc0 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -16,20 +16,20 @@ Item | Kind | Short description | Chapter | `HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html) `NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/librustc_ast/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html) `P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [src/librustc_ast/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ptr/struct.P.html) -`ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html) +`ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html) `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/librustc_session/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html) `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) -`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) +`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc_middle/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) `SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/librustc_span/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html) `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/librustc_span/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/librustc_span/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html) `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html) `rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/librustc_ast/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) -`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/trait_def/struct.TraitDef.html) -`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html) -`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html) -`TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html) +`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc_middle/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html) +`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc_middle/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html) +`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html) +`TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc_middle/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html) [The HIR]: ../hir.html [Identifiers in the HIR]: ../hir.html#hir-id diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 9b208b8c0..39913a3f7 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -18,11 +18,11 @@ CTFE | Short for Compile-Time Function Evaluation, this is t cx | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. DAG | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). -DefId | An index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`. +DefId | An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. Double pointer | A pointer with additional metadata. See "fat pointer" for more. drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. DST | Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). -early-bound lifetime | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) +early-bound lifetime | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) empty type | see "uninhabited type". Fat pointer | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". free variable | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) @@ -33,13 +33,13 @@ HIR Map | The HIR map, accessible via tcx.hir, allows you to qu ICE | Short for internal compiler error, this is when the compiler crashes. ICH | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. inference variable | When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. -infcx | The inference context (see `librustc/infer`) +infcx | The inference context (see `librustc_middle/infer`) intern | Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. IR | Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). item | A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. lang item | Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) -late-bound lifetime | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#bound-regions)) +late-bound lifetime | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) local crate | The crate currently being compiled. LTO | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index 9bc714649..2c7c73038 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -28,7 +28,7 @@ they are indexed in ways that enable us to do move analysis more efficiently. [`MovePath`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePath.html -[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Place.html +[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html ## Move path indices @@ -105,7 +105,7 @@ of [`MoveData`]. There are two different methods: [`find`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find [`find_local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find_local -[`mir::Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Local.html +[`mir::Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Local.html [`LookupResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/enum.LookupResult.html ## Cross-references @@ -123,5 +123,5 @@ references are used for example in the whether a move-path (e.g., `a.b`) or any child of that move-path (e.g.,`a.b.c`) matches a given predicate. -[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Place.html +[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html [`find_in_move_path_or_its_descendants`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#method.find_in_move_path_or_its_descendants diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index d0da861db..3b844b97c 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -219,7 +219,7 @@ Here are some of the fields of the struct: [`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.constraints [`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints -[`location`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/struct.Location.html +[`location`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Location.html [`universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_regions [`universal_region_relations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_region_relations [`type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.type_tests diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index 4086b71ef..9d6b229ef 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -41,8 +41,8 @@ only variant of [`ty::RegionKind`] that we use is the [`ReVar`] variant. These region variables are broken into two major categories, based on their index: -[`ty::RegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html -[`ReVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.RegionKind.html#variant.ReVar +[`ty::RegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html +[`ReVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#variant.ReVar - 0..N: universal regions -- the ones we are discussing here. In this case, the code must be correct with respect to any value of those diff --git a/src/borrow_check/two_phase_borrows.md b/src/borrow_check/two_phase_borrows.md index f036c3a8c..ad17bbb66 100644 --- a/src/borrow_check/two_phase_borrows.md +++ b/src/borrow_check/two_phase_borrows.md @@ -73,10 +73,10 @@ The activation points are found using the [`GatherBorrows`] visitor. The [`BorrowData`] then holds both the reservation and activation points for the borrow. -[`AutoBorrow`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/adjustment/enum.AutoBorrow.html +[`AutoBorrow`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/adjustment/enum.AutoBorrow.html [converted]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/hair/cx/expr/trait.ToBorrowKind.html#method.to_borrow_kind -[`BorrowKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/enum.BorrowKind.html -[`GatherBorrows`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/visit/trait.Visitor.html#method.visit_local +[`BorrowKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.BorrowKind.html +[`GatherBorrows`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/visit/trait.Visitor.html#method.visit_local [`BorrowData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/borrow_set/struct.BorrowData.html ## Checking two-phase borrows diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md index 55bc86859..e29ad26e0 100644 --- a/src/bug-fix-procedure.md +++ b/src/bug-fix-procedure.md @@ -120,7 +120,7 @@ future-compatibility warnings. These are a special category of lint warning. Adding a new future-compatibility warning can be done as follows. ```rust -// 1. Define the lint in `src/librustc/lint/builtin.rs`: +// 1. Define the lint in `src/librustc_middle/lint/builtin.rs`: declare_lint! { pub YOUR_ERROR_HERE, Warn, @@ -233,9 +233,9 @@ automatically generates the lower-case string; so searching for #### Remove the lint. The first reference you will likely find is the lint definition [in -`librustc/lint/builtin.rs` that resembles this][defsource]: +`librustc_middle/lint/builtin.rs` that resembles this][defsource]: -[defsource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L171-L175 +[defsource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc_middle/lint/builtin.rs#L171-L175 ```rust declare_lint! { @@ -249,7 +249,7 @@ This `declare_lint!` macro creates the relevant data structures. Remove it. You will also find that there is a mention of `OVERLAPPING_INHERENT_IMPLS` later in the file as [part of a `lint_array!`][lintarraysource]; remove it too, -[lintarraysource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L252-L290 +[lintarraysource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc_middle/lint/builtin.rs#L252-L290 Next, you see see [a reference to `OVERLAPPING_INHERENT_IMPLS` in `librustc_lint/lib.rs`][futuresource]. This defining the lint as a "future diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md index 16df10f72..68c9fd227 100644 --- a/src/building/compiler-documenting.md +++ b/src/building/compiler-documenting.md @@ -49,4 +49,4 @@ documentation for internal compiler items will also be built. The documentation for the rust components are found at [rustc doc]. -[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ +[rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ diff --git a/src/closure.md b/src/closure.md index deeed0722..d4f9fc385 100644 --- a/src/closure.md +++ b/src/closure.md @@ -115,9 +115,9 @@ Let's start with defining a term that we will be using quite a bit in the rest o *upvar*. An **upvar** is a variable that is local to the function where the closure is defined. So, in the above examples, **x** will be an upvar to the closure. They are also sometimes referred to as the *free variables* meaning they are not bound to the context of the closure. -[`src/librustc/ty/query/mod.rs`][upvars] defines a query called *upvars* for this purpose. +[`src/librustc_middle/ty/query/mod.rs`][upvars] defines a query called *upvars* for this purpose. -[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/queries/struct.upvars.html +[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/queries/struct.upvars.html Other than lazy invocation, one other thing that the distinguishes a closure from a normal function is that it can use the upvars. It borrows these upvars from its surrounding @@ -135,10 +135,10 @@ and `FnOnce` for move semantics. Most of the code related to the closure is in the [`src/librustc_typeck/check/upvar.rs`][upvar] file and the data structures are -declared in the file [`src/librustc/ty/mod.rs`][ty]. +declared in the file [`src/librustc_middle/ty/mod.rs`][ty]. [upvar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/upvar/index.html -[ty]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/index.html +[ty]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html Before we go any further, let's discuss how we can examine the flow of control through the rustc codebase. For closures specifically, set the `RUST_LOG` env variable as below and collect the @@ -183,9 +183,9 @@ The callbacks are defined by implementing the [`Delegate`] trait. The records for each upvar which mode of borrow was required. The modes of borrow can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be `shared`, `shallow`, `unique` or `mut` as defined in the -[`src/librustc/mir/mod.rs`][mir_mod]. +[`src/librustc_middle/mir/mod.rs`][mir_mod]. -[mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/index.html +[mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html `Delegate` defines a few different methods (the different callbacks): **consume**: for *move* of a variable, **borrow** for a *borrow* of some kind @@ -193,7 +193,7 @@ can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be All of these callbacks have a common argument *cmt* which stands for Category, Mutability and Type and is defined in -[`src/librustc/middle/mem_categorization.rs`][cmt]. Borrowing from the code +[`src/librustc_middle/middle/mem_categorization.rs`][cmt]. Borrowing from the code comments, "`cmt` is a complete categorization of a value indicating where it originated and how it is located, as well as the mutability of the memory in which the value is stored". Based on the callback (consume, borrow etc.), we diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 08e9417b3..9358e0c15 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -130,11 +130,11 @@ stack backtrace: (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) 7: rustc::traits::error_reporting::> ::report_selection_error - at /home/user/rust/src/librustc/traits/error_reporting.rs:823 + at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:823 8: rustc::traits::error_reporting::> ::report_fulfillment_errors - at /home/user/rust/src/librustc/traits/error_reporting.rs:160 - at /home/user/rust/src/librustc/traits/error_reporting.rs:112 + at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:160 + at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:112 9: rustc_typeck::check::FnCtxt::select_obligations_where_possible at /home/user/rust/src/librustc_typeck/check/mod.rs:2192 (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) @@ -172,11 +172,11 @@ look at the log output with a text editor. So to put it together. ```bash -# This puts the output of all debug calls in `librustc/traits` into +# This puts the output of all debug calls in `librustc_middle/traits` into # standard error, which might fill your console backscroll. $ RUSTC_LOG=rustc::traits rustc +local my-file.rs -# This puts the output of all debug calls in `librustc/traits` in +# This puts the output of all debug calls in `librustc_middle/traits` in # `traits-log`, so you can then see it with a text editor. $ RUSTC_LOG=rustc::traits rustc +local my-file.rs 2>traits-log diff --git a/src/diagnostics.md b/src/diagnostics.md index c112f3471..4810e4fa6 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -162,7 +162,7 @@ The possible values of [`Applicability`][appl] are: The compiler linting infrastructure is defined in the [`rustc::lint`][rlint] module. -[rlint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/lint/index.html +[rlint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/index.html ### Declaring a lint @@ -324,7 +324,7 @@ like normal but invokes the lint with `buffer_lint`. The parser (`librustc_ast`) is interesting in that it cannot have dependencies on any of the other `librustc*` crates. In particular, it cannot depend on -`librustc::lint` or `librustc_lint`, where all of the compiler linting +`librustc_middle::lint` or `librustc_lint`, where all of the compiler linting infrastructure is defined. That's troublesome! To solve this, `librustc_ast` defines its own buffered lint type, which diff --git a/src/generics.md b/src/generics.md index 310b9cda6..cdbf63b93 100644 --- a/src/generics.md +++ b/src/generics.md @@ -15,9 +15,9 @@ generic type parameters of the ADT. indicating what kind of generic the type parameter is (type, lifetime, or const). Thus, `SubstsRef` is conceptually like a `&'tcx [GenericArgKind<'tcx>]` slice (but it is actually a `List`). -[list]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.List.html -[`GenericArg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.GenericArg.html -[`GenericArgKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/enum.GenericArgKind.html +[list]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.List.html +[`GenericArg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/struct.GenericArg.html +[`GenericArgKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/enum.GenericArgKind.html So why do we use this `List` type instead of making it really a slice? It has the length "inline", so `&List` is only 32 bits. As a consequence, it cannot be "subsliced" (that only works if the @@ -41,7 +41,7 @@ struct MyStruct - This is one `TyKind::Adt` containing the `AdtDef` of `MyStruct` with the `SubstsRef` above. Finally, we will quickly mention the -[`Generics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.Generics.html) type. It +[`Generics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Generics.html) type. It is used to give information about the type parameters of a type. ### Unsubstituted Generics @@ -125,7 +125,7 @@ You may have a couple of followup questions… `MyStruct`: `Adt(Foo, &[Param(0), Param(1)])`. **`subst`** How do we actually do the substitutions? There is a function for that too! You use -[`subst`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/trait.Subst.html) to +[`subst`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/trait.Subst.html) to replace a `SubstRef` with another list of types. [Here is an example of actually using `subst` in the compiler][substex]. The exact details are not diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 276ff8bc1..472d1ea03 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -100,7 +100,7 @@ take: 3. **Lowering to HIR** - Once name resolution completes, we convert the AST into the HIR, or "[high-level intermediate representation]". The HIR is defined in - `src/librustc/hir/`; that module also includes the [lowering] code. + `src/librustc_middle/hir/`; that module also includes the [lowering] code. - The HIR is a lightly desugared variant of the AST. It is more processed than the AST and more suitable for the analyses that follow. It is **not** required to match the syntax of the Rust language. diff --git a/src/hir.md b/src/hir.md index 2c3e44a72..8b6637ebe 100644 --- a/src/hir.md +++ b/src/hir.md @@ -116,10 +116,10 @@ the [`hir::map`] module). The [HIR map] contains a [number of methods] to convert between IDs of various kinds and to lookup data associated with an HIR node. -[`tcx.hir_map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.GlobalCtxt.html#structfield.hir_map -[`hir::map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/index.html -[HIR map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html -[number of methods]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#methods +[`tcx.hir_map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.GlobalCtxt.html#structfield.hir_map +[`hir::map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/index.html +[HIR map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html +[number of methods]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#methods For example, if you have a [`DefId`], and you would like to convert it to a [`NodeId`], you can use @@ -129,7 +129,7 @@ something outside of the current crate (since then it has no HIR node), but otherwise returns `Some(n)` where `n` is the node-id of the definition. -[as_local_node_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.as_local_node_id +[as_local_node_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.as_local_node_id Similarly, you can use [`tcx.hir.find(n)`][find] to lookup the node for a [`NodeId`]. This returns a `Option>`, where [`Node`] is an enum @@ -140,15 +140,15 @@ that `n` must be some HIR expression, you can do [`tcx.hir.expect_expr(n)`][expect_expr], which will extract and return the [`&hir::Expr`][Expr], panicking if `n` is not in fact an expression. -[find]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.find +[find]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.find [`Node`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/enum.Node.html -[expect_expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.expect_expr +[expect_expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.expect_expr [Expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Expr.html Finally, you can use the HIR map to find the parents of nodes, via calls like [`tcx.hir.get_parent_node(n)`][get_parent_node]. -[get_parent_node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.get_parent_node +[get_parent_node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.get_parent_node ### HIR Bodies @@ -161,5 +161,5 @@ associated with a given def-id ([`maybe_body_owned_by`]) or to find the owner of a body ([`body_owner_def_id`]). [`rustc_hir::Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Body.html -[`maybe_body_owned_by`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.maybe_body_owned_by -[`body_owner_def_id`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/map/struct.Map.html#method.body_owner_def_id +[`maybe_body_owned_by`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.maybe_body_owned_by +[`body_owner_def_id`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.body_owner_def_id diff --git a/src/lowering.md b/src/lowering.md index c3a1a96cc..e0dc99bab 100644 --- a/src/lowering.md +++ b/src/lowering.md @@ -18,7 +18,7 @@ of such structures include but are not limited to * Converted to a virtual `existential type` declaration Lowering needs to uphold several invariants in order to not trigger the -sanity checks in `src/librustc/hir/map/hir_id_validator.rs`: +sanity checks in `src/librustc_middle/hir/map/hir_id_validator.rs`: 1. A `HirId` must be used if created. So if you use the `lower_node_id`, you *must* use the resulting `NodeId` or `HirId` (either is fine, since diff --git a/src/macro-expansion.md b/src/macro-expansion.md index db58733ad..279598270 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -383,7 +383,7 @@ implementation of macro_rules, turns macro_rules DSL into something with signature Fn(TokenStream) -> TokenStream that can eat and produce tokens, @mark-i-m knows more about this librustc_resolve/macros.rs - resolving macro paths, validating those resolutions, reporting various "not found"/"found, but -it's unstable"/"expected x, found y" errors librustc/hir/map/def_collector.rs + +it's unstable"/"expected x, found y" errors librustc_middle/hir/map/def_collector.rs + librustc_resolve/build_reduced_graph.rs - integrate an AST fragment freshly expanded from a macro into various parent/child structures like module hierarchy or "definition paths" diff --git a/src/memory.md b/src/memory.md index bfec4fe19..533d1337e 100644 --- a/src/memory.md +++ b/src/memory.md @@ -16,8 +16,8 @@ types for equality: for each interned type `X`, we implemented [`PartialEq for X`][peqimpl], so we can just compare pointers. The [`CtxtInterners`] type contains a bunch of maps of interned types and the arena itself. -[peqimpl]: https://github.com/rust-lang/rust/blob/3ee936378662bd2e74be951d6a7011a95a6bd84d/src/librustc/ty/mod.rs#L528-L534 -[`CtxtInterners`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.CtxtInterners.html#structfield.arena +[peqimpl]: https://github.com/rust-lang/rust/blob/3ee936378662bd2e74be951d6a7011a95a6bd84d/src/librustc_middle/ty/mod.rs#L528-L534 +[`CtxtInterners`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.CtxtInterners.html#structfield.arena ### Example: `ty::TyS` @@ -49,10 +49,10 @@ allocate, and which are found in this module. Here are a few examples: - [`Predicate`] defines something the trait system has to prove (see `traits` module). [subst]: ./generic_arguments.html#subst -[`TraitRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TraitRef.html -[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.Predicate.html +[`TraitRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html +[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.Predicate.html -[`ty::TyS`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html +[`ty::TyS`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyS.html ## The tcx and how it uses lifetimes @@ -85,4 +85,4 @@ duplication while also preventing a lot of the ergonomic issues due to many pervasive lifetimes. The [`rustc::ty::tls`][tls] module is used to access these thread-locals, although you should rarely need to touch it. -[tls]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/tls/index.html +[tls]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/tls/index.html diff --git a/src/mir/index.md b/src/mir/index.md index dbc2a316f..99396903c 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -15,7 +15,7 @@ graphs and desugaring), you may enjoy the ## Introduction to MIR -MIR is defined in the [`src/librustc/mir/`][mir] module, but much of the code +MIR is defined in the [`src/librustc_middle/mir/`][mir] module, but much of the code that manipulates it is found in [`src/librustc_mir`][mirmanip]. [RFC 1211]: https://rust-lang.github.io/rfcs/1211-mir.html @@ -212,7 +212,7 @@ over the overflow checks.) ## MIR data types -The MIR data types are defined in the [`src/librustc/mir/`][mir] +The MIR data types are defined in the [`src/librustc_middle/mir/`][mir] module. Each of the key concepts mentioned in the previous section maps in a fairly straightforward way to a Rust type. @@ -253,7 +253,7 @@ but [you can read about those below](#promoted)). *to be written* -[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir +[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/mir [mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir -[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir +[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/mir [newtype'd]: ../appendix/glossary.html diff --git a/src/mir/visitor.md b/src/mir/visitor.md index a5e8e9a0b..a0d38ca0b 100644 --- a/src/mir/visitor.md +++ b/src/mir/visitor.md @@ -7,7 +7,7 @@ them, generated via a single macro: `Visitor` (which operates on a `&Mir` and gives back shared references) and `MutVisitor` (which operates on a `&mut Mir` and gives back mutable references). -[m-v]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/visit/index.html +[m-v]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/visit/index.html To implement a visitor, you have to create a type that represents your visitor. Typically, this type wants to "hang on" to whatever @@ -50,6 +50,6 @@ contains useful functions for walking the MIR CFG in [different standard orders][traversal] (e.g. pre-order, reverse post-order, and so forth). -[t]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/traversal/index.html +[t]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/traversal/index.html [traversal]: https://en.wikipedia.org/wiki/Tree_traversal diff --git a/src/miri.md b/src/miri.md index 1f11633a7..16f2a18f2 100644 --- a/src/miri.md +++ b/src/miri.md @@ -95,14 +95,14 @@ Miri, but just use the cached result. [`Operand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.Operand.html [`Immediate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.Immediate.html -[`ConstValue`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.ConstValue.html -[`Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.Scalar.html +[`ConstValue`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.ConstValue.html +[`Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.Scalar.html [`op_to_const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/eval_queries/fn.op_to_const.html ## Datastructures Miri's outside-facing datastructures can be found in -[librustc/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc/mir/interpret). +[librustc_middle/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc_middle/mir/interpret). This is mainly the error enum and the [`ConstValue`] and [`Scalar`] types. A `ConstValue` can be either `Scalar` (a single `Scalar`, i.e., integer or thin pointer), `Slice` (to represent byte slices and strings, as needed for pattern @@ -177,9 +177,9 @@ needed to support circular statics, where we need to have a `Pointer` to a bytes of its value. [`Memory`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Memory.html -[`Allocation`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/struct.Allocation.html -[`Pointer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/struct.Pointer.html -[`GlobalAlloc`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/mir/interpret/enum.GlobalAlloc.html +[`Allocation`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.Allocation.html +[`Pointer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.Pointer.html +[`GlobalAlloc`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.GlobalAlloc.html ### Pointer values vs Pointer types diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 497c81fd0..549a9cd05 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -24,7 +24,7 @@ unsafe { panic_impl(&pi) } Actually resolving this goes through several layers of indirection: -1. In `src/librustc/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item', +1. In `src/librustc_middle/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item', with the symbol `rust_begin_unwind`. This is used in `librustc_typeck/collect.rs` to set the actual symbol name to `rust_begin_unwind`. @@ -44,7 +44,7 @@ pub fn begin_panic_handler(info: &PanicInfo<'_>) -> ! { } ``` -The special `panic_handler` attribute is resolved via `src/librustc/middle/lang_items`. +The special `panic_handler` attribute is resolved via `src/librustc_middle/middle/lang_items`. The `extract` function converts the `panic_handler` attribute to a `panic_impl` lang item. Now, we have a matching `panic_handler` lang item in the `libstd`. This function goes diff --git a/src/param_env.md b/src/param_env.md index 9ca117b31..aa6d6e215 100644 --- a/src/param_env.md +++ b/src/param_env.md @@ -8,7 +8,7 @@ type's `Layout`, but you can do all kinds of other checks on it (e.g. whether a type implements `Copy`) or you can evaluate an associated constant whose value does not depend on anything from the parameter environment. -[pe]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html +[pe]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html For example if you have a function @@ -65,5 +65,5 @@ method. This will produce a [`ParamEnvAnd`][pea], making clear that you should probably not be using the inner value without taking care to also use the [`ParamEnv`][pe]. -[and]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnv.html#method.and -[pea]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.ParamEnvAnd.html +[and]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html#method.and +[pea]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnvAnd.html diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index 505dde1a8..a41becfd0 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -175,7 +175,7 @@ fn try_mark_green(tcx, current_node) -> bool { } // Note: The actual implementation can be found in -// src/librustc/dep_graph/graph.rs +// src/librustc_middle/dep_graph/graph.rs ``` By using red-green marking we can avoid the devastating cumulative effect of diff --git a/src/queries/incremental-compilation.md b/src/queries/incremental-compilation.md index bed21f115..be8580f2d 100644 --- a/src/queries/incremental-compilation.md +++ b/src/queries/incremental-compilation.md @@ -81,7 +81,7 @@ Try-mark-green works as follows: ### The query DAG The query DAG code is stored in -[`src/librustc/dep_graph`][dep_graph]. Construction of the DAG is done +[`src/librustc_middle/dep_graph`][dep_graph]. Construction of the DAG is done by instrumenting the query execution. One key point is that the query DAG also tracks ordering; that is, for @@ -113,7 +113,7 @@ of order, however, it might visit `subquery2` before `subquery1`, and hence execute it. This can lead to ICEs and other problems in the compiler. -[dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc/dep_graph +[dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/dep_graph ## Improvements to the basic algorithm diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 156fd65a9..37b1bc97b 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -259,7 +259,7 @@ We give some background about the query model of the Rust compiler. In the query model, many queries have a key that consists of a Def ID. The Rust compiler uses Def IDs to distinguish definitions in the input Rust program. -From the compiler source code (`src/librustc/hir/def_id.rs`): +From the compiler source code (`src/librustc_middle/hir/def_id.rs`): ``` /// A DefId identifies a particular *definition*, by combining a crate diff --git a/src/query.md b/src/query.md index 9ae6baa9e..5a739dca9 100644 --- a/src/query.md +++ b/src/query.md @@ -99,7 +99,7 @@ When the tcx is created, it is given the providers by its creator using the [`Providers`][providers_struct] struct. This struct is generated by the macros here, but it is basically a big list of function pointers: -[providers_struct]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/struct.Providers.html +[providers_struct]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/struct.Providers.html ```rust,ignore struct Providers { @@ -118,7 +118,7 @@ throughout the other `rustc_*` crates. This is done by invoking various [`provide`][provide_fn] functions. These functions tend to look something like this: -[provide_fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/fn.provide.html +[provide_fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/fn.provide.html ```rust,ignore pub fn provide(providers: &mut Providers) { @@ -172,9 +172,9 @@ Well, defining a query takes place in two steps: To specify the query name and arguments, you simply add an entry to the big macro invocation in -[`src/librustc/query/mod.rs`][query-mod], which looks something like: +[`src/librustc_middle/query/mod.rs`][query-mod], which looks something like: -[query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/query/index.html +[query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/index.html ```rust,ignore rustc_queries! { @@ -225,7 +225,7 @@ Let's go over them one by one: - **Query modifiers:** various flags and options that customize how the query is processed. -[Key]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/keys/trait.Key.html +[Key]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/keys/trait.Key.html So, to add a query: @@ -263,8 +263,8 @@ Implementing this trait is optional if the query key is `DefId`, but if you *don't* implement it, you get a pretty generic error ("processing `foo`..."). You can put new impls into the `config` module. They look something like this: -[QueryConfig]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/trait.QueryConfig.html -[QueryDescription]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/query/config/trait.QueryDescription.html +[QueryConfig]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/trait.QueryConfig.html +[QueryDescription]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/config/trait.QueryDescription.html ```rust,ignore impl<'tcx> QueryDescription for queries::type_of<'tcx> { diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 90a88b3d6..6a2e87f4d 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -42,7 +42,7 @@ replaces this functionality. [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/ [`Compiler`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html [`Session`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html -[`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html +[`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html [`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html [stupid-stats]: https://github.com/nrc/stupid-stats [Appendix A]: appendix/stupid-stats.html diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md index d35fb71e1..41ce5ac9e 100644 --- a/src/traits/associated-types.md +++ b/src/traits/associated-types.md @@ -94,12 +94,12 @@ They are used internally by the trait system only, as we will see shortly. In rustc, they correspond to the `TyKind::UnnormalizedProjectionTy` enum -variant, declared in [`librustc/ty/sty.rs`][sty]. In chalk, we use an +variant, declared in [`librustc_middle/ty/sty.rs`][sty]. In chalk, we use an `ApplicationTy` with a name living in a special namespace dedicated to placeholder associated types (see the `TypeName` enum declared in [`chalk-ir/src/lib.rs`][chalk_type_name]). -[sty]: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/sty.rs +[sty]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/ty/sty.rs [chalk_type_name]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-ir/src/lib.rs ## Projection equality diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index a653528f4..5aba1c20f 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -38,11 +38,11 @@ paper gives the details. In terms of code, these types are defined in -[`librustc/traits/mod.rs`][traits_mod] in rustc, and in +[`librustc_middle/traits/mod.rs`][traits_mod] in rustc, and in [`chalk-ir/src/lib.rs`][chalk_ir] in chalk. [pphhf]: ./bibliography.html#pphhf -[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc/traits/mod.rs +[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs [chalk_ir]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-ir/src/lib.rs diff --git a/src/ty-fold.md b/src/ty-fold.md index e144767dc..f769ee638 100644 --- a/src/ty-fold.md +++ b/src/ty-fold.md @@ -6,9 +6,9 @@ on a type like we did with `Vec` above. But we might also have a more complex ty nested inside that also need substitutions. The answer is a couple of traits: -[`TypeFoldable`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFoldable.html) +[`TypeFoldable`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/fold/trait.TypeFoldable.html) and -[`TypeFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html). +[`TypeFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/fold/trait.TypeFolder.html). - `TypeFoldable` is implemented by types that embed type information. It allows you to recursively process the contents of the `TypeFoldable` and do stuff to them. @@ -16,7 +16,7 @@ and `TypeFoldable`. For example, the `TypeFolder` trait has a method -[`fold_ty`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/fold/trait.TypeFolder.html#method.fold_ty) +[`fold_ty`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/fold/trait.TypeFolder.html#method.fold_ty) that takes a type as input a type and returns a new type as a result. `TypeFoldable` invokes the `TypeFolder` `fold_foo` methods on itself, giving the `TypeFolder` access to its contents (the types, regions, etc that are contained within). @@ -35,7 +35,7 @@ So to reiterate: - `TypeFoldable` is a trait that is implemented by things that embed types. In the case of `subst`, we can see that it is implemented as a `TypeFolder`: -[`SubstFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/struct.SubstFolder.html). +[`SubstFolder`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/struct.SubstFolder.html). Looking at its implementation, we see where the actual substitutions are happening. However, you might also notice that the implementation calls this `super_fold_with` method. What is @@ -93,13 +93,13 @@ defined [here](https://github.com/rust-lang/rust/blob/master/src/librustc_macros/src/type_foldable.rs). **`subst`** In the case of substitutions the [actual -folder](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L467-L482) +folder](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc_middle/ty/subst.rs#L467-L482) is going to be doing the indexing we’ve already mentioned. There we define a `Folder` and call `fold_with` on the `TypeFoldable` to process yourself. Then -[fold_ty](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L545-L573) +[fold_ty](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc_middle/ty/subst.rs#L545-L573) the method that process each type it looks for a `ty::Param` and for those it replaces it for something from the list of substitutions, otherwise recursively process the type. To replace it, calls -[ty_for_param](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc/ty/subst.rs#L589-L624) +[ty_for_param](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc_middle/ty/subst.rs#L589-L624) and all that does is index into the list of substitutions with the index of the `Param`. diff --git a/src/ty.md b/src/ty.md index a4274bc9f..f8b15632b 100644 --- a/src/ty.md +++ b/src/ty.md @@ -12,13 +12,13 @@ The `ty` module defines how the Rust compiler represents types internally. It al When we talk about how rustc represents types, we usually refer to a type called `Ty` . There are quite a few modules and types for `Ty` in the compiler ([Ty documentation][ty]). -[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/index.html +[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html The specific `Ty` we are referring to is [`rustc::ty::Ty`][ty_ty] (and not [`rustc_hir::Ty`][hir_ty]). The distinction is important, so we will discuss it first before going into the details of `ty::Ty`. -[ty_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html +[ty_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html [hir_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Ty.html ## `rustc_hir::Ty` vs `ty::Ty` @@ -124,9 +124,9 @@ are [interned](./memory.md), so that the `ty::Ty` can be a thin pointer-like type. This allows us to do cheap comparisons for equality, along with the other benefits of interning. -[tys]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html -[kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyS.html#structfield.kind -[tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html +[tys]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyS.html +[kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyS.html#structfield.kind +[tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html ## Allocating and working with types @@ -150,7 +150,7 @@ allocate exactly the same type twice). You can also find various common types in the `tcx` itself by accessing `tcx.types.bool`, `tcx.types.char`, etc (see [`CommonTypes`] for more). -[`CommonTypes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/context/struct.CommonTypes.html +[`CommonTypes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.CommonTypes.html ## `ty::TyKind` Variants @@ -207,16 +207,16 @@ will discuss this more later. [**And Many More**...][kindvars] [wikiadt]: https://en.wikipedia.org/wiki/Algebraic_data_type -[kindadt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Adt -[kindforeign]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Foreign -[kindstr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Str -[kindslice]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Slice -[kindarray]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Array -[kindrawptr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.RawPtr -[kindref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Ref -[kindparam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Param -[kinderr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variant.Error -[kindvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html#variants +[kindadt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Adt +[kindforeign]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Foreign +[kindstr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Str +[kindslice]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Slice +[kindarray]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Array +[kindrawptr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.RawPtr +[kindref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Ref +[kindparam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Param +[kinderr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Error +[kindvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variants ## Import conventions @@ -259,8 +259,8 @@ There are two parts: generic parameters. In our example of `MyStruct`, we would end up with a list like `[u32]`. We’ll dig more into generics and substitutions in a little bit. -[adtdef]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.AdtDef.html -[substsref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/subst/type.SubstsRef.html +[adtdef]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.AdtDef.html +[substsref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/subst/type.SubstsRef.html **`AdtDef` and `DefId`** @@ -275,7 +275,7 @@ essentially a one-to-one relationship between `AdtDef` and `DefId`. You can get `DefId` with the [`tcx.adt_def(def_id)` query][adtdefq]. The `AdtDef`s are all interned (as you can see `'tcx` lifetime on it). -[adtdefq]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html#method.adt_def +[adtdefq]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.adt_def ## Type errors From 6b25ed275349b22e965d19ef66983a4e2441235f Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 30 Mar 2020 17:45:31 +0200 Subject: [PATCH 0871/1812] QueryDescription has moved --- src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/query.md b/src/query.md index 5a739dca9..e008cb628 100644 --- a/src/query.md +++ b/src/query.md @@ -264,7 +264,7 @@ if you *don't* implement it, you get a pretty generic error ("processing `foo`.. You can put new impls into the `config` module. They look something like this: [QueryConfig]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/trait.QueryConfig.html -[QueryDescription]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/config/trait.QueryDescription.html +[QueryDescription]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_query_system/query/config/trait.QueryDescription.html ```rust,ignore impl<'tcx> QueryDescription for queries::type_of<'tcx> { From 518da21a477bca987d4df664d019d4d112ce69a5 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 31 Mar 2020 15:20:55 -0500 Subject: [PATCH 0872/1812] fix a few more links --- src/bug-fix-procedure.md | 10 ++++++---- src/memory.md | 2 +- src/ty-fold.md | 6 +++--- 3 files changed, 10 insertions(+), 8 deletions(-) diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md index e29ad26e0..b4159097c 100644 --- a/src/bug-fix-procedure.md +++ b/src/bug-fix-procedure.md @@ -120,7 +120,7 @@ future-compatibility warnings. These are a special category of lint warning. Adding a new future-compatibility warning can be done as follows. ```rust -// 1. Define the lint in `src/librustc_middle/lint/builtin.rs`: +// 1. Define the lint in `src/librustc/lint/builtin.rs`: declare_lint! { pub YOUR_ERROR_HERE, Warn, @@ -230,12 +230,14 @@ lint name is mentioned (in the compiler, we use the upper-case name, and a macro automatically generates the lower-case string; so searching for `overlapping_inherent_impls` would not find much). +> NOTE: these exact files don't exist anymore, but the procedure is still the same. + #### Remove the lint. The first reference you will likely find is the lint definition [in -`librustc_middle/lint/builtin.rs` that resembles this][defsource]: +`librustc/lint/builtin.rs` that resembles this][defsource]: -[defsource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc_middle/lint/builtin.rs#L171-L175 +[defsource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L171-L175 ```rust declare_lint! { @@ -249,7 +251,7 @@ This `declare_lint!` macro creates the relevant data structures. Remove it. You will also find that there is a mention of `OVERLAPPING_INHERENT_IMPLS` later in the file as [part of a `lint_array!`][lintarraysource]; remove it too, -[lintarraysource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc_middle/lint/builtin.rs#L252-L290 +[lintarraysource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L252-L290 Next, you see see [a reference to `OVERLAPPING_INHERENT_IMPLS` in `librustc_lint/lib.rs`][futuresource]. This defining the lint as a "future diff --git a/src/memory.md b/src/memory.md index 533d1337e..620b7d858 100644 --- a/src/memory.md +++ b/src/memory.md @@ -16,7 +16,7 @@ types for equality: for each interned type `X`, we implemented [`PartialEq for X`][peqimpl], so we can just compare pointers. The [`CtxtInterners`] type contains a bunch of maps of interned types and the arena itself. -[peqimpl]: https://github.com/rust-lang/rust/blob/3ee936378662bd2e74be951d6a7011a95a6bd84d/src/librustc_middle/ty/mod.rs#L528-L534 +[peqimpl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyS.html#implementations [`CtxtInterners`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.CtxtInterners.html#structfield.arena ### Example: `ty::TyS` diff --git a/src/ty-fold.md b/src/ty-fold.md index f769ee638..5b409e8ec 100644 --- a/src/ty-fold.md +++ b/src/ty-fold.md @@ -93,13 +93,13 @@ defined [here](https://github.com/rust-lang/rust/blob/master/src/librustc_macros/src/type_foldable.rs). **`subst`** In the case of substitutions the [actual -folder](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc_middle/ty/subst.rs#L467-L482) +folder](https://github.com/rust-lang/rust/blob/75ff3110ac6d8a0259023b83fd20d7ab295f8dd6/src/librustc_middle/ty/subst.rs#L440-L451) is going to be doing the indexing we’ve already mentioned. There we define a `Folder` and call `fold_with` on the `TypeFoldable` to process yourself. Then -[fold_ty](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc_middle/ty/subst.rs#L545-L573) +[fold_ty](https://github.com/rust-lang/rust/blob/75ff3110ac6d8a0259023b83fd20d7ab295f8dd6/src/librustc_middle/ty/subst.rs#L512-L536) the method that process each type it looks for a `ty::Param` and for those it replaces it for something from the list of substitutions, otherwise recursively process the type. To replace it, calls -[ty_for_param](https://github.com/rust-lang/rust/blob/04e69e4f4234beb4f12cc76dcc53e2cc4247a9be/src/librustc_middle/ty/subst.rs#L589-L624) +[ty_for_param](https://github.com/rust-lang/rust/blob/75ff3110ac6d8a0259023b83fd20d7ab295f8dd6/src/librustc_middle/ty/subst.rs#L552-L587) and all that does is index into the list of substitutions with the index of the `Param`. From 595f2f386c67d0ef3719c6b71c84de2069662c8c Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 31 Mar 2020 15:30:27 -0500 Subject: [PATCH 0873/1812] and a few more links --- src/appendix/stupid-stats.md | 6 +++--- src/compiler-team.md | 5 ++--- src/tests/intro.md | 2 +- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md index 7453f4424..a07956f0f 100644 --- a/src/appendix/stupid-stats.md +++ b/src/appendix/stupid-stats.md @@ -17,7 +17,7 @@ complex make project or Cargo build, etc. That could be a lot of work; rustc, like most compilers, takes a large number of command line arguments which can affect compilation in complex and interacting ways. Emulating all of this behaviour in your tool is annoying at best, especically if you are making many -of the same calls into librustc that the compiler is. +of the same calls into librustc_middle that the compiler is. The kind of things I have in mind are tools like rustdoc or a future rustfmt. These want to operate as closely as possible to real compilation, but have @@ -27,7 +27,7 @@ custom code generation phase after macro expansion, then creating a new tool should be easier than forking the compiler (and keeping it up to date as the compiler evolves). -I have gradually been trying to improve the API of librustc to make creating a +I have gradually been trying to improve the API of librustc_middle to make creating a drop-in tool easier to produce (many others have also helped improve these interfaces over the same time frame). It is now pretty simple to make a tool which is as close to rustc as you want it to be. In this tutorial I'll show @@ -73,7 +73,7 @@ checking, borrow checking, type and lifetime inference, trait selection, method selection, linting, and so forth. Most error detection is done in this phase (although parse errors are found during parsing). The 'output' of this phase is a bunch of side tables containing semantic information about the source program. -The analysis code is in [librustc](https://github.com/rust-lang/rust/tree/master/src/librustc) +The analysis code is in [librustc_middle](https://github.com/rust-lang/rust/tree/master/src/librustc_middle) and a bunch of other crates with the 'librustc_' prefix. Next is translation, this translates the AST (and all those side tables) into diff --git a/src/compiler-team.md b/src/compiler-team.md index 42f6cc0ac..3f3719f3d 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -36,8 +36,7 @@ They are held on [Zulip][zulip]. It works roughly as follows: - **Look over new regressions:** we then look for new cases where the compiler broke previously working code in the wild. Regressions are almost always marked as P-high; the major exception would be bug - fixes (though even there we often - [aim to give warnings first][procedure]). + fixes (though even there we often [aim to give warnings first][procedure]). - **Check I-nominated issues:** These are issues where feedback from the team is desired. - **Check for beta nominations:** These are nominations of things to @@ -52,7 +51,7 @@ complicated). The meeting is held over a "chat medium", currently on [zulip]. [etherpad]: https://public.etherpad-mozilla.org/p/rust-compiler-meeting -[procedure]: https://forge.rust-lang.org/rustc-bug-fix-procedure.html +[procedure]: ./bug-fix-procedure.md [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler ## Team membership diff --git a/src/tests/intro.md b/src/tests/intro.md index b70a23a6a..b47a9fdee 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -129,7 +129,7 @@ Rust's [platform tiers]). [Azure Pipelines]: https://dev.azure.com/rust-lang/rust/ [bors]: https://github.com/servo/homu [queue]: https://buildbot2.rust-lang.org/homu/queue/rust -[platform tiers]: https://forge.rust-lang.org/platform-support.html +[platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support ## Testing with Docker images From 20fe7df2aaa39263f9aab74d7f38b9ca0527d7ab Mon Sep 17 00:00:00 2001 From: Adam Perry Date: Tue, 14 Jan 2020 21:38:29 -0800 Subject: [PATCH 0874/1812] Implicit Caller Location section. --- src/SUMMARY.md | 1 + src/codegen/implicit-caller-location.md | 280 ++++++++++++++++++++++++ 2 files changed, 281 insertions(+) create mode 100644 src/codegen/implicit-caller-location.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 722bcedc6..b0bf1966d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -109,6 +109,7 @@ - [Updating LLVM](./backend/updating-llvm.md) - [Debugging LLVM](./backend/debugging.md) - [Backend Agnostic Codegen](./backend/backend-agnostic.md) + - [Implicit Caller Location](./codegen/implicit-caller-location.md) - [Profile-guided Optimization](./profile-guided-optimization.md) - [Sanitizers Support](./sanitizers.md) - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) diff --git a/src/codegen/implicit-caller-location.md b/src/codegen/implicit-caller-location.md new file mode 100644 index 000000000..4cb3f583d --- /dev/null +++ b/src/codegen/implicit-caller-location.md @@ -0,0 +1,280 @@ +# Implicit Caller Location + +Approved in [RFC 2091], this feature enables the accurate reporting of caller location during panics +initiated from functions like `Option::unwrap`, `Result::expect`, and `Index::index`. This feature +adds the [`#[track_caller]`][attr-reference] attribute for functions, the +[`caller_location`][intrinsic] intrinsic, and the stabilization-friendly +[`core::panic::Location::caller`][wrapper] wrapper. + +## Motivating Example + +Take this example program: + +```rust +fn main() { + let foo: Option<()> = None; + foo.unwrap(); // this should produce a useful panic message! +} +``` + +Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore: + +``` +$ rustc +1.41.0 example.rs; example.exe +thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',...core\macros\mod.rs:15:40 +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. +``` + +As of 1.42, we get a much more helpful message: + +``` +$ rustc +1.42.0 example.rs; example.exe +thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5 +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace +``` + +These error messages are achieved through a combination of changes to `panic!` internals to make use +of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard +library which propagate caller information. + +## Reading Caller Location + +Previously, `panic!` made use of the `file!()`, `line!()`, and `column!()` macros to construct a +[`Location`] pointing to where the panic occurred. These macros couldn't be given an overridden +location, so functions which intentionally invoked `panic!` couldn't provide their own location, +hiding the actual source of error. + +Internally, `panic!()` now calls [`core::panic::Location::caller()`][wrapper] to find out where it +was expanded. This function is itself annotated with `#[track_caller]` and wraps the +[`caller_location`][intrinsic] compiler intrinsic implemented by rustc. This intrinsic is easiest +explained in terms of how it works in a `const` context. + +## Caller Location in `const` + +There are two main phases to returning the caller location in a const context: walking up the stack +to find the right location and allocating a const value to return. + +### Finding the right `Location` + +In a const context we "walk up the stack" from where the intrinsic is invoked, stopping when we +reach the first function call in the stack which does *not* have the attribute. This walk is in +[`InterpCx::find_closest_untracked_caller_location()`][const-find-closest]. + +Starting at the bottom, we iterate up over stack [`Frame`][const-frame]s in the +[`InterpCx::stack`][const-stack], calling +[`InstanceDef::requires_caller_location`][requires-location] on the +[`Instance`s from each `Frame`][frame-instance]. We stop once we find one that returns `false` and +return the span of the *previous* frame which was the "topmost" tracked function. + +### Allocating a static `Location` + +Once we have a `Span`, we need to allocate static memory for the `Location`, which is performed by +the [`TyCtxt::const_caller_location()`][const-location-query] query. Internally this calls +[`InterpCx::alloc_caller_location()`][alloc-location] and results in a unique +[memory kind][location-memory-kind] (`MemoryKind::CallerLocation`). The SSA codegen backend is able +to emit code for these same values, and we use this code there as well. + +Once our `Location` has been allocated in static memory, our intrinsic returns a reference to it. + +## Generating code for `#[track_caller]` callees + +To generate efficient code for a tracked function and its callers, we need to provide the same +behavior from the intrinsic's point of view without having a stack to walk up at runtime. We invert +the approach: as we grow the stack down we pass an additional argument to calls of tracked functions +rather than walking up the stack when the intrinsic is called. That additional argument can be +returned wherever the caller location is queried. + +The argument we append is of type `&'static core::panic::Location<'staic>`. A reference was chosen +to avoid unnecessary copying because a pointer is a third the size of +`std::mem::size_of::() == 24` at time of writing. + +When generating a call to a function which is tracked, we pass the location argument the value of +[`FunctionCx::get_caller_location`][fcx-get]. + +If the calling function is tracked, `get_caller_location` returns the local in +[`FunctionCx::caller_location`][fcx-location] which was populated by the current caller's caller. +In these cases the intrinsic "returns" a reference which was actually provided in an argument to its +caller. + +If the calling function is not tracked, `get_caller_location` allocates a `Location` static from +the current `Span` and returns a reference to that. + +We more efficiently achieve the same behavior as a loop starting from the bottom by passing a single +`&Location` value through the `caller_location` fields of multiple `FunctionCx`s as we grow the +stack downward. + +### Codegen examples + +What does this transformation look like in practice? Take this example which uses the new feature: + +```rust +#![feature(track_caller)] +use std::panic::Location; + +#[track_caller] +fn print_caller() { + println!("called from {}", Location::caller()); +} + +fn main() { + print_caller(); +} +``` + +Here `print_caller()` appears to take no arguments, but we compile it to something like this: + +```rust +#![feature(panic_internals)] +use std::panic::Location; + +fn print_caller(caller: &Location) { + println!("called from {}", caller); +} + +fn main() { + print_caller(&Location::internal_constructor(file!(), line!(), column!())); +} +``` + +### Dynamic Dispatch + +In codegen contexts we have to modify the callee ABI to pass this information down the stack, but +the attribute expressly does *not* modify the type of the function. The ABI change must be +transparent to type checking and remain sound in all uses. + +Direct calls to tracked functions will always know the full codegen flags for the callee and can +generate appropriate code. Indirect callers won't have this information and it's not encoded in +the type of the function pointer they call, so we generate a [`ReifyShim`] around the function +whenever taking a pointer to it. This shim isn't able to report the actual location of the indirect +call (the function's definition site is reported instead), but it prevents miscompilation and is +probably the best we can do without modifying fully-stabilized type signatures. + +> *Note:* We always emit a [`ReifyShim`] when taking a pointer to a tracked function. While the +> constraint here is imposed by codegen contexts, we don't know during MIR construction of the shim +> whether we'll be called in a const context (safe to ignore shim) or in a codegen context (unsafe +> to ignore shim). Even if we did know, the results from const and codegen contexts must agree. + +## The Attribute + +The `#[track_caller]` attribute is checked alongside other codegen attributes to ensure the +function: + +* has the `"Rust"` ABI (as opposed to e.g., `"C"`) +* is not a foreign import (e.g., in an `extern {...}` block) +* is not a closure +* is not `#[naked]` + +If the use is valid, we set [`CodegenFnAttrsFlags::TRACK_CALLER`][attrs-flags]. This flag influences +the return value of [`InstanceDef::requires_caller_location`][requires-location] which is in turn +used in both const and codegen contexts to ensure correct propagation. + +### Traits + +When applied to trait method implementations, the attribute works as it does for regular functions. + +When applied to a trait method prototype, the attribute applies to all implementations of the +method. When applied to a default trait method implementation, the attribute takes effect on +that implementation *and* any overrides. + +Examples: + +```rust +#![feature(track_caller)] + +macro_rules! assert_tracked { + () => {{ + let location = std::panic::Location::caller(); + assert_eq!(location.file(), file!()); + assert_ne!(location.line(), line!(), "line should be outside this fn"); + println!("called at {}", location); + }}; +} + +trait TrackedFourWays { + /// All implementations inherit `#[track_caller]`. + #[track_caller] + fn blanket_tracked(); + + /// Implementors can annotate themselves. + fn local_tracked(); + + /// This implementation is tracked (overrides are too). + #[track_caller] + fn default_tracked() { + assert_tracked!(); + } + + /// Overrides of this implementation are tracked (it is too). + #[track_caller] + fn default_tracked_to_override() { + assert_tracked!(); + } +} + +/// This impl uses the default impl for `default_tracked` and provides its own for +/// `default_tracked_to_override`. +impl TrackedFourWays for () { + fn blanket_tracked() { + assert_tracked!(); + } + + #[track_caller] + fn local_tracked() { + assert_tracked!(); + } + + fn default_tracked_to_override() { + assert_tracked!(); + } +} + +fn main() { + <() as TrackedFourWays>::blanket_tracked(); + <() as TrackedFourWays>::default_tracked(); + <() as TrackedFourWays>::default_tracked_to_override(); + <() as TrackedFourWays>::local_tracked(); +} +``` + +## Background/History + +Broadly speaking, this feature's goal is to improve common Rust error messages without breaking +stability guarantees, requiring modifications to end-user source, relying on platform-specific +debug-info, or preventing user-defined types from having the same error-reporting benefits. + +Improving the output of these panics has been a goal of proposals since at least mid-2016 (see +[non-viable alternatives] in the approved RFC for details). It took two more years until RFC 2091 +was approved, much of its [rationale] for this feature's design having been discovered through the +discussion around several earlier proposals. + +The design in the original RFC limited itself to implementations that could be done inside the +compiler at the time without significant refactoring. However in the year and a half between the +approval of the RFC and the actual implementation work, a [revised design] was proposed and written +up on the tracking issue. During the course of implementing that, it was also discovered that an +implementation was possible without modifying the number of arguments in a function's MIR, which +would simplify later stages and unlock use in traits. + +Because the RFC's implementation strategy could not readily support traits, the semantics were not +originally specified. They have since been implemented following the path which seemed most correct +to the author and reviewers. + +[RFC 2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md +[attr-reference]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-track_caller-attribute +[intrinsic]: https://doc.rust-lang.org/nightly/core/intrinsics/fn.caller_location.html +[wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller +[non-viable alternatives]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#non-viable-alternatives +[rationale]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#rationale +[revised design]: https://github.com/rust-lang/rust/issues/47809#issuecomment-443538059 +[attrs-flags]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/middle/codegen_fn_attrs/struct.CodegenFnAttrFlags.html#associatedconstant.TRACK_CALLER +[`ReifyShim`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.InstanceDef.html#variant.ReifyShim +[`Location`]: https://doc.rust-lang.org/core/panic/struct.Location.html +[const-find-closest]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#method.find_closest_untracked_caller_location +[requires-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.InstanceDef.html#method.requires_caller_location +[alloc-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#method.alloc_caller_location +[fcx-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#structfield.caller_location +[const-location-query]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html#method.const_caller_location +[location-memory-kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.MemoryKind.html#variant.CallerLocation +[const-frame]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Frame.html +[const-stack]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#structfield.stack +[fcx-get]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#method.get_caller_location +[frame-instance]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Frame.html#structfield.instance From f38f17c9d789b41b920ad69e9ab7ef5bc1ee8a3d Mon Sep 17 00:00:00 2001 From: Adam Perry Date: Tue, 31 Mar 2020 19:21:37 -0700 Subject: [PATCH 0875/1812] fix broken links --- src/codegen/implicit-caller-location.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/codegen/implicit-caller-location.md b/src/codegen/implicit-caller-location.md index 4cb3f583d..5f11dad30 100644 --- a/src/codegen/implicit-caller-location.md +++ b/src/codegen/implicit-caller-location.md @@ -265,14 +265,14 @@ to the author and reviewers. [non-viable alternatives]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#non-viable-alternatives [rationale]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md#rationale [revised design]: https://github.com/rust-lang/rust/issues/47809#issuecomment-443538059 -[attrs-flags]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/middle/codegen_fn_attrs/struct.CodegenFnAttrFlags.html#associatedconstant.TRACK_CALLER -[`ReifyShim`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.InstanceDef.html#variant.ReifyShim +[attrs-flags]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/middle/codegen_fn_attrs/struct.CodegenFnAttrFlags.html#associatedconstant.TRACK_CALLER +[`ReifyShim`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.InstanceDef.html#variant.ReifyShim [`Location`]: https://doc.rust-lang.org/core/panic/struct.Location.html [const-find-closest]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#method.find_closest_untracked_caller_location -[requires-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.InstanceDef.html#method.requires_caller_location +[requires-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.InstanceDef.html#method.requires_caller_location [alloc-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#method.alloc_caller_location [fcx-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#structfield.caller_location -[const-location-query]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html#method.const_caller_location +[const-location-query]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.const_caller_location [location-memory-kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.MemoryKind.html#variant.CallerLocation [const-frame]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Frame.html [const-stack]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#structfield.stack From ce08bcc1e6c2c2975cb5b526f17498a78d3e6a0a Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 30 Mar 2020 18:55:36 +0200 Subject: [PATCH 0876/1812] point to new Cranelift home --- src/backend/backend-agnostic.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md index 0c501a2cc..209df0afa 100644 --- a/src/backend/backend-agnostic.md +++ b/src/backend/backend-agnostic.md @@ -1,10 +1,10 @@ # Backend Agnostic Codegen In the future, it would be nice to allow other codegen backends (e.g. -[Cranelift][cranelift]). To this end, `librustc_codegen_ssa` provides an +[Cranelift]). To this end, `librustc_codegen_ssa` provides an abstract interface for all backends to implenent. -[cranelift]: https://github.com/CraneStation/cranelift +[Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/master/cranelift > The following is a copy/paste of a README from the rust-lang/rust repo. > Please submit a PR if it needs updating. From d3f1ef2a87f1975ebc53bac7378820e7603344ed Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 30 Mar 2020 15:43:31 +0200 Subject: [PATCH 0877/1812] follow 4-space indent idiom --- src/test-implementation.md | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/src/test-implementation.md b/src/test-implementation.md index e5bcedf13..cffc62cec 100644 --- a/src/test-implementation.md +++ b/src/test-implementation.md @@ -5,7 +5,7 @@ you have to do is mark a function as a test and include some asserts like so: ```rust,ignore #[test] fn my_test() { - assert!(2+2 == 4); + assert!(2+2 == 4); } ``` @@ -16,14 +16,15 @@ can even put tests inside private modules: ```rust,ignore mod my_priv_mod { - fn my_priv_func() -> bool {} + fn my_priv_func() -> bool {} - #[test] - fn test_priv_func() { - assert!(my_priv_func()); - } + #[test] + fn test_priv_func() { + assert!(my_priv_func()); + } } ``` + Private items can thus be easily tested without worrying about how to expose them to any sort of external testing apparatus. This is key to the ergonomics of testing in Rust. Semantically, however, it's rather odd. @@ -44,15 +45,15 @@ the above example into: ```rust,ignore mod my_priv_mod { - fn my_priv_func() -> bool {} + fn my_priv_func() -> bool {} - pub fn test_priv_func() { - assert!(my_priv_func()); - } + pub fn test_priv_func() { + assert!(my_priv_func()); + } - pub mod __test_reexports { - pub use super::test_priv_func; - } + pub mod __test_reexports { + pub use super::test_priv_func; + } } ``` @@ -83,8 +84,8 @@ something with them. `librustc_ast` generates a module like so: ```rust,ignore #[main] pub fn main() { - extern crate test; - test::test_main_static(&[&path::to::test1, /*...*/]); + extern crate test; + test::test_main_static(&[&path::to::test1, /*...*/]); } ``` @@ -108,7 +109,7 @@ looks something like this: #[test] #[should_panic] fn foo() { - panic!("intentional"); + panic!("intentional"); } ``` From e2c733c48137dae3b2cd5f917e82f93458e87d36 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 30 Mar 2020 15:42:09 +0200 Subject: [PATCH 0878/1812] it is rustc_parse, not rustc_parser --- src/the-parser.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/the-parser.md b/src/the-parser.md index 8b8ef77cd..c84ac4ea2 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -25,7 +25,7 @@ macro-expansion). The parser is defined in [`librustc_parse`][librustc_parse], along with a high-level interface to the lexer and some validation routines that run after -macro expansion. In particular, the [`rustc_parser::parser`][parser] contains +macro expansion. In particular, the [`rustc_parse::parser`][parser] contains the parser implementation. The main entrypoint to the parser is via the various `parse_*` functions in the From af7286d2c845ba4eb31b2b07e72f4fbfa12c4ce8 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 1 Apr 2020 10:52:31 +0200 Subject: [PATCH 0879/1812] add some type inference links, and fix/improve some stuff (#654) --- src/type-inference.md | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/src/type-inference.md b/src/type-inference.md index dca93dbdf..9c548364d 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -149,7 +149,7 @@ To allow for this, the inference context supports a `snapshot` method. When you call it, it will start recording changes that occur from the operations you perform. When you are done, you can either invoke `rollback_to`, which will undo those changes, or else `confirm`, which -will make the permanent. Snapshots can be nested as long as you follow +will make them permanent. Snapshots can be nested as long as you follow a stack-like discipline. Rather than use snapshots directly, it is often helpful to use the @@ -200,7 +200,7 @@ idea: ``` (There are various other kinds of constraints, such as "verifys"; see -the `region_constraints` module for details.) +the [`region_constraints`] module for details.) There is one case where we do some amount of eager unification. If you have an equality constraint between two regions @@ -210,10 +210,13 @@ equality constraint between two regions ``` we will record that fact in a unification table. You can then use -`opportunistic_resolve_var` to convert `'b` to `'a` (or vice +[`opportunistic_resolve_var`] to convert `'b` to `'a` (or vice versa). This is sometimes needed to ensure termination of fixed-point algorithms. +[`region_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/region_constraints/index.html +[`opportunistic_resolve_var`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/region_constraints/struct.RegionConstraintCollector.html#method.opportunistic_resolve_var + ## Extracting region constraints Ultimately, region constraints are only solved at the very end of @@ -222,22 +225,27 @@ ways to solve region constraints right now: lexical and non-lexical. Eventually there will only be one. To solve **lexical** region constraints, you invoke -`resolve_regions_and_report_errors`. This "closes" the region -constraint process and invoke the `lexical_region_resolve` code. Once +[`resolve_regions_and_report_errors`]. This "closes" the region +constraint process and invokes the [`lexical_region_resolve`] code. Once this is done, any further attempt to equate or create a subtyping relationship will yield an ICE. Non-lexical region constraints are not handled within the inference context. Instead, the NLL solver (actually, the MIR type-checker) -invokes `take_and_reset_region_constraints` periodically. This +invokes [`take_and_reset_region_constraints`] periodically. This extracts all of the outlives constraints from the region solver, but leaves the set of variables intact. This is used to get *just* the region constraints that resulted from some particular point in the program, since the NLL solver needs to know not just *what* regions -were subregions but *where*. Finally, the NLL solver invokes -`take_region_var_origins`, which "closes" the region constraint +were subregions, but also *where*. Finally, the NLL solver invokes +[`take_region_var_origins`], which "closes" the region constraint process in the same way as normal solving. +[`resolve_regions_and_report_errors`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.resolve_regions_and_report_errors +[`lexical_region_resolve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/lexical_region_resolve/index.html +[`take_and_reset_region_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.take_and_reset_region_constraints +[`take_region_var_origins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.take_region_var_origins + ## Lexical region resolution Lexical region resolution is done by initially assigning each region From 498f7bd27995a87070fe29706a7cd026132da389 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 1 Apr 2020 10:57:35 +0200 Subject: [PATCH 0880/1812] add link for Resolver::resolve_crate (#653) --- src/name-resolution.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/name-resolution.md b/src/name-resolution.md index 6dfbd91a8..431a8f1d3 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -28,13 +28,15 @@ source to relevant places where the name was introduced. It also generates helpful error messages, like typo suggestions, traits to import or lints about unused items. -A successful run of the second phase (`Resolver::resolve_crate`) creates kind +A successful run of the second phase ([`Resolver::resolve_crate`]) creates kind of an index the rest of the compilation may use to ask about the present names (through the `hir::lowering::Resolver` interface). The name resolution lives in the `librustc_resolve` crate, with the meat in `lib.rs` and some helpers or symbol-type specific logic in the other modules. +[`Resolver::resolve_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Resolver.html#method.resolve_crate + ## Namespaces Different kind of symbols live in different namespaces ‒ e.g. types don't From 610d8e89d6fde6fdc3e799eedd419c6d71a5b16c Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 1 Apr 2020 11:04:45 +0200 Subject: [PATCH 0881/1812] Resolver trait moved (#652) --- src/name-resolution.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/name-resolution.md b/src/name-resolution.md index 431a8f1d3..f3aacba00 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -19,8 +19,8 @@ namespaces and therefore can co-exist. The name resolution in Rust is a two-phase process. In the first phase, which runs during macro expansion, we build a tree of modules and resolve imports. Macro -expansion and name resolution communicate with each other via the `Resolver` -trait, defined in `librustc_ast`. +expansion and name resolution communicate with each other via the +[`Resolver`] trait. The input to the second phase is the syntax tree, produced by parsing input files and expanding macros. This phase produces links from all the names in the @@ -36,6 +36,7 @@ The name resolution lives in the `librustc_resolve` crate, with the meat in `lib.rs` and some helpers or symbol-type specific logic in the other modules. [`Resolver::resolve_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Resolver.html#method.resolve_crate +[`Resolver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_lowering/trait.Resolver.html ## Namespaces From f212f322fb5c1630200b8e8fff4a52d256e086e4 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 1 Apr 2020 11:25:14 -0300 Subject: [PATCH 0882/1812] Remove left overs from HackMD migration (#655) --- src/ty.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/ty.md b/src/ty.md index f8b15632b..76e71584f 100644 --- a/src/ty.md +++ b/src/ty.md @@ -1,7 +1,3 @@ ---- -tags: rustc, ty ---- - # The `ty` module: representing types The `ty` module defines how the Rust compiler represents types internally. It also defines the From aee609b57ede8f9c872100df7cd24065ed3d6996 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 28 Mar 2020 14:32:09 -0700 Subject: [PATCH 0883/1812] How to get the type of an expression using rustc_interface --- src/SUMMARY.md | 1 + src/rustc-driver-interacting-with-the-ast.md | 41 ++++++++++++++++++++ 2 files changed, 42 insertions(+) create mode 100644 src/rustc-driver-interacting-with-the-ast.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b0bf1966d..1a0c9e9e4 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -37,6 +37,7 @@ - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver and Interface](./rustc-driver.md) - [Rustdoc](./rustdoc.md) + - [Interacting with the AST](./rustc-driver-interacting-with-the-ast.md) - [Queries: demand-driven compilation](./query.md) - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) - [Incremental compilation](./queries/incremental-compilation.md) diff --git a/src/rustc-driver-interacting-with-the-ast.md b/src/rustc-driver-interacting-with-the-ast.md new file mode 100644 index 000000000..faf0f1514 --- /dev/null +++ b/src/rustc-driver-interacting-with-the-ast.md @@ -0,0 +1,41 @@ +# Interacting with the AST + +`rustc_interface` allows you to interact with Rust code at various stages of compilation. + +## Getting the type of an expression + +To get the type of an expression, use the `global_ctxt` to get a `TyCtxt`: + +```rust +// In this example, config specifies the rust program: +// fn main() { let message = \"Hello, world!\"; println!(\"{}\", message); } +// Our goal is to get the type of the string literal "Hello, world!". +// +// See https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-example.rs for a complete example of configuring rustc_interface +rustc_interface::run_compiler(config, |compiler| { + compiler.enter(|queries| { + // Analyze the crate and inspect the types under the cursor. + queries.global_ctxt().unwrap().take().enter(|tcx| { + // Every compilation contains a single crate. + let krate = tcx.hir().krate(); + // Iterate over the top-level items in the crate, looking for the main function. + for (_, item) in &krate.items { + // Use pattern-matching to find a specific node inside the main function. + if let rustc_hir::ItemKind::Fn(_, _, body_id) = item.kind { + let expr = &tcx.hir().body(body_id).value; + if let rustc_hir::ExprKind::Block(block, _) = expr.kind { + if let rustc_hir::StmtKind::Local(local) = block.stmts[0].kind { + if let Some(expr) = local.init { + let hir_id = expr.hir_id; // hir_id identifies the string "Hello, world!" + let def_id = tcx.hir().local_def_id(item.hir_id); // def_id identifies the main function + let ty = tcx.typeck_tables_of(def_id).node_type(hir_id); + println!("{:?}: {:?}", expr, ty); // prints expr(HirId { owner: DefIndex(3), local_id: 4 }: "Hello, world!"): &'static str + } + } + } + } + } + }) + }); +}); +``` \ No newline at end of file From c27285e7075e647e4d876ca0c1da0b386c8fa27f Mon Sep 17 00:00:00 2001 From: George Fraser Date: Wed, 1 Apr 2020 10:53:26 -0700 Subject: [PATCH 0884/1812] Update src/rustc-driver-interacting-with-the-ast.md Co-Authored-By: Who? Me?! --- src/rustc-driver-interacting-with-the-ast.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rustc-driver-interacting-with-the-ast.md b/src/rustc-driver-interacting-with-the-ast.md index faf0f1514..51d5cb6d3 100644 --- a/src/rustc-driver-interacting-with-the-ast.md +++ b/src/rustc-driver-interacting-with-the-ast.md @@ -1,4 +1,4 @@ -# Interacting with the AST +# Example: Type checking through `rustc_interface` `rustc_interface` allows you to interact with Rust code at various stages of compilation. @@ -38,4 +38,4 @@ rustc_interface::run_compiler(config, |compiler| { }) }); }); -``` \ No newline at end of file +``` From d3cca657f305128019a42138cbf20d7ec6aab0c9 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Wed, 1 Apr 2020 17:10:58 -0700 Subject: [PATCH 0885/1812] Update src/SUMMARY.md Co-Authored-By: Who? Me?! --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 1a0c9e9e4..e7cb6ed60 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -37,7 +37,7 @@ - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver and Interface](./rustc-driver.md) - [Rustdoc](./rustdoc.md) - - [Interacting with the AST](./rustc-driver-interacting-with-the-ast.md) + - [Example: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) - [Queries: demand-driven compilation](./query.md) - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) - [Incremental compilation](./queries/incremental-compilation.md) From 8a1879a2793802a2598b165ca8c791809a094e00 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 1 Apr 2020 20:07:00 -0500 Subject: [PATCH 0886/1812] Shorten line --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index e7cb6ed60..d8e6f852f 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -37,7 +37,7 @@ - [High-level overview of the compiler source](./high-level-overview.md) - [The Rustc Driver and Interface](./rustc-driver.md) - [Rustdoc](./rustdoc.md) - - [Example: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) + - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) - [Queries: demand-driven compilation](./query.md) - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) - [Incremental compilation](./queries/incremental-compilation.md) From 27269235d3c5a7d2a254be50c567bb1c38a0fd5e Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 2 Apr 2020 13:40:15 -0300 Subject: [PATCH 0887/1812] Update some projects locations (#658) --- src/compiler-debugging.md | 4 ++-- src/conventions.md | 2 +- src/diagnostics.md | 2 +- src/profiling.md | 2 +- src/profiling/with_perf.md | 8 ++++---- src/tests/intro.md | 2 +- src/traits/goals-and-clauses.md | 2 +- 7 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 9358e0c15..89a763c41 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -261,8 +261,8 @@ until it finds the regression. You can then look at the PR to get more context on *why* it was changed. See [this tutorial][bisect-tutorial] on how to use it. -[bisect]: https://github.com/rust-lang-nursery/cargo-bisect-rustc -[bisect-tutorial]: https://github.com/rust-lang-nursery/cargo-bisect-rustc/blob/master/TUTORIAL.md +[bisect]: https://github.com/rust-lang/cargo-bisect-rustc +[bisect-tutorial]: https://github.com/rust-lang/cargo-bisect-rustc/blob/master/TUTORIAL.md ## Downloading Artifacts from Rust's CI diff --git a/src/conventions.md b/src/conventions.md index 303eedd4e..3f957cc27 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -14,7 +14,7 @@ enforced by a script we affectionately call the "tidy" script. The tidy script runs automatically when you do `./x.py test` and can be run in isolation with `./x.py test tidy`. -[fmt]: https://github.com/rust-lang-nursery/fmt-rfcs +[fmt]: https://github.com/rust-dev-tools/fmt-rfcs diff --git a/src/diagnostics.md b/src/diagnostics.md index 4810e4fa6..50da15c22 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -82,7 +82,7 @@ is passed) as JSON for consumption by tools, most notably the [Rust Language Server][rls] and [`rustfix`][rustfix]. [rls]: https://github.com/rust-lang/rls -[rustfix]: https://github.com/rust-lang-nursery/rustfix +[rustfix]: https://github.com/rust-lang/rustfix Not all suggestions should be applied mechanically. Use the [`span_suggestion`][span_suggestion] method of `DiagnosticBuilder` to diff --git a/src/profiling.md b/src/profiling.md index b7cc72258..8eaa8e94f 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -5,7 +5,7 @@ This section talks about how to profile the compiler and find out where it spend Depending on what you're trying to measure, there are several different approaches: - If you want to see if a PR improves or regresses compiler performance: - - The [rustc-perf](https://github.com/rust-lang-nursery/rustc-perf) project makes this easy and can be triggered to run on a PR via the `@rustc-perf` bot. + - The [rustc-perf](https://github.com/rust-lang/rustc-perf) project makes this easy and can be triggered to run on a PR via the `@rustc-perf` bot. - If you want a medium-to-high level overview of where `rustc` is spending its time: - The `-Zself-profile` flag and [measureme](https://github.com/rust-lang/measureme) tools offer a query-based approach to profiling. diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index d22a3cf4b..7a4c972f2 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -59,10 +59,10 @@ do that, the first step is to clone [the rustc-perf repository][rustc-perf-gh]: ```bash -git clone https://github.com/rust-lang-nursery/rustc-perf +git clone https://github.com/rust-lang/rustc-perf ``` -[rustc-perf-gh]: https://github.com/rust-lang-nursery/rustc-perf +[rustc-perf-gh]: https://github.com/rust-lang/rustc-perf #### Doing it the easy way @@ -70,7 +70,7 @@ Once you've cloned the repo, you can use the `collector` executable to do profiling for you! You can find [instructions in the rustc-perf readme][rustc-perf-readme]. -[rustc-perf-readme]: https://github.com/rust-lang-nursery/rustc-perf/blob/master/collector/README.md#profiling +[rustc-perf-readme]: https://github.com/rust-lang/rustc-perf/blob/master/collector/README.md#profiling For example, to measure the clap-rs test, you might do: @@ -94,7 +94,7 @@ are found in [the `collector/benchmarks` directory][dir]. So let's go into the directory of a specific test; we'll use `clap-rs` as an example: -[dir]: https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector/benchmarks +[dir]: https://github.com/rust-lang/rustc-perf/tree/master/collector/benchmarks ```bash cd collector/benchmarks/clap-rs diff --git a/src/tests/intro.md b/src/tests/intro.md index b47a9fdee..a81255dec 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -183,7 +183,7 @@ communicate with the server to coordinate running tests (see ## Crater -[Crater](https://github.com/rust-lang-nursery/crater) is a tool for compiling +[Crater](https://github.com/rust-lang/crater) is a tool for compiling and running tests for _every_ crate on [crates.io](https://crates.io) (and a few on GitHub). It is mainly used for checking for extent of breakage when implementing potentially breaking changes and ensuring lack of breakage by diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index 5aba1c20f..ecd2ce145 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -43,7 +43,7 @@ In terms of code, these types are defined in [pphhf]: ./bibliography.html#pphhf [traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs -[chalk_ir]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-ir/src/lib.rs +[chalk_ir]: https://github.com/rust-lang/chalk/blob/master/chalk-ir/src/lib.rs From e1301ac847a1279ff8ca6a61b3cd3bf12e7c1d02 Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Fri, 3 Apr 2020 13:22:08 -0400 Subject: [PATCH 0888/1812] Add BodyId to glossary, and links for ids to HIR identifiers section (#660) --- src/appendix/glossary.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 39913a3f7..20c35e0ac 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -9,6 +9,7 @@ Term | Meaning arena/arena allocation | An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. AST | The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. binder | A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound). +BodyId | An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). bound variable | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen | The code to translate MIR into LLVM IR. codegen unit | When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) @@ -18,7 +19,7 @@ CTFE | Short for Compile-Time Function Evaluation, this is t cx | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. DAG | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). -DefId | An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. +DefId | An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). Double pointer | A pointer with additional metadata. See "fat pointer" for more. drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. DST | Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). @@ -28,7 +29,7 @@ Fat pointer | A two word value carrying the address of some value, free variable | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) generics | The set of generic type parameters defined on a type or item. HIR | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.html)) -HirId | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". +HirId | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. ICE | Short for internal compiler error, this is when the compiler crashes. ICH | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. @@ -50,7 +51,7 @@ monomorphization | The process of taking generic implementations of type normalize | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize). newtype | A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. NLL | Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. -node-id or NodeId | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. +node-id or NodeId | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). obligation | Something that must be proven by the trait system. ([see more](../traits/resolution.html)) placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. point | Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. From e89d981d41cb6c1403babb0da92e98da328eec3d Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 4 Apr 2020 09:37:39 +0200 Subject: [PATCH 0889/1812] add pre-requisite for calling into compiler API (#663) --- src/rustc-driver-interacting-with-the-ast.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/rustc-driver-interacting-with-the-ast.md b/src/rustc-driver-interacting-with-the-ast.md index 51d5cb6d3..1749c9db4 100644 --- a/src/rustc-driver-interacting-with-the-ast.md +++ b/src/rustc-driver-interacting-with-the-ast.md @@ -4,6 +4,10 @@ ## Getting the type of an expression +NOTE: For the example to compile, you will need to first run the following: + + rustup component add rustc-dev + To get the type of an expression, use the `global_ctxt` to get a `TyCtxt`: ```rust From 7b9fa81800380b0bc5b0dd996a394ea530510659 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Fri, 3 Apr 2020 17:53:37 -0400 Subject: [PATCH 0890/1812] [README.md] add build instructions, link check config instructions, link check error documentation --- README.md | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 62 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 4a8c975fb..a6658b023 100644 --- a/README.md +++ b/README.md @@ -33,17 +33,73 @@ In general, when writing about a particular part of the compiler's code, we recommend that you link to the relevant parts of the [rustc rustdocs][rustdocs]. -To help prevent accidentally introducing broken links, we use the -`mdbook-linkcheck`. If installed on your machine `mdbook` will automatically -invoke this link checker, otherwise it will emit a warning saying it couldn't -be found. +### Build Instructions + +Deactivate the CI testing link validations by commenting out the `[output.linkcheck]` field in the `book.toml` configuration file like this: + +```toml +[book] +title = "Guide to Rustc Development" +author = "Rustc developers" +description = "A guide to developing rustc" + +[build] +create-missing = false + +[output.html] +git-repository-url = "https://github.com/rust-lang/rustc-dev-guide" + +[output.html.fold] +enable = true +level = 1 + +# [output.linkcheck] +# follow-web-links = false +# exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il" ] +# cache-timeout = 172800 +# warning-policy = "error" +``` + +These validations can cause errors during local builds (see Link Validations section below). Please **do not** commit these `book.toml` file changes when you submit a pull request. + +To build a local static HTML site, install [`mdbook`](https://github.com/rust-lang/mdBook) with: + +``` +> cargo install mdbook +``` + +and execute the following command in the root of the repository: + +``` +> mdbook build +``` + +The build files are found in the `book` directory. + +### Link Validations + +We use `mdbook-linkcheck` to validate URLs included in our documentation. To perform link checks, uncomment the `[output.linkcheck]` field in the `book.toml` configuration file and install `mdbook-linkcheck` with: ```bash > cargo install mdbook-linkcheck ``` -You will need `mdbook` version `>= 0.3.5` and `mdbook-linkcheck` version `>= 0.5`. -`linkcheck` will be run automatically when you run `mdbook build`. +You will need `mdbook` version `>= 0.3.5` and `mdbook-linkcheck` version `>= 0.5` to check links. +`linkcheck` will be run automatically when you build with the instructions in the section above. + +**Please note**: You may receive errors like the following when link checks are active on local `mdbook` builds: + +``` +error: The server responded with 429 Too Many Requests for "https://github.com/rust-lang/rust/tree/master/src/tools/compiletest" + + ┌── tests/intro.md:6:1 ─── + │ + 6 │ [`src/tools/compiletest`] directory). This section gives a brief + │ ^ Server responded with 429 Too Many Requests +``` + +There is not a workaround for this error at the moment. Comment out the `[output.linkcheck]` field in the `book.toml` using the build instructions above to complete a local site build without link validations. + ## How to fix toolstate failures From 472ff7008cf6c936ca08a454a5a4620845ba3a9a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 4 Apr 2020 13:24:30 -0500 Subject: [PATCH 0891/1812] Update .gitignore --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 7585238ef..b8cb34883 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,4 @@ book + +# prevent accidentally changes +book.toml From 14a08a36632a5bb834acbda19af73dc41543c3a3 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 4 Apr 2020 20:15:51 +0200 Subject: [PATCH 0892/1812] remove stupid-stats, and some references to removed API --- src/SUMMARY.md | 11 +- src/appendix/stupid-stats.md | 417 ----------------------------------- src/rustc-driver.md | 13 +- 3 files changed, 10 insertions(+), 431 deletions(-) delete mode 100644 src/appendix/stupid-stats.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index d8e6f852f..366146185 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -117,12 +117,11 @@ --- -[Appendix A: Stupid Stats](./appendix/stupid-stats.md) -[Appendix B: Background material](./appendix/background.md) -[Appendix C: Glossary](./appendix/glossary.md) -[Appendix D: Code Index](./appendix/code-index.md) -[Appendix E: Compiler Lecture Series](./appendix/compiler-lecture.md) -[Appendix F: Bibliography](./appendix/bibliography.md) +[Appendix A: Background material](./appendix/background.md) +[Appendix B: Glossary](./appendix/glossary.md) +[Appendix C: Code Index](./appendix/code-index.md) +[Appendix D: Compiler Lecture Series](./appendix/compiler-lecture.md) +[Appendix E: Bibliography](./appendix/bibliography.md) [Appendix Z: HumorRust](./appendix/humorust.md) diff --git a/src/appendix/stupid-stats.md b/src/appendix/stupid-stats.md deleted file mode 100644 index a07956f0f..000000000 --- a/src/appendix/stupid-stats.md +++ /dev/null @@ -1,417 +0,0 @@ -# Appendix A: A tutorial on creating a drop-in replacement for rustc - -> **Note:** This is a copy of `@nrc`'s amazing [stupid-stats]. You should find -> a copy of the code on the GitHub repository. -> -> Due to the compiler's constantly evolving nature, the `rustc_driver` -> mechanisms described in this chapter have changed. In particular, the -> `CompilerCalls` and `CompileController` types have been replaced by -> [`Callbacks`][cb]. Also, there is a new query-based interface in the -> [`rustc_interface`] crate. See [The Rustc Driver and Interface] for more -> information. - -Many tools benefit from being a drop-in replacement for a compiler. By this, I -mean that any user of the tool can use `mytool` in all the ways they would -normally use `rustc` - whether manually compiling a single file or as part of a -complex make project or Cargo build, etc. That could be a lot of work; -rustc, like most compilers, takes a large number of command line arguments which -can affect compilation in complex and interacting ways. Emulating all of this -behaviour in your tool is annoying at best, especically if you are making many -of the same calls into librustc_middle that the compiler is. - -The kind of things I have in mind are tools like rustdoc or a future rustfmt. -These want to operate as closely as possible to real compilation, but have -totally different outputs (documentation and formatted source code, -respectively). Another use case is a customised compiler. Say you want to add a -custom code generation phase after macro expansion, then creating a new tool -should be easier than forking the compiler (and keeping it up to date as the -compiler evolves). - -I have gradually been trying to improve the API of librustc_middle to make creating a -drop-in tool easier to produce (many others have also helped improve these -interfaces over the same time frame). It is now pretty simple to make a tool -which is as close to rustc as you want it to be. In this tutorial I'll show -how. - -Note/warning, everything I talk about in this tutorial is internal API for -rustc. It is all extremely unstable and likely to change often and in -unpredictable ways. Maintaining a tool which uses these APIs will be non- -trivial, although hopefully easier than maintaining one that does similar things -without using them. - -This tutorial starts with a very high level view of the rustc compilation -process and of some of the code that drives compilation. Then I'll describe how -that process can be customised. In the final section of the tutorial, I'll go -through an example - stupid-stats - which shows how to build a drop-in tool. - - -## Overview of the compilation process - -Compilation using rustc happens in several phases. We start with parsing, this -includes lexing. The output of this phase is an AST (abstract syntax tree). -There is a single AST for each crate (indeed, the entire compilation process -operates over a single crate). Parsing abstracts away details about individual -files which will all have been read in to the AST in this phase. At this stage -the AST includes all macro uses, attributes will still be present, and nothing -will have been eliminated due to `cfg`s. - -The next phase is configuration and macro expansion. This can be thought of as a -function over the AST. The unexpanded AST goes in and an expanded AST comes out. -Macros and syntax extensions are expanded, and `cfg` attributes will cause some -code to disappear. The resulting AST won't have any macros or macro uses left -in. - -The code for these first two phases is in [librustc_ast](https://github.com/rust-lang/rust/tree/master/src/librustc_ast). - -After this phase, the compiler allocates ids to each node in the AST -(technically not every node, but most of them). If we are writing out -dependencies, that happens now. - -The next big phase is analysis. This is the most complex phase and -uses the bulk of the code in rustc. This includes name resolution, type -checking, borrow checking, type and lifetime inference, trait selection, method -selection, linting, and so forth. Most error detection is done in this phase -(although parse errors are found during parsing). The 'output' of this phase is -a bunch of side tables containing semantic information about the source program. -The analysis code is in [librustc_middle](https://github.com/rust-lang/rust/tree/master/src/librustc_middle) -and a bunch of other crates with the 'librustc_' prefix. - -Next is translation, this translates the AST (and all those side tables) into -LLVM IR (intermediate representation). We do this by calling into the LLVM -libraries, rather than actually writing IR directly to a file. The code for -this is in librustc_trans. - -The next phase is running the LLVM backend. This runs LLVM's optimisation passes -on the generated IR and then generates machine code. The result is object files. -This phase is all done by LLVM, it is not really part of the rust compiler. The -interface between LLVM and rustc is in [librustc_llvm](https://github.com/rust-lang/rust/tree/master/src/librustc_llvm). - -Finally, we link the object files into an executable. Again we outsource this to -other programs and it's not really part of the rust compiler. The interface is -in librustc_back (which also contains some things used primarily during -translation). - -> NOTE: `librustc_trans` and `librustc_back` no longer exist, and we don't -> translate AST or HIR directly to LLVM IR anymore. Instead, see -> [`librustc_codegen_llvm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/index.html) -> and [`librustc_codegen_ssa`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/index.html). - -All these phases are coordinated by the driver. To see the exact sequence, look -at the `compile_input` function in `librustc_driver`. -The driver handles all the highest level coordination of compilation - - 1. handling command-line arguments - 2. maintaining compilation state (primarily in the `Session`) - 3. calling the appropriate code to run each phase of compilation - 4. handles high level coordination of pretty printing and testing. -To create a drop-in compiler replacement or a compiler replacement, -we leave most of compilation alone and customise the driver using its APIs. - -## The driver customisation APIs - -There are two primary ways to customise compilation - high level control of the -driver using `CompilerCalls` and controlling each phase of compilation using a -`CompileController`. The former lets you customise handling of command line -arguments etc., the latter lets you stop compilation early or execute code -between phases. - - -### `CompilerCalls` - -`CompilerCalls` is a trait that you implement in your tool. It contains a fairly -ad-hoc set of methods to hook in to the process of processing command line -arguments and driving the compiler. For details, see the comments in -[librustc_driver/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/index.html). -I'll summarise the methods here. - -`early_callback` and `late_callback` let you call arbitrary code at different -points - early is after command line arguments have been parsed, but before -anything is done with them; late is pretty much the last thing before -compilation starts, i.e., after all processing of command line arguments, etc. -is done. Currently, you get to choose whether compilation stops or continues at -each point, but you don't get to change anything the driver has done. You can -record some info for later, or perform other actions of your own. - -`some_input` and `no_input` give you an opportunity to modify the primary input -to the compiler (usually the input is a file containing the top module for a -crate, but it could also be a string). You could record the input or perform -other actions of your own. - -Ignore `parse_pretty`, it is unfortunate and hopefully will get improved. There -is a default implementation, so you can pretend it doesn't exist. - -`build_controller` returns a `CompileController` object for more fine-grained -control of compilation, it is described next. - -We might add more options in the future. - - -### `CompilerController` - -`CompilerController` is a struct consisting of `PhaseController`s and flags. -Currently, there is only flag, `make_glob_map` which signals whether to produce -a map of glob imports (used by save-analysis and potentially other tools). There -are probably flags in the session that should be moved here. - -There is a `PhaseController` for each of the phases described in the above -summary of compilation (and we could add more in the future for finer-grained -control). They are all `after_` a phase because they are checked at the end of a -phase (again, that might change), e.g., `CompilerController::after_parse` -controls what happens immediately after parsing (and before macro expansion). - -Each `PhaseController` contains a flag called `stop` which indicates whether -compilation should stop or continue, and a callback to be executed at the point -indicated by the phase. The callback is called whether or not compilation -continues. - -Information about the state of compilation is passed to these callbacks in a -`CompileState` object. This contains all the information the compiler has. Note -that this state information is immutable - your callback can only execute code -using the compiler state, it can't modify the state. (If there is demand, we -could change that). The state available to a callback depends on where during -compilation the callback is called. For example, after parsing there is an AST -but no semantic analysis (because the AST has not been analysed yet). After -translation, there is translation info, but no AST or analysis info (since these -have been consumed/forgotten). - - -## An example - stupid-stats - -Our example tool is very simple, it simply collects some simple and not very -useful statistics about a program; it is called stupid-stats. You can find -the (more heavily commented) complete source for the example on [Github](https://github.com/nick29581/stupid-stats/blob/master/src). -To build, just do `cargo build`. To run on a file `foo.rs`, do `cargo run -foo.rs` (assuming you have a Rust program called `foo.rs`. You can also pass any -command line arguments that you would normally pass to rustc). When you run it -you'll see output similar to - -```text -In crate: foo, - -Found 12 uses of `println!`; -The most common number of arguments is 1 (67% of all functions); -25% of functions have four or more arguments. -``` - -To make things easier, when we talk about functions, we're excluding methods and -closures. - -You can also use the executable as a drop-in replacement for rustc, because -after all, that is the whole point of this exercise. So, however you use rustc -in your makefile setup, you can use `target/stupid` (or whatever executable you -end up with) instead. That might mean setting an environment variable or it -might mean renaming your executable to `rustc` and setting your PATH. Similarly, -if you're using Cargo, you'll need to rename the executable to rustc and set the -PATH. Alternatively, you should be able to use -[multirust](https://github.com/brson/multirust) to get around all the PATH stuff -(although I haven't actually tried that). - -(Note that this example prints to stdout. I'm not entirely sure what Cargo does -with stdout from rustc under different circumstances. If you don't see any -output, try inserting a `panic!` after the `println!`s to error out, then Cargo -should dump stupid-stats' stdout to Cargo's stdout). - -Let's start with the `main` function for our tool, it is pretty simple: - -```rust,ignore -fn main() { - let args: Vec<_> = std::env::args().collect(); - rustc_driver::run_compiler(&args, &mut StupidCalls::new()); - std::env::set_exit_status(0); -} -``` - -The first line grabs any command line arguments. The second line calls the -compiler driver with those arguments. The final line sets the exit code for the -program. - -The only interesting thing is the `StupidCalls` object we pass to the driver. -This is our implementation of the `CompilerCalls` trait and is what will make -this tool different from rustc. - -`StupidCalls` is a mostly empty struct: - -```rust,ignore -struct StupidCalls { - default_calls: RustcDefaultCalls, -} -``` - -This tool is so simple that it doesn't need to store any data here, but usually -you would. We embed a `RustcDefaultCalls` object to delegate to in our impl when -we want exactly the same behaviour as the Rust compiler. Mostly you don't want -to do that (or at least don't need to) in a tool. However, Cargo calls rustc -with the `--print file-names`, so we delegate in `late_callback` and `no_input` -to keep Cargo happy. - -Most of the rest of the impl of `CompilerCalls` is trivial: - -```rust,ignore -impl<'a> CompilerCalls<'a> for StupidCalls { - fn early_callback(&mut self, - _: &getopts::Matches, - _: &config::Options, - _: &diagnostics::registry::Registry, - _: ErrorOutputType) - -> Compilation { - Compilation::Continue - } - - fn late_callback(&mut self, - t: &TransCrate, - m: &getopts::Matches, - s: &Session, - c: &CrateStore, - i: &Input, - odir: &Option, - ofile: &Option) - -> Compilation { - self.default_calls.late_callback(t, m, s, c, i, odir, ofile); - Compilation::Continue - } - - fn some_input(&mut self, - input: Input, - input_path: Option) - -> (Input, Option) { - (input, input_path) - } - - fn no_input(&mut self, - m: &getopts::Matches, - o: &config::Options, - odir: &Option, - ofile: &Option, - r: &diagnostics::registry::Registry) - -> Option<(Input, Option)> { - self.default_calls.no_input(m, o, odir, ofile, r); - - // This is not optimal error handling. - panic!("No input supplied to stupid-stats"); - } - - fn build_controller(&mut self, _: &Session) -> driver::CompileController<'a> { - ... - } -} -``` - -We don't do anything for either of the callbacks, nor do we change the input if -the user supplies it. If they don't, we just `panic!`, this is the simplest way -to handle the error, but not very user-friendly, a real tool would give a -constructive message or perform a default action. - -In `build_controller` we construct our `CompileController`. We only want to -parse, and we want to inspect macros before expansion, so we make compilation -stop after the first phase (parsing). The callback after that phase is where the -tool does it's actual work by walking the AST. We do that by creating an AST -visitor and making it walk the AST from the top (the crate root). Once we've -walked the crate, we print the stats we've collected: - -```rust,ignore -fn build_controller(&mut self, _: &Session) -> driver::CompileController<'a> { - // We mostly want to do what rustc does, which is what basic() will return. - let mut control = driver::CompileController::basic(); - // But we only need the AST, so we can stop compilation after parsing. - control.after_parse.stop = Compilation::Stop; - - // And when we stop after parsing we'll call this closure. - // Note that this will give us an AST before macro expansions, which is - // not usually what you want. - control.after_parse.callback = box |state| { - // Which extracts information about the compiled crate... - let krate = state.krate.unwrap(); - - // ...and walks the AST, collecting stats. - let mut visitor = StupidVisitor::new(); - visit::walk_crate(&mut visitor, krate); - - // And finally prints out the stupid stats that we collected. - let cratename = match attr::find_crate_name(&krate.attrs[]) { - Some(name) => name.to_string(), - None => String::from_str("unknown_crate"), - }; - println!("In crate: {},\n", cratename); - println!("Found {} uses of `println!`;", visitor.println_count); - - let (common, common_percent, four_percent) = visitor.compute_arg_stats(); - println!("The most common number of arguments is {} ({:.0}% of all functions);", - common, common_percent); - println!("{:.0}% of functions have four or more arguments.", four_percent); - }; - - control -} -``` - -That is all it takes to create your own drop-in compiler replacement or custom -compiler! For the sake of completeness I'll go over the rest of the stupid-stats -tool. - -```rust -struct StupidVisitor { - println_count: usize, - arg_counts: Vec, -} -``` - -The `StupidVisitor` struct just keeps track of the number of `println!`s it has -seen and the count for each number of arguments. It implements -`rustc_ast::visit::Visitor` to walk the AST. Mostly we just use the default -methods, these walk the AST taking no action. We override `visit_item` and -`visit_mac` to implement custom behaviour when we walk into items (items include -functions, modules, traits, structs, and so forth, we're only interested in -functions) and macros: - -```rust,ignore -impl<'v> visit::Visitor<'v> for StupidVisitor { - fn visit_item(&mut self, i: &'v ast::Item) { - match i.node { - ast::Item_::ItemFn(ref decl, _, _, _, _) => { - // Record the number of args. - self.increment_args(decl.inputs.len()); - } - _ => {} - } - - // Keep walking. - visit::walk_item(self, i) - } - - fn visit_mac(&mut self, mac: &'v ast::Mac) { - // Find its name and check if it is "println". - let ast::Mac_::MacInvocTT(ref path, _, _) = mac.node; - if path_to_string(path) == "println" { - self.println_count += 1; - } - - // Keep walking. - visit::walk_mac(self, mac) - } -} -``` - -The `increment_args` method increments the correct count in -`StupidVisitor::arg_counts`. After we're done walking, `compute_arg_stats` does -some pretty basic maths to come up with the stats we want about arguments. - - -## What next? - -These APIs are pretty new and have a long way to go until they're really good. -If there are improvements you'd like to see or things you'd like to be able to -do, let me know in a comment or [GitHub issue](https://github.com/rust-lang/rust/issues). -In particular, it's not clear to me exactly what extra flexibility is required. -If you have an existing tool that would be suited to this setup, please try it -out and let me know if you have problems. - -It'd be great to see Rustdoc converted to using these APIs, if that is possible -(although long term, I'd prefer to see Rustdoc run on the output from save- -analysis, rather than doing its own analysis). Other parts of the compiler -(e.g., pretty printing, testing) could be refactored to use these APIs -internally (I already changed save-analysis to use `CompilerController`). I've -been experimenting with a prototype rustfmt which also uses these APIs. - -[cb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/trait.Callbacks.html -[stupid-stats]: https://github.com/nrc/stupid-stats -[`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html -[The Rustc Driver and Interface]: ../rustc-driver.html diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 6a2e87f4d..2cffba42c 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -11,7 +11,7 @@ analysing a crate or emulating the compiler in-process (e.g. the RLS or rustdoc) For those using `rustc` as a library, the [`rustc_interface::run_compiler()`][i_rc] function is the main entrypoint to the compiler. It takes a configuration for the compiler -and a closure that takes a [`Compiler`]. `run_compiler` creates a `Compiler` from the +and a closure that takes a [`Compiler`]. `run_compiler` creates a `Compiler` from the configuration and passes it to the closure. Inside the closure, you can use the `Compiler` to drive queries to compile a crate and get the results. This is what the `rustc_driver` does too. You can see a minimal example of how to use `rustc_interface` [here][example]. @@ -19,16 +19,13 @@ You can see a minimal example of how to use `rustc_interface` [here][example]. You can see what queries are currently available through the rustdocs for [`Compiler`]. You can see an example of how to use them by looking at the `rustc_driver` implementation, specifically the [`rustc_driver::run_compiler` function][rd_rc] (not to be confused with -[`rustc_interface::run_compiler`][i_rc]). The `rustc_driver::run_compiler` function +[`rustc_interface::run_compiler`][i_rc]). The `rustc_driver::run_compiler` function takes a bunch of command-line args and some other configurations and drives the compilation to completion. -`rustc_driver::run_compiler` also takes a [`Callbacks`][cb]. In the past, when -the `rustc_driver::run_compiler` was the primary way to use the compiler as a -library, these callbacks were used to have some custom code run after different -phases of the compilation. If you read [Appendix A], you may notice the use of the -types `CompilerCalls` and `CompileController`, which no longer exist. `Callbacks` -replaces this functionality. +`rustc_driver::run_compiler` also takes a [`Callbacks`][cb], +a trait that allows for custom compiler configuration, +as well as allowing some custom code run after different phases of the compilation. > **Warning:** By its very nature, the internal compiler APIs are always going > to be unstable. That said, we do try not to break things unnecessarily. From 6e91f8d0e9efd11443e02c670e18436da4d5f16f Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Fri, 3 Apr 2020 18:04:24 -0400 Subject: [PATCH 0893/1812] Add ids to all glossary items, make existing glossary links point to glossary, add links for def id in query.md --- src/appendix/glossary.md | 158 +++++++++--------- src/backend/monomorph.md | 2 +- src/borrow_check.md | 4 +- .../constraint_propagation.md | 2 +- src/building/suggested.md | 2 +- src/mir/index.md | 2 +- src/mir/optimizations.md | 4 +- src/query.md | 3 +- src/traits/hrtb.md | 2 +- 9 files changed, 90 insertions(+), 89 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 20c35e0ac..4d0f84999 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -4,85 +4,85 @@ The compiler uses a number of...idiosyncratic abbreviations and things. This glossary attempts to list them and give you a few pointers for understanding them better. -Term | Meaning -------------------------|-------- -arena/arena allocation | An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. -AST | The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. -binder | A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound). -BodyId | An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -bound variable | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) -codegen | The code to translate MIR into LLVM IR. -codegen unit | When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) -completeness | A technical term in type theory, it means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). -control-flow graph | A representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) -CTFE | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) -cx | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. -DAG | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) -data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). -DefId | An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -Double pointer | A pointer with additional metadata. See "fat pointer" for more. -drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. -DST | Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). -early-bound lifetime | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) -empty type | see "uninhabited type". -Fat pointer | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". -free variable | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) -generics | The set of generic type parameters defined on a type or item. -HIR | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.html)) -HirId | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. -ICE | Short for internal compiler error, this is when the compiler crashes. -ICH | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. -inference variable | When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. -infcx | The inference context (see `librustc_middle/infer`) -intern | Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. -IR | Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. -IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). -item | A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. -lang item | Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) -late-bound lifetime | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) -local crate | The crate currently being compiled. -LTO | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. -[LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. -memoization | The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. -MIR | The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.html)) -miri | An interpreter for MIR used for constant evaluation. ([see more](../miri.html)) -monomorphization | The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). -normalize | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize). -newtype | A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -NLL | Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. -node-id or NodeId | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -obligation | Something that must be proven by the trait system. ([see more](../traits/resolution.html)) -placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. -point | Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. -polymorphize | An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) -projection | A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref). -promoted constants | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. -provider | The function that executes a query. ([see more](../query.html)) -quantified | In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified). -query | Perhaps some sub-computation during compilation. ([see more](../query.html)) -region | Another term for "lifetime" often used in the literature and in the borrow checker. -rib | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) -sess | The compiler session, which stores global data used throughout compilation -side tables | Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. -sigil | Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -soundness | A technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). -span | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. -substs | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). -tcx | The "typing context", main data structure of the compiler. ([see more](../ty.html)) -'tcx | The lifetime of the allocation arena. ([see more](../ty.html)) -trait reference | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) -token | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). -[TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. -trans | The code to translate MIR into LLVM IR. Renamed to codegen. -trait reference | A trait and values for its type parameters. ([see more](../ty.html)) -ty | The internal representation of a type. ([see more](../ty.html)) -UFCS | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) -uninhabited type | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". -upvar | A variable captured by a closure from outside the closure. -variance | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance. -Wide pointer | A pointer with additional metadata. See "fat pointer" for more. -ZST | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. +Term | Meaning +-----------------------------------------|-------- +arena/arena allocation

| An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. +AST
| The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. +binder
| A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound). +BodyId
| A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) +codegen
| The code to translate MIR into LLVM IR. +codegen unit
| When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) +completeness
| A technical term in type theory, it means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). +control-flow graph
| A representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) +CTFE
| Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) +cx
| We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. +DAG
| A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) +data-flow analysis
| A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). +DefId
| An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +Double pointer
| A pointer with additional metadata. See "fat pointer" for more. +drop glue
| (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. +DST
| Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). +early-bound lifetime
| A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) +empty type
| see "uninhabited type". +Fat pointer
| A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". +free variable
| A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) +generics
| The set of generic type parameters defined on a type or item. +HIR
| The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.html)) +HirId
| Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +HIR Map
| The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. +ICE
| Short for internal compiler error, this is when the compiler crashes. +ICH
| Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. +inference variable
| When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. +infcx
| The inference context (see `librustc_middle/infer`) +intern
| Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. +IR
| Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. +IRLO
| `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). +item
| A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. +lang item
| Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) +late-bound lifetime
| A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) +local crate
| The crate currently being compiled. +LTO
| Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. +[LLVM]
| (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. +memoization
| The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. +MIR
| The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.html)) +miri
| An interpreter for MIR used for constant evaluation. ([see more](../miri.html)) +monomorphization
| The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). +normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize). +newtype
| A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. +NLL
| Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. +node-id or NodeId
| An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +obligation
| Something that must be proven by the trait system. ([see more](../traits/resolution.html)) +placeholder
| **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. +point
| Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. +polymorphize
| An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) +projection
| A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref). +promoted constants
| Constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. +provider
| The function that executes a query. ([see more](../query.html)) +quantified
| In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified). +query
| Perhaps some sub-computation during compilation. ([see more](../query.html)) +region
| Another term for "lifetime" often used in the literature and in the borrow checker. +rib
| A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) +sess
| The compiler session, which stores global data used throughout compilation +side tables
| Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. +sigil
| Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. +soundness
| A technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). +span
| A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. +substs
| The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). +tcx
| The "typing context", main data structure of the compiler. ([see more](../ty.html)) +'tcx
| The lifetime of the allocation arena. ([see more](../ty.html)) +trait reference
| The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) +token
| The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). +[TLS]
| Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. +trans
| The code to translate MIR into LLVM IR. Renamed to codegen. +trait reference
| A trait and values for its type parameters. ([see more](../ty.html)) +ty
| The internal representation of a type. ([see more](../ty.html)) +UFCS
| Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) +uninhabited type
| A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". +upvar
| A variable captured by a closure from outside the closure. +variance
| Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance. +Wide pointer
| A pointer with additional metadata. See "fat pointer" for more. +ZST
| Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. [LLVM]: https://llvm.org/ [lto]: https://llvm.org/docs/LinkTimeOptimization.html diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index 5ea8ba4f0..5e5d2e0c4 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -53,7 +53,7 @@ The monomorphization collector is run just before MIR lowering and codegen. [`rustc_codegen_ssa::base::codegen_crate`][codegen1] calls the [`collect_and_partition_mono_items`][mono] query, which does monomorphization collection and then partitions them into [codegen -units](../appendix/glossary.md). +units](../appendix/glossary.md#codegen-unit). [mono]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/partitioning/fn.collect_and_partition_mono_items.html [codegen1]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html diff --git a/src/borrow_check.md b/src/borrow_check.md index 034c36253..eea56e1c3 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -37,8 +37,8 @@ the [`mir_borrowck`] query. we will modify this copy in place to modify the types and things to include references to the new regions that we are computing. - We then invoke [`replace_regions_in_mir`] to modify our local MIR. - Among other things, this function will replace all of the [regions](./appendix/glossary.md) in - the MIR with fresh [inference variables](./appendix/glossary.md). + Among other things, this function will replace all of the [regions](./appendix/glossary.md#region) in + the MIR with fresh [inference variables](./appendix/glossary.md#inf-var). - Next, we perform a number of [dataflow analyses](./appendix/background.md#dataflow) that compute what data is moved and when. diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 6d190ae1a..1389628c8 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -55,7 +55,7 @@ includes a region R is live at some [point] P. This simply means that the value of R must include the point P. Liveness constraints are computed by the MIR type checker. -[point]: ../../appendix/glossary.md +[point]: ../../appendix/glossary.md#point A liveness constraint `R live at E` is satisfied if `E` is a member of `Values(R)`. So to "apply" such a constraint to `Values`, we just have diff --git a/src/building/suggested.md b/src/building/suggested.md index 087e9dee8..e9b48a7ef 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -53,7 +53,7 @@ the MIR). **The TL;DR is that you might get weird behavior from a compile when using `--keep-stage 1`** -- for example, strange -[ICEs](../appendix/glossary.html) or other panics. In that case, you +[ICEs](../appendix/glossary.html#ice) or other panics. In that case, you should simply remove the `--keep-stage 1` from the command and rebuild. That ought to fix the problem. diff --git a/src/mir/index.md b/src/mir/index.md index 99396903c..85c5d755e 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -256,4 +256,4 @@ but [you can read about those below](#promoted)). [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/mir [mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/mir -[newtype'd]: ../appendix/glossary.html +[newtype'd]: ../appendix/glossary.html#newtype diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index 2af3d06ce..3c143d555 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -9,7 +9,7 @@ effective; we can optimize the generic version, so all of the monomorphizations are cheaper! [mir]: https://rustc-dev-guide.rust-lang.org/mir/index.html -[monomorph]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html?highlight=monomorphize#appendix-c-glossary +[monomorph]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html#mono MIR optimizations run after borrow checking. We run a series of optimization passes over the MIR to improve it. Some passes are required to run on all code, @@ -23,7 +23,7 @@ optimizes it, and returns the improved MIR. [optmir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html [query]: https://rustc-dev-guide.rust-lang.org/query.html -[defid]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html?highlight=DefId#appendix-c-glossary +[defid]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html#def-id [steal]: https://rustc-dev-guide.rust-lang.org/mir/passes.html?highlight=steal#stealing ## Defining optimization passes diff --git a/src/query.md b/src/query.md index e008cb628..6e2193bd3 100644 --- a/src/query.md +++ b/src/query.md @@ -6,9 +6,10 @@ setup to a "demand-driven" system. **The Compiler Query System is the key to our new demand-driven organization.** The idea is pretty simple. You have various queries that compute things about the input – for example, there is a query called `type_of(def_id)` that, given -the def-id of some item, will compute the type of that item and return +the [def-id] of some item, will compute the type of that item and return it to you. +[def-id]: appendix/glossary.md#def-id [hl]: high-level-overview.html Query execution is **memoized** – so the first time you invoke a diff --git a/src/traits/hrtb.md b/src/traits/hrtb.md index f41d43ffd..81391f7ae 100644 --- a/src/traits/hrtb.md +++ b/src/traits/hrtb.md @@ -41,7 +41,7 @@ subtyping, we recommend you read the paper). There are a few parts: 3. Check for _placeholder leaks_. [hrsubtype]: ./hrtb.md -[placeholder]: ../appendix/glossary.html#appendix-c-glossary +[placeholder]: ../appendix/glossary.html#placeholder [paper by SPJ]: http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ So let's work through our example. From 0833cdbcd8a81ada320ed2ab5f3b46338424212a Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Fri, 3 Apr 2020 18:18:32 -0400 Subject: [PATCH 0894/1812] Wrap link in borrow_check.md to satify line length checks --- src/borrow_check.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/borrow_check.md b/src/borrow_check.md index eea56e1c3..7e076edf3 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -37,8 +37,8 @@ the [`mir_borrowck`] query. we will modify this copy in place to modify the types and things to include references to the new regions that we are computing. - We then invoke [`replace_regions_in_mir`] to modify our local MIR. - Among other things, this function will replace all of the [regions](./appendix/glossary.md#region) in - the MIR with fresh [inference variables](./appendix/glossary.md#inf-var). + Among other things, this function will replace all of the [regions](./appendix/glossary.md#region) + in the MIR with fresh [inference variables](./appendix/glossary.md#inf-var). - Next, we perform a number of [dataflow analyses](./appendix/background.md#dataflow) that compute what data is moved and when. From fabea21d800b4a5a518f2204fa78c169c0eca8cb Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Tue, 24 Mar 2020 14:52:53 +0100 Subject: [PATCH 0895/1812] Change ICE-breaker ping to use the aliases Related to rust-lang/rust#69949 --- src/ice-breaker/about.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md index e71001e5b..60182a3c2 100644 --- a/src/ice-breaker/about.md +++ b/src/ice-breaker/about.md @@ -58,8 +58,8 @@ To tag an issue as appropriate for an ICE-breaker group, you give team. For example: ```text -@rustbot ping icebreakers-llvm -@rustbot ping icebreakers-cleanup-crew +@rustbot ping llvm +@rustbot ping cleanup ``` **Note though that this should only be done by compiler team members From 255bf3cf353fb188829d590df454ac580048c42b Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 25 Mar 2020 14:17:52 +0100 Subject: [PATCH 0896/1812] Note that the invocation now are aliases --- src/ice-breaker/about.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md index 60182a3c2..1e5dc9416 100644 --- a/src/ice-breaker/about.md +++ b/src/ice-breaker/about.md @@ -62,9 +62,14 @@ team. For example: @rustbot ping cleanup ``` +These are aliases that are easier to remember than the full invocation. +They are declared in the [`triagebot.toml`] file and might be subject to +changes. + **Note though that this should only be done by compiler team members or contributors, and is typically done as part of compiler team triage.** [rustbot]: https://github.com/rust-lang/triagebot/ [`ping`]: https://github.com/rust-lang/triagebot/wiki/Pinging +[`triagebot.toml`]: https://github.com/rust-lang/rust/blob/master/triagebot.toml From af75c1001a61e7b3564bc816563b6a57ae9e1b4b Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sun, 5 Apr 2020 12:38:05 +0200 Subject: [PATCH 0897/1812] Rework commit message --- src/ice-breaker/about.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md index 1e5dc9416..642fbe4a1 100644 --- a/src/ice-breaker/about.md +++ b/src/ice-breaker/about.md @@ -57,14 +57,22 @@ To tag an issue as appropriate for an ICE-breaker group, you give [rustbot] a [`ping`] command with the name of the ICE-breakers team. For example: +```text +@rustbot ping icebreakers-llvm +@rustbot ping icebreakers-cleanup-crew +``` + +To make these commands shorter and easier to remember, there are aliases, +defined in the [`triagebot.toml`] file. For example: + ```text @rustbot ping llvm @rustbot ping cleanup ``` -These are aliases that are easier to remember than the full invocation. -They are declared in the [`triagebot.toml`] file and might be subject to -changes. +Keep in mind that these aliases are meant to make humans' life easier. +They might be subject to change. If you need to ensure that a command +will always be valid, prefer the full invocations over the aliases. **Note though that this should only be done by compiler team members or contributors, and is typically done as part of compiler team From a74c2abbef810721312440e70f3f05b5f49b20be Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 5 Apr 2020 18:02:35 -0500 Subject: [PATCH 0898/1812] update to mdbook 0.3.5 --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index e88ae40b2..df48ef6df 100644 --- a/.travis.yml +++ b/.travis.yml @@ -10,7 +10,7 @@ before_install: - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true -- cargo install mdbook --version 0.3.4 +- cargo install mdbook --version 0.3.7 - cargo install mdbook-linkcheck --version 0.5.0 script: - mdbook build From c33f0c615861c6481199b3ff40d3a8bb22ca3443 Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Mon, 6 Apr 2020 09:49:21 -0400 Subject: [PATCH 0899/1812] Remove duplicate trait reference entry from glossary, fix alphabetical sorting --- src/appendix/glossary.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 4d0f84999..11ddb494f 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -33,8 +33,8 @@ HirId
| Identifies a particular node in the HIR Map
| The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. ICE
| Short for internal compiler error, this is when the compiler crashes. ICH
| Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. -inference variable
| When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. infcx
| The inference context (see `librustc_middle/infer`) +inference variable
| When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. intern
| Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. IR
| Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. IRLO
| `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). @@ -71,11 +71,10 @@ span
| A location in the user's source code substs
| The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). tcx
| The "typing context", main data structure of the compiler. ([see more](../ty.html)) 'tcx
| The lifetime of the allocation arena. ([see more](../ty.html)) -trait reference
| The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) token
| The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). [TLS]
| Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. +trait reference
| The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) trans
| The code to translate MIR into LLVM IR. Renamed to codegen. -trait reference
| A trait and values for its type parameters. ([see more](../ty.html)) ty
| The internal representation of a type. ([see more](../ty.html)) UFCS
| Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) uninhabited type
| A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". From 269b5f08e703cdcf804a1883c06fa931ce47544a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 6 Apr 2020 11:23:34 -0500 Subject: [PATCH 0900/1812] Reorganize the guide (#651) * start on guide reorg * backend intro * part 2, 3, 4 intros * some missing files * Fix typos Co-Authored-By: Yuki Okushi Co-Authored-By: Chris Simpkins * add links from intro * rename compiler source chapter and add placeholder for overview * rename parts, mv rustc_driver to part 3, make syntax chapter * update part intros * add syntax ch intro * address review comments * Better overview chapter placeholder Co-Authored-By: Chris Simpkins * fix link Co-authored-by: Yuki Okushi Co-authored-by: Chris Simpkins --- src/SUMMARY.md | 68 +++++++++++-------- src/about-this-guide.md | 31 ++++++--- src/ast-validation.md | 6 ++ ...high-level-overview.md => compiler-src.md} | 0 src/feature-gate-ck.md | 3 + src/mir/construction.md | 2 +- src/overview.md | 3 + src/part-2-intro.md | 21 +++--- src/part-3-intro.md | 8 +++ src/part-4-intro.md | 12 ++++ src/{backend/backend.md => part-5-intro.md} | 30 ++++---- src/pat-exhaustive-checking.md | 7 ++ src/syntax-intro.md | 8 +++ 13 files changed, 139 insertions(+), 60 deletions(-) create mode 100644 src/ast-validation.md rename src/{high-level-overview.md => compiler-src.md} (100%) create mode 100644 src/feature-gate-ck.md create mode 100644 src/overview.md create mode 100644 src/part-3-intro.md create mode 100644 src/part-4-intro.md rename src/{backend/backend.md => part-5-intro.md} (66%) create mode 100644 src/pat-exhaustive-checking.md create mode 100644 src/syntax-intro.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 366146185..d6cbe0645 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -33,11 +33,10 @@ - ["Cleanup Crew" ICE-breakers](ice-breaker/cleanup-crew.md) - [LLVM ICE-breakers](ice-breaker/llvm.md) - [Licenses](./licenses.md) -- [Part 2: How rustc works](./part-2-intro.md) - - [High-level overview of the compiler source](./high-level-overview.md) - - [The Rustc Driver and Interface](./rustc-driver.md) - - [Rustdoc](./rustdoc.md) - - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) + +- [Part 2: High-level Compiler Architecture](./part-2-intro.md) + - [Overview of the Compiler](./overview.md) + - [The compiler source code](./compiler-src.md) - [Queries: demand-driven compilation](./query.md) - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) - [Incremental compilation](./queries/incremental-compilation.md) @@ -46,15 +45,29 @@ - [Profiling Queries](./queries/profiling.md) - [Salsa](./salsa.md) - [Memory Management in Rustc](./memory.md) - - [Lexing and Parsing](./the-parser.md) - - [`#[test]` Implementation](./test-implementation.md) - - [Panic Implementation](./panic-implementation.md) - - [Macro expansion](./macro-expansion.md) - - [Name resolution](./name-resolution.md) + +- [Part 3: Source Code Representations](./part-3-intro.md) + - [The Rustc Driver and Interface](./rustc-driver.md) + - [Rustdoc](./rustdoc.md) + - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) + - [Syntax and the AST](./syntax-intro.md) + - [Lexing and Parsing](./the-parser.md) + - [`#[test]` Implementation](./test-implementation.md) + - [Panic Implementation](./panic-implementation.md) + - [Macro expansion](./macro-expansion.md) + - [Name resolution](./name-resolution.md) + - [AST Validation](./ast-validation.md) + - [Feature Gate Checking](./feature-gate-ck.md) - [The HIR (High-level IR)](./hir.md) - [Lowering AST to HIR](./lowering.md) - [Debugging](./hir-debugging.md) + - [The MIR (Mid-level IR)](./mir/index.md) + - [HAIR and MIR construction](./mir/construction.md) + - [MIR visitor and traversal](./mir/visitor.md) + - [MIR passes: getting the MIR for a function](./mir/passes.md) - [Closure expansion](./closure.md) + +- [Part 4: Analysis](./part-4-intro.md) - [The `ty` module: representing types](./ty.md) - [Generics and substitutions](./generics.md) - [`TypeFolder` and `TypeFoldable`](./ty-fold.md) @@ -82,12 +95,7 @@ - [Method Lookup](./method-lookup.md) - [Variance](./variance.md) - [Opaque Types](./opaque-types-type-alias-impl-trait.md) - - [The MIR (Mid-level IR)](./mir/index.md) - - [MIR construction](./mir/construction.md) - - [MIR visitor and traversal](./mir/visitor.md) - - [MIR passes: getting the MIR for a function](./mir/passes.md) - - [MIR optimizations](./mir/optimizations.md) - - [Debugging](./mir/debugging.md) + - [Pattern and Exhaustiveness Checking](./pat-exhaustive-checking.md) - [The borrow checker](./borrow_check.md) - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) @@ -100,20 +108,24 @@ - [Closure constraints](./borrow_check/region_inference/closure_constraints.md) - [Error reporting](./borrow_check/region_inference/error_reporting.md) - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) + - [Parameter Environments](./param_env.md) + +- [Part 5: From MIR to binaries](./part-5-intro.md) + - [The MIR (Mid-level IR)](./mir/index.md) + - [MIR optimizations](./mir/optimizations.md) + - [Debugging](./mir/debugging.md) - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) - - [Parameter Environments](./param_env.md) - - [Compiler Backend](./backend/backend.md) - - [Monomorphization](./backend/monomorph.md) - - [Lowering MIR](./backend/lowering-mir.md) - - [Code Generation](./backend/codegen.md) - - [Updating LLVM](./backend/updating-llvm.md) - - [Debugging LLVM](./backend/debugging.md) - - [Backend Agnostic Codegen](./backend/backend-agnostic.md) - - [Implicit Caller Location](./codegen/implicit-caller-location.md) - - [Profile-guided Optimization](./profile-guided-optimization.md) - - [Sanitizers Support](./sanitizers.md) - - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) + - [Monomorphization](./backend/monomorph.md) + - [Lowering MIR](./backend/lowering-mir.md) + - [Code Generation](./backend/codegen.md) + - [Updating LLVM](./backend/updating-llvm.md) + - [Debugging LLVM](./backend/debugging.md) + - [Backend Agnostic Codegen](./backend/backend-agnostic.md) + - [Implicit Caller Location](./codegen/implicit-caller-location.md) + - [Profile-guided Optimization](./profile-guided-optimization.md) + - [Sanitizers Support](./sanitizers.md) + - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) --- diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 0882c40c0..9637c312a 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -2,14 +2,29 @@ This guide is meant to help document how rustc – the Rust compiler – works, as well as to help new contributors get involved in rustc -development. It is not meant to replace code documentation – each -chapter gives only high-level details, the kinds of things that -(ideally) don't change frequently. - -There are three parts to this guide. Part 1 contains information that should -be useful no matter how you are contributing. Part 2 contains information -about how the compiler works. Finally, there are some appendices at the -end with useful reference information. +development. + +There are six parts to this guide: + +1. [Contributing][p1]: Contains information that should be useful no matter how + you are contributing, such as procedures for contribution, building the + compiler, etc. +2. [High-level Compiler Architecture][p2]: Discusses the high-level + architecture of the compiler, especially the query system. +3. [The Compiler Frontend][p3]: Discusses the compiler frontend and internal + representations. +4. [The Type System][p4]: Discusses the type system. +5. [The Compiler Backend][p5]: Discusses the compiler backend, code generation, + linking, and debug info. +6. [Appendices][app] at the end with useful reference information. There are a + few of these with different information, inluding a glossary. + +[p1]: ./part-1-intro.md +[p2]: ./part-2-intro.md +[p3]: ./part-3-intro.md +[p4]: ./part-4-intro.md +[p5]: ./part-5-intro.md +[app]: ./appendix/background.md The guide itself is of course open-source as well, and the sources can be found at the [GitHub repository]. If you find any mistakes in the diff --git a/src/ast-validation.md b/src/ast-validation.md new file mode 100644 index 000000000..64e35bb93 --- /dev/null +++ b/src/ast-validation.md @@ -0,0 +1,6 @@ +# AST Validation + +AST validation is the process of checking various correctness properties about +the AST after macro expansion. + +**TODO**: write this chapter. diff --git a/src/high-level-overview.md b/src/compiler-src.md similarity index 100% rename from src/high-level-overview.md rename to src/compiler-src.md diff --git a/src/feature-gate-ck.md b/src/feature-gate-ck.md new file mode 100644 index 000000000..3b3a07a31 --- /dev/null +++ b/src/feature-gate-ck.md @@ -0,0 +1,3 @@ +# Feature Gate Checking + +**TODO**: this chapter diff --git a/src/mir/construction.md b/src/mir/construction.md index 52d1f4609..f353eacdf 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -1,4 +1,4 @@ -# MIR construction +# HAIR and MIR construction The lowering of [HIR] to [MIR] occurs for the following (probably incomplete) list of items: diff --git a/src/overview.md b/src/overview.md new file mode 100644 index 000000000..140d2f352 --- /dev/null +++ b/src/overview.md @@ -0,0 +1,3 @@ +# Overview of the Compiler + +Coming soon! Work is in progress on this chapter. See https://github.com/rust-lang/rustc-dev-guide/pull/633 for the source and the [project README](https://github.com/rust-lang/rustc-dev-guide) for local build instructions. diff --git a/src/part-2-intro.md b/src/part-2-intro.md index 1a47f21e5..dc774f0c6 100644 --- a/src/part-2-intro.md +++ b/src/part-2-intro.md @@ -1,12 +1,15 @@ # Part 2: How rustc works -This part of the guide describes how the compiler works. It goes through -everything from high-level structure of the compiler to how each stage of -compilation works. +The remaining parts of this guide discuss how the compiler works. They go +through everything from high-level structure of the compiler to how each stage +of compilation works. They should be friendly to both readers interested in the +end-to-end process of compilation _and_ readers interested in learning about a +specific system they wish to contribute to. If anything is unclear, feel free +to file an issue on the [rustc-dev-guide +repo](https://github.com/rust-lang/rustc-dev-guide/issues) or contact the compiler +team, as detailed in [this chapter from Part 1](./compiler-team.md). -This section should be friendly to both readers interested in the end-to-end -process of compilation _and_ readers interested in learning about a specific -system they wish to contribute to. If anything is unclear, feel free to file -an issue on the [rustc-dev-guide repo](https://github.com/rust-lang/rustc-dev-guide) -or contact the compiler team, as detailed in [this chapter from Part -1](./compiler-team.md). +In this part, we will specifically look at the high-level architecture of the +compiler. Specifically, will look at the query system, incremental compilation, +and interning. These are three overarching design choices that impact the whole +compiler. diff --git a/src/part-3-intro.md b/src/part-3-intro.md new file mode 100644 index 000000000..a1ec3ca90 --- /dev/null +++ b/src/part-3-intro.md @@ -0,0 +1,8 @@ +# Part 3: Source Code Representations + +This part describes the process of taking raw source code from the user and +transforming it into various forms that the compiler can work with easily. +These are called intermediate representations. + +This process starts with compiler understanding what the user has asked for: +parsing the command line arguments given and determining what it is to compile. diff --git a/src/part-4-intro.md b/src/part-4-intro.md new file mode 100644 index 000000000..00a74f308 --- /dev/null +++ b/src/part-4-intro.md @@ -0,0 +1,12 @@ +# Part 4: Analysis + +This part discusses the many analyses that the compiler uses to check various +properties of the code and to inform later stages. Typically, this is what people +mean when they talk about "Rust's type system". This includes the +representation, inference, and checking of types, the trait system, and the +borrow checker. These analyses do not happen as one big pass or set of +contiguous passes. Rather, they are spread out throughout various parts of the +compilation process and use different intermediate representations. For example, +type checking happens on the HIR, while borrow checking happens on the MIR. +Nonetheless, for the sake of presentation, we will discuss all of these +analyses in this part of the guide. diff --git a/src/backend/backend.md b/src/part-5-intro.md similarity index 66% rename from src/backend/backend.md rename to src/part-5-intro.md index 0eaa72036..41c3eceb2 100644 --- a/src/backend/backend.md +++ b/src/part-5-intro.md @@ -1,19 +1,20 @@ -# The Compiler Backend +# From MIR to binaries All of the preceding chapters of this guide have one thing in common: we never generated any executable machine code at all! With this chapter, all of that changes. -It's often useful to think of compilers as being composed of a _frontend_ and a -_backend_ (though in rustc, there's not a sharp line between frontend and -backend). The _frontend_ is responsible for taking raw source code, checking it -for correctness, and getting it into a format usable by the backend. For rustc, -this format is the MIR. The _backend_ refers to the parts of the compiler that -turn rustc's MIR into actual executable code (e.g. an ELF or EXE binary) that -can run on a processor. All of the previous chapters deal with rustc's -frontend. +So far, we've shown how the compiler can take raw source code in text format +and transform it into MIR. We have also shown how the compiler does various +analyses on the code to detect things like type or lifetime errors. Now, we +will finally take the MIR and produce some executable machine code. -rustc's backend does the following: +> NOTE: This part of a compiler is often called the _backend_ the term is a bit +> overloaded because in the compiler source, it usually refers to the "codegen +> backend" (i.e. LLVM or Cranelift). Usually, when you see the word "backend" +> in this part, we are refering to the "codegen backend". + +So what do we need to do? 0. First, we need to collect the set of things to generate code for. In particular, we need to find out which concrete types to substitute for @@ -23,15 +24,15 @@ rustc's backend does the following: collecting all the concrete types is called _monomorphization collection_. 1. Next, we need to actually lower the MIR to a codegen IR (usually LLVM IR) for each concrete type we collected. -2. Finally, we need to invoke the codegen backend (e.g. LLVM or Cranelift), - which runs a bunch of optimization passes, generates executable code, and - links together an executable binary. +2. Finally, we need to invoke LLVM or Cranelift, which runs a bunch of + optimization passes, generates executable code, and links together an + executable binary. [codegen1]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html The code for codegen is actually a bit complex due to a few factors: -- Support for multiple backends (LLVM and Cranelift). We try to share as much +- Support for multiple codegen backends (LLVM and Cranelift). We try to share as much backend code between them as possible, so a lot of it is generic over the codegen implementation. This means that there are often a lot of layers of abstraction. @@ -48,3 +49,4 @@ crate contains code specific to LLVM codegen. At a very high level, the entry point is [`rustc_codegen_ssa::base::codegen_crate`][codegen1]. This function starts the process discussed in the rest of this chapter. + diff --git a/src/pat-exhaustive-checking.md b/src/pat-exhaustive-checking.md new file mode 100644 index 000000000..b29bb1351 --- /dev/null +++ b/src/pat-exhaustive-checking.md @@ -0,0 +1,7 @@ +# Pattern and Exhaustiveness Checking + +In Rust, pattern matching and bindings have a few very helpful properties. The +compiler will check that bindings are irrefutable when made and that match arms +are exhaustive. + +**TODO**: write this chapter. diff --git a/src/syntax-intro.md b/src/syntax-intro.md new file mode 100644 index 000000000..dd7e2d735 --- /dev/null +++ b/src/syntax-intro.md @@ -0,0 +1,8 @@ +# Syntax and the AST + +Working directly with source code is very inconvenient and error-prone. Thus, +before we do anything else, we convert raw source code into an AST. It turns +out that doing even this involves a lot of work, including lexing, parsing, +macro expansion, name resolution, conditional compilation, feature-gate +checking, and validation of the AST. In this chapter, we take a look at all +of these steps. From daa1d91013d083d1d8b7d936f7f9d2d300e3867e Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 01:04:51 -0400 Subject: [PATCH 0901/1812] update about-this-guide.md with new Guide sections --- src/about-this-guide.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 9637c312a..164e8f869 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -6,16 +6,16 @@ development. There are six parts to this guide: -1. [Contributing][p1]: Contains information that should be useful no matter how +1. [Building, Debugging, and Contributing to `rustc`][p1]: Contains information that should be useful no matter how you are contributing, such as procedures for contribution, building the compiler, etc. -2. [High-level Compiler Architecture][p2]: Discusses the high-level - architecture of the compiler, especially the query system. -3. [The Compiler Frontend][p3]: Discusses the compiler frontend and internal - representations. -4. [The Type System][p4]: Discusses the type system. -5. [The Compiler Backend][p5]: Discusses the compiler backend, code generation, - linking, and debug info. +2. [How `rustc` Works][p2]: Discusses the high-level + architecture of the compiler and stages of the compile process +3. [Source Code Representation][p3]: Describes the process of taking raw source code from the user and + transforming it into various forms that the compiler can work with easily +4. [Analysis][p4]: discusses the analyses that the compiler uses to check various + properties of the code and inform later stages of the compile process +5. [From MIR to Binaries][p5]: How linked executable machine code is generated 6. [Appendices][app] at the end with useful reference information. There are a few of these with different information, inluding a glossary. @@ -26,7 +26,7 @@ There are six parts to this guide: [p5]: ./part-5-intro.md [app]: ./appendix/background.md -The guide itself is of course open-source as well, and the sources can +The Guide itself is of course open-source as well, and the sources can be found at the [GitHub repository]. If you find any mistakes in the guide, please file an issue about it, or even better, open a PR with a correction! @@ -35,12 +35,12 @@ with a correction! You might also find the following sites useful: -- [Rustc API docs] -- rustdoc documentation for the compiler +- [rustc API docs] -- rustdoc documentation for the compiler - [Forge] -- contains documentation about rust infrastructure, team procedures, and more - [compiler-team] -- the home-base for the rust compiler team, with description of the team procedures, active working groups, and the team calendar. [GitHub repository]: https://github.com/rust-lang/rustc-dev-guide/ -[Rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ +[rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ [Forge]: https://forge.rust-lang.org/ [compiler-team]: https://github.com/rust-lang/compiler-team/ From 2e90d882416e129321fef7c1f357f1a37f7c7a2e Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 01:05:14 -0400 Subject: [PATCH 0902/1812] consistent section title casing --- src/part-1-intro.md | 2 +- src/part-2-intro.md | 2 +- src/part-5-intro.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/part-1-intro.md b/src/part-1-intro.md index 7597c7128..95d2f8fcc 100644 --- a/src/part-1-intro.md +++ b/src/part-1-intro.md @@ -1,4 +1,4 @@ -# Part 1: Building, debugging, and contributing to Rustc +# Part 1: Building, Debugging, and Contributing to `rustc` This section of the rustc-dev-guide contains knowledge that should be useful to you regardless of what part of the compiler you are working on. This includes both diff --git a/src/part-2-intro.md b/src/part-2-intro.md index dc774f0c6..04bb32cdb 100644 --- a/src/part-2-intro.md +++ b/src/part-2-intro.md @@ -1,4 +1,4 @@ -# Part 2: How rustc works +# Part 2: How `rustc` Works The remaining parts of this guide discuss how the compiler works. They go through everything from high-level structure of the compiler to how each stage diff --git a/src/part-5-intro.md b/src/part-5-intro.md index 41c3eceb2..184d0ee3a 100644 --- a/src/part-5-intro.md +++ b/src/part-5-intro.md @@ -1,4 +1,4 @@ -# From MIR to binaries +# From MIR to Binaries All of the preceding chapters of this guide have one thing in common: we never generated any executable machine code at all! With this chapter, all of that From 826eddfbccabcafaa5d907b2d418b85d3ce0b2d0 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 12:15:57 -0400 Subject: [PATCH 0903/1812] mark-i-m review edits --- src/about-this-guide.md | 10 +++++----- src/part-2-intro.md | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 164e8f869..58b0cb9f0 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -9,13 +9,13 @@ There are six parts to this guide: 1. [Building, Debugging, and Contributing to `rustc`][p1]: Contains information that should be useful no matter how you are contributing, such as procedures for contribution, building the compiler, etc. -2. [How `rustc` Works][p2]: Discusses the high-level - architecture of the compiler and stages of the compile process +2. [High-Level Compiler Architecture][p2]: Discusses the high-level + architecture of the compiler and stages of the compile process. 3. [Source Code Representation][p3]: Describes the process of taking raw source code from the user and - transforming it into various forms that the compiler can work with easily + transforming it into various forms that the compiler can work with easily. 4. [Analysis][p4]: discusses the analyses that the compiler uses to check various - properties of the code and inform later stages of the compile process -5. [From MIR to Binaries][p5]: How linked executable machine code is generated + properties of the code and inform later stages of the compile process (e.g., type checking). +5. [From MIR to Binaries][p5]: How linked executable machine code is generated. 6. [Appendices][app] at the end with useful reference information. There are a few of these with different information, inluding a glossary. diff --git a/src/part-2-intro.md b/src/part-2-intro.md index 04bb32cdb..04ae3f955 100644 --- a/src/part-2-intro.md +++ b/src/part-2-intro.md @@ -1,4 +1,4 @@ -# Part 2: How `rustc` Works +# Part 2: High-Level Compiler Architecture The remaining parts of this guide discuss how the compiler works. They go through everything from high-level structure of the compiler to how each stage From 7adfab42bab045a848126895c2f1e09927c1331a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 8 Apr 2020 01:52:05 -0500 Subject: [PATCH 0904/1812] fix a link (#672) --- src/traits/chalk-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md index 88ae7b5a2..64cb589c1 100644 --- a/src/traits/chalk-overview.md +++ b/src/traits/chalk-overview.md @@ -229,7 +229,7 @@ Likewise, lowering tests use the [`lowering_success!` and [rustc-issues]: https://github.com/rust-lang/rustc-dev-guide/issues [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification -[`ProgramClause`]: https://rust-lang.github.io/chalk/chalk_ir/enum.ProgramClause.html +[`ProgramClause`]: https://rust-lang.github.io/chalk/chalk_ir/struct.ProgramClause.html [`ProgramEnvironment`]: https://rust-lang.github.io/chalk/chalk_integration/program_environment/struct.ProgramEnvironment.html [chalk_engine]: https://rust-lang.github.io/chalk/chalk_engine [chalk_ir]: https://rust-lang.github.io/chalk/chalk_ir/index.html From b315ce521963fba3b20f3cae0598efc492d9f56b Mon Sep 17 00:00:00 2001 From: Arlo Siemsen Date: Tue, 24 Mar 2020 15:34:03 -0700 Subject: [PATCH 0905/1812] Add section describing source file checksums in debug info --- src/debugging-support-in-rustc.md | 43 ++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 4 deletions(-) diff --git a/src/debugging-support-in-rustc.md b/src/debugging-support-in-rustc.md index a11edba78..912ceffae 100644 --- a/src/debugging-support-in-rustc.md +++ b/src/debugging-support-in-rustc.md @@ -268,6 +268,45 @@ Focus is to let macros decide what to do. This can be achieved by having some ki that lets the macro tell the compiler where the line marker should be. This affects where you set the breakpoints and what happens when you step it. +## Source file checksums in debug info + +Both DWARF and CodeView (PDB) support embedding a cryptographic hash of each source file that +contributed to the associated binary. + +The cryptographic hash can be used by a debugger to verify that the source file matches the +executable. If the source file does not match, the debugger can provide a warning to the user. + +The hash can also be used to prove that a given source file has not been modified since it was +used to compile an executable. Because MD5 and SHA1 both have demonstrated vulnerabilities, +using SHA256 is recommended for this application. + +The Rust compiler stores the hash for each source file in the corresponding `SourceFile` in +the `SourceMap`. The hashes of input files to external crates are stored in `rlib` metadata. + +A default hashing algorithm is set in the target specification. This allows the target to +specify the best hash available, since not all targets support all hash algorithms. + +The hashing algorithm for a target can also be overridden with the `-Z source-file-checksum=` +command-line option. + +#### DWARF 5 +DWARF version 5 supports embedding an MD5 hash to validate the source file version in use. +DWARF 5 - Section 6.2.4.1 opcode DW_LNCT_MD5 + +#### LLVM +LLVM IR supports MD5 and SHA1 (and SHA256 in LLVM 11+) source file checksums in the DIFile node. + +[LLVM DIFile documentation](https://llvm.org/docs/LangRef.html#difile) + +#### Microsoft Visual C++ Compiler /ZH option +The MSVC compiler supports embedding MD5, SHA1, or SHA256 hashes in the PDB using the `/ZH` +compiler option. + +[MSVC /ZH documentation](https://docs.microsoft.com/en-us/cpp/build/reference/zh) + +#### Clang +Clang always embeds an MD5 checksum, though this does not appear in documentation. + ## Future work #### Name mangling changes @@ -295,10 +334,6 @@ They implement just the expression language but they also add some extensions li convenience variables. Therefore, if you are taking this route then you not only need to do this bridge but may have to add some mode to let the compiler understand some extensions. -#### Windows debugging (PDB) is missing - -This is a complete unknown. - [Tom Tromey discusses debugging support in rustc]: https://www.youtube.com/watch?v=elBxMRSNYr4 [Debugging the Compiler]: compiler-debugging.md [debugger or debugging tool]: https://en.wikipedia.org/wiki/Debugger From f9b673309f791f3e8fee6fc385e71ddcd51795e4 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sat, 11 Apr 2020 19:34:25 +0200 Subject: [PATCH 0906/1812] codegen tests: add link to LLVM FileCheck docs (#673) --- src/tests/intro.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/tests/intro.md b/src/tests/intro.md index a81255dec..fd0e50c83 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -36,6 +36,8 @@ details. - `debuginfo` – tests that run in gdb or lldb and query the debug info - `codegen` – tests that compile and then test the generated LLVM code to make sure that the optimizations we want are taking effect. + See [LLVM docs](https://llvm.org/docs/CommandGuide/FileCheck.html) for how to + write such tests. - `assembly` – similar to `codegen` tests, but verifies assembly output to make sure LLVM target backend can handle provided code. - `mir-opt` – tests that check parts of the generated MIR to make From d7b4c7e899292381a08f4eadcb7b417d86d10662 Mon Sep 17 00:00:00 2001 From: Jan-Erik Rediger Date: Fri, 17 Apr 2020 14:16:56 +0200 Subject: [PATCH 0907/1812] Start with the basics (#675) * The very first step should be to clone the repository * Make the command copy-able By having the plain command users can select and copy the text and paste it, without needing to fiddle around to remove extra characters. Now that the previous command switched directories it is not necessary to be called out here again either. * Update src/building/how-to-build-and-run.md Co-authored-by: Yuki Okushi --- src/building/how-to-build-and-run.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index dbe1f4c7a..5171e5f31 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -6,6 +6,15 @@ be hacking on `rustc`, you'll want to tweak the configuration of the compiler. The default configuration is oriented towards running the compiler as a user, not a developer. +## Get the source code + +The very first step to work on `rustc` is to clone the repository: + +```bash +git clone https://github.com/rust-lang/rust.git +cd rust +``` + ## Create a config.toml To start, copy [`config.toml.example`] to `config.toml`: @@ -13,8 +22,7 @@ To start, copy [`config.toml.example`] to `config.toml`: [`config.toml.example`]: https://github.com/rust-lang/rust/blob/master/config.toml.example ```bash -> cd $RUST_CHECKOUT -> cp config.toml.example config.toml +cp config.toml.example config.toml ``` Then you will want to open up the file and change the following From fe12e05523a2528c405bdfbed7ed295acad9bfd1 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 25 Mar 2020 23:26:17 -0500 Subject: [PATCH 0908/1812] add overview --- src/SUMMARY.md | 1 - src/overview.md | 326 +++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 325 insertions(+), 2 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index d6cbe0645..28abd8d65 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -33,7 +33,6 @@ - ["Cleanup Crew" ICE-breakers](ice-breaker/cleanup-crew.md) - [LLVM ICE-breakers](ice-breaker/llvm.md) - [Licenses](./licenses.md) - - [Part 2: High-level Compiler Architecture](./part-2-intro.md) - [Overview of the Compiler](./overview.md) - [The compiler source code](./compiler-src.md) diff --git a/src/overview.md b/src/overview.md index 140d2f352..546f0ad13 100644 --- a/src/overview.md +++ b/src/overview.md @@ -1,3 +1,327 @@ # Overview of the Compiler -Coming soon! Work is in progress on this chapter. See https://github.com/rust-lang/rustc-dev-guide/pull/633 for the source and the [project README](https://github.com/rust-lang/rustc-dev-guide) for local build instructions. +This chapter is about the overall process of compiling a program -- how +everything fits together. + +The rust compiler is special in two ways: it does things to your code that +other compilers don't do (e.g. borrow checking) and it has a lot of +unconventional implementation choices (e.g. queries). We will talk about these +in turn in this chapter, and in the rest of the guide, we will look at all the +individual pieces in more detail. + +## What the compiler does to your code + +So first, let's look at what the compiler does to your code. For now, we will +avoid mentioning how the compiler implements these steps except as needed; +we'll talk about that later. + +**TODO: Would be great to have a diagram of this once we nail down the details...** + +**TODO: someone else should confirm this vvv** + +- User writes a program and invokes `rustc` on it (possibly through `cargo`). +- First, we parse command line flags, etc. This is done in [`librustc_driver`]. + We now know what the exact work is we need to do (e.g. which nightly features + are enabled, whether we are doing a `check`-only build or emiting LLVM-IR or + a full compilation). +- Then, we start to do compilation... +- We first [_lex_ the user program][lex]. This turns the program into a stream + of _tokens_ (yes, the same sort of tokens as `proc_macros` (sort of)). + [`StringReader`] from [`librustc_parse`] integrates [`librustc_lexer`] with + `rustc` data structures. +- We then [_parse_ the stream of tokens][parser] to build an Abstract Syntax + Tree (AST). +- We then take the AST and [convert it to High-Level Intermediate + Representation (HIR)][hir]. This is a compiler-friendly representation of the + AST. This involves a lot of desugaring of things like loops and `async fn`. +- We use the HIR to do [type inference]. This is the process of automatic + detection of the type of an expression. **TODO: how `ty` module fits in + here** +- **TODO: Maybe some other things are done here? I think initial type checking + happens here? And trait solving?** +- The HIR is then [lowered to Mid-Level Intermediate Representation (MIR)][mir]. +- The MIR is used for [borrow checking]. +- **TODO: const eval fits in somewhere here I think** +- We (want to) do [many optimizations on the MIR][mir-opt] because it is still + generic and that improves the code we generate later, improving compilation + speed too. (**TODO: size optimizations too?**) + - MIR is a higher level (and generic) representation, so it is easier to do + some optimizations at MIR level than at LLVM-IR level. For example LLVM + doesn't seem to be able to optimize the pattern the [`simplify_try`] mir + opt looks for. +- Rust code is _monomorphized_, which means making copies of all the generic + code with the type parameters replaced by concrete types. In order to do + this, we need to collect a list of what concrete types to generate code for. + This is called _monomorphization collection_. +- We then begin what is vaguely called _code generation_ or _codegen_. + - The [code generation stage (codegen)][codegen] is when higher level + representations of source are turned into an executable binary. `rustc` + uses LLVM for code generation. The first step is the MIR is then + converted to LLVM Intermediate Representation (LLVM IR). This is where + the MIR is actually monomorphized, according to the list we created in + the previous step. + - The LLVM IR is passed to LLVM, which does a lot more optimizations on it. + It then emits machine code. It is basically assembly code with additional + low-level types and annotations added. (e.g. an ELF object or wasm). + **TODO: reference for this section?** + - The different libraries/binaries are linked together to produce the final + binary. **TODO: reference for this section?** + +[`librustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html +[`librustc_driver`]: https://rust-lang.github.io/rustc-guide/rustc-driver.html +[lex]: https://rust-lang.github.io/rustc-guide/the-parser.html +[`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html +[`librustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html +[parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html +[hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html +[type inference]: https://rust-lang.github.io/rustc-guide/type-inference.html +[mir]: https://rust-lang.github.io/rustc-guide/mir/index.html +[borrow checker]: https://rust-lang.github.io/rustc-guide/borrow_check.html +[mir-opt]: https://rust-lang.github.io/rustc-guide/mir/optimizations.html +[`simplify_try`]: https://github.com/rust-lang/rust/pull/66282 +[codegen]: https://rust-lang.github.io/rustc-guide/codegen.html + +## How it does it + +Ok, so now that we have a high-level view of what the compiler does to your +code, let's take a high-level view of _how_ it does all that stuff. There are a +lot of constraints and conflicting goals that the compiler needs to +satisfy/optimize for. For example, + +- Compilation speed: how fast is it to compile a program. More/better + compile-time analyses often means compilation is slower. + - Also, we want to support incremental compilation, so we need to take that + into account. How can we keep track of what work needs to be redone and + what can be reused if the user modifies their program? + - Also we can't store too much stuff in the incremental cache because + it would take a long time to load from disk and it could take a lot + of space on the user's system... +- Compiler memory usage: while compiling a program, we don't want to use more + memory than we need. +- Program speed: how fast is your compiled program. More/better compile-time + analyses often means the compiler can do better optimizations. +- Program size: how large is the compiled binary? Similar to the previous + point. +- Compiler compilation speed: how long does it take to compile the compiler? + This impacts contributors and compiler maintenance. +- Compiler implementation complexity: building a compiler is one of the hardest + things a person/group can do, and rust is not a very simple language, so how + do we make the compiler's code base manageable? +- Compiler correctness: the binaries produced by the compiler should do what + the input programs says they do, and should continue to do so despite the + tremendous amount of change constantly going on. +- Compiler integration: a number of other tools need to use the compiler in + various ways (e.g. cargo, clippy, miri, RLS) that must be supported. +- Compiler stability: the compiler should not crash or fail ungracefully on the + stable channel. +- Rust stability: the compiler must respect rust's stability guarantees by not + breaking programs that previously compiled despite the many changes that are + always going on to its implementation. +- Limitations of other tools: rustc uses LLVM in its backend, and LLVM has some + strengths we leverage and some limitations/weaknesses we need to work around. +- And others that I'm probably forgetting. + +So, as you read through the rest of the guide, keep these things in mind. They +will often inform decisions that we make. + +### Constant change + +One thing to keep in mind is that `rustc` is a real production-quality product. +As such, it has its fair share of codebase churn and technical debt. A lot of +the designs discussed throughout this guide are idealized designs that are not +fully realized yet. And things keep changing so that it is hard to keep this +guide completely up to date on everything! + +The compiler definitely has rough edges, but because of its design it is able +to keep up with the requirements above. + +### Intermediate representations + +As with most compilers, `rustc` uses some intermediate representations (IRs) to +facilitate computations. In general, working directly with the source code is +extremely inconvenient. Source code is designed to be human-friendly while at +the same time being unambiguous, but it's less convenient for doing something +like, say, type checking. + +Instead most compilers, including `rustc`, build some sort of IR out of the +source code which is easier to analyze. `rustc` has a few IRs, each optimized +for different things: + +- Abstract Syntax Tree (AST): the abstract syntax tree is built from the stream + of tokens produced by the lexer directly from the source code. It represents + pretty much exactly what the user wrote. It helps to do some syntactic sanity + checking (e.g. checking that a type is expected where the user wrote one). +- High-level IR (HIR): This is a sort of very desugared AST. It's still close + to what the user wrote syntactically, but it includes some implicit things + such as some elided lifetimes, etc. This IR is amenable to type checking. +- HAIR: This is an intermediate between HIR and MIR. This only exists to make + it easier to lower HIR to MIR. +- Middle-level IR (MIR): This IR is basically a Control-Flow Graph (CFG). A CFG + is a type of diagram that shows the basic blocks of a program and how control + flow can go between them. Likewise, MIR also has a bunch of basic blocks with + simple typed statements inside them (e.g. assignment, simple computations, + dropping values, etc). MIR is used for borrow checking and a bunch of other + important dataflow based checks, such as checking for uninitialized values. + It is also used for a bunch of optimizations and for constant evaluation (via + MIRI). Because MIR is still generic, we can do a lot of analyses here more + efficiently than after monomorphization. +- LLVM IR: This is the standard form of all input to the LLVM compiler. LLVM IR + is basically a sort of typed assembly language with lots of annotations. It's + a standard format that is used by all compilers that use LLVM (e.g. the clang + C compiler also outputs LLVM IR). LLVM IR is designed to be easy for other + compilers to emit and also rich enough for LLVM to run a bunch of + optimizations on it. + +### Queries + +The first big implementation choice is the _query_ system. The rust compiler +uses a query system which is unlike most textbook compilers, which are +organized as a series of passes over the code that execute sequentially. The +compiler does this to make incremental compilation possible -- that is, if the +user makes a change to their program and recompiles, we want to do as little +redundant work as possible to produce the new binary. + +In rustc, all the major steps above are organized as a bunch of queries that +call each other. For example, there is a query to ask for the type of something +and another to ask for the optimized MIR of a function, and so on. These +queries can call each other and are all tracked through the query system, and +the results of the queries are cached on disk so that we can tell which +queries' results changed from the last compilation and only redo those. This is +how incremental compilation works. + +In principle, for the query-fied steps, we do each of the above for each item +individually. For example, we will take the HIR for a function and use queries +to ask for the LLVM IR for that HIR. This drives the generation of optimized +MIR, which drives the borrow checker, which drives the generation of MIR, and +so on. + +... except that this is very over-simplified. In fact, some queries are not +cached on disk, and some parts of the compiler have to run for all code anyway +for correctness even if the code is dead code (e.g. the borrow checker). For +example, [currently the `mir_borrowck` query is first executed on all functions +of a crate.][passes] Then the codegen backend invokes the +`collect_and_partition_mono_items` query, which first recursively requests the +`optimized_mir` for all reachable functions, which in turn runs `mir_borrowck` +for that function and then creates codegen units. This kind of split will need +to remain to ensure that unreachable functions still have their errors emitted. + +[passes]: https://github.com/rust-lang/rust/blob/45ebd5808afd3df7ba842797c0fcd4447ddf30fb/src/librustc_interface/passes.rs#L824 + +Moreover, the compiler wasn't originally built to use a query system; the query +system has been retrofitted into the compiler, so parts of it are not +query-fied yet. Also, LLVM isn't our code, so obviously that isn't querified +either. The plan is to eventually query-fy all of the steps listed in the +previous section, but as of this writing, only the steps between HIR and +LLVM-IR are query-fied. That is, lexing and parsing are done all at once for +the whole program. + +One other thing to mention here is the all-important "typing context", +[`TyCtxt`], which is a giant struct that is at the center of all things. All +queries are defined as methods on the [`TyCtxt`] type, and the in-memory query +cache is stored there too. In the code, there is usually a variable called +`tcx` which is a handle on the typing context. You will also see lifetimes with +the name `'tcx`, which means that something is tied to the lifetime of the +`TyCtxt` (usually it is stored or _interned_ there). + +[`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html + +### `ty::Ty` + +Types are really important in Rust, and they form the core of a lot of compiler +analyses. The main type (in the compiler) that represents types (in the user's +program) is [`rustc::ty::Ty`][ty]. This is so important that we have a whole chapter +on [`ty::Ty`][ty], but for now, we just want to mention that it exists and is the way +`rustc` represents types! + +Oh, and also the `rustc::ty` module defines the `TyCtxt` struct we mentioned before. + +[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html + +### Parallelism + +Compiler performance is a problem that we would very much like to improve on +(and are always working on). One aspect of that is attempting to parallelize +`rustc` itself. + +Currently, there is only one part of rustc that is already parallel: codegen. +During monomorphization, the compiler will split up all the code to be +generated into smaller chunks called _codegen units_. These are then generated +by independent instances of LLVM. Since they are independent, we can run them +in parallel. At the end, the linker is run to combine all the codegen units +together into one binary. + +However, the rest of the compiler is still not yet parallel. There have been +lots of efforts spent on this, but it is generally a hard problem. The current +approach is (**TODO: verify**) to turn `RefCell`s into `Mutex`s -- that is, we +switch to thread-safe internal mutability. However, there are ongoing +challenges with lock contention, maintaining query-system invariants under +concurrency, and the complexity of the code base. One can try out the current +work by enabling parallel compilation in `config.toml`. It's still early days, +but there are already some promising performance improvements. + +### Bootstrapping + +**TODO (or do we want such a section)?** + +## A flow chart or walkthrough diagram + +**TODO** + +# Unresolved Questions + +**TODO: find answers to these** + +- Does LLVM ever do optimizations in debug builds? +- How do I explore phases of the compile process in my own sources (lexer, + parser, HIR, etc)? - e.g., `cargo rustc -- -Zunpretty=hir-tree` allows you to + view HIR representation +- What is the main source entry point for `X`? +- Where do phases diverge for cross-compilation to machine code across + different platforms? + +# References + +- Command line parsing + - Guide: [The Rustc Driver and Interface](https://rust-lang.github.io/rustc-guide/rustc-driver.html) + - Driver definition: [`rustc_driver`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/) + - Main entry point: **TODO** +- Lexical Analysis: Lex the user program to a stream of tokens + - Guide: [Lexing and Parsing](https://rust-lang.github.io/rustc-guide/the-parser.html) + - Lexer definition: [`librustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html) + - Main entry point: **TODO** +- Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST) + - Guide: [Lexing and Parsing](https://rust-lang.github.io/rustc-guide/the-parser.html) + - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) + - Main entry point: **TODO** + - AST definition: [`syntax`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/index.html) +- The High Level Intermediate Representation (HIR) + - Guide: [The HIR](https://rust-lang.github.io/rustc-guide/hir.html) + - Guide: [Identifiers in the HIR](https://rust-lang.github.io/rustc-guide/hir.html#identifiers-in-the-hir) + - Guide: [The HIR Map](https://rust-lang.github.io/rustc-guide/hir.html#the-hir-map) + - Guide: [Lowering AST to HIR](https://rust-lang.github.io/rustc-guide/lowering.html) + - How to view HIR representation for your code `cargo rustc -- -Zunpretty=hir-tree` + - Rustc HIR definition: [`rustc_hir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html) + - Main entry point: **TODO** +- Type Inference + - Guide: [Type Inference](https://rust-lang.github.io/rustc-guide/type-inference.html) + - Guide: [The ty Module: Representing Types](https://rust-lang.github.io/rustc-guide/ty.html) (semantics) + - Main entry point: **TODO** +- The Mid Level Intermediate Representation (MIR) + - Guide: [The MIR (Mid level IR)](https://rust-lang.github.io/rustc-guide/mir/index.html) + - Definition: [`librustc/mir`](https://github.com/rust-lang/rust/tree/master/src/librustc/mir) + - Definition of source that manipulates the MIR: [`librustc_mir`](https://github.com/rust-lang/rust/tree/master/src/librustc_mir) + - Main entry point: **TODO** +- The Borrow Checker + - Guide: [MIR Borrow Check](https://rust-lang.github.io/rustc-guide/borrow_check.html) + - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html) + - Main entry point: **TODO** +- MIR Optimizations + - Guide: [MIR Optimizations](https://rust-lang.github.io/rustc-guide/mir/optimizations.html) + - Definition: [`rustc_mir/transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html) **TODO: is this correct?** + - Main entry point: **TODO** +- Code Generation + - Guide: [Code Generation](https://rust-lang.github.io/rustc-guide/codegen.html) + - Guide: [Generating LLVM IR](https://rust-lang.github.io/rustc-guide/codegen.html#generating-llvm-ir) - **TODO: this is not available yet** + - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** + - Main entry point MIR -> LLVM IR: **TODO** + - Main entry point LLVM IR -> Machine Code **TODO** From 62e6bd01317e229b89d8eabb6c710cebb6469886 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 28 Mar 2020 06:47:45 -0500 Subject: [PATCH 0909/1812] correct a few links --- src/overview.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/src/overview.md b/src/overview.md index 546f0ad13..c8b44d1c0 100644 --- a/src/overview.md +++ b/src/overview.md @@ -72,8 +72,8 @@ we'll talk about that later. [lex]: https://rust-lang.github.io/rustc-guide/the-parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html [`librustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html -[parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html -[hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html +[parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parser/index.html +[hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html [type inference]: https://rust-lang.github.io/rustc-guide/type-inference.html [mir]: https://rust-lang.github.io/rustc-guide/mir/index.html [borrow checker]: https://rust-lang.github.io/rustc-guide/borrow_check.html @@ -263,10 +263,6 @@ but there are already some promising performance improvements. **TODO (or do we want such a section)?** -## A flow chart or walkthrough diagram - -**TODO** - # Unresolved Questions **TODO: find answers to these** @@ -293,7 +289,7 @@ but there are already some promising performance improvements. - Guide: [Lexing and Parsing](https://rust-lang.github.io/rustc-guide/the-parser.html) - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) - Main entry point: **TODO** - - AST definition: [`syntax`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/index.html) + - AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html) - The High Level Intermediate Representation (HIR) - Guide: [The HIR](https://rust-lang.github.io/rustc-guide/hir.html) - Guide: [Identifiers in the HIR](https://rust-lang.github.io/rustc-guide/hir.html#identifiers-in-the-hir) From a43ef4d3b3f01fed9b880bd678eb66439425fa8a Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 2 Apr 2020 20:12:31 -0500 Subject: [PATCH 0910/1812] Apply Centril suggestions Co-Authored-By: Centril --- src/overview.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/src/overview.md b/src/overview.md index c8b44d1c0..82aa63705 100644 --- a/src/overview.md +++ b/src/overview.md @@ -50,7 +50,7 @@ we'll talk about that later. doesn't seem to be able to optimize the pattern the [`simplify_try`] mir opt looks for. - Rust code is _monomorphized_, which means making copies of all the generic - code with the type parameters replaced by concrete types. In order to do + code with the type parameters replaced by concrete types. To do this, we need to collect a list of what concrete types to generate code for. This is called _monomorphization collection_. - We then begin what is vaguely called _code generation_ or _codegen_. @@ -105,7 +105,7 @@ satisfy/optimize for. For example, - Compiler compilation speed: how long does it take to compile the compiler? This impacts contributors and compiler maintenance. - Compiler implementation complexity: building a compiler is one of the hardest - things a person/group can do, and rust is not a very simple language, so how + things a person/group can do, and Rust is not a very simple language, so how do we make the compiler's code base manageable? - Compiler correctness: the binaries produced by the compiler should do what the input programs says they do, and should continue to do so despite the @@ -119,14 +119,13 @@ satisfy/optimize for. For example, always going on to its implementation. - Limitations of other tools: rustc uses LLVM in its backend, and LLVM has some strengths we leverage and some limitations/weaknesses we need to work around. -- And others that I'm probably forgetting. So, as you read through the rest of the guide, keep these things in mind. They will often inform decisions that we make. ### Constant change -One thing to keep in mind is that `rustc` is a real production-quality product. +Keep in mind that `rustc` is a real production-quality product. As such, it has its fair share of codebase churn and technical debt. A lot of the designs discussed throughout this guide are idealized designs that are not fully realized yet. And things keep changing so that it is hard to keep this @@ -139,19 +138,19 @@ to keep up with the requirements above. As with most compilers, `rustc` uses some intermediate representations (IRs) to facilitate computations. In general, working directly with the source code is -extremely inconvenient. Source code is designed to be human-friendly while at +extremely inconvenient and error-prone. Source code is designed to be human-friendly while at the same time being unambiguous, but it's less convenient for doing something like, say, type checking. Instead most compilers, including `rustc`, build some sort of IR out of the source code which is easier to analyze. `rustc` has a few IRs, each optimized -for different things: +for different purposes: - Abstract Syntax Tree (AST): the abstract syntax tree is built from the stream of tokens produced by the lexer directly from the source code. It represents pretty much exactly what the user wrote. It helps to do some syntactic sanity checking (e.g. checking that a type is expected where the user wrote one). -- High-level IR (HIR): This is a sort of very desugared AST. It's still close +- High-level IR (HIR): This is a sort of desugared AST. It's still close to what the user wrote syntactically, but it includes some implicit things such as some elided lifetimes, etc. This IR is amenable to type checking. - HAIR: This is an intermediate between HIR and MIR. This only exists to make @@ -166,7 +165,7 @@ for different things: MIRI). Because MIR is still generic, we can do a lot of analyses here more efficiently than after monomorphization. - LLVM IR: This is the standard form of all input to the LLVM compiler. LLVM IR - is basically a sort of typed assembly language with lots of annotations. It's + is a sort of typed assembly language with lots of annotations. It's a standard format that is used by all compilers that use LLVM (e.g. the clang C compiler also outputs LLVM IR). LLVM IR is designed to be easy for other compilers to emit and also rich enough for LLVM to run a bunch of @@ -181,9 +180,9 @@ compiler does this to make incremental compilation possible -- that is, if the user makes a change to their program and recompiles, we want to do as little redundant work as possible to produce the new binary. -In rustc, all the major steps above are organized as a bunch of queries that +In `rustc`, all the major steps above are organized as a bunch of queries that call each other. For example, there is a query to ask for the type of something -and another to ask for the optimized MIR of a function, and so on. These +and another to ask for the optimized MIR of a function. These queries can call each other and are all tracked through the query system, and the results of the queries are cached on disk so that we can tell which queries' results changed from the last compilation and only redo those. This is @@ -209,7 +208,7 @@ to remain to ensure that unreachable functions still have their errors emitted. Moreover, the compiler wasn't originally built to use a query system; the query system has been retrofitted into the compiler, so parts of it are not -query-fied yet. Also, LLVM isn't our code, so obviously that isn't querified +query-fied yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to eventually query-fy all of the steps listed in the previous section, but as of this writing, only the steps between HIR and LLVM-IR are query-fied. That is, lexing and parsing are done all at once for @@ -239,8 +238,8 @@ Oh, and also the `rustc::ty` module defines the `TyCtxt` struct we mentioned bef ### Parallelism -Compiler performance is a problem that we would very much like to improve on -(and are always working on). One aspect of that is attempting to parallelize +Compiler performance is a problem that we would like to improve on +(and are always working on). One aspect of that is parallelizing `rustc` itself. Currently, there is only one part of rustc that is already parallel: codegen. From 0783019c123a14235102bb4afdc52e4026c7e48b Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Fri, 3 Apr 2020 01:41:04 -0400 Subject: [PATCH 0911/1812] [overview.md] Add command line argument parsing, lexer stages, and parser outline --- src/overview.md | 132 ++++++++++++++++++++++++------------------------ 1 file changed, 66 insertions(+), 66 deletions(-) diff --git a/src/overview.md b/src/overview.md index 82aa63705..ee8761149 100644 --- a/src/overview.md +++ b/src/overview.md @@ -19,16 +19,16 @@ we'll talk about that later. **TODO: someone else should confirm this vvv** -- User writes a program and invokes `rustc` on it (possibly through `cargo`). -- First, we parse command line flags, etc. This is done in [`librustc_driver`]. - We now know what the exact work is we need to do (e.g. which nightly features - are enabled, whether we are doing a `check`-only build or emiting LLVM-IR or - a full compilation). -- Then, we start to do compilation... -- We first [_lex_ the user program][lex]. This turns the program into a stream - of _tokens_ (yes, the same sort of tokens as `proc_macros` (sort of)). - [`StringReader`] from [`librustc_parse`] integrates [`librustc_lexer`] with - `rustc` data structures. +- The compile process begins when a user writes a Rust source program in text and invokes the `rustc` compiler on it. The work that the compiler needs to perform is defined with command line options. For example, it is possible to optionally enable nightly features, perform `check`-only builds, or emit LLVM-IR rather than complete the entire compile process defined here. The `rustc` executable call may be indirect through the use of `cargo`. +- Command line argument parsing occurs in the [`librustc_driver`]. This crate defines the compile configuration that is requested by the user. +- The raw Rust source text is analyzed by a low-level lexer located in [`librustc_lexer`]. At this stage, the source text is turned into a stream of atomic source code units known as _tokens_. (**TODO**: chrissimpkins - Maybe discuss Unicode handling during this stage?) +- The token stream passes through a higher-level lexer located in [`librustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations and turn strings into interned symbols. +- (**TODO**: chrissimpkins - Expand info on parser) We then [_parse_ the stream of tokens][parser] to build an Abstract Syntax Tree (AST). + - macro expansion (**TODO** chrissimpkins) + - ast validation (**TODO** chrissimpkins) + - nameres (**TODO** chrissimpkins) + - early linting (**TODO** chrissimpkins) + - We then [_parse_ the stream of tokens][parser] to build an Abstract Syntax Tree (AST). - We then take the AST and [convert it to High-Level Intermediate @@ -45,27 +45,27 @@ we'll talk about that later. - We (want to) do [many optimizations on the MIR][mir-opt] because it is still generic and that improves the code we generate later, improving compilation speed too. (**TODO: size optimizations too?**) - - MIR is a higher level (and generic) representation, so it is easier to do - some optimizations at MIR level than at LLVM-IR level. For example LLVM - doesn't seem to be able to optimize the pattern the [`simplify_try`] mir - opt looks for. + - MIR is a higher level (and generic) representation, so it is easier to do + some optimizations at MIR level than at LLVM-IR level. For example LLVM + doesn't seem to be able to optimize the pattern the [`simplify_try`] mir + opt looks for. - Rust code is _monomorphized_, which means making copies of all the generic code with the type parameters replaced by concrete types. To do this, we need to collect a list of what concrete types to generate code for. This is called _monomorphization collection_. - We then begin what is vaguely called _code generation_ or _codegen_. - - The [code generation stage (codegen)][codegen] is when higher level - representations of source are turned into an executable binary. `rustc` + - The [code generation stage (codegen)][codegen] is when higher level + representations of source are turned into an executable binary. `rustc` uses LLVM for code generation. The first step is the MIR is then - converted to LLVM Intermediate Representation (LLVM IR). This is where - the MIR is actually monomorphized, according to the list we created in - the previous step. - - The LLVM IR is passed to LLVM, which does a lot more optimizations on it. - It then emits machine code. It is basically assembly code with additional - low-level types and annotations added. (e.g. an ELF object or wasm). - **TODO: reference for this section?** - - The different libraries/binaries are linked together to produce the final - binary. **TODO: reference for this section?** + converted to LLVM Intermediate Representation (LLVM IR). This is where + the MIR is actually monomorphized, according to the list we created in + the previous step. + - The LLVM IR is passed to LLVM, which does a lot more optimizations on it. + It then emits machine code. It is basically assembly code with additional + low-level types and annotations added. (e.g. an ELF object or wasm). + **TODO: reference for this section?** + - The different libraries/binaries are linked together to produce the final + binary. **TODO: reference for this section?** [`librustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html [`librustc_driver`]: https://rust-lang.github.io/rustc-guide/rustc-driver.html @@ -90,12 +90,12 @@ satisfy/optimize for. For example, - Compilation speed: how fast is it to compile a program. More/better compile-time analyses often means compilation is slower. - - Also, we want to support incremental compilation, so we need to take that - into account. How can we keep track of what work needs to be redone and - what can be reused if the user modifies their program? - - Also we can't store too much stuff in the incremental cache because - it would take a long time to load from disk and it could take a lot - of space on the user's system... + - Also, we want to support incremental compilation, so we need to take that + into account. How can we keep track of what work needs to be redone and + what can be reused if the user modifies their program? + - Also we can't store too much stuff in the incremental cache because + it would take a long time to load from disk and it could take a lot + of space on the user's system... - Compiler memory usage: while compiling a program, we don't want to use more memory than we need. - Program speed: how fast is your compiled program. More/better compile-time @@ -277,46 +277,46 @@ but there are already some promising performance improvements. # References - Command line parsing - - Guide: [The Rustc Driver and Interface](https://rust-lang.github.io/rustc-guide/rustc-driver.html) - - Driver definition: [`rustc_driver`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/) - - Main entry point: **TODO** + - Guide: [The Rustc Driver and Interface](https://rust-lang.github.io/rustc-guide/rustc-driver.html) + - Driver definition: [`rustc_driver`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/) + - Main entry point: **TODO** - Lexical Analysis: Lex the user program to a stream of tokens - - Guide: [Lexing and Parsing](https://rust-lang.github.io/rustc-guide/the-parser.html) - - Lexer definition: [`librustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html) - - Main entry point: **TODO** + - Guide: [Lexing and Parsing](https://rust-lang.github.io/rustc-guide/the-parser.html) + - Lexer definition: [`librustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html) + - Main entry point: **TODO** - Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST) - - Guide: [Lexing and Parsing](https://rust-lang.github.io/rustc-guide/the-parser.html) - - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) - - Main entry point: **TODO** - - AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html) + - Guide: [Lexing and Parsing](https://rust-lang.github.io/rustc-guide/the-parser.html) + - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) + - Main entry point: **TODO** + - AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html) - The High Level Intermediate Representation (HIR) - - Guide: [The HIR](https://rust-lang.github.io/rustc-guide/hir.html) - - Guide: [Identifiers in the HIR](https://rust-lang.github.io/rustc-guide/hir.html#identifiers-in-the-hir) - - Guide: [The HIR Map](https://rust-lang.github.io/rustc-guide/hir.html#the-hir-map) - - Guide: [Lowering AST to HIR](https://rust-lang.github.io/rustc-guide/lowering.html) - - How to view HIR representation for your code `cargo rustc -- -Zunpretty=hir-tree` - - Rustc HIR definition: [`rustc_hir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html) - - Main entry point: **TODO** + - Guide: [The HIR](https://rust-lang.github.io/rustc-guide/hir.html) + - Guide: [Identifiers in the HIR](https://rust-lang.github.io/rustc-guide/hir.html#identifiers-in-the-hir) + - Guide: [The HIR Map](https://rust-lang.github.io/rustc-guide/hir.html#the-hir-map) + - Guide: [Lowering AST to HIR](https://rust-lang.github.io/rustc-guide/lowering.html) + - How to view HIR representation for your code `cargo rustc -- -Zunpretty=hir-tree` + - Rustc HIR definition: [`rustc_hir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html) + - Main entry point: **TODO** - Type Inference - - Guide: [Type Inference](https://rust-lang.github.io/rustc-guide/type-inference.html) - - Guide: [The ty Module: Representing Types](https://rust-lang.github.io/rustc-guide/ty.html) (semantics) - - Main entry point: **TODO** + - Guide: [Type Inference](https://rust-lang.github.io/rustc-guide/type-inference.html) + - Guide: [The ty Module: Representing Types](https://rust-lang.github.io/rustc-guide/ty.html) (semantics) + - Main entry point: **TODO** - The Mid Level Intermediate Representation (MIR) - - Guide: [The MIR (Mid level IR)](https://rust-lang.github.io/rustc-guide/mir/index.html) - - Definition: [`librustc/mir`](https://github.com/rust-lang/rust/tree/master/src/librustc/mir) - - Definition of source that manipulates the MIR: [`librustc_mir`](https://github.com/rust-lang/rust/tree/master/src/librustc_mir) - - Main entry point: **TODO** + - Guide: [The MIR (Mid level IR)](https://rust-lang.github.io/rustc-guide/mir/index.html) + - Definition: [`librustc/mir`](https://github.com/rust-lang/rust/tree/master/src/librustc/mir) + - Definition of source that manipulates the MIR: [`librustc_mir`](https://github.com/rust-lang/rust/tree/master/src/librustc_mir) + - Main entry point: **TODO** - The Borrow Checker - - Guide: [MIR Borrow Check](https://rust-lang.github.io/rustc-guide/borrow_check.html) - - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html) - - Main entry point: **TODO** + - Guide: [MIR Borrow Check](https://rust-lang.github.io/rustc-guide/borrow_check.html) + - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html) + - Main entry point: **TODO** - MIR Optimizations - - Guide: [MIR Optimizations](https://rust-lang.github.io/rustc-guide/mir/optimizations.html) - - Definition: [`rustc_mir/transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html) **TODO: is this correct?** - - Main entry point: **TODO** + - Guide: [MIR Optimizations](https://rust-lang.github.io/rustc-guide/mir/optimizations.html) + - Definition: [`rustc_mir/transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html) **TODO: is this correct?** + - Main entry point: **TODO** - Code Generation - - Guide: [Code Generation](https://rust-lang.github.io/rustc-guide/codegen.html) - - Guide: [Generating LLVM IR](https://rust-lang.github.io/rustc-guide/codegen.html#generating-llvm-ir) - **TODO: this is not available yet** - - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** - - Main entry point MIR -> LLVM IR: **TODO** - - Main entry point LLVM IR -> Machine Code **TODO** + - Guide: [Code Generation](https://rust-lang.github.io/rustc-guide/codegen.html) + - Guide: [Generating LLVM IR](https://rust-lang.github.io/rustc-guide/codegen.html#generating-llvm-ir) - **TODO: this is not available yet** + - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** + - Main entry point MIR -> LLVM IR: **TODO** + - Main entry point LLVM IR -> Machine Code **TODO** From df51d81272e4947be491e39d8fc59e6431738b7e Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Fri, 3 Apr 2020 09:54:12 -0400 Subject: [PATCH 0912/1812] Update src/overview.md Co-Authored-By: LeSeulArtichaut --- src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index ee8761149..efb96a68f 100644 --- a/src/overview.md +++ b/src/overview.md @@ -19,7 +19,7 @@ we'll talk about that later. **TODO: someone else should confirm this vvv** -- The compile process begins when a user writes a Rust source program in text and invokes the `rustc` compiler on it. The work that the compiler needs to perform is defined with command line options. For example, it is possible to optionally enable nightly features, perform `check`-only builds, or emit LLVM-IR rather than complete the entire compile process defined here. The `rustc` executable call may be indirect through the use of `cargo`. +- The compile process begins when a user writes a Rust source program in text and invokes the `rustc` compiler on it. The work that the compiler needs to perform is defined by command-line options. For example, it is possible to enable nightly features (`-Z` flags), perform `check`-only builds, or emit LLVM-IR rather than executable machine code. The `rustc` executable call may be indirect through the use of `cargo`. - Command line argument parsing occurs in the [`librustc_driver`]. This crate defines the compile configuration that is requested by the user. - The raw Rust source text is analyzed by a low-level lexer located in [`librustc_lexer`]. At this stage, the source text is turned into a stream of atomic source code units known as _tokens_. (**TODO**: chrissimpkins - Maybe discuss Unicode handling during this stage?) - The token stream passes through a higher-level lexer located in [`librustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations and turn strings into interned symbols. From 10d683943442ef27da0e8150dbf5e3be89b4e875 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Fri, 3 Apr 2020 09:59:09 -0400 Subject: [PATCH 0913/1812] Update src/overview.md Co-Authored-By: LeSeulArtichaut --- src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index efb96a68f..f0b2887de 100644 --- a/src/overview.md +++ b/src/overview.md @@ -20,7 +20,7 @@ we'll talk about that later. **TODO: someone else should confirm this vvv** - The compile process begins when a user writes a Rust source program in text and invokes the `rustc` compiler on it. The work that the compiler needs to perform is defined by command-line options. For example, it is possible to enable nightly features (`-Z` flags), perform `check`-only builds, or emit LLVM-IR rather than executable machine code. The `rustc` executable call may be indirect through the use of `cargo`. -- Command line argument parsing occurs in the [`librustc_driver`]. This crate defines the compile configuration that is requested by the user. +- Command line argument parsing occurs in the [`librustc_driver`]. This crate defines the compile configuration that is requested by the user and passes it to the rest of the compilation process as a [`rustc_interface::Config`]. - The raw Rust source text is analyzed by a low-level lexer located in [`librustc_lexer`]. At this stage, the source text is turned into a stream of atomic source code units known as _tokens_. (**TODO**: chrissimpkins - Maybe discuss Unicode handling during this stage?) - The token stream passes through a higher-level lexer located in [`librustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations and turn strings into interned symbols. - (**TODO**: chrissimpkins - Expand info on parser) We then [_parse_ the stream of tokens][parser] to build an Abstract Syntax Tree (AST). From 9fd274d9673264da0ef797968c19bdd5a46ff53d Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:30:45 -0500 Subject: [PATCH 0914/1812] fix old rustc-dev-guide links --- src/overview.md | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/src/overview.md b/src/overview.md index f0b2887de..148d7ab34 100644 --- a/src/overview.md +++ b/src/overview.md @@ -68,18 +68,18 @@ we'll talk about that later. binary. **TODO: reference for this section?** [`librustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html -[`librustc_driver`]: https://rust-lang.github.io/rustc-guide/rustc-driver.html -[lex]: https://rust-lang.github.io/rustc-guide/the-parser.html +[`librustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html +[lex]: https://rustc-dev-guide.rust-lang.org/the-parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html [`librustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parser/index.html [hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html -[type inference]: https://rust-lang.github.io/rustc-guide/type-inference.html -[mir]: https://rust-lang.github.io/rustc-guide/mir/index.html -[borrow checker]: https://rust-lang.github.io/rustc-guide/borrow_check.html -[mir-opt]: https://rust-lang.github.io/rustc-guide/mir/optimizations.html +[type inference]: https://rustc-dev-guide.rust-lang.org/type-inference.html +[mir]: https://rustc-dev-guide.rust-lang.org/mir/index.html +[borrow checker]: https://rustc-dev-guide.rust-lang.org/borrow_check.html +[mir-opt]: https://rustc-dev-guide.rust-lang.org/mir/optimizations.html [`simplify_try`]: https://github.com/rust-lang/rust/pull/66282 -[codegen]: https://rust-lang.github.io/rustc-guide/codegen.html +[codegen]: https://rustc-dev-guide.rust-lang.org/codegen.html ## How it does it @@ -277,46 +277,46 @@ but there are already some promising performance improvements. # References - Command line parsing - - Guide: [The Rustc Driver and Interface](https://rust-lang.github.io/rustc-guide/rustc-driver.html) + - Guide: [The Rustc Driver and Interface](https://rustc-dev-guide.rust-lang.org/rustc-driver.html) - Driver definition: [`rustc_driver`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/) - Main entry point: **TODO** - Lexical Analysis: Lex the user program to a stream of tokens - - Guide: [Lexing and Parsing](https://rust-lang.github.io/rustc-guide/the-parser.html) + - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - Lexer definition: [`librustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html) - Main entry point: **TODO** - Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST) - - Guide: [Lexing and Parsing](https://rust-lang.github.io/rustc-guide/the-parser.html) + - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) - Main entry point: **TODO** - AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html) - The High Level Intermediate Representation (HIR) - - Guide: [The HIR](https://rust-lang.github.io/rustc-guide/hir.html) - - Guide: [Identifiers in the HIR](https://rust-lang.github.io/rustc-guide/hir.html#identifiers-in-the-hir) - - Guide: [The HIR Map](https://rust-lang.github.io/rustc-guide/hir.html#the-hir-map) - - Guide: [Lowering AST to HIR](https://rust-lang.github.io/rustc-guide/lowering.html) + - Guide: [The HIR](https://rustc-dev-guide.rust-lang.org/hir.html) + - Guide: [Identifiers in the HIR](https://rustc-dev-guide.rust-lang.org/hir.html#identifiers-in-the-hir) + - Guide: [The HIR Map](https://rustc-dev-guide.rust-lang.org/hir.html#the-hir-map) + - Guide: [Lowering AST to HIR](https://rustc-dev-guide.rust-lang.org/lowering.html) - How to view HIR representation for your code `cargo rustc -- -Zunpretty=hir-tree` - Rustc HIR definition: [`rustc_hir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html) - Main entry point: **TODO** - Type Inference - - Guide: [Type Inference](https://rust-lang.github.io/rustc-guide/type-inference.html) - - Guide: [The ty Module: Representing Types](https://rust-lang.github.io/rustc-guide/ty.html) (semantics) + - Guide: [Type Inference](https://rustc-dev-guide.rust-lang.org/type-inference.html) + - Guide: [The ty Module: Representing Types](https://rustc-dev-guide.rust-lang.org/ty.html) (semantics) - Main entry point: **TODO** - The Mid Level Intermediate Representation (MIR) - - Guide: [The MIR (Mid level IR)](https://rust-lang.github.io/rustc-guide/mir/index.html) + - Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html) - Definition: [`librustc/mir`](https://github.com/rust-lang/rust/tree/master/src/librustc/mir) - Definition of source that manipulates the MIR: [`librustc_mir`](https://github.com/rust-lang/rust/tree/master/src/librustc_mir) - Main entry point: **TODO** - The Borrow Checker - - Guide: [MIR Borrow Check](https://rust-lang.github.io/rustc-guide/borrow_check.html) + - Guide: [MIR Borrow Check](https://rustc-dev-guide.rust-lang.org/borrow_check.html) - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html) - Main entry point: **TODO** - MIR Optimizations - - Guide: [MIR Optimizations](https://rust-lang.github.io/rustc-guide/mir/optimizations.html) + - Guide: [MIR Optimizations](https://rustc-dev-guide.rust-lang.org/mir/optimizations.html) - Definition: [`rustc_mir/transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html) **TODO: is this correct?** - Main entry point: **TODO** - Code Generation - - Guide: [Code Generation](https://rust-lang.github.io/rustc-guide/codegen.html) - - Guide: [Generating LLVM IR](https://rust-lang.github.io/rustc-guide/codegen.html#generating-llvm-ir) - **TODO: this is not available yet** + - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/codegen.html) + - Guide: [Generating LLVM IR](https://rustc-dev-guide.rust-lang.org/codegen.html#generating-llvm-ir) - **TODO: this is not available yet** - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** - Main entry point MIR -> LLVM IR: **TODO** - Main entry point LLVM IR -> Machine Code **TODO** From cb68eca0c1622493ffe6365d0b0217cda0971b24 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:46:14 -0500 Subject: [PATCH 0915/1812] Add some entry points Co-Authored-By: LeSeulArtichaut --- src/overview.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/src/overview.md b/src/overview.md index 148d7ab34..9c6b71b76 100644 --- a/src/overview.md +++ b/src/overview.md @@ -279,11 +279,11 @@ but there are already some promising performance improvements. - Command line parsing - Guide: [The Rustc Driver and Interface](https://rustc-dev-guide.rust-lang.org/rustc-driver.html) - Driver definition: [`rustc_driver`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/) - - Main entry point: **TODO** + - Main entry point: [`rustc_session::config::build_session_options`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/config/fn.build_session_options.html) - Lexical Analysis: Lex the user program to a stream of tokens - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - Lexer definition: [`librustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html) - - Main entry point: **TODO** + - Main entry point: [`rustc_lexer::tokenize`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/fn.tokenize.html) - Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST) - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) @@ -309,14 +309,13 @@ but there are already some promising performance improvements. - The Borrow Checker - Guide: [MIR Borrow Check](https://rustc-dev-guide.rust-lang.org/borrow_check.html) - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html) - - Main entry point: **TODO** + - Main entry point: [`mir_borrowck` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/fn.mir_borrowck.html) - MIR Optimizations - Guide: [MIR Optimizations](https://rustc-dev-guide.rust-lang.org/mir/optimizations.html) - Definition: [`rustc_mir/transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html) **TODO: is this correct?** - - Main entry point: **TODO** + - Main entry point: [`optimized_mir` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html) - Code Generation - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/codegen.html) - Guide: [Generating LLVM IR](https://rustc-dev-guide.rust-lang.org/codegen.html#generating-llvm-ir) - **TODO: this is not available yet** - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** - - Main entry point MIR -> LLVM IR: **TODO** - - Main entry point LLVM IR -> Machine Code **TODO** + - Main entry point MIR -> Machine Code: [`rustc_codegen_ssa::base::codegen_crate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html) From 4c50a79b08f733fed397b90084c5ad0ab18d69d5 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:50:27 -0500 Subject: [PATCH 0916/1812] mention the hair --- src/overview.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/overview.md b/src/overview.md index 9c6b71b76..0648ac7e1 100644 --- a/src/overview.md +++ b/src/overview.md @@ -40,6 +40,9 @@ we'll talk about that later. - **TODO: Maybe some other things are done here? I think initial type checking happens here? And trait solving?** - The HIR is then [lowered to Mid-Level Intermediate Representation (MIR)][mir]. + - Along the way, we construct the HAIR, which is an even more desugared HIR. + HAIR is used for pattern and exhaustiveness checking. It is also more + convenient to convert into MIR than HIR is. - The MIR is used for [borrow checking]. - **TODO: const eval fits in somewhere here I think** - We (want to) do [many optimizations on the MIR][mir-opt] because it is still From cc6b01346051926b0af8e60eaa07b0208ba899fb Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:52:55 -0500 Subject: [PATCH 0917/1812] mention token stream as an IR --- src/overview.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 0648ac7e1..cebff545d 100644 --- a/src/overview.md +++ b/src/overview.md @@ -149,8 +149,11 @@ Instead most compilers, including `rustc`, build some sort of IR out of the source code which is easier to analyze. `rustc` has a few IRs, each optimized for different purposes: +- Token stream: the lexer produces a stream of tokens directly from the source + code. This stream of tokens is easier for the parser to deal with than raw + text. - Abstract Syntax Tree (AST): the abstract syntax tree is built from the stream - of tokens produced by the lexer directly from the source code. It represents + of tokens produced by the lexer. It represents pretty much exactly what the user wrote. It helps to do some syntactic sanity checking (e.g. checking that a type is expected where the user wrote one). - High-level IR (HIR): This is a sort of desugared AST. It's still close From 2d81262bc0e12ac8d7ef5c79b16545ad7b649386 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:57:14 -0500 Subject: [PATCH 0918/1812] correct the note about HAIR --- src/overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/overview.md b/src/overview.md index cebff545d..8f6d00d7e 100644 --- a/src/overview.md +++ b/src/overview.md @@ -29,8 +29,6 @@ we'll talk about that later. - nameres (**TODO** chrissimpkins) - early linting (**TODO** chrissimpkins) -- We then [_parse_ the stream of tokens][parser] to build an Abstract Syntax - Tree (AST). - We then take the AST and [convert it to High-Level Intermediate Representation (HIR)][hir]. This is a compiler-friendly representation of the AST. This involves a lot of desugaring of things like loops and `async fn`. @@ -159,8 +157,10 @@ for different purposes: - High-level IR (HIR): This is a sort of desugared AST. It's still close to what the user wrote syntactically, but it includes some implicit things such as some elided lifetimes, etc. This IR is amenable to type checking. -- HAIR: This is an intermediate between HIR and MIR. This only exists to make - it easier to lower HIR to MIR. +- HAIR: This is an intermediate between HIR and MIR. It is like the HIR but it + is fully typed and a bit more desugared (e.g. method calls and implicit + dereferences are made fully explicit). Moreover, it is easier to lower to MIR + than HIR. - Middle-level IR (MIR): This IR is basically a Control-Flow Graph (CFG). A CFG is a type of diagram that shows the basic blocks of a program and how control flow can go between them. Likewise, MIR also has a bunch of basic blocks with From cc3fb247dd627e8010025ced56f1039d0a9d62ab Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 12:59:51 -0500 Subject: [PATCH 0919/1812] Improve description of MIR Co-Authored-By: Centril --- src/overview.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/overview.md b/src/overview.md index 8f6d00d7e..37a082070 100644 --- a/src/overview.md +++ b/src/overview.md @@ -165,9 +165,10 @@ for different purposes: is a type of diagram that shows the basic blocks of a program and how control flow can go between them. Likewise, MIR also has a bunch of basic blocks with simple typed statements inside them (e.g. assignment, simple computations, - dropping values, etc). MIR is used for borrow checking and a bunch of other - important dataflow based checks, such as checking for uninitialized values. - It is also used for a bunch of optimizations and for constant evaluation (via + etc) and control flow edges to other basic blocks (e.g., calls, dropping + values). MIR is used for borrow checking and other + important dataflow-based checks, such as checking for uninitialized values. + It is also used for a series of optimizations and for constant evaluation (via MIRI). Because MIR is still generic, we can do a lot of analyses here more efficiently than after monomorphization. - LLVM IR: This is the standard form of all input to the LLVM compiler. LLVM IR From 6cdb777909789f2147fbc6cb5b9452d8f6d0aac0 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:02:04 -0500 Subject: [PATCH 0920/1812] break long sentence --- src/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/overview.md b/src/overview.md index 37a082070..3bd60904f 100644 --- a/src/overview.md +++ b/src/overview.md @@ -190,8 +190,8 @@ redundant work as possible to produce the new binary. In `rustc`, all the major steps above are organized as a bunch of queries that call each other. For example, there is a query to ask for the type of something and another to ask for the optimized MIR of a function. These -queries can call each other and are all tracked through the query system, and -the results of the queries are cached on disk so that we can tell which +queries can call each other and are all tracked through the query system. +The results of the queries are cached on disk so that we can tell which queries' results changed from the last compilation and only redo those. This is how incremental compilation works. From e154e2684d29b0946e3a5e2ba1bf541aee9caed4 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:04:36 -0500 Subject: [PATCH 0921/1812] add a note on tcx name --- src/overview.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 3bd60904f..d92142e38 100644 --- a/src/overview.md +++ b/src/overview.md @@ -222,7 +222,10 @@ LLVM-IR are query-fied. That is, lexing and parsing are done all at once for the whole program. One other thing to mention here is the all-important "typing context", -[`TyCtxt`], which is a giant struct that is at the center of all things. All +[`TyCtxt`], which is a giant struct that is at the center of all things. +(Note that the name is mostly historic. This is _not_ a "typing context" in the +sense of `Γ` or `Δ` from type theory. The name is retained because that's what +the name of the struct is in the source code.) All queries are defined as methods on the [`TyCtxt`] type, and the in-memory query cache is stored there too. In the code, there is usually a variable called `tcx` which is a handle on the typing context. You will also see lifetimes with From 31ae8b8b07a312df5cc83ff24457b0043c131f51 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:17:04 -0500 Subject: [PATCH 0922/1812] write a bit about bootstrapping --- src/overview.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index d92142e38..7b8cae839 100644 --- a/src/overview.md +++ b/src/overview.md @@ -270,7 +270,23 @@ but there are already some promising performance improvements. ### Bootstrapping -**TODO (or do we want such a section)?** +`rustc` itself is written in Rust. So how do we compile the compiler? We use an +older compiler to compile the newer compiler. This is called _bootstrapping_. + +Bootstrapping has a lot of interesting implications. For example, it means that one +of the major users of Rust is Rust, so we are constantly testing our own +software ("eating our own dogfood"). Also, it means building the compiler can +take a long time because one must first build the compiler and then use that to +build the new compiler (sometimes you can get away without the full 2-stage +build, but for release artifacts you need the 2-stage build). + +Bootstrapping also has implications for when features are usable in the +compiler itself. The build system uses the current beta compiler to build the +stage-1 bootstrapping compiler. This means that the compiler source code can't +use some features until they reach beta (because otherwise the beta compiler +doesn't support them). On the other hand, for compiler intrinsics and internal +features, we may be able to use them immediately because the stage-1 +bootstrapping compiler will support them. # Unresolved Questions From 443e47cb1f124ae02a49e04fddba27e9707a9d09 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:19:21 -0500 Subject: [PATCH 0923/1812] add a few todos --- src/overview.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/overview.md b/src/overview.md index 7b8cae839..350ff5523 100644 --- a/src/overview.md +++ b/src/overview.md @@ -315,6 +315,10 @@ bootstrapping compiler will support them. - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) - Main entry point: **TODO** - AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html) + - Expansion: **TODO** + - Name Resolution: **TODO** + - Feature gating: **TODO** + - Early linting: **TODO** - The High Level Intermediate Representation (HIR) - Guide: [The HIR](https://rustc-dev-guide.rust-lang.org/hir.html) - Guide: [Identifiers in the HIR](https://rustc-dev-guide.rust-lang.org/hir.html#identifiers-in-the-hir) @@ -323,6 +327,7 @@ bootstrapping compiler will support them. - How to view HIR representation for your code `cargo rustc -- -Zunpretty=hir-tree` - Rustc HIR definition: [`rustc_hir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html) - Main entry point: **TODO** + - Late linting: **TODO** - Type Inference - Guide: [Type Inference](https://rustc-dev-guide.rust-lang.org/type-inference.html) - Guide: [The ty Module: Representing Types](https://rustc-dev-guide.rust-lang.org/ty.html) (semantics) From beb654898f6b27e9e6ac04eeffe333a656be5db8 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:20:48 -0500 Subject: [PATCH 0924/1812] line lengths --- src/overview.md | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/src/overview.md b/src/overview.md index 350ff5523..26f7a2ad1 100644 --- a/src/overview.md +++ b/src/overview.md @@ -19,11 +19,25 @@ we'll talk about that later. **TODO: someone else should confirm this vvv** -- The compile process begins when a user writes a Rust source program in text and invokes the `rustc` compiler on it. The work that the compiler needs to perform is defined by command-line options. For example, it is possible to enable nightly features (`-Z` flags), perform `check`-only builds, or emit LLVM-IR rather than executable machine code. The `rustc` executable call may be indirect through the use of `cargo`. -- Command line argument parsing occurs in the [`librustc_driver`]. This crate defines the compile configuration that is requested by the user and passes it to the rest of the compilation process as a [`rustc_interface::Config`]. -- The raw Rust source text is analyzed by a low-level lexer located in [`librustc_lexer`]. At this stage, the source text is turned into a stream of atomic source code units known as _tokens_. (**TODO**: chrissimpkins - Maybe discuss Unicode handling during this stage?) -- The token stream passes through a higher-level lexer located in [`librustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations and turn strings into interned symbols. -- (**TODO**: chrissimpkins - Expand info on parser) We then [_parse_ the stream of tokens][parser] to build an Abstract Syntax Tree (AST). +- The compile process begins when a user writes a Rust source program in text + and invokes the `rustc` compiler on it. The work that the compiler needs to + perform is defined by command-line options. For example, it is possible to + enable nightly features (`-Z` flags), perform `check`-only builds, or emit + LLVM-IR rather than executable machine code. The `rustc` executable call may + be indirect through the use of `cargo`. +- Command line argument parsing occurs in the [`librustc_driver`]. This crate + defines the compile configuration that is requested by the user and passes it + to the rest of the compilation process as a [`rustc_interface::Config`]. +- The raw Rust source text is analyzed by a low-level lexer located in + [`librustc_lexer`]. At this stage, the source text is turned into a stream of + atomic source code units known as _tokens_. (**TODO**: chrissimpkins - Maybe + discuss Unicode handling during this stage?) +- The token stream passes through a higher-level lexer located in + [`librustc_parse`] to prepare for the next stage of the compile process. The + [`StringReader`] struct is used at this stage to perform a set of validations + and turn strings into interned symbols. +- (**TODO**: chrissimpkins - Expand info on parser) We then [_parse_ the stream + of tokens][parser] to build an Abstract Syntax Tree (AST). - macro expansion (**TODO** chrissimpkins) - ast validation (**TODO** chrissimpkins) - nameres (**TODO** chrissimpkins) From fe38e8a9de49c6224724f46ee73769e4108ec502 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:23:23 -0500 Subject: [PATCH 0925/1812] fix links --- src/overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 26f7a2ad1..4d5ff03b4 100644 --- a/src/overview.md +++ b/src/overview.md @@ -84,6 +84,7 @@ we'll talk about that later. [`librustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html [`librustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html +[`rustc_interface::Config`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Config.html [lex]: https://rustc-dev-guide.rust-lang.org/the-parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html [`librustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html @@ -91,7 +92,7 @@ we'll talk about that later. [hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html [type inference]: https://rustc-dev-guide.rust-lang.org/type-inference.html [mir]: https://rustc-dev-guide.rust-lang.org/mir/index.html -[borrow checker]: https://rustc-dev-guide.rust-lang.org/borrow_check.html +[borrow checking]: https://rustc-dev-guide.rust-lang.org/borrow_check.html [mir-opt]: https://rustc-dev-guide.rust-lang.org/mir/optimizations.html [`simplify_try`]: https://github.com/rust-lang/rust/pull/66282 [codegen]: https://rustc-dev-guide.rust-lang.org/codegen.html From 55e7d6d1ed00f9c9901098ad3bced08b78433da0 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:27:24 -0500 Subject: [PATCH 0926/1812] remove a todo --- src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 4d5ff03b4..e2dc1e12b 100644 --- a/src/overview.md +++ b/src/overview.md @@ -358,7 +358,7 @@ bootstrapping compiler will support them. - Main entry point: [`mir_borrowck` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/fn.mir_borrowck.html) - MIR Optimizations - Guide: [MIR Optimizations](https://rustc-dev-guide.rust-lang.org/mir/optimizations.html) - - Definition: [`rustc_mir/transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html) **TODO: is this correct?** + - Definition: [`rustc_mir/transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html) - Main entry point: [`optimized_mir` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html) - Code Generation - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/codegen.html) From 0d0611b7d95a3225ecb573dda7ed9cd7254177f2 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 4 Apr 2020 13:30:40 -0500 Subject: [PATCH 0927/1812] add an entry point --- src/overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index e2dc1e12b..9b67343af 100644 --- a/src/overview.md +++ b/src/overview.md @@ -364,4 +364,5 @@ bootstrapping compiler will support them. - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/codegen.html) - Guide: [Generating LLVM IR](https://rustc-dev-guide.rust-lang.org/codegen.html#generating-llvm-ir) - **TODO: this is not available yet** - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** - - Main entry point MIR -> Machine Code: [`rustc_codegen_ssa::base::codegen_crate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html) + - Main entry point MIR -> LLVM IR: [`MonoItem::define`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/mono_item/enum.MonoItem.html#method.define) + - Main entry point LLVM IR -> Machine Code: [`rustc_codegen_ssa::base::codegen_crate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html) From 7a58fdc10ca186f9b00aeaf68244f0caeebdb5fb Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 14 Apr 2020 15:15:32 -0500 Subject: [PATCH 0928/1812] Improve wording Co-Authored-By: Santiago Pastorino --- src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 9b67343af..7660b2c53 100644 --- a/src/overview.md +++ b/src/overview.md @@ -175,7 +175,7 @@ for different purposes: - HAIR: This is an intermediate between HIR and MIR. It is like the HIR but it is fully typed and a bit more desugared (e.g. method calls and implicit dereferences are made fully explicit). Moreover, it is easier to lower to MIR - than HIR. + from HAIR than from HIR. - Middle-level IR (MIR): This IR is basically a Control-Flow Graph (CFG). A CFG is a type of diagram that shows the basic blocks of a program and how control flow can go between them. Likewise, MIR also has a bunch of basic blocks with From 5afed5f5adbb2729453999ce6df68ef3ee243880 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:03:08 -0500 Subject: [PATCH 0929/1812] fix lexer entry point --- src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 7660b2c53..09285c5ba 100644 --- a/src/overview.md +++ b/src/overview.md @@ -324,7 +324,7 @@ bootstrapping compiler will support them. - Lexical Analysis: Lex the user program to a stream of tokens - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - Lexer definition: [`librustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html) - - Main entry point: [`rustc_lexer::tokenize`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/fn.tokenize.html) + - Main entry point: [`rustc_lexer::first_token`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/fn.first_token.html) - Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST) - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) From cf14e7aa42c61c952336af461339335af67a87cf Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 5 Apr 2020 22:20:44 -0400 Subject: [PATCH 0930/1812] [overview.md] add parser entry point links --- src/overview.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 09285c5ba..432add21c 100644 --- a/src/overview.md +++ b/src/overview.md @@ -328,7 +328,10 @@ bootstrapping compiler will support them. - Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST) - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) - - Main entry point: **TODO** + - Main entry points: + - [Entry point for first file in crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.parse.html) + - [Entry point for outline module parsing](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/module/fn.parse_external_mod.html) + - [Entry point for macro fragments](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_nt.html) - AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html) - Expansion: **TODO** - Name Resolution: **TODO** From 2f7a6b1a62f9574d99826f7da302f851d5566b35 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:12:44 -0500 Subject: [PATCH 0931/1812] add a para on interning and arenas --- src/overview.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/src/overview.md b/src/overview.md index 432add21c..7085bb2a7 100644 --- a/src/overview.md +++ b/src/overview.md @@ -35,7 +35,7 @@ we'll talk about that later. - The token stream passes through a higher-level lexer located in [`librustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations - and turn strings into interned symbols. + and turn strings into interned symbols (_interning_ is discussed later). - (**TODO**: chrissimpkins - Expand info on parser) We then [_parse_ the stream of tokens][parser] to build an Abstract Syntax Tree (AST). - macro expansion (**TODO** chrissimpkins) @@ -193,6 +193,14 @@ for different purposes: compilers to emit and also rich enough for LLVM to run a bunch of optimizations on it. +One other thing to note is that many values in the compiler are _interned_. +This is a performance and memory optimization in which we allocate the values +in a special allocator called an _arena_. Then, we pass around references to +the values allocated in the arena. This allows us to make sure that identical +values (e.g. types in your program) are only allocated once and can be compared +cheaply by comparing pointers. Many of the intermediate representations are +interned. + ### Queries The first big implementation choice is the _query_ system. The rust compiler @@ -245,7 +253,7 @@ queries are defined as methods on the [`TyCtxt`] type, and the in-memory query cache is stored there too. In the code, there is usually a variable called `tcx` which is a handle on the typing context. You will also see lifetimes with the name `'tcx`, which means that something is tied to the lifetime of the -`TyCtxt` (usually it is stored or _interned_ there). +`TyCtxt` (usually it is stored or interned there). [`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html From 2ff2f560412e683fdd6bfbc417b4d3bf6aab3b33 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:18:55 -0500 Subject: [PATCH 0932/1812] add entry points for type check and type inference Co-Authored-By: LeSeulArtichaut --- src/overview.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 7085bb2a7..a8a631b96 100644 --- a/src/overview.md +++ b/src/overview.md @@ -357,7 +357,9 @@ bootstrapping compiler will support them. - Type Inference - Guide: [Type Inference](https://rustc-dev-guide.rust-lang.org/type-inference.html) - Guide: [The ty Module: Representing Types](https://rustc-dev-guide.rust-lang.org/ty.html) (semantics) - - Main entry point: **TODO** + - Main entry point (type inference): [`InferCtxtBuilder::enter`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxtBuilder.html#method.enter) + - Main entry point (type checking bodies): [the `typeck_tables_of` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.typeck_tables_of) + - These two functions can't be decoupled. - The Mid Level Intermediate Representation (MIR) - Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html) - Definition: [`librustc/mir`](https://github.com/rust-lang/rust/tree/master/src/librustc/mir) From 52bc0f6350e00b89e6f45c45330e0c3794ddcdc5 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:30:39 -0500 Subject: [PATCH 0933/1812] some cleanup --- src/overview.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/overview.md b/src/overview.md index a8a631b96..2565f902b 100644 --- a/src/overview.md +++ b/src/overview.md @@ -17,8 +17,6 @@ we'll talk about that later. **TODO: Would be great to have a diagram of this once we nail down the details...** -**TODO: someone else should confirm this vvv** - - The compile process begins when a user writes a Rust source program in text and invokes the `rustc` compiler on it. The work that the compiler needs to perform is defined by command-line options. For example, it is possible to @@ -47,8 +45,7 @@ we'll talk about that later. Representation (HIR)][hir]. This is a compiler-friendly representation of the AST. This involves a lot of desugaring of things like loops and `async fn`. - We use the HIR to do [type inference]. This is the process of automatic - detection of the type of an expression. **TODO: how `ty` module fits in - here** + detection of the type of an expression. - **TODO: Maybe some other things are done here? I think initial type checking happens here? And trait solving?** - The HIR is then [lowered to Mid-Level Intermediate Representation (MIR)][mir]. @@ -364,7 +361,6 @@ bootstrapping compiler will support them. - Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html) - Definition: [`librustc/mir`](https://github.com/rust-lang/rust/tree/master/src/librustc/mir) - Definition of source that manipulates the MIR: [`librustc_mir`](https://github.com/rust-lang/rust/tree/master/src/librustc_mir) - - Main entry point: **TODO** - The Borrow Checker - Guide: [MIR Borrow Check](https://rustc-dev-guide.rust-lang.org/borrow_check.html) - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html) From 8eeada5768e8a3f83bbd6f06f4d74623fce2b728 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:30:48 -0500 Subject: [PATCH 0934/1812] correct entry points for codegen --- src/overview.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/overview.md b/src/overview.md index 2565f902b..751a01ec0 100644 --- a/src/overview.md +++ b/src/overview.md @@ -371,7 +371,7 @@ bootstrapping compiler will support them. - Main entry point: [`optimized_mir` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html) - Code Generation - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/codegen.html) - - Guide: [Generating LLVM IR](https://rustc-dev-guide.rust-lang.org/codegen.html#generating-llvm-ir) - **TODO: this is not available yet** - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** - - Main entry point MIR -> LLVM IR: [`MonoItem::define`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/mono_item/enum.MonoItem.html#method.define) - - Main entry point LLVM IR -> Machine Code: [`rustc_codegen_ssa::base::codegen_crate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html) + - Main entry point: [`rustc_codegen_ssa::base::codegen_crate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html) + - This monomorphizes and produces LLVM IR for one codegen unit. It then starts a background thread to run LLVM, which must be joined later. + - Monomorphization happens lazily via [`FunctionCx::monomorphize`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#method.monomorphize) From 9bf8f9ed167a95456b088ba0abbc639aa4f4d0a0 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Sun, 5 Apr 2020 22:50:28 -0400 Subject: [PATCH 0935/1812] [overview.md] add documentation of lexer support for Unicode encoding --- src/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/overview.md b/src/overview.md index 751a01ec0..d641718c8 100644 --- a/src/overview.md +++ b/src/overview.md @@ -28,8 +28,8 @@ we'll talk about that later. to the rest of the compilation process as a [`rustc_interface::Config`]. - The raw Rust source text is analyzed by a low-level lexer located in [`librustc_lexer`]. At this stage, the source text is turned into a stream of - atomic source code units known as _tokens_. (**TODO**: chrissimpkins - Maybe - discuss Unicode handling during this stage?) + atomic source code units known as _tokens_. The lexer supports the Unicode + character encoding. - The token stream passes through a higher-level lexer located in [`librustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations From c3f9d0810fca318bda5793bc43018a71e52db1d4 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:34:23 -0500 Subject: [PATCH 0936/1812] update mono entry points --- src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index d641718c8..8bfa20118 100644 --- a/src/overview.md +++ b/src/overview.md @@ -374,4 +374,4 @@ bootstrapping compiler will support them. - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** - Main entry point: [`rustc_codegen_ssa::base::codegen_crate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html) - This monomorphizes and produces LLVM IR for one codegen unit. It then starts a background thread to run LLVM, which must be joined later. - - Monomorphization happens lazily via [`FunctionCx::monomorphize`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#method.monomorphize) + - Monomorphization happens lazily via [`FunctionCx::monomorphize`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#method.monomorphize) and [`rustc_codegen_ssa::base::codegen_instance `](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_instance.html) From dc88fe372ee21f2af3eaeaee0d7c1e58be93ddee Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:37:53 -0500 Subject: [PATCH 0937/1812] minor wording change on bootstrapping --- src/overview.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/overview.md b/src/overview.md index 8bfa20118..744ef3b1f 100644 --- a/src/overview.md +++ b/src/overview.md @@ -293,12 +293,13 @@ but there are already some promising performance improvements. `rustc` itself is written in Rust. So how do we compile the compiler? We use an older compiler to compile the newer compiler. This is called _bootstrapping_. -Bootstrapping has a lot of interesting implications. For example, it means that one -of the major users of Rust is Rust, so we are constantly testing our own +Bootstrapping has a lot of interesting implications. For example, it means that +one of the major users of Rust is Rust, so we are constantly testing our own software ("eating our own dogfood"). Also, it means building the compiler can -take a long time because one must first build the compiler and then use that to -build the new compiler (sometimes you can get away without the full 2-stage -build, but for release artifacts you need the 2-stage build). +take a long time because one must first build the new compiler with an older +compiler and then use that to build the new compiler with itself (sometimes you +can get away without the full 2-stage build, but for release artifacts you need +the 2-stage build). Bootstrapping also has implications for when features are usable in the compiler itself. The build system uses the current beta compiler to build the From ae4e4729598dd235c2c71d5f101cdb5f6d4cf483 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:41:50 -0500 Subject: [PATCH 0938/1812] add intrinsics to glossary --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 11ddb494f..5dc8f3801 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -36,6 +36,7 @@ ICH
| Short for incremental compilation ha infcx
| The inference context (see `librustc_middle/infer`) inference variable
| When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. intern
| Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. +intrinsic
| Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html)) IR
| Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. IRLO
| `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). item
| A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. From 68a9c1f6059b5615dec4b423a63ebe4ef7c4e873 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 16:48:04 -0500 Subject: [PATCH 0939/1812] fix links --- src/overview.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/overview.md b/src/overview.md index 744ef3b1f..69e71723e 100644 --- a/src/overview.md +++ b/src/overview.md @@ -85,14 +85,14 @@ we'll talk about that later. [lex]: https://rustc-dev-guide.rust-lang.org/the-parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html [`librustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html -[parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parser/index.html +[parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html [type inference]: https://rustc-dev-guide.rust-lang.org/type-inference.html [mir]: https://rustc-dev-guide.rust-lang.org/mir/index.html [borrow checking]: https://rustc-dev-guide.rust-lang.org/borrow_check.html [mir-opt]: https://rustc-dev-guide.rust-lang.org/mir/optimizations.html [`simplify_try`]: https://github.com/rust-lang/rust/pull/66282 -[codegen]: https://rustc-dev-guide.rust-lang.org/codegen.html +[codegen]: https://rustc-dev-guide.rust-lang.org/backend/codegen.html ## How it does it @@ -252,7 +252,7 @@ cache is stored there too. In the code, there is usually a variable called the name `'tcx`, which means that something is tied to the lifetime of the `TyCtxt` (usually it is stored or interned there). -[`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html +[`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html ### `ty::Ty` @@ -264,7 +264,7 @@ on [`ty::Ty`][ty], but for now, we just want to mention that it exists and is th Oh, and also the `rustc::ty` module defines the `TyCtxt` struct we mentioned before. -[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html +[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html ### Parallelism @@ -360,8 +360,8 @@ bootstrapping compiler will support them. - These two functions can't be decoupled. - The Mid Level Intermediate Representation (MIR) - Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html) - - Definition: [`librustc/mir`](https://github.com/rust-lang/rust/tree/master/src/librustc/mir) - - Definition of source that manipulates the MIR: [`librustc_mir`](https://github.com/rust-lang/rust/tree/master/src/librustc_mir) + - Definition: [`librustc_middle/mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html) + - Definition of source that manipulates the MIR: [`librustc_mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html) - The Borrow Checker - Guide: [MIR Borrow Check](https://rustc-dev-guide.rust-lang.org/borrow_check.html) - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html) @@ -371,7 +371,7 @@ bootstrapping compiler will support them. - Definition: [`rustc_mir/transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html) - Main entry point: [`optimized_mir` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html) - Code Generation - - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/codegen.html) + - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/backend/codegen.html) - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** - Main entry point: [`rustc_codegen_ssa::base::codegen_crate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html) - This monomorphizes and produces LLVM IR for one codegen unit. It then starts a background thread to run LLVM, which must be joined later. From 4eadacdf2926d8e5094745135f846debeee551d0 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 00:27:39 -0400 Subject: [PATCH 0940/1812] [overview.md] add initial parser documentation --- src/overview.md | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/src/overview.md b/src/overview.md index 69e71723e..94ca51048 100644 --- a/src/overview.md +++ b/src/overview.md @@ -34,8 +34,33 @@ we'll talk about that later. [`librustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations and turn strings into interned symbols (_interning_ is discussed later). -- (**TODO**: chrissimpkins - Expand info on parser) We then [_parse_ the stream - of tokens][parser] to build an Abstract Syntax Tree (AST). +- The lexer has a small interface and doesn't depend directly on the + diagnostic infrastructure in `rustc`. Instead it provides diagnostics as plain + data which are emitted in `librustc_parse::lexer::mod` as real diagnostics. +- The lexer preseves full fidelity information for both IDEs and proc macros. +- The parser [translates the token stream from the lexer into an Abstract Syntax + Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax + analysis. The crate entry points for the parser are the `Parser.parse_crate_mod()` and + `Parser.parse_mod()` methods found in `librustc_parse::parser::item`. The external + module parsing entry point is `librustc_expand::module::parse_external_mod`. And + the macro parser entry point is `rustc_expand::mbe::macro_parser::parse_nt`. +- Parsing is performed with a set of `Parser` utility methods including `fn bump`, + `fn check`, `fn eat`, `fn expect`, `fn look_ahead`. +- Parsing is organized by the semantic construct that is being parsed. Separate + `parse_*` methods can be found in `librustc_parse` `parser` directory. File + naming follows the construct name. For example, the following files are found + in the parser: + - `expr.rs` + - `pat.rs` + - `ty.rs` + - `stmt.rs` +- This naming scheme is used across the parser, lowering, type checking, + HAIR lowering, & MIR building stages of the compile process and you will + find either a file or directory with the same name for most of these constructs + at each of these stages of compilation. +- For error handling, the parser uses the standard `DiagnosticBuilder` API, but we + try to recover, parsing a superset of Rust's grammar, while also emitting an error. +- The `rustc_ast::ast::{Crate, Mod, Expr, Pat, ...}` AST node returned from the parser. - macro expansion (**TODO** chrissimpkins) - ast validation (**TODO** chrissimpkins) - nameres (**TODO** chrissimpkins) From 5090bb8d0f07bff111bfa253feeff06e104d079b Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Tue, 7 Apr 2020 22:19:57 -0400 Subject: [PATCH 0941/1812] [overview.md] add lexer updates, parser updates includes feedback from matklad (lexer) and centril (parser) --- src/overview.md | 26 +++++++++++--------------- 1 file changed, 11 insertions(+), 15 deletions(-) diff --git a/src/overview.md b/src/overview.md index 94ca51048..3391952c7 100644 --- a/src/overview.md +++ b/src/overview.md @@ -28,8 +28,8 @@ we'll talk about that later. to the rest of the compilation process as a [`rustc_interface::Config`]. - The raw Rust source text is analyzed by a low-level lexer located in [`librustc_lexer`]. At this stage, the source text is turned into a stream of - atomic source code units known as _tokens_. The lexer supports the Unicode - character encoding. + atomic source code units known as _tokens_. The lexer supports the + Unicode character encoding. - The token stream passes through a higher-level lexer located in [`librustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations @@ -47,25 +47,21 @@ we'll talk about that later. - Parsing is performed with a set of `Parser` utility methods including `fn bump`, `fn check`, `fn eat`, `fn expect`, `fn look_ahead`. - Parsing is organized by the semantic construct that is being parsed. Separate - `parse_*` methods can be found in `librustc_parse` `parser` directory. File - naming follows the construct name. For example, the following files are found + `parse_*` methods can be found in `librustc_parse` `parser` directory. The source + file name follows the construct name. For example, the following files are found in the parser: - `expr.rs` - `pat.rs` - `ty.rs` - `stmt.rs` -- This naming scheme is used across the parser, lowering, type checking, - HAIR lowering, & MIR building stages of the compile process and you will - find either a file or directory with the same name for most of these constructs - at each of these stages of compilation. -- For error handling, the parser uses the standard `DiagnosticBuilder` API, but we +- This naming scheme is used across many compiler stages. You will find + either a file or directory with the same name across the parsing, lowering, + type checking, HAIR lowering, and MIR building sources. +- Macro expansion, AST validation, name resolution, and early linting takes place + during this stage of the compile process. +- The parser uses the standard `DiagnosticBuilder` API for error handling, but we try to recover, parsing a superset of Rust's grammar, while also emitting an error. -- The `rustc_ast::ast::{Crate, Mod, Expr, Pat, ...}` AST node returned from the parser. - - macro expansion (**TODO** chrissimpkins) - - ast validation (**TODO** chrissimpkins) - - nameres (**TODO** chrissimpkins) - - early linting (**TODO** chrissimpkins) - +- `rustc_ast::ast::{Crate, Mod, Expr, Pat, ...}` AST nodes are returned from the parser. - We then take the AST and [convert it to High-Level Intermediate Representation (HIR)][hir]. This is a compiler-friendly representation of the AST. This involves a lot of desugaring of things like loops and `async fn`. From a578fc11c55f62de7fc7e25601a0942c21807e90 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 14 Apr 2020 17:40:10 -0500 Subject: [PATCH 0942/1812] line length --- src/overview.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 3391952c7..bdebd86e4 100644 --- a/src/overview.md +++ b/src/overview.md @@ -395,5 +395,6 @@ bootstrapping compiler will support them. - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/backend/codegen.html) - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** - Main entry point: [`rustc_codegen_ssa::base::codegen_crate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html) - - This monomorphizes and produces LLVM IR for one codegen unit. It then starts a background thread to run LLVM, which must be joined later. + - This monomorphizes and produces LLVM IR for one codegen unit. It then + starts a background thread to run LLVM, which must be joined later. - Monomorphization happens lazily via [`FunctionCx::monomorphize`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#method.monomorphize) and [`rustc_codegen_ssa::base::codegen_instance `](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_instance.html) From 8046502e80ce8c54babb29bf00a3f86b5792bc3a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 17 Apr 2020 21:14:11 -0500 Subject: [PATCH 0943/1812] Remove various todos With some items added to https://github.com/rust-lang/rustc-dev-guide/issues/674 Co-Authored-By: Chris Simpkins --- src/overview.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/src/overview.md b/src/overview.md index bdebd86e4..abe35188f 100644 --- a/src/overview.md +++ b/src/overview.md @@ -15,7 +15,6 @@ So first, let's look at what the compiler does to your code. For now, we will avoid mentioning how the compiler implements these steps except as needed; we'll talk about that later. -**TODO: Would be great to have a diagram of this once we nail down the details...** - The compile process begins when a user writes a Rust source program in text and invokes the `rustc` compiler on it. The work that the compiler needs to @@ -74,10 +73,9 @@ we'll talk about that later. HAIR is used for pattern and exhaustiveness checking. It is also more convenient to convert into MIR than HIR is. - The MIR is used for [borrow checking]. -- **TODO: const eval fits in somewhere here I think** - We (want to) do [many optimizations on the MIR][mir-opt] because it is still generic and that improves the code we generate later, improving compilation - speed too. (**TODO: size optimizations too?**) + speed too. - MIR is a higher level (and generic) representation, so it is easier to do some optimizations at MIR level than at LLVM-IR level. For example LLVM doesn't seem to be able to optimize the pattern the [`simplify_try`] mir @@ -96,9 +94,8 @@ we'll talk about that later. - The LLVM IR is passed to LLVM, which does a lot more optimizations on it. It then emits machine code. It is basically assembly code with additional low-level types and annotations added. (e.g. an ELF object or wasm). - **TODO: reference for this section?** - The different libraries/binaries are linked together to produce the final - binary. **TODO: reference for this section?** + binary. [`librustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html [`librustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html @@ -138,13 +135,13 @@ satisfy/optimize for. For example, point. - Compiler compilation speed: how long does it take to compile the compiler? This impacts contributors and compiler maintenance. -- Compiler implementation complexity: building a compiler is one of the hardest +- Implementation complexity: building a compiler is one of the hardest things a person/group can do, and Rust is not a very simple language, so how do we make the compiler's code base manageable? - Compiler correctness: the binaries produced by the compiler should do what the input programs says they do, and should continue to do so despite the tremendous amount of change constantly going on. -- Compiler integration: a number of other tools need to use the compiler in +- Integration: a number of other tools need to use the compiler in various ways (e.g. cargo, clippy, miri, RLS) that must be supported. - Compiler stability: the compiler should not crash or fail ungracefully on the stable channel. @@ -283,7 +280,7 @@ program) is [`rustc::ty::Ty`][ty]. This is so important that we have a whole cha on [`ty::Ty`][ty], but for now, we just want to mention that it exists and is the way `rustc` represents types! -Oh, and also the `rustc::ty` module defines the `TyCtxt` struct we mentioned before. +Also note that the `rustc::ty` module defines the `TyCtxt` struct we mentioned before. [ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html @@ -332,7 +329,6 @@ bootstrapping compiler will support them. # Unresolved Questions -**TODO: find answers to these** - Does LLVM ever do optimizations in debug builds? - How do I explore phases of the compile process in my own sources (lexer, From 96e912e6a61e1bdb65a245b1f386c28c91fe08ee Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 17 Apr 2020 21:19:25 -0500 Subject: [PATCH 0944/1812] add link to intrinsic --- src/overview.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/overview.md b/src/overview.md index abe35188f..e08f012f3 100644 --- a/src/overview.md +++ b/src/overview.md @@ -323,9 +323,11 @@ Bootstrapping also has implications for when features are usable in the compiler itself. The build system uses the current beta compiler to build the stage-1 bootstrapping compiler. This means that the compiler source code can't use some features until they reach beta (because otherwise the beta compiler -doesn't support them). On the other hand, for compiler intrinsics and internal -features, we may be able to use them immediately because the stage-1 -bootstrapping compiler will support them. +doesn't support them). On the other hand, for [compiler intrinsics][intrinsics] +and internal features, we may be able to use them immediately because the +stage-1 bootstrapping compiler will support them. + +[intrinsics]: ./appendix/glossary.md#intrinsic # Unresolved Questions From e927db936f5c87ccd87e8a89add57bd2a26f703f Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 18 Apr 2020 11:54:09 +0900 Subject: [PATCH 0945/1812] Apply suggestions from code review Co-Authored-By: Chris Simpkins --- src/overview.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/overview.md b/src/overview.md index e08f012f3..f2b360013 100644 --- a/src/overview.md +++ b/src/overview.md @@ -36,7 +36,7 @@ we'll talk about that later. - The lexer has a small interface and doesn't depend directly on the diagnostic infrastructure in `rustc`. Instead it provides diagnostics as plain data which are emitted in `librustc_parse::lexer::mod` as real diagnostics. -- The lexer preseves full fidelity information for both IDEs and proc macros. +- The lexer preserves full fidelity information for both IDEs and proc macros. - The parser [translates the token stream from the lexer into an Abstract Syntax Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax analysis. The crate entry points for the parser are the `Parser.parse_crate_mod()` and @@ -145,7 +145,7 @@ satisfy/optimize for. For example, various ways (e.g. cargo, clippy, miri, RLS) that must be supported. - Compiler stability: the compiler should not crash or fail ungracefully on the stable channel. -- Rust stability: the compiler must respect rust's stability guarantees by not +- Rust stability: the compiler must respect Rust's stability guarantees by not breaking programs that previously compiled despite the many changes that are always going on to its implementation. - Limitations of other tools: rustc uses LLVM in its backend, and LLVM has some @@ -299,7 +299,7 @@ together into one binary. However, the rest of the compiler is still not yet parallel. There have been lots of efforts spent on this, but it is generally a hard problem. The current -approach is (**TODO: verify**) to turn `RefCell`s into `Mutex`s -- that is, we +approach is to turn `RefCell`s into `Mutex`s -- that is, we switch to thread-safe internal mutability. However, there are ongoing challenges with lock contention, maintaining query-system invariants under concurrency, and the complexity of the code base. One can try out the current From bc5445760e1e9b7a71b2831ae660cce1ef3138dd Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 18 Apr 2020 11:40:16 -0500 Subject: [PATCH 0946/1812] Fix some whitespace (#677) --- src/overview.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/overview.md b/src/overview.md index f2b360013..37e82822d 100644 --- a/src/overview.md +++ b/src/overview.md @@ -331,13 +331,12 @@ stage-1 bootstrapping compiler will support them. # Unresolved Questions - - Does LLVM ever do optimizations in debug builds? - How do I explore phases of the compile process in my own sources (lexer, parser, HIR, etc)? - e.g., `cargo rustc -- -Zunpretty=hir-tree` allows you to view HIR representation - What is the main source entry point for `X`? -- Where do phases diverge for cross-compilation to machine code across +- Where do phases diverge for cross-compilation to machine code across different platforms? # References From 4840ad250be694070774cbc679b18c4d17e03df8 Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Fri, 27 Mar 2020 16:29:11 +0100 Subject: [PATCH 0947/1812] Add documentation about incr. comp. query attributes and the projection query pattern. --- .../incremental-compilation-in-detail.md | 89 +++++++++++++++++++ 1 file changed, 89 insertions(+) diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index a41becfd0..e545931cb 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -401,6 +401,95 @@ deal with all of the above but so far that seemed like more trouble than it would save. + +## Query Attributes + +The query system allows for applying attributes to queries. These attributes +affect certain aspects of how the system treats the query with respect to +incremental compilation: + + - `eval_always` - A query with the `eval_always` attribute is re-executed + unconditionally during incremental compilation. I.e. the system will not + even try to mark the query's dep-node as green. This attribute has two use + cases: + + - Queries that are **inputs** to the system must be marked as `eval_always` + since we have no other way of checking whether their value has changed. + + - Some queries are very likely to be re-evaluated because their result + depends on the entire source code. In this case `eval_always` can be used + as an optimization because the system can skip recording dependencies in + the first place. + + - `no_hash` - Applying `no_hash` to a query tells the system to not compute + the fingerprint of the query's result. This has two consequences: + + - Not computing the fingerprint can save quite a bit of time because + fingerprinting is expensive, especially for large, complex values. + + - Without the fingerprint, the system has to unconditionally assume that + the result of the query has changed. As a consequence anything depending + on a `no_hash` query will always be re-executed. + + - `cache_on_disk_if` - This attribute is what determines which query results + are persisted in the incremental compilation query result cache. The + attribute takes an expression that allows to make per query invocation + decisions. For example, it makes no sense to store values from upstream + crates in the cache because they are already available in the upstream + crate's metadata. + + - `anon` - This attribute makes the system use "anonymous" dep-nodes for the + given query. An anonymous dep-node is not identified by the corresponding + query key, instead its ID is computed from the IDs of its dependencies. This + allows the red-green system to do its change detection even if there is no + query key available for a given dep-node -- something which is needed for + handling trait selection because it is not based on queries. + + +## The Projection Query Pattern + +It's interesting to note that `eval_always` and `no_hash` can be used together +in the so-called "projection query" pattern. It is often the case that there is +one query that depends on the entirety of the compiler's input (e.g. the indexed HIR) +and another query that projects individual values out of this monolithic value +(e.g. a HIR item with a certain `DefId`). These projection queries allow for +building change propagation "firewalls" because even if the result of the +monolithic query changes (which it is very likely to do) the small projections +can still mostly be marked as green. + + +```ignore + +------------+ + | | +---------------+ +--------+ + | | <---------| projection(x) | <---------| foo(a) | + | | +---------------+ +--------+ + | | + | monolithic | +---------------+ +--------+ + | query | <---------| projection(y) | <---------| bar(b) | + | | +---------------+ +--------+ + | | + | | +---------------+ +--------+ + | | <---------| projection(z) | <---------| baz(c) | + | | +---------------+ +--------+ + +------------+ +``` + +Let's assume that the result `monolithic_query` changes so that also the result +of `projection(x)` has changed, i.e. both their dep-nodes are being marked as +red. As a consequence `foo(a)` needs to be re-executed; but `bar(b)` and +`baz(c)` can be marked as green. However, if `foo`, `bar`, and `baz` would have +directly depended on `monolithic_query` then all of them would have had to be +re-evaluated. + +This pattern works even without `eval_always` and `no_hash` but the two +attributes can be used to avoid unnecessary overhead. If the monolithic query +is likely to change at any minor modification of the compiler's input it makes +sense to mark it as `eval_always`, thus getting rid of its dependency tracking +cost. And it always makes sense to mark the monolithic query as `no_hash` +because we have the projections to take care of keeping things green as much +as possible. + + # Shortcomings of the Current System There are many things that still can be improved. From 2154b85ca4cf556c245f1f3df6a8d27acbf60a0e Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Mon, 30 Mar 2020 17:03:24 +0200 Subject: [PATCH 0948/1812] Apply feedback. --- src/queries/incremental-compilation-in-detail.md | 14 ++++++++------ src/query.md | 3 ++- 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index e545931cb..25db154fb 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -402,11 +402,11 @@ would save. -## Query Attributes +## Query Modifiers -The query system allows for applying attributes to queries. These attributes -affect certain aspects of how the system treats the query with respect to -incremental compilation: +The query system allows for applying [modifiers][mod] to queries. These +modifiers affect certain aspects of how the system treats the query with +respect to incremental compilation: - `eval_always` - A query with the `eval_always` attribute is re-executed unconditionally during incremental compilation. I.e. the system will not @@ -433,7 +433,7 @@ incremental compilation: - `cache_on_disk_if` - This attribute is what determines which query results are persisted in the incremental compilation query result cache. The - attribute takes an expression that allows to make per query invocation + attribute takes an expression that allows per query invocation decisions. For example, it makes no sense to store values from upstream crates in the cache because they are already available in the upstream crate's metadata. @@ -445,6 +445,8 @@ incremental compilation: query key available for a given dep-node -- something which is needed for handling trait selection because it is not based on queries. +[mod]: ../query.html#adding-a-new-kind-of-query + ## The Projection Query Pattern @@ -482,7 +484,7 @@ directly depended on `monolithic_query` then all of them would have had to be re-evaluated. This pattern works even without `eval_always` and `no_hash` but the two -attributes can be used to avoid unnecessary overhead. If the monolithic query +modifiers can be used to avoid unnecessary overhead. If the monolithic query is likely to change at any minor modification of the compiler's input it makes sense to mark it as `eval_always`, thus getting rid of its dependency tracking cost. And it always makes sense to mark the monolithic query as `no_hash` diff --git a/src/query.md b/src/query.md index 6e2193bd3..4e795c6a2 100644 --- a/src/query.md +++ b/src/query.md @@ -224,9 +224,10 @@ Let's go over them one by one: of `Steal` for more details. New uses of `Steal` should **not** be added without alerting `@rust-lang/compiler`. - **Query modifiers:** various flags and options that customize how the - query is processed. + query is processed (mostly with respect to [incremental compilation][incrcomp]). [Key]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/keys/trait.Key.html +[incrcomp]: queries/incremental-compilation-in-detail.html#query-modifiers So, to add a query: From 695e58d5ec57b20c929dcd5a873c6892d7dfcd14 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 18 Apr 2020 14:23:18 +0900 Subject: [PATCH 0949/1812] Apply suggestions from Zoxc --- src/queries/incremental-compilation-in-detail.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index 25db154fb..d8716acdf 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -413,8 +413,8 @@ respect to incremental compilation: even try to mark the query's dep-node as green. This attribute has two use cases: - - Queries that are **inputs** to the system must be marked as `eval_always` - since we have no other way of checking whether their value has changed. + - `eval_always` queries can read inputs (from files, global state, etc). + They can also produce side effects like writing to files and changing global state. - Some queries are very likely to be re-evaluated because their result depends on the entire source code. In this case `eval_always` can be used From 0daa3f70538c6edcc0098fb6acbba4a4fd8b5034 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Sun, 19 Apr 2020 12:54:45 -0300 Subject: [PATCH 0950/1812] Fix typo (#678) --- src/profiling/with_perf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 7a4c972f2..5945f0b02 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -241,7 +241,7 @@ Percentage : 0% Here we used the `..` operator to ask "how often do we have `do_mir_borrowck` on the stack and then, later, some function whose -name begins with `rusc::traits`?" (basically, code in that module). It +name begins with `rustc::traits`?" (basically, code in that module). It turns out the answer is "almost never" — only 12 samples fit that description (if you ever see *no* samples, that often indicates your query is messed up). From 5d0f59959bb91fba7fb13243f7da68dc5d8f1310 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Esteban=20K=C3=BCber?= Date: Mon, 25 Nov 2019 16:10:24 -0800 Subject: [PATCH 0951/1812] Add diagnostics ICE-breakers page --- src/ice-breaker/diagnostics.md | 148 +++++++++++++++++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 src/ice-breaker/diagnostics.md diff --git a/src/ice-breaker/diagnostics.md b/src/ice-breaker/diagnostics.md new file mode 100644 index 000000000..3b5f353bc --- /dev/null +++ b/src/ice-breaker/diagnostics.md @@ -0,0 +1,148 @@ +# Diagnostics ICE-breakers + +**Github Label:** [A-diagnostics] + +[A-Diagnostics]: https://github.com/rust-lang/rust/labels/A-diagnostics + +The "Diagnostics ICE-breakers" are focused on bugs that center around the +user visible compiler output. These bugs can fall under one of multiple topics: + +- [D-papercut]: Errors that needs small tweaks to archieve a good output. +- [D-newcomer-roadblock]: Errors that are hard to understand for new users. +- [D-confusing]: Errors that are hard to understand, regardless of experience +level. +- [D-invalid-suggestion]: Structured suggestions use heuristics to suggest +valid code that captures the user's intent, but these heuristics can be wrong. +This label aggregates cases where the heuristics don't account for some case. +- [D-verbose]: Sometimes errors lean towards verbosity to try and increase +understandability, but in practice the "wall of text" effect can be counter +productive. Tickets labeled this way are about _removing_ output from existing +errors. +- [D-incorrect]: A diagnostic that is giving misleading or incorrect +information. This might require creating a new, more targetted, error. +- [D-inconsistent]: Inconsistency in formatting, grammar or style between +diagnostic messages. This is usually related to capitalization or sentence +tense. +- [D-edition]: error that should account for edition differences, but doesn't. +- [A-diagnostic-suggestions]: error that should have a structured suggestion, +but don't. + + +[D-papercut]: https://github.com/rust-lang/rust/labels/D-papercut +[D-newcomer-roadblock]: https://github.com/rust-lang/rust/labels/D-newcomer-roadblock +[D-confusing]: https://github.com/rust-lang/rust/labels/D-confusing +[D-invalid-suggestion]: https://github.com/rust-lang/rust/labels/D-invalid-suggestion +[D-verbose]: https://github.com/rust-lang/rust/labels/D-verbose +[D-incorrect]: https://github.com/rust-lang/rust/labels/D-incorrect +[D-inconsistent]: https://github.com/rust-lang/rust/labels/D-inconsistent +[D-edition]: https://github.com/rust-lang/rust/labels/D-edition +[A-diagnostic-suggestions]: https://github.com/rust-lang/rust/labels/A-diagnostic-suggestions + +## Diagnostic output style guide + +The main parts of a diagnostic error are the following: + +``` +error[E0000]: main error message + --> file.rs:LL:CC + | +LL | + | -^^^^- secondary label + | | + | primary label + | + = note: note without a `Span`, created with `.note` +note: sub-diagnostic message for `.span_note` + --> file.rs:LL:CC + | +LL | more code + | ^^^^ +``` + +- Description (`error`, `warning`, etc.). +- Code (for example, for "mismatched types", it is `E0308`). It helps + users get more information about the current error through an extended + description of the problem in the error code index. +- Message. It is the main description of the problem. It should be general and + able to stand on its own, so that it can make sense even in isolation. +- Diagnostic window. This contains several things: + - The path, line number and column of the beginning of the primary span. + - The users' affected code and its surroundings. + - Primary and secondary spans underlying the users' code. These spans can + optionally contain one or more labels. + - Primary spans should have enough text to descrive the problem in such a + way that if it where the only thing being displayed (for example, in an + IDE) it would still make sense. Because it is "spatially aware" (it + points at the code), it can generally be more succinct than the error + message. + - If cluttered output can be foreseen in cases when multiple span labels + overlap, it is a good idea to tweak the output appropriately. For + example, the `if/else arms have incompatible types` error uses different + spans depending on whether the arms are all in the same line, if one of + the arms is empty and if none of those cases applies. +- Sub-diagnostics. Any error can have multiple sub-diagnostics that look + similar to the main part of the error. These are used for cases where the + order of the explanation might not correspond with the order of the code. If + the order of the explanation can be "order free", leveraging secondary labels + in the main diagnostic is preferred, as it is typically less verbose. + +The text should be matter of fact and avoid capitalization and periods, unless +multiple sentences are _needed_: + +``` +error: the fobrulator needs to be krontrificated +``` + +When code or an identifier must appear in an message or label, it should be +surrounded with single acute accents \`. + +### Structured suggestions + +Structured suggestions are a special kind of annotation in a diagnostic that +let third party tools (like `rustfix` and `rust-analyzer`) apply these changes +with no or minimal user interaction. These suggestions have a degree of +confidence in the suggested code, from high +(`Applicability::MachineApplicable`) to low (`Applicability::MaybeIncorrect`). +Be conservative when choosing the level. + +They point to one or more spans with corresponding code that will replace their +current content. + +The message that accompanies them should be understandable in the following +contexts: + +- shown as an independent sug-diagnostic (this is the default output) +- shown as a label pointing at the affected span (this is done automatically if +the some heuristics for verbosity are met) +- shown as a `help` sub-diagnostic with no content (used for cases where the +suggestion is obvious from the text, but we still want to let tools to apply +them)) +- not shown (used for _very_ obvious cases, but we still want to allow tools to +apply them) + + +## Helpful tips and options + +### Finding the source of errors + +There are two main ways to find where a given error is emitted: + +- `grep` for either a sub-part of the error message/label or error code. This + usually works well and is straightforward, but there are some cases where + the error emitting code is removed from the code where the error is + constructed behind a relatively deep call-stack. Even then, it is a good way + to get your bearings. +- Invoking `rustc` with the nightly-only flag `-Ztreat-err-as-bug=1`, which + will treat the first error being emitted as an Internal Compiler Error, which + allows you to use the environment variable `RUST_BACKTRACE=full` to get a + stack trace at the point the error has been emitted. Change the `1` to + something else if you whish to trigger on a later error. Some limitations + with this approach is that some calls get elided from the stack trace because + they get inlined in the compiled `rustc`, and the same problem we faced with + the prior approach, where the _construction_ of the error is far away from + where it is _emitted_. In some cases we buffer multiple errors in order to + emit them in order. + +The regular development practices apply: judicious use of `debug!()` statements +and use of a debugger to trigger break points in order to figure out in what +order things are happening. From 0ecf993367dcd12e33a0dfd2e5f8714cab5fe350 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Esteban=20K=C3=BCber?= Date: Mon, 25 Nov 2019 18:41:50 -0800 Subject: [PATCH 0952/1812] review comments: move text to more relevant section --- src/diagnostics.md | 104 ++++++++++++++++++++++++++++++- src/ice-breaker/diagnostics.md | 109 +-------------------------------- 2 files changed, 105 insertions(+), 108 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 50da15c22..51d6c27ae 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -3,6 +3,90 @@ A lot of effort has been put into making `rustc` have great error messages. This chapter is about how to emit compile errors and lints from the compiler. +## Diagnostic output style guide + +The main parts of a diagnostic error are the following: + +``` +error[E0000]: main error message + --> file.rs:LL:CC + | +LL | + | -^^^^- secondary label + | | + | primary label + | + = note: note without a `Span`, created with `.note` +note: sub-diagnostic message for `.span_note` + --> file.rs:LL:CC + | +LL | more code + | ^^^^ +``` + +- Description (`error`, `warning`, etc.). +- Code (for example, for "mismatched types", it is `E0308`). It helps + users get more information about the current error through an extended + description of the problem in the error code index. +- Message. It is the main description of the problem. It should be general and + able to stand on its own, so that it can make sense even in isolation. +- Diagnostic window. This contains several things: + - The path, line number and column of the beginning of the primary span. + - The users' affected code and its surroundings. + - Primary and secondary spans underlying the users' code. These spans can + optionally contain one or more labels. + - Primary spans should have enough text to descrive the problem in such a + way that if it where the only thing being displayed (for example, in an + IDE) it would still make sense. Because it is "spatially aware" (it + points at the code), it can generally be more succinct than the error + message. + - If cluttered output can be foreseen in cases when multiple span labels + overlap, it is a good idea to tweak the output appropriately. For + example, the `if/else arms have incompatible types` error uses different + spans depending on whether the arms are all in the same line, if one of + the arms is empty and if none of those cases applies. +- Sub-diagnostics. Any error can have multiple sub-diagnostics that look + similar to the main part of the error. These are used for cases where the + order of the explanation might not correspond with the order of the code. If + the order of the explanation can be "order free", leveraging secondary labels + in the main diagnostic is preferred, as it is typically less verbose. + +The text should be matter of fact and avoid capitalization and periods, unless +multiple sentences are _needed_: + +``` +error: the fobrulator needs to be krontrificated +``` + +When code or an identifier must appear in an message or label, it should be +surrounded with single acute accents \`. + +## Helpful tips and options + +### Finding the source of errors + +There are two main ways to find where a given error is emitted: + +- `grep` for either a sub-part of the error message/label or error code. This + usually works well and is straightforward, but there are some cases where + the error emitting code is removed from the code where the error is + constructed behind a relatively deep call-stack. Even then, it is a good way + to get your bearings. +- Invoking `rustc` with the nightly-only flag `-Ztreat-err-as-bug=1`, which + will treat the first error being emitted as an Internal Compiler Error, which + allows you to use the environment variable `RUST_BACKTRACE=full` to get a + stack trace at the point the error has been emitted. Change the `1` to + something else if you whish to trigger on a later error. Some limitations + with this approach is that some calls get elided from the stack trace because + they get inlined in the compiled `rustc`, and the same problem we faced with + the prior approach, where the _construction_ of the error is far away from + where it is _emitted_. In some cases we buffer multiple errors in order to + emit them in order. + +The regular development practices apply: judicious use of `debug!()` statements +and use of a debugger to trigger break points in order to figure out in what +order things are happening. + ## `Span` [`Span`][span] is the primary data structure in `rustc` used to represent a @@ -84,11 +168,29 @@ Server][rls] and [`rustfix`][rustfix]. [rls]: https://github.com/rust-lang/rls [rustfix]: https://github.com/rust-lang/rustfix -Not all suggestions should be applied mechanically. Use the +Not all suggestions should be applied mechanically, they have a degree of +confidence in the suggested code, from high +(`Applicability::MachineApplicable`) to low (`Applicability::MaybeIncorrect`). +Be conservative when choosing the level. Use the [`span_suggestion`][span_suggestion] method of `DiagnosticBuilder` to make a suggestion. The last argument provides a hint to tools whether the suggestion is mechanically applicable or not. +Suggestions point to one or more spans with corresponding code that will +replace their current content. + +The message that accompanies them should be understandable in the following +contexts: + +- shown as an independent sug-diagnostic (this is the default output) +- shown as a label pointing at the affected span (this is done automatically if +the some heuristics for verbosity are met) +- shown as a `help` sub-diagnostic with no content (used for cases where the +suggestion is obvious from the text, but we still want to let tools to apply +them)) +- not shown (used for _very_ obvious cases, but we still want to allow tools to +apply them) + [span_suggestion]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html#method.span_suggestion For example, to make our `qux` suggestion machine-applicable, we would do: diff --git a/src/ice-breaker/diagnostics.md b/src/ice-breaker/diagnostics.md index 3b5f353bc..96450d888 100644 --- a/src/ice-breaker/diagnostics.md +++ b/src/ice-breaker/diagnostics.md @@ -38,111 +38,6 @@ but don't. [D-edition]: https://github.com/rust-lang/rust/labels/D-edition [A-diagnostic-suggestions]: https://github.com/rust-lang/rust/labels/A-diagnostic-suggestions -## Diagnostic output style guide +For more information, visit the [diagnostics page]. -The main parts of a diagnostic error are the following: - -``` -error[E0000]: main error message - --> file.rs:LL:CC - | -LL | - | -^^^^- secondary label - | | - | primary label - | - = note: note without a `Span`, created with `.note` -note: sub-diagnostic message for `.span_note` - --> file.rs:LL:CC - | -LL | more code - | ^^^^ -``` - -- Description (`error`, `warning`, etc.). -- Code (for example, for "mismatched types", it is `E0308`). It helps - users get more information about the current error through an extended - description of the problem in the error code index. -- Message. It is the main description of the problem. It should be general and - able to stand on its own, so that it can make sense even in isolation. -- Diagnostic window. This contains several things: - - The path, line number and column of the beginning of the primary span. - - The users' affected code and its surroundings. - - Primary and secondary spans underlying the users' code. These spans can - optionally contain one or more labels. - - Primary spans should have enough text to descrive the problem in such a - way that if it where the only thing being displayed (for example, in an - IDE) it would still make sense. Because it is "spatially aware" (it - points at the code), it can generally be more succinct than the error - message. - - If cluttered output can be foreseen in cases when multiple span labels - overlap, it is a good idea to tweak the output appropriately. For - example, the `if/else arms have incompatible types` error uses different - spans depending on whether the arms are all in the same line, if one of - the arms is empty and if none of those cases applies. -- Sub-diagnostics. Any error can have multiple sub-diagnostics that look - similar to the main part of the error. These are used for cases where the - order of the explanation might not correspond with the order of the code. If - the order of the explanation can be "order free", leveraging secondary labels - in the main diagnostic is preferred, as it is typically less verbose. - -The text should be matter of fact and avoid capitalization and periods, unless -multiple sentences are _needed_: - -``` -error: the fobrulator needs to be krontrificated -``` - -When code or an identifier must appear in an message or label, it should be -surrounded with single acute accents \`. - -### Structured suggestions - -Structured suggestions are a special kind of annotation in a diagnostic that -let third party tools (like `rustfix` and `rust-analyzer`) apply these changes -with no or minimal user interaction. These suggestions have a degree of -confidence in the suggested code, from high -(`Applicability::MachineApplicable`) to low (`Applicability::MaybeIncorrect`). -Be conservative when choosing the level. - -They point to one or more spans with corresponding code that will replace their -current content. - -The message that accompanies them should be understandable in the following -contexts: - -- shown as an independent sug-diagnostic (this is the default output) -- shown as a label pointing at the affected span (this is done automatically if -the some heuristics for verbosity are met) -- shown as a `help` sub-diagnostic with no content (used for cases where the -suggestion is obvious from the text, but we still want to let tools to apply -them)) -- not shown (used for _very_ obvious cases, but we still want to allow tools to -apply them) - - -## Helpful tips and options - -### Finding the source of errors - -There are two main ways to find where a given error is emitted: - -- `grep` for either a sub-part of the error message/label or error code. This - usually works well and is straightforward, but there are some cases where - the error emitting code is removed from the code where the error is - constructed behind a relatively deep call-stack. Even then, it is a good way - to get your bearings. -- Invoking `rustc` with the nightly-only flag `-Ztreat-err-as-bug=1`, which - will treat the first error being emitted as an Internal Compiler Error, which - allows you to use the environment variable `RUST_BACKTRACE=full` to get a - stack trace at the point the error has been emitted. Change the `1` to - something else if you whish to trigger on a later error. Some limitations - with this approach is that some calls get elided from the stack trace because - they get inlined in the compiled `rustc`, and the same problem we faced with - the prior approach, where the _construction_ of the error is far away from - where it is _emitted_. In some cases we buffer multiple errors in order to - emit them in order. - -The regular development practices apply: judicious use of `debug!()` statements -and use of a debugger to trigger break points in order to figure out in what -order things are happening. +[diagnostics page]: ../diagnostics.md From a450260a5f09d6c023ab57f58945ac7b447f172d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 19 Apr 2020 13:07:05 -0500 Subject: [PATCH 0953/1812] Typo --- src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 51d6c27ae..2212fc790 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -54,7 +54,7 @@ LL | more code The text should be matter of fact and avoid capitalization and periods, unless multiple sentences are _needed_: -``` +```txt error: the fobrulator needs to be krontrificated ``` From cbd8d437daf3db7c7405bc3b8a4a441942f01cf5 Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Mon, 20 Apr 2020 15:16:27 +0200 Subject: [PATCH 0954/1812] Replace `rustc` with `rustc_middle` (#680) --- src/compiler-src.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index 472d1ea03..25b3baa3e 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -30,7 +30,7 @@ rustc_codegen rustc_borrowck ... rustc_metadata \ | / \ | / \ v / - rustc + rustc_middle | v rustc_ast @@ -46,20 +46,20 @@ crates and defines the overall flow of execution. (As we transition more and more to the [query model], however, the "flow" of compilation is becoming less centrally defined.) -At the other extreme, the `rustc` crate defines the common and +At the other extreme, the `rustc_middle` crate defines the common and pervasive data structures that all the rest of the compiler uses (e.g. how to represent types, traits, and the program itself). It also contains some amount of the compiler itself, although that is relatively limited. Finally, all the crates in the bulge in the middle define the bulk of -the compiler – they all depend on `rustc`, so that they can make use +the compiler – they all depend on `rustc_middle`, so that they can make use of the various types defined there, and they export public routines that `rustc_driver` will invoke as needed (more and more, what these crates export are "query definitions", but those are covered later on). -Below `rustc` lie various crates that make up the parser and error +Below `rustc_middle` lie various crates that make up the parser and error reporting mechanism. They are also an internal part of the compiler and not intended to be stable (though they do wind up getting used by some crates in the wild; a practice we hope to From 1398a6fe9da0f5353d4159da79c70ff1b99aaedf Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 24 Apr 2020 01:08:58 -0300 Subject: [PATCH 0955/1812] treat-err-as-bug=n means panic on nth error --- src/compiler-debugging.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 89a763c41..d6d03ab1e 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -69,11 +69,11 @@ stack backtrace: ## Getting a backtrace for errors [getting-a-backtrace-for-errors]: #getting-a-backtrace-for-errors -If you want to get a backtrace to the point where the compiler emits -an error message, you can pass the `-Z treat-err-as-bug=n`, which -will make the compiler skip `n` errors or `delay_span_bug` calls and then -panic on the next one. If you leave off `=n`, the compiler will assume `0` for -`n` and thus panic on the first error it encounters. +If you want to get a backtrace to the point where the compiler emits an +error message, you can pass the `-Z treat-err-as-bug=n`, which will make +the compiler panic on the `nth` error on `delay_span_bug.` If you leave +off `=n`, the compiler will assume `1` for `n` and thus panic on the +first error it encounters. This can also help when debugging `delay_span_bug` calls - it will make the first `delay_span_bug` call panic, which will give you a useful backtrace. From d596ab2bee4fcbc46cb54d2c8129723e941d444a Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Sun, 19 Apr 2020 22:48:45 +0800 Subject: [PATCH 0956/1812] Remove details about chalk and point to Chalk Book instead. --- src/SUMMARY.md | 19 +- src/traits/associated-types.md | 168 ----------- src/traits/bibliography.md | 27 -- src/traits/canonical-queries.md | 252 ---------------- src/traits/canonicalization.md | 256 ---------------- src/traits/chalk-overview.md | 256 ---------------- src/traits/chalk.md | 43 +++ src/traits/goals-and-clauses.md | 270 ----------------- src/traits/implied-bounds.md | 502 -------------------------------- src/traits/index.md | 64 ---- src/traits/lowering-rules.md | 416 -------------------------- src/traits/lowering-to-logic.md | 185 ------------ src/traits/resolution.md | 2 +- src/traits/slg.md | 302 ------------------- src/traits/wf.md | 469 ----------------------------- 15 files changed, 48 insertions(+), 3183 deletions(-) delete mode 100644 src/traits/associated-types.md delete mode 100644 src/traits/bibliography.md delete mode 100644 src/traits/canonical-queries.md delete mode 100644 src/traits/canonicalization.md delete mode 100644 src/traits/chalk-overview.md create mode 100644 src/traits/chalk.md delete mode 100644 src/traits/goals-and-clauses.md delete mode 100644 src/traits/implied-bounds.md delete mode 100644 src/traits/index.md delete mode 100644 src/traits/lowering-rules.md delete mode 100644 src/traits/lowering-to-logic.md delete mode 100644 src/traits/slg.md delete mode 100644 src/traits/wf.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 28abd8d65..38634e26a 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -72,24 +72,13 @@ - [`TypeFolder` and `TypeFoldable`](./ty-fold.md) - [Generic arguments](./generic_arguments.md) - [Type inference](./type-inference.md) - - [Trait solving (old-style)](./traits/resolution.md) + - [Trait solving](./traits/resolution.md) - [Higher-ranked trait bounds](./traits/hrtb.md) - [Caching subtleties](./traits/caching.md) - [Specialization](./traits/specialization.md) - - [Trait solving (new-style)](./traits/index.md) - - [Lowering to logic](./traits/lowering-to-logic.md) - - [Goals and clauses](./traits/goals-and-clauses.md) - - [Equality and associated types](./traits/associated-types.md) - - [Implied bounds](./traits/implied-bounds.md) - - [Region constraints](./traits/regions.md) - - [The lowering module in rustc](./traits/lowering-module.md) - - [Lowering rules](./traits/lowering-rules.md) - - [Well-formedness checking](./traits/wf.md) - - [Canonical queries](./traits/canonical-queries.md) - - [Canonicalization](./traits/canonicalization.md) - - [The SLG solver](./traits/slg.md) - - [An Overview of Chalk](./traits/chalk-overview.md) - - [Bibliography](./traits/bibliography.md) + - [Chalk-based trait solving](./traits/chalk.md) + - [Region constraints](./traits/regions.md) + - [Chalk-oriented lowering module in rustc](./traits/lowering-module.md) - [Type checking](./type-checking.md) - [Method Lookup](./method-lookup.md) - [Variance](./variance.md) diff --git a/src/traits/associated-types.md b/src/traits/associated-types.md deleted file mode 100644 index 41ce5ac9e..000000000 --- a/src/traits/associated-types.md +++ /dev/null @@ -1,168 +0,0 @@ -# Equality and associated types - -This section covers how the trait system handles equality between -associated types. The full system consists of several moving parts, -which we will introduce one by one: - -- Projection and the `Normalize` predicate -- Placeholder associated type projections -- The `ProjectionEq` predicate -- Integration with unification - -## Associated type projection and normalization - -When a trait defines an associated type (e.g., -[the `Item` type in the `IntoIterator` trait][intoiter-item]), that -type can be referenced by the user using an **associated type -projection** like ` as IntoIterator>::Item`. - -> Often, people will use the shorthand syntax `T::Item`. Presently, that -> syntax is expanded during ["type collection"](../type-checking.html) into the -> explicit form, though that is something we may want to change in the future. - -[intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item - - - -In some cases, associated type projections can be **normalized** – -that is, simplified – based on the types given in an impl. So, to -continue with our example, the impl of `IntoIterator` for `Option` -declares (among other things) that `Item = T`: - -```rust,ignore -impl IntoIterator for Option { - type Item = T; - ... -} -``` - -This means we can normalize the projection ` as -IntoIterator>::Item` to just `u32`. - -In this case, the projection was a "monomorphic" one – that is, it -did not have any type parameters. Monomorphic projections are special -because they can **always** be fully normalized. - -Often, we can normalize other associated type projections as well. For -example, ` as IntoIterator>::Item`, where `?T` is an inference -variable, can be normalized to just `?T`. - -In our logic, normalization is defined by a predicate -`Normalize`. The `Normalize` clauses arise only from -impls. For example, the `impl` of `IntoIterator` for `Option` that -we saw above would be lowered to a program clause like so: - -```text -forall { - Normalize( as IntoIterator>::Item -> T) :- - Implemented(Option: IntoIterator) -} -``` - -where in this case, the one `Implemented` condition is always true. - -> Since we do not permit quantification over traits, this is really more like -> a family of program clauses, one for each associated type. - -We could apply that rule to normalize either of the examples that -we've seen so far. - -## Placeholder associated types - -Sometimes however we want to work with associated types that cannot be -normalized. For example, consider this function: - -```rust,ignore -fn foo(...) { ... } -``` - -In this context, how would we normalize the type `T::Item`? - -Without knowing what `T` is, we can't really do so. To represent this case, -we introduce a type called a **placeholder associated type projection**. This -is written like so: `(IntoIterator::Item)`. - -You may note that it looks a lot like a regular type (e.g., `Option`), -except that the "name" of the type is `(IntoIterator::Item)`. This is not an -accident: placeholder associated type projections work just like ordinary -types like `Vec` when it comes to unification. That is, they are only -considered equal if (a) they are both references to the same associated type, -like `IntoIterator::Item` and (b) their type arguments are equal. - -Placeholder associated types are never written directly by the user. -They are used internally by the trait system only, as we will see -shortly. - -In rustc, they correspond to the `TyKind::UnnormalizedProjectionTy` enum -variant, declared in [`librustc_middle/ty/sty.rs`][sty]. In chalk, we use an -`ApplicationTy` with a name living in a special namespace dedicated to -placeholder associated types (see the `TypeName` enum declared in -[`chalk-ir/src/lib.rs`][chalk_type_name]). - -[sty]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/ty/sty.rs -[chalk_type_name]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-ir/src/lib.rs - -## Projection equality - -So far we have seen two ways to answer the question of "When can we -consider an associated type projection equal to another type?": - -- the `Normalize` predicate could be used to transform projections when we - knew which impl applied; -- **placeholder** associated types can be used when we don't. This is also - known as **lazy normalization**. - -We now introduce the `ProjectionEq` predicate to bring those two cases -together. The `ProjectionEq` predicate looks like so: - -```text -ProjectionEq(::Item = U) -``` - -and we will see that it can be proven *either* via normalization or -via the placeholder type. As part of lowering an associated type declaration from -some trait, we create two program clauses for `ProjectionEq`: - -```text -forall { - ProjectionEq(::Item = U) :- - Normalize(::Item -> U) -} - -forall { - ProjectionEq(::Item = (IntoIterator::Item)) -} -``` - -These are the only two `ProjectionEq` program clauses we ever make for -any given associated item. - -## Integration with unification - -Now we are ready to discuss how associated type equality integrates -with unification. As described in the -[type inference](../type-inference.html) section, unification is -basically a procedure with a signature like this: - -```text -Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution> -``` - -In other words, we try to unify two things A and B. That procedure -might just fail, in which case we get back `Err(NoSolution)`. This -would happen, for example, if we tried to unify `u32` and `i32`. - -The key point is that, on success, unification can also give back to -us a set of subgoals that still remain to be proven. (It can also give -back region constraints, but those are not relevant here). - -Whenever unification encounters a non-placeholder associated type -projection P being equated with some other type T, it always succeeds, -but it produces a subgoal `ProjectionEq(P = T)` that is propagated -back up. Thus it falls to the ordinary workings of the trait system -to process that constraint. - -> If we unify two projections P1 and P2, then unification produces a -> variable X and asks us to prove that `ProjectionEq(P1 = X)` and -> `ProjectionEq(P2 = X)`. (That used to be needed in an older system to -> prevent cycles; I rather doubt it still is. -nmatsakis) diff --git a/src/traits/bibliography.md b/src/traits/bibliography.md deleted file mode 100644 index a0242d4c4..000000000 --- a/src/traits/bibliography.md +++ /dev/null @@ -1,27 +0,0 @@ -# Bibliography - -If you'd like to read more background material, here are some -recommended texts and papers: - -[Programming with Higher-order Logic][phl], by Dale Miller and Gopalan -Nadathur, covers the key concepts of Lambda prolog. Although it's a -slim little volume, it's the kind of book where you learn something -new every time you open it. - -[phl]: https://www.amazon.com/Programming-Higher-Order-Logic-Dale-Miller/dp/052187940X - - - -["A proof procedure for the logic of Hereditary Harrop formulas"][pphhf], -by Gopalan Nadathur. This paper covers the basics of universes, -environments, and Lambda Prolog-style proof search. Quite readable. - -[pphhf]: https://dl.acm.org/citation.cfm?id=868380 - - - -["A new formulation of tabled resolution with delay"][nftrd], by -Theresa Swift. This paper gives a kind of abstract treatment of the -SLG formulation that is the basis for our on-demand solver. - -[nftrd]: https://dl.acm.org/citation.cfm?id=651202 diff --git a/src/traits/canonical-queries.md b/src/traits/canonical-queries.md deleted file mode 100644 index e15bdaae2..000000000 --- a/src/traits/canonical-queries.md +++ /dev/null @@ -1,252 +0,0 @@ -# Canonical queries - -The "start" of the trait system is the **canonical query** (these are -both queries in the more general sense of the word – something you -would like to know the answer to – and in the -[rustc-specific sense](../query.html)). The idea is that the type -checker or other parts of the system, may in the course of doing their -thing want to know whether some trait is implemented for some type -(e.g., is `u32: Debug` true?). Or they may want to -[normalize some associated type](./associated-types.html). - -This section covers queries at a fairly high level of abstraction. The -subsections look a bit more closely at how these ideas are implemented -in rustc. - -## The traditional, interactive Prolog query - -In a traditional Prolog system, when you start a query, the solver -will run off and start supplying you with every possible answer it can -find. So given something like this: - -```text -?- Vec: AsRef -``` - -The solver might answer: - -```text -Vec: AsRef<[i32]> - continue? (y/n) -``` - -This `continue` bit is interesting. The idea in Prolog is that the -solver is finding **all possible** instantiations of your query that -are true. In this case, if we instantiate `?U = [i32]`, then the query -is true (note that a traditional Prolog interface does not, directly, -tell us a value for `?U`, but we can infer one by unifying the -response with our original query – Rust's solver gives back a -substitution instead). If we were to hit `y`, the solver might then -give us another possible answer: - -```text -Vec: AsRef> - continue? (y/n) -``` - -This answer derives from the fact that there is a reflexive impl -(`impl AsRef for T`) for `AsRef`. If were to hit `y` again, -then we might get back a negative response: - -```text -no -``` - -Naturally, in some cases, there may be no possible answers, and hence -the solver will just give me back `no` right away: - -```text -?- Box: Copy - no -``` - -In some cases, there might be an infinite number of responses. So for -example if I gave this query, and I kept hitting `y`, then the solver -would never stop giving me back answers: - -```text -?- Vec: Clone - Vec: Clone - continue? (y/n) - Vec>: Clone - continue? (y/n) - Vec>>: Clone - continue? (y/n) - Vec>>>: Clone - continue? (y/n) -``` - -As you can imagine, the solver will gleefully keep adding another -layer of `Box` until we ask it to stop, or it runs out of memory. - -Another interesting thing is that queries might still have variables -in them. For example: - -```text -?- Rc: Clone -``` - -might produce the answer: - -```text -Rc: Clone - continue? (y/n) -``` - -After all, `Rc` is true **no matter what type `?T` is**. - - - -## A trait query in rustc - -The trait queries in rustc work somewhat differently. Instead of -trying to enumerate **all possible** answers for you, they are looking -for an **unambiguous** answer. In particular, when they tell you the -value for a type variable, that means that this is the **only possible -instantiation** that you could use, given the current set of impls and -where-clauses, that would be provable. (Internally within the solver, -though, they can potentially enumerate all possible answers. See -[the description of the SLG solver](./slg.html) for details.) - -The response to a trait query in rustc is typically a -`Result, NoSolution>` (where the `T` will vary a bit -depending on the query itself). The `Err(NoSolution)` case indicates -that the query was false and had no answers (e.g., `Box: Copy`). -Otherwise, the `QueryResult` gives back information about the possible answer(s) -we did find. It consists of four parts: - -- **Certainty:** tells you how sure we are of this answer. It can have two - values: - - `Proven` means that the result is known to be true. - - This might be the result for trying to prove `Vec: Clone`, - say, or `Rc: Clone`. - - `Ambiguous` means that there were things we could not yet prove to - be either true *or* false, typically because more type information - was needed. (We'll see an example shortly.) - - This might be the result for trying to prove `Vec: Clone`. -- **Var values:** Values for each of the unbound inference variables - (like `?T`) that appeared in your original query. (Remember that in Prolog, - we had to infer these.) - - As we'll see in the example below, we can get back var values even - for `Ambiguous` cases. -- **Region constraints:** these are relations that must hold between - the lifetimes that you supplied as inputs. We'll ignore these here, - but see the - [section on handling regions in traits](./regions.html) for - more details. -- **Value:** The query result also comes with a value of type `T`. For - some specialized queries – like normalizing associated types – - this is used to carry back an extra result, but it's often just - `()`. - -### Examples - -Let's work through an example query to see what all the parts mean. -Consider [the `Borrow` trait][borrow]. This trait has a number of -impls; among them, there are these two (for clarity, I've written the -`Sized` bounds explicitly): - -[borrow]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html - -```rust,ignore -impl Borrow for T where T: ?Sized -impl Borrow<[T]> for Vec where T: Sized -``` - -**Example 1.** Imagine we are type-checking this (rather artificial) -bit of code: - -```rust,ignore -fn foo(a: A, vec_b: Option) where A: Borrow { } - -fn main() { - let mut t: Vec<_> = vec![]; // Type: Vec - let mut u: Option<_> = None; // Type: Option - foo(t, u); // Example 1: requires `Vec: Borrow` - ... -} -``` - -As the comments indicate, we first create two variables `t` and `u`; -`t` is an empty vector and `u` is a `None` option. Both of these -variables have unbound inference variables in their type: `?T` -represents the elements in the vector `t` and `?U` represents the -value stored in the option `u`. Next, we invoke `foo`; comparing the -signature of `foo` to its arguments, we wind up with `A = Vec` and -`B = ?U`. Therefore, the where clause on `foo` requires that `Vec: -Borrow`. This is thus our first example trait query. - -There are many possible solutions to the query `Vec: Borrow`; -for example: - -- `?U = Vec`, -- `?U = [?T]`, -- `?T = u32, ?U = [u32]` -- and so forth. - -Therefore, the result we get back would be as follows (I'm going to -ignore region constraints and the "value"): - -- Certainty: `Ambiguous` – we're not sure yet if this holds -- Var values: `[?T = ?T, ?U = ?U]` – we learned nothing about the values of - the variables - -In short, the query result says that it is too soon to say much about -whether this trait is proven. During type-checking, this is not an -immediate error: instead, the type checker would hold on to this -requirement (`Vec: Borrow`) and wait. As we'll see in the next -example, it may happen that `?T` and `?U` wind up constrained from -other sources, in which case we can try the trait query again. - -**Example 2.** We can now extend our previous example a bit, -and assign a value to `u`: - -```rust,ignore -fn foo(a: A, vec_b: Option) where A: Borrow { } - -fn main() { - // What we saw before: - let mut t: Vec<_> = vec![]; // Type: Vec - let mut u: Option<_> = None; // Type: Option - foo(t, u); // `Vec: Borrow` => ambiguous - - // New stuff: - u = Some(vec![]); // ?U = Vec -} -``` - -As a result of this assignment, the type of `u` is forced to be -`Option>`, where `?V` represents the element type of the -vector. This in turn implies that `?U` is [unified] to `Vec`. - -[unified]: ../type-checking.html - -Let's suppose that the type checker decides to revisit the -"as-yet-unproven" trait obligation we saw before, `Vec: -Borrow`. `?U` is no longer an unbound inference variable; it now -has a value, `Vec`. So, if we "refresh" the query with that value, we get: - -```text -Vec: Borrow> -``` - -This time, there is only one impl that applies, the reflexive impl: - -```text -impl Borrow for T where T: ?Sized -``` - -Therefore, the trait checker will answer: - -- Certainty: `Proven` -- Var values: `[?T = ?T, ?V = ?T]` - -Here, it is saying that we have indeed proven that the obligation -holds, and we also know that `?T` and `?V` are the same type (but we -don't know what that type is yet!). - -(In fact, as the function ends here, the type checker would give an -error at this point, since the element types of `t` and `u` are still -not yet known, even though they are known to be the same.) - - diff --git a/src/traits/canonicalization.md b/src/traits/canonicalization.md deleted file mode 100644 index d6d57d785..000000000 --- a/src/traits/canonicalization.md +++ /dev/null @@ -1,256 +0,0 @@ -# Canonicalization - -Canonicalization is the process of **isolating** an inference value -from its context. It is a key part of implementing -[canonical queries][cq], and you may wish to read the parent chapter -to get more context. - -Canonicalization is really based on a very simple concept: every -[inference variable](../type-inference.html#vars) is always in one of -two states: either it is **unbound**, in which case we don't know yet -what type it is, or it is **bound**, in which case we do. So to -isolate some data-structure T that contains types/regions from its -environment, we just walk down and find the unbound variables that -appear in T; those variables get replaced with "canonical variables", -starting from zero and numbered in a fixed order (left to right, for -the most part, but really it doesn't matter as long as it is -consistent). - -[cq]: ./canonical-queries.html - -So, for example, if we have the type `X = (?T, ?U)`, where `?T` and -`?U` are distinct, unbound inference variables, then the canonical -form of `X` would be `(?0, ?1)`, where `?0` and `?1` represent these -**canonical placeholders**. Note that the type `Y = (?U, ?T)` also -canonicalizes to `(?0, ?1)`. But the type `Z = (?T, ?T)` would -canonicalize to `(?0, ?0)` (as would `(?U, ?U)`). In other words, the -exact identity of the inference variables is not important – unless -they are repeated. - -We use this to improve caching as well as to detect cycles and other -things during trait resolution. Roughly speaking, the idea is that if -two trait queries have the same canonical form, then they will get -the same answer. That answer will be expressed in terms of the -canonical variables (`?0`, `?1`), which we can then map back to the -original variables (`?T`, `?U`). - -## Canonicalizing the query - -To see how it works, imagine that we are asking to solve the following -trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound. -This query contains two unbound variables, but it also contains the -lifetime `'static`. The trait system generally ignores all lifetimes -and treats them equally, so when canonicalizing, we will *also* -replace any [free lifetime](../appendix/background.html#free-vs-bound) with a -canonical variable (Note that `'static` is actually a _free_ lifetime -variable here. We are not considering it in the typing context of the whole -program but only in the context of this trait reference. Mathematically, we -are not quantifying over the whole program, but only this obligation). -Therefore, we get the following result: - -```text -?0: Foo<'?1, ?2> -``` - -Sometimes we write this differently, like so: - -```text -for { ?0: Foo<'?1, ?2> } -``` - -This `for<>` gives some information about each of the canonical -variables within. In this case, each `T` indicates a type variable, -so `?0` and `?2` are types; the `L` indicates a lifetime variable, so -`?1` is a lifetime. The `canonicalize` method *also* gives back a -`CanonicalVarValues` array OV with the "original values" for each -canonicalized variable: - -```text -[?A, 'static, ?B] -``` - -We'll need this vector OV later, when we process the query response. - -## Executing the query - -Once we've constructed the canonical query, we can try to solve it. -To do so, we will wind up creating a fresh inference context and -**instantiating** the canonical query in that context. The idea is that -we create a substitution S from the canonical form containing a fresh -inference variable (of suitable kind) for each canonical variable. -So, for our example query: - -```text -for { ?0: Foo<'?1, ?2> } -``` - -the substitution S might be: - -```text -S = [?A, '?B, ?C] -``` - -We can then replace the bound canonical variables (`?0`, etc) with -these inference variables, yielding the following fully instantiated -query: - -```text -?A: Foo<'?B, ?C> -``` - -Remember that substitution S though! We're going to need it later. - -OK, now that we have a fresh inference context and an instantiated -query, we can go ahead and try to solve it. The trait solver itself is -explained in more detail in [another section](./slg.html), but -suffice to say that it will compute a [certainty value][cqqr] (`Proven` or -`Ambiguous`) and have side-effects on the inference variables we've -created. For example, if there were only one impl of `Foo`, like so: - -[cqqr]: ./canonical-queries.html#query-response - -```rust,ignore -impl<'a, X> Foo<'a, X> for Vec -where X: 'a -{ ... } -``` - -then we might wind up with a certainty value of `Proven`, as well as -creating fresh inference variables `'?D` and `?E` (to represent the -parameters on the impl) and unifying as follows: - -- `'?B = '?D` -- `?A = Vec` -- `?C = ?E` - -We would also accumulate the region constraint `?E: '?D`, due to the -where clause. - -In order to create our final query result, we have to "lift" these -values out of the query's inference context and into something that -can be reapplied in our original inference context. We do that by -**re-applying canonicalization**, but to the **query result**. - -## Canonicalizing the query result - -As discussed in [the parent section][cqqr], most trait queries wind up -with a result that brings together a "certainty value" `certainty`, a -result substitution `var_values`, and some region constraints. To -create this, we wind up re-using the substitution S that we created -when first instantiating our query. To refresh your memory, we had a query - -```text -for { ?0: Foo<'?1, ?2> } -``` - -for which we made a substutition S: - -```text -S = [?A, '?B, ?C] -``` - -We then did some work which unified some of those variables with other things. -If we "refresh" S with the latest results, we get: - -```text -S = [Vec, '?D, ?E] -``` - -These are precisely the new values for the three input variables from -our original query. Note though that they include some new variables -(like `?E`). We can make those go away by canonicalizing again! We don't -just canonicalize S, though, we canonicalize the whole query response QR: - -```text -QR = { - certainty: Proven, // or whatever - var_values: [Vec, '?D, ?E] // this is S - region_constraints: [?E: '?D], // from the impl - value: (), // for our purposes, just (), but - // in some cases this might have - // a type or other info -} -``` - -The result would be as follows: - -```text -Canonical(QR) = for { - certainty: Proven, - var_values: [Vec, '?1, ?0] - region_constraints: [?0: '?1], - value: (), -} -``` - -(One subtle point: when we canonicalize the query **result**, we do not -use any special treatment for free lifetimes. Note that both -references to `'?D`, for example, were converted into the same -canonical variable (`?1`). This is in contrast to the original query, -where we canonicalized every free lifetime into a fresh canonical -variable.) - -Now, this result must be reapplied in each context where needed. - -## Processing the canonicalized query result - -In the previous section we produced a canonical query result. We now have -to apply that result in our original context. If you recall, way back in the -beginning, we were trying to prove this query: - -```text -?A: Foo<'static, ?B> -``` - -We canonicalized that into this: - -```text -for { ?0: Foo<'?1, ?2> } -``` - -and now we got back a canonical response: - -```text -for { - certainty: Proven, - var_values: [Vec, '?1, ?0] - region_constraints: [?0: '?1], - value: (), -} -``` - -We now want to apply that response to our context. Conceptually, how -we do that is to (a) instantiate each of the canonical variables in -the result with a fresh inference variable, (b) unify the values in -the result with the original values, and then (c) record the region -constraints for later. Doing step (a) would yield a result of - -```text -{ - certainty: Proven, - var_values: [Vec, '?D, ?C] - ^^ ^^^ fresh inference variables - region_constraints: [?C: '?D], - value: (), -} -``` - -Step (b) would then unify: - -```text -?A with Vec -'static with '?D -?B with ?C -``` - -And finally the region constraint of `?C: 'static` would be recorded -for later verification. - -(What we *actually* do is a mildly optimized variant of that: Rather -than eagerly instantiating all of the canonical values in the result -with variables, we instead walk the vector of values, looking for -cases where the value is just a canonical variable. In our example, -`values[2]` is `?C`, so that means we can deduce that `?C := ?B` and -`'?D := 'static`. This gives us a partial set of values. Anything for -which we do not find a value, we create an inference variable.) - diff --git a/src/traits/chalk-overview.md b/src/traits/chalk-overview.md deleted file mode 100644 index 64cb589c1..000000000 --- a/src/traits/chalk-overview.md +++ /dev/null @@ -1,256 +0,0 @@ -# An Overview of Chalk - -> Chalk is under heavy development, so if any of these links are broken or if -> any of the information is inconsistent with the code or outdated, please -> [open an issue][rustc-issues] so we can fix it. If you are able to fix the -> issue yourself, we would love your contribution! - -[Chalk][chalk] recasts Rust's trait system explicitly in terms of logic -programming by "lowering" Rust code into a kind of logic program we can then -execute queries against (see [*Lowering to Logic*][lowering-to-logic] and -[*Lowering Rules*][lowering-rules]). Its goal is to be an executable, highly -readable specification of the Rust trait system. - -There are many expected benefits from this work. It will consolidate our -existing, somewhat ad-hoc implementation into something far more principled and -expressive, which should behave better in corner cases, and be much easier to -extend. - -## Chalk Structure - -Chalk has two main "products". The first of these is the -[`chalk_engine`][chalk_engine] crate, which defines the core [SLG -solver][slg]. This is the part rustc uses. - -The rest of chalk can be considered an elaborate testing harness. Chalk is -capable of parsing Rust-like "programs", lowering them to logic, and -performing queries on them. - -Here's a sample session in the chalk repl, chalki. After feeding it our -program, we perform some queries on it. - -```rust,ignore -?- program -Enter a program; press Ctrl-D when finished -| struct Foo { } -| struct Bar { } -| struct Vec { } -| trait Clone { } -| impl Clone for Vec where T: Clone { } -| impl Clone for Foo { } - -?- Vec: Clone -Unique; substitution [], lifetime constraints [] - -?- Vec: Clone -No possible solution. - -?- exists { Vec: Clone } -Ambiguous; no inference guidance -``` - -You can see more examples of programs and queries in the [unit -tests][chalk-test-example]. - -Next we'll go through each stage required to produce the output above. - -### Parsing ([chalk_parse]) - -Chalk is designed to be incorporated with the Rust compiler, so the syntax and -concepts it deals with heavily borrow from Rust. It is convenient for the sake -of testing to be able to run chalk on its own, so chalk includes a parser for a -Rust-like syntax. This syntax is orthogonal to the Rust AST and grammar. It is -not intended to look exactly like it or support the exact same syntax. - -The parser takes that syntax and produces an [Abstract Syntax Tree (AST)][ast]. -You can find the [complete definition of the AST][chalk-ast] in the source code. - -The syntax contains things from Rust that we know and love, for example: traits, -impls, and struct definitions. Parsing is often the first "phase" of -transformation that a program goes through in order to become a format that -chalk can understand. - -### Rust Intermediate Representation ([chalk_rust_ir]) - -After getting the AST we convert it to a more convenient intermediate -representation called [`chalk_rust_ir`][chalk_rust_ir]. This is sort of -analogous to the [HIR] in Rust. The process of converting to IR is called -*lowering*. - -The [`chalk::program::Program`][chalk-program] struct contains some "rust things" -but indexed and accessible in a different way. For example, if you have a -type like `Foo`, we would represent `Foo` as a string in the AST but in -`chalk::program::Program`, we use numeric indices (`ItemId`). - -The [IR source code][ir-code] contains the complete definition. - -### Chalk Intermediate Representation ([chalk_ir]) - -Once we have Rust IR it is time to convert it to "program clauses". A -[`ProgramClause`] is essentially one of the following: - -* A [clause] of the form `consequence :- conditions` where `:-` is read as - "if" and `conditions = cond1 && cond2 && ...` -* A universally quantified clause of the form - `forall { consequence :- conditions }` - * `forall { ... }` is used to represent [universal quantification]. See the - section on [Lowering to logic][lowering-forall] for more information. - * A key thing to note about `forall` is that we don't allow you to "quantify" - over traits, only types and regions (lifetimes). That is, you can't make a - rule like `forall { u32: Trait }` which would say "`u32` implements - all traits". You can however say `forall { T: Trait }` meaning "`Trait` - is implemented by all types". - * `forall { ... }` is represented in the code using the [`Binders` - struct][binders-struct]. - -*See also: [Goals and Clauses][goals-and-clauses]* - -This is where we encode the rules of the trait system into logic. For -example, if we have the following Rust: - -```rust,ignore -impl Clone for Vec {} -``` - -We generate the following program clause: - -```rust,ignore -forall { (Vec: Clone) :- (T: Clone) } -``` - -This rule dictates that `Vec: Clone` is only satisfied if `T: Clone` is also -satisfied (i.e. "provable"). - -Similar to [`chalk::program::Program`][chalk-program] which has "rust-like -things", chalk_ir defines [`ProgramEnvironment`] which is "pure logic". -The main field in that struct is `program_clauses`, which contains the -[`ProgramClause`]s generated by the rules module. - -### Rules ([chalk_solve]) - -The `chalk_solve` crate ([source code][chalk_solve]) defines the logic rules we -use for each item in the Rust IR. It works by iterating over every trait, impl, -etc. and emitting the rules that come from each one. - -*See also: [Lowering Rules][lowering-rules]* - -#### Well-formedness checks - -As part of lowering to logic, we also do some "well formedness" checks. See -the [`chalk_solve::wf` source code][solve-wf-src] for where those are done. - -*See also: [Well-formedness checking][wf-checking]* - -#### Coherence - -The method `CoherenceSolver::specialization_priorities` in the `coherence` module -([source code][coherence-src]) checks "coherence", which means that it -ensures that two impls of the same trait for the same type cannot exist. - -### Solver ([chalk_solve]) - -Finally, when we've collected all the program clauses we care about, we want -to perform queries on it. The component that finds the answer to these -queries is called the *solver*. - -*See also: [The SLG Solver][slg]* - -## Crates - -Chalk's functionality is broken up into the following crates: -- [**chalk_engine**][chalk_engine]: Defines the core [SLG solver][slg]. -- [**chalk_rust_ir**][chalk_rust_ir], containing the "HIR-like" form of the AST -- [**chalk_ir**][chalk_ir]: Defines chalk's internal representation of - types, lifetimes, and goals. -- [**chalk_solve**][chalk_solve]: Combines `chalk_ir` and `chalk_engine`, - effectively, which implements logic rules converting `chalk_rust_ir` to - `chalk_ir` - - Defines the `coherence` module, which implements coherence rules - - [`chalk_engine::context`][engine-context] provides the necessary hooks. -- [**chalk_parse**][chalk_parse]: Defines the raw AST and a parser. -- [**chalk**][doc-chalk]: Brings everything together. Defines the following - modules: - - `chalk::lowering`, which converts AST to `chalk_rust_ir` - - Also includes [chalki][chalki], chalk's REPL. - -[Browse source code on GitHub](https://github.com/rust-lang/chalk) - -## Testing - -chalk has a test framework for lowering programs to logic, checking the -lowered logic, and performing queries on it. This is how we test the -implementation of chalk itself, and the viability of the [lowering -rules][lowering-rules]. - -The main kind of tests in chalk are **goal tests**. They contain a program, -which is expected to lower to logic successfully, and a set of queries -(goals) along with the expected output. Here's an -[example][chalk-test-example]. Since chalk's output can be quite long, goal -tests support specifying only a prefix of the output. - -**Lowering tests** check the stages that occur before we can issue queries -to the solver: the [lowering to chalk_rust_ir][chalk-test-lowering], and the -[well-formedness checks][chalk-test-wf] that occur after that. - -### Testing internals - -Goal tests use a [`test!` macro][test-macro] that takes chalk's Rust-like -syntax and runs it through the full pipeline described above. The macro -ultimately calls the [`solve_goal` function][solve_goal]. - -Likewise, lowering tests use the [`lowering_success!` and -`lowering_error!` macros][test-lowering-macros]. - -## More Resources - -* [Chalk Source Code](https://github.com/rust-lang/chalk) -* [Chalk Glossary](https://github.com/rust-lang/chalk/blob/master/GLOSSARY.md) - -### Blog Posts - -* [Lowering Rust traits to logic](http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/) -* [Unification in Chalk, part 1](http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/) -* [Unification in Chalk, part 2](http://smallcultfollowing.com/babysteps/blog/2017/04/23/unification-in-chalk-part-2/) -* [Negative reasoning in Chalk](https://aturon.github.io/blog/2017/04/24/negative-chalk/) -* [Query structure in chalk](http://smallcultfollowing.com/babysteps/blog/2017/05/25/query-structure-in-chalk/) -* [Cyclic queries in chalk](http://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/) -* [An on-demand SLG solver for chalk](http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/) - -[goals-and-clauses]: ./goals-and-clauses.html -[HIR]: ../hir.html -[lowering-forall]: ./lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses -[lowering-rules]: ./lowering-rules.html -[lowering-to-logic]: ./lowering-to-logic.html -[slg]: ./slg.html -[wf-checking]: ./wf.html - -[ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree -[chalk]: https://github.com/rust-lang/chalk -[rustc-issues]: https://github.com/rust-lang/rustc-dev-guide/issues -[universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification - -[`ProgramClause`]: https://rust-lang.github.io/chalk/chalk_ir/struct.ProgramClause.html -[`ProgramEnvironment`]: https://rust-lang.github.io/chalk/chalk_integration/program_environment/struct.ProgramEnvironment.html -[chalk_engine]: https://rust-lang.github.io/chalk/chalk_engine -[chalk_ir]: https://rust-lang.github.io/chalk/chalk_ir/index.html -[chalk_parse]: https://rust-lang.github.io/chalk/chalk_parse/index.html -[chalk_solve]: https://rust-lang.github.io/chalk/chalk_solve/index.html -[chalk_rust_ir]: https://rust-lang.github.io/chalk/chalk_rust_ir/index.html -[doc-chalk]: https://rust-lang.github.io/chalk/chalk/index.html -[engine-context]: https://rust-lang.github.io/chalk/chalk_engine/context/index.html -[chalk-program]: https://rust-lang.github.io/chalk/chalk_integration/program/struct.Program.html - -[binders-struct]: https://rust-lang.github.io/chalk/chalk_ir/struct.Binders.html -[chalk-ast]: https://rust-lang.github.io/chalk/chalk_parse/ast/index.html -[chalk-test-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L115 -[chalk-test-lowering-example]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs#L8-L31 -[chalk-test-lowering]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rust_ir/lowering/test.rs -[chalk-test-wf]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/rules/wf/test.rs#L1 -[chalki]: https://github.com/rust-lang/chalk/blob/master/src/main.rs -[clause]: https://github.com/rust-lang/chalk/blob/master/GLOSSARY.md#clause -[coherence-src]: https://rust-lang.github.io/chalk/chalk_solve/coherence/index.html -[ir-code]: https://rust-lang.github.io/chalk/chalk_rust_ir/ -[solve-wf-src]: https://rust-lang.github.io/chalk/chalk_solve/wf/index.html -[solve_goal]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L85 -[test-lowering-macros]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test_util.rs#L21-L54 -[test-macro]: https://github.com/rust-lang/chalk/blob/4bce000801de31bf45c02f742a5fce335c9f035f/src/test.rs#L33 diff --git a/src/traits/chalk.md b/src/traits/chalk.md new file mode 100644 index 000000000..dcb0a244f --- /dev/null +++ b/src/traits/chalk.md @@ -0,0 +1,43 @@ +# Chalk-based trait solving (new-style) + +> 🚧 This chapter describes "new-style" trait solving. This is still in the +> [process of being implemented][wg]; this chapter serves as a kind of +> in-progress design document. If you would prefer to read about how the +> current trait solver works, check out +> [this other subchapter](./resolution.html). 🚧 +> +> By the way, if you would like to help in hacking on the new solver, you will +> find instructions for getting involved in the +> [Traits Working Group tracking issue][wg]! + +[wg]: https://github.com/rust-lang/rust/issues/48416 + +The new-style trait solver is based on the work done in [chalk][chalk]. Chalk +recasts Rust's trait system explicitly in terms of logic programming. It does +this by "lowering" Rust code into a kind of logic program we can then execute +queries against. + +The key observation here is that the Rust trait system is basically a +kind of logic, and it can be mapped onto standard logical inference +rules. We can then look for solutions to those inference rules in a +very similar fashion to how e.g. a [Prolog] solver works. It turns out +that we can't *quite* use Prolog rules (also called Horn clauses) but +rather need a somewhat more expressive variant. + +[Prolog]: https://en.wikipedia.org/wiki/Prolog + +You can read more about chalk itself in the +[Chalk book](https://rust-lang.github.io/chalk/book/) section. + +## Ongoing work +The design of the new-style trait solving currently happens in two places: + +**chalk**. The [chalk][chalk] repository is where we experiment with new ideas +and designs for the trait system. + +**rustc**. Once we are happy with the logical rules, we proceed to +implementing them in rustc. This mainly happens in +[`librustc_traits`][librustc_traits]. We map our struct, trait, and impl declarations into logical inference rules in the [lowering module in rustc](./lowering-module.md). + +[chalk]: https://github.com/rust-lang/chalk +[librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md deleted file mode 100644 index ecd2ce145..000000000 --- a/src/traits/goals-and-clauses.md +++ /dev/null @@ -1,270 +0,0 @@ -# Goals and clauses - -In logic programming terms, a **goal** is something that you must -prove and a **clause** is something that you know is true. As -described in the [lowering to logic](./lowering-to-logic.html) -chapter, Rust's trait solver is based on an extension of hereditary -harrop (HH) clauses, which extend traditional Prolog Horn clauses with -a few new superpowers. - -## Goals and clauses meta structure - -In Rust's solver, **goals** and **clauses** have the following forms -(note that the two definitions reference one another): - -```text -Goal = DomainGoal // defined in the section below - | Goal && Goal - | Goal || Goal - | exists { Goal } // existential quantification - | forall { Goal } // universal quantification - | if (Clause) { Goal } // implication - | true // something that's trivially true - | ambiguous // something that's never provable - -Clause = DomainGoal - | Clause :- Goal // if can prove Goal, then Clause is true - | Clause && Clause - | forall { Clause } - -K = // a "kind" - | -``` - -The proof procedure for these sorts of goals is actually quite -straightforward. Essentially, it's a form of depth-first search. The -paper -["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] -gives the details. - -In terms of code, these types are defined in -[`librustc_middle/traits/mod.rs`][traits_mod] in rustc, and in -[`chalk-ir/src/lib.rs`][chalk_ir] in chalk. - -[pphhf]: ./bibliography.html#pphhf -[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs -[chalk_ir]: https://github.com/rust-lang/chalk/blob/master/chalk-ir/src/lib.rs - - - -## Domain goals - -*Domain goals* are the atoms of the trait logic. As can be seen in the -definitions given above, general goals basically consist in a combination of -domain goals. - -Moreover, flattening a bit the definition of clauses given previously, one can -see that clauses are always of the form: -```text -forall { DomainGoal :- Goal } -``` -hence domain goals are in fact clauses' LHS. That is, at the most granular level, -domain goals are what the trait solver will end up trying to prove. - - - -To define the set of domain goals in our system, we need to first -introduce a few simple formulations. A **trait reference** consists of -the name of a trait along with a suitable set of inputs P0..Pn: - -```text -TraitRef = P0: TraitName -``` - -So, for example, `u32: Display` is a trait reference, as is `Vec: -IntoIterator`. Note that Rust surface syntax also permits some extra -things, like associated type bindings (`Vec: IntoIterator`), that are not part of a trait reference. - - - -A **projection** consists of an associated item reference along with -its inputs P0..Pm: - -```text -Projection = >::AssocItem -``` - -Given these, we can define a `DomainGoal` as follows: - -```text -DomainGoal = Holds(WhereClause) - | FromEnv(TraitRef) - | FromEnv(Type) - | WellFormed(TraitRef) - | WellFormed(Type) - | Normalize(Projection -> Type) - -WhereClause = Implemented(TraitRef) - | ProjectionEq(Projection = Type) - | Outlives(Type: Region) - | Outlives(Region: Region) -``` - -`WhereClause` refers to a `where` clause that a Rust user would actually be able -to write in a Rust program. This abstraction exists only as a convenience as we -sometimes want to only deal with domain goals that are effectively writable in -Rust. - -Let's break down each one of these, one-by-one. - -#### Implemented(TraitRef) -e.g. `Implemented(i32: Copy)` - -True if the given trait is implemented for the given input types and lifetimes. - -#### ProjectionEq(Projection = Type) -e.g. `ProjectionEq::Item = u8` - -The given associated type `Projection` is equal to `Type`; this can be proved -with either normalization or using placeholder associated types. See -[the section on associated types](./associated-types.html). - -#### Normalize(Projection -> Type) -e.g. `ProjectionEq::Item -> u8` - -The given associated type `Projection` can be [normalized][n] to `Type`. - -As discussed in [the section on associated -types](./associated-types.html), `Normalize` implies `ProjectionEq`, -but not vice versa. In general, proving `Normalize(::Item -> U)` -also requires proving `Implemented(T: Trait)`. - -[n]: ./associated-types.html#normalize -[at]: ./associated-types.html - -#### FromEnv(TraitRef) -e.g. `FromEnv(Self: Add)` - -True if the inner `TraitRef` is *assumed* to be true, -that is, if it can be derived from the in-scope where clauses. - -For example, given the following function: - -```rust -fn loud_clone(stuff: &T) -> T { - println!("cloning!"); - stuff.clone() -} -``` - -Inside the body of our function, we would have `FromEnv(T: Clone)`. In-scope -where clauses nest, so a function body inside an impl body inherits the -impl body's where clauses, too. - -This and the next rule are used to implement [implied bounds]. As we'll see -in the section on lowering, `FromEnv(TraitRef)` implies `Implemented(TraitRef)`, -but not vice versa. This distinction is crucial to implied bounds. - -#### FromEnv(Type) -e.g. `FromEnv(HashSet)` - -True if the inner `Type` is *assumed* to be well-formed, that is, if it is an -input type of a function or an impl. - -For example, given the following code: - -```rust,ignore -struct HashSet where K: Hash { ... } - -fn loud_insert(set: &mut HashSet, item: K) { - println!("inserting!"); - set.insert(item); -} -``` - -`HashSet` is an input type of the `loud_insert` function. Hence, we assume it -to be well-formed, so we would have `FromEnv(HashSet)` inside the body of our -function. As we'll see in the section on lowering, `FromEnv(HashSet)` implies -`Implemented(K: Hash)` because the -`HashSet` declaration was written with a `K: Hash` where clause. Hence, we don't -need to repeat that bound on the `loud_insert` function: we rather automatically -assume that it is true. - -#### WellFormed(Item) -These goals imply that the given item is *well-formed*. - -We can talk about different types of items being well-formed: - -* *Types*, like `WellFormed(Vec)`, which is true in Rust, or - `WellFormed(Vec)`, which is not (because `str` is not `Sized`.) - -* *TraitRefs*, like `WellFormed(Vec: Clone)`. - -Well-formedness is important to [implied bounds]. In particular, the reason -it is okay to assume `FromEnv(T: Clone)` in the `loud_clone` example is that we -_also_ verify `WellFormed(T: Clone)` for each call site of `loud_clone`. -Similarly, it is okay to assume `FromEnv(HashSet)` in the `loud_insert` -example because we will verify `WellFormed(HashSet)` for each call site of -`loud_insert`. - -#### Outlives(Type: Region), Outlives(Region: Region) -e.g. `Outlives(&'a str: 'b)`, `Outlives('a: 'static)` - -True if the given type or region on the left outlives the right-hand region. - - - -## Coinductive goals - -Most goals in our system are "inductive". In an inductive goal, -circular reasoning is disallowed. Consider this example clause: - -```text - Implemented(Foo: Bar) :- - Implemented(Foo: Bar). -``` - -Considered inductively, this clause is useless: if we are trying to -prove `Implemented(Foo: Bar)`, we would then recursively have to prove -`Implemented(Foo: Bar)`, and that cycle would continue ad infinitum -(the trait solver will terminate here, it would just consider that -`Implemented(Foo: Bar)` is not known to be true). - -However, some goals are *co-inductive*. Simply put, this means that -cycles are OK. So, if `Bar` were a co-inductive trait, then the rule -above would be perfectly valid, and it would indicate that -`Implemented(Foo: Bar)` is true. - -*Auto traits* are one example in Rust where co-inductive goals are used. -Consider the `Send` trait, and imagine that we have this struct: - -```rust -struct Foo { - next: Option> -} -``` - -The default rules for auto traits say that `Foo` is `Send` if the -types of its fields are `Send`. Therefore, we would have a rule like - -```text -Implemented(Foo: Send) :- - Implemented(Option>: Send). -``` - -As you can probably imagine, proving that `Option>: Send` is -going to wind up circularly requiring us to prove that `Foo: Send` -again. So this would be an example where we wind up in a cycle – but -that's ok, we *do* consider `Foo: Send` to hold, even though it -references itself. - -In general, co-inductive traits are used in Rust trait solving when we -want to enumerate a fixed set of possibilities. In the case of auto -traits, we are enumerating the set of reachable types from a given -starting point (i.e., `Foo` can reach values of type -`Option>`, which implies it can reach values of type -`Box`, and then of type `Foo`, and then the cycle is complete). - -In addition to auto traits, `WellFormed` predicates are co-inductive. -These are used to achieve a similar "enumerate all the cases" pattern, -as described in the section on [implied bounds]. - -[implied bounds]: ./lowering-rules.html#implied-bounds - -## Incomplete chapter - -Some topics yet to be written: - -- Elaborate on the proof procedure -- SLG solving – introduce negative reasoning diff --git a/src/traits/implied-bounds.md b/src/traits/implied-bounds.md deleted file mode 100644 index 5876f3b62..000000000 --- a/src/traits/implied-bounds.md +++ /dev/null @@ -1,502 +0,0 @@ -# Implied Bounds - -Implied bounds remove the need to repeat where clauses written on -a type declaration or a trait declaration. For example, say we have the -following type declaration: -```rust,ignore -struct HashSet { - ... -} -``` - -then everywhere we use `HashSet` as an "input" type, that is appearing in -the receiver type of an `impl` or in the arguments of a function, we don't -want to have to repeat the `where K: Hash` bound, as in: - -```rust,ignore -// I don't want to have to repeat `where K: Hash` here. -impl HashSet { - ... -} - -// Same here. -fn loud_insert(set: &mut HashSet, item: K) { - println!("inserting!"); - set.insert(item); -} -``` - -Note that in the `loud_insert` example, `HashSet` is not the type -of the `set` argument of `loud_insert`, it only *appears* in the -argument type `&mut HashSet`: we care about every type appearing -in the function's header (the header is the signature without the return type), -not only types of the function's arguments. - -The rationale for applying implied bounds to input types is that, for example, -in order to call the `loud_insert` function above, the programmer must have -*produced* the type `HashSet` already, hence the compiler already verified -that `HashSet` was well-formed, i.e. that `K` effectively implemented -`Hash`, as in the following example: - -```rust,ignore -fn main() { - // I am producing a value of type `HashSet`. - // If `i32` was not `Hash`, the compiler would report an error here. - let set: HashSet = HashSet::new(); - loud_insert(&mut set, 5); -} -``` - -Hence, we don't want to repeat where clauses for input types because that would -sort of duplicate the work of the programmer, having to verify that their types -are well-formed both when calling the function and when using them in the -arguments of their function. The same reasoning applies when using an `impl`. - -Similarly, given the following trait declaration: -```rust,ignore -trait Copy where Self: Clone { // desugared version of `Copy: Clone` - ... -} -``` - -then everywhere we bound over `SomeType: Copy`, we would like to be able to -use the fact that `SomeType: Clone` without having to write it explicitly, -as in: -```rust,ignore -fn loud_clone(x: T) { - println!("cloning!"); - x.clone(); -} - -fn fun_with_copy(x: T) { - println!("will clone a `Copy` type soon..."); - - // I'm using `loud_clone` with `T: Copy`, I know this - // implies `T: Clone` so I don't want to have to write it explicitly. - loud_clone(x); -} -``` - -The rationale for implied bounds for traits is that if a type implements -`Copy`, that is, if there exists an `impl Copy` for that type, there *ought* -to exist an `impl Clone` for that type, otherwise the compiler would have -reported an error in the first place. So again, if we were forced to repeat the -additional `where SomeType: Clone` everywhere whereas we already know that -`SomeType: Copy` hold, we would kind of duplicate the verification work. - -Implied bounds are not yet completely enforced in rustc, at the moment it only -works for outlive requirements, super trait bounds, and bounds on associated -types. The full RFC can be found [here][RFC]. We'll give here a brief view -of how implied bounds work and why we chose to implement it that way. The -complete set of lowering rules can be found in the corresponding -[chapter](./lowering-rules.md). - -[RFC]: https://github.com/rust-lang/rfcs/blob/master/text/2089-implied-bounds.md - -## Implied bounds and lowering rules - -Now we need to express implied bounds in terms of logical rules. We will start -with exposing a naive way to do it. Suppose that we have the following traits: -```rust,ignore -trait Foo { - ... -} - -trait Bar where Self: Foo { } { - ... -} -``` - -So we would like to say that if a type implements `Bar`, then necessarily -it must also implement `Foo`. We might think that a clause like this would -work: -```text -forall { - Implemented(Type: Foo) :- Implemented(Type: Bar). -} -``` - -Now suppose that we just write this impl: -```rust,ignore -struct X; - -impl Bar for X { } -``` - -Clearly this should not be allowed: indeed, we wrote a `Bar` impl for `X`, but -the `Bar` trait requires that we also implement `Foo` for `X`, which we never -did. In terms of what the compiler does, this would look like this: -```rust,ignore -struct X; - -impl Bar for X { - // We are in a `Bar` impl for the type `X`. - // There is a `where Self: Foo` bound on the `Bar` trait declaration. - // Hence I need to prove that `X` also implements `Foo` for that impl - // to be legal. -} -``` -So the compiler would try to prove `Implemented(X: Foo)`. Of course it will -not find any `impl Foo for X` since we did not write any. However, it -will see our implied bound clause: -```text -forall { - Implemented(Type: Foo) :- Implemented(Type: Bar). -} -``` - -so that it may be able to prove `Implemented(X: Foo)` if `Implemented(X: Bar)` -holds. And it turns out that `Implemented(X: Bar)` does hold since we wrote -a `Bar` impl for `X`! Hence the compiler will accept the `Bar` impl while it -should not. - -## Implied bounds coming from the environment - -So the naive approach does not work. What we need to do is to somehow decouple -implied bounds from impls. Suppose we know that a type `SomeType<...>` -implements `Bar` and we want to deduce that `SomeType<...>` must also implement -`Foo`. - -There are two possibilities: first, we have enough information about -`SomeType<...>` to see that there exists a `Bar` impl in the program which -covers `SomeType<...>`, for example a plain `impl<...> Bar for SomeType<...>`. -Then if the compiler has done its job correctly, there *must* exist a `Foo` -impl which covers `SomeType<...>`, e.g. another plain -`impl<...> Foo for SomeType<...>`. In that case then, we can just use this -impl and we do not need implied bounds at all. - -Second possibility: we do not know enough about `SomeType<...>` in order to -find a `Bar` impl which covers it, for example if `SomeType<...>` is just -a type parameter in a function: -```rust,ignore -fn foo() { - // We'd like to deduce `Implemented(T: Foo)`. -} -``` - -That is, the information that `T` implements `Bar` here comes from the -*environment*. The environment is the set of things that we assume to be true -when we type check some Rust declaration. In that case, what we assume is that -`T: Bar`. Then at that point, we might authorize ourselves to have some kind -of "local" implied bound reasoning which would say -`Implemented(T: Foo) :- Implemented(T: Bar)`. This reasoning would -only be done within our `foo` function in order to avoid the earlier -problem where we had a global clause. - -We can apply these local reasonings everywhere we can have an environment --- i.e. when we can write where clauses -- that is, inside impls, -trait declarations, and type declarations. - -## Computing implied bounds with `FromEnv` - -The previous subsection showed that it was only useful to compute implied -bounds for facts coming from the environment. -We talked about "local" rules, but there are multiple possible strategies to -indeed implement the locality of implied bounds. - -In rustc, the current strategy is to *elaborate* bounds: that is, each time -we have a fact in the environment, we recursively derive all the other things -that are implied by this fact until we reach a fixed point. For example, if -we have the following declarations: -```rust,ignore -trait A { } -trait B where Self: A { } -trait C where Self: B { } - -fn foo() { - ... -} -``` -then inside the `foo` function, we start with an environment containing only -`Implemented(T: C)`. Then because of implied bounds for the `C` trait, we -elaborate `Implemented(T: B)` and add it to our environment. Because of -implied bounds for the `B` trait, we elaborate `Implemented(T: A)`and add it -to our environment as well. We cannot elaborate anything else, so we conclude -that our final environment consists of `Implemented(T: A + B + C)`. - -In the new-style trait system, we like to encode as many things as possible -with logical rules. So rather than "elaborating", we have a set of *global* -program clauses defined like so: -```text -forall { Implemented(T: A) :- FromEnv(T: A). } - -forall { Implemented(T: B) :- FromEnv(T: B). } -forall { FromEnv(T: A) :- FromEnv(T: B). } - -forall { Implemented(T: C) :- FromEnv(T: C). } -forall { FromEnv(T: C) :- FromEnv(T: C). } -``` -So these clauses are defined globally (that is, they are available from -everywhere in the program) but they cannot be used because the hypothesis -is always of the form `FromEnv(...)` which is a bit special. Indeed, as -indicated by the name, `FromEnv(...)` facts can **only** come from the -environment. -How it works is that in the `foo` function, instead of having an environment -containing `Implemented(T: C)`, we replace this environment with -`FromEnv(T: C)`. From here and thanks to the above clauses, we see that we -are able to reach any of `Implemented(T: A)`, `Implemented(T: B)` or -`Implemented(T: C)`, which is what we wanted. - -## Implied bounds and well-formedness checking - -Implied bounds are tightly related with well-formedness checking. -Well-formedness checking is the process of checking that the impls the -programmer wrote are legal, what we referred to earlier as "the compiler doing -its job correctly". - -We already saw examples of illegal and legal impls: -```rust,ignore -trait Foo { } -trait Bar where Self: Foo { } - -struct X; -struct Y; - -impl Bar for X { - // This impl is not legal: the `Bar` trait requires that we also - // implement `Foo`, and we didn't. -} - -impl Foo for Y { - // This impl is legal: there is nothing to check as there are no where - // clauses on the `Foo` trait. -} - -impl Bar for Y { - // This impl is legal: we have a `Foo` impl for `Y`. -} -``` -We must define what "legal" and "illegal" mean. For this, we introduce another -predicate: `WellFormed(Type: Trait)`. We say that the trait reference -`Type: Trait` is well-formed if `Type` meets the bounds written on the -`Trait` declaration. For each impl we write, assuming that the where clauses -declared on the impl hold, the compiler tries to prove that the corresponding -trait reference is well-formed. The impl is legal if the compiler manages to do -so. - -Coming to the definition of `WellFormed(Type: Trait)`, it would be tempting -to define it as: -```rust,ignore -trait Trait where WC1, WC2, ..., WCn { - ... -} -``` - -```text -forall { - WellFormed(Type: Trait) :- WC1 && WC2 && .. && WCn. -} -``` -and indeed this was basically what was done in rustc until it was noticed that -this mixed badly with implied bounds. The key thing is that implied bounds -allows someone to derive all bounds implied by a fact in the environment, and -this *transitively* as we've seen with the `A + B + C` traits example. -However, the `WellFormed` predicate as defined above only checks that the -*direct* superbounds hold. That is, if we come back to our `A + B + C` -example: -```rust,ignore -trait A { } -// No where clauses, always well-formed. -// forall { WellFormed(Type: A). } - -trait B where Self: A { } -// We only check the direct superbound `Self: A`. -// forall { WellFormed(Type: B) :- Implemented(Type: A). } - -trait C where Self: B { } -// We only check the direct superbound `Self: B`. We do not check -// the `Self: A` implied bound coming from the `Self: B` superbound. -// forall { WellFormed(Type: C) :- Implemented(Type: B). } -``` -There is an asymmetry between the recursive power of implied bounds and -the shallow checking of `WellFormed`. It turns out that this asymmetry -can be [exploited][bug]. Indeed, suppose that we define the following -traits: -```rust,ignore -trait Partial where Self: Copy { } -// WellFormed(Self: Partial) :- Implemented(Self: Copy). - -trait Complete where Self: Partial { } -// WellFormed(Self: Complete) :- Implemented(Self: Partial). - -impl Partial for T where T: Complete { } - -impl Complete for T { } -``` - -For the `Partial` impl, what the compiler must prove is: -```text -forall { - if (T: Complete) { // assume that the where clauses hold - WellFormed(T: Partial) // show that the trait reference is well-formed - } -} -``` -Proving `WellFormed(T: Partial)` amounts to proving `Implemented(T: Copy)`. -However, we have `Implemented(T: Complete)` in our environment: thanks to -implied bounds, we can deduce `Implemented(T: Partial)`. Using implied bounds -one level deeper, we can deduce `Implemented(T: Copy)`. Finally, the `Partial` -impl is legal. - -For the `Complete` impl, what the compiler must prove is: -```text -forall { - WellFormed(T: Complete) // show that the trait reference is well-formed -} -``` -Proving `WellFormed(T: Complete)` amounts to proving `Implemented(T: Partial)`. -We see that the `impl Partial for T` applies if we can prove -`Implemented(T: Complete)`, and it turns out we can prove this fact since our -`impl Complete for T` is a blanket impl without any where clauses. - -So both impls are legal and the compiler accepts the program. Moreover, thanks -to the `Complete` blanket impl, all types implement `Complete`. So we could -now use this impl like so: -```rust,ignore -fn eat(x: T) { } - -fn copy_everything(x: T) { - eat(x); - eat(x); -} - -fn main() { - let not_copiable = vec![1, 2, 3, 4]; - copy_everything(not_copiable); -} -``` -In this program, we use the fact that `Vec` implements `Complete`, as any -other type. Hence we can call `copy_everything` with an argument of type -`Vec`. Inside the `copy_everything` function, we have the -`Implemented(T: Complete)` bound in our environment. Thanks to implied bounds, -we can deduce `Implemented(T: Partial)`. Using implied bounds again, we deduce -`Implemented(T: Copy)` and we can indeed call the `eat` function which moves -the argument twice since its argument is `Copy`. Problem: the `T` type was -in fact `Vec` which is not copy at all, hence we will double-free the -underlying vec storage so we have a memory unsoundness in safe Rust. - -Of course, disregarding the asymmetry between `WellFormed` and implied bounds, -this bug was possible only because we had some kind of self-referencing impls. -But self-referencing impls are very useful in practice and are not the real -culprits in this affair. - -[bug]: https://github.com/rust-lang/rust/pull/43786 - -## Co-inductiveness of `WellFormed` - -So the solution is to fix this asymmetry between `WellFormed` and implied -bounds. For that, we need for the `WellFormed` predicate to not only require -that the direct superbounds hold, but also all the bounds transitively implied -by the superbounds. What we can do is to have the following rules for the -`WellFormed` predicate: -```rust,ignore -trait A { } -// WellFormed(Self: A) :- Implemented(Self: A). - -trait B where Self: A { } -// WellFormed(Self: B) :- Implemented(Self: B) && WellFormed(Self: A). - -trait C where Self: B { } -// WellFormed(Self: C) :- Implemented(Self: C) && WellFormed(Self: B). -``` - -Notice that we are now also requiring `Implemented(Self: Trait)` for -`WellFormed(Self: Trait)` to be true: this is to simplify the process of -traversing all the implied bounds transitively. This does not change anything -when checking whether impls are legal, because since we assume -that the where clauses hold inside the impl, we know that the corresponding -trait reference do hold. Thanks to this setup, you can see that we indeed -require to prove the set of all bounds transitively implied by the where -clauses. - -However there is still a catch. Suppose that we have the following trait -definition: -```rust,ignore -trait Foo where ::Item: Foo { - type Item; -} -``` - -so this definition is a bit more involved than the ones we've seen already -because it defines an associated item. However, the well-formedness rule -would not be more complicated: -```text -WellFormed(Self: Foo) :- - Implemented(Self: Foo) && - WellFormed(::Item: Foo). -``` - -Now we would like to write the following impl: -```rust,ignore -impl Foo for i32 { - type Item = i32; -} -``` -The `Foo` trait definition and the `impl Foo for i32` are perfectly valid -Rust: we're kind of recursively using our `Foo` impl in order to show that -the associated value indeed implements `Foo`, but that's ok. But if we -translate this to our well-formedness setting, the compiler proof process -inside the `Foo` impl is the following: it starts with proving that the -well-formedness goal `WellFormed(i32: Foo)` is true. In order to do that, -it must prove the following goals: `Implemented(i32: Foo)` and -`WellFormed(::Item: Foo)`. `Implemented(i32: Foo)` holds because -there is our impl and there are no where clauses on it so it's always true. -However, because of the associated type value we used, -`WellFormed(::Item: Foo)` simplifies to just -`WellFormed(i32: Foo)`. So in order to prove its original goal -`WellFormed(i32: Foo)`, the compiler needs to prove `WellFormed(i32: Foo)`: -this clearly is a cycle and cycles are usually rejected by the trait solver, -unless... if the `WellFormed` predicate was made to be co-inductive. - -A co-inductive predicate, as discussed in the chapter on -[goals and clauses](./goals-and-clauses.md#coinductive-goals), are predicates -for which the -trait solver accepts cycles. In our setting, this would be a valid thing to do: -indeed, the `WellFormed` predicate just serves as a way of enumerating all -the implied bounds. Hence, it's like a fixed point algorithm: it tries to grow -the set of implied bounds until there is nothing more to add. Here, a cycle -in the chain of `WellFormed` predicates just means that there is no more bounds -to add in that direction, so we can just accept this cycle and focus on other -directions. It's easy to prove that under these co-inductive semantics, we -are effectively visiting all the transitive implied bounds, and only these. - -## Implied bounds on types - -We mainly talked about implied bounds for traits because this was the most -subtle regarding implementation. Implied bounds on types are simpler, -especially because if we assume that a type is well-formed, we don't use that -fact to deduce that other types are well-formed, we only use it to deduce -that e.g. some trait bounds hold. - -For types, we just use rules like these ones: -```rust,ignore -struct Type<...> where WC1, ..., WCn { - ... -} -``` - -```text -forall<...> { - WellFormed(Type<...>) :- WC1, ..., WCn. -} - -forall<...> { - FromEnv(WC1) :- FromEnv(Type<...>). - ... - FromEnv(WCn) :- FromEnv(Type<...>). -} -``` -We can see that we have this asymmetry between well-formedness check, -which only verifies that the direct superbounds hold, and implied bounds which -gives access to all bounds transitively implied by the where clauses. In that -case this is ok because as we said, we don't use `FromEnv(Type<...>)` to deduce -other `FromEnv(OtherType<...>)` things, nor do we use `FromEnv(Type: Trait)` to -deduce `FromEnv(OtherType<...>)` things. So in that sense type definitions are -"less recursive" than traits, and we saw in a previous subsection that -it was the combination of asymmetry and recursive trait / impls that led to -unsoundness. As such, the `WellFormed(Type<...>)` predicate does not need -to be co-inductive. - -This asymmetry optimization is useful because in a real Rust program, we have -to check the well-formedness of types very often (e.g. for each type which -appears in the body of a function). diff --git a/src/traits/index.md b/src/traits/index.md deleted file mode 100644 index 5544ce513..000000000 --- a/src/traits/index.md +++ /dev/null @@ -1,64 +0,0 @@ -# Trait solving (new-style) - -> 🚧 This chapter describes "new-style" trait solving. This is still in the -> [process of being implemented][wg]; this chapter serves as a kind of -> in-progress design document. If you would prefer to read about how the -> current trait solver works, check out -> [this other chapter](./resolution.html). 🚧 -> -> By the way, if you would like to help in hacking on the new solver, you will -> find instructions for getting involved in the -> [Traits Working Group tracking issue][wg]! - -[wg]: https://github.com/rust-lang/rust/issues/48416 - -The new-style trait solver is based on the work done in [chalk][chalk]. Chalk -recasts Rust's trait system explicitly in terms of logic programming. It does -this by "lowering" Rust code into a kind of logic program we can then execute -queries against. - -You can read more about chalk itself in the -[Overview of Chalk](./chalk-overview.md) section. - -Trait solving in rustc is based around a few key ideas: - -- [Lowering to logic](./lowering-to-logic.html), which expresses - Rust traits in terms of standard logical terms. - - The [goals and clauses](./goals-and-clauses.html) chapter - describes the precise form of rules we use, and - [lowering rules](./lowering-rules.html) gives the complete set of - lowering rules in a more reference-like form. - - [Lazy normalization](./associated-types.html), which is the - technique we use to accommodate associated types when figuring out - whether types are equal. - - [Region constraints](./regions.html), which are accumulated - during trait solving but mostly ignored. This means that trait - solving effectively ignores the precise regions involved, always – - but we still remember the constraints on them so that those - constraints can be checked by the type checker. -- [Canonical queries](./canonical-queries.html), which allow us - to solve trait problems (like "is `Foo` implemented for the type - `Bar`?") once, and then apply that same result independently in many - different inference contexts. - -> This is not a complete list of topics. See the sidebar for more. - -## Ongoing work -The design of the new-style trait solving currently happens in two places: - -**chalk**. The [chalk][chalk] repository is where we experiment with new ideas -and designs for the trait system. It primarily consists of two parts: -* a unit testing framework - for the correctness and feasibility of the logical rules defining the - new-style trait system. -* the [`chalk_engine`][chalk_engine] crate, which - defines the new-style trait solver used both in the unit testing framework - and in rustc. - -**rustc**. Once we are happy with the logical rules, we proceed to -implementing them in rustc. This mainly happens in -[`librustc_traits`][librustc_traits]. - -[chalk]: https://github.com/rust-lang/chalk -[chalk_engine]: https://github.com/rust-lang/chalk/tree/master/chalk-engine -[librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits diff --git a/src/traits/lowering-rules.md b/src/traits/lowering-rules.md deleted file mode 100644 index c780e7cf5..000000000 --- a/src/traits/lowering-rules.md +++ /dev/null @@ -1,416 +0,0 @@ -# Lowering rules - -This section gives the complete lowering rules for Rust traits into -[program clauses][pc]. It is a kind of reference. These rules -reference the [domain goals][dg] defined in an earlier section. - -[pc]: ./goals-and-clauses.html -[dg]: ./goals-and-clauses.html#domain-goals - -## Notation - -The nonterminal `Pi` is used to mean some generic *parameter*, either a -named lifetime like `'a` or a type parameter like `A`. - -The nonterminal `Ai` is used to mean some generic *argument*, which -might be a lifetime like `'a` or a type like `Vec`. - -When defining the lowering rules, we will give goals and clauses in -the [notation given in this section](./goals-and-clauses.html). -We sometimes insert "macros" like `LowerWhereClause!` into these -definitions; these macros reference other sections within this chapter. - -## Rule names and cross-references - -Each of these lowering rules is given a name, documented with a -comment like so: - - // Rule Foo-Bar-Baz - -The reference implementation of these rules is to be found in -[`chalk/chalk-solve/src/clauses.rs`][chalk_rules]. They are also ported in -rustc in the [`librustc_traits`][librustc_traits] crate. - -[chalk_rules]: https://github.com/rust-lang/chalk/blob/master/chalk-solve/src/clauses.rs -[librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits - -## Lowering where clauses - -When used in a goal position, where clauses can be mapped directly to -the `Holds` variant of [domain goals][dg], as follows: - -- `A0: Foo` maps to `Implemented(A0: Foo)` -- `T: 'r` maps to `Outlives(T, 'r)` -- `'a: 'b` maps to `Outlives('a, 'b)` -- `A0: Foo` is a bit special and expands to two distinct - goals, namely `Implemented(A0: Foo)` and - `ProjectionEq(>::Item = T)` - -In the rules below, we will use `WC` to indicate where clauses that -appear in Rust syntax; we will then use the same `WC` to indicate -where those where clauses appear as goals in the program clauses that -we are producing. In that case, the mapping above is used to convert -from the Rust syntax into goals. - -### Transforming the lowered where clauses - -In addition, in the rules below, we sometimes do some transformations -on the lowered where clauses, as defined here: - -- `FromEnv(WC)` – this indicates that: - - `Implemented(TraitRef)` becomes `FromEnv(TraitRef)` - - other where-clauses are left intact -- `WellFormed(WC)` – this indicates that: - - `Implemented(TraitRef)` becomes `WellFormed(TraitRef)` - - other where-clauses are left intact - -*TODO*: I suspect that we want to alter the outlives relations too, -but Chalk isn't modeling those right now. - -## Lowering traits - -Given a trait definition - -```rust,ignore -trait Trait // P0 == Self -where WC -{ - // trait items -} -``` - -we will produce a number of declarations. This section is focused on -the program clauses for the trait header (i.e., the stuff outside the -`{}`); the [section on trait items](#trait-items) covers the stuff -inside the `{}`. - -### Trait header - -From the trait itself we mostly make "meta" rules that setup the -relationships between different kinds of domain goals. The first such -rule from the trait header creates the mapping between the `FromEnv` -and `Implemented` predicates: - -```text -// Rule Implemented-From-Env -forall { - Implemented(Self: Trait) :- FromEnv(Self: Trait) -} -``` - - - -#### Implied bounds - -The next few clauses have to do with implied bounds (see also -[RFC 2089] and the [implied bounds][implied_bounds] chapter for a more in depth -cover). For each trait, we produce two clauses: - -[RFC 2089]: https://rust-lang.github.io/rfcs/2089-implied-bounds.html -[implied_bounds]: ./implied-bounds.md - -```text -// Rule Implied-Bound-From-Trait -// -// For each where clause WC: -forall { - FromEnv(WC) :- FromEnv(Self: Trait) -} -``` - -This clause says that if we are assuming that the trait holds, then we can also -assume that its where-clauses hold. It's perhaps useful to see an example: - -```rust,ignore -trait Eq: PartialEq { ... } -``` - -In this case, the `PartialEq` supertrait is equivalent to a `where -Self: PartialEq` where clause, in our simplified model. The program -clause above therefore states that if we can prove `FromEnv(T: Eq)` – -e.g., if we are in some function with `T: Eq` in its where clauses – -then we also know that `FromEnv(T: PartialEq)`. Thus the set of things -that follow from the environment are not only the **direct where -clauses** but also things that follow from them. - -The next rule is related; it defines what it means for a trait reference -to be **well-formed**: - -```text -// Rule WellFormed-TraitRef -forall { - WellFormed(Self: Trait) :- Implemented(Self: Trait) && WellFormed(WC) -} -``` - -This `WellFormed` rule states that `T: Trait` is well-formed if (a) -`T: Trait` is implemented and (b) all the where-clauses declared on -`Trait` are well-formed (and hence they are implemented). Remember -that the `WellFormed` predicate is -[coinductive](./goals-and-clauses.html#coinductive); in this -case, it is serving as a kind of "carrier" that allows us to enumerate -all the where clauses that are transitively implied by `T: Trait`. - -An example: - -```rust,ignore -trait Foo: A + Bar { } -trait Bar: B + Foo { } -trait A { } -trait B { } -``` - -Here, the transitive set of implications for `T: Foo` are `T: A`, `T: Bar`, and -`T: B`. And indeed if we were to try to prove `WellFormed(T: Foo)`, we would -have to prove each one of those: - -- `WellFormed(T: Foo)` - - `Implemented(T: Foo)` - - `WellFormed(T: A)` - - `Implemented(T: A)` - - `WellFormed(T: Bar)` - - `Implemented(T: Bar)` - - `WellFormed(T: B)` - - `Implemented(T: Bar)` - - `WellFormed(T: Foo)` -- cycle, true coinductively - -This `WellFormed` predicate is only used when proving that impls are -well-formed – basically, for each impl of some trait ref `TraitRef`, -we must show that `WellFormed(TraitRef)`. This in turn justifies the -implied bounds rules that allow us to extend the set of `FromEnv` -items. - -## Lowering type definitions - -We also want to have some rules which define when a type is well-formed. -For example, given this type: - -```rust,ignore -struct Set where K: Hash { ... } -``` - -then `Set` is well-formed because `i32` implements `Hash`, but -`Set` would not be well-formed. Basically, a type is well-formed -if its parameters verify the where clauses written on the type definition. - -Hence, for every type definition: - -```rust, ignore -struct Type where WC { ... } -``` - -we produce the following rule: - -```text -// Rule WellFormed-Type -forall { - WellFormed(Type) :- WC -} -``` - -Note that we use `struct` for defining a type, but this should be understood -as a general type definition (it could be e.g. a generic `enum`). - -Conversely, we define rules which say that if we assume that a type is -well-formed, we can also assume that its where clauses hold. That is, -we produce the following family of rules: - -```text -// Rule Implied-Bound-From-Type -// -// For each where clause `WC` -forall { - FromEnv(WC) :- FromEnv(Type) -} -``` - -As for the implied bounds RFC, functions will *assume* that their arguments -are well-formed. For example, suppose we have the following bit of code: - -```rust,ignore -trait Hash: Eq { } -struct Set { ... } - -fn foo(collection: Set, x: K, y: K) { - // `x` and `y` can be equalized even if we did not explicitly write - // `where K: Eq` - if x == y { - ... - } -} -``` - -In the `foo` function, we assume that `Set` is well-formed, i.e. we have -`FromEnv(Set)` in our environment. Because of the previous rule, we get - `FromEnv(K: Hash)` without needing an explicit where clause. And because -of the `Hash` trait definition, there also exists a rule which says: - -```text -forall { - FromEnv(K: Eq) :- FromEnv(K: Hash) -} -``` - -which means that we finally get `FromEnv(K: Eq)` and then can compare `x` -and `y` without needing an explicit where clause. - - - -## Lowering trait items - -### Associated type declarations - -Given a trait that declares a (possibly generic) associated type: - -```rust,ignore -trait Trait // P0 == Self -where WC -{ - type AssocType: Bounds where WC1; -} -``` - -We will produce a number of program clauses. The first two define -the rules by which `ProjectionEq` can succeed; these two clauses are discussed -in detail in the [section on associated types](./associated-types.html), -but reproduced here for reference: - -```text -// Rule ProjectionEq-Normalize -// -// ProjectionEq can succeed by normalizing: -forall { - ProjectionEq(>::AssocType = U) :- - Normalize(>::AssocType -> U) -} -``` - -```text -// Rule ProjectionEq-Placeholder -// -// ProjectionEq can succeed through the placeholder associated type, -// see "associated type" chapter for more: -forall { - ProjectionEq( - >::AssocType = - (Trait::AssocType) - ) -} -``` - -The next rule covers implied bounds for the projection. In particular, -the `Bounds` declared on the associated type must have been proven to hold -to show that the impl is well-formed, and hence we can rely on them -elsewhere. - -```text -// Rule Implied-Bound-From-AssocTy -// -// For each `Bound` in `Bounds`: -forall { - FromEnv(>::AssocType>: Bound) :- - FromEnv(Self: Trait) && WC1 -} -``` - -Next, we define the requirements for an instantiation of our associated -type to be well-formed... - -```text -// Rule WellFormed-AssocTy -forall { - WellFormed((Trait::AssocType)) :- - Implemented(Self: Trait) && WC1 -} -``` - -...along with the reverse implications, when we can assume that it is -well-formed. - -```text -// Rule Implied-WC-From-AssocTy -// -// For each where clause WC1: -forall { - FromEnv(WC1) :- FromEnv((Trait::AssocType)) -} -``` - -```text -// Rule Implied-Trait-From-AssocTy -forall { - FromEnv(Self: Trait) :- - FromEnv((Trait::AssocType)) -} -``` - -### Lowering function and constant declarations - -Chalk didn't model functions and constants, but I would eventually like to -treat them exactly like normalization. See [the section on function/constant -values below](#constant-vals) for more details. - -## Lowering impls - -Given an impl of a trait: - -```rust,ignore -impl Trait for A0 -where WC -{ - // zero or more impl items -} -``` - -Let `TraitRef` be the trait reference `A0: Trait`. Then we -will create the following rules: - -```text -// Rule Implemented-From-Impl -forall { - Implemented(TraitRef) :- WC -} -``` - -In addition, we will lower all of the *impl items*. - -## Lowering impl items - -### Associated type values - -Given an impl that contains: - -```rust,ignore -impl Trait for P0 -where WC_impl -{ - type AssocType = T; -} -``` - -and our where clause `WC1` on the trait associated type from above, we -produce the following rule: - -```text -// Rule Normalize-From-Impl -forall { - forall { - Normalize(>::AssocType -> T) :- - Implemented(P0 as Trait) && WC1 - } -} -``` - -Note that `WC_impl` and `WC1` both encode where-clauses that the impl can -rely on. (`WC_impl` is not used here, because it is implied by -`Implemented(P0 as Trait)`.) - - - -### Function and constant values - -Chalk didn't model functions and constants, but I would eventually -like to treat them exactly like normalization. This presumably -involves adding a new kind of parameter (constant), and then having a -`NormalizeValue` domain goal. This is *to be written* because the -details are a bit up in the air. diff --git a/src/traits/lowering-to-logic.md b/src/traits/lowering-to-logic.md deleted file mode 100644 index e1a6c1361..000000000 --- a/src/traits/lowering-to-logic.md +++ /dev/null @@ -1,185 +0,0 @@ -# Lowering to logic - -The key observation here is that the Rust trait system is basically a -kind of logic, and it can be mapped onto standard logical inference -rules. We can then look for solutions to those inference rules in a -very similar fashion to how e.g. a [Prolog] solver works. It turns out -that we can't *quite* use Prolog rules (also called Horn clauses) but -rather need a somewhat more expressive variant. - -[Prolog]: https://en.wikipedia.org/wiki/Prolog - -## Rust traits and logic - -One of the first observations is that the Rust trait system is -basically a kind of logic. As such, we can map our struct, trait, and -impl declarations into logical inference rules. For the most part, -these are basically Horn clauses, though we'll see that to capture the -full richness of Rust – and in particular to support generic -programming – we have to go a bit further than standard Horn clauses. - -To see how this mapping works, let's start with an example. Imagine -we declare a trait and a few impls, like so: - -```rust -trait Clone { } -impl Clone for usize { } -impl Clone for Vec where T: Clone { } -``` - -We could map these declarations to some Horn clauses, written in a -Prolog-like notation, as follows: - -```text -Clone(usize). -Clone(Vec) :- Clone(?T). - -// The notation `A :- B` means "A is true if B is true". -// Or, put another way, B implies A. -``` - -In Prolog terms, we might say that `Clone(Foo)` – where `Foo` is some -Rust type – is a *predicate* that represents the idea that the type -`Foo` implements `Clone`. These rules are **program clauses**; they -state the conditions under which that predicate can be proven (i.e., -considered true). So the first rule just says "Clone is implemented -for `usize`". The next rule says "for any type `?T`, Clone is -implemented for `Vec` if clone is implemented for `?T`". So -e.g. if we wanted to prove that `Clone(Vec>)`, we would do -so by applying the rules recursively: - -- `Clone(Vec>)` is provable if: - - `Clone(Vec)` is provable if: - - `Clone(usize)` is provable. (Which it is, so we're all good.) - -But now suppose we tried to prove that `Clone(Vec)`. This would -fail (after all, I didn't give an impl of `Clone` for `Bar`): - -- `Clone(Vec)` is provable if: - - `Clone(Bar)` is provable. (But it is not, as there are no applicable rules.) - -We can easily extend the example above to cover generic traits with -more than one input type. So imagine the `Eq` trait, which declares -that `Self` is equatable with a value of type `T`: - -```rust,ignore -trait Eq { ... } -impl Eq for usize { } -impl> Eq> for Vec { } -``` - -That could be mapped as follows: - -```text -Eq(usize, usize). -Eq(Vec, Vec) :- Eq(?T, ?U). -``` - -So far so good. - -## Type-checking normal functions - -OK, now that we have defined some logical rules that are able to -express when traits are implemented and to handle associated types, -let's turn our focus a bit towards **type-checking**. Type-checking is -interesting because it is what gives us the goals that we need to -prove. That is, everything we've seen so far has been about how we -derive the rules by which we can prove goals from the traits and impls -in the program; but we are also interested in how to derive the goals -that we need to prove, and those come from type-checking. - -Consider type-checking the function `foo()` here: - -```rust,ignore -fn foo() { bar::() } -fn bar>() { } -``` - -This function is very simple, of course: all it does is to call -`bar::()`. Now, looking at the definition of `bar()`, we can see -that it has one where-clause `U: Eq`. So, that means that `foo()` will -have to prove that `usize: Eq` in order to show that it can call `bar()` -with `usize` as the type argument. - -If we wanted, we could write a Prolog predicate that defines the -conditions under which `bar()` can be called. We'll say that those -conditions are called being "well-formed": - -```text -barWellFormed(?U) :- Eq(?U, ?U). -``` - -Then we can say that `foo()` type-checks if the reference to -`bar::` (that is, `bar()` applied to the type `usize`) is -well-formed: - -```text -fooTypeChecks :- barWellFormed(usize). -``` - -If we try to prove the goal `fooTypeChecks`, it will succeed: - -- `fooTypeChecks` is provable if: - - `barWellFormed(usize)`, which is provable if: - - `Eq(usize, usize)`, which is provable because of an impl. - -Ok, so far so good. Let's move on to type-checking a more complex function. - -## Type-checking generic functions: beyond Horn clauses - -In the last section, we used standard Prolog horn-clauses (augmented with Rust's -notion of type equality) to type-check some simple Rust functions. But that only -works when we are type-checking non-generic functions. If we want to type-check -a generic function, it turns out we need a stronger notion of goal than what Prolog -can provide. To see what I'm talking about, let's revamp our previous -example to make `foo` generic: - -```rust,ignore -fn foo>() { bar::() } -fn bar>() { } -``` - -To type-check the body of `foo`, we need to be able to hold the type -`T` "abstract". That is, we need to check that the body of `foo` is -type-safe *for all types `T`*, not just for some specific type. We might express -this like so: - -```text -fooTypeChecks :- - // for all types T... - forall { - // ...if we assume that Eq(T, T) is provable... - if (Eq(T, T)) { - // ...then we can prove that `barWellFormed(T)` holds. - barWellFormed(T) - } - }. -``` - -This notation I'm using here is the notation I've been using in my -prototype implementation; it's similar to standard mathematical -notation but a bit Rustified. Anyway, the problem is that standard -Horn clauses don't allow universal quantification (`forall`) or -implication (`if`) in goals (though many Prolog engines do support -them, as an extension). For this reason, we need to accept something -called "first-order hereditary harrop" (FOHH) clauses – this long -name basically means "standard Horn clauses with `forall` and `if` in -the body". But it's nice to know the proper name, because there is a -lot of work describing how to efficiently handle FOHH clauses; see for -example Gopalan Nadathur's excellent -["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] -in [the bibliography]. - -[the bibliography]: ./bibliography.html -[pphhf]: ./bibliography.html#pphhf - -It turns out that supporting FOHH is not really all that hard. And -once we are able to do that, we can easily describe the type-checking -rule for generic functions like `foo` in our logic. - -## Source - -This page is a lightly adapted version of a -[blog post by Nicholas Matsakis][lrtl]. - -[lrtl]: http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/ diff --git a/src/traits/resolution.md b/src/traits/resolution.md index 2ba451677..7f73bfe4f 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -6,7 +6,7 @@ some non-obvious things. **Note:** This chapter (and its subchapters) describe how the trait solver **currently** works. However, we are in the process of designing a new trait solver. If you'd prefer to read about *that*, -see [*this* traits chapter](./index.html). +see [*this* subchapter](./chalk.html). ## Major concepts diff --git a/src/traits/slg.md b/src/traits/slg.md deleted file mode 100644 index 74ec89fa0..000000000 --- a/src/traits/slg.md +++ /dev/null @@ -1,302 +0,0 @@ -# The On-Demand SLG solver - -Given a set of program clauses (provided by our [lowering rules][lowering]) -and a query, we need to return the result of the query and the value of any -type variables we can determine. This is the job of the solver. - -For example, `exists { Vec: FromIterator }` has one solution, so -its result is `Unique; substitution [?T := u32]`. A solution also comes with -a set of region constraints, which we'll ignore in this introduction. - -[lowering]: ./lowering-rules.html - -## Goals of the Solver - -### On demand - -There are often many, or even infinitely many, solutions to a query. For -example, say we want to prove that `exists { Vec: Debug }` for _some_ -type `?T`. Our solver should be capable of yielding one answer at a time, say -`?T = u32`, then `?T = i32`, and so on, rather than iterating over every type -in the type system. If we need more answers, we can request more until we are -done. This is similar to how Prolog works. - -*See also: [The traditional, interactive Prolog query][pq]* - -[pq]: ./canonical-queries.html#the-traditional-interactive-prolog-query - -### Breadth-first - -`Vec: Debug` is true if `?T: Debug`. This leads to a cycle: `[Vec, -Vec>, Vec>>]`, and so on all implement `Debug`. Our -solver ought to be breadth first and consider answers like `[Vec: Debug, -Vec: Debug, ...]` before it recurses, or we may never find the answer -we're looking for. - -### Cachable - -To speed up compilation, we need to cache results, including partial results -left over from past solver queries. - -## Description of how it works - -The basis of the solver is the [`Forest`] type. A *forest* stores a -collection of *tables* as well as a *stack*. Each *table* represents -the stored results of a particular query that is being performed, as -well as the various *strands*, which are basically suspended -computations that may be used to find more answers. Tables are -interdependent: solving one query may require solving others. - -[`Forest`]: https://rust-lang.github.io/chalk/chalk_engine/forest/struct.Forest.html - -### Walkthrough - -Perhaps the easiest way to explain how the solver works is to walk -through an example. Let's imagine that we have the following program: - -```rust,ignore -trait Debug { } - -struct u32 { } -impl Debug for u32 { } - -struct Rc { } -impl Debug for Rc { } - -struct Vec { } -impl Debug for Vec { } -``` - -Now imagine that we want to find answers for the query `exists { Rc: -Debug }`. The first step would be to u-canonicalize this query; this is the -act of giving canonical names to all the unbound inference variables based on -the order of their left-most appearance, as well as canonicalizing the -universes of any universally bound names (e.g., the `T` in `forall { ... -}`). In this case, there are no universally bound names, but the canonical -form Q of the query might look something like: - -```text -Rc: Debug -``` - -where `?0` is a variable in the root universe U0. We would then go and -look for a table with this canonical query as the key: since the forest is -empty, this lookup will fail, and we will create a new table T0, -corresponding to the u-canonical goal Q. - -**Ignoring negative reasoning and regions.** To start, we'll ignore -the possibility of negative goals like `not { Foo }`. We'll phase them -in later, as they bring several complications. - -**Creating a table.** When we first create a table, we also initialize -it with a set of *initial strands*. A "strand" is kind of like a -"thread" for the solver: it contains a particular way to produce an -answer. The initial set of strands for a goal like `Rc: Debug` -(i.e., a "domain goal") is determined by looking for *clauses* in the -environment. In Rust, these clauses derive from impls, but also from -where-clauses that are in scope. In the case of our example, there -would be three clauses, each coming from the program. Using a -Prolog-like notation, these look like: - -```text -(u32: Debug). -(Rc: Debug) :- (T: Debug). -(Vec: Debug) :- (T: Debug). -``` - -To create our initial strands, then, we will try to apply each of -these clauses to our goal of `Rc: Debug`. The first and third -clauses are inapplicable because `u32` and `Vec` cannot be unified -with `Rc`. The second clause, however, will work. - -**What is a strand?** Let's talk a bit more about what a strand *is*. In the code, a strand -is the combination of an inference table, an _X-clause_, and (possibly) -a selected subgoal from that X-clause. But what is an X-clause -([`ExClause`], in the code)? An X-clause pulls together a few things: - -- The current state of the goal we are trying to prove; -- A set of subgoals that have yet to be proven; -- There are also a few things we're ignoring for now: - - delayed literals, region constraints - -The general form of an X-clause is written much like a Prolog clause, -but with somewhat different semantics. Since we're ignoring delayed -literals and region constraints, an X-clause just looks like this: - -```text -G :- L -``` - -where G is a goal and L is a set of subgoals that must be proven. -(The L stands for *literal* -- when we address negative reasoning, a -literal will be either a positive or negative subgoal.) The idea is -that if we are able to prove L then the goal G can be considered true. - -In the case of our example, we would wind up creating one strand, with -an X-clause like so: - -```text -(Rc: Debug) :- (?T: Debug) -``` - -Here, the `?T` refers to one of the inference variables created in the -inference table that accompanies the strand. (I'll use named variables -to refer to inference variables, and numbered variables like `?0` to -refer to variables in a canonicalized goal; in the code, however, they -are both represented with an index.) - -For each strand, we also optionally store a *selected subgoal*. This -is the subgoal after the turnstile (`:-`) that we are currently trying -to prove in this strand. Initially, when a strand is first created, -there is no selected subgoal. - -[`ExClause`]: https://rust-lang.github.io/chalk/chalk_engine/struct.ExClause.html - -**Activating a strand.** Now that we have created the table T0 and -initialized it with strands, we have to actually try and produce an answer. -We do this by invoking the [`ensure_root_answer`] operation on the table: -specifically, we say `ensure_root_answer(T0, A0)`, meaning "ensure that there -is a 0th answer A0 to query T0". - -Remember that tables store not only strands, but also a vector of cached -answers. The first thing that [`ensure_root_answer`] does is to check whether -answer A0 is in this vector. If so, we can just return immediately. In this -case, the vector will be empty, and hence that does not apply (this becomes -important for cyclic checks later on). - -When there is no cached answer, [`ensure_root_answer`] will try to produce one. -It does this by selecting a strand from the set of active strands -- the -strands are stored in a `VecDeque` and hence processed in a round-robin -fashion. Right now, we have only one strand, storing the following X-clause -with no selected subgoal: - -```text -(Rc: Debug) :- (?T: Debug) -``` - -When we activate the strand, we see that we have no selected subgoal, -and so we first pick one of the subgoals to process. Here, there is only -one (`?T: Debug`), so that becomes the selected subgoal, changing -the state of the strand to: - -```text -(Rc: Debug) :- selected(?T: Debug, A0) -``` - -Here, we write `selected(L, An)` to indicate that (a) the literal `L` -is the selected subgoal and (b) which answer `An` we are looking for. We -start out looking for `A0`. - -[`ensure_root_answer`]: https://rust-lang.github.io/chalk/chalk_engine/forest/struct.Forest.html#method.ensure_root_answer - -**Processing the selected subgoal.** Next, we have to try and find an -answer to this selected goal. To do that, we will u-canonicalize it -and try to find an associated table. In this case, the u-canonical -form of the subgoal is `?0: Debug`: we don't have a table yet for -that, so we can create a new one, T1. As before, we'll initialize T1 -with strands. In this case, there will be three strands, because all -the program clauses are potentially applicable. Those three strands -will be: - -- `(u32: Debug) :-`, derived from the program clause `(u32: Debug).`. - - Note: This strand has no subgoals. -- `(Vec: Debug) :- (?U: Debug)`, derived from the `Vec` impl. -- `(Rc: Debug) :- (?U: Debug)`, derived from the `Rc` impl. - -We can thus summarize the state of the whole forest at this point as -follows: - -```text -Table T0 [Rc: Debug] - Strands: - (Rc: Debug) :- selected(?T: Debug, A0) - -Table T1 [?0: Debug] - Strands: - (u32: Debug) :- - (Vec: Debug) :- (?U: Debug) - (Rc: Debug) :- (?V: Debug) -``` - -**Delegation between tables.** Now that the active strand from T0 has -created the table T1, it can try to extract an answer. It does this -via that same `ensure_answer` operation we saw before. In this case, -the strand would invoke `ensure_answer(T1, A0)`, since we will start -with the first answer. This will cause T1 to activate its first -strand, `u32: Debug :-`. - -This strand is somewhat special: it has no subgoals at all. This means -that the goal is proven. We can therefore add `u32: Debug` to the set -of *answers* for our table, calling it answer A0 (it is the first -answer). The strand is then removed from the list of strands. - -The state of table T1 is therefore: - -```text -Table T1 [?0: Debug] - Answers: - A0 = [?0 = u32] - Strand: - (Vec: Debug) :- (?U: Debug) - (Rc: Debug) :- (?V: Debug) -``` - -Note that I am writing out the answer A0 as a substitution that can be -applied to the table goal; actually, in the code, the goals for each -X-clause are also represented as substitutions, but in this exposition -I've chosen to write them as full goals, following [NFTD]. - -[NFTD]: ./bibliography.html#slg - -Since we now have an answer, `ensure_answer(T1, A0)` will return `Ok` -to the table T0, indicating that answer A0 is available. T0 now has -the job of incorporating that result into its active strand. It does -this in two ways. First, it creates a new strand that is looking for -the next possible answer of T1. Next, it incorpoates the answer from -A0 and removes the subgoal. The resulting state of table T0 is: - -```text -Table T0 [Rc: Debug] - Strands: - (Rc: Debug) :- selected(?T: Debug, A1) - (Rc: Debug) :- -``` - -We then immediately activate the strand that incorporated the answer -(the `Rc: Debug` one). In this case, that strand has no further -subgoals, so it becomes an answer to the table T0. This answer can -then be returned up to our caller, and the whole forest goes quiescent -at this point (remember, we only do enough work to generate *one* -answer). The ending state of the forest at this point will be: - -```text -Table T0 [Rc: Debug] - Answer: - A0 = [?0 = u32] - Strands: - (Rc: Debug) :- selected(?T: Debug, A1) - -Table T1 [?0: Debug] - Answers: - A0 = [?0 = u32] - Strand: - (Vec: Debug) :- (?U: Debug) - (Rc: Debug) :- (?V: Debug) -``` - -Here you can see how the forest captures both the answers we have -created thus far *and* the strands that will let us try to produce -more answers later on. - -## See also - -- [chalk_solve README][readme], which contains links to papers used and - acronyms referenced in the code -- This section is a lightly adapted version of the blog post [An on-demand - SLG solver for chalk][slg-blog] -- [Negative Reasoning in Chalk][negative-reasoning-blog] explains the need - for negative reasoning, but not how the SLG solver does it - -[readme]: https://github.com/rust-lang/chalk/blob/239e4ae4e69b2785b5f99e0f2b41fc16b0b4e65e/chalk-engine/src/README.md -[slg-blog]: http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/ -[negative-reasoning-blog]: https://aturon.github.io/blog/2017/04/24/negative-chalk/ diff --git a/src/traits/wf.md b/src/traits/wf.md deleted file mode 100644 index aa17f8c2c..000000000 --- a/src/traits/wf.md +++ /dev/null @@ -1,469 +0,0 @@ -# Well-formedness checking - -WF checking has the job of checking that the various declarations in a Rust -program are well-formed. This is the basis for implied bounds, and partly for -that reason, this checking can be surprisingly subtle! For example, we -have to be sure that each impl proves the WF conditions declared on -the trait. - -For each declaration in a Rust program, we will generate a logical goal and try -to prove it using the lowered rules we described in the -[lowering rules](./lowering-rules.md) chapter. If we are able to prove it, we -say that the construct is well-formed. If not, we report an error to the user. - -Well-formedness checking happens in the [`chalk/chalk-solve/src/wf.rs`][wf] -module in chalk. After you have read this chapter, you may find useful to see -an extended set of examples in the [`chalk/tests/test/wf_lowering.rs`][wf_test] submodule. - -The new-style WF checking has not been implemented in rustc yet. - -[wf]: https://github.com/rust-lang/chalk/blob/master/chalk-solve/src/wf.rs -[wf_test]: https://github.com/rust-lang/chalk/blob/master/tests/test/wf_lowering.rs - -We give here a complete reference of the generated goals for each Rust -declaration. - -In addition to the notations introduced in the chapter about -lowering rules, we'll introduce another notation: when checking WF of a -declaration, we'll often have to prove that all types that appear are -well-formed, except type parameters that we always assume to be WF. Hence, -we'll use the following notation: for a type `SomeType<...>`, we define -`InputTypes(SomeType<...>)` to be the set of all non-parameter types appearing -in `SomeType<...>`, including `SomeType<...>` itself. - -Examples: -* `InputTypes((u32, f32)) = [u32, f32, (u32, f32)]` -* `InputTypes(Box) = [Box]` (assuming that `T` is a type parameter) -* `InputTypes(Box>) = [Box, Box>]` - -We also extend the `InputTypes` notation to where clauses in the natural way. -So, for example `InputTypes(A0: Trait)` is the union of -`InputTypes(A0)`, `InputTypes(A1)`, ..., `InputTypes(An)`. - -# Type definitions - -Given a general type definition: -```rust,ignore -struct Type where WC_type { - field1: A1, - ... - fieldn: An, -} -``` - -we generate the following goal, which represents its well-formedness condition: -```text -forall { - if (FromEnv(WC_type)) { - WellFormed(InputTypes(WC_type)) && - WellFormed(InputTypes(A1)) && - ... - WellFormed(InputTypes(An)) - } -} -``` - -which in English states: assuming that the where clauses defined on the type -hold, prove that every type appearing in the type definition is well-formed. - -Some examples: -```rust,ignore -struct OnlyClone where T: Clone { - clonable: T, -} -// The only types appearing are type parameters: we have nothing to check, -// the type definition is well-formed. -``` - -```rust,ignore -struct Foo where T: Clone { - foo: OnlyClone, -} -// The only non-parameter type which appears in this definition is -// `OnlyClone`. The generated goal is the following: -// ``` -// forall { -// if (FromEnv(T: Clone)) { -// WellFormed(OnlyClone) -// } -// } -// ``` -// which is provable. -``` - -```rust,ignore -struct Bar where ::Item: Debug { - bar: i32, -} -// The only non-parameter types which appear in this definition are -// `::Item` and `i32`. The generated goal is the following: -// ``` -// forall { -// if (FromEnv(::Item: Debug)) { -// WellFormed(::Item) && -// WellFormed(i32) -// } -// } -// ``` -// which is not provable since `WellFormed(::Item)` requires -// proving `Implemented(T: Iterator)`, and we are unable to prove that for an -// unknown `T`. -// -// Hence, this type definition is considered illegal. An additional -// `where T: Iterator` would make it legal. -``` - -# Trait definitions - -Given a general trait definition: -```rust,ignore -trait Trait where WC_trait { - type Assoc: Bounds_assoc where WC_assoc; -} -``` - -we generate the following goal: -```text -forall { - if (FromEnv(WC_trait)) { - WellFormed(InputTypes(WC_trait)) && - - forall { - if (FromEnv(WC_assoc)) { - WellFormed(InputTypes(Bounds_assoc)) && - WellFormed(InputTypes(WC_assoc)) - } - } - } -} -``` - -There is not much to verify in a trait definition. We just want -to prove that the types appearing in the trait definition are well-formed, -under the assumption that the different where clauses hold. - -Some examples: -```rust,ignore -trait Foo where T: Iterator, ::Item: Debug { - ... -} -// The only non-parameter type which appears in this definition is -// `::Item`. The generated goal is the following: -// ``` -// forall { -// if (FromEnv(T: Iterator), FromEnv(::Item: Debug)) { -// WellFormed(::Item) -// } -// } -// ``` -// which is provable thanks to the `FromEnv(T: Iterator)` assumption. -``` - -```rust,ignore -trait Bar { - type Assoc: From<::Item>; -} -// The only non-parameter type which appears in this definition is -// `::Item`. The generated goal is the following: -// ``` -// forall { -// WellFormed(::Item) -// } -// ``` -// which is not provable, hence the trait definition is considered illegal. -``` - -```rust,ignore -trait Baz { - type Assoc: From<::Item> where T: Iterator; -} -// The generated goal is now: -// ``` -// forall { -// if (FromEnv(T: Iterator)) { -// WellFormed(::Item) -// } -// } -// ``` -// which is now provable. -``` - -# Impls - -Now we give ourselves a general impl for the trait defined above: -```rust,ignore -impl Trait for SomeType where WC_impl { - type Assoc = SomeValue where WC_assoc; -} -``` - -Note that here, `WC_assoc` are the same where clauses as those defined on the -associated type definition in the trait declaration, *except* that type -parameters from the trait are substituted with values provided by the impl -(see example below). You cannot add new where clauses. You may omit to write -the where clauses if you want to emphasize the fact that you are actually not -relying on them. - -Some examples to illustrate that: -```rust,ignore -trait Foo { - type Assoc where T: Clone; -} - -struct OnlyClone { ... } - -impl Foo> for () { - // We substitute type parameters from the trait by the ones provided - // by the impl, that is instead of having a `T: Clone` where clause, - // we have an `Option: Clone` one. - type Assoc = OnlyClone> where Option: Clone; -} - -impl Foo for i32 { - // I'm not using the `T: Clone` where clause from the trait, so I can - // omit it. - type Assoc = u32; -} - -impl Foo for f32 { - type Assoc = OnlyClone> where Option: Clone; - // ^^^^^^^^^^^^^^^^^^^^^^ - // this where clause does not exist - // on the original trait decl: illegal -} -``` - -> So in Rust, where clauses on associated types work *exactly* like where -> clauses on trait methods: in an impl, we must substitute the parameters from -> the traits with values provided by the impl, we may omit them if we don't -> need them, but we cannot add new where clauses. - -Now let's see the generated goal for this general impl: -```text -forall { - // Well-formedness of types appearing in the impl - if (FromEnv(WC_impl), FromEnv(InputTypes(SomeType: Trait))) { - WellFormed(InputTypes(WC_impl)) && - - forall { - if (FromEnv(WC_assoc)) { - WellFormed(InputTypes(SomeValue)) - } - } - } - - // Implied bounds checking - if (FromEnv(WC_impl), FromEnv(InputTypes(SomeType: Trait))) { - WellFormed(SomeType: Trait) && - - forall { - if (FromEnv(WC_assoc)) { - WellFormed(SomeValue: Bounds_assoc) - } - } - } -} -``` - -Here is the most complex goal. As always, first, assuming that -the various where clauses hold, we prove that every type appearing in the impl -is well-formed, ***except*** types appearing in the impl header -`SomeType: Trait`. Instead, we *assume* that those types are -well-formed -(hence the `if (FromEnv(InputTypes(SomeType: Trait)))` -conditions). This is -part of the implied bounds proposal, so that we can rely on the bounds -written on the definition of e.g. the `SomeType` type (and that we don't -need to repeat those bounds). -> Note that we don't need to check well-formedness of types appearing in -> `WC_assoc` because we already did that in the trait decl (they are just -> repeated with some substitutions of values which we already assume to be -> well-formed) - -Next, still assuming that the where clauses on the impl `WC_impl` hold and that -the input types of `SomeType` are well-formed, we prove that -`WellFormed(SomeType: Trait)` hold. That is, we want to prove -that `SomeType` verify all the where clauses that might transitively -be required by the `Trait` definition (see -[this subsection](./implied-bounds.md#co-inductiveness-of-wellformed)). - -Lastly, assuming in addition that the where clauses on the associated type -`WC_assoc` hold, -we prove that `WellFormed(SomeValue: Bounds_assoc)` hold. Again, we are -not only proving `Implemented(SomeValue: Bounds_assoc)`, but also -all the facts that might transitively come from `Bounds_assoc`. We must do this -because we allow the use of implied bounds on associated types: if we have -`FromEnv(SomeType: Trait)` in our environment, the lowering rules -chapter indicates that we are able to deduce -`FromEnv(::Assoc: Bounds_assoc)` without knowing what the -precise value of `::Assoc` is. - -Some examples for the generated goal: -```rust,ignore -// Trait Program Clauses - -// These are program clauses that come from the trait definitions below -// and that the trait solver can use for its reasonings. I'm just restating -// them here so that we have them in mind. - -trait Copy { } -// This is a program clause that comes from the trait definition above -// and that the trait solver can use for its reasonings. I'm just restating -// it here (and also the few other ones coming just after) so that we have -// them in mind. -// `WellFormed(Self: Copy) :- Implemented(Self: Copy).` - -trait Partial where Self: Copy { } -// ``` -// WellFormed(Self: Partial) :- -// Implemented(Self: Partial) && -// WellFormed(Self: Copy). -// ``` - -trait Complete where Self: Partial { } -// ``` -// WellFormed(Self: Complete) :- -// Implemented(Self: Complete) && -// WellFormed(Self: Partial). -// ``` - -// Impl WF Goals - -impl Partial for T where T: Complete { } -// The generated goal is: -// ``` -// forall { -// if (FromEnv(T: Complete)) { -// WellFormed(T: Partial) -// } -// } -// ``` -// Then proving `WellFormed(T: Partial)` amounts to proving -// `Implemented(T: Partial)` and `Implemented(T: Copy)`. -// Both those facts can be deduced from the `FromEnv(T: Complete)` in our -// environment: this impl is legal. - -impl Complete for T { } -// The generated goal is: -// ``` -// forall { -// WellFormed(T: Complete) -// } -// ``` -// Then proving `WellFormed(T: Complete)` amounts to proving -// `Implemented(T: Complete)`, `Implemented(T: Partial)` and -// `Implemented(T: Copy)`. -// -// `Implemented(T: Complete)` can be proved thanks to the -// `impl Complete for T` blanket impl. -// -// `Implemented(T: Partial)` can be proved thanks to the -// `impl Partial for T where T: Complete` impl and because we know -// `T: Complete` holds. - -// However, `Implemented(T: Copy)` cannot be proved: the impl is illegal. -// An additional `where T: Copy` bound would be sufficient to make that impl -// legal. -``` - -```rust,ignore -trait Bar { } - -impl Bar for T where ::Item: Bar { } -// We have a non-parameter type appearing in the where clauses: -// `::Item`. The generated goal is: -// ``` -// forall { -// if (FromEnv(::Item: Bar)) { -// WellFormed(T: Bar) && -// WellFormed(::Item: Bar) -// } -// } -// ``` -// And `WellFormed(::Item: Bar)` is not provable: we'd need -// an additional `where T: Iterator` for example. -``` - -```rust,ignore -trait Foo { } - -trait Bar { - type Item: Foo; -} - -struct Stuff { } - -impl Bar for Stuff where T: Foo { - type Item = T; -} -// The generated goal is: -// ``` -// forall { -// if (FromEnv(T: Foo)) { -// WellFormed(T: Foo). -// } -// } -// ``` -// which is provable. -``` - -```rust,ignore -trait Debug { ... } -// `WellFormed(Self: Debug) :- Implemented(Self: Debug).` - -struct Box { ... } -impl Debug for Box where T: Debug { ... } - -trait PointerFamily { - type Pointer: Debug where T: Debug; -} -// `WellFormed(Self: PointerFamily) :- Implemented(Self: PointerFamily).` - -struct BoxFamily; - -impl PointerFamily for BoxFamily { - type Pointer = Box where T: Debug; -} -// The generated goal is: -// ``` -// forall { -// WellFormed(BoxFamily: PointerFamily) && -// -// if (FromEnv(T: Debug)) { -// WellFormed(Box: Debug) && -// WellFormed(Box) -// } -// } -// ``` -// `WellFormed(BoxFamily: PointerFamily)` amounts to proving -// `Implemented(BoxFamily: PointerFamily)`, which is ok thanks to our impl. -// -// `WellFormed(Box)` is always true (there are no where clauses on the -// `Box` type definition). -// -// Moreover, we have an `impl Debug for Box`, hence -// we can prove `WellFormed(Box: Debug)` and the impl is indeed legal. -``` - -```rust,ignore -trait Foo { - type Assoc; -} - -struct OnlyClone { ... } - -impl Foo for i32 { - type Assoc = OnlyClone; -} -// The generated goal is: -// ``` -// forall { -// WellFormed(i32: Foo) && -// WellFormed(OnlyClone) -// } -// ``` -// however `WellFormed(OnlyClone)` is not provable because it requires -// `Implemented(T: Clone)`. It would be tempting to just add a `where T: Clone` -// bound inside the `impl Foo for i32` block, however we saw that it was -// illegal to add where clauses that didn't come from the trait definition. -``` From cbbe9b423f3038a0bb9002bfdfaa7ae3c1ed0e27 Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Sun, 19 Apr 2020 23:06:05 +0800 Subject: [PATCH 0957/1812] Fix links and CI error. --- src/appendix/code-index.md | 6 +++--- src/appendix/glossary.md | 6 +++--- src/traits/chalk.md | 3 ++- src/traits/lowering-module.md | 4 ++-- 4 files changed, 10 insertions(+), 9 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index a4b18ecc0..327709c31 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -27,7 +27,7 @@ Item | Kind | Short description | Chapter | `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html) `rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/librustc_ast/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc_middle/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html) -`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses], [Trait Solving: Lowering impls] | [src/librustc_middle/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html) +`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Chalk Book: Goals and Clauses], [Chalk Book: Lowering impls] | [src/librustc_middle/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html) `TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc_middle/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html) @@ -42,5 +42,5 @@ Item | Kind | Short description | Chapter | [Macro expansion]: ../macro-expansion.html [Name resolution]: ../name-resolution.html [Parameter Environment]: ../param_env.html -[Trait Solving: Goals and Clauses]: ../traits/goals-and-clauses.html#domain-goals -[Trait Solving: Lowering impls]: ../traits/lowering-rules.html#lowering-impls +[Chalk Book: Goals and Clauses]: https://rust-lang.github.io/chalk/book/clauses/goals_and_clauses.html#domain-goals +[Chalk Book: Lowering impls]: https://rust-lang.github.io/chalk/book/clauses/lowering_rules.html#lowering-impls diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 5dc8f3801..ded31485b 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -49,7 +49,7 @@ memoization
| The process of storing the results o MIR
| The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.html)) miri
| An interpreter for MIR used for constant evaluation. ([see more](../miri.html)) monomorphization
| The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). -normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/associated-types.html#normalize). +normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](https://rust-lang.github.io/chalk/book/clauses/type_equality.html#normalize). newtype
| A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. NLL
| Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId
| An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). @@ -57,7 +57,7 @@ obligation
| Something that must be proven by the placeholder
| **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. point
| Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. polymorphize
| An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) -projection
| A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref). +projection
| A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](https://rust-lang.github.io/chalk/book/clauses/goals_and_clauses.html#trait-ref). promoted constants
| Constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. provider
| The function that executes a query. ([see more](../query.html)) quantified
| In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified). @@ -74,7 +74,7 @@ tcx
| The "typing context", main data stru 'tcx
| The lifetime of the allocation arena. ([see more](../ty.html)) token
| The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). [TLS]
| Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. -trait reference
| The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) +trait reference
| The name of a trait along with a suitable set of input type/lifetimes. ([see more](https://rust-lang.github.io/chalk/book/clauses/goals_and_clauses.html#trait-ref)) trans
| The code to translate MIR into LLVM IR. Renamed to codegen. ty
| The internal representation of a type. ([see more](../ty.html)) UFCS
| Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) diff --git a/src/traits/chalk.md b/src/traits/chalk.md index dcb0a244f..dceb04354 100644 --- a/src/traits/chalk.md +++ b/src/traits/chalk.md @@ -37,7 +37,8 @@ and designs for the trait system. **rustc**. Once we are happy with the logical rules, we proceed to implementing them in rustc. This mainly happens in -[`librustc_traits`][librustc_traits]. We map our struct, trait, and impl declarations into logical inference rules in the [lowering module in rustc](./lowering-module.md). +[`librustc_traits`][librustc_traits]. We map our struct, trait, and impl declarations +into logical inference rules in the [lowering module in rustc](./lowering-module.md). [chalk]: https://github.com/rust-lang/chalk [librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md index 3c5bd7be5..0efc82c3e 100644 --- a/src/traits/lowering-module.md +++ b/src/traits/lowering-module.md @@ -1,8 +1,8 @@ # The lowering module in rustc The program clauses described in the -[lowering rules](./lowering-rules.html) section are actually -created in the [`rustc_traits::lowering`][lowering] module. +[lowering rules chapter in Chalk Book](https://rust-lang.github.io/chalk/book/clauses/lowering_rules.html) +are actually created in the [`rustc_traits::lowering`][lowering] module. [lowering]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_traits/lowering/ From d79227e4538af2c84f21feff66f48f8ac6ddc3c3 Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Mon, 20 Apr 2020 22:24:38 +0800 Subject: [PATCH 0958/1812] Address review comments. --- src/SUMMARY.md | 6 +- src/appendix/code-index.md | 5 +- src/appendix/glossary.md | 6 +- src/traits/canonical-queries.md | 252 +++++++++++++++++++++++++++++ src/traits/chalk.md | 23 ++- src/traits/goals-and-clauses.md | 270 ++++++++++++++++++++++++++++++++ src/traits/lowering-module.md | 55 ------- src/traits/lowering-to-logic.md | 185 ++++++++++++++++++++++ src/traits/regions.md | 9 -- 9 files changed, 726 insertions(+), 85 deletions(-) create mode 100644 src/traits/canonical-queries.md create mode 100644 src/traits/goals-and-clauses.md create mode 100644 src/traits/lowering-to-logic.md delete mode 100644 src/traits/regions.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 38634e26a..ee4d7e3f2 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -77,8 +77,10 @@ - [Caching subtleties](./traits/caching.md) - [Specialization](./traits/specialization.md) - [Chalk-based trait solving](./traits/chalk.md) - - [Region constraints](./traits/regions.md) - - [Chalk-oriented lowering module in rustc](./traits/lowering-module.md) + - [Lowering to logic](./traits/lowering-to-logic.md) + - [Goals and clauses](./traits/goals-and-clauses.md) + - [Canonical queries](./traits/canonical-queries.md) + - [Lowering module in rustc](./traits/lowering-module.md) - [Type checking](./type-checking.md) - [Method Lookup](./method-lookup.md) - [Variance](./variance.md) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 327709c31..76f4609cc 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -27,7 +27,7 @@ Item | Kind | Short description | Chapter | `StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html) `rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/librustc_ast/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc_middle/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html) -`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Chalk Book: Goals and Clauses], [Chalk Book: Lowering impls] | [src/librustc_middle/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html) +`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses] | [src/librustc_middle/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html) `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html) `TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc_middle/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html) @@ -42,5 +42,4 @@ Item | Kind | Short description | Chapter | [Macro expansion]: ../macro-expansion.html [Name resolution]: ../name-resolution.html [Parameter Environment]: ../param_env.html -[Chalk Book: Goals and Clauses]: https://rust-lang.github.io/chalk/book/clauses/goals_and_clauses.html#domain-goals -[Chalk Book: Lowering impls]: https://rust-lang.github.io/chalk/book/clauses/lowering_rules.html#lowering-impls +[Trait Solving: Goals and Clauses]: ../traits/goals-and-clauses.html#domain-goals diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index ded31485b..a3b3826ea 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -49,7 +49,7 @@ memoization
| The process of storing the results o MIR
| The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.html)) miri
| An interpreter for MIR used for constant evaluation. ([see more](../miri.html)) monomorphization
| The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). -normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](https://rust-lang.github.io/chalk/book/clauses/type_equality.html#normalize). +normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.html#normalizeprojection---type). newtype
| A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. NLL
| Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId
| An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). @@ -57,7 +57,7 @@ obligation
| Something that must be proven by the placeholder
| **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. point
| Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. polymorphize
| An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) -projection
| A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](https://rust-lang.github.io/chalk/book/clauses/goals_and_clauses.html#trait-ref). +projection
| A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref). promoted constants
| Constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. provider
| The function that executes a query. ([see more](../query.html)) quantified
| In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified). @@ -74,7 +74,7 @@ tcx
| The "typing context", main data stru 'tcx
| The lifetime of the allocation arena. ([see more](../ty.html)) token
| The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). [TLS]
| Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. -trait reference
| The name of a trait along with a suitable set of input type/lifetimes. ([see more](https://rust-lang.github.io/chalk/book/clauses/goals_and_clauses.html#trait-ref)) +trait reference
| The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) trans
| The code to translate MIR into LLVM IR. Renamed to codegen. ty
| The internal representation of a type. ([see more](../ty.html)) UFCS
| Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) diff --git a/src/traits/canonical-queries.md b/src/traits/canonical-queries.md new file mode 100644 index 000000000..e15bdaae2 --- /dev/null +++ b/src/traits/canonical-queries.md @@ -0,0 +1,252 @@ +# Canonical queries + +The "start" of the trait system is the **canonical query** (these are +both queries in the more general sense of the word – something you +would like to know the answer to – and in the +[rustc-specific sense](../query.html)). The idea is that the type +checker or other parts of the system, may in the course of doing their +thing want to know whether some trait is implemented for some type +(e.g., is `u32: Debug` true?). Or they may want to +[normalize some associated type](./associated-types.html). + +This section covers queries at a fairly high level of abstraction. The +subsections look a bit more closely at how these ideas are implemented +in rustc. + +## The traditional, interactive Prolog query + +In a traditional Prolog system, when you start a query, the solver +will run off and start supplying you with every possible answer it can +find. So given something like this: + +```text +?- Vec: AsRef +``` + +The solver might answer: + +```text +Vec: AsRef<[i32]> + continue? (y/n) +``` + +This `continue` bit is interesting. The idea in Prolog is that the +solver is finding **all possible** instantiations of your query that +are true. In this case, if we instantiate `?U = [i32]`, then the query +is true (note that a traditional Prolog interface does not, directly, +tell us a value for `?U`, but we can infer one by unifying the +response with our original query – Rust's solver gives back a +substitution instead). If we were to hit `y`, the solver might then +give us another possible answer: + +```text +Vec: AsRef> + continue? (y/n) +``` + +This answer derives from the fact that there is a reflexive impl +(`impl AsRef for T`) for `AsRef`. If were to hit `y` again, +then we might get back a negative response: + +```text +no +``` + +Naturally, in some cases, there may be no possible answers, and hence +the solver will just give me back `no` right away: + +```text +?- Box: Copy + no +``` + +In some cases, there might be an infinite number of responses. So for +example if I gave this query, and I kept hitting `y`, then the solver +would never stop giving me back answers: + +```text +?- Vec: Clone + Vec: Clone + continue? (y/n) + Vec>: Clone + continue? (y/n) + Vec>>: Clone + continue? (y/n) + Vec>>>: Clone + continue? (y/n) +``` + +As you can imagine, the solver will gleefully keep adding another +layer of `Box` until we ask it to stop, or it runs out of memory. + +Another interesting thing is that queries might still have variables +in them. For example: + +```text +?- Rc: Clone +``` + +might produce the answer: + +```text +Rc: Clone + continue? (y/n) +``` + +After all, `Rc` is true **no matter what type `?T` is**. + + + +## A trait query in rustc + +The trait queries in rustc work somewhat differently. Instead of +trying to enumerate **all possible** answers for you, they are looking +for an **unambiguous** answer. In particular, when they tell you the +value for a type variable, that means that this is the **only possible +instantiation** that you could use, given the current set of impls and +where-clauses, that would be provable. (Internally within the solver, +though, they can potentially enumerate all possible answers. See +[the description of the SLG solver](./slg.html) for details.) + +The response to a trait query in rustc is typically a +`Result, NoSolution>` (where the `T` will vary a bit +depending on the query itself). The `Err(NoSolution)` case indicates +that the query was false and had no answers (e.g., `Box: Copy`). +Otherwise, the `QueryResult` gives back information about the possible answer(s) +we did find. It consists of four parts: + +- **Certainty:** tells you how sure we are of this answer. It can have two + values: + - `Proven` means that the result is known to be true. + - This might be the result for trying to prove `Vec: Clone`, + say, or `Rc: Clone`. + - `Ambiguous` means that there were things we could not yet prove to + be either true *or* false, typically because more type information + was needed. (We'll see an example shortly.) + - This might be the result for trying to prove `Vec: Clone`. +- **Var values:** Values for each of the unbound inference variables + (like `?T`) that appeared in your original query. (Remember that in Prolog, + we had to infer these.) + - As we'll see in the example below, we can get back var values even + for `Ambiguous` cases. +- **Region constraints:** these are relations that must hold between + the lifetimes that you supplied as inputs. We'll ignore these here, + but see the + [section on handling regions in traits](./regions.html) for + more details. +- **Value:** The query result also comes with a value of type `T`. For + some specialized queries – like normalizing associated types – + this is used to carry back an extra result, but it's often just + `()`. + +### Examples + +Let's work through an example query to see what all the parts mean. +Consider [the `Borrow` trait][borrow]. This trait has a number of +impls; among them, there are these two (for clarity, I've written the +`Sized` bounds explicitly): + +[borrow]: https://doc.rust-lang.org/std/borrow/trait.Borrow.html + +```rust,ignore +impl Borrow for T where T: ?Sized +impl Borrow<[T]> for Vec where T: Sized +``` + +**Example 1.** Imagine we are type-checking this (rather artificial) +bit of code: + +```rust,ignore +fn foo(a: A, vec_b: Option) where A: Borrow { } + +fn main() { + let mut t: Vec<_> = vec![]; // Type: Vec + let mut u: Option<_> = None; // Type: Option + foo(t, u); // Example 1: requires `Vec: Borrow` + ... +} +``` + +As the comments indicate, we first create two variables `t` and `u`; +`t` is an empty vector and `u` is a `None` option. Both of these +variables have unbound inference variables in their type: `?T` +represents the elements in the vector `t` and `?U` represents the +value stored in the option `u`. Next, we invoke `foo`; comparing the +signature of `foo` to its arguments, we wind up with `A = Vec` and +`B = ?U`. Therefore, the where clause on `foo` requires that `Vec: +Borrow`. This is thus our first example trait query. + +There are many possible solutions to the query `Vec: Borrow`; +for example: + +- `?U = Vec`, +- `?U = [?T]`, +- `?T = u32, ?U = [u32]` +- and so forth. + +Therefore, the result we get back would be as follows (I'm going to +ignore region constraints and the "value"): + +- Certainty: `Ambiguous` – we're not sure yet if this holds +- Var values: `[?T = ?T, ?U = ?U]` – we learned nothing about the values of + the variables + +In short, the query result says that it is too soon to say much about +whether this trait is proven. During type-checking, this is not an +immediate error: instead, the type checker would hold on to this +requirement (`Vec: Borrow`) and wait. As we'll see in the next +example, it may happen that `?T` and `?U` wind up constrained from +other sources, in which case we can try the trait query again. + +**Example 2.** We can now extend our previous example a bit, +and assign a value to `u`: + +```rust,ignore +fn foo(a: A, vec_b: Option) where A: Borrow { } + +fn main() { + // What we saw before: + let mut t: Vec<_> = vec![]; // Type: Vec + let mut u: Option<_> = None; // Type: Option + foo(t, u); // `Vec: Borrow` => ambiguous + + // New stuff: + u = Some(vec![]); // ?U = Vec +} +``` + +As a result of this assignment, the type of `u` is forced to be +`Option>`, where `?V` represents the element type of the +vector. This in turn implies that `?U` is [unified] to `Vec`. + +[unified]: ../type-checking.html + +Let's suppose that the type checker decides to revisit the +"as-yet-unproven" trait obligation we saw before, `Vec: +Borrow`. `?U` is no longer an unbound inference variable; it now +has a value, `Vec`. So, if we "refresh" the query with that value, we get: + +```text +Vec: Borrow> +``` + +This time, there is only one impl that applies, the reflexive impl: + +```text +impl Borrow for T where T: ?Sized +``` + +Therefore, the trait checker will answer: + +- Certainty: `Proven` +- Var values: `[?T = ?T, ?V = ?T]` + +Here, it is saying that we have indeed proven that the obligation +holds, and we also know that `?T` and `?V` are the same type (but we +don't know what that type is yet!). + +(In fact, as the function ends here, the type checker would give an +error at this point, since the element types of `t` and `u` are still +not yet known, even though they are known to be the same.) + + diff --git a/src/traits/chalk.md b/src/traits/chalk.md index dceb04354..70af2a1f5 100644 --- a/src/traits/chalk.md +++ b/src/traits/chalk.md @@ -1,14 +1,12 @@ -# Chalk-based trait solving (new-style) - -> 🚧 This chapter describes "new-style" trait solving. This is still in the -> [process of being implemented][wg]; this chapter serves as a kind of -> in-progress design document. If you would prefer to read about how the -> current trait solver works, check out -> [this other subchapter](./resolution.html). 🚧 -> -> By the way, if you would like to help in hacking on the new solver, you will -> find instructions for getting involved in the -> [Traits Working Group tracking issue][wg]! +# Chalk-based trait solving + +[Chalk][chalk] is an experimental trait solver for rust that is currently +under development by the [Traits Working Group][wg]. Its goal is +to enable a lot of trait system features and bug fixes that are +currently hard to implement (e.g. GATs or specialization). if you +would like to help in hacking on the new solver, you will find +instructions for getting involved in the +[Traits Working Group tracking issue][wg]. [wg]: https://github.com/rust-lang/rust/issues/48416 @@ -36,8 +34,7 @@ The design of the new-style trait solving currently happens in two places: and designs for the trait system. **rustc**. Once we are happy with the logical rules, we proceed to -implementing them in rustc. This mainly happens in -[`librustc_traits`][librustc_traits]. We map our struct, trait, and impl declarations +implementing them in rustc. We map our struct, trait, and impl declarations into logical inference rules in the [lowering module in rustc](./lowering-module.md). [chalk]: https://github.com/rust-lang/chalk diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md new file mode 100644 index 000000000..ecd2ce145 --- /dev/null +++ b/src/traits/goals-and-clauses.md @@ -0,0 +1,270 @@ +# Goals and clauses + +In logic programming terms, a **goal** is something that you must +prove and a **clause** is something that you know is true. As +described in the [lowering to logic](./lowering-to-logic.html) +chapter, Rust's trait solver is based on an extension of hereditary +harrop (HH) clauses, which extend traditional Prolog Horn clauses with +a few new superpowers. + +## Goals and clauses meta structure + +In Rust's solver, **goals** and **clauses** have the following forms +(note that the two definitions reference one another): + +```text +Goal = DomainGoal // defined in the section below + | Goal && Goal + | Goal || Goal + | exists { Goal } // existential quantification + | forall { Goal } // universal quantification + | if (Clause) { Goal } // implication + | true // something that's trivially true + | ambiguous // something that's never provable + +Clause = DomainGoal + | Clause :- Goal // if can prove Goal, then Clause is true + | Clause && Clause + | forall { Clause } + +K = // a "kind" + | +``` + +The proof procedure for these sorts of goals is actually quite +straightforward. Essentially, it's a form of depth-first search. The +paper +["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] +gives the details. + +In terms of code, these types are defined in +[`librustc_middle/traits/mod.rs`][traits_mod] in rustc, and in +[`chalk-ir/src/lib.rs`][chalk_ir] in chalk. + +[pphhf]: ./bibliography.html#pphhf +[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs +[chalk_ir]: https://github.com/rust-lang/chalk/blob/master/chalk-ir/src/lib.rs + + + +## Domain goals + +*Domain goals* are the atoms of the trait logic. As can be seen in the +definitions given above, general goals basically consist in a combination of +domain goals. + +Moreover, flattening a bit the definition of clauses given previously, one can +see that clauses are always of the form: +```text +forall { DomainGoal :- Goal } +``` +hence domain goals are in fact clauses' LHS. That is, at the most granular level, +domain goals are what the trait solver will end up trying to prove. + + + +To define the set of domain goals in our system, we need to first +introduce a few simple formulations. A **trait reference** consists of +the name of a trait along with a suitable set of inputs P0..Pn: + +```text +TraitRef = P0: TraitName +``` + +So, for example, `u32: Display` is a trait reference, as is `Vec: +IntoIterator`. Note that Rust surface syntax also permits some extra +things, like associated type bindings (`Vec: IntoIterator`), that are not part of a trait reference. + + + +A **projection** consists of an associated item reference along with +its inputs P0..Pm: + +```text +Projection = >::AssocItem +``` + +Given these, we can define a `DomainGoal` as follows: + +```text +DomainGoal = Holds(WhereClause) + | FromEnv(TraitRef) + | FromEnv(Type) + | WellFormed(TraitRef) + | WellFormed(Type) + | Normalize(Projection -> Type) + +WhereClause = Implemented(TraitRef) + | ProjectionEq(Projection = Type) + | Outlives(Type: Region) + | Outlives(Region: Region) +``` + +`WhereClause` refers to a `where` clause that a Rust user would actually be able +to write in a Rust program. This abstraction exists only as a convenience as we +sometimes want to only deal with domain goals that are effectively writable in +Rust. + +Let's break down each one of these, one-by-one. + +#### Implemented(TraitRef) +e.g. `Implemented(i32: Copy)` + +True if the given trait is implemented for the given input types and lifetimes. + +#### ProjectionEq(Projection = Type) +e.g. `ProjectionEq::Item = u8` + +The given associated type `Projection` is equal to `Type`; this can be proved +with either normalization or using placeholder associated types. See +[the section on associated types](./associated-types.html). + +#### Normalize(Projection -> Type) +e.g. `ProjectionEq::Item -> u8` + +The given associated type `Projection` can be [normalized][n] to `Type`. + +As discussed in [the section on associated +types](./associated-types.html), `Normalize` implies `ProjectionEq`, +but not vice versa. In general, proving `Normalize(::Item -> U)` +also requires proving `Implemented(T: Trait)`. + +[n]: ./associated-types.html#normalize +[at]: ./associated-types.html + +#### FromEnv(TraitRef) +e.g. `FromEnv(Self: Add)` + +True if the inner `TraitRef` is *assumed* to be true, +that is, if it can be derived from the in-scope where clauses. + +For example, given the following function: + +```rust +fn loud_clone(stuff: &T) -> T { + println!("cloning!"); + stuff.clone() +} +``` + +Inside the body of our function, we would have `FromEnv(T: Clone)`. In-scope +where clauses nest, so a function body inside an impl body inherits the +impl body's where clauses, too. + +This and the next rule are used to implement [implied bounds]. As we'll see +in the section on lowering, `FromEnv(TraitRef)` implies `Implemented(TraitRef)`, +but not vice versa. This distinction is crucial to implied bounds. + +#### FromEnv(Type) +e.g. `FromEnv(HashSet)` + +True if the inner `Type` is *assumed* to be well-formed, that is, if it is an +input type of a function or an impl. + +For example, given the following code: + +```rust,ignore +struct HashSet where K: Hash { ... } + +fn loud_insert(set: &mut HashSet, item: K) { + println!("inserting!"); + set.insert(item); +} +``` + +`HashSet` is an input type of the `loud_insert` function. Hence, we assume it +to be well-formed, so we would have `FromEnv(HashSet)` inside the body of our +function. As we'll see in the section on lowering, `FromEnv(HashSet)` implies +`Implemented(K: Hash)` because the +`HashSet` declaration was written with a `K: Hash` where clause. Hence, we don't +need to repeat that bound on the `loud_insert` function: we rather automatically +assume that it is true. + +#### WellFormed(Item) +These goals imply that the given item is *well-formed*. + +We can talk about different types of items being well-formed: + +* *Types*, like `WellFormed(Vec)`, which is true in Rust, or + `WellFormed(Vec)`, which is not (because `str` is not `Sized`.) + +* *TraitRefs*, like `WellFormed(Vec: Clone)`. + +Well-formedness is important to [implied bounds]. In particular, the reason +it is okay to assume `FromEnv(T: Clone)` in the `loud_clone` example is that we +_also_ verify `WellFormed(T: Clone)` for each call site of `loud_clone`. +Similarly, it is okay to assume `FromEnv(HashSet)` in the `loud_insert` +example because we will verify `WellFormed(HashSet)` for each call site of +`loud_insert`. + +#### Outlives(Type: Region), Outlives(Region: Region) +e.g. `Outlives(&'a str: 'b)`, `Outlives('a: 'static)` + +True if the given type or region on the left outlives the right-hand region. + + + +## Coinductive goals + +Most goals in our system are "inductive". In an inductive goal, +circular reasoning is disallowed. Consider this example clause: + +```text + Implemented(Foo: Bar) :- + Implemented(Foo: Bar). +``` + +Considered inductively, this clause is useless: if we are trying to +prove `Implemented(Foo: Bar)`, we would then recursively have to prove +`Implemented(Foo: Bar)`, and that cycle would continue ad infinitum +(the trait solver will terminate here, it would just consider that +`Implemented(Foo: Bar)` is not known to be true). + +However, some goals are *co-inductive*. Simply put, this means that +cycles are OK. So, if `Bar` were a co-inductive trait, then the rule +above would be perfectly valid, and it would indicate that +`Implemented(Foo: Bar)` is true. + +*Auto traits* are one example in Rust where co-inductive goals are used. +Consider the `Send` trait, and imagine that we have this struct: + +```rust +struct Foo { + next: Option> +} +``` + +The default rules for auto traits say that `Foo` is `Send` if the +types of its fields are `Send`. Therefore, we would have a rule like + +```text +Implemented(Foo: Send) :- + Implemented(Option>: Send). +``` + +As you can probably imagine, proving that `Option>: Send` is +going to wind up circularly requiring us to prove that `Foo: Send` +again. So this would be an example where we wind up in a cycle – but +that's ok, we *do* consider `Foo: Send` to hold, even though it +references itself. + +In general, co-inductive traits are used in Rust trait solving when we +want to enumerate a fixed set of possibilities. In the case of auto +traits, we are enumerating the set of reachable types from a given +starting point (i.e., `Foo` can reach values of type +`Option>`, which implies it can reach values of type +`Box`, and then of type `Foo`, and then the cycle is complete). + +In addition to auto traits, `WellFormed` predicates are co-inductive. +These are used to achieve a similar "enumerate all the cases" pattern, +as described in the section on [implied bounds]. + +[implied bounds]: ./lowering-rules.html#implied-bounds + +## Incomplete chapter + +Some topics yet to be written: + +- Elaborate on the proof procedure +- SLG solving – introduce negative reasoning diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md index 0efc82c3e..1efdcafb7 100644 --- a/src/traits/lowering-module.md +++ b/src/traits/lowering-module.md @@ -1,56 +1 @@ # The lowering module in rustc - -The program clauses described in the -[lowering rules chapter in Chalk Book](https://rust-lang.github.io/chalk/book/clauses/lowering_rules.html) -are actually created in the [`rustc_traits::lowering`][lowering] module. - -[lowering]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_traits/lowering/ - -## The `program_clauses_for` query - -The main entry point is the `program_clauses_for` [query], which – -given a `DefId` – produces a set of Chalk program clauses. The -query is invoked on a `DefId` that identifies something like a trait, -an impl, or an associated item definition. It then produces and -returns a vector of program clauses. - -[query]: ../query.html - -## Unit tests - -**Note: We've removed the Chalk unit tests in [rust-lang/rust#69247]. -They will come back once we're ready to integrate next Chalk into rustc.** - -Here's a good example test. At the time of -this writing, it looked like this: - -```rust,ignore -#![feature(rustc_attrs)] - -trait Foo { } - -#[rustc_dump_program_clauses] //~ ERROR program clause dump -impl Foo for T where T: Iterator { } - -fn main() { - println!("hello"); -} -``` - -The `#[rustc_dump_program_clauses]` annotation can be attached to -anything with a `DefId` (It requires the `rustc_attrs` feature). The -compiler will then invoke the `program_clauses_for` query on that -item, and emit compiler errors that dump the clauses produced. These -errors just exist for unit-testing. The stderr will be: - -```text -error: program clause dump - --> $DIR/lower_impl.rs:5:1 - | -LL | #[rustc_dump_program_clauses] - | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - | - = note: forall { Implemented(T: Foo) :- ProjectionEq(::Item == i32), TypeOutlives(T: 'static), Implemented(T: std::iter::Iterator), Implemented(T: std::marker::Sized). } -``` - -[rust-lang/rust#69247]: https://github.com/rust-lang/rust/pull/69247 diff --git a/src/traits/lowering-to-logic.md b/src/traits/lowering-to-logic.md new file mode 100644 index 000000000..e1a6c1361 --- /dev/null +++ b/src/traits/lowering-to-logic.md @@ -0,0 +1,185 @@ +# Lowering to logic + +The key observation here is that the Rust trait system is basically a +kind of logic, and it can be mapped onto standard logical inference +rules. We can then look for solutions to those inference rules in a +very similar fashion to how e.g. a [Prolog] solver works. It turns out +that we can't *quite* use Prolog rules (also called Horn clauses) but +rather need a somewhat more expressive variant. + +[Prolog]: https://en.wikipedia.org/wiki/Prolog + +## Rust traits and logic + +One of the first observations is that the Rust trait system is +basically a kind of logic. As such, we can map our struct, trait, and +impl declarations into logical inference rules. For the most part, +these are basically Horn clauses, though we'll see that to capture the +full richness of Rust – and in particular to support generic +programming – we have to go a bit further than standard Horn clauses. + +To see how this mapping works, let's start with an example. Imagine +we declare a trait and a few impls, like so: + +```rust +trait Clone { } +impl Clone for usize { } +impl Clone for Vec where T: Clone { } +``` + +We could map these declarations to some Horn clauses, written in a +Prolog-like notation, as follows: + +```text +Clone(usize). +Clone(Vec) :- Clone(?T). + +// The notation `A :- B` means "A is true if B is true". +// Or, put another way, B implies A. +``` + +In Prolog terms, we might say that `Clone(Foo)` – where `Foo` is some +Rust type – is a *predicate* that represents the idea that the type +`Foo` implements `Clone`. These rules are **program clauses**; they +state the conditions under which that predicate can be proven (i.e., +considered true). So the first rule just says "Clone is implemented +for `usize`". The next rule says "for any type `?T`, Clone is +implemented for `Vec` if clone is implemented for `?T`". So +e.g. if we wanted to prove that `Clone(Vec>)`, we would do +so by applying the rules recursively: + +- `Clone(Vec>)` is provable if: + - `Clone(Vec)` is provable if: + - `Clone(usize)` is provable. (Which it is, so we're all good.) + +But now suppose we tried to prove that `Clone(Vec)`. This would +fail (after all, I didn't give an impl of `Clone` for `Bar`): + +- `Clone(Vec)` is provable if: + - `Clone(Bar)` is provable. (But it is not, as there are no applicable rules.) + +We can easily extend the example above to cover generic traits with +more than one input type. So imagine the `Eq` trait, which declares +that `Self` is equatable with a value of type `T`: + +```rust,ignore +trait Eq { ... } +impl Eq for usize { } +impl> Eq> for Vec { } +``` + +That could be mapped as follows: + +```text +Eq(usize, usize). +Eq(Vec, Vec) :- Eq(?T, ?U). +``` + +So far so good. + +## Type-checking normal functions + +OK, now that we have defined some logical rules that are able to +express when traits are implemented and to handle associated types, +let's turn our focus a bit towards **type-checking**. Type-checking is +interesting because it is what gives us the goals that we need to +prove. That is, everything we've seen so far has been about how we +derive the rules by which we can prove goals from the traits and impls +in the program; but we are also interested in how to derive the goals +that we need to prove, and those come from type-checking. + +Consider type-checking the function `foo()` here: + +```rust,ignore +fn foo() { bar::() } +fn bar>() { } +``` + +This function is very simple, of course: all it does is to call +`bar::()`. Now, looking at the definition of `bar()`, we can see +that it has one where-clause `U: Eq`. So, that means that `foo()` will +have to prove that `usize: Eq` in order to show that it can call `bar()` +with `usize` as the type argument. + +If we wanted, we could write a Prolog predicate that defines the +conditions under which `bar()` can be called. We'll say that those +conditions are called being "well-formed": + +```text +barWellFormed(?U) :- Eq(?U, ?U). +``` + +Then we can say that `foo()` type-checks if the reference to +`bar::` (that is, `bar()` applied to the type `usize`) is +well-formed: + +```text +fooTypeChecks :- barWellFormed(usize). +``` + +If we try to prove the goal `fooTypeChecks`, it will succeed: + +- `fooTypeChecks` is provable if: + - `barWellFormed(usize)`, which is provable if: + - `Eq(usize, usize)`, which is provable because of an impl. + +Ok, so far so good. Let's move on to type-checking a more complex function. + +## Type-checking generic functions: beyond Horn clauses + +In the last section, we used standard Prolog horn-clauses (augmented with Rust's +notion of type equality) to type-check some simple Rust functions. But that only +works when we are type-checking non-generic functions. If we want to type-check +a generic function, it turns out we need a stronger notion of goal than what Prolog +can provide. To see what I'm talking about, let's revamp our previous +example to make `foo` generic: + +```rust,ignore +fn foo>() { bar::() } +fn bar>() { } +``` + +To type-check the body of `foo`, we need to be able to hold the type +`T` "abstract". That is, we need to check that the body of `foo` is +type-safe *for all types `T`*, not just for some specific type. We might express +this like so: + +```text +fooTypeChecks :- + // for all types T... + forall { + // ...if we assume that Eq(T, T) is provable... + if (Eq(T, T)) { + // ...then we can prove that `barWellFormed(T)` holds. + barWellFormed(T) + } + }. +``` + +This notation I'm using here is the notation I've been using in my +prototype implementation; it's similar to standard mathematical +notation but a bit Rustified. Anyway, the problem is that standard +Horn clauses don't allow universal quantification (`forall`) or +implication (`if`) in goals (though many Prolog engines do support +them, as an extension). For this reason, we need to accept something +called "first-order hereditary harrop" (FOHH) clauses – this long +name basically means "standard Horn clauses with `forall` and `if` in +the body". But it's nice to know the proper name, because there is a +lot of work describing how to efficiently handle FOHH clauses; see for +example Gopalan Nadathur's excellent +["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] +in [the bibliography]. + +[the bibliography]: ./bibliography.html +[pphhf]: ./bibliography.html#pphhf + +It turns out that supporting FOHH is not really all that hard. And +once we are able to do that, we can easily describe the type-checking +rule for generic functions like `foo` in our logic. + +## Source + +This page is a lightly adapted version of a +[blog post by Nicholas Matsakis][lrtl]. + +[lrtl]: http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/ diff --git a/src/traits/regions.md b/src/traits/regions.md deleted file mode 100644 index 4657529dc..000000000 --- a/src/traits/regions.md +++ /dev/null @@ -1,9 +0,0 @@ -# Region constraints - -*To be written.* - -Chalk does not have the concept of region constraints, and as of this -writing, work on rustc was not far enough to worry about them. - -In the meantime, you can read about region constraints in the -[type inference](../type-inference.html#region-constraints) section. From 9d9eb150deb4fb0db865f981c505dea9f93df54e Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Mon, 20 Apr 2020 22:36:05 +0800 Subject: [PATCH 0959/1812] Fix links. --- src/traits/canonical-queries.md | 11 +++-------- src/traits/goals-and-clauses.md | 12 ++++++------ src/traits/lowering-to-logic.md | 6 +++--- 3 files changed, 12 insertions(+), 17 deletions(-) diff --git a/src/traits/canonical-queries.md b/src/traits/canonical-queries.md index e15bdaae2..5ba450d4e 100644 --- a/src/traits/canonical-queries.md +++ b/src/traits/canonical-queries.md @@ -7,7 +7,7 @@ would like to know the answer to – and in the checker or other parts of the system, may in the course of doing their thing want to know whether some trait is implemented for some type (e.g., is `u32: Debug` true?). Or they may want to -[normalize some associated type](./associated-types.html). +normalize some associated type. This section covers queries at a fairly high level of abstraction. The subsections look a bit more closely at how these ideas are implemented @@ -104,9 +104,7 @@ trying to enumerate **all possible** answers for you, they are looking for an **unambiguous** answer. In particular, when they tell you the value for a type variable, that means that this is the **only possible instantiation** that you could use, given the current set of impls and -where-clauses, that would be provable. (Internally within the solver, -though, they can potentially enumerate all possible answers. See -[the description of the SLG solver](./slg.html) for details.) +where-clauses, that would be provable. The response to a trait query in rustc is typically a `Result, NoSolution>` (where the `T` will vary a bit @@ -130,10 +128,7 @@ we did find. It consists of four parts: - As we'll see in the example below, we can get back var values even for `Ambiguous` cases. - **Region constraints:** these are relations that must hold between - the lifetimes that you supplied as inputs. We'll ignore these here, - but see the - [section on handling regions in traits](./regions.html) for - more details. + the lifetimes that you supplied as inputs. We'll ignore these here. - **Value:** The query result also comes with a value of type `T`. For some specialized queries – like normalizing associated types – this is used to carry back an extra result, but it's often just diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index ecd2ce145..f4ceb99a0 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -41,7 +41,7 @@ In terms of code, these types are defined in [`librustc_middle/traits/mod.rs`][traits_mod] in rustc, and in [`chalk-ir/src/lib.rs`][chalk_ir] in chalk. -[pphhf]: ./bibliography.html#pphhf +[pphhf]: https://rust-lang.github.io/chalk/book/bibliography.html#pphhf [traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs [chalk_ir]: https://github.com/rust-lang/chalk/blob/master/chalk-ir/src/lib.rs @@ -118,7 +118,7 @@ e.g. `ProjectionEq::Item = u8` The given associated type `Projection` is equal to `Type`; this can be proved with either normalization or using placeholder associated types. See -[the section on associated types](./associated-types.html). +[the section on associated types in Chalk Book][at]. #### Normalize(Projection -> Type) e.g. `ProjectionEq::Item -> u8` @@ -126,12 +126,12 @@ e.g. `ProjectionEq::Item -> u8` The given associated type `Projection` can be [normalized][n] to `Type`. As discussed in [the section on associated -types](./associated-types.html), `Normalize` implies `ProjectionEq`, +types in Chalk Book][at], `Normalize` implies `ProjectionEq`, but not vice versa. In general, proving `Normalize(::Item -> U)` also requires proving `Implemented(T: Trait)`. -[n]: ./associated-types.html#normalize -[at]: ./associated-types.html +[n]: https://rust-lang.github.io/chalk/book/clauses/type_equality.html#normalize +[at]: https://rust-lang.github.io/chalk/book/clauses/type_equality.html #### FromEnv(TraitRef) e.g. `FromEnv(Self: Add)` @@ -260,7 +260,7 @@ In addition to auto traits, `WellFormed` predicates are co-inductive. These are used to achieve a similar "enumerate all the cases" pattern, as described in the section on [implied bounds]. -[implied bounds]: ./lowering-rules.html#implied-bounds +[implied bounds]: https://rust-lang.github.io/chalk/book/clauses/implied_bounds.html#implied-bounds ## Incomplete chapter diff --git a/src/traits/lowering-to-logic.md b/src/traits/lowering-to-logic.md index e1a6c1361..cc8b3bf80 100644 --- a/src/traits/lowering-to-logic.md +++ b/src/traits/lowering-to-logic.md @@ -168,10 +168,10 @@ the body". But it's nice to know the proper name, because there is a lot of work describing how to efficiently handle FOHH clauses; see for example Gopalan Nadathur's excellent ["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf] -in [the bibliography]. +in [the bibliography of Chalk Book][bibliography]. -[the bibliography]: ./bibliography.html -[pphhf]: ./bibliography.html#pphhf +[bibliography]: https://rust-lang.github.io/chalk/book/bibliography.html +[pphhf]: https://rust-lang.github.io/chalk/book/bibliography.html#pphhf It turns out that supporting FOHH is not really all that hard. And once we are able to do that, we can easily describe the type-checking From bdf565dba6457f86b886fcbca1e4c2148ede22a0 Mon Sep 17 00:00:00 2001 From: Charles Lew Date: Sat, 25 Apr 2020 09:17:48 +0800 Subject: [PATCH 0960/1812] Address review comments. Co-Authored-By: Who? Me?! --- src/SUMMARY.md | 8 ++++---- src/traits/lowering-module.md | 2 ++ 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ee4d7e3f2..fe040d9e2 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -77,10 +77,10 @@ - [Caching subtleties](./traits/caching.md) - [Specialization](./traits/specialization.md) - [Chalk-based trait solving](./traits/chalk.md) - - [Lowering to logic](./traits/lowering-to-logic.md) - - [Goals and clauses](./traits/goals-and-clauses.md) - - [Canonical queries](./traits/canonical-queries.md) - - [Lowering module in rustc](./traits/lowering-module.md) + - [Lowering to logic](./traits/lowering-to-logic.md) + - [Goals and clauses](./traits/goals-and-clauses.md) + - [Canonical queries](./traits/canonical-queries.md) + - [Lowering module in rustc](./traits/lowering-module.md) - [Type checking](./type-checking.md) - [Method Lookup](./method-lookup.md) - [Variance](./variance.md) diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md index 1efdcafb7..8795cb79c 100644 --- a/src/traits/lowering-module.md +++ b/src/traits/lowering-module.md @@ -1 +1,3 @@ # The lowering module in rustc + +This work is ongoing. This section will be filled in once some of it has landed in `rustc`. From f57f25dc45a7cd71886fcd89c19956b4c417d94f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 25 Apr 2020 14:23:59 -0500 Subject: [PATCH 0961/1812] remove info about diag ice breakers; doesn't exist yet (#682) --- src/ice-breaker/diagnostics.md | 43 ---------------------------------- 1 file changed, 43 deletions(-) delete mode 100644 src/ice-breaker/diagnostics.md diff --git a/src/ice-breaker/diagnostics.md b/src/ice-breaker/diagnostics.md deleted file mode 100644 index 96450d888..000000000 --- a/src/ice-breaker/diagnostics.md +++ /dev/null @@ -1,43 +0,0 @@ -# Diagnostics ICE-breakers - -**Github Label:** [A-diagnostics] - -[A-Diagnostics]: https://github.com/rust-lang/rust/labels/A-diagnostics - -The "Diagnostics ICE-breakers" are focused on bugs that center around the -user visible compiler output. These bugs can fall under one of multiple topics: - -- [D-papercut]: Errors that needs small tweaks to archieve a good output. -- [D-newcomer-roadblock]: Errors that are hard to understand for new users. -- [D-confusing]: Errors that are hard to understand, regardless of experience -level. -- [D-invalid-suggestion]: Structured suggestions use heuristics to suggest -valid code that captures the user's intent, but these heuristics can be wrong. -This label aggregates cases where the heuristics don't account for some case. -- [D-verbose]: Sometimes errors lean towards verbosity to try and increase -understandability, but in practice the "wall of text" effect can be counter -productive. Tickets labeled this way are about _removing_ output from existing -errors. -- [D-incorrect]: A diagnostic that is giving misleading or incorrect -information. This might require creating a new, more targetted, error. -- [D-inconsistent]: Inconsistency in formatting, grammar or style between -diagnostic messages. This is usually related to capitalization or sentence -tense. -- [D-edition]: error that should account for edition differences, but doesn't. -- [A-diagnostic-suggestions]: error that should have a structured suggestion, -but don't. - - -[D-papercut]: https://github.com/rust-lang/rust/labels/D-papercut -[D-newcomer-roadblock]: https://github.com/rust-lang/rust/labels/D-newcomer-roadblock -[D-confusing]: https://github.com/rust-lang/rust/labels/D-confusing -[D-invalid-suggestion]: https://github.com/rust-lang/rust/labels/D-invalid-suggestion -[D-verbose]: https://github.com/rust-lang/rust/labels/D-verbose -[D-incorrect]: https://github.com/rust-lang/rust/labels/D-incorrect -[D-inconsistent]: https://github.com/rust-lang/rust/labels/D-inconsistent -[D-edition]: https://github.com/rust-lang/rust/labels/D-edition -[A-diagnostic-suggestions]: https://github.com/rust-lang/rust/labels/A-diagnostic-suggestions - -For more information, visit the [diagnostics page]. - -[diagnostics page]: ../diagnostics.md From 159cb7e700f72a186a00b72790efda44127e1985 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 27 Apr 2020 17:40:49 -0300 Subject: [PATCH 0962/1812] Fix sub-diagnostic typo --- src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 2212fc790..b77e4547f 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -182,7 +182,7 @@ replace their current content. The message that accompanies them should be understandable in the following contexts: -- shown as an independent sug-diagnostic (this is the default output) +- shown as an independent sub-diagnostic (this is the default output) - shown as a label pointing at the affected span (this is done automatically if the some heuristics for verbosity are met) - shown as a `help` sub-diagnostic with no content (used for cases where the From 36a06c0f2565ac1ee4b21ecec084dfdde4a2edd5 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 27 Apr 2020 17:42:10 -0300 Subject: [PATCH 0963/1812] Remove extra the --- src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index b77e4547f..ab36e428f 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -184,7 +184,7 @@ contexts: - shown as an independent sub-diagnostic (this is the default output) - shown as a label pointing at the affected span (this is done automatically if -the some heuristics for verbosity are met) +some heuristics for verbosity are met) - shown as a `help` sub-diagnostic with no content (used for cases where the suggestion is obvious from the text, but we still want to let tools to apply them)) From 622be10b7b8501ae4c2399ea84572f90f8cf9050 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 28 Apr 2020 16:19:37 -0300 Subject: [PATCH 0964/1812] It's just ICE-breaker (#685) --- src/ice-breaker/about.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ice-breaker/about.md b/src/ice-breaker/about.md index 642fbe4a1..d9c724532 100644 --- a/src/ice-breaker/about.md +++ b/src/ice-breaker/about.md @@ -5,7 +5,7 @@ The **ICE-breaker groups** are an easy way to help out with rustc in a ICE-breaker groups are **[easy to join](#join)** (just submit a PR!) and joining does not entail any particular commitment. -Once you [join an ICE ICE-breaker group](#join), you will be added to +Once you [join an ICE-breaker group](#join), you will be added to a list that receives pings on github whenever a new issue is found that fits the ICE-breaker group's criteria. If you are interested, you can then [claim the issue] and start working on it. From 0b32573dd7d831efa55ae32d696629522b904828 Mon Sep 17 00:00:00 2001 From: Hanif Ariffin Date: Thu, 30 Apr 2020 21:18:21 -0400 Subject: [PATCH 0965/1812] Minute formatting fix --- src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 37b1bc97b..958dd3337 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -74,7 +74,7 @@ _actual_ output is much longer. [View full HTML output][profile-example-html]. Note; it could take up to a second to properly render depending on your browser. -Here is the corresponding text output](./example-0.counts.txt). +Here is the corresponding [text output](./example-0.counts.txt). [profile-example-html]: ./example-0.html From c0ad84300359f6ef9f19eece8e5cecf4955dd50f Mon Sep 17 00:00:00 2001 From: Hanif Ariffin Date: Thu, 30 Apr 2020 08:48:42 -0400 Subject: [PATCH 0966/1812] Hide link behind a clickable text It currently does not appear as a clickable link here https://rustc-dev-guide.rust-lang.org/queries/incremental-compilation.html Additionally, this is a particularly long and nasty link. --- src/queries/incremental-compilation.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/queries/incremental-compilation.md b/src/queries/incremental-compilation.md index be8580f2d..499b3282f 100644 --- a/src/queries/incremental-compilation.md +++ b/src/queries/incremental-compilation.md @@ -137,8 +137,10 @@ algorithm like so: it did not change. ## Resources -The initial design document can be found at https://github.com/nikomatsakis/rustc-on-demand-incremental-design-doc/blob/master/0000-rustc-on-demand-and-incremental.md, which expands on the memoization details, provides more high-level overview and motivation for this system. +The initial design document can be found at [here][initial-design], which expands on the memoization details, provides more high-level overview and motivation for this system. # Footnotes [^salsa]: I have long wanted to rename it to the Salsa algorithm, but it never caught on. -@nikomatsakis + +[initial-design]: https://github.com/nikomatsakis/rustc-on-demand-incremental-design-doc/blob/master/0000-rustc-on-demand-and-incremental.md From 1b9f80cc40d194b27b26a453eb7516ba0fd55cfd Mon Sep 17 00:00:00 2001 From: Hanif Ariffin Date: Thu, 30 Apr 2020 19:03:49 -0400 Subject: [PATCH 0967/1812] Update src/queries/incremental-compilation.md Removed `at`. Co-authored-by: LeSeulArtichaut --- src/queries/incremental-compilation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/queries/incremental-compilation.md b/src/queries/incremental-compilation.md index 499b3282f..394b4de74 100644 --- a/src/queries/incremental-compilation.md +++ b/src/queries/incremental-compilation.md @@ -137,7 +137,7 @@ algorithm like so: it did not change. ## Resources -The initial design document can be found at [here][initial-design], which expands on the memoization details, provides more high-level overview and motivation for this system. +The initial design document can be found [here][initial-design], which expands on the memoization details, provides more high-level overview and motivation for this system. # Footnotes From 26e0ae52dd2c4607ae77f21b2a9588eb1d78a098 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 30 Apr 2020 18:59:32 -0500 Subject: [PATCH 0968/1812] tidy --- src/queries/incremental-compilation.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/queries/incremental-compilation.md b/src/queries/incremental-compilation.md index 394b4de74..210d5b391 100644 --- a/src/queries/incremental-compilation.md +++ b/src/queries/incremental-compilation.md @@ -137,7 +137,9 @@ algorithm like so: it did not change. ## Resources -The initial design document can be found [here][initial-design], which expands on the memoization details, provides more high-level overview and motivation for this system. +The initial design document can be found [here][initial-design], which expands +on the memoization details, provides more high-level overview and motivation +for this system. # Footnotes From 03282ca486264fd5fae3b89defb1873a683b771a Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 1 May 2020 16:08:23 +0200 Subject: [PATCH 0969/1812] I confirmed this --- src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index d6d03ab1e..780f5d871 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -205,7 +205,7 @@ if you run the compiler with `RUSTC_LOG=rustc rustc some.rs` and only see `INFO` logs, make sure that `debug-assertions=yes` is turned on in your config.toml. -I also think that in some cases just setting it will not trigger a rebuild, +In some cases, just setting it will not trigger a rebuild, so if you changed it and you already have a compiler built, you might want to call `x.py clean` to force one. From 98e94be044c5e311a17e9fb661e3c24d50d69b74 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 1 May 2020 16:05:15 +0200 Subject: [PATCH 0970/1812] improve info regarding incremental a little --- src/tests/running.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index 4126341aa..a6303c1a6 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -148,10 +148,10 @@ time in subsequent rebuilds: ``` If you don't want to include the flag with every command, you can -enable it in the `config.toml`, too: +enable it in the `config.toml`: ```toml -# Whether to always use incremental compilation when building rustc +[rust] incremental = true ``` From a8bb0c17f3976957d931d16512b16ec7e1bed433 Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Sat, 2 May 2020 15:56:33 +0200 Subject: [PATCH 0971/1812] Fix example for winnowing --- src/traits/resolution.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/traits/resolution.md b/src/traits/resolution.md index 7f73bfe4f..236ca966d 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -191,12 +191,16 @@ trait Get { fn get(&self) -> Self; } -impl Get for T { - fn get(&self) -> T { *self } +impl Get for T { + fn get(&self) -> T { + *self + } } -impl Get for Box { - fn get(&self) -> Box { Box::new(get_it(&**self)) } +impl Get for Box { + fn get(&self) -> Box { + Box::new(::get(self)) + } } ``` From 158caa975a2ff9f8546e3d9d0ff314c22aad595f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 30 Apr 2020 22:43:52 -0500 Subject: [PATCH 0972/1812] Reduce cache timeout to catch broken links faster. --- book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book.toml b/book.toml index 3d90479cb..c342c3874 100644 --- a/book.toml +++ b/book.toml @@ -16,5 +16,5 @@ level = 1 [output.linkcheck] follow-web-links = true exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il" ] -cache-timeout = 172800 +cache-timeout = 86400 warning-policy = "error" From 32f3330167de451a6fcfdfdcd191a2d9298db97a Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 6 May 2020 13:59:28 -0500 Subject: [PATCH 0973/1812] add a bit more on parallel compilation --- src/SUMMARY.md | 1 + src/parallel-rustc.md | 45 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 src/parallel-rustc.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index fe040d9e2..f1efcf597 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -44,6 +44,7 @@ - [Profiling Queries](./queries/profiling.md) - [Salsa](./salsa.md) - [Memory Management in Rustc](./memory.md) + - [Parallel Compilation](./parallel-rustc.md) - [Part 3: Source Code Representations](./part-3-intro.md) - [The Rustc Driver and Interface](./rustc-driver.md) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md new file mode 100644 index 000000000..c8214af38 --- /dev/null +++ b/src/parallel-rustc.md @@ -0,0 +1,45 @@ +# Parallel Compilation + +Most of the compiler is not parallel. This represents an opportunity for +improving compiler performance. Much effort has been put into parallelizing +`rustc`, but it is still pretty early days for this work. There is a lot of +design and correctness work that needs to be done. + +One can try out the current parallel compiler work by enabling it in the +`config.toml`. + +There are a few basic ideas in this effort: + +- There are a lot of loops in the compiler that just iterate over all items in + a crate. These can possibly be parallelized. +- We can use (a custom fork of) [`rayon`] to run tasks in parallel. The custom + fork allows the execution of DAGs of tasks, not just trees. +- There are currently a lot of global data structures that need to be made + thread-safe. A key strategy here has been converting interior-mutable + data-structures (e.g. `Cell`) into their thread-safe siblings (e.g. `Mutex`). + +[`rayon`]: https://crates.io/rayon + +As of this writing, much of this effort is on hold due to lack of manpower. We +have a working prototype with promising performance gains in many cases. +However, there are two blockers: + +- It's not clear what invariants need to be upheld that might not hold in the + face of concurrency. An auditing effort was underway, but seems to have + stalled at some point. + +- There is a lot of lock contention, which actually degrades performance as the + number of threads increases beyond 4. + +Here are some resources that can used to learn more (note that some of them are +a bit out of date): + +- [This IRLO thread by Zoxc, when of the pioneers of the effort][irlo0] +- [This list of interior mutability in the compiler by nikomatsakis][imlist] +- [This IRLO thread by alexchricton about performance][irlo1] +- [This tracking issue][tracking] + +[irlo0]: https://internals.rust-lang.org/t/parallelizing-rustc-using-rayon/6606 +[imlist]: https://github.com/nikomatsakis/rustc-parallelization/blob/master/interior-mutability-list.md +[irlo1]: https://internals.rust-lang.org/t/help-test-parallel-rustc/11503 +[tracking]: https://github.com/rust-lang/rust/issues/48685 From e1736cc9d086678514130440b3eca3a50367b06b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 6 May 2020 17:01:45 -0500 Subject: [PATCH 0974/1812] typo Co-authored-by: Yuki Okushi --- src/parallel-rustc.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index c8214af38..66a692a91 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -31,8 +31,8 @@ However, there are two blockers: - There is a lot of lock contention, which actually degrades performance as the number of threads increases beyond 4. -Here are some resources that can used to learn more (note that some of them are -a bit out of date): +Here are some resources that can be used to learn more (note that some of them +are a bit out of date): - [This IRLO thread by Zoxc, when of the pioneers of the effort][irlo0] - [This list of interior mutability in the compiler by nikomatsakis][imlist] From 6f79c282d89df46e08c2f10938485189ed4358b6 Mon Sep 17 00:00:00 2001 From: Hanif Ariffin Date: Thu, 7 May 2020 10:44:39 -0400 Subject: [PATCH 0975/1812] Added link to the `ty::Adt` (#696) * Added link to the `ty::Adt` * Formatting fixes Thanks @JohnTitor Co-authored-by: Yuki Okushi --- src/ty.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/ty.md b/src/ty.md index 76e71584f..37f45cde1 100644 --- a/src/ty.md +++ b/src/ty.md @@ -175,10 +175,10 @@ There are a lot of related types, and we’ll cover them in time (e.g regions/li There are a bunch of variants on the `TyKind` enum, which you can see by looking at the rustdocs. Here is a sampling: -[**Algebraic Data Types (ADTs)**]() An [*algebraic Data Type*][wikiadt] is a `struct`, `enum` or -`union`. Under the hood, `struct`, `enum` and `union` are actually implemented the same way: they -are all [`ty::TyKind::Adt`][kindadt]. It’s basically a user defined type. We will talk more about -these later. +[**Algebraic Data Types (ADTs)**][kindadt] An [*algebraic Data Type*][wikiadt] is a `struct`, +`enum` or `union`. Under the hood, `struct`, `enum` and `union` are actually implemented +the same way: they are all [`ty::TyKind::Adt`][kindadt]. It’s basically a user defined type. +We will talk more about these later. [**Foreign**][kindforeign] Corresponds to `extern type T`. From 7f394a55790dc86fe352c4e5a4bfc2efe65ace00 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 2 May 2020 14:46:48 -0700 Subject: [PATCH 0976/1812] Example of getting diagnostics --- src/SUMMARY.md | 1 + src/rustc-driver-getting-diagnostics.md | 101 ++++++++++++++++++++++++ 2 files changed, 102 insertions(+) create mode 100644 src/rustc-driver-getting-diagnostics.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f1efcf597..87c638ffd 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -50,6 +50,7 @@ - [The Rustc Driver and Interface](./rustc-driver.md) - [Rustdoc](./rustdoc.md) - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) + - [Ex: Getting diagnostics through `rustc_interface`](./rustc-driver-getting-diagnostics.md) - [Syntax and the AST](./syntax-intro.md) - [Lexing and Parsing](./the-parser.md) - [`#[test]` Implementation](./test-implementation.md) diff --git a/src/rustc-driver-getting-diagnostics.md b/src/rustc-driver-getting-diagnostics.md new file mode 100644 index 000000000..d4b395555 --- /dev/null +++ b/src/rustc-driver-getting-diagnostics.md @@ -0,0 +1,101 @@ +# Example: Getting diagnostic through `rustc_interface` + +`rustc_interface` allows you to intercept diagnostics that would otherwise be printed to stderr. + +## Getting diagnostics + +NOTE: For the example to compile, you will need to first run the following: + + rustup component add rustc-dev + +To get diagnostics from the compiler, configure `rustc_interface::Config` to output diagnostic to a buffer, and run `TyCtxt.analysis`: + +```rust +#![feature(rustc_private)] + +extern crate rustc; +extern crate rustc_error_codes; +extern crate rustc_errors; +extern crate rustc_hash; +extern crate rustc_hir; +extern crate rustc_interface; +extern crate rustc_session; +extern crate rustc_span; + +use rustc_errors::registry; +use rustc_session::config; +use rustc_span::source_map; +use std::io; +use std::path; +use std::process; +use std::str; +use std::sync; + +// Buffer diagnostics in a Vec. +#[derive(Clone)] +pub struct DiagnosticSink(sync::Arc>>); + +impl io::Write for DiagnosticSink { + fn write(&mut self, buf: &[u8]) -> io::Result { + self.0.lock().unwrap().write(buf) + } + fn flush(&mut self) -> io::Result<()> { + self.0.lock().unwrap().flush() + } +} + +fn main() { + let out = process::Command::new("rustc") + .arg("--print=sysroot") + .current_dir(".") + .output() + .unwrap(); + let sysroot = str::from_utf8(&out.stdout).unwrap().trim(); + let buffer = sync::Arc::new(sync::Mutex::new(Vec::new())); + let config = rustc_interface::Config { + opts: config::Options { + maybe_sysroot: Some(path::PathBuf::from(sysroot)), + // Configure the compiler to emit diagnostics in compact JSON format. + error_format: config::ErrorOutputType::Json { + pretty: false, + json_rendered: rustc_errors::emitter::HumanReadableErrorType::Default( + rustc_errors::emitter::ColorConfig::Never, + ), + }, + ..config::Options::default() + }, + // This program contains a type error. + input: config::Input::Str { + name: source_map::FileName::Custom("main.rs".to_string()), + input: "fn main() { let x: &str = 1; }".to_string(), + }, + // Redirect the diagnostic output of the compiler to a buffer. + diagnostic_output: rustc_session::DiagnosticOutput::Raw(Box::from(DiagnosticSink( + buffer.clone(), + ))), + crate_cfg: rustc_hash::FxHashSet::default(), + input_path: None, + output_dir: None, + output_file: None, + file_loader: None, + stderr: None, + crate_name: None, + lint_caps: rustc_hash::FxHashMap::default(), + register_lints: None, + override_queries: None, + registry: registry::Registry::new(&rustc_error_codes::DIAGNOSTICS), + }; + rustc_interface::run_compiler(config, |compiler| { + compiler.enter(|queries| { + queries.global_ctxt().unwrap().take().enter(|tcx| { + // Run the analysis phase on the local crate to trigger the type error. + tcx.analysis(rustc_hir::def_id::LOCAL_CRATE); + }); + }); + }); + // Read and print buffered diagnostics. + let diagnostics = String::from_utf8(buffer.lock().unwrap().clone()).unwrap(); + println!("{}", diagnostics); +} + +``` From 718047c64721f61958c2c685dc76dd5a88007154 Mon Sep 17 00:00:00 2001 From: George Fraser Date: Sat, 2 May 2020 15:06:21 -0700 Subject: [PATCH 0977/1812] Line length --- src/rustc-driver-getting-diagnostics.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/rustc-driver-getting-diagnostics.md b/src/rustc-driver-getting-diagnostics.md index d4b395555..72649d6a2 100644 --- a/src/rustc-driver-getting-diagnostics.md +++ b/src/rustc-driver-getting-diagnostics.md @@ -8,7 +8,9 @@ NOTE: For the example to compile, you will need to first run the following: rustup component add rustc-dev -To get diagnostics from the compiler, configure `rustc_interface::Config` to output diagnostic to a buffer, and run `TyCtxt.analysis`: +To get diagnostics from the compiler, +configure `rustc_interface::Config` to output diagnostic to a buffer, +and run `TyCtxt.analysis`: ```rust #![feature(rustc_private)] From 0a3ac2d34f9662e7999d4b9189b77886be9a33be Mon Sep 17 00:00:00 2001 From: George Fraser Date: Tue, 5 May 2020 21:41:11 -0700 Subject: [PATCH 0978/1812] Reference complete examples --- examples/rustc-driver-example.rs | 56 +++------ examples/rustc-driver-getting-diagnostics.rs | 89 ++++++++++++++ .../rustc-driver-interacting-with-the-ast.rs | 78 ++++++++++++ src/rustc-driver-getting-diagnostics.md | 114 ++++-------------- src/rustc-driver-interacting-with-the-ast.md | 18 +-- 5 files changed, 222 insertions(+), 133 deletions(-) create mode 100644 examples/rustc-driver-getting-diagnostics.rs create mode 100644 examples/rustc-driver-interacting-with-the-ast.rs diff --git a/examples/rustc-driver-example.rs b/examples/rustc-driver-example.rs index 62c80b4ae..4b0b23aaa 100644 --- a/examples/rustc-driver-example.rs +++ b/examples/rustc-driver-example.rs @@ -1,17 +1,20 @@ #![feature(rustc_private)] +// NOTE: For the example to compile, you will need to first run the following: +// rustup component add rustc-dev + extern crate rustc; extern crate rustc_error_codes; extern crate rustc_errors; extern crate rustc_hash; extern crate rustc_hir; extern crate rustc_interface; +extern crate rustc_session; extern crate rustc_span; -use rustc::session; -use rustc::session::config; use rustc_errors::registry; use rustc_hash::{FxHashMap, FxHashSet}; +use rustc_session::config; use rustc_span::source_map; use std::path; use std::process; @@ -24,60 +27,41 @@ fn main() { .output() .unwrap(); let sysroot = str::from_utf8(&out.stdout).unwrap().trim(); - let filename = "main.rs"; - let contents = "static HELLO: &str = \"Hello, world!\"; fn main() { println!(\"{}\", HELLO); }"; - let errors = registry::Registry::new(&rustc_error_codes::DIAGNOSTICS); let config = rustc_interface::Config { // Command line options opts: config::Options { maybe_sysroot: Some(path::PathBuf::from(sysroot)), ..config::Options::default() }, - // cfg! configuration in addition to the default ones - // FxHashSet<(String, Option)> - crate_cfg: FxHashSet::default(), - + crate_cfg: FxHashSet::default(), // FxHashSet<(String, Option)> input: config::Input::Str { - name: source_map::FileName::Custom(String::from(filename)), - input: String::from(contents), + name: source_map::FileName::Custom("main.rs".to_string()), + input: "static HELLO: &str = \"Hello, world!\"; fn main() { println!(\"{}\", HELLO); }" + .to_string(), }, - // Option - input_path: None, - // Option - output_dir: None, - // Option - output_file: None, - // Option> - file_loader: None, - diagnostic_output: session::DiagnosticOutput::Default, - + input_path: None, // Option + output_dir: None, // Option + output_file: None, // Option + file_loader: None, // Option> + diagnostic_output: rustc_session::DiagnosticOutput::Default, // Set to capture stderr output during compiler execution - // Option>>> - stderr: None, - - // Option - crate_name: None, - // FxHashMap - lint_caps: FxHashMap::default(), - + stderr: None, // Option>>> + crate_name: None, // Option + lint_caps: FxHashMap::default(), // FxHashMap // This is a callback from the driver that is called when we're registering lints; // it is called during plugin registration when we have the LintStore in a non-shared state. // // Note that if you find a Some here you probably want to call that function in the new // function being registered. - // Option> - register_lints: None, - + register_lints: None, // Option> // This is a callback from the driver that is called just after we have populated // the list of queries. // // The second parameter is local providers and the third parameter is external providers. - // Option, &mut ty::query::Providers<'_>)> - override_queries: None, - + override_queries: None, // Option, &mut ty::query::Providers<'_>)> // Registry of diagnostics codes. - registry: errors, + registry: registry::Registry::new(&rustc_error_codes::DIAGNOSTICS), }; rustc_interface::run_compiler(config, |compiler| { compiler.enter(|queries| { diff --git a/examples/rustc-driver-getting-diagnostics.rs b/examples/rustc-driver-getting-diagnostics.rs new file mode 100644 index 000000000..cf08ed87f --- /dev/null +++ b/examples/rustc-driver-getting-diagnostics.rs @@ -0,0 +1,89 @@ +#![feature(rustc_private)] + +// NOTE: For the example to compile, you will need to first run the following: +// rustup component add rustc-dev + +extern crate rustc; +extern crate rustc_error_codes; +extern crate rustc_errors; +extern crate rustc_hash; +extern crate rustc_hir; +extern crate rustc_interface; +extern crate rustc_session; +extern crate rustc_span; + +use rustc_errors::registry; +use rustc_session::config; +use rustc_span::source_map; +use std::io; +use std::path; +use std::process; +use std::str; +use std::sync; + +// Buffer diagnostics in a Vec. +#[derive(Clone)] +pub struct DiagnosticSink(sync::Arc>>); + +impl io::Write for DiagnosticSink { + fn write(&mut self, buf: &[u8]) -> io::Result { + self.0.lock().unwrap().write(buf) + } + fn flush(&mut self) -> io::Result<()> { + self.0.lock().unwrap().flush() + } +} + +fn main() { + let out = process::Command::new("rustc") + .arg("--print=sysroot") + .current_dir(".") + .output() + .unwrap(); + let sysroot = str::from_utf8(&out.stdout).unwrap().trim(); + let buffer = sync::Arc::new(sync::Mutex::new(Vec::new())); + let config = rustc_interface::Config { + opts: config::Options { + maybe_sysroot: Some(path::PathBuf::from(sysroot)), + // Configure the compiler to emit diagnostics in compact JSON format. + error_format: config::ErrorOutputType::Json { + pretty: false, + json_rendered: rustc_errors::emitter::HumanReadableErrorType::Default( + rustc_errors::emitter::ColorConfig::Never, + ), + }, + ..config::Options::default() + }, + // This program contains a type error. + input: config::Input::Str { + name: source_map::FileName::Custom("main.rs".to_string()), + input: "fn main() { let x: &str = 1; }".to_string(), + }, + // Redirect the diagnostic output of the compiler to a buffer. + diagnostic_output: rustc_session::DiagnosticOutput::Raw(Box::from(DiagnosticSink( + buffer.clone(), + ))), + crate_cfg: rustc_hash::FxHashSet::default(), + input_path: None, + output_dir: None, + output_file: None, + file_loader: None, + stderr: None, + crate_name: None, + lint_caps: rustc_hash::FxHashMap::default(), + register_lints: None, + override_queries: None, + registry: registry::Registry::new(&rustc_error_codes::DIAGNOSTICS), + }; + rustc_interface::run_compiler(config, |compiler| { + compiler.enter(|queries| { + queries.global_ctxt().unwrap().take().enter(|tcx| { + // Run the analysis phase on the local crate to trigger the type error. + tcx.analysis(rustc_hir::def_id::LOCAL_CRATE); + }); + }); + }); + // Read buffered diagnostics. + let diagnostics = String::from_utf8(buffer.lock().unwrap().clone()).unwrap(); + println!("{}", diagnostics); +} diff --git a/examples/rustc-driver-interacting-with-the-ast.rs b/examples/rustc-driver-interacting-with-the-ast.rs new file mode 100644 index 000000000..105ee0019 --- /dev/null +++ b/examples/rustc-driver-interacting-with-the-ast.rs @@ -0,0 +1,78 @@ +#![feature(rustc_private)] + +// NOTE: For the example to compile, you will need to first run the following: +// rustup component add rustc-dev + +extern crate rustc; +extern crate rustc_error_codes; +extern crate rustc_errors; +extern crate rustc_hash; +extern crate rustc_hir; +extern crate rustc_interface; +extern crate rustc_session; +extern crate rustc_span; + +use rustc_errors::registry; +use rustc_session::config; +use rustc_span::source_map; +use std::path; +use std::process; +use std::str; + +fn main() { + let out = process::Command::new("rustc") + .arg("--print=sysroot") + .current_dir(".") + .output() + .unwrap(); + let sysroot = str::from_utf8(&out.stdout).unwrap().trim(); + let config = rustc_interface::Config { + opts: config::Options { + maybe_sysroot: Some(path::PathBuf::from(sysroot)), + ..config::Options::default() + }, + input: config::Input::Str { + name: source_map::FileName::Custom("main.rs".to_string()), + input: "fn main() { let message = \"Hello, world!\"; println!(\"{}\", message); }" + .to_string(), + }, + diagnostic_output: rustc_session::DiagnosticOutput::Default, + crate_cfg: rustc_hash::FxHashSet::default(), + input_path: None, + output_dir: None, + output_file: None, + file_loader: None, + stderr: None, + crate_name: None, + lint_caps: rustc_hash::FxHashMap::default(), + register_lints: None, + override_queries: None, + registry: registry::Registry::new(&rustc_error_codes::DIAGNOSTICS), + }; + rustc_interface::run_compiler(config, |compiler| { + compiler.enter(|queries| { + // Analyze the crate and inspect the types under the cursor. + queries.global_ctxt().unwrap().take().enter(|tcx| { + // Every compilation contains a single crate. + let krate = tcx.hir().krate(); + // Iterate over the top-level items in the crate, looking for the main function. + for (_, item) in &krate.items { + // Use pattern-matching to find a specific node inside the main function. + if let rustc_hir::ItemKind::Fn(_, _, body_id) = item.kind { + let expr = &tcx.hir().body(body_id).value; + if let rustc_hir::ExprKind::Block(block, _) = expr.kind { + if let rustc_hir::StmtKind::Local(local) = block.stmts[0].kind { + if let Some(expr) = local.init { + let hir_id = expr.hir_id; // hir_id identifies the string "Hello, world!" + let def_id = tcx.hir().local_def_id(item.hir_id); // def_id identifies the main function + let ty = tcx.typeck_tables_of(def_id).node_type(hir_id); + println!("{:?}: {:?}", expr, ty); // prints expr(HirId { owner: DefIndex(3), local_id: 4 }: "Hello, world!"): &'static str + } + } + } + } + } + }) + }); + }); +} diff --git a/src/rustc-driver-getting-diagnostics.md b/src/rustc-driver-getting-diagnostics.md index 72649d6a2..27ca2ca12 100644 --- a/src/rustc-driver-getting-diagnostics.md +++ b/src/rustc-driver-getting-diagnostics.md @@ -4,100 +4,38 @@ ## Getting diagnostics -NOTE: For the example to compile, you will need to first run the following: - - rustup component add rustc-dev - To get diagnostics from the compiler, configure `rustc_interface::Config` to output diagnostic to a buffer, and run `TyCtxt.analysis`: ```rust -#![feature(rustc_private)] - -extern crate rustc; -extern crate rustc_error_codes; -extern crate rustc_errors; -extern crate rustc_hash; -extern crate rustc_hir; -extern crate rustc_interface; -extern crate rustc_session; -extern crate rustc_span; - -use rustc_errors::registry; -use rustc_session::config; -use rustc_span::source_map; -use std::io; -use std::path; -use std::process; -use std::str; -use std::sync; - -// Buffer diagnostics in a Vec. -#[derive(Clone)] -pub struct DiagnosticSink(sync::Arc>>); - -impl io::Write for DiagnosticSink { - fn write(&mut self, buf: &[u8]) -> io::Result { - self.0.lock().unwrap().write(buf) - } - fn flush(&mut self) -> io::Result<()> { - self.0.lock().unwrap().flush() - } -} - -fn main() { - let out = process::Command::new("rustc") - .arg("--print=sysroot") - .current_dir(".") - .output() - .unwrap(); - let sysroot = str::from_utf8(&out.stdout).unwrap().trim(); - let buffer = sync::Arc::new(sync::Mutex::new(Vec::new())); - let config = rustc_interface::Config { - opts: config::Options { - maybe_sysroot: Some(path::PathBuf::from(sysroot)), - // Configure the compiler to emit diagnostics in compact JSON format. - error_format: config::ErrorOutputType::Json { - pretty: false, - json_rendered: rustc_errors::emitter::HumanReadableErrorType::Default( - rustc_errors::emitter::ColorConfig::Never, - ), - }, - ..config::Options::default() +// See https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-getting-diagnostics.rs for complete program. +let buffer = sync::Arc::new(sync::Mutex::new(Vec::new())); +let config = rustc_interface::Config { + opts: config::Options { + // Configure the compiler to emit diagnostics in compact JSON format. + error_format: config::ErrorOutputType::Json { + pretty: false, + json_rendered: rustc_errors::emitter::HumanReadableErrorType::Default( + rustc_errors::emitter::ColorConfig::Never, + ), }, - // This program contains a type error. - input: config::Input::Str { - name: source_map::FileName::Custom("main.rs".to_string()), - input: "fn main() { let x: &str = 1; }".to_string(), - }, - // Redirect the diagnostic output of the compiler to a buffer. - diagnostic_output: rustc_session::DiagnosticOutput::Raw(Box::from(DiagnosticSink( - buffer.clone(), - ))), - crate_cfg: rustc_hash::FxHashSet::default(), - input_path: None, - output_dir: None, - output_file: None, - file_loader: None, - stderr: None, - crate_name: None, - lint_caps: rustc_hash::FxHashMap::default(), - register_lints: None, - override_queries: None, - registry: registry::Registry::new(&rustc_error_codes::DIAGNOSTICS), - }; - rustc_interface::run_compiler(config, |compiler| { - compiler.enter(|queries| { - queries.global_ctxt().unwrap().take().enter(|tcx| { - // Run the analysis phase on the local crate to trigger the type error. - tcx.analysis(rustc_hir::def_id::LOCAL_CRATE); - }); + /* other config */ + }, + // Redirect the diagnostic output of the compiler to a buffer. + diagnostic_output: rustc_session::DiagnosticOutput::Raw(Box::from(DiagnosticSink( + buffer.clone(), + ))), + /* other config */ +}; +rustc_interface::run_compiler(config, |compiler| { + compiler.enter(|queries| { + queries.global_ctxt().unwrap().take().enter(|tcx| { + // Run the analysis phase on the local crate to trigger the type error. + tcx.analysis(rustc_hir::def_id::LOCAL_CRATE); }); }); - // Read and print buffered diagnostics. - let diagnostics = String::from_utf8(buffer.lock().unwrap().clone()).unwrap(); - println!("{}", diagnostics); -} - +}); +// Read buffered diagnostics. +let diagnostics = String::from_utf8(buffer.lock().unwrap().clone()).unwrap(); ``` diff --git a/src/rustc-driver-interacting-with-the-ast.md b/src/rustc-driver-interacting-with-the-ast.md index 1749c9db4..0cdc84393 100644 --- a/src/rustc-driver-interacting-with-the-ast.md +++ b/src/rustc-driver-interacting-with-the-ast.md @@ -4,18 +4,18 @@ ## Getting the type of an expression -NOTE: For the example to compile, you will need to first run the following: - - rustup component add rustc-dev - To get the type of an expression, use the `global_ctxt` to get a `TyCtxt`: ```rust -// In this example, config specifies the rust program: -// fn main() { let message = \"Hello, world!\"; println!(\"{}\", message); } -// Our goal is to get the type of the string literal "Hello, world!". -// -// See https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-example.rs for a complete example of configuring rustc_interface +// See https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-interacting-with-the-ast.rs for complete program. +let config = rustc_interface::Config { + input: config::Input::Str { + name: source_map::FileName::Custom("main.rs".to_string()), + input: "fn main() { let message = \"Hello, world!\"; println!(\"{}\", message); }" + .to_string(), + }, + /* other config */ +}; rustc_interface::run_compiler(config, |compiler| { compiler.enter(|queries| { // Analyze the crate and inspect the types under the cursor. From ee0059a6e25f8b78ce70e29c52f7f27b37dd61cc Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 25 Apr 2020 13:09:19 -0500 Subject: [PATCH 0979/1812] some cleanup in the macros chapter --- src/macro-expansion.md | 222 +++++++++++------------------------------ 1 file changed, 58 insertions(+), 164 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 279598270..e7a09d31c 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -3,15 +3,22 @@ > `librustc_ast`, `librustc_expand`, and `librustc_builtin_macros` are all undergoing > refactoring, so some of the links in this chapter may be broken. -Macro expansion happens during parsing. `rustc` has two parsers, in fact: the -normal Rust parser, and the macro parser. During the parsing phase, the normal +Rust has a very powerful macro system. There are two major types of macros: +`macro_rules!` macros (a.k.a. "Macros By Example" (MBE)) and procedural macros +("proc macros"; including custom derives). During the parsing phase, the normal Rust parser will set aside the contents of macros and their invocations. Later, before name resolution, macros are expanded using these portions of the code. -The macro parser, in turn, may call the normal Rust parser when it needs to -bind a metavariable (e.g. `$my_expr`) while parsing the contents of a macro +In this chapter, we will discuss MBEs, proc macros, and hygiene. Both types of +macros are expanded during parsing, but they happen in different ways. + +## Macros By Example + +MBEs have their own parser distinct from the normal Rust parser. When macros +are expanded, we may invoke the MBE parser to parse and expand a macro. The +MBE parser, in turn, may call the normal Rust parser when it needs to bind a +metavariable (e.g. `$my_expr`) while parsing the contents of a macro invocation. The code for macro expansion is in -[`src/librustc_expand/mbe/`][code_dir]. This chapter aims to explain how macro -expansion works. +[`src/librustc_expand/mbe/`][code_dir]. ### Example @@ -56,7 +63,7 @@ The process of expanding the macro invocation into the syntax tree `println!("{}", foo)` and then expanding that into a call to `Display::fmt` is called _macro expansion_, and it is the topic of this chapter. -### The macro parser +### The MBE parser There are two parts to macro expansion: parsing the definition and parsing the invocations. Interestingly, both are done by the macro parser. @@ -70,33 +77,32 @@ The interface of the macro parser is as follows (this is slightly simplified): ```rust,ignore fn parse_tt( - parser: &mut Cow, + parser: &mut Cow, ms: &[TokenTree], ) -> NamedParseResult ``` We use these items in macro parser: -- `sess` is a "parsing session", which keeps track of some metadata. Most - notably, this is used to keep track of errors that are generated so they can - be reported to the user. -- `tts` is a stream of tokens. The macro parser's job is to consume the raw - stream of tokens and output a binding of metavariables to corresponding token - trees. +- `parser` is a reference to the state of a normal Rust parser, including the + token stream and parsing session. The token stream is what we are about to + ask the MBE parser to parse. We will consume the raw stream of tokens and + output a binding of metavariables to corresponding token trees. The parsing + session can be used to report parser errros. - `ms` a _matcher_. This is a sequence of token trees that we want to match - `tts` against. + the token stream against. -In the analogy of a regex parser, `tts` is the input and we are matching it -against the pattern `ms`. Using our examples, `tts` could be the stream of +In the analogy of a regex parser, the token stream is the input and we are matching it +against the pattern `ms`. Using our examples, the token stream could be the stream of tokens containing the inside of the example invocation `print foo`, while `ms` might be the sequence of token (trees) `print $mvar:ident`. The output of the parser is a `NamedParseResult`, which indicates which of three cases has occurred: -- Success: `tts` matches the given matcher `ms`, and we have produced a binding +- Success: the token stream matches the given matcher `ms`, and we have produced a binding from metavariables to the corresponding token trees. -- Failure: `tts` does not match `ms`. This results in an error message such as +- Failure: the token stream does not match `ms`. This results in an error message such as "No rule expected token _blah_". - Error: some fatal error has occurred _in the parser_. For example, this happens if there are more than one pattern match, since that indicates @@ -143,7 +149,38 @@ error. For more information about the macro parser's implementation, see the comments in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp]. -### Hygiene +### `macro`s and Macros 2.0 + +There is an old and mostly undocumented effort to improve the MBE system, give +it more hygiene-related features, better scoping and visibility rules, etc. There +hasn't been a lot of work on this recently, unfortunately. Internally, `macro` +macros use the same machinery as today's MBEs; they just have additional +syntactic sugar and are allowed to be in namespaces. + +## Procedural Macros + +Precedural macros are also expanded during parsing, as mentioned above. +However, they use a rather different mechanism. Rather than having a parser in +the compiler, procedural macros are implemented as custom, third-party crates. +The compiler will compile the proc macro crate and specially annotated +functions in them (i.e. the proc macro itself), passing them a stream of tokens. + +The proc macro can then transform the token stream and output a new token +stream, which is synthesized into the AST. + +It's worth noting that the token stream type used by proc macros is _stable_, +so `rustc` does not use it internally (since our internal data structures are +unstable). + +TODO: more here. + +### Custom Derive + +Custom derives are a special type of proc macro. + +TODO: more? + +## Hygiene If you have ever used C/C++ preprocessor macros, you know that there are some annoying and hard-to-debug gotchas! For example, consider the following C code: @@ -190,21 +227,7 @@ a macro author may want to introduce a new name to the context where the macro was called. Alternately, the macro author may be defining a variable for use only within the macro (i.e. it should not be visible outside the macro). -In rustc, this "context" is tracked via `Span`s. - -TODO: what is call-site hygiene? what is def-site hygiene? - -TODO - -### Procedural Macros - -TODO - -### Custom Derive - -TODO - -TODO: maybe something about macros 2.0? +This section is about how that context is tracked. [code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe @@ -221,135 +244,6 @@ The rest of this chapter is a dump of a discussion between `mark-i-m` and it never gets lost until we can make it into a proper chapter. ```txt -mark-i-m: @Vadim Petrochenkov Hi :wave: -I was wondering if you would have a chance sometime in the next month or so to -just have a zulip discussion where you tell us (WG-learning) everything you -know about macros/expansion/hygiene. We were thinking this could be less formal -(and less work for you) than compiler lecture series lecture... thoughts? - -mark-i-m: The goal is to fill out that long-standing gap in the rustc-dev-guide - -Vadim Petrochenkov: Ok, I'm at UTC+03:00 and generally available in the -evenings (or weekends). - -mark-i-m: @Vadim Petrochenkov Either of those works for me (your evenings are -about lunch time for me :) ) Is there a particular date that would work best -for you? - -mark-i-m: @WG-learning Does anyone else have a preferred date? - - Vadim Petrochenkov: - - Is there a particular date that would work best for you? - -Nah, not much difference. (If something changes for a specific day, I'll -notify.) - -Santiago Pastorino: week days are better, but I'd say let's wait for @Vadim -Petrochenkov to say when they are ready for it and we can set a date - -Santiago Pastorino: also, we should record this so ... I guess it doesn't -matter that much when :) - - mark-i-m: - - also, we should record this so ... I guess it doesn't matter that much when - :) - -@Santiago Pastorino My thinking was to just use zulip, so we would have the log - -mark-i-m: @Vadim Petrochenkov @WG-learning How about 2 weeks from now: July 24 -at 5pm UTC time (if I did the math right, that should be evening for Vadim) - -Amanjeev Sethi: i can try and do this but I am starting a new job that week so -cannot promise. - - Santiago Pastorino: - - Vadim Petrochenkov @WG-learning How about 2 weeks from now: July 24 at 5pm - UTC time (if I did the math right, that should be evening for Vadim) - -works perfect for me - -Santiago Pastorino: @mark-i-m I have access to the compiler calendar so I can -add something there - -Santiago Pastorino: let me know if you want to add an event to the calendar, I -can do that - -Santiago Pastorino: how long it would be? - - mark-i-m: - - let me know if you want to add an event to the calendar, I can do that - -mark-i-m: That could be good :+1: - - mark-i-m: - - how long it would be? - -Let's start with 30 minutes, and if we need to schedule another we cna - - Vadim Petrochenkov: - - 5pm UTC - -1-2 hours later would be better, 5pm UTC is not evening enough. - -Vadim Petrochenkov: How exactly do you plan the meeting to go (aka how much do -I need to prepare)? - - Santiago Pastorino: - - 5pm UTC - - 1-2 hours later would be better, 5pm UTC is not evening enough. - -Scheduled for 7pm UTC then - - Santiago Pastorino: - - How exactly do you plan the meeting to go (aka how much do I need to - prepare)? - -/cc @mark-i-m - -mark-i-m: @Vadim Petrochenkov - - How exactly do you plan the meeting to go (aka how much do I need to - prepare)? - -My hope was that this could be less formal than for a compiler lecture series, -but it would be nice if you could have in your mind a tour of the design and -the code - -That is, imagine that a new person was joining the compiler team and needed to -get up to speed about macros/expansion/hygiene. What would you tell such a -person? - -mark-i-m: @Vadim Petrochenkov Are we still on for tomorrow at 7pm UTC? - -Vadim Petrochenkov: Yes. - -Santiago Pastorino: @Vadim Petrochenkov @mark-i-m I've added an event on rust -compiler team calendar - -mark-i-m: @WG-learning @Vadim Petrochenkov Hello! - -mark-i-m: We will be starting in ~7 minutes - -mark-i-m: :wave: - -Vadim Petrochenkov: I'm here. - -mark-i-m: Cool :) - -Santiago Pastorino: hello @Vadim Petrochenkov - -mark-i-m: Shall we start? - -mark-i-m: First off, @Vadim Petrochenkov Thanks for doing this! Vadim Petrochenkov: Here's some preliminary data I prepared. From 8bbe1ff044c2f835865a3dd90eedda1803267aad Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 25 Apr 2020 13:42:01 -0500 Subject: [PATCH 0980/1812] start working through discussion --- src/macro-expansion.md | 249 +++++++++-------------------------------- 1 file changed, 51 insertions(+), 198 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index e7a09d31c..002e077d8 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -229,136 +229,69 @@ only within the macro (i.e. it should not be visible outside the macro). This section is about how that context is tracked. - [code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe [code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser [code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules [code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html [parsing]: ./the-parser.html +## Notes from petrochenkov discussion + +Where to find the code: +- librustc_span/hygiene.rs - structures related to hygiene and expansion that are kept in global data (can be accessed from any Ident without any context) +- librustc_span/lib.rs - some secondary methods like macro backtrace using primary methods from hygiene.rs +- librustc_builtin_macros - implementations of built-in macros (including macro attributes and derives) and some other early code generation facilities like injection of standard library imports or generation of test harness. +- librustc_ast/config.rs - implementation of cfg/cfg_attr (they treated specially from other macros), should probably be moved into librustc_ast/ext. +- librustc_ast/tokenstream.rs + librustc_ast/parse/token.rs - structures for compiler-side tokens, token trees, and token streams. +- librustc_ast/ext - various expansion-related stuff +- librustc_ast/ext/base.rs - basic structures used by expansion +- librustc_ast/ext/expand.rs - some expansion structures and the bulk of expansion infrastructure code - collecting macro invocations, calling into resolve for them, calling their expanding functions, and integrating the results back into AST +- librustc_ast/ext/placeholder.rs - the part of expand.rs responsible for "integrating the results back into AST" basicallly, "placeholder" is a temporary AST node replaced with macro expansion result nodes +- librustc_ast/ext/builer.rs - helper functions for building AST for built-in macros in librustc_builtin_macros (and user-defined syntactic plugins previously), can probably be moved into librustc_builtin_macros these days +- librustc_ast/ext/proc_macro.rs + librustc_ast/ext/proc_macro_server.rs - interfaces between the compiler and the stable proc_macro library, converting tokens and token streams between the two representations and sending them through C ABI +- librustc_ast/ext/tt - implementation of macro_rules, turns macro_rules DSL into something with signature Fn(TokenStream) -> TokenStream that can eat and produce tokens, @mark-i-m knows more about this +- librustc_resolve/macros.rs - resolving macro paths, validating those resolutions, reporting various "not found"/"found, but it's unstable"/"expected x, found y" errors +- librustc_middle/hir/map/def_collector.rs + librustc_resolve/build_reduced_graph.rs - integrate an AST fragment freshly expanded from a macro into various parent/child structures like module hierarchy or "definition paths" + +Primary structures: +- HygieneData - global piece of data containing hygiene and expansion info that can be accessed from any Ident without any context +- ExpnId - ID of a macro call or desugaring (and also expansion of that call/desugaring, depending on context) +- ExpnInfo/InternalExpnData - a subset of properties from both macro definition and macro call available through global data +- SyntaxContext - ID of a chain of nested macro definitions (identified by ExpnIds) +- SyntaxContextData - data associated with the given SyntaxContext, mostly a cache for results of filtering that chain in different ways +- Span - a code location + SyntaxContext +- Ident - interned string (Symbol) + Span, i.e. a string with attached hygiene data +- TokenStream - a collection of TokenTrees +- TokenTree - a token (punctuation, identifier, or literal) or a delimited group (anything inside ()/[]/{}) +- SyntaxExtension - a lowered macro representation, contains its expander function transforming a tokenstream or AST into tokenstream or AST + some additional data like stability, or a list of unstable features allowed inside the macro. +- SyntaxExtensionKind - expander functions may have several different signatures (take one token stream, or two, or a piece of AST, etc), this is an enum that lists them +- ProcMacro/TTMacroExpander/AttrProcMacro/MultiItemModifier - traits representing the expander signatures (TODO: change and rename the signatures into something more consistent) +- Resolver - a trait used to break crate dependencies (so resolver services can be used in librustc_ast, despite librustc_resolve and pretty much everything else depending on librustc_ast) +- ExtCtxt/ExpansionData - various intermediate data kept and used by expansion infra in the process of its work +- AstFragment - a piece of AST that can be produced by a macro (may include multiple homogeneous AST nodes, like e.g. a list of items) +- Annotatable - a piece of AST that can be an attribute target, almost same thing as AstFragment except for types and patterns that can be produced by macros but cannot be annotated with attributes (TODO: Merge into AstFragment) +- MacResult - a "polymorphic" AST fragment, something that can turn into a different AstFragment depending on its context (aka AstFragmentKind - item, or expression, or pattern etc.) +- Invocation/InvocationKind - a structure describing a macro call, these structures are collected by the expansion infra (InvocationCollector), queued, resolved, expanded when resolved, etc. + +TODO: how a crate transitions from the state "macros exist as written in source" to "all macros are expanded" + +Expansion Heirarchies and Syntax Context +- Many AST nodes have some sort of syntax context, especially nodes from macros. The context consists of a chain of expansions leading to `ExpnId::root`. A non-macro-expanded node has syntax context 0 (`SyntaxContext::empty()`) which represents just the root node. +- There are 3 expansion heirarchies + - They all start at ExpnId::root, which is its own parent + + + + + + # Discussion about hygiene -The rest of this chapter is a dump of a discussion between `mark-i-m` and -`petrochenkov` about Macro Expansion and Hygiene. I am pasting it here so that -it never gets lost until we can make it into a proper chapter. ```txt -Vadim Petrochenkov: Here's some preliminary data I prepared. - -Vadim Petrochenkov: Below I'll assume #62771 and #62086 has landed. - -Vadim Petrochenkov: Where to find the code: librustc_span/hygiene.rs - -structures related to hygiene and expansion that are kept in global data (can -be accessed from any Ident without any context) librustc_span/lib.rs - some -secondary methods like macro backtrace using primary methods from hygiene.rs -librustc_builtin_macros - implementations of built-in macros (including macro attributes -and derives) and some other early code generation facilities like injection of -standard library imports or generation of test harness. librustc_ast/config.rs - -implementation of cfg/cfg_attr (they treated specially from other macros), -should probably be moved into librustc_ast/ext. librustc_ast/tokenstream.rs + -librustc_ast/parse/token.rs - structures for compiler-side tokens, token trees, -and token streams. librustc_ast/ext - various expansion-related stuff -librustc_ast/ext/base.rs - basic structures used by expansion -librustc_ast/ext/expand.rs - some expansion structures and the bulk of expansion -infrastructure code - collecting macro invocations, calling into resolve for -them, calling their expanding functions, and integrating the results back into -AST librustc_ast/ext/placeholder.rs - the part of expand.rs responsible for -"integrating the results back into AST" basicallly, "placeholder" is a -temporary AST node replaced with macro expansion result nodes -librustc_ast/ext/builer.rs - helper functions for building AST for built-in macros -in librustc_builtin_macros (and user-defined syntactic plugins previously), can probably -be moved into librustc_builtin_macros these days librustc_ast/ext/proc_macro.rs + -librustc_ast/ext/proc_macro_server.rs - interfaces between the compiler and the -stable proc_macro library, converting tokens and token streams between the two -representations and sending them through C ABI librustc_ast/ext/tt - -implementation of macro_rules, turns macro_rules DSL into something with -signature Fn(TokenStream) -> TokenStream that can eat and produce tokens, -@mark-i-m knows more about this librustc_resolve/macros.rs - resolving macro -paths, validating those resolutions, reporting various "not found"/"found, but -it's unstable"/"expected x, found y" errors librustc_middle/hir/map/def_collector.rs + -librustc_resolve/build_reduced_graph.rs - integrate an AST fragment freshly -expanded from a macro into various parent/child structures like module -hierarchy or "definition paths" - -Primary structures: HygieneData - global piece of data containing hygiene and -expansion info that can be accessed from any Ident without any context ExpnId - -ID of a macro call or desugaring (and also expansion of that call/desugaring, -depending on context) ExpnInfo/InternalExpnData - a subset of properties from -both macro definition and macro call available through global data -SyntaxContext - ID of a chain of nested macro definitions (identified by -ExpnIds) SyntaxContextData - data associated with the given SyntaxContext, -mostly a cache for results of filtering that chain in different ways Span - a -code location + SyntaxContext Ident - interned string (Symbol) + Span, i.e. a -string with attached hygiene data TokenStream - a collection of TokenTrees -TokenTree - a token (punctuation, identifier, or literal) or a delimited group -(anything inside ()/[]/{}) SyntaxExtension - a lowered macro representation, -contains its expander function transforming a tokenstream or AST into -tokenstream or AST + some additional data like stability, or a list of unstable -features allowed inside the macro. SyntaxExtensionKind - expander functions -may have several different signatures (take one token stream, or two, or a -piece of AST, etc), this is an enum that lists them -ProcMacro/TTMacroExpander/AttrProcMacro/MultiItemModifier - traits representing -the expander signatures (TODO: change and rename the signatures into something -more consistent) trait Resolver - a trait used to break crate dependencies (so -resolver services can be used in librustc_ast, despite librustc_resolve and pretty -much everything else depending on librustc_ast) ExtCtxt/ExpansionData - various -intermediate data kept and used by expansion infra in the process of its work -AstFragment - a piece of AST that can be produced by a macro (may include -multiple homogeneous AST nodes, like e.g. a list of items) Annotatable - a -piece of AST that can be an attribute target, almost same thing as AstFragment -except for types and patterns that can be produced by macros but cannot be -annotated with attributes (TODO: Merge into AstFragment) trait MacResult - a -"polymorphic" AST fragment, something that can turn into a different -AstFragment depending on its context (aka AstFragmentKind - item, or -expression, or pattern etc.) Invocation/InvocationKind - a structure describing -a macro call, these structures are collected by the expansion infra -(InvocationCollector), queued, resolved, expanded when resolved, etc. - -Primary algorithms / actions: TODO - -mark-i-m: Very useful :+1: - -mark-i-m: @Vadim Petrochenkov Zulip doesn't have an indication of typing, so -I'm not sure if you are waiting for me or not - -Vadim Petrochenkov: The TODO part should be about how a crate transitions from -the state "macros exist as written in source" to "all macros are expanded", but -I didn't write it yet. - -Vadim Petrochenkov: (That should probably better happen off-line.) - -Vadim Petrochenkov: Now, if you have any questions? - -mark-i-m: Thanks :) - -mark-i-m: /me is still reading :P - -mark-i-m: Ok - -mark-i-m: So I guess my first question is about hygiene, since that remains the -most mysterious to me... My understanding is that the parser outputs AST nodes, -where each node has a Span - -mark-i-m: In the absence of macros and desugaring, what does the syntax context -of an AST node look like? - -mark-i-m: @Vadim Petrochenkov - -Vadim Petrochenkov: Not each node, but many of them. When a node is not -macro-expanded, its context is 0. - -Vadim Petrochenkov: aka SyntaxContext::empty() - -Vadim Petrochenkov: it's a chain that consists of one expansion - expansion 0 -aka ExpnId::root. - -mark-i-m: Do all expansions start at root? - -Vadim Petrochenkov: Also, SyntaxContext:empty() is its own father. - -mark-i-m: Is this actually stored somewhere or is it a logical value? + Vadim Petrochenkov: All expansion hyerarchies (there are several of them) start at ExpnId::root. @@ -368,12 +301,8 @@ expn_id == 0. Vadim Petrochenkov: I don't think anyone looks into them much though. -mark-i-m: Ok - Vadim Petrochenkov: Speaking of multiple hierarchies... -mark-i-m: Go ahead :) - Vadim Petrochenkov: One is parent (expn_id1) -> parent(expn_id2) -> ... Vadim Petrochenkov: This is the order in which macros are expanded. @@ -429,8 +358,6 @@ Sorry, what is outer_expns? Vadim Petrochenkov: SyntaxContextData::outer_expn -mark-i-m: Thanks :) Please continue - Vadim Petrochenkov: ...which means a token produced by a built-in macro (which is defined in the root effectively). @@ -470,8 +397,6 @@ mark-i-m: I see, but this pattern is only used for built-ins, right? Vadim Petrochenkov: And also all stable proc macros, see the comments above. -mark-i-m: Got it - Vadim Petrochenkov: The third hierarchy is call-site hierarchy. Vadim Petrochenkov: If foo!(bar!(ident)) expands into ident @@ -507,30 +432,6 @@ generally.) Vadim Petrochenkov: Yes. -mark-i-m: Got it :) - -mark-i-m: It looks like we have ~5 minutes left. This has been very helpful -already, but I also have more questions. Shall we try to schedule another -meeting in the future? - -Vadim Petrochenkov: Sure, why not. - -Vadim Petrochenkov: A thread for offline questions-answers would be good too. - - mark-i-m: - - A thread for offline questions-answers would be good too. - -I don't mind using this thread, since it already has a lot of info in it. We -also plan to summarize the info from this thread into the rustc-dev-guide. - - Sure, why not. - -Unfortunately, I'm unavailable for a few weeks. Would August 21-ish work for -you (and @WG-learning )? - -mark-i-m: @Vadim Petrochenkov Thanks very much for your time and knowledge! - mark-i-m: One last question: are there more hierarchies? Vadim Petrochenkov: Not that I know of. Three + the context transplantation @@ -539,37 +440,8 @@ hack is already more complex than I'd like. mark-i-m: Yes, one wonders what it would be like if one also had to think about eager expansion... -Santiago Pastorino: sorry but I couldn't follow that much today, will read it -when I have some time later - -Santiago Pastorino: btw https://github.com/rust-lang/rustc-dev-guide/issues/398 - -mark-i-m: @Vadim Petrochenkov Would 7pm UTC on August 21 work for a followup? - -Vadim Petrochenkov: Tentatively yes. - -mark-i-m: @Vadim Petrochenkov @WG-learning Does this still work for everyone? - -Vadim Petrochenkov: August 21 is still ok. - -mark-i-m: @WG-learning @Vadim Petrochenkov We will start in ~30min - -Vadim Petrochenkov: Oh. Thanks for the reminder, I forgot about this entirely. - -mark-i-m: Hello! - -Vadim Petrochenkov: (I'll be here in a couple of minutes.) - -Vadim Petrochenkov: Ok, I'm here. - -mark-i-m: Hi :) - -Vadim Petrochenkov: Hi. - mark-i-m: so last time, we talked about the 3 context heirarchies -Vadim Petrochenkov: Right. - mark-i-m: Was there anything you wanted to add to that? If not, I think it would be good to get a big-picture... Given some piece of rust code, how do we get to the point where things are expanded and hygiene context is computed? @@ -728,8 +600,6 @@ imports in that module. For macro and import names this happens during expansions and integrations. -mark-i-m: Makes sense - Vadim Petrochenkov: For all other names we certainly know whether a name is resolved successfully or not on the first attempt, because no new names can appear. @@ -791,21 +661,4 @@ m!(foo); Vadim Petrochenkov: foo has context ROOT -> id(n) and bar has context ROOT -> id(m) -> id(n) after all the expansions. -mark-i-m: Cool :) - -mark-i-m: It looks like we are out of time - -mark-i-m: Is there anything you wanted to add? - -mark-i-m: We can schedule another meeting if you would like - -Vadim Petrochenkov: Yep, 23.06 already. No, I think this is an ok point to -stop. - -mark-i-m: :+1: - -mark-i-m: Thanks @Vadim Petrochenkov ! This was very helpful - -Vadim Petrochenkov: Yeah, we can schedule another one. So far it's been like 1 -hour of meetings per month? Certainly not a big burden. ``` From ff2f23277268535d3a084f2f8bbb4c32b04ecf78 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 25 Apr 2020 15:18:15 -0500 Subject: [PATCH 0981/1812] more notetaking --- src/macro-expansion.md | 148 ++++++++++------------------------------- 1 file changed, 34 insertions(+), 114 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 002e077d8..fc42ae864 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -276,112 +276,57 @@ Primary structures: TODO: how a crate transitions from the state "macros exist as written in source" to "all macros are expanded" Expansion Heirarchies and Syntax Context -- Many AST nodes have some sort of syntax context, especially nodes from macros. The context consists of a chain of expansions leading to `ExpnId::root`. A non-macro-expanded node has syntax context 0 (`SyntaxContext::empty()`) which represents just the root node. +- Many AST nodes have some sort of syntax context, especially nodes from macros. +- When we ask what is the syntax context of a node, the answer actually differs by what we are trying to do. Thus, we don't just keep track of a single context. There are in fact 3 different types of context used for different things. +- Each type of context is tracked by an "expansion heirarchy". As we expand macros, new macro calls or macro definitions may be generated, leading to some nesting. This nesting is where the heirarchies come from. Each heirarchy tracks some different aspect, though, as we will see. - There are 3 expansion heirarchies - They all start at ExpnId::root, which is its own parent + - The context of a node consists of a chain of expansions leading to `ExpnId::root`. A non-macro-expanded node has syntax context 0 (`SyntaxContext::empty()`) which represents just the root node. + - There are vectors in `HygieneData` that contain expansion info. + - There are entries here for both `SyntaxContext::empty()` and `ExpnId::root`, but they aren't used much. + 1. Tracks expansion order: when a macro invocation is in the output of another macro. + ... + expn_id2 + expn_id1 + InternalExpnData::parent is the child->parent link. That is the expn_id1 points to expn_id2 points to ... + Ex: + macro_rules! foo { () => { println!(); } } + fn main() { foo!(); } + // Then AST nodes that are finally generated would have parent(expn_id_println) -> parent(expn_id_foo), right? + 2. Tracks macro definitions: when we are expanding one macro another macro definition is revealed in its output. + ... + SyntaxContext2 + SyntaxContext1 + SyntaxContextData::parent is the child->parent link here. + SyntaxContext is the whole chain in this hierarchy, and SyntaxContextData::outer_expns are individual elements in the chain. -# Discussion about hygiene - - -```txt - - - -Vadim Petrochenkov: All expansion hyerarchies (there are several of them) start -at ExpnId::root. - -Vadim Petrochenkov: Vectors in HygieneData has entries for both ctxt == 0 and -expn_id == 0. - -Vadim Petrochenkov: I don't think anyone looks into them much though. - -Vadim Petrochenkov: Speaking of multiple hierarchies... - -Vadim Petrochenkov: One is parent (expn_id1) -> parent(expn_id2) -> ... - -Vadim Petrochenkov: This is the order in which macros are expanded. - -Vadim Petrochenkov: Well. - -Vadim Petrochenkov: When we are expanding one macro another macro is revealed -in its output. - -Vadim Petrochenkov: That's the parent-child relation in this hierarchy. - -Vadim Petrochenkov: InternalExpnData::parent is the child->parent link. - -mark-i-m: So in the above chain expn_id1 is the child? - -Vadim Petrochenkov: Yes. - -Vadim Petrochenkov: The second one is parent (SyntaxContext1) -> -parent(SyntaxContext2) -> ... - -Vadim Petrochenkov: This is about nested macro definitions. When we are -expanding one macro another macro definition is revealed in its output. -Vadim Petrochenkov: SyntaxContextData::parent is the child->parent link here. -Vadim Petrochenkov: So, SyntaxContext is the whole chain in this hierarchy, and -outer_expns are individual elements in the chain. - -mark-i-m: So for example, suppose I have the following: - -macro_rules! foo { () => { println!(); } } - -fn main() { foo!(); } - -Then AST nodes that are finally generated would have parent(expn_id_println) -> -parent(expn_id_foo), right? - -Vadim Petrochenkov: Pretty common construction (at least it was, before -refactorings) is SyntaxContext::empty().apply_mark(expn_id), which means... - - Vadim Petrochenkov: - - Then AST nodes that are finally generated would have - parent(expn_id_println) -> parent(expn_id_foo), right? - -Yes. +# Discussion about hygiene - mark-i-m: - and outer_expns are individual elements in the chain. +```txt -Sorry, what is outer_expns? -Vadim Petrochenkov: SyntaxContextData::outer_expn +Vadim Petrochenkov: Pretty common construction (at least it was, before refactorings) is SyntaxContext::empty().apply_mark(expn_id), which means a token produced by a built-in macro (which is defined in the root effectively). -Vadim Petrochenkov: ...which means a token produced by a built-in macro (which -is defined in the root effectively). +Vadim Petrochenkov: Or a stable proc macro, which are always considered to be defined in the root because they are always cross-crate, and we don't have the cross-crate hygiene implemented, ha-ha. mark-i-m: Where does the expn_id come from? -Vadim Petrochenkov: Or a stable proc macro, which are always considered to be -defined in the root because they are always cross-crate, and we don't have the -cross-crate hygiene implemented, ha-ha. - - Vadim Petrochenkov: - - Where does the expn_id come from? - Vadim Petrochenkov: ID of the built-in macro call like line!(). -Vadim Petrochenkov: Assigned continuously from 0 to N as soon as we discover -new macro calls. +Vadim Petrochenkov: Assigned continuously from 0 to N as soon as we discover new macro calls. -mark-i-m: Sorry, I didn't quite understand. Do you mean that only built-in -macros receive continuous IDs? +mark-i-m: Sorry, I didn't quite understand. Do you mean that only built-in macros receive continuous IDs? -Vadim Petrochenkov: So, the second hierarchy has a catch - the context -transplantation hack - -https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732. +Vadim Petrochenkov: So, the second hierarchy has a catch - the context transplantation hack - https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732. Vadim Petrochenkov: @@ -389,9 +334,7 @@ https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732. Vadim Petrochenkov: No, all macro calls receive ID. -Vadim Petrochenkov: Built-ins have the typical pattern -SyntaxContext::empty().apply_mark(expn_id) for syntax contexts produced by -them. +Vadim Petrochenkov: Built-ins have the typical pattern SyntaxContext::empty().apply_mark(expn_id) for syntax contexts produced by them. mark-i-m: I see, but this pattern is only used for built-ins, right? @@ -407,23 +350,17 @@ Vadim Petrochenkov: but hierarchy 3 is root -> ident Vadim Petrochenkov: ExpnInfo::call_site is the child-parent link in this case. -mark-i-m: When we expand, do we expand foo first or bar? Why is there a -hierarchy 1 here? Is that foo expands first and it expands to something that -contains bar!(ident)? +mark-i-m: When we expand, do we expand foo first or bar? Why is there a hierarchy 1 here? Is that foo expands first and it expands to something that contains bar!(ident)? Vadim Petrochenkov: Ah, yes, let's assume both foo and bar are identity macros. -Vadim Petrochenkov: Then foo!(bar!(ident)) -> expand -> bar!(ident) -> expand --> ident +Vadim Petrochenkov: Then foo!(bar!(ident)) -> expand -> bar!(ident) -> expand -> ident -Vadim Petrochenkov: If bar were expanded first, that would be eager expansion - -https://github.com/rust-lang/rfcs/pull/2320. +Vadim Petrochenkov: If bar were expanded first, that would be eager expansion - https://github.com/rust-lang/rfcs/pull/2320. -mark-i-m: And after we expand only foo! presumably whatever intermediate state -has heirarchy 1 of root->foo->(bar_ident), right? +mark-i-m: And after we expand only foo! presumably whatever intermediate state has heirarchy 1 of root->foo->(bar_ident), right? -Vadim Petrochenkov: (We have it hacked into some built-in macros, but not -generally.) +Vadim Petrochenkov: (We have it hacked into some built-in macros, but not generally.) Vadim Petrochenkov: @@ -432,23 +369,6 @@ generally.) Vadim Petrochenkov: Yes. -mark-i-m: One last question: are there more hierarchies? - -Vadim Petrochenkov: Not that I know of. Three + the context transplantation -hack is already more complex than I'd like. - -mark-i-m: Yes, one wonders what it would be like if one also had to think about -eager expansion... - -mark-i-m: so last time, we talked about the 3 context heirarchies - -mark-i-m: Was there anything you wanted to add to that? If not, I think it -would be good to get a big-picture... Given some piece of rust code, how do we -get to the point where things are expanded and hygiene context is computed? - -mark-i-m: (I'm assuming that hygiene info is computed as we expand stuff, since -I don't think you can discover it beforehand) - Vadim Petrochenkov: Ok, let's move from hygiene to expansion. Vadim Petrochenkov: Especially given that I don't remember the specific hygiene From 984d5a8b4d3cddacf5ac7f2b2cf24d2c5fcba514 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 29 Apr 2020 21:07:21 -0500 Subject: [PATCH 0982/1812] finish going through discussion --- src/macro-expansion.md | 366 ++++++++++------------------------------- 1 file changed, 89 insertions(+), 277 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index fc42ae864..fc04c6f8d 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -249,38 +249,46 @@ Where to find the code: - librustc_ast/ext/placeholder.rs - the part of expand.rs responsible for "integrating the results back into AST" basicallly, "placeholder" is a temporary AST node replaced with macro expansion result nodes - librustc_ast/ext/builer.rs - helper functions for building AST for built-in macros in librustc_builtin_macros (and user-defined syntactic plugins previously), can probably be moved into librustc_builtin_macros these days - librustc_ast/ext/proc_macro.rs + librustc_ast/ext/proc_macro_server.rs - interfaces between the compiler and the stable proc_macro library, converting tokens and token streams between the two representations and sending them through C ABI -- librustc_ast/ext/tt - implementation of macro_rules, turns macro_rules DSL into something with signature Fn(TokenStream) -> TokenStream that can eat and produce tokens, @mark-i-m knows more about this +- librustc_ast/ext/tt - implementation of macro_rules, turns macro_rules DSL into something with signature Fn(TokenStream) -> TokenStream that can eat and produce tokens, @mark-i-m knows more about this - librustc_resolve/macros.rs - resolving macro paths, validating those resolutions, reporting various "not found"/"found, but it's unstable"/"expected x, found y" errors - librustc_middle/hir/map/def_collector.rs + librustc_resolve/build_reduced_graph.rs - integrate an AST fragment freshly expanded from a macro into various parent/child structures like module hierarchy or "definition paths" Primary structures: -- HygieneData - global piece of data containing hygiene and expansion info that can be accessed from any Ident without any context -- ExpnId - ID of a macro call or desugaring (and also expansion of that call/desugaring, depending on context) +- HygieneData - global piece of data containing hygiene and expansion info that can be accessed from any Ident without any context +- ExpnId - ID of a macro call or desugaring (and also expansion of that call/desugaring, depending on context) - ExpnInfo/InternalExpnData - a subset of properties from both macro definition and macro call available through global data - SyntaxContext - ID of a chain of nested macro definitions (identified by ExpnIds) - SyntaxContextData - data associated with the given SyntaxContext, mostly a cache for results of filtering that chain in different ways -- Span - a code location + SyntaxContext +- Span - a code location + SyntaxContext - Ident - interned string (Symbol) + Span, i.e. a string with attached hygiene data -- TokenStream - a collection of TokenTrees +- TokenStream - a collection of TokenTrees - TokenTree - a token (punctuation, identifier, or literal) or a delimited group (anything inside ()/[]/{}) - SyntaxExtension - a lowered macro representation, contains its expander function transforming a tokenstream or AST into tokenstream or AST + some additional data like stability, or a list of unstable features allowed inside the macro. - SyntaxExtensionKind - expander functions may have several different signatures (take one token stream, or two, or a piece of AST, etc), this is an enum that lists them -- ProcMacro/TTMacroExpander/AttrProcMacro/MultiItemModifier - traits representing the expander signatures (TODO: change and rename the signatures into something more consistent) +- ProcMacro/TTMacroExpander/AttrProcMacro/MultiItemModifier - traits representing the expander signatures (TODO: change and rename the signatures into something more consistent) - Resolver - a trait used to break crate dependencies (so resolver services can be used in librustc_ast, despite librustc_resolve and pretty much everything else depending on librustc_ast) - ExtCtxt/ExpansionData - various intermediate data kept and used by expansion infra in the process of its work - AstFragment - a piece of AST that can be produced by a macro (may include multiple homogeneous AST nodes, like e.g. a list of items) -- Annotatable - a piece of AST that can be an attribute target, almost same thing as AstFragment except for types and patterns that can be produced by macros but cannot be annotated with attributes (TODO: Merge into AstFragment) +- Annotatable - a piece of AST that can be an attribute target, almost same thing as AstFragment except for types and patterns that can be produced by macros but cannot be annotated with attributes (TODO: Merge into AstFragment) - MacResult - a "polymorphic" AST fragment, something that can turn into a different AstFragment depending on its context (aka AstFragmentKind - item, or expression, or pattern etc.) -- Invocation/InvocationKind - a structure describing a macro call, these structures are collected by the expansion infra (InvocationCollector), queued, resolved, expanded when resolved, etc. +- Invocation/InvocationKind - a structure describing a macro call, these structures are collected by the expansion infra (InvocationCollector), queued, resolved, expanded when resolved, etc. TODO: how a crate transitions from the state "macros exist as written in source" to "all macros are expanded" -Expansion Heirarchies and Syntax Context +Hygiene and Expansion Heirarchies + +- Expansion is lazy. We work from the outside of a macro invocation inward. + - Ex: foo!(bar!(ident)) -> expand -> bar!(ident) -> expand -> ident + - Eager expansion: https://github.com/rust-lang/rfcs/pull/2320. + - Seems complicated to implemented + - We have it hacked into some built-in macros, but not generally. - Many AST nodes have some sort of syntax context, especially nodes from macros. - When we ask what is the syntax context of a node, the answer actually differs by what we are trying to do. Thus, we don't just keep track of a single context. There are in fact 3 different types of context used for different things. - Each type of context is tracked by an "expansion heirarchy". As we expand macros, new macro calls or macro definitions may be generated, leading to some nesting. This nesting is where the heirarchies come from. Each heirarchy tracks some different aspect, though, as we will see. - There are 3 expansion heirarchies - - They all start at ExpnId::root, which is its own parent + - All macros receive an integer ID assigned continuously starting from 0 as we discover new macro calls + - This is used as the `expn_id` where needed. + - All heirarchies start at ExpnId::root, which is its own parent - The context of a node consists of a chain of expansions leading to `ExpnId::root`. A non-macro-expanded node has syntax context 0 (`SyntaxContext::empty()`) which represents just the root node. - There are vectors in `HygieneData` that contain expansion info. - There are entries here for both `SyntaxContext::empty()` and `ExpnId::root`, but they aren't used much. @@ -304,281 +312,85 @@ Expansion Heirarchies and Syntax Context SyntaxContextData::parent is the child->parent link here. SyntaxContext is the whole chain in this hierarchy, and SyntaxContextData::outer_expns are individual elements in the chain. + - For built-in macros (e.g. `line!()`) or stable proc macros: tokens produced by the macro are given the context `SyntaxContext::empty().apply_mark(expn_id)` + - Such macros are considered to have been defined at the root. + - For proc macros this is because they are always cross-crate and we don't have cross-crate hygiene implemented. + The second hierarchy has the context transplantation hack. See https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732. + If the token had context X before being produced by a macro then after being produced by the macro it has context X -> macro_id. + Ex: + ```rust + macro m() { ident } + ``` -# Discussion about hygiene - - -```txt - - -Vadim Petrochenkov: Pretty common construction (at least it was, before refactorings) is SyntaxContext::empty().apply_mark(expn_id), which means a token produced by a built-in macro (which is defined in the root effectively). - -Vadim Petrochenkov: Or a stable proc macro, which are always considered to be defined in the root because they are always cross-crate, and we don't have the cross-crate hygiene implemented, ha-ha. - -mark-i-m: Where does the expn_id come from? - -Vadim Petrochenkov: ID of the built-in macro call like line!(). - -Vadim Petrochenkov: Assigned continuously from 0 to N as soon as we discover new macro calls. - -mark-i-m: Sorry, I didn't quite understand. Do you mean that only built-in macros receive continuous IDs? - -Vadim Petrochenkov: So, the second hierarchy has a catch - the context transplantation hack - https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732. - - Vadim Petrochenkov: - - Do you mean that only built-in macros receive continuous IDs? - -Vadim Petrochenkov: No, all macro calls receive ID. - -Vadim Petrochenkov: Built-ins have the typical pattern SyntaxContext::empty().apply_mark(expn_id) for syntax contexts produced by them. - -mark-i-m: I see, but this pattern is only used for built-ins, right? - -Vadim Petrochenkov: And also all stable proc macros, see the comments above. - -Vadim Petrochenkov: The third hierarchy is call-site hierarchy. - -Vadim Petrochenkov: If foo!(bar!(ident)) expands into ident - -Vadim Petrochenkov: then hierarchy 1 is root -> foo -> bar -> ident - -Vadim Petrochenkov: but hierarchy 3 is root -> ident - -Vadim Petrochenkov: ExpnInfo::call_site is the child-parent link in this case. - -mark-i-m: When we expand, do we expand foo first or bar? Why is there a hierarchy 1 here? Is that foo expands first and it expands to something that contains bar!(ident)? - -Vadim Petrochenkov: Ah, yes, let's assume both foo and bar are identity macros. - -Vadim Petrochenkov: Then foo!(bar!(ident)) -> expand -> bar!(ident) -> expand -> ident - -Vadim Petrochenkov: If bar were expanded first, that would be eager expansion - https://github.com/rust-lang/rfcs/pull/2320. - -mark-i-m: And after we expand only foo! presumably whatever intermediate state has heirarchy 1 of root->foo->(bar_ident), right? - -Vadim Petrochenkov: (We have it hacked into some built-in macros, but not generally.) - - Vadim Petrochenkov: - - And after we expand only foo! presumably whatever intermediate state has - heirarchy 1 of root->foo->(bar_ident), right? - -Vadim Petrochenkov: Yes. - -Vadim Petrochenkov: Ok, let's move from hygiene to expansion. - -Vadim Petrochenkov: Especially given that I don't remember the specific hygiene -algorithms like adjust in detail. - - Vadim Petrochenkov: - - Given some piece of rust code, how do we get to the point where things are - expanded - -So, first of all, the "some piece of rust code" is the whole crate. - -mark-i-m: Just to confirm, the algorithms are well-encapsulated, right? Like a -function or a struct as opposed to a bunch of conventions distributed across -the codebase? - -Vadim Petrochenkov: We run fully_expand_fragment in it. - - Vadim Petrochenkov: - - Just to confirm, the algorithms are well-encapsulated, right? - -Yes, the algorithmic parts are entirely inside hygiene.rs. - -Vadim Petrochenkov: Ok, some are in fn resolve_crate_root, but those are hacks. - -Vadim Petrochenkov: (Continuing about expansion.) If fully_expand_fragment is -run not on a whole crate, it means that we are performing eager expansion. - -Vadim Petrochenkov: Eager expansion is done for arguments of some built-in -macros that expect literals. - -Vadim Petrochenkov: It generally performs a subset of actions performed by the -non-eager expansion. - -Vadim Petrochenkov: So, I'll talk about non-eager expansion for now. - -mark-i-m: Eager expansion is not exposed as a language feature, right? i.e. it -is not possible for me to write an eager macro? - -Vadim Petrochenkov: -https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049 (vvv The -link is explained below vvv ) - - Vadim Petrochenkov: - - Eager expansion is not exposed as a language feature, right? i.e. it is not - possible for me to write an eager macro? - -Yes, it's entirely an ability of some built-in macros. - -Vadim Petrochenkov: Not exposed for general use. - -Vadim Petrochenkov: fully_expand_fragment works in iterations. - -Vadim Petrochenkov: Iterations looks roughly like this: -- Resolve imports in our partially built crate as much as possible. -- Collect as many macro invocations as possible from our partially built crate - (fn-like, attributes, derives) from the crate and add them to the queue. - - Vadim Petrochenkov: Take a macro from the queue, and attempt to resolve it. - - Vadim Petrochenkov: If it's resolved - run its expander function that - consumes tokens or AST and produces tokens or AST (depending on the macro - kind). - - Vadim Petrochenkov: (If it's not resolved, then put it back into the - queue.) - -Vadim Petrochenkov: ^^^ That's where we fill in the hygiene data associated -with ExpnIds. - -mark-i-m: When we put it back in the queue? - -mark-i-m: or do you mean the collect step in general? - -Vadim Petrochenkov: Once we resolved the macro call to the macro definition we -know everything about the macro and can call set_expn_data to fill in its -properties in the global data. - -Vadim Petrochenkov: I mean, immediately after successful resolution. - -Vadim Petrochenkov: That's the first part of hygiene data, the second one is -associated with SyntaxContext rather than with ExpnId, it's filled in later -during expansion. - -Vadim Petrochenkov: So, after we run the macro's expander function and got a -piece of AST (or got tokens and parsed them into a piece of AST) we need to -integrate that piece of AST into the big existing partially built AST. - -Vadim Petrochenkov: This integration is a really important step where the next -things happen: -- NodeIds are assigned. - - Vadim Petrochenkov: "def paths"s and their IDs (DefIds) are created - - Vadim Petrochenkov: Names are put into modules from the resolver point of - view. - -Vadim Petrochenkov: So, we are basically turning some vague token-like mass -into proper set in stone hierarhical AST and side tables. - -Vadim Petrochenkov: Where exactly this happens - NodeIds are assigned by -InvocationCollector (which also collects new macro calls from this new AST -piece and adds them to the queue), DefIds are created by DefCollector, and -modules are filled by BuildReducedGraphVisitor. - -Vadim Petrochenkov: These three passes run one after another on every AST -fragment freshly expanded from a macro. - -Vadim Petrochenkov: After expanding a single macro and integrating its output -we again try to resolve all imports in the crate, and then return to the big -queue processing loop and pick up the next macro. - -Vadim Petrochenkov: Repeat until there's no more macros. Vadim Petrochenkov: - -mark-i-m: The integration step is where we would get parser errors too right? - -mark-i-m: Also, when do we know definitively that resolution has failed for -particular ident? - - Vadim Petrochenkov: - - The integration step is where we would get parser errors too right? - -Yes, if the macro produced tokens (rather than AST directly) and we had to -parse them. - - Vadim Petrochenkov: - - when do we know definitively that resolution has failed for particular - ident? - -So, ident is looked up in a number of scopes during resolution. From closest -like the current block or module, to far away like preludes or built-in types. - -Vadim Petrochenkov: If lookup is certainly failed in all of the scopes, then -it's certainly failed. - -mark-i-m: This is after all expansions and integrations are done, right? - -Vadim Petrochenkov: "Certainly" is determined differently for different scopes, -e.g. for a module scope it means no unexpanded macros and no unresolved glob -imports in that module. - - Vadim Petrochenkov: - - This is after all expansions and integrations are done, right? - -For macro and import names this happens during expansions and integrations. - -Vadim Petrochenkov: For all other names we certainly know whether a name is -resolved successfully or not on the first attempt, because no new names can -appear. - -Vadim Petrochenkov: (They are resolved in a later pass, see -librustc_resolve/late.rs.) - -mark-i-m: And if at the end of the iteration, there are still things in the -queue that can't be resolve, this represents an error, right? - -mark-i-m: i.e. an undefined macro? - -Vadim Petrochenkov: Yes, if we make no progress during an iteration, then we -are stuck and that state represent an error. - -Vadim Petrochenkov: We attempt to recover though, using dummies expanding into -nothing or ExprKind::Err or something like that for unresolved macros. - -mark-i-m: This is for the purposes of diagnostics, though, right? - -Vadim Petrochenkov: But if we are going through recovery, then compilation must -result in an error anyway. - -Vadim Petrochenkov: Yes, that's for diagnostics, without recovery we would -stuck at the first unresolved macro or import. Vadim Petrochenkov: - -So, about the SyntaxContext hygiene... - -Vadim Petrochenkov: New syntax contexts are created during macro expansion. - -Vadim Petrochenkov: If the token had context X before being produced by a -macro, e.g. here ident has context SyntaxContext::root(): Vadim Petrochenkov: - -macro m() { ident } - -Vadim Petrochenkov: , then after being produced by the macro it has context X --> macro_id. - -Vadim Petrochenkov: I.e. our ident has context ROOT -> id(m) after it's -produced by m. - -Vadim Petrochenkov: The "chaining operator" -> is apply_mark in compiler code. -Vadim Petrochenkov: - -macro m() { macro n() { ident } } + Here `ident` originally has context SyntaxContext::root(). `ident` has context ROOT -> id(m) after it's produced by m. + The "chaining operator" is `apply_mark` in compiler code. -Vadim Petrochenkov: In this example the ident has context ROOT originally, then -ROOT -> id(m), then ROOT -> id(m) -> id(n). + Ex: -Vadim Petrochenkov: Note that these chains are not entirely determined by their -last element, in other words ExpnId is not isomorphic to SyntaxCtxt. + ```rust + macro m() { macro n() { ident } } + ``` + In this example the ident has context ROOT originally, then ROOT -> id(m), then ROOT -> id(m) -> id(n). -Vadim Petrochenkov: Couterexample: Vadim Petrochenkov: + Note that these chains are not entirely determined by their last element, in other words ExpnId is not isomorphic to SyntaxCtxt. -macro m($i: ident) { macro n() { ($i, bar) } } + Ex: + ```rust + macro m($i: ident) { macro n() { ($i, bar) } } -m!(foo); + m!(foo); + ``` -Vadim Petrochenkov: foo has context ROOT -> id(n) and bar has context ROOT -> -id(m) -> id(n) after all the expansions. + After all expansions, foo has context ROOT -> id(n) and bar has context ROOT -> id(m) -> id(n) -``` + 3. Call-site: tracks the location of the macro invocation. + Ex: + If foo!(bar!(ident)) expands into ident + then hierarchy 1 is root -> foo -> bar -> ident + but hierarchy 3 is root -> ident + + ExpnInfo::call_site is the child-parent link in this case. + +- Hygiene-related algorithms are entirely in hygiene.rs + - Some hacks in `resolve_crate_root`, though. + +Expansion +- Expansion happens over a whole crate at once. +- We run `fully_expand_fragment` on the crate + - If `fully_expand_fragment` is run not on a whole crate, it means that we are performing eager expansion. + - We do this for some built-ins that expect literals (not exposed to users). + - It performs a subset of actions performed by non-eager expansion, so the discussion below focuses on eager expansion. + - Original description here: https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049 + - Algorithm: `fully_expand_fragment` works in iterations. We repeat until there are no unresolved macros left. + - Resolve imports in our partially built crate as much as possible. + - (link to name-resolution chapter) names resolved from "closer" scopes (e.g. current block) to further ones (e.g. prelude) + - A resolution fails differently for different scopes, e.g. for a module scope it means no unexpanded macros and no unresolved glob imports in that module. + - Collect as many macro invocations as possible from our partially built crate + (fn-like, attributes, derives) from the crate and add them to the queue. + - Take a macro from the queue, and attempt to resolve it. + - If it's resolved - run its expander function that consumes tokens or AST and produces tokens or AST (depending on the macro kind). (If it's not resolved, then put it back into the queue.) + - At this point, we know everything about the macro itself and can call `set_expn_data` to fill in its properties in the global data -- that is the hygiene data associated with `ExpnId`. + - The macro's expander function returns a piece of AST (or tokens). We need to integrate that piece of AST into the big existing partially built AST. + - If the macro produces tokens (e.g. a proc macro), we will have to parse into an AST, which may produce parse errors. + - During expansion, we create `SyntaxContext`s (heirarchy 2). + - This is essentially where the "token-like mass" becomes a proper set-in-stone AST with side-tables + - These three passes happen one after another on every AST fragment freshly expanded from a macro + - `NodeId`s are assigned by `InvocationCollector` + - also collects new macro calls from this new AST piece and adds them to the queue + - def_paths are created and `DefId`s are assigned to them by `DefCollector` + - `Name`s are put into modules (from the resolver's point of view) by `BuildReducedGraphVisitor` + - After expanding a single macro and integrating its output continue to the next iteration of `fully_expand_fragment`. + - If we make no progress in an iteration, then we have reached a compilation error (e.g. an undefined macro). + + - We attempt to recover from failures (unresolved macros or imports) for the sake of diagnostics + - recovery can't cause compilation to suceed. We know that it will fail at this point. + - we expand errors into `ExprKind::Err` or something like that for unresolved macros + - this allows compilation to continue past the first error so that we can report more errors at a time + +Relationship to name resolution +- name resolution is done for macro and import names during expansion and integration into the AST, as discussed above +- For all other names we certainly know whether a name is resolved successfully or not on the first attempt, because no new names can appear, due to hygiene + - They are resolved in a later pass, see `librustc_resolve/late.rs` From b8935a916b96da9cf9ba10be31737f48b152c744 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 29 Apr 2020 21:13:35 -0500 Subject: [PATCH 0983/1812] get rid of old todo --- src/macro-expansion.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index fc04c6f8d..b0f23096f 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -273,8 +273,6 @@ Primary structures: - MacResult - a "polymorphic" AST fragment, something that can turn into a different AstFragment depending on its context (aka AstFragmentKind - item, or expression, or pattern etc.) - Invocation/InvocationKind - a structure describing a macro call, these structures are collected by the expansion infra (InvocationCollector), queued, resolved, expanded when resolved, etc. -TODO: how a crate transitions from the state "macros exist as written in source" to "all macros are expanded" - Hygiene and Expansion Heirarchies - Expansion is lazy. We work from the outside of a macro invocation inward. From 5d0cdc814aba41d7a252d3d95697d38236c1712e Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:28:44 -0500 Subject: [PATCH 0984/1812] add a bit to part 3 intro --- src/part-3-intro.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/part-3-intro.md b/src/part-3-intro.md index a1ec3ca90..2af8cce23 100644 --- a/src/part-3-intro.md +++ b/src/part-3-intro.md @@ -2,7 +2,9 @@ This part describes the process of taking raw source code from the user and transforming it into various forms that the compiler can work with easily. -These are called intermediate representations. +These are called _intermediate representations (IRs)_. This process starts with compiler understanding what the user has asked for: parsing the command line arguments given and determining what it is to compile. +After that, the compiler transforms the user input into a series of IRs that +look progressively less like what the user wrote. From 6ee323dce331d031900856da89c8acd0e27594c9 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:33:05 -0500 Subject: [PATCH 0985/1812] add a bit to syntax intro --- src/syntax-intro.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/syntax-intro.md b/src/syntax-intro.md index dd7e2d735..43ef44577 100644 --- a/src/syntax-intro.md +++ b/src/syntax-intro.md @@ -6,3 +6,8 @@ out that doing even this involves a lot of work, including lexing, parsing, macro expansion, name resolution, conditional compilation, feature-gate checking, and validation of the AST. In this chapter, we take a look at all of these steps. + +Notably, there isn't always a clean ordering between these tasks. For example, +macro expansion relies on name resolution to resolve the names of macros and +imports. And parsing requires macro expansion, which in turn may require +parsing the output of the macro. From d62ed17895ba2bbf5e5a8c9196dc2288c925711f Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:33:37 -0500 Subject: [PATCH 0986/1812] reorder some chapters --- src/SUMMARY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 87c638ffd..94768bc83 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -53,10 +53,10 @@ - [Ex: Getting diagnostics through `rustc_interface`](./rustc-driver-getting-diagnostics.md) - [Syntax and the AST](./syntax-intro.md) - [Lexing and Parsing](./the-parser.md) - - [`#[test]` Implementation](./test-implementation.md) - - [Panic Implementation](./panic-implementation.md) - [Macro expansion](./macro-expansion.md) - [Name resolution](./name-resolution.md) + - [`#[test]` Implementation](./test-implementation.md) + - [Panic Implementation](./panic-implementation.md) - [AST Validation](./ast-validation.md) - [Feature Gate Checking](./feature-gate-ck.md) - [The HIR (High-level IR)](./hir.md) From 3f23b32c63df7033c60f4f3b2058f0eaa431534b Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:36:47 -0500 Subject: [PATCH 0987/1812] add note about macros in parser chapter --- src/the-parser.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/the-parser.md b/src/the-parser.md index c84ac4ea2..c0f2a071b 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -38,6 +38,11 @@ To minimise the amount of copying that is done, both the `StringReader` and `Parser` have lifetimes which bind them to the parent `ParseSess`. This contains all the information needed while parsing, as well as the `SourceMap` itself. +Note that while parsing, we may encounter macro definitions or invocations. We +set these aside to be expanded (see [this chapter](./macro-expansion.md)). +Expansion may itself require parsing the output of the macro, which may reveal +more macros to be expanded, and so on. + ## More on Lexical Analysis Code for lexical analysis is split between two crates: From 0980ebf2c656ba857dfb35501669a66cbf6aad4f Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 11:50:37 -0500 Subject: [PATCH 0988/1812] reorganize the macro expansion chapter --- src/macro-expansion.md | 383 +++++++++++++++++++++-------------------- 1 file changed, 201 insertions(+), 182 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index b0f23096f..27d9d45d1 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -3,13 +3,205 @@ > `librustc_ast`, `librustc_expand`, and `librustc_builtin_macros` are all undergoing > refactoring, so some of the links in this chapter may be broken. -Rust has a very powerful macro system. There are two major types of macros: +Rust has a very powerful macro system. In the previous chapter, we saw how the +parser sets aside macros to be expanded. This chapter is about the process of +expanding those macros iteratively until we have a complete AST for our crate +with no unexpanded macros (or a compile error). + +First, we will discuss the algorithm that expands and integrates macro output +into ASTs. Next, we will take a look at how hygiene data is collected. Finally, +we will look at the specifics of expanding different types of macros. + +## Expansion and AST Integration + +TODO: expand these notes (har har)... + +- Expansion happens over a whole crate at once. +- We run `fully_expand_fragment` on the crate + - If `fully_expand_fragment` is run not on a whole crate, it means that we are performing eager expansion. + - We do this for some built-ins that expect literals (not exposed to users). + - It performs a subset of actions performed by non-eager expansion, so the discussion below focuses on eager expansion. + - Original description here: https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049 + - Algorithm: `fully_expand_fragment` works in iterations. We repeat until there are no unresolved macros left. + - Resolve imports in our partially built crate as much as possible. + - (link to name-resolution chapter) names resolved from "closer" scopes (e.g. current block) to further ones (e.g. prelude) + - A resolution fails differently for different scopes, e.g. for a module scope it means no unexpanded macros and no unresolved glob imports in that module. + - Collect as many macro invocations as possible from our partially built crate + (fn-like, attributes, derives) from the crate and add them to the queue. + - Take a macro from the queue, and attempt to resolve it. + - If it's resolved - run its expander function that consumes tokens or AST and produces tokens or AST (depending on the macro kind). (If it's not resolved, then put it back into the queue.) + - At this point, we know everything about the macro itself and can call `set_expn_data` to fill in its properties in the global data -- that is the hygiene data associated with `ExpnId`. + - The macro's expander function returns a piece of AST (or tokens). We need to integrate that piece of AST into the big existing partially built AST. + - If the macro produces tokens (e.g. a proc macro), we will have to parse into an AST, which may produce parse errors. + - During expansion, we create `SyntaxContext`s (heirarchy 2). + - This is essentially where the "token-like mass" becomes a proper set-in-stone AST with side-tables + - These three passes happen one after another on every AST fragment freshly expanded from a macro + - `NodeId`s are assigned by `InvocationCollector` + - also collects new macro calls from this new AST piece and adds them to the queue + - def_paths are created and `DefId`s are assigned to them by `DefCollector` + - `Name`s are put into modules (from the resolver's point of view) by `BuildReducedGraphVisitor` + - After expanding a single macro and integrating its output continue to the next iteration of `fully_expand_fragment`. + - If we make no progress in an iteration, then we have reached a compilation error (e.g. an undefined macro). + + - We attempt to recover from failures (unresolved macros or imports) for the sake of diagnostics + - recovery can't cause compilation to suceed. We know that it will fail at this point. + - we expand errors into `ExprKind::Err` or something like that for unresolved macros + - this allows compilation to continue past the first error so that we can report more errors at a time + +### Relationship to name resolution + +- name resolution is done for macro and import names during expansion and integration into the AST, as discussed above +- For all other names we certainly know whether a name is resolved successfully or not on the first attempt, because no new names can appear, due to hygiene + - They are resolved in a later pass, see `librustc_resolve/late.rs` + +## Hygiene and Heirarchies + +If you have ever used C/C++ preprocessor macros, you know that there are some +annoying and hard-to-debug gotchas! For example, consider the following C code: + +```c +#define DEFINE_FOO struct Bar {int x;}; struct Foo {Bar bar;}; + +// Then, somewhere else +struct Bar { + ... +}; + +DEFINE_FOO +``` + +Most people avoid writing C like this – and for good reason: it doesn't +compile. The `struct Bar` defined by the macro clashes names with the `struct +Bar` defined in the code. Consider also the following example: + +```c +#define DO_FOO(x) {\ + int y = 0;\ + foo(x, y);\ + } + +// Then elsewhere +int y = 22; +DO_FOO(y); +``` + +Do you see the problem? We wanted to generate a call `foo(22, 0)`, but instead +we got `foo(0, 0)` because the macro defined its own `y`! + +These are both examples of _macro hygiene_ issues. _Hygiene_ relates to how to +handle names defined _within a macro_. In particular, a hygienic macro system +prevents errors due to names introduced within a macro. Rust macros are hygienic +in that they do not allow one to write the sorts of bugs above. + +At a high level, hygiene within the rust compiler is accomplished by keeping +track of the context where a name is introduced and used. We can then +disambiguate names based on that context. Future iterations of the macro system +will allow greater control to the macro author to use that context. For example, +a macro author may want to introduce a new name to the context where the macro +was called. Alternately, the macro author may be defining a variable for use +only within the macro (i.e. it should not be visible outside the macro). + +This section is about how that context is tracked. + +[code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe +[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser +[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules +[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html +[parsing]: ./the-parser.html + +TODO: expand these notes + +- Expansion is lazy. We work from the outside of a macro invocation inward. + - Ex: foo!(bar!(ident)) -> expand -> bar!(ident) -> expand -> ident + - Eager expansion: https://github.com/rust-lang/rfcs/pull/2320. + - Seems complicated to implemented + - We have it hacked into some built-in macros, but not generally. +- Many AST nodes have some sort of syntax context, especially nodes from macros. +- When we ask what is the syntax context of a node, the answer actually differs by what we are trying to do. Thus, we don't just keep track of a single context. There are in fact 3 different types of context used for different things. +- Each type of context is tracked by an "expansion heirarchy". As we expand macros, new macro calls or macro definitions may be generated, leading to some nesting. This nesting is where the heirarchies come from. Each heirarchy tracks some different aspect, though, as we will see. +- There are 3 expansion heirarchies + - All macros receive an integer ID assigned continuously starting from 0 as we discover new macro calls + - This is used as the `expn_id` where needed. + - All heirarchies start at ExpnId::root, which is its own parent + - The context of a node consists of a chain of expansions leading to `ExpnId::root`. A non-macro-expanded node has syntax context 0 (`SyntaxContext::empty()`) which represents just the root node. + - There are vectors in `HygieneData` that contain expansion info. + - There are entries here for both `SyntaxContext::empty()` and `ExpnId::root`, but they aren't used much. + + 1. Tracks expansion order: when a macro invocation is in the output of another macro. + ... + expn_id2 + expn_id1 + InternalExpnData::parent is the child->parent link. That is the expn_id1 points to expn_id2 points to ... + + Ex: + macro_rules! foo { () => { println!(); } } + fn main() { foo!(); } + + // Then AST nodes that are finally generated would have parent(expn_id_println) -> parent(expn_id_foo), right? + + 2. Tracks macro definitions: when we are expanding one macro another macro definition is revealed in its output. + ... + SyntaxContext2 + SyntaxContext1 + SyntaxContextData::parent is the child->parent link here. + SyntaxContext is the whole chain in this hierarchy, and SyntaxContextData::outer_expns are individual elements in the chain. + + - For built-in macros (e.g. `line!()`) or stable proc macros: tokens produced by the macro are given the context `SyntaxContext::empty().apply_mark(expn_id)` + - Such macros are considered to have been defined at the root. + - For proc macros this is because they are always cross-crate and we don't have cross-crate hygiene implemented. + + The second hierarchy has the context transplantation hack. See https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732. + + If the token had context X before being produced by a macro then after being produced by the macro it has context X -> macro_id. + + Ex: + ```rust + macro m() { ident } + ``` + + Here `ident` originally has context SyntaxContext::root(). `ident` has context ROOT -> id(m) after it's produced by m. + The "chaining operator" is `apply_mark` in compiler code. + + Ex: + + ```rust + macro m() { macro n() { ident } } + ``` + In this example the ident has context ROOT originally, then ROOT -> id(m), then ROOT -> id(m) -> id(n). + + Note that these chains are not entirely determined by their last element, in other words ExpnId is not isomorphic to SyntaxCtxt. + + Ex: + ```rust + macro m($i: ident) { macro n() { ($i, bar) } } + + m!(foo); + ``` + + After all expansions, foo has context ROOT -> id(n) and bar has context ROOT -> id(m) -> id(n) + + 3. Call-site: tracks the location of the macro invocation. + Ex: + If foo!(bar!(ident)) expands into ident + then hierarchy 1 is root -> foo -> bar -> ident + but hierarchy 3 is root -> ident + + ExpnInfo::call_site is the child-parent link in this case. + +- Hygiene-related algorithms are entirely in hygiene.rs + - Some hacks in `resolve_crate_root`, though. + +## Producing Macro Output + +Above, we saw how the output of a macro is integrated into the AST for a crate, +and we also saw how th e hygiene data for a crate is generated. But how do we +actually produce the output of a macro? It depends on the type of macro. + +There are two types of macros in Rust: `macro_rules!` macros (a.k.a. "Macros By Example" (MBE)) and procedural macros -("proc macros"; including custom derives). During the parsing phase, the normal +(or "proc macros"; including custom derives). During the parsing phase, the normal Rust parser will set aside the contents of macros and their invocations. Later, -before name resolution, macros are expanded using these portions of the code. -In this chapter, we will discuss MBEs, proc macros, and hygiene. Both types of -macros are expanded during parsing, but they happen in different ways. +macros are expanded using these portions of the code. ## Macros By Example @@ -65,10 +257,10 @@ called _macro expansion_, and it is the topic of this chapter. ### The MBE parser -There are two parts to macro expansion: parsing the definition and parsing the +There are two parts to MBE expansion: parsing the definition and parsing the invocations. Interestingly, both are done by the macro parser. -Basically, the macro parser is like an NFA-based regex parser. It uses an +Basically, the MBE parser is like an NFA-based regex parser. It uses an algorithm similar in spirit to the [Earley parsing algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is defined in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp]. @@ -180,63 +372,10 @@ Custom derives are a special type of proc macro. TODO: more? -## Hygiene - -If you have ever used C/C++ preprocessor macros, you know that there are some -annoying and hard-to-debug gotchas! For example, consider the following C code: - -```c -#define DEFINE_FOO struct Bar {int x;}; struct Foo {Bar bar;}; - -// Then, somewhere else -struct Bar { - ... -}; - -DEFINE_FOO -``` - -Most people avoid writing C like this – and for good reason: it doesn't -compile. The `struct Bar` defined by the macro clashes names with the `struct -Bar` defined in the code. Consider also the following example: - -```c -#define DO_FOO(x) {\ - int y = 0;\ - foo(x, y);\ - } - -// Then elsewhere -int y = 22; -DO_FOO(y); -``` - -Do you see the problem? We wanted to generate a call `foo(22, 0)`, but instead -we got `foo(0, 0)` because the macro defined its own `y`! - -These are both examples of _macro hygiene_ issues. _Hygiene_ relates to how to -handle names defined _within a macro_. In particular, a hygienic macro system -prevents errors due to names introduced within a macro. Rust macros are hygienic -in that they do not allow one to write the sorts of bugs above. - -At a high level, hygiene within the rust compiler is accomplished by keeping -track of the context where a name is introduced and used. We can then -disambiguate names based on that context. Future iterations of the macro system -will allow greater control to the macro author to use that context. For example, -a macro author may want to introduce a new name to the context where the macro -was called. Alternately, the macro author may be defining a variable for use -only within the macro (i.e. it should not be visible outside the macro). - -This section is about how that context is tracked. - -[code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe -[code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser -[code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules -[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html -[parsing]: ./the-parser.html - ## Notes from petrochenkov discussion +TODO: sprinkle these links around the chapter... + Where to find the code: - librustc_span/hygiene.rs - structures related to hygiene and expansion that are kept in global data (can be accessed from any Ident without any context) - librustc_span/lib.rs - some secondary methods like macro backtrace using primary methods from hygiene.rs @@ -272,123 +411,3 @@ Primary structures: - Annotatable - a piece of AST that can be an attribute target, almost same thing as AstFragment except for types and patterns that can be produced by macros but cannot be annotated with attributes (TODO: Merge into AstFragment) - MacResult - a "polymorphic" AST fragment, something that can turn into a different AstFragment depending on its context (aka AstFragmentKind - item, or expression, or pattern etc.) - Invocation/InvocationKind - a structure describing a macro call, these structures are collected by the expansion infra (InvocationCollector), queued, resolved, expanded when resolved, etc. - -Hygiene and Expansion Heirarchies - -- Expansion is lazy. We work from the outside of a macro invocation inward. - - Ex: foo!(bar!(ident)) -> expand -> bar!(ident) -> expand -> ident - - Eager expansion: https://github.com/rust-lang/rfcs/pull/2320. - - Seems complicated to implemented - - We have it hacked into some built-in macros, but not generally. -- Many AST nodes have some sort of syntax context, especially nodes from macros. -- When we ask what is the syntax context of a node, the answer actually differs by what we are trying to do. Thus, we don't just keep track of a single context. There are in fact 3 different types of context used for different things. -- Each type of context is tracked by an "expansion heirarchy". As we expand macros, new macro calls or macro definitions may be generated, leading to some nesting. This nesting is where the heirarchies come from. Each heirarchy tracks some different aspect, though, as we will see. -- There are 3 expansion heirarchies - - All macros receive an integer ID assigned continuously starting from 0 as we discover new macro calls - - This is used as the `expn_id` where needed. - - All heirarchies start at ExpnId::root, which is its own parent - - The context of a node consists of a chain of expansions leading to `ExpnId::root`. A non-macro-expanded node has syntax context 0 (`SyntaxContext::empty()`) which represents just the root node. - - There are vectors in `HygieneData` that contain expansion info. - - There are entries here for both `SyntaxContext::empty()` and `ExpnId::root`, but they aren't used much. - - 1. Tracks expansion order: when a macro invocation is in the output of another macro. - ... - expn_id2 - expn_id1 - InternalExpnData::parent is the child->parent link. That is the expn_id1 points to expn_id2 points to ... - - Ex: - macro_rules! foo { () => { println!(); } } - fn main() { foo!(); } - - // Then AST nodes that are finally generated would have parent(expn_id_println) -> parent(expn_id_foo), right? - - 2. Tracks macro definitions: when we are expanding one macro another macro definition is revealed in its output. - ... - SyntaxContext2 - SyntaxContext1 - SyntaxContextData::parent is the child->parent link here. - SyntaxContext is the whole chain in this hierarchy, and SyntaxContextData::outer_expns are individual elements in the chain. - - - For built-in macros (e.g. `line!()`) or stable proc macros: tokens produced by the macro are given the context `SyntaxContext::empty().apply_mark(expn_id)` - - Such macros are considered to have been defined at the root. - - For proc macros this is because they are always cross-crate and we don't have cross-crate hygiene implemented. - - The second hierarchy has the context transplantation hack. See https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732. - - If the token had context X before being produced by a macro then after being produced by the macro it has context X -> macro_id. - - Ex: - ```rust - macro m() { ident } - ``` - - Here `ident` originally has context SyntaxContext::root(). `ident` has context ROOT -> id(m) after it's produced by m. - The "chaining operator" is `apply_mark` in compiler code. - - Ex: - - ```rust - macro m() { macro n() { ident } } - ``` - In this example the ident has context ROOT originally, then ROOT -> id(m), then ROOT -> id(m) -> id(n). - - Note that these chains are not entirely determined by their last element, in other words ExpnId is not isomorphic to SyntaxCtxt. - - Ex: - ```rust - macro m($i: ident) { macro n() { ($i, bar) } } - - m!(foo); - ``` - - After all expansions, foo has context ROOT -> id(n) and bar has context ROOT -> id(m) -> id(n) - - 3. Call-site: tracks the location of the macro invocation. - Ex: - If foo!(bar!(ident)) expands into ident - then hierarchy 1 is root -> foo -> bar -> ident - but hierarchy 3 is root -> ident - - ExpnInfo::call_site is the child-parent link in this case. - -- Hygiene-related algorithms are entirely in hygiene.rs - - Some hacks in `resolve_crate_root`, though. - -Expansion -- Expansion happens over a whole crate at once. -- We run `fully_expand_fragment` on the crate - - If `fully_expand_fragment` is run not on a whole crate, it means that we are performing eager expansion. - - We do this for some built-ins that expect literals (not exposed to users). - - It performs a subset of actions performed by non-eager expansion, so the discussion below focuses on eager expansion. - - Original description here: https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049 - - Algorithm: `fully_expand_fragment` works in iterations. We repeat until there are no unresolved macros left. - - Resolve imports in our partially built crate as much as possible. - - (link to name-resolution chapter) names resolved from "closer" scopes (e.g. current block) to further ones (e.g. prelude) - - A resolution fails differently for different scopes, e.g. for a module scope it means no unexpanded macros and no unresolved glob imports in that module. - - Collect as many macro invocations as possible from our partially built crate - (fn-like, attributes, derives) from the crate and add them to the queue. - - Take a macro from the queue, and attempt to resolve it. - - If it's resolved - run its expander function that consumes tokens or AST and produces tokens or AST (depending on the macro kind). (If it's not resolved, then put it back into the queue.) - - At this point, we know everything about the macro itself and can call `set_expn_data` to fill in its properties in the global data -- that is the hygiene data associated with `ExpnId`. - - The macro's expander function returns a piece of AST (or tokens). We need to integrate that piece of AST into the big existing partially built AST. - - If the macro produces tokens (e.g. a proc macro), we will have to parse into an AST, which may produce parse errors. - - During expansion, we create `SyntaxContext`s (heirarchy 2). - - This is essentially where the "token-like mass" becomes a proper set-in-stone AST with side-tables - - These three passes happen one after another on every AST fragment freshly expanded from a macro - - `NodeId`s are assigned by `InvocationCollector` - - also collects new macro calls from this new AST piece and adds them to the queue - - def_paths are created and `DefId`s are assigned to them by `DefCollector` - - `Name`s are put into modules (from the resolver's point of view) by `BuildReducedGraphVisitor` - - After expanding a single macro and integrating its output continue to the next iteration of `fully_expand_fragment`. - - If we make no progress in an iteration, then we have reached a compilation error (e.g. an undefined macro). - - - We attempt to recover from failures (unresolved macros or imports) for the sake of diagnostics - - recovery can't cause compilation to suceed. We know that it will fail at this point. - - we expand errors into `ExprKind::Err` or something like that for unresolved macros - - this allows compilation to continue past the first error so that we can report more errors at a time - -Relationship to name resolution -- name resolution is done for macro and import names during expansion and integration into the AST, as discussed above -- For all other names we certainly know whether a name is resolved successfully or not on the first attempt, because no new names can appear, due to hygiene - - They are resolved in a later pass, see `librustc_resolve/late.rs` From e8f918c0baaf1ed0216413d196d2686e162215a6 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 12:36:16 -0500 Subject: [PATCH 0989/1812] expand some notes about expansion :P --- src/macro-expansion.md | 120 +++++++++++++++++++++++++++-------------- src/name-resolution.md | 23 ++++++++ 2 files changed, 104 insertions(+), 39 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 27d9d45d1..f076ed5fa 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -14,45 +14,87 @@ we will look at the specifics of expanding different types of macros. ## Expansion and AST Integration -TODO: expand these notes (har har)... - -- Expansion happens over a whole crate at once. -- We run `fully_expand_fragment` on the crate - - If `fully_expand_fragment` is run not on a whole crate, it means that we are performing eager expansion. - - We do this for some built-ins that expect literals (not exposed to users). - - It performs a subset of actions performed by non-eager expansion, so the discussion below focuses on eager expansion. - - Original description here: https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049 - - Algorithm: `fully_expand_fragment` works in iterations. We repeat until there are no unresolved macros left. - - Resolve imports in our partially built crate as much as possible. - - (link to name-resolution chapter) names resolved from "closer" scopes (e.g. current block) to further ones (e.g. prelude) - - A resolution fails differently for different scopes, e.g. for a module scope it means no unexpanded macros and no unresolved glob imports in that module. - - Collect as many macro invocations as possible from our partially built crate - (fn-like, attributes, derives) from the crate and add them to the queue. - - Take a macro from the queue, and attempt to resolve it. - - If it's resolved - run its expander function that consumes tokens or AST and produces tokens or AST (depending on the macro kind). (If it's not resolved, then put it back into the queue.) - - At this point, we know everything about the macro itself and can call `set_expn_data` to fill in its properties in the global data -- that is the hygiene data associated with `ExpnId`. - - The macro's expander function returns a piece of AST (or tokens). We need to integrate that piece of AST into the big existing partially built AST. - - If the macro produces tokens (e.g. a proc macro), we will have to parse into an AST, which may produce parse errors. - - During expansion, we create `SyntaxContext`s (heirarchy 2). - - This is essentially where the "token-like mass" becomes a proper set-in-stone AST with side-tables - - These three passes happen one after another on every AST fragment freshly expanded from a macro - - `NodeId`s are assigned by `InvocationCollector` - - also collects new macro calls from this new AST piece and adds them to the queue - - def_paths are created and `DefId`s are assigned to them by `DefCollector` - - `Name`s are put into modules (from the resolver's point of view) by `BuildReducedGraphVisitor` - - After expanding a single macro and integrating its output continue to the next iteration of `fully_expand_fragment`. - - If we make no progress in an iteration, then we have reached a compilation error (e.g. an undefined macro). - - - We attempt to recover from failures (unresolved macros or imports) for the sake of diagnostics - - recovery can't cause compilation to suceed. We know that it will fail at this point. - - we expand errors into `ExprKind::Err` or something like that for unresolved macros - - this allows compilation to continue past the first error so that we can report more errors at a time - -### Relationship to name resolution - -- name resolution is done for macro and import names during expansion and integration into the AST, as discussed above -- For all other names we certainly know whether a name is resolved successfully or not on the first attempt, because no new names can appear, due to hygiene - - They are resolved in a later pass, see `librustc_resolve/late.rs` +First of all, expansion happens at the crate level. Given a raw source code for +a crate, the compiler will produce a massive AST with all macros expanded, all +modules inlined, etc. + +The primary entry point for this process is the +[`MacroExpander::fully_expand_fragment`][fef] method. Usually, we run this +method on a whole crate. If it is not run on a full crate, it means we are +doing _eager macro expansion_. Eager expansion means that we expand the +arguments of a macro invocation before the macro invocation itself. This is +implemented only for a few special built-in macros that expect literals (it's +not a generally available feature of Rust). Eager expansion generally performs +a subset of the things that lazy (normal) expansion does, so we will focus on +lazy expansion for the rest of this chapter. + +At a high level, [`fully_expand_fragment`][fef] works in iterations. We keep a +queue of unresolved macro invocations (that is, macros we haven't found the +definition of yet). We repeatedly try to pick a macro from the queue, resolve +it, expand it, and integrate it back. If we can't make progress in an +iteration, this represents a compile error. Here is the [algorithm][original]: + +[fef]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.MacroExpander.html#method.fully_expand_fragment +[original]: https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049 + +0. Initialize an `queue` of unresolved macros. +1. Repeat until `queue` is empty (or we make no progress, which is an error): + 0. [Resolve](./name-resolution.md) imports in our partially built crate as + much as possible. + 1. Collect as many macro invocations as possible from our partially built + crate (fn-like, attributes, derives) and add them to the queue. + 2. Dequeue the first element, and attempt to resolve it. + 3. If it's resolved: + 0. Run the macro's expander function that consumes tokens or AST and + produces tokens or AST (depending on the macro kind). + - At this point, we know everything about the macro itself and can + call `set_expn_data` to fill in its properties in the global data + -- that is the hygiene data associated with `ExpnId`. (See [the + "Hygiene" section below][hybelow]). + 1. Integrate that piece of AST into the big existing partially built + AST. This is essentially where the "token-like mass" becomes a + proper set-in-stone AST with side-tables. It happens as follows: + - If the macro produces tokens (e.g. a proc macro), we parse into + an AST, which may produce parse errors. + - During expansion, we create `SyntaxContext`s (heirarchy 2). (See + [the "Hygiene" section below][hybelow]) + - These three passes happen one after another on every AST fragment + freshly expanded from a macro: + - [`NodeId`]s are assigned by [`InvocationCollector`]. This + also collects new macro calls from this new AST piece and + adds them to the queue. + - ["Def paths"][defpath] are created and [`DefId`]s are + assigned to them by [`DefCollector`]. + - Names are put into modules (from the resolver's point of + view) by [`BuildReducedGraphVisitor`]. + 2. After expanding a single macro and integrating its output, continue + to the next iteration of [`fully_expand_fragment`][fef]. + 4. If it's not resolved: + 0. Put the macro back in the queue + 1. Continue to next iteration... + +[defpaths]: https://rustc-dev-guide.rust-lang.org/hir.html?highlight=def,path#identifiers-in-the-hir +[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html +[`InvocationCollector`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.InvocationCollector.html +[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html +[`DefCollector`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/def_collector/struct.DefCollector.html +[`BuildReducedGraphVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/build_reduced_graph/struct.BuildReducedGraphVisitor.html +[hybelow]: #hygiene-and-heirarchies + +If we make no progress in an iteration, then we have reached a compilation +error (e.g. an undefined macro). We attempt to recover from failures +(unresolved macros or imports) for the sake of diagnostics. This allows +compilation to continue past the first error, so that we can report more errors +at a time. Recovery can't cause compilation to suceed. We know that it will +fail at this point. The recovery happens by expanding unresolved macros into +[`ExprKind::Err`][err]. + +[err]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.ExprKind.html#variant.Err + +Notice that name resolution is involved here: we need to resolve imports and +macro names in the above algorithm. However, we don't try to resolve other +names yet. This happens later, as we will see in the [next +chapter](./name-resolution.md). ## Hygiene and Heirarchies diff --git a/src/name-resolution.md b/src/name-resolution.md index f3aacba00..d08fe43f3 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -1,5 +1,28 @@ # Name resolution +In the previous chapters, we saw how the AST is built with all macros expanded. +We saw how doing that requires doing some name resolution to resolve imports +and macro names. In this chapter, we show how this is actually done and more. + +In fact, we don't do full name resolution during macro expansion -- we only +resolve imports and macros at that time. This is required to know what to even +expand. Later, after we have the whole AST, we due full name resolution to +resolve all names in the crate. This happens in [`rustc_resolve::late`][late]. +Unlike during macro expansion, in this late expansion, we only need to try to +resolve a name once, since no new names can be added. If we fail to resolve a +name now, then it is a compiler error. + +Name resolution can be complex. There are a few different namespaces (e.g. +macros, values, types, lifetimes), and names my be valid at different (nested) +scopes. Also, different types of names can fail to be resolved differently, and +failures can happen differently at different scopes. For example, for a module +scope, failure means no unexpanded macros and no unresolved glob imports in +that module. On the other hand, in a function body, failure requires that a +name be absent from the block we are in, all outer scopes, and the global +scope. + +[late]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/index.html + ## Basics In our programs we can refer to variables, types, functions, etc, by giving them From ba8620f34a3125e067afc0b896f63ceb2937b36c Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 19:13:18 -0500 Subject: [PATCH 0990/1812] add a bit more info about eager exp --- src/macro-expansion.md | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index f076ed5fa..500b1a78c 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -28,6 +28,20 @@ not a generally available feature of Rust). Eager expansion generally performs a subset of the things that lazy (normal) expansion does, so we will focus on lazy expansion for the rest of this chapter. +As an example, consider the following: + +```rust,ignore +macro bar($i: ident) { $i } +macro foo($i: ident) { $i } + +foo!(bar!(baz)); +``` + +A lazy expansion would expand `foo!` first. An eager expansion would expand +`bar!` first. Implementing eager expansion more generally would be challenging, +but we implement it for a few special built-in macros for the sake of user +experience. + At a high level, [`fully_expand_fragment`][fef] works in iterations. We keep a queue of unresolved macro invocations (that is, macros we haven't found the definition of yet). We repeatedly try to pick a macro from the queue, resolve @@ -143,8 +157,6 @@ a macro author may want to introduce a new name to the context where the macro was called. Alternately, the macro author may be defining a variable for use only within the macro (i.e. it should not be visible outside the macro). -This section is about how that context is tracked. - [code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe [code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser [code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules @@ -153,11 +165,6 @@ This section is about how that context is tracked. TODO: expand these notes -- Expansion is lazy. We work from the outside of a macro invocation inward. - - Ex: foo!(bar!(ident)) -> expand -> bar!(ident) -> expand -> ident - - Eager expansion: https://github.com/rust-lang/rfcs/pull/2320. - - Seems complicated to implemented - - We have it hacked into some built-in macros, but not generally. - Many AST nodes have some sort of syntax context, especially nodes from macros. - When we ask what is the syntax context of a node, the answer actually differs by what we are trying to do. Thus, we don't just keep track of a single context. There are in fact 3 different types of context used for different things. - Each type of context is tracked by an "expansion heirarchy". As we expand macros, new macro calls or macro definitions may be generated, leading to some nesting. This nesting is where the heirarchies come from. Each heirarchy tracks some different aspect, though, as we will see. From f05ff9c30d4aa5305a7324e8125ff5d1f2c54471 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 20:08:36 -0500 Subject: [PATCH 0991/1812] expand notes on expansion heirarchies --- src/macro-expansion.md | 185 ++++++++++++++++++++++++++++------------- 1 file changed, 128 insertions(+), 57 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 500b1a78c..6bd809680 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -163,82 +163,153 @@ only within the macro (i.e. it should not be visible outside the macro). [code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html [parsing]: ./the-parser.html -TODO: expand these notes +The context is attached to AST nodes. All AST nodes generated by macros have +context attached. Additionally, there may be other nodes that have context +attached, such as some desugared syntax (non-macro-expanded nodes are +considered to just have the "root" context, as described below). -- Many AST nodes have some sort of syntax context, especially nodes from macros. -- When we ask what is the syntax context of a node, the answer actually differs by what we are trying to do. Thus, we don't just keep track of a single context. There are in fact 3 different types of context used for different things. -- Each type of context is tracked by an "expansion heirarchy". As we expand macros, new macro calls or macro definitions may be generated, leading to some nesting. This nesting is where the heirarchies come from. Each heirarchy tracks some different aspect, though, as we will see. -- There are 3 expansion heirarchies - - All macros receive an integer ID assigned continuously starting from 0 as we discover new macro calls - - This is used as the `expn_id` where needed. - - All heirarchies start at ExpnId::root, which is its own parent - - The context of a node consists of a chain of expansions leading to `ExpnId::root`. A non-macro-expanded node has syntax context 0 (`SyntaxContext::empty()`) which represents just the root node. - - There are vectors in `HygieneData` that contain expansion info. - - There are entries here for both `SyntaxContext::empty()` and `ExpnId::root`, but they aren't used much. +Because macros invocations and definitions can be nested, the syntax context of +a node must be a heirarchy. For example, if we expand a macro and there is +another macro invocation or definition in the generated output, then the syntax +context should reflex the nesting. - 1. Tracks expansion order: when a macro invocation is in the output of another macro. - ... - expn_id2 - expn_id1 - InternalExpnData::parent is the child->parent link. That is the expn_id1 points to expn_id2 points to ... +However, it turns out that there are actually a few types of context we may +want to track for different purposes. Thus, there not just one but _three_ +expansion heirarchies that together comprise the hygiene information for a +crate. - Ex: - macro_rules! foo { () => { println!(); } } - fn main() { foo!(); } +All of these heirarchies need some sort of "macro ID" to identify individual +elements in the chain of expansions. This ID is [`ExpnId`]. All macros receive +an integer ID, assigned continuously starting from 0 as we discover new macro +calls. All heirarchies start at [`ExpnId::root()`][rootid], which is its own +parent. - // Then AST nodes that are finally generated would have parent(expn_id_println) -> parent(expn_id_foo), right? +The actual heirarchies are stored in [`HygieneData`][hd], and all of the +hygiene-related algorithms are implemented in [`rustc_span::hygiene`][hy], with +the exception of some hacks [`Resolver::resolve_crate_root`][hacks]. - 2. Tracks macro definitions: when we are expanding one macro another macro definition is revealed in its output. - ... - SyntaxContext2 - SyntaxContext1 - SyntaxContextData::parent is the child->parent link here. - SyntaxContext is the whole chain in this hierarchy, and SyntaxContextData::outer_expns are individual elements in the chain. +[`ExpnId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnId.html +[rootid]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnId.html#method.root +[hd]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.HygieneData.html +[hy]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/index.html +[hacks]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Resolver.html#method.resolve_crate_root - - For built-in macros (e.g. `line!()`) or stable proc macros: tokens produced by the macro are given the context `SyntaxContext::empty().apply_mark(expn_id)` - - Such macros are considered to have been defined at the root. - - For proc macros this is because they are always cross-crate and we don't have cross-crate hygiene implemented. +### The Expansion Order Heirarchy - The second hierarchy has the context transplantation hack. See https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732. +The first heirarchy tracks the order of expansions, i.e., when a macro +invocation is in the output of another macro. - If the token had context X before being produced by a macro then after being produced by the macro it has context X -> macro_id. +Here, the children in the heirarchy will be the "innermost" tokens. +[`ExpnData::parent`][edp] tracks the child -> parent link in this heirarchy. - Ex: - ```rust - macro m() { ident } - ``` +[edp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnData.html#structfield.parent - Here `ident` originally has context SyntaxContext::root(). `ident` has context ROOT -> id(m) after it's produced by m. - The "chaining operator" is `apply_mark` in compiler code. +For example, - Ex: +```rust,ignore +macro_rules! foo { () => { println!(); } } + +fn main() { foo!(); } +``` + +In this code, the AST nodes that are finally generated would have heirarchy: + +``` +root + expn_id_foo + expn_id_println +``` + +### The Macro Definition Heirarchy + +The second heirarchy tracks the order of macro definitions, i.e., when we are +expanding one macro another macro definition is revealed in its output. This +one is a bit tricky and more complex than the other two heirarchies. + +Here, [`SyntaxContextData::parent`][scdp] is the child -> parent link here. +[`SyntaxContext`][sc] is the whole chain in this hierarchy, and +[`SyntaxContextData::outer_expns`][scdoe] are individual elements in the chain. +The "chaining operator" is [`SyntaxContext::apply_mark`][am] in compiler code. + +[scdp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.SyntaxContextData.html#structfield.parent +[sc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.SyntaxContext.html +[scdoe]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.SyntaxContextData.html#structfield.outer_expn +[am]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.SyntaxContext.html#method.apply_mark + +For built-in macros, we use the context: +`SyntaxContext::empty().apply_mark(expn_id)`, and such macros are considered to +be defined at the heirarchy root. We do the same for proc-macros because we +haven't implemented cross-crate hygiene yet. + +If the token had context `X` before being produced by a macro then after being +produced by the macro it has context `X -> macro_id`. Here are some examples: + +Example 0: + +```rust,ignore +macro m() { ident } + +m!(); +``` + +Here `ident` originally has context [`SyntaxContext::root()`][scr]. `ident` has +context `ROOT -> id(m)` after it's produced by `m`. + +[scr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.SyntaxContext.html#method.root - ```rust - macro m() { macro n() { ident } } - ``` - In this example the ident has context ROOT originally, then ROOT -> id(m), then ROOT -> id(m) -> id(n). - Note that these chains are not entirely determined by their last element, in other words ExpnId is not isomorphic to SyntaxCtxt. +Example 1: - Ex: - ```rust - macro m($i: ident) { macro n() { ($i, bar) } } +```rust,ignore +macro m() { macro n() { ident } } + +m!(); +n!(); +``` +In this example the `ident` has context `ROOT` originally, then `ROOT -> id(m)` +after the first expansion, then `ROOT -> id(m) -> id(n)`. + +Example 2: + +Note that these chains are not entirely determined by their last element, in +other words `ExpnId` is not isomorphic to `SyntaxContext`. + +```rust,ignore +macro m($i: ident) { macro n() { ($i, bar) } } + +m!(foo); +``` + +After all expansions, `foo` has context `ROOT -> id(n)` and `bar` has context +`ROOT -> id(m) -> id(n)`. - m!(foo); - ``` +Finally, one last thing to mention is that currently, this heirarchy is subject +to the ["context transplantation hack"][hack]. Basically, the more modern (and +experimental) `macro` macros have stronger hygiene than the older MBE system, +but this can result in weird interactions between the two. The hack is intended +to make things "just work" for now. - After all expansions, foo has context ROOT -> id(n) and bar has context ROOT -> id(m) -> id(n) +[hack]: https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732 - 3. Call-site: tracks the location of the macro invocation. - Ex: - If foo!(bar!(ident)) expands into ident - then hierarchy 1 is root -> foo -> bar -> ident - but hierarchy 3 is root -> ident +### The Call-site Heirarchy - ExpnInfo::call_site is the child-parent link in this case. +The third and final heirarchy tracks the location of macro invocations. + +In this heirarchy [`ExpnData::call_site`][callsite] is the child -> parent link. + +[callsite]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnData.html#structfield.call_site + +Here is an example: + +```rust,ignore +macro bar($i: ident) { $i } +macro foo($i: ident) { $i } + +foo!(bar!(baz)); +``` -- Hygiene-related algorithms are entirely in hygiene.rs - - Some hacks in `resolve_crate_root`, though. +For the `baz` AST node in the final output, the first heirarchy is `ROOT -> +id(foo) -> id(bar) -> baz`, while the third heirarchy is `ROOT -> baz`. ## Producing Macro Output From a1cf766577c85c6df1838806ee2c43952f0d6739 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 20:49:46 -0500 Subject: [PATCH 0992/1812] sprinkle around a bunch of links --- src/macro-expansion.md | 122 ++++++++++++++++++++++++++++------------- 1 file changed, 85 insertions(+), 37 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 6bd809680..faf9bad45 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -55,15 +55,19 @@ iteration, this represents a compile error. Here is the [algorithm][original]: 1. Repeat until `queue` is empty (or we make no progress, which is an error): 0. [Resolve](./name-resolution.md) imports in our partially built crate as much as possible. - 1. Collect as many macro invocations as possible from our partially built - crate (fn-like, attributes, derives) and add them to the queue. + 1. Collect as many macro [`Invocation`s][inv] as possible from our + partially built crate (fn-like, attributes, derives) and add them to the + queue. 2. Dequeue the first element, and attempt to resolve it. 3. If it's resolved: - 0. Run the macro's expander function that consumes tokens or AST and - produces tokens or AST (depending on the macro kind). + 0. Run the macro's expander function that consumes a [`TokenStream`] or + AST and produces a [`TokenStream`] or [`AstFragment`] (depending on + the macro kind). (A `TokenStream` is a collection of [`TokenTrees`], + each of which are a token (punctuation, identifier, or literal) or a + delimited group (anything inside `()`/`[]`/`{}`)). - At this point, we know everything about the macro itself and can - call `set_expn_data` to fill in its properties in the global data - -- that is the hygiene data associated with `ExpnId`. (See [the + call `set_expn_data` to fill in its properties in the global data; + that is the hygiene data associated with `ExpnId`. (See [the "Hygiene" section below][hybelow]). 1. Integrate that piece of AST into the big existing partially built AST. This is essentially where the "token-like mass" becomes a @@ -94,6 +98,10 @@ iteration, this represents a compile error. Here is the [algorithm][original]: [`DefCollector`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/def_collector/struct.DefCollector.html [`BuildReducedGraphVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/build_reduced_graph/struct.BuildReducedGraphVisitor.html [hybelow]: #hygiene-and-heirarchies +[`TokenTree`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/enum.TokenTree.html +[`TokenStream`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html +[inv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.Invocation.html +[`AstFragment`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/enum.AstFragment.html If we make no progress in an iteration, then we have reached a compilation error (e.g. an undefined macro). We attempt to recover from failures @@ -110,6 +118,27 @@ macro names in the above algorithm. However, we don't try to resolve other names yet. This happens later, as we will see in the [next chapter](./name-resolution.md). +Here are some other notable data structures involved in expansion and integration: +- [`Resolver`] - a trait used to break crate dependencies. This allows the resolver services to be used in [`rustc_ast`], despite [`rustc_resolve`] and pretty much everything else depending on [`rustc_ast`]. +- [`ExtCtxt`]/[`ExpansionData`] - various intermediate data kept and used by expansion + infrastructure in the process of its work +- [`Annotatable`] - a piece of AST that can be an attribute target, almost same + thing as AstFragment except for types and patterns that can be produced by + macros but cannot be annotated with attributes +- [`MacResult`] - a "polymorphic" AST fragment, something that can turn into a + different `AstFragment` depending on its [`AstFragmentKind`] - item, + or expression, or pattern etc. + +[`rustc_ast`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html +[`rustc_resolve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/index.html +[`Resolver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.Resolver.html +[`ExtCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExtCtxt.html +[`ExpansionData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html +[`Annotatable`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/enum.Annotatable.html +[`MacResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.MacResult.html +[`AstFragmentKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/enum.AstFragmentKind.html + + ## Hygiene and Heirarchies If you have ever used C/C++ preprocessor macros, you know that there are some @@ -167,6 +196,10 @@ The context is attached to AST nodes. All AST nodes generated by macros have context attached. Additionally, there may be other nodes that have context attached, such as some desugared syntax (non-macro-expanded nodes are considered to just have the "root" context, as described below). +Throughout the compiler, we use [`Span`s][span] to refer to code locations. +This struct also has hygiene information attached to it, as we will see later. + +[span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html Because macros invocations and definitions can be nested, the syntax context of a node must be a heirarchy. For example, if we expand a macro and there is @@ -184,24 +217,33 @@ an integer ID, assigned continuously starting from 0 as we discover new macro calls. All heirarchies start at [`ExpnId::root()`][rootid], which is its own parent. -The actual heirarchies are stored in [`HygieneData`][hd], and all of the -hygiene-related algorithms are implemented in [`rustc_span::hygiene`][hy], with -the exception of some hacks [`Resolver::resolve_crate_root`][hacks]. +All of the hygiene-related algorithms are implemented in +[`rustc_span::hygiene`][hy], with the exception of some hacks +[`Resolver::resolve_crate_root`][hacks]. + +The actual heirarchies are stored in [`HygieneData`][hd]. This is a global +piece of data containing hygiene and expansion info that can be accessed from +any [`Ident`] without any context. + [`ExpnId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnId.html [rootid]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnId.html#method.root [hd]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.HygieneData.html [hy]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/index.html [hacks]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Resolver.html#method.resolve_crate_root +[`Ident`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Ident.html ### The Expansion Order Heirarchy The first heirarchy tracks the order of expansions, i.e., when a macro invocation is in the output of another macro. -Here, the children in the heirarchy will be the "innermost" tokens. +Here, the children in the heirarchy will be the "innermost" tokens. The +[`ExpnData`] struct itself contains a subset of properties from both macro +definition and macro call available through global data. [`ExpnData::parent`][edp] tracks the child -> parent link in this heirarchy. +[`ExpnData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnData.html [edp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnData.html#structfield.parent For example, @@ -226,11 +268,20 @@ The second heirarchy tracks the order of macro definitions, i.e., when we are expanding one macro another macro definition is revealed in its output. This one is a bit tricky and more complex than the other two heirarchies. -Here, [`SyntaxContextData::parent`][scdp] is the child -> parent link here. -[`SyntaxContext`][sc] is the whole chain in this hierarchy, and -[`SyntaxContextData::outer_expns`][scdoe] are individual elements in the chain. -The "chaining operator" is [`SyntaxContext::apply_mark`][am] in compiler code. +[`SyntaxContext`][sc] represents a whole chain in this hierarchy via an ID. +[`SyntaxContextData`][scd] contains data associated with the given +`SyntaxContext`; mostly it is a cache for results of filtering that chain in +different ways. [`SyntaxContextData::parent`][scdp] is the child -> parent +link here, and [`SyntaxContextData::outer_expns`][scdoe] are individual +elements in the chain. The "chaining operator" is +[`SyntaxContext::apply_mark`][am] in compiler code. + +A [`Span`][span], mentioned above, is actually just a compact representation of +a code location and `SyntaxContext`. Likewise, an [`Ident`] is just an interned +[`Symbol`] + `Span` (i.e. an interned string + hygiene data). +[`Symbol`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html +[scd]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.SyntaxContextData.html [scdp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.SyntaxContextData.html#structfield.parent [sc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.SyntaxContext.html [scdoe]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.SyntaxContextData.html#structfield.outer_expn @@ -323,6 +374,24 @@ There are two types of macros in Rust: Rust parser will set aside the contents of macros and their invocations. Later, macros are expanded using these portions of the code. +Some important data structures/interfaces here: +- [`SyntaxExtension`] - a lowered macro representation, contains its expander + function, which transforms a `TokenStream` or AST into another `TokenStream` + or AST + some additional data like stability, or a list of unstable features + allowed inside the macro. +- [`SyntaxExtensionKind`] - expander functions may have several different + signatures (take one token stream, or two, or a piece of AST, etc). This is + an enum that lists them. +- [`ProcMacro`]/[`TTMacroExpander`]/[`AttrProcMacro`]/[`MultiItemModifier`] - + traits representing the expander function signatures. + +[`SyntaxExtension`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.SyntaxExtension.html +[`SyntaxExtensionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/enum.SyntaxExtensionKind.html +[`ProcMacro`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.ProcMacro.html +[`TTMacroExpander`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.TTMacroExpander.html +[`AttrProcMacro`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.AttrProcMacro.html +[`MultiItemModifier`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.MultiItemModifier.html + ## Macros By Example MBEs have their own parser distinct from the normal Rust parser. When macros @@ -492,11 +561,10 @@ Custom derives are a special type of proc macro. TODO: more? -## Notes from petrochenkov discussion +## Important Modules and Data Structures -TODO: sprinkle these links around the chapter... +TODO: sprinkle these throughout the chapter as much as possible... -Where to find the code: - librustc_span/hygiene.rs - structures related to hygiene and expansion that are kept in global data (can be accessed from any Ident without any context) - librustc_span/lib.rs - some secondary methods like macro backtrace using primary methods from hygiene.rs - librustc_builtin_macros - implementations of built-in macros (including macro attributes and derives) and some other early code generation facilities like injection of standard library imports or generation of test harness. @@ -511,23 +579,3 @@ Where to find the code: - librustc_ast/ext/tt - implementation of macro_rules, turns macro_rules DSL into something with signature Fn(TokenStream) -> TokenStream that can eat and produce tokens, @mark-i-m knows more about this - librustc_resolve/macros.rs - resolving macro paths, validating those resolutions, reporting various "not found"/"found, but it's unstable"/"expected x, found y" errors - librustc_middle/hir/map/def_collector.rs + librustc_resolve/build_reduced_graph.rs - integrate an AST fragment freshly expanded from a macro into various parent/child structures like module hierarchy or "definition paths" - -Primary structures: -- HygieneData - global piece of data containing hygiene and expansion info that can be accessed from any Ident without any context -- ExpnId - ID of a macro call or desugaring (and also expansion of that call/desugaring, depending on context) -- ExpnInfo/InternalExpnData - a subset of properties from both macro definition and macro call available through global data -- SyntaxContext - ID of a chain of nested macro definitions (identified by ExpnIds) -- SyntaxContextData - data associated with the given SyntaxContext, mostly a cache for results of filtering that chain in different ways -- Span - a code location + SyntaxContext -- Ident - interned string (Symbol) + Span, i.e. a string with attached hygiene data -- TokenStream - a collection of TokenTrees -- TokenTree - a token (punctuation, identifier, or literal) or a delimited group (anything inside ()/[]/{}) -- SyntaxExtension - a lowered macro representation, contains its expander function transforming a tokenstream or AST into tokenstream or AST + some additional data like stability, or a list of unstable features allowed inside the macro. -- SyntaxExtensionKind - expander functions may have several different signatures (take one token stream, or two, or a piece of AST, etc), this is an enum that lists them -- ProcMacro/TTMacroExpander/AttrProcMacro/MultiItemModifier - traits representing the expander signatures (TODO: change and rename the signatures into something more consistent) -- Resolver - a trait used to break crate dependencies (so resolver services can be used in librustc_ast, despite librustc_resolve and pretty much everything else depending on librustc_ast) -- ExtCtxt/ExpansionData - various intermediate data kept and used by expansion infra in the process of its work -- AstFragment - a piece of AST that can be produced by a macro (may include multiple homogeneous AST nodes, like e.g. a list of items) -- Annotatable - a piece of AST that can be an attribute target, almost same thing as AstFragment except for types and patterns that can be produced by macros but cannot be annotated with attributes (TODO: Merge into AstFragment) -- MacResult - a "polymorphic" AST fragment, something that can turn into a different AstFragment depending on its context (aka AstFragmentKind - item, or expression, or pattern etc.) -- Invocation/InvocationKind - a structure describing a macro call, these structures are collected by the expansion infra (InvocationCollector), queued, resolved, expanded when resolved, etc. From bc9c0e6c35cd95bd232c93cbec97793073d163fb Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 21:22:25 -0500 Subject: [PATCH 0993/1812] SPRINKLE ALL THE THINGS --- src/macro-expansion.md | 88 ++++++++++++++++++++++++++---------------- src/the-parser.md | 3 +- 2 files changed, 57 insertions(+), 34 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index faf9bad45..5cd3c067e 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -4,14 +4,27 @@ > refactoring, so some of the links in this chapter may be broken. Rust has a very powerful macro system. In the previous chapter, we saw how the -parser sets aside macros to be expanded. This chapter is about the process of -expanding those macros iteratively until we have a complete AST for our crate -with no unexpanded macros (or a compile error). +parser sets aside macros to be expanded (it temporarily uses [placeholders]). +This chapter is about the process of expanding those macros iteratively until +we have a complete AST for our crate with no unexpanded macros (or a compile +error). + +[placeholders]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/placeholders/index.html First, we will discuss the algorithm that expands and integrates macro output into ASTs. Next, we will take a look at how hygiene data is collected. Finally, we will look at the specifics of expanding different types of macros. +Many of the algorithms and data structures described below are in [`rustc_expand`], +with basic data structures in [`rustc_expand::base`][base]. + +Also of note, `cfg` and `cfg_attr` are treated specially from other macros, and are +handled in [`rustc_expand::config`][cfg]. + +[`rustc_expand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/index.html +[base]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/index.html +[cfg]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/config/index.html + ## Expansion and AST Integration First of all, expansion happens at the crate level. Given a raw source code for @@ -24,10 +37,7 @@ method on a whole crate. If it is not run on a full crate, it means we are doing _eager macro expansion_. Eager expansion means that we expand the arguments of a macro invocation before the macro invocation itself. This is implemented only for a few special built-in macros that expect literals (it's -not a generally available feature of Rust). Eager expansion generally performs -a subset of the things that lazy (normal) expansion does, so we will focus on -lazy expansion for the rest of this chapter. - +not a generally available feature of Rust). As an example, consider the following: ```rust,ignore @@ -40,7 +50,16 @@ foo!(bar!(baz)); A lazy expansion would expand `foo!` first. An eager expansion would expand `bar!` first. Implementing eager expansion more generally would be challenging, but we implement it for a few special built-in macros for the sake of user -experience. +experience. The built-in macros are implemented in [`rustc_builtin_macros`], +along with some other early code generation facilities like injection of +standard library imports or generation of test harness. There are some +additional helpers for building their AST fragments in +[`rustc_expand::build`][reb]. Eager expansion generally performs a subset of +the things that lazy (normal) expansion does, so we will focus on lazy +expansion for the rest of this chapter. + +[`rustc_builtin_macros`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_builtin_macros/index.html +[reb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/build/index.html At a high level, [`fully_expand_fragment`][fef] works in iterations. We keep a queue of unresolved macro invocations (that is, macros we haven't found the @@ -114,10 +133,15 @@ fail at this point. The recovery happens by expanding unresolved macros into [err]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.ExprKind.html#variant.Err Notice that name resolution is involved here: we need to resolve imports and -macro names in the above algorithm. However, we don't try to resolve other -names yet. This happens later, as we will see in the [next +macro names in the above algorithm. This is done in +[`rustc_resolve::macros`][mresolve], which resolves macro paths, validates +those resolutions, and reports various errors (e.g. "not found" or "found, but +it's unstable" or "expected x, found y"). However, we don't try to resolve +other names yet. This happens later, as we will see in the [next chapter](./name-resolution.md). +[mresolve]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/macros/index.html + Here are some other notable data structures involved in expansion and integration: - [`Resolver`] - a trait used to break crate dependencies. This allows the resolver services to be used in [`rustc_ast`], despite [`rustc_resolve`] and pretty much everything else depending on [`rustc_ast`]. - [`ExtCtxt`]/[`ExpansionData`] - various intermediate data kept and used by expansion @@ -217,9 +241,9 @@ an integer ID, assigned continuously starting from 0 as we discover new macro calls. All heirarchies start at [`ExpnId::root()`][rootid], which is its own parent. -All of the hygiene-related algorithms are implemented in -[`rustc_span::hygiene`][hy], with the exception of some hacks -[`Resolver::resolve_crate_root`][hacks]. +[`rustc_span::hygiene`][hy] contains all of the hygiene-related algorithms +(with the exception of some hacks in [`Resolver::resolve_crate_root`][hacks]) +and structures related to hygiene and expansion that are kept in global data. The actual heirarchies are stored in [`HygieneData`][hd]. This is a global piece of data containing hygiene and expansion info that can be accessed from @@ -362,6 +386,13 @@ foo!(bar!(baz)); For the `baz` AST node in the final output, the first heirarchy is `ROOT -> id(foo) -> id(bar) -> baz`, while the third heirarchy is `ROOT -> baz`. +### Macro Backtraces + +Macro backtraces are implemented in [`rustc_span`] using the hygiene machinery +in [`rustc_span::hygiene`][hy]. + +[`rustc_span`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/index.html + ## Producing Macro Output Above, we saw how the output of a macro is integrated into the AST for a crate, @@ -551,7 +582,17 @@ stream, which is synthesized into the AST. It's worth noting that the token stream type used by proc macros is _stable_, so `rustc` does not use it internally (since our internal data structures are -unstable). +unstable). The compiler's token stream is +[`rustc_ast::tokenstream::TokenStream`][rustcts], as previously. This is +converted into the stable [`proc_macro::TokenStream`][stablets] and back in +[`rustc_expand::proc_macro`][pm] and [`rustc_expand::proc_macro_server`][pms]. +Because the Rust ABI is unstable, we use the C ABI for this conversion. + +[tsmod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/index.html +[rustcts]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html +[stablets]: https://doc.rust-lang.org/proc_macro/struct.TokenStream.html +[pm]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/proc_macro/index.html +[pms]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/proc_macro_server/index.html TODO: more here. @@ -560,22 +601,3 @@ TODO: more here. Custom derives are a special type of proc macro. TODO: more? - -## Important Modules and Data Structures - -TODO: sprinkle these throughout the chapter as much as possible... - -- librustc_span/hygiene.rs - structures related to hygiene and expansion that are kept in global data (can be accessed from any Ident without any context) -- librustc_span/lib.rs - some secondary methods like macro backtrace using primary methods from hygiene.rs -- librustc_builtin_macros - implementations of built-in macros (including macro attributes and derives) and some other early code generation facilities like injection of standard library imports or generation of test harness. -- librustc_ast/config.rs - implementation of cfg/cfg_attr (they treated specially from other macros), should probably be moved into librustc_ast/ext. -- librustc_ast/tokenstream.rs + librustc_ast/parse/token.rs - structures for compiler-side tokens, token trees, and token streams. -- librustc_ast/ext - various expansion-related stuff -- librustc_ast/ext/base.rs - basic structures used by expansion -- librustc_ast/ext/expand.rs - some expansion structures and the bulk of expansion infrastructure code - collecting macro invocations, calling into resolve for them, calling their expanding functions, and integrating the results back into AST -- librustc_ast/ext/placeholder.rs - the part of expand.rs responsible for "integrating the results back into AST" basicallly, "placeholder" is a temporary AST node replaced with macro expansion result nodes -- librustc_ast/ext/builer.rs - helper functions for building AST for built-in macros in librustc_builtin_macros (and user-defined syntactic plugins previously), can probably be moved into librustc_builtin_macros these days -- librustc_ast/ext/proc_macro.rs + librustc_ast/ext/proc_macro_server.rs - interfaces between the compiler and the stable proc_macro library, converting tokens and token streams between the two representations and sending them through C ABI -- librustc_ast/ext/tt - implementation of macro_rules, turns macro_rules DSL into something with signature Fn(TokenStream) -> TokenStream that can eat and produce tokens, @mark-i-m knows more about this -- librustc_resolve/macros.rs - resolving macro paths, validating those resolutions, reporting various "not found"/"found, but it's unstable"/"expected x, found y" errors -- librustc_middle/hir/map/def_collector.rs + librustc_resolve/build_reduced_graph.rs - integrate an AST fragment freshly expanded from a macro into various parent/child structures like module hierarchy or "definition paths" diff --git a/src/the-parser.md b/src/the-parser.md index c0f2a071b..da318c9ef 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -7,10 +7,11 @@ The very first thing the compiler does is take the program (in Unicode characters) and turn it into something the compiler can work with more conveniently than strings. This happens in two stages: Lexing and Parsing. -Lexing takes strings and turns them into streams of tokens. For example, +Lexing takes strings and turns them into streams of [tokens]. For example, `a.b + c` would be turned into the tokens `a`, `.`, `b`, `+`, and `c`. The lexer lives in [`librustc_lexer`][lexer]. +[tokens]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/token/index.html [lexer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html Parsing then takes streams of tokens and turns them into a structured From 5dedd70447c37afa2e461f5b941f824e9c3cdc99 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 22:41:58 -0500 Subject: [PATCH 0994/1812] fix line length --- src/macro-expansion.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 5cd3c067e..d8b5c392c 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -143,7 +143,9 @@ chapter](./name-resolution.md). [mresolve]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/macros/index.html Here are some other notable data structures involved in expansion and integration: -- [`Resolver`] - a trait used to break crate dependencies. This allows the resolver services to be used in [`rustc_ast`], despite [`rustc_resolve`] and pretty much everything else depending on [`rustc_ast`]. +- [`Resolver`] - a trait used to break crate dependencies. This allows the + resolver services to be used in [`rustc_ast`], despite [`rustc_resolve`] and + pretty much everything else depending on [`rustc_ast`]. - [`ExtCtxt`]/[`ExpansionData`] - various intermediate data kept and used by expansion infrastructure in the process of its work - [`Annotatable`] - a piece of AST that can be an attribute target, almost same From 7e916519ed9a340d57c10538b62bd06edeb17d94 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 30 Apr 2020 22:47:13 -0500 Subject: [PATCH 0995/1812] fix some links --- src/macro-expansion.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index d8b5c392c..50e4dc2a7 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -81,7 +81,7 @@ iteration, this represents a compile error. Here is the [algorithm][original]: 3. If it's resolved: 0. Run the macro's expander function that consumes a [`TokenStream`] or AST and produces a [`TokenStream`] or [`AstFragment`] (depending on - the macro kind). (A `TokenStream` is a collection of [`TokenTrees`], + the macro kind). (A `TokenStream` is a collection of [`TokenTree`s][tt], each of which are a token (punctuation, identifier, or literal) or a delimited group (anything inside `()`/`[]`/`{}`)). - At this point, we know everything about the macro itself and can @@ -110,14 +110,14 @@ iteration, this represents a compile error. Here is the [algorithm][original]: 0. Put the macro back in the queue 1. Continue to next iteration... -[defpaths]: https://rustc-dev-guide.rust-lang.org/hir.html?highlight=def,path#identifiers-in-the-hir +[defpath]: https://rustc-dev-guide.rust-lang.org/hir.html?highlight=def,path#identifiers-in-the-hir [`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html [`InvocationCollector`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.InvocationCollector.html [`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html [`DefCollector`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/def_collector/struct.DefCollector.html [`BuildReducedGraphVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/build_reduced_graph/struct.BuildReducedGraphVisitor.html [hybelow]: #hygiene-and-heirarchies -[`TokenTree`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/enum.TokenTree.html +[tt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/enum.TokenTree.html [`TokenStream`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html [inv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.Invocation.html [`AstFragment`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/enum.AstFragment.html From 2d639a3696f8329ffd3cc28b4fcc4bb729b18d1f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 2 May 2020 20:54:27 -0500 Subject: [PATCH 0996/1812] Typos Co-authored-by: Chris Simpkins --- src/macro-expansion.md | 48 +++++++++++++++++++++--------------------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 50e4dc2a7..a29f56b7c 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -93,7 +93,7 @@ iteration, this represents a compile error. Here is the [algorithm][original]: proper set-in-stone AST with side-tables. It happens as follows: - If the macro produces tokens (e.g. a proc macro), we parse into an AST, which may produce parse errors. - - During expansion, we create `SyntaxContext`s (heirarchy 2). (See + - During expansion, we create `SyntaxContext`s (hierarchy 2). (See [the "Hygiene" section below][hybelow]) - These three passes happen one after another on every AST fragment freshly expanded from a macro: @@ -116,7 +116,7 @@ iteration, this represents a compile error. Here is the [algorithm][original]: [`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html [`DefCollector`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/def_collector/struct.DefCollector.html [`BuildReducedGraphVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/build_reduced_graph/struct.BuildReducedGraphVisitor.html -[hybelow]: #hygiene-and-heirarchies +[hybelow]: #hygiene-and-hierarchies [tt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/enum.TokenTree.html [`TokenStream`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html [inv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.Invocation.html @@ -165,7 +165,7 @@ Here are some other notable data structures involved in expansion and integratio [`AstFragmentKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/enum.AstFragmentKind.html -## Hygiene and Heirarchies +## Hygiene and Hierarchies If you have ever used C/C++ preprocessor macros, you know that there are some annoying and hard-to-debug gotchas! For example, consider the following C code: @@ -228,26 +228,26 @@ This struct also has hygiene information attached to it, as we will see later. [span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html Because macros invocations and definitions can be nested, the syntax context of -a node must be a heirarchy. For example, if we expand a macro and there is +a node must be a hierarchy. For example, if we expand a macro and there is another macro invocation or definition in the generated output, then the syntax context should reflex the nesting. However, it turns out that there are actually a few types of context we may -want to track for different purposes. Thus, there not just one but _three_ -expansion heirarchies that together comprise the hygiene information for a +want to track for different purposes. Thus, there are not just one but _three_ +expansion hierarchies that together comprise the hygiene information for a crate. -All of these heirarchies need some sort of "macro ID" to identify individual +All of these hierarchies need some sort of "macro ID" to identify individual elements in the chain of expansions. This ID is [`ExpnId`]. All macros receive an integer ID, assigned continuously starting from 0 as we discover new macro -calls. All heirarchies start at [`ExpnId::root()`][rootid], which is its own +calls. All hierarchies start at [`ExpnId::root()`][rootid], which is its own parent. [`rustc_span::hygiene`][hy] contains all of the hygiene-related algorithms (with the exception of some hacks in [`Resolver::resolve_crate_root`][hacks]) and structures related to hygiene and expansion that are kept in global data. -The actual heirarchies are stored in [`HygieneData`][hd]. This is a global +The actual hierarchies are stored in [`HygieneData`][hd]. This is a global piece of data containing hygiene and expansion info that can be accessed from any [`Ident`] without any context. @@ -259,15 +259,15 @@ any [`Ident`] without any context. [hacks]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Resolver.html#method.resolve_crate_root [`Ident`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Ident.html -### The Expansion Order Heirarchy +### The Expansion Order Hierarchy -The first heirarchy tracks the order of expansions, i.e., when a macro +The first hierarchy tracks the order of expansions, i.e., when a macro invocation is in the output of another macro. -Here, the children in the heirarchy will be the "innermost" tokens. The +Here, the children in the hierarchy will be the "innermost" tokens. The [`ExpnData`] struct itself contains a subset of properties from both macro definition and macro call available through global data. -[`ExpnData::parent`][edp] tracks the child -> parent link in this heirarchy. +[`ExpnData::parent`][edp] tracks the child -> parent link in this hierarchy. [`ExpnData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnData.html [edp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnData.html#structfield.parent @@ -280,7 +280,7 @@ macro_rules! foo { () => { println!(); } } fn main() { foo!(); } ``` -In this code, the AST nodes that are finally generated would have heirarchy: +In this code, the AST nodes that are finally generated would have hierarchy: ``` root @@ -288,11 +288,11 @@ root expn_id_println ``` -### The Macro Definition Heirarchy +### The Macro Definition Hierarchy -The second heirarchy tracks the order of macro definitions, i.e., when we are +The second hierarchy tracks the order of macro definitions, i.e., when we are expanding one macro another macro definition is revealed in its output. This -one is a bit tricky and more complex than the other two heirarchies. +one is a bit tricky and more complex than the other two hierarchies. [`SyntaxContext`][sc] represents a whole chain in this hierarchy via an ID. [`SyntaxContextData`][scd] contains data associated with the given @@ -315,7 +315,7 @@ a code location and `SyntaxContext`. Likewise, an [`Ident`] is just an interned For built-in macros, we use the context: `SyntaxContext::empty().apply_mark(expn_id)`, and such macros are considered to -be defined at the heirarchy root. We do the same for proc-macros because we +be defined at the hierarchy root. We do the same for proc-macros because we haven't implemented cross-crate hygiene yet. If the token had context `X` before being produced by a macro then after being @@ -360,7 +360,7 @@ m!(foo); After all expansions, `foo` has context `ROOT -> id(n)` and `bar` has context `ROOT -> id(m) -> id(n)`. -Finally, one last thing to mention is that currently, this heirarchy is subject +Finally, one last thing to mention is that currently, this hierarchy is subject to the ["context transplantation hack"][hack]. Basically, the more modern (and experimental) `macro` macros have stronger hygiene than the older MBE system, but this can result in weird interactions between the two. The hack is intended @@ -368,11 +368,11 @@ to make things "just work" for now. [hack]: https://github.com/rust-lang/rust/pull/51762#issuecomment-401400732 -### The Call-site Heirarchy +### The Call-site Hierarchy -The third and final heirarchy tracks the location of macro invocations. +The third and final hierarchy tracks the location of macro invocations. -In this heirarchy [`ExpnData::call_site`][callsite] is the child -> parent link. +In this hierarchy [`ExpnData::call_site`][callsite] is the child -> parent link. [callsite]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/hygiene/struct.ExpnData.html#structfield.call_site @@ -385,8 +385,8 @@ macro foo($i: ident) { $i } foo!(bar!(baz)); ``` -For the `baz` AST node in the final output, the first heirarchy is `ROOT -> -id(foo) -> id(bar) -> baz`, while the third heirarchy is `ROOT -> baz`. +For the `baz` AST node in the final output, the first hierarchy is `ROOT -> +id(foo) -> id(bar) -> baz`, while the third hierarchy is `ROOT -> baz`. ### Macro Backtraces From 9c7befcdd8ad3bbe245cb4335f407dddad498d9f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 2 May 2020 21:09:44 -0500 Subject: [PATCH 0997/1812] Use full path of span Co-authored-by: Chris Simpkins --- src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index a29f56b7c..22895a68d 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -222,7 +222,7 @@ The context is attached to AST nodes. All AST nodes generated by macros have context attached. Additionally, there may be other nodes that have context attached, such as some desugared syntax (non-macro-expanded nodes are considered to just have the "root" context, as described below). -Throughout the compiler, we use [`Span`s][span] to refer to code locations. +Throughout the compiler, we use [`librustc_span::Span`s][span] to refer to code locations. This struct also has hygiene information attached to it, as we will see later. [span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html From 1f6d127a703349dbddbb8b6d3813a4c1dafec02f Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 2 May 2020 21:02:54 -0500 Subject: [PATCH 0998/1812] move discussion of eager expansion to the end --- src/macro-expansion.md | 60 ++++++++++++++++++++++-------------------- 1 file changed, 32 insertions(+), 28 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 22895a68d..aa6680f45 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -29,34 +29,10 @@ handled in [`rustc_expand::config`][cfg]. First of all, expansion happens at the crate level. Given a raw source code for a crate, the compiler will produce a massive AST with all macros expanded, all -modules inlined, etc. - -The primary entry point for this process is the -[`MacroExpander::fully_expand_fragment`][fef] method. Usually, we run this -method on a whole crate. If it is not run on a full crate, it means we are -doing _eager macro expansion_. Eager expansion means that we expand the -arguments of a macro invocation before the macro invocation itself. This is -implemented only for a few special built-in macros that expect literals (it's -not a generally available feature of Rust). -As an example, consider the following: - -```rust,ignore -macro bar($i: ident) { $i } -macro foo($i: ident) { $i } - -foo!(bar!(baz)); -``` - -A lazy expansion would expand `foo!` first. An eager expansion would expand -`bar!` first. Implementing eager expansion more generally would be challenging, -but we implement it for a few special built-in macros for the sake of user -experience. The built-in macros are implemented in [`rustc_builtin_macros`], -along with some other early code generation facilities like injection of -standard library imports or generation of test harness. There are some -additional helpers for building their AST fragments in -[`rustc_expand::build`][reb]. Eager expansion generally performs a subset of -the things that lazy (normal) expansion does, so we will focus on lazy -expansion for the rest of this chapter. +modules inlined, etc. The primary entry point for this process is the +[`MacroExpander::fully_expand_fragment`][fef] method. With few exceptions, we +use this method on the whole crate (see ["Eager Expansion"](#eager-expansion) +below for more detailed discussion of edge case expansion issues). [`rustc_builtin_macros`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_builtin_macros/index.html [reb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/build/index.html @@ -164,6 +140,34 @@ Here are some other notable data structures involved in expansion and integratio [`MacResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.MacResult.html [`AstFragmentKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/enum.AstFragmentKind.html +### Eager Expansion + +_Eager expansion_ means that we expand the arguments of a macro invocation +before the macro invocation itself. This is implemented only for a few special +built-in macros that expect literals; expanding arguments first for some of +these macro results in a smoother user experience. As an example, consider the +following: + +```rust,ignore +macro bar($i: ident) { $i } +macro foo($i: ident) { $i } + +foo!(bar!(baz)); +``` + +A lazy expansion would expand `foo!` first. An eager expansion would expand +`bar!` first. + +Eager expansion is not a generally available feature of Rust. Implementing +eager expansion more generally would be challenging, but we implement it for a +few special built-in macros for the sake of user experience. The built-in +macros are implemented in [`rustc_builtin_macros`], along with some other early +code generation facilities like injection of standard library imports or +generation of test harness. There are some additional helpers for building +their AST fragments in [`rustc_expand::build`][reb]. Eager expansion generally +performs a subset of the things that lazy (normal) expansion. It is done by +invoking [`fully_expand_fragment`][fef] on only part of a crate (as opposed to +whole crate, like we normally do). ## Hygiene and Hierarchies From d1bb1327803018cdec39ab113a163343fb1ab134 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 2 May 2020 21:10:14 -0500 Subject: [PATCH 0999/1812] add some section headers --- src/macro-expansion.md | 50 +++++++++++++++++++++++------------------- 1 file changed, 28 insertions(+), 22 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index aa6680f45..ea1240fc4 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -98,6 +98,8 @@ iteration, this represents a compile error. Here is the [algorithm][original]: [inv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.Invocation.html [`AstFragment`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/enum.AstFragment.html +### Error Recovery + If we make no progress in an iteration, then we have reached a compilation error (e.g. an undefined macro). We attempt to recover from failures (unresolved macros or imports) for the sake of diagnostics. This allows @@ -108,6 +110,8 @@ fail at this point. The recovery happens by expanding unresolved macros into [err]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.ExprKind.html#variant.Err +### Name Resolution + Notice that name resolution is involved here: we need to resolve imports and macro names in the above algorithm. This is done in [`rustc_resolve::macros`][mresolve], which resolves macro paths, validates @@ -118,28 +122,6 @@ chapter](./name-resolution.md). [mresolve]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/macros/index.html -Here are some other notable data structures involved in expansion and integration: -- [`Resolver`] - a trait used to break crate dependencies. This allows the - resolver services to be used in [`rustc_ast`], despite [`rustc_resolve`] and - pretty much everything else depending on [`rustc_ast`]. -- [`ExtCtxt`]/[`ExpansionData`] - various intermediate data kept and used by expansion - infrastructure in the process of its work -- [`Annotatable`] - a piece of AST that can be an attribute target, almost same - thing as AstFragment except for types and patterns that can be produced by - macros but cannot be annotated with attributes -- [`MacResult`] - a "polymorphic" AST fragment, something that can turn into a - different `AstFragment` depending on its [`AstFragmentKind`] - item, - or expression, or pattern etc. - -[`rustc_ast`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html -[`rustc_resolve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/index.html -[`Resolver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.Resolver.html -[`ExtCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExtCtxt.html -[`ExpansionData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html -[`Annotatable`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/enum.Annotatable.html -[`MacResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.MacResult.html -[`AstFragmentKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/enum.AstFragmentKind.html - ### Eager Expansion _Eager expansion_ means that we expand the arguments of a macro invocation @@ -169,6 +151,30 @@ performs a subset of the things that lazy (normal) expansion. It is done by invoking [`fully_expand_fragment`][fef] on only part of a crate (as opposed to whole crate, like we normally do). +### Other Data Structures + +Here are some other notable data structures involved in expansion and integration: +- [`Resolver`] - a trait used to break crate dependencies. This allows the + resolver services to be used in [`rustc_ast`], despite [`rustc_resolve`] and + pretty much everything else depending on [`rustc_ast`]. +- [`ExtCtxt`]/[`ExpansionData`] - various intermediate data kept and used by expansion + infrastructure in the process of its work +- [`Annotatable`] - a piece of AST that can be an attribute target, almost same + thing as AstFragment except for types and patterns that can be produced by + macros but cannot be annotated with attributes +- [`MacResult`] - a "polymorphic" AST fragment, something that can turn into a + different `AstFragment` depending on its [`AstFragmentKind`] - item, + or expression, or pattern etc. + +[`rustc_ast`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html +[`rustc_resolve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/index.html +[`Resolver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.Resolver.html +[`ExtCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExtCtxt.html +[`ExpansionData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html +[`Annotatable`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/enum.Annotatable.html +[`MacResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.MacResult.html +[`AstFragmentKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/enum.AstFragmentKind.html + ## Hygiene and Hierarchies If you have ever used C/C++ preprocessor macros, you know that there are some From b6d140f789bfd182734a9b5aaef41a094db15d01 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 8 May 2020 09:36:10 -0500 Subject: [PATCH 1000/1812] Typo Co-authored-by: Chris Simpkins --- src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index ea1240fc4..7961d0cf1 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -408,7 +408,7 @@ in [`rustc_span::hygiene`][hy]. ## Producing Macro Output Above, we saw how the output of a macro is integrated into the AST for a crate, -and we also saw how th e hygiene data for a crate is generated. But how do we +and we also saw how the hygiene data for a crate is generated. But how do we actually produce the output of a macro? It depends on the type of macro. There are two types of macros in Rust: From c386ec3d1acd6e0d58a7c9e5dac155000736b081 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 8 May 2020 10:40:35 -0500 Subject: [PATCH 1001/1812] Fix typo --- src/parallel-rustc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 66a692a91..add902d3a 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -34,7 +34,7 @@ However, there are two blockers: Here are some resources that can be used to learn more (note that some of them are a bit out of date): -- [This IRLO thread by Zoxc, when of the pioneers of the effort][irlo0] +- [This IRLO thread by Zoxc, one of the pioneers of the effort][irlo0] - [This list of interior mutability in the compiler by nikomatsakis][imlist] - [This IRLO thread by alexchricton about performance][irlo1] - [This tracking issue][tracking] From 1caba740639b2fc0ef9499d6fd98a026569342a7 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 11 May 2020 07:57:46 +0200 Subject: [PATCH 1002/1812] glossary: intro feels like not adding much (#699) --- src/appendix/glossary.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index a3b3826ea..c8738c998 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -1,9 +1,5 @@ # Appendix C: Glossary -The compiler uses a number of...idiosyncratic abbreviations and things. This -glossary attempts to list them and give you a few pointers for understanding -them better. - Term | Meaning -----------------------------------------|-------- arena/arena allocation
| An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. From 95420468b924825096dddc3438e65fee36ed0204 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 11 May 2020 14:51:33 -0500 Subject: [PATCH 1003/1812] fix links (#702) --- src/test-implementation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/test-implementation.md b/src/test-implementation.md index cffc62cec..a5ddd9135 100644 --- a/src/test-implementation.md +++ b/src/test-implementation.md @@ -147,7 +147,7 @@ $ rustc my_mod.rs -Z unpretty=hir [test]: https://doc.rust-lang.org/test/index.html [TestDesc]: https://doc.rust-lang.org/test/struct.TestDesc.html -[Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Ident.html -[Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Ident.html +[Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html +[Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Ident.html [eRFC]: https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md [librustc_ast]: https://github.com/rust-lang/rust/tree/master/src/librustc_ast From d7649f4b4415a96064933964e0063821113ecb4d Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sun, 10 May 2020 16:37:26 +0200 Subject: [PATCH 1004/1812] glossary: make soundness definition more readable --- src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index c8738c998..b89050034 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -63,7 +63,7 @@ rib
| A data structure in the name resolve sess
| The compiler session, which stores global data used throughout compilation side tables
| Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil
| Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -soundness
| A technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). +soundness
| A technical term in type theory. Roughly, if a type system is sound and a program type-checks, it is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span
| A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs
| The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). tcx
| The "typing context", main data structure of the compiler. ([see more](../ty.html)) From 8e126df6fe8f626d4c5d214d47f4ebea50fe4ba8 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 11 May 2020 07:56:48 +0200 Subject: [PATCH 1005/1812] Update src/appendix/glossary.md Co-authored-by: Who? Me?! --- src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index b89050034..d7cf30b91 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -63,7 +63,7 @@ rib
| A data structure in the name resolve sess
| The compiler session, which stores global data used throughout compilation side tables
| Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil
| Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -soundness
| A technical term in type theory. Roughly, if a type system is sound and a program type-checks, it is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). +soundness
| A technical term in type theory. Roughly, if a type system is sound, then a program that type-checks is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span
| A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs
| The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). tcx
| The "typing context", main data structure of the compiler. ([see more](../ty.html)) From 7fb45e52e9c13a876368e8a185b7b1463ea30c35 Mon Sep 17 00:00:00 2001 From: Jade McGough Date: Sat, 16 May 2020 18:19:52 -0700 Subject: [PATCH 1006/1812] Add missing closing paren (#705) --- src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 5171e5f31..16d3e1462 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -97,7 +97,7 @@ The result is that compiling `rustc` is done in stages: the symbol names used in the compiler source may not match the symbol names that would have been made by the stage1 compiler. This can be important when using dynamic linking (e.g., with - derives. Sometimes this means that some tests don't work when run + derives). Sometimes this means that some tests don't work when run with stage1. - **Stage 2:** we rebuild our stage1 compiler with itself to produce the stage2 compiler (i.e. it builds itself) to have all the _latest From 266ab6e3a9d601d42759fe2ae1e5ebb039fee7fe Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Mon, 18 May 2020 22:30:27 -0400 Subject: [PATCH 1007/1812] typo fix (#706) --- src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index ab36e428f..c68b76f03 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -35,7 +35,7 @@ LL | more code - The users' affected code and its surroundings. - Primary and secondary spans underlying the users' code. These spans can optionally contain one or more labels. - - Primary spans should have enough text to descrive the problem in such a + - Primary spans should have enough text to describe the problem in such a way that if it where the only thing being displayed (for example, in an IDE) it would still make sense. Because it is "spatially aware" (it points at the code), it can generally be more succinct than the error From 59c9fa7b3ed7d97d8d5ae4f03fa31f418decefbd Mon Sep 17 00:00:00 2001 From: Paul Daniel Faria Date: Sat, 23 May 2020 16:25:53 -0400 Subject: [PATCH 1008/1812] Fix BodyId link typo in glossary (#709) * Fix BodyId link typo in glossary * Fix broken link to rustc_middle's Predicate --- src/appendix/glossary.md | 2 +- src/memory.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index d7cf30b91..0b4aad658 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -5,7 +5,7 @@ Term | Meaning arena/arena allocation
| An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. AST
| The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. binder
| A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound). -BodyId
| An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). bound variable
| A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) codegen
| The code to translate MIR into LLVM IR. codegen unit
| When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) diff --git a/src/memory.md b/src/memory.md index 620b7d858..43b3746f0 100644 --- a/src/memory.md +++ b/src/memory.md @@ -50,7 +50,7 @@ allocate, and which are found in this module. Here are a few examples: [subst]: ./generic_arguments.html#subst [`TraitRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html -[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.Predicate.html +[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Predicate.html [`ty::TyS`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyS.html From d10f70b005f2bd9c458003e88cccebf720ca7229 Mon Sep 17 00:00:00 2001 From: Adam Perry Date: Sat, 23 May 2020 13:40:23 -0700 Subject: [PATCH 1009/1812] Extern blocks are allowed for #[track_caller] now. (#710) since https://github.com/rust-lang/rust/pull/70916 --- src/codegen/implicit-caller-location.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/codegen/implicit-caller-location.md b/src/codegen/implicit-caller-location.md index 5f11dad30..c6dc89f65 100644 --- a/src/codegen/implicit-caller-location.md +++ b/src/codegen/implicit-caller-location.md @@ -160,7 +160,6 @@ The `#[track_caller]` attribute is checked alongside other codegen attributes to function: * has the `"Rust"` ABI (as opposed to e.g., `"C"`) -* is not a foreign import (e.g., in an `extern {...}` block) * is not a closure * is not `#[naked]` From c2561c43510ae93fd4e51d35b6ceb87b10a14e5d Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 25 May 2020 17:23:15 +0900 Subject: [PATCH 1010/1812] Update docs related to const-eval/Miri (#676) * Update docs related to const-eval Co-authored-by: Ralf Jung --- src/const-eval.md | 41 ++++++++++++++++++++++++----------------- src/miri.md | 30 +++++++++++++++--------------- 2 files changed, 39 insertions(+), 32 deletions(-) diff --git a/src/const-eval.md b/src/const-eval.md index aaa2ed2d6..2a5c5d2f9 100644 --- a/src/const-eval.md +++ b/src/const-eval.md @@ -5,7 +5,7 @@ specific item (constant/static/array length) this happens after the MIR for the item is borrow-checked and optimized. In many cases trying to const evaluate an item will trigger the computation of its MIR for the first time. -Prominent examples are +Prominent examples are: * The initializer of a `static` * Array length @@ -20,19 +20,26 @@ Additionally constant evaluation can be used to reduce the workload or binary size at runtime by precomputing complex operations at compiletime and only storing the result. -Constant evaluation can be done by calling the `const_eval` query of `TyCtxt`. - -The `const_eval` query takes a [`ParamEnv`](./param_env.html) of environment in -which the constant is evaluated (e.g. the function within which the constant is -used) and a `GlobalId`. The `GlobalId` is made up of an -`Instance` referring to a constant or static or of an -`Instance` of a function and an index into the function's `Promoted` table. - -Constant evaluation returns a `Result` with either the error, or the simplest -representation of the constant. "simplest" meaning if it is representable as an -integer or fat pointer, it will directly yield the value (via `ConstValue::Scalar` or -`ConstValue::ScalarPair`), instead of referring to the [`miri`](./miri.html) virtual -memory allocation (via `ConstValue::ByRef`). This means that the `const_eval` -function cannot be used to create miri-pointers to the evaluated constant or -static. If you need that, you need to directly work with the functions in -[src/librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html). +Constant evaluation can be done by calling the `const_eval_*` functions of `TyCtxt`. +They're the wrappers of the `const_eval` query. + +The `const_eval_*` functions use a [`ParamEnv`](./param_env.html) of environment +in which the constant is evaluated (e.g. the function within which the constant is used) +and a [`GlobalId`]. The `GlobalId` is made up of an `Instance` referring to a constant +or static or of an `Instance` of a function and an index into the function's `Promoted` table. + +Constant evaluation returns a [`ConstEvalResult`] with either the error, or the a +representation of the constant. `static` initializers are always represented as +[`miri`](./miri.html) virtual memory allocations (via [`ConstValue::ByRef`]). +Other constants get represented as [`ConstValue::Scalar`] +or [`ConstValue::Slice`] if possible. This means that the `const_eval_*` +functions cannot be used to create miri-pointers to the evaluated constant. +If you need the value of a constant inside Miri, you need to directly work with +[`eval_const_to_op`]. + +[`GlobalId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.GlobalId.html +[`ConstValue::Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.Scalar +[`ConstValue::Slice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.Slice +[`ConstValue::ByRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.ByRef +[`ConstEvalResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/error/type.ConstEvalResult.html +[`eval_const_to_op`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#method.eval_const_to_op diff --git a/src/miri.md b/src/miri.md index 16f2a18f2..76996271d 100644 --- a/src/miri.md +++ b/src/miri.md @@ -1,9 +1,9 @@ # Miri Miri (**MIR** **I**nterpreter) is a virtual machine for executing MIR without -compiling to machine code. It is usually invoked via `tcx.const_eval`. +compiling to machine code. It is usually invoked via `tcx.const_eval_*` functions. -If you start out with a constant +If you start out with a constant: ```rust const FOO: usize = 1 << 12; @@ -12,7 +12,7 @@ const FOO: usize = 1 << 12; rustc doesn't actually invoke anything until the constant is either used or placed into metadata. -Once you have a use-site like +Once you have a use-site like: ```rust,ignore type Foo = [u8; FOO - 42]; @@ -35,17 +35,17 @@ Invoking `tcx.const_eval(param_env.and(gid))` will now trigger the creation of the MIR of the array length expression. The MIR will look something like this: ```mir -const Foo::{{initializer}}: usize = { - let mut _0: usize; // return pointer +Foo::{{constant}}#0: usize = { + let mut _0: usize; let mut _1: (usize, bool); bb0: { - _1 = CheckedSub(const Unevaluated(FOO, Slice([])), const 42usize); - assert(!(_1.1: bool), "attempt to subtract with overflow") -> bb1; + _1 = CheckedSub(const FOO, const 42usize); + assert(!move (_1.1: bool), "attempt to subtract with overflow") -> bb1; } bb1: { - _0 = (_1.0: usize); + _0 = move (_1.0: usize); return; } } @@ -55,16 +55,16 @@ Before the evaluation, a virtual memory location (in this case essentially a `vec![u8; 4]` or `vec![u8; 8]`) is created for storing the evaluation result. At the start of the evaluation, `_0` and `_1` are -`Operand::Immediate(Immediate::Scalar(ScalarMaybeUndef::Undef))`. This is quite +`Operand::Immediate(Immediate::Scalar(ScalarMaybeUndef::Undef))`. This is quite a mouthful: [`Operand`] can represent either data stored somewhere in the [interpreter memory](#memory) (`Operand::Indirect`), or (as an optimization) immediate data stored in-line. And [`Immediate`] can either be a single (potentially uninitialized) [scalar value][`Scalar`] (integer or thin pointer), -or a pair of two of them. In our case, the single scalar value is *not* (yet) +or a pair of two of them. In our case, the single scalar value is *not* (yet) initialized. When the initialization of `_1` is invoked, the value of the `FOO` constant is -required, and triggers another call to `tcx.const_eval`, which will not be shown +required, and triggers another call to `tcx.const_eval_*`, which will not be shown here. If the evaluation of FOO is successful, `42` will be subtracted from its value `4096` and the result stored in `_1` as `Operand::Immediate(Immediate::ScalarPair(Scalar::Raw { data: 4054, .. }, @@ -200,8 +200,8 @@ division on pointer values. ## Interpretation -Although the main entry point to constant evaluation is the `tcx.const_eval` -query, there are additional functions in +Although the main entry point to constant evaluation is the `tcx.const_eval_*` +functions, there are additional functions in [librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html) that allow accessing the fields of a `ConstValue` (`ByRef` or otherwise). You should never have to access an `Allocation` directly except for translating it to the @@ -217,7 +217,7 @@ A stack frame is defined by the `Frame` type in and contains all the local variables memory (`None` at the start of evaluation). Each frame refers to the evaluation of either the root constant or subsequent calls to `const fn`. The -evaluation of another constant simply calls `tcx.const_eval`, which produces an +evaluation of another constant simply calls `tcx.const_eval_*`, which produce an entirely new and independent stack frame. The frames are just a `Vec`, there's no way to actually refer to a @@ -229,4 +229,4 @@ Miri now calls the `step` method (in ) until it either returns an error or has no further statements to execute. Each statement will now initialize or modify the locals or the virtual memory referred to by a local. This might require evaluating other constants or -statics, which just recursively invokes `tcx.const_eval`. +statics, which just recursively invokes `tcx.const_eval_*`. From f53fc666ea2bd7d75d87ab083356358f7f1a1e18 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 27 May 2020 00:21:56 +0900 Subject: [PATCH 1011/1812] Rename `upvars` query to `upvars_mentioned` --- src/closure.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/closure.md b/src/closure.md index d4f9fc385..0f9b13965 100644 --- a/src/closure.md +++ b/src/closure.md @@ -115,9 +115,10 @@ Let's start with defining a term that we will be using quite a bit in the rest o *upvar*. An **upvar** is a variable that is local to the function where the closure is defined. So, in the above examples, **x** will be an upvar to the closure. They are also sometimes referred to as the *free variables* meaning they are not bound to the context of the closure. -[`src/librustc_middle/ty/query/mod.rs`][upvars] defines a query called *upvars* for this purpose. +[`src/librustc_middle/ty/query/mod.rs`][upvars] defines a query called *upvars_mentioned* +for this purpose. -[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/queries/struct.upvars.html +[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/queries/struct.upvars_mentioned.html Other than lazy invocation, one other thing that the distinguishes a closure from a normal function is that it can use the upvars. It borrows these upvars from its surrounding From 4295e7b578b15eec1a0a86495629b9dab420f057 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 27 May 2020 14:17:39 +0200 Subject: [PATCH 1012/1812] Add section for debugging rustc type layouts (#720) --- src/compiler-debugging.md | 59 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 780f5d871..a499224ae 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -274,3 +274,62 @@ try`. This is helpful when you want to examine the resulting build of a PR without doing the build yourself. [rtim]: https://github.com/kennytm/rustup-toolchain-install-master + +## Debugging type layouts + +The (permanently) unstable `#[rustc_layout]` attribute can be used to dump +the [`Layout`] of the type it is attached to. For example: + +```rust +#![feature(rustc_attrs)] + +#[rustc_layout(debug)] +type T<'a> = &'a u32; +``` + +Will emit the following: + +```text +error: layout_of(&'a u32) = Layout { + fields: Primitive, + variants: Single { + index: 0, + }, + abi: Scalar( + Scalar { + value: Pointer, + valid_range: 1..=18446744073709551615, + }, + ), + largest_niche: Some( + Niche { + offset: Size { + raw: 0, + }, + scalar: Scalar { + value: Pointer, + valid_range: 1..=18446744073709551615, + }, + }, + ), + align: AbiAndPrefAlign { + abi: Align { + pow2: 3, + }, + pref: Align { + pow2: 3, + }, + }, + size: Size { + raw: 8, + }, +} + --> src/lib.rs:4:1 + | +4 | type T<'a> = &'a u32; + | ^^^^^^^^^^^^^^^^^^^^^ + +error: aborting due to previous error +``` + +[`Layout`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/abi/struct.Layout.html From 6d5e0740f50bdd3f4ff23926193f387d36aa3072 Mon Sep 17 00:00:00 2001 From: Michael Bryan Date: Wed, 27 May 2020 23:04:56 +0800 Subject: [PATCH 1013/1812] It looks like the high-level-overview was renamed (#721) --- src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/query.md b/src/query.md index 4e795c6a2..be84fec54 100644 --- a/src/query.md +++ b/src/query.md @@ -10,7 +10,7 @@ the [def-id] of some item, will compute the type of that item and return it to you. [def-id]: appendix/glossary.md#def-id -[hl]: high-level-overview.html +[hl]: compiler-src.html Query execution is **memoized** – so the first time you invoke a query, it will go do the computation, but the next time, the result is From fe96650d1ad7eaba896bfb8cdc95daa4243dda3a Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 26 May 2020 18:21:46 -0700 Subject: [PATCH 1014/1812] Add some guidelines on the CLI. --- src/SUMMARY.md | 1 + src/cli.md | 29 +++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+) create mode 100644 src/cli.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 94768bc83..19afb765b 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -29,6 +29,7 @@ - [Emitting Errors and other Diagnostics](diagnostics.md) - [`LintStore`](./diagnostics/lintstore.md) - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) + - [Command-line arguments](./cli.md) - [ICE-breaker teams](ice-breaker/about.md) - ["Cleanup Crew" ICE-breakers](ice-breaker/cleanup-crew.md) - [LLVM ICE-breakers](ice-breaker/llvm.md) diff --git a/src/cli.md b/src/cli.md new file mode 100644 index 000000000..0e04b3818 --- /dev/null +++ b/src/cli.md @@ -0,0 +1,29 @@ +# Command-line Arguments + +Command-line flags are documented in the [rustc book][cli-docs]. All *stable* +flags should be documented there. Unstable flags should be documented in the +[unstable book]. + +## Guidelines + +- Flags should be orthogonal to each other. For example, if we'd have a + json-emitting variant of multiple actions `foo` and `bar`, an additional + `--json` flag is better than adding `--foo-json` and `--bar-json`. +- Avoid flags with the `no-` prefix. Instead, use the [`parse_bool`] function, + such as `-C embed-bitcode=no`. +- Consider the behavior if the flag is passed multiple times. In some + situations, the values should be accumulated (in order!). In other + situations, subsequence flags should override previous flags (for example, + the lint-level flags). And some flags (like `-o`) should generate an error + if it is too ambiguous what multiple flags would mean. +- Always give options a long descriptive name, if only for more understandable + compiler scripts. +- The `--verbose` flag is for adding verbose information to `rustc` output + when not compiling a program. For example, using it with the `--version` + flag gives information about the hashes of the code. +- Experimental flags and options must be guarded behind the `-Z + unstable-options` flag. + +[cli-docs]: https://doc.rust-lang.org/rustc/command-line-arguments.html +[unstable book]: https://doc.rust-lang.org/nightly/unstable-book/ +[`parse_bool`]: https://github.com/rust-lang/rust/blob/e5335592e78354e33d798d20c04bcd677c1df62d/src/librustc_session/options.rs#L307-L313 From ba1a8dfd35b32ee9352ef930809ceb7060fae2df Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 09:21:23 -0700 Subject: [PATCH 1015/1812] Apply suggestions from code review Co-authored-by: Chris Simpkins Co-authored-by: Who? Me?! --- src/cli.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/cli.md b/src/cli.md index 0e04b3818..bbb7bae24 100644 --- a/src/cli.md +++ b/src/cli.md @@ -13,14 +13,14 @@ flags should be documented there. Unstable flags should be documented in the such as `-C embed-bitcode=no`. - Consider the behavior if the flag is passed multiple times. In some situations, the values should be accumulated (in order!). In other - situations, subsequence flags should override previous flags (for example, + situations, subsequent flags should override previous flags (for example, the lint-level flags). And some flags (like `-o`) should generate an error if it is too ambiguous what multiple flags would mean. - Always give options a long descriptive name, if only for more understandable compiler scripts. - The `--verbose` flag is for adding verbose information to `rustc` output when not compiling a program. For example, using it with the `--version` - flag gives information about the hashes of the code. + flag gives information about the hashes of the compiler code. - Experimental flags and options must be guarded behind the `-Z unstable-options` flag. From 6e2b70c9dfca2b4c2443d47d4ba33195a1f92e97 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 09:24:53 -0700 Subject: [PATCH 1016/1812] Move CLI to part 3. --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 19afb765b..0a9dc7773 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -29,7 +29,6 @@ - [Emitting Errors and other Diagnostics](diagnostics.md) - [`LintStore`](./diagnostics/lintstore.md) - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) - - [Command-line arguments](./cli.md) - [ICE-breaker teams](ice-breaker/about.md) - ["Cleanup Crew" ICE-breakers](ice-breaker/cleanup-crew.md) - [LLVM ICE-breakers](ice-breaker/llvm.md) @@ -48,6 +47,7 @@ - [Parallel Compilation](./parallel-rustc.md) - [Part 3: Source Code Representations](./part-3-intro.md) + - [Command-line arguments](./cli.md) - [The Rustc Driver and Interface](./rustc-driver.md) - [Rustdoc](./rustdoc.md) - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) From 8bb723c6731005b2ede262b92aacfd83c0828571 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 27 May 2020 10:04:09 +0200 Subject: [PATCH 1017/1812] Add definition of `niche` to the glossary --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 0b4aad658..f2fdfe217 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -47,6 +47,7 @@ miri
| An interpreter for MIR used for cons monomorphization
| The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.html#normalizeprojection---type). newtype
| A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. +Niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types, like the `NonZero*` integers or the reference `&T` are invalid for certain bit patterns, in these cases a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant ellision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche to determine the `enum` variant without storing a discriminant. NLL
| Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId
| An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). obligation
| Something that must be proven by the trait system. ([see more](../traits/resolution.html)) From 54d64bd8ace120bbf490a4be357e4ab72752e688 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 27 May 2020 16:36:00 +0200 Subject: [PATCH 1018/1812] Fix typo Co-authored-by: Yuki Okushi --- src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index f2fdfe217..6f770a777 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -47,7 +47,7 @@ miri
| An interpreter for MIR used for cons monomorphization
| The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.html#normalizeprojection---type). newtype
| A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -Niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types, like the `NonZero*` integers or the reference `&T` are invalid for certain bit patterns, in these cases a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant ellision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche to determine the `enum` variant without storing a discriminant. +Niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types, like the `NonZero*` integers or the reference `&T` are invalid for certain bit patterns, in these cases a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche to determine the `enum` variant without storing a discriminant. NLL
| Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId
| An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). obligation
| Something that must be proven by the trait system. ([see more](../traits/resolution.html)) From aca2a716ea864009c7d69d34f0feb29c1edc8afa Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 27 May 2020 20:17:27 +0200 Subject: [PATCH 1019/1812] Apply suggestions from code review Co-authored-by: Who? Me?! --- src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 6f770a777..dddf628f2 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -47,7 +47,7 @@ miri
| An interpreter for MIR used for cons monomorphization
| The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.html#normalizeprojection---type). newtype
| A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -Niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types, like the `NonZero*` integers or the reference `&T` are invalid for certain bit patterns, in these cases a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche to determine the `enum` variant without storing a discriminant. +Niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche to determine the `enum` variant without storing a discriminant. NLL
| Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId
| An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). obligation
| Something that must be proven by the trait system. ([see more](../traits/resolution.html)) From 39edbe59ed172dd470d50f86558cb5380d6287d5 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 26 May 2020 18:20:47 -0700 Subject: [PATCH 1020/1812] Add some guidelines on diagnostics. --- src/diagnostics.md | 160 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 159 insertions(+), 1 deletion(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index c68b76f03..adcf598d5 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -3,7 +3,7 @@ A lot of effort has been put into making `rustc` have great error messages. This chapter is about how to emit compile errors and lints from the compiler. -## Diagnostic output style guide +## Diagnostic structure The main parts of a diagnostic error are the following: @@ -61,6 +61,163 @@ error: the fobrulator needs to be krontrificated When code or an identifier must appear in an message or label, it should be surrounded with single acute accents \`. +### Error explanations + +Some errors include long form descriptions. They may be viewed with the +`--explain` flag, or via the [error index]. Each explanation comes with an +example of how to trigger it and advice on how to fix it. + +Please read [RFC 1567] for details on how to format and write long error +codes. + +The descriptions are written in markdown, and all of them are linked in the +[`librustc_error_codes`] crate. + + + +[`librustc_error_codes`]: https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes.rs +[error index]: https://doc.rust-lang.org/error-index.html +[RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md + +### Lints versus fixed diagnostics + +Some messages are emitted via [lints](#lints), where the user can control the +level. Some are hard-coded such that the user cannot control the level. + +Hard-coded warnings should be avoided for normal code, preferring to use lints +instead. Some cases, such as warnings with CLI flags will require the use of +hard-coded warnings. + +See the `deny` [lint level](#diagnostic-levels) below for guidelines when to +use an error-level lint instead of a fixed error. + +## Diagnostic output style guide + +- Write in plain simple English. If your message, when shown on a – possibly + small – screen (which hasn't been cleaned for a while), cannot be understood + by a normal programmer, who just came out of bed after a night partying, + it's too complex. +- `Error`, `Warning`, `Note`, and `Help` messages start with a lowercase + letter and do not end with punctuation. +- Error messages should be succinct. Users will see these error messages many + times, and more verbose descriptions can be viewed with the `--explain` + flag. That said, don't make it so terse that it's hard to understand. +- The word "illegal" is illegal. Prefer "invalid" or a more specific word + instead. +- Errors should document the span of code where they occur – the `span_..` + methods allow to easily do this. Also `note` other spans that have + contributed to the error if the span isn't too large. +- When emitting a message with span, try to reduce the span to the smallest + amount possible that still signifies the issue +- Try not to emit multiple error messages for the same error. This may require + detecting duplicates. +- When the compiler has too little information for a specific error message, + lobby for annotations for library code that allow adding more. For example + see [`#[rustc_on_unimplemented]`](#rustc_on_unimplemented). Use these + annotations when available! +- Keep in mind that Rust's learning curve is rather steep, and that the + compiler messages are an important learning tool. +- When talking about the compiler, call it `the compiler`, not `Rust` or + `rustc`. + +### Lint naming + +From [RFC 0344], lint names should be consistent, with the following +guidelines: + +The basic rule is: the lint name should make sense when read as "allow +*lint-name*" or "allow *lint-name* items". For example, "allow +`deprecated` items" and "allow `dead_code`" makes sense, while "allow +`unsafe_block`" is ungrammatical (should be plural). + +- Lint names should state the bad thing being checked for, e.g. `deprecated`, + so that `#[allow(deprecated)]` (items) reads correctly. Thus `ctypes` is not + an appropriate name; `improper_ctypes` is. + +- Lints that apply to arbitrary items (like the stability lints) should just + mention what they check for: use `deprecated` rather than + `deprecated_items`. This keeps lint names short. (Again, think "allow + *lint-name* items".) + +- If a lint applies to a specific grammatical class, mention that class and + use the plural form: use `unused_variables` rather than `unused_variable`. + This makes `#[allow(unused_variables)]` read correctly. + +- Lints that catch unnecessary, unused, or useless aspects of code should use + the term `unused`, e.g. `unused_imports`, `unused_typecasts`. + +- Use snake case in the same way you would for function names. + +[RFC 0344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md#lints + +### Diagnostic levels + +Guidelines for different diagnostic levels: + +- `error`: emitted when the compiler detects a problem that makes it unable to + compile the program, either because the program is invalid or the programmer + has decided to make a specific `warning` into an error. + +- `warning`: emitted when the compiler detects something odd about a program. + Care should be taken when adding warnings to avoid warning fatigue, and + avoid false-positives where there really isn't a problem with the code. Some + examples of when it is appropriate to issue a warning: + + - A situation where the user *should* take action, such as swap out a + deprecated item, or use a `Result`, but otherwise doesn't prevent + compilation. + - Unnecessary syntax that can be removed without affecting the semantics of + the code. For example, unused code, or unnecessary `unsafe`. + - Code that is very likely to be incorrect, dangerous, or confusing, but the + language technically allows, and is not ready or confident enough to make + an error. For example `unused_comparisons` (out of bounds comparisons) or + `bindings_with_variant_name` (the user likely did not intend to create a + binding in a pattern). + - [Future-incompatible lints](#future-incompatible), where something was + accidentally or erroneously accepted in the past, but rejecting would + cause excessive breakage in the ecosystem. + - Stylistic choices. For example, camel or snake case, or the `dyn` trait + warning in the 2018 edition. These have a high bar to be added, and should + only be used in exceptional circumstances. Other stylistic choices should + either be allow-by-default lints, or part of other tools like Clippy or + rustfmt. + +- `help`: emitted following an `error` or `warning` to give additional + information to the user about how to solve their problem. The error or + warning portion should *not* suggest how to fix the problem, only the "help" + sub-diagnostic should. + +- `note`: emitted to identify additional circumstances and parts of the code + that caused the warning or error. For example, the borrow checker will note + any previous conflicting borrows. + +Not to be confused with *lint levels*, whose guidelines are: + +- `forbid`: Lints should never default to `forbid`. +- `deny`: Equivalent to `error` diagnostic level. Some examples: + + - A future-incompatible or edition-based lint that has graduated from the + warning level. + - Something that has an extremely high confidence that is incorrect, but + still want an escape hatch to allow it to pass. + +- `warn`: Equivalent to the `warning` diagnostic level. See `warning` above + for guidelines. +- `allow`: Examples of the kinds of lints that should default to `allow`: + + - The lint has a too high false positive rate. + - The lint is too opinionated. + - The lint is experimental. + - The lint is used for enforcing something that is not normally enforced. + For example, the `unsafe_code` lint can be used to prevent usage of unsafe + code. + +More information about lint levels can be found in the [rustc +book][rustc-lint-levels] and the [reference][reference-diagnostics]. + +[reference-diagnostics]: https://doc.rust-lang.org/nightly/reference/attributes/diagnostics.html#lint-check-attributes +[rustc-lint-levels]: https://doc.rust-lang.org/nightly/rustc/lints/levels.html + ## Helpful tips and options ### Finding the source of errors @@ -373,6 +530,7 @@ If you need a combination of options that's not supported by the `declare_lint!` macro, you can always define your own static with a type of `&Lint` but this is currently linted against in the compiler tree. + #### Guidelines for creating a future incompatibility lint - Create a lint defaulting to warn as normal, with ideally the same error From 1e8a467bc28a742960bcb4b5f7568f6bb384c9bd Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 09:26:28 -0700 Subject: [PATCH 1021/1812] Apply suggestions from code review Co-authored-by: Who? Me?! Co-authored-by: Chris Simpkins --- src/diagnostics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index adcf598d5..de081bb20 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -75,7 +75,7 @@ The descriptions are written in markdown, and all of them are linked in the -[`librustc_error_codes`]: https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes.rs +[`librustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html [error index]: https://doc.rust-lang.org/error-index.html [RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md @@ -104,7 +104,7 @@ use an error-level lint instead of a fixed error. flag. That said, don't make it so terse that it's hard to understand. - The word "illegal" is illegal. Prefer "invalid" or a more specific word instead. -- Errors should document the span of code where they occur – the `span_..` +- Errors should document the span of code where they occur – the `librustc_errors::diagnostic_builder::DiagnosticBuilder` `span_*` methods allow to easily do this. Also `note` other spans that have contributed to the error if the span isn't too large. - When emitting a message with span, try to reduce the span to the smallest From 4d94eb902ea894ccf26e57578608bcfc238e83ec Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 09:45:18 -0700 Subject: [PATCH 1022/1812] Updates from review. --- src/diagnostics.md | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index de081bb20..b85b198b0 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -73,7 +73,7 @@ codes. The descriptions are written in markdown, and all of them are linked in the [`librustc_error_codes`] crate. - +TODO: When should an error use an error code, and when shouldn't it? [`librustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html [error index]: https://doc.rust-lang.org/error-index.html @@ -82,11 +82,12 @@ The descriptions are written in markdown, and all of them are linked in the ### Lints versus fixed diagnostics Some messages are emitted via [lints](#lints), where the user can control the -level. Some are hard-coded such that the user cannot control the level. +level. Most diagnostics are hard-coded such that the user cannot control the +level. -Hard-coded warnings should be avoided for normal code, preferring to use lints -instead. Some cases, such as warnings with CLI flags will require the use of -hard-coded warnings. +Hard-coded warnings (those using the `span_warn` methods) should be avoided +for normal code, preferring to use lints instead. Some cases, such as warnings +with CLI flags, will require the use of hard-coded warnings. See the `deny` [lint level](#diagnostic-levels) below for guidelines when to use an error-level lint instead of a fixed error. @@ -104,7 +105,8 @@ use an error-level lint instead of a fixed error. flag. That said, don't make it so terse that it's hard to understand. - The word "illegal" is illegal. Prefer "invalid" or a more specific word instead. -- Errors should document the span of code where they occur – the `librustc_errors::diagnostic_builder::DiagnosticBuilder` `span_*` +- Errors should document the span of code where they occur – the + [`rustc_errors::diagnostic_builder::DiagnosticBuilder`][diagbuild] `span_*` methods allow to easily do this. Also `note` other spans that have contributed to the error if the span isn't too large. - When emitting a message with span, try to reduce the span to the smallest @@ -112,8 +114,9 @@ use an error-level lint instead of a fixed error. - Try not to emit multiple error messages for the same error. This may require detecting duplicates. - When the compiler has too little information for a specific error message, - lobby for annotations for library code that allow adding more. For example - see [`#[rustc_on_unimplemented]`](#rustc_on_unimplemented). Use these + consult with the compiler team to add new attributes for library code that + allow adding more information. For example see + [`#[rustc_on_unimplemented]`](#rustc_on_unimplemented). Use these annotations when available! - Keep in mind that Rust's learning curve is rather steep, and that the compiler messages are an important learning tool. @@ -183,9 +186,13 @@ Guidelines for different diagnostic levels: rustfmt. - `help`: emitted following an `error` or `warning` to give additional - information to the user about how to solve their problem. The error or - warning portion should *not* suggest how to fix the problem, only the "help" - sub-diagnostic should. + information to the user about how to solve their problem. These messages + often include a suggestion string and [`rustc_errors::Applicability`] + confidence level to guide automated source fixes by tools. See the + [Suggestions](#suggestions) section for more details. + + The error or warning portion should *not* suggest how to fix the problem, + only the "help" sub-diagnostic should. - `note`: emitted to identify additional circumstances and parts of the code that caused the warning or error. For example, the borrow checker will note @@ -215,6 +222,7 @@ Not to be confused with *lint levels*, whose guidelines are: More information about lint levels can be found in the [rustc book][rustc-lint-levels] and the [reference][reference-diagnostics]. +[`rustc_errors::Applicability`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/enum.Applicability.html [reference-diagnostics]: https://doc.rust-lang.org/nightly/reference/attributes/diagnostics.html#lint-check-attributes [rustc-lint-levels]: https://doc.rust-lang.org/nightly/rustc/lints/levels.html From d7067f19d2d2936816bbf6d01cc715f23168ee57 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 27 May 2020 15:18:47 -0700 Subject: [PATCH 1023/1812] Clarify lint vs fixed diagnostic. --- src/diagnostics.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/diagnostics.md b/src/diagnostics.md index b85b198b0..a9634ba63 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -85,6 +85,21 @@ Some messages are emitted via [lints](#lints), where the user can control the level. Most diagnostics are hard-coded such that the user cannot control the level. +Usually it is obvious whether a diagnostic should be "fixed" or a lint, but +there are some grey areas. + +Here are a few examples: + +- Borrow checker errors: these are fixed errors. The user cannot adjust the + level of these diagnostics to silence the borrow checker. +- Dead code: this is a lint. While the user probably doesn't want dead code in + their crate, making this a hard error would make refactoring and development + very painful. +- [safe_packed_borrows future compatibility warning][safe_packed_borrows]: + this is a silencable lint related to safety. It was judged that the making + this a hard (fixed) error would cause too much breakage, so instead a + warning is emitted that eventually will be turned into a hard error. + Hard-coded warnings (those using the `span_warn` methods) should be avoided for normal code, preferring to use lints instead. Some cases, such as warnings with CLI flags, will require the use of hard-coded warnings. @@ -92,6 +107,8 @@ with CLI flags, will require the use of hard-coded warnings. See the `deny` [lint level](#diagnostic-levels) below for guidelines when to use an error-level lint instead of a fixed error. +[safe_packed_borrows]: https://github.com/rust-lang/rust/issues/46043 + ## Diagnostic output style guide - Write in plain simple English. If your message, when shown on a – possibly From 6a54bc6dab9f968ad6b5b856e1f91c41bb5fa5f8 Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Thu, 28 May 2020 13:43:22 -0400 Subject: [PATCH 1024/1812] Expand error annotations section with examples (#724) * expand error annotations section with examples Co-authored-by: Yuki Okushi --- src/tests/adding.md | 67 +++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 64 insertions(+), 3 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index dadd8e2c1..e2a397a5b 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -193,15 +193,76 @@ source. Error annotations specify the errors that the compiler is expected to emit. They are "attached" to the line in source where the error is -located. +located. Error annotations are considered during tidy lints of line +length and should be formatted according to tidy requirements. + +The error annotation definition and source line definition association +is defined with the following set of idioms: * `~`: Associates the following error level and message with the current line * `~|`: Associates the following error level and message with the same line as the previous comment * `~^`: Associates the following error level and message with the - previous line. Each caret (`^`) that you add adds a line to this, so - `~^^^^^^^` is seven lines up. + previous error annotation line. Each caret (`^`) that you add adds + a line to this, so `~^^^` is three lines above the error annotation + line. + +### Error annotation examples + +Here are examples of error annotations on different lines of UI test +source. + +#### Positioned on error line + +Use the `//~ ERROR` idiom: + +```rust,ignore +fn main() { + let x = (1, 2, 3); + match x { + (_a, _x @ ..) => {} //~ ERROR `_x @` is not allowed in a tuple + _ => {} + } +} +``` + +#### Positioned below error line + +Use the `//~^` idiom with number of carets in the string to indicate the +number of lines above. In the example below, the error line is four +lines above the error annotation line so four carets are included in +the annotation. + +```rust,ignore +fn main() { + let x = (1, 2, 3); + match x { + (_a, _x @ ..) => {} // <- the error is on this line + _ => {} + } +} +//~^^^^ ERROR `_x @` is not allowed in a tuple +``` + +#### Use same error line as defined on error annotation line above + +Use the `//~|` idiom to define the same error line as +the error annotation line above: + +```rust,ignore +struct Binder(i32, i32, i32); + +fn main() { + let x = Binder(1, 2, 3); + match x { + Binder(_a, _x @ ..) => {} // <- the error is on this line + _ => {} + } +} +//~^^^^ ERROR `_x @` is not allowed in a tuple struct +//~| ERROR this pattern has 1 field, but the corresponding tuple struct has 3 fields [E0023] +``` The error levels that you can have are: From 8ca0464e6592805d08c31ce3f9193e200b2c085a Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Thu, 28 May 2020 16:16:34 -0400 Subject: [PATCH 1025/1812] add documentation of UI test error annotation substring support --- src/tests/adding.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index e2a397a5b..e20d7fdc1 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -194,7 +194,10 @@ source. Error annotations specify the errors that the compiler is expected to emit. They are "attached" to the line in source where the error is located. Error annotations are considered during tidy lints of line -length and should be formatted according to tidy requirements. +length and should be formatted according to tidy requirements. You may +use an error message prefix sub-string if necessary to meet line length +requirements. Make sure that the text is long enough for the error +message to be self-documenting. The error annotation definition and source line definition association is defined with the following set of idioms: From c9850bb7d2ca73a28b903fffecffabee61b336ec Mon Sep 17 00:00:00 2001 From: Chris Simpkins Date: Thu, 28 May 2020 17:10:21 -0400 Subject: [PATCH 1026/1812] Update src/tests/adding.md Co-authored-by: Yuki Okushi --- src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index e20d7fdc1..9dcb89326 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -196,7 +196,7 @@ emit. They are "attached" to the line in source where the error is located. Error annotations are considered during tidy lints of line length and should be formatted according to tidy requirements. You may use an error message prefix sub-string if necessary to meet line length -requirements. Make sure that the text is long enough for the error +requirements. Make sure that the text is long enough for the error message to be self-documenting. The error annotation definition and source line definition association From 55c92daeb6b31801224527f1653a49205b69d04b Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 29 May 2020 18:20:24 +0200 Subject: [PATCH 1027/1812] Document `RUSTFLAGS_STAGE_` bootstrap environment variables (#728) * Document `RUSTFLAGS_STAGE_` * Fix typos Co-authored-by: Yuki Okushi --- src/building/bootstrapping.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 5bdc8dc6f..5ba8ef88d 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -159,6 +159,16 @@ links against. This `stage2/bin/rustc` compiler is shipped to end-users, along with the `stage 1 {std,rustc}` artifacts. +## Passing stage-specific flags to `rustc` + +`x.py` allows you to pass stage-specific flags to `rustc` when bootstrapping. +The `RUSTFLAGS_STAGE_0`, `RUSTFLAGS_STAGE_1` and `RUSTFLAGS_STAGE_2` +environment variables pass the given flags when building stage 0, 1, and 2 +artifacts respectively. + +Additionally, the `RUSTFLAGS_STAGE_NOT_0` variable, as its name suggests, pass +the given arguments if the stage is not 0. + ## Environment Variables During bootstrapping, there are a bunch of compiler-internal environment From a6bace14e44c757e81605c4df7579d31cf289e80 Mon Sep 17 00:00:00 2001 From: Tom Eccles Date: Fri, 29 May 2020 14:18:52 +0100 Subject: [PATCH 1028/1812] Document remote testing --- src/tests/intro.md | 84 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 74 insertions(+), 10 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index fd0e50c83..2fa1363d0 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -147,10 +147,81 @@ the Docker image, run it, build Rust within the image, and run the tests. [src/ci/docker]: https://github.com/rust-lang/rust/tree/master/src/ci/docker [src/ci/docker/run.sh]: https://github.com/rust-lang/rust/blob/master/src/ci/docker/run.sh +## Running tests on a remote machine + +Tests may be run on a remote machine (e.g. to test builds for a different +architecture). This is done using `remote-test-client` on the build machine +to send test programs to `remote-test-server` running on the remote machine. +`remote-test-server` executes the test programs and sends the results back to +the build machine. `remote-test-server` provides *unauthenticated remote code +execution* so be careful where it is used. + +To do this, first build `remote-test-server` for the remote +machine, e.g. for RISC-V +```sh +./x.py build src/tools/remote-test-server --target riscv64gc-unknown-linux-gnu +``` + +The binary will be created at +`./build/$HOST_ARCH/stage2-tools/$TARGET_ARCH/release/remote-test-server`. Copy +this over to the remote machine. + +On the remote machine, run the `remote-test-server` with the `remote` argument +(and optionally `-v` for verbose output). Output should look like this: +```sh +$ ./remote-test-server -v remote +starting test server +listening on 0.0.0.0:12345! +``` + +You can test if the `remote-test-server` is working by connecting to it and +sending `ping\n`. It should reply `pong`: +```sh +$ nc $REMOTE_IP 12345 +ping +pong +``` + +To run tests using the remote runner, set the `TEST_DEVICE_ADDR` environment +variable then use `x.py` as usual. For example, to run `ui` tests for a RISC-V +machine with the IP address `1.2.3.4` use +```sh +export TEST_DEVICE_ADDR="1.2.3.4:12345" +./x.py test src/test/ui --target riscv64gc-unknown-linux-gnu +``` + +If `remote-test-server` was run with the verbose flag, output on the test machine +may look something like +``` +[...] +run "/tmp/work/test1007/a" +run "/tmp/work/test1008/a" +run "/tmp/work/test1009/a" +run "/tmp/work/test1010/a" +run "/tmp/work/test1011/a" +run "/tmp/work/test1012/a" +run "/tmp/work/test1013/a" +run "/tmp/work/test1014/a" +run "/tmp/work/test1015/a" +run "/tmp/work/test1016/a" +run "/tmp/work/test1017/a" +run "/tmp/work/test1018/a" +[...] +``` + +Tests are built on the machine running `x.py` not on the remote machine. Tests +which fail to build unexpectedly (or `ui` tests producing incorrect build +output) may fail without ever running on the remote machine. + ## Testing on emulators Some platforms are tested via an emulator for architectures that aren't -readily available. There is a set of tools for orchestrating running the +readily available. For architectures where the standard library is well +supported and the host operating system supports TCP/IP networking, see the +above instructions for testing on a remote machine (in this case the +remote machine is emulated). + +There is also a set of tools for orchestrating running the tests within the emulator. Platforms such as `arm-android` and `arm-unknown-linux-gnueabihf` are set up to automatically run the tests under emulation on Travis. The following will take a look at how a target's tests @@ -165,15 +236,8 @@ reading the results. The Docker image is set up to launch communicate with the server to coordinate running tests (see [src/bootstrap/test.rs]). -> TODO: What are the steps for manually running tests within an emulator? -> `./src/ci/docker/run.sh armhf-gnu` will do everything, but takes hours to -> run and doesn't offer much help with interacting within the emulator. -> -> Is there any support for emulating other (non-Android) platforms, such as -> running on an iOS emulator? -> -> Is there anything else interesting that can be said here about running tests -> remotely on real hardware? +> TODO: +> Is there any support for using an iOS emulator? > > It's also unclear to me how the wasm or asm.js tests are run. From 8a5438b4b150e2a952ad1bcbc2a1e3eb69e6a6bd Mon Sep 17 00:00:00 2001 From: Tom Eccles Date: Fri, 29 May 2020 15:01:42 +0100 Subject: [PATCH 1029/1812] Document more //ignore-X test headers --- src/tests/adding.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index 9dcb89326..15fff1ff3 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -134,6 +134,8 @@ Some examples of `X` in `ignore-X`: `musl`. * Pointer width: `32bit`, `64bit`. * Stage: `stage0`, `stage1`, `stage2`. +* When cross compiling: `cross-compile` +* When remote testing is used: `remote` ### Other Header Commands From b381598b3facd2d1d9f654d8b97d838f9f07d380 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 30 May 2020 08:49:25 +0900 Subject: [PATCH 1030/1812] Update lint declaration example (#713) --- src/diagnostics.md | 50 +++++++++++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 20 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index a9634ba63..428688fd3 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -457,7 +457,7 @@ crate. Every lint is implemented via a `struct` that implements the `LintPass` `trait` (you also implement one of the more specific lint pass traits, either -`EarlyLintPass` or `LateLintPass`). The trait implementation allows you to +`EarlyLintPass` or `LateLintPass`). The trait implementation allows you to check certain syntactic constructs as the linter walks the source code. You can then choose to emit lints in a very similar way to compile errors. @@ -482,35 +482,45 @@ declare_lint! { "suggest using `loop { }` instead of `while true { }`" } -// Define a struct and `impl LintPass` for it. -#[derive(Copy, Clone)] -pub struct WhileTrue; - -// This declares a lint pass, providing a list of associated lints. The +// This declares a struct and a lint pass, providing a list of associated lints. The // compiler currently doesn't use the associated lints directly (e.g., to not // run the pass or otherwise check that the pass emits the appropriate set of // lints). However, it's good to be accurate here as it's possible that we're // going to register the lints via the get_lints method on our lint pass (that // this macro generates). -impl_lint_pass!( - WhileTrue => [WHILE_TRUE], -); +declare_lint_pass!(WhileTrue => [WHILE_TRUE]); + +// Helper function for `WhileTrue` lint. +// Traverse through any amount of parenthesis and return the first non-parens expression. +fn pierce_parens(mut expr: &ast::Expr) -> &ast::Expr { + while let ast::ExprKind::Paren(sub) = &expr.kind { + expr = sub; + } + expr +} -// LateLintPass has lots of methods. We only override the definition of +// `EarlyLintPass` has lots of methods. We only override the definition of // `check_expr` for this lint because that's all we need, but you could // override other methods for your own lint. See the rustc docs for a full // list of methods. -impl<'a, 'tcx> LateLintPass<'a, 'tcx> for WhileTrue { - fn check_expr(&mut self, cx: &LateContext, e: &hir::Expr) { - if let hir::ExprWhile(ref cond, ..) = e.node { - if let hir::ExprLit(ref lit) = cond.node { - if let ast::LitKind::Bool(true) = lit.node { - if lit.span.ctxt() == SyntaxContext::empty() { +impl EarlyLintPass for WhileTrue { + fn check_expr(&mut self, cx: &EarlyContext<'_>, e: &ast::Expr) { + if let ast::ExprKind::While(cond, ..) = &e.kind { + if let ast::ExprKind::Lit(ref lit) = pierce_parens(cond).kind { + if let ast::LitKind::Bool(true) = lit.kind { + if !lit.span.from_expansion() { let msg = "denote infinite loops with `loop { ... }`"; - let condition_span = cx.tcx.sess.source_map().def_span(e.span); - let mut err = cx.struct_span_lint(WHILE_TRUE, condition_span, msg); - err.span_suggestion_short(condition_span, "use `loop`", "loop".to_owned()); - err.emit(); + let condition_span = cx.sess.source_map().guess_head_span(e.span); + cx.struct_span_lint(WHILE_TRUE, condition_span, |lint| { + lint.build(msg) + .span_suggestion_short( + condition_span, + "use `loop`", + "loop".to_owned(), + Applicability::MachineApplicable, + ) + .emit(); + }) } } } From 33fa72af752837295f0a5b1a10e2c21d2cb18a31 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 1 Jun 2020 20:48:29 -0500 Subject: [PATCH 1031/1812] Playing with travis images --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index df48ef6df..e6c5e431e 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,4 +1,5 @@ language: rust +dist: focal rust: - nightly cache: From 9c5a183b389c362f211ef44539ab74eea169ed2f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 1 Jun 2020 22:16:17 -0500 Subject: [PATCH 1032/1812] Update .travis.yml --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index e6c5e431e..e4a72f7c6 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,5 +1,5 @@ language: rust -dist: focal +dist: bionic rust: - nightly cache: From 37117d5ad6318f175b479101c8f349d585e19e24 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 2 Jun 2020 19:24:54 -0500 Subject: [PATCH 1033/1812] Make travis badge link to travis --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a6658b023..8f7db233e 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -![Travis CI badge](https://api.travis-ci.com/rust-lang/rustc-dev-guide.svg?branch=master) +[![Travis CI badge](https://api.travis-ci.com/rust-lang/rustc-dev-guide.svg?branch=master)](https://travis-ci.com/github/rust-lang/rustc-dev-guide) This is a collaborative effort to build a guide that explains how rustc From 2c2fb3f05faffec381f6b1eaed44caa044f78da0 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 3 Jun 2020 22:46:04 +0200 Subject: [PATCH 1034/1812] Add more info on useful workflows (#727) * Add more info on useful workflows * Apply suggestions from code review Co-authored-by: mark-i-m Co-authored-by: spastorino Co-authored-by: mark-i-m Co-authored-by: spastorino --- src/building/suggested.md | 69 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 64 insertions(+), 5 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index e9b48a7ef..4491a3b72 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -1,14 +1,39 @@ # Suggested Workflows -The full bootstrapping process takes quite a while. Here are three suggestions +The full bootstrapping process takes quite a while. Here are five suggestions to make your life easier. +## Configuring `rust-analyzer` for `rustc` + +`rust-analyzer` can help you check and format your code whenever you save +a file. By default, `rust-analyzer` runs the `cargo check` and `rustfmt` +commands, but you can override these commands to use more adapted versions +of these tools when hacking on `rustc`. For example, for Visual Studio Code, +you can write: + +```JSON +{ + "rust-analyzer.checkOnSave.overrideCommand": [ + "./x.py", + "check", + "--json-output" + ], + "rust-analyzer.rustfmt.overrideCommand": [ + "./build/TARGET_TRIPLE/stage0/bin/rustfmt" + ], + "editor.formatOnSave": true +} +``` + +in your `.vscode/settings.json` file. This will ask `rust-analyzer` to use +`x.py check` to check the sources, and the stage 0 rustfmt to format them. + ## Check, check, and check again -The first workflow, which is useful -when doing simple refactorings, is to run `./x.py check` -continuously. Here you are just checking that the compiler can -**build**, but often that is all you need (e.g., when renaming a +When doing simple refactorings, it can be useful to run `./x.py check` +continuously. If you set up `rust-analyzer` as described above, this will +be done for you every time you save a file. Here you are just checking that +the compiler can **build**, but often that is all you need (e.g., when renaming a method). You can then run `./x.py build` when you actually need to run tests. @@ -62,6 +87,40 @@ You can also use `--keep-stage 1` when running tests. Something like this: - Initial test run: `./x.py test -i --stage 1 src/test/ui` - Subsequent test run: `./x.py test -i --stage 1 src/test/ui --keep-stage 1` +## Working on multiple branches at the same time + +Working on multiple branches in parallel can be a little annoying, since +building the compiler on one branch will cause the old build and the +incremental compilation cache to be overwritten. One solution would be +to have multiple clones of the repository, but that would mean storing the +Git metadata multiple times, and having to update each clone individually. + +Fortunately, Git has a better solution called [worktrees]. This lets you +create multiple "working trees", which all share the same Git database. +Moreover, because all of the worktrees share the same object database, +if you update a branch (e.g. master) in any of them, you can use the new +commits from any of the worktrees. One caveat, though, is that submodules +do not get shared. They will still be cloned multiple times. + +[worktrees]: https://git-scm.com/docs/git-worktree + +Given you are inside the root directory for your rust repository, you can +create a "linked working tree" in a new "rust2" directory by running +the following command: + +```bash +git worktree add ../rust2 +``` + +Creating a new worktree for a new branch based on `master` looks like: + +```bash +git worktree add -b my-feature ../rust2 master +``` + +You can then use that rust2 folder as a separate workspace for modifying +and building `rustc`! + ## Building with system LLVM By default, LLVM is built from source, and that can take significant amount of From 7119767f69db663b9843107e7c4cd5d8c1895393 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 5 Jun 2020 10:10:01 -0500 Subject: [PATCH 1035/1812] Fix link (#734) --- src/appendix/background.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/appendix/background.md b/src/appendix/background.md index 50a550dc8..b688d2c75 100644 --- a/src/appendix/background.md +++ b/src/appendix/background.md @@ -133,7 +133,7 @@ does not. > recommendations, and to `tinaun` for posting a link to a [twitter thread from > Graydon Hoare](https://twitter.com/graydon_pub/status/1039615569132118016) > which had some more recommendations! -> +> > Other sources: https://gcc.gnu.org/wiki/ListOfCompilerBooks > > If you have other suggestions, please feel free to open an issue or PR. @@ -142,7 +142,7 @@ does not. - [Types and Programming Languages](https://www.cis.upenn.edu/~bcpierce/tapl/) - [Programming Language Pragmatics](https://www.cs.rochester.edu/~scott/pragmatics/) - [Practical Foundations for Programming Languages](https://www.cs.cmu.edu/~rwh/pfpl/2nded.pdf) -- [Compilers: Principles, Techniques, and Tools, 2nd Edition](https://www.amazon.com/dp/9332518661/ref=cm_sw_r_other_apa_1tUSBb5VHAVA1) +- [Compilers: Principles, Techniques, and Tools, 2nd Edition](https://www.pearson.com/us/higher-education/program/Aho-Compilers-Principles-Techniques-and-Tools-2nd-Edition/PGM167067.html) - [Garbage Collection: Algorithms for Automatic Dynamic Memory Management](https://www.cs.kent.ac.uk/people/staff/rej/gcbook/) - [Linkers and Loaders](https://linker.iecc.com/) - [Advanced Compiler Design and Implementation](https://www.goodreads.com/book/show/887908.Advanced_Compiler_Design_and_Implementation) @@ -160,4 +160,4 @@ does not. ## Misc Papers and Blog Posts - [Programming in Martin-Löf's Type Theory](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.118.6683&rep=rep1&type=pdf) -- [Polymorphism, Subtyping, and Type Inference in MLsub](https://www.cl.cam.ac.uk/~sd601/papers/mlsub-preprint.pdf) +- [Polymorphism, Subtyping, and Type Inference in MLsub](https://dl.acm.org/doi/10.1145/3093333.3009882) From 8f2e466f3c56250926fa7928753632fef1f175a7 Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Thu, 4 Jun 2020 14:34:11 +0200 Subject: [PATCH 1036/1812] words --- .../region_inference/placeholders_and_universes.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index eda8e6ff1..169f1b486 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -61,10 +61,9 @@ we swap the left and right here): ``` According to the basic subtyping rules for a reference, this will be -true if `'!1: 'static`. That is – if "some unknown region `!1`" lives -outlives `'static`. Now, this *might* be true – after all, `'!1` -could be `'static` – but we don't *know* that it's true. So this -should yield up an error (eventually). +true if `'!1: 'static`. That is – if "some unknown region `!1`" outlives `'static`. +Now, this *might* be true – after all, `'!1` could be `'static` – +but we don't *know* that it's true. So this should yield up an error (eventually). ## What is a universe? From 8c8130ed2d6a650260ecd859a3a5cfe9f3d4306b Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Fri, 5 Jun 2020 11:33:55 +0200 Subject: [PATCH 1037/1812] braces --- src/ty.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ty.md b/src/ty.md index 37f45cde1..6197a22be 100644 --- a/src/ty.md +++ b/src/ty.md @@ -29,7 +29,7 @@ In contrast, `ty::Ty` represents the semantics of a type, that is, the *meaning* wrote. For example, `rustc_hir::Ty` would record the fact that a user used the name `u32` twice in their program, but the `ty::Ty` would record the fact that both usages refer to the same type. -**Example: `fn foo(x: u32) → u32 { }`** In this function we see that `u32` appears twice. We know +**Example: `fn foo(x: u32) → u32 { x }`** In this function we see that `u32` appears twice. We know that that is the same type, i.e. the function takes an argument and returns an argument of the same type, but from the point of view of the HIR there would be two distinct type instances because these are occurring in two different places in the program. That is, they have two @@ -37,10 +37,10 @@ different [`Span`s][span] (locations). [span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html -**Example: `fn foo(x: &u32) -> &u32)`** In addition, HIR might have information left out. This type +**Example: `fn foo(x: &u32) -> &u32`** In addition, HIR might have information left out. This type `&u32` is incomplete, since in the full rust type there is actually a lifetime, but we didn’t need to write those lifetimes. There are also some elision rules that insert information. The result may -look like `fn foo<'a>(x: &'a u32) -> &'a u32)`. +look like `fn foo<'a>(x: &'a u32) -> &'a u32`. In the HIR level, these things are not spelled out and you can say the picture is rather incomplete. However, at the `ty::Ty` level, these details are added and it is complete. Moreover, we will have From 8a9a1f935ffc34b385b1888b02841220faeb9ee8 Mon Sep 17 00:00:00 2001 From: Bastian Kauschke Date: Fri, 5 Jun 2020 18:06:39 +0200 Subject: [PATCH 1038/1812] update conventions (#735) * update conventions * typo Co-authored-by: Santiago Pastorino Co-authored-by: Santiago Pastorino --- src/conventions.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index 3f957cc27..b9001ee0b 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -7,14 +7,18 @@ chapter covers [formatting](#formatting), [coding for correctness](#cc), # Formatting and the tidy script -rustc is slowly moving towards the [Rust standard coding style][fmt]; -at the moment, however, it follows a rather more *chaotic* style. We -do have some mandatory formatting conventions, which are automatically -enforced by a script we affectionately call the "tidy" script. The -tidy script runs automatically when you do `./x.py test` and can be run +rustc is moving towards the [Rust standard coding style][fmt]. +This is enforced by the "tidy" script and can be mostly +automated using `./x.py fmt`. + +As the output of [rustfmt] is not completely stable, +formatting this repository using `cargo fmt` is not recommended. + +The tidy script runs automatically when you do `./x.py test` and can be run in isolation with `./x.py test tidy`. [fmt]: https://github.com/rust-dev-tools/fmt-rfcs +[rustfmt]:https://github.com/rust-lang/rustfmt @@ -114,12 +118,9 @@ you introduce some code following one strategy, then change it dramatically (versus adding to it) in a later commit, that 'back-and-forth' can be confusing. -**Only run rustfmt on new content.** One day, we might enforce formatting -for the rust-lang/rust repo. Meanwhile, we prefer that rustfmt not be run -on existing code as that will generate large diffs and will make git blame -harder to sift through. However, running `rustfmt` on new content, e.g. a -new file or a largely new part of a file is ok. Small formatting adjustments -nearby code you are already changing for other purposes are also ok. +**Format liberally.** While only the final commit of a PR must be correctly +formatted, it is both easier to review and less noisy to format each commit +individually using `./x.py fmt`. **No merges.** We do not allow merge commits into our history, other than those by bors. If you get a merge conflict, rebase instead via a From caac584a9e883c47a5fac538d1828ef9bbbf865f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 5 Jun 2020 11:11:09 -0500 Subject: [PATCH 1039/1812] Add a bit about various type system concepts (#697) * add a bit on dataflow analysis * add a bit on quanitification * add a bit on debruijn index * add a bit on early and late bound params * add missing link * Typos Co-authored-by: Tshepang Lekhonkhobe * clarify dataflow example * fix formatting * fix typos * Typos Co-authored-by: Tshepang Lekhonkhobe * fix errors in background * remove dup material and make early/late intro short * adjust intro * Niko's intro Co-authored-by: Niko Matsakis Co-authored-by: Tshepang Lekhonkhobe Co-authored-by: Niko Matsakis --- src/SUMMARY.md | 1 + src/appendix/background.md | 146 ++++++++++++++++++++++++++++++++++++- src/appendix/glossary.md | 1 + src/early-late-bound.md | 107 +++++++++++++++++++++++++++ 4 files changed, 253 insertions(+), 2 deletions(-) create mode 100644 src/early-late-bound.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 0a9dc7773..f45e8ba96 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -76,6 +76,7 @@ - [Generic arguments](./generic_arguments.md) - [Type inference](./type-inference.md) - [Trait solving](./traits/resolution.md) + - [Early and Late Bound Parameters](./early-late-bound.md) - [Higher-ranked trait bounds](./traits/hrtb.md) - [Caching subtleties](./traits/caching.md) - [Specialization](./traits/specialization.md) diff --git a/src/appendix/background.md b/src/appendix/background.md index b688d2c75..fe69f6bfd 100644 --- a/src/appendix/background.md +++ b/src/appendix/background.md @@ -79,16 +79,158 @@ cycle. [*Static Program Analysis*](https://cs.au.dk/~amoeller/spa/) by Anders Møller and Michael I. Schwartzbach is an incredible resource! -*to be written* +_Dataflow analysis_ is a type of static analysis that is common in many +compilers. It describes a general technique, rather than a particular analysis. + +The basic idea is that we can walk over a [CFG](#cfg) and keep track of what +some value could be. At the end of the walk, we might have shown that some +claim is true or not necessarily true (e.g. "this variable must be +initialized"). `rustc` tends to do dataflow analyses over the MIR, since that +is already a CFG. + +For example, suppose we want to check that `x` is initialized before it is used +in this snippet: + +```rust,ignore +fn foo() { + let mut x; + + if some_cond { + x = 1; + } + + dbg!(x); +} +``` + +A CFG for this code might look like this: + +```txt + +------+ + | Init | (A) + +------+ + | \ + | if some_cond + else \ +-------+ + | \| x = 1 | (B) + | +-------+ + | / + +---------+ + | dbg!(x) | (C) + +---------+ +``` + +We can do the dataflow analysis as follows: we will start off with a flag `init` +which indicates if we know `x` is initialized. As we walk the CFG, we will +update the flag. At the end, we can check its value. + +So first, in block (A), the variable `x` is declared but not initialized, so +`init = false`. In block (B), we initialize the value, so we know that `x` is +initialized. So at the end of (B), `init = true`. + +Block (C) is where things get interesting. Notice that there are two incoming +edges, one from (A) and one from (B), corresponding to whether `some_cond` is true or not. +But we cannot know that! It could be the case the `some_cond` is always true, +so that `x` is actually always initialized. It could also be the case that +`some_cond` depends on something random (e.g. the time), so `x` may not be +initialized. In general, we cannot know statically (due to [Rice's +Theorem][rice]). So what should the value of `init` be in block (C)? + +[rice]: https://en.wikipedia.org/wiki/Rice%27s_theorem + +Generally, in dataflow analyses, if a block has multiple parents (like (C) in +our example), its dataflow value will be some function of all its parents (and +of course, what happens in (C)). Which function we use depends on the analysis +we are doing. + +In this case, we want to be able to prove definitively that `x` must be +initialized before use. This forces us to be conservative and assume that +`some_cond` might be false sometimes. So our "merging function" is "and". That +is, `init = true` in (C) if `init = true` in (A) _and_ in (B) (or if `x` is +initialized in (C)). But this is not the case; in particular, `init = false` in +(A), and `x` is not initialized in (C). Thus, `init = false` in (C); we can +report an error that "`x` may not be initialized before use". + +There is definitely a lot more that can be said about dataflow analyses. There is an +extensive body of research literature on the topic, including a lot of theory. +We only discussed a forwards analysis, but backwards dataflow analysis is also +useful. For example, rather than starting from block (A) and moving forwards, +we might have started with the usage of `x` and moved backwards to try to find +its initialization. ## What is "universally quantified"? What about "existentially quantified"? -*to be written* +In math, a predicate may be _universally quantified_ or _existentially +quantified_: + +- _Universal_ quantification: + - the predicate holds if it is true for all possible inputs. + - Traditional notation: ∀x: P(x). Read as "for all x, P(x) holds". +- _Existential_ quantification: + - the predicate holds if there is any input where it is true, i.e., there + only has to be a single input. + - Traditional notation: ∃x: P(x). Read as "there exists x such that P(x) holds". + +In Rust, they come up in type checking and trait solving. For example, + +```rust,ignore +fn foo() +``` +This function claims that the function is well-typed for all types `T`: `∀ T: well_typed(foo)`. + +Another example: + +```rust,ignore +fn foo<'a>(_: &'a usize) +``` +This function claims that for any lifetime `'a` (determined by the +caller), it is well-typed: `∀ 'a: well_typed(foo)`. + +Another example: + +```rust,ignore +fn foo() +where for<'a> F: Fn(&'a u8) +``` +This function claims that it is well-typed for all types `F` such that for all +lifetimes `'a`, `F: Fn(&'a u8)`: `∀ F: ∀ 'a: (F: Fn(&'a u8)) => well_typed(foo)`. + +One more example: + +```rust,ignore +fn foo(_: dyn Debug) +``` +This function claims that there exists some type `T` that implements `Debug` +such that the function is well-typed: `∃ T: (T: Debug) and well_typed(foo)`. +## What is a DeBruijn Index? + +DeBruijn indices are a way of representing which variables are bound in +which binders using only integers. They were [originally invented][wikideb] for +use in lambda calculus evaluation. In `rustc`, we use a similar idea for the +[representation of generic types][sub]. + +[wikideb]: https://en.wikipedia.org/wiki/De_Bruijn_index +[sub]: ../generics.md + +Here is a basic example of how DeBruijn indices might be used for closures (we +don't actually do this in `rustc` though): + +```rust,ignore +|x| { + f(x) // de Bruijn index of `x` is 1 because `x` is bound 1 level up + + |y| { + g(x, y) // index of `x` is 2 because it is bound 2 levels up + // index of `y` is 1 because it is bound 1 level up + } +} +``` + ## What is co- and contra-variance? Check out the subtyping chapter from the diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index dddf628f2..f8042170c 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -15,6 +15,7 @@ CTFE
| Short for Compile-Time Function Eval cx
| We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. DAG
| A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) data-flow analysis
| A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). +DeBruijn Index
| A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#debruijn)) DefId
| An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). Double pointer
| A pointer with additional metadata. See "fat pointer" for more. drop glue
| (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. diff --git a/src/early-late-bound.md b/src/early-late-bound.md new file mode 100644 index 000000000..a703cbab5 --- /dev/null +++ b/src/early-late-bound.md @@ -0,0 +1,107 @@ +# Early and Late Bound Variables + +In Rust, item definitions (like `fn`) can often have generic parameters, which +are always [_universally_ quantified][quant]. That is, if you have a function +like + +```rust +fn foo(x: T) { } +``` + +this function is defined "for all T" (not "for some specific T", which would be +[_existentially_ quantified][quant]). + +[quant]: ./appendix/background.md#quantified + +While Rust *items* can be quantified over types, lifetimes, and constants, the +types of values in Rust are only ever quantified over lifetimes. So you can +have a type like `for<'a> fn(&'a u32)`, which represents a function pointer +that takes a reference with any lifetime, or `for<'a> dyn Trait<'a>`, which is +a `dyn` trait for a trait implemented for any lifetime; but we have no type +like `for fn(T)`, which would be a function that takes a value of *any type* +as a parameter. This is a consequence of monomorphization -- to support a value +of type `for fn(T)`, we would need a single function pointer that can be +used for a parameter of any type, but in Rust we generate customized code for +each parameter type. + +One consequence of this asymmetry is a weird split in how we represesent some +generic types: _early-_ and _late-_ bound parameters. +Basically, if we cannot represent a type (e.g. a universally quantified type), +we have to bind it _early_ so that the unrepresentable type is never around. + +Consider the following example: + +```rust,ignore +fn foo<'a, 'b, T>(x: &'a u32, y: &'b T) where T: 'b { ... } +``` + +We cannot treat `'a`, `'b`, and `T` in the same way. Types in Rust can't have +`for { .. }`, only `for<'a> {...}`, so whenever you reference `foo` the type +you get back can't be `for<'a, 'b, T> fn(&'a u32, y: &'b T)`. Instead, the `T` +must be substituted early. In particular, you have: + +```rust,ignore +let x = foo; // T, 'b have to be substituted here +x(...); // 'a substituted here, at the point of call +x(...); // 'a substituted here with a different value +``` + +## Early-bound parameters + +Early-bound parameters in rustc are identified by an index, stored in the +[`ParamTy`] struct for types or the [`EarlyBoundRegion`] struct for lifetimes. +The index counts from the outermost declaration in scope. This means that as you +add more binders inside, the index doesn't change. + +For example, + +```rust,ignore +trait Foo { + type Bar = (Self, T, U); +} +``` + +Here, the type `(Self, T, U)` would be `($0, $1, $2)`, where `$N` means a +[`ParamTy`] with the index of `N`. + +In rustc, the [`Generics`] structure carries the this information. So the +[`Generics`] for `Bar` above would be just like for `U` and would indicate the +'parent' generics of `Foo`, which declares `Self` and `T`. You can read more +in [this chapter](./generics.md). + +[`ParamTy`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamTy.html +[`EarlyBoundRegion`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.EarlyBoundRegion.html +[`Generics`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Generics.html + +## Late-bound parameters + +Late-bound parameters in `rustc` are handled quite differently (they are also +specialized to lifetimes since, right now, only late-bound lifetimes are +supported, though with GATs that has to change). We indicate their potential +presence by a [`Binder`] type. The [`Binder`] doesn't know how many variables +there are at that binding level. This can only be determined by walking the +type itself and collecting them. So a type like `for<'a, 'b> ('a, 'b)` would be +`for (^0.a, ^0.b)`. Here, we just write `for` because we don't know the names +of the things bound within. + +Moreover, a reference to a late-bound lifetime is written `^0.a`: + +- The `0` is the index; it identifies that this lifetime is bound in the + innermost binder (the `for`). +- The `a` is the "name"; late-bound lifetimes in rustc are identified by a + "name" -- the [`BoundRegion`] struct. This struct can contain a + [`DefId`][defid] or it might have various "anonymous" numbered names. The + latter arise from types like `fn(&u32, &u32)`, which are equivalent to + something like `for<'a, 'b> fn(&'a u32, &'b u32)`, but the names of those + lifetimes must be generated. + +This setup of not knowing the full set of variables at a binding level has some +advantages and some disadvantages. The disadvantage is that you must walk the +type to find out what is bound at the given level and so forth. The advantage +is primarily that, when constructing types from Rust syntax, if we encounter +anonymous regions like in `fn(&u32)`, we just create a fresh index and don't have +to update the binder. + +[`Binder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Binder.html +[`BoundRegion`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BoundRegion.html +[defid]: ./hir.html#identifiers-in-the-hir From a960baa49f3863584d4b1741a515ffaebd5239a6 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 5 Jun 2020 12:42:45 -0500 Subject: [PATCH 1040/1812] do a rebase before testing (#737) --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index e4a72f7c6..3e5febe30 100644 --- a/.travis.yml +++ b/.travis.yml @@ -14,6 +14,7 @@ install: - cargo install mdbook --version 0.3.7 - cargo install mdbook-linkcheck --version 0.5.0 script: +- git rebase master # this will exit with an error on conflict - mdbook build notifications: email: From 42520d3ca82298e6e5d17ccef80d9c6187c3ace2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomasz=20Mi=C4=85sko?= Date: Mon, 8 Jun 2020 00:00:00 +0000 Subject: [PATCH 1041/1812] Document needs-* compiletest directives --- src/tests/adding.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index 15fff1ff3..1df17ae01 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -185,6 +185,13 @@ source. errors when usage of a gated feature is attempted without the proper `#![feature(X)]` tag. Each unstable lang feature is required to have a gate test. +* `needs-profiler-support` - a profiler runtime is required, i.e., + `profiler = true` in rustc's `config.toml`. +* `needs-sanitizer-support` - a sanitizer runtime is required, i.e., + `sanitizers = true` in rustc's `config.toml`. +* `needs-sanitizer-{address,leak,memory,thread}` - indicates that test + requires a target with a support for AddressSanitizer, LeakSanitizer, + MemorySanitizer or ThreadSanitizer respectively. [`header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs [bless]: ./running.md#editing-and-updating-the-reference-files From e349f81b225e09542574acdcd85c664438e7915c Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 9 Jun 2020 15:42:00 -0400 Subject: [PATCH 1042/1812] Rebrand ICE-breakers, introduce Windows notification group (#739) * rename ice-breakers to the more general notification-group also less confusing * add windows notification group * rebrand LLVM ICE-breakers as a "notification group" * include the link to example windows PR --- src/SUMMARY.md | 7 +++-- .../about.md | 0 .../cleanup-crew.md | 0 .../llvm.md | 11 ++++--- src/notification-groups/windows.md | 31 +++++++++++++++++++ 5 files changed, 42 insertions(+), 7 deletions(-) rename src/{ice-breaker => notification-groups}/about.md (100%) rename src/{ice-breaker => notification-groups}/cleanup-crew.md (100%) rename src/{ice-breaker => notification-groups}/llvm.md (77%) create mode 100644 src/notification-groups/windows.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f45e8ba96..a86eedd6c 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -29,9 +29,10 @@ - [Emitting Errors and other Diagnostics](diagnostics.md) - [`LintStore`](./diagnostics/lintstore.md) - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) - - [ICE-breaker teams](ice-breaker/about.md) - - ["Cleanup Crew" ICE-breakers](ice-breaker/cleanup-crew.md) - - [LLVM ICE-breakers](ice-breaker/llvm.md) + - [Notification groups](notification-groups/about.md) + - ["Cleanup Crew"](notification-groups/cleanup-crew.md) + - [LLVM](notification-groups/llvm.md) + - [Windows](notification-groups/windows.md) - [Licenses](./licenses.md) - [Part 2: High-level Compiler Architecture](./part-2-intro.md) - [Overview of the Compiler](./overview.md) diff --git a/src/ice-breaker/about.md b/src/notification-groups/about.md similarity index 100% rename from src/ice-breaker/about.md rename to src/notification-groups/about.md diff --git a/src/ice-breaker/cleanup-crew.md b/src/notification-groups/cleanup-crew.md similarity index 100% rename from src/ice-breaker/cleanup-crew.md rename to src/notification-groups/cleanup-crew.md diff --git a/src/ice-breaker/llvm.md b/src/notification-groups/llvm.md similarity index 77% rename from src/ice-breaker/llvm.md rename to src/notification-groups/llvm.md index a6291a8c2..d657231f2 100644 --- a/src/ice-breaker/llvm.md +++ b/src/notification-groups/llvm.md @@ -1,10 +1,10 @@ -# LLVM ICE-breakers +# LLVM Notification group -**Github Label:** [ICEBreaker-LLVM] +**Github Label:** [A-LLVM] -[ICEBreaker-LLVM]: https://github.com/rust-lang/rust/labels/ICEBreaker-LLVM +[A-LLVM]: https://github.com/rust-lang/rust/labels/A-LLVM -The "LLVM ICE-breakers" are focused on bugs that center around LLVM. +The "LLVM Notification Group" are focused on bugs that center around LLVM. These bugs often arise because of LLVM optimizations gone awry, or as the result of an LLVM upgrade. The goal here is: @@ -13,6 +13,9 @@ the result of an LLVM upgrade. The goal here is: - if the former, to fix our IR; - if the latter, to try and file a bug on LLVM (or identify an existing bug). +The group may also be asked to weigh in on other sorts of LLVM-focused +questions. + ## Helpful tips and options The ["Debugging LLVM"][d] section of the diff --git a/src/notification-groups/windows.md b/src/notification-groups/windows.md new file mode 100644 index 000000000..328ee6480 --- /dev/null +++ b/src/notification-groups/windows.md @@ -0,0 +1,31 @@ +# Windows notification group + +**Github Label:** [O-Windows] + +[O-Windows]: https://github.com/rust-lang/rust/labels/O-Windows + +This list will be used to ask for help both in diagnosing and testing +Windows-related issues as well as suggestions on how to resolve +interesting questions regarding our Windows support. + +The group also has an associated Zulip stream (`#t-compiler/windows`) +where people can go to pose questions and discuss Windows-specific +topics. + +To get a better idea for what the group will do, here are some +examples of the kinds of questions where we would have reached out to +the group for advice in determining the best course of action: + +* Which versions of MinGW should we support? +* Should we remove the legacy InnoSetup GUI installer? [#72569] +* What names should we use for static libraries on Windows? [#29520] + +So, if you are interested in participating, please sign up for the +Windows group! To do so, you open a PR against the [rust-lang/team] +repository. Just [follow this example][eg], but change the username to +your own! + +[rust-lang/team]: https://github.com/rust-lang/team +[eg]: https://github.com/rust-lang/team/pull/348/ +[#72569]: https://github.com/rust-lang/rust/pull/72569 +[#29520]: https://github.com/rust-lang/rust/pull/29520 From 089b82651daf84eed7fb21e1a49ab082dddd7220 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Tue, 9 Jun 2020 17:58:22 -0400 Subject: [PATCH 1043/1812] add the ARM notification group (#740) --- src/SUMMARY.md | 1 + src/notification-groups/arm.md | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+) create mode 100644 src/notification-groups/arm.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a86eedd6c..36048f7cb 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -33,6 +33,7 @@ - ["Cleanup Crew"](notification-groups/cleanup-crew.md) - [LLVM](notification-groups/llvm.md) - [Windows](notification-groups/windows.md) + - [ARM](notification-groups/arm.md) - [Licenses](./licenses.md) - [Part 2: High-level Compiler Architecture](./part-2-intro.md) - [Overview of the Compiler](./overview.md) diff --git a/src/notification-groups/arm.md b/src/notification-groups/arm.md new file mode 100644 index 000000000..0b0d21776 --- /dev/null +++ b/src/notification-groups/arm.md @@ -0,0 +1,23 @@ +# ARM notification group + +**Github Label:** [O-ARM] + +[O-ARM]: https://github.com/rust-lang/rust/labels/O-ARM + +This list will be used to ask for help both in diagnosing and testing +ARM-related issues as well as suggestions on how to resolve +interesting questions regarding our ARM support. + +The group also has an associated Zulip stream (`#t-compiler/arm`) +where people can go to pose questions and discuss ARM-specific +topics. + +So, if you are interested in participating, please sign up for the +ARM group! To do so, you open a PR against the [rust-lang/team] +repository. Just [follow this example][eg], but change the username to +your own! + +[rust-lang/team]: https://github.com/rust-lang/team +[eg]: https://github.com/rust-lang/team/pull/358 +[#72569]: https://github.com/rust-lang/rust/pull/72569 +[#29520]: https://github.com/rust-lang/rust/pull/29520 From 1a229d6d6036884e1509439da4608fe8653e72f6 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 8 Jun 2020 13:27:16 -0400 Subject: [PATCH 1044/1812] complete the ICE-breaker => notification group rename --- src/notification-groups/about.md | 44 +++++++++++++++++--------------- 1 file changed, 23 insertions(+), 21 deletions(-) diff --git a/src/notification-groups/about.md b/src/notification-groups/about.md index d9c724532..f95236aad 100644 --- a/src/notification-groups/about.md +++ b/src/notification-groups/about.md @@ -1,40 +1,40 @@ -# ICE-breakers +# Notification groups -The **ICE-breaker groups** are an easy way to help out with rustc in a +The **notification groups** are an easy way to help out with rustc in a "piece-meal" fashion, without committing to a larger project. -ICE-breaker groups are **[easy to join](#join)** (just submit a PR!) +Notification groups are **[easy to join](#join)** (just submit a PR!) and joining does not entail any particular commitment. -Once you [join an ICE-breaker group](#join), you will be added to +Once you [join a notification group](#join), you will be added to a list that receives pings on github whenever a new issue is found -that fits the ICE-breaker group's criteria. If you are interested, you +that fits the notification group's criteria. If you are interested, you can then [claim the issue] and start working on it. Of course, you don't have to wait for new issues to be tagged! If you -prefer, you can use the Github label for an ICE-breaker group to +prefer, you can use the Github label for a notification group to search for existing issues that haven't been claimed yet. [claim the issue]: https://github.com/rust-lang/triagebot/wiki/Assignment -## What issues are a good fit for ICE-breaker groups? +## What issues are a good fit for notification groups? -"ICE-breaker issues" are intended to be **isolated** bugs of **middle -priority**: +Notification groups tend to get pinged on **isolated** bugs, +particularly those of **middle priority**: - By **isolated**, we mean that we do not expect large-scale refactoring to be required to fix the bug. - By **middle priority**, we mean that we'd like to see the bug fixed, but it's not such a burning problem that we are dropping everything else to fix it. The danger with such bugs, of course, is that they - can accumulate over time, and the role of the ICE-breaker groups is + can accumulate over time, and the role of the notification group is to try and stop that from happening! -## Joining an ICE-breaker group +## Joining a notification group -To join an ICE-breaker group, you just have to open a PR adding your -Github username to the appropriate file in the Rust team repository. +To join an notification group, you just have to open a PR adding your +Github username to the appropriate file in the Rust team repository. See the "example PRs" below to get a precise idea and to identify the file to edit. @@ -48,18 +48,20 @@ cargo run add-person $your_user_name Example PRs: -* [Example of adding yourself to the LLVM ICE-breakers.](https://github.com/rust-lang/team/pull/140) -* [Example of adding yourself to the Cleanup Crew ICE-breakers.](https://github.com/rust-lang/team/pull/221) +* [Example of adding yourself to the Cleanup Crew.](https://github.com/rust-lang/team/pull/221) +* [Example of adding yourself to the LLVM group.](https://github.com/rust-lang/team/pull/140) +* [Example of adding yourself to the Windows group.](https://github.com/rust-lang/team/pull/348) +* [Example of adding yourself to the ARM group.](https://github.com/rust-lang/team/pull/358) -## Tagging an issue for an ICE-breaker group +## Tagging an issue for a notification group -To tag an issue as appropriate for an ICE-breaker group, you give -[rustbot] a [`ping`] command with the name of the ICE-breakers -team. For example: +To tag an issue as appropriate for a notification group, you give +[rustbot] a [`ping`] command with the name of the notification +group. For example: ```text -@rustbot ping icebreakers-llvm -@rustbot ping icebreakers-cleanup-crew +@rustbot ping llvm +@rustbot ping cleanup-crew ``` To make these commands shorter and easier to remember, there are aliases, From e647444811d3d286bfa691a05f0f55de11270ece Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Wed, 10 Jun 2020 20:19:59 +0200 Subject: [PATCH 1045/1812] Include "Lint" in the title of the diagnostics chapter (#742) --- src/SUMMARY.md | 2 +- src/diagnostics.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 36048f7cb..ecc11350c 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -26,7 +26,7 @@ - [with the linux perf tool](./profiling/with_perf.md) - [Coding conventions](./conventions.md) - [crates.io Dependencies](./crates-io.md) - - [Emitting Errors and other Diagnostics](diagnostics.md) + - [Errors and Lints](diagnostics.md) - [`LintStore`](./diagnostics/lintstore.md) - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) - [Notification groups](notification-groups/about.md) diff --git a/src/diagnostics.md b/src/diagnostics.md index 428688fd3..ce7a37a79 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -1,4 +1,4 @@ -# Emitting Errors and other Diagnostics +# Errors and Lints A lot of effort has been put into making `rustc` have great error messages. This chapter is about how to emit compile errors and lints from the compiler. From 8d82570b042b60ba83e2e55ea311fcb7d920a666 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 10 Jun 2020 15:51:04 -0500 Subject: [PATCH 1046/1812] Only build master branch on push --- .travis.yml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/.travis.yml b/.travis.yml index 3e5febe30..582615c4b 100644 --- a/.travis.yml +++ b/.travis.yml @@ -30,3 +30,8 @@ deploy: fqdn: rustc-dev-guide.rust-lang.org on: branch: master + +# Only build master branch on push +branches: + only: + - master From 3b1866b1ea010601618c76c313211a65c4658f6a Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Thu, 11 Jun 2020 00:04:19 +0200 Subject: [PATCH 1047/1812] Clean up the paragraph about aliases for pinging the notification groups (#743) * Clean up the paragraph about aliases for pinging the notification groups * Add windows and arm command invocations Co-authored-by: Santiago Pastorino Co-authored-by: Santiago Pastorino --- src/notification-groups/about.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/notification-groups/about.md b/src/notification-groups/about.md index f95236aad..02ceb9271 100644 --- a/src/notification-groups/about.md +++ b/src/notification-groups/about.md @@ -62,14 +62,18 @@ group. For example: ```text @rustbot ping llvm @rustbot ping cleanup-crew +@rustbot ping windows +@rustbot ping arm ``` -To make these commands shorter and easier to remember, there are aliases, -defined in the [`triagebot.toml`] file. For example: +To make some commands shorter and easier to remember, there are aliases, +defined in the [`triagebot.toml`] file. For example, all of these commands +are equivalent and will ping the Cleanup Crew: ```text -@rustbot ping llvm @rustbot ping cleanup +@rustbot ping bisect +@rustbot ping reduce ``` Keep in mind that these aliases are meant to make humans' life easier. From ff98a7573de3809bc5ee937137123b1ce46c3c5f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 10 Jun 2020 21:48:02 -0500 Subject: [PATCH 1048/1812] Fix CI rebase (#745) * Fix CI rebase --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 582615c4b..58ed7c562 100644 --- a/.travis.yml +++ b/.travis.yml @@ -14,7 +14,7 @@ install: - cargo install mdbook --version 0.3.7 - cargo install mdbook-linkcheck --version 0.5.0 script: -- git rebase master # this will exit with an error on conflict +- git rebase origin master # this will exit with an error on conflict - mdbook build notifications: email: From 5371f132368a980170681e7ae64460a348b2ccec Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 11 Jun 2020 12:38:42 +0200 Subject: [PATCH 1049/1812] tag/niche terminology (#747) --- src/appendix/glossary.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index f8042170c..0a7568992 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -17,6 +17,7 @@ DAG
| A directed acyclic graph is used dur data-flow analysis
| A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). DeBruijn Index
| A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#debruijn)) DefId
| An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +Discriminant
| The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). Double pointer
| A pointer with additional metadata. See "fat pointer" for more. drop glue
| (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. DST
| Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). @@ -48,7 +49,7 @@ miri
| An interpreter for MIR used for cons monomorphization
| The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.html#normalizeprojection---type). newtype
| A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -Niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche to determine the `enum` variant without storing a discriminant. +Niche
| Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field. NLL
| Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId
| An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). obligation
| Something that must be proven by the trait system. ([see more](../traits/resolution.html)) @@ -68,6 +69,7 @@ sigil
| Like a keyword but composed entirely soundness
| A technical term in type theory. Roughly, if a type system is sound, then a program that type-checks is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span
| A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs
| The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). +Tag
| The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). tcx
| The "typing context", main data structure of the compiler. ([see more](../ty.html)) 'tcx
| The lifetime of the allocation arena. ([see more](../ty.html)) token
| The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). @@ -79,6 +81,7 @@ UFCS
| Short for Universal Function Call Sy uninhabited type
| A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". upvar
| A variable captured by a closure from outside the closure. variance
| Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance. +Variant index
| In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). Wide pointer
| A pointer with additional metadata. See "fat pointer" for more. ZST
| Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. From 4228f467774bf11cfb13a2dc8dfb5b56ea7f9209 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 16 Jun 2020 20:23:26 -0700 Subject: [PATCH 1050/1812] Add some more detail on compiletest normalization. --- src/tests/adding.md | 60 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 47 insertions(+), 13 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 1df17ae01..538860f65 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -136,6 +136,9 @@ Some examples of `X` in `ignore-X`: * Stage: `stage0`, `stage1`, `stage2`. * When cross compiling: `cross-compile` * When remote testing is used: `remote` +* When debug-assertions are enabled: `debug` +* When particular debuggers are being tested: `cdb`, `gdb`, `lldb` +* Specific compare modes: `compare-mode-nll`, `compare-mode-polonius` ### Other Header Commands @@ -204,8 +207,8 @@ Error annotations specify the errors that the compiler is expected to emit. They are "attached" to the line in source where the error is located. Error annotations are considered during tidy lints of line length and should be formatted according to tidy requirements. You may -use an error message prefix sub-string if necessary to meet line length -requirements. Make sure that the text is long enough for the error +use an error message prefix sub-string if necessary to meet line length +requirements. Make sure that the text is long enough for the error message to be self-documenting. The error annotation definition and source line definition association @@ -216,7 +219,7 @@ is defined with the following set of idioms: * `~|`: Associates the following error level and message with the same line as the previous comment * `~^`: Associates the following error level and message with the - previous error annotation line. Each caret (`^`) that you add adds + previous error annotation line. Each caret (`^`) that you add adds a line to this, so `~^^^` is three lines above the error annotation line. @@ -242,8 +245,8 @@ fn main() { #### Positioned below error line Use the `//~^` idiom with number of carets in the string to indicate the -number of lines above. In the example below, the error line is four -lines above the error annotation line so four carets are included in +number of lines above. In the example below, the error line is four +lines above the error annotation line so four carets are included in the annotation. ```rust,ignore @@ -259,7 +262,7 @@ fn main() { #### Use same error line as defined on error annotation line above -Use the `//~|` idiom to define the same error line as +Use the `//~|` idiom to define the same error line as the error annotation line above: ```rust,ignore @@ -360,12 +363,43 @@ you can even run the resulting program. Just add one of the following ### Normalization -The normalization applied is aimed at eliminating output difference -between platforms, mainly about filenames: - -- the test directory is replaced with `$DIR` -- all backslashes (`\`) are converted to forward slashes (`/`) (for Windows) -- all CR LF newlines are converted to LF +The compiler output is normalized to eliminate output difference between +platforms, mainly about filenames. + +The following strings replace their corresponding values: + +- `$DIR`: The directory where the test is defined. + - Example: `/path/to/rust/src/test/ui/error-codes` +- `$SRC_DIR`: The root source directory. + - Example: `/path/to/rust/src` +- `$TEST_BUILD_DIR`: The base directory where the test's output goes. + - Example: `/path/to/rust/build/x86_64-unknown-linux-gnu/test/ui` + +Additionally, the following changes are made: + +- Line and column numbers for paths in `$SRC_DIR` are replaced with `LL:CC`. + For example, `/path/to/rust/src/libcore/clone.rs:122:8` is replaced with + `$SRC_DIR/libcore/clone.rs:LL:COL`. + + Note: The line and column numbers for `-->` lines pointing to the test are + *not* normalized, and left as-is. This ensures that the compiler continues + to point to the correct location, and keeps the stderr files readable. + Ideally all line/column information would be retained, but small changes to + the source causes large diffs, and more frequent merge conflicts and test + errors. See also `-Z ui-testing` below which applies additional line number + normalization. +- `\t` is replaced with an actual tab character. +- Error line annotations like `// ~ERROR some message` are removed. +- Backslashes (`\`) are converted to forward slashes (`/`) within paths (using + a heuristic). This helps normalize differences with Windows-style paths. +- CRLF newlines are converted to LF. + +Additionally, the compiler is run with the `-Z ui-testing` flag which causes +the compiler itself to apply some changes to the diagnostic output to make it +more suitable for UI testing. For example, it will anonymize line numbers in +the output (line numbers prefixing each source line are replaced with `LL`). +In extremely rare situations, this mode can be disabled with the header +command `// compile-flags: -Z ui-testing=no`. Sometimes these built-in normalizations are not enough. In such cases, you may provide custom normalization rules using the header commands, e.g. @@ -399,6 +433,6 @@ concrete usage example. [`main.stderr`]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.stderr Besides `normalize-stderr-32bit` and `-64bit`, one may use any target -information or stage supported by `ignore-X` here as well (e.g. +information or stage supported by [`ignore-X`](#ignoring-tests) here as well (e.g. `normalize-stderr-windows` or simply `normalize-stderr-test` for unconditional replacement). From 178e3052b246fe05f847ec33fea60c8e21109487 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 17 Jun 2020 09:52:39 -0400 Subject: [PATCH 1051/1812] Document rustdoc behavior - `RUSTDOC_LOG` - `// aux-build:filename.rs` - `// build-aux-docs` --- src/compiler-debugging.md | 8 ++++++++ src/rustdoc.md | 8 ++++++++ 2 files changed, 16 insertions(+) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index a499224ae..0bb3cd1dd 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -164,6 +164,8 @@ your log filter, e.g. to get the logs for a specific module, you can run the compiler as `RUSTC_LOG=module::path rustc my-file.rs`. All `debug!` output will then appear in standard error. +If you are developing rustdoc, use `RUSTDOC_LOG` instead. + **Note that unless you use a very strict filter, the logger will emit a lot of output, so use the most specific module(s) you can (comma-separated if multiple)**. It's typically a good idea to pipe standard error to a file and @@ -193,6 +195,12 @@ $ RUSTC_LOG=debug rustc +local my-file.rs 2>all-log # log rather than a `debug!` log so it will work on the official # compilers. $ RUSTC_LOG=rustc_trans=info rustc +local my-file.rs + +# This will show the output of all `info!` calls made by rustdoc or any rustc library it calls. +$ RUSTDOC_LOG=info rustdoc +local my-file.rs + +# This will only show `debug!` calls made by rustdoc directly, not any `librustc*` crate. +$ RUSTDOC_LOG=rustdoc rustdoc +local my-file.rs ``` ### How to keep or remove `debug!` and `trace!` calls from the resulting binary diff --git a/src/rustdoc.md b/src/rustdoc.md index fc964b18e..120ebe139 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -232,6 +232,11 @@ expect in various situations. These tests also use a supplementary script, XPath notation to get a precise look at the output. The full description of all the commands available to rustdoc tests is in `htmldocck.py`. +To use multiple crates in a rustdoc test, add `// aux-build:filename.rs` +to the top of the test file. `filename.rs` should be placed in an `auxiliary` +directory relative to the test file with the comment. If you need to build +docs for the auxiliary file, use `// build-aux-docs`. + In addition, there are separate tests for the search index and rustdoc's ability to query it. The files in `src/test/rustdoc-js` each contain a different search query and the expected results, broken out by search tab. @@ -240,3 +245,6 @@ runtime. These tests don't have as thorough of a writeup, but a broad example that features results in all tabs can be found in `basic.js`. The basic idea is that you match a given `QUERY` with a set of `EXPECTED` results, complete with the full item path of each item. + +You can run tests using the name of the folder. For example, +`x.py test --stage 1 src/test/rustdoc` will run the output tests using a stage1 rustdoc. From 163efc6fcd7d55f2487049b1487085aa23e494ab Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 17 Jun 2020 11:01:46 -0400 Subject: [PATCH 1052/1812] Don't give `x.py clean` as the first x.py example This command shouldn't be used very often, and it has its own whole section below anyway. --- src/building/how-to-build-and-run.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 16d3e1462..18b7d1977 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -259,8 +259,6 @@ Here are a few other useful `x.py` commands. We'll cover some of them in detail in other sections: - Building things: - - `./x.py clean` – clean up the build directory (`rm -rf build` works too, - but then you have to rebuild LLVM) - `./x.py build --stage 1` – builds everything using the stage 1 compiler, not just up to `libstd` - `./x.py build` – builds the stage2 compiler @@ -283,3 +281,5 @@ everything up then you only need to run one command! ```bash ./x.py clean ``` + +`rm -rf build` works too, but then you have to rebuild LLVM. From 708acbc72b321b0347cdbc99e29158c043edbbf2 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 18 Jun 2020 01:33:15 -0700 Subject: [PATCH 1053/1812] Add a link to the forge procedure on adding new options. (#754) --- src/cli.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/cli.md b/src/cli.md index bbb7bae24..f47c89e1f 100644 --- a/src/cli.md +++ b/src/cli.md @@ -4,6 +4,9 @@ Command-line flags are documented in the [rustc book][cli-docs]. All *stable* flags should be documented there. Unstable flags should be documented in the [unstable book]. +See the [forge guide for new options] for details on the *procedure* for +adding a new command-line argument. + ## Guidelines - Flags should be orthogonal to each other. For example, if we'd have a @@ -25,5 +28,6 @@ flags should be documented there. Unstable flags should be documented in the unstable-options` flag. [cli-docs]: https://doc.rust-lang.org/rustc/command-line-arguments.html +[forge guide for new options]: https://forge.rust-lang.org/compiler/new_option.html [unstable book]: https://doc.rust-lang.org/nightly/unstable-book/ [`parse_bool`]: https://github.com/rust-lang/rust/blob/e5335592e78354e33d798d20c04bcd677c1df62d/src/librustc_session/options.rs#L307-L313 From 8fbc9f524113acdbbf0e05c9cb8a396245339a64 Mon Sep 17 00:00:00 2001 From: mark Date: Mon, 1 Jun 2020 21:58:37 -0500 Subject: [PATCH 1054/1812] start a getting started guide --- src/SUMMARY.md | 1 + src/getting-started.md | 223 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 224 insertions(+) create mode 100644 src/getting-started.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index ecc11350c..f462817c0 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -6,6 +6,7 @@ - [Part 1: Building, debugging, and contributing to Rustc](./part-1-intro.md) - [About the compiler team](./compiler-team.md) + - [Getting Started](./getting-started.md) - [How to Build and Run the Compiler](./building/how-to-build-and-run.md) - [Suggested Workflows](./building/suggested.md) - [Bootstrapping](./building/bootstrapping.md) diff --git a/src/getting-started.md b/src/getting-started.md new file mode 100644 index 000000000..c82964463 --- /dev/null +++ b/src/getting-started.md @@ -0,0 +1,223 @@ +# Getting Started + +This documentation is _not_ intended to be comprehensive; it is meant to be a +quick guide for the most useful things. For more information, [see this +chapter](./building/how-to-build-and-run.md). + +## Asking Questions + +The compiler team (or "t-compiler") usually hangs out in Zulip [in this +"stream"][z]; it will be easiest to get questions answered there. + +[z]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler + +**Please ask questions!** A lot of people report feeling that they are "wasting +expert time", but nobody on t-compiler feels this way. Contributors are +important to us. + +Also, if you feel comfortable, prefer public topics, as this means others can +see the questions and answers, and perhaps even integrate them back into this +guide :) + +### Experts + +Not all `t-compiler` members are experts on all parts of `rustc`; it's a pretty +large project. To find out who has expertise on different parts of the +compiler, [consult this "experts map"][map]. + +It's not perfectly complete, though, so please also feel free to ask questions +even if you can't figure out who to ping. + +[map]: https://github.com/rust-lang/compiler-team/blob/master/content/experts/map.toml + +### Etiquette + +We do ask that you be mindful to include as much useful information as you can +in your question, but we recognize this can be hard if you are unfamiliar with +contributing to Rust. + +Just pinging someone without providing any context can be a bit annoying and +just create noise, so we ask that you be mindful of the fact that the +`t-compiler` folks get a lot of pings in a day. + +## Cloning and Building + +The main repository is [`rust-lang/rust`][repo]. This contains the compiler, +the standard library (including `core`, `alloc`, `test`, `proc_macro`, etc), +and a bunch of tools (e.g. `rustdoc`, the bootstrapping infrastructure, etc). + +[repo]: https://github.com/rust-lang/rust + +There are also a bunch of submodules for things like LLVM, `clippy`, `miri`, +etc. You don't need to clone these immediately, but the build tool will +automatically clone and sync them (more later). + +[**Take a look at the "Suggested Workflows" chapter for some helpful +advice.**][suggested] + +[suggested]: ./building/suggested.md + +### System Requirements + +[**See this chapter for detailed software requirements.**](./building/prerequisites.md) +Most notably, you will need python 2 to run `x.py`. + +There are no hard hardware requirements, but building the compiler is +computationally expensive, so a beefier machine will help, and I wouldn't +recommend building try to build on a Raspberry Pi :P + +- x86 and ARM are both supported (TODO: confirm) +- Recommended 30GB of free disk space; otherwise, you will have to keep + clearing incremental caches. +- Recommended >=8GB RAM +- Recommended >=2 cores; more cores really helps +- You will need an internet connection to build; the bootstrapping process + involves updating git submodules and downloading a beta compiler. It doesn't + need to be super fast, but that can help. + +Building the compiler take more than half an hour on my moderately powerful +laptop (even longer if you build LLVM). + +### Cloning + +You can just do a normal git clone: + +```shell +git clone https://github.com/rust-lang/rust.git +``` + +You don't need to clone the submodules at this time. + +**Pro tip**: if you contribute often, you may want to look at the git worktrees +tip in [this chapter][suggested]. + +### Configuring the Compiler + +The compiler has a configuration file which contains a ton of settings. We will +provide some recommendations here that should work for most, but [check out +this chapter for more info][config]. + +[config]: ./building/how-to-build-and-run.html#create-a-configtoml + +In the top level of the repo: + +```shell +cp config.toml.example config.toml +``` + +Then, edit `config.toml`. You will need to search for, uncomment, and update +the following settings: + +- `debug = true`: enables debug symbols and `debug!` logging, takes a bit longer to compile. +- `incremental = true`: enables incremental compilation of the compiler itself. + This is turned off by default because it's technically unsound. Sometimes + this will cause weird crashes, but it can really speed things up. +- `llvm-config`: enable building with system LLVM. [See this chapter][sysllvm] + for more info. This avoids having to build LLVM, which takes forever. + +[sysllvm]: ./building/suggested.html#building-with-system-llvm + +### `./x.py` Intro + +`rustc` is a bootstrapping compiler because it is written in Rust. Where do you +get do you get the original compiler from? We use the current `beta` compiler +to build the compiler. Then, we use that compiler to build itself. Thus, +`rustc` has a 2-stage build. + +We have a special tool `./x.py` that drives this process. It is used for +compiling the compiler, the standard libraries, and `rustdoc`. It is also used +for driving CI and building the final release artifacts. + +### Building and Testing `rustc` + +For most contributions, you only need to build stage 1, which saves a lot of time. +After updating `config.toml`, as mentioned above, you can use `./x.py`: + +```shell +# Build the compiler (stage 1) +./x.py build --stage 1 +``` + +This will take a while, especially the first time. Be wary of accidentally +touching or formatting the compiler, as `./x.py` will try to recompile it. + +To run the compiler's UI test (the bulk of the test suite): + +``` +# UI tests +./x.py test --stage 1 src/test/ui +``` + +This will build the compiler first, if needed. + +This will be enough for most people. Notably, though, it mostly tests the +compiler frontend, not codegen or debug info. You can read more about the +different test suites [in this chapter][testing]. + +[testing]: https://rustc-dev-guide.rust-lang.org/tests/intro.html + +If you only want to check that the compiler builds (without actually building +it) you can run the following: + +```shell +./x.py check +``` + +To format the code: + +```shell +# Actually format +./x.py fmt + +# Just check formatting, exit with error +./x.py fmt --check +``` + +You can use `RUSTC_LOG=XXX` to get debug logging. [Read more here][logging]. + +[logging]: ./compiler-debugging.html#getting-logging-output + +### Building and Testing `std`/`core`/`alloc`/`test`/`proc_macro`/etc. + +TODO + +### Building and Testing `rustdoc` + +TODO + +### Contributing code to other Rust projects + +TODO: talk about things like miri, clippy, chalk, etc + +## Contributor Procedures + +There are some official procedures to know about. This is a tour of the +highlights, but there are a lot more details, which we will link to below. + +### Bug Fixes + +TODO: talk about bors, highfive + +### New Features + +TODO: talk about RFCs, stabilization + +### Breaking Changes + +TODO: talk about crater, FCP, etc + +### Major Changes + +TODO: talk about MCP + +### Performance + +TODO: Talk about perf runs + +## Other Resources + +- This guide: talks about how `rustc` works +- [The t-compiler zulip][z] +- [The compiler's documentation (rustdocs)](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/) + +TODO: am I missing any? From 324eb69950056d9ab30e33cf8febf86afdad62c8 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 2 Jun 2020 13:29:06 -0500 Subject: [PATCH 1055/1812] Typo fixes Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/getting-started.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index c82964463..3c4a541a9 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -60,11 +60,11 @@ advice.**][suggested] ### System Requirements [**See this chapter for detailed software requirements.**](./building/prerequisites.md) -Most notably, you will need python 2 to run `x.py`. +Most notably, you will need Python 2 to run `x.py`. There are no hard hardware requirements, but building the compiler is computationally expensive, so a beefier machine will help, and I wouldn't -recommend building try to build on a Raspberry Pi :P +recommend trying to build on a Raspberry Pi :P - x86 and ARM are both supported (TODO: confirm) - Recommended 30GB of free disk space; otherwise, you will have to keep @@ -75,7 +75,7 @@ recommend building try to build on a Raspberry Pi :P involves updating git submodules and downloading a beta compiler. It doesn't need to be super fast, but that can help. -Building the compiler take more than half an hour on my moderately powerful +Building the compiler takes more than half an hour on my moderately powerful laptop (even longer if you build LLVM). ### Cloning @@ -120,7 +120,7 @@ the following settings: ### `./x.py` Intro `rustc` is a bootstrapping compiler because it is written in Rust. Where do you -get do you get the original compiler from? We use the current `beta` compiler +get the original compiler from? We use the current beta compiler to build the compiler. Then, we use that compiler to build itself. Thus, `rustc` has a 2-stage build. From c5c498ca19606dc54072c90df52b4ca8b51e73d3 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 13:44:20 -0500 Subject: [PATCH 1056/1812] address some review comments --- src/getting-started.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 3c4a541a9..bc8d6648a 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -69,14 +69,19 @@ recommend trying to build on a Raspberry Pi :P - x86 and ARM are both supported (TODO: confirm) - Recommended 30GB of free disk space; otherwise, you will have to keep clearing incremental caches. -- Recommended >=8GB RAM -- Recommended >=2 cores; more cores really helps +- Recommended >=8GB RAM. +- Recommended >=2 cores; more cores really helps. - You will need an internet connection to build; the bootstrapping process involves updating git submodules and downloading a beta compiler. It doesn't need to be super fast, but that can help. Building the compiler takes more than half an hour on my moderately powerful -laptop (even longer if you build LLVM). +laptop. The first time you build the compiler, LLVM will also be built unless +you use system LLVM (see below). + +Like `cargo`, the build system will use as many cores as possible. Sometimes +this can cause you to run low on memory. You can use `-j` to adjust the number +concurrent jobs. ### Cloning @@ -113,7 +118,7 @@ the following settings: This is turned off by default because it's technically unsound. Sometimes this will cause weird crashes, but it can really speed things up. - `llvm-config`: enable building with system LLVM. [See this chapter][sysllvm] - for more info. This avoids having to build LLVM, which takes forever. + for more info. This avoids building LLVM, which can take a while. [sysllvm]: ./building/suggested.html#building-with-system-llvm From ba2d73db5ff43f5c7e162151db12ed22328c55e1 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 14:25:30 -0500 Subject: [PATCH 1057/1812] write about processes --- src/getting-started.md | 108 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 102 insertions(+), 6 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index bc8d6648a..1ec7b1b26 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -199,25 +199,121 @@ TODO: talk about things like miri, clippy, chalk, etc There are some official procedures to know about. This is a tour of the highlights, but there are a lot more details, which we will link to below. -### Bug Fixes +### Code Review -TODO: talk about bors, highfive +When you open a PR on the `rust-lang/rust` repo, a bot called `@highfive` will +automatically assign a reviewer to the PR. The reviewer is the person that will +approve the PR to be tested and merged. If you want a specific reviewer (e.g. a +team member you've been working with), you can specifically request them by +writing `r? @user` (e.g. `r? @eddyb`) in either the original post or a followup +comment. + +The reviewer may request some changes using the GitHub code review interface. +They may also request special procedures (such as a crater run; see below) for +some PRs. + +When the PR is ready to be merged, the reviewer will issue a command to +`@bors`, the CI bot. Usually, this is `@bors r+` or `@bors r=@user` to approve +a PR (there are few other commands, but they are less relevant here). This puts +the PR in [bors's queue][bors] to be tested and merged. Be patient; this can take a +while and the queue can sometimes be long. PRs are never merged by hand. + +[bors]: https://buildbot2.rust-lang.org/homu/queue/rust + +### Bug Fixes or "Normal" code changes + +For most PRs, no special procedures are needed. You can just open a PR, and it +will be reviewed, approved, and merged. This includes most bug fixes, +refactorings, and other user-invisible changes. The next few sections talk +about exceptions to this rule. ### New Features -TODO: talk about RFCs, stabilization +Rust has strong backwards-compatibility guarantees. Thus, new features can't +just be implemented directly in stable Rust. Instead, we have 3 release +channels: stable, beta, and nightly. + +- **Stable**: this is the latest stable release for general usage. +- **Beta**: this is the next release (will be stable within 6 weeks). +- **Nightly**: follows the `master` branch of the repo. This is the only + channel where unstable, incomplete, or experimental features are usable with + feature gates. + +In order to implement a new feature, usually you will need to go through [the +RFC process][rfc] to propose a design, have discussions, etc. In some cases, +small features can be added with only an FCP (see below). If in doubt, ask the +compiler, language, or libs team (whichever is most relevant). + +[rfc]: https://github.com/rust-lang/rfcs/blob/master/README.md + +After a feature is approved to be added, a tracking issue is created on the +`rust-lang/rust` repo, which tracks the progress towards the implementation of +the feature, any bugs reported, and eventually stabilization. + +The feature then needs to be implemented behind a feature gate, which prevents +it from being accidentally used. + +Finally, somebody may propose stabilizing the feature in an upcoming version of +Rust. This requires an FCP (see below) to get the approval of the relevant teams. + +After that, the feature gate can be removed and the feature turned on for all users. + +[For more details on this process, see this chapter.](./implementing_new_features.md) ### Breaking Changes -TODO: talk about crater, FCP, etc +As mentioned above, Rust has strong backwards-compatibility guarantees. To this +end, we are reluctant to make breaking changes. However, sometimes they are +needed to correct compiler bugs (e.g. code that compiled but should not). + +Depending on the scale of the breakage, there are a few different actions that +can be taken. If the reviewer believes the breakage is very minimal (i.e. very +unlikely to be actually encountered by users), they may just merge the change. +More often, they will request a Final Comment Period (FCP), which calls for +rough consensus among the members of a relevant team. The team members can +discuss the issue and either accept, reject, or request changes on the PR. + +If the scale of breakage is large, a deprecation warning may be needed. This is +a warning that the compiler will display to users whose code will break in the +future. After some time, an FCP can be used to move forward with the actual +breakage. + +If the scale of breakage is unknown, a team member or contributor may request a +[crater] run. This is a bot that will compile all crates.io crates and many +public github repos with the compiler with your changes. A report will then be +generated with crates that ceased to compile with or began to compile with your +changes. Crater runs can take a few days to complete. + +[crater]: https://github.com/rust-lang/crater ### Major Changes -TODO: talk about MCP +The compiler team has a special process for large changes, whether or not they +cause breakage. This process is call Major Change Proposal (MCP). MCP is a +relatively lightweight mechanism for getting feedback on large changes to the +compiler (as opposed to a full RFC or a design meeting with the team). + +Example of things that might require MCPs include major refactorings, changes +to important types, or important changes to how the compiler does something. + +**When in doubt, ask on [zulip][z]. We would hate for you to put a lot of work +into a PR that ends up not getting merged!** ### Performance -TODO: Talk about perf runs +Compiler performance is important. We have put a lot of effort over the last +few years into [gradually improving it][perfdash]. + +[perfdash]: https://perf.rust-lang.org/dashboard.html + +If you suspect that your change may cause a performance regression (or +improvement), you can request a "perf run" (your reviewer may also request one +before approving). This is yet another bot that will compile a collection of +benchmarks on a compiler with your changes. The numbers are reported +[here][perf], and you can see a comparison of your changes against the latest +master. + +[perf]: https://perf.rust-lang.org/dashboard.html ## Other Resources From d255b4a0cb5aa41c18d3ffea9a1c8c2e9b6dd6df Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 14:45:37 -0500 Subject: [PATCH 1058/1812] some minor updates --- src/getting-started.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 1ec7b1b26..4207fd1ee 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -67,8 +67,9 @@ computationally expensive, so a beefier machine will help, and I wouldn't recommend trying to build on a Raspberry Pi :P - x86 and ARM are both supported (TODO: confirm) -- Recommended 30GB of free disk space; otherwise, you will have to keep - clearing incremental caches. +- Recommended >=30GB of free disk space; otherwise, you will have to keep + clearing incremental caches. More space is better, the compiler is a bit of a + hog; it's a problem we are aware of. - Recommended >=8GB RAM. - Recommended >=2 cores; more cores really helps. - You will need an internet connection to build; the bootstrapping process @@ -146,7 +147,7 @@ After updating `config.toml`, as mentioned above, you can use `./x.py`: This will take a while, especially the first time. Be wary of accidentally touching or formatting the compiler, as `./x.py` will try to recompile it. -To run the compiler's UI test (the bulk of the test suite): +To run the compiler's UI test suite (the bulk of the test suite): ``` # UI tests @@ -227,6 +228,13 @@ will be reviewed, approved, and merged. This includes most bug fixes, refactorings, and other user-invisible changes. The next few sections talk about exceptions to this rule. +Also, note that is perfectly acceptable to open WIP PRs or GitHub [Draft +PRs][draft]. Some people prefer to do this so they can get feedback along the +way or share their code with a collaborator. Others do this so they can utilize +the CI to build and test their PR (e.g. if you are developing on a laptop). + +[draft]: https://github.blog/2019-02-14-introducing-draft-pull-requests/ + ### New Features Rust has strong backwards-compatibility guarantees. Thus, new features can't From 73d88a1385b2057c83236230b7357a067ae4df7f Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 14:57:37 -0500 Subject: [PATCH 1059/1812] a couple more small changes --- src/SUMMARY.md | 2 +- src/getting-started.md | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f462817c0..4f818fadf 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -5,8 +5,8 @@ --- - [Part 1: Building, debugging, and contributing to Rustc](./part-1-intro.md) - - [About the compiler team](./compiler-team.md) - [Getting Started](./getting-started.md) + - [About the compiler team](./compiler-team.md) - [How to Build and Run the Compiler](./building/how-to-build-and-run.md) - [Suggested Workflows](./building/suggested.md) - [Bootstrapping](./building/bootstrapping.md) diff --git a/src/getting-started.md b/src/getting-started.md index 4207fd1ee..5d78e416b 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -272,7 +272,8 @@ After that, the feature gate can be removed and the feature turned on for all us As mentioned above, Rust has strong backwards-compatibility guarantees. To this end, we are reluctant to make breaking changes. However, sometimes they are -needed to correct compiler bugs (e.g. code that compiled but should not). +needed to correct compiler bugs (e.g. code that compiled but should not) or +make progress on some features. Depending on the scale of the breakage, there are a few different actions that can be taken. If the reviewer believes the breakage is very minimal (i.e. very From b5e41a5e0cd95822061af3fa4c2934d758deaf28 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 19:28:36 -0500 Subject: [PATCH 1060/1812] mention incremental disk space --- src/getting-started.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/getting-started.md b/src/getting-started.md index 5d78e416b..3c3781da8 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -84,6 +84,11 @@ Like `cargo`, the build system will use as many cores as possible. Sometimes this can cause you to run low on memory. You can use `-j` to adjust the number concurrent jobs. +Also, if you don't have too much free disk space, you may want to turn off +incremental compilation (see the "Configuring" section below). This will make +compilation take longer, but will save a ton of space from the incremental +caches. + ### Cloning You can just do a normal git clone: From 2abbee9b5c0077ab9e2023ef19d12ec0c637c040 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 2 Jun 2020 19:53:54 -0500 Subject: [PATCH 1061/1812] fix link --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 3c3781da8..9fa76817a 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -327,7 +327,7 @@ benchmarks on a compiler with your changes. The numbers are reported [here][perf], and you can see a comparison of your changes against the latest master. -[perf]: https://perf.rust-lang.org/dashboard.html +[perf]: https://perf.rust-lang.org ## Other Resources From e2620a8199a3f423dbed6a949ebf743d2d570445 Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 5 Jun 2020 11:24:47 -0500 Subject: [PATCH 1062/1812] add a bit more --- src/getting-started.md | 66 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 62 insertions(+), 4 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 9fa76817a..2d11edf8e 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -147,16 +147,24 @@ After updating `config.toml`, as mentioned above, you can use `./x.py`: ```shell # Build the compiler (stage 1) ./x.py build --stage 1 + +# Subsequent builds +./x.py build --stage 1 --keep-stage 1 ``` This will take a while, especially the first time. Be wary of accidentally touching or formatting the compiler, as `./x.py` will try to recompile it. +**NOTE**: The `--keep-stage 1` will _assume_ that the stage 0 standard library +does not need to be rebuilt, which is usually true, which will save some time. +However, if you are changing certain parts of the compiler, this may lead to +weird errors. Feel free to ask on [zulip][z] if you are running into issues. + To run the compiler's UI test suite (the bulk of the test suite): ``` # UI tests -./x.py test --stage 1 src/test/ui +./x.py test --stage 1 src/test/ui [--keep-stage 1] ``` This will build the compiler first, if needed. @@ -190,15 +198,65 @@ You can use `RUSTC_LOG=XXX` to get debug logging. [Read more here][logging]. ### Building and Testing `std`/`core`/`alloc`/`test`/`proc_macro`/etc. -TODO +To contribute to `libstd`, you don't need to build the compiler unless you are +planning to use a recently added nightly feature. Instead, you can just build +stage 0. + +```sh +./x.py build --stage 0 src/libstd +``` + +TODO: how to test? ### Building and Testing `rustdoc` -TODO +`rustdoc` uses `rustc` internals (and, of course, the standard library), so you +will have to build the compiler and `std` once before you can build `rustdoc`. + +The following command will build all of them. Stage 1 should be sufficient, +even though the release version will use the full 2-stage build. + +```sh +# First build +./x.py build --stage 1 src/tools/rustdoc + +# Subsequent builds +./x.py build --stage 1 --keep-stage 1 src/tools/rustdoc +``` + +You can also use `./x.py check` here to do a fast check build. + +TODO: how to test? ### Contributing code to other Rust projects -TODO: talk about things like miri, clippy, chalk, etc +There are a bunch of other projects that one can contribute too outside of the +`rust-lang/rust` repo, including `clippy`, `miri`, `chalk`, and many others. + +These repos might have their own contributing guidelines and procedures. Many +of them are owned by working groups (e.g. `chalk` is largely owned by +WG-traits). For more info, see the documentation in those repos' READMEs. + +### Other ways to contribute + +There are a bunch of other ways you can contribute, especially if you don't +feel comfortable jumping straight into the large `rust-lang/rust` codebase. + +The following tasks are doable without much background knowledge but are +incredibly helpful: + +- [ICE-breakers Cleanup crew][iceb]: find minimal reproductions of ICEs, bisect + regressions, etc. This is a way of helping that saves a ton of time for + others to fix an error later. +- Writing documentation: if you are feeling a bit more intrepid, you could try + to read a part of the code and write doc comments for it. This will help you + to learn some part of the compiler while also producing a useful artifact! +- [Working groups][wg]: there are a bunch of working groups on a wide variety + of rust-related things. + +[iceb]: ./ice-breaker/cleanup-crew.md +[wg]: https://rust-lang.github.io/compiler-team/working-groups/ + ## Contributor Procedures From 5784b6cb92f5868d70ce8249c1dd31ed9fb9c3cb Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 5 Jun 2020 11:25:48 -0500 Subject: [PATCH 1063/1812] add note on submodules --- src/getting-started.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 2d11edf8e..d5a4c51b3 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -97,7 +97,16 @@ You can just do a normal git clone: git clone https://github.com/rust-lang/rust.git ``` -You don't need to clone the submodules at this time. +You don't need to clone the submodules at this time. But if you want to, you +can do the following: + +```sh +# first time +git submodule update --init --recursive + +# subsequent times (to pull new commits) +git submodule update +``` **Pro tip**: if you contribute often, you may want to look at the git worktrees tip in [this chapter][suggested]. From 5ff627e2d573df70b3cb7750654c06b1067f2395 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 5 Jun 2020 11:29:03 -0500 Subject: [PATCH 1064/1812] Apply suggestions from code review Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/getting-started.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index d5a4c51b3..21f52ca9c 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -132,7 +132,7 @@ the following settings: - `incremental = true`: enables incremental compilation of the compiler itself. This is turned off by default because it's technically unsound. Sometimes this will cause weird crashes, but it can really speed things up. -- `llvm-config`: enable building with system LLVM. [See this chapter][sysllvm] +- `llvm-config`: enables building with system LLVM. [See this chapter][sysllvm] for more info. This avoids building LLVM, which can take a while. [sysllvm]: ./building/suggested.html#building-with-system-llvm @@ -274,7 +274,7 @@ highlights, but there are a lot more details, which we will link to below. ### Code Review -When you open a PR on the `rust-lang/rust` repo, a bot called `@highfive` will +When you open a PR on the `rust-lang/rust` repo, a bot called `@rust-highfive` will automatically assign a reviewer to the PR. The reviewer is the person that will approve the PR to be tested and merged. If you want a specific reviewer (e.g. a team member you've been working with), you can specifically request them by @@ -334,7 +334,7 @@ The feature then needs to be implemented behind a feature gate, which prevents it from being accidentally used. Finally, somebody may propose stabilizing the feature in an upcoming version of -Rust. This requires an FCP (see below) to get the approval of the relevant teams. +Rust. This requires a Final Comment Period (see below) to get the approval of the relevant teams. After that, the feature gate can be removed and the feature turned on for all users. @@ -400,6 +400,6 @@ master. - This guide: talks about how `rustc` works - [The t-compiler zulip][z] -- [The compiler's documentation (rustdocs)](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/) +- [The compiler's documentation (rustdocs)](https://doc.rust-lang.org/nightly/nightly-rustc/) TODO: am I missing any? From 69baf677ef2fe2eef8e62fffbe342368725b2970 Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 5 Jun 2020 11:28:36 -0500 Subject: [PATCH 1065/1812] add forge --- src/getting-started.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/getting-started.md b/src/getting-started.md index 21f52ca9c..dfc0a843c 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -401,5 +401,6 @@ master. - This guide: talks about how `rustc` works - [The t-compiler zulip][z] - [The compiler's documentation (rustdocs)](https://doc.rust-lang.org/nightly/nightly-rustc/) +- [The Forge](https://forge.rust-lang.org/) has more documentation about various procedures. TODO: am I missing any? From aa9b3ecc2278ca0a07be1cbf6bec83a64b5d5ad9 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 17 Jun 2020 12:51:41 -0500 Subject: [PATCH 1066/1812] Apply suggestions from code review Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> Co-authored-by: Joshua Nelson Co-authored-by: Phil Hansch --- src/getting-started.md | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index dfc0a843c..d7d7f9314 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -173,7 +173,11 @@ To run the compiler's UI test suite (the bulk of the test suite): ``` # UI tests -./x.py test --stage 1 src/test/ui [--keep-stage 1] +# First build +./x.py test --stage 1 src/test/ui + +# Subsequent builds +./x.py test --stage 1 src/test/ui --keep-stage 1 ``` This will build the compiler first, if needed. @@ -215,7 +219,9 @@ stage 0. ./x.py build --stage 0 src/libstd ``` -TODO: how to test? +```sh +./x.py test --stage 0 src/libstd +``` ### Building and Testing `rustdoc` @@ -235,11 +241,22 @@ even though the release version will use the full 2-stage build. You can also use `./x.py check` here to do a fast check build. -TODO: how to test? +Rustdoc has two types of tests: content tests and UI tests. + +```sh +# Content tests +./x.py test --stage 1 src/test/rustdoc + +# UI tests +./x.py test --stage 1 src/test/rustdoc-ui + +# Both at once +./x.py test --stage 1 src/test/rustdoc* +``` ### Contributing code to other Rust projects -There are a bunch of other projects that one can contribute too outside of the +There are a bunch of other projects that you can contribute to outside of the `rust-lang/rust` repo, including `clippy`, `miri`, `chalk`, and many others. These repos might have their own contributing guidelines and procedures. Many @@ -300,7 +317,7 @@ will be reviewed, approved, and merged. This includes most bug fixes, refactorings, and other user-invisible changes. The next few sections talk about exceptions to this rule. -Also, note that is perfectly acceptable to open WIP PRs or GitHub [Draft +Also, note that it is perfectly acceptable to open WIP PRs or GitHub [Draft PRs][draft]. Some people prefer to do this so they can get feedback along the way or share their code with a collaborator. Others do this so they can utilize the CI to build and test their PR (e.g. if you are developing on a laptop). @@ -370,7 +387,7 @@ changes. Crater runs can take a few days to complete. ### Major Changes The compiler team has a special process for large changes, whether or not they -cause breakage. This process is call Major Change Proposal (MCP). MCP is a +cause breakage. This process is called a Major Change Proposal (MCP). MCP is a relatively lightweight mechanism for getting feedback on large changes to the compiler (as opposed to a full RFC or a design meeting with the team). @@ -402,5 +419,6 @@ master. - [The t-compiler zulip][z] - [The compiler's documentation (rustdocs)](https://doc.rust-lang.org/nightly/nightly-rustc/) - [The Forge](https://forge.rust-lang.org/) has more documentation about various procedures. +- `#contribute`, `#compiler`, and `#rustdoc` on [Discord](https://discord.gg/rust-lang). TODO: am I missing any? From e72e2c5613b5e77079a5969ae9ba2bd6409e1937 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 12:53:46 -0500 Subject: [PATCH 1067/1812] python 3 also --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index d7d7f9314..9715403e6 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -60,7 +60,7 @@ advice.**][suggested] ### System Requirements [**See this chapter for detailed software requirements.**](./building/prerequisites.md) -Most notably, you will need Python 2 to run `x.py`. +Most notably, you will need Python 2 or 3 to run `x.py`. There are no hard hardware requirements, but building the compiler is computationally expensive, so a beefier machine will help, and I wouldn't From db004ad24f52fa8b12eae9c1d45264b52a3ee65a Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 12:56:57 -0500 Subject: [PATCH 1068/1812] add a note about disk space --- src/getting-started.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 9715403e6..755034cf2 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -129,9 +129,10 @@ Then, edit `config.toml`. You will need to search for, uncomment, and update the following settings: - `debug = true`: enables debug symbols and `debug!` logging, takes a bit longer to compile. -- `incremental = true`: enables incremental compilation of the compiler itself. - This is turned off by default because it's technically unsound. Sometimes - this will cause weird crashes, but it can really speed things up. +- `incremental = true`: enables incremental compilation of the compiler itself, + which can significantly speed things up. This is turned off by default + because it's technically unsound; sometimes this will cause weird crashes. + Also, it can consume a lot of disk space. - `llvm-config`: enables building with system LLVM. [See this chapter][sysllvm] for more info. This avoids building LLVM, which can take a while. From e1c7b6ce92426ba7074bab87f03b91f6df18569f Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 13:45:55 -0500 Subject: [PATCH 1069/1812] Slightly reorganize to first present the slow command then the fast commands --- src/getting-started.md | 103 +++++++++++++++++++++++++++++------------ 1 file changed, 74 insertions(+), 29 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 755034cf2..466394577 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -66,7 +66,6 @@ There are no hard hardware requirements, but building the compiler is computationally expensive, so a beefier machine will help, and I wouldn't recommend trying to build on a Raspberry Pi :P -- x86 and ARM are both supported (TODO: confirm) - Recommended >=30GB of free disk space; otherwise, you will have to keep clearing incremental caches. More space is better, the compiler is a bit of a hog; it's a problem we are aware of. @@ -125,14 +124,15 @@ In the top level of the repo: cp config.toml.example config.toml ``` -Then, edit `config.toml`. You will need to search for, uncomment, and update +Then, edit `config.toml`. You may want to search for, uncomment, and update the following settings: - `debug = true`: enables debug symbols and `debug!` logging, takes a bit longer to compile. - `incremental = true`: enables incremental compilation of the compiler itself, which can significantly speed things up. This is turned off by default - because it's technically unsound; sometimes this will cause weird crashes. - Also, it can consume a lot of disk space. + because it's technically unsound; sometimes it will cause weird crashes. + Also, it can consume a lot of disk space. This has the same effect as the + `-i` or `--incremental` flags. - `llvm-config`: enables building with system LLVM. [See this chapter][sysllvm] for more info. This avoids building LLVM, which can take a while. @@ -140,19 +140,44 @@ the following settings: ### `./x.py` Intro -`rustc` is a bootstrapping compiler because it is written in Rust. Where do you +`rustc` is a _bootstrapping_ compiler because it is written in Rust. Where do you get the original compiler from? We use the current beta compiler to build the compiler. Then, we use that compiler to build itself. Thus, -`rustc` has a 2-stage build. +`rustc` has a 2-stage build. You can read more about bootstrapping +[here][boot], but you don't need more to contribute. + +[boot]: ./building/bootstrapping.md We have a special tool `./x.py` that drives this process. It is used for compiling the compiler, the standard libraries, and `rustdoc`. It is also used for driving CI and building the final release artifacts. +Unfortunately, a proper 2-stage build takes a long time depending on your +hardware, but it is the only correct way to build everything (e.g. it's what +the CI and release processes use). **However, in most cases, you can get by +without a full 2-stage build**. In the following section, we give instructions +for how to do "the correct thing", but then we also give various tips to speed +things up. + ### Building and Testing `rustc` -For most contributions, you only need to build stage 1, which saves a lot of time. -After updating `config.toml`, as mentioned above, you can use `./x.py`: +To do a full 2-stage build of the whole compiler, you should run this (after +updating `config.toml` as mentioned above): + +```sh +./x.py build +``` + +In the process, this will also necessarily build the standard libraries, and it +will build `rustdoc` (which doesn't take too long). + +To build and test everything: + +```sh +./x.py test +``` + +For most contributions, you only need to build stage 1, which saves a lot of time: ```shell # Build the compiler (stage 1) @@ -170,10 +195,16 @@ does not need to be rebuilt, which is usually true, which will save some time. However, if you are changing certain parts of the compiler, this may lead to weird errors. Feel free to ask on [zulip][z] if you are running into issues. -To run the compiler's UI test suite (the bulk of the test suite): +This runs a ton of tests and takes a long time to complete. If you are +working on `rustc`, you can usually get by with only the [UI tests][uitests]. These +test are mostly for the frontend of the compiler, so if you are working on LLVM +or codegen, this shortcut will _not_ test your changes. You can read more about the +different test suites [in this chapter][testing]. + +[uitests]: ./tests/adding.html#ui +[testing]: https://rustc-dev-guide.rust-lang.org/tests/intro.html ``` -# UI tests # First build ./x.py test --stage 1 src/test/ui @@ -181,22 +212,19 @@ To run the compiler's UI test suite (the bulk of the test suite): ./x.py test --stage 1 src/test/ui --keep-stage 1 ``` -This will build the compiler first, if needed. - -This will be enough for most people. Notably, though, it mostly tests the -compiler frontend, not codegen or debug info. You can read more about the -different test suites [in this chapter][testing]. - -[testing]: https://rustc-dev-guide.rust-lang.org/tests/intro.html - -If you only want to check that the compiler builds (without actually building -it) you can run the following: +While working on the compiler, it can be helpful to see if the code just +compiles (similar to `cargo check`) without actually building it. You can do +this with: ```shell ./x.py check ``` -To format the code: +This command is really fast (relative to the other commands). It usually +completes in a couple of minutes on my laptop. + +Finally, the CI ensures that the codebase is using consistent style. To format +the code: ```shell # Actually format @@ -206,15 +234,27 @@ To format the code: ./x.py fmt --check ``` -You can use `RUSTC_LOG=XXX` to get debug logging. [Read more here][logging]. +*Note*: we don't use stable `rustfmt`; we use a pinned version with a special +config, so this may result in different style from normal `rustfmt` if you have +format-on-save turned on. It's a good habit to run `./x.py fmt` before every +commit, as this reduces conflicts later. + +On last thing: you can use `RUSTC_LOG=XXX` to get debug logging. [Read more +here][logging]. Notice the `C` in `RUSTC_LOG`. Other than that, it uses normal +[`env_logger`][envlog] syntax. +[envlog]: https://crates.io/crates/env_logger [logging]: ./compiler-debugging.html#getting-logging-output ### Building and Testing `std`/`core`/`alloc`/`test`/`proc_macro`/etc. -To contribute to `libstd`, you don't need to build the compiler unless you are +As before, technically the proper way to build one of these libraries is to use +the stage-2 compiler, which of course requires a 2-stage build, described above +(`./x.py build`). + +In practice, though, you don't need to build the compiler unless you are planning to use a recently added nightly feature. Instead, you can just build -stage 0. +stage 0 (i.e. which basically just uses the current beta compiler). ```sh ./x.py build --stage 0 src/libstd @@ -224,13 +264,16 @@ stage 0. ./x.py test --stage 0 src/libstd ``` +(The same works for `src/liballoc`, `src/libcore`, etc.) + ### Building and Testing `rustdoc` `rustdoc` uses `rustc` internals (and, of course, the standard library), so you will have to build the compiler and `std` once before you can build `rustdoc`. +As before, you can use `./x.py build` to do this. -The following command will build all of them. Stage 1 should be sufficient, -even though the release version will use the full 2-stage build. +However, in practice, stage 1 should be sufficient. The first time you build, +the stage-1 compiler will also be built. ```sh # First build @@ -240,7 +283,11 @@ even though the release version will use the full 2-stage build. ./x.py build --stage 1 --keep-stage 1 src/tools/rustdoc ``` -You can also use `./x.py check` here to do a fast check build. +As with the compiler, you can do a fast check build: + +```sh +./x.py check +``` Rustdoc has two types of tests: content tests and UI tests. @@ -421,5 +468,3 @@ master. - [The compiler's documentation (rustdocs)](https://doc.rust-lang.org/nightly/nightly-rustc/) - [The Forge](https://forge.rust-lang.org/) has more documentation about various procedures. - `#contribute`, `#compiler`, and `#rustdoc` on [Discord](https://discord.gg/rust-lang). - -TODO: am I missing any? From 814d27d7600b100fce2b0699d94ac310475365d8 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 17 Jun 2020 14:47:47 -0500 Subject: [PATCH 1070/1812] Better wording Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 466394577..cb87210ad 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -140,7 +140,7 @@ the following settings: ### `./x.py` Intro -`rustc` is a _bootstrapping_ compiler because it is written in Rust. Where do you +`rustc` is a _bootstrapping_ compiler, which means that it is written in Rust. So where do you get the original compiler from? We use the current beta compiler to build the compiler. Then, we use that compiler to build itself. Thus, `rustc` has a 2-stage build. You can read more about bootstrapping From 46099c094e4cc334dcdcb44700527c7bec070663 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 17 Jun 2020 17:08:42 -0500 Subject: [PATCH 1071/1812] Apply suggestions from code review Co-authored-by: LeSeulArtichaut --- src/getting-started.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index cb87210ad..e7c270079 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -2,7 +2,7 @@ This documentation is _not_ intended to be comprehensive; it is meant to be a quick guide for the most useful things. For more information, [see this -chapter](./building/how-to-build-and-run.md). +chapter on how to build and run the compiler](./building/how-to-build-and-run.md). ## Asking Questions @@ -77,7 +77,7 @@ recommend trying to build on a Raspberry Pi :P Building the compiler takes more than half an hour on my moderately powerful laptop. The first time you build the compiler, LLVM will also be built unless -you use system LLVM (see below). +you use your system's LLVM (see below). Like `cargo`, the build system will use as many cores as possible. Sometimes this can cause you to run low on memory. You can use `-j` to adjust the number @@ -140,16 +140,16 @@ the following settings: ### `./x.py` Intro -`rustc` is a _bootstrapping_ compiler, which means that it is written in Rust. So where do you +`rustc` is a _bootstrapping_ compiler, which means that it is written in Rust and thus needs to be compiled by itself. So where do you get the original compiler from? We use the current beta compiler -to build the compiler. Then, we use that compiler to build itself. Thus, +to build a new compiler. Then, we use that compiler to build itself. Thus, `rustc` has a 2-stage build. You can read more about bootstrapping -[here][boot], but you don't need more to contribute. +[here][boot], but you don't need to know much more to contribute. [boot]: ./building/bootstrapping.md We have a special tool `./x.py` that drives this process. It is used for -compiling the compiler, the standard libraries, and `rustdoc`. It is also used +building the compiler, the standard libraries, and `rustdoc`. It is also used for driving CI and building the final release artifacts. Unfortunately, a proper 2-stage build takes a long time depending on your From c99d5245be2a9dd95416d21711e1184af80e8e6b Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 17:18:34 -0500 Subject: [PATCH 1072/1812] address review comments --- src/getting-started.md | 41 ++++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index e7c270079..b1ed6bc0e 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -77,14 +77,16 @@ recommend trying to build on a Raspberry Pi :P Building the compiler takes more than half an hour on my moderately powerful laptop. The first time you build the compiler, LLVM will also be built unless -you use your system's LLVM (see below). +you use your system's LLVM ([see below][configsec]). + +[configsec]: #configuring-the-compiler Like `cargo`, the build system will use as many cores as possible. Sometimes this can cause you to run low on memory. You can use `-j` to adjust the number concurrent jobs. Also, if you don't have too much free disk space, you may want to turn off -incremental compilation (see the "Configuring" section below). This will make +incremental compilation ([see below][configsec]). This will make compilation take longer, but will save a ton of space from the incremental caches. @@ -92,7 +94,7 @@ caches. You can just do a normal git clone: -```shell +```sh git clone https://github.com/rust-lang/rust.git ``` @@ -107,9 +109,6 @@ git submodule update --init --recursive git submodule update ``` -**Pro tip**: if you contribute often, you may want to look at the git worktrees -tip in [this chapter][suggested]. - ### Configuring the Compiler The compiler has a configuration file which contains a ton of settings. We will @@ -120,7 +119,7 @@ this chapter for more info][config]. In the top level of the repo: -```shell +```sh cp config.toml.example config.toml ``` @@ -134,13 +133,16 @@ the following settings: Also, it can consume a lot of disk space. This has the same effect as the `-i` or `--incremental` flags. - `llvm-config`: enables building with system LLVM. [See this chapter][sysllvm] - for more info. This avoids building LLVM, which can take a while. + for more info. This avoids building LLVM, which can take a while (45 minutes + on my laptop; others have reported 15 minutes or faster with incremental + compilation). [sysllvm]: ./building/suggested.html#building-with-system-llvm ### `./x.py` Intro -`rustc` is a _bootstrapping_ compiler, which means that it is written in Rust and thus needs to be compiled by itself. So where do you +`rustc` is a _bootstrapping_ compiler, which means that it is written in Rust +and thus needs to be compiled by itself. So where do you get the original compiler from? We use the current beta compiler to build a new compiler. Then, we use that compiler to build itself. Thus, `rustc` has a 2-stage build. You can read more about bootstrapping @@ -179,7 +181,7 @@ To build and test everything: For most contributions, you only need to build stage 1, which saves a lot of time: -```shell +```sh # Build the compiler (stage 1) ./x.py build --stage 1 @@ -216,7 +218,7 @@ While working on the compiler, it can be helpful to see if the code just compiles (similar to `cargo check`) without actually building it. You can do this with: -```shell +```sh ./x.py check ``` @@ -226,7 +228,7 @@ completes in a couple of minutes on my laptop. Finally, the CI ensures that the codebase is using consistent style. To format the code: -```shell +```sh # Actually format ./x.py fmt @@ -237,7 +239,9 @@ the code: *Note*: we don't use stable `rustfmt`; we use a pinned version with a special config, so this may result in different style from normal `rustfmt` if you have format-on-save turned on. It's a good habit to run `./x.py fmt` before every -commit, as this reduces conflicts later. +commit, as this reduces conflicts later. The pinned verson is built under +`build//stage0/bin/rustfmt`, so if you want, you can use it for a +single file or for format-on-save in your editor, which can be faster than `./x.py fmt`. On last thing: you can use `RUSTC_LOG=XXX` to get debug logging. [Read more here][logging]. Notice the `C` in `RUSTC_LOG`. Other than that, it uses normal @@ -347,8 +351,10 @@ writing `r? @user` (e.g. `r? @eddyb`) in either the original post or a followup comment. The reviewer may request some changes using the GitHub code review interface. -They may also request special procedures (such as a crater run; see below) for -some PRs. +They may also request special procedures (such as a [crater] run; [see +below][break]) for some PRs. + +[break]: #breaking-changes When the PR is ready to be merged, the reviewer will issue a command to `@bors`, the CI bot. Usually, this is `@bors r+` or `@bors r=@user` to approve @@ -386,7 +392,7 @@ channels: stable, beta, and nightly. In order to implement a new feature, usually you will need to go through [the RFC process][rfc] to propose a design, have discussions, etc. In some cases, -small features can be added with only an FCP (see below). If in doubt, ask the +small features can be added with only an FCP ([see below][break]). If in doubt, ask the compiler, language, or libs team (whichever is most relevant). [rfc]: https://github.com/rust-lang/rfcs/blob/master/README.md @@ -399,7 +405,8 @@ The feature then needs to be implemented behind a feature gate, which prevents it from being accidentally used. Finally, somebody may propose stabilizing the feature in an upcoming version of -Rust. This requires a Final Comment Period (see below) to get the approval of the relevant teams. +Rust. This requires a Final Comment Period ([see below][break]) to get the +approval of the relevant teams. After that, the feature gate can be removed and the feature turned on for all users. From d90acc8e37bc06bcf884c4fd86f1f3071c7edc0b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 18 Jun 2020 11:55:58 -0500 Subject: [PATCH 1073/1812] LeSeulArtichaut wording/typo fixes Co-authored-by: LeSeulArtichaut --- src/getting-started.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index b1ed6bc0e..628326763 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -323,7 +323,7 @@ feel comfortable jumping straight into the large `rust-lang/rust` codebase. The following tasks are doable without much background knowledge but are incredibly helpful: -- [ICE-breakers Cleanup crew][iceb]: find minimal reproductions of ICEs, bisect +- [Cleanup crew][iceb]: find minimal reproductions of ICEs, bisect regressions, etc. This is a way of helping that saves a ton of time for others to fix an error later. - Writing documentation: if you are feeling a bit more intrepid, you could try @@ -357,7 +357,7 @@ below][break]) for some PRs. [break]: #breaking-changes When the PR is ready to be merged, the reviewer will issue a command to -`@bors`, the CI bot. Usually, this is `@bors r+` or `@bors r=@user` to approve +`@bors`, the CI bot. Usually, this is `@bors r+` or `@bors r=user` to approve a PR (there are few other commands, but they are less relevant here). This puts the PR in [bors's queue][bors] to be tested and merged. Be patient; this can take a while and the queue can sometimes be long. PRs are never merged by hand. @@ -410,7 +410,7 @@ approval of the relevant teams. After that, the feature gate can be removed and the feature turned on for all users. -[For more details on this process, see this chapter.](./implementing_new_features.md) +[For more details on this process, see this chapter on implementing new features.](./implementing_new_features.md) ### Breaking Changes @@ -428,7 +428,7 @@ discuss the issue and either accept, reject, or request changes on the PR. If the scale of breakage is large, a deprecation warning may be needed. This is a warning that the compiler will display to users whose code will break in the -future. After some time, an FCP can be used to move forward with the actual +future. After some time, an FCP can be used to move forward with the actual breakage. If the scale of breakage is unknown, a team member or contributor may request a @@ -449,7 +449,7 @@ compiler (as opposed to a full RFC or a design meeting with the team). Example of things that might require MCPs include major refactorings, changes to important types, or important changes to how the compiler does something. -**When in doubt, ask on [zulip][z]. We would hate for you to put a lot of work +**When in doubt, ask on [zulip][z]. It would be a shame to put a lot of work into a PR that ends up not getting merged!** ### Performance From f880b1b21aea511328540cc5e75ecebbab7ce99b Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 18 Jun 2020 12:09:50 -0500 Subject: [PATCH 1074/1812] address a bunch of review comments --- src/getting-started.md | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 628326763..5dc9f4d71 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -163,6 +163,20 @@ things up. ### Building and Testing `rustc` +Here is a summary of the different commands for reference, but you probably +should still read the rest of the section: + +| Command | When to use it | +| --- | --- | +| `x.py check` | Quick check to see if things compile; rust-analyzer can run this automatically for you | +| `x.py build --stage 1` | Build just the 1st stage of the compiler; this is faster than building stage 2 and usually good enough | +| `x.py build --stage 1 --keep-stage 1` | Build the 1st stage of the compiler and skips rebuilding the library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | +| `x.py test --stage 1` | Run the test suite using the stage1 compiler (first build) | +| `x.py test --stage 1 --keep-stage 1` | Run the test suite using the stage1 compiler (subsequent builds) | +| `x.py test --stage 1 --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. | +| `x.py build` | Do a full 2-stage build. You almost never want to do this. | +| `x.py test` | Do a full 2-stage build and run all tests. You almost never want to do this. | + To do a full 2-stage build of the whole compiler, you should run this (after updating `config.toml` as mentioned above): @@ -206,7 +220,7 @@ different test suites [in this chapter][testing]. [uitests]: ./tests/adding.html#ui [testing]: https://rustc-dev-guide.rust-lang.org/tests/intro.html -``` +```sh # First build ./x.py test --stage 1 src/test/ui @@ -214,6 +228,13 @@ different test suites [in this chapter][testing]. ./x.py test --stage 1 src/test/ui --keep-stage 1 ``` +If your changes impact test output, you can use `--bless` to automatically +update the `.stderr` files of the affected tests: + +```sh +./x.py test --stage 1 src/test/ui --keep-stage 1 --bless +``` + While working on the compiler, it can be helpful to see if the code just compiles (similar to `cargo check`) without actually building it. You can do this with: @@ -223,7 +244,9 @@ this with: ``` This command is really fast (relative to the other commands). It usually -completes in a couple of minutes on my laptop. +completes in a couple of minutes on my laptop. **A common workflow when working +on the compiler is to make changes and repeatedly check with `./x.py check`. +Then, run the tests as shown above when you think things should work.** Finally, the CI ensures that the codebase is using consistent style. To format the code: @@ -447,10 +470,14 @@ relatively lightweight mechanism for getting feedback on large changes to the compiler (as opposed to a full RFC or a design meeting with the team). Example of things that might require MCPs include major refactorings, changes -to important types, or important changes to how the compiler does something. +to important types, or important changes to how the compiler does something, or +smaller user-facing changes. **When in doubt, ask on [zulip][z]. It would be a shame to put a lot of work -into a PR that ends up not getting merged!** +into a PR that ends up not getting merged!** [See this document][mcpinfo] for +more info on MCPs. + +[mcpinfo]: https://forge.rust-lang.org/compiler/mcp.html ### Performance From 6c580ad664c7afc36433ee7bb04d7d49e7d16793 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 18 Jun 2020 12:11:43 -0500 Subject: [PATCH 1075/1812] fix line length --- src/getting-started.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 5dc9f4d71..4cd997200 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -433,7 +433,8 @@ approval of the relevant teams. After that, the feature gate can be removed and the feature turned on for all users. -[For more details on this process, see this chapter on implementing new features.](./implementing_new_features.md) +For more details on this process, see [this chapter on implementing new +features.](./implementing_new_features.md) ### Breaking Changes From 45e540ca813a9a326aafc4e6e78284f1c2958fdf Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 19 Jun 2020 00:55:58 -0500 Subject: [PATCH 1076/1812] new tykind::error convention (#715) --- src/ty.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/src/ty.md b/src/ty.md index 6197a22be..c6affe75a 100644 --- a/src/ty.md +++ b/src/ty.md @@ -280,8 +280,9 @@ There is a `TyKind::Error` that is produced when the user makes a type error. Th we would propagate this type and suppress other errors that come up due to it so as not to overwhelm the user with cascading compiler error messages. -There is an **important invariant** for `TyKind::Error`. You should **never** return the 'error -type' unless you **know** that an error has already been reported to the user. This is usually +There is an **important invariant** for `TyKind::Error`. The compiler should +**never** produce `Error` unless we **know** that an error has already been +reported to the user. This is usually because (a) you just reported it right there or (b) you are propagating an existing Error type (in which case the error should've been reported when that error type was produced). @@ -297,6 +298,19 @@ compilation should succeed, then it will trigger a compiler bug report. [`delay_span_bug`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html#method.delay_span_bug +For added safety, it's not actually possible to produce a `TyKind::Error` value +outside of [`rustc_middle::ty`][ty]; there is a private member of +`TyKind::Error` that prevents it from being constructable elsewhere. Instead, +one should use the [`TyCtxt::ty_error`][terr] or +[`TyCtxt::ty_error_with_message`][terrmsg] methods. These methods automatically +call `delay_span_bug` before returning an interned `Ty` of kind `Error`. If you +were already planning to use [`delay_span_bug`], then you can just pass the +span and message to [`ty_error_with_message`][terrmsg] instead to avoid +delaying a redundant span bug. + +[terr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.ty_error +[terrmsg]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.ty_error_with_message + ## Question: Why not substitute “inside” the `AdtDef`? Recall that we represent a generic struct with `(AdtDef, substs)`. So why bother with this scheme? From a10ba12047ad56f916c69b41b9d6673c246e191e Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 21 Jun 2020 13:25:43 -0500 Subject: [PATCH 1077/1812] Fix master branch links (#757) * fix links * some debugging * more debugging * fix git checkout in ci * try again * already tests with a merge * Typo Co-authored-by: Tshepang Lekhonkhobe Co-authored-by: Tshepang Lekhonkhobe --- .travis.yml | 2 +- src/SUMMARY.md | 1 + src/building/prerequisites.md | 3 +++ src/getting-started.md | 2 +- 4 files changed, 6 insertions(+), 2 deletions(-) create mode 100644 src/building/prerequisites.md diff --git a/.travis.yml b/.travis.yml index 58ed7c562..d375fe9d6 100644 --- a/.travis.yml +++ b/.travis.yml @@ -14,7 +14,7 @@ install: - cargo install mdbook --version 0.3.7 - cargo install mdbook-linkcheck --version 0.5.0 script: -- git rebase origin master # this will exit with an error on conflict +- git log --oneline | head -n 10 - mdbook build notifications: email: diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4f818fadf..c900070a4 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -5,6 +5,7 @@ --- - [Part 1: Building, debugging, and contributing to Rustc](./part-1-intro.md) + - [Prerequisites](./building/prerequisites.md) - [Getting Started](./getting-started.md) - [About the compiler team](./compiler-team.md) - [How to Build and Run the Compiler](./building/how-to-build-and-run.md) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md new file mode 100644 index 000000000..aa13c7524 --- /dev/null +++ b/src/building/prerequisites.md @@ -0,0 +1,3 @@ +# Prerequisites + +** Coming Soon: https://github.com/rust-lang/rustc-dev-guide/pull/723 ** diff --git a/src/getting-started.md b/src/getting-started.md index 4cd997200..a848b0b75 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -355,7 +355,7 @@ incredibly helpful: - [Working groups][wg]: there are a bunch of working groups on a wide variety of rust-related things. -[iceb]: ./ice-breaker/cleanup-crew.md +[iceb]: ./notification-groups/cleanup-crew.md [wg]: https://rust-lang.github.io/compiler-team/working-groups/ From 34df55db770c7bf9fccc24e7c7fffc7d4a4847dc Mon Sep 17 00:00:00 2001 From: ThePuzzlemaker Date: Wed, 10 Jun 2020 21:43:01 -0500 Subject: [PATCH 1078/1812] Add information about size for building the Rust Compiler The Rust codebase is large, not to mention the submodules. It would be helpful for some to have a warning or note about storage required before they spend possible hours to build, only to get a message in some form that they are running out/already out of storage. I did a stage1 build incrementally and it produced a build directory of about 14 gigabytes. --- src/building/how-to-build-and-run.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 18b7d1977..586fa3a2d 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -118,6 +118,9 @@ process described above, producing a usable compiler toolchain from the source code you have checked out. This takes a long time, so it is not usually what you want to actually run (more on this later). +Note that building will require a relatively large amount of storage space. +You may want to have upwards of 10 or 15 gigabytes available to build the compiler. + There are many flags you can pass to the build command of `x.py` that can be beneficial to cutting down compile times or fitting other things you might need to change. They are: From d103f0d897da91eb4afd0c24cae260188ef9b325 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 22 Jun 2020 22:48:15 -0500 Subject: [PATCH 1079/1812] Fix links for now. --- src/appendix/background.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/background.md b/src/appendix/background.md index fe69f6bfd..983f028a0 100644 --- a/src/appendix/background.md +++ b/src/appendix/background.md @@ -286,7 +286,7 @@ does not. - [Practical Foundations for Programming Languages](https://www.cs.cmu.edu/~rwh/pfpl/2nded.pdf) - [Compilers: Principles, Techniques, and Tools, 2nd Edition](https://www.pearson.com/us/higher-education/program/Aho-Compilers-Principles-Techniques-and-Tools-2nd-Edition/PGM167067.html) - [Garbage Collection: Algorithms for Automatic Dynamic Memory Management](https://www.cs.kent.ac.uk/people/staff/rej/gcbook/) -- [Linkers and Loaders](https://linker.iecc.com/) +- [Linkers and Loaders](https://www.amazon.com/Linkers-Kaufmann-Software-Engineering-Programming/dp/1558604960) (There are also free versions of this, but the version we had linked seems to be offline at the moment.) - [Advanced Compiler Design and Implementation](https://www.goodreads.com/book/show/887908.Advanced_Compiler_Design_and_Implementation) - [Building an Optimizing Compiler](https://www.goodreads.com/book/show/2063103.Building_an_Optimizing_Compiler) - [Crafting Interpreters](http://www.craftinginterpreters.com/) From 85248c2803df51b7e78ff7300d7aaa084174fe6a Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 22 Jun 2020 22:54:14 -0500 Subject: [PATCH 1080/1812] whitelist amazon --- book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book.toml b/book.toml index c342c3874..4b029127e 100644 --- a/book.toml +++ b/book.toml @@ -15,6 +15,6 @@ level = 1 [output.linkcheck] follow-web-links = true -exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il" ] +exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il", "www\\.amazon\\.com" ] cache-timeout = 86400 warning-policy = "error" From 175a18c2663cef15749aa0907de576806054e7df Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 18 Jun 2020 18:35:52 -0500 Subject: [PATCH 1081/1812] fix the rebase trick --- .travis.yml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index d375fe9d6..634d73871 100644 --- a/.travis.yml +++ b/.travis.yml @@ -14,6 +14,8 @@ install: - cargo install mdbook --version 0.3.7 - cargo install mdbook-linkcheck --version 0.5.0 script: +- git checkout -b ci +- git rebase origin/master - git log --oneline | head -n 10 - mdbook build notifications: @@ -30,7 +32,7 @@ deploy: fqdn: rustc-dev-guide.rust-lang.org on: branch: master - + # Only build master branch on push branches: only: From 21ee99e5af767d9d4304cc642a4f88e3c0466f7d Mon Sep 17 00:00:00 2001 From: Andy Russell Date: Tue, 23 Jun 2020 09:36:44 -0400 Subject: [PATCH 1082/1812] add suggestion style guide The guide is based on [existing rustdoc]. [existing rustdoc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Diagnostic.html#method.span_suggestion --- src/diagnostics.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/diagnostics.md b/src/diagnostics.md index ce7a37a79..80ab1306c 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -441,6 +441,22 @@ The possible values of [`Applicability`][appl] are: [appl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/enum.Applicability.html +### Suggestion Style Guide + +- Suggestions should not be a question. In particular, language like "did you + mean" should be avoided. Sometimes, it's unclear why a particular suggestion + is being made. In these cases, it's better to be upfront about what the + suggestion is. + + Compare "did you mean: `Foo`" vs. "there is a struct with a similar name: `Foo`". + +- The message should not contain any phrases like "the following", "as shown", + etc. Use the span to convey what is being talked about. +- The message may contain further instruction such as "to do xyz, use" or "to do + xyz, use abc". +- The message may contain a name of a function, variable, or type, but avoid + whole expressions. + ## Lints The compiler linting infrastructure is defined in the [`rustc::lint`][rlint] From f85ef8ec94f3a2d29a8b8cd8023e541030a19404 Mon Sep 17 00:00:00 2001 From: Florian Gilcher Date: Wed, 27 May 2020 23:20:18 +0200 Subject: [PATCH 1083/1812] Add prerequisite page --- src/SUMMARY.md | 1 + src/building/prerequisites.md | 28 +++++++++++++++++++++++++++- 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index c900070a4..b7439d0ea 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -9,6 +9,7 @@ - [Getting Started](./getting-started.md) - [About the compiler team](./compiler-team.md) - [How to Build and Run the Compiler](./building/how-to-build-and-run.md) + - [Prerequisites](./building/prerequisites.md) - [Suggested Workflows](./building/suggested.md) - [Bootstrapping](./building/bootstrapping.md) - [Distribution artifacts](./building/build-install-distribution-artifacts.md) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index aa13c7524..9db18778d 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -1,3 +1,29 @@ # Prerequisites -** Coming Soon: https://github.com/rust-lang/rustc-dev-guide/pull/723 ** +Before building the compiler, you need the following things installed: + +* Python +* A C/C++ compiler toolchain +* cmake +* rustc + +## `rustc` and toolchain installation + +Follow the installation given in the [Rust book](https://doc.rust-lang.org/book/ch01-01-installation.html) to install a working `rustc` and the necessary C/++ toolchain on your platform. + +## Platform specific instructions + +### Windows + +* Install [winget](https://github.com/microsoft/winget-cli) + +Run the following in a terminal: + +``` +winget install python +winget install cmake +``` + +If any of those is installed already, winget will detect it. + +Edit your systems `PATH` variable and add: `C:\Program Files\CMake\bin`. From ca5591815cf17ebb1c4e12cca126e780ba509733 Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 18 Jun 2020 12:35:15 -0500 Subject: [PATCH 1084/1812] address review comments --- src/building/prerequisites.md | 37 ++++++++++++++++++++++++++++++----- 1 file changed, 32 insertions(+), 5 deletions(-) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index 9db18778d..3224c6dab 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -1,15 +1,42 @@ # Prerequisites +## Dependencies + Before building the compiler, you need the following things installed: -* Python -* A C/C++ compiler toolchain -* cmake -* rustc +* `g++` 5.1 or later or `clang++` 3.5 or later +* `python` 3 or 2.7 +* GNU `make` 3.81 or later +* `cmake` 3.4.3 or later +* `curl` +* `git` +* `ssl` which comes in `libssl-dev` or `openssl-devel` +* `pkg-config` if you are compiling on Linux and targeting Linux + +Additionally, if you want to build `rustc` with your system's LLVM, you will +need `llvm-config`. See [this section for more info][sysllvm]. + +[sysllvm]: ./suggested.md#building-with-system-llvm + +## Hardware + +These are not so much requirements as _recommendations_: + +* ~15GB of free disk space (~25GB or more if doing incremental builds). +* >= 8GB RAM +* >= 4 cores +* Internet access + +Beefier machines will lead to much faster builds. If your machine is not very +powerful, a common strategy is to only use `./x.py check` on your local machine +and let the CI build test your changes when you push to a PR branch. ## `rustc` and toolchain installation -Follow the installation given in the [Rust book](https://doc.rust-lang.org/book/ch01-01-installation.html) to install a working `rustc` and the necessary C/++ toolchain on your platform. +Follow the installation given in the [Rust book][install] to install a working +`rustc` and the necessary C/++ toolchain on your platform. + +[install]: https://doc.rust-lang.org/book/ch01-01-installation.html ## Platform specific instructions From 917f7efa28673474531fa9589226b610b5d2ff69 Mon Sep 17 00:00:00 2001 From: Drew Youngwerth Date: Thu, 18 Jun 2020 16:08:57 -0600 Subject: [PATCH 1085/1812] Small spelling fix. --- src/name-resolution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/name-resolution.md b/src/name-resolution.md index d08fe43f3..917f792a4 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -6,7 +6,7 @@ and macro names. In this chapter, we show how this is actually done and more. In fact, we don't do full name resolution during macro expansion -- we only resolve imports and macros at that time. This is required to know what to even -expand. Later, after we have the whole AST, we due full name resolution to +expand. Later, after we have the whole AST, we do full name resolution to resolve all names in the crate. This happens in [`rustc_resolve::late`][late]. Unlike during macro expansion, in this late expansion, we only need to try to resolve a name once, since no new names can be added. If we fail to resolve a From b8065faa0f1ebc55a91fa79b2b7c6af72cfdc560 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 17 Jun 2020 11:04:30 -0400 Subject: [PATCH 1086/1812] Move rustdoc to 'How to build the compiler' The old layout was less about rustdoc and more about the compiler: "Here is an example of a project using rustc_interface". This gives focus to rustdoc on something you might want to work on for its own sake. It also makes the page much easier to find for newcomers. --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b7439d0ea..bdfa4aac8 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -14,6 +14,7 @@ - [Bootstrapping](./building/bootstrapping.md) - [Distribution artifacts](./building/build-install-distribution-artifacts.md) - [Documenting Compiler](./building/compiler-documenting.md) + - [Rustdoc](./rustdoc.md) - [ctags](./building/ctags.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) @@ -54,7 +55,6 @@ - [Part 3: Source Code Representations](./part-3-intro.md) - [Command-line arguments](./cli.md) - [The Rustc Driver and Interface](./rustc-driver.md) - - [Rustdoc](./rustdoc.md) - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) - [Ex: Getting diagnostics through `rustc_interface`](./rustc-driver-getting-diagnostics.md) - [Syntax and the AST](./syntax-intro.md) From 4329b8e91a765ab0053d281500fbb07eaefda5ab Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 17:40:35 -0400 Subject: [PATCH 1087/1812] Split up rustdoc page --- src/SUMMARY.md | 1 + src/rustdoc-internals.md | 197 +++++++++++++++++++++++++++++++++++++++ src/rustdoc.md | 193 +------------------------------------- 3 files changed, 200 insertions(+), 191 deletions(-) create mode 100644 src/rustdoc-internals.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index bdfa4aac8..d80919657 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -51,6 +51,7 @@ - [Salsa](./salsa.md) - [Memory Management in Rustc](./memory.md) - [Parallel Compilation](./parallel-rustc.md) + - [Rustdoc](./rustdoc-internals.md) - [Part 3: Source Code Representations](./part-3-intro.md) - [Command-line arguments](./cli.md) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md new file mode 100644 index 000000000..59cee9f1c --- /dev/null +++ b/src/rustdoc-internals.md @@ -0,0 +1,197 @@ +# Rustdoc internals + +This page describes rustdoc's passes and modes. For an overview of rustdoc, +see [`rustdoc`](./rustdoc.md). + +## From crate to clean + +In `core.rs` are two central items: the `DocContext` struct, and the `run_core` +function. The latter is where rustdoc calls out to rustc to compile a crate to +the point where rustdoc can take over. The former is a state container used +when crawling through a crate to gather its documentation. + +The main process of crate crawling is done in `clean/mod.rs` through several +implementations of the `Clean` trait defined within. This is a conversion +trait, which defines one method: + +```rust,ignore +pub trait Clean { + fn clean(&self, cx: &DocContext) -> T; +} +``` + +`clean/mod.rs` also defines the types for the "cleaned" AST used later on to +render documentation pages. Each usually accompanies an implementation of +`Clean` that takes some AST or HIR type from rustc and converts it into the +appropriate "cleaned" type. "Big" items like modules or associated items may +have some extra processing in its `Clean` implementation, but for the most part +these impls are straightforward conversions. The "entry point" to this module +is the `impl Clean for visit_ast::RustdocVisitor`, which is called by +`run_core` above. + +You see, I actually lied a little earlier: There's another AST transformation +that happens before the events in `clean/mod.rs`. In `visit_ast.rs` is the +type `RustdocVisitor`, which *actually* crawls a `rustc_hir::Crate` to get the first +intermediate representation, defined in `doctree.rs`. This pass is mainly to +get a few intermediate wrappers around the HIR types and to process visibility +and inlining. This is where `#[doc(inline)]`, `#[doc(no_inline)]`, and +`#[doc(hidden)]` are processed, as well as the logic for whether a `pub use` +should get the full page or a "Reexport" line in the module page. + +The other major thing that happens in `clean/mod.rs` is the collection of doc +comments and `#[doc=""]` attributes into a separate field of the Attributes +struct, present on anything that gets hand-written documentation. This makes it +easier to collect this documentation later in the process. + +The primary output of this process is a `clean::Crate` with a tree of Items +which describe the publicly-documentable items in the target crate. + +### Hot potato + +Before moving on to the next major step, a few important "passes" occur over +the documentation. These do things like combine the separate "attributes" into +a single string and strip leading whitespace to make the document easier on the +markdown parser, or drop items that are not public or deliberately hidden with +`#[doc(hidden)]`. These are all implemented in the `passes/` directory, one +file per pass. By default, all of these passes are run on a crate, but the ones +regarding dropping private/hidden items can be bypassed by passing +`--document-private-items` to rustdoc. Note that unlike the previous set of AST +transformations, the passes happen on the _cleaned_ crate. + +(Strictly speaking, you can fine-tune the passes run and even add your own, but +[we're trying to deprecate that][44136]. If you need finer-grain control over +these passes, please let us know!) + +[44136]: https://github.com/rust-lang/rust/issues/44136 + +Here is current (as of this writing) list of passes: + +- `propagate-doc-cfg` - propagates `#[doc(cfg(...))]` to child items. +- `collapse-docs` concatenates all document attributes into one document + attribute. This is necessary because each line of a doc comment is given as a + separate doc attribute, and this will combine them into a single string with + line breaks between each attribute. +- `unindent-comments` removes excess indentation on comments in order for + markdown to like it. This is necessary because the convention for writing + documentation is to provide a space between the `///` or `//!` marker and the + text, and stripping that leading space will make the text easier to parse by + the Markdown parser. (In the past, the markdown parser used was not + Commonmark- compliant, which caused annoyances with extra whitespace but this + seems to be less of an issue today.) +- `strip-priv-imports` strips all private import statements (`use`, `extern + crate`) from a crate. This is necessary because rustdoc will handle *public* + imports by either inlining the item's documentation to the module or creating + a "Reexports" section with the import in it. The pass ensures that all of + these imports are actually relevant to documentation. +- `strip-hidden` and `strip-private` strip all `doc(hidden)` and private items + from the output. `strip-private` implies `strip-priv-imports`. Basically, the + goal is to remove items that are not relevant for public documentation. + +## From clean to crate + +This is where the "second phase" in rustdoc begins. This phase primarily lives +in the `html/` folder, and it all starts with `run()` in `html/render.rs`. This +code is responsible for setting up the `Context`, `SharedContext`, and `Cache` +which are used during rendering, copying out the static files which live in +every rendered set of documentation (things like the fonts, CSS, and JavaScript +that live in `html/static/`), creating the search index, and printing out the +source code rendering, before beginning the process of rendering all the +documentation for the crate. + +Several functions implemented directly on `Context` take the `clean::Crate` and +set up some state between rendering items or recursing on a module's child +items. From here the "page rendering" begins, via an enormous `write!()` call +in `html/layout.rs`. The parts that actually generate HTML from the items and +documentation occurs within a series of `std::fmt::Display` implementations and +functions that pass around a `&mut std::fmt::Formatter`. The top-level +implementation that writes out the page body is the `impl<'a> fmt::Display for +Item<'a>` in `html/render.rs`, which switches out to one of several `item_*` +functions based on the kind of `Item` being rendered. + +Depending on what kind of rendering code you're looking for, you'll probably +find it either in `html/render.rs` for major items like "what sections should I +print for a struct page" or `html/format.rs` for smaller component pieces like +"how should I print a where clause as part of some other item". + +Whenever rustdoc comes across an item that should print hand-written +documentation alongside, it calls out to `html/markdown.rs` which interfaces +with the Markdown parser. This is exposed as a series of types that wrap a +string of Markdown, and implement `fmt::Display` to emit HTML text. It takes +special care to enable certain features like footnotes and tables and add +syntax highlighting to Rust code blocks (via `html/highlight.rs`) before +running the Markdown parser. There's also a function in here +(`find_testable_code`) that specifically scans for Rust code blocks so the +test-runner code can find all the doctests in the crate. + +### From soup to nuts + +(alternate title: ["An unbroken thread that stretches from those first `Cell`s +to us"][video]) + +[video]: https://www.youtube.com/watch?v=hOLAGYmUQV0 + +It's important to note that the AST cleaning can ask the compiler for +information (crucially, `DocContext` contains a `TyCtxt`), but page rendering +cannot. The `clean::Crate` created within `run_core` is passed outside the +compiler context before being handed to `html::render::run`. This means that a +lot of the "supplementary data" that isn't immediately available inside an +item's definition, like which trait is the `Deref` trait used by the language, +needs to be collected during cleaning, stored in the `DocContext`, and passed +along to the `SharedContext` during HTML rendering. This manifests as a bunch +of shared state, context variables, and `RefCell`s. + +Also of note is that some items that come from "asking the compiler" don't go +directly into the `DocContext` - for example, when loading items from a foreign +crate, rustdoc will ask about trait implementations and generate new `Item`s +for the impls based on that information. This goes directly into the returned +`Crate` rather than roundabout through the `DocContext`. This way, these +implementations can be collected alongside the others, right before rendering +the HTML. + +## Other tricks up its sleeve + +All this describes the process for generating HTML documentation from a Rust +crate, but there are couple other major modes that rustdoc runs in. It can also +be run on a standalone Markdown file, or it can run doctests on Rust code or +standalone Markdown files. For the former, it shortcuts straight to +`html/markdown.rs`, optionally including a mode which inserts a Table of +Contents to the output HTML. + +For the latter, rustdoc runs a similar partial-compilation to get relevant +documentation in `test.rs`, but instead of going through the full clean and +render process, it runs a much simpler crate walk to grab *just* the +hand-written documentation. Combined with the aforementioned +"`find_testable_code`" in `html/markdown.rs`, it builds up a collection of +tests to run before handing them off to the libtest test runner. One notable +location in `test.rs` is the function `make_test`, which is where hand-written +doctests get transformed into something that can be executed. + +Some extra reading about `make_test` can be found +[here](https://quietmisdreavus.net/code/2018/02/23/how-the-doctests-get-made/). + +## Dotting i's and crossing t's + +So that's rustdoc's code in a nutshell, but there's more things in the repo +that deal with it. Since we have the full `compiletest` suite at hand, there's +a set of tests in `src/test/rustdoc` that make sure the final HTML is what we +expect in various situations. These tests also use a supplementary script, +`src/etc/htmldocck.py`, that allows it to look through the final HTML using +XPath notation to get a precise look at the output. The full description of all +the commands available to rustdoc tests is in `htmldocck.py`. + +To use multiple crates in a rustdoc test, add `// aux-build:filename.rs` +to the top of the test file. `filename.rs` should be placed in an `auxiliary` +directory relative to the test file with the comment. If you need to build +docs for the auxiliary file, use `// build-aux-docs`. + +In addition, there are separate tests for the search index and rustdoc's +ability to query it. The files in `src/test/rustdoc-js` each contain a +different search query and the expected results, broken out by search tab. +These files are processed by a script in `src/tools/rustdoc-js` and the Node.js +runtime. These tests don't have as thorough of a writeup, but a broad example +that features results in all tabs can be found in `basic.js`. The basic idea is +that you match a given `QUERY` with a set of `EXPECTED` results, complete with +the full item path of each item. + +You can run tests using the name of the folder. For example, +`x.py test --stage 1 src/test/rustdoc` will run the output tests using a stage1 rustdoc. diff --git a/src/rustdoc.md b/src/rustdoc.md index 120ebe139..0e80c0699 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -56,195 +56,6 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) series of JavaScript files that encode queries on the standard library search index and expected results. -## From crate to clean +## See also -In `core.rs` are two central items: the `DocContext` struct, and the `run_core` -function. The latter is where rustdoc calls out to rustc to compile a crate to -the point where rustdoc can take over. The former is a state container used -when crawling through a crate to gather its documentation. - -The main process of crate crawling is done in `clean/mod.rs` through several -implementations of the `Clean` trait defined within. This is a conversion -trait, which defines one method: - -```rust,ignore -pub trait Clean { - fn clean(&self, cx: &DocContext) -> T; -} -``` - -`clean/mod.rs` also defines the types for the "cleaned" AST used later on to -render documentation pages. Each usually accompanies an implementation of -`Clean` that takes some AST or HIR type from rustc and converts it into the -appropriate "cleaned" type. "Big" items like modules or associated items may -have some extra processing in its `Clean` implementation, but for the most part -these impls are straightforward conversions. The "entry point" to this module -is the `impl Clean for visit_ast::RustdocVisitor`, which is called by -`run_core` above. - -You see, I actually lied a little earlier: There's another AST transformation -that happens before the events in `clean/mod.rs`. In `visit_ast.rs` is the -type `RustdocVisitor`, which *actually* crawls a `rustc_hir::Crate` to get the first -intermediate representation, defined in `doctree.rs`. This pass is mainly to -get a few intermediate wrappers around the HIR types and to process visibility -and inlining. This is where `#[doc(inline)]`, `#[doc(no_inline)]`, and -`#[doc(hidden)]` are processed, as well as the logic for whether a `pub use` -should get the full page or a "Reexport" line in the module page. - -The other major thing that happens in `clean/mod.rs` is the collection of doc -comments and `#[doc=""]` attributes into a separate field of the Attributes -struct, present on anything that gets hand-written documentation. This makes it -easier to collect this documentation later in the process. - -The primary output of this process is a `clean::Crate` with a tree of Items -which describe the publicly-documentable items in the target crate. - -### Hot potato - -Before moving on to the next major step, a few important "passes" occur over -the documentation. These do things like combine the separate "attributes" into -a single string and strip leading whitespace to make the document easier on the -markdown parser, or drop items that are not public or deliberately hidden with -`#[doc(hidden)]`. These are all implemented in the `passes/` directory, one -file per pass. By default, all of these passes are run on a crate, but the ones -regarding dropping private/hidden items can be bypassed by passing -`--document-private-items` to rustdoc. Note that unlike the previous set of AST -transformations, the passes happen on the _cleaned_ crate. - -(Strictly speaking, you can fine-tune the passes run and even add your own, but -[we're trying to deprecate that][44136]. If you need finer-grain control over -these passes, please let us know!) - -[44136]: https://github.com/rust-lang/rust/issues/44136 - -Here is current (as of this writing) list of passes: - -- `propagate-doc-cfg` - propagates `#[doc(cfg(...))]` to child items. -- `collapse-docs` concatenates all document attributes into one document - attribute. This is necessary because each line of a doc comment is given as a - separate doc attribute, and this will combine them into a single string with - line breaks between each attribute. -- `unindent-comments` removes excess indentation on comments in order for - markdown to like it. This is necessary because the convention for writing - documentation is to provide a space between the `///` or `//!` marker and the - text, and stripping that leading space will make the text easier to parse by - the Markdown parser. (In the past, the markdown parser used was not - Commonmark- compliant, which caused annoyances with extra whitespace but this - seems to be less of an issue today.) -- `strip-priv-imports` strips all private import statements (`use`, `extern - crate`) from a crate. This is necessary because rustdoc will handle *public* - imports by either inlining the item's documentation to the module or creating - a "Reexports" section with the import in it. The pass ensures that all of - these imports are actually relevant to documentation. -- `strip-hidden` and `strip-private` strip all `doc(hidden)` and private items - from the output. `strip-private` implies `strip-priv-imports`. Basically, the - goal is to remove items that are not relevant for public documentation. - -## From clean to crate - -This is where the "second phase" in rustdoc begins. This phase primarily lives -in the `html/` folder, and it all starts with `run()` in `html/render.rs`. This -code is responsible for setting up the `Context`, `SharedContext`, and `Cache` -which are used during rendering, copying out the static files which live in -every rendered set of documentation (things like the fonts, CSS, and JavaScript -that live in `html/static/`), creating the search index, and printing out the -source code rendering, before beginning the process of rendering all the -documentation for the crate. - -Several functions implemented directly on `Context` take the `clean::Crate` and -set up some state between rendering items or recursing on a module's child -items. From here the "page rendering" begins, via an enormous `write!()` call -in `html/layout.rs`. The parts that actually generate HTML from the items and -documentation occurs within a series of `std::fmt::Display` implementations and -functions that pass around a `&mut std::fmt::Formatter`. The top-level -implementation that writes out the page body is the `impl<'a> fmt::Display for -Item<'a>` in `html/render.rs`, which switches out to one of several `item_*` -functions based on the kind of `Item` being rendered. - -Depending on what kind of rendering code you're looking for, you'll probably -find it either in `html/render.rs` for major items like "what sections should I -print for a struct page" or `html/format.rs` for smaller component pieces like -"how should I print a where clause as part of some other item". - -Whenever rustdoc comes across an item that should print hand-written -documentation alongside, it calls out to `html/markdown.rs` which interfaces -with the Markdown parser. This is exposed as a series of types that wrap a -string of Markdown, and implement `fmt::Display` to emit HTML text. It takes -special care to enable certain features like footnotes and tables and add -syntax highlighting to Rust code blocks (via `html/highlight.rs`) before -running the Markdown parser. There's also a function in here -(`find_testable_code`) that specifically scans for Rust code blocks so the -test-runner code can find all the doctests in the crate. - -### From soup to nuts - -(alternate title: ["An unbroken thread that stretches from those first `Cell`s -to us"][video]) - -[video]: https://www.youtube.com/watch?v=hOLAGYmUQV0 - -It's important to note that the AST cleaning can ask the compiler for -information (crucially, `DocContext` contains a `TyCtxt`), but page rendering -cannot. The `clean::Crate` created within `run_core` is passed outside the -compiler context before being handed to `html::render::run`. This means that a -lot of the "supplementary data" that isn't immediately available inside an -item's definition, like which trait is the `Deref` trait used by the language, -needs to be collected during cleaning, stored in the `DocContext`, and passed -along to the `SharedContext` during HTML rendering. This manifests as a bunch -of shared state, context variables, and `RefCell`s. - -Also of note is that some items that come from "asking the compiler" don't go -directly into the `DocContext` - for example, when loading items from a foreign -crate, rustdoc will ask about trait implementations and generate new `Item`s -for the impls based on that information. This goes directly into the returned -`Crate` rather than roundabout through the `DocContext`. This way, these -implementations can be collected alongside the others, right before rendering -the HTML. - -## Other tricks up its sleeve - -All this describes the process for generating HTML documentation from a Rust -crate, but there are couple other major modes that rustdoc runs in. It can also -be run on a standalone Markdown file, or it can run doctests on Rust code or -standalone Markdown files. For the former, it shortcuts straight to -`html/markdown.rs`, optionally including a mode which inserts a Table of -Contents to the output HTML. - -For the latter, rustdoc runs a similar partial-compilation to get relevant -documentation in `test.rs`, but instead of going through the full clean and -render process, it runs a much simpler crate walk to grab *just* the -hand-written documentation. Combined with the aforementioned -"`find_testable_code`" in `html/markdown.rs`, it builds up a collection of -tests to run before handing them off to the libtest test runner. One notable -location in `test.rs` is the function `make_test`, which is where hand-written -doctests get transformed into something that can be executed. - -Some extra reading about `make_test` can be found -[here](https://quietmisdreavus.net/code/2018/02/23/how-the-doctests-get-made/). - -## Dotting i's and crossing t's - -So that's rustdoc's code in a nutshell, but there's more things in the repo -that deal with it. Since we have the full `compiletest` suite at hand, there's -a set of tests in `src/test/rustdoc` that make sure the final HTML is what we -expect in various situations. These tests also use a supplementary script, -`src/etc/htmldocck.py`, that allows it to look through the final HTML using -XPath notation to get a precise look at the output. The full description of all -the commands available to rustdoc tests is in `htmldocck.py`. - -To use multiple crates in a rustdoc test, add `// aux-build:filename.rs` -to the top of the test file. `filename.rs` should be placed in an `auxiliary` -directory relative to the test file with the comment. If you need to build -docs for the auxiliary file, use `// build-aux-docs`. - -In addition, there are separate tests for the search index and rustdoc's -ability to query it. The files in `src/test/rustdoc-js` each contain a -different search query and the expected results, broken out by search tab. -These files are processed by a script in `src/tools/rustdoc-js` and the Node.js -runtime. These tests don't have as thorough of a writeup, but a broad example -that features results in all tabs can be found in `basic.js`. The basic idea is -that you match a given `QUERY` with a set of `EXPECTED` results, complete with -the full item path of each item. - -You can run tests using the name of the folder. For example, -`x.py test --stage 1 src/test/rustdoc` will run the output tests using a stage1 rustdoc. +For more details about how rustdoc works, see the page on [rustdoc internals](./rustdoc-internals.md). From 2e104620d1c6b90d822c9b0d331e50969fe15f67 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 17:53:09 -0400 Subject: [PATCH 1088/1812] Move x.py commands to overview --- src/rustdoc-internals.md | 3 --- src/rustdoc.md | 6 +++++- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index 59cee9f1c..ab3bf1b30 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -192,6 +192,3 @@ runtime. These tests don't have as thorough of a writeup, but a broad example that features results in all tabs can be found in `basic.js`. The basic idea is that you match a given `QUERY` with a set of `EXPECTED` results, complete with the full item path of each item. - -You can run tests using the name of the folder. For example, -`x.py test --stage 1 src/test/rustdoc` will run the output tests using a stage1 rustdoc. diff --git a/src/rustdoc.md b/src/rustdoc.md index 0e80c0699..6ac944697 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -41,6 +41,8 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * The completed docs will be available in `build/$TARGET/doc/std`, though the bundle is meant to be used as though you would copy out the `doc` folder to a web server, since that's where the CSS/JS and landing page are. +* Use `x.py test --stage 1 src/test/rustdoc*` to run the tests using a stage1 rustdoc. + * See [rustdoc internals] for more information about tests. * Most of the HTML printing code is in `html/format.rs` and `html/render.rs`. It's in a bunch of `fmt::Display` implementations and supplementary functions. @@ -58,4 +60,6 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) ## See also -For more details about how rustdoc works, see the page on [rustdoc internals](./rustdoc-internals.md). +For more details about how rustdoc works, see the page on [rustdoc internals]. + +[rustdoc internals]: ./rustdoc-internals.md From 093b9032de1821f8a9f507f80f985aca1920858b Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 12:47:50 -0500 Subject: [PATCH 1089/1812] Upgrade to mdbook 0.4 and switch to book parts (#764) * upgrade to mdbook 0.4 and switch to book parts * update linkcheck * fix links, update about-this-guide --- .travis.yml | 4 +- src/SUMMARY.md | 255 +++++++++++++++++++++------------------- src/about-this-guide.md | 12 +- src/part-1-intro.md | 7 -- 4 files changed, 144 insertions(+), 134 deletions(-) delete mode 100644 src/part-1-intro.md diff --git a/.travis.yml b/.travis.yml index 634d73871..4a78953cb 100644 --- a/.travis.yml +++ b/.travis.yml @@ -11,8 +11,8 @@ before_install: - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true -- cargo install mdbook --version 0.3.7 -- cargo install mdbook-linkcheck --version 0.5.0 +- cargo install mdbook --version 0.4.0 +- cargo install mdbook-linkcheck --version 0.7.0 script: - git checkout -b ci - git rebase origin/master diff --git a/src/SUMMARY.md b/src/SUMMARY.md index d80919657..f57ba4f23 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -4,128 +4,141 @@ --- -- [Part 1: Building, debugging, and contributing to Rustc](./part-1-intro.md) +# Building and debugging `rustc` + +- [Getting Started](./getting-started.md) +- [How to Build and Run the Compiler](./building/how-to-build-and-run.md) - [Prerequisites](./building/prerequisites.md) - - [Getting Started](./getting-started.md) - - [About the compiler team](./compiler-team.md) - - [How to Build and Run the Compiler](./building/how-to-build-and-run.md) - - [Prerequisites](./building/prerequisites.md) - - [Suggested Workflows](./building/suggested.md) - - [Bootstrapping](./building/bootstrapping.md) - - [Distribution artifacts](./building/build-install-distribution-artifacts.md) - - [Documenting Compiler](./building/compiler-documenting.md) - - [Rustdoc](./rustdoc.md) - - [ctags](./building/ctags.md) - - [The compiler testing framework](./tests/intro.md) - - [Running tests](./tests/running.md) - - [Adding new tests](./tests/adding.md) - - [Using `compiletest` + commands to control test execution](./compiletest.md) - - [Walkthrough: a typical contribution](./walkthrough.md) - - [Bug Fix Procedure](./bug-fix-procedure.md) - - [Implementing new features](./implementing_new_features.md) - - [Stability attributes](./stability.md) - - [Stabilizing Features](./stabilization_guide.md) - - [Debugging the Compiler](./compiler-debugging.md) - - [Profiling the compiler](./profiling.md) - - [with the linux perf tool](./profiling/with_perf.md) - - [Coding conventions](./conventions.md) - - [crates.io Dependencies](./crates-io.md) - - [Errors and Lints](diagnostics.md) - - [`LintStore`](./diagnostics/lintstore.md) - - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) - - [Notification groups](notification-groups/about.md) - - ["Cleanup Crew"](notification-groups/cleanup-crew.md) - - [LLVM](notification-groups/llvm.md) - - [Windows](notification-groups/windows.md) - - [ARM](notification-groups/arm.md) - - [Licenses](./licenses.md) -- [Part 2: High-level Compiler Architecture](./part-2-intro.md) - - [Overview of the Compiler](./overview.md) - - [The compiler source code](./compiler-src.md) - - [Queries: demand-driven compilation](./query.md) - - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) - - [Incremental compilation](./queries/incremental-compilation.md) - - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) - - [Debugging and Testing](./incrcomp-debugging.md) - - [Profiling Queries](./queries/profiling.md) - - [Salsa](./salsa.md) - - [Memory Management in Rustc](./memory.md) - - [Parallel Compilation](./parallel-rustc.md) - - [Rustdoc](./rustdoc-internals.md) - -- [Part 3: Source Code Representations](./part-3-intro.md) - - [Command-line arguments](./cli.md) - - [The Rustc Driver and Interface](./rustc-driver.md) - - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) - - [Ex: Getting diagnostics through `rustc_interface`](./rustc-driver-getting-diagnostics.md) - - [Syntax and the AST](./syntax-intro.md) - - [Lexing and Parsing](./the-parser.md) - - [Macro expansion](./macro-expansion.md) - - [Name resolution](./name-resolution.md) - - [`#[test]` Implementation](./test-implementation.md) - - [Panic Implementation](./panic-implementation.md) - - [AST Validation](./ast-validation.md) - - [Feature Gate Checking](./feature-gate-ck.md) - - [The HIR (High-level IR)](./hir.md) - - [Lowering AST to HIR](./lowering.md) - - [Debugging](./hir-debugging.md) - - [The MIR (Mid-level IR)](./mir/index.md) - - [HAIR and MIR construction](./mir/construction.md) - - [MIR visitor and traversal](./mir/visitor.md) - - [MIR passes: getting the MIR for a function](./mir/passes.md) - - [Closure expansion](./closure.md) - -- [Part 4: Analysis](./part-4-intro.md) - - [The `ty` module: representing types](./ty.md) - - [Generics and substitutions](./generics.md) - - [`TypeFolder` and `TypeFoldable`](./ty-fold.md) - - [Generic arguments](./generic_arguments.md) - - [Type inference](./type-inference.md) - - [Trait solving](./traits/resolution.md) - - [Early and Late Bound Parameters](./early-late-bound.md) - - [Higher-ranked trait bounds](./traits/hrtb.md) - - [Caching subtleties](./traits/caching.md) - - [Specialization](./traits/specialization.md) - - [Chalk-based trait solving](./traits/chalk.md) - - [Lowering to logic](./traits/lowering-to-logic.md) - - [Goals and clauses](./traits/goals-and-clauses.md) - - [Canonical queries](./traits/canonical-queries.md) - - [Lowering module in rustc](./traits/lowering-module.md) - - [Type checking](./type-checking.md) - - [Method Lookup](./method-lookup.md) - - [Variance](./variance.md) - - [Opaque Types](./opaque-types-type-alias-impl-trait.md) - - [Pattern and Exhaustiveness Checking](./pat-exhaustive-checking.md) - - [The borrow checker](./borrow_check.md) - - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) - - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) - - [MIR type checker](./borrow_check/type_check.md) - - [Region inference](./borrow_check/region_inference.md) - - [Constraint propagation](./borrow_check/region_inference/constraint_propagation.md) - - [Lifetime parameters](./borrow_check/region_inference/lifetime_parameters.md) - - [Member constraints](./borrow_check/region_inference/member_constraints.md) - - [Placeholders and universes][pau] - - [Closure constraints](./borrow_check/region_inference/closure_constraints.md) - - [Error reporting](./borrow_check/region_inference/error_reporting.md) - - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) - - [Parameter Environments](./param_env.md) - -- [Part 5: From MIR to binaries](./part-5-intro.md) - - [The MIR (Mid-level IR)](./mir/index.md) - - [MIR optimizations](./mir/optimizations.md) - - [Debugging](./mir/debugging.md) - - [Constant evaluation](./const-eval.md) - - [miri const evaluator](./miri.md) - - [Monomorphization](./backend/monomorph.md) - - [Lowering MIR](./backend/lowering-mir.md) - - [Code Generation](./backend/codegen.md) - - [Updating LLVM](./backend/updating-llvm.md) - - [Debugging LLVM](./backend/debugging.md) - - [Backend Agnostic Codegen](./backend/backend-agnostic.md) - - [Implicit Caller Location](./codegen/implicit-caller-location.md) - - [Profile-guided Optimization](./profile-guided-optimization.md) - - [Sanitizers Support](./sanitizers.md) - - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) + - [Suggested Workflows](./building/suggested.md) + - [Bootstrapping](./building/bootstrapping.md) + - [Distribution artifacts](./building/build-install-distribution-artifacts.md) + - [Documenting Compiler](./building/compiler-documenting.md) + - [Rustdoc](./rustdoc.md) + - [ctags](./building/ctags.md) +- [The compiler testing framework](./tests/intro.md) + - [Running tests](./tests/running.md) + - [Adding new tests](./tests/adding.md) + - [Using `compiletest` + commands to control test execution](./compiletest.md) +- [Debugging the Compiler](./compiler-debugging.md) +- [Profiling the compiler](./profiling.md) + - [with the linux perf tool](./profiling/with_perf.md) +- [crates.io Dependencies](./crates-io.md) +- [Errors and Lints](diagnostics.md) + - [`LintStore`](./diagnostics/lintstore.md) + - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) + +# Contributing to Rust + +- [About the compiler team](./compiler-team.md) +- [Walkthrough: a typical contribution](./walkthrough.md) +- [Bug Fix Procedure](./bug-fix-procedure.md) +- [Implementing new features](./implementing_new_features.md) +- [Stability attributes](./stability.md) +- [Stabilizing Features](./stabilization_guide.md) +- [Coding conventions](./conventions.md) +- [Notification groups](notification-groups/about.md) + - ["Cleanup Crew"](notification-groups/cleanup-crew.md) + - [LLVM](notification-groups/llvm.md) + - [Windows](notification-groups/windows.md) + - [ARM](notification-groups/arm.md) +- [Licenses](./licenses.md) + +# High-level Compiler Architecture + +- [Prologue](./part-2-intro.md) +- [Overview of the Compiler](./overview.md) +- [The compiler source code](./compiler-src.md) +- [Queries: demand-driven compilation](./query.md) + - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) + - [Incremental compilation](./queries/incremental-compilation.md) + - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) + - [Debugging and Testing](./incrcomp-debugging.md) + - [Profiling Queries](./queries/profiling.md) + - [Salsa](./salsa.md) +- [Memory Management in Rustc](./memory.md) +- [Parallel Compilation](./parallel-rustc.md) +- [Rustdoc](./rustdoc-internals.md) + +# Source Code Representations + +- [Prologue](./part-3-intro.md) +- [Command-line arguments](./cli.md) +- [The Rustc Driver and Interface](./rustc-driver.md) + - [Rustdoc](./rustdoc.md) + - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) + - [Ex: Getting diagnostics through `rustc_interface`](./rustc-driver-getting-diagnostics.md) +- [Syntax and the AST](./syntax-intro.md) + - [Lexing and Parsing](./the-parser.md) + - [Macro expansion](./macro-expansion.md) + - [Name resolution](./name-resolution.md) + - [`#[test]` Implementation](./test-implementation.md) + - [Panic Implementation](./panic-implementation.md) + - [AST Validation](./ast-validation.md) + - [Feature Gate Checking](./feature-gate-ck.md) +- [The HIR (High-level IR)](./hir.md) + - [Lowering AST to HIR](./lowering.md) + - [Debugging](./hir-debugging.md) +- [The MIR (Mid-level IR)](./mir/index.md) + - [HAIR and MIR construction](./mir/construction.md) + - [MIR visitor and traversal](./mir/visitor.md) + - [MIR passes: getting the MIR for a function](./mir/passes.md) +- [Closure expansion](./closure.md) + +# Analysis + +- [Prologue](./part-4-intro.md) +- [The `ty` module: representing types](./ty.md) + - [Generics and substitutions](./generics.md) + - [`TypeFolder` and `TypeFoldable`](./ty-fold.md) + - [Generic arguments](./generic_arguments.md) +- [Type inference](./type-inference.md) +- [Trait solving](./traits/resolution.md) + - [Early and Late Bound Parameters](./early-late-bound.md) + - [Higher-ranked trait bounds](./traits/hrtb.md) + - [Caching subtleties](./traits/caching.md) + - [Specialization](./traits/specialization.md) + - [Chalk-based trait solving](./traits/chalk.md) + - [Lowering to logic](./traits/lowering-to-logic.md) + - [Goals and clauses](./traits/goals-and-clauses.md) + - [Canonical queries](./traits/canonical-queries.md) + - [Lowering module in rustc](./traits/lowering-module.md) +- [Type checking](./type-checking.md) + - [Method Lookup](./method-lookup.md) + - [Variance](./variance.md) + - [Opaque Types](./opaque-types-type-alias-impl-trait.md) +- [Pattern and Exhaustiveness Checking](./pat-exhaustive-checking.md) +- [The borrow checker](./borrow_check.md) + - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) + - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) + - [MIR type checker](./borrow_check/type_check.md) + - [Region inference](./borrow_check/region_inference.md) + - [Constraint propagation](./borrow_check/region_inference/constraint_propagation.md) + - [Lifetime parameters](./borrow_check/region_inference/lifetime_parameters.md) + - [Member constraints](./borrow_check/region_inference/member_constraints.md) + - [Placeholders and universes][pau] + - [Closure constraints](./borrow_check/region_inference/closure_constraints.md) + - [Error reporting](./borrow_check/region_inference/error_reporting.md) + - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) +- [Parameter Environments](./param_env.md) + +# MIR to Binaries + +- [Prologue](./part-5-intro.md) +- [The MIR (Mid-level IR)](./mir/index.md) + - [MIR optimizations](./mir/optimizations.md) + - [Debugging](./mir/debugging.md) +- [Constant evaluation](./const-eval.md) + - [miri const evaluator](./miri.md) +- [Monomorphization](./backend/monomorph.md) +- [Lowering MIR](./backend/lowering-mir.md) +- [Code Generation](./backend/codegen.md) + - [Updating LLVM](./backend/updating-llvm.md) + - [Debugging LLVM](./backend/debugging.md) + - [Backend Agnostic Codegen](./backend/backend-agnostic.md) + - [Implicit Caller Location](./codegen/implicit-caller-location.md) +- [Profile-guided Optimization](./profile-guided-optimization.md) +- [Sanitizers Support](./sanitizers.md) +- [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) --- diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 58b0cb9f0..dfe14d224 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -6,9 +6,12 @@ development. There are six parts to this guide: -1. [Building, Debugging, and Contributing to `rustc`][p1]: Contains information that should be useful no matter how - you are contributing, such as procedures for contribution, building the - compiler, etc. +1. [Building and Debugging to `rustc`][p1]: Contains information that should be + useful no matter how you are contributing, about building, debugging, + profiling, etc. +2. [Contributing to `rustc`][p1-5]: Contains information that should be useful + no matter how you are contributing, about procedures for contribution, + stabilizing features, etc. 2. [High-Level Compiler Architecture][p2]: Discusses the high-level architecture of the compiler and stages of the compile process. 3. [Source Code Representation][p3]: Describes the process of taking raw source code from the user and @@ -19,7 +22,8 @@ There are six parts to this guide: 6. [Appendices][app] at the end with useful reference information. There are a few of these with different information, inluding a glossary. -[p1]: ./part-1-intro.md +[p1]: ./getting-started.md +[p1-5]: ./compiler-team.md [p2]: ./part-2-intro.md [p3]: ./part-3-intro.md [p4]: ./part-4-intro.md diff --git a/src/part-1-intro.md b/src/part-1-intro.md deleted file mode 100644 index 95d2f8fcc..000000000 --- a/src/part-1-intro.md +++ /dev/null @@ -1,7 +0,0 @@ -# Part 1: Building, Debugging, and Contributing to `rustc` - -This section of the rustc-dev-guide contains knowledge that should be useful to you -regardless of what part of the compiler you are working on. This includes both -technical info and tips (e.g. how to compile and debug the compiler) and info -about processes in the Rust project (e.g. stabilization and info about the -compiler team). From e7db51facac88729e5dc9ec63ea233c1bc6a9be0 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 13:22:30 -0500 Subject: [PATCH 1090/1812] Fix formatting --- src/building/prerequisites.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index 3224c6dab..f4b0a92a4 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -23,8 +23,8 @@ need `llvm-config`. See [this section for more info][sysllvm]. These are not so much requirements as _recommendations_: * ~15GB of free disk space (~25GB or more if doing incremental builds). -* >= 8GB RAM -* >= 4 cores +* \>= 8GB RAM +* \>= 4 cores * Internet access Beefier machines will lead to much faster builds. If your machine is not very From b183202f37201529fb8da326b541eabc6e4acbd1 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 13:11:27 -0500 Subject: [PATCH 1091/1812] Fold chapters by default to make ToC shorter --- book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book.toml b/book.toml index 4b029127e..1e1c54cc9 100644 --- a/book.toml +++ b/book.toml @@ -11,7 +11,7 @@ git-repository-url = "https://github.com/rust-lang/rustc-dev-guide" [output.html.fold] enable = true -level = 1 +level = 0 [output.linkcheck] follow-web-links = true From b7095995aa2b55b23922d412ac40a784b640a8a4 Mon Sep 17 00:00:00 2001 From: Aaron Hill Date: Sat, 27 Jun 2020 11:47:47 -0400 Subject: [PATCH 1092/1812] Add 'recovery' to the gloassary --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 0a7568992..f428c8f0b 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -61,6 +61,7 @@ promoted constants
| Constants extracted from a function provider
| The function that executes a query. ([see more](../query.html)) quantified
| In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified). query
| Perhaps some sub-computation during compilation. ([see more](../query.html)) +recovery
| Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors). region
| Another term for "lifetime" often used in the literature and in the borrow checker. rib
| A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) sess
| The compiler session, which stores global data used throughout compilation From c1c66a82f2e6d177c2d47ea69315d22b929a6b62 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 15:54:01 -0400 Subject: [PATCH 1093/1812] Revamp bootstrapping section - Move most of the overview to building/bootstrapping.md - Add things besides stages to bootstrapping.md --- src/building/bootstrapping.md | 78 ++++++++++++++++++++++++++++++++++- src/overview.md | 30 +++++--------- 2 files changed, 88 insertions(+), 20 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 5ba8ef88d..536a4118f 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -2,7 +2,83 @@ This subchapter is about the bootstrapping process. -When running `x.py` you will see output such as: +## What is bootstrapping? How does it work? + +[Bootstrapping] is the process of using a compiler to compile itself. +More accurately, it means using an older compiler to compile a newer version +of the same compiler. + +This raises a chicken-and-egg paradox: where did the first compiler come from? +It must have been written in a different language. In Rust's case it was +[written in OCaml][ocaml-compiler]. However it was abandoned long ago and the +only way to build a modern version of rustc is a slightly less modern +version. + +This is exactly how `x.py` works: it downloads the current `beta` release of +rustc, then uses it to compile the nightly compiler. The beta release is +called `stage0` and the newly built compiler is `stage1` (or `stage0 +artifacts`). To get the full benefits of the new compiler (e.g. optimizations +and new features), the `stage1` compiler then compiles _itself_ again. This +last compiler is called `stage2` (or `stage1 artifacts`). + +The `stage2` compiler is the one distributed with `rustup` and all other +install methods. However, it takes a very long time to build because one must +first build the new compiler with an older compiler and then use that to +build the new compiler with itself. For development, you usually only want +the `stage1` compiler: `x.py build --stage 1 src/libstd`. + +## Complications of bootstrapping + +Since the build system uses the current beta compiler to build the stage-1 +bootstrapping compiler, the compiler source code can't use some features +until they reach beta (because otherwise the beta compiler doesn't support +them). On the other hand, for [compiler intrinsics][intrinsics] and internal +features, the features _have_ to be used. Additionally, the compiler makes +heavy use of nightly features (`#![feature(...)]`). How can we resolve this +problem? + +There are two methods used: +1. The build system sets `--cfg bootstrap` when building with `stage0`, so we +can use `cfg(not(bootstrap))` to only use features when built with `stage1`. +This is useful for e.g. features that were just stabilized, which require +`#![feature(...)]` when built with `stage0`, but not for `stage1`. +2. The build system sets `RUSTC_BOOTSTRAP=1`. This special variable means to +_break the stability guarantees_ of rust: Allow using `#![feature(...)]` with +a compiler that's not nightly. This should never be used except when +bootstrapping the compiler. + +[Bootstrapping]: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) +[intrinsics]: ../appendix/glossary.md#intrinsic +[ocaml-compiler]: https://github.com/rust-lang/rust/tree/ef75860a0a72f79f97216f8aaa5b388d98da6480/src/boot + +## Contributing to bootstrap + +When you use the bootstrap system, you'll call it through `x.py`. +However, most of the code lives in `src/bootstrap`. +`bootstrap` has a difficult problem: it is written in Rust, but yet it is run +before the rust compiler is built! To work around this, there are two +components of bootstrap: the main one written in rust, and `bootstrap.py`. +`bootstrap.py` is what gets run by x.py. It takes care of downloading the +`stage0` compiler, which will then build the bootstrap binary written in +Rust. + +Because there are two separate codebases being from from `x.py`, they need to +be kept in sync. In particular, both `bootstrap.py` and the bootstrap binary +parse `config.toml` and read the same command line arguments. `bootstrap.py` +keeps these in sync by setting various environment variables, and the +programs sometimes to have add arguments that are explicitly ignored, to be +read by the other. + +### Adding a setting to config.toml + +This section is a work in progress. In the meantime, you can see an example contribution [here][bootstrap-build]. + +[bootstrap-build]: https://github.com/rust-lang/rust/pull/71994 + +## Stages of bootstrap + +This is a detailed look into the separate bootstrap stages. When running +`x.py` you will see output such as: ```txt Building stage0 std artifacts diff --git a/src/overview.md b/src/overview.md index 37e82822d..9594bab53 100644 --- a/src/overview.md +++ b/src/overview.md @@ -309,25 +309,17 @@ but there are already some promising performance improvements. ### Bootstrapping `rustc` itself is written in Rust. So how do we compile the compiler? We use an -older compiler to compile the newer compiler. This is called _bootstrapping_. - -Bootstrapping has a lot of interesting implications. For example, it means that -one of the major users of Rust is Rust, so we are constantly testing our own -software ("eating our own dogfood"). Also, it means building the compiler can -take a long time because one must first build the new compiler with an older -compiler and then use that to build the new compiler with itself (sometimes you -can get away without the full 2-stage build, but for release artifacts you need -the 2-stage build). - -Bootstrapping also has implications for when features are usable in the -compiler itself. The build system uses the current beta compiler to build the -stage-1 bootstrapping compiler. This means that the compiler source code can't -use some features until they reach beta (because otherwise the beta compiler -doesn't support them). On the other hand, for [compiler intrinsics][intrinsics] -and internal features, we may be able to use them immediately because the -stage-1 bootstrapping compiler will support them. - -[intrinsics]: ./appendix/glossary.md#intrinsic +older compiler to compile the newer compiler. This is called [_bootstrapping_]. + +Bootstrapping has a lot of interesting implications. For example, it means +that one of the major users of Rust is the Rust compiler, so we are +constantly testing our own software ("eating our own dogfood"). + +For more details on bootstrapping, see +[the bootstrapping section of the guide][rustc-bootstrap]. + +[_bootstrapping_]: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) +[rustc-bootstrap]: building/bootstrapping.md # Unresolved Questions From 1c68f636cf2d80ec7a64f6ffeb205ebca3764285 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 19:20:42 -0400 Subject: [PATCH 1094/1812] Improve wording and fix typos Co-authored-by: Who? Me?! --- src/building/bootstrapping.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 536a4118f..843cc2641 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -15,7 +15,7 @@ only way to build a modern version of rustc is a slightly less modern version. This is exactly how `x.py` works: it downloads the current `beta` release of -rustc, then uses it to compile the nightly compiler. The beta release is +rustc, then uses it to compile the new compiler. The beta release is called `stage0` and the newly built compiler is `stage1` (or `stage0 artifacts`). To get the full benefits of the new compiler (e.g. optimizations and new features), the `stage1` compiler then compiles _itself_ again. This @@ -62,7 +62,7 @@ components of bootstrap: the main one written in rust, and `bootstrap.py`. `stage0` compiler, which will then build the bootstrap binary written in Rust. -Because there are two separate codebases being from from `x.py`, they need to +Because there are two separate codebases behind `x.py`, they need to be kept in sync. In particular, both `bootstrap.py` and the bootstrap binary parse `config.toml` and read the same command line arguments. `bootstrap.py` keeps these in sync by setting various environment variables, and the From be8c8bb7bc52f1b1b231a91da350770235ee0d48 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 23 Jun 2020 20:46:31 -0400 Subject: [PATCH 1095/1812] Fix line lengths --- src/building/bootstrapping.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 843cc2641..e7a031522 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -71,7 +71,8 @@ read by the other. ### Adding a setting to config.toml -This section is a work in progress. In the meantime, you can see an example contribution [here][bootstrap-build]. +This section is a work in progress. In the meantime, you can see an example +contribution [here][bootstrap-build]. [bootstrap-build]: https://github.com/rust-lang/rust/pull/71994 From 2c6f17671f727b30cd274832b550f2e0428784d2 Mon Sep 17 00:00:00 2001 From: pierwill Date: Sat, 27 Jun 2020 16:08:48 -0700 Subject: [PATCH 1096/1812] Edit ty.md Makes various edits throughout for formatting, punctuation, and typo fixes. Also makes some edits and re-wording for clarity. --- src/ty.md | 85 ++++++++++++++++++++++++++----------------------------- 1 file changed, 40 insertions(+), 45 deletions(-) diff --git a/src/ty.md b/src/ty.md index c6affe75a..2587f61ba 100644 --- a/src/ty.md +++ b/src/ty.md @@ -63,10 +63,10 @@ Here is a summary: HIR is built, some basic type inference and type checking is done. During the type inference, we figure out what the `ty::Ty` of everything is and we also check if the type of something is ambiguous. The `ty::Ty` then, is used for type checking while making sure everything has the -expected type. The [`astconv` module][astconv], is where the code responsible for converting a +expected type. The [`astconv` module][astconv] is where the code responsible for converting a `rustc_hir::Ty` into a `ty::Ty` is located. This occurs during the type-checking phase, but also in other parts of the compiler that want to ask questions like "what argument types does -this function expect"?. +this function expect?" [astconv]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/astconv/index.html @@ -79,13 +79,13 @@ They are syntactically two strings: `"u32"` at line N column 20 and `"u32"` at l don’t know that they are the same yet. So, in the HIR we treat them as if they are different. Later, we determine that they semantically are the same type and that’s the `ty::Ty` we use. -Consider another example: `fn foo(x: T) -> u32` and suppose that someone invokes `foo::(0)`. +Consider another example: `fn foo(x: T) -> u32`. Suppose that someone invokes `foo::(0)`. This means that `T` and `u32` (in this invocation) actually turns out to be the same type, so we would eventually end up with the same `ty::Ty` in the end, but we have distinct `rustc_hir::Ty`. (This is a bit over-simplified, though, since during type checking, we would check the function generically and would still have a `T` distinct from `u32`. Later, when doing code generation, we would always be handling "monomorphized" (fully substituted) versions of each function, -and hence we would know what `T` represents (and specifically that it is `u32`). +and hence we would know what `T` represents (and specifically that it is `u32`).) Here is one more example: @@ -107,13 +107,15 @@ or `fn(i32) -> i32` (with type aliases fully expanded). ## `ty::Ty` implementation -[`rustc::ty::Ty`][ty_ty] is actually a type alias to [`&TyS`][tys] (more about that later). `TyS` -(Type Structure) is where the main functionality is located. You can ignore `TyS` struct in general; -you will basically never access it explicitly. We always pass it by reference using the `Ty` alias. +[`rustc::ty::Ty`][ty_ty] is actually a type alias to [`&TyS`][tys]. +This type, which is short for "Type Structure", is where the main functionality is located. +You can ignore `TyS` struct in general; you will basically never access it explicitly. +We always pass it by reference using the `Ty` alias. The only exception is to define inherent methods on types. In particular, `TyS` has a [`kind`][kind] field of type [`TyKind`][tykind], which represents the key type information. `TyKind` is a big enum -which represents different kinds of types (e.g. primitives, references, abstract data types, -generics, lifetimes, etc). `TyS` also has 2 more fields, `flags` and `outer_exclusive_binder`. They +with variants to represent many different Rust types +(e.g. primitives, references, abstract data types, generics, lifetimes, etc). +`TyS` also has 2 more fields, `flags` and `outer_exclusive_binder`. They are convenient hacks for efficiency and summarize information about the type that we may want to know, but they don’t come into the picture as much here. Finally, `ty::TyS`s are [interned](./memory.md), so that the `ty::Ty` can be a thin pointer-like @@ -137,14 +139,15 @@ These methods all return a `Ty<'tcx>` – note that the lifetime you get back is arena that this `tcx` has access to. Types are always canonicalized and interned (so we never allocate exactly the same type twice). -> NB. Because types are interned, it is possible to compare them for equality efficiently using `==` +> N.B. +> Because types are interned, it is possible to compare them for equality efficiently using `==` > – however, this is almost never what you want to do unless you happen to be hashing and looking > for duplicates. This is because often in Rust there are multiple ways to represent the same type, > particularly once inference is involved. If you are going to be testing for type equality, you > probably need to start looking into the inference code to do it right. -You can also find various common types in the `tcx` itself by accessing `tcx.types.bool`, -`tcx.types.char`, etc (see [`CommonTypes`] for more). +You can also find various common types in the `tcx` itself by accessing its fields: +`tcx.types.bool`, `tcx.types.char`, etc. (See [`CommonTypes`] for more.) [`CommonTypes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.CommonTypes.html @@ -172,35 +175,27 @@ types in the compiler. There are a lot of related types, and we’ll cover them in time (e.g regions/lifetimes, “substitutions”, etc). -There are a bunch of variants on the `TyKind` enum, which you can see by looking at the rustdocs. -Here is a sampling: - -[**Algebraic Data Types (ADTs)**][kindadt] An [*algebraic Data Type*][wikiadt] is a `struct`, -`enum` or `union`. Under the hood, `struct`, `enum` and `union` are actually implemented -the same way: they are all [`ty::TyKind::Adt`][kindadt]. It’s basically a user defined type. -We will talk more about these later. - -[**Foreign**][kindforeign] Corresponds to `extern type T`. - -[**Str**][kindstr] Is the type str. When the user writes `&str`, `Str` is the how we represent the -`str` part of that type. - -[**Slice**][kindslice] Corresponds to `[T]`. - -[**Array**][kindarray] Corresponds to `[T; n]`. - -[**RawPtr**][kindrawptr] Corresponds to `*mut T` or `*const T` - -[**Ref**][kindref] `Ref` stands for safe references, `&'a mut T` or `&'a T`. `Ref` has some -associated parts, like `Ty<'tcx>` which is the type that the reference references, `Region<'tcx>` is -the lifetime or region of the reference and `Mutability` if the reference is mutable or not. - -[**Param**][kindparam] Represents a type parameter (e.g. the `T` in `Vec`). - -[**Error**][kinderr] Represents a type error somewhere so that we can print better diagnostics. We -will discuss this more later. - -[**And Many More**...][kindvars] +There are many variants on the `TyKind` enum, which you can see by looking at its +[documentation][tykind]. Here is a sampling: + +- [**Algebraic Data Types (ADTs)**][kindadt] An [*algebraic data type*][wikiadt] is a `struct`, + `enum` or `union`. Under the hood, `struct`, `enum` and `union` are actually implemented + the same way: they are all [`ty::TyKind::Adt`][kindadt]. It’s basically a user defined type. + We will talk more about these later. +- [**Foreign**][kindforeign] Corresponds to `extern type T`. +- [**Str**][kindstr] Is the type str. When the user writes `&str`, `Str` is the how we represent the + `str` part of that type. +- [**Slice**][kindslice] Corresponds to `[T]`. +- [**Array**][kindarray] Corresponds to `[T; n]`. +- [**RawPtr**][kindrawptr] Corresponds to `*mut T` or `*const T`. +- [**Ref**][kindref] `Ref` stands for safe references, `&'a mut T` or `&'a T`. `Ref` has some + associated parts, like `Ty<'tcx>` which is the type that the reference references. + `Region<'tcx>` is the lifetime or region of the reference and `Mutability` if the reference + is mutable or not. +- [**Param**][kindparam] Represents a type parameter (e.g. the `T` in `Vec`). +- [**Error**][kinderr] Represents a type error somewhere so that we can print better diagnostics. We + will discuss this more later. +- [**And many more**...][kindvars] [wikiadt]: https://en.wikipedia.org/wiki/Algebraic_data_type [kindadt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Adt @@ -249,8 +244,8 @@ There are two parts: - The [`AdtDef`][adtdef] references the struct/enum/union but without the values for its type parameters. In our example, this is the `MyStruct` part *without* the argument `u32`. - - Note that in the HIR, structs, enums and unions are represented differently, but in `ty::Ty`, - they are all represented using `TyKind::Adt`. + (Note that in the HIR, structs, enums and unions are represented differently, but in `ty::Ty`, + they are all represented using `TyKind::Adt`.) - The [`SubstsRef`][substsref] is an interned list of values that are to be substituted for the generic parameters. In our example of `MyStruct`, we would end up with a list like `[u32]`. We’ll dig more into generics and substitutions in a little bit. @@ -268,8 +263,8 @@ is only referenced). `AdtDef` is more or less a wrapper around `DefId` with lots of useful helper methods. There is essentially a one-to-one relationship between `AdtDef` and `DefId`. You can get the `AdtDef` for a -`DefId` with the [`tcx.adt_def(def_id)` query][adtdefq]. The `AdtDef`s are all interned (as you can -see `'tcx` lifetime on it). +`DefId` with the [`tcx.adt_def(def_id)` query][adtdefq]. `AdtDef`s are all interned, as shown +by the `'tcx` lifetime. [adtdefq]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.adt_def From 19f7d2e77d16de9a31b1be2bfe6ef7b910b75739 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 30 Jun 2020 23:22:38 +0900 Subject: [PATCH 1097/1812] Rename resolvers following the latest rustc change (#776) --- src/macro-expansion.md | 4 ++-- src/name-resolution.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 7961d0cf1..1b06cab41 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -154,7 +154,7 @@ whole crate, like we normally do). ### Other Data Structures Here are some other notable data structures involved in expansion and integration: -- [`Resolver`] - a trait used to break crate dependencies. This allows the +- [`ResolverExpand`] - a trait used to break crate dependencies. This allows the resolver services to be used in [`rustc_ast`], despite [`rustc_resolve`] and pretty much everything else depending on [`rustc_ast`]. - [`ExtCtxt`]/[`ExpansionData`] - various intermediate data kept and used by expansion @@ -168,7 +168,7 @@ Here are some other notable data structures involved in expansion and integratio [`rustc_ast`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html [`rustc_resolve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/index.html -[`Resolver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.Resolver.html +[`ResolverExpand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/trait.ResolverExpand.html [`ExtCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExtCtxt.html [`ExpansionData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html [`Annotatable`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/enum.Annotatable.html diff --git a/src/name-resolution.md b/src/name-resolution.md index 917f792a4..dfea5f22c 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -43,7 +43,7 @@ namespaces and therefore can co-exist. The name resolution in Rust is a two-phase process. In the first phase, which runs during macro expansion, we build a tree of modules and resolve imports. Macro expansion and name resolution communicate with each other via the -[`Resolver`] trait. +[`ResolverAstLowering`] trait. The input to the second phase is the syntax tree, produced by parsing input files and expanding macros. This phase produces links from all the names in the @@ -59,7 +59,7 @@ The name resolution lives in the `librustc_resolve` crate, with the meat in `lib.rs` and some helpers or symbol-type specific logic in the other modules. [`Resolver::resolve_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Resolver.html#method.resolve_crate -[`Resolver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_lowering/trait.Resolver.html +[`ResolverAstLowering`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_lowering/trait.ResolverAstLowering.html ## Namespaces From fd4c83f4ab5d1432646e09a75c6e5d11f117d87d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 13:15:29 -0500 Subject: [PATCH 1098/1812] Move Errors and Lints to Analysis --- src/SUMMARY.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f57ba4f23..21f642a08 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -23,9 +23,7 @@ - [Profiling the compiler](./profiling.md) - [with the linux perf tool](./profiling/with_perf.md) - [crates.io Dependencies](./crates-io.md) -- [Errors and Lints](diagnostics.md) - - [`LintStore`](./diagnostics/lintstore.md) - - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) + # Contributing to Rust @@ -120,6 +118,9 @@ - [Error reporting](./borrow_check/region_inference/error_reporting.md) - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) - [Parameter Environments](./param_env.md) +- [Errors and Lints](diagnostics.md) + - [`LintStore`](./diagnostics/lintstore.md) + - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) # MIR to Binaries From 99745b99312c04fc1e64520048f8dc3f54d1b451 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 24 Jun 2020 13:20:12 -0500 Subject: [PATCH 1099/1812] Move Getting Started to a "prefix chapter" --- src/SUMMARY.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 21f642a08..31a2259f9 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -2,11 +2,12 @@ [About this guide](./about-this-guide.md) +[Getting Started](./getting-started.md) + --- # Building and debugging `rustc` -- [Getting Started](./getting-started.md) - [How to Build and Run the Compiler](./building/how-to-build-and-run.md) - [Prerequisites](./building/prerequisites.md) - [Suggested Workflows](./building/suggested.md) From fe7856889a138eced7caa9b0faf43860fdebdc87 Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 27 Jun 2020 12:42:26 -0500 Subject: [PATCH 1100/1812] fix file name --- src/SUMMARY.md | 2 +- src/{codegen => backend}/implicit-caller-location.md | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename src/{codegen => backend}/implicit-caller-location.md (100%) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 31a2259f9..4edb25d42 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -137,7 +137,7 @@ - [Updating LLVM](./backend/updating-llvm.md) - [Debugging LLVM](./backend/debugging.md) - [Backend Agnostic Codegen](./backend/backend-agnostic.md) - - [Implicit Caller Location](./codegen/implicit-caller-location.md) + - [Implicit Caller Location](./backend/implicit-caller-location.md) - [Profile-guided Optimization](./profile-guided-optimization.md) - [Sanitizers Support](./sanitizers.md) - [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) diff --git a/src/codegen/implicit-caller-location.md b/src/backend/implicit-caller-location.md similarity index 100% rename from src/codegen/implicit-caller-location.md rename to src/backend/implicit-caller-location.md From 0006f199151dbda14c936ab078f971bdd8754983 Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Wed, 1 Jul 2020 04:26:25 -0700 Subject: [PATCH 1101/1812] Edit Part 2 introduction (#777) * Edit Part 2 introduction * needs a pause Co-authored-by: Tshepang Lekhonkhobe --- src/part-2-intro.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/part-2-intro.md b/src/part-2-intro.md index 04ae3f955..5ea4d7b6b 100644 --- a/src/part-2-intro.md +++ b/src/part-2-intro.md @@ -9,7 +9,6 @@ to file an issue on the [rustc-dev-guide repo](https://github.com/rust-lang/rustc-dev-guide/issues) or contact the compiler team, as detailed in [this chapter from Part 1](./compiler-team.md). -In this part, we will specifically look at the high-level architecture of the -compiler. Specifically, will look at the query system, incremental compilation, -and interning. These are three overarching design choices that impact the whole -compiler. +In this part, we will look at the high-level architecture of the compiler. In +particular, we will look at three overarching design choices that impact the +whole compiler: the query system, incremental compilation, and interning. From b1198eff6ba9b6cb29f53c37ceccccd742084ab5 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 17 Jun 2020 14:38:39 -0500 Subject: [PATCH 1102/1812] move CONTRIBUTING.md to rustc-dev-guide --- src/SUMMARY.md | 1 + src/contributing.md | 499 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 500 insertions(+) create mode 100644 src/contributing.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4edb25d42..5a1dcc68e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -28,6 +28,7 @@ # Contributing to Rust +- [Introduction](./contributing.md) - [About the compiler team](./compiler-team.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [Bug Fix Procedure](./bug-fix-procedure.md) diff --git a/src/contributing.md b/src/contributing.md new file mode 100644 index 000000000..e2bce693a --- /dev/null +++ b/src/contributing.md @@ -0,0 +1,499 @@ +# Contributing to Rust + +Thank you for your interest in contributing to Rust! There are many ways to +contribute, and we appreciate all of them. + +* [Feature Requests](#feature-requests) +* [Bug Reports](#bug-reports) +* [The Build System](#the-build-system) +* [Pull Requests](#pull-requests) +* [Writing Documentation](#writing-documentation) +* [Issue Triage](#issue-triage) +* [Out-of-tree Contributions](#out-of-tree-contributions) +* [Helpful Links and Information](#helpful-links-and-information) + +If you have questions, please make a post on [internals.rust-lang.org][internals] or +hop on the [Rust Discord server][rust-discord] or [Rust Zulip server][rust-zulip]. + +As a reminder, all contributors are expected to follow our [Code of Conduct][coc]. + +If this is your first time contributing, the [Getting Started] and +[walkthrough] chapters can give you a good example of how a typical +contribution would go. + +[internals]: https://internals.rust-lang.org +[rust-discord]: http://discord.gg/rust-lang +[rust-zulip]: https://rust-lang.zulipchat.com +[coc]: https://www.rust-lang.org/conduct.html +[walkthrough]: ./walkthrough.md +[Getting Started]: ./getting-started.md + +## Feature Requests + +Feature requests need to go through a process to be approved by the relevant +teams. Usually this requires a Final Comment Period (FCP) or even a Request for +Comments (RFC). See [Getting Started] for more information about these processes. + +## Bug Reports + +While bugs are unfortunate, they're a reality in software. We can't fix what we +don't know about, so please report liberally. If you're not sure if something +is a bug or not, feel free to file a bug anyway. + +**If you believe reporting your bug publicly represents a security risk to Rust users, +please follow our [instructions for reporting security vulnerabilities][vuln]**. + +[vuln]: https://www.rust-lang.org/policies/security + +If you're using the nightly channel, please check if the bug exists in the +latest toolchain before filing your bug. It might be fixed already. + +If you have the chance, before reporting a bug, please [search existing +issues](https://github.com/rust-lang/rust/search?q=&type=Issues&utf8=%E2%9C%93), +as it's possible that someone else has already reported your error. This doesn't +always work, and sometimes it's hard to know what to search for, so consider this +extra credit. We won't mind if you accidentally file a duplicate report. + +Similarly, to help others who encountered the bug find your issue, consider +filing an issue with a descriptive title, which contains information that might +be unique to it. This can be the language or compiler feature used, the +conditions that trigger the bug, or part of the error message if there is any. +An example could be: **"impossible case reached" on lifetime inference for impl +Trait in return position**. + +Opening an issue is as easy as following [this +link](https://github.com/rust-lang/rust/issues/new) and filling out the fields +in the appropriate provided template. + +## Pull Requests + +Pull requests are the primary mechanism we use to change Rust. GitHub itself +has some [great documentation][about-pull-requests] on using the Pull Request feature. +We use the "fork and pull" model [described here][development-models], where +contributors push changes to their personal fork and create pull requests to +bring those changes into the source repository. + +[about-pull-requests]: https://help.github.com/articles/about-pull-requests/ +[development-models]: https://help.github.com/articles/about-collaborative-development-models/ + +Please make pull requests against the `master` branch. + +Rust follows a _no merge-commit policy_, meaning, when you encounter merge +conflicts you are expected to always rebase instead of merge. E.g. always use +rebase when bringing the latest changes from the master branch to your feature +branch. Also, please make sure that fixup commits are squashed into other +related commits with meaningful commit messages. + +GitHub allows [closing issues using keywords][closing-keywords]. This feature +should be used to keep the issue tracker tidy. However, it is generally preferred +to put the "closes #123" text in the PR description rather than the issue commit; +particularly during rebasing, citing the issue number in the commit can "spam" +the issue in question. + +[closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords + +Please make sure your pull request is in compliance with Rust's style +guidelines by running + + $ ./x.py test tidy + +Make this check before every pull request (and every new commit in a pull +request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) +before every push to make sure you never forget to make this check. The +CI will also run tidy and will fail if tidy fails. + +All pull requests are reviewed by another person. We have a bot, +[@rust-highfive][rust-highfive], that will automatically assign a random person +to review your request. + +If you want to request that a specific person reviews your pull request, you +can add an `r?` to the pull request description. For example, +[Steve][steveklabnik] usually reviews documentation changes. So if you were to +make a documentation change, add + + r? @steveklabnik + +to the end of the pull request description, and [@rust-highfive][rust-highfive] will assign +[@steveklabnik][steveklabnik] instead of a random person. This is entirely optional. + +After someone has reviewed your pull request, they will leave an annotation +on the pull request with an `r+`. It will look something like this: + + @bors r+ + +This tells [@bors][bors], our lovable integration bot, that your pull request has +been approved. The PR then enters the [merge queue][merge-queue], where [@bors][bors] +will run all the tests on every platform we support. If it all works out, +[@bors][bors] will merge your code into `master` and close the pull request. + +Depending on the scale of the change, you may see a slightly different form of `r+`: + + @bors r+ rollup + +The additional `rollup` tells [@bors][bors] that this change is eligible for to be +"rolled up". Changes that are rolled up are tested and merged at the same time, to +speed the process up. Typically only small changes that are expected not to conflict +with one another are rolled up. + +[rust-highfive]: https://github.com/rust-highfive +[steveklabnik]: https://github.com/steveklabnik +[bors]: https://github.com/bors +[merge-queue]: https://buildbot2.rust-lang.org/homu/queue/rust + +Speaking of tests, Rust has a comprehensive test suite. More information about +it can be found [here][rctd]. + +### External Dependencies (subtree) + +As a developer to this repository, you don't have to treat the following external projects +differently from other crates that are directly in this repo: + +* Clippy + +They are just regular files and directories. This is in contrast to `submodule` dependencies +(see below for those). Only tool authors will actually use any operations here. + +#### Synchronizing a subtree + +There are two synchronization directions: `subtree push` and `subtree pull`. + +``` +git subtree push -P src/tools/clippy git@github.com:your-github-name/rust-clippy sync-from-rust +``` + +takes all the changes that +happened to the copy in this repo and creates commits on the remote repo that match the local +changes. Every local commit that touched the subtree causes a commit on the remote repo, but is +modified to move the files from the specified directory to the tool repo root. + +Make sure to not pick the `master` branch on the tool repo, so you can open a normal PR to the tool +to merge that subrepo push. + +``` +git subtree pull -P src/tools/clippy https://github.com/rust-lang/rust-clippy master +``` + +takes all changes since the last `subtree pull` from the tool repo +repo and adds these commits to the rustc repo + a merge commit that moves the tool changes into +the specified directory in the rust repository. + +It is recommended that you always do a push first and get that merged to the tool master branch. +Then, when you do a pull, the merge works without conflicts. +While it's definitely possible to resolve conflicts during a pull, you may have to redo the conflict +resolution if your PR doesn't get merged fast enough and there are new conflicts. Do not try to +rebase the result of a `git subtree pull`, rebasing merge commits is a bad idea in general. + +You always need to specify the `-P` prefix to the subtree directory and the corresponding remote +repository. If you specify the wrong directory or repository +you'll get very fun merges that try to push the wrong directory to the wrong remote repository. +Luckily you can just abort this without any consequences by throwing away either the pulled commits +in rustc or the pushed branch on the remote and try again. It is usually fairly obvious +that this is happening because you suddenly get thousands of commits that want to be synchronized. + +#### Creating a new subtree dependency + +If you want to create a new subtree dependency from an existing repository, call (from this +repository's root directory!) + +``` +git subtree add -P src/tools/clippy https://github.com/rust-lang/rust-clippy.git master +``` + +This will create a new commit, which you may not rebase under any circumstances! Delete the commit +and redo the operation if you need to rebase. + +Now you're done, the `src/tools/clippy` directory behaves as if Clippy were part of the rustc +monorepo, so no one but you (or others that synchronize subtrees) actually needs to use `git subtree`. + + +### External Dependencies (submodules) + +Currently building Rust will also build the following external projects: + +* [miri](https://github.com/rust-lang/miri) +* [rustfmt](https://github.com/rust-lang/rustfmt) +* [rls](https://github.com/rust-lang/rls/) + +We allow breakage of these tools in the nightly channel. Maintainers of these +projects will be notified of the breakages and should fix them as soon as +possible. + +After the external is fixed, one could add the changes with + +```sh +git add path/to/submodule +``` + +outside the submodule. + +In order to prepare your tool-fixing PR, you can run the build locally by doing +`./x.py build src/tools/TOOL`. If you will be editing the sources +there, you may wish to set `submodules = false` in the `config.toml` +to prevent `x.py` from resetting to the original branch. + +Breakage is not allowed in the beta and stable channels, and must be addressed +before the PR is merged. + +#### Breaking Tools Built With The Compiler + +Rust's build system builds a number of tools that make use of the +internals of the compiler. This includes +[RLS](https://github.com/rust-lang/rls) and +[rustfmt](https://github.com/rust-lang/rustfmt). If these tools +break because of your changes, you may run into a sort of "chicken and egg" +problem. These tools rely on the latest compiler to be built so you can't update +them to reflect your changes to the compiler until those changes are merged into +the compiler. At the same time, you can't get your changes merged into the compiler +because the rust-lang/rust build won't pass until those tools build and pass their +tests. + +That means that, in the default state, you can't update the compiler without first +fixing rustfmt, rls and the other tools that the compiler builds. + +Luckily, a feature was [added to Rust's build](https://github.com/rust-lang/rust/issues/45861) +to make all of this easy to handle. The idea is that we allow these tools to be "broken", +so that the rust-lang/rust build passes without trying to build them, then land the change +in the compiler, wait for a nightly, and go update the tools that you broke. Once you're done +and the tools are working again, you go back in the compiler and update the tools +so they can be distributed again. + +This should avoid a bunch of synchronization dances and is also much easier on contributors as +there's no need to block on rls/rustfmt/other tools changes going upstream. + +Here are those same steps in detail: + +1. (optional) First, if it doesn't exist already, create a `config.toml` by copying + `config.toml.example` in the root directory of the Rust repository. + Set `submodules = false` in the `[build]` section. This will prevent `x.py` + from resetting to the original branch after you make your changes. If you + need to [update any submodules to their latest versions](#updating-submodules), + see the section of this file about that for more information. +2. (optional) Run `./x.py test src/tools/rustfmt` (substituting the submodule + that broke for `rustfmt`). Fix any errors in the submodule (and possibly others). +3. (optional) Make commits for your changes and send them to upstream repositories as a PR. +4. (optional) Maintainers of these submodules will **not** merge the PR. The PR can't be + merged because CI will be broken. You'll want to write a message on the PR referencing + your change, and how the PR should be merged once your change makes it into a nightly. +5. Wait for your PR to merge. +6. Wait for a nightly +7. (optional) Help land your PR on the upstream repository now that your changes are in nightly. +8. (optional) Send a PR to rust-lang/rust updating the submodule. + +#### Updating submodules + +These instructions are specific to updating `rustfmt`, however they may apply +to the other submodules as well. Please help by improving these instructions +if you find any discrepancies or special cases that need to be addressed. + +To update the `rustfmt` submodule, start by running the appropriate +[`git submodule` command](https://git-scm.com/book/en/v2/Git-Tools-Submodules). +For example, to update to the latest commit on the remote master branch, +you may want to run: +``` +git submodule update --remote src/tools/rustfmt +``` +If you run `./x.py build` now, and you are lucky, it may just work. If you see +an error message about patches that did not resolve to any crates, you will need +to complete a few more steps which are outlined with their rationale below. + +*(This error may change in the future to include more information.)* +``` +error: failed to resolve patches for `https://github.com/rust-lang/rustfmt` + +Caused by: + patch for `rustfmt-nightly` in `https://github.com/rust-lang/rustfmt` did not resolve to any crates +failed to run: ~/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path ~/rust/src/bootstrap/Cargo.toml +``` + +If you haven't used the `[patch]` +section of `Cargo.toml` before, there is [some relevant documentation about it +in the cargo docs](http://doc.crates.io/manifest.html#the-patch-section). In +addition to that, you should read the +[Overriding dependencies](http://doc.crates.io/specifying-dependencies.html#overriding-dependencies) +section of the documentation as well. + +Specifically, the following [section in Overriding dependencies](http://doc.crates.io/specifying-dependencies.html#testing-a-bugfix) reveals what the problem is: + +> Next up we need to ensure that our lock file is updated to use this new +> version of uuid so our project uses the locally checked out copy instead of +> one from crates.io. The way [patch] works is that it'll load the dependency +> at ../path/to/uuid and then whenever crates.io is queried for versions of +> uuid it'll also return the local version. +> +> This means that the version number of the local checkout is significant and +> will affect whether the patch is used. Our manifest declared uuid = "1.0" +> which means we'll only resolve to >= 1.0.0, < 2.0.0, and Cargo's greedy +> resolution algorithm also means that we'll resolve to the maximum version +> within that range. Typically this doesn't matter as the version of the git +> repository will already be greater or match the maximum version published on +> crates.io, but it's important to keep this in mind! + +This says that when we updated the submodule, the version number in our +`src/tools/rustfmt/Cargo.toml` changed. The new version is different from +the version in `Cargo.lock`, so the build can no longer continue. + +To resolve this, we need to update `Cargo.lock`. Luckily, cargo provides a +command to do this easily. + +``` +$ cargo update -p rustfmt-nightly +``` + +This should change the version listed in `Cargo.lock` to the new version you updated +the submodule to. Running `./x.py build` should work now. + +## Writing Documentation + +Documentation improvements are very welcome. The source of `doc.rust-lang.org` +is located in `src/doc` in the tree, and standard API documentation is generated +from the source code itself. Documentation pull requests function in the same way +as other pull requests. + +To find documentation-related issues, sort by the [T-doc label][tdoc]. + +[tdoc]: https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3Aissue%20label%3AT-doc + +You can find documentation style guidelines in [RFC 1574][rfc1574]. + +[rfc1574]: https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text + +In many cases, you don't need a full `./x.py doc`, which will build the entire +stage 2 compiler and compile the various books published on +[doc.rust-lang.org]. When updating documentation for the standard library, +first try `./x.py doc --stage 0 src/libstd`. If that fails, or if you need to +see the output from the latest version of `rustdoc`, use `--stage 1` instead of +`--stage 0`. Results should appear in `build/$TARGET/crate-docs`. + +[doc.rust-lang.org]: htts://doc.rust-lang.org + +You can also use `rustdoc` directly to check small fixes. For example, +`rustdoc src/doc/reference.md` will render reference to `doc/reference.html`. +The CSS might be messed up, but you can verify that the HTML is right. + +Additionally, contributions to the [rustc-dev-guide] are always welcome. Contributions +can be made directly at [the +rust-lang/rustc-dev-guide](https://github.com/rust-lang/rustc-dev-guide) repo. The issue +tracker in that repo is also a great way to find things that need doing. There +are issues for beginners and advanced compiler devs alike! + +## Issue Triage + +Sometimes, an issue will stay open, even though the bug has been fixed. And +sometimes, the original bug may go stale because something has changed in the +meantime. + +It can be helpful to go through older bug reports and make sure that they are +still valid. Load up an older issue, double check that it's still true, and +leave a comment letting us know if it is or is not. The [least recently +updated sort][lru] is good for finding issues like this. + +Contributors with sufficient permissions on the Rust repo can help by adding +labels to triage issues: + +* Yellow, **A**-prefixed labels state which **area** of the project an issue + relates to. + +* Magenta, **B**-prefixed labels identify bugs which are **blockers**. + +* Dark blue, **beta-** labels track changes which need to be backported into + the beta branches. + +* Light purple, **C**-prefixed labels represent the **category** of an issue. + +* Green, **E**-prefixed labels explain the level of **experience** necessary + to fix the issue. + +* The dark blue **final-comment-period** label marks bugs that are using the + RFC signoff functionality of [rfcbot] and are currently in the final + comment period. + +* Red, **I**-prefixed labels indicate the **importance** of the issue. The + [I-nominated][inom] label indicates that an issue has been nominated for + prioritizing at the next triage meeting. + +* The purple **metabug** label marks lists of bugs collected by other + categories. + +* Purple gray, **O**-prefixed labels are the **operating system** or platform + that this issue is specific to. + +* Orange, **P**-prefixed labels indicate a bug's **priority**. These labels + are only assigned during triage meetings, and replace the [I-nominated][inom] + label. + +* The gray **proposed-final-comment-period** label marks bugs that are using + the RFC signoff functionality of [rfcbot] and are currently awaiting + signoff of all team members in order to enter the final comment period. + +* Pink, **regression**-prefixed labels track regressions from stable to the + release channels. + +* The light orange **relnotes** label marks issues that should be documented in + the release notes of the next release. + +* Gray, **S**-prefixed labels are used for tracking the **status** of pull + requests. + +* Blue, **T**-prefixed bugs denote which **team** the issue belongs to. + +If you're looking for somewhere to start, check out the [E-easy][eeasy] tag. + +[inom]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-nominated +[eeasy]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy +[lru]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc +[rfcbot]: https://github.com/anp/rfcbot-rs/ + +## Out-of-tree Contributions + +There are a number of other ways to contribute to Rust that don't deal with +this repository. + +Answer questions in the _Get Help!_ channels from the [Rust Discord +server][rust-discord], on [users.rust-lang.org][users], or on +[StackOverflow][so]. + +Participate in the [RFC process](https://github.com/rust-lang/rfcs). + +Find a [requested community library][community-library], build it, and publish +it to [Crates.io](http://crates.io). Easier said than done, but very, very +valuable! + +[rust-discord]: https://discord.gg/rust-lang +[users]: https://users.rust-lang.org/ +[so]: http://stackoverflow.com/questions/tagged/rust +[community-library]: https://github.com/rust-lang/rfcs/labels/A-community-library + +## Helpful Links and Information + +For people new to Rust, and just starting to contribute, or even for +more seasoned developers, some useful places to look for information +are: + +* The [rustc dev guide] contains information about how various parts of the + compiler work and how to contribute to the compiler +* [Rust Forge][rustforge] contains additional documentation, including + write-ups of how to achieve common tasks +* The [Rust Internals forum][rif], a place to ask questions and + discuss Rust's internals +* The [generated documentation for rust's compiler][gdfrustc] +* The [rust reference][rr], even though it doesn't specifically talk about + Rust's internals, it's a great resource nonetheless +* Although out of date, [Tom Lee's great blog article][tlgba] is very helpful +* [rustaceans.org][ro] is helpful, but mostly dedicated to IRC +* The [Rust Compiler Testing Docs][rctd] +* For [@bors][bors], [this cheat sheet][cheatsheet] is helpful +(though you'll need to replace `@homu` with `@bors` in any commands) +* **Google!** ([search only in Rust Documentation][gsearchdocs] to find types, + traits, etc. quickly) +* Don't be afraid to ask! The Rust community is friendly and helpful. + +[rustc dev guide]: https://rustc-dev-guide.rust-lang.org/about-this-guide.html +[gdfrustc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ +[gsearchdocs]: https://www.google.com/search?q=site:doc.rust-lang.org+your+query+here +[rif]: http://internals.rust-lang.org +[rr]: https://doc.rust-lang.org/book/README.html +[rustforge]: https://forge.rust-lang.org/ +[tlgba]: http://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/ +[ro]: http://www.rustaceans.org/ +[rctd]: https://rustc-dev-guide.rust-lang.org/tests/intro.html +[cheatsheet]: https://buildbot2.rust-lang.org/homu/ From 431df827e2e6adea1ee44f23219ac91d926eed90 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 23 Jun 2020 12:51:07 -0500 Subject: [PATCH 1103/1812] line length --- src/contributing.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index e2bce693a..017f0c2ae 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -202,8 +202,9 @@ git subtree add -P src/tools/clippy https://github.com/rust-lang/rust-clippy.git This will create a new commit, which you may not rebase under any circumstances! Delete the commit and redo the operation if you need to rebase. -Now you're done, the `src/tools/clippy` directory behaves as if Clippy were part of the rustc -monorepo, so no one but you (or others that synchronize subtrees) actually needs to use `git subtree`. +Now you're done, the `src/tools/clippy` directory behaves as if Clippy were +part of the rustc monorepo, so no one but you (or others that synchronize +subtrees) actually needs to use `git subtree`. ### External Dependencies (submodules) From dbaa12ec12330fbf52b0f66c643ba38528b186f5 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 23 Jun 2020 12:57:15 -0500 Subject: [PATCH 1104/1812] fix links --- src/contributing.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 017f0c2ae..f6368c607 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -306,14 +306,17 @@ Caused by: failed to run: ~/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path ~/rust/src/bootstrap/Cargo.toml ``` -If you haven't used the `[patch]` -section of `Cargo.toml` before, there is [some relevant documentation about it -in the cargo docs](http://doc.crates.io/manifest.html#the-patch-section). In -addition to that, you should read the -[Overriding dependencies](http://doc.crates.io/specifying-dependencies.html#overriding-dependencies) -section of the documentation as well. - -Specifically, the following [section in Overriding dependencies](http://doc.crates.io/specifying-dependencies.html#testing-a-bugfix) reveals what the problem is: +The [`[patch]`][patchsec] section of `Cargo.toml` can be very useful for +testing. In addition to that, you should read the [Overriding +dependencies][overriding] section of the documentation. + +[patchsec]: http://doc.crates.io/manifest.html#the-patch-section +[overriding]: http://doc.crates.io/specifying-dependencies.html#overriding-dependencies + +Specifically, the following [section in Overriding dependencies][testingbugfix] +reveals what the problem is: + +[testingbugfix]: http://doc.crates.io/specifying-dependencies.html#testing-a-bugfix > Next up we need to ensure that our lock file is updated to use this new > version of uuid so our project uses the locally checked out copy instead of From e82626f802d2822a20ea2cd21d3a17f61cebaf23 Mon Sep 17 00:00:00 2001 From: mark Date: Tue, 23 Jun 2020 12:59:05 -0500 Subject: [PATCH 1105/1812] fix links --- src/contributing.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index f6368c607..d4dfc5a0b 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -374,11 +374,14 @@ You can also use `rustdoc` directly to check small fixes. For example, `rustdoc src/doc/reference.md` will render reference to `doc/reference.html`. The CSS might be messed up, but you can verify that the HTML is right. -Additionally, contributions to the [rustc-dev-guide] are always welcome. Contributions -can be made directly at [the -rust-lang/rustc-dev-guide](https://github.com/rust-lang/rustc-dev-guide) repo. The issue -tracker in that repo is also a great way to find things that need doing. There -are issues for beginners and advanced compiler devs alike! +Additionally, contributions to the [rustc-dev-guide][rdg] are always welcome. +Contributions can be made directly at [the rust-lang/rustc-dev-guide +repo][rdgrepo]. The issue tracker in that repo is also a great way to find +things that need doing. There are issues for beginners and advanced compiler +devs alike! + +[rdg]: https://rustc-dev-guide.rust-lang.org/ +[rdgrepo]: https://github.com/rust-lang/rustc-dev-guide ## Issue Triage From c2c219af6cb0758d0b07df95d1a9336146b31a2f Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 23 Jun 2020 20:59:35 -0500 Subject: [PATCH 1106/1812] Fix non-link Co-authored-by: Joshua Nelson --- src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index d4dfc5a0b..3959e14ed 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -306,7 +306,7 @@ Caused by: failed to run: ~/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path ~/rust/src/bootstrap/Cargo.toml ``` -The [`[patch]`][patchsec] section of `Cargo.toml` can be very useful for +The [`\[patch\]`][patchsec] section of `Cargo.toml` can be very useful for testing. In addition to that, you should read the [Overriding dependencies][overriding] section of the documentation. From 00b67a55de5ec17d5477ffca5906d5a068286b91 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 23 Jun 2020 22:52:33 -0500 Subject: [PATCH 1107/1812] Escape other non-link Co-authored-by: Joshua Nelson --- src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index 3959e14ed..3cadde822 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -320,7 +320,7 @@ reveals what the problem is: > Next up we need to ensure that our lock file is updated to use this new > version of uuid so our project uses the locally checked out copy instead of -> one from crates.io. The way [patch] works is that it'll load the dependency +> one from crates.io. The way `\[patch\]` works is that it'll load the dependency > at ../path/to/uuid and then whenever crates.io is queried for versions of > uuid it'll also return the local version. > From b85f30d01357163b253622ffa671743029b7d651 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 1 Jul 2020 21:42:05 -0500 Subject: [PATCH 1108/1812] fix links --- src/contributing.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 3cadde822..0667e5339 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -306,7 +306,7 @@ Caused by: failed to run: ~/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path ~/rust/src/bootstrap/Cargo.toml ``` -The [`\[patch\]`][patchsec] section of `Cargo.toml` can be very useful for +The [`[patch]`][patchsec] section of `Cargo.toml` can be very useful for testing. In addition to that, you should read the [Overriding dependencies][overriding] section of the documentation. @@ -320,7 +320,7 @@ reveals what the problem is: > Next up we need to ensure that our lock file is updated to use this new > version of uuid so our project uses the locally checked out copy instead of -> one from crates.io. The way `\[patch\]` works is that it'll load the dependency +> one from crates.io. The way `[patch]` works is that it'll load the dependency > at ../path/to/uuid and then whenever crates.io is queried for versions of > uuid it'll also return the local version. > @@ -363,12 +363,12 @@ You can find documentation style guidelines in [RFC 1574][rfc1574]. In many cases, you don't need a full `./x.py doc`, which will build the entire stage 2 compiler and compile the various books published on -[doc.rust-lang.org]. When updating documentation for the standard library, +[doc.rust-lang.org][docs]. When updating documentation for the standard library, first try `./x.py doc --stage 0 src/libstd`. If that fails, or if you need to see the output from the latest version of `rustdoc`, use `--stage 1` instead of `--stage 0`. Results should appear in `build/$TARGET/crate-docs`. -[doc.rust-lang.org]: htts://doc.rust-lang.org +[docs]: https://doc.rust-lang.org You can also use `rustdoc` directly to check small fixes. For example, `rustdoc src/doc/reference.md` will render reference to `doc/reference.html`. From bd1801c8b9b1fc050c7e5a2b37095d5cfc023bbb Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Thu, 2 Jul 2020 23:28:32 +0900 Subject: [PATCH 1109/1812] Fix the names of table of contents and heading are different Not to write the part of Appendix `A` in heading along with other appendix. --- src/appendix/background.md | 2 +- src/appendix/code-index.md | 2 +- src/appendix/glossary.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/appendix/background.md b/src/appendix/background.md index 983f028a0..e7b9f3afc 100644 --- a/src/appendix/background.md +++ b/src/appendix/background.md @@ -1,4 +1,4 @@ -# Appendix B: Background topics +# Background topics This section covers a numbers of common compiler terms that arise in this guide. We try to give the general definition while providing some diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 76f4609cc..8561efe4c 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -1,4 +1,4 @@ -# Appendix D: Code Index +# Code Index rustc has a lot of important data structures. This is an attempt to give some guidance on where to learn more about some of the key data structures of the diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index f428c8f0b..9e8703d1b 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -1,4 +1,4 @@ -# Appendix C: Glossary +# Glossary Term | Meaning -----------------------------------------|-------- From 7a42bf2c925e6c2fa940a6264edd6a5bbfa223cb Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 2 Jul 2020 17:37:29 -0500 Subject: [PATCH 1110/1812] add stub inline asm chapter (#773) --- src/backend/inline-asm.md | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 src/backend/inline-asm.md diff --git a/src/backend/inline-asm.md b/src/backend/inline-asm.md new file mode 100644 index 000000000..0cae01ef3 --- /dev/null +++ b/src/backend/inline-asm.md @@ -0,0 +1,4 @@ +# Inline Assembly + +**TODO: You can find more info in +https://github.com/rust-lang/rust/pull/69171#issue-375572066** From 30518e3df2cc732d87c4db6611c0d15ca1146f92 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 3 Jul 2020 08:28:44 -0700 Subject: [PATCH 1111/1812] Minor updates to stage docs. (#781) --- src/building/bootstrapping.md | 20 ++++++++++---------- src/building/how-to-build-and-run.md | 9 +++++---- src/img/rustc_stages.svg | 3 ++- 3 files changed, 17 insertions(+), 15 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index e7a031522..cce9fac49 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -128,7 +128,7 @@ The following tables indicate the outputs of various stage actions: |-----------------------------------------------------------|----------------------------------------------| | `beta` extracted | `build/HOST/stage0` | | `stage0` builds `bootstrap` | `build/bootstrap` | -| `stage0` builds `libstd` | `build/HOST/stage0-std/TARGET` | +| `stage0` builds `libtest`/`libstd` | `build/HOST/stage0-std/TARGET` | | copy `stage0-std` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | | `stage0` builds `rustc` with `stage0-sysroot` | `build/HOST/stage0-rustc/HOST` | | copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | @@ -143,7 +143,7 @@ The following tables indicate the outputs of various stage actions: | copy (uplift) `stage0-rustc` executable to `stage1` | `build/HOST/stage1/bin` | | copy (uplift) `stage0-codegen` to `stage1` | `build/HOST/stage1/lib` | | copy (uplift) `stage0-sysroot` to `stage1` | `build/HOST/stage1/lib` | -| `stage1` builds `libstd` | `build/HOST/stage1-std/TARGET` | +| `stage1` builds `libtest`/`libstd` | `build/HOST/stage1-std/TARGET` | | copy `stage1-std` (HOST only) | `build/HOST/stage1/lib/rustlib/HOST` | | `stage1` builds `rustc` | `build/HOST/stage1-rustc/HOST` | | copy `stage1-rustc` (except executable) | `build/HOST/stage1/lib/rustlib/HOST` | @@ -151,14 +151,14 @@ The following tables indicate the outputs of various stage actions: `--stage=1` stops here. -| Stage 2 Action | Output | -|-------------------------------------------|-----------------------------------------------------------------| -| copy (uplift) `stage1-rustc` executable | `build/HOST/stage2/bin` | -| copy (uplift) `stage1-sysroot` | `build/HOST/stage2/lib and build/HOST/stage2/lib/rustlib/HOST` | -| `stage2` builds `libstd` (except HOST?) | `build/HOST/stage2-std/TARGET` | -| copy `stage2-std` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | -| `stage2` builds `rustdoc` | `build/HOST/stage2-tools/HOST` | -| copy `rustdoc` | `build/HOST/stage2/bin` | +| Stage 2 Action | Output | +|--------------------------------------------------------|-----------------------------------------------------------------| +| copy (uplift) `stage1-rustc` executable | `build/HOST/stage2/bin` | +| copy (uplift) `stage1-sysroot` | `build/HOST/stage2/lib and build/HOST/stage2/lib/rustlib/HOST` | +| `stage2` builds `libtest`/`libstd` (not HOST targets) | `build/HOST/stage2-std/TARGET` | +| copy `stage2-std` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | +| `stage2` builds `rustdoc` | `build/HOST/stage2-tools/HOST` | +| copy `rustdoc` | `build/HOST/stage2/bin` | `--stage=2` stops here. diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 586fa3a2d..f9ce3f734 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -95,10 +95,11 @@ The result is that compiling `rustc` is done in stages: particular, the stage1 compiler itself was built by stage0 and hence not by the source in your working directory: this means that the symbol names used in the compiler source may not match the - symbol names that would have been made by the stage1 compiler. - This can be important when using dynamic linking (e.g., with - derives). Sometimes this means that some tests don't work when run - with stage1. + symbol names that would have been made by the stage1 compiler. This is + important when using dynamic linking and the lack of ABI compatibility + between versions. This primarily manifests when tests try to link with any + of the `rustc_*` crates or use the (now deprecated) plugin infrastructure. + These tests are marked with `ignore-stage1`. - **Stage 2:** we rebuild our stage1 compiler with itself to produce the stage2 compiler (i.e. it builds itself) to have all the _latest optimizations_. (By default, we copy the stage1 libraries for use by diff --git a/src/img/rustc_stages.svg b/src/img/rustc_stages.svg index b6671aa7c..25f7ab11b 100644 --- a/src/img/rustc_stages.svg +++ b/src/img/rustc_stages.svg @@ -1,2 +1,3 @@ + -
Download
Download
beta
beta
stage0
stage0
Builds
Builds
stage0
stage0
Outputs
Outputs
libstd
libstd
Copy
Copy
stage0-std
stage0-std
stage0-sysroot
stage0-sysroot
Builds
Builds
stage0
stage0
Outputs
Outputs
libtest
libtest
Copy
Copy
stage0-test
stage0-test
stage0-sysroot
stage0-sysroot
Builds
Builds
stage0
stage0
Outputs
Outputs
rustc
rustc
Copy
Copy
stage0-rustc
stage0-rustc
stage0-sysroot
stage0-sysroot
llvm
llvm
Builds
Builds
stage0
stage0
Outputs
Outputs
codegen
codegen
stage0-codegen
stage0-codegen
Stage 0
Stage 0
Copy
Copy
stage0-rustc
stage0-codegen
stage0-sysroot
[Not supported by viewer]
stage1
stage1
Builds
Builds
stage1
stage1
Outputs
Outputs
libstd
libstd
Copy
Copy
stage1-std
stage1-std
stage1/lib/rustlib
stage1/lib/rustlib
Builds
Builds
stage1
stage1
Outputs
Outputs
libtest
libtest
Copy
Copy
stage1-test
stage1-test
stage1/lib/rustlib
stage1/lib/rustlib
Builds
Builds
stage1
stage1
Outputs
Outputs
rustc
rustc
Copy
Copy
stage1-rustc
stage1-rustc
stage1/lib/rustlib
stage1/lib/rustlib
Builds
Builds
stage1
stage1
Outputs
Outputs
codegen
codegen
stage1-codegen
stage1-codegen
Stage 1
[Not supported by viewer]
Copy
Copy
stage1-rustc
stage1-codegen
stage1/lib/rustlib
[Not supported by viewer]
stage2
stage2
Builds
Builds
stage2
stage2
Outputs
Outputs
rustdoc
rustdoc
Copy
[Not supported by viewer]
stage2-tools
stage2-tools
Builds
Builds
stage0
stage0
bootstrap
bootstrap
llvm
llvm
stage2
stage2
Stage 2
[Not supported by viewer] \ No newline at end of file +
Download
Download
beta
beta
stage0
stage0
Builds
Builds
stage0
stage0
Outputs
Outputs
libtest/libstd
libtest/libstd
Copy
Copy
stage0-std
stage0-std
stage0-sysroot
stage0-sysroot
Builds
Builds
stage0
stage0
Outputs
Outputs
rustc
rustc
Copy
Copy
stage0-rustc
stage0-rustc
stage0-sysroot
stage0-sysroot
llvm
llvm
Builds
Builds
stage0
stage0
Outputs
Outputs
codegen
codegen
stage0-codegen
stage0-codegen
Stage 0
Stage 0
Copy
Copy
stage0-rustc
stage0-codegen
stage0-sysroot
stage0-rustc...
stage1
stage1
Builds
Builds
stage1
stage1
Outputs
Outputs
libtest/libstd
libtest/libstd
Copy
Copy
stage1-std
stage1-std
stage1/lib/rustlib
stage1/lib/rustlib
Builds
Builds
stage1
stage1
Outputs
Outputs
rustc
rustc
Copy
Copy
stage1-rustc
stage1-rustc
stage1/lib/rustlib
stage1/lib/rustlib
Builds
Builds
stage1
stage1
Outputs
Outputs
codegen
codegen
stage1-codegen
stage1-codegen
Stage 1
Stage 1
Copy
Copy
stage1-rustc
stage1-codegen
stage1/lib/rustlib
stage1-rustc...
stage2
stage2
Builds
Builds
stage2
stage2
Outputs
Outputs
rustdoc
rustdoc
Copy
Copy
stage2-tools
stage2-tools
Builds
Builds
stage0
stage0
bootstrap
bootstrap
llvm
llvm
stage2
stage2
Stage 2
Stage 2Viewer does not support full SVG 1.1 \ No newline at end of file From 2c51b6f6289f1575698c64ada5a3ce197059c6ad Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Sat, 4 Jul 2020 00:31:52 +0900 Subject: [PATCH 1112/1812] Fix jump marker of debruijn index (#783) --- src/appendix/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 9e8703d1b..748f4feb5 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -15,7 +15,7 @@ CTFE
| Short for Compile-Time Function Eval cx
| We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. DAG
| A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) data-flow analysis
| A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). -DeBruijn Index
| A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#debruijn)) +DeBruijn Index
| A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) DefId
| An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). Discriminant
| The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). Double pointer
| A pointer with additional metadata. See "fat pointer" for more. From 88f57a5c79910297359637a4dbbb61bc3e6f1eac Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 3 Jul 2020 09:56:05 -0700 Subject: [PATCH 1113/1812] Update mdbook --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 4a78953cb..a217f1cac 100644 --- a/.travis.yml +++ b/.travis.yml @@ -11,7 +11,7 @@ before_install: - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true -- cargo install mdbook --version 0.4.0 +- cargo install mdbook --version 0.4.1 - cargo install mdbook-linkcheck --version 0.7.0 script: - git checkout -b ci From 689eca469d27a605957dadd265007ab676cea049 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 2 Jul 2020 22:35:47 -0700 Subject: [PATCH 1114/1812] Update docs on using Docker images. --- src/tests/intro.md | 50 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 44 insertions(+), 6 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index 2fa1363d0..b772da011 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -136,16 +136,54 @@ Rust's [platform tiers]). ## Testing with Docker images The Rust tree includes [Docker] image definitions for the platforms used on -Azure Pipelines in [src/ci/docker]. The script [src/ci/docker/run.sh] is used to build +Azure Pipelines in [`src/ci/docker`]. The script [`src/ci/docker/run.sh`] is used to build the Docker image, run it, build Rust within the image, and run the tests. -> TODO: What is a typical workflow for testing/debugging on a platform that -> you don't have easy access to? Do people build Docker images and enter them -> to test things out? +You can run these images on your local development machine. This can be +helpful to test environments different from your local system. First you will +need to install Docker on a Linux, Windows, or macOS system (typically Linux +will be much faster than Windows or macOS because the later use virtual +machines to emulate a Linux environment). To enter interactive mode which will +start a bash shell in the container, run `src/ci/docker/run.sh --dev ` +where `` is one of the directory names in `src/ci/docker` (for example +`x86_64-gnu` is a fairly standard Ubuntu environment). + +The docker script will mount your local rust source tree in read-only mode, +and an `obj` directory in read-write mode. All of the compiler artifacts will +be stored in the `obj` directory. The shell will start out in the `obj` +directory. From there, you can run `../src/ci/run.sh` which will run the build +as defined by the image. + +Alternatively, you can run individual commands to do specific tasks. For +example, you can run `python3 ../x.py test src/test/ui` to just run UI tests. +Note that there is some configuration in the [`src/ci/run.sh`] script that you +may need to recreate. Particularly, set `submodules = false` in your +`config.toml` so that it doesn't attempt to modify the read-only directory. + +Some additional notes about using the Docker images: + +- Some of the std tests require IPv6 support. Docker on Linux seems to have it + disabled by default. Run the commands in [`enable-docker-ipv6.sh`] to enable + IPv6 before creating the container. This only needs to be done once. +- The container will be deleted automatically when you exit the shell, however + the build artifacts persist in the `obj` directory. If you are switching + between different Docker images, the artifacts from previous environments + stored in the `obj` directory may confuse the build system. Sometimes you + will need to delete parts or all of the `obj` directory before building + inside the container. +- The container is bare-bones, with only a minimal set of packages. You may + want to install some things like `apt install less vim`. +- You can open multiple shells in the container. First you need the container + name (a short hash), which is displayed in the shell prompt, or you can run + `docker container ls` outside of the container to list the available + containers. With the container name, run `docker exec -it + /bin/bash` where `` is the container name like `4ba195e95cef`. [Docker]: https://www.docker.com/ -[src/ci/docker]: https://github.com/rust-lang/rust/tree/master/src/ci/docker -[src/ci/docker/run.sh]: https://github.com/rust-lang/rust/blob/master/src/ci/docker/run.sh +[`src/ci/docker`]: https://github.com/rust-lang/rust/tree/master/src/ci/docker +[`src/ci/docker/run.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/docker/run.sh +[`src/ci/run.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/run.sh +[`enable-docker-ipv6.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/scripts/enable-docker-ipv6.sh ## Running tests on a remote machine From 87b9ecf2bbe4da7396bbe1d6b504841eb273f1ab Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 5 Jul 2020 02:40:39 +0900 Subject: [PATCH 1115/1812] Fix link for armhf-gnu Dockerfile --- src/tests/intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index b772da011..0f517f871 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -266,7 +266,7 @@ emulation on Travis. The following will take a look at how a target's tests are run under emulation. The Docker image for [armhf-gnu] includes [QEMU] to emulate the ARM CPU -architecture. Included in the Rust tree are the tools [remote-test-client] +architecture. Included in the Rust tree are the tools [remote-test-client] and [remote-test-server] which are programs for sending test programs and libraries to the emulator, and running the tests within the emulator, and reading the results. The Docker image is set up to launch @@ -279,7 +279,7 @@ communicate with the server to coordinate running tests (see > > It's also unclear to me how the wasm or asm.js tests are run. -[armhf-gnu]: https://github.com/rust-lang/rust/tree/master/src/ci/docker/armhf-gnu +[armhf-gnu]: https://github.com/rust-lang/rust/tree/master/src/ci/docker/host-x86_64/armhf-gnu/Dockerfile [QEMU]: https://www.qemu.org/ [remote-test-client]: https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-client [remote-test-server]: https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-server From eb07beaf8e348d7ffdc6113bf549a6b033510e92 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 4 Jul 2020 10:22:29 -0700 Subject: [PATCH 1116/1812] Update bug report links. --- src/contributing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 0667e5339..8e0eebb70 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -49,7 +49,7 @@ If you're using the nightly channel, please check if the bug exists in the latest toolchain before filing your bug. It might be fixed already. If you have the chance, before reporting a bug, please [search existing -issues](https://github.com/rust-lang/rust/search?q=&type=Issues&utf8=%E2%9C%93), +issues](https://github.com/rust-lang/rust/issues?q=is%3Aissue), as it's possible that someone else has already reported your error. This doesn't always work, and sometimes it's hard to know what to search for, so consider this extra credit. We won't mind if you accidentally file a duplicate report. @@ -62,7 +62,7 @@ An example could be: **"impossible case reached" on lifetime inference for impl Trait in return position**. Opening an issue is as easy as following [this -link](https://github.com/rust-lang/rust/issues/new) and filling out the fields +link](https://github.com/rust-lang/rust/issues/new/choose) and filling out the fields in the appropriate provided template. ## Pull Requests From f3339032d626b3cb5b7cad4b082d33003c2a4809 Mon Sep 17 00:00:00 2001 From: Nadrieril Date: Thu, 2 Jul 2020 22:16:34 +0100 Subject: [PATCH 1117/1812] Suggest selectively disabling optimizations --- src/building/suggested.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/building/suggested.md b/src/building/suggested.md index 4491a3b72..102586721 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -87,6 +87,22 @@ You can also use `--keep-stage 1` when running tests. Something like this: - Initial test run: `./x.py test -i --stage 1 src/test/ui` - Subsequent test run: `./x.py test -i --stage 1 src/test/ui --keep-stage 1` +## Fine-tuning optimizations + +Setting `optimize = false` makes the compiler too slow for tests. However, to +improve the test cycle, you can disable optimizations selectively only for the +crates you'll have to rebuild +([source](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/incremental.20compilation.20question/near/202712165)). +For example, when working on `rustc_mir_build`, the `rustc_mir_build` and +`rustc_driver` crates take the most time to incrementally rebuild. You could +therefore set the following in the root `Cargo.toml`: +```toml +[profile.release.package.rustc_mir_build] +opt-level = 0 +[profile.release.package.rustc_driver] +opt-level = 0 +``` + ## Working on multiple branches at the same time Working on multiple branches in parallel can be a little annoying, since From 954802cc68af2596174b9e338f1145e288031262 Mon Sep 17 00:00:00 2001 From: Matt Kraai Date: Sat, 4 Jul 2020 23:19:10 +0000 Subject: [PATCH 1118/1812] Canonicalize part 1 name (#788) --- src/about-this-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index dfe14d224..11b0876a9 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -6,7 +6,7 @@ development. There are six parts to this guide: -1. [Building and Debugging to `rustc`][p1]: Contains information that should be +1. [Building and debugging `rustc`][p1]: Contains information that should be useful no matter how you are contributing, about building, debugging, profiling, etc. 2. [Contributing to `rustc`][p1-5]: Contains information that should be useful From b04ff74782ee440f446bf30ad963e66a9e972faa Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 10 Jul 2020 18:14:16 -0300 Subject: [PATCH 1119/1812] inluding -> including --- src/about-this-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 11b0876a9..77dbf2699 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -20,7 +20,7 @@ There are six parts to this guide: properties of the code and inform later stages of the compile process (e.g., type checking). 5. [From MIR to Binaries][p5]: How linked executable machine code is generated. 6. [Appendices][app] at the end with useful reference information. There are a - few of these with different information, inluding a glossary. + few of these with different information, including a glossary. [p1]: ./getting-started.md [p1-5]: ./compiler-team.md From 745c831429d6ac5a6a34245e60992123a7b88cea Mon Sep 17 00:00:00 2001 From: Ivan Veselov Date: Sat, 11 Jul 2020 15:25:04 +0100 Subject: [PATCH 1120/1812] Fix typo: review -> reviewer --- src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index c74f72cc5..c2a1308b6 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -189,7 +189,7 @@ questions or discuss things you don't understand or disagree with. However, recognize that the PR won't be merged unless someone on the rust team approves it. -When your review approves the PR, it will go into a queue for yet another bot +When your reviewer approves the PR, it will go into a queue for yet another bot called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches the head of the `@bors` queue, `@bors` will test out the merge by running all tests against your PR on Travis CI. This takes a lot of time to From 3394e1696a6d4d5727a56b5f7b45af56394e1ef8 Mon Sep 17 00:00:00 2001 From: Ivan Veselov Date: Sun, 12 Jul 2020 02:29:17 +0100 Subject: [PATCH 1121/1812] Earlier clarification of pFCP abbreviation (#791) --- src/implementing_new_features.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 686c9b270..233d223db 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -20,12 +20,13 @@ process (e.g. a big refactoring of the code, or a amounts to a small feature) but is still too controversial or big to get by with a single r+, you can start a pFCP (or, if you don't have r+ rights, ask someone who has them to start one - and -unless they have a concern themselves, they should). +unless they have a concern themselves, they should). pFCP stands for +"proposed final comment period". Again, the pFCP process is only needed if you need consensus - if you don't think anyone would have a problem with your change, it's ok to get by with only an r+. For example, it is OK to add or modify -unstable command-line flags or attributes without an pFCP for +unstable command-line flags or attributes without a pFCP for compiler development or standard library use, as long as you don't expect them to be in wide use in the nightly ecosystem. @@ -33,10 +34,10 @@ You don't need to have the implementation fully ready for r+ to ask for a pFCP, but it is generally a good idea to have at least a proof of concept so that people can see what you are talking about. -That starts a "proposed final comment period" (pFCP), which requires -all members of the team to sign off the FCP. After they all do so, -there's a 10 day long "final comment period" where everybody can comment, -and if no new concerns are raised, the PR/issue gets FCP approval. +When a pFCP is started, it requires all members of the team to sign off +the FCP. After they all do so, there's a 10 day long "final comment +period" where everybody can comment, and if no new concerns are raised, +the PR/issue gets FCP approval. ## The logistics of writing features From d3e682e590b0fcb3c975a5c33c048068379fa5f4 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 14 Jul 2020 10:06:22 +0900 Subject: [PATCH 1122/1812] Fix the difference of title in appendix A (#793) --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 5a1dcc68e..4f1c73293 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -145,7 +145,7 @@ --- -[Appendix A: Background material](./appendix/background.md) +[Appendix A: Background topics](./appendix/background.md) [Appendix B: Glossary](./appendix/glossary.md) [Appendix C: Code Index](./appendix/code-index.md) [Appendix D: Compiler Lecture Series](./appendix/compiler-lecture.md) From f196779cbecd5230c9b1c7516136a1daaab2c3ee Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sat, 11 Jul 2020 15:50:34 -0400 Subject: [PATCH 1123/1812] Improve getting-started guide - Clean up wording - Suggest `build --stage 1 src/libstd`, which doesn't recompile rustc twice unnecessarily - Fix rustdoc globs which only work on Linux - Add suggestion for `build --stage 0 src/libstd` - Suggest `-j1` for very slow builds - Suggesting letting CI run tests when using a slow machine --- src/getting-started.md | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index a848b0b75..9d5c86a03 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -83,12 +83,18 @@ you use your system's LLVM ([see below][configsec]). Like `cargo`, the build system will use as many cores as possible. Sometimes this can cause you to run low on memory. You can use `-j` to adjust the number -concurrent jobs. +concurrent jobs. If a full build takes more than ~45 minutes to an hour, +you are probably spending most of the time swapping memory in and out; +try using `-j1`. -Also, if you don't have too much free disk space, you may want to turn off +On a slow machine, the build times for rustc are very painful. Consider using +`./x.py check` instead of a full build and letting the automated tests run +when you push to GitHub. + +If you don't have too much free disk space, you may want to turn off incremental compilation ([see below][configsec]). This will make -compilation take longer, but will save a ton of space from the incremental -caches. +compilation take longer (especially after a rebase), +but will save a ton of space from the incremental caches. ### Cloning @@ -169,10 +175,10 @@ should still read the rest of the section: | Command | When to use it | | --- | --- | | `x.py check` | Quick check to see if things compile; rust-analyzer can run this automatically for you | -| `x.py build --stage 1` | Build just the 1st stage of the compiler; this is faster than building stage 2 and usually good enough | -| `x.py build --stage 1 --keep-stage 1` | Build the 1st stage of the compiler and skips rebuilding the library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | -| `x.py test --stage 1` | Run the test suite using the stage1 compiler (first build) | -| `x.py test --stage 1 --keep-stage 1` | Run the test suite using the stage1 compiler (subsequent builds) | +| `x.py build --stage 0 src/libstd` | Build only the standard library, without building the compiler | +| `x.py build --stage 1 src/libstd` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough | +| `x.py build --stage 1 --keep-stage 1 src/libstd` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | +| `x.py test --stage 1 [--keep-stage 1]` | Run the test suite using the stage1 compiler | | `x.py test --stage 1 --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. | | `x.py build` | Do a full 2-stage build. You almost never want to do this. | | `x.py test` | Do a full 2-stage build and run all tests. You almost never want to do this. | @@ -197,10 +203,10 @@ For most contributions, you only need to build stage 1, which saves a lot of tim ```sh # Build the compiler (stage 1) -./x.py build --stage 1 +./x.py build --stage 1 src/libstd # Subsequent builds -./x.py build --stage 1 --keep-stage 1 +./x.py build --stage 1 --keep-stage 1 src/libstd ``` This will take a while, especially the first time. Be wary of accidentally @@ -281,7 +287,7 @@ the stage-2 compiler, which of course requires a 2-stage build, described above In practice, though, you don't need to build the compiler unless you are planning to use a recently added nightly feature. Instead, you can just build -stage 0 (i.e. which basically just uses the current beta compiler). +stage 0, which uses the current beta compiler. ```sh ./x.py build --stage 0 src/libstd @@ -326,7 +332,7 @@ Rustdoc has two types of tests: content tests and UI tests. ./x.py test --stage 1 src/test/rustdoc-ui # Both at once -./x.py test --stage 1 src/test/rustdoc* +./x.py test --stage 1 src/test/rustdoc src/test/rustdoc-ui ``` ### Contributing code to other Rust projects From 37ab8da24d63db35f0060daa850c7bf676e075e6 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 14 Jul 2020 16:20:30 +0900 Subject: [PATCH 1124/1812] Fix distortions of "representation" --- src/SUMMARY.md | 2 +- src/part-3-intro.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4f1c73293..53e75fc09 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -59,7 +59,7 @@ - [Parallel Compilation](./parallel-rustc.md) - [Rustdoc](./rustdoc-internals.md) -# Source Code Representations +# Source Code Representation - [Prologue](./part-3-intro.md) - [Command-line arguments](./cli.md) diff --git a/src/part-3-intro.md b/src/part-3-intro.md index 2af8cce23..c10080632 100644 --- a/src/part-3-intro.md +++ b/src/part-3-intro.md @@ -1,4 +1,4 @@ -# Part 3: Source Code Representations +# Part 3: Source Code Representation This part describes the process of taking raw source code from the user and transforming it into various forms that the compiler can work with easily. From 2c49ec23676a3a2c7a07ae3e0f129d184e8ff057 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 14 Jul 2020 16:20:44 +0900 Subject: [PATCH 1125/1812] Fix typos --- src/backend/backend-agnostic.md | 4 ++-- src/backend/debugging.md | 2 +- src/backend/implicit-caller-location.md | 2 +- src/backend/lowering-mir.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md index 209df0afa..d0984feec 100644 --- a/src/backend/backend-agnostic.md +++ b/src/backend/backend-agnostic.md @@ -2,7 +2,7 @@ In the future, it would be nice to allow other codegen backends (e.g. [Cranelift]). To this end, `librustc_codegen_ssa` provides an -abstract interface for all backends to implenent. +abstract interface for all backends to implement. [Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/master/cranelift @@ -175,7 +175,7 @@ in the LLVM implementation of the trait). The traits offer an API which is very similar to the API of LLVM. This is not the best solution since LLVM has a very special way of doing things: when -addding another backend, the traits definition might be changed in order to +adding another backend, the traits definition might be changed in order to offer more flexibility. However, the current separation between backend-agnostic and LLVM-specific code diff --git a/src/backend/debugging.md b/src/backend/debugging.md index 06e62d9ec..f8ea4f5ed 100644 --- a/src/backend/debugging.md +++ b/src/backend/debugging.md @@ -117,7 +117,7 @@ tutorial above): - The `-Cno-prepopulate-passes` will avoid pre-populate the LLVM pass manager with a list of passes. This will allow you to view the LLVM IR that rustc generates, not the LLVM IR after optimizations. -- The `-Cpasses=val` option allows you to supply a (space seprated) list of extra LLVM passes to run +- The `-Cpasses=val` option allows you to supply a space separated list of extra LLVM passes to run - The `-Csave-temps` option saves all temporary output files during compilation - The `-Zprint-llvm-passes` option will print out LLVM optimization passes being run - The `-Ztime-llvm-passes` option measures the time of each LLVM pass diff --git a/src/backend/implicit-caller-location.md b/src/backend/implicit-caller-location.md index c6dc89f65..e0a12415e 100644 --- a/src/backend/implicit-caller-location.md +++ b/src/backend/implicit-caller-location.md @@ -84,7 +84,7 @@ the approach: as we grow the stack down we pass an additional argument to calls rather than walking up the stack when the intrinsic is called. That additional argument can be returned wherever the caller location is queried. -The argument we append is of type `&'static core::panic::Location<'staic>`. A reference was chosen +The argument we append is of type `&'static core::panic::Location<'static>`. A reference was chosen to avoid unnecessary copying because a pointer is a third the size of `std::mem::size_of::() == 24` at time of writing. diff --git a/src/backend/lowering-mir.md b/src/backend/lowering-mir.md index 93516c5d8..2ab15e6f8 100644 --- a/src/backend/lowering-mir.md +++ b/src/backend/lowering-mir.md @@ -38,7 +38,7 @@ LLVM's `mem2reg` for those variables. The analysis can be found in [`rustc_codegen_ssa::mir::analyze`][mirana]. [mirana]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/analyze/index.html - + Usually a single MIR basic block will map to a LLVM basic block, with very few exceptions: intrinsic or function calls and less basic MIR statements like `assert` can result in multiple basic blocks. This is a perfect lede into the From 3078d380cf478372b65ecfac11337fd9bc55cda0 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 14 Jul 2020 11:08:43 -0300 Subject: [PATCH 1126/1812] Resync config.toml and suggest better settings --- src/building/how-to-build-and-run.md | 57 ++++++++++++++++++++++------ 1 file changed, 45 insertions(+), 12 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index f9ce3f734..155c84972 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -30,23 +30,56 @@ settings (and possibly others, such as `llvm.ccache`): ```toml [llvm] -# Enables LLVM assertions, which will check that the LLVM bitcode generated -# by the compiler is internally consistent. These are particularly helpful -# if you edit `codegen`. +# Indicates whether the LLVM assertions are enabled or not assertions = true [rust] -# This will make your build more parallel; it costs a bit of runtime -# performance perhaps (less inlining) but it's worth it. +# Indicates that the build should be configured for debugging Rust. A +# `debug`-enabled compiler and standard library will be somewhat +# slower (due to e.g. checking of debug assertions) but should remain +# usable. +# +# Note: If this value is set to `true`, it will affect a number of +# configuration options below as well, if they have been left +# unconfigured in this file. +# +# Note: changes to the `debug` setting do *not* affect `optimize` +# above. In theory, a "maximally debuggable" environment would +# set `optimize` to `false` above to assist the introspection +# facilities of debuggers like lldb and gdb. To recreate such an +# environment, explicitly set `optimize` to `false` and `debug` +# to `true`. In practice, everyone leaves `optimize` set to +# `true`, because an unoptimized rustc with debugging +# enabled becomes *unusably slow* (e.g. rust-lang/rust#24840 +# reported a 25x slowdown) and bootstrapping the supposed +# "maximally debuggable" environment (notably libstd) takes +# hours to build. +# +debug = true + +# Number of codegen units to use for each compiler invocation. A value of 0 +# means "the number of cores on this machine", and 1+ is passed through to the +# compiler. codegen-units = 0 -# This enables full debuginfo and debug assertions. The line debuginfo is also -# enabled by `debuginfo-level = 1`. Full debuginfo is also enabled by -# `debuginfo-level = 2`. Debug assertions can also be enabled with -# `debug-assertions = true`. Note that `debug = true` will make your build -# slower, so you may want to try individually enabling debuginfo and assertions -# or enable only line debuginfo which is basically free. -debug = true +# Debuginfo level for most of Rust code, corresponds to the `-C debuginfo=N` option of `rustc`. +# `0` - no debug info +# `1` - line tables only - sufficient to generate backtraces that include line +# information and inlined functions, set breakpoints at source code +# locations, and step through execution in a debugger. +# `2` - full debug info with variable and type information +# Can be overridden for specific subsets of Rust code (rustc, std or tools). +# Debuginfo for tests run with compiletest is not controlled by this option +# and needs to be enabled separately with `debuginfo-level-tests`. +# +# Defaults to 2 if debug is true +debuginfo-level = 1 + +# Whether to always use incremental compilation when building rustc +incremental = true + +# Emits extra output from tests so test failures are debuggable just from logfiles. +verbose-tests = true ``` If you have already built `rustc`, then you may have to execute `rm -rf build` for subsequent From e403d5193276a3858d4ecda5bf1885136aa105fa Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Thu, 16 Jul 2020 11:13:49 +0900 Subject: [PATCH 1127/1812] Change `rustc::*` to `rustc_middle::*` (#798) --- src/diagnostics.md | 2 +- src/diagnostics/lintstore.md | 12 ++++++------ src/memory.md | 2 +- src/mir/visitor.md | 4 ++-- src/overview.md | 4 ++-- src/ty.md | 4 ++-- 6 files changed, 14 insertions(+), 14 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 80ab1306c..432ea8903 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -459,7 +459,7 @@ The possible values of [`Applicability`][appl] are: ## Lints -The compiler linting infrastructure is defined in the [`rustc::lint`][rlint] +The compiler linting infrastructure is defined in the [`rustc_middle::lint`][rlint] module. [rlint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/index.html diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index b0ae9a328..2942dac02 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -15,9 +15,9 @@ Unfortunately, a lot of the documentation we have refers to both of these as jus First, we have the lint declarations themselves: this is where the name and default lint level and other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which -boils down to a static with type `&rustc::lint::Lint`. We lint against direct declarations without -the use of the macro today (though this may change in the future, as the macro is somewhat unwieldy -to add new fields to, like all macros by example). +boils down to a static with type `&rustc_session::lint::Lint`. We lint against direct declarations +without the use of the macro today (though this may change in the future, as the macro is somewhat +unwieldy to add new fields to, like all macros by example). Lint declarations don't carry any "state" - they are merely global identifers and descriptions of lints. We assert at runtime that they are not registered twice (by lint name). @@ -55,9 +55,9 @@ internally. Note, these include both rustc-internal lints, and the traditional lints, like, for example the dead code lint. -These are primarily described in two places: `rustc::lint::builtin` and `rustc_lint::builtin`. The -first provides the definitions for the lints themselves, and the latter provides the lint pass -definitions (and implementations). +These are primarily described in two places: `rustc_session::lint::builtin` and +`rustc_lint::builtin`. The first provides the definitions for the lints themselves, +and the latter provides the lint pass definitions (and implementations). The internal lint registration happens in the [`rustc_lint::register_builtins`] function, along with the [`rustc_lint::register_internals`] function. More generally, the LintStore "constructor" diff --git a/src/memory.md b/src/memory.md index 43b3746f0..cde2f454c 100644 --- a/src/memory.md +++ b/src/memory.md @@ -82,7 +82,7 @@ of the more Rust-ic "pull" style (think the `Iterator` trait). Thread-local storage and interning are used a lot through the compiler to reduce duplication while also preventing a lot of the ergonomic issues due to many -pervasive lifetimes. The [`rustc::ty::tls`][tls] module is used to access these +pervasive lifetimes. The [`rustc_middle::ty::tls`][tls] module is used to access these thread-locals, although you should rarely need to touch it. [tls]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/tls/index.html diff --git a/src/mir/visitor.md b/src/mir/visitor.md index a0d38ca0b..c80462b95 100644 --- a/src/mir/visitor.md +++ b/src/mir/visitor.md @@ -2,7 +2,7 @@ The MIR visitor is a convenient tool for traversing the MIR and either looking for things or making changes to it. The visitor traits are -defined in [the `rustc::mir::visit` module][m-v] – there are two of +defined in [the `rustc_middle::mir::visit` module][m-v] – there are two of them, generated via a single macro: `Visitor` (which operates on a `&Mir` and gives back shared references) and `MutVisitor` (which operates on a `&mut Mir` and gives back mutable references). @@ -45,7 +45,7 @@ terminators and removes their `unwind` successors. ## Traversal -In addition the visitor, [the `rustc::mir::traversal` module][t] +In addition the visitor, [the `rustc_middle::mir::traversal` module][t] contains useful functions for walking the MIR CFG in [different standard orders][traversal] (e.g. pre-order, reverse post-order, and so forth). diff --git a/src/overview.md b/src/overview.md index 9594bab53..15946edc4 100644 --- a/src/overview.md +++ b/src/overview.md @@ -276,11 +276,11 @@ the name `'tcx`, which means that something is tied to the lifetime of the Types are really important in Rust, and they form the core of a lot of compiler analyses. The main type (in the compiler) that represents types (in the user's -program) is [`rustc::ty::Ty`][ty]. This is so important that we have a whole chapter +program) is [`rustc_middle::ty::Ty`][ty]. This is so important that we have a whole chapter on [`ty::Ty`][ty], but for now, we just want to mention that it exists and is the way `rustc` represents types! -Also note that the `rustc::ty` module defines the `TyCtxt` struct we mentioned before. +Also note that the `rustc_middle::ty` module defines the `TyCtxt` struct we mentioned before. [ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html diff --git a/src/ty.md b/src/ty.md index 2587f61ba..d1e2750c1 100644 --- a/src/ty.md +++ b/src/ty.md @@ -10,7 +10,7 @@ quite a few modules and types for `Ty` in the compiler ([Ty documentation][ty]). [ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html -The specific `Ty` we are referring to is [`rustc::ty::Ty`][ty_ty] (and not +The specific `Ty` we are referring to is [`rustc_middle::ty::Ty`][ty_ty] (and not [`rustc_hir::Ty`][hir_ty]). The distinction is important, so we will discuss it first before going into the details of `ty::Ty`. @@ -107,7 +107,7 @@ or `fn(i32) -> i32` (with type aliases fully expanded). ## `ty::Ty` implementation -[`rustc::ty::Ty`][ty_ty] is actually a type alias to [`&TyS`][tys]. +[`rustc_middle::ty::Ty`][ty_ty] is actually a type alias to [`&TyS`][tys]. This type, which is short for "Type Structure", is where the main functionality is located. You can ignore `TyS` struct in general; you will basically never access it explicitly. We always pass it by reference using the `Ty` alias. From 5411388320b779aa35c3b7632f5e04a24432ab34 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 17 Jul 2020 01:53:43 +0900 Subject: [PATCH 1128/1812] Exclude `rustaceans.org` from linkcheck --- book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book.toml b/book.toml index 1e1c54cc9..10bc2edd4 100644 --- a/book.toml +++ b/book.toml @@ -15,6 +15,6 @@ level = 0 [output.linkcheck] follow-web-links = true -exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il", "www\\.amazon\\.com" ] +exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il", "www\\.amazon\\.com", "www\\.rustaceans\\.org" ] cache-timeout = 86400 warning-policy = "error" From 467d4295973ead18c41bcd19df8dbe939e2a7fd9 Mon Sep 17 00:00:00 2001 From: Felix S Klock II Date: Fri, 17 Jul 2020 00:01:31 -0400 Subject: [PATCH 1129/1812] Update chat info to reflect decision to close down Discord `#compiler`. (#800) Co-authored-by: Yuki Okushi --- src/compiler-team.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index 3f3719f3d..33ff65af6 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -9,10 +9,13 @@ contributions to rustc and its design. ## Discussion -Currently the compiler team chats in 2 places: +Currently the compiler team chats in Zulip: -- The `t-compiler` stream on [the Zulip instance][zulip] -- The `compiler` channel on the [rust-lang discord](https://discord.gg/rust-lang) +- Team chat occurs in the `t-compiler` stream on [the Zulip instance][zulip] +- There are also a number of other associated Zulip streams, + such as [`t-compiler/help`][zulip-help], where people can ask for help + with rustc development, or [`t-compiler/meetings`][zulip-meetings], + where the team holds their weekly triage and steering meetings. ## Expert map @@ -53,6 +56,8 @@ The meeting is held over a "chat medium", currently on [zulip]. [etherpad]: https://public.etherpad-mozilla.org/p/rust-compiler-meeting [procedure]: ./bug-fix-procedure.md [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler +[zulip-help]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp +[zulip-meetings]: https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings ## Team membership From 26adefdb05582148a3b417d5249619649791621d Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 18 Jul 2020 00:00:34 +0900 Subject: [PATCH 1130/1812] Clean-up minor issues (#802) --- src/compiler-debugging.md | 4 ++-- src/contributing.md | 2 +- src/getting-started.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 0bb3cd1dd..0c40d63e4 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -176,11 +176,11 @@ So to put it together. ```bash # This puts the output of all debug calls in `librustc_middle/traits` into # standard error, which might fill your console backscroll. -$ RUSTC_LOG=rustc::traits rustc +local my-file.rs +$ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs # This puts the output of all debug calls in `librustc_middle/traits` in # `traits-log`, so you can then see it with a text editor. -$ RUSTC_LOG=rustc::traits rustc +local my-file.rs 2>traits-log +$ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs 2>traits-log # Not recommended. This will show the output of all `debug!` calls # in the Rust compiler, and there are a *lot* of them, so it will be diff --git a/src/contributing.md b/src/contributing.md index 8e0eebb70..ec94a3f9c 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -453,7 +453,7 @@ If you're looking for somewhere to start, check out the [E-easy][eeasy] tag. ## Out-of-tree Contributions There are a number of other ways to contribute to Rust that don't deal with -this repository. +rust-lang/rust. Answer questions in the _Get Help!_ channels from the [Rust Discord server][rust-discord], on [users.rust-lang.org][users], or on diff --git a/src/getting-started.md b/src/getting-started.md index 9d5c86a03..a2994a4be 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -268,7 +268,7 @@ the code: *Note*: we don't use stable `rustfmt`; we use a pinned version with a special config, so this may result in different style from normal `rustfmt` if you have format-on-save turned on. It's a good habit to run `./x.py fmt` before every -commit, as this reduces conflicts later. The pinned verson is built under +commit, as this reduces conflicts later. The pinned version is built under `build//stage0/bin/rustfmt`, so if you want, you can use it for a single file or for format-on-save in your editor, which can be faster than `./x.py fmt`. @@ -508,4 +508,4 @@ master. - [The t-compiler zulip][z] - [The compiler's documentation (rustdocs)](https://doc.rust-lang.org/nightly/nightly-rustc/) - [The Forge](https://forge.rust-lang.org/) has more documentation about various procedures. -- `#contribute`, `#compiler`, and `#rustdoc` on [Discord](https://discord.gg/rust-lang). +- `#contribute` and `#rustdoc` on [Discord](https://discord.gg/rust-lang). From 63536944b0d680c07b53811601f8499d6dec5897 Mon Sep 17 00:00:00 2001 From: Federico Ponzi Date: Sat, 18 Jul 2020 12:18:06 +0200 Subject: [PATCH 1131/1812] Fixes menu for rustdoc page (#804) --- src/SUMMARY.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 53e75fc09..b856afe74 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -64,7 +64,6 @@ - [Prologue](./part-3-intro.md) - [Command-line arguments](./cli.md) - [The Rustc Driver and Interface](./rustc-driver.md) - - [Rustdoc](./rustdoc.md) - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) - [Ex: Getting diagnostics through `rustc_interface`](./rustc-driver-getting-diagnostics.md) - [Syntax and the AST](./syntax-intro.md) From aecb593979089a2bbaf38b7faddce2c2fce4fcdb Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 22 Jul 2020 19:32:21 +0900 Subject: [PATCH 1132/1812] Fix links for cranelift (#809) --- src/backend/backend-agnostic.md | 2 +- src/backend/codegen.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md index d0984feec..07914b847 100644 --- a/src/backend/backend-agnostic.md +++ b/src/backend/backend-agnostic.md @@ -4,7 +4,7 @@ In the future, it would be nice to allow other codegen backends (e.g. [Cranelift]). To this end, `librustc_codegen_ssa` provides an abstract interface for all backends to implement. -[Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/master/cranelift +[Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/HEAD/cranelift > The following is a copy/paste of a README from the rust-lang/rust repo. > Please submit a PR if it needs updating. diff --git a/src/backend/codegen.md b/src/backend/codegen.md index d7bad9cfb..5db9b2b05 100644 --- a/src/backend/codegen.md +++ b/src/backend/codegen.md @@ -7,7 +7,7 @@ codegen itself. It's worth noting, though, that in the rust source code, many parts of the backend have `codegen` in their names (there are no hard boundaries). -[Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/master/cranelift +[Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/HEAD/cranelift > NOTE: If you are looking for hints on how to debug code generation bugs, > please see [this section of the debugging chapter][debugging]. From fd458b988ced462f4390a0a62abdb6e8993f98b5 Mon Sep 17 00:00:00 2001 From: David Wood Date: Wed, 22 Jul 2020 11:42:50 +0100 Subject: [PATCH 1133/1812] Expand on the documentation for polymorphization. (#803) This commit elaborates on the existing documentation for polymorphization now that polymorphization has almost landed in rustc. Signed-off-by: David Wood --- src/backend/monomorph.md | 82 ++++++++++++++++++++++++++++++---------- 1 file changed, 61 insertions(+), 21 deletions(-) diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index 5e5d2e0c4..47b41d4f6 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -61,33 +61,73 @@ units](../appendix/glossary.md#codegen-unit). ## Polymorphization As mentioned above, monomorphization produces fast code, but it comes at the -cost of compile time and binary size. [MIR -optimizations](../mir/optimizations.md) can help a bit with this. Another -optimization currently under development is called _polymorphization_. - -The general idea is that often we can share some code between monomorphized -copies of code. More precisely, if a MIR block is not dependent on a type -parameter, it may not need to be monomorphized into many copies. Consider the -following example: +cost of compile time and binary size. [MIR optimizations][miropt] can help a +bit with this. + +In addition to MIR optimizations, rustc attempts to determine when fewer +copies of functions are necessary and avoid making those copies - known +as "polymorphization". When a function-like item is found during +monomorphization collection, the +[`rustc_mir::monomorphize::polymorphize::unused_generic_params`][polymorph] +query is invoked, which traverses the MIR of the item to determine on which +generic parameters the item might not need duplicated. + +Currently, polymorphization only looks for unused generic parameters. These +are relatively rare in functions, but closures inherit the generic +parameters of their parent function and it is common for closures to not +use those inherited parameters. Without polymorphization, a copy of these +closures would be created for each copy of the parent function. By +creating fewer copies, less LLVM IR is generated and needs processed. + +`unused_generic_params` returns a `FiniteBitSet` where a bit is set if +the generic parameter of the corresponding index is unused. Any parameters +after the first sixty-four are considered used. + +The results of polymorphization analysis are used in the +[`Instance::polymorphize`][inst_polymorph] function to replace the +[`Instance`][inst]'s substitutions for the unused generic parameters with their +identity substitutions. + +Consider the example below: ```rust -pub fn f() { - g::(); - g::(); +fn foo() { + let x: Option = None; } -fn g() -> usize { - let n = 1; - let closure = || n; - closure() +fn main() { + foo::(); + foo::(); } ``` -In this case, we would currently collect `[f, g::, g::, -g::::{{closure}}, g::::{{closure}}]`, but notice that the two -closures would be identical -- they don't depend on the type parameter `T` of -function `g`. So we only need to emit one copy of the closure. +During monomorphization collection, `foo` will be collected with the +substitutions `[u16, u32]` and `[u64, u32]` (from its invocations in `main`). +`foo` has the identity substitutions `[A, B]` (or +`[ty::Param(0), ty::Param(1)]`). + +Polymorphization will identify `A` as being unused and it will be replaced in +the substitutions with the identity parameter before being added to the set +of collected items - thereby reducing the copies from two (`[u16, u32]` and +`[u64, u32]`) to one (`[A, u32]`). + +`unused_generic_params` will also invoked during code generation when the +symbol name for `foo` is being computed for use in the callsites of `foo` +(which have the regular substitutions present, otherwise there would be a +symbol mismatch between the caller and the function). + +As a result of polymorphization, items collected during monomorphization +cannot be assumed to be monomorphic. + +It is intended that polymorphization be extended to more advanced cases, +such as where only the size/alignment of a generic parameter are required. -For more information, see [this thread on github][polymorph]. +More details on polymorphization are available in the +[master's thesis][thesis] associated with polymorphization's initial +implementation. -[polymorph]: https://github.com/rust-lang/rust/issues/46477 +[miropt]: ../mir/optimizations.md +[polymorph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/polymorphize/fn.unused_generic_params.html +[inst]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html +[inst_polymorph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.polymorphize +[thesis]: https://davidtw.co/media/masters_dissertation.pdf From 9a078339af77b830efc73a38f81adb71a25b019c Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 25 Jul 2020 04:46:33 +0900 Subject: [PATCH 1134/1812] Turn off travis' email notifications --- .travis.yml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index a217f1cac..304abbf8f 100644 --- a/.travis.yml +++ b/.travis.yml @@ -19,8 +19,7 @@ script: - git log --oneline | head -n 10 - mdbook build notifications: - email: - on_success: never + email: false env: global: secure: YQX/AWq5KsvAFYqcCK6c1DmOZX9EMrecBM5qnc4uE2HvEBS+x0l8xatI2Nv8U9eiasZYfsqmHn0ANvxu6e4oqL15m4cVsdliCzdkrPsDapxTnwwJvMQg+yHZiEd5BPlaDQt/wYvP8QBXgQsXoAJKrfAS+BFsowBFHt/LOFOunbAQrtQZqwqrnI6+xh+2TRMckws/VcTLRqwl3pyEyfacJhbbv1V3gJh7Y17hELsgsP7+7cMXT0bK6dtf7a9vne9Hsm5fw7VeMKBn1/dJ82fyEK6HHjkjdw1/OoY35YVyNZ/9ZxP2u1ClEXzCRJQ2CvKr8Tuoh/AuoL0pwrfhOTaOuWU0QZT4QBqjTimsgBLqiJicMiSndgsXinLWvlDqrMS1XfleqCKqAQy9AJTCR1LnwR90/HRxfE5YDAL/mbc0Su4jj+l5Zv3UE8vUqFE34E/jzip17JkDT5aMkl4bgW65lqJE7SLWl7gXT7eYbPEtQZoucR1hkSsBu/4YTvcxSlD98spWZ68mWwYyjLJSQDES+GefUnHJ/RbBVl9pW+sL7jXJ+kZ/NBCtCIgrkGchudEMDEvS6rcOzwCejxqL1of0jYHGopkBXSVHOPneWIdNeKXwBZA9hp0yKh0sWwrKHrA3wYhS/kF9uO19l/RnSTXAfApYR/yJUbYliuMJYCgNeKE= From 87a11a3045b979988c1af1ba1c04c445698b1cad Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 27 Jul 2020 17:03:37 -0300 Subject: [PATCH 1135/1812] Fix MIR to LLVM IR sentence (#811) --- src/overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/overview.md b/src/overview.md index 15946edc4..eb774b113 100644 --- a/src/overview.md +++ b/src/overview.md @@ -87,10 +87,10 @@ we'll talk about that later. - We then begin what is vaguely called _code generation_ or _codegen_. - The [code generation stage (codegen)][codegen] is when higher level representations of source are turned into an executable binary. `rustc` - uses LLVM for code generation. The first step is the MIR is then - converted to LLVM Intermediate Representation (LLVM IR). This is where - the MIR is actually monomorphized, according to the list we created in - the previous step. + uses LLVM for code generation. The first step is to convert the MIR + to LLVM Intermediate Representation (LLVM IR). This is where the MIR + is actually monomorphized, according to the list we created in the + previous step. - The LLVM IR is passed to LLVM, which does a lot more optimizations on it. It then emits machine code. It is basically assembly code with additional low-level types and annotations added. (e.g. an ELF object or wasm). From e20ac5d64bf7ebb94b2d384b5b70376890f6fd5b Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 29 Jul 2020 02:06:07 +0900 Subject: [PATCH 1136/1812] Add RISC-V notification group instructions (#814) * Clean-up notification groups instructions * Add RISC-V notification group instructions * Re-order summary of notification groups * Add a list of the notification groups * Apply review suggestion --- src/SUMMARY.md | 5 +++-- src/notification-groups/about.md | 12 +++++++++++- src/notification-groups/arm.md | 7 +++---- src/notification-groups/risc-v.md | 22 ++++++++++++++++++++++ src/notification-groups/windows.md | 7 ++++--- 5 files changed, 43 insertions(+), 10 deletions(-) create mode 100644 src/notification-groups/risc-v.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b856afe74..db2155cb8 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -37,10 +37,11 @@ - [Stabilizing Features](./stabilization_guide.md) - [Coding conventions](./conventions.md) - [Notification groups](notification-groups/about.md) - - ["Cleanup Crew"](notification-groups/cleanup-crew.md) + - [ARM](notification-groups/arm.md) + - [Cleanup Crew](notification-groups/cleanup-crew.md) - [LLVM](notification-groups/llvm.md) + - [RISC-V](notification-groups/risc-v.md) - [Windows](notification-groups/windows.md) - - [ARM](notification-groups/arm.md) - [Licenses](./licenses.md) # High-level Compiler Architecture diff --git a/src/notification-groups/about.md b/src/notification-groups/about.md index 02ceb9271..260c59c24 100644 --- a/src/notification-groups/about.md +++ b/src/notification-groups/about.md @@ -16,6 +16,15 @@ search for existing issues that haven't been claimed yet. [claim the issue]: https://github.com/rust-lang/triagebot/wiki/Assignment +## List of notification groups + +Here's the list of the notification groups: +- [ARM](./arm.md) +- [Cleanup Crew](./cleanup-crew.md) +- [LLVM](./llvm.md) +- [RISC-V](./risc-v.md) +- [Windows](./windows.md) + ## What issues are a good fit for notification groups? Notification groups tend to get pinged on **isolated** bugs, @@ -48,10 +57,11 @@ cargo run add-person $your_user_name Example PRs: +* [Example of adding yourself to the ARM group.](https://github.com/rust-lang/team/pull/358) * [Example of adding yourself to the Cleanup Crew.](https://github.com/rust-lang/team/pull/221) * [Example of adding yourself to the LLVM group.](https://github.com/rust-lang/team/pull/140) +* [Example of adding yourself to the RISC-V group.](https://github.com/rust-lang/team/pull/394) * [Example of adding yourself to the Windows group.](https://github.com/rust-lang/team/pull/348) -* [Example of adding yourself to the ARM group.](https://github.com/rust-lang/team/pull/358) ## Tagging an issue for a notification group diff --git a/src/notification-groups/arm.md b/src/notification-groups/arm.md index 0b0d21776..4514f8ef3 100644 --- a/src/notification-groups/arm.md +++ b/src/notification-groups/arm.md @@ -8,16 +8,15 @@ This list will be used to ask for help both in diagnosing and testing ARM-related issues as well as suggestions on how to resolve interesting questions regarding our ARM support. -The group also has an associated Zulip stream (`#t-compiler/arm`) +The group also has an associated Zulip stream ([`#t-compiler/arm`]) where people can go to pose questions and discuss ARM-specific topics. So, if you are interested in participating, please sign up for the -ARM group! To do so, you open a PR against the [rust-lang/team] +ARM group! To do so, open a PR against the [rust-lang/team] repository. Just [follow this example][eg], but change the username to your own! +[`#t-compiler/arm`]: https://rust-lang.zulipchat.com/#narrow/stream/242906-t-compiler.2Farm [rust-lang/team]: https://github.com/rust-lang/team [eg]: https://github.com/rust-lang/team/pull/358 -[#72569]: https://github.com/rust-lang/rust/pull/72569 -[#29520]: https://github.com/rust-lang/rust/pull/29520 diff --git a/src/notification-groups/risc-v.md b/src/notification-groups/risc-v.md new file mode 100644 index 000000000..15ce1cfc6 --- /dev/null +++ b/src/notification-groups/risc-v.md @@ -0,0 +1,22 @@ +# RISC-V notification group + +**Github Label:** [O-riscv] + +[O-riscv]: https://github.com/rust-lang/rust/labels/O-riscv + +This list will be used to ask for help both in diagnosing and testing +RISC-V-related issues as well as suggestions on how to resolve +interesting questions regarding our RISC-V support. + +The group also has an associated Zulip stream ([`#t-compiler/risc-v`]) +where people can go to pose questions and discuss RISC-V-specific +topics. + +So, if you are interested in participating, please sign up for the +RISC-V group! To do so, open a PR against the [rust-lang/team] +repository. Just [follow this example][eg], but change the username to +your own! + +[`#t-compiler/risc-v`]: https://rust-lang.zulipchat.com/#narrow/stream/250483-t-compiler.2Frisc-v +[rust-lang/team]: https://github.com/rust-lang/team +[eg]: https://github.com/rust-lang/team/pull/394 diff --git a/src/notification-groups/windows.md b/src/notification-groups/windows.md index 328ee6480..0483babd8 100644 --- a/src/notification-groups/windows.md +++ b/src/notification-groups/windows.md @@ -8,7 +8,7 @@ This list will be used to ask for help both in diagnosing and testing Windows-related issues as well as suggestions on how to resolve interesting questions regarding our Windows support. -The group also has an associated Zulip stream (`#t-compiler/windows`) +The group also has an associated Zulip stream ([`#t-compiler/windows`]) where people can go to pose questions and discuss Windows-specific topics. @@ -18,13 +18,14 @@ the group for advice in determining the best course of action: * Which versions of MinGW should we support? * Should we remove the legacy InnoSetup GUI installer? [#72569] -* What names should we use for static libraries on Windows? [#29520] +* What names should we use for static libraries on Windows? [#29520] So, if you are interested in participating, please sign up for the -Windows group! To do so, you open a PR against the [rust-lang/team] +Windows group! To do so, open a PR against the [rust-lang/team] repository. Just [follow this example][eg], but change the username to your own! +[`#t-compiler/windows`]: https://rust-lang.zulipchat.com/#streams/242869/t-compiler.2Fwindows [rust-lang/team]: https://github.com/rust-lang/team [eg]: https://github.com/rust-lang/team/pull/348/ [#72569]: https://github.com/rust-lang/rust/pull/72569 From eeca3757b8be614be23a253cc4118b22cd36dc85 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 28 Jul 2020 15:20:00 -0400 Subject: [PATCH 1137/1812] Update docs to match the new x.py defaults (#813) --- README.md | 2 +- src/building/compiler-documenting.md | 5 +++- src/building/how-to-build-and-run.md | 44 ++++++++-------------------- src/building/suggested.md | 8 ++--- src/contributing.md | 10 +++---- src/getting-started.md | 42 +++++++++++++------------- src/queries/profiling.md | 2 +- src/rustdoc.md | 4 +-- src/tests/running.md | 35 +++++++++++----------- 9 files changed, 66 insertions(+), 86 deletions(-) diff --git a/README.md b/README.md index 8f7db233e..345b38589 100644 --- a/README.md +++ b/README.md @@ -132,7 +132,7 @@ git submodule update --remote src/doc/rustc-dev-guide git add -u git commit -m "Update rustc-dev-guide" # Note that you can use -i, which is short for --incremental, in the following command -./x.py test --incremental --stage 1 src/doc/rustc-dev-guide # This is optional and should succeed anyway +./x.py test --incremental src/doc/rustc-dev-guide # This is optional and should succeed anyway # Open a PR in rust-lang/rust ``` diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md index 68c9fd227..111f6858d 100644 --- a/src/building/compiler-documenting.md +++ b/src/building/compiler-documenting.md @@ -9,11 +9,14 @@ since documentation is more about the content. ## Document everything +This uses the beta rustdoc, which usually but not always has the same output +as stage 1 rustdoc. + ```bash ./x.py doc ``` -## If you want to avoid the whole Stage 2 build +## If you want to be sure that the links behave the same as on CI ```bash ./x.py doc --stage 1 diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 155c84972..f4d783f5d 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -62,19 +62,6 @@ debug = true # compiler. codegen-units = 0 -# Debuginfo level for most of Rust code, corresponds to the `-C debuginfo=N` option of `rustc`. -# `0` - no debug info -# `1` - line tables only - sufficient to generate backtraces that include line -# information and inlined functions, set breakpoints at source code -# locations, and step through execution in a debugger. -# `2` - full debug info with variable and type information -# Can be overridden for specific subsets of Rust code (rustc, std or tools). -# Debuginfo for tests run with compiletest is not controlled by this option -# and needs to be enabled separately with `debuginfo-level-tests`. -# -# Defaults to 2 if debug is true -debuginfo-level = 1 - # Whether to always use incremental compilation when building rustc incremental = true @@ -147,10 +134,9 @@ To read more about the bootstrap process, [read this chapter][bootstrap]. ## Building the Compiler -To build a compiler, run `./x.py build`. This will do the whole bootstrapping -process described above, producing a usable compiler toolchain from the source -code you have checked out. This takes a long time, so it is not usually what -you want to actually run (more on this later). +To build a compiler, run `./x.py build`. This will build up to the stage1 compiler, +including `rustdoc`, producing a usable compiler toolchain from the source +code you have checked out. Note that building will require a relatively large amount of storage space. You may want to have upwards of 10 or 15 gigabytes available to build the compiler. @@ -190,7 +176,7 @@ Once you've created a config.toml, you are now ready to run probably the best "go to" command for building a local rust: ```bash -./x.py build -i --stage 1 src/libstd +./x.py build -i src/libstd ``` This may *look* like it only builds `libstd`, but that is not the case. @@ -220,8 +206,8 @@ there is a (hacky) workaround. See [the section on "recommended workflows"](./suggested.md) below. Note that this whole command just gives you a subset of the full `rustc` -build. The **full** `rustc` build (what you get if you just say `./x.py -build`) has quite a few more steps: +build. The **full** `rustc` build (what you get if you say `./x.py build +--stage 2 src/rustc`) has quite a few more steps: - Build `librustc` and `rustc` with the stage1 compiler. - The resulting compiler here is called the "stage2" compiler. @@ -244,12 +230,6 @@ Build the libcore and libproc_macro library only ./x.py build src/libcore src/libproc_macro ``` -Build only libcore up to Stage 1 - -```bash -./x.py build src/libcore --stage 1 -``` - Sometimes you might just want to test if the part you’re working on can compile. Using these commands you can test that it compiles before doing a bigger build to make sure it works with the compiler. As shown before @@ -296,16 +276,16 @@ Here are a few other useful `x.py` commands. We'll cover some of them in detail in other sections: - Building things: - - `./x.py build --stage 1` – builds everything using the stage 1 compiler, + - `./x.py build` – builds everything using the stage 1 compiler, not just up to `libstd` - - `./x.py build` – builds the stage2 compiler + - `./x.py build --stage 2` – builds the stage2 compiler - Running tests (see the [section on running tests](../tests/running.html) for more details): - - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from `libstd` - - `./x.py test --stage 1 src/test/ui` – runs the `ui` test suite - - `./x.py test --stage 1 src/test/ui/const-generics` - runs all the tests in + - `./x.py test src/libstd` – runs the `#[test]` tests from `libstd` + - `./x.py test src/test/ui` – runs the `ui` test suite + - `./x.py test src/test/ui/const-generics` - runs all the tests in the `const-generics/` subdirectory of the `ui` test suite - - `./x.py test --stage 1 src/test/ui/const-generics/const-types.rs` - runs + - `./x.py test src/test/ui/const-generics/const-types.rs` - runs the single test `const-types.rs` from the `ui` test suite ### Cleaning out build directories diff --git a/src/building/suggested.md b/src/building/suggested.md index 102586721..fd2c00baa 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -58,13 +58,13 @@ don't work (but that is easily detected and fixed). The sequence of commands you want is as follows: -- Initial build: `./x.py build -i --stage 1 src/libstd` +- Initial build: `./x.py build -i src/libstd` - As [documented above](#command), this will build a functional stage1 compiler as part of running all stage0 commands (which include building a `libstd` compatible with the stage1 compiler) as well as the first few steps of the "stage 1 actions" up to "stage1 (sysroot stage1) builds libstd". -- Subsequent builds: `./x.py build -i --stage 1 src/libstd --keep-stage 1` +- Subsequent builds: `./x.py build -i src/libstd --keep-stage 1` - Note that we added the `--keep-stage 1` flag here As mentioned, the effect of `--keep-stage 1` is that we just *assume* that the @@ -84,8 +84,8 @@ rebuild. That ought to fix the problem. You can also use `--keep-stage 1` when running tests. Something like this: -- Initial test run: `./x.py test -i --stage 1 src/test/ui` -- Subsequent test run: `./x.py test -i --stage 1 src/test/ui --keep-stage 1` +- Initial test run: `./x.py test -i src/test/ui` +- Subsequent test run: `./x.py test -i src/test/ui --keep-stage 1` ## Fine-tuning optimizations diff --git a/src/contributing.md b/src/contributing.md index ec94a3f9c..180197ddc 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -361,12 +361,12 @@ You can find documentation style guidelines in [RFC 1574][rfc1574]. [rfc1574]: https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text -In many cases, you don't need a full `./x.py doc`, which will build the entire -stage 2 compiler and compile the various books published on +In many cases, you don't need a full `./x.py doc --stage 2`, which will build +the entire stage 2 compiler and compile the various books published on [doc.rust-lang.org][docs]. When updating documentation for the standard library, -first try `./x.py doc --stage 0 src/libstd`. If that fails, or if you need to -see the output from the latest version of `rustdoc`, use `--stage 1` instead of -`--stage 0`. Results should appear in `build/$TARGET/crate-docs`. +first try `./x.py doc src/libstd`. If that fails, or if you need to +see the output from the latest version of `rustdoc`, add `--stage 1`. +Results should appear in `build/$TARGET/crate-docs`. [docs]: https://doc.rust-lang.org diff --git a/src/getting-started.md b/src/getting-started.md index a2994a4be..9d5db4b05 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -175,19 +175,19 @@ should still read the rest of the section: | Command | When to use it | | --- | --- | | `x.py check` | Quick check to see if things compile; rust-analyzer can run this automatically for you | -| `x.py build --stage 0 src/libstd` | Build only the standard library, without building the compiler | -| `x.py build --stage 1 src/libstd` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough | -| `x.py build --stage 1 --keep-stage 1 src/libstd` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | -| `x.py test --stage 1 [--keep-stage 1]` | Run the test suite using the stage1 compiler | -| `x.py test --stage 1 --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. | -| `x.py build` | Do a full 2-stage build. You almost never want to do this. | -| `x.py test` | Do a full 2-stage build and run all tests. You almost never want to do this. | +| `x.py build --stage 0 [src/libstd]` | Build only the standard library, without building the compiler | +| `x.py build src/libstd` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough | +| `x.py build --keep-stage 1 src/libstd` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | +| `x.py test [--keep-stage 1]` | Run the test suite using the stage1 compiler | +| `x.py test --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. | +| `x.py build --stage 2 src/rustc` | Do a full 2-stage build. You almost never want to do this. | +| `x.py test --stage 2` | Do a full 2-stage build and run all tests. You almost never want to do this. | To do a full 2-stage build of the whole compiler, you should run this (after updating `config.toml` as mentioned above): ```sh -./x.py build +./x.py build --stage 2 src/rustc ``` In the process, this will also necessarily build the standard libraries, and it @@ -203,10 +203,10 @@ For most contributions, you only need to build stage 1, which saves a lot of tim ```sh # Build the compiler (stage 1) -./x.py build --stage 1 src/libstd +./x.py build src/libstd # Subsequent builds -./x.py build --stage 1 --keep-stage 1 src/libstd +./x.py build --keep-stage 1 src/libstd ``` This will take a while, especially the first time. Be wary of accidentally @@ -228,17 +228,17 @@ different test suites [in this chapter][testing]. ```sh # First build -./x.py test --stage 1 src/test/ui +./x.py test src/test/ui # Subsequent builds -./x.py test --stage 1 src/test/ui --keep-stage 1 +./x.py test src/test/ui --keep-stage 1 ``` If your changes impact test output, you can use `--bless` to automatically update the `.stderr` files of the affected tests: ```sh -./x.py test --stage 1 src/test/ui --keep-stage 1 --bless +./x.py test src/test/ui --keep-stage 1 --bless ``` While working on the compiler, it can be helpful to see if the code just @@ -290,7 +290,7 @@ planning to use a recently added nightly feature. Instead, you can just build stage 0, which uses the current beta compiler. ```sh -./x.py build --stage 0 src/libstd +./x.py build --stage 0 ``` ```sh @@ -303,17 +303,15 @@ stage 0, which uses the current beta compiler. `rustdoc` uses `rustc` internals (and, of course, the standard library), so you will have to build the compiler and `std` once before you can build `rustdoc`. -As before, you can use `./x.py build` to do this. - -However, in practice, stage 1 should be sufficient. The first time you build, +As before, you can use `./x.py build` to do this. The first time you build, the stage-1 compiler will also be built. ```sh # First build -./x.py build --stage 1 src/tools/rustdoc +./x.py build # Subsequent builds -./x.py build --stage 1 --keep-stage 1 src/tools/rustdoc +./x.py build --keep-stage 1 ``` As with the compiler, you can do a fast check build: @@ -326,13 +324,13 @@ Rustdoc has two types of tests: content tests and UI tests. ```sh # Content tests -./x.py test --stage 1 src/test/rustdoc +./x.py test src/test/rustdoc # UI tests -./x.py test --stage 1 src/test/rustdoc-ui +./x.py test src/test/rustdoc-ui # Both at once -./x.py test --stage 1 src/test/rustdoc src/test/rustdoc-ui +./x.py test src/test/rustdoc src/test/rustdoc-ui ``` ### Contributing code to other Rust projects diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 958dd3337..33d001f39 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -20,7 +20,7 @@ address [issue 42678](https://github.com/rust-lang/rust/issues/42678). Compile the compiler, up to at least stage 1: ``` -python x.py --stage 1 +x.py build src/libstd ``` ### 2. Run `rustc`, with flags diff --git a/src/rustdoc.md b/src/rustdoc.md index 6ac944697..1a3cf7019 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -30,7 +30,7 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) ## Cheat sheet -* Use `./x.py build --stage 1 src/libstd src/tools/rustdoc` to make a usable +* Use `./x.py build` to make a usable rustdoc you can run on other projects. * Add `src/libtest` to be able to use `rustdoc --test`. * If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1` @@ -41,7 +41,7 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * The completed docs will be available in `build/$TARGET/doc/std`, though the bundle is meant to be used as though you would copy out the `doc` folder to a web server, since that's where the CSS/JS and landing page are. -* Use `x.py test --stage 1 src/test/rustdoc*` to run the tests using a stage1 rustdoc. +* Use `x.py test src/test/rustdoc*` to run the tests using a stage1 rustdoc. * See [rustdoc internals] for more information about tests. * Most of the HTML printing code is in `html/format.rs` and `html/render.rs`. It's in a bunch of `fmt::Display` implementations and supplementary diff --git a/src/tests/running.md b/src/tests/running.md index a6303c1a6..44561f6f2 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -7,7 +7,7 @@ you will almost never want to use! – is as follows: ./x.py test ``` -This will build the full stage 2 compiler and then run the whole test +This will build the stage 1 compiler and then run the whole test suite. You probably don't want to do this very often, because it takes a very long time, and anyway bors / travis will do it for you. (Often, I will run this command in the background after opening a PR that I @@ -29,35 +29,34 @@ If you are building gdb from source, you will need to configure with ## Running a subset of the test suites When working on a specific PR, you will usually want to run a smaller -set of tests, and with a stage 1 build. For example, a good "smoke -test" that can be used after modifying rustc to see if things are -generally working correctly would be the following: +set of tests. For example, a good "smoke test" that can be used after +modifying rustc to see if things are generally working correctly would be the +following: ```bash -./x.py test --stage 1 src/test/{ui,compile-fail} +./x.py test src/test/{ui,compile-fail} ``` -This will run the `ui` and `compile-fail` test suites, -and only with the stage 1 build. Of course, the choice of test suites -is somewhat arbitrary, and may not suit the task you are doing. For -example, if you are hacking on debuginfo, you may be better off with -the debuginfo test suite: +This will run the `ui` and `compile-fail` test suites. Of course, the choice +of test suites is somewhat arbitrary, and may not suit the task you are +doing. For example, if you are hacking on debuginfo, you may be better off +with the debuginfo test suite: ```bash -./x.py test --stage 1 src/test/debuginfo +./x.py test src/test/debuginfo ``` If you only need to test a specific subdirectory of tests for any given test suite, you can pass that directory to `x.py test`: ```bash -./x.py test --stage 1 src/test/ui/const-generics +./x.py test src/test/ui/const-generics ``` Likewise, you can test a single file by passing its path: ```bash -./x.py test --stage 1 src/test/ui/const-generics/const-test.rs +./x.py test src/test/ui/const-generics/const-test.rs ``` ### Run only the tidy script @@ -81,7 +80,7 @@ Likewise, you can test a single file by passing its path: ### Run tests on the standard library using a stage 1 compiler ```bash -> ./x.py test src/libstd --stage 1 +> ./x.py test src/libstd ``` By listing which test suites you want to run you avoid having to run @@ -99,7 +98,7 @@ you may pass the full file path to achieve this, or alternatively one may invoke `x.py` with the `--test-args` option: ```bash -./x.py test --stage 1 src/test/ui --test-args issue-1234 +./x.py test src/test/ui --test-args issue-1234 ``` Under the hood, the test runner invokes the standard rust test runner @@ -114,7 +113,7 @@ making a new test, you can pass `--bless` to the test subcommand. E.g. if some tests in `src/test/ui` are failing, you can run ```text -./x.py test --stage 1 src/test/ui --bless +./x.py test src/test/ui --bless ``` to automatically adjust the `.stderr`, `.stdout` or `.fixed` files of @@ -130,7 +129,7 @@ exists in the test file. For example, you can run all the tests in `src/test/ui` as `check-pass`: ```bash -./x.py test --stage 1 src/test/ui --pass check +./x.py test src/test/ui --pass check ``` By passing `--pass $mode`, you can reduce the testing time. For each @@ -144,7 +143,7 @@ You can further enable the `--incremental` flag to save additional time in subsequent rebuilds: ```bash -./x.py test --stage 1 src/test/ui --incremental --test-args issue-1234 +./x.py test src/test/ui --incremental --test-args issue-1234 ``` If you don't want to include the flag with every command, you can From 5bde3efd900b622bd9cafb60c925b17de6de26e0 Mon Sep 17 00:00:00 2001 From: Jake Goulding Date: Tue, 28 Jul 2020 15:41:28 -0400 Subject: [PATCH 1138/1812] Add basic steps for a new target (#805) Co-authored-by: Yuki Okushi --- src/SUMMARY.md | 1 + src/building/new-target.md | 101 +++++++++++++++++++++++++++++++++++++ 2 files changed, 102 insertions(+) create mode 100644 src/building/new-target.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index db2155cb8..391a32b9e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -16,6 +16,7 @@ - [Documenting Compiler](./building/compiler-documenting.md) - [Rustdoc](./rustdoc.md) - [ctags](./building/ctags.md) + - [Adding a new target](./building/new-target.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) - [Adding new tests](./tests/adding.md) diff --git a/src/building/new-target.md b/src/building/new-target.md new file mode 100644 index 000000000..0bd200908 --- /dev/null +++ b/src/building/new-target.md @@ -0,0 +1,101 @@ +# Adding a new target + +These are a set of steps to add support for a new target. There are +numerous end states and paths to get there, so not all sections may be +relevant to your desired goal. + +## Specifying a new LLVM + +For very new targets, you may need to use a different fork of LLVM +than what is currently shipped with Rust. In that case, navigate to +the `src/llvm_project` git submodule (you might need to run `x.py +check` at least once so the submodule is updated), check out the +appropriate commit for your fork, then commit that new submodule +reference in the main Rust repository. + +An example would be: + +``` +cd src/llvm_project +git remote add my-target-llvm some-llvm-repository +git checkout my-target-llvm/my-branch +cd .. +git add llvm_target +git commit -m 'Use my custom LLVM' +``` + +If you have a local LLVM checkout that is already built, you *may* be +able to configure Rust to treat your build as the [system +LLVM][sysllvm] to avoid redundant builds. + +[sysllvm]: ./suggested.md#building-with-system-llvm + +## Creating a target specification + +You should start with a target JSON file. You can see the specification +for an existing target using `--print target-spec-json`: + +``` +rustc -Z unstable-options --target=wasm32-unknown-unknown --print target-spec-json +``` + +Save that JSON to a file and modify it as appropriate for your target. + +### Adding a target specification + +Once you have filled out a JSON specification and been able to compile +somewhat successfully, you can copy the specification into the +compiler itself. + +You will need to add a line to the big table inside of the +`supported_targets` macro in the `librustc_target::spec` module. You +will then add a corresponding file for your new target containing a +`target` function. + +Look for existing targets to use as examples + +## Patching crates + +You may need to make changes to crates that the compiler depends on, +such as [`libc`][] or [`cc`][]. If so, you can use Cargo's +[`[patch]`][patch] ability. For example, if you want to use an +unreleased version of `libc`, you can add it to the top-level +`Cargo.toml` file: + +```diff +diff --git a/Cargo.toml b/Cargo.toml +index be15e50e2bc..4fb1248ba99 100644 +--- a/Cargo.toml ++++ b/Cargo.toml +@@ -66,10 +66,11 @@ cargo = { path = "src/tools/cargo" } + [patch.crates-io] + # Similar to Cargo above we want the RLS to use a vendored version of `rustfmt` + # that we're shipping as well (to ensure that the rustfmt in RLS and the + # `rustfmt` executable are the same exact version). + rustfmt-nightly = { path = "src/tools/rustfmt" } ++libc = { git = "https://github.com/rust-lang/libc", rev = "0bf7ce340699dcbacabdf5f16a242d2219a49ee0" } + + # See comments in `src/tools/rustc-workspace-hack/README.md` for what's going on + # here + rustc-workspace-hack = { path = 'src/tools/rustc-workspace-hack' } +``` + +After this, run `cargo update -p libc` to update the lockfiles. + +[`libc`]: https://crates.io/crates/libc +[`cc`]: https://crates.io/crates/cc +[patch]: https://doc.rust-lang.org/stable/cargo/reference/overriding-dependencies.html#the-patch-section + +## Cross-compiling + +Once you have a target specification in JSON and in the code, you can +cross-compile `rustc`: + +``` +DESTDIR=/path/to/install/in \ +./x.py install -i --stage 1 --host aarch64-apple-darwin.json --target aarch64-apple-darwin \ +src/librustc src/libstd +``` + +If your target specification is already available in the bootstrap +compiler, you can use it instead of the JSON file for both arguments. From f8012dbf426dfbeda7687ed4049ff8530323b814 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 30 Jul 2020 22:47:22 +0900 Subject: [PATCH 1139/1812] Rename `src/libstd` to `library/std` etc. (#815) --- src/backend/implicit-caller-location.md | 2 +- src/building/bootstrapping.md | 22 ++++++------- src/building/compiler-documenting.md | 2 +- src/building/how-to-build-and-run.md | 28 ++++++++-------- src/building/new-target.md | 2 +- src/building/suggested.md | 8 ++--- src/contributing.md | 2 +- src/getting-started.md | 14 ++++---- src/panic-implementation.md | 43 +++++++++++++------------ src/profile-guided-optimization.md | 4 +-- src/queries/profiling.md | 2 +- src/rustdoc-internals.md | 2 +- src/rustdoc.md | 4 +-- src/stabilization_guide.md | 2 +- src/tests/adding.md | 4 +-- src/tests/intro.md | 6 ++-- src/tests/running.md | 6 ++-- src/walkthrough.md | 2 +- 18 files changed, 78 insertions(+), 77 deletions(-) diff --git a/src/backend/implicit-caller-location.md b/src/backend/implicit-caller-location.md index e0a12415e..a621b57b1 100644 --- a/src/backend/implicit-caller-location.md +++ b/src/backend/implicit-caller-location.md @@ -17,7 +17,7 @@ fn main() { } ``` -Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore: +Prior to Rust 1.42, panics like this `unwrap()` printed a location in core: ``` $ rustc +1.41.0 example.rs; example.exe diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index cce9fac49..a2eeb6029 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -25,7 +25,7 @@ The `stage2` compiler is the one distributed with `rustup` and all other install methods. However, it takes a very long time to build because one must first build the new compiler with an older compiler and then use that to build the new compiler with itself. For development, you usually only want -the `stage1` compiler: `x.py build --stage 1 src/libstd`. +the `stage1` compiler: `x.py build --stage 1 library/std`. ## Complications of bootstrapping @@ -128,7 +128,7 @@ The following tables indicate the outputs of various stage actions: |-----------------------------------------------------------|----------------------------------------------| | `beta` extracted | `build/HOST/stage0` | | `stage0` builds `bootstrap` | `build/bootstrap` | -| `stage0` builds `libtest`/`libstd` | `build/HOST/stage0-std/TARGET` | +| `stage0` builds `test`/`std` | `build/HOST/stage0-std/TARGET` | | copy `stage0-std` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | | `stage0` builds `rustc` with `stage0-sysroot` | `build/HOST/stage0-rustc/HOST` | | copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | @@ -143,7 +143,7 @@ The following tables indicate the outputs of various stage actions: | copy (uplift) `stage0-rustc` executable to `stage1` | `build/HOST/stage1/bin` | | copy (uplift) `stage0-codegen` to `stage1` | `build/HOST/stage1/lib` | | copy (uplift) `stage0-sysroot` to `stage1` | `build/HOST/stage1/lib` | -| `stage1` builds `libtest`/`libstd` | `build/HOST/stage1-std/TARGET` | +| `stage1` builds `test`/`std` | `build/HOST/stage1-std/TARGET` | | copy `stage1-std` (HOST only) | `build/HOST/stage1/lib/rustlib/HOST` | | `stage1` builds `rustc` | `build/HOST/stage1-rustc/HOST` | | copy `stage1-rustc` (except executable) | `build/HOST/stage1/lib/rustlib/HOST` | @@ -155,7 +155,7 @@ The following tables indicate the outputs of various stage actions: |--------------------------------------------------------|-----------------------------------------------------------------| | copy (uplift) `stage1-rustc` executable | `build/HOST/stage2/bin` | | copy (uplift) `stage1-sysroot` | `build/HOST/stage2/lib and build/HOST/stage2/lib/rustlib/HOST` | -| `stage2` builds `libtest`/`libstd` (not HOST targets) | `build/HOST/stage2-std/TARGET` | +| `stage2` builds `test`/`std` (not HOST targets) | `build/HOST/stage2-std/TARGET` | | copy `stage2-std` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | | `stage2` builds `rustdoc` | `build/HOST/stage2-tools/HOST` | | copy `rustdoc` | `build/HOST/stage2/bin` | @@ -196,21 +196,21 @@ later copied into stage2 as well (both the compiler's `libdir` and the This `std` is pretty much necessary for any useful work with the compiler. Specifically, it's used as the `std` for programs compiled by the newly compiled compiler (so when you compile `fn main() { }` it is linked to the last `std` -compiled with `x.py build --stage 1 src/libstd`). +compiled with `x.py build --stage 1 library/std`). The `rustc` generated by the stage0 compiler is linked to the freshly-built -`libstd`, which means that for the most part only `std` needs to be cfg-gated, +`std`, which means that for the most part only `std` needs to be cfg-gated, so that `rustc` can use featured added to std immediately after their addition, -without need for them to get into the downloaded beta. The `libstd` built by the +without need for them to get into the downloaded beta. The `std` built by the `stage1/bin/rustc` compiler, also known as "stage1 std artifacts", is not necessarily ABI-compatible with that compiler. That is, the `rustc` binary most likely could not use this `std` itself. It is however ABI-compatible with any programs that the `stage1/bin/rustc` binary builds (including itself), so in that sense they're paired. -This is also where `--keep-stage 1 src/libstd` comes into play. Since most +This is also where `--keep-stage 1 library/std` comes into play. Since most changes to the compiler don't actually change the ABI, once you've produced a -`libstd` in stage 1, you can probably just reuse it with a different compiler. +`std` in stage 1, you can probably just reuse it with a different compiler. If the ABI hasn't changed, you're good to go, no need to spend the time recompiling that `std`. `--keep-stage` simply assumes the previous compile is fine and copies those @@ -254,12 +254,12 @@ variables that are used. If you are trying to run an intermediate version of manually. Otherwise, you get an error like the following: ```text -thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', src/libcore/result.rs:1165:5 +thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', library/core/src/result.rs:1165:5 ``` If `./stageN/bin/rustc` gives an error about environment variables, that usually means something is quite wrong -- or you're trying to compile e.g. -`librustc` or `libstd` or something that depends on environment variables. In +`librustc` or `std` or something that depends on environment variables. In the unlikely case that you actually need to invoke rustc in such a situation, you can find the environment variable values by adding the following flag to your `x.py` command: `--on-fail=print-env`. diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md index 111f6858d..af3cd7ce2 100644 --- a/src/building/compiler-documenting.md +++ b/src/building/compiler-documenting.md @@ -30,7 +30,7 @@ and then it documents the files. ```bash ./x.py doc src/doc/book ./x.py doc src/doc/nomicon -./x.py doc src/doc/book src/libstd +./x.py doc src/doc/book library/std ``` Much like individual tests or building certain components you can build only diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index f4d783f5d..29d10edd0 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -52,7 +52,7 @@ assertions = true # `true`, because an unoptimized rustc with debugging # enabled becomes *unusably slow* (e.g. rust-lang/rust#24840 # reported a 25x slowdown) and bootstrapping the supposed -# "maximally debuggable" environment (notably libstd) takes +# "maximally debuggable" environment (notably std) takes # hours to build. # debug = true @@ -92,7 +92,7 @@ One thing to keep in mind is that `rustc` is a _bootstrapping_ compiler. That is, since `rustc` is written in Rust, we need to use an older version of the compiler to compile the newer version. In particular, the newer version of the compiler and some of the artifacts needed -to build it, such as `libstd` and other tooling, may use some unstable features +to build it, such as `std` and other tooling, may use some unstable features internally, requiring a specific version which understands these unstable features. @@ -176,16 +176,16 @@ Once you've created a config.toml, you are now ready to run probably the best "go to" command for building a local rust: ```bash -./x.py build -i src/libstd +./x.py build -i library/std ``` -This may *look* like it only builds `libstd`, but that is not the case. +This may *look* like it only builds `std`, but that is not the case. What this command does is the following: -- Build `libstd` using the stage0 compiler (using incremental) +- Build `std` using the stage0 compiler (using incremental) - Build `librustc` using the stage0 compiler (using incremental) - This produces the stage1 compiler -- Build `libstd` using the stage1 compiler (cannot use incremental) +- Build `std` using the stage1 compiler (cannot use incremental) This final product (stage1 compiler + libs built using that compiler) is what you need to build other rust programs (unless you use `#![no_std]` or @@ -201,7 +201,7 @@ stage1 libraries. This is because incremental only works when you run the *same compiler* twice in a row. In this case, we are building a *new stage1 compiler* every time. Therefore, the old incremental results may not apply. **As a result, you will probably find that -building the stage1 `libstd` is a bottleneck for you** -- but fear not, +building the stage1 `std` is a bottleneck for you** -- but fear not, there is a (hacky) workaround. See [the section on "recommended workflows"](./suggested.md) below. @@ -211,23 +211,23 @@ build. The **full** `rustc` build (what you get if you say `./x.py build - Build `librustc` and `rustc` with the stage1 compiler. - The resulting compiler here is called the "stage2" compiler. -- Build `libstd` with stage2 compiler. +- Build `std` with stage2 compiler. - Build `librustdoc` and a bunch of other things with the stage2 compiler. ## Build specific components -Build only the libcore library +- Build only the core library ```bash -./x.py build src/libcore +./x.py build library/core ``` -Build the libcore and libproc_macro library only +- Build the core and proc_macro libraries only ```bash -./x.py build src/libcore src/libproc_macro +./x.py build library/core library/proc_macro ``` Sometimes you might just want to test if the part you’re working on can @@ -277,11 +277,11 @@ in other sections: - Building things: - `./x.py build` – builds everything using the stage 1 compiler, - not just up to `libstd` + not just up to `std` - `./x.py build --stage 2` – builds the stage2 compiler - Running tests (see the [section on running tests](../tests/running.html) for more details): - - `./x.py test src/libstd` – runs the `#[test]` tests from `libstd` + - `./x.py test library/std` – runs the `#[test]` tests from `std` - `./x.py test src/test/ui` – runs the `ui` test suite - `./x.py test src/test/ui/const-generics` - runs all the tests in the `const-generics/` subdirectory of the `ui` test suite diff --git a/src/building/new-target.md b/src/building/new-target.md index 0bd200908..eea01e9cc 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -94,7 +94,7 @@ cross-compile `rustc`: ``` DESTDIR=/path/to/install/in \ ./x.py install -i --stage 1 --host aarch64-apple-darwin.json --target aarch64-apple-darwin \ -src/librustc src/libstd +src/librustc library/std ``` If your target specification is already available in the bootstrap diff --git a/src/building/suggested.md b/src/building/suggested.md index fd2c00baa..08858507f 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -58,13 +58,13 @@ don't work (but that is easily detected and fixed). The sequence of commands you want is as follows: -- Initial build: `./x.py build -i src/libstd` +- Initial build: `./x.py build -i library/std` - As [documented above](#command), this will build a functional stage1 compiler as part of running all stage0 commands (which include - building a `libstd` compatible with the stage1 compiler) as well as the + building a `std` compatible with the stage1 compiler) as well as the first few steps of the "stage 1 actions" up to "stage1 (sysroot stage1) - builds libstd". -- Subsequent builds: `./x.py build -i src/libstd --keep-stage 1` + builds std". +- Subsequent builds: `./x.py build -i library/std --keep-stage 1` - Note that we added the `--keep-stage 1` flag here As mentioned, the effect of `--keep-stage 1` is that we just *assume* that the diff --git a/src/contributing.md b/src/contributing.md index 180197ddc..e835eef84 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -364,7 +364,7 @@ You can find documentation style guidelines in [RFC 1574][rfc1574]. In many cases, you don't need a full `./x.py doc --stage 2`, which will build the entire stage 2 compiler and compile the various books published on [doc.rust-lang.org][docs]. When updating documentation for the standard library, -first try `./x.py doc src/libstd`. If that fails, or if you need to +first try `./x.py doc library/std`. If that fails, or if you need to see the output from the latest version of `rustdoc`, add `--stage 1`. Results should appear in `build/$TARGET/crate-docs`. diff --git a/src/getting-started.md b/src/getting-started.md index 9d5db4b05..055551c60 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -175,9 +175,9 @@ should still read the rest of the section: | Command | When to use it | | --- | --- | | `x.py check` | Quick check to see if things compile; rust-analyzer can run this automatically for you | -| `x.py build --stage 0 [src/libstd]` | Build only the standard library, without building the compiler | -| `x.py build src/libstd` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough | -| `x.py build --keep-stage 1 src/libstd` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | +| `x.py build --stage 0 [library/std]` | Build only the standard library, without building the compiler | +| `x.py build library/std` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough | +| `x.py build --keep-stage 1 library/std` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | | `x.py test [--keep-stage 1]` | Run the test suite using the stage1 compiler | | `x.py test --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. | | `x.py build --stage 2 src/rustc` | Do a full 2-stage build. You almost never want to do this. | @@ -203,10 +203,10 @@ For most contributions, you only need to build stage 1, which saves a lot of tim ```sh # Build the compiler (stage 1) -./x.py build src/libstd +./x.py build library/std # Subsequent builds -./x.py build --keep-stage 1 src/libstd +./x.py build --keep-stage 1 library/std ``` This will take a while, especially the first time. Be wary of accidentally @@ -294,10 +294,10 @@ stage 0, which uses the current beta compiler. ``` ```sh -./x.py test --stage 0 src/libstd +./x.py test --stage 0 library/std ``` -(The same works for `src/liballoc`, `src/libcore`, etc.) +(The same works for `library/alloc`, `library/core`, etc.) ### Building and Testing `rustdoc` diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 549a9cd05..1b4f827d4 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -2,14 +2,14 @@ #### Step 1: Invocation of the `panic!` macro. -There are actually two panic macros - one defined in `libcore`, and one defined in `libstd`. -This is due to the fact that code in `libcore` can panic. `libcore` is built before `libstd`, -but we want panics to use the same machinery at runtime, whether they originate in `libcore` -or `libstd`. +There are actually two panic macros - one defined in `core`, and one defined in `std`. +This is due to the fact that code in `core` can panic. `core` is built before `std`, +but we want panics to use the same machinery at runtime, whether they originate in `core` +or `std`. -##### libcore definition of panic! +##### core definition of panic! -The `libcore` `panic!` macro eventually makes the following call (in `src/libcore/panicking.rs`): +The `core` `panic!` macro eventually makes the following call (in `library/core/src/panicking.rs`): ```rust // NOTE This function never crosses the FFI boundary; it's a Rust-to-Rust call @@ -29,13 +29,13 @@ Actually resolving this goes through several layers of indirection: to set the actual symbol name to `rust_begin_unwind`. Note that `panic_impl` is declared in an `extern "Rust"` block, - which means that libcore will attempt to call a foreign symbol called `rust_begin_unwind` + which means that core will attempt to call a foreign symbol called `rust_begin_unwind` (to be resolved at link time) -2. In `src/libstd/panicking.rs`, we have this definition: +2. In `library/std/src/panicking.rs`, we have this definition: ```rust -/// Entry point of panic from the libcore crate. +/// Entry point of panic from the core crate. #[cfg(not(test))] #[panic_handler] #[unwind(allowed)] @@ -47,18 +47,18 @@ pub fn begin_panic_handler(info: &PanicInfo<'_>) -> ! { The special `panic_handler` attribute is resolved via `src/librustc_middle/middle/lang_items`. The `extract` function converts the `panic_handler` attribute to a `panic_impl` lang item. -Now, we have a matching `panic_handler` lang item in the `libstd`. This function goes -through the same process as the `extern { fn panic_impl }` definition in `libcore`, ending -up with a symbol name of `rust_begin_unwind`. At link time, the symbol reference in `libcore` -will be resolved to the definition of `libstd` (the function called `begin_panic_handler` in the +Now, we have a matching `panic_handler` lang item in the `std`. This function goes +through the same process as the `extern { fn panic_impl }` definition in `core`, ending +up with a symbol name of `rust_begin_unwind`. At link time, the symbol reference in `core` +will be resolved to the definition of `std` (the function called `begin_panic_handler` in the Rust source). -Thus, control flow will pass from libcore to std at runtime. This allows panics from `libcore` +Thus, control flow will pass from core to std at runtime. This allows panics from `core` to go through the same infrastructure that other panics use (panic hooks, unwinding, etc) -##### libstd implementation of panic! +##### std implementation of panic! -This is where the actual panic-related logic begins. In `src/libstd/panicking.rs`, +This is where the actual panic-related logic begins. In `library/std/src/panicking.rs`, control passes to `rust_panic_with_hook`. This method is responsible for invoking the global panic hook, and checking for double panics. Finally, we call `__rust_start_panic`, which is provided by the panic runtime. @@ -84,13 +84,13 @@ Finally, we call `__rust_start_panic` with this `usize`. We have now entered the #### Step 2: The panic runtime -Rust provides two panic runtimes: `libpanic_abort` and `libpanic_unwind`. The user chooses +Rust provides two panic runtimes: `panic_abort` and `panic_unwind`. The user chooses between them at build time via their `Cargo.toml` -`libpanic_abort` is extremely simple: its implementation of `__rust_start_panic` just aborts, +`panic_abort` is extremely simple: its implementation of `__rust_start_panic` just aborts, as you would expect. -`libpanic_unwind` is the more interesting case. +`panic_unwind` is the more interesting case. In its implementation of `__rust_start_panic`, we take the `usize`, convert it back to a `*mut &mut dyn BoxMeUp`, dereference it, and call `box_me_up` @@ -99,10 +99,11 @@ itself (a `*mut (dyn Send + Any)`): that is, a raw pointer to the actual value provided by the user who called `panic!`. At this point, the platform-independent code ends. We now call into -platform-specific unwinding logic (e.g `libunwind`). This code is +platform-specific unwinding logic (e.g `unwind`). This code is responsible for unwinding the stack, running any 'landing pads' associated with each frame (currently, running destructors), and transferring control to the `catch_unwind` frame. Note that all panics either abort the process or get caught by some call to `catch_unwind`: -in `src/libstd/rt.rs`, the call to the user-provided `main` function is wrapped in `catch_unwind`. +in `library/std/src/rt.rs`, the call to the user-provided +`main` function is wrapped in `catch_unwind`. diff --git a/src/profile-guided-optimization.md b/src/profile-guided-optimization.md index fb897e901..03198fb1a 100644 --- a/src/profile-guided-optimization.md +++ b/src/profile-guided-optimization.md @@ -108,10 +108,10 @@ data needs some infrastructure in place. In the case of LLVM, these runtime components are implemented in [compiler-rt][compiler-rt-profile] and statically linked into any instrumented binaries. -The `rustc` version of this can be found in `src/libprofiler_builtins` which +The `rustc` version of this can be found in `library/profiler_builtins` which basically packs the C code from `compiler-rt` into a Rust crate. -In order for `libprofiler_builtins` to be built, `profiler = true` must be set +In order for `profiler_builtins` to be built, `profiler = true` must be set in `rustc`'s `config.toml`. [compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/master/compiler-rt/lib/profile diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 33d001f39..8c6050da2 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -20,7 +20,7 @@ address [issue 42678](https://github.com/rust-lang/rust/issues/42678). Compile the compiler, up to at least stage 1: ``` -x.py build src/libstd +x.py build library/std ``` ### 2. Run `rustc`, with flags diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index ab3bf1b30..d44e6679b 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -162,7 +162,7 @@ documentation in `test.rs`, but instead of going through the full clean and render process, it runs a much simpler crate walk to grab *just* the hand-written documentation. Combined with the aforementioned "`find_testable_code`" in `html/markdown.rs`, it builds up a collection of -tests to run before handing them off to the libtest test runner. One notable +tests to run before handing them off to the test test runner. One notable location in `test.rs` is the function `make_test`, which is where hand-written doctests get transformed into something that can be executed. diff --git a/src/rustdoc.md b/src/rustdoc.md index 1a3cf7019..b37c15808 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -32,11 +32,11 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * Use `./x.py build` to make a usable rustdoc you can run on other projects. - * Add `src/libtest` to be able to use `rustdoc --test`. + * Add `library/test` to be able to use `rustdoc --test`. * If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1` previously, then after the previous build command, `cargo +local doc` will Just Work. -* Use `./x.py doc --stage 1 src/libstd` to use this rustdoc to generate the +* Use `./x.py doc --stage 1 library/std` to use this rustdoc to generate the standard library docs. * The completed docs will be available in `build/$TARGET/doc/std`, though the bundle is meant to be used as though you would copy out the `doc` folder to diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 73edc3be5..73875bceb 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -124,7 +124,7 @@ writing, the next stable release (i.e. what is currently beta) was Next search for the feature string (in this case, `pub_restricted`) in the codebase to find where it appears. Change uses of -`#![feature(XXX)]` from the `libstd` and any rustc crates to be +`#![feature(XXX)]` from the `std` and any rustc crates to be `#![cfg_attr(bootstrap, feature(XXX))]`. This includes the feature-gate only for stage0, which is built using the current beta (this is needed because the feature is still unstable in the current beta). diff --git a/src/tests/adding.md b/src/tests/adding.md index 538860f65..c74f6cec4 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -378,8 +378,8 @@ The following strings replace their corresponding values: Additionally, the following changes are made: - Line and column numbers for paths in `$SRC_DIR` are replaced with `LL:CC`. - For example, `/path/to/rust/src/libcore/clone.rs:122:8` is replaced with - `$SRC_DIR/libcore/clone.rs:LL:COL`. + For example, `/path/to/rust/library/core/src/clone.rs:122:8` is replaced with + `$SRC_DIR/core/src/clone.rs:LL:COL`. Note: The line and column numbers for `-->` lines pointing to the test are *not* normalized, and left as-is. This ensures that the compiler continues diff --git a/src/tests/intro.md b/src/tests/intro.md index 0f517f871..125e2c931 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -51,7 +51,7 @@ details. - `rustdoc` – tests for rustdoc, making sure that the generated files contain the expected documentation. - `*-fulldeps` – same as above, but indicates that the test depends - on things other than `libstd` (and hence those things must be built) + on things other than `std` (and hence those things must be built) ## Other Tests @@ -82,7 +82,7 @@ including: include typical Rust `#[test]` unittests. Under the hood, `x.py` will run `cargo test` on each package to run all the tests. - Example: `./x.py test src/libstd` + Example: `./x.py test library/std` - **Doc tests** – Example code embedded within Rust documentation is executed via `rustdoc --test`. Examples: @@ -90,7 +90,7 @@ including: `./x.py test src/doc` – Runs `rustdoc --test` for all documentation in `src/doc`. - `./x.py test --doc src/libstd` – Runs `rustdoc --test` on the standard + `./x.py test --doc library/std` – Runs `rustdoc --test` on the standard library. - **Link checker** – A small tool for verifying `href` links within diff --git a/src/tests/running.md b/src/tests/running.md index 44561f6f2..1a6805132 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -68,19 +68,19 @@ Likewise, you can test a single file by passing its path: ### Run tests on the standard library ```bash -./x.py test src/libstd +./x.py test library/std ``` ### Run the tidy script and tests on the standard library ```bash -./x.py test tidy src/libstd +./x.py test tidy library/std ``` ### Run tests on the standard library using a stage 1 compiler ```bash -> ./x.py test src/libstd +> ./x.py test library/std ``` By listing which test suites you want to run you avoid having to run diff --git a/src/walkthrough.md b/src/walkthrough.md index c2a1308b6..9963692c7 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -50,7 +50,7 @@ before, not all of these are needed for every type of contribution. - **Implementation** Implement your idea unstably in the compiler. You can find the original implementation [here][impl1]. - **Possibly iterate/refine** As the community gets experience with your - feature on the nightly compiler and in `libstd`, there may be additional + feature on the nightly compiler and in `std`, there may be additional feedback about design choice that might be adjusted. This particular feature went [through][impl2] a [number][impl3] of [iterations][impl4]. - **Stabilization** When your feature has baked enough, a rust team member may From c7a3bca8291ba5e8e3e161d9428c4f3c5dced5db Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 31 Jul 2020 12:56:11 +0900 Subject: [PATCH 1140/1812] Adjust mentions about CI to GitHub Actions --- README.md | 5 ++++- src/notification-groups/llvm.md | 2 +- src/tests/intro.md | 24 +++++++++++++----------- src/tests/running.md | 6 +++--- src/walkthrough.md | 4 ++-- 5 files changed, 23 insertions(+), 18 deletions(-) diff --git a/README.md b/README.md index 345b38589..eda6a4565 100644 --- a/README.md +++ b/README.md @@ -103,13 +103,16 @@ There is not a workaround for this error at the moment. Comment out the `[outpu ## How to fix toolstate failures +> **NOTE**: Currently, we do not track the toolstate due to the spurious failure, +but we leave this for when we do it again in the future. + 1. You will get a ping from the toolstate commit. e.g. https://github.com/rust-lang-nursery/rust-toolstate/commit/8ffa0e4c30ac9ba8546b7046e5c4ccc2b96ebdd4 2. The commit contains a link to the PR that caused the breakage. e.g. https://github.com/rust-lang/rust/pull/64321 3. If you go to that PR's thread, there is a post from bors with a link to the CI status: https://github.com/rust-lang/rust/pull/64321#issuecomment-529763807 -4. Follow the check-azure link to get to the Azure website for that build: https://dev.azure.com/rust-lang/e71b0ddf-dd27-435a-873c-e30f86eea377/_build/results?buildId=7780 +4. Follow the check-actions link to get to the Actions page for that build 5. There will be approximately 1 billion different jobs for the build. They are for different configurations and platforms. The rustc-dev-guide build only runs on the Linux x86_64-gnu-tools job. So click on that job in the list, which is about 60% down in the list. diff --git a/src/notification-groups/llvm.md b/src/notification-groups/llvm.md index d657231f2..f1f2097e5 100644 --- a/src/notification-groups/llvm.md +++ b/src/notification-groups/llvm.md @@ -21,7 +21,7 @@ questions. The ["Debugging LLVM"][d] section of the rustc-dev-guide gives a step-by-step process for how to help debug bugs caused by LLVM. In particular, it discusses how to emit LLVM IR, run -the LLVM IR optimization pipeliness, and so forth. You may also find +the LLVM IR optimization pipelines, and so forth. You may also find it useful to look at the various codegen options listed under `-Chelp` and the internal options under `-Zhelp` -- there are a number that pertain to LLVM (just search for LLVM). diff --git a/src/tests/intro.md b/src/tests/intro.md index 125e2c931..3503e7ad1 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -116,19 +116,21 @@ including: ## Testing infrastructure -When a Pull Request is opened on Github, [Azure Pipelines] will automatically +When a Pull Request is opened on Github, [GitHub Actions] will automatically launch a build that will run all tests on some configurations -(x86_64-gnu-llvm-6.0 linux. x86_64-gnu-tools linux, mingw-check linux). In +(x86_64-gnu-llvm-8 linux. x86_64-gnu-tools linux, mingw-check linux). In essence, it runs `./x.py test` after building for each of them. The integration bot [bors] is used for coordinating merges to the master branch. When a PR is approved, it goes into a [queue] where merges are tested -one at a time on a wide set of platforms using Azure Pipelines (currently over -50 different configurations). Most platforms only run the build steps, some run -a restricted set of tests, only a subset run the full suite of tests (see -Rust's [platform tiers]). - -[Azure Pipelines]: https://dev.azure.com/rust-lang/rust/ +one at a time on a wide set of platforms using GitHub Actions (currently over +50 different configurations). Due to the limit on the number of parallel jobs, +we run CI under the [rust-lang-ci] organization except for PRs. +Most platforms only run the build steps, some run a restricted set of tests, +only a subset run the full suite of tests (see Rust's [platform tiers]). + +[GitHub Actions]: https://github.com/rust-lang/rust/actions +[rust-lang-ci]: https://github.com/rust-lang-ci/rust/actions [bors]: https://github.com/servo/homu [queue]: https://buildbot2.rust-lang.org/homu/queue/rust [platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support @@ -136,7 +138,7 @@ Rust's [platform tiers]). ## Testing with Docker images The Rust tree includes [Docker] image definitions for the platforms used on -Azure Pipelines in [`src/ci/docker`]. The script [`src/ci/docker/run.sh`] is used to build +GitHub Actions in [`src/ci/docker`]. The script [`src/ci/docker/run.sh`] is used to build the Docker image, run it, build Rust within the image, and run the tests. You can run these images on your local development machine. This can be @@ -260,9 +262,9 @@ above instructions for testing on a remote machine (in this case the remote machine is emulated). There is also a set of tools for orchestrating running the -tests within the emulator. Platforms such as `arm-android` and +tests within the emulator. Platforms such as `arm-android` and `arm-unknown-linux-gnueabihf` are set up to automatically run the tests under -emulation on Travis. The following will take a look at how a target's tests +emulation on GitHub Actions. The following will take a look at how a target's tests are run under emulation. The Docker image for [armhf-gnu] includes [QEMU] to emulate the ARM CPU diff --git a/src/tests/running.md b/src/tests/running.md index 1a6805132..1043f87a1 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -9,9 +9,9 @@ you will almost never want to use! – is as follows: This will build the stage 1 compiler and then run the whole test suite. You probably don't want to do this very often, because it takes -a very long time, and anyway bors / travis will do it for you. (Often, -I will run this command in the background after opening a PR that I -think is done, but rarely otherwise. -nmatsakis) +a very long time, and anyway bors / GitHub Actions will do it for you. +(Often, I will run this command in the background after opening a PR that +I think is done, but rarely otherwise. -nmatsakis) The test results are cached and previously successful tests are `ignored` during testing. The stdout/stderr contents as well as a diff --git a/src/walkthrough.md b/src/walkthrough.md index 9963692c7..8a41b3dd8 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -190,9 +190,9 @@ recognize that the PR won't be merged unless someone on the rust team approves it. When your reviewer approves the PR, it will go into a queue for yet another bot -called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches +called `@bors`. `@bors` manages the CI build/merge queue. When your PR reaches the head of the `@bors` queue, `@bors` will test out the merge by running all -tests against your PR on Travis CI. This takes a lot of time to +tests against your PR on GitHub Actions. This takes a lot of time to finish. If all tests pass, the PR is merged and becomes part of the next nightly compiler! From 5d8a8c832b84d3985f6abdc41f9eedbcb0a1f00a Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 1 Aug 2020 02:05:57 +0900 Subject: [PATCH 1141/1812] Address review comment --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index eda6a4565..5dbd5d27f 100644 --- a/README.md +++ b/README.md @@ -103,8 +103,9 @@ There is not a workaround for this error at the moment. Comment out the `[outpu ## How to fix toolstate failures -> **NOTE**: Currently, we do not track the toolstate due to the spurious failure, -but we leave this for when we do it again in the future. +> **NOTE**: Currently, we do not track the rustc-dev-guide toolstate due to +[the spurious failure](https://github.com/rust-lang/rust/pull/71731), +but we leave this instructions for when we do it again in the future. 1. You will get a ping from the toolstate commit. e.g. https://github.com/rust-lang-nursery/rust-toolstate/commit/8ffa0e4c30ac9ba8546b7046e5c4ccc2b96ebdd4 From d89c8c9b12ede0df2cf2ed3e8fa04b6edece8310 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 2 Aug 2020 02:33:51 +0900 Subject: [PATCH 1142/1812] Rename `HAIR` to `THIR` --- src/SUMMARY.md | 2 +- src/borrow_check/two_phase_borrows.md | 2 +- src/mir/construction.md | 20 ++++++++++---------- src/overview.md | 12 ++++++------ 4 files changed, 18 insertions(+), 18 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 391a32b9e..1fe7dcf11 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -80,7 +80,7 @@ - [Lowering AST to HIR](./lowering.md) - [Debugging](./hir-debugging.md) - [The MIR (Mid-level IR)](./mir/index.md) - - [HAIR and MIR construction](./mir/construction.md) + - [THIR and MIR construction](./mir/construction.md) - [MIR visitor and traversal](./mir/visitor.md) - [MIR passes: getting the MIR for a function](./mir/passes.md) - [Closure expansion](./closure.md) diff --git a/src/borrow_check/two_phase_borrows.md b/src/borrow_check/two_phase_borrows.md index ad17bbb66..a5e26c6a8 100644 --- a/src/borrow_check/two_phase_borrows.md +++ b/src/borrow_check/two_phase_borrows.md @@ -74,7 +74,7 @@ The activation points are found using the [`GatherBorrows`] visitor. The borrow. [`AutoBorrow`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/adjustment/enum.AutoBorrow.html -[converted]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/hair/cx/expr/trait.ToBorrowKind.html#method.to_borrow_kind +[converted]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/cx/expr/trait.ToBorrowKind.html#method.to_borrow_kind [`BorrowKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.BorrowKind.html [`GatherBorrows`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/visit/trait.Visitor.html#method.visit_local [`BorrowData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/borrow_set/struct.BorrowData.html diff --git a/src/mir/construction.md b/src/mir/construction.md index f353eacdf..585984e2a 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -1,4 +1,4 @@ -# HAIR and MIR construction +# THIR and MIR construction The lowering of [HIR] to [MIR] occurs for the following (probably incomplete) list of items: @@ -13,19 +13,19 @@ list of items: The lowering is triggered by calling the [`mir_built`] query. There is an intermediate representation -between [HIR] and [MIR] called the [HAIR] that is only used during the lowering. -The [HAIR]'s most important feature is that the various adjustments (which happen +between [HIR] and [MIR] called the [THIR] that is only used during the lowering. +The [THIR]'s most important feature is that the various adjustments (which happen without explicit syntax) like coercions, autoderef, autoref and overloaded method calls have become explicit casts, deref operations, reference expressions or concrete function calls. -The [HAIR] has datatypes that mirror the [HIR] datatypes, but instead of e.g. `-x` -being a `hair::ExprKind::Neg(hair::Expr)` it is a `hair::ExprKind::Neg(hir::Expr)`. -This shallowness enables the `HAIR` to represent all datatypes that [HIR] has, but +The [THIR] has datatypes that mirror the [HIR] datatypes, but instead of e.g. `-x` +being a `thir::ExprKind::Neg(thir::Expr)` it is a `thir::ExprKind::Neg(hir::Expr)`. +This shallowness enables the `THIR` to represent all datatypes that [HIR] has, but without having to create an in-memory copy of the entire [HIR]. [MIR] lowering will first convert the topmost expression from -[HIR] to [HAIR] (in [`rustc_mir_build::hair::cx::expr`]) and then process -the [HAIR] expressions recursively. +[HIR] to [THIR] (in [`rustc_mir_build::thir::cx::expr`]) and then process +the [THIR] expressions recursively. The lowering creates local variables for every argument as specified in the signature. Next it creates local variables for every binding specified (e.g. `(a, b): (i32, String)`) @@ -152,7 +152,7 @@ case of `enum`s. [MIR]: ./index.html [HIR]: ../hir.html -[HAIR]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/hair/index.html +[THIR]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/index.html -[`rustc_mir_build::hair::cx::expr`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/hair/cx/expr/index.html +[`rustc_mir_build::thir::cx::expr`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/cx/expr/index.html [`mir_built`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/build/fn.mir_built.html diff --git a/src/overview.md b/src/overview.md index eb774b113..8813d215e 100644 --- a/src/overview.md +++ b/src/overview.md @@ -55,7 +55,7 @@ we'll talk about that later. - `stmt.rs` - This naming scheme is used across many compiler stages. You will find either a file or directory with the same name across the parsing, lowering, - type checking, HAIR lowering, and MIR building sources. + type checking, THIR lowering, and MIR building sources. - Macro expansion, AST validation, name resolution, and early linting takes place during this stage of the compile process. - The parser uses the standard `DiagnosticBuilder` API for error handling, but we @@ -69,8 +69,8 @@ we'll talk about that later. - **TODO: Maybe some other things are done here? I think initial type checking happens here? And trait solving?** - The HIR is then [lowered to Mid-Level Intermediate Representation (MIR)][mir]. - - Along the way, we construct the HAIR, which is an even more desugared HIR. - HAIR is used for pattern and exhaustiveness checking. It is also more + - Along the way, we construct the THIR, which is an even more desugared HIR. + THIR is used for pattern and exhaustiveness checking. It is also more convenient to convert into MIR than HIR is. - The MIR is used for [borrow checking]. - We (want to) do [many optimizations on the MIR][mir-opt] because it is still @@ -187,10 +187,10 @@ for different purposes: - High-level IR (HIR): This is a sort of desugared AST. It's still close to what the user wrote syntactically, but it includes some implicit things such as some elided lifetimes, etc. This IR is amenable to type checking. -- HAIR: This is an intermediate between HIR and MIR. It is like the HIR but it - is fully typed and a bit more desugared (e.g. method calls and implicit +- Typed HIR (THIR): This is an intermediate between HIR and MIR. It is like the HIR + but it is fully typed and a bit more desugared (e.g. method calls and implicit dereferences are made fully explicit). Moreover, it is easier to lower to MIR - from HAIR than from HIR. + from THIR than from HIR. - Middle-level IR (MIR): This IR is basically a Control-Flow Graph (CFG). A CFG is a type of diagram that shows the basic blocks of a program and how control flow can go between them. Likewise, MIR also has a bunch of basic blocks with From 61824dde4f47e5a2a8f2c56c63daece1eed2c578 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 2 Aug 2020 09:37:43 +0900 Subject: [PATCH 1143/1812] Mention `HAIR` to clarify --- src/mir/construction.md | 1 + src/overview.md | 8 ++++---- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 585984e2a..7fe9ee884 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -14,6 +14,7 @@ list of items: The lowering is triggered by calling the [`mir_built`] query. There is an intermediate representation between [HIR] and [MIR] called the [THIR] that is only used during the lowering. +[THIR] means "Typed HIR" and used to be called "HAIR (High-level Abstract IR)". The [THIR]'s most important feature is that the various adjustments (which happen without explicit syntax) like coercions, autoderef, autoref and overloaded method calls have become explicit casts, deref operations, reference expressions or diff --git a/src/overview.md b/src/overview.md index 8813d215e..ec96d243f 100644 --- a/src/overview.md +++ b/src/overview.md @@ -187,10 +187,10 @@ for different purposes: - High-level IR (HIR): This is a sort of desugared AST. It's still close to what the user wrote syntactically, but it includes some implicit things such as some elided lifetimes, etc. This IR is amenable to type checking. -- Typed HIR (THIR): This is an intermediate between HIR and MIR. It is like the HIR - but it is fully typed and a bit more desugared (e.g. method calls and implicit - dereferences are made fully explicit). Moreover, it is easier to lower to MIR - from THIR than from HIR. +- Typed HIR (THIR): This is an intermediate between HIR and MIR, and used to be called + High-level Abstract IR (HAIR). It is like the HIR but it is fully typed and a bit + more desugared (e.g. method calls and implicit dereferences are made fully explicit). + Moreover, it is easier to lower to MIR from THIR than from HIR. - Middle-level IR (MIR): This IR is basically a Control-Flow Graph (CFG). A CFG is a type of diagram that shows the basic blocks of a program and how control flow can go between them. Likewise, MIR also has a bunch of basic blocks with From 80c2dfd9d69eb4eea50143b40f51cbbfe86f258f Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 24 Jun 2020 11:53:38 -0500 Subject: [PATCH 1144/1812] rewrite/update compiler source code chapter --- src/compiler-src.md | 282 +++++++++++++++++++++++--------------------- 1 file changed, 147 insertions(+), 135 deletions(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index 25b3baa3e..efb9ae896 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -1,137 +1,149 @@ # High-level overview of the compiler source -## Crate structure - -The main Rust repository consists of a `src` directory, under which -there live many crates. These crates contain the sources for the -standard library and the compiler. This document, of course, focuses -on the latter. - -Rustc consists of a number of crates, including `rustc_ast`, -`rustc`, `rustc_target`, `rustc_codegen`, `rustc_driver`, and -many more. The source for each crate can be found in a directory -like `src/libXXX`, where `XXX` is the crate name. - -(N.B. The names and divisions of these crates are not set in -stone and may change over time. For the time being, we tend towards a -finer-grained division to help with compilation time, though as incremental -compilation improves, that may change.) - -The dependency structure of these crates is roughly a diamond: - -```text - rustc_driver - / | \ - / | \ - / | \ - / v \ -rustc_codegen rustc_borrowck ... rustc_metadata - \ | / - \ | / - \ | / - \ v / - rustc_middle - | - v - rustc_ast - / \ - / \ - rustc_span rustc_builtin_macros -``` - -The `rustc_driver` crate, at the top of this lattice, is effectively -the "main" function for the rust compiler. It doesn't have much "real -code", but instead ties together all of the code defined in the other -crates and defines the overall flow of execution. (As we transition -more and more to the [query model], however, the -"flow" of compilation is becoming less centrally defined.) - -At the other extreme, the `rustc_middle` crate defines the common and -pervasive data structures that all the rest of the compiler uses -(e.g. how to represent types, traits, and the program itself). It -also contains some amount of the compiler itself, although that is -relatively limited. - -Finally, all the crates in the bulge in the middle define the bulk of -the compiler – they all depend on `rustc_middle`, so that they can make use -of the various types defined there, and they export public routines -that `rustc_driver` will invoke as needed (more and more, what these -crates export are "query definitions", but those are covered later -on). - -Below `rustc_middle` lie various crates that make up the parser and error -reporting mechanism. They are also an internal part -of the compiler and not intended to be stable (though they do wind up -getting used by some crates in the wild; a practice we hope to -gradually phase out). - -## The main stages of compilation - -The Rust compiler is in a bit of transition right now. It used to be a -purely "pass-based" compiler, where we ran a number of passes over the -entire program, and each did a particular check of transformation. We -are gradually replacing this pass-based code with an alternative setup -based on on-demand **queries**. In the query-model, we work backwards, -executing a *query* that expresses our ultimate goal (e.g. "compile -this crate"). This query in turn may make other queries (e.g. "get me -a list of all modules in the crate"). Those queries make other queries -that ultimately bottom out in the base operations, like parsing the -input, running the type-checker, and so forth. This on-demand model -permits us to do exciting things like only do the minimal amount of -work needed to type-check a single function. It also helps with -incremental compilation. (For details on defining queries, check out -the [query model].) - -Regardless of the general setup, the basic operations that the -compiler must perform are the same. The only thing that changes is -whether these operations are invoked front-to-back, or on demand. In -order to compile a Rust crate, these are the general steps that we -take: - -1. **Parsing input** - - this processes the `.rs` files and produces the AST - ("abstract syntax tree") - - the AST is defined in `src/librustc_ast/ast.rs`. It is intended to match the lexical - syntax of the Rust language quite closely. -2. **Name resolution, macro expansion, and configuration** - - once parsing is complete, we process the AST recursively, resolving - paths and expanding macros. This same process also processes `#[cfg]` - nodes, and hence may strip things out of the AST as well. -3. **Lowering to HIR** - - Once name resolution completes, we convert the AST into the HIR, - or "[high-level intermediate representation]". The HIR is defined in - `src/librustc_middle/hir/`; that module also includes the [lowering] code. - - The HIR is a lightly desugared variant of the AST. It is more processed - than the AST and more suitable for the analyses that follow. - It is **not** required to match the syntax of the Rust language. - - As a simple example, in the **AST**, we preserve the parentheses - that the user wrote, so `((1 + 2) + 3)` and `1 + 2 + 3` parse - into distinct trees, even though they are equivalent. In the - HIR, however, parentheses nodes are removed, and those two - expressions are represented in the same way. -3. **Type-checking and subsequent analyses** - - An important step in processing the HIR is to perform type - checking. This process assigns types to every HIR expression, - for example, and also is responsible for resolving some - "type-dependent" paths, such as field accesses (`x.f` – we - can't know what field `f` is being accessed until we know the - type of `x`) and associated type references (`T::Item` – we - can't know what type `Item` is until we know what `T` is). - - Type checking creates "side-tables" (`TypeckTables`) that include - the types of expressions, the way to resolve methods, and so forth. - - After type-checking, we can do other analyses, such as privacy checking. -4. **Lowering to MIR and post-processing** - - Once type-checking is done, we can lower the HIR into MIR ("middle IR"), - which is a **very** desugared version of Rust, well suited to borrowck - but also to certain high-level optimizations. -5. **Translation to LLVM and LLVM optimizations** - - From MIR, we can produce LLVM IR. - - LLVM then runs its various optimizations, which produces a number of - `.o` files (one for each "codegen unit"). -6. **Linking** - - Finally, those `.o` files are linked together. - - -[query model]: query.html -[high-level intermediate representation]: hir.html -[lowering]: lowering.html +> **NOTE**: The structure of the repository is going through a lot of +> transitions. In particular, we want to get to a point eventually where the +> top-level directory has separate directories for the compiler, build-system, +> std libs, etc, rather than one huge `src/` directory. + +## Workspace structure + +The `rust-lang/rust` repository consists of a single large cargo workspace +containing the compiler, the standard library (core, alloc, std, etc), and +`rustdoc`, along with the build system and bunch of tools and submodules for +building a full Rust distribution. + +As of this writing, this structure is gradually undergoing some transformation +to make it a bit less monolithic and more approachable, especially to +newcommers. + +> Eventually, the hope is for the standard library to live in a `stdlib/` +> directory, while the compiler lives in `compiler/`. However, as of this +> writing, both live in `src/`. + +The repository consists of a `src` directory, under which there live many +crates, which are the source for the compiler, standard library, etc, as +mentioned above. + +## Standard library + +The standard library crates are obviously named `libstd`, `libcore`, +`liballoc`, etc. There is also `libproc_macro`, `libtest`, and other runtime +libraries. + +This code is fairly similar to most other Rust crates except that it must be +built in a special way because it can use unstable features. + +## Compiler + +The compiler crates all have names starting with `librustc_*`. These are a large +collection of interdependent crates. There is also the `rustc` crate which is +the actual binary. It doesn't actually do anything besides calling the compiler +main function elsewhere. + +The dependency structure of these crates is complex, but roughly it is +something like this: + +- `rustc` (the binary) calls [`rustc_driver::main`][main]. + - [`rustc_driver`] depends on a lot of other crates, but the main one is + [`rustc_interface`]. + - [`rustc_interface`] depends on most of the other compiler crates. It + is a fairly generic interface for driving the whole compilation. + - The most of the other `rustc_*` crates depend on [`rustc_middle`], + which defines a lot of central data structures in the compiler. + - [`rustc_middle`] and most of the other crates depend on a + handful of crates representing the early parts of the + compiler (e.g. the parser), fundamental data structures (e.g. + [`Span`]), or error reporting: [`rustc_data_strucutres`], + [`rustc_span`], [`rustc_errors`], etc. + +[main]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.main.html +[`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/index.html +[`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html +[`rustc_middle`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/index.html +[`rustc_data_strucutres`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_strucutres/index.html +[`rustc_span`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/index.html +[`Span`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html +[`rustc_errors`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html + +You can see the exact dependencies by reading the `Cargo.toml` for the various +crates, just like a normal Rust crate. + +You may ask why the compiler is broken into so many crates. There are two major reasons: + +1. Organization. The compiler is a _huge_ codebase; it would be an impossibly large crate. +2. Compile time. By breaking the compiler into multiple crates, we can take + better advantage of incremental/parallel compilation using cargo. In + particular, we try to have as few dependencies between crates as possible so + that we dont' have to rebuild as many crates if you change one. + +Most of this book is about the compiler, so we won't have any further +explanation of these crates here. + +One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM. + +[`src/llvm-project`]: https://github.com/rust-lang/rust/tree/master/src + +## rustdoc + +The bulk of `rustdoc` is in [`librustdoc`]. However, the `rustdoc` binary +itself is [`src/tools/rustdoc`], which does nothing except call [`rustdoc::main`]. + +There is also javascript and CSS for the rustdocs in [`src/tools/rustdoc-js`] +and [`src/tools/rustdoc-themes`]. + +You can read more about rustdoc in [this chapter][rustdocch]. + +[`librustdoc`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/index.html +[`rustdoc::main`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/fn.main.html +[`src/tools/rustdoc`]: https://github.com/rust-lang/rust/tree/master/src/tools/rustdoc +[`src/tools/rustdoc-js`]: https://github.com/rust-lang/rust/tree/master/src/tools/rustdoc-js +[`src/tools/rustdoc-themes`]: https://github.com/rust-lang/rust/tree/master/src/tools/rustdoc-themes + +[rustdocch]: ./rustdoc-internals.md + +## Tests + +The test suite for all of the above is in [`src/test/`]. You can read more +about the test suite [in this chapter][testsch]. + +The test harness itself is in [`src/tools/compiletest`]. + +[testsch]: ./tests/intro.md + +[`src/test/`]: https://github.com/rust-lang/rust/tree/master/src/test +[`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest + +## Build System + +There are a number of tools in the repository just for building the compiler, +standard library, rustdoc, etc, along with testing, building a full Rust +distribution, etc. + +One of the primary tools is [`src/bootstrap`]. You can read more about +bootstrapping [in this chapter][bootstch]. The process may also use other tools +from `src/tools/`, such as [`tidy`] or [`compiletest`]. + +[`src/bootstrap`]: https://github.com/rust-lang/rust/tree/master/src/bootstrap +[`tidy`]: https://github.com/rust-lang/rust/tree/master/src/tools/tidy +[`compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest + +[bootstch]: ./building/bootstrapping.md + +## Other + +There are a lot of other things in the `rust-lang/rust` repo that are related +to building a full rust distribution. Most of the time you don't need to worry +about them. + +These include: +- [`src/ci`]: The CI configuration. This actually quite extensive because we + run a lot of tests on a lot of platforms. +- [`src/doc`]: Various documentation, including submodules for a few books. +- [`src/etc`]: Miscellaneous utilities. +- [`src/tools/rustc-workspace-hack`], and others: Various workarounds to make cargo work with bootstrapping. +- And more... + +[`src/ci`]: https://github.com/rust-lang/rust/tree/master/src/ci +[`src/doc`]: https://github.com/rust-lang/rust/tree/master/src/doc +[`src/etc`]: https://github.com/rust-lang/rust/tree/master/src/etc +[`src/tools/rustc-workspace-hack`]: https://github.com/rust-lang/rust/tree/master/src/tools/rustc-workspace-hack From 146635d7ff6c1be7bf2ee2dceb41bb45f734b76d Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 24 Jun 2020 12:38:44 -0500 Subject: [PATCH 1145/1812] line length --- src/compiler-src.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index efb9ae896..e0789e2a2 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -140,7 +140,8 @@ These include: run a lot of tests on a lot of platforms. - [`src/doc`]: Various documentation, including submodules for a few books. - [`src/etc`]: Miscellaneous utilities. -- [`src/tools/rustc-workspace-hack`], and others: Various workarounds to make cargo work with bootstrapping. +- [`src/tools/rustc-workspace-hack`], and others: Various workarounds to make + cargo work with bootstrapping. - And more... [`src/ci`]: https://github.com/rust-lang/rust/tree/master/src/ci From 041e86cb9597e2031d9c7aaa4cf4036198c44048 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 24 Jun 2020 13:24:40 -0500 Subject: [PATCH 1146/1812] fix typo --- src/compiler-src.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index e0789e2a2..27d656ead 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -53,14 +53,14 @@ something like this: - [`rustc_middle`] and most of the other crates depend on a handful of crates representing the early parts of the compiler (e.g. the parser), fundamental data structures (e.g. - [`Span`]), or error reporting: [`rustc_data_strucutres`], + [`Span`]), or error reporting: [`rustc_data_structures`], [`rustc_span`], [`rustc_errors`], etc. [main]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/fn.main.html [`rustc_driver`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/index.html [`rustc_interface`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/index.html [`rustc_middle`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/index.html -[`rustc_data_strucutres`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_strucutres/index.html +[`rustc_data_structures`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/index.html [`rustc_span`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/index.html [`Span`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html [`rustc_errors`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html From abd77148a404faecfe61ab4007a5c40785ea37df Mon Sep 17 00:00:00 2001 From: mark Date: Fri, 26 Jun 2020 19:59:46 -0500 Subject: [PATCH 1147/1812] add a bit more discussion of big picture --- src/compiler-src.md | 55 ++++++++++++++++++++++++++++++++++++++------- 1 file changed, 47 insertions(+), 8 deletions(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index 27d656ead..5d8c3ca04 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -68,20 +68,59 @@ something like this: You can see the exact dependencies by reading the `Cargo.toml` for the various crates, just like a normal Rust crate. -You may ask why the compiler is broken into so many crates. There are two major reasons: +One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM. + +Most of this book is about the compiler, so we won't have any further +explanation of these crates here. + +[`src/llvm-project`]: https://github.com/rust-lang/rust/tree/master/src + +### Big picture -1. Organization. The compiler is a _huge_ codebase; it would be an impossibly large crate. +The dependency structure is influenced strongly by two main factors: + +1. Organization. The compiler is a _huge_ codebase; it would be an impossibly + large crate. In part, the dependency structure reflects the code structure + of the compiler. 2. Compile time. By breaking the compiler into multiple crates, we can take better advantage of incremental/parallel compilation using cargo. In particular, we try to have as few dependencies between crates as possible so that we dont' have to rebuild as many crates if you change one. -Most of this book is about the compiler, so we won't have any further -explanation of these crates here. - -One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM. - -[`src/llvm-project`]: https://github.com/rust-lang/rust/tree/master/src +At the very bottom of the dependency tree are a handful of crates that are used +by the whole compiler (e.g. [`rustc_span`]). The very early parts of the +compilation process (e.g. parsing and the AST) depend on only these. + +Pretty soon after the AST is constructed, the compiler's [query system][query] +gets set up. The query system is set up in a clever way using function +pointers. This allows us to break dependencies between crates, allowing more +parallel compilation. + +However, since the query system is defined in [`rustc_middle`], nearly all +subsequent parts of the compiler depend on this crate. It is a really large +crate, leading to long compile times. Some efforts have been made to move stuff +out of it with limited success. Another unfortunate sideffect is that sometimes +related functionality gets scattered across different crates. For example, +linting functionality is scattered across earlier parts of the crate, +[`rustc_lint`], [`rustc_middle`], and other places. + +More generally, in an ideal world, it seems like there would be fewer, more +cohesive crates, with incremental and parallel compilation making sure compile +times stay reasonable. However, our incremental and parallel compilation haven't +gotten good enough for that yet, so breaking things into separate crates has +been our solution so far. + +At the top of the dependency tree are the [`rustc_interface`] and +[`rustc_driver`] crates. [`rustc_interface`] is an unstable wrapper around the +query system that helps to drive the various stages of compilation. Other +consumers of the compiler may use this interface in different ways (e.g. +rustdoc or maybe eventually rust-analyzer). The [`rustc_driver`] crate first +parses command line arguments and then uses [`rustc_interface`] to drive the +compilation to completion. + +[query]: ./query.md + +[orgch]: ./overview.md ## rustdoc From 0dab310a1bd95059d3afa1b7331c280857bd47ea Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 27 Jun 2020 11:07:25 -0500 Subject: [PATCH 1148/1812] missing link --- src/compiler-src.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/compiler-src.md b/src/compiler-src.md index 5d8c3ca04..fc7118734 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -104,6 +104,8 @@ related functionality gets scattered across different crates. For example, linting functionality is scattered across earlier parts of the crate, [`rustc_lint`], [`rustc_middle`], and other places. +[`rustc_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/index.html + More generally, in an ideal world, it seems like there would be fewer, more cohesive crates, with incremental and parallel compilation making sure compile times stay reasonable. However, our incremental and parallel compilation haven't From fc7b7a5723e8e3eccf3b2c1800352156d365a645 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Mon, 20 Jul 2020 19:34:11 -0500 Subject: [PATCH 1149/1812] Link to overview ch instead of internals Co-authored-by: Joshua Nelson --- src/compiler-src.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index fc7118734..67940d367 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -140,7 +140,7 @@ You can read more about rustdoc in [this chapter][rustdocch]. [`src/tools/rustdoc-js`]: https://github.com/rust-lang/rust/tree/master/src/tools/rustdoc-js [`src/tools/rustdoc-themes`]: https://github.com/rust-lang/rust/tree/master/src/tools/rustdoc-themes -[rustdocch]: ./rustdoc-internals.md +[rustdocch]: ./rustdoc.md ## Tests From 6f983169300c3e022b0dfb93f18099bd722bb75b Mon Sep 17 00:00:00 2001 From: mark Date: Mon, 20 Jul 2020 19:42:01 -0500 Subject: [PATCH 1150/1812] mention the overview chapter --- src/compiler-src.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/compiler-src.md b/src/compiler-src.md index 67940d367..a9d708f1a 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -5,6 +5,9 @@ > top-level directory has separate directories for the compiler, build-system, > std libs, etc, rather than one huge `src/` directory. +Now that we have [seen what the compiler does](./overview.md), let's take a +look at the structure of the contents of the rust-lang/rust repo. + ## Workspace structure The `rust-lang/rust` repository consists of a single large cargo workspace @@ -35,6 +38,10 @@ built in a special way because it can use unstable features. ## Compiler +> You may find it helpful to read [The Overview Chapter](./overview.md) first, +> which gives an overview of how the compiler works. The crates mentioned in +> this section implement the compiler. + The compiler crates all have names starting with `librustc_*`. These are a large collection of interdependent crates. There is also the `rustc` crate which is the actual binary. It doesn't actually do anything besides calling the compiler From 5756aa3ecff83d691395b5250b8edb50547fe1f8 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Fri, 24 Jul 2020 18:13:25 -0500 Subject: [PATCH 1151/1812] Typo Co-authored-by: Joshua Nelson --- src/compiler-src.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index a9d708f1a..a976701aa 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -106,7 +106,7 @@ parallel compilation. However, since the query system is defined in [`rustc_middle`], nearly all subsequent parts of the compiler depend on this crate. It is a really large crate, leading to long compile times. Some efforts have been made to move stuff -out of it with limited success. Another unfortunate sideffect is that sometimes +out of it with limited success. Another unfortunate side effect is that sometimes related functionality gets scattered across different crates. For example, linting functionality is scattered across earlier parts of the crate, [`rustc_lint`], [`rustc_middle`], and other places. From f8dfca5001c2a8acccc0737950fd8a146a0f101c Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 2 Aug 2020 18:45:03 -0500 Subject: [PATCH 1152/1812] some updates after std libs move --- src/compiler-src.md | 47 ++++++++++++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 18 deletions(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index a976701aa..55eea49e5 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -4,6 +4,9 @@ > transitions. In particular, we want to get to a point eventually where the > top-level directory has separate directories for the compiler, build-system, > std libs, etc, rather than one huge `src/` directory. +> +> As of this writing, the std libs have been moved to `library/` and there is +> an ongoing MCP to move the compiler to `compiler/`. Now that we have [seen what the compiler does](./overview.md), let's take a look at the structure of the contents of the rust-lang/rust repo. @@ -11,27 +14,25 @@ look at the structure of the contents of the rust-lang/rust repo. ## Workspace structure The `rust-lang/rust` repository consists of a single large cargo workspace -containing the compiler, the standard library (core, alloc, std, etc), and -`rustdoc`, along with the build system and bunch of tools and submodules for -building a full Rust distribution. +containing the compiler, the standard libraries (`core`, `alloc`, `std`, +`proc_macro`, etc), and `rustdoc`, along with the build system and bunch of +tools and submodules for building a full Rust distribution. As of this writing, this structure is gradually undergoing some transformation to make it a bit less monolithic and more approachable, especially to newcommers. -> Eventually, the hope is for the standard library to live in a `stdlib/` -> directory, while the compiler lives in `compiler/`. However, as of this -> writing, both live in `src/`. - The repository consists of a `src` directory, under which there live many -crates, which are the source for the compiler, standard library, etc, as -mentioned above. +crates, which are the source for the compiler, build system, tools, etc. This +directory is currently being broken up to be less monolithic. There is also a +`library/` directory, where the standard libraries (`core`, `alloc`, `std`, +`proc_macro`, etc) live. ## Standard library -The standard library crates are obviously named `libstd`, `libcore`, -`liballoc`, etc. There is also `libproc_macro`, `libtest`, and other runtime -libraries. +The standard library crates are all in `library/`. They have intuitive names +like `std`, `core`, `alloc`, etc. There is also `proc_macro`, `test`, and +other runtime libraries. This code is fairly similar to most other Rust crates except that it must be built in a special way because it can use unstable features. @@ -41,11 +42,16 @@ built in a special way because it can use unstable features. > You may find it helpful to read [The Overview Chapter](./overview.md) first, > which gives an overview of how the compiler works. The crates mentioned in > this section implement the compiler. +> +> NOTE: As of this writing, the crates all live in `src/`, but there is an MCP +> to move them to a new `compiler/` directory. -The compiler crates all have names starting with `librustc_*`. These are a large -collection of interdependent crates. There is also the `rustc` crate which is -the actual binary. It doesn't actually do anything besides calling the compiler -main function elsewhere. +The compiler crates all have names starting with `librustc_*`. These are a +collection of around 50 interdependent crates ranging in size from tiny to +huge. There is also the `rustc` crate which is the actual binary (i.e. the +`main` function); it doesn't actually do anything besides calling the +`rustc_driver` crate, which drives the various parts of compilation in other +crates. The dependency structure of these crates is complex, but roughly it is something like this: @@ -55,7 +61,7 @@ something like this: [`rustc_interface`]. - [`rustc_interface`] depends on most of the other compiler crates. It is a fairly generic interface for driving the whole compilation. - - The most of the other `rustc_*` crates depend on [`rustc_middle`], + - Most of the other `rustc_*` crates depend on [`rustc_middle`], which defines a lot of central data structures in the compiler. - [`rustc_middle`] and most of the other crates depend on a handful of crates representing the early parts of the @@ -75,12 +81,17 @@ something like this: You can see the exact dependencies by reading the `Cargo.toml` for the various crates, just like a normal Rust crate. -One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM. +One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM +During bootstrapping, LLVM is built and the [`src/librustc_llvm`] and +[`src/rustllvm`] crates contain rust wrappers around LLVM (which is written in +C++), so that the compiler can interface with it. Most of this book is about the compiler, so we won't have any further explanation of these crates here. [`src/llvm-project`]: https://github.com/rust-lang/rust/tree/master/src +[`src/librustc_llvm`]: https://github.com/rust-lang/rust/tree/master/src +[`src/rustllvm`]: https://github.com/rust-lang/rust/tree/master/src ### Big picture From cec6addcafa725640108dd8544524349e55fcdab Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 2 Aug 2020 19:38:20 -0500 Subject: [PATCH 1153/1812] Typo Co-authored-by: Joshua Nelson --- src/compiler-src.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index 55eea49e5..df8bc2bd1 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -103,7 +103,7 @@ The dependency structure is influenced strongly by two main factors: 2. Compile time. By breaking the compiler into multiple crates, we can take better advantage of incremental/parallel compilation using cargo. In particular, we try to have as few dependencies between crates as possible so - that we dont' have to rebuild as many crates if you change one. + that we don't have to rebuild as many crates if you change one. At the very bottom of the dependency tree are a handful of crates that are used by the whole compiler (e.g. [`rustc_span`]). The very early parts of the From e54d59ca743296d75fb59750fb24d36300f252bb Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 3 Aug 2020 10:14:27 +0900 Subject: [PATCH 1154/1812] Fix link/wording for `parse_nt` --- src/overview.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/overview.md b/src/overview.md index ec96d243f..9d8dfd908 100644 --- a/src/overview.md +++ b/src/overview.md @@ -42,7 +42,7 @@ we'll talk about that later. analysis. The crate entry points for the parser are the `Parser.parse_crate_mod()` and `Parser.parse_mod()` methods found in `librustc_parse::parser::item`. The external module parsing entry point is `librustc_expand::module::parse_external_mod`. And - the macro parser entry point is `rustc_expand::mbe::macro_parser::parse_nt`. + the macro parser entry point is [`Parser.parse_nonterminal()`][parse_nonterminal]. - Parsing is performed with a set of `Parser` utility methods including `fn bump`, `fn check`, `fn eat`, `fn expect`, `fn look_ahead`. - Parsing is organized by the semantic construct that is being parsed. Separate @@ -111,6 +111,7 @@ we'll talk about that later. [mir-opt]: https://rustc-dev-guide.rust-lang.org/mir/optimizations.html [`simplify_try`]: https://github.com/rust-lang/rust/pull/66282 [codegen]: https://rustc-dev-guide.rust-lang.org/backend/codegen.html +[parse_nonterminal]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html#method.parse_nonterminal ## How it does it @@ -347,7 +348,7 @@ For more details on bootstrapping, see - Main entry points: - [Entry point for first file in crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.parse.html) - [Entry point for outline module parsing](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/module/fn.parse_external_mod.html) - - [Entry point for macro fragments](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_nt.html) + - [Entry point for macro fragments][parse_nonterminal] - AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html) - Expansion: **TODO** - Name Resolution: **TODO** From 4e41d060c1f64e419c6702be861c20a5b5de437f Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 3 Aug 2020 11:53:26 +0900 Subject: [PATCH 1155/1812] Prefer `::` than `.` --- src/overview.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/overview.md b/src/overview.md index 9d8dfd908..e97fba6b9 100644 --- a/src/overview.md +++ b/src/overview.md @@ -38,11 +38,11 @@ we'll talk about that later. data which are emitted in `librustc_parse::lexer::mod` as real diagnostics. - The lexer preserves full fidelity information for both IDEs and proc macros. - The parser [translates the token stream from the lexer into an Abstract Syntax - Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax - analysis. The crate entry points for the parser are the `Parser.parse_crate_mod()` and - `Parser.parse_mod()` methods found in `librustc_parse::parser::item`. The external + Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax + analysis. The crate entry points for the parser are the `Parser::parse_crate_mod()` and + `Parser::parse_mod()` methods found in `librustc_parse::parser::item`. The external module parsing entry point is `librustc_expand::module::parse_external_mod`. And - the macro parser entry point is [`Parser.parse_nonterminal()`][parse_nonterminal]. + the macro parser entry point is [`Parser::parse_nonterminal()`][parse_nonterminal]. - Parsing is performed with a set of `Parser` utility methods including `fn bump`, `fn check`, `fn eat`, `fn expect`, `fn look_ahead`. - Parsing is organized by the semantic construct that is being parsed. Separate From f75a2fb9b1c3ad50b030376c8159f33324aad3cc Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 22:02:52 +0900 Subject: [PATCH 1156/1812] Fix examples not working --- examples/rustc-driver-example.rs | 1 - examples/rustc-driver-getting-diagnostics.rs | 1 - examples/rustc-driver-interacting-with-the-ast.rs | 3 +-- 3 files changed, 1 insertion(+), 4 deletions(-) diff --git a/examples/rustc-driver-example.rs b/examples/rustc-driver-example.rs index 4b0b23aaa..f01072b7b 100644 --- a/examples/rustc-driver-example.rs +++ b/examples/rustc-driver-example.rs @@ -3,7 +3,6 @@ // NOTE: For the example to compile, you will need to first run the following: // rustup component add rustc-dev -extern crate rustc; extern crate rustc_error_codes; extern crate rustc_errors; extern crate rustc_hash; diff --git a/examples/rustc-driver-getting-diagnostics.rs b/examples/rustc-driver-getting-diagnostics.rs index cf08ed87f..e1caab326 100644 --- a/examples/rustc-driver-getting-diagnostics.rs +++ b/examples/rustc-driver-getting-diagnostics.rs @@ -3,7 +3,6 @@ // NOTE: For the example to compile, you will need to first run the following: // rustup component add rustc-dev -extern crate rustc; extern crate rustc_error_codes; extern crate rustc_errors; extern crate rustc_hash; diff --git a/examples/rustc-driver-interacting-with-the-ast.rs b/examples/rustc-driver-interacting-with-the-ast.rs index 105ee0019..e33c2ee95 100644 --- a/examples/rustc-driver-interacting-with-the-ast.rs +++ b/examples/rustc-driver-interacting-with-the-ast.rs @@ -3,7 +3,6 @@ // NOTE: For the example to compile, you will need to first run the following: // rustup component add rustc-dev -extern crate rustc; extern crate rustc_error_codes; extern crate rustc_errors; extern crate rustc_hash; @@ -65,7 +64,7 @@ fn main() { if let Some(expr) = local.init { let hir_id = expr.hir_id; // hir_id identifies the string "Hello, world!" let def_id = tcx.hir().local_def_id(item.hir_id); // def_id identifies the main function - let ty = tcx.typeck_tables_of(def_id).node_type(hir_id); + let ty = tcx.typeck(def_id).node_type(hir_id); println!("{:?}: {:?}", expr, ty); // prints expr(HirId { owner: DefIndex(3), local_id: 4 }: "Hello, world!"): &'static str } } From 4db8160fa3e7401c46443c1665db9404b091bbbf Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 22:06:35 +0900 Subject: [PATCH 1157/1812] Avoid "whitelist" Fixed according to https://github.com/rust-lang/rust/commit/62cf767a4a39b47677d18110359d9e7152dc9d1c --- src/crates-io.md | 10 +++++----- src/stability.md | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/crates-io.md b/src/crates-io.md index 21dd00afe..17757454e 100644 --- a/src/crates-io.md +++ b/src/crates-io.md @@ -14,10 +14,10 @@ reasons: TODO: what is the vetting process? -## Whitelist +## Pemitted dependencies -The `tidy` tool has a [whitelist] of crates that are allowed. To add a -dependency that is not already in the compiler, you will need to add it to this -whitelist. +The `tidy` tool has [crates that are allowed]. To add a +dependency that is not already in the compiler, you will need to add it to these +crates. -[whitelist]: https://github.com/rust-lang/rust/blob/659994627234ce7d95a1a52ad8756ce661059adf/src/tools/tidy/src/deps.rs#L56 +[crates that are allowed]: https://github.com/rust-lang/rust/blob/19ecce332e56941ea0dd2a805270faa102acdb14/src/tools/tidy/src/deps.rs#L59 diff --git a/src/stability.md b/src/stability.md index f48c3d529..1160ee98d 100644 --- a/src/stability.md +++ b/src/stability.md @@ -76,11 +76,11 @@ Furthermore this attribute is needed to mark an intrinsic as callable from Macros, compiler desugarings and `const fn`s expose their bodies to the call site. To work around not being able to use unstable things in the standard library's macros, there's the `#[allow_internal_unstable(feature1, feature2)]` -attribute that whitelists the given features for usage in stable macros or +attribute that allows the given features for usage in stable macros or `const fn`s. Note that `const fn`s are even more special in this regard. You can't just -whitelist any feature, the features need an implementation in +allow any feature, the features need an implementation in `qualify_min_const_fn.rs`. For example the `const_fn_union` feature gate allows accessing fields of unions inside stable `const fn`s. The rules for when it's ok to use such a feature gate are that behavior matches the runtime behavior of From 2cc652be17b8525f4c6c89c517381075e16a164e Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 22:58:57 +0900 Subject: [PATCH 1158/1812] Fix: crates -> a list of crates --- src/crates-io.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/crates-io.md b/src/crates-io.md index 17757454e..9e94ba540 100644 --- a/src/crates-io.md +++ b/src/crates-io.md @@ -16,8 +16,8 @@ TODO: what is the vetting process? ## Pemitted dependencies -The `tidy` tool has [crates that are allowed]. To add a +The `tidy` tool has [a list of crates that are allowed]. To add a dependency that is not already in the compiler, you will need to add it to these crates. -[crates that are allowed]: https://github.com/rust-lang/rust/blob/19ecce332e56941ea0dd2a805270faa102acdb14/src/tools/tidy/src/deps.rs#L59 +[a list of crates that are allowed]: https://github.com/rust-lang/rust/blob/19ecce332e56941ea0dd2a805270faa102acdb14/src/tools/tidy/src/deps.rs#L59 From 04bd4ccd97d43cb7ee884fdf2d55f6cfeac64c81 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 23:03:59 +0900 Subject: [PATCH 1159/1812] Fix typo --- src/crates-io.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/crates-io.md b/src/crates-io.md index 9e94ba540..7333bd9b8 100644 --- a/src/crates-io.md +++ b/src/crates-io.md @@ -14,7 +14,7 @@ reasons: TODO: what is the vetting process? -## Pemitted dependencies +## Permitted dependencies The `tidy` tool has [a list of crates that are allowed]. To add a dependency that is not already in the compiler, you will need to add it to these From 44f1ab3bcf421b740bd8e2c8d9f214e2d05939a1 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Mon, 3 Aug 2020 23:32:19 +0900 Subject: [PATCH 1160/1812] Some small fixes --- src/crates-io.md | 3 +-- src/stability.md | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/src/crates-io.md b/src/crates-io.md index 7333bd9b8..6fbabdc91 100644 --- a/src/crates-io.md +++ b/src/crates-io.md @@ -17,7 +17,6 @@ TODO: what is the vetting process? ## Permitted dependencies The `tidy` tool has [a list of crates that are allowed]. To add a -dependency that is not already in the compiler, you will need to add it to these -crates. +dependency that is not already in the compiler, you will need to add it to the list. [a list of crates that are allowed]: https://github.com/rust-lang/rust/blob/19ecce332e56941ea0dd2a805270faa102acdb14/src/tools/tidy/src/deps.rs#L59 diff --git a/src/stability.md b/src/stability.md index 1160ee98d..9255f4b57 100644 --- a/src/stability.md +++ b/src/stability.md @@ -76,7 +76,7 @@ Furthermore this attribute is needed to mark an intrinsic as callable from Macros, compiler desugarings and `const fn`s expose their bodies to the call site. To work around not being able to use unstable things in the standard library's macros, there's the `#[allow_internal_unstable(feature1, feature2)]` -attribute that allows the given features for usage in stable macros or +attribute that allows the given features to be used in stable macros or `const fn`s. Note that `const fn`s are even more special in this regard. You can't just From ec373ae12ef030e435cdd70c8625cc3ead628c36 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 4 Aug 2020 22:20:38 +0900 Subject: [PATCH 1161/1812] Enable a link --- src/queries/incremental-compilation-in-detail.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index d8716acdf..a4e1cd92b 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -507,9 +507,10 @@ session. The overhead of doing so is a few percent of total compilation time. Data structures used as query results could be factored in a way that removes edges from the dependency graph. Especially "span" information is very volatile, so including it in query result will increase the chance that that result won't -be reusable. See https://github.com/rust-lang/rust/issues/47389 for more +be reusable. See [https://github.com/rust-lang/rust/issues/47389] for more information. [query-model]: ./query-evaluation-model-in-detail.html +[https://github.com/rust-lang/rust/issues/47389]: https://github.com/rust-lang/rust/issues/47389 From eb0522c4ac909bfce4f2e3ea56fad5fc62b32590 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 4 Aug 2020 22:21:19 +0900 Subject: [PATCH 1162/1812] Fix a broken link --- src/parallel-rustc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index add902d3a..0405a947a 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -18,7 +18,7 @@ There are a few basic ideas in this effort: thread-safe. A key strategy here has been converting interior-mutable data-structures (e.g. `Cell`) into their thread-safe siblings (e.g. `Mutex`). -[`rayon`]: https://crates.io/rayon +[`rayon`]: https://crates.io/crates/rayon As of this writing, much of this effort is on hold due to lack of manpower. We have a working prototype with promising performance gains in many cases. From f1cf48835da7142a3fb21f6cecf854cb4fbce12f Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 4 Aug 2020 22:26:06 +0900 Subject: [PATCH 1163/1812] Fix typo --- src/name-resolution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/name-resolution.md b/src/name-resolution.md index dfea5f22c..cc6eed7f8 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -13,7 +13,7 @@ resolve a name once, since no new names can be added. If we fail to resolve a name now, then it is a compiler error. Name resolution can be complex. There are a few different namespaces (e.g. -macros, values, types, lifetimes), and names my be valid at different (nested) +macros, values, types, lifetimes), and names may be valid at different (nested) scopes. Also, different types of names can fail to be resolved differently, and failures can happen differently at different scopes. For example, for a module scope, failure means no unexpanded macros and no unresolved glob imports in From cb51d0e1f0ad88863bceea0c7a8a7455f0801ab2 Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Tue, 4 Aug 2020 22:40:10 +0900 Subject: [PATCH 1164/1812] Use angle brackets to turn URL into a link --- src/queries/incremental-compilation-in-detail.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index a4e1cd92b..96255227f 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -507,10 +507,9 @@ session. The overhead of doing so is a few percent of total compilation time. Data structures used as query results could be factored in a way that removes edges from the dependency graph. Especially "span" information is very volatile, so including it in query result will increase the chance that that result won't -be reusable. See [https://github.com/rust-lang/rust/issues/47389] for more +be reusable. See for more information. [query-model]: ./query-evaluation-model-in-detail.html -[https://github.com/rust-lang/rust/issues/47389]: https://github.com/rust-lang/rust/issues/47389 From 4657fbcda70ed0d098a2192ea18c79f5cddf38fa Mon Sep 17 00:00:00 2001 From: Takayuki Nakata Date: Wed, 12 Aug 2020 08:36:48 +0900 Subject: [PATCH 1165/1812] Some small fixes (#823) * Fix some typos * Update from `typeck_tables_of` to `typeck` * Fix comment --- src/diagnostics.md | 2 +- src/diagnostics/diagnostic-codes.md | 2 +- src/overview.md | 2 +- src/queries/profiling.md | 2 +- src/rustc-driver-interacting-with-the-ast.md | 2 +- src/traits/hrtb.md | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 432ea8903..5ad2fbb32 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -58,7 +58,7 @@ multiple sentences are _needed_: error: the fobrulator needs to be krontrificated ``` -When code or an identifier must appear in an message or label, it should be +When code or an identifier must appear in a message or label, it should be surrounded with single acute accents \`. ### Error explanations diff --git a/src/diagnostics/diagnostic-codes.md b/src/diagnostics/diagnostic-codes.md index 0e923c5e1..e0d144bfc 100644 --- a/src/diagnostics/diagnostic-codes.md +++ b/src/diagnostics/diagnostic-codes.md @@ -1,5 +1,5 @@ # Diagnostic Codes -We generally try assign each error message a unique code like `E0123`. These +We generally try to assign each error message a unique code like `E0123`. These codes are defined in the compiler in the `diagnostics.rs` files found in each crate, which basically consist of macros. The codes come in two varieties: those that have an extended write-up, and those that do not. Whenever possible, if you diff --git a/src/overview.md b/src/overview.md index e97fba6b9..5bcf26911 100644 --- a/src/overview.md +++ b/src/overview.md @@ -367,7 +367,7 @@ For more details on bootstrapping, see - Guide: [Type Inference](https://rustc-dev-guide.rust-lang.org/type-inference.html) - Guide: [The ty Module: Representing Types](https://rustc-dev-guide.rust-lang.org/ty.html) (semantics) - Main entry point (type inference): [`InferCtxtBuilder::enter`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxtBuilder.html#method.enter) - - Main entry point (type checking bodies): [the `typeck_tables_of` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.typeck_tables_of) + - Main entry point (type checking bodies): [the `typeck` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.typeck) - These two functions can't be decoupled. - The Mid Level Intermediate Representation (MIR) - Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html) diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 8c6050da2..593d0b385 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -282,7 +282,7 @@ We explain each term in more detail: providers may nest; see [trace of queries](#trace-of-queries) for more information about this nesting structure. _Example providers:_ - - `typeck_tables_of` -- Typecheck a Def ID; produce "tables" of type + - `typeck` -- Typecheck a Def ID; produce "tables" of type information. - `borrowck` -- Borrow-check a Def ID. - `optimized_mir` -- Generate an optimized MIR for a Def ID; produce MIR. diff --git a/src/rustc-driver-interacting-with-the-ast.md b/src/rustc-driver-interacting-with-the-ast.md index 0cdc84393..21d03bbb7 100644 --- a/src/rustc-driver-interacting-with-the-ast.md +++ b/src/rustc-driver-interacting-with-the-ast.md @@ -32,7 +32,7 @@ rustc_interface::run_compiler(config, |compiler| { if let Some(expr) = local.init { let hir_id = expr.hir_id; // hir_id identifies the string "Hello, world!" let def_id = tcx.hir().local_def_id(item.hir_id); // def_id identifies the main function - let ty = tcx.typeck_tables_of(def_id).node_type(hir_id); + let ty = tcx.typeck(def_id).node_type(hir_id); println!("{:?}: {:?}", expr, ty); // prints expr(HirId { owner: DefIndex(3), local_id: 4 }: "Hello, world!"): &'static str } } diff --git a/src/traits/hrtb.md b/src/traits/hrtb.md index 81391f7ae..c0ca318e6 100644 --- a/src/traits/hrtb.md +++ b/src/traits/hrtb.md @@ -107,7 +107,7 @@ impl Foo for F } ``` -Now let's say we have a obligation `Baz: for<'a> Foo<&'a isize>` and we match +Now let's say we have an obligation `Baz: for<'a> Foo<&'a isize>` and we match this impl. What obligation is generated as a result? We want to get `Baz: for<'a> Bar<&'a isize>`, but how does that happen? From 6ff87f49baf9669ad3329f091fbbf34518f81ff1 Mon Sep 17 00:00:00 2001 From: Matthew Jasper Date: Sat, 4 Jul 2020 17:00:34 +0100 Subject: [PATCH 1166/1812] Document serialization in rustc --- src/SUMMARY.md | 1 + src/serialization.md | 164 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 165 insertions(+) create mode 100644 src/serialization.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 1fe7dcf11..70c34f2a6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -58,6 +58,7 @@ - [Profiling Queries](./queries/profiling.md) - [Salsa](./salsa.md) - [Memory Management in Rustc](./memory.md) +- [Serialization in Rustc](./serialization.md) - [Parallel Compilation](./parallel-rustc.md) - [Rustdoc](./rustdoc-internals.md) diff --git a/src/serialization.md b/src/serialization.md new file mode 100644 index 000000000..252dcf8ac --- /dev/null +++ b/src/serialization.md @@ -0,0 +1,164 @@ +# Serialization in Rustc + +Rustc has to [serialize] and deserialize various data during compilation. +Specifially: + +- "Crate metadata", mainly query outputs, are serialized in a binary + format into `rlib` and `rmeta` files that are output when compiling a library + crate, these are then deserialized by crates that depend on that library. +- Certain query outputs are serialized in a binary format to + [persist incremental compilation results]. +- The `-Z ast-json` and `-Z ast-json-noexpand` flags serialize the [AST] to json + and output the result to stdout. +- [`CrateInfo`] is serialized to json when the `-Z no-link` flag is used, and + deserialized from json when the `-Z link-only` flag is used. + +## The `Encodable` and `Decodable` traits + +The [`rustc_serialize`] crate defines two traits for types which can be serialized: + +```rust +pub trait Encodable { + fn encode(&self, s: &mut S) -> Result<(), S::Error>; +} + +pub trait Decodable: Sized { + fn decode(d: &mut D) -> Result; +} +``` + +It also defines implementations of these for integer types, floating point +types, `bool`, `char`, `str` and various common standard library types. + +For types that are constructed from those types, `Encodable` and `Decodable` are +usually implemented by [derives]. These generate implementations that forward +deserialization to the fields of the struct or enum. For a struct those impls +look something like this: + +```rust +# #![feature(rustc_private)] +# extern crate rustc_serialize; +# use rustc_serialize::{Decodable, Decoder, Encodable, Encoder}; + +struct MyStruct { + int: u32, + float: f32, +} + +impl Encodable for MyStruct { + fn encode(&self, s: &mut E) -> Result<(), E::Error> { + s.emit_struct("MyStruct", 2, |s| { + s.emit_struct_field("int", 0, |s| self.int.encode(s))?; + s.emit_struct_field("float", 1, |s| self.float.encode(s)) + }) + } +} +impl Decodable for MyStruct { + fn decode(s: &mut D) -> Result { + s.read_struct("MyStruct", 2, |d| { + let int = d.read_struct_field("int", 0, Decodable::decode)?; + let float = d.read_struct_field("float", 1, Decodable::decode)?; + + Ok(MyStruct::new(int, float, SyntaxContext::root())) + }) + } +} +``` + +## Encoding and Decoding arena allocated types + +Rustc has a lot of [arena allocated types]. Deserializing these types isn't +possible without access to the arena that they need to be allocated on. The +[`TyDecoder`] and [`TyEncoder`] traits are supertraits of `Decoder` and +`Encoder` that allow access to a `TyCtxt`. + +Types which contain arena allocated types can then bound the type parameter of +their `Encodable` and `Decodable` implementations with these traits. For +example + +```rust,ignore +impl<'tcx, D: TyDecoder<'tcx>> Decodable for MyStruct<'tcx> { + /* ... */ +} +``` + +The `TyEncodable` and `TyDecodable` [derive macros](derives) will expand to such +an implementation. + +Decoding the actual arena allocated type is harder, because some of the +implementations can't be written due to the orphan rules. To work around this, +the [`RefDecodable`] trait is defined in `rustc_middle`. This can then be +implemented for any type. The `TyDecodable` macro will call `RefDecodable` to +decode references, but various generic code needs types to actually be +`Decodable` with a specific decoder. + +For interned types instead of manually implementing `RefDecodable`, using a new +type wrapper, like `ty::Predicate` and manually implementing `Encodable` and +`Decodable` may be simpler. + +## Derive macros + +The `rustc_macros` crate defines various derives to help implement `Decodable` +and `Encodable`. + +- The `Encodable` and `Decodable` macros generate implementations that apply to + all `Encoders` and `Decoders`. These should be used in crates that don't + depend on `rustc_middle`, or that have to be serialized by a type that does + not implement `TyEncoder`. +- `MetadataEncodable` and `MetadataDecodable` generate implementations that + only allow decoding by [`rustc_metadata::rmeta::encoder::EncodeContext`] and + [`rustc_metadata::rmeta::decoder::DecodeContext`]. These are used for types + that contain `rustc_metadata::rmeta::Lazy`. +- `TyEncodable` and `TyDecoder` generate implementation that apply to any + `TyEncoder` or `TyDecoder`. These should be used for types that are only + serialized in crate metadata and/or the incremental cache, which is most + serializable types in `rustc_middle`. + +## Shorthands + +`Ty` can be deeply recursive, if each `Ty` was encoded naively then crate +metadata would be very large. To handle this, each `TyEncoder` has a cache of +locations in its output where it has serialized types. If a type being encoded +is in the cache, then instead of serializing the type as usual, the byte offset +within the file being written is encoded instead. A similar scheme is used for +`ty::Predicate`. + +## `Lazy` + +Crate metadata is initially loaded before the `TyCtxt<'tcx>` is created, so +some deserialization needs to be deferred from the initial loading of metadata. +The [`Lazy`] type wraps the (relative) offset in the crate metadata where a +`T` has been serialized. + +The `Lazy<[T]>` and `Lazy>` type provide some functionality over +`Lazy>` and `Lazy>`: + +- It's possible to encode a `Lazy<[T]>` directly from an iterator, without + first collecting into a `Vec`. +- Indexing into a `Lazy>` does not require decoding entries other + than the one being read. + +**note**: `Lazy` does not cache its value after being deserialized the first +time. Instead the query system is the main way of caching these results. + +## Specialization + +A few types, most notably `DefId`, need to have different implementations for +different `Encoder`s. This is currently handled by ad-hoc specializations: +`DefId` has a `default` implementation of `Encodable` and a specialized one +for `Encodable`. + +[arena allocated types]: memory.md +[AST]: the-parser.md +[derives]: #derive-macros +[persist incremental compilation results]: queries/incremental-compilation-in-detail.md#the-real-world-how-persistence-makes-everything-complicated +[serialize]: https://en.wikipedia.org/wiki/Serialization + +[`CrateInfo`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/struct.CrateInfo.html +[`Lazy`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/struct.Lazy.html +[`RefDecodable`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/codec/trait.RefDecodable.html +[`rustc_metadata::rmeta::decoder::DecodeContext`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/decoder/struct.DecodeContext.html +[`rustc_metadata::rmeta::encoder::EncodeContext`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/encoder/struct.EncodeContext.html +[`rustc_serialize`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_serialize/index.html +[`TyDecoder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/codec/trait.TyEncoder.html +[`TyEncoder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/codec/trait.TyDecoder.html From f08527cc4b62e2c2012e14a568b25fb0147dd3f5 Mon Sep 17 00:00:00 2001 From: Matthew Jasper Date: Sun, 16 Aug 2020 11:37:48 +0100 Subject: [PATCH 1167/1812] Address revuew comments --- src/serialization.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/serialization.md b/src/serialization.md index 252dcf8ac..292ffc546 100644 --- a/src/serialization.md +++ b/src/serialization.md @@ -1,7 +1,7 @@ # Serialization in Rustc Rustc has to [serialize] and deserialize various data during compilation. -Specifially: +Specifically: - "Crate metadata", mainly query outputs, are serialized in a binary format into `rlib` and `rmeta` files that are output when compiling a library @@ -17,7 +17,7 @@ Specifially: The [`rustc_serialize`] crate defines two traits for types which can be serialized: -```rust +```rust,ignore pub trait Encodable { fn encode(&self, s: &mut S) -> Result<(), S::Error>; } @@ -35,7 +35,7 @@ usually implemented by [derives]. These generate implementations that forward deserialization to the fields of the struct or enum. For a struct those impls look something like this: -```rust +```rust,ingore # #![feature(rustc_private)] # extern crate rustc_serialize; # use rustc_serialize::{Decodable, Decoder, Encodable, Encoder}; @@ -59,7 +59,7 @@ impl Decodable for MyStruct { let int = d.read_struct_field("int", 0, Decodable::decode)?; let float = d.read_struct_field("float", 1, Decodable::decode)?; - Ok(MyStruct::new(int, float, SyntaxContext::root())) + Ok(MyStruct { int, float }) }) } } @@ -82,7 +82,7 @@ impl<'tcx, D: TyDecoder<'tcx>> Decodable for MyStruct<'tcx> { } ``` -The `TyEncodable` and `TyDecodable` [derive macros](derives) will expand to such +The `TyEncodable` and `TyDecodable` [derive macros][derives] will expand to such an implementation. Decoding the actual arena allocated type is harder, because some of the From 3dcd4e393f9aeb5592a885d0912b6fb4321b9324 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 16 Aug 2020 14:51:37 -0500 Subject: [PATCH 1168/1812] Remove unneeded hashmarks (#826) Co-authored-by: Joshua Nelson --- src/serialization.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/serialization.md b/src/serialization.md index 292ffc546..d28df6ec1 100644 --- a/src/serialization.md +++ b/src/serialization.md @@ -35,10 +35,10 @@ usually implemented by [derives]. These generate implementations that forward deserialization to the fields of the struct or enum. For a struct those impls look something like this: -```rust,ingore -# #![feature(rustc_private)] -# extern crate rustc_serialize; -# use rustc_serialize::{Decodable, Decoder, Encodable, Encoder}; +```rust,ignore +#![feature(rustc_private)] +extern crate rustc_serialize; +use rustc_serialize::{Decodable, Decoder, Encodable, Encoder}; struct MyStruct { int: u32, From 6a59d0df34c03fcf411f5054a34cab3dcc3680ea Mon Sep 17 00:00:00 2001 From: Lzu Tao Date: Mon, 17 Aug 2020 19:51:38 +0700 Subject: [PATCH 1169/1812] Link ref to edge concept in graph theory --- src/queries/incremental-compilation.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/queries/incremental-compilation.md b/src/queries/incremental-compilation.md index 210d5b391..c8e7d4d7c 100644 --- a/src/queries/incremental-compilation.md +++ b/src/queries/incremental-compilation.md @@ -12,7 +12,7 @@ called the **red-green** algorithm[^salsa]. The high-level idea is that, after each run of the compiler, we will save the results of all the queries that we do, as well as the **query DAG**. The **query DAG** is a [DAG] that indexes which queries executed which -other queries. So, for example, there would be an edge from a query Q1 +other queries. So, for example, there would be an [edge] from a query Q1 to another query Q2 if computing Q1 required computing Q2 (note that because queries cannot depend on themselves, this results in a DAG and not a general graph). @@ -145,4 +145,5 @@ for this system. [^salsa]: I have long wanted to rename it to the Salsa algorithm, but it never caught on. -@nikomatsakis +[edge]: https://en.wikipedia.org/wiki/Glossary_of_graph_theory_terms#edge [initial-design]: https://github.com/nikomatsakis/rustc-on-demand-incremental-design-doc/blob/master/0000-rustc-on-demand-and-incremental.md From 75aa32f7b4bccace71ad78a3ad446b102eb5b853 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Mon, 17 Aug 2020 16:10:29 +0200 Subject: [PATCH 1170/1812] Document how to use build task for x.py check (#828) --- src/building/suggested.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/src/building/suggested.md b/src/building/suggested.md index 08858507f..0cc91b403 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -28,6 +28,28 @@ you can write: in your `.vscode/settings.json` file. This will ask `rust-analyzer` to use `x.py check` to check the sources, and the stage 0 rustfmt to format them. +If running `x.py check` on save is inconvenient, in VS Code you can use a [Build +Task] instead: + +```JSON +// .vscode/tasks.json +{ + "version": "2.0.0", + "tasks": [ + { + "label": "./x.py check", + "command": "./x.py check", + "type": "shell", + "problemMatcher": "$rustc", + "presentation": { "clear": true }, + "group": { "kind": "build", "isDefault": true } + } + ] +} +``` + +[Build Task]: https://code.visualstudio.com/docs/editor/tasks + ## Check, check, and check again When doing simple refactorings, it can be useful to run `./x.py check` From 76d7b6ac7078ce8fa609d168ec8f79e23de1c062 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 19 Aug 2020 20:46:02 +0900 Subject: [PATCH 1171/1812] Remove duplicate MIR chapter entry (#830) --- src/SUMMARY.md | 5 ++--- src/part-5-intro.md | 6 ++++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 70c34f2a6..edf97c6db 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -129,9 +129,8 @@ # MIR to Binaries - [Prologue](./part-5-intro.md) -- [The MIR (Mid-level IR)](./mir/index.md) - - [MIR optimizations](./mir/optimizations.md) - - [Debugging](./mir/debugging.md) +- [MIR optimizations](./mir/optimizations.md) +- [Debugging](./mir/debugging.md) - [Constant evaluation](./const-eval.md) - [miri const evaluator](./miri.md) - [Monomorphization](./backend/monomorph.md) diff --git a/src/part-5-intro.md b/src/part-5-intro.md index 184d0ee3a..82663b562 100644 --- a/src/part-5-intro.md +++ b/src/part-5-intro.md @@ -5,14 +5,16 @@ generated any executable machine code at all! With this chapter, all of that changes. So far, we've shown how the compiler can take raw source code in text format -and transform it into MIR. We have also shown how the compiler does various +and transform it into [MIR]. We have also shown how the compiler does various analyses on the code to detect things like type or lifetime errors. Now, we will finally take the MIR and produce some executable machine code. +[MIR]: ./mir/index.html + > NOTE: This part of a compiler is often called the _backend_ the term is a bit > overloaded because in the compiler source, it usually refers to the "codegen > backend" (i.e. LLVM or Cranelift). Usually, when you see the word "backend" -> in this part, we are refering to the "codegen backend". +> in this part, we are referring to the "codegen backend". So what do we need to do? From 844361cb78226f2f6e084f7e04e060a164d18c0f Mon Sep 17 00:00:00 2001 From: Gurwinder Singh Date: Fri, 21 Aug 2020 15:24:59 +0530 Subject: [PATCH 1172/1812] fix type in example (#832) Because the below explanation says that function type is `fn(u32) -> u32` --- src/ty.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ty.md b/src/ty.md index d1e2750c1..49f6405fa 100644 --- a/src/ty.md +++ b/src/ty.md @@ -92,7 +92,7 @@ Here is one more example: ```rust mod a { type X = u32; - pub fn foo(x: X) -> i32 { 22 } + pub fn foo(x: X) -> u32 { 22 } } mod b { type X = i32; From 401abb9bdf11d8db78581c5bef36c7c35876e185 Mon Sep 17 00:00:00 2001 From: Guillaume Gomez Date: Sun, 23 Aug 2020 14:36:45 +0200 Subject: [PATCH 1173/1812] Add new section to have a local HTTP server easily (#833) --- src/rustdoc-internals.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index d44e6679b..f9c37ecd4 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -192,3 +192,19 @@ runtime. These tests don't have as thorough of a writeup, but a broad example that features results in all tabs can be found in `basic.js`. The basic idea is that you match a given `QUERY` with a set of `EXPECTED` results, complete with the full item path of each item. + +## Testing locally + +Some features of the generated HTML documentation might require local +storage to be used across pages, which doesn't work well without an HTTP +server. To test these features locally, you can run a local HTTP server, like +this: + +```bash +$ ./x.py doc library/std --stage 1 +# The documentation has been generated into `build/[YOUR ARCH]/doc`. +$ python3 -m http.server -d build/[YOUR ARCH]/doc +``` + +Now you can browse your documentation just like you would if it was hosted +on the internet. For example, the url for `std` will be `/std/". From 92499eadd4e6dc17d14277c65032af338364333b Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 22 Aug 2020 18:51:53 -0700 Subject: [PATCH 1174/1812] Clarify section on MIR construction --- src/mir/construction.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 7fe9ee884..2d5eef6d0 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -3,10 +3,10 @@ The lowering of [HIR] to [MIR] occurs for the following (probably incomplete) list of items: -* Function and Closure bodies +* Function and closure bodies * Initializers of `static` and `const` items * Initializers of enum discriminants -* Glue and Shims of any kind +* Glue and shims of any kind * Tuple struct initializer functions * Drop code (the `Drop::drop` function is not called directly) * Drop implementations of types without an explicit `Drop` implementation @@ -20,9 +20,10 @@ without explicit syntax) like coercions, autoderef, autoref and overloaded metho calls have become explicit casts, deref operations, reference expressions or concrete function calls. -The [THIR] has datatypes that mirror the [HIR] datatypes, but instead of e.g. `-x` -being a `thir::ExprKind::Neg(thir::Expr)` it is a `thir::ExprKind::Neg(hir::Expr)`. -This shallowness enables the `THIR` to represent all datatypes that [HIR] has, but +The [THIR] has datatypes that mirror the [HIR] datatypes, but the [THIR] is a shallow +wrapper around [HIR]. For example, instead of `-x` being a `thir::ExprKind::Neg(thir::Expr)` +(a deep copy), it is a `thir::ExprKind::Neg(hir::Expr)` (a shallow copy). +This shallowness enables the [THIR] to represent all datatypes that [HIR] has, but without having to create an in-memory copy of the entire [HIR]. [MIR] lowering will first convert the topmost expression from [HIR] to [THIR] (in [`rustc_mir_build::thir::cx::expr`]) and then process From 7e3fe0a96139e61b81331cd9416ba63c1f09cda3 Mon Sep 17 00:00:00 2001 From: Camelid <37223377+camelid@users.noreply.github.com> Date: Sat, 22 Aug 2020 18:59:23 -0700 Subject: [PATCH 1175/1812] Apply review suggestion Co-authored-by: Joshua Nelson --- src/mir/construction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 2d5eef6d0..50545f776 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -20,8 +20,8 @@ without explicit syntax) like coercions, autoderef, autoref and overloaded metho calls have become explicit casts, deref operations, reference expressions or concrete function calls. -The [THIR] has datatypes that mirror the [HIR] datatypes, but the [THIR] is a shallow -wrapper around [HIR]. For example, instead of `-x` being a `thir::ExprKind::Neg(thir::Expr)` +The [THIR] is a shallow wrapper around [HIR], with datatypes that mirror the [HIR] datatypes. +For example, instead of `-x` being a `thir::ExprKind::Neg(thir::Expr)` (a deep copy), it is a `thir::ExprKind::Neg(hir::Expr)` (a shallow copy). This shallowness enables the [THIR] to represent all datatypes that [HIR] has, but without having to create an in-memory copy of the entire [HIR]. From 76efc9b91f629d32464e7bfc1d7afc101106eae1 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 26 Aug 2020 13:19:07 +0200 Subject: [PATCH 1176/1812] nits --- src/mir/construction.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mir/construction.md b/src/mir/construction.md index 50545f776..010305556 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -13,7 +13,7 @@ list of items: The lowering is triggered by calling the [`mir_built`] query. There is an intermediate representation -between [HIR] and [MIR] called the [THIR] that is only used during the lowering. +between [HIR] and [MIR] called the [THIR] that is only used during lowering. [THIR] means "Typed HIR" and used to be called "HAIR (High-level Abstract IR)". The [THIR]'s most important feature is that the various adjustments (which happen without explicit syntax) like coercions, autoderef, autoref and overloaded method @@ -30,8 +30,8 @@ without having to create an in-memory copy of the entire [HIR]. the [THIR] expressions recursively. The lowering creates local variables for every argument as specified in the signature. -Next it creates local variables for every binding specified (e.g. `(a, b): (i32, String)`) -produces 3 bindings, one for the argument, and two for the bindings. Next it generates +Next, it creates local variables for every binding specified (e.g. `(a, b): (i32, String)`) +produces 3 bindings, one for the argument, and two for the bindings. Next, it generates field accesses that read the fields from the argument and writes the value to the binding variable. From 9bb3872dc742e1d403841460feba53d62310330a Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 30 Aug 2020 14:35:45 -0500 Subject: [PATCH 1177/1812] fix links and names after compiler mv to compiler/ --- src/appendix/code-index.md | 46 +++++++++---------- src/appendix/glossary.md | 4 +- src/backend/backend-agnostic.md | 2 +- src/backend/codegen.md | 4 +- src/backend/lowering-mir.md | 12 ++--- src/borrow_check/region_inference.md | 2 +- src/bug-fix-procedure.md | 12 ++--- src/building/bootstrapping.md | 2 +- src/building/how-to-build-and-run.md | 6 +-- src/building/new-target.md | 4 +- src/closure.md | 10 ++-- src/compiler-debugging.md | 32 ++++++------- src/compiler-src.md | 2 +- src/diagnostics.md | 16 +++---- src/diagnostics/diagnostic-codes.md | 2 +- src/diagnostics/lintstore.md | 2 +- src/implementing_new_features.md | 2 +- src/lowering.md | 2 +- src/macro-expansion.md | 14 +++--- src/mir/index.md | 11 ++--- src/miri.md | 8 ++-- src/name-resolution.md | 2 +- src/overview.md | 30 ++++++------ src/panic-implementation.md | 6 +-- .../incremental-compilation-in-detail.md | 2 +- src/queries/incremental-compilation.md | 4 +- src/queries/profiling.md | 2 +- src/query.md | 6 +-- src/stabilization_guide.md | 6 +-- src/test-implementation.md | 10 ++-- src/the-parser.md | 12 ++--- src/traits/chalk.md | 2 +- src/traits/goals-and-clauses.md | 4 +- src/ty-fold.md | 2 +- src/type-checking.md | 8 ++-- 35 files changed, 145 insertions(+), 146 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 8561efe4c..9046cab13 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -6,30 +6,30 @@ compiler. Item | Kind | Short description | Chapter | Declaration ----------------|----------|-----------------------------|--------------------|------------------- -`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html) -`Compiler` | struct | Represents a compiler session and can be used to drive a compilation. | [The Rustc Driver and Interface] | [src/librustc_interface/interface.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html) -`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [src/librustc_ast/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Crate.html) -`rustc_hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [src/librustc_hir/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html) -`DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html) -`DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [src/librustc_errors/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) +`BodyId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html) +`Compiler` | struct | Represents a compiler session and can be used to drive a compilation. | [The Rustc Driver and Interface] | [compiler/rustc_interface/src/interface.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Compiler.html) +`ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [compiler/rustc_ast/src/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Crate.html) +`rustc_hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [compiler/rustc_hir/src/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html) +`DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html) +`DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [compiler/rustc_errors/src/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_err.rs/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) -`HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [src/librustc_hir/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html) -`NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [src/librustc_ast/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html) -`P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [src/librustc_ast/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ptr/struct.P.html) -`ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html) -`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [src/librustc_session/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html) -`Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [src/librustc_interface/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) -`Rib` | struct | Represents a single scope of names | [Name resolution] | [src/librustc_resolve/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) -`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [src/librustc_middle/session/mod.html](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) -`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [src/librustc_span/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html) -`SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [src/librustc_span/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html) -`Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [src/librustc_span/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html) -`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [src/librustc_parse/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html) -`rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [src/librustc_ast/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) -`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [src/librustc_middle/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html) -`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses] | [src/librustc_middle/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html) -`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc_middle/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html) -`TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc_middle/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html) +`HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html) +`NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [compiler/rustc_ast/src/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html) +`P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [compiler/rustc_ast/src/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ptr/struct.P.html) +`ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [compiler/rustc_middle/src/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html) +`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [compiler/rustc_session/src/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.P.rseSess.html) +`Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [compiler/rustc_interface/src/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) +`Rib` | struct | Represents a single scope of names | [Name resolution] | [compiler/rustc_resolve/src/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) +`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [compiler/rustc_middle/src/session/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) +`SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [compiler/rustc_span/src/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html) +`SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [compiler/rustc_span/src/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html) +`Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [compiler/rustc_span/src/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html) +`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [compiler/rustc_parse/src/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_p.rse/lexer/struct.StringReader.html) +`rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [compiler/rustc_ast/src/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) +`TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [compiler/rustc_middle/src/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html) +`TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses] | [compiler/rustc_middle/src/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html) +`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [compiler/rustc_middle/src/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html) +`TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [compiler/rustc_middle/src/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html) [The HIR]: ../hir.html [Identifiers in the HIR]: ../hir.html#hir-id diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 748f4feb5..007edce8d 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -16,7 +16,7 @@ cx
| We tend to use "cx" as an abbreviati DAG
| A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) data-flow analysis
| A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). DeBruijn Index
| A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) -DefId
| An index identifying a definition (see `librustc_middle/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +DefId
| An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). Discriminant
| The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). Double pointer
| A pointer with additional metadata. See "fat pointer" for more. drop glue
| (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. @@ -31,7 +31,7 @@ HirId
| Identifies a particular node in the HIR Map
| The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. ICE
| Short for internal compiler error, this is when the compiler crashes. ICH
| Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. -infcx
| The inference context (see `librustc_middle/infer`) +infcx
| The inference context (see `rustc_middle/src/infer`) inference variable
| When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. intern
| Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. intrinsic
| Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html)) diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md index 07914b847..e1eeb9a7f 100644 --- a/src/backend/backend-agnostic.md +++ b/src/backend/backend-agnostic.md @@ -1,7 +1,7 @@ # Backend Agnostic Codegen In the future, it would be nice to allow other codegen backends (e.g. -[Cranelift]). To this end, `librustc_codegen_ssa` provides an +[Cranelift]). To this end, `rustc_codegen_ssa` provides an abstract interface for all backends to implement. [Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/HEAD/cranelift diff --git a/src/backend/codegen.md b/src/backend/codegen.md index 5db9b2b05..8e18ca242 100644 --- a/src/backend/codegen.md +++ b/src/backend/codegen.md @@ -63,8 +63,8 @@ before objects are passed on to the linker and some to happen during the linking. This all happens towards the very end of compilation. The code for this can be -found in [`librustc_codegen_ssa::back`][ssaback] and -[`librustc_codegen_llvm::back`][llvmback]. Sadly, this piece of code is not +found in [`rustc_codegen_ssa::back`][ssaback] and +[`rustc_codegen_llvm::back`][llvmback]. Sadly, this piece of code is not really well-separated into LLVM-dependent code; the [`rustc_codegen_ssa`][ssa] contains a fair amount of code specific to the LLVM backend. diff --git a/src/backend/lowering-mir.md b/src/backend/lowering-mir.md index 2ab15e6f8..8b9dbe7ce 100644 --- a/src/backend/lowering-mir.md +++ b/src/backend/lowering-mir.md @@ -15,14 +15,14 @@ MIR to LLVM IR. The code is split into modules which handle particular MIR primitives: -- [`librustc_codegen_ssa::mir::block`][mirblk] will deal with translating +- [`rustc_codegen_ssa::mir::block`][mirblk] will deal with translating blocks and their terminators. The most complicated and also the most interesting thing this module does is generating code for function calls, including the necessary unwinding handling IR. -- [`librustc_codegen_ssa::mir::statement`][mirst] translates MIR statements. -- [`librustc_codegen_ssa::mir::operand`][mirop] translates MIR operands. -- [`librustc_codegen_ssa::mir::place`][mirpl] translates MIR place references. -- [`librustc_codegen_ssa::mir::rvalue`][mirrv] translates MIR r-values. +- [`rustc_codegen_ssa::mir::statement`][mirst] translates MIR statements. +- [`rustc_codegen_ssa::mir::operand`][mirop] translates MIR operands. +- [`rustc_codegen_ssa::mir::place`][mirpl] translates MIR place references. +- [`rustc_codegen_ssa::mir::rvalue`][mirrv] translates MIR r-values. [mirblk]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/block/index.html [mirst]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/statement/index.html @@ -49,7 +49,7 @@ and can be found in [`rustc_codegen_llvm::intrinsic`][llvmint]. [llvmint]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/intrinsic/index.html Everything else will use the [builder interface][builder]. This is the code that gets -called in the [`librustc_codegen_ssa::mir::*`][ssamir] modules discussed above. +called in the [`rustc_codegen_ssa::mir::*`][ssamir] modules discussed above. [builder]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/builder/index.html [ssamir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/index.html diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index 3b844b97c..d8cfab00c 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -82,7 +82,7 @@ maintain a set storing what elements are present in its value (to make this efficient, we give each kind of element an index, the `RegionElementIndex`, and use sparse bitsets). -[ri]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir/borrow_check/region_infer/ +[ri]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir/src/borrow_check/region_infer/ The kinds of region elements are as follows: diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md index b4159097c..69732b627 100644 --- a/src/bug-fix-procedure.md +++ b/src/bug-fix-procedure.md @@ -65,7 +65,7 @@ described in more detail below): 1. Once the change has been in the wild for at least one cycle, we can **stabilize the change**, converting those warnings into errors. -Finally, for changes to `librustc_ast` that will affect plugins, the general policy +Finally, for changes to `rustc_ast` that will affect plugins, the general policy is to batch these changes. That is discussed below in more detail. ### Tracking issue @@ -120,7 +120,7 @@ future-compatibility warnings. These are a special category of lint warning. Adding a new future-compatibility warning can be done as follows. ```rust -// 1. Define the lint in `src/librustc/lint/builtin.rs`: +// 1. Define the lint in `compiler/rustc_middle/src/lint/builtin.rs`: declare_lint! { pub YOUR_ERROR_HERE, Warn, @@ -137,7 +137,7 @@ impl LintPass for HardwiredLints { } } -// 3. Register the lint in `src/librustc_lint/lib.rs`: +// 3. Register the lint in `compiler/rustc_lint/src/lib.rs`: store.register_future_incompatible(sess, vec![ ..., FutureIncompatibleInfo { @@ -235,7 +235,7 @@ automatically generates the lower-case string; so searching for #### Remove the lint. The first reference you will likely find is the lint definition [in -`librustc/lint/builtin.rs` that resembles this][defsource]: +`rustc_session/src/lint/builtin.rs` that resembles this][defsource]: [defsource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L171-L175 @@ -254,7 +254,7 @@ the file as [part of a `lint_array!`][lintarraysource]; remove it too, [lintarraysource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L252-L290 Next, you see see [a reference to `OVERLAPPING_INHERENT_IMPLS` in -`librustc_lint/lib.rs`][futuresource]. This defining the lint as a "future +`rustc_lint/src/lib.rs`][futuresource]. This defining the lint as a "future compatibility lint": ```rust @@ -268,7 +268,7 @@ Remove this too. #### Add the lint to the list of removed lists. -In `src/librustc_lint/lib.rs` there is a list of "renamed and removed lints". +In `compiler/rustc_lint/src/lib.rs` there is a list of "renamed and removed lints". You can add this lint to the list: ```rust diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index a2eeb6029..d2384f9fc 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -259,7 +259,7 @@ thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', library/core/sr If `./stageN/bin/rustc` gives an error about environment variables, that usually means something is quite wrong -- or you're trying to compile e.g. -`librustc` or `std` or something that depends on environment variables. In +`rustc` or `std` or something that depends on environment variables. In the unlikely case that you actually need to invoke rustc in such a situation, you can find the environment variable values by adding the following flag to your `x.py` command: `--on-fail=print-env`. diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 29d10edd0..f2f87e1d6 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -183,7 +183,7 @@ This may *look* like it only builds `std`, but that is not the case. What this command does is the following: - Build `std` using the stage0 compiler (using incremental) -- Build `librustc` using the stage0 compiler (using incremental) +- Build `rustc` using the stage0 compiler (using incremental) - This produces the stage1 compiler - Build `std` using the stage1 compiler (cannot use incremental) @@ -207,9 +207,9 @@ workflows"](./suggested.md) below. Note that this whole command just gives you a subset of the full `rustc` build. The **full** `rustc` build (what you get if you say `./x.py build ---stage 2 src/rustc`) has quite a few more steps: +--stage 2 compiler/rustc`) has quite a few more steps: -- Build `librustc` and `rustc` with the stage1 compiler. +- Build `rustc` with the stage1 compiler. - The resulting compiler here is called the "stage2" compiler. - Build `std` with stage2 compiler. - Build `librustdoc` and a bunch of other things with the stage2 compiler. diff --git a/src/building/new-target.md b/src/building/new-target.md index eea01e9cc..24d47edad 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -48,7 +48,7 @@ somewhat successfully, you can copy the specification into the compiler itself. You will need to add a line to the big table inside of the -`supported_targets` macro in the `librustc_target::spec` module. You +`supported_targets` macro in the `rustc_target::spec` module. You will then add a corresponding file for your new target containing a `target` function. @@ -94,7 +94,7 @@ cross-compile `rustc`: ``` DESTDIR=/path/to/install/in \ ./x.py install -i --stage 1 --host aarch64-apple-darwin.json --target aarch64-apple-darwin \ -src/librustc library/std +compiler/rustc library/std ``` If your target specification is already available in the bootstrap diff --git a/src/closure.md b/src/closure.md index 0f9b13965..3a7a10f5c 100644 --- a/src/closure.md +++ b/src/closure.md @@ -115,7 +115,7 @@ Let's start with defining a term that we will be using quite a bit in the rest o *upvar*. An **upvar** is a variable that is local to the function where the closure is defined. So, in the above examples, **x** will be an upvar to the closure. They are also sometimes referred to as the *free variables* meaning they are not bound to the context of the closure. -[`src/librustc_middle/ty/query/mod.rs`][upvars] defines a query called *upvars_mentioned* +[`compiler/rustc_middle/src/ty/query/mod.rs`][upvars] defines a query called *upv.rs_mentioned* for this purpose. [upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/queries/struct.upvars_mentioned.html @@ -135,8 +135,8 @@ appropriate trait: `Fn` trait for immutable borrow, `FnMut` for mutable borrow, and `FnOnce` for move semantics. Most of the code related to the closure is in the -[`src/librustc_typeck/check/upvar.rs`][upvar] file and the data structures are -declared in the file [`src/librustc_middle/ty/mod.rs`][ty]. +[`compiler/rustc_typeck/src/check/upvar.rs`][upvar] file and the data structures are +declared in the file [`compiler/rustc_middle/src/ty/mod.rs`][ty]. [upvar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/upvar/index.html [ty]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html @@ -184,7 +184,7 @@ The callbacks are defined by implementing the [`Delegate`] trait. The records for each upvar which mode of borrow was required. The modes of borrow can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be `shared`, `shallow`, `unique` or `mut` as defined in the -[`src/librustc_middle/mir/mod.rs`][mir_mod]. +[`compiler/rustc_middle/src/mir/mod.rs`][mir_mod]. [mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html @@ -194,7 +194,7 @@ can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be All of these callbacks have a common argument *cmt* which stands for Category, Mutability and Type and is defined in -[`src/librustc_middle/middle/mem_categorization.rs`][cmt]. Borrowing from the code +[`compiler/rustc_middle/src/middle/mem_categorization.rs`][cmt]. Borrowing from the code comments, "`cmt` is a complete categorization of a value indicating where it originated and how it is located, as well as the mutability of the memory in which the value is stored". Based on the callback (consume, borrow etc.), we diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 0c40d63e4..ead9b020b 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -53,17 +53,17 @@ look like this: ```text stack backtrace: (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~) - at /home/user/rust/src/librustc_typeck/check/cast.rs:110 + at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:110 7: rustc_typeck::check::cast::CastCheck::check - at /home/user/rust/src/librustc_typeck/check/cast.rs:572 - at /home/user/rust/src/librustc_typeck/check/cast.rs:460 - at /home/user/rust/src/librustc_typeck/check/cast.rs:370 + at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:572 + at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:460 + at /home/user/rust/compiler/rustc_typeck/src/check/cast.rs:370 (~~~~ LINES REMOVED BY ME FOR BREVITY ~~~~) 33: rustc_driver::driver::compile_input - at /home/user/rust/src/librustc_driver/driver.rs:1010 - at /home/user/rust/src/librustc_driver/driver.rs:212 + at /home/user/rust/compiler/rustc_driver/src/driver.rs:1010 + at /home/user/rust/compiler/rustc_driver/src/driver.rs:212 34: rustc_driver::run_compiler - at /home/user/rust/src/librustc_driver/lib.rs:253 + at /home/user/rust/compiler/rustc_driver/src/lib.rs:253 ``` ## Getting a backtrace for errors @@ -123,23 +123,23 @@ note: rustc 1.24.0-dev running on x86_64-unknown-linux-gnu note: run with `RUST_BACKTRACE=1` for a backtrace thread 'rustc' panicked at 'encountered error with `-Z treat_err_as_bug', -/home/user/rust/src/librustc_errors/lib.rs:411:12 +/home/user/rust/compiler/rustc_errors/src/lib.rs:411:12 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. stack backtrace: (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) 7: rustc::traits::error_reporting::> ::report_selection_error - at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:823 + at /home/user/rust/compiler/rustc_middle/src/traits/error_reporting.rs:823 8: rustc::traits::error_reporting::> ::report_fulfillment_errors - at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:160 - at /home/user/rust/src/librustc_middle/traits/error_reporting.rs:112 + at /home/user/rust/compiler/rustc_middle/src/traits/error_reporting.rs:160 + at /home/user/rust/compiler/rustc_middle/src/traits/error_reporting.rs:112 9: rustc_typeck::check::FnCtxt::select_obligations_where_possible - at /home/user/rust/src/librustc_typeck/check/mod.rs:2192 + at /home/user/rust/compiler/rustc_typeck/src/check/mod.rs:2192 (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) 36: rustc_driver::run_compiler - at /home/user/rust/src/librustc_driver/lib.rs:253 + at /home/user/rust/compiler/rustc_driver/src/lib.rs:253 $ # Cool, now I have a backtrace for the error ``` @@ -174,11 +174,11 @@ look at the log output with a text editor. So to put it together. ```bash -# This puts the output of all debug calls in `librustc_middle/traits` into +# This puts the output of all debug calls in `rustc_middle/src/traits` into # standard error, which might fill your console backscroll. $ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs -# This puts the output of all debug calls in `librustc_middle/traits` in +# This puts the output of all debug calls in `rustc_middle/src/traits` in # `traits-log`, so you can then see it with a text editor. $ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs 2>traits-log @@ -199,7 +199,7 @@ $ RUSTC_LOG=rustc_trans=info rustc +local my-file.rs # This will show the output of all `info!` calls made by rustdoc or any rustc library it calls. $ RUSTDOC_LOG=info rustdoc +local my-file.rs -# This will only show `debug!` calls made by rustdoc directly, not any `librustc*` crate. +# This will only show `debug!` calls made by rustdoc directly, not any `rustc*` crate. $ RUSTDOC_LOG=rustdoc rustdoc +local my-file.rs ``` diff --git a/src/compiler-src.md b/src/compiler-src.md index df8bc2bd1..324b9105a 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -46,7 +46,7 @@ built in a special way because it can use unstable features. > NOTE: As of this writing, the crates all live in `src/`, but there is an MCP > to move them to a new `compiler/` directory. -The compiler crates all have names starting with `librustc_*`. These are a +The compiler crates all have names starting with `rustc_*`. These are a collection of around 50 interdependent crates ranging in size from tiny to huge. There is also the `rustc` crate which is the actual binary (i.e. the `main` function); it doesn't actually do anything besides calling the diff --git a/src/diagnostics.md b/src/diagnostics.md index 5ad2fbb32..a3293101f 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -71,11 +71,11 @@ Please read [RFC 1567] for details on how to format and write long error codes. The descriptions are written in markdown, and all of them are linked in the -[`librustc_error_codes`] crate. +[`rustc_error_codes`] crate. TODO: When should an error use an error code, and when shouldn't it? -[`librustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html +[`rustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html [error index]: https://doc.rust-lang.org/error-index.html [RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md @@ -633,12 +633,12 @@ like normal but invokes the lint with `buffer_lint`. #### Linting even earlier in the compiler -The parser (`librustc_ast`) is interesting in that it cannot have dependencies on -any of the other `librustc*` crates. In particular, it cannot depend on -`librustc_middle::lint` or `librustc_lint`, where all of the compiler linting +The parser (`rustc_ast`) is interesting in that it cannot have dependencies on +any of the other `rustc*` crates. In particular, it cannot depend on +`rustc_middle::lint` or `rustc_lint`, where all of the compiler linting infrastructure is defined. That's troublesome! -To solve this, `librustc_ast` defines its own buffered lint type, which +To solve this, `rustc_ast` defines its own buffered lint type, which `ParseSess::buffer_lint` uses. After macro expansion, these buffered lints are then dumped into the `Session::buffered_lints` used by the rest of the compiler. @@ -669,8 +669,8 @@ the structured JSON and see the "human" output (well, _sans_ colors) without having to compile everything twice. The "human" readable and the json format emitter can be found under -librustc_errors, both were moved from the `librustc_ast` crate to the -[librustc_errors crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html). +`rustc_errors`, both were moved from the `rustc_ast` crate to the +[rustc_errors crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html). The JSON emitter defines [its own `Diagnostic` struct](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/json/struct.Diagnostic.html) diff --git a/src/diagnostics/diagnostic-codes.md b/src/diagnostics/diagnostic-codes.md index e0d144bfc..d5aae201a 100644 --- a/src/diagnostics/diagnostic-codes.md +++ b/src/diagnostics/diagnostic-codes.md @@ -32,7 +32,7 @@ Here we see the highest error code in use is `E0591`, so we _probably_ want `E0592`. To be sure, run `rg E0592` and check, you should see no references. Next, open `src/{crate}/diagnostics.rs` within the crate where you wish to issue -the error (e.g., `src/librustc_typeck/diagnostics.rs`). Ideally, you will add +the error (e.g., `compiler/rustc_typeck/src/diagnostics.rs`). Ideally, you will add the code (in its proper numerical order) into the `register_long_diagnostics!` macro, sort of like this: diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index 2942dac02..8f0c21ab3 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -92,7 +92,7 @@ understanding the code. However, with the current type-erased lint store approach, it is beneficial to do so for performance reasons. New lints being added likely want to join one of the existing declarations like -`late_lint_mod_passes` in `librustc_lint/lib.rs`, which would then +`late_lint_mod_passes` in `rustc_lint/src/lib.rs`, which would then auto-propagate into the other. [`LintStore::register_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html#method.register_lints diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 233d223db..2103c8803 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -126,7 +126,7 @@ a new unstable feature: 2. Pick a name for the feature gate (for RFCs, use the name in the RFC). -3. Add a feature gate declaration to `librustc_feature/active.rs` +3. Add a feature gate declaration to `rustc_feature/src/active.rs` in the active `declare_features` block: ```rust,ignore diff --git a/src/lowering.md b/src/lowering.md index e0dc99bab..a4d270b4d 100644 --- a/src/lowering.md +++ b/src/lowering.md @@ -18,7 +18,7 @@ of such structures include but are not limited to * Converted to a virtual `existential type` declaration Lowering needs to uphold several invariants in order to not trigger the -sanity checks in `src/librustc_middle/hir/map/hir_id_validator.rs`: +sanity checks in `compiler/rustc_middle/src/hir/map/hir_id_validator.rs`: 1. A `HirId` must be used if created. So if you use the `lower_node_id`, you *must* use the resulting `NodeId` or `HirId` (either is fine, since diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 1b06cab41..7f704d05d 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -1,6 +1,6 @@ # Macro expansion -> `librustc_ast`, `librustc_expand`, and `librustc_builtin_macros` are all undergoing +> `rustc_ast`, `rustc_expand`, and `rustc_builtin_macros` are all undergoing > refactoring, so some of the links in this chapter may be broken. Rust has a very powerful macro system. In the previous chapter, we saw how the @@ -222,7 +222,7 @@ a macro author may want to introduce a new name to the context where the macro was called. Alternately, the macro author may be defining a variable for use only within the macro (i.e. it should not be visible outside the macro). -[code_dir]: https://github.com/rust-lang/rust/tree/master/src/librustc_expand/mbe +[code_dir]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_expand/src/mbe [code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser [code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules [code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html @@ -232,7 +232,7 @@ The context is attached to AST nodes. All AST nodes generated by macros have context attached. Additionally, there may be other nodes that have context attached, such as some desugared syntax (non-macro-expanded nodes are considered to just have the "root" context, as described below). -Throughout the compiler, we use [`librustc_span::Span`s][span] to refer to code locations. +Throughout the compiler, we use [`rustc_span::Span`s][span] to refer to code locations. This struct also has hygiene information attached to it, as we will see later. [span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html @@ -442,7 +442,7 @@ are expanded, we may invoke the MBE parser to parse and expand a macro. The MBE parser, in turn, may call the normal Rust parser when it needs to bind a metavariable (e.g. `$my_expr`) while parsing the contents of a macro invocation. The code for macro expansion is in -[`src/librustc_expand/mbe/`][code_dir]. +[`compiler/rustc_expand/src/mbe/`][code_dir]. ### Example @@ -495,7 +495,7 @@ invocations. Interestingly, both are done by the macro parser. Basically, the MBE parser is like an NFA-based regex parser. It uses an algorithm similar in spirit to the [Earley parsing algorithm](https://en.wikipedia.org/wiki/Earley_parser). The macro parser is -defined in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp]. +defined in [`compiler/rustc_expand/src/mbe/macro_parser.rs`][code_mp]. The interface of the macro parser is as follows (this is slightly simplified): @@ -542,7 +542,7 @@ normal Rust parser. As mentioned above, both definitions and invocations of macros are parsed using the macro parser. This is extremely non-intuitive and self-referential. The code to parse macro _definitions_ is in -[`src/librustc_expand/mbe/macro_rules.rs`][code_mr]. It defines the pattern for +[`compiler/rustc_expand/src/mbe/macro_rules.rs`][code_mr]. It defines the pattern for matching for a macro definition as `$( $lhs:tt => $rhs:tt );+`. In other words, a `macro_rules` definition should have in its body at least one occurrence of a token tree followed by `=>` followed by another token tree. When the compiler @@ -571,7 +571,7 @@ the parse is ambiguous, while if there are no matches at all, there is a syntax error. For more information about the macro parser's implementation, see the comments -in [`src/librustc_expand/mbe/macro_parser.rs`][code_mp]. +in [`compiler/rustc_expand/src/mbe/macro_parser.rs`][code_mp]. ### `macro`s and Macros 2.0 diff --git a/src/mir/index.md b/src/mir/index.md index 85c5d755e..f771fa0ed 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -15,8 +15,8 @@ graphs and desugaring), you may enjoy the ## Introduction to MIR -MIR is defined in the [`src/librustc_middle/mir/`][mir] module, but much of the code -that manipulates it is found in [`src/librustc_mir`][mirmanip]. +MIR is defined in the [`compiler/rustc_middle/src/mir/`][mir] module, but much of the code +that manipulates it is found in [`compiler/rustc_mir`][mirmanip]. [RFC 1211]: https://rust-lang.github.io/rfcs/1211-mir.html @@ -212,7 +212,7 @@ over the overflow checks.) ## MIR data types -The MIR data types are defined in the [`src/librustc_middle/mir/`][mir] +The MIR data types are defined in the [`compiler/rustc_middle/src/mir/`][mir] module. Each of the key concepts mentioned in the previous section maps in a fairly straightforward way to a Rust type. @@ -253,7 +253,6 @@ but [you can read about those below](#promoted)). *to be written* -[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/mir -[mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir -[mir]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/mir +[mir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html +[mirmanip]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html [newtype'd]: ../appendix/glossary.html#newtype diff --git a/src/miri.md b/src/miri.md index 76996271d..af2a92802 100644 --- a/src/miri.md +++ b/src/miri.md @@ -102,7 +102,7 @@ Miri, but just use the cached result. ## Datastructures Miri's outside-facing datastructures can be found in -[librustc_middle/mir/interpret](https://github.com/rust-lang/rust/blob/master/src/librustc_middle/mir/interpret). +[rustc_middle/src/mir/interpret](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/mir/interpret). This is mainly the error enum and the [`ConstValue`] and [`Scalar`] types. A `ConstValue` can be either `Scalar` (a single `Scalar`, i.e., integer or thin pointer), `Slice` (to represent byte slices and strings, as needed for pattern @@ -202,7 +202,7 @@ division on pointer values. Although the main entry point to constant evaluation is the `tcx.const_eval_*` functions, there are additional functions in -[librustc_mir/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html) +[rustc_mir/src/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html) that allow accessing the fields of a `ConstValue` (`ByRef` or otherwise). You should never have to access an `Allocation` directly except for translating it to the compilation target (at the moment just LLVM). @@ -213,7 +213,7 @@ function with no arguments, except that constants do not allow local (named) variables at the time of writing this guide. A stack frame is defined by the `Frame` type in -[librustc_mir/interpret/eval_context.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/eval_context.rs) +[rustc_mir/src/interpret/eval_context.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/interpret/eval_context.rs) and contains all the local variables memory (`None` at the start of evaluation). Each frame refers to the evaluation of either the root constant or subsequent calls to `const fn`. The @@ -225,7 +225,7 @@ The frames are just a `Vec`, there's no way to actually refer to a memory that can be referred to are `Allocation`s. Miri now calls the `step` method (in -[librustc_mir/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/interpret/step.rs) +[rustc_mir/src/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/interpret/step.rs) ) until it either returns an error or has no further statements to execute. Each statement will now initialize or modify the locals or the virtual memory referred to by a local. This might require evaluating other constants or diff --git a/src/name-resolution.md b/src/name-resolution.md index cc6eed7f8..ebd44da1d 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -55,7 +55,7 @@ A successful run of the second phase ([`Resolver::resolve_crate`]) creates kind of an index the rest of the compilation may use to ask about the present names (through the `hir::lowering::Resolver` interface). -The name resolution lives in the `librustc_resolve` crate, with the meat in +The name resolution lives in the `rustc_resolve` crate, with the meat in `lib.rs` and some helpers or symbol-type specific logic in the other modules. [`Resolver::resolve_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/struct.Resolver.html#method.resolve_crate diff --git a/src/overview.md b/src/overview.md index 5bcf26911..baa1e0aa6 100644 --- a/src/overview.md +++ b/src/overview.md @@ -22,31 +22,31 @@ we'll talk about that later. enable nightly features (`-Z` flags), perform `check`-only builds, or emit LLVM-IR rather than executable machine code. The `rustc` executable call may be indirect through the use of `cargo`. -- Command line argument parsing occurs in the [`librustc_driver`]. This crate +- Command line argument parsing occurs in the [`rustc_driver`]. This crate defines the compile configuration that is requested by the user and passes it to the rest of the compilation process as a [`rustc_interface::Config`]. - The raw Rust source text is analyzed by a low-level lexer located in - [`librustc_lexer`]. At this stage, the source text is turned into a stream of + [`rustc_lexer`]. At this stage, the source text is turned into a stream of atomic source code units known as _tokens_. The lexer supports the Unicode character encoding. - The token stream passes through a higher-level lexer located in - [`librustc_parse`] to prepare for the next stage of the compile process. The + [`rustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations and turn strings into interned symbols (_interning_ is discussed later). - The lexer has a small interface and doesn't depend directly on the diagnostic infrastructure in `rustc`. Instead it provides diagnostics as plain - data which are emitted in `librustc_parse::lexer::mod` as real diagnostics. + data which are emitted in `rustc_parse::lexer::mod` as real diagnostics. - The lexer preserves full fidelity information for both IDEs and proc macros. - The parser [translates the token stream from the lexer into an Abstract Syntax Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax analysis. The crate entry points for the parser are the `Parser::parse_crate_mod()` and - `Parser::parse_mod()` methods found in `librustc_parse::parser::item`. The external - module parsing entry point is `librustc_expand::module::parse_external_mod`. And + `Parser::parse_mod()` methods found in `rustc_parse::parser::item`. The external + module parsing entry point is `rustc_expand::module::parse_external_mod`. And the macro parser entry point is [`Parser::parse_nonterminal()`][parse_nonterminal]. - Parsing is performed with a set of `Parser` utility methods including `fn bump`, `fn check`, `fn eat`, `fn expect`, `fn look_ahead`. - Parsing is organized by the semantic construct that is being parsed. Separate - `parse_*` methods can be found in `librustc_parse` `parser` directory. The source + `parse_*` methods can be found in `rustc_parse` `parser` directory. The source file name follows the construct name. For example, the following files are found in the parser: - `expr.rs` @@ -97,12 +97,12 @@ we'll talk about that later. - The different libraries/binaries are linked together to produce the final binary. -[`librustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html -[`librustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html +[`rustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html +[`rustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html [`rustc_interface::Config`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Config.html [lex]: https://rustc-dev-guide.rust-lang.org/the-parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html -[`librustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html +[`rustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html [type inference]: https://rustc-dev-guide.rust-lang.org/type-inference.html @@ -340,16 +340,16 @@ For more details on bootstrapping, see - Main entry point: [`rustc_session::config::build_session_options`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/config/fn.build_session_options.html) - Lexical Analysis: Lex the user program to a stream of tokens - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - - Lexer definition: [`librustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html) + - Lexer definition: [`rustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html) - Main entry point: [`rustc_lexer::first_token`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/fn.first_token.html) - Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST) - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - - Parser definition: [`librustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) + - Parser definition: [`rustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) - Main entry points: - [Entry point for first file in crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.parse.html) - [Entry point for outline module parsing](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/module/fn.parse_external_mod.html) - [Entry point for macro fragments][parse_nonterminal] - - AST definition: [`librustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html) + - AST definition: [`rustc_ast`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html) - Expansion: **TODO** - Name Resolution: **TODO** - Feature gating: **TODO** @@ -371,8 +371,8 @@ For more details on bootstrapping, see - These two functions can't be decoupled. - The Mid Level Intermediate Representation (MIR) - Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html) - - Definition: [`librustc_middle/mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html) - - Definition of source that manipulates the MIR: [`librustc_mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html) + - Definition: [`rustc_middle/src/mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html) + - Definition of source that manipulates the MIR: [`rustc_mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html) - The Borrow Checker - Guide: [MIR Borrow Check](https://rustc-dev-guide.rust-lang.org/borrow_check.html) - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html) diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 1b4f827d4..308add57f 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -24,8 +24,8 @@ unsafe { panic_impl(&pi) } Actually resolving this goes through several layers of indirection: -1. In `src/librustc_middle/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item', - with the symbol `rust_begin_unwind`. This is used in `librustc_typeck/collect.rs` +1. In `compiler/rustc_middle/src/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item', + with the symbol `rust_begin_unwind`. This is used in `rustc_typeck/src/collect.rs` to set the actual symbol name to `rust_begin_unwind`. Note that `panic_impl` is declared in an `extern "Rust"` block, @@ -44,7 +44,7 @@ pub fn begin_panic_handler(info: &PanicInfo<'_>) -> ! { } ``` -The special `panic_handler` attribute is resolved via `src/librustc_middle/middle/lang_items`. +The special `panic_handler` attribute is resolved via `compiler/rustc_middle/src/middle/lang_items`. The `extract` function converts the `panic_handler` attribute to a `panic_impl` lang item. Now, we have a matching `panic_handler` lang item in the `std`. This function goes diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index 96255227f..bea9a886f 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -175,7 +175,7 @@ fn try_mark_green(tcx, current_node) -> bool { } // Note: The actual implementation can be found in -// src/librustc_middle/dep_graph/graph.rs +// compiler/rustc_middle/src/dep_graph/graph.rs ``` By using red-green marking we can avoid the devastating cumulative effect of diff --git a/src/queries/incremental-compilation.md b/src/queries/incremental-compilation.md index c8e7d4d7c..5ff189f96 100644 --- a/src/queries/incremental-compilation.md +++ b/src/queries/incremental-compilation.md @@ -81,7 +81,7 @@ Try-mark-green works as follows: ### The query DAG The query DAG code is stored in -[`src/librustc_middle/dep_graph`][dep_graph]. Construction of the DAG is done +[`compiler/rustc_middle/src/dep_graph`][dep_graph]. Construction of the DAG is done by instrumenting the query execution. One key point is that the query DAG also tracks ordering; that is, for @@ -113,7 +113,7 @@ of order, however, it might visit `subquery2` before `subquery1`, and hence execute it. This can lead to ICEs and other problems in the compiler. -[dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc_middle/dep_graph +[dep_graph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/dep_graph/index.html ## Improvements to the basic algorithm diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 593d0b385..ad31c9e53 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -259,7 +259,7 @@ We give some background about the query model of the Rust compiler. In the query model, many queries have a key that consists of a Def ID. The Rust compiler uses Def IDs to distinguish definitions in the input Rust program. -From the compiler source code (`src/librustc_middle/hir/def_id.rs`): +From the compiler source code (`compiler/rustc_middle/src/hir/def_id.rs`): ``` /// A DefId identifies a particular *definition*, by combining a crate diff --git a/src/query.md b/src/query.md index be84fec54..52786ad34 100644 --- a/src/query.md +++ b/src/query.md @@ -114,7 +114,7 @@ for external crates, though the plan is that we may eventually have one per crate. These `Providers` structs are ultimately created and populated by -`librustc_driver`, but it does this by distributing the work +`rustc_driver`, but it does this by distributing the work throughout the other `rustc_*` crates. This is done by invoking various [`provide`][provide_fn] functions. These functions tend to look something like this: @@ -159,7 +159,7 @@ they define both a [`provide`][ext_provide] and a [`provide_extern`][ext_provide_extern] function that `rustc_driver` can invoke. -[rustc_metadata]: https://github.com/rust-lang/rust/tree/master/src/librustc_metadata +[rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html [ext_provide]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide.html [ext_provide_extern]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide_extern.html @@ -173,7 +173,7 @@ Well, defining a query takes place in two steps: To specify the query name and arguments, you simply add an entry to the big macro invocation in -[`src/librustc_middle/query/mod.rs`][query-mod], which looks something like: +[`compiler/rustc_middle/src/query/mod.rs`][query-mod], which looks something like: [query-mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/index.html diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 73875bceb..2cdb0037b 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -91,7 +91,7 @@ should appear in the documentation. ### Updating the feature-gate listing There is a central listing of feature-gates in -[`src/librustc_feature`]. Search for the `declare_features!` +[`compiler/rustc_feature`]. Search for the `declare_features!` macro. There should be an entry for the feature you are aiming to stabilize, something like (this example is taken from [rust-lang/rust#32409]: @@ -140,7 +140,7 @@ Most importantly, remove the code which flags an error if the feature-gate is not present (since the feature is now considered stable). If the feature can be detected because it employs some new syntax, then a common place for that code to be is in the -same `src/librustc_ast_passes/feature_gate.rs`. +same `compiler/rustc_ast_passes/src/feature_gate.rs`. For example, you might see code like this: ```rust,ignore @@ -175,7 +175,7 @@ if something { /* XXX */ } ``` [rust-lang/rust#32409]: https://github.com/rust-lang/rust/issues/32409 -[`src/librustc_feature`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/index.html +[`compiler/rustc_feature`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/index.html [The Reference]: https://github.com/rust-lang/reference [The Book]: https://github.com/rust-lang/book [Rust by Example]: https://github.com/rust-lang/rust-by-example diff --git a/src/test-implementation.md b/src/test-implementation.md index a5ddd9135..230e2fe36 100644 --- a/src/test-implementation.md +++ b/src/test-implementation.md @@ -32,14 +32,14 @@ How does any sort of `main` function invoke these tests if they're not visible? What exactly is `rustc --test` doing? `#[test]` is implemented as a syntactic transformation inside the compiler's -[`librustc_ast` crate][librustc_ast]. Essentially, it's a fancy macro, that +[`rustc_ast` crate][rustc_ast]. Essentially, it's a fancy macro, that rewrites the crate in 3 steps: #### Step 1: Re-Exporting As mentioned earlier, tests can exist inside private modules, so we need a way of exposing them to the main function, without breaking any existing -code. To that end, `librustc_ast` will create local modules called +code. To that end, `rustc_ast` will create local modules called `__test_reexports` that recursively reexport tests. This expansion translates the above example into: @@ -79,7 +79,7 @@ hygiene. #### Step 2: Harness Generation Now that our tests are accessible from the root of our crate, we need to do -something with them. `librustc_ast` generates a module like so: +something with them. `rustc_ast` generates a module like so: ```rust,ignore #[main] @@ -116,7 +116,7 @@ fn foo() { This means our tests are more than just simple functions, they have configuration information as well. `test` encodes this configuration data into a struct called [`TestDesc`][TestDesc]. For each test function in a -crate, `librustc_ast` will parse its attributes and generate a `TestDesc` +crate, `rustc_ast` will parse its attributes and generate a `TestDesc` instance. It then combines the `TestDesc` and test function into the predictably named `TestDescAndFn` struct, that `test_main_static` operates on. For a given test, the generated `TestDescAndFn` instance looks like so: @@ -150,4 +150,4 @@ $ rustc my_mod.rs -Z unpretty=hir [Symbol]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html [Ident]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Ident.html [eRFC]: https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md -[librustc_ast]: https://github.com/rust-lang/rust/tree/master/src/librustc_ast +[rustc_ast]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_ast diff --git a/src/the-parser.md b/src/the-parser.md index da318c9ef..7c59ddfe7 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -9,7 +9,7 @@ conveniently than strings. This happens in two stages: Lexing and Parsing. Lexing takes strings and turns them into streams of [tokens]. For example, `a.b + c` would be turned into the tokens `a`, `.`, `b`, `+`, and `c`. -The lexer lives in [`librustc_lexer`][lexer]. +The lexer lives in [`rustc_lexer`][lexer]. [tokens]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/token/index.html [lexer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html @@ -19,12 +19,12 @@ form which is easier for the compiler to work with, usually called an [*Abstract Syntax Tree*][ast] (AST). An AST mirrors the structure of a Rust program in memory, using a `Span` to link a particular AST node back to its source text. -The AST is defined in [`librustc_ast`][librustc_ast], along with some definitions for +The AST is defined in [`rustc_ast`][rustc_ast], along with some definitions for tokens and token streams, data structures/traits for mutating ASTs, and shared definitions for other AST-related parts of the compiler (like the lexer and macro-expansion). -The parser is defined in [`librustc_parse`][librustc_parse], along with a +The parser is defined in [`rustc_parse`][rustc_parse], along with a high-level interface to the lexer and some validation routines that run after macro expansion. In particular, the [`rustc_parse::parser`][parser] contains the parser implementation. @@ -52,16 +52,16 @@ Code for lexical analysis is split between two crates: constituting tokens. Although it is popular to implement lexers as generated finite state machines, the lexer in `rustc_lexer` is hand-written. -- [`StringReader`] from [`librustc_ast`][librustc_ast] integrates `rustc_lexer` with `rustc` +- [`StringReader`] from [`rustc_ast`][rustc_ast] integrates `rustc_lexer` with `rustc` specific data structures. Specifically, it adds `Span` information to tokens returned by `rustc_lexer` and interns identifiers. -[librustc_ast]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html +[rustc_ast]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/index.html [rustc_errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree [`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html [ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html -[librustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html +[rustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/index.html [`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/parse/parser/struct.Parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html diff --git a/src/traits/chalk.md b/src/traits/chalk.md index 70af2a1f5..659f69637 100644 --- a/src/traits/chalk.md +++ b/src/traits/chalk.md @@ -38,4 +38,4 @@ implementing them in rustc. We map our struct, trait, and impl declarations into logical inference rules in the [lowering module in rustc](./lowering-module.md). [chalk]: https://github.com/rust-lang/chalk -[librustc_traits]: https://github.com/rust-lang/rust/tree/master/src/librustc_traits +[rustc_traits]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_traits diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index f4ceb99a0..9aaab96fa 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -38,11 +38,11 @@ paper gives the details. In terms of code, these types are defined in -[`librustc_middle/traits/mod.rs`][traits_mod] in rustc, and in +[`rustc_middle/src/traits/mod.rs`][traits_mod] in rustc, and in [`chalk-ir/src/lib.rs`][chalk_ir] in chalk. [pphhf]: https://rust-lang.github.io/chalk/book/bibliography.html#pphhf -[traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs +[traits_mod]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/traits/mod.rs [chalk_ir]: https://github.com/rust-lang/chalk/blob/master/chalk-ir/src/lib.rs diff --git a/src/ty-fold.md b/src/ty-fold.md index 5b409e8ec..c390597f9 100644 --- a/src/ty-fold.md +++ b/src/ty-fold.md @@ -90,7 +90,7 @@ things. We only want to do something when we reach a type. That means there may implementations. Such implementations of `TypeFoldable` tend to be pretty tedious to write by hand. For this reason, there is a `derive` macro that allows you to `#![derive(TypeFoldable)]`. It is defined -[here](https://github.com/rust-lang/rust/blob/master/src/librustc_macros/src/type_foldable.rs). +[here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_macros/src/type_foldable.rs). **`subst`** In the case of substitutions the [actual folder](https://github.com/rust-lang/rust/blob/75ff3110ac6d8a0259023b83fd20d7ab295f8dd6/src/librustc_middle/ty/subst.rs#L440-L451) diff --git a/src/type-checking.md b/src/type-checking.md index d4f4bf110..797cd9487 100644 --- a/src/type-checking.md +++ b/src/type-checking.md @@ -4,9 +4,9 @@ The [`rustc_typeck`][typeck] crate contains the source for "type collection" and "type checking", as well as a few other bits of related functionality. (It draws heavily on the [type inference] and [trait solving].) -[typeck]: https://github.com/rust-lang/rust/tree/master/src/librustc_typeck -[type inference]: type-inference.html -[trait solving]: traits/resolution.html +[typeck]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/index.html +[type inference]: ./type-inference.md +[trait solving]: ./traits/resolution.md ## Type collection @@ -38,7 +38,7 @@ type *checking*). For more details, see the [`collect`][collect] module. -[queries]: query.html +[queries]: ./query.md [collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/collect/ **TODO**: actually talk about type checking... From b259473dd18c5ac7c9ec451d4e083441dc0dafc8 Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 30 Aug 2020 14:51:48 -0500 Subject: [PATCH 1178/1812] fix line lengths --- src/panic-implementation.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 308add57f..7c10ae215 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -24,9 +24,10 @@ unsafe { panic_impl(&pi) } Actually resolving this goes through several layers of indirection: -1. In `compiler/rustc_middle/src/middle/weak_lang_items.rs`, `panic_impl` is declared as 'weak lang item', - with the symbol `rust_begin_unwind`. This is used in `rustc_typeck/src/collect.rs` - to set the actual symbol name to `rust_begin_unwind`. +1. In `compiler/rustc_middle/src/middle/weak_lang_items.rs`, `panic_impl` is + declared as 'weak lang item', with the symbol `rust_begin_unwind`. This is + used in `rustc_typeck/src/collect.rs` to set the actual symbol name to + `rust_begin_unwind`. Note that `panic_impl` is declared in an `extern "Rust"` block, which means that core will attempt to call a foreign symbol called `rust_begin_unwind` From 4cb43d81603dab7f65448029b20d81226dccdb9b Mon Sep 17 00:00:00 2001 From: mark Date: Sun, 30 Aug 2020 14:58:29 -0500 Subject: [PATCH 1179/1812] fix typos --- src/appendix/code-index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 9046cab13..345a99b4f 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -11,20 +11,20 @@ Item | Kind | Short description | Chapter | `ast::Crate` | struct | A syntax-level representation of a parsed crate | [The parser] | [compiler/rustc_ast/src/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.Crate.html) `rustc_hir::Crate` | struct | A more abstract, compiler-friendly form of a crate's AST | [The Hir] | [compiler/rustc_hir/src/hir.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Crate.html) `DefId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/def_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html) -`DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [compiler/rustc_errors/src/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_err.rs/struct.DiagnosticBuilder.html) +`DiagnosticBuilder` | struct | A struct for building up compiler diagnostics, such as errors or lints | [Emitting Diagnostics] | [compiler/rustc_errors/src/diagnostic_builder.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.DiagnosticBuilder.html) `DocContext` | struct | A state container used by rustdoc when crawling through a crate to gather its documentation | [Rustdoc] | [src/librustdoc/core.rs](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs) `HirId` | struct | One of four types of HIR node identifiers | [Identifiers in the HIR] | [compiler/rustc_hir/src/hir_id.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html) `NodeId` | struct | One of four types of HIR node identifiers. Being phased out | [Identifiers in the HIR] | [compiler/rustc_ast/src/ast.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html) `P` | struct | An owned immutable smart pointer. By contrast, `&T` is not owned, and `Box` is not immutable. | None | [compiler/rustc_ast/src/ptr.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ptr/struct.P.html) `ParamEnv` | struct | Information about generic parameters or `Self`, useful for working with associated or generic items | [Parameter Environment] | [compiler/rustc_middle/src/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.ParamEnv.html) -`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [compiler/rustc_session/src/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.P.rseSess.html) +`ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [compiler/rustc_session/src/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html) `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [compiler/rustc_interface/src/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [compiler/rustc_resolve/src/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) `Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [compiler/rustc_middle/src/session/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) `SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [compiler/rustc_span/src/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html) `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [compiler/rustc_span/src/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [compiler/rustc_span/src/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html) -`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [compiler/rustc_parse/src/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_p.rse/lexer/struct.StringReader.html) +`StringReader` | struct | This is the lexer used during parsing. It consumes characters from the raw source code being compiled and produces a series of tokens for use by the rest of the parser | [The parser] | [compiler/rustc_parse/src/lexer/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html) `rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [compiler/rustc_ast/src/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [compiler/rustc_middle/src/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses] | [compiler/rustc_middle/src/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html) From 45a153500720933a7445ff98cd0b093958a4b177 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sun, 30 Aug 2020 21:15:08 -0500 Subject: [PATCH 1180/1812] Typo Co-authored-by: Joshua Nelson --- src/appendix/code-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 345a99b4f..68d12be37 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -20,7 +20,7 @@ Item | Kind | Short description | Chapter | `ParseSess` | struct | This struct contains information about a parsing session | [The parser] | [compiler/rustc_session/src/parse/parse.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.ParseSess.html) `Query` | struct | Represents the result of query to the `Compiler` interface and allows stealing, borrowing, and returning the results of compiler passes. | [The Rustc Driver and Interface] | [compiler/rustc_interface/src/queries.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html) `Rib` | struct | Represents a single scope of names | [Name resolution] | [compiler/rustc_resolve/src/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.Rib.html) -`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [compiler/rustc_middle/src/session/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) +`Session` | struct | The data associated with a compilation session | [The parser], [The Rustc Driver and Interface] | [compiler/rustc_session/src/session.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html) `SourceFile` | struct | Part of the `SourceMap`. Maps AST nodes to their source code for a single source file. Was previously called FileMap | [The parser] | [compiler/rustc_span/src/lib.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.SourceFile.html) `SourceMap` | struct | Maps AST nodes to their source code. It is composed of `SourceFile`s. Was previously called CodeMap | [The parser] | [compiler/rustc_span/src/source_map.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html) `Span` | struct | A location in the user's source code, used for error reporting primarily | [Emitting Diagnostics] | [compiler/rustc_span/src/span_encoding.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html) From 9ab50113c21055d7a6dda8f010f5b9d087e32ed1 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 30 Aug 2020 22:20:09 -0400 Subject: [PATCH 1181/1812] Fix misguided suggestions in config.toml - `verbose-tests` is for debugging the test harness, not the tests themselves. See also https://github.com/rust-lang/rust/pull/76141 - `codegen-units` defaults to `256` whenever `incremental = true`. So there's no need to explicitly set it to `0` if we already recommend incremental. See also https://github.com/rust-lang/rustc-dev-guide/pull/795#discussion_r479762977. --- src/building/how-to-build-and-run.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index f2f87e1d6..364a307d3 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -57,16 +57,8 @@ assertions = true # debug = true -# Number of codegen units to use for each compiler invocation. A value of 0 -# means "the number of cores on this machine", and 1+ is passed through to the -# compiler. -codegen-units = 0 - # Whether to always use incremental compilation when building rustc incremental = true - -# Emits extra output from tests so test failures are debuggable just from logfiles. -verbose-tests = true ``` If you have already built `rustc`, then you may have to execute `rm -rf build` for subsequent From 2924b6962d5c548a9e37f8e768dad68047215a0b Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 30 Aug 2020 22:09:57 -0400 Subject: [PATCH 1182/1812] Use fewer stages in bootstrapping docs After https://github.com/rust-lang/rust/pull/73964, they're redundant. --- src/building/bootstrapping.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index d2384f9fc..ed0d9693c 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -25,7 +25,7 @@ The `stage2` compiler is the one distributed with `rustup` and all other install methods. However, it takes a very long time to build because one must first build the new compiler with an older compiler and then use that to build the new compiler with itself. For development, you usually only want -the `stage1` compiler: `x.py build --stage 1 library/std`. +the `stage1` compiler: `x.py build library/std`. ## Complications of bootstrapping @@ -196,7 +196,7 @@ later copied into stage2 as well (both the compiler's `libdir` and the This `std` is pretty much necessary for any useful work with the compiler. Specifically, it's used as the `std` for programs compiled by the newly compiled compiler (so when you compile `fn main() { }` it is linked to the last `std` -compiled with `x.py build --stage 1 library/std`). +compiled with `x.py build library/std`). The `rustc` generated by the stage0 compiler is linked to the freshly-built `std`, which means that for the most part only `std` needs to be cfg-gated, From b737f79192fab31fe630d067ee4faba51494ba4e Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Tue, 1 Sep 2020 14:57:35 -0700 Subject: [PATCH 1183/1812] Adds documentation to cover spanview output Documents the feature introduced in #76074. --- src/compiler-debugging.md | 18 ++++++++++++++++++ src/mir/debugging.md | 14 +++++++++++--- 2 files changed, 29 insertions(+), 3 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index ead9b020b..fce579253 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -260,6 +260,24 @@ $ dot -T pdf maybe_init_suffix.dot > maybe_init_suffix.pdf $ firefox maybe_init_suffix.pdf # Or your favorite pdf viewer ``` +## Viewing Spanview output (.html files) +[viewing-spanview-output]: #viewing-spanview-output + +In addition to [graphviz output](#formatting-graphviz-output), MIR debugging +flags include an option to generate a MIR representation called `Spanview` that +uses HTML to highlight code regions in the original source code and display +compiler metadata associated with each region. +[`-Zdump-mir-spanview`](./mir/debugging.md), for example, highlights spans +associated with each MIR `Statement`, `Terminator`, and/or `BasicBlock`. + +These `.html` files use CSS features to dynamically expand spans obscured by +overlapping spans, and native tooltips (based on the HTML `title` attribute) to +reveal the actual MIR elements, as text. + +To view these files, simply use a modern browser, or a CSS-capable HTML preview +feature in a modern IDE. (The default HTML preview pane in *VS Code* is known to +work, for instance. + ## Narrowing (Bisecting) Regressions The [cargo-bisect-rustc][bisect] tool can be used as a quick and easy way to diff --git a/src/mir/debugging.md b/src/mir/debugging.md index 93a79076c..edb68ca72 100644 --- a/src/mir/debugging.md +++ b/src/mir/debugging.md @@ -1,8 +1,16 @@ # MIR Debugging -The `-Zdump-mir` flag can be used to dump a text representation of the MIR. The -`-Zdump-mir-graphviz` flag can be used to dump a `.dot` file that represents -MIR as a control-flow graph. +The `-Zdump-mir` flag can be used to dump a text representation of the MIR. +The following optional flags, used in combination with `-Zdump-mir`, enable +additional output formats, including: + +* `-Zdump-mir-graphviz` - dumps a `.dot` file that represents MIR as a +control-flow graph +* `-Zdump-mir-spanview` - dumps an `.html` file that highlights the source +spans associated with MIR elements (including mouse-over actions to reveal +elements obscured by overlaps, and tooltips to view the MIR statements). +This flag takes an optional value: `statement` (the default), `terminator`, or +`block`, to generate span highlights with different levels of granulatity. `-Zdump-mir=F` is a handy compiler options that will let you view the MIR for each function at each stage of compilation. `-Zdump-mir` takes a **filter** `F` From af533030a27168df357398ed47d605ee54441f06 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 3 Sep 2020 09:54:06 -0300 Subject: [PATCH 1184/1812] Fix dep-graph-caller-callee test location --- src/incrcomp-debugging.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/incrcomp-debugging.md b/src/incrcomp-debugging.md index ecb29d544..ba312c959 100644 --- a/src/incrcomp-debugging.md +++ b/src/incrcomp-debugging.md @@ -4,9 +4,9 @@ There are various ways to write tests against the dependency graph. The simplest mechanisms are the `#[rustc_if_this_changed]` and -`#[rustc_then_this_would_need]` annotations. These are used in compile-fail -tests to test whether the expected set of paths exist in the dependency graph. -As an example, see `src/test/compile-fail/dep-graph-caller-callee.rs`. +`#[rustc_then_this_would_need]` annotations. These are used in ui tests +to test whether the expected set of paths exist in the dependency graph. +As an example, see `src/test/ui/dep-graph/dep-graph-caller-callee.rs`. The idea is that you can annotate a test like: From 039e29f77caa82de1d4679ee7e2d09dcdd89556f Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Thu, 3 Sep 2020 15:56:29 -0700 Subject: [PATCH 1185/1812] update docs to refer to the move --- src/compiler-src.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index 324b9105a..843000a07 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -5,8 +5,8 @@ > top-level directory has separate directories for the compiler, build-system, > std libs, etc, rather than one huge `src/` directory. > -> As of this writing, the std libs have been moved to `library/` and there is -> an ongoing MCP to move the compiler to `compiler/`. +> As of this writing, the std libs have been moved to `library/` and the crates +> that make up the `rustc` compiler itself have been moved to `compiler/` Now that we have [seen what the compiler does](./overview.md), let's take a look at the structure of the contents of the rust-lang/rust repo. @@ -41,12 +41,9 @@ built in a special way because it can use unstable features. > You may find it helpful to read [The Overview Chapter](./overview.md) first, > which gives an overview of how the compiler works. The crates mentioned in -> this section implement the compiler. -> -> NOTE: As of this writing, the crates all live in `src/`, but there is an MCP -> to move them to a new `compiler/` directory. +> this section implement the compiler, and are underneath `compiler/` -The compiler crates all have names starting with `rustc_*`. These are a +The `compiler/` crates all have names starting with `rustc_*`. These are a collection of around 50 interdependent crates ranging in size from tiny to huge. There is also the `rustc` crate which is the actual binary (i.e. the `main` function); it doesn't actually do anything besides calling the From bb4695345ed432382f20e7ee1023754fa04a215c Mon Sep 17 00:00:00 2001 From: Ivan Tham Date: Sun, 6 Sep 2020 22:14:19 +0800 Subject: [PATCH 1186/1812] Rename src/rustc to compiler/rustc --- src/getting-started.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 055551c60..9c67f3dc4 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -180,14 +180,14 @@ should still read the rest of the section: | `x.py build --keep-stage 1 library/std` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | | `x.py test [--keep-stage 1]` | Run the test suite using the stage1 compiler | | `x.py test --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. | -| `x.py build --stage 2 src/rustc` | Do a full 2-stage build. You almost never want to do this. | +| `x.py build --stage 2 compiler/rustc` | Do a full 2-stage build. You almost never want to do this. | | `x.py test --stage 2` | Do a full 2-stage build and run all tests. You almost never want to do this. | To do a full 2-stage build of the whole compiler, you should run this (after updating `config.toml` as mentioned above): ```sh -./x.py build --stage 2 src/rustc +./x.py build --stage 2 compiler/rustc ``` In the process, this will also necessarily build the standard libraries, and it From e69542d0ea1c2bfd4d7004079400b8e5436c48ee Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 6 Sep 2020 15:00:21 -0400 Subject: [PATCH 1187/1812] Link to 'prerequisites' immediately Several of the commands on 'how to build' use python. But we haven't yet told the user how to install it! Do that first before going into detail on how x.py works. --- src/building/how-to-build-and-run.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 364a307d3..f52622322 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -6,6 +6,9 @@ be hacking on `rustc`, you'll want to tweak the configuration of the compiler. The default configuration is oriented towards running the compiler as a user, not a developer. +For instructions on how to install python and other prerequisites, +see [the next page](./prerequisites.md). + ## Get the source code The very first step to work on `rustc` is to clone the repository: From d1170027197cad66756291818cc43f7cbc5b8050 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 7 Sep 2020 11:16:03 +0200 Subject: [PATCH 1188/1812] Update src/building/how-to-build-and-run.md --- src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index f52622322..1e6702498 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -6,7 +6,7 @@ be hacking on `rustc`, you'll want to tweak the configuration of the compiler. The default configuration is oriented towards running the compiler as a user, not a developer. -For instructions on how to install python and other prerequisites, +For instructions on how to install Python and other prerequisites, see [the next page](./prerequisites.md). ## Get the source code From d8db731a4ab9d1f35b71f7a542a361776eed6ff4 Mon Sep 17 00:00:00 2001 From: Aman Arora Date: Thu, 3 Sep 2020 22:46:56 -0400 Subject: [PATCH 1189/1812] Document CGU partioning in case of generic and inline functions --- src/backend/monomorph.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index 47b41d4f6..e678b4f76 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -55,8 +55,28 @@ The monomorphization collector is run just before MIR lowering and codegen. collection and then partitions them into [codegen units](../appendix/glossary.md#codegen-unit). +## Codegen Unit (CGU) partitioning + +For better incremental build times, the CGU partitioner creates two CGU for each source level +modules. One is for "stable" i.e. non-generic code and the other is more volatile code i.e. +monoporphized/specialized instances. + +For depenencies, consider Crate A and Crate B, such that Crate B depends on Crate A. +The following table lists different scenarios for a function in Crate A that might be used by one +or more modules in Crate B. + +| Crate A function | Behavior | +| - | - | +| Non-generic function | Crate A function doesn't appear in any codegen units of Crate B | +| Non-generic `#[inline]` function | Crate A function appears with in a single CGU of Crate B, and exists even after post-inlining stage| +| Generic function | Regardless of inlining, all monoporphized (specialized) functions
from Crate A appear within a single codegen unit for Crate B.
The codegen unit exists even after the post inlining stage.| +| Generic `#[inline]` function | - same - | + +For more details about the partitioner read the module level [documentation]. + [mono]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/partitioning/fn.collect_and_partition_mono_items.html [codegen1]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html +[documentation]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/partitioning/index.html ## Polymorphization From fb88941f06c4fad48bce826ba55e58bff510e07f Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 7 Sep 2020 11:25:11 -0400 Subject: [PATCH 1190/1812] Consolidate information about bootstrapping into one place (#851) Previously, 'How to build and run' had a long section on the different stages of boostrap. But new contributors aren't interested in bootstrap; they want to start their build (because they heard it takes forever and want to start it so they aren't waiting more than necessary). This moves the section on stages into the bootstrapping page, and links there instead of discussing it on the main page. --- src/building/bootstrapping.md | 42 +++++++++++++++++++++---- src/building/how-to-build-and-run.md | 46 ++-------------------------- 2 files changed, 38 insertions(+), 50 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index ed0d9693c..dd24699fe 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -15,11 +15,41 @@ only way to build a modern version of rustc is a slightly less modern version. This is exactly how `x.py` works: it downloads the current `beta` release of -rustc, then uses it to compile the new compiler. The beta release is -called `stage0` and the newly built compiler is `stage1` (or `stage0 -artifacts`). To get the full benefits of the new compiler (e.g. optimizations -and new features), the `stage1` compiler then compiles _itself_ again. This -last compiler is called `stage2` (or `stage1 artifacts`). +rustc, then uses it to compile the new compiler. + +## Stages of bootstrapping + +Compiling `rustc` is done in stages: + +- **Stage 0:** the stage0 compiler is usually (you can configure `x.py` to use + something else) the current _beta_ `rustc` compiler and its associated dynamic + libraries (which `x.py` will download for you). This stage0 compiler is then + used only to compile `rustbuild`, `std`, and `rustc`. When compiling + `rustc`, this stage0 compiler uses the freshly compiled `std`. + There are two concepts at play here: a compiler (with its set of dependencies) + and its 'target' or 'object' libraries (`std` and `rustc`). + Both are staged, but in a staggered manner. +- **Stage 1:** the code in your clone (for new version) is then + compiled with the stage0 compiler to produce the stage1 compiler. + However, it was built with an older compiler (stage0), so to + optimize the stage1 compiler we go to next the stage. + - In theory, the stage1 compiler is functionally identical to the + stage2 compiler, but in practice there are subtle differences. In + particular, the stage1 compiler itself was built by stage0 and + hence not by the source in your working directory: this means that + the symbol names used in the compiler source may not match the + symbol names that would have been made by the stage1 compiler. This is + important when using dynamic linking and the lack of ABI compatibility + between versions. This primarily manifests when tests try to link with any + of the `rustc_*` crates or use the (now deprecated) plugin infrastructure. + These tests are marked with `ignore-stage1`. +- **Stage 2:** we rebuild our stage1 compiler with itself to produce + the stage2 compiler (i.e. it builds itself) to have all the _latest + optimizations_. (By default, we copy the stage1 libraries for use by + the stage2 compiler, since they ought to be identical.) +- _(Optional)_ **Stage 3**: to sanity check our new compiler, we + can build the libraries with the stage2 compiler. The result ought + to be identical to before, unless something has broken. The `stage2` compiler is the one distributed with `rustup` and all other install methods. However, it takes a very long time to build because one must @@ -76,7 +106,7 @@ contribution [here][bootstrap-build]. [bootstrap-build]: https://github.com/rust-lang/rust/pull/71994 -## Stages of bootstrap +## Understanding stages of bootstrap This is a detailed look into the separate bootstrap stages. When running `x.py` you will see output such as: diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 1e6702498..00127d560 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -80,50 +80,8 @@ effectively deal with the repo for various common tasks. This chapter focuses on the basics to be productive, but if you want to learn more about `x.py`, read its README.md [here](https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md). - -## Bootstrapping - -One thing to keep in mind is that `rustc` is a _bootstrapping_ -compiler. That is, since `rustc` is written in Rust, we need to use an -older version of the compiler to compile the newer version. In -particular, the newer version of the compiler and some of the artifacts needed -to build it, such as `std` and other tooling, may use some unstable features -internally, requiring a specific version which understands these unstable -features. - -The result is that compiling `rustc` is done in stages: - -- **Stage 0:** the stage0 compiler is usually (you can configure `x.py` to use - something else) the current _beta_ `rustc` compiler and its associated dynamic - libraries (which `x.py` will download for you). This stage0 compiler is then - used only to compile `rustbuild`, `std`, and `rustc`. When compiling - `rustc`, this stage0 compiler uses the freshly compiled `std`. - There are two concepts at play here: a compiler (with its set of dependencies) - and its 'target' or 'object' libraries (`std` and `rustc`). - Both are staged, but in a staggered manner. -- **Stage 1:** the code in your clone (for new version) is then - compiled with the stage0 compiler to produce the stage1 compiler. - However, it was built with an older compiler (stage0), so to - optimize the stage1 compiler we go to next the stage. - - In theory, the stage1 compiler is functionally identical to the - stage2 compiler, but in practice there are subtle differences. In - particular, the stage1 compiler itself was built by stage0 and - hence not by the source in your working directory: this means that - the symbol names used in the compiler source may not match the - symbol names that would have been made by the stage1 compiler. This is - important when using dynamic linking and the lack of ABI compatibility - between versions. This primarily manifests when tests try to link with any - of the `rustc_*` crates or use the (now deprecated) plugin infrastructure. - These tests are marked with `ignore-stage1`. -- **Stage 2:** we rebuild our stage1 compiler with itself to produce - the stage2 compiler (i.e. it builds itself) to have all the _latest - optimizations_. (By default, we copy the stage1 libraries for use by - the stage2 compiler, since they ought to be identical.) -- _(Optional)_ **Stage 3**: to sanity check our new compiler, we - can build the libraries with the stage2 compiler. The result ought - to be identical to before, unless something has broken. - -To read more about the bootstrap process, [read this chapter][bootstrap]. +To read more about the bootstrap process and why `x.py` is necessary, +[read this chapter][bootstrap]. [bootstrap]: ./bootstrapping.md From 677a95f264c22a9750d46d59ef1c4b74819080b3 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 30 Aug 2020 23:01:52 -0400 Subject: [PATCH 1191/1812] Update error codes to match the current implementation - All codes are in one crate, `rustc_error_codes` - Extended descriptions are loaded using `include_str!` - Give an example of a PR adding an error code --- src/diagnostics/diagnostic-codes.md | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/src/diagnostics/diagnostic-codes.md b/src/diagnostics/diagnostic-codes.md index d5aae201a..092c8a2f8 100644 --- a/src/diagnostics/diagnostic-codes.md +++ b/src/diagnostics/diagnostic-codes.md @@ -7,12 +7,13 @@ are making a new code, you should write an extended write-up. ### Allocating a fresh code -If you want to create a new error, you first need to find the next available -code. This is a bit tricky since the codes are defined in various crates. To do -it, run this obscure command: +Error codes are stored in `compiler/rustc_error_codes`. + +To create a new error, you first need to find the next available +code. You can find it with `tidy`: ``` -./x.py test --stage 0 tidy +./x.py test tidy ``` This will invoke the tidy script, which generally checks that your code obeys @@ -31,17 +32,16 @@ tidy check (x86_64-apple-darwin) Here we see the highest error code in use is `E0591`, so we _probably_ want `E0592`. To be sure, run `rg E0592` and check, you should see no references. -Next, open `src/{crate}/diagnostics.rs` within the crate where you wish to issue -the error (e.g., `compiler/rustc_typeck/src/diagnostics.rs`). Ideally, you will add -the code (in its proper numerical order) into the `register_long_diagnostics!` -macro, sort of like this: +Ideally, you will write an extended description for your error, +which will go in `rustc_error_codes/src/error_codes/E0592.md`. +To register the error, open `rustc_error_codes/src/error_codes.rs` and add the +code (in its proper numerical order) into` register_diagnostics!` macro, like +this: ```rust -register_long_diagnostics! { +register_diagnostics! { ... - E0592: r##" -Your extended error text goes here! -"##, + E0592: include_str!("./error_codes/E0592.md"), } ``` @@ -73,3 +73,7 @@ struct_span_err!(...) .span_note(another_span, "some separate note, probably avoid these") .emit_() ``` + +For an example of a PR adding an error code, see [#76143]. + +[#76143]: https://github.com/rust-lang/rust/pull/76143 From 75ad4417024fc29569122441a3584cb400631ebb Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 03:19:01 -0400 Subject: [PATCH 1192/1812] Document speculative crate loading (#859) --- src/name-resolution.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/name-resolution.md b/src/name-resolution.md index ebd44da1d..3785e3aa7 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -145,6 +145,23 @@ the code can be processed. Therefore, the resolution is performed in multiple stages. +## Speculative crate loading + +To give useful errors, rustc suggests importing paths into scope if they're +not found. How does it do this? It looks through every module of every crate +and looks for possible matches. This even includes crates that haven't yet +been loaded! + +Loading crates for import suggestions that haven't yet been loaded is called +_speculative crate loading_, because any errors it encounters shouldn't be +reported: resolve decided to load them, not the user. The function that does +this is `lookup_import_candidates` and lives in +`rustc_resolve/src/diagnostics.rs`. + +To tell the difference between speculative loads and loads initiated by the +user, resolve passes around a `record_used` parameter, which is `false` when +the load is speculative. + ## TODO: This is a result of the first pass of learning the code. It is definitely From 13c18fccbeb61d0580be8e1c9cc13d0b9a5efe0b Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 8 Sep 2020 23:24:18 -0400 Subject: [PATCH 1193/1812] Fix typo --- src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index dd24699fe..697ca80d1 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -96,7 +96,7 @@ Because there are two separate codebases behind `x.py`, they need to be kept in sync. In particular, both `bootstrap.py` and the bootstrap binary parse `config.toml` and read the same command line arguments. `bootstrap.py` keeps these in sync by setting various environment variables, and the -programs sometimes to have add arguments that are explicitly ignored, to be +programs sometimes have to add arguments that are explicitly ignored, to be read by the other. ### Adding a setting to config.toml From daa7597067531cb415b755c65e62e0f3668df2be Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 09:18:59 -0400 Subject: [PATCH 1194/1812] Add information about default stages for x.py --- src/building/bootstrapping.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 697ca80d1..7116d908a 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -57,6 +57,20 @@ first build the new compiler with an older compiler and then use that to build the new compiler with itself. For development, you usually only want the `stage1` compiler: `x.py build library/std`. +### Default stages + +`x.py` tries to be helpful and pick the stage you most likely meant for each subcommand. +These defaults are as follows: + +- `doc`: `--stage 0` +- `build`: `--stage 1` +- `test`: `--stage 1` +- `dist`: `--stage 2` +- `install`: `--stage 2` +- `bench`: `--stage 2` + +You can always override the stage by passing `--stage N` explicitly. + ## Complications of bootstrapping Since the build system uses the current beta compiler to build the stage-1 From b29062cb76dbc47f4decc6116f3b7c13c0718ec0 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 12:22:56 -0400 Subject: [PATCH 1195/1812] Fix broken hyperlink (#862) * Fix broken hyperlink * Link to previous pages instead of skipping ahead * Fix line lengths --- src/building/suggested.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 0cc91b403..424452b62 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -81,7 +81,7 @@ don't work (but that is easily detected and fixed). The sequence of commands you want is as follows: - Initial build: `./x.py build -i library/std` - - As [documented above](#command), this will build a functional + - As [documented previously], this will build a functional stage1 compiler as part of running all stage0 commands (which include building a `std` compatible with the stage1 compiler) as well as the first few steps of the "stage 1 actions" up to "stage1 (sysroot stage1) @@ -89,6 +89,8 @@ The sequence of commands you want is as follows: - Subsequent builds: `./x.py build -i library/std --keep-stage 1` - Note that we added the `--keep-stage 1` flag here +[documented previously]: ./how-to-build-and-run.md#building-the-compiler + As mentioned, the effect of `--keep-stage 1` is that we just *assume* that the old standard library can be re-used. If you are editing the compiler, this is almost always true: you haven't changed the standard library, after From ab5809b0181aa3f447c0c53ad8d8149276d8248a Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 12:24:01 -0400 Subject: [PATCH 1196/1812] Update prerequisites, with an eye towards windows (#863) * Update prerequisites, with an eye towards windows * Address review comments - Say version of MSVC needed - Link to more details windows section - Fix grammar --- src/building/prerequisites.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index f4b0a92a4..63d5aca8e 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -4,20 +4,28 @@ Before building the compiler, you need the following things installed: -* `g++` 5.1 or later or `clang++` 3.5 or later -* `python` 3 or 2.7 -* GNU `make` 3.81 or later -* `cmake` 3.4.3 or later +* `python` 3 or 2.7 (under the name `python`; `python2` or `python3` will not work) * `curl` * `git` * `ssl` which comes in `libssl-dev` or `openssl-devel` * `pkg-config` if you are compiling on Linux and targeting Linux -Additionally, if you want to build `rustc` with your system's LLVM, you will -need `llvm-config`. See [this section for more info][sysllvm]. +If building LLVM from source (the default), you'll need additional tools: + +* `g++` 5.1 or later, `clang++` 3.5 or later, or MSVC 2017 or later. +* `ninja`, or GNU `make` 3.81 or later (ninja is recommended, especially on Windows) +* `cmake` 3.4.3 or later + +Otherwise, you'll need LLVM installed and `llvm-config` in your path. +See [this section for more info][sysllvm]. [sysllvm]: ./suggested.md#building-with-system-llvm +### Windows + +For more information about building on Windows, +see [the Rust README](https://github.com/rust-lang/rust#msvc). + ## Hardware These are not so much requirements as _recommendations_: From 35af35dd890f41760a47ac551c294afc4f140437 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 3 Sep 2020 17:45:19 -0300 Subject: [PATCH 1197/1812] Add ./ to run x.py --- src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/queries/profiling.md b/src/queries/profiling.md index ad31c9e53..fc8846fc5 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -20,7 +20,7 @@ address [issue 42678](https://github.com/rust-lang/rust/issues/42678). Compile the compiler, up to at least stage 1: ``` -x.py build library/std +./x.py build library/std ``` ### 2. Run `rustc`, with flags From e1f750feda314d8f5710303d25b10a2ed86c2265 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 3 Sep 2020 18:14:12 -0300 Subject: [PATCH 1198/1812] Fix typo, hellow -> hello --- src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/queries/profiling.md b/src/queries/profiling.md index fc8846fc5..a89e05c74 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -139,7 +139,7 @@ These rows are **sorted by total duration**, in descending order. The following example `profile_queries.counts.txt` file results from running on a hello world program (a single main function that uses `println` to print -`"hellow world"). +`"hello world"). As explained above, the columns consist of `provider/pass`, `count`, `duration`: From 91bfaa8e20ad11efdd298e6e6dfa28e178520ecc Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 3 Sep 2020 18:16:53 -0300 Subject: [PATCH 1199/1812] Update def_id.rs location --- src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/queries/profiling.md b/src/queries/profiling.md index a89e05c74..ec04ad2c3 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -259,7 +259,7 @@ We give some background about the query model of the Rust compiler. In the query model, many queries have a key that consists of a Def ID. The Rust compiler uses Def IDs to distinguish definitions in the input Rust program. -From the compiler source code (`compiler/rustc_middle/src/hir/def_id.rs`): +From the compiler source code (`compiler/rustc_span/src/def_id.rs`): ``` /// A DefId identifies a particular *definition*, by combining a crate From af3a92e843a30ffa1f81034611260cf1ad215a1c Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 9 Sep 2020 16:24:41 +0000 Subject: [PATCH 1200/1812] Update src/queries/profiling.md Co-authored-by: Joshua Nelson --- src/queries/profiling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/queries/profiling.md b/src/queries/profiling.md index ec04ad2c3..7e0b68686 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -139,7 +139,7 @@ These rows are **sorted by total duration**, in descending order. The following example `profile_queries.counts.txt` file results from running on a hello world program (a single main function that uses `println` to print -`"hello world"). +`"hello world"`). As explained above, the columns consist of `provider/pass`, `count`, `duration`: From 7d544181379af99e80c7e48647f7a30acc90dd8c Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 8 Sep 2020 20:14:05 -0400 Subject: [PATCH 1201/1812] Document how to promote a target from cross-compiled to hosted --- src/building/new-target.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/building/new-target.md b/src/building/new-target.md index 24d47edad..022f8f1fb 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -99,3 +99,12 @@ compiler/rustc library/std If your target specification is already available in the bootstrap compiler, you can use it instead of the JSON file for both arguments. + +## Promoting a target from tier 2 (target) to tier 2 (host) + +There are two levels of tier 2 targets: +a) Targets that are only cross-compiled (`rustup target add`) +b) Targets that have a native toolchain (`rustup toolchain install`) + +For an example of promoting a target from cross-compiled to native, +see [!75914](https://github.com/rust-lang/rust/pull/75914). From 987b5ef0085c3ac490ad84a99f236351603b7537 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 9 Sep 2020 17:00:32 +0200 Subject: [PATCH 1202/1812] Update src/building/new-target.md --- src/building/new-target.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/new-target.md b/src/building/new-target.md index 022f8f1fb..91b337052 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -107,4 +107,4 @@ a) Targets that are only cross-compiled (`rustup target add`) b) Targets that have a native toolchain (`rustup toolchain install`) For an example of promoting a target from cross-compiled to native, -see [!75914](https://github.com/rust-lang/rust/pull/75914). +see [75914](https://github.com/rust-lang/rust/pull/75914). From 683cbdda74559b7d3cdc79ede2b4305f876a1102 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 14:36:46 -0400 Subject: [PATCH 1203/1812] Fix nit --- src/building/new-target.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/new-target.md b/src/building/new-target.md index 91b337052..3bb77f7fc 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -107,4 +107,4 @@ a) Targets that are only cross-compiled (`rustup target add`) b) Targets that have a native toolchain (`rustup toolchain install`) For an example of promoting a target from cross-compiled to native, -see [75914](https://github.com/rust-lang/rust/pull/75914). +see [#75914](https://github.com/rust-lang/rust/pull/75914). From 91a4afbcc6bb746b9b96dadfbc3752b4f6e1c7a6 Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Wed, 9 Sep 2020 15:13:18 -0700 Subject: [PATCH 1204/1812] broken intra-page link from spanview to graphviz Just noticed the link was not correct. Fixed here. --- src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index fce579253..9c69b1511 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -263,7 +263,7 @@ $ firefox maybe_init_suffix.pdf # Or your favorite pdf viewer ## Viewing Spanview output (.html files) [viewing-spanview-output]: #viewing-spanview-output -In addition to [graphviz output](#formatting-graphviz-output), MIR debugging +In addition to [graphviz output](#formatting-graphviz-output-dot-files), MIR debugging flags include an option to generate a MIR representation called `Spanview` that uses HTML to highlight code regions in the original source code and display compiler metadata associated with each region. From a7ac2cbad676652a0a3dc99e841d8e85162c1188 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 8 Sep 2020 13:32:09 -0700 Subject: [PATCH 1205/1812] Minor cleanup for "How to build and run" --- src/building/how-to-build-and-run.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 00127d560..0c96545ca 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -18,7 +18,7 @@ git clone https://github.com/rust-lang/rust.git cd rust ``` -## Create a config.toml +## Create a `config.toml` To start, copy [`config.toml.example`] to `config.toml`: @@ -122,9 +122,7 @@ It is, in particular, very useful when you're doing some kind of "type-based refactoring", like renaming a method, or changing the signature of some function. - - -Once you've created a config.toml, you are now ready to run +Once you've created a `config.toml`, you are now ready to run `x.py`. There are a lot of options here, but let's start with what is probably the best "go to" command for building a local rust: @@ -177,7 +175,7 @@ build. The **full** `rustc` build (what you get if you say `./x.py build ./x.py build library/core ``` -- Build the core and proc_macro libraries only +- Build only the core and `proc_macro` libraries ```bash ./x.py build library/core library/proc_macro @@ -186,7 +184,7 @@ build. The **full** `rustc` build (what you get if you say `./x.py build Sometimes you might just want to test if the part you’re working on can compile. Using these commands you can test that it compiles before doing a bigger build to make sure it works with the compiler. As shown before -you can also pass flags at the end such as --stage. +you can also pass flags at the end such as `--stage`. ## Creating a rustup toolchain @@ -215,13 +213,13 @@ your local environment: ```bash $ rustc +stage1 -vV -rustc 1.25.0-dev +rustc 1.48.0-dev binary: rustc commit-hash: unknown commit-date: unknown host: x86_64-unknown-linux-gnu -release: 1.25.0-dev -LLVM version: 4.0 +release: 1.48.0-dev +LLVM version: 11.0 ``` ## Other `x.py` commands @@ -252,4 +250,5 @@ everything up then you only need to run one command! ./x.py clean ``` -`rm -rf build` works too, but then you have to rebuild LLVM. +`rm -rf build` works too, but then you have to rebuild LLVM, which can take +a long time (on the order of a half-hour). From ab19c3eef8928bddce3e7f1e7cde0134e5018ae1 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 20:54:14 -0400 Subject: [PATCH 1206/1812] Use imprecise times, because the time to build depends on your computer Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 0c96545ca..af6123e16 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -251,4 +251,4 @@ everything up then you only need to run one command! ``` `rm -rf build` works too, but then you have to rebuild LLVM, which can take -a long time (on the order of a half-hour). +a long time even on fast computers. From d145fcdb4e56dc73b0f6e4a97514012d4206fbe5 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 9 Sep 2020 17:16:17 -0700 Subject: [PATCH 1207/1812] Update "Helpful Links" section --- src/contributing.md | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index e835eef84..c79dd3e3f 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -121,23 +121,23 @@ on the pull request with an `r+`. It will look something like this: @bors r+ -This tells [@bors][bors], our lovable integration bot, that your pull request has -been approved. The PR then enters the [merge queue][merge-queue], where [@bors][bors] +This tells [@bors], our lovable integration bot, that your pull request has +been approved. The PR then enters the [merge queue][merge-queue], where [@bors] will run all the tests on every platform we support. If it all works out, -[@bors][bors] will merge your code into `master` and close the pull request. +[@bors] will merge your code into `master` and close the pull request. Depending on the scale of the change, you may see a slightly different form of `r+`: @bors r+ rollup -The additional `rollup` tells [@bors][bors] that this change is eligible for to be +The additional `rollup` tells [@bors] that this change is eligible for to be "rolled up". Changes that are rolled up are tested and merged at the same time, to speed the process up. Typically only small changes that are expected not to conflict with one another are rolled up. [rust-highfive]: https://github.com/rust-highfive [steveklabnik]: https://github.com/steveklabnik -[bors]: https://github.com/bors +[@bors]: https://github.com/bors [merge-queue]: https://buildbot2.rust-lang.org/homu/queue/rust Speaking of tests, Rust has a comprehensive test suite. More information about @@ -476,27 +476,26 @@ For people new to Rust, and just starting to contribute, or even for more seasoned developers, some useful places to look for information are: -* The [rustc dev guide] contains information about how various parts of the +* This guide contains information about how various parts of the compiler work and how to contribute to the compiler * [Rust Forge][rustforge] contains additional documentation, including write-ups of how to achieve common tasks * The [Rust Internals forum][rif], a place to ask questions and discuss Rust's internals -* The [generated documentation for rust's compiler][gdfrustc] -* The [rust reference][rr], even though it doesn't specifically talk about - Rust's internals, it's a great resource nonetheless +* The [generated documentation for Rust's compiler][gdfrustc] +* The [Rust reference][rr], even though it doesn't specifically talk about + Rust's internals is a great resource nonetheless * Although out of date, [Tom Lee's great blog article][tlgba] is very helpful * [rustaceans.org][ro] is helpful, but mostly dedicated to IRC * The [Rust Compiler Testing Docs][rctd] -* For [@bors][bors], [this cheat sheet][cheatsheet] is helpful -(though you'll need to replace `@homu` with `@bors` in any commands) -* **Google!** ([search only in Rust Documentation][gsearchdocs] to find types, - traits, etc. quickly) +* For [@bors], [this cheat sheet][cheatsheet] is helpful +* **Google!** is always helpful when programming :) +* [Search Rust documentation][stddocs] to find types, traits, etc. quickly * Don't be afraid to ask! The Rust community is friendly and helpful. [rustc dev guide]: https://rustc-dev-guide.rust-lang.org/about-this-guide.html [gdfrustc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ -[gsearchdocs]: https://www.google.com/search?q=site:doc.rust-lang.org+your+query+here +[stddocs]: https://doc.rust-lang.org/std [rif]: http://internals.rust-lang.org [rr]: https://doc.rust-lang.org/book/README.html [rustforge]: https://forge.rust-lang.org/ From 9e00fdfc933dcc21ff415f7504a924013d62f3c8 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 9 Sep 2020 18:38:42 -0700 Subject: [PATCH 1208/1812] Add more info about Rustdoc --- src/contributing.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index c79dd3e3f..98b1a2d7f 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -490,7 +490,10 @@ are: * The [Rust Compiler Testing Docs][rctd] * For [@bors], [this cheat sheet][cheatsheet] is helpful * **Google!** is always helpful when programming :) -* [Search Rust documentation][stddocs] to find types, traits, etc. quickly +* [Search Rust documentation][stddocs] to find types, traits, etc. quickly. + You can also search by type signature! For example, searching for + `* -> vec` should find all functions that return a `Vec`. _Hint:_ Find + more tips and keyboard shortcuts by typing `?` on any Rustdoc page! * Don't be afraid to ask! The Rust community is friendly and helpful. [rustc dev guide]: https://rustc-dev-guide.rust-lang.org/about-this-guide.html From 3c353e4eec75e9d995206a8f9293985465ba6312 Mon Sep 17 00:00:00 2001 From: Camelid <37223377+camelid@users.noreply.github.com> Date: Wed, 9 Sep 2020 19:07:00 -0700 Subject: [PATCH 1209/1812] Add back comma Co-authored-by: Joshua Nelson --- src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index 98b1a2d7f..4ec87f78c 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -484,7 +484,7 @@ are: discuss Rust's internals * The [generated documentation for Rust's compiler][gdfrustc] * The [Rust reference][rr], even though it doesn't specifically talk about - Rust's internals is a great resource nonetheless + Rust's internals, is a great resource nonetheless * Although out of date, [Tom Lee's great blog article][tlgba] is very helpful * [rustaceans.org][ro] is helpful, but mostly dedicated to IRC * The [Rust Compiler Testing Docs][rctd] From 0b58331de0504139072e90deeceec8b5b97d30c4 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 9 Sep 2020 19:29:47 -0700 Subject: [PATCH 1210/1812] Add back information about Googling Also cleaned up some other things. --- src/contributing.md | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 4ec87f78c..80b3ea5a4 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -453,17 +453,15 @@ If you're looking for somewhere to start, check out the [E-easy][eeasy] tag. ## Out-of-tree Contributions There are a number of other ways to contribute to Rust that don't deal with -rust-lang/rust. +rust-lang/rust: -Answer questions in the _Get Help!_ channels from the [Rust Discord -server][rust-discord], on [users.rust-lang.org][users], or on -[StackOverflow][so]. - -Participate in the [RFC process](https://github.com/rust-lang/rfcs). - -Find a [requested community library][community-library], build it, and publish -it to [Crates.io](http://crates.io). Easier said than done, but very, very -valuable! +* Answer questions in the _Get Help!_ channels on the [Rust Discord + server][rust-discord], on [users.rust-lang.org][users], or on + [StackOverflow][so]. +* Participate in the [RFC process](https://github.com/rust-lang/rfcs). +* Find a [requested community library][community-library], build it, and publish + it to [Crates.io](http://crates.io). Easier said than done, but very, very + valuable! [rust-discord]: https://discord.gg/rust-lang [users]: https://users.rust-lang.org/ @@ -489,20 +487,26 @@ are: * [rustaceans.org][ro] is helpful, but mostly dedicated to IRC * The [Rust Compiler Testing Docs][rctd] * For [@bors], [this cheat sheet][cheatsheet] is helpful -* **Google!** is always helpful when programming :) -* [Search Rust documentation][stddocs] to find types, traits, etc. quickly. - You can also search by type signature! For example, searching for - `* -> vec` should find all functions that return a `Vec`. _Hint:_ Find - more tips and keyboard shortcuts by typing `?` on any Rustdoc page! +* Google is always helpful when programming. + You can [search all Rust documentation][gsearchdocs] (the standard library, + the compiler, the books, the references, and the guides) to quickly find + information about the language and compiler. +* You can also use Rustdoc's built-in search feature to find documentation on + types and functions within the crates you're looking at. You can also search + by type signature! For example, searching for `* -> vec` should find all + functions that return a `Vec`. + _Hint:_ Find more tips and keyboard shortcuts by typing `?` on any Rustdoc + page! * Don't be afraid to ask! The Rust community is friendly and helpful. [rustc dev guide]: https://rustc-dev-guide.rust-lang.org/about-this-guide.html [gdfrustc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ +[gsearchdocs]: https://www.google.com/search?q=site:doc.rust-lang.org+your+query+here [stddocs]: https://doc.rust-lang.org/std [rif]: http://internals.rust-lang.org [rr]: https://doc.rust-lang.org/book/README.html [rustforge]: https://forge.rust-lang.org/ [tlgba]: http://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/ -[ro]: http://www.rustaceans.org/ +[ro]: https://www.rustaceans.org/ [rctd]: https://rustc-dev-guide.rust-lang.org/tests/intro.html [cheatsheet]: https://buildbot2.rust-lang.org/homu/ From b3b8f0ad6c9e4883e63e1663f402a79b549fbbb6 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 10 Sep 2020 18:29:08 -0400 Subject: [PATCH 1211/1812] Fix incorrect docs about stages `build library/core` builds the compiler, not just the standard library. --- src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index af6123e16..07c8ed069 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -172,7 +172,7 @@ build. The **full** `rustc` build (what you get if you say `./x.py build - Build only the core library ```bash -./x.py build library/core +./x.py build --stage 0 library/core ``` - Build only the core and `proc_macro` libraries From a85aed08e4d00f29c1ce8dc6876f6cccb0387fd5 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 10 Sep 2020 23:50:12 -0400 Subject: [PATCH 1212/1812] Fix other library commands --- src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 07c8ed069..177fa20d2 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -178,7 +178,7 @@ build. The **full** `rustc` build (what you get if you say `./x.py build - Build only the core and `proc_macro` libraries ```bash -./x.py build library/core library/proc_macro +./x.py build --stage 0 library/core library/proc_macro ``` Sometimes you might just want to test if the part you’re working on can From ee99dea822d95e3bfef58b455e30a4080a044b09 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Thu, 10 Sep 2020 17:05:38 +0200 Subject: [PATCH 1213/1812] Clean up 'Contributing to Rust - Pull Requests' --- src/contributing.md | 90 +++++++++++++++++++++++++++------------------ 1 file changed, 54 insertions(+), 36 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 80b3ea5a4..b7f0b7f5c 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -67,41 +67,15 @@ in the appropriate provided template. ## Pull Requests -Pull requests are the primary mechanism we use to change Rust. GitHub itself -has some [great documentation][about-pull-requests] on using the Pull Request feature. -We use the "fork and pull" model [described here][development-models], where -contributors push changes to their personal fork and create pull requests to +Pull requests (or PRs for short) are the primary mechanism we use to change Rust. +GitHub itself has some [great documentation][about-pull-requests] on using the +Pull Request feature. We use the "fork and pull" model [described here][development-models], +where contributors push changes to their personal fork and create pull requests to bring those changes into the source repository. [about-pull-requests]: https://help.github.com/articles/about-pull-requests/ [development-models]: https://help.github.com/articles/about-collaborative-development-models/ -Please make pull requests against the `master` branch. - -Rust follows a _no merge-commit policy_, meaning, when you encounter merge -conflicts you are expected to always rebase instead of merge. E.g. always use -rebase when bringing the latest changes from the master branch to your feature -branch. Also, please make sure that fixup commits are squashed into other -related commits with meaningful commit messages. - -GitHub allows [closing issues using keywords][closing-keywords]. This feature -should be used to keep the issue tracker tidy. However, it is generally preferred -to put the "closes #123" text in the PR description rather than the issue commit; -particularly during rebasing, citing the issue number in the commit can "spam" -the issue in question. - -[closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords - -Please make sure your pull request is in compliance with Rust's style -guidelines by running - - $ ./x.py test tidy - -Make this check before every pull request (and every new commit in a pull -request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) -before every push to make sure you never forget to make this check. The -CI will also run tidy and will fail if tidy fails. - All pull requests are reviewed by another person. We have a bot, [@rust-highfive][rust-highfive], that will automatically assign a random person to review your request. @@ -116,6 +90,21 @@ make a documentation change, add to the end of the pull request description, and [@rust-highfive][rust-highfive] will assign [@steveklabnik][steveklabnik] instead of a random person. This is entirely optional. +In addition to being reviewed by a human, pull requests are automatically tested +thanks to continuous integration (CI). Basically, every time you open and update +a pull request, the CI builds the compiler and tests it against the +[compiler test suite][rctd], and also performs other tests such as checking that +your pull request is in compliance with Rust's style guidelines. + +Running continuous integration tests allows PR authors to catch mistakes early +without going through a first review cycle, and also helps reviewers stay aware +of the status of a particular pull request. + +Rust has plenty of CI capacity, and you should never have to worry about wasting +computational resources each time you push a change. It is also perfectly fine +(and even encouraged!) to use the CI to test your changes if it can help your +productivity, e.g. if your machine is not very powerful. + After someone has reviewed your pull request, they will leave an annotation on the pull request with an `r+`. It will look something like this: @@ -123,25 +112,54 @@ on the pull request with an `r+`. It will look something like this: This tells [@bors], our lovable integration bot, that your pull request has been approved. The PR then enters the [merge queue][merge-queue], where [@bors] -will run all the tests on every platform we support. If it all works out, +will run *all* the tests on *every* platform we support. If it all works out, [@bors] will merge your code into `master` and close the pull request. Depending on the scale of the change, you may see a slightly different form of `r+`: @bors r+ rollup -The additional `rollup` tells [@bors] that this change is eligible for to be -"rolled up". Changes that are rolled up are tested and merged at the same time, to +The additional `rollup` tells [@bors] that this change should always be "rolled up". +Changes that are rolled up are tested and merged alongside other PRs, to speed the process up. Typically only small changes that are expected not to conflict -with one another are rolled up. +with one another are marked as "always roll up". [rust-highfive]: https://github.com/rust-highfive [steveklabnik]: https://github.com/steveklabnik [@bors]: https://github.com/bors [merge-queue]: https://buildbot2.rust-lang.org/homu/queue/rust -Speaking of tests, Rust has a comprehensive test suite. More information about -it can be found [here][rctd]. +### Opening a PR + +You are now ready to file a pull request? Great! Here are a few points you +should be aware of. + +All pull requests should be filed against the `master` branch, except in very +particular scenarios. Unless you know for sure that you should target another +branch, `master` will be the right choice. + +Make sure your pull request is in compliance with Rust's style guidelines by running + + $ ./x.py test tidy + +We recommand to make this check before every pull request (and every new commit +in a pull request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) +before every push to make sure you never forget to make this check. The +CI will also run tidy and will fail if tidy fails. + +Rust follows a _no merge-commit policy_, meaning, when you encounter merge +conflicts you are expected to always rebase instead of merging. E.g. always use +rebase when bringing the latest changes from the master branch to your feature +branch. Also, please make sure that fixup commits are squashed into other +related commits with meaningful commit messages. + +GitHub allows [closing issues using keywords][closing-keywords]. This feature +should be used to keep the issue tracker tidy. However, it is generally preferred +to put the "closes #123" text in the PR description rather than the issue commit; +particularly during rebasing, citing the issue number in the commit can "spam" +the issue in question. + +[closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords ### External Dependencies (subtree) From 6366c1dbaae299b04517541557889b4c14a20ccf Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Thu, 10 Sep 2020 17:59:53 +0200 Subject: [PATCH 1214/1812] Apply suggestions from code review Co-authored-by: Joshua Nelson --- src/contributing.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index b7f0b7f5c..350b991a4 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -92,7 +92,7 @@ to the end of the pull request description, and [@rust-highfive][rust-highfive] In addition to being reviewed by a human, pull requests are automatically tested thanks to continuous integration (CI). Basically, every time you open and update -a pull request, the CI builds the compiler and tests it against the +a pull request, CI builds the compiler and tests it against the [compiler test suite][rctd], and also performs other tests such as checking that your pull request is in compliance with Rust's style guidelines. @@ -103,7 +103,8 @@ of the status of a particular pull request. Rust has plenty of CI capacity, and you should never have to worry about wasting computational resources each time you push a change. It is also perfectly fine (and even encouraged!) to use the CI to test your changes if it can help your -productivity, e.g. if your machine is not very powerful. +productivity. In particular, we don't recommend running the full `x.py test` suite locally, +since it takes a very long time to execute. After someone has reviewed your pull request, they will leave an annotation on the pull request with an `r+`. It will look something like this: @@ -136,11 +137,11 @@ should be aware of. All pull requests should be filed against the `master` branch, except in very particular scenarios. Unless you know for sure that you should target another -branch, `master` will be the right choice. +branch, `master` will be the right choice (it's also the default). Make sure your pull request is in compliance with Rust's style guidelines by running - $ ./x.py test tidy + $ ./x.py test tidy --bless We recommand to make this check before every pull request (and every new commit in a pull request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) From 150b915338bac3e6fcf903433c122e00cafdc153 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 13:02:54 +0200 Subject: [PATCH 1215/1812] Fix typo Co-authored-by: Tshepang Lekhonkhobe --- src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index 350b991a4..f158d1635 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -143,7 +143,7 @@ Make sure your pull request is in compliance with Rust's style guidelines by run $ ./x.py test tidy --bless -We recommand to make this check before every pull request (and every new commit +We recommend to make this check before every pull request (and every new commit in a pull request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) before every push to make sure you never forget to make this check. The CI will also run tidy and will fail if tidy fails. From cccee1a93e1429784c7fa24048f075de59dab060 Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Fri, 11 Sep 2020 16:49:05 -0700 Subject: [PATCH 1216/1812] Improve link and description of entry points in parser section (#876) This seemed to be out of date! --- src/the-parser.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/the-parser.md b/src/the-parser.md index 7c59ddfe7..d3e48a17e 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -29,8 +29,8 @@ high-level interface to the lexer and some validation routines that run after macro expansion. In particular, the [`rustc_parse::parser`][parser] contains the parser implementation. -The main entrypoint to the parser is via the various `parse_*` functions in the -[parser][parser]. They let you do things like turn a [`SourceFile`][sourcefile] +The main entrypoint to the parser is via the various `parse_*` functions and others in the +[parser crate][parser_lib]. They let you do things like turn a [`SourceFile`][sourcefile] (e.g. the source in a single file) into a token stream, create a parser from the token stream, and then execute the parser to get a `Crate` (the root AST node). @@ -62,6 +62,7 @@ Code for lexical analysis is split between two crates: [`SourceMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/source_map/struct.SourceMap.html [ast module]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/index.html [rustc_parse]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html +[parser_lib]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/index.html [`Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/parse/parser/struct.Parser.html [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html From e616159576547bc38571d01437569e038dce0a3c Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 18:41:51 +0200 Subject: [PATCH 1217/1812] Add a chapter on useful `@rustbot` commands --- src/SUMMARY.md | 1 + src/contributing.md | 17 ++++++++++--- src/rustbot.md | 62 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 76 insertions(+), 4 deletions(-) create mode 100644 src/rustbot.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index edf97c6db..d1560c960 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -31,6 +31,7 @@ - [Introduction](./contributing.md) - [About the compiler team](./compiler-team.md) +- [Mastering @rustbot](./rustbot.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [Bug Fix Procedure](./bug-fix-procedure.md) - [Implementing new features](./implementing_new_features.md) diff --git a/src/contributing.md b/src/contributing.md index f158d1635..af3bd7b81 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -154,12 +154,17 @@ rebase when bringing the latest changes from the master branch to your feature branch. Also, please make sure that fixup commits are squashed into other related commits with meaningful commit messages. +If you encounter merge commits, your PR will get marked as `S-waiting-on-author`. +When you resolve them, you should use `@rustbot` to mark it as `S-waiting-on-review`. +See [this chapter][labeling] for more details. + GitHub allows [closing issues using keywords][closing-keywords]. This feature should be used to keep the issue tracker tidy. However, it is generally preferred to put the "closes #123" text in the PR description rather than the issue commit; particularly during rebasing, citing the issue number in the commit can "spam" the issue in question. +[labeling]: ./rustbot.md#issue-relabeling [closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords ### External Dependencies (subtree) @@ -413,8 +418,8 @@ still valid. Load up an older issue, double check that it's still true, and leave a comment letting us know if it is or is not. The [least recently updated sort][lru] is good for finding issues like this. -Contributors with sufficient permissions on the Rust repo can help by adding -labels to triage issues: +[Thanks to `@rustbot`][rustbot], anyone can help triaging issues by adding +appropriate labels to issues that haven't been triaged yet: * Yellow, **A**-prefixed labels state which **area** of the project an issue relates to. @@ -435,7 +440,9 @@ labels to triage issues: * Red, **I**-prefixed labels indicate the **importance** of the issue. The [I-nominated][inom] label indicates that an issue has been nominated for - prioritizing at the next triage meeting. + prioritizing at the next triage meeting. Similarely, the [I-prioritize][ipri] + indicates that an issue has been requested to be prioritized by the + appropriate team. * The purple **metabug** label marks lists of bugs collected by other categories. @@ -444,7 +451,7 @@ labels to triage issues: that this issue is specific to. * Orange, **P**-prefixed labels indicate a bug's **priority**. These labels - are only assigned during triage meetings, and replace the [I-nominated][inom] + are only assigned during triage meetings, and replace the [I-prioritize][ipri] label. * The gray **proposed-final-comment-period** label marks bugs that are using @@ -464,7 +471,9 @@ labels to triage issues: If you're looking for somewhere to start, check out the [E-easy][eeasy] tag. +[rustbot]: ./rustbot.md [inom]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-nominated +[ipri]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-prioritize [eeasy]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy [lru]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc [rfcbot]: https://github.com/anp/rfcbot-rs/ diff --git a/src/rustbot.md b/src/rustbot.md new file mode 100644 index 000000000..1c75b6eba --- /dev/null +++ b/src/rustbot.md @@ -0,0 +1,62 @@ +# Mastering @rustbot + +`@rustbot` (also known as `triagebot`) is a utility robot that is mostly used to +allow any contributor to achieve certain tasks that would normally require GitHub +membership to the `rust-lang` organization. Its most interesting features for +contributors to `rustc` are isssue claiming and relabeling. + +## Issue claiming + +`@rustbot` exposes a command that allows anyone to assign an issue to themselves. +If you see an issue you want to work on, you can send the following message as a +comment on the issue at hand: + + @rustbot claim + +If you are a member of the `rust-lang` organization, `@rustbot` will assign the +issue to you. Otherwise, `@rustbot` will assign itself as a placeholder and edit +the top comment to reflect the fact that the issue is now assigned to you. + +If you want to unassign from an issue, `@rustbot` has a different command: + + @rustbot release-assignment + +## Issue relabeling + +Changing labels for an issue or PR is also normally reserved to members of the +organization. However, `@rustdoc` allows you to relabel an issue yourself, only +with a few restrictions. This is mostly useful in two cases: + +**Helping with issue triage**: Rust's issue tracker has more than 5,000 open +issues at the time of this writing, so labels are the most powerful tool that we +have to keep it as tidy as possible. You may not spend hours in the issue tracker +to triage issues, but if you open an issue, you should feel free to label it if +you are comfortable with doing it yourself. + +**Updating the status of a PR**: we use "status labels" to reflect the status of +PRs. For example, if your PR has merge conflicts, it will automatically be assigned +the `S-waiting-on-author`, and reviewers might not review it until you rebase your +PR. Once you did rebase your branch, you should change the labels yourself to remove +the `S-waiting-on-author` label and add back `S-waiting-on-review`. In this case, +the `@rustbot` command will look like this: + + @rustbot modify labels: -S-waiting-on-author +S-waiting-on-review + +The syntax for this command is pretty loose, so there are other variants of this +command invocation. For more details, see [the wiki page about labeling][labeling]. + +[labeling]: https://github.com/rust-lang/triagebot/wiki/Labeling + +## Other commands + +If you are interested in seeing what `@rustbot` is capable of, check out its [wiki], +which is meant as a reference for the bot and should be kept up to date every time the +bot gets an upgrade. + +`@rustbot` is maintained by the Release team. If you have any feedback regarding +existing commands or suggestions for new commands, feel free to reach out +[on Zulip][zulip] or file an issue in [the triagebot repository][repo] + +[wiki]: https://github.com/rust-lang/triagebot/wiki +[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/224082-t-release.2Ftriagebot +[repo]: https://github.com/rust-lang/triagebot/ From 58c2b85aa9ef3c304c68d01bd557075c803a5b35 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 11 Sep 2020 21:59:39 +0200 Subject: [PATCH 1218/1812] Update src/contributing.md --- src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index af3bd7b81..98dbb4638 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -440,7 +440,7 @@ appropriate labels to issues that haven't been triaged yet: * Red, **I**-prefixed labels indicate the **importance** of the issue. The [I-nominated][inom] label indicates that an issue has been nominated for - prioritizing at the next triage meeting. Similarely, the [I-prioritize][ipri] + prioritizing at the next triage meeting. Similarly, the [I-prioritize][ipri] indicates that an issue has been requested to be prioritized by the appropriate team. From 1d9675c905282006c6642294fbf47da651330a90 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 11 Sep 2020 21:59:48 +0200 Subject: [PATCH 1219/1812] Update src/contributing.md Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index 98dbb4638..2289ede19 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -418,7 +418,7 @@ still valid. Load up an older issue, double check that it's still true, and leave a comment letting us know if it is or is not. The [least recently updated sort][lru] is good for finding issues like this. -[Thanks to `@rustbot`][rustbot], anyone can help triaging issues by adding +[Thanks to `@rustbot`][rustbot], anyone can help triage issues by adding appropriate labels to issues that haven't been triaged yet: * Yellow, **A**-prefixed labels state which **area** of the project an issue From 3c749064d335f25774a8b5803bd80095fe26975a Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 11 Sep 2020 22:02:13 +0200 Subject: [PATCH 1220/1812] Update src/rustbot.md --- src/rustbot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustbot.md b/src/rustbot.md index 1c75b6eba..880c35a82 100644 --- a/src/rustbot.md +++ b/src/rustbot.md @@ -24,7 +24,7 @@ If you want to unassign from an issue, `@rustbot` has a different command: ## Issue relabeling Changing labels for an issue or PR is also normally reserved to members of the -organization. However, `@rustdoc` allows you to relabel an issue yourself, only +organization. However, `@rustbot` allows you to relabel an issue yourself, only with a few restrictions. This is mostly useful in two cases: **Helping with issue triage**: Rust's issue tracker has more than 5,000 open From 5fa00e007462539ac6af5ded44d7d8f05459562d Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 11 Sep 2020 22:04:04 +0200 Subject: [PATCH 1221/1812] Update src/rustbot.md --- src/rustbot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustbot.md b/src/rustbot.md index 880c35a82..d7164d0e0 100644 --- a/src/rustbot.md +++ b/src/rustbot.md @@ -36,7 +36,7 @@ you are comfortable with doing it yourself. **Updating the status of a PR**: we use "status labels" to reflect the status of PRs. For example, if your PR has merge conflicts, it will automatically be assigned the `S-waiting-on-author`, and reviewers might not review it until you rebase your -PR. Once you did rebase your branch, you should change the labels yourself to remove +PR. Once you do rebase your branch, you should change the labels yourself to remove the `S-waiting-on-author` label and add back `S-waiting-on-review`. In this case, the `@rustbot` command will look like this: From ff958b3d4b30288d8eddd7c5d5ad115fae7dc4e9 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 12 Sep 2020 15:28:15 +0200 Subject: [PATCH 1222/1812] Apply suggestions from code review Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> Co-authored-by: Joshua Nelson --- src/contributing.md | 2 +- src/rustbot.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 2289ede19..08ece467c 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -154,7 +154,7 @@ rebase when bringing the latest changes from the master branch to your feature branch. Also, please make sure that fixup commits are squashed into other related commits with meaningful commit messages. -If you encounter merge commits, your PR will get marked as `S-waiting-on-author`. +If you encounter merge conflicts, your PR will get marked as `S-waiting-on-author`. When you resolve them, you should use `@rustbot` to mark it as `S-waiting-on-review`. See [this chapter][labeling] for more details. diff --git a/src/rustbot.md b/src/rustbot.md index d7164d0e0..d0bbee301 100644 --- a/src/rustbot.md +++ b/src/rustbot.md @@ -29,11 +29,11 @@ with a few restrictions. This is mostly useful in two cases: **Helping with issue triage**: Rust's issue tracker has more than 5,000 open issues at the time of this writing, so labels are the most powerful tool that we -have to keep it as tidy as possible. You may not spend hours in the issue tracker +have to keep it as tidy as possible. You don't need to spend hours in the issue tracker to triage issues, but if you open an issue, you should feel free to label it if you are comfortable with doing it yourself. -**Updating the status of a PR**: we use "status labels" to reflect the status of +**Updating the status of a PR**: We use "status labels" to reflect the status of PRs. For example, if your PR has merge conflicts, it will automatically be assigned the `S-waiting-on-author`, and reviewers might not review it until you rebase your PR. Once you do rebase your branch, you should change the labels yourself to remove From e64ac0997efb663b67620c4f90c016d136fa81b3 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 12 Sep 2020 17:35:53 +0200 Subject: [PATCH 1223/1812] Hide `@rustdoc` implementation details --- src/rustbot.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/rustbot.md b/src/rustbot.md index d0bbee301..275e07a70 100644 --- a/src/rustbot.md +++ b/src/rustbot.md @@ -13,9 +13,10 @@ comment on the issue at hand: @rustbot claim -If you are a member of the `rust-lang` organization, `@rustbot` will assign the -issue to you. Otherwise, `@rustbot` will assign itself as a placeholder and edit -the top comment to reflect the fact that the issue is now assigned to you. +This will tell `@rustbot` to assign the issue to you if it has no assignee yet. +Note that because of some GitHub restrictions, you may be assigned indireclty, +i.e. `@rustbot` will assign itself as a placeholder and edit the top comment to +reflect the fact that the issue is now assigned to you. If you want to unassign from an issue, `@rustbot` has a different command: From 716adae5acdafd33b81ab87664c4964638bb5b08 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 12 Sep 2020 17:56:53 +0200 Subject: [PATCH 1224/1812] Fix typo --- src/rustbot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustbot.md b/src/rustbot.md index 275e07a70..53211f297 100644 --- a/src/rustbot.md +++ b/src/rustbot.md @@ -14,7 +14,7 @@ comment on the issue at hand: @rustbot claim This will tell `@rustbot` to assign the issue to you if it has no assignee yet. -Note that because of some GitHub restrictions, you may be assigned indireclty, +Note that because of some GitHub restrictions, you may be assigned indirectly, i.e. `@rustbot` will assign itself as a placeholder and edit the top comment to reflect the fact that the issue is now assigned to you. From e7b11c1d89acd021d6c0410fb0b604f3a824814d Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 8 Sep 2020 20:20:08 -0400 Subject: [PATCH 1225/1812] Document edition flag for UI tests --- src/tests/adding.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index c74f6cec4..57ee49338 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -179,6 +179,7 @@ source. supposed to error out. * `compile-flags` passes extra command-line args to the compiler, e.g. `compile-flags -g` which forces debuginfo to be enabled. +* `edition` controls the edition the test should be compiled with: `// edition:2018` * `should-fail` indicates that the test should fail; used for "meta testing", where we test the compiletest program itself to check that it will generate errors in appropriate scenarios. This header is From d333d1e74f542727510762f9b5aac0846ea79849 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 08:50:04 -0400 Subject: [PATCH 1226/1812] Note that the default is 2015 --- src/tests/adding.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 57ee49338..4576e377e 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -179,7 +179,8 @@ source. supposed to error out. * `compile-flags` passes extra command-line args to the compiler, e.g. `compile-flags -g` which forces debuginfo to be enabled. -* `edition` controls the edition the test should be compiled with: `// edition:2018` +* `edition` controls the edition the test should be compiled with (defaults to 2015). + Example usage: `// edition:2018` * `should-fail` indicates that the test should fail; used for "meta testing", where we test the compiletest program itself to check that it will generate errors in appropriate scenarios. This header is From 434556f9e001773d347f2ce025e308cb0a5152b6 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 9 Sep 2020 20:38:53 -0400 Subject: [PATCH 1227/1812] Address nits --- src/tests/adding.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 4576e377e..c88d5e81d 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -179,8 +179,8 @@ source. supposed to error out. * `compile-flags` passes extra command-line args to the compiler, e.g. `compile-flags -g` which forces debuginfo to be enabled. -* `edition` controls the edition the test should be compiled with (defaults to 2015). - Example usage: `// edition:2018` +* `edition` controls the edition the test should be compiled with + (defaults to 2015). Example usage: `// edition:2018`. * `should-fail` indicates that the test should fail; used for "meta testing", where we test the compiletest program itself to check that it will generate errors in appropriate scenarios. This header is From 2c733c97e8d176839227c633bf09b66734376b45 Mon Sep 17 00:00:00 2001 From: Monadic Cat Date: Sat, 12 Sep 2020 17:06:58 -0500 Subject: [PATCH 1228/1812] correct attribute used here --- src/stability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/stability.md b/src/stability.md index 9255f4b57..1cbbcb849 100644 --- a/src/stability.md +++ b/src/stability.md @@ -62,7 +62,7 @@ there's no way to add `const` to functions in `extern` blocks for now. ## rustc_const_stable -The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks +The `#[rustc_const_stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks a `const fn` as having its constness be `stable`. This attribute can make sense even on an `unstable` function, if that function is called from another `rustc_const_stable` function. From ed3d2551531563345288db242f2581dc29434fbe Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Sat, 12 Sep 2020 19:20:37 -0700 Subject: [PATCH 1229/1812] Initial draft of MIR dataflow framework docs --- src/SUMMARY.md | 1 + src/mir/dataflow.md | 165 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 166 insertions(+) create mode 100644 src/mir/dataflow.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index d1560c960..25ea76e78 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -110,6 +110,7 @@ - [Variance](./variance.md) - [Opaque Types](./opaque-types-type-alias-impl-trait.md) - [Pattern and Exhaustiveness Checking](./pat-exhaustive-checking.md) +- [MIR dataflow](./mir/dataflow.md) - [The borrow checker](./borrow_check.md) - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md new file mode 100644 index 000000000..abe04e376 --- /dev/null +++ b/src/mir/dataflow.md @@ -0,0 +1,165 @@ +# Dataflow Analysis + +If you work on the MIR, you will frequently come across various flavors of +[dataflow analysis][wiki]. For example, `rustc` uses dataflow to find +uninitialized variables, determine what variables are live across a generator +`yield` statement, and compute which `Place`s are borrowed at a given point in +the control-flow graph. Dataflow analysis is a fundamental concept in modern +compilers, and knowledge of the subject will be helpful to prospective +contributors. + +However, this documentation is not a general introduction to dataflow analysis. +It is merely a description of the framework used to define these analyses in +`rustc`. It assumes that the reader is familiar with some basic terminology, +such as "transfer function", "fixpoint" and "lattice". If you're unfamiliar +with these terms, or if you want a quick refresher, [*Static Program Analysis*] +by Anders Møller and Michael I. Schwartzbach is an excellent, freely available +textbook. For those who prefer audiovisual learning, the Goethe University +Frankfurt has published a series of short [youtube lectures][goethe] in English +that are very approachable. + +## Defining a Dataflow Analysis + +The interface for dataflow analyses is split into three traits. The first is +[`AnalysisDomain`], which must be implemented by *all* analyses. In addition to +the type of the dataflow state, this trait defines the initial value of that +state at entry to each block, as well as the direction of the analysis, either +forward or backward. The domain of your dataflow analysis must be a [lattice][] +(strictly speaking a join-semilattice) with a well-behaved `join` operator. See +documentation for the [`lattice`] module, as well as the [`JoinSemiLattice`] +trait, for more information. + +You must then provide *either* a direct implementation of the [`Analysis`] trait +*or* an implementation of the proxy trait [`GenKillAnalysis`]. The latter is for +so-called ["gen-kill" problems], which have a simple class of transfer function +that can be applied very efficiently. Analyses whose domain is not a `BitSet` +of some index type, or whose transfer functions cannot be expressed through +"gen" and "kill" operations, must implement `Analysis` directly, and will run +slower as a result. All implementers of `GenKillAnalysis` also implement +`Analysis` automatically via a default `impl`. + + +```text + AnalysisDomain + ^ + | | = has as a supertrait + | . = provides a default impl for + | + Analysis + ^ ^ + | . + | . + | . + GenKillAnalysis + +``` + +### Transfer Functions and Effects + +The dataflow framework in `rustc` allows each statement inside a basic block as +well as the terminator to define its own transfer function. For brevity, these +individual transfer functions are known as "effects". Each effect is applied +successively in dataflow order, and together they define the transfer function +for the entire basic block. It's also possible to define an effect for +particular outgoing edges of some terminators (e.g. +[`apply_call_return_effect`] for the `success` edge of a `Call` +terminator). Collectively, these are known as per-edge effects. + +The only meaningful difference (besides the "apply" prefix) between the methods +of the `GenKillAnalysis` trait and the `Analysis` trait is that an `Analysis` +has direct, mutable access to the dataflow state, whereas a `GenKillAnalysis` +only sees an implementer of the `GenKill` trait, which only allows the `gen` +and `kill` operations for mutation. + +Observant readers of the documentation for these traits may notice that there +are actually *two* possible effects for each statement and terminator, the +"before" effect and the unprefixed (or "primary") effect. The "before" effects +are applied immediately before the unprefixed effect **regardless of whether +the analysis is backward or forward**. The vast majority of analyses should use +only the unprefixed effects: Having multiple effects for each statement makes +it difficult for consumers to know where they should be looking. However, the +"before" variants can be useful in some scenarios, such as when the effect of +the right-hand side of an assignment statement must be considered separately +from the left-hand side. + +### Convergence + +TODO + +## Inspecting the Results of a Dataflow Analysis + +Once you have constructed an analysis, you must pass it to an [`Engine`], which +is responsible for finding the steady-state solution to your dataflow problem. +You should use the [`into_engine`] method defined on the `Analysis` trait for +this, since it will use the more efficient `Engine::new_gen_kill` constructor +when possible. + +Calling `iterate_to_fixpoint` on your `Engine` will return a `Results`, which +contains the dataflow state at fixpoint upon entry of each block. Once you have +a `Results`, you can can inspect the dataflow state at fixpoint at any point in +the CFG. If you only need the state at a few locations (e.g., each `Drop` +terminator) use a [`ResultsCursor`]. If you need the state at *every* location, +a [`ResultsVisitor`] will be more efficient. + +```text + Analysis + | + | into_engine(…) + | + Engine + | + | iterate_to_fixpoint() + | + Results + / \ + into_results_cursor(…) / \ visit_with(…) + / \ + ResultsCursor ResultsVisitor +``` + +For example, the following code uses a [`ResultsVisitor`]... + + +```rust,ignore +// Assuming `MyVisitor` implements `ResultsVisitor`... +let my_visitor = MyVisitor::new(); + +// inspect the fixpoint state for every location within every block in RPO. +let results = MyAnalysis() + .into_engine(tcx, body, def_id) + .iterate_to_fixpoint() + .visit_with(body, traversal::reverse_postorder(body), &mut my_visitor); +``` + +whereas this code uses [`ResultsCursor`]: + +```rust,ignore +let mut results = MyAnalysis() + .into_engine(tcx, body, def_id) + .iterate_to_fixpoint() + .into_results_cursor(body); + +// Inspect the fixpoint state immediately before each `Drop` terminator. +for (bb, block) in body.basic_blocks().iter_enumerated() { + if let TerminatorKind::Drop { .. } = block.terminator().kind { + results.seek_before_primary_effect(body.terminator_loc(bb)); + let state = results.get(); + println!("state before drop: {:#?}", state); + } +} +``` + +["gen-kill" problems]: https://en.wikipedia.org/wiki/Data-flow_analysis#Bit_vector_problems +[*Static Program Analysis*]: https://cs.au.dk/~amoeller/spa/ +[`AnalysisDomain`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.AnalysisDomain.html +[`Analysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.Analysis.html +[`GenKillAnalysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.GenKillAnalysis.html +[`JoinSemiLattice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/lattice/trait.JoinSemiLattice.html +[`ResultsCursor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/struct.ResultsCursor.html +[`ResultsVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.ResultsVisitor.html +[`apply_call_return_effect`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.Analysis.html#tymethod.apply_call_return_effect +[`into_engine`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.Analysis.html#method.into_engine +[`lattice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/lattice/index.html +[goethe]: https://www.youtube.com/watch?v=NVBQSR_HdL0&list=PL_sGR8T76Y58l3Gck3ZwIIHLWEmXrOLV_&index=2 +[lattice]: https://en.wikipedia.org/wiki/Lattice_(order) +[wiki]: https://en.wikipedia.org/wiki/Data-flow_analysis#Basic_principles From e8003db79a3162e0713d27a128016d425326d07d Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Sun, 13 Sep 2020 12:22:57 -0700 Subject: [PATCH 1230/1812] Add missing link to `Engine` --- src/mir/dataflow.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index abe04e376..e83c4ebb3 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -153,6 +153,7 @@ for (bb, block) in body.basic_blocks().iter_enumerated() { [*Static Program Analysis*]: https://cs.au.dk/~amoeller/spa/ [`AnalysisDomain`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.AnalysisDomain.html [`Analysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.Analysis.html +[`Engine`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/struct.Engine.html [`GenKillAnalysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.GenKillAnalysis.html [`JoinSemiLattice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/lattice/trait.JoinSemiLattice.html [`ResultsCursor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/struct.ResultsCursor.html From 92fdaa6c421c127c01810d1b046af9b0a18378fa Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Sun, 13 Sep 2020 12:24:46 -0700 Subject: [PATCH 1231/1812] Line edits --- src/mir/dataflow.md | 53 +++++++++++++++++++++++++-------------------- 1 file changed, 29 insertions(+), 24 deletions(-) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index e83c4ebb3..9f93921b4 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -1,22 +1,22 @@ # Dataflow Analysis If you work on the MIR, you will frequently come across various flavors of -[dataflow analysis][wiki]. For example, `rustc` uses dataflow to find -uninitialized variables, determine what variables are live across a generator -`yield` statement, and compute which `Place`s are borrowed at a given point in -the control-flow graph. Dataflow analysis is a fundamental concept in modern +[dataflow analysis][wiki]. `rustc` uses dataflow to find uninitialized +variables, determine what variables are live across a generator `yield` +statement, and compute which `Place`s are borrowed at a given point in the +control-flow graph. Dataflow analysis is a fundamental concept in modern compilers, and knowledge of the subject will be helpful to prospective contributors. However, this documentation is not a general introduction to dataflow analysis. It is merely a description of the framework used to define these analyses in -`rustc`. It assumes that the reader is familiar with some basic terminology, -such as "transfer function", "fixpoint" and "lattice". If you're unfamiliar -with these terms, or if you want a quick refresher, [*Static Program Analysis*] -by Anders Møller and Michael I. Schwartzbach is an excellent, freely available -textbook. For those who prefer audiovisual learning, the Goethe University -Frankfurt has published a series of short [youtube lectures][goethe] in English -that are very approachable. +`rustc`. It assumes that the reader is familiar with the core ideas as well as +some basic terminology, such as "transfer function", "fixpoint" and "lattice". +If you're unfamiliar with these terms, or if you want a quick refresher, +[*Static Program Analysis*] by Anders Møller and Michael I. Schwartzbach is an +excellent, freely available textbook. For those who prefer audiovisual +learning, the Goethe University Frankfurt has published a series of short +[lectures on YouTube][goethe] in English that are very approachable. ## Defining a Dataflow Analysis @@ -56,14 +56,14 @@ slower as a result. All implementers of `GenKillAnalysis` also implement ### Transfer Functions and Effects -The dataflow framework in `rustc` allows each statement inside a basic block as -well as the terminator to define its own transfer function. For brevity, these +The dataflow framework in `rustc` allows each statement (and terminator) inside +a basic block define its own transfer function. For brevity, these individual transfer functions are known as "effects". Each effect is applied successively in dataflow order, and together they define the transfer function for the entire basic block. It's also possible to define an effect for particular outgoing edges of some terminators (e.g. [`apply_call_return_effect`] for the `success` edge of a `Call` -terminator). Collectively, these are known as per-edge effects. +terminator). Collectively, these are referred to as "per-edge effects". The only meaningful difference (besides the "apply" prefix) between the methods of the `GenKillAnalysis` trait and the `Analysis` trait is that an `Analysis` @@ -71,16 +71,21 @@ has direct, mutable access to the dataflow state, whereas a `GenKillAnalysis` only sees an implementer of the `GenKill` trait, which only allows the `gen` and `kill` operations for mutation. -Observant readers of the documentation for these traits may notice that there -are actually *two* possible effects for each statement and terminator, the -"before" effect and the unprefixed (or "primary") effect. The "before" effects -are applied immediately before the unprefixed effect **regardless of whether -the analysis is backward or forward**. The vast majority of analyses should use -only the unprefixed effects: Having multiple effects for each statement makes -it difficult for consumers to know where they should be looking. However, the -"before" variants can be useful in some scenarios, such as when the effect of -the right-hand side of an assignment statement must be considered separately -from the left-hand side. +### "Before" Effects + +Observant readers of the documentation may notice that there are actually *two* +possible effects for each statement and terminator, the "before" effect and the +unprefixed (or "primary") effect. The "before" effects are applied immediately +before the unprefixed effect **regardless of the direction of the analysis**. +In other words, a backward analysis will apply the "before" effect and then the +the "primary" effect when computing the transfer function for a basic block, +just like a forward analysis. + +The vast majority of analyses should use only the unprefixed effects: Having +multiple effects for each statement makes it difficult for consumers to know +where they should be looking. However, the "before" variants can be useful in +some scenarios, such as when the effect of the right-hand side of an assignment +statement must be considered separately from the left-hand side. ### Convergence From 0520a58b42ff29484ad4ac0c2cec3328c4d5aa05 Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Sun, 13 Sep 2020 12:30:29 -0700 Subject: [PATCH 1232/1812] Update `Visitor` and `Cursor` examples --- src/mir/dataflow.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index 9f93921b4..5b10afec1 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -127,19 +127,19 @@ For example, the following code uses a [`ResultsVisitor`]... ```rust,ignore // Assuming `MyVisitor` implements `ResultsVisitor`... -let my_visitor = MyVisitor::new(); +let mut my_visitor = MyVisitor::new(); // inspect the fixpoint state for every location within every block in RPO. -let results = MyAnalysis() +let results = MyAnalysis::new() .into_engine(tcx, body, def_id) .iterate_to_fixpoint() - .visit_with(body, traversal::reverse_postorder(body), &mut my_visitor); + .visit_in_rpo_with(body, &mut my_visitor); ``` whereas this code uses [`ResultsCursor`]: ```rust,ignore -let mut results = MyAnalysis() +let mut results = MyAnalysis::new() .into_engine(tcx, body, def_id) .iterate_to_fixpoint() .into_results_cursor(body); From d91788c71d86f10b478916bdf3402b0f0241e246 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 00:29:15 +0200 Subject: [PATCH 1233/1812] Add a chapter on all the identifiers used through `rustc` --- src/SUMMARY.md | 1 + src/identifiers.md | 63 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 64 insertions(+) create mode 100644 src/identifiers.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 25ea76e78..8915541cd 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -85,6 +85,7 @@ - [THIR and MIR construction](./mir/construction.md) - [MIR visitor and traversal](./mir/visitor.md) - [MIR passes: getting the MIR for a function](./mir/passes.md) +- [Identifiers in the Compiler](./identifiers.md) - [Closure expansion](./closure.md) # Analysis diff --git a/src/identifiers.md b/src/identifiers.md new file mode 100644 index 000000000..852bfe8a7 --- /dev/null +++ b/src/identifiers.md @@ -0,0 +1,63 @@ +# Identifiers in the Compiler + +If you have read the few previous chapters, you now know that the `rustc` uses +many different intermediate representations to perform different kinds of analysis. +However, like in every data structure, you need a way to traverse the structure +and refer to other elements. In this chapter, you will find information on the +different identifiers `rustc` uses for each intermediate representation. + +## In the AST + +A [`NodeId`] is an identifier number that uniquely identifies an AST node within +a crate. Every node in the AST has its own [`NodeId`], including top-level items +such as structs, but also individual statements and expressions. + +However, because they are absolute within in a crate, adding or removing a single +node in the AST causes all the subsequent [`NodeId`]s to change. This renders +[`NodeId`]s pretty much useless for incremental compilation, where you want as +few things as possible to change. + +[`NodeId`]s are used in all the `rustc` bits that operate directly on the AST, +like macro expansion and name resolution. + +[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html + +## In the HIR + +The HIR uses a bunch of different identifiers that coexist and serve different purposes. + +- A [`DefId`], as the name suggests, identifies a particular definition, or top-level + item, in a given grate. It is composed of two parts: a [`CrateNum`] which identifies + the crate the definition comes from, and a [`DefIndex`] which identifies the definition + within the crate. Unlike [`NodeId`]s, there isn't a [`DefId`] for every expression, which + makes them more stable across compilations. +- A [`LocalDefId`] is basically a [`DefId`] that is known to come from the current crate. + This allows us to drop the [`CrateNum`] part, and use the type system to ensure that + only local definitions are passed to functions that expect a local definition. +- A [`HirId`] uniquely identifies a node in the HIR of the current crate. It is composed + of two parts: an `owner` and a `local_id` that is unique within the `owner`. This + combination makes for more stable values which are helpful for incremental compilation. + Unlike [`DefId`]s, a [`HirId`] can refer to [fine-grained entities][Node] like expressions, + but stays local to the current crate. +- A [`BodyId`] identifies a HIR [`Body`] in the current crate. It is currenty only + a wrapper around a [`HirId`]. For more info about HIR bodies, please refer to the + [HIR chapter][hir-bodies]. + +These identifiers can be converted into one another through the [HIR map][map]. +See the [HIR chapter][hir-map] for more detailed information. + +[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html +[`LocalDefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.LocalDefId.html +[`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html +[`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html +[`CrateNum`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/enum.CrateNum.html +[`DefIndex`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefIndex.html +[`Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Body.html +[Node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.Node.html +[hir-map]: ./hir.md#the-hir-map +[hir-bodies]: ./hir.md#hir-bodies +[map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html + +## In the MIR + +**TODO** From a87ac24331b2df24d471910afcb42572af8cea72 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 01:10:07 +0200 Subject: [PATCH 1234/1812] Apply suggestions from code review Co-authored-by: Tshepang Lekhonkhobe --- src/identifiers.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/identifiers.md b/src/identifiers.md index 852bfe8a7..a672c0274 100644 --- a/src/identifiers.md +++ b/src/identifiers.md @@ -1,7 +1,7 @@ # Identifiers in the Compiler -If you have read the few previous chapters, you now know that the `rustc` uses -many different intermediate representations to perform different kinds of analysis. +If you have read the few previous chapters, you now know that `rustc` uses +many different intermediate representations to perform different kinds of analyses. However, like in every data structure, you need a way to traverse the structure and refer to other elements. In this chapter, you will find information on the different identifiers `rustc` uses for each intermediate representation. From 557f8063d335213a0ac95a39d47e54d2fdcddd93 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Fri, 11 Sep 2020 17:14:48 +0200 Subject: [PATCH 1235/1812] Make the HIR chapter point to the new chapter on IDs --- src/hir.md | 46 ++++++++++------------------------------------ 1 file changed, 10 insertions(+), 36 deletions(-) diff --git a/src/hir.md b/src/hir.md index 8b6637ebe..47262c485 100644 --- a/src/hir.md +++ b/src/hir.md @@ -68,45 +68,18 @@ the compiler a chance to observe that you accessed the data for ### Identifiers in the HIR -Most of the code that has to deal with things in HIR tends not to -carry around references into the HIR, but rather to carry around -*identifier numbers* (or just "ids"). Right now, you will find four -sorts of identifiers in active use: - -- [`DefId`], which primarily names "definitions" or top-level items. - - You can think of a [`DefId`] as being shorthand for a very explicit - and complete path, like `std::collections::HashMap`. However, - these paths are able to name things that are not nameable in - normal Rust (e.g. impls), and they also include extra information - about the crate (such as its version number, as two versions of - the same crate can co-exist). - - A [`DefId`] really consists of two parts, a `CrateNum` (which - identifies the crate) and a `DefIndex` (which indexes into a list - of items that is maintained per crate). -- [`HirId`], which combines the index of a particular item with an - offset within that item. - - the key point of a [`HirId`] is that it is *relative* to some item - (which is named via a [`DefId`]). -- [`BodyId`], this is an identifier that refers to a specific - body (definition of a function or constant) in the crate. It is currently - effectively a "newtype'd" [`HirId`]. -- [`NodeId`], which is an absolute id that identifies a single node in the HIR - tree. - - While these are still in common use, **they are being slowly phased out**. - - Since they are absolute within the crate, adding a new node anywhere in the - tree causes the [`NodeId`]s of all subsequent code in the crate to change. - This is terrible for incremental compilation, as you can perhaps imagine. +There are a bunch of different identifiers to refer to other nodes or definitions +in the HIR. In short: +- A [`DefId`] refers to a *definition* in any crate. +- A [`LocalDefId`] refers to a *definition* in the currently compiled crate. +- A [`HirId`] refers to *any node* in the HIR. + +For more detailed information, check out the [chapter on identifiers][ids]. [`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html +[`LocalDefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.LocalDefId.html [`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html -[`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html -[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html - -We also have an internal map to go from `DefId` to what’s called "Def path". "Def path" is like a -module path but a bit more rich. For example, it may be `crate::foo::MyStruct` that identifies -this definition uniquely. It’s a bit different than a module path because it might include a type -parameter `T`, which you can't write in normal rust, like `crate::foo::MyStruct::T`. These are used -in incremental compilation. +[ids]: ./identifiers.md#in-the-hir ### The HIR Map @@ -129,6 +102,7 @@ something outside of the current crate (since then it has no HIR node), but otherwise returns `Some(n)` where `n` is the node-id of the definition. +[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html [as_local_node_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.as_local_node_id Similarly, you can use [`tcx.hir.find(n)`][find] to lookup the node for a From d4ae7b08a9114aa935b21858605c771b88b0096b Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 12 Sep 2020 20:41:12 +0200 Subject: [PATCH 1236/1812] Fix typo Co-authored-by: Who? Me?! --- src/identifiers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/identifiers.md b/src/identifiers.md index a672c0274..f485132c6 100644 --- a/src/identifiers.md +++ b/src/identifiers.md @@ -27,7 +27,7 @@ like macro expansion and name resolution. The HIR uses a bunch of different identifiers that coexist and serve different purposes. - A [`DefId`], as the name suggests, identifies a particular definition, or top-level - item, in a given grate. It is composed of two parts: a [`CrateNum`] which identifies + item, in a given crate. It is composed of two parts: a [`CrateNum`] which identifies the crate the definition comes from, and a [`DefIndex`] which identifies the definition within the crate. Unlike [`NodeId`]s, there isn't a [`DefId`] for every expression, which makes them more stable across compilations. From 4150ebb4edde7cf7e1651824ba96974ad480c1fd Mon Sep 17 00:00:00 2001 From: Camelid <37223377+camelid@users.noreply.github.com> Date: Thu, 10 Sep 2020 20:13:36 -0700 Subject: [PATCH 1237/1812] Bump mdbook version 0.4.1 -> 0.4.3 --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 304abbf8f..2da87a125 100644 --- a/.travis.yml +++ b/.travis.yml @@ -11,7 +11,7 @@ before_install: - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true -- cargo install mdbook --version 0.4.1 +- cargo install mdbook --version 0.4.3 - cargo install mdbook-linkcheck --version 0.7.0 script: - git checkout -b ci From 42938a33fd1aa10da1068662eac20a9b19060cee Mon Sep 17 00:00:00 2001 From: Camelid <37223377+camelid@users.noreply.github.com> Date: Fri, 11 Sep 2020 17:44:44 -0700 Subject: [PATCH 1238/1812] Use latest patch release of mdBook and linkcheck --- .travis.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index 2da87a125..fba5ab87e 100644 --- a/.travis.yml +++ b/.travis.yml @@ -11,8 +11,8 @@ before_install: - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true -- cargo install mdbook --version 0.4.3 -- cargo install mdbook-linkcheck --version 0.7.0 +- cargo install mdbook --version '^0.4.3' +- cargo install mdbook-linkcheck --version '^0.7.0' script: - git checkout -b ci - git rebase origin/master From c99dc88eb8171414f355aed3ff3c1282ff74df64 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 14 Sep 2020 16:37:37 -0300 Subject: [PATCH 1239/1812] Add Salsa In More Depth lecture --- src/salsa.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/salsa.md b/src/salsa.md index 68e92b29f..8e2ba6dcb 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -2,7 +2,10 @@ This chapter is based on the explanation given by Niko Matsakis in this [video](https://www.youtube.com/watch?v=_muY4HjSqVw) about -[Salsa](https://github.com/salsa-rs/salsa). +[Salsa](https://github.com/salsa-rs/salsa). To find out more you may +want to watch [Salsa In More +Depth](https://www.youtube.com/watch?v=i_IhACacPRY), also by Niko +Matsakis. > Salsa is not used directly in rustc, but it is used extensively for > rust-analyzer and may be integrated into the compiler in the future. From f19d3e64b4383cafd27b4f4d4e6c4df51130bd96 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 14 Sep 2020 16:41:25 -0300 Subject: [PATCH 1240/1812] Complete text about salsa base inputs --- src/salsa.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/salsa.md b/src/salsa.md index 8e2ba6dcb..f884ecdda 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -32,7 +32,8 @@ see its type), completions, etc. ## How does it work? -The first thing that Salsa has to do is identify the "base inputs" [^EN1]. +The first thing that Salsa has to do is identify the "base inputs" that +are not something computed but given as input. Then Salsa has to also identify intermediate, "derived" values, which are something that the library produces, but, for each derived value there's a @@ -107,7 +108,7 @@ potentially invalidated. A query group is a set of queries which have been defined together as a unit. The database is formed by combining query groups. Query groups are akin to -"Salsa modules" [^EN2]. +"Salsa modules" [^EN1]. A set of queries in a query group are just a set of methods in a trait. @@ -212,6 +213,4 @@ fn main() { } ``` -[^EN1]: "They are not something that you **inaubible** but something that you kinda get **inaudible** from the outside [3:23](https://youtu.be/_muY4HjSqVw?t=203). - -[^EN2]: What is a Salsa module? +[^EN1]: What is a Salsa module? From c911b40be5e559705ea8052676125f9bea32c9c1 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 14 Sep 2020 16:43:34 -0300 Subject: [PATCH 1241/1812] Remove EN1 --- src/salsa.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/salsa.md b/src/salsa.md index f884ecdda..567f1b153 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -107,8 +107,8 @@ potentially invalidated. ### Query Groups A query group is a set of queries which have been defined together as a unit. -The database is formed by combining query groups. Query groups are akin to -"Salsa modules" [^EN1]. +The database is formed by combining query groups. Query groups are akin to +"Salsa modules". A set of queries in a query group are just a set of methods in a trait. @@ -212,5 +212,3 @@ fn main() { } } ``` - -[^EN1]: What is a Salsa module? From a72fe531cee19ee7fc68cd97d47b3f5507ace1c8 Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Tue, 15 Sep 2020 19:20:11 -0700 Subject: [PATCH 1242/1812] Describe how to generate graphviz diagrams for dataflow --- src/img/dataflow-graphviz-example.png | Bin 0 -> 81892 bytes src/mir/dataflow.md | 16 ++++++++++++++++ src/mir/debugging.md | 4 ++++ 3 files changed, 20 insertions(+) create mode 100644 src/img/dataflow-graphviz-example.png diff --git a/src/img/dataflow-graphviz-example.png b/src/img/dataflow-graphviz-example.png new file mode 100644 index 0000000000000000000000000000000000000000..718411a8c42a81111a51c920734eb5a0b54d3967 GIT binary patch literal 81892 zcmaI7V|ZNM_dndEabw#y8>6vp+fHNKNt4DlCr)GAP8!>3*qG0>z5CVwcRllF=FB-~ zW3A8f+TrrDVsJ3nFz?>IgOd;!R($vFebKvjpqNk)z<+$$E;WH)U`~P(%22?M7nE_> zyLW`|B!oXHyXpSOgw$60jxp#9?I{-*O)M*bdZ+6gOMO;`W>#KNu30|cA~ydzpJe&% zTf?#?UQ>nU9bmpp1W_0qTo`=Glg#}MCn*Xs{)>R$Prhug1lJATyNq+4^R`wu+*Sb$ zBtlSOKPW^HVgWEqCjT#A5Up&M27UtTlG;n-AMAX*N zDbK`uwk&3%k_HQV_xF7=WN|sU!4if1YNJ7TN6EyYL}4W0tIc4ru&|puJAtK2#e$Tm zstKV;N*Nvk zzRX^Qi@PWca76-tCYB_=IBne69*D-_@VaMo6B~3ck`mi6lw#l?{sEaG zkLQ2#y^4gJo0}b^<|{Tfc0{w&0Wl+^ymNTG@o&nYA)Bu@F@?b4gnYC5u9}NpOCdv2 zR9lxv@o%zNO6ng@<#IS|2MM3{E3G}=p3*Qy*&_cUdl`%W*qC&^^%Ao0>jOnbX6F1d zDmIhK$q%Bve?h@N0vQnsjKlZUi;8J^c{zp22%^RLM3p+q_7BQHK`v3(RmxRWBBQ?y zF;zg5#aI*m3xgx1_Io3VJr-@-p?y};c(}Os=j*)I8y)SMfOhIx4w&ChCJ5>84#kN} zO7`?eVvM@iS_Td?RcO8@aQy`%agHHqI=fwnJmr{-h?p3K>op-QE$tnmN6YV3e)I22 zqSLC@?*`upyD zbk|ra%XGbk(pVas6rBpipfX)ua02nawvg~?bFs##d64Y+@uVt+!y%7ZI3D)b*aF{3 z5pi%LZ%E{+mayg30SvW#0=?I*%q!Nslj?RhQ zORLc~Q!`C~q{uRrt^oC4d;Pm=fo8D2!NGd-X;2J$?V&X=*-UyMYl>G1b^h$?A1VKR zK}}4^$7ed7C!*e9of@GiuT2}BLOmf{VHn|xff_DsS%^X<^sgoTW?Pt_BlPq2tekqM zPkWDGKVM*RF$HiZkZNjb!F!b4#GFMVf4b~bWrAoEJ|2ZM>LK(upST38G zho?+YnN%O{uv>dpD&_N>*7O;d0>)jV=dG*+1{!68>ilAU8)m&d+BGrOt+| z4kj{H05#Uz7SW~uDMN`ueo}%Li9au5_auuc=m47*3h0W+N^vAa9v1$eL;ulmH2%>z z?1q=y{gy_2oJE#j(F&mc(ot049`xxzc5uQkV}_$3*o5D2a%iENg*ha#f=n8>MSmez z-Z(i)(Dg4dbA&?S8ChBT5^2=t0w92c#laPT{WF+94DzO<{+un7Y$!P~9WThMm5qbp zvDhM-EY6O~7g`aDUtpP22bD^u??0X|pYP!VY8GM~ap=Dg6oIxEZ+fBQ`>_r>z5>@{ z<_ktr$Ji9bnCWt%%ZN)?anluwuPquYCgt)v+)bEiTjH&F69d{pAM+ z>ZQc7h(j`2IOpG6C(dyQqSn%Ci>26z+*?Uig%GcpUJ#U8C0)Di&Azvb|wEIxrsp%B^L(NWONtx3@&p7GDKC6b`H z%T0vfB1{MzZ69D zw-o4_nL*ZR`P^M&G)S$ZBxaG-kvyz|!?_;oRt-W3Fm za`ANDna_-1Pc*39J_=?b_TSF{Uno%qbv{`T$rp{b-x-LOlxlRmdsoR?XQ?OX;NVc* z&`{|e^0oi(#;N1{1PBErC1J+K#;BQ8BqM%d{UXLMCPub!lM<8dborZAVS(5|iYkoh zJcXf&Nw7@%$5K8bN&kO@LV%7O5eo}iPfu?wle-aJiEtJu?La<`CeaB2c{`#qG&Ceo zXF86EjSa)6cY|W1k{vJ-r|^fN|GmQ;X;2Rj5A&s3GTZgGQt29#5#qsmX;#$#A%i3` zA`v$Uo<>jn-H{zJki)PzA7KY$393+g&7&;}^^1gm5rG#>IECsZVtB7q7iG0()suYf-Jj9&a95tjK z@ZJ(&B?nC`1>BUp8Yr$Jes<5K=c}MS48jmnPszGx3QrXQvJ1n2U96)dP300)zS_8m zD+_)Q5=D*6j^5DGM+6$t7J)#i-i?*QJ}oAgBku1zbEA3q)#MrLdI7;NfKT~Sg$}cL zdnlN!=7_(%wefUz8a+4Y@axKa$G(JL{Qnm1M@fMK$_qdF>K$OM=6aF!8cFES*95=~ z(+{`J28gTxC^*_I8NiHG^{rX(4za7%q8dSsO}__zFO!>=;K!>v!|g)gb`iAOOFp!d zsUrMVfg9HjL_i6a|JXa+$4l(bqV&D4cqf8VU!uZ7C%eB-g^m`m*^h6%Gk}T#EJcqY zl`~ExwwwNB%{A-GP+xcydw2;2`*52(J&Ay%OJ6d%{VfiCk`Tm<#Yx`o(9vsd{hc9| zG$HF}xM3=lx;%xi^GJ5r`l0OfK)(anO|Jt2h`PG z?rva|d@mzfT%>BfpZdrc5?(`8@6Kb6m9qP)Cq|Nu>KQ)0FdN#TfXDjd6<_mMjF6PJ zwZV|I^|ytw6cRushzWzGs5jSOZ{$6&!0s(o`M_ab*PxyK?Sve_%g!`pwQ|${hS7Mw z-MQ48hk5@rn1AHgZJx9h8(P($pTpc|BxiAqwKs}B${Laj-`-I!lUqU-@hj#4IxX_e z-;`@rVp5O^f$CBfdCKtB7Gi}Vl9 z6A?GlIlC0tp^EP^`rE%y7NBdyDd+}hgF1=kV|T56!&=25XQa5H!x2i{+y3(S2ps_W z9*Oc59DK(a1}C*J5=xoaKa1CM8)%HF<>HF2%5a&;fKnlFN}3Z6VV!V2B^OF~l@i6I z>1y0d=oZ7G^?i$+0R=id&75oB2-blfQ#MfsjQ1alL`|4;;E%8$-CL7?aQQUQE51-I z_;Y<{lXniUNHNrdgY=>9s8zONx=#QD+xDjBDTIF;VlhW{{aKr8B;sP>99K3Nt*!Q? z$3|Fa5nG{?5F8tvD%H;o<{YSA3Hb&!l$4y$@{dVru%N<8er;cw9W)JYIXC)73TlNt zNHr-chH3-bCL|^Vk{`x3=7E@0_nl8O1O0q7?2*(jWmXac<~HSY+>@bni&C(ClOK8S zeJA^D+KQjuz)tO{3Y#1u<}+!aKZk5!or&)lrH^_B`4+@?Xrin8z6#_3#OXpqjq0kL zL~^EC6A3Zf;P~h$-1F`%*Zb*~dRFK74ll7#GT=8}zWMu!dc&r@ajv_@?cfmV5jY>S z2?#Y#U~(5Surd(zB~mVtd(A@>7?b=mgaUL>=GZ+A{e;(66NBaUN3)L2*81E<6)p(-O+jn@!RK?$Mzq?XnM2bP`r|}+fvNl znvTR(Utmjak+R)4;^$%e;dfcb-(Q@)|I*f~PB_PaSXx_u3YbKM4o2L6U3}xzAf_6( zL>2~fg#LUy2MshYDpYWsd^_dJ2*|R(X^jUatiaJ~3k@H<-??O+8iRu^d!gBk8z@PS zwSCmxuIGwb!5duue(h)|Wm!RRND?TqbBXWLcUFn ziOo=Z(Z>LVEmPcGS{?n}FH?)Z&yvMa0LiWPUJ#ww*6So5zE=|*VXlwt5qqR!g3Z- z3rYP!@_&uS7V1}8N`;JqqGE`MhmnsANMx8>T*QpXcqWM<;j7kA`WjPT@vNPX`dbKu zb6SuP?^3t38yZ}kl`^l%fU|@k0;9jG_#MN(`?j{WYU5$#u-F)dTaop!+Hlo49u^js zU>I{nMdX&xN1(pGZ`3mx@xa%9$5Zm&P+(qB=4ymBdBVk_G^ZISeAa3* z=4p4wnVc=;7tQ^%W-cCxCA2yM&H!^l|GjQ7nwU%4o#rU3OfBftfKZ zjh0jj$LDT&o4ijP?E$n#{JUf5*& zX4Q-e4ah$IB87jNtN>=riJIhv_J*4RAqR0G{a6utOmv04~tn>?1 zYmdmDFhIZhkjzJ`2~q)_xWIUqu&Q`AXfPC~W@iclR<^56jbI6s~E!IIZt6KRF9oXs0lkO{Cm)$<4FJP1%XIga6UL z>Tk2Po`=)s>*lAd@k1J}@0CF`&q|7&^?Wy2q+{}nMvU~-KD*pH59Qh%+IH7)}-#Tu2Z^pBBINRZ4h0GduG5xJ_hyx?CPR39T^@WAw1$ z2os`Nb9jpcUqn%uNY^4st0$I6OQ|EulFe z=Rqxz9#qB#f@CO^O|rCrax226es+q5+q8hl^7>Qs#AD3BSuW0j4 z)Kpb_TWjdkmd8z;C7>rs{=?HLJaROoH)vd)zmllW)XgKJ7yRP23o-CccVOA}ea_nz z)a}a($T~j;9@c*E`Y?X#f#5~R!#w>pbTO&MWBMQE9Dz6_?G=2%9csVjOcLc9_jVH@ z)f7>fjVs))lFZ1}$e`TaPqtZArAq8^tPlkl9R!zOD1-?0dj#Ld!keKv(M?`H#!?fUfs;jK)HG zVS}a{I@Yc|hw2v$}?DZjVyd=3_;R*?yJ9j9Rmb%}<>) zy7$osNh~D^CI<%w;yLSJZank#u-79M>kqnx%SYdi-!m0)1sbdw)J zG>pfr^}>2{Zw>EGO{Tl@8tJ~;YFMHR3+kQ$ESjr6B;4{iOSzo#%OBX55rAYVkgzs{ z3(c)K-l|eE%KRT`oxHpa_c{iBgH~0{8oK+nk|IHKH%5YXNV(n~#H1(B2wo#v1=rPc zsH<^T$$m!>rm%=Q!@6YYAu5$H77=1lwrsyI-;~OlfDRA%JT~#y$%W9EtER}=n~(F z3Q{oz06&74hfo6B_ajbX`4gzH@2O?m@eWzx)bZr0mU4dQL6<*0j8wY@K~h7gtx zfA{w}LtVWxxsqo1bt=kc06scuB;!OGgpS>-)P^`FQveq09={&GG2rb(mWBV0b zqDa8z`h^OnN|I-kEQEx18cHX6m?aUKgjX2Mk_bem0W#XnOxMV$VW||E!O}Sas%}4g zyZdt&jI}vIs2CF&-PlrLTt8A%a)c26ozz^CPFd2%4P;_*{sL|Y^E}P|4qYhPr z*3$M=TVAy~AKvF{*La*l&E;CO6+TSk0fijs?tGE_+*SeG3F@ZJ-HWll@`1;aUG#f&+GxrB^!cf0F;Dw^@V{o zuCB7g*eg6n<0A~V(a-d7c3HvxckAfd8C`a(vpIf8>gFN?hs23fnWc}GY3esY98UL$fL zSwPhX^z{PXaTb;3NHWi-`-QNC&_7@c&1*@`#QY;r+#n4F{Z`Y8ZYoK5iJ7`4OCm== zJ1I{CHN_LH88>cB`b&ZSc5QzX0(c?d4Gr`eJKTlR{*M%01Tb?JBY6#U;K|e_DF2^# zbM}#d#W4{NkCqv@e6}J%?6Zo`bp}q13NV=Vlpy&ve}ad zLcmXMlOu&F(jR9RX#Sl*x8Lu5tFJHF0PH`A9|Il393L?A=+ei%@OU<4Viq#2R6&ux z+NNO%@npBxG~z2ubzFL+?(da^lvy+e>gdGh8$DkO;_pTqvPUI^1O=&Ur9`(B5w9k7 zf=m+dk_G=x1SCIjsqd3-01L2UefS2>>mxJ zPay0s&BH}+V=fLGA->PTAn$znY{iZKb_}^UNuO-^1@}{cU$oog6141%&Q!e$LR41g z`^J2jIrMJ&243HIp4nP2aGR(UK(!OPho_JD{X1L(-T;gXK-6{O&F#G zZUJKf_F44ImGlF1=b&G7I#@jd{yWN3mI4K)_eZV2ezKs4A50$WZywOPJpW4JR$a$t zJMjh@nkNZAEb%4L1%#&PJh(ex6w3V)mx1KW=$xX$Kv!LpqX0a!|6EO1V7M|1%mlTK zY)sJ7R147dia>v=72a{=$>?&gxvKIoWCTO+)A|A1h$26+61L@M#gz9JK@-L$L=_3i zMRqKtErYsWJA=qW+_%krUL?~_yY5sltSi|N(j%l_Wc_zcnnURi0MLddvr#?~4=OJS z&x`0T!)0_>MiH%_=fY=0*3qwD)HVlyRYQ@_@+9#(iuE&gy~aC)t+DH$t$ZKb{jymE z36=ef@JSx^-9NnmAxlOBh685;#_LNF(D`CU*Ned%xLF6{;oGm>F-y9KOS!x)2$|vM zw!-;c{Q-w$F|=v^nQC^1Pf|BvM-E#zMeJSTL+7Gq#I7#;1`D>cFuHBEOcVHCQR2 zA-B_w%!T%>{we6F3!jKp#iKJ}cyrGuo!pUf-FXs5#Y!(no9u?~`@HA(>HR5@(%$xW ze=AS5xp_4H3h1Ow0`u^DKzw-H;q$R0f%q%QK z>l>m=$#gNpPZq} z26;njet%z)UfBEg2?|VcM`D%?bEViTg68I6=erOe=2sW=V&aHcEVGTy5bphoY0WXA z{YWA03mNTpdtCmpjUeANnXa&X&2z(_v{Nn7bZ0s*7}Nw8i5g}e|F|=M;YbbXCz66El<3- zoH!4*a|xp%FDc*D`N~juc$SSWnmWvL48m?vObz5wcndmWg!3Fe)B{k0AY+{fy2UoFkmmS32p?ld~hBfl}Fmv3nJ=Y264f@GOl?yIeFgax?$Uo zkj(ixdkP^sLgxK`@4_^E>eeKZieZpymhz#-|A=oT*kKc<^LQ%EasTXmAp8nF#fm=V z$4pzW%2Kp5Jv2czImkVPwx9YxnDF%oj5~k0f$6;>>5XN@OyaEfug4{s3}6hjePXrV zGXMJ49%u#+>FM3q7Gs)UALFj1I3XwHn(i0v% z7hy7xw%D!8PY@QvW=(tFoZrzigyELzjG>2M9%;u3kNX5&H`{$9OLgkyge7j)8x1kW zjV2LEA(Px_hiGK^CX1oNy{NT+r1(V#6l4WnQc0=7qAl1R5d5*uw|9C;z-6&2Wy+Ih zf$J^$+i7ZJw&!I|X?IF(V3gBHdZ-TN*Vq3k|0l=^@Fafk>k~c-7-mx8QoKPdF;F9r zO%uByR)pNqYBbQ*X7nO)vp?4Ap`w-3v2kKOVn@hsyJP8qbpru$l8%&SrbAD+(+7J` zk2Y*E<~f7b3QUIvF@J!N4H3a*yKFA)M?q`9e~)uJ-(BnL(@QCZE_VTS(yG&=bc?yM z2rF8OB#vt5MI)=85)@>N)Hhn;PCM538Bulp8NdC5SCiK?Xs2%kMLb?uXzaIX>!1(y z1$`*IcT`#!LL`_)VkF=6=M)nHjBg=v!p1xAtE+25R9Ch7>dXMU*lgn{xu=ULYdBuv zvj|3nmU`8)DnW}WZWkxZJrVmHsFP}sk^gCmaulJ%*!dOvMXH+1a?0SDqq*|+2F)}0 z+%QU|vtc`hIPe#+Us|*hIJY%QT#nyoaJ?edJeYNdZJ%#m1=4bGtsKODzA`X2h4EQb z;$f(LO|aVl!8<+MxgQQ&jgAbmTV!43-aniw^|?fvLH6SC_v2;2zeI%uHUu<7ie>NO zb>}S=V0fhH_S=Q_rliyKrSl_fI~uN6=bC=)I5hKt=6}1i?alwu2;zpRYaC6L99Ulx z%2E4+26qlSy7Xl%hm0)ivkq5o<^o;D$eKXJk^2o;WfDiPa-)bAt2dTkS5Llk0R{y9 zEz;|)Z@MokY$)nmF9(`&glIHvB*)KGs4HLi-45X@E@9U{Qr+#K0 zD4Nn>{=tHh{d!3i(tIA=;Da*8VGqTE<7s%iUz);LfuZ?k2>F_BKKG!H)9^XL$2KBl z6mtyA{+$!ox4~HHPS~Fl7oX=xoEAPW8*DWkrQ9mGvg(?_hQ^%dCbpBi8M4%C8FW`N zFuE?kt6#KzZx!vM9Wuc_8yPLll7brf;(nRh@FIKt#+s4oJs`a zB}@I<*%dZ>2?X!QIN^+wpLgaq&jb8>rm<7cXJ=mUUdTOi@*8Bb)qy01Q3sM)Fz0CS zu<&`&^wgE=CQl?&EZ?2gQx7-aPeP^e9dki{gUx?wXMaCxmtC~-exs8s^Z7Jn=8`fI z4lXWYLc*MS>>g!dk!mART0DItD_+;J)uqRJ>(1Kh3-Vg-m0j#SOMPi^@C6EvefyFdEkJMXX)dHR zlSO(@^&7y=0zJWSvyR*--I22-S8NJIWxP=P^!{48{sFmYmv_^&cRy!?NgKcL?w zF#anJ%16!z#vqc_svYu|$sg?O?3z)~&&zIZPql*oH<0S<@81G;exGwHK3~mKGuLmHboO{{}upL_~`%&NMga^E?C+-o)~m(7;Yd6|BDQlo@Wcs<{UIsISm#dQ+}L}rXLP1IT=w^w|0KmXC@e` zgaQOVwivk|7#2dSIwMl|l-HFrIS6pG)_)AWanmcH7NJuaR#E1J5C7hvzaD!>jv7Lq8YQmu<2lNAM@$!Q} zrpQ*CykCV(t*B3mx9^|oO+=X^r&KBFr6{Mzl?~(Y9hM8+d@^RMqHToWWv`giWll0f z&(03w!vQ0Y76+PEpfMI#1;niilp*J>ig-g?98FFnS3=!fojR)l25j=W$Y*WZc;xIJ zS6xqa)LYT{RX&R)jmpy*Vl`4)tb>oXp#y!f)2fZcj%9@O$?x-BA|1FAqSOAf5M+WS zIQ#EvQu%q9fo=A3+RZ#Zpvn{nnfl!D!6#w8tcj;PL!0VF3xSnVFdc($acNM`)eYa>;F|9YOmf6%Irg~iZMT%hR*-4Gq4hW&V)5-e-!)DbRjGVPD3J%>iJSX>A@|*O(%*YBx$0{*H6B8o6X2r~pfU7@XwM+`2*;V(Kl=zpWiDWuT1SL9 ztXQOMA_eUf3laf9ZWE~uIBPEWyG2(H&byWNJKTZS!6y@dcJBJ8iav1DgE*-h|!?W_d?3D`?&1G z^0#blPxv)`FvT? zrM#N?C!Yy^XwM;JRX`Zt+>q{e@D)QCzG09|e=EdEbG_;zzKx@)lSfi*K$*~=w4i|X z+^D&*`s~g;Iz#sK>Y8#ttQ&-i4uYhMpBCzn{yLGaqYy(cG8cc^$#uHfuFs*VdBU`I zv&rm%%0-OnpIhr4vAYBtqBbkF=(KHvPqU<`@=P^t1kgJ0C)=t$f;3Ic=RPUtuIX5o zPW5IRz5ASW{z|){)i&yS6hc)dMUKDr0J_t88k97;Htlj^Yz^h1a$l1oW#WCWyAWEX z?|tvF5Sk6FOcWjwM;V<8Ls(I0?lz*N0WvR)PlH@^X%(nXBJXNDQiiSDQ*Zja-Mt+a zSX9+~%$)adRMl>4TO5Pt6XyYyJmXa~8h}b%17{PoavHt57ROFEovqaBE5qKANIkMd z3=2fcD5yD6P+T3h0KfcvBP^F)djvH%`w*c!2P)(&U>pDL>e?DvP=c#e%j$NG$m&XD zdh_J|*w%i+z4z@67QG@RT?OsgNbyb6qml2{GjV=%a;%+WD8lMyUZ2BEe)H5O;n}g; zDMxRI7Dwk`Z1Z3@LsN=0Iyuzt$NI+IWm=AL-Wa#BOx>v%mKn!wQ@v4oY3b`@$jaoH zkKavBK2#RKAom6_G_M67+r#nQr#{_@VBT$X3~MVz>aO19(z;A^u5K4CXZRmjpQ-DE z-Cb8PG{+>-H7ELT&fFL;8}|o0bbtEZWO5qav;{e{-u)#ht1DY;Nie(aM?(rX)IDhBn^6$kpLt*vI}{Sx&FR-x)20(Q|kbTXvez)oPaNM$$g4IOnW-tXw^4WQOTB%}O6x`uGsg z+MAXiAk`vGWur60WZNb~V>?cwTGE%yn6R?iAMtY;V>H}&YA+Ka;)UU5-%Q&mGI!N( znivZlisLPjj$;%d#sSzh8O1c}F}AUhjl*G|v#W1_*yv*8bT(Q|TusKWu}y!XBv;$v zk-poZNsdH@KjPJQLU; z<90KE!G~sd=B&1*He)_f4Ny4-6b;&P8Vn7crQzd4+9ir>L_3c$%ncbt6XJ zZh^cHo{_l}-UJ#k5g!(|D0+375jYMvO_X`OonIDO29B0sYbD>kXoLA&fy5b9)IBl; z-eB$~eTuIOVOk2POh;O1M=Ls7U542V2tmagb`Sl2p=bhGu!G&?X4kinl*?>(&F@BE z;WAW>7S0A1eVIX7_|PI3MDH|4FML=&T%^$rn4O>Y9UJ-II|hrTdh8D{y9yd9$;{0k z5LJhTD9)xQChIoFVi;88q#tY;Gq1a1M~KNSsd)^x$&JKYQz9}@MHwlvFta-6YAsS< z}UzuzesGf_smCwI>G4qYg9DV9mmCUTPeu7Q&FgUVhpq23UKk4wi7+ro< zXPSi$G_4wVl;hr)rBW_B{m5j}$be$=Zk*g^sz&0&YLy*a`R({Ltc=0uD>%b!g1&~I z<2AcS*4OpO>_r4yqcz-&`xm@`(?u*zYgsYtLnqP|j~-oZ!U%1X;iyPztz;}GPb2F$ z4fSK3Fppt9`0{1o(OzdE6sMMNHQ{D!ff+Mr za5-E9kjc@#96k=noYFrPW>}DgJ%da~RpraB?Qp|7iR`y}H>RQI6?xN-K*Bg3G>>Mb zss_-|sWEo$=j^P!uW3Q)51|A+$Xa$7j7bhU0fHCX+jN|nb2;i%p#5zQyOWrwbwEoGZj;-m`CE9Ub!>F801-B zYi?MdOa_S#+Yn6U@M1M&@O$q9xeED^6KiwhPj|2u#EOaXza+(lERMI@-#Q|qd&eK7 z2rBYY%c~ozFEtR@C(d**4klEULi5R?q@`*8ppX?t!4AMRZif{S-nRk#SVqO+g#Y2m z8npDoNbxP9=T`MgFD@8*sc|Z$lIiEDgoa9dk0`9Ld+-h@^=+6n66-Rz^Zvt89)?`K zhn9p9ISo7Gf3-M#V8K4%MyeIwXPQmji}KgzejFigxxm^_>1dA1zssuOBL|n8K_-IY z1KqI4XI;dIYA_sBrgtB4S0^-ns8rzENF-?wL#2l}h=uR3_Y`#FU=L|F<-#vE&hxSL z?OR>|0U&IQK3=#35E{+A-Ru@ZJtfb3omQa57DUGk`9Z8G0@S%{LcgIb#5#0+?5s>d zKZ+dJ(90NlG~7?QdU$XSo;;Sc%{7A+22}RdU8VLOj|>nyiwqq{thBZe%c_0F>x3Mj zZ)_9y=2zg7Ko$qH<|yfJHiVnI%X)}|MZH>;n4aZzocvT@r1YMH2pOsBCyOv@WY`cb z2U|(ax=+MZLa8VtEFVKlml%JzVMc9I$X)CnDFp?I z5MPJBTEmClZ}-kjKxo!Xhb5Ao^f8Z4i&UMc!%A>R2;G5hdhW74#(E=&(vsoRFw6ks z&>+}5N5RYVMhurl+kxTe_TANYVnHdt8&BlbupY=2boi{bDhK_sIxb$!X$CYoyRGg& z-Pd*^#9&8zsBEuRd$F55Wc6I>c(_tc6T90+7~bmdRkWzz?b&2xG(dLBYDf4CwDlm6 zcr*YI^!gqzq5%kYKm_S&5M+^tDgqr@^ND3>_66B$1SaCO=MIi?alMT0M?>IG_4uo8 z$BMy`Vvus0Q4JjpAXqe2)jCX_O}swoAc-08k)}iDw>Q?-x+^p7<%axjE@kD*PD+S9t!qLF56RK!tJ$yU=|_ZB-m>0IITnQQr+1I%eu)FU&xdPrJSc~205ee=`g`aBVWxjVD z+PEOK-tn7hLSG)=+i_&eKL;zWJBB3qI$U48@7v{W&1=%)c(X%4ZsyocW*K(YWcpAr zNWH>Glx2hEPjq4{WVcDKjR4)Vboya)zNc(aJd@exJ9VRXoONUf&C2!o6~lA&!5TUJ z(zK7;#rE2*m`4Ry7u_lX2y+&es_jbtEQnDE%x3GA6mAqwP|ey;U3pfMDUn(<#WNTZ zhwGhgbt3gBqm_`ZG!y|sRKe8>G~FeP>S`UDs6}*b%VwyRBRG(^;2ed}g}t$fxV*r! zz&`J?u$##-_mR_br#C%P1&}&Byt?xU(x(ws*~#!dPo7a%_ZW35ISlAw2jV1(X5NZ> z!GYVd_lQaHwhkXcMl! znh_9mS70O{wGwg-2c{2mQrVrwjzp)Fbqh&UF#LbORg?f!{(42#o=GR0`FS=JG`Mn7B+_Z#4`!?zGS4g%`}H!^>cD##_Ts4tr^!}skI zJ~&e|2dr+@3ZqOAJZ+DGQXLIn`G1Os16L;twrDcEy)|j#%%jNgtpnr#_+ADBw<{nC zkXizLi$-JUVSmVqKe}jVp^6@qhQ*OjzZcbBPo=tF=(RQ6tl`3$uBN(Xbmz>qRlZio zc-Fg6tzimU40OR|#6HSY9#Y6im`G@H8kv=@KQ7~-w273Qn1_sgXJW)@LV~1N+^f0+ zCtXM^O0>v^IG*GSHOoFpNPE?cN&=#@maf&ClawsBe#LOO!{pxFOO3;>Ca{8>`>>E*%t<$*GGoWq+F%P3^n{x+k&fnE*GrXFtxd>kGp?snMZGrjsMLm<5( zZ5$@4hc_-?C;!0DA5`Xf{AA}?4WA9>w!jL*lQ94G0^s6iHRc3Lc}5ey4T_`eF>q5- zQ@udQZhRgHD+DK4Bqh&pOXu-~y?Z18b1q2uZdh8wcY}UXeusKg&Tr`Lthb;RJ9JXs zY;CGXS{M6OKO1%Y0iAZ^RHFm3&dZKUsDq`rmPdz_tXRPn6un_F@`y%z%c#;Hw%7It z>${5QIwK9wTa1(5_v!?;!;cs03!!)V-c1^uJH)tF6ce>B+ZaI28atUP0m!sBI~9gp zkTtJvVa~egZ&lax%Dm}^1~8lfgQXBa+s4-dgI8V|Rkb2us1!M$_yJG}d^CRGctluL zjrM19zj58wRa9cKf8l6k-UFcs2@LSCW)7+U)ty)#McI205!VC7y$Q{c9rA7F9X&^) z?#ZU1KG)Xc5n{bBS7{%hy?b3M6ZR~yvWI0ib@{wUf(J2{WR=^jD#}sVe>y@Wqoa)k z3zIusoeis-9>>qn{4^i~+a+~~o6K@xK#8cXl(MZ##e1N-iF4RU5P zOxPbk5>4i;whl8yM`J1auFj6AjzLD3M7@LG_~8`~sD1L23Z+x;z_lGgX?z`^tqIoS zF{~zM)CpcgZnloDuD1Y{1+^~35#LZOke8uBP9pPxj*%)?e>^toTl#z=N0AjUEbU*1 zQ+Iy|O-#;=AC268Ak@KuAp?y-l)rA*i>sF$Kzf1)p6{f0*P`;B4YQDt%Y0Q80_8bO zS<3fMeJ-=WT+Z>&eZDLhm|_n0?yYU8-4yDqWJxb8=##Sakd!VKNGM|Zu{a zcq*%vOMBg0thD$3-C{?|{*@;MUfmzg=joC%Brp>Yd7zvZ$@(!ODExw47Nd7zOyn(I zYr_#5D$23{_#26Q@p2`G@ogc~Qwa0Z;>78d4(-O8Mn|XdFBc-S;z@a}5QIc2dG*^s zA;Ut}Q5|1KrV8yw|8WG+vmDVJDFQkM<+YE77F0DYhV;3WVWU#aGz`6@iOCVWfvh^f z3>Kn)9@r35;gx)bAFzk6R%kDf^h_`>JVa>U@bk}SDu%u@Jdh5y7B@MeA|nyK#d%aq znMOI88nt#!>-UKRGP%BAD!z9x_*v|b-CNDdH_fFO>dv0hCYS1O@Y_5k-Zf0)@d;Uz7{Q zkcdf0z=`pcFca#6>U+u@hTX8Sp=1W(?I%`zG~we6d6#7MxyYxKzGc-~lHpgtbwI}T zdfKxq?+rBofM-hRQ5Xd2i3Z|NS@bpM^~hBeCK9amf=A3GZsXrnfk3QfeK?Eo4h0_K z*#frOU5O-YSvZ%*GnYul{#_)nX(;Cr8BzE_zo(;4e1`heOZ)?kO$}5Pe#Jna-AeA3 zmy`PWRd7@~eKNYr7Ps|m!6qAKTRr?Sy^H^NagqIcHEQzS5}dj&-XethQS8BXVCVA{ zyGFc>ALA>B>HkO9SI1=;H0?@vceix6G)PEGcb7NcBjVFl9Tlv^8L8(=B78RnP7=5&uwuoDE`I;X-B^^E=cvO ztVr)sM2^w;Q(Rr81FvbMlKM$WOpAvkQ%xY2lUSoH(FO7JvR<&8b>nrbF6SXh12!3Qs9|(>}?}W+HBfvO4dt(KR29!MF%oabrt7!lls#l6M?imxKsi; zrh2FuN5c#6ZAMKueV;$DA=C0W+>31ois>iK-}!aiT8r|Ee;brLeS(LwBJNGwC+fOA15$A!9!oWi zq}NTUt$BL_R*7m0)FrU1zHO%?hoycuIXv}_#>n3P{Oe%2`SYiBt$2j6@tlH11C%m;uWHzQcC0qjHC7;S%~3KS)^mad7+=H z2JA70%9d`B9@rLa1!m3t zI>cjqD60ueYwS>fq!3|_2WygN2(4tLv!6Qip}fm{K0aDhJgvd$r4LoMtNJ{x`z=%H z&1{MhA$v75zk=KEhh2UryVa%0@B3*UY$s5E$;)+my+Km_)Wa_`S{^L+=)V4~t^TI5 z6ejj4BY>n1w37bW@z)Qy`H$SNBH!C%rV~>(eC2*En^qO;6Izg-Otgkv-gk5-Oq512 zws=zFMGAEy2P<7!+2mf*y19ZjQ?oZuC1T)v`tJFN3WDp%MnkioO&*MEaXVc`yRRzo z62{sG$U3ijHSGmV`!DMGgg@iu+@kh=o)~qnIANL`TOf5OU6X3zf;sOEIUPr5aFH^V zgD{X16b-2rCY-~d;9{tnkYf3;a5_R=g&Gss_gEoYtjfcQGSaOjXoA&Y{S%Vp9zjdw zjL3)6MEEY^+z>m2SwyiLrjmw_>%h_{%@tF6Gb%BqBzlVth^a488(`fY^6?Nqkgam* zhUq7MG0F%gb>b7==SmMop~5Xt-qpm{C8ot(~b z#`80v=UTld7h=p-X!_pj;YD(iFgJ(J!^P?k&BGg2Yh$6K;qc{4$d@|do0czDW-HY8 zueFH}E**)Z_JeMnVG9s4NtVpk1uxp`%F=qKToQ;&(pW+xofaJSfEe%+cZi4l^fbFj zUl+oMOYXOtnc-a~gi+5EQeTgv+2&(O*ey8;j&+gy3#}kR(gz*(6nL4^gs{J-`F_6} z7h9{$)f^S3-yYRKJgE4LW@8W{xLuFEsN)q3JbjXJYQ}>B*q1*F+7lXDeCOev)lSDn zYFklgGGL1Ro!R;PUFb?yuzGr%*+;pjPx)xDE}fkGcjWYA5=P9*8XF(>U}f*mr- zzJ1QUaG{}Kb=H`djudu^u}#h>jE%wnwa&>@)y6DbIsz>o9Wfp1XNt<+>!|UZ*&jv; z_;bW{mfEqV!_!li(*gDI#hjRH{;Swow))GyOd+4X9JQ9cBE?@=Dnu5bS<#3|XS>B& z-52Qk^rGqu6fw$eKd;HhlIT9Rei!UF;Chlh*e_YF42n#T9TES4R=_LEW{<>zF-D2<(IzueTpRrV5o!we<5^MCctYtcsN z`Sj)zo(b7VDVy?kFF>v}8Q+eQR<)_)9dxvPNSwY}pNo{698c5SJN&tz*z-veBVx$| zOQd0YbE3w%Rw?IuAQ$sQ)vbxoPD!9Ns|3XqH~1b@Q59rieSB5|jD&u#%7G0Mv$-Oj z(l~JmY;UcpCtJ{*V0U7p62_S;wfNw*rKt-{Dm?p8-8#`yz8$|}IbT?qC)AJKa4IeX zyvu{H;q@BO;-;Qu_B5rO8kBO_#sijm$n_r+bOJ&Zq7{Ze+Md-mVCF}#9B;i7m3U(S zVYo&-kbWvdmv+l2``SmU{}2Yun$v<6b7uJCif+*RPD&Etd;%P{UPs`)= z8y*8mAqmQJGOkO)Jh>54s{rJpR9dccL*n-97wor+5gzr0=f>J)mfJ6w&sp}Y-SEPX z!?$B$5wRAq$I+2o?6xRf%@ljx&|wLlLdl-|!h+O`7l!;i&~<_8!D(i4O6U)S4PkE( z29xCYL&__4O+X?wYt=Y2zhcEu3LOq}I}>_b-k?2`gqtoIJ8+KlO!7pY7Evyrrwrisv`*1^UsK<1na*mk<*02383D!A5ff-+XCv~4G-PSzE zG+2;MhmU!)lvoY;XqL$P-RQTO>~Vw4W)U;Uxigrq#AI)i7}`?crqot-3|@Tm`A^}J z=q2=x&EpE){dYc+tQdCYg^V`J)CRVpj5J+*Q`fLTQZC;N zgSB6kNUb1f&6}{6)HsC3HN$csx8{Fn*Lc#-BWSwTB$G#&2um!cpE5BlREz^cBN}7) zumYQBv)cCZH#)dfgi(HV;tOY1;zTOATuaDKeit zYa0AQ-MN4W!4DuppsC4cSQ}g|MNBy@&*lbl_0ZW-BKh7CI6a=lZep}KrTB@B)VL-% zK3ii8pTuozsOjz6dfT`Im!}zwpEd3xib&wlj^tq?wo+7v$!?*bh18KV`|~mVUcD8b zOGBnH>Jqedjsh7I**WRmGYFQ~87ZQHWW!1?sGduo8p!@f7Y%LSN+H>s{0tl7i_Zw& z>Qggoa||D0SKxC$?@wP<>9TU`(M+^3ULLPDcJ6^z{BW0F&7b*2|Htb{9_%7Uisz!_ z`Uk6z+L{TzQ^Td$E{#GFgFC-c&wZ=EP*sp#3Gnk%2ny=inFF<26UB0PH~04=|6f-^ zahjj{PDwKSJ&D8Vba^c!&oC{s{FvFWuU@#V{ZF>KxM_l^NXkE)O>PPNzoKaL>9d!_vZfel9C-6 zW=7Q!y<-3G4NP()vdq&=nnyo4ruF#z%5fs0ctMb2>7S2^cqV zlbTpA{*N941Kh?pxbK5OiX9$s!pE91Y0WQO*My?Va|mBW>6}kF<-8MGofjyJuEF0e zjg{nTSgA2RBXn22AOW6y!N9=CcNCG}A>3r0iudtEhM^OMKvWKZ#IB`;Kv>=%@9xPw zaO6=4h`X`d-ISc>F~wTwT407BV@OQS%i^Ij7aKjeK2}mS5%` z+Aea2bM0nLPWuv7BW2;Zq;5@5*KmC6oP_m)QPcG58aX@X@^c^@ZxQBGoZSZ|w}nvw z2sioftxsBBzt^1i0%lZF6coNHR9enrJ826Nj9-S9F?4K{N2!4aVrOQWHvA@OS zRb52+$}Puqk|M+10Tf_h(753t>l1e+MY`O!+Pezji&3;)?rpLWbL92?KC3efe>H=v-Mo*-buAjUvOGU|*_ezt)MnkX_6;b6+M`GYsriAn(R zj~P33%lcwtP%&IpN<7i1=^w z^qh@`kpfbK)5>n_<3W>yR&|9sW>a!h7K26LeWZPUAy87HC%{DXZ=zYMlWRvu^2HKS zA^p;Kb)C~Vv=-4RiuDh;E=NM*0X{tnCwAV6GRfT(JJVdD+sfPGxMNdLqi-D#O=%*Mn4&?yjva1#6O z^udGcAJMScjJFV3IAv+|boD z&ykNP{n_!qnYu<{=GnQ=5zS8j4gLFjEVf27#gd4+z6}i2r2aiH3mEuPlO_!3+vFsMTnf|V zy^&<;Md$Mq=blzO=O)B|mIk~BD!4P2Ju`k|B2ThX2T)@ zL}trIAfuz+*u~)9I6i(p?93Cp+4!W_*|V!Za7UkbYT7VN&~qs#H?r!P+R@+Senruk z^?D=+w3GE*Yw{W{wZ(Y<>fjr_po$7 zFTDMOLPA{=mOIp-rT69>LgLBh_nz3VB>NwTA+8&vPj#oJzpA>*d60PAI zsp;JyR=Eqe`S?pSUcU%4WJ{#hxQ499`%XNZ5^}reWGZA8{*sCH$dEMf@h+dAh2rjR zQ=k=d+-?uY2cO7K?nP@!iuV8~$3Jxr9HVpGiSkGLRf^9SUP#{xPQNqSgN!cSPkKv= z@gE$}-1>(}X$w8v&u?n9IL;aST(iQ8*L*@SE=Q;|-Qb8;@xyS^A5Ry?GwWQ+un(kS zdav0{=G0`miwkv6ZZib-9&g8Qezv#pahr3cWce;fj^5t0Jyqa`v9b0lj#Pc?L^of< zS9rf9#8O#=*^{Bs|5Kv0OH<)e7|Y|YE%o5lbsls!!c?TTo#tmbdM@ zu6tXqD(Mr)T@*_ebwy#0;EoYjadOQvuc?CJ*AXkzgoU>Ks1eENQ}K$TbIA(LJ~v7R z`zy{B-uammgs$!i=_a!doc3-VDETzPs*`xFT}Acq30I%G7KhAS%I>JX@Jh!+h(qwd zc#4=74c0{}s>NE0<%yhG94ZM0^QK9qKrJ?FC`>}nPPstl6yjJJc@fp6@y1dXzl_{> zDHzMrhq03Q$cBp^=^z+Ed2e{QQbZUMb$SL*@9v`~A;F2=F^eNt8)6aU%643%O}Jlg zPt&`7wq@i!UX)v^t8FY8L|J0g7yK9F0*)YUDh}+-xxE*|8l;?CP3K+d-Vn3Nh)(4j zI>?0c%NKVrPY&xr0)nsj|zeC3mxTX+0{EApUSa%;m{9R|x z*Co8(r`Mv)mlJW9bYF(KW4h)2nUPP{HP5WyEQxxE;MR~?ya@a7TimhS=CHgHl#Mg_ zQuRTfrvDh=Ken#`@(WGID=c0mh{0X9$4yj^jms3Pp9iST!DK!{E;p#XpV(LLe2~N9 zd`XQfeaYL2(Be`%20$91W!5O7Vo+h5-*sxC<;Xa>LI;9pxKeF#<~bErxuMcU6>1pjkvi=iKM|_15pZi7>VaEGrZceQ!1$+4fDV-Z9VG{(M^OWPjw8+|69{f&v ztWribD9Y9XG{hF3~y z1%_!n-Fw`(`WI8jbVmyRn|f%MuR`j z_LDH){x#ZvQ4Jd-M2D%h#!PWXZF6&TL`;lYXK)7dyLazAZcg&W1}oltto(}>a2e4_ zNIn!5QTy5H*r0H-Au8up0aRsX^rYI&Oizz2mP_5wwsv#l0c~!gywW%x{ig^4+(9bn z5db_*eCj+sdXUf$>|9<6*zR;CR7nVHKF$Di&}w>8jV@{i+2 zyr(lt24qRcyphxD-)3T1$Xf%c;EwaA!!v6^)0*fzWkPW2>rr7)rKVo2XhkAS#Vk<| zFa0uFU>%dUWJX3q9gplwK-Wqgf!`zMCaT)5nsB_6-W*m$rF6hehu4Hm-_v6Fi(t?X zrPi7|A*nG;YJ4Ukj3J4RsuUhzMT=2|st{-3@Mrs13$XbLF)dLv@@Xg?3wi{A`hUSg z6m9&6!z`yVWwAL5!J?DnQ{0zv`=KQrs1w`5rl-TDd^%k#3aWJl!!B)D8lP^4fFeff z$1v_zsEL|55tsLRgoNI>V?dJv@=e1zCOb>vEdVXOmg>LmoTp4h@d_;Afl zhHib*9;c08*-A|D7eDAm;Y_#YJ0|9&xl_}0*5~@69+aZIZk4)3Uu+R6v2Tv4q6A?c z8|)e0D^=ZY=OlCxv+1~UP#`8n2H4HTa?lfU7XRmbT2Pa3QPR%Ae&H$6wV>F*8`XlA zzv~=x;51R<+uh3LGbrcJ&}9BuV$SlBQwUwym;cMrN-)_=wVp5ey>$;Q1(j*Rz0L+b zpo{LCqid-7b}ybgwXb-`qt>6$h}K}O*3W2#2|M9+;|zNq3wS?mf33Ap6Jh#}A7bzJ z7?oUDq$LErG^U>@;Rcu+ehpNKjtuBrea_l^kWZB#Ki(SCQXKLvi4Fb=O8uvX?yL{q zwVTtsj-J*cqrwJ7?-|Ntc9?xn=bo_ED@!sCB6O=I@``FmXY;?&{qq89tplsJmYQyM zUmmuqB3%Z#w43S-n~7syjb%jNup_ZeOs6S`@?+K*NLbIjxJmIST_&(KNDuOJB}s6* zfB8`_gM5?|v2=`nH7S|mrx=4x7Gr*tG|o*}!$5$TZ63E;YK~Uh0g{WXb~HlvL07#j zo7eXz5_dDuigu@vd5FKbSkQN0EDrgUHcQx;fzn?^Gjh68QO%bf596rg=IAK;H9dMl zcpoK1?Mf<}2a4VFz?_cvogTG=tstSCn>0vKMR2T&Bxuw=+_+~P;aha)2fmwv3?;Gb zD0hCS2NDc_0mXMOaZFQWZTcsEVQ=gbZEaKD@2K}#WOpsQHDX{A$E@qPvRUb4ZfU=h zBwb357>qC}(EpUu+CmsT{sFrd9b&r8Ne7;#_dk9fA@uM@Gg{pG=)&=Y&2zXGsW##H zhrI&^@=Xm$CzUUojj^^9B?{7Q^#>4`e(52Ko4g>mx}*6wZx;rM+#*k9m^5B3ntn9Y z4{oj$s#~wYns4?)@zc5$Zt;{Qb-g0qkL?-WtZVW=r%OReFqz(q)WR#3t{LyZ+z%P= zT3WGn;5lR1Qe*)z8U;-|+XtJX60_c+{x^@U4M8s==mLjx&pLfhA$4si+}1zUQ86Eht$1#jp42ox0+7g zQJF>?EYITR)0camB!UCf8d=m*T>W*nyAW4buP(^ZCA1KM;z811l zX}2Z6JJ5l$y?1+!^5!K+!%D2YK&WlzvzT~y8~@q;;K^XQjT+KfaJIj0!?{r8cU{vY zD5fDh`@s^^-n%mW?oa7_?PW+oKEabk>drq9GUG;hEsP^-Qg%K)2*>&^L(ME#kk`7g z`9Q%L8Sc^E*fgOPxhb3;eV$9;ui+0O;uVwG{24)Zin3~7YOY9pZ{cCTV$o30<4ag1`@mU!W()Mp2YQjl; z;ko_drd7lbUsJatDj_J*E-DUpME~u~98_$aK@X0D{bRJ%SLYX$Jjg+Vs_ybAHE_RZ zK%_gYMpmtB_z8@6s6bszL_`Fel#^0X{x&0Z;qD;xKXsfJV2&u`JL%rzP{eE#w(mM% z@?O@lH)-?e@oevU!+XyFFRQld{SYf8&+=6GoLp*7=O24B@Qq5j)mk#&FwM(g5-NG132lxB^1$uR2D>QeJx+(}sfnt!gW5|}X zqbs}pQvmRR{z^E>96dUt9LP3P>zvCg`Er!Uoe+2V-25%XKSwb@2jTh;VjE$(o#ih%Bl$vvkS9LgN4dMY zEKpx==)s_0|Im`xXwS>PSnh3>kLO>|D@q2TkXxSdW3t0}*lmU7E{ySv6 zk@Sopd7%ts8kP!=s_Svzh!*<_TV|+5ZJIC*%-!^aO;vBdVaMGI`tN!I?8xoh&`hw06UM2S2F*6>#Ai(_O z!4x00CUOhQLuDYrN!0;q>SA2ZD`ndplk7{9E2|@Vx1g`pcw7;MMk>ICFMx}q=^JB6 znzqlIB$a9s^v5-|fXon9<+fGTH~JqiwYNrV`r7F3B-z31nHqFVOG$H!`9y@_rEr^ljt_m3eo#cTv3&&}L`+o1Ey~tvg``;SrN7!c zPLCTuHUwJDm63|;UJts|6_%$3=`?ksIfpCsgdM>6x1D9qzcQy=U8?@3`Y_-zvb0CE zN(2?&8D>sPw#J^Ue?w~OeLe7P+cMtMhQa_nyb<-76XKvoB&Sgiw1V{b{yCDna~TUR zbr&441spOuehAmx@+e|3{V3@lyxT&D3cd2nYl2Cqr_44E@803hwsRBCRK{88OPg+V zEX8%S;T+|5O*yV4-oL+yynsQr z(LcA^lNM`i#cM~eA%FaGRdPSlQ(EOrBypwz2~p_c30X-b;@7?YX;0Hp8D(;w$)F?t zmNWj+m5|3W?6n6{SxzQz` z%N8uGv=Nu=<*vzkKndf8j=?2+!tanww)U5_7Z-h+**lFaI#W!1Y}w7aWtnnLUTPT9 zO<|~F1#@`dEOBL9E>?|D3V+xwZGg-oc1lRD-j0*&zqL56#6C}RV)uve_xBGDl2KH| z-Jh$eIhzM`KD@d_34;GN?gCRQeHG$0x^>${yTiU$%*k=fr1&q{aU?_iWCZb50%JP~ z>3pYqf}XLm_dT~H_VAZk0*Hny=wILIn0*bsgz^pTdXftfDKrhO9PGfn)2v}^^JY>N zWRPyUQQ*z@x>pL})aDnzm>LsrM2!w9t9pR0KOTgi+(kpG*X2WEweh*(OO5f^u)grz zn5fzbQl0A;-wH+Q3Eevo7w>kw71%+r+~L7y=xorJnNt(C1E)p+M;seI;@l5O$ouNY zlEk*9wHQOjmv>`ynm6`}P~GLnuP7AGV_|evLnD%N5s6Tw5t=5XHg*7$q?omYqoRBLdC8PwoS4alIU*UfeF2RKUJh&#vakuN3C=%D)Xl+8K zxXSGeB_g2jY3WcD&rUB5?Xie`xZ>Ejb-EH?qM3uSHQr4X4^A&}lUe0AHjW+^pQdjO zMXJLKSy9bE8gql_(G7Pd-FU|ky>APfBAHNF@HqQT{iK|XrLFZU{^WWMqi0sVHB`>CQe&-_Mm4Y6{_zn{nMiU-U1?fdsIg_Gt@K z1|MQ-p5gnwQ&)SO)v=F1cSNO2q?n%UOsB0?pjfxx3E`6d3P=rqhHCZCVw3jaZ7^tl zXgXwsC7=I}n-hzf#Yk8ofddVz8P;A(RWzplmXZ4Pt-?`aG2gnSh>7e;g!Vxi! zCWz9v_8Subk){d})$_#JhVOLgcyIcCdtZlrl@T3oSU*`5(06X36thQQDn=46$Z>ea zl9l@l5!-w#j6@?)Z(A?=K>CL3&ldiX2-&5ZIr=Cr{s%}^H=TATippyi_!}tmVO)}x z@nJWuEqE0T@RB4y!p_G4KdYo!->8%+#V>b5Tcawwhjn!qF`c~;)oG8E07j8-Bu~%@94}V6Y^VT(Uz2|88l=TGt1<(qs z7Fyb*<_ue1_BXpXR#pmh8NMHg@NC}Bjj7matn4Hf+v9D%kE8Frlq6yAcr{I1aPZkZ z8ZS5Oys85B;B%DH=IuLOs7vdW!MV(9ip8%qkUq;BMm-YEf^QvZ9*{CYG{`n%L%Z8i zWNKf&3?r#+Q2ukay347`V_x`6_pQYSpFyBRVlk*Qcu=VO+%8R0pz-UhZm0GeNZQOI zjM{1vQFM31e^Q4Fo~04XNltk-rl^j>+ffQQ_+%R&qa9!jAt|RuY#fQ7la_*S$&y<_ zhe{py2dFbcRtT#ip-na@$bG)E#l<`sY?v*Zv7xhI){Z^au$sedRxMO7K;c zYZcXoe-!Se*(P~w5c6{B9eKwq5BN2d>(`1Y$lD~tB1a(_Rsn&Dw5ATGcq9TPVd+C4 zyUmjKpxE@u&KPjE^X^c%`(f5;L^Ck?;RMuHb1apJT#W_w03ts7Wg6 zw?{YF*#Z0mb4N#)hTs0-`cNmdZ$-?#3OJG(VDRT~Of)Fe$Tu7@b+*7dYkHe>8`9P~ zKN3FFp82|*CkeKg?kT%tYmmnEKW0kT*+gJxN-6cV@MUK_-g+)+if5k?c(k^nj7b@U zF30l(lZ%21iuLnG6*|Wqh&l<&?7X2gO-Bm7&T-*gBKl|W5h~_>)N@`XeWtKbvBcvO zl9%){zL(93N@^%I!Y`+Mbq#OuW0S7jigg!H6yCL8ra1gB0G_(qo)(_|<*V`*(%k@2PcyLP-p%5Q(0xF76qSFY$bi+vlx5^05r@D=H|_i)$~ zc<||{)y@rGnoLb#^1FWj-%hiTN|GDm63=sRNRVR0!xQ_1BLmS)(1VesQD(Q4X=@&v z)Fq&7dS1r7TZX5aT^%CJdg~Y=2N&}7L+@4NV1AQW^69mXO~)*8`zv)n7k9O7$IylH z2gA(teYXhP>?pt_EKtoHnmQevChgX0^R4c^6*8jz^RbYTFqe}vv`xFpJz}tIbwxy<;31#tgSz~ z^`|KfbP%lS@)EHaHcA-%Vhfq6L46*eI-Tw(Hp|ip*g!gCGrx4&L4HH`$Js0nkUVflEj;KMp{{!t%WJdi>oKkIqr?epeb_;^i4F`$CcWqy$FZ@ z_|!a2s{Pv^K&VYiXer9Xc6N zAmY?P;iEunJJ398WB;w#e+31?z7TLVAd!X^{^S(AhA_|@WFx|6^o>>2i zhpy7f669?sKG8#i|I3hCSbebkQ$SGT;&-(#5)3Zg&&)qVI;CbM+F#~dJ)Y{{h&=A4 z{8ms#+FbpqmF?NZXD3e8?C)oww^-nV-Dk)z7B|8yoPNueM<4p_?}O5y zX`0}hzCKAdEb+gaZO(fKR?N;YB zTdnDbH7xxLKRjq!kdjaXuiW$4t&E6!*1WiB!gbSWEM}0N4Q_2pOoI?W^S^0H^*&RK z@3w_?{S{>56E-sCz`H}bMQY;1GJp^D1E`rQufJ%GXr>L+aI2Ma(B*EWo|HhgHj7uh6>Y6*1u(j zeYuY&`J5I|aE#8P*o%*WVH~rSBh!oTpCHAGjm3onRDpSocK3X{Kf;b{wfJ!6kiu{{Uwu?-x@9y%^hAbt2 zvt+f@5WUA~`}yRp0k*kz{e^QPxqLtV#5*QT+QbW`-!?JAT;QSSzKB?kIrbBdV!S?I z$6Y3%8i-OIY|g`Yhj zP7wmaSV8)yx#lb>q=pMKgvS)A*+S0$LSX+%;JpR%RynZ$Bhd+bRJjBQo2JlYs`*}cE3F*1NOFff1}Ew;(R2N1U-F*8px&>2<7#s)d&Us~-q z?`wU)3CCO4QTYD^y#7!ktpQy5qc6ln{M+ydGRJ3SJzOw6DFQBX7c~sH7gSajaUv5D zk|cyGIGg#yI%N9~6&oSH+OJ6gEenA@p!sfOcHl_35d&na+b?mTsiEW5p|&bL=7<ST=xU`twK2j^6~&OYKTE^g{q%FGR*?6Rp{7;sjP5_!--3x&%crM=%m-np_C< zb8YgvwARKA_f+jN0~cQ{R2X;v&TQr>uLCWhwK{zGJMQ)w3&1e|Hi1Ay90s}?1>K=Y9lu~Te#JVfR7I)F5SM88J@!C-8t@V1AukzuLq=;-J-smY<>?c}}51KRoC ztUW)416|$3PwPSLo-EjTq8;F&SpSCZjHU(D$^jqP>anFqF+CB&HtI?eCIpo8o8Den4b*Lu&Bg9 zC=>qS;e1^AAuBDd%!Kt*LBJ(EP(dZ+`dtRh<+Nl`9UVeI-G+0&pUu;2cCt`+!%YFB zHx|g8oE&9&`a+MYuRsUqo69*vSN@oLjKp$$B@aSoThD)E!dF4=dY^tWCDK}%b3DpmIbrvdnXEXZqp@7=b4AV!VR19S|4 zoFzv`M-S)?N9$c(B?TINZZ~kuD*uc*MF1)*J;i~40M_&d0eE)Oc(LK#%|0qp+lvG%w3Y#4xCP3vVhRpomRCW!t z?|j6KirfoFA+p$)G`|J2E~zXaH5KpbXeAoxC&&mV^~(FoCUR%6k6w8eeAr!4*!;n} z!&XMr>+m7S^?%|A+EGhk{Qey}40a9YXcj+~q5or}lPp1hsyjfYaxj^!zjLtsCKGjh zYHBzj&jg0PmpBX>RaR0omT$qFOKKB6n5}j^oM%5=sD}%NLzA+$wjQz^CZCal7w z?-Xv|w|>gv+}^u)P?MkD3Wa<*iuA_(0s;z`V%;udJM1i*gB6p9~m+1wAzeI`%zD@&ubHx zF!Chkl|IB~3MTG83?a952o|lPDEsdD`JoR!G(dy$YyGwLfM{h1v zNB8kUobr25!OgcXh6MJ2cl%_pR4{z4SSgR`y}p1bi#Db<)=rNL*Hj(pP2g}l9v2dC zhx#w2c}zFXtOPqxENwD$$^4ZvgShKperiz)n-;vt*2d=lR|^0$3S{+HNB{^URV|&BAJ{~{{_lg)5n%GepkLrFYL4QS%U-}tr6%K=*tR%?Gxj=( zs&f^0N;;Uh=}6QsUz&jWBDLzhI`~L}i1ugEl-*>J@U##A--%ZAD5BP_g@>d!vRQos zXxrziseE1FP=QZiW7DEw4j`v6fj~VhaEeJhE@w3Pw>9WJIHNyetdmTCbTqH{VYcx(wFp?v$>ZH!bKG#Nf6G--rndW$eU9DBR4mQv(f^1SJf{e=9vN1#+3_w(nR zqhaC9HO?Ui7_hW+VwI_u#)1!Ro=g;mH;!{|3ajCXd1iWl4@jpJD5=)5Z0G!qsmxyj z-H1g*SyDHXH4WbC!Y;Ld0;H0!O%^g9AmXqEcKW12xd%}jaoEw=EI2C^?YJKp`6WLl zXo$@)pkZ9vKUuY>gTA$Q8t&MRQ;I(T#o~Zb1Uj(;W`_0T{9ILd(feSQ87Vd;UpoUZ zC@C6+G2vjsA|Unk^%->s!7P^Y)!K($&wdXZ(foz3CGdaqey5JCKbi-r+cxWP^&ubL zGM5qI8lu}L$}$vQAFxtv7xKVkNLSnN9=v>bf3iW2B}}8m1=!(lkWtr)yMVPy=d>&U z$js++Q=8yy|RGs@%-`+$?+Q`D(s8>R_=Rj+ulK(DSW0MGs#$yHb;~9p4E+ctYJ$jL;j1m+S z$Z2RKZwW{N$a_(68e2a3CY}5@CMm2d|Af`b4Z9Xv??3cd5`j`5{Z4pWDJ&B(;I26UgY0)Qe^6Dv@0!@%S-M|>?M z1uD(;>)Flqw@ZiMU;t~3mkjG5P>_DBTO?Gsxp7wj1h^I}G9{`1vm0QhsvnV!9>4-7 zt0g*#PsnZptx>HL3P6V>2RnH{GJ(J3;MQV<3mbm1A<${G4h23<3iOdyI__DcSKa|@ zZBLxq7vTS6(lr{0A=q2`%9_DzZ?_Q0@#^>VEGI{;$0ox`^d3jeyADqeo>;8R(U!K5 z#1#{Z)>)@uGesvEDDwP(1@v&%9IO6Y-ac#~ddgQ57Z-Pi)QiKYK?hg7DGs5E4xB^P zGMJP=@P1(sscC3703)y2p=-W;4!$5GLC8 z9oR_eeBdDcy)4SSy(GmfK8!}|8IA;os+sllI1p-`?fkp$oa8c@5A&uxwE|HjN(Monot=?N7J6XIpH|-kP;%qfFI%y<9N537XUx07bbNZa1vilf zdYl5~;vOR?DGBLSz{+3hax>wBC2kro;=_l~>}(Qn7M$tuBaPhp?ru1scryJqw8g>S z!S)dUtz}-hR(y8$+8jXHSI$#|;gdHhcjDyyJrT{xK}{zEl=Wf*Js2<%3wogYKVGJq z!wgx0HKf$c;adh8@O1u}T zM}I1KWCNcckNx9^%*L(gW+f#h9TnRw&6b`pTyzj=H_wQk5^3;GD)NWsHwuYKtUY9AK>!OT%bdq0PaCWI&m6mP*-(w>buS_D)1h_V#VoU%#reWTn{2KZ5F3Nrk+$ zXrT*vq5}F|7>1!{sRrSEiC34B%?UoB@b z^mb<8Ew^Wy9>(Ftn@i=_m;K$FGrIDq<0GJJ3oXZUBI4qB!zt@yUQ%`e>O}>E38=qN z4uVu+b;)={VtHvvF2qfs*1yHFI?9ewc?wgGCCTnmNK{*ZE*UBQ38hSV zCAOYTXGeKdd4f!>^$bInpeH5}uBbPFm-?g*P`LW_GGH{>=pi;JRHn|3ZIw5Nc+F|YFp8uh7|ees(t5K3VC+eTJzZIjAS6cT)Uhn z-Hwe%M;l95_u?MR`n~3^C>T9`{W|jz+_t;@N^rMy962@@SI95>JPtx&_9kM-w-kEq z^X}o_VNk!}jbCy^xVmu0J5F0gC)-wUS7>S>B@0*T&6nr(Xx;%Ci1Rn3H6S_*@TZwY zFk%0d4@{V#prBf(ZP|-oOL)L#)H1EQ0-CU)G-T}f2r4t}K6LH;{QO}oy;ECcz_ag~ zf`K+$jqc8FlZ7wa52EcfR;^d~CMLT~vMh(SzE2du5bI;qH#LqqARQpSi*4t^J!Nu zysQhabm#t2rJkKVrBX&=@%JW;GHqU(a0$?hB8|_nphdrF6%ic4_&;oYb9i2h@^xc3 zwr$(C8=Fni*iK_RZ5q2tV>Pzj*o|$Q-%iiH=brODzyE@Fzt6_(!CJFsx@61;{`NI* z{z}$AR^S1e({81QbJbhrTd&~?1sR~dfl-5u{7)~)U!KVdsj{j{SzxpzS!4$==UF5c zlj%2+4hE6!zj44Q#%wHHGXROe0@es_Y-~hjfvB+2z6nK(n>025qzM1M$U0{JxKgXtm(`K0iaBp@@{ zQ8S>U|LX|>R|9-8or2+dS1^~;4m^kTyrDxCGtn}5X8Ma_y@{M-#nzVTbg>#7N_Y?1 zaKDIhM=HeR)YLlg*I(dKK(js2`K9kWgp{SFA|wgYYbX_=@CktIkT5VpQh^pVcQUu1 zXn))`#cl?-69pa~9$mgI78C@XgyC$dRx+nuW^Yfo5MXYXD0e{g{8iEcoLZ@B$JEpt z)WII|9zWs@37cr!HRcEP{yOJ*kQ)DoGyIS12avS4#0yA!)-v2ynBU;AzBef1u0ZZD zv1}$%94RF$*aA!SpV#UgL=D_X2Cv3_+di0s6*U!kMx1aSQx60w>1D?xK$UbZ8W|#S8<+0}qFiBhRDw7*u&*o-*3ek;-LJ_p6 zj6c0(TI}Z;=0tNmlsk&fm2~&oh_;Z>VzA!b=U@6_Kf+I6cZb$=%TOg0PeQ({v7SvW zEScy1EDIJUloNq+gE6h*Wq$qAI$$G+?F0$gDd8TrxoW{>I~qBld5-M5Ot%PDCoYtA z%T$|&c_)ALb4m9P)QJXxcAEBP|3GLH%ae!(kTJuEUelB)x(<%kc;S?EGY}73j0-$) zT>%$lZkIz*$9=TXU2c(q(O|s9iI?bmi*G*2X@Ymi9)Y`tQW=g^2Ex_~E5oAd3hY;} zYw|U&BOS->9L5V5==RCHsLQSMOVg#JWoT5S{-spb4>wFh28c$LQ^Ie@<%wZXK;_6%NQpIGS@6oWs=U;>i83^W7 zryS4|Dk*6(XC7V%^=*_v?nT$74OLdcGbUMhAd>%>swjlFkI(snd6v<1q4IpYui*C& zb+_=fY)PA%-GI^zLsg*}Ct7)P=aZQE?%GDtVd3m|iVFjqq^`CAI9{ybOM&pQ4m(j#0gdSPDJX!apEItC&FU1A%2=@Iu`ZnM3Uk;bm~3 zscb=6t#`M_R4--C5x$${=oham_~?SPFFWY%k-WpGJ^c*?*{-qrgT}qL}rv(Z$qa(_y=HZatjH zmuz75$UUJ#ud1YGrB7!D!g3^OGhw7o3c7M{x58i8nNl(62RFgHB*EBatDCi}M6U0c z9x?_x!a-zJtT-BA*N3yh&#BVJl-HT=h-yjVLJt{{T)roGqtq`Mv3(hA=c9Cg5L7fK zS^u{Lc6%t1%j>38>swavte#)&#er=ve>8<*B+iE3r2MK)Kuf0ueBGmL{nyL#^?GtR zd)0*C@1{D_1W!1gP#7x;GxRVg;y@(I^%DhaVe_D>vwH-y5?qKTGP?E|(azl>qgXq}E56-CLvFoa$732-2~{n_ql~II z)m;6}Ek#kR9UVozA*rMiQ61r^lw8446Q=Tv#IADk6$+)fVs-4Pc|~*b1KQI;dcbrr zl_Jd48~h;1Nv@|_AGmV9fk0I&(is{qY%&NrRUyz&zdGYx)u*JS7+&*RljCCayP^Y0 z_n*N(A1KL#oYSLQLSRRukuFz#H?pNi?c0#US*7*Pyv1#NuQ;HOn33)3r{dbeEvq#D zgo14CZ22^fy`@H0v$0HsQQ6YP0hC$Gr_n_eP*Zpc8bcNQ_0yI}0bx&XP7;?O$y%I3 ztqO#YmPzzFsLy?!T+0L}tjZ7=kw98*cob;te?<#t)ktzB}Z7`=Np-FR6J4*M+faV zuyyg&_v5Zzj-k*xY|-6K$i4gVZgY;xv^w8%ff6E*)xf{>@a}OM;XC@s3dwhazJP{Dw{FrNkI>_LkIVtG zCwTjc^m27*gaS2vItwy->9(#k_K?of_njsoI7i6e?@sDudwJEU*9}ycR!zv(5eE+! zzU#1TX-2Rw(poo)4>4`g1o>?5bOlo2`k>=nh>XFsP6XJX+vO3a&5vAB%CIB}S|6iQ zX(6UJ>QNdV{rfH7N%j}|LLvWFo6%`jzH{0cVGcz38TJ4z1@17h`%Yz z?5m0bX%8?TfXU8(WJC_AIndr})mG2z5ne1-Iv+q3_t!8EqpQhFW&OM_EW&?cx;tHV z@|Ssh0{zUw0R?JB_&PCc=!tMbvVnT`>+avPC;oiaP#x6P z);1Xk&jkt@mg?JPMl(PSSiBOV^CwgMD@Oo+L`8SM-%fJ4+>r_0Yat(NG)% zFfZ)aD8CK6sfC3`Qxx+*uxkx87dQ9%)&5jEgG3}Mr%Hz|1cgF6G|)2IayiPogA=gu zwVCWkWEDFu1U-ZrJig6dsDhBtJKLp(9CE0)+zK8Y8UdjfNb%wM)BE4ll2ib1f%Eo= zDs}xEopxzIQabp6NtmrS{m zPSaP#&=p2HapgQlc@>Fzj~K1bG{jrS-4c&FQ>PCfT&n~lsfpJAkM{J$&cn%{Gac-I z%;HSyjVZg_9qX_8G*xK)#zc1hR20J<>f*2Y((wj zLed_dRZuRhOU^yX;$)QG4*Oie_z|VKm_~XvaKBrlYybI6SbJ93*Dcw3mPQDg#63#b z3fbb~fWtrLxmG0v)cU|8V28C1km}?dp>Ph;k@3xN5;*C0qhBZQt`0Y2bCoW7Ozw=W zHQuC&Mj4XpQ-Ka~v@u^-JNm*&tNu;;OdQ83JaCt0aUdPz%!pbXz9hG8vsBl7r*1yu z@4GpPjt7+2m-8YmL@&%Cw<&(tbBXyLs+swZh(_lFyAutk?7UJ{l;g2KZFR7ymD>oFbX|Eb5M%GkvMUs`5E zr!AK2=QY}nQg=EiXFOnKV!NSB*AqnOZmO5a^SquYJ+z=(a(kS>)arUh)#NEpyYQT? z{HOu{de@P6=+{&|VEig>DkFOCi3$$oKpF0X&UQi=0|{Y3SJ*6JCg~l7Y2XEC!V{9S z+>o!y+=`3Cx&No1yn^+hJP-n6-9=h2`md4@77f<>VvusExxmpw*ejXM?CtdrDIVg! zr;O3CjM-6(WE!+H`c?Q@GnE;7_2>beR#LjkbB&3vnIiKk!Yw<-y02?{!u|95*gRXk zz)L0vgq3malhMGbVfUVGvP(X~j`dO?ewIM&u*##+jYE}HF|mA_Wh>L>lp=G90n$+L z`+mtt45JCk(`;EI5A=SCqmHh6!S3bJpH+_6#!)tF?>r2l(@8LlwwXW9X^dn8@RaNFQ{!>GVqkv*d1Juuv>AJY{i)f4~34Gd8cMz-?AYWc8SeK&aQPn+ssN;nk zO?WH{ae%Mz`ao|3sZZT5F<;yAy$T30L2?d79h z4avHSA+p!wJd(%H7_FDE(|qU9ZY*9Gov(^D@N2zdB(nTyxxAz=Me8n-v(B#xbKLC~ zble%{5&g^bdq;>-tXI98*7P{oKk=vv8`?8jy7Pz}=%Uy52zJG-Sr+PE6~x4WwXeU? zfX5RJ4!Bo@GpOveHC+Qq>6OR*U_;G~7il_GC#teh-c@@UM%3P5-tjKauqT%L8YSdg zkgyg=12S#Vk-oNFZM?Ngj8b#F1vn^l;qw1dr6$SF%q1m2gV;-?X%u7|=t+KGZVM+% zqJX}P>MC-I!1VkmXP#4dIL*Fk4ed|J!~Hl5vOd*{_{+!>&JEp3fnk zE9XOg0Op6@P98k`i@3Z-1K9uZki9VN34qcozeXr7P_^ZPCV~x%$q9r_Eh>uNA#2BvqPGg<|$U04GX9LcE@bR1m>rsau3EM zWkDAu#ojbi_R}1)83Xg#4~KJwB_~8SN?{iiHJ3{ zDX;S4j*3pPF~Y>k-1urQyl~+`BkE@Iyz%3sOd+ZOn4OzJ$Y8t%v0eE-P7#HOuwRdO zx69dtQ42#6^41@67tLMf4f5EVDZzw9B%u3@Y-wo&ubxB$5}2k|jPkR_<-NRi?n<W^`w{Ctq&stG1OKfKU%>;@}VI93Xkm( zoP%2dnMwZoH!u7EuS9b$@fweRb_-Qu__41t*!KFry#Vi8mK2zSq$kKxm0$IR%f1=e z&s6yoS0yh=fuMt;>}o^bw8b`fdGawb3=j{05vIUwheq)oRe8}RJ5TpXUTlGZ^v2g4 zX--8^#jAl#GB!radvb%Z0>luzeUfEC5wR$E25 zCAG$kc>F?MYJd^JQIvcNvpf6TY&=3~vI>7%mWGg2u}EC$iq&k-ihlr63cN z@%Mdn@aHoZ6GZK?CWN;_?40NPw~L);2zY)zIazBz*9GEmJfo+#c?#E?O#h?MeM7%0 z;r)S>*cib2Hj?JGS4w_H+5ZxN1(cIe7tbih>a9%B4 z;^Qq=jqVD{qg#ydx>f!VzS9>6S_+VhA&@gS-zJS8B-9z|+eG_jrSsXY;%WwnT*dC- z8b3^(m!!jV0tIqbbC;_~lRx~lFatd)^F=;(eJ|7#BCN#s3{cL!$VyK>nLviUK(jOV6@qjkQ%gnP;Z#-j5!+X8D+98c{F8V!p>d zU0u6wcD6`e=;$IE`$TWUhCI1Ra>hY{Zdou}$u>#Fgx?R)uU6<(WO#qhH3>o z_|PT3F!m88ZdgaZoFM>Py(ys~5pb@UO$wQQqoSY?wK1w6xv4o*Z=0V-5R?~O_Xir) z-)pXrU?Ap3-k(~ARGLDS(2i20|5Of*PXxoWrdgmy7hiwKM7VS9;ajp6gbBot@aUjJ z-R~X<(X44eYaL#&A8h7(|a4Odkn0o~x0*C^BOjj5p$r&90#{5z4yQG{fs7eH77ZRTC z4X*7cFQbkDeT!^KV&(kgIZNxH>99`@8NsntzT!j|u|gO{8o?%GgL}K`F*cWK{QBqT zaIeofHc9z#Gsqz1q(aCl(&Q%yl0tG2BX*B!mjgM3w z%@lKfSqq^f#V0!8)}fIQLF#o6lHv$2LOWcyHk zwQe@Ol=10Gz|y;W&z~-@+`j^{^AJ*L#}Bnjt3vGh!||YT@XmM}e<0}tJ(S1rK}cLe^#TsZ0}^TBZ+Hhi zON?jFiIa9giDdfBV=_ACGXnxehhOv%ul7jZmlJ@-762V*wZ;QVjKGv@Z*TCHmX_-1 zHh}Z%H}^)UPR5(UVbl6fgM8NjO}4Rhdziyw3ZI%Z-%4Aez(P)J?$_r7hBV%dHb@=O zV4m=kj?-spIe1O`3LI^K`5U+EGm62uv*x zFBS4dhow9Vlr}!aUC+L&Cf%9ad-3itNupbWT#SSSmg3;R8!0K|J?q>XflipU&OWdq z^Gu@}$Q4%%T%sx~=+finyyrAzt6;6!C)WrJEtiB}Yu!!1$>gwS!G6)zq7A&H#X#|z z87pZJvN_lU?X&?CVn))ue}qRqLmf)|JWh?)otXcP8JLtIDM$S|jp<2nN!kLwT@jzC zjX(K^J}$w_XZx{hBQa);D%Y=eu34EGAx6EyQW&QYECJs(E}6eDRku^gE3$sw=1zOxzoZU+m!4JO5W1?=T|%;+%3jr*89kj6dL8w6?; zXYJ>No^smQiL;F$&NCf@(Q8Tr=zWbjSG^O|D4#TSS^bmer;(soP9xQ^OsuALg2{4* zesj9btkoZ=RitdY35%tb-FJQM zhDN+K+vD*d>=L76X}6>CyuTJ(?KC+Xjut_l(oIQhe(Bjd`884KpacKB?fQ93fc6N< z?Dod&rnb+I9Jk7I1N=$(?tqb+!!$5aiP9<~v9F2d=u4x(J z^5-q7^73K16Hj$%X)PCW9n8-Oy~`P=qx(0DqvV6O$vSBR5H`A<$1U!$UgrFwd%krT?BZOCY5SJm`igU+YtMDNaiEyqt|w~yFjFIv0oULKhvP(HfVYPEeT;}6GIVq)k5B+Ure=~bqH6QC<$IHs5P=x#`V$N!ZK**RVUPn^l@5+k!$2jtbN7iy$Voyh2~@7|h=n$=z!S)>6F#P|`R zIgv%9`4psyz0S2C+>D~eG{0APhMgZdZcl%mehQ-=>%cW&(1SFxGU3h}7ug@FvFu)1 z06%c4>6|Npqr^-)3af5_CdBW_T${an5OZt50%cfL@IUSIBf%M-6nE5Ha2_Q5Ivg~! zMp)^bP1++n-A!8GHxD@)Qe2q#tGk;7Sb?A<`I{MJZ@qXd3M)p@#&f+>1te$?D%r<| z`Iu`sVf4rf=?vZ5H$`9I(X{ku6N{!sqR+-*==XBP8Bcqch~6=;F{1fNTn-G0aT<@K z7H}I+p||A}R0?apuaAU}EjJxN&q+?X{+0UahRyydqGI;f3JOAfVw`wrU^x#F13??RTbV8I)4;{sy-)=5VB?FZ?D-+brkRhT+k&NB z%kd~|>yxGE7p*TjzcB^%8p2kg=7i0fkW#f%AruN@cpnr}0$vCn9C->pnovY}2f6|K zm&XS)H1~`qh@VK6M9FymDr?dg+E#^pN8IVIPvuZ;8CZ9wY#yF8 z8iC4K<-ygAXl@eu@{ULrbI|4Elz6Vzws+y;IA%uFsPSbCl50jRlHL24;HlH$Pgzke z-!>Ix&GZyh$RdVK2#43mTzo{(q6g*|tttKd)8jqDEyqRQ?xGL}i0e-Jb7f%wuiFVy zyrqO6-jpQ=@%Q(@suXVUyQ8P&-4jmxD{o^Mvg!jFw$aZWC(cVt_&k=WXPWMagQ1Y! zQu1I7tgrDN1_cpQhJZc-rp?g`x?;!Hq8`>_=bMwU%9HrR&d{iRrL)A;H+_q>MyyYp z?Y-}YKM1HV;3sJ$xdfIG^QvfNEhAd4LYXhM^%r+ytd+2LUm5ff+r(q0^QU(8lD<U#-y5+amY=i7BgIl1KR=5D)5}?mW(XSu8TXe?d`K`%n z-U_E4$vSo5+}FaMwf3N-(ZJynI93gD zd0TKOD063h4}+U)P8@+d*Gn-|`tu+UJ*X=#i?E$p>))>H`D7Czx*y4AfOy(yjG_g2 z=jvJWn^@77Tt3r%X&1l;Ao+iQjxyFL1lk~rzN)J}=fIrxP$vppWhXLcrlsKm?O8-C zyyX^ERaKqCNsQ>|c{gv4Lt5zRrN!+uGrjCG)gerf2W17f#o^{mY74)4q$pAC#~M>U z2PVnBJXNk3MP(feT@AZB-2n0CGj7Z0r1$cyxSCj7+-3PLG$Nk5;46LKMSe}=e3QTt zCl%H@cgM#-h!007jYg9mjSIi6n4dL{2RYDA4cMj`qQ_e~zQeP5e=9sb`k6_M%pr;i z2HEJ8h~?wWzJ^#^OErrL^41n~Q0r#r$Sgch{@rW-FChh=1()~=UvZsq(tA44EDw0m z1A5_ZSq-M{BEH99SuOL3VvUoV$)hi=0*!lu=S7#0HH{7sQ!>MgX++{HKiO{5C1}3+Y=79e+ueIKG7X zd#arGw*-i!xW*G30ukK#8|P|QhWd)t*RUl?^h)Yxa_D+a(^K@n3ls8($|JX4h8|SI zcAML~Z`?I%Dm6s++Jd=&)}XdB4T2x4rLxqArKJZnbQ%#rQECnuqj=TP5Li@r+zy_# zpfON^3~QzM7AdF*L2PVn-jsoou>`^G?d=!Xnxgc%Vbp0{5y`XTGqRR*SfC#xlW7by z&zNs2pv7L!$4GLE?T@&zpO<77-j{UPPk)70r30x0TN~AXYI}su?1wenTY?dls46kJ zLWi-@D3w6}tuymm5_u{jL-`;YnhMMxu&F;yCV=pRCHb<`Iy-D1N>m;U8F0g-Fon~h zz8!eucA4ysH&UO@PyG6_OnAJg&6QmrzdFqh(2!&wfos>>M!zx1rz@?Z$BVUz%S$*$ zgvXIZ$Wvl6|JaiA*Zw7CaCbg}w~kbR?AB0CnpWh7i8Ikw@FP?Bdu0|70Dvbb^ox|q zeog3TsqyCyb@_LkFDAv`QDx15(|UWnfR_Sp81PA=3?YESCqfBFA|POBMV|3y0+soa zsG+8Y4w#9_Z94Udm6e6X8z?~t&x0TaF2Df_>Iwzf+AmP2Md=0X-X)GpOjPsvN-Ph2 zX`wo}=j}=K^W&|_#n#}AOhv3RcD{ogD=X_ny`4eWlpw7(pyLSa41}VkkvIlc=*4~M zm@ZP;=ck|q7JLHd+=~jZ6|TK*GW@`WXQP4lymX(fcMmd`LH;aaiz!O}SfXB*T~SfN zr0!5t3kXkOhvVNapH`4pvBW{%q_$b`u}YIgv?pxcuf=Qoc398X*kqOi4&2^5 zdQUvx@pb7+*Ve2NOCa@_Hif8IE+w`dCH?-dk-eRE6r0~Kah@KxU~FFx!f6f0dNKz#h`C{uR7MS7_5^cSkNGk~ zL)O&p=%2V(Q2Xv{xW4o8_}gHLD0h};f`1&klNun2+y7OycEO(hyX{?Dkq-0P&)x>* z{rG;ebiHO|8nBSOq5`}oC#~_z^ay^pu5*qH@|R4j7!y>=%`uH!T_g5}_xPZBHYE;E zt$0q9{c+PlZ^rsR%iVg@0!vCsL4Wvgk*5Uy0~VU9!Xyb?s7!wS}o0G4I8KrqmIXjjdbFAp7xAE2RD1#GR zPp4i;c2zjpcMoFn5;K9O23}5SE*~M}wGyj!#jdx)9L32pe<-nF7={jKI%R(&(x`-i zlxMXe-L~;=YTjcA_VY45@!ZDbSq~0UZkvm4yVy@px1?{GPizqy&E>XssUR#@7y^p4#%7q%0G>J)88ToPH&u`O@{_2$*~S4h}A%AhMNIs1yAvffzG$ak$)QFTC=z!*-@X z{)f#W`KQWv%*|m^Dx?=KNKD%w5AX0#zsqZ^LEGuE5MiZ9QsHsyYdB^epH>&Pl+oT- z=Hxe^TW-ZWMsYKdU}WUtanF5C_!)-wXqZ}1>EaxeQG{{VWM*%e(vpr>rYsA#ma9m5 zCc__<{0xz*sgt9e#f`PRM**tX!Vs3~m{NJvj&&(;>)-4JcZIbV=}FUM!R$`*q+1jB zbi=-Jjhh#~PrCFu9b)}w9@p746soyPXyiwJ=VTTP{930`+la1PlT8l|xyNxjG4QC49Zf&fM;=^|E1ag>&o@Uza!y})Grj{k?gAH2br1q}0%{F#dzCU`zosBO1 z=on#`G*qy?&CWa0S~k9D`A~$&>4?WD=1QUEmP0M}5kvjREc|Qqw)edyQMj73W!$rl zcw9FqW(5I0NVub;;~fPB zh5OABHl7wz#84<@c1=uCL@>U!Dj4#EHdr8E8Z#pU)?=4PdZD zG^WSTRNy1b^apI{&K+|Tf$x)|deB@W)POw|X4TLiA)T$A;kYfm3(+DeB1GJb?_E_! zT5m7~IE@?wpfne6@OVGLoLxs}C*j4opU2CdcXWZbD542_>(Iu|U}HTPbtYzwhl^Xo zVRmL%i4&R%^ep!uSd90BSh8%15g&d(%q@Xho~9z(6{i=MmNNCN6tcEm&->PhJ#D;7 z98+6FZ#T_Gi`LxtzKhUI*51!Xl7r!V*dLmC!eMQ$C~^_jt3{l7+~8k#Lre(8zg(|* z0|@_H$ua?#Aeq#sbKb4$dy_1%l5VR)EMO_F=7{e@JaT25wLg$%-nV?Q+Z^a@4jXKR zlR$IB-?cOESX^P@oE!|zj3>S`Qbhi+_e8xqiAzs!yS}!5cGM%@1zm@5+r-@Ba}*&V z6)8_giBx&B5%!}Yp!<tqW^HtKqkxY4`>WGF1Ckd?95%*l|GRctfl0fx~;BzzjmJSnZtgzhUCLM>LHTl z_I6OlD=#AmoiGtEwD}ko6^4cNz|ceZ{Ogi5t0|-3sB08vZ+TC#(5l(+sGJ{b_sCyb zFsf%w8Grpg6ygq9ndy1MywsNZaRm)M^yRMjH-q=~6lgp1^JJ7xXI_r>Xln+Je)9RH zMbtwzetObgckwo*g=Gt5e73-4=dObz{QV<@>{Kq_z54RR?`z8R zru3k(r)sD#T4M2%=ZBe;(8K9|W@f04i`C7tUUoj=f}T4e{!=e~gTB`1`)raa@7qTF z3;z|`fZC2|93$yg@4vkOfWm62#Y05`uDDnZl+Tr+s^+%}jnfnC;qRFlcHS@F+S=T| zSmlt&NtkjqoAva-?sz6V+gBX{LnI>hNkkqVsl@sUM1BQjl(2o>wYIdy)PixxB>+>V z-)X=u9{!YvG>FW2uAmC{4Fi&jnj93aRD}JIt&dGV_@Q56gEq9KwK^rt_cGNcYbMk~ z57lC@Irv*+Tf(;KA&FeLm^&MyOX;Cdb5Pb8@%omS^Fto@`{O6Vi9vwXg4I*TQxl!kHt20L*xO8R_5?lOH*YBiCF5Xi987!MH$q8o~XARcuQ+5^QX!0v4dNd zCRX970W%V;AO62|6nJ^hKw$Rv_k~48!2qCv&|VcsM$QjUMH}khUhfU9&;pH@jUC(30|^kOHOt6FB(B<80v{ud+o(6q5{GzxwFxbZIU$ zRkR7s3gSwOhm(bs743)_&|__}P@Ui9NcLtu-rzTE ztEE6blCPbd!~ptb>JpEcSq6fBnc5izklv-GrD{e``r+*b4h|0Y`-^h+c#bf$291wELg(k(7-4Rf9MwF^r@*8M#uiyRF9s$cCetPh8r@vg(cm+Ljb?wp?n9bNG`KVDZd9m13Cl=&~q zj4>mJ)bc*CKSL;hg0a54dXYhtkm3FB2kq>c>QJO13yQ`F(Wm^Gc|@@@ilF{3A+KdBgwuOd*|EZ_Cjh<|+K1DwaXkhocFg$+0> z>(3<({AmuP=KOv4N)rl5muq3vISGpsUcBM4miQw!^4CyCxM@3 zM>jJH3$Oo2X)`$Fl$rhpQ65n%#ovzHiPl|T_=Kgd8z%O-J~wIpdPb>~*9*BM)HNv7 zi`6-!1<|OtkDeLo!x5^$N{}+Ym+@YRmsE2TURKrf(dR6Mo|y4T9y;cLbVL~gR=!Ju zvkKq$I*6^bfnVr<;7mvT^UckcfeFK(0w`S7qW6Tq*8n7?euFYbbmuUQ%O^pUgDjJW zF0C%KL>gmbN^Tvq5(ExED(+=f8y=Sni)U`kI6%)IL$`~aZl52zU;8OWRPRtk{0f6N z)UC6=>(iaj9AafOf7E`Ur-|)ynx>_$>SJk=+c{AuioWXz@;BmJA6e`sO(>IVKV+^c zOSqfTvQSLH_q~2h#3AT7G?#tcPkO^}Q->I@J|YpveRh>Dns%jA1|fQqJR;Yp!FRc* zL>8-D(dRd%i09ZN*@1V*B6MxZ+?cqOMMOuopw*@jm>(DBzC)RnS%ho+4(&XZ@TJpR zfWYCCPyRYyzhQ1*8Ow+2?xABmyWktgQ;O;Qo#Q*~zbrddrlYeH1Q=gXQgkpU)jG(W z$ZS(|3tHv59h`1KJN8a5sm3U#h(J3!IV36>6Z*YJu<3KbS?N!RR{>K>qGQL6>fCwR z&p@F)n0jaaOiST3N4C zZpsJo@RTn4bL(5OY-7}0ldEAGEeapO*hW_&!z1_P>kpl`>de+-h_;dh&B}zUlSDgsd_D7Lcdt3&bA7GwF)B40qI$YhF{OGZH zQ$|Ty=+a^1?Xw#VaD>$B%=glcLFPtKbH|C0cYP7ARjc(%} z!n?<2I=Sl?6q9=PzLn0|HEgWz@j}jTtII*eh+EuZb|>%g+2!5oT0*x(1C72HfFz~7emxYBL;um4e7=wBy*-Ph|7&^N7JYm~ zUcM{nGJExe*P7s(04{`~-^R$v`=<}Xm9Hh(<3r||wJDTUY|hH#&{?OpG_z%{dvU~8k(59~1B3$op;vG$zVX<~oa9Pc(9TS(~C|5~mQf1f$uPpCB zMYgORO`tIlfP~>x6F4oRHCagnXpWMCoX}tS6{O-!I~r*JO4_KB+1I^llJA=<_&vVR zhg0`nukyj6lbuI*NQbZK7ORTn7t2R|hT?KOD++dK$%^^BG4oMJ?#&MlN)SM%^LNrG zR7*kRDreB@saEEqO0n&JRGL?sUc}y~&dJFM4gt~G(II4%VPkE5cCjrBu@xlci5fu_ z4^vtOADJmkUz;S?;)_0tM-4Vz%NAU>^jklFaBx;U8PC7cjW2m2Rrp8G7!uw_Y)sHC zq+L2cABu;hq%1ozEkQ+hE-_1$f30#nYD0d6j2+Q0fqj&X)T=LfhJxB*t0y)ASzN=a z`55m{UA<#CLLZ4N%mu^T9980D{qCMUPFMKvaa8^!B|;FWRAX*Iupt0A(I_oTE?Sk!d1@(Ohf zG)+5&KY+n-4hebpn*ZUH3Q2$b$Tx$QmHc*4FA~Z2Xo^50B34S_>C1_&N4re@(bN9) zoT-`^gZ@NRp{Vpz4$nVg2^9zk92{JW&!ajFT@f|~z<{vs6kXJ8>E!IDrzFn#=HHBj zE_b-xX{|5^{b|9Bz=Ii0Qv0g~lfp!YWen^1$7qrpo2BIcGA|&p353zq*50^2oMWF4 zNX_TrE?~E6llpyuq*R3X>c@S?s7OdA`_BW;l#!U&*u>=IMkI}_T$rkRinh0X`p^uiElU7VFa&pyyb5jNN_j$Zg6RG%fDuiHf zWzZ5G?JKs5GGqekhq&HEh+?Gua2P4{ui`hPaqAn%-us{gz38E7{&V%^8`2`@yB`g^ z$k*>{aiL{t1L?y5mHQ+4JHGXZ;GLnNspA(q7pfM>knBK&mf{Gq z@qh9#s5^1?F8pRTje&HH507Wj;J5Alls6oeRZc?B1;-PohX{9+#Q|gU(3wX4HPm;k z4TZZ5?hm*UzCMuQIDEnIm?1X8uaK@59FLYD8krQ645M8Ggr~#YZmD;#B zs`ml$R;f4cFpqS|n=SHmpM(&*-3t2Bz{lcXSpms|>U9TI5fM$$u;{QCKLwpMsyim8GdbAQBm%k5s!+ z4djks>UmPvL{V>Ay}JMK5f5#;>m^UW1ozwE6ogC2WEcgG4V54Z)3S0G_AVYKVF1YDbV zu9oMr(1^WGCp!JIsIvHhuV$OBVsv`<_Z?~j7M3Ft8y&tz!|n()*K z4!VS^1XQ`LAUWGCgVOsz8NK9SQn?=%iVSyvyXY+%-XTU#96qZ*c~UT&!$>94$|s>} zvK6vU^q$5>3uZ+MMrZseU7K4@a7e1R594FP^i5Xi45Gjx4{~>D$_~9GKjI_M z8!)1uh$8T21Lr!M_f$4NBp2=SytiPA%K@zaFJl$TM_s$T9~c-YymGL3N43T~ZLhuW zR=(NR1eH3YK|6!;|8Xv~XssGm`vFCf7{(HaUWJ@Tu^w+q!7i9R!@eb^37sQ6LFo2^ zdy|=yR!z>h*ke%%6BW(!TM7Zj`&;JHlxI|u-(x*Z*Rsst<0*JwX@o?YV7z~n_8CBd zR(-Bvj)}sF{$*^gaR+`VsnEe)GC1GzXbvy8?7yv}u<@Dh|1tI!Ky_`)7HF{G?j9hx z6WkqwySuvtcXubaOK^90x8Uwha0@Pfb8^nP$$j_#`c|wY-nrmilL^87 ziFxl4i!k!ENaHgrbhojH?M4wi$@fDz^bywsIzuXUv;Bn+Q0q|<`{5o`u`qH}6m>BX05cL>m}^ zL8G#v(}`!v(}vLs%^{~y|gUFBceg(J)?9XVs~{}=6|d9p(Pi+1s- zSG;3KsbH|uQEk{$8L>rJpC%cV0GlT-+DTBRfi0q1DeP&LkD+2yZEg+Yt<5&{p-Dlj zWE`3#jtb`O{Qg)}Jd7JE-O-L@XI0zn^mP{Do*B5Rh|q?jDmeVJPe6zi4Jn?2BF1!S zDT9%60;l$MZ73uJ9&hftXkl3Hsk^+vi#r5nMqaA`zySl6S9%#bw>m9ny_T~@+xem^ zV%49%4ONntth8R$kYZ_u;zYU$ce+&O7>fhKD~Y-bsD5l#B}IhX9BL+FbIK5^->Vw3 z<}8T66Gz@uJN=&B6#yh+lDcEBO+vv(3=oH54i*m3zRcXokfTYW1f2F>p5!OFozS{l zb?+>o-{e`2S0Ps&KQ^}`UdQ$z(sJ8S;He~e--ZwdTbu7zv4aTkP&Hm6v!imPkT=?u z6)Gmf+ul~OV_n;Nr@*ku4zmAfJ~-rKVS*ZRkrkIkLR!QJJAH>=H#(Mu_6TQNDtRK8 zn~yWK*8hR>f+GJ8cWjP@=#)#(rRLmJ4Jy*&9-pel!yQpCXS=gP9v$T)C3_ju1FfQn zLHTM(sl<)vW|8lw#GCKKHL>Z`fMqr?7p8RTx>@zJTmMKXs4NksUQ2Mw_ml|>gGhnZu5T&Ke^c<1wRiaWLl+?tSt zRkgJ2ibGmQI*_^B$O;4=zN>KHMi7^fX!ccsySR02ZDW96P)`jqIwa8o^U6{G`Aroi z76EmAF)Pq?L?5ea=T}s?vkHs87gDyOCo6zHkysS%wAJgZ0m1Z$Jvh_JXUU|z=Cfde)3D1 zqDm3NO8#v|-p`OGW(f~qLZ7K$&yC2-^eI9)L$z-?`4(azO^l3yk&!P(fQcdpV-&?v zg3L=Eb7Ja1R#M$^d>&tICLIXSZdt~o+z%b`f*?uUCR$_#7|kv*=fY}sid}T3;E7^x zJVc!9O~Z^V_lR6ODJ0Cv-S|pauLqP@Gl)71z}Ov4LQZ*r@L=t7MSk%=5K47^HR8zE z97f*x3B?;B#!_wM`Ic#r&+E(v9a;)I&!=BYsZ?>>QCFBbwBCHp4xVEfy7ma*IZAkf>*)f#{Fgu=o zu%cXlr6x5dsEg zR5KDlZ9#V6OidoK@Q7IF@;OGZnQGUROq*cc4mkfuk=9-gS!xwEjI3{Q5LA^=v!&A* z)6S@e_#7b>IF~oWMuab8=Jg&*_;uOw`Lu-{_zNjx3Z^LUs3`bytv0nQ6w(Ml+X-_YUc(IU$q)Iu0isJhLy&=2n zjOgy?AMjG%WrlH~Wcq`_G4aLu%Y# z0LduN9cb@S(*J^70La1w1VCFU2?+`5!>a1)>bm(wMMaIy7dihDC%r{|fKoPm$~W~D zpp*?EL=bhI{HN%z{fsKcYlEmyLNvy?Ku`6d z#ERhuM4KxN%NhiwN)?R%dZYiqg`uyO0y+(%bj6cj^bC|z%p3auCv5#?#3h8cVBZFw z=WeM>W*&5|-iVIjw!4rApGcGD8YhR=JqYi6exd%^J39}7g@z2jt09+eoGse2{B-Tz*s((2AZ7Thi#PA<8!GN%N2mCRXhpyoDKm7Z*O_yD z$0rMNyXqnj2NEGx`h(87@WJ;cpTY%pH~{$>flt z-x2uDR$>7ae2*Er`m}w>!k@K|LRjygT?=6_{q|C()KO=Gqhrz{l}26#Y;0_9j$X9= zWLYxnuvSDOd@uG4Sy4!5kzC&AF#q=*D#!zi9Vg8Nrbc0p*7lMVceOr~n&ezU>00OY z!(SDMV!Ys=eq;<>FMylSlXf|*+uS?@ciQWK#JBD)%;2K8@8SBUsTn!`^rX@fvVfSf zeIBY;u6IJF&1k&?H7?atxyAqSQd4(Q{P@9)Y%aYmcvgU;yQdAaS!yka4uF)7lS243 zJtlhV5K|uE1};BYU#72>RthAoE@NAr0-8?@372ND0(o(MuOs?bjhEc^0-+OW^g~t` zaqT!YRLhfV(&-%I=}Ybhy%d)t5g5!@(u{q5q|Mn3a*W0;>u({D@eFvkFRb-=b$n;i zWdyHVTYS@%aHFH6)!Gi>bzy^-qi&rYFKiZE*HX=2H6_<|zM=j1PR&D(UUwpEt1w&e z6&URaV|CM`oeO`3Q^tROJ1o-s0q68=r^4Mq#pFMzj?+}#cKzH8E$(!s@?BgT(sPrf}0l8 z9$}=QoL{h@Y2j|bEd0wnKU!kI9i#jmm<8`f5%K~<71|9vPB`ovRKh6f!0?f0{#11| zXapm^7#h%l+m~*lMCuxr-qW(NykAD=H4llSF^M>CbltzwA#NvmPj_;TnoyDClV4?Q zTM}JUerf_c>4RUz!8-p5H9&V=nj_k36GoD)f27qG&TIbCSDA0HMqy1S)t>e}V?cTt zGUqdi{!!bv95}LZP_4CuM$a4k30ZkI8#!cv*Z4gZ-2*|^q)*X#wS82%^|-6z7TQDF z^SnVgek1pMs^Vcl&HZ^HFeDu-OUlytI>`-b@g-Hsa)E;*R|^+ycKS_wh2F@z+${*Q zv4%TPE*^=|VnfDhX*uECNho3Aj@tqkgf1xAB%uQP0wfMz9}px$c?W+4CxXgVi$xFH zhHXalV~nzO{!Nv3djU|TL1f}|W^B|aF?XP2sc_`jbt<3F4zab6LoG*SO1EsLYLjI9 z)u0}$dxk86II~vX8WkC9&qi2o9BaTk)P|*l%%1rJY33p{((YRnpZ9qlyUhWCG-LWv zI&l82i-V<7+;Jy8zuvt1$$ZRXkFhUh(G7a^!F|?}6Rrpt{`B*Eh~iqM9OatA>MIVi=&|-{bXE?UA_| z_HRx8a7beOfASKb-Mp8lQLS9 zcNAWN`AA~GJ1^BRk^C9;uSzs6i#}hTL!F@>UKmEhFTO2F^VcZ8s_^b0`Uj)|n{BMm z70x=koLfkO6UMJQRqO(}Ybu^j$jxZCbxlbOw4!CqAQPVqId4|3gB&;1?KSTpuT`vp zRksbJ`u`Dq^$?~y>_nuX%_#`szh?(-{Y;ytB<6omh;cqfB_lGV|74iKi1gPPitu*6 z|Mk+DlDwxp$M$p1wl2M7o0P+CM4zm|;Z|6D!@^8|e0GWbTg~K#9!_>cA@!OHqz+!P zBKiUUp?~aRV~&KyDbp6#=1Ie9z3KLWa%u;fHw$0e^2^CNZ`NqVyDd? zgF_$!Ykhr2+}RFRQ^hd{53;oDZ@!Bu{Wq!e{8Zv#(81B@Puh4-M#C~GPojnU4CbcI z#HUWX%I|C1__}V#>f+YTtJbJ?L#OaZ)*4_3UM7;a+C#EasD%4jzw9dF{MEG>R83g z)jmnQ8sbc$xpXb&l521RBQP0o?bXJ3R4VqF(iyowfND1}`77J8)T)Cq+KohvnB8qG zk0Hm@^&;;%;7)935u~V>_|j&u{oK1Vdek_0oeBK$19Dv0vGN8Zv?F83WdwLd{QyXk ziK%e6y*7omZ~K}uX}TK{PKwHOif4$GsR9_0SC?%Ic zG2Ey=34rj^?iQQXmAeXMkZo3Dg>BT#6s~89xzO0~{eDctq~o)2c!{!!Y5x1o15~%` z`%%?=KiYZknLj8lKnUbxCgMHtop>0Lzr@isQD$>MH+osN!zl&F5x(6d0}B=cO?>;2yzV4I@5=*Pu7gNf`&G6I3iz2I@(ECDjQ>c?_i|qK) zxVVDq{%r&=`;Vj0~8cn`=;)zN(GE6zI{{EnMRYwec zp2|Y#yWIN2@x?+cW!eFgGFghqg(tOGLajP~q1Pjy#22oah@jKUm>p$0O( zPL50VD;a0dFG;6s!x@Uk{mx{*z2-wH0Ma?+7O()R(%l}XPk*Zs`$Ym(#0-C(68s|? z1|T;G;8=J~&)^tSn19^NAD4s!!ueX5KkxrnAT9QWM)K}VZT`piWB^rPs;a6G(9nJv zT0^b%d6ITUMkM_F{9@+9KLNiV7sKo7%HB3GJQ&#v_-!&CAmS#>il+~S;BPz_YS0RpO7RB(7a1(nFROQQcmv~2@B0zzeP-vE8Xv&H^e zMdE+|geb6me=VUYAa?V!YsA1Ae^DHRLXX-IM?WVk2b6I+dmK?@d_?im8oO2&#HGO; zFHh_7OZu|(FA(<38(a5!PZV7Ado))`Nf;9vtS)=A$=Somw`2__y`6N^cO1o4f z%5|&CLPvcZ4A7iH=OQF=P$4TyE*0uuV#mn0phNe1-Z;9jYvd%Sv|fCgH`tiRL4-?P zdbBY*W14K6qWz*ez++$0`C}YO;%%Bh_w3K4y4}b$yMZ0S%>^DeLguwZ>-s!1nWSVo z4D*%+;|g$WY&X`H2EKLgbmye*G;LX|EyA@APnXt7Rd*O`!QXCFA}9reS+BVIuK}$m zNYz;*xc%e0mo6D&9Bt8rUz|Ji<_(!h_>2F@ivaQl!)HmqGdT$>F%o=g3<@5~+kn=s zeH~2|S;QyVvY2*6qr75j`lIbO=uQ=x-O?UH3-o#@%$$_7=9C4@{~?CPe9I}89Cclx zs;`9_9S@*-ff}yO!EM>5-)V@w_s@IJ#P*NkXOYpM2jJd_aq-qQx>wy;Y(0-ylQL3$ z`PMZB0*wUjq?03yJT$W7_t!^GOV#F}*gP74rudR;N<^p0JsBhZN9f~G^i_%ageVWN zm_GcAHj8P2h@Aj+1b9hdJQ4*u{K$QpV(ke8X7fdU?28pkbhGHUF_8mq`?~h{+O<}j z5pXZtReSvYI}oPBTox&p#0hDUqqfCz|4sOmHmr2Z`_;Dt!AMw4=pB&RGc`tGJJ|sm zKMlRo$UyLDC7D&|A(0IFDX_cFxbohn@=Swr__P>%(Qg zLu>30dhrHY<2}QL4+7(%ucDhh)mIqd*b88I4on0?9ee*ugKAfJ&J|iSW{7^Xc(6AE zl8hNZ2F4Z%cH~|4X}ODcip4Vd(=fr+i5IKa4b}Hh?R}bU+fr7!kN=B8y8kXGRiLre zp)%_Qaf1QdotQqFMHt%Ke(|D$vlXG53R0!7tKOQ#fgoPK-;#g7WYFg7EfRuO*&u72 zkwwLZ*<4vx@P8#cT!sG-NJf2$J}AroZwjNxoI9MY|D!NslWKAObZzni5hR__oy~!F zu*fieA7kYgDv1urN+Nu6T@Yx~^%_;Lg$P5F;tkU9_)0UzcSc{J!|o1ygL4Nx@-WB$ z)Ur}GeC&RZEHFM{)rG&n&_ZxJn(BvJk(^QOJls{PGxUv+>LU^-k^TYtfU<$+=LYE& ziDKC5>$oN>%Bomp=!~($t-U_48lrWDKbCkfuMnb4N@**xH{HO_%9dg9%R2LQ@z_8B z60De4bU&f{(LC6$V3hO20b>L4;rx_PSQl~(B6g^;ZbeM#I)kD}06*i~(i()P<>LJ{9Kg!AT2N$VyZgfeKho0w2zalD6j|wgN0> zpD7uUlno!(56>~V!88wR+$?dyvs-4-ou4$`#qjoXVrWnYBqK=Q&~%2o9g4!Wgd)#} z(;ru43}#3b2_<;^kh4Sx_&hJqd1fXzP%;X|eW<4X;aLNMFgePacAB6oFt(gvX{2KjV|^a%W$cIp8Y`BWYl~TI_$c`4LJADF`A6QH8+Lqfu2Mh=*_pmU918;Nm9niIn*DIlH4vy(rKFhsm_Xc2_YwE|EnrJ-9K zAJ7uAXhWkBOWOU_(%fbyB52h3a{zW9L?%ynO&YWc!f_BP4)}%cdiRQi&B^qdMA%MC z&SRYQB;Pjo&FCZAzW$f&E?~T--JJtM_n$}?Byg1_@f9uQTsTyBXQk695Gr(I-#w@? zwM82=ZMKQGbihfMpO82|v9izbKZUW9u<+3BCU@4f=PINgU(uC4tAwx5Az<@3z8fDz=_esbLT*Aj3F~9%Zee-XPH)Cy z6}Xq+d0r>YoA~`xRr@$!c(lCKHJwI2jXQ_{hCx3;n+{t(8Enxp{4+n-JzYbckJ1+9 z$0|;xP$Gx(pRn2Ek$Rs|&jd>-@kmC6)XdWAk?XE;!cH&{I=+{Ha|_ zg9~69&LecXBTFU4MD@%yPVzwKr$&aZ{5Cpjppw~YkAnzw(d6cJd<9XRhCkX+dW8EJCk{OYVq&BS!-AU8?#B%KchoN!eQaGj{!%S_P z7q4RQJiWs--p)CRP!UdIF9NnNM2_p^uAtEH&F>#3n60DEJdY#YK6P|AySYqU9|ubr zk)9tVG+^WHwl_zXNQ;%z&)VaUItqJ)&W=P8O$#`(xip)&*86uTp}?hyp_zy6$UoW? zFJR_3M?A}%Ejl>vgnSuCUMF}*eN3x+_EHe*klUSzxL~&i14Ml!ic6ps1Nj=jCtugIGEMDnmVb^76(pczK^M zBkIGz`@9TvwAJyaEGBMMH)SpkG&@2FF#dXZ2Diq=GvJG}01ovK>hb6 zDeVN2kkdb+DFmNb&|*^^wJ8|~%}JYQ41M1-eX)_fyDUv;dsWCg#_0O3DDa+6%sbNw zbE>B=Y~`UTdfm-KbPvQB5zk9mlHM$>zU`e#XtfEV7Fd0UOK5kqJGoTAU9rVA-HE#$>Qk*Tg;Ey zPzp)J;lGk6GT1(VVoksp%kb8@$)NSSkaSQTyeXqyqp{Y zpt1EQY3u@$;mL`}z<>l-=E4#~C5b+5y)EZ*X9{yAr-tI=BwK0y`RUXxr(Rl?B zwx63Jk}trP65V8mE%aJ6L^_Ittc~m`9b_mXATQ`^|q`{$KvzxdOC!3`;&n6!hYzZ|hY&)t{e0tHV=sNiQxFfZvHBAwYr6 z^u?-kEPh**g(0BDk~%3dF+P9+O1uIBKm7QhpVO0)f&l`{IlOjKbhu6?e}qjE#*s0nI*;ngSFEfM>(J z8yZ;N#8qwKgyw+j3mHIrJpdh@{<`DB6;P81)7=|*)Bm#K+l4m(BT)N=39*?vrzb#{ z!!U?x#)I#-^El4U+{fB+`;6!Phw-L0j-M1;n8d^>Q=$Yp&gB z;uTb9Dc#j!7G2<<&1dBl`F{)-sbv=LiWO*jTEYEbfzx>=cN@iCLm_Tx6Ya|kQ{vN~ z_l;MxC=9OenM>R82emnQP!^Y-cGp*2OMV~wNNABs$^T!w>l+xfy-%LLFW^cp=c!UqR#(nJ=D^}VDDQw{inNXxjR76w|1gl8^b-c+{}BCK^+duDE_Y*;U}=g{Ci zv0^;qLDLHoCc=+6>Q`0*G=F$lzT&i@V&i>37N4uAJkV~QFk!B0-R|}&z_VHD3|;dx z?yzvVo5D}cJ%#-{AY*AQ20Co1SZxdiI<|hs8sBUsb|6i9T}qTj)}+ zejZ-JkE-i{S9yevn}1O#ix~bRSW-aoImAx744=3>;;C$@XThn}yKuTw35Udk+%CbM zT-7iFEsEwyOz@ql6;N^0qp!z%#8Yze>L$(hpqt*NNT_rDWT=vYASpn}$_gP4n(r=7 zWHKTv;%rP?FVfIGAJo!04SJqN4~IK1NnXmoJc@}&l2TdT*E8lsfkwzij*1nyS6N-_ zTh@l^>VjtA93fEh>is?V>s`5selR}p{^{3=MiUnr^hjMEotJkk!N%l|cRTBGs`yzy z7GbD4vA5-Lu~nFEg*|5cHeV7&^+4hyzYGH{nQ-YrHM?Tcg9PQI+BvN>j`$jo3V?dD z1F=EEBRrpDPDP}2&p)s{xqU6eazHvFDoI1t;H1j391|XdJ=r+@5#q!}#NX`~BwBan zeZvaJBknJX;&+5eKG@!btFC>~HGjn) z^j?cDW|E}QV(z6{^|57aX`OZMWlQBzeQYTc*4)dgdRbfYn*{T3CvFx6Vqw2e5oC%d zO3E2DOCy!KZ&;A4-s2A{`?I14HHnOJJbP9VcScjzltp@X$L$NlWy2)59cIun_m6y9 zL%n`JZszU=37UGLq|yU0{R~>&eP8^m=$#D@As&4?-oU! z)nJ0!oIW&1qy{Z!TTLMLZy~0#|Cn3W3~Vpe%YejUv`+xd8zyPbC%NO4G%+))!nY-t zG=aD@u;NxAOEi9Gcl8vIVS${j<_g@3f<4%`eGqqgXAy)Dk>b`V!GYYcT_and(_dZs zMU0GUP``^>zMAod9Bo9OFjt$geAf_f=2jS#`^86GUa+ZTw0wuUuJ|%`{$*Jl02WZ<1{3`eRVcM z&gCaC?lh++!RY)SY-r$761*Uoh)C-b5brUoL}^v<$i;-jQbdbPb6jBqbygP%RK8xm zll7A5naI}Pn7jNCsD|A$gCQDjOr#WDcd7(}#b6&hP|(XI^%Fw!T8C)QqO!j=wS}%T z_5w|#uQXo-K{F?IN^7I1dkswu(pFSQqij~UKoAUZYa6Mvp(=P1V+^m&Ncz`fFWBx9R)R=O2|fiKG?JL$U!@e{O6j;Mtp>$>L3Z zVGXgDB4~CORC-K~oaVlBFYgV3$3Iy`NWDng+Kj^*(0^Vznr3xRi0U8XG>GD^uFIm) z#_P=8AHQf_7~kHm_LHm1N%^Usn|EV+%$?B-tPS^hz-jA_!#HV}ffSv7^7cH1nq!u+ zJWOeIIfsT8I(aLbGlOZ#YX)V0j%Hwe%cWkAL(Y18Z+eST$8e}T=?H*Vp9V@3dh17T z&fr7R4v8X@SM)<3C$GxtioTGl2p_qtVmETION1W~l%uK@6$vz-DA zs80YTo_}nLvWqyqa|UhOMk@8BzvOFRqG}zz&a9HVYD0Jx>pG&J*Bu_IYkkmwlrcs> z&wK7Cphwq~cvE@eWVA!4&eC1{oGTq#XSQSkg%L<8upV2Nn4~o`vU-vof}cX{)mBXY zM=U8em{rI@B&?fTv2b_SSa^ z*rk8*vtN3$%LUi|`bdA&#}7mKEW*RRKC(_a7azfv0TusN$6Otiq~2%tfyM^shIDQ8 zBb;B+oKB+@tDkxp$Qq6aU?L=949x-4s=%1MKPrW?!>4l`ge5z2(1b4;Eje=+Dvw8i zXpdsZ&gT^%KL_#O>HSI`#vmt{I3X*s3N)E)38{n;v*CDOKn943m{~8|prY zb9(mqNm^nbP~xiF4StU7x>8=8sIv`hLwV;yPVbCF>tECcGWs(Pt<)E+7!8q-dJl0+ z5Y6TbqwX?p5v8p&E;a())$2_Gci(3ufEzjU^PX|?zs-i21<1R2+E-X&PYm9N%y>Cc32$|s8&eEdS73teyBRgd62}O zRbHeJ6C0-1e`7<9G&1u2zWvmsb7BoO(5xZ@{OiV|inHM-t6sax1{(d3L&V!g79gX~ z?dV{6X1DPuKJIfbRFvh!KX~g)X;!|D6@FvXE@9m;cMY0%Z zC`wt6ib(zkE_6P71C3`iAHe?Dlz)9-N__{G&$Rq%!1cQq|BFc4XhSY!HkSY-Bqj=F ziO%oyqUt^|Fl=mXU9P3`K>>(fu@78a=}RgO4m68GpvCWisHrjc`xJpzKMTFx1g|84 zj3uxv!w3nb(A8ia170n>o zoIS~*oaEL-R`ZmU%z$L2*yX0|E+WA+uufm?fTC)?p=F0D2E4nXj=E2HTYUdGt6<() zQW-7~c^b^+_f1_xLq$7L=Gsp;atiGk$i&+Vt-30<<#*zrg5nAllOC2)cgRb84#*v) zu>&0D^WqS=x>Kwi*6SwoK6$q0O7NDdpm(im(>)#Oi_UJ6mssu&CAuKLKIXu3nziI) zln@=dS7IcB-5*}q$2gc#1U@_C_Hik=zHW^CQqtAAi_*MfN+3*_|{zq{oC^@=Mf zTs`PwKszc+;-K)nYm-BF!g@a`V)H;w92(bChxw%jvggo@j0%c5kW4#~5l6cU4(mBE zr>Gohi$XDhD(%sVZm-|I?`%GEvu~t;wWF9c4XVnd%l!O9(n}RgP;AMmiA^5AmhP|t z-`9Jk#CvAHd*=9i=7@WxZ=*!oy6kd7{~GyiiRBT?d`DC>ot0Jg#Iuhm)3LOKHK&xH znc5H-=w*1dMn0g>WlFRM;)#M3YVqEKuvkaVq(XRNp0<9i-2aMPxlG*y5L4D5H&SD_q35K{`oC2v$fToW@8R1W#LIt)|S ztF9K3p*tT(i_mUv9`YsBL09+aD0ksYFCu{^j*K_u{t7$>rxk;6KrP=sJ&%6Ru?%S4 zsh^OsJh8l?P{^y!*g*!8k!7=22>y64pM~aWJQD`JE+y2MuCo4(M4vHFhDiNFc(}=N z5)(waI+I9PBnZ9Rx*y9tF>`Tr^|;Qol_ku*6-(UUU z#t2lz%)Ya|1+sWGMeBI+Vh^Ac z%7-y$b?UxrTGx|PMmJ%(!>HN&-nU}i!OxM(LLpIbU(P zPx__8)?%HjHn|3_eSsjp@n#ud`ied<1}xY)p`$l-Tk?D zUXZq8V}WPspl%0x;h7DbL(*7Bv4ivJ;fUNIL`!F6(C3b=gfziw+2w=gO+E)X!`5zb2ai}z14&+-}Cnvu8ZfMcM_T%(5W4k5#XP|b=F)y4;ITI zakm7RWK&+hqXt4 z?ruKlUNYc5lIwGJyA59)|J(L7BjoidQivvOm6Gxc^ueSWrPkeF!&!A@4vG&XcYjW^ zIhvy0fy}M4y3;9brtseQPOQOl>xZ98SZa9)!P3B9IYY_ppKBhnWMx&TUj*Ln1FNyR zx_P<>YKL0|OwRgn#B2hu8UBL+cGG0rKTxw@N5*bQGNE?z%K@u>@jgrx9LQwf1%cJN zvXN|hI3R(JI8Vwyl{+9>W9#oxMIM`S%6;x+4rOg@&S)|B4sQ*QE;vePsw8&-RTVu` z>L`jtD$-=ZoIQ}GHCQt!Q@~&WEgQeR`=xC%mVC5Z1bo572Eo;V4(!&RWiI`?+aI4> zBs!JL>=C|ezRfv!K|R!=@jedfWqV3KCczN}TiR`NxsB9TN7hbo94q|nl^pB%Qg`1V z>X;NBvE)NPElI|UdnRa-waaM3(rCltXanYGgZrL(x|91OH|n?MKXMof1aF2lYrZ=_ zI-9thn>X3p0(zD5qceU5*{Lk5p?TpRY;naL$HVFC5}&ud8&`LB*oBJ4e$37&F6f5( z#j$Z|5GaC5;~N>>^HD4}ibzWbYZz|HDUQ&S00S*se3q}V!LkM-;cn^QHszNWfIdD@ zVNO-?v*aY={a%t7?1!6XafMHwfr*1_M(`qp11)S$Kvqi>3xC{0?SlY+bJp{BTEUYePu8XS&fig=%}I zo%B@0#;803CX&ZU_1BTw5vx_k+-P}!WtqNNm=~m02PIrqm!&KY(zM7XuTH}o!nnh^Z|9^u5i6+3bs ziD8LO_#Xns04S;0&pTSFuxErn-@A<$P+0160)1zi3&DrWk!@Laaz{QD8*u|jkG@d; zheYEl@c*4eGtweYbOfIqM?G5|3GqjO2#EC#(|?8bCnOfZGCYVK7f|K|emZ8iYF{+` zOp%v^eh&v^qU#0ecFPkVE(WD7tTXQN3ADDfr$1SB$}})T(|@7iT>V(;&|j;}>~pBO ztD_)k4f37C$TDoy7j4afS<>PPKzA6hErIoYR@aSs17uv4JY$3!=SaQ2SGb+n{=#CYc_p(n{nhfvDZ2`OPO|Wn++U2gf>G8DC^&YLBtMbK=llf;|K!7AR zRZ|&j7AjBml!MC^-4$+2R?s{#&OL`@Q-S&j`2XPeCUQP3O$bj)O`4s( zK1l>uHNMzyS~|FiSx)U#O`vMlYJ#9!-(y%0O|pgs{7bfGO17@~AGYL-%o{Fl2c$lC z6SdEK;CVg}5(1xE^n6eq8X18Og2xYxK}KTH50RUKz{$(*p z(=g(y6}87MMYI=Gd=SVS97*JM!Bb|6sTapD(BR0Y7^cY=1Et}^R zT)KQj`NI=b@)-%#>Vy;&#S#o_u$&=9ZI9XJ#G#nI(v)qYGbwhg!kL^Wl#>&1$&q2Jzma{S}-C}4fW z(36Y|4RvWawy!#UKp^1ZMN*k9DPT*n3LsLM7hSd%hK=jb;ozPc@h9bs+0ApT&e0DR zdB6J#;idYHG1ufMKtj^3o6)ad8r~`Ox~GzkH^fhTlneRoWEbS6_Yp%)!sBv9(I1Eu z%H;O2x!4jqI4CqtRqDeb6Hz40+Vm;kCdn~ZoJzJ=jC^-xiFZZ)H?#HYUVT!8vgAPX z0nOE8y|0J9k}lL3!*gfS$7S27?Ia&SIx`6a%U*E-nX4btPiea`N(~Uy0c)exMud( z`g{tV2Q;;{wS&jW^0I1Oxi}4A5y?1waMDuuf`svD`%gQpKF~gIG6T3UL1>QLw&@UjXa zLH(uAZ?$R9H=WSW?Fzs2Sn+?yh;WnUi+)B4|14uH8W+lgUgq1M_4RyO5zh1eM~=pG zK+_bwzSsgg#%PCkBc1ZWUVHa$F!Ti3d<9A?_0(UF&6P9bX zEw6|_HERf{6u0{3^hjgu6b8YnM)pAUWo_BU^e51WOMMSneiSA5Ia$K#hGzt-7fLk3 z1ls*k_iIdgte&L@LKA0J&x|QZZpjv%({*wSn1sCR)CJBa7T*--t`?O5D5S8t z=qNPqN?K{VUcz#}Tk`pLn(f0^?=NTC3}GE@UA8#gJw1~Z+B{E}BeZ}K4a|&8BZj<6 zkd|c70I#L!`z|qPg%j4qtkuiXjyA1R)z0f~xu{G%PFDd>%UG4rU>NI|{R>7%1jE27 zkgm#=C=SKm*7fm=O2P~M+=~kmBDPVEI<6%IDri0yT*SoS0qCAr6==)%H6gu8AA?Cd z3!EvC&18?N!%n_Z?CycUHIS-@Y>003L>pEy@MopSfM=hg1-%53dm7Uks03pg{Zv0;Y*osP5znvqo0R zxIis9EW}WkuG5(L$|Ysgp1SJZ8n82>ua1E-j52%DvRu!v&%J}(Jg!&cU}PQDVoX~& zl>!mqt^Ok)XUgy%w)O+|dAII<1xq5877S=OrF$@u&4fn+1aQ*4s=(|f zx2x-oj{4M3kzPSe%1}xw6zW>5_ji?*4FO90I7q`TJJSDfFIW4OURT0T^;Yccs#j2c zTy5_KDo>B)KXQll9(uZ4;IqF^)e}ejX_}hrIj9hRR_cSTjK^!B1L{EoOa23l;Y)N% zEC>h@$fCLF;uK6q45oyHo6gv*iQsyZABWS~*30(3b7k|VTIh=~1pLHz?GbHTvYHMp z;XD6{bZ0}o#e7U9Bw&_mP5r{dVU{)u)wtjcU=RycfH?)6oEJz4ZxqRM_#(?9P#_3U zs(8bmX`-LB1kYCVlXlio+B`!O!XYS9uT$Q49u1*t(2gNehT6x-u?@7(AXn1G^?6d+ zin7t#O>_)LFvX-Vn!(B0kAozfiw@5Z>l`+45?fDCk9;jJ(}`(Kg~@NlYLkTOTyX)h>|R$eDG!_;px0mW@^Esn5?`0sblrt%R&Wi*d7eC4Y47XzRbEhmcyQi5R3)-|{bt=ch#_^=__Gk+ zw>xi5*2vEo)(qxPx}g zb!-|YLcOf9|H?d0C3^dotuEsdlaNFLo_`daoY+7zC@Zu2RuI(~?`f{P!`YL(2&n$# zS)lUBzAy9A@`AikZc;q*s9D%7cFj)qMc-B%r86fsr$T4=wQ}*UDy90K2QuzlL%SMA z9Ja#mY)W9!M`3eATS5Dw{nfQY*q-*x>L4pdOm1*p6S7RG2L0K4>m*(_-Lz2HTn6^U zu#^g9ma99xat5Dz2G6Lk@Qc6#@&|ervO;{K$Xf%QSB(gEgyFHX7_@p@g!#%n=_Rf` zKVHSX#T>36k;Yi+K7?sd1aF)Yed1WX9Me3%NZ^8rkK~1Fk7h18-#R8b89VQL@1UiF ztt+GN5l`3lE8SvJpd%sF8zqzYPv{6x1_#*~;1d%^WOzN`H8>qf+}~alF~ig)Y_9Bn z@`_p|_IJ%C_KBv~4Ckskq1}UCvvl&!@aTK#piIA}Y|FJr&EWyLqAY8HQZEI_On6HO zoTsu82_RY~%sgx?s`%|u*(>=CI*GwY$H%}%H$Ok$yzI0n_$GIdwwv7V=s(UCkRG!b ziqDb2EW)qtc1jLdNQ;S{VRY1-4ygC)zPR1^I8nr(&i-ni=IjP*wW~|WmT?gl**&Fo zER*fFet}TZ_t&GmitwKN+BiEqi_7oK(rFg=a5f_JiklV&dTbT`?vzE@p8f=meExdl zc<@0JOY3K~C`y?Ea|c+T>4goF%C-O5d6Wyl=V7k%C4ZAV35Es1YS=)Y&Sf;ZQI%kj zZ5`_%AzTKggyUJk9*UWBE;GI?W6=1XC++1CSW28w?r8g|B>H(4;u6ubXC%zhV#2CA z+OK>1PF1D4E}7hGak5kRT9?AD3yhCK(dS8|9WNPMDDy|?w7;&Pa7GaNIB*T95KuWp z!-|?_FfiJ==&GEjs*&Fr3uf$de|eK%?len!%|R47k-XUzvhjOE0-2C1lCv;!BXoCl z!8AA?`1<$=n~a_b>_+`Tr|8GATyDn#<{Fxe%h;lhOC9xxU4eo;Im_JM7d^yMF3FQ3 z6rAGoR`-zmvUEom_D2M0Q~Ix-_gZ?L9!h^x@5RfuJ$jimK83N1cXaY2>AWKeqZS2r zf|-?o9~0Z1@l?%A2kB2ES|*hW(`R3UB{CS=KOZ2Dy}ICd@YMVal_~Q&3;{q3 zAV9g&jrw@FNKsW4Yp%vJ(0n4#aBDDm<%I5p))2;fJqFeAtv|b~y`8I>lfrM{itdTr zv@-7rkNx-pv5z(63(a?4Qx5#e`i+fwxVw!g{yuY>#>a-_#*taPjFIMPB=S%UV^WVEf9enWz^vXjx?Y za_u(RrGG-X|`a^AH43%^8X1B-+DH(*byk<{3!uyCGJ zKidW$+$pe9V=6xQUu+h~t!>;YN z;)4(8HA3NwJuyp{I9gX9j0Q{z8)C_b8sds7lV0vsof04Qa0$F=ZBUXuPjkYcifE3{ z4-IoG+*2N%2_zBvWa1~}t&nZH!|zB#T($Vaqna3EuvvYF>pf9I_$>l~ z4bJmU(hanA06%<`|s~|Se;xZ z6id@@;1>GfL?SSC*0(rHyR@p)`wv#f*Vi5aIbFge|2J52@os;RJk$>B>HO{n-`wKPeQu!9-h4^jTg{t}Jg@_U}uqMnhf-h>S`*I z7bYH=Y!%p4z^@mP!M77kA7OOA(3-xw@`>P_vACg-kDh&B9n~SHmq7*YW3;kqdzFIL zw&>}a5}LF!f@i^Fm#wgk-5#4CdhSNIM_#J5FvG>VwNDW60rQc&OSj%WV7^Asw}IY3 z;Zw1o*3!1$3idaa)>HtP2R7VnFgY1(lbU_emAKmwFgw+3p}E6Voz0M}GXvX}5-)Vx zy}#GZnWDY0)LKH1EA(aqaI2#Ab1^Zo4=Q%?Fn0#s&4n>^v=ZYRt`}Bm(_1Y8NM)}G z^ZV(Qbt0S-k5CZU3pglC)V9$WJ_`R3f*Lfn6m7C!iks%N3kVFRF19@RP(_O(Ko54- z1kKlDUk5mTxH^vu8*WUw{&kSbxH^eJ&Z$rMq1wLYFtIEKB8J#KIC}jYm?(X!o9Seb zLTTQq{%}E_*GRh(uU9Sa2_Bk~;U>|^{)?$drxd7!!@yS#S!MbVq;!zK60fdnPuv74 zG_nUh?>u`yK>7wWQH7`N%-NmG%UN!57=Bv-*KyAreXQt7a=Jx13Cs&7cB16snbCoT z5Ol^C(B*gvZXXKk&|ohEArNkd1C&J(Nv%xsHfXCAIoWwU5{{?!tRihbm7zNM(A))` z{-#vAz}52W<}9ncPHdN{)8P)d_r8HzAbkirKIvuzN=c+VJCmwnYFxlPnTU8BV4qo zk!0I-tIcu1PzT7&!8*L}?G~%n;4uGZGBw>f`%$sN);hyuoin>nlbpDGE?%?f=%GSpJQ+$fGiYJ-7ZYq*h_+ ztglKqaaADdW}fBz_S)@dd|niX$#1agLnr0EoGpp^6A0>$jw))DtH8XJ0<Lgn|sFXWK4$BIVamzMkQtj~XSzb!n07B8i-;fqc%PZ55EPy;$e7TN%HJDG5?e}(c{*KF}D!7NSA_j^?rlmBw1C%ZY~aA zVF|i%#9JdJI_2>Y`$4*T-50t`>bY%#Tx!K&O;*7>Bo-N25w<%f)foS>=s0D^JA|T_ zm#HtWOF3FJ#ph|ZZ?GiZ-e0*X3H{_Pm1GiTNr@8s6Hh55fp`c)rzp%&v#69RGk?~Y zuG4lw-ot&IrcKtn3hB7-$}sy(9JeFSKs=d(rMJc&DES*xs)CqL>Rp3ZfA3zk8hx#9 zv+&~Ql~m)s67gXvUPu`UO8aB2P1g~H{@d;q6L6`sWzPENXaL@W5eJ=3<2SrJyHWh+R*z>FS6Z9 zZL0>gW9^L4q#ZZsp=O%#e^D<(@gb+`#_HzPGq%AtN3+f2hN&QHrYoV6gRRjmSnC(NKSH6zZ-iO$-HQAzmE=}#p)k&$ z$bAfErY#!}%39S$mIuBrsIzbKTV3^M!?iu;=vOl&#DcF^ciCZV{nQOz74e2+$1Xd# zQcT<5nV{+H-L!u*B;vk7>OOM%7=3fZ?>~fT&>ryecx*!0ucE~$pbf#DjUD4_9YEGx zASyldN%CMKlI-U6FDioLWvJ5wTNW4|Yr0$C!0~ePRp2bkYpUBP_6)KI1=$OiDWb;v zS@2x%0GS6&h_46C`d=E|#_3JWcuS8UJs5Sb-QAFP@7fItbD>81wq?>!-iUbzxZzSe zH2ASDA+H>5hjYsMm@d6nw+hkEVP@KWrU8e_VZ9o8+q_I+xq)D_4?gIE2}RRFzSESX+QV(=s}0IoWaKVGR3&%?o%uDbOidCn;xziJoR|}z+DE%8 zi0f|5Cgy_`60~*lsZ5JWJ~g^Dm)F>d&oogV+Zj#Nh6>6kTlXeX9{_lgp(ROmTKNS- zK|bL@?3KGrGvQj(fM|NUedO+^)gbO(hy>k6vNUNz%*Oz#OKSI(YYP^a>qcTfC5FhvQNQNmUqr%*W{OxxhP2U4{ z<%r;pq9G5o>K2?~t6fA{d{#!uX-e${!7`v$O9t)Z9EqD!{4A%eR_NNkNKV(^c*y&_ z8651js8~Y3?Xt=&%XK8Tb>B?2XjSyeSiLoI5$bA&v=xKGvqPz<{`=5k!5pLm-K2oT zNPS`BzI}EKW-CTZ<#@c5te6LkNc|H7m3i1(gf*|tYE@mF&5cCPL}$v3@YZeO&dmC= z(G`12>bk^DKTw;Uy7onXs(ymUX@&yRgV)Yh1*|X*IjeA&?rr~RgraGc^iv{D?Q<*O zoQ#f#7kqQJtzphLnd>eigCO#qHEsumLOQ*nG9)P zVWRTpp#TI_iGjeaxZxDhm53&MI!^);sq7F4axWk@`PQ;`V_$3*x?Z`MzT@+BoSI1C zDAj`AsA>6f<^Qe1?Su)7>CrtfhI&B|KeTztB*{j9>Z^)d*#@yOfvd};Xo|qmqbo8)a6)C;lE@hgO|h#v-4*7~01nn(0274$Is6@Qj1ZuuP_dpIaGYtE+ z-5p6%hJk^JiRu1uvrQMDD+08JmKr$hOm<`0eIW!s#i2q-N=m-7P!H8eKZOue{-&6GcQy*$U3h<%uNn_y26_cOm`W*Q5JbNUs3V zz<2YtjKirsDu7H(_TM`dgaXvxJ#y)fK_Dusa?>GvATR32`B0GaKvq-8v#2*|TQQ`df;biS$%}3B?bT9n$eZoM7qM8t}TF@AQ|_?MgxyGD0XQD2R!R zOG~`IyE=*t3k$Qbq{sVH5-J8#14gb;CZZqRhYqw7Df9pWgnJFm&9z{vsa^oC=v08J zuQw5&7+_y!Xp$p|KgY{ecFmy}9dUAyMHBpij9MXGXKYH@1NgQ8 zv@)R})CJgu{7NuB+#S(LWs*N#_B4eH1%U}v)Qs8(Nq&st1CZ{?SXt4n=WD6hfd5cM zhiq!pr2E42kEaSq02p62RLK|-Xn;@A6^b)4H!ib|40t!vDzvt@ zLjvJ-pX+ycCpfZe7y19MgRq`D2umS0?UipUP-gI9cbp2CQrQyUWhF3t_9TE3Vkksx zhSuwob*i?n&RFq(N!LD~K|p2n=M|I6if%Ntj7V;q1@7aU$!g26iM~+_=}fbc^zQ(5 zz*zezk$s4o9x|8lIApa%D72^m-#!p)gq77#6)?7Mfo`09f>2 z;=MXpZV_T*W3%8yt4#mXJFlL4r^c-h{8`Lkvp*hJ(4D(eQc+6bZ}sr_`+>$n3!Y@i zU0C35G8lkcO=koVAEl&FaAaJa*JE=G)c_emVgO%$#EJ#K21@&8aE_o9F;V@mm!yCR z=)n@EbV@!84xjULRVy8Wh=HEkj-hTOPADhxCT?^ka+Hz%NbzW%uA|<^H&Y)^bH{ao zQH!H&T|Z&5T@z!_s)TN9YYPerQmo7=oaJs5Y(iT1tn+uegvA!g=|Sri--z0p{F;8#w}Ay-|^)d{)rv z`p!kY$jmCPa(lUEEi`kcQe9G&>vK)I5G+Vpf{C~>K}!}{-+X(&DTjAm_8q=%U#Y) ztIa21Yin!SEY>;l(i}l-9}&fQ#u)9@T}}+LRK2fx+kgWdx5Z~P@&c)X#tiqhEI8H zgkp)ops(;jGtmGr!_LaeigCyX>}+4Exdf%ZU5_G$AK4F8gF`V|L=)sZCk~oI6(22F ze4#R{)ywV*7U|(bI_t7_ADh`RNPMhsrCJ{y=DRjn<+RF}Kue@nXzk8tC|8|41b8k2 zRXB(}%v}SQ>=ia0Z0^(FvGFV3l>g9~Yq&Lg3>9b*3Jj=8u<%GE*OieB{rH<00D?gu zEzWc;zz3#uzt6KCTQm~%D!Xm@y78K!)K$YT&wpt1FSyg>|0~CDbx<-oaAplVyXnkg zUl0h3vhTrR$_LBT92|x0_0}7T?K<3=C8(4u zp)Q=amK|LkkaN>Dtz6Z9eDipkWuU?hK1ScQXc3q+`Ip4)4gp2y0IME|QYn6AE3S(zir^sshB0p48%8%yNjtNml0f>*YBC5G_ z0wd7K_`I^d<6P2EHjJOij#@&UKOUi7>VbWs&}Y!yb}?c;*Mgwx^wS0o8{)=u`<;`p zsGc^fNy4Y~pHM$GcPgs2{S)Go^)H)N-i!hKbecylGeN`P6_poX5^3yKkc`3z0pN4)#(&l?y%&P`(mzxQ&Rs;Tvrd9?F?N?zfCp;E{lwk>y)mk(ukqE0M0LRIf4|VI{87qc zidrlA6ajhV#Sx22!LD*lBC*~Kkic{M)an)qZnAR+cz%|v`#X~9jx|qH|NPL80P%p` z#c4~gSG3?zV5wTS_hC zz^X73Im-+7#K%>hI7|@zXyD9xBvxG&CJT0V>A8lv-Dd_ak8@19lXo; z{2_^`o}$aH5rDe8x1XKtU{j}_UCsURP+l^NHXd}MYxA+SCY-#W-^m>j)$)g_z#vL= zAAHIG-05@X%chVpHN1k0>mH7e%@GtbUIr0VBTV=qYzaJjD!{DSB-vTn_n#|GD=#+a zvEIc{dw=Cl1AT2yK3vEsSk5Urk4kh*H-p2tFgse{YU*{MSU$zzxXLTr?{pu5+9uGBpv4` z1>}%ec;Kgu(WGQ$JEF)$GXZbT*)|P*{TAcl#u?`aZensoGw$R<%P$_{wQk}b8sdA( z7|goBc`4HsjobN{l$?U%N&jZgP!X?0N?JOaP=ortX+)t~@1izHElU-!wg#vRG$xpml=kFn$B+FO=NKC@2yDj;@=QZ2t$*etJT*S&}Bft!|{{R!bj&Cn4_h+jlD;>jr z0YZRY6cG_|eRtGCCD|7=14~6iL;oi3^e>&K01a4W)ZtAF{oxA&Tl?ebS?zZe0sru? zlB7@aEt%bDqhn*yR{mJ{_#uGokWSsl-0tu40e_Oon=}BN-n>FLmx88*uB@yqH|&7z zg4bY O_>&fw7b_Jp@ckbyu=>RS literal 0 HcmV?d00001 diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index 5b10afec1..be8d4fb98 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -154,8 +154,24 @@ for (bb, block) in body.basic_blocks().iter_enumerated() { } ``` +### Graphviz Diagrams + +When the results of a dataflow analysis are not what you expect, it often helps +to visualize them. This can be done with the `-Zdump-mir` flags described in +[Debugging MIR]. Start with `-Zdump-mir=F -Zdump-mir-dataflow`, where `F` is +either "all" or the name of the MIR body you are interested in. + +These `.dot` files will be saved in your `mir_dump` directory and will have the +`NAME` of the analysis (e.g. `maybe_inits`) as part of their filename. Each +visualization will display the full dataflow state at entry and exit of each +block, as well as any changes that occur in each statement and terminator. See +the example below: + +![A graphviz diagram for a dataflow analysis](../img/dataflow-graphviz-example.png) + ["gen-kill" problems]: https://en.wikipedia.org/wiki/Data-flow_analysis#Bit_vector_problems [*Static Program Analysis*]: https://cs.au.dk/~amoeller/spa/ +[Debugging MIR]: ./debugging.html [`AnalysisDomain`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.AnalysisDomain.html [`Analysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.Analysis.html [`Engine`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/struct.Engine.html diff --git a/src/mir/debugging.md b/src/mir/debugging.md index edb68ca72..3a47a575d 100644 --- a/src/mir/debugging.md +++ b/src/mir/debugging.md @@ -6,6 +6,8 @@ additional output formats, including: * `-Zdump-mir-graphviz` - dumps a `.dot` file that represents MIR as a control-flow graph +* `-Zdump-mir-dataflow` - dumps a `.dot` file showing the [dataflow state] at + each point in the control-flow graph * `-Zdump-mir-spanview` - dumps an `.html` file that highlights the source spans associated with MIR elements (including mouse-over actions to reveal elements obscured by overlaps, and tooltips to view the MIR statements). @@ -87,3 +89,5 @@ rustc.main.002-006.NoLandingPads.before.mir that appeared within the `main` function.) TODO: anything else? + +[dataflow state]: ./dataflow.html#graphviz-diagrams From be58aab8809ea9642220ad3a5c2ecb0131465f38 Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Tue, 15 Sep 2020 21:18:37 -0700 Subject: [PATCH 1243/1812] Add link for `AnalysisDomain::NAME` --- src/mir/dataflow.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index be8d4fb98..bc65ecfa2 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -162,7 +162,7 @@ to visualize them. This can be done with the `-Zdump-mir` flags described in either "all" or the name of the MIR body you are interested in. These `.dot` files will be saved in your `mir_dump` directory and will have the -`NAME` of the analysis (e.g. `maybe_inits`) as part of their filename. Each +[`NAME`] of the analysis (e.g. `maybe_inits`) as part of their filename. Each visualization will display the full dataflow state at entry and exit of each block, as well as any changes that occur in each statement and terminator. See the example below: @@ -177,6 +177,7 @@ the example below: [`Engine`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/struct.Engine.html [`GenKillAnalysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.GenKillAnalysis.html [`JoinSemiLattice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/lattice/trait.JoinSemiLattice.html +[`NAME`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.AnalysisDomain.html#associatedconstant.NAME [`ResultsCursor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/struct.ResultsCursor.html [`ResultsVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.ResultsVisitor.html [`apply_call_return_effect`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.Analysis.html#tymethod.apply_call_return_effect From ed59c2d47de60f9b009144990a4bceb7db53fc18 Mon Sep 17 00:00:00 2001 From: Macdonald Umoren Date: Wed, 16 Sep 2020 20:50:33 -0400 Subject: [PATCH 1244/1812] debug-logging=true instead of debug-assertions=yes --- src/compiler-debugging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 9c69b1511..e4b04aa96 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -207,10 +207,10 @@ $ RUSTDOC_LOG=rustdoc rustdoc +local my-file.rs While calls to `error!`, `warn!` and `info!` are included in every build of the compiler, calls to `debug!` and `trace!` are only included in the program if -`debug-assertions=yes` is turned on in config.toml (it is +`debug-logging=true` is turned on in config.toml (it is turned off by default), so if you don't see `DEBUG` logs, especially if you run the compiler with `RUSTC_LOG=rustc rustc some.rs` and only see -`INFO` logs, make sure that `debug-assertions=yes` is turned on in your +`INFO` logs, make sure that `debug-logging=true` is turned on in your config.toml. In some cases, just setting it will not trigger a rebuild, From 7ca5568bae5c17d06ac8118cd3e58e0a9e9db39c Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 16:38:26 -0700 Subject: [PATCH 1245/1812] Improve MIR sections in appendix Add a new graphical representation of one of the examples of MIR and basic blocks! And make other minor improvements. --- src/appendix/background.md | 81 +++++++++++++++++++++++++------------- 1 file changed, 54 insertions(+), 27 deletions(-) diff --git a/src/appendix/background.md b/src/appendix/background.md index e7b9f3afc..07515aeab 100644 --- a/src/appendix/background.md +++ b/src/appendix/background.md @@ -8,10 +8,10 @@ Rust-specific context. ## What is a control-flow graph? -A control-flow graph is a common term from compilers. If you've ever +A control-flow graph (CFG) is a common term from compilers. If you've ever used a flow-chart, then the concept of a control-flow graph will be pretty familiar to you. It's a representation of your program that -exposes the underlying control flow in a very clear way. +clearly exposes the underlying control flow. A control-flow graph is structured as a set of **basic blocks** connected by edges. The key idea of a basic block is that it is a set @@ -44,12 +44,17 @@ if some_variable { d = 1; ``` -This would compile into four basic blocks: +This would compile into four basic blocks in MIR. In textual form, it looks like +this: ```mir BB0: { a = 1; - if some_variable { goto BB1 } else { goto BB2 } + if some_variable { + goto BB1; + } else { + goto BB2; + } } BB1: { @@ -64,10 +69,33 @@ BB2: { BB3: { d = 1; - ...; + ... } ``` +In graphical form, it looks like this: + +``` + BB0 + +--------------------+ + | a = 1; | + +--------------------+ + / \ + if some_variable else + / \ + BB1 / \ BB2 + +-----------+ +-----------+ + | b = 1; | | c = 1; | + +-----------+ +-----------+ + \ / + \ / + \ BB3 / + +----------+ + | d = 1; | + | ... | + +----------+ +``` + When using a control-flow graph, a loop simply appears as a cycle in the graph, and the `break` keyword translates into a path out of that cycle. @@ -82,10 +110,10 @@ and Michael I. Schwartzbach is an incredible resource! _Dataflow analysis_ is a type of static analysis that is common in many compilers. It describes a general technique, rather than a particular analysis. -The basic idea is that we can walk over a [CFG](#cfg) and keep track of what -some value could be. At the end of the walk, we might have shown that some -claim is true or not necessarily true (e.g. "this variable must be -initialized"). `rustc` tends to do dataflow analyses over the MIR, since that +The basic idea is that we can walk over a [control-flow graph (CFG)](#cfg) and +keep track of what some value could be. At the end of the walk, we might have +shown that some claim is true or not necessarily true (e.g. "this variable must +be initialized"). `rustc` tends to do dataflow analyses over the MIR, since MIR is already a CFG. For example, suppose we want to check that `x` is initialized before it is used @@ -207,17 +235,17 @@ such that the function is well-typed: `∃ T: (T: Debug) and well_typed(foo)`. -## What is a DeBruijn Index? +## What is a de Bruijn Index? -DeBruijn indices are a way of representing which variables are bound in -which binders using only integers. They were [originally invented][wikideb] for -use in lambda calculus evaluation. In `rustc`, we use a similar idea for the -[representation of generic types][sub]. +[De Bruijn indices][wikideb] are a way of representing using only integers which +variables are bound in which binders. They were originally invented for use in +lambda calculus evaluation (see [this Wikipedia article][wikideb] for more). In +`rustc`, we use a similar idea for the [representation of generic types][sub]. [wikideb]: https://en.wikipedia.org/wiki/De_Bruijn_index [sub]: ../generics.md -Here is a basic example of how DeBruijn indices might be used for closures (we +Here is a basic example of how de Bruijn indices might be used for closures (we don't actually do this in `rustc` though): ```rust,ignore @@ -231,7 +259,7 @@ don't actually do this in `rustc` though): } ``` -## What is co- and contra-variance? +## What are co- and contra-variance? Check out the subtyping chapter from the [Rust Nomicon](https://doc.rust-lang.org/nomicon/subtyping.html). @@ -246,17 +274,16 @@ the type checker handles variance. Let's describe the concepts of free vs bound in terms of program variables, since that's the thing we're most familiar with. -- Consider this expression, which creates a closure: `|a, - b| a + b`. Here, the `a` and `b` in `a + b` refer to the arguments - that the closure will be given when it is called. We say that the - `a` and `b` there are **bound** to the closure, and that the closure - signature `|a, b|` is a **binder** for the names `a` and `b` - (because any references to `a` or `b` within refer to the variables - that it introduces). -- Consider this expression: `a + b`. In this expression, `a` and `b` - refer to local variables that are defined *outside* of the - expression. We say that those variables **appear free** in the - expression (i.e., they are **free**, not **bound** (tied up)). +- Consider this expression, which creates a closure: `|a, b| a + b`. + Here, the `a` and `b` in `a + b` refer to the arguments that the closure will + be given when it is called. We say that the `a` and `b` there are **bound** to + the closure, and that the closure signature `|a, b|` is a **binder** for the + names `a` and `b` (because any references to `a` or `b` within refer to the + variables that it introduces). +- Consider this expression: `a + b`. In this expression, `a` and `b` refer to + local variables that are defined *outside* of the expression. We say that + those variables **appear free** in the expression (i.e., they are **free**, + not **bound** (tied up)). So there you have it: a variable "appears free" in some expression/statement/whatever if it refers to something defined From deb671073486ea0e46039a041c26f0fe1c62ebd6 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 16:41:25 -0700 Subject: [PATCH 1246/1812] More improvements --- src/appendix/background.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/appendix/background.md b/src/appendix/background.md index 07515aeab..ae6136dd5 100644 --- a/src/appendix/background.md +++ b/src/appendix/background.md @@ -237,16 +237,16 @@ such that the function is well-typed: `∃ T: (T: Debug) and well_typed(foo)`. ## What is a de Bruijn Index? -[De Bruijn indices][wikideb] are a way of representing using only integers which -variables are bound in which binders. They were originally invented for use in -lambda calculus evaluation (see [this Wikipedia article][wikideb] for more). In -`rustc`, we use a similar idea for the [representation of generic types][sub]. +[De Bruijn indices][wikideb] are a way of representing, using only integers, +which variables are bound in which binders. They were originally invented for +use in lambda calculus evaluation (see [this Wikipedia article][wikideb] for +more). In `rustc`, we use de Bruijn indices to [represent generic types][sub]. [wikideb]: https://en.wikipedia.org/wiki/De_Bruijn_index [sub]: ../generics.md Here is a basic example of how de Bruijn indices might be used for closures (we -don't actually do this in `rustc` though): +don't actually do this in `rustc` though!): ```rust,ignore |x| { From c758b595b023f06fa08e19ddab655799f60f9c71 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 18:56:22 -0700 Subject: [PATCH 1247/1812] Mention that places are sometimes called "lvalues" --- src/mir/index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mir/index.md b/src/mir/index.md index f771fa0ed..fd55046ec 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -44,7 +44,8 @@ This section introduces the key concepts of MIR, summarized here: leading underscore, like `_1`. There is also a special "local" (`_0`) allocated to store the return value. - **Places:** expressions that identify a location in memory, like `_1` or - `_1.f`. + `_1.f`. (Some people call these "lvalues"; the "l" meaning that they occur on + the left-hand side of an assignment.) - **Rvalues:** expressions that produce a value. The "R" stands for the fact that these are the "right-hand side" of an assignment. - **Operands:** the arguments to an rvalue, which can either be a From f6ba69175bab92d1349a656ba209c307ec5f7f07 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 19:13:44 -0700 Subject: [PATCH 1248/1812] Revert "Mention that places are sometimes called "lvalues"" This reverts commit bf5e1c451de505fa453672c1168b09db07a145cb. --- src/mir/index.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/mir/index.md b/src/mir/index.md index fd55046ec..f771fa0ed 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -44,8 +44,7 @@ This section introduces the key concepts of MIR, summarized here: leading underscore, like `_1`. There is also a special "local" (`_0`) allocated to store the return value. - **Places:** expressions that identify a location in memory, like `_1` or - `_1.f`. (Some people call these "lvalues"; the "l" meaning that they occur on - the left-hand side of an assignment.) + `_1.f`. - **Rvalues:** expressions that produce a value. The "R" stands for the fact that these are the "right-hand side" of an assignment. - **Operands:** the arguments to an rvalue, which can either be a From 1a547f756876cc9371749f36c3e68c843b393c5d Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 14 Sep 2020 20:18:28 -0700 Subject: [PATCH 1249/1812] Fix typo in table of contents --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 8915541cd..5bd038780 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -145,7 +145,7 @@ - [Implicit Caller Location](./backend/implicit-caller-location.md) - [Profile-guided Optimization](./profile-guided-optimization.md) - [Sanitizers Support](./sanitizers.md) -- [Debugging Support in Rust Compiler](./debugging-support-in-rustc.md) +- [Debugging Support in the Rust Compiler](./debugging-support-in-rustc.md) --- From 447064120f284b3cf07829f8dfa332ced70f7bd5 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sat, 19 Sep 2020 19:40:17 -0400 Subject: [PATCH 1250/1812] Improve instructions for adding a new test (#881) * Improve instructions for adding a new test - Add a section for library tests - Expand section on rustdoc tests * Address review comments - Say what should be considered a library test - Mention adding error numbers to doc tests - Link to #ui section - Line wrapping * Fix incorrect link It shouldn't have been a link in the first place. Co-authored-by: Yuki Okushi Co-authored-by: Yuki Okushi --- src/tests/adding.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index c88d5e81d..acdc2fd25 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -29,15 +29,25 @@ rough heuristics: - need to run gdb or lldb? use the `debuginfo` test suite - need to inspect LLVM IR or MIR IR? use the `codegen` or `mir-opt` test suites - - need to run rustdoc? Prefer a `rustdoc` test + - need to run rustdoc? Prefer a `rustdoc` or `rustdoc-ui` test. + Occasionally you'll need `rustdoc-js` as well. - need to inspect the resulting binary in some way? Then use `run-make` -- For most other things, [a `ui` (or `ui-fulldeps`) test](#ui) is to be - preferred: - - `ui` tests subsume both run-pass, compile-fail, and parse-fail tests +- Library tests should go in `library/${crate}/tests` (where `${crate}` is + usually `core`, `alloc`, or `std`). Library tests include: + - tests that an API behaves properly, including accepting various types or + having some runtime behavior + - tests where any compiler warnings are not relevant to the test + - tests that a use of an API gives a compile error, where the exact error + message is not relevant to the test. These should have an + [error number] (`E0XXX`) in the code block to make sure it's the correct error. +- For most other things, [a `ui` (or `ui-fulldeps`) test](#ui) is to be preferred: + - [`ui`](#ui) tests subsume both `run-pass`, `compile-fail`, and `parse-fail` tests - in the case of warnings or errors, `ui` tests capture the full output, which makes it easier to review but also helps prevent "hidden" regressions in the output +[error number]: https://doc.rust-lang.org/rustdoc/unstable-features.html#error-numbers-for-compile-fail-doctests + ## Naming your test We have not traditionally had a lot of structure in the names of From 2a09b06365bdd2785e87d57d53a33ee208a2796f Mon Sep 17 00:00:00 2001 From: Camelid <37223377+camelid@users.noreply.github.com> Date: Tue, 22 Sep 2020 13:52:05 -0700 Subject: [PATCH 1251/1812] `ConstEvalResult` is now `EvalToConstValueResult` (#885) Also fixed typo. --- src/const-eval.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/const-eval.md b/src/const-eval.md index 2a5c5d2f9..d21d0ea58 100644 --- a/src/const-eval.md +++ b/src/const-eval.md @@ -28,7 +28,7 @@ in which the constant is evaluated (e.g. the function within which the constant and a [`GlobalId`]. The `GlobalId` is made up of an `Instance` referring to a constant or static or of an `Instance` of a function and an index into the function's `Promoted` table. -Constant evaluation returns a [`ConstEvalResult`] with either the error, or the a +Constant evaluation returns a [`EvalToConstValueResult`] with either the error, or a representation of the constant. `static` initializers are always represented as [`miri`](./miri.html) virtual memory allocations (via [`ConstValue::ByRef`]). Other constants get represented as [`ConstValue::Scalar`] @@ -41,5 +41,5 @@ If you need the value of a constant inside Miri, you need to directly work with [`ConstValue::Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.Scalar [`ConstValue::Slice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.Slice [`ConstValue::ByRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.ByRef -[`ConstEvalResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/error/type.ConstEvalResult.html +[`EvalToConstValueResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/error/type.EvalToConstValueResult.html [`eval_const_to_op`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#method.eval_const_to_op From 22b096ba2f95daff3bee5ac155589c53180cb57b Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 23 Sep 2020 11:46:43 -0400 Subject: [PATCH 1252/1812] Don't recommend building the compiler for running tests on the standard library (#887) Thought of this while reading https://internals.rust-lang.org/t/contributing-changes-to-std/12829/. --- src/tests/running.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index 1043f87a1..5e18b8a95 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -68,19 +68,19 @@ Likewise, you can test a single file by passing its path: ### Run tests on the standard library ```bash -./x.py test library/std +./x.py test --stage 0 library/std ``` ### Run the tidy script and tests on the standard library ```bash -./x.py test tidy library/std +./x.py test --stage 0 tidy library/std ``` ### Run tests on the standard library using a stage 1 compiler ```bash -> ./x.py test library/std +./x.py test library/std ``` By listing which test suites you want to run you avoid having to run From 30d03d013f0d7f61ac8ec205640fc85d73b453e8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?D=C3=A1niel=20Buga?= Date: Wed, 23 Sep 2020 22:29:17 +0200 Subject: [PATCH 1253/1812] Link to the -Zmir-opt-level proposal I was confused about what the different levels mean. This PR adds a paragraph that shortly explains the rationale behind different mir-opt-levels and links to the current proposal where there's some information about them. Let me know if I wrote something unreasonable or incorrect. Co-authored-by: Joshua Nelson --- src/mir/optimizations.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index 3c143d555..65323ed52 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -36,7 +36,7 @@ implemented in its own submodule of the [`rustc_mir::transform`][trans] module. [rop]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.run_optimization_passes.html [`MirPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/trait.MirPass.html -[trans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html +[trans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html Some examples of passes are: - `CleanupNonCodegenStatements`: remove some of the info that is only needed for @@ -47,3 +47,16 @@ You can see the ["Implementors" section of the `MirPass` rustdocs][impl] for mor [impl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/trait.MirPass.html#implementors [constprop]: https://en.wikipedia.org/wiki/Constant_folding#Constant_propagation + +## MIR optimization levels + +MIR optimizations can come in various levels of readiness. Experimental +optimizations may cause miscompilations, or slow down compile times. +These passes are still included in nightly builds to gather feedback and make it easier to modify +the pass. To enable working with slow or otherwise experimental optimization passes, +you can specify the `-Z mir-opt-level` debug flag. You can find the +definitions of the levels in the [compiler MCP]. If you are developing a MIR pass and +want to query whether your optimization pass should run, you can check the +current level using `tcx.sess.opts.debugging_opts.mir_opt_level`. + +[compiler MCP]: https://github.com/rust-lang/compiler-team/issues/319 From d35a4c4bcb8ed5ab3f96c9e72c25b8ab2378828f Mon Sep 17 00:00:00 2001 From: Jakob Degen Date: Thu, 24 Sep 2020 10:44:20 -0400 Subject: [PATCH 1254/1812] Remove reference to copyright notices. Immediately below the section on copyright notices being removed, it is mentioned that a particular thing should be placed below the notices. This seems confusing. --- src/conventions.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index b9001ee0b..582de0364 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -38,8 +38,7 @@ keep things to 80. **Ignoring the line length limit.** Sometimes – in particular for tests – it can be necessary to exempt yourself from this limit. In -that case, you can add a comment towards the top of the file (after -the copyright notice) like so: +that case, you can add a comment towards the top of the file like so: ```rust // ignore-tidy-linelength From 0adf8a36c81ebe1faf65e5a78678989871306d66 Mon Sep 17 00:00:00 2001 From: Youngsuk_Kim Date: Fri, 25 Sep 2020 17:23:37 -0400 Subject: [PATCH 1255/1812] minor punctuation/grammar error fix --- src/closure.md | 6 +++--- src/compiler-src.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/closure.md b/src/closure.md index 3a7a10f5c..665f7734e 100644 --- a/src/closure.md +++ b/src/closure.md @@ -5,7 +5,7 @@ effectively "desugared" into structs that contain the values they use (or references to the values they use) from their creator's stack frame. rustc has the job of figuring out which values a closure uses and how, so it can decide whether to capture a given variable by shared reference, mutable reference, or -by move. rustc also has to figure out which the closure traits ([`Fn`][fn], +by move. rustc also has to figure out which of the closure traits ([`Fn`][fn], [`FnMut`][fn_mut], or [`FnOnce`][fn_once]) a closure is capable of implementing. @@ -120,7 +120,7 @@ for this purpose. [upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/queries/struct.upvars_mentioned.html -Other than lazy invocation, one other thing that the distinguishes a closure from a +Other than lazy invocation, one other thing that distinguishes a closure from a normal function is that it can use the upvars. It borrows these upvars from its surrounding context; therefore the compiler has to determine the upvar's borrow type. The compiler starts with assigning an immutable borrow type and lowers the restriction (that is, changes it from @@ -189,7 +189,7 @@ can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be [mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html `Delegate` defines a few different methods (the different callbacks): -**consume**: for *move* of a variable, **borrow** for a *borrow* of some kind +**consume** for *move* of a variable, **borrow** for a *borrow* of some kind (shared or mutable), and **mutate** when we see an *assignment* of something. All of these callbacks have a common argument *cmt* which stands for Category, diff --git a/src/compiler-src.md b/src/compiler-src.md index 843000a07..5183a7c85 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -78,7 +78,7 @@ something like this: You can see the exact dependencies by reading the `Cargo.toml` for the various crates, just like a normal Rust crate. -One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM +One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM. During bootstrapping, LLVM is built and the [`src/librustc_llvm`] and [`src/rustllvm`] crates contain rust wrappers around LLVM (which is written in C++), so that the compiler can interface with it. From 4a9c3579f38baca5920e7b747f25e248765927e1 Mon Sep 17 00:00:00 2001 From: Youngsuk_Kim Date: Fri, 25 Sep 2020 17:39:17 -0400 Subject: [PATCH 1256/1812] update description of 'ByRef' borrows of closures --- src/closure.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/closure.md b/src/closure.md index 665f7734e..4e6e69d1d 100644 --- a/src/closure.md +++ b/src/closure.md @@ -183,10 +183,10 @@ The callbacks are defined by implementing the [`Delegate`] trait. The [`InferBorrowKind`][ibk] type implements `Delegate` and keeps a map that records for each upvar which mode of borrow was required. The modes of borrow can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be -`shared`, `shallow`, `unique` or `mut` as defined in the -[`compiler/rustc_middle/src/mir/mod.rs`][mir_mod]. +`ImmBorrow`, `UniqueImmBorrow`, `MutBorrow` as defined in the +[`compiler/rustc_middle/src/ty/mod.rs`][middle_ty]. -[mir_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html +[middle_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html `Delegate` defines a few different methods (the different callbacks): **consume** for *move* of a variable, **borrow** for a *borrow* of some kind From 80537ec1186592445b59a57542dc6a9adf47f090 Mon Sep 17 00:00:00 2001 From: Youngsuk_Kim Date: Fri, 25 Sep 2020 22:42:13 -0400 Subject: [PATCH 1257/1812] add link to 'BorrowKind' in closure.md --- src/closure.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/closure.md b/src/closure.md index 4e6e69d1d..f357eed9c 100644 --- a/src/closure.md +++ b/src/closure.md @@ -181,11 +181,12 @@ shared borrow and another one for a mutable borrow. It will also tell us what wa The callbacks are defined by implementing the [`Delegate`] trait. The [`InferBorrowKind`][ibk] type implements `Delegate` and keeps a map that -records for each upvar which mode of borrow was required. The modes of borrow -can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, it can be -`ImmBorrow`, `UniqueImmBorrow`, `MutBorrow` as defined in the +records for each upvar which mode of capture was required. The modes of capture +can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, the possible +[`BorrowKind`][BorrowKind]s are `ImmBorrow`, `UniqueImmBorrow`, `MutBorrow` as defined in the [`compiler/rustc_middle/src/ty/mod.rs`][middle_ty]. +[BorrowKind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BorrowKind.html [middle_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html `Delegate` defines a few different methods (the different callbacks): From e34496fb61ed3dc686a44e8bb54133319bf71d52 Mon Sep 17 00:00:00 2001 From: Youngsuk_Kim Date: Fri, 25 Sep 2020 22:50:50 -0400 Subject: [PATCH 1258/1812] update link to 'BorrowKind' to be implicit in markdown --- src/closure.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/closure.md b/src/closure.md index f357eed9c..3b535040e 100644 --- a/src/closure.md +++ b/src/closure.md @@ -183,10 +183,10 @@ The callbacks are defined by implementing the [`Delegate`] trait. The [`InferBorrowKind`][ibk] type implements `Delegate` and keeps a map that records for each upvar which mode of capture was required. The modes of capture can be `ByValue` (moved) or `ByRef` (borrowed). For `ByRef` borrows, the possible -[`BorrowKind`][BorrowKind]s are `ImmBorrow`, `UniqueImmBorrow`, `MutBorrow` as defined in the +[`BorrowKind`]s are `ImmBorrow`, `UniqueImmBorrow`, `MutBorrow` as defined in the [`compiler/rustc_middle/src/ty/mod.rs`][middle_ty]. -[BorrowKind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BorrowKind.html +[`BorrowKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BorrowKind.html [middle_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html `Delegate` defines a few different methods (the different callbacks): From c320337018ac6d56d0cd5b181ee0399d4ee94132 Mon Sep 17 00:00:00 2001 From: "Shahar Or (mightyiam)" Date: Sat, 26 Sep 2020 15:17:19 +0700 Subject: [PATCH 1259/1812] correct output path in Writing Documentation --- src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index 08ece467c..0415f8e08 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -390,7 +390,7 @@ the entire stage 2 compiler and compile the various books published on [doc.rust-lang.org][docs]. When updating documentation for the standard library, first try `./x.py doc library/std`. If that fails, or if you need to see the output from the latest version of `rustdoc`, add `--stage 1`. -Results should appear in `build/$TARGET/crate-docs`. +Results should appear in `build/$TARGET/doc`. [docs]: https://doc.rust-lang.org From ea7ee3a5035e5fd34b80058a937ac5e7b7b04f0f Mon Sep 17 00:00:00 2001 From: follower Date: Sun, 27 Sep 2020 04:08:41 +1300 Subject: [PATCH 1260/1812] Add link from "Writing Documentation" suggestion A link to the relevant section of the contributing documentation makes it easier for contributors to locate the relevant information. (e.g. via an in-page search for "doc".) This is particularly important currently as https://github.com/rust-lang/rust/blob/85072e330394440776ace5ae612e3ced32ef6348/CONTRIBUTING.md links directly to the (currently `rustc`-focused) "Getting Started" guide rather than the general Rust contribution content to which it used to point. --- src/getting-started.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 9c67f3dc4..75838060c 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -353,13 +353,14 @@ incredibly helpful: - [Cleanup crew][iceb]: find minimal reproductions of ICEs, bisect regressions, etc. This is a way of helping that saves a ton of time for others to fix an error later. -- Writing documentation: if you are feeling a bit more intrepid, you could try +- [Writing documentation][wd]: if you are feeling a bit more intrepid, you could try to read a part of the code and write doc comments for it. This will help you to learn some part of the compiler while also producing a useful artifact! - [Working groups][wg]: there are a bunch of working groups on a wide variety of rust-related things. [iceb]: ./notification-groups/cleanup-crew.md +[wd]: ./contributing.md#writing-documentation [wg]: https://rust-lang.github.io/compiler-team/working-groups/ From 5f39b8131fc228cb70baa0e70a66b555e8f6fa6e Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sat, 26 Sep 2020 16:05:06 -0400 Subject: [PATCH 1261/1812] Add docs for x.py setup --- src/getting-started.md | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 75838060c..66b5389b7 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -126,22 +126,29 @@ this chapter for more info][config]. In the top level of the repo: ```sh -cp config.toml.example config.toml +$ x.py setup ``` -Then, edit `config.toml`. You may want to search for, uncomment, and update -the following settings: - -- `debug = true`: enables debug symbols and `debug!` logging, takes a bit longer to compile. -- `incremental = true`: enables incremental compilation of the compiler itself, - which can significantly speed things up. This is turned off by default - because it's technically unsound; sometimes it will cause weird crashes. - Also, it can consume a lot of disk space. This has the same effect as the - `-i` or `--incremental` flags. -- `llvm-config`: enables building with system LLVM. [See this chapter][sysllvm] - for more info. This avoids building LLVM, which can take a while (45 minutes - on my laptop; others have reported 15 minutes or faster with incremental - compilation). +This will walk you through an interactive setup for x.py that looks like this: + +``` +$ x.py setup +Welcome to the Rust project! What do you want to do with x.py? +a) Contribute to the standard library +b) Contribute to the compiler +c) Contribute to the compiler, and also modify LLVM or codegen +d) Install Rust from source +Please choose one (a/b/c/d): a +`x.py` will now use the configuration at /home/joshua/rustc2/src/bootstrap/defaults/config.toml.library +To get started, try one of the following commands: +- `x.py check` +- `x.py build` +- `x.py test library/std` +- `x.py doc` +For more suggestions, see https://rustc-dev-guide.rust-lang.org/building/suggested.html +``` + +You may also want to set up [system LLVM][sysllvm] to avoid building LLVM from source. [sysllvm]: ./building/suggested.html#building-with-system-llvm From 35b702bf36fc9b2ff26f181f8b9145b958b9113b Mon Sep 17 00:00:00 2001 From: follower Date: Sun, 27 Sep 2020 04:22:47 +1300 Subject: [PATCH 1262/1812] Add links to documentation sources. Linking directly to the relevant/example document source locations makes it easier for potential contributors to find them. --- src/contributing.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 0415f8e08..ba446b274 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -373,10 +373,13 @@ the submodule to. Running `./x.py build` should work now. ## Writing Documentation Documentation improvements are very welcome. The source of `doc.rust-lang.org` -is located in `src/doc` in the tree, and standard API documentation is generated -from the source code itself. Documentation pull requests function in the same way +is located in [`src/doc`][srcdoc] in the tree, and standard API documentation is generated +from the source code itself (e.g. [`lib.rs`][librs]). Documentation pull requests function in the same way as other pull requests. +[srcdoc]: https://github.com/rust-lang/rust/tree/master/src/doc +[librs]: https://github.com/rust-lang/rust/blob/master/library/std/src/lib.rs#L1 + To find documentation-related issues, sort by the [T-doc label][tdoc]. [tdoc]: https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3Aissue%20label%3AT-doc From e281cf57a6ceaa4c0834dcf70955b20a2fe6c2fb Mon Sep 17 00:00:00 2001 From: follower Date: Sun, 27 Sep 2020 04:40:15 +1300 Subject: [PATCH 1263/1812] Fix line length error. Reduced line length to <100 (as indicated by PR build error). (Also removed extra space character before link.) --- src/contributing.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index ba446b274..b797a6b0a 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -373,9 +373,9 @@ the submodule to. Running `./x.py build` should work now. ## Writing Documentation Documentation improvements are very welcome. The source of `doc.rust-lang.org` -is located in [`src/doc`][srcdoc] in the tree, and standard API documentation is generated -from the source code itself (e.g. [`lib.rs`][librs]). Documentation pull requests function in the same way -as other pull requests. +is located in [`src/doc`][srcdoc] in the tree, and standard API documentation is generated +from the source code itself (e.g. [`lib.rs`][librs]). Documentation pull requests function +in the same way as other pull requests. [srcdoc]: https://github.com/rust-lang/rust/tree/master/src/doc [librs]: https://github.com/rust-lang/rust/blob/master/library/std/src/lib.rs#L1 From 6b5c62c6f8946a1a158bb1e84e1dabe87daee820 Mon Sep 17 00:00:00 2001 From: follower Date: Sun, 27 Sep 2020 22:16:59 +1300 Subject: [PATCH 1264/1812] Use implicit reference links for shorter lines (As suggested by jyn514.) --- src/contributing.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index b797a6b0a..5dd80c933 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -373,12 +373,12 @@ the submodule to. Running `./x.py build` should work now. ## Writing Documentation Documentation improvements are very welcome. The source of `doc.rust-lang.org` -is located in [`src/doc`][srcdoc] in the tree, and standard API documentation is generated -from the source code itself (e.g. [`lib.rs`][librs]). Documentation pull requests function +is located in [`src/doc`] in the tree, and standard API documentation is generated +from the source code itself (e.g. [`lib.rs`]). Documentation pull requests function in the same way as other pull requests. -[srcdoc]: https://github.com/rust-lang/rust/tree/master/src/doc -[librs]: https://github.com/rust-lang/rust/blob/master/library/std/src/lib.rs#L1 +[`src/doc`]: https://github.com/rust-lang/rust/tree/master/src/doc +[`lib.rs`]: https://github.com/rust-lang/rust/blob/master/library/std/src/lib.rs#L1 To find documentation-related issues, sort by the [T-doc label][tdoc]. From 5ee9d96c07b1ca9c9e3f888f7b6f4050bb61aee4 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 29 Sep 2020 15:18:00 +0000 Subject: [PATCH 1265/1812] --verbose is useful when not compiling and when compiling (#901) --- src/cli.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/cli.md b/src/cli.md index f47c89e1f..408ae2070 100644 --- a/src/cli.md +++ b/src/cli.md @@ -21,8 +21,8 @@ adding a new command-line argument. if it is too ambiguous what multiple flags would mean. - Always give options a long descriptive name, if only for more understandable compiler scripts. -- The `--verbose` flag is for adding verbose information to `rustc` output - when not compiling a program. For example, using it with the `--version` +- The `--verbose` flag is for adding verbose information to `rustc` + output. For example, using it with the `--version` flag gives information about the hashes of the compiler code. - Experimental flags and options must be guarded behind the `-Z unstable-options` flag. From 328bd35e7da69c68fe75d8ef81565f2e6878dac2 Mon Sep 17 00:00:00 2001 From: Jakob Degen Date: Thu, 24 Sep 2020 10:10:52 -0400 Subject: [PATCH 1266/1812] Add a section on using git. This section addresses the biggest issues that new contributors, especially those with limited familiarity with git, are likely to face. This is still a WIP. Thanks to jyn for the recommended improvements! --- src/SUMMARY.md | 1 + src/git.md | 203 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 204 insertions(+) create mode 100644 src/git.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 5bd038780..eaefb2ed4 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -33,6 +33,7 @@ - [About the compiler team](./compiler-team.md) - [Mastering @rustbot](./rustbot.md) - [Walkthrough: a typical contribution](./walkthrough.md) +- [Using git](./git.md) - [Bug Fix Procedure](./bug-fix-procedure.md) - [Implementing new features](./implementing_new_features.md) - [Stability attributes](./stability.md) diff --git a/src/git.md b/src/git.md new file mode 100644 index 000000000..07e30c2de --- /dev/null +++ b/src/git.md @@ -0,0 +1,203 @@ +# Using git + +The Rust project uses [git] to manage its source code. In order to +contribute, you'll need some familiarity with its features so that your changes +can be incorporated into the compiler. + +[git]: https://git-scm.com + +The goal of this page is to cover some of the more common questions and +problems new contributors face. Although some git basics will be covered here, +if you have never used git or GitHub before you may find that this is still a +little too fast for you. In that case, it would make sense to first read some +introductions to git, such as the Beginner and Getting started sections of +[this tutorial from Atlassian][atlassian-git]. GitHub also provides +[documentation] and [guides] for beginners. + +[atlassian-git]: https://www.atlassian.com/git/tutorials/what-is-version-control +[documentation]: https://docs.github.com/en/github/getting-started-with-github/set-up-git +[guides]: https://guides.github.com/introduction/git-handbook/ + +Although this page should get you to a point where you can start contributing, +learning more git is almost certainly a good use of your time if you want to +keep contributing. There are many tutorials online for those folks that are +newer which combine excellently with man pages and official documentation. + +## Prequisites + +We'll assume that you've installed git, forked [rust-lang/rust], and cloned the +forked repo to your PC. We'll also use the command line interface to interact +with git; there are also a number of GUIs and IDE integrations that can +generally do the same things. + +[rust-lang/rust]: https://github.com/rust-lang/rust + +If you've cloned your fork, then you will be able to reference it with `origin` +in your local repo. It may be helpful to also set up a remote for the official +rust-lang/rust repo via + +```sh +git remote add rust https://github.com/rust-lang/rust.git +``` + +if you're using HTTPS, or + +```sh +git remote add rust git@github.com:rust-lang/rust.git +``` + +if you're using SSH. + +## Standard Process + +Below is the normal procedure that you're likely to use for most minor changes +and PRs: + + 1. Ensure that you're making your changes on top of master: + `git checkout master`. + 2. Get the latest changes from the Rust repo: `git pull rust master`. + 3. Make a new branch for your change: `git checkout -b issue-12345-fix`. + 4. Make some changes to the repo and test them. + 5. Stage your changes via `git add src/changed/file.rs src/another/change.rs` + and then commit them with `git commit`. Of course, making intermediate commits + may be a good idea as well. Avoid `git add .`, as it makes it too easy to + unintentionally commit changes that should not be committed, such as submodule + updates. You can use `git status` to check if there are any files you forgot + to stage. + 6. Push your changes to your fork: `git push -u origin issue-12345-fix`. + 7. [Open a PR][ghpullrequest] from your fork to rust-lang/rust's master branch. + +[ghpullrequest]: https://guides.github.com/activities/forking/#making-a-pull-request + +If your reviewer requests changes, the procedure for those changes looks much +the same, with some steps skipped: + + 1. Ensure that you're making changes to the most recent version of your code: + `git checkout issue-12345-fix`. + 2. Make, stage, and commit your additional changes just like before. + 3. Push those changes to your fork: `git push`. + +## Conflicts + +When you edit your code locally, you are making changes to the version of +rust-lang/rust that existed the last time you ran `git pull rust master` on +your master branch. As such, when you submit your PR it is possible that some +of the changes that have been made to rust-lang/rust since then are in conflict +with the changes you've made; maybe someone else changed the same lines of +code, or git cannot figure out how to merge your changes with the others for +another reason. + +When this happens, you need to resolve the conflicts before your changes can be +merged. First, get a local copy of the conflicting changes. Checkout your local +master branch with `git checkout master`. Then, `git pull rust master` to +update it with the most recent changes. + +### Rebasing + +You're now ready to start the rebasing process. Check out the branch with your +changes, and then execute `git rebase master`. + +First, a little background: In git, commits are stored as "diffs" which are a +record of all the changes that a commit made to its parent. When you rebase a +branch, all the changes in the commits on that branch are reapplied on the +branch you are rebasing on top of (in this case master). In other words, git +tries to pretend that the changes you made to the old version of master were +instead made to the new version of master. + +During rebasing, you should expect to encounter at least one "rebase conflict." +This happens when git's attempt to reapply the changes onto the more recent +version of master fails because your changes conflicted with other changes that +have been made since then. You can tell that this happened because you'll see +lines in the output that look like + +``` +CONFLICT (content): Merge conflict in file.rs +``` + +When you open these files, you'll see sections of the form + +``` +<<<<<<< HEAD +Original code +======= +Your code +>>>>>>> 8fbf656... Commit fixes 12345 +``` + +This represents the lines in the file that git could not figure out how to +rebase. The section between `<<<<<<< HEAD` and `=======` has the code from +master, while the other side has your version of the code. You'll need to +decide how to deal with the conflict. You may want to keep your changes, +keep the changes on master, or combine the two. + +Generally, resovling the conflict consists of two steps: First, fix the +particular conflict. Edit the file to make the changes you want and remove the +`<<<<<<<`, `=======` and `>>>>>>>` lines in the process. Second, check the +surrounding code. If there was a conflict, its because someone else changed the +same code you did. That means its likely there are some logical errors lying +around too! + +Once you're all done fixing the conflicts, you need to stage the files that had +conflicts in them via `git add`. Afterwards, run `git rebase --continue` to let +git know that you've resolved the conflicts and it should finish the rebase. +Finally, once the rebase has succeeded, you'll want to update the associated +branch on your fork with `git push -f`. + +Note that `git push` will not work properly and say something like this: + +``` + ! [rejected] issue-xxxxx -> issue-xxxxx (non-fast-forward) +error: failed to push some refs to 'https://github.com/username/rust.git' +hint: Updates were rejected because the tip of your current branch is behind +hint: its remote counterpart. Integrate the remote changes (e.g. +hint: 'git pull ...') before pushing again. +hint: See the 'Note about fast-forwards' in 'git push --help' for details. +``` + +The advice this gives is incorrect! Because of the "no-merge" policy, running +`git pull` will create a merge commit, defeating the point of your rebase. Use +`git push -f` instead. + +## Advanced Rebasing + +Sometimes, you may want to perform a more complicated rebase. There are two +common scenarios that might call for this. + +If your branch contains multiple consecutive rewrites of the same code, or if +the rebase conflicts are extremely severe, it is possible that just trying to +reapply the changes you made on top of the updated code will be too much of a +headache. In this case, you can use the interactive rebase feature via +`git rebase -i master` to gain more control over the process. This allows you +to choose to skip commits because they represent changes you no longer need, +edit the commits that you do not skip, or change the order in which they are +applied. + +The other common scenario is if you are asked to or want to "squash" multiple +commits into each other. The most common example of this is likely if you +forgot to run `x.py tidy` before committing. Your PR will need to be revised, +but a single commit at the end with message "fixup tidy issue" is usually +unhelpful, and it is easier for everyone else if you combine that commit with +another that has a more meaningful commit message. In this case, you'll want to +run `git rebase -i HEAD~2` to edit the last two commits and merge them +together. Essentially, this reapplies the last two commits on top of your +current branch; this is of course a no-op, since that is where they are +already. However, by selecting the `-i` option, you give yourself the +opportunity to edit the rebase first, just like before. This way you can +request to have the most recent commit squashed into its parent. + +## No-Merge Policy + +The rust-lang/rust repo uses what is known as a "rebase workflow." This means +that merge commits in PRs are not accepted. As a result, if you are running +`git merge` locally, chances are good that you should be rebasing instead. Of +course, this is not always true; if your merge will just be a fast-forward, +like the merges that `git pull` usually performs, then no merge commit is +created and you have nothing to worry about. Running `git config merge.ff only` +once will prevent the creation of merge commits will help ensure you don't make +a mistake here. + +There are a number of reasons for this decision and like all others, it is a +tradeoff. The main advantage is the (mostly) linear commit history. This +greatly simplifies bisecting. TODO: There are other advantages to a rebase +workflow, but I would like to focus on the ones that people in the Rust project +consider most relevant, so I'm going to leave this unfinished for now. From be11a5201dd1f04f99b800d68d678580a00bd65a Mon Sep 17 00:00:00 2001 From: Jakob Degen Date: Thu, 24 Sep 2020 16:48:55 -0400 Subject: [PATCH 1267/1812] Edit using git page for brevity and clarity. The previous iteration of the page was often wordy and occasionally unclear. This has been cleaned up in places. Additionally, the TODO in the no-merge policy section has been removed and addressed. --- src/SUMMARY.md | 2 +- src/git.md | 86 ++++++++++++++++++++------------------------------ 2 files changed, 36 insertions(+), 52 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index eaefb2ed4..0e52a2e08 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -31,9 +31,9 @@ - [Introduction](./contributing.md) - [About the compiler team](./compiler-team.md) +- [Using git](./git.md) - [Mastering @rustbot](./rustbot.md) - [Walkthrough: a typical contribution](./walkthrough.md) -- [Using git](./git.md) - [Bug Fix Procedure](./bug-fix-procedure.md) - [Implementing new features](./implementing_new_features.md) - [Stability attributes](./stability.md) diff --git a/src/git.md b/src/git.md index 07e30c2de..b6b852587 100644 --- a/src/git.md +++ b/src/git.md @@ -8,25 +8,21 @@ can be incorporated into the compiler. The goal of this page is to cover some of the more common questions and problems new contributors face. Although some git basics will be covered here, -if you have never used git or GitHub before you may find that this is still a -little too fast for you. In that case, it would make sense to first read some -introductions to git, such as the Beginner and Getting started sections of -[this tutorial from Atlassian][atlassian-git]. GitHub also provides -[documentation] and [guides] for beginners. +if you find that this is still a little too fast for you, it might make sense +to first read some introductions to git, such as the Beginner and Getting +started sections of [this tutorial from Atlassian][atlassian-git]. GitHub also +provides [documentation] and [guides] for beginners, or you can consult the +more in depth [book from git]. +[book from git]: https://git-scm.com/book/en/v2/ [atlassian-git]: https://www.atlassian.com/git/tutorials/what-is-version-control [documentation]: https://docs.github.com/en/github/getting-started-with-github/set-up-git [guides]: https://guides.github.com/introduction/git-handbook/ -Although this page should get you to a point where you can start contributing, -learning more git is almost certainly a good use of your time if you want to -keep contributing. There are many tutorials online for those folks that are -newer which combine excellently with man pages and official documentation. - ## Prequisites We'll assume that you've installed git, forked [rust-lang/rust], and cloned the -forked repo to your PC. We'll also use the command line interface to interact +forked repo to your PC. We'll use the command line interface to interact with git; there are also a number of GUIs and IDE integrations that can generally do the same things. @@ -80,34 +76,27 @@ the same, with some steps skipped: ## Conflicts When you edit your code locally, you are making changes to the version of -rust-lang/rust that existed the last time you ran `git pull rust master` on -your master branch. As such, when you submit your PR it is possible that some -of the changes that have been made to rust-lang/rust since then are in conflict -with the changes you've made; maybe someone else changed the same lines of -code, or git cannot figure out how to merge your changes with the others for -another reason. +rust-lang/rust that existed when you created your feature branch. As such, when +you submit your PR it is possible that some of the changes that have been made +to rust-lang/rust since then are in conflict with the changes you've made. When this happens, you need to resolve the conflicts before your changes can be -merged. First, get a local copy of the conflicting changes. Checkout your local -master branch with `git checkout master`. Then, `git pull rust master` to +merged. First, get a local copy of the conflicting changes: Checkout your local +master branch with `git checkout master`, then `git pull rust master` to update it with the most recent changes. ### Rebasing You're now ready to start the rebasing process. Check out the branch with your -changes, and then execute `git rebase master`. - -First, a little background: In git, commits are stored as "diffs" which are a -record of all the changes that a commit made to its parent. When you rebase a -branch, all the changes in the commits on that branch are reapplied on the -branch you are rebasing on top of (in this case master). In other words, git -tries to pretend that the changes you made to the old version of master were -instead made to the new version of master. - -During rebasing, you should expect to encounter at least one "rebase conflict." -This happens when git's attempt to reapply the changes onto the more recent -version of master fails because your changes conflicted with other changes that -have been made since then. You can tell that this happened because you'll see +changes and execute `git rebase master`. + +When you rebase a branch on master, all the changes on your branch are +reapplied to the most recent version of master. In other words, git tries to +pretend that the changes you made to the old version of master were instead +made to the new version of master. During this process, you should expect to +encounter at least one "rebase conflict." This happens when git's attempt to +reapply the changes fails because your changes conflicted with other changes +that have been made. You can tell that this happened because you'll see lines in the output that look like ``` @@ -140,8 +129,8 @@ around too! Once you're all done fixing the conflicts, you need to stage the files that had conflicts in them via `git add`. Afterwards, run `git rebase --continue` to let git know that you've resolved the conflicts and it should finish the rebase. -Finally, once the rebase has succeeded, you'll want to update the associated -branch on your fork with `git push -f`. +Once the rebase has succeeded, you'll want to update the associated branch on +your fork with `git push -f`. Note that `git push` will not work properly and say something like this: @@ -173,17 +162,13 @@ edit the commits that you do not skip, or change the order in which they are applied. The other common scenario is if you are asked to or want to "squash" multiple -commits into each other. The most common example of this is likely if you -forgot to run `x.py tidy` before committing. Your PR will need to be revised, -but a single commit at the end with message "fixup tidy issue" is usually -unhelpful, and it is easier for everyone else if you combine that commit with -another that has a more meaningful commit message. In this case, you'll want to -run `git rebase -i HEAD~2` to edit the last two commits and merge them -together. Essentially, this reapplies the last two commits on top of your -current branch; this is of course a no-op, since that is where they are -already. However, by selecting the `-i` option, you give yourself the -opportunity to edit the rebase first, just like before. This way you can -request to have the most recent commit squashed into its parent. +commits into each other. If you PR needs only a minor revision, a single commit +at the end with message "fixup small issue" is usually unhelpful, and it is +easier for everyone if you combine that commit with another that has a more +meaningful commit message. Run `git rebase -i HEAD~2` to edit the last two +commits so you can merge them together. By selecting the `-i` option, you give +yourself the opportunity to edit the rebase, similarly to above. This way you +can request to have the most recent commit squashed into its parent. ## No-Merge Policy @@ -193,11 +178,10 @@ that merge commits in PRs are not accepted. As a result, if you are running course, this is not always true; if your merge will just be a fast-forward, like the merges that `git pull` usually performs, then no merge commit is created and you have nothing to worry about. Running `git config merge.ff only` -once will prevent the creation of merge commits will help ensure you don't make -a mistake here. +once will ensure that all the merges you perform are of this type, so that you +cannot make a mistake. There are a number of reasons for this decision and like all others, it is a -tradeoff. The main advantage is the (mostly) linear commit history. This -greatly simplifies bisecting. TODO: There are other advantages to a rebase -workflow, but I would like to focus on the ones that people in the Rust project -consider most relevant, so I'm going to leave this unfinished for now. +tradeoff. The main advantage is the generally linear commit history. This +greatly simplifies bisecting and makes the history and commit log much easier +to follow and understand. From c26ab70782bcf4edf916ec24b93fa9afafaefc76 Mon Sep 17 00:00:00 2001 From: Jakob Degen Date: Fri, 25 Sep 2020 15:30:29 -0400 Subject: [PATCH 1268/1812] Incorporated suggestions into git page and edit for more brevity. The Advanced Rebasing section has been mostly rewritten to include both a major suggestion from jyn and a general rewrite. Additional thanks to camelid for some suggestions! --- src/SUMMARY.md | 2 +- src/git.md | 97 ++++++++++++++++++++++++++------------------------ 2 files changed, 52 insertions(+), 47 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 0e52a2e08..f3ebe4da8 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -31,7 +31,7 @@ - [Introduction](./contributing.md) - [About the compiler team](./compiler-team.md) -- [Using git](./git.md) +- [Using Git](./git.md) - [Mastering @rustbot](./rustbot.md) - [Walkthrough: a typical contribution](./walkthrough.md) - [Bug Fix Procedure](./bug-fix-procedure.md) diff --git a/src/git.md b/src/git.md index b6b852587..9f025ff61 100644 --- a/src/git.md +++ b/src/git.md @@ -1,29 +1,29 @@ -# Using git +# Using Git -The Rust project uses [git] to manage its source code. In order to +The Rust project uses [Git] to manage its source code. In order to contribute, you'll need some familiarity with its features so that your changes can be incorporated into the compiler. -[git]: https://git-scm.com +[Git]: https://git-scm.com The goal of this page is to cover some of the more common questions and -problems new contributors face. Although some git basics will be covered here, +problems new contributors face. Although some Git basics will be covered here, if you find that this is still a little too fast for you, it might make sense -to first read some introductions to git, such as the Beginner and Getting +to first read some introductions to Git, such as the Beginner and Getting started sections of [this tutorial from Atlassian][atlassian-git]. GitHub also provides [documentation] and [guides] for beginners, or you can consult the -more in depth [book from git]. +more in depth [book from Git]. -[book from git]: https://git-scm.com/book/en/v2/ +[book from Git]: https://git-scm.com/book/en/v2/ [atlassian-git]: https://www.atlassian.com/git/tutorials/what-is-version-control [documentation]: https://docs.github.com/en/github/getting-started-with-github/set-up-git [guides]: https://guides.github.com/introduction/git-handbook/ ## Prequisites -We'll assume that you've installed git, forked [rust-lang/rust], and cloned the +We'll assume that you've installed Git, forked [rust-lang/rust], and cloned the forked repo to your PC. We'll use the command line interface to interact -with git; there are also a number of GUIs and IDE integrations that can +with Git; there are also a number of GUIs and IDE integrations that can generally do the same things. [rust-lang/rust]: https://github.com/rust-lang/rust @@ -33,13 +33,13 @@ in your local repo. It may be helpful to also set up a remote for the official rust-lang/rust repo via ```sh -git remote add rust https://github.com/rust-lang/rust.git +git remote add upstream https://github.com/rust-lang/rust.git ``` if you're using HTTPS, or ```sh -git remote add rust git@github.com:rust-lang/rust.git +git remote add upstream git@github.com:rust-lang/rust.git ``` if you're using SSH. @@ -51,7 +51,7 @@ and PRs: 1. Ensure that you're making your changes on top of master: `git checkout master`. - 2. Get the latest changes from the Rust repo: `git pull rust master`. + 2. Get the latest changes from the Rust repo: `git pull upstream master`. 3. Make a new branch for your change: `git checkout -b issue-12345-fix`. 4. Make some changes to the repo and test them. 5. Stage your changes via `git add src/changed/file.rs src/another/change.rs` @@ -60,7 +60,7 @@ and PRs: unintentionally commit changes that should not be committed, such as submodule updates. You can use `git status` to check if there are any files you forgot to stage. - 6. Push your changes to your fork: `git push -u origin issue-12345-fix`. + 6. Push your changes to your fork: `git push --set-upstream origin issue-12345-fix`. 7. [Open a PR][ghpullrequest] from your fork to rust-lang/rust's master branch. [ghpullrequest]: https://guides.github.com/activities/forking/#making-a-pull-request @@ -82,19 +82,19 @@ to rust-lang/rust since then are in conflict with the changes you've made. When this happens, you need to resolve the conflicts before your changes can be merged. First, get a local copy of the conflicting changes: Checkout your local -master branch with `git checkout master`, then `git pull rust master` to +master branch with `git checkout master`, then `git pull upstream master` to update it with the most recent changes. ### Rebasing -You're now ready to start the rebasing process. Check out the branch with your +You're now ready to start the rebasing process. Checkout the branch with your changes and execute `git rebase master`. When you rebase a branch on master, all the changes on your branch are -reapplied to the most recent version of master. In other words, git tries to +reapplied to the most recent version of master. In other words, Git tries to pretend that the changes you made to the old version of master were instead made to the new version of master. During this process, you should expect to -encounter at least one "rebase conflict." This happens when git's attempt to +encounter at least one "rebase conflict." This happens when Git's attempt to reapply the changes fails because your changes conflicted with other changes that have been made. You can tell that this happened because you'll see lines in the output that look like @@ -113,24 +113,24 @@ Your code >>>>>>> 8fbf656... Commit fixes 12345 ``` -This represents the lines in the file that git could not figure out how to +This represents the lines in the file that Git could not figure out how to rebase. The section between `<<<<<<< HEAD` and `=======` has the code from master, while the other side has your version of the code. You'll need to decide how to deal with the conflict. You may want to keep your changes, keep the changes on master, or combine the two. -Generally, resovling the conflict consists of two steps: First, fix the +Generally, resolving the conflict consists of two steps: First, fix the particular conflict. Edit the file to make the changes you want and remove the `<<<<<<<`, `=======` and `>>>>>>>` lines in the process. Second, check the -surrounding code. If there was a conflict, its because someone else changed the -same code you did. That means its likely there are some logical errors lying -around too! +surrounding code. If there was a conflict, its likely there are some logical +errors lying around too! It's a good idea to run `x.py check` here to make sure +there are no glaring errors. Once you're all done fixing the conflicts, you need to stage the files that had conflicts in them via `git add`. Afterwards, run `git rebase --continue` to let -git know that you've resolved the conflicts and it should finish the rebase. +Git know that you've resolved the conflicts and it should finish the rebase. Once the rebase has succeeded, you'll want to update the associated branch on -your fork with `git push -f`. +your fork with `git push --force-with-lease`. Note that `git push` will not work properly and say something like this: @@ -143,32 +143,37 @@ hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. ``` -The advice this gives is incorrect! Because of the "no-merge" policy, running -`git pull` will create a merge commit, defeating the point of your rebase. Use -`git push -f` instead. +The advice this gives is incorrect! Because of Rust's +["no-merge" policy](#no-merge-policy) the merge commit created by `git pull` +will not be allowed in the final PR, in addition to defeating the point of the +rebase! Use `git push --force-with-lease` instead. ## Advanced Rebasing -Sometimes, you may want to perform a more complicated rebase. There are two -common scenarios that might call for this. - If your branch contains multiple consecutive rewrites of the same code, or if -the rebase conflicts are extremely severe, it is possible that just trying to -reapply the changes you made on top of the updated code will be too much of a -headache. In this case, you can use the interactive rebase feature via -`git rebase -i master` to gain more control over the process. This allows you -to choose to skip commits because they represent changes you no longer need, -edit the commits that you do not skip, or change the order in which they are -applied. - -The other common scenario is if you are asked to or want to "squash" multiple -commits into each other. If you PR needs only a minor revision, a single commit -at the end with message "fixup small issue" is usually unhelpful, and it is -easier for everyone if you combine that commit with another that has a more -meaningful commit message. Run `git rebase -i HEAD~2` to edit the last two -commits so you can merge them together. By selecting the `-i` option, you give -yourself the opportunity to edit the rebase, similarly to above. This way you -can request to have the most recent commit squashed into its parent. +the rebase conflicts are extremely severe, you can use +`git rebase --interactive master` to gain more control over the process. This +allows you to choose to skip commits, edit the commits that you do not skip, +change the order in which they are applied, or "squash" them into each other. + +Alternatively, you can sacrifice the commit history like this: + +``` +# squash all the changes into one commit so you only have to worry about conflicts once +git rebase -i $(git merge-base master) # and squash all changes along the way +git rebase master +# fix all merge conflicts +git rebase --continue +``` + +"Squashing" commits into each other causes them to be merged into a single +commit. Both the upside and downside of this is that it simplifies the history. +On the one hand, you lose track of the steps in which changes were made, but +the history becomes easier to work with. + +You also may want to squash just the last few commits together, possibly +because they only represent "fixups" and not real changes. For example, +`git rebase --interactive HEAD~2` will allow you to edit the two commits only. ## No-Merge Policy From a8b7e92c12f3d0f2fae55507a34a3fe329593069 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 30 Sep 2020 13:19:46 -0400 Subject: [PATCH 1269/1812] Fix typo --- src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/git.md b/src/git.md index 9f025ff61..5f88235c2 100644 --- a/src/git.md +++ b/src/git.md @@ -19,7 +19,7 @@ more in depth [book from Git]. [documentation]: https://docs.github.com/en/github/getting-started-with-github/set-up-git [guides]: https://guides.github.com/introduction/git-handbook/ -## Prequisites +## Prerequisites We'll assume that you've installed Git, forked [rust-lang/rust], and cloned the forked repo to your PC. We'll use the command line interface to interact From 4a6fd1131b7e6b689947cd68586dfc474a4d9392 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 24 Sep 2020 09:29:46 -0400 Subject: [PATCH 1270/1812] Recommend setting up `check_line_lengths` as a pre-commit script I've run into lots of annoying failures from this. - Make it runnable without arguments - Add it in the README --- README.md | 11 +++++++++++ ci/check_line_lengths.sh | 17 ++++++++--------- 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 5dbd5d27f..fd83cea2d 100644 --- a/README.md +++ b/README.md @@ -76,6 +76,17 @@ and execute the following command in the root of the repository: The build files are found in the `book` directory. +### Pre-commit script + +We also test that line lengths are less than 100 columns. To test this locally, +you can run `ci/check_line_lengths.sh`. + +You can also set this to run automatically with the following command: + +```bash +ln -s ../../ci/check_line_lengths.sh .git/hooks/pre-commit +``` + ### Link Validations We use `mdbook-linkcheck` to validate URLs included in our documentation. To perform link checks, uncomment the `[output.linkcheck]` field in the `book.toml` configuration file and install `mdbook-linkcheck` with: diff --git a/ci/check_line_lengths.sh b/ci/check_line_lengths.sh index 32bf739e4..8ecb8a309 100755 --- a/ci/check_line_lengths.sh +++ b/ci/check_line_lengths.sh @@ -1,19 +1,18 @@ -#!/bin/bash +#!/usr/bin/env bash if [ "$1" == "--help" ]; then - echo 'Usage:' - echo ' MAX_LINE_LENGTH=100' "$0" 'src/**/*.md' - exit 1 + echo 'Usage:' "[MAX_LINE_LENGTH=n] $0 [file ...]" + exit 1 fi if [ "$MAX_LINE_LENGTH" == "" ]; then - echo '`MAX_LINE_LENGTH` environment variable not set. Try --help.' - exit 1 + MAX_LINE_LENGTH=100 fi if [ "$1" == "" ]; then - echo 'No files provided.' - exit 1 + files=( src/**/*.md ) +else + files=( "$@" ) fi echo "Checking line lengths in all source files <= $MAX_LINE_LENGTH chars..." @@ -21,7 +20,7 @@ echo "Checking line lengths in all source files <= $MAX_LINE_LENGTH chars..." echo "Offending files and lines:" (( bad_lines = 0 )) (( inside_block = 0 )) -for file in "$@" ; do +for file in "${files[@]}"; do echo "$file" (( line_no = 0 )) while IFS="" read -r line || [[ -n "$line" ]] ; do From 8aaf8edf2104e1fbe2be228704f4057a8e0a288e Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 29 Sep 2020 11:43:11 -0400 Subject: [PATCH 1271/1812] Add windows instructions --- README.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index fd83cea2d..99e781490 100644 --- a/README.md +++ b/README.md @@ -81,12 +81,20 @@ The build files are found in the `book` directory. We also test that line lengths are less than 100 columns. To test this locally, you can run `ci/check_line_lengths.sh`. -You can also set this to run automatically with the following command: +You can also set this to run automatically. + +On Linux: ```bash ln -s ../../ci/check_line_lengths.sh .git/hooks/pre-commit ``` +On Windows: + +```powershell +cd .git/hooks && New-Item -Path ../../.git_hooks/* -ItemType SymbolicLink -Value . && cd ../.. +``` + ### Link Validations We use `mdbook-linkcheck` to validate URLs included in our documentation. To perform link checks, uncomment the `[output.linkcheck]` field in the `book.toml` configuration file and install `mdbook-linkcheck` with: From c58ff8dc096c0a3165dc02a7c7690e73deaa462f Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 30 Sep 2020 21:01:48 -0400 Subject: [PATCH 1272/1812] Fix incorrect windows link Co-authored-by: Yuki Okushi --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 99e781490..aab497af3 100644 --- a/README.md +++ b/README.md @@ -92,7 +92,7 @@ ln -s ../../ci/check_line_lengths.sh .git/hooks/pre-commit On Windows: ```powershell -cd .git/hooks && New-Item -Path ../../.git_hooks/* -ItemType SymbolicLink -Value . && cd ../.. +New-Item -Path .git/hooks/pre-commit -ItemType HardLink -Value ``` ### Link Validations From fdd5946d58dd66409a876dc932998c0fbd4b7224 Mon Sep 17 00:00:00 2001 From: Roman Date: Fri, 2 Oct 2020 09:42:41 +0200 Subject: [PATCH 1273/1812] add the last missing code highlight to t-compiler in the docs --- src/getting-started.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 66b5389b7..1f338a661 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -6,13 +6,13 @@ chapter on how to build and run the compiler](./building/how-to-build-and-run.md ## Asking Questions -The compiler team (or "t-compiler") usually hangs out in Zulip [in this +The compiler team (or `t-compiler`) usually hangs out in Zulip [in this "stream"][z]; it will be easiest to get questions answered there. [z]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler **Please ask questions!** A lot of people report feeling that they are "wasting -expert time", but nobody on t-compiler feels this way. Contributors are +expert time", but nobody on `t-compiler` feels this way. Contributors are important to us. Also, if you feel comfortable, prefer public topics, as this means others can From 6159dde37a4f975129cc09923d469930077b7d53 Mon Sep 17 00:00:00 2001 From: Camelid Date: Fri, 2 Oct 2020 11:55:43 -0700 Subject: [PATCH 1274/1812] Fix instructions for squashing `git merge-base master` does not work, you need `git merge-base master HEAD` instead. --- src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/git.md b/src/git.md index 5f88235c2..633e7d572 100644 --- a/src/git.md +++ b/src/git.md @@ -160,7 +160,7 @@ Alternatively, you can sacrifice the commit history like this: ``` # squash all the changes into one commit so you only have to worry about conflicts once -git rebase -i $(git merge-base master) # and squash all changes along the way +git rebase -i $(git merge-base master HEAD) # and squash all changes along the way git rebase master # fix all merge conflicts git rebase --continue From 156423221c46d60c28d90abb205c0fe5d310b915 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 4 Oct 2020 03:30:36 +0900 Subject: [PATCH 1275/1812] Fix the report link --- src/appendix/bibliography.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index ff09a26b0..1453f85da 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -24,7 +24,7 @@ Rust, as well as publications about Rust. * [Thread scheduling for multiprogramming multiprocessors](http://www.eecis.udel.edu/%7Ecavazos/cisc879-spring2008/papers/arora98thread.pdf) * [The data locality of work stealing](http://www.aladdin.cs.cmu.edu/papers/pdfs/y2000/locality_spaa00.pdf) * [Dynamic circular work stealing deque](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.1097&rep=rep1&type=pdf) - The Chase/Lev deque -* [Work-first and help-first scheduling policies for async-finish task parallelism](http://www.cs.rice.edu/%7Eyguo/pubs/PID824943.pdf) - More general than fully-strict work stealing +* [Work-first and help-first scheduling policies for async-finish task parallelism](https://dl.acm.org/doi/10.1109/IPDPS.2009.5161079) - More general than fully-strict work stealing * [A Java fork/join calamity](https://web.archive.org/web/20190904045322/http://www.coopsoft.com/ar/CalamityArticle.html) - critique of Java's fork/join library, particularly its application of work stealing to non-strict computation * [Scheduling techniques for concurrent systems](http://www.stanford.edu/~ouster/cgi-bin/papers/coscheduling.pdf) * [Contention aware scheduling](http://www.blagodurov.net/files/a8-blagodurov.pdf) From 6a5b29b31e8b521a47aae40524523cac44e92f1c Mon Sep 17 00:00:00 2001 From: Camelid <37223377+camelid@users.noreply.github.com> Date: Sat, 3 Oct 2020 13:56:29 -0700 Subject: [PATCH 1276/1812] Use HTTPS whenever possible in bibliography links (#909) Also updated a few links that redirected. --- src/appendix/bibliography.md | 40 ++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index 1453f85da..b5defaefd 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -7,30 +7,30 @@ Rust, as well as publications about Rust. ## Type system * [Region based memory management in Cyclone](https://www.cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf) -* [Safe manual memory management in Cyclone](http://www.cs.umd.edu/projects/PL/cyclone/scp.pdf) +* [Safe manual memory management in Cyclone](https://www.cs.umd.edu/projects/PL/cyclone/scp.pdf) * [Making ad-hoc polymorphism less ad hoc](https://dl.acm.org/doi/10.1145/75277.75283) * [Macros that work together](https://www.cs.utah.edu/plt/publications/jfp12-draft-fcdf.pdf) * [Traits: composable units of behavior](http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf) * [Alias burying](http://www.cs.uwm.edu/faculty/boyland/papers/unique-preprint.ps) - We tried something similar and abandoned it. * [External uniqueness is unique enough](http://www.cs.uu.nl/research/techreps/UU-CS-2002-048.html) * [Uniqueness and Reference Immutability for Safe Parallelism](https://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf) -* [Region Based Memory Management](http://www.cs.ucla.edu/~palsberg/tba/papers/tofte-talpin-iandc97.pdf) +* [Region Based Memory Management](https://www.cs.ucla.edu/~palsberg/tba/papers/tofte-talpin-iandc97.pdf) ## Concurrency * [Singularity: rethinking the software stack](https://research.microsoft.com/pubs/69431/osr2007_rethinkingsoftwarestack.pdf) * [Language support for fast and reliable message passing in singularity OS](https://research.microsoft.com/pubs/67482/singsharp.pdf) * [Scheduling multithreaded computations by work stealing](http://supertech.csail.mit.edu/papers/steal.pdf) -* [Thread scheduling for multiprogramming multiprocessors](http://www.eecis.udel.edu/%7Ecavazos/cisc879-spring2008/papers/arora98thread.pdf) +* [Thread scheduling for multiprogramming multiprocessors](https://www.eecis.udel.edu/%7Ecavazos/cisc879-spring2008/papers/arora98thread.pdf) * [The data locality of work stealing](http://www.aladdin.cs.cmu.edu/papers/pdfs/y2000/locality_spaa00.pdf) -* [Dynamic circular work stealing deque](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.1097&rep=rep1&type=pdf) - The Chase/Lev deque +* [Dynamic circular work stealing deque](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.170.1097&rep=rep1&type=pdf) - The Chase/Lev deque * [Work-first and help-first scheduling policies for async-finish task parallelism](https://dl.acm.org/doi/10.1109/IPDPS.2009.5161079) - More general than fully-strict work stealing * [A Java fork/join calamity](https://web.archive.org/web/20190904045322/http://www.coopsoft.com/ar/CalamityArticle.html) - critique of Java's fork/join library, particularly its application of work stealing to non-strict computation -* [Scheduling techniques for concurrent systems](http://www.stanford.edu/~ouster/cgi-bin/papers/coscheduling.pdf) -* [Contention aware scheduling](http://www.blagodurov.net/files/a8-blagodurov.pdf) +* [Scheduling techniques for concurrent systems](https://www.stanford.edu/~ouster/cgi-bin/papers/coscheduling.pdf) +* [Contention aware scheduling](https://www.blagodurov.net/files/a8-blagodurov.pdf) * [Balanced work stealing for time-sharing multicores](https://web.njit.edu/~dingxn/papers/BWS.pdf) -* [Three layer cake for shared-memory programming](http://dl.acm.org/citation.cfm?id=1953616&dl=ACM&coll=DL&CFID=524387192&CFTOKEN=44362705) -* [Non-blocking steal-half work queues](http://www.cs.bgu.ac.il/%7Ehendlerd/papers/p280-hendler.pdf) +* [Three layer cake for shared-memory programming](https://dl.acm.org/doi/10.1145/1953611.1953616) +* [Non-blocking steal-half work queues](https://www.cs.bgu.ac.il/%7Ehendlerd/papers/p280-hendler.pdf) * [Reagents: expressing and composing fine-grained concurrency](https://aturon.github.io/academic/reagents.pdf) * [Algorithms for scalable synchronization of shared-memory multiprocessors](https://www.cs.rochester.edu/u/scott/papers/1991_TOCS_synch.pdf) * [Epoch-based reclamation](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf). @@ -38,8 +38,8 @@ Rust, as well as publications about Rust. ## Others * [Crash-only software](https://www.usenix.org/legacy/events/hotos03/tech/full_papers/candea/candea.pdf) -* [Composing High-Performance Memory Allocators](http://people.cs.umass.edu/~emery/pubs/berger-pldi2001.pdf) -* [Reconsidering Custom Memory Allocation](http://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf) +* [Composing High-Performance Memory Allocators](https://people.cs.umass.edu/~emery/pubs/berger-pldi2001.pdf) +* [Reconsidering Custom Memory Allocation](https://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf) ## Papers *about* Rust @@ -51,10 +51,10 @@ Rust, as well as publications about Rust. idea](https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea) - not exactly about Rust, but by nmatsakis * [Patina: A Formalization of the Rust Programming - Language](http://dada.cs.washington.edu/research/tr/2015/03/UW-CSE-15-03-02.pdf). + Language](https://dada.cs.washington.edu/research/tr/2015/03/UW-CSE-15-03-02.pdf). Early formalization of a subset of the type system, by Eric Reed. * [Experience Report: Developing the Servo Web Browser Engine using - Rust](http://arxiv.org/abs/1505.07383). By Lars Bergstrom. + Rust](https://arxiv.org/abs/1505.07383). By Lars Bergstrom. * [Implementing a Generic Radix Trie in Rust](https://michaelsproul.github.io/rust_radix_paper/rust-radix-sproul.pdf). Undergrad paper by Michael Sproul. @@ -67,23 +67,23 @@ Rust, as well as publications about Rust. in Rust](http://spw15.langsec.org/papers/couprie-nom.pdf). By Geoffroy Couprie, research for VLC. * [Graph-Based Higher-Order Intermediate - Representation](http://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf). An + Representation](https://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf). An experimental IR implemented in Impala, a Rust-like language. * [Code Refinement of Stencil - Codes](http://compilers.cs.uni-saarland.de/papers/ppl14_web.pdf). Another + Codes](https://compilers.cs.uni-saarland.de/papers/ppl14_web.pdf). Another paper using Impala. * [Parallelization in Rust with fork-join and friends](http://publications.lib.chalmers.se/records/fulltext/219016/219016.pdf). Linus Farnstrand's master's thesis. * [Session Types for - Rust](http://munksgaard.me/papers/laumann-munksgaard-larsen.pdf). Philip + Rust](https://munksgaard.me/papers/laumann-munksgaard-larsen.pdf). Philip Munksgaard's master's thesis. Research for Servo. -* [Ownership is Theft: Experiences Building an Embedded OS in Rust - Amit Levy, et. al.](http://amitlevy.com/papers/tock-plos2015.pdf) +* [Ownership is Theft: Experiences Building an Embedded OS in Rust - Amit Levy, et. al.](https://amitlevy.com/papers/tock-plos2015.pdf) * [You can't spell trust without Rust](https://raw.githubusercontent.com/Gankro/thesis/master/thesis.pdf). Alexis Beingessner's master's thesis. -* [Rust-Bio: a fast and safe bioinformatics library](http://bioinformatics.oxfordjournals.org/content/early/2015/10/06/bioinformatics.btv573). Johannes Köster -* [Safe, Correct, and Fast Low-Level Networking](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.704.1768). Robert Clipsham's master's thesis. -* [Formalizing Rust traits](http://hdl.handle.net/2429/55609). Jonatan Milewski's master's thesis. -* [Rust as a Language for High Performance GC Implementation](http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rust-ismm-2016.pdf) +* [Rust-Bio: a fast and safe bioinformatics library](https://academic.oup.com/bioinformatics/article/32/3/444/1743419). Johannes Köster +* [Safe, Correct, and Fast Low-Level Networking](https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.704.1768). Robert Clipsham's master's thesis. +* [Formalizing Rust traits](https://open.library.ubc.ca/cIRcle/collections/ubctheses/24/items/1.0220521). Jonatan Milewski's master's thesis. +* [Rust as a Language for High Performance GC Implementation](https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rust-ismm-2016.pdf) * [Simple Verification of Rust Programs via Functional Purification](https://github.com/Kha/electrolysis). Sebastian Ullrich's master's thesis. * [Writing parsers like it is 2017](http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf) Pierre Chifflier and Geoffroy Couprie for the Langsec Workshop * [The Case for Writing a Kernel in Rust](https://www.tockos.org/assets/papers/rust-kernel-apsys2017.pdf) From 3d6d0e04ed6257d243327a9abdab0f506befefd5 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 3 Oct 2020 20:30:30 +0200 Subject: [PATCH 1277/1812] Add a paragraph about reviewers and review latency in Getting Started chapter --- src/getting-started.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/getting-started.md b/src/getting-started.md index 1f338a661..1f5a691ee 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -385,10 +385,21 @@ team member you've been working with), you can specifically request them by writing `r? @user` (e.g. `r? @eddyb`) in either the original post or a followup comment. +Please note that the reviewers are humans, who for the most part work on `rustc` +in their free time. This means that they can take some time to respond and review +your PR. It also means that reviewers can miss some PRs that are assigned to them. + +To try to move PRs forward, the Triage WG regularely goes through all PRs that +are waiting for review and haven't been discussed for at least a week. If you +don't get a review within around 10 days, feel free to ask the Triage WG on +Zulip ([#t-release/triage]). They have knowledge of when to ping, who might be +on vacation, etc... + The reviewer may request some changes using the GitHub code review interface. They may also request special procedures (such as a [crater] run; [see below][break]) for some PRs. +[#t-release/triage]: https://rust-lang.zulipchat.com/#narrow/stream/242269-t-release.2Ftriage [break]: #breaking-changes When the PR is ready to be merged, the reviewer will issue a command to From 080b0c8aad953706b2d3e464282578236dfbb013 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 3 Oct 2020 20:48:15 +0200 Subject: [PATCH 1278/1812] Update src/getting-started.md Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 1f5a691ee..26558e836 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -389,7 +389,7 @@ Please note that the reviewers are humans, who for the most part work on `rustc` in their free time. This means that they can take some time to respond and review your PR. It also means that reviewers can miss some PRs that are assigned to them. -To try to move PRs forward, the Triage WG regularely goes through all PRs that +To try to move PRs forward, the Triage WG regularly goes through all PRs that are waiting for review and haven't been discussed for at least a week. If you don't get a review within around 10 days, feel free to ask the Triage WG on Zulip ([#t-release/triage]). They have knowledge of when to ping, who might be From f833b8bcdfcf79d86369657ea0b760d86d39b014 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Sat, 3 Oct 2020 20:48:24 +0200 Subject: [PATCH 1279/1812] Update src/getting-started.md Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 26558e836..d9070f706 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -393,7 +393,7 @@ To try to move PRs forward, the Triage WG regularly goes through all PRs that are waiting for review and haven't been discussed for at least a week. If you don't get a review within around 10 days, feel free to ask the Triage WG on Zulip ([#t-release/triage]). They have knowledge of when to ping, who might be -on vacation, etc... +on vacation, etc. The reviewer may request some changes using the GitHub code review interface. They may also request special procedures (such as a [crater] run; [see From 47ce12a4c833243444150dce2d855b5a6c25512c Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 3 Oct 2020 22:49:38 +0200 Subject: [PATCH 1280/1812] Fix time periods for Triage WG procedure --- src/getting-started.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index d9070f706..5837e9423 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -390,8 +390,8 @@ in their free time. This means that they can take some time to respond and revie your PR. It also means that reviewers can miss some PRs that are assigned to them. To try to move PRs forward, the Triage WG regularly goes through all PRs that -are waiting for review and haven't been discussed for at least a week. If you -don't get a review within around 10 days, feel free to ask the Triage WG on +are waiting for review and haven't been discussed for at least 2 weeks. If you +don't get a review within 2 weeks, feel free to ask the Triage WG on Zulip ([#t-release/triage]). They have knowledge of when to ping, who might be on vacation, etc. From c583e8b98290ac10d6a49bd2105fd424123a5534 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 25 Sep 2020 17:03:54 -0300 Subject: [PATCH 1281/1812] hir_map -> hir() --- src/hir.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/hir.md b/src/hir.md index 47262c485..5757d1e77 100644 --- a/src/hir.md +++ b/src/hir.md @@ -84,12 +84,12 @@ For more detailed information, check out the [chapter on identifiers][ids]. ### The HIR Map Most of the time when you are working with the HIR, you will do so via -the **HIR Map**, accessible in the tcx via [`tcx.hir_map`] (and defined in +the **HIR Map**, accessible in the tcx via [`tcx.hir()`] (and defined in the [`hir::map`] module). The [HIR map] contains a [number of methods] to convert between IDs of various kinds and to lookup data associated with an HIR node. -[`tcx.hir_map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.GlobalCtxt.html#structfield.hir_map +[`tcx.hir()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.hir [`hir::map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/index.html [HIR map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html [number of methods]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#methods From 95650a8cbbb8e5cd35f15b4ef7ea2f6d08d6b675 Mon Sep 17 00:00:00 2001 From: Aleksey Kladov Date: Sun, 13 Sep 2020 21:11:06 +0200 Subject: [PATCH 1282/1812] Document new way to not build LLVM Implemented in https://github.com/rust-lang/rust/pull/76349 --- src/building/suggested.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 424452b62..cc8d92a5c 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -161,12 +161,21 @@ git worktree add -b my-feature ../rust2 master You can then use that rust2 folder as a separate workspace for modifying and building `rustc`! -## Building with system LLVM +## Skipping LLVM Build -By default, LLVM is built from source, and that can take significant amount of -time. An alternative is to use LLVM already installed on your computer. +By default, LLVM is built from source, and that takes significant amount of +time. One way to avoid that is to add this to `config.toml`: -This is specified in the `target` section of `config.toml`: +```toml +[llvm] +download-ci-llvm = true +``` + +Downloading LLVM from CI is still experimental though, and might not be +available on all platforms. Otherwise, we'd make it a default! + +Another alternative is to use LLVM already installed on your computer. This is +specified in the `target` section of `config.toml`: ```toml [target.x86_64-unknown-linux-gnu] From 7adeb090fc50bf71928c4d6b1e46dadeb1f0b41e Mon Sep 17 00:00:00 2001 From: Julian Wollersberger Date: Sat, 3 Oct 2020 10:46:18 +0200 Subject: [PATCH 1283/1812] Document the usage of cargo-llvm-lines and -Ztimings. --- src/profiling.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 80 insertions(+), 1 deletion(-) diff --git a/src/profiling.md b/src/profiling.md index 8eaa8e94f..db5806927 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -12,5 +12,84 @@ Depending on what you're trying to measure, there are several different approach See [their docs](https://github.com/rust-lang/measureme/blob/master/summarize/Readme.md) for more information. - If you want function level performance data or even just more details than the above approaches: - - Consider using a native code profiler such as [perf](profiling/with_perf.html). + - Consider using a native code profiler such as [perf](profiling/with_perf.html) + - or [tracy](https://github.com/nagisa/rust_tracy_client) for a nanosecond-precision, + full-featured graphical interface. +- If you want a nice visual representation of the compile times of your crate graph, + you can use [cargo's `-Ztimings` flag](https://doc.rust-lang.org/cargo/reference/unstable.html#timings), + eg. `cargo -Ztimings build`. + You can use this flag on the compiler itself with `CARGOFLAGS="-Ztimings" ./x.py build` + +## Optimizing rustc's self-compile-times with cargo-llvm-lines + +Using [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines) you can count the +number of lines of LLVM IR across all instantiations of a generic function. +Since most of the time compiling rustc is spent in LLVM, the idea is that by +reducing the amount of code passed to LLVM, compiling rustc gets faster. + +Example usage: +``` +cargo install cargo-llvm-lines +# On a normal crate you could now run `cargo llvm-lines`, but x.py isn't normal :P + +# Do a clean before every run, to not mix in the results from previous runs. +./x.py clean +RUSTFLAGS="--emit=llvm-ir" ./x.py build --stage 0 compiler/rustc + +# Single crate, eg. rustc_middle +cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/rustc_middle* > llvm-lines-middle.txt +# Whole compiler at once +cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/*.ll > llvm-lines.txt +``` + +Example output: +``` + Lines Copies Function name + ----- ------ ------------- + 11802479 (100%) 52848 (100%) (TOTAL) + 1663902 (14.1%) 400 (0.8%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} + 683526 (5.8%) 10579 (20.0%) core::ptr::drop_in_place + 568523 (4.8%) 528 (1.0%) rustc_query_system::query::plumbing::get_query_impl + 472715 (4.0%) 1134 (2.1%) hashbrown::raw::RawTable::reserve_rehash + 306782 (2.6%) 1320 (2.5%) rustc_middle::ty::query::plumbing::::start_query::{{closure}}::{{closure}}::{{closure}} + 212800 (1.8%) 514 (1.0%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl + 194813 (1.7%) 124 (0.2%) rustc_query_system::query::plumbing::force_query_impl + 158488 (1.3%) 1 (0.0%) rustc_middle::ty::query::::alloc_self_profile_query_strings + 119768 (1.0%) 418 (0.8%) core::ops::function::FnOnce::call_once + 119644 (1.0%) 1 (0.0%) rustc_target::spec::load_specific + 104153 (0.9%) 7 (0.0%) rustc_middle::ty::context::_DERIVE_rustc_serialize_Decodable_D_FOR_TypeckResults:: for rustc_middle::ty::context::TypeckResults>::decode::{{closure}} + 81173 (0.7%) 1 (0.0%) rustc_middle::ty::query::stats::query_stats + 80306 (0.7%) 2029 (3.8%) core::ops::function::FnOnce::call_once{{vtable.shim}} + 78019 (0.7%) 1611 (3.0%) stacker::grow::{{closure}} + 69720 (0.6%) 3286 (6.2%) <&T as core::fmt::Debug>::fmt + 56327 (0.5%) 186 (0.4%) rustc_query_system::query::plumbing::incremental_verify_ich + 49714 (0.4%) 14 (0.0%) rustc_mir::dataflow::framework::graphviz::BlockFormatter::write_node_label +``` + +Since this doesn't seem to work with incremental compilation or `x.py check`, +you will be compiling rustc _a lot_. +I recommend changing a few settings in `config.toml` to make it bearable: +``` +[rust] +# A debug build takes _a fourth_ as long on my machine, +# but compiling more than stage0 rustc becomes unbearably slow. +optimize = false + +# We can't use incremental anyway, so we disable it for a little speed boost. +incremental = false +# We won't be running it, so no point in compiling debug checks. +debug = false + +# Caution: This changes the output of llvm-lines. +# Using a single codegen unit gives more accurate output, but is slower to compile. +# Changing it to the number of cores on my machine increased the output +# from 3.5GB to 4.1GB and decreased compile times from 5½ min to 4 min. +codegen-units = 1 +#codegen-units = 0 # num_cpus +``` + +What I'm still not sure about is if inlining in MIR optimizations affect llvm-lines. +The output with `-Zmir-opt-level=0` and `-Zmir-opt-level=1` is the same, +but it feels like that some functions that show up at the top should be to small +to have such a high impact. Inlining should only happens in LLVM though. From f7870395f53fd67f8a69a92b1ea5a08e580be8ce Mon Sep 17 00:00:00 2001 From: Julian Wollersberger Date: Sun, 4 Oct 2020 15:09:06 +0200 Subject: [PATCH 1284/1812] Did more measurements on what exactly affects llvm-lines: optimize, codegen-units and mir-opt do, but debug-assertions doesn't. --- src/profiling.md | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/src/profiling.md b/src/profiling.md index db5806927..e8139dd25 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -21,7 +21,7 @@ Depending on what you're trying to measure, there are several different approach eg. `cargo -Ztimings build`. You can use this flag on the compiler itself with `CARGOFLAGS="-Ztimings" ./x.py build` -## Optimizing rustc's self-compile-times with cargo-llvm-lines +## Optimizing rustc's bootstrap times with `cargo-llvm-lines` Using [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines) you can count the number of lines of LLVM IR across all instantiations of a generic function. @@ -38,8 +38,8 @@ cargo install cargo-llvm-lines RUSTFLAGS="--emit=llvm-ir" ./x.py build --stage 0 compiler/rustc # Single crate, eg. rustc_middle -cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/rustc_middle* > llvm-lines-middle.txt -# Whole compiler at once +cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/rustc_middle-a539a639bdab6513.ll > llvm-lines-middle.txt +# Specify all crates of the compiler. (Relies on the glob support of your shell.) cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/*.ll > llvm-lines.txt ``` @@ -72,7 +72,7 @@ you will be compiling rustc _a lot_. I recommend changing a few settings in `config.toml` to make it bearable: ``` [rust] -# A debug build takes _a fourth_ as long on my machine, +# A debug build takes _a third_ as long on my machine, # but compiling more than stage0 rustc becomes unbearably slow. optimize = false @@ -81,15 +81,14 @@ incremental = false # We won't be running it, so no point in compiling debug checks. debug = false -# Caution: This changes the output of llvm-lines. -# Using a single codegen unit gives more accurate output, but is slower to compile. -# Changing it to the number of cores on my machine increased the output -# from 3.5GB to 4.1GB and decreased compile times from 5½ min to 4 min. -codegen-units = 1 -#codegen-units = 0 # num_cpus +# Using a single codegen unit gives less output, but is slower to compile. +codegen-units = 0 # num_cpus ``` -What I'm still not sure about is if inlining in MIR optimizations affect llvm-lines. -The output with `-Zmir-opt-level=0` and `-Zmir-opt-level=1` is the same, -but it feels like that some functions that show up at the top should be to small -to have such a high impact. Inlining should only happens in LLVM though. +The llvm-lines output is affected by several options. +`optimize = false` increases it from 2.1GB to 3.5GB and `codegen-units = 0` to 4.1GB. + +MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Zmir-opt-level=1"`, +level 0 adds 0.3GB and level 2 removes 0.2GB. +Inlining currently only happens in LLVM, but this might change in the future. + From 9175746a7ed04395b43007230c0cbe4ac32262b3 Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 16 Sep 2020 16:04:40 -0700 Subject: [PATCH 1285/1812] add suggested workflow to setup nightly rustup for rustc --- src/building/suggested.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/building/suggested.md b/src/building/suggested.md index cc8d92a5c..a50d8a932 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -67,6 +67,22 @@ the problem. A nice side-effect of this style is that you are left with a fairly fine-grained set of commits at the end, all of which build and pass tests. This often helps reviewing. +## Configuring `rustup` to use nightly + +Some parts of the bootstrap process uses pinned, nightly versions of tools like +rustfmt. To make things like `cargo fmt` work correctly in your repo, run + +```console +cd +rustup override set nightly +``` + +after [installing a nightly toolchain] with `rustup`. Don't forget to do this for all +directories you have [setup a worktree for]. + +[installing a nightly toolchain]: https://rust-lang.github.io/rustup/concepts/channels.html?highlight=nightl#working-with-nightly-rust +[setup a worktree for]: ./suggested.html#working-on-multiple-branches-at-the-same-time + ## Incremental builds with `--keep-stage`. Sometimes just checking From 1753f0f10d494e1e753c77ca068ff8ee9d620d5c Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 16 Sep 2020 16:15:39 -0700 Subject: [PATCH 1286/1812] add note --- src/building/suggested.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/building/suggested.md b/src/building/suggested.md index a50d8a932..51433c5a1 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -80,8 +80,13 @@ rustup override set nightly after [installing a nightly toolchain] with `rustup`. Don't forget to do this for all directories you have [setup a worktree for]. +**note** see [the section on vscode] for how to configure it with this real rustfmt `x.py` uses, +and [the section on rustup] for how to setup `rustup` toolchain for your bootstrapped compiler + [installing a nightly toolchain]: https://rust-lang.github.io/rustup/concepts/channels.html?highlight=nightl#working-with-nightly-rust [setup a worktree for]: ./suggested.html#working-on-multiple-branches-at-the-same-time +[the section on vscode]: suggested.html#configuring-rust-analyzer-for-rustc +[the section on rustup]: how-to-build-and-run.html?highlight=rustup#creating-a-rustup-toolchain ## Incremental builds with `--keep-stage`. From e5bf7061893c0cad746454d4199934e8756e33db Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 16 Sep 2020 16:42:53 -0700 Subject: [PATCH 1287/1812] Apply suggestions from code review Co-authored-by: Joshua Nelson --- src/building/suggested.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 51433c5a1..1091245ec 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -80,9 +80,11 @@ rustup override set nightly after [installing a nightly toolchain] with `rustup`. Don't forget to do this for all directories you have [setup a worktree for]. -**note** see [the section on vscode] for how to configure it with this real rustfmt `x.py` uses, +**Note** see [the section on vscode] for how to configure it with this real rustfmt `x.py` uses, and [the section on rustup] for how to setup `rustup` toolchain for your bootstrapped compiler +**Note** This does _not_ allow you to build `rustc` with cargo directly. You still have to use `x.py` to work on the compiler or standard library, this just lets you use `cargo fmt`. + [installing a nightly toolchain]: https://rust-lang.github.io/rustup/concepts/channels.html?highlight=nightl#working-with-nightly-rust [setup a worktree for]: ./suggested.html#working-on-multiple-branches-at-the-same-time [the section on vscode]: suggested.html#configuring-rust-analyzer-for-rustc From 3f853d5a30507cd0806232d9747e10cc411fb7ea Mon Sep 17 00:00:00 2001 From: mark Date: Sat, 3 Oct 2020 19:31:44 -0500 Subject: [PATCH 1288/1812] address lingering reviewer comments --- src/building/suggested.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 1091245ec..112aedd98 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -1,6 +1,6 @@ # Suggested Workflows -The full bootstrapping process takes quite a while. Here are five suggestions +The full bootstrapping process takes quite a while. Here are some suggestions to make your life easier. ## Configuring `rust-analyzer` for `rustc` @@ -78,12 +78,16 @@ rustup override set nightly ``` after [installing a nightly toolchain] with `rustup`. Don't forget to do this for all -directories you have [setup a worktree for]. +directories you have [setup a worktree for]. You may need to use the pinned +nightly version from `src/stage0.txt`, but often the normal `nightly` channel +will work. **Note** see [the section on vscode] for how to configure it with this real rustfmt `x.py` uses, and [the section on rustup] for how to setup `rustup` toolchain for your bootstrapped compiler -**Note** This does _not_ allow you to build `rustc` with cargo directly. You still have to use `x.py` to work on the compiler or standard library, this just lets you use `cargo fmt`. +**Note** This does _not_ allow you to build `rustc` with cargo directly. You +still have to use `x.py` to work on the compiler or standard library, this just +lets you use `cargo fmt`. [installing a nightly toolchain]: https://rust-lang.github.io/rustup/concepts/channels.html?highlight=nightl#working-with-nightly-rust [setup a worktree for]: ./suggested.html#working-on-multiple-branches-at-the-same-time From 5b895d7040f9170d4e9112240454080628474ee1 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Sat, 3 Oct 2020 19:35:37 -0500 Subject: [PATCH 1289/1812] Link to .md files, rather than .html Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/building/suggested.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 112aedd98..2ebdecd07 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -90,9 +90,9 @@ still have to use `x.py` to work on the compiler or standard library, this just lets you use `cargo fmt`. [installing a nightly toolchain]: https://rust-lang.github.io/rustup/concepts/channels.html?highlight=nightl#working-with-nightly-rust -[setup a worktree for]: ./suggested.html#working-on-multiple-branches-at-the-same-time -[the section on vscode]: suggested.html#configuring-rust-analyzer-for-rustc -[the section on rustup]: how-to-build-and-run.html?highlight=rustup#creating-a-rustup-toolchain +[setup a worktree for]: ./suggested.md#working-on-multiple-branches-at-the-same-time +[the section on vscode]: suggested.md#configuring-rust-analyzer-for-rustc +[the section on rustup]: how-to-build-and-run.md?highlight=rustup#creating-a-rustup-toolchain ## Incremental builds with `--keep-stage`. From 10878783ce24be8339969f99f8d587a6f1619704 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 4 Oct 2020 10:25:02 -0400 Subject: [PATCH 1290/1812] Explain stages in terms of the compiler currently running (take N+1) (#857) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Explain stages in terms of the compiler currently running - Address some confusing points + stage N+1 -> stage N artifacts + Use more likely examples of an ABI break + stage N -> stage N compiler - Mention why rustc occasionally uses `cfg(bootstrap)` - Note that stage1 is built using two different versions - Add lots of examples + `test src/test/ui` and `test compiler/rustc` run different compilers 😢 + Separate examples of what to do from examples of what not to do - 'ship stage 1 artifacts' -> 'ship stage 2 compiler' This is hopefully less confusing. * build -> x.py build * Add section on build artifacts * Improve wording Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> * uplifted -> assembled Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/building/bootstrapping.md | 241 ++++++++++++++++++---------------- 1 file changed, 127 insertions(+), 114 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 7116d908a..24f86d940 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -14,7 +14,7 @@ It must have been written in a different language. In Rust's case it was only way to build a modern version of rustc is a slightly less modern version. -This is exactly how `x.py` works: it downloads the current `beta` release of +This is exactly how `x.py` works: it downloads the current beta release of rustc, then uses it to compile the new compiler. ## Stages of bootstrapping @@ -71,6 +71,8 @@ These defaults are as follows: You can always override the stage by passing `--stage N` explicitly. +For more information about stages, [see below](#understanding-stages-of-bootstrap). + ## Complications of bootstrapping Since the build system uses the current beta compiler to build the stage-1 @@ -122,43 +124,76 @@ contribution [here][bootstrap-build]. ## Understanding stages of bootstrap -This is a detailed look into the separate bootstrap stages. When running -`x.py` you will see output such as: - -```txt -Building stage0 std artifacts -Copying stage0 std from stage0 -Building stage0 compiler artifacts -Copying stage0 rustc from stage0 -Building LLVM for x86_64-apple-darwin -Building stage0 codegen artifacts -Assembling stage1 compiler -Building stage1 std artifacts -Copying stage1 std from stage1 -Building stage1 compiler artifacts -Copying stage1 rustc from stage1 -Building stage1 codegen artifacts -Assembling stage2 compiler -Uplifting stage1 std -Copying stage2 std from stage1 -Generating unstable book md files -Building stage0 tool unstable-book-gen -Building stage0 tool rustbook -Documenting standalone -Building rustdoc for stage2 -Documenting book redirect pages -Documenting stage2 std -Building rustdoc for stage1 -Documenting stage2 whitelisted compiler -Documenting stage2 compiler -Documenting stage2 rustdoc -Documenting error index -Uplifting stage1 rustc -Copying stage2 rustc from stage1 -Building stage2 tool error_index_generator -``` +### Overview + +This is a detailed look into the separate bootstrap stages. + +The convention `x.py` uses is that: +- A `--stage N` flag means to run the stage N compiler (`stageN/rustc`). +- A "stage N artifact" is a build artifact that is _produced_ by the stage N compiler. +- The "stage (N+1) compiler" is assembled from "stage N artifacts". This + process is called _uplifting_. + +#### Build artifacts + +Anything you can build with `x.py` is a _build artifact_. +Build artifacts include, but are not limited to: + +- binaries, like `stage0-rustc/rustc-main` +- shared objects, like `stage0-sysroot/rustlib/libstd-6fae108520cf72fe.so` +- [rlib] files, like `stage0-sysroot/rustlib/libstd-6fae108520cf72fe.rlib` +- HTML files generated by rustdoc, like `doc/std` + +[rlib]: ../serialization.md + +#### Examples + +- `x.py build --stage 0` means to build with the beta `rustc`. +- `x.py doc --stage 0` means to document using the beta `rustdoc`. +- `x.py test --stage 0 library/std` means to run tests on the standard library + without building `rustc` from source ('build with stage 0, then test the + artifacts'). If you're working on the standard library, this is normally the + test command you want. +- `x.py test src/test/ui` means to build the stage 1 compiler and run + `compiletest` on it. If you're working on the compiler, this is normally the + test command you want. + +#### Examples of what *not* to do + +- `x.py test --stage 0 src/test/ui` is not meaningful: it runs tests on the + _beta_ compiler and doesn't build `rustc` from source. Use `test src/test/ui` + instead, which builds stage 1 from source. +- `x.py test --stage 0 compiler/rustc` builds the compiler but runs no tests: + it's running `cargo test -p rustc`, but cargo doesn't understand Rust's + tests. You shouldn't need to use this, use `test` instead (without arguments). +- `x.py build --stage 0 compiler/rustc` builds the compiler, but does not make + it usable: the build artifacts are not assembled into the final compiler + ([#73519]). Use `x.py build library/std` instead, which puts the compiler in + `stage1/rustc`. + +[#73519]: https://github.com/rust-lang/rust/issues/73519 + +### Building vs. Running + -A deeper look into `x.py`'s phases can be seen here: +Note that `build --stage N compiler/rustc` **does not** build the stage N compiler: +instead it builds the stage _N+1_ compiler _using_ the stage N compiler. + +In short, _stage 0 uses the stage0 compiler to create stage0 artifacts which +will later be uplifted to be the stage1 compiler_. + +In each stage, two major steps are performed: + +1. `std` is compiled by the stage N compiler. +2. That `std` is linked to programs built by the stage N compiler, including + the stage N artifacts (stage (N+1) compiler). + +This is somewhat intuitive if one thinks of the stage N artifacts as "just" +another program we are building with the stage N compiler: +`build --stage N compiler/rustc` is linking the stage N artifacts to the `std` +built by the stage N compiler. + +Here is a chart of a full build using `x.py`: A diagram of the rustc compilation phases @@ -166,6 +201,58 @@ Keep in mind this diagram is a simplification, i.e. `rustdoc` can be built at different stages, the process is a bit different when passing flags such as `--keep-stage`, or if there are non-host targets. +The stage 2 compiler is what is shipped to end-users. + +### Stages and `std` + +Note that there are two `std` libraries in play here: +1. The library _linked_ to `stageN/rustc`, which was built by stage N-1 (stage N-1 `std`) +2. The library _used to compile programs_ with `stageN/rustc`, which was + built by stage N (stage N `std`). + +Stage N `std` is pretty much necessary for any useful work with the stage N compiler. +Without it, you can only compile programs with `#![no_core]` -- not terribly useful! + +The reason these need to be different is because they aren't necessarily ABI-compatible: +there could be a new layout optimizations, changes to MIR, or other changes +to Rust metadata on nightly that aren't present in beta. + +This is also where `--keep-stage 1 library/std` comes into play. Since most +changes to the compiler don't actually change the ABI, once you've produced a +`std` in stage 1, you can probably just reuse it with a different compiler. +If the ABI hasn't changed, you're good to go, no need to spend time +recompiling that `std`. +`--keep-stage` simply assumes the previous compile is fine and copies those +artifacts into the appropriate place, skipping the cargo invocation. + +### Cross-compiling + +Building stage2 `std` is different depending on whether you are cross-compiling or not +(see in the table how stage2 only builds non-host `std` targets). +This is because `x.py` uses a trick: if `HOST` and `TARGET` are the same, +it will reuse stage1 `std` for stage2! This is sound because stage1 `std` +was compiled with the stage1 compiler, i.e. a compiler using the source code +you currently have checked out. So it should be identical (and therefore ABI-compatible) +to the `std` that `stage2/rustc` would compile. + +However, when cross-compiling, stage1 `std` will only run on the host. +So the stage2 compiler has to recompile `std` for the target. + +### Why does only libstd use `cfg(bootstrap)`? + +The `rustc` generated by the stage0 compiler is linked to the freshly-built +`std`, which means that for the most part only `std` needs to be cfg-gated, +so that `rustc` can use features added to std immediately after their addition, +without need for them to get into the downloaded beta. + +Note this is different from any other Rust program: stage1 `rustc` +is built by the _beta_ compiler, but using the _master_ version of libstd! + +The only time `rustc` uses `cfg(bootstrap)` is when it adds internal lints +that use diagnostic items. This happens very rarely. + +### Directories and artifacts generated by x.py + The following tables indicate the outputs of various stage actions: | Stage 0 Action | Output | @@ -178,7 +265,7 @@ The following tables indicate the outputs of various stage actions: | copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | | build `llvm` | `build/HOST/llvm` | | `stage0` builds `codegen` with `stage0-sysroot` | `build/HOST/stage0-codegen/HOST` | -| `stage0` builds `rustdoc` with `stage0-sysroot` | `build/HOST/stage0-tools/HOST` | +| `stage0` builds `rustdoc`, `clippy`, `miri`, with `stage0-sysroot` | `build/HOST/stage0-tools/HOST` | `--stage=0` stops here. @@ -201,85 +288,11 @@ The following tables indicate the outputs of various stage actions: | copy (uplift) `stage1-sysroot` | `build/HOST/stage2/lib and build/HOST/stage2/lib/rustlib/HOST` | | `stage2` builds `test`/`std` (not HOST targets) | `build/HOST/stage2-std/TARGET` | | copy `stage2-std` (not HOST targets) | `build/HOST/stage2/lib/rustlib/TARGET` | -| `stage2` builds `rustdoc` | `build/HOST/stage2-tools/HOST` | +| `stage2` builds `rustdoc`, `clippy`, `miri` | `build/HOST/stage2-tools/HOST` | | copy `rustdoc` | `build/HOST/stage2/bin` | `--stage=2` stops here. -Note that the convention `x.py` uses is that: -- A "stage N artifact" is an artifact that is _produced_ by the stage N compiler. -- The "stage (N+1) compiler" is assembled from "stage N artifacts". -- A `--stage N` flag means build _with_ stage N. - -In short, _stage 0 uses the stage0 compiler to create stage0 artifacts which -will later be uplifted to stage1_. - -Every time any of the main artifacts (`std` and `rustc`) are compiled, two -steps are performed. -When `std` is compiled by a stage N compiler, that `std` will be linked to -programs built by the stage N compiler (including `rustc` built later -on). It will also be used by the stage (N+1) compiler to link against itself. -This is somewhat intuitive if one thinks of the stage (N+1) compiler as "just" -another program we are building with the stage N compiler. In some ways, `rustc` -(the binary, not the `rustbuild` step) could be thought of as one of the few -`no_core` binaries out there. - -So "stage0 std artifacts" are in fact the output of the downloaded stage0 -compiler, and are going to be used for anything built by the stage0 compiler: -e.g. `rustc` artifacts. When it announces that it is "building stage1 -std artifacts" it has moved on to the next bootstrapping phase. This pattern -continues in latter stages. - -Also note that building host `std` and target `std` are different based on the -stage (e.g. see in the table how stage2 only builds non-host `std` targets. -This is because during stage2, the host `std` is uplifted from the "stage 1" -`std` -- specifically, when "Building stage 1 artifacts" is announced, it is -later copied into stage2 as well (both the compiler's `libdir` and the -`sysroot`). - -This `std` is pretty much necessary for any useful work with the compiler. -Specifically, it's used as the `std` for programs compiled by the newly compiled -compiler (so when you compile `fn main() { }` it is linked to the last `std` -compiled with `x.py build library/std`). - -The `rustc` generated by the stage0 compiler is linked to the freshly-built -`std`, which means that for the most part only `std` needs to be cfg-gated, -so that `rustc` can use featured added to std immediately after their addition, -without need for them to get into the downloaded beta. The `std` built by the -`stage1/bin/rustc` compiler, also known as "stage1 std artifacts", is not -necessarily ABI-compatible with that compiler. -That is, the `rustc` binary most likely could not use this `std` itself. -It is however ABI-compatible with any programs that the `stage1/bin/rustc` -binary builds (including itself), so in that sense they're paired. - -This is also where `--keep-stage 1 library/std` comes into play. Since most -changes to the compiler don't actually change the ABI, once you've produced a -`std` in stage 1, you can probably just reuse it with a different compiler. -If the ABI hasn't changed, you're good to go, no need to spend the time -recompiling that `std`. -`--keep-stage` simply assumes the previous compile is fine and copies those -artifacts into the appropriate place, skipping the cargo invocation. - -The reason we first build `std`, then `rustc`, is largely just -because we want to minimize `cfg(stage0)` in the code for `rustc`. -Currently `rustc` is always linked against a "new" `std` so it doesn't -ever need to be concerned with differences in std; it can assume that the std is -as fresh as possible. - -The reason we need to build it twice is because of ABI compatibility. -The beta compiler has it's own ABI, and then the `stage1/bin/rustc` compiler -will produce programs/libraries with the new ABI. -We used to build three times, but because we assume that the ABI is constant -within a codebase, we presume that the libraries produced by the "stage2" -compiler (produced by the `stage1/bin/rustc` compiler) is ABI-compatible with -the `stage1/bin/rustc` compiler's produced libraries. -What this means is that we can skip that final compilation -- and simply use the -same libraries as the `stage2/bin/rustc` compiler uses itself for programs it -links against. - -This `stage2/bin/rustc` compiler is shipped to end-users, along with the -`stage 1 {std,rustc}` artifacts. - ## Passing stage-specific flags to `rustc` `x.py` allows you to pass stage-specific flags to `rustc` when bootstrapping. @@ -287,7 +300,7 @@ The `RUSTFLAGS_STAGE_0`, `RUSTFLAGS_STAGE_1` and `RUSTFLAGS_STAGE_2` environment variables pass the given flags when building stage 0, 1, and 2 artifacts respectively. -Additionally, the `RUSTFLAGS_STAGE_NOT_0` variable, as its name suggests, pass +Additionally, the `RUSTFLAGS_STAGE_NOT_0` variable, as its name suggests, passes the given arguments if the stage is not 0. ## Environment Variables From 5ee77badd1ed21da22807902f5395f00441f6a32 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sun, 4 Oct 2020 16:18:37 +0200 Subject: [PATCH 1291/1812] Allow anyone to change the status of a PR --- triagebot.toml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/triagebot.toml b/triagebot.toml index fa0824ac5..ccb0de862 100644 --- a/triagebot.toml +++ b/triagebot.toml @@ -1 +1,8 @@ [assign] + +[relabel] +allow-unauthenticated = [ + "waiting-on-review", + "waiting-on-author", + "blocked", +] From d4581a56ae7b16c258b7e43b21d9caacc66e9ff4 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 4 Oct 2020 10:44:03 -0400 Subject: [PATCH 1292/1812] Document `Assemble` --- src/building/bootstrapping.md | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 24f86d940..2da4d2e46 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -146,6 +146,20 @@ Build artifacts include, but are not limited to: [rlib]: ../serialization.md +#### Assembling the compiler + +There is a separate step between building the compiler and making it possible +to run. This step is called _assembling_ or _uplifting_ the compiler. It copies +all the necessary build artifacts from `build/stageN-sysroot` to +`build/stage(N+1)`, which allows you to use `build/stage(N+1)` as a [toolchain] +with `rustup toolchain link`. + +There is [no way to trigger this step on its own][#73519], but `x.py` will +perform it automatically any time you build with stage N+1. + +[toolchain]: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#creating-a-rustup-toolchain +[#73519]: https://github.com/rust-lang/rust/issues/73519 + #### Examples - `x.py build --stage 0` means to build with the beta `rustc`. @@ -166,12 +180,11 @@ Build artifacts include, but are not limited to: - `x.py test --stage 0 compiler/rustc` builds the compiler but runs no tests: it's running `cargo test -p rustc`, but cargo doesn't understand Rust's tests. You shouldn't need to use this, use `test` instead (without arguments). -- `x.py build --stage 0 compiler/rustc` builds the compiler, but does not make - it usable: the build artifacts are not assembled into the final compiler - ([#73519]). Use `x.py build library/std` instead, which puts the compiler in - `stage1/rustc`. +- `x.py build --stage 0 compiler/rustc` builds the compiler, but does + not [assemble] it. Use `x.py build library/std` instead, which puts the + compiler in `stage1/rustc`. -[#73519]: https://github.com/rust-lang/rust/issues/73519 +[assemble]: #assembling-the-compiler ### Building vs. Running From b8cc0a5355526ebd78d56722c1f05c0948995660 Mon Sep 17 00:00:00 2001 From: Cass Date: Fri, 4 Sep 2020 21:13:46 -0400 Subject: [PATCH 1293/1812] Add section describing git hook functionality This is a companion to [this PR](https://github.com/rust-lang/rust/pull/76356), which deals with including functionality for automatically running `tidy --bless` on each commit. Undo editor auto-formatting and clarify git hook renaming a word Phrasing Apply suggestions from code review Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com> --- src/building/suggested.md | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 2ebdecd07..58996e639 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -3,6 +3,19 @@ The full bootstrapping process takes quite a while. Here are some suggestions to make your life easier. +## Installing a pre-commit hook + +CI will automatically fail your build if it doesn't pass `tidy`, our +internal tool for ensuring code quality. If you'd like, you can install a +[Git hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) +that will automatically run `x.py test tidy --bless` on each commit, to ensure +your code is up to par. If you decide later that this behavior is +undesirable, you can delete the `pre-commit` file in `.git/hooks`. + +A prebuilt git hook lives at [`src/etc/pre-commit.sh`](https://github.com/rust-lang/rust/blob/master/src/etc/pre-commit.sh) which can be copied into your `.git/hooks` folder as `pre-commit` (without the `.sh` extension!). + +You can also install the hook as a step of running `x.py setup`! + ## Configuring `rust-analyzer` for `rustc` `rust-analyzer` can help you check and format your code whenever you save @@ -82,7 +95,7 @@ directories you have [setup a worktree for]. You may need to use the pinned nightly version from `src/stage0.txt`, but often the normal `nightly` channel will work. -**Note** see [the section on vscode] for how to configure it with this real rustfmt `x.py` uses, +**Note** see [the section on vscode] for how to configure it with this real rustfmt `x.py` uses, and [the section on rustup] for how to setup `rustup` toolchain for your bootstrapped compiler **Note** This does _not_ allow you to build `rustc` with cargo directly. You @@ -100,7 +113,7 @@ Sometimes just checking whether the compiler builds is not enough. A common example is that you need to add a `debug!` statement to inspect the value of some state or better understand the problem. In that case, you really need -a full build. By leveraging incremental, though, you can often get +a full build. By leveraging incremental, though, you can often get these builds to complete very fast (e.g., around 30 seconds). The only catch is this requires a bit of fudging and may produce compilers that don't work (but that is easily detected and fixed). @@ -118,10 +131,10 @@ The sequence of commands you want is as follows: [documented previously]: ./how-to-build-and-run.md#building-the-compiler -As mentioned, the effect of `--keep-stage 1` is that we just *assume* that the +As mentioned, the effect of `--keep-stage 1` is that we just _assume_ that the old standard library can be re-used. If you are editing the compiler, this is almost always true: you haven't changed the standard library, after -all. But sometimes, it's not true: for example, if you are editing +all. But sometimes, it's not true: for example, if you are editing the "metadata" part of the compiler, which controls how the compiler encodes types and other states into the `rlib` files, or if you are editing things that wind up in the metadata (such as the definition of @@ -131,7 +144,7 @@ the MIR). using `--keep-stage 1`** -- for example, strange [ICEs](../appendix/glossary.html#ice) or other panics. In that case, you should simply remove the `--keep-stage 1` from the command and -rebuild. That ought to fix the problem. +rebuild. That ought to fix the problem. You can also use `--keep-stage 1` when running tests. Something like this: @@ -147,6 +160,7 @@ crates you'll have to rebuild For example, when working on `rustc_mir_build`, the `rustc_mir_build` and `rustc_driver` crates take the most time to incrementally rebuild. You could therefore set the following in the root `Cargo.toml`: + ```toml [profile.release.package.rustc_mir_build] opt-level = 0 @@ -218,6 +232,6 @@ Note that you need to have the LLVM `FileCheck` tool installed, which is used for codegen tests. This tool is normally built with LLVM, but if you use your own preinstalled LLVM, you will need to provide `FileCheck` in some other way. On Debian-based systems, you can install the `llvm-N-tools` package (where `N` -is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify +is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify the path to `FileCheck` with the `llvm-filecheck` config item in `config.toml` or you can disable codegen test with the `codegen-tests` item in `config.toml`. From 2e8a3e8f6d4988c321fbd0d4dd84776a38d586b2 Mon Sep 17 00:00:00 2001 From: mautamu <2220164+mautamu@users.noreply.github.com> Date: Thu, 8 Oct 2020 02:19:56 -0500 Subject: [PATCH 1294/1812] Fix typos (#916) Fixed two typos. --- src/rustbot.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rustbot.md b/src/rustbot.md index 53211f297..8e952c3f2 100644 --- a/src/rustbot.md +++ b/src/rustbot.md @@ -3,7 +3,7 @@ `@rustbot` (also known as `triagebot`) is a utility robot that is mostly used to allow any contributor to achieve certain tasks that would normally require GitHub membership to the `rust-lang` organization. Its most interesting features for -contributors to `rustc` are isssue claiming and relabeling. +contributors to `rustc` are issue claiming and relabeling. ## Issue claiming @@ -24,7 +24,7 @@ If you want to unassign from an issue, `@rustbot` has a different command: ## Issue relabeling -Changing labels for an issue or PR is also normally reserved to members of the +Changing labels for an issue or PR is also normally reserved for members of the organization. However, `@rustbot` allows you to relabel an issue yourself, only with a few restrictions. This is mostly useful in two cases: From e912d1904b7bf7595d5321379fc5559374fab6db Mon Sep 17 00:00:00 2001 From: Stu Date: Thu, 8 Oct 2020 17:38:40 +0200 Subject: [PATCH 1295/1812] Fix broken "system LLVM" link --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 5837e9423..c13d4f044 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -150,7 +150,7 @@ For more suggestions, see https://rustc-dev-guide.rust-lang.org/building/suggest You may also want to set up [system LLVM][sysllvm] to avoid building LLVM from source. -[sysllvm]: ./building/suggested.html#building-with-system-llvm +[sysllvm]: ./building/suggested.html#skipping-llvm-build ### `./x.py` Intro From 95b1f2b08e420b2de024741397b2049d2ea280a2 Mon Sep 17 00:00:00 2001 From: Justus K Date: Thu, 8 Oct 2020 17:41:37 +0200 Subject: [PATCH 1296/1812] Update more occurrences of system llvm link --- src/building/new-target.md | 2 +- src/building/prerequisites.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/new-target.md b/src/building/new-target.md index 3bb77f7fc..4873e6652 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -28,7 +28,7 @@ If you have a local LLVM checkout that is already built, you *may* be able to configure Rust to treat your build as the [system LLVM][sysllvm] to avoid redundant builds. -[sysllvm]: ./suggested.md#building-with-system-llvm +[sysllvm]: ./suggested.md#skipping-llvm-build ## Creating a target specification diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index 63d5aca8e..00692fda9 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -19,7 +19,7 @@ If building LLVM from source (the default), you'll need additional tools: Otherwise, you'll need LLVM installed and `llvm-config` in your path. See [this section for more info][sysllvm]. -[sysllvm]: ./suggested.md#building-with-system-llvm +[sysllvm]: ./suggested.md#skipping-llvm-build ### Windows From 0419c55271e5c6e330bf7c4a08929ef4e55811d4 Mon Sep 17 00:00:00 2001 From: mark Date: Mon, 5 Oct 2020 13:23:14 -0500 Subject: [PATCH 1297/1812] linkcheck only for changed files except in cron jobs --- .travis.yml | 2 +- book.toml | 1 + ci/linkcheck.sh | 20 ++++++++++++++++++++ 3 files changed, 22 insertions(+), 1 deletion(-) create mode 100755 ci/linkcheck.sh diff --git a/.travis.yml b/.travis.yml index fba5ab87e..3e4a3dc0d 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,7 +12,7 @@ before_install: install: - source ~/.cargo/env || true - cargo install mdbook --version '^0.4.3' -- cargo install mdbook-linkcheck --version '^0.7.0' +- cargo install mdbook-linkcheck --git https://github.com/Michael-F-Bryan/mdbook-linkcheck script: - git checkout -b ci - git rebase origin/master diff --git a/book.toml b/book.toml index 10bc2edd4..af909446a 100644 --- a/book.toml +++ b/book.toml @@ -14,6 +14,7 @@ enable = true level = 0 [output.linkcheck] +command = "../../ci/linkcheck.sh" follow-web-links = true exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il", "www\\.amazon\\.com", "www\\.rustaceans\\.org" ] cache-timeout = 86400 diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh new file mode 100755 index 000000000..85573314c --- /dev/null +++ b/ci/linkcheck.sh @@ -0,0 +1,20 @@ +#!/usr/bin/env bash + +if [ "$TRAVIS_EVENT_TYPE" = "cron" ] ; then # running in cron job + FLAGS="" + + echo "Doing full link check." +elif [ "$CI" = "true" ] ; then # running in PR CI build + CHANGED_FILES=$(git diff --name-only $TRAVIS_COMMIT_RANGE | tr '\n' ' ') + FLAGS="-f $CHANGED_FILES" + + echo "Checking files changed in $TRAVIS_COMMIT_RANGE: $CHANGED_FILES" +else # running locally + COMMIT_RANGE=master... + CHANGED_FILES=$(git diff --name-only $COMMIT_RANGE | tr '\n' ' ') + FLAGS="-f $CHANGED_FILES" + + echo "Checking files changed in $COMMIT_RANGE: $CHANGED_FILES" +fi + +exec mdbook-linkcheck $FLAGS -- $TRAVIS_BUILD_DIR From 728c06bc5a2d241b52a3ea2df53adc7040b66bc0 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 7 Oct 2020 03:10:35 -0500 Subject: [PATCH 1298/1812] pin mdbook-linkcheck version --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 3e4a3dc0d..395334e5c 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,7 +12,7 @@ before_install: install: - source ~/.cargo/env || true - cargo install mdbook --version '^0.4.3' -- cargo install mdbook-linkcheck --git https://github.com/Michael-F-Bryan/mdbook-linkcheck +- cargo install mdbook-linkcheck --git https://github.com/Michael-F-Bryan/mdbook-linkcheck --rev 14441d77646d58cea8ffc32fde9ea33b2bedb1a2 script: - git checkout -b ci - git rebase origin/master From 19f70c2e6071665e6ec880eac7531d3220de37be Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Wed, 7 Oct 2020 23:01:20 -0500 Subject: [PATCH 1299/1812] Add comment referring to travis docs Co-authored-by: Joshua Nelson --- ci/linkcheck.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index 85573314c..7149ab3a7 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -1,5 +1,6 @@ #!/usr/bin/env bash +# https://docs.travis-ci.com/user/environment-variables/#default-environment-variables if [ "$TRAVIS_EVENT_TYPE" = "cron" ] ; then # running in cron job FLAGS="" From 6361b425d86ac9fd9f203c5482eb573fc11ab8ee Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Oct 2020 15:15:58 -0500 Subject: [PATCH 1300/1812] More debuggable bash settings Co-authored-by: Joshua Nelson --- ci/linkcheck.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index 7149ab3a7..a1cd424fb 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -1,5 +1,8 @@ #!/usr/bin/env bash +set -ev +set -o pipefail + # https://docs.travis-ci.com/user/environment-variables/#default-environment-variables if [ "$TRAVIS_EVENT_TYPE" = "cron" ] ; then # running in cron job FLAGS="" From d3134dd9a912f7bcbc9372dff841298a0098163f Mon Sep 17 00:00:00 2001 From: mark Date: Thu, 8 Oct 2020 15:54:29 -0500 Subject: [PATCH 1301/1812] add assert --- ci/linkcheck.sh | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index a1cd424fb..db6b35a5b 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -9,6 +9,11 @@ if [ "$TRAVIS_EVENT_TYPE" = "cron" ] ; then # running in cron job echo "Doing full link check." elif [ "$CI" = "true" ] ; then # running in PR CI build + if [ -n "$TRAVIS_COMMIT_RANGE" ]; then + echo "error: unexpected state: COMMIT_RANGE must be non-empty in CI" + exit 1 + fi + CHANGED_FILES=$(git diff --name-only $TRAVIS_COMMIT_RANGE | tr '\n' ' ') FLAGS="-f $CHANGED_FILES" From 28a5c3588d73d1e9c61b5129ab268b012f67a0d8 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Oct 2020 16:08:25 -0500 Subject: [PATCH 1302/1812] Lol logic is hard Co-authored-by: Joshua Nelson --- ci/linkcheck.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index db6b35a5b..6979e9867 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -9,7 +9,7 @@ if [ "$TRAVIS_EVENT_TYPE" = "cron" ] ; then # running in cron job echo "Doing full link check." elif [ "$CI" = "true" ] ; then # running in PR CI build - if [ -n "$TRAVIS_COMMIT_RANGE" ]; then + if [ -z "$TRAVIS_COMMIT_RANGE" ]; then echo "error: unexpected state: COMMIT_RANGE must be non-empty in CI" exit 1 fi From 647d5620f9b7ce6feb195bfe09a7e353e397ca3d Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Thu, 8 Oct 2020 16:08:42 -0500 Subject: [PATCH 1303/1812] Better error message Co-authored-by: Camelid --- ci/linkcheck.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index 6979e9867..d827b8476 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -10,7 +10,7 @@ if [ "$TRAVIS_EVENT_TYPE" = "cron" ] ; then # running in cron job echo "Doing full link check." elif [ "$CI" = "true" ] ; then # running in PR CI build if [ -z "$TRAVIS_COMMIT_RANGE" ]; then - echo "error: unexpected state: COMMIT_RANGE must be non-empty in CI" + echo "error: unexpected state: TRAVIS_COMMIT_RANGE must be non-empty in CI" exit 1 fi From d1e314f53ebae543e5491c5b0587452345c2365c Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 8 Oct 2020 09:28:53 -0400 Subject: [PATCH 1304/1812] Recommend debug-logging instead of debug This makes the compiler faster to running without sacrificing too much performance. It still shows logging so contributors aren't confused by `debug!` doing nothing. --- src/building/how-to-build-and-run.md | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 177fa20d2..0195659ac 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -37,28 +37,15 @@ settings (and possibly others, such as `llvm.ccache`): assertions = true [rust] -# Indicates that the build should be configured for debugging Rust. A -# `debug`-enabled compiler and standard library will be somewhat -# slower (due to e.g. checking of debug assertions) but should remain -# usable. +# Whether or not to leave debug! and trace! calls in the rust binary. +# Overrides the `debug-assertions` option, if defined. # -# Note: If this value is set to `true`, it will affect a number of -# configuration options below as well, if they have been left -# unconfigured in this file. +# Defaults to rust.debug-assertions value # -# Note: changes to the `debug` setting do *not* affect `optimize` -# above. In theory, a "maximally debuggable" environment would -# set `optimize` to `false` above to assist the introspection -# facilities of debuggers like lldb and gdb. To recreate such an -# environment, explicitly set `optimize` to `false` and `debug` -# to `true`. In practice, everyone leaves `optimize` set to -# `true`, because an unoptimized rustc with debugging -# enabled becomes *unusably slow* (e.g. rust-lang/rust#24840 -# reported a 25x slowdown) and bootstrapping the supposed -# "maximally debuggable" environment (notably std) takes -# hours to build. -# -debug = true +# If you see a message from `tracing` saying +# `max_level_info` is enabled and means logging won't be shown, +# set this value to `true`. +debug-logging = true # Whether to always use incremental compilation when building rustc incremental = true From 3f9812cfaa47f7d4616d8d8f4ce858fa80c722d8 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Thu, 8 Oct 2020 00:04:54 +0200 Subject: [PATCH 1305/1812] Talk about git submodules --- src/git.md | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/src/git.md b/src/git.md index 633e7d572..f9a6fca44 100644 --- a/src/git.md +++ b/src/git.md @@ -73,6 +73,30 @@ the same, with some steps skipped: 2. Make, stage, and commit your additional changes just like before. 3. Push those changes to your fork: `git push`. +### Quick note about submodules + +When updating your local repository with `git pull`, you may notice that sometimes +Git says you have modified some files that you have never edited. For example, +running `git status` gives you something like (note the `new commits` mention): + +``` +On branch master +Your branch is up to date with 'origin/master'. + +Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git restore ..." to discard changes in working directory) + modified: src/tools/cargo (new commits) + modified: src/tools/rls (new commits) + modified: src/tools/rustfmt (new commits) + +no changes added to commit (use "git add" and/or "git commit -a") +``` + +These changes are not changes to files: they are changes to submodules +(more on this later). To get rid of those, run `git submodule update` (or run any +`x.py` command which will automatically update the submodules). + ## Conflicts When you edit your code locally, you are making changes to the version of @@ -190,3 +214,54 @@ There are a number of reasons for this decision and like all others, it is a tradeoff. The main advantage is the generally linear commit history. This greatly simplifies bisecting and makes the history and commit log much easier to follow and understand. + +## Git submodules + +**NOTE**: submodules are a nice thing to know about, but it *isn't* an absolute +prerequisite to contribute to `rustc`. If you are using Git for the first time, +you might want to get used to the main concepts of Git before reading this section. + +The `rust-lang/rust` repository uses [Git submodules] as a way to use other +Rust projects from within the `rust` repo. Examples include Rust's fork of +`llvm-project` and many devtools such as `cargo`, `rust-analyzer` and `rustfmt`. + +Those projects are developped and maintained in an separate Git (and GitHub) +repository, and they have their own Git history/commits, issue tracker and PRs. +Submodules allow us to create some sort of embedded sub-repository inside the +`rust` repository and use them like they were directories in the `rust` repository. + +Take `miri` for example. `miri` is maintained in the [`rust-lang/miri`] repository, +but it is used in `rust-lang/rust` by the compiler for const evaluation. We bring it +in `rust` as a submodule, in the `src/tools/miri` folder. + +The contents of submodules are ignored by Git: submodules are in some sense isolated +from the rest of the repository. However, if you try to `cd src/tools/miri` and then +run `git status`: + +``` +HEAD detached at 3fafb835 +nothing to commit, working tree clean +``` + +As far as git is concerned, you are no longer in the `rust` repo, but in the `miri` repo. +You will notice that we are in "detatched HEAD" state, i.e. not on a branch but on a +particular commit. + +This is because, like any dependency, we want to be able to control which version to use. +Submodules allow us to do just that: every submodule is "pinned" to a certain +commit, which doesn't change unless modified manually. If you use `git checkout ` +in the `miri` directory and go back to the `rust` directory, you can stage this +change like any +This is usually done by +the maintainers of the project, and looks like [this][miri-update]. + +Git submodules take some time to get used to, so don't worry if it isn't perfectly +clear yet. You will rarely have to use them directly and, again, you don't need +to know everything about submodules to contribute to Rust. Just know that they +exist and that they correspond to some sort of embedded subrepository dependency +that Git can nicely and fairly conveniently handle for us. + +[Git submodules]: https://git-scm.com/book/en/v2/Git-Tools-Submodules +[`rust-toolstate`]: https://rust-lang-nursery.github.io/rust-toolstate/ +[`rust-lang/miri`]: https://github.com/rust-lang/miri +[miri-update]: https://github.com/rust-lang/rust/pull/77500/files From 50f1e77e4a7482fdaff1176ff92f2e69ced459af Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 10 Oct 2020 17:46:04 +0200 Subject: [PATCH 1306/1812] Apply suggestions from code review Co-authored-by: Joshua Nelson --- src/git.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/git.md b/src/git.md index f9a6fca44..2d2200b3a 100644 --- a/src/git.md +++ b/src/git.md @@ -95,7 +95,18 @@ no changes added to commit (use "git add" and/or "git commit -a") These changes are not changes to files: they are changes to submodules (more on this later). To get rid of those, run `git submodule update` (or run any -`x.py` command which will automatically update the submodules). +`x.py` command, which will automatically update the submodules). +Note that there is currently a bug if you use worktrees, submodules, and x.py in a commit hook. +If you run into an error like: +``` +error: failed to read `/home/joshua/rustc-worktree/src/tools/miri/cargo-miri/Cargo.toml` + +Caused by: + No such file or directory (os error 2) +``` +it's not anything you did wrong. There is a workaround at [#77620]. + +[#77620](https://github.com/rust-lang/rust/issues/77620#issuecomment-705228229) ## Conflicts From 30d4a42313fa0f3cf7c1fc2daab97814f4fac001 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sat, 10 Oct 2020 18:35:25 +0200 Subject: [PATCH 1307/1812] Update installation instructions for `mdbook-linkcheck` --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index aab497af3..8b46b249c 100644 --- a/README.md +++ b/README.md @@ -100,10 +100,11 @@ New-Item -Path .git/hooks/pre-commit -ItemType HardLink -Value cargo install mdbook-linkcheck +> cargo install mdbook-linkcheck --git https://github.com/Michael-F-Bryan/mdbook-linkcheck --rev 14441d77646d58cea8ffc32fde9ea33b2bedb1a2 ``` -You will need `mdbook` version `>= 0.3.5` and `mdbook-linkcheck` version `>= 0.5` to check links. +Note that we use an alpha version of `mdbook-linkcheck` to be able to use a feature that hasn't landed in a release yet. +You will also need `mdbook` version `>= 0.3.5`. `linkcheck` will be run automatically when you build with the instructions in the section above. **Please note**: You may receive errors like the following when link checks are active on local `mdbook` builds: From 60808ea520c23144d7c8136e87a3cea7136ef440 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 11 Oct 2020 11:43:26 -0700 Subject: [PATCH 1308/1812] Use official mdbook-linkcheck version We were using an alpha version before, pinned to a Git hash, so that we could access a new feature (Michael-F-Bryan/mdbook-linkcheck#42). Now there is a point release though (0.7.1), so we can update to that! --- .travis.yml | 2 +- README.md | 7 +++---- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/.travis.yml b/.travis.yml index 395334e5c..de1392e88 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,7 +12,7 @@ before_install: install: - source ~/.cargo/env || true - cargo install mdbook --version '^0.4.3' -- cargo install mdbook-linkcheck --git https://github.com/Michael-F-Bryan/mdbook-linkcheck --rev 14441d77646d58cea8ffc32fde9ea33b2bedb1a2 +- cargo install mdbook-linkcheck --version '^0.7.1' script: - git checkout -b ci - git rebase origin/master diff --git a/README.md b/README.md index 8b46b249c..6bd2177ed 100644 --- a/README.md +++ b/README.md @@ -100,11 +100,10 @@ New-Item -Path .git/hooks/pre-commit -ItemType HardLink -Value cargo install mdbook-linkcheck --git https://github.com/Michael-F-Bryan/mdbook-linkcheck --rev 14441d77646d58cea8ffc32fde9ea33b2bedb1a2 +> cargo install mdbook-linkcheck ``` -Note that we use an alpha version of `mdbook-linkcheck` to be able to use a feature that hasn't landed in a release yet. -You will also need `mdbook` version `>= 0.3.5`. +You will need `mdbook` version `>= 0.3.5` and `mdbook-linkcheck` version `>= 0.7.1` to check links. `linkcheck` will be run automatically when you build with the instructions in the section above. **Please note**: You may receive errors like the following when link checks are active on local `mdbook` builds: @@ -118,7 +117,7 @@ error: The server responded with 429 Too Many Requests for "https://github.com/r │ ^ Server responded with 429 Too Many Requests ``` -There is not a workaround for this error at the moment. Comment out the `[output.linkcheck]` field in the `book.toml` using the build instructions above to complete a local site build without link validations. +There is not a workaround for this error at the moment. Comment out the `[output.linkcheck]` field in the `book.toml` using the build instructions above to complete a local site build without link validations. ## How to fix toolstate failures From db9070f69983a6df06d10bc8575d1c1eb9bc332e Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 11 Oct 2020 14:46:36 -0700 Subject: [PATCH 1309/1812] Mention you will need recent versions of mdbook* --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 6bd2177ed..143ecca16 100644 --- a/README.md +++ b/README.md @@ -103,10 +103,10 @@ We use `mdbook-linkcheck` to validate URLs included in our documentation. To per > cargo install mdbook-linkcheck ``` -You will need `mdbook` version `>= 0.3.5` and `mdbook-linkcheck` version `>= 0.7.1` to check links. +You will need recent versions of `mdbook` and `mdbook-linkcheck` to check links. `linkcheck` will be run automatically when you build with the instructions in the section above. -**Please note**: You may receive errors like the following when link checks are active on local `mdbook` builds: +**Please note**: You may receive errors like the following when link-checking is enabled on local `mdbook` builds: ``` error: The server responded with 429 Too Many Requests for "https://github.com/rust-lang/rust/tree/master/src/tools/compiletest" From f34dd04a39cc0c262c4f53438e8e5714718317a1 Mon Sep 17 00:00:00 2001 From: 1c3t3a <45260993+1c3t3a@users.noreply.github.com> Date: Mon, 12 Oct 2020 18:57:18 +0200 Subject: [PATCH 1310/1812] Added description of word Scrutinee to the glossary (#921) --- src/appendix/glossary.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 007edce8d..842613d25 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -64,6 +64,7 @@ query
| Perhaps some sub-computation during recovery
| Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors). region
| Another term for "lifetime" often used in the literature and in the borrow checker. rib
| A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) +scrutinee | A scrutinee is the expression that is matched on in `match` expressions and similar pattern matching constructs. For example, in `match x { A => 1, B => 2 }`, the expression `x` is the scrutinee. sess
| The compiler session, which stores global data used throughout compilation side tables
| Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil
| Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. From 7f9c36b6a9f1b2160ee71966f986caceaaa6bd55 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 16 Oct 2020 12:00:19 +0900 Subject: [PATCH 1311/1812] Fix a link on git.md --- src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/git.md b/src/git.md index 2d2200b3a..f567188de 100644 --- a/src/git.md +++ b/src/git.md @@ -106,7 +106,7 @@ Caused by: ``` it's not anything you did wrong. There is a workaround at [#77620]. -[#77620](https://github.com/rust-lang/rust/issues/77620#issuecomment-705228229) +[#77620]: https://github.com/rust-lang/rust/issues/77620#issuecomment-705228229 ## Conflicts From ada57a32f282577f47ffdb52ad81861e2bec4a2f Mon Sep 17 00:00:00 2001 From: Nadrieril Date: Fri, 16 Oct 2020 21:59:28 +0100 Subject: [PATCH 1312/1812] Explain pattern exhaustiveness checking --- src/pat-exhaustive-checking.md | 82 +++++++++++++++++++++++++++++++++- 1 file changed, 81 insertions(+), 1 deletion(-) diff --git a/src/pat-exhaustive-checking.md b/src/pat-exhaustive-checking.md index b29bb1351..da4dab3bf 100644 --- a/src/pat-exhaustive-checking.md +++ b/src/pat-exhaustive-checking.md @@ -4,4 +4,84 @@ In Rust, pattern matching and bindings have a few very helpful properties. The compiler will check that bindings are irrefutable when made and that match arms are exhaustive. -**TODO**: write this chapter. +## Pattern usefulness + +The central question that usefulness checking answers is: +"in this match expression, is that branch reachable?". +More precisely, it boils down to computing whether, +given a list of patterns we have already seen, +a given new pattern might match any new value. + +For example, in the following match expression, +we ask in turn whether each pattern might match something +that wasn't matched by the patterns above it. +Here we see the 4th pattern is redundant with the 1st; +that branch will get an "unreachable" warning. +The 3rd pattern may or may not be useful, +depending on whether `Foo` has other variants than `Bar`. +Finally, we can ask whether the whole match is exhaustive +by asking whether the wildcard pattern (`_`) +is useful relative to the list of all the patterns in that match. +Here we can see that `_` is useful (it would catch `(false, None)`); +this expression would therefore get a "non-exhaustive match" error. + +```rust +// x: (bool, Option) +match x { + (true, _) => {} // 1 + (false, Some(Foo::Bar)) => {} // 2 + (false, Some(_)) => {} // 3 + (true, None) => {} // 4 +} +``` + +Thus usefulness is used for two purposes: +detecting unreachable code (which is useful to the user), +and ensuring that matches are exhaustive (which is important for soundness). + +## Where it happens + +This check is done to any expression that desugars to a match expression in MIR. +That includes actual `match` expressions, +but also anything that looks like pattern matching, +including `if let`, destructuring `let`, and similar expressions. + +```rust +// `match` +// Usefulness can detect unreachable branches and forbid non-exhaustive matches. +match foo() { + Ok(x) => x, + Err(_) => panic!(), +} + +// `if let` +// Usefulness can detect unreachable branches. +if let Some(x) = foo() { + // ... +} + +// `while let` +// Usefulness can detect infinite loops and dead loops. +while let Some(x) = it.next() { + // ... +} + +// Destructuring `let` +// Usefulness can forbid non-exhaustive patterns. +let Foo::Bar(x, y) = foo(); + +// Destructuring function arguments +// Usefulness can forbid non-exhaustive patterns. +fn foo(Foo { x, y }: Foo) { + // ... +} +``` + +## The algorithm + +Exhaustiveness checking is implemented in [check_match]. +The core of the algorithm is in [_match]. +That file contains a detailed description of the algorithm. + +[check_match]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/pattern/check_match/index.html +[_match]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/pattern/_match/index.html From b04860c0780c8a6183ffa8119b4a09d5f87e9395 Mon Sep 17 00:00:00 2001 From: Nadrieril Date: Fri, 16 Oct 2020 22:48:00 +0100 Subject: [PATCH 1313/1812] Explain why exhaustiveness is necessary for soundness --- src/pat-exhaustive-checking.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/pat-exhaustive-checking.md b/src/pat-exhaustive-checking.md index da4dab3bf..767b7de50 100644 --- a/src/pat-exhaustive-checking.md +++ b/src/pat-exhaustive-checking.md @@ -37,7 +37,8 @@ match x { Thus usefulness is used for two purposes: detecting unreachable code (which is useful to the user), -and ensuring that matches are exhaustive (which is important for soundness). +and ensuring that matches are exhaustive (which is important for soundness, +because a match expression can return a value). ## Where it happens From 783c5849c45fed6d9fbdd6875483a38ed9531942 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 19 Oct 2020 15:00:49 -0300 Subject: [PATCH 1314/1812] Fix typo errros -> errors --- src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 7f704d05d..a02b854af 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -512,7 +512,7 @@ We use these items in macro parser: token stream and parsing session. The token stream is what we are about to ask the MBE parser to parse. We will consume the raw stream of tokens and output a binding of metavariables to corresponding token trees. The parsing - session can be used to report parser errros. + session can be used to report parser errors. - `ms` a _matcher_. This is a sequence of token trees that we want to match the token stream against. From cd35d2b5944d8436350b7f2f16f5e720d9912db6 Mon Sep 17 00:00:00 2001 From: Ivan Tham Date: Tue, 20 Oct 2020 10:03:42 +0800 Subject: [PATCH 1315/1812] Remove outdated build rustdoc --stage 1 It builds with stage 1 by default. --- src/rustdoc-internals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index f9c37ecd4..bfe291229 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -201,7 +201,7 @@ server. To test these features locally, you can run a local HTTP server, like this: ```bash -$ ./x.py doc library/std --stage 1 +$ ./x.py doc library/std # The documentation has been generated into `build/[YOUR ARCH]/doc`. $ python3 -m http.server -d build/[YOUR ARCH]/doc ``` From bd82b750208a15c4f7bd8b9e2de6c21b9b3be7b6 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 19 Oct 2020 22:31:34 -0400 Subject: [PATCH 1316/1812] Revert "Remove outdated build rustdoc --stage 1" This reverts commit cd35d2b5944d8436350b7f2f16f5e720d9912db6. --- src/rustdoc-internals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index bfe291229..f9c37ecd4 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -201,7 +201,7 @@ server. To test these features locally, you can run a local HTTP server, like this: ```bash -$ ./x.py doc library/std +$ ./x.py doc library/std --stage 1 # The documentation has been generated into `build/[YOUR ARCH]/doc`. $ python3 -m http.server -d build/[YOUR ARCH]/doc ``` From 97eebb9adbf651e437fd4de541d8d36251281704 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 22 Oct 2020 04:26:40 +0900 Subject: [PATCH 1317/1812] Replace links to `buildbot2.r-l.o` with `bors.r-l.o` --- src/compiler-team.md | 2 +- src/contributing.md | 4 ++-- src/getting-started.md | 2 +- src/tests/intro.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index 33ff65af6..ebb8cbc16 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -82,7 +82,7 @@ offer r+ privileges. This means that you have the right to instruct merge a PR ([here are some instructions for how to talk to bors][homu-guide]). -[homu-guide]: https://buildbot2.rust-lang.org/homu/ +[homu-guide]: https://bors.rust-lang.org/ The guidelines for reviewers are as follows: diff --git a/src/contributing.md b/src/contributing.md index 5dd80c933..fb65a8eae 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -128,7 +128,7 @@ with one another are marked as "always roll up". [rust-highfive]: https://github.com/rust-highfive [steveklabnik]: https://github.com/steveklabnik [@bors]: https://github.com/bors -[merge-queue]: https://buildbot2.rust-lang.org/homu/queue/rust +[merge-queue]: https://bors.rust-lang.org/queue/rust ### Opening a PR @@ -540,4 +540,4 @@ are: [tlgba]: http://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/ [ro]: https://www.rustaceans.org/ [rctd]: https://rustc-dev-guide.rust-lang.org/tests/intro.html -[cheatsheet]: https://buildbot2.rust-lang.org/homu/ +[cheatsheet]: https://bors.rust-lang.org/ diff --git a/src/getting-started.md b/src/getting-started.md index c13d4f044..6ca7f1eda 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -408,7 +408,7 @@ a PR (there are few other commands, but they are less relevant here). This puts the PR in [bors's queue][bors] to be tested and merged. Be patient; this can take a while and the queue can sometimes be long. PRs are never merged by hand. -[bors]: https://buildbot2.rust-lang.org/homu/queue/rust +[bors]: https://bors.rust-lang.org/queue/rust ### Bug Fixes or "Normal" code changes diff --git a/src/tests/intro.md b/src/tests/intro.md index 3503e7ad1..3be9219f6 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -132,7 +132,7 @@ only a subset run the full suite of tests (see Rust's [platform tiers]). [GitHub Actions]: https://github.com/rust-lang/rust/actions [rust-lang-ci]: https://github.com/rust-lang-ci/rust/actions [bors]: https://github.com/servo/homu -[queue]: https://buildbot2.rust-lang.org/homu/queue/rust +[queue]: https://bors.rust-lang.org/queue/rust [platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support ## Testing with Docker images From 47893bacd89cdaffe9189e22217d932e6389f8c1 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 22 Oct 2020 06:53:32 +0900 Subject: [PATCH 1318/1812] Add reference PRs for `r?` and `r+` comments (#928) --- src/getting-started.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index 6ca7f1eda..da444cdbb 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -383,7 +383,7 @@ automatically assign a reviewer to the PR. The reviewer is the person that will approve the PR to be tested and merged. If you want a specific reviewer (e.g. a team member you've been working with), you can specifically request them by writing `r? @user` (e.g. `r? @eddyb`) in either the original post or a followup -comment. +comment (you can see [this comment][r?] for example). Please note that the reviewers are humans, who for the most part work on `rustc` in their free time. This means that they can take some time to respond and review @@ -399,15 +399,18 @@ The reviewer may request some changes using the GitHub code review interface. They may also request special procedures (such as a [crater] run; [see below][break]) for some PRs. +[r?]: https://github.com/rust-lang/rust/pull/78133#issuecomment-712692371 [#t-release/triage]: https://rust-lang.zulipchat.com/#narrow/stream/242269-t-release.2Ftriage [break]: #breaking-changes When the PR is ready to be merged, the reviewer will issue a command to `@bors`, the CI bot. Usually, this is `@bors r+` or `@bors r=user` to approve -a PR (there are few other commands, but they are less relevant here). This puts -the PR in [bors's queue][bors] to be tested and merged. Be patient; this can take a -while and the queue can sometimes be long. PRs are never merged by hand. +a PR (there are few other commands, but they are less relevant here). +You can see [this comment][r+] for example. This puts the PR in [bors's queue][bors] +to be tested and merged. Be patient; this can take a while and the queue can +sometimes be long. PRs are never merged by hand. +[r+]: https://github.com/rust-lang/rust/pull/78133#issuecomment-712726339 [bors]: https://bors.rust-lang.org/queue/rust ### Bug Fixes or "Normal" code changes From e75c72baa349333817b91d1b74dcb4f96b3837ac Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 21 Oct 2020 18:25:54 -0400 Subject: [PATCH 1319/1812] Add a `check-in.sh` script to automate writing markdown links Example usage: ``` $ ./check-in.sh usage: ./check-in.sh $ ./check-in.sh 2020-09-03 usage: ./check-in.sh help: you can find the number of PRs merged at https://github.com/rust-lang/rustc-dev-guide/pulls?q=is%3Apr+is%3Aclosed+updated%3A%3E2020-09-03 $ ./check-in.sh 2020-09-03 72 Authors: - **@1c3t3a** - **@arora-aman** ... snip ... Changes: - Replace links to `buildbot2.r-l.o` with `bors.r-l.o` [#929](https://github.com/rust-lang/rustc-dev-guide/pull/929) - Add reference PRs for `r?` and `r+` comments [#928](https://github.com/rust-lang/rustc-dev-guide/pull/928) ... snip ... Changes in progress: ``` --- ci/check-in.sh | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100755 ci/check-in.sh diff --git a/ci/check-in.sh b/ci/check-in.sh new file mode 100755 index 000000000..d41a7ae57 --- /dev/null +++ b/ci/check-in.sh @@ -0,0 +1,34 @@ +#!/bin/sh + +set -eu + +# This is not a very smart script +if [ $# != 2 ]; then + echo "usage: $0 " + if [ $# = 1 ] ; then + echo "help: you can find the number of PRs merged at" \ + "https://github.com/rust-lang/rustc-dev-guide/pulls?q=is%3Apr+is%3Aclosed+updated%3A%3E$1" + fi + exit 1 +fi + +curl() { + command curl -s "$@" +} + +# Get recently updated PRs +curl "https://api.github.com/repos/rust-lang/rustc-dev-guide/pulls?state=closed&per_page=$2" \ + | jq '[.[] | select(.merged_at > "'"$1"'")]' > pulls.json + +show_pulls() { + jq -r '.[] | { title, number, html_url, user: .user.login } | "- " + .title + " [#" + (.number | tostring) + "](" + .html_url + ")"' +} + +echo "Authors:" +jq -r '{ login: .[].user.login } | "- **@" + .login + "**"' < pulls.json | sort -u +echo "Changes:" +show_pulls < pulls.json +echo "Changes in progress:" +# If there are more than 30 PRs open at a time, you'll need to set `per_page`. +# For now this seems unlikely. +curl "https://api.github.com/repos/rust-lang/rustc-dev-guide/pulls?state=open" | show_pulls From 8539c7f4e2fd43ce7a0047aa2fa974edadaf3e9b Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 21 Oct 2020 18:38:38 -0400 Subject: [PATCH 1320/1812] Improve markdown formatting --- ci/check-in.sh | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/ci/check-in.sh b/ci/check-in.sh index d41a7ae57..694c3bdf8 100755 --- a/ci/check-in.sh +++ b/ci/check-in.sh @@ -24,11 +24,16 @@ show_pulls() { jq -r '.[] | { title, number, html_url, user: .user.login } | "- " + .title + " [#" + (.number | tostring) + "](" + .html_url + ")"' } -echo "Authors:" -jq -r '{ login: .[].user.login } | "- **@" + .login + "**"' < pulls.json | sort -u -echo "Changes:" +echo "### Authors" +jq -r '{ login: .[].user.login } | "- **@" + .login + "**"' < pulls.json \ + | sort -u +echo +echo "### Changes" +echo show_pulls < pulls.json -echo "Changes in progress:" +echo +echo "### Changes in progress" +echo # If there are more than 30 PRs open at a time, you'll need to set `per_page`. # For now this seems unlikely. curl "https://api.github.com/repos/rust-lang/rustc-dev-guide/pulls?state=open" | show_pulls From 132df6222b49bf9ae11bd9792f4e2d72cbea96a5 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 21 Oct 2020 20:15:55 -0400 Subject: [PATCH 1321/1812] fix formatting --- ci/check-in.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/check-in.sh b/ci/check-in.sh index 694c3bdf8..ef61b6871 100755 --- a/ci/check-in.sh +++ b/ci/check-in.sh @@ -7,7 +7,7 @@ if [ $# != 2 ]; then echo "usage: $0 " if [ $# = 1 ] ; then echo "help: you can find the number of PRs merged at" \ - "https://github.com/rust-lang/rustc-dev-guide/pulls?q=is%3Apr+is%3Aclosed+updated%3A%3E$1" + "https://github.com/rust-lang/rustc-dev-guide/pulls?q=is%3Apr+is%3Amerged+updated%3A%3E$1" fi exit 1 fi From b1af2f0c07ce95720e8d59c421cbd66b005f454a Mon Sep 17 00:00:00 2001 From: Nadrieril Date: Thu, 22 Oct 2020 21:28:41 +0100 Subject: [PATCH 1322/1812] Explain lint renaming/removing --- src/diagnostics.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/src/diagnostics.md b/src/diagnostics.md index a3293101f..04745ee98 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -591,6 +591,21 @@ If you need a combination of options that's not supported by the - Later, change lint to error. - Eventually, remove lint. +### Renaming or removing a lint + +A lint can be renamed or removed, which will trigger a warning if a user tries +to use the old lint name. To declare a rename/remove, add a line with +[`store.register_renamed`] or [`store.register_removed`] to the code of the +[`register_builtins`] function. + +```rust,ignore +store.register_renamed("single_use_lifetime", "single_use_lifetimes"); +``` + +[`store.register_renamed`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html#method.register_renamed +[`store.register_removed`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html#method.register_removed +[`register_builtins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_builtins.html + ### Lint Groups Lints can be turned on in groups. These groups are declared in the From 53a7fd3ad3f11157210105b0b93d254f7d291b34 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 26 Oct 2020 08:15:21 +0900 Subject: [PATCH 1323/1812] Improve prerequisites section for Windows (#934) Co-authored-by: Joshua Nelson --- src/building/prerequisites.md | 34 ++++++++++++++++------------------ 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index 00692fda9..ebbe13ce4 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -23,8 +23,23 @@ See [this section for more info][sysllvm]. ### Windows +* Install [winget](https://github.com/microsoft/winget-cli) + +`winget` is a Windows package manager. It will make package installation easy +on Windows. + +Run the following in a terminal: + +```powershell +winget install python +winget install cmake +``` + +If any of those is installed already, winget will detect it. +Then edit your systems `PATH` variable and add: `C:\Program Files\CMake\bin`. + For more information about building on Windows, -see [the Rust README](https://github.com/rust-lang/rust#msvc). +see [the `rust-lang/rust` README](https://github.com/rust-lang/rust#building-on-windows). ## Hardware @@ -45,20 +60,3 @@ Follow the installation given in the [Rust book][install] to install a working `rustc` and the necessary C/++ toolchain on your platform. [install]: https://doc.rust-lang.org/book/ch01-01-installation.html - -## Platform specific instructions - -### Windows - -* Install [winget](https://github.com/microsoft/winget-cli) - -Run the following in a terminal: - -``` -winget install python -winget install cmake -``` - -If any of those is installed already, winget will detect it. - -Edit your systems `PATH` variable and add: `C:\Program Files\CMake\bin`. From 30c298dd7c34e7e06f8673178ef79733876da6a2 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 25 Oct 2020 19:58:00 -0700 Subject: [PATCH 1324/1812] Clean up `compiletest` chapter (#935) --- src/SUMMARY.md | 2 +- src/compiletest.md | 104 ++++++++++++++++++++++----------------------- 2 files changed, 52 insertions(+), 54 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index f3ebe4da8..41de14954 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -20,7 +20,7 @@ - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) - [Adding new tests](./tests/adding.md) - - [Using `compiletest` + commands to control test execution](./compiletest.md) + - [Using `compiletest` commands to control test execution](./compiletest.md) - [Debugging the Compiler](./compiler-debugging.md) - [Profiling the compiler](./profiling.md) - [with the linux perf tool](./profiling/with_perf.md) diff --git a/src/compiletest.md b/src/compiletest.md index dbd6c4b6e..2e0bcec53 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -1,52 +1,51 @@ -# `compiletest` +# Using `compiletest` commands to control test execution ## Introduction -`compiletest` is the main test harness of the Rust test suite. It allows +`compiletest` is the main test harness of the Rust test suite. It allows test authors to organize large numbers of tests (the Rust compiler has many thousands), efficient test execution (parallel execution is supported), and allows the test author to configure behavior and expected results of both individual and groups of tests. -`compiletest` tests may check test code for success, for failure or in some -cases, even failure to compile. Tests are typically organized as a Rust source -file with annotations in comments before and/or within the test code, which -serve to direct `compiletest` on if or how to run the test, what behavior to -expect, and more. If you are unfamiliar with the compiler testing framework, -see [this chapter](./tests/intro.html) for additional background. +`compiletest` tests may check test code for success, for runtime failure, or for +compile-time failure. Tests are typically organized as a Rust source file with +annotations in comments before and/or within the test code, which serve to +direct `compiletest` on if or how to run the test, what behavior to expect, +and more. If you are unfamiliar with the compiler testing framework, +see [this chapter](./tests/intro.md) for additional background. The tests themselves are typically (but not always) organized into -"suites" – for example, `run-fail`, -a folder holding tests that should compile successfully, -but return a failure (non-zero status), `compile-fail`, a folder holding tests -that should fail to compile, and many more. The various suites are defined in -[src/tools/compiletest/src/common.rs][common] in the `pub enum Mode` -declaration. And a very good introduction to the different suites of compiler -tests along with details about them can be found in [Adding new -tests](./tests/adding.html). +"suites" – for example, `run-fail`, a folder holding tests that should compile +successfully, but return a failure (non-zero status) at runtime, `compile-fail`, +a folder holding tests that should fail to compile, and many more. The various +suites are defined in [`src/tools/compiletest/src/common.rs`] in the +`pub enum Mode` declaration. And a good introduction to the different +suites of compiler tests along with details about them can be found in +[Adding new tests](./tests/adding.md). ## Adding a new test file Briefly, simply create your new test in the appropriate location under -[src/test][test]. No registration of test files is necessary as `compiletest` -will scan the [src/test][test] subfolder recursively, and will execute any Rust -source files it finds as tests. See [`Adding new tests`](./tests/adding.html) -for a complete guide on how to adding new tests. +[`src/test`]. No registration of test files is necessary as `compiletest` +will scan the [`src/test`] subfolder recursively, and will execute any +Rust source files it finds as tests. +See [Adding new tests](./tests/adding.md) for a complete guide on how to add +new tests. ## Header Commands Source file annotations which appear in comments near the top of the source -file *before* any test code are known as header commands. These commands can +file *before* any test code are known as header commands. These commands can instruct `compiletest` to ignore this test, set expectations on whether it is expected to succeed at compiling, or what the test's return code is expected to -be. Header commands (and their inline counterparts, Error Info commands) are -described more fully -[here](./tests/adding.html#header-commands-configuring-rustc). +be. Header commands and inline `//~ ERROR` commands are described more fully +[here](./tests/adding.md#header-commands-configuring-rustc). ### Adding a new header command Header commands are defined in the `TestProps` struct in -[src/tools/compiletest/src/header.rs][header]. At a high level, there are +[`src/tools/compiletest/src/header.rs`]. At a high level, there are dozens of test properties defined here, all set to default values in the `TestProp` struct's `impl` block. Any test can override this default value by specifying the property in question as header command as a comment (`//`) in @@ -77,29 +76,29 @@ fn main() -> Result<(), Box> { #### Adding a new header command property One would add a new header command if there is a need to define some test -property or behavior on an individual, test-by-test basis. A header command +property or behavior on an individual, test-by-test basis. A header command property serves as the header command's backing store (holds the command's current value) at runtime. To add a new header command property: - 1. Look for the `pub struct TestProps` declaration in - [src/tools/compiletest/src/header.rs][header] and add the new public - property to the end of the declaration. - 2. Look for the `impl TestProps` implementation block immediately following - the struct declaration and initialize the new property to its default - value. + + 1. Look for the `pub struct TestProps` declaration in + [`src/tools/compiletest/src/header.rs`] and add the new public property to + the end of the declaration. + 2. Look for the `impl TestProps` implementation block immediately following + the struct declaration and initialize the new property to its default + value. #### Adding a new header command parser When `compiletest` encounters a test file, it parses the file a line at a time by calling every parser defined in the `Config` struct's implementation block, -also in [src/tools/compiletest/src/header.rs][header] (note the `Config` -struct's declaration block is found in -[src/tools/compiletest/src/common.rs][common]. `TestProps`'s `load_from()` -method will try passing the current line of text to each parser, which, in turn -typically checks to see if the line begins with a particular commented (`//`) -header command such as `// must-compile-successfully` or `// failure-status`. -Whitespace after the comment marker is optional. +also in [`src/tools/compiletest/src/header.rs`][] (note that the `Config` +struct's declaration block is found in [`src/tools/compiletest/src/common.rs`]). +`TestProps`'s `load_from()` method will try passing the current line of text to +each parser, which, in turn typically checks to see if the line begins with a +particular commented (`//`) header command such as `// must-compile-successfully` +or `// failure-status`. Whitespace after the comment marker is optional. Parsers will override a given header command property's default value merely by being specified in the test file as a header command or by having a parameter @@ -107,18 +106,17 @@ value specified in the test file, depending on the header command. Parsers defined in `impl Config` are typically named `parse_` (note kebab-case `` transformed to snake-case -``). `impl Config` also defines several 'low-level' parsers +``). `impl Config` also defines several 'low-level' parsers which make it simple to parse common patterns like simple presence or not (`parse_name_directive()`), header-command:parameter(s) (`parse_name_value_directive()`), optional parsing only if a particular `cfg` -attribute is defined (`has_cfg_prefix()`) and many more. The low-level parsers +attribute is defined (`has_cfg_prefix()`) and many more. The low-level parsers are found near the end of the `impl Config` block; be sure to look through them and their associated parsers immediately above to see how they are used to avoid writing additional parsing code unnecessarily. As a concrete example, here is the implementation for the -`parse_failure_status()` parser, in -[src/tools/compiletest/src/header.rs][header]: +`parse_failure_status()` parser, in [`src/tools/compiletest/src/header.rs`]: ```diff @@ -232,6 +232,7 @@ pub struct TestProps { @@ -163,18 +161,17 @@ As a concrete example, here is the implementation for the ## Implementing the behavior change When a test invokes a particular header command, it is expected that some -behavior will change as a result. What behavior, obviously, will depend on the -purpose of the header command. In the case of `failure-status`, the behavior +behavior will change as a result. What behavior, obviously, will depend on the +purpose of the header command. In the case of `failure-status`, the behavior that changes is that `compiletest` expects the failure code defined by the header command invoked in the test, rather than the default value. Although specific to `failure-status` (as every header command will have a different implementation in order to invoke behavior change) perhaps it is helpful to see the behavior change implementation of one case, simply as an -example. To implement `failure-status`, the `check_correct_failure_status()` +example. To implement `failure-status`, the `check_correct_failure_status()` function found in the `TestCx` implementation block, located in -[src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs), -was modified as per below: +[`src/tools/compiletest/src/runtest.rs`], was modified as per below: ```diff @@ -295,11 +295,14 @@ impl<'test> TestCx<'test> { @@ -213,13 +210,14 @@ was modified as per below: } ``` Note the use of `self.props.failure_status` to access the header command -property. In tests which do not specify the failure status header command, +property. In tests which do not specify the failure status header command, `self.props.failure_status` will evaluate to the default value of 101 at the -time of this writing. But for a test which specifies a header command of, for +time of this writing. But for a test which specifies a header command of, for example, `// failure-status: 1`, `self.props.failure_status` will evaluate to 1, as `parse_failure_status()` will have overridden the `TestProps` default value, for that test specifically. -[test]: https://github.com/rust-lang/rust/tree/master/src/test -[header]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs -[common]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs +[`src/test`]: https://github.com/rust-lang/rust/tree/master/src/test +[`src/tools/compiletest/src/header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs +[`src/tools/compiletest/src/common.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs +[`src/tools/compiletest/src/runtest.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs From de4ca807961d7ab99a3388954220b4d4c4204746 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Oct 2020 11:30:20 -0700 Subject: [PATCH 1325/1812] Add "ctxt" and `TyCtxt` to the glossary (#937) --- src/appendix/glossary.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 842613d25..84fff5e79 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -13,6 +13,7 @@ completeness
| A technical term in type theory, it control-flow graph
| A representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) CTFE
| Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) cx
| We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. +ctxt
| We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](TyCtxt). See also [cx](#cx) or [tcx](#tcx). DAG
| A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) data-flow analysis
| A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). DeBruijn Index
| A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) @@ -73,7 +74,8 @@ span
| A location in the user's source code substs
| The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). Tag
| The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). tcx
| The "typing context", main data structure of the compiler. ([see more](../ty.html)) -'tcx
| The lifetime of the allocation arena. ([see more](../ty.html)) +`'tcx`
| The lifetime of the allocation arena. ([see more](../ty.html)) +TyCtxt
| The data structure often referred to as [tcx](#tcx) in code token
| The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). [TLS]
| Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. trait reference
| The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) From 5b3fd170fc2b90b5bd1d6b23e1a8567685e1d721 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Tue, 27 Oct 2020 18:34:28 +0000 Subject: [PATCH 1326/1812] Small improvements (#936) * Fix typo errros -> errors * an -> a * hir -> hir() --- src/hir.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/hir.md b/src/hir.md index 5757d1e77..a88ba9066 100644 --- a/src/hir.md +++ b/src/hir.md @@ -87,7 +87,7 @@ Most of the time when you are working with the HIR, you will do so via the **HIR Map**, accessible in the tcx via [`tcx.hir()`] (and defined in the [`hir::map`] module). The [HIR map] contains a [number of methods] to convert between IDs of various kinds and to lookup data associated -with an HIR node. +with a HIR node. [`tcx.hir()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.hir [`hir::map`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/index.html @@ -96,7 +96,7 @@ with an HIR node. For example, if you have a [`DefId`], and you would like to convert it to a [`NodeId`], you can use -[`tcx.hir.as_local_node_id(def_id)`][as_local_node_id]. This returns +[`tcx.hir().as_local_node_id(def_id)`][as_local_node_id]. This returns an `Option` – this will be `None` if the def-id refers to something outside of the current crate (since then it has no HIR node), but otherwise returns `Some(n)` where `n` is the node-id of the @@ -105,13 +105,13 @@ definition. [`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html [as_local_node_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.as_local_node_id -Similarly, you can use [`tcx.hir.find(n)`][find] to lookup the node for a +Similarly, you can use [`tcx.hir().find(n)`][find] to lookup the node for a [`NodeId`]. This returns a `Option>`, where [`Node`] is an enum defined in the map; by matching on this you can find out what sort of node the node-id referred to and also get a pointer to the data itself. Often, you know what sort of node `n` is – e.g. if you know that `n` must be some HIR expression, you can do -[`tcx.hir.expect_expr(n)`][expect_expr], which will extract and return the +[`tcx.hir().expect_expr(n)`][expect_expr], which will extract and return the [`&hir::Expr`][Expr], panicking if `n` is not in fact an expression. [find]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.find @@ -120,7 +120,7 @@ that `n` must be some HIR expression, you can do [Expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Expr.html Finally, you can use the HIR map to find the parents of nodes, via -calls like [`tcx.hir.get_parent_node(n)`][get_parent_node]. +calls like [`tcx.hir().get_parent_node(n)`][get_parent_node]. [get_parent_node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.get_parent_node From 5d6a0cdf69da83dd48135db81b7199763f60eacf Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Oct 2020 12:26:08 -0700 Subject: [PATCH 1327/1812] Fix broken tags in glossary --- src/appendix/glossary.md | 176 +++++++++++++++++++-------------------- 1 file changed, 88 insertions(+), 88 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 84fff5e79..5a1c5c16b 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -1,93 +1,93 @@ # Glossary -Term | Meaning ------------------------------------------|-------- -arena/arena allocation
| An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. -AST
| The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. -binder
| A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound). -BodyId
| An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -bound variable
| A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) -codegen
| The code to translate MIR into LLVM IR. -codegen unit
| When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) -completeness
| A technical term in type theory, it means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). -control-flow graph
| A representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) -CTFE
| Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) -cx
| We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. -ctxt
| We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](TyCtxt). See also [cx](#cx) or [tcx](#tcx). -DAG
| A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) -data-flow analysis
| A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). -DeBruijn Index
| A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) -DefId
| An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -Discriminant
| The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). -Double pointer
| A pointer with additional metadata. See "fat pointer" for more. -drop glue
| (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. -DST
| Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). -early-bound lifetime
| A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) -empty type
| see "uninhabited type". -Fat pointer
| A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". -free variable
| A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) -generics
| The set of generic type parameters defined on a type or item. -HIR
| The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.html)) -HirId
| Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -HIR Map
| The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. -ICE
| Short for internal compiler error, this is when the compiler crashes. -ICH
| Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. -infcx
| The inference context (see `rustc_middle/src/infer`) -inference variable
| When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. -intern
| Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. -intrinsic
| Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html)) -IR
| Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. -IRLO
| `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). -item
| A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. -lang item
| Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) -late-bound lifetime
| A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) -local crate
| The crate currently being compiled. -LTO
| Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. -[LLVM]
| (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. -memoization
| The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. -MIR
| The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.html)) -miri
| An interpreter for MIR used for constant evaluation. ([see more](../miri.html)) -monomorphization
| The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). -normalize
| A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.html#normalizeprojection---type). -newtype
| A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -Niche
| Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field. -NLL
| Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. -node-id or NodeId
| An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -obligation
| Something that must be proven by the trait system. ([see more](../traits/resolution.html)) -placeholder
| **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. -point
| Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. -polymorphize
| An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) -projection
| A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref). -promoted constants
| Constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. -provider
| The function that executes a query. ([see more](../query.html)) -quantified
| In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified). -query
| Perhaps some sub-computation during compilation. ([see more](../query.html)) -recovery
| Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors). -region
| Another term for "lifetime" often used in the literature and in the borrow checker. -rib
| A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) -scrutinee | A scrutinee is the expression that is matched on in `match` expressions and similar pattern matching constructs. For example, in `match x { A => 1, B => 2 }`, the expression `x` is the scrutinee. -sess
| The compiler session, which stores global data used throughout compilation -side tables
| Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. -sigil
| Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -soundness
| A technical term in type theory. Roughly, if a type system is sound, then a program that type-checks is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). -span
| A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. -substs
| The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). -Tag
| The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). -tcx
| The "typing context", main data structure of the compiler. ([see more](../ty.html)) -`'tcx`
| The lifetime of the allocation arena. ([see more](../ty.html)) -TyCtxt
| The data structure often referred to as [tcx](#tcx) in code -token
| The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). -[TLS]
| Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. -trait reference
| The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) -trans
| The code to translate MIR into LLVM IR. Renamed to codegen. -ty
| The internal representation of a type. ([see more](../ty.html)) -UFCS
| Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) -uninhabited type
| A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". -upvar
| A variable captured by a closure from outside the closure. -variance
| Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance. -Variant index
| In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). -Wide pointer
| A pointer with additional metadata. See "fat pointer" for more. -ZST
| Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. +Term | Meaning +-----------------------------------------------|-------- +arena/arena allocation | An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. +AST | The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. +binder | A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound). +BodyId | An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +bound variable | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) +codegen | The code to translate MIR into LLVM IR. +codegen unit | When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) +completeness | A technical term in type theory, it means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). +control-flow graph | A representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) +CTFE | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) +cx | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. +ctxt | We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](TyCtxt). See also [cx](#cx) or [tcx](#tcx). +DAG | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) +data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). +DeBruijn Index | A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) +DefId | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +Discriminant | The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). +Double pointer | A pointer with additional metadata. See "fat pointer" for more. +drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. +DST | Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). +early-bound lifetime | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) +empty type | see "uninhabited type". +Fat pointer | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". +free variable | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) +generics | The set of generic type parameters defined on a type or item. +HIR | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.html)) +HirId | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. +ICE | Short for internal compiler error, this is when the compiler crashes. +ICH | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. +infcx | The inference context (see `rustc_middle::infer`) +inference variable | When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. +intern | Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. +intrinsic | Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html)) +IR | Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. +IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). +item | A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. +lang item | Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) +late-bound lifetime | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) +local crate | The crate currently being compiled. +LTO | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. +[LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. +memoization | The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. +MIR | The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.html)) +miri | An interpreter for MIR used for constant evaluation. ([see more](../miri.html)) +monomorphization | The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). +normalize | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.html#normalizeprojection---type). +newtype | A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. +Niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field. +NLL | Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. +node-id or NodeId | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +obligation | Something that must be proven by the trait system. ([see more](../traits/resolution.html)) +placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. +point | Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. +polymorphize | An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) +projection | A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref). +promoted constants | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. +provider | The function that executes a query. ([see more](../query.html)) +quantified | In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified). +query | Perhaps some sub-computation during compilation. ([see more](../query.html)) +recovery | Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors). +region | Another term for "lifetime" often used in the literature and in the borrow checker. +rib | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) +scrutinee
| A scrutinee is the expression that is matched on in `match` expressions and similar pattern matching constructs. For example, in `match x { A => 1, B => 2 }`, the expression `x` is the scrutinee. +sess | The compiler session, which stores global data used throughout compilation +side tables | Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. +sigil | Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. +soundness | A technical term in type theory. Roughly, if a type system is sound, then a program that type-checks is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). +span | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. +substs | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). +Tag | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). +tcx | The "typing context", main data structure of the compiler. ([see more](../ty.html)) +`'tcx` | The lifetime of the allocation arena. ([see more](../ty.html)) +TyCtxt | The data structure often referred to as [tcx](#tcx) in code +token | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). +[TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. +trait reference | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) +trans | The code to translate MIR into LLVM IR. Renamed to codegen. +ty | The internal representation of a type. ([see more](../ty.html)) +UFCS | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) +uninhabited type | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". +upvar | A variable captured by a closure from outside the closure. +variance | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance. +Variant index | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). +Wide pointer | A pointer with additional metadata. See "fat pointer" for more. +ZST | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. [LLVM]: https://llvm.org/ [lto]: https://llvm.org/docs/LinkTimeOptimization.html From 384eddb2efc13d18f12cc7d591beff20881218d7 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Oct 2020 12:25:04 -0700 Subject: [PATCH 1328/1812] Put `TyCtxt` at the right position It should now be at its alphabetical position. Also fixed link to `TyCtxt` anchor. --- src/appendix/glossary.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 5a1c5c16b..fb216c4f9 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -13,7 +13,7 @@ Term | Meaning control-flow graph | A representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) CTFE | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) cx | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. -ctxt | We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](TyCtxt). See also [cx](#cx) or [tcx](#tcx). +ctxt | We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](#TyCtxt). See also [cx](#cx) or [tcx](#tcx). DAG | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). DeBruijn Index | A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) @@ -75,12 +75,12 @@ Term | Meaning Tag | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). tcx | The "typing context", main data structure of the compiler. ([see more](../ty.html)) `'tcx` | The lifetime of the allocation arena. ([see more](../ty.html)) -TyCtxt | The data structure often referred to as [tcx](#tcx) in code token | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. trait reference | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) trans | The code to translate MIR into LLVM IR. Renamed to codegen. ty | The internal representation of a type. ([see more](../ty.html)) +TyCtxt | The data structure often referred to as [tcx](#tcx) in code UFCS | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) uninhabited type | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". upvar | A variable captured by a closure from outside the closure. From cc841a185fea73437bf63c616dd52f64b44b1b60 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Oct 2020 17:32:06 -0700 Subject: [PATCH 1329/1812] Use new-style mdBook internal links in glossary --- src/appendix/glossary.md | 60 ++++++++++++++++++++-------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index fb216c4f9..58ec39e4f 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -4,20 +4,20 @@ Term | Meaning -----------------------------------------------|-------- arena/arena allocation | An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. AST | The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. -binder | A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.html#free-vs-bound). -BodyId | An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -bound variable | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.html#free-vs-bound) +binder | A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.md#free-vs-bound). +BodyId | An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). +bound variable | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.md#free-vs-bound) codegen | The code to translate MIR into LLVM IR. codegen unit | When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) completeness | A technical term in type theory, it means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). -control-flow graph | A representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg) -CTFE | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html)) +control-flow graph | A representation of the control-flow of a program; see [the background chapter for more](./background.md#cfg) +CTFE | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.md)) cx | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. ctxt | We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](#TyCtxt). See also [cx](#cx) or [tcx](#tcx). -DAG | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html)) -data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow). +DAG | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.md)) +data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.md#dataflow). DeBruijn Index | A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) -DefId | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +DefId | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). Discriminant | The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). Double pointer | A pointer with additional metadata. See "fat pointer" for more. drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. @@ -25,10 +25,10 @@ Term | Meaning early-bound lifetime | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) empty type | see "uninhabited type". Fat pointer | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". -free variable | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.html#free-vs-bound) +free variable | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.md#free-vs-bound) generics | The set of generic type parameters defined on a type or item. -HIR | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.html)) -HirId | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). +HIR | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.md)) +HirId | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. ICE | Short for internal compiler error, this is when the compiler crashes. ICH | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. @@ -45,26 +45,26 @@ Term | Meaning LTO | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. memoization | The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. -MIR | The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.html)) -miri | An interpreter for MIR used for constant evaluation. ([see more](../miri.html)) +MIR | The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.md)) +miri | An interpreter for MIR used for constant evaluation. ([see more](../miri.md)) monomorphization | The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). -normalize | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.html#normalizeprojection---type). +normalize | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.md#normalizeprojection---type). newtype | A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. Niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field. -NLL | Short for [non-lexical lifetimes](../borrow_check/region_inference.html), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. -node-id or NodeId | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.html#identifiers-in-the-hir). -obligation | Something that must be proven by the trait system. ([see more](../traits/resolution.html)) +NLL | Short for [non-lexical lifetimes](../borrow_check/region_inference.md), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. +node-id or NodeId | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). +obligation | Something that must be proven by the trait system. ([see more](../traits/resolution.md)) placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. point | Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. polymorphize | An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) -projection | A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.html#trait-ref). -promoted constants | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.html#promoted) for more details. -provider | The function that executes a query. ([see more](../query.html)) -quantified | In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.html#quantified). -query | Perhaps some sub-computation during compilation. ([see more](../query.html)) +projection | A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.md#trait-ref). +promoted constants | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.md#promoted) for more details. +provider | The function that executes a query. ([see more](../query.md)) +quantified | In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.md#quantified). +query | Perhaps some sub-computation during compilation. ([see more](../query.md)) recovery | Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors). region | Another term for "lifetime" often used in the literature and in the borrow checker. -rib | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.html)) +rib | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.md)) scrutinee
| A scrutinee is the expression that is matched on in `match` expressions and similar pattern matching constructs. For example, in `match x { A => 1, B => 2 }`, the expression `x` is the scrutinee. sess | The compiler session, which stores global data used throughout compilation side tables | Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. @@ -73,18 +73,18 @@ Term | Meaning span | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). Tag | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). -tcx | The "typing context", main data structure of the compiler. ([see more](../ty.html)) -`'tcx` | The lifetime of the allocation arena. ([see more](../ty.html)) -token | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.html)). +tcx | The "typing context", main data structure of the compiler. ([see more](../ty.md)) +`'tcx` | The lifetime of the allocation arena. ([see more](../ty.md)) +token | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.md)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. -trait reference | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.html#trait-ref)) +trait reference | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.md#trait-ref)) trans | The code to translate MIR into LLVM IR. Renamed to codegen. -ty | The internal representation of a type. ([see more](../ty.html)) +ty | The internal representation of a type. ([see more](../ty.md)) TyCtxt | The data structure often referred to as [tcx](#tcx) in code -UFCS | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.html)) +UFCS | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.md)) uninhabited type | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". upvar | A variable captured by a closure from outside the closure. -variance | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.html#variance) for a more general explanation. See the [variance chapter](../variance.html) for an explanation of how type checking handles variance. +variance | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.md#variance) for a more general explanation. See the [variance chapter](../variance.md) for an explanation of how type checking handles variance. Variant index | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). Wide pointer | A pointer with additional metadata. See "fat pointer" for more. ZST | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. From 1b43503411dccd69e233f317cbb9f9f4c64cde8c Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 2 Nov 2020 22:52:28 +0900 Subject: [PATCH 1330/1812] Use `provide_both` link instead of `provide(_extern)` --- src/query.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/query.md b/src/query.md index 52786ad34..77d3b50e5 100644 --- a/src/query.md +++ b/src/query.md @@ -155,13 +155,11 @@ providers**. Almost all **extern providers** wind up going through the [`rustc_metadata` crate][rustc_metadata], which loads the information from the crate metadata. But in some cases there are crates that provide queries for *both* local and external crates, in which case -they define both a [`provide`][ext_provide] and a -[`provide_extern`][ext_provide_extern] function that `rustc_driver` -can invoke. +they define both a `provide` and a `provide_extern` function, through +[`provide_both`][ext_provide_both], that `rustc_driver` can invoke. [rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html -[ext_provide]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide.html -[ext_provide_extern]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide_extern.html +[ext_provide_both]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide_both.html ### Adding a new kind of query From 877f5fbdaf60ff6fce6b3aa933be13db4175ce95 Mon Sep 17 00:00:00 2001 From: Joshua Nitschke <33307206+JoshuaNitschke@users.noreply.github.com> Date: Sun, 8 Nov 2020 10:15:22 -0800 Subject: [PATCH 1331/1812] correct minor grammar mistake (#944) correct `a lots to `a lot` on implementing_new_features.md --- src/implementing_new_features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 2103c8803..baf4e2b51 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -170,7 +170,7 @@ a new unstable feature: 6. Add a section to the unstable book, in `src/doc/unstable-book/src/language-features/$feature_name.md`. -7. Write a lots of tests for the new feature. +7. Write a lot of tests for the new feature. PRs without tests will not be accepted! 8. Get your PR reviewed and land it. You have now successfully From d0988bcb5dc13de950c29ea5f11e611ec5b9ca71 Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 8 Nov 2020 14:46:41 -0800 Subject: [PATCH 1332/1812] Document `src/tools/x`, an `x.py` wrapper Document the newly added `x` binary that wraps `x.py`, which can be installed system-wide, and can be run from any subdirectory of a rust repo checkout. --- src/building/how-to-build-and-run.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 0195659ac..39d7e9a4c 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -70,6 +70,14 @@ if you want to learn more about `x.py`, read its README.md To read more about the bootstrap process and why `x.py` is necessary, [read this chapter][bootstrap]. +### Running `x.py` slightly more conveniently + +There is a binary that wraps `x.py` called `x` in `src/tools/x`. All it does is +run `x.py`, but it can be installed system-wide and run from any subdirectory +of a checkout. + +You can install it with `cargo install --path/src/tools/x`. + [bootstrap]: ./bootstrapping.md ## Building the Compiler From 4e9e17fba41552dcfd453fe9f942b9e680a5b360 Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 8 Nov 2020 14:51:46 -0800 Subject: [PATCH 1333/1812] Fix install command --- src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 39d7e9a4c..bf9fd5b33 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -76,7 +76,7 @@ There is a binary that wraps `x.py` called `x` in `src/tools/x`. All it does is run `x.py`, but it can be installed system-wide and run from any subdirectory of a checkout. -You can install it with `cargo install --path/src/tools/x`. +You can install it with `cargo install --path src/tools/x`. [bootstrap]: ./bootstrapping.md From b4acbb95ad2a28b41ac78f28a140e3938aba8c64 Mon Sep 17 00:00:00 2001 From: Casey Rodarmor Date: Sun, 8 Nov 2020 16:20:37 -0800 Subject: [PATCH 1334/1812] Update src/building/how-to-build-and-run.md Co-authored-by: Joshua Nelson --- src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index bf9fd5b33..a97568e6e 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -74,7 +74,7 @@ To read more about the bootstrap process and why `x.py` is necessary, There is a binary that wraps `x.py` called `x` in `src/tools/x`. All it does is run `x.py`, but it can be installed system-wide and run from any subdirectory -of a checkout. +of a checkout. It also looks up the appropriate version of `python` to use. You can install it with `cargo install --path src/tools/x`. From 0a1da4f8a4bf086d00b2f3f3147f62d09fa0485d Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 10 Nov 2020 16:23:35 -0500 Subject: [PATCH 1335/1812] Add some more examples of using the compiler --- .../rustc-driver-interacting-with-the-ast.rs | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/examples/rustc-driver-interacting-with-the-ast.rs b/examples/rustc-driver-interacting-with-the-ast.rs index e33c2ee95..8ee38206f 100644 --- a/examples/rustc-driver-interacting-with-the-ast.rs +++ b/examples/rustc-driver-interacting-with-the-ast.rs @@ -1,8 +1,9 @@ #![feature(rustc_private)] // NOTE: For the example to compile, you will need to first run the following: -// rustup component add rustc-dev +// rustup component add rustc-dev llvm-tools-preview +extern crate rustc_ast_pretty; extern crate rustc_error_codes; extern crate rustc_errors; extern crate rustc_hash; @@ -11,8 +12,11 @@ extern crate rustc_interface; extern crate rustc_session; extern crate rustc_span; +use rustc_ast_pretty::pprust::item_to_string; use rustc_errors::registry; use rustc_session::config; +use rustc_session::config::PpMode::PpmSource; +use rustc_session::config::PpSourceMode::PpmExpanded; use rustc_span::source_map; use std::path; use std::process; @@ -46,16 +50,24 @@ fn main() { lint_caps: rustc_hash::FxHashMap::default(), register_lints: None, override_queries: None, + make_codegen_backend: None, registry: registry::Registry::new(&rustc_error_codes::DIAGNOSTICS), }; rustc_interface::run_compiler(config, |compiler| { compiler.enter(|queries| { + // TODO: add this to -Z unpretty + let ast_krate = queries.parse().unwrap().take(); + let ast_krate_mod = ast_krate.module; + for item in ast_krate_mod.items { + println!("{}", item_to_string(&item)); + } + // Analyze the crate and inspect the types under the cursor. queries.global_ctxt().unwrap().take().enter(|tcx| { // Every compilation contains a single crate. - let krate = tcx.hir().krate(); + let hir_krate = tcx.hir().krate(); // Iterate over the top-level items in the crate, looking for the main function. - for (_, item) in &krate.items { + for (_, item) in &hir_krate.items { // Use pattern-matching to find a specific node inside the main function. if let rustc_hir::ItemKind::Fn(_, _, body_id) = item.kind { let expr = &tcx.hir().body(body_id).value; From c15e119fd5fac8987c3dbe68a8bcc27022fe6318 Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Wed, 11 Nov 2020 12:31:58 +0000 Subject: [PATCH 1336/1812] Update link in compiler-debugging.md Link didn't point to latest version of `env_logger` crate. Add an explanation to disambiguate the RUSTC_LOG syntax. --- src/compiler-debugging.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index e4b04aa96..914aee1bc 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -149,10 +149,10 @@ $ # Cool, now I have a backtrace for the error These crates are used in compiler for logging: * [log] -* [env-logger]: check the link to see the full `RUSTC_LOG` syntax +* [env-logger] [log]: https://docs.rs/log/0.4.6/log/index.html -[env-logger]: https://docs.rs/env_logger/0.4.3/env_logger/ +[env-logger]: https://docs.rs/env_logger/0.8.1/env_logger/ The compiler has a lot of `debug!` calls, which print out logging information at many points. These are very useful to at least narrow down the location of @@ -166,6 +166,10 @@ then appear in standard error. If you are developing rustdoc, use `RUSTDOC_LOG` instead. +See the [env-logger] doc for more info on the full syntax. (Note: unlike the +compiler, the env-logger crate and its examples use the `RUST_LOG` env +variable.) + **Note that unless you use a very strict filter, the logger will emit a lot of output, so use the most specific module(s) you can (comma-separated if multiple)**. It's typically a good idea to pipe standard error to a file and From 10869964a796254b02c8f67c95bba240236c699d Mon Sep 17 00:00:00 2001 From: Olivier FAURE Date: Wed, 11 Nov 2020 14:58:56 +0000 Subject: [PATCH 1337/1812] Update src/compiler-debugging.md Co-authored-by: Joshua Nelson --- src/compiler-debugging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 914aee1bc..4b241d8ea 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -152,7 +152,7 @@ These crates are used in compiler for logging: * [env-logger] [log]: https://docs.rs/log/0.4.6/log/index.html -[env-logger]: https://docs.rs/env_logger/0.8.1/env_logger/ +[env-logger]: https://docs.rs/env_logger The compiler has a lot of `debug!` calls, which print out logging information at many points. These are very useful to at least narrow down the location of From f36f645daf1dfef9ac28ce5c32261c0e0e8df6f7 Mon Sep 17 00:00:00 2001 From: Alexis Bourget Date: Thu, 12 Nov 2020 00:45:34 +0100 Subject: [PATCH 1338/1812] Links to htmldocck/@has/matches for searchability --- src/rustdoc-internals.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index f9c37ecd4..1f7f10045 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -177,7 +177,8 @@ a set of tests in `src/test/rustdoc` that make sure the final HTML is what we expect in various situations. These tests also use a supplementary script, `src/etc/htmldocck.py`, that allows it to look through the final HTML using XPath notation to get a precise look at the output. The full description of all -the commands available to rustdoc tests is in `htmldocck.py`. +the commands available to rustdoc tests (e.g. [`@has`] and [`@matches`]) is in +[`htmldocck.py`]. To use multiple crates in a rustdoc test, add `// aux-build:filename.rs` to the top of the test file. `filename.rs` should be placed in an `auxiliary` @@ -193,6 +194,10 @@ that features results in all tabs can be found in `basic.js`. The basic idea is that you match a given `QUERY` with a set of `EXPECTED` results, complete with the full item path of each item. +[`htmldocck.py`]: https://github.com/rust-lang/rust/blob/master/src/etc/htmldocck.py +[`@has`]: https://github.com/rust-lang/rust/blob/master/src/etc/htmldocck.py#L39 +[`@matches`]: https://github.com/rust-lang/rust/blob/master/src/etc/htmldocck.py#L44 + ## Testing locally Some features of the generated HTML documentation might require local From 9e346c9d174857e64a06d81eb0e1b2a913d0d5c4 Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 10 Nov 2020 16:22:45 -0800 Subject: [PATCH 1339/1812] Add a section on data-flow convergence --- src/mir/dataflow.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index bc65ecfa2..061ea9038 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -89,7 +89,21 @@ statement must be considered separately from the left-hand side. ### Convergence -TODO +Your analysis must converge to "fixpoint", otherwise it will run forever. +Converging to fixpoint is just another way of saying "reaching equilibrium". +In order to reach equilibrium, your analysis must obey some laws. One of the +laws it must obey is that the bottom value joined with some other value equals +the second value. Or, as an equation: + +> *bottom* join *x* = *x* + +Another law is that your analysis must have a "top value" such that + +> *top* join *x* = *top* + +Having a top value ensures that your semilattice has a finite height, and the +law state above ensures that once the dataflow state reaches top, it will no +longer change (the fixpoint will be top). ## Inspecting the Results of a Dataflow Analysis From 79b3788fd7e66ccf813854b1e4f7b65669736aca Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 10 Nov 2020 17:41:40 -0800 Subject: [PATCH 1340/1812] Explain the purpose of the bottom value --- src/mir/dataflow.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index 061ea9038..2bf293cc1 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -92,8 +92,8 @@ statement must be considered separately from the left-hand side. Your analysis must converge to "fixpoint", otherwise it will run forever. Converging to fixpoint is just another way of saying "reaching equilibrium". In order to reach equilibrium, your analysis must obey some laws. One of the -laws it must obey is that the bottom value joined with some other value equals -the second value. Or, as an equation: +laws it must obey is that the bottom value[^bottom-purpose] joined with some +other value equals the second value. Or, as an equation: > *bottom* join *x* = *x* @@ -105,6 +105,10 @@ Having a top value ensures that your semilattice has a finite height, and the law state above ensures that once the dataflow state reaches top, it will no longer change (the fixpoint will be top). +[^bottom-purpose]: The bottom value's primary purpose is as the initial dataflow + state. Each basic block's entry state is initialized to bottom before the + analysis starts. + ## Inspecting the Results of a Dataflow Analysis Once you have constructed an analysis, you must pass it to an [`Engine`], which From 25016aeb3ba66c409f5f0870f4f50730d6ef5cf1 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 11 Nov 2020 12:48:15 -0800 Subject: [PATCH 1341/1812] Provide a brief example of a data-flow analysis --- src/mir/dataflow.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index 2bf293cc1..b5cbd4686 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -109,6 +109,32 @@ longer change (the fixpoint will be top). state. Each basic block's entry state is initialized to bottom before the analysis starts. +## A Brief Example + +This section provides a brief example of a simple data-flow analysis at a high +level. It doesn't explain everything you need to know, but hopefully it will +make the rest of this page clearer. + +Let's say we want to do a simple analysis to find if `mem::transmute` may have +been called by a certain point in the program. Our analysis domain will just +be a `bool` that records whether `transmute` has been called so far. The bottom +value will be `false`, since by default `transmute` has not been called. The top +value will be `true`, since our analysis is done as soon as we determine that +`transmute` has been called. Our join operator will just be the boolean OR (`||`) +operator. We use OR and not AND because of this case: + +``` +let x = if some_cond { + std::mem::transmute(0_i32); // transmute was called! +} else { + 1_u32; // transmute was not called +}; + +// Has transmute been called by this point? We conservatively approximate that +// as yes, and that is why we use the OR operator. +println!("x: {}", x); +``` + ## Inspecting the Results of a Dataflow Analysis Once you have constructed an analysis, you must pass it to an [`Engine`], which From 2777deecfa07fe6d376b6bca9aec5fc2c8731274 Mon Sep 17 00:00:00 2001 From: hosseind88 <72156162+hosseind88@users.noreply.github.com> Date: Sun, 15 Nov 2020 20:44:06 +0330 Subject: [PATCH 1342/1812] add string interning wikipedia link (#960) --- src/overview.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index baa1e0aa6..82f2289e4 100644 --- a/src/overview.md +++ b/src/overview.md @@ -32,7 +32,10 @@ we'll talk about that later. - The token stream passes through a higher-level lexer located in [`rustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations - and turn strings into interned symbols (_interning_ is discussed later). + and turn strings into interned symbols (_interning_ is discussed later). + [String interning] is a way of storing only one immutable + copy of each distinct string value. + - The lexer has a small interface and doesn't depend directly on the diagnostic infrastructure in `rustc`. Instead it provides diagnostics as plain data which are emitted in `rustc_parse::lexer::mod` as real diagnostics. @@ -97,6 +100,7 @@ we'll talk about that later. - The different libraries/binaries are linked together to produce the final binary. +[String interning]: https://en.wikipedia.org/wiki/String_interning [`rustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html [`rustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html [`rustc_interface::Config`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Config.html From 950e4a4a25b1dcff1ff04f70ef37578f0b0fa537 Mon Sep 17 00:00:00 2001 From: Tobias Date: Mon, 16 Nov 2020 18:38:14 +0100 Subject: [PATCH 1343/1812] updated link for Citizen Code of Conduct (#959) * remove the code of conduct; instead link to https://www.rust-lang.org/conduct.html --- CODE_OF_CONDUCT.md | 37 +------------------------------------ 1 file changed, 1 insertion(+), 36 deletions(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 89a9cdfcc..42f287fbb 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,38 +1,3 @@ # The Rust Code of Conduct -A version of this document [can be found online](https://www.rust-lang.org/conduct.html). - -## Conduct - -**Contact**: [rust-mods@rust-lang.org](mailto:rust-mods@rust-lang.org) - -* We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic. -* On IRC, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all. -* Please be kind and courteous. There's no need to be mean or rude. -* Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. -* Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. -* We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behaviour. We interpret the term "harassment" as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups. -* Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the [Rust moderation team](/team.html#Moderation) immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back. -* Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome. - -## Moderation - - -These are the policies for upholding our community's standards of conduct. If you feel that a thread needs moderation, please contact the [Rust moderation team](/team.html#Moderation). - -1. Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.) -2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed. -3. Moderators will first respond to such remarks with a warning. -4. If the warning is unheeded, the user will be "kicked," i.e. kicked out of the communication channel to cool off. -5. If the user comes back and continues to make trouble, they will be banned, i.e. indefinitely excluded. -6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology. -7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed. -8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others. - -In the Rust community we strive to go the extra step to look out for each other. Don't just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they're off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely. - -And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust. - -The enforcement policies listed above apply to all official Rust venues; including official IRC channels (#rust, #rust-internals, #rust-tools, #rust-libs, #rustc, #rust-beginners, #rust-docs, #rust-community, #rust-lang, and #cargo); GitHub repositories under rust-lang, rust-lang-nursery, and rust-lang-deprecated; and all forums under rust-lang.org (users.rust-lang.org, internals.rust-lang.org). For other projects adopting the Rust Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion. - -*Adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](http://contributor-covenant.org/version/1/3/0/).* +This repository follows the [Code of Conduct](https://www.rust-lang.org/conduct.html) of the Rust organization. From 8f5a1440aeef3b30f1def0ffa3977dafc0a00044 Mon Sep 17 00:00:00 2001 From: cjkenn Date: Fri, 20 Nov 2020 12:09:37 -0500 Subject: [PATCH 1344/1812] add mir-opt section for optimization fuel --- src/mir/optimizations.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index 65323ed52..b34520f35 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -60,3 +60,24 @@ want to query whether your optimization pass should run, you can check the current level using `tcx.sess.opts.debugging_opts.mir_opt_level`. [compiler MCP]: https://github.com/rust-lang/compiler-team/issues/319 + +## Optimization fuel + +Optimization fuel is a compiler option (`-Z fuel==`) that allows for fine grained +control over which optimizations can be applied during compilation: each optimization reduces +fuel by 1, and when fuel reaches 0 no more optimizations are applied. This can help with debugging +and identifying problems with optimizations. + +MIR optimizations respect fuel, and in general each pass should check fuel by calling +[`tcx.consider_optimizing`][consideroptimizing] and skipping the optimization if fuel +is empty. There are a few considerations: + +1. If the pass is considered "guaranteed" (for example, it should always be run because it is +needed for correctness), then fuel should not be used. An example of this is `PromoteTemps`. +2. In some cases, an initial pass is performed to gather candidates, which are then iterated to +perform optimizations. In these situations, we should allow for the initial gathering pass +and then check fuel as close to the mutation as possible. This allows for the best +debugging experience, because we can determine where in the list of candidates an optimization +may have been misapplied. Examples of this are `InstCombine` and `ConstantPropagation`. + +[consideroptimizing]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.consider_optimizing From da0701b97974f0036fa942d818a0fdebcf777d8c Mon Sep 17 00:00:00 2001 From: cjkenn Date: Fri, 20 Nov 2020 14:51:29 -0500 Subject: [PATCH 1345/1812] add small explanation of why fuel can be useful for debugging --- src/mir/optimizations.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index b34520f35..080c8fd3f 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -65,8 +65,10 @@ current level using `tcx.sess.opts.debugging_opts.mir_opt_level`. Optimization fuel is a compiler option (`-Z fuel==`) that allows for fine grained control over which optimizations can be applied during compilation: each optimization reduces -fuel by 1, and when fuel reaches 0 no more optimizations are applied. This can help with debugging -and identifying problems with optimizations. +fuel by 1, and when fuel reaches 0 no more optimizations are applied. The primary use of fuel +is debugging optimizations that may be incorrect or misapplied. By changing the fuel +value, you can bisect a compilation session down to the exact incorrect optimization +(this behaves like a kind of binary search through the optimizations). MIR optimizations respect fuel, and in general each pass should check fuel by calling [`tcx.consider_optimizing`][consideroptimizing] and skipping the optimization if fuel From 8e87c1cf0a7e27035aad3938474d0006b619ff13 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 23 Nov 2020 15:10:44 -0800 Subject: [PATCH 1346/1812] Update `param_env` link `rustc_ty` was recently [renamed] to `rustc_ty_utils`, so this link has to be updated. [renamed]: https://github.com/rust-lang/rust/commit/f59d03038c8601a66bd165a2f1980109665d077c --- src/param_env.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/param_env.md b/src/param_env.md index aa6d6e215..9050c5c79 100644 --- a/src/param_env.md +++ b/src/param_env.md @@ -25,7 +25,7 @@ You can get the parameter environment for a `def_id` using the your use case. Using the `ParamEnv` from the surrounding context can allow you to evaluate more things. For example, suppose we had something the following: -[query]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ty/ty/fn.param_env.html +[query]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ty_utils/ty/fn.param_env.html ```rust trait Foo { From 8ebb338abb64ed2089bbe0cbc23c2be4086746eb Mon Sep 17 00:00:00 2001 From: mark Date: Mon, 23 Nov 2020 14:49:04 -0600 Subject: [PATCH 1347/1812] don't use cache while running PR builds --- .travis.yml | 2 +- ci/linkcheck.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index de1392e88..f503eeefa 100644 --- a/.travis.yml +++ b/.travis.yml @@ -12,7 +12,7 @@ before_install: install: - source ~/.cargo/env || true - cargo install mdbook --version '^0.4.3' -- cargo install mdbook-linkcheck --version '^0.7.1' +- cargo install mdbook-linkcheck --version '^0.7.2' script: - git checkout -b ci - git rebase origin/master diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index d827b8476..41cb6a35e 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -15,7 +15,7 @@ elif [ "$CI" = "true" ] ; then # running in PR CI build fi CHANGED_FILES=$(git diff --name-only $TRAVIS_COMMIT_RANGE | tr '\n' ' ') - FLAGS="-f $CHANGED_FILES" + FLAGS="--no-cache -f $CHANGED_FILES" echo "Checking files changed in $TRAVIS_COMMIT_RANGE: $CHANGED_FILES" else # running locally From b5af9f07f25b94f9172e1fa820158129d7008b6e Mon Sep 17 00:00:00 2001 From: Gabriel de Perthuis Date: Tue, 24 Nov 2020 12:20:16 +0100 Subject: [PATCH 1348/1812] Update bootstrap documentation with the new envvars for RUSTFLAGS This follows . --- src/building/bootstrapping.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 2da4d2e46..0921755a0 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -309,12 +309,8 @@ The following tables indicate the outputs of various stage actions: ## Passing stage-specific flags to `rustc` `x.py` allows you to pass stage-specific flags to `rustc` when bootstrapping. -The `RUSTFLAGS_STAGE_0`, `RUSTFLAGS_STAGE_1` and `RUSTFLAGS_STAGE_2` -environment variables pass the given flags when building stage 0, 1, and 2 -artifacts respectively. - -Additionally, the `RUSTFLAGS_STAGE_NOT_0` variable, as its name suggests, passes -the given arguments if the stage is not 0. +The `RUSTFLAGS_BOOTSTRAP` environment variable is passed as RUSTFLAGS to the bootstrap stage +(stage0), and `RUSTFLAGS_NOT_BOOTSTRAP` is passed when building artifacts for later stages. ## Environment Variables From 5f7bd5794239c5eadfa567eaabce2355f574771e Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 24 Nov 2020 17:09:59 -0800 Subject: [PATCH 1349/1812] Document when errors should have an associated error code (#967) Document when errors should have an associated error code --- src/diagnostics.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 04745ee98..fe75c2215 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -70,14 +70,23 @@ example of how to trigger it and advice on how to fix it. Please read [RFC 1567] for details on how to format and write long error codes. -The descriptions are written in markdown, and all of them are linked in the +The descriptions are written in Markdown, and all of them are linked in the [`rustc_error_codes`] crate. -TODO: When should an error use an error code, and when shouldn't it? +As a general rule, give an error a code (with an associated explanation) if the +explanation would give more information than the error itself. A lot of the time +it's better to put all the information in the emitted error itself. However, +sometimes that would make the error verbose or there are too many possible +triggers to include useful information for all cases in the error, in which case +it's a good idea to add an explanation.[^estebank] +As always, if you are not sure, just ask your reviewer! + +[^estebank]: This rule of thumb was suggested by **@estebank** [here][estebank-comment]. [`rustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html [error index]: https://doc.rust-lang.org/error-index.html [RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md +[estebank-comment]: https://github.com/rust-lang/rustc-dev-guide/pull/967#issuecomment-733218283 ### Lints versus fixed diagnostics From 72eca8fcc517033d5d6b6c1e60ff3008bb4edc34 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 23 Nov 2020 14:37:10 -0800 Subject: [PATCH 1350/1812] Document how to modify feature gates How to remove them and how to rename them. cc cc @varkor --- src/SUMMARY.md | 1 + src/feature-gates.md | 65 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+) create mode 100644 src/feature-gates.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 41de14954..62081cd56 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -38,6 +38,7 @@ - [Implementing new features](./implementing_new_features.md) - [Stability attributes](./stability.md) - [Stabilizing Features](./stabilization_guide.md) +- [Feature Gates](./feature-gates.md) - [Coding conventions](./conventions.md) - [Notification groups](notification-groups/about.md) - [ARM](notification-groups/arm.md) diff --git a/src/feature-gates.md b/src/feature-gates.md new file mode 100644 index 000000000..b4aae0443 --- /dev/null +++ b/src/feature-gates.md @@ -0,0 +1,65 @@ +# Feature Gates + +This chapter is intended to provide basic help for modifying feature gates. See +["Stability in code"][stability-section] for help with *adding* feature gates. + +[stability-section]: ./implementing_new_features.md#stability-in-code + + +## Removing a feature gate + +[removing]: #removing-a-feature-gate + +To remove a feature gate, follow these steps: + +1. Remove the feature gate declaration in `rustc_feature/src/active.rs`. + It will look like this: + + ```rust,ignore + /// description of feature + (active, $feature_name, "$version", Some($tracking_issue_number), $edition) + ``` + +2. Add a modified version of the feature gate declaration that you just + removed to `rustc_feature/src/removed.rs`: + + ```rust,ignore + /// description of feature + (removed, $old_feature_name, "$version", Some($tracking_issue_number), $edition, + Some("$why_it_was_removed")) + ``` + + +## Renaming a feature gate + +[renaming]: #renaming-a-feature-gate + +To rename a feature gate, follow these steps (the first two are the same steps +to follow when [removing a feature gate][removing]): + +1. Remove the old feature gate declaration in `rustc_feature/src/active.rs`. + It will look like this: + + ```rust,ignore + /// description of feature + (active, $old_feature_name, "$version", Some($tracking_issue_number), $edition) + ``` + +2. Add a modified version of the old feature gate declaration that you just + removed to `rustc_feature/src/removed.rs`: + + ```rust,ignore + /// description of feature + /// Renamed to `$new_feature_name` + (removed, $old_feature_name, "$version", Some($tracking_issue_number), $edition, + Some("renamed to `$new_feature_name`")) + ``` + +3. Add a feature gate declaration with the new name to + `rustc_feature/src/active.rs`. It should look very similar to the old + declaration: + + ```rust,ignore + /// description of feature + (active, $new_feature_name, "$version", Some($tracking_issue_number), $edition) + ``` From 23b04794dbeae9ec41db13150c51670210bfd6a0 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 23 Nov 2020 15:59:15 -0800 Subject: [PATCH 1351/1812] Move instructions for adding a feature gate to "Feature Gates" --- src/feature-gates.md | 35 +++++++++++++++++++++++++++++--- src/implementing_new_features.md | 22 +++----------------- 2 files changed, 35 insertions(+), 22 deletions(-) diff --git a/src/feature-gates.md b/src/feature-gates.md index b4aae0443..b81721edc 100644 --- a/src/feature-gates.md +++ b/src/feature-gates.md @@ -1,9 +1,35 @@ # Feature Gates -This chapter is intended to provide basic help for modifying feature gates. See -["Stability in code"][stability-section] for help with *adding* feature gates. +This chapter is intended to provide basic help for adding, removing, and +modifying feature gates. -[stability-section]: ./implementing_new_features.md#stability-in-code + +## Adding a feature gate + +See ["Stability in code"][stability-section] for help with adding a new feature; +this section just covers how to add the feature gate *declaration*. + +Add a feature gate declaration to `rustc_feature/src/active.rs` in the active +`declare_features` block: + +```rust,ignore +/// description of feature +(active, $feature_name, "$current_nightly_version", Some($tracking_issue_number), $edition) +``` + +where `$edition` has the type `Option`, and is typically +just `None`. + +For example: + +```rust,ignore +/// Allows defining identifiers beyond ASCII. +(active, non_ascii_idents, "1.0.0", Some(55467), None), +``` + +When added, the current version should be the one for the current nightly. +Once the feature is moved to `accepted.rs`, the version is changed to that +nightly version. ## Removing a feature gate @@ -63,3 +89,6 @@ to follow when [removing a feature gate][removing]): /// description of feature (active, $new_feature_name, "$version", Some($tracking_issue_number), $edition) ``` + + +[stability-section]: ./implementing_new_features.md#stability-in-code diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index baf4e2b51..3a65f15e7 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -127,25 +127,8 @@ a new unstable feature: in the RFC). 3. Add a feature gate declaration to `rustc_feature/src/active.rs` - in the active `declare_features` block: - - ```rust,ignore - /// description of feature - (active, $feature_name, "$current_nightly_version", Some($tracking_issue_number), $edition) - ``` - - where `$edition` has the type `Option`, and is typically - just `None`. - - For example: - - ```rust,ignore - /// Allows defining identifiers beyond ASCII. - (active, non_ascii_idents, "1.0.0", Some(55467), None), - ``` - - When added, the current version should be the one for the current nightly. - Once the feature is moved to `accepted.rs`, the version is changed to that nightly version. + in the active `declare_features` block. See [here][add-feature-gate] for + detailed instructions. 4. Prevent usage of the new feature unless the feature gate is set. You can check it in most places in the compiler using the @@ -182,3 +165,4 @@ a new unstable feature: [stability in code]: #stability-in-code [here]: ./stabilization_guide.md [tracking issue]: #tracking-issue +[add-feature-gate]: ./feature-gates.md#adding-a-feature-gate From f9b3946411ad4b675b2036ba3cf6389f69a867ed Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 23 Nov 2020 16:06:24 -0800 Subject: [PATCH 1352/1812] Link to feature-stabilization docs --- src/feature-gates.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/feature-gates.md b/src/feature-gates.md index b81721edc..db6c72ff8 100644 --- a/src/feature-gates.md +++ b/src/feature-gates.md @@ -6,8 +6,8 @@ modifying feature gates. ## Adding a feature gate -See ["Stability in code"][stability-section] for help with adding a new feature; -this section just covers how to add the feature gate *declaration*. +See ["Stability in code"] for help with adding a new feature; this section just +covers how to add the feature gate *declaration*. Add a feature gate declaration to `rustc_feature/src/active.rs` in the active `declare_features` block: @@ -91,4 +91,12 @@ to follow when [removing a feature gate][removing]): ``` -[stability-section]: ./implementing_new_features.md#stability-in-code +## Stabilizing a feature + +See ["Updating the feature-gate listing"] in the "Stabilizing Features" chapter +for instructions. There are additional steps you will need to take beyond just +updating the declaration! + + +["Stability in code"]: ./implementing_new_features.md#stability-in-code +["Updating the feature-gate listing"]: ./stabilization_guide.md#updating-the-feature-gate-listing From ad67023401f7f897492a9c7ff73c99d79afe557c Mon Sep 17 00:00:00 2001 From: Hirochika Matsumoto Date: Sun, 29 Nov 2020 04:02:07 +0900 Subject: [PATCH 1353/1812] Fix a typo --- src/compiler-src.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index 5183a7c85..b26ede579 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -20,7 +20,7 @@ tools and submodules for building a full Rust distribution. As of this writing, this structure is gradually undergoing some transformation to make it a bit less monolithic and more approachable, especially to -newcommers. +newcomers. The repository consists of a `src` directory, under which there live many crates, which are the source for the compiler, build system, tools, etc. This From 4663f85bd0215149e66fb251054c56e033312736 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 29 Nov 2020 09:46:27 -0500 Subject: [PATCH 1354/1812] Add information about common git issues --- src/git.md | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 50 insertions(+), 1 deletion(-) diff --git a/src/git.md b/src/git.md index f567188de..b4968df81 100644 --- a/src/git.md +++ b/src/git.md @@ -73,6 +73,55 @@ the same, with some steps skipped: 2. Make, stage, and commit your additional changes just like before. 3. Push those changes to your fork: `git push`. +## Troubleshooting git issues + +You don't need to clone `rust-lang/rust` from scratch if it's out of date! +Even if you think you've messed it up beyond repair, there are ways to fix +the git state that don't require downloading the whole repository again. +Here are some common issues you might run into: + +### I deleted my fork on GitHub! + +This is not a problem from git's perspective. If you run `git remote -v`, +it will say something like this: + +``` +$ git remote -v +origin https://github.com//rust-lang/rust (fetch) +origin https://github.com//rust-lang/rust (push) +personal https://github.com/jyn514/rust (fetch) +personal https://github.com/jyn514/rust (push) +``` + +You can change the URL of the fork like this: + +```console +git remote set-url personal +``` + +where the is your new fork. + +### I see 'Untracked Files: src/stdarch'? + +This is left over from the move to the `library/` directory. +Unfortunately, `git rebase` does not follow renames for submodules, so you +have to delete the directory yourself: + +```console +rm -r src/stdarch +``` + +### I see `<<< HEAD`? + +You were probably in the middle of a rebase or merge conflict. See +[Conflicts](#conflicts) for how to fix the conflict. If you don't care about the changes +and just want to get a clean copy of the repository back, you can use `git reset`: + +```console +# WARNING: this throws out any local changes you've made! Consider resolving the conflicts instead. +git reset --hard master +``` + ### Quick note about submodules When updating your local repository with `git pull`, you may notice that sometimes @@ -94,7 +143,7 @@ no changes added to commit (use "git add" and/or "git commit -a") ``` These changes are not changes to files: they are changes to submodules -(more on this later). To get rid of those, run `git submodule update` (or run any +(more on this [later](#git-submodules)). To get rid of those, run `git submodule update` (or run any `x.py` command, which will automatically update the submodules). Note that there is currently a bug if you use worktrees, submodules, and x.py in a commit hook. If you run into an error like: From eb8fefbea0c77d69ea237b5e6a61181565cda8de Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 29 Nov 2020 10:32:07 -0500 Subject: [PATCH 1355/1812] Don't imply that the name of the fork always needs to be changed --- src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/git.md b/src/git.md index b4968df81..d1e6b8c41 100644 --- a/src/git.md +++ b/src/git.md @@ -93,7 +93,7 @@ personal https://github.com/jyn514/rust (fetch) personal https://github.com/jyn514/rust (push) ``` -You can change the URL of the fork like this: +If you renamed your fork, you can change the URL like this: ```console git remote set-url personal From 59de3a0c58de156b2f6c833680daa16c76152a8f Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 29 Nov 2020 10:20:24 -0500 Subject: [PATCH 1356/1812] Document what 'sysroot' means --- src/appendix/glossary.md | 1 + src/building/bootstrapping.md | 59 +++++++++++++++++++++++++++++++++++ 2 files changed, 60 insertions(+) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 58ec39e4f..8ecd4f615 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -72,6 +72,7 @@ Term | Meaning soundness | A technical term in type theory. Roughly, if a type system is sound, then a program that type-checks is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). span | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). +sysroot | The directory for build artifacts that are loaded by the compiler at runtime. ([see more](../building/bootstrapping.html#what-is-a-sysroot)) Tag | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). tcx | The "typing context", main data structure of the compiler. ([see more](../ty.md)) `'tcx` | The lifetime of the allocation arena. ([see more](../ty.md)) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 0921755a0..1d420a978 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -264,6 +264,65 @@ is built by the _beta_ compiler, but using the _master_ version of libstd! The only time `rustc` uses `cfg(bootstrap)` is when it adds internal lints that use diagnostic items. This happens very rarely. +### What is a 'sysroot'? + +When you build a project with cargo, the build artifacts for dependendencies +are normally stored in `target/debug/deps`. This only contains dependencies cargo +knows about; in particular, it doesn't have the standard library. Where do +`std` or `proc_macro` come from? It comes from the **sysroot**, the root +of a number of directories where the compiler loads build artifacts at runtime. +The sysroot doesn't just store the standard library, though - it includes +anything that needs to be loaded at runtime. That includes (but is not limited +to): + +- `libstd`/`libtest`/`libproc_macro` +- The compiler crates themselves, when using `rustc_private`. In-tree these + are always present; out of tree, you need to install `rustc-dev` with rustup. +- `libLLVM.so`, the shared object file for the LLVM project. In-tree this is + either built from source or downloaded from CI; out-of-tree, you need to + install `llvm-tools-preview` with rustup. + +All the artifacts listed so far are *compiler* runtime dependencies. You can +see them with `rustc --print sysroot`: + +``` +$ ls $(rustc --print sysroot)/lib +libchalk_derive-0685d79833dc9b2b.so libstd-25c6acf8063a3802.so +libLLVM-11-rust-1.50.0-nightly.so libtest-57470d2aa8f7aa83.so +librustc_driver-4f0cc9f50e53f0ba.so libtracing_attributes-e4be92c35ab2a33b.so +librustc_macros-5f0ec4a119c6ac86.so rustlib +``` + +There are also runtime dependencies for the standard library! These are in +`lib/rustlib`, not `lib/` directly. + +``` +$ ls $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/lib | head -n 5 +libaddr2line-6c8e02b8fedc1e5f.rlib +libadler-9ef2480568df55af.rlib +liballoc-9c4002b5f79ba0e1.rlib +libcfg_if-512eb53291f6de7e.rlib +libcompiler_builtins-ef2408da76957905.rlib +``` + +`rustlib` includes libraries like `hashbrown` and `cfg_if`, which are not part +of the public API of the standard library, but are used to implement it. +`rustlib` is part of the search path for linkers, but `lib` will never be part +of the search path. + +Since `rustlib` is part of the search path, it means we have to be careful +about which crates are included in it. In particular, all crates except for +the standard library are built with the flag `-Z force-unstable-if-unmarked`, +which means that you have to use `#![feature(rustc_private)]` in order to +load it (as opposed to the standard library, which is always available). + +You can find more discussion about sysroots in: +- The [rustdoc PR] explaining why it uses `extern crate` for dependencies loaded from sysroot +- [Discussions about sysroot on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/deps.20in.20sysroot/) +- [Discussions about building rustdoc out of tree](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/How.20to.20create.20an.20executable.20accessing.20.60rustc_private.60.3F) + +[rustdoc PR]: https://github.com/rust-lang/rust/pull/76728 + ### Directories and artifacts generated by x.py The following tables indicate the outputs of various stage actions: From e66adf6bb56e44bfa1cf5a58d915600ae6dae80f Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 30 Nov 2020 09:08:32 -0500 Subject: [PATCH 1357/1812] Improve contributor experience for the dev-guide itself (#973) - Fix typos in the README - Don't echo all instructions in the linkcheck.sh shellscript; this is noisy and unhelpful when developing locally. Verbose output is still enabled in CI. - Link to the index page for compiler docs, not `rustc_middle`. Note that the compiler docs are not a guide - that's us! - Remove outdated instructions about avoiding 429s. These should no longer be occurring locally now that we're using caching. - Consolidate info about `mdbook` and `mdbook-linkcheck` near each other --- README.md | 67 ++++++++----------------------------------------- ci/linkcheck.sh | 4 ++- 2 files changed, 14 insertions(+), 57 deletions(-) diff --git a/README.md b/README.md index 143ecca16..5448ca9bb 100644 --- a/README.md +++ b/README.md @@ -9,8 +9,10 @@ some new part of the compiler that they haven't worked on before. [You can read the latest version of the guide here.](https://rustc-dev-guide.rust-lang.org/) You may also find the rustdocs [for the compiler itself][rustdocs] useful. +Note that these are not intended as a guide; it's recommended that you search +for the docs you're looking for instead of reading them top to bottom. -[rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ +[rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc ### Contributing to the guide @@ -35,37 +37,10 @@ rustdocs][rustdocs]. ### Build Instructions -Deactivate the CI testing link validations by commenting out the `[output.linkcheck]` field in the `book.toml` configuration file like this: - -```toml -[book] -title = "Guide to Rustc Development" -author = "Rustc developers" -description = "A guide to developing rustc" - -[build] -create-missing = false - -[output.html] -git-repository-url = "https://github.com/rust-lang/rustc-dev-guide" - -[output.html.fold] -enable = true -level = 1 - -# [output.linkcheck] -# follow-web-links = false -# exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il" ] -# cache-timeout = 172800 -# warning-policy = "error" -``` - -These validations can cause errors during local builds (see Link Validations section below). Please **do not** commit these `book.toml` file changes when you submit a pull request. - To build a local static HTML site, install [`mdbook`](https://github.com/rust-lang/mdBook) with: ``` -> cargo install mdbook +> cargo install mdbook mdbook-linkcheck ``` and execute the following command in the root of the repository: @@ -76,6 +51,11 @@ and execute the following command in the root of the repository: The build files are found in the `book` directory. +### Link Validations + +We use `mdbook-linkcheck` to validate URLs included in our documentation. +`linkcheck` will be run automatically when you build with the instructions in the section above. + ### Pre-commit script We also test that line lengths are less than 100 columns. To test this locally, @@ -95,36 +75,11 @@ On Windows: New-Item -Path .git/hooks/pre-commit -ItemType HardLink -Value ``` -### Link Validations - -We use `mdbook-linkcheck` to validate URLs included in our documentation. To perform link checks, uncomment the `[output.linkcheck]` field in the `book.toml` configuration file and install `mdbook-linkcheck` with: - -```bash -> cargo install mdbook-linkcheck -``` - -You will need recent versions of `mdbook` and `mdbook-linkcheck` to check links. -`linkcheck` will be run automatically when you build with the instructions in the section above. - -**Please note**: You may receive errors like the following when link-checking is enabled on local `mdbook` builds: - -``` -error: The server responded with 429 Too Many Requests for "https://github.com/rust-lang/rust/tree/master/src/tools/compiletest" - - ┌── tests/intro.md:6:1 ─── - │ - 6 │ [`src/tools/compiletest`] directory). This section gives a brief - │ ^ Server responded with 429 Too Many Requests -``` - -There is not a workaround for this error at the moment. Comment out the `[output.linkcheck]` field in the `book.toml` using the build instructions above to complete a local site build without link validations. - - ## How to fix toolstate failures > **NOTE**: Currently, we do not track the rustc-dev-guide toolstate due to -[the spurious failure](https://github.com/rust-lang/rust/pull/71731), -but we leave this instructions for when we do it again in the future. +[spurious failures](https://github.com/rust-lang/rust/pull/71731), +but we leave these instructions for when we do it again in the future. 1. You will get a ping from the toolstate commit. e.g. https://github.com/rust-lang-nursery/rust-toolstate/commit/8ffa0e4c30ac9ba8546b7046e5c4ccc2b96ebdd4 diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index 41cb6a35e..d329a7164 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -1,6 +1,6 @@ #!/usr/bin/env bash -set -ev +set -e set -o pipefail # https://docs.travis-ci.com/user/environment-variables/#default-environment-variables @@ -8,6 +8,7 @@ if [ "$TRAVIS_EVENT_TYPE" = "cron" ] ; then # running in cron job FLAGS="" echo "Doing full link check." + set -x elif [ "$CI" = "true" ] ; then # running in PR CI build if [ -z "$TRAVIS_COMMIT_RANGE" ]; then echo "error: unexpected state: TRAVIS_COMMIT_RANGE must be non-empty in CI" @@ -18,6 +19,7 @@ elif [ "$CI" = "true" ] ; then # running in PR CI build FLAGS="--no-cache -f $CHANGED_FILES" echo "Checking files changed in $TRAVIS_COMMIT_RANGE: $CHANGED_FILES" + set -x else # running locally COMMIT_RANGE=master... CHANGED_FILES=$(git diff --name-only $COMMIT_RANGE | tr '\n' ' ') From fb6176d2a2fe409f3d93cdd5ecede98406d4d33e Mon Sep 17 00:00:00 2001 From: Ben Striegel Date: Sun, 29 Nov 2020 12:38:44 -0500 Subject: [PATCH 1358/1812] Add notes about running the UI test suite --- src/tests/running.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/src/tests/running.md b/src/tests/running.md index 5e18b8a95..15f11cb47 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -59,6 +59,43 @@ Likewise, you can test a single file by passing its path: ./x.py test src/test/ui/const-generics/const-test.rs ``` +### Run the UI test suite + +The UI test suite is special in that it tests the command-line output +of the compiler, e.g. the wording and formatting of warnings and errors. +Every UI test file such as `foo.rs` will have a corresponding file +`foo.stderr` describing its expected output. + +Similar to any other test suite, the UI test suite can be run with: + +```bash +./x.py test src/test/ui +``` + +If you have made a change to the way that the compiler formats its output, +it would be extraordinarily tedious to have to reformat every `*.stderr` +file manually. Fortunately there exists a flag that will allow you to +"bless" the current output of the compiler as the expected output. +When using this flag with the test runner, any UI tests that would +ordinarily fail will instead have their `*.stderr` files overwritten +with whatever output the compiler produces: + +```bash +./x.py test src/test/ui --bless +``` + +Some UI tests will have different output depending on which "mode" that +the compiler is in. Specifically, the compiler may have different output +depending on whether the feature "non-lexical lifetimes" (NLL) is enabled. +Any UI test such as `foo.rs` whose output differs with NLL enabled will +have both a `foo.stderr` file and a `foo.nll.stderr` file. +By default, the UI test suite will not be run in NLL mode. +To run the UI test suite in NLL mode, use the following: + +```bash +./x.py test src/test/ui --compare-mode=nll +``` + ### Run only the tidy script ```bash From dc722209253a083a7af8ead7e829b99b8841fec1 Mon Sep 17 00:00:00 2001 From: Ben Striegel Date: Mon, 30 Nov 2020 18:02:07 -0500 Subject: [PATCH 1359/1812] Address feedback --- src/tests/running.md | 52 +++++++++++++------------------------------- 1 file changed, 15 insertions(+), 37 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index 15f11cb47..4fe61f30a 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -59,43 +59,6 @@ Likewise, you can test a single file by passing its path: ./x.py test src/test/ui/const-generics/const-test.rs ``` -### Run the UI test suite - -The UI test suite is special in that it tests the command-line output -of the compiler, e.g. the wording and formatting of warnings and errors. -Every UI test file such as `foo.rs` will have a corresponding file -`foo.stderr` describing its expected output. - -Similar to any other test suite, the UI test suite can be run with: - -```bash -./x.py test src/test/ui -``` - -If you have made a change to the way that the compiler formats its output, -it would be extraordinarily tedious to have to reformat every `*.stderr` -file manually. Fortunately there exists a flag that will allow you to -"bless" the current output of the compiler as the expected output. -When using this flag with the test runner, any UI tests that would -ordinarily fail will instead have their `*.stderr` files overwritten -with whatever output the compiler produces: - -```bash -./x.py test src/test/ui --bless -``` - -Some UI tests will have different output depending on which "mode" that -the compiler is in. Specifically, the compiler may have different output -depending on whether the feature "non-lexical lifetimes" (NLL) is enabled. -Any UI test such as `foo.rs` whose output differs with NLL enabled will -have both a `foo.stderr` file and a `foo.nll.stderr` file. -By default, the UI test suite will not be run in NLL mode. -To run the UI test suite in NLL mode, use the following: - -```bash -./x.py test src/test/ui --compare-mode=nll -``` - ### Run only the tidy script ```bash @@ -195,6 +158,21 @@ Note that incremental compilation will use more disk space than usual. If disk space is a concern for you, you might want to check the size of the `build` directory from time to time. +## Running tests with different "compare modes" + +UI tests may have different output depending on certain "modes" that +the compiler is in. For example, when in "non-lexical lifetimes" (NLL) +mode a test `foo.rs` will first look for expected output in +`foo.nll.stderr`, falling back to the usual `foo.stderr` if not found. +To run the UI test suite in NLL mode, one would use the following: + +```bash +./x.py test src/test/ui --compare-mode=nll +``` + +Other examples of compare-modes are "noopt", "migrate", and +[revisions](./adding.html#revisions). + ## Running tests manually Sometimes it's easier and faster to just run the test by hand. Most tests are From 792ccb1523852923729df5e170f6ecf9acd70e3b Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 30 Nov 2020 18:08:17 -0500 Subject: [PATCH 1360/1812] Move the bootstrapping section later in the guide (#975) Now that `x.py build` works in most cases, I don't think we need to teach people all the intricacies of bootstrap right away. This moves it to the 'overview of the compiler' section instead. --- src/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 62081cd56..fbeedbe15 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -11,7 +11,6 @@ - [How to Build and Run the Compiler](./building/how-to-build-and-run.md) - [Prerequisites](./building/prerequisites.md) - [Suggested Workflows](./building/suggested.md) - - [Bootstrapping](./building/bootstrapping.md) - [Distribution artifacts](./building/build-install-distribution-artifacts.md) - [Documenting Compiler](./building/compiler-documenting.md) - [Rustdoc](./rustdoc.md) @@ -53,6 +52,7 @@ - [Prologue](./part-2-intro.md) - [Overview of the Compiler](./overview.md) - [The compiler source code](./compiler-src.md) +- [Bootstrapping](./building/bootstrapping.md) - [Queries: demand-driven compilation](./query.md) - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md) - [Incremental compilation](./queries/incremental-compilation.md) From 29c66a3f0211fbaaedfe4146e92e8115d45b54ae Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 1 Dec 2020 10:52:02 -0800 Subject: [PATCH 1361/1812] Use shorter 'rustbot label' command 'rustbot modify labels: ...' -> 'rustbot label ...' --- src/rustbot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustbot.md b/src/rustbot.md index 8e952c3f2..5350f44ef 100644 --- a/src/rustbot.md +++ b/src/rustbot.md @@ -41,7 +41,7 @@ PR. Once you do rebase your branch, you should change the labels yourself to rem the `S-waiting-on-author` label and add back `S-waiting-on-review`. In this case, the `@rustbot` command will look like this: - @rustbot modify labels: -S-waiting-on-author +S-waiting-on-review + @rustbot label -S-waiting-on-author +S-waiting-on-review The syntax for this command is pretty loose, so there are other variants of this command invocation. For more details, see [the wiki page about labeling][labeling]. From f7d7e48874068bb6baeebafb5b1830d94713ab13 Mon Sep 17 00:00:00 2001 From: jumbatm Date: Mon, 16 Nov 2020 17:48:41 +1000 Subject: [PATCH 1362/1812] Document SessionDiagnostic --- src/SUMMARY.md | 1 + src/diagnostics.md | 4 ++ src/diagnostics/sessiondiagnostic.md | 97 ++++++++++++++++++++++++++++ 3 files changed, 102 insertions(+) create mode 100644 src/diagnostics/sessiondiagnostic.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index fbeedbe15..43df9bdb5 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -128,6 +128,7 @@ - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) - [Parameter Environments](./param_env.md) - [Errors and Lints](diagnostics.md) + - [Creating Errors With SessionDiagnostic](./diagnostics/sessiondiagnostic.md) - [`LintStore`](./diagnostics/lintstore.md) - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) diff --git a/src/diagnostics.md b/src/diagnostics.md index fe75c2215..f9217785d 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -347,6 +347,10 @@ if let Ok(snippet) = sess.source_map().span_to_snippet(sp) { err.emit(); ``` +Alternatively, for less-complex diagnostics, the `SessionDiagnostic` derive +macro can be used -- see [Creating Errors With SessionDiagnostic](./diagnostics/sessiondiagnostic.md). + + ## Suggestions In addition to telling the user exactly _why_ their code is wrong, it's diff --git a/src/diagnostics/sessiondiagnostic.md b/src/diagnostics/sessiondiagnostic.md new file mode 100644 index 000000000..b64c62007 --- /dev/null +++ b/src/diagnostics/sessiondiagnostic.md @@ -0,0 +1,97 @@ +# Creating Errors With SessionDiagnostic + +The SessionDiagnostic derive macro gives an alternate way to the DiagnosticBuilder API for defining +and emitting errors. It allows a struct to be annotated with information which allows it to be +transformed and emitted as a Diagnostic. + +As an example, we'll take a look at how the "field already declared" diagnostic is actually defined +in the compiler (see the definition +[here](https://github.com/rust-lang/rust/blob/75042566d1c90d912f22e4db43b6d3af98447986/compiler/rustc_typeck/src/errors.rs#L65-L74) +and usage +[here](https://github.com/rust-lang/rust/blob/75042566d1c90d912f22e4db43b6d3af98447986/compiler/rustc_typeck/src/collect.rs#L863-L867)): + +```rust,ignore +#[derive(SessionDiagnostic)] +#[error = "E0124"] +pub struct FieldAlreadyDeclared { + pub field_name: Ident, + #[message = "field `{field_name}` is already declared"] + #[label = "field already declared"] + pub span: Span, + #[label = "`{field_name}` first declared here"] + pub prev_span: Span, +} +// ... +tcx.sess.emit_err(FieldAlreadyDeclared { + field_name: f.ident, + span: f.span, + prev_span, +}); +``` + +We see that using `SessionDiagnostic` is relatively straight forward. The `#[error = "..."]` +attribute is used to supply the error code for the diagnostic. We are then annotate fields in the +struct with various information of how to convert an instance of the struct into a proper +diagnostic. The attributes above produce code which is roughly equivalent to the following (in +pseudo-Rust): + +```rust,ignore +impl SessionDiagnostic for FieldAlreadyDeclared { + fn into_diagnostic(self, sess: &'_ rustc_session::Session) -> DiagnosticBuilder<'_> { + let mut diag = sess.struct_err_with_code("", rustc_errors::DiagnosticId::Error("E0124")); + diag.set_span(self.span); + diag.set_primary_message(format!("field `{field_name}` is already declared", field_name = self.field_name)); + diag.span_label(self.span, "field already declared"); + diag.span_label(self.prev_span, format!("`{field_name}` first declared here", field_name = self.field_name)); + diag + } +} +``` + +The generated code draws attention to a number of features. First, we see that within the strings +passed to each attribute, we see that field names can be referenced without needing to be passed +explicitly into the format string -- in this example here, `#[message = "field {field_name} is +already declared"]` produces a call to `format!` with the appropriate arguments to format +`self.field_name` into the string. This applies to strings passed to all attributes. + +We also see that labelling `Span` fields in the struct produces calls which pass that `Span` to the +produced diagnostic. In the example above, we see that putting the `#[message = "..."]` attribute +on a `Span` leads to the primary span of the diagnostic being set to that `Span`, while applying the +`#[label = "..."]` attribute on a Span will simply set the span for that label. +Each attribute has different requirements for what they can be applied on, differing on position +(on the struct, or on a specific field), type (if it's applied on a field), and whether or not the +attribute is optional. + +## Attributes Listing + +Below is a listing of all the currently-available attributes that `#[derive(SessionDiagnostic)]` +understands: + +Attribute | Applied to | Mandatory | Behaviour +:-------------- | :-------------------- |:--------- | :--------- +`#[code = "..."]` | Struct | Yes | Sets the Diagnostic's error code +`#[message = "..."]` | Struct / `Span` fields | Yes | Sets the Diagnostic's primary message. If on `Span` field, also sets the Diagnostic's span. +`#[label = "..."]` | `Span` fields | No | Equivalent to calling `span_label` with that Span and message. +`#[suggestion(message = "..." , code = "..."]` | `(Span, MachineApplicability)` or `Span` fields | No | Equivalent to calling `span_suggestion`. Note `code` is optional. +`#[suggestion_short(message = "..." , code = "..."]` | `(Span, MachineApplicability)` or `Span` fields | No | Equivalent to calling `span_suggestion_short`. Note `code` is optional. +`#[suggestion_hidden(message = "..." , code = "..."]` | `(Span, MachineApplicability)` or `Span` fields | No | Equivalent to calling `span_suggestion_hidden`. Note `code` is optional. +`#[suggestion_verbose(message = "..." , code = "..."]` | `(Span, MachineApplicability)` or `Span` fields | No | Equivalent to calling `span_suggestion_verbose`. Note `code` is optional. + + +## Optional Diagnostic Attributes + +There may be some cases where you want one of the decoration attributes to be applied optionally; +for example, if a suggestion can only be generated sometimes. In this case, simply wrap the field's +type in an `Option`. At runtime, if the field is set to `None`, the attribute for that field won't +be used in creating the diagnostic. For example: + +```rust,ignored +#[derive(SessionDiagnostic)] +#[code = "E0123"] +struct SomeKindOfError { + ... + #[suggestion(message = "informative error message")] + opt_sugg: Option<(Span, Applicability)> + ... +} +``` From 36583039881ee3090fb5263f1a23640cd9f6081d Mon Sep 17 00:00:00 2001 From: jumbatm Date: Mon, 16 Nov 2020 17:48:41 +1000 Subject: [PATCH 1363/1812] Apply suggestions from review. Co-authored-by: Camelid --- src/diagnostics/sessiondiagnostic.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/diagnostics/sessiondiagnostic.md b/src/diagnostics/sessiondiagnostic.md index b64c62007..4583e6d3d 100644 --- a/src/diagnostics/sessiondiagnostic.md +++ b/src/diagnostics/sessiondiagnostic.md @@ -30,8 +30,8 @@ tcx.sess.emit_err(FieldAlreadyDeclared { ``` We see that using `SessionDiagnostic` is relatively straight forward. The `#[error = "..."]` -attribute is used to supply the error code for the diagnostic. We are then annotate fields in the -struct with various information of how to convert an instance of the struct into a proper +attribute is used to supply the error code for the diagnostic. We then annotate fields in the +struct with various information on how to convert an instance of the struct into a rendered diagnostic. The attributes above produce code which is roughly equivalent to the following (in pseudo-Rust): @@ -49,7 +49,7 @@ impl SessionDiagnostic for FieldAlreadyDeclared { ``` The generated code draws attention to a number of features. First, we see that within the strings -passed to each attribute, we see that field names can be referenced without needing to be passed +passed to each attribute, field names can be referenced without needing to be passed explicitly into the format string -- in this example here, `#[message = "field {field_name} is already declared"]` produces a call to `format!` with the appropriate arguments to format `self.field_name` into the string. This applies to strings passed to all attributes. From 459e414b3a7041a7f1edd0d1f4273aa85bd876c5 Mon Sep 17 00:00:00 2001 From: jumbatm Date: Mon, 16 Nov 2020 17:48:41 +1000 Subject: [PATCH 1364/1812] Use shorter [][]-style link to not pass 100 chars. --- src/diagnostics.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index f9217785d..fce79d725 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -348,7 +348,9 @@ err.emit(); ``` Alternatively, for less-complex diagnostics, the `SessionDiagnostic` derive -macro can be used -- see [Creating Errors With SessionDiagnostic](./diagnostics/sessiondiagnostic.md). +macro can be used -- see [Creating Errors With SessionDiagnostic][sessiondiagnostic]. + +[sessiondiagnostic]: ./diagnostics/sessiondiagnostic.md ## Suggestions From f98c407fcdc4c4e3743e9e08771dbabecd633ba2 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 2 Dec 2020 22:37:22 -0600 Subject: [PATCH 1365/1812] exclude play.rlo from linkchecks --- book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book.toml b/book.toml index af909446a..af9cd167f 100644 --- a/book.toml +++ b/book.toml @@ -16,6 +16,6 @@ level = 0 [output.linkcheck] command = "../../ci/linkcheck.sh" follow-web-links = true -exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il", "www\\.amazon\\.com", "www\\.rustaceans\\.org" ] +exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il", "www\\.amazon\\.com", "www\\.rustaceans\\.org", "play\\.rust-lang\\.org" ] cache-timeout = 86400 warning-policy = "error" From af2aa997d064b83c05573373768147a05cfcd7b3 Mon Sep 17 00:00:00 2001 From: mark Date: Wed, 2 Dec 2020 22:40:36 -0600 Subject: [PATCH 1366/1812] fix a couple links --- src/pat-exhaustive-checking.md | 8 ++++---- src/traits/hrtb.md | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/pat-exhaustive-checking.md b/src/pat-exhaustive-checking.md index 767b7de50..a3103de8f 100644 --- a/src/pat-exhaustive-checking.md +++ b/src/pat-exhaustive-checking.md @@ -80,9 +80,9 @@ fn foo(Foo { x, y }: Foo) { ## The algorithm -Exhaustiveness checking is implemented in [check_match]. -The core of the algorithm is in [_match]. +Exhaustiveness checking is implemented in [`check_match`]. +The core of the algorithm is in [`usefulness`]. That file contains a detailed description of the algorithm. -[check_match]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/pattern/check_match/index.html -[_match]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/pattern/_match/index.html +[`check_match`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/pattern/check_match/index.html +[`usefulness`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/pattern/usefulness/index.html diff --git a/src/traits/hrtb.md b/src/traits/hrtb.md index c0ca318e6..aa85448af 100644 --- a/src/traits/hrtb.md +++ b/src/traits/hrtb.md @@ -42,7 +42,7 @@ subtyping, we recommend you read the paper). There are a few parts: [hrsubtype]: ./hrtb.md [placeholder]: ../appendix/glossary.html#placeholder -[paper by SPJ]: http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ +[paper by SPJ]: https://www.microsoft.com/en-us/research/publication/practical-type-inference-for-arbitrary-rank-types So let's work through our example. From 55c7be5d83d68ca2ae82dd29d3efa2f748e7ea55 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Fri, 4 Dec 2020 12:23:46 -0500 Subject: [PATCH 1367/1812] Link to the Rustdoc book in the rustdoc chapter (#981) This makes a) makes it easier to find info about rustdoc's features and b) redirects people in the wrong place to where they should be looking. --- src/rustdoc.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/rustdoc.md b/src/rustdoc.md index b37c15808..c087689d9 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -2,6 +2,8 @@ Rustdoc actually uses the rustc internals directly. It lives in-tree with the compiler and standard library. This chapter is about how it works. +For information about Rustdoc's features and how to use them, see +the [Rustdoc book](https://doc.rust-lang.org/nightly/rustdoc/). Rustdoc is implemented entirely within the crate [`librustdoc`][rd]. It runs the compiler up to the point where we have an internal representation of a From 02068c0612a51099a864936c8110470d127800bf Mon Sep 17 00:00:00 2001 From: Siddharth Date: Sun, 6 Dec 2020 19:10:45 +0530 Subject: [PATCH 1368/1812] Add links to the rust documentation for all MIR structs (#982) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Add links to the rust documentation for all MIR structs * Update src/mir/index.md Co-authored-by: Léo Lanteri Thauvin * Update src/mir/index.md Co-authored-by: Léo Lanteri Thauvin Co-authored-by: Léo Lanteri Thauvin --- src/mir/index.md | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/src/mir/index.md b/src/mir/index.md index f771fa0ed..df47151a3 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -221,26 +221,28 @@ function (along with sub-instances of Mir for "promoted constants", but [you can read about those below](#promoted)). - **Basic blocks**: The basic blocks are stored in the field - `basic_blocks`; this is a vector of `BasicBlockData` - structures. Nobody ever references a basic block directly: instead, - we pass around `BasicBlock` values, which are - [newtype'd] indices into this vector. -- **Statements** are represented by the type `Statement`. + [`Body::basic_blocks`][basicblocks]; this is a vector + of [`BasicBlockData`] structures. Nobody ever references a + basic block directly: instead, we pass around [`BasicBlock`] + values, which are [newtype'd] indices into this vector. +- **Statements** are represented by the type [`Statement`]. - **Terminators** are represented by the `Terminator`. -- **Locals** are represented by a [newtype'd] index type `Local`. The - data for a local variable is found in the `Mir` (the `local_decls` +- **Locals** are represented by a [newtype'd] index type [`Local`]. + The data for a local variable is found in the `Mir` (the `local_decls` vector). There is also a special constant `RETURN_PLACE` identifying the special "local" representing the return value. -- **Places** are identified by the enum `Place`. There are a few variants: +- **Places** are identified by the enum [`Place`]. There are a few + variants: - Local variables like `_1` - Static variables `FOO` - **Projections**, which are fields or other things that "project - out" from a base place. So e.g. the place `_1.f` is a projection, + out" from a base place. These are represented by the type + [`Projection`]. So e.g. the place `_1.f` is a projection, with `f` being the "projection element and `_1` being the base path. `*_1` is also a projection, with the `*` being represented by the `ProjectionElem::Deref` element. -- **Rvalues** are represented by the enum `Rvalue`. -- **Operands** are represented by the enum `Operand`. +- **Rvalues** are represented by the enum [`Rvalue`]. +- **Operands** are represented by the enum [`Operand`]. ## Representing constants @@ -256,3 +258,12 @@ but [you can read about those below](#promoted)). [mir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html [mirmanip]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html [newtype'd]: ../appendix/glossary.html#newtype +[basicblocks](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.basic_blocks) +[`BasicBlock`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.BasicBlock.html +[`BasicBlockData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.BasicBlockData.html +[`Statement`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Statement.html +[`Terminator`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/terminator/struct.Terminator.html +[`Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Local.html +[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html +[`Rvalue`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.Rvalue.html +[`Operand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.Operand.html From edc94c0c84615a59b22ff92b504529940e175906 Mon Sep 17 00:00:00 2001 From: Siddharth Date: Sun, 6 Dec 2020 20:06:52 +0530 Subject: [PATCH 1369/1812] Edit the Mir page to fix infelicities. (#984) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Edit the Mir page to fix infelicities. - Remove dead reference to Mir. reflow sentence to talk about `Body::local_decls` - Fix broken links to render properly. - Add links for `Terminator`, `RETURN_PLACE`, `ProjectionElem`. * Update src/mir/index.md Co-authored-by: Léo Lanteri Thauvin * Edit the Mir page to fix infelicities. - Remove dead reference to Mir. reflow sentence to talk about `Body::local_decls` - Fix broken links to render properly. - Add links for `Terminator`, `RETURN_PLACE`, `ProjectionElem`. Co-authored-by: Léo Lanteri Thauvin --- src/mir/index.md | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/src/mir/index.md b/src/mir/index.md index df47151a3..55a4a4349 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -216,31 +216,31 @@ The MIR data types are defined in the [`compiler/rustc_middle/src/mir/`][mir] module. Each of the key concepts mentioned in the previous section maps in a fairly straightforward way to a Rust type. -The main MIR data type is `Mir`. It contains the data for a single +The main MIR data type is [`Body`]. It contains the data for a single function (along with sub-instances of Mir for "promoted constants", but [you can read about those below](#promoted)). - **Basic blocks**: The basic blocks are stored in the field - [`Body::basic_blocks`][basicblocks]; this is a vector + [`Body::basic_blocks`][basicblocks]; this is a vector of [`BasicBlockData`] structures. Nobody ever references a basic block directly: instead, we pass around [`BasicBlock`] values, which are [newtype'd] indices into this vector. - **Statements** are represented by the type [`Statement`]. -- **Terminators** are represented by the `Terminator`. +- **Terminators** are represented by the [`Terminator`]. - **Locals** are represented by a [newtype'd] index type [`Local`]. - The data for a local variable is found in the `Mir` (the `local_decls` - vector). There is also a special constant `RETURN_PLACE` identifying - the special "local" representing the return value. -- **Places** are identified by the enum [`Place`]. There are a few + The data for a local variable is found in the + [`Body::local_decls`][localdecls] vector). There is also a special constant + [`RETURN_PLACE`] identifying the special "local" representing the return value. +- **Places** are identified by the enum [`Place`]. There are a few variants: - Local variables like `_1` - Static variables `FOO` - **Projections**, which are fields or other things that "project - out" from a base place. These are represented by the type - [`Projection`]. So e.g. the place `_1.f` is a projection, - with `f` being the "projection element and `_1` being the base + out" from a base place. These are represented by the type + [`ProjectionElem`]. So e.g. the place `_1.f` is a projection, + with `f` being the "projection element" and `_1` being the base path. `*_1` is also a projection, with the `*` being represented - by the `ProjectionElem::Deref` element. + by the [`ProjectionElem::Deref`] element. - **Rvalues** are represented by the enum [`Rvalue`]. - **Operands** are represented by the enum [`Operand`]. @@ -257,13 +257,18 @@ but [you can read about those below](#promoted)). [mir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html [mirmanip]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html +[`Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html [newtype'd]: ../appendix/glossary.html#newtype -[basicblocks](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.basic_blocks) +[basicblocks]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.basic_blocks [`BasicBlock`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.BasicBlock.html [`BasicBlockData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.BasicBlockData.html [`Statement`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Statement.html [`Terminator`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/terminator/struct.Terminator.html [`Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Local.html +[localdecls]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.local_decls +[`RETURN_PLACE`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/constant.RETURN_PLACE.html [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html +[`ProjectionElem`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.ProjectionElem.html +[`ProjectionElem::Deref`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.ProjectionElem.html#variant.Deref [`Rvalue`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.Rvalue.html [`Operand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.Operand.html From 9f612dace656b3f8f750f2a1cc475e479a6cffe2 Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Sun, 6 Dec 2020 13:58:29 -0800 Subject: [PATCH 1370/1812] Adds a dev guide section on Rust Coverage --- src/SUMMARY.md | 1 + src/img/coverage-branch-counting-01.png | Bin 0 -> 11282 bytes src/img/coverage-graphviz-01.png | Bin 0 -> 340404 bytes src/img/coverage-spanview-01.png | Bin 0 -> 320657 bytes src/img/llvm-cov-show-01.png | Bin 0 -> 416748 bytes src/llvm-coverage-instrumentation.md | 627 ++++++++++++++++++++++++ src/profile-guided-optimization.md | 8 +- 7 files changed, 635 insertions(+), 1 deletion(-) create mode 100644 src/img/coverage-branch-counting-01.png create mode 100644 src/img/coverage-graphviz-01.png create mode 100644 src/img/coverage-spanview-01.png create mode 100644 src/img/llvm-cov-show-01.png create mode 100644 src/llvm-coverage-instrumentation.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 43df9bdb5..9a695c94d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -147,6 +147,7 @@ - [Backend Agnostic Codegen](./backend/backend-agnostic.md) - [Implicit Caller Location](./backend/implicit-caller-location.md) - [Profile-guided Optimization](./profile-guided-optimization.md) +- [LLVM Source-Based Code Coverage](./llvm-coverage-instrumentation.md) - [Sanitizers Support](./sanitizers.md) - [Debugging Support in the Rust Compiler](./debugging-support-in-rustc.md) diff --git a/src/img/coverage-branch-counting-01.png b/src/img/coverage-branch-counting-01.png new file mode 100644 index 0000000000000000000000000000000000000000..c445f3552a6594249d57a395a68cdc0609ad7719 GIT binary patch literal 11282 zcmeIYXH-A_x=x-$oULVV7XR@Z#(lW8ZSU`xatkg$htSbx0Dxu#B3zV5D zWX-X}oK7Lr_cwD7@})wWcc!DxB;6Ntq5$p$zqVO~H8G0vu>n0Nt~W6?*&P>2dJRP^ ze}|Hr+DhndTwENWRlL;FecT9Sy@1;o{y920Kezaa3>Rbuu0v+7uKDXcN`asQb5+>?UqE(=dSU>&V2ge)w1?fsi*z3u}C|jA!qAS?%;t z#bALb&QOXB0zp9v)fFE>F5$S@$-*IzwyeJKKiukKbk~m+Bw%?E_e);&f#|I552vy5 zv8w{`*)t=Kq}rLM2lR#cSp#kx+G*Qi^L>mzmY>{$cytk}&$XuXdC&mQ?13z$x&XbA zXVfZNtpHB}z}ipLfT4W>5xzs3gJQ!IL~@hG#@wVOeGZ7xqA0KJEZkwTrrB19jFHzo zAU7et*9!3?V~2?1h~x>yP{KHpIzrAEm^c87p~G{g+@Otp@Qs#fFm{*Q*QGp&8Wwqu+m-5^-rYenT^&pLUnzi1PIvdV>c+ zcNmaj-(zk3#Mv)F@aUcy)<4|8DD$H$Fd;bDA3o)W1lRc(If~LhX-Jr= zmYA3;3$gIsD7&%ny4ysiM8}-%Jwp)1a5Ae-goew2xiq0qT(Bl-;p=|;UCCWm#MK6Z z2w*BjHK93fLo>ag#p&A>pA^0hrmr1s&bP&TB<{bE{I2?4;`{yY9N&ROmCMORE`}fb z#?-ypWtkf3?GmR_eZJJVG=4lCGi9fKoAkM@eon)mJ%=(gVKPZ6Q7N@Ci47CcCOor; z4@O3XE5l-^QP8iWbH+39+5EXqG9eXw#X!Kg&C7$H&J<$j4k1cT1xv=+?rmgbXpEJ;4Z`caKGGs=gt5l2a8|mH*SI z!8lZ(|Eb|O*gW!63OdeSS5-e!&B@XoVQAuAy{;c4?o?W-m!f+F4Yx2TI! z0-gorN`BBVkucpdohkWX`p#UTeDJm8`&$;(7E~6!CZgtLR!wgdOXAI>On1!Y-YvWz zexGZx_O`Gj-keJ)v*B?=W@w(G`qx1NPj6eHGE{Klh&G$4m05^Mx~1bQ*t^KvO_^zh z+5O|Yh)}vyvQx3s9g$p{4>l(@+3qrZ4GL=yI=rc%RLwfgI!`+|Qh#Jo8mje5_d54p z?(MYo5Tz)Kv+b$g_sAV(%`?nim(5mEirRlXPE+ONL$U6+o-t89VO6agga{%)v?(eD z^{rB_4F)wK%!2fTj8~{vO!t&`V?&EV-|oT0f3k?^D8A0|Pm?IDDB~)Dj#i9p4suC} z%OpyU-RXD5k3I7ECT$=qBJ*3EU1Crw3trV-(z+Zi(fYzuL>%k%%k!kQ?dP=)*Qa{P zT?Oyr1t+CDt6Fy-vy6Wq@_uQPI_?wrL19R_H@x_uA>V z?3Mi%{Jga*1QqH7_IGJJ9C8Z5@{vIS!B6C6 z6sZ*06a*AE12&unUpRf&Skz`tNv`d&&14YEx6ieAE7!F@_xl{6A6Oc~mgBCNt_I&k zM}`oFq=i+7Rgiw=9hlQihZ#p0r@5ytnL#z7d84WoOCo`mLTlV>8MUdkZO1PTNV%-? zhgH{`uTKNh;nQMjGA-9z$Xf)?NX`V$sLpsHX%Jz;2||hJ*68+V6>kpNOovX+O99lj z90;)&jO=vwbSKhnJX-XFvRrvw(ovHqx)dqQiI=NlV@!gVYx+B#ik*7CL^>ooT&bxH znEC8CiMN=^rTdv!M7Kw`$=k%6%)_PgQoHN5Vxi!`rGcOUF6VHUTh5^_OC9BDP4sV> z1X8?GJKJ?TH=4(BU3!{lTW6`mV$%f1o*5RH>BTshu1Tt?w4|vXL*mkYs+K52p zOl-hC`PX{C-#F;;+H-ACZ|LVSS3Hwz3t7s<=L<9nWL~2wu6ygP&q9wR?;F-e;J(RqM<#!rIKrN+sg~ORwd=MWp!CTkDC;Z@25re84C{x*9$9I zu2k5zyobwp1?{nV7!GEoRmXb;j#7W1unxJS;vX?_^+uc!sP{ENH0jcvJl0vR$^t zu{V4d+n4`BZFqfX!m4s}Epp%tOE^Q?H>@x^JnS{fEQ6uij(_#w5-FU0Tjl43$FTL3 z7Fnj(B>>dSXpm!L3w zi(k#t;rmC0$L$Q6_E3(N@919v?JKu-EILa&%N1ZsBMU!=!>0~I*Qhete5Q69jHh*H-+p@q2sh`*SKx<&sL%0rG%k^X+uhDfe3I*w>(R@$_x3Qf0BQ!qYd4 zay!#mp}C>P`-l4u5v*IgPHMI13!8(}EtK=BylTQ>fr1--`ULd8XT&PO2)Q z78IFwcoOb?$owmFyJFFCvY9w4Ogc|ORc!I5{L?akoW(Cd5`gdXp8B%`KiL3UX2ZSF zrv!#gm-sK82;{A{3bbEBO>hD{Rs^&GRH$60oBGLr-g0loh?5tF5LPxdIiKji>DmuA zYrdIx(`y?Uep1E))Hwsqm($bJhttxd%Cw(Ekg135n>(sqZTQCKLI){W%fxO>G*F)y z7Kfgx4gWb{F>u8JXR7B639{^sT38_Z8Cre!U_p-ppgn#uD06>B#K=e0_5m;Y5kHB&<=U+A9lX!p>{6!BIWC6jysUffe!vD0vNE-ld zm}%N_MHZ)Llf%}L# zxx$^@#E?FI7dU`2QW0$WxFMXlkv`tOfr>~Kp1&v*!S+Qrl!yB-5`>oukF}u*wuHtPioxi7pzf^cU5C}g-C^RG_L@Y!~3?ASPl~7PnfQm~( zB_%~c3emv(z6d9zsBa+ezd-(tqvaOp65#2F@PzwvU*I}9!-EhiJUkbS{`356oo-0a z|8nvT{97zgKwhZ zrbVDzfF|4roQP2UuhRdX{LjJv@5H}Y+Wdp1xb#0+{$u3tnaa=$$^W5=f2sMeUQo}f ztMO4!9w-&SA3urSi9+I-7rT&e&?zr zGB_~C>uM*{(0$N~B`*8f-KRkz%*Mvlny)<&Crb3VeL|zE^7BVVrdS7Bwm4MA)a8c- zab(Ueyv}@o5=wt>gx8Pv{x*>8GU`+5%FQ_@dTtQ8p|_~Ac|0F3l{6iHO>c0KizjTej4yI>euw6xYW3+i5*;9KGU8m(OE*7Lk3VsLzX9Oe}*#-)tp-h^P1xwa#(AlUHRdQ)pd&ySCh zgm?n%4X5lVRops5IoiaVp$bh3KqJ2$JN5fuD3C9`i8%o@D#T=LF`ouW{HllITW}79 z2<^Y`AiRlU#!GIID+5SK1x+lZf*YY4^La$)4x}PgHNKk{M~pT=6VL!K%o?E&Mwl!& z9rvM{&Kl$OI{no)84?0zsK5|{5J&24cyf&;UU@GcqRaS+WtS3V0vM*JO&AY=5UTwo z=$QUPvOZh3XkxVN(G{Wef3mImAGZH{C0i4t*(|5+cOFuZ7of~Q>v%KZQPuVWv>{H_ z@GE8F*>Z5B;NN49y{8(g^&hmix6kh^{pkAgMPt-OVtRlGzJ0Jc{hSCi$gcT$*LUnE zOV^)DaDKawN(ynCZ3^AHXS*P&qLLaFaQ04eOOc+Jl@%AALket?Gvuj+S;jT4R5-Ta zjr-J4asnh=;^7#}Jpkvh)%{8{VQ|qY_7+|x;z%0rus{Xwa_kKp1Y>u0HDY_dD~~qv zV1oljh+gP;r?`bj*X@DL)2O{w3leNPms&A=y1Cc4F*R2ygkYLK{3Vijh`L{t#=)Qg z!1~fiw+ufLgF@X4a$mmG1F7?-g4t*|l|d7(om7@+eGrjxz=aR?3YqIjrTnC?ukX3z zbyxJ;*`F=m#&b|w(6oZHNw2)pW1<1k^1~0e`3QfXoP?8%HHK{7J!nk*?Ed3!y2Zf6 zY@qy4%&YiiP3}vwIMJAp^RrXpI>m^I2H)xCCO@*6r{3&yz2669FO9aVztXMeMAeq` zJQXmO#6RaSLLP3r?bl5vo?c^PfHFY2RKY`nN-v)cSADw%_8K-DtBtreD*O1+Nj|IASF83>EU}?#j?xpU7fRUHWpqzpT6T z!A1TUsZYIfu@H=%pa>|+q6&_C^2Bk}6^PiH)o$<{D!v7qsP?j|>GMHHoi`6QoUElE z%Yp(8yoB*qeKbNdFfe$YaWx6jBKCB~YniAym0z5l9De@2G9K|GUoE{O83fgF38uo; zc(svZK^u23_+7g-9d*tWZm}>)voQ+yi70aS`R-#6AxHK2&@B}b^STuO`;`X9t z!AU@VTr&^YP0_n3WVa^GG;@oDLkN^n5 z32St^DA#uh=Dq5Ds^6aT~Z|B8}3g>X}qM~hij_Fy28Ltu#KPt|$N*HP^? zN=r;kVu|a^RVtJD`yL$)#Z2;D3TZ1>=R|+>YCSs^1dyk@!XJX2YoKy)tbuCypZ?~q zY6vk<5zRm1$_!LE^ZHITWZ1VvHd**jH%FkXOeYneDTe>Sn_xR0^Xk$sfD)L=n$ergYzjLloJJkV zI9$oSD`1p!lbM;>uEu}#tx+zk9aYZKBy(ommE(7nKepm9R??Vccap6~e9H}|Bxs>C zD?$3 zMZ$FVJ!29{Ltm@`8d=Psb2ypX?-Ln~HCF{H9-dn~d?9J6s^vC`V*c^$@XM4tM}sdH z^;*%egwEU ze#?K1nHbN{yV` zG7vz#EiNwH4z=O`muj@!bTDiQ?qc?Jk51*k7&fSf6m6oc+Rufw0eGiB?vq~haYv_@ zdTmGr0EhdKe5<=f2cG?2B(S{iPJmmlFxLL_o>79KL8#Ebq_x}~wQ6QR7MhDTX$DmH8XhlQ4^X4KT>- z;Wb`d#>z;mRtC@Af{Cj}E0GZF)&XUI#sMw9ySisfyXdB1K>*Zw)gPmT&4V;Vo)V%X zkIDi}ixLGZ%MYR<$j(uzp`oD@%CVi&^uOh=c>8knflB)E@y{D_Q8Ux9N1o(Jw}v2B z>moAHO;qoz3m~A5&Gu^tlXQc&O;(uFF9sPr)sh{RhCQ$1x3($!hu4{L76WD=x!Y`6 z5haOp}pst_2HgT+Gt#*ekV4=htdM^RSVb|4h_R3-mZ zume9fG>l}Kx>gPBcFf=bFYVgPoIu0ZA5tK?bVoD3^Z$0LIwU(o$8>1$M^BE>8%_s$+RuU_I~ISGieFl)VO9XqN2s^d{*nKvc5U;A#e$+6tb8j^?65WN5QW? z>TX}XRLjn3L|;f>?#oFJY1Vk%<|~xc)LA7WwpEFLGTywRQ9BVQ58JW9zMcx7*rS6E zgqvSu4zIHLD%-s&zkY)Rz2HT%{G4mY_dYqYX*VuY=bp?e1REeji0DZTk;Cca6T+aU zGevY5yTO^@YiAA0gj1^v0=T_F0T?R;jT&tvLHWuAGT=j3n4zgi;|3um#bVZnqm=!k zsvR{7Bp_yLrVap28_fm@s{`plLN1U{Uvbj3?t7>_c2=4Yk(^vs!45&gj=t&hqL@3^ zK0pded6^*Fa>U>$AvH&&AV&>GX2d1<5;n59Dxrg;CH{0LG_hHjjE%>r+rFbpU|qJA)S% zUoQjL3&)oEEBc<5Rp>Ih5!H~*fZ>#Y+=uS5 zQS|iI-l$_Xo1E`_477hZ!}0iF^Pq3aBt;h+zVfkI%xQOw#T~Q((2$Mu@uvWYn~Fvc#YaVU*ENpHeYfEvi~7;(SU zie$vFHxUSOUopIS#F+Ohp`c`4q;$$xtb{E*x_l$&7FOvi@t0Ru(g^|#Yj2X1C2k3# zX?2d@Or{Dr(>JSIMX3g{dCZ;W?FEr_ye8`~sCnmjz4@Ru6F=X1eR|R|ILyYGu9X?o zi+*$3k%l-Y@q)d)^A-y?*O#@;O)DC#bS+zmO2{TQwMB+2>g3~5#KAiOAD^UP2Z|xe zcix5$)|2yF5>xnJfj{1*IbN=1Gww@DN?Np|hVCsr^BAp;y`xOdF20xiCJ|Rh4tI6c zl0onl+f4Z?-`JdL%v@8R<~d4}J)N)e7%TFS<0M}DW-P#jemq1V!93&1wa(}1x-n9$ z71(_BUZK(PyyO&Z%+~d~3JAOwm?Yn9M(>9g(2)%Y-u4PM*!4K!#$qpG7Le@K8$0`p&(|8`ZN=;SzPALxKf`S?` zaydElqD!I^sk)Dqld3t=ZaOP1P=()*6Bwe@_SUuWISOdpa&13c?UNWlp6P~kTO<8<^Iofht7$s}&`mM97RZTBrF&tQby*R7bdd5h_MXuEd&Ml02SJNW z7E1Lnzx8V6WQL!S(*qy6GDs#oUILkGyI;G?L=N7K_$r4=V0O0s+GZ5QMF|Zr&v>4N zF*y1%(h!2`g>=j%2}7mg$67orpP zzA~pIaLc^P5>X5H;xCD=`(jKj08VV8A;rV4qIsc_> zfmUG6mOIMsM~+^j9mf!5z0BiA4J+|OlwHQ;vg}mBVe@O7A7iw50{eiX$%ywdZ0VlP z)Xv=ue~i8ig`e9fwA5J9>3%mf{>ISt)Cd&DTX}oFc`1m_JP#F2pEoj~dX~AKi=*)C zN_F)`Wcl`cD?d55nhk5q5E#>&@#I`@tam`^8@*Z3+Ac9J-MTs1S(vG^b?~d4Z^Rb$xmSy*T|Em97KR8@!#YRX-xWaU=x$5beQcMUES@#iqzspKUo;sk5 z2IFPfj*gCSX$xC6uaOU)DQRiX_ankh>*(YoPmnG*C>2vO_L&E23bKe~k+%|N#Ug0e&L2o`lnh4x@QQBH$AOd6;H-xu4rY(0QZ3S|cp z6O7kmgc#(lSQ;}GaFOxzM_*>eY!Mh|LKy!aXGM*3sJs(xQ{`d0>VgG7JB_>N=U%q5 zSs>!Naz)&f?!bD%XT8ct9=n0JZ$P|L2>$)za4{SH9oll@9C@@NAf>2yPxbsHP%32O z*Ih?27lvh*_rvV&?Y&z&HVXZA%z~>X+T2?k<@I$9Jv-iP0o`Zacr85trG$%)X!~Vm z0o*!uIWkAODe_<{q_@njHgr)lJXh`fN*suXy`sr{!3;??V{RJ_KAsRe z9eG@4xKRtAmSq;R7f+z(xW~B=aejKRIPhB6XHAb<`+Ddv)Q=o<6kcXTVQ^ zG|Nb7{mFf1$MBDQq;HHSj$Vm<-3q>9zKsax#NTSPDz{JSC|wL3yt;Jg+q*^pJH<62 zx15uoxBQt+HlRJ-XxuDbg}~V1`~%mVGMUktP{%y_Tr`00@Kb!LO4hTRst*Kpe2o$}Oa(jqC=aWFPs8j) zCn*8cs1$PH%R{fxav84eqt*wcqH6qF&Zl5Jl$x`3XUOyFPYAl9Rru}0_MV4K!uLwu zvcrkcd97^BE)#2D3X=6OZnStvql6F{^uX%7Hu`&>N@I;}O_wfajRn0e>~liL?7m%H zH`AWXJbJqlB`1P!-tHEz{`rv#QACZ~qr}eJkW02Gx%aX2F5x*78;ZQ?$D=4&;BC~iIP87nG7IoDugw7{vc^iwJ-gcZ{WW-~71^VFi6 zgA0j4DYMZi4WcHeukjNrW0&VID2~CCR*kY+jPy}5@lwH*vY`tb=anmRRvuZT2N@0F;*vhebiuLw}9cy7_=sH81Rm)t4 zDz-5MZhzK08u0oYOgLx7Q7{{M9=~+YlTZr&Exw)3(6!wqkZ({nsxS9SgcN-lmtod1 z8|C5*d$TO`6WG#I(V+VXv89LL&W}YN_#apHf6zgHMja%b$4MUU)=|>X$jSOl{5-j{ z`2A%%GyWl&Ya+_S9gL9b7s2d1n~RGJ%RLMC486|DD;(hed-OjSwPWo}=c?%I_{b;3 zgU7W#SPXs`EDOi}s_9i}owR&Flc=6X=0OTib8xfZ>AwuYOkSo}z0OO3s!h4R!(oxC z?u)k!(j60Xprf7f%(<6XJb}>8E-P~;k~Eev_n#Z*=TRq0RKHHQEZ@o2-S?483q?j7 zEu;hBEk9a~T@1#g0XV9LuyF;j{r(F00jVA4l${9Bktq_Os{**s30eahfRu&goK1A^+4hg64C`CBqR*W3mD*=66pOY zBqZ!_X5!)sQsUxN3idX}W|l@sNDl%dqcN40T1kBur*>WuP*L|`)nWBvQPJ!mVfTqD zixEDcr_M;$RlTBWt3vQPBY!5x*Dsfm%0iS$P0=zd3#XW#zWb9OUZe{|a%9qF%46|# zu_IyQWIw5)BZha866s6I^`g6|kCCaAZoQE}J7WFz?eewCX=E&2U+hAp*z5Vq9oQEy zqQ8*o_KDozN8)6gE>HZvyK#1wo3(lHh#5)Y#>ZBH+dP-QavRoudr8BNq##L9*UKK` z>bF59^M(rRhQQqq*-9ryesAbV^4QHT6MqdVWJ7W#e1203-PbT^iDYy_x%uMl>v|fO z`blB^Drq-7V%@1E66lcWTj0t3v4|}|X?pglP zC!dPJIkw~}+jgdUECmU>!EA1i^xUPFCx@vbNimhkFUL62eR5R4JboXEmFh=S=3uQ^Kg0NIV_rpJ>GuC!cQ_L zz(zqvmGH-P-M!h&h-W6!V8?|(_S9otJ2jnor=(f4x`Ny4Tz61^J|XPLu%`08zP_iz5l z5+cZ)$yhtSmsl}}8Y%9gy3F96h_YTlRivU|!qB8big~cm-uSQ(f6ia55N{QUSodNU zGUf+8TOv;XH#1C?7xMk$W|)_d>vWN7(QeKNUh}8Afccu5;T_hpIPEK9!;5Ux@?R*i zpWaAzrN?^sRN~e3CsLr-PD z^0Hnw{y=R@RC_`0Y4pb`TZ&qAX8+u;;m^?D zU!vV{+p%(_bVobI6aT!V`<~VM8aFNeo0sa(T3aIY_Y6V}n043nF<3W>)R@REo;iKM z(3>qX8zCO)9MKxNZ%I~;Gag3%>8ow*UB-A!X55w!t+t1i_7l_-BolWgkk)T%V-v>oydW|ahl1iYl#6^7~ zwvftDwfmM-+EhX}>Qx>+Vpq0Td6Ilf`AM#FhNHxC_@ksgx^U9g@Hy#+w_2q%9$-GO zdWZS0!jOG5VpUd-s{M<`m$EsBIl8&9Hf19+qjGk6w-Ebu`!`#6=2eMMJ_USCWy+X) z^ze2IJr8{o0~)asu?}%)n|b8J$jc0q3~4#aD*S`2gEE7iIZipzDwu<|<{9QNbAd8} zGSV^!^HXJ_!51si^N)BG_7zzaFiq8BNkU|$(}?@<`}xdnu9&ZcuCT4N4>AtQXYcnZ zIx6wSC5lcz6n@wsc_tw3a>e3`&rpUsUWs+*QF2P&*SrtI^gX5nmARYhZ&H>EV)E7B zjlMrr!^tzsE)%hc8M4m9dD1k-Y2{*-?+n>fTzk$}7@95@(1o2qnqa|~R_$I5sn(yg zpLD2ha(5K8spG68tm}6dKT`IR_e${&gpr(H#dX36di{akAl@YS+R`;Nk}r6Bq>iM) zB(Ws-$?|zDIXx{UIQ2=>uSH%fBMZ3(CF|zUHq*2@=?T#N$a(4QD(5omp{}_xsYP{f z>8N9mOjEE`l*MD4y)W^W>qhkhwPPot=tF*HudR#Pzh%%^E*su1d|z6thpxe^ftBa1 z?$r6Y!#Uwjtd?NSc&uS(aaVbM#d=A~c)-~E3bS%It`=9hkMXIzm_SN zN+meu8aBh``=6)!5-oJhd|Du@1T%%7Q$BqyON+cYZC5etMVHerkQpMkCa0626;IQJ z*Co#UnOTZig?Unjlq0?>#;uijc4fBu^X@w+9ghi5%(!BO@I>BZ|0Hw*b1}AazI&3V zV!Elvf3|2iZTQXCn7P9=lY(f-)t1~bXm-VGo^FqZeTOJ?#t^3$yKOB)lHVLA7X1t2 zHW;S4g(Gy5bs##K4Y59@K2OiyAT{|8_#XMb7RhWRhFFQdO@5V}nrvOp9M_(26oyuV zR)8%;DTW=0n|;BJ)SQF?%PIl08z-^CYbx!KcKhCTT$9K(eoK#$S=*BD>0cX|8<{WY zC{)d;2WU07y$F3^J{SI_`pdqekfKJKdunIeeD4}t#M|b#V{b1Oc^7>usJFTKi(aT?=^I`SJ}ES99{F~IDD~_@hje@;K8Sp#oH9OKi&4vrpO*wdXA>;_vk}m zkE$BAXTp_;a=JBfceNwP&SvmP@MjrM<3|fvuVd-89EGG=EZiPPk35WLS=U-AcWmjq zB=y3ufhe3gy!?ylgEU83Yvwb#spz#Bt(a3g^^RhLc9rO$D4q7Aj?sv10UoOTOyVWt z3F0+IyvO+(qZKd9%s0$Uowio?xb9nQ4dK4W)AX<|NKW^~z@LDoV@8tQa+NSrE7nXi+H(p<06dpNM*lRk7 zinx=Ykx;Qd^=y)M%(>u8?vieixt+D$*`C{Y+{0@$=rkM7Orv&H14WMAa^K_*yQYeJ zilgjjx2)!MfZK3k^kN{(byv6Q+1Dds+wah|7`9m9{A4 z8s+NV`?Lx@2s~6;^UgbcdfY%kK)xh+&F;Hrp0t%!g52bgd!@Fvup|9uPiK?&a}Cn> zWP99wWH@2IH@9xGc*`9fPW8S@TWfjSLh8+Sn7(p%*H!fLKtw-hACu|2RiMo>-zCq~ zy1}~Lg97dbio0gE#aj_a*?F0PncH$|pHZ&fIv~X2+%-o8-qBOLT=VzDkdfTpf^>!)B3_r_g*W zZF3qDiA+~yS*2!#H1S&tfPd!*{Cs ztE}!E#L4WQ_~dMEaJ>D}c-4 z>DxFt3f{N@f6(uLKjvxVYWC+z)($_H1s2ExKf}Vt%*yh6Y;dap{98T+Ggl)^H3>5- zAT#g`A$C^oy8`Do{NvQ0NB+1~#lgs4+{Oyr=_vF^>OXHrJo)z<&!4IO=b3EWoScZy zL^$>HRsk0H+7V>&L(u2n0!a&D3$Xm&H6d&TrpXAfk=M;6HRBrH#{>LXc zMlqnjeedEp5|Rj#l!U0VEAr|jRxQz|s{KuS^k^LGX8LQr1O`3Q5(>9oFu48V(s z-$%F$(t-Yf{>wzL;9rJ09~F{?@|@DUQoYzPP^Z>oe|_QWbIQ${;!T# z|2!OW_rfa$g6Aa?WS9OvC#o)#5K=C7o7&B1*($kF%l(;QBto99@ipS(IJZQ^L?ODo zOurWjmTbrZzT9(O4g9nGUq=$eBOV)do$V|QmZY4fy4Kapv<|z2s*;nD_C`0rT`}>d z)d;tV#G^f+f6+ghn)geNzXqZrFo7gEkF~-Dy2N(D;BzpWp!?1X2NzS1M7TUS=%0%t z3TXoV<>afIhW34VSR;3P1k!nZo0XOu~bkV{tqwytik*KEXQ$i~HX3!e$RnY^u`55|fZ!Aj>x5JrR_m}a`| zm1R_fY5q9htTOYGF`v~R^CGuKxh324>-H}WXZ$aI8zUY|NCS8Aq7?HZ-ZZBJwBjVr zUgEC`37;6%Wr#z!;P8ac*(r=Ugp7xq@$vgFhAwSUFW^G5zp;#gFi<*NCvGRm9{K&= ztY6ZyBR)9Y@Ufwljh*9ZFlvu7{`&E$-5T~<*CX&~rmrJ-fAkR<4Vw;(^VO1<9bxRB zD}NQ(xY?pfB1)WAVGrB zNqMX-qgZs-H})5W&qgPJtVk&R$-luDaMDF`2fC>rlaxZd@uh?7-2F!!Ypd~cK<#}7_F7Rl}ftlk7w-A-U^}*BGlxtI~G}N!GncvZz zF)8LZ%2fpWZ{D22fcWqia8u)?d-xAmi-clFyfj%;QMFb+-m#eEV~sDkqX488Tj`ws zZd_JOR4PfE@A)5LhzNkCy;yWh8$?iypKeZs7G*KsA=GUKf_b9leG1iy8`k!?1CNh* zV7rx3*;Nqzp@=c~(s1FP8R9&D3kj~!X9q39CkvDg9c;$y6IDP;QsqEO;R1P%*oacX z0aDu7mW2MRltTH}?{XM?#`TE~CFhSd>(4L(BEo?iKC&GzC&JEOFoeehXY19ce-``e zs97cXUeFbINc7&Wae^9C02ct4&lp@j337b?zb>Tm6)}VB1L@*xZN#~rQp^KMp_H+dKk6eErB_E)#3}hP^cPCom3!m6JEGD?bN;6lzJ0R0ay>lxi zSwfy^QVhW&nNeb`M9!o-3=bzayiGD>V!~UQBM?mX_oXjl8vEsit@s?5bZO-Px^!M6 zEg6cw?*M>w$o2yk1dsP3PlPs1@Vh|wd##!wPRkM2^3(LM|I|Mul-}P^Z=oZ`V64pI zs+Z)$g?qptYFX|7;()$9PPQ5^hY>j|?l+w7jmvIK)umm@ypE_4zqGmo{TV*F`O)5* z1ppG(PfAVo>cPgn-KQ7oq)VX^T6`IG zqnyc$x*Xxc-?v0WG!m<7>S0`@u!L>7%_jR*13C z?>VxYVj~PX&tN;E_dEvp+4Q#c?Mi=!K>FX)`=iDYrH#v(N!AozJBkfqaA%5hm6>T7 zHsrYYfIe%PL*x{3M`m!AiZG8i8hoCFpyJ#-15ydaEfPzQH%?Si4S7neSyVYF>6skMfc?BE$)P@fXQyp@{cbuQFa8DRRq#h$9H^ z_qIo*HUiga3diyNfH<;;&XorL_`7tJ3Wqr=GSxqkp20(UGpX5re}DU_TRl_ z6cK~ue(*q)D?K*kwo=AhxdgsLtFLyL_v{{;qWyDF0)FJqN6Dku^(R}>+fbdevD)MH znj)yUEYI5jzgQvEfxjT+NVHXhixi&UMbq~GN?QC1IEFWEhty3-PD7=nfyg_9UEh7G9jgYM?cMoR#J5%ok$t3VOos6>C0LQg$1IE7)j)z>wNZb3WBnf6|K5&o)V3?xnX%4m zW3Lqm!uszqp6@+2)%WOzlTQ=w(7c5=@8CU@qzX>Z{HIWm7st5FJStIOq$`O ziCQ8z>A6f5kRbV5HL;tsEyt49lhtK0JT}^3RxRhVO8if=!oFn-vc}lVME5q~BO9M% zjqSNN@>jAlz6mkGMR*bXN}+#-Xjq7wL?8`(tiIcr={fEdK}HW1Ix^*OS=VfMCJfsQ zTiEb9^FX#>>=J*YK(JX0q;cux|K8*xBCxknnIZSjeFBkMveX+|V_=>ckMo|u^_kse z(n%F!!Ia+wAI-nfnM_HYAi5SK!rlGOZ8C<73fE5(13T8@-% zx8Oc!f2KSSTq{VpE#EGWSJ-e3YL*OwdG#g*_`OgdLL?>sY9{F*?JW|p;v|KColJ`E zJferW-R%SGcU1kiU-ewb$m{pB3qIXHP#MH zmTKMP)!w;cDOWT`s%o2A*B=^h1N|H?HSPVlgpu$_1Fi=5fn6h-G(-(Y)8};8818&X zbMt#Zqls{JVsj{H5Jvwfe=0`J{i>|?h?6J`MG zv7vsHaQgdbXW77c%q(+;_H4Ui+S?+(ZtuzT%~GTvzUGHZrN0Es>EWD2A0FISLClGJ zHWC4IhJW_?%H;d4g*cnX7N<}1gMo5=1Z-SD>b2i!Kx7rYOJG~ZVW(G8RYMGdUb9{e zl>scEOgR=hDkeUs@L{WbhpLX(d^fW~g|*gYnv`VK0__Fh-_oaXjo!$|a<-lTwuKE4 z;(HwJWqKfASa?QeT_`(G{99R&AmPA5lW)m0CY)zySs0M@$(lHj2^?~nad&}yRz*B- zPzfEljD)|7aRjHCD@Ejcth%Ta8eP1t-||4V(z^gZ3PJaSum@_uca!ki8$R9UG5kVM z(#~9S&{8!QE`2hLjedX-2Sl&{eW4&m_a^^5CMehVdSB%N1WJSUskJ$f@8HxkG35t9 z%~k%c=6fg~0{ougk;RJR^ENM;d;@wul2pDH!ZY=Nzp{SX`#9#Zyg=`2%|?9&KwAsY zf`+|~BcJuE#b64y-yLtY zv-rm`cy@uz`(r5N;`%HBkmal}4vRuS7=p8p2nJ4z#(`n^0$l4v@US^;rY354`lP*a zI5{$`a{{;F5xoRNv%dtgX6;5=qDt~ZU^=IwCzH{& znD2JQ*&LnlrU~PSbD9355nu$h0Or;tMzzyEqCa zx#O!CewX~-jb`SWRdxqxUd51tw0!}{!d^W4r-@CxL&96Ip!KVma%UW65o}8a)F#YC zuz04x=QQ_BJM4ZX$h=PXfj;HILxOsVv8;Uq9Gc;ha?;1Vdc~X~5{M@L43{mA$7XL| zm0c9@$fqq-rk?=H4yFitW!}n_qT535vO{U7Ya(@x&oN8A%v>dB1(D=qcn2jyL__U z&C?mnwLLuT*e|;P=FMZ0;1qS1g_?Jr%RIsjC@aHSCJBCoaxxmSpt$wk>S!yw^D{q6 z?}HDTZu61%!!$22^Gth|WNTF93tN0hkJcugh(C#!7K2a>CZElm?qmw@hGlX`ecWCT zzgsK%o2C(=dJ0tOwyxSwfEa~Rtv(+}m&m#{R>lGRXu)BB5-ei=wYfD9(Dt!^M3Ae6 zSm?1va0ixh+UsZq{M$~2Anagvp=vRatS@PA4X_6LVJQtj z^NqO<#;0LXnj7`J^ASoifFU?hiN&L4S{5NIk)>B)hZt*`_9R1eTG}ER4FqWtrmbP)V9rPXI%gfv&8N%51v;iaoK1}{F5Nt_a;KO` z3lmxqzM;E6>B6(Tha)%=#%Lw>p#iqb;s6vO;EEN1cf7N~9N^k_AAx@&d%_GDORI{> zA$i&?orZd!4xh8*>H8cv5UC3VX1GIXkI6{-=}=hh=N>q;(nP;?+g^y-TN@{vjJW*# zDNu5gz`r4t7j?d}^ne#jN|^yq%N@uRzbH7M>DYS@b_5)K%u}4JM@C%RzI*+%7bZqA z8OW&&pUTpYRNAFgEyP-gJ-p@sj4cQOojPf6&aVKfJD=Q3UI#c1gwY#6SPJgWt`5ZElKW3bDV zTgwC>OVT*Nh=+BT{cyTi{>-%w$ zzD4dBNT{1jfXDp1vjkdbGUc%$$N>UdiS;C38p(wn>CbR9cItQ;pOf_rRC+pBtD*U@ z^7;1YIKcZf!V%j2@v(9%3qI#nQ}f|`P~rdycPEHXiw(m%)YodduM6UE0=JHoo5j9 zXf}9tJcBOO_#9I;%gw-@38>6(j^|B#+|jBoH9ZDmXjTHt{ObxIi}>#X|Cu`q(A$k& zJ-{)*5>D6C0L5&on_u}2J5BP!$i4B&?k8t(a5iDzeg|f7Y3CpyQPAT^3e!2svA~+p zU&H##D{A9tEoVDb71x4WPr<&9fyDAol{bhHvWKou4O1wmgGssCYBxWVeHipaEXo?f z3t%xyQj+JGOP|UXfU+2@%d`h~tfuShVgx;$70Y9Ru4TgQ0};f($ZISgx3+k8k8VKy9g+60doM#JIlnS7Kn^979v+#(S7pISZ4_W)E@2y7%B zWI(X@*w$yO-1{o67Xa|wHqo#h-ljmnW{(Jg8AWu_dY${(7yiB!)H!6jr6=ny4cjJI zcgmfCOWF+nd(uR6JGtc=01QHK8tOjBWeN2NT-!!u%(w2lDG6&Svd5YU!*Pry7`hk9A*ChC#HcH zRvXS>urx6;K(ZX|Z`kBFz>ZRvNZ=!({-=?!u+G^?z%Snq6TK$nSqVC1N*NeYqea&d))7~B&W_`Ed1;Fk7hO^0&%`l($y%gaJ1h4;F1}TBQUbnB^ z5BLRmWy%2<|F9Yh5cmW6|0M8_C_GcHX;mvZxgEtu?dLrJAOp*(s{n5I7NCJ{5dClN zM;~6rXObriIkz=>I|yTb_75;PKcb2P(W`l@ zwAb`J3t}f&8ZF5r0f^)f;67R4#X0~!*S4yo1ry@>Pn#EW!4W#t3D2*+Z8R#Z;hLp- zM-aZSZIFK&!JB#N4;SKIcqsfyk^eS1P)^1g$Wdwk#ddF+-_83$t|jB5$??t;aX76g zH)J-PuGw?~(n$TgHn6+bBeX;kOmhDh2I_Cpy9_C}8jl? zZI~+y6L`z2=f``x(|_~-L2CW1>#+2v-oq(z-Tdat8ThJ;{XBa&nVz9&sfR%99e(%i+#zx0F;IIZ<*;I4|;y|H_ndWJ35>z zcL0od%+GqkqAWZvM1WZ#=HG~P13Wuog4eX?&C+^*Bv7}07yRHl2CpD*&qwRfRu~;W z1B2QBx51PND&g%y$)f%p0HRqu0g4PdT6FY0GAO}A>F@s+llK*&fdIliZrr-2)AMLK zbK%R)FixAg-N)(dimD)3D8BqJJ`D+?0NL*1@16jhHmn?=z_*`*u0D^-HK)NsSHU{1 zO!#kuMWFZ`G*NbdjBmk47~uQPU=of;QL<%_06%4R2xuok6L~me@P<~lLz<<|(0Rg6 zvcJy5W&3;6#b}WNSOE^^bz5IvVC<(C+oM@{av$gAMAZ)}*A4bn2|O+aP%j1$zA^B| zLQl|(Wek$u1)z3c4Dh}_&&hUg(r9|}FN`rn|1yZPBV8BPe&jP$E|AM|cR#?p3SkgA z!ChtG(BB1LT%p;UktfCo3_y`@2W?bEIUgCAHyuG8>1a{ehbA0L-$ffbkUhIB-=hJY zmfii8SypYgh?i3u`lkwWW%XFs07(dPT-28M^TfaxJwBgXy!-;Yhxe2La!A7J<*%1cha?Y)Vj$%d7yqA<3XIxtO80LMG^5x<6)7 z;8xH8b59q3GF@WQ9pTO8h6i#+ZEcW9*8*_wuH&^ES)teTEMm_I_Yreoot*`|0THFz8e}K7tn1Z8V%sd2Dy`;EWk-&=s82%Hk5BHY2f#Abf~y zwuszFX*~0B`=;K0qEjT{eX+|)^<vDHQxc?Y@S6067I)DwU$ja;q!M;zLHLS+en6|0HW;F;82pxF=d%2sPEUo zyER8^IJ)kpJvoX9bMFRl$LBle=s{y#b1ARN9u1qtGs=d*Y^NM1vcb|<^Kc}yUj=HK zgG1VQa+w;OFUW@$V{4y*n&{|5*&$sgHGY36Xx&mW)2R^)ycakse}kOPb;2>J1+<&y zJ~$i$1ZR(X*%Yn7(>2X30%yhA(cRiD2e!Y6?}sqw$x%TnxPQ2Kw0LqE zE@6c+Hrp@M&s{0Kc3z+5er-6JXNft{t}NBtB0g9KX~6D^kq;f^;V!^$U30e-xw~7@ zUgAtr=hgUbR705y6kHk?7-18$*Ij2Itq`Wp;u&j)>1mK@cndr>5reFBr%!>3F>OH# zjdYYNX`{+k2>BH1ioSl6j#?K0SVDs z(^jUaZe5;VIINg<|FC7G+9@})rnU(*N%8Hfv;&uyla~khE}gTZ=nCBre%L;a_z?ue z#>#JoUlBq}mzYlh`FyyMc8jR8B#ueDcBH={>>)Rt;qk#eO(#M9cof&pcU+emL*V!M z=sigw$d$;S6dajGgVrnehfD*M2`n|ZB9atG zPUbs5zzxzL9=qWwPun)(MZ!#H#H6bsGlfU$lJR5L3Q-@&<~->S7~lOctckJb-_kbc zz`RSFIQmV8vbvvFEi+?aI2BUhc#6NS+L7cyGSZ!{Q#Fv=LhK0mhd$l|(C@LDM0u(* z7_mVrQf}45+nvrbSX3ZO-{X^&n0Rq(Uhoco*r;g56gf*|lzJC4gD>g@RIrJMI9 z4z;+Gmqpgff%TSmq&%lEZ@F~BPrT;7?*y_PZxWsq5hXhL1inF^`?ZOe&jys_4_!{p zg~=VhH3zm@jd_Dw+A-Z@m%SCA0MIc((~JzdL9jLy6Lfva(A)FjD`Q8j;O=lz~P zJ|BIlc8v}IpS2_$#s{cmAW7adOsnY|oQ4wu(mXwH*XrGkcL19cyIL{e-&C~0_U}kbI-0hf~JbTWZUm|Njp5@b#zJhrR&Rf6i0r%%kSRQ<`&eC32%I8 zahZEmfD!9dQUC4k$dyTS%V^Metvp7-MEShiSwYKd3XmXmfUfsg$;?Nlxy@xcQrPB= ze~q=VL5S;K2!>9iZK|Z}QjPfVyo#!p%JQ|tES{y@gNpVquWvFAk}wrOMT5ptMf+y< zJbi}9Pf10zK~(UWT*h~hl`g3HvPR{a!#5kD@M^>2L72jW`EYBm4A7k$n(lM4Y-tlE zyUnmhC^`V;^w{|$7F|GjEB+88g!SS0&W1#On0@QqkrH9R6+!2FUOi%B$ig_1fhuhT zbbpTqZq0yvo3~4>O62YSd5)B<_gco4kc7vVF8it=&!H{=rUu!KW_gqLdv&2HEm)PuBl{0iv&^Nqe3f5#alNt_k6PI+ZfD+hjJC{~2fL7C ztL=2X^U+skXWc%n%zaYV96(S;TG?iD4Ex&Ul$+O)k4zWp`DboZmYWhhS!7$i3tC5g zwwRX-z1FH{$g8V{$cC=ufvCM`8JQTa_b4)`-<`kk44@f0N`u#{hTlT+sokFKN@3mL zt5CT^diUabl62h%gVFAXnuXF40T*dlM(2xKC~^nxdrWxNjzJ7GbiS*gHhys5smp_^ z43}x`B)schr=%HEcDjQRMm}G1iVv?HCz+;76odM~v=7>Yh|{JvLwmg2il4lvmye~e znDts@%9ts!(D_#j{gd9&o`DJySK5(MS-Y0atQZH;(j}y$P}K$_il~9P^|pxZsQ>9s9p7YK38A(Gu{zsZ6<0YThz96U0vaA)b|R>5_BVLwxZE6f=c39rM5!qbzGMM`i8V%cgwEO&3%_u0B{1?uy$WXL_2R}x|7J-X@P zS1cd-$5ADJxK-AU@0Uwn-kCFw|8Qx9VYtLZz5u)=;=L7sk-SP+EB?ggriHFt5QgRe zW#@}zvw<~7*jPsS_|d8b^YO|x{*BraAIwT)^d3rnQ&kl)NL+KW7kHy%VRwCUoYL1G z^Kft-{`SIn-ky2k$gTp3EJxmZ%1LVTtDQr-$0U0>qn9i_nlJ+Wk4GS09-eh8*V{%C zmGb)8xV9lRKDN`K@wL;YpsR%3aG?H)Uw7oi^;~vEsMGjNz3Q>$G}qFCb(`?sZyO&)pv#A`=J|Vl0yKuXDyC zi@!K74_$S6FjAIio@6=Hu+_%sy=|DWp@7!~t?9=IV1~Eo1i8P!YTkKUTnUp|341g|OQfc{ zui|7;o$vrf!vE5=R{@!YJonN#|1KEu!xnw$%sv zWSgQ0m=F$XB1~{W1tf7X0h+Ka2R|p`*5dnFw$xNW!9am}Q(;Pkno941HgG_s!M!t) zBZ`*FIoU#=n;i#BmSy)%qMpnKZFL zVF9w^@)u{Ik+cVUp0hCx4Xvhob+qKoJeRKZ@VM%vl?^5i7i-1`+nP1dE+My`3oe+d zpMsN>dxel5&AqY~7oD|6^J-+#vPoKzC9c&_7@*zhFnyi!xu_P0w!t$GyuzPi*iKkE z&#>P`4bZp`=+5J5y2(cgk}i}kx;p*_=4myju@?DK6!L2&;}ISDR})Ytt1K#(RThV2 zA3TUwcqLV5O}_4d7eBU`m8-Q^blp0pvc6(7)BCp6rw}s1^~TR30IJNK6bilQNB9{qFuh1iz2&d;hl2Jk=$d!KF~aDc=oYvp;*qvuL3kT z_iZ{=l#^GgYE1C$TqD%Vb&m*^9V-rt>g7A8dmB7UaWi^)hw0)J6-PKAh%O!*)s_f(4*1v<-#BFi4YrkW(}I-*B$N6dNEe z+>(6qeY%9t&&`vef=+^}GpLtkrzktKUj@kdLN`p5K!CmrT>&+`*bq;S{5N!Y~^Io}u zkTO-Xf?>7`+t7+LtKNS8;RYzP-TCK9Puze43`0D?@b_`z0$|PJi5W$a8pac zG09;g+G(~JZ69vuh*yT=5&$Bgj;qZ?s{H}tzhF5TK$-+N+*e#_uAF0Z`i5&gY4&BF zpt_c5o$8>Ue8L*vRYPDlZ4#?6GgZcLAd?Y9!KNSJEX7>S$gLFzN^jtG#rWchLcON& z76;7rH9IRY(Fp$ONzv0e(Og#tFp#Qg9LC0@JESun3o$0)s1xNOdtA|8Yiz5z?l$=YjnnnAZ2-acuqOM?2dnkP);DzHO&;X@&N3R0k4GV1 zZq+Sz)6mzX&b`}BWu5qZ>ErVAM6>RilB_AW#@#2Km+LS#0TF8)x7eA$&toL)cWk_M z81K*}HFRlS*7jMT%nEi?+2&PlHS_kdmXwi=R{;CniX(|9|F{lZ^ff{kk+J;l4DA}5 zk=%S79^QMcxO($`&@SP#6GNSy;6woGyu3jJT=?!g_c!aIXR+W_lR+2tal=Gn#>elt z+ILC&k}Ja}KyTMl>25$77l^sqY8rb028I8<#i+m*1Dx=WM8IWO|i#2lqih zQ~T@kvxl^WY^hrh6$)FjS5yM=A71GfT84Q^xx~{CPh-)=CubaD;XW)ZY;m}ZT`I)% zx;tt>5={vOpKdFvsFg;6SB?3$q)*e!pcictp`e z(Val3(=tFFl?^i`kSrlV%M8g^$_(|%EF>Q(wQ|sL8ZJ3Lz|invJ{~g|QPuDPMlBep z9du;6kK-}8Gvtg#YdjL*2kOiXeQccK{!uv?wG$t9>HC|;Azqzwmxi?S9L6o*2syS? zU74hgH*au+!fh{OUBDZZ;!mBISOm+PCKJ2&qqW`5iWBK=c9sG?2W@8MOLX7yEr9Y2 zl&Agk^9-MgAofp>)}pPwxOX%76DRjT-h3$AKd|YnRjulEb@ZM~b0%Zl8h7V{-qlW` zv}Q&cH7(b#PZPr{R(+j-bmo$UOnWD{vo&+JNwF=&LCb`rrWeoneC>8uZjVkU_v==| zp)O@8XQlPkT^beMQ_C6J%S(1Qv)it?dsRbiK(1BJ4-39=w6Ef`>H?WmQ@Np@a@@Fi z7!&_5U@kTcfH`y6bz5><{GWSi&WABkv_eTK-60id|Hxj7-Zt!PNWc2{FcwcETI*f(d(h!f?^^;^%s@H^2usOB+_M|-5FE#PL6P%NEAVj=XZPjXSk`gAZOCtdB6V99?lOD|ze*O6MtSt;1aJ zBvI&lA1Fah#tJ-Xh?d4Gq`&tHgI5powqnbMoic`B@_R^sKc0AE`k0g^dt^RJ!@6}u zYIxfh8CAgT>FKy7^yOCU`jH2CsnC+6zdoY|KeZIXej@X46x)dbC|VsPiRX)VQU8dl zB0~C&b++NOEY!xE8i5EM*E-5RwY-|wkK}194D881R!pE$ z%fFlS`cU{v=n$wRJ9>IZW`sst6G-?M0RBCzhn9c0n4Ai)T-9H1NEFp%eNS`GDa>Gc z+`W&6$h6v~rWTYGiN_4W(uP4sG<{{8h-JOp^A?dQYd<_N(lAYh zo8Sc=r4(;L>)95WENtjx`KRT&5aGHUn-AqR{cTIumNi<#30Efd;#XpzM?$?W;v*tn z03sbJ)#Yo~joGLU)WjcyzNqM7oewPm?{aST@0O#;PEt;&F2su7ldcY6iknC`jGJNG zQJ;p4%BfO1*E&Ku@4<%hG)}oO8z{?k>hq~-x+{a$ZRLmaXUf6Oj%;|A-8-YefZiT3 z*+1sC%((8=Qqzhytmz>8wEQ;K%~iXb)*eop$2KKLnNarVfON-U9nhF3C^&Ub_-3Wg z>g=ll{7$4^5Ua3HZO7X^ytQe6Q&YbpqJFY~KG@=|yWN`I@g_gmD+oQCEg(5PKo`=` zMhJ3{zQR%f3SQfoD4f$(d2qc)+$&2P z%M)Fw+Z$`|PpIRrx;H)%fQt8kL9vn99af9M=HzLmggY8Q7}*=KWj#4MlxqP0OA3#n zw@1GMf++9138-DeoCW!s^EmQ1tWL6(s^4f2N7h?_cYnW`iS*-h=fuaoOC=FnO`Sv8 zXTzk?Rhiqwt8i zZ!_}59y9~ck%QL718o1j6`yK8j?s(_TM|YL|FBoR4OQi5dSSte`qLoiWD4N{t#jDZ zN-r<16+oG^;s73q5P0SVf732wf^K>^X$(|LS`Jlm>z2pbxV<0$o8EYy>kaR)=5V~l zZ@u|GyV3LErC%iIWb+qVM@k^S_F&%}a}WH5i=HToYR1tzgMJEW)O&yumn|Qb#V$1BblL~4 zSEmLePJE96?0<8d-B7ifTeFtNTiW&O4o8}q&zsG zYihkfRaVxjJMY*Xyn03xWJc97xlli>n>=>KskZ~$TE~fLkT^JV#)MqQ<-xd@L!PSC zZN;lJ9hF|8;~seWW613}NAK+)(qio?`oCRIwXYtUxR(?upugW)rcE=2b`@`+#;eza zfBb14&mfespf+4UleLI`P$(wfC5gPCZK52Wyx`W9bBe4oe=soBQ2Ta2!>Vk4(vZ@_ zlBU0M*POveW2$}uO8Q7YAkH#{TO!6u%ztC~N|_I+sYH%hnfMkS=V%tfKeOe+XK| z_3u8nIuZCcM{fpa&(iHEswjBFezIq7p~xa>z8TW=Jv-Z^cVARzS%MPTiOv|*dUJ*< zxg5%DQzngC^T8mumj5Pb3hU8YAidR#i|MQ&;ooR6oWHx_h_|N{rjTW>I2lXJTUl`W zo}brB>w|%r?R{b2YL{&bVH&9sn!$R~Is6(N!Duh8anXT$YxWzsk88MWg`8JM9-_YD z%jjwa6yqD0p(jbqTGh%qk6Oz6)1VV*(UO#2oC6yEp3Vw7tyjuJXL8pQ%Uq10BcvAw zd`($L#asHed;O2cyZLOk7rQTVcb~mSmhTkPYhU3Sb~hrlG*Fu-MJnf@t=w%{uFKeW zi3a`SqaJXwPYYU&KVcZJOUZT5?QKjjCo4s58b9T(Ie{{kh+aGBm@ItNr?n>|}#vpP!p4MP#i<*IF$#wCi<7NX4+D(AfI` zl6`#FapSt2JW|bzad^~8!>=%4YYno+*j*BYL*2?&&f~(iGmQ@ypM=eWy3{>(iixeG zMC@_8_b{1Zv+omv`_^@_)HF;nB2G(1jNHzXUVa(#x4I1&1z^{hcd4Jm*Rs@~iTBhku?^G|-Ks#G%zz>%+Q5h%KX^WA>)9eKOwr zXnFbN+GZ@tL0Y?0McxbI_|MPx+xWZimjd2X#|a0dop zPJp@{yg5qSS`7^9ZBV!?E?!Tk=veOeIur@{6k z@>80rYz!k?ak-HWr^rr{S1pB$GL> zlH2rYpy}f1eqhZpN2s2L$&Hv#*TIY8Fc*~@x7%-pyR2r^Hss{P`@|bygji1&K=U{& zD4}u(juLEXtB(91_TDlq>aK13wg9Cp1c|XwK`A9=XpoWyX$hsfW(H{i1*IG5k}l~O z!lGfwVSpi&aA1az7KV7&=y~1ub6@ZEez@Py&$rWa+Zgdb>wm0c9s9oj*2yaj?{KVp zGhNTIR2AG0-#T47y>paxInw5#+t1#ICcb+XH;bNJ)51Iho>S!)uVy65c}E*c%Vdvz z@5TrnH0F#Z5w;m>u66%g1Sl?pq=DYH#0ZQZtX3RUFaCqJSO6>t5F29Y0Ft^bMuPrH3x>S_89~Wmn9di(c{-kIpTY zIZjQLj^DTxdFR19oA$X8?}?CC!oNP9KGf%Z{Lr%ZD#@4h^l!r9zui!z{|b==t;wxN z=lK7|I{k0aDGD?Ns;W%lN8%C38oXVB&7>GLQB_FvUu*Ckp$lmJS?9GFD+cma7+=9p8z@|)dYwrscf z8gOh(1Jc2Y56}aRUwlFzSN)gQqD#JML30fyvbL-OLOo#E-GAU#gaG?k8_57t2V~bP zAErpD=3SuuzGmw2?S22yhTt&W)KCW`Wb+i@lk{5qdR}4+^=K}vnz&$_23kDJ-uFLz zK>OK(2GJz~FhO`36L(gMON0`A+#K9%iRW1!4Xj!HDhIBVyp=WJk|l(*2oHH3AMT1V z+9=*;eF;pGyRh(FTQ$&PkbEY2VWGg?<^_5kyY53Rh!B1s{aZgg%5GI(o&?@!1W8mhqtVnOGIy5`XIel5*9;Q)>thIU-!6?tkSr-$msI|!j!%RoB^)Q~ zpCa#IIHteiYY0Hy$2WsXgD-F3C8jMLh|Vh^BX_hb)r({Uic(%K`M}3 z7D|o_$YA{sQ@R`EPwtTe;842Kz4Rrjb>%3=l! zXE?|~ik=tS8W?aR&}IXY%INi1BRA$j@S%MEVK6o0rA8-i250VVREiMKcx}gZzsa?f zN(VSYixFs1Qg;Qxv4V!3JRAq+eMTUlmjy&E7}7e5w5Yd0wZ5+Q?gq(pJv9#jcI+%7 zZq`1syq09RI8we6DZ262FSzFZsL`jwh>V_=!U+Av?c_q4&==oImH23^2TwGDVU(Ka zrOz{Et^5k$M8$l}($ICPF?K4!-Nb=$s^VH0mCtAxd*LOOWtUYjJu^St=>sQ0X+jkd zjPNn^+vOPWPx9O*V0M9?n?Ap1)avUqVP?Ja`g`^`y*(s%!}c=eRx`b*JWtav>G|7~ zMl!3KMSl)@kfRWrzEdRk|1q&heLa&PGb0OC3-L;MKz}DoawZ=!C{Q&1a%-w+tWHV$ zoxmGBL&t)Z*8i}j{B!pAPbSH!Z<~`t#DE>`?>roTl^x%HrSJRGLN>Y&%q*(#lXl%c zT*;^zt|}0Tn5ejVOl#?GC_aq?W`c(5*EIDL_sZixMnxhTJ3#0rNt{yJea3b$ZtJsu zDag_e%;dH553G$QM(!4s0|`Aof>dwr63|oY&*2M|PGjqo&8m@{0|J@3004JoAJ~9- z{SHAOO8a@UL+rJTELm}#PpnL##V z2U~(5yWVAbnd7Ns75@jjet(KQ(pg3j&aF%`R)vqRZVb+`SI51O{tP0Thb>*onAb6VAb+qh zvtGXT8~?~J={DWi8NNR8i}ooh&xYOYotZN@jzwRcyZaxWV4NyRs)gcW2r+Jof2(d( z$JG;jl$OF^zURCK#yvavb!&j-kl1r#06-NF{c{0B<*D%191-M7X4+1V#rLuz&y^d| zt1Rc!-NgvTq3MN?$pivO1v&%MrWad=ccnXs{Jl&@h;wS(ur&f6zD;a#D;R<#)b_1l z>(s<=NsT@~cSVCxWu)hVkf zL-RYS=AO?)qDstO8>u-;OM#F|Gf1WOYPH6H&wL%tzTLn__xN5pujgd2(GCdfP;M_) z&=|nveMaUilGSg7f&}Qq-It9iqW0v$1=|djsfUh3!b{W5$m5rn?zArsvTESbVGIT^ zmO~NE&es7T$3w(~#bjq60H>Pc2l2;C`Q2klJX>Nc@C@(7p4(ZU?wa5G8MyM1FLrT~ zK5X=H2lZ>7_MK4G<$g=GI<+DP4Lk&7ax05Sk!&I$Ij)_*gs0U;lH$<% z=!_yG1EiST#?#34tp{aRL zhvgCOYJoqNb}F!y{2-z{)V?rdqPi1)_o@d_Ei`GG83M1_H^Cj?VxPi&k_zfWUuO)JrOZ%&YxMJV0 zHea&Zun__w6La{Jp)OoS&NYtM*QZh*eV7LZG}*Nk*83w_z{4@3V3NI)-NM=;PI_VT z$?J-ejaxw$&2jt4i>AeDpDb3f`H8DSjkP4_aAQs!=2fN9e9rAt?!VLmaZE2GT{+_i zPkc0ju{mfH8{7l2hrEopsaE|+0;PVwgO(r>zv?YSj<)ov?daVl0Eh8f)#6185To6g z;qaH<23G3!<5Wek9Fhd6f{b8^o_ZO=BHKr5qjh?$XX-41UMfAxFy5IE}Q-*W|UF$t;>FsmK z3>8s!@O+QbKrgE`FY$T&o~r<6PQw0HR0;2%YEO+L(hm$clMCCpp*%ZR0h#BO(Ml@< zh~Eu;2|wa9Apd!Z3y_w0t&%|P5<|tGX_utx!>D1D#ir7ZCfGwp<{G_>0zFpgrac`G ztulNPSf0MyU?Bp9$cyB|bIkymLUB!RQl`5ha@rcYuFQ>B#-r2n0r0R)J%cC}SoIv< zv-IjT?b|Ij&Ue|M+)jhayE@~tI(^QLq8J@i(4V1uDF|Y(tN8^~O~wh!y6cXo0`LZ4 zn~x{f6L&#}HJr9wYYdSY-a}ewHuob;XjYM->HX^??w>|Dg z2g305bo|Ta0F2-P;m5oHI#o zoThz6L7*b0+DJ>~$c5h@DLv`AOJpmFNH*97aci#-S?2S$@<1`*NHr7ta(hgCZ(MJP z`YOWfCh5%;*e=o+2I)!ZE+6mSHw?y$U6o*0R1B4_<^zlVPG9}8<&yWf+fU>3ZA>X| ze$BlzSm*os<>O4UVcja#qs_A$I5V6XP>_7n4g?2eNkCT7Yo zpIV8_+t1Q9*2L3u0L|bY0d+S^Qc(nOPR~PHn$adm5nsVxKVty(>A}7NaiIBR!l(U@P=K~T{PKUW}zg> zz}Uj>pKd@woaATreNGAO{BY~hE=4>3VT-|3rzDN z(9@5_`{0}^c8=JGKw1dfPwr{iTMhPVA`u*LlKseIU_4G0y}rs!a}7y6GsE%lCtBA; zWi|WTYttlUaXUF`Bq=g}FEU;Qq*1>PRDv+^lde0!ep`#)$3dT@fLi|6b@BzzCZG`z zb?|;4OFj7mjN&-WkH_pf9D4**Cq2KCZ#jrPFNYql9yK)So{FH~2AeiYNt|3JV}+G_ zs~HWp-6k~S=(O@>%H@Y~7Y32;PRA}6N#4bL`8DfvcVCZfG;LI|{+oN~Pvk(dupLZQ zz99Ni+{qVj>P3<}tYrH;xg+;;k$yP`gL7n)KErfF#f?k^P87-qkIA0yYhbc_HO%d4|F}rpJXYQG@*93K zpI`N!tIbAn&n`}0+YwHAeagrT^gq8~Qx+R9-+bJ+vz-FLb)WlU*Y1u5eK%Sg<^NsO z(RXIIZ^w<)_JCv!|3-#4D#G-7bPhps1w$>gBhs^@A4%6$>!h*UBbfC`tR<#qIlCjP z9{ckD=L)qRnBY#nB>vLB>)Z5tx$9@#Te}NmKC3UC{fHg_kyp!ftgW?yb$DJ5G(IUM zr1b@fm&;&u(BrrREKS-rULU<%#LEq8y32LDn4fn5G?&_n+(fKy+6bT`-@{Xi@rilnb%7bryO@^p=5=RZU5htO z1kJ)zYb$`gJV2%w+sZg2)0j*;&~x_#uq!yQGxAdf)6=}g&W-7c8Gqph69>!OmD*Gy zXg~b-&6>3nW6XB|tV{vkusu5OB~~eQj@{r3OZlW2+UhF7ht|9I5-`haZt`Df~8?&%bN;r@E(Yd%JQ0G8$q+5UYPOCjQPe zfaBj^5C_)UZ33F^$dlz2L>;r)?r`dL#1#b2o118$b_X_g@(I@R&cm^lH!o|3F@$Fp zt_NWHgT3qdWW>2Ya@x+ogDd3pZhZ*Z9Tif}dw7{~RqzgO>?l|);44=OC^A?}A)8E4 zWqiTODw{SB)anNyYHKLFp?&B~)TUk&AZtNIhfUsQ^|@ZAUv+nU=Od$M@VqCSmLKQQuAJl|G*iJRXr0BOz_s1nyW#oKV3js@Ua)3K5MrzsLfgk96Xx^MZ9 zmAMdTsHa}AYTJKIAN%80%PcX=ED^cx@iCL`G9|y>A~(~g5z`O|OEort@BAW_%xSC! zJ%n$HADCn>}8W>i?T-ieQa)ZIiQqx+WEzwF|!I$(5|?I1!F6NLgT)jjWM%G50H&`f_h>a znI->=4k^4chtvJ=^=eg#b=8D0bcSY$r44y6mQ62rCQQ$pC?i83u|Cj9P3$@*MSN*_A=a z&(EGiJ}CYyNk@E!5kH}gR%AI!BW-CSw%p;#DHp336)WiC)UEe)cUm78s&&yn?*YmW zz0EN@d<2$6B86%)Y(F~Nr)PFOHap2+V_fwP-G{~?d$Ve>WdqGyI?fuJMqs?VInnOD zlW4Zi$MGL`%q(CXI`yJt;9>jvyN7?ipIL^}*n^itmv}gr&RjZ224q2`BK2f47*vZH z4eB{6QCp{c15&X|M~x!2Z}PVrb&8?{>}_)YqFjl0IGvPlpOA{8p)Ce@rCxH=Bb?t+ z2Prnb<}}M~7OP+ngg`<7I^*gCfp`A*hs%saHbHVMi4?vm=Zl7Ee1ry4sP;ZFy%Z_` z;GKE&_q@1_D@1^NUhh|X(S9cO{i*5O2Z$Egaf9DoDT7mrm zDK~9`NO9PTPaltYNf$VHy)FL*YxKP7rNAOa$n9u#Q^dFhLu~ypmIXed5xuMJy(l8* z!~OG4H1!LBWqaJ}6mm#Pib=@7W26dc7#A24)Q13a$C3LaIG!m#WL|0{e!YHVO5y}; z0=@=wjZo}bJJZQL&3_N3QgQ;-fJFW01%$*0U|`1W?7;FbI>hV^l2lmr6b}SFM)n}d z@w4pfGKy#3=~LZeQy)2_T6T_X&)N;Rb@vKV%>GTI`18kkH6YU+=)2zj``11p(U0F+ z#rzZI1(-7D%an0qWfrJZ;b^NzowXIo8Xw$ns3T=s66;80wcf0qkIvjsi1=^X=ARFz zlLMdjrQY@F-w&VV{PWBHiy|diLrD$#t1a+CNvDw*P+*)U{|3Hy^bxkCIb3ZsOc{(e z(=-5-r00<9|4Cw;C8=uOs4HCmg!CH${o^hBzc>`&UTa;OSFVth#A%l!n*6+Wc|&U@xH(UFJXM3Drv6fRefy6<2qSu+XRFP6>v zq?3`T&cHyOR}$$-0`35=uT`^z$p6U+{v!ZN)`QyhgS+IPUn`ZA7k|0)U*Yu3vuA*a zVFhyD^s(P^GtKf9blS0mbZO89>f*9X<3@KJF?WKxyF-j}N7{=*T~=&q zh8CX)R5DSI=;;nmbl)##7RW>E3Fs+#pMAkqgMXoMp_u*r_C=0cWt6{D%hYA*YM{p+ z{jC{9k=@Cp2CLPtyIwe=Pue^&t$`0`V~i71!)*#%8T&Qs;J|o5NF1C~1BU7}k4a2? zV7STWV+=h6BhjaNwfFjZ z^yr}FvGFDKZ%b`O!e60#V_uXO@RKM1x=tJ zI_~Pd+o-cHLtS(PmY(8WKwP3{BaeP&#A(tZdJWv_i> z`a77pmm=-`z{N|{;(nJX>J1FGQ>qOjRktmAK|rE8vIR7EHJ(dGS!mDbvh_*L*7wpP zD^s+XNb&uG(OQE+qLRoS{FVbxsth!OHBywf1>D0le8jw63g(s^Z&gGNU9D1G@H!7se9QK8z1sN#2ErnFhNI+VDS`^u>Wd z-oN~*rq_2p)P%n;N1sujXz|*K9s&GGy_J3duE ziz;Um7!-b9>K>_^s_(MCT>Rny(DV3J<)S~x>0{Y(NhQ3%mXJ9HrQ$3@j)We7dvxNH zbb4QXQtz?aCUz2(|jk-6U;ErsF$yDZ*%94`q<#QC8_Yp-aX29lmN>^h-{ zJ*VT777R@f2|yJ#K?|og0$7Xz^`&*P+QVaK0>L;Bi;OnY>onoT3z5i#E_&+wjvoNP6MREhy+713iqDB}+LHbE+VRm^o=eJtz`!oSr?=U+39uSn-pbhf zxeW4!q%RSR5Bv=PEQ>g`Wz>$U;YA&`?xV{!DNK~GlsT$f7M<@D`rCY?Ts8sfLYhy7 zoGIQ$$nDl35|IQ;3n79~`3Ka(j&Y&?&@enzx2}dC?w@QbC`9 zqWfU9fLA!6KIdErwFNhlmypnkFS|&cTsRB9=5k^4*DY5$N|`;;S&}?sl;B>l0z0Zc z{!C{eSYjN661vzf4ju02Gm4QU`r2r$V#&n?`WYhw7WntyjRQ`7Z)0%Qvp=;E;P~XO zCf|y=Z~ReHaE*7pbnHU#DTx`x(7wm^tP|n);Pwb6sLYHv!UAo`_d-t(U^GR6iSBnn zPDF@6PtY4)x%v`b&*v!-t@hS}A|Y~li>V`T2P-?QRka?`{ZiJ~5y@KL=Dcgg!}u0_ zS&ho!czsDZ?kTN#It2Ke^ZTjvEfyy(Fo6lnrAS7;yH&jB6kcvp5Z2qopy1i2Fwg?W+D*B7bWk)i_@_fMoi2a4F2pg#?ZoHVzE}s~M z;U1J{g>m5Oo)RIWs;PRUQQ@E=AOs2;`BV36RCKeU@CY^Ze0)+#I#6Dmeu|| zF+OincK~*@ieTj6daVpu$#bwUf>cu8q$MlDf&kaRgFb@3RhotNYB!FlH!E{F|Hg=a zNhSl0A6=MSg1$PNA;)saP(c$Qc?--FRJX-^4}J$7I;PJ$K%8Au)fZ)hPpJ^?((x@a zU0~mi9VMY*`bBj-LO9G-Zdwm-^*l-ysQC!Lo%k@M-rLY9ku`!$Sp9uR12n;i;#`|e zO;{96hk}KYY3=Jz^?_xUp4pOnELG4bmB`X(YgOG#{SMF!^9yKdF8Yz@Y!r8o`{gL$ zo3XNw==g2xCAJ?%btlLSkkI?QYKh6hpCsfMi&h#n7=-t3;xr^$@}L;u+re^5Y#pp= z5}rC5jEFvUUjtnxi425qij35_ohAn@Su*-@g#Rd`9V!Mo4IIY8Y0aM=ExtUo@<&7r zs}$>B;G|>RLc2KhtA+5eUCfQo8t5zUZJbcsW4D$I;#$hz46Sw@`UiH}xXE zp4!F)o?1I0{IosmMmhHed95=Lq{-33Jmn=T?Kvef{u@J24_f&AYYDmSP`(YhPeize zxaY<7y2QOwr&j%e5;9pEa793}9D4Cq-`T9ph|k&lN8&!3pJqmvX26n&vZ~)0Rr(p} zyOlE%IwR*|{lQA7f$3ry>O;w3U~i0dYCjeV>1puw4*IwMh_2xt9YUvb&Wx* z{9@QH2#PYF^aa--XqtV5&hZo5&-?xgR93Z>2$$1E9)T-iR6V+#xlR{7vP(9JH~MLS zM)?$=s~a)4`(8rU-x|g1qI1tfiUZ0Zjci@xS{(o@k#~VeM3(4fi07x z?{JdB7n0@pW8XD1&o}4nb>N`vggw;E%uH)8kMQ}4&3c>PfZ3ul6TM&Li%1(0c=$oN z?-dTe2YOG{;iYCNTvECUjJE4}@6O&{Li4fyekCngqx_<`mJeJNscP+s8e%)Sq6eGa zNAwOkLdJ{2Vhg*M}0b zaOPC5U$!?Fb7x$4_>30QCQDP&h3zx8?&qx@>7<{|b*u4TD9)YQoNPi1Ca?E~=M(Cg z<@pi|j2&5ODwsP=65WDxN#tG4oT@S}rUyAzy27D0C&DsN$E98*l1qF-DemgjdH8j% zIrRr)s4Vs1Qx%RiCaMmZ#A23!13@Uv zJ_X0)lXGDB_d35s)TU4v{x2EFT@O-pji(Vv%h%o;k{ITh2eS#~gfwW}X7|tzqI&X) zflUYZA>lFEE&r#|#_*bI>eG9o;uJ|g(ppr6KCE`>4 z!OawtAQLrYWIcA_+m8f0RSH>LS=gIZ52q@rhCSOUmbNX$!jkW`vDLQy1^O;ED)4xj zM8lb*XLVNhg%fJ`Sqi)w1E%v~oCwv|P&)Q-qtheYhg~@Z_DfGN?87de16>kgm?hyt zb_cc{#vITSqS5E~S;AA-t57%7I6QS-3Hm!n`Gmw(JKl%}%$>Bgqnd5){szNc2BAgK z%EkhdPv=`szostm9SFP6TWe)Ru?)R;%~9Pbyb5XL(Ye=+kE^qDgMa`s)XO84vAWfyP}Q3-r0aveyi z-OKCov5DAq6aFbDk=?9H8-ZCB%(KLI_;OVj_uKgueFh z5?&=fm*rDXFtn}HO}p3aLy-+;)rJBo-0_j;8OMGz@W!qR zIZk;6!f?>DwvP+Z^1CAF4(Nu_*WkA3K@&Okr7^wY)%}&DrI!{86|f`C#u%4=A%&u4 z%bYcMctxh!`eyA6FWrQX@j6_zQFU)(q^gP$0Y7ToMp)ITL&c7ln$Vj8MA0H2K?Ak5 z(~Wid>J7<#-%^iY#&+}N5F~%T)%o2thTYRSgFn(C7|F zx@GIINbA^Qa$e@HAyp#nCknQdVw>ob@_2dK!(+zliBl* zf?D*pO1oiAKH1Ex;?17(yw`e!G0m#?BFL}Pp{0o3TNdx54QQXawrhGVKKdpBGlx~} z!)#ko7RYkE*w;SYiKuHUFGm>WSDhAw)lb_!lRqQIx;UNd_O;It7mm8Jo1C;@Uub24 z9z?m+l%_^*%{zWxlZlsnXcQ1WMgqPbsZn5MoXU9#~_p66xRMOB^) zyb}x+@ZGK`GpV#wt1TsP_oubFZZs15Hj@s%o+_VltGgIg$Mf{B zaaKc1OXY-$`FeRw$i?ic7W`GEbP{iUEi{QZbi7mQhvGO7AJI#1uC68&;0rbtFx2iT z(4iExZjhu<_=fF{L%XGikicw6Kyc|)7fMqGarno z1fg2HC#iTfEqr#Q`*rEfC0%+1gHNW_ts+VZXk<>fbkF=Yki|1SQ5#&nT|CjChrleNHPw8nMYh zC`-JX<&jdT`qdg0%w_k{Sj4Iy^gJAb7Iu`9v)P>}+HS%G)8w}5*1h^Y0mHgYWl?ic#9AN|*Q#%2XY;i3 z4h!W$|J5aNyZ(xy)MA=e)uYX4RV~zYsG_>-Fz!8zEu53v?_Kcgs6rFzyn|0+ojMry zSr$>9w@!LROP~Vx{#B2#~?nt9MHnol*^In{gQ_@!lPv(^KQgl>|o)kKCU)zbTcbWe5T9i zxL-;5`6#P#Z}@d$ml8QSBc%XTzoSU?{L<%C^R1<~Q3qks6|{zKH`W>>96hAf%h)ova7YjX1{5}awll_V>;q@Lsbn!; zb!G!AnFwqygey^zfKpZeAQXSJ>)ftWst^!2icyVh{3-Cx@_b(<6H9w-ai$+O>*n600&RJbbt|>i zxEnTVIkpz+aaq#OxH_e75R5N6n>&2YV5IJR?qkvMm;3oiPSLm z^}wz`$0KB<6ed(Bk0+BXCUKojW>qU`2zKk8sh1oW7RnD6SW6{L=eT`)I)X@7(i@eV zX5~Sv+$fi1xs`720iJPV{{+Il(5{4R=JS_u-8`PJKE^uJyu3XRxMXSwsXALFxP&PN zLYgZ(`zDKZKeuO4m09(!p?i=3GPvvB;H(9gA)Gx*D`^qyYLw5CImSpVUU!S8Sg7Rw*r;33%Z28RynfWCSBLBFJ^Z?Ztt5;=fevW zBGmsHA3d?l9E#`J{*I1Nrznzp==+A$>Y!sha$r#rhO6ZBB3- z$QVFR!V)WKavFH&>w`D20^}Y;DH8Hwbz8lIT~*fR&}S+=OEQ^*8Fqb#VAF~nbhS2s#~H9g zO`gf5VfP$p$vkp;V4S>1`X85katnE-Rvez$+bmUu*&?3ZM5(Pz21^fjpDl~973zFd z9^osJo}IheC)ih=50C|J0yTIo8r2Gq_G7aQ`q?dSsCydmOf`A6Wl8d>ExJ8+OnFxkc1GX9yu%cAQ+DOK z3)mbd=MpQ1W+(Ux#m*ZD_vNvRI z?OH?APq%fU#C-h5OOXy3`-@o_5`)P1Z+QFZ9UJ;aMfSLJ_n*k*ohwF`X|GmERzc&( zop8^_t**KmAgq4eyI*&Cx7FC0{iE9S6-e<))vj|h>x7`Y%?h@6ylhIGtghFRfJnb0 zyfi_#KUBDYgVLD`=j)3i^XM+Bzmdc29L!Fh5i=myroVNCXa@#f%kM zP*?vcJOCdVde~+2mBw=#O>C)YB|J`P%e)dC&_t}BGTCl=VNvK!HFLC6XNPrYWq;LU!c=79&-?_8QHM@s%1EA< z3qIxYFmk!6aGp-yev%dvUUK&NMByXwZRm+D%PI|rPY4?B4-a6bPw?vSw`Jv0={Keo z$)#HK&-1`ds->WkE<5J0lZC~ z0%i3a1*bnKL(~8)*{;QuRYu`xbVHB*9Z}E8nhZ zwYcmD_XjR0L_XpvWs#l6G(N2MJJZG9tWOa10xriZgpAPZ2El|pvdPd}njqlpJS?X; z1l)q9-^%!BI0^aLJM^OLHoEl#zV!%_p z+Ah?uH~>FzshOLOtqPMQy=$thwpM1`wYFM5G1-gbgD+E94Wiv5+Z=wXe@A#5`t*W9 zi2EDM{*#`LAHVwr`~Xr{ol#BF*~uifO3NG0Ryg&vjiYbME>joN5tGfeFaewdMfbgt z05L1dnOWGZ(UXbToQkFK2n|fBV`O?Y!F=3`%8mUj{L$LC z!*T}jM86uo<)-Th`{A)`Zill3LdydDR(cwbXK-(i6QC;Cps!$N>uJekQO$x#Jw{x9 zb_;c1qnVV4p^tsx#UaW@#6<0pF`^qB&=Ro^7sM!RokPjQaASLRE2V=If_6b7p^*y& z9zz#)=k3{_`Qx{)JOjgW-md|v*C&6kHa5=zIly@s<~8+xXII#~zjufBlI!HkR!`D! z$b`z8r-itNCHyPt)MDd*$Kaop>^pSgyUeHaI>D#-=oZ3lV-sstgiC^7z{P`q!R9)9 z3?binl|!nKJm$?>v}8Lk3g>?Hpj`?B#pcyA7=8^ifbaF0w&OI_o3In3HpPkMmearV z7Ya-HCls|hYoRj!3wAu!`ZK?43s1pCWpB=7x0Aahd1hsKI(7093Hv%#0dVTh6FI8x z@N3;tkC&?=(A`giqZrlVBB@(ecoF#wqik#?B_$S%!t;o`HABzsA@%sUPF_d-jwEV9 z{q3!~ck$9DDD_O#BJkckg2dz1Y*sMkx_;QVY(5Ej%8=a4RE^W|iiULVUtXVE2RCyE z97|iW-MimEm52i!?>VD7RIQG9`HP&MP;r;+Xc_tuMn;43rk5+$!u+Lu)7hR3H7Q~5 z=qCyB!gPx*ck%;E%m&4}0>Z*Va+W%;z*Zc#4QxFUmK0D$CSa@pwvg|c_hP0paSs`# zsw_i3sy$s2|6n%IOTW`=>R}#^ubmT+NeWx4Egc`i=X)-RZq0$~M#pUii-KGGeeIz3 zZ<w05q=coSCNsi?!%#_#D#dr?h+4iDNX)7 z2vLiS(<@2Fd?FLgvJt;2%kNfMcSfr{2LaF;M4!m0qX^yN7-y#Vdz7+X6y4 zv6NV)W>eHRZ=Se)kctUf1yAGS^LkHHh}b{=4GHTLi#G=-a%B8P-Xw=ninBeeNW3gY zN1R!Ux%lXtx^+%+d~g7i_pma=*S#AE;cqE#=G2AYwGbI{X6yx8;vA)Nj{0mF&{HE9 zf3y!DS>_Cze|HI#yV>Xwr;jOMAVhUCy(y<1AYB^qV+}~~YQ>p}u<$rX%U(29IWs9u zoRdX(P)Zn~2F|9YtT#z@7?mbeJ^epe#;o?h@*} z&Q~5z!PukL`vT;S^pjS5DO@uvS8DmcYOp~ldmlM%4=M{`6{i5RL8R@(`-k6?CS8cL(nZ5;FwPx8~XT=OL8LZL5u&8J~+j?dN zUtF^objwT^vl!|0oUSGK%Si?K@+$Sy({F@z9k$7!1`x_cIn_D+zRLhHlw`1|Bc@WN zzgwBj>+srbk(w;6{7|`v~tEE+3e%-ICRAgLg9tZ%IqaZc}la}4H1>OKm;gaSE_V@I9*<}Bmf7xhGh@UwC=ieyZ=BDw(HU8qc zadG#|L^(fCUASeVmaZ+{OQqGukIAKgfjgILwixw5Vv)I4*5<$`i#8FLbuV{>H$AE~a>(A8%2Yj# zoe9rXVa>qYi`M-KP+fNDxSSxYxIvvN#W71P{g!5VqLLrfKo~c+F2sCKXNP5|rx^aJ zV792$M}AoDPJO#nUDY=h@@jA=_T}LS1sfU26(+G4SwOaytH-VPVI3{v6$ue76#f;3ycyFlpYCUATKA~d9*nn!yIp#}6loXZ zSIuVEpilQ^_Tdo9xL|5+Pw^;!^$hij=DI|xoksh!0B+r6tfh8xpCqcaD zZOUEMBMUeT%Pv0EA6D3Ej}sqJHE6xI&(*;wmaoUwGVwXwN{f~79ube^W5fx!`t)IG!{cX`ToO zWAY4w?@vzuB35l%EnmCR z(0lYpH(oRNxG74AHP`Xm_0ZpiiZPFiqZK>0Qf3bFb`G?5^!qpP^Oait{=R9;(CF8*IYQi3z)i<>AB zY}cyd)Q_TFK9p3ITdk>JfKYa~oF9K!*I2y?45o6sQest01|Qswk%ITriJah2!Csn< z)pj@96ex}s{%)7C=KTM#_ZC21ZqeH)(juiG0+OPF(j{G@fI$f&4bqL2goJ>KK}kwC zh;(;&L@DW#RuJiw&bwX|^_-*U&fNRWH}}r>pE)xJ#ozne@7`72dymbD|vMRvEa-esCq zMUEZMo$<3_NYh+>A79weXW2h6j=OlSgLRz$>7-_Sugah>U6aQv8Z2VQETbplhc0-Z za>*ue`F@{K8==(E`eVh5yHB^JV<}gVrYiJNy(*A?9pflkzKlY7EXeSv*4{&DM*|-x z`>%52kL&_IcZsnwxJu><9BXb*wQ0~?FOaUz(#0ZYVx3+s)$|^s_q;PM2 zqwEnyQqz$snzfG7DsvMZo(j#U1H5ykxF)WICwbPRJTJkXqCTIaO>?1R}k(blRRMRPau0%~jf^w^Ckyg93D5ls^FMb`MKZ(@7-5}oR+ zr>1V?T`GPpWS>9SmG4>>MdD<&I?5=cv><6!5ZLWtI_dY}W^V=Wjp5nT3Y2y({<=>a zWhn{fa(YYcjxk1gv=@iB7oK+(=<}twJeLsEC|)~;dF!5vBhV&RuvJ8ac5A%xmbe~q z`?cTrUbo|yXmO63FstiUcDSYE22p-f#I|@=b5{8YW4XrqkrzCDDPuBgck?{vOy_c5 zRdzprHOgedN+!7Nt5W4-=OQnZyVUmb>S)6AG*^m~m$UGs@B|55?q@mVMH4og$!Zn)yyMSv;bS%c5QQ!|Bd+kEiTAF!c*Cuhg^SK=^ zhhDLmjFifvS%d(N!erv{y*~Youw*84Hzt7obz! zsVUY1kw!vB@u#NmtvZB&H7X~0+EQsacZ+*O2D809_Gp@8!dtWO^78ybp)B!+saMS! z0v0)KYkcNf-8UqTxP*4jZx<{D4H+=kU7fe+kZMS8P3OE7)z$4t?{i^V>TaW%-Jpcf zt4gOug|gn4b4)@{+-F<(CHj+X-fC_RmOinH4(W0axS1R=)ZG{@el_K2maAa}RB&RL zya@P|m^4Z|)V}p8jI7#WyP|Kg27?VLiwjCw|icYdZ#8iSVc zd9Iff(*sJ;{Gs9kxW`*~f*L1S-l%ErjHRFP)QYAHoNDzAQM;1%RS!g(!b;oiR26O* z8n=6&C%>8Gy9j-^$=#Ew)A5mnPYvwkyi)o%W(&jGr+1C%5;7{xFHrDgYAAG0PKlIF z6!A|oSCoC*heh~t)2{SYzFK+MQqy-??IeSz_ybeKlDZg{44@Ie;k;~w%bQuzrtphu z8`I9MW>T&iwpuFD?_(2=Mkx6S>V|q-KBW_np-!Zp4RnuFA*3fu;|d>aunpx89qh$s z5^1_~y3hh@Kzg_7?oBYkMpQIR{LO z+9zG)@`j3K(&mIt)yQR9@3>+J`4#sZ4^DDeH4X#_oKTrzms-E7BXvU~qh;B2WYT5> zndBPE9(k59q1zo#iM=wh+DU<b8*LUzA@_uR%dt*5aF7DEh zetL#^YT;^Q)20t{`7vo^<7s@q{Irac%a3u5#IMF`=nk_6(RqI`z zhzW!XI$8(Wu1nS*Q3KYj;d5-fg?q&HI?7 z2SZpg-&OB44Q2uMx=UA5?1OB5B@r^y_|I?IuWI(iC%%bG8!HW?XYG^c(AN$se^456 zq$g=dZ>l`s|tszie%uza)J?Ai5YlAi86+g(8s&|EVSv$qkG0E`q|LgTKW zI+M~TB_WM|Q@~2<$+7V)uFO8}jk9(=Toj75r??4QxmDH%LALstypEzz=R5tmGKdJf z@}G=q1o09iwcsF9w+SE&Rq(0UOuSu%{0!YxLgE|2cDpwhN0^=`7Y#Q7FdV)8D-Bs3 z)tRUS`Sx?vJAlQv%+sUn9R_$~RDOn{W{NYt9J0oR?J+~6Dt8B zujR_L@ihZlb`W~oT?*~6N$H=jYnr-Y;FdNouHR7iG;OP*S$8GjbaP-*wAHcN(tMX? zXQIvBlu@%3R`InNOP6W2$qKc#*_x7bS1C4f@iPjgYhMa`N8P<~LWlTF^SJy7v1mF8f$I z)46<+iHwP_Axp4*;yFff9xvJJ*hJLTagV0eKaH|21p_TCgPf2#ol>C9}yBEj6((w95j=Woy%b5%IX z3$Dh|A{U@&A?5%Xj&@KJHp`t!Mm(dlSVzds2X2kskg+sXkJ-qL4P!FOnpwR{fpgqA@%dv4@9iz9E1hx3vpWDIU!+0*O1E>Y5URH%;9j!zQkM2tJmPjjBm z7u(Ah%d+Yzia(y{qnW10+Eq(|6A&icKDjq$tG;X;ulY*A?vwib1Iz*0!>8$%OEecK zyf8PF(dwBFP3}mJ$2_!%c~*~$VJu%ib2;Chy2zeBv;Xt!9csM&!=*IwQ1zqxZ{tv+ z9!xyook0Kgx0q#^%NjlL*+7-VpEMD45p4(BT&~V34~HvB3EN*fxh#Hixqat01eU2J z%ar#jrdMwaI%TlveD(s)(7(+5W5g?xJ1n~CH%@CuI#Zq5h5q0Bx(ub`eLV!^Qo=c7 z!;ePbF3nCecNagjLq1rZ<#?A)1|Sz{l8WV%;tlYluBjHknnis=9o_ZSe%2UHjU@z;lHO zdz)E%CLd}su|;FI(BY9JgTSEJ2F=OsYvFUDybD*A3(Zt)K}(>>S=((R)Q#*6XHkA+ zrNUvP+kOJr-F!h3JIDx<+EER6MZW~{5?p#BR&du0cu{XJBMmw7I_eqbx)|Tgu9X=T z=@SZa4#^AIf%ew~gj6@Jh3JX67#HvYF@#alszNVFhM5u#${}n~FjmrX^g9gLX7?y? zP{oeo!BeVf&ctqA;?Td7-yu_45JCX`9$L1bIT$1>g|q(&Fz-$8YUueri4a3Fhlai% zX}^gk+IXCf7G~(%Q`b2UQQ-Ka9{gDt{^Wd$ugZ#{?$8^9gQpz)V`RS^jD`?KLrU0G zCx(m-e!+hg#mhr9l9w3W;}rRifA-5KzW=BgfP#+^Y&7uZG+*x+#QOPLCTU5W<|>8F&o>;}kFc zb7E24O$gT){oE*;qJ;#)d98HvfvC$wF?R>ABO&?kDk8*6L9AR ze+c{g5?C={qyOgwzB~;kcfQw5k^K8!{6FLcp$Lf3co>10hp`28v^_4g7$kpTLtGGe zp_uSgp|mzICO@l$PQdQ5ueBn(>`uU9I9;f}V?=MRK#I1F;Qf*!aE;F)`hF z`EYl`*`z3NbRGgHLV|l2uo`r@tXjVIz`(OwA}tE+ZnCNKr(Fbs$CFhciL(gu$l*%* zz{IhLMj%M&N6LPxNVspURh-~05U{9!83wIyGTBI8cAg3~uU&O&Xy_FL!NSaLgc+mY zY^EAe&=wk(%qGstW(GAC9Q}4d9iaQaImq9k{ zbA~xuMEXosQgnU!-uZ-=xB?TjVRFIJmZ>AOo7SG>vG5kz_#CKOVV4fl?0!Y&{Unw^ z)|9YP3DnY~1j6eyLpi#Vn}!dOE*0rUV|sJ9#U%AiAH*-%@3Q?q?qB|(ea9Fq|8>_; z4s zlbAoJklZ-}^m`nud#=!4Tmx(=+6Jm=_q14%o)_g>qGP2hJd7eWan)Ip0>(S#>rLFa ze;gCy#mE?;c%j;M9;SSb#lL@19UntoyfhVhthD|- zEiOs0ty@*KjD4(I$&p!!y+Qs`QNPTDhUJ)rikAoUsPG|OjiaFSezp=QfOVu>EFaCM zTMzW&H6&BA>s%6qL(^fRH4e`iwAC!{&N~bgTj6a9Ov~FJ7L5?H|?M{c-EH$ zdTux0=Uy=Tpe@f4#gHr$72Z6Q4IHcM2py=%i5%CR&2`{se(xP~>lP!r7b@u4lHWc6 zOZ;wGUj|^_VGzx_+0JNpIcwi16z&j>IUZ!ZopDt>)QUkFct6ZI(O$ImhH&WkQSjxu zKjb6M4=8;62`IoaCX_MVL^7x4*qoLp96k6s|UVg>E2Ym{h_pRH|r}P#Yt)Fu1>_RJE zVbkPehv8O${*a_z?-R5D7SIf`jbJw=K^ul_>%k-nbf8Uo_1@M(Gw`gmbzssoY#Ph( z<|aBl4NfLyBc&{mY&@r#tt}=_84dgbTt^DLB6(P#v)8r|l}}8W7q;ukcKxoFkx{v7 z?$g((&BRaq*<@~Zz@=?eXcC@OX+(mUb}K#kMBqgaTp0aFsGwf39HKC-siN#)DVsSa z0x}NSEaQ-4NNlF_2d^)t|`2Xc{q`?P0js#W804sFYy^d*2zT7Z#z*EX?t} zW%;6niB~taW2ie~G2Km))4)~pqzB<#nNuckccs{3M%x0k0BK8%hzJ$8i6Zk55K9tU z_7`S^c)6;Dr;kA=;H_tA!AKpK%~gr2sc;a;Hwrko)Wq`E9k*(|$%uv>Mtv6Hw7DSz zaydRL#*cx1fT3wG_?G73hW>AFB$$yyY5pIUbOm{%p7WEzrSZ4Ey^(Qj3l0tk6l&if z8vxwlxt!)Gfu5OGI~go!g1xF58Wwpt+VM-6Dj9s8k%h*9t;+OV3T`IIX#M59eAo;0 z%WDvcvGV!KEs}Rl=Na|-5q)=o%s?6b)Fcj2V^MFUv%DOWik<40R2z5SRO+$jV^5ji z-W&TPchW!x*{0dUup*wYze`=)M5~C&^|EKrhy__O6hqspjo*BFUNeV)Et6*jWy1cH zFZs*w!8XVk+k%;)$53^FWDxAv&ujwme$Dql)!ppvrdzu5Qbg|2Vv zm}9Sg=<(#Dww(}~>2>i2Gm>#|-E&U0w=jNwE3!6Vqsu2Y1D;2LliFX7U%zw}syMN8 zj30(^hijK=KOy<^@?!=fhxEMXm3azACrLDzVRTa(ULDV)ciF^PrsWnu_NNv|32X#G zra;-a1$>7O5_OH)E+9DCy=V)?w`7e<=aSxrQTRuk!azYcwF{m30dw{uIojqaWJJI? zqqw$#F&oI~?lLDTLkP6rS{g3Q6(K+%m=SErh!AS{%qKIKRRS4K4MO^VoM`$(tuJLn zh<@H_L|d?6C(oeiRo9z?!Y>)cBLZqFEs&tLGgs)2(+1E_0mntZ+VdZ-_O)_6t}Vd( z&l{bCygCl0BB9Y`yk7`4+i8rYb zCqiD{Zc8yFIBg6l2~>-;d~sp>S!@HpOQ(6&MEtX<_7X=U4TasUPY|6jT^}8n|58Lj z3M{uoRdtVst=n7KRfmA=%us`ZGV7$-Dt7-W_<>#RQ#San&VU61eW5W`{@_6w)ii-? znF@bC-QhR3YRG=gu`u=CZX@0I2?EGp>LpF%7P`=upYrkmx2T6Kq9MGTuGOWQUqF8X|4n~tb;0u~@{ z%*{ygBFUlYuSdf%Xc?j7eI62Pc(sVCw!>t565bUqn;N*2J5Q9y$u&Q)P-SR$7rbVntC1(;_1<|hSP4H? zN>@HAw7WhkzvOsG#AI&%D4oQm1W7+%NKAyDOz98+!KLy1A&~V@UIvz~%OGrGqPh#L z|@MtfA`x@|10#~ zPg<1!|0QX``aduD|B)3$(9v*|w!t1~A3%1G`CutG+c<*>z4;y5OJ)((7G<*}E-PtT z8I9w9Zri%c6A6CZ=8cBAIL-Jd=#3rWf7}tc7JmcPz8t4;&_Z(w6GaaH!>7Q-fb_XpMq5Dl=r|K0UzcJ z2rfxa+amst@9XyI7XiH_BajWqHg+l!cFA%5C7LEmv)Be^u(t;R^|LGV(^jCP^p4tj zL984?iscp@As}^%2cMlb_026cNH4is> zf4%%?Ic+OVK<;(EQwM?&B4bH!(%Xfz4nUu^_&$ttG{KkuyiD>)mbn|q-{APIfFe}d zTNg+IjDkYcyM~^ro@Y2n0O}Gb{tu-e*|~mTuf0d zQwZz1dV0bW1i8GB!M=Qed0xIgll+nR16A-TKxx(2PiXbSdbnxklX=hpQttQ~@kt;} z(EhGxu5sQ{o;k2|%FGUJ&bXU@4F#{rnYp>{Ii1bu#^mWcDj>M1O^38 z@uSbi4`z+f{%EPOSNB~Rr7KyT$1CCyJJ`IA=AtC$dAsPU4=k)UuxsZu;c815sx>^0 z($D7s+L`t*RzbRdfl^|7Jc3HTzB@OA4kV_!29f34gR{Vo`2@)h<)<^N71oT_`dRX^ z@@Tnfa56JYTkvP z^SpNPuJj=2;hBzsYEI@`L`E(hPj#4O5G0*lT^c4Kxxq%xL# zOS5m@i-T@waFaNrteIfbOiX^D++~yL&FA{SlkG?bs(_5-VifJn3oD3H0#bMi6Y!8& z^LHUO$ge}14Ru-dOvQ~`%TJMiG{K3ttRjXdF>s#S8WzB30jVr;`mKRJrqpaJIqf`E z)j^02yw0z-K6?mXW<$KiC8j2j`fXx~W&u}tZv6p~%;S{}w5jiSXcxp@5^IYXmTFM1P#|UaZOeGGDaz@HNJ5 zwec}B5}QU-!qDEgW`$wqMxyG;6)gaNV^`PKe$U7vgtLHoWL1c{^MYMh!WndlY7ml~ z+v+0b6Z6+tN)nY~{vBio{;v3b4@>C=E@f#Aq_Mv`&Kac{}DvC9(YXaGRAyn#|`mvJ^NVS&P0?2v=}waEdJLx)p+^=w77; z&SbkS?gV$2)!4c=F~?UFd`xwstV+LnJktXNcsKxz%Yyfx?{jV+H*fl!Cjy->$v+Cbdwwhg{!Wg9JD-~>-$=^qhTI&v1^`6iDdbQ z*20Z&Qe<-?0m+l!Oe;DQ$z!Q$9+5;Xv?hL*PnonppWTUVa@y z?*gNOF%Z<@Y|Q0Q)0l&_&18zMBX138JeM$#$<)f>kzXnAg+Tt7CyZhWy~y& z&opn~C%*oIElx>d!b)XF?aE12%*Eou{j2;>yH!pCaYsTqoM>5`_K^U%47s&;HV1TP$N-6tUAjef zFP&MxIDwGjwX_z#^+o3BDraCkHJwzv3tv6QR3h`AFVkv{?2>n-8SG1vy2t{%Up0vh z2+rjEu=;QT3Kl@1sBUPc3E4eofKPS%B!;#*0!i#5RE(ylhGbL)EPPtsfJ1{Lid@ej zhSN|+BP^s@g9=m$@MN%GeGNEsZ3IbW89VV&zId$>V>7W@ch5!mVjhj&L*!l_-kGyM zIfWF9zQy66o!RZ@1{~TGuN3IYo&FYy+ij6^SY4=l{#w6ZMwN%UyF}@~-$)vHqsr1$ z*6;NQcM}tUUh$~s(hwhonpeEu`E8?5e?4r2^oBZdfyMCd);#qr6qDNE@J;~o;wlTR zJnD=@X@et=eL>=$YZ_RMFC$!L%b&ccFEE}TjB)0mx#~S7ztsC+0tyOG5r%mBzUA zHxMC12jK}xB6=C`0C$^U5i0zHy1M%+Qp>H&zUk#rJ@e$x@eBO>iCYkiFEhI0czuiC zmyv2KY6Qmrl!5;bt#c2-(ZQu!Vy(ZNBC>Oi4dcHs1SqIorxqTvI@A8ZSg0OPDLhC8 z**-)t7RpU=AAw={$aS&*MoAQ4<5KbydwG~}lNCJtW{cku0vn(I??EFA^`8F&E%-N{ z=6|pgzr#-44XOsx+<4@!X**H1{&oU9WgkcZ75aV|wlFB0$-QO^vEU`7%(8rdtmtnF zSUxc9f2K;SQRwfBzecgt#wYle2W>s&&U>X+iwG0&Vd-~jDebwk!-ZX(N?Ue8r7f0L zhH4aYDUSGL9H%QG!M-0UL)uz4Z3&t#Q>vgs5~UVXGeLo5e-Vl}YJvVRH1*v1YZq0_OqIk5Q zdAoB;J~ivWtUht<6U*&>&MWvB`_U!MnQxoITtj#SaRrjn1_e7VEZ46LQ5c2rP!7PK5HUk7*3 z@0r2bj2Vd z(z@Z?A~4J!^CRbeb$hP}z|ve965DI-^=nZ2NnB~Cr_3y0YEU*$*hJF*L%I6bnn+!s zRJWp70Y^I2&gS!+$h?85RLAKx#)%q`RgvC9Di8)|D0>T$Zgzw;c4$%8iV_E3c>SaA z`0zE=WR?N9-!BakBRK6x4Yiu>barBX`@Uy%n`nz-VhWxYRQHjp#yU_*`(y#F=sFb3 zpXfU?Z_Wh?ltF3#GJVI$+h+>m*}`~o#H^;n5LyN&S3r5!vmKvWSP+9GB=(kni!$s@$B4bz-D`d-DU-uWpm`ks2i*$=O)Ra-+OP z1Xve~ZBWTf8LM1sU|f`ipwj`+S0x)rO}V#+{Xc5Tn@A|KjAyuvYlxTurzUHpZxRWo`aLPD02#B|W*duWk?& znAw}3OTl?&54r-~g=LH&yk^4e`?ery>J+n42-avq5^(k+$6XW}Q&d?bq$ARMNy8sP zmgGX`n|8Co(k`Xx5NozOjSXr9(1lM=%y@cU(0^z!H}R%<#|)9hy~$z?8CACx*lO*i z8`;e(6o1SjqTuCcf;+2f=ryOkp9&R4LsLfMvXB}D<~cUqR}u|??K%gF9pX`9%I^l_ z#J#%7F7FquU3a*pw;>%jg_{Tbf@zE`vZH&^5Y4C_C$ryi*_{X4aFqhnYd-JRM(sw{ z;0RM@)P*);G0s!Y^Y@0Iao?=+z+EHfgF1IDPv<-smVq+>etU{5!2Mr@?3U>wkVBIo z2#%Fr|+~EW>=#j7Z3)Oezp#hqoj74hzrkqeAxk@1?27h!p!=STE%y6 zrx)g^P~;0;IthKw)+5UKM$dCIFmkE@lA^;WXq1e51e##eyXryH4Ti3O$Ci_C>}GE+Taw=HE?zE)@x^rrurfa(Mgncxuib zqJ7HUH^?fBkAkze=C*gMKjp&n=W6dPcq*GPV_Oav_wU$oHk^Q78kSAm`@&tZy(l1+ zJDssyRM;ESl>9LyF5miob}ZSkfgRNzLjoqKYEN)tarCKe$|p#u-)Gcc z0E_^8^g;B;2gsI!?8bF8E(a-3K)JLs%m}RwCwM+Ov-UoI}SD6(KoMO2NHs{J5M(d=Cx=&0Cez%i88P zlS!f7xoo->xLY_n$z+G0P7y;1BDv>13J#Kwzg-z35fh$$2NZP-lgT*rq&5$uyzNNG z2Irye;twL@mrdq%3_V))mV$SEf|9 z&X7QI)ql8K2D`w89~^t;`svxXS3ll`f_I|*4nW1=djd_-qXg_Td#_GM;seEgaK7V8 z=+Qyk9S&DRpMjRE_aK*+XotHo;GWb&ybSsmkCBtx0cu-KLaxt-pCt8t1_cW57^kUJ z&FrL-Fs@Ze_`g4%v1{PZs)_3HS!ZbPQu`G zEOsoJrjzvb2E^%ravpwhe}M(SWe?+ReZC(X8%DHkyE_l$U7v|RjVH-oV1TQP5pRq5 z1YrB>D-G6t&i?5dYUM$;f+cT)A@8>hBl?z0)bk;iG9=xkvtmNWK~*4_Tw%o$$w_?6 z5SHiWYrL~K0@-$_jPiIcL^CIF!UpB?;-={^Kw<(_vNY@mxue2F^NuhWgg8q<0 z=??e^K4U0x4kWjlF`t?yjJqub#&jmxea%?`hL8d9qKsWuWMd4ots9w`Jr_r7c@l4J zAw099G3OSh)5y4p?=XDqn>O_vHbVW=`t78_@wXW&vgx&7;e(pQOH88|{*TU$%E@t+ z4od7b#!itx*+20vuk-}1ljzkkKTUJtKv6?7_7U%jwiSITNVozt(#`IrghC1BN}4@r z#eNQ1go`-IN^ilwvB!{7r?erq{7X5-5#%aCkIf`x{CXIh#8+ z^NoW~QKjoAR5+*1B$JnrxZn+r2Kzm#l4?&SO(GJ1fI76AM7D4!BK==3d z+h-@#0+xvmA;?i^VR!pp% ze_(CR6QT|d0uV`FheFUZ1fyv?jNl#>L*t!t{ieTL^lwkDbvN>C*J^Qmz6X^&n7aGP z{{8))?7p{_UG1qL{Oo&P*86p8QeM5tS_j%}V!GhG-!A}gk6 zoplx)JZcTfvtE#o7x_W8Nw)YAZYt%NneX5O-SB!_Mu!*=_kI3*XIJCe&x z+#0)oyZKO`JvfnEiE71n;?9_s2C=K>(XQ75Sbw7QZcYnhF_}rkG*@hkPC4j2Sp?;0 zx~ft(hQdXq8g^mYBVqy020-+s6j(`R!@16VeE~&! z`D^w-ZPGRJvWfWa%m?}YFWr;fYL+`Tb4@2k=p|8jDl*bCz>g5&(uaX08Rj9Te|VBvqloOJ-iI~3kH#3bALCrF3Fp1ehMMQFVv%4ss)or6uUdPriK$hlGeF|Fq=RE9(`e$Pv zKCWE!vAhI*wR>b|nhA^t^g3N_A!56Pv}qk@+mkzQ_JkMnrV{Fm!FS0dhLwGiRba z2X@+541c)(BF|L?$f;o`5s7a)1z@n2np(Cl`UcP9Hy{1YO23DfTMRHe76%m-GaL5uXADFJ_> zx6FU1mjBgLNC?nH!fAl3pz0p`Pw1kYIckjCu44hg{l0?^rcDoAD?vhh4IDGk=CPs%O?Iit@{tOBwIH2M>)1^Aa`{C$D{rPuC#ps zem&)Dsk6Tf$QJ~Ki z`lo5DNRI!rvx5Z-Z57#~ah_v29e@5;EmdLu;yi!p3@47+Vp8~ox zb_7pq<$IGMGS1DAYFM&(M96(}DYS}WXS!!; zpUawntgw|W_(ZD?KB-hc-~H$8zodePzv?mQJiyDsO2o!s8!35!+R~{$NTw}A^t(2h z8}sU74&i;#iyyOgr?PIOcp%l6Qb4}MgCZvu%P-6G%a4@EA&7N5;P}sPuC6|_Ux-l! z*xHm78)OhBkTPa5R^xNA*o)|^aP@SiYD37<21$*0XtYp#xvF^lclNb>0Y>gr=JJyA z=hH>~2wM&DmrFd=EGxJ-i`=$~s8Wx2!IE6khUu4$!l~R{$&v*1KflVaQS&I6zk9A| zEE)oqM7fmvi}jLzKwnPv++WeEJ->>3?h&bd)FQiYQ;Fpj&&vedh??Nb{T7%&11b=Wj&jd^w9flqqn!a6Q*(7#Opp52H@-r0&u2!vREO@6NpH&W|I(; z{Y$o(P>S`?F`V`^Auu!S?>f|?;fE=pPdoSStm-3vsl2;!yx7Hu5wOD9)Q^u&TCn*^ zM_dSo__R2qLGYiV*od4hDI)iL=*i8W($KlLv|D4v+S6{ahH)7OKLfH1P#0G4bmm0yf_%ozIO9B0cWSf{&N1Bvtq_SpWQAM3+-;X z&KuSnU>8XjAL3Yltaj%*Pk9*xd8JT6YcXH|z*%}BiC;eU zeNyVQU}~3oViM@?AG|_hYISRzc+$PKxg|)gN|oK6ZO;!PhOdl2JaOkthH60o1Qij9 z9*}&H=zlQwyJ7Afr-{2SCyMgp`)DqSdhsjg=sbi-NaOs?S2c22w8G_=s!dVDNo^s8 zPzQZ^(l^{Ii^6_R+RvZjkNC?G4nF4o`8T;zvCxLT1gBg?9DZi;2#yNy4Ulw2zdGe# zf+{PrlMfJv*QbwgTMnsLLZip~3?^>zpQAbWDd03{fCtd@{$f@J*xsb<7y0eym>}&I z0*$f;5=k#HP_aqf5iCfl?c^!Q-#?j5)rNFq-S0HfFA>tj(V*f#`(>=xVnIoH3DWv6 z;_$(C1o<2mwC^60Q$x=c{Rpb!{!~IvFQTOo2+0QIo%3S575^>WO(=C8Lh0FFnD|>j4Ny3+L?_aY{Yqts9i+k*I($eX%?@s8+c?a->7y^;B0{)H6rlgBAW| z+zZJ1V`KcXMYd7-YhHsACq4gXv7Sr~cCb*~6BEN#Rm;;ove1B|6M%!D9zSs>JNo}uQkhmBA!_2=-(FyC0xr2>0K)vKl)%Mb}E9V_{R(kRhzbF#@`0S4t#%6^%a5x$A zV^Xm7vPE-r-s*uVT0_%R17t9p<*>*Gx)t%$)p zIw`OKj$D;g;-7~rmpiz84N$LQ2L0}Up^AHwYEiJ!{m-Cgs1=1ACOQj@?p{gI4z>jT zgu#`j)U!W6`(r-*6~JI4&%PJ?@d9;s+#yY^3Fo|_6T?f@g7aXn4)+v<&_|9JL-t&+ zA?Tbz9#l2!I#U%!2Qj99V+UlkFb5J`biqH*md7{YXjz|1%SycTO<(K4s#i|UovQpJO>r2pw-#_Mj(}-%V_5KW%qpF_B5k#ztk05>zj7YYgieHf&=M5GX+3{T;*Uf5-$qqu zafosRIfh_E0rN|%V2j036F(Hx92_H#fK^4gd?WeE?u-arsK5Pw;TQ73PNOY^ao|JW zM@g7g4JjT5Xe}rcTy7QTxbv}EnMYR$-meEn@53_VN_nB~A*3RJuU&5Qn##6?sme;W4p zpYET)kYZTSNs~ADF~jaJFyPRG0$zjdO-<^ zLvWkUnG@qjh<@|9C&=S;(r(cIc-$en)_h}yFkzQcXDC1+g6Eu_hpgODP_GcRQpqCr z1AdV2_SW!T$lPEVz4`DA_P@8K)Ct7rNjk%T_2WB5Z(!JZe}%Tx@HqVQO6d&Hq9QZ3 z+e-%jKrZ#hnLx$Z7KXL%j6)G$jSAN>c!S+!=wogz< zBGu2AkoX9fBab*G;`ZGru^w}#o~m9AT7X09N*IU!jqa-g_H#jSkai95xj<4TWu}+{ z+uiIq!_8Mgpj@hE()p5BA^H0A5N0(4uFI}2g=0NdoTcok6#sm!qljmC|IMkN%Q=6T zNxfKZsyoB<9Y+s)lONv~(l98zbf&8)03y+$x6D4P9N^sXCwc)I5-@&zAkWY*^3Gp} zlS3as-_e(i#bp!#p+r*f-l?XTM((;ut9NAQ_*k&SX!7aoL17ogB}DuFzi2;qzy@qd@+@qGuxLy%f=4?KqS;I4y}57SAK9@4q{X?^d8msR z;k!TsMi7OpTR*h!^U4k4oxG4ZQ@pM5diZ9|{q^k=n=ZSFXTDM)nAWeKcY0D}sbfTF z&o2lU$(r+oNF-!@>|9y`lO8!Z^5AX&#EZJOCN3_}^@PqD?&gB6Q%VA!sEp0q5N zNA5qWK)&}+@#EsR7{NT9q5moQgWXi;bAY>wgx%EE`f2swfASwgP8mlOIhTV4ry)W= zxZy89BdO=^QP+Kys2jRZqI=(TW+WHxYjs5CnHsHunsH7UT-ze}yN0y09|QCT>wW zd6x50neW){8v>EXd(Fnktz?9XMTFXWegPV5>HzY8YWFtb`+J|^-nn-E@_8bhrRhB8 zw$Y{DkWM*W!+%VM3X}ix+=-o#86vd5t(JRG&3$}J@HHnyC|9d@Nml4dUuaenPzzJM zFbqA;qW)o(a1JUhTE1gOpP+}B0Jy8cWh^ani{l&E#27PxEXJA1LQ+I06(!)MY~+FQ0x zkZN&8)SPb&6YM_lsNQ1D@)E4`Yq{X_?2=!j;mH`ruboa_6=}hw^I81k$ZH6md zn%Gy0vG6I_B5DHUw24r`!yi%L85d!G7PVbLh)!7qQJXO3n?V^!04@#!`b^kO7NZi} zzpeBfmifUl`_{rI#kqJfj+(yisR}9KMGZh~;f$b8+J^{IuQSwTwG@7PeKO76_pviI ztiQhB{)vz%kK0OW+(~*xAoWtzW7D70Q}>8;0>CXLqD2twQB)-$UGI6HqLB%wl#}ufeJyP@J zi%_2R*wtak(1iu9iGzhknm^ZyF<+zzZMh&U63O0ZGvbaMV1GL~9=ku#rTK&xXuah5 z=uOPueogb7v^5TYdCox^_YS_D_FBR1H<&h`EP&D}vr5fvcf&Am8+MDWhQ(T7f2{+H z>tr?_zj4L#NF_e~oj&7~4IC0CqlTAH5CDL0YWd=6Vq7Z054dU{uPfd;OOy`P`&%#N z;wWl`92R2FWrb|PS>KSOJ`1(K+j+jbP)_3Pv9mUPzv}$R;T+~WKWfV%qVQ!TqxNM} z=+nao9(t~YZ@-2$fX(7*ZkolW*D(Hj(X4P=d5s5nON2`<{mrK9YDghtBC7q;6Hefg zU4vZv7SoaY5$=@7wBc&YY#c1SqNgc%qH1Qa(VcO@m!5z5zUF;1$cEw#onV_Ibo0o#utW2>LgBk=$YhugafPQVBwYv;Xbaq8z%h*Fsso=nOz^?yp^$E|zt> z_OhKpUzhcT+j-6(vTuJMbNPuX31H74JzGuOI#vaZjuOl^@rN;3tG2B_K87xTYw5Fc zUce{Cl^reIMvM2?j)LiIlW47&Y>mJ9`Zi39!%{tc(>9g!Z^K6=HwU^BYm5Klz)DS)W83YYZj8wL{$K2Rr6d zGbUB)CDvloT`%S7?y#3bdO)nvTCK8mcC=)@D^?6`_~8jnqXq>a^3#Ge^Lw^K{M)Z# z(8LTj#kVOUYh_NyRXe_(g|080Vq!QndrIw0wZH*E`)Z4gE?~U$=<5f;aTgif8WJ>U z-Fe`65_-A2ZUK$PgCR*xDF&%8hH8Q_sTc4!%$_k*Wt{MHIC|iN{Cpcx+y^x%G_*8_ zqiSwb*Bt$IH5{qY_&Z-C-G3Ox008D3nJdjb_5tE zxTmKtZ$kDnd^n^}z+H2o-55Gx9Cz>8KymMja*p~o2jk{m#{+lhGDQ!T4#YJpsoMAw z5v$+K-#-o-cEP=a(0iDWxdj6Ded1d~kgcJZW>wCvW321f}-0G@{u?$>xA3lr<_zx0qT4a>mmEb&Xw^+`i(T&bV0+M5%AYpzw$1?ijL zWGS79j~(Uje>z_8QuT3Cs0Ff3FV=i2hoM`Vbg?2AdPHB&JC0|cDe>`w_idcD+A#Y% zv_(^t)3BP)_p4EUw_L|#XpXrZkLg8>q~8C16OKG_2STHo5*?RGQe=+x8u8~Z)e4dT=pO+MJoIK{i#M!n-+e7;` zz@0qTT4ry#=*P*jEAV*?Qq#U={<{y*OCX;*2F>e7_wF1XneP^vb4k?kgoy5G)t0p* z?3^*!U4h};rdJ_Gt8we8TKB^Dhg0Z@2rbR=%U32y4I`}{t=HZ^v3Fc%aV?!@_cY<6 z7OAw6me~W*LLA%KzMDvnZ5N%c1S(1TNHCQ0F|X;Xv=qkAjOzYRxyq1VVzO|4^&_q6 zAXY8X>ApVC5xldt)(FK0I!M*6Ud%a12Qi+1wkR|pj-{qVbJX)SMeu|IGX#A(>xD}{ zy!sz0C2KlJGFdEtAo&p|)5u~#p}wjfUNiA(@cCpz)Y-WEhvCL-mWMKHk2P! z;mp!DaYB;gNE5qoQ2 zDM3GrAlb_UR>JUV*GnYf;?L+V;X@vl=z;X_I<3tidC-Qg-4CQcOybANK0XW9!bKbM z^Boeee*^}TkOI@5|BJ2bj_0!d{zWQOgi^{ZE31&~tg=UV%HDf#**+o~R%Gv#WMzHq zQ3@d|duL>R$j<(qTVIXm`Th4iueja!b)D;6=e*zVbIvQks>1&X!baXilF+0z2?a5E22F_nkb-{u_Boe}hM#wwa z&RkIrfhQPf(Wak9R^T#D0(NAH(v3PWy&{X($4S7tL*(0<1S3LC|~F|Lh@EKLU%P&!$x# z{8b?`+^P5i$nu{%| zo3DRyDOdgAgMXck`lDdVdCAYy5f8k78bge*APo%z5VHYX@fE0rFF`<3)4L*%5yQHF zZv=9cXVCjb-mEK=5pdo&fVqDtd!9Ug@X5ayItLbdoayE$27f{jMsuuhmx9swO{ zI5aY43Y3;^L;jpKK8)n!Q_Rs4aGA|261(a3|8SS6|N2ZjT7?ub+%SoxU}&Ne2Ko4e znU}>=+1L$N2aG@kX-k^%4 zknFYPAw(<-g9TMV*K3egxyKaKnj-DkbfIJ9d+G20wF?x1!RSOk%8OL<6_aG`43lpu-AUDK?b@n zlnj48wi7EY&hGK~nIx086h(mVm-#ylNABQl-)p~L zEfZXVuBpmz=N`g*n9tK0+>-&+>3r&A+1jU^B!qN;P_hG6<0p`YUjdvj1OhF(x1?OZ z8L6KidkAHLkhT}pqIqe&_eeE_4tfFnZ}~SET2pS}NAtVn{lfFDoCVQ1{>V|vtoFqv zPK9mEgHwydMus3jcRC&X?~Q|NT?khB5RUwBXY`E42E0`4*ONgY*G<0hGpZV4E~boiJArEWS4ILL+2y_PIB>e)9td zD=vfhoG`Vp(qBHultuwKeAOz?3PxE-?#H1;g=E;XJ16%4^bHiX=tGH?1c3?I%V)@a z4^ZX*%kLOOBQM=GqWnwjAmLXHi|`Usi1tbkw=dGdSAsrW+y5Rr`m2yIKp+@AH(aH? z3v&nL5zW*9CM4@WzPEZAxj!p$(+`%IDntt_p4ahN=q2%nlv_{6AtaW}d4Gp&eZH&15-nITpIhG( z3kQ!R1XySZ$ebqT%N8OaTN2#ClYF%Q+j>M(Z7=+hIfzDsfK)faWu(^^^!z_hrpia| zqRh2au7eK}O29?1;I3@V3r>3iZfoJNW%b(|%P%1^)a}+kjJ&(|jU$MLLSAqqmC*w1 z&Jb{)AqMW3|B1p;sR${{DdpsQu-*n}?=^0Pmr`fGYzdj@p#bV#_S{*$$Iy*Ar?+}VTknB49Cmj24O`%9v787!Sfz9ZVi}JT?25O@fhe!#(r<)74)`UxCa_PHqn$x-{`=_HVDNt>81>Xi6@(;AcbV(l zC!Zp@8(^Qzz!N((|MW^i4{iJ9 z_6(nn-(2Z|tvrRdKZ5mZr-j50S1cE3S9zZ9#?_RtKKL+pc|`OB36VPw#QTOosQ6&k}CoNxXVx^8s2YRCBQ`f`d3DV>_cjmw=6>xuj3o&WJSG$ zFN1r!{ums^rNi-}`}>6Ku@<4pKyfax+Wm#EPuPw$yq7`#G-?lzn&&$axM0 zLG?(P|8H>{Je?}U39H%H2g-vOFb(1;LJ8#A?a5~tun!D6b}%kpTBha z^V37t;7O?-#CNJWk?8a!8R}>Jh8Vy!-CGd8LaXE_CZwJJlQdmc(t*^s9bkVLpdp_M zuWI+>`&Wbc1P^M&u73H3YlxVV1C+P9@XD$KKa|N2&ctzg5G~NxgWRiz#YphyuapoS zg!_Vf+x8$OggX0(jGf$Te>@SaDgd7K=yk5_f233g&z8VOL7XKGO#TEYj6xvntOq!w zJqbi|2S0+G+dN4yAqz9hnHc1fc+`+f{@33@K4e@9N%GnuB8L&K8A#6VG(QmipI0Ib zh6gN~lD?#0$95k1{1eJqX8gO;xK_<<~aOT#Z*X-});2T^n zJ_C408*6Z*w%8qh^UD1>(-V(k`f%>9XUBpMEFx7ck*KQL$TbpGXob8tB= z`;=iRB}IhEZVXiI?O2yU0|(F)dLm~32_pF~#RViM4_0sA%d!fIpt{vVmeNFEWt16= zzhAQuK@Ht{@B6309Z$`#2DN~&h%oPsR=gqOM-6QrDUoavhbN-b_`$m4moRSwv-+#cc%M`axU`NiIH)d zP(gpUAZI*z$v-!|ngjXSSLqBUf`~l?|A@9R0oh~nne<7 zA~(!BB(%JC9IgNHZvW+e5x3Nbtm&Gp*x@foR>x^_gpCyCi^Wz%VfYJ;fZM7JoY!|P zxAmD$>7ysf4DdVwC}@D1#`1f(Qu`_Y!O1jb0uZr}>m-i!CBz}WzE-Y6LWEb|V;260 z93C}C0)90XGXyD}3vh|DUy%`xaHN)vZZYhKcL&R!8V}27+I^XX;Ur>QHMbWPL*Y#n z&F|d(W0mvNAy`^Kdjacg2tuz{SV#e%Arx^BWu2h?<1-GS3QmIuvW)TZNkyCnu)bOh zWUxObv<=9u`D;tAAgec)1h)^nY5QfRM@T3R4KK?zsegNI*xlAFlpcYvYfKV;@ZUE?K;6nVdmREu zLq?KorRq|iDTD-Ni69sc>IV++?+gfF3jK_wpu-6>3@#!`Y$4qX8XXvg+U(~@I}eN1 zMz$&>L>?W$&iIKA6C&3{uKLTZ7zB>kSe}g4J9X}=(B}F=;{2^w?!Q+OjQb(t{&im{ zq!tjv;$vbysN>N5x>Zp&Sb&k`XxO~NL4Aa7x{&}t;Al;D5?8!c0^w)Ao2*XjVhC|O zA~!DqJ(8@R7=*wGosxHdaWtSTLn$o?(XVkPzqf2Z;!mn||DEOO<^4;Np8T}1GVTt+<5 z%0%`&y<8jvP~;8EOK9_MIVAq^+Ug%}%7yf^vN#yY(jEsTYk+1U$ug2v^U9Yrd4d?y zO+6@*P)ref)Y>bY1Be1MB8+I||Ct}%2YE4;HCjDYvHSHMQSc#pp3(=BO7VYJPY8v; zx(i<{7pexN1nb^eqgv#hGZizDyZFAS4z&JOOcFXQ`Hu+d4G6b*+6&F^VTVhI2v0OT zzg5I%Hy*GJA}G6dN&0Bs4`B)*i#?3^2p=*@HyIE_v5i9>P7u?Azi*QZ;9y1u(NC0@ zpv$-fFcoyX;jj`f#KI2$jS!+#z&!-qdgPd=2|mOk*juA35wbQda{;XrqOQ-12P4Zre}lfCn;!NP7tihH;!u_lXKa42?wA zNKFdVIwZLR)Q=SEEc3s;<4X_eYPIe@!?3Sub2@|s@+;QLJ1p09-yhkSytxO zp^!OzrJZd3sXWBlGMkK-XM(?QNpGw~;_43k9$z0MI4v~mlo9dHC+WlYc4CC76b_RX z%Sd-1PEi697B$W~_Q|JEwxe0n{R5Ff3FWkJQ56`}x zJ;SId2Diu06T^&A)d7IfZmN~KO$;03*(2xrZiok+%aL52{i1)NH(#8S=PTr|Mfnq* z_q3lwbF3TR`!JI5K~`G`B=Gbik7DKCu3OQ^rhNnYo`iT{i-IGM-J#1(1FVf0F^+Ll z6g7O4v<}<8Y5elPAi>(^nvyVkZgszk7$XsCV&qyFlkm63pjnxf_EHVI4Wz!{tvS6rlg}Mb)=D zs6l0fbini%-S~tj9&|AjxcdODIf5G>!xXOSR3Brep{`QVYn1-bJsXX-b3|<0eC5+ zGi8JD?aTxMD+*Ia-wK_0+@W93qcuSr&~_f{vRzY15@q2BSp>>(4U%^a8c<1IV=MH> z!lY9TkjRS&!@-+C)bWsR0&n9^B;jK+R9*ru`pZQTH?>xLg`ZLW5GmYXTbAeKPvVg< z=se`)g#kSiFr9~3*2X{t37mdKu0Jo&`$68wl{3%U6nMv*0#DCZ?>e$Jm$105jX)kp zvNOpwO}^FV_g3};QG)WTI>I*nB z88#dc=oSLjJ79T+gDt_==PlnN+kKe!`uRs=ACn01?3c0{epW>U1LHap`cTU5+Rd#w z4g}+FO1!Df86C2}Nx$CsEo_zwF2(7C8kY}@d&2 zA%axrW#_3@VOD5=z;PLsojFG01uRE)zhCS$oNSMN>a!x9RXC{i{t&Y93RqYd>$o;?xb|MeMmA6bagPVC2%uF&|E`JS5cPnFR;nHZVl;@^ zgPe-HRbQx>8ehYCWjGp63p6W_S_~5HW&=>mgaD_{F?Yz28>)9`cf{>snPTIyTVS_Ag7>sk-@bA zaXsf9jVJtK& zN3{C$kjk%D@`)5tlnY_dBtls#f|=24XEoAcrh{?lv+6#+NcF!cRnj(eWnCB&pm9K8 zID;7l`ThS)gHW8rQJ_^AaO~DxO5EF~|15RemQaEc3H{Po_*IFB@c4TzNDwsgIPzr< zI29qg(Bh~b2+(mPD1+%>YETBC>x$dz`v8b?38#f2%e9yE->$0)r2*0&J#-RLm@aQZ zn=JOmW*DWpyb0AHc5sAaCpQy0l3}=mB8u*$$@}*pVq)!6ss_>7%O_3jMZVbi->ddM z#wgeznrW!XkqtiPYWo#x+l&ar$sNOip}h-1kAapofI19^-@7m;><5JRrI8?}@SfK5 zyTruc4R!)we0ui3eEz4`4XME5N~UtdflAai2;~E;K9K!UpinJ}1!GS9k<^t=l}au5 zdbAFxTVIvwOqN1raH2Bs;8&%)zjy(VeWK|L#Rk*K$9?5!%dkpI7f>qX9FCQHghJ!x=oac$TS@3M((0W-ESZt!6NUO9O-YIsv{WGxu z;r7T5m(1OhXPH%~5Y{eJy-4oO-K?0*!92=8jt$}WsA{koR>Vv5!(2%a37-vqo-j%i zLI(S%I2M;HPMu7p9~vs8z7q`gu+q;2COXsr*daaefeBt1l*jYKcRu z?O$-r_XPO2A@h9Y=l3^Prj2@Df;HCTkZS0-sz`O_^8A)e!EG>}2tT`F+!9&=DlL?A z-xU^VDG^~cE_}bg?mwh@N<$&)3}F<|wgo0_B7m)krz^gEJU39n@%HIYH~PPPDO3d~O7{l!`Q?<}WyR|D%dfoQNmf+GQetN{eo zD8rwK=Kt;^O%^&e?Su>F7W02!@i6e)zDS{C2&Vb ztcVn*7(x$pMn0}%f36d%1EJY?&4b1@;n&LholNi8{mi6~{IQA053XY(!utSGO+YC# zXAYu!R)z7iI_LjjwD$vA0P>$YrJi*`FpZ&2qwOIG5`WOW^7$jZH9%OD^IyUlGwKnp z2m9!Wt92QgWoTyAyvv4l--Q17QL2!2SjzDV+fs^TP&Py9m!VQQxG6x6)fE+$$<-EM zyf;T3j3!S<5O>Z~L6N&u>He&_9?N2o*uYyf4a$uk-xYUMB(Mi>Y{nwMbS z!tKH5T{j|D9mF9$nlSK_zyfF|0_qNx;AY>E$jJSh^sjeDAqXlw5Zf7R+zrLxZF~e6 zn9IPKaZXr5K`AobFoBT|=TC?a^&JZe1&}K4d6+QB1Ko`$Kx@O!hZG4wH(ZUC>}9|; zrGeP5p==VB22g^nPrn~#Xo!VnR&Wb|*m$YMYgY+gn!bg9StjTTGzt&(}Z4abVPV5xVii()sT-}f$Hu@#itPFtCw8Q{6r!yTO z6n4l!l`Lcr^_JMDnV(s)=HF3g`v(^XO^ArD<6x>0E-eYS+r8F=aeDa#=F%!8h(Njz z*ayHB$*)&#Cenn$J|?60bS)}LD-=G5X8JAjn`#K2Wa-X28;iZ%C$WBgP`xqAJg4F= z^cuVY(?pb(N-kd<%D{qgUsvhP3$~pH9V5%3Fhwg1Z{jbarAi2@U4V8zK2T9<(aVm& zw1xmwd>h4hAI44v+~shij5GrjE<8|vqs*vqla0Ua$%LzD!H`Un=ph6E)_sEc=!=yl z10k>h9HVcE`F2nwlpoG;M?|kATEt(y7&_;Dwjp#)5GxAg+}Ot7@D~=jHqzq0NY3lP zkZk#gZ^-#iIsd*uJfz{=58#_UVB#dLSJn4*>ukLdXrjE_n-1`IN#DIIV~P5UF4Dh? z68E1l{`9by2x`M+p-QxWwWz`?3VUmL_=eM*O1I<6f(+kAS&Oq~-OZs2Yrs7O_X0~R zVUFjgBBRe_!;oyd!&f)vdV-G11C&my(A~Rw9Y!v0Y!5CS>nhot$?$-ZH;zV!k}CDR zYIe(E2nK$@a5CEbZO8$aU=W63B>>RPMFyXU>^1h{H!A^=+mhp*PEEpy=+_L3qSD*J zJzUBrEsd`foG%`8hsch@aYZ{7HngZ^9q7!BZGodd9-n2IDXoI?mD1+~*N(JT&Mt$I(>VfSUE*31{o>U|*Hz7N7& z;7S`yv-L4~mG2es{*~ZD-gm45Pk7yO5c=e511s$g#VV`uPJO1r6W`Yvbb>PaH;AcZ zc*FzA41+SRrA@ru3ZA^9FG}wvBHV!~l!5H|+AQ=IXl(0h+4%M-O(!#U&=amZ=dI=4 zw4J|o?Byibmq`e7K0WS6#IIqjo7y1zONqa)%OlDBul*K^sTC^l#i~fZn+AlvzolqJ zy>%M&HNnZ6T&So{Bkin_brrtHX2!R7H(J2WsdXmisZOLhjmT6g>37T$9Fn6fU3O)% z`$YmkSDms*>z}nP$gBcrVnifALSCD1Z=9r#rJ~RISFGa@@{FOv8J{TsxkJ9_gbC4&Ll5izxEYkn``14AcK_Yhh+Uz zX3o%VvH*=`4X&TW59TKqDZx>%QG0%;{+FJ{?aL3gqL94ws?WYFEV0c{s zRLYfLcw5^wY0+i%7%`etn~? za~%*MCY!ICk$zf9&~5b*V{e!j zj;9m%rAzP0>lZKVNVpRB=puNGle`Igiek1Jg13{{ki5;uw%g=g;K$K@rUJHlX-`# z=#lvKhI7RW?XtM;uZQMRYlyjnlPj>M#$_1ZHaePM^YOq7FF{A+X67#ZufT%i_vP$b zW`2SC{RiJ>$>;lC_|VDEezc8WNvW)K+RXrhuGMKRs(FYIL@^N;XHD3B^S{lCpYr>cXC#SZ)bbOjTODMLb^Bm4L5s=thLMd5@Y%d zc`u{l3*sS-J*)C+)?|S|E?5E=hxf!oblPCiT2oSuYLDcsL8PA`+;IFM_w~A~reDRr z&!#M`s7;CoH6^(zpB#hl=pyf06axe0NkJ1jaAd4wXbN$p-yC;)Um9{ zr@mN4`sM^jd3Qj*CR}G9VGD?W5jnYCHP6if`wF*VIjg#Y{%LkTQ>+K^)|Bz^JSLRZ z)uKi{myRc+PLBjX^86cC`}P#glK5=b@gULg`qH74NX6g3iUoF(bFyfvoPxOh<*AbAH09M@dSl7zeKy zleS!aacz?&Us(nfh=zN{PF>`_YBOLXd90Zo87+^ZU@NeMsSFz38`~h4WUqS^t~08g zNQ`&xG6gvJ%U0q8y5j%3hf}!_x0U6L{q@O(DJM@!%^eG;BNRD1kf4 zUS}^@fAQSckSI#JMPFa6p_}Die}6{6;hYbUhI}y7sxyPA*8{17rndobp|QmG>Lk%p zDS6M$1;^jk0k(ot(Wg=rc?Z4eNQ=44pcbXra~SDmjfnB&IWKz?j9T#&DlDmp`-?wQ0gOYTb`!$?Sw^ zXim2#;&X|-hZgkws^;P)5t*_p>Q+0-=g0Bgy3QZ(=%YIL*hl@RoqPT)*F(BQqz6Ls zr#Ks*wU|Y}yf!~*-dtB4U*33^bmsF`@ZWXIul zDMZ;c_{zR^PdYvB2&}To_;fagP`7c$y$M!=PH2i`A>>%8Y%%_Khl zaD&nVjoB2^NhBXnOn6c}`k2Y53(id`F}crs)1(#%l*lDGal4Nu_fMG{=a3;yk%M+h zEnigJnj)daeL!&a2LHE@XGxJ3P~$J}$AHX#W8^qStxnp}hAG2n12Th_v}jx8R@HX0 znx%D1aO!qTK<5MNh}n;e?;af6Dqwa^xa+TCFXs}vKS!gQ8j`(* zFGFN2+Z&*rGAE+9$iZ_R{Mcm*5+jsl0h8C{#v0ONC{5rxcNV04Ppi>RlqIqZ_aOkm zGGtKAGYH!0AL|kC7ex)4fOfeOpw>PWz}GO9pno1>#gpQ0MHhK3Pvf~-e(tMCD ziCLW+^B`PNPz7?KuQKLo_H8qydduE+*eavuT+h`^gQ{2T+Bq+ z#=Qj|bCI$3l|hYTaf;7dk=%Y#*CXcS4D-FrmO?psfz@!+3tJNznoN*$m?n(Mt55gQ#_TUV!52oGLpdH}U zzgGnvsIL`9?w)=%cn2AaarN6Oy!#BinOe}zk%5^suOGdc21OH1#M;2GcpzQq7C>cS zzmulg7aF%T#y1D)$SN`cD0`xFW7FS0mEBxpn$mOg*y|xwQWXwORwBd{ZOa_H(AVOybCS>f$M@G=u1^8#VV`j= zu_Q&elvjljnJNjKH(4-1q`m=s%{Tw;O-#>Ww-Mp3SRbx<>kgMglKm$uwiOy%sA_r8 zr@GMPEa#dnv~ax0Yj1{KAT4u}O>}R*b*z@R_bbuLXnsYHbx~(tza39mQBmWnhRRfK zV>lzR!<~Lrt+M#${7+{}D-vF`R!w43;a_88<9B7PbIu^DWMK-Yt=2k~> z|Jd=kV1=9kJxkiEt;;xp2Why34zs=ch`1EPxf@n-B{nat^Hg>P0Nv=}wOD3i#o*ZN zv^M6jU$)bzc%jMhV+AX@e+_uFYuXxX4{`w`%$_Z=jE!{xxarg;mArv=-)eAwWQbAo zt-i!vq1Gq(U+H$9N&chf7oo(~I@N);RPVO4hT-VnZBK^fQ~3mP0BYO=!Q zmaoTZ4C9B^Vx*m126rV+uA;qKd4uBLkvsE+DAK|$+|4n=G3_9~u1Isxm~lkzpuvwoIEPr6-C ziMa6xIM7$Dkr29Oi!5C3)(VYZcD(7jt!`C9D}H)aFQ42F;VyY1{L9+pT84YgZ#M_7 z#FegPk92)`oA9M=d9FE+r)USLuBO4Q=Bka==1rSfzM??dWJI}*l0^p9qh(iqG}}Mu z6LcMvuqJVkbJbGGaeip7ZdnF32dyQNBPD31_4&aEXlUE(q@a2It60veZ^CTrhZ6!h z7$*%&(u&*$mTSU|8Iy+w(e|Ls!iw79^0GIwr**<~dSI{=g+Y zP(Xk&%lRElFmC6-B-6iG#VU}q(#Pe|ulKBebtPFSI7^$*$u5GnYZCp0az~^sY!-bA zPFuk-Y(CQzKO>GAau42!ut9%M-BQi^M}-!-*=d7N@GLeu|49=g z!sGllm+Fi%b2BH8*H@V)&stN_@+!z3d$}G$J}JZDMGw`-wHfV~xh8{a0BaPpxU`d; z5f=1rVwLN}z1@Lwg7+AXh>a4SY){YWV1u0pqQr+d$5iPDjSKW=gI(fR@>c=s{BBBD zFmy7d=k45JNgJ<4$Znc*->p7>QnrU?9&z;D7@T|)T%64@5qbezip^VD z^z4{a(l(mt38!d^ey5@rgIeN!iKN7M0B;#GtY&w#miDsgS8z{Q)U>Xauk<}xp#DtM z*)-6~Winh@;c-C>L)RbOdtq8HC9;pbAhV?8EoEuWeJ%RsVt{QpEXkxrP`mZWU1xtn zI>jrzSJKVp(OuG5?~oa>*CrEo>JS+^Yzq`kxLj+|x*8M_ciMFhF$H)-e=Cy`Jr~QH z=AcG3gdzoqWw%4)z$>|qew6Ez7G?%!OqQneD`#B)lyOD;iWUAO`=mV)-Ve8$^91Rh z+0G$TBrLeRofD(?%h~=;1oC)}j>PH>Q8O>eNmh|6(qd zpn*ZC?NGj}3!nzGrO+FgIQT2;WizK|a?QS2pSRm`vmLi>chX2_=I$59XucT3^cilx z9?b12%Pia?Et9Fs>9m_7_wB35X{O{bdiv>99=)3-59Y;Cp;=M4xSPi3Y%^N+7~hH4(bc31W7Y z7RJ9|I%o14S?veAD86i%EUwtps;9*SgSQuK zw91^aOfO;bZZAl6TNXZ{#)ycQP1;hZkM+v&YHN1flOIKDmR63QmakRK#Kj?Fauu%4 zD!XjFULQI?YTqSVrNK$u#={md*;f$+@PVI1zb~A98v?*8{GC{`YrhU*J5{MoLP}Ma zw)k4$B~(QArfK$>Z>+Xuxw%c^$jW-R+L@(1rntv;--KswSCq04vts38Oe*U{ZtN@^ z6KFc=wsDPkNVH44>c$*N4FTP9bmr`=@$*4(I)QKBJaotvcXspZ3WI?P>9HK3SS^#F z-=T0;pN~tcDFzs2K_h~+W%b-9dB*S!SKWWSZkjr~ZK_gWmfNI(cHAJ3==a6ypWp9v z;~eD_e;?`vKdw-;wrIy%oNHXTVg4o=eg>x0^Gqxue>szz!Iqyaw>lAkuZk!gJnCutLvRXo@pEx zOjoyM`x6`pe(*0U1!s{S5v8v>SpKY4Ql5MEqm88w zoqXMI8^0WbF#h_r+w_)7MfgjhL55{?=!LHmvwgl;fuC#^Gy`QZwe$`* z`%Z?^z4*ZHM`zPRNeYw22`+qbU6do15(&OAU0CZAulGYF$b2|7C^oW@{i}e12j}?) zIjh7*CxI<)*A`G0N4#MBKpC)WD3Mml}vWxHlTdoJ1fG>xyi zb?4ivbChE#bPJaqO+M9_q`4?gmPcRkbd&ccT+&RHpoos5cvoQje87GE!!r4+N9kR% zVR|oC=dVI@2%)K&VJs`pM@?V!XUDh8XdG^q%9IJ7h;Nx4-w6ybbdZ*n=#uoOeaBQv zdi&hpQTMpv3E**~7hiVo&6QYG+zyMpHvZ9L_BxRpD}C+PKn@Ot@}B!z%t*f~q$ZqR zVTIMQVoX(g_M@7468+hD&AizLS3Bj%*})p8s3Y+?nkQ%DU!tX*F}l@GH!~YC25xvZ zT7+FUq^EE#1s1ahv-{?iS4Xo3Z+CYus$zCm3$?^@Ctzk#lt7$(-K%cCxK)E}PwL*V z+oe7cAJ<;%6m^#6JG4I`;^p*>kY*cij^?OqD%vZFcli7n?ds0*B8XA|dWQ%NLZ0hO zcg@5n;FN8$W`Ms|CemlGS|T`2E=J{R+{%0d(4{!F7rG2x6?-;)-3lC4w^!8v zuFlad0S>fmTrMtFjLTU|8FD^~g8aDTN1Rp@9WJi)S@9yoECUD@=XAlNL#1s!o+ZE8 z-ff}pNph*iusAQ*Iux^*xNh5^vsiD=X6F0E#rMwuuI-^cjdN^kw|gVz;@2)>l)C1M zfJJb|ma}@@lVvc;4v-foVg$tdJ25nw>itvkMNSQ=T!oIGKW|l+SbA3O*@Y=24f_Fk zgZ1l&GPy=7k^S+t|0<+}b4@U*RgaCaZ^?n7gH{Y2;>{huH+>)567Z2)8*iwbGmMMIrp-E+&tIf97U() zE7y17cB+2w@KQ`i$|Jr_&75Jj%`J&x|2EIqV$2rISUgU0NyF~7mAJ@Zuf4L5@}5m! zT5RJ*_MGa2^K4{>NdE>%dl6@5V6{E#XD84d@>uIu#TrGsIlrqVlUmD6kgK6p68Dw! zi@s-PX(_P56;I*H3LMVfn|q{&k>Y>m1+fD5?98B}>!OxC|LjNCc<4$nTo2zUvF3CU9^Q_=*|O>c2OpOdm*YtijWr-(nxDpd&vzyQnwaDI7*G zLeG-VBA+U5%s2b7RAP39ebVjT@MMhg*ud=ti^4GUbIn(zopY(AT%yBX2>np*?@$3C zyqb1J&6j!gump#IQ+y>A;+WF4J8Zt(ZVNWEsvojv3&jD4;QacDXWCe`z-lz!(tucf zg(k}0laAk+4(G$NphVibHu!|TOF{OJC-QrGzs02L(XZODN`JH8k?U9pZ}pg2Al~vg z=SqFAs%9l$*?%l|(88QO0XUAvj21>?jp<2$y3!5zd83w(1V->0My$Y{&To@1cc4xMP_jfCUHEC`FPo+9yapZt$B}h zbryoKkIjZ}ePL~&*D+%#eE}WRoKN~{RgQU*ca0{uOTKKen{{yYeO^WD%ST55eR8BM z>FrWI>Old)tXAvWFgi8g`I^eEClpTYx#Jjjj{?$|&Ke%=L_T>LZQGA$cp~~&;|CRI z$sag*rix$ia?NeB6u91vFUi|W?8YnRA5SM2H&q&s{sLgwXEWE_niA`@2U<-Itobkw zZ^@rdrN?pZh2?^T^Kh@DC}q4POP}aIv$aKMBM60kNJzw>Y_tPO0}%C%td6F zEi)t)N_ga^(2pt!+NXCSAv*EQnKrK63F<0toy?_^=W)xq4`SM9eXPltRNOn8swGfo zysY|SqKiUjZsAge!iCa6kE~Bec|UG$SQj;Zez8lp3EZdq=6MURFH^fPZJ0;t><(MI zHST1t(kl5Y0j_E168rn{P~dsY18wdTn{Q#&GA7B;+LEL)v~DHoPgd0z8?xJF$J)Ih zVaz7A#`h&F(@863ShxAIqNNf!&HMQ;n6}-BHpf-BTW*Z4=h}wtogQCjEucRQ=Z@HL zAjotwRH1r!kLzsvL>rxywlKPf)8_7_?z1(GFYE3vhw+6;GUn5xiOraG@MuqMmqY#r^dvK2P#O>WUt&T$S>8o zY)iDP>h(fBmwVq@GrmYDy3H`gJt?fx>qS;ZqrS_+U63Iv5Nw@Kd31!=Z|&4+R~hoE zevF3!TPk4W>=rzZ3`Bf>(!2^6$aibxT)S0G&OcjJV^gW+_4Di+U;7dLok9_N=TvT@ zs9E}8ZJpi=P1}CPg30G9=wNgZ9peX%>07-fTTdNbQWhRKxa^q<5W^)$HtnZ(VX|#L z58ZG2EI58?$tQ$kcWzOH^3tF{A|)eI&m_`$VLJn@k7sNQo9#^6 zBjagyhPo{|qpR00zUcqZE(?ETduQQkk%P-F^udXJy9XEXgCT-xMZt!5TMz$sS7E@i zVvX{JjqyElyrl3fAllJun?6P%Ni%WwlL&d@Kk`B|nv$;fT#M1IVSa1x3ldD*%95av z=8Thv+npt#^6<)nv}6jy`u$X672ZOrz}qdGh;A40JS~2h2gjy7^<%IZv$_FN!Ur>^ zjg#&jVTH;4J2%&cj@*AU(?IEE_Vfgun%KGb63m<*bWdC(Jn_N%D}9Z3sP5IPzNlyI zC=!%VZa{drg7?Vr(+#H?RIym^1f)C-AhOXvPn{Hwr6=|-NhpMt_BBJB$+LB@#H|(= z`>iz(^Qw94_1TuJ8PCSSmYsp3_!fb*j&fHQ+v7N(M_Y+Kf|HdnJV2ViKzB`)#6_5i z@ukn(;BQyE*{HK0ncgAl9XKn|KkInG!g79 zRcMWxwqdC$k2o}Y!YC#)D3_f_vi^-$c$hy=Y9qGMyVFTJ?JdVJ__ssp>&;{ohPWqn z&G;p&3pwRVY}-@gk9A(%OZ8GE#8c>kCX+k5)eR1eH!Ya#v0E5)r`u~$+YE;@a)pz8 zo@s^`=ZTa@9LIsewMbS!!S3rF0!>_ZL-?@fKcesNXlRHWW>%ub<XFZHC$qEy!x4N*L`(4k6_f>o%utZ z`pyG^fTPdkh9AE_X8OSWHPFTimH)g6UUc=Gqo*Ya=)_^T`z&)L!d3UKss>wlO^(#=;#?X+MEuyer{i^!2*tYs%PB;qhke6BTE$3H~iukp|X6!9vL65kQDpe6QuQ>W`gQ` zHO=qXvF~!}4PAa$6h#$eM@;2d7hM*T>n-PjSkNeFLXY82$ z7osE^DH{4|uK^YfgX$|%ag^DHwvB;dayDv>_7V$|h}yj7th5~OsrLbruH=&Ixp)H2 zJ)n;3^jla-ojCSVo{xacb$5E_(_@9Co0oL7b1s=^2b|G0s7)%jZN?YIPvscU{>(4( z5Wg(wkt!z1El1U;BzR24)3n|#Dr-;gpe5gqf|I8JlP`&O& zOx)?P4P^@Hlh5GTsN}46cHBk#*+2T*g|Hz41(jy}h{gc|td~t#LEA}p8&{2m83^-N z6(pkayeUoZC<{HpQ(96ecp`#NX>Uo%a*Od%&NY>3-H0ayX`2lU>gOeaBTd}6YQJfM zPtx>?N5x&?R+W#;Ox0M)QK4#a-Ta#`$FDa&7G)5kSiBkZkG1eO6H4eD-D$KPUHLGd zisTSJkwRoIX@9QHG4jJl(FWeHm{uRRH%TN`gBC z5|`2F#*)jhQj8(q1XEE;igGZhg2eQra*%Yn1whSIw_dXd+DK`1oRwlaqQiNGWpuR! z|5gqQ!AvAo#Mva3=Z9|jvQU2G8Ibf2*I!d5NoT;eB5&HJ+BojiWPT=`q12D)hga7! zwlN4R7`fBxy89~YlOrZWSnW&DwS_6Ui`IfusOQ|f^{b_CJZ@t6P3kv{8#tLn-a+TV zVCuVvt?o9tHt83ahw7C6xc23hK*UlcC`LOdG>pYeFW$~1a%TMIDAVUV8?A9~LW8Hs zF8HlLf6~yyO8;n&I_@Xwo`m>K_m{a@ldGE|C$34P5y^C8y{6A_i&Ci%DYaNvtkB-P zc!B@E4T@QpMFJ}`dV1q+@K%W&-POcvIps@IMNoWlYa{g{fR(#!DzCe;%Kd$koInP4 zRIfy>zs1Qm=58JVBVKiQ#$^%8X?@d*L;#AT9^7gb^b=0ZKrUu7z&a# zuJ5$ZN=dqhe5muty!zqT?Whw+PYe4n1j=5l_m3-PB@j|1l*Us?ct3YVusub?!fkDC zdUPzkBhYEqQOd3L-j{He%^>#E7LR=tmu4)hE9>R%PR1_Uogl>~3R!#1l>L1RTa_Q` zdx^3%l%wzln2+O7u}gTTsPvshpD|=u(k+~X-u@|qGBvy(AZVFwJU{J_@@T$@43BUJ z`$oXYQkrIEhFM>%4*d4R;X?}Z`i{BTPw{CkPI){A4<^YP#iqgowMAZg{%2Z`k8%m+ zhz^U#HXUlDag9mZfz}PpEo8>GUXIAKS3nJ})a{Tn21k1(TXBy?U1CS~U?o;l_u<4P z1>1cV^88ZzNYFFN9I1)PJBM|`TY;MCL1?$K`xKs02)V;~eeHT_t{b?*b{XH6X^iVr z&VFkRIDM(3{Af^`O!O%6BO6&)VD(#1p7FUmAEQs5VHWxcEj1vcEnR0iDJoGx z7l&$9_}Yn=m$UgwmrmPj&6n8TO@47w&l0!zP4xeVy!o>GLv`D?dX2Pr=#sq`_I&)zhJ5%R z9?EOJSGn|Di2t5FWe->L^}i!twRiiXnJk?`RKH{r=l4S$D|M)=B8N#9C4DN@=Hsif zYP*+3a~bpvvwcK(J^m?Xpj{Nc6OQGonny4}DfmjdY@;`2hE2Tn*I{iC?rptO~QZfrT8sC!Zzf2k$2H`E~O?>|j?9!L$9kJnKljvXy^EX&zic^ zS((+zbEN2;QT6ISiDleDWmhhko_?FPcI`=jrQ+n_8Pk9be^=r8ywCO?FrT^~lzvyW zY|>Ko4^7_*lH-40Qfy@68$VR*(_|X;50a2NgvTr6m=lyU%-k_Wj)Y{7$a3 z&N_eHd+p`Dw=>`Gd_M2EuGeKU>r2IF!{9v8RV4SB`6Ay31D7F%jVE&xZYI`&i5j-p zsIx;4?~wsKg_HBPCLv5X1fmK_OCVo4E{llyx)b|Q&r2u6e&+cj(<%oxwoRUx+768? zqX)I=Z0>EBO0FnzkWy>wV~Nqc~DHE2VvPx|)Gy+0WgQikd@rn(>5RM>$A&-Fj&tb^rtjr`I4zOEA z>;^gCn(Y$MY*27x6V&UdARMX#Sx3iOqm*quD8=y}dU`arxM?yh zs-9pM4W`yy)wEXNRU4&nN8+_~a=S$ov5$w4G43(s=M?Wr@s%b7I3(N=YIq~F&v%tK z;)nb9vD@{2StCNr7G*m;J3-`k#qA8)UT8g=pNqfuJdOQ?h3Qaw8+WPwsvM)P$bVif z$@DG>azy$S2mOl$x)i) z!@HA=O(}A2C)_+pmAWKU7d#>mc>uljy)xG2(X~(flP%e;>zdH{@%^!FmgTmXDSnny zSId7LEZuJ+E9zhGSo9D)eX7qjV9MxP&ZEE9=2fW`mzNp$=luUNWc8_8M#5Nd4*+ap29s}9HGgvxyN<`>rt1!I?J_Y z*Buk~@bs?Nbb4{ewGUpDqxDQGNOSU8Fpj>&=`JTtc$9{z@X<-S#E16S?zVP~FxJQ{ z;F);b$xkB|j*A@9HG;GZ{OTKBuObFtcM^L8%n0c0%y%6vDL&DrH9 zc4B{j`ZzJkvG3LVuY+GV72V{>JTl=6_C!tmnDJl|KP-`6P_;<%dy z$Y$t;MKED&cDKksDC3HK{lKJoO>rbiZAIl$S-`1#(6c#dS2rSDrLDN zghG)|(xM`L>RFR)sbG=(7ltmw)aL_%_c?r;Dby=phc9-IS7xSJc|r2gKJwm-m$~rG zeWQE3E5eQ`&d;8w_43}tBvrg4#mX-)8(F;UpZU?pIX2HY=2o!sEU!Ps+~-aDpS5-@ z1>u?&pTF|(D_5hHATry&HPpldf)VbBUM25+L~Zk{iHZ8A(1nhoO^5tzh>^xCX)@Z6 zaaPXgH#TuJg8o!>F|-h^9(3<&il|bp%C`R4<;P2~GBQjMiIl~*L(6Apei?PUx82o; zJ?8fCHkc#$!JgJ-AM zRLXyUF`HolZ)i#39xZ8KrmR!d>U-p$(R3+>_2_(0_hYWZb)&b;u?VWnODiT?j0uai zGTRFwG-E}`FC^S4s~~8MbH)xG87iQ8hLv;!}8U8cGeVw z&40BN4A8jBvy$@E}yB3n%QIET7b&hJ4Pvpgy&n=Al06ELk=VkxGWtHzIBTn)0 zLf4~iPsQAhdSnhJh`ZY@p>^*o#wJ(SyweI|gGq$Ku0FL^m}9 zW$Jtbo`&tUB!C>DU0jOYVOiDhF!sh%Th_K#1}y1?k=^(*$io;R!x0ejYa4+YP~V{y zE8`@av{9m(T!Q8(P{x=!F8%UlKBlv`sGjC1gZG_uD3_LRQuu@B6e}{A0KeuN?I0O9 z-REwik{p!7kBxzge7A0SmK{wpBW(an^_OB;mkiq=G87U-=Dx<8y~qPm!1WVt*Z60| zMdpb9`W>U>E!mfY18d#p>d=NNc5=Q49)+!AEcdm?L`>h*{P3{?-N3v%ex%1c?>#XS zCYEz|)l6@gP*L^QsedSrFEx7gBHxsXfE)5E>ew3r{6#a<+Fv==DYO-Wb{^0(s0Frw zehK#kD-ez8ZP=62?9Q^c}<@+<>r@#UI7 zd!QRPU91`vnG7N`#~3WJQ7zFIC1{N0s4UD0T-m zygpBe-c4g4b|QAUm1evz9@8y`Bu`L0TSuVMrcW`Qw}YgYeW<$%g#ep$?WZ~)2$*T$ zbDo9I=`nRRhewsdc0S<_O3f*AkcN7%~jUv??1X0g{yrL zc|x4qpzm`TF*|PIgc9ctSnQ?~bS_xUG|5(BQ#ms_XB(Ng@kq*)&1aLRz=fbL?#KLs zCE0s+3xZy@)|a6Qzs|PDp-*ovtJF>NgDje-xwzQK_hpxk$UF`Sj_a4cZzC5off9PZ zz?P$-n1cNzI{-^tPR7VN6Ijrk%znt)4V$QodR0rxAb+7DMFiO5-Rg%&x}wC%Z<~^y z^0#m979Z#rP`@PUwlI1k`g3ajM(=)qw)_9%vqc2Fp&c+nlcn3{AW>f< z{SHCbk*dp701nugauEK4g~WA*J=qLfz`gN}g6Dyu7jq-JDFIi!9k2rE&!#=nZnK(A zH@;#+qsgLO%E0@ZePCGZx7xvY>1g7d(tLk4(5bI!9D`tE2OB5USbwvRwaK?8^~1Wk z+2nVI)~Gfy6KecQqpQf)09G(rIh?t=)+`wm49v$}JM0r}CJOTB={*Cb?Za-Gt3r_; z|HfQm9Y=gvpCEf9CcHFMpdN0DHTiA;^jjM>;hxoHGZLBmD+aI~RVx~6psbYgX3S%X zVv`d0)wb<9zBV3mW~m}RUs!+B+@QOeG?1fCdmqfFORygw5xqlbtH1)}!Cqck|ELe} z1Ml7g?DOp0snM(ipsJo>J=fRr* z46ozEELe1?E+e!3iB2@PE7A=Tqmxoyj81L;{M5yZ>#vCu;yF^mEO~pH^B7`y5(coA z>MzR+ummB)fP1K%jq&D9FzOTRJ|EfuW?7-7#hDgOL17Ma&ldQMHCIw3ZbnOvCGozO z{mI+O6il<*6t5kTo|YsQFKgjAXs@v{qElazt6||prYvN+6x{~s_2bj zX?}be;ltQ!Jw!DK;Y(P-6sJ)sJpiBE4f1txK|36Kuep?$7Z6V=HE*oKb~k{%CGInGI;OSARNRd)1P|F z7s-s;OWDo4IJYrZG>qFkOR8o7L*)>|HpkZWx92A_9sB53)9=6Wn_?bcQ6w6@H|+43 zEq+ZHxfSD<{@2&SPKvjw#z(cj1%}U;o6m58-`=ON|5hHfF$ZTwr$hwju59DJNE?1_ zH${twW>~uc07G9RTQ8RF#o@s|JOm07=gIoH#%#4)^cmhiVpC+*D-;D~P+&#inzcLY zG(k5Kw;l0n1m5I5pJ&oerb^hH#G*ANTZmNFQc5#=5B5Oa>$?viDoEv%$_sY>6h*2F zRH%{~s8;N4RxB+^GrCsAfJN$UL~W3uS8SOH=lT+y@CkjaqO=w-czdqY>+iq2=l1@; zJvh5L|KpuXz zfMJ~Z9{K77PFeq!R5+*?F|(LI1e)#}${(>%=&SMEe? zh&l!Nr?!85erXhI9iLSnt}0sl-h#Jy7H`jc_Q}mo$NPZD8ep;zZk9&JZ6(G@tIOM7 zmm6W9u;7X|;*jubV41S`3CV}(L2^$I+)j8W?H6PQC*|^!%ZmnlCwtg5sz5pJR9p57l+PG5++}m8;?R&YP`yWY2iSp2~GAXY&w8AztkKJh^hOWV@8N_Zn}tPeP!^~t7QcG~Hg_qb*K;Hd|m zR(Sy=3f*xg9)#dg5C-29H59QNXUT)(xmrx4&l?kX-(xDywUsAbQo<0{U5}!}ieim=6MN|S$ zm}w@B3`=h^viT_HI9(+*A!n$sgsZ`0+*tJf`&3$4<%ZNmE5(;*#jIs@t%!r+uWORi zvSq{5w!x{ghVCmJT+%g}tL2qOP1KEW$c67cJu5=@tt{IaQZ|pnwuXo3@0LLQNFaSk zrJrslJbS!Q+O#wnz9;Q4G~GospjSAzT2=w0G)_Z2Hg?@_Oc|9j$lLDT8g|mGobd`C zNjhfyo~!1CO>a~D}Iwox_Gqrp~DPKoWtDubIdB7R1X ztz7)@cT2LsNh*8%_pi8s8qbrP?lqM1qkuQtefd@~RMm3SRp~>GIc~uTIKOEZMiFEe zR~@tvcLkIpKcE%wa=WwwMId6n32Kwbiplev@mCe>4z*5w9?zN67GbCxLTm(hAS17* ze1p6QP9Me%aV$<_KCjpZ*2dfGTx=t9U;7E3k#W))c9XyHCm?w|_q_b^eP!GfO>^W= z#j*-QawhX!DF zh1eX^Xi&i^kVQ2NoNdMnREL(MknjA#wRN8F(g;XEbYFeEIC?ck?gBQkM*o3Dj}lUy zn80o=aNs84$eT7H)0DNg+cxs;9KV6nUJQP0NGID}PZ>g5T?8wkMF+>P@A>+3N-wQK zYAM$(TPH(|%CJcJl|B92KDo01BU!gGbP)Pn(6$DY!lI$bJA$URfQEWrMywnYEZQpx zTne2Y=SR(zwFaf8CDDt3Vbs5oaruaPXZq(WtENdpOhqE^VdDbo#ydP; zO`R3en(K7K0!av)BU4oP?s4M>I(tLH((7t2a)K^Q@kt70!RR zlW#R0W;2n0m#1@XUm2b4j5%}gR74S4E|~Q3p5&sUpjyf5x4y3QQUsSVUZ|Wu7?JW? z)3}5Wk%d;uhv&v{Dz55;BZ3Nu9D1>gQRhg|G(2adwY+N1qWstF0Mb`J->l()->rKv zp>|{C85izs?TojieMqLoo@8qq5#k}A_F{X=L&8r&xuPJaLI%kica~w{V?ZYdo-jLLrkj(>u%a zd|5wDLMcbzLU3S>(AQ9V5oZFk+p{cPy^n%3_sK`7)KjD!o+`4Ybfp{dA}F*}ZB^Ow2_S{+tWi zD!)BsS=aHj8br_YTr5YdUOzbQJk9i)5NPJ6Wj~W(0d32#v4->dPta&-r!hJGq0Fsz zS&_xKdw9c!xa1is#4AWTz4w3|D(!DAXn{VxaBB+qShE8p1Q51uWzGCfp}C71;hi6O zClZ7J{0qRq)w7upA<1GVVa+YkaI&yaO(lvFf7OHU`@aJqq@b}RZb}}!< z(O0w|6fL`z;j?A5sp2(3$#(pG3va*1v^j@ymfe~3zGPhob6FIRV)t3ECJWQcld+|D z{B07ibJ6|qIlJ9)1A`5eXD3tVZJb6?1=-KYRVgEcq-(WGXfn@iAgMk}6C{aa!W#%xQa+;GP9`Hc(hnhY3-> z1&swJ*p=VbsO+g}Yb=L~au-RVpM?VsZp8VNbYvT7iv8DU1n060K@RW4DY2aYoP(G^ zv;*NL`$O8=QQ%(do?~aYI1^jsJDGJR4N1N@s#p;WX9v^;de@__KOp-F45`k~fVU_Z$_XM`XrJ*{v2+MTskhgJyU+0%%ocI)Kv#IUhiVna>n7-DHPmU|#P?*!BZ(aaGONx? zk`q8Ys3iZtd+`q;!*o`VqDPFlKl_0fQ#ZIGyy_ zJ9u3o;W$$BK`M2#Lmt~#>(Mhs!kE0k$DBmaOPg1jE(_(IqPW)0RqzN7{oHAKal}wc zF!}@hO~>U`AcamhRZx{rEvT!;>WTX~j%3tFa@8{{F`oXr0iKUT?c=Rkxqrr#d>~?- z#GjB?KV@Ne-hF=BVE6O2tEx%oA#-h!{FFfQ=d(}@kGRIZfw~^FFD2q zKPqNS%1{PdN}uFyZ_^2EZ@YmS@h?x>bYd#v$SOd|c)ybrh37zpdt*K%YM73%l_nGoM=Z;cMJ33(qnQLnLHC zb61&anb004a?%0R?t)W=_=3aU$uLX4qH!;lBC>8KrN{RmQ8IXT5p=vthcf>4_zjwF zW*8C7PBkqW|EXtdv_+y4LXFhIjvCyc;_6FIaA^m0duz`OO+MK8ku~ohXJ~?iB2Z;u z03u%L887lt_2bUQ@TI^BrO^}Fn8QP7zd_7H3=Phv&2@f=b&wnCET);ea9YDKNwFw9 ztRtYtLH!(ZGD+|!>NBKsTrDyi#F56)(SKSjEE46WdjgQN4RHb`<5(A>hRC4Jg(8z$ zooAm6CfX1Xzr#%$k7i#jyXBurOG*_cF1qY8nuxWD&Zn%{)DY>n z6|sg^9>2=Fym!@~o$KMmXv9u`Pg$|eu0u?`@AKATXiX3t{$JHSlg-8w#B4PG z?437(*b+E@iurwN!O7Hu+vH}}ccScJAcCv!5{M7(P9nDW6~PARNz4pzkLO*4ZP(}e zw%4%`yz;dl`1saX!}~3Tl>Sf}I*iQ?&wfY-Gmw7#XewVSa*`CYUiO+@!JPghT2E|_0xVd88d2yrm9o(_{|UaNeb>-6!J{E~-|ek~q+IfW=)lrs%~E6bbYuY?;kTwUi44HG>o9va5}V3CeW2 z=G>DB0J6B!7x@M&^2vZfb8MY+X?*559#7-b>KevLuiSBD8Jo2Qst7lr$YzUdTZSa1 z&sHvG_XtJ)Sr|L&7%iWA)9d@oe3KY=c{9OjYb{rk|Jt8pp4)g(UVrYCaZ!-mk&*Pk z+nKy>#f|XkpG`z(ZflQ+RVdTt8h*^``nI(UvBMuP@vW~IuHL$Q^E^?mjQ(o!e4nvF zLg0vb;bld}Wb_J*EcbjOhr&5|e{5Qr@mipM+IB8t5 zlZo7TJPJ6kK*v^=ssxHV#MwWP#+4#Jvx<^8Vz11-e|A{GedPngG^ASD=KFT8_OR+| zecqLF7|K6V{vNtV70oJNps$HdIygnNsrL}COeSlPYi`_g?i6Ei9H>MX+PR8hre-j& zp~6Qs>2J5C_dW=Xqbib6taJ6N6b1IKZ<`mspT=i_8wd%O&rz({`t)nF8J)uACqyp$ z#H!-NR4#taH}o~`)|65o>?p6^%Urp*-%(7YX6EH*AB=EO3Us|oj&a9#bjpeHI!*VG zyo{ihY|tQ>eL=!?*#oE!KD+8Cz%Z@jxtbR*!<}y2s7QrZiPfIpzW+;R86$BIn&r5< zxgH7985367Yb6PSe;#H7*gsit-(JS4;I@51ftV`WU6Q1E)(kH$I-D55J5=mVAPDrB z6w03(BN7%R7Xzf;s7B4kwkB3_StSTcgQ1XEHhbxb)2h-h3YmC@Rzg0ML-72DN>5%mQA7SXv)&swOI?HuG@Z1cthFAa z&HeNP-PuUaQL9X!!Dkw-RJ+fUV|?cEn~@k@&1E=w3iXSX?* zPtq6u*xZrXN81X)zGF8iCSF14(M~vQgxsvp!*^L`=>`b@a$hVg-nzkS-+g_I_Oxc% zY>1P~Xp!XGk_DUgZ(-*{AU?6Cj2qWgS(jB?RE5OmMTnUjNtvN}=MtF(@0pAVYKJ3_z^z zXb^js*~4}vgHj_LLV#G(qeYU{9QmLwC`0-Fxb`wQ5aen5R+-~|XsHrL zq}2S03IinjEsMLb{nCMuvW@PR0dlB+fG%_@veJt*QrM ze+;Q-YhEVHS&q(aHy!)5_>`OO_4%&tVL4I%w9P0V?0vk)a{v8y`&7CNo|#bL%5zT@ zTtygg!!cY3A3nk_<+~#6ZGW(iz!^>dE(A~?-(tf02@A*ffi-lTnQ*~>CLmKRC{Ewt zBv(U`GX(}O_cN@umrUIU^ay4GHQARaGrcde1!7{?6WQrdF9}Wrd4Gh>c%W1O3;SW1 zxWN#QF<*tnrcx^?8NGLvzZix@9Q-JqE_c{W{H*f@{{K!q%>#Ht+~*Kg1iyjE9k>UM zJj1al%tM7NoRoKiE@F^2p|{lNvmddhapLQ|K2;8fp=x1XkEL;$8>%0LI%gNQM0k-`qNlO~ zh8e!sV_$MlJmp-X8me|$W<7sTGh6w_gc`Gw0IYf91?r)56fTkOieWRb(G60c1_KMf zY=C(cr1~H@PZSM5^tMl8zfcuu#K$yq4rXU(&9utwIqYg@&f|&2BC#gn7?){pp>dfK z$RQjhS{*^jCSQG@aK`3OFe_>kTb9kAAbTHKz#3WL$YN$*nD!?2l5#+ab4xNE-?i@& zCUmqiM3(-Gt*0>$a!AOk^j_+)>ia|ls$fvHG)|5dn<(ThUd?{sdv@*F4VrY6CUX^* zk%`|T;-kgb$Y15(uRs_S;8-9u1RBQkKiS&gV0L71ciV>Y1xIt_QrR3{k&7`#%f*%p zpZ{z}!yU^u(@6q&He!c$pnFC}1jxOWvUMj{7269o$D9r~@+b%%P^TN4 zqfVJz%kh2o`gBhwUzi?)eD|hdvaFhoPP8H8V>z#LvSDZ54-2VJu;vmO`^L8BG=>hf z7DRrNiskTEm;Vt=_NsW#L{(u_hq#FDb081ltE+Oe^%P=M(eRUMol!YJD>OHY`0ZYH z7wmW-DyF3Q@2?5V0hm68olH)7c6nSpbI12}&*l~OZXtECr$%#?=(7pW9ye3kr$15}af zw6CwkSHr$Hm5kDO*qsOV%4fLt!^Qh2KI-4keShWIxq%Et@v54Ogf|2$o)RU_n=x!o z*jy-?;pB?Vb3R2Y-VZt!AMdYFvc3@K2FUvhqDQ7c8 zp)d_9E?|b(*vula&Hg+FYcDjZ(JPy=d+1iSWl3{A#}6Hd`l7w~RMzc<^=frZ*u%|7 z`3F&R_0X0ZW83no&dBw`@10~h7x4}E)Rj-qrbv#YXm2IR|9R{G#9ln-YN?&vd8_Ld zoMDuw6}XcE1ASCy(|=F?M&Lj3=LS38zTTgBhpfY$g`nD0(S)S=(k@W>bW<%%>qkg$ zHXNPZ|G`zni;|_7agTKsyzxx3mu5tGSPK)4 zA;_!z&I#f(>@R-c;xl~exXAB=5r_9XP-i$k6zzZR(`5PQtrzc*Wc=tKf%pWII>3w< z4DEgGP;ytH<}55g!{Yj2=V7S5o2d|m9HGy-VTZg=R#Q50?nzaYMmI}DG(<4gIdkAu z==3WD$@wQ=qO$29p%wUe=?nGoZbC(NQS0x`A9X0QlYY_)99Z-8ILinSJv*vqSjjMi zSSfj;S^v2du&;3f63>%|4$GMdiL@1>syIv%zHxFlDyE|x4t;}2xpEm2M|2Q_zHNy1 zkEjU&hG|>;&(O?S*}gJ9%oo!H zqQdf->p3TM^EU93ZU+rT5ww(%I*_sJ;m`E0dBd29bUIXwn6F8S*8_Dk@LbQjjaMyC zmj8N~+heADDe@n|h@C_>d9S_eqGXcEKvp%r2{JPy)FmkF#)&s05!;;b(5C*$%G%zzg+$$Sjzn8n~0t2^U`6XV!|`Vmusdd zkFQCO5O=fq-!UM;x)S>?d-EHENDW0STFi}PmeMS6&kB}a2yjP`*dD-knH$p~?JeQ- zvP+rI-;~qNXwul0L+BqCz-=!8ixGIj&N^?%8^TBf*VTJtG{)g<)k6|<0!C1GAGAwo zG{c9-=-6duyU!h=t1QR2JDOp-mN3q-!`h1MO1!mzhm=F3v2rJ)$6iw#4xj~!kc|in zI@<*E=BC?wGautE4|~peXvUm6|04Y`%UVjzZ?c_)ej8@g^c_#^T*%29T^L7i_-qcS zS|bv0D*_BPzhVVy4Y1wa8rM4q6m}{k87|F#^l1;`|D#WfJ=?noY)qy4y9ib6zJ4-r z2>wxT_;cfcU5H&XUGCfc2Kf5{peZ0HNZ=M^+D(!<#1?s^SAYa2Ahf;t+Ew`(Ur->v z^n**U$!PLEkbPg46SGWZo$K8y6PiqA%4fsA){0i|Ja43zAARfdo%P$$SZ|4#(n)v8 zGT}G)bL`M>^&bVBK!{{Qr{T0!$x*e%rG#xra1-7mtiC-Uu&Lz?1zomGgHVmA%-tWc z$458_Aswt(7jlJGi=Bt@6C>(*6x}X7# zGx8(ICqC2xyESKsz$n!n;z7Heuq?^Q$<2+2UE4bNLY*fiY&CCr^+a~W60<*?7y-dY zarAG67lS{(noBjLf;6djB#M2~?)>w8g>nET1&@oJS(YYd^Gp{sfBDEOI}7l?ZPX}9 zWwrT8ELyQE@jwyt%y}4My7AyeD^eWGD{7~%xg#? z)dsQ{W!SA(L*!0VJ}3bh6FICNULa!>7JArK9ta{G8nhKoS3$!AEz?-UB z=><(!q0MZ{SRD47hiUH|@G)SN&AZLeKRl235eHfo3Xtms2olGCpiPyvL$ zh2$&P7g~YI-d|{w1t!RTuY~CF-d_EqDZ<`=pGmRziT)je!paZtp|2>2LGLVpYQd;U z{&S$**NdiRe=eExuaLt$S=0tYw+#_)Zg54KP5jog9l0G~MZy~_;{bYAYy_5<>MEe_ zx2M|P?zL_Dm;4HilNV}mILd^rne{_5;hM~R`8X^G-nYJN9WodgS*Fb4xK-UPzkUpS z!{~z+_rTA&PJ_k9c?n0bb6%PHuHXTJ3Ex9!>8!by#`d-|!6(A3YB-5+ze;Bf#*;5H zZ5X30sI&^7F zsXxp?sk5wd;2z~6eKkRB^^=Q5`2I5Ho!5L6B2-}nAwbTG%AL5Z^ z^5?6EMOn{dbxi}(r_*?Mnc^W`YkzH2z1a49&8(G)Y&6TIe?LY(5&373umIj*J7YXm z@{WE^S<=9&R5CF*3}0aO0eVh9BeCiVD74zLTcR)mWW+p>7`rED-s}$pLMV=C1v83; z(jGu1ulpcNCaeQrViZzjMnONMdNd*Y9UL^m7^kE>wq@)x;}DSl^fN)1NlBb*Gw137 zrNx7RclMT2TDsQO#}d#H*LL&H1y(6DtO^o;E$@ED*v_7{=6zNQ($SKrT`rvXZ<+dk z&ewqecv=NkEHZ3svXtYy@9!U6)mGf?xyq?%O-;1hj@y+urSb3YxH2@ri<|DD=l)g2 z!_RvolsxBKZ)W(+rn`SJ@;#Zdnw+@)VjstC#1v}dO>WO zv&co)=gB4&ZjAB&_hNw;qXorELV%5b+)o`pxM)Q9A#uloNh9 z!fSTsHmD-vBD1Ekr&ot4Dgts6F{t*~9d2WeCnFG&q_kUjv;Xu@rce4^H8cOu6l^E| zKUT0oe;uNMT$duQQD>3&`g{t|oaX7T9eM@WSmi!wNo4ljO!u_?b#MFEw`-56XA$0b zJa(XFn)(vo!4hF?FxLP5e`wc!HMWk7{itqoE$qK@(-%4x2xGn@CS(G_0u33 zIUrj+v#MNBznkr(7b8#{jpp{nL#0o!EjaHxSK^X08-#p5Br~dVPMzR|YxO>gu`n)LowtZXv z+BiXjCTzMQ_U!JAgR}VXpqoe=U7 z)JiD}q9Uh3`bJRyJ(L+y>SVE2cwq!vU$ot}$_kBkN?N34kSy6&$Ixqrls}74U`&*H zC)Yj6diwP6L>NWi3GGE|Z+Cex_no{ar^a{7aF_OYlgH0HGr@V-p?cLqu2qFm{|srqw`&)N{uMf*=zwY$2JWZ$%Z zYDATmG7iy%=qtG2K zTAA?QbDm0$-M~Gg@nV1qTSop&uh5Cjx#C)^lpdpaWSAHadVwXpy0x#2Ppk0+&%o^b z)Dv9>Sc_+aixzW(}f@4eNNO8*uW?WjWw_C8=g z)gG;wbc*GP_VSI4GzrC{(K3FSe0VQ$BG9x3b?Tcng>%EehSZHV5{`bQ6PjIgot@7A z2BH45D-0Fa>5`E4tFy92*Q-+;%V!4?O;(N_lj!e}8{kUiG9=u{rVI33E)(abB%OyT zYL|wfXTN>!jebXS=GmwTH)7nQfNYG<(e9kybwkM-up12cnkXv`y*ZaP0U5bb_FQ|h zGc3xUq6-2Xzr}0Mt<6e23=LZjlp%S`TxgfDk_WV4&#$(C;4jg&S&aoIQ4?rtq$nA$l&VbUuwfa3F~ zC&D)gy1T&VB_h0weAe~m2{7%xTfnLr%ax>n9c?e#wE?=9+u;IHos`(2+GKML5f1?ceLX~&BUz<|gEmQBKR%A(Jr2BLFQY+7!6k!Ux1l+9CXP~m%f1pM3; zO`FG{`9#WHStD|xdB@|OF*kclZ}RjnJn$7?v?-WILZ%I=Gi z-!go0_-VM^r%`Z*0=uvHe2jmSI0&X$kFHcw!HF!(3HBIYAtZn6SQlWAT+nIiR=!Jqv(X-m^`n_i`b8QA#C? zKs9r$L}tHw#5K~)B!R@8it%k3a1KA5Q#@EvNhHuHsk}2-AQsYkO3-rZ`ZLk}a_p$% zgm$A#`^~D1mf;i9jwZKK-|bDZwgt-|IuX_<@y$tm-~E=dO+ZSjz$tx_=VNgA1Lj7f z3J~7|=2Id+S(MG67}dL_*0g1BH@;X5D)}HC zD!GEzoXIP`);IX_8gEm2Ub>fnYY9XswbD=0h$}0kxK(6dC4I0tVBljw+MM@W%hryA z)v_`Ct!4A}{g0L{$v9;>*}Sf@d;pJ3fc+49rQ#oBwSLFGj9;vs6?>j~C(g*l`tsC< zsk25&1jaT^%T;e~YrYqYQG{@`_GEe&Rii{aJmvJZSL(8un@`%${4+8BJsXgcJ0SM;rtHXgxaR%ezZ zqQc-!90Wqsa$%-j@}n8QatqKUH%<#iB3_ib7#b2URI?H-AjBQfWfz|Gz_986SlgzY zmWYMI$4?(^0bN#2_om^4jT%;Yul#eF+zf+w5cY$1hpqROju2|n;Jg02T%@x#*hiF& z1d)`{dydx}{8{W2tedL^(?>96Tb$~v3ewvsdqbUfW#%+pCI$OE)FixLKrqYfFXKa^ z@w}I8iX}noJ!IE!Y82J@nt>5Qpur@W8aL#8KU^h4jEX{3YQ7xWDZz;FFjYMKXJ~(! zgaA+A<>1$tH_ILxINle8Bc`N)^)RL``f^4Yr98 zO^^#tH$X-ptRG{kTFjTGeM})eGC|9cX&?2fU<2GqccC~~>^*@g&G+Rr6{1w@EKBUk zS3$BnG*{y5H}?{WwRd$8&_ycm_)m&NAK&4NaS2wR7n_O28 z_#E=!8U7(F-|Ea5CSsqjSI+Ca`L|0CiEFl+eaI0d$%7_tk3^W|ufE(5yz%+kyqwwt zqzW6PeNvuPA{bG;yvVq|-jL6V-GsTAB4tWL6i8*4VaPUj*jt}B*qT!Qh=upxSxL7b zb`Dmx9noyyr*x}4Sv6dW zCPfA^svR{>O%uLi#e&2p;C$ZLXQ-rA)e;@fj2F$kD=`JDSj$Y0IGn&hR<S3ZY1!ve0-(raa+WnLz~RGG!UgQVe<>k;fFT$K3iV9BE-*RS#P ztY>Zs2#0#^44;0c!pHSn^yaWw^jUV4hb-ZVSHpi4Z!F#sI#njY2)=mjOCxN~$%!nzw0_Gqj{A_IMm2^^EK)FkmIy z3kx;*r{J#s z^rs&b%_iZ5+&7_}u&{aYD4ss!Mfe?KPw-4E43;J@bqo#7lb*{H?E8?Od6)6VU2WVa z=Gg2_yCBTN2dtz5Bw)$mD4PsfA4v7bOP$6REFDM3B0s zSN(Mbx`O((c;CxLSp3`LB8?tF*Y2lif7kf896482_+qyV_Vo|OELm(S8(!~1TO=MKY zeR!S5evs&f)}F$el2U#>7v#7kRIrFb>M>$>eplmLpCzlc3oG`u&uDqQ;3)ZffLPIq6|L)jNx|58;%jITRdI?;VZEQZ zv9$%dT_5{%FVE~ZM$(rW2IO~jed{7!f-a2TZ^flQEcbEZQxHo<+g}1M=37T>fZdm6 zm}W#288|gLjy-4%Ci(JaU0QJ1pK{Skj~NxB0|FA}WlFoYZy@l+MC&qZX{m8i`pC>hUm)czFAMn#X^s z-@N{Z`t4Z-jp$$MH>0#W-zsu-7lCF~nC;H%;P-N!J@Nt55V?3be$5B9A>@m>2WWY0 z12Ngi>SDI&)A@j>6KQc~qSU6oGqB{&Gqy>r$4KM=l=iIH2MIrGZd2kIHt75|%W9a*=Y=rkYk^A)7p^{EPKIdALA{?ohh7|xq$s*i zZ4l^c$gcRhTvxdT3b#XnjeR7hb5r@Dwo))6C*EK0NUAo=Bwo|F=61@-I9h)AaYs)vWaE)vrzno~-5_*9D(uh9@)NQinY$BdO1|Riwm$Xr7P-3@#g4 zF0ihQ3gK!n7x^xaH#Hr{Co-1Fv3tHflkmE(pJ}Ft)Ig$`MTLJ8j3)Ifo5FKtA)LCJ zl`85%3O`n>4mGGqGd~ALDK-9HNv5JGV~I@DqBz8-s5P z*%ky}<`zkhdrO?X3g!#$mt>LnI_ahin)fiC-%KIa%{K$x4AN)PA#xrn>cN!~r5yIQ9RUVA+XlY7ks%KZnnUK|mqkGDHjPx1C(rHIfOn#IwO-X-t(dhxrM zhV4v5n5#)bV;SFSu85ENBi?RyL;4u13q@kX2{)Bnz}d{D^3(CZv~JuqIwv`m{x`bb zJD$t-4Ij6+5E+m4wu!9D-jP+25RpBSjL6DfAwtQQsVM^fhD;so*)X!+7tD0%_5e#n<#SS58+Bm zh14(Hck?x7X7QrMaAlPF=AaAkI|0?L%PCzxeitZ&5qTT2a9X+I(>x=+nA20n-LE*O z(utzESEnhpNj7|(Ygj8d=U7{RYTM@7-jpgNsPoRdsr1L4D$yW;3twaQ@ZxhJZcO#M zdi(~)o{KkU*{5n(`_D|*JjNC5F%J^E?1wer<1m3xumMGGTMPXPwK5FGhdgX29-3_6 ze~i9-vT#LRe*mLF{OY1=lrW^bp`vD6Eb#LT!Zn9^Og<-gm!I2JbwwDI&V1_0Ef+e+ez?512hnKs!HWN}C)U`fd&<6hGJBCR)fqfSkD0IN zDuauY zH+T=R+z5IFm{`CasDC;4kviHu-K`fo#4@7H6EHcr_&wLQKFGQ2FYZ;fW+B|SuhEb=QK}opGTsS4WTOdMmJP3|JnSJN60w_tZ zZJ?!v&YG}NAapQ0#?{BEDm4fhy`!r)$(5mkTjG=3t4QNZ0_J$vw1Z`-P=dd#ZBvSS4lr%2B z{3_HX;WN*MFDLl=-iWTDRMO164IKzHZ0CvB-wzl@Lh4YL(=C-^j({d$XMlmNq=$NPqZ^F2BGt_Wu99%M(;B2fqHB=l9g0u9~Y|v}RBo3fHo`f%fG(+x3@ zi#H5w%XaP5m1uGv0q0q;WND&HmfwPKf%UM%AfUILdVYZ(@{q9 zaZDsVFu{^iG1X}Ene;@}VyGI>l#_1AhR!$^=mf48I8U?HKQvYN31~(tBC-WEh5MS- zatSE{f%CU@c+O+C-gNwO9`SJtb%g&z_>l=qg@FfOSW^}Bu1TtP96?1%s(VqBzR2}i z*hZ7_>z-JWnU%{V+Nn0^BS(H~=5C046!rv>gNw{=IU3GS`?rd`C+gL^pLQ=0Y0~1{ zlS4mf@~_ar?_r&6huPCwBM{pTEzwTPiz;T>gloFHgEikml?d?sPugw{IL3v2V~f)t zH#DvGi(MaDyMKX59+`4}i-t@w`s#V(QKZ|WTatwGYu4+VcL-Yhpxw(UcDkZ{f3ml$fi4b9cJl{*4&m;uK;nBB7>W}t_IT2nCO7? za>fg1wxrLPcRbNlk@KB0y`zyT=($Sl7vN`-K*|w~FVLPxjf~nG+9xQQa@NHlJW+(q zg(w)=2q}F~OE;BVaR7BlW(K(dL#x<4Pb<@eD5X4M0LVw;rluanw=#T3!_@^dXn>S2_mBV7%`JkkJ^A+f z51Tj3Z(IL=lQ(^Hbl8nswCX)kPp7W7ewGm=;?c>I*`@beW;(Ff$ET43Pc7_CP#Ziy z^;-DK2y`ap#=meCQCb%V+kos0zPo$P=NhLkoo}*+jvHQs|Ehyqvpn4raFJoXggs}^ zq;yHO7S;$gheTkXBp7dgSdx|lwqS^yL>dFqq0$6NTFq;W{gkc$jD`FU2QmhV=0n8p zZI@QXf;{er-CG{YsIEVJ_3-p!+6OT7)B7fZ+e~oM=sk+_=D@lYJ~q-6Y*CumlF}=E zr;lIyEojZL@7@>ltO665{LWc786BB;KyQ}s`ywt`Coz?Awc4fdv1_RYP`azo8wf{^ zI0T&&W!%HH2xQNAG1KZZt#66ApYLkxn25d)W&2+Pn2580e0T2B(~F?X4(A6pU`hpp^#O?B0(y#Xbuf4HHVotxLYK+u6W-8? z^wZI8bn8z18c1&WYp__Bo1g8z>al4%0DUStFmzTT+Hb-e?|0H z=y|4kYe5D=`d6J%>N3o-toB$kRz=`*#>7Hw8y{5ix3tZN`W7C7yAGYlTGFvBDxsC~ zDA`*Htb!(vn9XOn^}K`mFC@6s{=AILi$6kbDB8(90tQw;HK|?sD_jcaD3+(=tNnZf z5O1j3dDapB>n{-?)#Sh?-eKqtZunP7)tm7$>3Y!aOj+K&k|UbJ@LTUT_pQ{Cqabsm z$l2$X4rYQ{`Qa%0GE`d;5=Dv?-cv2}EMkTTmQTcUJ>eaA-M8 zW$2OrUAGJ_4=)cy2tV%RXBXd{2UC%#I6tJCk*L~zlD#4KF#w-@2rN)2yWq69QEg&7 znY=%$r81=3C1gGe@{}uFhvN6XkH(Q~e}qog)hRp|a*JbDhDqGBC+h7Le9+>Ei(Ex< ze|omjKV^7J!}`v;w^a?MZ6NYKEPY*DWzNwrQmPX9Jmde)UPwtqbjLfVIVyFW%~#KZ zKhN%oX{5d~KivA5|7M|2V>nv)Pt?>riOAdn8dm`GQ*Z0!cel&%7u2tTSN?Dus+-dt z3U@7ZFF!qZ7ev@&SHNn7xX{9AI%?t_fNb6{+MbegE4N~6z)xs?iT>b9;DS#WlewZz zhv8j4G`DB7wJK=Am=<*50L;F*QQ$D8VqKo}3e*BifW{B;-Yk>PI5qC0oENzc?n+he z;I#dr+SeecxQ&q9JdyzxEj^C@u44bct4WF(gLKEo#0almc8jCMl-}!zIB4@6Ib3r2 zLSi5>EiC&sOW2Z9Lk?lXSq%Cas$qn7B{ zsTL-H$F>%=UU0ttD6Hz#k_|Pd@8roH05lSzm#}x0{lZ#Hi!A;hXW#$%{K{ant+;q^ zyR-r!Yl*9eqvCV2AqcBn>tbuJ_n~z+O`FH7LTFC$xEEHDg2jmr|M`DEGJ~-YH|bEr zgBlvKdzp?Sp4(dKtq7>3+Qi8zW@o8oU7t%#>ntN3#HM7<$6xQEZo$UFH`|a&!9k$Snf8J_C2o|{cjV2Vk@K)}a zy!>tlS#*bzT;qvA!Qo`thHdTU>~l#p-ZP*!zSk>o01w0v zwI4wfCd~wi_m2OQwu9aE=b*;jUq$95uQML6GM+HQF~P;7kwt{RC-AUOGPo}Y%z(Ll zJ{_eEP@;2)uj%)LHt!?H89zc^d!z=$-B*)XmB0G*(q%T+mxbkGPtb2NkS-^#{|RzG z8MZe@KD;Es-8Vj-9!#Li9yvbRt`&P_y?61YL{xK>;ER?&MOcaff23j@ZqgL*563uh zkgW7xJGp;fFG6DUz8U&)sTM#eo9A59 zt*oWEFr8|gd>KY-WX7ZJC|qH<%E~Ft_fQ$D>0O{JQ)&vd2H{TqErR%QWAFh#k~y3| zRzB8e=8JCE9dUeSQBivDYI_iWQtpdDe%;ZB<|}*hzqAuS-I-jon-6D97CgYZmv=ZQ zwItRa4C1J;{81iAyUCNTO?^}e;yCDi0HFbAI%>_LEot#p+;iyn513xp7od1|b!}Gf zo!(sJ89Z!@_QBAS3ioZwsi*_1;v~XAzuO%}Q5$c88FtzJd z^h@fMT;I0Pb^*l}_8MUmAvZdr*;+TnF1I|AKDYd)czEs=$$)P+M&XsNO{C#3l40Wj z8X4B!P{zBdias!Z2e*J>Zqo>^tkGCapvo+xHe3~w`Z}lDF_kcqtRJL#4KyW4d6p$J z?$$*xGIA$JpOWX~ZzQrjIOAVzoPza474b_SIoc|o^*>koJ>LKShzzHB&?D4GUHSG~ zU&a~S7<;Nq502}a8W@Jhd%e$*8zc*{D(cupT-O@sbgBOJV<%Sr$B!NS_6&*NOO(A% z!WfzDdGqW?{PI3pPks(4N%LyUcX812hqoRSQzThq;AZf)G`4yeo5KQSJ)?+$NQzM9(uNB;Rc zLnR%n(VKS*#FJj4#~dS0N%U=Of$NZF)HiX2M2-~pOqWCVu*2zffL0Ph-&GQ@rlwTZ zJ*#;6Pqa(Hx~+==Mi^_~^B1FK1o1~dz4G8ZoK^GAk~+!3?faVRulptiYfcu!jh&+F z(@uUw%wy#Cee7s!&6J8NzR(Kp#A54ii0xAE};#@BiVK5B_ggeD!YRvspnwk6vIk zG5bRQ(a7$oKZ#~P_!8Iy$8|0Cz7FTVOJ<`2we$d;a8X$S^1B6Vtv790DJE@|`kDS* zr#~(ZR55(uf6tS8@)lUKI__;)#aKY&RIB%4uXkXECF{R``%nq~_8yJ(*0~C-9~%7W z4OU?KjQ{rV|M}hDGsC0ZHc#)nqJnbAPxRdCZ&hUUoJ@3V6>SB`I}v=&%nb2W)BjnZ zOi_3b>W&xcaD<^Hhw~O%>db2u@QXY5bb;`nFM`GvX$K#TTwXO_=Je&nPlUNCHfT)apYB4LNQV5l(Lds*W~ud(H_h zz*D$AxoiV6Vmk3$-C^k48$t#vN!}d~I6V*Bz=ecPWYl@S=S)Eh$mqmldF}WZpK%EX6nPOnaRee zZ-8fOU3TYYqw4u&E&eB82e8ivv3v@~CnuM9Yj+6|pH^&*fUT#8<#aLM-w!uO0U31H zwmA9-zG;N_LO^+Z&us0vJAxoo0e`mMx0P3!3)6ks)4T29 z9h&3VHIU#t@|KKZSi;`Jc1w1fra|hBxgnRzb$UziR={3G1pgDB>gqGUvna+9n2U$_ zNK}X!RC!f=h3-P>x2ewHX8a!#v%+W6J|Yg>&j)QkeEBiCMF0Nm%PWweK1Ys*-N65j z@J{_u>OUtK!lp6?>}WS+eqf=4-VErS0uFORDHTJ&f0)^6x#qYW$58J zsN7$VBYLAWkwP9i_s=-n5Sc<^dSazpOQC}@Tj=AWZ$hPITM{-Um645Xr^l?Sp@ueX z61V|UNk`lnL*_A^K6;|cdl!-SB8|`rpc45u=RDh4+s18fgtXL@(F)zMC!rUctOQZ# z5-82}m)RFg$~W)zDefYWR~88`4YbiN30ZZ1rU$^`gGns`6)zq8rTEeNSRrZU7P=BA z>O{>i^#6l)hoRr#Go^mSrp(*G8G6m&@+3k(C;d#{84J}(cP|fxZm?p z#FH3tL`C-C;*!Dq==BEDJ1y1olr@P@tOL)fm1FJ0#y-WVLB36bR+fJ3&Yqa(^ zC9I`O{6z^r<(G-W{cL)EEdSx4T#DxEsOBNz9S|^bh9R;bC~Y4YXM|qKVBt;WT{%CW(@>4b;F? z@r+ZTqq}ZbHc$oW4Rmt8=a};V4?epH+gh|(a+IYG(GEDiYSBi}iH;Z3KJ?O|B{jjC zd)wxw7216;PGh66y2B6MR5dUZK{h3i5|8ui zrJdy}mE2TJFtXKgVALe2HdTFza^cLIbD{CgtIGgrSQF6;@Vc|<`EuT40D@Vb5rDAH z7FxVc?DN;=27y#0Fe4}iBYv+K`<-L84|?jZjZ+%WM(-Ux%6gb9`vj-pUAG%3mi(3w zHXlVFj8-=P0BF>m+4?Y=Ymt;wraZC?Fw8Noy%BFm9dnzo^DT6iQ$-4oH|VW7=!qzD zku>@LCAafEMj*#yMt4h0n@?`b$M|H-a@gI4I$RuSS*N2_qV-=sRDWbYrO*3v!=g6L z;J?#kHbd>K3JxLi!KBU2mmN6$*qK&O$~J61A+1-nC1v~Wkm*1Frg1%ad41VV41lN# z%PqKl7b>dSZq&CVxfyu1E$_AzStczXBzf=o>9u=j_GxAZsBo2QG%HhFKuKmG7 zTQ59^OP?{ezGJrT!GHym{t1boHfPz70Pmab;kXIx@*z?%fpu_8xl-^Nl!l6vH9#-?y$NLB2DUbUDAB?K)7qa-Pzmw>-?4igibK z91j|QJ()0k%4~aQZSQjbPDT#%uu%f}n^K$%Mp;?ti8tL-tXUkqK=3eS6y^g9G@rlI z*ZwrG4$F)Am_<7FQe+np+`WRX?ZE+g2SD{+N18I)q>szRT$U0kwDOw-a{Nte3kreE^ek!6Ip6R8Iui`1L=GA};6dZi3ym*Jo;Gg{t$fJbmzGm|tbVSL=g zGs+8~cH&O7B<{L3;4y(;N)e5O-s zpyeisSQk(HXXUt&l{=N2!_TNohGWqZpSr9HSz^n+h7>N#|DFR@S%y+jMi$+BzuC^) zcA|iEo3)CraHUxwhAIFSFGqNf>0D&v6x^gYT0&CLW>9qYg|tp8NDGiPL$QO-5gNYU zj9a+?U*nmqYEVCISY3)1Zx)ljkmwUcf=qJ#iidsPx<@nkl23s0{a4R-78KQe8VH}T zt0gVmV4UMItSmoY1m@1N@=`R8@>lE&aqG@+&ijb`zb*p){s2=?~VX!o$3^<&ecx^f>Wq6x90Rtk#nSuK4ql)UILT(X! zK|t0v488jgF46PT%$(JYP^#X4jO2H2vdK(Z{4)&#{1hnlY3xm`=Y7An<0}* zl~tsfQNmSS*bNMvG99Zf?YAo^3@AR<)<5T3VEuye?9ahC8i+9xm)e1qq+$@2|?0l zzC(K^quyAr>FuQbFoxVrPgbU+$c#POh4{&Ri9*$Z;KYI-#$6?MMYS>Nen|bKrKgM|Y%K?s~Un>yUte{Yv7kZg;2}yCI*< zw%y6f%WD^du@JkNoaC_8*@MYRXH(#o%L1>{xy9mTVuiOBo%Bl`YLBim zb^26C^b_vn3i9^z-Z|gVwu%myk|o`R(hTE$TvTa=ZNt{CUA_8P zuP4(K;vRq=P|8v~rkc>!&`7JLbHFe`|IjD1$8i+EXUeuwdwGM&$-a5n?w@TgjRYWr zgO!@{$=XN05ZveWbR@WCu;hy+BrZDtT5}`@i6Svb)Ur#EzCEA%s*B@kejpGwI zFAviTs38nXa3+RG2)?O2SEfNlS*_ge+Ek3^8e>!!9L%eT6AYMzFGB`X(9~b0M5<*3 z;3U~*A0Z#G-4AaV@p0_yupbRp1@+Z_D6&8NfUGVp&gjZ*>Td46;B@22MPA3#^-hDCLN)&2XYz;O_v^%;|tqHn&&yI`wrXxsZ{r{xCC?=35XGenb;QvHo@GSG_& z^N1!Aw@saLa%yT-O6Zee{Mh-?K{Hbf+yXkBBq*cG4q8 z)vF)I%?Hq~2o}CLKIn85`8$Z}6%0St@)nsB4pErl;`Pt}w>B~sXGzu6ed4rW7#XMZ?uKf%LA|(=t`%mH zvF@x+V+2218kRCCn-Z;YAE@W9K^umqafl z%pLCLTAyh8DWB=r-G7tlGdV?rPBUxv+3|wJh+<+5%Ex%DUy`K_jpb;(6%-U4bS@_d zvW?lb!-aTbH=kTc_9O74EDP&vkOfcdO7=SfKG5?e=&HI8Tf<=n^i%GweFaCIm(T18 z2yAzPE_@*-mmD3z%t)y&fvGBC&uq&Yy^UiVlt~c(v-VMIVcwC)?$0jUM5JCEnbeYg@R?7olXP(Xqb1$e(pTTuc{cwz zl;r^8Ym-~VdwtT!ko7)lHas$k?trYRG<{mg3gVxg`NQ zxCdOM9Y=D~#`EBJ{i005qJ`R~ic5|^$@^$Gb3Ok=_43MHW#tfK-YBxiU*ZHm@-!Z7 z_|~GaP^{cv*?-Ott;*c@h-&Kljv;?YZHnWwTb(Mlo#u%6nb`d=?Omld3cy$+iy%p2 zVU(r*4z`V(1?qs-x*0ZGTK@IP22z}Zi=0Swt?9fTOs%e?leyC43i+!^crm~+BLx}M z22M*u{qJo9W);isZ)VNA?b?WgjO00qs&EP~YZV#6T+f^A+r4k;i|MWS8n&P-rFYA? z-&bc-zrZ$D1nvRk62qk(++fW&Gqg<$awVzN z&*Wma14Q$4S1gXf?ji#e2`>?0O&o_z0G_4z8qH%$7&et1PA8fc*IO;ok4#wt2EioO z3V`%2^ds5N1h1PbC7tG?ThDsz*!QkynjY+|-UjyRHsF1?A+%?~?3UBo0T_k0!~C7N zjYwo(t7LK6p#S?Uq0uPuLEf3(J2Ls~sP#O~(Ujp)?fpC$T1D84>ry&Rz7;p}SA6fI zSz+PSd3Wn^jal(oV?Qs50dK30<<%oE^}AMzyKm(PVQ!b^uW4mzDuWrB?#$VdJJ&5X zZdEL6sjI(KIpws_Cy@Oio>Q2G_VXRSSbBqq5BLNv#cSQ*k4904ziHIT@EQ_kGUwpx z8o{1?e`QBL=N&RYa&;3*T+UIg!mv2Qu-mlbPhhmh#YsmmnW`_D!&l8s@d>ow>c7rw z5!nmLm;3MBEp>Uf9dZ-g;s7ciCR-T?UN@tjM!vIqC^razO2aOb;gx@7)JRP)&3NOCo#RSu-7h-Ttz>@Ad$&2C?Lv*Z}N->tNW0yZZ+QFaq;2bd_q7#!0dJ0 zkB#lsT(tEUq2$!BaAUyjG)5wx=h zpzTCe0{9|q`(bmw*M;~v;w2fY8`%Ze1s<^aWw*ns3Xk2~+-?l{5P_XRmguCk)Fwl`nE&i_WK)>8LE>sIjZ=O?1gEqHVSlD{6ZZgIYnr(n7OC=k zTSWRs3PQy~YQ07kRbN1XF)UGhJRO6-YSuI`|IrKZ=Z%2;gZ2e57L$iM7%m*KLC7=B zrdGK*!GOh=O-081JK^4KJC2xrXIb=tnq+w&C00%!`jvXXv%4XtcSBaz1%7Y$&S9?h zLN7S^z>=c+%2*JiO84CCt7L5m$y%iG!3~(IS5njn9{BE zaFb{Fkb-tZW|%4?A^Q znE1QG`T9i$Mu%*E5;<5eOg`ipXEG|YF?OF!{wuj#B7)_*6wl8zZ6|igfF&k6T7L4Q z8J~ur`JyR~0Qy{PK*;TVw|y_ja-4)N2~B+Q6t$$H7!{FQXfD;!D=!TfUg$80Ijwba zIzlTVZi1Q9N94lVi2HIy8DGJqFI}-6_w~0qaml13p9f4rFx*9pJ*EBphAZ6bZ>y-S zU62>_I@rk+f&_-TFmW&h8aEZXjN#8GUD)$2xN?JXL*`~IB80F`Wkx8W>!mE4d1S*M6w!r-(I1KY42S5;T@eHCmSTxRX z`Xs|}sucb)zNpPurlRMt>JUKL?U6H3$}liEiyPweo)>v+|;$N7iy%h zNm49wwQ9F&%wSCMR6#=P=n85jm zXO7q$kZp~q`hBsTTC691dkllx)REzda;#|krJBodBbu78Bt*%00CzRxWw(U}Pm z#_0@C#={Oi(GHBpH+GM&fI)SG{o^JG?dKak$WF-cqc%<5L8M@#mSfJp;P!0`o_)a$ zMhs*Q`bawH>ja=(2p27e@7_Db$(fRZVrRW_tK1_a1=Z)RY2eW!u_5r+hKCoRM2y^v zbrF+~y;vc$&(te^>%|}BjR<-&Hu{O`KOMWa|6K~8kQZPiM_DzWo^yxkzZgWw61*-L z^6ZkXJbPX!e&X0VTy1aoQ+b^miU6`eu4sa&iLEN2|E@d>!C!(7GA=yBmtliN5F^R# zhF_4JzugtASNDb?xBdwk1xn5*9emFf`X4BJDX(pLNw@=gg`@}B4}7ZMw8At>t*6>6 zFDGGqO_Wsl-CNyRF;4oe%|&v71ow3bW;DnRu&|kLPy>{rC7l$4O8o|f(2e?+6`;NR zzP=OWhe1G)hDN6Tq`!`wVw8}uiSFPVn7maE)DE1{pq$G#yJMQrc`U0Ak)#_M?yYn9 zEp{Bh(%Pg(fKVgWRBz8zmGNu+?_(n)guqm#try?+ziJr+b=ANe7@mFbQlgqqWvM^w zSQlkloBu1`M$#kiZZv2J4wTc5=cO%E4QKGa?MWABAG$l#`T&pMAhwpS3Fy}iJH>-S znAYC?!NqQ##4gFygnDyuFtix4?Yqg?RNKrk1Ej?5_k7}fl{;y#3N(U}&tQ=&>7-R# zi(cwdmHQkBIsRNhyrq88orLp34HF9LC<#=V3^Oh1BMkhbdl$p2B@!-;nuaZO&{q>T zp=9|r)YXmN2YMg|5Xb{jJ zP#7u}*s5TDM<0re{7!9ai*jVjum&{ZUW5ty@o33#zZ!YMLcOKr~TM2 z7cKWPTv?wf0{2X(9K{*ZbM!o4I_1E5%F4{-WX3vCSuM3YNgnuK2c-Xr`~i;`2kXM= zv#Unm>X)XiaDZ>775*V@dJZFPLfpve?^lV$_8;Jstj=gGPc$2*>tng3vj$!n`sUP2cAAb3-Sb$4?f z9NnEdH1P<)gn-rJ`x^j`BMZFt=~$1!Eth$ZdLEf5l~yU?_s*J+n?$}Gk6>Xck1-w6 zTdyrI;;+{?PW_IQk*Wy%HS8GTvUPr_e8gk@%N)2D@AVwIRPEn<{q0qhzrADi>e$Y2 z2*Mo)fo&eC0a&03xVmO2_{`AhB8Y>nMD%&keU%0w2tE=b-qYjq((dUAeWdaR!yKb&NzvDJAn6itcg z`T@~z^cF9;CZxU_Fs?9*|0^ZRr%}47F5_Ld#o-zCzOr#3eDz|B=KJWazVi$T>jH@+#gtv<^E`uQkgL9cCX)2lWa->b zeK1F|KU+|_mqwm~6i$Y>fZeP&Uwi#u*C44j5^0_pn@2fM2|WXn?CbV|&Wl){Ng+Zy z?{Mk=Z35p7q_W)eywZBMbB4z1oLycgigLw4b{}rTMdIRnn{!%ITRpIeR@zCdJ4;@| zK&Sag!TdWmQ2+2gaFQc^QX7$iQqt}F3R9)DG&D@!M{r`~FAzDr*z3TMR4=c($GpCO+c5V(<%_+HQf9B)x}Cwy!yeMrhIlIB+LYO8a=j{+q=*I zc_PwKBoDjDBjlQRC%_k7H-oJ0LX8oL&8U;???;)$KuDx@{ZR>QPgYJYdz04T@4Kfc z!sx|?YOdcbyLVNPDO~vb`r2B~I@C!(6K&8QZ{^pd7pFrpr8C9amU;EXhEuG(nv#l_z&T;L;%SI>?i!{8x-QHbwHI;Neq@~UN!D3{QZ~pT%Uz1 z4U6r|iMA|SIY{jR$S&Qg08(T+ryCCG8wqDw#H=-EVr%vO#3SLH0tgF*Ycet@xj=k! zcAfePJOaPy_k%)k<1`B`pvwFXJx*^yW0=`{vU_h7g+wBP#w^IX>72XDhGYclHWC7Q4)ke9} ztax{KSNoWdkT5E%3Q+Jlz%8{U^POR6OKjc|D$NIF9<|BXyt@B)byivnFS+#maCxQZ za6(HpT(_HxqD2WqBm=GUk-tM0o;b3TI`Yo`cXA(3MG1$Q#f}sX1wxk=M%32U?p@pk zf>WCTPI;PW54Bc~PRG+@q@;*h278Zp;ig>JyZa!rdo$4oNcAhNi_l}PJ*PCY1H&BGL}?)Yc!0b418^nLeJ0G0{2_Ec!J|6dTzEDi)y5&*SjDGZgafFn6gEgOBKog}k z)fDqaP{S^=Km)hP_0vd_Q8q#V<#+j~gGTT*Ec}O}uaGzg9+`66T&VWN>Uf}6dfmWH zA}^v($qLpbOJ6NF%B&Hgm|2kVA#e8G_RhL_cm9nm{)xT< zZozJT!d!_mml}K+WzlWDpqKL{;6s{lX0;%QZ(<3Dvxs8j0`k!cy`PukWOciI%UEkq z(uwdLK*m4E42MCvuQAjKX)$iJOY>PoQ!r`=t9T|#zQda$|$0(;{THF z&vA+7pm>pTttc1P8?f4&J)#Rcx@$<^OyxdT2Qe(vG&#eBi}>$-1*x)66cSwnqVT=g z$rEbO(sr4~L@#CZT@rWm{3||HBRBpzauH(RM_6oF{*n2@{;OEnpf>3c{$Oxa3Wzb{ zqP>M#vtU^1(XT4-dK{NYj+IncKF6j|=m~1GSQnxHH|F$;*CUOCbweyNOj=@t0nfmJhpfE!af+UR9Bw(gdDW1j^7?+LbLP^3yFj}!k(mCEH!=^mrca86x z2NyUx4YBwOru>MM05g=}+C~1P6eEC;inz>Q-rx96My7?vAz=K7{{RZK;=PFWeQ1Bk zZ<5n*hYH+jwv%n1+L>SZQJ%L!9Z3iA(8*XrB~7XR0-YP9z$%yNZa4yyi9e`frdqzf zGKh?cV#14*x{&7^Ok%4lfj9{h$YENF!R#tZl0KGGGU})rk}#UOYE?NY_d&Sa*U{Tn z_y5sKpcs(g6yfTzLbuz1h4Z5gZsfs4(jnOEp6;F@N*E;>Xqb=v6U>?b^g^G$$={0z zBD-IzQgI8uixcvX-qes@PY*vlIPj3Hqqf|&2Ep2^kpbBzi$3a%)-jr%yK1OBwbk8V z4$j~y@$%QhWlq*HErWYHOK4*|Z0Edlglg{59loo2o_u1EG|&h}gWiTRY!2*$w09!7 z4L*nfdWoPkVgS?gk6$P+bLBlcf8n@Y`mfdE6o;6`DLxYAzL!Ll9`0Mu;C?BT02z>I zTRIh6vc13IK6h}%uru!0?-WG&0wa##J>}Ozs4OcSAbqPKZV5%YJ;hYc8yM7r!TwAa zv}?`uQ+5f19HFAi32LzJS4ay>)+gKRWn0sdlQnO8rp1$pA~NpZ}XMizw3ofz9) zIKaS5eL?OQ7b3*L!rAcItJA_u?N|E#lTP$)f!xZkh4F$x5ZwjAm17#P8jbcEc3YcN z-h5=|!NQ#^dKXmBf0BS%BZTa2wislQV0l_}{h42MjF8bY$Nt;<>DzDxpB%WBt$oG` z#?reBR75oNKq7ou$KZ}~FJ*HY6(!|d@J#U2Gx*F8VXnX|-VE?cN(tW}v|S^eV^$H9 z#~QbjAHLExgEA-YrmtB)kRupNVGTIPBXmu@dY*%ar}IRC((n8T9wagtIp|8v7hRLW z%uZrnctF(Ab{$;ZvR6_>qVBwUQ{MB}$>4{Q4<*#}xd>{c(@iEPZ+1dQ)2W)3iQLRg zr4!j8cK>`pA8dcH#a1VLr!VD&PpFOYAdL3aP&CXFqcWX=Y(-$7?wuM!AilXzMj&+<2IFC*1n1?dTz4j+1kAZioXMrj1`hM^`Aadq{G*Lni~g)_`h^U z*YQVLu$jzS*3%2ts0OFr|3RTeXz&VC&^j_BfhnR~6>np>jbv_QGYf~Gp5Q3yup5K+ zQ((QnIl9}+z#!@57|xv}P-yv~FjSqXC@45LuAN+3RBdkkku<1gOLOJK88UF)vv`e8 zr%lVnIl4)%Eo4R2&-yn+ZjWF*3HE{?+sv40slS8R%d2P)w8u9gOz_PlT{izjT|jcc z`wQk#cP837MWLB%aC38c#E{7ZO>RAcT7Y@Ujz57_@g8QCIp}ILK}5E&w|~NT?{VHe zUs`EMmpW!v+aQkITrY`n6xRlJUkm!gWSmO6t)yP!+dmQ#<%0y%tKk%p`i z!8q~+P|E3RIMrHb!*w>GeNYJ9)A5_1>Xm|rMsw7#D8>Anr41BL{Y$!pq5R|84q z>J>jGg$QXNd!4-W<(J7nK@Wvl+K6O&qD$q&qDw$vfIDH1;wv3J;p=-}yw?8vm3GMB z`0)dMfs!sFJv9nB#Qg$#6AWb#_C@Rwv;QEr?&Nqqq8HcB3gt2r@jfbV^%ve4fg~7; zwX`@25r}P11Dpiqrw#M|)ZuJtK#0xT z6L(n}3fROY!^YyGO&_s3-Tds!IZ-jD^n_cu*x2P>f{*nEF8!%{Ag(?`^i9tuTIZin zB!vN+UaJ|El+Y_w**G(1?ZjD_78 z{k|9TG1^@01`y_o?@ZeUp?R_~qj*bro2)}d9s{2Jk#0~|kU0*(mYMB8IiffRuOg5* zPnpcZV5j=67Jb-0Bm@bRmfG=0Z|$*42zeQc+ws1&Eb$Sqll*w{Ck zt9cR1pwrV?P&@1uSpmtT?KZS+ijOUCNG)_HzNUZ}GQZv#E>66S3i8anW!W>TsD9_U z`lo(=UHj3Aov;4dAqYKn522^-9jF-0UKb=azyY|^R8oJjFP|lO;;QEVG!j341s7qa zU=~F1Y!yP%jNJT5()jtAHI2JCdwF?%7R3EQ(n$B%-A#~p(YtL7BX)c28l(dirzovjtHaOloWapXB>D-rX|ZGzabMTXUu?nTJ5wSVVGS$~LL& zGYvo3&fxfb#SvSOYVl=?Pp=xULz`5T`|lbFq}J>ZXU(Qdpq?*z3=UUAKt1$a=mGgm zMB6*MD7;B-YQqi2L&cvLc|xntB@2@O&T&pJvyx#O0Sx>t(*sJH_g;1&4B#CHP(ApP zJ>;d?w&hNC+b%Gf=M;O_V!hchXsgTU(nw_}Q1$tej?-aME|5qBPi#r_L5K9?_YxQc zDSSU!7u}$^HgHCd2(E4ix}#U5zZLpYfpje&l_?m)AuJ75;`Nc781C zj;s?PZRbIL5ZLGyFjJ2u%)a=Te=K}rYs3navu@Jn0znQ-L!uO4tw1A^1&&EQh5)JE z`;a*@oV2h#*RA^Sv^;C%1U5Ey&nkRxz51zgPwNOXR3Nlq*Or(sOdT$4fA6^PwEgfY z^sP2EH-EKZ62ypg%M0b^#|_zIx*r+9Nd`quSG_=630M$W--)abO_6aeabA47?1jTM zUw_>^I!@TgeA0CU^`N8G)el1=Cu-7?o|5zB!Yq_YT&r3@2yas1R_5hfs7QD-^EAQz z-37eviz9oFhDfHn&Gp&hH)pamUu)bRvrH!`V2|`H&r7~_$Pi7Up*=7YJ2LXmx$r`& zpz@uuK(|KKA^{)V;U`C%hR5eO+RhhzIbI;Cy7ue%2SlMKU^$1X^8?`+jBmAjW~!)G zq7UGWHzPW-O@1*U9;^X`3$ll+3wOQxl^D%J z%f^8*c7#s#Yda)0Z#!$mM3X(%Lf{9qyJ^EBt0pX}j{*748BqH%IUSna*zT|>^%t!1 z4Q?KNlQHbL{`+moP$M9P{)5M=1M<9I8>X}43RF$YoT(f7WNDW<{v-L# zg=DFx%GEf8%sq0c1d4tRlBKIc6V+gM@6>h2(oLSFx;*)8DucX~J;4u7WD|WHE4L9M zqDD`D5YbKxUmg)PE8#+3|9@)gXnOeuA*@wJkj3j!T@Fk!f(ce84~FlbqA+qe0*iyN z9S}Z8$th7+9da!mAmQ)3X$}b}e!0&ND!dz0P#@h;j4Ws^+esLi|NTx7a>y28H+Y9i zMg<%mTN905J|}M{zgNrWb@g@|p2L^i1->fPUwa557%W_V9R>L&Xgf8)Wv#tgyuN7$ z221D`@0HU*#T6S~ez-q!Y`|x{Xx@L@y+Wr>HkL7uk?)HqkCjhp3EYO?%^AwyjR33D zUFGfF4Hy}lDsyzkBT;P^3xiQnA*Ixc(q=4KSukU!817UY0EbWHAw^D^8&BE7h^;ci z9i-wwNDM|fFR#j)$x6x6z(r-PD!*V1zv#;`hdDvVjK6XsMBeiO)*bbsKCYLqK90!M z60L)<4afmTDk266k#}v+MKXr#qbt*Le?25?y^NqA#-5m{;a5AF#o{o)6eKJtdNumzbD*Rk3r2L>FHl? zGbnW4Wl6sx`HCz$#Z|9vgOEKlX_5~A|C7Qf1ZSXZXk5yM{#iwsPNgKRDMS4Xn73@; zITWUfi~j=7o43S$k6s=B&K7<75rkux=xp-4M;;l^{y)av1D?zFZv(bhvS;?po@I|8 zDMUgPkv&RAi0qY6MmA+eic&^pC427*S=k|!kv-q9x~}s& z&+j~rP?Rt8cfbK^WHd zK=g&G-8NCpeCfNBf?&T^Y9F4k#}}`_<0ijOh;;Wuy+QbefJGmIO+*QVfzfij?k>SS zZ$TE_I;z|s+P~TxP6BZTA$aU8wvP-xlNhPQ;!GdAi|69}ZQx{1jSD~&j6Zp#*kL1~ z7gAE(e0O*N;pL4sAVsK}@FR?D)TM1`MnW4<3tM^R2b0J>%ho%g)3vZu@iSA0sLUIQ z%Dl~6=3eVGyw>6Qa#V#@nMmbR{WwJYqCI#yux@f{*n*8r?vqh?_DY(}(*>s`_A@eA zuV*keGE<=_(2C`lJbpLmsp~tA_T4Q|B=;#4w`P#v88L~N2a46rl4`Sv4yHUBykAGek z655*`q`o2bIQL`14Xs9t2JJt-CveRk^U{%G3~4#i5o`{W7)~!%M$11!aL^8Js7zr~_fV4p(T_UGNjgYZ@xlWE5J|!qyrRCcK z!m=BVsV;P|b)d&gHnnbcTlPHI!k&HbypLxcpzBz6^J}#3`P>u$=y2r9hj2lc>+SiH z&V`$Q3;;Z$zaC=y#mow-CoFCg?)c)^moJ@Jt;S`VQN{$4uTIT0+6rAB!=JA(e>`~2 z)>5_C3e(abH^0|+C!bQ*1SfYVQ4Z=7z2eWIR$aIZEHLu+f`)96W9r>mhk@R?UV0fQ zvUu&tN}$ADCYt*OM5Y%a1p_x20n`#K;JGw@dc-otC2RZ@U%g*fpwC=wBI>3;)`-c2 zAc#+&ld_%32Gut%C7Vbk1@ubZ-R1fni=aPYBpw}7DQ(UdR`qPM(4%!*|9oq8!Vdt) zz3Z=n^4IRVE_ob6VTX`_$*{z++FZ*}iD5Kc5l0CJ??}_H#);*T|Is*+%lxZx@({)x z={CIZDK>{3@`J8%$qg1$eI=4aVe_C_u(ml$Tz=lmR`OWrS3BFM^cwU3?xIlsr;GA` zm^_QB6huPrt1=FV@dPY*dTn)oe!6mGSMgVokJ$@e97%=nmI(yfii10c<4A>H5SD8%{su|FXLDDT8B!N z?n}dd9`ii$ULOdmdZ65NlYxY)t|fTlpr>-Ze5X0JR+~5)=vq$!puRAG(BUb!?!S1A zjgCvEL}&j6Nad6{mxUGK_1vMeZ^rmj35d)=Hkqqv+?9cIuC4db-K|7Hifc|^QNO>& z)t%wcQ)eOPZ1UNOl9n1N{IgU_qTYab18j9V)W32-^M1;X7eXG*sDf zBo~x5g+SNv`O!S@$QhjG*wq1?A4}V*e|94njCRCe$nKTzN$w#A0~zegbQExdRqOBM zyi=1qzlv{#|N1;?3o-8A6`Y@Fzs(`BhKMD7GgOjIAkGt^PPqZoNp*XmlP;Tz_sSPq z41t#Hwa|^Hj6WB$e)=^Gq-ka>xZ_r(-yxubnu?Alb6K0$zr%se?!7S%wPdvt zf@1tu$+@LvT2fjIMI+n5cdki}I}qPL1G&QZqa-ATl|EPQ&Ab3g8PjpnW;DC%ClH4y z$AxD%t)Xi%KvHP&25?2xzCy&6pMD$hgV%O=mL>xT*{x8lG!?)$?|mn`8{g-!LhAh+ ze!#qgY}Y;EaTkhv!UT6n%W1jIO;Lr^=759(9JJkqmb0rf@7Y+Np=p@a95dZ0i1q99 z``;TdvQTV$o*a8?khRR;pvDQkV+Z&LxSn0|Xj zJX|DNPP|oZcplnJx(z2Mn^5U&%X z@V!9mu|Ii545_nCfZ(XGMw*v$kxk2B?}5USJ=4ZW!5SMS+nC z$EEDt1$9#hBx;4~(S)C$*f$rwTx@SQd*iu|XWnx0Sax=UDWF2a~vW=$Jy3qdqW`IW(1qBUM?FxlK z^wS*FR7rafrq~9|NctFiWGI`oTiwhS)k!1UW7T6CFb9zRZB z!Tj-HNjtJ|Y4+%xl3}B&0m0 z>9|4*=QHWR=~vsK%z;Gb@k}`T)sb$B`gmMX^rhdo0Kvzk7!p^lZT#4p-iYz<78WwC z!P>Q@Zq*xqBIuA80@ID9OFBC2Kjv*f zOH-?|zOAW$ONO(tT?JpuS9<|GDwXcVd4W(n;6j-TsM@>q4M_r4FsI+{%(Jd@?$G-2 zrT_@tOA;TAg*&v0xUt7>mUdl2O52kd)AMYSht>Edl&cWbAzj1R@{}XkXyK^9Fuf9= zKAWHxT~OoVP0JH5byH&%kLY8rg@DC+>t|G!Sjl!#w&w+bQRaq`(YEEw$aa6K>=K;E?^WW zS#g+8?1zxDA#t?XngM4s>E|j3gzfYU;-I&^;X=DAm-38UWSQo~#aQW80%QxU?|dry ztp%{$e;;OSUxLJ9@Pd)2r2IA{Pt>n;pgo>B04Ds2(RZ{5_d-K6J1%8wDumODp5ebz zrt_`;mGZPCRR0iK77{6DEH@VNBXMBA-df;{+Z0F$HQh~BXcJ398ecJX>aXN24l8ra znEkEb#QLR+%IzhKEYjy`HrgG0GMV;RE$pw!U!9Uj_$={pedQNJ+=3S=xdO~lTklNO zgNnVa>nAx>ypeLo(X zRU%%O^Phf@?WLdnAUOYFJQKN?X+P7CR~#0N8yqx+=u22P^=zLYrB*$?#|#!xe|caF zW>O?1j8Y0)l%Zw8Y!(&*`q*wC70az99J<}aWTt;SFv9nWbhlB$hM9!vskXt1s1MNK z%Jjj#n~qxE;HC@3y-RjS${e58EbbkI>|&NsdeJJ9Y6U_C(h1V3aq93O^G+49yw{@+ zDU(_6{SZWWe0=nb_V39+*7;7otXO#%93jbt{~}Vm-)IQ@gx?rQXhHn5uWN&dwSovmr?nlS z`?)_|U<)ivA8hRBm+~&+qrgbY2@O3G6D>8nsFa2YSs`v)GegLGR%NXK~RoVEM90pbJHgXcaWax)kYx0008Y zxE@drI#{H3l0T&7eIev2V!NdV!x+wUh0E?V56%i+SP|d-wE|hqNQVowG0pah zswYostE#Fh0m6y>LhrCc2)<_VV-S{-$zbp_D)v?qAu&h=8LUprg0?Ea8B-2C*Uq{( z?PM=jCshO@`(H0=uR;&??*`D^&vtLTLygl;kS~pyec}xIJ|hI!~KedhO@ubm$R`+bZncm)j2M)Rru^kI+G~NzBms z+1!`5G_>!C}h)`L$NKWG%UdMOuGoo2WPA`45}%C7<6^vBdA?A zzM!K=G#VSAGZ7AqWo~<;>1Jj~H1B*9#l|+Jiz0kA4RLS-fALVX>BWzRhY$BF&S}ym zX8)nde961s=OaR7CaJ?jWWL}64l_L8L0f1d^S&H`Hbd**Y-dd#MldKsBR9l-mO_n7 z222ImOuS&5i|uWFsyqhAzX%d!=$B`+g95<$$RvlcIVqOdeGrSh-m~D+Xn3&-X}c~Z zRPNL#G*v+0&;Wo{LT5>g37|}g?=9@_bzYB2{n1R5j#h^bRl-F>s&QS>8vhPr7PMKX zCm{1O0mUTI@o@iGd<15Dae#O(J|G}JLOrMthIDaf0z0bVc$!x<3)M&U|Lu`a*mSGN zV+o%Un|gMn&*9(`A7=fbPjSq5>tou@Brw${0sj%*yVg(hH^uv|40B9>BB2JwBeeIp z%*Q04C#&=Zvagd=f=0Rb$J#g2b|#PaLYTmQfhr0gY8eh8iK9@4PZ0+E&hzh}JVFOf zO%!M`*BG1!fh7BqifnWUioM~G{FhjUN(FgdRpO}}!%;s@C$)u8k?Z;AC?m8A~}741-En0wSdR2m$seG}W1w_k;CpHRvqnt$#^_BHb}W`g2uT zsmm-7V<~Lku4a|BjpsqI+zrc7-@R$y*iFkX9uY%}W&cZHn8?C_OdNLGuh}+00x;Au z+8HSNzPX1Ww!dzl*pgG<$NfmP$N3XU;-4=9-1ilSIAA~3@1&UB!^j;G1;Trap&aT# z%LQLuM2zpMI{V0m~qvrd?#DH+yBbi zU^VeQIoVW#6v70Gi(zn99C3EfX>2V5@w^X#-#-DHMHfOJ`&J5_Y|vo746x|tmJ2T~ zpY-makkxB!<05?qGBaBxwBZWS&T2bGXCcBy!T$P+n~K$UQ5AhbIi3lb9WvetbQL^@ z#BZ61lTF-wY&RM6x09{vKoa)q4$SptOj;EtOsKo0t)_o6G?2(lyAzeP;&{sV@R@}^~tKv~I&kidwaW*qpCBwnlFC*dLFs0thj(Nn$i`?D4SiT4#( ztn%*;wi*^zyGxB(JJaG$KnT?U}{2M=AhjDi7m zE10IqzKhkk;UK3}*U~ca_j<&Z;R3lZwoJ>`j}h+yE@(0J`&m4cgl_ym$a|x|9~}AZ zw`9S!e~*y$)ByF0v1Jrcc)~#1TeI>J02buUm&WVIL?U|+{VA%$4R%p7t&QsmKje3h z%21soBp^^h|Jybm+>XUP`1_{VsEic&&&VT;8`Z=W9}Uj4 z9ey{k4MN#KThvtzF673zf;pVSGSZoy8}7yb?RAj1Uiuv%H%=*NYiW?E*G%~X8*#e< z$X4Nq5~dr>4hn;eAh2C&;MAcmhd%P1LNCAmcd^K0#Fhx(;)V5x`iAV&|K|Mda3{Z) ztO=VK{6rH%b%+Ac4k3e7ccP@TmB7s;@5g_>=O2mu&PYP6cDy&p(yT59j+8)i6`UIF z{<7eHhV;^>%DtYx3h%emL_K-NBUb@g+))YbnhBW0m)a^~-tRsNM7suLdu4(=6QD@B zq)(Z>1~n&hm>BcD%evTZ&}!6Qg#2*9;LV`EBi9`Qt>0K!36WMz;MfQuw7*gJE`Udb zgG`6@Mck|WhhMVDMP5zcqs*~uYknew6HMNb6v*j;>Qeig+|7Iq)hz(}13s_d(iQ9XMYWM#} z@Bn;%D3f05W=JKb`@R}t$?#Y(5e02sXxdlYViL6?Y~%_wuN$Es_I2+1#bRT2rV+x% z-db-2S)PsU+m-T7C|ewn>5M7r8ygKgP-}#`qQ|n4FL~1b25lvjO|wDw^(^(t5s!6U zv5V5y9m%8@C}!`+b^1Urv*>_-Avupy_cLcZ6Sk-m{I24|P@d+afQPc4MP*)_PJ!<@ zI52_BzfrE)4Nqy`64R%^ctFOAqC_#p_VWw}|L34o{?4 zKKrw+9?#IX#L9&X{7tPoy$2=axojM(8QGCt6Ku_T&qO9v5v^)fKsf$1VF`|_-(;czyOw6XYnDlq4MKk*kx9_ zP6chcA_sT+T{@dJ^xAJSfRtON>2TyRKo^N2$m~yFoGsqS#S0n_BX~&1R{mm|DKh*Z zNd^1)q0*01OhqXWInW@}JYMS~LWjb311HQO{t3#N7YBsewVhF1`L1d8xXL$7L2^hn zvvfLDRK5C)dXTo=Q@BCsP?;UnCjm_B-Pw~w${faWDu`z4_R%X-aI%H=zK!giTR`Y+ z4N%D?{BbSV^o+339wa7%LTvhOF9+4mz@s4eHL*54yat$+AuD(~G5D}V3AVgy4Dn;h z(ziOU_T@jCAe8@QF$0@10lq5^EaxW+xAzx=?!d!F01|lH z_8O7A&NYTE3&U3c4cqZ1*ZrARkgDHz3mre^Q#`8m9uvMn~C#` zP0N5R+yoNym*0{l92IZjvTSQnE8>|EB8F`D-PY{$77A^p*v3A-%deYSZtsMkOp2!; zSf}2V*oUbd*}#HSnk<+uUQi1R0R1!f76-vl@A8~{gb^C6;OJOjblnlyBF|J~IBh_D zxrJXQLsk(Y)T7-74)3xuO-xh?g+2iP?R?P*hhamKyKn0h0EW{8DxiXCI*B0p}47qYBR)Z$f_>}Wj2uR&uK^cPv>7QmQ8$~3#4>1%qKqqdd}wEWNvrjjk}tQAJhcDikGLn zco5UPRl+S4BEdmQ(58B60)(A~0Gvna$jEe%Wr5iar z=Yv-&xCMmwcBbX&rr5o@CAa-6K~o!N*e3rtECL*u&qCPTTb(|`J1yO$gz8IyyEnQk z;7mdKlXaiX27TDoS#8RRu3_T7ynTuyJEqW>dI^#Gl7f=#6XqJX$tdM8C`(;uB>jT9 z#$ppB%W@23`JoxXw(0kSEcZ_UDIrsZhfNf`_%j+|Sw~BiW+r1x6=puh#>xO4fWsIo z@+?ve$n@Rc!(o*Xg}*`B5^IjB-EsIp2(OKKfXbO0{Z4T%l&biHS9+5r!t+nDQuK*F zXl0ry?ovB@Hn(=l;+Y}^8u?OoB^<>$uc`K@a?>1&=))}ufyHa`dmHAK8m_$MryT_1 z($%$4I@0!bY{&dWKl^NdOKmCZpn8fYz=jGyFQ#uSls3b8HvjZj`NJcyy&fpC<68^Y4BUJlUG2kjVHsN%eyJ^OlsO0~wYMp4yQ zi;=I&N6ETsaBt1x9z(`_B!~n%KsA$K!gd;D3GG}5*N;6yTVrjx{n_fZod9+Q8?|A% zo0j_f-TY!u;^CPy%t&#QEB@5HJF|el6)5*RmyDE#=7Pfau#MGxzM&Fqc+Nsv;os=<=&iDvn6FOSQ7uJDMv?&(%v|{uO+S2ZYZ`BL3pGU*-)ZWIz>keeFE@jV#b_0$~*y&-QF=DdUW0J3eD{d7z#vPX}{hrG4|IarkjAFndjIYlcnO zK!I!AaIGe+!X)K9I~UriwY{c7jO;4?JXxl-cLW5Flli3mD_lV~E8~hx-x<&~wykr- zlNrU`z^=h%4`G=1si~m7%a)P+x|x69_pp=SgkpzyRB7wBR~Hl57~r{(%(0ERYjFbM z);;BSEglb%0S@%^0(iZZm!dhI1CAokv5;E@Tci}D4V^Du1_WSup9=B)7j5#%G)=_; z_-S#t7#QwsUJ!}&Isz6-ROX!}u`3iV^1yIrG6zLU33J;zblS(v15;NjgHh>Hq;t-& z*)mn_qd3wcv zhS-VkJynIW6qKpkL<*;(lF$@cDZpoGbQ0z~~P#O9UZXi(D^v z^N#Cxi_@>&8B6oWz?i->3y==z7$llU;9;piYJ~tgs=o0%7i5AqPZ|AQHC6>Z^_ZXY z2fYX;NhhT@4kJbj}in>H^F6{U6<2nlsK z!7;i8ZO$ethZT8f(jcCPz@aV_O);!!oBEr2n%tE%MI}tHhNSOnu^>_KZEyB@-ioPb zH-@;hnt>*wWZNpU^06I9QVeFd_rMf^Yyi?gsq>x`kW46_?UO8Xip!}&^A%G zM6s#^2uA(0+eA2in!bgNJalihe&+^RNT(}n&UiWLw(bH~X3<9h_gwUQtE&{o?M^qcseNb5Na< z0%d!9(y-yw7IyW$-D8mxL(BUTzn>IVXa~s{_P!o*QZPp1u%m=B+w-rsjNAdqKRcD= z5aEFndDPp2$?e5&6a&{4*cV(^_M=B~mmGR;28thL0i7`-VuvbV)MYVn5GNR4Aun^K_KWc(2fEAV@oFExQhE`C&O`O0hEzsa0m$^FrsS> zgi#lbWj9I+h;U_|<#zkO`0QZBxeUd~N8ir6Hs6Lafx+%WA=3axVm!kj(6*4<7{ye> z0zP?TiR<8YmG|EMFSZ7(?Bp?UG?ANz=Bc|JKT4~rnD#f6y(`OM<{ssoF$yM!rY6_qnWndS26t<=0-`f(g z$fIwnuKUAzowq>1?OU#!AkTWq?Mba;M~CB7iId?^>{0rO0|Z|j&Lw@l;|k3+3g-sH zF97p79xMMTA}^#wStY6N$9fih_;tJ^7l^r+IeodOOEHe2J|%U$QJ6dQ#=f?|FcomP zqn$GbjBsndzCBHgz>AUYJXukwc>U=>KOfLok};+A+%{T&3wf#we>@3hfIqmudfWXs zpNu}bRB3<;WRb8ie>49v%!az_itnI9cFT^5e2zq(`M#{_vKJ7Zq1QcLUOuFvf#cLOcPE2!6K6(N(o9UE>%8H!#j312w85+lAVV5GPCfJ!}v6a zFP%qeE@=+&{P-r_axeHN=usDJV(*y%6 zt~7|I>#4C@sTubZ8x{YykJ^m~MDgcBpKfoWx7D+IyziD1PyijrF`wCnflxtVhmcbC zojbx?lv8C@Yq^M$2u%0IA*#c4s+(Ew;|{F+O<(Idw$i? zFcMS~FMtyL-9)an0irE#hfGiY32~;Hne$0v=gxCZ$cqmtAwi-n*nT8?#NUspom_)b z5nDX5-_gX^!HH=5OPg=FAMEI1JOZqFMFTZ4J`|FlZmoTL-iS*o5PeNLrX~G8jdcji zyjimPET&z1@`8H=W#he{F1zq9n71Zpv8A?(NNW+2_A1DLUY^EwYyJX)8=YIzKnHk; zei(>XA~k&pW2L&#S4MNh+P%X#Q}y|=KR||SMeV-Z5~Tp{gARb@xm6#_@Mi4$u@JA|nTeLzMM8g2Ty5=s|Agr-K^KoQF z{O30xM*}kjgD=U>Sman#(z_yt$GNZ32a{W6TP?&9oKeU%Vxu#!2kixeccIvH+)%@C zUS*o9RR?5YT-?f>4Qu{&17cqu#(k>Y3amV;P^6_MLr;pn!m1lSTey^~k+34^N@-0O%%hWW zCVXy*uP*=ukWJDeamH~JGr<^IycLa%+YP11LHYP+K(bFQCZT9Qu-^g;8&pI-ww9j~ z@|Q2zMU=-xBM_!?=q38yrlHWG_fcJ_G&NT(gdLsWW^LU3x8#QiGPXg)bH{DhaR(l8 zv9$`QLb*)p6Wf*GQN3JMw9x--N|Jg%^$vtj#O)8gb6zDvEr=Bwo5OfhzibhyM-KK%v8`>W?&NyC|g?1JPOTn~P!@z|Nn6VbEIb8$41b z58l;|JpQDgNsYcSG&8f*o2S2UGSUg6&O4%zBu=E7SG zM(t1g;;)A8sDxaNVit5bLngr$h3UK{gHU?ic7F%FKiMPx>IXAC9&+b?&?r2Mqup4Q z=d;SY8%aUzu>b|jWSrJaqX^0665$Ra_0+FPx8-7H}lY{@MA*ryo>na63z&W`bmnnwxX}? zj$rvS`vL?Um}6cUVPT6nhmKGnFxr@JB;+cW0c_p9KuAiV!YFTPzDmpTm7|_a1W{)# z%m%Inh?9GK75@}^?_TZ%B5+*zX&6MGL|>E_-p<0Cch`O+@4jqtO%Z|X61=A;>j~!~ zjV38TCuIZKYZ6_1X#NnGVW|T2`vRyWUz7_WM+&*jd`KI~;#J4ne*ftsM&zuQCFVd= zmn;wu9EmPcp{{Y1zR(17g_yLA662QjSjPcIs=HQjnt_C0V$j70pkx67fsqoARHtC2 zcFxNjh~E9PU1G7381HT2XoOv~G=gFRzr@>Vs0*xz56eSg=1dU<(-Jr6e;N}Ia1oJ& z3_ssvbv8tNreFxYH!UHMWNmE?Mx9hzep_wwf$TS~`>yyH^o3~Nr%u*Vncdd=3Mh~J z`Wmw+9c=3w_KM{5U#MDnBr@eu?29m(m^*~c;sK_05;SGrb5^YO8pK~g%tH+t9zMH# zger_Qj7Jnvsm3p;IZwJR94OI&p2ns{8X}fTrpTI))epi8`ysa%YYQiXev=gTjs? zXcU>BGn!C7%K0+IebO1wL){RuzZjA0NP*Gq!dCh@m<|A*iB~qBcUV)a(6M`;2C}C$ z*Pg9zLd^RNI_RXXp)=@eM?x5Y&EIV~@9;IVQUwSL+CJVSxJ&b%2Q3K4H~3&J4yR|7U;Z}Q`4euFFIBUk0t)x zL4HEWL1FzR866B!^w$xZM8o*90!jr15!ekVb!PHUS7$(N|Nhm+RO;RBy+7j{XZ`shBF#ZN#P^bi{kU|7^S`!#$Dhb`paWnk1X*+sa0x~W<`q*8Rv zHtyW78gXDd=99=OJt!WCwHlu96Z+J4H0kc^zj`$vCefXpdfmW5h66j64$g(MT@M8| zK*#nQK;6+IF=p|lJIs1FPju*`n+h!cgC%PQ%V>YlMuK_8&xmDVjCF(geOb<@SBkA@ zd@`ZO+5kijLeW4UCB`8-b9+!)?h~s0rku?CoEU}}2vsbFJJ3vpqG@p^wzAMz1)@(N z8XI!B#+5prrxDsoP7nF!WdG z`0|Uw4hCpA*$%u`Wjf;{*i7LuQ-DlBhS5q*fv2nRX2lXzgpd(pLY1Pog+k>%-~4#4 zxf(X41+P_;DWc0gkQp>y}aLFfvB zNJ3qCnvBOv_MRQm3JQ@Sdjz;N6H$42d9w$%q4lcVz0e>S&l72Jk2zx*DcCq&)&=h} zTmDWXxzS*c%bb8>eCkcYw(tCBTsMlIfvTm14D>r)q$}E#;RM=ooCF`SUY@{>Jy`B3BqX6A$*Lr*nW22ycgTWGkC*HW%eYSHTlCwRaet!36i7vrbzVi zP5dP>SO~C4P-y7C|5bI`9~li@&)-jo{C`y)7(mL319n148S6{vn~j&_=A{I;_Wk+} zGb8$hjl(4?F3n5v)Lfb#@jH|fpV`QZp(%cB(Zu$>FWBsjvCWw*qrePYKYu071DHp<|O6x9gJm= z<*l=wC_jm6%f+%O!muU{oNP@vU*s_I(%M7<(Bi`jd*FGj0>Q)BnpKH-vG!Wj(^TNnv&)hB)=-4f^O#)8?NapO40D=ox<5rkO6_ zd@I%K*3EANJ!3Lsb2l`y7BnwqNuPh+Xm~Ww=)RqKn`Y#YcS`ZOkkaTY-{z7VMvw_J ziN3SXJbUtN?Y4{_Cq+$#Ti3i6ek~Nb{Vb!+@?%KW|I8;jx&uC{Fe#kjbEXb>Cy0 zZ^zA~a@$;I;b{1mJr{iMZ+rn=Z?kE-9km8?^jW*xh+rVlr@7?g`wSf!81FRNrA#O9 zc+dm1pjLnM*(b}E*k)m9z61{p>mh7X2}e4~=UbtIPbS+mK?H~Kb33F6;{Y4k-suXx z6GcHax0xC6e=cdh7LiW2X0;=Df?d;D7{O3i@aBEN7iVL+?c+b+gbELCSj?*>N(!aZ zr|T(>&>X)-?xAyh9jV4Au9N2UU#id55P4ge?K44_S(X)3kZsq!vSrh<-xtaw5aM7w zanfacZ|`)yW$vx%Of59im8S&afOVPCERNP(q6;lMspwT~v;l4={2V<*_8)|iL36O1 z$=9E$Ozb7bg+32;E(*b2yY!8=SVw5!E<@hZ!(+zt6;Kc{$-UQgr%2NdAUvmj%+X2)}bb&4F9iP#*DiohzpX@ z9F2g0UzvUmpzpW)m^u|tn*MCd{A)z)7d6wrD=>M|p12xm4%H3f!22EDXSW582F`-R^KdmCnhnJB z%5Y$)BI~VIP&j=Y^hZ0tDGDfW^9Utkikd161L{B=S5GAex_1 zPH??xAN$bz$~U$(*N*2OvmoHr2Cz57G}yi`fVicezB|>I#IZHxPKWE5Izv6(vvk)! z;b9yUonrvJs|N94z2tR235Nw{7zkz|OEFk*%y`Tuq!Xz213cmxE|0FY44 z(au`Yb*iqe_Q|e_Bt7soi^T9-cP1o6Te^?P+}Ovqjwug9mqZaoV&0uZ>FMdU*;yuk z{B9B#LRopCZC%<0)E17Vx$1Oi|P8pBc#Kj*S6K5ues7Hd8jjdi%&7WS@qkFcN)kmJ3OD{hi zW-DuDWM+QJd78TX>bSy1)sOC#!mY?Q;_wxQ@EF z8(xPJhWbck)ymNh^T4Axuvnv9uz71G>HJftZUF8s0_gbB)RT8Cozr3CN+nFUJuvSV zUfh1Le*E8+MZVfj-xSB2U=AgbEr%R%4U5GTY51_HKVN}Z3%b2~)%ID3ioDl1jM?wq zA!e+6ZM&itDsy7GlXd!L&=w}<>ImonF(@b~c#SN1TYshBn2b4pQv-y^`aevJT0fEW zwQ@3)5cv1XuI>I14N3wS>*ao`Q^)0|kqcg8$PPL9SRXrJ7e{xWUm2+^b2ntam!z=C zVHRV|I(f%;-_{Lke+(VlZF9r~Yu`W5!N?5CkwGtqK~~)Eo)b1O3H*|+Fr&}K?e$KZ z2>Hgef1FEIl4KDK4XOiIMAGdHtNYVZ1hQ(rlB2mz=x3QoG4{~n)SGCRe2&#u=EbYe-G0q^$h3LhJJ1VKzGk1x4Z{iUbD( z&+R-jz$QE{1|VTG^gGP0I7&e1dp#iiIF=Xlfp`ftR38fpzl*@`gT8;Uv{2sVj1z-ej&iA2jxrO zOd*d-Qlyj=%cZ6G;jvcbp8nz24}KcrCLtwd0ioFhXf%F(K+t`fkngX%(7OVcc+R9S zu8fABfQ5m9v671gP{~-};x)9LU4)>#?6o`{3m8A}6|I1lTd5SWY|-VRP1FP@%CIt?AMZ-0|bZ0MW2`z+E?~3BF^8^X6ztU8HcBz#%`W+(Cf`++&B4 zib9B}uju51ES%2khL?Xm{>B-2V&t@o`H+1s@U8aDKi5LT z_)e-xEt?(6gurw|k>OXfsX^DU|D>&G=z@5_AjP&QgXQZyvNHGSyvO?Y7t)AosQ{;h z>wMz0^b=exK4#6bo7c3M^l~tgibs3~F-XZ-|9wk>{!l%f?c~uZxCNRs7SP;VJI0)O zxW4%>069@4`F&_gQReTso-s7XnRjw{bI!R&>XFF^mkI8XKUQEXbPzv4>W8 z)mMf>+yBRz>H=Vc7PSI^o;0W_cYwA0-8Qx8uTL$8z{MC%v$U{C7K2bAhiK82u2A+I znm}`A0RY@{%e=mYs?x@&4JJ+ipiL7%4FsUBny)jD75dL+?^8{O92$HAO(}@v2=M5E zN^43`qu$}QY`I{oA0_5FrC9YH13WbuB_#)pdyE3K&8%VoB>w&0ePP7@6i2`jXoD&V zH&Rs5KrCr4F9MCyO1loz z6_od&Sp^a>YPr%htYCwFT`K<#^0MU035n3R@hG4?(Rnugi7hg*M}S@P6$N-v)HsIC z#Q=CuE$bt`f)Jdmd71aJ9v(^LC%1FyKw?Hb<>wK=33C8Bd*$-T&A`JI_InN+y@aRU z6_0sT)E}r+tx&7sU}i=^@e-^OvRhxd&CsCp;)B$?0faOHFkWdH5=H~=n`Wo~+%ED| zwu0&Q?m`fL!jgw)V_>e9;{Kh+SdoGCQ&+wXZ;m+v1u&CUC~C~gyWDvr#bPt`ow*~( z%O4E`p8!e+x;Vs)d^S?;w4zq*B@DcWulnF8FE+%H&ORVO0tG0i#{lqSo0G)jue*WT z4gtZq!WakazIP}f`C4>mYrz^*Z2~O>u8WxH1xz*!EI!WkC!IQ%N+|@5450&NSulf7 z{reRl&qT6FjA*mXWCT=Ip{~IIGxdijn&ojixPB%B$Vb!#Vf%e0CPil*HO6=#DiH2> z84Zm!L{&*a$GZ0w8B&LI0u>BdUImD85dU4tOv8_1Po{Yq3((>pKU$aNs6PC6e~>Kt zq2R%g$R=9W)Aib5(F+7IT5VKl)y@NjBx}w_tUG$JTE8sKr~o|f5QnNX9&@A(y36(3 zO-(B9^979-{e_m`oWZcO^nCk(hOx&JDQ0)M6yz`G2aC_2jpzHCM;J!;&-3Pop9n9>uv;2G*wRlT0MS;+*!-LuMK;14#fQ;uBvH+nz#FFh_? zL^w$TskSD)gqGA+-)Cd>^h;9vyf9F(u~)G%zVkxczB@rHr|+piY$zev(p4;3;#&vs{TQfSjO>g2v;I`b>#tE^gV#^*4}4k`2>h_Hv74bg z!Vbq3iXzdIC#s9!hzIyN_Y&s-%x$vm!387+pk6Z}KeTQKKZ)W?I9MKsqJ9kQc_=HN z4|oK%ca>yO6lX~)n&47|rGCSc#klb@Ymc>Xe#h?qD5WTPHu^Sdgd z`PX50q{{Nz;6!?DE^}0{Tt7TI2gg~RH{Wf^EC*)DWGo4*DP+jxD*Z7lDtEvN=2V$q z!XmkG1#woeo8cI@K$dcor5XaVD-M4Aq$p;63`wWSNU&~Az{Oa3o!C6^ApF0VVL=9^ zT?3e~T7i(7znZ%3p%si&hXstrZRXG;?!ml8UPNOGeOX{fVqy$-(y7E5|M|o3Q#r95JVl z4`XYXkG_iFGB~os-vi719CbDnUx%bkd$jkIg8AXw)_^5a!9+e#1uD`ntT_p=Jl_Cg2%il?+>E| zX7%wQc4UXDV>FOiV6)cki;Y6YxS^h|opp8@-kvJd%#aGbwPTm?e;&vh3q&+?j~oGs zk~9!hN7h8Gc3`Bh#!V5RY9V{NvbIt40(hW zz-~Ff^@^zK1RlDogLNCV_lF+DtN{z;zw`c29%PN8lNtS7HDouc_`|8^MwwG%?dXnz zu6NHXvTS*6LBo=CYYsdxEzmjM;KiRfQx%JWOtBCp&*m2DQOEu}t3x)y8kOc9Z19!| z5Eh>`F)?W~d62~%6ma}-Pjf@o!hGk(e2`xyJ~Gr^1PI-mpjN>G?RU5+OmplQp`j7P zh$n$ZI&rlNwLI0%3(cK3N^Mw&FW}&jB0c<}Z3K@5hCu-gE-NgZ$A!bZc?U@|eLK+_ z?xV;sKtce1J;aP>_O|8(z0a@Z=L>;XzD(v>cnlrOizEN~CjqTXPwOgp>Ms>^3I695 zIbd~%VS`XZ9I%2~0o>|Ej`i*^?$a}Z3$-#S;`sSZV*zuQ19E}rr>P!i0ces1sS7BM z$$VnrXY=zjzyfRr3!JHVNN7v4WRLwP2+4ox$0PAHy{fG7e$$^VX?z4M%^VwQA1_e{ z$s)w4zR z@VN#eygq|bC~n8S&s0`}(G`|(B;h!M1z2M|k$I}>%t1>JR7zAps3{9tWn#x@{}WsP zYcCy;+l6-Nsj4~*NcTQuDibq|fsD3`a5bF6bM(TGSp2GXF<_=g6sT6HAdw;jzUz5Y z*MA@5f6e2sqiqSdYxuX<#USeG=MirRVLzM$GouVP6 z3N3qv^y)VtEw0B#*fOE`PSYKBOHm{hl?2%V0SU%F{l>waC4aWSKR1nregS^7$+KDo zAv`zbbSR~X*!Bs1?uS7yVDA88w4yP+0_8hK$`a4@mq@D}67!k&K3D0{&*RfzV?$Nq zhYt1Ye{;USjQMB=*a88?0$L1L61U~%;~YFZXKlK(S)gXoa~k`?6ZL}HE*eY>JPGXX z^$jq077$l{fKkorB>9g~^8o?yIejNWEN~hBtjF*F>^lvo^6#um-|6Ihc6B|6h zCJQqfmJIJAbdmpB|6p)aT76eH_8kG{1P`W#$rBg}; z38e)EBm|`!=|%|&6_5@ArMu&|ZfDM!ne#p8{k;DioteYK{p@@1wb#0?YhA0ru)+Q@ z%rXivgG2Y+me1|4i2l#NiLpY()L~^!i8_gs!x#ug8;U7np4+htHje`#y*gy2L~6N0 zJQ@ifEjqt_<4!C8p<>ZeodZ22}Sn zf!e?vdRPuGU;~yUcqbeKwqpvZe5ynpRAai(p}`3{fgL@$vhYVwkQc_o)AP6D=68Jh z*Z+JXffr7tWgGTL8xy=<*g$Xj9F%}a`40Ig5FA#6j-l{$Vhrn`5b1LMDE*J-Rr%@bHf8Q`@lL2kg-#f@}#rNeUQIka{g}pN$ywq?~YisuQO` zHs(gnXbKst8D5SqEzBm@2@DMU0rHSfW63?|c%on_=C5D4^$+MDcmuFpM2065Gy_&) z4#$+&(0egd^r$EHattEKfTH#{zB5+qd9NP&1ekAX9(@C-HO24H`qNAP>`cXkyNJs& zJPg0lIbZJ3G~ z(p>H$xUGR43_C^NgO?oY(5-`^bOknNC@~S-DF2Es5K;|sfAl140z%0MU}QAw9qR93 zp&U*xIWdd1y0{0q*tgP}cB0{F$B)qVasDU^J0%w_5UD^w;X|*LZBPa65Wvmdys!Ib zdb1w{&v@z>OO?Teak#g371|&MOmPVbA)z>iR^#%vVM+|B#|)+b6-u}$WG@d&54A~3 zE{3U_aB2BGRUZ2Lj(a2}h6Z-rF;H50=BG8{Tq-|-id7RX04`+SODR5-jxrRe%wXsX zN+RpNw16D^Yrsr#!eA^CK~rhuA_9m@M9kH=11`RB70*9X?8ZTePs4}ne8QqQvE2GP z06=GD&%=9*sh2whCEyB=KsziGpdgxfIVOSNzjqgMmASVX)>se}VAEW5|2v)oJMa8? z`IXR<;E_9vuI}5p78)x2xIlc|gLt~8CM^x0oOLVoe08Ff?}W*f_c>DfKeOVYlInu} z6rnEmM|x!R09L@(*MsWSH%w^Kn_*tA3W$)H!4)8^ zE^Glu3!x#pX!+3oQ7k3nw@MTjN_cw!3OEPq;}{^UJ|eb#aCbX{Me8l{uQK;QeiVz$ z&qJ^(|C61BoZjo-R`kBbo!PwPF~0HY+E{;KzmYR|KKRafgHuS37$Vz(PBK;g&ff$t z)a=Btl>05J7UA)vDh?mPGAe)VNx|x!w;YBD_xZtzga?2=xinB!r@tM!ckkexWQ8_K zQ3-4l4GFK-$iFrt3Yr@k&)wzRbX3~S(X}dkCk_`x;@s$fVJPU%n^K>)j zY?tuSdy1GZ4oXb^k_vaE1FBB~lJuqZG2YIo&uSDK)cYKq+V4ZUjU0VlKy{6}S~}D6 z*i~{=E`>tu1(iY<2d7lb=*DqbZ_X|KreM@zHzp&7oI&}0- zmzGiyu1!Q7$t!~yN>0X{ZJ2Q~9CewC9kBZQuSON$r#}TBUNx|(IbY+M^2ZhR*Opet zK)Sb29*cm{-XWnoV2#V;HA5WJq-;?6X-V~1Ah(eIWyGzAUhd`|PA2T>z^@0zLjOpN zrtE>flzOeSHkhB>%8kc!2paC^NDMHngDThiWD~{=F+=|1ytk@fXXxTmR_xhrx=gxj z;}$eLnprlP*lsGWU@a{ToN$V(bkE!M^%ml#3t(~20-BVCtx>IdvEMLlQ6+58U5Wbe z&p(g~xWDu~QeGhpi6skI!o2#F!72uIL~;H?<$QjH z``SN_BZe5a(W_xezvHUYW4?N#CAgk}Tpq}UTL53*g~#SAyFvo@Ys8xa&}EuQ`@?eB z%AFurWd;}~s`Sq7qlhmbCk->p(iq%yZ7jYcurC!kw?QpCq=DgeNeh3(&0!6Q1*3F2 zSQc&p07G>Gt$J(xrY%$r=|Fy--6{RvA>{*^7f}FQEsNg77G3c@G^pn=(cU4s1G&fY zA6MhQPNj!bqi}Jd#eG_FFPBQ8P^r(S_`5mhK^@W=JssDT9DMMpkLPMn-~4ItE*gI0hTKp37T z5nW+%$jRr?Fo77oh6Ao(^v=-tdRZec(Oo2y0+Kzrz_6XH|2z|a-u3bUkDN>-i*uph z_5mwgf#33Tb?Fe^0*V`EXda6m_6rS(8StBZ@I@aJ6C`pkz;jW`ofmonzQb%%pYaXq zKXzCJg8yqgiD^pIPXj9YFv10npc(iWA07a!X0uxqN(^B7m35dxv1pBiC4 zViCa5L*O$(wu=AY##!KfYo37mS^b*B1Woo56yUcV9gFJ8A61(e>VGJV@0C2$!=vEN zOI1!1P=Hqax2YYcSD|hifU$a?UNAiYq*{)Gk#gzYNMW)6vYb0PS&p_PG9V~>TB0XNT?C0}ZuZet{pvD=8Xm}2F1-2b znq3klg~}Wf+Ugf8ux%Q^mZlRjr#YbJ&XbTZfKk?SKs;~5^|w=xL?#&1)IlJaby+h`*^O$XO1ZP7gTmw^XlZ6`4`ELECt#z<7X)2PBmk{+GPswT04RcH!+fNl`c1ev z$OTJHZ#?60R^gX`PVg%h2oml4Oh+BV_zH)?PPyuSnn6@pSTr5GF(16|#6;b4Um|Be1INWfv!70EE@}+AypLIb$YNWYOU4mRNidEXrzF5xf`r z3#hJc{P{&zkS}s_$>LEx34*bLz)ug}@!LWgIvB*4XHYjn@um-g`mml7YT zu<_gHGt50s8Q=s<(wMjZ@kxKi7!3+U1eKF}0CTQc3Jj#O>>s9uVFKpE3^vwrK<9*t zNT&3HLAX{C97-(QB^$vPQY#8##~+f;r3B~B0YxF z3i%?*&8GjPG5%GnG%g_d(=iFjBU%ik0m%1oyZ@#tKUvPv!`G7j6GS&n3E+dB17I^L zg1tQp+-|HLghxW%m1p+`b z+KC!qJw`#BCsnDuuewJA`kktSKqf{EHF!zVczwhFv-*AxpGy~*rG13|n+heQW`-`w z7f6*1mpVud22Rl}gW-{>1K?1$%@tj(G_itqAKgzZ-PIwRA z;?_OH7*K98Gcw*l&=jN^f=-Sui0datKM2mDVsx{rfTsGO*Z-6Wgak1l;7#Nbn~`Ra zfyK;x8u9vX3jrbFUu%tm8ige9=QOCxbETjk#uZh%J)8=`YlKq&TC%O)B~jS}D(DM0aqRE&oj*uadH9#>Jq zmer4_-|5M8*{=c5|AAf5cLN>`EPG7?>%&)jL0CUJg z-@X}$HzCjiJo8e*9u02IBm93cC`fAoKtdz_jp2R&f3cdkdzc_~Wr4ntc&LXy!4tB; z-C>Bkd?No7mYn3Np%EDQd$|Q#rg+MNRZ``?(2P1z)Q%tzS8WKoYEWxc{P92d>Ax1g zC>2SmMBj#gBt%^GF?Ub_pOze3h~hC?eIMpo0lpaz8+& zv-%)0o@D(^BOESf9-h7@=lcHC6aS-D{3FgHZ{boC6WZMXrI&mN@+n|9avx#%0AKZr zM{`787(d?fWP>5J(Yz^~zh>&w8Z31i1J;ufNe`e-$ue`_{SUDDukYcQ0pG*EHS_WV zd?Y7)Ohn58j&kwv%DW)fGJ|(INJrKW=uU?V&EL{RcuFFElEpPfhSEfE{kXbE4h z4*)m%6Q=b4v%2`}`>-N8g&B6RW9`-F-1;J+aGfCP2RKgVaA%ySqvIxe(sI<)hv3#z z>5r0LB9r4wTz;v&(=1GR<_&=4JQ53!JD%eF4~Whmsc%wEd*o-&<>=Q`q=ZgEk@$se z?kfT2;w>x$12S?$$iOb(C(NK`+JuBGSzK@CX5+u%<-a!n-~ZM)3!ByBRU%P02M?%E zkY=PGaKjD2gg$r+z=^3hNK1cLtBjsN;vA%dR^+K6n%Aw#P(!9AwhTks|#>CmfkY|@6LGMtL2qNQGo8!GEyO|N7)B z%ndC_utyqxAfUc zepqmQNN?$AaPCZ^cduu(>a@c@{Q8i`t=yS_=4SLGMzo962J>Cq>R{q5Bn_`Y8RJ<(+?*se$`Cbs*SlUzaB zjhkUc0HZVkpGp(lPS8J@>`+e?4rA#xj|s00GiZ6Qls^o~7xK%Go&Yb7Ab_{Al_d_$ zDkWE8g0>iW1KinLP0;$0v5OmVmoX(zr1CJ7}R0mI`h2CgQ#* zJCtl&qVUEC`gCV*e~7w1pLoM*YtR(T_=o{~p9YL%9#|d1L2b*|Uu(fShO|3HTokOC zgg8zZ1UT?+%&vbG_Uwu$FBm*^hnf-_<`3M?UxPsd6MfE>-xPYi=6zXTg_H_25IseQ z75w)fE|l0`r)USK>_m&5V15zi8caVB(B54#JQEpq?&2D)D45A>=W8VEq{hL~y9t`8$RLh+pLF3dna0BHTWddnfzL~72b>>`Y#cn8l)n}2H0Ie-*EP*u2@kl);-*#y z`{aq0(neBd*Dv@eO53XG$DvL!1DwulkR&fhC-_TyI~2EF_^?SRPUSj1?BKVRthW&s z8&{;M?;2;=+PVcrG0S|9FaMx?7$~7PTRmjDD2WZ@-1cE~Ruw2}WXyVK`t zdB&}BlzY;K>Lf)&g5CP>KhmBEGo*RrSlwY2kpIe$*MsAYrqP zugq+ga32i~j((t=sR5l#%t+q#5v7&q4YZq-WJT#@Ede%x#nLrKXTTK8exnt#*HawC zoh1r(>#`w@U6)s;BGc0DX3x41gckeQgIUV@1k&F71Z42TM#q7D^_qH4G9>nU=Rg5a zT*CO;5-~~P=dJk>t%!3WEv{ zpm0&pnNF>)#ysp57t-|IGBPpl+?M2LZ=_@~n1uEj9%1Mcdgs<<(WWIL}~0_t#q$FPN^lplg614!B~Q*Ujr z+KCb+Hea#pLXY))dz?j|rqsrHZdw(u9!y!rB7eY9d^kE~dV3h3yDDvNF__aOru4H2 zXX$ail?sVJw%B?jx~l6IEW3Ua%yFcdYHCtm00&#akMFB} zO9SPNKW!@81&(xHt3hX!NyB76>h}S_yH-%YNE(eUE+y>Et}7K zDzc)~s!x!@4&@UU-AG;`A|Z277|w(C+!vS7j(lg^P|PpfHX^&Jz-a|40s57M&ndqk zEnbbD&q^@R@q9esWMr!tShqXE34In8Wb-h4Bx08YX?o14t904`m*HMH^LKBbU&#m- zpL&FzehhHYx%?DENLU*E=CNsAR1&HwHI^Uxt&|VBy-UcC?(hgIexm-}p>9W`@wQ$& z^Rr|Zvk<|+0a5E3bje5umGzLTK9`0eegr+^u4b=VsTd6eJpe|{a*3jaL8gpwXWKOl z$4Ba)DGWS}i^knXF{?(;VCr%|7va5+vu}(bWDrM+Eap6l8?eoFnh9mYs*2d_dg*G= zn#RCI>tV$Q80UM>Nw5i0bzE$6ch;%isgBwp%H94IwN0;)I2)g${v+atbN*c6w=@(} zLg5!?Qy7v;70~CPmslEdBj2^i14b2vm6$(6sY!6ljA8^)M_4=c=j8r0BbeSw1Ub$t zE&6+7rerTPl+Pq4mOAZkzQ{h){$QrkcYTsgqSvLsjp9GwaRAYeN7Qxb7sZFnluBos zGgI=5nsTO+Cyy-@hqASuG(HGi3q$YeLX8dj*z32;AK}lJX)Q`*Mn#s$OL&|L9W6HF z8xsL(Kf|NUvtK#i{y{B)_k2A{yno}7*@g=9;pXYlnr6xyjA!_=*cTE^$HuGjxg$Fi zb$TMt)80huGz&cc;=vhl3r6gmU;V2LO1a_`7E1Lzc<1^vbWoR!r%&OAIq=-;K15Z~ zY2T`N5bMnfe5i+wFuns8W-KQmXYBCTo|)lurs%b5_hT~cD7w=gIdo;#jlFX>DCF7U zVQ>7|#2i&Z9Yh=>>+oc@=BQHagegqp0jX>uIiwrGAeZAZBj0Ggf85pjXrM6?~gJ zTQG|6-TjM9uku`YoSQOG0!?U`;_}w5dwEJc!Gtc|1!?>37WjO9;T8KUDh=b>;O$^( z)X@Q+K{W>+WxkK{xu(bUR5JIsgl}Hlr?a6{d{0%`x>d3ycG63L$D`4_j++qyZD_Z2 z1+_#(uB}y;jmX+D{l~qCgcxHYvdHJxo!(%Pq(sc1#EdIhFy#rGUhS8i%W`Qmg`jU` zK|})%GW}Y@ptgtz;$ye^{bq^|zcW9`y4pDpnj2B!ov-(5rf#P4N;i2xF^SFg+C?pM ze{=6PTX+4@s&1$#)Mt%kn+*Amu}kJ;doWJG&k>0k`9IFN-skD>JugLoy3% zBmGBzs7C50<>l;c&Cy&%WA!kRQg}RrueTr1*YvY7>KO%U?1F~|j{`B%;fWbVmO*(t zaR_5zclKyuo-gI2ll#1%u&B^0E`G8T%4i7)#4i{JS53*LI4^6*MWqi0mox=H332N& zi(9H`E#aq80=z3U*5W7IUtRo6WuyCCu<_NzwCmCnn)4w`mxIu9GyKhHu7d;ny{-py zk@U)pYkj<;Yw%1cp-@V}n7`jHiO3lL+cBS#7q<8Mr|vFeoaX7oE?U&IzBCoIO`xN`PpYwEsVT%)jIf}G zGd3hyz*;TAaVoJq0(F#=VJeCI^X4ug9=i}7(K6M>yM|8ymvi>o>SCto1Cu$f!J6ti zsC^;-y)^1$R=?5G@qlkZw+4zzoCj@Gj7B}RrB$^qXd8ptsH!_`jKlCDQ z3YtHb<0b58^3PN*NH*~4?S6T;GbTjYM1mGl=ue!oaOdJI`lR<`JM8ES^eq%EZ6i;X z%GNiI!u9>M6=oaJiMzuc^rrS=vW6fDAfWSUdWz9PZ%71QkGDPZ^sGC8v(sGcsnWGO ze!54$X|5YqwmrKyyOFyi>7SSGI~7Z{^IS-l86cgW*Z#F))%KAN=gWger2mmd{qe@| zusPTci!a_y3Zv`^XS8| zx-2J9xT~fD?KftPKUApy_=?`9rQzHhm5+S@**YuaZ8`HO36(5d5F9gZ6HXBa$p^J(OXKY0a(4|;vN>n*&IpQg1kpa= z{=E}B&ip_RMk7s4cYGS9_cdkTtN}kG{BmN0yFN@<`=1ld<~E~jd5vbgor^d4At555 zuNXFYrsuDq8@YaGbL?R+riaUhxJ0AOQmQRgOo#kiP<)d!aV!R+#u;{GJ`A_ILO;`& z{i{;JIA)c6#Xo!wDQbRrHWkKre$61DOk$bK@?P0nNx!C^9QKbw0tuMdj#3e0s1ak) zq*NdYEvWKoo8vxW&CUO6_&Y~-B)`dNsLG)CRcIsxT^kD%l;XGKNEP}IXAUQrA2d8P z{IpuwUYH<_Iw`bKqWgXEU9gOk=B;5h1_SPbp0r2mX9~Tgt8dKs74CiQm`#>OrNf@- zUG{>myLekOmm(M&p;^FNRpO}70Vu7zDu*s5KfCnr#E^$hbC7iq8b^P`^q&ys>xsBSBF^}ggAEQ%x42ws)(FX-GMTzk>rZxNfjoMYJ zFKVm=*Pc{;`#hcT2}aWA7Sqdm^@i^ z@2C9m-6GlAmLQHa}mN@5~ADuAB`S`iplG4{f+zUHW(pgEjAIFP`pF zDO|r=7y9v>!+kzO7tj=_eVrWpWhm5R$Ma28P>3vYg3sNh=FXe&hb)f6wYO`bY`b$z zaxo`^V~$e9#j28T^yZ-$p50ODk=w0})dX}0Qkm8$-4&W%Y}VrnMf_g(2nVG`4Hj$T zi@pt3XIovSDVaH2k1yH}KX6^|%G{bi-Bmrx@%=w*oQ5f!CTkNQyO^l(RD5r&v;>=% z^laHYZ&#HbA`Il&oY*R5m&yz3NmKMU$mn`P zDhN$)C%LFZG{tS8oQiB}QS#UIJ=-O;fp!$Lao3@8+d!D@Cn9K|<25D}6nMn}B^Fn@ zKQT_DjsUN_FIcQ}v(!?;y_A6OiVv5ZZcmgPe(dswK=)6^+>nU<|g*{uX-fMM3 z`4T@uC{QYxc$-j~+?`S@#cXjMzndpuRt@%EWV`%o?EpQpwZ%yOx!f_AzWi)a3lTn@ z*UvY4{xV13p$5>u94%RJXx<^(4bEvC(?}X-@4D5(_L~0!5N)h{@_Uu~@_4!{2K}cC z*%W)}Gm>9CANoGb5&uf}cjVzu9OB2k)as)U|GwOF!FK0}_DQcQVVtx`9tR0i++8Ja zQZWum5bmR*0jnYDvUIJLajKPZ>y=mLDv!{<7}h0azQQgnAJpMgtDU_zvEI^Cg?nT$ zda}O(xJQLiz#3+&A^9W-Cb>6+hK+(c>-Qq~*o(fEI0?;b_{Cb*zvzeFCi-vab2HpE z%L7@p7oIS64#2-^P}Do~gm*E(DA}RQazE`9S=WzpshkI}4Af~`UN!rlDHu6cAw|?2#!LO0s^V`^G^`CdfS^sYy z{7AU3nMP%{+;O(N4WkY0L}>1O=KU0We)?$g%un~LV(q{%Bm5Mk$auUO^gZQ_(I((NpggyHCUr<8*Gy}}(T z1hWh=&`Vv1-yZJXn!VOGdpIOC?h?bIdL4M&ws%ed#f&8TecmOk??-F5{e9!5n$`YD z&|Wy4_%A>VR5+K2a*B0wiq+U|>68;eD^^|}UkiD$v3P+piqmu7b(RL5(D0pMXsmPek40LU%&SJhYJ(I7 zzO#5_X$o40PRp+xJ80eYDn*65;_l7H0NBgy^hjZ+OubKG+ErQ1hK1+{FMFBvJ8RSz%!=@2zmAd3+WOEAW`mdr04=t~Y#l3NRt%u?iHK1q3dSI^w<3NbzCaw<~P_8@9^3PRzOtX=O~&9+<+Q&xMMj*)d&0qL=1C^SZ? zy~bU)^;z_tuV3|C38FZ@W8m152mhk@B3*F5a2~u z(5=ssi#GthQC(JNXc1lQh}A>*5jJF;a;<<*>D(# z&*rQzeDH<;B_{=U0{lRJ#RO-2hlfHW&Kr_pX9X`GS zEoeud-Rntx8-h8L^>bpwL#&orW*Y&cq58&u|Fp)D-1{2=*WI6l931XdN#h}$PjlNj zFEZ%8S-KJO7N2~A`~LH46;&PKPkkZPqgELaG_EZ9VkIyRxMt0F&0BRe*nUOdih1gW zjD1RuYNAThvfGGt_S1_9%EZk*e^>01k(J(z-+B;zl_O`-(~jx*i`-+KjF-$d^ZWE0 z@CkX+pIE+fdW=v0`4j4r3x!X^(fFF|{s3ZLmX)M-&0xTC%lX6G@MifR-w>WaJ*H6YEepw{|1Tn@nKreH$>iy}mGK(ldScHsv9q zsdLU$R69G*TRZRD&0Gq4Ry6TP;!+>rorXVnqG*DX$Q?Vo^{_Zr^u} zi~1+Q^#|J(KqoDQg(;3!%7+@@f0*s>yztuHK;Y6Ym>N|(lE>hWzr~~ZgB@dkB=s|W zI3#ywOkGodu9-Xq(}W|3#EK9jjGC-WHeUq%R;pD!n1En-7i&kD)&ee`^EZg`UNG(` z8Xl^-*h*cyt@hukHh7Y>o9CW$ihP)TAdLN(nBKstvdf?xPOWFl7Qs>JCJ7cKYkh7s zIGU$2+^$!lDz3;)ZnvweoRXU0B5q9>oL2l9$I*C4)cMODA?xM$TQ%1O1fCVmO#&Mh z;_!Ooo7NW*(}c+d_p3?-4;`Dc%5lpH{RgRX$;3>uL zTrqYE<*1nnKt$5u^4Gn!IUxSrPNocscI%f7=QO3o3$&N=4>!gLBW3w&8g0YE2)x zds*ck9C$YOb}Gv%&Vs7+CyH;Df0Lyvp;A>L;rNx2PSER2o>rLojpu%ozyXJhJTS*v2=o(`FmLq(^j&=wa>`=GNJ4=%5s+re z!TDcY@t;Sj0lqn!>Kg$xY#PT$qDy(DV-3e$4OIwqDq;xkR=-^0{v?@QJN8)%>8z94L`)( z75N0JUT=FKIwK#1{_%PRh!6<13Y}Q2Z)at6s1D*>M3?+!`~ZU+u=aHrwI$@gzd7>a z|LY<$Gr$sKsJP^cph2ltDGD^_IOMlK!Lx9V6~+qCfnoCEIr1BSyy)AP9FbTJwd$9A zI0dVvy%L;p@r?KZ7PsKn^$c@x#Qd*q_xrcM4uh{QQa-2nHF<^buH=c!9x&i?2Dp&r zi|u`4OO2IRRSo&QfDBjB01C<+1^3-?7_&ZCt4ekkr;H2@K<{_+YQ}&3pZ*uG{}2Nx zka}Bz$?2pw*!$afLEO7BZSuz|46Jc$ZOgj94 zLFCKif4Ao-|Ns0lE1~dZMoRUU404g-=LjtOE5)gu${r@8tU_H^=q+(u<&SkMIS0Pm z#A9H8Hx7w^EUk)ih}1JiSosTf!sNO*WKxe-zUo$%|v#D&Seo&PWDblI`ut%^*<5ry9 zzfY(YBSv7+l|xdjP@4V0%6f9h|HM)G{7;XK;FaDXU?X}*9Ew0}eI7)4aC`TA(0GOR zYvt{^jXE<3us`*vAF;_TS4Vs;sX^8#j8n<=YqtX#m~A<@2Xn}9Vb+6QBj+ zp6w|p!V7*Jfk_M&boYGh-UAGc7;L9vbtXYmA;$0bf^U$2na+FpTrlb4Ir?LNXg{(? zS=gKx^jM$5xq5g*_&{H90tp|%q;sklzZ6Wz+ciN=t08DGv6&eXqzUcRHmyBSNb>A& zrJjwgi+$-F$lL4M)o(CBCX>P^7o$kLy6TwO=9c{cHIt9 zuEtgILPLMf!xeSnWlwixfJhu~+};96TC{%p>PI=3=}<#h%C8IL=zy!WV!k;0#g623 zFe!(5_m=p#k0tCYhY=L!MaRt)^(5QS#e4Zc=dD55D9y2&Xbx>_K>UJKm!{O!Dy+-u zNO{?rxdZYIa-TU)!*hrR0R3J2CAgYCwxE(3f22QM$ByWrjv9?eU$KGKP!UBH6SfHS z2l?e1nLKx&DOMxJy~$YScG#FV0N7tjB4UemZHr|Je86dNOMc@)=*hfL!zc1Wd2L+p zZ|a)b7v6RJsbwJRwl4X%ltI$$<8$ue)-B5c3A&B~LztfEv2H)K-q9@7a;^;n3*{q1 z|2Mt?69jbvf`JjXcgx#UF^~(I4T9&}i%?-=8ety(l)0`}WPB1+1~Gx;e#Y^x*a~HV zY#F0QB;~!#kf_P*6VPH0uuKAifzUOD+J#-)`njZ}lSnR%X(<}u0A=aDQDcjpLEbY5 z9D;bBshgC~!i+Ro?I(OXw}U3Up3LRz@&~s}^|i0r$W0VNbeFmmDNqfOu*$Smf3g2( z?G@h%Uxir?%qGXK=JKv{=*koQJ2|5Or_t6zy^i`gn3XNX!{nX`q6pDG7lePcw&-$~ z7H5Y}-Qn!<#|XK{ zJJ3ljfz(fP%tMtUd_}E`V1W}fMsw#j0R%CaEoq;tn3JlxNH(QD_2voP;->rA$sV@S zJWB-C>HA9>`J|D>Q;^*iup4jas5rE3R4)}=j1W5ZMk*elzPN|sG0+~+ua<5~zU$ub zR_Z=P#1&*uox(rVgE_%HCzH0prBn;QPN=;X8{ft z0VN5d_Lw;r_*?Bkx&?JO+0w=#a56znFyi(l<<(rV2)}kSksH3gA#|kmILDp$ur%Hr zseuXvbQG$Nth*=IdLF1qU2MfPO}P?9@pTp=T4Z`tA*4ktB3DgR9$|+t|B6t5?>Uk+ z$n#b{KWi;|0SVH)!Ptc#-Uvn4+UY)cNnW^9zh&8-c+QpW(6oP-lN2~=^FwKex|Yqs z{K^(%$NTqJ;Sy*Tvo;e~UG)dClB!@q?Pe#a-9T`s8xY};gGdfGH%*0F@>RSuX(C#` zDJMHT2zJ0c^ZWjAi+eB+3zJfEN?`>mYp&&hyerot!Y7GN>R;@eW%aC`i;<-&u$(Kj z%-@U1x^^!)6rHv$Ao9Jfz9imgamISU5nMhjhxYs53jN4!Yd6}Pm2PwX&JUA<(b-8z zSlvf9Xfs8AB@=+6qe{5T2sZx~Yrr%Hyr4%ewxS_~ zLSsB(Ee*A|Ehp2ApdGbIL)VVn$R*}}{l0kD9$5WFZE~5YNa=u!n_n#bitRuF7H0Xj zK97kada%=l*=&!CKXoQ4Y}t$g_u3d=v6EKHOIWC=C`$g!ch`DxxZ|c(pA7<5%?*v9 zOBdU%HzaE*7<#JOXm0xk@8PU9%bMDRIT9$I)TVgOzs#XQL>vi6eu)}l07Z*UR>~|| z3SY~WmVQxPrZepJbFVJsLqtfep;s`LZDTlX zb-X-Y@w^oCbT-k^DDa{L)v9cNibe`dlEw|3ItdV%-i09vbhU8!`cH-oyz_0Spl(lL zztYJt@kE{u80nkZL1-24ips)h9tg4*iTQ!n@s{hHp(^CZ+uodVOp)ef@9InTKrUJE z&W>6&+w1Lhlh&tGzyXDwI?DA>hP|MgP!R4waR8B_s-#J`d2WP2p&)>FzK#I(%M_f2 z_6j%OUS^h|pyM0nZr+^tfYMb4i~DO7m*U4E|IY_6l`k@*gfDYDn4I-C2UG;AKrxo6T?TdNTwe)H3>3L@ulumEHArJHzvQvAwSkEOBfefW5ZKv>6dH8 zj7~$)sPt2R>S5A`_*$jW3wMPJ*avi1L|ApbWM&2j)(%oEFFi57Rg*NtBgSM*&~;5@ z+nYd7`J1~P4eVJ zg@&tK{tc=88l%3nHK!UBbj>#bmJxZ5ZnI5fyUk6H=EJ=HB4TQ0k^XFhzD8`##pk|% z#5p8EyFxQ;U$c^4EK*-ms@<9GoKyHU2z|v~r3j=g7;?0(_XYYrx_LWdH?i7mykfv~ z!osg1f{Op`3`c@OIrE%q%5IBdGi3V|=0~lh%4YMPz^UAtPDEj{8+}57sg+V2_IM+X zS7|22x$`pW4%QYQ-PLY(G)#kXKHl$EF(<8@i!Yi7_ToB}Mn-(k0GVT_e7W3Vg`V~J z^3q9>^@5T|dLyrKNnH{eJ6FEVo;7-_#!r~1UKejShhw4rD=`~|NA~;Wpupw5yLE@Y z8p&U0wO`iPfW7xq$vpNpyNBYPF>zQiN8xXNBrFiiL>HQUye+yybzl}6@yU;p!2Wo< z`)6Z2n`GYWjIV;2lukVlpNdz`vLxu8&x*KlO@ZfrQSC;NamuaeX6LAqYb7fxB`?Lm z^enDKo2oR@e8wUxc{@)@QvP=DD!Jzq?N_yOoTbwjB{x%UE8@#&3O4av;_}Piiy?dF zk@E7QecX*C_TY2j<5!5iVKkU897;5T>(Pg)bs0|$SqtXY=$kOC%Mt>+xNGvFqf#Xo z>ie12UhY3Ut7e!v1XCZHp%dMpa(jZ0E-_eF|{9o zT1^lx5HfwK&bpJ8PGjXB6qrNWaSB*fVG&;lu6Xj(+_&;ud*kJKp}LuNS{rT5HTfls zw5(qT27W?|TN~HO-!(OvW91%GA}eKII6m=EC1@C~npTle+*2`Y+e$4K`J5`%t=66> zEiI;8@N&OvmIbxVNRK_p@U7SD(j=-kTs&{36K`2;e$l`@j44()NIFs63|pt)0!oO^c4f^=;nG112FExEnu3*<-b2x-^(r#Y)MaElWlSp%2^;PFIrd zm#z-ZSkVYJz*bUeE{S+H*R^mgiGUU5uO-eOtQ%6?}A)Z9L;b zb-7mdxA;yNQsVU~kj=&@H_KAn#DgKBO3ZJ9;yxmh!b-zyydyk`TU$C+?UcCCeXngc zzOKS=mh(c7B2jJy@09E(3(gl@l2y-ce6L7Iqu0^dCal;lb|)M1!T!cnkYy~#bM4)( zzKN5~^&}yV_TkKZjXiLhVv%6Gt6cwtGD_(n6!j-A+ba^gQOqIR8Wu#gD0DK zrmx#dnPy*JrMy3#)m(wSm1<5!7JERK%fciclWGMt(ETbK{iB!>iL%`M8tvvEK>Ezl59R(S`T2f;=eiYj4U@;wde+ZEyro z2xTyLq{?or>fKduiSu^nqt#8cG~5}9-j^OWApi9|w$}7xr9>WSQ#WCSZ@2BTOXeL4 z-2~Z<(7psKaIt0{dxNswWX3;jSKqaW_ONEO<~9d6nMIPg2y-^Xg#fVqi#F5FFC`!Xn~ST8o)x z#rx)!W0-RikM`3WJSkEBw7oG^+MTG9_WfIk^ooPJ6L+-Yk;0t;;~lbSa}^_5>}`78 zo-09t+r{O!4Od6%&6^W`)eOopp|Kp_oYsD8tKbCS&YBg08BN}~K(v{*W%Z3fmec=(;Vzn-XD7ul7;haA7zPj~l`^559vhx$(kNy_E@g5#G zHd4P|UroM4J*W0^g`A`)_gbXxhh;6eHec*%y`_gMV4F5RR<_(bFZ}L|Fz4_}P0(6^ zhe$;c%ey-sYu~StI&rsuc{evg_AH$C)uCGMl6??+nq}ye ze)6)PXbjeDs3+?q5k>)<_UxMgaS85^r z^*&hHJHESR4&aJ@XV|ps$WfM+-egtyis+1RU*RxEI|fsR2W5dB0V~bU?h)qfG9rJW z1dWS-RQBBLlOfMT_YXzqt|9lQERBk3g{rB>38m2*^O5}Nm()`-ZDBXH6LrlUcZiKv z=0rRJ5mSTJaZ7JXa_KFc8p$Y>;>|)Hlw0PZm<+_>vT=%rdHH|4KT$6Z#G}=fDf-;B zD|LAp4v(a2A$1Vc6oW3rWQWy~kuY$+S{!+J_OtNo-d=Z)sY+v~ChKhO3Co>9Vrl{Q zM$8Rpw&ldL>~w|6fSRn|68C%526V-tJCEW+114v%g1L9RYZ>nD83pH4jTy_3z0_jr zXazN0V>xO{@?jez$tw$0Hojny#ng-M_gYKZ_Po0{oih5Ikxw%(?x;ttPJvws{a#;% z&C3;P`P?LFR4j~ZRLfg;u`s`{#gv@X$Ga7<+|Bn*@LR;^TtlkeN95V;O-h@Q`Q@>7 z*)xeC^ScqxhK0^r&o{C9ovy3aUrEc?Zev#NVbh1z!N%Nx-P z)}x>)GFG$8%1m{8@sPiaWAWt^vCdX5HQDCD5#s30cRR54G|IipF6DZFl?kcu7oK`k z0gK@c5GXWxk6`$v%Ln&TvTJG8D*V_eGo9X|ThYI9%KlyHMW?GO$b+~SdJ-J#rKS6; z{3I%LlGM9TPrOn__pFn6pXWCg&g*AF(&xkZa(yM3f~#G0s|xKJ$Y2eBTw)<)yO(k} zYpbKRnq0}UiL^MF=pvpxVR0YEwIJ=|bISJ{BnBeAvtIGa)ks^#`DYE)lf(%w28v@P zClf+=!oMse2dSb&Nd{`l9~6%*Ze4aW-m_WP-ovOQWY0Ocnc{` z$0@_J9m9;thsRItLpI-sFKU)Mrs)&n4HOw|jK2j?8q>)GuRe8ThH~@MNWGa#__R7pi$6z+MSi-)Xm8ns!o(@*H~7IJSk+F3D2$R! znU!6lWMDVd7$-=LFd@^EjMPt0^a&|k*_F#od;Pmt*7`M0+V}A8hV|N*YtX7H8@`Mo ztLPR_jx|f4(7QG(LTye)IxL^`1dX4jaW>cxtEPd`Wg(1@TT$C)V|cfR+1flmWGjl& zJF)TJnfAm(-8*+1K3(h}eo|u>Bfvx|S^Ih@V^UYA&Z&E`M(O!cV6Gu26DOt}pLm4k zg^G{;yPX#4lD+h=b_hR({g``l2V^vMw_seia{dH+uROX8p&B7JnF(t>FQs)N1=@sW zJu0d0E(0ar!Q32;PuNHPUa>D+5gti0g_m;`l1v1+dib2a4CL+jX-GcJ)}E)mpqx8W zzNRti7)h`Cw(U!kV^6*B%=Glt6RcTb|ItSt)a3@c_4P{+mze4|uXFkG;~9AemGM~b zb+zt%5eP9&aj&H>{CF_d;GNX$$Z&ZAWJ&37`PbMLjF%0R>z*u&@_)Wu!0Y${ke0yx zVGHvgT3^#pqVBR~7%9DQYB_CXHf*xC^@PYFo#7T67wA28s@O=xE5YmLx7$NY*%X zR4pm()^IT{f1v3VT^Z4=eKULqzvDE&o;RS-QU2MNoTCbVj>$Edt#$Gs_P%HB4!1m# z??0hnw;NzqI9M#aCM4lh_DM~VGwNsoey!Cl-CeUJZC{FBa#n@gSH-Fr)-w&vcPp`q zYIAA7Q`Fm@egjF{EZ-7^h03E%Yz4LD!?|Y4PUeC~!avi3mR09O$;=Dq;>vc2+HbN3 zD<0i^Au|kf2Fe8P`uPfXd~9Xz-Jj~XN;;&RO}C(Z(x}|PHfap-Fpm{el!Q;0(YBSW ztA$TuyJ)*t?N6TgY+Sr<<`$WT&oaGG08r>TO1I6DV(B{eR}h3|JIJDX+zOM-b<<}p zNUdm?doj6p!eids6Cn|{pIN4aO6z`-LROKz8i1L?muIU`8|c8E5z~49Ynl<*MW|lL zd>NZEUb=aopS@_k&Z&&g!jnCxqb5^mQ8vZ=sE!KL=;!@1BAFSJ;RnqgFXAY$_;A(+ zGaYyR+VQmpwrcmnFNXi}oMnGCpZZ%xX!U@o%ymxW)cnbV{tkM7vBQsz;>H6QuSKd3 z|LC^MZ$eF0I_;10`?|3vqWW?g6`V`*RtKhqS)OV9u{iG$tJ|!+#!*5b>A8?c;Eq{&9 z(J;}l9>1Ckl56K|c}k?-1)8uq)Mh#wJ&4{GTS{3osZ5&2C0$3xjqjSuNhinIf497L z`IE!>*gU1X&cx0x(hN@OsS6^!4D#2K`1q`Mu5()6 z8Q8tXtz$pX)FX(c;&~cLRH>(+`$31<;RtJ6-|6VKh2c9Z(;_OeVNq5)@{G8a$;#{2 zOQhk+&&mHEYi}7>)!MFaD^h|IO1IJ-Qc8n>bb~ZVcXvs5cY}a*cXulwsnjH;yZe7n z*R%Fs``Ph+c|W;+OJvS5#y#%1uJb(3Y*Dn8kIqAJe&wZxQl|LB)jvcb&)=QA7Cxqh z7NlIdly?wv)=(W*QzIx%xS*l>sMk`HS_qMI>Ht{=AdfKOR~>K zWXLL!Iq_WIb)qmQK8#;Hze;3AqIx+~&XtrxcE-b3;-$6b(NQN(5ys~Eu5E^>o$!w7 z-X+@o&RKZm>K>Xoz1E1#J8rauf@IrvW3CnVPM0n^j=gLby-heKqyIn?YeCtO-Fn(g|(uLLAzg+H`C!QfCDb_2cNlud6EK<~OJy6--iVZ_Gken+) zq%Y#%da51qm|FqcV^7O1r^&|du*HiD7XCC~z!V9Ap-8^tQ$W*U>M)(DImNeuXsjyi z=f;~*J$UH(TxRS@W^6EjtHn$XkV!tm%Oi}bd&h)KX?HW6tFO#iQ4uV7{7JAeC|g8% zR&4a!1b@s5F&ux&C)nQ4qvTvh2Zpeg%uh4=NxsBBL)r$Lnb~T}eWjh|X_=+Ua>aae z_TP#-2t0C;RW6{+a|n5b!$lqs_XOt6hz^}3(rWn!BR6z6ClHnD5WEby3HJqFHrq{3YZ`dRpOkgl zNq(9wQsiraU)|fSz~WhRYy@$4CJO4WHKTB|kROy8&Y&bzRTcNFHX4n<;Hk3>^04;k zb#tFmlUH*bjhm->v8&Y@LDkurG$_qYc)9h7K<7+GP1E-^emN=yP{F#vX;&DoV;m)$ zpG|~k-o&~kOamyA!fJ(JroA?RWPgtTOr`T7_B;hBCdtvsq~xnpPCz{*s0HZ~{t-^n zrJLG>=aKF8%srCj@Zm}*<4D+QKclOqI&;>u!a#g8g{soan~*K;^(_ovAGK=_qT6l4 zuab~FI&+UtD+lX)7yTfOoh@wQtdEqQCyx6AIw~C1mKdrKe%+)1jvWY}9XDX3Izeb- zR!qUhUVMVX`HD`B{{!Q9RuNaZM?f9#xpV(S2ON=F=m$c-z!38UH7y8T%0^mOZZ4O{n1X{Nwg8bUVFIz|_0ae!tUhYL4n&OP-`O!}8 zX6j-a`TafQ`{ENr8mDcgi?!UBSYQ85Dj8a{8dGaj-~M7`B^yAHIvrxFMmRW081{lM zkW$fp6E*1RL@61b7>hW^l9j(yHNkKRs2beH?hkl+*eT&Wq~wF-5b0J%X_U-xEX&aiJ+ zo$$Slkz6?a;bC-I#RO8(a)tWNK5~zW$32)Ct~5C6_oy&#kG$^$58ZH;0a7;ECy zuO(KbcBED&Jucrpyh^%AXsN?`Ic|6HGAO4Czg>L%(QwFG&SZE4pLOP%c&S$$4@X)< zX1;Q9+($omaA$=~t2Z8f#H9s3UJTinQrj5e(mVk6e79yox_B+TQ#8XSg0+J}>vyhM zT>!H#S8Xm+Q@#uJpU&I6h$n<9%XRLLkF)uJ7-W-Y6t(ui^P<^8Rpz4HD?Y z)64e_wZtANEU4?<8jJeEoL8Q!bchmO9XurYy=NZHHG3g?BK=|cj)b~xLFk8mtgIya za?@-EIiYHB-%!!zd#YYTc{4x+O+LC~jg1q{RkwIOD?>VZ1s0w7cZH#}Q)GHD;|6DX z@;rBrE8LOI<``(~m6EB|v-HKgk}z}P5NA&b5Y|%HH8L)k{f*2eZ37oF!jtp7 zFYs`a?Z)jF%sYc8YBy!^(MPe64x7%gfTNkN+HK~+tVag~lYvJ+dm2uGv3s_(1F{Hp zYjpyDk-W?AOePe<^h%bg3cYVk{&0HfrD}B>VxqH;$kk%9=JnRCGVEik8rf1$rbm9a5Ub-8+D!)HN5+1dSA&Z<(3;8&hj&l&qhVg z_&@qgAc|*092wGJ1V2goiDNM1xWcr45ENY1Z6JTSOh z+_jILuax!AS_<|})A(_fDY91F8kb2^tD0Tz0Ui%Ns2Kvc+*Knd(7_h_412{{?wm|$ z0+a~$t=R_gpBOAPlPn^b&fFRn1#Q^s*Rl$1O1%s zUhmO6p6o*s6D8QLL2~SSPU~gVrcInO81Uzba%sd6{a?Z?YD7@Z>}38O$j6{rKqvk* zZ%#0)79H_95)^}?v1u^qFTOZkCRuX2Y>IYqci;s95_U@l4W5Gx*KKNSY3U}}Wg_HX zNyD;RzuV4Atr`J732TTXt-?0D>vhOW8e7eV*Hch^ssH%qU`O@~$R3!=8Paqdmfvgm z*>G0Q=m{fUEI4F$fp!E*;|bXas^{U8dLU|U9*gSmcZ+PcZuToW5?XIZR_SlF_L;le zv+}abe*ME=})`m0Tan3nHI690t0ZpZ>^d8U-KivUL-n z4fCSkPZ7HJ{9fPt6)$QU>uk1NeYa{V2MU@WZgi)TOM<>7MO*ft9$nLL`iBTz02V+c z8f&Ei#is z$b-R(_a?9WLZjIB5hLcV+5EuN;8_Q}l{H27>spn?&RS=x0?~!|fWAb>rOyYByrT)P zJkz1okspoM@~S9@WvrcMg1=5Nw9_y^D~S~a2t|Gbr0RfmX~sF{it^7a-1B(#vsQ)) z=|}ap z!~3huhqtrpA=>EK_zl2^iDEqLYT6;!4z3OebGQ(GGGbrldtFn8-&H-cP)8Za%5sCu zI8#aXcrUK=1A<4+h1IQggOadN|0ixvGOTt7HLG_7KTv4Wk9~tG(f@R>vf_t-7to4B<(n~&*x$XIJ^_vZks3S)plY%N7VCY0GcmQV6W9Jr zdYOXe4HW@fw%?uGEoUTK0`9)lM?p+6#5hrK5$nu~NPjDS|9Uw8E^7T-1+BVa|Ix!0 zbfB96sE~8s1aOmQm$%hk|FwLihdyFZx|lU%Z1g$MK(c@T-9UB>{dGAuxGC2VpZpJn>OX!tc!+-~d0zq@vwqh^HER259;2|uu)hoYgh@% zp!c(V3G&s#xv6L=G69yJ5aScf$SJt!0@kfJNeE*S`Le??QX-EDE2zq6b5trSWMW-&l-Is+38`u}zzf5FQ5HPL{oT~nuoKHB4AVJ02Ope*y# z9c|wjehV5Q25QsU7YcO$x*RvypD0FPU|9k#jO9&JkxzOkRA^nlr)2kken<-RmYvF{ zLMQ0E+YP=*3?Wdfvw<2!7~|jn`s+^c7n6LZOob-Gc$}m{%;R4drwL{;frn4^EcrE} zcY=@(prkkgq^!f;%|+x;oB1!6dXRtE46N9#>)T&o{<<0elEwc6#Fq6E4Y5mnyF8Ey zhtpaIO*#%?0Cb&wt-NmLy4nIOut%pxfsa3H>MfcpB_bBx$E=HhMSP3zk8h;aENZ7_ zi!uPg<2e?i76CV~x-Q%|fSk<3Z`VY2-Zuz$c zY|HPMz@bWm=Y->hc5FZ}s~;Qe{uZC{|{ zrZLrc-T4P9M?ILD&ipRG~}{9*=FNn@W?@Ql?@p|5>W> zh96@vfki%ZvGVD`N1O7>`5iI$IRH0;b4bYQk?wK`~} zdbPS}7RONfx`Fru&^FbQ%Z*z4FQhajQ+x!yUVARF9u$R+p>F%(f6}Ab|VUw8mw%*dlmk7+<8 z9MQVHQ5}~${lG8A36;^#qLdq&)H~9PHn8Q%QJoE}M3r3Y5jYIf*V~7V)^qoHry!eV z9!%2_Z6?pEg7d(i>iwTTvc7X>!CTn-Lc8Og3r-NiyCi)B#l_%akwl5D(3`)yIamlx zAN1m5XG?2mrSRG`V4Fa5`Napa4!3W2>K}P`00_~0TYFWT-Qo% z)?$dBvT+JD3A_{N%(1C|mv}h$4Lxw*dIF^eUE$_WsN#3}ABx{5sN&bhqJDw>I;T}~ z1b93&&c6Ew`)BW=D{pAq^kQ~`gNTo{SxpDG;33`joMc>#tdEg17l2{*Y=rydTT|l9 zkmk-2P?Y70%Ym{)h5aF&cL!s0q5}b+r#r^tz0w=1Bo+g4jJWt6&(z;{nj(J-e~*r5 z#!(NmqR51K{CbAR&1ax8QHaNqHv$csCaCO1&tP%4B`qU)6b5aC8g`4UQ=dPVLu~L&$ z@cP%Nr?M(DGuSNY0A?80h?*)5bT{>xQ}!i-EFMdAp_5IeQ{|y4eT$^-f@Sf=Hz9!r zBlm3Hu*Z*mn%5da_2cj;pzO75`;*g9>&zP+@Yr_~7y_On7JC)v2{od{x&4nww)ReV z{P!1E7eG<$;PN}L_$=)d@bi}}kw&4i{}`*;1mv$3;%-`I$#}S|1~J*`dAOyMK=9;SW_nr`9)L-b%`ujtm1*5y-N)~I z0&CK>2ZjWXGXS&Y+(03bQ!HTl<&pc?g10pFcu-GP$AQXBwu2orL3vS+=lZew?_>-% zaFS^sRi9DoN)Ge^B@*xpS_NKc*#8jLoP`tee8aBe?@YgLn!t%8IuBr)KOp|tS~%g^ zILXWDen%KjT0ji3=pAAi6hczC__1Rb>{^haYf`TfL1*ggMWL0mUZFlIjs?ZRR2HUw zZ*OGXUsZnYrRI*%H?uj<0eENMFK-sRkAj2`mJT<)oVwlMnY;l9Twj0x|!gzy3F2~r<$Me%hQKk3c+ODT%OS5Y9$a8%-CFdUdhVgB&A5( zm_A^Hzzfd~%XhgyWaw3|PK2SDyB~MYUV)V17fg<7+$RK| zM)#Zt$rIn}j=bBUYo1yU%J$9k4t#z>HclSpB%qoKXsTAS{MvfM#C58jsgku8((aP* z&+!yHI}gVyFT7+5pHD(vtN#Hvg)Wuf2@2kR@g(TQ!27rj0kqN|GJ59&JxJO;814U> z`nP)@$Egad98A$#<&hFyU?6}wy<;Le%TdDuh<}_<_PI{?Le_>lAo?DW(ZCr z$w$l@LCCb$p=&NcB7}frnxw-Tg#`hewGyxQ%t`$cFd>}{vH>;R!}CULZv@qKBz?2y z)0p){_%p!F0u2Fti{u2}CQ$=(N6>9L_XRJ=+2)18Z1V?=H&j7*9OsP12iF4TMY$Tz~?2rqP^YXFl5rbz~wU6ed2KbywGqY&7|{- z^JzLT4GH&I=oks6{6^2Wg0w|*Jb5FydjBUd1xWmbd{}qRw>b5!DmL{$Uor^Y-8wK3fsQCB2Hz7b@l*pp zzQzIhQTE-{SeeBwCYE7g=O#1x(pKx!E89?nkHvDAqjRw3DFc;O+e((>)dtOfZael~#`*zvvD31ha= zsCovoas~D8X?}UhF|7V*5mu6lGVMzm1x|DpTG+;_cK-?4K3J<+Rxgi2)2iVJd_H}z zqwhdWWd;7+@=aC12*M>C^OB^V*#(bl7eV+r($M+MYYTOD^W-+<1N1)Dy0I*}!)}!r zY}|w6Nw`tOFmIQ8coc$cgSUKbUJ)F@rmMDAQ|edS^}he*6@tD{ip!rL6~V}^pbCdhlxw#S z&}0$^gLu|bll9oVyqpHAzgFp}UT?m;Et$tixg|`l6ezXt5F~Au%S+79-pSqnsx}g3 zSXAAzIuno^y~ugWu(PK+Z3Cj?u*g4xVnZ2c+hdq$U@Do`I4U6kmNvT@2XBM0PyX>u z=kt8mv}bp%b5cKIYS$mrYO4-v?J=4ZBgXNM@?2;z0f1siSF$Z3xOz-sG+MXnxKm}+ zwj+>@VleewHejy0gmlPOJETOiFP%@k9%^EZffa$P!{f|208kgwayDnJ!<`*Ptk@L?iPFgP6KIN_@B$0`Bpsa zg|s(cbi-|f`tB?S-)FPZ$dy9IKl`h(d4i?%?#$W3#yPP)g))!XsVtIkY$^sxxs?7V zgI61wR_}rbcy7UBn(8LWPdy^O#B$?OjRcANO(kJnOjMqVi&BBK;AMEhOvV2;K*0aO z9psY4H?6l|6CV9bbrh(ed+Sk zV=KV)Wm=={6P3dKrIDq#-fyYu07O}T~|Ca+CoEJAzTQ1 z62x_tA$0{Rs^E+Sd6Z|f$j7;ZA2X#ELFNlHC*pT~y;_L-)EoI~IsTE@j<)hw5Vb74 ze2J}+kouR%EtYynu15Wx<7xa(yx$vXs4>dY`~s(!cdsVb?Tr${|cta?WHu0}n% zG>ocN)_5*+p`KLSpuLSU&Dw`&$bow;N~o#lVj?8-CWK?&uRn9{3^;42dy|$*sz=11 zo7vzw^z^cKO+Wvm8v9;_iQh+w*rIcA#wsS?mZI*qf|JRavNAay(rhZzRhs_{sYDXo zX8Ghs72p6Wn776L zpL()akL4}Q2*a`^SLV72?8gMosW^dABnJ$OiTrVd*t*4|_?Z z@rK76Ef;VyX^NkzfT!zw%Ljo{o_${Rx!k`==YU)k%)YmP;;H_*&e*T=*W+L7zLfr% ziw@`HP`9#C-+pJYLgZs&vZQA*OryFVu zExHb*y=bWFlcDw8Z-y6L#_<|qqg}tVK(SUz$6(kY`l+MuP5CtJWmT858+;wbR99bS zB&d{qQD);7K!0oaE$NXEavfGszS5|f!r>>@&oS|sYx92!T{46~wKb>xOTF-8*Hea} z;`n;-OicF>OrR)Z=oYP1BfKp$|9~R?u@&8)6Oxh^Szfd~st{ZqOXnk+QDXJ7Nj>CD z7I?Vxh|Xqy`Se|)MOjIAm4|bJRSNxHNUMRWbJ*jK-mYIixJk#n_O!SN_&`P?B0`(W z${Di^%BdG5_Q~?kgf4v$Te`5)H!<$8<2hWkH|hA#`wlAjLyy_aGXm~bu-kDO8P*X< zX!Si$bBMPPbOM%zi6k*aJY@cClY!P`bc`S#@id>WI><>Rz!#(J^&;YUX{q>)|p_x+dt ze}qrmE>pB&jeV3}8VCIo!dD0XiARf39_gQ8#@<=;jXTm07)Q}%Gw04Uo%wA^+^eGe zvEmRDLUkI7W2&E*e)^63IT`i6ToVN~xfnv8ZJLY*A84eZi&!I%;<`M04fcOoi+5RA z&^_8s?)h%8+tjtCJT8=M6XN8IG=j9w*XTVa^z*|Ow{I$ji!`gIZ$ z#gz*P1(+j(1D17*L?chmbnF`svKGI@e_PGR^awU9!_>|ZUhZ#xE6Ti+JX@7X`|;=x zr-k3j`m@syC|NbZBl8^IaH#t1+7yV3(g4IPT9B{ovOk`Kp+L%-gK%S)IzR1GB&h*v zG2|%8z>8`Fog1}hb(T$BP1{7$8AJ4(duw1wzANjIzz;oI`d^U?DlH0uxtC%Wl7r!0 zY=v)}p0{5%>M)D=H zsfFMFvwQ`urOX08=zK|E?-aEUzVsX|6KzXIu*|>S!0?q0pd5H1h4>etkNpY4UjiLb z;`n90xWe6Pb8*XkJ)9`Nc4|hbLYEs7hOnK5 zBM;%!;e4RA`*Bm}I&<8KJzh0+Wx;~I=0_|Oy_Hmx-&+kn9q^4ybGe$6-Do= zmKre`54U1cR)zFX&TMPdT~>jB0R3H?8X?|M3($mdH$?PX!{}@G>du=r8GssDWay6NMoT!4(UrD}Fm< z&-`R#oS56zVfSovXh|`$AuPG=Gr66BVU+IZikA6p3#CkkdFN}rr)`gK*>#Jb@wJSc z-O>Ns@)GofzUwiYqP);u{lhtghJh8jt*ul26{V=Mpg{art&xrMvzZZv=ag3I4=vOD z+1WzE=Sa}{83XMSZA!o)EcufVmy<_m8{Yw<ov)Q_9esAYvoJRN7Q$~>~0f2&)9HSQ>T`%^nXl?FRfzA=N(%M*JPPRzs_ z6|UVvh+kiMbf(*mU(Iu#57ZTD*ZpGGOo(2O@ZRi7w$LqrQ(i+%fLF}dC=l9MMof3q zQvVF;_|FTaqf`UIZ{zVOsXdUF)|Qj#w*Ag~-f(!Z<;qIa4t85Dc2UHumBHb|qr5jI z3rM$n7Es5HPFf0Cn2>0oi1gHUN0M%UnofGZ8|eXm+_9L?h7YLwGpoFt8d5IbSTc49 zOH4jE0iCH|7ZUTROUHxar1We^h-Xc!q!V$ZWL=--YUE?~PMmPUNLgkT8{&yLxz zy!Bd8>m>^C_yB!vOtbMn(PP42ki+pbjBjPx%7{rcwsr;AJ^d2B+T}K~1wvDqbbXK) zj#a7@F+g!gcsq(}*(!ZEOJhlZSW6W@=40IAacP#ipr_es%5|5X8^c5S)o-vKlo znhoS}&7gz40D@~Y3O4t{SL!7*vN_QD8%COgDpvs3!7jUt&*^FlHCujR0T8np=Br4Y zxEH+vup%G1zR^1SRVYZex9$gwi)l>XDQj|&hFFTC!mU_s9I9AomXxZddx7#B`_%SYE_+FT0)p5U zR-;O2pwH_qT65-oB*x|ckzO_?Mi3R~Q&AfYh*ld6_D{Dyc6zJ$fY51EgYE}kk%zwq zP?i`Pq9#nUwM2%oFeU9168#VNkcT;trdYf@ zWd!HBS;TwXF#zQ`BZ4%*k_i7B%S&eh9bk87}?9rn_5c@uwrN|G@URCWOv&JM-fATnuYj9x+z z6~z)b{2{W+&i(?j?_nBih#pbb{sv0q)C+_H7U;n!`g4-4Z5P%3}VD zLN<%-4K?4*>NWpB3Og5;Wix|=a-fh(b6JqQM}+=U!LYI$d>@;6n`^sJ5DUDrZ=WGb zf|Bj7=XrJJFN1O-;7VHscoSJWTxf5&3Ah3Be_w`B!MekWgyEpOq?{gLzU2c4g$00~ z3w{!(Nvm}Lm>oBBZZi`~1CbbDtDt>otaq*y(692pz{;RsQWf@HU)H0G zICC@W%jLjkXvrARX2I)rMmIYo^)C(;|5Mm9P?>k?K^JWRX<3a>1m1h`5E|GNY|x5k zwVEr?|3Bpr_Czp*y0V9024OlDuh{yU+5~Oz{%}N4`}NC3UnTs{yHFa@0qsy;K*> zC$3T2a@%=rc_Wln^$ws061i%Ul`Q@mTE+;lfEdkk!3Q3S{hWDqxEqk>%w>xg`J!zG zfIfedz!&`g^QIwsYYAoTJwpOCZ5|GrmG>85^!Gp$rhrJIxU8vY=8Er>cyM^K#C1J!{FEH*8A1cTGKSU*2 z_2|aPzCLWzAG<+sUUeUu%K#KjGxMOt27NEx@YUD34 zn3S5$ic2E0B15k!Awl-7AO9-aPtfRC_*to^2^DNfCeW+@K8JuQ3oN!A3==5gE{U3s zHqicWA|4-T-6$Ptf+s!?RsGe2j=l1VCwL~7BWZ8<%f0T*)-$C2_?usk)mv#pL4(3m zdNxB~XEj$_RFnuE5Lx&z=A{GEornhyP+`+MN93Qw9MW&sF)ly@hlQpWy267<@C7Y~ z=qhZO*1!(zwnP5{h$YzA?Ssj}8t4a-+&~(eYdQarD$r-uiIO0i{jBnWqH55jBVY%h zm=kvZwX^!wRAb9kuv6JyF_p5un?i8jfZV`n_c81pRcZ zyH;=>>jWjhOgzd`I^q35kx!kVAma;~5sfhipm>Mt2d|%eMFdDroge{5e#Z^GEJl5d z@_nuW3!r`KV;%Eu#rJ_R?HS6F#$pRJ_I+7cyWx+j0y%!|Pv@(adG8vmC9t5Ys5<5B zG8{`uaH|f64}Qu9XpZf4tGx}Rof^WSL7`c`1FF?_(|J=9j@6SYkD$61Fy;6Fqducg zsLg7+)8bQ{gSkDz>9D<-AQt9~q{B9g_eA1vZn$Kjn2jta&I%wxnmtr`do1-MY!4mp zo$`<~X!)@k;HIK;#1}eUE9Y1fvl`2?^2u&JTO0%$#_{R9FFTl{zepNxW$eqAENl;7OU$s?hb_*yjbSysIXbhte5Ss395P0j@2p+Ya4b0*p$}^Re zP<-+RbXT{K#S_46l{O(@j&VDiQlSkYgzvI$?j7G^|3uJ}Gz!~2FS7On-{jNe5on=o z>A&^HbpMR)vqsRN6l>FWkC0qr?j1C0i2iRP-sRO$@Ad4)hnLvVfo7zHisJ7KynL6`j0 zN{ibD1D(RnEjDL}tCfBy_<4qE2$Bfg8J$pd9vlS@+b4aIc2)3Dw$-#-tX@$eZL2!H zp)ptXh2gGQP7gWge7#t@9V|yWUUjfmAZK^K%Ap2=9(GNR=N|iCLz#0QlRr{eRxhyt z-3gKqL(5@TM_4TLbRWJ(bzJr0Iw1awC|Y?o&v04fsobh(e{=5v;!D}(L+Cnsm(XRF zPtSYVzMKBE0&}YNzCLS3h%}Otdnm-`!M7w{gRtCbmVV}vnG4D2V zw^!uWEOS9L4J4sXP6xH;vni;B>}|u3B$h$U!B&j>7(x1?H&Dtg@Sj|zuXjqHhz({5 zBgD5jDQ}@(4a$>u2e2=J47uuoYnJ(!6j14p(D3#*S9wRXqnPtAtxJyxjNuU|q*5?i zpX>s#E%yUb$(pfx;(7=S_hTiT?3 z{!qcq;Zi5zTD-2WAeKSsn*3N`whOm07#hk#2<@e{uO$R5Z*F(w<5Z1%a_f&FV0n4x zPIqIuGi=eQLwvZte{;4;v+?!Y3>HqCWL;h)1>Eh9$wt?=7O??q!R!dOdV62#1E9R14+2GwiB*art!tUe#k4hU+Dsap zO#@~L7@Dr4icvc&WQ?aE4K+UB$FWB$_7o~C4X!5+k9Q3$H1Yr*X{?-1aa(%_Umx+R z`eU9}%Ao@OAvWY$5$aOZUv5ERqw0+#wL@i2UdY?(v+#OA7Bu8199>g8q<&z}*nVrP z=z(i8!*x)WlDWu3SF_`2u8DbLYm0f6P<0TvMi5%(QA6U}Vr#I|^jnTDPCZM3+9T&+ zOS9uQJz0LAg@uHw)oPdN+2M1f(|Zuwn~I>uuSl=ye>260MMK6QZ(UXc&MTs?awa)`EIlI-D3q}7bfH^ zHf46N;NkE>%YjsS^NKvL;n_3_=h9~s2g&KH+*oO(T*(=-!t3b6nEseGWdTsoN1POu zBAU7aLcHCm_BxgyMckqJIdxQG31;n~r|sOMPb?O`kmOay?-5^s3gD*acozRmsfSV` z07>_3Iml#uFvukldQWW->oT1(ef$fY17MB>En}y6@sQUvbH`21T~LpYW@z56=RZ}I z^4z&oI^f1L+slYoIsGU>T*VTvJg)$Wc4t9~4+GZdFlTBZ-Zu@^tY@4lw3h7_ckZ?P zlARn>W7P^4R-8NY6fNtWVjgl9$?1-&eRBOmIJ==$LPFjic5MMnb^!! zW0zm=Dg0}<8Ap}tJoo`^qjlm+E8qR9D1Ae$*k)`aa8@cL+0@|Yo!WJ4-dUu}V&|>> zyU`S7A{@G(Ty`vst#4>A;o*d@Wut4_%vEnP^9pM-?MvUBuocp`9;!-8(+jl5pUGfTF% z;A+q&Fv-H)Zlcheq=Qr&27NuMoljC2wLP&`JwR2~cKceeI6d7|ZuO2YqQxw?m1F0s z;DBfOi&12lsAc1NLe(f5ZO)sBT2F~!39QqMgWc)HJ6pVOB44gE}vuBCPplRcxg4|;fgo=#iWCz-k%c# zeSpEg*tC~RNP1}ZTH{N&F)4U$)smkWdTe>I*4cVQrQav@c{_4YMIj4Pld_sPfk+vw z*$esNEqX=uWp~ha>Micg#VKbs$(Uwvl+t=}s#^?f2F)3caV&}g#4b(csDl26I2gu) ziZ{nai(TAO*{KwEvutldq7s8@ZtmGU%zyQN88?af)}DE$@e&8?v@<c%tnXu}%^Rc>c4zsC zV`5`JsWmW25_Ze!sAcw0yzUZZC`+=+ZQ+sqRFT>NBW6@a!A~_^@-2z5liJ~2{s*8`ahd=i&2H(1!hgF>lN7SCbiZ9%VtSH4Yk7)=>8?2dj z0$!=w)zwHoqE;iQeLVUj3tnZ-@1fa56_24h`s4B)jh71v%Ka^Oj9c_n$?c1Y6Adxv z8F?2xE>g#Gn#rVhPkAznK^BDT?qWW zN4gpBz&3Rbb*pb2au>aczKIFf&c~hlIBs3F4|89C98Pj6*ES8x{uE@(X*YFYJ8laj zF>o)ndds)j`eE)jTa|gLkX)ncGo%_qJ(huwqIOs-x>RN}>EEXLt%1u-_!!!k-Njw- zpDUt0LHyNZNt|zCjL#Vr`2^~mKb4HLA^f@CjnblqP!3+74{b?1^~&^vFSt-;&UCF_ z+FVl=#%YCQtObUS|E889Zjhh6Bz_PhFUZVP7D=kI2b-<%AyWWI!|RJtr{!?Rtxhw8 zD}d8}8ke9PfIOHLoLSSbUPcHGN72~<>p799wl;fD7FVuCr9||PVzPqo^`oAx2QU86 z{F?S3{b<_okRFdLa z-a4A$p>MX6WKN~)S6ljN@rp6+VADVzo8{^L(4x#>7Um4pi4sMHM*=TxwpFkuiS;$~ z4YoCC%jq}Ul$mB}jCv=qXw{a@1y+N+ARJV(1ikUE(jaw19E~tcg)LKl^%VWJ+p2CJ zb8qBaX8kJS4&>`-sbos|B~D~XdTX~00_a@7=DV;{k3X2Y5aj|&3_*snk{MjKC#8Xs zSM(>yg}tuBODwz#{UmZp43uZ_qtkuD<4D@bc==Q3rdDT4bAc)s4vdZ0n&KKR?M!d; z!fGqEY(t38!^Bqu2Qx1|ni0#tt(%H#piJD7_mhx|QCw0|2Ue6}a+ ztswkJpCFvl$AeSNJoOk(!A3o~PAWEiizZV<6zcSMG9jL=b81{g+#Z3KdSPW-t?Qsp zHD!X)qe<%o5+9F3XL~qiI>Jo=$mHWAJX(QEfe>J`y zqV6f&mS-xqbKwU0EbNfroxUaykz1HdlpJ~OQSf0_?OK~hzm9vCiaaUYtq=8#9G5`x zO;Q<~1^uXWEQb}}n2&mRDPHXERY8vDTqed0-fHPHE-aUTsqw&??Rl@6ajyEhJf_Ae z-gh(N?rwbJ&3S{V+#^6ekW$l)mqtNa<+GyQA-@%(vH&= z^(-9av_v6emRDZn{k@&I#nw#Yo6);>{m)N(#qzEYd5Gx|Y1>hbQS=3zfuw%qY`!MS zUF&P_!LFGr#b!F4Nfgbme!!WoZL1x~oXO%pI7qpXhs^x^vV`C4$728esbOiuI6{sO zKf}gQZt+m0hGwiv4e}lg!V*8N9e=R_colvOo$)(f>yo3?6odRlK}lji*H;(iSF|-W z%X$~LQw#DDKhJ7%!ccct+3?kCljEv<20Jt7C-3|KZvx#$mS%;Y(*1Wah9Jbw)V(M;M(93Oi2 z(~I0M?^G?TB-hFPHCeQHJP$yjYKS)lvDN~aRrO0t-jZyAJ`^&!&BuN4 zRmVMytY5EYE6;o!J4Y0ASyP+w zdA4$UGt?iKE-!v{VZV=$Vcc8k1?hXWp3YiyLa8(nXAKReWxY?)%09)e_VQh#L&y!n=SAKyQ zW+q!FUzOS`Nf;4KR`WFk)uVhkN;SN!?0Topx!P7f9v7ERj8D6kPV?$pEYo&K!I#R` zI}uRJ?z*-{O!q4W*mPHXUuhlGSHW9fZg(m|RexZ1G28PJx6)$F-L1Nn^c>XPGZT?M z-(R6^Aj^+4a^Zf8m#8RmOsL?%DpW;=ofkId7Q0w%E*X^_3ftL( zi8HSHZ^yAGsJcVC<5y^cR2R{nEO5 zK{vbmF5}{<4NbB#r%{$FM_I~JRiMSx-k-!tN z*^oSO12f^Mc3UxGr-`pp67e&cYbO^--#^KcI0dAHm7gcFtCnLr+6t5?QGK;mPOqtw zJEk#yF{L6NUtEpBnNm@m^>o(O=59xKtrCotdmBAkIx@q(~|qy3BwV zsRtAJ|B?3AQB}8F7pNj7t%9_mNSB02heaqU-3mxai?~Tim5>Idk#40ML}{f%8iXwh zBCzSc>!+{ZIp=<#=Z|~GV7z0f`(^*)dDgSmTyxC{vWUtyHThIlW`Vm&Q3SdpIcekx zXN%b$#oMT)R8xG%(|MaCTYJGn&O<5Bq!Xt=H1}z6;;W~-iACCd7Y)vtz2bG_)(2DV z2)AH`)cYo}1)E!){pp1hSJ255ke|y5)UHtM%V(6-N@@!ODE>ugvq+1^<)GbEU=p)< z&n@E?5235qrIDqbFm2RnIVFwY%~&{lC7pDHdf^9`rGJ{g<4uC5 zZq42xDapb|KRHcG9XkuJ>_TbA-~4vNpw4%J+HRT1YE6M)_JVV9vA;{YTMP zf=aogJM^DY8n0mYSEi;s_k9132tUTp@XW(cTDZAMx;Y800>P77+|QEZj$*EymLlaY z&zp1Th*HsM!25VDssnLupRLxRcOG~xNf^C-e)+N|*$Yp}=&qo2jrzlin;DJ^gUcE> z!|ifvVH^0EGIUt0gk_L2^Qpfg(CIt7e%SdNbD2~3%QmXgi&%$lE0N@jp`f1 z{3vw{T0c=|%|_10)`lVC?0b6qZP5-%UP%bA6=~hkx9X^Ng6jLL5wdqO%~y-Ht*bVs zizUR=W9P&|Ci)W;iapB-^b;=YM>yO);AtMaLdk9XHgqD6&fYxADCYGYTzN+(Eu|!@;j-P{D2mcM(##I`quHz_e2DO znj@EwEV`wqOkO5gp8bF$?TNK;I9xL7>T#!({3Jm>X6cjXK%`Ae5$>_3PZ>O$Gu zKHnKm*RKS&$}RHa3(5T0AMYjP2yYUTnf*ApbFk6H#MCQjcY`Hz?oOMP3ga~vLUhZi zx-mUCwHc|`ZL@?lXqRP@)vnf-uFK`xZ5U6zUpvK4I2T2m=ld0h%i`9Jn!>cRq;tfhU7g)& zoJm@HF%ciF+}wDDh&~Xz4G-vz+ zE(&KOo*nT^_UrpIRGgdNxWx8`o3$Y-2l=tX^(pFo-cRgo=XXrov+}t zk)~}t4%;Qr$rwneAxY6NxU4l{bjc$5%hHK}jdyQqsL7vQ8THbWi7bkKoIW^yc0E<& zQ=&&kZQ!^7y2v!#dcf3>B~3C=@UD&5qlp)49D9~!n9Is-0w;N_9SAM=?!?oL?hPjU zVYE_o6YkU7Ov&3!gjL)&I^Xv!w67M!R`2mFh*I~wI?uMDcs|_}MartYEE@eZUC;Q| zG6O9{`Qiu8{zaG8&9WczBs|C?8B{)FuGV9zX5^N&%jpkwl1#>KSw|f#{ir_q_w0kq z(8_pjk;Bcjpkd^N4(Z-en3qp0xKJ$jc47H^p<{-9tWUvsV8d&DAz!SGEWr^Q-aSXa z__}R^!yHvm+j%vmr-iwvK>cw@3K9mJ8sk*m20=TiL(}@r_Znf2s{A8XjI_5*Ki{>D zK8W_T#9Ud^1-P2Lk)|RYJJRQ7%O(Dsw<9})u{z2ebZKg0t`v|55)78Vj8IMS7c?t} zwaygL-j{9CD|xZXG$A4(zhZZ!cWS=M&{)Cn~Ci08WDzaZ;GGAC%5Y7O_XVKi{zGdE3E3i&wR?Gu&Fu*_>`+W zMX5h`J`=D^Ni+AlOv-wrZeAx#x_Q?#wTCWrU;l`akE3_f0Chf2?jomD#aJsy=R;mYu5N z#|`t&k?`Fwc*f;9+B+3cc&eKlWz%`4uRJbde0NhN@d4Bwxp`-ag&eyw&*9>nWO}}P z`!MtJ{TS=w!(PISCPc4BDW2-n1x^RiSk7tEL;GVSjmIhXL7yqK92<*p_gal(3hEDkb7Y1Q;~3*lReaParTpsq-OsY3$rTrlN4GCVWp3w3s2Hg>sZ|IiPDMwqFKZG zfLlE%zSi#N#pwFDnddBhN`zb0F{%Cy8rS)|UH8k|k1M8FQxvg8K2#(SQp8#i4;d5U zGkF{(7Du?MP<$3n*3qZwa+)eeWJMh9k+rPM88`)_a+AXsgZxYP+PBN^F)c3Kkg6NJ zR!DWQIM}r~LYf;rn7tRh8`i=>Xc;KH!Ayv%ZBx$;(k$-SC?hH=-VXtt1+91ujDjdH5zrPf-@C4uvB^pVIb1XV0&z4WhcWX2Fx+Y{%lh3sex4h&6 zkarKfbg=Sb$!qu(^0^+i?RaBVeO z@B25m0=D^`#w$$)nJ;@Qc{4VlZ7jyt&e5LgcBAh;j23G(R8*UKkd|&A!s><{?&(?H zUHN9KXbhDkX=?f7C96&Ep}E<@%Pjro;SO7yS@Uj<4GMHBj&Qrn>4t>YmXRp5$D`fv z5Xe7)+(zG1D~%s}+uC|LHWa3%@wLhO1`xi#6t~zDx-!J#NzYounIEsC)eT#!&k$`FZo4{kWBw3Of>}KgM@bw#-J4N#c4O zk&TH8W5uWY60e`87{=vC(5XiJip-GP%gsMwnJcYe-Am2r8-@%E+eR?f{lJL`8Jod0enz4i2|?c8OVxc!pnsvZ{L zcFa>&Xt`0;df6$2x9YM^*vC5^UUvl9yMX4ec3PIB4a^w(vsbuJP>v}8$h z2a8my>R|A0b9h7S1e|NY!4O4JM_Ypb!B-3B|uCNxOv{es5`>Zy<#iaYMDTDOT6_y z4Y?eTbp=2&bwmV24AdKKwAYGxS?Yq?ROC{}CBM2}d1L?em3bznS6HnuRQ{~j$2WX8 zc6M(nvedj7Dx%1WkntvZc#z^EE|sh>f1{6M3jEDB7PdG9y4{S6f1>*D!#|K z@*FGS4N_I&_dp8NWTQt(j%IE5R-3Q2r6U3O9KHo*U@TlU}` zosws?x_Z%uLLu$g#i=1J!JdH9^H73LygI?p($i|<((o0gGHtPCuLP;sI}sdW#6^Drw6s^rEhm{vCmHRS4n;qJY_ut zM7xkxiXq*dwDsLe#mo(_PH9nU4(cbC{`HvX)R*J-*3luDJ8mP_pJ8sruMA$#jZ)M- zxkP)ct?>hSn?l~^n%V87?j#AlUIm|VCf3=(#fmD)fu|2ew(3wF{MSyg-zd(^Yfedt zk(}GIDSONEuz=>{xWFRBxAHZreL*Iv@Nhxs4!bcqQ} zjm>5BhAh+uI(i?oUXvtL6C@C;DN2hP_w1>;=J+G0CFcUNroGwEl`V7>1tq#L`(i2f z#7F3L8*b)K>0x7{9+6qY9(SdjrvY55emgOa`0Au`HehtAHdwH7ggCR6#Az~ z6bT5>=Y4tWOcoA$$pr$^gzb1fM!%ipoU_$iZo;tLb2B_D8R)>pajlRKu-Y5Yn}Cw^ zoGWXwF)EXOad0`(?erJI9t3 zqGu&`OY5h0`uK(J(?;j?5_y&4W%9mK?F%3708^1ke_eTO!Gh?`9{;0(gs`%zFY2RB zy?vK=wb%7H*prDS1q*elL?2oN%kbM`Do_tpNAGhiL^@vd>TGQHsV824pwwd7vK%AC zw%r$7PyV^{g=j0N9)D(M6iQ2FORI~fFXde#1T53sLHcZAS-$2H7m7W$J|gzSl7))# zndnWvRMNX18cd0b!_g!Is7~<|fKOq%5SJkH#A&X+Ymf>-3gFA{S zZhZ@tI(68=&pCBPSmm6RGOFm!a}$FzKhc{SW$u~E$%Wa>GLJtWxH6Pk4KKugVCimc z2xjl|A-A{W=d6#8k5L-#*pNYM-C~H)!tv60+Yv@2FCr*EUz8qp+*|6^z3&gzDdn>6X!;;g3^Pg&hGKSyE9d)jWubApiH>tWgN|I*3xK~YchDD$hEYS@m(Vb~(M%`mag7F{A{i-Ux z8pYG8V3C(abTZP-Fuw2B4tutd1tD8mIIkAQqa8D#O1J88Yf-N{Q=*MKG1$EC%fX#M zuc1#}&QZ5xhNO73-!z7vO&mK*>sed61}F{FClY@ao{L&#L!-+cRn{od(sfi{2Y#pB z-t|E>uQ*0-#=wj7#%YH@eVH;4y76*%WcbSgX9!!HMfg)NObI;K* z<(mMP9Yfz0e<_|KGQ1Cf7LbMsM2WZ~to9v7)2T=TKAWd2rTw zan!ZAN_|7c?U(m>NZ_rpjYSp@F1qyEu~V;ftQZ8GK6HC&e~U&&GjgPFQJdSgWZAm& zwQHUEAcvcwFBbK24T4mI@_Ao2nwU|(r6b=VH&i5OuIVq(3?UAfn z!9~wy727ftt-doU=Mi#5&rflht4tRyY|IY37OuV>$Ij7wnn8Ugn~R;TZ^82OD4!zC z^l5N@Qp7Do#r3r*r^#o7l+@=yHW8~ERYh!@{gzl&5m)D77?EdHe>!WUJ7aoFtE)Ze zx`a61w%Nt*%d3_$3F@zgq<&99VOV#$dFjhsnc%dZTCS2=pWT~>Zcmi#q-46FTA|!s zAq4kzaUiHH+>T{JThSfT~_O_C{&iI__ zYTsPB>)aAvOyR3m*Y)#N)JpM}2Iq`MO)Uf#hc!BKqdR%)*3}{&g}dAu?9{B=J0<9? zZR?}6{IO*T8N9jXwf44n33tEt)3v84o|WaCgGdh<6a6?f4G$%g@MVn_UcGtOF1EHe z?|zP0Ng8zXd+S^O+Avx^@`YA2&sme6Eix&~TAJMB4=pvf4KEGI5>ID|#?dTKYQ@Xs za*uHP!Ij$fNR7n^gS6fxTioI;l!s)xsqfrm=`283Oq%sq+M#3a+|J|L=y!C~b*0~! zRFMx)&N^y8p}~(YKz*`3tj!0C;A8J9^UUp-MT)1hGzJMe`X_q}Zi`v*$yB}l)X^hW z6RZ#^gG=|tbacOl{7Bx{JY)EC+J1ggwPxW&x@oD4c5^ZewT*WxmODb>5o_vR5ne0r zi`A}jt3kQLu+uFC9e%lhd`@yRS2-i4@+-w_IR=i1p@nRdq{A#&X~=V{^i|n{$wJiGH-`J&3!+hz<>u zjMwTbl^1yKjotWmz{{L7I3n$~E9j-A`+yy*NVFO{Zu|jxPqnsq`5qDXM)WF!RB}&tY42K=4$P{3%LLw9e;fN-K{5 zlLg`9d-~Uf!{?fwU(Vu7$qUfk3tKo-*yu1rKu5`OJ7G6`_ihFskKj%Fnbrmvy7+YO zTwaJS^FSY|XqxSfJ(cXoj#E2bF0aeg+yVmFRT+p_Pl%<78Wex*`syfra_NQSt_An- zqtqG)O4n5j0;SZ`muQlk`9cJ^FJFCM`b{E@hLwg=q$t}m;n z_J;NEsR>+F<#~#W)%%i;CJaqu)SQLL11%S(4##~`!Q_MXkNgMWjA|=H?Z0=zj{(v2E+?7*`D- z2s=%AD|LXFGq(2KS-@i;!jDFuxF4-=J7`ri6z}Q`nxHSv5lq`{&G6bJ78Rf~zCeLC zCl+pJ@)dU))DBakTgn%>)pLc?iCPZaXC)tdQ$k(w3)>M6i#>5TM664nd_`h)EYj)g z1luPuVw=Nmq3*?0#uK(7=Oe4k2n%jwRbhQ(#CLdk{mBWNE^iojxH+lXH%=+!82l~Y zkyeKlWBairkHQ{Q_MFl@$qVn9eav5bIih3Yzcj43?4hOS-EGN#Po>ABwL(zRo>=mC z5iWg>FHNLLjFDe;k(c?VS@z66-OT>U z3Fog*qQc9y;x;S#&y{{E{!wz^P{ym|EyL+D+Qm`v$~irMSF*F3KS^qDr2Dmbe(f=5 zGZE`>#XS|JSNzO0v4WD8yluLeoXd*l!4$h}#bnjfHdY?i%{jf_FR^`-oYhIIx_)SX z5_vm4b;2oiO`QJri^nI+7Q`E*85Rvaf;ThkW{`%WeM*V2Jq!xnEJDo)*~?TOU@bqK z*iY;_YYr1E&i1KTlmR64al0sT+i*=z+YMUm!5lO8i&|$udgN*WR(K)SaZ&5W%<AZiESSeR2h#q?8vAW`@rC?MV!;Q~tcx zQBoc7<*q3oUNIWjGuQuw4)nw4VTV=E%WGvaC!K2k6GJ6~^~92f@?=K0v8uI_zJ@I>-|GvV-&U&3lq}2-pA9Q-p%; zJ^9oqA&OT(UlJrE~_YPlGS zy5Jb{cG|UvH*lC{55ZKZjA8KBq2mshZYf)CY%O*zFlBpDCBy`x*7;%K&xq>h&^dIH z6W>K~ae`wfo-Yqj)W7%Mr|WU^A&Rozc~7h2Sv$k_@*T3}ezk*<1?jyxeQZi?srNQ9fPT^El|afZSaB#s~SWMq+TmD64AEfP&U(h3B%}ONBe6_ z<|8JR#J=&89@T_(NtGc&qiy~|q_*GtGI+-K`fOky+k(o03yiFm>6P49d@63m?E+SX zE@0xEzlVu!7(cIEgZR``+v`zMR`-uP>{A)omp>N#SbY z2zOpSb}xuKp{1`Ux)9NJnScSrA59Xu<1l-&Sie=boY7JA5Yc1);zrX7KG6x;HnTzO ztT$S-C+pmh+3ap&TA_~~Xig&s&=@Z#)UvMLS(}$NF|v3Vqh{sA>yL|L3zKutO$kF3 z;`D?wypQ2O`TNg9X~r#rR?v;$?=hq$Fi%3=fAh0?@oN`Tl#ihCF}%1B-iSJ|s@Grx zoE$EV66$@jTMRG>MzR&SsWBEQewIhhIXJO7Nb^I)6Sqv@5ejWw&1Sx2b z56Fx)yv*Ayy?xdHuKj8=rHh;vG2zd(+7%Hpj#MUB|C=Hv_x`ZlzP0DG_a!^#Nm&%o)*Q*!Tb8(GESd}Bq9S2|qn-=in< z)N}8nK=<_u#M}sOu!G!{?<6t-I1R!Lq_8nUvJ(K^L3A$3wFs(UvX_YpRb;(e2)*lBPJQP=4V%t1KphA8HT}-r!J;KK4YLP(acmIjB#F}c z7V@Fm)s$SL&(CrXp&AF5R`x=bpQVIxmL()3)g{2V$?xPl5O_XeaHmJL zMHM|~+u{tftHUpch?G=u6MX*X@cQ4+&0jc-dsPOHp8TcHGG)W|jg<^ukDNQK@s{fk zmT;A(FOv8bzE=#58nwH&^}Y81W(+TFc-B3Bh-f>aO##kC4}magD+zzdISJ8CLq=uX z!MV;mw%-cHBUA~lN=>~IFmIviIQG6FYt6nB#Lp@Vu0P#Fw5*9q)GH)Cb{{^A{1`d4 zJ|##Z_p0EMc~?R?S_QCK_u!Hj6d-#YvR4xvurL1boUH-bL~OV!#&FbbO*9Pfxgov< z&?E^oiDcG7ciiDWBsm3D^~aa?fTP)kSF_PsO?vFt-ZLTm8VhU;D%n&GF?<~BD__p?=u?5Rx6SM$7#AGiKj-#? zZ|jqtr$9BOt$DQQiwu_hwdS76PyU8R<5GvKp`!D*A3@;%FF&YL*%m5f)$g2tof{xH zF##v@1(RO`p?1_C@Q#yxGsT7pC1J|yiO_VpJE!H}2|oCIsp8>xwF;PqymEUqzeDt- zeKUntC5-V3Yn)|&m4wttw*J$FFgiCNeAq0G-u(_Fx-;S+_{%fiAgSiKyXua9?N!&e z10rM#FF-d|LA4SO%j{IxyH79xtN$&o{y~CfeeWPKfuBt!cOd9~{jP+xZHAH7!zY`GCVo}8;edYL%!A<4$9%vp|Si}be z9zdwlJ7*ER1D+5Rc4x@67#$ozBS0%!#I8!H9<(Sp!Ay%a3IFOcNsgI+3zdU-qQxy= zN3T?KUq*GIn{EYqB6O&vIrNk9$%cJQXO8>FcrC5qslf_yvimaxyVD?28&YA!PK{l^ zeabZgzkJjxFLx=*9C$i)#V=G-W8<`I9Zez)hN&`^PKi3{odp@C+v}(<5%+(k%>O&; zBzAeL9WSM{uOzq<_qZOu*4G|wGx*$|<}LZPm1CiWE#5H5)Y6gOv*h_yk~<@|X}row zY&_500K>Lfmh4hlCVf%4azgfm@pE-z9Cu~Hm%uIK9DPf%d zk{b~?Oea5g+xkhL04PqcdkOhNJo<+!vB~zCGlZALm&Ptk;w&^fu`^JlKU-g;1OH@5 z&^AHQBf`zI)-_>X^@laU%N-8= z&sah;ru(slQ_PMLqlLsRWk}i{PeZmF8ht}F7Vj9Lo=eQP(d8}F-SrEZIstSJcL`A>rtxj!T2fNXGw+?5+%O>*6 zmOSc7hiDfY12tIIlw>NtP(@@K9!O`pM~8~%rib)f5!x(H$Bun;A|e>|BC=*lW+RmR z&l2U|Gqgr;AG)4&3Fk3KXVq={zb5v7RZHPEs@I>8BvIp_2NMqG zU#}a9U=KI{ahjl@G=*;4s6#B8@ff$shS2yIDl%)xXMt<-QL$XdOr_=$z}w9{Djse zHsjk5gyz{uyZ+l9W9YQ4`_kpr?ER@u!3j`Jhy~%r_m_qf#U0zBd>tP3XU$P zu|~)mQy6KLK4ATq-{^gx@rjI#fJ!FOKgek|6Bd+s&ZYc^ft-c*PtUnp&^xhkl6`Z> z1{`ExNE+*(&;9R9gTJ{1AG&l=*yne}Bpt-~2Gl02kpy@2v?=6y+!rq2^N|*UPqhV{ zdHdha?i6Z#W0fAFDE1TBx`Nni}lw6@F6aij5eDWq!QE8AHBi# zL`1vJ)%lYb2)#W{pqwR~<)pJ9!b<|jm1)SHzQuTi@a6I)EO2;S7G%RGcisFk;yne{ zaJCPXk6_96&v<5tk^@0O48$>}f7UFM#DM;BJ7&Z@8KY3wTW#iDQY?Wm}a>dwunP z0Js0h9(3bRJZ8hEzWvWD_13(`sBTdWT20l&LZ2H8wBNoS{2*&c#ug;aOo{_`Sq?}x z3lG*d%Cn$sogR*MSx#P5kv$R>inE(CqQa zwS4~f3^_#l$skYu?Wg~gay|FxDlr|LX%zWJ2Mb!3HD|4BR?J=q^2~u9!4^S5Ys}k@*ykFiyLxL7{tA`l1B_An2d6vuOTe&2nAwXuUb$Wk6 zt08a^1Gz^=rebGN`0z#R$rVJX=k_C%y^40F{oVH+*%aM9D;IdxtLjwq!CHZ17Cyb? zxKTuLrEit!Z)u;jwZkz|obx6p|EU3btnmFhZc|nty1@8eO~2JWEc{YJtY~ra>=&u3 zPuu`Td%ciZuo-F_wWD>hpqR*@w+6v^np1`JQS#-RS*uZ|cZ%ASu=RS!6{3h<9?9jnWiR3>kTO zY;83hNnBPMZHCCWu`t*By`RLs=c{` zCrE@-I@?=HB3+(dple%9HSS4~k;#5Q+_Z%4gQ#E$uQZ>+ z)v6g75=J;=DJP$sVgLj5_5;w=`mn_VseFW6yZa9pi_c_!3SVzKa4T}Rf?)c^2pjMQ z%Q0*3_i2LBq28H8#CgW4ON6y@_Jx=a5V7$XJh$(z0Lumk5fmb`UG6#WDYAocWy7zy zjo-w57Yh}x@(KjwiIdzh?Z#g}zIu0yw~l-@U0%}xbI-_i=;pz$@?*tZC3wz z&#G#NL_UVUK}0s)-sMG%k$2g!{z1Q&gc;FcP0C)o{pESIyvY-L6I`J(-ci|>cfs%L z9U>T%Y6nB=sD8~aXy}Ms;8VBN6=%2LMj8do4owoDvp$Yo(`)Vr#DS!s2sO{voA)P3={^IapPj*b|1H~@y{t@qf&MV!b>t0%kfY;m=@y@MQtG68U}a36y} z6i&h6R)3UOx0MQ+?Tu4y+R`(i^G=MEebNM5@Z?w@AMVVjE$*^5dlqw{O1B{eo)y-8 z%lrO0$e)M_1A+fuM*W2Z&_1T`18QoUTkzFNW<_!%Lk@R3=Jy~?mL|Lja_kGbrQ zw}%O`g=w9zW@sMV0SxCHTd3(v=tq;;Dxd0H+B#9z3cfB>KS0jeJD6ea`}kMa1UIBfnf)smbFdbWhUt&(BCV{^H)}* zuTF)sl47+`qvJs*gsp=f%GpePg1-bzux@a%R>#-5}uelLv*|Bq1DX2vpO*M8(XviPHQNSmJS-<4) z<%4w6>A9-L1#wVqZ{vJ&P@YzGsO1rg{w%$WH(Kpz#@fz!d5Prr`YGu0W}cZG8C|OxT=d>wzmbeQD8xV~<|y-`Cv=;> z2-nNVOqSLMAMV8H+3I{zGg7cVs`uhyE@F>U)Zuj5f3yTiGh6%+CfwyjRo8IfCWICB z5C~l&K>uFO^@65H_&2qo*iI*KM&wwnHFj1!ht^2ZKlexi*3Xv)$UfRHe3`;rvIjx} zHpFrd`B(MluhLa@$oJ9u!%&G6OGPjVx%=UW1btEULT+Ugz>h88_l05d21?C=pJx%d z_>9cxQ{FgJDbrB7mUq4iMNBg9bgr186CCLNGf4gGiP(JdE-$2uG@9{arl%tMwa=E? zy&;noR>Qxnn}hE)8YyK^X0S#@uC6O$v)6O$xUKWX?{(An;#d7jZVy^QE$ED91CW}+ zs+yDfSviYEeHmCQO?<6%clc~{Jws|?DudC#lzb~XY8pg^Wz?Ce6)fU$tL9^`>KoF7 z<>;e4+uVvLrXCn7@@)E_5IasQ6FA&8O0eL>8gsmAc27C&%^xiQOKV&yxv!317)i!7 zZ-`b|>4|-yb1)bn&P?aIJ)^2mf50vDU_VB@U39PE6X$giU#z3*WTi1hZFo|kVs*7f zzdT9PE4pCm)c(3Bb;8<%zh+q#Gtw0~7R~LV_@t!2Lr}_~u(4aXUG?`&@!3l$*0dyZ zd~9s<#L_KTna}D#EWqS}J77MRc_E~uhtlVllhzOhQj}648bWeQaSW#&2tmEOL1{o< zwQg6+ry3_CBU1IFy8PvvumFc5!@3`jOmE-)-a!w$20!RMi5ORys&_E`oX9;ue+UpY zowl$UWMrpvqoPJdpYU+Q5tDA9EWjq$a%Yd@<@tbGRqZg06tz)V&pswABm_xM*4nJfOvy1Ip{lGuNRox-M%J-K-7?mglRqTdm?6dTWTHOS~X0aF#_ zyiUvB?HYSVkS`NKAApwpJ+s_~1rR%Ei!VQ2ulvr1U>4Na_?^5G#8Hl1S;5#G(W!2_ zGs{nJ+M(2ffYB{XZrXFV!>Pfr0W7P(a11zg`l_bgys^WhSI$KtJJmLqla<8r+@u3F zSmClf$-L!0a%I#a%@}G(`k&@}Y;P3w4gu{8Ga&eYYM>MIf@6MG7|TIb4uVv1|8%E?-uRHM%p>S6ukB-3xK^|2Rwj?GHURB0V;oU2{|f*M7$i z3riAkD3*Foer;-Ra!a@RT&*95=c^OkySHc~#6e%k4zYF7bs(IHv-b5<5JjeZ+VQCr zM!Qi^%wbpSQ)thNUO}YW2A09Jh|1=;vA@FiYqxbS4 zD>b;*&gY_|JBvo0+cOw-@|w%`kj5g{>tMoPg8l_>VlPaQ>JSk;2=W6PNX;mjBz&$~ zSaab|u_EP>W@Mi&Uc=tRvI3@06Z>qb;yW;2r=1!e!a+d0=RZK__MW>DY8Zx&KBxm7b!pqnriS}hV5+O#dJOa}RyHI|5Q837 z4?yUMZ=IXQdCE7sd@JES-v1eBCn8Qv6!$SlJ|X*)K}vHvN-L=26x_7Au@nBvGq%NB z0T%~gr)SX#gG!nOx*D&kcp@|%!OoZ(Om}r0Edd|O@lfqBVNYC!qGlSo z=p-rPpt-VAQMuy@!CG?_GWD(%;){Zc*tEWvaTanPm!l5tmwfO^-v$j!!-2$^^N z%2M>4qRxm0A0Vn;svW8*_7yFIAX=D+s3U)e3?POHUU*XsV$f&YxaAxjU}c@Km zr`Wd~!@Af%whRS*OQ12#(T>)+(r1VlnyQ4UTV+La-e|CiCDRfX4}a$$HC>;DH8bso z4W3ialhc1xEi?c?(XuhT;7Q2OB2TF6e6(ceC8iV^br5w&>10Pn^h_(f5C)5}6SwB= zrouE0F>yrX5gjOMzqZbs{B5+&Vdt+Y5Rr7; z0gdxY`^)u&TIDr8YflI%x+ps1#8Jg}l0DGTTH}Cye+AWTeLl~O_|(&)3Jf$?)B}fd zwyxeN9RrTzI2Z(dy^5}^0Y4Ih%Ibzxe*eG?i`ztX(v?u1)ByRP&x$Gf=r=6LcxT6I z%038}a$(S*63534#$WU;7{l3Z3c@cI&5;t*i~}s9R#|JW2W?QJBhk~cHm7KeqbL;J z2|`2>qv^#aZVALHa(JbjgOljW-+;7gIxH&khgB>xjQ@akZ2^tYn3%mvIjBVN8Td$- z^)B4=mZp?NtXOyqnLnKH&SWC9-IxXy+8@wh^b(ff#Q$r1QH2wJ`#>Pw_kX@Vg^-b~ zy5ohWnKi|wy19%>_7P7!LE7e^?&UlsAz2+ZM)bYymCkHJma~zx@Hr`y=u(YK{v& zPsX4#F@ex;=5kWZyOVxG&EyRIMWbou%P@i9V4#`v;bKg^w*WeYl<_RR#8m&Y4tE#8}QU@R{mHIhMb!FTm|oD3Pxt z3^v93=j#%mHo~%>hja8B!V>5@;}ap1qJ%sLR>pSRKalwU)e~NLf;`e=;aq=KtH7z3 zB2JmKQl7PlLj=;_61zj*f&2e{6#wVK@vc4(sQE<7MW%n2>^C~>OvU)GN@7cbS04S) zz5*uPU8j81{=Z*amXv*7dTv?A?WggEQ$cj`6?VM zGRcx23%lOBNpS;Szgvd`QPmuP6yoRi|KS3$W{%fODz`trHtKihNIdS&^^XV zXuJWozRkD|HM0-+)|OgTJEE`b?c<AY1=AQIm=}2cWnE?H(%viVr#hXrUw}@9sII zW3Hh%_JE5$bXocT%v^pk0ndIp7BYA>q}h}$@WSs;$)S-2NC_|OpYJeuR(o0MIp#=nkrq9>QCL{75qvafkSXkQ}%ADKxmXU0>+I`*g_7SHGF*l8*Jw1F{l;{ z%fhl5x%7BtTAILBiVo;*#Itlj>5`&+oasaVHwbB3I#Kvom@`)K-7`6Dc(VUMCNy|0 zp$rV)w}7C~w1)5N6Z2IXI{45xMCLLH5ORP%VlNJJ08|euX99Aleu2k}Tkn8}z`9@u zN1L`ih`h_r!$aW;g~{=20YuNE_F|0cLa#j~30cB1d_3cioE`Klh*#SeVMtjYKi$in z1-jxHVE)j*1JPDrq-*vVN@^dZ2>%Q{6R{7xT6jbRj}N0~affGc|8`GtE#8?FQK&Cr zEm?|xa>}{cC*;8d;9bGotw%(l8;1ZJ0KJ^zEIWwQ$kW8J%=-!oH?@{Fw?PXt@%3wH zN1b^9#jWCHHY&b**H=K=tr^`J^rT&*J1rQW3&Co0%-Y795CQxf@xl)Gt_kuCIP`rE}$OCKjWW_WysU(qi@iq7{Js^xv(URt*X>b128 zO(`iEB4Mp5je>)^2le3OX#6jb6q^u)MlRe}wD#Br=_cSlb_aA-dOZrI3p(6 zk^RmzZ&($VngFVc?3Y^zZ%`Zne{UlE{bGdur7bzboDU`jQPWUs5|}7b`xIS5stu0d1q!(T_CHwnmFKBb6xyM_oAOS!Yy?3NO<@zELY15bRemQ;@ z!mvz(=YeP&%PbZlxT!4JOX*Mo!$Rsr#OGDoAAjEQpUw0q!XCq0_;CD5{+Tch*6Zwe zg}>YB(o75qxU^92m(JSG7H1mK&kuwR>Z zLg_?`tq$Qyj^|TWwBzyot)HKApJX86%>p)K2v+%@P!ZSa-LE9Ztu_!sEf8QXh>OGB z=`D_n$ueK52a`bBZ|6mc2~?g$dl|qFZ$O* zMoj9=7OSAak}bt$SS$Sd8SgP$}bScl6H-<{|eBDYrz>b9-=S!lj7^;B50-(&1f|#@-F@UG|m| zKX6~+;3*n^ss15F`W!Y-^|#l?AWuuYs>1kc3Nr2NTz-5N6nY{2k%8WAZMpZAz^!~F zCRdaE@eC=B_*i7Z^p%8vtu}*T*V*7`v<0!encX7=Ze>%dlFE@ zem})pIPqbrUbfcEFO~fI(&QgZ7TRKF$UwlO?f5HphUzg3jp5#o$m36ah(!DP4!&M#c)r$hO=k1$ z#0nb!{{QzX3<;4PvrFVB4?F8iM-^DD2$mN1Svx5JJf-K5!+K-jELf+KPx%6?!4;(E)Uq zgM!qm5c^As3qPR2_YSN>&Q3Kz@nk{`o=qROtAE2o-;&;V0RiNTn`rwz6=S`NZEwyi zb}0;h>~F%M)DHuRe)pdmI#%7!}FkSKeUbyTzd2UbO<~Y3a6m1?pixu63*c^f| zw|w4vXbx-fg=Bnki;~5?(-!|RLP`gZ`jQQ--nT^jzfw3Z`G@QM+w;}z%D5bzbDh;? zetifE>>x^Qd9hO?p%m$57z6b%s9$%4ZimP3FKv)xaNgw5$T zEp#dzVf5q`Va09xR2hFl34B3CLxTTOO=goK6(^posS|PpZUO(XOlK)usfGy(x|)hh8~+b!?;THd|NoC$ z2ce>rM4YHlN+^3AN)%Zc$u6VF$le?pT4os`DoSLpY+A^yls$^@v8M>~z();%L z{{FdcmpHHUd_DK${ zFHv#=0t*sq&y`ZF2Fdi)XW=f?5~mv9yj4NuYXNXE3}hr|se6RrJ8NtkiBA5ULVx-n zD4M-SnKASBxU&H&t&r8lt8-<++T(k%Th&AzHL5NsM(1yh@}q z4D*4^ojhKv6t!(6kl^ct?EW@;D75l&7&xk`=dBt3UnUmI2(T}5p}JSeWPe@KX;Ybu zMjF(l6xHWj|I(y*)TH=KMyr3CWd8CiDHP#bY#WN#U5rB-*8BC%r1(TUZm*Xo2s~aQ z=x)mdoDWw(jPGFd2*j;gV%fTb; z-VO}=ZwQY}!8hC;>TP>))KsWB>8h-M`uDM2M@>}rNXNd|lnC7LxG|K-{XuL&1gE$g zA4P#-hmsSTN6iH3A2_;tZR8^dnr4flhA*fFUfx{{M6v~wY*f)Oa*voec#XzAHQVQN z?`;;_`T@mlIKfO)NH0jz#!#>PmBF_ns7JSjqxMk##7DVNN2W3P+HC@gWl?%i{|tX` zWcygD=C4tEgIi{+Q$NOiX*{yyW!YAGX;3I8UY-MFp<@ns4XjUY09)YAd6af42H_b) z9@IE3hQ{usViZU=PaQ@iJ*4|^F?85{nHIp8vl(}upLzD99GO9~{t1Rt&Ty$yKix#d z$>GJls`>r(I<(T|Qi8bG85du3bKjC&y|3-J!X3!l7G2t@Q8F(dZwVj{zVEQh%!qg0 zTyU1W)W?10LcmEoFKDA&7S$ed!RKbjDGgL^D+-Eq6{CRT>Y>>u&dMI;BUlZ2S7tf{DEkzwU^FwBfnpD7`0l z`6$v)>FT%UIeth%o=)Vn>4UETjXv{n6DsozB*-a%O#+-F1ou^ez#_;Ll!thcZ4)qQ zcZfJxrhgMJpnv!yun%PL@|+W=6ADznciQ)Ie)dO~xpE7-q#B-{a#KmV(a zmqONw`gtxWDhfRfetomQef`{W4Q>;GIdO625v5bJmeeb^(VcGzIYhRBeDV;)rK`;j zd3r9sjSf^%oSK;xhonk?2OM16z|WrSt?}s`vnw3rkE5ZGv-Umv?VB+{e2%s6-Fd0~ zhzd~3cx+z>*SYl4H$J|79c2zu?&a8H`o*4@ZR28nu}?fb6RHfB6{d6#w>7S^M5X6tMjghc9YGiN1^+ucaxYAuZ~ib z09kZRd0Zax@HYo9eQv68m}3z_8J+pcn&cspS_gXgkxm#2*}(kD=wC$v3OSZ<@1Si4 z>{H2Y&K{{btb#gf5LK!qYwPDMt%Y-m)4iWcQa9al!0iB5Voj26;ilBGmqn6rTNQ3r zcz;JiB4z2`o4~gA4eQJnLIFi$GJ*usnmBp40Jgjp2_ru76(I*^8}x(lLtO`so-xEp zv#dN?7yYFqbB=l#^dQXwJ{F38{0UU#6^g}elF{Hzcl%I|%r_~C)@`YG=pdZR+k4Xo z_=}bI4#~D|H%2_t@(?jsr$-AwqyyzYc~^BLa~`6NUV-(0Wr=>amwU@-wIH~*>REFc90KuOKz}Dn;w1#j>DHA2)0{pynD3C5WijT;0uaR5d)f-!-$L5-$Xp|+G?>a>>J@u7 zr*2TE*JdYYF#Cki>2}}~Z$y%-X1G0l5M2a~m9g=YY`G;%s`a8l+pjono-)w}nGU@0 z>JZ_(EcFsHzTBd9C^)}uAk0ftpu0rSSE3k-z$v#$#MJV|%vAEXF_w%XYS8`jBC;?0 z;^M!J1q?2SwJq$ck~}qyw0MRc`#v>VIKqu^!&Wx=%i#8Qe;oFHDXaHb+;@!z4WGvI zuOxTA%XgYgZIWnQG@y52FKxRKuw#sYYMq2IoBR zqWz}&hl8LUQFt+9IxTdj@XJ6QK)BH_bpVVz45zz{MBxggpsg;mb0fS>P9&R|pqMrk zvwy!IlKCea3cerc$xwX-1l%omn8n4Gc)cQJ4`oMRX4L<5qr;C7JZ-X2EqP6`!bqPS?k!-QQS-LO0dNaWeem^$`^sNDcfNaFdO;;s*^9Ssg&%PV_+ zkb0u~24ZX@JpBT_0S^0QgZRv)1?#u|Y{d5sp}6-s$xDE#3=1ILkkGw&flK;uYsTkE zo(*LjpFVS#nD@`O4T4QJ2R7NnzvsE)y#=$fo^tk*A(nFQXGGmK*KpS{*X(vpTA^}i zKW1hEL1L$2Q6c-ajOLN)!KSRM{Zb#Fj+W>?8V=^NASs)v7GKU|jv2_#6qNx(MpIKf zT=fM`B{@}v@;*E7B5roD`xnSzH*rk*L8j=Q;71ZX$PI&sX+(5eDOhnYoZaH&RJuiF z87vm~6AK$PuM=r_ev2v7raTdSDI(=s=HrC*W}zYj*_Sz@mm|2JVxNn~BwbYz{gMh8 zbI1=5fsXrPcbsz8_7m76?3RyYU9+YdO>-3+!k_Q^YGTcA)1#Pm{w)Pv;5pQr{v13K?R0}AX7O!HpZeieH@V;hHlbk zkggx;6X4$=JfMU7DamT6-?N4M>ioUj8en*U8odQ7{^eekBPS#}39+yY%PWh&!4Ewm z@JBr&1EBX^iMJp46al}#lMhOLPIE!o_0zV&trNGD^~zBwSkAZ0b2SwFlkr6QZa_TJ z^`9v3UHwY-8y=Y=HDAb(m02$64c<$22$9?DM7YS#3EH*r`;VdeF4Sqnd$iW*2vbse za8VqBtAI5eBL(2#($Sdpxb}r14g8&9*rsBMKV{Ze-l>rq#k$E#&$q0Oz`bL7$S(x4 zAvc|&rfxGZf&TwA?SvlW89xM(A^#C)u)=7{O|4D*j$YvV11kKw4QpRcv*#M&`8>Z| zQYf=W>8n!2p3Z0YIs%$TpHz88>PAajO&s7@^rmf5jP8jNu!=kLJWxhT>ibxELPwAv zwNI|q;DHFv0p(Utw z)Jh(np58}ZtUMoUje#PNdnW z@lG8LyA8ZKMMO9;%O5+2fQSa($y??%#mejQs7IZDd&>m0)h2_D8F4@_33YxPuHnDc zTTM~1z{SxP*r0vZbCB5s`AIxcq%MmYG4s`pf9@{=Jk{2yDD3M)?9aS@j0#Q>FKFG> zqsdeorz&gKlzH$XZ|1Qm9Om&hS{a%S$#ZBg*z=L^qr|x^^90x)<3Ypm z91`_$LiR(9m(DCYmH6!X4Dd)oBFOk`A@GlHbDKX6TfTyA|CiGTVY4>TR9o+LpHoAN zw)HV?{V~4yBh)(%>vmjISHdTd1s+ zwe{zz!KTkp<+>Iwx|5u2*BZEduKj7A5)eJ7v6Q^=eKVYWLn5IH+yy85+2q5$8(W}myJy7x3#HwL>oGldj~Zjo1J@XCnoozEAu?viUsfLYTeDBu4jAp)Yd zo=KiC2}qH)n7t1=7;mftX&^kSyCi0-d~Ca963odQNT$gc1Dm4?GOH0a30uRvD#LQk z2E|&yeWVKE|GR|k1Ox>ItG*;?MgY;8Q7|(7}@HHlFUyvT5!W-IZnY zo~ZBqcG34VXQwgIB3|>X1^4nn`P)=)&L|#snz+cjop~xGEUe$A|I5MZ*?J6SH1lZW zO&*7Xx0~alPTk+XfsVE`Du?rr5KD?7d!XEEp`nLH13JC0&ko3--SK6}J2SJgG}@&Gg>6gv$ga9>l8?A5T?= z>ro?fsyKMWOt|jIvBXPC%Z36EJ&AbrTzYDDci-kJumoWQ*?54P3mE6TvNEHi4cX|G zc{FkCuB%3?`?72P@Ir;6;&bJ_#&5i7^cP)$$nkp4#K&0Nyse

wz89&cJ-by_MxXIcuhzRB!!ym7Cbjk zwLow5g?7^d=njXL3<|p@wR7zR;kdLksY~3I*~-{7oC4To71$U~%quLJG-aAqWby=- z!reRqc6eb}Nxs?nZCAYVwns;`L$c(9Yj7xbVd@eEMaAImg-q_GGC7Qq2JB$NOBI<$ zK|~xQhm*>laBN4eEw6O4vKsOn)5I#kxsBEQfdZ)?v*1_nOi&A(8xiT{(GghZa%cgd#a}(33kN94uO7>s< z4a_tV0L`2{%;8+p8t2UJ>YXdUB7(vA7kuD)OJro}2&jqqQVzp1?S+=D7!@QWq6udp^U_CXJlhW!aVy@Hbz-hi1LvBEJ7mNk z`P#M@5q1Or)#m*@jt(X+Z)@0^Tkx}I(-_dXBg*Bt<&u#Hw&ZTc>2!LEPBqG|Oky5c zT!fIVOSNFDrzc$Ga=Y2;-Y5CO(Ponc=c{2o-&5enESg{XfIKJ?wD=1b$9FDUtiMKZ zq+!89hkVI7^d;erFg*i=l#` z@WuG{jX#d9yEa1>d85|{-Zx~Js=ui|O&=bNx1a6Gmn-4=G+(|Hr*%z$qoM~vZ_36py@$P5KUlHzUrOqQ;8FU;E5=8bCXLdhy_Gu%V zam5RI&UXgfEjLSb!lod*Lyn6pH!AL zo7lT0OEnwxm!MP1GrlUX2 zktJovKvP!r2A<@bbi<*Z?{Vp#o{%uUad#`!+|{X8)GK5se#awQ42BGJeC^@zM%MRx zrxt_U7U!<*Qg3{JhXnYHmU&VnPZwd&Xwjft@G;ae{Tz2+SlA={Svqfjz-&lh;Dwy+ zQ|!c3H#Y6E$~0^0N;hlzGF|T`wOLinwUP~n;O@q@&^@2-xQ>RdKYjh4)3Z+{ZKV`VUJYk)nUr^!M9%?s zCJR?x`O1f)!cBq#%e3TIDJWDxB=;FqypJTkit$d0fMBW?y17mQ|0%Y{!!C-?=*jWM z2d;0%&&HhE_W98`NSke6rWf=^lvzavIys>FB?Nyhr+gP-N|^2^W(h4J(FGl0O8_ zaQRM$0G)(z^>Eg3wnGq?pR_rD1r&&?!E`dT-rujP3;{y65EMLp#2iU%lm%be;JP^OJO%ysiC3(Y z3ImEfPl}fFlEeFLDCwXl6BmYp?EVWEKxk%=51-axCL~xv0m$hPp=2j08~Whd`{2kW z<(X4%l2INIJhSVyQ#CI_o-g`bhRJtlBcF~QO+MOpgS%aXi*En%*|b+6Ccial%idF+8ewqa#i=}h+-XO? z8iD-|c~BQZ(?`QT5Uqr`cj%D%3{XM;g27^NZRK5Z5iFjdfgW^C#E44#F-{^RVQ0q@ zuQuLKx*a4yYT!T9Rtuo#GX%hj^g9ybJ+}bP5oOT8wI0s#dqZFyTyM-Y3p)pw1a!Z6 z7s6K0$3hMJ#0;I|mc-N?n_cNs=D;NbhE|6oU}@#g}9v)qNxt-uq0 zqeO6WpMe}@mI<5z=U`?2=n^NwG7aFyPbBauw=p=aefjVGW3W2G1)W#0o5vK*prtZ_ z3xx^98z!&=DP=BjK8 z4^?dYYRe|hd|&v81Ii+Coa8l%zWL!o1+Uf`%zq)WAFqkcML5||e|5vk!>G@+C%G@i zJHf?X6=IpsU`Bo3yqc7J56ejJv&cAzXyd`Y_88m%_WNsp*uK`o|AF5mpmVp7L<_DA zV(6io7aF`7mm7E{!Ph$u{JOY4DFlzprod2h6c8{nt@E5@nA^#R9d51SFH1y}bca;n zWL5+8NHy1PaIDQ+okqqJo^ldrK=*s6uWiTy@D!OXdvaIS4>k~!W841}X?Tx1jOZP` zT%Rl_rdoCIEt=aiM3xTg^i&b7prTjp9IFdxhVtGa?Q>?0=_ez^T+dZ2`#}_4xI2l( zFA7?-f#@USIc2te10rNshXrC zngN^d3jt&K)Dh?+b`evbtAB>($lt(dVS}jq*BT>-Y{k^j3WhvecpoH<>xJBKSS9>L z3c~w;>JaT{vQ{_g5Z(3<2<{YM#Sr5zo!^jLiUyZ#)Vtd0W8J;^4;l z91yH{VzN!KyN_Lu1vs)ktjn=A<%0BHjG(%%YlaXo#y(pVEvJ>(T2g>;yc!YYAi9H_b^QS8i&M=iNPj*O9r>L_UQyH zJvl&?m+!MHu_$DM411`vtE+EvOx~~&(aayY^6mI= zm%g}t@5jC8HLVv^M5chJ(U9+)W&I6InF^oDM_5TpNmYRWt&>sE>J10nGC$6{&5Y=G z1G;*$&0;^5;J!%LwQK)cnDb9Fr9_CeidftTXK$#H60G1NQ8m1Z@oERVJIexrEM-cu zSifK|oaSzSTTKyLw*;oGPlS_qS!~~O=|D+9v9-pYc}PH5Nv7=;c%(r#;gQ>0i!2f6 zANmnmX&3+~H1bs*w(szhf%~#C6g+y&!?U!VQ!%o^b`=?iySG0Nk*wMq>bjxj;VZ_E z&vo*hl&2#q+)|S&mN>u7S-Gx<)U+EFxxNzr!i|;s8FG?T6#+(+K(=UryRZ9V#&y32 z{b8?qH(uIO?kyY?GSOzRr8Y|p)g0XXibod?7yA|<>A(I$A6#>AOE_Fs_f;de_FOaI zS4JA=U(&7j1vJfOe)27yZVwT8@39P%&*8wWd9BT+@aAafVj3j{x&hU?vZX~1-2O`> zjOQ#Ppc9fkbYyu)Id=ETb$-uLV%XR|c-?|DzI>nC?68&HviWukV6It~r!N4)Y2E5F zep=dmmtvxpV4Iv1CB?T(&WJb=orcjrUFR%rGfj2NlB55PuKY$fv$Hx6=Z# zutp>OqCYf-sT+>9DwzF@y-8XY)>KSs^VZkJ(~99b zaJJ`|o;ZwtbBfZ*^d};4ZsWP&CHflQ8rqGF6oj|!SFvom&#CdTA=~m{tHZS)et*CwuHYc!SeI1 zv6iHuCeRVpD#7k5RM^{3HvsQkad!04u^Wt`^z9(DJIvKv0%o;)ILqxM@C}DAY6^^+v9KxikN+zU@?vv+)3)#LOZQTOP zbf-_Ac@PvS5PS^q={M7DlhRzU)EPs{_X;ch+oI|cn zS&}n7PkhJHgC#v6(GhY?V2T@Vc)eP{NSB9bw0TmQmL;jd9eFc~%(uWM+4L0HdX8UY zHw~P>9+eeL-uKSVrC<$?`fp0dz>@UkODH!qzHniG_o>#E%?H~+KLfUEkIBY5!y3z4 z`RB_E^4^_M#I}h{mwQtUgndVrt63>OrgDjYC z)9?W{oEEpah`>C^;}j-ea09s*chm7k_2@c7f;LV-An!UaBY3njrc}mActqHz;)LEU zv1sa|+`G+^#he>=9w|+0&CPEPD&_==!=0D;u8VAPA=FodhnHpr=f!Tk?9#ISIU!eb zW@}si%9Pc=Yw*%kV38OX^Wlgf1=hiU8EEy_P!J$82iQW4*2G_kQW=Zg2s2 z^XGIXzehNmnZ+sUG(ny&S{O1quO5x^G}OHeBdNpT;fxVwfU>;|O-Ey?33jXb;V~3#$~EoUu&}W)4-|+t!77a6!f% z1O|=-GbJjdl&drHD^+P$sv+e36t=X|Eo)Z|wN-xOVD~=4;6Y1SdXU^86cR;YCv&5) zt(oAvc&{~b;X6NX5nNa&o#>N&_+PJrshS*@9Y9Nr(nzyYtZMVveg#M_&!d}#GzHTD z9}gvdb{wFSoyI^`&LIad^L=+Ec8b9~O73BhC z;xkarseG7vFs-!0Krb`61Tq*>W?RkN{lAn6mQ@fMX=Is4uwL6dH3ewv70TTMo}OSV zk&|UvT3KnEV?WIFMZW3-)l&K3ram}=API8JNZL>8*1pcOV>#jd2a@u>Er6lAQv@wn z$l#5Q3{Q0f3k_UfU*FhbYbAE(soa%1ur8OWPStB13z_K_zrN$2jpo;}$3Efp`@q({ zbc|(pmr&qpzp&3x0TEknb7L6+S1V>X;^w;#6f36#MTrxO7l6)ncGe*>njM$jUu%=* z#q20*J|{89TJl2Wd4RLrCwU5ryxZAFJsew@82JbDeBHVg;chHaGM-spU9Ie*Z-hPU zD&jJe%$l`d0CG=`C&j10r}M>Tn8Q?>Tx!ZudK4QfPUTV;HRnZ<0jOTkaST&U>YzV4ERoLV4WgzM_!Yev19f5u&c7dvemYzS=O z1+ijI%ZiFKQFRmmOm0%) zlF;M(Ez_X$>*kR38wXx$+9$XJij>^Tgan3Nv|mxKOfF=)&>d>T%$Pa2dx78g=Vtof z<8xt|igupvL=PUb7SzdT>A_Ru08Hou0h{vHeR47`HwJdclSpDPaiHYx1516yM}+;j zZbUXkQ0=z46ZsUbx5X71(v;j9uank%Mlr4=hQtJz=q4cBK**p`uo81Tz8i1c$C#bre@q~ey8nnG z^JK`Q$0XbKA5w&iz49YXu~<~xXvj@HUhTAQ8=Pevvs?Q^K0d0EqXEaIrd_dM=q||& zdgEBO*Qfr7V5BNS%*vV96V9_5vvMFcU>scRo+GhO97NU_NA{@*JP{;>OL3&~D`>!4 zU;Tsd$WQ{d^YI%`&4!il;gLm7K7Czb7HUW+x)bbVjUpJ0&qN`-fSpTty+HpP3egW8 z;#);I@K_?q>C~LbE?4P*Sq8(uGn&2$8wKbl$$H4nZy=zb5)q7{qIQmr5*RFxpN_Gel zY^jS(`|~T|C(s+^Cz9o_B27<7mcTzc9w0c~jZ7kE;bzPEr0Q-U#}4Q~ig)+(*CRg7 zBE(nRBz+a|#p8&;zaj=8>-$2mIXsMM2ad~zTA#bA>M*1O`BUMmFx&6l6deig)oXvc zhi2u)==VZ}6PcrWMFe|&k$Ub#1Or>33xYu{-ZQPo3tOOom(~?*T;b7q;IR1ps&PFU z6e#Ji^QcKQOl6wbT?~fL;JX?eTLex2IQyt&6ws_0`EI%`g~gJpjjlpJ~n{x(lk zz>ep~SaniBlDE0JxpOEafAuT>3-P=;2pCbb!I9NTiFd$Mi7&eV>ILOK;&$?zzu>!E zPd$97UQCuGItpi$rneq+PA!9S2hR&hCsvRi{0r(H;6^wBQ*ABZ5xA|p;^cZGMUGXx zhw=*V)qM+A&^5)YBp^zc%W#@BQ3c}SXM}qK_QO)^oU;aF{yt1t58M=BXMV1A;k+x0 z0c%JEw?IX(ynF!pivY-DSiheu#;-F(Xo+Go;XP9B)~_TI2uT9ilL2iNJthINr&>^{ zguf9@TkZMZz{HgwWuC(4%W4gDR~tut24%zgfV!s&Zl(AfWbBD>;NO6yfBopU69!nh zqe^L|m8B+l*g>BI)hQkjt9a0n7-eACeE&O^tB=6tpm~<4e%)0kaf^XZ$-!8 zKu7TzI7qQTuNSoiYSA-8=3d%$HY0#%8xTaAspDA1@MHJIAE7~kr3xBKAap+hIJMR0^t^+|r;8ZWUOhU##i z3tXK6oaH|X9wq7h%)2DloeS770GLak##d&qrhmGK5JWr&T;0zgDprAve=WF5e#|Se zSuc?V^Qi&>@775Njj#V044gkLcnV#0S{N<)jJlKwIB6`7n{1$>$vU$dFNZj=TN7Ej zSNa%7xl_tO}aJudZ-S`~TxSfKz5Dv#7IxE0AT^c1|Gw}P6tW5^2A0yiDJ4$s{ zzY%+rNSPBnTO2ZgA~_kkJR7O+44k+82f%FEuUn9}Uro;KzW%!VC%mL5G%*UR(!jPl zq4#i(z&w8rqMXx{0}W@ON{(6tF!bm6$dxba1&J^ADwu%StV?>m6X(Zvb`!>b4^5!< z+Nm=}f~cop$MFOxx~jk`o_s-K6;JH!2sTj@37ZG%9DIJh;(y=03>~O~J_BnvKMGts zSk0&a%rw=K)*;Xb2)Y_v+{U%5|C|M0=}x~8*duSwepnkW3K^UcD~LfKqdZYMm>HBQZo9L6b&M2?hyXaN%MxJMEpVw|og8dZMD-)bpLtxQbjK0^HG3&1s6z3 zHgCN2-!b`Tj{Zt(rfgFxB#3J$nP#LP>e0aOO;X=9!!!}_PN2M%R(&oiW8Rwp5C zsz-$y$iql%LEpa3J-?q~)u;Y1X z6dzX)Ch8g@umSpfjf8>kvLZ}VslUF!FL`?poYMvwZalbK{Pi_)9`!rpSth&f0IE;%r^@c@BU@z*Pf0$fjZAW_>0(Ly~H;YcLu9$UOg)82G%pjHJk;t$-NENbNkD{>ShYlLw!w_AeqkW;7C7%z578BvD3r>%IZO)$n@V7SN;E<%F(|{2@wo#qhjc@xQ*xj{>?=`B4=& zjm$%IOHVUUSoi6xztDqquctpki)UenZ==b(XtPET_?Th%cpHtwQcQpf4IcK z)9{k8W}>K51Zjyd=<5ihQf2>gF8+9k;w?`iWe?m3AR0wo)D?GHKj>H)$VN1`GlQ@D z?5381C4rN>{41*q*o5p=z9y0*Ye9tHhkTuL3ZXttN++ zpIhqBMYb|6qIKZ)YITX7JYe#oX)CSyOJ8E8h#)bd!V}^Kw%mP8$XOr3QJB^+P(Z71 zZjZe3j(+Ye@alD&OJ1DIh;srhh04t>dtWs|?E<-cV6f;XNzF;z+6l$wqV}uAQfHPS z#sZ&3>kB~U>86Cle{awU)S#EvDkK4WVQ^FTG;IE*=lqE9fP6^79anCfngl-lTj63; z;d3Y?(U(>U1ZM~X?xzd8&ZWOED^r3$s_mvukHTd#i#R0nNNp6h8&HH=(&DuMW}mUd z2<-Xg(H^)XFc%;9CU3$|pmSw0iAMC-Ya0s%?ORBR&~teDY3?gU_Ktm_+da3_ihwi7 zDI-C@DFBs~kjArhv-@v**1v$4QQ)aj`)+UgbvwDVPmhlFazm;V8g_L=g=C6a28)%? zfOt=E5`4%xxcu@AupCrDkph&FE4H1bG#R%2Y8fuGRxknCP})Bh;_K|(kt#)O)~;C1 zti&7?ssdU%DMtv0QB8Hr38jaSKEjsxHSH};1v~D)`89+s z$TO#-<S4T3>L`t!Ju^a%XN5VsYwV{6Ks@ZJ5T@8a=Z=AVGQP}IFFzENV|k8s5NY%bWfiqWoZti$$B&?Lk6qB zS$Gm86hA0yg?o4@2U_zr%LwvmciuaoUUfMRi4{?C%%#g92cnBv1e!|p?XAF5W*kqQ z1C3`b%7{iTqFx+IyoiU3Eh5|WYS2IeJjPfRWH5qEl)p`_e{e}ZW|(DTPfjrW z+NY;UAiDvwAT1OfxjXCTuw}7;J7Oe?xP}IylG-B#8b@y4aTurV)EhIGoi_#e>i*Em zB2NAmn?RG6oQx%IHHl)VX+%{`sbptopQ6CZeSHH`xzB)jomO}FbwN_gJc8qo z<4t!B`5p&EvSO${_Mbq9 zsTKiMfBFE{Q-P^C*>XaM>YSn_+Oy4KDxs#wW6(cwDYQu4VnF<`X_1y~BEJRj|A?^n zNI_3VA5Pu+Yfl~}dK#q%A#opsUt@z;o4eX!0jNv+Fe*VVQW5c^jH$eB%8A-`E%r<0 zMxp97ePHTco#qJV!99@Dy*SIA;W%!D_?}%2@A7_Z%us@SInko6-Tw9sV5`T@P4@S< zh)vWS>w}yY?~QhvU#|ji8UZ7d{NZaBzdf*s0!Yftf8797$U%}-a%IAd$_?<^Wb-2? zwK6S`kC{VMl>R27(#=NH%MiTfv;Zvfs(4AiX0m193w*tP`(eHX|132#mmh$!Fd*CyxReeya_YL3R0sJBpiGEJc+jd z(r*O#T9hN0GsSJDmN^bRdwk;J?O$#K(PxW5$ii=cT?9VA3i#eC8AsR#nS6MB4bh4p z?!{4T>I@ki8G74X^BF{b1r+q z5LBAg$|_hXV&&wK+_pt|Bs>7Rq_$eGts92S>3iYQt!J>-uzu$;8qtNog8Wns&i_Bw zV&rg3uKL{_+>+wmT))2x+78aS`}p798EAeQuM2d+}P9yZ9c* znOZP^-ICdh$mgI{8!Xt@R2B&`&)lRkD$td`?1s7daP;TCnf8a#*4gzH{Io z_&PJd(+e(E(u28K-o>q`4B=;R*@)E*IPVQ=pg3@w(_H3Uge-3CL)BvQ*Vex`7cs(j z+WXwXrK05*v}gX;Nl&2^1*-*+GPNO^ZeXRN6$kr6Kr-Gb8}lkYsUQvve;FV#Usebu zJL17@K@|zgr^<7Ze|QG~UqT5IK|?vf@Q(vIYpyt`p48w7I|;VTRj#K=C+!CtV}MVR z;I=raK5aW54SZ0i?Zo40ZBJ+^U>=rO+!reZR)4=HPd$T-KEC4Y2sjcpagG1R6~#9gB(a}-4{7k{04fvqt9BB>>2lO8yFV8mxw!s zhUn4(IE5Q^b_%V*M86##Yd`+`w*4;=z%T9o_wuGdi-Snt@EJMn1K8BBov6gG`?o8< zC_MyiO6_;D&J0D7R+sjfD)N6n@xLF(r=yeY;347&9JUR*v@^`-`dWK`S(E?ToT*Pk zyDkd7IEGz>OS{an>G93$BmF<34fX(dG;LY=iDxvH@DWQ6hrfXkKfb>V;Q*lz1}O2b zkp09+r69|%{r{iVY3znqR?{+)=lRXo;Umflp2Wt#}|?tT*HO(7}iEfc-2Dbr_^sQf+tCMPGW~VJ>`TPtNw;q{1^xd6l!?# zcaf9RUd6S0dP1f!7NliyP_P0w2{Kje+$*vF(XlwJ7YQKb`l7-Tz=N!XTLEuRg}^qF z)MMyE4TCuNl29i@!KBNmw=@%vbVGgVzkLX|8_q(-(sss80HVU)Y@ld&t`Ob{JuRtnLd_8Scw&u7lr`;1)e^-cfhx zLtTJvGZKU%D^_0nA+2u623kSn&NOJQ=dXjx5x3948j2mP7~SexF+5+*m<3O7JU1r_1xY1)(**f^ zuZ_1I4!^RVo5Jc`q$!y3Ok(Gu3bM<*ASC9bNxxMn zpY0C4)3Isi5t+?<9u$O?h(j5!g6=+ha}Z+M4{(-?8ML3%>4z7qT?`kv@=DNQB#M<7 z7<2Mjbq0!Bt&!J0Cn0W>R)DuJB+o|%ee(`Q9`FwWuFPzv?3ZldC6~>@ZFG!Lr}Y4E z*vCcf>JqhG$1mCeXj(v3~m`rY7z6F zj%@Iy4G%Gd4`Ld1t>u`!7R~Wn<$vXm{laX;j`O0!O7}u*3BCJWuLwOL-C~Ka@+7l* z)rV3iA}HfZ+$+Ybr=Mzq^07st0jhAbe>>_==#aK&d?sb;e$N$1cJ=Ep&z{K80Pq1h zo9rS8DmI<9vj%1mi;!crw9yeiDbk1e{T~O7XScu9*h6>igZQ}PZm$ujKd7m!2=jT_xl4$weAD`3y@deUh3%W8~R*w4$I3yQdSEQu5EA(A_lcu8YH_Q zFAU59xW=4ziUjR1)eGkcbudx~zH`NN$XKY}_E4!uP`xWh;Dp$8wBM=iSG;ZRZmCp! zJS;9)P=VFw0ytsb!tHUL&y>I#k?y~|ETEw2@xZFrIIPj0QfjpOY>5{wZE2Qi!1X8PW@^X2F}1nm}$SSho=F z#lh}pQC!lr1lY!>OrD6smP`=PC1zK6pHGtgVx1j>=N#L(2xK1d5$DR!rm1SsU?4XDjm*oTtX@wb z2E2kupbgofF4MZ zI<*~i8JxV)0wZp)oEpE}^n z!@dtgP`EI5o0WHKh?Kc=`y%UGYCFwwtpdVB#QFZ)XS>EB#(D5;5HO>$BbORdV=g?M znohj;ir89ixC5|+0dpNVBfOhV3Onn$Lp*OTJb#m_^~3{5NeUSQ*B4Tx1cPq-oV1*E zN4L|4xX9pd=0`e2qPopPm*_eM z`9SSd*Yw^Q8PzCd-OXfnZUF(%q}cZ)z)1EOMoulAmMBJw{R(acks+_eXwXnM}p^h;-IB`E1@bwRSt>J`~VRDPLs?5uAtK^K8@lI;1-* zuY6a!Mc=9UfoI-BqjQH54P`?lhmE&N4YutBzgMgkm(%t2Jl#AzhbIsrrmS zTOP$r!^ez#lIcRP>rk*FW{$C8a$SN(+P)WNEF~H9*y;}03r!7z08JL=iT9+kycJJX z^!S3WM!~Fk(84C46OCDmIkeY84B`A4spM!i93E}lZ-tqR)2hM$`(c>#wN<985bD>iaaR$T@K=jg}7+5m7vGQY@{q+uZLJ#ccD`p(*3Ih9t*y z>(I98$UHIw|7rYyI>l>)(Rn$(lJDI0!^8q#kN*_m{lj+txlnN;^ifeBd2a&gGEbN1 zk@TyidlEUvO@Mx8lC+pfWdSLAsA9|7?^7KKGhDGZ+KuM~$k3H4^dt_6;x1c{SMvAU zjs?@w)KBweQIh3NpR{Oxney~3C zOWb5Z=UF%`Q|NltYc7-x5RK{hNxismI*BW*apX`6>15?n{$NElkC%ks(tGDNoz9n2 z-3orLBrPW>G%8pYgIS2i=~nsZEDpXoORM~^m z&(KVm{R5{og-`rf{P70kPJYrH?+@R$KS5YH1*5D>b2Z(+ccF3&=rz4drJ_TXENLfa z1~o~QzH7ctEycy;pLX*#9eyq1`|O7ocaC@$S9Z*e=BLLfcFJvfTL^o#{^HS+F|qfY zghn^-U9kvTSmI3caDif!IYma`t1zczPIewiRA#3d4p9YYT6Ip(jHa6c9ykt8LPFon zNZn#wp@35J^us&_PpWiS!*BK99vI7}jpj0XN7%v28+_b^tpwb|X#LN#a)_l`=(F%1 zJKlK1QTu6UFy79ZVMjxfOJMgQEy-erYrJ9B-3rC?Nw+7o%nkLqc*2fFn|+@=-s&E}I?i-oSGn@ak6VmW$6HpN zpG)aC<;;(p-kt-*knxN$Fub`K%_&>Fi7_E63W})=o&5meS2JNamQIzlumXvyV$CW! zF+67thK1=d7#@Mk!=FTg@mv}Phu`NJiNDiS)MKm^By(hhE6;GsX$c9Dwst<(V30jY z6~vh7_)c8hJWyU_6g?=H@&+!klYCa?6lpT@EE$0omA7L;8;ULmw{<+2nz{gfPIiUg z!v_{i<=}+4ukop>KuRh-l(k}N7It3~XFl>z(!(7a`J1Wj#JbKtXJfu$wNqw?&(U^iPFUyKMNp>`VHnsGiq+FW=)s!=VyueQ}(pDnV=ru2ZKZ$(&BB>M= zapq%z42{vM=AO3isIE%y-*NbpN4XjCx9lRG5ThW7Y}rhjAe-2GI^S!#jGf(YX?}7Z z-GWQx;Hb05DOc_N$lM!9WrRNI6>MdSDJ+n7K0UN-9t60~o68oP2c+k(yUNS^v<^bV zHzCG$`hmfwt=4mng-c!2FWu%5`dnaZzP&8M-kpc_8r-9;hlL6wA+j;G>qaahMTWw~ z<4&g&Z)U4{bV|28qjj&sfPe&0E7o%cKEFNPn(%za!W$jJinU4 zidzF?R>;Q}b<4gj+gpux2KEZ_b;s$x>^f#Pcn975I_Uj-66Q>YZJvJS7kepEzR(8R z>|TRf!;B+yTcJmAi6V#W@B4z`Dk*k?=wT#6#6xYvOqY&F) zC4jiN(f6$RG@zAw-?dRORJUb&wFNFWB<{a@hB$xr%a01k@Cev_qeHkJM^~Gr;gNhk z^LatAQHy&!WLEH7+iuW8T|~?MY7??9zz6Zp1ujlMOa$HH{0|AWH$0&}GxDB4Cv)8m z{v=x(gm_Igb;NE+#($0(fu#Yvo!vzk0OjuH6*2CBor!XgpziU`d;1P&i5XWMD><`Y z$9JmN5I&a(oZX&di!Z!C^V^q9 zQXi5QDxY<H0r+u{4RUn{ z=MW#)*&QjWwKFVB-F83UNkMO+>q`KLC=z@IXG7rhXRS@teqq8G#M0pNxw=z23lkyV#Y zw@~$?YkMoB8KRHe#>8ItUJJ*Cl`!vgtlzxTc~kpUX1%#oV$-5WHG3cr7}+2w9(GAb ztm)gqNI-C<@XCUlBXC(!$Ln(MNL%7RxjyiIxq8bK3Izq1;bWP*X8I_DJfZy-o-L~i z<1A11$$iNG5LpHA!B+={BjZJ5p9P&xm>CgaU+6tJYUa4;$=s41fl_NOpoYv=wG-U~ zk>X|~dF}%%)Lzhle<~hF`Is!4djXQX+k#XLPyM}T$#^XJ*U8VhpFpp96eI`T$FC@iCo+w{IkZTqv0 zze_!m*>sl$`>&qIY(EPJOLMvn*xfs{n?D%Y8E#wf{rTr~H8!g$%rN{%;DOU1D)a5S`1-Q^PywE8+*uX|nV!F9CKu=lju@>Btk_RR^%*@2mtwT^YiRKHs|YLHUTxGPr;SB=iA+W>Cpb;a%*@Ax_WZ2i}4 zWarMn{^Y!bccXuOtL#$Xt-WoHQVe{B`Mv}!368iYGoIA+r@v3Msd^UJxQlEnjzv@S z<&X{Y{XGIhb`(%wwjxEkw6-V#q}A=Q)cQpPmG&7uQt|wX=dd)Y^bf9G88V+|D6}Jt zOiVIXBVSVx?A4!`)gOC1IBetp(O>klU-nX*&ze7v^qoI*{nLIiGrq2KRz_wn9;jmw9 z0y)rKuxdYd0oozCb#mj^%A!a&#EpjU=VUU`t_>eBW&C%0{l7_k9*~9qwLsH6dAiT6 zQ_@T*A!;f#B-(8P!oViCQi7W&l^!V+D56+@^uJ^*d$TwNI+<~AP>B_@SIPV5J2}ZR z5{u7&@RfiE>+bC`mvyxuq79*^AA){Z@>@a_}ZeQx%Uy+ew403VLFS4YsZ7T@W$Z&9_YbnX0kMcICZ} zJcS#`2=9~s_D^G=9q~3A8sk(bEc2Ree&aZJ2OFfbR56ZxZayBbbDJzYPeaIcMZRw4%L=Z*44LoHD!zN=hT58k5I>AQkF6GZXC&@YJ;w`3GdC zz)CCfcDpNtDwi`yg839w;fj7fz1so?yYJf$+sEIvp;W*X+9iV*S)LZ0F4 znRgHzjsF%4MBUPS-J!itZ`u75HRsQX=3JAz=IbYVp@kf{Bae$`LQv^7U)%W3?f*2f z%=Qi2L#dEd|6TIaBn9#V2p8H-W=kS<2Tn6qtG*5}o&$8jwHJZH|=RCvrAoA`RJ0H`Vz3TsDSZzzot|!M5KHSdjXI`^&>Kp{aTD4jM;bF?RN_Oc|PkQ zkjENDvQSw3o#O|J3c%$4t5-@xHXA4z>n&z!ANgU$@J_36}Z40dRq%a3RQ1prvxc-*Iz!to|D#1~dj<5<>wp z;By}NE|iWYlw9ooriN+~*LOzmw%7kgCWnG=28RyiSmeR>fbI2-vXURPNY-bo05`YTOiEfeZxo`BM@ z>KH*lu7-1k>>5WhtP0`OkYa7#MWDosWNvc=q?;E2I8d9#@$Z;`*VMgW@Tmv%x3w4 zY54^_9gMw*_5X-H{sO%D>`g9_f5ly8;Y0+vJaZZJd^kBFsnS*D z|Mn37>z}!e!TSc=zh{_Q!tu?iiIkeZsa*aaD*Qja0*#%3+7X?JL?1^8ii!zceMO+cvBf~zWmPV~YnQ1XCxtCk9S>=Y>hSBKT%_XPj@Ye9BW2=DX7J_LqG#b8Yr zFu;Hd@#yJa{J$7}w z+f*TF>>0|Hj>-T?^Q~9wY?Q$l@U*CmooI<2}Yee8_;Ap!%2`uP0>r z<~FItb#Gkj+)a6SaAsc2H~}iY+n4rwGie$&4v0!=-$-|q zftS!o3-d8(8O6_x+VBR#ReHmqHQ5$`Dje@8qN)?WzvTHbDhN_GeL%}F*@o*!OQTOx z0Z&NgPe^%t65-l=;t zhn}4dKtae}QSA1_h?=F;I6CFc)>_8J?)XAgyIBR25n2n5C*^_QqI<`7$Ng4-8}6n& z1%V@p5!!bP$|9}J2zjWEZCULLc9!oXG+6m8=UV#qV^`%Yggp(7NYdL9V$6&SGIUc@{gL47iXkzvh5C@g86MrDDcd(SmeTqg96U z_oB+PF3^uSo5H>Ar3DOmwH%5aYp_UN*z4CTlK4Uh`T>>Ih&kqndepggOiLYKAEbb< zXjHRDQ^YgnJ`~82(}@t;t5q{|QpN&zK=aHx3gB;M4j27~Ad|^*-}nL{1djJIGva9^ zn7iK#4L#Zbt+77Sb2-AJZS-(9QEKhN!Wws_wSNTX9sYH{O5u6ShDaHSu}>9BW7*!Z zL(`u^Q#Pu{wBcTX`H8uXKh!PyNuDWAtQtji=GDHE47$nOL*=W`Zs3|m z{-xVAjFPwV&6L~D4hiwCJl{DD-t;e)lF|{)F`tF$NDcH?{@GtL9MTMcUaVA zI}o1YNUJ!yU*~Ht&fZ-CJD=erv?EB=@v7V;+$`=}nH01EP%x)2|EvOvIL8ld3o6In z{!yIoGtFt}YZkLzD_9ARRca;J63_9f9DxdFDN()t&OxeK0YT1#SPAqsVc>P87gs|= zZEdhRZ<%h-8(012dhj+HjjN*E=P=5cf~6%jSQhvva>rFaqXg9prR(^*bsxA}?C^mh z=te%B*6WssnzTiQv3+0iTNKo?wi%l8Lm*O$4DU5N#WMTAnQt88WrsiYrWCe*sim*| z@19^_zaCnK%A&h}_4qBu$?O=*;d3TJH?vE66!g6t`_K-ef)EsA?+Wb=05!E&qZ>iK z6e>)Kf@b1aI;uqv-I3VcNBR84>AcCS=td+owv!vPz^71ibsRW8&EcQhH8>3S>qlC$ zZGtiTGwl^npJa%~6leOFF#Bg7HVs$KDiDByOehQf$zMH=Qu(P!9#l$iDw*@2R2>!gHdkA4v7Yg4Fy)Wk#dmZ_k zuk8@q9jS~VStoZ6S3^!48TiR6g*37J(Zt9*+yQhZ>@^O0LbkSxaym+E-g2Q#ycSFsJKBk-U=z}4`pI)HWVdH>O0mt1 zOeO@eMdIWO#Y&*c&k`%jIyV4>XNuEV%Tg;zwfu(M>6UIjM~YX zvnO`$-v)S61yWab_`UyYoZKD)`OyMPY&^T&$mpAU)@pfuP9 zhrQ;A<$0T-QuHyMSUzb#ND8{p@UgUnx6d{Z8^8qbg40S<^vRJ+tacJ<%jQd(YnbIAEY0 zwti`EW*~(6;wyuX+0@QrX#6v-Y>w1yX$7k(=VmAM1A z#VGYh0HD#eMaBkFzjVgY94b3e%Ya@3zui*cw!cAhO_`!iM&}p(OP3aKmg%on9Jyri zns~l>!BH>^u_9)7(tJ}^Ws}v;*l)Vg<#i(<=ja&BMGFj+QR}U`EkS#UZ~U^xc2XV3!Oy;lZvP5rcZIwE z)vvh3RL8WSzX64EH06gT9pgaIAu4kqf#SOLR+00&l1ML2FRjxh*xSg2ktFc4v+{>m zy^7R9h0m3?O%WZ%E?!~=?ozG~d}CB?Qw%+vSb066kLaHZ zf{P(Rcgx$S6Ni-Iltpm&2*QKthF?8&sH}HM%LQAQ@d*K~%0fM+zwknlC54HbV9Rj( zby~K2mAaJBvbT<)ufpMTgtWz&r)GDAN;YEPJjXH6tWeXl zJgXdk^;AbWoww|%@TEe$(S(hmg-lLh9JPE;QwU;`z|o@zfygL1BYUTZn8p{9&~3BJ zak5eGB&Dj#>`$->FqP}TDf|{{p4gSzqltleU)<8jOND`A!uDoNn0{Ccy1hk55mg@R zE(B%K-nxPtF;8Rd7Q(0@3<#4@Ae22#QA;A+wbvMw5um!o|oUctHxunUXbN-pT_>ZOa3EcI|HH4F% zcM(;HQeXDTNS-YwL580#J5igK)-RFXKRz)#GvXY2w#O2Cq4T^eTT#}Ty0@y`+i;yu z5<#99-+7Z2|2vy$$k8+6a8b~qjV(UuB|aI@QqE=Sjun@3xsw=G=n9M%F;XRf{2p%FW``|xd2&~JUd(7;FJ}O&0oi5k z#>S!dGN1eJGu1BsJ#8-z*&#fbS~Un4iP~I!&G0HF>9pvc zE#}^VfpXh9wq3F!*deHbZAV-j7qOK?BW!RI+w(myM(~Rh*XK=!T@cmmCg~(`KziME z-__HvGJ!2a(VAjc2o^+y>CC251?>r9A$A)N`po9IXIfxEqzk1H?D@0qm-Z?+^!&>_ zncck3sJzO~r1#+^yyGW(mtOvkKf})~2Py#k)ql6fk^IRNJg>(c(6l`Be*2YenP>;bntw9k$k}!>^hp@L0Gpjv^stD{>sgpl+4iuym z3)ZZw3Ul%?Zttbf5x-v0D}5dHw$M}{#$Bi=svETQ*wB`_85KVNk|4HsrFtT}Nv-0h z5HaXJ^rs@<&Id>`P47QiD|;VHhq1;CLmw$LPWc&I{1W=et{o=AmhYZ*@zwCd3OGs7 zSIOVww&;Jy!+?>Gd?Uxa)bBzJ;VGEerq}xPQ1+GP?_R-CQT;Jb#V)u4NKVnoZoYb` zia5WpB25y>_T~pIz2eX=9LcDBeTBv94g9pwH?aw^=d!?b%N~XqI`?)Fw7_Dmh5B^) zNV%uF)UZqF-ns7+;Y0eOJjCDP{WwVIsN&n<;k+I~J zCL~9i$MB7|{JWX(JE+5!C&<@WZEQbiYB6J{M;f2%aeg0?h>?nOV=(y&OpQamsC{ux z)gLBesz0}ubYCl6z4shruOCB{dMNsWXwxE`blc~d{WWi;1vhl9~fmAJE@8w zCwr#qTk?lv#^Yg!HfyyI#Ce9?#wFm;OV)xgS?k%%mXTf{*Hv% z2I^tM;&adbY~}b#uDGhutKusAtTzO-gCnxW%m3^F^TZt_U{vvfQi7) z34}j1YV$g`zF2p@{Od7ZB<|UdUK4y!2?%W`B97Jl`ui2md1UE@n#qcxc=A)W6E~NN zcHl2Rz0)lqpQ|z5^p40YZLzv3^3^)f#wCl#x;z_@*V76$M;B!~v!#u;WgFLKu6bgz zq!e^*X~-$4XX^xLI#+hHAaa-Lgv450U*uA}P??nt)DBbW=&CFW&hK&5|8A7IGEQcC zs1IS~CQhxOfB7*ccYvKTC85 zl8;!B_GTH1cX?G_%fEU^`0W|SsjBrBNFqc(wxOZ4?VTPK`6j8qDu!QN+Nl-4a7zBQI89zaiItjDZ|%@M|9yqO7SXoFH4^x8&Ox~rb2 zQ?Ta*2q3I{?!&c#qQD5J* zk_w>-;6&sje&@O~VdW+@N4n0?`SN>+H0tX!h%3I|OuL5hQ1iG@!I0j*{%WxR***ls z2k_}-_4;9oo090|s!E$uND!l01iNG6r4`@8Q#!(fIGbZS4!E5l{Z=shXORhS#`jJ3 z^-2ccB|f~TcOOg+b`@5GDsGjYe#x%%w5jQu4ZPDkPrE1fnpGi<@u0}^zq_0{v?mp- zs2f`17f|}gS@qX6LsbV+_!H8MR#Bm$+b>8JUeA_pR5%23Xs+k>{ZiH<+jn@fE?;^r zI=k^1iw_>54DJB+4H&RKu3)Pt#3&dpL#Y7-bkP;j1Ok+5182&isJqtVPy2%|d|!3T zM4FU)jo$sw{YR`!K2Wjv;B+53(W%QrtiqQ)_i`k2!S?h`2Nm5 zP;cAkf}+-t$=PMWT3RVd;r?xZ*3dFpA7*o52>h78OMAu)$$fW03QK(sMCz3gqm!(Ju6j)q(?tPGQF^7K|osCTVM0nNzk# z#~;~@HHM4Q8w;#t^EQo@#QR(@KcDUTnDVBB639&ZN+RgGWE!Y%du=>4ckr%y!w9?U z@V%ptSu!W8r2>2HXwlow>tT`#o-PVto~|pZ^3KikbK{s(G67$;&r;LSM04^9-ia)-W&fs_jSKxfG}- zbJkg2-c8W@r+c;)eY)KcyT?fJq!#GxoOj6D2nn(STN`eBF~J=A@NFQj4~;kIQmjTH z*2(sGXp^Y9?bLQaeg*lEawaaKb+6w1z&G*<)^4_P?D%hUS4oN2>5Ueq$*gsf(e$%MD6y0l6Q07Vr2A=dSuP^D*)UY4#_567o$&mMHtVdkp4@nnz zyKoJt=hwQ7G*0j4J7ZpSkG%RF0}DnPAuk8e7RTD9IQXB$?yFN6g23MU?RJH0JL5EL=PjB-NJv( z?HWaY3Z@9#(Mj09&0L!?wh$2DHEZj;h}fy@#+d>)`+;jg9>d-KJDC-hvuo6WMjZZx zO9jCcSUZ&Ez>zOPmwxY9%J=a`ep&UwjQpH{dBt*qk`lD9Zpt!!2UNp`*Hg`K(oe#V z3(X=FOaB%bfj@fy0q?lhHtg47H@{F_>0;USj#}hq$_V(*mEwH2^%o!(7hBrxg3Cgk z#DhZ$#lfRqtYAG4h>(XU2spEPFI>;_z1pcW9T-X@Io^%515J=qZ`zJORWJGt<2xZ! zAjow5-H$*nnFk_rd$l|R*djHv>FcQ}Rw^js6PwHEFA0%Zbf3P|z(u)KVDs_YZX%f2 zw=i|(mYDhE(1tz_BT-i9p7~md+NJqyugq0iwbxT;PtIJr{G^mYqkMBWmG}@n3{we1 zOG#c?hAr<4EH746kfm)zj?#HQ!elqG$+5z8ERpjr^gxGpNpO0eQ>eF#kfeR5KH6PR zS7$yHSwWnfxI|hGW@D`7sPk>gv+2%rPl*h3f@NGrXK|^TkI5@qcA#)3%5@7rf%S); z%T)BX))p#9Q+(2?+vgUcT3X>Cn#)()MH_kSvM@H!-n=kGr)~>A;?ff$%^4e}7H?mF zooR`&jjj>=k}CsdjX$w>)i%=>ORG5nXL(MS$O0P1TMgyb-gs9}%1w(|>K+Ia5PtCcx^<6!V5H(F~Qoit$r60Mnq;KT- zm|Rc3wg`VdRWV^7Vve$xu}JNclHfC9eOliUETv0jah^IXmpYRaYVT4(V#aidYeUgh zgW{_#-|?v~fbX&JL&Bw8D~@9viOR49ZV2Cao#TdBUQPtsmA$h6Nc# zGdQO;fASx{EsPIC6q*>HbOOwLqH#3+c@U2)8N5IJv=wzqMd&S;Gkc^WKHnmA&E`Jj zD(O+Qa0O+0|bKP)|V zWl*csgOMx+t?3fs;uU`tH0++~#$d|83+hY`er6>-9{3eQS87XiICcW`BLuOm4##b!f=gkYBz9H^o>GacDP)U|D zr1sP+383xfWGhX5=ic$OMH`>~%HnWhJN~8JMwpyqEk`_h#sDLE%^^X`=_=kwdB?=- z{g``s2keO5rmNK;Cvy$Pp1u?A%0_YcHc^@Xg>H8VTl^(e0vM+ctuiyhknfY zB;R*Y-~p$u&ePyGY)2{qGBhnBWBAkP!&ghV{tY5$qY)LA0)Oa6F=x))E3{>5FGq!Q zw zH7Hpxm07SIfO_rwKz2p1i@;VdR}LlA%`GvG|h!|x^go%-H`Z=?k0(9u95(38qcA_*(%+|%02=S`sXV@`G$RW&nYjC z{)smmI!Z&;XVL2LOnp`~tVkH2)3U@?DJpLrjRKHE!e zr`s`(f*zR*YKt{44qHOuCLe}B5ES9#Mbl`wC3p%!y7ap!BJ(_FRTmPclXKPmq|a3+ zVXZ>?b~9WHKF27Mbgty#7;&#IkZflwYBUv@3Z}!K zv)(}I2q%j^-XDmj5`5#v0+}9{nW~K+UW#`6_7IZheR}k#RgofR^oMqPmpOCFTvD)5r&eh!0CCnEBMS`;UN3sukN#HIz(Wm*v)vqIT1^EYVJsP0|>^ z1*U;i45Z@{JN4{KqVj2U!>A$MALFGJFhU*>*F+&lsh$yAnLeGbPY!iX5<}Oj)*03h z+=-_%UM-j7*+P~_CG5xJR6!+_YYE%^YW+LN!cz5uaiYqh`wEu<9m(M3_@dvh`7Vn~ z4;v|ypf1cn9h37?zoUMp;Ln&_3{i*D+@SilQ}h0`3>}Z{wNzn_16CrIln^PSa3pLb zM1=;0**dSG);ImA<~f%z=4*fNxee&H;WVCU<-5;Dzl@zZi9@;(Nz%FamxOv zM|jUGX^e6ie^B*=#A>Lp5kl1@3fgMJOyWMg+V<$;S?3<2wFn7na_x&-EV=*qjUnPo z2;wQjH@RBxa&0mN^a=Aj-Fgo2y+3>Dcm|(Hxs-m9f}mrh`MWQ#&%{~)GiKlL_f~?k zD9pcZK6nEb$T>9E6U@A5u}dwP9CT0|Jw6aN%Q!Z%9NN5}y32?@$6jy8%b z$4fm42?Ba*tPRiMxbeKvV?;T^oQ4UjocJEbS>R#LAyE}TZfcJdzyQ%&eOUUs(#9O0 zO-mArCDYvSd7BMV{Zs!jluzY#jZ@@+Zz+bZxODsvL|)=`<~3m$LQ(}AY}5`~61{=5C;0(-75*%&gc+T!CI)B&R!3Ng6w16sg@pX420pfzi5M z-fW30cH`vfXBZoM1U0Fsd4i6gBdg+c=!d5;`+(JegWkQaJ`NEplt9bXqD#oM^@0DLdO(%Bys|2JE-rdA?De)CYxV8fOnsSW zL@+m`MD{!3GDtzya+FsyiM-y@V%dlD_B1>W{fIpvppX62pB8G05f+5p`5Vbdw-S-W zG}7LOP!xHqQ*67CoZ&~9=t&N&czTz=qbNo@1D5874rM6v&2lEJyEn~{PL+C6$Yu09 zg>f^z zQps~d*y-{{*>5WGAfi{lVlCk~*W7a0!FY+n*qiAe!f}HiW8jI?sEnF}LCx=l$+z7% zvFwI;TTDx4fgxytp?BCLSX3;j>A$rlUIbNk3r7fk@e)F&(x0db3P|emA=zgipHU#o z$xau@hb=tjuvSqLj_Fy|DyT54_?`eS%5AxDVxY`@HN=N}`5yXsh(B6Mo++NXlBNUb4+ zQ3T2@|Wy+57+7qb%D zsg%0tM`Vf8)p4+1dRh=ts}&_LgEv&e7XfKq_?;cw{uPH1{ldaM@$DNOkoboj( z%Uf%w>r*RLR^C$p?|Cf`>@LLNy;7h%Tc}$N@mSPWt{jwhrrUldO9B0(5=6Trtw>5t zKk%HRY~_g#aaE7Bd`D=LoL_>Ucg&#(}kSj zi+-B(Z@`sD;~i5RcXTr?VfIOAk=l!&G{Y9jx{S@BCapQzMSq$mn%DPMI41mhW-_64 zkLt+zv(70BOgu_o`-oqb&7<4c`a(|q4?^F3$ zMm5$&H>fMRE%gi~UOb_?dQ4=Cdmh#9)AyP%hA!sP80UL=YN^(g3Chqs!y{qM>7Zo| z5gV-PZ&57HDLStrJiJg_-+XmXbQp-N4+Uk(ZX?JBRJ1mXcR$$~r9|_+Kc1Y*^HY~u zUjTr~*r`fUj`Az#cn-s|7RK4@(NPR!Jnxg@8Ve(siW2w zET&&Ik$s(T;nhs0;7Kw!B(^ghV*O8Im3Ogpr4sjv1F8ZT<)j9tgOsI9}sxE0)lTlQ59%9Se99S3Lp1!ueeQjl5NW#aSm%IK3 zNgNZZHV0NDpLI+uhAlH$8Q5r!U#dmUJYj>aj0<@5+jYCS4t0?_v_#F0=Q*J%>t0L> zuWpSQDSXO9PvHw3^<|UO?OSQ=4DYeetW7j29zcAv6L|%;ygn^miw`?|@!s1SZ>P8U z+a~(IB%jO9J z-9bSVYlQC6wopAP-;-a95mGQZd`Nf{6UkLoL&Xx+Ew;7Cm#A^QLpWBy0y!K&4rR)3 z93>5xW`jAQyA|Ixvdw)tugp)8$pno&oMxCAEM1cd)F{buaiw&hXq1-`v^TH4DuKRb+(NrQ;LS#msk9AT8)Pu^McRX-(`8doVr);6I?6E`br)7>7Gj=ua z{oa{z{DBTy=@QVL z(P7O?hsTPr4pP}WcMLCqUVYX1-X5aknIyEC>)F~8(`-%HSWWunBQNnTRHO)Z6qA|z%lCa= z3d~R)UTxY`w{#f_+}MYs%+0d$pCkod84~s$eypQSBG;j*-t7dTCrf>(13HTHRQesj z#Z~+~jkA@O9(oD)>C^@v1}Ij*(7n(?@i-EJX5b#YNd9HaSOQNxA`r2HfUGw;t*MVR zJQuqFN+rDYt=@V}!0M$5h4?{B%}R`rR*VCNm7RZZkW(tkwqKHboPx?DuD#{4{4B|I z2C)|H03OJRQkMs+&!ohoY*F#jR|*X4wF>_vkOh*Yyx&_$^-42Im z<&vuiAV4)q#jgxOG#I37@b0y#$_kRfZ_zU8>D8iZi0+;C3?-o%1;e#To0^#f-iSpNXci;DI0K-9 z7v|Aw_}Z{rLfx<_;Ypm})_z0q4cSzP@SwbM>$^SzM}7&!;lkNl6jLi?!Z55|fk%Hre&}`)md;}?II@(s5GMpqUu{51Q=hiaTFv>0A8EG$lm#vW$ z-$x6$%*JGIa%*;&#AG2NgDqcBkOw$_{xE*&bw+NI3=kQoC0evF$q6O?@&OfM(2`KO z+qofn-iYtqN*Nu{?SFz1Na-<2JL7+UTcgM~_p}*Ma;}r2n6}~Rt#~q5?jJUcW!Q_YZ0JKPKV-{M!jW z7)kz|?AWn^M5+hi!bl(VWrqHn3G#0a`M;9;CuI0el7R#eMzhu|+2Ng#pokORTiyS@ zz<=Fv|FynPEBUvjk-N1i{Ra_TjvK;98RvgqLI3HK0*BB6eGCKTlWjy8sU^tpo(wwn z4y^xw3`4Zp-||9d1K-w7_-=7v^Uovo_oa+~{hP1EUpKL-&~x-0?HyQ4sHnA8tN$NY z@RH+iSJ1Dy!ZiO|Fvn!MRo$OXCL13SkgC<|04dWFlcT}ptiJu0y&0$})_{ibC)fM_ z_cKt#*q#5kFG|Gy>tUN5ja@~YeoM?$Ie<4hOu_kWcEC+sxoryQLJQ1*Bf3W4p^?GM zAK*X(K+<@}4loaXSf*JdOQ(D0GWSm zU4K^54@i#%Dw+O3fHkjLAN*@IFm@8rw=Vcl{ibDwa_J7Z(Zo@@^wCcJlA#u1@!{n7 z3$p@+rTEsn(+Xuqv^Ho}R0y{}fRkXvIwpZTaN@3t187q@Mpyx9e?3%hxP18O@0U}c zS{}z3;g7cEX@-D1LAGxOT;ry|!8pw|q=Wo3 zn`*-sh=`d}-z=i73@p9*&HJ1VPA;zj&?^%hq)KUB!glNfJ4M<~exeer?X0$f;drOF z2QJ8@56VhB)B6bu9BH?JDEmi-cSZ1r;O=6Xqpz*UpMsQkXL@HpKWDhezt*=fy~(6k z33=fAtylD{$_@y}4qJi>7Tyl%mHLqkln-*DyW6818=2l5Cj#)4|MmTDy5I8u@JL0Z z#GAru$Msm@yODSDUM164fQg5>A1QD+OLkVav%*h3@QB4XLUZe1`T?^E%coa5b<;K_ zJKqSD*)$TwE*67*HC0-`UHxdgzumV2;^JhgPucpZy?3hO&Vjon_wqd8_hx%@S*Ek*$Cg8DL zF@R5UAzduY^1JdNj>7=8Ab)evt@XxZ*15N~g5=W;sJ^3{XrV6S@tSSAeSo z2<}-;oEXd}{GsvHNJ@1ujv&+^*sa_3+ekikJaJ@)@$Hs&U_Sn5UjRH?8ehV+mj~$m z@^0YsgXh{WHBQ{5nB}VlI%@(;;v-psMJb`@z;f{39Ne1>G-@PGwzp~bfig)imA9P? zI$Z7ut1B*wUIh)|iaz|cvoQqY0MxjK#*O`NWBR$yevji{xz(=4;EVioQS+a7g3-Ti zW<{E&!UsQTpZvi<(c!&YWfH^STnA%GbsAKuH4j3ipe~-a2+ex{3sG?RZwM{)#{e3= zQ;ZswBSN353?)$uLI}0Uoz;gExM`jTsL7)Zqg#~!sQ?kCiS^w?``t4gSY9a_Qj)(~ zpWh-9bswBDpP8&>al1l&pK6L>gCdRNaN2$~Rxv%WMB#{>L?mIVKw9YsmSdJ7u)Va8 z(kR`i%H6Mh`AP7ZN#q3Dk&LqWv1^Os z%^zidn+g9e4O&72(Bm=nrKDVtPL41GP%FB^Z3&iS_;v%DBp2kw-Mcnrq_U0Cj{OJ)76tsC)f>!|*!OJw`0`+k+h%d@~r!Y|Lp*P?DHDdU? z6XUNf-APhnnDqk_zY5rB4_I;@XrDOxtdQFV#*VlE0d_1cSVMP8P-Z=>81A4|!|#I!!HIhHq8hkl1djk+$Vkb_Lefty8-UPda5RO{+eL1gpti($6MFbM~LK4UmiOQk^;Ffn^Sa3>8@Y%lxo#xoc zhz~^;1CXZOAHBI;e39M)92u(N`+45c7>WYaL;-6R92oYKMv|tm7$Ezs1xNNR+QCKF zz+o$BV+kHamY|1mat_ER2gW_Y2UV*&q`ImLaL#=Cr44s~pf^I8F~0#&A5NxP#|_|? zK5}00=SQ?a|2Z`2hx+h=k>n=QR^<1`vgpwfO3D0nQ!84B|3Wf~;>_0+B z?0>LMw>Nz_8&FyHO`62ed{0YAn(PkjKKu>qZ6If==JZ*@B+~&Dd$y`?56R?j{UB6S z2Sy0aK}`<|LHmkhosB~vZfAht;BoJatx6$d2x8w8ILjlL8<#tHE;qRB#W}?|Depw#V*7hT$W(cQbxGZt;2P#sOVgOa+>EnT)r`?w+?Kf+yJk@i9@F-Q> zE-?B8Bn4qy2;9oTLqGY-Kt+4kO(k4vmLCwBx}WXUXyTsg9swnEQP1G)Ha*j89GD0| zoGhZHR~7u5L7^Fka>}gWgO-hVp1?+iDm+ah;?OLo4lj;5wdNKNmw@Il_rAk$E6Ux+a4)b9cU? zmKKCq>9(bW#_lh@U;Iw)h;{h`D2{ZhHRI$w7;vbQ7ypIh9K?6tf$20Do~ zACSIb&67YBSwVY{McwyDwv!4=vv8g@E!*!--q1tFbh`v!uw`I-iFahbWVV)s28eeY z=Z1&2JjgM{1Dx%;QSZ99;+}qNr)3jyqct%-wS~Jhn(IK-Rq&(+j>DXR)g?-lUt;UY zR-8yRQ{1v^??^6TUYy8fo>krUh`~KlkPdg_xQm(|AC-Y528-3I4|x&Oy?yG8rgx*aXyqIx?Co@{4HNYH4MM5ogrS8s@K zhx&O`Ih?RO1)8vk9o|e+8ze9BvY!QiXK9!HIw2A%TFO@STDlSEGO!f}^2J-2d@=~i z7-oEqf6PR(8T91c?A2ytaUA7$jN?OZN<6J9*P52zk$3ST8wAG%@&(Yrk!c=bd7T_# zPfuA4j;X3AFI3)22Izo5EV!D?0!rKpBvuuq?Tz6{SPh&{GzAz;S@vIly^x5|2J}lc zylq`(G&#aGrnRlG*H3y0y400Lh}g1JL)83L-%5S`^BgMsp+ucL$O*|AK@H2j12X^k zU@O4H`aO}eJiOkQ<^%FnRE9eW*FpR~v0ysF4A9S(m-JPqY^BpIHJ@ac#*b|T#6uq!!$WsGf(u3JND{&;C$GV5N^x`@z~<~e zV>+Qd!A76wyTGnO$WhDyW!tF=Ksm|g2SyAw&2v&6fu2FxSXQN~fEL|C@Y53i>Jd8n zjVexEs);S>6-UxRi@vZ~xLZK(-Ke@UwuLEX0H@z!lzkWCw?Zi#fyenm%tGcg zPWoPJAA;ZDwQvTI4{I}eMrDf?W(D^h#>e`6!$7eJxD@#hX(vef(a>elR40U-aI2|) zKmKWN0HXaVh7|rBlb6OJR`aBRa>`KgKfyspK_kQiN`xnBsAJA0(aZ3i%R)ss@1Qs6 zp~48AE~ur|0P~DqdWSb^TViLEW(6F_sxhX_F+l|{J z$$=~ph+Var9gG9fk9cj1zxN3=Se=s`8e{{7J?>U(%~bn)#Cuud3;2b}N( z3s#vdqoM*9^r@+swO?NL=GRyeh;!+4RU2Bc$A5Us6yHUCg=03J8}kpC1aSoL6sE3#S6==(4A#UZ zSKI%^ozw-}Hx!-zE814oRhCLB?ZresB_WZqj_SriIXC|E5JX|lMO~zv`v+oI7H!LX9-O{~j47y9YrIALZr8`Ahx{)sF z?vn1>bSs_G9lmS-&$-9_#CXsBe9|ut_ukjF=9=?YQ^eEHO0qc|0J39U*Kw-1`{cUE z-MUG^!)pIhx5D3`VIrC^hF3aU`9JAz7t_}S7&xEvAdpH+$vz# zbt?H=_-3$-%&r^zcUmZ=DnWt=WPu8qGafHX1lP1#eV|W&*%)zC_#(2Y|4vHPD}i?z#-1A$rXZsvACCl%_XmBWis#d3paWJF1f%Z~N-^OoSwM zj`j7=fVQwos?7&@e~QI?U%~a*TLL*C*$jw+^`L{Dk^g@P-M>%s_|s=K`Z}{o<%rsm z<~VJe9Z8)>$yZn~yzL1t0s>oxidcCKRCZt-lB+buy8Eu)?1~+{;7-d>I^~{F zHz*6vpWmEDu?k!RK;KA#hd|Qrl>XHAne^a(Cm5p$k>D7^KbA(7j9 zpQR$63Z#ep$FsS=R zKhjPOOoDnIvbgk9B#^VVlZj)&U+#uUeMd7o9f^nP%Rb~Qhfb`qyW-}3!{Ata%AZVQg9G+*@ z#*7!4bwk4nQ@EfGCN8kqDn1zU2UfXf^DJYbd^SL6mayOsXZQsea)T9d zY#ApQTUP(`h)eo^0n*B+&ZY{oQLdJ7Wk$&nVXh_g(XOjoFnL=;K^xH2bUkGIK)jXN zWC8F|ojE>zbnOaemm2(u1JO|e1e_8BMsDL}(S7fEY{Kz|fwvu;(x?h`(n(-m`f`d$ zr_2HiyLgQ!2??uY>5;q`^LadT=J=B%!hC8a@)HKUMp5G-i~ZzZIl*`!b;>2x>dcN3 z&l2h*b*Sn3MFzjG^^Y0-F0tNriy=x-bpy4oHd9eVOe7lZBwIdYIN>Q43N7faEp6qp zEL-`E8NbnS60P4*(OZ6QCrP|dTfj>C4o24BFDVIN9{58k<8sG3oGg8@=ZrC6&|P6n z7!*)r!TS9334*Y!?Y_PshNaIe9bU!5^Sj2dCvfI)uh5-911-ZJobiRv2R2U(nUOQB zxvu|q!4>mEG8Wi|K}OlOlhwM}S`&3I7K8%0B#7$HGXHmd9GH78>%dCFh&`Z@dw!w2 zj;D`w%x08wtc6^CRI2%WP2Cz2si2hdpjAd92B_5{26Tb;vBTKwI zz>I_@v=&s(_1Tj!p7tugOIMs#DXT_*w#c4Y5f8<)ItlfKClL)Pb;yG){y@xY#VdDx z{WC_>AIBYpvy8x2y&vB2)r|4k?vI;04 z6Uw|76IJ2U^8tLQSabHnY^7eg9Hb&)ifQb>L}fDN3vkwP-gpQVbx(-uJ|5Qnqb}ozy16# zzlaR#fX=k5kxWiaq8tlyg6Y2yuc@EBBukCG#QvW<-v|*xq))9ie-=Clwb9k_9Q8qt zgSqnn9iYgH2-m+Bf@YW=WI25BaX}7EBGh-Kg3OiPUCf<5`3=j3u>uwu^{LJrb<#X| z*4A?^ui%f$Omk=u;xoL8>fu*%$}9G1UfqnsS0%re;Sh8fb~o~0;B*4Kk&BvmDNNVC zGdT4IljS{?p0W}aOqgXlKkB_1u)BdnVfGtQ=-4kR@F7T@MOQEPSrw8~>^<$nC8^)E z&|Nr9r4)wrOUR;$IW#bCX2s(ujSK`v|7LI^mNR!da0UKcf0#Ne6$ix_8agPM8d_gH z-g>Q-sQhyV(hOeOU{htJ$yv12^K7!rOu!cubmfTl&wtAK7I^rwnF%vpZf>o+P7TL6 zreVo`$PAJ6vxu~&#FI|lBMJ}!v@M>2_7WMP{h64rv{BR~EimqWbiV!_w7(rpV@lJ4 zt_8(T7p&M}k7@A9i_9t=*pFD7U~@|chGezG-t%CWNJ#>1+Bmhv`F36P*ZDsJ9Hf5F|8>yOiz21S;GfZRW<9yz?XGAE#}``? z&#DGrGeWh~0n^gEWMAbz0U2e&rFH+knP}(AMMIrbVPwp04#mR`Bu1184v+di1Wkk} zju94FqN>vAg_kT48@Hwxo0;1|cMkBaTscAB(|aow<&8S>ul%lq4t^u&8?j2GurAAk z(Jg|S6m^=q0|h@4SAd(yNM*R%83!*5O91Ab#THee2G&-lj>VtBBq0=FBb7rS!&j{e z0inGgIWU!8i_{)HiX=;-N(%*$86Dm|@Kox4$jlW-9|p^9IYoAX!XMrXUfF^$wK zw-dW`%-A4{ubgYUa`>Js%Iwq= z37go7iG~ON505W}Ci8;lN_m`APN@T%2=y7gV3tT`4v&Or3v5u4vw}%^$mAwOkqG7? zD=K@l*euKPj%j%YW6!fY;k{{e#mEXoF3a>OTT=}1Ah0M_`B$BAgQ ztieBkzhdY=c|oT~^J-=XVy_}FjlGnl1lBxFA?_j228$wvz7}}XtOvS*0bYRKe?#V`gtzre}sjDc!;@#uhvgt z!XETJPr&73>XLu%_UHs126nLTm%-Ju|AA2Vvw*$(f_U$W8ObfQ04(28(MHUkNW;;K zWcYv@@}wLAD6N->67zZPPUImFZ>IM3|ACi zye=3;9(ef8)eT&}nFR0&$`v3cu@^E?g70UQ(Do9 z;uL#&{6CC2|4chS10)Tra8TxK5)Mn>16vnN3)Fi@a(>DWA4~e*dX`Mk-m#m4x;hkW z+4^V)l8Q`0jMYZ4={yDu4}W1d0*H?PhyO2@*lz$_3m@3WV;l8vt2Lznaxq$m)Dve z0+4Bk&10@#;LlhXOnn)X!4Llps{zLTgIla||INx}UA-CLIgDpd1hfC+YysrNWbm=^ z$`#;({0O_r>Hx9TT;N|>?49m_3FZz_Op$Zie>x!|u4k})VpgCQ?H6gmVn(?@?t~Nm zEDbL_<1@;e67ZrH>c*Fi0ATw#ZBTfdRA?KfWaV4_Nd6 z(UJKL{;M#@GlwCP$^yWGBd)v$b@Tt_1^oB(3-|dK%yD86#&CrTU`qRTA0PMs2yyw`Tyf{{x6K<|1EPF2>O@8>c--s+uayQbxN*wmHwX& z(Z9a~+P^hKmd2 zRKCcDgxd*P8z#Z_Eu?VnXRt821DFWna*(+^zcn!iIaD z%RufHs%{@}%~!)XzT%o&vR%*s4ZyCr1HcC&o%MNdZ}0NMcZL7dT{%s#0@(W~NF6IX z05Z!#a=_yov6Ur`{OhGN49C)fU2K5sJfyk;QZp)88Yoj@uFTS4vg^+*QA0q5i~;Jj z?f~YV|AzzxOxNhop*pB6vl*Q8KvO(U}e2v15k+5R?p;OaXd|dXX9GqV&&$1_$o3X93cJAtze7hT8++FLg4a$z$SR8;1 z=4J($=L4@$g=%sN(%p+{0Xa&rrM;b86gWb7uT$=^ynma*aL7U@;8S4F6|%^9Xw<%% z`@k8(f6ySGe+r00Bbt;^svuHm<%m4J=e;)nmoJ{sl>=Fp$J){xnw8~(#b;QYSXdO_cL0;c}bCGV8(Y5x7`log<< zn7+Lz_gQuaXoIdWh{IwQ{xbNx&%)^wsQOm3iIrLgLI8bVxY^%OuyvnIYCEDo%#>Mb z7|o_x0GN(0tj*d7PeW>avfC)s+ohVV4N&p;d)m3%*(?wG`)uy{+51qzOlC%u*VyF% z7hlL4fT7m0dyNch&F3GBMChO7{yWt1%_BZJ707fP{I5*M_eAXVq_VwodDA1DLUS>&gigL|_su=cK8De}_1xZD>@ME~)xR z%oz4_5`^KE9U%RdfO+CHL)8-Wh5uB#Qt|@L<)`V(kj}v+Bks2A z+KnwmdnO;BlWGaHO+H~w1Bj6UGOL`kdbs_};7Hker2GY7-x45s5F!^kSc9 zO84RORHKl|f1W+d*wNG}n2=%31nVK%2Q1 zvJ%s_DgVp^dFNbyC@Bcz_zH4vbOU&IO}m=^oWV9Rmx8FQPum9O}zF3hQ0bbkY z7f*R*?+aEmMk*Ouj`0^mS4+8MZ$d0HZa_gGBt4{Awc(PVaI4>6J10>O;MGxC8OF88 z)S>Ck@+KMJgH;;I3%i#0V}iXkcb!1QR#TDot$sTj@K*e`TI?T2cqW40k<8IEW&JXt zxYKGrY6X3u&Iv`yAW$;A(WW92p@R|06;&T7jo}pRfhLN6{W6orH;2gj{kX33~0C)GYn zqPrSJBAHPw|Gb6ONiCn=PGWTL3Q;lkRfO5n{Kt&<@5MLQLI1=1XTL|wSV;f04YYC0 zv&abFcT91&;D=XLrnbxaJytLz{F&66rb>l}=cA42@Qwwv6kw!U=@P!h*vrx|P4+I$ z_Z4b)9ek~cH<5`ol<~(0uA?TE6%mr}VjH>w#@KyshLq7MVQU0OSy_ZTj6&!VAbOfa z`KK;w1T&P!9SUTb z-Y&Id_oegXiuPE}A7ha(;L>-w5IfS6l3oRs8OVfU6;XOKnuK;t+Va#~XYWZY#r)D+ zW%xm&&pk0WwxeVXLM{_Xi*mAy<|}Jh3&mdNGy#EbtIKTS$z@2k)0LTsSose;|Ga=*kn33h;Wa7W_Fwf7tpo?hb-jL=ujWo6d z*b+LvNuAV5`0<4lQk#ox4^mZN(q$cs?D{5N9^)W}~voSg&i zd|8=i-_gSm@RF)NckrPZ>)!VTV4ZyZJDS8*THl40fr$|8XJr(iEWE~-wOZx>v5g1K z?8u4OP}4*-n+u+Nc-JE>5(xn&6&!<-V+Q!^uk*0%ibnku%nL@)S}z=#%Ry>lp~sM$ zN7Tk3h`TrxUo_5&Ej|3)xKc=}u;wi55p^{kltfVN~^r{3mYB~K1AKw!-&Gy9m-t6xN)g6SYi1r zp@W=%{~gdNBqWV%q>^!Ee$vH{q-qBLVcm(Z-t;?l%rhHAx)iJhM`DhOwr0SL`s4UZ zn$+=hK&kLodTX}_O~wP@Z_kWY+iPX+EOBPrGESToSKpGwX<|>a3vGoF^ixibW5AFL zf^}pRj$6wTYRb!84nsLSqVfC6i!mVjn!W|HR#L4w$h|Fi* z&+dwAEys*1@cd>b!B$kAtHOeG6tkV&ieEyT1xnsvUKhWkL+_>U6}@ZWP_WkCiT!lP zg|^L7wy-Ux5<-{;GW%wUgYcyK`0O~9cz{zr)@%atgFHmU$UMUXbhW4_Mn5|BrKrAL zFrtPuN!=v%iTqL1`-~-uj=;vYNL(C(+ELbDja8OuG&PBNW^<#QT_Sl_s=vt`zE9q4 zEME@3BJL_cbB3oIet~o zKNEFLd{7g!fWTjk5v{%PD0h5I>K8_v^tu%~e#XYd|mdDhAb&tYm9yY;9B7~x5L_z^_0*-tcC9GCn9)-ARkd+%cwdJkd?{~-7j={3XJ%tvY z;^3mB)MU}yU6eGKm@0j^HR8x$&HBr@*jBoD;(PU0up*ai>uhQpsJj_LQU~X0%b>xL zPJ8zCcJnVHPQrwd(+?fL(X7f>W@8O~x>c&B7&YII`(lTa$8Z!Xv;&o6XMH!UVJ-e^ zj5P9ohx;Xy;diiNwwy+3%krRkh_g*s%^`z`VMH)&hMuU4Q*({j1xVz8_8(APo54h3nI$xUL9WtB=(8PPs~9XKyD^oqtIZ6UQcfv^ufD8#jEz~9`*=o!`Fn>XN!vFZ(41U5!9i3J+8h^ zuP@TC2J}*I(5=%iil#jK6N=fg3_%t6OpRS@lXhvb)vAl(7MylqZ^*2>uXB*-G zzx0&U%=qKwqk_!B{dyg!qQKho8qz6t|P>NlEvqpPSjy{2r~RPY-U`cSNsb3)_fq*Vdv})tN)sXQHTm;hCJ2nD^chQxZkY8?pq-*R^5P>=QikLd=rvmVJFqsm>t$ zi*#f=7I{6jT`qHR)ujTCEfa01`N>Q5vTV!FxLaksKxev;5Db>jiO5c^kmc(pC^24^ zuM4xL&IbA)C!y^1)2lO=*vna38}6|H<9K)V3(T)p+&6eVzjN><%W9D}9;#a9ldHn) z%H&(*53PmwXOZJ~5Pvn@`yDfd%hBo%HH&3p|n+F9w#x@G7RR4wI=mw=V*-B@&NKHkE53k`qr?b1&VJ zJoR?8ES2E*O$6R^N!l@<_efVr5AOwh!nz_hZMPhLnSOP9K4_(jd8^Xf1QHt8;WoE* zrJTBi%13vfg0y$O>mK~iRurXpynsQd0i?>OE`yUY^3rTfWijMqTs>1qfGq2wt?ps_rq(a5NK=Var|ZPJ%n)-ORvNBrcN*RSf;$*L@06jtr0 zP9Y=Q&@RB|hQz)o7JMZ_?lh%B)4A9nxeaq{@Fy#V8CId$O7$z1xj9v~L%bTHrciG% zwgw<5Jx3-W)XuFKOw4}cNcJI%pcf)eX7&U6!yd%f2o;QKcNguYb!>etb{~)uI*o>2 z<+g_7rPIiIr=|-^QPFkaL`aI!`?Ca}uvBIb_f9u1$%KWJ4$Q3IWY=}#k(n=@tdZc( zWFIS(TmGfy!-?su{;;H)I^6x0W6h-K&94POu%vY2Pt<#?zn*#wc2oND`s_ z;(5;@_A>}m5DzB`O@exj+$L|`wQw~6?D~TEex*S55-GAWaVv#&9QBJI^V!R2rtWOc zs!o(ojo+7jB^&&yC6X%1YuS}QDyc|=F{3esxq#pmM=R+~DS!WR)St>LZ&{I6AJ6y% zJLXG((1?yxN7KjClD0@8!qa5n5JQ9hYCM5|DmvWuWhy=P^67WibB6=V;m$WiIx0RU zgr(Y);=Bo`8m~dLhHoPQs&X%kQ=%Chc|AoIbl~8EtBEVIpCuA%T=6zprXAyEWUD8e ziX1M9gPP@(nYE(JUuB)7-Rx@zB9;SrTvli24B`rN*b5!cEDS~iA$xVMQwi*#StJ6% z%0VM$*S}m&*UqR!r_Lz&bir992MX)J)jl=J-Di*SQXb{fAXbhvmhhd zQHQWN<%4jSXvx~$3W{~4n~1F6Vp!D_9o`#a%uhi$Tk^xjlv`pgx$i$=^i7m0&Dlwu zghiapDd|SfDz0gbiI*gE*p4p+IlnLgVJ_WEGnc#@Bh4GUjFD+3j#bAsUO2myW|ko* zucvNUSsoLI{`O)Ev}b;f^0QbsLDP~2!hp3@!88%_ISyaOwc(y3K2p*eeN=CorhTs(8dby7OF5LSs;#HT z)d!U+9P2br9zUKkkJ}tE?MDIe$vX3jHXT8MHVjnqe~RO@$GURmJK=N72+2y->(*q< z<3hje7bzOQcj_}AufV2HrFI2~!m*v1jsCRvzg>pCT{iGjWZUa-;gW+teVxP@g zuXXyHYshZgY~~TSxeu6k@4mA@GC!5wYHlTzSr9AN6}Fv_?<#3WG2KPU<)IUYeLcHQ z$LkFbIT7@JT^ZNCK}ydT^Uh5gH|wDfl`26xz{&7?y-=O&?kl+3lcWRliC~kW z)|aBV>5#4fWL*317!jgb?OoXWq2n^`&>{r?&&PviWXVgyq?Zm~Uzi^gOz+R4kaupnF@ovSvH^Vz;4hoF;D>1b6EyY*?@p^#AQcU!9_ zrgrBITiiL-W4{xG$GtV<7drk%UhfAkFVtuV^lNn-Rh;;GE8dnFDwK)aK`Kw(abq5f z)z{)%h^6ymz7u>fBzM}Bg-R$aE+(mD&`VklsbR5=Fb7eP!a+J3a(H%SoRE>zjhiuY+}68p@C~l`{Waov@=a>6U*6peG{0hETWw{Bjshn!PUJ=Kt0eC zh~KKGhPASnF^GhKQp~4TKz7_(b`p6+zWDbg!^CYJRI&69@)s16^Af(j)cC7hOUXX{ z^01sQ*sRx21i{%3s zgc{>x!Tna{4vNi@7lDvJCPt%_l8&D2=~B?yZm@6}!>O^q;fXvSvc&Hx4-1^xnD5q) zX}2bAFNvF{g{<|`zDOSMj=#9TV&h6t(c6>U(_XjK88T+2X(RkQiUZl_A$~;_Ll6K7Y=C`{*J)g`b zu|X^Y%Bd6|>u~SM{{0N%3oDNJ_p;orISrGVw;=rKIV0XOh}`AVK^}H|Z)=Zd=kItJ z&|s4S;o5np4WjwLZWFw4oqPXtH97^sjEXWGDWj&4FsP(;(DgY*-KyGxiI)}h@gJJ5 zELK>TR4dC%_O}KD*#i6EGlDaf80Cyz#PbQwb2wTtI1~Nv8S3K|gtnd(fj=a=>Aps* zW37KDV|FwE2E6pL-5qTVa2blk{as?V~6NKsDhc`Rj4>!HdbjZ=Z|U=swBb$`M%Q&ds+ zG(6X4wFE^f{kFZFq5;&asjp%T=;3O6ze<$iRY%%#6id0)CO)Q>2~J|+4)>fKPh{6L9o`giP@HYi!=6Xt#jghWOBe1{BQEbW2gVSs zoay?Hqy{L~y+Cj-qt_d!UmB)FASPNwHsBj{^>I~!eHJgStj($DTyDAM={_$b*p-Hs z!W|{#Bt5&nZu&|5#S(zyjQ^p$GEy!8E&iR~A>N*Ws zYR+D4;ijzOCft+-S473--K~?LJ;XRB?9e0~E!w_bQ}a>Q)3qJe`$%q>k$i)&8d^8@ zt68)&18fjgw!`D*dljlN^NeOl@%z zKYna2EbAj$I~k=FAaNIKv(qxEOV?}oIQv}N_D}pQ-OM=cPUS(fd|H??n5+#RRtjgd zYOZ-FkPsLv97mcu4r(Z$B#WR1`N|=dIr5R+Aa$P+Va|s=Z;V>7J)GEmiu&q5IOHxpq-PJOBlE`|%NKPhTldmev`*pWRWkv>q zYZl_)8PU`s^2O2EreJWQ5WR4uJB&M5Qa4H~Pn0R6Xchwm2+_?uAE|McbnmogD6Ol`erx7DD{#;v}@*T5B^kKBtq6w?&YekZ`V^x2@; zl5g-Sa?;KVsi7p+;xp&UDV-_H;c2lrJaz#Z53QJ>U`@$ToA`oJo?ITjnQz5SM)d;Y zh=FO}nI5ho2r)@RCl6Jtst1-s8C4Y!MY_V5)4ljKT;6>sY77QF=Jr<5z`+)U2{s}^ zwcH;1O}a7yqJ!^pCY+&A#a&Cd)HbTT^N4lOc!3zi_i=Tm&qvVnb_{Q{!TTDw~UrFcueI5vH^@26K3X!eZ3ka|f9`#;XSBEM@Y5 z&@FCf+f_VKJ@fs34=I)`5$h$JuD9O7Gju88bc4G3NYb-RQqIdxnrsLm%Z)nr$(?az z#1wI>TI3!Ng1PQk_zG#`uxF`&YYs5B~&Bb5zX(URwTMSUjsx|Q*OUI|~BVGI~+nqUS%B}T;7M_ln zBO`bs{_fiH%l%B2v^KAA0V;PQy0w=EGL^uvTIJZhDq zH#PdNUg`*j%}6L4fBsTe@9zAnGj_3+Xh?6tXh=keBzdYL``EmcLd=UPPGVD0-qG16 zi{D+^K1|I}1t$zUoiDen#h60l*IJ4)(eMRo#6t^FNF0nTC5yFFYaa?c)vl67y7B~=C+Av&i-MBZBC*#zwK!hm=t_{;M)`l>7<>A z5ZxG~t+KLzk|pDX2-^@*yPSy+jb$aIKYq*La?z$B^M^ zkEHQcIdhxnyb>krXT(lk75_ES3@aE3g-+SGN}~*e)E`HIn%j10a=F+5pJp zHYsppJkye~_yYh>!|<%~>cim2r!FaGt6l;wu?+`60W5~NcFn7637hx40- zbrsg^>08P|e(+IL)5cc04+}y~F-!>mTmsplqy2}_I5&Koy_exE$I>I$gT=lSO))HmI z@7->W*w1@|H0Mn3_TeuoR?>bK&qZJrcpk=+N-p&`TYtrOz7RFHCTzLcV(wIO(^4|yVtKBGq9$=( z(1K(c?ObL%S-Gtv$A0!M)F|;8b@iI%`!J92WY^@)#feMF8ow!bo!ExKRr0TL+CEFD zV}6~Yy*71dds2h9R-Kb$(yF=7L6?@G%mDy9uE!fe2D~_<%t0@pz|$RH*nR_HeQ_+N zCBh`f?i7hhbSWq*3eQW0->a|oQA9l6tl*FCEIuT}sdZ2V*CL$;W6YtFQg^dF)G0!t zJ=n;y>sW6u>C+E;DeEprzU}uNKg?nX*9rQ1&itOyYkC^k5UJSoTulYzx9@0eHL06t zzx#MXbVc7Z6G?-r8BB0!6nHY>+X?57G}rfssyHF11YO22=>^_lALn31)qPPN)e=;? zNjp5zKcdH;AbkDRd!Tity2+NT=V=*yC5?%|vT=}cq%iiZzMs=WZ&dUzI25o8nzz!v zGtGIrooPj;i4j%SofWItMifi#P@(jJ-8{o}F61n>Goy}Tb=^e`*ffJle{MvxO4A-V zqz+E@7K%eESjJu*s7T0K5zhr8WeJ=52meYIk>HneHu=uT#6PhA%~-l%SmHp&sFcpQ5l}z>b9APEVkD%#qtjdu>13kY-U23CzR#P?GCo_}EX) z<{+~rCoAsOEd{()%J`rJ%mhKgE(-7Ta*jlchK*AGeHs7i(pSAal(@rUlUz0arRqeU z)LCn@1Q6}~VmIlDmPQ+rD)ZTI%$hafh+JvcdNX}3u~Qma%i)Nwnq6UE@CV_HdfCpq z&3=RPZ0D{3qcv-}lzU<(6Eq*x@Wn(YxpHre2gOCfHKiASmR_q=?3I75chSN2N>)Yv zE#%Xygt=FG_5*ZTNaxI0GSm4D4YF-Lq3A=6Es@7IJIrf$UAMXqSYztoSbNjsDdSk0 z69h5emNt@@zpKpsr(xfhfHmy6xSHA~zf#4lHO7#mY4co}nZ#rFokwyM`HGsSHknRJ zxUolUi@L+QKJh2<$-2rxq=`d=4}NkReb4ZAd5wXs8RMRz^S9)b#i_mP-Jd2Y#y3MV zu?I=ki$J22Hdts|Th*8Z-APb>;)h`WIuz$I$%T1DpBxPS*1UjP93SFDI3B-mkoTio zYBEQxL49T)4GoDbVV30^Ii%Mmx%IgmMfeoDH@r%Q6kYLr=t)=!qb5k=X0fa>eVIU* zEf*)J-9ThoTa)RS_4%c~EaSHqKi~;iHY(3kYgu=mX< zG?&~}K3p=*c8ni6lKFh7T9-%Z9^l`LsTF^reOH}8pq#mCS?PJhM!-K&YCiasx0H2P z%1XXr{O0KIbugwE6T@e6sjSw|HBHb!iptyRuqjni4dJz(_LC&*nNy{&S;g@4KkU0P4b=4B5Ddsfa+rK?AgDR0v z@&tsBnHmG%I7ZU_rPFCSysetXq|acjo_vFMa^EDifLUrU*fBgaIOLGQL87Z+Qk)p+ zoNmV6J9IH#bNj+Ud+0(l%-V$9L~vhqD%0KeS_U({iCepMhD45?+$xpz;@BJ`t0pKs z5DB78nMUV<#d76qC5jaP46pyC5u;^2_?f)MG}@6(yV{Es*8hMefJ z3Gv>TH)iilEK~9k@aE*~FAh%kt1c`ImIm5X``Qp>W$&(CT59_+ljKvXt5V!c4=fUD z^~AY!6z^|37kq>Z};TeP5 zu{9Z$qe08?+>4zlhs?j8c~3a#mR;~oH)ji+Rz=^jWo9OP?ANiHR=j&0KSw(;ITqee z)|YAL_awU)ctO3Ydhe2uQ694`vZ}ZrzmR|m;V4j8a1qN>q-<}EU(orL^hW-6<=wn{ zmhm<<<4;XDrU#)4k>~s_w>Fwew1NiLeX%wAVb(1zI$C8tGb@-=uQNsZEVfHiEc^B8 zZ`!|FeNrZCHrKWZfd3|8CNo<+pU28t{LflLDF1lE;fIG2Qasa!Obu)tLH_U(t{Ik>kD!KQaN&_b9Qz36;;h2o7QT9wUsx zWMzy1kFqsp1+|#Q_krzO#upu{>IKa|Y5Gfb3%>9UIz-HFD^Gj(N6#8H$Pc|l^5762 zkNBB$Qe04+!+S-S7!2tmn`MZHNBQU{&lq3N)P$D zOA#B#B%w_=tWa-U+WB|Y->^}7<2?yeBKDq{4P5Q-E@>I&zD1lkLR%giW^1c46l9i5 zb6a=2A9Ge3*!ynP9vL@VU+Z+ny@4Dt;}Do(ntEAqyI~uG$kd;h?egU^wV!=#<|0+< z%D^&*)v~hom6iE|*>WU_@rDS0zU-gPnYX$N9>&Y<*19v$wp3icclCcjU3vG;v`F|} zT)>ogtQRjz`1QD+J5@F!k6ftptY`6M!6(`GNalpeX)J#c8sqb_WUPFks?n*>i`}~x z3G2U0K7SkIpf9L6O@EQ3(p^BB$z-5nNidMjwGqOnV4=CdWnLU4>y>poDz|)nf3p)C zcmYLKubqzxRDJWUc1mDY*4-^xqaFAK;WZ)>++U`eh~I*zOj#ncscByKTPXl$xruT@+JQ+!|PdVWPnfJ*2nAB;@;(OOf`W*eq{0 zDtq#tourkvlHGhiZ;PMc;g;1v0;CSp0SYP7lLmTi{4 ziRw5g(w?zL-%aj}(TCi02w8*)#}z(&D#`yQ!!?syv+yxgmMq0WymmHY*EENrkY$y4 z12fI){)d-LAK7aDHjAKm$~yZawEK?&6Zgs&{W|B2sWVp{-yh4GQ{MY#c{h!l-Bm_N zPUI!C#R`kmT&5;tBTcJ2js58lwZhE*E*uIb9$D|%GDXJD6LRbS3gm2yB0zPZCq>p8 zLG2~yycHUYTX@QpT$`CHI79AKhAlFPtp_JhnHiS$_h`KLwu^zf8wv=AZ|1sH2Ph;_6omB=W&Ai?EoWEZcdKOzdoscl= zqLHF61J0j|VeKlNMm_7{-Qu2lD&B?#ID(_et>0&FCTxA018d&-X2K6!ecE9O`e9&W zQo`MRMD@T`vCS?#o*Q$S+L~0{UAE$Ofgu7u&QUIgI)}6g0-p33KC?zZUx|A|p{lIxtHn2DTlHBnP9A}(%{}?wXZX1J2yY|mR$Ug3+H>BK)y~b_Dvk;FT0BKL z*Y8k589yJg?!VA+tugckujJHYplg94-&}1z2^Yz}{+>cm7WC@N=~rTY z24znDl`d$HLZx?VG4meimC>9R)yr!4ACFucomnkIe_RWB)p@*4_k|ZU(JA`yPEpX~ z`Uri~W6A?gaI!eDy_H{s>?AtbqEdm+W|Hl(^s2QSSRC((wGs!#ed_=0armu-E_k)_cmx#hWuwnHL5p zxk4j1b6Xy{B&oHbk#8PEs!=r;y%>JX?~2l-ZxCG^p7WBcSY1xDJs2WPms1?w#?+uH zE}nD5;AwBR^C-8~#BtIlEs#;{Np8|!Jf23X2!FmOL^tlzC+OFQqq`LAs1GY&d|GRD zA9sOJZhz?4X*HGLI*)#%4fi5pjmCcGZN@uI*4e0dm$MOW-P+%%sDFF%y~h(K8&WK# z4PIT+P!|apNrLE6wui*U!9NE4w+F9F#~#B7y$XBIn3YsR$I!LHN_R{0$jR4au3iZ% zscDyQ-WK=N6_Wah*NF??pJ#6R+~{Hs@?c)h>p#waBuS8Azgxeex3k9lMDWSbStq|W zVCLoRVenPeG3U68&i(DgRs1rARowqa*;_zW)pl*8f)b*D0iv`CNEw7Qh=71}gOq?Y zNK1!;3IftfZW<&dHVrB$CEd9}IySxOICJaszUTkOf4)c07<(vV=w_{Tult^H&1+us zSdES+t*yYV@17g;@svl^eNJJXEm~BI1c^=DtjZ;xEewH6Pc}7G*98nWoh=<=SJx-Z zLyMMz<@HDdBzN{LdE0uqw4&F$+oFo%yNAS$wuM{_(_M?I?Iu{hyFTpJ%qy(pk$ut>3+wS+QlB1Fi z1tfXvmX&%{Ws=XA2q`B}{oHyNU&H#%)pv@AttKk28nxEXp-Nk|-sz+sc|QC0prWL( zNDhjCsBQyg{Ki~+L2_AaID(WEbbe$*+kb!`uA#)ZtrRFyV$xYAtjF?g)G;~aH@ zY;rwhy60|uULr0L%dLBjTQj5|tgm+Ov~3^G8hY$49;O*pDiyCazA}=G-9{p*PZ{sby(fwk!->d@!Z3`*IG~7hE9zYDe3URQ3D5$__i&AMvfH+ zZ`tj9Wx8F2Jy0>l|&1x&tm8G(7BlNV<;y*804z zoNL*9RAx-Iw!OC!*gTIzb{HrAJ!V|N2>TB)>CE|2XEJVemNj&+!IMxk*2_kRP~GO>~gA{ z52*97*xre5a$)V$Wkt$NZ7+HPBn{nwrhCUaf5JbgUX(_e`M?Qor4N!;~mKg#vH&PMy@CT||)5R(s0w zfe6YXM^o`WX5^+A^c~R4T{~F0e=Ei0w))vvadIT3@? zz=_W_9^8z45t|L_i{FePD#ZaS0CD6j+CmA-sjq0INWJkr_!pQDp5igT+`kV zyt+)tEs4yJ@7Yq{gelv9lJQ}(<(lDCu3zR#&!Y6*+5qC~lPGkTI!;aq$64R~nR zOQL*v4=ZbGLyMX!a;){6$c|!X`Lx(q(e8+1CDgzwO0l?KbI;5pti{lh=`xu5Spg@q_X=l5dgTz)`dJ z$wHLDLYnrV-OII1cgH{}2KV~C<%IRO)FuQeGa^|-kuFH3CYPh!N}~OO@EL&sI(d4& zkv&dIsl@DF8hO2X_Olo-#N|W>ocScvM-nl#EI$=0dy(0x9%nL)%XD03zucLV@CdD% zS7H~zs8ey8DbKgiHzEfuJC$@VxMb!;t(3QuS;$*D_w<`8`CQQFPkL3CCQxJiKbNeYUSq`)p0cgw(lbzarWIW?t53-9Thhp z(RD{|WcNweDINh~24cL6eQBBQsxc0yWpcDl(V5uTgDXdX)wCj)4`bGTa4)M*xGHEs z=l)(*$%0ChZm!?^z6|2s(MSH(nDxPO9kK)>p1!aUSW>R4B^mq(;fp7Sp4u4E&}_fZlW z=}KINKP`-G0WiA7l(@0p9i=jx=Q3-=Gtv}q)ds2}=i(h|{9 z&BxsrHGNk?%>%5@OmjizF~+RQ-e<%{G@kM9#g!C&PE{V#J!@>0sY z!4uUNU8`laH1pHkF4<_gBS~%&jomV?i6F1(i+0z1MKO?h+S5?Fs-(He+JQ;>nU=jVn`vZac>MVllswcj1&teR89`jZw?Pi1WNX zFK~ElHYN(p`*O*To@Gk7GM;bMM;P5kP!vSYkDS7B)V#nKE7!_!`tvdDhl2*+BK#s% zhreByeQQf1FNLjzx}w~=Xird@&T`^uMw9u$_Uc|cx>boA>v1Z#+FdS=J?0LylMxni zZxe;3;Ek+{JKUs>C{os0Sc&FHO^fZ}3e8Tl4QAj$9W1m`kIeIDw$@YfbR!!-ReBuk zCY?QD$eeCBe2F$sB7yw$yB-`(wDhS*?IuO@{p6%C)y@=#+RN`q&VhooOl)t}g&{ME zx3_b$F7f1F7LWO~d!XQx8f+QNPJVAXLF+a>7fXNgJ0aA!`@$lEaclFEf*UV!E_&fy zG_gFLVVvTUI@>mVNx3^s{7GgJx0!iY(8QDn&hcBvetp`>F0Du~$uF0t^@|U7m-Yn_ z=VZ;eVM-qy86F&X;Rezs3t@hW~igXT6eJof!E+0r;>byRE>+pWt?9||gq9dx7b?s{qxpgr~njjNt ze!VSWb7Oj@o4vtTRJu*g`(97X2>!nhLwzZKrvnrEkq4Q;#Xanhu3wiErM>@+gO_4~ z-(g<)Xhyztv|s6qjjVs$Nf(Z4+JFnJM6T&~cts}6NtaCoo!2HqmlItGwoC{;uFKdB zL|?QB!oka#+b@bVz#RWV{!n?!W~RdVocuev^qX?`iy25OVy{{}(;1_{pKtTJg3I|x zq1e-I`p0;Dug|h+w9w;_R!T0W!*n{9=&gW-qQgEW%H-SsY`M?EqIVJTT$DGRK$?yp zhJEp)6g{LfUk!{_xsE{7G43fN_4bX>UE+O^Ws~qU`2JR;8L)- za$Xrrg;d!&-#t9+gD~jc?d>>?uZQ5gjfj#Uy3wA`)3e_a$5%4Q4wJU$aR0MW{@E@T zm&QuSmPs_bDvk${kLn+TFFM>278dC`$*5lW+@_I`94V44V=8qzw=2>q&TLRWW;)3l zRoxRi;g)m;dpWi{_CCLMCv4Dv`*1TBqeD=cm;)8eUt3kpo{rg!wRwPAJOz@n|eCgC@i4e#B{NXr>N62`Q z?u>lp%I7~Rn--HV*H)|ANe;fe2o<_h)LS(+6pS*m52g+7KuR^94h?BMjw`r$G=W2d8ot%^V@?(*XV zBrhr5L0WWawVuuir1jK4YKuNTez1$N3l`kX*c*F6I;^JaK9yU&J3oxkhO(wrb0lkG zoCUY#;3Pf?_4}df&ds*>w`+5>O4t+(ENj-9nC~voa#_6Bs(k)wsMuUBWA)1mf|1@F ztr5_c4l|AFY<1(-hjQIq_!V1D2K*RmZ?;+Ds6RhzyZt5DA4Yg&KVo_A+RGasQ1RFr zCM6WQZY^0I9Uf$+4IwSvaMY}#}Svi)b7QyF~s`RRWL z8~^?%hbulIqsa#xyy!KAVvPwb=}3E`sCIo2O@Kv({oFa;&zQVu+x4Par(JV@yi|T1 zJUDA4>+>k4^w@L7dmtPWhz!1T_r_p+I;->A`}HFb=F2Tzj2Cb%2NABqI;-)oz6vqS zEZhmnu@KJjPT_d*o1FZgR{sBUx!Wl((j(vm^2eGJdZxlmjjXz}@rLXuhrV2GyQ#n- zwR7?-Fb&HW?E(@F(({9`@k-^AY3mj;Fm`~7m^zpn;z?5$)3YYjXn#5B+qPrX`^&TE z#ZQXL{i`eZ?I^q>Tfv&Kaw8B<%cHVg7vIte2`-+^J4^U+dDk8rsI_8THTx^W;B5% zRqiY9)6r6_N0*>zm(=zq9J+T0INnf><-icDQ@NtANXq8B?axIc$3d7NNa{V0-BXPr znHVmyom2Ip%i<83{*O@b-#jhE5_6})O%>o0J^k_iEKhWCfk8dV76cX-ER_(#Jh`t( zXfzG&R>nl4(zg!aq^cUGlVS%o4(#q@@3#HfQ6$zCE57nM&0;!vq9#bQ&(iQjM4oVf z&Bgw4}psGEYV}Rw$}$aBhgasl_Sz27*38)){k+&gJW`ApGA}^VsPkd+fOY zoXt4F9XV8B6o8dN@ONn>r4!_*G!-V;d+;BCRWr(n56d+z(^)@HAtRBgCgFML8X>K>q*_~D<_|}M5`ciRILH$6YpFD4Flq#l!uXE zNs}yG@rfxXIXLRPj}zSIi+kM?!_CJN9M)tVIOK>PRI!J-vVMCetS+)|~Yy z&DOj1AC_Hl;@VH*>p>X#zkLwY$4`(IL7@lJP-5RD!>uwY_xFlJ6V@YO#yhaHD3Kg_IQ<>ZRw z%q2vvg-r0~;MIc35|u#+G8(JF)|5stt3@8T zg3@tpTFC3DIE*uTuvoteymn55tdZI7@$0OG^X=73BNcpsyb7>eUo-;Vd1n*`Ddyt< zV}#>nPK3Vn`P&wc#&sdr^)t&Kdm$%u(5>x?E|xtr3L|h5*B=|1ybjFOu81V>na}I9 z1qbQ)uq-NAU{if$&@#}(32vb8p0A9p^mo5_ ztaOnPBAtGjM>~FC{;my!oLF*;K4`^e`EO4309%jrXS)q~Q9K~L^rnzGQC(qw_@a2j>rBtWnRWe3a?ed~4aS-A-p-dhg zGM#F{CQ|?MLG0Ytt1bmKt-LF`kL-l{j^m#ubeEs_UL5O%%d-^4sx`e-u`KAczgkZb z*9HhL=UVf1On)EYy6wxX`lF4xuDE60@by7nuc!rwBM4G_%Xg2kgYS}%;RaYXSC}j> z(?>IGWFU~GmKTIH58ttMP%Y4<8B1M<>A*ip_!jdsEM%DU53N-M&AKy85+d?4ucl1F zY${i7+sOu#6o*T13IncrT7}?0vTooHHOd%0n<;Sc*?|a1(Occ57r%xUSF6j@`v(MsMnBmHp zhbV7ad+rUb-0H+7DtB0zCVP}rCT)+S172E|;xX8xVhxIq;&0mduRT$m$yLkKk?nYd zg%k1uw~5uz-DIZ+k3bEOiJEDmmQ={TIf~th;_)+)pElQMsD{=?hT2cY{o4zNy@2q* zI%NnT*{U`a?MVHkF^)$N=fv$y6e+YWUPC2{zbHZAFh9V-?==`jHrB*C2s9;Jk~_~J z`=dx9-GEAl-pV{-s^U?W+TkNs2IjPlmcc-+H6WBV!nFYDytkpVZ%Xaodj z^&>uN4MC{9y>9cCR-imX+o!G5G(AqWsBOL|^@`%+wfUFvZflJnc3N_yjWmV7V5iCP z_N%1%+zaRM@z#BXd$OPt(vpC+J>;qbGs9fknKpCu?U0+l9$|ghnQ2dGImOG zb1l#8+OBP1^uF!K`q2F^^V#u6>6uH-*8?@*src>Nt%gtP{-q_@3>vPsI!K>m{pw~%DoVn_`cUzyU7$T`+7c8w zo!?rJ<*2JE?0x0=q_A2UWtraU&u{wH&uijgYMFpV^4du^JQ>D@&*F~lt+t|%)tw#l zHMsGoXzm!kHgbp#7M+n0*w3q6Yf1_bIjuf`Tm)Zjn04ww@+HPy$z&RnhvzHCO+Iu7 zrFh|rNimtmp9#Ex2)Idm>xnmhQ+fgC{m)=~rs^K@e`DueH9#xs5HBRr`#ksZ&LzdW zVe~=4Z!wPNsHr1^NRQzBxH=A~O zca@dHgWe*7=(EC@n`21^^+9C|5#p4Wb$GMFs>I)9D5qPunpaav0G-Dc(e#}%b%$oM zv^eGRq-8>+hpy76h zQ_?*vD{T`1L&XzlFtrM@b8jt(TGx`@eICDw9+HqDJg;3k8 zwb^MsySI$}pG&&R{Z{f*KEK>PJUrMNT6(tYx9!m-*6OOuaLIJu2U~q!RTuVx`KDBe z!G&O1gzZmo{iomH^8ZvK8wSPCJ13RgX31pI^(6aX)D~H{o}>u5q;r4da=f4H?1?{Q zdzgPRm(Rt(FiSsa8oR8=e3J3qRZiBMq5@SBlfxLXd@mm}i-WVc*dbyW!<7(~$J&U` z=abqpW^q@cdQ&hEQpF^2Kh}W}oJN+RO^t;uq>S&9hYyu)%DiwRP*tu@-0r*fCH8ZQ zCHl4a={l>@kt}aqP|_v*==|es6!M7Im!v_nJ67q8mk)=V#J-A}wn|bVt^kWEhi?(r zj_BLER~(SPMNBNDw3*^Sl*7`#bc?C{X69(Id7oxv(u91=E znq>BRz{~8{9P^6(=~0C|0F094Rb$_otwWC-=9Mol$>#U=KzWaan(cn8X3Uzf2+3+Z zX4RI1qdr3+`RiqdPU;?;7&9R#;YJUBZu+FNy~$%b$Jd;E{;XC92e~A2)$*w-P}ph% zw}adZyA%hRO(r06Crr;-Sy(xK)-5L60WWIXNWBU>kF01!{LE~3rczN$NyqFtsiqn0 ztv>dO#e$4W9(pguiSs9|w=6jq0~GlY!ghtqp&Svfb=eknmW=-5>^+CGCoGK9r!}E% z?a;}K!cjg4!RV}MAPuBYlXo$3H5cUN19Qk3XNqEvHjRfYd2D{xg*pPd#Wu{Ug*n_D z8cCOyj9;* z6gQSi)?je=1Y6DiTDu5#JdEKqXN*}CY}%=&yEEl3Nb?82&pl|86?=JBEWiHn^_&uC zZ09)UA?z2sYFjCt2a)5;K`o7$1W%9dTo8D#67&IQ}>!#H((>&TQ(v?X)zU zp+hxrWocy#{XLkDt{BeSEZ~eqFrLRcxM{<(FHe_l`c0JeRfbBCpL^rzaVdMI!urqI z$LB=IK5%h~O7Th2oc+gk|2YHLsUXtQu}KhMGL(h-m2FW0$zV_|(-Lqp(O1Q>y@v@t zC&E>8AJ4IYBzMwowiRYxt<#nT~UH`QC7&4u_p$OTo7 zP=lVG5s){3pPDGa*dBgf$~2i_W1)|IIL{M+uAsrRIYt&E8Q;qSt{b!C97zuz4?)t+ znk}-3d6jM1(NCEbGWY)i`jS21~QH zO%nuZ!zCC`Za@D?$Z=8KxK-O(hLfPmQ}37G@ZdQt$8bc64xyIvbRmiid9ek6Z}3`X z`p(a90m<$fIJk$mww~tOOnlE^sj2o;FR@E3mlZnL7{;i7_KJi6AW`Y_%h*n*VH=5# zvP_O&IM@fv=a39Px=>;hv1xB7olfU&hA7iyE9DS9Tw;gVn_I@&uNVj_;iH!F9`Put8l1bC- z0TG@g|5|TrH-%WB9Ox5nnaZ2gl-?&vRk#MRNLa1{&jY zZB2Hy#N1>(bA4?t)q8)lhoXKj24&VVXD{LIG@nt3G~lWo_u=&F;n{oG`eqrVzvQSOMI*KtL2nnR;&t8R^&TWA%s@v-6+Fi!5MBs!Xg6eh4Y)I0txgU z#c;6>v$`&5FVFPtX604SbA0nI?$JeBqehtsujd>>4p(LlW^iuXFnx4i5{F=w_n-~y zcqB(C&wdtn$gec3{iu@lwd1%&OynsFHkMCnd=R%U(ZastHt%KOcG)mV4`E*d)z^0A zF2n75(*>deh0kJ&oeg+UGqn+L-F#G3d`Eq{BJa;uN!a}#v;1jS#{kp2rG-+KS2s+D zLd*)p+XQ&VPoKejaUFZ!^*?+VEw1}$aj?Y~iN{fY*=mH443Y{csUDbp7f{6Z0 zzjCgUu~||goRcE@rH6=H{=)Kvi-a)1oDL7GjsN2QiirHh5A=*D^e4?k^)t>K)Q!FPb)9Kd>r9MW+F>O4HF{21kv#MK%R^TZkxmd zB;L8wr@K`DT)oS9=-o>xztXIGct@W83$*+yhUgfId#9ygYnte{?eQ0qKZBYq<^E5K z8bZ)&EnI0%f`jgz)WK2i(}|q~H>Oszs}jJYLvrHJ<;R~yMVnqerL=D1-qYACw4mR1 zj6O~FO0#P(qLG{vI$9Tck#MkRELqY27j;-x@n84ecC_F21w82sI5v3LF><$O!j7A| zLzT6Cx0Od?_#x3_tl%uvA?e&;bn>ZKyI*exf**Xa@@m-EDQ^XHQB=R_q$F+Q0| z_dL9gUvDX0@SeS~SF{3x3re#YGD6u3e^Y}!hNnpOt5QS8(LekMenfnTWsH9F7gc93 z+!mQ%R>{QbN9X7hxF}=q3%NgUtX~yo;uKhMKnu@Ek=eb5tB##HDOdbg-)-+C|8>8S zt8```Z6@-oWD;9?UBc`6ZgIx{>q{M3E z>x9OqCt@p5beR@JYFgN--TxjRow4~ptz z;eZoqhdP1h85i6G)14j4Z|czf#N5bnvA=^=3;82Qw?=T)x+R(uTkveL=z^i?)A62% z&Lzfe@hi88aL!t_#`5HX!}#FX>nB>p5A$KQ$MF^WkV}Kb&9XKf1@Qlj7IMCA%9~3c zOf8fCO{HD(G#M_@{hChanK-rHgm6RD;}YVFx9ItoAYO`~c49s30Ok<+&aZGYbZy%6PJWi>8t>08ZOPAmpN9LYn z^>;&n786+iK-oz80OQUBT7ErXy?M zNh{=0IaKbD#rJGXxO>xmZ?kNwIjRCM_Hrkbdx^+UE>$-K@JrY-;GsrpdaSL~fQ#8D zOAGBxc9g&$Yam!O5L*Tb$0zIlNe4>a=Axc)@Tk?>KMOp{w|OXeY*UoZ2x|_O+88|j zFqjZ|l+5K`9@< z64Hdre80ecGz39cpQ=IR{?n7v8SAk!Z}A^)PlOztm*XEl5run(MFz%&_4E#+-Zz7K zYnj7Bug3bFD2zpvN-P6{el!T%Ew##n;(YsOsNq(7KjfD3l=6BrhzqEB;5m?&4}Cnz z*#7WDB(3x0+4N%s2bTT$U$`o;lVduBT%ZCZ<~*6#&A2+he*ooXu_2X6nu)~6qp;2j zF$Jn*kDtN#2(C9=bW&A!=3AX6EJ$$h<}(v)5Se@36FR1t`5rN6F6&WhD{NuhAE~A! zAv$O=gk-gdI?Pf3^c6GL#bANDWE?vl$)-(-?vfJirDAWsc?Cg_;w0+}Zkxsb19)<) zy%Wnrn8PEpKvfIauWLirAy)ms!3?kKt?Hg#9{siZP>GXdY6BQB0J!kgu=v?W^|o0r*JPUdx--bZVe2;&vARmHl}Dq zHhFLl9Zu&ARSPQ!a>oYgS*?;R%_(eU;LUPg!<#q` z!VZH+dm(Y6v&Hmh-J5X}JV(2B z*#O5kL*Iq8w6MiA;%}IVyXAiPm z^NM7Ji$x+`LY0_at&q{$SERu~&QKH%32be7K`J;a9z=a<_bIEF$fcq-(kJivoo&^v z4EJ07d1IIxM0Z%{__r1Z?tbhFDj{hGA^~((p2)Ju{^H-;{_ITTwQ6)%Cn=nz-sO5)Ui3fq$?{Oq8(&I;VrXY3fo^*BNTst2mB((bT^pv}S%jzI z+_h<1=U08Qi`#?)zl+)W*2`jF?2eNkhSNO^A z@6!0TS87RHB4*aM$vJn+Bg%m2na@xiF~dFsguDo5hBCA(Oh`*cYnF}qoJw+!td9(w z(kkA~*7wNwLU$?BjI)kFb^SV;mc!&7nj~sI!+qGMUTlZgadFlKGf(bL3phr&ZZh?? zz|p+VIMS;fv>XL5uj8Fz%>QDYm!_7Vg24CGjq6<>LBPh7-;j)A(>_OKy)r*`aJ=9b zD0fZm+AHz1vruDFUXo;po7`L)F?Zp0-(2V}pWc%16r)6?w{bbt!cGq@MOm<{e7;%n z)1UdydW`n71_F5$ z#W|U9{1=b*U#hrRH_mwrI2=20bNk8D`*Q0xO~z(d@f#@Ke;Wj6h6aaz%I=^HJEe)U zhL>s2d1@Ww+M;#2x{WJy>HA8KW>s%mkr(b%p#c{5kqR0CQ2qGP>#ISGjRp>;I}q+@ zM2LCgd(h@s50~ElkuHlm6cj?xvtFEpeGxpL@y&X%FXmJH@>6X|;V<(&Spg)2d2T>l z>-e%GLhuX2)%9>2p}R8y>=Gu^D3=Llrf2k4S#6FY{6I8$v)3XX!kjD~XbX_Ta(zV9;UU-jn1ZG`lI_I3;xli6O#!zew^vCfVIa;GdM&KB7tjvvp zl@K@?KPiWVrRm7nSG5{cOg_hGdhJCK|KQS|$3f64oYvMc(@kht>4c%z3DN8=)nCy& zR!tD`FwS4eIh!mIj5M&b-P95Um-W53>7kZp+g_Be2hYd0H9>Gy`mUX_ueIMQr9EN- zr2G>F+#;@wxjb_NG;C-=>F-sSGvoquOu!M~d1 zVk00yFp)g=)8A{M_@cEEQge2I9=gMIlss_*@zZC{;W~OKZl{H{+ zqRrv*5X?Ab9aOU-dckEmSlY~9!*Acd@UyU-%61@8^i_s{?V*|`lDOv+#Np4_-j!C3 zC>OMPTN?!Gzx@C2+aj&mT1tR5GMMl^q)BBL>fX|8CjRzRncB|4W)FgdWa@@xAIHf^ zS|HIC7;*Yp_Y9h%*Wxyja?RlXhYL!<SgU`|Zf&yhy5%`C zu9v=P%qz{&oaU+~F%AVRHJGK6rqCeNT5kcif|29@%*D5;045&trXTYMI*fR|q2Jx7 zKVBn0RJG>e>4XPF-lk#>{^jfEzMrf5a};$78}-8>Z)0sNc|WDanUEE^w*Jkzd@@w} zN5l+-sG3E(amfdIK2UfqHmTv&R{MFRWbKSeQwu#`1tFi<)VHCuHn6%X+L58SL|8bv zL9Nnus;SOVjZ*#@jQQ4x&^O*lnNU0S1)_*rH(m-4+Ea|}t=MD=tt1$Tub)iMC|AW> z;cD6BRGZ6z5SHD=TE;jiypD^!rQzc`@sJ?Z9!QkrG?jGVA##$qr(5H+IDCCbCSfYaA@dmF3uy;7 z-D-ZbLa{X%;Z2}mhowDd&|J8Mn1TpxHv9-Y4(Zh(iw)dMs+98W5RYU8Rn{95XMg9i zrkQMZvP}LXpX%7@?f@`1YY@-PW6jOZ@Z?Oz>US#9glxA$Qo(J#$r)uq)c7zY%+I87 z*LzwLgiypZyd1kqZBE5vj?V9~Btqa-N0HCiS2quErdg|4eloyIc7Gu-UZ`gAKcl2Um^?i$dsB56u^j?+gPa-eo4!*8yNzkq?b&vaSSydslptG!e^Ts(A0~3z`>q zc5v`61S&s?%@^@LU5za6-<^WDqxn}0bo0LpWZx9dBsN+GQ|4N*8GJ}Wr(;ux`&uId z#m-{gOX{gr+3!y$*t@8wfX9g`^j(-=%+cA3xYc*DS_LyLC%twVqN|ZiQ6x%aC`hE* z0A(GmDjO|(Q{wRPPD@zm{xn3Ka@{|`j8*GYx$p!ct>fk#mH@FC$0F_zw9Gw4*=jH{ z`o3b0Hvt4*t~v6Me|_&HTls9#;*Zf$U=a)6gAwdLU*%7K0kU|dz?2$uF&YpP`O;%A zeDXy^e&~JkC;tMW(m66*ye2i(28D}eS1#Vt6JC)!+K|Kc%J}%K3q-{k-TXm%?qNDG zX8Y61*-zOSzN~-z9(9#pC`&cxrk1C^Y|t2k(2k^hDWT8T$Mj!Zm#fsa92If?qHjZZ zK?wm}K3L*6<0BPXmdB;}J%scL$@_u4n@}a46kL)zNLJ0?kM$*KOAIa=^CF3Yw#%rG z6UIV&8Y?g)lW%)u*@J@2rJn$A#!W?q18I$cp|q!n1a@Cw0U?jhkCfWJ3W;4#^0Rfc z``h(GBt$rbiB`V!Z@WW@aPYoBBJBe`8I13A`$C&SNGm@njT|SU-1EvH{Y%Kvlo6so zBY?gqvOD}mGlhW@m1uSz@JlJ@d9lChRl0!f1_DCtvpTAc6|DB?7?klyC3^a1k81sh zPc;hx0EL|k&N1IW?Nc zA*CH9QWE@&U2u%3ND)v?_(DVy>Iq4Vm(K;en>=U!T#JBaFcZz+%~4%fLVJ}z!b(Qm z6!-Y6Zwh-q{{2-p`G#&ocrrv|JSF8{R1sjUTC{$z?C6Ou7hEE}zr*n55p2INsQo#q zU0exJX7R9S|Gz@T5e`i4n#YMecA9nZ&);}NcnCWgnR~vq19=Y%k=vw)AHV-sn=LI- z*qoHngwohs6(Niv;((B7d9><<)kwK7>wn>DD-~8`8S`a>mfwXUn3AfZ+zKT93zfhS z5E}{=1WL6s?a<%cd2}^y4ktoyvLWOPcEacwWFaR3SKdkUOftDlWXL#1wAXZaFh(Hs zObT!$wnjdnr9VqJh=FiSGQNn{3_^20$Q>hr58Ioko3LH-w1v`XJ~RC(G81B7tHu6L zR=~)%0*7P;oPZBIIZJ5;zrbnmDGP(sP!k?tV$%e+XrV<_aX%M%psB>p-U-UYvwz?N zeD-R?b`Wkb0~y@e=s>bs+fJ7bEaUG!FqQg|;WjF?T&3rAD;6BS|1i!g@@fuwD{o-arr6&(S>SglajM!1qJla?GS@|C9Xe4A6S@LzcI*LQyvQ*3T* z4=*mA-=T~pm)B!BfCdy2_aFa-hFeO|!0OOgQ@bc$2Vg35&s>#hS6X}ZEtwavidv-C@03Qp~b0bE$elNGsIupPThDgGDtVqyW11Dvu?ACjx_Yucum z^Lc>#nC?;R1;eCo6k!Jl-`90gB4Nx&5OCUqXUdgJ5Y!)PyEkzfODbFMdDU!&X)rJ* zKP&%knX)OF$+`X9zf!ER$@z6?uz+e3>zf%>7Zz-G_Ey7^+KN3bpT8&{M^v$5_kVVOY`#X{ruYv;J0dR-=40}fJ83etmkHl zc^}(4Hz0v^f@=*|rK!h%<@9v&2*)5`sslZ}k@(V`y2eJ`#*;v}(F5od+muHVjDc1O z8>}F+7-rfs+2=+$oPjV+5PwRbneM0o+kIh5iC#o?u-w61;V|1#1KtJPYC(}99p%5b ztUyms(SzS_^1AIvQxFrXr7RR=3OURNy#TTA%dFprEZa1umUh)fq6CjjJx$7j74g~P zAT@R$lI=$HwY(dMu^)HaHnL9lMX~F~SF~1s#^xRh0#iYAz=eBO__XDwX)P8Rj7(fl z91Fy@awU^95`OK3Mi1%5&_R=(lUQi*x@iMf(TjiYIfi7s5#lxQ(bCfu5!71MG4??0 zfo`(+u)sIZ`}JRyi3MEvKsqR}Ga1$)h$R=@EXKG_X5nH+vDED3v&W0j0OPQJY#Suk zRfX1NsI+AHCn-zH9X+S&6x0RL7X_MVBt5HcuVY|;dxM}*_m;W8wqhY7= zvM-8?{_*`sHvE474|25zZckP4!25p&4O)GGP@PLJet7^{lBiITOT*rMkXhkG+J;&W z7BvdMp2&shQlX3?&OUUg!YOa3Do$|E;YN-cG?&;yOEpbTa>TEG9&JgCv8C&5;;STH z4owl&(QJ1Jker~U(+PN14pdwg&!AV%4mg`OdzvO^8HIwTj~gYH(m(wTOuP3CtDArv|9q)zM)3TnMfYOG0;|;O+TeZ>`Uz{5H^dGc{ zsaRW8ych=$cL_!alhSO|Q`;W#gaWsxLD{oDka(CIDX zxZ|iBKOS$_69Q^>S(opxVN_FLk+yh&+PUr;SjhGfF5o~8d(>bNvc^^GIbip-TAEjy zy4bHLX!0D|f_KWiO1E9DgZi#Z2aU_$EDMl5<^!qH6k8B4mts4btj)Huy-`cp=u{%f zdUjVWTYcO<9=7<*Z z;+=5Dlz|}Y!icrQbsFe&j<9n5g%CZ;$ooIwA&cMekj4RTjpKwK7ASjZTK^ZokRJU9 zI6Y7$cuT$>tO^~jNLw#v6|gu!LVJmX>b^a6xH-KbAazuGY~zdVA^(crO;>2mVe3jng0t&5xCZ(^%)+oV_UiS3ceeBR#nlVvKgTS-vH)cgavm?Is7Nmk-Z*mm78_?Pv z?~8D=sb>b}p)kXE;wxHPY>$&t@BuVKUWm(RW~<14$Wft}Vv>r)RilU&^7R?a)5DEf z5~k>ZRuMI23N68P8L;p&IS2r zecDc(pu{-R`*v+@*dt3l&@bd1) zoYJJ-dRy=ghU5O15DD73?hkwLm(3c14tS`geuH3{VodX!yciTmPKk#oK3T?uT`;Y{ zM>FHf5z_=AC``9kF;!)UArsVi2Z~l-K8cpw7$jwz{K&da zmxKw~%aoLdlr0J8tkaVMe?d7{&^KhF$%0nK5+tC3i2JIiuH@xWzwK|T0haq0As}`6 zD

qi{uC*goDf+-pfkCE;YM&>x@v;1^E?Nu!wC#m7sl>wZ8A@0zo>@{Z)nY9ABLk zb>Mo3@-hjCF`%on>l%j2bRvNhE?zCM!v&3Rlfy{Ksq2dLz!MN}%#48#cUUp&C-l%<)UV2)#bw3SzPS)3H9}WGx0$ zJ+7JhBB58b<~8zyfQ9HW?t4>xy&DCB63+z51MLxWjPnD6O|4GueLxo+XOUn z)w~*I32T|ucZM_8N-HA#rqND9a-!Kn>p$))a88Mzd-%~BQpAudT#o6s1Ukog)py>! zF?*Tdg%tLj0PtFFdfeA=Znb=-C5B>P_A&qV*b7<95BF@IJP)!=-)t13Ey=3|%zp-g ziTU=i?`M2@i8|P0`8fV1Hu W%z>K1?ZUZjPRj)*DkaHP@XD~qZ>Z%>{O6U&Li3>a6KP-3I-IHux-!@qxl3%g>xd5b~YTXB=x#Rm2 zJ7x#j$4*@jB$7APh@KYKWHfbdVoDDWw`t{>c_4C8*KJkIo`lzFiQ17+2*RN_B=g+k z`NE^9ZUwiMu`l`_2VEOP(XCfTHygtkB%Fa9tyCZsUxOn!Q*rW_U=jYk%YinXnJ>If z{wcbIAlbVdazUt5;__sJ=tSsqHkMn$RUPg^DcC3fg0fm5BD(cz8;08M_G{LN{${qjwx?UnHmy93~+JApjNo6Vg~WbXLkf&Djf zHN$D{3aQ9wM`1}3(ujVhJR#mMIVGdfX8#XmUmaG}w)L%qv`9-xDAH0YC=C_}2r3fN z2q==$yY zQxcc{?-+r9{Og62|KL?L%UvBl4TF~B1yhS>yEnutk6ge`Ky<|w?aTR{YdZszmkMpu z=!Fm@!oS}YffBk?xtXrNVwn7(95Z#{9eU)o-+jOn+qa9|OQfMSu(?l!|9A%l zRWji^LeYKy%r#R}xZML}1@mN#u*pq@3OKnh@OTIJPxnyiBLPEd%RoO3 zHAJnB=;Jog2ltANzc2^?Vw{f?{o@;{W^G(x83%dKnfg^Q1=3HRudj6NNa^F(DH6=P zH=HN2y4WVMuA~<4cM!PTw&#uz?ggSl_IIxpXich@E`#FeMgMzl_H?F<7|+{&*6J1) zeCh(|o@qC|I+BpXhe&E}pHkO=wuqQr^;gnIQ;u-HnxJ2@?OmlE$9tL6cA-@N%*Wz5 z5$eD7mwf>IhgPH&0Q%SX)iFWDRl_Jg!fkc@$)d`*+$4_&I1o}@eilG(#}l>q?(zLx zsd$?jqBo1s-<`L-c(!ITLVpRE*SXi1ry^U*v>Z$qJ7);OAamtaS191&!LXu!#rBM($gbP(h3V-kpuyazBdCa3A~6 z8qlcsfqwZ=m*P-|NrbMt{WqXk_rsRIGFp=^8Vl4{G~K-;HS*m9bV^9n(WT4pQdHuX zZe5-X{ixGr=2&4jgo%$8bFhVa$IjLjIXd6OZXw0zn?;~-1Gb{d&pjh!q%CO07J|}K zi7_|B-USk-u68vLNdx@%&UKzUg4UlcwW7I3%r{Vp3zE!#NGvK>a z^ZVqR9K(BG439pY!OXC`6(1B?tXnqPu2G# z21!cjZSJ#_9L{I~>k&;~qxyTo9R-m&?_~n1kGG`d+5GP z0*<@AtB>8A6JlAuEe*=9(DrKQZ$4aHNs$nAQ+8tG4-PI;jS4Ru zZnpNgD{J^B7NKzVmn&JIf8{Kic^8m#K9}xq5;tAEs)SsGh_MdQ1N^s$xTSG^(q}A8 z4nJ;J!?B2#Yug-j^fg@dLEn|)+At*_b{>CaqxG!_Dm2+dQTLV3_`?fe>A>UF$Rx!Q zzdp46V5lpWg8$H2b!L`@4;XL@JFP1MR{*BQ-Ay3r#BtW1FTH=#fmLFvh6~IlkNrmB zm?Q?>86)$R;%JpiV^0y3j5PlMVYo1}Dkz?Zck=Wd;vKrR;KG%@6a+7}I6c}g-_b^4 z##sn_k35yx1T{7dleTe;&b9Z+y=m?6jjqP zuJYZf7=++K$Zk833n1H!LXj@^$5gr*b9Bw;c0czX=D&7!R>|1?!|oc*Tbd_cvV5I4 z>i9YoYfutSBN0bP)feZnr6uZ#aqfYG?1vcUI~h-YJ_Rv|)@OP@zb}RJhAM@~8TP2t z1PA_{agqIwJ_>g!;bZ<%TraKx@OFG4nfv%p6RxVN4{^>==)Ty}hgiQ`-c+#Uh_Teq z4YvAI){}BTouiAy1m4)^3k-)A`|8Om1mxcah`AWl#-)Iq_bJDUbpeD^QELh<(e2od zyCzIDa#*U>V zyvoaiW$%PUfb=au&IQ;0OZxLKqy`AW(yGw5_1_NNdwBoWS26ghpTYM9|6597A`Za8_!7H&My8>0^G1Ng1>XiGm_z2Oq2edS@ z)8Ar!&{xEpv;!=G?%T=2?qz-CLnV)9A15xK_CcQ?9MN$s2X9L?%i+qiQSFgE^_6<* zL!q64%7X#57?3xgcZTXKV5<@s`f4Cobn`M2rNGvLuEaD~k|I$lqxy%F`Zr&kQ))Z$ z_z)BerCeeoB#Tlr4`Jj~?&FDF?NpL+H7V`5y5a1q-2}^B|xkgooqOhi3*g zY_0wN0(kU<5wqVlYe`C2h--grM|*xt?bLPMG$ycf~kq7gG?cy`FRd zCzE1-Vk#FViGt=eX!^P0KX}hTdg+E%CleC(bm99NaH9TOS}`O?@xK$2K|}4^nMYHQ z1#ge1!xCbX-{Mwbvq}7j0fL)mvCvjio#paV$43Nz<@m7SI{9ev3^n!T#vLI0RlQ4I zs;(ej!)pD5E`5Apq`3woUWB+-o9i1s-%mJUd}1*V_KVNwlx~~=K#W7P*w$nvKp%6u z7y3v|M5j!RQ0LxTyr~+8h-@x1<>2nJ=PRWZC)Bo+VK@}@;zd9hbmrU`=o+XPeI6)< zov%DJN8+)r$1~a{4-(>kGKXWeS{n038V@{_@jg&+(%#dD5(Ys`tU7mhKzFfkljrqL zX_x?IkJdk2i;y)GBeGt`W+2E+H7wXlUq;MrVyKzCuUn|zWE?a4@$q&w7?Zz905M1O z_4O&n%=N#cdr8>kX}^DiYX@qQes>jyb2pBvc$eT&W42LPr*?>i$cn~lhn?RG*R~=O zebnnoBK9j=1e>+daSw*{+VBlclAn7J_)4)%7uoVE}+_!xB{ zWkfddA?i|{9EeRNOz%xLQmL*$=W`5UAP`4A*QFYsTrafT5v3I#^iWL+`ULFb?c49Ut{?SIeoph9D?H)(+BdP9GIflRrws_IqI~}Zl1Dq`x`JBX& zf`;f`s=3b{%A!N;AaN|?1!r>ZTY{tF-0}mO<9Jz%L!}x#8ku}RK!pK?LJ)u{Bf?Qq zvia%HSz;cp(R1kOB4M(2nyWn<_gx~RF`VAE;BdUIG(tuFNS^Ss!*n=Eg!o_~Q&F)- z&YUhaX6A&{A5o2TwsR9eFgfieBqSKsy?AFxW#l;K;-dN4$T#oN_tU1Q_~m~4HVLeF zCCQFqH0J8_>L|Y#M=9C0#1%U=-tpio$rzL#Zk^@ET;sm2qD;%mLq*6LM*L{#f@BYh zj??&&M_Sa(9!U>Tp;9|@9hN^)|eM(YN?ZPJHoP;3tlkmXANTGFnvl|+H#f;G| zq3YVeL_zD)g2eIOyQ{QQ39t$?!+cc)$w>;v;(Cl37m-Y0W@4Z@d4PRwHt%%rX;xOX zfg`0ED$en}atMg4o1#+MrJ+U)d;FnKHw_J`U*1c%2a2)@WYG&R;0IEs<$LNEX03?E;$FOP4tnBWnnfN`bQ#c#v?RuNo50+?aga&&C_zwEuV;ZR0+*YD$PtK zwF$@Rn6cD&_@;N*f34_$FS;j+M`UFOhZ#7Ic}q|%E}wBfA7iVcYQtrDaLdTp;(;sVTV_r`9$l%#N);|ez6F1QtS5pw%zt0n zvK*R9MS`LOAJKXIl+<0;4b1n8YNi-!-Ts{sC5PO;@(y-haJbzMY@(A9 zn~+ki4Epz%$&hNMKO-%@>x9m%Vg1qmgX*lSv~yL83Jhyi?8n%q17z0yd01EE*dHa6 z>N5o;p^t{J&Y(Uq38vt`J771CT*fWUMB{7dk1Vv{k$zG$a342J9mT|mSh53AMdDO1 z{vQkQ6fD3ePKuEy@Yb%4j%JA#Uue!ss2Us(WV+lTdCK~yH^eeGK$I)T)Y@R3NB_5Y(3rYRFPh^cGs@w;5Z3n0g02r@Udu7>!rBsYXn^_a110Pv~mX^ zTkHrym#wJ>_%x?Gq2I&j9}_qW3ckO;aYN@2Xy;_O!xTNl^X&IkZNLm9{{0J$h7KE) z3fo^OF=OPY6-gSr`fu>z`lEaNAaJ$LVI3-zfX&Yi^Xg7k1wv*W?E0ZXZd(>YdV0jf z#0$}VU!a^l-5u!Sd-9S^0?SVWpl9y@6~c$c%@TP1`zD5LmOrfaVhzF^-_VE3&>SI3 zG$!#n@p;wyw3j^%i}|6|vbpp;QP5$NQ5IqV`%gpRGh8`q$e zwQuZc)NE7YHY~TPxkK<@ZiwdC&3vWl0T3L{( zl{Z^;_T!ON|M;NH2+fT(IwGfa;Mg9hbSQHNB~But>hCPT_-GX({nO~EO0sY(wU@vS#B5r#i?i>1t%0_Pct#K3E;?uv>+d{*umCv!K6;K>S%GB(n#j)>_5(ks%3HA}<#eP}aGw zhZqpcMd+8LO!~wi9>#D)h3&$>;>RnmokhNX#U8q>{bBO5dB;K6kOv`Wmg0fy_tpUaudf)C zp}D!Z1g(j|Uit=%rwZV&A99Bu&c=IeMMd7g*TyCK{fxeLjrC%FTDo5D%`eA$X)Dc+ zE{tSGVGHhM;Z9v=Rme)36-~xVdp|}Rto9_K?R%QneRFe%G|S;*gWu;Km0n#}57Oe# zBoL^Ln3pH8&CfU4dAmvyh`O13UD%_^-bC^D?d#Wbc4qfVU}at=w&NkegXmB_dhqPI zwGWpyk~4}ZNx^X=ryqS7J?VL)Ie#1$`sIrS$}8_*i`}FZ(0jYw`V&)-aX004?^M1E zb2jHR_yf)qbW}8m2v1Ea zDD{nUM^2C{^Yfq2@{)>* zx+~844GD2k+KGl+sz>O5KkBGOz4?bq8luC@g*^yAY8(y0`}pvvA`yL~p}!Xu_(7`F z@IO%4Bp%<;$>K~Ul<{GiQLH;US6+pO$3{c)bmI{l)ejBtE$VQpBE3zum|3o=ZC1(L ztZX{GwB{ZB>G+Nd*MJSNDh$H=?KS=N;}dx}V3~%gKdA8#{m9ZEAtFMYN}{NBK5IQ9 zgegy&msM3wa-J=_lYG+_lqAo&AMnLOfPhpe*nt|sP>it?{{2pHJ;q5*mHbiK{h~$J zb6<>lct%tJmxIa%o9e~N{U!6+0r^w&$OKm9x}%ME${*jmoVuuB+amPpBA;e3#=3DE z=Go~tSrd5Py^Y=qjvReU^RbE5=(6Fi%#`yj6Pril&(4zYm?k-6thsv1OJ{ zHY2$__H=ym`I-3!6=|zrUy{n;c+dM;2NNC#-^VpRY2N#!o{v?@? z&D)!d-mq6F182kq;>{b8sz$r#P<84 zkWd80lVjM$G>zF0g;oX+jV~?Z5KWn|3LYI0+?Hd~EH}=0s69**%-c}DJ;V!G{yjEX zUzq?K$KmPqiPzFY`~wA6VfLIivx5kue{_2Llkz;`G~>~>sqwvXQeV8|+wpHdHYa?w z+Jo(BxY<7?R6o8JsK1)sB)kx>q7Z1;*45Fl0r|L1BZpg}UD8kYzgZo8{wke&K);8- zrF9^RQtmN(9KoMswb=iBH85RYMUO#9u0KzV-_}4L6svyr60I0D*2XKhXKavP>2#Ay-1!aNWc3+WW6@`=vy74nM{(Qf`;x9sF z9`~qis%G~uHV;H3;td6TQL7ohx3G29zKuk#D9z?BU`w54udQF{==V2Vz#Cg3?)E=s zkiGkm!|j_sE^pEK(z#byh!2;C5d5;oTCcGl2M+WXR>mxPtjW;h8cH|AOYiAC8FJ{k zw$YWl-bTsm50&Ot3LDA zpU`ONzFdZ$JpJdo`&ZfRed!GBw%@D>JGp7_Aa8lBhH(&DAFB$)d@F~BAr^G|m_^aJ zl`Q3A(pL$rbTZVxm+VJyo~R_4KNi(0bxmHsH0ro9WLoxuP)+7UM_J|V#e%l;2h=l# zA1aSCv1@G4&v$PR9D1xZHD@(Vq*590=Fr&c#EefQ?z8+*#o;Vk%g{!>fnu=B_lUfF z&nvsTTt(KpQQ>Fbkh3%^$qm(5x|flJWC z!c=KE{vfY1BI#ZlZKm!@hFjoLj%^)7c~bez4(>8ab8ow{`yRdI-Z>Y{XDp{1YUmty zYjk7t8NKl9^%rbSM29v|!e$*47P|!XfqJNr56Z@Sp=OyZ!~gM`9}>cAUg=iz@@I?; zP-K%pqJ{#*+l0(pDWk+_u-J2_CRK{CadC0)yd?RjynZSNSx@U zMNLf=TQ<%wm0jl}3^;DTUwQk>p74Wi3)DMoO3X-z!}`F!ut|MV67ky4bpiPZD_xy( z=^^(3ci|`K0(Eji_3FJYDRU;zqCD|~ZPz%q_%^JLqqV38_RYBH;~%QW(=-)CtVceK zQF*?(O2cmaNIOPDj_dXu(`}98Sx<_rTChBfo|x~gUpBKYpHlWc<{xZ4OuNzY6}9-P zXR>7^-Yg^t;&El;r{Xh*09Wcp!Rg28T6*Wpe)N1FKXWo26YbMrAQ+#>%eG8OE3!H_rJd(R7#rSj^9gX)TLJ>Tr5LL+elg(e(Qzp4;K*I($KOHC-$a&x%>!Q>q+T z=uw!z?qOt9!t%2!oTB5^;)H6B4(bZ3c>8dFF&JEda?JavKr`)uvbGJvppV*vpBOGp zMLsYF3L`Vl_poF#eBeTSW)}Nw?=Ih_kxeCF34>v7*3IgCA@$giabfc*CQ(oM=~eJs zDEJc77%x4vn~dho`kvtwc1#n4ADd-agc2TmU^bMKZ_$@??UuDu$s9$^xOO~&B;V6E z3yeU8CMz^U;R2PIn};@L@L;VE{2LX7&A0ecQN|ux*`s!3)=s_`?HjdG8#{%@#Kdtf zTUzuY_8&J&W^m{wcFcOF-Y!W_?1%9RyU7PLW-bd{H1B%jqVLWT&%kJ%SrT_4WfxLu#+WuvsK`(0DKT~V`c&1+^xjnIxDHazsrYlzQKQ9RyBx(^#$AS*YPgm42tg8RnO8( zURMjmoAP5l^Ih_d_1N*ZqDO~4FcnnPy@hA(xPhZ~D=f&2Ep43J?AObRsrL%< zJDp8^M+lu9dR;mBP91TM!+>L7fl00vHsGyIhrh7ng7^|iVjA^k_?tKUbov+qt(+b6 zQ=$ro2ZJ`VAI1pzVgWZtCYJQ5$WIUKJaSl;Hjn0IJm`*Dt2)?H!&a}h`gn6n2sU1s zycsru8u6T;BV{>Ehd_hM^n!}xnb@d@evN?crK}H~PAL#S)4Z4QdH?6faZVGpps%eA z3K`M)Cg0!fS{=~o+P^6oX0+(KP*&3i{a>-U;kcXrCCgeHVZE_c7LNsM+paK_eFOn% z(Os#%QIEpIM~CWcmpn^+T?tp9nDmE)#k$Qe{|zk~;PSXyKEAoocbDVV+mk3Nb6=B2RH}AD$%~%u~{ns`l0w%IQbup!ZIlOsbxooisVui?Uw}-~sk0O0kLCV|H z1RWj8iap=f))WOw_qIo{K`-goOS%gWuh@1f7dA<5Km9_YA{_2Gu+U&HX-J=_%OCP;<1doh7uhforAe{PjalW!_PN4*^~Ci&ByuXD>d=) zeV&m%S%lPAHeU7gjUMZcm+Yr_bn%az61NWmYOaA|GcfelDe=pnpI*FQG^1FI$x-YQ z_s(dqy0+G4=`P27X`}4-$_$R$=h`@g#6P#X1wT`=w}Z9C1q|ntfhbaG3n7bMLD++! z13P;ut@p}6mOKFqt-o%)?lsjQT&5R)I7hti$R?x_6L+WUCNmB;mMCN<;%%hvKYeK& zTk3MMJ!OBW=ZqU>XpM)neF5W3k_@pzYXC(xU!IOjTNF;lyU$tOKWmCADOpnye1kp| zP#8!uyJGI<9uqR*vpv#TaaE7;;>}}{m~6*WYxUUq_o%S6tdjmPeP=^!tsLXeeo|2M zU@JozE`Dk*E4G{D*{Caa!4|*`GVh(BBL1~@2)0cBB`nD{lSZ>d&+D#;|bA&7j0@8Ei7QF<0;Z~oS)Ga}f*uhzjGN*|PB=1d#^+e-fj zE_%C>vIto2w;DM6xE}y$;83+8k>%&O8Kd$K+ygPSGP5mSYoh-F`w~`ws z@P;GKgwQ1wbFSXIl)<+FOS+b8D*R;4*lBB}%3FADv#0JWYIN*I zl76N6;O0myM!c{1K}ymE3$9MJ69%)XY%0ww596C1FquQ8%^($+>ED=l%4o4&bf}4H zoU$C3NE+7?yMd3-dr$R*P9<+UhoOS3ZTP1Ck7haMr;^n6J*(_|hb)5y8zO8uz`rtcU##!7`3z7mmB4)qj&I0TV%^d+35 zmrB``Qfdj`rjdUd1opR+eYUN29w}T37Hi_7NqIO@zn%}IS zBk44rHHLlYgZ^iuC|;I>?g3k@&vwzOHcMI}vDEQrJVnbD1d|z`ts63cP5`k_RvL(! z-1_pyQgrIAlhM9JkXkE(%i^r6$8w-vyHjvTz+9w~34_chs#h~iMuzjAZw?r}3h*bl zzx^qyeG|VM^(1SUVQrLK)Q^Z*{c)MJ^??FUc01c!%`g4h0*y43$p=xVCTao%f`{pJ zX8O-*WF33BJwqRYvKkjvG<)$3=f)e+-`jSeUse^6HfNa5^qxB&s0~j}zZnJE>WR;5 zKviAN?f``tU`>gCk{hF_!7SDQ&^#alHvzQQRRN;;4N&&ei9I%9=)Bf-R<%Et{7sSo zRU+l&b*G{$!RayMQ&Cm!#2?FKu!`*uoN)(5DqF|BVqY-{-9fySy$ecMZw$B}=wL!+5{o5NTIZ-Qs$$`p%zv1I1B9_!67r>Am#vle^+#e=Kym7T>ma zl%qd15(m_L9L+0Je(Seo9Zn;vKVb^v(WKsS1Or6(7mP^eO4XRdRZ9M~hYE zgcH|u^zDREdrifKfJ4FE4*_98-Le5FFl<3^yfb~-gt$YbWMutY=T1VKSx{o`ZDFwI1@go(%1tu2KkE`9U_VkmI&(l?qXa*~Bh?SQ81MR5Jj7^7drj zS;i^2n5j@n(TBUel~m!jGR!~cS1hHObz_}9i1i?ImXlm^ExXH6e`l%lk`w*Z7ybS0 z3@qLdPGP~tPd%aF29W=xk-;CYv~zU{eDcLgmHL=*AZi8zzDes>XqEiP-~1}Qv@<^W z9>&Q`I*qsmmhBgKCblqP_Zat^aknK$oA`@XaCTRGY|7o1N)*3VY~KoBb?6yxtuv+& zJ7f9q4$+(9c#owTQuqBCTd`YXCXShh@JZRrkKB|O1`W&(K{nHEFQ4jo*{Z#-2lvs(7Q zJq>sXrxC_}C`qM3zPm)sdRjMt_4w(v|vK{4j86h+|xuemM*K0b44&RL;qC z-SEf9p2@Li1dq!bHaQ<#5I%Sy#YE}w_GQbHnzG=Dp8@>sK?LxMjs+3$QXA)7c%-Rs z+7>(oHc-$@{_6E1{;V>$dOW%FpJhF3V+_fATb`Km$S2#oF;`I!N zAo|Zc<-eguV?2h7kJ({hRSwCz|aCTTGA3rRO(fWdVDtt5KK;2g@Q4GBVIE=8d*))9-DIY8;{cZ2z_H^gFWN zRwXgp-Ye@{CFSuSVbf(a(4-zRCnzla`=7wBkA3V&vFf^bNG+WX)^l?=vbD^AkID~w7zpCy+ z(F~eovPO@tc;37_>y1@x$?S7l=juDo?g6Pz>ZbBXO7{-;SsG$d%m$tI=JM^Y_OqF4 zzU3#oo>-YY;$On-aLz`(KG%36?M!;HMPI?SV_3WFmP7l3jfLSWOX^RqPBzi#Y6V&i znM{5PqZltmw|MG$7aKK@t{RY9Vgg+CN1sUu%2r3iUTjNx3j3a1>JEjAc~9%Sbp=1x zb9H2G+>a&sS{m(If~)?ctj8XToez~G=J$28ihD7!&4jpA4=@}60Qx0V2?qb61U^bw zdln%aU9=vM*)H0fp-&#kM5 z(t;vp9arz?Jz@hjElr!7tUO9yV*KU#2{4$D^N0L_7ihZZojI3?7>k>#YH@hD+Lc#V zXbY?+=BJ#|E{qNC{Ud8^t=f-p_wVey^V68`$k2X`*;+WfXH~Ij8YTKLJZXN)DR>Jt z@qKgBXS*H_s%P~Ur4IX!#Va-IlPP4<59zUk>uqly`jKr9K-4P>I7+9*tT)pW&bMWo zJX+hrP@Nm}ejSx`6UW+p{qD*_u0T`q^i@|AJF@d5hX?VfX6YYa^Cza_Z%3`D|ei~ z!fC=r6P1tv@d^Ady(GEggM)v@g|mQ69!WG4D#kBooG4rb^NAn7{0lDS^X!64a13 z!wd-YJEi_b(X<80f#uCLhjuPV+p4&ZMmuWL0oF^}{*RFhTl1W@F!DEDjyb{KsKb{E?!B=8Q@()z=5%kZm3S{}kAfr7t~QSCgr=aAKWH2z(@T0gk1I zK{tP=vSe;k&h%frhdn4!7p?7D_2fF=?rrt@nZ^2u<-@cpndaaw67PZV9&4o%>8#T} z_CxKrg0ZEm*NeyY=99zy&Jc2}-xr+jylgw7yWOCoUGQk<=%#Z5&0y))$U7I3;)5;m zq=Tr+i0J$p%f*pOV7NM44-=u?D5`bBxiJI_{$Aam!;i@CJjM}LiHNw>Z&)*F$DYD zfDsK{RQp0A@bnsate9h{gY*HlkZ10c@jah{5yK{3)WnfMM~R20@K?&cu0vU$G9=q)$AbUzGL(G;L*S~zvAquwQO-Z zk2Ev!LaMWy(Xf%{bxtbkNE~k0^h?NFW%C`{jNlRQT$P)6? zEe4BjL(GwUM4>2^USx_7I0jM~JH|2ddS7dgbw@uIJ7oPT24SsEIJJVKs6A{lvF^7rX?)sbP%rhRS629;4PsAM;S9?%n_|u9* zuAAvp2k{~e3vC$O$Qw`d*w-h5Mr#{$OFCzZ6ldr8f1rRF+_&S zRp_o|Fv)8OoYIOI78je4xe66QIj$p5c-~f^BF&!^#(Hpx=0nifCF|o` z6G230&_;Oc7gj(7G|-is65Qfb9m;)o@FXZ-UxR{auQ_)eQo@SXL3$;oLO|=u7HQ!L z;>;lMESE%Rn7+d&nf;?`=k^JC-~r~FMGV(3Ke zOTszLixo(PH%98GzDl1l&hJ|GBBm5BBXhDeq(rkHIOX_Ls@*&>TvcdW&V1OBZ2R=; z&|aIo?IivwY?=Vw%~xN{i(RHRL{Nt~#X9B1QMIfB;{tjs`D$5Ok}3SUeQ13B8K;2e zFK8c1O;ivngo9hya&ALsS_%ITZ3uu_T=W2D-SiWGPb+nFpyvWxHDnQSJ8UGrDz=*z z3&aCa0XL@l=g0aLYi*ZERZo2UDXS3)oXCVK;CjO*kQtRKs{_T}n>EzEE~=_QBOpqN z%NAWGa6I!q#D#PRL1dA%Lo!$e>B5ISHOT%K?$|;py_P7%u93e0o+fyhx08s%kJTT88c1xz^7Rc$zpe zEX=_r=siiM?w0b!~q+k0KIdlZu@bs{>AI3NxLjJg~|58{5 zq~9;*$E=hSAF(KumJQ_K%$}%V-5m*5A~iVeoh^!6IoPFU=+#YP;wmC<6GyfHLoI1F zt)pu2=0`Hco_L3++OQ?P!%4ZuRkd@lr^~r{@1(`}Go_P;=IudvQ!dqId>^Uh>g7X{ zM?830DzLI~^~)p6_fwsIQ1nZc5%*X-Yb`}*w5jLW&u*`Mf7Wf?n|tL+)`&ZmGlo&r zlA|-_)_0dTf2x~)W180#N0H{!2o08w?~AFRLQ?~kPWXt`O%o4nO3t8ZJd3Qir5N1M z?>Run^9}XiT~RMUVLds8S9qKe38A?M(otDHim_o6i@Jg5CU*!@;eS3cocY?gg2GqM z0#Vvn#5W**?#FvhT0&Qr=gi26NL$F3Z2%1?6U9{396mn2qx5Ty!uKNBg*)xy)i4lX z5~5ZDw7PzxH6!s9Wd-nMWvd6QD;LYyuR7Vh|N0Iw6%I`z7%`9|r*wVoeqWu`kzOub zn&qbVoN@Ik$)X7Vd{nKL)Y8wmf02%ub*ffa zfcaBGRSiF4SL*=f7CpG_5s`O_A+cIGovgQud^YES^3^9GO}zecnuwUs-rLtZdjZJOzSuED{#OgW8nm&2Id^pW`b{R9t9 zvabRc4qKxyyy5QrzRSCl%{VP zW>LHXl(N;3*fR*?;YULtwpv5{MektHi6TrMSzL=t7**|;f|v>6NA0X0{haI&ArRP` zEn@funW6EuA)v?W3JrDbee>J8%>fApU>JZsj0WJJbRE~(WQx11c=+`6d+$FGv)L-b z%(!rn^Ixv;_us-bTQDAGQ))Nlo{pyn@S(D%D19776*F5?q%xqp~QxNm0vJ4NFFg#f;9LJ z43yy;@2A?lm!=*DX-bXYHHl4@a2`{|$1nJ9#Y~};VKf&CTqJ(!xgYLUXf$Bhy)I_i zvaP+AQq`gQvejTx;)j8XmGd<?R(43PY!bzSkEnZ$PfssJp82GZLbPEY#dPy z&XN5lYFbLoNSs#JF81>|-lfJ7ts36zS_ucKxHyu4%o6e3Z%?|9)8nQYl+Z(8*^cna zS3mqrtm>oxUlAs5+M{lQo>g8)J3igxo%XNV(ri61>!RWv|HbzDoA@At?hyZD;N++I zZsv20Z18%iWd#;g1ADk?aMsHh@8va0VvCsVuh zIT?n>@4tHi`bt>N;Xp;)@96v@o$h*|)X8!L(iVQ+I>+wkfAY_FaOh5H(~FB~4r$U? zgzcTAwFu-pBU~67z)o2W7SB0T23R13yq^a06peVN!ScMB5x2Xnleruj6ooa!!+&J zni?%NbY(O#wcPza>u9aEskR;8dTD%F z?+J&mk(&(S1VW;>AxA)}3p6ls4}iF_!xD=jjrBSv+K^?q9e2<#0sZ&&rV+LT8P zjGlv6w6~JBCGxXYude~%C2s~M$n|(1RX|{)ksSVd!RXnTnBqrd9Hpi>0i{bN&6R^` z8UjK~-yIH!qoRB4NTW=QE z&mt&9W?}AWON^+%Pq9A$5nOyYx}^?b`E%cSbwx2>W=A#N1=XExQ2L|#z1=)~VW@_& zw{(|5zCHWct>6SKzlx0*?t!SQ-$Be!W|{$8?gt`DN~Nj=bF)}g%Iz(a9mXpBiE)5p9`^zG_cp+k+2-`JP1IDkAZMQ9&Hr*C4 z0HJNkZug~%b}bnXV7_6@y3XjPZcu?9izCGCoMLYT>8`>4?(d?Oeen-MMpZS0HcfqovtMXys)}>(2>a9Edki+Jrwtgf960hl zD`vOE60l`t#iNALLUmrQ-136t$LOaLtCH{>8*A}6Sh7pr=;tbZG{C`6xzS#r?(<6^ z{1557@c$}(PsV&}+!7`rJ;@4P0slm)uZS~rkIe!>66q3a5t&R36YN|KiBY{AJGXC~ zItxzSZ`-D;iFuL`>t8z<8O?hDB5pAa%=ei2%dLg1CKn(7uu<6_D5`rC92}f^aCh80}~S3rB2)bku;D=Xb0semwl4GGa=qWwduON4Giii zA;`mSW}zBa#=ejzrmXc$AOiLD12~O~?G>L~W(|r>NMPcNJ^Q0eU7-$ZBLw#op~ z6jvOat#DrFK|u;e!!g@VdYse{a$DL{8KQ|)(@%x%+;Yud+p5ftLk(@YGl$sx%6=}OYdb164z~I}F z^Ry_66OAq^rZKTQ4RuEdJexY5K{(rzJrDMTnu`d3`{e)iN7X&#Rvm0-U&t6u3b_Tk zMld^mSKfamIvfPzfLlm(PDkF$qG(?DH6^D^tc4-WI0&pt^*X&^22KL5=>PB6q$fb% zbW7f5KBMp^B*spH48utd4fRo&-)#LR69skc=AxnP@2lpIJo&$F8CN-AB%#A@8VsgZ z!|mttyorcf%=Z9mcpGE@8+EebUb4|^XvXU-je`Hi)jW`^Rk*1$nCgHOULSTp!z)pc z=1WES5>y=*lq%I)DP(0+OLUcJ|9nvY>l6L^b0$B7qr1Z{>*g1wklH0^(LHj0*S3``g z8rHH2@OH^2M9H>s@MR}0A9Vcnmwk>xBsW;*x_#39joI<1c(52l0Xf=}Lj#syxBsKL z76W&~f1u&?e}1<=U;YFN!Ky|ixzC*!1K2P&C;^s44n*MU%V)zHge590qylUBr$`Rr z?+qzpr2O|C``3^EGVT5JxDM&(AiRQE+gF8!h27bzA*q&b`L007dUI~VCIGZT{8ttHu27uZ8pBg^rDljaKgSBmG)A!i;BnhrcaOhPim)_ZWKg zI%M6-F4r(UhzMJ?T&&)7bGJAsxNaTGOfG)kW4S~qRW%XKwz`}#xu|zvKfFvR{gv+e zLLJT8u|L0k*W{`y0we*wSp(FZP62CwUxY9Z>~G))fK#314zr zLt(;b;fN=1vZ6`9*a_Z7pDZz^s_|&_QCj`u(Kjq58;t+qk)N&GYbvwB;rwK>Vc9Di^{$6))s8H#O~P5&XG_{V(f7 z^(r2ri|SQ_W|=}b)?g2T%~u}0Q4>f*B!`AhA;P;WEcPsHXyV(!VgKa{e?r_@GZE== z+5iPz2*g%Bm?)Xgq@tqyk*1*n!Bt~V@nAUJtAJf0e|dOcPP^Fr$20u%J%GzoQ^JPr ziS7Ehk(;&W&6Bt3v8P^2P@Jg3YL+!Ho<%CJdyJ;%MMo zLktNOHn-{j+nfHUr_;a-_s!+(y}fyd#r`gM35tFa7e)dc(?&#uL=bdT7TK2J;Neg1 zOy%1D^_QhasL*Q)qEdTONK9YQDD1nAR1A<0j7X4?p$9Bf#)b`Q`jC z57zhwd>KdMn^*^`69}$kgvL>XC;Dk!UeIl8p`-GW`Y07ZVDDM~!Azk*tg7j-I;eSxc=s;IPHYWo7}$>Bskq z{yc}`5Nz7T!pn=Tq9ZMLI7@{PnNAx(Z31~v>b66!{g4`5h3i{-J9 z_OVbrX{aJHEJX)71EfO`3Y!Q3OVNH2n6ldep{01-mveSImwLGEN?umk!RICgRU63C z^M!#c6ip2cHhvo*beQV%g6~i?3Z3w>)xyHCRpr4}q}?78(R9a}xbGqfIOIj`Au8sp z1tU}Cr8PkINIZb`ytQNS^Vz65P#}rmqkV=jTB>*M+|g+%yc8*TeORi}22Ca6MP`88 zd*mHNGTQAia&)Y{su0 znSiFRA$p2Aol-J7#kY+8?y-D0)UQs@4Qae~*>|rdy7iZz_t#farL}|wKbtcTaHubm zUl&xkTxvUcvv8V0fZQOWu1%g>^X~A=OL6%4!z`x3RtU(&QDL1G|(s<9ek+U>NYR<<13Q&TqhYeOfo`1x zH*VMQks3T_GtfyKIuEnRtsC2bl&zMOO3-#fKFe&TmP)0iqkH~~c)#YQ=?!3(1>)Ps zCT5IG5$?lMDSvx$)`r01d~WTw094Zg{YEq}Oyhx%6((YMbPJxi*uFB1``OH<)G&qkYPu1*``cp2mfo`3`0HtsmO zryK)Y&_ZFp=Q142$i`Ftldm4^zL*c&_x_ay;J3HE%<|n7?jOab9>C7e?UrlzE*e%R zuKd5wzC4=By?sC1#ztZz63I+uNU0=hlSD~6jmnf#6cG_o*}H@^NQELvD$S;nB14Lh zsZN=xC^95tLjA6f&N+5Y-}RpLd;fUXS*v>X^L&PTxbEw|?wA#I3!nVwMG#FTi?Aqi z`Lbnvz3tWWv^M8ZU2dvx6{J*i=0A0wdQALaAN_rFqjM<45WK>+OTO+)83c}C0N>ZG z9zg8!Q+YpSmCor+*KSK>q?S2HR$&yB;036aUP7_e(DG#BSEogyc~kaAX$U2xHNCoz z*rG0F_&u8V-JMRaKA3j433WFO0rW1ry7T@lvKqK#^sdW4v&4FqAg49KEe+}q4BpP{ zh(Uk)V8+%Q-oeYWY_rBG&x+9TxUs(R1SAQ2-t0PfjOZP%+NBIT7ukIz0q93yQsz*T z#)0Y@ZS&~V67{Ht!~ex>*>Wn{b0Sg5>jS}4icBb8JThy*J#(llxZAYu(qf*zk3DZc zg?>ABhPAt!TRD?OaZhz|)*aWUke*i6AL{JnWA8bhj}O%HqT3ODe4AU$q>| zbMJ27EK`-@`2OOi2+ox;wt3K7`(|Hfxq9{L{jxc5Y?c*#cWg^NFTyy@57fN7yCBjE5x&(tUyf=qKL}Nxwvq@0Tj2GnLJB39149Tt~el}dN{G0TOCY5H|igI>zV32rPqBK{dL{v)&Trpe$e^{M%VYY z3P|f#+!YrE9(Nal-29s~QA2lXHB5c0>vGXXJDc~v#T3hOxDg25tv#pg%CFhs&rrUl z|D{VKsAPlYv2*hRv591y8NM-c*Td)adpaN?XHzm#eIVd%ucKsRndEB_Lc8+{pYQbJ zrC?^n&dd(D-Ql!}Pgdl=+29R{lnRdJM7J;Ov7WyEzJ2?`k~ZwT0JYoJ!mrP!_uo0E zoxNQDGcT%#=vqr^f70D$d%vOgxu(m-mH+uG-j$KBIB69P>X>YI`gbtx9<}S_OcoXF z_Zljim>t!{JsbN)CJsK59YVzC?Ndx&nKzxJ*$m1%8mZo9>&_t4UA-v;ky~l(#Zma55WT&G4Via64D~)1vcMX89Dcb%U~9#;MQp;@057g zElmB-Ugk_3i35EHZ^A+~gJ{W5^z3#WJf6VqU-Cd<(d^yYo^|6su7^fZVU2T z-@rOrde78d+_Rz$!!qjw!Uqt?4S5^B(P;KgiD|&630}E+^#~lNqD{i)Zo=!aE0%>7 zkG$*e*BLszJ899HI-R1qtk`2<1P$1)Q^qPRG&OY_Y)=g!Q%plDv*85O?<{_{Agm!v zGI&ef!n^-@HF6J;)zDp_+Y)!$;0MOsEv{Sq`0yMR-TPlUErQ<9Zxq;L28ZJD*;~4E z?-BR>bg&n{A92^O;=Y9WImJ`UqKgEhH!*p|SiNd49fRHHoubRyGrIB7+ghH@ZOG`# z(ZNZ5)qlT1pxK|dv$);i4Y#1Ql;&e^i@>$>P^jtSQF-kPCVG?4!p529Oi{Yo@Hix0y^Hepm{(f0KwEqJI-m_8!SY&+EVocKM zTx6VmOi$BA@?G|~u)81?s$3J;byrYidG3y>Z7!Htvyjt=@&lRTi&@qQ-!C;{uuI3u zw=Z5S=%~+JMCMkMLNdlcNjI<~6Ge{7`@P>1ws^8AttC0i$E4=Zy6TmivrHGd{<8d< zbUjaVb8{H=Qcwe;lqn_KR1KeyWNw{UZCH2u{)KO;%KtNi8}U7XOC=fRt`439kLrij zwH!)gN)cDK-|wRBbajw=|7G^7st;#E=5N+(j9OzZ)B5IaIIyiv>W|uzqGs?c^ANEl zys}l{lChF`%+Q+Tfbu>}92W8Tp#gCmQI97Y4_B!HR4v$_U=V*v@||6jQ_VZ$$&(pt zL}f|X)BJMysb<`wBVYcUDHLnRe{R0}RZJ(X(g-e&k6{pOM_pMV;<^9nqk@)3{#{8XG}O_MYX?OHa5w$c@t{^F`hXL>7CU`9*Z5lerDCg2S7qO8Jd*S@^sGiwsd z|Eek^9)0jXfiQD!JYL&N1Vc|645EL7zFl_re{O`3Nt!$jXrnkujI1HCmXPOWP(G{g;;p!xh=HF@fCZacn7YMOM7i^Q@_!&nSepvQ#f70U~$2mzPJyXC3B3G1V>AzR+M9xDWcD<0R~}5Fy?Rk8R>lz`%*$i$)x3y@A+nnychKtatl44B1(H-s+#@x|Jdw8MSY5)u*z>K=WV z;yyiDr>yCUkjUyIWO22~C<|Dm3XuZ}GIRv`Qs1cq(;IXHFjZRME*yB!A10+r*(GrdT8!#E+(a02e#XX*q_9 z(2GD~Md55?*0p?u5iU)%T(bSWSc_ z*&NQRz$ah%&FQowh!h8^o#Ww+9W zz%PW0bO-)yUtp%w6EdHF*q?QnGdeIUcbhf(n#1|6Y%h&(n}f!R zyMgj3nJyy-Uvb`1$KTi68ZTtQ8h4~m)Y|dN*yw~*%V93O{Ex0WjyZ)=9NiOydgO$b zOEm;>7qv3Xrpe1c;ic+cV(iL``WCDDgF1apd_yq5?kRmT*d-%uy=)G&<8pJk$~5?| z+r7c0T%LYDe}jRGx@zRMopGaJLms=OwEG;>N0i8j(pVO%*or6BuCJTSTX8k%spGD)SpNkZ z>wKC%?5oe=X;d2DSuoF~&T{gXGlTO#Di|UizeA?=e7_0TVrNZvTc*F886=>4i8&?1 z-MxJU*;MoMyiw4adCWuUHncrB^-v4uL>}#A5Uzo(Ci=o-#*;{hdzaku-<$pXXa?Zo z3#k;J(8`>ta4!}9i}N3IDSk1{I?NGmoV8#d9F?e{a&@WIeW!D`Hl?aB&CbFc<;#(7 z*2TOL*N(>IXLa2_^%~yxhy6$WH+5zCM1wZ*#T*fd3eDGry4EB7uUt+hNh1%d&lIHU z-_`5;aoxI^(!J2uJ0~~y$%QQwgj6=dOCJr>$oM@2B$t;-nslI2JcA(du`Kwh*=F0G zY1z>O#rVBG-ajWf4%ednmmSOs&8B2u0is5qC%D&<Xd8d6Wm9WK`u`;#?GmBdNczN19(9>x&J{kJlw9lLvS8!70BNd%2Q%UH2 zaj#*uaq0Z^tPbt=QCv=;p z1W$VN&OeJxIXujzq(1Xe|6%UzEe5P%%ZqbJ_07Q6R_y!zeguPIS^`yM$ApgXw?Zs2L(b1Mv+9P`@f$s~v!& zDnsL&iNE(7q6^c_q@iHO-7`puYxODzk-E>{oDKV2pctI9F(u8{rTYGDLaBubbiXEb zL6tjMc~WOCrEUPl|I0VsCvebIn9zb=N*f=`#p4-mRfSO>8gprU0=g@CFdA~P=ZZA^ zom@>Oh|M}Vt$yB9wb7iJTvTBoj=Q{p;Fo(-(lbVUb(aAkU~83CJioW~rossV4^aRu zO#2u;gUlX|WkDt(&h*Z`1abR2RhOS~et4}H(RSUjIvsE5sl~x`c0g3a%u%+DrIb9< zzqJJg)h!dwM@L6LeZo|p+j#=z@}SBvWO$4+5o1%+o{R}zvixluaGnCQ)rMB8zRe;% zFsn|&-i)IRkRWbRO8l?7Z-1|;xe{*;;O{O}_m4V904v^r`3)xF8mEKx4lk*Ew$)tM zR+@G~`(0pQbQ|wSlmnjww5=`d0(Q09aEcjTGgQ%5*4RyWieWH|m5eC-rpOd8%Aw}V zyn$F8Mm8^*CG^-Ui{FBH^Q|ovBJJLF+-(m)zEkaeK&)O&45_i7k!k<^Jt?4aR2xgq z-gYbsLx5%>OjlNonCrap+=fjD#L57y1co4kATXq%`2ADOK|JZCXejr|74p7k7E(|P z>v}TXD~Ge&$j#{Emv?jV05K8wsjTPIaLEHzR&m=Vb%PjPVTX!@OC;jX zKq;^(Ks`{buVVWQoi)rL9@@(_(zlPySsb&K_#BCjV|>58J3`l}-vPyum{GA$>yGz~ zuOAovnD)Wof$CL+hW2#9S9h!y*j*QkmTC6L>H^SoA|75x#{2*@$%R*13bjtkkeIAM zrXACm`YE{4{oo2X8AwyEocG&r1orb=ejZ&8=9Dc#?xtQMJ=(Sdz-YsEaGOfQ3qRvM2vYudO_C#9NYfL_HobWv&7g&@L>| zwawuhv2^Leo#|2$+c`hmN8W%jBBX@-3xa!hMcxoIQf#i3iO{$ych~8XxzHPGQSwT2 z6`>-`8`dnWQA;mJKT1-%scr&N3)S9{ZrzwT!g^_0koA=Gc{M6 z+X|^^&s^WBWSXyT(e^baD=U|$Z*P@PAECynA^0xKsg*8ZTQ`P+kvg zC5grjAJB1!)Qc@Xxf4`@p$h;g}TRyA_4eV#;T2C`#N3GpF<=xk}fS8LI1Z=!02!ZHdz0k5wfv{glNzi$NL} zwKzAM-0&+A2sZ!l?T*kH2~^qMaO6K3U+9=LuiS{?kEakL&R>;{vWJcDp{2(~MTH^) zvuf0Qp4*)P^le4jmV#+*lSe#=g?vNMgvnYCGJUhMnc@8>$i$`-h2N0~`0i#Z&#FkW z4}P?*<6}m+x9gWKA~r<&;O#Qx~rLtLA_lpse~8s&VTZ-*a5vA#nM`+qH}1*3{pc zcbR%BAsMFDxCN_PJ$x0!XYJi|*0=xEYR;7mS14Eo1x-?|VTF@kP{M{qtI7*rn(E4* z5jl&P?_)v|5m_?V!g+;n>CV%jWuHUOeLXK-m!5-TX<5NFSiMV*%ZIDmTTjs6AbayN zRU4%1iQ&$l#6Of7h%_on)Ni0LH{>wAHiw0Kj5r~N3Hmb3Lwh77fBVWYuY@rknIR#z)n@(|i;@q0)RXZ#CMMXhDyFmYC8G6l z*z$_eRN~j@l8=#PFx3)+o0Bm6LV3Cu_(SgPFR0Y$epHU5aDWd;1{XS8^RTQ(l5004 z*Cdwpq*bgQT6<&7?#S-Cm&0811@9xKb34T(JgSHWHLR+n+w}f|u0Kki$&cJ(#&Z(g z&Z?1^`1`dPPj7~nE_B7CqEumfJaQ<(nQe;5k?MF<4`&mBl!-ykpiy>i zV-h9va$cuM#(>dh1N_vX-mlO^^ zu1=u%_(pGER8myj?YgMn!z#1YUH(VgoBAbw<2Wc(nve{TFb)crEJlV`M?iZVEbQs+ z>q4YfgrsDfQK(RgD(NFB*LDupekoC0$4*|E%(*38Rnu`;XEm zI)F8e*k2o(g`$|-6o{Dziq(a689qCyv`}>_ta8cYekS{?q)nGG54pM0$m*Y$`{zIA ztCeDGxR&8eaCCYyu5 z{M>(@NTq2#Vz|ZWm;2k=_{GG>tK4*a|LpiFsofz%AaWcGLNDgEdaHxOy_y(vUy`aJQYc($LwjBs{j##;k4kTmp4@y2)g*-ATaMt5w3$5N zMCP`l9uqv*?z{jDF9?DId1NB?+O=yP6G)r#y}Hl*zkJ0}e8nAIUXQ;v?U%2}+P-M8 za6GFR<0P#a9V%c?<=q7O98QaKi7T1a4y;D z)2F|?el7Y&f4UO;N;9_5Xrfw2Zp`QX*Q>j2Y={k3zfl%sYmFs6Xm5L#87lX}$**&oe`M@t#!_p`6j&+qY`<_aYL z&t?NiXtwT|ihiWqbU827X(K%j+S}Xjet&%4GX$39<`5k{9eGbWScGjIY%e0xUC8_S zH;+{#e99{vEOeD$tECldzdyETk%_G>#y3{3;x>tqd1EbZ>8f9KyWy~iS)j!1ZE@MG z-qtrCH=g?>J9-&o{PEr?2|T+Vjr|3tfp9bK8kPjau{{qn8k<=^rpg(gn42H4zWhQ1 zXvrth0T*|P)$;P%$Hf?V$o5bM7nP5%C%Z~)?BR$J;sQuyBhPR}yG>km4f>N_Gi|}+ zOhgZIdhK@%$PM$Hfgz?=Lm%d41~nQVZq%k~uy2>vJ)G#(!JAI98-S5_ZwR5Hf!#vh z5d58hJ-!|u9>;~UL5}n>?*7pA0v(eluCKoKY|a}?5tCH^qeqWM%-Ok4J^a>Owx{!% zBWD;l^@bXqZ3{+rxyvF3S7Q!^x@5_c7Ec(yb?+w~BFou5SMWyPs>?=KYWWb@PsE6z zV}PtHu+{p;gMU#P#ntrr|E5`eyqWLLf z-QyJ@Qr$BlcT0w5puRG3m9@1r0{IuI&hg=+3&GSCgnKqQPd1}2J~H0qO$CUMsvA>Oqyb0v)M`B6d2JE0-SBG?$Fw0({zTyZyh)mz1eO)PJ&^RWZJVTtHyo-xxUimLB z?du*qd1e0>HTGlmbAQz+Btb3( zMJwbKFe#QF;(G4hDK~m){TTbHRK8D_x2ukQI&1{Aj&2$$v%qh-LNU2HykC}uWxnHo zy|LI6#HzlpPc;tE(Ohe?nCtA>vuUfNma#2J{sO#py3bZVCAJ?M*;%dISV_(#Gb-j@ zn~MJcTQ=$P_)wW_(rurz#NzfkW^8OMKu$A)Dz^AoSXk(SeLL32y;8!xiagf(F9Rkv zz4Kg&uTralxuvBP8Sgm#3rGO3X!Ie79ywhy7)We~XPv)#; z^BIg{xS__P%jUFyt;ztE;KoO2M1isMlle z`;+fKu!Dku?JoV05Ke$%)k}*u6>{sB?}QW-wyUM zrE5bBa;{T*lpjFi$?nM!fmN$k(UF7~zMnGf!sv6DSA~UC9Hu+AvR|+fljg>V0p(Lat! zPy++yu%Y^b)$7JM5@wE&_UH8O@^SjYa?L;k?_ZDOgi0oV?2Q}K2?4w9p&)gF0vRs& z41ld2sPbeGt=5K+A*(JnI}l^fkBFe{qs!P(h7nBz#bE(Ief*@EGB>|Ltj>5b^|{8u zA7~W7!poS8GodUsxciOO-lve6yc`=VM}}ZR{%W(;)mcYI&j*ttB&4F^7vR9pw$18uwwPHooxqhn3!#hR0X#0A)iq?iwgrn zBVok^r$#@X3NJm)5RucGwQH~FvrvY+Zz}bu*qaGlXVC!^xRydV#jZGN{;G`|CnJ!3 zG4ODrG283cBJTUNYx~$AVKn$r0E@to#UO!ciD(p0gxfbh7!3+OXYqS(N}62fO`GBA z2RaW;%^kJGXUkvdvpt*>=Td8Cd<)xG{k*Y3jNQ9;iz$!*{b&;6NURJ(8m3%GDj6|n zQWUMXAXHrvvKa>nl^9|H{^_+RbJ&)+A`?OOcPmT9u?|WqDGTDaI5G$<&z-18UCA?w zv}Xx=n{m<_Z!i!?y#x3a6fTT)typv4N%~FK2%{x+a%Fn10{bv`M zVeo#X<i}YczC-VX|M|hc{-Yt23*3ZL{xk%v=MM}+(G2fS(r6Ts z2kV~g3_;vAM~$&J>JT3RW-J05j?TDa z{IL!}GJZtZ0Q2fouN)YSQq}%|_gJ#f zGjeR;u|out$hRQ6rZ1JE1K)pPKt%@q1%rM6oLl2Tp?+WAu%LdxtOjk(Ul8;eBIZXw zy%MsxDGS-&wDA;7ytJO`m9a~IT;7%RtU;0Y9V$ttPpIfqSXrH-JcSlIPQU9rn7(t1 z-)&Pg&!T_>vT`vOLfR9++MgjhDF1Pl&#UnMXzYj@26CxSyQ{{J*#cJ;%G0M$9Ybs} z*SrkFIV;lKw~s7RTh+Z*^Q-Q#T=!^0odJuEA&;*BVQU{XXUg6h`cx3b)%HFz9o=Nc z9TMXdoHpkf^An{C6oiv27E?`@vM>)bZYSyX)I9iosAoH}hZTPWETN@nF;Sa;iro1! zpb#;2%SoVsIKE+peXz|OU8*h<*yM}RVH?>l9l5(q9bU4}r}oGi8&Jtz)yYG^dYYSt zTAH}zT&MV#>D+V~*JcVFxI5W`cG@4ve9)*6urP=|`h1#J5Vqp<%uRwzNw9;idGbspUcY*n#M_j$Jfu2b!F?(HXDY8r+ zcEGKTsq%|^$B)Nf%u3k&BuPd;T;1v&+9MF_DCA8h=}7OUEC&j8vZ+jqS!eRaVO1a! z!gw$?f;+MroznlrVy|p)M86-|_S2A!{=s>R7@N!kj)5{QhNY-}rksZs_x4(vwNLxK zZFfq$sI*r~Grc++yc(E1v9QBm5Vc)hDl>$T?H`B2^ z&dBOz>Ss5-KqCC{1t>vLr~Z78t3j>@b!d3{u%%Uv!)ORXoIWunab^y$-&$!|~M zAIDE~#c;W&pxoM_J%!*RAglYdp$hR~#dkJ@j&X?KiL}cmY(G3=f~u%yh_(?k$Syt- zmkN+at<^BWHk(y-FTr`;DbYR)Up&FAA#c(5-D}pYAsd6>4U$Tm zs?r)7j2;D#S~KSVfiGt1^DAtRRL+x7kY$OOY0FLtkMf9)a*w9+k~rs3bm4KVk@h4e z(A}pnQIe!lC2l!^b+!N~JRa*W7g`aVTY#>h&%!HSo##@OGOg9H zLEPtJ$Hz^ub4Cr}nM3vpQ}{wVl$)BGR{ilu`Am^W|9{?|!7qlCC0nrmHQS0|@flWJ zq4EOI)cDk++_Eer9iomGJOJj>eWC2-aiLBd=lhjOLk_>jF@VS#VE(1_)L&Lu(@E5l ze??sag;Y9IM_t;_pVoF530!e;E^zZc+|v?zViVZNBv2S`s>MAP+^0SdzB?w7x@`IK z_g5o#9R*5wwU(~~`jyW%7Nle8{<3L&8*#m2rrv$Q7S|E~^^M;bZObJO>6UKK6*!TsyN{y z;=jDE1@VeOV@W#V`MdmY)@e>@J+;N+{z}-!j7YHq}#-FQbG4Jkg-}wc-V7Xv~ilNsz2syhv6VIGO2;ymll zuc!-CccL~Z3`i*Ee~dcaVTXay79m*{Z@s_So?YR`xXf4M`b1ziq|EY=hh0uj*KJ=1 z0(|tZv4R^8ip-mfA>T$1CfSNCeLhP>W|~MTv`kB(H%*GP*i6jabqh&;a2#K$wqAyJ z^YFJfnI}NDcn1G?8St){+QwII`fX8vuR_dIf?a&gq>TIJ`7#%|ppteqrs_1$U?3ea9=5zls^RAX_c9 zMwoQCo;iE=N}f!k!}WsE@TRnZ+#s_Z2BRNBZV)2CrBgiCh{;V_=J&_CG%q+yknRYtv!)u^vCH^xu+_h_|`+Wc|r zn-1`g8#nF`6GQzq_#Qr^h8p*h6^BMH>}fNdX@qUeP3z<04PE3z)`0Pnm&8zdeGSTs y227l4AI@oCXKrCpxrb{*(BJ#($CynU65L^V=d$BQvw3*>IFlu2hIb5XS^p0-CKieS literal 0 HcmV?d00001 diff --git a/src/img/coverage-spanview-01.png b/src/img/coverage-spanview-01.png new file mode 100644 index 0000000000000000000000000000000000000000..f3e4b353559d1cd2e7ec1e80d6c2acc7972ab47f GIT binary patch literal 320657 zcma&N1yo#35-1D=8Qk41I1CWn-Ghfg0t`-YcXtl~0zng;puyeU-JRg>4*z8J+kN}q z`G<4Q?b}_|T3t?r%6l19BqAgzC@54pSxGf0DEMP2D41jbJftRc6+s*d3Te|)LPAAO zLV`lY(ay}$+7t>(HXN5rfC5)Q5U7$0JETWKqpfg6&XIL!xa0dGM zq#j%lrlh2bcDp7toR*g8Y#^v2d%l9LKl{5NJ~Fq)DjXTuZO!8}<2H-at@U!v?}fvB zC*2Q2mXciI@0wtNh+cx;v1eKa% zr>%7NaQphIIqmMvfDc6vy+MVjK9+Fc9J6qmsws1gMUPPHTRhY`FDWo)Ns;6w=!qk7I6tEt(C$gH6i51 zI)t21z%lh+tu5U0t4S!65v_tZXlgiqxI3vpis1@ISa(B227{1uM7whjZi-nc3Xu8h zTy>B3!d~jdTh;$oQO{56m~c{LhRK9!b`Ul`Aaaq9^Zrt*gfMFoBxNhuTD}&ol-Q}y zeEFdpt00Ww=zbp>spTD$_^%J4B%|MIz>z|V+pr-@oB(KOf9Pyc{?E{e>l7paZ|KkG zTK#V$&j)bK6@nRH2!leFd4+>mHg(3p^9%EobatCB?@1%-HWF^Jva?brOi!d@FT8$_ z;*9Nmk%zVzcq6*i5j|>w4wa|}l`2s0C^wskCUo8bMfDwuXdJe&9U}#r$q*skpZE;M zmjVzRD2svc6^a$ZABE;}+YlFoejy4yk5n6kqyqP;1KJ)y0?o1x%ln4apJ^Sw{ta26 zJ`hSj5c7;IS_~sNs2>A&GWd$ZxF4%BDCIN4Z-fxh4Hc3^K%OX-ELv$Gw>X>%q6W04 zgvD? zz#(>z6pmrxVfJBhy z8@9w9NYYV~!^8Hu`T&fu#(_+f ziS5)T*pUD)M4RBlVCYT))g%jfXF6#t^@ziW?QZE!k4@@LU0Pb&H?;V9A@bsRF7n&* zVM(lv*9<;XMe)qC!nv?t(yK$Nv!>rSDtjutO;GCB|LtBG-5jDPBdp*n{!*x@S^L3^ z=`wMSQHzm>X-&gdic%$-fq4*19xX50G0`!DqeNVVUG-dbqp(D^NQ19zGKb@*yk?Ci zs^*9ai$v!|2foItK{j(Njzle78H7X9xOxtY0+fF$gboT+xzgM}S? z0qh+qmdwCa@UrDoNB1;MuStSj)WG+mP==*{YMm=_bWUoIGK0Qtamc(YFnb?|I}mA_WIAIwW3E((_G{H}#pwA{ z*~Ic)Lywcdu5Xn?wOrkT)#dny5$=B1Ae*#fVgY1zM^@D z38CGR6vbYW^6V|ZZv01b9GW1N# zWb|I`s~i=airt9Q&H3X*>`t3~-QKvxdewN9BXm(uY{|swEBh$Nn#b&_vq`XJ&IyJft{Gs*9=XeoVPVAlJ&85k79EUxQlnUSk#EYNKyMYNLCBe_?n*eW8Yqg=TuQ z_=Y{8BcLZh$eNTp`C}g$q9d9PsWWQ|4hg0n=F_`wDoLzKZt_g>cYaGxGRV>R;ds@- zfhw+hwc~x@eDF}G@5k_u1ho~88&&p8XPO%snA72TnAe!6)GgFeROHg%qy}>Mvl%83 zCtN1Tjl7NJjXaHad&^>5unKVLqOD^3dSv=eqsTx0uCsW|4uI_oZVqmWQo=6>d0R%z zez~HhOIG{p_?1klo2Hj$md%Re@)NWZg-rbNM4oQ9-Q=?@x+c10 z8ua}70&4|AEO(?q*e-E$aLAdQd}Ovsn)oce|8rUKC8L>bh`N~LaO+}kTSlv}45PF@ z)h51$@6jXHZ&aCSf~kQ?;KP2oPTNmAE-RO7A`7L-)YzI(E2lZM5@e8@p^$^m;)4~j zHFu)5dmX!(v2NM>lg8zjQ5Adj?{@VyEV1t7-C~2wZZeWsPlo*IVE)I&ChpURinO}N9kOzv7)^dnIL$0S zoEP_U{_l+qy}9`%c)DqtkJffqtD{*dA~VNRi&_<@hrSapt8X?CMrZiuW@fDB@VVMi zFG7C=AtKn3TnJ4sTFih}B<&b^QP76a+wSo_+aC&A#HkGCqBQ+3o2W z@0EMcL)2tqo0ZE(<&~>ukDaflrO0&)b>++2_63i&(<@#=h(ay5?zix#1#5oK6o(!2 zT`qCJxC`=PK~}Hq=iD8h%e7R`3{T~o`ZR$Zb) zV}w1j&V7$0USvk%5QN!9Tzq5ipS-Q_@t2b?%6ANwTH*Y>-es~2v+l_9CX_-U5!yR) zK-t|;KRb{>O%p?5;459vCBP`PAihO>qRTw!pzA^OUnGN~(t^QoMD@?Wl~stkE1)GIMuJsA#ed^&b`D2?`32_Rj+?r$%!I(b%0WH9*cFB}IN?I~!K8iJg%ttGkW;pMIbO-T5I!8&hX6 zg}aTltrNey5Y^ux_#x##)ofH0e*&(Fr@=H|xg#>r~uXwJsY$H&J8-zg}f`2;W*K{&27KblC*?iIziSX%+AaG?jLCX-Sj_Ewf~LE$HVbg%)hk!1@q4u_>~ zLAL*+?!V#HOr7kkUH*V;+FCjbLx%Yq%70b=151$Y&$;~Noc>M(f2)O1fiRLF+rKDE z7-{>YzY+>c6iQA~Ov4@eCYXDgnz}Z3XzAL;Sy1|3AhG$OnKd=5WONc>cOg{{!$}{h?x3jF(aR$J+ka{{3IK zEtSgf$47No(zSn`!vCv#$kx1*G@J-MN6ukuKI>fQjAH)6(mXD{AfDm1*YWzo^LQGB zZuaW49&pr_;g#^8$NT^47#YJt(<02@c0vk&1Y49e*EiiLv;+`|?*Y8#7nw9x*W6#v&&qCi8N5Hgik8_C2vNZf>p zJb?jx(Y{}Xny*F{4wk$Nb;kwD1$mlYs-K(M3NA;?(ri*~8u#-h?z=BX1w2Gh8Z#Zs)0WO_MY$X_G-5k7Ir>36xUaS2<)ELZ=>ML;B~D zS|)z?hXz#we%Hm;@v+~>$~e5B4z>O#0h5VCjd8#I>tzVI!A#*ae_uPot-I?OgUYiE z^xDMEN?GyPEq8pAd*ejBg7bP&oMra=ag?uo8ea6V@iqVn&nuWbl<_4JPG{}G_rw(9k7yaQ#bPReClUzp5Gx*Y<#z*I1?DyuQ8T`;p7Ej@aFe^pR*f4RFW-t;K2p)`ZpE`Q!d{$gMIbTMS^ zv^zRd)^f9W5HG__vy+b!UR+wMb5q|Z#M-p|Rk!jDx}bfxJfBVvH0Oa|2=0e|G@+~U zqo2iPM5Qo|@21ECR$P}@bUzj4Rc5_h6)Y4LWbz-k&5>LDxh5%*fC_!XkvqTFIztv= z+_nzWlbCj+D3-5GGTAhI^eq=j<-_`ysdK;k@Q&)%eAVTDI5H;tj6YDVLV#9j8n=l4 zb^Rbak3;c!h-=3>t?gd3Z{A`*FZm=?Jk;Uk9)Fm3s7W8s?d)<++x(bSdf9)9p}^a7 zxT@%C3)z5|n(gF+ZVUCA`8Crcu#4xzlmw`coRz)KduhorU7#zJeZx}gsCMoWwK9EM zaKyu58?~(xB{g2Kx-`zPL+|+Ny4uLp}V^vd3l&c<3n#}zk zrm{ZyY(u0)Jo0h))yr+0$lB11ydl;b*}dT?{~AZ(%@dqWzCmL zYi4yk8jJ`xg<#@tn|Fm4T5ea z;%IiTwdo0L?ff2>oMLtts?6hz%aoEI@bj-!3C5mfqll?F&agKtZfnb)gd-J@ zZoTrm*jd`he`Iju+|6fM{~#59#e^5@BlEI$9pRc&R9L3l%9#hKt|dE<2ERD>DM%6i zkUdW-_omggZP@OG1N+2AdA@M3d0$#5C~*(?-VYhXBJU#P#6hL4kNMtIHFTOVv*0Bi zme%R7-d3ch$(nZi9?pW^ul=Va3s9AU(n`UQkHZi=5V~Dv!k=&1S4#WcDR86K&zYZg zW}Be=#QeI$_?j0ea8q)*G z$^mI|INp?=4~{WTz4!bM;|dvcx+X|9jcXS!9Dd zapdDviA5!F5Gr^7u3RvOskp%EMktL=>6+7+&;q*eS z351yMrK{57?WD;93WTqV7Ay-gW^w0#l{c&hB6E!LbiE0>;lkH<2it~(U9U*0w7DEg zCjJ-^Ts@C7oNMLA|5>X|R$%&9Sr2RgRLpIngQu6)T1{<9Xf{ak zJT7+)*c;%|gO_vG%jmt3Pa;){ZcBcRqs@KADATd8%i%oo#FYSJ@QVS)@pPN(>|P#U zuFLi1ZhUSb*O|p@B1-=qE6G<^fLP{LF5Pz8$7RdTGZIrH?A9UHrf5e@rX-sP+OPdx z&ku8Lwe4kCM#wNiXYFqq9&?CPrMc;&^)YvIe-s%(_VOR9-cM@(;%@p1-9Sgv-g>(Wkzmzi!=gAJbuS}tf-1J(;7e|oino6SqH-IU|5ye$ly1? z<7t~;FQ>W?EXF*k>pYlnuFfUar|=*EE?@<}^(@4?2UlyDvzutrLCND1yJktXFv!Epm?X*nBKm6G3c1t>+kL8v>yE98LY?LS)!VV3{XoAWe1XmbMqWpv~`@a$lGIM}n_j!IQt0yu!tQ zzSCQ38^9m7SOf0=R3ip;33dx5z+Req$O!tLM;Ro-S#9&VQ{)NlcE_X-~mdBaHVqNI@Yh zfB01MF?De9#c^)wN6Kdc*7>oaNo_gDMEnA>X%2mY-NHy5?QaR9_V2G> zAAbsz^RqSiuKK=usW>8_TaBjMD6Bp>u)!Xj3MNe3+k~HO#|oSdXErQfEPROrWtZ2G zf+zJ?q+2J<6Mj~1wBhZX<7(-}fArkX zBb*hD^S#Qse6nk~o_!(_#D(ubDPwAo7N>CE`DSi*>b3UR7`Nb_<@>OIe|qY@E6^Zq zersCK_pq14iKZRKOF}lHL_o*0>TdjUq+sx%Ry(KfwS9Zu_6CiYVoR_((ZRvIAanKk z#Lb*%#aW$)H#%I|=Rp15ZnQ`2k$>`ouFZ@~SHuF_VpBYZtoKDi)-d^x;p5}lYo-lEye~jh z?^5~|CK&WH*)i*&Ul(a>Pj9^rb=OkCru3bIibRc`HxOmfppMT8b>zVJ8XX%WpA-fG zQCbdG0kq7R)SzMW=CDur=GVPs&%FTEqR2CqjaGBt$7ER>(Y7=_Fo^2=%q=d_aw$&&9%L730#d!RIx!WkwsV_YZw6ocEEJ(;Jt$?7&Gy9|Jm$_;%A10u)HR z2$%@t?pQIM)C3>nol2(5_g1Va9#B?56s27&T=~|E zL8jef?4AsI_dZhgjn?xRI~-pMC;UsZXbI5=6u;fYj1%HlN2mf3+<8di-YQXsOIgc-oF|id*?<_C5&*ReCD1-@z zl|@H`;`9na2;= z?=USAgDSq}p;w%gE0jzb+*BsVEJ#$CZKi!Am(-jq#h&2N%+J?iKAcCE1@zS<_k3im zIK-{BTp;-m+t|<<k#5%K?w@F1l3Rh=mci?>j(vdsD>~4nJDgiPU_d1~CJ5{Mw3K|tbKSPHJc7PaL zq$wK`U9(46ey0@v$9L}y`vg)x0zVlNC2%dr8sm@6a?gzClIDM&%V}ZHQTS(H{)w9vt5tjS<^O7i2c78*; zt6%E63Iw+qKJLVBPLb8F`93;`tFP7ta1FBrFRB{KEG9zi2Oql=+wisc?)DrX1&knR z0T=k2pf43Pr{zA!R(zLyr3ix&hDc_v@_>WFISoS@-pTwisxzfF&3me8F#?bVdM>mC z$*qFwU6)gMBkx8qHWJ)D;1L{H(D`ojhob$os?7E*)Du}EL6_k??l$yPO4a8{UyMtl zYL1mx1MX z5Tq2`z*y9GT`&#VGE0y?{rB>e(;cVs;b z6A-@0zVcPSsLjn4XH%s;e9$Da-D^>ig!3xa0fDxMc$lw^bQtAUD1H+?z8FxISV5U6*iF0X=_;Mm*U#E=G_ zcx5A#mq=Viqq4zL2j5UCGLUy7l}s6Wu6Uicc<`1CU>qgI2eZ!UIVp|Wui3RdBh|EH zLIvWZq%M#a6CJ2uOA`TmFqktu4~iN>a8rMS7)60&lbrB9DO=AF3ooM%w|aA;LWY_+ zdo@Q|P+ZKu{ik~HXQlb8uCKfx+YS^-fC8Z*^9C!@Mk4GH&^Q>`VX>1)4DY^kybB3c zp^~Y*`3tk-ruM-LCaU|MK?WxiX5?9n#pfXGS?OxjGRtN`wUAdsMYg(SN5WYLfWf|B zI-*1)1_*rq(~*7vV#m}m4SzqThz^b*JtR%e0SZTjb9a!>+Es=oZ6mIU>tOiAaSsH? z+NW1!L!2-wb@xfFa*x>-r7XGh-M|L9A$c)3>b=D`m6_j73mJ7<^oCB* zbCLCvkVTkEtG(M5dF4}%^;W;N8tj`Z3W6fCsWyIKxB3F%lYCL~^7I&zi`G>mjh(o9 zTAaHaH{&}sp@!DRBq6avH}lOgl;e0m40B!k+!NKxuQiBV$JZeD(I&brn%yw0hRq6o z)@)crEp@Xc@jK`eQKBWzD$n90K2HEZuNcFM9Y^O3gn<~vwL=~5nscB2AWaW_j!JLA zV31j*8j|AWo~2gZOQSSFVfCSB26q`$&d$wQ%kK8GB&eiE79S34@z;)c$&AHei7~y% zJWvalp$?-h=0==9K3n%xpQuS^4TDGLwy)ZArHWjvFtUfq3U>#3_7_zz)&#}jZ0%$I z;N(qB*7_(+Q!S>O=RXaxKWgzJK-S%@8&k#=B@OQ=V_uikX?UW+OZGS`e^P4}bABZA zc@*u`{%K9)VO5ps@Giq81}j^vp+XpXOcwr&05R=(Fb*iE~`&!#J| zbQfdSAA(Eg%b6jJsDTtc13dJ1ZminQGu|5`52?@R^{Kg`2!QlA~eTxVs?{cG?` z)cXtR!f;VE==|k<|CocMr+at;B}Z*Ii8sd%fVb)*ff3PBO|n3QNpnL+Gr+JHK^zu; z0Q(6VW`6s0ZypVb09 z;%v_YPdO|Bg<2EAWrG(`0ob9@IRRarwE!@-ykOs8T+{yu-*l9s59lGS-}FdIyN?(jCdk{vZeZ1M=X!0h z6tx=~ax*BH6Gaof31kSADHhS)DJQ@0TcBn+qDMJ0%%b~7f-q82kIw{>bWBf+W5bwUMo zTrZV)i7*IjeT>7_)mA=B6Cx94Gk%c%@01Td zn^Kp+8tWRZgbKWW@X>H2GFe%4T`M`0dxH?a{(jb3FHf(~ytaavKwswFznmn|?bVV{ zzHH6Hu&!rgS~`|J>2+`M<27+v=!nz#VVVY551mK+3@r&!TBOL0aK_JeoP*y}F{4z} z3!DTSS1J2G zmW6O>__j_e(fD>K_`v0!c0*hVMN4`#t%lyy4UX`5u{8 z+=1V@&@t#3>1{5cm)@n%K-Ev$U((ONVv~s)HW#8mSHw4z3X@IEyUcxTx~2&rJvARm zO+t`J>DBgNpzO!fKR>E`r&qpKjgI;J9!5Y&A|g6S1spZO_%fO$!>d-ybI871IU=0p&krUT~tp*iI z8ZqY{PvNO>uq)ZX5+u-8OeK$(n@%V-#n^}jB6apQWUh5fe3n>R=cm8cQAUOMZOV`N zT4K(Ve^Cfwr#R-c(?+`dFmEZlGA-?>&OE|xof8OdqUz;GJi3ZzI+TbRnP}npFrmYi z$I797JIM8RkRi1owM5(an@T1l);y-!cn#C#O)-4~zi*dGC|D)9!m$DG4qYHu~PYPl+)!;>}cz5C>8(`+M9I?J>^}zEQPy zgC!~i?3#C|#>7L&07^JKVZhS3^-MlNZ_GQB3Hx$!Rj77&NWv6(H0~fa94;^b6G*YA zUA{#m!&+4zhGC`_RxcQB90gS(g>Kzb^O7XdU%a=RRPZwIjmFM^t=YVr!^I>8}F`C^dHMDgT~I#3=N~e?|op zU1?PPgRoRXLyax zGKLp?@G3H!CnfpZ`8)T$npFY;nHjaX$_%OL_Y`OnH_{<0r6*TefE5en zvWy`qh7-tE(qH53Z^mfbzKHEHz*NN>)SQKn+T0`biE>DHKsJT- zrS2~%*Qhzt)M+#l!rp}!noHvDA))KME-%r&W^TD4dn@wp=nSMF0~b`y{It`uEHsO% z>|OCeWXDb3+e$=nlK0uSVDK#xo0X?8^_}VSn_sJ+fji%W&<0tGDj3bZBRl;C&-`Ei z5PHh*dJCJ;eVdpz>*>f|w;exN@G#SF%`h5K>i3?#pE8^Q#JCL=H%wFy>}vs&lGXL% zMKH*0!9DXJT}1F2kJOG`@FQEpvkjnvu=TUm&1<>I_^yo@r%Y-*C>iXeWa z9V|?%>q@Q+=4M2uVym8FN0v0>U*B<2vzfE&ZElqE_>PKU-2jKbg=g_xyQEk4{}SLZ z^rV2Y`z&(jUtHd*!&=RxgRLA_eyvp^c$2 z{0SVVz%1ClsTy2N@#2YT?kE*_AH5`LBU@y}ehyyj_$+1-){ZNNt0=6U&>qaxMZcrE zO{SPfs@P}>dx;DUR8&dgL`4oNLb^7#9+y7ASgU}TtG`*fyx1)dbG2!izb4jKWXICK z!3(bx58iNWhen9zGcQvr$mbqi8jPp(x>)=A8cU^3Xqo#nHAh^)TBL7 zQhd$kg#nJNaoQW@aYEP&dnn1}cnXxGpl3QxkZn*|mDS z$fQY+MSH!Ce+4Jzq;7OU*t~=|C7liW3DY z5cQ@r*EyF-GiGVOkJQ|qO({58(qW=+$+k*!^3>g8vqcyxlugmX^YXUE%IXKNNNv&BS6vouku|;M`Go*nMBk@h{y^)ijlXE{LXASg9fK zg43=^VkrMiem_a~dqdpRqPT@#=;M|f2N|9R21Ut1yjOk^=xP6cfi`Z~b%=;WSzvV$KGZ9*F%MY-!Au^-jcIPg6YQ;^Vb(YmeD>v15~WPdjlO#biczMeb}*_hpTjofU2P zbDz=)`|q{u-Mb<+x25L8LvW1&r$Z&tQyiQ6^>Zm-jQoM`%@6Y|_uYoQ<~J}kk`e1Q zGTm*hR?cz*Or_aqV>#Y7Ut|?BT?*i-%aD1P*t!&)BW%E)V)Ro07^;ji3mxBU2tW8< zq=lc?ow!ZZ<=O|#*c}`+eexuF^AHlZx=GfP zEDQCLEMHo1thBV*P>t#-kiCN|Gf0&SUC-9%EQoygqq-3;T#i~N9s!!>{vcENk#Yq^_s18wB*|kG(qpa;s4y3p&^lHdYZuh;~CyI=cSU|;W>ut;0SDD zq)9H(RP`>dnE{&-f`ZlvOKki`_} zgIe3LoGIQM$U&mSGMkoYi|i8n5VVN$2+y#LA$(0V;XERr+EO^6gF>k&GPf}1y~EjL zwGN5}*WiN{^d}B@c1C<~76-g!h*D0{~nB=535b%vg@@LSS z#eS^4bt-I1=-_;|GPGhy9OC^~Pt7eXv>^#ZRzs-L)`tTR=TRK&45v}PdzMZ#Jz{ZC zT$1I}4mA87x-?esS5C!Ts%#edApspxoRExub0g<3bY zt#e|y2UlNTZru_B#n@7rON!T$t;7?GF~iu&Im{a)Q@Tzg!fd-iHA@24tHi9}wdy9001v{<+=*P44PX4u z44UC_DsiwV%sv6U8M_Ae2NVcX-Zt3Pp7QwdUf&c9PSv733u=fOCx|wc!)7o065FMy z49k1@^*(4Mbom(ULWlhGs(8OENR1>aPa{4bw{P!i1?a0heYaG8G!e)YD)f9c)g+?2 zH@;Z<2y9q@cmOL)>sI;kh5Jz%#hhn3Zs{L!FrD6rqsZE_8}sTNiUZ((^-uF-=8*&k z#;2BP8|z5jD$N>Q*auL_E~M8%0)Dur0@e5YWCAK5L~vxyu{mO8ppC%bu(OK&Mi+n- z5$}M8Azd+lhC>*JGM?K3{u}e1@c)n_Q!vmsBag?BNIzY`%G14;iPv$Bn{Vw(^_{F= zcQA#DwuP2PDx?pqlI#l5Y){)el&|hZT>3<28h$dRW{5RL+F<>Pg-}E&VYVIYY=_XXJp*D;Q$_=@cI8e~%jN6v6vQNSThgKi|A zmp4K*RIA)@3L`6;G2zc;1E&$L6~p>tnl@R0p742uvNO5TSFcf9=uV|-f}C`Q0NwHt zA#s%n;?*N2L&C&{>2efBi+8#V3BYcMRn_(7|*?+f=(rmg((6R`S(+Bin#yYRzLO z_SjPd8UL5QyAb55>;{vw#35rNDaFS-NGgRs0e$0A)M0`J9BGm`688Q%FqTpkETNkD zd}JP{S~7kKHlQv|HqP#*VeiDl|}-7LN!Q)kYc4l`r1Lu+XXa+2`c?BVj>+vB{F zwV>n@@?ZVQJ;{UJNiN@mcdm?MwwsA}?u7OllN@6hlMs(I^pQ`3gUkPexG4M!Vn4ci zoDzUnuIJW1BOd}?BOkG;&0v3006$<&Qiqo8?Tlq*WlTEcsmmD7Q7>4YBMqVJHHiVp z=8vkrnI*K1a4(r8>p9Bx@=*ih_&Dh@r>LQFGltD{17Wm*jEYIcut-2#dpg&>A7MMJ zfC)vB-=8HM#YlB361O3-SF+^a-^??=i6o@)!4mvx21Tzp^pP5O8Y<0lXV`Zlu5eOe zEK?*xf;TG{POpZBMlrcn(imzK^TfDVp@|4lQhHgNg8(zaHJ4?FzH8=BIEzQkm!tP? zIeb}2DwC3il}2#A=yLTtO??%~Wy`NVH!t-Ep&Imz8D55QCqh#4iy0&d4i&>?^!gbF;1@W&y7 zwDjVJW2s_o+CvsA5_+((RI>syq%Io51|kQlag$r}TEQr4>7u|6_hH^Xf^N{5UCo$0 zVl9pZRqtA5w!Hgj>MkU*J2Zz|B#J7Q4v8f-L2RbWnm4nR^v*y(aC~3ZnS?0uoLh8G z<<(o1XL7B>=#FZ!9o*635PIw_M@&nhP!2T72H}T^I6SzK73WK%aV{%xHoA~?C7$s! zvlLc^p`OW+2}*A16dolw^A+&QWy#j^&~ib`wDbG6^|s~yA%H`T+_7QAOV3A!Xy>k! zFXic=MA!IUdcQTR{k>_;`g_^CPybFd3iuWUEJwfI55KV$}9j0Q#-Ae zgt&0l*}QwckScylVWYHcLRG(oE}l~0ra48GUUKmE!Mcgxw1fz62X6OeT^}W%qtl-X z89w-pwOJJ4*bx?M624b0yZ=);y{&gIp=7%G`D|S)m-+BIOhj8E#%IYG*OoB30K@l+ zqy!=iloo%|dvDoK$d}#%dp1=%`3OQGNtKWF*5ePSdB=jRov?z2qP?4zFGfXer_FNS*3y|P4cPD_TJ9l*R73=>?$Dtg^&#dO6I zuxuA>?yxtTZPT3sVy}_T*ts5cNmwL+5yu~F z`4s<_b(2OfZeO!uSC3qed16kEx{*8TT$z7Am))4@11f;a6dZ{wA5V*fhYuh|pky|0 z2lVn@LmTt@3RoI#gla0qCmANxcGpW}^+^%ecUgo|4j9n%4)mw|CLNYb`3cCu@O51M zKy!fH%vILo*3}3}Y$B+(uGiDIDy_NLi{=FEq^PG5TeJZTf|+21Uer2?@H>oi8GTqo zZ+$pnQzRr!%jmCLOPS0wz(ur_w$-g_WLGm9hCwd4m+XPuo2}a{b_1^jeHh}?l!^2- zzqLKKlbX!S7*LnbdYziCyi?{P2>gZy$Gl6cXy zA%sNCRaU8L7k^Lh;Q#7C;Fh*e_;XrhkjXSnIdOb56#*T)vNg(dy>&m8ONs5pwh>RF z2s%CYN^EIIxqG=~KR<1UcmG?N(xO7S?-*e&U`_w^VQ%+2+WvD}qRN3>iy?~B6Pfc$ z>Q^ruUoG7Eq7tm-`)C2m&EmhrV9nrRjvBa^&oo!6*6%+h>O#`rIUUj6IN!keZ38h2 ztu19JF-8YAW7mR^j=}|0X;?toh0`N-pS+i6*FWt-{QShpa42X56Cn0nbIuxE~ zx5T7xSCUdNQ$DvVJda1_B1bcQ`IY3h_u-qda%JPz*7cY`L1q$qtCMlZ46Em4StN&KJZaJ z)tTG2$WIk#j8v-~^U-BuxM+fgu02lP?qMo`A()beNza}@M6)YM*f@bMp;h@%&7+6u zo+`KbsB);c27NMz)gCc2PhK9xPw{=SLG4`V&QMHlK|S5L-uD*hw+2bNiu;wVO7gG_ zv5nSj4EAraZO3aR^?I>_s|>TSo{1C?MxP&h*nHV{xWqp$Vh&eTD^`;er2kCAAr6^) zWJh%KrEl&`YT5N5@q)Ql|%neio!n#N^cw=w)i0 zi*^Dty8jB74kwu!$x=9UA<;`)e5z^|&jpPOP1bn$riXP>ID; z`DS(Yy=#Xre$W76ciD3@%9BoOcC&_xQG|W3C~S_d=|0XA?Iwcnp_wQUSmpDCL@{SU zZKi8tnGn78cR&c8F~f7fIZnsBON_&34f_n=t?$QqT5WW3f80a{Tlh2RAQk`~kja;=WDerZpeUrD#cP*FV_8Ama8#S|j!FR|fwqV#~xJZe7S$}W7 zoF{Mgy!qJj7qX6SpB94xue?obX0I!m;#(|1Q0Cj7$`I;AK)Tmf-#yfuR24V;5qonJ zB;Pct809_Q+LB-q^h&J-tufeR4B^+#}cF_Py?yw>Q)t5d0HUlbp^n4Z^|gFwsZecjfT8s*`Xk^?F~+Pj zNMFqjKo}OFkmQ&Peru)Qo|@1Q&i5UFymJXjci`$HY|b9)x+1>&IJ+C!`Jn9tYmcs| z%lflvr|4EW;2gV{J9teKSFXZ6Z$;HMqh?m5U=!mi4Zmei%Hy@q(^6v=2r+x}!~J*F zGcOXK*gJDH?6JCxNkes=gVDQ3&;CP6-3F}RTjeEv7#wn*6{Yv}3@tir;Gg|55hVaZyG6+BYE5 zodZZK9WyjYNJ}>i-6bvE-6ayz!ca=bAR*nt020zjNl8h!J{!+{o^zji-uvZG=CfyZ zthM%9zw7#5OOD36qUyUw>>n`VSNgK$K=KpPQU#7FmgSV|EGt6C;nn;?jVMb@v2OPLdRlwg3Q5Zj2eyR9 z_-$fmFAMsqMh!$_3-kB!lf|p*pJJA*y8i7Pm*u58&z5RuD}hq_(LM{#PvvIrz+I)t z>H#-MLKj|-NDKKlCvKe^vB2>9Z-ud-&iI)s&tV}fb9Bh!5dWM+uI=UXD}-)J*CjzH{z2bl?qaOM(s@I(q;1FZ^WGaq z$7_;E*?5j&_V-G9gboSA{uBK4a8RiL3bv?d)m&roM&%JOUCW#35z!x3ImoUu@k?Tw z2U<@3l$u19U$N?t$l5sIz*N)?AZCJBoR{D^q9$|+q5h?U5De{IuPT!w6V|UqcnRhJ z)2r=3^bPyJS6kpQNI9OBb90rFe{13IY`U*sq0NLyZb~fUxFV@agTD?f+?VO_7XbJ9`|hlgGJd6X2f7hZMyGcesrQ z$Vw`Wvi}Lz)4~M6&QeXMmdby+e4vhB6ZinEG|}U{+4W!l1?&SGDb8D}e{XaD`?zj#V1a=-y8)imT||4e%Q?+?$6iO#HWS^0x?aM8bbN-r6K177MS z|2G!-f4K}WF+uHDXQt`;&WV5Vl!^gZ*SWZ2F!G4s3<4D(lyfi}_g((Ui1PnBB>>sxfK%=MbX)tMo6bMR z=KuIv8x){*|Nra`@v6GJWX2wo_4$=*G+zS94eSb2INky3^nd?NOTw$8U|P^^SLgrz zEEH3EwHuu_x3(=e1$gvR#Gwz~`#=dqhF2i{Yovdzy&*G#jUKL)t3!49UwgV;7-zCT z6YU@n{(s%S|F|*0`GUAm#G%g3S0bMOc2XZgx&Sz0Yu_B-AL`YMD`*9HG?gMjcoq*A z4pKn{U`=_en&A7r(;j0$X?Va3pJzYz{P=$_{U3K96phptt0K6}_W=9VGmEZa&J!td zq&$$A^P_?*qFj}f(;$}G04 za2+P5a&{E_$Nyr_^p8m3{)(L0Fhdv9Ie?#7nf!i0ujf5P90TVzPzyL)cVGaa>GX~h z4$$R*M>y{QKt=S-ulmF@E<`>ti!jIq4p779wz9j zMXyfEa0o-+b)1#VFSWQg$dc(>DRVstCY*4p@R(rWdcn%T1FeWXe5=Hj#o0KmxeRUk z?&rX1^HAZ<B-uE+&F`B9h!BlREhB_-40)kVR(o zt2F+o$yE>e){z%bGz^V|M8@8(!C$;UIEiloh=bAvKw6f}cz5rMUaf}nl6@_HCS}*O z7De^bcJ~~hQpWz4n-wu?g3c?HdXLwC_2Q3bm7^PFd%ugXt8bm| z_+audZwBh>^*}A>GYJu@%mbDAJKy*CXGIMc?sFXzj!$zI^A#rN4wZQ z%1NG{k(=x%fB>-?_y2xc{}*Lc1Avj%FNn-vt6F@YU_QqHxyN@4I4dNo>N4Zpu{Rn~ zZ&$7c1nU7puM?h>iJpm1$FW-$&VPUU{?DCbmURZj<>+b%+Hb(c3pvcAJ(EY;{Q59m z!S?}h1)B%t>2u1Q^n)pMd4(l)31|eq{`Cy@V`e=606ZKXX?*qtnt1*L=fuXLOR`Fe_Dh=at0dhgVtsqc%n3;( z`fqzCm#u9tXn+5TW{&&<2P7%)!Rb_0k&k3T@Q)Aet3^|?Du%vx!P>E6?L2c4kS01U zgKp(rP%|aW9HlV80Lp=%CfBt<^q3F>?cNYzS0`(=Hv6&IE8iS++#ZU>V~1bfosN$` zC?M0CNI$dex<`tVMA-B|H}m5`82~Iy%Z>rL(AdZS$!IB^_Q!9!h$j7@WjlWpS;Pe@ z7zmJ5!|B0MP6`tPLKCN!iY6BP3F*|(j-$Y%5vW#H9AOvHG4MrR$0K7}nWqu}Ak}~$ zxFgM2v#)zYC}slZZ&Ln|t4b@MLfFGlJ{yEKFssO3l@<+56qVc`XWk8x{C25nzo0DY z%L>ABB12m-kEYHjT(y6d)b&7Pw_h~Ya4PQrij4OKAOs0C#a#h>qYh{QpP3dJwFYp+ zdz%oXoe^B+$PtG!?R8Du!D3l;(i?+0zP#(a+uR4>*!biC2^5U3BWsCAb$Y#7Ank(?W1Fdyx5MzJn0&tIiOu6ktPsCy3+u;7ZUte7k zAy`0cN;@`z0Z;6rbf`=*41IIRn}3|3K)CRw6}NQd**hc6Jz`);9jWfZ8<3Df;(*uI zGq!)SkEZqlr9MSO*)0ohl?4A#Ho`p6HSyidkD*&42m}z3sRMZDdXOE!YLC|%P?Q!B zMbd-7YQDo-Y?ud8xT5!H>@pm6=6#=@!CBZYWs-^69?f_?AjR(8=UVS?rj1yv4~z=6 zjuaOIyRl8)0$)HN&>Y#ba*2iTKx65A5q1$$~j1H!vi| zdpxhIf$O7^uvpPK9zL7Soq3`Bb+At2J->r)^-v^wWU89DZ`f-u0Z)PgwSqpJZuGjZ z)p&k*4nQ}Mp(h~yQkz>de46*+M3@$M#n|8h?_!V*7KIMw{ws};lU4BYvNnL zc(vJF0CWkL0Wqp{bTAR*DB5*p^AsvqVq=8I2o5B8VQCOYpl9N1eSqIvl8q7n8IXJB zCD={POX-I`h~(?3&LKAdSiMjaU%2lV3jSP|Yk(vyBB020f?;ztzi67;QoI!bDB;ti zZdrkB!1=ZQiEuq`6N{{7Dt7LNVg-#Pbx#Gr&$DmjVk|taw#OG*4OybJhOR6R2tn-T z0mPTvqe_JkVU}n4GqFpr^X8jT=p$?eP}>9AUC%#j#OuNh&q@yX!AOzOGPRrA|2-yQ z%kZay)N{yMykgv<)&&W{M)w112Q$;Up}4=xcBuZ+8OlgPkPnNI^p6BR@?E(Q{_MNX zdnU1j8w_y1qv`YnSW{$mcc|_p=5*MHHg+4oY^g#CC6Q<-^SS&8X~4=w(IH8^FsuB} z@-;z542*!v4y3V2IraX^Iwz1OWC|592WU##+kvfB&82Zd=7DGHGVgaMn`-G_h?cF9 zcV5Z*Y#2Vg`d>W9Xafq&yG$N8yJg--72id#zo;FeRXLQD#Q^eem2;pI1@cmCfkI*d zT2DQe-W%4!QI`0Ap!~^w3ovzAXjvznZp)-u-@vX9Fr78+{f>OYw&=F-_2onSz?7<8 z^kd^YXK@l63EfCQ2{Zn^e4GHglN|Ze2vNl`c=|I-Ad!e9!vX^qWv?S-CoIoOQ++UP zBeeH;R^tKhYY4{^Vd35a+~zxX2`@O>l~bd;ygP4~4?EDvHK&ybEwQ%{We%z(~+YSbL(eqvGPH<@NJpnGK@- z??S!HiY{c9d`od^TCQvF;-hgeS36@Ul(HRMg&Ygc1En9+%7B+p{Kr zWR-|A@gHJAXxhs61mMRLd}MX>G-RpQtKs-#ob*FV;<+uR4>KUkB;lwo;A)%@yok9QJU4dV@#|qR2TfdH`g^4=RBZvxYVR;gA2WxlX)?OUt$%Y>cjFK{0c zDMYs_E!UXoKikuY5PN4DjsGB^9|Tj>U>vpU5)8M6U>_g)J}h#FWxYT7jAD;JOFL)b^T z-9~k8?AfQLcFrTqhrE&#uke16d#ZsT3C-XN5!Ev#?v65iUNmFxWzUB|1v1m~HuT$v zij^-2^?5?HTfPC1qjPc*XOcu8qJwyH`slS>P@s@uR{9B9qoxOaY6+U7zy2jkV!uT$_!%o zp;I&0-dJ}OJ2sm;R;c~LU6rRc!{v!PH1!5L*ploC5GA77EUs|;erILndd$22VY+La zOkP5OXZ%PTi(6Qg48~4*@Ou z?-a1exp^&$!WmQREkDh;@OX6$pTMj>cF8U{N!@$gZ>Hh3Ea45WKmPC#NOQ(y(qnQZ zEwK)5uj(O_BK;OUOtiAwD)IyGeVVvK>AA>^4^?b3@@`|4SWMa8C)Vm&&#wcuwl#34@KClPEeJ&T>yQ1h=0>tv zMTn>0qmxCy=3f~Zc74Oo;@K}McLS_1Zrz`8OcwsOYnpz(_fWLj-c0yopFGwu2)u=t z^(qIa&M`LFZ#@ZZf7QP$!Ecbrj_d14^8`C3iT5r<`94O>9RbMvd$winSV3u_i&Q|q z^Xyo$L4+`OK|==#7Nnm3j1vjp(Q6k?sjV*MqFYeOdfi{J*Ci5&>%E0|gy05dzJD^$ zT}`^e{$$qZzn7AA$OPO50+-H(A67Ns{U+Xb5WV^Ivs%N9DIg8Zto&grluT(k!QGU> zkzn@2^&;-Wdw(VP{SQszLc(|h4GEi1J$3U%PZ$Kudx;j@N(rc{(}qlYS|BOc9n;~O7mB8rNxtuuSvDcW-9f4ZzhWKA~}NtXv1O|_Q#(ewL#8{ z>RGs~ZBu6ADMq#obKHNK6@f;OPoq_ykJoi1M5xDHu@chmza%#zd|3+bBT}+@FiZ-% zv`2p&r9D4+kiAUz_lynoG8r5{zW`0@QLPnmFX?0$FUjjmmG z{<-ISbtxGCwHIF^z=(2HB{-A<_dC%fVTzx13VxlNg?sL#9FXnS zGM__?Qg2HG8@~t@zSa_SEMV*gD`hDi2d4TD=wcq&5zCT{gip#7)=kKKs1%R}3FMu* zp&Ee4cJ{1SAVWeL+DTUl9eAfWHjP`m`+`RtQ6>HyL-a-4TRi#(h#FI+wT@nv?zSh8IjPQHeV25^}{`A_u5`kMDo@TB@1Xh zg%{B};6y8cs(67RsSB-?)f3Bd{~?l$(WbK_{hU@vGGLYk>mZYuLON@lFsU09<=b;7 z#1>%@xxnXcMaWOV+=aBo>Ja_%t~7XR%if!E+#-|dfWK7hvZG44ons})@<|Wo4OZX6 zhnIGPeo$?A6txFuF<%QTMtXTFn$f;e6dYiOBALSDCz0fsoatnGCuRvY)YOqQzyPza&yrKCk&iIH zn_wo$COvrMGk60YW8Gi5A~sR1IV1%N-&XP|^>)U3d`;z5X4j*4Uz!TPYRbSL8GWbs zN$8`@Z08O`ABgp+i4MtV z!c{cXo;R=N{UZ+>BXo9+vdpfz*nx;%u7WzFZ82zyz9zL}IuOi=VCWF4>XDYe{cc6P zEwV8w{A`PK0YBJmgc7@?CN0x_hk2UcUUp5w6KJ-Ab-)sFd$>9-xz=Qks8rcbeqp-o z#;r9&+b_KO(cVSl+zjFOFK=}>Sz0H*Pl=h~$S;P{GQeo32^UKIERANdh3Q1 zgLaISby@!Q(QXK9vHqq|+yi+TLxiw6hYB44>>+fL_`!0SPiyk9&`Nghwwr@YC|Fk4$XH-jQMo(B4DfW@TgtQR34ad zzp0gIJ;hgd<4v?Eo)T2vq}P_uqB87BoOzI6g})zg*bqb^AY;Lxs=eq@YtFoM9Qyi_ zgW)F`1I^0V7TG{{C9D1qb!Pz!9Sm&RVdT(9yRMuJV@gKc82fW+T^N$YI0sS-w8cE7 z_O-{eOz&zjVyb~vIM-nswL>k#mP@wo@`~N1f>~LcJ=GcRjUu76l&^aA!vdS#@sWS# zH#o&Pr$86R(-F`!u#VZl%N=>+-luD~6Eh^dpu#?Ij7t)kMOx}nR7=b^iau}W`Y%kD z^~_HYl9>C`CidP$Yz?6nj}io&D83yyz?sj@tLs#FnEJh!$erls_hmw0+w{$BcOJOHro z+^aZ=Uwq^H^W|!JAlF3uu-wuJ?iw|pPo%78j>Ze!V~BLH=2hD5dng@8DC!FlDQ2-^IE& zOv=oWTuLJx(!>t^^$ka;Yu0xa{RbKwYqx}Cg|YJwk`?$5>jCISx`m`b@y!@Hz_C=ieU z>6Bh?Umb7WOlw6g^wRVZ6`|B6+tVN_pRY5ejNjJSOIF6)RL}~I7}%aC8y^MoqX5ba4smE5TWl}FKCUED;7KZ4 zM1>$3#DL^i^{5KpA84AUAb6C;^eOyo!cImBYCYpmhHZdj zY5&EhgSM`@^w5ohk^<(~rNw!`@->vO9Z2&?RG@Jn>L}YOu$Yv3jv1yAs_Ot3dNHCn zquT6fRm3Pclc|h$CD|bokAWDHCqqr65VUOm&dQh>77_k|cS-Lp z?!o2Duv>USM6OcDGFLh_u|OneZB20|Oj&*A!q=u#llG{TFOa-#Ub%!aq`5Cu9lMbB zcq5Y`o~pa4N)bc=P96 z6!EE(d?&HDC|kQuJdv56E=w$k#9lM_q|7dY|Lbe;$2~^S2^bFur@DQW>Si&wGQ%B+ zdOb;FdzVZ$VrNz%R=7%Uo;E2{FerpJQ99?Nc$;er7IvkOF_jPLTS|9cSOhWKF}{AD z!8X+;Dy`nXo+e>Q63t4p@!cvxQrvT z(aN5L3>h`KM9fbpK7I@`f=PmH)WIwa!>oFO<=Y@UG!=uHtDrZxl7pCA^aH$GOk<{L zJQ$wIw=838(jQSd%$jvdpx&~|KgxG;c%QiA1*QQ85)HjOdK`JX5dW91{TnZ=s&N{W zAx<-IdXn5$Pe!GQu#+6Y?){z$3pW4&pie-hovN%_6+Ls zGDYpk&$v!;k}}H`Bb2eO)HYyHIz02zZ@g`gGFv<*oeQOw!Fv~LJiR5P1p_;Fhd%Um z!PD+5rdRbzMam1rDKvXaMakj@3fsfD(3fwxEm@jR5*cPr87|l>T^db(WQH}9>okkZ zLglBQZR*@C@n*zB|Jc`z@NQ|el=bz*dgWn3pfwJ-NK-k&qIvjp>~iCx!!?QQPK2Qh zx}RQ$e!0}}8kYXtZNW`y$8Q`yP@hVBYZxdvEZ>}lM!pr$_NEU)iIBmtFk6>Sz}zqL zBUCK=8wj{5&+0?}!=h~)KL{%$5E@;P?_VMam~NXe)^~{)7zcR@90!hx2!zhpn`*av zHcJM==FkWj8jcbyX{%?~`d`3rq0HC4W5I6t^3)eFk-aX-TS}|~O4DCV6UkRLtX476 zU%AI*I&6)&+_9@((+M36=6vkc(`;?+aam11&N${D6J+@)!`>(0!#k`u%VupG7>j~* z%hATKFqe2Dc!2Dp;B#fc^|41<=etU^+i$M*ZhnPDx4#mxCjr#VM4Nd42V+Fam<$Z= z>vxT%Ol_uSVIZrv2W)nxj zE;m;@JRCuD+zu2*2En}XpbSS!{iOk(ihyR>Z>5R#4KMcPi^Hu=NahH)0Ylt4zp~|B zGt}ZVhbX($41R-$;6%L^wwnbxK<-8-F3R7PK&2-#{74Uz{O|*P_qs76!5i&rL#s=$3az%_E>%aQ4?2!uvlG|QaK#j1wN#X;u z5*d5g1(qDy{4w{h&_Ia0ZVXiP%t(uwUz{I5Q-d@RB?jRHa(#1z6ornjqh%3gK;)75 z#0_H-rmXeqqE7U&Si++%mMYx!&tF>oQE~V(x z%!a0(Ct6?kypTP993_qt*PLW=@QC=P2b&vloMK_1Z=jOT%d`(DfWoIlp!!BsBRaa&)_UWagsM2yuV;vc+U2$lDk_fwc2+m}> z0NImX@OYXT#sYFjaLyrXqA0gk7s1RTzEzlUaI!*;f*%sYihFhNX6cB90paN;h22+kJwLFBXrb z4Ws}cU{#Yuu{$Z+I`(fnEh$}%{MKCglG&e)1XHDBMca}P`2%!fHtK2&`lq!Uf==v* zrty`|n1UFPKlQ(*Qc(ISE`DgZMSMyqNWasdVO!6`dFx{6_B1oe|3{{mw$IOKDn$pP zxfC=fx{G%{V}eKa;|85?yo@?e@`FSxiso?W`QjXQ@64}i4nND#t0@=^H-udBW{TlfHsD;v-DSbxu~XC^PxROF4q@I&||5nNi(K zyH~v*W=n-S9QJ68%-Kr%o{syzRJR%{Ub{+sOrV<{p=B(`ghZD5(UnC7-N_WwangI& zg{-IfE@V!-F0`8HU4IiO1jDCRXkz_2m(>S+dm|WsUsM^crb%)CI@7ZSt^=K%+q3qF zrZh2Y9)gTSJg&8_oFfJP#0?5eXfIh~3*Y#s;ELeE8(3canTaw=zWf%p@*~V^U-G@g z-`oy-0?$%HrJ;5_HwGR`QC-L?5EY}zeVMw^_@zDW+ol0ZNycJJgV z1%6{}fO70t8fYvCSb{NYuM_E>K1)m#9jqeCzG66k_rdeywV^p0H8Tr&j$C4$VzL{W zlQpPbHX$%lsV2d+eZZtr*ori7U{f&6zt+^SZ44PL#;Bu@f&6>J>#Jt4uYgnItF3mMJyQYa8jAjGhWohMq`6 z6AA>MeZw9{r(j+e451I}HNipf{rPzHxe9_O8Nc+hTe%;G8uq2M9e;xgr{$$nWu#Et z3+*3q8b_1t2({mQ(K}+N94p~pW%mTz_dNSWO5a7|1hN{?mD-!LO68PMkMz9Q5H*jq zq~!i>({3~^XaQOl)E|^Br1D>b2~!vmlGUzE8N6>JWW#X3n3MHqy>RuxwU^pwhtFD# zY5Ymr{yB`TnvJiBa^lkyKoz^fCgE_#BdMG)bpg zW_|mj<(m~}e}}qED_mpC1uV5nlin_Lt8vis(q47fwdymT> z2*G-*#JG@OC~+8jTIPNJB#C|WmmDJC8h)%2g$Ae_6Ct|YGf1b zAAy_@$+$=iWo$c#(InsEjfy`}ze|kgGjDPW8UpeBaOA1>ICi?9t#%Cp6oI&*kI7iz z!Z#?o1z@d-L)lZZC_T{zDNxC5jJ~6iee>?G&xsu(J3=Yz@;M5PBU50fKczKYe3o~G z+%Lb5FhM=>i!hl?6jR(Nj5$iy&I~sqgYZRE3Di!7?Yna$G)PE&)8tdx=V}Z44GMSK zo>rQ<-Y<;zyL9?iC;+#FrL;&`M|tZ?^)ey!qk4?@1TMv)k6GFPMDkdEZP>eqWHq@F zW#$GJA&4P;q_$8! z(3Hj;!KuB7D%geBML`3tRP1oY?$++evY#-0$Ktydz;Zy6eBXPiEXM1q*!5Q|%SUzm zdS%H;LQ1}Vqwbq#tYM}#kI`#DRnhbTNt3K;%>BYYH(viKU05hSF=cnKwgsDF=Pan= z*GF~j@%U<$88?k%!u~2dPLnipp`s7n9l|rd^Ec-ihR&>tr85mev;)`d2IgO2Tq;5r zr*j<`M0mL!5FD9zHT-e1#4Q(XDK#%Fg1uVp(kb&_4vWOTjIt!7UsGg z!Jx%-@ezhwJo!Gx!K!b-AM?#OFBT;@#s>oz>zu|fI}X!d07sB}6jLC&MIkItWcKFQQkT`N-fgKn_oCw1()i16h~nS@B^C{?Lh z%zZlC3vx&gn76XLA8S^nF5=H?t*LlBCKFZIzMjwCh*G5Lr(somZcuclSTy_`Q?)!o zCzCA@D-@!ufboW6kI_CUemwho5n)mZar0Wclr028LkC^+p7wLL%q>7b+1BgTXZX)J z53i+%5PoP53Bap|4Ak0zHJ6~l_EV9)^DLNKEa@=%gm-$SyO+7^}Mno4OzkT zKq#rV&eXy9>i{KRklK^r4fkd2;Cq^xbO^eVYh@HO+j#2=tnL}7>HhPdEB2Y0dJ+gs z!>4D`%?XhVr$TX4aC0AR45E?{Y1&m%#Q1=oNe9Zk0_Q;j^a+L zPZK<8P$k}+(>Z`$Y zbpj^`CFprUt7TX1z&1RnE7L2Uz0;!_rmD|=M%BCFSF4=zY}EVBiUx7un=1&OyNHy| z7_NeG-o*F1>OnxcY?ln-?s?vZ?^>c(t1C?((Qqi^lt5hkc2Wl>#me=Cu7tB1try02C>=sRHaRR9p%_wjfAD_eAp-1^(>e$GDRd5bp{$n>{D1HyQc zC7gn1txCwRnLJ0-``)uEGH#_*dt3ULk2RzT68G+kmsZ&7RQq_p0JelE5HI#YJm2q* zGdgEO6zE+f0uCqW;p6z@s5X7m%LX}WK8b%z^E#6T9IMd;aSK=XFXE4~VnB$BX61zA z=H#4)v%FyZsE`O3*}6u$BxR!>*;yss}1g&~;Y?KYM zDPJnfiG?pYU3_cZkTJ;ka+6qL1d>nC0n2wQ=eU7tWNmwE?PmwtXVL0s1p#r(uINs~ zW(zG-rhfm$P{e1(F`X_&f^J+y#3vvm8N;y_Nm1ddWV~$ns5yn33VS4i+InsA%4;Af zq7j33{RzNu&$*pP>zL{2eLO~_GsI5{3@_CH3^9%P(mW7Ri<2$p@Ab)KaF{?86islJ3%I}_ikBS+7uhqC zf<+n53zQpn|-mZuCkk`C=YRnvmu`3>nSk`{Vm+bNW!!96&D7MD3Q6krawVtzX&;vWC%`RwFdYo1jO(YG zaG8YhobOF7Xif$hlIy(H3_CXaiRVS|IjwaIsx{xZk3Gr*={M6tL(qO2R!&;?xGUmb zHpU*@0igkb0o#TAF_IFM(ru$AjigdQE^lQ)tidwsHEmEs%kuqRi3=3rM5@bcZ&7L; z1s){7plZwd-ExK}`6qu_-+j$X7z;hN-+-Wo7h}^>-@i=g%8$fK z52Dge_yQ@smQKupj%RdIB{#Dh<1`M)nn8u{9On7^yVx@~2by&wxyO8ZHmbYXBUpd6 zO>G^KC7P1JS38MDYy${2Gl5TkGI&}Nti)3!7m%v__ShI_V#?2R190lWofg9uT!A^d zU^HUx(O~7(AMzgWiaIEOChdnwY&q9@dEAx&SdXfl&vbj``$Kuq6u;pJ6Gur11QRh> zY8Y+F)6#QnP@ao^n3VZekIVjq>Lut7zGiao0u5{&7D@?vPIYmH!;UJm+no8J%^f^C zfDUlnRHAO!uO#_)?-V2xMc2*Pu33Xjeg{eC<^UPBF;?9psl@zv~ zqTK3DDRz&1*ISIRR=oVHM4DKFjnVU_a+2IC#q^1Jba~&q zd%gXjTv(piNZ>D6#as787(nUMoHp63*YN;XU_kQVJoM}_>tpcmF8D?=KU9DWW37C|ezbZ;AT=%Dh!(T?wF>8t@(|G$o zlwAVyRvg;9lAHBb1<8sTwrWiF#3SQp?Tm*zn4Oe*HO;7IfGLaNx7%j5s`{n@whV!k z6FZRm?sM?3se8+s`Yxr|xMqwh!ms$@KNLdXyMjR0S31@#w^bk8wh?)f=P ziX_%&MS%anA(xSfo4g*Y_|GwQ8hNN{U-fJ&)$foi(tvHiSoY4%*+~bM*mn^$4=24S<6h%Hw)e^OAu z7SAtRfc9jJ>RBC@zJapJjw*}Il1A|XyIW_k`H|NY<2SUa#M!15 zAZG0(H5}ORt2Ddr8542SV`pkLch9H9;Z!Ra$w8rjvj;=tI7Y`c8 zmWW0mL%B2??h-qovPOOSkBwyn`BsQv(41-lOzR_F0l%NOQicS{oW7HC2^m#H% zW$;L9O_K_YU&$!oy=Ze$S5zj!j_6#vOI|g*+~ck z%>dUX%_WQSEMt4us$0yifW_pwNB#V4mQQqNSgEE!_keiQ!hLo zVWMhMoJ^1#O3gREu=2}L{9!^ z`1BF&)eF5nJAfD%U3OpyFyDwZd;E^*s+#$}ezat=+`s+DTcuVUhf28XL9AKmr+D_3 zAvmkz?M_khp}38fobWC?)E=;cd9^sGKQ5rrgwe{8>pY=UrUctUjkL&yk%`fe&5Gxe zyUF*kKovhaf&G=HMdY8B8g9}ssf#XR6@oWQ+cliw1B6HqQ8x3B$&KE8Uafe0NN3K# zNT#A2!2rg!i@qxve)OXoE%o(UdAbmW!dK_0UH_}KXm5(?v&Nvq4Oa-W)X;NBm}&Q1 zY;Zk%lWN`l&>8~Ot!`%RKY8S293hK>D^pD*^#hZvI)nrrTU^QH z3Dzvus{&ESo&Z5JGH5suUta8+BxDxHkC_pFc1qGvZm)|ePYn?`9lVmFUNa%w*A7~c z8J^o-q9$~Iyjd*4!!5U#*aP>KRY3JFV+q@@8>HD7d;c+&JVADJt@)h78g>us$16gM zXIxN733*lD5n3N>uDWQBAO#E!1awneb;ZTO3hcC{bl0mHD%u`oo`1U>?6n)Um1^?w zM&L4p>%u(osF?6EDdb*YMv6sE5hR(@mH5myso|n*#e8%4=4WxLYWXu9sri$K_|nIZ zD*H9#KU`6VFUbqWpEb@?dz+aJP^Mi+@c#mT{33$)Y?h^<|FuG<)|NiCl68lItw5PS z^3Rujxm`vPU!TxZx@o?%!^$ziOeQ6B$J`6Jz|^phK4sSGDK|B7w&VUW_&eM;?vvD? zce0OfoihhmM-QN^v9%qtpq?v9%F2~_Y1mh-zF%a{edvrc_=sIZKZdk|C3M;YcR{xW zI&M!rB%bHVJHr7Dg^V{`sK)wYJm!d)KO;RXL;2E^Qm@(MWAUbustqe**z@tr@E}2V z?VpF~=WcKx8omRVkIF42*>5)$Aj#VIBRH>3E*&(x>)-wxge@1DePWXxgdP}m&t-`+ zTYoM+6;R%ne8A0yryaWoexO4`1qh)9Ni#NaQ{XBV4<%zEo$ICM*bnu`@lsMH5?QGk z!{GF4J4HDsh4egL4oxN!Wf=(a{EM#Q4Yj^v+>OFGD*XPB{*f(6sS?&_?9{{RKRUv_ zLTeLn#i`UYKg+JAsV?d*_0!`#b>U-TRnoCYN&LpvBZq-Z5X@Sb9ve~{^UG=6M&I^% zdWi7PM*O+TBXYNym``_VniX+Z;@Bu~_fsy~=@o?20MH>_7>Uz)eShjWyBTYh}PmI!~?5xZ+L;u}pP9#XpR#BFB8X7T}2TEHT=H z$kz=6gU<{Vt^K)r=H8uM3Dj@7&xNq2(Ohia9KC3H zQp4_(Nl6-~+jgJkBVU5xivCNE0wlN2hgmx(o}nnt>adxh3W# z`j}>T@zEz=LIUPbL8ZH5QW|9LA8SKaFfzA1Ic7E2L!8MbSf}2&ib^kL$R>QiNe1?G zF;A0gTPLf0H^NDV3)N3^dNEJ1I+oJ!L{T^oT9!|bthmj6OlHu1^+FBP23LwggOCZ> zwd`dzvN7BqHs)G3JMM`=C6YNIYfa}O5aLLn)uUMR(lFJ7MQ`Fds<_Z^hF_fhv)Ur# z8i7|22a6Ue9iAs`73Rp~wr?@?(^VUgl^zT>?PBG$)yOkPo*p?N9}vtQhn8#8w=`K; zHUL}2=*CXs5_j@)`U|Qzv%a!jJ8xcOTbobl{mM}>m}&Rd0;et<*TK5}!L_$l4x8vC zhRoX9mq(8A&P7;$qPKxc|nN1rlB-Y57vsn+!zWmeR&E%>}GW%Pi zw-SMc=mLZHE9i!pVnVPL2`&Tuv-_T^z5VcIM2YX%McKr}WcrFPeqetj9-@)@0njtZ zWspfxQLR#`qXMZiBj+=(XKRkMS6aoEy*qimZGxi5OFmZsf1Sq0%UWe)!kP9poGy@6 zmsaWIlJ_CZkHEiP(S9KACch9@`^}-tUn|O{#@vRfDJHB4K z;?}YVqPw*Z3r>xC8fVP%%p3{9!>OE`yX##~MYt!;)6t*hX|3vas}#nI59P90^T<&+ zZ%a{jD40t|A1NpopWOIkT6evDgvBU$^lUD<{+D1nUT7#^S=VdgOSMbcvHNDcgW>TO z{KKg3aaJGsRTq5Dt;U>Lr|P{68dZ}tsu95t;?d$|)nz8xN9K8YN5B^Eq_LgBuK2l| z!c803s!_LM?wZIyH}9xM^k<<>5Pfvrp|L%w7CVPu7)7_FO`BxYx-VX^jVoWSAL-_+P7OZatGV>&+<*uajVHQCXn8k-)R-cve>w#<^imO%dKXC1 zBNN$Sqp%K31Zx@QHuKw%H1>NoHo04TEno67D@Of&@e(TI}`{Iqp~ z34)EsrT0rRMpE)X6OkoIxTub|u@rcF(P;BsN+Tvz|FnpH+81I;eh3h}@8B4Yepa_c4>^qXS^r)EzK;G71MiIaLSXTh_Rq}KEkCw#J_c8GNV?=V+ zfGd@brltk!vTl`uH9KP6H{Xf_J2ih*70Wq!&3V?TK#*cDQKUPJ_Q;}b5d3m^A+_dh zx{|{*`$7px$l41 z_x)?lVhz1!X7_a0RCPa9PZdr&LS~1(Qe^EcM<6d&+uiu?Pgz9KZ^TNp)0LISQFE@O z49cgGT^|s=JiDbxeLX+l2KArAgb^ z&mq?1`F7EBMSskd?s^}AtX60qGfjR;|^;5*f~J<)|zw^Rn@h*I5<1kc!df^eW`^)_F4peB(d)}(Di#R{ z<{F4NlwcOr;Y8N=kHtK4DB8qbaKZ23UJJuP<6!Vgid z$05cT)plg#JgXU{s-XX{EQ-QF#@ZPVT(d3EIo7)Pe@)4u2deT zIxrR7@Tw4TnMhHBautEQg3LCXAqwbiDGFuYM^A^H1=UnHT^vf---pCo*al**QWJ83 zB=#YrYGf#wZx~>oC{0dH!5^FfG=`V@DI`E&J5ed~vWeAL-E5Ajfg8csIGK}7ZTuQ9 zP+tpx1CX&aE6=h^X*ZP>B>WKm^Po&Zr4)Pk&2$%0$G#_9CN>=I>KZMq@I3oYgJ|DF z_t$7Z17M66YoqRBD>PkV6J7Lx1bftsj3dur1Z`JaKA#$P{&nR)PQHFY2*MFVra~KyL$$mdTBv3Q z>6pa-%*H>S`mZS(*FaIQnA13ZTONaeBTh*Q(Mjk@OQ(*3K?TPB|9X6W?xX*6Xh@aW1Hzhq5LA_Za@~7D`e$<;B4Fq3-`V-2eMhpoJ2QP*5XHsZAjJ-{195 zp#+9u0~?rLQmJ7;=>OLG-_B8A3qy3^Hmc13N2vZKTL0}YO0cjdcT!?7AdyDT)qS8n zkIw|@*bBXl0=|LMImBT#|)>*Mmvr};zP|68a2 zY^VSK@nDub9g;Pe^z{D}_~^in^c-i0&275xhsglO#}*CIED=YhR+t-qt%WtMuEy2C zt;9CvKL%QLEs+~6&autVx|)+%DSWf9^Ob4Ek%x3rBn6)tP%wW^Z7d59vvmc-KCeXc8XvT%KC{9Ug0iIYf z)r9dz&kMDs5GnTQwDWoKc(4umSC*kKS6pg?G2xh+dyP-YK8l(WX!+Nx-)BM4(77uu zDRB0^)6F+U`Wl*~_M&CQc@eO~@sInEqR2Ay(>~lP^A&qKrCEP|SnaQ@b~l_trx_+#RhORd!7jG7EgDaop{1o=Ycfx_qe$aFxcCV9#K76rfZ( z7c=9`JHatDEFdX2mJJ9b>ruohMpfI82&$rOF@ERjZu;FoqX4f*fhoc1{K=cV=nJf9 z5}S{HWXa-36OE&^tl9mvmv|h49-t zr_uEj8e}EgndXzWSrm#qI2)@#SxUUd9i?rHi8m(&{cuWUGOpQDB8t1Y^}4K*%P?ZC=&Z@yVxQN%5)Qma0l?E+siN%KgoHjL#xy>VYO^)kt@4%!U(Rt~5EL zalbenT}F6D$XJoM*uJ*n96on?tIqV7_2VUkMYpp;gVDZ`+j*QEg6;&h`ao6^9~aWl zltH@CZG%SDqgSa_T9`C(HB`4Qo<)aw1mAmc}WXaTVugd(XzRmYCpr0qJ_qi4o{=_ zhxn{+=_-aDHtkPs)sF~qE@b8Ir(u7oWngK63)smoOI()Iw8Y$YnQ^$sVNNAYuf)Ah zWm83+PF7dsG^X0j( zO2pHgufh!o93KXq=+28eeSB2;_T+3rc3YSXogdroal2h6vW8@{?DAX&(8<>TGEh?clHjq{FCHJdQ$-`wnd$ zwcc2DJyk|&PE{0BIjrM2>IC@%CLRqi0aEz%@U-U6L7Do)H#9C$xdqP>IYA3@<@D_3 zc|7C0NFhvD?vd(7`{7x5pWaKp!zgLj{`DUrZ8`$TrD=QUt|Y#>8HzT0QfTbP<|kzb zx1jAQZw`md7CEHCL$V^%bwid8km)l+No$2KoOD-C;-DAXAumek6^=83TS~#fq3<2u zHQjVlcE&#(EXM5>Xc#qVTxgtG1gabxsJs~@$uwL{x91NkiPjDio{d2 ze5bFbcAx57@189Nb>f+IZr%i*aPZ2MCx;C*DL5ujj>*mBw5&dq0aWwERjtcFOSb zq?trcLRKfIm%I$~WeCi##s2?6h<&p;0 zgBPYzhsO&xQAHl_iIww?DGok+`~nSrtt@Iyv>`5y;d%E}VNhHPR0?KE!<0gevs}95sXR%m!IzfNbO;rz*BRh$*?Zsx`j( z>oQOaO-8@F_%$6=XGoI)tEm3tUn$N6iT36{+XVy0vl6d*Ys?%~J*1f}Q z2^&y9!=c)k+!eX<YazigDw}diHxFjuk2WEJ-arfKuOTA>5tXO!*7eOEspv zh2(qe%G7tI%v|-GUaY`@;}pjzPoP)R=dj^a{KbS3j`e<8db{<@WO=J5S-G0t$gMe> zp%&m`N5-M)deqg4ykTY5@M_YNK69YE%j$DE?#u^{n`sz_J94 ztwfO3{#Uogf%gQ{CbgG1YlPR43wi04D+iuG8Z3PuX6{8%qGZB?=g>(sHV0-Y7(Oa!?!B7~)5uvoA|-Eku0){4Nm+Csh0a zUu6$obg3++`99t_0CgKQ`ZwAEbm#k+&n3HO3h3_|>NPe9{PWQx;(`JC>w0-vJBi0J zPv!3R)+0&Cw@usk;o@=z$eq!zI|tIx&^W*{T%({ zsCjWNL^7V0JU_jJ!IoP(5I?)Y8J%ZaWi_5YN#(jkPClY^SPE*43Z^aj*ZQ+J*6g0O zM0Vip&E~PA$pz?+AS7U1hOp%O*Ye>5#@^Xao_x|BgC3Ay786uw=^$5Q~!a2UaCIqqFl z;j!-8dpy8%5MAX5B46ayE*Bw5+cS2?GQlE$Xav_?&llg7bc*XBOlBUnIvGm$294$< zC^$S$d~{v5?O{)<-z?DPXjCvQ=H~bKsY{WcK(y`Ob;Eo@J}G&LV~t{y{8)GWmH%u3 z3>(&%W~m?}gqBZ7U6V3-Ono7vuYf=JUdtl?c&0s`takKtQ~a{9#Kr&a3%C{{HBpRs z1$%W>6)NBq-THZRmrljDlzWPAwh+wJ^Rh{qE{N%)P(B>e1K3A*B0WRbf!j~$y0!cO z;Nb`uk6w3p`qdd~2JAZ;D(EB>PE|Nr302m)R^MM%MY^dfy!B%|rb7x!3s@ndoN)*W zwvwSe@VS}=6I4dBNHi;8)aA7L=n5R_1{4!1_*&esx;vKIDkx=O4UH7(hKRmZ!1$T` z5R-&_=(amvZZ1L+`oZGr>I&=deW{5r#Mnh?QRF+gE*^qsxj_%rRq`e%gKrtBQ`4BD z^;J8qTtzec}QA3;4rO||-RnxF~!bBUPy{^n__fL;)1SiThYAB08Ih3C5upgvQ zEg)PSOI`?M(ro{@%{p#yt?)}JZZlXZS<}_@nSQ(!Z=RE4)t=-p%EQ5daRjtWK$0G$ zPFA2eVWY`Vd}!VL)Qvx5bv3*hIk~_ANehMx`c*9xth(;+G>z5A?4!%$edgtz%RmCt>r9+3PAcz33h=?i8r=CJB^~(>D z=!??qyN(uZ3}d6OXatf;CuH$UqbK-w9v9b3a3JPk8Kyz`YKAnHC897sbV{$2ljiMj zT5)G$81I6j&1PUKRY|)x3-ha9^W>UZTQTjPCbC9#x}Xg94R2;II~A4)m}u1Kf8|fS z--iZVw)Vkr9kVms=sO2_VnIf2W8t1lY35(xn^L7b<5Q0_=s<7=P;3zDeInJ&CqO(s`=On5QC=lP+nG*!IMUMfpZ zd)?I?5+_77AV!?$Mki%teX`5br4x+ULBbSPq|h(_aklY&MAB2%8S;{lk3yN^;?3d< zBrf|C+0Kpv0(B>#Sa$T25kIq=>d)a!>rIW`b%xvawboj_$E{7l(eBdDvHlsqx3QX< z`m8JB0w*&?H)#>Y*<<_wV3nBbEGwdAJxxPOM zq+A8CZR0nzqr^SuOvG+W_O}dm#FqMd4_iapPzEtey?Xg#yQ8ow6 zg_wtOGOB(ZQeF)nNCvC{s3;Zafo%BD&Ct2a?{l$}V(9?om1?QKep^thNTk_D0iJ5g z;9kvqCjBXt+ZH#$W%%wRoX|>6>nE_oi#0{f@1^a&_RRXFVXnOCwZVGJudr76JCwl1 z?XEwEE#%QEczddYs@Aj}waZct$|S^g3?_;Y3GODItu|io*4_GC2oMf$PP=2uWKNEa zBXNjC{sqYYfiZr62LSC+e5_`pq~8aAV!Um;TJ?<29&s}IVIn%$>}uQmp@DbWMEE9X zZ6`sG$!e}FE=uTeesr(aP!qb(kBoVZBy+);U@gDyxptRcTCvpXS>Le(Sr9yKfAZlu zX*n-Z52>hY2H4Y3DWFDs_a(3Ds@J(Jh(g<96iCUYub0iq!gASqc&h=A!4uxBUUq3$ zrZu`xN3;xnx7B7^%trg{**P5YVosr&D}<8m>1%&SsH$A&vu>=ZO-Zy^q247#DXXwe}x!Kvmz{LKh6!tY_wM-kpMLTU8Z7CQ{4oW9O3 zl77)U%M*xa!so(541LGVO>aBS25Ux}AG$VSdeN5Wc}fk39s8RwL1>J7Ajl%d0q@1n z?YEGI9+;Q}ePM$5PnvDH3`{cNf%`?JLif=pZo^dKOJfSp7?kuSv+-TrY<5TK>z0+0 z-Sx@fZFE}RDwyt~%o&W_syMgXGp_l%Bv=a|f@o;R^+%os(jyK1>=wpDV4AIoqd0ho zkiJu&{WvRkK~ci=sHVe*w68zo8n4K|L41Lu-jw+4b!@AC?HG;~MDc!W)f`q$>6ah5 z_DYhsUs8V~xwNNiJpM7~b)&{Z5HGon>K3GiWTw2>(zcELorVotzc9urthchKs+OC0`Jn(H>_V<)6Fu}?(C;!go0E=ucV3ZPp33of z0f}Kq4K3)9nkCm^yM=u_L=;fYSdnWcLCr~(X|a9UZrvAgPp+YeZ4LIQa2J7iL8kN* z(O*gxlM~R}&C``_tdSVmpP#5)@RvoB{XK!2k68;Ki<~w%nag4qv3tgvKC z2CK&6fGe{;KFKKYRDQ0XRE$S%Diqmd1tD90#Y^*$*ne;VEZx1mYKGL;!mmwdq~z3v zSKU8Kh8HE4t!W*7>i*0X%Z4%b93kH1I$lctLWsl8{aLt2O<{r>dE8+>f%`1MT%_$w zYj1w5PhhXRa=z00#9a78`SP)>GkV{YAzPP>6ZdRNzF}L_nk|V~7uq_B#t}rUW%(AZ z)&r8}l4|w}`F`mt4ViCIu^`Wm@%eF2}zfPQlkMnvtZZ7z2matqcr6 z14eN{42`_zth2MTAQv6)SR$)Yu3EY95LxS(c6|Kp%Etb$sw%eDK@%M84uKb3HmNGO z%X>gdR1oYlz9ToF>>R@oPf2%?9LS+E4IQpGB0UMiijNUK#jKTTHGx3=+UY~1hZL5U zLGWSsdZ&rh$9z#OmVImWXNK6_g%wkG%x_}}G>HqZ+!G z-i$+OvOuJpgB(~9URCd*)}P<{o*lYLtpY*#T^An1Gtq{KT-7ZM4ND{ z)^5zAdb5-PhL=qVJ3w(wNgajHB&{me&!60(O|b{C{JB|U?N0s^{XEM!T2eyY0r{VF7?u(qdd5$E2+%HXY-kN!3WEgo|pQ-GiDOB5kSym2ZFrh0)WVKJL zdM{ho^%)%{cCg~LYmC&^!cT{ULl`6-}^8qHRZ+R`6Wci2nlBE`-v&DEp4(z+h|)U8X-sJ-ib5hPG= zyYCtr`vQrUWKf~}V+!`+HTr(b(k$1(B3~Uiq_2#t4H4Wq*adKx z4&BmxlEV54jx!Opi49a)kf4O11of#I7&O!6;OHPF**Y{i^Z`<}0J&=o|Bpka0K0F) z5DPvXTm8WTtP-H45NKfuGXd(0VE28!L=-Y1^(=MiQ*jfi`Y59VEyb_4_hKvgL;>j0&$UCdOzMliDs!?qk*WI?Uk^Ts+TX0yvw(8B%|s8`DF4&#}lq#vz7*D8@4D8yqqP(+a-EEJBt$1 znj;E&^@}s!POAu!DPrZA$3`Ibs3H$@zI@W2X~p$rTlO3RqIabJ5ZX*`0BR6uT4Lz7 zs_N(aH3(!nQ9FC8;%QijnB?yy@*Z6ps_aDyV9vNVj1phLY-Ynfc zFAfgW$hGR$Jzu=sQ9$IZ*}||2#Fjv+5g4wHS3n_poX!WzpcMuXWlkk5Vdzi-GnZmR z@+Sl*blzz+sg>VpbzT;8TTU0`DlVE3Rcnn9&+j(X^>hoXiQ}qQ5#OrZow2}_;MG5*w$rFE_KGo#5zc6wY-#Dkf!f@QPRKefKBiU zBDIl;&tu9HB3Xbq7^i>y+PMvW=g~^2C~`va$A;ig&G5AQR^^8lGDh85F9Fh1M<*W! ztdxEbbx=y;>5Hg>MD;w%$GAFGmQtk={!m?cu5=ZFf@EvjGwdii>C!A=&N#cMwiY$B zQ|)8a?A*&2vD0H=?z&^R9~xdQUXpKEM6>a2z80}S24`b3P#(tBevRLtk55r@(h|KD zO3}ICJx^RBstERfuSF{SEuT7G{XK2BnRT{wxYxeZ5^>4r4R0?gK3bRYt30{{TawG` zQoQHIk|1c!=9EMJ4__yL{I#Mx%{z^7aSFonD=IuE8#pU@>sDO|!;@?{i@GwC%5j0g zH!{mJKVo03y+35iHG9hR%kXc6e(bCi-zBxtqxZuVMPdld5Iytv(O+657A9e8tC3&H z4?UmjqGqy)Y6YmlHGKZ8NNkT}KrJA{ICAA!#llX*Vu7};;M~n>GuTKKwO3PYaHC4N zeG)`kJTjw&Ta{@UUPr>YRP27NFbBCxnRVXXrfprb4rL+S_}pa27jN-TTn!WUsy(cm zrz&9Q`|xnAMzyJi8e(`Ikil4^aqM(#R$5-Zek+>i5HF?c4@;)uLdk<+Jakj$knnup0ypS>0(m%0lw(inAE(#YbAu)3qPg%#I9c4W>Yl zDrGL1cay7^3C0k`Gv!RFK5ZSf)-+6p&)OX}KA&%4Xy-^wB0s#fcaG3(dQn~E{35$0z6Zai=zC5 zcLX=p=)IY9r>Am&-s*2AxBj>~(B@NbMWS-gO$&Vy3rDQVfvrBzZNyCVAl$gdOY{I< z;H(geP4o^-fTLC>wyyLIG2wtZ=AiAcBh9Lv`~pGOP4NcFXn#3T2xw!}(B#xyRufoJ z5RP4C^H>bDaP9i>GVD9Bc}vkQ0~wc5Q7fw6B1+*ucy++ZUIpemAupshw${0NmxfH_ z)5uX0>;=*@F&mdEDjr%1(tPl0fgubK(SC8@Shr`wzZ!0?rl)kOv*AD*152quYXxDe zGox4A579913xDsSHJF9_h^k=DzClaCdebR8yfLiPdvzywoFALir*MDE5?hw3=I-{vPLz z$BN?={bY-(c2uMF=z&~MZC~{;x={s&D#4ZB5_5WQy_Cj8-IY2$GGfnR@dGP*HzS&j zQgEYsTcBqPI|V~%5FKRFl!NHLQgM2PO28z4cym3D$c}1!73QwsOWdHQbh+ zN7g7xZrqa>u*8Kfkt6h3dNkT*zskWgZs*x_VhmM4jIzaE3r*;1WNlRVp6Bxu!gKO{ zE3P#@P2ym0TW>`h(9zEp%EuMq9r_t%4*u%x3I^>xN8gg6siDioRp$pK6`D|P;}A&{ zlV6xK;^@j_a12p&)~w*)=UIdtl~ zNZ=XNZPQoTEyk0=>c-NSq+3>BmVVqg4uX)s!H6|>)AC0u9y56VT;uDOARTD_bn$}k zO+%u$ScOpo5J2{4GzxHnBim6fD)lQVy5)XzbF;uwUH3R;f^4)C0)e=2_6X&?7J_AG zO4G9b9l6o0Ji~gpeC9m;mbTh5mXJf;r{TN(tAUoKM`MZi47|(}@kFf{XuQJ%E8|DW zn3cIKL|gZ-+CQF-_j|;VMLE${jj9ZC-Dg&GmE0x>@>=$`zq^sCh@&!y(?&t~GYRMy^Dfgn0yIt~ELQTmr>;!X}{y2n9 zmnfs@Wib-iF{}&&3zU0^I*^;`s&9%IfD_I0YO~q(Jm({8TKgSj?aqVuXcUQa@eogy z7dP&WR7zgcLdONiFR^oEhiG>Q=43rw4uTe!@q|BOtj)OKWo1%^?JcqhP!oh5MJq;ZZ3s~xU zmv(EiWx1zrK9yz{SKW6lYvDhxP6PD2`f(r(-rlt*C+~X}0&B?@^HM1LQrYu<5M5aB z?~u=xqO*@c@4A-Pq-Ax-qeE;lbzHcm-2(g!ajVYltfwoLoY9rkXEzB$J1&}bVdnDw zV;M~V_sx6ZjdUrlLKNV+SvY212|Jm}kFpL$7S%B^flSZN2JK)z-x0ZCcRw?3Hcw?v zlu2R}1^mc1W?++5pxB?ats`|M!g?2uJ#w>)3M*YzHKb|rM0be){P)Uw9DfQ z_yf<<+u3t54}NXw%_trA)kF;>Jj9I<;&AC^hi7{YZrdUZINAYICY!o(WsvcT?0|4a z#t`dW<#~fO)ovWIJ=tG4&!$lW91v_cDee<&Ysdq{^VVO~Zlc0J@$SYX(abmT0LiN8 zp0i*dxw_**s0bZ45i8=VTK&l$M-rUr0Qu{E0 zB%AXhsQEjeb`<$YiB%R=R(14jTR|-Lon9wFj$T@O;7MKSg$-U%U+St06YhoX2R$_E z74nO;%oWpYZ;xKwo_eAZVcDD8Uh3x{Xl9RCJ2GKqXB$)okz-WA`a`<=fvS!;x-eq} zrht|DwsWUzM5JWsB}w6t!r(i`Zt44r2@BmJ9>-mT9#-)mUjPcq0ElnuuP~C|dW+H! z?s)2viYf1bqQd>$RHMNzYY&TJOOt?6(|AX#$*E8-`sMqec_{(DN_RvX*3*~e_^be0 z@iIV-ue9!m+>|6oiQ&4y=uf|kE*`Rk~{j2Ue5c=9wFa^%l z$fNGslSFQw>76tAG-%ngEDF^%G?CsYSqC<|wUaE4Zaq?6P}h)Ne^uABMRdjfzH66w zjTSy2Lk@iSo^gzskDj|vc0GPk7*kUZyVysEM90=>`Nko z>Qok4W0qrgn~v<)5Cj8CNs6LOJIy*+ONBTN!nN{oz5z>#BqjlvpCY0%kg~HR=1SND>x9C09t%r_c z)oUzd<1rl5g(AEQ7tER#)XtOSvB}e6}wqLR0M0aiaUDGwNv@>|XBg=$Q&R%y`CU4#- zB_7*$Gg4IQ*6KTm=Kqh&}D%L-H@sfN@Lvl@PebP%)X1Eo5TgGg+?W@l5~$)FK1C?#isgu4{F`Xb`FGZ$7p*43$MG8-(W_A z{nnS%@0FIA2oLrfB16t3n}G({SKkt@f^;OO9=3lw#g``yC}EFFeildC^|{Z}*o=la zz5^p3QlR%RDA+`-Y9BgUe-;Tu4R~OGWOXY;9ye%xYuo#Ahz#c!*Zkwny>}glaP9>P z*V9$T3S$&~TZJFk0S}(6fD4Jk_ih%pIq@SCJW+zo4;#=bOY_|VBp6XuS3%go&s5Jn zt)=?0!Aq}q+jHGLqc@!i8$M<69a4aQRBO|iEA&8pxjbVS?J50`?UlwT`P|CrW6$9o zB7vhF*!ctN^}`afiQ3mr8g*fBv0n1ena4sZ_bfz#hl06fPxZFs6-E=nJlw(>A9+oZ z6&LqA%Q)!U=H-=%L-gPg$>t4AAB0wgsDS;=8x?1tA<9^I*FepU&;}_5yc}|ckPb+p zS_!ooS@uE@l_XYQm%#ei-U&V}!D-3nEtcA}mJPgb-emjL)qo+Zm?njQaB!#VFX9kb zghQc24YjLISwo8xo1NPFx9aC|FOKfsjF-9FV{{_X0v3W5)Oi~`7N=2mHZCu`PEM#w z;On!O>2>~{EZ$*g(cm80>N(?Bp&-r!Vr-K+`=Z0X{mj~fWZX9ywgL@{{KL4 z`_}5WM;Of}3QLcOi1|jiz9>0RX2)-67t7#pU$D;A@f(t2fRe?_j=E&UP1#W#FRLxB zKXSpWRw`79WM=wm%#g$@xgC#-XQ%4J9e#L7pSZz3936S(w`$9Dnm)e9bpi^M%cf2r zdvU;9Rjy}o?w`zmv7H?N2f@U1yJqUWsp+`|pva%~%4;_*0Ov)3WdU)`@EX$(aPp_W zybgM+qj+%M@5!_J)9YvALBfO!XR+;TZN4|W79whHQ%+B7xlcK5=RZe+%@DoD>)-Dq zLzv4>^hO5tyuDfy_9B=n!g}h*IWLyQ=Qs>><}Fqy41YD>hmasO&ckLsKr zfE;6`ATw8-!<6B5CMhkcrl6p|qDDJhGl^ctM#!xDN$>Xl=GD%!%V|sFT=NO zoiKv`Y~a=JAUmz#cN3lf#S{V0u@jLH;ZyxZpVN*i@-t=>q_q>ZFmfdp^&+F9#Qjm{ z;bp|o{XYL+ldn@lQNZMd~64Xd> z?`6PC!%`gFWjdFMcbm1CtJm(R%b1-yc}nY-Cqo(gjP0uMnfe%LFPK3u_A2KEZI!_# z3IQra2>vSYvHYdfb|%5|{0eR&&rb{9ONMl^qTjoHFR5H%KqFCK6kfOt@IAKqh7TWa zZfoPu&7Hwlp1|Su#WTFK0y)l~iS)b7Ar*T+-h4p6Lj3&=+0(a%x|P8}ysOvG{Y9Ge z=tOCbN$`Y72D^$~TMprRi^+$3GT-{--S1w$+|6qxxAv?@Gv5O#0DB!BYXO3zD${gb z{aQyBG0%ryt2=)a+e)mlDJUU<)-&s)o|_TgAMiENBDVDxI0Q87IT_T}S>YZL2XiX2 zH9zMR`m@gRX+@)w5q_q%L*K^0%~JT-%Xe^=T(r3tp762g2QP-ywek&FltR^S8{B{h zil=e;A8lPNkKwUaD*4TG(r;YqSJ4LcX3H~MM0%54_%*BfTLE8Ju;|`N1S)%z48v*J z?WGbJy6=E*MSyF*yq)}AV4KSl2h})TF>&~AAOo$;p*>HV#sjtF(2SOPg=DZwA-pbe z1_0l#XFKbO-bAkpz>3OI;S-;F&D!Z8S~_6Hmftqxk>kpgqel4}R0y*cQO{mc-6qZn zG1dDt$?To&5;Ja*^PTq?kvx#bmMOU9=&CMRFcGZ<0C7!of*AZ*`ijVJjD*v5z2>U5mdPdah#o*;Vl5kGmr6~e>orbgI*lY4FQ>5OfC*)4Em+fX(|09Vt4a} zAPaD?!S7B>de!kCT3h3iQs|n>Of_3(H!#t|i1v8wF^IP9`er)a`#~l|Wn=E>mj>(GhY7zbk)kR}7YtVD zcH0!ZhKt2z^*#VIN0a?!vStKPmV@Ues@O4{k%xNf}S?aW>v;! zF5jBVe;gKJ_sHzn5(UhOO<8`Ft3l0BxjJCuSl`F%xw@S-c?6#`G1Vd3ZMdv)K-flJ zwP78vT$Mp-?8JXiSESyo)iXDxpi#-ra7#^A_3N7)y<`2DRyspYa^Y6^h^;E8k zixmsr!I9$|b*rl!Cps7QO+H;0J@f?)`X|a>>FQWkI$G7!BC38?qYH%Wo1*Q*KKSQo z9|h-fbj!73hBWdJVxeelo-wf_rIKey3UjU1^=ZjN@&I8r#V!yO@XdIb==S z)i#8|l>+wVU+r*n^$KDajHb_z-{8gtuEBF*R4{U+x&K_&$y@YfvA?t?mmR1^G4teD z%2^UIzgeupyOU=xu|+E4EE{^i;;8Jq8!NHK#VGwVfyly>t9-rNW|32?xM8Vf86 zGU=X(ws=k?G}mg-YK)8X^d790G1TfnlkV&Vt_oadv0sTns$~!E0q{m*$*JNVcbff5 zXGU#H0J2n6rdRNYew-d}VQroZVTKjK3^imNrSM^ksc-^w+{fMOhz zjS7>vBnP`0{q%5s@~i_4uc$J^cC1pREmz}9^hWw2rjq>T<|bZ+T-!Js<7mF}edd>` z(}U=&(V_A*qB+Zs2VCuCvX8T*)CW;(x+BMFn;y~Jgq&CPf{47aE*WZJl+LK}%{@7B z7nAkkd5NbIEpixhyvWlWTTRV$CLi=TP)PS>^vbKcC4-9@8v6OOka$?$w*?o$BV`RI zZD$RhHj00$*yK0pz^Fd3hmLkK)jP1Hkl3(p?4!X8Y3^^wbFEsKJKh27bB4p)V#kz9 zzb+oa=XZC z!%5r5+_+kV+3{Bo({(v6C5#{0t=)r6%Uka=z&z0r!f(B`YfgIm+cGIUwt?8d zXAQ@J%_1#xQcVy~depaEzq)@+O^C6_?!r{k<#;pK&RsqxSKa$tNub24*$`YMC(NDA zL`8jXS6)^fcq;NV=wtZBo7b8zey7`0kFZFxdT7Ups9AWtd8?D7yWdsO7)FJVt+~DLHLAyD^;EehSS*(qMT~N+C$6<&_>-|yPMv#Z_cep@V zs+IJlIg;`Vx0)-r8HhkUJV>KKG#rS)>g2@`lG>xhmi>){Q^h)82ZG$9#P0+h({lvs zTxn&T`E^?|-fOt?lxx`P*?DleTa}I->@%7~Y@4nWoV&!D)SQTVN&oujZJ06OBqkY% zf!j*;@EEa&xW0l=pXaM&&#+;GS2lbeOB1DE^%FNEjx6@Ry05MV3EhR^@+CRPHu}y> zs@Sg4LGybctmp(La0S4cbnspJUTXiQw*Ga1LjdX^AuAjCzZj6%sNlVsk|&cCc%uYS zhkIXoH4A8`2Ya-Y;U8Su5M&y|mQ=?0aM7HJsT zU&S$xGQ=wlzU317>@Z%syije1{95SO_>+44YmfC5< zwPDD?Z^+30mp!g|?f1wU|A=q%KnqQPVTdFsexJd)BYbGq;*NkTV~ZUs>Xo-0f_Grkt&cM>Dudqx4pY6w7uz%BUOYc-xW*AK8H1-MPa^113~=UMOG!pa zc#W+GCol9+vo8J*83up&%{Kn#q`?VLq9$>!yKY($khFWB4$r7c4u0Q@u zeQrv3gduY@va|)(iCBafao9_g8Pm;uiT#NxqkJ;EX+s(6b#C_(tg%IWW`sDGaeo4o<(wq|X2EiQkP*1yE| zKTg28lwT*?eV_8`3M4gObnn+9y6*8P5tXin<|=*S;;8*@v_?07M)eQ0%nyMV32gqP zySt`Ew)J>U|8K(t@W}z@E^E?iQxY=e1CHh{B;wKH1KjgXD0jq?d|{3jvWmI z`@Ve63jhBw5&&g79tM7hI-XgY2Aunv<&;Y+rb;)oY9=q8GUOu%D+&JnI)9U~e>Ikh0h6KnegwBx4Nj-Y=^McE zYQF7{B&(j|yOlC}Un*e~;G9HPxE~#z{CrN@rhxx-ME-$hY*MlcWnoey<7CoTH#pe? zAFhqI_livt3BStPF1R0ji*`S!7L}TR)J&*hkQ}1>^lkMU?sz%>#k5j%S{j*M5Vz}#R45)8y2uQY1~RM*zl zI^18|FErTa=-b6ddm&6tPHrDJpTz&Jht0+Yhp(b{w>W1EunWJd?Q_o*Tn=z9oG)TQ z4DS@din7uZN%aGMR^(GD=|haZZ5olbZnA8i=&@5L8v99De4G!rhJ`#WwW8^Q)orh+ z374m+1d?z~N0O<3myj)??~*zQrAe3AJwTeq2&?h76{6qC7>-%Y;XCpsM)WowZq1lq z(gh)}-a%qp&vdM=5)UM;o#H?3w1p8z>8$bd2Y9Q7! z>Nk1CgNs3Ed3xQ6=vljE>Tj>O`CCl zk~_}?Szs&w-s@i`+Nr}UNBH?sB)qX~D%xdXnl|OhtyCF$OM6StnRZ68WL|Qo1g*t0 zX%#d}5V1MRcT)4lVIK8w6vscmkiSgS4=05CoZ+`zoB|sfEatOIPZKo zE6dcljRUso)t^k#W<=WhDsv|#Eo~i0R-(7+`{ex_s#jK1)0$bXu~1@D;VN_HX}DH% zaTn;*0SSyYXtKrjlD=kaZm#{Z=bQ6%?%m8yi#~U6o(pgjXJ6XgPt{uo>c~AwPC5?m zQ8%A(XIKr_2!p2FrVD;eQlR>1&I&l>71u&m*S;kr&cha#m*;nty;?KZCHYfJ{4Zhs z4CDi8W)bN$#0=wBq6dLSWIf54-pU5*=;)+*{hAO5DEV*fB0?XG`o2__Kv~qKC7Ixi z`Xg&WH69n1jZcqvP-tYEVykVbcPM<>W0KQ%lrOa=C+JmhfifpaYl@ZQRsP!tZq4yb zI`l#h`|_n|T8(TCTI0q|w=s8fOEdd?cRt@q*t%CST_ODqhp){#@Iam(K9UW=&bMA3 zipZ;I|Mb!QH39!R0qp1(PL{vus_|-z0-HbtoOYDp)v}{CT61?W){s9U+V(VE`w+MK zCvSiRQP$5^2}S*NvbI+C!K_){S=?1~F1;9!WrFs|&Q5jAfU|wH#-BTmx&7Xuxq16` z%kzl0dy?sep8o7b9ogt`oS&v+%>&fa_sjc@A zlX-_9>?N-ukz6|e!fM~(dn|$13Vpngh6Z(jc>RBv`^vB=|E*mmMY=^&LK;Lwx+J8# zI|M|!8$?8u?rs^nVHmnYT5{;Fp=%hL^SJ-#?04_?J^O#1kLTMA&s@V3zxl1T?)zT% zVwL!YRW=Eb~WsvH=Xp|>GHS>7c(B1Q0WxXZfIp`nXjR# z+0U5eOZ#Vj^q*cb_QEe;U_Mfe&#%eUtwCfvS>rkBSaMkv3 zBdXi%S+)LahFAIUM)Jgan4=Kb?0oLpo7z|wi$}lX-m9@Y=p!At$6-Qx4T-*5amT&UfQ_?=+P13K^3>$ZwM>dP*p7J;EbE<)F z=mK*aReOwwR7k$01P9Rv%qR@bz0w1L&kPn`{*Ryge=WN}$3JQGSE4oS;dK6qfycaw zXWOGmdlhXRp^+^(ifa|XX%F4*P#DoNk9*8%5N}F9f zY_6D)Y&FyE`W&XFqr>E}JQ0PaDYKa;Kb_Qt9Mmt7XR_(Qo{RlYgN@)sInCm4yrt$B`l+7 zy27F0qfuFdAIwA5nqOc~djsrIt7lIa_h6U6+Hwj3Cnjsn&`2vzNj?y}XP#v%^bZc! z)OF1FFBEwOSu6pg(rl=45e4&gb~T5T@thw?|70$JHExnKVDCD6)vWb<#Q%1kTE8#n zKvP5GSAQI1SzSU*%&MD?1`M^!O3qs;$8SHdr>%N=!r4b|wch5ywbZjgX^8DPo63$g z^YU?{SW4o@Krr-M-zX{5vlqHj5_$7G@(etz$}AqfG=01+%#{=i=OtkuhCHTaimRW8 zL42=a1@8LdX=7UTG3n?}1sALoklI_mf%02N0n^wt;A|eg_v=A*lgfMOK%Upy`y1=z zq&n%*zvV$U2m9S|WY5wN&2r54;PF8YK5^Fhth;Io{WH#z^T{Ct(6d(A*Nq8s!yU?- z$L|Bc@lNxZ*XiMx10_hj75QST5I84f4(P**+``s83|F53UF_f#&D2R2BTBWJ$%nfL zs{NO|wr4kUN3;Li^ZNIFK9cPK+?d3HM&YN(i;FGhSqg04NgTT!K1m+%*%tBp7$ z?T`)>5_i2ihh+}PvVW6U5vF+B=V}~8>-#9G#LcaFhqkhsCXSqEy||%mf0U$;pDx){ zv`kmmx(L4t?WS6PyguOo}%TJqng#)P; zGYwf6xxX~G5d^sROs_36c^KvJJFLc0TrQgI5GcC!cC9o?OI3pI`yqx zsvQ@^eoPJi_Xt-3icJ2QV;=fG+*li%SBFY~fr?2oQ+|MkL&3ytIaG-gv`HNQ z*#~iLaKk^?`Iab%oY%hAL!6ALTwn2qrkp?JGNwEOB4 zvlP{4jC7%u0FLU=Z%@~1uR#4q!<3$h6oz-rU_+N*M@Um6(I~8(&ByP;^lWD;JCr1_ zq(ar~c_xc*ng`wm>iEEk(Mz+UA|5iWm=Rfe#RxwF6V2q9qbOxBAhfa^E`nk+kFvsZ zqU5_zfx?93%;=qN2m+JM$zy*e=DT{e!rvr9?m!|Wxc&`bHRMNx&Jm6*q^vCFe$8VPTA_?4hw~MwdX*a7xA^Fx6$-No*pl_A!gqi8ymB& zFgK-ncRDCPS}k&ArI{J1eX_L2geKc3h0gfoyUHH1NVFZ}2BrL&0eX$SIH7+X+euoou5x;_xs)VX-U`dQ!g;`i3U|Zn= zx+D0U%a;6s7^m8USEErmw37R4RqTXAF6ffnYg_;Ib=qJaqQST(O5nVMdQ-y=)ROT% zVLJ=aqbE5#cP)UwZJP2od+|XCz(l4VO#!*TEh5PtQlXqBQpZ3=1)azD|=}aCJ3z)Sm60^{l_mRPiD;YRl~ql|QOd&om)~8zH2#BvbLWWLssBVXOac&km9TR9kY;*s&NAV)y$5 zR&70wVoTRzViyruHi$9JfTZ0Po91f0&2*v44i{06TK2%9&Omq6;)~Kc=%QBW z%YbRQa=}(@9Cn{^_ApMxp5W4@GpDe-0;NQBJ8iPXoB2LZW?W#U{2lBT$oI!?2`js( zs3_MwmZzv=1*iaP`36!%%zLo{*RbvJO}RV(mD7xtd*$!>dMER+*Fz{1i!a9&LD?x$ zdv@}V5O=dySzy+a1BU?pKV|{_{rxe23_<9kglOrc!z(Z7jsS0vPumAiSS#I&MXN+t zJc@fsw<}Z|1YHkpN-?QMEBfkf?AZ1KUTflT2FS5M+8pk72L|{3m<`oH55x~P06V@f z#D9KIJ$ZHU7do{NS%jI?*tZG*rZCW! z9RQwcZ(C>(le3v7pImeM{-WN`c9FIE4#wG_)sk}>UFv0`(cUUjbC?i|c?cM_@rI5z z$m3La>N(mTj8Rsf@du<=0Y_p0jLzI@6eijqDy#MO;YMq&ob-s~R!{!^I7D=2z;~O! z05FxfO!@MbfNcqs!kYr!Q`%1e<3-oo2ITx--z%CwITX0FM|VK(rRwfBwFVWpIvCpUZ)x$<%^z~J^hGPyuZ@f1 z_sX(mN-8QKFWo-?Ufi0&e}{BueE*|{sGrR*88Gj=C1Dtm$cgqk07He$r^HV#7Fj^WgX$QlCa7CDug-*Wi z`DYXwR^~RpO^QEmMAK=Oq6Gvin?wUU55C6UN)2VfAoWmZ!960TE2Wz`!B};HrG~*d zX{_2#3|^TEYZpTV#4^{*SYpv;g0g%ht+El#5!>!0A(miPIO)~g_@C7HdZe{&(+{gK zElTYEx69^vleSD0clm`R62r=88)}CtY7WgD`f~y%j2sg-zOv1)m=)$`vd|+W9cMu6 zFocezhmt$Eu? zGL}*IUv#|mwEVpajSk`mBi)x*Notf9kDj|N=iv1Uzc&zIvI)XiXq={)<-jIJXVWgW z_UefpE1Qfg+7WuIda$+RbCdwA)!!n26zx1k$kQ`_EQL?c=U!G=HHrM)e)XOD@q|uS z$>f^~N`!wzk&GzN8ST~+K9)fSI=M3 zP*yCvyjSUZ-B=W`Iq|Hasw6V!eU z-$NDscZtuxWqD%TFMoqvj72K`hcW7Z`|iKq&Se7s!7cz-2l+oI#{Yzu0+p12D^pr} zlz|^!0*T9qR>9K$jJ^NYIuk3P0d9Xm{cy9)f4oKifaD(Kf-G3w5;Mm7D65cQf7sxaw zhU26r2?Cp(08U`2oqS$Vm3Xx`P8@(EigSkFNva4f$O7Kt?`X!4Vg@p(<;?vecH_Pk zixgGJ|4^U}++a`%Fw068x-80bl}%{wn2^wlKM_tv@JgwDLfHQvj9#Io0`IEe!tupo#X@1CZPSzo6_5Y z<(7Bj&OYCSzL5dTc#apivarpGWg~mTZXh_4s9E><=lU%>OpEv;-Cp2kX%?o(_($yr zY;QaJcG<)VnuLa5p8Ceb$Ey^q_!G!HN1D${VfBP;;bxH~jz=B{Tia8z{sS7|!Uqz& zcfPZ;v*VD80Qc!ccKy7fBIfLPpesWriDT7=Y7ww=0em!3;ybVjK4K#wqhUq=0U6*L zGJt*Dwjsi8vOBcwXkdvqfQ=DRo}dm+xUj%!T!oIC-@-5I=H)bJS!OT8FiQ=C?5|tS z`PM%{Y_;_KHecx8tUQC>bvXnumqs~3gHmRSo^+2JJ^s|=;jPmQgigh4V|XEB)5wC6 zvaJD)e%5t5YZ`{=Tm{iSS^15Cnc3n=OJXMuRLi+TSPnml^z^ll(p58X2du`kubTmi zkoJz_!RePdLClNTdw%?Fs}y=X=0L}rZJ9wu*ZcflbpUT}nYMl^ZBU5zi!nsVqWYZh z1?vD7#*5#&*V`kv?8Hak2!|0eS(ryvK#4CVaM3S6?l(kyQcf}`Z-(@LxWeT3Pcm@+;kE%J$a618 zyG|4x1`Z2GdZTTzqFsc5>`p9-QrSLF+KNRR^?y+n4-%_-eb9J4PmIvi0fLh>_^uqXRSDq z--52DO+XN)K-=bu zr`o_xwimx=J?qAEWMErplvi zS(`d#A4u?vKkP8l7Qf=|i+FUiU7xd0gxYf|94qLV%7c&0(S+Ob5Td0y=N6h4*G)QW zzTg)7bB*lXoVvoU1oiD$F?X}U2DUI%4;LX?hj5hTqW<&qrRM}jJapFc{*;c04MaxQ z<2NNMSkwm~i-n0l<>ll?+J5iL!od zi+M8dLtmQ=c+`JJiH#HcARORqB=OD$7@0!rxQNd0e_Ib`V`8dIyg?j65?Ak&Qd3#t zUS6Tgie9cDTWtO&I(KBc0&-I;K)=2AmCd+yVQK3r20ij)AwtJ8ezWc;%z(6-Xx>u< zaL8b2yWQl}uRZGsLLby_yVh*lotZubar()YH}0~uShJII7%){dpUR2pm6D?;-Of2r z1v)EfQrCo)EVOD|wA_7fiAVr;jhOPD0@OUy^{J zlJyG!ap>6#RH|>n6TVDXvZCfXyv?a`W<>bWZj$?w1PU_-C_Ue^*|_Y5ZgwYnB-}(C zOrHSko5{-(*_V%tHIn>noeEWhcpUxGrfj}$mNPE!;m2f5CN-Ju z`RtPEe=ux}{lC>E8dW|FGn`{sgLjQlKK8OP_jCyoV&e zVs2wxy@c;s@J53&;k?;wPj^sV3&&G5e;YnNyWU#5(4Y`me%-XGR9x;GmFITw5{Ak! zAPl32AEtnohP#kPbd8f#yARo966!9ya+bpF`I=!s{+`t<;`g|-m+vg7FsW#O8|1fSn%o6jN6+aV-h zXyL=3XRM6WT36j{wB47vClN9++HXhCr}r7x;H8-Yx*YGd?j-!eO2MUAO&_+3jmp{7Ir!arkwCx7os{J&%@kxfzWK#KT6Ai6A!+~}g)Y1l z{G(02a#{Y^?sF@_+SK9NiEu3Mhel9smlsPNyHfHvV49YgDxsfe&`@2bb*C_#GaNhX z_jzh`BPuz;5jsD1&iy^%hl4Hqjxmj=G5<|Ue7pwC@1ECn`ZL2w%R@$1N$pFXv15gP z?L^C+u2j2p)hAUh2&Xy;PQ2^`~Wv4JuK@-+;Y$0j6XH~6R zw|kGd~rv zG``YuIn$62s2=yWu=CX6YmcvGVr*Vf;2?4>+G=~$Yc|;fMb*bYENC>%aHt&a`yVzM zL5mx;KOk>r3DNc%U+75sn|C%CIoTdy6Ppc6Se2aFQn8K*q9E(Q)RpiFD`2hV!>?EK zb9NT)Zn1ZD&7dS}?gs$}R`y&hsyLy-XT1HTJ}WhSLz)R3It1IA*60k>@q6{tTzoCC zD8@!%2pk@jtbkhZAPT9I@DmBSNsAO8yQ{b}hz~fAE)hMwLXkQPRHi1hRwrTRb)HFn z5isAP`1)hff_000UO4~Ulono5tFIEDQ^nf>mzH&mqV$85$!uKWqt_O!8$Q2E&$^S( zj@*1m$1OSyzj;@zdL15kLk9bRb^(wfAJiv6D63q7M2_9XNOBQI{ucp{MT`Itp!^QEeXukZ=-JO}{Gp7~FX4V=^=zaEis(~s znJE02J9qP9Rl>X$cbml$En7^=5#L%^rx0OF=w_3E7=xqlFFT#jH7E=3XEW@4R3K=Z zb17DtMFzT^&+TWcEm+DD>@zYlazP-574xra!?iC@NfAoC>FN8aW#5{MSr936jTA}r zzo}7_gia(+&axgB=6KeG?3Y^&nU75vo>NnE0`*)EGOiE}pvx30S;!Rj(csUB0c5o2 zU|`%Lhl%Q^0aD{%fqo$j+9T0>`&F?v4#ica?Z;}NDUSK{a;zMJfj!6~A89I!k1688 zCF_z@XatD+oA+Akj?BSPrbFK=;sk!X_#fGK;+pnS(r()a6zU)GmZ>rUr>N7UV^gP~4sMGn zdUWbnV$FLgHa&SZ#PrdGhn~7-W?eePuTlv>!~)N#g?LZ6R6A-T|47FBVl`@ zP=P*>{XO|!xajzzQo}XWr)%jj#!`8xf#1_Fzi?I1_PlI;&jBRQxY;_*E5#gFfCak0m^oOTfu1CMS+yhN7G^FZ872vgl3 z%Nz>yU*6*=2L@+o&0vdO=<(VJ*OU?-(Rqe+`p}g7c#3_G=R2AIf{=8{rEi7eArsgW zb`X8}VLImY1Ib7}Jy9i#+tZsWo0|!DEAdgWOLVu8*Tm3 zS2c!A;atqBm@g-H5SAI+4!SL?nwpX=VT#7N<2%TQ$OfXD&d$AsHHSM>LnDk8bwut1 z1S$<-k!k}{!X033hBU0Q^De=N?WXUFPV=R$jZ1bOBY&wu0xJQH_ixcmGYAgM$!8qd*<~=% zTS;BC!)-#TD0nR6Xuh%3~{I&blz3BT|}+mXdo zc_Jpexj|!C4`nq_UFAj2El2Dn4OkTGK_B#3JeYY^y%+l}64EzvEIJdE&#S+&3T@k4 zv=k5SF!)msi}MQYfyZ&Cx1P~pYrRSiXIO_K7J#yd6=BPzN3l~_}sh2!R__EAC!%S?)66Q%8sScHj-r<+YQ zgJVb2_%1|f4T;wqH8Z7O0ib+O48(tSGvscbc6mKCX>eOEs+~2+IwQ;FJi%-bc`=k; z=i8Nwap^pUE7^z(+99LjSSUw*JrKkNG)r3!aAuAJvLwqM5tNm+%;L>Z2?u4H7c}{8f;&#PPZz6KcA;MREQ~ zj_{i|A*Ap zF$~^hVemz=puX)_6BB#9#=l1$G^Da%U8J}E{MV$HHwIKOpA~;&oAM~N2qP&m6KN2z zpfeTCL_$p|I-WdS5E_JauwM4{iQ%IR2$z`z1*1voa}^U`DYLRxi5ynHUj&SiC7R~k zLexGy<9?_T*7zYGmzaIp#X2KuTov%{V9=yQo6ekQH%c4JHub3>g}jDBv-4(g)Ly$) z095vU;`e}D;_~DaK@xj?pK|_|pu(MJT(>h0-*43q7I$`>J2>Dp#JdsE1G1wX0Zaxf z(zss&4Vm6F%igc)1F>tMJ(NVwl-=>cIy7!!KBB{uTPvcWO>DgK&G`5#{<7jWZmmV- zLf1jSRUfXtVz|H=F95u!)N99^Wfw^PsEu}3>ufO^PWCGzR6Ya-_ zr+Qz-d`D9<*#pjU`4&A}9N{iSw7nU)-LO<^<^^t>gQq$5G!pJV+SHBagCMP>P_|%WVB;pO=;aKwP57E1} zj!LV7)k!OhY2e&>NAr)>$qyL(w>pZZyCn_^ph1OE+-C?Z{JLQ>4xu`jK|2(->nFXEl8_b8+tBu|rm_X)uzXm@*$|VRV^gNv@b9FEamqLnrkbC5)g={q4ZdmMl2YAmeQWN(K(uluc(9zu^kp9Y$yT@?_FLor{9J6wDf|u^qN9?*fOE5XvSroI1B{NFIfgL zZtXQnZ$o@70~DDvDL#qpSW0s=^6v<&YCXB&rL+fuKgen4XA&?nZktp-a}vG7FvGUy zI&#Y(-5Duplacg^|4D~=At5lh(guq^DzXZTR(dfglM;%a{bZr?`}>vebM z8<`XbtzEfF^_tNgk0{^s5qGFD9B}BMu(ob}n0in>x&daEX92Eke7jq6QDm*%MF{+Q zrO7YLsxKD#aNmfhtFX_$H^_~%m-mbkQ?Qgd3p}u&?=&R)I7-$Wv^CTuu+a6iSfo`k zHvCA=P?t5QD)PvrK6^5^P4HF2RPCqfd11!EUEfjARoZjHto;W5Lbyt~$L&Q|qdI0U z1=C*)svkha3kG@F+n4k07XH-0DgBzrX>4zskVx~IBO_6aed$kY4&WrI0iK@LssaRO zi(i*F0d%%!Ac6HR(fl#N4lYvuCakKDiuHI~KD#{#{xKU7Sy6|xX_rr6zt^>WDK)0C z>sR?}BH_C|7WH#)F`exc`R+U>Kfp{-6Vx!Q;Ne!AR-!ehk^T|YP@(gcjZbYY(-@Kk z4cdtwmOL#JAwtmmUjJ_>UGlRNYyV!`vC{r{(?b|Jy4=NcGvL|-SuLnUG*Jz z;WC{1#RiEkPHGtDjQNA)$~OEp%^6Mn>SNfv()oP-lwAEZi*l|-G)F1%riYx-wN$ne zv&r4(V#Vh^DJBge6Q&9ZD&>tI=(aYHN8fVkXiUV->KW#(#ds%TSO_od5hs3jTm%_@ zu}?f{{jH64+kVP!vEWM_@Fu<$RgH1)xI!jrfVwdE`;}hvt$j?SpS*`ba&wH3v*joA479}etl_@uJ(zFQwNT=idmh;-6N)a5SLoB6zV$$*&opP_fTAaP8A zlj9fx$fcgzgy$!c?j#XBmoAM8onpMw5O3;+OGr)NkG^((}AWOskL4#Lg)1? zhAh|}9X>K*^t#NmIcUF~X%4(d59B3o!XW6N(tfqcHTzp>$fl*HtY1@7>0LKBb?(v; zHm0rN69c%URE8Dg4Z`%EV=e)n1jX-!<9OW8F|@T^G-Ui^TcdIQ(~4`F79CAP!g-k4 zj}um>ZS1Fs3Ypr;@eKR%L$zcE2b3u)uFz;bk+0ixO{zlU7A9wAy?`xAh9xj^yQf)%iWGd?!y^a{pIVz`KMQFEv&1(*Rk`cl`GMS z;0ye!GlcVZQ7ei!=mCi~-8MfMNJ3@@*(6Q}%CFX@e zp9KkVuZ1$P`;uK;B2PzE^2%Uoy!SDF8^pVas*SScVg{n@gxCHA_cWgO;Vm2D`k1{m z?u06;ZlmOJ%1Ff@WuN~g2ZYdJj_(_H}`lBwDVDHi-Vn-3Lj}W=u z(?OjuTF3z8T|z43AFyPTdAC=wCp@!V69;W#43eopAkN4}Lw*F+WpfF6HX#@m-XSvvG&E z0$h1Fz}keo&tcf8;Th)OF)qufYX`KUPIUgt?dVpac{HfXl>b88&@JJ~q{Y4p-^INE z8uwcqUxad-wN#cn>aLi=VxshOb@oP zJ5c%vsn)@S-bKvT0&9f(X=(l{2}eF7PF4b$Nv>w2=#*LG@swA{^|(g8r=C)(t-ySf zAwJzGGc@_*;Ez3Gej(ny94Da!@~ zhH416;9CvD22n}K$9i*E@^656=KM;CF*l;VFr#dV(P`HPw~vZ)@013Q3DbD<`poET zADZLY;`93Z`L&p*2;-(AAz_7=(VKmJhV_CL+FcL-j}2vgCrJQMxwHF`FnIfJi3B}! zSY=MUc=}#mxB_hP_Ov>xnF2FwZSqFOC2CJrVe841&*#xdfyyyg*~0_=pzS)63Dn#X zOb`C(Ozy24-}*k{qU$Z6^rH5&g)G?hxJz0?WPih_Q^Hbk4h7cOM2|`R((tR>r&6-=EvMxV_%!v$

SDd7ixMOq> z-x?!vn^(bRb+MYr;F)sEaQW_wB&)_&+qlFZCom4wmT#uL4ijGP^4$JxW=Ce9MTmeM z27|XJFbaV`T&~acTbSz&(aYA|^X-aH2ez^_5j-31p(;LrQcL} zp*kZ)McPFZ)+Xho!%vZ?$wy!9u!(8=^GmPTcZP%W6~Wmxm+2T-WUUh?&3*JQDwey{ zuC~ZR=JfY~GDA&H(D!{Upo86obnBaPUICPjQK~s$QUXW}#i#+bLOHr8(1#BUFFvH$ z*xuGp^i-Lgf(}xTCX$SejhSj2q&s$EXx#$c{*yZE5BRy1yWJo2E-%N5D=`0mxX>+m>!opb}o`U8JAg%|S?rXM=NIB1WLSJfcq z!D6?J+;5GZDc+QY1}eCSjXMNqB8@q%qT=AXiuxIHB=7O4_DcRn8cgb5(gEgrTeC((Tvb0Q=bhZTZB#A_PukR59|xIP8rv!HtKObVKOUAE%$ZYcSrD) zTd=z$Z+Yui$}=|L#yQ#4zBx2zuiiGu)kZd2^8zhy%{d)U<6Z9iY%C3n4hgt>2LY(Pk5s{6*?O}qB; zJxVWV^J=-h+69EqDr*v6e>%%jR!zI@A$1XTfLppqaAZUaPYdLy4iEMmdui+M0d`x; z2X!8cr_E(zG3Ds2C(W2r*L(b{{v&tGC0lvO$Nk2>HWgiVMGK&K!kOsk^=ry~&EFm2 zDu+A=U$Bp~JX<|oHup_DFn8yU9<;uvqf+Djeh7kZD2W!pd)f&~v$m`eo*7(;|^h z@tPO;cN&scM61!gx!@Pf2k%;zPN*8sib|$hPjIOmEN_nqZ89+aA)gFveSw!^9pE?N z@g7laH~;no=v?!@lb{e}|I_8mf;j1;-eZIO@jqsV1Qu?WrRy_95l_hBraj{xLdMgk zduKA3c(~I4aY5tx{K0<1c4kdAppw>z0h+PPd|paNJZH#PatpBL8Qh(?66>;pDQU-M{Fj(#;wR%*f zY8rAUjlgW;PjE0=J)9(XGYi8{yqO9xD>oD33JW7sNc#3i8>7J6dQ z-6AGpDPx1F#FQ5&&9|*JEql09fW8u+Hp2nEi53wF7@VV|){z>|cV$&B4S$jPs_Zcr z8694KvU{p#=~`GpS*_CKfVe8UxT3#)$#RzNSXPYLroGlXd zmKQI-v*-7?a+jSAS)`lVO>3Nj8mxbTxUDj+DAlh*MdhWOBEXT7Jp+t>A~lOo2Z`?% z0tG8b_#LTB&!H}~Gd?_T`So{x$X_a2zlwi!os26ZPs?r{M+(cMlV?2Qaml78?EF^E z=hqT4$O5cMAd5FAkS$1O+g4O4d1XwvTfOBw^~r2Gz<^{lPzlX>%`eY#a9)dg{AK1x z5M9QT3y6izs;XAffT(vRw5DFZ7hClBq)RKM7NZdXJ+1Hb?VVC4w;+Ns{jM#V0Wo*P3Zw3Zo-ybO^l5-0|$QPvl zbjpTea@30nopckf0c)Bx$!OR6hbC%x0MO1=Gfl##Lu221W$AR<&xomWvpTB&!;bi{ z4}}Qp8GY?N7OzKZ-K-l~P>T1XLic$evpwTcb*{->klLeweB;}2n7pL-Xf~pQ^MS5T z*gLSDO@N8=_;Ex2i$S$oy(P0U`i$5p(29we0u0bO4MxGGCr|-ShIOPQ#{GPm_ z)Wd|n z99%>$Fm)1r1kW1n;S~aRqt79x(TM9;6Fi5zOgLO}6uPG@Tb}S7iV=MqHoNZ?M{!{MEA1WO2DE);> zH(l?-lD7XR_ynv&>P`6e{dCA^OgY~}*&(;r&!TOG;e6f=+mni>3*ml*Ly$GLLG3>2 zZo?zeem<+qGYwl^?2s78(<=%E-d9!h+l8ze#7uK_LcWQinwpGd0*)=-dJWe$g1~_? zT6Bg;z*YJEzfa z6cmThQ(Gb`xiTCzELa2P7WF#>X6{iMVW*QAkD3_IcOHaHKz(NJFxD2^08IQ?qf)8$ zCo%gCKtZY!B5iV$khnWW6qN;LYe-OVID9$Cq{1D4$w{=8hvVSp=FbNtGDiGN>oD=x zmg!RkS~nf{btbv=YhCY-Gb6XL4i({LjO<<~P5F#idCJ0?^icxu65MvPevYP44ay5q zdkA~9ILAZ)q+LE^Yqt8G*1^i%(yeq7?4mblnnO>x4(32mBKGVDmi1!A^4;-a%~^_r z3@(O4i718O5;}4MA58Hvl@v{~WRSz1NuFp0!sNQY`Y+693B%PUx7lHvM7BNL1G=!V zAJ-53u>2Fti|8i>SvfhOvK+EBW+*0P*MRp*7`em#z0Bv+OF*MsbCCp8 z^O*tnUN(1;f`@of!WYTE`ukNw4@xRp^;S4_W&uKL25gh`3>X<0UPZy6BzorxFPPVD za0Xq%lns&T1=>WD(jJ<18d@v&x>~g#-mi?t^LxbiUurv9CbCizvrA{Wh0L7()@8wc z`f6f$BhTS>ewck=$K?pWOxYl3%|g6Cq^&g?1-APNQNO3*%jzq3nD`V^xj)q}=d+YL zJ^f2&!|=9KjHur_!3X_Z)8$X_oTnaK^AGo$F539YRtlmL*uFdBlP#R`7U=iyqU$GxHlIEXy28^L zu>N0^eFaoiTidlDlF}`WbP7nffOL0vhjfROl!74LA|Tz}Afcpmw{%H2{OjEN-T3b7 zeaHWeamHXDPVKe!T5CURK6B2;n!AYPaEDxdm*X;EL>-_Gsil5kVb zwzu6j(Un;RKuG?AjCgseCobpal(1VbGmf>TH3O_wbxRwRhA<9A9p<^{P;^Vnq#2>k1r1 zakvq|*!2EwoFT0P*)a7asNxfeg(*qcHcx(<9#;t0<3W_iRKmWtK#Tl4}$ zK(zgWxRvQ!WkNWU3zkWk%Gt8MH%GGpQ&a2&33QxU3f~O_l0LV|a`+~YQ_As~|4hlp zZoJ?>ypc`vs&%8kRfsICuF)uJwa%R^&?e@Zw}S&Is{jnd7c za&Y%GZg+ar+cs}X8pC$*1S*Fc<^%CzBW7NZQ}cC25wi0=gZOW?HPHn8H-Dz!T`?xA z3BaK?m~FWedpJ5)ye1H0B=I?kmV>SC9~|6QZKq+1_6^7k$Ddb`84(}V}R+79_<6eZ`<{Y5{)76!owY0WV>}j zLoY5vgBP#1IE&E~p1F6^hR2Yc<+h0}Rvol3uIAm0Rq(OZK1J^1e=J8~66G`tlaq&2 zyE>8Nh+iBRL3}M19WeR|*A<5tZ;rrWG#8hw8l1m`Aa(90+$5LJ{N!`( zbmrP!SDok=Da?$1O}UbY)M#E$FfBs0<+|{=L;&^KOxKusefqm~?h1O6{!>KCfr~y8 zWxqsITk5YvyvwsA;m+mrW^v|=)RU*X)md{7tXpX(n+ss6_j-l>W7x0B8)ci1?9-xJ zR~({wmOB^DGaUA^$YWtffB5XlehbzdQ?}DEY@m) zYh~aNKgFFVr_wu4eYT3|vC{_F0hO8dM{E?}@LBUQ9-MHz>H{;USM5fO z9jOapVL1T(+Ka5rO`$o%z)#!0RQ`J5I$o^GPMq06F4yl~1fSD3dC<{j>xUDpT1lnd zEDd9_v+Qk>8<9st}EEgt**G`e%tDFn#ybSdQHHl|wwLjdt zf+sln7yJ#TL8f@4NU|yM?Y6wq+QsYiY*ngaE!imIyX`kl&0cRX+p=|kmnI4=VusQ& zFgTOM9efh7aQom>#k=2)1a)k@D2;CRL8uL8=?UgO!}0O4n5AX@6!2tu-6tzgsndqc zqhmi9I7?*b@ZkApotrqi$@fGf!CKxk@M~t>%7+`y^2<^%b_+AxeQTKuCfrk;#QH39 z2i@jg_UM7H&+!O5L$GzAI|9DUW|j|i*Od>!YfQ@N=HDa^#7!3Qy&92?ZJnN$b3v;t z(x$7Sul1P{oSOpW4%23$%z5qoCv|GX7TDm%mfQoH%;yAd`02Tth?(5R^!?5m*rkaO zn}p0LT#?nr=7qItfbPe09ZZf{L^g=c`*e2tqB-mqsYrybX%_ME>kSy+n zwI7?9tZ!ecOM3Fn@t2xkx84ohpZ?5K)qvlZt2tx3*wC?nI&I zt6+AUw${gcAosp<`cNF759aE6rahC+tbL`F`BCMU>*I8U1m5j0!E*}YGzWXNBqP)pgvWXkL#1y|^nzG%@~`+;1i)UEFa4;$Bn%y2612Rke9X%(ZG z$@slSV@)tQodUi~cWGC*V0tF(jg<)liQmJwfp^>=OD-Ln`3PWo>3=xhdY1;z9YCoJ zhwU^AqI_;mA1Yhwfx$rUJO&E;OL0^!&1vz5M&oLZ3(24(0i}`E^e4o!uqhoVTv%R~ zWbpLu0@woP9o@EcyJ!gtUWF3UImT@Z`TT@(zp?F>QVQ85Nv*#-3 z#L~*oPo;=;lXxoWmmjLL3M*wbm9Gok^Z2L>IGfD63Qu}E?Y!FYTf;*eWgC5v$D2T= zQKJrEo=6A?R7C(cpMSrNQZ1EcE6a+qTB-Kfl!iR!*gV)fvAreg?e+E-{-Nw;vID1Q zDhyg@()ijp!S5RpIX~aBZ&Ce_LoEvrou1Na);Afv3QwI|NAwz9(4h2tXjko-;v#Bb zcd01ch>JRAEDQ*(xBEjy0_6UZp1+H*{qM+t*6ZGWL+>w*yMY3_!bGvKhJs-m>qvPxY9mo9;?CZLm!-3%?G*>^hQjH&rTnNyS=(Ajc%{fvyo?SzVeP^z zpun^~Y+Uz--MIUT7ttMb^QFZzprB-)$-Lp^vflKro? zLIlo>@SRc-;&n`jsxe3AZ?xEVJp=0x3`uStSUx!1sWMQQcQW9&J`1K>SIMlrcG1>3 zqk8|`NK50~%29BkusO=iem%&sc_Zzo?eMS$(FjzE-Qf!>19+8ym679m*24mG(cZdC zk)=)81+r{eO~UvXN~W&b*<*jV&WEMqiY$j}pV6XF{Bp5U&yJz?SOsiHptn?w{ijWH ze?QBsFd-E~Lqm1HU0#m(tB$*+{rVvqeAI{+&>@Ka+^BYfDkyP1KrZ!%U#>4g8+0ad zyi0FZ-V4#LPCBFq8dH?-68CEbklwc$khkqLzZz20w$0C*KZ~qb3ZCuy5%5K<>g_vm zGXIY<5B6CI&We@nSZ8y@ymreNP8-9+ln%EZiEMvY*X@})64?$qG5}NS>aCEMSL33O zqU8qe@OLJmocZqpt$aLgpnvO+m!AB#Wc`O&9R}j2Y!Ft?2YJ~U6JFF3S61WC^ZxG# zw~)`?tqnDQ_>ZrJK-T|wyv`hn#Qpyf&I1gG4XV3pX9M&5VxzfC90GA zOAOFAK1);(Vc=!MXjzBbco8SW&}SK~*wnH({RCIq23L2Far;5mY6x=C!>w&BJdH^V zoBMuaOvPbx9wtf7F2H(kBa_Pngix`=qed~A7vYH>v#_ntt!i4Hp0!>H7Tg$emSU9C zez~16{Nrl>V<5mM0HX+D3>i5&oJWrysTJ?d)<%?+FoApsM9A{;Egl)*y{py(>=3|w zC=N?)P(xWd)cyk0-_`ttAe*#3Uuv*9i{`m=pSA5LY=WT^xDS~E1k!P+{)^?$)y{`ZJ2q50iogt|y0e=%p4e1M}{V1haCiYE?M|`1Sjn zPNe~eZVvw(rx<-;O)!2D?n@v?5^r7!t+E#)FC*Qr||tATMYM#*rihVWK~nf$1w7cQIed0H(TG&CT;#lL$21a$L(W(TRz9m1C^T%Q#RrB8a{gQc+QX(L!$d_Qt1B?6f$8E*1c`?-`U zc2UPmrW?hdKLd)FIli@B2L&3WAXj@Irnu$#J2YOkP>JRpjj+C&{e&C-rdfYV)jT~A zCNppLeA_llO^d|i!wK!@(6C9q1KY}8W}kCEF>&ip5>HrkO^AG3hAPl!r^c79wCLW^ ziew0VJ8B#g?&!6RO`#jB?$N2RL1DfPP{F#>liNz1~e-^O~Qg zIL=kTBd&TuJ*<1B8XABukAILz*?n!hS!zg#MXC`{oH-qrL^crILyiNa!wv6FNlwX~ z!Ao+w8m|fw?>DcIXzEHw5gQGI#St~SDRBF7dfCm2tR2N3=o+GvzyPjp_<)~)m~+*b zc8+wR8kl*hGjzN?CH>*RS@xSy!Hu4{{fP)x(e6GJvz; z9yA?CT3A~vBet$a^2)t^!Y+j!GOp|FT(!BoJ2qYq{w|yT9kgDoHIee1xa*JXbuX}+$ zt%-Vm@!XuEY1}YFl(5rz5*9ZhJ)lDC2?0SDP_}&pyj5#kTWor@ zqVFl=tel*awrTW`wbVWj&7zpL0!5WxvFPms3|liFOG|NwbRlr(HXTUh*fL>RzwrXp z(=!~R6jG&bLPjd@JxPbDfxs`amO3-=L7B&t-=v*N2Q6MP!)SRZasNEGs zikESGM}Gofmw&9Ve=fC<15$EOM_>bP=WF!SE>NgSH9tA|Nj30cRPO^ye!XfWM4kOP zV6D1f%{yoE!sGMm%CzQAQXG|hI>XB-Vq4SkiHUHC-P?}L`!*p`$jV(X(L$3PJ}Ft4 z;-XYPPxj^=&kM~;lYy&nXZ1~DUO+CDQ7Q87*!KLAK2&_-FMmh1GBRJRuSA`i2RmK- z!jJ;2+G1-3pH-27$ORiagP&>p+?Q!KgW55wQO`h#L`|exdr{4fr*cEDK<6^4(I$pv z)2h~`=d8oE4*xXvVaBblbIn*7WJv=F)#3sB4UNWIe(UCZ_hzXtrUn4^u03)g-}p+e zl5x^7+IPjD5tjU}G@?P5gcb>dW{A~1mGW7eEj4?}A{JOBvyu8>q5%rp9Pa#lGCX{U zME#O>HA;QbpJ{AZg|S!AL$tKOTC7y%_WV&kp`%~TTJOah7KHqUPz$*GuwtlbSY4Z}5C~Ig9qp$ftJ3i)P2CnRGqx6wO@1z;-^3apwR_y z1IRJ6y;$~Lo3dc9LzRqbQ^_H+oXBd|QoYZtc(?oz`u2MaZAKr0rtyhYX^uxJvfvfn z@bm;*gEoD;%FK(E8KQc5lv@5`$Mwj^-Sy#xzbqo zH41G&c3kW%IzfA<1;hT{`fhO94Q;a5z>n&J$IR{zZ>awjoxo?bEfLE;zQ6FPdH+9Z z*50<}HDKl0)rG5XGfqqAs2R2?GdiB5*1u(|ktLfJRdE;V3d~&F`fCd^PG+{p|QP-w(W%8NVz*nhQrz=VM}hZ2E}_X3b{Y zFGIc1RjTpq4PwMV9-Hr0Zk2UmX&L{^=egMVo`M=3?>^>NSx>cgTl@Uvc*HWf8|(T} zr_`)bSLsmkW}S$R9%vD>jcW9E-B+Y4LmhEF6tsTGG_8BM+|6^K)L`d3504b9Gz*u) zRu$>ormCEsM9w3MrO%)4t6Jj1y3xp=-EMHq-kE{a!5x*CI#4VsJT{dObN$qGAiWsU zF+o|UUyyy>MZ4&$yp((#d)7_o;xl$|)j1PnF3Xv)mestKsq(-#3#+*W(1|wC?v?t0 z_T#aXW$nTE{jlmdh7_B=6z{Q~G@*dxuFoaTDc|V3JmdG_Ujs&csj!O$$ENM1`R-ls zcc>JNX=W5N8}~<{aqL&uoTw~CYeNDeCt!DyL#4lAbBp^86!SO6b(2rB8P4VSVRwjF zhHMn$&}fLD^95o!ea`!axUJRAzs!Q(Ridkr4-w+l%GNuQ3#;(yH_vC<|I(GP?cD=$ zlsWr4H6tUVPKbcgXt14f9hkzYJh?=pnbXqJshn^b&~0=L>+j#kKVR*B=cHWL)!iMg z4ANk@*!sSgIdNz45^{2`vnr~pYc+$|7@P9YW!+QGi{I36GYzDO{8C@5%7Adl${y!o zO=Eh!noPr)SfLIO&Asjrk^a&${sOhcOcIHbh*|no$hclMh1b5RlID4OMfYoRD8Ddn zOi`sf8B5BOn3=uy>U&4!ncz{}$MGpWC~J{5Ff7NX0xM7PoTTY@S1;2xW;~?wCJW7ZJ&A57*8_uLiYp8CAS z+k7FPxkivv(e1z4;<2<$Bx6L=ooGhBZh@Dvq#nw_ne$5@DRTq9tqd7k9}yXz8XCSm zo>!{Y1{n&ZYTAiku1KU%8Gs{v9AFMY#CS2nmGABBRI&D2zyis6#I_zdYO{Eq+2kxq zOGuz4=y~ST(9$YOwE$fXLh%VCd;(FmOW{s^42Y#?SdM}Gu3t4*GV>l@!nDS+nRUJ6 zI;W8>VYVz9$&bRd^{1|>C0y5I*k%?Bq_BhuoAn2rMLSg^C~5>VN8}@LoL9TNank)Y zGr-e$a35-QDt6iE3RO^%ssBs@DHUj4W8&RNcqZahwpcOzw6xY*v~yS~sK~nBg)Is^|FivCei&6hsh}gBCksAF>(LfsIJUyQ4hR;$A|H z+wUl9nZV_p?e&sxd29BplG?_j3YnB91hJms}#2b{1pY`*o`f*7e8)9HF2{LEb|VZ(c?))BqPE zh+qJe-_?80$yw;FF-b->pU7ey+fkCAFX?@A*t7DEbHTpQycX1{_`C~>m#{_bP<&^G zu`=oBNia`K2QV8bmCE z&_Yv0*r{bilz?`3n&%+_faVrl(O$IzO|K)UptiL`P3X%KW+}D&Fh~BGpDU9#s9YRr zI@g7&aSk{0`gAwlZ-Iv6#xPyO?_5TaVLrcxc#c5om~1laxm#o8J0PC2W10Fnhv(Zr zS)64bY}pI7MXZ6O(`6M*bY%3QQWQwCPS>HDgD9EiZjxi%ZcZnx3Z1!a5a*(Cm|L|? zmx*ck&TBz)Y`!MBRjehQn5qhY-2p#pe?gG$mGk|HA}e7wAt z2`nd7qCJgXOy4j485~-woZVB+(}sT6!~X{!!zD~Q5%%(p5&`fy$6oD;QV)SCtQjv< z*A7Ye@WD7oT3WieDk+i6A&cv3^AlqPj}yU2SykW)6Pmw~{qg#M+OUw(l4fucsXsiX zkT*3W*ujq|?K?HoCGb0xWxHS&ku1p-wc9o-R*`%#YkE#2ZgA?K6K{dv2Or?gU9dYF zBdz{Kv~QPNzk1L1Y_2pM_&BJ{Ceyq2CVG}2Ak|>Q3Y$@ssMC0U^bXAyQsmt0c6(Zn z)M`upj!≪!sNQYX3gmQ3O3WybMP4vFOda#uId?^P1@RmZg1<$L^8s{Dq&}_CCee zG&t5?#J}Tb;xc?>rZu^Jlpg*p?Nx0*|1vN67kldDu}>Pc^wtTS%OHFmJX5pA9JI{L zV$2>mT4!q?#kNsS+G&0ipBNgo5tF_Mn*^2cp{yqOImuMX1qz$d2s>7B^&G~5&z3ly z8pYu4a_xai_~At0bwkELL9wwaZ~8q?vbAb_dhBvN|92PV<&Y^ae+h53j}6q$(=?XR zPq0(+)PLI*{>P4t6iOR_l=vEsPEK8l;zT))nHt(H-u30GD9>`7wO2?-2Ul$Wpt7cc zav-5Zysn{VXRa*3rx`+AU2}9A&JtT0l^4W@)C1|Ap#%=dn>d(5C6A9KGF#y-YJ;Zk z0aUVIOP~OhdJmZ};KD__s5Eqk5gQVN3`_Vd8S@^M;0^d|rwJw|DAdeI21GBaDVwO9 zd|wk=@eIx}bJiKjG)9*SS=O?L(C{Atsew_9u%te{F(SD@YP{}{w+KbAhQ3_4@R)5% zAHak6^ukzHm|Sb{F&%#dJ?az+q%e6`u6pt1iKe{Ov#22^Wc6%lKeF(&6~^zmP4ynZ ztQEQq;kzdaM%60&70GX02=8trrPl`Sa?;R6DiyURb7c7>+lWj*sVoWqtdlIxC2 zeflI^r?<_}xM6Xg?;P{#s>QY^>ryr!>Vj^)=LGv?^%1HEOW4*rRjH*6;uaER%_NHb zFU#PyWkS5=hAc&H>VcnsA-hIZGq9F$^zLDQ%E!bsSdsq46=;$)mXi=00Vz&aMYUeX zw4IV_TNZ#nd#iwDb6!|Q5UY;G>+==Of_q7c$9RdGj>qgfQRDOm5VQ1rbcW08>ivMP zTUJG2v?A+YfSt%SH=*TKxYGWH9AmOjsrxYpn&BC)RBx3e(wP1otsuHW&928`2ptN3 zGLxQfg3wK+gp{8>C!>8camwMK0iDN+l4G+POPsGB(&_OV3uAH-QeDe@N7}v2sR;I> zgy!+6{Ujl%LHqnLyzo=6#?|rZ`p%#c6e)hjg_X?ioXGEDqT+>B+56?`HLMS1syN3r zC}q`?)Tl6jjhHT>K}~K}i6Em)m~}@I(Pw>X6uB|<7#73z;K#CQJ?f<&Kg*F$K&&ed zl9pivH9%dJr?zfD?ST=c8DU8YGXHiNA?;^Nc)9Zzk)e{kc>N(x5@*eQRgYN_@DO`n z$6~*nXX55IB$c8lnKYOV>Ud=Luy5hs_`53DJ<}<5yY#>zH8`SSV^s7+bR7FKug<#M z!%iIBJrAAvh`ooj|M9e6wNJ%436W1dY+r?1=KzI;WoT#$X&-ZIR1Rqyev~S8s<>+Q zlFUpxbf)+q?+V;67^D_j#K&y(m|ikme5|T*{pi|}SFFyHnRJ0y05sX)9PRY;d;ubIoAXs#RCx!t1@v+mO8j8B5< za0sb3Gi0Pg4JD3{XxI8=?E&@NlE(*8OT$l(CfM=nP*tm}pO5uq-V5P=Q13KKwDLqOm=V!@!Z}+OeRa;!I za+w2r=b>0?liu}F;*tP5Vx0lyM2K{^!7O5SQ-1$DN&7Cp(;|Xkyw?i5)nguZPaJpL zscKaA)ck;aL$#mdm=t875HCDxH@XfY0)f#G?Yl8Pk1 zmL7ecjXHYYZaZ5uVE(oq)X*4HnrQ|l^0I1bCW;kle#XT7Fv!O0EWQT*S93KY`J5m? zr!TDcfEQkYScARU3hU=`PH%$u!$(Lj3bU%j97HPPYC)b-H-T_ePmqF;04 zo4fE?;3)uavy>Z*-VWidO~2KOV#5-VrPN2%5PxhEChelRK4Isj-r&bOU)%^MaGNsQ zP#Smf825Pnh_OT4hDzTysG-<#e3abpP=3CMf~73V8=gT5<9LoydF62*@8hp2Qi3!@ zec8eNLRi$LlP!ELKW;RQwrdx6`*a)jkPstQYJKUCr3HmNfD^rYY~bcEr@ZB0{&rOxM*cLW|nOEC=Fi$A)78`yJ2iP+!L;8)>Ej z+YjYJg7*n(1MLM*a-g!ORnCV6!_Oupw37WPbTLRM>XV`Xnn;)&tbJ5s%quL2hRZ_x zD!E!yyRur!Ek5U9@$(Uzr;bgoynq<(o)mII`InbOhU2F)nT$kFOFh3>L%2irgZ}1* z%sbV*0%bMXvfN!#*V1jO_RRYWIvCg1Z)blAd!pb&FNjZ|;KSUZKBuC3X(8Rf)Tw@` zF!eF`$T6XMpvrQzvm+Sk5!NdQ2M42-&M>-{>8@eZv~Z5VuX4+&hn9A~7j^H=s5zw_ zh5s`Iq5L=PY7%=j=baO+>D14@BlOYVB$X$vjJyn2G`~@b>uS5p6-=iwMsB9%$v(x- zE-uj#%CEc*J_xUFO{bXkP+gn7Wh*`jkH39U|Img(k6Me)HLo=?_erDGZ9E*VwU)5v z9e|T!km4QjOn$p<>1D>4&~yQKJ1uYeq``u2)`W-`iy#`~#A9}m>HYOAL-Eawm@>ru zA-YtfF_1mVQaBiyHdtJ9_Po_IrGbfOHaRYMKGIKzDbt-Wbmhk>4_XwnlFzn#6kNm$g-oHJ{ZprNr&)5{jDaq>4U;)X z-46apy)#O+t*-eGMn|^GWd&PL&g|pyL(+;N72at|T?LMjx0EhyPeY6a>+aU> z4^BX>oq>UY8g_xJ&8JYf$qFOFh=_<|8RmvGw+o&-jB8q>PAPhvaX~yoDu~;BOp``+LY+Z> z+P!SfZUDLEkl-ulLSU(KmZ{TTuNv7Vg{vp=FDzl%8jn^(lPBvfNJ|*Dc zDi~zFtx+1g6fq1lhoN$T;FLUs8m88LyF!u7AeXqKrHs?cU%r`{DV;E3Hxs}jmd@-K z<8g6m1OWoN3MOup`Dbs&hiB296b`KGZkmz0S*r@?*L{XVunQKb6Mh*Ggm8e|^&|T` zS@k#w=X5hg6@7L;PF>HTvJOK0Oh_COyl1J(1K z+Q1GcqyFIY2nf`BfWNpwrq{5P<}&*-+OJnW_FDCo?O89UX3Cb{qj|P~mXhCDiyzjj zt@eclIaSgfUTv{{dsNv~b zmyzG1lbD5k%)R-}&{=-5xf)16-x&d#DdxhQdX{`BOM=&&OLK#5cXeOlFn^dRu2hC+ zfgJ4fk7QJ2b^KeOqZVx$FS zWo3oxb|fYcVq{sNz@nIuQ5K$nciq?CUW`yNIQsftDg06ChAu)2*7J`<4~wODhe)Y1 zb=RxM<9eaCbVY{q&2sXq5ts)PeQ%`JEPn!Q)}6X|6OXVjrxh?9e8G)dyUtp?efr}_w;tYfUp*7D!J zJ(C96lr_NYIO#S1Wp(Pd@8l1Bq6I&C$@m4mm_or#zCPPi_9Ig<$Hu^`f-#C=jos-K z_Ig0(Oo&K-gKXCBA)V4hQz!BsM-pLrbxhwL8%}OZ!$L6|MJUQ{YU8Qpj4 z;$<8+b>3U7RtZ>mCOJu=kNs0WwNj0E&OwQUZOA)DHLEooG-+s(iWm~TT>>0##AEsE zB>l zSiWnh4@-@A(SNl)XnPGRd(6KU6x${Jv!DKX&_?2K;rFQScWaAZ zCYb;JPtpp2Yez8X*U0_R`d{t){_Htlh}j%2I?_K0U;jAm-=7MZAc$fE36hvA?pbk9 zH*0D-KmPi^7KQuUS3IVK-rL*rMGc8}^+hlL+YA5YXGP<|2#Q|ooA_mP`5&DG@kGBN zH~IxU^^27+lmQAhK7wHpYVm3=#P#uoKtwk5iXEKwYx{ZAJyDLj4VbLH&N3y3$Vsf5ur1@wk$TNgzvMpv@*MUHZmu6&2=inX`=<8xCH_vApBXUg8Z ze)fW%|28C}cSEeDnmE4`6r$V9Ei25+L%W!5aIwyI{pR|wqdrp}vVy>@Pfcm~w|88) zCv**h6278dUbXB|(_=uD-32PJ4KS>ASl?V6(%tXXF5;-Fs@j1aG4#U#A@z_#g0z=2 zaXaj)AnR6sTmF@9y=kurY?r`>Bzl1ZE^cvrdcD>AIZ4JHS$Pm9%rllwmDg^k8t=3A zN+LO|wZ&J3sa+=v-$kx#S(Bvg?N8*`-NyKAA#txK8W+v;-QOHTtGWGqJt{mz7_M!? zPEDN(lQ2L>@8#hQo(DDNgFdG)0cI8|NT|`s@$Nl81SLp3t4ENsv>BwJAHER+^fC<} z{PLv`a-X9Y=pW{6n{hJGQ@hf~6<&uOp^}tInGLikKsaQfLr)4p(t@qnR*n)PYA>Xv zc|1AKGOlGF0Ejq_F#U^@00w1rGvM6gd(9`AW)~0va+(yNli{R>fCQ3 zE9c5MC{NkW)hQO~HEYpsR8&;JVEF;}1}T5HAJO6vlFoL4PE6Zt()U1u#A4IWH=a;e z6%BQcFd=9^4kwB4Rz$;9Jlkc~h8(0>R<f-T{J4?BT<26P}r2`5-gDP?$!}Wa^%& zssW0JW=0`wB0QV2)zs7^IY?{#moz5eX?=wh%z02V`dJq=&~E^?{+!T?Gi#Ckpzhb=)Xe_|K_LoP$gWE<3`UpAtrZ>TCs>9l%J|Lyy>k8*8;Gq(!n9jlN+O}~2JH9<0~PWzb} zDZFkabgIhApW?T+wyZR@w6@i}fTKk`lFVZY;2EfE-xtpqKf=U4-AaizL&)!0Rl;Ot zZEcxmK5Wo|0G(F+F3V_5&?cpqds{010fAW~a?%#F7W!IcJtCtvFcWc^r@ z9;0(d9hyM8tnxh0t}5B0Wa{Gx2yi_2c)9)JB|wy{sz$x->b*4aW>8#EnL0gN{b_CN zhX)0mjF`w?t!Myg5!KdBk{A@!p}-|%a*S;1kM|K*uBN&Ffj<8Eb&+?&olwaM07q9^^tou;T-jf(y{2#SA25IPUmRu z9r~K^p@RDs(!TxZHM8)VtA|-u1A=P;Sz_I9E647vYMbdxbErk7*O+o14Cs3ohVD5; zZ6lOdd$#5+{4C(xXI|r;A_Zo8eZ~nJmNS;n;p+dT=Gp@ULMzA>aOhT6Qi5PCs$n%X z9OceiN)CrzxZ3RD;o(KkF`mAxEBfHNKetsQTUu39vz;9p7FIs8fB`r+Xn%8&CnEd4 z0JLlnZb=PmZU)&Zm#6v+#KR@0ijCkkG=g6)g$WK%K^1S^9X7-sXh1j5*;=+-s8!}0 z*yd>G=#J0eigj%?W5?5wSmx+9s(9|*P0D7OjqaGKi-DcDV*R$I!_sO<*9ASXy43SZ zp_D3%u^zY_odIh>%+p4l!&6|HT9!QUDm+YGkUGw4e+ZvutflF*7kR+69q^LR@4OZ= zjr09U&9dA}Et;hQpR5FMW;J}aRtQH&k?wK1E|N|Thh*?vEJ6GhgEhjwm;Q}!sr6^q z9p0>yX0NW_?d!c%d9;vO93(J8qoM>UqEg`gPWS$M0QKwy5-_b1ihOhho-73yPWEB- zHq)$e6X7+3gK_{dUQwHU>!Gf=?1*iF)BEjPx!Ong6YBH{cl&ZlGAL?$gV4csE!C>#{Fk&TWvn)1=zt~6Vkb+nF6XL^>P87!?Wl_@t6~B0E!ExY z?mS(|JT`5$HL#bn{pqdY=NzN84?Ot8ltl!<0#`_=9bU3ODYIzYo@v|7kIt&5iPC_( zZq0wRt3RUzlSOj>@VU!IxZZu7R0k`g>5ccWp1K|FVCI9u>64r4i`f;@IR|CPq=CQa=8FLQLRb83-;FqSExBAx9LNoJMGQn zdUQ6`0FP%WKVK9CV2yNoA%*2~NQ=5uAO9G=$F&EorJqWH#LOW50reX)N8ow z-&UNd=2Q#I%9)?UnMphuNQeticQfkzwuq}u%qK$25V3Gk{WaOCJXD_fdy0tO3vNVH z!?GBiXVSELPa-CQR0PlKUU6qt1y=tkn&k*DDcN6)yQuQsQHT*Az+ro(TRQP6YqiLm z8WVzCIoGh~QyGWUQ>BxBY1V(5Hdkz`{W-(8A#QPOY@V7v@ONvOU*0Z$fW@kk+rNj% zE%j@Ezlt`8%@pa`?)0aT&{v;xDk_wyizyj4s`IxGHa_fDvaJ-M@wNYP+nlB zAv_3s?rZRfRk65X2nQM_O1zUo>K2!u*=(rphBQK=*Uf4C2ui%8YYd-NumXq}Ppw=4EYwK5`#x;df5q-x@Rf=wfZU|ta&39h5e>E`c0M;% z#IqsL62_*EGbxjJtd_MJ6HvTT?G4Dpv$pop+d)R7HHYakuN)A{r?p$Xt8x1|I-U7% zetsE$wE;oLZ!V9Ex0zcmvf|7@?DF?L-rtVjK!be`-yk`|a(5I-siWa|jpwOVVbIo0 zMOD>U?_^j*0}qRhhTBak$ZL&9M%sq7cZ2%IO1P?hGc$Iz0d`5VC@@&(@J*2N&>q{We4wjH~K$e@;Y%12NS4ssXY70>2v^tDX)u0sLV85Lv zg(dd+1`J3a&18cO&0`{H#<<3!KyF}I;xFhoqEtVs=8uuE@A$!@<|E^$D%F&FIkNb?U><9hp7$Fw|yDH*5u$&qlu5?);4#x! zEE~dOe~nkvX7%bg14qk_&gHf<6@kaHetdV^qV{MGLy={IZl&1LLAuY~4UH%S84)OH zEcWFm&vk$a=~@4Z=X;neuR)Rb<8wv~u-cQ~j-vRELfc48zzVPeG5QES4?h8W7$&>= zH5_WUo|-=|=06WI^SK)>Coa_9*MG>CU&Ryt!d?v(FZoO%H=Q1)V*c{jT3OoRa* zC_>$|s16^^ok1KNXOh|5hM1U`1!T4mFz_J;owmlzb@E-AJAHu*=e>;aM>ZEt)}rZe z@xgtuyBLYU*Dp4w&S@5{Tgo}Lj~uo9CU>!l{Ov?QA)=UR5=r5UMx5Vs{{y(}DSEi$ z1bUV9D{Rd7RT&7KXuI;lZ@&Pc$*DOm;p{mG$vb_{=gn!i%?6U!G-ho=|MeomLMFQB z;0rxHi-(0}CC6BuHI+`*+~$LXg`3^)2#TLWGOHpXuhn;|(nX##_Rl=InwY^k+ySxW zXU`ZwXjXJzI50%ng>5aYoOcK&az(=?q6d82P>|HjDlVC`&4|{s{J?Te*WymMIscfR zPYH4tm<(1C1kAy+#u28?K;k9rrJAetlviqMyJfFG|0{OWra%s%q)Z2`5g4tzfB4Ug zdXuU{UkE*O-ARB@zPjGN*LTl92tow*pD+8_hBScI0n9W)=<;v)YUWSQd<=8;Fd&)f z-3B6h(ceodKUS7?cOE)MQu_n#reu z4i~x?C5^a!vxbT;+Xxc+al9Y|28;{K1^`)2KUW?5H!&;}BOZ zx8mHaXf|cX6^~sJd6S_SILni;#n?RV7kzf4%7Sktq)knxpf)hCf^B?{LY`m7@Op=d z{P>b>diUO{caT~5IW1HRTgy+C(%C!{BW#kmJ8P#^PK18yNKoO)hW31QCZp9aU?(ZY0T+tp@9Tv#&W(pjafMf#4@3* zzGhrc5iLZ~H<6+FGHmzgpAQdXrDxc>Xd?v0!r#QKVFhngW}|i*n_Kg{RC8RRG*?#p z&s@&geq$uEli{1ObakJaJGR(~;7rLr_w(R-$Fpxuk^AhJzFYC`dpQ*|J#R>N#wi;x zouW>ybOeRu(^mJB zS1B2nw8*pfI&^udqQ$&|*{7&_BFNTyJ1*DdbSP;qbnOi0dq?ILLtdz(y|aTkEYyAp zLMCQwKNPhGs91Ap7VGBUXRwueE}*5B&y3%+M?8=*sj03;)&qIe|2AsQ=wM>2B32#4 z@tLq}EiDg=S**rrK3Q@CZe2%@ywFth>4dhgCb}huBn^Ifzois6KOJ-!>36l-r1%>X zIfJ-0KQ2o0Qkx^i=eOY@j_}1xW zE+_ckpjpp1$4}hu^x65IA}oe}w+hVfF8@3)L_pFw7^``|G%k~9-q-&zZ4ws7N_xh*BVVlPfvZ+jAE%CDMyARZp{~TOzGkP)PoO{Zd~Z!Q3*1Z2j-6#BVL%gg1FdBG|%!hx|6o(9@dD6_CRX+XIoYhr$f=5tx< zQEy?s!PEu(XmT!{oBsWWNcC+7K_w=#+l)j!n@ST)ZUvy)_dh&1U9Ha%CaPZE~ z&Ygr}*@&Y3D_W#apdWbe%~TJETcnd`f-~hu`#MOUm9;&+KKhhR7U8G7hDvkkWp;kV z)Ih}qDZG@o3YNb+x<;7+RP))4we!VtND5tWaBz^kurSGo!9x^{K3eGT*S~$$FaJ1@ zXJ+fB3R$xJwH|Mhz$^HQkbYuAj8S?aD3vwUhDsT9sLtQFX3X6GeWM-zc=xJ zzm|;)<-(Al=Y8$7lXS*Cb^tX3wXX`#z;}?@yzPBr@>kpcJm=8hwz%Va^uo~f|K0XZ z|F+qTlqcf(Kf?2JbsaA(ZT~M9%Mx<2p1iRA^Jo5JV*KyMLY_&W{6DhZGOVpGiV`mF zR@@y56n70;pjZnOin|pnPO#u^g%*dPp|nseSb?C$-JRl4oZtlb^3M0n%ri4T^C!u@ z_w0N2S$hd`(Wdq2IRBr2KN`!_{XR6Cb)mEa!yOGz$z^1;CO zzAyWKpS%29;&(_izt5^C`n{cSzZ}AK;{^g~gxR_@USB&vow~!Q+FBbYiG3a6BN05CpMFQ3!r5ta997MvMZKCU1!8{iTo7>S=2dUkQT8rp zkp(;ZppgrmKjjW{0P7!QlAW&?qyzVlMU$ZE)kSJ5>U^vIgXnRX44Hym4+9|I>1Z?8 znU^fz-`@)Nf0(qI9zs2|sa&vI^Z$lQPEIa@48vJ!bfuNOn$b(ERQ;bdQE0(bW2qwhcolUFvypu4#N|Mb zF8k0^1S?A~Fxzay7xq)c(W>M=qt^gw2Yue)3$T8lbV_Ul{v&Qi8kq88U`M4g3{BGN znwVPyqh%#w7~Pdq%|UHzQ2G8Z-jc-)3^sfz;t(XL^@BTc@o@7>%loi?nPq^c0$r<} zA8f!o83J6Por|*#jnZ8iO>r%nT{a1r9SPK&d%8a7ZU2#5@zx)>9U8}eNk}^L9OO!Q zJif6KR*0I*)d{uuUzY%8eTPiAUb^qD{_gh23&zTu>xr)=b863Vet&HzvEJoa{6F@~ z;6!APjuM)gnTfTn%;CP)CMm>BmMa@5M*q1J1qM{3lT2G*lG{#|@8+*5wnx^hyfKMo zk0JE8(@WkT`5HfSAQO?rK9^sHD4lG(8ll%elXy^r!#V*?d8+VenD$n@*u5`S-O<{- z@0)FfpUO}HhTuRV(MIpdC{+R-S`WkZ8TFL%#Q=I*4JDV&h!F*(Fml9OO`BWN4lP=5(7i_!LX}vNt9@decp{$_jE8DL zjLab5C~t4iN7@ws)f-Y@s$*|EV2=9n;|B|N>&;qV3I)HpOOVP47_d(4`$`&kVatAu zE`n_QA76xxozUIS{(FXqI}`e-!ofKa2j|D-Q=|1AiaRYnZoe%o&EV+9rs6RMqS{5W z$32cglL1ndn*=##*98{mogyy8tBp^>(0W&iQSLzS7~S1x%SC;=Hj^esUiXCatU7;)JbRZfg=d1%Y0Vh~27r4F=B4gBEeyOQVZA4PAV(@P)Zo8SEO zUvbWI;T>}-u3-PUKl7u%LO}W>T2a~0)Qq!+Pp7_f_pxuP2AaDGG(Wr6=;~4)9WU6S zC*`wWu8eIt@`7&~=eRjCnx+${>~??KIY`2qODpLpXBp&8jDH*qr-$&UpVVdy3gy;3 z9G$ZsbRwVpFi(Pkn-j!BX0xsIqWhu2dmpNsBP7%)ma=@ygd0js(uD~}JVw9OPYIMn zWdsCC5t@OKYKJkfga&$8RpO z*Lvt;M)rOH-+h6l7z_MZ!$K0=Vp^f3!KD;>q1S6asQJa)e@~=dT#e>mqK-f4r~0-o zaUbL|A|mC?gDq0vhy3GFR13n=d(*UmgeA2IP0x@kK*g)_mVSS|?9?9)ORx|=bj)@j zguZe->N?M9Cm0TKI3_EeYlv)^B=q>{624Vs8q*tyUUSV|eIV(N-T>Qm5Rvjv$-zqXhJA z>wBzw1^A8TE`*XV4cOULcAu@^miAN4$YYJeuZgGuZF>U})<<{scM>e$qd@_j9f0Y< zqGRgS}|DEe!Vf~V!Llmf2Y*tkO3|!8chvVyki%au~ zAQR!Fi}emfRTkqNLpa!)*72{6>LMw4joIEWHG7n3EbZ*=(N1S?-mdbN{@3s9d!aA2 zUhLnK&(n50sk!my%UuW#4ZD?exZRS8`cTj+9;OyOK|VJLTX`-=5APo@p|SQoD)it7 zc=oG%Uw_BiFBZH}-d0IiX+M9dM`TAaKd#Q>)C3KocyxLsj~=M)hn9wj$<`fv--Ee2 z3L~P=0M}GglldB;Wp9#s$r9DU-^q1f(|wu5z{@}x3$O+bEpOxNO3B{D$9~~o1T(3K z)g1mesrA0W(m`hv&lBPh#EAA=sl1~F!BEadup(&HpUX<=y{*cYcL4C_{iT3K1b74? z_H8>-eD^)3U6Bf|?p2+K-#a6>c74(QD8}e52L_Qu!ffMzyE=OWR;m6VAmQ_?ICB&8 z>eBoKZCgtnw9|!1(6wm1b;MMOj@9;iN2IRT*fgrOf9j`Xx%n}hBVGa#_im> zXzOE3&r~qvxXVrcb2i^4shQ9AA1PX5{bl27`9*m^t|EPqb@w01!`I1lmk@u9hwWwa zW$h120if|&Uwpwx`U3bh4@i7-=6>31L)ztWL+9{mIFTrFCMcxhljayC_8h{U_Wu`B z?;R&xQ<|y(uVnPg?p~bn+V)G$nlMK+oXJZ%_c1}PnQH~IsbukACKSY?9h=klo-vm^ z9eLuTC99A&Hc^?ssZ3LE``@_TB;8^wRivK@4%S8>90R79*^Xe+SudP7Iugqqq;qq8 z&3|;SBFwF~wh|X{brKRyXx%G)k5u*PqSocx`&94l8&&48P;gjEj;4BXz7J%C+vH0( zyTjHN+8QwC+pb(W{IqSR;s;y(F}#|t=*vZFbU2;nXFF{=)|nTN&clMb9`%BR(%rm{ z>7Hwx_DI~YY%5gd5oHn3!>ffmxr)}Ly|;9yUgY5I)Z`N`pL0o}Y%R@O^6@>N!hul_ zwAudP{2>UP%Hkcno3XY6*N2h2?~~0YNGOM+9XOoUt0v9h*VEAqda8IW*X6oIa2YVV zMUe&rd5?NkE487R!MoM2c5-4eC27Ea*T1oEJdp?;icZtr)fbaq=sLTb!M71pz!5En zEwqN?$r9C8rFB?vD{V5TfYTHkHsJ>IPo5ikFPxEXY~7(McRU|9(O_G!>?lz%w7l7%}4!zC_QkA3UktQuxK zEwSrdbD3#-0k_JdL_6gz!(QFp%%w~Ue&e6a>RzCIUF~5(GChUv9GkIK2Ektca?B0(bm^}plbilm$kkNhp3#i~l|Q(%`h7Gy2WC6!vjPi0|Id;XMsszH%0eA07}I-tjlL(Qy;L!<>snXsHb%!1l-c12=8FvCjBRvNIaSfUte2uTI z^a@O_q10Zr{pam}zwI{i2~(yfXJT+%G*GJVNHM!!Uk?N-T+aQ#G#)b^$dYDC=BT|s z-8m+g^_h%PzC?YucgRvC~ZW*mqh!LIoS>!xU{Wa>keqcJmxyGeA{1A=T!lWR$ zI>VUSM2$5?#TFywQBW+D)SRB?{Ngv|F zMsRbN%LD9B$Dr|K9r9YFv?G0t@#sBO4sjFv;MJiz{wm>LrUxTTRgjV?E2W+NxUlM} ziYP>r>Ew)VLzH&aq5!X{A-OcyAh;*5I_Lu&t}Vs(VH}$6&!@SY?OP*5i8)HGlq$IK zqWjm;OOAa-6XsRK{(5h&50g=NsgFliO@vqi@UQ?BzMSDnVE)N6fROFo#s&)SXGR~t z&y3Rfh&Cq#RphF-8`_k|VC|h+ zaUm|@%V9e0o&^uH$eLk3zX1hD#Zd2vzbo;{cCQoin;!`Xnxa85y8bS}EnsX1G(*#I4kTmc&;6#Yels2_Ji}NpG_!wZSZ`bCONsd-jy2BW(sInUjV?S}}1zc+-v zW+F+g?Z8p5)HnnTaWRY|lRV&D-TsD1<}6eh8OwU|iOn?lwDJXu7TbVB{&rwWBV%is z#yRvK_K0hN_muj}q=)8H*n=+8CEJ7nc1^*zZ6QPc-}#0bRbUnVg48+n^wcX~V}V(Y zW&Ms4=lB)it}rB;SyBE|u9i#^xVU74z-!AsQQi`Hq7nhl=#Z~7gFrm1>q9RcI$!`%Mq(oIpf0{Vp+p=ekW z0y6>yyT)DX0cX^fH0gk1@>8B3EYjoo+s_ZaeFLfoKW^MO+PIzwbHgvwlYf~Cn`be! zhujm$#=l)9)=IkO!#;0 zH_iUStB{2$di>`T<&OOZnBp0@t+nD>S^EM-L3qj$Kl}T`H*oHskd%0{DhA@$*U|Tn z?k7Ta3L>31tH#5<3}Su?m%PT)YMJyFDj02&&IvOO)5LuoVsed^_>*d_;#sc(b00{; zIv~nw(#y)PmZ-*QrzX{;vz!9Y0Ig-Mv0JDdt8J*$#UZ7u51I?H7Gf@l=ktRq5-PWi z(JZ?*h4#GR;6scr!vF8Fqv?G z!X+na-A;$jc-%0ecqVQSyBl6$nC~N2EHloS$e3jcuN6e^Fk_hzs_TD!AORy2B6lj! zPd7WzSZW_@UOnj|h$Ow2@!>no>rHLYG+k*e+*=4U6Pa>bO{VZeG|zv2%2H)%#;iVH z30qVgS$C}KW^wNe#I7q0U@}rRH!{$1prdLh;=&6bBJx`~6sW*SPhyH-mWcVIIe_@v zeXc*|96zAQ;V59i98zi~n|}Em&|{=ACR;h>m-MA^dm-0H@!$2e|GIPQel|OyN2J(i z*hjwto2h4>@(+5Vq+^YL?}vb9{@b4|rU=;zE2+(=#tMXeTd@J#Mj(Obw$fFlqaN*` z^rfrwx)*Yd`Wb>&CrV2jORJAl$qdKx)1)CXf+^a2DOD{_O-NmRHo%dQKYoF#_~_p; zZ*=POXgTNIuk=^KYb>6E&k8}D+yXj}?K|t@_5<(ze2s1aw40AREyP=GA%A>!voXd$ z`D2Dw?=X=rPz4I5#XBr%%2IM5o6V14JiA{avL}&+>}-+ry7HLR8%eE9f*f`J?zp>5 zaE=%aD=*mfjW!*}c6cdJA*+T*mcQ*h6V8zyHV%ha=B9%Qg*dWnn*^P(2Knrge&hKI zr>pamq-s^2N-1Mu>k#WzWUSzlzYU;KD2Qp18X5-gf7#^dg(e@E`jUPyF3*;@noIu)+=M1Ss0%@~r?- z?6Yp@{vXpgyFStE4e|EQg-Gnyx`gKHb8Tk~EXmv@rYwbbVc&6=I^9e*^Ef|Qk9{o| z@8S1aQs46vvZ3rIyn!;_@y+w5%%iycTefz7*%%I$PV?$XiS(Uh*f>cxSUSHyb_+N_ zFA(s+ReL`I!rqMz2C?vFi}Ei%sLsonhV`n<%j`AP@XyPvC@C&%tTn0otqhBbOV5+= zC*aSCrrfTydm>YtNXZ(NkzCiWP*MS1A9O(uPb5cMS3x1{Ty=h7L5)_-C3d19-BZHe z!J*aIH+H#nwW7S>ZA%NG>eB42-B2;U$X>BJQk$%NeX`ohx=HgMi6Cy1GzU(z+bf~x z*t6o@k`JcJJLA9>nPyR7t8d8N*d6E1gm&Hgz#qT=kX(Qr6+8VX5?H%^dWt{I_6V|@ z8og|7un=)AJoX-(N&BWhE%;Rqut6ju!ryim`?UMD!$D0tGD0k-Ci}AI+kB3oQpriV za0m7DDdUnx)R7@9>mqvraoH@*0)0_``>ik-2q!2tOYI~Yk;O8nd#^LpO_z~X7>+ae zabD{myQil8kJaL~R!lF6HG@9~GIRH{xDv-NdZ=W{+k*%tv?{6h|jaAe4woFx{S^{w0F$)qP zVJqbnpz3lxvg9Qvert}BZBObuVM*OXyD4pCqk$a?5-!T=FFnMO%h8%*P=gR3T2t0~=W1$HLKb@x^M^_5vB_~c z$uFY)uQO!SUlfMfR|{**iT~y|&J%FJ?l2%b!9yMsvpd#_KRJ21l|tsU{aiZ}C?^sd z?a0=#%u%SHK-Fg_UTU8^66p=(eS$!+F5}s(o0PL*nwFrkbKc>x#4_O&A@-+##sIXlFdB1DA;955ZHQA-bux|w&!>(~Un&GQ%% z7t2&wqQ>DLP0LSXJ?rY{5j%K0HkaNM+cH{3Yb((Mv^Q4PwDKZzmDG_o%Lb+g{WzMvdRCQclRoEp39sH35~F zBVq7c&WQ5_-ckO~fQ0VD6z0InPlLaJ5}9jjfZw}Dlq_9^zktE5yBimwjxm3CaFv>+ z--{C*_;<0WVgAYK=f^HJK@Az2UUhwT>!=ZEQ+Ng86WlCPipd#A@>}*dVi+MA83UvB zIHb2Yyleyn1kw9Smq;(3a%QFItUL@niitKLT(Rs{VRkw?w+kf^O}UWwKXarK8Uy58 zh>aw)rPI()nkYQIDLP)LJUx zOULuo+YQlZHA!Hvo(RmbefdVNj3@jDdw$4ftOGV9z(`koSqpP;i*teny%wj%cPZr| zu|^352A`?Y1*wP(4SD5{+IA=^*sgRm7T7@XR0Y)oXKD-)KREI;MivAC%>L6M-W$8I zwMQg~N#SUxf2Lsv$U4)cc4@$6zY=n3a*q(&WGqIgAd8xiJwUVPY4pHhPT+`s> zvbHdMy&@K>)>L24I-q>2TO6)fy%o)wCx>{<#V!cdGc}k>&*M;TCYvp(Zd@ejXH*H<`obFPLC%rXce^ZYfd+{$gqmAB|Ybig-snMVRBn#A_4h`tmIPj+Ipt)UEu(aBHes zHY>Q{G4ApDoG`QPf`{>|?`*|vUt-0!66+zCm=-QD7e^0}B*KN~Nr7rDZXO0yHlh7T zI49P2Un%(Y(4keVaIzXKnbYtN&k-{>00FNbtLKW%8%|+#Qk!#sbj@e}AZPoM<3p(# z$e2@p0Y#WtJ9XOs1lRzri<@+~jcWb)H(+r|;A^k2oOw2g9o z^qe1x`&)nFKeEwkk|ks?jXnHyNKBpxm5CaEbZ8s1lp$(s$=yBwofIgNW0{0@er*wS zx(IPDx_YF`y%@0~ZJD%{cn%4LlIjBH?leqpc@cv{?vp?IxHM;YSyDy)*OtK+=r0e5 zkm&VrFoKrA!dIXwbV^b{L+O{Okp_TY2GQ!*hH? z7sLSvaw!?}in3>0;+no3EM`}lnpNJPw)+(-*`|C)>JajHjM2ozDdsFQgE+xnMve_( z=-qGRf;tCV;}2Mlv2T?2cNA}fF5eFG6p{6O@JOZO^#v8?GeqQ+|2!P6sj-a!lL#2 zOy}!2`o|X3s9IkuhOmzj6x^{O6ErHjsfOJ@UdUrx3{R@@q$q!b|58;KK1c7|fUoXt zlQng9SCK0UfVWklWfw<+OYVABMA2uyQVopI%msi#QWTIr z?t@ySo&-)vaf9f=PlKvrq&Hrxa^5P$WD+-#UV1KGvI{vmzE+z?{|}RvMP(Ej5kaR` zYY5LXxE~7afEfBR+D*AIdJFhu$BOt-Ou8NdY<_f}QbBLS(b<@T_QEP7cC%80zf&gp z<9^~_ycE?UHREknih(UE;Sn8g5nPEo=YbX`gnA{`|4L|T;C{(Gk_gayMvj%5cYlrj zjLuKH#n^&@h9x20)E2#pDw!cA5W+e?v&=m3$u71Vb8&hnhBCv?epITy(SLE14n zlm|t^UD$@-1ceFfOMA_T-Z?ey2F-Vv-&Ca#C{O!ONqyCMUn6{()mD|22e@;Y@<+Td zQBhSisT2c0xsy3I;b2MtR(J&VxGu;ZvX@QJ_gK7+r)*S}iG7it%ZT!iySD4wl$4ua z#=$b&;WbM1Z6cn13gmrzR#36Cx=1y>0Yh+aM6$oazs#Qz>Mzp&^z=g{E!+Z zGoPR_XDxv<=YHp=sWI_Wk-IykH`B;dWToyu5CcE|3~)DWqrU_us#l$g018FWl&fnI6lRUi~Mw(d4!& z6`rk?H6J-MGeZnLasdJNd2)`H8WJ*iw=8;6J1aRvZuOCD6eb_+wnm2nr=y7?yo1c2 zFq#Y2ro>+b7sAGC68T8P_VdK=@RSyR3`k}O^kVsq7oiVK>TW*FoU7XO8y0My-)k{ zV`jCt6sQ%(qsE0yIUdIXAeg{8h!r7Zt(HJdJ7CIjTxj&-CG`@YPxo&6wAhF=WFkLyQpW%qR27-*oSI-hjnv;v-p@ZN_6*Q1Vsq#L>% zzjY+Vh$H42;E(Mgv!PtC2Lau3C*LXN^XSmoA#TEMgOLe?e;+)?ZqJe_gOVQ)ugs37 z1v6oRYZCe%D%h*22?I^)!8qa#M$Z>3OK5<<>;WEc{3R6-A&O{q5$D>AOdfky_JVj+wVxzdv(Y5GsO>>Ia4|DwM=Jm!vGwxbw=i?CTaf&m*!CWj{^7Qbg zCG4N{(8!+UFs0y--F?evWL)`gr`cJmpXo=M|I-TqH`r!KEAkxH_TWg06&K@g@wROo z`gqQsk4=*qi(-)6sj&EleN>$x36jr2bt9v8M59Q8QQ_K^E*!~YE#y3qfsi1LD z*$q?a%+FgLjplmx3bJAyo2jY-%UEI0?P+@X=h9pU510x|2<~*A<$Spsg~Yo}jf?2$ z$!nDKbeB4UUVKDXn7}{mc0*b#8WDmX%sce7sw-Eyiv=u!&bH;R#oofNl%9mN_sxto3@?6Cz;=P8W%}E- zcKtEXCxyKmek76iKT`9KVPeYbZPJKA4Pk}?B0KP3r!HsAd)1Cc$Y<_(8GP0+|KSZ_ zy!iw+Gx)vRD9>NfUrw~uhMK?`M9%4kWKh?wj!*&R*#klMgd@R&X@6JqE)Krm8jy3* zfNDMX#%%E4>=)39z6&~1)qH^T1FlKeY_6|Q|Iap13MrINN|9zuW{{N%hmwMQ2GBNq z=ZqZA`wS?;@&XYaA@O$EB5|Mw#c-iX+wlTf=x1iYx9|UPZI+0M`>!TE13hElr~fq4 zLsZL61)9e~7Av79POGB^&4wp0Oho-b>Lawt-5js`$c?v8FdvTQ7Z*@dnvG~X!FA_HwQb2s7|Sy`Ix z#mAp;lLpo&ZT3&25sRbTTOiTb*&1XtY+QROkm~mS6=iE-d+6<6+9FXiZs&2gMhxUy;CtrigCt_`Yq6 zq{%$fciIcNe!0|?p=|UfrvU}}3+}D_doZidXPl89FPYZxFK;GdN0#){ttr*1uq$z1 z;DZ-BMIyJ^8~Hj`#*vUl4-B#W)Da+k zUHD#v|MM6ITgN=KY6hhXhvXU5iG3scixT0uWSgUxwx>K0L%+E-ekV$OcX)1lr|*FKlxuBKfJw^t8_MBuL5FV!DWX{lm+e*eRMR3H~(2x zaX*y8bGO=aB78I|&UQJjklmfvAEs{X=cawjge>e7xoNQy`95odva zH?dzVGB;Gzls-vEPl#u(?!WW}(*%|? ztCqSxEG!spx{a82!Y;3QO+M9`wBnk=ljBmOe3#pCKnoJzeuX@9WY)AI=M?DS13H$l z`U>I7BoF03sK4Q%I+Ilopo|ciEn_8yqBYiKotvKp7f=Vkg1;|){m~vF+4EThE&kHo zGPjRQ{8^iDZgYovqoVwHe_FL-Qx=JCu(yU{>wu{(x^0E3jtLWYs* zZZN$VH*<>-Vw*gTw`x}3fGUK}F|O{;ofPf5uN@k-MeMA!uC3ZEvAxBYGYD|c@1kO~ zzpG8~eG;W`qV$%1i`$Jp%=fcx^;eYw7b4Gs=HJJ;?qiMs@@S_&`~|vNjbhtrNM0l0 z!TW(d9nIqT&^W-($gFxP*fL`Q+Y4h-x?xwW+61;Q&P;9{p4CsM zOunv1EZSYP5Thafa9?lr7{mRY4iS?#LtMnzY-(-eC2oJ%P~&8#ubcL|l?$96nU-w`6NZIrF+=glEnhWFW}39_7|TxE5dM>gH~Q_<3ByWC?sspxAAjK$1-`;QBY_QOD|Coy-S%vlTUF< zeaQ+ox7yVl9WqyBWt~3gs?pt>N1b>zI|OX}8$j?V1$xS@UX9zJb0mf+rBS!8`^(36 ziPNJ)Gzm}+lv!a#M$v(ky#-&+)=APDIEztLjT@!-Gg;cb5zK2Y>;BWi+Cn3fiY3G> zA?!sv4hfgJ@&8x7RRSmE-Gg2Q@mu9Lf)dVOVqkj#s4JZd7%3{$hP6~!BPs}TvzFVX z5x7($|6IZjGzU<{;&75Av4=WsAp<$07b4tT0s2VT3#MGym=9)C(xqb&Zfr7`Bt4?6 z5(05<=m2c3&yBqjuN!^=QO%kV0huHBh)BQ`63Qg1^c?=plW0Jr2I=8mE7js1>)4#t z+9)5UcV*p=s1iOndjCx5!bwieU+?s1{a4G72u6C={IM6B78hYV!`^h)n>k`K>NFD# z!&-Y5Y&PszSVVN2o#wk)s48rM$w$|x7lMnxjE`npi|=r|zX{BWPMlrWlh$T4^}~*x zgQcz|K2Exp*HcevjGQ5vk^*KDyNrDj~vn*UXmHPTfBhvmfS|!jqWrP6C`_1jm7AUnh8Gxv27z zl!(jGdF#WNnBFzkwv1Pa9`{jsY)?CGQ@gDEX$8LST%NO(iL8CJ)DvzWLO=LX#d~?S z9Jv4bTA}4Fv?j77nD2nXeF_wV`@hhDxANi6$LfZ+8>KC#~rOhcGf&%*u# z8ksVd=7msNb&eY0cfl`$aE(feug6UbKoJ|xqvNVZM{_TEP|^q(6Wa@(L%NRWvELDU zn|mcNg(|#`c!eg(y33xl4t>`oaK6~hCWyEz)4%2a#eC#XN^5Jjh!K>O-;osUSlN-= z-v=D!7nt-mA1|nF;SG1TPA_Fj%(d9ONBDExM1Iv8M3T%Nk`zX)H;u_807kO$)am6i znUTt9R{fVl7K_tCq{h#=f90ptpp0Vrw)m!y{0UZIz z7WY^6FQELdn__2ks#a(fa7AScEr_wo<31cm6Ig_0-1o6sVNG0i@SwhX>&t|tDSUfn z+CzVePeI@HSn9Tll#7e&OJSgC!zc0$Rw1ulO{EoPLJ+VvXh~fb$v2Ld4pMG-d}u~l20tt->0|(W-n7bKY|ZK`MCL%*Z1g{T&1)A+ZSMT}UqQo2~O1F%7{ z2*!m~<*YAUc&i$YQm}Kx8s`$B4fcVz<77d!cj`%Y0Ta1Io+v`x@w>@Q$$b&XNqx32 zS=B4|11XJV2Y;iQzOPN@7JXg8be#~I^8>lG#PQd+A5GeRP2!`;-RY_?Ey6CtJ+|_b zQJ94L$f&0X(K$!P!h5k_GW$xq+H>jOhO=@X^ze>Cs``<-O4<9}7{qv@9bN8(=C_Y@ zsr-WCL&k6 zIryCyp&p=A*-F9JH^*`%37a%8Lr&$Fc&&;FJ0kL3GVy8r&+wczAO(1W(OA4%cc*;M zFxl7Qh|?-YVJpXtogImeayR>U)Hu26;$`GWX<^yHnBOI0qvhRLOY0y`7bT^bVr?y< z-j~~0Y)O`L|KvWI5;A=MXAIg9VgM+UEPb7h)+Fi+|XCbw6DIKN=+&FDthrb{t6>@HaWRW1ittC`TWXKigccN zwv=A8-x@!4s=hmtezVz6zSkY$T0!;)IZ|dWr5$n@e+y0Yd z9Gd21MyZNE2UbAGgZhIpCwZw6B^b177L-g+NR6MytL7OWqw98nou2>g_!%&5(q#Ed zDXTa*s{_3y^eK#Iw}BT48Ev+JY_+CE$6+jkQ9h#@<2hJUX4tLWK&x&-Lp=L9yt|Iy zz%MLNzJTgYWHGf-l?weTHA8hA%My&h#lzD|LMpv~R1?X%dcHL=*-osgs1P*v^@Z0v zjQf_jx7*1Qv{r0%TE)=6nJ$MrD>I{X`HjoosOhI5@tHH)&0 z^M^MLZMYMBRJ?W&{@^A1WY=~zC!Qi6g7ycr#*TP%Z&bo?Ns++w)TBj8i;CB~g^|Ja z!=Jmyecj+1?Um<6Y&rfQw?~JKdq1q^nmD|gc7T%e38p&T=qrzx`?109{Q#JLK+Xjn zwaLrhe9;Trv@O8(Yf$p~d926I z5J~Lh8F%mh3eWeaFeAeUP@h5ku+z3zwQdg1`cs4DcLj_#!H@3G2&4=uxC{d{B56*ZoV}|Y3`ET!ARX0O^MGW2S zw$wC@L#dP?V7zo7~#YTHCk7w0V3Wi(BgA{g272PteOss??XK3$!P8 zqXnbdtP==sNnwvEjF9#v3NPBCehN#B(VuH?`x`%x=G`&|uDIKjS~6ZgHz6j^kV#sfr%S1ts!Pm#o%iw9$=S`?*Lt1da|)}VpkCps?oeE6$1Ia%gHP26c3qUF74 zm)UZzj21+#A1ZHWSB7GZ4DE%5CNcsF2<2`q#m6;%he6T4WYT+Xo}aXy{*Tu_sGA?$q{Zo&L;q49`Wr*? zMS7{uX_kB1eErC`(F?%<=={y#uN6QSM93)lx?`z!;ozG{lyWT7_&IPZPTGG|O z=GEEm5@&^~gIeyL`$TrBE6x0vo$38|zEkf+LzV7@H9qZoUL)Us+|V5y*Mk zd!v_aO1@STlH4#E+T!X{*`i1c|`btR#`|S+xS!Ks|?8x zxsl7wKa(Jd_**Q;i~Vtlw4YHG9xt$bypaG|-hZ_+sG)_R)sT8L4VYVXFmUwIHK3G_4RPo15DBWr$aRWUi9z1P#9$ zzvG8K*1=z-=a(c^BMEH`44t;suJq53NmkRpR5ke%zMH#zNuOYn^)t6azi#F$mZf-K z%cxA4Yw*^+%GW&7AE{UT9X_~P$W@!9E^BJD(s7VhM%z8k6j$j)nRM3*+`yW{*!{{Y z*i-+w$jq!a9<~1f+6(%!^!wvZFROUc5!h7=jnRaG$m&T!g|eQ5zzi8R z-etqA$RDh~3iFDYH%4AD|D9+Ht^UKoakA!vyQ>{v$uy5r(QX7!Yez~jwnVwRu8il~ z1|$*@xcBYhYB zyIao5Xz=ZJ$MQ8wR8t^*eQ%8014O$l=wl^PfutOopVeh8Yh9Pcj2kQW`s4;A&W-&3 zGh4V9h=^-cxQ}bQz^yhAEQN}APGjT*a{t$d7^C-*y9p2|!m)eJRLu9)Mc#-D@cJLu zF}5gEi)6`vZa4D_HGxxK^I}@>Ar($FK#dUVt5_{>W;~nkR_R)fv_iH11mwGCfIO-T zg&s{mx>xaDx0egjsLobiTZgC5E601iBszNJ4_?5M-FHodh+dSGf8D$=d%2DJlddX8 z(Vb`5oub&Ne=ANzXPY1Vjsrh!f5589!nFkp3Qaeiwo~;5cN+ZGI@#GHC zA5NpT{e+}hES*%aeI_P;63VG-qkbFpAm+L?BLZ;X506kp77k49--!j&67IP7Mh=lZuP`UB2*@EjG(S zwk})lk21c9l`oRd18Rp2&nD;fz_vJQARjKMi)J{3fUl@bC}I zuD)r9O=nppmRD<5lMa6@IpO0F2Mk5>&%JeAc)ZI#YeVwpCSs>M8Mcwid?zl_KmpPq zM(_id4Ausv`(QN3@8g!wtFiHqOm%>DkpJYSEW_TiGtGf`iYug^Xam?o0rw6ykqxygkqiEG8yd?8Hb#qDpn@tc8d zFDnIKo()!1UC1}lz4+1#=yWRhfz4r`jDr(mT z6;Z%K6;KdDRRO7jh?IbUbP*Mh8W9wbCemx9NbfE5P(?tRfJluZy@lS3bdcVYknBC% z_q^wP=bZQYX69UT&HS2QxsvR**4oc{`hCN^4cu2NK6Ivek7|nNalv=0_fHvm9~$qa zUlz0DOZy>q@wZ>Ed1WCsw3geP!S(ah{!OF{=MrTfV``kvN70}kW3cjbcrrgJ?c^o# zX7hIMT?VT>zvLEZyK8H(e#{rs`-9&9lxB=OHRM83f}e-__3*r-`!}Urt!WPO@CLVn zPGxHh-+QuW%Z6+W_U^oG=HYpFwvZ)y({~m9`~Wcjv{qib+NL#W=9>jeKDMK>gD+|A zA9jp=uCX!Y-$wszTH&oT-AHAYLf)-dnU|!&tbSkR?7wN}9dj;QLR{6!wYxL5hnE<%@aG;m1Dbd$IBR#fR0S z_jG>sKB|_Si9&m=iPZ5{ou&S|I}ZjrRqTA$YZ?vlj~NtUFdY-p1UFsNb;)&ce%LF$C|%MtiNf7 z`r>eT_}jT8{q*~Bz6Wbe0Sv0wyopNUbg-pU2bMIB!0Ua_DXSFs40-`k1$Ka#twqQgehoj%(S0#)z5R>artGMuvT$peD3jg&a zDZp!E;_!0Xaf1tpeU#_L9V*BCX(5H_lgcTfmUcBG%+m0uaLQ`4CX~WBhGH|!DzxSt z^uN#|ax;q-|9AY_luULAUPOur8*_H?V_%IBJHl#$|zc;FZ zRlHqyZO%&%%~AaB@c>Us#Ta;3lRlfqs-RYGNhV|Exd*+Bj_}!M%@*d*(Qgdqo2HV) z{90h#6GS_+Co*%KA0F0jpUt~O&J#8e=pDqJS@)yy2D0RPnN{5G_*BNI{8ClJinnJK z)|~H@oQ99Em|1v%A<|BR%jh$vU1}$;l51$|nr72Cq00p?o0!ooQ4}AucrOfI$Wz=B zlxcrwS1UM00V7_&V4dmzQX=m*q9EuLf1~@mU=w@Jc?y_iMU}Diw|B_Vxv6O?&8J&1 z@r8GuU(HcTJ@|v8fR|Cq@lh`G)84ask>98THEzPl<^_QJmAKfE=>E;4)b_DUaXqBF z<6{khV>TuS>1yqBDK8FoA707xL!P`Z{}|J4(@!lIk*k;femyx=C~8E7bn&vyf50Cf)5TkMP{7aUPgLawmHp z#+!MVMRH@j)u4K{XAQtp9xRl;JOG2G8izeyhDvEK{(?_Z*b<&BK?#sgg}gBJ;gj2+ z(B5}TTFm(o7sZ*W#13xVZQ6Q!v-!p+T37dYl3Qh2PVARPX01%K%7h%=}U-#-=!)5X~!+a>6z`dOuErB+ownDlNBi zh&O$UFXpo~CX=*>2_kRV78ZEFrekEbETZ4A`uh!zJj>c;tCm_%ZsL)~AFtKO+yQp_ zpX>!Q2-n-^QuVp?M4E48Eu9>Hp9_4Y_?vtr_|dJtD^9{m=~$LG`Wc3HRVkjvis+3q zTK&aXmZ4w5*9m?Xu=?0*TdvmTyrI6DX!l;)^k;&4P+sXC}g?t zotDsjd`L(8M$%X$ih9MXNBgDy?t@HWL}ee0{6SAkmrQI$wy%5A{Zr&1gif8Cx9GmC z#vMtcC4FTc?-VqM4-W2JK4Ufgw(|>vJvSBklCdbJsSk(i)#&*ZUAe9SPiYmtVeHux z!fw$2;&f-|(NMDbD$DWh-|;ba+`{J$_*PLCWf~CgWLe+4V?~0XX*||qf5Ho?=3zCK z(MygG`EWXtc~VhYQnfBC$2K?~RMvXkJgjj-bTOFPWKFKV=LlCB-$k0QeJ6>zx_qlb zGX#nii7@`7x0771(ESr*I^^*6wA{6GfHI@rj(23*LjB}F&%2RtZ2!jEDS7#B+YU?B z%3?IISF9(;F(uiNGPX&m^tL=!R0WF9L4bqGu7p1(nAWNw5t)S44!Xbh!(lc`R7v&o z8F8fT-9&|>xa(f7=^E7c?wF7bTXKx!oI4-)QBV(vqx#9kuWQJ4eRrQDQO#3x6+*40 z@2U6KW8$-VDNDXmz7l!Pyu{Y_1VE%?$AnX%62ktv57>&VZ=$7~`YmnpZOfMLuXwaQ zPrJG=)!dM4wZh42m@-frFMf8R`$(cA*-wU{xvyso`)W{vT+nQH_$DLJd)usCJcizs+bp^ufAj*0= z&1X!^%nZa1gU)f$$ZmxYk_iG2h5ZHEI@G|C+D z5TFItWE}+7E$I}eN?t$0wMhkOBoO!@!V6yL*daE zhLd$xvS~tr*X3>7n#qmDYxlK_HSej`YeP*3mC0!a;nr@7(l!}apS->fc0X4WAp5Ro zWZ-n=lXA9?o~$^$|M@FJiny1HS~6p<~`=dc%s$?q}LVLmLj^Tzq7Lla2YafT_2W5!UL-*8>ekI37OwllLbCMeR0P zGsJZ4cP}t>)zKC*02ZGg4KQ#0xGbpI@Tw{54RJw=;!8=|^^>+FA@i?H5N`oJ(ecY` z!OjxzEkpb#zuE<}hS}e(5zbu{X{qaDoLcW<{)FNxE8CCAjVQm{{d#@aPLk7B2uze? zo(yS)u}5G(rucr+TB_ac!h>s$q6!v2HZ!!|e7JgBN*X8VSwm-fxjdFakb_pN|COl2 z(yd*tvzoruWs6L;)IG8n=%nq@*=O2j4lQms!zUEw+S5Y6{JdI|_j1$mWSMXL#|~4N znwG7-e_ji|U4TR90p7>nHqU>Wd|OoQaj|2vsKlG=wb)Jd0^d7xeotlBDCg+oIG--;CxbP->e0UQcVwoBI-;w>^)zBR(%t(x;lf$m z`+y4<<<6=7b|_5_op-#>A|6uoJO$a)&v&i2I^cyDwJ(R+(|hbt;$gn+tQ&AxEgt}N zZYdZV_{e6?9#h08;dr=S7-jF>e{$aI9ft?Q-Yry^lMhaCw$@?-En()RF`g~wO$%>X zsSSXt=?7LHX2pEJ+y>c=@S&Ug#%pfM^ODrC7>E8dV&t?8^o~@*7sgv8fzE}Z{z_Wa za3$ip+NEA$jS#A~XMbm>Tyf-TgshA|PLV?!`ce|-gufL2mW<5*$_m}ydgO<9UC}2j zMr?T&n+c*(8M|xpo;^64^-T^g?LO_vrGKE8WNYSi_z8RET43TMLd=-mOE z#^dBpzw?JCsZ&30N|eDwa2L{pZl2sFfBWLsN*l#)m)*|N2Q^;jvuU)?)nv&~?9%>n zZ2*VULPcQ;VH<)2^$<+Gp&? z`*=SY*VBdNh^1b8;4=By^^x9GLt5N0)!=7G^}{j;oHK);gGkKfbIKR?$I}p0xwhgz z-0ymDP_ESClE@~W-Kd34?>y#AYk%P?N+S?}OG@u-NyVJUQ8xSq9^bgQ@0@$dQAA7XHu3u6b8lpvM4R6&+aXXhKII2E6(hgmiHVu z=$~epoHbNtj;sy7$yBzbd?}@Ha3aIpyUVZP^nwG9@l9p#2j4pjU@447C-~kOx(`%+ zvYOLJdVf;K^@7w5X+N~RM5NScc2im9hRI(grysG37`&>*B9CPs==;?-wEB=Wvgs1d zFocJtc>9X1AMMNd1~7fAB-$=3pYFdN2zQUyxjDSL-GMd(oL8^Q3X*K&nLpc$)p zj=itNg>8nK$5f>i-3%`%<3!-FVg4v$DQy4ga{uKX3IfA2HVC<8@#DhED!FIOx9|`X7f_ z&_h_GVxdjPCI5qyM99=9*Tw%k(CGid2mM#DQ?Us7QQY2Q{aw+ZX=9fH6xDR2&zsk; zJ>tbnDL1Pro!u-gYNu@Wh8dpypWs;kHlBd=Rb|%)nCwB&5){pTjBrxT>j@-k1-`5t}y;5(rp%uGv-V0ystBVBTE?J zaD&m-Q0;$_ z2=zky2_5C5-)p(ipDqbE#QfRVu!j0_tDwFf&$aB}&$+qW-{V#ejmRN72jzoRYys5# z^GsR!yxn-YpMBl>Ctqn(wq)on&ZF_uJl!1zDhJ&h7p)BT^ofhfH?0M74zyPhlQ;Em zT(R^7T1AxvbN<^5DJetv&7XIzK5>=1af?7$4ymH%k6P4BJ(d%lTN(AQkqL9&;Pb`8t^a_U{pZa710VW~ zAw_30r^7HeH)w;O2JSy%i_zYpy`h@*}BBti5 z_51tpS?<2MY*q>(HxIgunW&)gJ(dLLJE5-kAozL$X$QGubY=Zy4vBG?olSO!D7PNb zx=Ook^LXohc~K#mS(+KoRX)b`q4z}yE$@4!)J7ef0&Zc|hOP67@y-q&^{_3t=JWCI zl&-!i!kNCWH^u+{){59e;W<>iws9XD4?4>tGFAi~PI95SNB2-jO**v;Z)Rx!^H_9K zGV=I^_?Q2-4i+rX+elXW1M1RV;Mz(OGhOYU@2G5(hJC#a44iK(fn5|AnD zwHB+w9;!MN!WBbBZi*ziG*kH363URIZd;~+9~(P^BO@bo!Q+;TzdU*WDi->x?Y|vh zSs>R-2l>g|DoMUrdz4}(Tg|V*3xgc9UsW%4RZa~6+|@-5qLuTy*9*x%UEe-`F`*k82a-~93ix7jBe zJSrV30;nH!SP9}^Z;w~}5;hpR>KDOvCQ^sCt6%Knw+vfP3+E>~4}vk@7#`pMDR?$M zliB#4A1h4r?9}Cz+-SK6$&XF2x^&l`PXPXX)m?g9UYhkdOH{n`Pv-Wl2T!%Ta)gw+xbOH_fe*mf zLLCjeZLgy`WFAU|^xVpua*44-C6*_kyj$|^IuE|_ZmB=`6GlFw&~&(dMZ-iIX6@w&+NBjOk^*dl)l+b-BkETX=D&x zxuo!(tzWdH);*@J?5xv757oy^VJ?T;RG#{>M?9&~s zXxvbdzH^jM6RN>_U!DDrn(?FvRkm=a%5a*n&Ou3;9-|$-Mh}{m!@~HA9c}lWtpHZ4AE^AUxyJwd(I;!_ftahBy1+7J~f*=6SSnpCiNB!!}P&}KbP+?JB&9Wc}j;1X5FVLnVYI#(ZFFrpohK2>({*VPCw34^f#W&Y9I+i z=*`W9K(nXxd08a};X!6BHQ&D{ms8(xY@ws`J=l!8E9L5SgK~9s)$6atcbm-T!v|X+ zTYze6!>U1XO)JBFYV`fT?f@YU z)#9zVTbM21*Wz0L%?Mq)^mk?zYRk*}wFLS29Dnu8G+RzqSqI5mSz9|EZ&9~%fcTfUq|}^Y=Z!Q(^eE-6vS5rsHqRUZEbWO(bZQ@PLu_3i|dm% zWfJE2X67b&ZJE75QInJ+C$ywP=G1VR?~%aYv<}o=&9Nm^zxg#pJk-K-Q;hnCLTQ+| zq@>1^za_i<6qMtvAz!I(x4YM&2)^wvj`Cp>776=tQQsT)tO_&?Fu66d7%|oOP|f0=UT%eX`|<61Xq#ZSPKBiDq92C146&0= zSf>Vjn_zRBR?s)~;LY$@Nojj-QAALXMj?D_r*2fu+QMTx+_!62RaNbikurNN3^V(M zl=6yK{Jl;g5P{7B9?E@IhlUE32lQf6u2!7QG;_+#CQ5T4aB^jWFQ5SgPI*8716G}z z?D(z%*Nm#{jlBvCt@j<9o|> zb#-gtgfxwOZBdb3ne^S0n>;bJst+k+9+!~~Cd`KWf8@XD|9qW8Ri9QzUY?e=JlvTv zMre@d&=ewCmvL512fCO;1|7VUKT7`PItHdyQL5sp~eD)Nj`{Y38ePv4v5@DjzKN ze=UpcVN$#Ay!HfwU`uvmTU2(ay0Mj|5I`gp6_>u1ob#?kW1|s+x7t<*RA6?HP6^@z z;9EF{Xp`d!&y5n+ASp=uKmyghIqS7!_dRo#hn$}50CtvlH|$_|TJ^RZ1NNv0ja>*4 z1B`rb;SaXCootG0f4bUF_LMZNxH=7;OjlWNyV=iSwdS0L-q19~zlzd-qi9GuV+Q2yglFZn4=N^tTGE@TI@ zzpZ;~>f;P?pN>Pc=SyDGg+G7)41gzA3FvhfzH%^)g5Zy*Ai_>D;pn_?RDMWSKf9Wl z(c(XlYj@D3^rjJ#1^g-U#Ns2PUPnDGr*8|L%F>R_eWUn)#{#f)qgQL3m_d(i&_I>M zrlR%hpVCs37N5J!B#WBc9}1u~hZdNw?q;JrKHB*q;^Y`ERZQ9~_y<)jq|I|*BDy?5X_JFR_i`U=_V)q3zM z%|q5p87WHO@W{zM^xG5!wA z8+9!&Y)oE{)uX|V3G^zygV~5fSpvu zQOrPURHPL=r>ZYu6`1{f+PY*UOF!7+YtBOrjZmYrV3CE@W>s-ceAGp(OTVa=F|tXI zX^FdF^WOTG#pp^kxel@SOZ7mC_m2KC&A#+qeDfnhcandXQSLLwh>xl!<+gu*TX!K~O>j*_;8pF^bA2>tBNzDl8GQ`(l7G}w& zrx}hzT-v|xT8c>s!__~Q0_+YsLG$#8F`vW(`jcW~{Ts;`-bo+Ka{H5^n5m#+nw<&*|fF zDICymjy7DAKcLw$WX_k^}d| z3Flb9JL7Ao5c~NxZQL=}ZEQ;6`YA}GagBzXJ<~wS4HV73M6Z9oEubrDpZ@`l{Z9H> z6(lwpe`9vV)id{)O&XI>%HlN_ld(>^>*${cw4(QmU1Un7K(1NpZ%4v_tb z1M~t7{!h45r*J^dp_?WfxIoN39z=hW0-DwLB|wIa7R!%&bY{k*F0B^n;4(7e#qkMr z0R$TEf}c2Z1MF)iGA!A=lfc7p{TaRo#X^|$&M_AhmIzy!vjrSav5kQKj3Xu?eJdO5 z#kO5pX_sjKcZ>cnJN62kEVL?3MN=U0fyGY4L0^Gf$!qaNx|7wg9cWkljbtHfT^7Ej zm1@Ck;yhp}*7AxmEGbuZ_s2OngOt;s=OY2P(%<0Sc$^kP@CNS;YFB0 z?*q^~)f*4@<#=DIZXEjj7;njb2otxseJ-K+)mck1lHISe2@?magnyW2|3#4G&XMCZ z?y(*C%U9Gr?j&kUSAn`RP)PL1J=K(f4CID#POFfCSL6G}{7&4<-tNI3nru5e!U}Gh zjcZP~;Oj#ZMnRSK+-k@78127vMyAzeVqSa?uLg&5lcbCoX9 zW#xEvLI(IlXvdXJAr26tK=^S1&BVDWXfDa_;1K2T{biKg%0nWah-gRXewImDL}TF* zQm7pu+S@sn?YWBp{wpSmK>}g%t~qb%C$I?*N(= zoE3yE<>Qes4lG8)GtEyIdaK7wr<(A+4l8iTbFx$?qd@KbR|nhg^<dfuWw;`^dWCpTuX-Gw&qeeKUY;t{-ahKij?<)e5-1D zaq$`IwsEu1byW?z69$?z#VRz9=n7vTR$1{n z)NTXci{9BcXfjPT~cC*3&{!3{3108N5W10-7TQ+y7`h zedTcipJZNkTLr&<*vBa#@$M$RKQQ*-Z*U)D1%7~^n->+l#pl%t{1*1j&q7vVI#{FO zrU4}7!rk-NPcR&aK%EFU9@35N=uwjtFbGG3Titg8i@WuS=T8@Dnqd<;F^oIP;KqWF z#tO1B96rym0RJrv=2q5$QUxgZW+T@Y?T#sh1s zghj9@u*e`6cuZSMQr5cw3jB!YWDT^?7u1Nx7gUl-7g6__iT+{2R%2w-R^mEGk+~8KgN@ zVUEo(AWGt3ILUE%J3I|}7Zm6No5VlMAuk>{Ku;$P>aV;4I+sp~`sqjcbJki3G@IglV;*KVjs`Ru5CycUrMToT+_6)PM2q|6#I)egMKWC@AmLt>plB zrA2}+Uw>s&TKmTLw4$B88*AzI^owCCbMs@8bxPAhc0O@1mKLYYB_es+Ly}(fSkFfh z_ukjqs<62X+tv@ly3%aFcG~W=vo5wph8O5fy9r^&ogs&%OvG zTaMgQQVVqctN74@WMP%pY@i*v!o3&kvo2Jm_POt(+N1o|#udTha;`GX<{JK|iYXTS zmkg_UGAP+@RjIZ-I7KI`tgBcA!E6wwN@ zwS6e5&b2M!x~Wq8QVLW#z<3cU=X9% z3j9V-A!5Em4p!o2&=?frcV^iwK+bjpY}4Ia==r(xfCA(ZQ5ZwaEE|2G*eT>Gf{ce{ zx*w6da8v-;3Alja$0%?fJt+~!Iwy)_TK7VwDvNj@HRMtW`tvP_;Bc=6ZMWhlJG*A zXb1R;m<|6`3hfZld&18pz@9d6B@ff>1}Q~Vy9xLZ`~bNXeQg!q3l9T7Bh!%)_<~Zn zud-!HD)J>FfG7guiSg?&QrTzZFJk-@W(^r}esi@CXkiBQTkY9!K}4}}G+w{)-Q6DK zS!D0bmAzZyO7%W_O0lUmhq%o3gfvk%kh?e&eknTE<=h6uP3+0|% z3&iWU)NKAWI0iHhFx_KBeN z#Krya1MPUA8Kc_92><2B2X~eQT8{C(&T;>u{UT_8m(@8_`id@sySIz5Rl7|m6onR*#;W&Z?uiA}l^>SO4_t!f-pX)}Gx5bQ0~7~AtoBwYQ_n(^cR$bH zd((3bv7+PEV^`72^bH_vr178m>qklz5s3%bsh*U(vZG9fR-Ej;fBsmFm3F z&3#zV)}*@d!LaHEkHyDh&Z6g2YS(Oph4PVVssaK%;1cI`{oXf&POQ^P6cZY;?+o8O z-b(BpGljnsGCjY*bDmK_og2l2&ik4q8&Bk?^4N+V;l=k+4lkpu7x&d#xMX=UW3`1c z0xZ6DTZXn>l*Mwv3fHpu6Fy_;e_kOxa~#QnKQ(-t;!VHjg6BDgv~9B9NNBgE@gPQa z2$4ISoC7Qf`FoovgPOi5d#ee_dGvajPvLN}GQJso@B#C5<|~6B4*nal#g3%kc{TK$ zZ!`<8E6?@N=!IN4TkWVA1KuvhyZXw0E}*Vd?;XOZYovTy^P8vWDNlZ8w?mouB*KgH z0zRU;6Rh$!lm5PX9DFC1Gz0dFbvYbj>^FrGPN!pg4u|k{9-?xjh};fGVfqxF`aaXMhIacM81h1Tx2_wW1ey_H`W% zV`zZN4)i&o7BIA+m;JL}iE{(vy>$nvkV(IWe>j~ofHN)VDfEWy%dyElwrHdXz2L9c zw_wGag*QRwqc36dx@>BICb8^1XwwQ_1t(!*HApjnZxI}xk@!OcKuTFB1U`Y#c)$b+ zE@q)j8nR_l*B#E2x+5y;@hS-Z7+{MX?185Mliea6%uz?UZ~}$xXZq*F3Z=a-$NHFk zjRh^7Ir50PDC5%J+$M5n683PEGzX{h2Kf4roWKwG0erqJOdCOczY?>%qZIuc85do~ zM1+9!Y0_`@Aw_}rL?1v=x1)%u73TY;>y;1Cf*T{EkbtW9J+KormJ<^Pm-d1iZXma- zMfK(p>0qw6PtSLfa?`qv@_dix16Y-DR`UfAmR7UcE3}r>`s_n zf+{nfIU3@A?n|nAwyfir@=*4fF(7mt3;Ci4tY`5^896B1?M_H(=qgYi-m1jPWnP7e zz6vC5TEb6Jule?}^9BFL)OQqHYK{xTgF_CWQh*0dy;I&t#Rv(Kv)ku~$72}a=uQnJ zo|beX(acrPcmAe13R{^G)2Q9_cA=*SknxbkN*)$kSF5$%>S~x;QGJOksO5d)>$3t} zD))tBTl4zJP1Qm@<5Jb5-j^^oX9bYwQARx`NoPINQ06bZ-4$+IdVHD7ub4@FvpH*k z&1X>W^r?$Ndgu#*SaRL!n5CKl73NUSPGOCvC4RLo?UW`S#F46w?=9x4Dsu`oXO#9J zqI=RBErFsjS{l!w9nnp+o-MBQQX||Nd^gF*24R1ysgI63pR%(`i7;6y`Tl z3K*Z`%e@IQ=;Sqyb#dJ)Pv1Z!>=4{4-kCzuiaF=t3KmbHf5cFjpZ0)1_;KjnXdswI z=~QxEc$@Q%ELEsHYbz>gZFqc=3)qKy7cqXji^5(LwPZq`$49}F9{>uz0U##=D0pok z3&;Shdnmit@!#$M0^7)r;PgVha^Z0gV?Lk~7jV<;PK&}e$O#?Ah-}f>MS834wd1OU zb2o%fLzMP#G=RPW@{isDZfG$32!D$JBQWnWGx9$9gTt~Q2SAoX6wC@Ls)y9?AsnyS zdNfAl#-|SX1BOw9tC)%PGGRmU7Q|U(=4GIOSDq1cw|xUCe3v(S!V7(?@EZ93PtCi} zXF!%CnghfPST_PQ+Q4LCD4(<<%!w2v>*f7$K%01V$$YJuC|L~JPz$tSlJJ6^v8=mj z7bpmYC!Xtb1YAxpL4mM+BpSH~-!f61<7#fvYr{)+VM*wFTw%E+UA02IBmuKB_cs_Y zK@knZ0&fz%c74aw$l+v3%a+`hid@Kcw1yypSwA@jQUzhqGmw7-S1 z&Xi|$$9vbGEO$ZaC_Bj+XNEbJ=L zW9QGtcEvV~#>If4Z%c|x>$;Ai zFN@b35yZYBp|V2Tvc}`ot!WWVJNq&qP*wy)s>FVd7#sYX_S!Au?3aml9@B72lSxsT z2rN>1Zt_r%zK@%hJP%Uasx5KXMjp$RaCIe=--pO>PuIFq`reI=@!hHyz+ ztfdx^*s8z4m(?P2Crdw!Tw{2-9%z23=6Q%B-azsnvh1oLw|*_}^C?i_C`h{bO9Us( zMc<|Lb-sA`C16}rY`swjNoS(qJB()HY5Mt)a0$#Id6?>Igb0j7YGUcMDR>+Cdx2mH z1Y1%f%S@l4Yk~71LsAsv=WzkmJ-`4Ip5$QOEE8oqYM-4&5o!ECh^_)V1jVEdAPRnb z5~h!bKX_KiK%${F20uU+wEJiN{b|sn=_ha*4i)g8`@sQ)TTkFuJ4jIMb055kzYc_9 zeuHO=KOl2K3erF~NqbM*Xg(T}WkH3tz37B{hehp(U2q!Y*fdmHYQ=RE;S0j-T+#4o zum|+$B$e?2khP145hVNI?ir`B7m{nj3Mt_HoFfn$EWV&EO%xrQBVoKq8+&jsl8p}X z-9Em6l_UYP?%@Qk#kRGJyeIvX8%JpDx8Vy!fxzsdX(gsn$e4w;nj&#VNIgz@1DE#n zPvE*+j4SACP&{pdxCo5h#;`-mb-7=T9&$tjNRDJR3XprhbBraqVx3p=T~1I3$CN;3TsS&PFH{jg&xxBdjliOt9#6=a}#R_MQ}Tcc(-AFWwTULLc@XKzotH*y!v@RrX;5&1QB9v zuZ`P;!~G3-lW^RRM)-^R*GGy`w+?l6a$ny`V*o1UNSFh4!nq}6!OY6oXDE;FH06Yq zwevgARNmxsx-#@`5s-^rQBY3wtR9tuO?eJ{` zyS~ygR8wzK+R^=YDb8kcWYzjRH2fC zz#j!%A_X|>rUJZqy_RIn7$QySK|*5~u2h?XC-RnfBKvFY&-5CYSd)U(pjU#gVBiJmZ-{rM8!(DQM#Zm-Uxru$dl-gwdUcz?=DbwSr6a7pp`&rr^xjcj); z1fWu<{gxH~T<^QLEOW;d&@+CC`OxiQwgK|6NL6YKmKr-$lvJijL&qotAHsZkO>#Fi zXME%YNweb*`XxnwXZfVt%f*c)MVp;GB%8IJZjnc%34OJe(36rt@4G;=^8QEjc;GB@ zHx}TTH<7EOMDEYoLtf`uq^?)!5H0W(PQdzOY~?ChiG`7Iq>sY5vE}e-|Aco?R5sW9 z5uz2jgjB{?9$=nULcVP+=_g{pS|2e0%&bGEA7rSOkoLH2N17jIZ9_>5<|CT@eB>1n zH5c;0z8t<3G=)y4O{87aW-M$*GJ)|9wWL*(rgpR!+e=GeF0~aig}jHWCtYXtHr$2d zkz!m3mz*fk-Jtfkp1zS6jG;mcN`X?A~0J{P|!F<3RM?af-gLffX9)Si+*n5!N z!xrE@pc(KJD+XTjY{Mgf_NU3)xhdf51I!9%WVHvN&(j5g_ZNId9^)y5CwK7-%K}kp zka2ua7mu|}!y;1!>Q0G#Yr^0G7B0fpFsxcn?DJv)0J9KZ=aUmhx3O2J{~Do9W+q>G z4t1TWb(=rpaUa?DEX*l6qxygZvY(CBbu?)Gym`8VahR;!g8PJscoFy7Nvm)^Bc2Rj zAY&0DaeV*H*4W99b2Q_18>Jg4&*M#N!a!Ws`rm>Rz=fRadVvK*^mY0wy49xjK+LN> zQI$+!V4Iw!J2;Ue2Eb+xV@G5yN5s*px0yq4EyY=PZ= z!dR`!*BLe8Sp5`lSry45ex0~){IZG4k22#Rs{2Cy+Fm`2xw(-fMC+`lTdFl0YwgfL z%@n77O1*OZC^zu?j-ApzQwH<;T>Gez4V#g7MfSbpkE>gqmayvRxgjB?NP<8o%MzrN z41UT7c(*Sm)gQx%g>byigqN<8T-7l)XFNEmGuh+y)+JjL&P%4pEY*~d%{OjAwY0wx+ zd4?!-0*}1p9S+Ic*a2HJ`esp*KmdmSMII)p&c?iKLU;7VFTEG`j9w0tQ^&u#bM3l@ zYkv5PhB*KBxX(%$Gj)~uNTgr&VcvE?Bb;1VzYag~0&{6LJ1sN6p-jE0q9_L`(tWNg z{Y?g~8+!x7w*7JE0>JS5KM{{le}*387_hbf2U}+z4fX%O{ZFeFWlNHnY$;-jP>D%) zitJe@ds)jemSLtW3E2{om?YVaeP<-Qm?G;~vXdFiV9c1A_xqmD@4oMIe)soxAAdN< znd6T+Gq3mad0mg|dI733VWs%+mLzWCrnAC+aif9x+qd9cH-w_q%rynD5xopy#Ot(Q z+K|1>5Anep!76K!P8EXHW!b$%D4lQJ>shW&d3&E_4* zWA~U1p&@CY0a|M3q5XIHYXa0IIRPlG=*F`laFack!g{xrB1@j zU0!ijAZ8LVH@=C~CpH-Pylv&ma$3XjGqe{8VpsA#I`?K?z^j@>HuJ~+hm_5{cQF~UeX{qr5u0-mJ*eLr zTg_*jFL}26jo>y!Y5)*ur^0-D{^c78zNIyz@+1%CXMfsuBqPD(H2sME*~q)sp9=6H z{ZvtJ$@-k`h5GWZC7e?^El+7S)p$TeUgz=ldYB{HVw2jOt<*k<1T6B@_NLcia^I)F zFXkFww;5FruQAEcn@Jt3Jwj^6WI6Pg(&<*&E!%0CB#!*-MZGy*b3alNUy+TJmK18wU5j+KSm|^1tR?>n?|jl2GX81s3uXj(4iaF(SqZqdX}3QaAN2H?_H1_NU*0 zrj1$^*R>{kdn*zZhp&DvnjHW2%a+&h1Eo3$Yv;^|dz@zzsEKOT5nQUjyYA3$XkMY- zZKbNXj}+=&W^t%X@oF-}1`gvy*jK|a^I(x;67$PKWj^^?&s}G>U2u$+Ec6^S=_*}< zCVJ-}AY0q1ok>VUQ^W(_*NydZrg^|Yv-9!Y*KA zsMK}=Be^(67OWH%19$#l=)sfiOE!Gx;`)^1>8aYK4B>zc_CPEGBkS;uGy;tQ#g zA$JPjp{yf}Do_o=KY1-3clwmY?%Xq^AByEY>9KmimOt%L#Hn{2O(r6GoEIYW+a69Ym8wb=)c1t0LT z=NKRbd-59A2`fVlm|I%oz8NezO+Fr|nFck_jk0jAs)UfqTW%OHnUWgBj8gX0Hwr5s z+>$8Io$Mt+IUY(nRKo!F;*8#c55UAW%}#wSy4?vEI(*%f$2yu#X~68B>j9Qur|<7< zin341H7s2R*aXIg+-Fs37a2o!)HfRaaOj;~9mK+H*)AQw0@<;2DL(e;0vclU8phtj zxnCSC`gyP$0qUfPaGS-l^=*F#1*w$RoNHLM8qm=g{XonG18UxhqU#vkbI+K#33A$n z98OFlEyX}@bf8rMd6u9h2mIRQzfi{5Pgsu|X9s36nr*qE-LTVMO)Rc~>%V#jCz@bc zh*&%1_ki&vHQLncZOqQBbKC&22?iXORdf(Y5F93QM2mPE-J##{yIqmin@Gl>foriF zOs?0Vz!8byi&!>3?Wt8NnDE9-JFk27+^QSrG6EcujQ&>J4pEZK$SxF>By6m_te<5LbFRd1ux4b8 zb+3-KyJBzv-3n+kCev%{>b@FD=@k_v6vbPISTRO0z&J^vv7TiJuUWD@_Y{e8V_Qc{ z3i~HU9@xD#vK~oCO3cl~co&@;;tgmw=>JeC??wjV25Q0i__W$1@=T3`p(Mr8m*ouO z3O&@!C{n$NW{InvMoh*yvw~0 z((pFeW_Jz|M0v~Y=dsXq>))V&8_+&F`K)E5@e{?P+z$O6?%70Y)y@+)u(3>r9z4i0 zx!Rm2`uw#w9hVx z{ed#luQgK%e1Nd^TfT!jsn$j9yc1$Len9pJ)22ML8x}E4sfmS&1FbFiR`$ErRi=NV zHxSI1HUNCa!Fjly^Y;Qz;>Nfq!Atb50fNGn5aA#0Eojamiu)NcR2tp)|eeSj4@*c+p7?1-nR4{qFMTZSOx_5qv*4qo0y7awM_VYN_4y)(Y=py1}lw$3(|0p|Az6#giC zk->_=*|suqpI}ZVc_D9L>3GV=AsG>}LMzRFMT;`H@K5sxEF)@1=D!~h|03~hY`OsS z2v7_B*l6%yY&`qm`1kKy;K_s2Jcwz#xP58$N1_!ITJ7A{gL(&LmA^)+PH5$2=tY|3 zwg;!?$<(|Ny7l07qWVlH%?(o-2W@=MF!N7(Uvl?RKyuBfh^J38_57N{Svs$v=JU?8 zHs01!#ETaUVRSR0FtDX|#MNd}y<233J@}dNS)P-j>{`3JZ>gP9*CHt5*hw z3kUt2qmp;_N`%9m8u-(S`49@Q+Lk@FwoA=72hZAgmfHobMb-8=zNx4gP@47jXrk<; zr;MAu#dV^de`_!fL+=0LApL+~98xafyfHRTvJ5)D!SV`0UZ&Jt=7IXnUwMWVgd_;Z7IAiQ3+Gk{b)|__{ zugbcq=RzV$F=Y^wSMoc$iBy7jl>xN1Z8Bu1R{S*V$7qjqdIDpnqIOS|@ixf9v7z%U zvFe4LKhU70ITEpgakI1!I8~hdw&UyP@~GG}L(gJX(HF2+Dl2IZVk7}ao-XqJntB*j z4Hm*m5|=jXW*h}T%0Ulyn{|TP&NaqVqX&JV+o6u_S3=OD$JwggK_~F^V!8w*>$d0( zXSQBPz3&{On?1@KW^c2yZ%H}{pL&0yv}(RQG-en#i&E&P#8-^jhjpG^8|$`!``Hml z9x9W*#igEyqOZD)0ZX?DNVbS{6*b;V%emt@;bPHqylF6z;Dry{t0p_yS4yUxdyJzk zNh&>wkt`X?P4{XVNTcS<0DoF%Iv-gurdEWGHTmIhb$jD>wUJ_a0AR?II97&Vuj9y?H~$vy5m4U^wXU)YSOBjdx3Gq89G-6uFo>^d+XY&)s9( zD&6+)n6jH;2&Hhv7R7JFRtxilL?>^6SAd$U&wk?~0Wnuip3&F6Y;Uup^{N<7pdxxC zIQo<$GZ$^64&DT#=mM;o5{Z3Fv%ySZmu2a;e69i5n+NdrHbA%%MwSBCx9I6XS9`{o zeDjIx#%hmb`)p05h>zxX|AZ0QccJI|)<=_eNvfW4s(XRGO&i<7O@AjnzMR^OU^*Gm z9WJD)`Y|3LdbI>7Q{jlMVwsN>U1bz+##IbzR3f}&GzOWsAN)}1BN zIj#k##OhP6^(f%Yu~asyFt`^LvOSNC3qXc%5*m&f( z(<-ZvGq1VGN9qh@qiCW8ud$G*-im0*93>A1rj+O3)9Rm3=1vcl^|Iv6&^sD>$>o8h zzqwe$kJcw~r;02mr;#hue<<%&DdVQpRdJ(94PxB>_;(|MX>;w*=rqxh%0LfnW9+W= zjW?u-x_m-mx3G_?J@UJKNN~8Y-=gueb1yGguWe(hfRm^HloCyAWa}oowAJNncRi~# zaDitig-VXi)ZM`;56;8+PNF0wDTka%P- zg3qY37yF>%I27lsBjR_nF*@JUChQco+a@xPGY`$d{=fuSjzEREPl??U0~FhS&)A5; zA`7=tfR?kwfwx}*+Be?u8PQw-_eRrhtqqZo^eo->S&Sx) zygmyIhCpw(k<&juP_mYqskGah9I!vXCx-H(?!T+sifh?MW_mSO@IBrD|DeYK#?sy( zea#9n0D)Eo&IaRM5jAY#{CSQlwe1ORHt^>^HlcH!-|j|66EQIDa5f|ngLXd3)S5qv zKBusJga}5e4vHig@roPWp%kcYEiTZy7L;~JEQRKcfK7?Ri%F+>j*9}HLG=!Yr@eR< z7sUw3S9t~(1Ueuq6f}=hk(qlJT;gpv%v)HOS5{mGl$*#nBDNdcb)Jik+1%~3Aru5 zns``Ny_jxvxPf}u)}6*%OZ>SMgnwV(IB)Zt+ z_Lqb`J1G61a?kpX%p~uKQxe^DP6;_^q}jYmctqu6X(>I$=&jAx=@{7{epeDxZ{F-U zv5oIB7WeFs{~jcNp}%rv`*pH`%_eY2fpwD2;7=-o^4@eDJMwbmzA3X8KKUM0o<{VK z*VsMVN&aD)*aT!LxK2W$w7eG9RLUF*^Ro6CrgcY{=@X@>W|Zd$KJ%IMKpaFG8f8#E z#An?cOi&AN=y#K->a>6p&N?Oxw`OqmVz@A{`{aG*Q!32*IC^51?6&Fvq~Duht^?^4 z7zUl0J^*tG19V;d(?K>H#nb`1*|Vun+9n1~!x3;7XZ7Y!C;MrE(J#_L#U3v5*i~E; zEthc-QgeRZh|ODe=IVBJ;zZD_y?d6V_crxQ?Yv)IdmqU*_W=H7_6cXlLN4djoRI}un$l97ocGxewPGuufoVbshUfy&;kAOL!3GjYEw&h1p zGifdVmf5X@aczD>$7Sc?xUlD5o zX!82mrp^Y#4Z62~g)r_#h^gNX!c35&&^Tt$&{K12R_6Nek>zRx}m*pK>c@M|7z92!rEI)!F(4WI{jmsfEe(Nr{x>Cff zI8qE5ylF@9!M1oZpy=M(i3LLZ-gy3In{Z%_rG54)8Mm0^Lb{Ol{x>;A{B*^yz4%u@ zOi~>RI#jl{B1m!YiKr$;0%}0fYwL9mVrFS9h(TL_0dWU!RwdeBaB4zr+pJ>g`M&_g zQQTj;c+Q3jUIN76@(ts*lFZu+qzz?QuY|Neqo%8%mp zVmCv_V}BeV-(2{uaL1Jycd>)^2hpI11<7W>g$ z``@uk+nDKXTQ(Betey{d@ba&abP$6nFzP zPz!kyTl6A@Ets<(5h<)ZT#vc)po zyQ?L7ok+|Z{vTqsTlhbq=Y#){q3$Xi#H4+aL9Mq2m7)3!l`2BT^zE)GsTmBUSmhzhg*dhp^BM$9MgEVX;X#@Fjzw zO|(%aaBZM`=fz zX#UBV?sGkqv>>Bc<=O2`*4pOyhvG7ib)VLp((;|lj3Dj&c#*LD>9Daw)MfUSGvdB) zHE#=U^N2?;`RbVNN;&p+{!OjS=70qKej}zVEUuGK%^`w3M>lT*zo929x-U4e_OEJZ zB6WX89B?uzG#5a69tR^%-}>EmwW@HT*>A91c{T`--!({;DXKU7-1v%Ru71OR@ih~O zc%wzRQn48Q_e@*R)=Q3U#&_-0?CG&(mOSfUwM%-P+kR1b%J~q%e|VrRO|_v~^AhbO z?(CyUX{VxVh&5Qys!46HYi2Oo67F{@a$1x6CO$PS6v%6$Zi)g<4*N)fNLG zvWxg*gy0pQ@zW|BPu#KtxGB z>h(2R;COiH$xZ@y8)RH$c7|WxSJCF<-=-A|>V)s28ggEggqErdr!DA^1(=xef0SU6 zu-k3WTq$#_Yrj|Q{A+h3{D;V+gw09ey4h6#D>|~}L8`dSsS%LxShfQ@4bV)8rYQ4h1J!2fl%T4fHBxWwz`Gcu3BQ*-00Oj-^5r5G5^l zcdPp?L;L7EFj`_{k}y3g{yVoT>hZ8zC`Y@+;G?QJ1FrsP>Xt_CG;HalF|f)Z5?+1s zfwrtdWZzIXg@$bmt>#Gl0}er|>A!MBSNp|U>x8i1z(Q_zijAtHFl!_C1H8dj-YPk( z2<)gxyY2L?IM4$~#qhJZ_Pi=_S2ZNX7sUQ5fLvrO9G?7z)QfhvMH(6DDCt?k(K~JKK2^{%)5$t!u{4Ks)81 z*_5x08yLa7IEXl`)K1f?)5M%c03op#+ag?~rz_{-bJ;xo^-Uyeq&EqXGjLF~;OAqQ zyku>DtHKBn$~whqDxsdqccAG0lU$Pr;^Irk6+eBsbNFInvHR8z1eEaa@FBsv4E?fy zhtYaDNKF%2yQ6k^Z?Kyr2m1?uS!WfHwNHr^e|7aK{!Q4ceDh+_qbaJD1s_e9YfJg) z+&8|Am1bS_dIzOA{hUwIxDfW}Hf72{Zfl$75g#yGsgZC)WvA^BDMw1=)wPrRiRYB$ zl|&0UM{U!CC-uq#lN(S@lrK!+TG3fMbUM6(-6F_!=H1RR2VJsH+l*gqUf(Nl@~Imd zF;vV)ERq4{Y2Aam5vDE&^NzgKcts$=d^@(D3ANmwSV;(xwyww*U?2i=K#!|o=M!CC zLHiX+IwPI(=>g&HIZ^vbH!bF~HI=D_#{9!tR_21diN#5FW_6FjR7-nBgv&}6TIqcn zac3Cyjt^1!oDr>1+8y3PLFjK8fc@yej1)xUb?4qrul6tLdZSJ}si$1_`$6eHUxqT+ z7GZQSgbhfsgHy6fo*5yj3tuyR9A@_i11X5xR^D`eufVeD(CK*UcT=M;7xJHg`7o=-VB&2hii!gW_MndQ{k7cXr4NO#1;872KiMn^KZd z;Hpze70YQcF6)?1rhf7w`iH;=aqZI(UZ07@vHV4v$IcQbXgTwE^QKMuf!arjwIbBx z{K;~dJxSe`RWyZb4fgC;6sZWO9$qnf?o^Q10tbu#oP9{QV)ID{L|3mAffP71Cy_{; zJqQ$i@ntlD6|)e23zs4=J7nG%`99BLY|_``d&P;!X-<`$Or%x!j|`Ej zVn~Nvk$%?u0d#%+o#^f}Y(y{VRxCgEMwh+aD)z5U=ev3Ap$l=;L|Q+%FI!*WRkeH8 zV%@4@WIX>_#sj6q?=^mgYTp*{B>WEr|3?Mo&b93Zg0l5GOi6H{7rTs4xKMFt(srG~ z4^Fc&O^1Y`HyY`!5|(wN3VAv&m6xS|7Y;_!bHt2gl7v^d(zz5+rv zy)ZZ9<8~Z|vJMYkHf_9L_djsIQ^&T9mj5e5_J5T4e;vIW;@4E#%NpzyUgk6S)6z{V zV)IpcBT^JD6_VDYjCoS?G|fr(^1^$v&PrRJ#Y-b&S!}cV3UYlnhMs3!T;k}K{rq%{ zLBP0!!71V7+02_u{JgzI9BX1aS1K>}U?@jp0OGmZ{$FTEjfiRNJ^N9e$GwP#9P;9jt6HU8tX+#Mk}cw+l>(fUqIBMBDkY zWJ>uNBT?xERw&L#p3kqn1#-f*%su5WnjT49fp=??hq~WFOU-I3Xl*ZpA-97)`pzIX zlJg%{XBU9 zXZBUx^h0i@ov(E+0|)A6T-iyV(?~MC0>Qj4^;jzOI3rM+XK=eRkfW9@qa7MQL9T3< z??>uDP3DGok88?~DUUyM!cngxCCloTCu_fbT_=>*O}*1|E?~P#_g!%Gpw#XB&Be%_u zr4h$nqeeka^@^+0$C23&F|PV|zbX7nI(20tm&Oa8w;b8;qR(PSVoT=H&36Ld7hqi&>=nX(nn%_?^){5w$nL- z2~Wh) z3v9URrOrl;3>XxQ^68)$IORXI5`Y%<4UsvH$|kN-(|eh($@%rC$pV{CxD@Gd8N@@y z96YQNwwZ@pp8dcMz(H9AC+4r)`{*imIIpCJy5iL>o=}l>`cCD`@+KN>lh6`4YqN*G z^Z3t}gW8w#+qTo-Ioq?K!U?}I-lQf`AQ>+JSwyR&tC#P9%w+m|IT`MxedcrK0+Vn9 z)PRhwzz5K@mrPhsH(1HW8Zqme+eYu;JLq795*WgK2^+tik=_sOfaT@~hyx9wSH93r zVql^`JF|HFH&b9f5kUj5?)w>Iq}bt`s^*5zhMNmDv`J=Y2Y)Bl{*+*Mi)M>EiFW>#IqzG0;l?KEQx|I_BtrEbn>_ugURiN3;2wto!Mq@3F3qxZ zN5*XOfgt!fZ12S(qG}pT+{wFNuBF;8Xu@TN>5`)*v- zhCMgeaNFKZldfjjLHw^0t#2NOQb(ND1|v@2d0pII(0Nw4T(_+6N_UoL9cw|m>;BT2 zg*&WnSPj&(ws3aVAzhd_0lA~`l0)yYx%TtlW&s-d%?A4^&gp}1H=Ew)e3Ibw_Hw=3% zO*@H2PV|fq*2eh@BwlMt%61>3LYn(Hz+Z|tkUW}FSMa{^Q@&>uXUXs-@BU$kfW23 zEQ5`YQ}J74E<%O zd3NeI!W9=*UXZ8vKB70=F!&cFQUCkz;)c0gFdFE^^$O$s)h3ao%RfkhifA~^>xN!pZKLRIGLomesM$Y{Hu8EA>{r$SkWJNK@u+${a66V2OK30vW_M@^{J z^@uH}zIvRmpZ)~R^R>mg(7*3=O=_s*x}6%{a!KK)7Qd&t)}yan&rc2E%r&_vHBujR z%h*wn5Tlg*=Duyk^|~inTcL?zlbRQbhkS-Q(m(6+&Q!Xk@7hT`&J%*pDSX*oJAiyz zZ6;Vq@mz;`ea}YeEaEqgR9d(BaQtRqHNKo(k@!}`Eb2tgx1i0iKNtiF zBUgn*I|cgeH7r?Hxn(1d{YZ*vC37d=f9K4OFT_m;%&Lxd4aHP~rGczzHTstL-ku>7 zTzU?jXmA65pJvQlpXm(2z=r|UUY41z1K%E+M|uu_G5LypgFc3$N5|<}aQ(W#HtU8U zwe3qfY&d3xrZIjJ&4X%O;kOw_L*_pZsc>5eVCV{rKUrK^x+#fIdT~LI`G1}r)w~#W z4{G@FoDWaGL2yYU>$#(OzP>h?_xJE}Bc-UKGfUxCQz z2H*|0o9xiJ``7Zct@D<&0UV?cV=>Y_SPSTpjba>ulH1^&?D|P72HadSR z9gO?r53=_ib~@4U1G@;|d;00cQ)=K?C_5dsf`RqCricUnFE|HqJz`zwm)YyB90b&1 zXP_**VS_O1+f`PmD7q0P>X7$*t$B?@F7N|(-sUVw-d6RCWlEw31&%k);|@_?tx5bR zt+XY0ksEZUb2b{<{XfP(Z8q-i{hys<1$x_zAUo`?CZ^!s+py0?XQbt-c`=s4Nd?3| z&67oWE${p-6{CxS`piCI+1G4@z!pT)EGSBdXtsWNo!pYJzDP1j((JgaF2_eG+zC#;PdJB&Xx!e!7Yz)19wq#*cZc)f-%nqPg zvZK)&U7tIuUKhuz?*BZLt%-e^MU^a$aqeA|A%QI^>Z@+r_(^3q&~;m)2JFg|~S9a59>FP&YGAMf1Pi_46oE55K@~ z9(nkO`Gt#SWHYaedd#5vce5=mp66(=vm#|c;fuBKfx;wqeMP|toA|ILNpA0o-PUpx$_^#Xvb4T(HKIredp}e#_y8!) z$SyocJUPB6k(TtP`z3>TO7s>F=eT5?rkYDEYQ6J{8NW++)t^t2m!lrW>)+)@FksA8 zr&~|!=2t8#q`L0(3e(}M8i`G;TtH&4hDelxJg8d-C<66InQi3g4`x&KT&YBIx0RBj zip8T~mnOzwQ?pSgJYN4I9g|STiIy5C7n-=DNh9W;<6p+i6v9Ty*~FyDXAs(%>Li zGg%mGzG%)*cnXl0EWg<}uhk1&8s}V&Uq!cK#8mfD-ZNdERZ#DwL~sZLbZj(j9(blm zAQO<|mBjhU!pqUZ z?Buf8`COKu1l|GN6FLEp3@a}3R=4siS%yEQ?yqABSQJZ0Xh8lG3>ew8V;;@)_Nto# zxE3uv=OvO6lP9a=8;YX?{89Hj=g?M6==GrYuw3{;Mt6W6a-w(E{|PXbuIbC*>jvl% zOgSFQ=FN7tvsI6n-bbHBU%UufGCAmcg!I?jXFt!br`j@Q3pN(f{L>tp*#X$Uy&lY+NgSQ=kSuv5{iI&N29$V4( zawqJdH}vxVn@ID&#btIuu;wI-!2R{~e;bNuAkRy-nryhQ^;xd=7m}ot7x_%cIW3ts z${T8Z`fAect2W(V^(1+ht?dWaxFRS`ZlPRe@|YuC;#iWkd%vXhXFkO=Ov@__;aprr7u~X zs0jRZOTcQ=Q*SVE2FWh*TT=Q`s3NVW>yNG7FGBpaa${8O2mE%39$z3vb(QPAsk=@s zH*-2Nl&c*cHo>1>Q>&lBn!H3%L^pJmNm^lJkB+vP#?H1@u8(cEPR{y7Uwh%K4hoeu z&6MHh@T<9=axjU6V)N--izsJQ%t}q<{9q@apo_XqIUCFxI&_$p6-lK?~cw;9Ous_bD#0vGr!hM;+@0_ct3TC@s zq%oSu-w3IUDounc*aVoHUmqow?vVvU^$xeiNM-fe$83%>Aor^_U2f}d_4UVB3az0* zR=a$@Pcv}zFt0)BJX#JiWdV0mR9PqbjZ7te$04~7PbegyGZxXuk+09E;c?gJQpbPn z%g$h=@6sVXC)qJd4r>0}%PL=6t_yB!ymRn0pX|`kG~qCR>C%_#Z?6rO))CrUtG|zx zjH(T{vXdjUfBNlR*)tUmb+Wsgbcz~4{8VJ@{P-O|mLO zg)Z~lA-sfK$oNqqPfxcjKg2h{%+10&hP>O1sWbD^3Uvo~PK}Lz`}6VR-IL3Z5uNAX zUdgHbmZJ?o+>)oKqh_-iri@{JOIIq#Yfdy9rT08isrd2H2_qPFRYQ04k71|UhuhPw zE$azX!n)6*E1MK{S+ecO-BUgB?L==xqNV0rmuRZ<8HWw><~GLhmWbHXaIl*$HDf&T zIIc&EtTl1{Q(e)6UxIMYe5U@F*`fZ^{TuRiuNV8~vAX}%K1L^N(V6|sly1nr4#UIB zbPYc6?{c;L{cbPM*oW*2FabV0VZoXzqW&%BBfT|1bs{_iKwuWU$B8WmxZ+z)gLn;g#7{@Z7)xbR3f(BRBxM!$+A5Wauq+xfJy8HufC4(G{Qz z^f>fd!h@N=ApRFA{OADYb;mkN(;Xn3T?nuzkqe&HDT5{|L;tE`Cz=_kX9`_1AXOEap(^;z|g1 zeI`LUYsxe)yl$x`Vh@M(ZGN!pEFLd<-ujWdp`Kdlr1m7{uvo7yZ=x_$=6=jbnq1NG z+sL~&Wxc;!*u_WxsGV{RYg+o+RL|v*zeIe}G;E2WAoq9M#P?*n_3l;mUuvaQpR#c^ zUvCZ3EQpG} z0VLDfZM;Yiuh;#4t3mRqo4FhQh++lAU+02cpE}AVxGXP%Tz%fvcO_=_xsw!4k#(C~ zZ|b>?R9blRL9mk1a`w?rs_Nn=CU7%t==abk{>44J%U7X=nJ1}Mk(w>5gL2qA)+?pT z-xbDd*u@feijev^Y3*H6J@FngOFWkQ+)i!9RzaJmQ+B0lU@7ILV`X zu$?3(5Gl~z1Wbw>>~q=H<4!?pzo<&gzdKxW+TrX@w@wl^?5n1ILE~zaz(K2qA18{( zUjT6vJB6mCYSY2$1*6+D7*%loB(sL*!G89R?C>Qzwd(MTwhO8?fFESPw+0CSl%XI( z!tMEIMUjBuu}5VVqWoI5HEq5zwojvZyrkKoGF#y(0 z94Mt>Xv=bA5Xx({YEQQvkV-9TDb0I|-0`QE{@^3=``^Qy$a6i}sefz#BhY2TZ3H3g zJRNRG1f4+gf_-&zKh`o>k)a7S@s%5+Ilg}FUo0DhcF<0JH&h;{ zPm?~&U`tLiX@`*B%$q%buCW`J7Je1pI>59!1BwxU!9-+}^zE#Ur1eAJhEdQ(KkSj> zaSufHnUlqYc;$*s$wm*r&i~J2p>o?T!QF`?y=PV+JU--eHAG&s1Xpr81IL}t677;_ zkrCK&6Lu7q0_rO1gK3_CjawFUa%kP>N%6%$uhxAk>I%z;nc|K%234r%EwZ^!ki^23 z(l2x_5TaabZx^;$AvMVg^!m^bf8i2>L;cL5`z?slHQ0^G*r*1pZ66vlIe$Iw1ch-8 zjJY|ylDM_E^w8>j72Bu(cwznsm|?@ zLGv36kb|)EN=wn=!#ESj8cv>ch__$J=#|>-%;{NYZog zCk*}+E=cq1jHC%7*1eR+>rPL>jmC|ovb*K)=# z89Fy8Q{Q^XPWYgM8(3RJbJonBq1vx~s(stWg|Iqy?Obi`a5mBn|DMHTQmV;oCGkaC z!0^`GBSOH69g&r&RVz9%6SeEH{;MiJwrg`4 ze}~+2i27}Z>*KLfQIK60T@iq*uido?a$uZfps#q?Mcrwn{*@tOE$w=@F50)@eka)J zC0M48xH7r!P+so^cVgt~FqpvF^_=8)^?OtA-Nq9)1E`m5+RttbceB|dE5w=)%A-_O z1~L9Er||(7tPd47JR8>i{O#0|cFAKj+p*o;%aDT9v2az`An2??(bO*m@#x;zl;3i5 zby<(udgt!ntZg)^mb6XU9G~@WOlTqPvv*wLQ&j=m9tM)SmQU(PNvxBRW2Ed7g&Yq;RG4tuKzu0F z|LX3R#o%jN9GYb~;ecr$;%^AhCUQY_^3`b}N1Y3($WtOp?VArUw>#BBKyma}3;q~! zU)c+j;zN3hTb3AUYZhbHyYf)0&^490-;j!f3kS!Er-fel5F5LdJzL_H`m(*Q1oc4BIzk3-oM9-GQA@Z7D@h#yu%61~}`<4XkhiML!`lT{_J z(We;c)tXWpe;Fsj(ee5w$+od*PDd3J^|2$y1xpW?mOlRCkWFGtM{rf!wKk+Dx-m$# z2aUSIh0PtVfZ+E$oMabzc@GChq?Eun?Gdx8dz0D(ZK)&kKjd&J}I(Vq9tSD%qs>vsC7%8s$g`2nN9ru--z%viklVHbUbxrS<8*AMz z7&qoQk}Nj#MW!W%eP0f*?h`%TP1T9%x+ZW|d1Z#Nfo#e=O!VaUUJ-p+r*tve8N&nqCnaP=bh#L^=B58`xc?8k7)VLS6V zP_fIv8E^=9eWa^gJ@wt{*Iga56mj18Yp@?_f225LTt8MqWt_?p+Sh9IMvd8)J6h@_ zph73)_$t{(K-AxNuH*a6;}&ctuH=VKkCqfwk@>oYUj>|^ChS6KaBK90E+yk`!41>Y zb5sF~cJLd=MopC{=>{rbHjJ9$6V`A4b;KvYyvA}%B+$Ffup87i_dWzbXEScN$aj5k zsGYc5WoQ?Z2O;>N8A8-KPZzh3*0joRwmlpC{b`NU^E68#lbqpm1PIon1DxN5t(Z?H zgWL2JD!Lm&Zw2~hMI|HH9I9nK=mAwx8`&Z8?eJ4ufye31>rj*PZU&2Sq2Iq=7*or6 zi#=z;R1|}IDQ5|H2rSUX1Wc=eBXn!DI75moMK^0Xfu_fYMli}b|#xl&9 z^}6os^SjS|&hPuZ&-*{enHgr@uX!!c*Yg4Ss!gX{U!n%OtAZ?cuT_x?5IF97x$`6y zC!TV^$UNSvab|O$g|JH*LbRyf{*ES*O`qz9lQW38iugZ%uXSGJK zOkwTv;G_P}dc29c*`1uOGKP|>_e;M`Pm+wX%xKx&2dme<*-GObB_uo4h+q1{MqI1+ z2=9{b<=MDLn128K4aR1(m~Pl_dJa9qZSj91NJYg;W)BXn1yvh4_qo$9*nL&kRNjR(_Gw|NmW3VAYpl*{i-v)-o z?M!=rvT|b7XvSAmm(ZT>u>9>&17aH7;zZ>PiT5sk4_LXU=|!G!9r+RW=uIL-CR}I7 zc1|+<-J)s$S*B9chPd2K?&*Q5WM@YFc#lP?10NGzXCHo+KaNc(Lr^JfFauMY9j7s< zm0=ii_xm@_yx-nRaUsJdjl{f9L^m~NsI6eN)*>W(8)}3zhR9_<%oStCI^5#*%HhLEd|Pzy2aD6i}v`e>%_U8FM#Y- zX{zN|KS1Vl3Vn8?R63q}HYD9XX#DDrd;{YRZVT;jE1(Kt_ZIpN<}9Lu*;rziPXP^- zns`$71@QCsyKRB;&5()QJ;WlxZ7jd(>8<4F-mC8kip)Gsawnff`%L_PMQv_J@93Yn z-LmV^Ks%}~U~9VlNgbq&pbTx1Pqtf`JFj-@Mx9N5g868_k3yk? z=`0o(OT#6d7|I%^4+#(M!zTVp8e#2KwHutM8y$ZCNVZ<4qNq;V-w-Z|a_0-RoulV& zFb$}L%MvBf{j3CAHP)uuh;QunQj9nZJ6RO@(XR-Bxq8(2sV8^pnQDMRCX!y&(swPX z+HTEZ|?~k-V+*nE5GyX zqSk}x$)id5qOxLh8dn=C+i2rL^=@Nsu!Huk^6ts?#J$By2G=FzsC~$L);j(EgGDtH zmJQbHWhQwknOLfZ%GW&K^;abqdic`dSvad?i1-@IQV0l~Uwc(M?F!2W)VuB=2fo+x zb*=c}(0hHPWkpdorDYGfON|A&0yctjirCm=Ws{{RIrPIi(v+;HHiiKz5ksu# z!MwwpeK^%+S*K^yG;#OE*Eesu`(y@wJC`q-ei&Qa!oG42G}r zOMdKW#tJi$*|78AOJ1^Tk;S`?q5%0Hs4;#{HqqKx?0pvL9K$l~eM~pG*s?ueIzD!} zuX3^J>APN*;|V=^@$d+yewO*tM+1$@s7>r7>plf@f0&KJ%^%n)pe%uD?ihq%8G5Cf z%s^a<^3#D!^-CiN8?@M=f$WwvCELgE3CP~ICGot69*-Whs3+sGdzQnglttbH7nq}E zxe@MsxEGXk&wui*pjgF*=5S`V=cmROBYU;PP6;hN@~YiFqI&c=HCB*AhmyjUGViG_ z=jH@K^VOD<tKL$eZ zJ1MM0rMutYt+`jJOkIlG!U2FLva*xKG^sIroyf~-sdEltn1DflAmQSXrqy z_Myr*jFPDT?KwYU3ScM%_VQcSL&KFPx*W(hfH>?ZUh3&eMOgt0)K}*oFz5BP;Z0#2 zWi)#emv|T&gQ{f&ef;AaSR1fx1&s>i>Atce!$ld(tc4khTaOTp%p@1mN;q_`xa3<* zannGV|FA}pLUrEFv6~_`(;6J?&P0zQ&~(Q#-KKa1lbb8OBf|nH1k{*W(DXS}+Ks*! zL?nYCq!u+=?b%9?0!^LBF#&-@wY~~w!-p=~(n)d|V&yQadPZOYHJo~rK<^oy2ICOH zI57StVK*R<$$^_33Ytlqs;3&3PWw(@4IIx+cTyW!HfI`txH7DGeeu*&d(+TphhDVn zO4$6as@vx8PAFy(QG-CAKKbRYIU4bO{xumvMUSA`u_FKqdRD}KdE?whJan6Ynt)&r zM#m9=_LE|A926NrTZL}})2CXG(>yrN!9Ny(2)oKjvtP(+iQFTbKsj@PDxWHX0mR!0 zn$o}MB73+#JvtjUCR)8^&9f>i<%HMz$_~5ky*b(nHY?jqRps#iKHwjAIEX-xb)lZk zbTFzL82?+j_J}?7@!<-idT!X`MEgxMg6pOF9Zzqmt}#lfe2I^M%~uxNabG#3Hg#G@ z=-(4V{?Gm}JUnq`B1NrcQm>m>IlCU393~Z?O-p9W^QV($et9onL~;!$9VRzOKJW1; zI`-H;UE)LkjNkL3jdzhbiH{XuH4Hhpq?&JENqUTlvO7P9VJnqmOLV(fJL>Ss@oMpC zOzZsAK+IhQRi5TX-8r#H&-%SpC)?xaTZElmEp(9WpUh;&Du(6lxrsb@lDuK0QBzWX zrytD&xSeNCs&+e*BAz22{S0|k{h{9V%Sru77~Sfm2BWw;CA=FRws|U2NLqnS_IU*< zeXmB%=!Jk950(w((Tg6B5qFgAWA?ou+A1c}s}Rolu6~iH&7JVgNed>ko3~mTj&+Ze zdJ(*9%T+gGRfAe?g}BjeqeIuY-@k$FAuJP*3)c`&5+=&iQ<3T8f?ijM_LPKg>$)z{ zi}7)TsG3-^kEECoL8NxxjBqVcz@2FibO-+R7+BKL_`y<6rSLst$%|zMJ8+9#@}pXe zn7d>{aT>f3LpKojo+l!h4`Zs6-4%&-=L}PlyW#&*Ex}SCrfNmlMnx%2pr;qt$V?pdmA4XN8Fi6 z+QH{hcqi5?)>Wmhcp|D9F(~rEwdza?c<9Z3ZB`~@?B|^&x$TAakC?SQBogMv}8p;A=uN z#hLeUiPXIZlpn574mAhsC19xOkieRf%1PMq7B6-!y$s>Yd`*oXLA0Y5Aoxy~J=)uv z#$u{-GgnLYS8TH^nk#??P_-6(%qo2{6vrr4`=L4#L@YiEt}5P=qhM!P^zj31LigVy za3ZX1YW8Ma3A~*w4TRIEF9@MMy-cZ+eAFka#giw z;ASuJZ(^gUyq9$94np`9QT45SPij{+kI z6qLBNqr|8L9nX(qKTszVARMVWP&F0yXQA%8{UQw!fI?7{ja-gHp}WDj61HOrkFV^9 zGSJ#ghB`?-Y-C5fbs+2AxuSbVog$Ho!{a(mBC|WIq68C$qJ>`sd$dY=o+YMon|kwM)}M( zhNYEaJiki>ZF;bIjjqjp3lidR;qg7k&tEk6wNF%hbuTL`IiFm8Q#Y%#Zs6EuyKK#^ zXN?F_nvHAHVC8vK$mHpLq1z$9pPR2Hga#!==SUm6o32Z`8G770`ZO0iB5ajYELQ1Z zSR{9~C+)5|$A#xbMv6n=J;_LdyrF9m{Wd2rshj!p{!ac1zxcBsw{sjM_7@JmRmUe6 z3^$xhWv(EkcKpSAe$<*))jh(GilW{n4CaV4x(hxRVQw`|q`c&h_>sN$;Og<@mz`!G zt-As-9}5h6WMnasGW@3;+B=;SFcWoLUEFj}Kq|doI@|*|y{9kX(m^6Od_nALLml*~ zqdO*hZYRj^#s94T!15AX(I2#R?>o1-C!wRfM7g-Yduhi2_j@Y#Io~LwMRTE}SPn1| z6i3wErsfkdstM#AJSVAV3jF6y=*AYw-JN66YTldvu@)%PW5jyM)(Qnq%qZ3`_!0i* z%AZq3Z2n}K1hTlpGdhD9o`AwQ_AfM$cOc^RD_KVD-+$6mSn|Wk$}lhl-TAc*Qch)v zG@YA|XOjXEiW4IDD>Ib|-Z;qgS;m!z-xihnDPqu_HIWVOJYk>(;s-+BjsLo*xqCbv zJO1TB_!>Po)@zn^LLnN_Yh7(73&n4swt;qU>%rE`cXO6zcV|LI<22|6FmS|R*f1KV zRq5@-8<7y>|EY;}!3Btfy#+(AZZW%{SD?5F=MD<~NJGh)3$TZo{97pzn==sHWOxU^ z)RC9hz(wkv1=PsJ62uYa4%^0TrvQ&`#nQKc2h@7j5|m4?1c&|KQ|=unptPY1gYYae zZc@@nOMI$d5(VcEbrn}YUY5EE94X+uLf;x$kKUU`MpDmg~2yvCrjf#s}R zB$GBI2r6Pv(-J{B^5Vzu;A^T<>+C2r2W=kd9HrxYwvD>r(tu!67)nH>&xv%IXh8`u zlH?dzD@(dVoZVRQ$pN+wgq41K1%q`1Q0)uE(V2f zr^Z)bQW-2e;#g68`F~^sT6yeV$J_;)gel5L9_x4ntqr#S4D?nnleE<1P2XEna2T2jtJwc9w*arQH(U+M)TFMPG8_#{lR3)& zCR5fQX1}S4M}eb=K0EV8{I9$VgVpwZ8r9R=`t6I!X_NL!Q8mVvLf4x${EhD{D$OzQ z_&m?$0f*9!DHF2$TEzwnQa&sk9#)65D(?0>f4Sn9w7X2j{(J6`iEpU^(xh5V$*o73 z#a@@1hVtYj2UM4CbJl@P<#)X4H{_a4y+;FuW?JGV8_yrsG<4)`)%qs*nb&_tBUue# zwH*v`UOq<{)N)%98CR2}GDA(@*~u@&sToSj|GBqWRq`fXGTA*f|Eq2#Z%tADgD02z zYbi+97u8^K{5kVdZNE&RHwIo3mg@I;GaOuxYTuf%h9m!*u<)XSoC|#Jy6qq3lDla& z*rMWAhdYusb@BLOsSm3#z(7(8OjR5{tXWvReheRzkbPocN!~t|{jDTS%YGEUF0-td z8EhDPwR%K1?~FlLKG7~q?ecy>A~k?FUspMKPUdlbIT z5&^mPi=2eHm#z#hbt*WY7)1TJ2Cga%-eaf?S6ccHAU3#=Z$c9#>r~+9@=N*`O}XSL zE>f3E@?VW+uf^6n;7@=w$%Y6G)eU+W%DgZ*d7%^&hCN1q zbvY-CeZvtt1&$#!k5WX|mDs#T`W?_$W^8*jP*&f7@4(fHQ_jB3Balb~?Ir=?xVz__ z*jvIb$5Z3+a-F_#xt!$;rE^`)_S?p!LfV%ML3nD>7_c>rD;mf?jXnjw=eIKQHU3@@ zb9b-flTT9@ZJ=_~jl@=zxQ+b`g9bUTad1}iyU6R*0vX&BPowef4!%qoFpAal7CPF_ zhJP2>7Yl!AMQDi2vhT4Gq0AIomya_;%@J;j=D9TAm|r(gqckh82mlU znpL{Hwnd5GOAmD_y|vRX@WP2%9e50SM8@G%OAs%V2MH!?bOOPt3Z&Czm}UeF4tR$c zezDjQR|y8qE*-9x<179iq(HzhM3lGivXs##uc6tHA?KTP0S0zMa6<$yz(kY)2cVO% z21+TtZAWAtbqSS-_D==cwTFBA0FK9fIbW+j1ZcZ*Tj!6J?Q>XF9VHuW#-tAb-U z{#S4D|W4Da%rD)GjBF*iLTG|0+cmTNo$&=Lj$I zNi(EIll<4rIL^(-h24dn8FDh?_}T3t{bg22BovzqZnxCw<>2460Wb0u1Gg!eYR_V1 zco+Fn%%=w4PM&zO`gvmvQavc%D-1Z-$v+=Ek!jpE-O-U_?MbXna4q^RFC@XJDaQyk zSg%d?HaXPQ%qTYKv3HlYJGpO5m_J>$L!N*97}8iN z(^Xx&k@S=QutAnflN?1ZvyD&rpmE+}r=LgEqDxmJe^#v?J|k(rNc!t1aq*tgxYJLI z%#+Qt1|7bqZdIo3dz@oGmD?k>Ag5QblXan46z!jSI6XAcN|3KSVc&GYph=EhoaQlF zD0bo|@6Bpj96it-pHXVti9Ndez8eFK(`Nwe`46_~Cb@CE^rfWu zOV#4fXm;z=WbgDcqpZ<`FA7d^sv2&m!(1QZkJrH8s)^iO|IR$$?w6qtkxon&^%i{B zbxPQx#u_Ano$26R`8n=~hhb`HfYhqh=-9{ShQPhnvLm!!0@f*vD}>qD-S7F^%rBu8 z-hQ0Y`BA{1!&fRO&n7|qa{<1@#gc_(9?xpxDl|4QswwUaH7A(GGB`VZU-Ha~G$jZ! zSwm9*7d9GKU`L^h?FuC{`kohC@?YWC{Y|7>5x@cz4L&qcNRQ{zs|r4UCmvB5A{;z6 z!*I-Epo<=#6E$B}vTM#{4=f0uUhI?Se&6 zCR<)u@{X@LN?VVgZ3$}4JMN{!?D3%f>jl3~+GB;`MJo4>j2E1A&~@U@{5Zm5t} zQXutTo&^*so2*a09CeGCjky1U`Rc<0f{lkkx$ZLw+kUtP4017wRV;IoCq=AnAp8xR z_#Dq8ky(3gh0!CB6BGph$Ni^t=h}DlLyrMnCiAm)OdUX=6d-lNl}RU*Ard9z#@=HJ znf>KZt5!6|z)>T8j(bxKq#Zm|c`*)lrj$a^ZT~+nfPU;4NJUW6y$7lCF9u1RgxQXz z^nAPwK_s{f`d9)bg8UZ^mf9v?vI##1z+JRA>qV2}%gm~>HD%4#kVnNcA%B(;ED2k3 z-;nU4RK7K%C1k9*A3V&90qCTS=l`?I`F~=_ZBYrL&A)e%exFp9`!Xl-R}usHL;VAF zvVCToRA1~p4uQ#ss?Tf!FT%5!IaFjbYcWka=|n`%x$)ZS>h}|HYsVnh+V3I7C7V6; z$ur9#lN*XZ{nHezc$y9fW79Q3ABpYXDXGyB=qaZ~bhS7w9DMxpzCf2+fXxQ1H7pzaYj{snH0Qukl{Ig z+V5Y*cA_cgV5^2Ms(}{&Ek(59&(K8mPJz@v1~n5)yG3y^lIh%rb0kCE;=x4#i<%Hn$0Z`?{G7Q(Zr#jema2 zJ-kba3TXahhkO@N`W7wV#|Kg|mviwksH*_8e-Y7wZG&1=Mo`0zF%Z2I z`b9TuMo^$C)_Dom5EZv0vK_yqGxD!~BZauzeXXSP)*8Js?>`fbgxEoZ4Yd9m%K+ds zVlSOLEuYM$RtgLvgn%7-@)!axcTvaUg!;dO-NNpyrR*3$7#<<7~B3wxAa7U*a!lk_UwM$|2MHaV;z_uJKJWMq^<+Gis}g9f$x z4qq9owosAucH2)GdH3Q@T7cvXa{B9GfAy6&#{_uOnfZccgK>6i(RY!W!3-73%*9u$ z+c77nlh;opdoTEw3i}noOXYTx|HLMA=6}>tS^way&M)z?vS*a_JTYy{&=p@y(fegv zE{5VaQCF#SUBzVvqdk(VLVII({k!k_7(iB9ZSh5(x=(YL?gXHaKce=09B1X%wqS3@ zGpF&znvV>oif_c-P}x6DEhd#mgcOH;ERv4|w2V&2ItHkiwq{^@1U3`?sSvOA724Z> z_*f6uD0+yO)$+v(DEr6OUY_@k@I0x`EP>lXTv@LpWgQiPt&d#hpG3!GSph~h-!pj` z21es3end3u&YsUYu<`J9!W=NwP1YCLJi8b5I3c)`!~L7?i$gy-0M}(H?7u)aG)OU7 z+X^rs@h_(aSsSyk2WL}eqi?2g89Y8vX0&D$iuZTZTA5&{Z`OA^9UjRHHj8g_rT6CJ~Id4Gf z21n+<(4;5=U?Nl>8V^r8hQ-Xng_$sE;evcS_Te0Sp<2L~t%O4}CD8dHl(*Yrqb|%%^N}IinR8;#?VMFOD8Bw;iy=g~LUPOs%GO+# zvn5l8RChNomo`1BF3r6B$Koz9sPX<maAX39gwRma^E+vgjb8>=9`*m%5&;9) zOYAT?Zf9)wo(LgWXu!PPbXJkxL7i38sD3zmJ-i}O?7Q+|=?1K{yRZ7OiXgKN=2DR= zr}J#7hIC}+%y@}eDx@2wM*kj+{E=?3{D|ZF^vfJO6$5Fx_>YzqabgwU-Smlzy2yx` zA?-Jo%g+yfk}Q_<3pSB_m9!bKcgk$NI?*UkFjcZhW$r>Ko1cNri*KLtUT68~T$1*w zTc?e4+Ol(E?wd&&Hzu`B*?Myf|N9%Bh{m~d7m?^5MR7ljy6jxGPYW1nbv@?Y5D%!r z*~PUz78g02a(f`}y>6&c)68k#e9d;~?f${~Mv^6Gw<<)K@$<8MO~C6=Cdt=J{X z{;uW`kKqU&tos5;(am0376FoIpBr_c-RU(E-Vv3kqS$i-sOT+GbQk+SMeVw0jj|<0)lK0uCTPmd$!`X%U=T_F3M%86TsSF^D`y6wLkJ>)yk8PP-~h+?F; zY$J7j4k%}Ff~W+HvEVdh57-lx8org&SA7WYDjN<$96a?(tD9$pYaFaOc z*Fi#)+hu^W3M34~kBCv|reMRp{>}30nQnOxj5x*?c zDF*M@(vHQLzZlMAqIX-0c!5|Vrg19*Vq@~r5+Mft&`WU!EH*h<8Q|LP~6!z2I|ozN-uy1 zpRW>7oS*;$XaWE0fbd;>0$lF(b86Ce2xbg=8T?7_y6{d+SuKb}4$g_>m*h=i{R2dxqI z^a0J;!>8(MWu0NT@(2cn#s5u}w|uee(aks=jc(d{X-8d{dU#G z^L&qHUcapmXTg>8f3s7$#!L8#!jo(f`D;sE*Y8-a5CcM=s8$TyRA?$VGQ@ySpm(xI z7aqUbrQ3)8Rj0mO1F2?)Zjxy3{-f3kv(H2Z8YcoL;od7xvzZ&_&J)BbO;y*N$)Pft z!to-HAuU9}R`6!|=O6rpK_pGuR}nh*pa6to#bh! z5shOW=2CfPV#Djh4*jsP*so?^5z%~2sgxreI+8E$RJ@5HJCx_*T{JoDs`XE`Mw@ zcgQlicu(NEy$nqo=(P>LGK|0piJlcL%mEIO{FAom$rEmIT>nb6RvuR|l~R75)TPcN za`N=X<|%wSCja||G*qwqDrRn>^cXo!;=@cqaL{PipKnT4OJ?3ti}6H1kMRr4UF62u zcGgvtSB~cFxpNY%Kep8C7M(#Xy(dPHRrn#25EQ|3W+B_fnf6UyoR8f9OaHCUCKSd9 zdPy>d;^1!M-oEB$0=LxXRdgrLq8wB)v;m~>M~oJL8*rB;!*g3_WK;04RVig9qLY_H zlA(5+-V^T5vJdBDxkCS_6|foljC@W0>{;u;V?h42~cVU;+QN$R4G1AT1l%0GhClg3uaS zfAlad8kSo4?Zlcg!%F?3_yxFHOAldco6CY@)5vDkR?8wbf?OLX+|dGM z!?jBCYX4dZk|a@!?TKGNY3LEqBO?0%(zAPW6Sz?U;@}u64=ZO#WI!Vl>976)6C!XN$Eu@@0LRJ3Ybc9z&7`ez&x4?RDn6nS=bG~ z))7Df3H&2a+G0Nok%sZ;d(8Ti&c8sGp%0Z)CLXA645bG+8&$Gr^{|9_Hl~u zl$|@Sh!M^0i{_Dep_|VHeMMIYvpdv~XTRfjr9Q-15Lr{(@^`}9DRrA9ec#f9c zfB&VCqN;l=JW|#*-Gx2$A`g`_WULe;;r~D-Pe*rEM)PM)|5Y)fg?0vO?q!`Sck2bs zWxdeZJ42T6LfORF2R83CttmWB-Um}LDhe)qW$me^R@pYy%xntT+7;HXbe^yPKUVa+qi^_XEIMI=dP2}hVKNLjeD&0p{%L~4eN$sDcr4h-M<1iUB=23cZd z@FOt_eqih@ebh9on`iFwSbppe;T&aDWo1>gHdXj25jYN5YiveuG;mRkfW+{flQfE; zf()`faA8LCW2xv+-QtYBcdb@^LG-N2hsF`%Begn+KjSCnWu9oBokg`(G0n3DkdF|6 zS9oZr$WC-T|UOTBRqH?Ycqy3 z#r-#Es@a_F*rjKEmwvZ*?NG#S87}~QT*34V{(LT3x0^|NB zrzC$ScPsEVJvS2VmgO=f7|ilTM|zz#?7tCx+tor(FfByyOte)}w}&3vWuBy1K^gw7 zl|t9A6tQn_IQ*hG5(E`3d2R6T9Fi|t)ICVR==VPG{$rECUH;{F1HSllu5g{vUCUdd z2I-QCTYy&5+a+agZ8Jmhj4g?}P)wCUmy%BS3_0rafgzPqwC31Y`fsx35iY5h_nJ=5 z8ZFm{jv^#G{GIrnSbCBv>sut9r21Qu7xF`rtoVcGlxPkw&y>Wfp1DPN29$~ zmv3Uf#vQb%t7M)tEIdnH#V|yBZQsG>7D9<7<*dw61E$g-q5{xVHQeC#71~~LILO10 z*LIL*^r%wNljz_b%CpwH{t?Gu5pt#e?6h9nqAG9QV&?9xWYI(6x{X-{ z35=uCMjM`$8Q@?BqxC^haA;nf3FCCpZK(24*n#X04zRwwqtvLkDi7*i!qL+uur#XD zT>P)E2&xQ-YrFxT`b9%FL2?48C3qT8GJ^PJ}TbyN~0&jh)51@!2r6~~;Q&>E0tC!eX(Ciz4!<#{i6Q{#8*pdGvI>;k8LePi0i_78&e8pc zVVO(H)`034Y$qyU$oE!U|5Mhd`rNP8sNrla{0m;uchCFLX4*ejmu98XYtMi8CpFZ` zun9i>H)t|CzWT|u2AtAes`%e2-2wf70a@4VQwMmQcg6xn?Mr|D{D|m0@7??HYToH| zk1*N;ToYsSlikl3J0=rV?q<&(uMI9pI{#_e(EG3FD=qO|iQk>zNfS_W_BL*8 zWbevTPAC#Xs^scp`i=~WhC`GU0h!25o4cC^?Z%Vq$82jj|?5XB-&Kg7pg-2NW!( zj6a@bcSv-Y)V|w|>u9W;(7ja{QAV$WLzRQ3QTt@2ndO8C8kN$3-AxEI??8Tf+h$oX zVcWj=D&b{O-u1`zX@<%?fvsU|%*L={zfU(}J#d{A;LX_2e>HhO`JPR$eR#}OANCOx%x14bJ6GGem=4At&pCp(~INlEpD1V zk@(L^X_8UTvqKoiCIezmgx_5;`CK<)k*$ACXY0a)RoZoxV7p&>bXl3ig0?4FcfZM) zq&`5ZBD)^3CuuaAXj~sPFikItIGO}36$O5g(+=S)r2I-=`4b@Smh!=3^0vL%uTnqr z@q)yR&bXsRde6dN*IG#^+gbGf4mOuI<3LJfX|5TN5_P?^0$u(ZKjnrc1F}fFK2Ku% z3Muusp0bI#xQq!oxo73#BayDr(3DHk;}>bae@4`$`#;f2QetJ^aLIZf4VwR0n=yiJ z8U4*heDExbn!|@pznaa8ROB1N1xx^iq6qXV<^_W1%^*r)I|s{tuFI0q^t>M~30n*uvHTOXf<=|Tr=DnDE3EdoL+=60LD#Hyfi;=e&B}k! zHlJQR3xqg1UiiF^0mUWFHP3CJN&qRaR+uIK!O{zuS2DUZf^E91EX)w``%t){NB?A5x!|FtTWK(ve$<>z}e&QQ&F*R*Nl>g9>e;? zWeHgloheOQ!Pv z1yDDEU4I{LjS>2N+kr8ivXfBJ*f9$C&KAF!Fa!rrGL@TPq725sNlp@#6Q0^PbV3iX z&so;_9=r^J?NOmCLCDwb1QS8%VlHN;Mko@|e&+)+n$IZZeYV62tgQenW3?ieIg&J-X2Kv|pFu)Vo zjL{AbO>o^ys_u(zc$5``h39tkA$(F@?nXc1By{&6?fJ-(3rm&^J!Xy0da2{n%gdGu zVF<>*Hjp#z2-8~oQrXC@cDP5rCc*%y%mdblsJi;lQsCz+CdLugC9`&AT;acO8fq41 zO@mEfHZHFWk;ps)>4qnQugSBc=oBcG4(sN)PA057W`_}Nsy$q%e+K-z*9&ivUYdD@ zO|x9RbKXz3)NI~&q;dB9@MYA_s8H?L=!ADuF`_@*^?!A;;MB|fFs#%$i{Fb1x$$>V zOE^;_K!tT&NaL??@Z142`QO}^Z@)k1>dw1aw~{qExAalp{e15c&eLAoA2%HT3x;`O zPsdK!C-Lb?x8-EMP2fsA{nLObhRc7Oy({|G$d*!Qzsy$kglQsNbma!QW8dcUH-lWv z=4^47FVa8=tN&G;hT%(}+^~$12S3{FaR=-0Cn!IZ@gr9qQmu?Dq+~na4y=;j{6I{4 z^6HBQ)Y(+>Rk8t=h;}OQ_@DbU)Mv_{;hQ`D^?G1U#=BF6xkYthWA&xEUkTX2?MEXT z9(;APBbgf-omz=DN@hI!g+lciMLLV+Z;A%$B^Ym?US|x<+`EUvaZi;c+cVOivcjCx zClnK`J$5FhPL7j%O<-nSLfpA1UVX%i$7PLoY^@W6Jn9QolY6;%B6n8*wz3u%*Yv9~ z#*;hyCJI%%8L!y;-*Z(93SF&wI&#>czr8JQ;$8TYXQQnzS3k%tr<@weL>aIb*HRpd@I`Cgi`2z zZdge2MBNdABB!{+SH=OUx2f6QlH=AU2knA}K}Yguk*0YRv1|Mo@>RkY>H6*&N24ZF z-M&xF)7{r+X_-$l_bS5k$F)E?MgCZ739_@CzS()J%_WTR%J!OA&iUo5NT{isv4q z-)TPsTzF86pyMbjOrxyWfdrNm7VdtL(}g(ci!zBI32y};U5uJ!YJ>oPZ81(50S4-SPKFE7i<1;<5Vs_l*3R2kVK4VFNL`Ng zirEP^=d#9QSll$nL@Hv}vK~7Jm4~`Wkpi0D^3X(7mLh&n(yqMKC0<=+kPV?W@By<6 zvTrK;`?>{EU#BSjiXX1HUut*$yU!si4n%RhAz}Z^#$K_DF;FFl(b4<`6BqqMW4^dY zi+c0@ zN3&*$N=$wTo|yij&ruhD4WbEq%|hjDJMov7#U8?%B+v$MDKUjc>3jqXYv8YnCBY;D zOTavr2McQ?zf^-f8Nz_L6(?1n^arJdC$*f&gB6T1h>bG~m@hyg)OC80o3%(bVLsyl z1x+^k>FHF&w^h%xBS04pl6!iW*t{_9wmox0LW5DtFOVXuzQwz z*#wcUbdam4Rkvy4Vm(;FpIRS>2rP`s7y*4j+9K6on1Ct_ML{`O9Cq_-emm(G(w8Z) zh)$aw`!{sCZCDYtkq3|8?;6rje2{*)4Ins>o;5LHvlWru@5`#UMf;w6A;b-Ee{isl z!gR$mqxiHOMe3z6Gaa6l>xzfG2UY+s>0XG7e^x2v_sP!xb;iyd97m-{u?G-s3>Jom zcZ{9hsXPzGUeTY1vwsYz2 z&+}+@)cVP_AnLs%rgThlnv8;SyvR`FTlg2m7f$5-++22R6)tmj&wk!qlliQm>!jEj zzCaBtL)q4ugj{jrm9(4x*6L2UD>VmKy{1m5lt-NYZaH&(Ql4XRclew+(K}ucNo|OW zXEnx)Z(R9%)D(Ht!?NJ+XBqm33WqnAl7d}?=zl#$6Z0dpu8^>Noqy^6;cDOYQzz17 z>#Xu(L^okLx=j+@;`X$fA7aW&lMLdcnHu3= z;{CaOqL#b-1}ENE{VDcvo%Cre^{yT^u>BF5_&&_Hq!;xggK_mR4gXgPA*nO$z+-NZ z5VZDpI1t1ujuh+rgoMytK3#KtSSCY+xClu1SZ$Iay@k=_vD)&7P zoyx%JpEnC4*tRV7N#k1m#S!bex0Al3%AXzC_d4u3kI^VH>Qky*w}8Xmil+C#a#-h5 z`sAdKNo{&Zqfz)rIf3y@Y22PU(=1)5;Ci#=)A($Oa3%5FqcmhEED{fj1Q>DlV>L#2 zmpTR8>Q)a=!)6?*9NXD&2CCsFdi^cP^qQOdYB6c$e0e5p)FFILO6Ecp_vdYata9d2 zq^+0<5~YZCPD0PchxVqMYVIW%w{(&Pc60*XPhwBdLRIS^4nXkj;YxUE6;0qy7FVfl z-O&fyk5DZ53yKeddZ<$snK1jy!(wEjEt=13;`&y^*FaM*IS7Yf#xb-8T;)(5rE&E5w(oLIG z97VvoiB)4exvUdqi|Zp2r(sx2o2<`RQhU!q(EOoMxccEf6Tml_ylPngA_;=G9M*!A zz&PViH;%B}ak5bC21*I~^+Y`FoL+*&Z1GI7asAgZFw`kl;|RlGF^dr zl#YUf{G=20(gK-p4&`GeeXpv}EbnJ%L>45$c!kB+vyj8xKP!ei6}%ZjK@}5Ao?cV% zhQsfm8BXPwcJo^lncv9Q>!1wmI3z`g2RKBl!5kv`7byPi7==xHQ%3miHY)z+GJ{d4OhX$q(1RF<3zYrYT_{+Am&sJ%Uy& zxvt(BQkpJrq44_Y(k|z9^#&=D!e~d}c^1ccRY%UA(P8+F>;Ep$q1nH3Ufxj>MYlx4 zgcc|`zq;&+ce-8ZSK|y7Wf-`IC;^5$O|*cwrfX*yuybV!RvE&%zwVCctytJCIdVQ??kS)IN&<+$U|cFS`Hz``2p9HD5no_%xucYCIF2vELu0 z6@T@dn01dovSzjYy!XzSE&im%aCt4)b(&W3<7wusN%%vG{Qp{57u9j(4NqhXB9b!UsRWOEzQb#>eVL8#J38K~O^3`izpPn|yDsgNri6OZ ze`EJ9>1VFY#MWkM?Tpb0f{59tLDS21qW?$Ev2CJ#Q_}Fp-=zDJ5pr0q?y;ax_bAc5 zoD7R6BX{Nd(l#gGd*mu@4P92h+t(~-xEz+T^Lm<--#>RW;11F=RhVIkwO|wni`4dc z`%A0nBeZVKw4*8a=G8tK;nEDQBTv#n!$k40`X@hGTE{jk(<0@r_cqpzBov+b8}8wA zKQZ5<{#=o0abb+SkocIT#3b*Rt7hfqDGRBmJX$Vt}m|Pkr$!r*tB85eLF}|49DSTX4tLJ-xf;FJ=7exe?wSy22A4 z5PFYbCnUo#xb=WvmAt|+JHo0`@Z7o*||~yy?^UM-@a_< z{F=f%RzdP8%rlDNYzq2H4BO8CH09GCp&qy(fOUyYS1`mEi|Zo|blA8mP%P4I-i&sl zen2voxu(dN53oGS5<8Ug_w`XvEiBSzzVyk0PfZXlFwaV*}%ZpTIPDogZ%DH zU9B#kE3dK-sLEaaE_UUB#`cAy60Il(Ue+2IMj{OI{BT=Os?f}Zqe=4{B2s>LDJ!?d zJ@zL(5%qf?J(K(wWvYuU#@*e}&Sog|T#l{84+FsHt>}iith9&|a8p>`1#l`nNcx%; zbFKQ9yj!XHb#)#uB-L&KSXDwzyZz3p*)5p%DprV^T$Z@q=HyKtl%lMA`izC`PZ=Hr zLXSbBvpb`L&ASVnSZ}tlqQdw-)b`8FXUymtFOEoA|H6YhG*cZsB zGpn_7F=TyBpd8`f0Xqa;-6vpr18f{;F11zi=#Mdov^gl29W;E5QE2NvQMJCkM;Q ziKe|=KH{|dmL!Q^CrJc@*aUu?z+n|ZBJR>#Dqe& zNrIRD?_1Uh3E9^%29xZ|U@S9cKl8iKb*}5&_c_<+Pk;Dl zW-Bs*p22@BbX$yOlL4<};fQg|%1Fwiv3s;h5Xd`)c4%SI%J|%M;)pLD;pFgH z<*wb@JweLgiuwQy3ng|m5QIAG9uiM?^9Brt*O0a3`7?jgvg|V`oB2p z>VS7fF3jD^0=dNshuq%Ds!qT%g2*$Iannf$fF$VhzL(Wp6C?JqT!fxX&#a0Bho5TUCRs49TZxKLT{4~2Htfm#;)60Tgkd*cCE^nLjMhxnaj z=Jt@8)YT{+v#PXqs_EbinJf_*7e0akY2O6{r%k*1bCOT?7DEeW{Ip^&*G&}YO0?KE zdw*6x9@nCX4V#4wl1J1hT33E0dF`3t9se_EKyaL~c#Qp->$p;?H)(P!1;4;Q(URl| zx|4cw-UDnF!~C`T+!EMK_Q|NJPVzd=G}iXkUY(nhZyPKG4($unx0GzU8iV(3U#C65 z4P6!Hy<^2$Ld=_m3kQZ-FX*uT3T-WV()Wz0u4;)AcHZ$wv{Tr9C7ex;W*D7J|-zbos=jV>^!A@H!N|i2=vx3xDu-I%f$gaw9&Uw zdalSe|7Dm{%O3usEwa37EjnoUkYH}}X3&&spk4Y{@Ck$?$|CzAGwIw2g>zZ_P^S7j z7quAXMcq`VudZit295LHL_E2(bHn%a?1rAc@v-J=+02b-qYle_M;=ag*N@QBoNGSa zr43TIdWf*|KHHh@iy_f~3tKPr3#5=z=6$%9IOLxjD@Y~E()r7ne3U+3WA#S4r~tMd z)6Vp+n(-s2Z?QFFIwMM)$CPru+qeLv=7AAIJ|jytVygq{1mN>n=r+65d}it$T`1?C zov9q87u=#4nzTfjHib9Hv@G;6YL{!cw`yFnmHo~}w1`M(UZkqh$TFJ58AL3y2Z&1G=B&L?JxE?NjiJXnVXJh8&hJAm9D%eM;AI|KJ zuO)ot&@BO#e-TZsu4?#Q+RUC^()n|~Y3qfRgX4|eo5co@zn=yK&Hcz$`Mt6QL7thl zQ}->fXol#G_DcggorQf|64*Jbf#;psEhp!ry%s^juC|L1Gu!zYf6 zq+JlBqwcd6TG0+HCTIA#UDn}073|0GXyM^zg;AAW_u;QscAaRet?GOc)Dz@f>Ef?@ zt&YCO+o&-iMi=XDtub^y6X5uTF#!FY0BHS*2OihD*Gy$wQ4d1MOFF#sz3jsbo)Cl; zT9NalShrJ~+dmX_bgJy#Kfb_wj0ro6gd7RVkQX2YkI_`N1((?CuWm3E2MnM-mwa`` z&Ii@XI-pU(nASO+(r}Lla-#Gp$Ja@zRGqghPy+DaGTv(D;~vj4L%LbswctB$wa!Vi z7up?@>qG3)bB@MZqLP*6Evp7sS}|1F8N)S5zhKZgvXdT?^V=w0&*mp1r7?!t@T|pyAQ?U!sp6E^qY!ZWKjAG;!CA~Z3W$mq zuh^c#xOb5l0-br}TXh*whzaN-Yv6F}!iunW>ewSK%I6%&sHf4~6XH;HhhllPckK#H zwL8Y7Ds1Lf)^-YvW!;}~#b|B{^ZfHg7$k7Kp%KSONTsLkpCa=WcG!Y$GpdjqAUQhr zCA#N8quqB5j~PWKIX8Bzjp4R$mdXplg%=U{Rx$6<#LrJC4u0LY@LFBoPU@j(IXLjw z-uEL*B!&uXqP0?OKDt7ih8bRrgK5$w>_FWdeaO1Tb>kY;@DZMH0<2=#82aHmbt0OB zpEt+;izlndyvz`ss&vLt<3#!ptJ0$n&?hzJ<$gUzpyZh)oSf;#1;&qfKzZ{~-u)b8 z#S#=1&a1;98IX2?NKG6{Ae?e{F+?$>VfX!ik1kz~q(5Q$7(VbT_Tlr1e4RnmJjO@M zWpyA`=l$YBtAA(FdNDghpw0JxlL;8u54mRfzY~xAM$fYIWG@(LId6?|Lnp zPf%ptmLHt2zIU~R*(lX|i=`#Wsd&Xf>7jB7A=3*YbW`4rANx#34mo|V21J_A!mt*8 zUm~v_nAGLXetjKSc1*hRGe_$1p0l(0&vlG~c2^&KN_0CQROoB%iY5^Zm3?H~KhtKo z-w&+wp8Rz)w=7=Np_V#&-txYPI zb&wVX9_qH^UQMS^j-7Pp)5m}=O7vyRoq3MdftqhK^R+U%SDD+tbmaIg)HU~S3hr+9 z!W!LH>S@Lh5tENmke$ zwFvCA!mbxceWWYm_ZFV?Q!GfvG#|hHooCC>yXQD^P@F1iH(AiFo);54t6L`QO)-g^gdIJ#p=ayYwKg z2A3ODzWsDU?Gz=3!j@+CLQhlQ*M_dGy@n78fci1$dIKe=ts#8-t=2A?*U=#3%9>ZA z5S26!-|HG{UVO=z8Eh(h|IEDTWYu0hYxD!~7~7E(j-QG}^|UHb=i|2(A)9An86m8> zDEcVc+fIAVfnETAn2(L}4V(1oB8nr75Tj}<0k)Jlri-T=Kh?BdCO3eI`KwN% z)*i$ev%u{Xgy#b_sf&DMn*#^6Q;RV-kBE~OB_s}qQV;;ST=895@*dG%VLn;;g)kZ2 znIbju{hzd=uj+ka(E9^%f1u@&R}R-yw@zYN>rNB#!CFx7TT~wCA=DzS6)s5|Hzj#( zrO~zccqnX_ry-53)L7Pn5Czd)N7_z7GhIR#ou|6*-5?(QG(T6Yxj9~nBP6U?tbq0J zQ;UM>9`Vx(6%+501LIX*A`og9Owl=QP*kQJLLGR?z}3RNEC)IEVkZ(sCa<8LV zG&Y}{ak@#>`NIrF3NPk`+e1-~xRO&ONrEb1Yk|@LDNg{P^fg}a#9>k6sdw${TgcBX z57ev+z5%E~wEhl6?4J&aHJ|0FXcrFs8o0j@)#?wxr?2>&fj*JW08r}kGy=^72{{R4 z8%AH@{MCqiu}m3ZHS;T9F9BpKRnuu9h@6O1CkXyEyx{>rOG9Vn-BH<79VG%ZAQbxR zaz$`Zxv)B^vLWmWD_*yY!P$EJssz>}KFq#F*hZ8~DOVzF&DQA2K*h-o&<|iUV<$I7 zstM=QXMl0G<1fFB{R4uEQMD*KJ0R8^7vfpNhDEb#+!Lbe$_E;3x&FrmWQ}d zlRuR__b*`{!CnmTO{oh46G#{qpj3)0eW+p!xc;Z!LR}yk^&M8*VTe}=P z-ss8T`RD3na&kN2j8N49DCVJE*B~YMLpv2k-dWqK=vezE74=un4R6~n^mngk?D$q5 zFSSBLNu-Hl{MI9zs5U;!_=I{VDsqUdGqtlXqtEAj+C2xCDX``}% zcdp$ybW8nUUY>j}6f0vR_+b&@0T?XoVKtkUHXVXV=yFs`9!x_2qHgDHWI%o|#F>j$ zSOfgx=|g47WiP(DiIClcL+|6qCB;5h+jjVc_rf#%MDxF&Y1K;WHRr!~qtJ_>QN5i# zwN#r0f@b_yc7PM!`>W$W4nHmb`#Zx`;)!jh@3~;VXP05&^fX^|IyC%zTHX@PZ_L45 z6jIN1Y}g0KFf}3SgD}jCgXqwZZVBBabl<;?zdv%?2kqh zTR!VXk3`j~(h?-*&%&rPu>B^&5Qk3qjSuT1Co>;V+7dT@hF1%feD}YaXUu z4?SLnpdAQgoG*063t#4un|QpzjTCl%$Y?UL$^$g9-<%fV8Yp_Ethgsh87p#InHuZ-cF8mQ zdwSsZ++t=uZ$`Noq3F@;OCO|@{JU`A_MOqtf4d(>C+r6?(=t5(hEf}lDDKHmhriwk zw4SiiI_zf>MA`3gq><|B$>{x`T|Uc~gom!mG$zP?XSbQ-Aj89#g7FLfW8^0EUSm|# z{`{b&j3ahNrB$W;ya;#BA9Ga7*CcB|MFoW7VAI6>Q8@Vi#khc<&2G>l=^A<+#thLF z)O`+*)D>Q~83*xLU&@kgj1><5A@t^01pkLrpA+`-APYmG1wjTPV&|Rl@|C614RS6J z{k@~UmE;Bj@DrnT*?Vs{8uBk#PB@tI1gPO&BL^A6BK(Olqa|NyO{;Cf4uMTn;u!Sr z{fhw+^uHy*megL|x#R*!oveDuL`Z~!-S-!owLls>EM7&*wf4z42xsQoi&6j|)TTx} zUEH>SkUoQoW)@Yx4b(yBT~(g4Eiby`4cKpcm2LKFwcM(-b9Xh0#Nh$LumtIXWKlgz4a;CpZjfT^~@1|4P z=IJTcg$|SvfAE5|%L7ZFofp2u1_7UMIkZtl?z9Grmg-qnxI?FF5*j*ODmNI2p=@V) z?<(uv-9(@qj~F9BvB#3nMaO3!+E-C_DD@z7wm3 z?dwf>$0rgz(4L2kMrC{Q%k^5sY}q&H4|w!vlMK4&%bz#i553jwOb^zeWQD3-of!^X zIOS!a{hr6zi9YuU7F%rtzSEe~k}F~s#nh0KIydRedCstJ4q2nkJIU<|X#Q*!r}z<@ zdl)Q8laloQp-@L3yIq%ShT)fkFICoqh(S?0FD<7XQY+-pj*|cDfqRB$H?BfVB0!jt zD$X?UugcGkZVP2DsymZ80Hy$D(3j1Lf`%*CRj&P8K3R+)TqRZHlu+0}KWL(0{u7(* zNqTyF($fIM#*%6+Q28}A z`D4>Ab#3gx?N@hwb6lW@U;(MBen^20TxHI0_QxN(JG5=Xk&HOf{$)A;s%soKI<54I zzuMq9>)Uf^)nd}AJs(bt?yF4?TZOuXU{(O9@DC=e96>)XR7BR$Q+(n@EMlKRZ@~Tn zW`VyDH{c1k1nDlFYi$g?fwA+v@DK)^=&hs2{?m7JW+vImAMv+bwQ7Q&M3E_px5N8B zuZq)skWr2LpSwtgeN|U9B^4sfIT8@KIQ&_GVcdhM<8N=90qTtk9sX<1LL;!72nTGg)7{LHy|G%IOyvglHV$c}PD4}`xnl+wHyKBmrbqr5rg*_vW{X2QPFXZI*wA16Vj z9WYiEQfDEpSIo$ms&9g73;<7pn!?N{5{{9kTcBjhQW-w)q|sxjZa-}msnzqJE}pO2 zx5ditynAH9rxmNee^<7Bm-9dZr|)OKYUqFsA#br&Hz^=APefe~{)~VJtpi+_jyy(i zgk!I*cf`4bix=tjPw~|(r!Afi?pE|a@v9w|x&l)d$p=~!Ub_r67`c4UbFNlour&)r z3a^>WAMWLvP4YsbVKwceT@ib&5u*nqv8eC2T!NGBGk>^f1T|h^BzkDCHgXhqa+KH~bh@sQ9(IYGg|h5zu3vn-{~{q%rrskrWHjV> z+q1J&uYCoN_FnF}1?jRnSlyK_`RbZg;hgTp{}QLOt^%*-Qt;?BH2Bls%HIzijK5!Z zZD*;oy`?0bK1dU5X8k!&p29@cwlfT+smN~nSd=n&%<R z)dS_kaKNp#Etmh}0_gj~tnR!@Pu5_8Uh{5Q3~ukFGp-)Mt2cu|QEW_P22b#LHRe&o zb?BAGS@Rx5w}gd{nYeLdX!o~w)T!Lq+ol;p35jSB_P$l^exTYyAUA#3Cu>nRw#91} zols+VXF!6sMu&Fn_()&_CL_pL-!b*0kNpfBk~@}Xki>Q1VRLXIF##ujI8N(aIZY4a zFpmdT$s9tL;TwT&oY46e8Q*<`g7k1YCRPygzVja5BC}Bua+(UixL@Povp-CHn<2Nc z18VJWcWxT)3S75QBz+jOj_4N6HVQ<3Fiw85S0urPIaCeZ?2g?ffoKa-?T>1Uekl+Z zy^xNtCHDvD0@$bJzt8V>WX}xeIO)C`Q>Hc26dz4ezCL}H#K>syfUWjx^&dbFWTWp_ zp8QzGr`w%f4qYyjK>b9D-vvbj@fZ4)X<8IdYFT41tJ=VR83>?8RzonX3NFylp5|-y zNmyEIL7M-u>+f{fd;yyVV^wEynl%fQ2#-d*3i@q$8Wp|^J@swhmM7yae!AToCGSN; zrlQ!$(jy!~!`OX`*BwIg-U+AX?UeYT1&?E5l$2$=Pt_u=S9nft<9(C!!Fn$WbLh4U zv#0Fi`swFAFDwrze~iagV8Vv5`*2_vjp;wA39u!Jabtm(n@r&torNqk3H6!G3={T& zpYYjGj!Ybh?W2&H2rZtWtbiXdurr~-xMh0~)SB+Zu0;_+h^E0^u;!E?H~OO_Kk@uz zWzjVj?VPJ=caPmZJpOC`-a$?3^pSxM+9x8yV7ssX|A`bcI4=ZmWDh78x}T$Q9?2%G zv0(Q?&*G#L)b!FKb(SPX{}#pily>GDkOF`6_hQ#)jhf94!(h3W)3-TQqi>pNz+2G1 zh;TF6k=jS?`H5bOx|P<`HR z!ZG<*XCjigiz=ovRO&1h(#d>3avh_!wZe9RC#Ex2qK->;-(|nkCHk9c2zG&kRHti$t|=cmql2aXi|StF+HvkB8r{Xc;>%9Q+E1hdm2ib;t026WQupfWQUOJ zRc6`iC)3*JAvKCv&?)U5zul0~o7ZGx!HVLZm5y~d}MsB$L>j%xJhu{ zQ(YYX!oPC!;NG9NdDaTVt~&#u!&23@h;sG<+l@3q@srs1W;R60S9_bi;v@nUaPK@nkKRYP0J;tuJCApzn_c;MY?&NcIj0Dp5_dtf*QA63**-tX zs6Je~4qe%=+i--0Xs_;dZD>G#M1+R8S?hFhk{cv=NeR=xmEHl7KTo~J7)LnbZJN0Q zcOPP2#whs6F#Gr_1X@KuUKc11n*G1&Lx2yu6>bA@%3C%As; z#EK_(K&lVw;#M0}?GYp}q0l2@8Q&jOwmxm_?=rlsJJ&dvjzS#xgk^lMF2zqt-FVx$ zmpKvp{T+jG%Z@Tg*447%kz*-qFFwTt;9jd&+f~@)3u~km{58|pw}wvPOAh^!cQ;56 z{3|Ubyr`NQ>~jvrT_3yL4#QTLV(0dW4{)_qZ$8)70g)=GZB`FSqOGo$w!T15ET3#3 z-nguR>))wq?z?2R!}@0320GM8)5QzVLiI%bcZX`;G3GXLNDOa(mv_Im$7OVfa7HRX zd}se~js5USK-z7_Of}pus2xudmj4e4cfi1>!)c|HRjFfe`6~J*Lm#{QWBS>S@A6TN z5V_?$t>N+Zk*?gAO2h!*1Q;HynE~m;S*5^Ffg2h6(Dhja6iT;8B6doQa=tt-l;~p; zBFy&GAg*i^>(6-k!Kr{ojSKcaF&F1`Q*? z(qkU}>v*;;y3m1SO|hSG+%he>j1o_Vy(249(aNvIIRHj>o@5_0gW>X~a%QO{@Qs`S z!4_r5LcyIgjc$f8-eMlkg+0e#%q(|jzVfvAN0+#;k`1Y3|Vdl0K$i7dDM$7Hi{$o8CSJ&B;$?oi6_fyXA zFA3IrgZ9Qp=|2h|#|Yee^Ka*5NDzQs*u(Tesu1g&Gbp<}` z;tu?AuINo~Yae5+NNWtPJkOT!Ft2XYKcHYBHg?gY^$ z(hASr{Xrd5+rN%MdQ-eya_$aA^}W^XO*?7~H08@se!5g48f&YZ-T8;Qdiokgab zisE_9MsD!+w%VtjE@^)nZC%pb7T$ksIuTZ3|9AT~0DYkNJskTnhEis$m}ep;xLFd;itM)Opm^w7|wq#@c!2%vyK<8bi!h-JzCxvRS}J>bT#pxycSwCt${s8EageKJ@w{ z@&uQ$%AimO9RQgjbg^ANviQmUucoriiKB%kP2MVEHq=DQ$!dG_i z^xd2bZyhX}Vvxg~3R@SqL?W5e#?LaPh%*)GnLgAsjSnc)13Y7r%x4qQ&}J`unn7FT zOL1f>Y)N^j_lRHQ9OomwN87_Wt@~u826;h2DV;q`illtO-RHr^ZW9vmJExLf-ASPA zEit{zKO_G16%uDZ+{OApVZ*(Po+tR7-nA(lHcEv9ZZVMy*bd`Z5@V{>zJ_c+fsh#| zcy=w3nH5G!Hr)kj@1K)WFCyUE6CSAeay2`b{?huqwV`Q7fvX2)lQ~>YV3;`?;m@XK0(R_(#qC$4z8dQ${tGl** z2)I!R*L0)})5yy}8;7wOFiYXg>s=As8%6@Hb_r5#RHvtlG=4c8{ROmw4T?zQKRHjU zxs|9z1F=jfdaUluf>%a%;~SvP5|l&EpU63Y@o8Pol{4-Q8nq~et;%1BRVazw|I*!v zMyRGk#i239cbxyMcl*BZAE|qtN+{Z!eyn|s0cUb4Vi)tCin16z&vyOO*XXx}Vpg=0 zaCvol3e>}(Dkb9V=6O8e>G!a%khk>V>$uF5C2#$-Gw|L8Py#iIwmihl517XsDLzxz z9i*qgPk;|Hs~JZ!cZ=B#_@OY3!IAEW)#pP~*w(g*x}=tMC_g{|su8QrDCU-ELeg=hi#xrqJ7 zWhwmTK&u89Q8zXJ^lFsK1Iv8_2XCaBqvWS2V?2U{iM}$U&XEg{_m{u5v;2E>Q6)1V zpveFARAk1#9ZTqIoF=ZHKXfaJ0~&{fzc_`0mlm@|3Y|vQA71SOws+?WDvbRyu=DoV z@BDHCIfo3Q(=<(!V5 zW5tlgVtz<<(JKD|lxK5C@?hdycaiAUZTg`hRX%d^=eKj!TzvmZJXg2E)(ubhCx`Wh z)VEj=X0#>(tF9K+%T)!o^5S{bN*gjrPASmrPEpn4(0@2k_yz@|hRB_mTNfn~1;EBY9Jfp9 zO5XDoOwM(kIivP{9~WI%y(-;9`RJQICyrRc04Z#L52dKoo1O>Aun1P0!{ga%|6TtgyjG z+FORhD*Dm=NNdUT-t#8{tDh#Ge{g8xE<27@UTNXYm9#9VzdvqzQjtJYm?0j+DIfoB z{Q!66{OWn*$6XnG$pL&0I?f+O&4szMADJ=$o+ZQP(r5SffX_#`=@*2;e>T&$*Jm3r z|Fj=nZCkuSisvpuZL=gz$B9DUF_{N(<2SAd{LJ-L5l@Qfzp4m0hj|AkpJ1t-L64Jb zwUX7+ZkZ1Kr$w+1iV>nkXofZ}D>M*Q6@|{8ul#*joL;A({0&i?N|O~1ghJLIG~>@} zQ4WJJLN3NYA~(L5jzefhiPfD?&7A8#bw=A2JhmlRSgrZ)M?_%uFiTVXS$AsnX-9sP zf7Ln3{SU@VnfI<3ebXj-u_d~=WWTS?mLrB|0|_p6LFsu5{IwlX8B$&C$UQ}B)Mro1 zeHU$+?kpiSncjy(^qcgFSmAn^mbrOLht8VCh#|vM5#cMks|xHoZMBF+G3d|{*`h_r$mMQ1?)gQX=i@Yys9JpBOqP7ot77n zpvB0f6y2xNSG2Vo5j!xtr{s7?lME- z_iQ!);BaS|OykU)52(Wgv}%Kk}#Z{v$zK71OMY+Vl_YoV)|{yg@q> z@QAAjndcI{nj^=k`Sj&BSruM}9zW^NyYygVswf50z5n>&Tq3orxszw7mMgI{{Y4yo zOQD28DudZ!hfvDCRhIp(|8!0Im`d*kcbj)Fdh!Plx5ga6Y0-Ej`27^%gOU+&V^u5uZfdq76)5E(hGv zi->2qpHn|FdPQn(a?v}hpdQA#YAE227;A_@JN9EhZBZhi#|T<5%J;fvM1X5xt6E_H zq*brIGLaIT{P2H1Ud#u^pD67AI<&`#mZ_{MF1+epdnYPytncU!8x1?Fq(8UywJW2e zLksf@#Nk=uyTp@T^#1QP(KG+`vibwM6q$8H@VKEvYsen5e@vGi8IAs=c9bkRWQLOE z)9CDLZ4!|&UhMQuAk+i2YqcLeafo8;Q0y1dlf5=wQkB!?aVzU(@XvyvJr|@JK94KN zxKn-X_-OxCfDfoPyk*NtR3LDHxZq7M%WZGF&~#_jL(taJ0yxu8L*oysYqkl56>5br zb-b~o_(Q84HxJ^2mZ0Y(E@HPb_yw%X;s(E+YUB0oRLmwg3wRodwks@%uvPs#S=P%J zB%_CEvIHaN-QdJrmH?^4?Qhy11xp}TBvA5^1!knAbU4o|;Ewfz_r{|741DM7(jwnv zaI8p<#aO{xCXO$tOfIoq}WdQjsC zTq)N1P4{f%x9{u8!0#PN&9pCpUg*VjK+lCQ(tWck=c^@6=89fbbwcA)lBGhFD*k-B zJ~FJSefIu{6fy6OzD4>wnRC{%&qi7e``1N+uX|oc48HcDOed>iOPW71l9-yJ=E4mdVQIhVOKb!eVz)!5$(~w*@s~%6 z(F@U+*3mFyRl{XWV`+DU z-+Hjoucw%hOiORsJH>mIgBK{5hFfFQi}|(fU+t%K?~qIi`jZ0bb{+>mlpCq|@`}$j z?SkaI#q>1D{rM=FZlI$*TbeO2@SB$R@pmPW8{1n~W#>nf7G9iH`sZxeA9U!R8=w(PQzU#D+>R0ZfGF>hj1)f3xB{hX1ij~{HZy`2W%HHF_u}oaBnqvNTTIErPth<_T(6`)h6KG>j8Q@o^PB? zteE1OlGhAJy%k<}j4Ay>9aL+9&eC@nrd+@WEJN>V+_D7OIZHTDsncip5^p#I8mVke z9`KMaqiro!{$o!yPCpg}WY9av?2IaRl5|1X1G68%Bsi+t|+oQSq5qbuly z?l*0CC)Id+o!kejF-oCz@H-}y)Q~e@OO1{JakWp9>w{|Y6n~BV0`Uo49c&k&iEJ;> zNRPDp7(72=Kpg*iS17j8<`2VSXY%r~5-JSWb8C}X@|>d*=Lw#TSdtXJuZpR2rU%;3Dg4-%_s05O>uj8BUV#cT|91SPz31+^uUH|E~WZm%w=QsMk zW#w58DxvWKBx03$m6_tgZsH^*BqbU#JMq~_BoI|LB+;(s)?vJ86dG2P9Uh1sbKEPo z6*@`E(2$?1UO0NNSF_M~I96|6HSAC|TDSenC1}e9R=>NJ9T3?`;264jOV^7~jjYL` zI%8-M!leeg-E-IWCkpg_7;ZhXo8Wko`^KEIs&;D={r5< z`vPNb;gR7j^J@83qWym93NhJ(&*-omS|m-{ONV^99Q5(W)izDzm|S@xj3RO&q+CIFhSvD{4~Y9n*@%3!o5XORNt_1FvKV?ibrRD&=bj715`yaa`i( zi3{J?)Z&45kwAMNYsijxx3OD$$T_0)#t zxopTnen04DHB7n!S<7I=hn%kt6@^?`(M@4X?%}y{?&Oppjuu~RxAAQoW(uiV5#9x4 zRr#95Augu(%jvR^wwL^n^Q~n1Xrm5VLX@|x zTG%XPfn79r?j_IiHO(S=VVqgdd#aL7Kmc~J^HF7ol4tx*P4YF^x$B>nOwnE~o!B`p zqo@1of4+rVulq*y(M>jc%cdre+y)BMjZ_(5Z&{bPTOqVo4{WvS9^+kx!PHFgZa6}B z3`-eKVcfdy<-uWB_q|Jp8{v1+ZI%3b3;J6j*VWezUv6{nuC?p)qL+0AUqXZTbcCHN zYJ6Of)V-H2P|d?NBZEA@4==cH>BXj!5g(q*Mk<$?5=2igg%ewcF3?qKXZ=1;(7iUt zrB$6CQZ%ja7a%^^6F>I@SEOk((YL9(wQLwXI-Do1;duql4dJ`j(I6Ob47-LH?V|RE zgSp8Rb=;}T93sa4pe`H=@5I8O9b=VRr|5j2jHk%0g{>)@e7H}g1%r5q-gfsRuENbV z{Ed&;NQnC+83Bct+&I}ZBc`kcYf^=8JlSNHYNj$s56s>9Z4ZLbEBdV-Q7%Z-8l8c^^Ra!s)|A2g=_uztFiuV9WV zd7nrVO{YGuLCDiE*Kj3K6?GyHV(I-9E4^kOcDd1iF6S9lr9gRvaVd1wgx^f{P}qG1 zOD?MY!uehunr4^t*uDX!hFR8>u5(EmbldZ#{a>5}<)SeRI_OcJOs7I==}^f>E(uI9 zlKzZ*VM=C>dCM20vI+$fs6QEt{nIdd(ahKWg%x#OMWSsL>g2p^&XL0+N?xEVM~@jo zedAAd;t|JZ$Uo^Bicz#(K6?Nw5M*~wqQWi9<6ldknEUkJ{yDNdNIA;n6 z-sz6Z$)|10o6EA&VvXc&9(S$7x8Y$l=C|II2j-lsrx%F0qy7`C#58Ea@6Ta0w-bg1 z-4cc<1%_-Yfb4A54j!JiS>t`X^$NGtsRN3%>%`xJ_eBF&Qp1HXcHIS*xIrOCvd9|m zMpOHrvmxCd71|Fj-#9qv-R>VaYgd;ExuzddHThyN?8ArTQXTeiNe68<0FE~ z%_Bx9JvsDB7A##XMeKl&xpK1W1>8eYhvR0f4`%3+lyKe6f=sO44?n1FeXX?q{gScjpTH~s|6N^uvcUi;h;MHf4UHYZ-Q0cuiK-$*dv**V}W?U6CoFXMy;=@G_SCynU zn7C$nuM{DlO4Y}W%NK}T7JO>70Pz*yzgolXPb zkg7Iwgb>ginfIX$*eTyH6mi6bcIuTC7Yz%JT`y67@O^s7eH2^^+rodWBG($Y&(2CK z#DX53M$Bqr$Jwx;maQ*>Vk6*zR;Fc!%*HB0Z{fVw1I9 zmX$V_j$2$GaCo#+AE$S9w!v+=P)BZ-t$O z3(pLK^2b)=(!tE+$gOdW0>dkRPip!4z$Y^&`*yhfxIZ>*xQlwjRik(kO{015TO_1^ zF$nc$0Ep!Z-0Z$Uv?euePPIZNFP7AE+l?cJpM@~2ZY{pHXo#Tqw1C*|n6cV>>Lt98 zi+2xY_2&J#(zwUcSfKkH++olAWQNp_2G9TWoO_l4di29Dicu5MvR} zNf$!Oxqqy=C5*r~)u28Dfl8h0r3Gva1o6>Vc0|9>L!i$az)?|y($e*~t4w;w&|LsU zw*&7N-H3J-3*8x+NQT}pd-vfvwBsD+YPL8%)OViT{QA*+=PAiwNbB(TZA7rAn0`sb zb9Hj{ORt82{IFkHqb`Q(C=iX84FgTAmgmUlp-aeL+*AqEbSc*=wOkDNQv+2v;6}?S z{B63JR$_7$XWES+d~{XgV3wmfbhTOI)UjnH)fy;zl&8XOj6h98mLqhK!Gzd_+p78^ z64Xg^W^bHo>6OMB&4NJ-gNl4@so;i1Nb~HsCTuSorUeP&^JG&eep5f1WJdV*oW_aJ zx6~!6k8s z(1xbkx9@g%yyfaSDCL6rli4;fRu1if4OA{aLQo6FX{5nDcIT8TGIl8qmRWR7b({OD zY3znl8bF=iH=S@r5Gs_-Nhid4Y9A0PKb|6%Ue5l$#V?%>y%fK{n&K)0m8R-UdK#E+ zirOU%Ybic+pA0neYo*`9N%$GOk)r28)l>p^S5L{g?@r@X?l?^xgqh|sq=leiU_9y@ z;-H^CNip-f!oc~2b6C}O$8WzgYKeyQNJ@m*Crq2s;`;IJwZ_h&_)D(BZMs6i!&qSO zZ>F7=!FBsb{dph2)(tT?8Suc+42d8J15oyn`rbd)x;)05YT&TPD9~XBZ_OTOlZY4D{F{0UH|-{I73mKsT>U}y{TI3} z_Q+V#aZrmq>w&o45wP`)Ox=ef(tY!X zLvY`>HKJdng3+t0UfPMxbp>{HHkaO!Y3{%^f)=&|&TeloGNq+v_7y8V!jd?h{89aZ ze=t8WETS97U*z-8mXn>cVwlwg=LHgN8-wz<>{ERn^7sw~OiY(@eUM|>?kV8OGkD#g zw;Tam#Mi1L$bxn(vi&(>l^Fv1+y;`84am$7%|bcS4spVxpJGxT+b#Tn`~8i3Ge_D% z+a4A1n!YV&GFUd#cj705s}a%hO}k{}$f9X;<>EEX=n;$qq$p6&^3o?&k7{+&xJz|5 z%k=gn+I!^+7AQ*vAgmCh%6o4F9{lV4mKcKMa=3PjrTODr&Wr16u7VO`?)4xvd_Vlh z9>U{$kfz||fY3N< zWE3Vex$mLe(b&nOba8|H-2{hmXsi=@ZZIHbYYsxjf{{6p9>B{=|Nf_E+Ra)V@mS$7 zKqrt~sL#Nb!FV-CkAvr-rxUTa-)G&JTrvg_=QDeEw>IEL*c$4$W|s)uHKo_r-~5g( z1ZKK)iB^1RHF9vM)jky~%-yZ(QEw}4&|6fkr=JG>Lg7`zdt+D^t-nT&kUy8xolEkoRkF^%Xu#TuZ=Px7>SZR=coUn*d68 z*)P?&DBAY%uC*}%R6q0Mr;=kJ)H`N1#dygNT{WAtCKiO+fA~12FtTwRM-!;goJ{BH zHfEUBUX4@V!z=7sOHViW1LJ@B|IX@ibo)ymU4K>o`MtDgvtrx@2T%*kP=mY&(PtRp zRi& zLsNd!ME&>&7Edk@M(w1ZAX1=TJ~O#UkaX!>N~Od$x+ER<7>VEHWNW+AvZ$MrRCRqZ z1g(f!8k@EAS0^8dv85}G6eq%6(c)P??TgL$;i<9H!;E+!5p%c8l>_#gOG48!=G4q5 zi(d6eHbIx`^@>B$AJ8LXBBJX>KBeN8k~;kjMBq+pZZiTgDVpV!^)?#fZP5I)A@Kj$K|84vznTk{=Uy(U0N!er*1=e_S;_xt_bcg;VrvI1F?IiGXRKKtzL z|Afc-p6$%iJMac(;>nJh`fAV<^BxiL!xoY4NvEIu&r5-gg1tPlL!DP+`_BtL%dYo5 zbEjcwwK;ruEb)}(fn?zI_gAOy7>YkKy%nXFqCH3sSh%8RAKRR9iAT8BxTS1@1gSm3 zlA<=nbMAbJ7tc=TG!sY}pA@|ib_Q#6QxGTf=y!i$mJJ4HURSyrTPI&H29Nya|7h*G7)>}Zl@O3IV%k|=Y zg%(t~-t)o!z>lnoj9-LUk}>1q-cxpc*!4k4X2ICK9L4I=?TaJB#@f)CQlI%uZJTW4 zUG<_0X2yz&p!!vZ(A5wU_SxTIznSclLA`32?c$>y=)IoNwTVI96zPxiZ38bpJw0#s zB=R%eRXV+8u>5g9Y)?zcfdAgyCI1+?==S^2TP?3oJ(+4h<{~z-FeaQc9jA*=v3fQ5 zvlrd|LS;@1;)aPTM2yA|mR7PpT-<6Wm4E7-6O7#A5m&4bS6{rzFAlST!Q;D5Chu-W z+~T}E@#OU|&`rO*=dc5?Z+Wyr^#o~HpFj`c_qDPME*hss*LlBM6X^HeSzqxX5}4VC zn;~^$4c7U%F*@p!r*CW3ZxLrg-QU`PgaH$+zW2Z?NByY>&9l1o&R|Ih<#zjz5B}Jn zr^}ljHNoRh!1hpO6-xaL-}A7)tvEKQ{v~V1G+OJ-BrB<-9ToxcZPOkaU}@ySt>$^r zkV-vQiBK<}YF5zE`nw%dZVnGSDD%!6K!?>W$>6a_3h~&~LFd8d8W>Nje(`x)tL3k*B{Zf-fS__b6-)Ed%p(v7bHIbWwFuUs(azP1k z2fa^in03WlZ|6HtE1+aP+rhIfz>idpv-SZu{0@z}a~F6-D})Wqpa^y3@-81x9$lFn zgl-AtW^vReo`JYpxJ5GO2>;xscflQ)Sf~>dVfz#Q)cpu!H}N%%?|D8%UsT;0ReU!S ztcWeXMsc&7MG5cYJbZ)^ttqsbl>X41vz+?!z)x>TUR7~>cgt(MO7#Kw3eJHf!P^vs zvq3~;77x9e$7H65ZO!KcjprpMH!&ew?B2!#TG6&8&ZuPx^)5v=QFd6nef~EZB>t4-?#V z^ga+kEQI*IwO}s(fKSmu-X}|VU>Gxn=BQ~rj%gyj0(7AgIzd~>3F_%2DHHEn|6Z9l zNiIQ0Ja)_gG$BTUKiG%A{)u5lS6$lVVJw{wTgZy0uY4xIS@D-Wjg5b-s4L#7b6+y- ziha-{EY^Jkb0Xl!jnlTi_KV)X(}fsI>hgPSBCh|}SnoUT=-x)x0F)8H+k9i3*QGG@=I8RKid=O zy5Tapz`4N+IR7{upX0jF5`W;V;`4mpEzH)GZqUZLEP90c?qy^ZvPmR_es1}ObpKt> zRWGd2#ha1-FRlBj;i!`IBav@?zx63yQ=c}*?1U|Ur+TBIZI3aJJo^>SXq3qPzdJ_N z6Dw8vI1}EjrxoZ@)XGk{ZN1|YtxKRuv4^5CU%}40iz@h+w$*5b51mjC^mMCR`>N7v zTAL#ic3jq6$(b;jhXS5vOI~nFkA1gAb3b*-d7pfMha0kBA<)Gd_Z}EF^r#cAuE;Sd z4Dh!PWmE;|e13g{_wu=aOV?SpfM z%J`W{NtmA{10|{s5q;V$y4fV5fIWr2A(1p}X?x#j$AM>eK&x5>6DV{1&W$al-5L9x zTQQcZToqRZ0?)_(NvYP9evme^hWX=a14>@?mnl;qte5u2tr_Vg67tD-J)VcQJ=OKj|L)w)@lOu z#$8v{11Yw1#5X@2!f|7l(k}{FXGPiUZZG?)PWoA$PIWPYJu^px%f`jB%pVKZ?A`PA z0Cnz-w1_{O9vvp-;)bgTgjPiUf9~yS_9pQM23ra3BUSR5sC6)l)V>pY-Y}jhGM(=} z#n}5I-p-<&8|-b^Or@U3(9bampXP;N?~VP-W634nhz{Cxb{)fi`mTLu3zY4w|# ziHR>j8F3Rxd?35d)lZFIIuaLMt1e*0F;UP8|2|QfIR3!u*Y+x}?`RoD{aFQd&-v_I zXoln*nS6NNje>qcxVAs{;37)>>r)a(JCj*MkCeW9`k;2s5@pi-L12G%0x>G`E;%J3sV$!(TY4hO{_nT}wPCTOtEq zLM70w>{!^mea|Sr4;`3vn|~krZK=4=t;ucUww9qe(eqITCEGrCDKQQIU4u&JQeZ*WFhjy`U z>mQW0v?%##%8`$exr_44HO7YAeTfxCMtmomEJBTMSasZn z>UQ62tiG>XcRliFhI%35mP5-(B)W0&tfrqddCfOs6*9Qknm)C6uO0MH+|ZVg<8MEU z-5$W+l{EP5jyDoN^%bkY98BdpsGdN*s>q6`K2POIlBX%L>z zcVeh}_r437eDVacyz|CM%Gt|KWb=LKn)Mr7s@H!H?H;fWEy&oWONbkL=+JQV(z-6?`n}{g4{>uD&?8LdRl5lHY$>w*L!x z#a@tKX!|g%9J=R~446-rRle0SXi$ME=UivygnQv{nQPBgs@z1V5`NLB=b8fdWj$|` z!`Euue7XzJBahxjOZFye&6*FG&>oV3wTgT`DUGs$$J(>CS3{>qq*u{IFiJ-`%4n`Q z@rr;Yk6QWdmZ1}Ged}Jp&Ta8T!gg~!vVp?3POaS{5y}eg9~uww;)&9$yI1khnn@qr z;9Px0ny5U>rl?h4^5k3?(dy?!_ zmTP!&wXmZ1pX{r`Hv%u%P)+T{hYyVj$kMzpc_-)WqQ{4Fhu@`gpFF|153F*vUf_@0 zo_OPi_f`E97OCV&{Qm#_!A82^CBca-7y3h>LQ!s9=#+1{tbZy?EfUj#Y3Mpa?p*2m zNuK(#vZD$&-LGAhTJEo^Q-lIiJd)%B_pX-y zICAuBTflrO|PNcYRDZpd+T(s2zW23;a)#r?)_g1L7U*}Zefv5$nlkbZ#ga_qY zkr_PJgVtCExxb*JIps%8S8&5I^`q?Y%KM=E0GK7j(&6;nfU$NDv&O?nnc5SsW8OX_ zidi_A5pb0hKTaA+43xw=@NXv3Zkr*>+7}dE4jQC5#sS41&yx!U zHg7xVIVAhWXY?1}A7aLT6ZFeU%=rMX7dQUCKbn4e@cpdVi2QoCmyXis_fBEAMc&|6);awa7*=`-WR*6qvAnP%$$MU_LhaurdL3`3 zOMERZ7;ThRinlnC{AZaN4Q^83mW(L{L@o_4x6gp{?=x8yRL!*5_dL8Oq6xV_e{?CpV&BMlAzJU49qY8@Rz2v>?5VS!G9Vrb| z2^|Hwi93^lp5l{wc8j<2HB%oxGVm=>kWMu=+0t}46&Ll+?C@I^;|G_F+$<+Qlf*e? zuJs@8yJNSM>CC|uFP>JZ`m&a^RPUALjkAAHHvZ2@$+w6Rr#|V5RkB24DS~>wJtDt4 zV)h|)-F$hHbsQda^PSC{0pix?6hTMtxN6-R2#(R31CkG+1s6YJFIf^u5#cNk821;gp_&P35muG$WtI zZMeF6&UaYW03JR$hqiH5LYd(2N3X&A-f9P?2aoEp@L@}_Tca2r0&&%(j@v!ov2gkv zM>v^u3;bkE+`Tf#w}WwZy4tw5Q~dR}<1TBJG?Ec%`GcKfcPq!F$Zv7F1)}e5)M7Qn zUUZTh*4b|uibJ#V&4|8tLI`(m_xHzth=vVee;_E)-Y>)j(8J%NdM(xQt?Y)bd#HRe ziW+v01?qcO*XcQ@%Va?P6A3OIq=tpdZ?!264?Sl6JR-**^aKWtxZpM%VhG2&X!&U> zKe6?fT2PR5Kj&l!wJdK&Hk53#bB{EISWO zFoPDCTv}&Dv&Q%VL}+T$q;JzC1~X}RHWq_RV%-B>SXjCtu!FEOS&L@g`1KVRvx$ef zj~+pf)+!GMG5a{js;ehQGhA=(?5LN0Ts>zXVg$*L98+Hd@0_2ULETZ~hb3+6&%E=p zseDF{r$>X;5AWWY^Zz?-^4H=iOoW`%g^?mV02hAr=S?7T9eDS)(dK5c88qupB}pgKRhARaBM<0Dcv4U{70z?|3(FbM(B^kF`T zIepcOj=0x-2!Wnl^LgfcyBe<@pAB=u+zeGNUv~N9Sz9M@)ePoey#YrWvfoHK}dl)lESpTN z#4y@0Fu(8Pf|9BOu=+hTq6dwcoBRN@!t{IkOTd&#<83!rBSmV5MbYBq2O^f-Mn~(= zTP2PKP)ygC{WV1vkG+OO);CYIYY>v@58Phh=9B)rmHhWN*p1zjxwDRC#Bafxe>!J{JEvIEZK^XW*c zX_1lwZAJC|w-&%e64^f1Uwr4?)QqWN$N2es+2Mn};cvBF;soo44(D#l@#+-Zn)!I? z;E(E;geaNn@-rx5v`g)&LA9oct3CWTm+y!dPJW3j1mMPctgmnVh34bEw%_ZA)42ER z8>V_F$^FF1&K(~z(k*KYB{_VBn9C3LTL+XR+~uhX*_4_7MD4p`&(rRES=;98OYFck ztv(zfzw z_EP4#fNh1@`-qo<&27bYv=q~fwV(b0Fl21)$Z7W=Y$xDB^>CTHC9Ek+?(l{376;pl8u_3TX@XpY2 zjp540^|5aUb5g8c0KW)(u3KHk=O(i&VNUK*HtdS41=)ej+nl-W>50O%!*4KJV_)H) zi4oBe;fJoMJ#BynuarCXO8?FwEq&z(m30VZy`n{rtp~#LhQQDJpT4cq2YSS7Bx5=j z0GXB79q=E>Q4z0GyIjJCL^Qk)EvE9%M#gWPq=DeAkHB&duchmoAt_o@9E4}0sMv=r z3;ZVPe#1y{EqDV&Q-Gf?&WTg7_@2?=wHTt0=iwKI-Y3aJ(MK<)u7{?J;XkRYJhu2= zdIaw^SrM&8U2xLwWVmH|C1H9WycB{<6ssc(Bi)bAf9S{|>|$CT|8u}#gt?6!YOETl z{)OK;1{VyYUhFL)Q@eslTCmTiV7EW)D|6iY1ynF{b-B>(aI(9vPI1H*g|mea6MX`h z;!#W4hUauLizq|f3(A5c}xvxhk(k#;Hv)_N;sleF3MGezq`NW(CQJvkX^dyG#Pr?|c z6*!mXvrMt-!&2H#ECt;tL~hSH37DHHO~KKDw@lj6p-AtEHq=-E?R5g9+JYhe^E<&v z3#;&X(Oo}1+`iP&<0+6#xCw28g5*g!kFzLfsF8hGVa&hUejFBunxe9yS0JL!QD;k9 zV|`1HxH)@@NQh4ZyFz1G(h0)E)JlK?%AY2~VhE@GI%IzluH3>f2nXmdNcJT4ttFRj z`c$++m8R=T=zW~$E=ea~e5e1ElE+*OX>~z@$8Z(@0x{)GMQNW(o}tUb)R8HMDw*I8 z=eGa8pdZ$Ufn#K0u#1U$$i5qSirrCcZc-1i@N9zbK|XJQr{D=d1dfHbPhVwkAZU3m0|QfiR+5A*6xgW~=Rs*UHGT(@mGryU>3IDYwlr~kbMKU$Wp;Bh{i zdd{uNk1Y#bMX!)mtplIe_SW)DtL}CsD;Gods^!KaLBNYpB2H&91up&|xj0wbJdF`2l@T0kJAyKJqK_EoZ?dX%2gB zVGSE`g-%lGXxBA++Y2i_Wa^^2S)1i`>6C?5m!8&b^sl1SS0&TxB`LYRG3o+Z_Q1qW zO-ypf(&Xbq0>*u)=^Gr_RY^&fR|;?Xr zFhcNVcoDLQfyP|h+M(-00)&Qsrp}#857N(C+T#4Jcfqtp+8|$2bsQ#61N!wRK>%@v zeF(@>c}C|iYcMPM!ru{@funwH!-k_jj`Y~WgV2Hr=;d)mvEk$j&;5KDai!3GeemHo z{@~?7s2}y`nD5@4z&Oq}4MRdXzN#veB1KWb9lrs^LZ$8#5SdN+lnMSk|`Z3cy?&K49dmFv3 zL)-Mt`9IR&EF6|E9*^k>u19<)s65o6MfI01Ptf(WtHF_75pgD3j1y8F?Krp&vq-yK zd<2kO(Vtf>nj%eKcN&h|+EaYX;PZp1=_GLM=w`_QLTUF$+S^Sq?@t;N_>PG{LISQ4PQLVH>FU`-!DS zxr#p-Xkr`d(fG}*@@py9{uX_i?<>t4Ewu-p`VWqTV=gLMSVn_aS6LsuhK!=@0u?`( z7AbM!h{}Kx{#=7UTWZl`V~)7`QIt%5-qV`79AotqyZ#vXhRw8*o_LhS)<4w!)DJg< z&AC~U_`g*vpSP^sUVZ_4*kX1)7rJjX*_IFUo=qvi1#Z4U@uVNPFJ!2e z_2zk)F*B!e3$4<0ax0I89>NR1ImV*skKhaRA%S64xhZt&75ZixeNx`H@t(%&*5T#; z;+(^FzKXV?McY1AP=gOtSVLQT*+GL|UI%XmGpvyhe*AVd;eg~{6xpmkI7A4Z2~>%& zCZDXiF?C#pX0jm|GEWNzLwX~g4AJBD+C^CVkI--hMPH@tJ#y-of6YqMtO{%38K4Qy ztwWM}C@2ODD2@adEgj8OBL9t6hKRO8@IZgO_`DgSn3}LdT_%n!!3`(1vl8H;BIFr3?~AzQzhs_F^2@NnEpfM3K0Ra1`MfD zK<0F+{5WTf{w)3|(23zlmm_;8VBVbHhR;AXV-zcGzg>B#014p=tj!xqlmPHBa#y!v zhNmOp01-1)VkZ{%5~~TR(5#^Ao7nw;^_ifMRJtbg_9NlmI16?2HC}&LUL*&WWNPex z1KJ7$7lc5e;hD)z{8rML?1U9MUv)c)ggR+6g(sudgc!_gr*=rvKACqlMmy%;ar1&F z&fzJ@^cq20q!I^fKTL;bwc+lxLKyJj4)JNy}An5GWBq5qJ2 zMVA*UkhLN&Z=xAsJ{_A1r>x@Z{49gZeVY)zQ~nfD$=uYv^X%|HKteKOt~DsUKMLy|N1TX?5+kb-)q={uU3| zZ?jX4>-dqA^521#{DIGovKg17?gJmSKi3u|4!a1xFSy28rc-8oCQ->_%2fZ6z&2o# zH@-5YTAIIZ^z@tAL6Pz(@e=hI^K#31eZ{WLa|h-v?4rAK_F(s2nQGx^HJkY0Zs>=b zo%WRZ{AKq?owfTb`CEFw9b8{tmF?BVdb}6^JLq!xTwTht1wBgOATw zB8lW9prL$8qvNJvdDw?8A{~&Y+D<1y!`>B&s#W)eH6-b}#aUziXl>tk!BW+eG_>1B zNg}305bA>h>4;mYGF`>q1B(%!(@iMS?``SWV{jiNz^Ij= z09!GXylcnrN-;#>A;{!D1p($-RkIPb2GLiQGk1PNT|<+UHk3^VrVkbX*5DDko5M*A zbCSA&KI_{G$e|i+;(;AP0^|XT=`z#8(!h9E3#9D)1hv&%Wni9_hn<;2;Y?O)VT)PR z-^s+>;OakN{%=)xoK8_XV{U?7@E5Ad%My?$Vg$53^WJcZkPVJC!!|##7Xx=oWZetGzJ{rRn$PPzWi_#$m(pYx`*CA8LJkfh~Q+gCLhndBOKX?S0tRU6* zY~ehHNGJjzJ=XP*_XJ!DfsM6G!~R%{SSnGN{S)<8-hejwlM)g?d(Ix4LM_khKk$tr z^eo4GfBqu`BC^<b|3n^%|Lp4n7F?RD?#Q%@W@=E`* znl3)AXf|0}z(uDVpu>3@oPSc$;k=N3dIsUL=w(Lx;a=&*~NX=R9E4ahmlr5<=^fUKqb#R(r zA_rPF+md{WS_PQL_P!jI>d0H&_aO25IUcS}esBHeYw5HXa_(xi&&aYGvC{cA&FFSt z%aqg?8J=P%>>Afzg$1UWwm-{od>r2U#>bIJ;1?g-Fp_zYjO0>6~JAJgw=Pxrs(YTVWp>1zMo_zOkNSgM!V z?!G+;MeCD#OmYkCnLYz_bqWTG-7tqpabZShC>U&9QcYicdI}mWK$=-NBL;IR4|xqX zU`ar0FhY;QKn^n$s}~siYvq{YV=NOU=@A%BALuVvoKCXNWAee`w=*c=DVO>+TYwEh zMglz49@K(g#+L!fXu=B!F?ZapR)dm%T}bYu5+2=?AI3r?Wk?J9ZvCvFzCdXFjhwb3 zQk}J8YUH*tV#lYkxS!yF9^~PHIHosYA!(S0QF09KynYVydgByBXn{3h#Wwgh%)`uM zNH<}aco6HHJI(W`ox(%mgz6_1;I{osb4DzanmuJ=Fr|gX!>Z!nK*R^CVqu&!z`)QY z264xOb`2YUZqOxQ%Nb(*WiEyQs0Bw>6T4TofOR77 zv##SWeBU2fnR>l67Fu``wnNZs1fare5mW|lj^GXc-PaHMrXmu89rKf1z zYvpNDM`skD?S+g=5gBENk>&FdwD!)PMm&c2A3^hP0MU1@I=Wn|W1Cdcfa7mfSWe#P zNz7|Ginan%)X=uHd!TKZ`Rr)2Nx#k1zSIp3SN{4BH5(Z~Fy zg`i;?*LVI1{qLr8QORamuMJZC9rWB}F9^6T?th{)B@&3Mr0Dn@d=NkOmonJ)^EH2S zLs-`d=5OE$S9#pKDw}jOJ$B_YSp7hOT-$aWKP;}ByiWd*#%ZHzM&|bq%-GN1-__@T zDYI4=7W1?`j?|5He%daglpRs97AcA~y!b`b{@w^i(Ym@YY>s?cih3nyh04e3vu%mu z`su>eEoYub4Y6ga$cji}=~sBKoMvaq)@txdu*4=mVuTf!?xi{;5-M*twwvay`yYVK zfxy?2)GJL$S_nJ{6=PaA&4KZxFpCW{mhP3tgRJ;=LA6tLbUm8;;$R^w5bJ*rFg0p? z>EsD}vT#*|E@v%bp>1pCB3aJhk^)`UTcqP#!*v?ib!{tl~6br$@i0=0h`I)Sb8yE%-1PwXCm8zqv`w#tmad;zLzp;+kApk%a$n5@)fmdVDb#eyHdx}F z4`;J}yo+Sb!mmKo3O)jAp&R%RVYb%UE?zlWNeldd+~t!Kwz#e~gO>&b)K?}lG+Re2 zuV6UL9w@AbXqFh*r!^>r7FW&V=SP395huI;XUxD+msPf35Y@Mcf589DLjV4J=LnnJ zHs_Vl37%vwxlCp4t~h}^Ory{X7y9ms zPUpU_tzM#3&X%6f<;s2{!-pC;^E4Xf3V6f+4TpW1T~&P)0P}y@>xwC-pxU!N8FHIC zo~0&9T)%A8iL)x0&Y6VP3Ei8&4Byxo8y6|JTZR9gl`yODqsG>JPBxDHgLo00H4{6( zfK401_eDa8wJ|zOlJE=)@H*coET*;{P*|C~er)K3c=lEQ!LVbj5#M6VOp#)OlyMen z198z9Y6*L*hMxW)j%6Bv6-<}+BKWuFvQH_DW2F?&XOznG zWeph4nFel|#)5H(o#hqSbq#$GPJnET%?-Z~eJF@{3Qes;M>o)d&WAe;f{SsG0EncK zvckAsQ|+Ac(T_1BQ$Rm>rrflA1rwLAfz~} za>4ry(n5(p*|G_{RtikR$W2+N?fg6SkW|fK=|_ZsF`ynUE{vg{jiI0k!SH;BIWQ+% z_YLYiXeaRRuJST$y<5FOU}3Sw7`H+Z1DU_MZVvQAB-2Q%p9yVz;C)4&>Z z0#z*#w4@|Gm;)exZO3?k()669!oT!TsEZD~B#L@K*JqFpY&LxyYM$IKX~Av*B<#tq z-`63e2kO9d6P^N6@FU10(morOhbt2SNqBjabGlF;Yy+_=C=i*N#KG~`th_@YBXS$a za}7?VQbvj4&K|f&jAB~?($=jV# zT?z*@xd?K(adN*J1HQPV%iQtF(zoLAH)>4>Lj|>i*QQ!0YbaKObn2Rd21huGu7}I;1FP zp40!ClGs04j${Tkp#%JjCKv8JvpLgtIbH`7=|AX6xcodl?A2-obGhNUG831AUePK^SlCwpp@D1?kR*O`&PJ(vr@c5}9HEd58~C|1?G z>|oa85|HSVtMq1eDG5w~nxNqms1(#y)~OSpl_;17k_?!Op;GS0pca$hCr*_F5qqHB zi1)ZDz(@y8YTM0hTCp@=i-?wgE61;Vev)VG5nu#*MF+$Q$ABgGt|>Gt3d1%Fq#EuM zRZ3|=IT-?z+=t(`(g&0)&q3t~@$~Tl1|9Xy04}gX28xrb$YH@K&uT}3#g=rHqR0ON zc+AT@M*jzlt!PC3MmB9@>pj-;g&*>ID@TL^K9=wadUVE^Cy;P@4-9I=!RRw zcHi?G#HFM^j<6g!K<8$(SqzG#PYyC8 zlwzRCSnt$MPWU{`g{+zpw&*2fd^$ytY&DIE#Sjs!#I_CNh4_vuQjl8d6%YvxW2r)- z(}a5PEfYiY?bi-bB5(nWNh&xw>lI=)f=MpBf+QV&?yf4J8_uZf;-Qt0F?*mw`Ysz; zkUVT*0NN$tXDsqqE+FW;Y6m&|7m4&=rI_!N+)v(B?uLrJL3TzrBz2~S)_rI|Kkako z8uWGzV12#<41_a`{?~927G%FChE6oK|JC(Ai5(v!H92X}>Lc)8w*AW`1@WBNr=BWZ zpN4K}k+dHyvGDUZdoV@=H0GScd1kr z;jmegjXN-HFEIB5(rM2-Vtb1-id>QI7(3siFlMEDZgjT5ky!33IebttSLSxy@zS`k z*9XydW@PVY{IccG91R%(pRP5=t(t1 zVh*(bu4w)FX!8h5pgo0c$6_mbI4kDR)2}8X)3w^=gd2=m1VYB7pjjNc zoAen1?G&}Z$~00KSzcUesL0Y8E^q`wGC*4> z+Ix+cS76J4;|u6g+jbkqvCNRCH*N4iY;EHdQ#awCMlxMjsgvizW(>w((E`DlvAZWb zU8DGs-RQbh>sql^Wm1KBWYz7ur)`B_> zGatu6NEJqp|J)3}YF4I4s#8jGMWf(yMs;!va2$?fMZ)r<{h%)Nf`)@NXqO(DhHz*~ zA^}T=&qKEv`V_tcNF|g*_%gy)NiQq_ zb3XY(=f-2MLqsMZKFPv|Xh7fGxOe3Z?xhvNEHkn+&G$FwF$1tWkywGBkGL{tm0nr^ zX^8rdD4SF$r>ngo{LhS#Eb)tr4fL1$FBZ+ej2dkowh?hVT8K@1j$`4|Gu*wV0v|Vw z1gbAzvF1Mia%AZrbhQ@z}*ktJ?xuY)ugDu|@%?3X$e$4r7>)0)> zk5!Di7W;ZvZ}juo9+oC4)f0iLWn3>)hg#c~Ww23!tF~v#jdQ#93naXWeyxBbIvFyS zva{>CQa%<-;IKN{Q4#CcbnuxiS9uY6F19&z1F`apDb(L={WHqc+CfM#{>PlQ{ zN_mA=y1IF6^~0nK*I<4a2|H>Cq#W9!{k-#`SFHO``#ZL+`s{_3`w8c!(ark)f{Cf=?K{O?dW|$yFEQ+~0Ky7>3N5VT zp@x+8tUjaAEdj$jCwAikdl6@$)-)+B=?c^EaTZ0@{^4X#Vm`4|si~l*o zv?A9T{^Q_u35v4Za66J8Rx0TCiFSU8)&yS`oyIREB^DECN1YO>7}FI9E7g|_QN;9>&5r3LI2hvd@2s7X3%B82C(-1YajGD?I-YS zQcL{kMQb?i^bW?lVH!w9gQhRCzfzb6%iF}V#7 zWM}<5?F=PZg`iv0PVbmOZ0uX?$K+>`JQerH46N;tQ zm^IE&l0a|hFa-_gh5p*aubjF!;6$QGx9#~z#RfvJ;3&HEzWq2NdGZFh=#T_lbytKm zVJQl!8G;xRBmH+7NWX@agq`^A58x!BS@I0b;azw-g|(8N@qZOPh+II))62%Atb#k@ zc!U2)6WFJ3`A z;-%N9E|g%LDjsDWSX1?qxFTb`TmG8ADc{$>QVO4_tnPH15n(;NFaN7-O3A%TAKBgs zMp2#)m9f1e*Fh`ia7#(O8IfEw+x&%*VOv(AN7V~dI&gu`n&=ZM>r!z)#YL7M@(Xux zuL<_>ZO>b#$QBczdJZ5^@dmKBxk{gFWiPPy0DSu$pY^(A2F*Yw{n7@CQ#_`F>@~8} z`Pxk=N`lZ9`Xh57cp7Q-jv0imhmhjt>L$g1)N!Zp1X}NO&FKEAiK+Tw=g2R*B zoO`PQ4j@k=C+sRxx{bS|8;(;e=yfbftn-a6g3GqxWG*9@*|mr6bN$Tq|E1#By10K?oK@bZP1=?1}RJiqjK)Hd^(7z#muP&EqO-=<`z0JaiI7FQ6^>;e*hF zq%)AccB6FMCvglNnHIJHTS)aRfdUTF+%y^ZG3==59uq?rkAjN;@A>USAQ@{sjjc=> zLn-_b7X2WAK8sPL5b1@na9kiJg<0cN8>3D$+2B~TE=zed^shKZH9Dg}NFBp@{r zgD{U-yb1CFSr@8L0v$;dK?;sFUSvC6(tB-7fH!?<-6zr%*m${j0|<=x1mWAQg70zw zcT4b((#bt!U@@v;>HJG-?h0xXA7;Riel>Ywx?~i#o#L?+g5B6e0EjVzlvb1Jl<2T( zpdFS^#MqzM=6UuG#HN{S0#_T6u0F}+8&vcY7L>qh&styimN8)Jp8|%cIPJ}8#uAZ1 zkLc2%TK(S)C;-Jy_tN;kj(r@&mr`bbA6I#4JjTBmCJ_W#at<9VyLybs~w@Y0&P7mY84WLZ;X^=?EQ6pwpQ zn&!+AM|2?zo?0HMh_Cr9^#YV42QK!Hahc-;mF_qi;@m^73Xm4-WhC%&b!5TUZq@e- zhJWf-S6d*zC@up0lfwke|eK?9(zc?9||){OW)H-nOj`D7$dQQ9$%ZM$|dFS53_muObiK zi^Idrtu;?G3^+XTX#2w3{ZdNUr~sP=J&u>l<_l<~zqrZ2TGj24w&8a3Z%Ov0o(l_c zkP>ELGB?z=xM=70#=DyMKC_nmt%C?@;KQDxEAwA{)JNr3$5f2ddfuy&wxh+G^?zB@ z(K(oL<5@lJ_aAB-OS!033c}9V)!TDqFHajj_UFNnU)ICt*=SFwy_3zk*2wd$esMP)SFXI?snb`30fN5_MNgN$hj<7QokltVL7%$J zM%Olx;CG6QfJW9va^!auBUwYkn~)<6fJr`3Ui@k_rwIQv59kbwC%Mo*n}KRIg>=4Q zs^BVGmXU~|S%EoT*7VRb2CSNk)9VxzSkj(>6Rr!aEIBmZz5j^a4=JMz&yohHwkH$j zWsgngd{x2@JBjJ)b;7z};QGYS#nFe{r@F(}5yj=J4XjV$=bbLn_rn94r-3!!e!Bts zk9B7_JLY{lvh@}Zp--E^R&IG@KDY@IgU?@(X4b*F;+_X}*3z`dfOzdo_%!?lITbKd z#Muen(S(RTIOG^v?bmfVvul&n#Xu-A<^24auGIjW`L?TA*_`dzHlR_&{NdTaB7>(Vgp?q}y); zebk51N}7{jhwpQu{09xuBL}5LlJ+w5a11v?Hs#SLrwm;dDLD3@a%0Z)Y=(9eB! zoM?-PUN%v^If&^jK`1ah(N5Q{+w1!X%n>!WZ;pkOG^7h@?Eb8im@NO1bm{fehHIj| zw_f|&dixR@sp4bqn?B_@=BD%-@I3;G=YGc@2=)=qTs_39vU|6c7adJHeDtK|mxt>g zBcHoE*yUxfUmWA9hz9~a)FENjad#^R|5uK*@LtcsTuwF9uKKSNa|J;izQs36SbujK zxogxEr-*l63?rxoQQs~L0jwEPjA4bX`Hr`*D{8AmlQRa3q#_QejjdNU_|&voer>AN z_5Q`&my)M-pyzn^n}aFpqic2R#-XdNymX^V4EtH?TT%5&=Pw(W^>-CMIA3%;qYc$v z8hJ#!TbseI91}_gwl>aMZE;j1PBarVwW(;O5++GV8s$cWwk6Z`TcJMKd?in^$~DwMfy&NEXo85;a9^I>!BMSohMD5^fnsFIMze;xFA-mD*!-}ZAh z6nt}7r1a~ywa??Ek(*wpCVpJFaM8U7`W?9w`p?y8wd*|`kod$nWG4;#CL@%Hx+4!C z<+)7*XLaq+HW`vfwV)N54&7-JI4N^_m-Lv~aq($7f zcf1)^VH)hp!|jv0E0^!&02_$<$rHjqrt=?a9S|6wrT?Al#}xcwzt~5*?>M|j)OpP= z1xbTL-$Cqq#Ahr! z8?!?D|4sY<2DXrL%WwN&`?0Xi9-p1@;A+Hh`M1c&ZyJu@AERZ(|94z>iQlqs-^{-M z=@+g+wilLIR_z3X9qS<(7YXx&6b;0C!v3;8h!W9V2 z&2N0SFnQ>S>E%Xsw@Q-r-u*?vc#8{zTuB)hw*yXJx%?si_|azvtCsJ7`-;4O-)iN& zNYEOQXdtH_^fxJU!TQEFi7iU*yLVloWToKZz0r& z!}OdwkOz_K==5j|m{q2yai8BC4qelxKcgqn+8W#cAGY2-oax8^|9^FmBBbPyoD=1+ zP~^0cq!N-u#Bx59b52{5oMH|kIjkI$n6nTolH@RjW)^ZjZP+lIZO`X#ulMKs{r-NR z&-eGA%jMc!*S5zVhui&r4+psg7N&A&m}Lx0&gmrQK4HkAAk~0O9JB=#QGnk|qDbxF zm(cv6`ZE}ZxQS4Txh=_$Cj0knv;T`6`u~ieoGm46f9wzJbx^Pb6h{%N?X@^rhD;Cd z3qHS<^R)t|)bUMTBi}eug@BI8oqC#b++8?4z%)mh;xiqwBw^p^`BQy&K7iwi+8`*Z z=KL%xtWY<+8NuGGD-(#4KA93W6|qF%WIxkzMdqrI|C|Z_!Vksz2CCYRjvTCl_c}YK z^fmlBZBvgCHn!1GI%R#dEX&y1Dl%C#ZugwBPu@+537=Gi(Ar1?8e4S1yVPN;T|9b4 z`+Z%Aai!wvc)=7Y}lE;gRb%B$aWmuY$Pw{3=%rG78wvuila=pcIHC$a>H|UInu}y=XoP*4< zLtNX(D3;G{UtMx(6Zx?7>Bt?|r2x{y19*GfM#G&rheuypX|oNGajh^yk2%}xvulMz zc#E!o`+-|iW$D$3k56OPh|^6ckU<4zB?s0&N}*lR%CCAvx0{_f9s~ixVM)LeI>uiV zwq;K>H50-ZANt8wf4A{EjJ#uGpCH+xZWCW2EBw0Ekwayz;7*?+ytuGz@g=|Jq8eAI z>~qDxQG^FnFO~P9Y>EcYrmk;8wnGRZz)B2*-F~VMEW2n%juL6W_PO7c_98^@5fyUO zG#Fdm{_|S%c{F1e2>d7!@%;;pw%n4j!G5UuxKO54k4Fh{Xb*VV&unel%^S|$h_a8iZifwC;H8k4_by6 zcqFLzN(EP#$RQ*tyZ)8S;0;#xPi&e`V`&9xCF)}G<&4SWjMbLAy_ufJYr3Wx3bw1D zo9<=;Qx1}T69=WFJA};iD4Vp8a^$+NCm&6k-CG_dtV%C8PrBPjt^Tao>^+9mC4bca zxlksd@F{?mHS`NNp0X<`#_!L z*VbP2cg07popy^>047F$0Svvt>Ib@Njc%0N-b6$S;jyvp4s!DN(Gbw zQk2~2g%0<1>*Pdwe~?>_fi-^$!-8q@o1+PY1>a-Ewrt`%i&smnOEchVS{nZsF0Cd$W#Rgc2=8wQO1)lF`%ER* z1Tff@^(vk0u>bh$6TeO8ee91jS#X z1jA8dOZ6`Exc}+?9CQ$nJUm}I8Fc%PcUASh&qBOZ>zq!Zc@q9Y$15}rL6VcW4Di$y;D@|+5c2}|1U!Wp@XGbhLH+q zo;?%Ve<;D=%$|xuXSSf<*GWpdf3{$5VL0Sa#{ur#cn)DaGa4?pAd2{C%Ex=cn%2mce>* zP6;89k2%tHa+1mVmbqZ|>x?V0IZ;hEMLIX%c{gNbh2F7ZuNJ{moypH!P!0AQAH}Xz zxZ)pxBKD8#Vw-VarZ?B%Q^5hcw2vjen#OJ_OnTvlgqdNBYd@y>IhjQ$BvVr$1NHeHcfaSd$S{VORMg)5jj#cMPK%#n&2gX!_QE%Q`l1$T zcL~0XZ*fl=%n#_)7=eAqjQ)iCJn3mx6&akj zGiW&ea;^YY;Gw&*eItrIXk%IJM2setAROT|LU4E#f|N4lcbRfBr{_icAi zC&9tzM;(7aTep^|b!obLitX%0`}j`O?%xBu#ENkC3-)@r$HWAQS)Nu*Zl3<_-%fGg zE^YY179cI}-S=UK`n4JwZ6^AQ4;4k0T*Ds5j`%sG>m6RD(^Br!ZBwy>>;} zC4yuL`>G(VHypA3PK{O_5ZyiWY1tXuxsa1jm=5TO&scUgY9KdHshUsokMFM0e!n0< zcU#KMTG;&1VgC*-R@yEFKM*#* z*69wM>|3XWgLB2Ks}!85ou<{@TIl;XHTJt$Ww0H%52P>@RyR1n)Rt4*6`*eiMa|3H z4xqqlk1)6y>&QIdhj=T<&15DV8-{%XFLET(67Wob5sVz*ax?7s@ik=SPjSEOaqkG(=4 z-n6mT*}Gy;XtFW?>T;knhA3?BTj#hmVez5<$9dW}@qqEonQkJa41HohXRkG?rW3k) z*DANNjl7-U#gu9QGm_-r{^#-j!V(SYuJ1z3;`aMnPr`(}*OdG3z0HbGu7t45-Dsmb zZ;Dl8&VTx?>UPZhyfCCTF(o2&)>Yx$Xr8QkS?Q2K(K(Ihi4q)- z>a;Uv^zlpY^U6l#y}_Ggvlfq3xHN5r2n@PAhixlG*V zfaPH>CO2DLnK$CkE^4WO)#Zzt?EJ@RPZp->83vV0X2ZPZVOQhFIHDPQwqg^Cvt79X&SJ?68G)laIeChDjjrVsg;m6ZO$k;9O z*iXM6Y5@xt%0DBOuqanRz_4oJAMqwaSQiT6oXcj|P< zjVa{f>6qm&otUEQd<+{t`)@{cBlryRA+MMa>LK!ZHzuK4Z=jR40IB8PeB3@yH650! z?_yijNwVN|C&|+#{^iO*(?B`P>f2F3pfaAI^PMlZD5^-Me)%|U_yG9i9gZaxJr8EV z(Z?(Hi(P>!N|@KTe9!RTSmw*E2sIPI_v*!g+4pDUBvVxrjZiR^t;$!HfFX1|Y`BS# zgzf{C=v6uE)xV|BIUqKXI9M_=B#|;5%ko4j6!K7V*Kq7#aCIT%s=CiAnt&d6#eccN zGKEs47NUR=mtXg#oDMTEaiaYTBZ7;s)esy%UTh-v0*xNf2Qy<;EpITm*-@Y2g??3vQW``tOc+;8BQ+OV z7C8&=ME!;7a)2{3B41bOEWbpmGtwK=bWhv{s@kKkyKV05qMx$!sY~w2P>#<4FUNrW z-<+j~pduWaGPS|Y7+2)z{FH1b(&&iku(pNXtK&_dGZ6oyq&!9)TV~@)QD>IpE`C5b zVeWOqDU*|vVbh$pC~yygWd-$L%8-b3|MBviX5_Z#iAt>~nlIL)Pd>Mi+%i3NM6mF7 zuY)Yv?yo6~l_2;E8q<~)_WF6^T4xS|EnuORWbt1u(bD1Voqf->V`^oD*{2#)D^0H& zGt{~6j=g9~u*}}?om8xR$tfA9+;@%gpx{>O6>pG>xzuKs&nPET#$tTQmwq>Y=~p3} zicZBW!ANftHYygYY9x|NgzT9+8x^sv$MZwTJ0kJ(hLT{g0QKBq*bY6ec|Ad^$?bXd zS1ZHLwwwGqo-m?!Lp8bDD}YcPK4so5@{((Q0Aq3a3lO%&r@U5OwsPCx#QbfXbc}KI zLb!za4M1v0yI1%6-vbYFB@=bobI9vhBer%-1jl*So})ugm1j4-c$*_#D!D<`J?HBa zprxYq(I9l+BRIl7F?g!4mJn&V$aje90J6AaS!Ke|-3D6_23%{>sDq8m42XYyF!4bWIfi z<&%hBee-`jBlI&K${x75WYif`n!N{Eo?$2##e=~CAi{n_??F$Y6{GN_Q_td{WQA>J`t8b$cQje;4LV48BK1uR*^V|bCAy| zwMTq^NQ_MIW9O}@c65E)Z1)I_HD{i{4=1`j_c@MX-wTRwp5593B zKaB<+-3!*~hVNl7`#+6gAfYb2H2CMU9h%v#!=XLnRn_fn63hnl0tc+46EFxLZliH1 zK+jTz_ZNLDc`-C0Rh{+9%d?p9777Vh@D2SYhHW&?5hK~0#p)3J-HzOm45U?Lnam?Y zNvFsdpB_5?R}Go7GcVj>HXM-Y6CIvCcJB*l{Eq~+I>22+CQXvzA&GQ5+@4Rs2TTq& zZ>}XE*!f|5+8!UtLP$6;F~tbhnxuwb4~XYqJ}f?BtAjP|=i+ zTlBRb6vz#v^EHWRyC3*1)a-Ml8GFnj3Hse8!EOLt2QPFNI-7H#+_-4qP;O z&rq1%pvL-w z_KJ<&IC8D{Z)H3<40&1Om*oc?qCSuF8~)Wlv1lLQW{SD+6&=OyQKRA40nmLJl2>ZY2~d)^1*g$8EVH948WzTg2` zga5a&GdA~~npn*?j;FXSWmrucFBka%p=o%e*9$+-{C|#|F~o9tO1@s$!!o|PGPmG0 z!G%qKig;$_NsE8@IbYGA>SNqnCZk!oy&aw+4uO>rDKRchX<;4N%A0SaNXtv)GRt>y z(W{$j4xen|oUg45>_I-=mfjy4^Ch19=_j69*^^ffJ~}RYh4t*Z%*mm6@bwy|gvh?U z(BknB<#BXV6=^qErjP8uO zIFup6z6zSGSi%s@D)7&0Z{`yZZ3 z6MZ|)5w7P-o#Ah~{=wdVG!s8ZZXW;K6N9-)ep9|)=$~V4{UmXjvaa0I+zTsBB;lH# zLvVNq9!^z~1og5QpnHDIpB!<$?}t>{OZ{5M!kWJ(_qPx9LDHJmYOqCW%V+yZ$SqFB zT#IAAYoV#K3!1pG*37Pea!&Qz$ttY_cbdo3k0B%J*K)2^&%#0vD>67J;$$XpW0uwRtkag`SKWNyGqz#$LlVaYky{kTxg zK#BH|rgec>N#f1M@XRJUw*KlO*p}ckQ8m1UnzzyEsWyDY#ma6gX4M=8b?A7)3CO$@ z31wM|ja-%mj2X_E`W&6s)71$Jjadj7&Wv-kNthprI6~nVo7Jg+A?!YwtWiW*8a*zX z8Xz(G^;u-D>V`OwvH#pUrVRW2$_geP9tZG!BcGQ+pPp;`C|3-_$79#v=~A>HpxB_%(#p2hWRMk!Kt{qb_e9J3I=qWnd2#SpCX16Q3<+nU}m7 zZ_!J}^F1Dmq43ihG5^(_{Ga)XQ#Hg79{0j?dryR`N@gioq(PSYchy|J&6gH#lw3er z+SvPDvPUo$w%W_h@_+jXbg-NwGydNx?Q^t|wD8gdx32f~8d^o7Bs ztZ}&jsc%JGlIH`eO8<-rilYkoMRP6A*-i#drn~klcZ8fi4?<^ua{GODHYL_8 z3G4({Rf96R3-cqSbh&X_Jn7Jy--aZkwq|%Z&c3>UR{Ntum#61V`iy_7_-SY0l5fs$F zU-{C(X@?;T@^&6>d_YWtbg}J33Lvs00`NN9NQ^iZE*Dy6VmdybS57?#8w<)f$-;0y zH3K$)CHes&i428;kWbZ(tP4?FWGzw#w`2&2bo+Lfxg%CFUISo!PvU+CmTr#B_8fPf?GA#j`)kqq7QLkVb*w%RIfGtpr+Pq{+^h zO@J_d3c(~t@Hf#We287~7CYX3T?vwro<+Da@#Fh94#hgh+C^!UFQ`rPC9mXh);xbf z-u)Y;PZS)O%CnXurK2|t?HmM;sR~_a8g3=zbY54biQb9%~O5s zV7e0JcHk#diDMzhD=msYn3vq@gamwxzPmhjJhDzBm8TlE9_qD7Ft#bWIWu|e!B`q0 z@rp(Ari-n5AenD@dDT~#!F|;68z=HuU6&MgGjC16$kHM9EdvMQ%b^#vk%Cn!qqX0cSCF{EV-^&7Fs$!@F)Ve2slEJ zkqx!Crh_CKg&0)~d2+@WeC&x-+7%z`$dD;c{qmr*vr1G_VA|#AZPNjpXBmT}`jRxA z%&yCGlmbQm(6j2iWAs*wkt+vS6$Wb<=z1@z?Srtq~n@e*F2ewx-YJ3RJivHNp?mn$Id!2QSRuT2C zq+i(aL+ghs|Gg#7flDw!>W2~!`&ML%N=q}mfM$vWg5i6aY!<%4PVD%%zN)9-5%90i zcyf(AIZA<{Q_(T^EjLrG}NlmVI!V}1r9>71yce|T=f8tPW?$nh7 z!i{+Ww;H$(ss4~mVi!c8i*q96okYL(iZCX?o=k2F8x zO12@7yJo)mUpe0wp;@V~lVGEOG-Y~UM7O-y0euayTdGKkQC!_FBN0zlHiv z)MP1`NB0fsQAD2Wer(aH{8n)O)?K~S&4i#Jc0k9Lq)xZ{3~>s#u-AR2*tDF}yFA#X z_fyfd0V^PodJL{?_;jTW0y!cni5%ArIjhOWS}<*1Gfe0vjHBN_Q(X#q=}Ll+0WKsC z+Xa8it5(j@eb|_|X#n{gONK#rfGuhh_0K&e*%c$8iXN0vScBbg=>01LG$o#W^9Y_m zMTJ-aCY?GdE`T2nwmLwgbA#pJh}<8-$gP=9Kh}t2dAS;nO`Z1{e_kTBKxe4-?%nr<6tVgrSqdf(L8)_>ZVV2E3Vo;?!YfKu)qXIqixU8Zv(0ssfAEf%+xxqtnFB-36k&U!bI7qGM!yCr zOE>1Yn0ty!+sEqWFFJuYJ35h`g$m>xdvKAu(aMzi9WjfmGZI`o3vSiq6LaiI?$>{a3OazR?)l%Q`&MIP5^($W%l2uRajl? zPu(AixZRe}9=h~nI-(6O zxJj(96&yJjbG=luJ%~WhJ^QWyL$_9UXYhDfoc{#w3XK`H*{Fp5zvh`F=1&K*F59Bb!2NiCI=< zu|%*B7ZBrbP)2jc;D(@KmV_~TftxaX=NaGTlA6x?#JtvMgz$XI;jv$_ou54Yk!N`W z?|h>OaTYiIcxvr3*=V*Z6Ufkx->y=&9_b%C=GT%$wt_#gLy^11hKkg2B? z7)=A`5<+=lk*>Qj^5Tz*lG#W~mzN3mlGEOrRbg!@mgBTOy z!&?Dmc}U~MZ*)8Y@dL)kf>Xx=CkzwNC*1Y=Yo5i-p}=fC@S(EcZU|31@M4i_YS=k{ z9ic_tVs!@_LR$|pY^N8LfcMK%RHW^?H3h;#U00_;7V3RlSugdU()8JhE z?8g4!DAg%+rvm33{og7LAaU?DvJ%iOVZoxBk>H}ja}hhww-0nfC0C~3SJnK;yo@J& zxX=2ck>GNl=dMppYdNSUJ!>`@G61@c&Kx#F*L<^lj(*h->;n~d2>>Y142D4aK1X3{te8H zkCQ{}Ij&~v#F{NApVPQcIh3(CZ$sjPKH2^bTQC01OO{q!w%s)syo~mq1Q>KVsL4sD z$0z-u_> zDeT}8Q}{QRUJKIIl9{Kp`4JRh5Xsd2m^ko;_c^sKCx81#R9LVU{%U&C(Mu$Zx$F#N zSpvCzLhP+-O?{jDL%l|Bn;ICk7YduW_YmD7FD&)l=n`ion|S%8eZXL-@4zdOpUvL7 z{;h6^somu(U8`%)7F0u>NW61gT67oI0ATOm)G86d3SrTnLKvWn04y^rO#DMjk^bPX!iju75gdnvhdKRHYCc<9n3nxq zC1B3+v17*9m(u37$keb~czB|^Q(rFFH|LhHArV>-}&gL$HuCH0V&9j&9^!wdFU-mSa*Prn(^nQ0I+iuxiERk)W0n{#4iIClZ~XZOaKa< z`??CBau@HhNr1fPBXDWsmN4T;c|9@;5Q%+9-?+!hQn>h<13TIPv9iG+FLftG16YiQ zS-xhXX@7WWxhe-J?^#wq=A(eVS*%0nECi2Lq7 zlSz@9ap;k{Z>N05)4L9BQaaCBm5+A|z%1h#0I<-_zFeiL4gqYpQ-Hqhyxc{ni0!R1PU9UK@7XD-w zXDmN~Tk|;iu)T3fcv@FR+jE$5r;c`U?V(uHp@`=EwvUPX$ys-cMcGLXVf7ZsRbI_@ z%}IX!`D1HOkL8=$XCF4$L;Lp0zm__43S2$t`qKBgaFt8+@79LF7Q*w6NyJ=fY|fvx zE7v^AoY#EmGU)ZMBKNOkI9JW%TR|Ckhlauq(g`nr%eu?K( zgY_qo%BzIdxR{K0K1P`ass_hYETIaM>82(ltoISisvkMb+?%CO>tw?~a zl@^|@9e7hl8tk+BkYBUjjSW6%9FTK=4yxio=zj3l_=CAZ0xe!C*lhBm?mE?r$?|}? zHMFgT(X|BX?-x`(Ioa`K%D8zmGu@h?=A*#^yO6)dZnmYNLZDB^4FS-&YHvibyjBPNu($r5xk;c z1MlUu4=(7bP#b$6&i!XE-~X)v+=Fl<=NHF9s`NZ-l`riU7q&QytMF4|(G2{lVLG7y zS0MFC_KI@1>ZIPro|QDlfJcAuPLlol$HHpt)U`kM&03BwURTN5Ttz1A;3j1P&$%C@jXyU5M<{}DU&7)B9%EFTy&{yw)^$a0Z@XVf26v}|Fx9QU z_n=b%_i5K@{ne-!3BaG*#!LRo+{|f^Bwh75ii|xPMStY0t<$jNum4Rl^*_ zliqBccIW6og!)x~WgP6pPe01y`x<8b-78eUOF&~r3Ux?)*_dry^VNuHbsi{qT)cLZ z8q5}ZbLCe5^VMg{Blj0d9XO!N^8)1?VLmMpyB+c15M!rMJ?m%AM&0SdHOcXjUJLNWCR@9!w*YE{-9tkAoy5$I*2!_ z?kp5O4NFS0pe4cjH5VyMoVYJJSU24DWj~%Z-fm_(`;8^X=z@Kdx|8jlPvbVyQ(v|) zDa+CKn}s~RN6Q8FF2_?*)PT?MIysg;&?8DU(#By8K}j4~qk^a?Q+URGq9XV?Dte3 z^l`AnMTc952e|f;omx2Mkl;Wv85tXM>xW=J#ZXe1TTD|h}=Tj|L7 zCp^Ivxboi{UuM_B;$74%dfb}Zi~pKZto%+0UDH)8djIHM*+wHPU&Qy^#2p3qfi{)8 zuXi*_Mr#B+sj1Ph@i33JerXwb)wKCAUXC&!=)MZdO!dt(TV52(0f8;3c-=B7lAoLUR;758NcGU@#7u2jNEb$Q2} zcXQMqpHvx1px4OP<>Wl-6y@pFiOhcf=EATkG3uKnu!u>PGiL84&d3$&b^W7?{OruT z7ZG#cxvs|nxtHoY5DXa~y^%#uwK+@3$J}c4I#IzvXU>j~_Cc7tEE&gJGo1=W5`t}? zhp#cWTiHHe0E*)Z##%IG57IQ?Oq)rCUeOXeb8gS3(OiP+hTQlV$WdO>fwhjhY64T3GW8u>XT#V){#Ul~+NG{Fhe#9jOQV6Vu{H!rin-QcpdZS|f{4Q)# z2&D|j0#bX!-!xq*GI@aK{ysSlUE(3af>WgCtGKG3ve#A%zD|!do$WHGZ9H%_Bzh-U zj4$f0`!c0!!_(0WWG!;6dBSz;vbeam^GhO_=kZflxA~#AU7yyh1!a1U0AMDiGheMN5z0Aeg`J9NqVDmAuVq`|{tS6*a+yA}8fFG8v_b-%{bPu&0g8m#3| z9;>QWHeQL~c>rVH8sv_QxosF+a~!nI5D;;tXWjq7`FqwDOMDZL@cn^}0J>4Kz-tRt zw7;P`*B~~Jr3|)$lrQm$aE1l7X})xC@oLga(GyssTMm-*>UL!TmqI76vD}bJT)Ye1 z(Uz6adARmrs!aCzGj5^Y>MG9V=%s;cFR-@|pQXA!yh3U)m70El*~od0gTnqxIBezy zL+d-9`(h9)13s4jbQYzh)+Z30##vQqV4t!}z@A<7ZV77{{8h$Q>}=`X1s{^Nf(le>Ju4=I`ltOUJvmJsoiur(XO-=ffN|bAbj6$gVxPO5 z3f|2X_U9aSdx;;mc+lSSOAl#EccYeU`#!KGrgMF1XQ7K1^7NLI|M#(!xisBxG&<*y z9lCe4eI0|hdQxs52R4$>5aRcO0^${J3E94@I_m$R!ioKJj!jzdLe~SfPXk6!$N_UY zp^nx*?eGwSRgYDD;}kY8fHc6{N#D5!WnYv!WLa^v$NMAKSVSei)%Ho=6WhBJP4iZ7 z*Pr}6-id5q324S?VaZhF=A0Cvi&y1g%bzgb{%nE94s3m{U;UUSBDHs!9$6%NIo_?P z<8MI&`5A}t!$|DNIkhHE;<)cX&9xYk@M)M{H=Y;r=?Uh%iiX6f9_^J2d5grQxkX<2 zH_b0<*FI^z66O$E>F~u7e(Q)ccY&h2&A82AZsM~?ADM4WVqU-;qAS^ZS{01rX?&s7 z+oXHkIYg-o@km7D3Rb5dgAON@AsAw`Xkx%LJ3XFnw1X?J@>Iiol~HMee$Dw~Q7C|_pK7M3BSzBr_u6NH~vMP`Lqb5xQ&)2 zN80JH)2@ecN~-O{Va#867E5LtHlYc8FAwYW)0zmzq3TcCoc5m9nJ0#f@$Ibb1&yI= z4v99*$i22Dee55iZF1fbKjn&ALVv^Yox$5`3^rA_wNU8yujiCw`(+^u$Q^#sipPJ! zG#IV`u_x9Hl*bzA(yO8fCvf@;d!|soo9Sk<_Quj)M+G%xhTM=3rpeRW$i9Ga(-UV2 zjW&*T#`o=zS$^TQbI9LrOGPnhW}L&az2D#%C;I`_V4N#8+Ym9+*X!$UR%jPW3n_T0 z>7(P9z{^RT^YgDL2rFjq;XODJB#?>ZxSXaK0i9uJ8{6EHH)^%7LLU$co={Nfeft;8 zk}hkRp6w0^J$@n?xo<(o4e0fhCv8mDX&4(^c{8Ki3Z#4efVhQj1yw%X6!F<9>o3eQ>ebL!TDvApwL8s}zqb87IY<+ZkF5SPRA9voY9dCeb? zzZn0o=}6<+BR-wip{}okG+P1Z|++It>ebC#@|5a>Vn>tP_#1zcjGc zz8ma0$z{C06ngZ^dJ=|YiZEiJSXL_EccbKhWsLmGF|)nS9065I$Aj8cMc~6On#MsH zC<(uE|L^kmC;sXG!CcIsB9J>_!$!GTy>vTuqV;PVeC4?a~qt}!`jm)xo^q}s%t zYbP`+^R}b2vHYQ}vxWSf>;i&FvTB;mS+hp*n$AB^24hlUH4e*+8Nt%#h*290Jy+pr zFDUDsThOT045sg7s^*rxfNS4Pwvwb4uya1jY5SEyrVQLZcQSBSB5ao&u4ZPPqbrtl zQ!{?uyiM=wkk@pnYVz_b<#vlPN+gf5-^sfCGtubhZex~3y%bya*mL{gBNfOF{&kSi z2ixlE$Zc`x%&~p>vK-J)t&v8niWmelFt;KnYp}CC#CX+55(%dxUV=Wkb<>Eb+i~l? z8bU2A&TVt(-Fl(F2bzHdt(o8Tkh#h-y_DWiJkVE!bUNBkuB=Z*D7Qs0^&bW;>E{8f zuYMwK3%wD$-xE%@I?IlM8!SSC-tLPK5%AQ8H1F1GWv>sCagH&o$Kr&OTUKx2(eZb* z@kg|qoDhC~ZM;eYH#qodVs^AxY_KZ4hn^Qe#33FRNW^rZeB-Tu*YiT?aWSd86xf5H zw}s(9dqM(Ky+#-Y6C5kakzZv*gs-^x`K}b<-k%WE)_MWQ7)&z03yEf9hfb$wNJvdm z=gN^W61sn|se`X5XV)$3deIT%>z^oRiHC}9doy6rFKNEWM1g-KK7t6ls^eh5{If!T zVn`NhLc?N2KN&1!S2g&u$MDUUH2-`z;lwMV@_?PtXs|YbK)O$2ayeZHj_fOn+Rh-g z*0cZi!pLiax$vGaDokZi3?)e`y!()5m7D#lob);Qp&Ye4sLMPT`f24XZTs-zt+hLa z%@h1INu?yxKW1dU-z{v8rb?f$l~-!DnWOVaW-m8dJ($(}nhxwh+sI2Wkn4=9iz4uO z^VuA#NvbI1{dC*RZ{2Yz1|A>y<4EsgRwbP0-t)3+KjA>a9V+3@BFD->-IVuA{jR*t zGs`BmZg*a#?OgL8PO>wPuBacJKVBMy+D^E@v6I=s7;btA=;1g@aE1k=f|t#Ffn1R4 zfw>l4$OO4rd4hE+?55DzC0LCM>lQ-cnltn@7rm7&! zTDT5y^5A(A-w6~Rj@0jrHks~ClgOXes#wt2691L*>@)J8Scfn#;iP$tM`7qaSrTv{ z?7Hj;&W3uIdw<4@e7vvo491qjz^A^;eh<5{)FhOj+|NWTTM`;C4O&gw z4~34O6WYK*FQq>u2YFZ&`6iHCF#2qvC`ZeJdma{pyfgB&DBVBnojV(36di|mh)gPs z?z-{zaZ$g=S<6nI-AqieDwoY*eZIE0Lgo2jbRRWA$K4{oGB1*%`vc1!it@uwb~6KObY>9I(-WO?~Wq5O@1R#j%>M$0uc1bf@*c`ny=Pb*A|&C+aeup-1MsH8?I} z-!p+?PoBN4M_Q8?i)}m&oXSt%#h4D5(W{nKgXAOwa0Npa-zzpDsux?Z16&bmE{CGX zZYF+vzS|;wax9;)UX}1i^68OyhbXgQc(4P=37dMXXU_4jwu#724+;{e-$FoqSX6W2VXD&tKV4>V)^Id*t)(0qHwzgDbBODW z2f`JAvmL*Bt=u)rJH4l;wyMJB;58o5bR$Wyc&35w;w&36YAikrZ?Iu`tuMdjufFQu@)m^o6)3U~!OTgugcc>#V7n zwYYU0YMT-5dIWj@_SO-)ob9~u$oDN26RrV1XN{bN^}|js&QMR57^pI208#v$6w`y+ ze$3W`-yfOypa;9Gs(*Z2fU*SOZm3ic29U-KK_vMNcdH^ehfonbAFw5WoTvL-tET%% zb)+Mo$s~)+n=n&stKRW`v|yG5=YaCqF^<+^Eur|XjVUX|$H8Z5#H! zo#00*Q=7Z%y;EHIW5F)y4(y%MyE~ZrqvEDjKSR$<899jCogYeR5VEtr?ilOVlu+B^ zS$0cd#052xui<{D(fVAzxi%uI%IZSE%l41?Lwu=xGZ!A_$@`J5@ns`%TMbdZmzm>c zQ9h@7LQh6ts!7~`Sm%0t(JjQgC=F?9gL945oIvLvyRR;SUCu*ZlP3vaJw}#GF zO_%OZ`e=ZS_ubj~U3c;jUsHw)x@oD%T|nQj=;}|~yonUV~*xv6xleDPIczd}kRU zWXTK2g*2WhQni1-!2O}}8PH0m={f2Y*NpVEG9CS0@HByJp5zXUHA3*et!3T|L*(u zuZOuFnXdQyobx*8JYPuo^bP_gJL{fFmI5<7sf--P;5z^&P-W6x&Y&tA==ie40?POd zmn$D^G9VSnK!x)VnnWm%S=; zsHFNlBUhL3V`}Z>Cb0JZqhSs2I*#7@x%}wM>z~U#&&U7RIKGA@E&F2-$9-w4mF=@O z;Wq40frESdne-?WA+zq<^Fn2b=W*AM7g9|2TiJ=%+25zBc#l}f)IaW2<}dX&_E+{cuM$l*~+ zW}NF->7I9ngP$cu61M!&r791HZIykN4Z)W*Q6(%n}&tnG?%{@atoqrf4 zv6aot0cRE5mp&Xc+0%M)LHni-EiPX(u!Rg8k06;sn-{M#;;-$oeIZ}89>v^*2~H=z zzLKvVqkOptjbQjw?I#W&^%gk9td*<;kPN$^IUtFsd?&O_ftiT@5gCqWaKTmX6l#ao zdnsQ%!mFeR56#+8c7ez#$a=&##JLQAgOyP7PECz*<&+{r|LR9gX(v07SZNAy z=bSn_h29U{11hbDaK)DDV5G68VCn`IEQaARVUTNdYd%!VRAw%B>l;}dRca+;DB>S} zo8Hv|R%c&O729iX2Ba;Mm*B02l6nv9Uc9lOVWzsauo|O7EA(nB>O{=@M5Y#lpUDM} zjd*(x!|0Gh3UON9E@?Lg;Te`DT^Rmdppf$d^7`I00|<~KKfi#8Tf|iyY$=&{1|+F2 zA|YMZvC#70il-R3yLaKnymA|k4)lU0aw@xj0SdrV*bBbWSD2hBJq?!YcB6*Och=<~ zgU033u{X0QcekH_5a`Evutxx3KfT8F+4e1O`8gobsSBuuc4vVp1QRtqxj}{L;}&vf zooEPJCeTaR#Lpv04``9Mp3=rwcXoFXv>VE>Yo{uhgi;=Y2@o_cT1O%yVjeY%p2c%R zijW_u6J)sq;0UF%*k=n&)kY6`^on5s8fh;Fir)IB(s1)XvGTu#?QRcvY91?I*LvKL zS~O_yUu+V$s8{t`W#TfNWJ+R4rGoap_b2DwTcddVG?4fXPG%^6!0PU>Ca3%xT+mwW zJY_JjATpP<*)hwsv9LV*!7T zXesXd<~*D&S61)+xyL1gd}+qAnq@zBFhuHIcKUbs+SUmh+u1Wa?%82+P}PzADBM-L zyZ5bDOJ}q2?5py2_A8|?=Xo?`*02j(_j4{~s-&M*(z4@ch)Ebe7=sN+Mx!k_D6SpW zWZUrB7qmC-VF8J8BfEN(`@B;4<}2QP7A~_{Tb;zM{RSp$y^6d{Ra1LyO-p*YJ|J4y zf4DG@U)5qP<>b=&9N(pIw=L_Bcl|G>+)j=sDB!1+wbhAiOr1~HNqXvgu4(u~gn&=| zd3He7Pz-9XNN+qI6~5?scI78)&QJ_~8Og9rxB)1ZPEBT`a$ZIvUJ}lKhrKBD8)t}b z$M5lM!LPBrE%dSoezg@H`@yM6amE;E8x2E1;9P(a9OzIl^5k#0V3noS?eU1>hKS;8 zkFKOMM)=atzl?h=q}KD}+Xan7n~LEu%JdXy3?W3qzb@9-K;^?KX!nU=JEHS zq(5)pp!s04OWy1fU=F$hx&zPWMMaw7b^o*+_`d5vl2EGygNBV1M6j#r=mZ5GYni-4 z(=!jEHoc-FUdn){o`?Rq*GggJP_>AujKO#y6_5Z$x>H)kOL!!#KEcZb>w+u!%>dV5^O{@-=AM=zB%hp~-rE%v)@E%fFym+GjkpE|C2 zcj%az)R?@x&>54Pp2}+rFt?2f=$miPH|Lj?#%8XstW=$@mf{uhYCD#nD5*Qro%XXq zX-_FLs%e@G^91++qf*`j>xU04a`o=A{JHQ5K9L*ybw1cMrKfWw7RpWJtZ`V@TXqX1 z=1*tu9O|=wwDfE_*haSZiqq-T(y(K{GR>;K+#0efKWPv=d+=0(L!FgEIg2=J>)LTU z7l}q0E2|;p;{91uhNnNhFbt`^8B(uFzMJ8b%`#x9;r2HBOt@|0={pCEH?zAIDVAq$ zG%iFvK7%IM8U)!<8tiT{{h!k`-muW#skCy0`!4dQ#yBp?F5IB;{mo(Y7y;hfEX*`+ z9S`}~+c%&?bt#4�@i%t5~Gj@dLUPOAqVzRQB5An@Nla0+&-{M@!v?DH(UiHNhm( zCLf>7`h2@^-K61#DUck{jyoj+oDn-N*^fuUez6iVFer+^k?~9;hzGhE;T8-eAZHJN z{9D}Rr?w)6pEBtcfH}aQR&DK&Fgbh|c)ED+>;MN9uQns^KONn^+Sxw5d`!Yz=*!XlahbA0>;@4<#b4PE>5OJ>mHc2m>3U z@G_A@=*G{d9g8|JLX4N0R{^kT2G1&D63`a*XZ%!zB6krOd}zQh zUV3j5N(p#!21*9kZ#1eK^#}1m$Cj3vsLa^OQJe|te`KU{f(IIayBTOnpy`JY-1{fm zj6a1JaMpyKkxFYY|H8Faw0?T4Q`eicIQc$4npb+{AlJ3?1%#l+FcVz?ef5m@*Ze59 zIDJ9h1Dgj!98?y*Ma|O0k+1*VBby+yw;r%Z=Z<}wv&)Xs&los-#`V_~?fZ$AqYDb0 zZT^ZZ7wg2Hqa#!Oi+aa(5^Y#8>>mss2rxo>Ow01VcDV5^oh|e-;Tk`E$I2}7<;}+l zK5q(m&QKJdXB7^e^VDL&k__3f#0-l9zobldk~t+;IY$ha_g8z!@-$vL8L4>-b7jA@ zCgywj)r4%uF%tbKA6@*S_KU9pF*T=un#0~eCAu`(6+`L2QcOFmUuahU&eCOJRxj^w zg;|=E0Y}T3v|k~G6lJ0TAkAaBJ~)l7E9D0UvMt9}{|;Y2q_Lt`U<-lq@&nHY@n&gh zi$tOub?_IeOYm_2%wDYab@f~`G5-VLdG?_bbioY_MaSW>AMpj#i|)L~xqfK*NFCFQ zsm1nY_x(qkk}IJuA`HpltOuO_Gl-H{-{as~fmaiL95Q&`e+3+pgpDP~Atgo_wAgsP zL{p8iIwzfx49QSia|^RK~m?Xop)(?0^R2_($j*M848 zW5R-k&n4EAUPHsrAYklv)+{@}WDL{|8N`Xlg)xF|GX$qGu4}LkdISil)nKr_{1wdo zzgYm#U~M*Z@YJPG4|W9i+yVK>MG)o&Q_)fQ1?ZnPcqG?B7TTTc-((nU^8MluU;}SO zm-7g35Y7Rc!I0p?JIEh6pRTiD6!REEg&KcNngFB)%%04MrOwk#US*X1q;Rp*iHeX8 zOpH)jMQq|!1J9sH=%aiLFx2L(o(`pSP-= ztP30H@c1*}G9~i{sa;7ypa6py(`?gBK3{0E& z0x)I}>rnx6FSgsr+B|L)|(E|Q=7hCy2d9Wbo^S#@;4AJu5?H#Wy z&Zv`RunjroqtCObfGmNo%S*P)3#KXw3eT+D&!Km24fI|Wv3-42$BBc!RK}gyt08XZ z-|qrk;qPk6v{=crdhosk+O9V5c5@b>QiA+U_+hd zZ%el1Gq1p`Se?D1r^g}|&>#EvlPEe{7iWvY3hW2hEm+|JCou6)#s!f+9EaQCE0slC zMOpZrAD*-T%bJ9`Bu#7rNwR&LNIGcz2D#}g$VaJO$xBUt6VN_6>xFz7*(2+1%gU&B zPRU#i^-TmNObO3rK0OsCu`$NaurijXkO!1IJfmX;T7lf@zFTz{bRblvWCpWg#i!8DMv`huAg(2nPXhr!-~XaWNT>$SZ1*-hn`^ePnD z`namu25Qx75o81RN~i=T0)<-zrOl$(YC@T(@ma@Umk+9IB4$~ead#Tof)|^dK~wv0 z+w8`-bc0m`lkJ1vgLBFN@LK$n9PwKqeFg?3fmD0BwkuzA$aO)^7u*8mz7_ z(ugxSsw9-c562#3IKs6vT1d^(n<&y?HJjrZ^!S}F)QGgX)Qb+3IJ6xOm^RK&+Nw9I zb3w^|E$SJHFr#IY>QN3TgK7mY!JpHUn;K1MTEY7^KoRQc1icxU3j=e&RG%DF-Ni*i z(?2;tq44+I06EdD_rgl&C)FA2YOs4TDAOU`n9Uqz;$`q*yLcb3*4;g-e{;Q%q+0U- zpBugvJP=();I4xcIoj{1!>M*JZtv{BJtScJRD<_f)-jb;FO?c*L#FTa;Z(7g-}knc zoekxyEkH(`kTNAtX?dhrfFx?!^3~I8q53V;GrWOY%j@e zf}4YjI{(&b9=c)zixS6HrR?b5(-khR=GC|!c&bbbmPBp4upn%j-M0Jmbmcg z{c?Vjes!|{Vq^9#E;k*Xw9tmS&kIiX%%$bbKNLql%TmqO)jsa{!dLLP(;lr1besO@wD9TxBtQ(n|zjkV60f8^oX z<#W5kxlzO-ONT@0uBnTL`YZi``q;u|7z=ML^6YnKI%Oau9F(W@nvh--1hcYx8f>9s z`QktHE0k#OROtsJyfhlw<80MuK6(|f0x`QwN{``+jT2ZzhU&bMXh12zem>eyHS-T8 zO~FPmPWP}g#O&my6|EqfO!J*b)9XWCK7lu>&M@TNm@+GAB(_v47>%>@t>;GIY_OBuSdi|WxJv-p$1 zNcDx@TMWf7Q7rE`DyhkkmeCESxa2i(?-y_rw7%bc0=NRE!PU+LQzkkdfA!PJHR$^! z6WN7~?72+Cc8q32m8p57XmEaK*Cv)6$t0uDnP#u-->j1{x2Yy9zCuQC08a)doCuE`aFwpw=rWjh*BC{#0r8^*KIVspH4c+JJ$U|c0 zs{csf^#PN95UG7H#nS3oc3t6Kl}rE1kRwJu(*Q2D;DI>0>mSF$2(@`}YTpT3ZyrKCqxb=|CAcOM2T(VuVsvdjDa{I&CM{hXWc zkHu_BECdKO94hrMEHSr{H@6$CaJ$IyOIA2G>rvu5zaK~A$=K7q0UqZQ-Je&z`F;8f zjqi&8a}nB|x}IIznap<_t)}YX57%#IeYVTHTay3c#QKFC&O@~E4y^mpHR7!QZX8GE z>RwTpOqcE%;x@Zr3~|Z$F=<=Q;coXvF$zz9TPo% z5s{M?y!OJd*n26&9mb$b+>RC-Xmm* zUJ1#n#|F??U{%USHv-^t(zB%RWyz+uvOyJ#wHQ3VO!4uPn+(a1QM?np%O(EbYggI)b?j>Fk%Iwu47c@*< z1Dmwi!>Q&z1zUo9Lh!D=EdXy)AQ;j3lV0-hZL#!E4!4UJ21p<9?f7;?>s?WR6j_LG zFJPb+5G%y@zr=R|@5nYPuayp6>t11w>5(iK;c`r1 z0`R@mil?Ac0aEfB0B^+7q$>eYSf%9Q9dc^y@MuSELT5mYR6357+~Ne)c3QW8IMx8P zOD1`e=Xci06VwLg%e^cAncVs3B>mUHI*;ep%N=KED!oqTrtXvYz~mpWlg)PT%hlgm zsU(i%VAS{a|CTcT_jBKT*e?(Nx)gw(kEtn?DUKIQJT~HG=-qtW@TQf_pS?aiZqcP{ zn>Pd4YmT>G=Ni|Q&^USXkLe=?V*ah->^gQHdFQhfc8OT`v;1X&wc4qE{bqq9gyL3K z--C4$zr!_5Yh-Z!rj1wKtB9#{rzK2TeG>PpS(1wQ57HW)oYPKoW?1wxJF=Qa!z6xd zdePJxyG3>GXP(`B!o@myeD(Q~m8t3NJy)ViijJN7SJIw2!-wf@=UDmN$uj)@BJu0F zMl5Xetxf3E5Y-F%jZ?Vt`{7<6;`{ZzA{#^1oH~+iBo+INz5^UGothQuQ zV8u^c_@L=w3W%~4z~@C5kat+LyU=Yue#3jtcKWtF{$X_}Ot|Bg=?#>ia{{oLyKT&# z>!Q&xnq*@4qGzk%XIHym^Q{~kdB(ut8BJ?~@RtrOlarcGg3XGc&PgXoojln0-godC zNm)xeP#9?Z3JQTEImXmMB|00_zHbW63JE~Ge*KZqykTk`R5LuuG@-IF8*(mAI_je5n2ulyi(4hG2(_5Si^%~Tm9nEs(ut3kZbwu66S$nGb$rxj4E+q= zv8$1=;&Gn~5EXUBMaeyHPUbA%Pjp(EcqStA+q`U7ElcLJQmm0Wp-CTFGXh983tU&S zKtX9Wi^7LOb+$msg>7AR)Xx$LybeHmbYzjpkXC}O3y*9M?PFz90%8c?+h$$UR5@l>sgA1ch*3rJL3D0x zYV&VyxKDQwbms@Ku1lt8rsp5a#^bQSfm8 zD?sfWl>9y$j7JSkW7QVW2O#%$bjA~y-~_i{&IJlF&|alwlkXU47A*2Xd&5PZlwL>~ zN@mKzYtU@42mmX?9oQaI=(yl3K*vxnraA?r#xT%YmxtR;OoQME2HHsMLNB0X#tB%` zmIFzU8Y`nH1{g$bqRKd_u{Mu?;El%h^FZ3x4_gp zC3sA?)HTh72pH3Oo2jN9s4k$9krS#*W&@Wfgl+3c>G_<1UA!jfvI{lB)3Q)Lln9i2 z^g`NZ)8)mW31j&n+f~F$>1Y0F)E=x6BIz^GHEDbe`m4Jd+lx2@0lf*u&C zwqwvfl*}wJY`hf(1)~;1@lk=WCdaJ)T$HNm&8TFII)i?LuxA{WnZxLYv_LJT%Ri_% zN030GH+~?E0NYe+y+#<#_Z;|tPX(-tOMIxi{;wYJuSot6WnnJ(dg6!J8ouZ{-o=_wk&v7oOiVmwmDHja_l1(B@v!ccj0^$21K`%}Z|z zJ^eM_?p>?4;}}@V%$fUS> zlPl)dZ_u``Aaad8|4Bx|+47;!fqYcsiU!cDqXCKGvu^T}cK_fG1m>gCZ#1y)7! z>L2rsgn=R4{Ci&gXyxObyc@_4XS_Ure9Q5|sTE2NGo6Zkg&##NptT?YnytqYSKLtZ zEAI$Aqj}XDw!d9&*ud=ISVb4!!5jD0k*N&rNQT);T#)`3}Gk}gAoA4mc3 z1et<@q}W$|eszbp1Lh#LDdOvH4Nw;{iiHRJ;sjSGY=xQj}*wk44x*IgD-7+6XIV?bo_7}T64%EXX!09hq zQM*(}1qD<;UJV=r<8XeqnUMBu9VECixdgx5*lXZv#JADu($ml{{dpQ!MTrY+Abj!5 zJgRX(`*P@m1jOoOCh#>xk~EnB^Z2E}ll&Xi?J1CNNxN0=VDIz`tN6gU z!cBMhHh@z*2Hal~r;B#XGo?GY)=`xBe>{F-@MF+q2>7IbaQUfc?cng-VLQw&T@jV4T zu3x6-gIqX^%gCyM7smf>C{38NjKq5F)gmQKk{_L2`1r!0{BE0zBTmK5>yPm>bAQfq zL*98A%}>Ff4WtI{Z8sENKH4(XwxI;4&xx3!n6Su*P$X*$_D7==6u`L8Q73V?N}9*< z(q7B$@*|=dXGRJR#~c(&(6V>ZZ4^8?%o*qJ%BSMmu}*3f!%dfy%v*POGK53lI`l|T zzBYO3g%;m(j^U^oL4PtR2qP4143GCCrmqu%V}g0Fgc_yZFY-jCyA2E6^>Bl=!qVce z-(xI7<#sA@nU8A5p33j0il6`eT1K%Ckt;T-eeCg?H%V8d0X9*KJ-MX0Xd9Fdr1hM^ zBBw+BZGo%C2SB41va^fP`GJ_I{g9d1EhXB-`s`lOU9GRr97|AbFSksG;rUZr;QY+{ z4Wx?AAq(QCr|${#U^k5BZ9>1gZ%OrncbBL$<_lSYt7iM&sLjPnagZW~Jt^<^! zC?Em&P_1Dl~J9ufiMXh{GzfI$Ro@*Ez!F<-xhg=Y^mf?^@B*I8qOv(QMg35ZN@W6Y4- zZL6Fd`k^ppNO2qZ)m9Whj6Ua7UD;^)s?{szS^tEnraBf+1G(?7;iFrNUh$OE3`D(Q4gwrA?};P17OO2GoBY=>JnRC2;$yz#ZbX@eiq)|4cc) z6yG2XExwqUF=sMf4c0$d=wrGqR|~9qqtVhQ)y6N)RWP6YFf^ggDq`0?Ttz*x-dlHb zOGo=_|FfO30mKBu2%+hchF{j-MAzj^Py7KN9+j8YHMQ{Hcy5mQY?iwc@~hCi8~MQL z)m5#k0;|`{{EfeT*Mbi=x}b;riC32V+SUPQ=S-jYuGBb_{r0bpvl{a}lMO05zeYFI zS1-`XD7?I4DDjXo@Hi)MSPFmet-ZWubhfX+O8~LaD#Sn^f>zQGUZ* z6~oRrWy+{=XRt5Hvu+R~kWP*JUW8{k1~c!z(a~N>F&9-4s8~X7AhhygAF9d zDq#TDD!MJ{%EgU4FXQK9ii(}8(+3XsyCFvRW^N8Ges4sN5IeS<%sXOct#Nx>=xY1_JFj4B-_z%66Q{j1ewGcOnExx)R*~2|51CkKtg#edgrG- zW2r!TsCtkgr0PVr{sq;y3qMc|+~FiA&h6gz7*?mRxFO?(1!46dlFM7=;m8N^<)LU4 ztu}DUyx#X(^xNa5f9~Bpy6S%hUa@4rF_>?<>L&YO&0dfd-Ze;I+|$-b~3qW5l|<( zO867ZvqUL5vd>(kIgpC*{kUA|0({Jz1;#YhC*&E4 zlLXlJ5}h!4@0u1+kdy*68@!Z(OG46QK2-fbH9bn z%#NB=FY<~K*55PtVlRQEy0fSP!T&sPiWzZTYW_m$^zyfag3w}v624l?X)Awgwr~@9 z{g3VyzXrrBH2r^RSeVA;eR~XJxtxQ59^1pJM{7od*hbcgmq%q~Wz4r8h(*bBGklD_)*k)%?AV+~99j-@}Tjn42{oZX?zA#3hyS#L}~Vbd{w zCmWDTE-S8|NAla05yah_5XpGU$jF7Y&fbod6RvKm0tXJO!Kyp#yz zV(ON)3Rd8NJZ$6Hc<#qtn}kwk&es|p=##g=Ha39grYXQ98JD<>QIHkjRQ|i}-yjYU zioaB$;DvuC*~EIJODnP#R6w_ig+Id*^-54H*r+e?2*~<9iVi`l4(tG^<&iTk^~_9v z-|Gap@#94oWOC81$DH56w7ThrY(@yD{KLtsE9{8fITSQ-CO$I?lxZ2#q1S^FxG^Xc zJQ5nPmJBI!-FfV5vBygrK-+U$gRf7m2$v> zAcn?f*NLiSI56}Zr}6NgRpq5I5-X+xp)1I z*oj+jWQ3&Vh0lE3!kGus8|f3>GWCeH8ai|Qyz=_^uL18*pVo~stjAlEDBfU5^S4x0 zXq1M$tIp&CG1SVRKkx{kta1;C57z?thwRD^WqBvyvDWJo)SpkBTMsSybi;@ z*{eH(wRy;x?c$o|%D4zJY3;4JJ$yAj0~X~3K@S|N+1cmg!DrIK2afHJ4AyEApW=SX zewju10L00@Flh>LdS>XsKc9k~sJfpW6~fzdOrNzA@S5uMmkVj{svm5$m#f+NEUkD> z*W%7-Im!Pvb35l{U8kRi-e*s{wB6~$70;Gb&HV5sW(}*0dE-m*s_?Uqh2Vul#`Tv{ zY+NF%E+oIRHQ*95OfdBmGbnp5(ZTtx*Fw_ZV40CfQj^$eJ<>D%&Z1KM&671Q>&q7x zH+v~RzanR`E_i+V3%5MFVtd#9c0}p?uIj?QMW2C-l<)n>caK@5ymAVy4$OzNo=+<8 zX!%i|k2`bGw6n#lF(6swlK#CT7y@-Te>W+{;Q)@!bUeZ6uk{Thsv`Fh+kHu1D6H_z zvR-zaRrRY6MQiIi-ugH03Hz%&xmRZ_^`PnX!RId8k765b#2=<^DDQUf?mZK+;D|1B>ni( z_Eq@w3UcVK0xR?IpU8E-_^;ikqPv_*H<4v@5?;=P1;tckcA)mlcT< z2A58M&6i}BYSaCxl?JR}QY=&}Xn#+qb1Ew=#ipy}a>aH5(=>14FM_l9+Ib?B zMG@p$2|@k-9uqTf=^9<=boXmWF@Xx$r-;q{AiO4zgh2;Zsk}F9 zoV*PV*$3tsr72m;rp9)K2P&j^DJ&A|^N4wYq%a@Ug_baIJbqDD1cTBbl1Ia8CS@mY zz7l>*`IC4xi4YYzRq}fE}bnnK|4WM=d|jSJ(p4I(;qn7b*dzF_d0u6TB-~K zIS3B#v8|Xe%H2Os6T7Yvp{(j?;5EwLW2KaLA9;7X{pl2Bo3C=z`8<5cHs^4Cb0}?& z(~nN={$y#uu)G;T=tkq=mCBQ?xYwvV(K{v|C_NZd2JoTkWIP#{24AN*ejrZgHR{*f zD8LaiVk|CvqvrHzz`cyWb4jq^AovytqbNR|F?kOJSE8V&<2HMUH)j&NWsS_$mVN?O z>Q0{yYO2e8iVNUQi9?N28O^|jA5Dm#&~K&lrPm+3Gfsz*+0x#F3y`&4Kkh(P;P%cv zp{*s(R^QHe||EBzHx8n#fqcp=`+<9K=Lo6(}z7Oq~O?Eh?qidO{o)|h?0Z|YK0JM-_; zCPS~EH+5zm(at=svU9J;~$=ddU7SR~My8t2L35iuz_q@fqp(68X@yBB*Mk+ukg=nO>+4VWfaORqfzFpEe{AK z%yyX--8BAaS^QwUC4@^6&ea5d=_z|pzEAAItv~7!Utw{al zxKDHVEqELwxbM=GbOOdRIkotX-sVI32hHCmop#>SrUu0j=g_id3k2ldl87a|(4NQ8 zH~Ys{pT#3zT(e0E_S^Z4e$e*rwT(mqAvE6!N?px$N&YdU>XP1lJ#XZX$mspjw|owZ zZG1_K;ts8|%raq7va?~Z{P){A4&nmJRP=S`S1yLC&9V8u}Ia{f8k zCHy>>dC{%U_RfU~6Z&+`jh`nSAKC$quG~=-{S@GPll_E zFS*%D&dOON#&w^Y>>9Os z7rydUn3>`4^PY|U^s9|CwTZ}?=eE4l_hj-+g>UEMw2L#=TZfN`^-_SLz$ezeM~ z>rPiS3~JeKMI9d3)9!=%^oDf*LM{yOR*t5zi;u5r+japCc*V6AEI(!5gwx(H*LHHS zNZRj#T*sX8veRaS{MX3^lXvom(ZzS`BP=4IS;4h81B5>(7~_<0_*qdeD(HTAf6)+_0h5wH3{0PFrfG3cJW;$FQ zRDX@p5oVUz5+FiF1D_9}#`F1;w}3r# z6jcnAumaZBBZm5DTs@sMuC7J;^d_zxZ+Z2VQiaT)eE9>TrIh<+FSk#%6c9S5C+9zA z+^Ket^vg}`Mt`+=_>;lUnh^(_0$g0i_qbg~zKZWyq$?PvDuf0kn2K#K5UYUXe0nEn ze1P13`k`W@n?0i!+}?3zamub>Cp0fHc*_9$T8=*7(vb=;>#WbWkD5hq@{&|aCbhfn z;d^MD*s!lg_l1k|gi;G^&pRh}zgM%{_89uG|0{t~5%5=HD)UXmTh3#T#yPyU1#VyV z`SN+V%)Z@_VJ;Q>NOFhEL9W&0I?EjT_`?s{fwVZ_Pip=Y^o2}o;pmi&+SWRz&R5g^ zfI&K&^u5vhz1Io@!i6@D0_>K^hy&k{XwD zs#(x-v5KPZE%@s?0~QDL;02)b(yB;s5!l;*L^vCKYZO4|RS5)@&fIgP2OwVubBc1Q z?}oMaCjNUj|KIHHScqEuKA^?>=YR4&hB^ClUu5MG>y01n)`uqjO083#t~BJI77jqC zHo`}>-TJlf$00?Ze?QMq5`bf zWs{X>6-WHM3Nue#o;rDD?ssN|U!HiJ%*-Pc&#uoMTO-9_x`Tk5?XxTnkw7|C9Sn zSqPlCb$g##gk!+;M`@?YOKwbi*GrFON{^f>SzoUY{1Bl0Fm&uU9{;?}hVyz!@twvy z?}Fb~xOL@rRy-EbJ1a%O1#CTY@o{qY?}BKATz$_L1lu$In13n0E6F*h z@Fwi452bWI_OI5&o8BDVE<@rsiP_~7n!Wbt_gZ#mVHbu0SvduNeY0qPXH#JO6ldq- z$`wi8Ip5dHQbUvk_O+4X`Z3yv=AS$5I9mFjj*EknQk(PL@MXG0xZ85S|9bs07`Zjx zMcd39^lKoGSPZ`R+DY@=4i4ew;k1>fEL9Sz>(KxYBaUKTDDcvmRPb^wWgeHRGU?0f zAE4vZ)KoP4)!e`H&qX<>y{*N*T6#3d3`iVFL=M^xnmi;jjHkt3JhJpXA65EJ%yhTc zRXR>2r_*EGYv{|9+AgJ)Fs|*fdXJ;26M|d4gFAQs?)>!Z)d?h3CHot!$5s**^#Sm9 zK^LV>uG2E?{l3%w8C8u7>WroqrDxMpQtOJBxX)>+sbPPnOE-iF zZJSiw;c%2p+<-B(dTl4Y?^nJN_O?-djaPc0xj~mEeUQYIw_HH|RcWyY^ba*$(3}36 z=~VaQyquE$SjdT9>cP|-z@4Zd4TrE?!4=Hzxg@ExZI^Mh(Id3yt*T;tnv_*ic><+b%SP}VKWNi*#IjodkGRwq?GGGQYREXk^|(rh@VD1? z)i<%ZgXYr;9t^3roIjuprJTLXli|kw(N_OQfa0Mq7s+gy#`+bL4}T`_j2m-ZbhS>o zvZ*KRPeg5_Y}xRYM7*eUrqsRN?TFHdZ?dB=R=#gfY!Wdjv*a|IO36T78npm?!&T58 zDZkNte8r~_Y?r+ohk4OIk0g23+Gm(gt$*p=wf!HNE<;)@fjRgc_#QQO;{Pd`8EoPS z=^g#Ko@YDN&g`ePso@f;b*D3gjOY*8-*QLQu_R3%KFxk>G1OMVN9Ah1p)-1U5H0e# zb5v%{nIog~8R$5Yxb0VZM3jUc{n+2D*IGFp8|}MUWY;$0&o8~=t6NL)+#KgJ+&nn) zs9H-RK9A4PMfFS0ryE$$Bc0~RYx3hScitGn5WkngK2`CNIcqPBRB9O!=}*@#_#JCy zi#d6IEq7&~5L~2JAB?uxO4khMy*vE4x`JI*)bK~zJ^?>)*x68O#rJ1O#??+QqIy9m zXmQ~#)K$GKAi3g892T^f(ux2q;>u=fc}-B}H?J_AxKG-A=g~f_pC|JpI(+mV(gI%= z%09T5{kDv4l@QaK6Tf67alc)iU|A|xdeqNQ_D$)zaGOgdRbTu@kLhVZ`^q-|MiK^8 z#_zxnZNSMwYl!tOuX41MjsC;OcRCA+rtNAAWD+4sc2UF0`v#Vg0c zhan6;>(;R3x*In4Gws+5UJdk29fF4?1BbXXI9AleO9g@9b6 zGTV}NOcQ!6@FMzhH)BVPmMsO*)Pr`R5mXFWqW zdi^j>_wdyh!8GX}nl2fWJQ*Co9b1JYJx$Y0@{Pl@hhAsmV(vE{x43No+zt?8uI_qD zrq&m;CSBZ5djW^#9dE6Qar7UMls(%RO8N#{ z!l$$&fI61%@z&v_--e}$%EX26L~Zaqc*&2<77?%VI47VQABmC-CY(q=q~iix!wh`= z!g^R$bW{j)ijjqJlisd9iF8Bl6za8`_cW^kn;5)j?w8^iPB8;^f)hVs;nE0n^X zJ;wcOr1|wX$?@UrEI!TJjl#|=b039ug( z2ynv;;{w(;1J>3L?tG&!{+Cepf9l|&WOhC%_P)u^+MefsuaGy;QPh?#TF61JQ{?G<5S zj!z4M+7eD+#P)YGB(R)!8K;sy*pG4&5OW%$o>Vb~3ZR7A@UzrC>Y32DoXKyvi*^l zD~eax25yhni=JJsd6HzPuqZ8mRX88ps^XS(sFin?NI1H0 zm>3H0wcm?9&)f9K2>fC5QDfrR3)P&#MUbgt`z-Hy=tR4>x@IHv@-x6FbiCSm$D&@u zZ$pE!d#bxH|JrbY4^r)g4!-f1xWsIiMFJZxXac`35=XaKx$nF7v7if!d;3__zpo>5 z{I8MU*)wEgLn)18{fH?!MGH^XQMZF7Sl+ANZ~Wcs?Y?|QyWUJWE1eO4*>*P4G~>9g z68_JGH*+*7bEjx02aL?w!r!Aaa=1vOl8gsU{MLFQ&Vv46HE>N{dS7hFpq;pmO@+m& z)DvR`J@y8Nbh=2Lo25s;U9PtOjmste->B`U#_${SF4xZaRqrGj3=|2`xC_C^^5<9f9;p#M zjQ9q5cl0 zJV|&$K0Q}9;1hEvSHipgn%xU97s`Y&2h)85_bJAy%!v_=^5jV#pC^8x0-G+Wza4YX zQMz%nqCs?7O#4m8A@WVf>UDW2apm#xvlk#486}S0J`UfZr)1oHv@d(`WVI|?+UhxJ zIh1_)Uk^`cewVENEw+ANVd}J^?I`JkR(f};Qx2byt&+cObIpm&rhi|Ve#!I8?Ieod zV?P8l*?j3BPA51Ly*STlz z?V^c1+ZGqeQy*6=MiXQfIqR{bOnLL0LOqkOBTJlFb6$INk|?tWN88tnjLUvBJt5o+ zk#N(1q)wcU5yeBEYrt1pg51&06wbDuYO<&E)wKFOk$;>n#4&K8e+c$Le&kCGXnOV` zJaE&GO8|~OO9GbGxcv-&sE-_xW zW$Otkh_8^y2Ynl%uUjqNJpMe#ftb1IjXQL|a442;wn~VekuVP2(bwFzXy zJZ@jw zr3!gQMfD1o4Hc75%S1y#9)d^sm40FGyJhR~jj+TU4|z3zJt*ckL_y@@0C3q z{sRWzz%J=XFvabY&d|UI7jx$`emgwI$T~d6xmT~Kh`4uC>}SZ*EpwL4FInr)O~4(x zKBeb?Im!eqen+;a;&eW7%q9K7qOswoO1kI=x&yKAE5llkd&Q6+&7Y(Pz_>-5O5=gu zeSzC)g;4O{uZbw9U(IvgoGZ9>>!g<|xxipYx)rbR6{0BT#Mg8u@Sqe3fUZoc(#B96 zn-J`>*j_Gp7QFXS_sqf;w6HP1ndR#-q8ocwtDPm0Y+1;>!rHs@dj9(9oJYhguzpk0 zcNq3#Hn$R8^nKJ{0napu=uRJZJE^wn$rDpj&0nOQ+;a~tHLbb38@TX16L$y$ar_H9 zNs%nJ{Wde5mDRVSQ*YfnufGzP<(}w{&f>M8WyGvb{`M5UfpByA?k@2C{OuM`&!fKE zuUw`KlF)&7j-=0$^YXyjvK+MXuK$A4Htlz-^p^p=TGd<(pLua`15Vz>W zuJAGg_{#p`OE&TJ*T$XQL!Fh5^qjO`ldoTJ2Y3%fLkZ|nJHZrn?|5RX{ex#LS1u-Mu0wDsS1 zp&=TO6ot2LQAqJMLKpTkSo<5Kg!&0te0Aa^d@%+&JztA0PW7BxP46v7KTOsxG+c{u zSO=i@(j^s-*N&?^#%`O{zkI83+&)s}IX<{{D{b4+l3rCLNH~7hx6ZZIv&5?l5QICJ z+4MT4W@Q4Tgb6;< zmKAKdR3>M||It`1Dkg6QiPh zK-uRPqVDQ8h8%cq zR zrP&FI`!c@#wSe@W>ouzEzvg;z=7nbc?XhQBUXy({uA# z{wDw4Py509wccg0l=&}%RJ8gC2P978#|O{%qb^f-i%m+eTX?&r`0>)-@W(U9`9M}1 z@z_vN?HR782;0EnualgK*6fra>iWX^R}Twx`_gt+`v#lBK;DbWU%q%P#h(;ht{>zx zC2QwTPeyp0BUFl6GVZ-{?h1z7r-Gk#zPXS>7}AxHq6eRxhXa8Q%cNC?#H37-7A#)r7F#zVFy_Up65?tQFUgFC=_|X501OdEZ7*- z2AFAX&*t_Sc$)Pu5L6il2at^ecV1tac>3R202Y2P6?wd9zA#`>q|UW?7<$d(mMr{r ztK826P#Qp9p9Gk12&)I)(x+1!+h7UAYYNcYyS}0)J4K#m=gE|&TRWlna29n-)>4q3 z`T%f*ULdeib=FQ{3rH$T>R>kh5=&r_+_iT4ll8+TG4k^rN$690+oR&?i~51_!$R&hl&DjyoQR> zI#P777dO$5UmNIQ65605lRJG8Ieg9DVXl9wO6M<~-}&SC4m&|xsi4+6Nd_-5%2p^t z5F^fyg$KkOimk(4fTU2qG<*M>2l#+YDHo2liWuUAsEw#rP=-h>?9Sa@8Rw{C^M2B= zX(k}4$ENrUubd6SHFyYX7Q>5qIn#&dZ=R;304&2={|T}asJW5qIAqbbO}|n-VUuQ4 z@M|0wKPVbXmUi53`T6Yg-r;}(_krDwdbH0n%T%0P>{_=8fx&Czd>|*$Yn78|XVZyV zg8dk1L(V|I4ypdIxSaUfY^yDt16U_N{Jl{3J^lapng5s1pbG&wLi%lrp`)^0%Ks!c zP8qI6RyYiQ{k9xM&FD|_m?D#kP9UT^`_%6Eu>`f4N>jQNdnUxyL@j%7%BGC6!ti+EUOaWKut_P}tC`=BYwTVblP%R`dzhr#py=?K9^ zy$K50vZ;BZ4P~U<6qfyi*If%7D7kX;G}Oib5Fo{?mmV=Nw(x*Qne-Y7dsWzAUz z0ISK~nXwLCGFyU1zBx}GRtR)QeH;C1WAjMi#I%0Dw`4(qLH;=V@G;#DDKy6+%b8a1 z_)gZ!QS|_&?lFM{M?MP z8r3?S6FNf1A~TYIyxe;6{g&Lv4~-?0I>!K(iEO&vrV|2kFv&+*nCj7~f~HFxN5v^c zR_c4OiBiGT8-^)67T(NR&?Hq4=N)MEyu-}hbFl~I2kTSwIWzAZxi8zP0=EuKs-Lm= zbF3IqYyuOZnWysQ?`xhu8ej-qZ-=iWM@?YcR*L)+{7$dF0uPtqCnl2A8JXdQAJHX5 z`OM7P#DjCCrNo-2afjuZl*gY|h0`2Fb&K|2NkQ(@wH@Azf8p7Hgc_Ecd4J6&j=w+R zBFDP%g%1UG8SH(fzO<>|e)U85p|{ajt~+=6|DBk&7%wxUwfQw$_u|Ag?Djfxfb?m8 zU)sK>+f55wq~Rsf@H~QWqi~<=>||!&$|2nb2^Sn}BvcIub3Nl?dxE#Q+Z#gOxNyel zIw83cE2~Ik2t7}_env!gAfp4zkVwCF{i%D!+kimu#oXE<73fBa|HfIoApmIsUSS{H zZ=AONXYI2fcE35%8<1%J>i@4d2Y82}qCK1FTyrh5v`?`sOhDMTqK)aDye_wC(#;2w z=g5PTR4nB#t5Gra%$5sX2bffLiT_l$jiCXc@#;DwC?{y41j%KYWzMRU#rfx{X?p3fG zO&((2bKa9r&7S(tm&_Mkg0pZfacg5M!TtB@^=f8%Y(~5qY4;O0I^HX+`yv0qXkPl|cq?C=(r_K@uN6+Vx!-ZJtuuj-qWl42ckD(8v<5?=5b%C7Qhx?0@G zjBos?Yxm?hLTOekQoxSEoXer+o+6E-yl$Ba!6O0x{5<#0jp97o&bR)OXKl}mk>SB5 zhQKpz;(t)TDSc~+?7s0Rc-;f70|GJABg+2 zU_(88p4BH7RDU8LrCRzBA<=oICFgDFgXMfgQ1^Kb;;&c_l6`gu9>3 zg=JElc?Xzc^!OYtQXW6gqn2x~_uNMo|1syYYKM`SBogl>IiJ|T||qX)!q>^#6r^&z?aPw!KH#efw|;<=Ovk4?a`Rcsdrya!>#Kxl$>d%PXF?0!?DZeq^Is0rFM@jZy0cxCt@ zUXgOl%%;t-f_WS5*mrw#e8<%JwKC`CZ2jk3Gj*w@){Sak2)B($!j5%QrhS^aRfA7t zl6wZb0$wP;p{_yn&VV|h;$ni)2MICI;YdIXkIRg668AATme1&4`0 zP1);04Ip1Al;3k!9h+~5ue&kk)FuW9fvXZSGjh-~!s;Z_=!()>jU1A?<(b5m4zz6f zw}Vsc{Kfmg3GFO1FvpVtXj(E@oxyEd?%swBO5G|w9c_W#t_+z$cn$K1)-Yhr!Ax)9 z7egm{;*+Cz`SV4>U~t61hU&gZWtq6yxkzPphiY)JcrQJoA=0z&%x`KK^`)Eplwh?w zv#wJMWv<(lD`6|hmcn;NCTx;?e$!269#An~z=RH>=v|*4b(OA@vU`Djf~;Vjp>-R)4DYPWgjotvabM=l?_K`iBku8L7M`yZ@)5#cJ)}L+}NNirm#x z)MUbvQS4M>-l4xJfJbaXx^VueOv4^^2Iv=hD&z`7ht-Ez_kSBSKQkgtverH&$mw4l1L@g zBdgoJuS{$N#!j8{+T`~LQmc!29)lf+pc=a8Zv&PdcnVT5+OGBcl9c)$Kb_?@d~X9g zt#SshBAkjC^4FX^ZLpm;5XTkj_E9z%`3eEfm7nE+h}===BQhPT{;+VDtR})NLctz1Q+*WJ((m)?H%NDR-DXcLm#tcg$BJctC`v1h-nwP{B+=5|$hPqZ{+h2W3tr|? zrVPaa6@O0CCHwWl=jsmI=PtYbCir5XFX^m0#1$ETuF4s4=M^+-(e$MKJdAY`xvPpK zA(ZeyIejG_oWzfcvua>EowWMGU8Jk~*)M7(Q`;pmL~P}yO$yeN)PVxW8=OW@?9&^F zz0s2PlT=AI-5cg-Iu`T&+{s6F6!V2wr|{6 zN=(j^Oa~tO+w-?7s2tueuM${!(e*-~GLhOfB?C~i)RT3=m(SPWyMHMcH&7UMAV}ak z1>6w5jNM4j09XKXadD_PV2RdM4l<~9yD0%wR3)CkRDh+spUQuMc)#?#gAg)9q2yV* ze$AT}(&;pl)kEC{P(;2_+ghzfrj*y!GwJUJN{{-g2ay7)S?^7)WS33qzd|g9!^>V5 z29amULda!cpG-vCe^+_}M{EMuvi1Y3lE1?;$XC~u09V2R&S5$J5SC)d=?NP97zNdW zPe7?bl;zUR(?;a?=IB4ZAeHEAG4B6Goikp*O3z6Dt19`27PlnN$e#Iwu&(q^EI>#& zy}R_K#q4s3&Cdiwk-OH6*Y9alS697Fy@VCDi9eg&`{ElB=c$br_E1c&*XT{^yU@}W zm0dzP#~(ZGS)@GD#CC@x(h8xHS$8jKwsyuH%@k>u=j!1eMNW4^+^a9)yF4a$&n04)}qJmS3#Hrnn-Z@~Q zo{FPx1f5%6k!bq0$+}G^L{p_JuUDH!zsuo4#Pfvp<@n@w)R>5QswyFuYSpDJ!&J}l zsGw2f%@W&D!K1>TNq4)WJ_fuyTkp8&xKK9HSN57<6(^6mmTD8Gc-R@sE*vQOWArF; zPx@I%cI62bjjcuX6YZh$7F3_`K#pQxPLhTDce8_tmy`5HNrk099T&7g9AY>69&NCM zu!NL1YzehC96lW!a1OBYBQ0z>{D$s8sjdIGoYja|dwo@8;kbvBc%H;Iyw!G^Q({?SBFrfm$W^J1@yA9!@wHCWHo@-G1Bz&H00k zI*QOI=yi0okr7lm z`UwtjK)gbW^X)dvI>h-b;1>9cuskz=3NS&s7OytQ8|OObo`foKeYiKtQf9%YGv`&8 zJye<8aNH?wxWVFwQMp706jDx29ik$UG4H~XCoucx-&zuOM0mQ4l4Czl|IPxQjZJHj1diwRP%eJ8nJ(fn0sd^N7QQ@~1+W1w#^tpID=)Uw zHSsgp5{r`BQMa-2JMK%!D6BzM_Z^Nk!tx-Hp}tL^CAtZ>M$lH2WSzl}O>iNTwuJm# zfhX*-&?)l8-$ zwd`P~-Vy=%qWLCcZ0g&90pJM;_n~zd`BqfDes+jlMPerd^Z9>5za`$E&a34_e z-8r0?R9ptQfc?`zIWQyYZuU;yKg?7#--7-=VLzDe^Bm7FWn+*( zTxuGo)Lg1u?&`~)8p&fx>%a5$&|~;$A@oQA-H0R5R{74z9Q8b-x$1jUQ(*X`k&Evx ze6XkMvyz&<9RGTb*H^>og50?*w0C`}O&!fWeal+W7$r&n8&)HG`ctWBqad7fIP(^x zubuD7lu-T{pZZ3liH&Dve~z?4dY0?xx73E)t{FTw)cUKKpmg5MxIC%!8*Rfbvs6*B zsc-bQ;%B8xviTS95{`l{Q)ssKnd&92F}~9HBn2SPMkIy_%E`7tTdC=*s|Bc(`E`P5 ztog0vAfnXcfxLf)u$Bd)11h3i;>-ZmtjtjTK))m>4jv$x3E_lxZ*_5cahE6!F?M4Hv!6PH-6F zq^ovYzG^1tlD0kbqb8-uP_rEGI4n0s!8Kxef!=$is@x{vq-cA7S6LA{yR+Bb22((w z2eWQo{wtfDwcEfwlbcCg?hL@C+OxlfBt&1a>s8onnIHz0D@Xz@Di8kf6DcQo6qRy8 zBQ74vBS__~^kB8|4#uGVw3c%<#ZMNltX?aGiin%l!S(vY`+h;Y zvu``W3IR>EP?C7nTwYCpzuq8Kf2A*_Pfm~O!15K%#987#ak8#5s&}C-wXo1{H{axO z@8Eo>E*T9>Y?LTq_D7ST_nSk-m6YZm_Ei@0Kq+@3ODe=Y(a2r2CQb%42)QU@Jnm^` zxTF(wo5t7j`DyZRht=NN2xs`AU>+yAbRkH{g@D3~W(A9xZ1fB0%xA8IN;GWjg`SY?zUef(c z;RB#?cAjz>Na%T>`2jM^zw(s0=dZ>gQz%sZWiagv@BAQ5zb5I@rY^a!kg=7&J)NfY zXKoT{3y*2$Nq=iPclx+!CM`_HT&1ZWB^8lab_Q#}i8_z1`gqaJBiZEd{_x&;zGkqI z+qc{Ly!uIh8cUx^1`d9f-gPm%z$UN}n0Ik+O3VcIXDiN-2P+O0js}^sufu19y5=7e zS{zFWa%*tLX!D}&4wNWq=b|Ge5w63HC+HD=9d;>|6GOYzlcxXHx^R4U%FSrB;gF2`oCv3k zYem7V&cCWIFqHn~HEw^>pu3vce$W2B7JpT11dYpMFy+ajlD6gD zxH0Nkf#@*_u|^q<_tNg7J9l2`A>PA1-|d&=$@p%wVoo?i1$B}aOD{fNy24FqUJ@5U zi}sumOh2ZOSnY{t?rp_I6SZ#0x*|?PMa<=axFh*JE`+Xwl3iCc9hI}(>or$;Va-jS z{ai2*U+Yd~WmesB`|hZbvdK?~U0y=;b+r&Gr9}8wOB`nM>Apz1g zzva#=bkuY%{hsouV{w0fEU#ihAw*bC{LaCcz;&Nz-UZ>RKv0=|k*K^>u6-c1c%N9W zaP8gIcwUX_i?n$$SI#ZUCAW;CqAw<0TITV|MZ|rs5>#Q#y(TIU(IBcQ)}Z#YiP#je za)NK*n}knB$L599K%XdRx7mv<%0m?P`wgld?^@QcG#u*POH0raLmOKA|K)D{LQMP+ zW+N!Q8_|^;@sWy#b>@2vZ+fs4)}KvvP) zWg&ER88#<%ruu|kMCTc2iG@AF>~~2EsTeOc98o+9w&9`Xf&;UzJ30h^hs~iyR8X!J zPr%CW*7DMD(LvQjiRJ=-ial7JT;KmYdGuuD+z2~*np=gY{8&qf~xznPEc4dNXik4W<^07!G)we zHV=4UJvDau$wE9zVL`fgosH>*TrBebtpVVyMZ=kv5$!No?Gb4B^~c{Je^N3Cu76X~ zcd4!-eG2u$ju*T!?sBaTc?dH@y2n`t?Ba@{uC|EYqQHJCp=qAi4f`cNpoX93fQM}_SlT#mX3OzQ-)cWiq< zVAqkR!84vS&Vl8rBc5~vC_+uc@vd${L?>ug%J;Qwtg4YjY|*c^SWq1`nlke4%0a1R z=GM1S9>)9MEIt4JG27e8DnbQZd#$t|oP;G|*n1;gIY~M;fyNhKcc@tVfe{jB#4Px$ z80!gJym1Y{b>c*bkb_!5OQrW`Ogfyv5wh$rIhg%f>kt?%ICH2FdoxH_aLIWc_TgR+ z@qf@i*w?%XINHT|z8$nir(Fd1)t`qo^FjEXTH`YFnj}%HA6R0o%f$1#y;rQa|GOq@ z=G))97p(c?kLKu<%k~B~M{BP`PyVi?AWZZA+E4AID?il)>vc`Z^Ah#7dEaI1cm2^A z4zKW@Xy$yLFp=Z;@bSc>8OM{s4_T{IT|6m2pQFhlEf7{Jyy6l)ioxF_Qe+YkgNmTW zNuW>N%EYE88RM6~6VH{U!xG_?BMI?aU;UpqSl8aPS)FHUWqkV`~$~opD4) zEyJoGdYfi^gHg~t;fp; zHke~u;IY6idM}NGAil||!;Gn~3a+F!sP=>9_OCCmOZgg4O1wA6# zRayE4iJ3J$kzU~pFe9>2{Z>obtS(3Q&YmLx8AsLAqZ>N*VVGpkK>=9zejQccfV7L$ z#NU#XOa7a_n=_}9gHR!|=SD*PKJ7A8*sx+sDy1~SP9k((Y$Ki%ux&YEN6@X4p`R`WS!GJ_S55uXOP@dJoD{!c-%-Q3JLif=y<}uga#}F-_Tp}U>W3~C5@ZWp6Jc| z^RtJP8_(~RJ`i!qka}6kPkK4tA9c`16?1*groC5w36_+8QioxO5J%etCn}yJk-WHq~3j?*AUN19O3Kdjv+ZG2A~b*ov|*Sggy26 zqxruo^v{ujM@=M~iQE3`JseX8B+k(7MuONjrL~Sd@owBV{_t?Wc-x-^`)Qy=Kyr&c z@|*hW1w3!#iFgKJZ|nfQ*A+Br6?m0+>{Ae&8xcmKIp#=X`>DcP<(mxyesIrMJ+ohq& zKVpboieG{j#yPd+v(P^8o_FCTn1#DItfnq?xnt?aN=cCETWOWkwPo|GS4= zKyrrIVnng;KMw>BUL+VOzbv(U(=Jq1weT!qQpl<8;`yXk;q=r3x!Rr~EO#ExO3}n; zBdVjZcO7XkQQ911>46+FX4rtt+E@CCm$j5UMR?m2u2DJ_MmiabT=!V$5i_a1puuUF z6pYpCRB7PV>dp3&gP~ayA8LJ)q+3zD@ka5TxW-D*@BJJ+TZgV*D!E651K(F-XX!0a zia1a#y@e8lFWVhodi4biCg<0cUfe`=GDf7tzoFUwYh+z)Qo?T`wMod_fJnG7WRT|OC+_-ava?pB70jBp2fg+RU{-7j3!x=S$* z?SsiW{BM0%6%uI1D$n1VH~7;P$EdgE5mk-`Hb%gJ3+IZ9uUzl zBK0LEgd$kUz5;Qxv>7V=e5Wr^MtHh_CYE?G zoeXbBT1F9Lp+%l|UyZ8i&SHAcVqHRzX>NvifhQR$LSOM4w67(Xojq{eceNYpSO_DEq!t&k{Sbwy)$^Poa0TpGP5JhSOYj6ET zmLucO*UFCRODJy0c>pQcJ%JOV1rnpidb^d5-}m&cYB^H5mK=)xVyi&@qoX?$>^!yJ z1V6~-AFo4d?9;Es`Qb-Xt5}44F!!_sk#W9*hsb4U>ae^9Nt%GggTb1yS64^#4k`DS zBumAIJ0tToq1DzL6?yJ2!R1LvX4QCq@r(Jzm3+ar4x|HD1er6CQ$*Rf_E0|0(>aSATy`lRzWS#ec3_O$AA)Kq*WlOdz~NzX0FG# zpo7}(W9BB7^F3F4EAE8I{%Wd4hIZ{#E1hOHcK*-Oh6Fa#U7#WC960SDv*hvBzoC2U zxajYK+e=t7{Lj56VWZ)#=J3^gE5l0rd-7`;4pATGxU0%1wRis`Jmm_x>l;y%4DHEO z@0mRCL;vC}%w z+SA(6mq1SG8{(fqMaL(QdC3mVn_z&*)}<{tjnE~gK3Z9n<|wup?tZVX++1o_t#4dv z71}tR@X_g04vjV;PUHC-&8NniW;hL}-jmjy_ZJI-N}F32^!}W~6(;C@_^raIb>19j z=_x@I*p@@MmV~iv6^ZPB#e6Dh=bnVO6ovJSdLMP`WoH(njT!ZT?$01YaM4+{#jG-pqHsUj zK$Ghu@M2M+Y-zY9FQ4AqyxP8IO9ySB$U+L%kb6flZL`DJjMAe1a^Z~A^X6wjgX%77 zS=knN`LOt%e^kdN&}=u`UTIqE_2U*Pvg%U9!EN?C&trZkV>)_eL8k*9!CqTHdK$?| zD$hT~5baF<0y)H~${MIR)`fTe7Nd~m6{#4BkQQB>b9cOIkce65q)k`sUn3GYLyl7+ zCg%|A3)oL@;@!qwu?*L2YAB`{X5%J;2r8;fE^;ARaY{duEnlvt&J}{#u9!`)$6KfK zs!H!9CIK8qkd!7Ni3ItNs8V)|Ac_?WVtt+sIcB{d<*1>Mw6G6gE>f;PBnT~zvf7)e z&+Puh>;3tuy9`sxJ8&YxDwPTUyqPe$s2U`Z)-yIh3c?=1a0sOU+~jMKi=LuAI4Y({ z`2l%;u^CW2%Tsp?N`MJUgH!C*q#pV*7 z!3tS67;uxF%r^-lyy|=p3b4z}J6lupTk&I_xyZVwGjDy!RPN)KNxFAC+~ylpWz=U2 zEWx{6l>_8 zq^Z=AiIITJiS^j4mA`Q)2a4;O_ySwf6n?eT49#=WIvb_*5;b6nqyIu|1G6Ey&Yho8 zx*r-??5G$S54zUlGo4}rNSkg0+=gs+U^qU*tYN4OVkiD0P#uzFE*O%0AF)y7`jrrv zB`ZO^&?ksq4!u!~R92xn!F@gil!M-btO@SN6F69$2Ht|`{1PuB`(`8ld$Y?Kq0e`a zB+hNu>=yj*!b6~WKFO+2<>R9dw?T&8J9Vz?pe>%&g52LM`-oRDqYLvP!GS^Ry~8W{uZOIe6gmSVGs3lbTMGU6U$pT&j!b+$-Y;GET)6cwBF+Pn zP+2v;px({3BB*;WM3N#;L6Gj#g&IALd=89Q40&ylsfvz_x6+RUUN@8`x z`O8FIrAT2$x$b@b#a=`46$fpJ(rl`#cSO&J8XBrfk!+%w_i^88PSX)^B3~Bw{kxOB z5%h?sl_Fe8Sj*dqMryO1v19h6BnO?;C&y7@aF#0??>TV1hzfP1q&_YC21nhZPiF#| z7GV;dZ_b3toRZ2kXLVc=jz@!`0VmxzlE}{)PxD>B< z7w9%2R;sfe0f)HtyyqVp>$R9QXmouO?qT?1+($#gxade^imAkTKL$u)0cLJkf;9xT z4N_ZBVFmT+{SnpdyIJmJmbGsZbsIk3gFeR`ru9cFgo@4}b>`{llP ze@q$an~IPLUbU$bNo^SO;e@Kuc3bJp8R8}PBbA8m?PiG* z0{6Qyj?s23V&H=CICvFQgbqp6`z8}2j~?OxAcxrY1Pf>|1CDa_DqDEMLJ0jiUriuVE~jN_FpEEY{~B8Um-^HEoNqznC!_6>ei|u?p>CjwkREih@mm#x z=`Wb8=X!!aF+HOw`*=>vZ~Ojoj_>i`iPQ4gTDL61(TEP{|8G(*1WkEftCMK9Cv(8s zpcJK@r(5wcRk@V+UGOVv2j6x>wm!K}Q6WYz&EIxCR!S<-qnEWyLdp$1`-tedN`J1j z$$ph7IW>_yDId|7A?H-YSR$Sv9>=fAq53JEg|W}%X2ei{S>0obU3GirRB_)M@O0In z_ZSb6x9u+ED|#2pGh^vggUB)RqN?E8QqG8lst znB-756~$d#1=VWxvzwvFvntZFr4spM5uN}GG!<-n_JJ*pvcDD?P7CC^Nn+c;!th+8 z{F70|MeB|D$`_mUAHhg2f&n?@vJo+t>bdL*sSdAvwkcVE78RZUWXxRBVM}Zy3slEk zj`Ti8XB;4F(7)#==X=+aV)7TtPYMD^60Q3xC+7?KJH~n)dfJ_VRPu(MY^!ZOMoQ`Y zc|-@qz>APE)QR{RR2i_Pla!h2O1d7#Ks0h0hFKT0M8qrZzvC-eq>4eF*(8f@zp+eO6Jomh0Hbjbfs_c}geak4aD($1Kd3pR0whS4eldjFj(wv2eTOH} z^kJ)tL@EvIsf-v1v=AKr-tYXK96BWqrVnCa3*`sy+wSXdCg2E&VK|IWI&Pm&Muq(` zbG|}Bcl3&sQ?E^;HU*b;7)7G03Urk48pfq&AxcBRG(WBD`~;}2ur|*LZE~GpxQKR} zD9sWK*9nH;s93rNG>RM530G_|Kjvxm~UW!erYxNDVQ5=P74 z&SS%Xg_oQVa8yLeoajDTko6Y^=>frOilLB#Jz~zFmd_ySPa+Dz7j@DRR{20}1Of{% zJBMODSce3n%I9(li~Yd;SNj~N)Bj1EHuF^!(7*7XP7Qv1y89>JduQ73Nq>e!mABjO zmt(L47MgNQG6W`pr;W|p*416BF7rB#oN_&;{r9;#JX4IJz zg=$o!FXCiGgV}TMW}Z{(Hg9fl)_$BCWeI-*wnN%i^^-U zzZjy{ly0&NuY6*3=_tZp&+tRVvquM1O2z0UHKNDON+HS{sL5a-J%R_F;*+B;UOv+D zQ#0H>f>BT$_}%1Sum%~>JZ*J+y6^P%L!yr4#58=&ls?^&M3g4O&nM<$5>v(#N5G8& zHKGdF@OmkzL<+#TMXg9fHU>G>u1Bd0}IU8QS` z9Vo5VvlB5vFo3iL5}AHc}$r97!(ZD=u@v{ovK}1uerU*k^hm}lj0F-cZ zV6@@BvGu= zwNajRiL8DBDwXhe(ke7%Y<5YLTn#Bzz<`IVkgijKbwfRYf<5Gs?#Y!&o7#1dMpkN#$&mS#nVo^X|%ylhV+G{4O zs#k<(bYC&7Dl4{%Uu=DgVS1<`;M^D0khChmu+t+{uTNg}hDEIOmYriZ-&mo*oIox& zEqhWp%?slW@!a@_ilA4Bk`7?oA9m-oQ}s{om$;E@#QjwP`7$+{3VT7G*HiYdvU^XD z3IcW`yS8AA&x_IVNVK)b&cf&H~_m(-!|?k5cHT4G{W$T zv$Kel@n65;VXH5_~5Fvyf zI1xy_ua46FN6{qkSsvreoT`IwvpJuIgbIn3LY9{>nm!iL1depZ(4YN!4|wgbVP$5JX%93K1`ufowq)nmdZ|j3LHz3&2y7g;4 zEFC9m{-nN)s=@uFo=1U|pvdb}=D+iA-uRz5vdIx@@xeuNx(kkdX~*$~g}N%A^h6pN zqcz8hjqf@gA25!5SGL|w(;pb>2PkTjE-xQ;qo zhL@BF5Ix-3mJe2wbwh%5X*`uc|Rl14v2$Wdp%U( zH}o0lZqsu8{n2R4DE#1<(MRhm5t1wau2wvTiclfw93KHd1FPg+M;hvg)0 zLNZ`1WVg+xGX%vz7WnF*@oMxQV7ZojnvkGOumdGXr5pSR*@^6bgLPm@KR}D%a=?^a zu>9cvkoD&AQ1);8c!g9dQIRZD*|SV2LR^)E&}fx)Lheb*RJN>FNRnmjk~9gqTZQZ~ z$uhQ#C6T4E@7oN7e zpDiFMs9Ao(6S9M>p-gu1im2P46%Y%@j1i|$Wu%g|Kw?NE${g3b*{}g}1a&v-A0<#` zjHf6srZ7|FwiPq$VX&A+lp9_-&c0nHnd;N_(i`{>=WWoojj-v2{f4mp$8NEgMj7R| z=`~Jj^Wl{GWUIMfA2UIxWg&~2Pfk^{2h$AV<&5@&^$e0(^C9l90(=1#o_44XTzi`3 zjH;rAZvRUQ4U*evOz~GfMIf)#iXBjlEi?bw$S^$F|8){RyH$Ol5xw4(=I+*Dx5eVx zo79{GTgy*i((Pg%KKsVKU!F+;#z)kX>ez8{dvB=3bt>EwoVuVCK7LI5qxsJK#3xqS zq$5f7O_#=YD%E!MW@ff!Y{DYY9zIG>i@D}E|J^FsrxWKr2tFvGe z;r`$(sq;pwnd{!>n|SbQoSF?)^Ui`Q@pdQ1m z3x5YB_ud;mtNk!KSQAS?AK@D4;&K_6>Vl%FFK)*JwT~NQDzN?LFnyBfLyI zj-y0pAAJ^Ap~wLiMDOcb)}YMr%_+{b04)6S*E-;a+~&jr@))is6lQg0(_=IUnRLN{ z*F9NJDol$3GU%`PZu>!{$vaTu;0PRU2UFR~e>%covNU4v@dl2nyrhQb1Frx&j}cXK zr~}xC$`5FW6ng%on5Cz1bfT_tpW9uSG10BpnLmra2t^EPF>su};O3_wH(3(7r*8c` z1MQ}yII+l{U6Sp>huo2NgV`&PS4JTGZ;?Wxn7D{Oue4p1!)MGMM_Cp^G> zzwg<6MoJ+fQAs#EVe`S=aT3?1bY<#_o~bI?oI3M4Ji0_->#8j4-HmJBr?evlw_F-j zRVTg~mrBY~c$(m3sx6o5{r8)LQzto1Pu_n(DT~6<^q`1fImydlu1&^pt7rf-z#%?( zHug)2Qg_9;v|#ovK_-LL<7DL(b+pqeJSy7jMgAd2={;^Sa~d6(dW(y`k#GXJl(}~| z)P82@LvVuh*5Pcfz;$ui56@o(JGJY)0;s!Re>mzR0E=B7W^+wK#eOBV4dZ_e2{7SyWS=zYLEr^6tM(`SF#O8ndU8!RH(Bs1lnrz=f2Xel(>Npo8Rz0Z z@uRP3p%8k4l9r}2mZ;8o75WOIj&!>%3wwf1`NGKuv_nmy8I;S5g44uXnjewQ-dIE$ z5os~on~x>4qBg9$LjZ=W4c`QZab;H!Y&rg9tdjJ?SI)ZeP!Wrp5Ic4Q&ffPdD zJ&a~b_mkw1#iqExf-&UnRGWA-& zM~bYiVM5eYR630NL@8GbocU(yRo?$<|K?8#-rhvoT6sMwo*JR?AfC#pIq~5`JuMy-e55;3||*SIwrS3b}6BV?Fd_TI&^K?XRz*4{Tv3{#;+n58m0+vc9ax z-3^Xfo>qteEDkI>DIVzP>dPb@_g*?YTEM05ICbW0#~lgytM1-!Xu-K^p4}4345Ji+ zHi#pnCHL3I5U6XLc5cdcy+_*(p zhpEF|u^$7!US-&#lW^2i@Kq9j3yc8wv!yw|**fqORE6IRx}nRPjX;&zCC-8O)9-8e zdqFh}^RjWl8;TVFBRbq3`6KwG;7LAkuQippD%yt`x(hQIQ9F>MaCZ74Vw!m$9tmp1 zTt1J+S-${}uts4~aAjF<1rwWLh+N}qz+ZqT53XJ-1jH{W{4Pi2b88V7)75A%E65JD za*w&{Jkx&MDH-oh1y*;=5+}UjJcPqqN9&G@i~$n<%@q>jV|OE8-WJ_Lp@9E{bi(iC z0@Z&b!vHvrC@cqa6xo|A)$cs8HO&J{;W=j+*U%RsM5uxR%tsjy65?szd z4IU%PIDjsfK%B%&gDJG*3J3(sd!@e-ec)=p z=gTR59wh2aSn~bP-mfZRgGe#_!Q=2WP4oVg&KAM+lI@EZ{HL>{&}{aewbNH;HSE8r zc<*-Zd3%WpQoM!?kdmO0|4YTbfx4Tlx_+OLHG7`p3Q+%JlCd< zr=r13v$XwUALU;Mr#$-`o>qP&SY2qkhqp258DkZDDl~;FKSonTx)4(J%ERL7cZ>X& z`h-b|K;ouz$#29>1)l7+jNOl)U1=Z$M;~kKdp%jbZ>7tPX%X95uky5WpTl#kf|kTC z!TP5gbLC%MJ{4HC-u^;=Dum*RtRoODL#ljF=P+ECr9Xvd5ew*t34eXG3o70|xqa*H zbgImEN|2%TaB_Eh!(q-;$;x%;+VNV=s>fhD+zLgAI%I&CP5g5s%_N_Ta54y!cus|J zHgb^ZO|4nX9$Ydy#|7QLR1B5mt0S8%28U`^3GxPi#_kAL4lQRPWf@nj5@ z;)--L2%9K<08=g06Pdlai5~uzQ7}zuB9U~tB--XrqK4e{6*EK+R?n6nd*$XcM(=~a zHnTIwaOmpN!)CT59JP23>U5^E{6!gVn$uLa$cgjGd>lUtImVh&Tq7Y-d@5lxi;#az z^!#wu_WP)_26?7-$h22$%!f2XV=W%T^ElrA>sG)ey6xt}0;ypwC*5CZ+erPr{qp9; z9RjeFi_zjn0Y3b!NSgSyFoc;c8gi4zeJHTg9ClbZ&K{0PMjT;gG8r1bRo1ieuOEjt z9J!w4Re7Y>s5ivvjbZMq>tzwL_DZKzZ4>=<8RoSbNpT8*g;nJTr}>6@Srb-<_YxY# z_ao`bD#f%i)9Qt&m8+VJFJz`S~u@Bw`ml=TL|oCJJQ&H zjcYte9QD(T{avim7*thrc6i`p(II2+Qk`}MCTpMohvBe+++za^De$alD3(8_Y<$W! zHA%Mj1@(|nWuNG$VM&fg@Mp72O`G$q!C6tb?|R=j5UY+=Pn!Z5CM|r)`Bn<~8)5zM&A5fOsCyYnhp8nfoM~^|WAnKOIluIeAc> z{BE4To5Qa~h&2;sT|!fiyVmVfS|EAkDJ#A8&@3Jvh5{L;mI@A-7yo2$TFsCO7p3Qm;OZ7I0P zkSuYp98{Xe=&k`YcOI5KU)v}n%#B@{Z=rVrnS#2kvT#II7W#fvy=4C5j%OwDeILB?aZ|<$2q+#?sjoh8aAuXHjD2 zWDGmU`U@+44L^$O1n0mu&l_r2eZ=F(=vy*d*-UypW+Cx+^PN_JE%9RBpjeVoW1n)(dP+IT!xyk7^OgXWqFl;q(^z8JEf*IQc2Ae3(bnFWvwxaXlIl!|!p zrNMgtPnTF2UfB2EGZ6VR@(B+3vAv2ZjP!x^=nY<>;CbQ)#1&k8BTSU#cteC>5fX!w zye3-f#xaD+F(Ym~au00CD!T~jEP7%Y907Q_W;n+a*_X?va7D>?*rLHDV%#M*K$dDi zoL-mLV~{PUd1b?cYZN;}dHqV$@+!5K)S%XNW&ob@p9m&yZruAfFKAqN=E2ZnB@yHe z9LxjCX|!VeccT-I#_#3+jo9ltN1Q%;m#SsWozt?s(6}g;ZsbGL=$cia^mbe^<0jM> z@!B*B!JbXc7k4j8Y<}$RS35DDKeQ<)!&)JPb0KbgG@<_MP>_Jglkxq(C!UOJM>kFH z$yRZ#4JT+wRGQh7c~PV%Byg7ksJ^euT z_k4YZ0H{!N{}58Q4nF8#JSZ9seuO@ppjtf>k=6C_UA0&?02ry{W9@dc7tW`Ub1Q=* zQ1cdP$6ndb^t!J6R62id9B({*wwW#AKmGJ{d*^)P7sQzNW}((!Lr6qMfK~=M3^Pxx z?4^v5{oW0OUJF-eL_?9Xt`S^l;P6X+9yY(XnrUmmP49Iv7=9JfeQ$|3kn-z89Ip}| z&tCzoF`Vfr3&R1iTv(?@u}Tl2)2(p4X!86YxdP(X*{7>Tc&Nc=D6Z_J0ZW)7Y^>D! zr#hfFYW`)-z4m}O{_m~Fo*ufkOrHh@Fe^7Unc+l%+7Ze?!es47 zKqnp+CP6w)7~K;Z;0Vx44D+;y3z19LJ;!mww2A^*C<>`HL2-Z?CwC(gc%&GedL4%! z@jWCz^7Xi)kSnq)4k0lZh!U(gN_R9v8XFSO-#TRA>Nje)JRFvdU_B(Q3elfjCy5_< zgno32>&rXPZaTZWkkT`Ti$cyoB^#po*3;lO$JpjL6pe>qZ7q>MZX6ABac~)Ug8~g{ zT`S;QH)0I^djR*DZ?-i(^Vm7^dFy$4_`nTFlH!Iq1wXL61%L*u0(jw;2(Oh%FF~Xb zB|Zw=pfF$rj6>wXIplA7V`SI>0!BsI8b}rmV2koZ`D2JI$Hey8+|b_HO0D8S2V=yO z@u~HEh|_=7&;Kc>cR_8N7{B$0*6YO%Rl3TTA;p!_0k4?+A@b5wwNKC3meq@&jf=
  • 6M7POL5;Ad-1AYzZ>cxuv!VlsA^fYE>p<(Aa@$YeF@h|4c=#&P%8w_xJMK`;BgC z|Dp5G3!nR?^jYCCPJpOaU4Ei_TLL017AR)p%1GD){Of}zAQnB{hn|7EkuXinR~ry* z*rI7hpveEpRs(#VOPQctel z{O!z&5rzuf*a6C(#;vA9db8xPBI3~ZAO_1wn*&kS+P?`5c0n)VdM8z(?}In|$O$<+&v_A}q#4CkcBb`Nym7-Rh`>!5hTj0l7%Pu~#Wy|t0R!8_H$n=%bweJ}(+C_YsACuq|XM(ew zY)YR!SG617ZRon6Qcai8bQ%xgjat__(fL|)r zA#;kHzD&ZkCdsX8F($S4)$|wIcSIm**0Vg;e-{|n7Ebr&SxB#lbS86(6lLsCZ;S!7 z6e^SzBQPQ*Dr4OJFOM+iLq-~@-vij4D}J0S4_gKm z%*;7^sLsZBopl!FQ7XQB(`v8U?Ts76c;Wn3Ef`Z4-A~@1fbyoYIsO1oXYG4fST9or z4=ZEn4uDBHVKeVX)WE)D?CREQVisQCe4}nYdMZV##-Iw8ZjOHdy{BfsEbBX0Hrx@T z%pY8L-{gS%Jo9!*_pRSee4A-)k!RKY86a(eAIE*+(A^tzro?4?&&F;WRl&&%NG5{9C#E-%9?*SP6iaD?otQ|to%y%uCVkvE zFUKiW?ug5f#@KvR?FMwvR1{VwsvqoRK7zPDB6xo$8p{Fw=rz}WYSbobp1z9X>QE8g zvRHFub0YE8TRg+^?a`I5iY;pb!HCApjt{S{@_c3m%5T*8CK(|1nH>Y7=AWLrZQnuW zMF5{h-~*es0e_c=ebr;xx?k$6MPA=aWR9Lf6b_=_r@4Y$?*2|R-CEUI-J zw`9XlJ~?u_AT|rXPSsbL(*I1x+*E;BdjbEu-X}|y2 zdJwmer4A1z0Sp3u6!))SbR+JPaQNMgRDy#yLAJuh%S?@DfIc_|T_@vS^wI3HeT>d) z*42bwF;dUrT<1`S_3L2^lVXq#;xyi9+2d}w{zVn}+}a;EnXw-Lu7&`FeYNI7SRqD?vNpM@AuT&ib+vw{n(a9} z#Dx9U{GiwRIVp3g2NX@*gRl!XQ#>E@MbI=Z&#W`H<6*6a*THavM||g7kMLf+`|0H= zWzai>Q^fFPn_ap_LYn?|DT_nY+0Tjhs0F@F*DsSRr3OZR4MeX6-2BgKWRZp6^)GNA zj>G2n68enqpHNWkN-9o^JCGEOTI?9UXD4IQc^pRziwJ0|Zy1DJ#wYvXrkomvIe2o| z|3gUKe@P2l?yRm#7^=^~I{d_R%`1F_$2){wkh^Lfd+S?cq|b?}ES5(lr%BVNa%X7QrZl80c^(tj{$CKa;srNT z_8G(1eV(jFvCLRH zXx;2)nU+z>03g<`q@*PKMA!P+JZ!H1x+|9NuO-N?;o5;^0iU+R1PoWe)&KN2RZ%gbfUIT@N{=qrY zf$uFA`FEGSf?Mt(#R&9~&I!G7)wLl5gN55QBN1b{^RFO_+~N~u-{PLcm`F2))UK0% zcG`FRIY#^mR%1z#2_{>9@vuT>={u!*)r8JhwKc|>S;w*?T0WW>TTa%c67k4>Kr&d6 zG${tr8fw4{D}1OF)$N8pKJ;yJe>}{@Aa3K*3&MyyL({*UPA$M- zit0bS!KOJKTtxfP)CC18G@3jnZqqVc3LTw)cZub=wwih+sb6Xmx2_Y(8D`kP!_Koy z?`a32T~2uO+zb-;<2@8b?S_clVc_)Y_zW9~W>&q0KRP=#|AqBw&~V$k?_B!0=?o)R zQ!*xFTmy+NMg1B4DZ>}(0uyjMVfHz8pdysFUbVWWo3EO(ZoOJuROh@qk_M;bHTP*y zQ;HPO@TjYUp_D)7NUAB4EUSfz#(INTs35ZvOi+@|t$NaO5PIpH(Csk}m%~0^lTiy+ zfIt-P?{C1VAl$5U?ZPddD1Fm!L(pm-4#p?)fKfjEq8h2g94to{jjsu2$(HZ|)yLK| z@9uOGOH6kxch`2~V~XmL%;TzsmKdYqIHQ=t3=PB=y{Zr1O)b%r8ms+fr@lXE4~+9! z1lK~ET1&im>}d1izyx1cj@r~;!hXQkANwvG+c*gQHd}Hke~hr8GX-vqTa%;zFN@LjTiL*nv?kU0pDGr z`%ys?mS5Ru62^ie2oPg8gKI2&eMna%)NJ-zu#{v}*EL{DIg5nh;hwY)bUvO$lOjKf zmrqCzRcv3uPs#2qHJDoeMard$kAYq@I7xP0C>(ccPYTSp^7{ng<@mgGn(&7gnX^N~ zerYh^H(S>&P=0<*lfx={q~9oR9W*Od~cp=WE+XAkA5;5I7}t|XvRW%)2cIV zZS9wullR*j^~1rbk+?+L6?9X1EeGch!9A zv3i(AAXYLW$@JB*GmkCxr?9hW6?qM8`XZ*ikkT%-&CPSS8noX2<=zPYRaDy;9CrbS zLav0Rl%4u8R;xnmb${ex^=QR~*oKj!xrZpF>Zd<=!`;aA$$?K8Sf!h;jE5ZXK4BvY znV;LrZ4LkQ{fAdofS|=>c^|Olmz4^{ZV{#`g34Dq|4JQZ{Kj{q2oisa{d$z*Y=Azy zQStr}Cmx5irKkfJ2b~fxcXZylA{x{lrlFf8O&|9B4G;q<{LCuQoqVY7!I`7J_au}6 ztGv*!>+8tAJs(1Q2%1oOPpnMrXPc2)=u>DSZNPo~Xv0Y}&x@~)a2CMnVFUS5V~^AO zcnH z_ze*Tx8fq)6%>kxbE68ClDFBi_8j;95$Jw;L5ds+4ejyT4qKogLXVA1x@CQHg)2Y?9XjM1>i#H1M9@s< zjtrN~2jVbX%(roA(3ZCMbp~)hxtcPhZxJ#9ZHL@Ak-mdh=|E6|*MQkr(c|0f83P0B;4O}{m+b7Q{+dN2e)SdM!)iEiQ)yy; zfH8cI>G-U>txfxhD(1#Nja&dLNP{{L3>or*Q_U}zP~|ydM5?u{HReM1vJ2=n9AK6s@+$g=FLqR-97!kKMzj-?^P|T&rMn&E4N}-C^?Jsfj=3RaA z8=ylI;V2^}ok2E+Fi8Cc^Zc)%i>((o#SG>AV6dQq>R3O0ikGOR2?5Xn&-y~+CM;5t z_=@7w`I`@o`wo9TfPYh(#ZV<6Bv&n)#ciTFb_+j+NO$8HrNC@Vg1LISzGBZH(tM%B z+);ah4eawX8Q9Oo$?V~2>?~3YrlzD>Akxe1X{0tS;xYJ^O5xh<6jtJQ*j;DJc`1$$ z+uLdQK?cmLBzJCp!N@E9Krd5;P5Hl2H0fOEBOtPL{JRo>RgOctu9~*_G+#%Q0t{@x za8fyP6WR)Rd#k^dgh`;;;-f=Mso?(+P)UaL8@oGi@2{w3dw@|f)>mUZA%lNUe`&4^>cH}qIb!`C1s@t z6-LBvqyR!NADKkD9dC*my|UiKEZtaW=I^<*_JtL}3o zh0ASL!AmjN*T? z65>0pdN!ud_Zaz9XC5#PU^SCmp%3sksL4+rp-fZfnba{DrZ}rrgRPC1%ggpbM(!zq z!zjEC(6MH*rChrDI*DEXbO#tIcs@C@bzm1``3@8`#YprtqRKJwlsPx$q%ZKS$tpQF zMNr@5W=5#xwO!S)C)Dz;=;0^e{rTx5e=aO&c^J#&{|@2`dN6_|C6=iqZMGI?XiLh%`D_b z2Vt5MJSG`pk#ByS4(|eUkjD2^|AAX!`??<$yMs+fLBHD@(s8WBAxJ_u+l=`f8JI;S z?!Y8+4P1|Q?V&2oJ$*`t6CFPGbV>JpoN9Q&F731lQc4%hvKUOtdqta7n`H20t(Z# zN>^KvaoihKJRL+V0*8pNa6@~zK@;zdAGt$2D9koAYqlPj2DEtV@L&YEdEdrX+X07k zhKJn=gz+W-j2w8Q3H2=014r2D3pBaoix~NI7sJ!jyn<)Wan(~KuTmoXCR8LI%2iEB zy5Y-2MX(1yMcjv4{f?ZEOqZKB|!ivX|!!m4h)n=|nq$Odo4RxdZf0XuIPQ;~&3!9d8f3BDCO}J|ddqi3w6&{Jejl+EJ(;YX^GN)srfL{|8fC=gr7 z9&rDN&e6xxe0_2~_{5?T;meg+$A(TT}rj3AELinL+e$}c?Q-0SNbWQ9Js0$mz zJlA}Ebm8RPMIZ)p)texB8-?R#3^1K*Cq-S}n5nCpJ8MT-j3!-MUG?98$90nslV6KYh%&)_q`3k$L;UzEwjUtq9{4Bd2Bf?mA@LC z<4eT0_6`{7M*DIJD{Ptjdkzai>vCZ9N586Ma(x^*mB6;IZ~uhBVCx-(Z2iFb93uSI z%J`%F_qJ17Fj=EO%_$R~?2#ya=YWo{`VBdGn@93l5XDX~^T0V=QMh|QNTRm3T@0B{ zsPR~<&yjSFqGtqAo|im!US=3u5SV6>Oa*W$fX`}qppbsWXD*%`e^>M~uUD9=&2E2u zbF*wHP5FDiXBm%^taM1-kq1&0TF}sMVQ4`Mv6ICiA(w>Y%AkcD)bbU_^DXN;_rj`Y zC%Abo-^Z5KaIbrMmhO*;jLFBq{XhO>&rA|%wyHkXF6?!@%SadddP34)4OEJ?fjDJD z0j>V!FjOb^>zXd?GU#(AF?x&H`*!0ox@@1Lm!Mw7&DWROnz|BbNJV-MFrDXxodK-~ z%PSOu+`Zxq7&v16v{fI5KER_v7XN|OM&J~{O z>LaOZ`V#XYj16IZ-bBT}>#NP_+&#An_{2wI1d@k;bhW(;G-n0-+UMnm^rVCG53yw< zln{2*M~>%c(q$Eptc-1Zt%+woHyumbq9$qf;NW%=$}ewL}G^ z(41DStm#>8R!X_p5|w3xyr;)TgXF-%gud8wVL;%{$Z~D~h9!+S)539`wOg5<>hWj- z0A7IV>vfp6+EWpA$x83wO!EY`WIkP2>o6lwLyu2lzPXjeC-0|0_mwsVO?pnzjG^6z zbtX#aq8|H*Vz5!uQT?84D-3UP=)|Qr2D7L<5a#9La1YGO{}?ZEzHgJ#ZeA90eIy0Q zmL^OH#=&3IhG;iJdbAIiF8FzCC+=pu?wX?;^n|@pv)b1)(WLx>mlDoT#5fC$u=v*f zFtkJ#r2wS8MB_3FVtDkk9vk_&y3A-uivIf$$Gs-#;|COwjE#EtC^nhNTHl1M4yGNR z6(d!AF{A-a>cod`sI${HN$zO&k7a%JcN-Zw4~dqi?IL&(Er<@~y!xy5{_X7@|E%G* z#z^y(jg<3mcrV_@D*`saYfX@e#=E9lIi0&=JJ;^7G~ip1$pEiUEk$qQBuVaQ(zp|+ zf^vB|HctcHu1v{hRB{bZm-@WHQ&HIB9DuvR(Cy!xaA3H8C5r#qSN=UQPY84-Ku#Us zmJINa=s`!<9E<3cc3-P_g+$P)*iD6?-*x+&ZEdEGCk?_A0yUg-($g&oPkU@8y+H)} zPUcA+Z3>)gr*vR1d+W&Egr1t#&X?Pta)OpNI_jeEkMj3V?L~ zPA2GEmDMEyz0@)RMs^As-hbQ=|LK}BH!Lq~?jyFle@3@pu;1`xC*TvCf_~CL|3epk zM|t;`JA>cqztjfz8PZmt6_0IPUtJ94wEq07_b|a{(4%E5;NQgj?(gj{>guK2R%Nl( z$<^2~)#8P4nLU9rvf(KnInZ)yQ#9!kuZy-gqeqx_Es1-ayJg*a@8^L z)yD)jAv%$$DUvwn73*-HL~}@Mc*YzMcYqqLw%uOf9L9tQAiri*BIh%;#ZA_l?;)Pt z-=2%t@6QAS``$cVa!LQ8Yqrc(O5Y zUHw*fe@Kr@9?|Bo-hkM2D-3yPh1DxgRA8sR4bx7nOU`IuwfBtSG7?WE%f%<3i;-PH zM)2Vm7R4eJXT5trrFhZ9w7ch?VEGeFz8v;4`cDS)rb5iuxfis8Xj16NGc#GMug~_~ ze|>Chd|V~vF+Y1~IJ-%R%Bci7EcN)2v2@6uS(0AR0@Oa_83vxAt}*gt6d?BIXi|M< z!IVfAG>2DJ^)P14Bp)3beCRT=>n2~bDRjrW9!jy$&NDL^3-5b z)l||o!BcvpG*3u(w~E~Wa`)LMZ6(3n_;7F(5e{hC+Pi#lxGI-|qe?#p7-WOxSR z{K(D4U?+Z3j?O8zy)G8Y4;mvwe@oduRKb=pQn8?(1c^%dmm@iVvkQ7CZEmBHBH9-a zO{r)UQpud~hxc{*j>zZ}VSW4URFP$o%Zfb@XNnvkoJQdTN$9BsC(bg86^2jAAhi}H zHm;$MO&+1vpxgV(bcr|pX8>qGkV?EA2vAJ3TF;E zK~ktSCtmU3UC|L@KHHcZH_sBdNV<0Sp((d z7#0Kmu59(5{_bs9RID~|?lcjzF>gKNWUyr-nEj@=QBMYjp@QH_JN>w-|BmE3O3}td zB|0DqSg>OXe|=qi1+$)qB&9sRB5@m<2g5!DLvw~iEZn;rB^e(tFqsvXqwLM=mrpbv z3w)uMcTjMhE1K&Wy~6cDM70+O+7udwg+V`MeZM`=Xcq{uj>Wu%UxUepJ*|nO8-(hy zhw8V}7J?9WM{frZwvN;yCp*3vqMZixV0k#tDy%V<7&~0#jIoJS;N{R=tfpKm3yfO3L7>($qkU zoCveiw^@qg`ZA%G=SqHg4)+k(v#MC4GUo>%y)`|{$?7q;iz+wQ2c zVY(?fU=&K%2-fLwfb&3RK*$m%MfvLOh;p>+CC8bOB9{1O`X_ZUCvEr(Ue+OB0w;c$ zsdeO;kpyt#_nXy`lo|(wf@GRa+MZ7HOQ-OW6UA=<93WPAq2^Fc=&2FtV1>2Iw5k$4 z3If!wZy(#r|3zVHDi6_MTD@_mU^ey2bYbTUJBk)B@*L4@^`$7f(Zah}r_o){Bp`TQ z=jMI6k!mhQzK$6E2YOB@*3`L4=yI0o1Glvf@9Q?_zR-!exu(oa)6JcIM7q`ja~v4- zS#HRBM{!lOE3;F#Ld-`!DRxFBKCm!Y&BDK}Lexer`H;9eZoR0A!U!t+anjQd%;p&B zsB33NB}2}c^|3(J)zkng{Wmwv?^lP3*Kr&2@k?t7wu7>Z6wtcLA-L#gY?#`r`N9=y zWdXf6P9$@8wLVuVP6`Q~aQiWTLa+QZG0ju@M((tsEF^lKFfig$j2;e|yu5&c)7+3s z#K4z??GG0-ZcO`f^RhFRi+=v3PX;oE+9cG+hJXEKHF9CPo6B)U@V0jjR>Z7`IpP17 zNj_4AT%j@u$hyn|?7{k_G6+n&)ab97QKb!#B)Di_y)a!lk`lWr>q4_%ssID8q^!2m zJ?5x&*j*of#V|!7H|;2Y-cjenzB!7Px>#I5zYRYR;2s95+Z!nNkrs0guD+ZXeDdYa zh}u{Po=g#{wWk%0(-@)EqbtK3|-~-u*;P;lDqmG%W z3^%P=N9pgkf~e|u(xiMH(#pz;2UQJ3tS-fsOmr-Y1U3T&mf#w%Or%1^gU6@;fEgU5b1_0lQ>xjfucB>DNJ#(j%2J!$KeM6`wFc5{q@9|+g z8wx__`(FR#JlQ&(@neXpxc%ee4tbPVj*tK{HRB%4zE+WxNk7zteM7D{0 zW%@`Iqw1ieY>ijNNO$JK!KMAOmQ{O^;#jRf%O5RPpNR#wm`#)~NYl|cP(!55y|;Wm zjEKe&TjqQ?QOEB`0kC?Ya{`^e3|=`5SUtQ*pL+seEp8A{fOM#zTr)=eWx^A}cR`3x z{}w47+)+|10T>FNED1P@o1PNWUe5C$bs+$NApw-R1hA+dIUhV8U+vv|@29hWV$Hw4 zNdQZY0G*+f9tKBlzVeCfPW-l$9r!)s!HdA*#lW`2f&%`L#`{N{e^x+1p%19EWSO4h zv-Oz{x9L#^@zQTWQX7)31+b%=+uL*W>k#*aZ*KC8bwEb}_?)%+6kvxgyg`BF!Tez$ zvQ~ejY#;n!XYZ~hJOghemw*p!+W(Iv;Hk*1)!=w zFr{A#gK~8K6*~A-9H1HhL&652tlI(Z_L0E{`G5;_;tIEIPrjYuFCO5h6FcF-uPj9^ zC^l}pc(UIms;=UCYCy|$0q(0XU6L^;vbYs2djq<30zN5xoqkOKEo@^ z{z-`5`qGW4R@4knBKFn1P{Yz3`3eu+>tKgnh!}voe2l#KUGl*{6>B%g<+dxvtT^$` zikEwM9`J~*pQ|if%X(YJ-4&;T0{$oh9g2^4UaQp{l21>;nE4h~CdGW;r|}&`W@!*m zznnx};tcF(dM5z#wi{;vdeA+v2S1g67TzRhgm+=!M=t=0`^cBUk%R}2U0~J`28|hA z4iKfaPku3I1T;mx{er|rL5##s?Tm>nw}uHhZ1zSO|1Gt^d?QN8tgAXj;%h6nf)@=; zgI+R9z^sdGEtQ=&M56=Qh=PD#XueBJ5xJK@1@r=5g%Najo@6oQfHi>;R{Q%G9U(8K z^)HfU41R{Jt{lN@mu^nlk^4J=Iq)glVq-zq5~YbnYp>VS3I6?jR<$=gJFADk`XX(o zpM(?9T&*1FsGAQywCDtY^ST189A`J~OvFkf5Na$_qc8fZV86(_Zdqd^@#yDJhiBxc zj|%TFo85UUs*&Z;RegI3(5d{NQV%!DLEo8;!Cgh~98StqG%3qTmf^kwJxXE-Ni9L6 z@mdwCefJ@#C$n}&?qQfR8j~|*L$qn+vXY?h;1GSp6cWdXYsIb3ciVVdBpy{$zz!!D za%hzxl^2^Cm#3*N@xH6&7259_c`5P|I5W6$B+Xw^H5mA!8T(>(A)MMDb{iKPdu1@~ zqe9+wqSf=$u_KXuw$6-cHO=q7r6JX%M9&RE1--90Ro%+^WWBGNFrHj$rh5L1Uzou^ z#cqIjb*YTzhOfT*-Abp5Pxn*-xo(b}lZExn(lH1pi%ervrpB#@`=k;5v2FNb zUI8murm(QzC7&l1p?``Vx&KR9(z2bgrBB5ZY_0H>iGp^2g7rcx7q@(bC2)dBG?sT0%z7m=J?HK<;O+vm)lqD}$D&l$f@bV4b zx}W_9HeKzHZYzeUw!=$jTrSZ97e^DQ=-oMy@%YLkwYa#^uq(hptfk(YZHs{;ysp6p z*wfM4-&5#%t3eB9u``YhA+zYv{9_W1>c3B~ z=l$eLQ|$7QVTdiw!Zgd1K|V&MaAfwtL_uk$iOt{)y$?-!p}cJ{sUoZpXU^B@>d$A6&Ff zJsTf{R=Zl`M(I*=HLDJtpzk}x z#qRcE`#_NRu#2U|*$9JcF_CqHdve1;>1fa<6Ic8;z2HFTHzpR&nnTSlilZ3ux%G0& zw|{`>zVk_VIo?P>)K*+yT`!GK4zTXNfyC6jWGa|KA-k5FRxBlMdrF2iFRbS|uhieC zfXyFgIinrMZ2Q`?*9xAekkBF-fEr)a!<2EDiwPA9P+Lsits6IQMQDZ9uT2hTGA*5u z%z4^nn2`#Un~{9etdKF;(v28+teW>N+v~>)gI`B3r>yYVN(CCX)P{t7F#%~fwo|)k!L#G(KWwmZ0~!`F zuY%lp8!Pra(|~zBr1h8WJ&xfruYAuaJY+_BEIjyy`3O`*oz<`on@PP~0B%jo2oV}H zK7|$PBCtZgloKPik&f*Ra z4@^4(7Zb^XEC-2yiHMbNx{ZP5lOERBK6@m?n$1bl&m-+6u31LK>gSdr>pQbC*tG;H zucM>fY)Q#ZE@6r=yCnMyjOPde;kTG&-W%8i8{n5v8vuUuyc>ZWXrF{SysBMe%nnse zL<{D)UA{Z}@OJi7Eo+TDaH#SE2lfpbIwV?#=OplbQRyR#1O#P0Kv1rsNF*0WDdl;a z_N@d48C+wZwIkRIv29QSB!twHzD%;LODe4~-Ks|J$ok91PhaYhjeMv;aZz|xh_yW- zRb8(6VN~sl%$Br1^M%|7l$qX-Fm<-QDHDp4-BiED>#3 z_SmxKSk4nFJsq(h+|BTFc}(~3%yR>2PR{y5rDlo^Q(4$5w%T`}*v@d8k;oyvE*wNm z%i!_1x^aC_KJt=#F@-tiv4Np#lF;e=x&6MG1sN@TB~rag`iTvyWIQrzXzI*Pw=(GufTfNgX#FI4%Vs<| z&MShD_Buye*EPiTwV%_v=g^^b*kv3RiPuOy7nZ^lKg30|5`in@go`81CF2B8#~=!m zW%(a6i>5{hJ$tmNjg@f)RmV}D92TMzC3gx6QC!wSMfm!EX$8Qlc9dg*$sX5x`TV4q zw@eg9{PI>Gv)y%C20_UvL+=knAo}?YD%3HNGf~0VB)lL#PV`ld?Qm(SFC&!+s-`1Wz0#sui<&h0|!*px)EC`_8(?D#n zLH+?4rDP!uEkCg0zdZY(y@HwD#L6R~MQ->(Tv6uJHiLfW80s*O&nRo2x{niK^$M<+ ze-Z{Hg5RyKE!-VQ$Q1aTS|!r+$iYNIC@9A0ThNB~W(UGSI3oxy8-wK3OI4x7PY}o; zttj=h3<}dI1AVUiZuUcZnh`F8OVHoet^}h3W#GVY#iDDeWgTM99cBs zO3cGLPlM#hTRu{DgfQ75NfbHx;bQ9&v&5+Ny>W6xTK&j0C}zhkJbb_}M_NNKxyaeK zf4SXMp)PyDD)q;i)km!JxpBnnvq=$-K>y3Z;5q3$vSrA#}@BmGU{ z=l%^J_gUFq8P?yDgOmzD?~yqF_LRHm!LWrR6BGTCj^i6HcHd!SPzJa>-eeT~5UanG zSfzN8#%nA^RnEk*?-0eI#W5$BobPAsmoGMPYb_mJv*N%jjaMEGE>cd_Dy{UVFRep- z{J#eDSGNPjjhHPRG;p+@Xt`XmT+21{hCIS>-y8DnM5Y$3RY`GPPyxvFBX}H6Tua?7 zhkff$ugG4uoe|wmRc>nL{ZjhhpeX{GJX=M!x|;!J|C(CeK?<@#EDLagecQwM8}}ca zluNU#vPf$1EOHNkS4GjoSxR~XC^Y{Q=mOSLK$;44+&W3W4T0=c2>wT^a(Cwf{J8#s z*$>9G+cgG!HUa5(=Rkf{;UBP|zeVoyqq~*1=PyfP&J2?HKqWaHvyV zuG13FL#}bGp1J476nM$#&FBAIWh^8`es=k)GQ}hGzWMpuqkCP(KBJf#7u7^#vB#i5 zH$uZG+F;=VD0B=t&0%#YG=s9HS`Rtu8JZEy0%JjadSYPMnH_vs zKn_aAN2jMNmPfDA2`QsPXHSvgsW-x>u3RhDhwka|{GE;1{~AysnV?c-UO!jT>nvpf zjxdsG9(LkKDtT+vZmRz#%?@m7c_1CVQBehQ0)DIR5g74>Z#?KLJP(FI-Pc|z(l!56 zpvK3z%h4-qFDU$>F`%QCc-q-Mhn)8v@eTSJ0zmzTz)c@ZS&H_6JRHz6t#5i-pBn66 zZtmoukN8Vys=Yw+Z)7Pvh&l+p{*IVb38%PVYWw}L*LfbIz6yctrHgcrv`lqSyh$}G z(MvaGw5L>Ho{mD7ZNAuy*JS`XMabmenIWboNnk+Z%bnu z$o|Uk{EiyXe6Z=^5=NXiI&18uO>w}a*Ep*+doS)6;MmO@T!?rthOpa5yG#{z)TCQE zo)S7*Jt621gl#av#$oR+6=C2{Ye|=R@8E#NkaNQ$0fURNkB}IL!l`7ydz`ba6?V-S zT$vks^3#`i)udH@GFFkb^ z((Son!Cv@1L;U>yh;Ty?O`>^;dDziAq^-0j)i2@BuSq|o&`WX({ZVcFtHp_66_P{g z9fAJA_n!e-pyR8(?K#No>r-U6Is%?&ottnLxPNRo{1MMP$0a?c&hX{>tecBX7(`fv z%-Y;^>CZ?$t$LHv+=%#^e!Igz!fOs#M(6lNPgX9XhEY1M~AkH3IGi31) zboHGMy9*L5wJFb|e&+T3j9iwr1FMHrSYfbim#)7A!QReS^55U zv|kY{BxB-(i_8Ux$o9R|GB`A%GL?x`Ph89CaHpND{Yf5<9rfvvnU6a#)AnJ|nY%j$ zVd!^XE+lLgtGftV7ZxhGjPaaFC8ZqgYEKGox$xVCFvDo2s zLUQX%*Nxh9QU|UrI(G+S3nkX+O>_fELex z7<<(AMow)C~400piSU-oHkYv{?V|- zwOPNjfwXNP=5_U6hw%3tsJJ?|Os72#U2}Evy=k8yO6}b+RWtfMs z3I1c|^H1;aSvklfn1hC03GV;O5akD-jQ_S@#j@hWKy9Mz9~{@exrF;p1_R{g`|XA? zP~i11t~i0zJ&<4k(Hx}5R=Ydbx?eH(G3939d?QB`E-_4%8~%|K<6Df1V*+!OZ#rxG*a7SE?BQ$A#MzWuZDt=j=r6Cu7a*v8iX#1z}A=exe}-}-?a`UL3d1lPB6J{zAUwSS~&-?P)3Nywcs z-QDd8jPDx@*+2H)pIykd>+p6~Y-^wGe9dSDn8~|GfQ81No9&;gc;fR> zg1DRJ#n^+#pSzCC*C`LlX6 z*@uk}2`Q+bzkO+DNp%V1REu^_wsfkivGyH&l;bmD&qE#|lwUaFShw8uXe9SpSk{Q2 z-)OIx@WN4M{En^vZO2jq$|`{mXjx2q^JW;E(fQpws9cv0#^Q`w0a9M$yWUS(jvO2s zf?r|-5XAOW5e(vY;M)f-nB&X4PsAt8@w$k=o@Ji~t&8Gi3-1D%vhAO{4ESUG@b~e& zpNFLD)zIC%*;E|-cJ!RiVKAZ(;58RHtwvYo27Z6PEIL#=N^odsXl&Q`e*e6$>rjHL zZu`-s2)D7E87>0ER&IZyDmU?IBwEx2!= z0iR&|{YDEj6Z;5+;g!hh5VrV~6e*nY>C;Z#ocF z4UiQU5fNF4pt|<6HId~HpXX}pDCk{4@b=O#cST%NvoAq8-QKV04sdmdGCzN&C7hU9Y#(;-e-2F}4-Vxm*reKRw)%fF9K9@O#y(ybF1pt|E+DRO<<#@^8JkM*mUn}>jjhYk5F z4tCm&)P{?Ti-T9K#&1uejtka_hv2HK(@LLfXQqh*{^J~`GCDd`c-R0}6Zm&X6a)^3 z(>bO)udfad>+!H%TbJMLLk!lRnIFFfZ#z{~RM<_sR=yE2$|)$Yv$K!K@q?vpNleX*c3zqQpiOZZ|;yyub@x~nFkV_Jq-M@*#r36!3M0v)_oow%{@Ee~CCt4!mID>mU)9l41ttkrv3^09%5 zHeZiy;~j7PcdS+@B>CgV2fM8nevH3|e#c0L=G`_l1O$WcfuvVmFpEBr8UuJz)QQ@c4>YoB zPl8Fl=X(`~nu5Yq3-6P|Fy?6V?XB-4Ah=2sNAyFId#^9q58X9Vr{pi z_(YaqT#IK(Yk&>+9@G>6);(^!tH%+#P!t4-uC)O!z$n*7Dr@_1Tff}NFlemMN3_op zqauQqSC&_0n7^gLoX46KVFMQ6PP!;eULM}a6EF&d%!mTknFUBKRzVl(C5>-RP$3h_yPt||xROJ*0 zJ^@d1%YQVc&n=_`%f9~vA$EXqR7YhZT=YlqD z*#@~b1FHCtX5WwF#`xA_9j0^imnO;cmpY(4-K#R71+%PrlQ%41NE}nj7*ePnmyU=_V0wQNKx7713raC@bPk41{NTp!?6?5|vH9+UB^=zz7Aa=+mP^B}s2^yT# z)|BAXJmtN9e~PeCu^Wb4PkVn88%17_>S(9yf`Ow*6HB}@ogF78^l=ymBUubQz!>#< zwEXz-<3RH)-*zq%Or0MPVJv5NICvyM13TZ9H{+ZQ!$D;ecpN0Et|R#WqEDnKTJ9Mm zJmj3`u>7;YL6VHa%wpM;-ZE;qlE|R)K`_7OR(fF73vn$x!TY z=o)z;5L6Cmu(0cH6cf{+tIe$>FO+3xy{g*i4J4_Qg8%YX#VOdu<%^ynS&R8WyLS7a zNv2KMS#KTIsDW4+u64U%DZ9n|?gWBpvtK0OT{c&r! zE3zu99l6#t*jZv+Irckm5)EP{PT&0Zwa^`bR<Kg*}*>V4-OB?xqCi zs=-01PK!29DlaS7WD&)viVlrf7demn`B}Uw5XTxi4*~5-N=Y=j=4Zcq$0`9sL!?~7 zBK$bodhj@DCf`z9zQfFV1QIjssasWff{Y^v1`7>QRqJLD55AH9@r6}qwz*JmIsSaQ zd5%CQJxurmuS|*hta92n5LqaUyiIC5kX&_?u-ihkzL`T2_eE_j%iCv7;&$3YLPnVH zBwUyc=DTotS+Vze!37#cQL1XKgA*pMk0OdGb6llFoY;>OUKQ4KC6RSL^u6lh%DmZ& z+l43Nc?;5c?hx}Jov~?L7ns*;W^n5As-Kpa#-=Hg5RL{8%yE6#zRvG;ukr^7`|B<( zcDlz@b=NtXnHTq+h()aTM&cMa6hZev$h{h*0*lci}<1lhP z4>l5v(BhdZk<>L`RL5awU=jsyM!*Yk`h06&S^oOXT0{ZyUpAws>taLDmSjGgq>1L% zP<7k6`>|jVx;mETVq3zYItuA*LyLNLx59}w42Prq1$1aQJRFH@es#c=ksD*I>t6KJ z$AkffMITfZ7q0<&P7~wfa!T?;hvi{1~Dx^|p z@Z~4yjYC>7@s%w9mVLc_;Cfd@KFZ0AW5HK*%zS7(-^+mPf~Q_a%B~AK}<55 z+dEJO`vYhDJ~9%JWy>@$k#Ujz6D$~Fbu5uCC>aGp2G?ZbpWp6I0Dn_sRGN*bAV$ zQup|{Ve?rmE&fLFo`=9t5SGIAsT>4pgRKasa25jOl9LAxlzU90Q zy$cGvwkY#-MNm8}(iASMcKKxCyN&q&BO5GTSG18n*)ipDu_dTmz}caPq7XR}?Kq;m zkxPkAee8>(8rRfcAIn`KDG1Ux@rP*kj?d&^$VA#*BkKZBuf_QkoLb5lJe%|**8WJ# zC-s}m+4Q5vlj5c82?v~RpOLHV^zEs?%gOuVIoliFpcbZz2iTZ8Y0v6_W%}sl8C&vs z2%x2hU4j0+gWRXM< z*ugcKXk1A2azmW@BNm2%1CKC`Mt-gPS}~5D=Tp>OacN;rV+?eok=maXm8Pnkr3*!S znO#z;mh{@zBD2d{6&bWiV}?PmDu+`Jv0V=1JSTGd)mh zOtWZ_jC=;R6_<|-LtUjaQV^)=3p7NiNuAfi>P>Y-I1RHzYFoYIXkVmJ|xz^7) zDOb$=N+tszUv5)3kmcCr?=UUlV$re2Z7KZhW#B4~^Q-<&%vT89ogr%%pA!vnnO4r|#%;=W)R((yC7sj=XPb$~yvg1nmj6|%oF^c!sJBJfm zr;R5A*;?}vvCL$(Plkv|a$86zd?&|aGLFx+#)s4jey+{x8nc>xbho+n)Z!y+vuV%E z>JF@Rxmt%x40F8^dHvH~`eZYCy)bXb){g}qD>NNHkjhe1Z^&FnQQe-bTaf?hB zwBcq;Z~!^qt5C1^wuSMXkMYR>-z-npp0(w0-RGudiSC0o4Tp}x@@jHkd92Sw*}ZY8bIgk*>Nr%)*B-fjh*oib*f58azLr1zT+-1OXJV zeMskO1vxoZfJxo494>jz+NZXS)av{o!SLPLz||Izi`VNGVu+p_k8sHjL+ zQ4kOi5RekUl_DU$gpPuA2+|=m6-9b4(v>RR&|89t^d>d55ClRCgiZ+cJJH>J-S_={ z`Ae@W{HPHC>nU!gfXC?Vgn6uXg4+6$bh2 ztbK&BVg=Cx=$A{uhN+H58NpBrs5{csHjcF!9%%I+S4x8`U;|IFyC!ft+=>oe%w8X z*Wn8I+O%jY#?(enQki&T4Ho7>*a_$=K8Sj5{}J(F*S6RN z>zOEKmxk1w(On#`w@dR14Vbf>(HSJzFhMY)a}#b#=!s&XCNIyuDOn*+XVm)DY+vLQ zLHW&h$0ee4*G+T#ZZMT!@7y*&2rKrqq$fe}ob^Qwm=YXMA(8V$6 za=sdLHyHmKp9RPyNPj2vrL}$c*hENx<``x*c*>i`lSbXQX|>j#f*QH(Zx{Z} zE_D{Up8O^!2AOXyO1&H;Ahi9uunaOIcq}-o_78CyGg^}q8&0W@Q%D4D5t9TtyB+T7{ZM6cNsv999{I-uP+$~4Y%abYpJ<12UpMoLOJEvU z7+BtKO+8nJwOI-g5?3oZn4roR2;}kn5te*l73hYG(KWyMd$2N)4!Tk+$4S)fXJ6Sp zi&_maPj#OOx5W<@@YL$-tW0KRkBw5R z)H90dO)g9rlpQ+cxZ`>&SPB~`&9=2Q-`cEzq-X%s~bTIohv>cWFJ}6y`sU{sy0|Y&vE)|wtB6c<4etE z#~IX!uMenl?C-w@E#aOiXXZ;w+3fCfmdPW1Rd+1D86}H!Ue&X6qN-r?w#AI>jaY9s zHcIUDN$jit^vl`G%y}O^e3&Giajr--s{5R6Ju5n!ebsR1N1*b857E+mHlUNug?kSN zV1~pxA*bl_p(n;@ylyg&^bBX0;z3B3*!GoBc}FZs-Ot~vUC71OE#!8~d2N+I$-tZR zl?Jua#yJX6$kaYul`zbfanaD||D*#5+J&=5+f#@5!|D8jBXlpF2l;z^oAD|5VEmrvR#qyuZ?KdzJg@#Bw)dS4nILk-0rsW(~3bV~qqU|@+% zk6pF~!r48!+SY;X?|0f;i<|ue53Liy2JLl*GIG_prb1p!WH6%QJ!g|$l~TlTyVyh7 zoFX3sfr3+^PT{cCo8Ve1AjmGP3mr5o3CH{iUL=XusdK>j?cKS+WFlY2Azij`{<3_A zFv{BCA$>Zl2-L@G^eUsUg=h!`wP6!5WMwI5P{*wA;_y%P4@x;#acV?;cCt9t(^KcY z3>wT8o2o1dIAQc;Guk8KL%_J}w+dc4thkR3<~8w-5(!IuX)-xXvpX@=0ZWM*8{1}z zCO&@=XFq*Z{4Bu~GHMcov=&^Z#lf?kDlC}M6o~WEwZ7D!c`UC(zKOKxA_ zN1;D3$w%t-aCa?`kBdbI1uG?_a_lsf+eAKh1$uIp%{KXkAkWsbeKhFeT_rqC#RDL) zLi9OwstikZ$o=qP;$)xC=U=FIsN8dtl=Id=6kD~?aE0+L_8z?j9^%HXd<5bAb_1o+_E(zzi@OzvTUhb6me+@ybq8o?v;mR%puwkdXCbd{Ba>$z zgS}EC;vq$#E^||fgy4!Gj40# zNM)s0fd^#Z3(Lx!!PGr^A()MYML3#GIfd*(_!UI3f05*iCG_B}%8+0fh7qZB-hl{Y z_7X`7v)dFoxTm;K$2p2fZ;T3%Q#lP|n_>r7=#6|@qo(ZT%{IX$2m_4w#FtjU+mhLY z4BK&^I>R=(X);Ba>FX2}NBffkdh@<+Rl=n$2UKqCsEswq@wDhbyJ{J0<8FA-WG~gH ztJgv$m#kxZ8athj8!|@o?QWNIi4@z>XLL}gquS=GC+JkhF^IMrn!-ktI0?-v*FFzi zuj>Wut_lrZ0AedpyI zgcT9>N#5!Fu}vY)ZHsFPB;e>z5l4{C^%b^cvyU`KW&hD7w>%>)yTbekT6G>(vDd!y zQ!FP%rFzbcOnfMAa%H}qx9A&X!IOsbk{zp=z`8*X-DaPCSE8MLcE&V#Q8)ud8CoFp z;)q~?lZU%~U~VR{I^Xt1-SMWLQzHCc9udazSo)M0I%^G6hK6m?LS_Cu-(@cP zFPbVUE66&-m3295IvR1u`FEV$MeYay2nrz{xUy`ef}K`?0XR7F7CnHQl^FH`#T~lL z6}7cKhs%dva;;Pl#vQ}H>~82(Vv3hbc6MTau4c`~;wK*O)$U}ysek1(bI`TTb=EU> zlMtT;z)Yd0Tq>1iEI_?FCiqiQNNia(nE)=j!AcpZ#@-x~&oGy7diWO!eJ`DkZZx{A>O1S44@8 zO6<<6_eOvep{|Vi)M@p>MimvT?^<>G3jqhIm0w*UW1KJACz}@3J@Ab2fMPQ$pSr@~l-M zzT{~vM2K*3qKpn;|^7D9Sc2&ebn0BV(U%J z`#sD$Y!3~`XT^zCRgQ-}eK(?Y%dF6ks33^vtxaGw+U6!2o3F)Y)_suej8}U64$$WF z*%A;q)~jUWTmx|MY#$|NgMKC`e;Gm!8Zs}i-|XYL&@ADNZ=}K2)By|_35YRra(y}~ zU`?pP%WjDr{EzG)c9LT*$%8P+JVo{Y2!rN9vI!Jy1c7{2&^u;tu}1i6BUiD%dH9z| z7`+g|Z4u#49N(1y&YKoc;R6FA&q_ezs#+kl1B6Pp4Sq|nSfa>TZUDPCko~4DFZ1*Z z^StWglm?1tCbvw*q+=;7uNSmRIqnTv*M#l%eo)_<*pfEJmRD6^wN<|t3Mbm~@?6+y zM?IM{h9!Cw;NjsQ7Ns8aihk&`i*VO6vD zni5=wr?3t|cxXEic$~yRk7kX;_6&z-vr4MQ7E}Dmj9RBO!{wcThoVf&j+Zyw zgJbdGGIf;3zBLt{;|}R{c$Mw0Mw#cHc!Rdnob8VyHmA2Lrn2ajoW{%1of~ZQsh!_s9?Yjp9Yd+3zq;O$h7* zlgxuC6{KJ{Vo-xk;e8IC<<;iY^A`*nV4-GAcY`uM@Oi^z6}sLZJo*UR#SgSI0-vfG zNDOR^dt@J#WhGaCodd;f(xzVVXeW~^$P;$)b7$V<;8Cgsg`O@o1jWGH7X`A=APnaj z!@)&wl`iFub7^-BrogH>+E^DiC z-_Wg{@#Jds;dUM$n*RI40x18vB3E zkFRz=>VD0K@nE7e-O?Dd3n8XIw{iT!*1vwWMsP?VforZ)4X5{AcyZ9M(zSWy1W_;> zrMc7L1gFD!6Qx(S9G zNQs8bhp9|4b)>ObaUsW8Y4=1sKEJn)SZ%!jMEXALqKINl(o z@%Q?nPnW^eWGolE&d>4$P$Kb9^@n!dGdQqDSGjaI$d$5q(2QBmu>JCGg(5;{fv7~T zXy{kx;W60p1og*IrUSxzX$f`@%VfH5Jb!8tB|9 z^Ki|BvubesECspaIK8mo!seMSpRh};5N4bV`B|;-v$*Jr#_0xHVW^J#{Xyj?;e4$- z#ecE|9Mz;PY@{X~*&^!#s>d0wf$DJK+VXn3%-kKAdD0?A1pqXW?BbO03FRJ$sZMKUz4b%rLZiokQKZnK9k@J1fs}_kqnf5W{6SjcTc>&HwkqJ3aPl z&eDjJI{NUbyFEN`gW_$8!xgq5nxeqCx{oKI|EfY#_02r^!K`KE*mf6VE z7dWZg*yeT&!1<6zil~Cqy0{a z{XWOA!+qCX!=QszATmVAl)5kCC*UGCiTjcE6 zsHo^BpCl~Y(XeYTICam8f1|lq*7fh|;3G$R$;GUortE}2`Bw1XpX)y#3o_OtqoXVl z{)Q)7C>^@m<5O3ojBNc5w0GwIQ;aD&^4#%YhSP|220YaZv@!no4;2gh@Oy0804jb5 zj4ZxD1-|t6NAmA7|JC2`*MXY>KVM!^Pmi8NKTRh*i|gp#ZY>ggDqOw9c$UCq>ymae5_dZ+_ZX(GbHCx#T(I328IcQ?n`%8nhZB{~(F>HVjB zx8~%i3mq$jD^P{zYL_MlES znnyw}&wL|T;E7$_@m{$ucj0wkr33HGe-7;>MTg_F&#ut1{LD!GfpdhL*2=g^*jiB5 z4@34RD3qa`z1^b=l}8aKmkB)!0Zs+N+Z%tfX3Y0dpFn3(es=uz?$+OBHn3}`n5 zyqNzg_MuLmxgR8xV^}ZcnVfPfs$^1VzDhO3nTi4S3Y3&OT>M)PsvKwaFCG*1;Ky@e zF4=X0;XF1hv$aX2@u)g%PUm-K1!l}?u(~7b`eFAA<@9(old!cWLA(Mks)O3{t}BLR zC0Qp7T7$SOL!Sk}-tR$+ls?_)=djVDNuRgLMQGTlSf^Fb<;+wH-YNeU7h8Kp^o|v6 zjgj3|Avf3WY=Uou%Mlb;t)stH94#FVN^~L5|6Q8cl6~x0*3s)1F@2AE;7Fb1&$D>Zcst=8_ z;wqZmMVp@XAyTm(mkK1(*K$VjZ;JMD2l+kEk5#t>IE<;?goMy*6Am+nCBrP?RB?{s-*v?B!2 z1DMH_xkW$orzX`NC)16Q1r+MyBJAD*j4lQ3@0VDUCmFw8u4psPZ_`$ts4sc!+U*39 zF6d<#W*FV=yfErs77u^oSmV5`txWW5W*pW2@_-Khnn|jF?WwgsCxVGpU^0iQ9J01+ z6)wbT9&RD*wz&Z%%3N*HT9KR;zx;C@tvr1 zM~>WkDNt1;t4lNINpm8d`t9n=tLT0UJL@!I!)S8>-odo3J1Kb{g}3z;=<)ld^8@As z&&{vh-qL1s)V7u*-j+9Ka4cDZ&G1!2!8x~Vyv#|kegJJBIuaznIlpzRpgrmNxinc- zE{_YY?U+v5dMg?F`q?)gtD(s5!jMqfmpk|QXI)2e~uOwLW+qJ}b%;ZZ% zC->Kd%!HZXx%fHSYMz>D3=4Wj7|)w66ISeT+^k)|FI=aI0qs)R^u30r_B0cM*SXzG zQsYqpHzDV$*Aiy@(-+6C#YKiQG$wudT|H&nmF3L?#YVDWK_fRxOhZ%t6vCHP<=G3h z+)PeyXK(7Yx{~{GkkQSez>nXrYVFfRh=0MbeiK7S0u%iMm*Q_)PszV>mwf=89N0AJQ%q-2IY+6^I{Gkpb7e~Pkw&j*pcUP)secE-f~M_P5TwXBalDb zbzp`g-*o4*+mk)6%T2n`+IHRfmtC6Ib?p^-D;goFqALb13D3^Yk6PX?e}l-c_qrVX zP;5$6VRw*PtkBrGoV&Sc@IqhLzoh)-vnkl?cQtXP9Y-(Wm#rJizcchhbi*ryc4&QX(?Mrw6IqQ} z^ooqzNqTU^<(ha-KGu`#wg^P2N01j6GRgeSOMw%1QchyaV{>k=6sm;&{07%48f$LA z^afSQu9T&&>~iHYH03S>!IMv!&!aCaFUwBZuHSb2OPuiqx$c8hiz zBX#hS*%KkHG(D?OySpYgM19ixgsN$+8`Jq7%q-bQVh&kFn$dhP_Xf%rM~+B>@n#@c z$w;XaMvr*UJ7ni7^5d8bvE!F*ck;|g27`6Bwk)yCj*85Pw3(K`i-SouvCQ+erKHiF zw9Qks@%m5w4TQukX06p4q zdqZj$J{DKUz~;%aN3)ogFTABT&OL*BxL#I5QRpn(Af-dSs8~8DJos9MEqgwmpqt8D zBox&AP2$+A^(0=gbb8T+coRV{y@`~kOkBh}1aFykjAA8R*D<|c!^o#mzr?x@vY(t~ z#}NP2=Gg`7i|Cxig=IPwXJ^NP&dK3p-J%mZU*|xrj3qp4l=`(xD{@||eO%lZ0`0yh zvr=%qypzD&skw_b+bWqCsM;2BcWoZJMsy)n=fn=Qwj=oyhE=IDgzh~}yl;{`IQeSo z1fjO%!{NQg6TG_YF8o4YG3+l9tAXHb?ZzOl1gn==SR znx|PmGF~6U-`5>nh$KYUB-W@OF?u)Dn`0X@fK?zm@=UHMZG|zEvI&}7cNz+sTp)_& zWeT-F>kN@7Hzq)xsu7nkYL1>Jw2-CIF{xBxoHeU4n`;_vQp&X57r~p1iRp zq>-RN_WoXMK0a|H=k^gBJ*m&Z?*jLKMakZ%hkuA>J`Fl<95jO7i#+k-^-N=y2ig** z{Y7RZFW5H7+S9|(iNYkbY_mz`fg*OL>6l6U_+8k_U6_L{ax(ab&fT{d)glAE>$Z-b zj$Q=Sv9oksu0lULN@lj9Hg~NYmU9Mrkw7;Uu@CG|xCBw!+k8xn5a@CTKDQKD6qXyY?y z2YA)VUVdc#rN+60r{;gSjO*O%dBz9Mtwc~jqye0qt3+pJ=c`(9a31M@9EZK(uk_#w z{qpt?)~4YLuFB~+!{n0E3R4$H*E19N3wk1D1$^k4ABMMNuJW?#A*c78dh#eo9thM6 zmGaiZ=f`2h>+*YurMOqjY(!lXmfa>k_?Ebj2?F-UMAqyl(%txZizKarM4z{q6w(;; z6>(IE$~M%wghfCkbSe}*glofUzoJK5fJ&3Qj@p6pt{}8Ja^%$8L$!p)>g%)BW7(CW z&AL6Dj)TS&={m1@&L-gPsR#?pDOaY(U(ZR-SVPd?d}+gP~W`%{iuCR3gULHN&MMOE*}$TXhgjBM3eCwm|8dXF9iJ9c>n|%!$0E-GSo1V z*!z^3xjC8XUniI&`a^8P&+5R6Zq8yl{U6QqiQeZWD=? zjceu1W|PjWn@)=3m#A;WO8kPz8*H>>{OM@q;iwHA3eIx_*xnQ=SX84EM@oA}PmHO0 zaFGFf*W(xw2U(9yvp;(_&%D&6dE6%Y=Q(VKWb`;C-@0@lF^tfzEn+Pk-hanV&1iz1I)kF=yXj&NBUDUN! zMW@7bD^$EPDjjH3Lj)(erO10%#(9|-s<94s#dDMl(+W8^G z(@mX&I#0tDI&90}c*3i9UmKB1jykui`H0>LdHhCsS~dbQoQ<#7U&{0uW?zMB50dnm3n4E#G4dj z>Hb5P*kLiqH^beVTo)=GbiV2jp_}6^LMA%O>AMp2t;^`Tc8xdriLCO8 z&eflA#^}Q*h(@k)aYPm0P*DeEP!}ThUODGr{jk13>-@UxaciRxM+h1dTmeg0x4TMo zWd0*PRk#6JS;h)}B{u^~RW8fg($3>i-jqPUw7?{-+f*GAyTEE!g=8!wa+m*@5q^fa z+MAREPr#JN_Vf2|2e`8K)C*|cHijf=R*GsnWe?4L9Xh6N^K6~*o}ZJJg-zvZ@1#{$ zu|iW%0N>!XQqs&|qCw~Usuttt@-H8c3f6O0Cn19oqlGL_%YtzRT#k)|kg&kbdtFsu zmYnU2`pj%Kp4jj@-ZP=KF7|kY37XRi#CXbnD-oo@Hqk5Wp5TM;=x&MYY&`FF!N&_8 zmRG{RY0W1Po(QthJ<^FXQOvtS-(rzjsa^={5on5abPT%*piHG^wdr!yZ9}%Ge5uYC zw${PC!h+>CLA#0d3z?M%44-3PEJyY9xsD|V%nTuDQ;J?d!Xfn~Opc6A+?!xZsN#UH zc1LZnJVu)U-|@ADcpqF|1%yO+-p@k>e23CLe!e8&=Bcet%SFA3W4COA<&)}8R~{-p z9kyql4Hdl{lSPgt_MWr(jQoaHjyME3C-Y6vS^M30=XpR3buM$hzS#dor1E3SR|C3F zf9~9SPAkljVuvuKAsGOL#uTxHMklp*j;&2$o!l=$Yq-{hUMfurOt&FIgU zPV#jf8Ooz@dC?I5w&wl|9dpFnDcf-V?`|&i@P>oSY+@z(>P6<*Z>LeTaPjxDu|9Zh zBFY}403!YC?|#w}Y8}`lvCSXxC9`R-UUp*J5=qq&RBjmf-Dv*Cw#jRXoSN%gS32bq z>UtiMR@yv|6&&fzNG40Sb(uhPXD|bcvRwx`3Aa6 zwlv;XLQCvfX$`N`#Vp}PIJ9k3X&%_3$s4MOz) zJc#@*zdn+O*L|qDy|f>J1{uF%u5*$y^I@4`2e(+rOxs_d?-DK8Hww&yzglzv@whK2 zm;&k=C|e*$r>D_?N!gc^=?2&7=Lnb2(UQA^{r#8wU}kaU#xqKC+deWm2|7h6Iy#n| z|Kmv2^Os3`zmDiJJ>mcJMqpm}Enrrge;xbFMVB?Th6KMg_JOE1qGB|MFhV6kldFaW za}h&c(f-@t9tK=?IJkMm@YiI#;sE*4=s|Axjk%;fFY0EE5GIu4``YoIT4b(iMSozm zsnwvfUJ=r)eL$_Z|19{m>z%)^8SF(sL|v;r*kbT``rQ(5r7oAyJ90Z$Bg1UE@FIsT zi+aBzEVL9oXF5r*E+7&E1K%UxHU8&h0NE~SJZ7^~%=$QGDt@3p|mP^;ms% zm4vpb67j)Gxg*kGIx+i4a-!nsoWjDTs#zLb&qoc+3xeMQ?C)=f@@=mZ+$aZ4@3k;T zir+e}<-J1@m2)%`$&|5AWQ5>fOa37IT^E@K8*VXR(He-Gm$PK$y8fL>K8-sa3qn2Q7H@{#!QA9TQEcFsj(pB|+CKAtnk+cWv-i zef+&VU%5c2d1UAKFUgOz0ay2;K(o2eZxZXOzztQ_C+{VXog99%rx-eQ@Us`6gO+AH zfn`acI>HkCq_XG(fnLU*CGQHb{MLZC)xcT5-1uF{Pl5YXI36F;5W+<2MYtm9K?g?O zfJYv2_#WHTIkgqsi4{_{x-RvCj|p|Lc#Bsv-CESjSyZpZyLHq+w?--#$V&?7R1yx_ zg#2sKu$ravB5)^rb8{2a{_@VBOl7mNUh&Cb=^07r6@z z)I2>=wS)ZNrGc*fc9e{y#DmZY27RZKBzm&(_)GX(_+qj-{FWKCz@NbyY!#+vEKg=H z_$^Im`T<>Vy>C}!HOx5w?37GwOeQ$n%#?|E@Kzrm@i%FN#QHFTV;V_I7%rBBk01F! zpiVbzuL5l+gnbDqyeD<@OcOJw)$f5foDCIUn;9>)eXNW%2Alo@3`dUp+wg(%Bh~Iy zH4?o&=t@cttNd7AuGOssu7#1sS{S4Vz*52mfcBij3g>?^+iL2gFJ9zkeU`KIDTbwQ za3E_`m5oQ>Nlr?1o!unRQ$}?G-SZz3xFP8K(Rn&%t=AV)D;&OL>VO6AJ-Pi_-NE<= zQ0Z#k>(bRM#jeE>3;L0mID;DJ=1#B^PGP7Vt6|J#1b0+R;Piubj{X~(x0{U^HH9;f zmFzu03f8t-xAJ<(Vos~dS3%PN5+`r`f8S^?(8wr3x7H1jLh}u7)z27oUiT1TbZpw9 zR$arWGlh_F(>Qs_l=0OnLrG8>1;TRNS!C&hbU5a3X?sq+`6PN{=M#>*lmXp+%k;L(6cJ&m`H8}{&dB)_`TW0zX zX&nRiMXtK*5MPQ?PZ@Q+f9?c0Nk__Ow%Sg9B$4`?Ex^VV58&G4G_~&`mOW=h$@b$~ zEqFO#siFN`oCOAv;1Cr@{Vor5Xwd{i;*?6XZDk7>-Uv|Q94ix4n9lY=w(9tL%H<5dOo4vo(Ahs`2ES}Z|zcO(@lqLJ9s7Ca|$qZ zb^%>?u(@%0%zJm~=VF8VJ5R$f_KpXrfZJ?WV+Xl;ivn`#f4FfsaV~689o;)TfJV?| zm*0nJp-Y%W?mu#ok6B-di>Q%#yxx=UnBlvauvo)%{Mt0wh9{yAG`kkQbQjCb$TKT% ze^_?qr0t)6|A0zKP3UtEfA162>!f8)l1ro=2MLr}!hLJQ)-oYObssdoJnrJ$#NDl7 z^*PcSjW0Lk6y>bRKX@8>l-rTTMP9~Ro>};O%6+w>Rz3FFaytDMONmT)Wd7Iq$e~w* zR>RjYKqgv1SDt^|SHSmmA$C8zH$14xvz3)uLq$i|xyNy7^YONL7L^(b=UrZ|CT#ndrT&ONUx6$8VGoPFN2uA%PVp59(ncn6-S2t}SgSYF{zsnN1 z5$$=fo~q32$pU|0htLkXVGQesCRBH@h=-N0-YbM?Wy zdLc76){UQScu)9iZkjImaieXKS_bI5z~#PG%INPr`n=H5hytn2w@|zfcJ6sSc;gpW zlhhzNvNU%`t4E%n9qe8MOnHPjFelC;?|t9j-o4{d zooVklc}!WY*r?dGn&RBKwTIz-dR>mB%bz0ADOAPsTrJtoPX;VV58N)90fY4XBI$n4 z^MJit%h3y@=W>T`t_MRv>^v8oSvXs05_Zn7n(Iva^1S=gtkpg?JzC&dT)ooxDK??2 z-0sb|=PDFsDUo4R=BI#gUH@IU0H8729YL#6Vg134+xu7E+Q)8g1eSy=^onmaVeDn8 z-boAI^og?6DmDY1El#fs4es0TFqNGq=L%lFngD7O7}ibHhfyi$K@$&in1R>;D4;2H zNyI(pVYw|Zp=%{=l?I)_0+tPf8XU!o`=Uia6irV}+j%X>S8YTL2s7@yvWd*s5PErV zo0)fon0fFrTU-lm{5;Z>@#LMS2Zc*vg~m!^6rwi!TwGfv5?c zkQinZmM^X=o?64CU3%kCin|UR)~%SVq?5&Ao`OOt;~&UCZXXPb`wt=p;0rV=+sy0V zUK2WCAAB>>5i~rI7(DNBq?rzrK)YWQazrTAFlN4*WSGK(AJj>uv#?|v0BM5OJd{J=I1+Glx^&E1^q z?+ZH0=|g=Mqs^pk-ejba#oAW#fuBD%)PA#qt!7>5DDAx@P-+gz72wf< zp?l0*#TUM0FE;vuF7hrb01*z}k0x&* z8X!?oM1Y>_*xi!zrCRuLRs95MfWxmiw@)8cb1?qsI2r>&7*a-yFuy=n1fyzi|X z)1T*Lm_bZ)t;+h%Ucc>i+vz7!%B5uVvBC43G58rM{S#MqiKl!4%^pKUKbZuIrnCL* z)VN<%kY@{w(jih?Z9{GHEQyASv)dOWt9BKYw2iW zbrn!##8l5+WOJG7$K_UlN5t4y>m}f%WpVQJ%XJwX>fAQD+Zn6TFqTtsW{y#Tk#6HV zS&#eDWoH4hase3$|CT0f^^_UrF;z^h>N_PAcB4Nj0qu|a=31;hyGq2JJp{Y8 zh3LA9nI)xXkm?aj?Lh;~%vOblrm)AjK@|saq6jh%Aj-A({ zPByHIHh4Jee!!wnvs`Nn^O-f-hRh0~d3Uex?tA;+e4_75JlF!KQXO%0I!fGg_8y5^ zcm)h+Rr5{it{_zEK+05ZL1bh1Di;ATGaAamDV zI}a7%r~V^Kf`yI^n@Rsz@oCmou=VV}DSrUquRyOu5zp-xl;IvHT3U;KR&E5Bl1VGc zLqLZt`S2;6cytfL)v2g1o9*zC=rEu+3ymx9;Iinb+XvFjTENfGR?5SJ`keDMDvTHZ z)z4vmO3bA3?l6ZlC>zbTj2FW6-7w6l4Xr)J`PvcqP4(KSlPB`QIV}9)4nRBL5%4*% z#^zab`)!$g%R4?Ba}1bM$`k1uH(Oz^rpC5dn6GVR!KER{+tKuoK_KC*0Bpfr4DdXBEx^uKhaB8wt_B+R zZka(a%c>L%d$JhkF4~U|%W#jVR}c?a;7^bcIQ%P{dTlq0Jy7_)P`3- z=%qtFYcIbJ76g6@=D~t>06HJV!%4D=DH;ZH)I$8x%!c1s?1(7xA|3QoX2^)Mueqzn z6d19B19$q}(N5dF{05LfUV9u5I(tGCOFB;`$a=HO(_O|=5FluD9v#H=ju~o2uIe#L zZPoSh*;T`a3Y}!08}F`70y~+kcW-?%5#P7-H2;1?=Xu;vY?Ag++-O>hocBXJu7lA{9QQa!Gbr^AD((>=Wz5M~8g!li4x3Cuj zQ#xL50IFiCYJ3dS;|(-)=47+skV+w&sYYLa4-mWO1|Eh6@bWoS7y+4SI=*o>k>kYf zCKP`l;wApoOU?|?ertowmPM+a;M7UGtXtf#S!ToTqE zIsC+AQ4kyUvN~Jou(Fr7N`F&pcg>g-8&#z5d@gy{##y7#$yi7UXg{*=;Z+-h4S#CM z=qXD@i360?*4uNO*y?KDl{ag+_>w;)EP(y;{$I)X#m{B50+9u%BN19wqnA*y%bjl^ z{sP9~IKQOGwVu_^s-yh=%vA5%k&A5x4AYDZfZT;`-$I4Fs}Aso4S_%!oZ(y*OFOVg zUXXAfmIL%kGQcP=2wFFB!F~Ar?hjd^?-xB@ z2VvK^Tb}iYY`a>~o~m95ZOvZm=s3+$$Y#VSC-E`)9T6OEw|j7e=Na*8;?+&v_pUQ4 z=2N99VhoCy^YUFoz|(AGY)?-|uR62LwcpcEy`K`vgJ{>ZYkjC*QLSqE)$y#E;gCiT zUUsAvogUn0sCCosm1k;;-u2Et;@JBS)A;-2=uq!8>~zg@_00?lx$|*J&c!Un^$urR zfcNI}vWDE83wBD1HYt#o&=J*pb~dd}-ZJ+%ho`~J&X%p4mNx6FW2 z2?EBz-6Rn(%o<%XoiVT(_Kd4gUPkvDx9LB~sM|AOx|JkaW*99B2A6EI2?c4P+P&e; z0G>PuyAnmS=9i0}PlqMnWSb_Hwd0aB!i0*`-0~EPoZ!lroP+Y4_C~uqlCCo**`1@6 zLP=hdY6FI@?R|>dn{$)F*V!@{ZVGFe#pcQO>%6WUfygXkp3u zEH4{P{TyWet^E5R<<}oXWM$mk#YRw8ZqL9m<&RXg7FiEn_ND3`I#}}#UmSjl54Gqq zcP``MiA6hHT3|Ywl62HzC9^|0KH>e~<%pdR_GcM@5eF%Se^N4JnruGZh(d= znC$q5y+@OLx0~hBc)~5S$xY#2!@eM!H?ry(a<;WF^PKWRLHD!M@3XzXO(Q*kKXO;b zHG;VR61MphP4(jLV9Tt5Jce2tBO=|^w7vz=)nJvB$BZ}01-1|y-csU#bBckzA|08} zLCGXt)TkiD&XhXN!Y_KW}@DI56O3Tr3z;mBZs_AMG%&XblUjFtOa2*Q|11S{FAAr4^&V~`+)MkUc2tC02Fyb)q zSkqC2u?m@FX}FVFPh);>3E|oY6a&R9`*xZ)7uX?pT~N>aAJXkR;D_Ft(cJg_g0Ww z)uWAk_Q4!uXZn^ie>nJ61+*AoECv>HMP1Bh-n{axc$x1CaHe|>iucfEQ|b!) z=7THoz2zH-b?dlPaF|&NIUeD2HzISyG*^Gcme<|~#B%KFXgKKR?h-yFg+Ga~9fX|t z$Q6=kN&}){BJKuH8Dp8;a(gePhu|aC5B8wHAtQ-eMtsJhtA!1DSaKa$D*4Z9_%6Nm zEPT`T9!&4u(YvYgZ0F)W>>R#)1gN65{t${s;*o2-!8B6q76~FE7~+#^7`|*(EfJV> z(A1mEcgP9O+JO{F9WX}UU4P7w|6P8XnlEwqJZ*9hj87Qfo6z38 z$L@SnuGMMa*@t9|vN2})JxzBx-nn^4ux<1D78h28YiQFImNi(jf}z|ie$FaL7);0}e^ zT!_&va_?d?Pe^Jv5_ehD4!p>~0;VZisXZA0)9NJ1rn~YGq)0wKa0l(eu~MX*(S3)v zRF=KT2PdPSYh{Q!0BYdqkF9gXlx8C`@`6ti_z>i*X6{ZgP=MUoCxB-K2yX*8KlqOg zl^cm&4ITrJT&A-AR%&+7+~kLYULvTg@2`X&}AR-bK z0YMQY*dR3Es30JqL_vZ9L}HUe6B@Hf5+z7h$vFu~Y!%4@k|i{a>RR;{(Fwk<23U{}up)kC#IEcJ%|(dfPu|EyZ%#f+qj@`94OF67>h zwTLcjD?uT$*ms5eNUXHM0=iMcV+`f-^;YK$5ph+`ze&)4uE8EfBoR^ z>jYD08;~l#9YPw2FzNDpvp7%&q@bPkhXW|AO|x-o6d7i5`>|(C7V#-5%~`G$q;-O4 zJ5;(x$xuf?JgUB2huI4?neY8&7@%`Upkypl z+bPvtqf=rTmbbf(oVX>GM>BP;xPfsvUZ+jiPFQ*9QY>;xFt^Vt0%-wyLK0GLN^XT~ z!_}nka4k9v{>JGY6vER@wYzZz+#N8N0L!9H;Zfgnj~Xv2I^PZ_rvIc7MdUDe)OB#@ z&df0E1IizaRgG0s230>j(a-^oDa2@7-zQCv@~2@m7|S?R7%NK#;THFPyhdk`znB#} zfAL!g0kO<3N?-U&2t>0q&=We=dLT_eObCOrAj%mF)gGp+$UIZ@e5<;{7(llCb12vW z`Z$BOYXZca9Af;B^f-l)nqOW$E3B6jT?911T)_TJTKY8|4v3 ztCLlvx6=&xzss71l&+O2HC!HS^By`l-4c5H5ORCjx}M2io&wrFB9QNkkd@z|eIqxy z@7v$R^b$0m&0c_y!{>MA0mR7~yKy=8szYC_`K9Gw)5CK#z z$i02Px32)nMEZIzc_S&O!~H5K4$0*TWDA@hF;b^(8sPsGw4i*><*vPdy*#=bV$pcK zP6E^Ld)ACNXxG=KUapivSrEMM(NZV*a+=iQus|H3`3 zzxW?@LegHhUi1mt&4$Ka{mgF)qE&>wWunD)t;Xwm01MH(Nd{4XT<xpC8m#)YZ| z-^5uRKfAnEZ@7XOy9|;pJ>O3Ze{}p3a)kk^FZo+gIiktk7M870@nsEIHFTz5SP2rXIA~#qZ|eR9`Z_<={JO%EsJL zTzC`i2$9UPUea;bAmtbgj}v?bp9qjA+UT>cYEH;O;B8+ z1tEx@EfOCi1f-v>vzEuI1dxNXkMH$gsqXy4R6bg6hb_n!z$*vC))G$Zz>P!EK6kL# z*_b`FB5%6BD0k>t_|%IrJaS~6%9TkrQDJ;3o~-q=JwU4DGk8w&T&4N884EbnfWE07 zEG?8((?&=qI5_}S@cf7^93{B&f2FpkpB3d0M zT}QKXpO{eNTDKTkyaXXipg_O9l^@)F4xeQ|uD!-9GA)Q6Ff9%HFpI_|#zk>hg_LPG zY^XN-AN{rqiN&WRr2vue@v$lxm1fKK>DrYy&9A^A2JXVn;iEz>)LoS%bjC;fO7I>; z>@|LZ&Flh-5ehR-ZjVA>wThs$_o)h~lSD!x+Z?HwYJ4OD+9EmH4DgqYzVJ^2E&QOUc^>|9rUL2kwAM?79h|y_EJ#8+M$N5~7 zt!8ws+d)gmK~$=;5L)zA~i^-q9{J}qxI~@)OGex$5R_^gMb*;FA_jCNTlQ;j zhZM3=QC1v+l_BQ$4nRBtox=94E9dSuK)cs8{DFsLx~<@<1j5A`F*W zZLgNvlqDoztB&6;Tf162MEA5kza2tJlJyKaBB}HtfWiKIcF{#LMc3Gkc+TUuHL%?OMvjjG#F(i&Ui0-_t7msWDy=zm!^ib~sefV2e4#b@rZk7sdx zU%5tk)TZACC5a!HRB!Dwcq#P*weKc`WU2nKY}UsjjJG;& zByq>6f>={`gxCtT-sfFq$LWpkD-EqfvyaSWp9f<(xwusznEFU{BlHGYZ+uw)&ps>{ zeB)+s_L*^Q7Z=J@c!|7e5G0Ny*aT`q&We{l7~TB?<^JV=xF*f)hJL&+P!%w!K<*53 zH_Ha<0^%3=3T(v_;lmhOTrA`UW`vD7iB$q_?xG9;3I7Bu@JR>ftO_*0^@7X-A?hm~ zZ}o?Pg{Ll`RwL7XRB}&1_-?!1W`_B*=!Cw$xdPkhJkhkzyF22N`*W8xH`_@*?>Ce3 z)06a7Zxic*XpT2&mYhvGB;oB&j@@I<5jI29FGx*|uFzfcBGRtXShcy1fOv!~VEEP|_Y`jC?;apfQ1iJRbQ24x1}{55THn7YO;n zimmC}*j*9&3@bpq3Q$lLSgZN&M45i`$404LP7$0s^mcE!%m_9IuA$U zCDhM>0BM?|gMqN)loHo2X)Iv}6!zXw9lC8gKd*P`X?$Q>ODc#VLjej805Lsk)l6US zOymy;$fIp2fw#KDUcv*Uh$_|izpdbOQ)X=5WozedLw&vtUeo{3Odx;71`jG9=cax2 zMjyrqfHB(`xt?3#r+W6-Lg!Rjy_4f4lvn!&4njddh2_q#*N5HEq#9G3rhAr68AFfC zRFI+)qj(y?cX-!${PkzTUfP3@RFF*wz)s9}3nVVZyX7vznNT-w!(G!5QWOy3ef)bERJA;1SGl~nKuPmd7x9H z(7YMT?ew8saba7Bj}Q{a;MIXKZG3}bch*hCjdnf?&aWpZ>6r*zIuAygq*X=m7YGG$ z*a6J|6ufgpJ7YdeO^2Z_xZA2s+ukB1!!Y>w!AScbyV$1NIkOoy<%H6gSI3cC8&Nxh zz^?~XsOZKH;7glV>j$bz-&}QLy`{0dVp;vQH>oqz#Vj&)cmy=q}Q3-y^HEkbO zY&mFw1%)2}pGQDH;>;W*#US!KL5UcU}VyMZ`HC%x&Iy*!VTyV&|Si5NIC$ zL*W%WO(G2w%V+=FHcoO}u5~+|ZSn>g6rwD+K4Ii`I@k>+4v<_L97h1PK>?Fb%WnAl z1Uwl8rGDIy6NnguyX4*`?KAwG$?NF@kh6Iw@3ue^AlHl6#Ph(DgHo>Rl=uOV?dq8n z-4pn8sy0~g%ic#^GqPTjSDkC%6-0Jv!d&K=APl3#Uu)G7g-R~ZnTE+f-ZO%wMdbOh zJkxI=J`AzKuDJRSpCfddN`UK9)>)PR$G5&-{YIC-5`(h^JUAD?Qeamj(+tb0zCh&; z&%f$m0L-)3EUe;;wsJPW`AEL}NyLFb`|f$|_pl%84%g7j1M7^0KUzvuLtby+%Ux+G z>5vM|B$qEEW!(l{A7qq|#RE4ba6-;P z!@+V`VbeQ?EIFfjDrZu}W?FEvLfochi(WRsF>I*Itm{Ye-C&=MEvSz`8^-+ADGLBV zYrY->jt;L=b|p+?IoAEC!{l3g76+>jlbxeh%^TlzAWy#ujqVO$=lYY7E7)HI5b_2I z`#~vrx0UX^z#%%yT2T$mkOe|_f=Owe!&1>~&RhY@5#oz>OXS{PF$!lKY8uF3GWi@M zcyWuDC&|R;wi+04u(JVe0=`vDi4pjj2mky7_872zksHb|T)ML7ohFbj+28rDH^0TN zKylSxEe}DyD`)Op@CigoJ{uR>Y%`-Ps1QTS7jN&Mbp)#Y*g@30id@6NUq$&3 z-Qrju!~mVLPvD>JGg}(ENlv_7Z%`;+Zcb}yZN-v`i_+863k!AXcKe0rf>}no{r4wI zc<@pfWBWh`oCW}Lb}!<&!2GXTGLrKiByVsv+1SC;gV5g>ftC&doeuQmRY-*lBpnij zgh#TfT3^DQ8o?zL23rkq7mgRjE?=zB5yT+wuwS*GfIr%BnevAi1jXq0&`crtuj&k1 z1cYTQD@gB1@HiUaw8$6Vap@UyUnA;jH^dKc+`)D^bkt8y8k0WI&=Cr&G@%B8c;4(% zwD=4hrpzP6oXT$ya==ejZ~hhi`7=kP6|3kD)Wg2f`aJWussK&9CtTNLFbf}3PM5Ui z|8SV8JLq&8Sm4b6Hkr?_@&phL!TkP$U(cA3`%cZ!qhcyugECI6T!v_t1IbxO&b6Im zwh4P6TAqFTL%L5}y~v9^|03-;mJQz>bNL#$2B(>g)1YO+7+jA~E{O%5h0?h>f5;C} z#Y-I%zXsG^HK2+sRmfZrR%A(Gy~&XlKCB`b6J;HvU3IAi+AAPWt3uKRWgDz|AeEbF zILH>9X$CFeD^Rdd-Vo}b08C`MN`UGS&XCenyy`v|aEM6RJ}3j4^1F^CYM=e)u2?78 zwveF_k>GmrC^HIcEgQ2t5Z`*AEtDV6QFw^8RhxN10&81--^aLE32eZ>+m#N+^E3!= z@b&p?!*M`hBeo{U%20IK0*eAP+Okw$OtNTg;V|-25MJf^2e|e|=p$YL$>uD0F*5!k z+k+HVhg0U)mR4=^;;0%p3_x9C&2L+}$JtXWJ193EOx$(o!q;d8!bB@n$wME=Jctzlnx zlDVqFjn0*vsbBKc|GLi$8_Q{V_p@5vVa7$DU918P=t_o*f#Anok5H>Xw1L$QVP%&i zn3!guRm;$;4fOm*i zWAXXmun+X7<$-L*Yl2v^s=ic6?Fu>3(tmAO0AvLln&Sb{V&Gj7p${OoL4x2r9dlP$ z1*~$`K<)R(nc%9l!c_%d?CZxj`I|l4_xFoE(k)wy)7=>So4ZS8cLy}TS13Nx@x*HA z&!F9=Wpbi74Cw1>OLsjuYx7Jm_fBZm@x4vpj%fq!7*cfpA-fnMYXIp;#R5vyE50U{ z?W$+y$CM~4O$7*S4D<42BzVvTXOQpDbK>a=_mr|O`iOf; z%5C`u63__PsZOZOpT4G$72)qT*m^cd1Svj4kWT;yI1Xk!y{bm+dKSST$6uS@u54$@ zjDN)V5CAS1a^G6?6@qILv@&SGsL)@5Zm;^?`kr4a?OII598Vjsal z0EcKqgn}M1YQZD`RQhBHl6rw~aZpQD%PsR`0BU*O?4&RRD6n4T`_aRO>x2#~s6-A= zo&$uY-FQ6$G-Bk4OG-**-3ieXZO{_}a?1ksnf(Yu^0 zIXlYwBdw;;yEKR}edhl8adPd~2`3Hl3)LY}MxTVx(+n4nfclsMemq-;J6ghJzmj!RnOko>}H>gJ!S-%^komN&K+KJkCe```; ztRp?S3Nw%P?%uU2Z@z>0K^ewsKq2_BqYn1KzOzt++c&ekVF0v@s91dYa5JIyz>%v7 z4}1vL<8A8Ts64v+fG$*lK;#r97AFJLheM@qG0?(-hJ5twnl0<=>=>)8@9Jq#92}!h zxZzMxuj*=Gpw1)dZ(@1FVXdAPb@coHvYa8V^qnJ0g*LURz37~!>fL?JobAXcpeCCME{&;8#B+OlC z_T24LHF5IABw$%~8(8j*_FiVKYNVP0ZWkD8bDaNszgk!^fLxV5ZPTcP;x~^Omu{Yg z^6&q6fA;chyKL`-V{08De88+iQ4H~e37D=G5W!D^e+gW9_Ib)jg`T*ww=UUrqBAFc26>(c#X#2vCbjnSv;mc}~N?va<*2ZjvKn_YuP{`VMhvt`Vw#DA9x3l|8Jj z&qI%pz5IMM)GCRc${z5H5HFxDPUERH;O3ZNig4zMfSHGgKfjO#RE@_PM+UJVIq5sE!o0km2EMNt&+alEK`qBsiV*=9TgoSa-ICB>8giyBq z&Pt`QFPmX$_$w1_rS=_-XgZAAr;^Z*mAo+BwUAEJaEZdT zt?1Fl<>4@v0SP-xQ@@U}FYfyfgM;Co93%1^6*NFDo3GFUI)d%O>K^3?AlECjKrGAs z9tuWD>jZFJ*|Bzo-Zd;I(n0@UuASi$?x>1p#|?3y!if;ilZ+M#8P=l4)gRwF1q*0^ z@V51*O+eVUZvKyJ+V6ZPbtlSNqd(#0hZ2&7o8=g{cih}b*cyFrLC67Zh8K@`y+DWK z30xJK0r~)fw;`v=^fx;I1j+_+pgeIm(xm|vwCEN1&fsRz9|lnnHjWGKxSc*~M=5jD z%C5`j_Yo=mbjjxs&V$$>qioByy;HJ0Ajogp{-hRrg5$y&I5jltw&jQ_h3kkSdFWdg?|j3a&+%t7GzFbWZUOb@ z0(}PbKYU;HE^N7%blGeFXHi<`ah&aF_K2B}NeYp0JmYLecDUq6({i8O@mAbwcfIO| z-%aAbnHXfUL8!danbluDZBX(wnZpCJpGNosAY#Dco$oyc&CV1sLBTisl7L+#+~6mE z_!4;Y^OZM$X0UrI<;Op}TWav(u0sBW3$(56QM9dl!e}k+=({T84ve?wVX?NM4q7zZ zeIkzio^tS;AznXaw$VlRJ5$e5mva|^3mcV#pO?;oHig&|q6mI~bUpe(c5dH3x8E2C z7Gw_}zE`oX!bSOW+1Q=gXl+{o8QSsf#yY*Cw2STYuWL~+EpX_Q?JZPwztACN5$W!s zgx^PNlNDQ^0Z<|0H&FqHrJ1yr1eNvrw_z{PNyR0B=mO>Ul?8&${ekTfR|Am7=n5$# zkYRVmSuVC}S zRx-*STYAC$B$w%5UHN}Z-xVwnT&X7I`jD@GtUp!3UNs3|P&34YE)AUdjp%V_VN;+2h#wOzrVS6^C_vjSyrjwtj-U2zj z#E_qkWw@dwfr86uo~|LDAHM@0lrxK+HomLp-ZM$(SSnGdYtNZhQkoJKH|A3e<-v`e zt&OUdE91GyJo(OPeTV%d^x$b7XJo%9Axt6K{rfRMyhzqBi;GN+zoh}4A0X!<3e1~F zkfN@GjKhR_bpumPVrTrl7ePrDGHHq*g*$Qjs{-Vpr!ockVbj4?2US+dw+VG zzR*L)#E1duxVXgd9Eh04^*yQSx)GgLiJ~j82uQ`I0`&S3w#Z4RcK_ATtFfayQ3hLu z-pk+>+n6=6Z=ZcJmj$Z)<=`B~gzg12>GZu2n^eNzpAJV{2B^LquwuX~!?~Qi0^a#C ziNZzsxYHf=3}6~C_`H{?%5VxYo0f9L$b;6|gAp6fA&K|Qs3H7Tp!q)?Vh_J~tk$6J zTrunE!#2DvMkt@W;|(l%hK+V`QT#Q~Pf+e*t;BkZSQFg!^)@sYkbodRob$gRWb zPq3svMkqB1%?(YrJg$SU>}GT3Ei{T9$o+rj!!!gDf-%kuJ*A%Wg`dFD$-zJH&~BPr zy9M(q$f5kh;}-lFLs{P`jQIJ+`wN!dLq@3*7hZ-8w7t41{@{=S02`XecGOT&#!$6h z^i0vmjRr-s!RT=mO3MU>SMVgIP6FCMJ_d@W8RP@m#jX!byVW#en_W zG`cg7#-u6t+0!E>>ACN{S*lcf2DkaN>mMk357L4`6tt?Q72CC%#w?B?V^!QAra(SL zgcRB*aT`DhJ}TqiTO=uPK9}WD6-^w9t>SL>%x5w&!_xNJ@AT}s&WaA#4 z`t3Q}tquSY;y45n!A;#@!xsW!U{H!mZu*M$u;$e;DBE3g@>=8eGSk1#zQ6g#^>i+} zvTkgUgzq_w4@h~WG2$w6XTH2j*4G7&Ay!W&6V5loWAK)dJNL-wc(4nvi&1V zY}b*WJE#mlr-fBE2}TzcMCmF6xCD*!w@CO95uc#^y#X8lU#+amg$=!Q z$RzrN##+@hCo5$bU)&bvm=NsPNN;-5^!^+n=bI-x6NKJ_rzLuQo4!RwsP=2QLoi?m z$0}l5lsCG(@tckSO3(wORHoe>P?A9_S}W~;wJF0%$9>;lb@W$&-GR%!e6^RGIo&8_ z=ojJ7&jr3vIu~f2B3)xYkUywpZqtl=CT>HAKV-0L1|9sKMugR)QJ7+=a$xEk^3Ivp zRHKLC1|INMsFJBq>Fe-%xo zp>cQHdcORIR~0YZv^x5?!0x@|P_y|_eJT#O$AYkCkL+9oM|lyK;`l;aHV*8U1XrhN zaMtBN6b5Vc9VnfkPJ{fpv4iLLp{{PNR6WjoCoN&|G;?3J)CEYBR%T_BE`EMykqYe$ z$a8;01YiEs^|aA#Kq~=(3TL6gYl~ETH+>Kbfw3eYds>ob&(P^jhRDDhSe`{S9TJE} zNHj+6(+2Jr3h`8?t67lnpyehOAjH2Yg~u5Dy&aY_*9@=+e_Kxtya|rIb&IKI;Y7gS zV=V^-8~Bp8G{a~p1rVhY9>-(L;~?IFTi7ByxRz?5zrVSuX_ZJ?3lF!gfBS*yeC*IO zKJnOp3b1tvJ+mYb?`mFUgSO2T9$k-p7bl?R$peywHd+f>#-YFNfBg#BgNql7CNT>? z@72`Qq!lkG7Fr5iL7QExr@du=jgg(3uthyIcusI!Q(jD4iP%`yRnXHu_ZqI$fU6lK zD-htL>9&|IF2e}7kZmigJnS|9)i$ct?VTT~Jj#?%P?Akw(#KP9i~UfWJ1x{tUJW!JE*K6A28L7s5X$ zo4-Y`frymJxHd~=0=G1@by=;OCfG6m>mLRp==ODJmAvz_F150o8VCcgP$*;Q6Z`H~ zutN!WvW=l#UbZ&RZ=i;^9zihgUxmHC-VgP-eZ+xqYp(asI=De;4Q@L4hZsPn@$L`` z+`Zpj__xRjp6gqbu{v0yp#liq|C(>MGyBgpO3-*(?Z!J+T!1WV>Smd2F&6}aOdLyC zA`|K$-2D6x%-w+WbuB5k>}V>E)K*d{Y|0b4DoN+JOt<^o-F(_E%k@DB!M1>59 z(Th|m7jQ~lg$?%Pch>?muK*+9ejNr`F^ZTp&9~|kto!AOI}t@|ojKo`7UY&acFT~e zwLVOYT_GEM6;N{9MX@PD>n#vAum&&%a0@g+uR~JBw*tpYch`Qo;?UQRNmt5UHb4f3 zIh?r=f6J|M;D8!4%wSwq%rP-HCk8(nZj6HhL_ivR59$$#jzd4Z0CKAbgxz!m+Oh6g zovRcTf1WybXMKaZpFuneh)>qr?eMTqJU$Gtax%#5k^dUa6-pq_1QA?dFxO!YQP;ge zKNVzYIB3{)dfFq>4O)*MOGfIntvh(PCRiq7ugb&Z0MH{Yq#2*$2l5$&GvG6L5`&AN zximQ51g3WYy9=agPGa#H7|G`OrKP3WzB-9Ynk`>kA47*SNPuo0AYkpHNR?7b@D+KX z)cFB(K>p>9_}_EYdMd_Oy|d-y93ob0q!H3=8paF#LdFC@6o(#rKm^94Gn5jQSWv@% zA!C(Fz(E!m2}oVu1_)gBY71iJAPAlt`ZzST{@rg4?)Jdx=9dNtFKx(dT=lIp552Uk zPjzgsI=;Du$AOOnEN;s|*GGz2rbo?f&S-pXR!dsVrMjVkmU0aOvEb#Qu;Ql*Iy?10 zoy-oe8@?obd$ZPh@&HtM2pAw@tHfk0z(IUJv2MQ10;^gtaJbcVkcGhXHDsv5gS*SiLm3zIDWs6Fx_v*o?Z@Fg&Gh(H$?>5Fbq%^z*V@Qr=kt3{JA4tRO()Eg#36B zBh=})zn~dx+s=o>_saeCM@Epx{LMvoZrQs&_X#bJ%VG<1F7g@p46&41Fe&U(IPZf$ z-0E++-;XGEA!%3duCsziH(dvFy72f=zi${L^ua?O;t0l9VQ~<~LS721SI8KeMuRB= zAQuoWuApbCkIC$?2$SUXX%r==f?W_o?r5U;!1sV@!$8%{F&IgrrVk7z!XE!@zpvSTSFH4{iz)o}BbUmI7g^H(eSOJpvobC`g^l%CKD??-YQM$ERUDclL@_%Hp4qSGA zb@ZO@HpWAy7bm&eSCghwN(#bEKjg}GYjCoZOOZrMJ5Tmz<2$Z&e~UIv4=U(=xXWu! zapuZS7&6;766Gt2JHCTVCeH*nRimU2B#@-+*DX(Vbj4PPEj`M*9}du>vR-u3#81E- zwj3hxuHYm8`(QEZlY!VMJs4$l&fJF z&iZbk>DTw!@}BF%O%7R524*AS0`gx>hu&5RaB)>yJvn&RD(eDIt$gn;*;S4Z)z{(@CboXaxH#>{0-WS^BvVI zFu-F&hm}!xCAo?1uT_l)Do-JS2TURmQ9k%HC&gZUK-jzFiKe(rj-1%QH98Ftktj|d zt=>VNULo&{M+NA+Rz&kafiRh_9da>Hqwm+GQq(*=mG-9yjq#) zvpI+eY*OGBEjAy%hZ{lJtamnjG}8kIen6HOaAk#vC*+RmQ=1ajVJ^D$80#UI3(Q@( zenDq4M2o8qCpQ379@rvyEu&`8pom|$3Ip#Eq;I6bU(D9EP_-5qWPH|g84TvwfJ}X_ z!N1F~LIOyK22%@JHrN6sjopgp3@+ejKj%MKD!FfP-fZ9+QKY?epa0u5zJa?fwv#Sw z;sQNW_I7Yzz@qO1B{{>^yHU#nqAHB#VT=vOGY5mi!xghjecanBv#$R*@fb!qBH-4Y z1O`Y*eK3mCOx+a`_`m|)JO{_uU>UqL&_52j0R}#Om3G^s0+cZ*C;U=&;y&POsPsW( z6?;|?ZT*%88!;RCk>8uyW)TR1SUAulC~Z(6Z}gXjm)$9gEW1DC?ABIX6b zxNmBtEy3^N#82GpF4D>~3xuAQ_5pa3m;PP{y{ro%8?)xXj9U8F8VKOulzJjj`3tzA;0qKRSe~T|D)(3+X zP_cx$1+GCiF*ktHe*5$Nj){G>J_>CKkkWnpBSu;d8zaN=T>H8w!Hmk4n#k|`aWxgb zbpnjKfwXpvyco1hU>E$GV$3|rW`%kMZ18{T6sR*1$v5=h^>u|6NJFr);IB^X$VG6- zx<#!KxK8lnKwSs^5PwPNVg$W4xNvF7fCyO%0#@J`?uod^W65LwtH2z$;`zh2_le%j zt@FSO|HXDnEZy{2A$2mAc?84(@Est7gn_>8Vt0a`Am>GXS=P0I@O<-7V1RxW>XDs~qOZC%42chrro;xmA|$9! z5~vjYmp=%2Joqa+#+PkdU$c0|e9(F+VJi87))pJT+gldEj~z6;B?1mfe75YgKNRQtZbE)UHTLBo2qs zNgcJyAq(AXcq2HRB4N5*>{<|0*Uaxyc?x$|p(yMH`+j;y+u6C2NX*!TY%OtiNEZi# ztxzc2t1}K7&TEIQdn07XZxoeL(x!d{9)4nqA)-nM!aKl-)od6ak^)kLf9q*+O|P4n zLU>vg8qIx<4wGC(pOrJ_^x75pURw{9clWAPJdb*Ig{t{=Ev@MC zOq92p6nJowF;_;3^OL2y?-DFHr$N^zekyVxAs0{1R z3`M@zBZR_9*mTWqGs6Mlr~8HmglhsjBELK9xbiDBig8aw*s7W>?F`_!H~jdJQQRVV zP%*T>$&96`q-p|r0qI?HR%=Z})v_Uv#A<5fDk{-z!sfuptt%XORlWRM)d7(n-NaX=cYVnRZ*j%vrH3*oKoTIC*3;cEZVpp-jQoa@uXU#RJ1rf}p zu%xQ92gZIbOeYUN!6r^dt&}IREwtwv6o>7fFHmE{2*?pN9=}vYLNTg}(yBL8EcbDW z`gyy0IQ8C_RTd-ETd@^iS~MFsb!52b)t3E!IG9jxO7nmlS#i%B=K!Zx!`eCXkIzqZ zDMl6*+^LIlaJ8j6vbe`b;%?VjWY^*+v0YZZPgnGvjg=b5U|*`{Hh)k?C$E(oN=ew? z8SHLN_+XGU?cJ+J{Agi7?RSO!+09=^e(m2WU?XM7?cfSgpk`M{|G~Z=kEUqb{lYxQ zOO}PhZF*pzxe88NF)FMCey0vSlpC=Z_=vm^>Tk-k*Mx{BYU=Hl98a9N*xD#hj2l&R zGA6r;G=uv?x;$ql#ZU-Kovy`*M;6BnF4tg3@~*IN`Ci~K5WT1$cnEh6*;Kbx2)x;& zjk?aPMW!q1k|UmScWDleh+~@;dt7v+)a&LeS3C6b%UqjQJ)NnuDxJ z02`qd=LzQV3^_2AcK(J?^LVDS;owV3^-7iNxc*|Iu!`&8o|*2?KISSoM591m-!_vw zwTq*+OKhPkXLW7 z`dabw&!^#W<{>zET>Wt8DPslPoPO70tQ|+>PZhSy=64e&=nm5)duZMJvs%u7Wt}>PjKgu<%f9m5L2*7SZFAp zSCwKG`MyFhjrHQ;ddh+CjU-rKhez<$vy5(fWKN5Fm}aHi3t^;c6#`EDP?`eG1KHCg z?S(l$j8QEmD&nl8n?c;7l#9M{^ojqux8!qe25X;Q`84%)FTCMhB(fH+JWPDoWcl!-t>vGT2k zOO$;Bs$jd+!u*anzGh3RPKw0$WMs(AFMUk9 z?>$=NHXDkgDQV1|)0tf`#hsx4-=Ff_D&;UcWIoq#BfrEg3e(B`40FjjWZRNsmy95)Vda;szs81+C*{u=|jxYPI1P) z@b0;Zcc#6{<8(!47uYo8BOrLpnC=f?(ikX9jvFKo=Ob;9J=<}m=#jIg(0Ue)XPmz^uwTpWUP%tauH;XD z*S)-1w36b%6ziiWrKKFVJh@ggBl~eVd??mN$)Awm;8UbBFoqxJERw13A{GpPGnFz-K0zqrl3Q~Ps&k#Vi1CBL5&uU_`V2{V;QN}QTQSr9wtjAV{KQR+pCKfM z3D0~V08UoQQP&c&1%8mLC=k0Ll`K)a>N@O^qv_uM@$TSAarN`_Y(M#Pccm2K>>K|U zkzzm1ocB)Cmva!_HE;H-WavV19K+#32&psN3tfZv6E6Ei+>!&#!j^CHBI4AQ-iWeu zqq2+oUAc=5db0eY*03je8}Cti0<;8Gv48sCT^m40MmS)Rw_$Q^fVb5mzkOZxlDNG& z-LY(itvGG6j%OafHvdLh=?7iHCR9o2hpWt$q>!6Va-cnGOZK>sIY3k6VDZ+mbjA~~ z>uD*m064;n-bNJ8rTw9Y2h*5OHh+rCfFohAoG<6|_gZm46O!5hH5DNuDhf4W+L>iF z?W3ut*e2@wqbkYyjF^Mz>@Jgp&Y{9|->RNdy~idevgaP%ep)}ut=#!zIqexyGPw>3 zkRI~+#>5JEUxwLBYP@>0-vXB*_t@(<&DYY>8O{LU$vKa8MF3u?#sI%wu!v=;`;Lxd zb3WHEX%uIh4U9=?djy_u?z_l)w$XCdDvi=}dR8WK4i5i-q~F8GPnJ&~=zalC9l}-M5WYERsO}Oo6pwF2<>?1?FiqaRnwz zS(P-wswlUK7Fj7@(|AWOb&>uj94pvc!ybu__ZCg)Ki$yxOX}(w0t5_sEU-Vx)F3w# z-Imf>8qUP!gJnkBHXjVOfu|x!3@WHtU%J0j|3^W#(DOMCKtKNcwN~Za9i)`+dllC%>m|c_kED)xreF+|K^t&K5x+} znz$RxMkn!)!&J{5!`ukdjhr|}5}g>@A-i7>w}8pwckOMtILmg-ZS-q3lCy)*)TxP{ za>;!BDgy7=S_a=Z`Hq^;7_{`0MhJ7ytuOhk!S05Ib#8ynIug#Ghk?52P!cFv&izP0 zm|u^Xr_u&!R&KGV^X$!A)KlP(CkbjQ2bEOV(Z!mDrE<&L-maU7rIZhOXlKA1L)cn| z4|RWS2#{*TPZa<*cY_(vs86O=?18Lu294t%w}W5vwOCkAZ==p9A!V51;d?b5X%H*J z7(Zp0R8~3h%4ID!y5g8V-Gdl2=q)Mt{|gy>>VaehRm-SH&zZK2pToI-NB47R9FT&e z1j~UOnfXqE;Uji$RT|GLvOx59Rha!m-%4#&m+HC@Uk*58{FWddfcf~R>92fo_#&hl zW)``|HM^R9Zc=|St7MQeN_T6dfPdt|{j~>TAJO({fn>;2Rp!C`<5Yl+CWh;AsQqqh z92;NP^vkBP*ryP40!JX|JRYzEt)kn3IY@1#Tw38>W~3Am|`sX){BCT6wzsXpN~zS-sQJqS20QZA1pq-)yp zj0Rti`u-DP*NZ_&ph`c244>$Ez5KNp7lz`hZo5f+5@G3OalrqPci;L16O1K)NSHUOX?{J0q@uB}wFmfEX6tF*EJ)y5GlSyR zCTecw^N-*b%Xo0!j~o^)-~=jZux8*s1$10D4uBBZ(3rPaHqpEmL8ahz=X((pimhCw z5zj#m;LCo7${W=W=N9o^tBIw91j|KE#lf&o{c~w}fu1pz)-djQ$^qZkuYCZCoPFwj zX27><($yl+_7QUk^FYf*Oy9FnSs1K|LOpOeZJ&zdGRS0cI0dQN&jmMg*!D~bsmw+sVRK*i zJZ2#|5gzM}JHhyWAXF9s{A^V%eH`ELIr#q}V~%PW#<(57ns|n~SO?*H5Hn8%^weop z;{^5dFqG8Q-Vh%O7h63>Gz0sjfoga&GD$t0+xcL5YTVaI5y9$k+H}`C8;~OiXsa#M z>@UUfz8|pbsg9INs$H`$g7=Kb`fEK`EcIA$u;G{ne28#pplp4#Ph59zq#ox#(o7W?^2x9!e>hZt8+FPGMLY_^@H>7~9 zx15x6b6XDHtL${oq0Oz-1pu3At4@mBu-w{_20+ge88LeN76B0SFoSkZ__;duZzrcn zE1~KK2gCW2j+mKVCx@0Q)+O-E-*^~W*F}7%5oj(IA)>2+1SsxF0tS{Guz1oHa+Axu zyy~&EG(!KQ2e0o_P5BdO{7QtQ#6*k%@Ah2{)pxt7ym83d2WwWk^o!#w@{NCalfs-w zO6zo&t1`J$u4K%YWyWzAS#|`|(hwvIR>*i3fwitA{k0Ol{*)a-2VCx3PTn2))k_eZ ze?d)KHB~yII$z`qseUEXC$*xzph(Vc{!>|jY+7Wph37MKegM`{5fzyT1A|U(rd#Uq zgczY$FkphY!38DBdkQJ1TbG|Fk73@TBWTcN7_vHX+1t(#c%T-NLtccmH}4F0*;Y<# zOBl1l;IkmXyq%BoT#XGDM_((ns;tXBFd9{Sy)W<9$~;hq{HBkQkW8Qg(=$Y2!0Kf^ z2wCJ4aT{M6?NiW`q}JCo&f_>uB!6_y=FtV|udPM%+qOYWf+HATd`#Ar$LB(7^gL{} zGfC!ctL^Z;t`dgx$g_}01y*aZCs|6NW;c~|iW<{j9D(w89@$sd?{sMJ=}Rsww@wDX zi#y#tJK&mj?UPfPu`EXD)8eeA?mNkJyz_!rca&A0gNUjL<(1nP*%^~HG+Q3FwPSR? z_$8MEZ$ZkWtJl~?i?@p>avhSLb<-G*FE+m{NP5D4&RsimkZrPJx65E#u;5_^l7QMy zGEMmY*D6l_-MTcT4BudGno6!9?vmW ztIE_V-Cz#Q{QT`zde)*N+O^4R1x0o2{rWbUN3GQpm4tjhF5y0|v__1zD&lU>ejpQc zmqtA!3v63+YB*XIk3x81RjB2g>2SAKW}LNJQ^P#uFTR% z@*&m;=3jCp6%;#!?Vvaw!N=IlDL9Nw7Pugc-=9tKP#Dh76*|vf1|#49tpCDlNu7Cj z?k--@#S?CSTGe9p&NDOb!a+C&G^lN;Xz=tGKV=0D|9%R8%mG>2l`AF6{b>#&#!hz? z)?PH1IJkx^WG+GKGzbUI;la{M1%#lnPXiKdMz08D$kf&jnrFoITW(AqzWTV);pnUL z2lOae#sthcAyezy>Pb64R5w<*6uZTxWj=}~7kj`1^+M>uF5GxY&z znw@Zd#WYYF>#$J%YyQHX6LB$_w=4 zFyapBd!=+e>dNwEi==~PGa0Q(*h_wm$4BFXz2^_mM-ImCw|mfV-ZbWBjy% zG1l*gv+0t%)>?X4(yn^zpzrAP5^<^6<$>T5P2USpPw>}>oj(;k1|>!E83n^zMJCU= zgHpVX&bfCL*w-4^WwAwiQJ_*6l~lb~eVATLO#i&e^M6I%Q^YcFCRzIT zMs*Pu{aE0DaW1{0#2Yv#E}D@!$6qw_Kt8A!Rdd%)i=G zu-K&k6Br-}%&xVbt~m!r@43CN0Ja*fW363xg*z1AQT+^9q7(QM>T2mjB%c+aKf17F zBmj*CV5ZXKfF#-)qAZ*Px)pU!U~_)~<1IDyT|JjC|L+mB=ks~}F7yL~Gsf=B-5Gm} zXS-R7c&9rqL48utGvLOJVWXNhf?ngLC8d1~sb#8{dUZ-o9SbPjcuMQt%*#l!>KMPd zh#Qbiamq1owx(CyEpK@Eewe-5!6Sc;)KBQ&x-cRyL>E=TJjEc zW%kKsY<@tuQ2T1-w?JFtdux}h_3yVBed(vEp23{uRpBuI(I`o8vD*X=c*AY2l<0J& zzuF#;HGY?=AntHD#Qe_Rwn^x*^DT2zk-T#9rDbHBTVJYu#H>KyBgxYz=ob|@dz$82 zxSsYXYiik>65NQUGDt#<;0qIgB(rYx-(BgoAiu5L3 znh>h=P6kowAiWb25~M>y3#5EI%*;7+%DdM0ukZa`EZ0h&B>Q=GxyyB3``&eSy$aLX z_K*b*arR8^C3PrDQ}_18@*~!BZPFr7=BkYPPr`HIg4tSg9_Q*$2HYtNPvSeW3w#PE zFm?L+tbtd$?pK1vTW(zfVF1C%gU`y12dGv6aC*a(3}ZyM)4<3Q?HpIdN9KP_>&#nW68cm zohz~}l&T&8_}kz}ix{ABfE7wZZ)X5tCV#E`$}ZlhtOqa!d%(!h0+%)925yHk%hR_O zO$&%&3T~a>^zVZlX&(ep=IhoL^DOBy$gQ8QG`eo1O;pnlhuO>z27YX{ac&=(zF$xj z=N8-j+Xn3tc;-2Uqu_k)v2P)={J2MEsX%)HN}!U2{PZweZX&RW2KW-M2ZPmt9jKQ6? z_LxPEMm;T>nTy*%5Sk3B&pK(A3RodR*05(<>Xqa#ufLjR7hYD2RNxhIA1OnMhM)6g z?ksfmJ}#<{dK<78Su-^EI3Tst0tZRY#`EUW>7kz8e?%zQ!irsDIuc!_x?n_^-{Zfg zYb zO7 zHR^0qg1N0(c%8Hb0^-tEUWgRVb#{XP1t>07Ftf0=CPBFXt0p6Fj4`8l2SJtTOc_H!PS3tUB z-g2!V491!(BJFLE=rm4FPvzLRwNFa}0ynm}y=R7tWKRExBWy3mhQ-0OTdOFzaweb25ybgQaOzR?T*#kCukdbW& zID~Hdq#_=*8!R0-Y9pEmn4+PG+Jc={9U7Ys0#vT#qdOA-xZK11kOfl+_`Ipc=WizW z0XPKMBS|vSvH-n?r;$B8kLqb);&9FMKhv*Da2j+h088TTr0U)nqYgd<9eR9+;q8vKYLaP_5)Y0TFi$%ZRK-#fm z;AQlV7|Cg4SU<*(LGd( z;U{$_l6mAvjDX7i)n^pC`#h|Q1jU!d>=4}=PJr;4LB8#b{EpujYEJUCg!Q*nOHS{= zjz{zA`X)U-*LGzmNbep$(DiCqQ0G*<12%5326 zb8}sKiJ{|^7*#t@5Er#04AJa4wi#yaaZJh6y1l>fU*{P?CHlv-S|xHNxQf9u+PHN3 zGvQ-f3(Af0=HF^;v(l8f#W_Ziqvg3De0w9kYlazv0R!Cx(xC5tX=)=NsYOV|O%8(G z!DQ!{#8Z$H0<&F3Za%r_Cp9*aro47)no~U=AOrw|#m(-a0O;aJ!x90%3!F+?Rd(wi z5$*2A_Assp+wrrl7<98ETiM zY>FK^G*pS`BiWKR1NX$kfW0{5Zsvld!qTx%f5DqpssAjw^P8w zf33z5btRXL+g5`TcS&Mc!7A;Jz5cUXw0KH@j^kUBPb7h2HM3(HARJa1p8tI`XD)B3 zC(viI%7HjhZmaSoO_|S?V8?{EQ9E|>0uxtc7X3ELCVxoJOC`P|W!OwS(W+M@zk48q z^UiQw&IPlwGPk5#A|?fD@f`;J;~o)=hwYg0@2|?8Kj9*ySdX+Qx~ zRt|}MpT*3|NB({+ZZY?G?gC(^M9P7uOGLwqQltra2_G=mOxiWs$wM1~Y5P&;zb61T zvtu44-D^V7i)3ow5UHCoGI10tnb|L)wY_vx(h6lhM7;)$kKfBVCNtb9Xkzr+>zu4& zz4R5;_Lc84irISOT#W(3A^QDJ<#XWy(U!4C-jb(dpOBwuRs^_ba<52wI>xbvR~Ec4 zBsa+U1jnVQT(`|=+PTei>Y<8qqkr#FIqhpZ+z?aWmPew$(lWtgt^JRwk(=e_GOVF| z?p=2tgiGJa(CJrLbjn|kycH+4=;<-OyWoD#U59&KWxFupid9NyWQA=HipW}g4cTg*Fz9>R10q7fvC_wJPQ?bHIzI9q7Pdr5zUBcy3jv%~zS$vthffUWP-|l7K9rmBC&YA07i&*8Ljx)&_OisdR z`YpD>EE>UGwwQE#bzi}+c;q|NJjKtg_v$V#`S(?B*Cz5{v*+ZP9}Q0~e09Xf0|vn5 zo$TaodC8@6Pf6cw|2)Tzch`{RE1Bki2?L}kO%Wu5{<5=hHsVaf&bRMjalOeBRI9~| zvuko()kHivZlKN#R$`d`xnT2cKFDuSy@NxN-AB1&L|liZs+Fy)=LnEOaqu)Mrc{|$rmO-Ul)(o)~(?)RM9rv1gxMH zqufdva5ofM%(!mLFfd>=Jyy23sf^zKJj-RA+Mpd!@;hH#T;G*)e>b4Y&}Rb%fVNZt zQ}e+&>FP^3U}=P0t+dtfHzPNh?jX~52e<|17fue=A+ofL(L@coD6lK*zapQqb1*=+ zc>3V-Dm~5fbI*cI_^w~Ai_CGTe9F#E@J&=GaO8&(q1l-iLn~qkj5tfN-6sU2D)9-`<9d>Us;R^(5JWn zQ4q-5;uAH_pN6J-cVt1$w#F^J>ztpWf5}||sBjGkqwezBf(VOm%@fR#4#2(zm$2t( zrW8s&`*Ns~_amUo)Qc7FQHBQc+-Zs}Ai)@6Jo(?D)c!^yE}8k#%sb0)dw0rBLa3Nx zfA0mkIz$~wiXZv8gQFrafxJ095y7{WkXC?0??|GlEm`u3J2h#=*PTfUVZU?>p+AD~ zCPK1Em#Xj$L?=N1RFc3%LJ)rntP;c1giUW_^Guk{hlv{{>sZM{-y?g;9B>_`Ir}v9 zVn9d)wF4}x9*+LC-!$pErE_!lKAZVTX{?(Fmva10r<(LLLg_HJY-wc+_-P^yTC?*7 zAv@Nxgr`DVu$yk1&@TPr27dQ_=Ex@h)T6A=^`P! zI@EhoQ~YZ6a-CA-i#Jxk({+Xe1=N;|fx1D@KA?UVPr4o2@-&!DCmraLhi=)in{G)f$X{*ZeXsCvbko}2zD{1YTJZPAka3CrOK`ljKn z(cm>xW26Jwy;YuEpi6OUZD({@i6ywHyOiH0ZUEg6P)kjb@TUP=DPM=!16j*dtwpB! z_7~=459<6v1nb`P-WTujYob(ZTmof%@R;}2L*I<~83{P99izVZ_h8(9iF`BfA@dYXx*rt@@cE_$n`p#=0#8<~gE!%7T5*WAx zj$Cs9+Kf6u=>m(1(7v_vci$YSFogBB-ZuilhFKbpK5at7&%GN>B9C$iN<(pH0H2WZ zp$l_DU`zS4Rl3Nb%?ErSbyt^&4c;>LZU%JUS*V-?SW^7_H^kisEEh%2sM#z+CYH14 zZkp}w3_L}8@(Fvke|F79+G3i%jqq1b0j)9 zPq%Jdwl=>7`xUVK(;!JpLdnXn@C zb9cSRedZgVgCxzi>6t@<6o!@XEz#AV(CF!nG^5n`QA3pF2=(%_wr4IA9#i`~Q{9$U zS_`iZJJXb*(-lV4sD@Sj#?v*+zo$(BDcCchYD%$&cUE{s8Oz-U^%#ZdECA`|2TWM#+aOfTRYJFvB(fP_SqDSHf@P0m-&t}qp@19p;fpQaK`E-|C?jifmoL&c4qLx#qv}Q z?xc=ka~33jf(mvR%2fR&jPNFaYGaTX5Jv2GGB?Wkd@Z0D4z_jeO}EO5)>KcPXo4xJ zk^Obgg(3iNAgU>&CNWRvc1RBjI-N#Sg3bm@gpNZVR1;F>3WWLuhIuFU_HhiOnlyYcF?5gRej`O0uHnl}xd#QbL6)5m!dx3b z4-|hu#qsEFBG3j!w}VVW4{D!4c}l5qt{mVsF` zMMRC_5k}D*7$B@VtGnQUmMBSb?*>tHYs22qnlcq&N(9n96C`rWXduGWTe&mg#$mx9 zt`B0TaEb&Fl?{M^JS}{5YkO}eL8z?hge`T|OhmK|)8OCx@&}raj<=+!n`3=+^maR< z1S7JuC|>PhKB`Qas@ReH!#e;AcJ_kQueYsCQ5Qpv5c@a=dn=$J9Ac=?qj`5ecN1KM zV}pr{Ti1zjxA48yFk0{WzniLf)bpf&;PVS6!-rFwkDq0RF5E`+Yb!v-!LY%Z7wKN; zEnizOH{~(A5mD;>3z2{z$Zs8sXUeDLyqvpPJ-bkadVJ&(l7xNELmfz$ruLp!klB5U z@tu9yuAJ)EZDFaouk+EkU}-vwI)7U?yl!zB886q#wzZG7C?mjRC;4i=HIW8y!y_2$ z$Y=+0lmZEpaCYyF6VvkD#diOxY^`{WrkV*+WjVl1llMqj$+<#frCwx(c=PAU_^%iWRBdUsw*$YL%D&N@Iq;?La26DxPFmFW`-_yh;xTBP%5WCSM3h?{A z8p4xQCjOz54w|>2K>=6Gt*{MfEfVT~vYfkV>=&|OvgW_!b{|gBAxHwLs(XJ5jO;+F zzC=&?us1YktF-l)rki~}$`}z=1hmmW(s7FO4p0#f1GODq`BlWef0W6-s35Mm_T;0hX#Q~q!1Y*frvxlp5Ap2}y z5d1JVZA}II_-%}``7`3LOdbe8p96G3d?_UjP=oQ?ZM#t#gPHHMopJj(onhwDqvA*v zg-lU4H6TMcVqkjPn`{MQd0=}(O4!}!0?fgj3$qb=+I~}cnGL z5R_=1M{+X(ARF|E?0RYX8sC3UKd87PcFF8(7l?=2e$_b}>5`yIl=M<5RWlEyX=@M; zR=o}cpmnwR;A(}vHj`lxkF@^TafqfO`93iGL;X0~^q0jDGd)FDn|gV&im`d|%#9L7 z?31kr@7!z`HR#k7C2`YV^P!Z_w|7?r%)>23e)|*~ab@dUR))QeyKVPFscsvt3GC84^$N~4PbN=W#y9QO zEECJ(rm2T=CyXt?Jg@^RC6#$Q3JLs<8QR(fK;mbha{M7w&$a0ljee=-`b@w;pROCp zr;}#0N;`p~!TUu1G{EldDpBI3@Fn9Jv6E@f$F;%Q(4NmLrDOo5#I@=eIK-wsHOaZ{ zR;|z&6|AhKmi-^0Y)j@0$KzNR(vS`1&O>+*^C$ds-IOI6y>ybM-zqKM`+1LDkQNrG zx#ac6S%27R{~U}e3)n&wotiktalb?O%&! zf!Kd=cE*945Zte@6?+`oh%*>_z}}iYcNns}Y#@DO_v*=7A){F0;rwMtNW@EG_VMhu ziBC*bkHy?gx|L@4 zT0be^xE>w7l+$+WUJi;u8T(`?E-#6PySf`g?-CY@0S-9R?YPXB}xnxPEvdU(VNDeFs0Iu_P{P2UoQ0xZdWV zN=TcWTKZ82Pxy<)NNXFl5W1xTjqKJr>FA=lU%NiPo-`oy$#I2_`)8;YWE*0a^VH4b zCf&dJl!CQl|cYNVCO!R(| zpp55$)IOX0w&q)9X`)NDr0r_~tBSVO4p2nh93O;&Nrx+UgEN}bS8yD`I%{r4?b0Dk&YJmU~4%v*kAU2pJ zkesdj>?u|GaIJ3b5{)I^=JK=(zGoEz&(+bAm%7eJ->+0gH~_zrxN=qN^ujmR7?J#` zu(WFnwo-xp1h`3~Elv0=YD?Abd37sV<7xS$Y0|!6Li6{hxhuq0ndS+xQfq&oHyz1;9?hi8i`JF`4qs$|6z(FxZ*kL7jo-DGKQlv3{3apWX<{QHZg0FwM*;pYjI6*5#S&@z>&N|Jy&*bJjr3*p`=7*+rw-GXhR0tnK|w4|(tdg09dAHQd- zpuRrNkyaiSQ~2r;%Ua0#YOEI*rPi8%=4Fc80(ZGqK>Pbm_LjL@1vzkYD*^ZV!QPM9 zQ_;FtQkbvsd*2l?Qtm0-8-#}6t2A=yoXHaoAvSX9;83xB+^$xxV-JR7ivmhBqAxid z7O$T4u#2xy4$~^1TeZ?Y_e*4be5e_&^E^tT zBFU}Ep+SG~ao1_gE%AHVU}psUV_&n7Po!cQqkVSahhf7UdSx~5{uB;~(cM&`g|6?4 z;hPx`^NS;+OAWg&t3I=~f^BWB8eG-NY zb@J==RH5B>R`Q;RRCNg%Xpfy=Dlni75|QDg8EQN&f1r%Tg&ZB4^~5YoV`b(wWD%2F z7*WqVgiq5nBh#zkDP!#&;jfkIKJbYpOMD?{BF$Jt-yN>j?YGhVT<9&4@I$ramXA*N z$)*;|?uvF1zIjEqwYh>O)Gp7y6}&&@Tojm0)! zvp)O%y_HIv!*Gixw(a?`d6nZYVu2C8l2|f)QeH_vM(Re3YT8o~I;Q;lXZg4CIGK}V zr%Zacz={@!vZoFzM>`x-(2hvDHwcSz-~V@qr%ha zywzSkZqk3m_>}#N+L;gcRBn5HO9ts@xC*_IU#5^}E;~!$^rNs+HTUpBz6g>|vu~wq zflk0L`G|bu=WcJDSgd5C`D+s1>s6?y{WA9i`)ilKgru10xfS(2{yTj9=GUkl&T%JS z#ovk(6_DdnzW6|Lu8K80#V;}I7xTM```W)9A2Z#0;l%XzEK`8CfC_4)xGccM`rYzf z19@Ofjdabpn(4bwDOuj0do|eDSv<(4`fR)Vxg&eHTaZH)KVhcrmisMS5G?-c^~5hX)!;0M*O&y$=D;!Qdz&e zcUkQ`4zS~i7=q~?SrQeAy=>xJ9 zEiJ=n*~kt;q4(x~0|EmiOi3`^*qlMn_Z=;TvNshrMn}gONDeeWZu9pW`B_8#0_dGA z1#0Jy5A&o9=D`0N{hu=;CLe6bH3J)RmlhWX(H)Xh1;68@f%FnmE>FoGGF^D7BL<1+ zXr$sp1KBwclxHY)En;^sU0CGaPI9l@j^vT|wB(1OAm_Yb#AZpM`dt(1^HmG}(TrKPc~(x*9Kogr*N<^} zR7{G*di8vY#1?bz!+O%o5TWR3&3IyqKV@ZxnKh$|%@ePHiWtpx-^WNo$FV<7=Bk)^ zP3>4!9!4*3#y~mzmd#Q%-}w$Eq)UJGN$|Lri%IiYE}`?IMkq*GbVYx#gC~dvtm7u=(|gE0c+nK;BYF2)iG#H~X6E_$jDWBk3Ep-+taq zW}6OOTet+aFQm9GmGa1WPugpdCN@e^zLASu^6MJCaqU_Zr|)Y`o?E>#Q~f)_s3;)6 zU+#xd>^8M|9xhChi)Xcnv(L$`?8xDFjQ-MlyXqzK7T@z`k@BQhcMaLD3*;>#_WP(F zRJ5w!(#&kQ?_5oZT;Iw^bb9t8%hr??L3d4dJK6$sd2A;gDZV~onC>|qmYd>7IM0l# zqr56mVkP?M2ZpC4>m7+8?lbtiCFHNsHxfS!l!z{^w;!R5=$Z|k+f&%W#HpgP{3Y8= z=Qj^~ZW8-G4}_S*H`%6bwW)j0B48Sn-v$jS!{pt*BR#90-L(pJq)&$%_n`>i3QhFF zu3$_AbrBOz9&c%FU&%P4S%X*RIm4Qt(80+!Ht)GAUA!X{p+JnEwXQ4~zNSxe~ ziSbcERUO;vuJ8Hj)_TR(oEX^SnX-pYm)116;{aa+O-70Bze^UBS?HifdZZDuplX3w zFD$ecGPI^#ozK3zun}QGwv2O2U|lOkvu4!Y8#1i+_jWjRh`Ooz;I3Y7DxW8Wnj~5z zO-U+1d#-xbhU(Hy@yF0ni$X~Iuqq-su#MN-A+k~b4Xk>Q;ed;iw%O81SRdFatdARdX z)AlRq@gqK)=Z~!2DJ#(TWPe_=f+GS|^j+Pq`xzSN(=OmBN=L>=r$#mzs zx1DINJh>rS8CQt>Bvc$jPWNh-D?=6pUReRFIQD_pD1M-;O*N8&b$<8)y2dxdYyo9|XUMJFM28%^EIyGmrju zgqeG|-bX!`JgL4@d&+Ssj$@NoC5BH#sVSgwIQ;tzoBaEctzqB8t#st_+blYCDpkUy ziH1ezoH$*rDhW-Db)%^TqTaXO6b<;VZyNE)ITV>%k>^H_S2EUG^mt|lutzTTQJ*7@ zKH_G$qvLSsD7RtpRoTAiCF#c+f`=XLqqrxGOU`C8O{zZ9$VfQb(U*Ja0n;_(4 z{GZ_o!FGLv(TGRDbXx?=) zLp=KNt!#Mt<5noU!X8G8E!TX7)dML+%#tAptzt+7cjTRl2@do&Op;WhU=+%)XG>ZR zUNtnolu{qcP?GLu$FNoHQM)(|^HrqJ$9zvub!(NfbWtEr#@y6l%kCjkcAK*NDUHf| z+g|vG`qfjU7TsJjK$}QfdvZG;sT&HER)q}TO}ZO@)#LdqSf*`)yniw@e=|GxR4^5Wsl`Limu5uVG&(Xva9m*Sz-gA#5I_LCk;wDEl^3Dt#|R z;B7pwlKKTD^@~~D9aHqoZ{r_>ci6jPgpD(QuIIgB|L~;Z^V2{79&8MzzwEo97^1Ad zDSRx8`%)HnekPkas08r$x*Y2d`Xz3^PU-jod;OS5Gzp-OfLF9I9kg&Vi~CLA1*}WR zX(jbr;2j2>>Sc(wo0py?)8smSz5#N z5&1tYP8~E1+NL$HMgF(uGx^77a%kr%T=|FA_sp05<0ai_Wo^>JkYObQP=MzCUb0&X(gAOK~=Ut$7=4#|9Z#Kl-a48 ztpGau2F|qnYqNEJOD~JA!vaKob0IgqV`=;d9sSRRTO3HzMw8$E=7acX5A#LLg+JB; zHyLs_q;>Jc|IR?t?&m+1;(7*EAKvwwNEZyEx$#-q;J-k67+7WemKAy&SvegClN2Q) z-C!ncod1@-L|#cf?zZvxF>uLi@!-|QlWD=r5dHW9`Vt_J3j&WCd-@**WTMm*9j;DO zKDKcp2f}w}i#iTQQOEji{32)|v7U|gRi%(>u-@YOW`Ae3x8Z!kAnS9kktj~C( zWNvE3wNFs-JIc)H+vw*k#N?Fk5!L*z2WA9xPkuz7j`gZX4edGD4thr^#E{mTmmwR%T^_M2|Z@?@n?cT%I?_v!9N`H}8`8t;fFmpM8+G@t(7}@*C@}CDCYm&;RGA^+g-P{i?Uf~kzU1;=d0llVw9#c0D{1Apfn$$biDbTmi{QT(BLC`r z-s;_@*tD%jRcqC)1t|*otv81_XtxA>sn%-PVdg?g`Y$pvDD3cq=l=8G3*LWg9t?la z-U9akyYIv9$y&#qBykvdb;lFxzXF+E^;wQmEYRNt^}qh{{UBN`w|{O}(D{Oc#Wz;q z=Ua;F7e7q2VxZKy0xI~8s!dY2)O?EWd<=`Xfr~6SDd-2!?tbwDVPN1v%HG^`tIz8Y)?>t9+l`t3AdAHJ~KbzGZFO`oN z&P)-jXPT8_fM_{XF(%lmam7uVXDmQQPJar;f5XSx%#-k>ZkT^o()GEjv?X;13r%Ce z=&R{K3zyRiKALv$(XcK=2>75FlL9|}*sB05g_b=6RuA4lM)ZUEzE1B=YyS2)h zhAyA4Xnif9mlyxa&JvG6@aJFoQfR%Ht3s}s&YfDb zmdOx}Q%SZG;tJh@?y~dQSk-R9t!LwkI$TFY23S>y_P%PJIn8~+SlX5No5#9Elapd> zP7{i|<9RBD6(G#2VOr8`Que+&tIf$hc{GCI(WQqW9)0n3`=OYn}Cmkj_=QZA7ta`+7GYAjMm2|mUgQrLH*z(r8|P; z5*V?XfI#dyYdQWZFQkJW+VD&zbPhOrPBy9+1YGJkRa%WzTCN(>)@jA%j;T4#rq$MQudnf3EJFqcAN4UR#?OeVr1JpU54(bf$PhoKV79KWV)4X9@eHZ3b9rcg*r zHh3j{F{C90QtGi{>?#7AE2;b*S1r(OfP}p3?nHFPP_o;RA)Opw`-R<2T#h0a=c};! zxBG5#i{G*LkK-1fi0xGuZv^uR^m97lv;=C*#jNPd+j-WiNvEpz*S7t3vt|epaT7sF zQ-r*D^2#ulPma|Mu5%j9D+`I~STIe;of6%C;KfW^PQqO8)dxd%=S9v1SH~S zrR;oyEs8BU#zsIjOcF~tr2(tG70uLzI~ZBbq;x8M?+jM;KTS^*Q#a;li6aw1A2!|A z>9(adJfBr!+M((ULrAd!@=k80uzgdS9nalzNHfV-!sO&t zluChV?Y-{!dN|@#`53$k2O4xcZ)NW=1sopiTU9FQtjr9?09jY!&c-68w>rY?hn1Ekl zM>MJA$VFU%9{F%XTnOAmUh!zWi51&*N%#<00^A&JnS`f;B@XOF=V;r+fApvxK^SbZHw;}#8y>1l;3waZEv59EJ z9q&vtqp*ZvRYz=am!T_O!FUdUDl4%_rpf@uEbjS)Tu`dB7e0@F>)fDt33UmVyTJ$6 zyQ&OU=_4;SOR+oFBcFJ$+cUEz)oc5fzup|pGMZR5IhYq4rwuOuBsI9#ypqrv=c=~; zKq|;1A{>2ns)6NG>Q$!NT+5m4b-t+(12t}9gBc+V z!67OR&*&LGJ9+$i_PTvhQkN~&1d?#+c-WasSdY1PVTO%t6}sbv@i=6Kici2L9MM5v z?$%k|7*$A@NoSD_-5Xg}xjs!`%9M_;oH?#T&jPD7)i@p&OU&OuI3g-qa^&uwCQz-e zipisbYMpC8dYeDalIK>w!{NfU~u zu*u~Lg+C^4_jVrcwXCFxie=$lPDpHdBsKnYIac+oW>N{yc;L{?r#ST?r)<}Rd~su| zey2ExY?@8$9%hucH>WQd{?Y2%?<=Qm)@LK2X`0rjR0j|G>QT~lJ2~5!7e9c{wpluv zE+*8g^`ZHMs)GgiXkT&R%*tm){s0?bCysaZMN>OPpNN}u>sdA3>eeq;XFIR~Ox%^G z?JL;C!DSt-mtcX%Ds?!Q>*q&t@`P!@YU_&H9LnJS#xBvpsNtIjHo#8dZYPsrnq1ub z4ZbYikT6N*&`IHmtRx=zsFOvdX}4Z>P?;DH#IRd*%~1UQXNd#5Aqc$J*MbQ|)4dqu zG(x8+YK)IS_~vxoGpQdg*U3YeApb{qib8Qp(5WgJqGR`|1_3GHwv~`hfJNWb16pRLYP6xWZsgv-a4c6+S0>y2Nk zxPb~HI@JoZtbJC@KiVCS%t2hT&%PDSLa9re48Js_r-%c7?ru3Ycue*>!TQ5wn^rlt zIOlf!W|Kw|)S3?hOe5&x*p?_32a~>VHo<-tlnZZ}P4U(AK{$_K|BJElY#jFE*e9pj z`@LyuV5?sA!``~k*zt`iaZbg{)R~jlcNwxhPzRhIv&!K6$!6ZQ(_lhU%*O-WqirDL2`LBs}GP(JkUbtXT}^=5n*;;g-n zyoQ>PvS>WTFxN14iNFh=hTChc^MsL_87F%Xbu zmMnZ4(MrbIs4^9oJog7K%ApSVoRBX4PRrz#&scjAXx@!VVc-O9K&YY;_kIjtBG$_p z27bB)IubL{mzk8`Mw+aWwX2#GPUf*{>WXC{+E-0hihYfqu2v-!+{(csnq*^=QsH;t z_nigCOIsAZxrWXv4ujx0#(4F!;#FajYvjdd$5I|H|Q?}p?8 zr}02W!sK(6aQeT8t$Jw5Bhanp8Buw|NWdf4mmeriA;r(SO;!<@Nlx7h@7Jf4EDI?EcGsow-T5 zKaHAXD`f2gKPE*DHl(+JN9tM6jp^8>JAo>n zM(rx;r`;=4&stEd%#Xr14jTQHg7OqD9MyQ#P(C9#oeXEQJ*Rq^rD(Xh9w0;qdHx*TzYah!Q~k*| zo)VK^d~}Ov&v2f!%o>vR8lfFS4gjDPkU28MSjkvoRpXBnJ~ln@5wSFYoNA z7EwDSwkshe2sTEA2S*kk)=T^bzil1T7_xfubv1Rnu*kHQw-wPzdSEr$+f-22Qy znac*tH}j1BY`OYLFUFfLO*4feVf?FYuFqD-^ItN?KVNm-tnwvYITMQyc2%Oz{d}(- zJ6CEEw)VX+;o0lh-#MhP7-#OkW+)g6-`$yz44&xEJfR)3p%>exhfd#Fv(MQ~fWuF~ zuU%=)G=DC=C9N$kRXjwwU{0vx@_%*7E4SRFdeQbIX&$w5Zc$ zPo6HJe(U3GrD%~p<@q~-F0|}rL8FOFITahH4|>!1?jNflAL}V02CHn_XDAhAW28>& zZMKnI1X@_6R``7%e`(6S=$TZcJ(%{R_sMU_$S+MZDYxIdx_#qS!w<1ZM-10jDu%^f zxagCCRr_=NXx+ZAG2!7?F+b2NKeE+j?e5M)nd$yy6}Q-}kdn9N)|2DTqvq-1brM9*z|eES)RI1K=?zC_T|+ryL3A2jbeZJL z2YZov2VrLA@7uUgWVS^Yl2r8a`pmZ+IYahDLBFp_SM>IN%Z8a)Rkm>7*S@Iu=O0_q zpF=hdhKv_hndD2oPH9B#YSEDfj7jyc5G7ABx=FL?`;+YMq$`71Hp>mz9a~n^PSvvs zOh;C};d9HZMTVZ~z}M;=Ur~$S&1lArW}3$Elwojg@|q(>Z)9Lvy-3yZRLl@c9Qo7O zbHQnCyH3??DOirp-1tHJ^|s%vI6^&@^%d$Q23b74wU)~pZARQ1T~kZjmh$Q>T;EFR z6$|*k%Euqim!vcfOl>j19;*u&nR(*}4&=DtU+$Kvf9*d(7&L+lgnjE1e#f~ic#gF4gx7an-LGk~91RJ}d>xZ(JcQ~^)B zdasP((tSIl?qm$-IGj+^rBuB2%WdOL%_Ap0Z$M5COLjn89RraqlSN2R_^Er2$GgNE zk29n?yH(Z+mAHx-U0voG&AzrVsm-lVI=7_`)qqcM@Xrj)q}svWai^4U7C&&cx@vh- z?3SWM*UNe4?Mu_D7EPXOGa1Qn;>EtfaQ)}^GoRIk4LvQu!Y^g$zTbJ0a)Ns6hI_qa zu~ksKdK0$G0jIhd@|(iTduPuz*NAjLd2oks*iWqc`n1$!Si2`kzgce)`fFB!>E$f2 zMNhMR`N5bm-q>nF+ua}=Z=V>siUz;j=~O#=eK)Gj5ze)41JsY{Wd7}e!zFL41-R&b zdb`bQlxzIJrNSubN!-FUpZk4hY52! z&c&mpGoD_%gB7vQe+%hJurb|l=aJT%c39c^J{{s?dframt-&s8A zhgyFsJimn7-_aT6C;j5Nm90MHTh2XArVmwcuoOo-LyFEee%rbFgjJ=cWhfY2}xIg>Z)M%yqU2Kwg*X1*}eMIB) zePCm6Zx$E!m6ca~D5R$VADUa&Uj)~2%cZP%7q)h!#+!MJ2ER*ucEP{crIKG7nbC38K3#}i&4@V zd;YtpYcpOE-Eozue?ID+-6+WA3$%6XCu}*oEWD)wU|A%;9D22p4joy25ZPy_`6#3 zi=zo~{rzV>J$%YUacOA`T+KUf9EVs(gp5W%&t`|Ow3V^quDmSF7L1j! zy3%A3f*87;f9a17V)JKL`HoQdcUz@CxGeK7I#uA*qT#njZ_0Z5X8TiOMqjDUZC~*o z4OsQdyEi`OJpXD1_0Scv^{ho>4*hvpMC5FB_KF&5p?KnWFmtyt%>C@h6f&KsuA8`5 zDKdM!?X~KMOeU-6!S1`SiKWllg>FqVc1Mpr^S4)RI_ft7SFer#EyE%Fn!xHT#%o)A z{YmRNkxQ(DIZ^W?K|jqaY`q&A-JgdEt7s|3O+WF=BnjhOE7)~^CneYV(l1egR(3~F z2kl<*4%M#786Y-LW}LKP4k@Tq|Ae{sYV=+nv+sGL(@vLD+HES95X$kCS#(Z{%AA?m z>w52fgJr{=>~FNCna`epWzLLkmK7HJNA%o=7Q0@}k*%)RHqG!5VkEMTA4qDWzo%bI z)?vCaSbbTjR096WnOVkLVB^Tm=0cQJKVv_luc%$pa9I7W?Azu~5rf^q8ay`{mv6A7 z%{YJkJk!`fynfTw^uVTUi}bUv%IWQ>-p>AmRC>B3EqSlrWxGDO+`a)9k?;N_wpf_) zJK4n_y_8}4y_e{}#GQZ^-iF`gtyqUUot-7Zw4898igL2ZROLa--5H=i_o~Cqu^8@4 zH>9I0Np_!ov8B2j9DwXINTZdZZaN@R&Udx>^ykr3^+Y8K7rP!YoPYfAChwUF;;i_< z_{#RsItO_z6B$WvW{U!^p^3<1ayO0)%WwdcW!4Zjy5l+bcZX@F+174pGY<{+$y2gd zijIEDh#tM&`r(|gd0)ELo=a4qjjx08Q!%ZV)Nl;syS8HDZM8ODa^UaqENhhemtPBp zRavy_&BpD*KB?D1CfGZD6V~_NpBKL>){63`!_i!npYQ@W_M3VpnWQc@*YA|N4AwH^56Z+OUy&4FbA4+mrdHmzn<}StP^Ow*7@Ne z!(wwowEwBBuJ;l%p4vy04Ie04Wo_m?40p;SO63QcV+51qO!Ez=*9%p=UpA?D`4;nO zQ;60HnfGA}x8w0YTe%`2e=uR21L%XLF$X?7d0jeRuGJu#o^i1GHEkwmEDyGpRD&`~qP1XMI9 z01A@o3nzmF5w6BpI+NaT*q6#8PTz#PZ5Z7@9J=o1t2TN1$`Z#s!H`I2^VeMG{ z5}tR@@bLD-EAH|Y$&DuW*$YYv3%Y$t?CdPGF-i^G6P^aX5qet>Dk!U%!hRTyG}~}j zqH4lf7zalOo|jvkiZ(+yopOa1y^~1P2FXtV!i4+Ve-K2p_ke*O-k+IA6c1Y5oY3N$ z8i_`jubrDVXE@ywbiJiQ*HGs61-C}6IZbNgKlQtzKgp{bES?}W>F(!cr}N}X5}#5e3Ig4$tW?fIbm^FsaAdXq}-g98^f z(Mf&xG+dl8ZbRam@1}0_y172zq2OJ;eA*?5(o+*9USA+Gq_=$?}mg(&VF#}x&3YVp{aSr3>TRK+pF|PwN8{L^x*;ln% zw0Wmw3ZzrSZJXD!EiQInbP()^`_}u|=xIhONT~?x){2|o!J1qcR7X)-Ik`Ds<$I8& zLU&FauZ;PPj60mz%9=AMi;msQWG0bGK(2ggubu7QQ_9NjoF>|3&58w&8xRSSE#IT z+upnPHwrV)j;g?4y%|Ts-wWTbh_>8#yek$`GPof7^xX5x3+d2p`g5+ntXDPNA+Dg~ zk2}4uC@JjL6-*pgBRK(YkUqX{daQyHF%_CWH&^M}6@X77iwqPhUE1wKKUo`1TI9x~ zh8%X=LKrp`3h#wd+8x=+Y+ERJ4REtHZN;?0S!wgQ8~kPtDK05*aohZ4BAa&;r=Fdz zh$%%vSV*mAi$8d#4653w7ay0$bSTGdJO~!F->GMtr^u8M>j+(O)IVP9;N+N_DLhLC z-3&vEiQ@F;D}^lA-A0pI?6|`GWD`8qa|a?`Hg(ZHur=MvF*$+J0%2-jre~T#d=oOE z;Vn#aX*$!zk7g|QmfsUtTKKL8R4iaq;mVlFDQGa3G5zcNyF3Z%>`FEY{&N}XIU?V)Jc_Clkqrk*K!x z28~d@?!Ap+hZp{&9bYpG9$~BN#4SdnPb55TM>-Fv>pL4twHjZsU477dvx&)0V#A2* z-nQScy7L2RY9qcvgL`1gb4~d7HYc9eJv(;~sx)(X2uypsInJPkf#HXynEvDrfizTqD4TGMb4s-h+EbnZ-d3Pu zJH%?pX#wk;+eLta%Cz+oJ%&8DE@hrM{U^CWAvuNkMsKi<4m>Ibq}tl}apgPV0eNGo zx8vU%s}-psI|}FNbE&PHW9_S$^UJZG1vO>MTW`rr3lQ6yXW_ z&z049F8)9i{-0q#7(r_SZCXq7_9Z)mfx#NR&b)lo2cfG7Tc8gg-k|y zU{D`xoT7RQ-5ptc-L?cZWnn1$C0N&mvZZucdo{nkb0o!J`3^%w42#&B*_SsJ75w=h zT~?K&y7}t8|An8q5xndV`jS!O5JmrOvMFl&6Xw z{~5sehw}RgVJE|c9p<`I6&M(=rHTDJ1&le{ip-)LN^a^8cTIZTfRih>9_h`|kv&Az zBi;Yok0=X=%NvlcXZ|+yLoo02i>=epUa@OQdI-;nv#W;33w^GRe=2mfzA+z(+NR$Y zH7IjeQculn>KAn_GBdKH))aEijps|3?3nAMb03r;V47}Iyzx{&mjfa1nS7j3oJ}1K zEyUW=)bs;5MkG}}E`wUNI`ET&!!whaWA@kgZ?|z*e9FVvgrGak$jv4a*&V(hnm1-m zopcBTbgIcXFT{uD+0Jb_OFT>6=qCrgGYMKt%!IIzIX7(Lum_tWd(U;Uc$1b&WMR-0+%aI9GAfcRe1NZhMwnymHb|t-p8{j7U5dHj#Wd;76mFU zKiNnYwl$e6b1HWWLYXcIqBd63u!(|6Mn!!trQS9E;YM6!X<0%sYH_DhS5AHYk zoiGq@zPoo7Q$B7VOmA0^@{4e>(wu9Y7GCeA?y1odTz{O9Y(w`glq0A5 zbz7w=f|K^zqc2{^$XA~l3JDo78%x}vu?vQkCEM^G@#W>|SPayx`~0LGFH!dOteVDy zQTc&GivjNr|A@4ytw@1A9DSjqj|g$7`z^?Vx7IH)kUZI^$K|vmwrsHgU@K2}kOc2y zlpXZ!Y09LzRdIUpE8@p4UxiI1TS*8nZ-D(DgxIMcapi7G6tq&QO7AjLk{^{_aIvfV zF!OsIHa>E04|tV__tqPJr)P8L_iqRY24XDag9~bG`)n`R{xW0v*)=KGy5?buNQ58$ zHDR*}+Yv0BEgW%4%$^v13lDo5k^Y6CX1R9HquL+; z42=D{fYsFEf~cRFHP*dA@VH=ULFV{oy^s~pxD4jIDysOpp&Bh;uoO{%Evem&tO@Sz zH;5=1Do-(k6n&#C{v|PmYCL&oU~z1A9Az$&mQU9u_Mgg2Q_!jlAcp+VCiE_=<6%Q95e^y1(9CCn$Ji(+pm^DT8}`Wots^98~?=egb$J z(K+YqNOrA@F!H#GmgjBdQJI5{QAI?L$}8MRNOspweQf03e{r)}-bk$~SG|kdK;A-d zu+k-(H7SR7IV~{x(V)RMKoIa^X9vP#b}pg$y8!f++#%3)QTK zI)}kpk!t?*V-R)yoh?^d4jB1pd%n}75o(>fr4E$~Zr?4R(WyHv&cundZC_}Nags*n z#91evd2=cRCa&!ajNyWgqLr=Y+IZF83-}KmS`6NQj+l$Wm~dx;PRHaHc$x(x^ESfx zwu+NU`x7*a8a^YlESFy5y1E3`WIE$qvtS7+ozTnsk4ev!T&+leUg43fQ zIZPE}grGRsdBMK|Ayi5Za2*??ZczC4C~SA9PuC5cO^>bq3ji3bSS|+3@d%O0;$UF_ z?+hP!ge9^vt~gFR^^eMe_?~8=dALYimLqaL7g1?Ba8>l+B-vkTHCF-2(W`XFYCq~7 zEVK~ZgGhcN)<1(9A4UvhA0 z{M((!;@?MSD!u>Y{{^rm$&2r-f>T!Jj=e73f93lHy4{L%UupEEvu)6E8c9xl!oL5k z1Gf1meCDvy$m%rLovx4|RxAC;_;^m{{8h)~c=q1Uc{*Bol;*S#Nr1@Ue>Rd9r=aDE zvgcn~Ujl$RTf4Z>qK}H<6AwTEJJgXG7huoW{$UXU9?ANrQ#)I0w0*Bx4bu2uog&NW zu_Mt!@a3ZW(e(GhSyzhBHs%ISanzrix#}1a|D1`VU?EjDf9(Pbm>CU<23T5g+*M~E zK}ymO6qxeGmzG>@#_RD|~kb!8`uD2&$tx@n-s{n^01xs+hU4Ab&(a$fX-mryQBJNQ?h zkVIfvL4f1*r9}E4OdD$5V&qHI1h~Xzf_|GOp{IxbirC}T z%Er2okwXyw$(^iwO?yi@;OlRjmljX zT$$2gV4ACtpzdF(_f}r3X(;ZfKMms2oD0w9PP$Q3#0k1;;Pv$lhCVl?xa{gjr|9NrjCJdro$(3atkld-|UJ=79$$XD@NezRJHIdIAOKX zqP^F0PD95TIcr6@k04)>Chj%=^Ig+9Ii z4=?-!30c*B;hvkr`R}4=lV9P2A}4s%*F6LL_d2!*7sTN1=NC(nu!o15-DNwiYGdDA z<>f7ZcXy?)>(+a|b-DqA$WPB&^xl6SJ|rl$KThF7LCeqFl@;*8$z9!*elxhat-{_y zt_u#9K0uL3g@NeSFmt(0fSGFd9Sq%xro|NLw=S#jRK7C3+az-VMYUc*k$24YAK>M1 z6VmJEl}YH;%~P=-V&!-M3O6C&AW;Lyw1c;x0L-VV^)HX|chMEWH1o<5BcH!*4vGsr z*0yYW)mFHoFL32YJIB!q-Y)4; zn`nfer@H(#2{1~kf}9q1z~9@kSD0WEy9?bWehJ*In}K`1myMI-Thh;L$0WJb-zlcF zlb6LyNgG$GeDWC;Fpf2@`%=XS_0v7sI(!lOPeb!x@sK-MeViW6&{`;0R{*JAJ6S^lItrF8?C2oB`wIKl%JNTy)Y0)cf&bnoXh$;XO|89{OCdb^KrHlu@^dt*NF+ z#9@(`0d<^^_chrE53gLFNJOs z(7qg^%>eZ=Q0XE3%cI0#Od%Ot7ut<*FG>CdX#QUgf4*VY+T+LSj_+X! zQ@vlk)qjPr{xqlmq=WWux!&_X86y_01R6xAE~i^1nZx*Y?9YJco2E6RX+KJ<`#vB{ z)5>bU(6~C@2u`3@4_@pnQkYdDAGCX(k;!U&vWWl2%ex~+lM>mN?tMnu|B0Az(sT*t z_c!ypR6hAKZMW{d=kffnko#H!LUa4ebI+ZvAdB`ep6;`spA+@Xl^o92i|GTYGXfV^ zBz596iK@_*a1M=t@oYM`*91Z+2}phSY<>#?i-|R=Cw%o0A86~sByHFfcK{ja*8&)x zg@shb{AtbEp+>`6E*--!)P=T!lp_)fcQ~ZO2i=MQpdKl8&@OYdT0TXGK2>iSG1B~j zs9nI%@y*CLS@0LGUp_AivE(lTnu3MoiiYKP%a*Gw-82zP``z5k{Bck`j zXeNtVu;>fQPaO~GIbck*d%KGGBM^C;4Cj60t!-D!&sfp5BsR}xqRz+1CxE-s88j?N2spCs%AON#CHnPU zRKsKZ0>vD@PZiSvmT15PFnqu^Ys}PJ5Zll-1%CR}H+c)7 zvh}^<6~=+pJn1g}h@kq&1@<@XXP%9&F@}x8s&3}j9J&)~AbeZz)rak?Y_oF~^U3B6 zqk*52=`HVI;p0r#Zfsa|@CQ7CgUYDv>|#x9#-Uc(e}5|&wEst#2yI+YOpnH%^XiXQT2N-Q6Jv$!PnzZ^03{+f|7(P z>7K+BU8fJA{1fA%w6RXKck8X5I;s~&TDzW%Ngahx1(Cr_`$@8Rk|2FrQku@5gK29^ zlIZRany=BFXOekN$Y^A|>X$IkOM2%zJ{FZZv|+{B71TqbO~vXY2V^S}e*++MX^it1 zjO&_@ZAjhS4pTeYMi$Y(Pi3v~DKC8dj(w(Z7C%q9)yURyHJ4LXloTM3+`7ClK3*{n z6l)rR)@=ld8_0LAl}NM&;7ytm+md$3`h!BEsuONy4xxm^@+-`l@^{v)@8aLLr+BXc znbQ`N3wc4VdAU7C+Oql51}ZZ;art2oeTBzod!^sm3)*I=@M1yyxY-9mtI4jVZ>fAL zU)5<>7+o#3O>?UX*tuk2RhE3P;(P(p8Bj3C8N_f!L)KkQr=2?K9H*=+Y#pReKNjpYyIY~SV zu>FtUr&r*Db`x{Cm+VG9i*OGzT!tsGyDj?dcnPkU6_lhP+VQ4h57pC!S6Iuvjp0`X zZn$N9m4%@1O8Z8row*#}e#Y`UMgcr~{>BF)R=;MJr|94+a*ZS1MQ2l(+;-f*Y8GTd? zxz`0c%I-kDcvwr@Rc?{&lstJr-TS%2N*h%(>fr9C<=iCsR`77`albFyP=73nw$`F> zAWM;VN1(8P4SzB)zTy6b93Sv`EMInQj=`qWt!&EGG3x{S4UtFBsi(mrgyRN)0sSX1PRdDCnEKd`A9RJYcH6128pGs5T z^XVdYfmoFM;Jp}ZTzI@{RHVP(E*?JPH08y_XQjzL+<@Ffx{$v$F+PrGj4krp zwT8coaxfJC=6g;-jgOOhM9}UGmn9Jvutpum1lG*9L2WU|cpeR8k@!1-)SZxw?3U&` zFqd~W&e0GZjY-Z9lBxtxR#3-#BazluNhRK#=VN3gJ_d

    j^PUvcgOw?*~QV zO*s2OWX~5G^N^Sl1K1N6=P@Sr%q>h{cvjFj2#Q#=MOu%(cusTF{H<4RN_%@jgv-+o z%7FyLMY9iumshR5oh(}K=*@BDdDqRob|7}*7L+l!z?-Gu%4vTsqIJ*~^TXb{M! zLLU$x*OMI0(LZAP_e=Dh>}jYM!y6?DOn5JMiv=EaU1x;)My*G25W^=WN-P&(LcUF_ zDd^QHj0?}_T{_{_XfdIq>OO24DKc2NBO%NIuE&E9f1RN_IJvUfFAU>*p(&6u#t$dw zD~Ufs1qL|b+Mi23frYz+K-I%g#FONwSlVQI#w&}i(|b3){_R&Z_=AA`>85`tX!&n4 z%9q4om{B*hl^t>$jo2Nu$elfQ9`;vPs|!Uh153 z@$$CH^(mg8c5D&ix|=(f`W7ep0_X_4(L7-pJ%HmGY)0Z@fpNVGe9-@0+30(h5i zYZ+NuTKb81^=-(b-)(b5ebcBZ{DS-ozPU`B?AiPTmubG&3XC{FGI#&}R+?Wvj#$M= zzND?vZto3Wgnsox{vm9>W>*JRvdT0P^RK$1+8{`y&qbUeYgbiDfY03x{yL@hX1)jHJ2+Qg71*k#SC{~Y5jb_T zfxNB#A8ZV6-mI>r))R4Gx?msMzJ`;lz9vo^7KK=jq>k7! zJIgBtSR=umSevQ--#MX(%#T4dpYmKD#(9B+lXMCXwFj)&o>p%Fgq#usvV`d6p7i_; z@Z_-;Xk5#ePb(pDrEEMm#`QdoagW>;^6cn!m*JoolF+-uQExiG9R3QhgiqhN=_%Cm z=Vue0qsoWuV-AK}!Lt>@UVu`;nY6*7JQQc$6lTt*`awxj=-_JPu$hHCiUtY z!Q2538q#o*TEzgH-cT|}s#KyJ$WhaVZ2r1SUinDo?hA_Op`)GDRwvS4LQQPRWaS{(t|ZK*B%3)T5iAXk4tj0yi+BOz;YRh1sy(%C15@kY=H z2n9~*0XLg1ozHY?kRn=lRXzxQc#A9OAWhe6uVfiNPQGCDD^HizoW!;of z!;R$;F)hRl_P8f!nigl9DXVrS^Y@toJvcepITqmVm0fITFEC1PdxDeejYRezgMS1* za7S((fl_2nFTn+2X`s#16_l>J1!5)g`Z*}rHG1>=&GI;=qo~>u*=C+CM$AoGH}X*l zX!Zl+Eta&G#0Yzge1_=CZ{9Xz$4>Y*%-mt{4Nat|9+X{}AsLZ-dt+91sJE*9+(I}L zEv-fUa3P{}gsw$AxI5yxzR#_%JCIs;Owf2?lVyap?D_7rs0reYn<(NA>i~hj_W|Kp zT3-5__&Na)g>Z22WCnNFlXPA5z_xIG!xlG!05n#3(FKMfP^~x>uahg2AZVUcrM85I zWKM`7NLvDRE-amww9ny}cI-9!`T$dnZkAJ|40oGFoj4zAD^-tdg3iztj8M`DBQOSb#1lpsH53}h;ij3qJbn1&!y^HVPicwK?$ER$54f?8O zCBV^r7a_;V=`Vih4eM3)=kvw4$-k}EWxuZVAHbTVe}!`ZNEaG$XXGr2>zihdk7lwa z?Fq!%9r?o%dE&nXW6O&f+X8qt-e4K@eZ{-D?%op14c<8*>_Acrr!TQX+)+Zgt}prb zAG)X50g&DuYM$x_laS;Gfl<$D&s~ctv09;2`jSnbYE=KH?>F5dZ<$!!-p^h@Vlh>~ z!MvVBJ~+X#a5=jeaIkdt?Kf(Dp7U^LyB%Icip23jQA6{s=qV zIlJwYqCdgUvezL6Iwz)}r^P5Y4!2POwdgGrJV8nNkMir`;#m1FeL-h^3papXfX$*3 z%udmRWQ#{n9E9D|%&oDB;*S`Qq+Yr!C;83$>(oADrf5p7$w8}+7D^V)OZ@~kWnKFg z%Q%{Q5EUmKGuzTm6k~f-GUwzF)N!A-k3cNj@f>5kKnFGA&0q@L3%W7E@-5I`Oz|u` z^{FDjXyp|XbV1mALVHdJs7R9j-ni0lrgvEwz}t^?p&F)p5|d+g4?17rUSeAEDwB`R zb#_~!qQcM1A`jhDCiqgbqy%3|gw0%o;7fVZ86Qu6TRT^|8vkZPzx9%XnH0$)mABSu z1YgPyV|n6uA&W>`0=bp`OMn-CClh%MrEIat9Pl#DrI8LBNM_zBski3VtRcJDJol1>kS5258sat-VuSc#;5Vgrr-W9y9(cxvJ@H z=l{@A!hl`M!q+HbmMd{AbZ<`CAfHbxpBAY5j4$$z3f`E4jO8}(#YDi-u_3!Qc26p` z*P;t@Wjhe#Z(L+2#Ph6AX`#5UPJ3y+g-`w=KI!R>=N>7~XRvGSdClfZxApW1#hycC z_-{Bwi&2P<`Xmz*2Qw70<9@88@;sJytlsohyLU6vZi4gqkk2Rnfs7>v-@(N4;y>Vf59KJ&Cb?~J-G1#@r01akZ?7K z|BBmw)~m3Hs|7Ef-eMcv&88BIT{3MzepLR13+f~dx%zMUMs#M_+gfAKW`m#OPVA?0 z`w=%t0fJ;47DFbs32>~Ci*m`r`zBS9TQ(NKbhRfS!-{^Q9L*i%VyKy8dZBheEhJ6*=_n$D>t$KwBx>nWGiH;cr$A8`D>%P!w4IpQ=OGz-R z>{uYx3m_*AI}&NXy`kS+wRPPHl|U9a_bVXWpsc&+M0{fEpy8iRU0T+ZizGEAAT(Oc<{tyWXBSY( zhV7 zm#3O8J-wqGKZ}5tx!DuUV}&SFh;=2`H9U3XS1&YsCxj{5}&72nU<-trm4j6 z8F+h)9Ap5ycpQ2&_69VCM>$QnMa2|;OAK!iVB@lIpFzGVk*pzW_hgI_1uGFUg3OnLqd*2uI|iJQ2&rGGoyVf zHZ7L(Pkd_^TK2KX#Tdw^zOIXtP}~&ieS09V$3OxC7}}Gh!_GFbK>R$Dt})jHmB7-X zY3=ts46P=lp+~$dJ_YA5yh%DDnVd$jxSVx&mR;ppDt5iv?)m9xO*XEpVK%gOc-1-| zSfntXlL^LIRBg>+#M!U7{keBy-FnT4zN z(v0?c7i_k9Lf*V9moyC?xQHog8#FO2xwM4u5t(S+sU`+e?)2D<3i~c_P!}UK!l@sB zYKSE3W*^*wGmbi*VNNZ;iQ6@`uH`q6NU7<1KDLMH%K9Wh9)4AGe!d1d*2v<*yAU;Q zOU>9}{)fNDnp&<92m@pJ4-oyqgaQd?&v!NZbe+@R%EfJX079%YVfNUS8{4+6;-Lqv zpcn``O@jd=B{rCCh-a~fnahu1OknJ*W)7yoSe{~+p+VV4&glsn+d~CeK!W?u#U6^c zs_2TqCJLklHH!|GEvE)$PZ%w-mPWS6uGohnY#%Be+YT9dE0M9>Dd(g-dAl5IZaniY zn`_T$>`_SckShMVVU{(fKxFZjyQhn}@XBg3-{>4?SV#EH5pvxH1saPX&J#0-6L;zW zeR2pPUT8V+9&CS+kGgV$`!=eu+fr@w^#oashP8r8&dDX#gnfAV928Vb8PbS__cPz{ zN#T_BkOva5J25oR5J&56s&KJEyT+Ak{DQjX-#CgwoZRzWEOhgCq(2IprO;VX)|bF3 zE$%|v!qa=VJR3Wd?5V$KWmtF%q#tO5GmKW<=bdjKC*_jw^-OX**2074nJq#=OIa&yoA|1t$4C3YS!&%tQk+p=nWQ8 z`K&+4r5oti5Ju(f^em!G@iuRZZc*@Fe2PX~LcyUFxjM%A_S(NCO4ZV-e_#N9nWOf8 zzDzSRY8E(U$t%@-4jC`2A&JdF;fR4k+l7OB>{SYo=-?GUyu{LO^V%C2+q-~KEHmLa z%sQADjhELtvq3r1ifp$|;&z3EZoexgX({M?ZgmgknbdUCu9=0V_>C2H9xpHY6Edgi z%O~UW=k3CX(?HNJS5Hg+HXSrb5k|q%!o?4Qb`Ez>RZt8BRLFe`9{F*tQglebtk3s* z1AsjgA(-bxkBp}pwLN7fe*lvv~8o{4l8nle)xr>k{Zjrfm2wJ4YZ08*%7P1dL;D&`iItt`>`x$VbA*1`if91dO#>W`Kz=tAav^HkYiuW*mx-Vh)0X`FvDBlu#i znJWlAs;F+Xrj1*vic3$Q8F>q-ic)bUVLCy)$Y^17b3rGyfOVa(AE;+c;$4jIjM0wq ze=Nt`=B=RFx~@W+*g&bjy`LHB1A00xmKztnCbBK19K3ikK|~+yc~BE@O5aW*5LC)} zZv?7vPuRce^A_X>4OvA)Ku?^x{@{O88Fj3Kl; z3`d<*rHYw3)i#nh=qjk~iIx?gT4^DI)2ouJI+A9KOSnv#cs*>}$Q%R!G! zQ(f&AmRoKu*J7HvI7`|@_p?Jl5&2M;odv%QO+to~2NTGuN8GTm%^e6BgZ^lsD(~#k zAndyORF^NgYKI2v%&jKhCcFo20>5v{Voys*&P@h`ZSBH^ly^FFti8NPw4LAu#UQ7J zgF7mA;by?VjX=jaMwn2!?F?6o$J}8&%O{yexaw^Oz0$@pZ&EJ%EdP;YZ$T;X{x}c} zTu6OHIfYYz= zF?|ge^woe*#48DDs1#HF zXYc*boZzOOZ{dUnT#)X!Zr$sq_D|nKzk7du`{xp25FPnGR`x!6Oz{oY|8(PZZ~(zx zTE-tYo-JvuPVm-0KRNJsSw{bVFBTzrDfFDpMNo&o zNl{uMKL?a_*N4E;@l(0erf@B_;zFT+pYXJ4D*>F(@pt!3i34Ws^>NV7KQ86}#u`fk zH9yxP*qC*l=GTTM6c{T$1NPbeU9lSLVPFaPyWFkS2$w%jL-|qSZ@F8q?M1Htuju0c zLr32K=3?!_*71ksGv-=1@WSM*m{?4V;Hlr*Zn__NwJh@Dczs~G&+A>D`0AS5ttU@U zTw{+M^ZK+*Wys~z{J`h+spB_3(k_ZVe*W9Rg}DH}>>KTB+MVr5_bItg2t7D|^fuoS zAnzP>%hoDfA9U->S<<~%2oyA)JGv?BR*UyCdzW%jDhCb|hLj6o_#Xnx%#Z8;ee_3L z{2$vAs&;teO_w(S9M1^;VlYGqHsrVe_tAmJ|E(>NAqcZW!5Dy?`g+?hrf8C|h@Adq zvETP2iYSDVIF4@ikI{8Na-HwMYibpS79oO8`=_V8W=|)3aPUCI%PrI1Qv`cYQ0RZZ z?%mmWBXZz?C?OBkueZQn5gmA4|Ca%v%Dfh`a^S$~8DL*;|G)^3Gv4Br&K-DsjoWC+)?G*TA174NnrSjg`0IzjeFDg34ON^zr2YSZXXZK2VsA7AmEIT_J z1SfO~&3nL+T|I;4dlgW}!XZd^JM7BTxQV^2tStU((Cg97Kj6&cB&A(8vIEx}z=O54 zv?924O5L$5AcskM;quMNu zzCQFwnR<56UYD+lz%ZDE-TOXJkbA>z^XtPx0q(UrhCeDm5ws=ka^Qe|IjDexg9D)g zCAL#-FuYx%0O72-+wB;foQg`=re8VWs=)DuY4`4Q)589^U6F5&Vd~(4=T2WfK1r^0 znD0%$r$i|D)A(uVsOR=#IET7_LIc=tiLTtv(Sk?*Ys>Ql(+d|_kCcLfbLmy$0K!$X zc(b>bi?$(;mN}s#^llWIb*0?&B?XQ0H?Ot@uTH?Prh@ykb90fPwX|rTfnj#>(M!ZB zfUm>B4oJU*Rt52$0xe2~isf(a1*m}Jo4t|41{bi>Dz%>l5^-IRwR?r^=k~gu9mZq{ z;!7RU43y$;h6V>gF;jY_l%Tjj@Z0r{G{QhVKQrQlw6d}S0;$=IdznR0WKJ&%NFWcK zzSfL9%3Zmcw8_J1IZ}Er+dt`FJO0Hc{RQzJPFy4b`riH`08=@?YxQGvG5+Uc{vdeZ z_bcP&ULU&>_TF9m0kp2)Q{EeVAq02!C(D^8v)89HU^nvq6Lzu@*$nbiqne}p^k6$c z{Dzq5=Kte`uN%HkJ`f`yY!@?WjTLlSx=$HvbIZe8hXqW@YhkP~UKkz+hgQ1O1=5VO z&N}>YGf4wLp*}FueO;ZnWzId$wKYv&T(lnxlDtw)m?uye6&XSU@XQ zto4>HmC7DAp;JoGjwHjdJ8gy{ZL z-r%&h>?VT7*JNc9`kmL>E8_#jPc+iq)4hb_Zy)pif;bK<|9|>wg=}}z3bgugLm0vZ zsF;^Z=W{?&ftt}t;79YkR*w;OS^{-IgRcqcEdEl-=Lzw}qptIWwgZ94pDKBvqLa{G zl~|NEXde*L{iU=nD-iH1YVn&U%~3W$zN+`Sy7`jlOOSGBjp2_;0!m%c2}VaQxIG&54bWx&rL@iQqT4>S)*nD! zYuZ!_f1FKt;B_Rn9)_!*2L%N`hyt-(;?`?P@``)oN96$?<;NQQQ{Jkdl4n=E+gm(W zAV0EN{q(JBJmFA7U@QLa=H$%u+3dl=di;bN1bM|kO+lvM(Y95H;niHtMU`+3f;9m% z>!;+8f94po@97m=uRxEizA4#g-R{^Cz0^^ah2DLH&ko35PnWs;eK!46kUvXT3f?BZ z*)i-E$pzGCOx*TmHDhFA{qJXTdLYeFMuiIZ^uN#1y|-n&*D79$gIjBfxvp-4MW2_G z(|2vFoP=@rOu^=HG*F*D;QDG;}zJ{fPMa`F}rh+|<&2Xs~1mWRuyw=>zq;@yw?oTwPC8J3AvC8-Un+IU4;V zqbi{hGv8z3(|uV3f;LrN0}y1nam(2?w9oQ6+;RpY!5z&Ui5~))g=(IRf89pwMT)~z zz92M4F%5Hw%BeAKg&of)yZW0 zANa*(S7TJow5*}x_-+++jCSpK1ZN{BAqyW^a2H~PlT(aq9AqWtC)nTZ4(9fCyW>mO zKa#3KnrQE~_4WA(5HeJbTv{f2yD6(&dGOlmSiNw_j#T#;nRtXnRd1Gu<*=6@=(2Q% z-OXA2&US+B=S#4iK3K)0u?*jHuEs4f*#T6dICa>XI_xVE?9uuFQ(v|nW=E0w{-bCd zeUis|zDb&NWq#|{uBPv=(;<1@hbAA@TH!SCep)Seln1m^p+&DdE^mX(Pda2L#SWP} zI=qo-P%r*+*MCzuVR$v46Ya4fzAhi*j;!$`ul?3^PWAL0m`Ug=LIYKd>4*C8pTjcb zM^J8ZM4i|vL40F^=3mwx3eNkLbYpu&tp^bm(wT88$z|9ZxsQq<-qAz zAR|N{iRRsCTCLq0^2I)n$`ll)nCnzXS&ZN8o!VH7MhB)_(oFC9nSp-Pz{sDjxU=`A zc5UYBT1ny>&lH(~YVo2YFnxUgTX$*->bdg%8V$do8stKN3W-aw(t$}I2_JSHy z=)LX;1~am+&bnKXwMS;f&WGVrqb4_fr7Q|~4XJ){X=y5>HX%*G zvCr{{W%AQX2_Lo-YBCQ=>HAlWr8ad;uT))6*u@GBLOJ|}L9Tu^r+s9~R4yxhSj6|7=#XqXR z5rSZJ7v{P@nvg|wJ8W<;c%h#%;q`U%*YlRaj>3ek?o@ffsaFX&!~8H`RrP1?24~Awvj`P=(^FYQuj=$qI)@40PA znL8C6ybH4OT77GDxFuev5*D2o;~=T5ghA zRqm{V?Y=v`Tb9@aD_^n1RdF4z%`hFO1TJY-f%5g#<{%N-2fO2wP}h?(Y!1v7C%t`+ z+y{v=OK^9i-ZZi>9epCmqWhU|8Y;n?eH#le2)vt?H4T4(xm|jNgd2TJ>UalQ${T0z zpVkgdC{bDEpSmcd;>={xR~doG+5uLBtig>zGavu4akpa3)M~v5;)GavqCvsYaF&f7tkvHEYfL)!LeJClc54R+?dC zbQp(OnfEgXHFR0>)u6c|NHh!D8lrDBU8$!D2b*UIR%T9Gh$>SWS z^N`PX{p-zvXbc7h84lyaG!(L9+%hPER%Y6|5B$5aA#mU_Fnb82CaS&8)GA1m#lmeS zaz3D9&>E1pc`^&<9p}yQDQ7qX%%S33P+L3Di9u(0#@{!UA8ifbcJyDVhS*L`t@K{g zF1qCfy|rh!C0meu5C*M$R5&fv{mW;LU8|mqxL!3KJnL{T(R5v;0;Tejm`-q@jiLC> zAQ=$~QP>2TWQh0?E+x>HlhEPte4Je9OOBCCP`o`aOeIjJqv7H`iPkr!SUBOggE{P&yQ(1q39dB~_#Z z=~7ba&<%%BlsJSm2!~KQ1O%i(xLX1+7?&U@$H;d%D6_u6ay z)^F8f@}oqS(iN-NMqIuRqqXgQlX++UXW|^BFVk_BZ@k#{=V!=#$GDiwf_c_8eT`b$ zb!+L#0Q-Sx1{*0sv$syMuFm7};3H8dU1xOZuNz|P8*LpyI|r1SRX zkJ;Eqp8mK*tdCPwtrahga!Ifb%cQlCrZzraQ&a6%bIjOiPgNyXTmSlkll|!zmf=pP zmuucFeDW4Qocl!_Sv=yD4vHhg9(;cHauRlOI*#0aN2s+^O#ixkz<70h6%X1bQ|he0 z%0x+av@s0_;v7NgsM=?3vOm)2rU=CiD_ZPYWfjOfT_at$jI2~GT%m&>)Y1WO%OtCx z)8)WolVdknl1p{@dRlVwCFmxh_D7+xcT71a9tB>R;o;gR>&Vl6|f}~ z$uaGu?PrQ|mW$=o+iMXTM-Zsc;TQ(A%s6YZ!B5#IOt;c8qTtQm${+xhH!*x`*2{|$ zs!m`h9~qF&$vyjXew;@wJ9W_U!`=qX=5hXTGe;!il$@NL(k18^N$K5>n%|ws0Sp$6 z0(-wEcT)K&)+Udv4|%P*X4`mUxVG!=rNdddNxYbnp}fqLIHw|Dz7E9|qY*=C%<5x) z*T+AcL44ncO2>tSHtw;5s?Sfy5v7&KLe~ys>rm%9dgSeB>X>i(IAUc=@y#W2nNe17B9*Qby~&a-W?7Q zBEDhenjQNgYJ&2$rq45r8Q3!lVpR`iIt#5{&&~TMDF!=2ofZ8|xuR>gL)Bq>*3`N} z+6p}!TSpVSZJ#Jg3O4*+Bk4I9k8UfPc!u09Qs1CyDZe@BODbx8@vUt7ELT*Hsm}Mr z79mKjxuqzH285F6Q?^wGw?^@NM*ZDvT_j@NPjQO&NoLXB%G0Jw1L$#A10D7!hr_N_ zSpUN&C*!&LOX@g4RBcv5)+-L0*>c}>0blJU*TwHQ8$aVjKXEZ5qcnyp|l##6u~;qrBk)IHJm&X4NOadT{8(k&mL3mU&jpf z59#)Oz=VuiNv(dQAyv*C;018jB)fR7v;t5|ny$OOfW;_xxQ}3>@Z;>G-5dv{JRdIA zP415M$(@A=ig|+k14G`*_jHPWqr`S}w-GaWw}16sn{<7gHtoFVAKN!g%mp-0uS{PFZ@@gNgYtR8!dLnosc>mo+4IOjZ}clLe4%0s6WhJd{U-q;%+Q z_ILPkD%Px17Pz)Uk%=lDjRUucUUa=5i9B%qI&XNeB0-H%_(1$p6-TJdcCPif@?+%9a*=Gn&rb_jtS;->GVS9}}k1UM1=;F=d0%t9kS(O%8Of7A02MXt~ z^&iIMxUQPKzLQ-?a!-2bwmw`ip1AOx&#OI?yh{**#)iyvtq$8Ja6a2EAK)BUy4 zsoaAchq6~S=qBBOpQe-fM2|wGuJ*~me5B-Lb%ZVql5wMQH zn&U`Hyo`_VV*`DhB0*nl+j@i^Zy{uCx)Yb@bPd9N9*bMYAv!CVRwd+jC0b!wSAwr0W zB9HK1!-}XFU(;<%&4Jq#166*rMLIij*a2)d9ts229ZPmbdBnF}DiWd$3Uy=a$ZF&; zS_wxpFG|oF7sjj}YqHyIz+(puCW?;**ovH_uMFYXa5`jGTE~qYr4+^`cfDM0nsZ+3 zLpzG?8Qs9SaRZ{*(5gJ>LY68==`WB3&n)sfwYsG^c4MDrk6&&s@WXf2&!n61fK8{m zm#(h!-`*58UJU@JalcRHc<1Ykc7DSiIixIkaaK|baX=_3=wfszX%-{Ik62cwg!Ue@ zq)Qh0sqN0F7j#sf?z!URL?a;B+uQ&}Z2+%N&A*Ng<)P%1v4l7(WJ4!B`T*gH@@a^8 zZ5E~jGfI1G(%ep_31#@qz9K~!m;1`8xlcDKoeggt?H*^2X=mg1We#R2|C?|@`Hc6~ z@*HY>C5P$!DWUdet6bVrQZ0a))^eDoX6b5zS5EIkfmK;3Vy z`KTZ8bxNx6`20jOC8#n64r72>wr>gFpV^nyv>TiyBw;DvVLv=oSY2&6L@=N&2+o7? zVJ0ahpbN2}S%IMP9wWr}2h(v#|3*qewXF3lM)py+QvRvVP}TbLw;Iz46=~94aHjc^ zNmmxqlkeOmo~J&k3*?z`m+ijFlCPwnrdcoeT*fXc^lsOGS?kBtVobO3c}BATl_Txb znP<*(Z+UeqU2roQ?%mp=BDqcB@%9?4tX>6Gdf6*BT1N|SLbWSoX9A~hOI-$?xHb8P z(&4D@;YPEwyp@fzC0ndGb!`-IMW#+#}h!yPL|~rxT0#7&1MA$h|8Zq)Jf7so12-MMmg$)uoP;O-f`gS&6LM zR>)K($}a~0V~~fR%rKzf;L+}KkwF{!a_YrpB%%_jSeOZ%GP~lm+|5xAM~VKlJan{_8Pu<@oc!$I1sjQR&B(9ZlF)Yudgt} z<8wydI&AEyowOg*Nfx=>XN!;UuCm)Dd9zZ-Su0{1|P*`5u$t+Ln7d%VBCzOZmG z;e~VN5~vZx0{SNdAUo&P0vycDy}jwaNlX1XNFf9{+bv58%Z$(#?1G)NDae)|ujESt zKBEO^T!ZU%?S~eY(v#$vxep~fFNzn$El|Y9_p8`vv6crw)eSLdUIFA3My@=iGlt-( z|B-M%;%lGDy@SQfLDLCc)1215OY^=<{u*gQw%EJO!&ZtyF!b_yQpAQ}qDXlG<57*( zbZRH|*!$|av{TtoTjf>RSTA+)D?kn<>}i!9h0M8!uDQjT*)!yMz8A~-rX4J2h^Jj) z;aGb6ps6HtW0``Dw$FMKqrq^^K-wyQTa(_I{q31SZCR3VKvs$064abne6L1u(a(wG zt$~^a5iGV1F(biFZ)`^s@O%fmeo-W+;FRRbv8ilvXYExob2I7h5+XG;jGdlrTM6bE zjO$BI3#sUBe(%ZJS#G_@EYbuRwoPuz{FO z_H_j6%kRFCg>_N!kuXC~0-nrCM`xqOLLX`#%{%Om)P z&}mhM&NnhA+l#AjfkT-?=(RlPc{-}DUnl+zgD5hE z+jrM0_X}etFBP`O5yQ|J0q2AQ(GHWXnf0bUY5Vc=rXlGb*ZqR@HdVv8L!q54%YOlX z-;cI6{_8P^G2hqWM@_PBc>AXc)hBKHS$q0EqsgP?FWj1XlHqVgN-YFpzw#JZzhgdD zPu;~Ah-9g8p#r@oye{I5V7!Rd@#k?TtHTiO`xG;2;Qv6V?!ilb`UlYNF5H75hD~iC zWw^_`$$(L5J)uf(WUV^$Kx+eWZx>x#1cXt-E97bscWdmi(RcIGtcnUZcmXu^1V{hf zMnkR#&JSv#PAnI8X2t_Y!$SStSLv0h9aEevdc)l9v#vHIr)lZCO(yY>V)KJn7pL(x zAQ`6~*_*`MAD5FC8k7#5)jHI^g|EgSZ)I+y6IvVM>O+H8)^kWBD2Xzp6S5L7z8_X! zCH%p-J-sTdx_VjSWvGyi0eoKOT7bks(8jYI-0f63L(kYEiC*U^W5ZKn#T5=;1_;!| z`@NI7^o^v}6dgnIm572)OfBq5OlkLxy4wzQt0~h(@L2hT$*rO#&idjNfm7+?s6}RU zZ~C4*GNxs592?rSj{ul8N9Bkt6ky9dDD6;EPJ#yujtm)V7b+bl5jsTu5SdOWF-TS&qSRIsA!3sg^y4`9VmZZ$CEDs%?`M3AEY>UNrNo5@bgs;Q_K zU9{3It-<_saFHSx9?yfvL)L zaBPDcHB$P8)yK-TtgO`yv$3+n!+AKMy!jJ$W;^bCY8ja9^IjBccHlFa(Cwf*v>;!K3X zk(kDlxxPI2UdV_=Y&k3L%xlVpC1N-{9d*BaMQUKrcrES#yIS zprm?RE1vfm9k)eeM88Rwo24Xn^c@M=J-(@Nqg;5?b+3>>P$(-aA=c}QR>8!~wX)}l zCwoFdKZs^NV7Bq*i-bH@+_?-Es-Q{8hQr%hGDyQW1 z+O)O{I5NeJxP7Y!9Y5S2`S;~rc)UJ%#XxGqf0iClsZ+>ZZmom4CTXCjJ~%PmK|~8U zZY6Q=pU#DqSGx8xm8SuJ4D{n1aGvAj1W{|~Ne4G0_5`Lp=SXcAH2<=- z9+pP65YTi-N@>rhwk%U?nvER0kos~?PG=Cwu^*>LL`{Y;1SY!jRbEGW5oJeAS_dR6 z5N*Btqm^7nFl~ZOnfUieI8IdMVNZ&n?QZWlLz|fafCjTd2VSyAy5we^cQy@sn5^eA zk3dxT=hs*B|BbrQEO`@;!v&55K-_n~Q?%pxrw6b0+PHI6r%$iHHZxmgE*i;mIkeh5 z0Hxr#fpsKEZG7vPnMx*KKo{AM78oN=>HwKYsIh;F3Kct3s4|mwIe}=A7TmBST#{L< z%%Lk$oJl!56r7=S2a>txslf3H+hMHSyU>9_UVhmqX2{@H95&#J{D7;pi*5NQT8uJl z@{Wm&Vd~bE6vWq-%7FqTLj~+L(@WRK9yo46pTpfs3o0CTg^=^&j7Ipnv(1`)cmIRe zXXhd2sL%+F6qn3OpV0lYWsl@e^{GQY(Ls~;)-VBAu%rdglAzD{Cy64|78+~Ju=$y4 zZAbK_Jr*TG=w)Ye@>~bfWd^tgzAsuT2J@BG{u4pg@5SP%KzdQ$Pu2Xk=W*O`53(AH zm|Yy!MvlQ$BSn4GNE?vJ=Z&J4Q;pM+2Z5CP>qw-pu`%zRewWGX&@Vr^IXTCV`mmg2 z|D}2psajgbM;;;rhAA~|`j^Zjcw8nu-_Id7K$q`c`E!{BiRqbYYSaJiYe+$`o1N8>ToM!{Tm_ za+T~@cIF8%kl!{b#fP zePSpz@jGJ$vvoYR{CsB3jk6FT$bhkQ{(#y|#`moX|&^Uu!$HM#8`fHJ5qc&A7Gl}i7Ap7Xz-{=fe%cqg^nMsVfh zBOg^psB8q7E>k)gRB~UmhvDyMx+kKVh=6RJ_~`T5sh@u5d;b2nsjoYpBSWG;F$5Cs zlf&%`vp-F@(Ga?%&#^*=4@nC~sK2#g_RB^@Ymef~gHj?jNzA*zcI$ByW=yFwd=--MwQGM^y$W zp>Nn2T4Z!|4vu5<#@=qoclgG*U`sVoxv3zZ^)V-E-Dq-OR&e&lG`2eI_jWFIos@CV zx^&LFCN3dr>hT0#T1KaKgzhdyuGT4klD~a|Q)SIe2*tcB)1@^Xmp||7!_we+4_lpq zMXeMcp&z!B#4g^<`@vC$LNKdnZp6CVDS^HYZiTqqg5{ZieM5L|U1%F7iIYYHmT~LP zp<1sD%#vwQssvdU>x$9_Bo>fev{d2S4 z-1mt7L4Wu}P78$&RLh8kbd|`kEw=>!bsVQX_Ht@x$cA7|SOZZ8=eEmhuddz|(Zd^k z<2h=Z%FDDX<})(k!+0wW6W7qWXRrxQre}*!y?bg>ei#y1tv1G?%TP5T-YJo$bjmU^ zm6mq3RH^1?CYO&+<8ay)zQ5mDt^ql5B(r@zXnWY4y4t158K=5NR-av8kq1)YY7->7 z`vzORcOQ3YHnMjx7PZJfK)<(`zAGk}gtjeK&vFgJx2>dGqJb*Puu(t(Vs;@y%A-{O zSSPM!fK1PBj81kcCm8EC`?vZuDw!EGEUaf1`Wlz&k4A`htqDA(Z}Ic`$Ua-^8-3hL zkws|-b#vmwuxr69RbTEUd33WnZf>X$%09zOjUijWK`nU z)W3J^mAugI$!J@}6DxaXGoy0*Z)&0Hm=0lAC%_rmpbGb%$N{|)3#Sxxn~I=3ohx!% zEnfZ<9c`kP=XWbC{7h~pY?wux%u|bQ1f;gGi)l82KkaQf&|togG_)AR8P21uAeO4v z+H5c^;^#OWUJ5SqLfq>bQ18UJyvJt8u6|=J>J65yM-!P2F^XB`w=c#{U zsd08&fYrw3xfk(Rk4@PNFCXC=i3*f2u&9*9S}nuM%icFBo5hb-UBe2tZXZ#_5qBTp zF7g_bis?66E35ywQlz%gH?Q@2JMyCaHbsmqXN9Qez$52Rdi>e|p+0b!=Lm1LUf^mC zF%-9_vY-2oo|%83OQ}MrvPDVA#XB0wI@l0g+g^ecoL(@GlPw~&-|Bp1&4(U9SXQ{3 zHx6HU5q}*aV)vAVD67`yLB*BaTZh#A1J+4tIzpGE#&kzXw?jR=t@R|W%ozH{#5=`?OpQwu%%09PiPnajF3ZU0786{AV zwnbx!-=E!MSO37HYeQ$_Y>B0^?0OWRsWB|kKpoNZs+vGVYEZWotG=ttfBN3^LML%z zyCJ;V=)u~|>xe32YoYbrH94K?5EK4^7-7;eQQerq61riDID(5-^EU*!oFbeLoam^srte17qG!W*q`OGzng~yP<EQ^tk%+7ukr>_;cB zy#8J|ZW*v&lna?5FTJ=dIaci25KCRoJU@~}jvZ>1v3VQjS)aGE2_gB+_FwgOY44Ot7nzx{m*|_Z5!Ovlq{LMl>Y8^5#IC$BuRI7*P1z_kXevlJ z{bF&P9<0M{<=5v_`i?%2!x-MV=@H8SZ=wv1EsLMd?&}cBrvB@(p^*O0d~0Vx?hA z>^x;_UnHj(%)U963|Fww@s#aVVYJ}h7ORe>B8rXh54r42Hlo1lc-*qte65hE+sE{} zCD!E*7UI|zOq+W}%nmZT3923>nU->EK?9 zI@nQdD|eBg?kkMMo-?V|rAXfIp5LEQySm$L)H*~k#u>iiF*L~AzF=zMr-CVHuZtS{ z`{(RXmx%1-u+&3Xbo(WOay0mEq%dzo;LyS-pdTMmgL4xo%@3>G^x|{s67ut%IG7|Q zZy29s3g4Pzqjo6kz!|0cgF7;l2}uL zL4kIKcfpO9ho#i+LSR(ew1PGi$+B5+*o_+4PsurzEWdorKc zH3F|B=r(`fa-m>zfUJ8V-O3R z&s!(`Pqn6vV+yQS_--@g;g@WFM;8&mr&9A>d}1N1`xM?!$nTS@w?<&u7q7$QY58q1 zs60grbM4kmdn?NixkJNJtsQ8#i4zQ0%Bgz3<^FIcT6v?0v0X4ho*2l+hr1xR#_!Qv zp`qKim{oV#Lm{$3HMY&{njOt|P!J26^YWeL_<$6mvMp<_IAP2NoDq#(2Xk(r7fDk* z)ebOi56~<0`?YW3!%JrDF<(+GfJQ_^OOo+}SbfwF(cCvXyM|J0 zo^-=lO+2&?4qxe<7)B1iMv7up3mSQ7)`_&{U)#T%>|EVVBz0xY!0zsMg}0sC4`uLN zSgHlArK-yl#cY1?NNHS}V^K32*BGuo^_qVe?#Vn8=Uo8y*_27->+Ncup(nQYSy+2tx8Bsi)A~Zw(ffr>t&k!Kb>DFDxO`1xJ9+-|7xz7eGjz>yW0?! z!+E}4L&rfZgqG&XjcoU6>%f!16RV;NSKaE3R_1X1ppI+BbIkf>Dzyrl`>;m!ykFE>T;_b0@JU+G+Bd;euAw<@$k@#mH z1E8?OV~@Trzb2PYZ9wgzFfTOBu|K|Q=DX%eGw{*UDxVVZ(Na*iX_&c)X6Xfc$HZ!u zT_BmS`^2L*-7hmOYzH%CUq;^ef4OMSQA*5z&$IWi3fDk%FRuQhy_k;BBb{OaPl2%2 z=u5=i?v-%CFC_zB$0V^>{NYl?v@n_+`E3n0+2#@E0jsxvuTt*JYWVQ$(_4+?keiZv z{TLky3t?K$z?v)poTnvMH-+%u&utCo{@L2lA04;h$n~OEvTdUU7MXtPo_2Lu zD4J&5FId<<^e1n_@|dvG?(!5PCVaX9q*JmnAdNvAWQYe9|)VtnHa0 z%vdU`uA%tIER`HJbA>o<=hqAabmd|vC=KX*rU5T*b3>5x)zpUKFGg9JPMi@SsSah9*a*a$+=SDf(c$*diL5M+uW57`vb?6E<_4^ z=9H=&TYKbVx=|^PgF}ydTgKe%%S^K$?(aj~t@T54Ig_b|5>jylZ=t};mP~(Q#EQ35 z%fttin;(W6Ze`*f{Pmnwl*OD<`BUZ%WpxiV@uMCh;$#HHhCN7hb?dGPd*O zmmorzI%K`$kVKgkl%JC$=3TSBW5!X>!1?2{WEJ6@Of`0ymQ8FjnPi(k{D}@5>laz% z)FNn5*?GaK+-xNC8X>`{UvE!Qxs~4Fg(G&D(#ZTGl#xxUP6JD(pFQ+H%L|R#cQkW+ zaec7$ts+*_wbNJSIld5)3-Q;tPV^QI1FM&gAA_B7r$QChT`P&HyoNdITOZhERD2)x zqR=AQfU#Tr43ngcVA?!b>F;0rAB?_NxeI>}-CScGN8T3yQe1ogwspZu_e(p`a(xRi z&G5TR&;DU*{_r=VFBQ(N;O}Ss;zEFyUKvL2P1ZxGSA(A3;L z@u$Y?@a7X~$CQl!eE-=?4O zzK{^)*bhA*w{WfJJ|ngIc=bZ7>80Y z)9vy_2HH8}momz>s@|zg#NuGA@$apgcxE7Jww`&Ld^?#lu=w+<1IMVxj!P#6(7jnn zef96h$;E>XtT4tZFpvyYYJBz+&dJjs z$5&z$>Hh>%0PFI}$c=i%ZpwDQyAo;*uf}q%BeDFzvvC@tkN7}-+hZMW_2;xeS)C$S zr-k3~pKFrpR9_`cHgnOyqaweTSD7cl1)#G`liMlACVFNtLPq7)Y~lnG=#e!L7L=-w28?w zsARqFGx3Y}q9^$yY{H+y1zM7eH2Blazxub_Fkj${UsQ~ZVaq5qD|y~wQAvzyQ}S0o zd1Rcxbi^(64wBQ-o|<8AR&W|0Fq4lV4{)fg9`2D8=S=0`Wa3)!9XA*UZ<1LP=3FYa z-Fvia)pPer*v>q}281K&;QV$gkt*F?UBN`vzxV)oFyQ<5?n<@9=|?=gK{+tvy4n4* zjWBZ|QnC=;9sk@pf))qVdhAixS<5V@YJEcJWD!IC6@{Q0vf!?-Z@Y?5l(1aA#uuF!enS_$+3O4E%9N@dCqqg8=1?|(IcMO-B= zXiE@HRDmn9875an^R*sI7G<9s*ph6x)d*#L{Ef}!=RIoI5SObz@17pU^!4>w97qh6 zJ9F<>J|$g4p=t1QA4}Hn$QvqLoFo zZlAx$c#mLu9p8XL-#*7(GzfjMW85b23@!a*c-$FjleoI08~odD@Ue0jS%{7!+FT`i zVrdEHO+TSDu(1#t{k3!7lbU$~qe^;kq+*g2>2(orf0K{f#epzJ924{=SN|h0az2GC z&Q$qHcJ1{H;Nc4nFqWu%T$&`V*YCkMyoRn>Uy289E&iU>9qGfE4HAgB&0O6`uT1?8 zzx#B-nprC%ClF0WAK;;)Kll7jtlkfUIq%J+W$z_^SoW(Z#JoN_%!G_#o10xL$?p@E zyA9R3{ZO2Rcsh~_t$$S45@>3yxEzR8FjJ(fr$3YH=H*mbRs6O$Brm3n*;w>}H9qv} zPjI#)C`a{d$0>|m&9b6ggA2a9hCi=Y;Vdyvbxb13N9VeNkbXgHO3NL~8cij8DW3P- zMSNVc#a-M9GyG}HfuQ2xRPFO{(q$pX9~jpr2R$6BX=f7bSQ7^BwqM2~ZqdqgaRc%DDg+EsHz08WT>qU1)@pH;WzjYj~4n#u! zYWURqr8tF)Rn4tf(^)ot**_p0x?c=!t|wZ$QfZ3mp~cgk+jW#>@sFxZqy3M16CPS1 z{n_XMi~77cK4SR9Rj8b&c+rJCBG-4g6-^j3_#egd*VO*L6vF#tyt(7e1q-MpKdWhE z+=zR43A<%dL0Pd9}|>xHS_Q zGAva`LeSBi9-R|Ilz}~O*?J!*tL(rGS>6ztqrXPyO8b68d*Ct}J@vUiLFHKW^>LZ> zWv+wjviCTY?RxCzu^H?D@+>(6)f(WJaak@j8|F$!GyG(U{@c6-;brAy6?n2H+6Wq0 zbss8yt}i2nX{15;^W$yP2d`crK@%o9FAV@Tf_YF@AnOd&mJb&}D))v=>Mp@JjjI~~ zB4lcbzH*)5vtCL1g#TH96@?IfV;1+RMgBYmI-MOtp?8&YPwC#Yx8L~6U5AUjyJ^iy)BO_F8sSWF{ng>Z`zwM22Fb5%$|U+0N)kku zjXTh@P0DL(pJMIjf&~Twy@T|8!bB# zgCwV}vcS|8z2KY@?gbI=C!l-D-)**tti(M|l@vZa*d*QJ4y(m!6Z>Lvg2gC|U#bx9 zKc?cGS(+HsBjfg457MUtn4sOoCflGdhEh_x4@-7NO?K=>n$-InP20jwnV6ZGjW5vSb3mY5NJ^xmtySE}ygYX*AfhJ;)lh2|yRTBVJYe*enf`O8gZpn$ z!Fd#Y@z;1&y+X`o=C_jwIN2B)&U<5#CO?nL1Noi>35{h}{fXT+x47r>{2QOEWf3^H z^F99hsPsB&Gs5nXmNg|Cp6ExFEIvil53^+ikxtLl?aQ9|xs0BNb+U=Z!^!H8qby<6 zZTDa&YV`8p+M;&GF6e3WzHB&{xdEuQm~;C0F%VXofQfsv5XFlPs%UhH0EsY&Ad(Z` zzTo10J}p3hABumwH~2NT4XRBL_z4q}^X3Y%ya<{1gNwo1ZgAKWa2ihE8V#kdAOK{< z=bPv56lg=#xDE$Rv0s6K>Zl3fW981hbBPQOpwss$!EjYjm!=qMAtLeKROC&}2eAOX z5l%WVKm_%gJ1+qq5HZlsyw?T7x;y$s zFESG@yZ9fv%CbM_xZf?r{**f4C-co@u(jpH|Nf+fb-2^yJ3^MqlP#c)Q?bOu!N@j< zvaY0&|LUIA6tRpQj&pF~xz632@N4GRwu^?Hf4}hiYkhF1g;a}Di_;G; zmIs2jri17y+RS-F4eE7{5ZpAS+pt?$zUUZAga?1}RoOe){X?3FrLGGmLuPdfzCPH_NdVsBc3<^c~0^9+yF(1av=y7e#)t zoYUSOpw*U74Y!CQLW1@9)h7)VT1HL$C*WN=%ui+@FMx;o2j=vOHJHq_neLdGqCbpf ztfVpq0&mqugH=<94P54eib5rF@Njpk^BSt?Fa~rg2(e;ryN!S~e*p9?T%ff?)1TN_`>A4Utu(^_JfG#T1o z&<7!*KRD_=&_yx%md#)%^lj>I^nGZsnjL8U3fzubb6$y>wm0C>PUm4UunY`@d?$Ee z@tb{3t^V*hwxW5ir#^gQpWIKReStahK(!}JLj#TxfzZVsHt_doXrc!h@jI?YdQA{7 zk{9E$?@a;l=E}C50UFi{>IoDz+Jp0#o3&~DvI3{oT_!4?kZ)d;O`EAI*kGhI7+!eM z7AR8{cljg<9}`XTGXPs&v*u+MMP2}$Zf@O&d0Wuip)zBQAIH&Y)D%`x^Q9cmKl=6@ zr1{rEJ=9&0x4?gPU+M%xS2pXPin>c5{G+mn@iJo7~5^+DzR#|I2@Fh-Tj)AKUN_WG6@cWGRpfs`Y zm2(coe;`R6trsV+I<*wkBa}D~mowY)^8n-Ctz!tvN}#ql74y7S(?J*jFOs!<=i_rO zv^OBtBJSg2I;uU`Sn3Y?HoV~M$Qt?(Bf~Z?+N67ckO!!lv5(We9OQq04Jx*QDb0E)FFUcmAlBf zRs9=0cJei?yZtNx2)PUb%akJVUJim~g3SiU<|}Q51SVHe6g&Y9^E_$tFY-i*(Io@I8kRE?{ZFJe)Dd(ewi>iT);eNNa~3#@^yar z7);{YK!UQyO<`bHBaTsz1DljEgp%H%^R^85W-mdq4t^tuRx-Otg{03D@%5wRU%FC&#q*#F1729BeC z-hTRT0vLSUyPAgvA0_IIu6CoIwSaf-Sx+Pp_1AlEMW%zTKKaX%F1!Sr#6LaWBq3p} z*De9d+r#(M!7+g{h+~}?lsZO3148u|?0QnnL3sK2>dZMXA3(;+K-E=xjSD#X8-MS) zB8{VAG;l5e0ZgpPt(a_f#Jx}4X_M{{577~AM-igJ4CnP2&NjCQZOGviVWmn)KVikj zJ5WQPektz&!Eo!+Uk;Ul&WpVynOOTGjRI%M47WtnM-xCM-7aM|htmYUWJcXw;iz-+ zjEZCa0QHTPn=pt!Ip1D$kRMCQlgyl)9OY6H;KdUC-GC=yK%Ck6j1A3+gi6d8s**K6 zN<>6e2B(o|ri1)L;7u@{+eB1fNh)d{LQR`smBE35R69&iBZeDzy8iiNYZ(|wvS}CK zw@JjjATU$%G~@J2;JCY10Pp26FahqD7IXjE$v_MezVljjU}ccDpd+`bO`rnn%u!4M z2FeNuzdXkdT~t0Kt@fR0+(5PA93uP33e~OG{&6j;DvphfSmiOJ{>#U!6 zET?9gLMrzPazNuY39}D)5nk867+;hpf>e(aJ!u&bS&S0ytXJRQS}No}#CcrzR~qkp zjPeh@8v~%PzI!rY+C8KhWjRnRL~`!dLm;VXz;Ob<^UkJ4%o)=Lik>?;I{5Ryd=by` zePw8#NFg;x5*4Mo`c8ieB8%Vr6BMxc)zC?^S2i(j-c-E0#Z4~-MRHJ4sBnQ+HtxRLtyEp`_i|r;U6*Hu{IY#RXm+T>>fNe|*1e>FsE&k0P;WHohG zw%b9{i8LR%Ozo~f^H&xY6G9&5=|xI}5+~z+sib-qUKRzTcN8L(2Lx>Nstv_pnha`N z(CE(#dFsRo%(wM&#E!=po53fbfL3TBenU4~M`|fOF#!|)3vtn>_x1NR-}J9|1iMe3 z{D_a^&Zp18U+nvUwogZ4Ei~aT=k-BP%cXdi=Ry zI*&kP2fJZG@eHE`Jtc|FLMa~&YGcJwonm#fVVf5ykcQ?CQ1#z{#vhG;=GNXRhi*BT z4ex;0Uy3<;tH7BENd5bwkMvAXe}^^-Cf)uk;M58Nr~f$mFIDWtrKQ_$FZX1gp>5ZfxI(H5FTo8T^0(kz=hOCZPhBW_$1K71`(1<8Q+p z_DtW{F@hbU{KI-oa5GEtZ{b`qp<6nPbOs6^$^eeQNV6tDiX~iSn@-5Pln2?SN8uFg^ zF|b4zCZ3~!9)M(wZ(A!qzxszUw7SCK$z@PQOQnb(Qn^X;p>=kE%WO!o`^?gZA!_E`=0*t{)OAPhHe4;AF@KY!v~(M{sN>p< zzL>M@Vd((Hf3rP*gp1~8z9q_b zwKC4s^EhsvDxje$!hV@WWx%Zzqpl)KsEl}fTl+w~4$l88prYTEbRx|Xz15x(0}sI| zNAn+{*?(e+P%Uj;Ad)oPW>qynNboC}wTSs+RxMmXuB6+p=Z*}T_VPJ@r!LmCGUWT7 zwVRg0brksWxGRfL>_4ljeby7{$5H`hv=dcEU7S0ytvQ}}`pL#(QQTjN2R^T9aeS_T ztB}3qR#{g9Qb@)W{Q`zU0%-1eOM|D7nVNXhuQY@f^0mGiLE`kdYjKe#dY#4fQA zwVHU5Mboyw-pC8uH&Ydu&qAZparMWl<~n^&(=|~mK?^c(-{Q7&k}xg0$TdeH$kdzY z$(Hwq{PVSMNraw;%92ay_X>>c@0DgElqJmbkYWF80bhk@ev>BaRliA-J1FL@1wiaE zt6ay3XuwQ@3j$0K%GS}oIbftedwF_H%t_nh>2{9d0jWFikWad7g%};(?@nNr$e0zD zYE4-80j!{M25K4ZbmEC1Nw-*jC;vOf`%5KCU&%Lj)U7u>aUKzKJq(?K6rsQ;ns8I2 zi$DFTfE*w*LWy%wrEs}kju9kzXQ~yg3UFgCE*8TaTlHLH%`432V~)Fqt8Rkz74tBL zAnPVh2Bi!|*m$CgX&jsVXUB`{mfxv8E|rJFot{aW$2AKEyeYr)C*nXh2dNcY!j%(r zI{`Dq^z*j3J&Poo@GF{L+$9sefI)-ucif-4ar6MR11vxBOYQ^U7Fi7& zt`_h4Zx5wBuy3+s$lkq}`a4Mga0Z9X$`w>@(y3SCpSOZy@+Cpde^I@^QU>C=`D|Vz zr}k8jWVkNH^ZoENIL9SK-hfHms`jemt{-9cI;0{!V9B?(ZN%c7Jv$wQ;g^8K-l za1X0L;3_??>N3V(rbH1HrqBVeirOXbUg=I@uwC(baN>G^<8dIe_Pb(4TPPA5S5 zSZHX^JkJ^2kvT}a!2XD4sa+V4XSZd`2FV)`x_<4rd#@n1X;=IeoJ?QxH%R#031Sc& ze8wQ-g42uhQjFr69<^#qEve>(Cau4s&d~2*?1L>wnmvyfJO;$T#^!QLl(PaSJJLOBWGhQ#YO1eh^a0RRiiqS2Z~ z+?Yel-oqUCqXAYE^T7awG`AP0%OjK<4SanttLiTXkn;xw95v6=L(;G+OM)sNBiL^e zs8%+e^!fwi9(oYycc%)z7Gu#U;r1vLaJ!B;q}ywpGbm>o*wlja$nyOmDd=~@4y9fh zDp=m>mPNIuAJTXTQp!Kg>NbvlCIyh^j5jVx0o=zg&IdjRJ?#cN11?qg^MSXbTz}TN z5PQzYjdwVV0n=zv-L%b^l4nk&jbKGobW`m-mVB4{mq8NeU#{@~A?~fiqU^f1aTFUB zQ9?yPK|n-6L_i6#XprtwBqWE9A;zXeq)R}$K|pGVF$n1{iJ^x^hMZxT`Su0q!~Oi8 z-}@fN`+eW>ad`iMw=>ti_Fj9%xz4rLXOP%4NHJ=3frulIZ3yTbR|hEkBv!`8_8$ zEP_xO{q27$6xG(?d6u0n%txl@z-fLTVNHtD+gRInF8XdY@C*^auY=-~ph=LdJ(nA3 zaD-ogukl#7_f}Wn&Tjm}5e7GC8sq>WTy}`yANtkjea}Yb@&t$|!4Wd-dadmWo-hcO z0^}qSVZO(YRpNlPG*qgw&^FM?T-#aiUF05z3zF^s7BhXGAG~y45BU9c^t~V}bZya! z1tkap5CAIpP_%O^({%Ul0!SxX_T5-b`*Ip2)_GYp#3wBFzlf@0$YPBfJP2jlwtZ}w zL?CYf2E1}4DcBO0QCU4)ZB2q{Sy7s z-5QHO(zT+!XN|40Six_q{<=SXk2GJNAC|Nexf%u>HSyhWMX>~Mx?0hcP~N_|Tk~ji zojk^m0VGuXVvhFhEb#6gtmWm^Ms&!&T{QKd*ippEm|h;(Q;_4G0kYrHa2#^8*(~20 zEc`$h zg||h5AXzR^7I8b|iYqxiP$;gqobz{Ac686m?$H2;^vuo~-W8g^)0?8gkCpx80L+_5 z?)h`+5MncF2HraN{I&-~MyC8~kIDv&O=zG+a=3m_-Jy$3|Kqyu~#TLCTN%JLxrXuow<*B|`JkU#=;5#%iXL2lS( z#2f)|MIBkwN|;}*$=kaA-gjxjR=Q(Sk)H!~#M5`KG;qd&2Kc)nJK5`PO;ho0lRcne zr4d;F8wyZFZ}K?USuFa}>el!uNTqca$zucrcEy=@&l&H*U=@v_qqK+CECwh(0C7w( zDhH5*Vhk$K=RzJz==ARA1NZ2ay`Q%Q$|t%{Nf-#{xx~P4=W+f@2|!}oZbt)zq&jvn z?%J|}^UimWflSR`IAJ&Ye{g1Qt~`%yC)1l0SsvE}5YQXue4nN}K^CCu6}XrU1pjjX z6X>(s1Gqri5d@vcdAcp%v=7>2pgFgROa>le(Ex33NIM}| zuyYB>uI@#t{%kS;Og_CEudsRu;6F#{AHRVs1c;GNYRd=h1s+jx3J1)oZti~mA9((r zI6tIjC)WZ#0HH;WFnWl&!~HBqW_TyCBTEAvpCIo*s%sLK1CW8Qf&T&e{5V}=>>}Uv zTSusq8GQSDpehDHoNXmuTMiOWH9&YQ9SZ?OVXw~hV8Nnu zVbeUQyE0j5kiIKq+IckD>pf!qBADQR>fE=|sRX~OdNBXIPz6k%x(ATyP~$-wiJY2% z(ecxKo>3B9cnH}rTB-TP(h7z&qxOvg&TLqp5+_PdrW4ScfdT+XrXa}JXqEzK`p;{U z9oq}Y?a;q9NBj2xS8iCH|sSh_;#%!&tcp2uq~+3A~)UWnkydb)7- zS(Qk=ST+RFri1)+P^1sNnE%s(%9?)K=#-_kdDl+1(>VGSlN(PUl!MI@PzQ(08!sx6 zM?C^*9w?zQnn$?7p=8(sVN)!-BKK)_j{yKo1L#;GX82B{20~%3hgDM)zxe~r>)oSu zHKr?1pDxcxWAjP_ctTKAb4L`0uSKDn-Y;x43N+Qap1cSDfJ%QRFB!{%30(Bd3xM;-Y0t9$GTD3&cNs zuiUu-xWlUPz*hg<4nUWngx<`dhA$As2+&Nri{$B|f%a7?+ciaZkM7Y@Akppr84Qa` z`t8piVaogCTHl7O=FoAuXNl}~##P!D{?D8@lB6Z@Y`9ZN20iGNiey$T$+5*_(OT!tH6jk+mTpKc}y}92j z62ufm6VK{*1LJjtuLV{wBhJwFG%khlb1!<(XYXcu9Vb5?&@FQ=Q**q(O+ znFpkSmpj=$8dgSthd_}X@XNfjx09IAo=Y+9x!PAui8VhGzW zEc@X_zj>MQrNc#p$_t}4wuqvoZUAWc_|8b>(Ia0j#@)wT^{rPyo~6lK0KKRU^_l71z73b00@vz;G!ionRJadEv??s*>P! zkqa;v&XY{|sW>7Pf3YzKvf!3t(m>pxm_1%BBflM9S^`cf&@4M=i69w8l4N#e`+4l1 z?8M6(7#Km(&pGZKr@+`jgT~JdGtx78k;O}|v4Y)CCKFJ4Ocw?wxl9FJbvoZZo@67Q zN;(Wq^fXgo-k3n%68*Q9->*SOAL1dJY~Yk)85IWBf-p8sEOc(O;JT1G_dJEbUg|KNf5NdB^2V_nNO}_74 z-Gg@mSTHSXFA@&1Gj|-A)(0S;1Xye^kUIc5Q=qBKK#d3xC5Y1lNY^_*MtiR19_IlG zDjJ$WE@j7nodDG3-cD21!Qn{ynqWW(-TrwFGKhcKRG*?iq8?a3kQcbexELoA3mlJ% ziBX8~-E{)gJEZMae~{;;6j=#HZnK!cw_Mqq1BM(*K;8r`^ezXVxEobiT%7t(mL=iD zHSpDyAg2wGF31)<6Iul*2p}Rvbc+BqqrCCGcHs^w4EW%CRWK;<*{-O$aLeYblxSqR z^bZF$Xol4`&%t33JXL~b_#I#KMMOt*o$$cV#b6}ZEU@2zUn2xkf?(UAP|j&rn~{~= z-4if_0{@fCTPkS>hGI;CTT=343kHt|*5DDW)CKGrAf?rBf2DS-P$9rN{;u#Jg!5gm z3+&&tD9C-#_uR4r40Rxpz~J1yR*A@OgyH`f7mYn$^S}JvX!EXZa)lKLaKXNhXIobx zAT~H;DF67YihDz`f4M>``~Z@Ep4| zCJ2(g$H5qiRbt&3&`Y4Yg)#aZ8@V9BitEz0xsowE;zCAdc7M;N0hGZ2z-VCVVds8D zHYi=*@*hw%`Q&GP1#&|p5{In8Nx(s+(vJ7cZu94jXh5kqv1JTm~nbM4`k z06+WWwpgLTMLzK%7W|XHWNCRJW2a8w`j4Aw^mcGr3rR6hUBckc(( zse)!93(!gDp^c)%2;evwh=392^tkAd-uy)$a7RH9m;-zik=P+STTqpS35+pk|MOL> zd!rNZRrW2S&VY&s2!9SBnJ;nPQ`SpUUsRgQ+|EO(mtC@Nhl^F83~GvS9?HO~Qd-Uc zHXI2g7(vF)4)*8nq^bY&MC`k@O#K-}kp%_zKi-~DNs-gaH}d(VXrzCj<~Yg)M{lns zVZ@fL?k9?gx!C*hFCLH*0u+KF$m@XE9dK7@SWyb*;3|RqapoTbL)PWDCq{x&nYIVm zIS`4bZ#D0~MU@?hk_J_D01J}O15s&F!qXuTa07iqA2uzPV`~Il(n@8(O5FZ|U)p07 z!BGXG#Xt+;?>Ty9kHE083b*x)CUG#^tw!q(fO-L9a__}nIyVN8L81ZD0E`1f`T?#W zD6|1{Xu3@PY99a$FcFHP_)~1=DXV%4u#>IoJ5~Un;*LV z4K6+qNC2+U-x!EY5v=}ihzF`$IBYj0yz9|Z#$xY+DH;GDdcO|v+pJIm#9*tl=`(s>r8;1b{jegSoi#c)?*3NTE-3Iza`^yhTo=8-_K$nz`)3Dvyt z?MeaJ!XAeRg4)1*na;#^8Nh_CdZ$Yhn!CM$pTpdD5aVI>#YS}bPR19U$zj2jm;nbO zu(1#!V;2BarkVF|En;Wa=E${M5o;Kb^5S6HrnF4<-+K2OAB>Ux|?De{tXT)#} zBhe%l4xg@`W!ezV@LIL(@CVgmAi46K4`dRGAiv|(jZI~b4z=By;-pImkS*>59*fZ= z#8U$XL;+SB@pTu%BfDs2)NHc+3nsdp*n-;NiKAI1oIw17H=I)QYtGv*s1CM8S>X_#=jcCPT+l+(KO_B1J+QzB%N@ zqDB;qBiQoBi7j_rzU36XnYrzJ5G^+GZ{;HJvI+{x&MPdm3u>HhpF(iaKxae%O%Gf! zz#Y2{_%&d=fM3M&$MAnb#t>F*ISmcF!ro?PUyuf!eh!*W-;^%4m|Z2$Dv{RUwBd_b zP;2Kh!iMmFe$z8T8pzVm{s$v^r%(mXFXnDvjT{(@m9&xh0G-UP$1Lu1n9D6J{Y2WS z!$XAh)#9niLiA}w{T=&7+!|9&{0uH`_8+Yp)uszq@%y?_(ORpG6`1HtK?_}Lsir!l z_dWhXI13_WaP?kh`Odbkn9Sz1PSXd3f1S1^OO?U_hBad@;71GaS%P>304#u#hJsX^ zPC(sec>NJDK`w|QJ_|mARwy7U-R-gGJFG1%wmE#z@MG~!T`Qt7qZXlbo8JM1{QRCs zX$Lmz@Y7nN7uP1GNeHw%{xQ!U+nh=`1>na)NKu^C%PyXJJfEcG{kDB`KfV z=aY5c?ox=FB;}&&*q`tIhc<+KS5P)hTQ!P!9C0Z>wANW{A7;+uq~l+f^>!mU4H&w~WB+t5~ofp!#C zv{NBh=elm4%FKmbB|xT1u}7&xuW_as{d2V%BqX?ku%PjKjG)tCno^>X^Lk7AN<1KquF(%V{GBhYB$rG#|VC3lORD%9{fj+%(*KGC=$pIZc3%gA{umAp1`}QQhkB&Gu?0tWR)bHG^C5(Ew z`uR@yIok{ckGrFPO0VTjO;dZVB=$`)V*%dadV1?#3kAj1n80H-ki()VQ+_2DNpLc`#- z-u0dKf_C6&=D2(Ccza)j#v&~|+N;fucsxZa*UrT%y91Md1gnXD_w28|&l z?HZK4KI#5MuQ=%+kc9lhVVIB9G*0K`KFZA2ec@m?8pCb@c`%XHoH$vsbKqlMt`|&X z&yq8$ccyY&*J0+}{qudJiwWAx=Uz0cX2-VW=ySqJ7Y%^vK0g3rKS1||W?(@>89dLp z&s!Mi6qxw`I#u_mFe~;lQ*Nx$Yt8*n&eJ6FF7u5@5cINWv0TxF?)-kj8_Nb0u|^0K z)dD*0+*0wwq!j|!x947JQ_p3$7YD7UfHlkRuQrdYyyW8N_5-TNO858HgV$mUPT8wqARHyu6xKoLX- zr`FKyjSJ@KEM?v(R_0_3?C2qptow&`!LIP?i~{)uXBsLzymP7FF-`v4bp|&Yy3}JD zh<`id@4iCAdfVfpsaX&zA2vSv(na##=X34232Gq9C8dUDTI;sB-$ZWq0Wj={%saw~ z?^%}emy+MlB?R2TOO@wtZHxr~Ed=SQACzLM6w=5}7Y$O_6@7)*-26kykV=rMc=DBX z`zWE)1J|pRoO@fqzHdBX{5R18T54NSt^T{B%1R?2+MX?aZw4zEzxro^8wm=GJ*-VI z%MF{SaaB88#m2%@=^A%#KinoF&(% zZ45j8^s8(@pR!?NSpMUp5TFpYegD?hS45TK0j zHpa56t~x+l;saI!J$U=%lB>@C-hMv0J{($8QOLo91L!w!JGHLs$Xrt+e+1f) zoDShZB)+^M;bOd+WLYkr8&XyUVq*Ud*Rx~ZbLYp>z8)Pnso*bZ(h*R|7C68sxa9Te z+E4UFISedkt9kBrG3cMn65xZhYCD~G3t?t5Q6L;U;1)rUm-$_*e&%i{xj<>0?F^Ela61Kv% zm^?+9btVUsMcXAt}ORh??T7g z4mx89wFE$b2w^~!hibk#SyJ`Caeri5&@THfEK%@z&B?<+)bm6LQ83dNQ!F~*vekI7 z0MmV^()!f^oUq}O&Cn0i`C^3a;`=}JXx|nz**%~`yD31sGr|N z&EpwQd-d?H9{8WiJfQ1<4oczraA`LB=Qk~2FonI5XJB|UdIhBE|6tB!Hc(9y)Tq6{ zV{>gMTvcF$wO`lk(s}#g{rlcUDYr3yLC`oVmG` zj>Cc}6nb2T)3=M?e#&BC#I<%#Cb)~guIt=}o3L}`4cLeWI`$4mk}^lD4XO9`PZ>J& z08Nl#zPk-r(*&Z9N`lTe5?SmBmE(b6h}?g=vR->u_7EcGAKh*~AqIx-v^^2G`BwuR zU9+8#1KKj(&6qxW>k7<>B;y&!{sdM-TVi`-y{WTEsUTgYPXk)lsn3}I&eGj%8Gn9@ z?w^%M)z{kxtb*N-nSTo>#x^V*HKFW4&p-L`wvN&Fuz4uYglI9Gv&!+7nnKl#(?PwA zk$vG;N0t5O%IA_EukoqHP&(^m1r8PnBq#L`Mzoksx#|{kj$%PIIvDiyj2N4F;+s79 z%UJ7F0=9fQCE7^vz>;S6YW3=MR#Cc9p*XDH&6Wt+^a_#XbzQ3?PB$jVW3de#svB8S zI+*NO@S)D{-ijj(s$0Agm8*-uOuOO{UiH>T-W<1tBf09Dk08ZpY~LKqXTM*HAwr*i~OP&3*CDt*op*Ah7Rz(T*lAlvcH8L*l9rKIt>V~bljC|!UZI7 z^y2cRYlreSraE|{>*%!rG`?Z4it?kO{7$-{s6QzTThb&fu`s2U_p{+NUTdelj`bUQ z>lRA1_S2tcjH-~gZ&^i2rWqUPdUY&6WG>UA3O6@uDGV{lu#KU!`0gRAfMF@)LMD}& zI`NARF3h+;l5QD84tAxg(AvgyR>{~iC#NpE!nuVmENIHW8GEeSSO-N5GC8J;9>@Ng zbJeBn=&-+(vuw*FDI>(xV#h6u!j3IZwmUXa*`WB~huWKg8P)YPya}4W*>2zM3E-s}_)ccuzG6Gg=;)O3TSoMps<9 zQkBlq!d+t^ie*Y&#;$C}=8{jBOKs^(#tBV?r}iwS6+kcS%fQU!cQ~*%Od|Y{faqWt zv#NNk$m^;OP!$KaloD*W*fTC?&NG`|NBHEJ>U#ppF5}so7Tt1OH z6|7o}O~32;&e{y%Py5Xlam0k16M={+`_H=9^YoTjYjk&M|8#%!q@~F^`s%2lS;=xJ zwxM&b)J2g4rO*Wa_XLN8CZ!$N);{}hbLAWpbY>;}hI!1~3I!M%2iK^sV&+*ISR0PA4bs1QsBLlcF<7zX!#o70Dmc)nzHn&~&S{5dBtWO%QWOIv@bC9aYf8a1>;3I3&YPG@vGc<-5V&ExA= z-^3Inxl$w#>SYrhntOhfteVHmITUljJ%q}*rXR^9XoT9mi4x5XX;8Ud#>J@GIuUt` zb+kM4O@6-Tb#r27;LsEBc|1$c=T(kPP~98P>9aF?0bxDr9spENl2JU$ZE^fHR$r4!7OJx~D3WRV z?EQKrPf;p&*YeX});rED45K2CE#jrauIOfk z)1?q{b%TRq!9TV00J@@TRkzW9R~u~8RV%TfP&Y2J5a5d3-in5WWsUchWh5phe)#SG zX}k9h3lFD`ic~sF!HS!1`a4+FnQ7;l(Uxi7siLV+LW2S6TNpOhFV;K9_mMA2#?B-8 zc*zEfyps;GkWKYr%jzu(TZTs?XL!r3sG^O~?YD^|v3~kKIlhPCD(0r|`&`?Y@~$AS z5;^NuX?S(6PMOohgbaGmJ`r-uDYKGx7c!5}%4+s|?=$3k*swx3nApb*O>_2yp5)~l z!Nq|Rndp@Pgr0ym_0#3RbM#Qyd59l(5htu&b5~Ew zULJ|nse<=asIH3S^pC8X(c4@akZxlFv)-slq2u^3j(4nkJKO_(t$`Uq%GwSBr%iHg zfLWk!A=xTpeA?ZGHrc(%JJwsgO}bS7!z`z9QPLWAZsu!>`PVTa7}cyXP*6C6C|v~@ z5KUfjhgCFS)@cAA;-K?WY}l+!1d1S_v0gkL)3UD)oj`&{FI_hjPlkq~I6m%Z0cP2j zI4jqw;%PfxQH0p|C3u=JhY$}_QaQ%%qa)=6S{!>Xs*KBrd-{>DSZ`H=iz1b1PsaoA zS({^V-hEc`k1n<8ltwf!6~no~C({L!ohBn- zF?d8#tj=KfF=(&lfO3rK-0D2T0d4}E8%#m3hWFvVtcr*XCx{`vrb)&b!c09sI@feR zOXz>rfA8QlG#5V=yAZDlR_D~{*fMcz_K|OB{_-@FO&inTk52vA1U{sgPXV)9%(}4k zx^8fX1d4Wg8dy`79*ru?zz5kqes>z=!O=eqU%`ivPIl?}&+3EQHWh1O*X(_=p&C5v zx-bvpR4p9Z^`G(GqSO`gBNJvf4iC70ENUpoB#+M67cg7S=6q^)!VoSLmx?h=*3Z>Q zNy69;zSl9JBIiaX^`wqtFGHRNRN){ro0a#pHf+1X!DcD*Cm$i~WL`NuNV{_!pYU1X zeLe*SHjW zBVF1X?vPTF;T*6^XXb9PVdtDU=6^vyuVyZ2F8)I-xVJi78xPmp2@R?(A4(W&fG#jL zmS6NOkvcdyFHfmf5AE^ ziwL-}3UeeSE#us{nPd$G^X%bp>(dOu6=2H;;Dw5JkQn7;!di#}X1Ote+G*$`*XWBr zrasY2Zw6_zV!;EZ;(MclfHM_|2^~De3@jv2Wns5qMwp4Qn+EZ=q6#?3G>FW0v|8Q! zcvGRJ>uQ{)!CC`U^M4ttSpl7asslDoOWOQbt$3~+TDG#@7_{p1L3L++Eein~PV{Ef z9!DP?eK8;@^`ym7jCBhmUtg9@dLn*Cl$x{pRmi&TXJAA|zKBv~_R~0|N9mp3qVl6{ zQ^=DR`LKCpI`Xzj?twuaX@?sC`rTBa(y-9L*l(L1-x3iPVGiVFAu}pH8gN@n13vuf zV=lYu!(A=zz3qxH?_j^ct>Kz}mxSV%jx|r=`Ri<0>@zLPY(_*mDY;Fb9*A zVT-Ecog57KR&x{B7&833HHAqF=TvcOk}wbQGNa~0jcT@~ujroO=04_44xfeOqW+f) zr8w%#Z4aPlNVk*;eFk0;bq{XEAU;r(jzlxdWhc0FcYz}$4}%m7V*D*KJ8?e#-5@Qq zTSW8jIe;NOpmsaid3|&QrH-&(Rjzc)mioo$J63PPpGT5GK$FfX?)N7+c zW;fQQ6)46>E;^H9#b2REY+1`eXp#-q3+731>MG)6!uTjH7OE zwYsFxQvC|38XU$4N4*k}8s8syED~IThK9LPTyMyCaES^(&?U?@KJwL1#?hr!M{yxF zMqdnt1jWwYIbx!*H6-r9W9>0LZGFU~rRkd>jzK}Z<>25M;0)EdGkc;N(5{1rzs(i7 ze84uSI6wGo;)lDo60ym^gJ`LCExY*{Jc&7Hd9q3XxUInTiELs1m&ymG>==&%OfNkY)q#%Bi1nU&3s*G@&*&5ME97{?S3480NCmopzJ-UdZnCATRo-+c zb6W@KTZ99ki#OZi1HU#sd>f zvvN3n>K%MMczc!S;W?WZHGu`!mpLSoj|sJNojm8X{f%Z*z%YZzr?JDnusc;9r`*1r zbJ9`<$@NCqfJ5Wiz-J4?VEDK!6bi(EefFM>*X00fwOidrlKzrPUb;});-^y=2g@|9 zxTF4ms-*q|zGU0Ik){6G!wT?~P-Jl?EQbb zQPKX#Zc%?9Mh0kJ00##N+|H~2`pdgKfCmZ94*Qc!1^;Ut>a6_#;IBXe`?l?9Rb4Q9 z7cY&h$ibzD8DpiNuJVfSBlBiK$Pzsjy$rcRcXJIc$Ov4MH}k+2(SUKEW;AS0^^ zM6qV~`g41_sdEpJRE6~KRXwpLt2hAyhOde{bu&r|@7vn1PkDnE|?Vvs< zLHFP)@3&Ku&Hh6lQB;NQ9Yq!k7DSAfz~JW@T;HmWwS_CLGSxtf_&qwnajt)Pc|9w} zO#$S+E;&YRm&1epGI!zEch6Egk6w?kmZe)xN_QxK>HTAX41S3lXFZ&1T+Hh*$mZ1y z7Gx;J%64}2XK7o*vS5O`Xz>_29QLu$X}P@CK=;cN%qT{GQ+ji@>?C7>Q)ah$NlJ}# z^LM?{P>__Aib;_Ju#XMsrt^VOPKk_c^d~w9dIgjyC*30ADnstY(d&ZG^}S^)={L;! ztd8py*TokY3L?)c`y73H%g*`(imI!XI72xr*bt2t!4f!yNy}-454yT@#0|<*s@+=M zt^D1G>Hc}NV633pH=g55)Z>&(=35h9GPVDMV+9mlt@&K0^4U}XpP8&jqo%|SgbU}J z?Q<-{0@kmIV1B)wg9BK0G>+a5yA9Tk!=A4^_T5i*N|G4%1-!$?yjH0TNoCsQAeC3? zzLopB*uk#~4c1Smkn$&EXv*5EKgh^kuL`sWby_*$LqY`n$XIv%3^x{VeaJ2X`uP9s zknRyv1VPCRWJ*AfFX(cK7OgMXTR@ZlwD*&#QvFlN>^F|x!OcgxFOHWB!uipj%3PPW zN{}!9s}q^->Tf*!<7Nh|JS8GHAUUI`Z+#@SUOg}F8msza(4UO(WxU^}n9Qf*n#zaUa8 z98Yy1FJt69%xx`<%hUbx&tD-rNro~f&E(}5CIu6~MaOztQxl4dcJv+8{0p>9qFtj% zEI~;>oW(jnU!VOn3;SKIa!TRyNa@ew4>YSiuRMF`XB@ww1OiXCsdSFXtIQTs=UN}r z*Rgo-y4BdjNpg)41_K>ER#_QzPUVV$PUaM3Q*1j2n=y%w^)1$!a@HNMKXwLe6rqvu z#QwKQeAY{a%+_@-C7uF)zj_WlO(QmLy!2q@J=us>4tV<&DPrlqPgncG%h!WNe<$|i zC7-|a6m_^4kJ3?L#iz19&>(x8(?8y-1@y(*2RPx$iAt(7E#*jbM76?ahl*kSfc?1- zmylB^2Ek|n_Ir4V6qoUV&&z`Gy)r-e#hcJ`S}u=r()te!6?*d1R#{>fHcARB}H0`AMim8l{F3h+Jm$#lgY9E{Hht8a9{QI z*q+Kdjh>CMu;Y_P{d*74gydt;mf>>MGm}gc))(Z<>@y%#HrjKPsh)q@? z(vlFZ!8EHt(m2zA?F!!!wOdIEGIuhj)6$O8t~<-zZg8W}i_&2CXsOU;#ng!A#tu0A z9&bUDe&!B}ou59aneSJfE3x>7B<++p?_?VqyByA9LBy^NmU=X1v$WtEqN3{j`$C6C zK+?&$BA^Qa}X3T$t|@OMwi~MR#|#aNi|gc zcM#8N8QtQ#)IlPPW~YMe+ni5^Q%F6#sjOcAoZ%1Z-Dq`gPV<+^ON)U)^56A^&wSt6 zQ^NF%;LV}nE|K&Ula23sebos)SVUGjuGXZY#4LV&rg4o_HqhI|lM4%`9lEVcD85sc zKNMY8V9>ca7qwNb_{yN%Ud1W!>gTGEQ)gJV#02NAZosT=A_l9uh#+;2mv>dv-%egjfj8E*;mOplV2|p}$J$hAvUH|3R z*r?Lfo{>yO!MED64fGepExYEY9^@Mu2xrLB@QYW_<$Z8vERox0w;rp;P8C9i4#IY^=ADm-b=2J)U53I!OeLA0uc+_$q~yfY ztjL~7ahY4^GJJo~pt6;Z-{715f{RG2)bG%Co`fZtg9d$HOW(=s3rFEbl|^$z>|cSo z(Ok1Z>xh~|i1V2GjTpuas_e6`Do!-qibiH_g#)U>cShjFSm;9{(*O7$KKlS*Q-ys zteh0;M)N~jgm*&e)yoGu*-Dl*J{RA7XCFw?xp0wJdPY#~D}KrOR-sH}NNth;+fa~0Y1r4=W8X~xw# zbrJss@mybtzApBbsW|NV*;Ro-u{V=q$AiQJPJl`1Yq9|dH1#>}KDVAl^>5n=A z<6~k+nxl*|GFUlFvwaen`4NgOrHkrqnTz;AzNR1its7FM|p;+3LmO3d6S!o(5|K!Ycn$$5DSP4E5a&+ zs$F)b6nMQReI~KrBeRXX85Vu!mA_;Q!?df{8Z{KkWm}wenAbO(SCoYP(u=yX)q;yy z6ZSQ~*kG{EDUhdMNiWs)c%MuATib%}na9EvE?Glw{8JW{&S{F~GGV*%BvAwSNLPvKu<^zi+se)JRY1nR>T7B5}|LwWQ%>RSuxe!AD-U&2CvR!&`+p2biErE(t3nvxg?b8Gn$($J3zU5 z1MgjRB{whh$jev@mwOBEsgc7VNtR z!y^~hvl%XjJdyFVRJ;<>6*k3@tKS$yhxv4s-vEVE=V^Y^v-asHE1%jjccg|aGN-iF zF~)BJdC}>qUr%y|U=&eK(L>)rC7t+1G`RQv!o$YQq{EsnY8;1k9P2U;E8}2?*RKxh z)|3T1N*4GbQZL{_m#4oTMf;296>9TkMVj_H*(*chg49Vjl zG#(t7pM`UWj04L)^xwoqn-iJ5`D}5yF}%TT+6g}edKy%I(ePfb`g#RrU6Q==?sr`F zQbF!#>mO$fP_ex|Ckk^=cZ;UJLBZ8|OEJWlzJI!f;(Gh%N+aszk$RnLupzRlp$d!o zB5{=9%?q-ldQD==rO(|I6H00)7!q|lQ*KlQ_NH9R_tUTYJo#1-5KQ#SS+1+7vH}8o%Ua zqvI}Cr{+gqMl{~cp1mVqE>I#~BxxmJF7W1lydtgsN}18AvOMF}#aPefcD^p*EPLs6 z?TMUGz3<|%l(vIIQmnRHEHXNl%)6776s?y9yzDS2tAeKIdx(6F{{TR@ue~$^9Lf>u6t^dQ7%Cl_9Kod2t_5y zE|$xA{93-gU^J)SnJw%%GkLQR}M#WhT)H9-t)H{?|- zUkEK6y0S`q@7>*{;5E)Nf@$TXMW*7z!w&(}+yC0%o)zolvDv{w%X6 z2P<2_4gU>=V~4nw1<{_PqoA$iCQ}@ujT(pdzK-3~{zMru?F{Ju-S%xpox$e%5ofa>cC7X6Dnwbh^z9 zc>nTySvpsTB2$NSw+GoYOz(eLmZzE8G2Z)=Zb#5`zKMJ;M z@di@ksU$hW6{)SX&~O_$)e_cSMxS(CRKRm{Bz%Fm=7%PDCJe-@+(P~CGjBE}<;b-6 z9yC%q8iCq8?DSr@CX!lwkRf%*Tcrw_OZr{W{LxK~IC&D+t0Pc4c}Dbu9eI9 z_1M60@N<&|m*aWq^(X7hZ(pB1JJEAON2bNQ(;|1%PRUb%CT=60ZoYFNNSqRiR9YYB z6Z}gb`fW4_i(6`;3V#-R2`nD4ZCgB%9UvYyWp!;!^3hha#$4oU_?Xi^gk$MF(SC%W zqwi*Arthy1%OtdR2c|1%$Sp&+dcJF1peb^2V?gOwSm!B6_#M4=ijbVN?@BWPXS8Nx z@y{CFG7lGy+%>;q?t(cKe~#cZ-m~c+rAnuktS&2hf&<7({%``C^;NGwm+Kxi%FVX6epdb@M5b!VZzaD{fk-3p`u zC%wvrw3OHVA=SdC`aEGTY`#3~S$hz+a!&PdtYRTw-(`%H3i+Ld#wj`0UgMdA z_K2pfd3H$4W4z23NDKYrpFRm?+}?w|qt0dnX7{9d6b*XPxeLQ>GHzNISOjin2w^gr zh#!hO{AJ!{QWNbI>%gRfR|#*M8u1RrgLdw1|v-^r5gJ%n;g{FTy#KdgCeM&Y!Z z!;L3J~>>72m!UpA*wY2n>jfCv7#7J6uWF3`rN0qp_f^J zh@?aV?*m7#Q|1g*f)-3g^b}v$TISlVhN-&FkHSNYUtE*L*W|h!4T!&U`?zOR1?tfu zu~g}5qv3wuTFEO_3YGim42%X64vPWW;Iq~nh~;dU7;cajc9vduD4n&x{8KdZnr7}4 z$-fQh{ovH$cD$xhAk1uySvhnAXc#n3IlL{y61xOXFg0>M7)RYdTDcg-OeteowWT}c zk>$G{dp`F4v*?A$!QTT)+Tr7;9Ao+Gf*7@%wcGZOM6B1og_O%pyKq&7LYky`PIi*;Q`Jn$&HA=&RHceyQqGRkj_lSV;l7!NVpzJN}(+Hm98bPMl zOC|XWW^y{G?cd+*x@~I;PtBiDk#^J*L3Y+8dZw&goi-JGb6?BR3|?QhXfRS1>i&ch zeO|k=C{r1Ey;q+~(gEk#qsLf2ukSqiWB$jfd3~;)9>@HjmH01~i2fA3F?*Ty^GobI zsztUnIX_&cM=IZIaBXTdi^kc^h4~QY=sU}H%84Mx$JnGEjUepxK~d|C;#XI&$Fz8c zVOk-EOx>)Ouh11r*#&)Rh4~MguFyD-*ogPNd)%}7?Y+Un<+qIVfK%FAP>L;FM?Fe0 z?R*-H$}22J=~ZqF=*wp$EFhLSoF7&G%z9Uh$EXrhqMkajuVayvh(|41SV0q-&>~k- zc&2p0b79FMwAHe?-_$Yts6$tT5GtO7pMlFFmCYQUJLFK`lG1)g43`k&&M!qHx&g(M zuhwwUsd27rVuV^cxwc&5x<;@gu2I;injDVh#$6?yOI2?wB~)!;m&j)Vm~x907wBYX z-&E84^?k1qzwq+bhwfTtzkyto@NLt@80Xvegr`gJuUyS};eG?!h7>al{C&-;!JP|h z+^BME&E667>XfzRi2KIb zZZnA;^Vy7@Z^_fsOROlm9Vze8iYBdk20zsgg}++BLbgil-oI?sarC*dNbIM9n2bj@ z#dC~~#3qNipi1IVVcpQ-FA|5RLZ+xySsjOmzSBDy9O zuY@?GHwn(1IOYqeTg3>gp2cfpsCRy}`owsJvN$#0F*rtV)W)GeJkudGiUnPMIX7lU z!V+1pl4wl{f( zx^s&*w6i*+zss}OF9BZp`5PnaukeLDJSFc|$&AFH!g}U|59I}sjF0n|R#y=&;u-jQ z2338`WqA8J7%{9V{pPHYpEx9pN0qYsld4RNvwPkd23q9^aVo zCNu~H|HjHHC3?Z!4%JRB9W0KXABSwH_$vRD$o7$?ze9lX%iQUd#Lm3_oX-JWuN3O6 zI~kJitG;w*wj`$fMz)CK5R5l-SKpy(@NMxM&JAd~|xzGuJbw zsj{RPRo+3rG<1If$&F;o^wm^C;TxRyBckX1ZXK|_xNX`BER_iBw>=aWXf$nf*W+Bg zJhO5>57wYb@y=0Op7@wmw`lvw1t+PI2g`DyND1e)sX`UO6ir>6I)cBAFq^;@^ zrAO9hEwj(Ru=8~M43C^Ehz6eYm4>T$y&J%M)%`?RsS$23W}|ga6Ie8dNgWNIDck1nCvF$Z*NW6KepF<7Kg;(Jtk=$s@nrXc%<=cgAnitafj0EDk!MRe^Ks?N zh~ECq1{Bs+ZM6bH%FG?yL{;F{yo|d#;!wEMHKHHNep7Hon@e`|c!p_Qzgba9Ei;pF zMJihi%ZcVsvB!lvL{$>fwvdOdNmA(~>I$fSI8-%b5@E!18URWOXB25krp*P}~6ocvRxcvxN+?sIqoII+v znl0vD9O2Sq$`ir5Nxk&`8d{|)K2i^XkI64g=)>DoZH9Z=+YVi*{=Pt!tk2~fKdVY1 z-!Q)vMRYKaDZ+)TCCnN1@Si9}_U5!weyq$!?wIWKs~HL}^*XIuW3&t;(>c{J`7$vF z%bW{s27jOlbfm?Kia6pbPdaN{ImQEFyvTo;gtyglTpA*wNh)%L=vq~^*@QLyIJ)(( z^G{RX%(Sk2Pl#D?RXB0I!hJ9p+d5$FBayEA)#**?r&W#O;EZm8yK3UI-J2Pt-yDc{ zOhwn9DPRA!>f@w6MVrS`jCgs-O>}G}!(gS)R@(w4#OtN2=1T9}tdX0rey6v0W8TXE zp9rhim|E9YoZu5ftv4f#85^*m$|CVin&FRRW5Szhk_%?TiR`IEl+#W zk$r)RuPd^h!tcy{?2X;9^_F-*-3s4*#392tNqD8r-4bc$on3(0CqcCs+ zpUG}9CUAgNR~Ez~;)sIRiPdFAXiuVqK(Cv`E%6ww+y_?;O^Of)c*PbPH#o*}Mjh^( zd>oJ65AY3qpM1Qcx*j35d|l#NGCG@}F($Jm5$0+Y;795P8>^w=*9XS12>A35oDd|2joQw@#aFyBgS)uXGjwp=Rf z3@ho-CR)*S`WDXloKkxQMy&>xDJCY*FyHRD<76WAwDF{vo-(tu~TZ6$$N zp1iNc+3hHqj%dni4q+1*&F1tIERU(^#lbDC*Cn`)M_u+UP$^A9JhxuTO#>~mXKA)l z6{;7%Xb+PAFYewuEUK(oA7#t|K|myfN)nKaG?_sGC1(&Mh(r-+a)wqA5Xq8+CMY>0 zAUU+;43aY~S+Zmrn&z%nXGXu#`Mz_0_xGH0@ALQ%HtgPe?NzI)-g@gTGmo1YyvkJG zWhP9B3eZ`m-FHAaP%ZfP3nKUW5Dm-kDSug7U^#k|e=K~Wj@STX5b z4&LkGR5yr3XZr``7`>uLS@jM(+Srde4zf-=#yK4dim=Z6M}9gDoWbENV`sUoXA`$` zQS9p_krjrsbR|tM4|izdMNvUjj$=k8Z{a$F95bCBpTH#c<(HWnyF0o^Z}Kux1)p-y zKZF#^j-}it?q!r0JyB&Mcn6=i-_@G^!Z5{#_)ueek?dzP4i_?0^F0*2+aLGC%xX|C zqB&Oa>S5u?H5awin0?S4zs1a~H<`uBuh#8_txWPNPl#oKwd4*nsl;Tn=USvkX2KK3{LTYwo4&`#t>gIXUzN-4q_m}PqGCB!GX|#1$ zbgrEsZsHVn-k^#?+`bf6m@&U}v1NG!V&JG#7b1uX%H*`~yS+7O&lpE6(fws-MVHIC zhF9bk(u(gW6f49|n6}=-9j359K6hW-Q4VwRNWJxPqYvl;n|5WFRi!S~lrT(0-416S zBkI&MLiGv4Fe-EFG)KK{yAv3)_1}@gcRN)Pb@rQ4;yItJ4u9`(8}}2Y#`Qnx29kwd)@ z|7&=|?(!`UT9=7#>9l<|sGEVtJL?xDdMGdE9qk{VM90q}n`vbBQ81zoJ&RB&hG~07 z%)KsE_pG_f&3XG}Nw!oPRTM?h49(I0>?+d-6kJRfB41tS%GGKkG3DWrL*z669 zMterDlh-p6n;M~_=$;JVU7ESs6|WaRzxrkqa;OKXR=(31J_!57(#kGh8?3k2 zxxrq6g~K(Q@)gxJNfWUf^v%o*k0@MV2cK8V#%i~_dd{1KykrTuaL(xTc?A@nw?

    z?2LU)NwA&H{MWSkR@7oGPSVT^YKj@?b?a^voETyGZ4ZPX-YCwg{HGUwSat+y@2Wd9 z8OQ&ryi>wa2jG+5Z2jK9NwyFR^QvOzynPd#<8S3l-~vTG_g8B ze}Q~=08#3FA9kmuei>`?;TE{v2G!%&_kovBRD9Wh8@i3?#n1*#^~kV~H%8u^dv(^E-}u%e{&@|LS&jOOH+#J-qxmn}wm++- zQ^oiz>mivu4RF4I2fHXaYEGQb_ z7h9H$f;sFV)?1Pp=05Z1G=T4a&L42WAKV^+t-2_0y(`-{Y{7PaYhf30bT~zKijB-;PkdDV%K$asG#xNt+UR@3fN2IDsc;cii|eE-siW6`QzDoJI}s^l)D{n zRbZRmkTz|si2W=Cb1rnPVohZI{llPWMPtGFUD(ks|F53S4Lwbx*D>!q^2!#g=Hszb zm~fM*b!VrjfFIlpqA7iem+|hzr;X@dlRZOaBHO*#0qkY#DI0yhK4BIO1_P2vff9x^;Z=|4Y)qj-@HYKOun5&68G2Rrm8(d8g1y?3Sa zV~_Qz(7GWUhgLHYQA!$}K{A~|&5+9OS%ogWnJ_8;u1Db0-#ZtZ8WRqO6R=D?pl$X< z^Uo_@g%uu)tx1{2z2=+$+j4lnn+Kmrc`kQ(Zs8T@BrvFkB%v34@)Qj6b$@lf)erFX zI7l}j@3T3?f5W+c1}q*>5&7+xcL7E(e7ghCk1EoBa#kEXCMhn8;(m>Str0JA-6H9 z__kvFK)?&<6rdlzir~Gym6??*V80k14d%>6{YST>aTa?!O+kT!=*c7ZcZrU|Kr9L8 z1L*t4-qWWD4PEDjl&A@ZQ43>ooF{PvU+&=FEV3T`m7gs#@MYKzKB!AC{P{;590xh@ zV!hEF=d4ae1#v&8Y&`W=1z6SO9yqqZzpo3S?H2I_d}0Hn4fNTre?6+yV-fteZm^?0 zGH#{G+B4jPTrk@PVhu_vs-obJ&(rGSQxk}NPaF5VNMQ9k>xhT*yNTF_B*_MZMM;8|Zkuo?YNv2*Kg}oxJxocZV?`0r@;L8ss7b__d1FSU)?K9e>74vhTKkjR?9?s#K$h{- zl`p&3_#~f~OcR+np26`UCYb~D2ivaGYP<|^gwnQJj&yG+XN*Wuk8Fi}ib+p2MbqR{ z=|;Lu$k{HM<-_-==DYGE_Fa@P`hbr-MOS<68C(cwq4Mzp>hn6PBdK_)=`C<-4i&TW ztk?MP$C8h+>H4I;BhfI^(Qp=YH%kHLE3)t4-P;h+h=3$!PhdI^0!lJ95y@zBLj#^jLvq@Oyj+FD{ zbt(Fe>7MxB4vpPW6uZ^bZEeW(OX71?)Pnk8KF+}zc@>QDr~IfPpvi;t9_J_a`ML}L z_RbDZG&(TTajBBb-K0SKvD+1c3v*~B~4 z&h@Hk&$@hNF~)D*WFOL{CA`GJF{k_cerQ9XIj$V%giKf~Q2J-k5ps8Cixf3dR;+$D z5+w_x+vGfGN`OZ6g?hq~bW=BVucb*)B<6;R5fNA9<7bPXqHoP8onbXpMm#WD(23oG zjM}ib*z3%$Y-QZUt~nT4v2h-{ZB*zU(rYZGV}BiEkC>!3Ww!}JXzo^Q+T@5gKJM7qE22-Os2S4EzlzD0$DqIA4oI&d43j_ zg9#Cs0+thG0` zl4*BZF>n`=LC7jLl+v%uwN&0Zx}fqHd*EvwVZtxM1mnYW3ielp){9(Hx^$J1>w|jl zq8`(8UEb_<8(?0ps=_Y<|w5D>%p-a&eC zJoVbQxMy^~57>LEHTaxp0|2`{r};~Ed_kgfigx$ zJ9-%^HCB{yP2D8i^>rnSn7P5x$M-9NjcOcmpuVv)Ng)=m?^y4A zTU~ySmVr|sjn8J#&&X`m1q70Q6jjtt{DnPcmeF zjOuvJE5*8ea-43fff@6vyVJ*7-cbC?j^B3S*Ifhwpa!$DK^UjKxa4D?s48ipg~5cg zjBS5J!NbymsLtCkzp;vt+knj4>nwF5pXo*4L0S#EEPDqu?7vfZu*H865ZL)r$K(@5 zkGKi*<2n<&Ta(@mX~pI{#FiXG&jrrG;58ud{m!9>AjrhS?>z54?I+}!Y&^JhO2$Zi zgNH4Nyaa)mH0BHi{yh*VXh~wGSL`pj)m0tK&+ zT}u$P-oBG3Vm%?7@mWqdI+>80D=7?&wNf6EnJ&+@d3?}E4s1S3X#=u&V7}SQs_$1_ zwpK}UH9r@fIyUwxQJW<+|5d_Vq56U?2zGQ@K1**fCa9XzTgRN6D*S+1er$tM2j(o# zZ$^A1(Q+BJIKyC{Ez8UDyxF|ylTNS~7Ac~IaX;q^R(t_DF(y&hck5ciMJ9II5;m5s zBW4R;|3|Ps%_+GGLIjVG0F-!KP)9aKLFo1Z4olp8WL06EwC z3y&+$$R%i51nH2_8;={kANoM+( zAJwy88Sv*#>u*f1*|iK$3LNL6LV%-^__9jF0B${pk-58|F)6Y>co7C=vT za45s|E*;{Iqc_q@a36%dWw|m_EIZ1qWd3EXaW`*_oa%c~lNHuFHblr1|J{-pSE1lMYylj$w6jnKAT5r=@#OEv zc=p_8-FmluTwtHQi2|kZntq`w)|A1qMu1wWa10K~AvIw?_a*h?d_|DZJq-leeal|Q zVucUAz%kqov}M7}@t*`k-||~t`N23*Yx~KxjLXa*y6jK`u zxbVHhA?z5#4v>5o7Brv(dBsi`_rx8?8KD1rP@088Te;ckn1FxSyVc!AXi`;6{|*uu ze&8WE{_+t2!ytle8@eL_-I9O~gKa2aYDD)=Ppw6Z?sKtbTg)_1np#m0BX=;-bDM2UQUijSU#p@a3ncsSAhBvC^A8vrgd zDz;s%+?4P9m^g2B>LmD&hE9F+GvBUOP{4n*p@(S$I7)gT|NQcBA)`V(&o?|MVXvN% z)P8&pdtS<84%jz-g>+3EVRru@^*JKlclFTzFl#7uElclku>yH$x&B^jfYSOB0^NqF z3}k)$?Ynzyf=WIA{o^GZ)>DY=mUS)o_X8klX=+35KY{SDqjJI4P^7T!TE&ZkmTNr%qjYUq@lYIyHX<2ef5+gX+>BZkkdC`AB(#^1PGLmQy2X=V6wh# zNd=9$^wu30G|7G0;b=_XKfoGjO!yx-5<;~9M4ODtUYv)hAc#Kx*_Vc?v;QLw2iF- z2&K6Y5m4g1&&2|{{}zi3I0>+tU?vc`l$!dd2Z>{ z3n2HhLlC>~{KhwyvY?t3ufb{_OhNk!DgFTHopkqjWo6eC2=&;6i#i2I%YKkC1zEk} zocexWC%5`9I-7!L@A~xXoY!p6WNMsTqQBljfZ9_vJ zCaY2z)gCzsR0zYc7}z#{TG7UmLa{nRvA#hQOeOdeay2$WQEUq%+;`>0^_!6o=D>Er zF8>9nQ(c+uJix=^ALmu=7|e!%fSjd3l)4Y0Mny8qSm7ei9@yCD1U8 zZ;C|(w#-3Q-PN*scq{`_6>@m$as_SC5&K?o07YD*r{!ZHQ)xz~f9`1OkL=qJJ8{QC zsKVRE!Z%mYb?R+MCexsg?0fn`w{mrFsHMw$*$krsf>>-8aqvlwar>E8cVPEcMg;a? zzu$~}l~?E0=fCeV>QR^**&=R5Eu^RiE!i95s!HCk7K$sgrW*u-lMHiF<9(bRsuU`kqz7atyGf#c=_s zB#4_aI`d7Y$#q`K!jH5~@Dg@KaFw0O=V@spnp-Bc)3jMEhU}Twlv9+i&1!WWhYa6u z1M}^?M>ZK1Tpm$G?D0p8q$TtbRL*T@^kdhcZVoD&E)l^2vvvC9o{&@h(h*U|yQQ(+ z>A0x5K;Q2;Pla88J085Zn&YRi4}Y>zl16EFAdxxRGCz-6xGP4@$Gq{XwAn zN9Ms(Gl6ExZ2(S_&jh;(`&DE-Fj@p!T`zX@^vQ{mW#XzS{Z$#eJH{<_USoskpk)5*070h#mL88_#U_8S;T&6*?` z#T*oUfNX|;N`|mRJT3|>m!F7aI51GSP((KSOb(1F0gy_Dc986ug@jO$nPM%l`165^ zCt9}>%mXQ}6W<?$ZQpAE&c4Ubw@Vc`U5h(h@ok;+aX{FQZ= z1hOzvt+Gz;4R7??4+p3tMp8ntGHVVLM?Ei4r9T?I0ttR?#x;4uo>VQ)QMT;xvig@D zv9p^dpCEELP*S};a36Y;*m?CqSmory#^>C3Yu8BwyHZaQda?Z~pA1c)8OVUUVHh+G zxOv>oSZvqIKhHsOJ2oJgwR>u!?DQoxN8xH^14GG6nH9CobkgW)#o3YAY7~60m`9Q; z>g!)&1KNxYh+kg*(pn{a12RmXC557L+c$aJ3Sb~k!4^7kE(0aq0)?E~p-*hi)n*gi zN{2o=+pQlCvS;ZGc+{(TBlf_<2mcYJYuaKMUf`Zl0mEq+oH9Tx;TG6a zE~w6->ATT68l3!*H)>$_?fk!bpaw7R2wwW=3k)qJA*&0d$}|Nxj~VLI`4=VzRT_`PpqU)iW>81@SdqY$v!s zCdy|Ob|En9LF33gbi@~WLU?HL&8G`;{FC@hP|Xf9@xb$RzS_Ua1*b$r!#Q6GPyji4 zg+o)-E@VQ_BWjpb^xLz%OJi5kv>%)I*mLOf4;^1{r z5{`A3`<&ooZ=AcUxoM;e3$U>;b_Co;FxrIYaca$9WOMQ7_ z_AN*{O9O)z_|yy$@2r+ZQf^pDYzw1#YY`b0Fg}WvWV(Tf-Dysiov(!o+Bqm8Buz;b zPts#E?mDJqyhDb;Qc=G;7+ORE@b@rM8Los-vb!kygFfkiK#!STQ5U(3R0*xKePl7! zCLN)!huy73FU%vVTqA!dPJxJp@pcGr6FM-O;)W@`CoW!DYIZgzD_o-{8+fR1m=>vr zpKmJp&21-K-z2P2-VLmIdlrOw*mC>76vtECJYHQ@;aoTX&v$QH!gRmS?EEJIdmxn4 z6bQn`?Lw6ac1dT$_{OXV1cy;VVZf?J@p@OtpIVq~O zkgH72Q*C5Dm@DQHulp<`#51lmjeqAVr6RCShl{^@*&$u{wqOEIOtt|RmxRG%FNuSG z>CL6`dHl*(GLzK2))>h{%WzFT$3eSI<5HC^rdIis zuMJK;e>~d(ZEX`QBePG7HA~~dojK{a-zSY-hx`plbcJ4WOaFLY`6klMS0;vkhsBw! zN$SW@)=UR%g&7GRRlYh&dUUUjmhvYR5WqH1R_Wf5+|J={a+l1?b%;-1jGKWHEE-z>2ucQpX~tHaKbm zD#J88f~S+l#nxo!2fNR#!7_bAUb$)UB_gAE?J`vm)^`?GLiCnY1l=)`M?+zHmCtX} z-)(HRA2l&;mo0R+B?%0#F9+4yRx(lDx3}Z!`4&U(DKBAT_~+$GvN}^5$JfYmxFE&i z3Okl29aI#ZT)N%ZjY02vMD6!|9Iu0d8*7v5&q=l-Wr5%-&I25<^#5Ax2Yi<4q$L50 zjHS+aKJ(oqrSsT)a9AE=thfPRGn6%P`oc13d?4v22{7cp(u6O}3~Y$^58RMpJ{?C) zeLo65c0&zBz(yEA#c$e$dypG*e7&k-Be<%;w!t@W`gnWmfh%2 zm#vQA1nX+Y{x#S8f~ozF!UZ4%2Fjv&vBIwEl@>R~55Y`;{jEpbzqRB4aa(Of_~@R& z>YXBxeC8SCSAX_qw>m`<_?7J;*qI=Tz=D5{;IGPaDZa9F+7PZE^+lrJeZx1FYrlYf zSpHYN%p#G3(0bp7PNkC)TFUqbDp8>=V&}tcd_U1Xz4s5PsHm*}`WjuAg%m6ksJhUk ztH*vEG*4q8lxn-xvwwX}wuiaU;Z`qr*RRD6(1A|+H`$-cGzR|0Y5U*CbeczzQh-_a z`~MD5<^RhJr%*kB_dd9eWqLj07SAhR%v4E}j|OhdLF(^0=PxNl%R_rC3e}eXw@YtI_>Ie>D+Ln-K29R zT^b89V7W?uFJ5V`Jv?f7z&)#_FZ1PO@@4Fd@q1U8fY=|p6TD!vJ%4D_u&CCbAFS&> zRT*tjwluNzBsyAkL~?#dAQvH_F{DTa~o#;yz$vLZ{zA*SC|uT zEMz^Snvd^2WRKK!Yn5@xGcpel6RkO9ob#SO=$AShzwlx=Cd7IC19_x5rNQbkS4V#6 z)9|&}>wlUaRq{ z^2zIYY}4SnWPN|66FmO*%M9p#%f0rOj`C{cv?Mi5?89l1`JAV=pKZrSEQ$}My_J4n zN)TIj9CA*@W!&^$!J~kTsPhop=^tVpO$@_pu9KYyo7rpuQ;ol^_t^86jV-^j zut0(20Sb^cah|OF1bI~!6;*xuiejylF{nY6(2vYSJweMLNQbeGt?d2?T@SC)wWgQn zvxWlQ6|dYDMHvwmc{#-4W~5&aa1RM@E)aJniHdp~D&ta8CuJ_jw3hM}Xo*(BFkmiZ z%qjHDMt$n+fbxz7Rnni@<%=$>CkyBy)N*bSDIzp5Xq#awUE0%kyXGcu+1NHkDt4s{ zyxN83Hj)=kmHpo%ECX=}Kg4HbqqkD5;Rja-<4mcgkBYfd%Fy{$hs-U{l7|b@bvhqL zpI1bVy093-hDJBfkAo|&GZx^8?Q_lZt>=4@O`i)>T zw{f5{2^mW{7`W$0*~l;&nsuPp9|o%SePjWiD$?K9Br9{?=GwVw>oA@SRk^8~Vqifg zm(#ehyDu}^fAl5VGH@hou*lPGv4EA5MP+WP=S13; zENtKLAePO#jhO?;Q|WBveOVnJp{8xqbCOF*C^e`yFCn{@*AVO>bN z$L2n%3Km9SZ*1~xuSu?~Anw6Z!(>}Pk0Ds;GQP)AC{tLd^w-154OcQ0|Wm> z449y?w@!{ackxE7b1O-dIp2X=*bL?N=DqH=?<*GV`yin`{W`gN5!vaj^y;RS*Qo;G zmJec=6s@9EBlPJQ3NxmB`krOmjrP4gm)d9id<2;w;J&|gAGr^(r>cI{nLlVoMgN{= z^kLqY7(xZ|_unTzr*>AGV}}8Y4xi*I8eJ%#+<@44R5B6Q@TbZ!yU{MYU?dfhws2@E zMIB^gv$g$U%1S!>xSG`X2Tv^Qa<`Gxosbs`MhuZdY*oOFR_-YyJypsy5o;GNRDq%v zc;{KMNQ}pLW;)sTE?}t**{6E!%3dv&Z|5=e{sLoj(*n!0>#slNM&4yNG-jAPWn1sC zi;p+<>Gm}9D|z@;vo%=nTqh((sBYD^M&?8FSy;VOn^`C6Bke2viN6FKcTsNwYWjx3 zsbSO!mAAMGVB#xl1-)+^1a%;?7|C%k+CosVbFn75Xc{EE5e|pMP8`wK!gwZMj~NOs z$~bz!%vQDN3<5;X!Y{k(o16Q=nqtf`l8p0-2RhO7rEG}<2(cjc62rP-jor?5z3ZM; z-};**1jqhhvzv3E~#8C6M6`dzw3pJ{XZLd$j!g^H~~8LJFHV^qIEOwOI- zoEHPm@;^HLJD)Bt|9y5WvFfeQuXq{Dn{^ymBt|yXWCt%k3jcH`@)LY%W`K3DlNUI& z@X8XoSIwN8Su_bfi8SfT4g#>SJ^NQZyPs}tux!eeB=Nqi3_dxRD8bcu9XKj=@PHCd z%wb?9DucS5UIZ*8TUrojVRvl?gHfa8#n551KWbvd8z4qr+Vna$TES7^YIFO{)VKg~ zv{E8-Ne=eGSe9?8jE*B6BOhs>?0poCD4TgHgN4w*^O@Y*YggoMfBk&%l1U#ATL`7W zulU9O`)I}4hg^vlgS3a*+MEja`^aTJ2{6LKq#1aUXLfh9K&-2}fn^@8eeS$GNwO)TNs(g4I}x;R zL}ua)@^RW;{2Km<=uGj(L@Yqzm!E%RTo#jw&tS=}ii<5C&k*u(mqVn70H z`jcKQ1S9gsDR$CN=058y)_8^BHb){kr0+GeSN1JS6_n0ho2-I@{XAvelPYH1;>f*5 zh~=eff*B^q)2ftjtQ)oeE&V7XfrgxmIIQ|eZp!DT?lVvZD1MTwvRj$IK!);C)V;yr z2&K??NVZ+4%swxYbYsvAn6eGPFy4ko83FNWQ9C>}l3!yqaO+#t7i)tRq^^EROkhyeYxxc&^uga>c! zAt_fmG*E47|nHgy&_>VXJG?X8=_>nJ!^r#C!U* z{X2Q#;W)lH2=5D-bF+nO_=TqS-@8EjS!g|cJe~zmkF!W51;P~d@cSwq_(^d4&2P3{ zxREYLMY+gIzUrgq?dpUHU6SY*GI{eL1+b6DB7M?@P?Jxr(};y9+RcFmX&W#5gVV3b z?*Gc3WB@-q35X7>21uT_)T7>=MO0PM483fvNk0?B)?H-<&Y@+t*u*3ufW`~z zkjz63V^i=t?lON&^mj}nGpW{y-SY?Zp(%6TX5^W&DpPkelQ=|ZU&%-@pB}U=ud#}~ zE$LvusbI8wwh7z$9M(! zzKrosx6qu0b|mb&Lasa6(KvIye{f7@yE+d?ZsQBnVH9D%`Pz4yMBW{PnF~g+ItadZ<>7dRL!47MF!p#1W=9 zO#y!PfybY%Rq;+AqX3kY2hbgND*tV7cDJY8rKVrIq{gi=Xw(;w2mDpbp<}vcKb@0**nbmvlQ|FPVd*B z5YxYH{QA0V-`J3xQ2Us4!icla-FVTVgPM5O(_Qf4+Gvv9apwCwdhKqjn`7(l6+uhyckMlHoT`>ZJ5vZ3N+HuZ^4T9_Za$d7G0+qG_Bv=@{3UGCawdSnBUAz3Q6NHn zNn-Uq@|Sg7La;`wsMoEHAXdt(&QyCu4w39lQ;*RfjN`{hAJzonwE{pV1b4|$L_?WB z-b^PV&H5VORj8oZWK3xNBVI7^H9qDHmHrpRhfn-94&KW( zp#cgtP*kJKoBf5=lQa*Nt-l)fmT6GE4>HTjB~UwA|Utx?DbohF0tmjjw=ad3aa|7!#7eg!3IEue^7b$`C&lS)^CvbH78*t=I zUKAkL7xB24(ADowIIh94#+$|;_W-C8A{ImgXmPNWA<&X^c%UKxqXqq;RDur6p?9b` z`~uCRKdp=|Yl(u7Qc7WO;19%3XtT5_s;it)8)wR|g8yy0Qj zL-Y~_^}?Ev1-=>QtEIoRK43vZ^@rx>(LyI3sYC-5o^{DIinkWsGGou^lfO8=>FxRh zVZ{iOy1yt&@Y~Rwcj!o*(GEP8DH`pC4u-pY=#9z1yLNt+aB}kGSe(ZF?oCghzTONq zj#L0X02F01^1dafJ=sQmIU^6XW_N63XyiZgcOth@Z`4xs3B{scpnuEw%$T(346-Ve zV;pYByQ;cCme5x%63(q9L!pg`qd=1Id}YUM>pFpre7N0u6#L-7p9qrV(IJx<>}32w z`&;e%7~L_V6dq+{M;njAA@^-i6HG&8t9_#_-B%O7Pb797C?-JUb`er*^hN4hi<2KQ z5HGGjnA77TwUTMiy0-lf`xJ+V@T-0dKLgrVuCMzMlhi2c2pYW}x?V!S2or$El8Cyry^+n!tB}#8b!k zE8tlwfkw-I5j37j4GiJRC5*I=Rpc(rLG)`IrRj~i?z33lkve5p+;6X>mEy2dKbdck z=1DQ&)aF`};QTSwz~f`8_I)hUXn|#|7raBuZ8wy)ONPU;nWa_f5O78VPFv8&^^LwW zlvsWQrb49LlU1?sVBaXZHk7f?U%8b!_2b58gH3y^Bs|A4U#Pu)hI^*eKcmufu(V#X zk6_3-qlzv_$#2e;rR}UHQ&a(WTh;?Q3!n6=BRRMr(sUx@@=S~U%?lDRCmyzo!KtOc zAPvmAd6Zc z;L+Mw>_ct|L0-}F7Q?JQ&Rr$fsJZ?J$ig+=JsrpZcsxNHcOP?JBJ%p>D+aX%Ev{24 zCg7l$$sm>E@}}h$0RGVL-V$2QSy13?c%@)xak;$2y&k66MmvAEX`Fj?Heu&H4N^NNS< znHy}JYNfJGFDyg??rFa$dkVHS!#)9SlLH2xbZf)+r^XZv=%z0j-iS^=kGfJ*a+KE zi`~6|&BGcpZn-8v6wZtnQ92uuq@7hXEOUhv|H6-N7gQA@fsM}BUeBjxip@#Q!nt)x z|FhYJ2*0g$bJVXENSBnvA6+tNSoCS9Ejda7Y;T;xtqp87cuvfQ`^*tbWyqCTp~xY6`y=v1Ln zKkrIS3FCuBk<0z5hE`2ST5$mlH;6l9L`lgzp$S@zjeMSl0YXfu!520b9K6~!y7dbp z>Co52)yd(z*S;t0fn^GkzM|T0X)h}_Eb7r1NLRmpqD51;KlL{5%{+OvGTX|_(F_^R zowsVFv3~sQCdAk(de}QO^(O0srk9(Bcg;`XJdyheIXxPjWT2hw^+O&ls{`^3g%!#* zSkkJnN|ZPrc5UbZoWtyyBttsIWZtCN#-i(H@;*20EZo3;eeE*s^bJgvmFjy5686%h zbk#uCNjbZMA~B5Q_0<%O6&oN~bpRFBPpTF{_BI^NGEKIxR}_e{(5AogX6ts`1RkB) zabPMyVgdanT)lR;kL)z5Zz3;+q2=#GgyZ_YfGHr(q-VaLZG_jq{ZRkx1Nzhsp3~ltg;SFr#31|fR0x3vhj72&rk-I%- z7w27@S(am1=b-P-`t&6Wp2o?R`L`^E^QA`}&ztZ4L^g$6Iqecp!MTd(j~)N9d+s}R zm>)obP(3GbLqMiR5)@E109^-=U|y62rc@kZ4ipkZEWRhvI8Qy*+aDRMcCfSCvcEAv zQvLZP=nMO%$kT+{oY%n0vjEz&++TQ(Bfd~OW7y@dx;n8sq+hTru{Ka1kaC~$V~p3T z_9tO~A==V@fFT=g{`q^^NlCQdeGSOA-+dtk?JR5lMGA`Q6t4N} zYx;u&(-J&lu-(3<2?zrA>^XX?mQv0u#zB7|Q{Kn~t$z^mK_=LIgF*nX^S`JK@c$=x zk~I8kE9ohmXf`EE*JaeAB>E9x4@v%8y9AO2KM^1TILuW0`e9X-*KO|p zw#k}_3CudTG4p_`sD_=A3`i}bbR34^6I%?|_(1O&(ch`J-;S*Bbg8}`QA9J)t@afF zAz#62I$lMsuHua#|s4EiX6q|A8vg@6}0k%i$%|U+3~FCC-y? z(n&v{nSkD`@++*z8(=+x)kj`c!aBN^+i#En>}jY4VXl;1SG#4?cpJ<5X_+ub>^Vpi z&-a+Y%tREnogYlyJGd+m41mjqAAkL}10ldJ@&T0UbJk(F9 zH->KpU>)-(0S($^jGcl;p&Ku;r2y_(;U#=(9$WX0JY2l0w?|cxP8m$uKa>E#A_Nd$ zQl_4PYJDE*y>&a`@zP=$H5|*Uo{MMK`aaX^ngzP2i(v}G=29RRE zZIi=)#U$2XS9u)-#{DLO7CT><5DGw+Xa&d;sTB^toPf*@vya~dN<=ehG$)9k+;vaa z`HJ4WN^qiUW_0r3(nYr_<~z1p^SVxc{%~KJb-Fs>d%MqOh4pR`i=yC@MS^>AtBG>J zXn)drRcj*20OP)gpzn12Rh96eh$wE$@9lw(V?<34nf>YmxU&>;@=J5WT3#KJ#3?uv zwvZ-Zv760_hs>cwZrazOPYsG=hm6CUqcfKbVPi8<)lTNv~35ug};x?bFY4P~%o} z%>D@48(&l#`u%Xw3QpilP|0t3`C6;QiBWT6w$SsM>mICXM#braN^pl=rJH^CyDfW0 zLqD#xg^dKcQmVOkz^8dz+_O)N1}y4i944hF>8WoC!4hng2=>%CF1~Lr@ge96~e40%$U%W}&gqK zBk*Yknz5!D_2o(8+qhMyxtIK?m?vJqglMcslEK_laI6n5onm`A1i|k*^?4{?Wg^EUc3GwjYcDHb>_rob zVTejkhgC3FE1bd-hKz3XIR^k`n6KyuDzt0;%Jn3V*xXnkLcw)ro7A)!S-%eYO#UKG z70p70mA&5|)7G(421G>}cjFm*#mw6TD#YOzQTS6$x7Qt#nuSbTi zm;+@4v;6wUKd`+NF$VtN>EiP( z(Z;TvjtP@7tm_w7()pEIm(kJx26F~e}F8|egk#P4&x8WpH zI&+6@dDf^>6JXEY?pv8JvAS~HVOrq<>#*0%H=^;!W|;dU$D4d)QJ?JOjTUqLL6;Uk zQWSKae_=ek-OIJ#9+uCl!e+?>(TGsJbP||XBgj5seuX#ItY0?Y`_?cTdBvJq*iYkB z*^4SKdBx1+pmWF>1L5y|F-sTnE5QqFSFv~R&tD1e!Sl%3DeUb*?RJU<*yj{w1_qBmW;spMYF3nRXCX656^)l@j-;coO*__q|jfYX29ilqs3Y}Sv@ zGvD<&;mM9JiAGrWTr);?jut?u*j7`?Dh<7~vVgIIlgP^H;xcbZk(m^ftRb$~&D8G# zoot_k*@)iIXi9~g${Y3k^RpVmFIn-FN@jH#$+z9CvxiAKU+LgM)ydXKx@V(x3r;V+Bs93^P|B12>ZpxXA5IX`-0=fW3#=ruh) zkB?|K*{S%;hBu6*;xf!|nn!#3^v@7Sq$@nsmwKbXYG4plY4Q#iS&CpK4!9r|KQ+VR z#omnM$@|wxR$h;EJ?e0@9Z5;)Qjv!YyIIn6LyL7v^8ab?OW>jY-hX|+rG-)vilnlY zOp=hjWQoWUDrBu8W{fTSQc8A;2opl~eH$jE>@tH%_GPk{wK2$KjC(#x%Wt{=d++Oa zU-!OV_kLczVvaNCbI$X;&+|Ozoaa0bYfX=DMci}lMvlJ)cbNGFyO+AJlh_6&kxaQm z*18s@y^H{6qdH{+%qFOrH1;<$- z#!L=+0%cIlZa6haPeI#nuF8s|#!(#hW+f+Bi+Y?Vww69wkYIu0`uwXv0{?KSgWN(? z94ni6D>2<)^F4s=?^h+kt*v)W#1Ig|_J71H0w=!_XDB!^3w<_pW(Z42s|RaMgV%dJGiE z`mcx|8T){<#5+bPptq2HAp;%V>0GeZ4!nGZj_%%Fo*$udaPPt2e?0eq7cxll2p0RB zB_M_}_yomt{#8Op4>@G~1qF}Ve9l9kte`+uKOZgV)BkVk|I-RW#QzOocxynG=r;C% z0i@PKQtjt+{JPD?B?jn9+kyY*f&Sko)6IErkg)n62?&vMH*^~C^I?E?`L+O={qwo^ zHzdKK8^J%H7pA!sGzjYx4P2h>hsNyL1y6YKVa*sv$+T1*CE+t&fI?W5deKRcSuiA91Ha+erg+`y49hta^&6H<0{8tC@4}a zG#_6OG)u@9^2-+aZg`t8E@^lgn%Wc&{?R^##|83pB8?Cfy?po1@b#5&^k@Elo4^7> zgU^b;&k9JFP#SBc;4d(%;BONWeISL;pTKNUQWxDnT;ssmW)(;nmfR@D3^1`r_q!@z z4k1L;{)=Kn0+;uA)U`O&x%RR7wW?|raE^yL`po7LY7~56dfFEm7cGh zf4z!Rj0_d0k-~jEL0CO-Nf7?3dD-9?qQstb?QQ?ivbZSWA(LjGA5-@Mn27RarWC#g zt3X&;Exqz(X7GEk8z@osZ^XFA{GGxVNQkJjQZ+BBbDeH8E2;bRrAL3yRnrn)5d(9> zSv#v_e~{>1 z`G^X9Nuk0n_&2ik4Rb&gZwAyn04p4KE`Rf#z9RoX--z$sL#_Qo_Ym1!OtUxV-PwPL z!t0ttq_X<)XG6ZEO z{?@?M0j7pTAA*3$Y-sDxxIv8&b~04L6pmav{T(42 zkO(AoC2oMVF!ylU_Yq+FhTHS1Y3@KeJi0*Jrgcjf-iCiCV* zIe{s?siM8-Y!E(sMfX-cBCn)aYQ;Q*wR4-{Y>u%^+7#Hh>eJ59VR2|wt12~v0y-F- zt^QKO2qYH>$jJ@PhD8atQbJMR%IY>G87Y(&{h~I~IjL4`Q)~k4w#?dnpQ$ACgg>zf z#1#aZp>O{HnjU@WLw&-u5n-@qfpq=o|IaFw^j!aa>>alw=^AqMVgj`gp|>s3Jt*&UQoesF_@wQ8699B^`1(q z)k7)q$ah5D%XhBO8cgg~Dd^+xA~cK2Yf?uPL-?|B$*J+p{?9mpKOTtmZnc%R8JcyEBl9s6V9AbZh_u9n(G5qAeqbU1pQ)L zGk?7w!X;QWKYn5BXAvO^JUdiSh%Dg6sj(N+>rHD=)Xh2&D3O#Iqq_Luvhi3w`U^d$ z&phvFE`O`{JTU}x@+NO|xZ+7*A9&D?zYVyj+)l2)&wTaZwNI|W6N;P=kq9o+IWZE35lqW<}5d(gRa4}2 zi)U>^uMqbyNO&8l z0&S5}b&N1QP_R(oC&xIe8v&#l8J4bG9HgY^S1 znDakXI&`UhhF(^0l&PDIq^lurj0@?PoFp6@i<5|iyBuh9v~tVqR}JqT<69T&6;>pC@izt&# zRx8n$PtaQzFti0<&+3)aa|~ri7FQwho+SYjfs)?}ufGvT>Ep%2`$8vUOJurdH1=3B zW0eh({mf~*5|jL*gCEszKNA@}83#KYpt^Ql$bucMT1@ZKot(K`%GX^(DKTmilZ%;8 z2$MW3*NwPbqJc|X@902ctzu>^Z6>%*#R>2)SrmrcM96W?F@v*6L3q!~i*eh?I!}V> znyW2rPaKk-%r0WERix3mRBWAa%-}fq0zsy~Cbq<=GKSYB-e$;CN~YVvCGC?N^c6W6 zyF+N1BBSLBFYK&g$-5ulIyae~UZCCBn%-+rM6%6>ukO;o3^139db%@U;R2Iw)wT7{ zW94P90bBM5p+`8bQSWDQ2g?f%$ipTYsuqmZij~myCOd4&@F9mmQ_7+S~T|%gfVP1a@cLlu1p{#f0Lc7eGYXa9P_a0}5JU=o5`%!#oJR$6$xSZ{>PC|lh z3;W`t6T0d}y5*|2NLfQ8%mu&vIo8H`l|>|}{E2&*_e`AO=qPxv>Z?1AtuK2O^2SdU z;+`iaz>hJ9C&vO7%nVQ|i*9*-GO}d?-LB8B!ymP^JG9)*?XTQmFZip=3NA6hW+U+- zn5*Q4Pt_}^b>H&qIzuFXVKi2LG_UsT6>$+Fs4lSh~i9yaHq^WT>dDt6kd!Az1S~26k zNY6J3VQ%7bRv6^Vm1{E2lh+-sFds3V7c|?9ijg*!J&1l@Qoid<}LXSMVU)Fn~6OlbWZ?1d}SA`WMFfAnLrXOE2lK6hh%HCARkzEE_D7- zjQ3{UXH00h)dgP}6W8SNx1OjKzGUV(qovb!jT9jmeyscR{xi+9>Ufv3xl?1}y!{5v z{Xs@2-?bgDkC&{x$i^^hHCPuK&|*Zs)O>Sy+x?Z32J1&*2IT?pe*Hjs=0$FVC<;p> zE0?HHvth}-akd!m%ABNQaY*!28#~+Au`#~=GjDLK^0ruHC$+J%e}!JwOsRih+b8kq zMp15P zF}lTZZn?Y{qbkZh_5;+g@<_+S0+_!-z0hbBzcPE7%;`4UHZkc0`E0n2Jr6|Am=mo~vN5=)ftHhs_&3eIlnBw+ z(UKh3K;SdZLnJ>+)M@kgN6jJzZ!MKkYLN!1@s!Fq1?fHsdr{JO&WcB; zIxdiQ(m?)-v0qzm?=ouJg_6oI&)Pf<^41R(!AiVd2QaZaJ)rL=2U}sS3f4H!bbmZ} zIG`W#OpfszNoG~vic*x2Wjo5g_;B|(qxM`@I1N!+B{*hqt~R;??_4T*NK_>L1&Pu9 z(JPoqdxz*Jy9;gm;H!%t@Q#3O!@HzqY%5!2xr(hli+Y1y-5X#gbsbkrr9`ec+4%L! z$x3jrLVp@RHAwkJ@&w2Os^*w-FqjOO*^a-qT{Mskvq-xhIV z9v#}Z_?2}J3%cvX^mjPk22uq|40*&dQo4JrbVyD7C9|JerF!6VyDb8||bOVcG`8)x`OjP%F1B`VS0Jp^ za3jcfur$X@5_&9n7M~$pbuB%Cchx0s?V{~I7`sNP#yhcd04eHkk(knebnB#ArA}Pp zcQW5a!vdCtMtb`kWF{xjfdqOyhK;l+B%z~=Up~lD;(0=|&9x+8IUx2M2}e}FD-f(4 z)QDx9098Mihn7vO^THOfG5Oo6GOGhftapxKb|70&R;)|;kv>s!x@CJzgZ2{$*859% z4;-zLNld`P%bp9Xzem8jFOg8~>*j?wWG_0x*z2gNmHt87o}!w_Id zp?f$^z+1nlTK7WI~yd!WPuntkOCp%N^j-j6Ud&J{Ryh@UOB`}pr*9@`{& z7d&-oOT9dX@;1|QN29hBc+PteR~JR4{K1+=)D{G6QModhws0(ng~{H6SMY+4rMkLa z>dj={YSB_j6p#B2thBIlioo2J@!PtLgUFSnXD?=Bl{81;7zUTg=`vyAv?>0se80=g_G3N|>I|)GON^?2+{f zf4!Zh3weH^(oMW#&9xOT!7>_z&MlP(`1UJ*VjgCtX9^Tl`8WVE<{+ym0@ETc)Lk>+ zDJqir0*SoRc!&dK$j2dccq@Emu>?`ewm5g9N53AAHY=9kV#QM6=8D+p{ysNIdJios z#su1rb4adRTCL8-8@Akhm0174i0l9e=!9qyBQyiO%-`Ek#;s)Tu+Y#CpWZ%VB5M*u zKEjS@8D(qD0{GsP9?K*|ViGnw*r%TQ#xnshb8-S$5TH`-xXl?I+Ju0P_e`Vrj2PG_ zEwpIFmCUPnkEwVss`z|RUy;gRc}9D0!hA9=Fd&1OF=i)GTz~(pXJ@wY(x^Ob6y8@B zS}UC2Gkg3YGH0b$o?4sly_AiA7;YvyT!3A8cXH`F?;Z;c!oljc(8SPiG)Sa3MjB_qNCMa`^Z{Y-MsZP>sou1e}jhiW7v(ly)gFIidKRNkm z^)f#D^X|AUE%WLfv$|7x$4f?^ct#D}!roR&re9vTX0jUy`J=R^oiu|E_|VL~{=V2U zBWnC8P1Zuda%g6N8!_@07|j9vSg!<|F9S@xR?EH#Sr=Mv+5$D|aMX&blTct=T>s#O ztf(i(Rw}{r{en@kBiV8T_s{x2Qh-IW0L-opLESMfey+R54P#`-nJB|mvx}2^4>KM) zwF?a^hb2-vI&P!6z5-(^!MDG_h-b3bwM>uE-Tjq@1C|U_HXhmIn~>y->?}%nX=~#M zA%MPY98|C-9U%;CYbzkx7C&2BEP;i4c-v~WX-GTsH;}F+cBjcCE0j<; zm=&+6s2fO+dx+vZ=?xMEv-7M#o6UbPlSQ7yg7WC^$3e`@HiJ&|$M%yY6!gX$t(mWO zI$6*fS{{86i4=@6f52xReD_d&_bGFofg7caN<=;t;gj9(zeW~%bQce#xf-f1JZqX2 zI^v?6t81llk!3o*cPhFr@#4sPeR)iGxoDDb{%j}4rWGHCRS^N}q~(CFzD7(YdESnI zSS_oPV;GzSnrBtOD(|hM^xm@G7Wb@eTyqZL<_SCkR+Uy!F&5nY+uGbpc9`n``?kyf zbhf39KS{u)RdstCF{O@&VZJfK1{vJb7u$pJmL=sCZ200x zU~Z+4D-@CZIz%EH1khY|d(6OBWcEfb7b0hI(nd0Dun*x&M{%=|K-=#S`rL99*-~FU zr(F*3SuncV|2&`>8@fN28LIyUrxNTf#F5E8ozku+dIyU{TSZx+k;*_leg1N*WyzwS zk_Rm|?pCzOK86fk1nIo`#*jagjauq03{%4uzEac;^3b=qC7fqGrHn3#gN#R9J$V3w zz;N)`4~!Ws1rSK&>RBE6t`^+XXDojz75{)pxiG0fQ#RCkoZPRyqyPF7s)nr+@S0bU zEGraIcjm_t&RyW5e7P%dn5y|oLGY37p)>p=0-7_=kH0@=b7p6RLR3mYaX=1%^TTIW zm&}aYezVuDQ*mdOT8}M7GtOFdC{~?FO-hxsSIX`#>aGw?S~q3v5w^GNpNX-0xoSCy zGt67>BjAK?)41}`>9CAirCQ%}m-5~gOYJ4>>YuqSt2c8gjuP#uPDiwDT(^R zr!jXNr^&XXZVP~6RRQUi*eB63*c`%{e(-BA+#uG_pE3XL+)i%K9q5e(C@-gp9G9b& zXHpwXyL6*ox|S6Nth@_qx4<|hYa4zE@fFDh|E;K&W!4lc+EVM-5#b8rP&$92|0IcJoof?{&oK? zKqTtOC~c}$fZ=GT8*AXXz@S*(>@(8Y`i~jf zgNed9sjbv{C;m4dlGD+^b90^48SFDTNpxIWUupAwu8|kOSHEBmTaf7U_1!-hrqI(6 zG=_2j4gJNIb(yA|e~aauwOadSminKkgLD%qz@hppdo`uodm?D9+P+hG?VErcsaoF5 zQ9S*yD{W5RONVMR8DLNta$QGAxa*it3hekL!iG+}MB^_z2J(U@Wqk=rdEKmW%7>?X zdacH?+Bn^{i73?l_2+BY>OGt9C+kztRUk2l$wJ)Mb#mLl-SuE8Bw5AhTYQ_>oFmZC zCnkcS*A#itCPwOmzYe+(8HFoN)4ZTetDlnmaS!v!LEs)li{GxT+EKw`2#b1$$L5^= zCdP#u)4A|*wOJ3&x(B*Lcb>;F2{`9`e+u?aTxQx|iYHc1`O}IM`_|F(w5ae;Z}7uj zdwj-txc9A3sfw6<2)Zr)jyO{e+H7P60h4SeYQb(X-PtqjS(^>fF`B&|JFgAG&fz^Y zsU7`uRR8skKyK;fNROyQO7Hp{H*I2meOW+${VkDZGPDp~7T{A4GPB?$F3-#cj@KKQ z-_>p+0`H#_M|>iolji7FqYU7B{QVJnNQu~@)JqM0_nx1Uju;O2MVD8vX$YSpcw_<;xhJ*ozP4Bd69f1<$;MJT%x z&pohKkD`?(V$H!}s-FB};@Srq(erD*=NM6Laf>$7yvGU;Hzi=@nr09sSzm}}1D$nK z$s2vYdY;A)tWG+ic&rxvW*4sSAoFbx>YG3rdo|k(t+&ZLcCQIfy}@&@eRhFzmj(JP zy^ImIhIVNCz`Xjc38VvQq@HJ-N+HA9Hd{N73YVvq)0jp865#qQP}2tEsO9wrz3Rnj zkd$qm_V7x7fWy@N$$46bKz+4ySO#lL0ADk)MDY&-7%a|$6W1jF!_4fj*-sgrF5Y|r z-J>rv#cfkNT0vx|#j!}uIII$c60tE9Ej-_tDlNaBFumUB19uc3-<+CfkNweYyvI~# z`eDy67wkJ%f$u}$NmEhw&DKqiw8^c`ScJ<$w+uf%*dw>};VRrV0b(%7YPmgOMKh6F z^HuKd1QslwPMWJ0R$d3WUw9TIfNv8>15fwneJo>V2)I<}y*6#a-d!=0N(07zLhMi3 zbUI_+`)dV=n=BC?7IxTe?8&_6q%_?2(f2oSYWqIaKpz9Mwc``mHkNjo8)y-(Mx+g| zK&f0nFe>!Ub8tDtuU(;<1X7rMj>)+>ulYS_tnby~Q~6jMv8Gw|CVk1>ZfpMB?)5k^ zoWWa6CFb&6knQct3s>WFwQBmzSt>->vre?hkVBY=GSn}%4}Utfz0sFlohc5NS!jCl z?P!)|f?ES{g*S0{u@T${Y>XRF`cOuguaWCti0iSj158oIs(i|~Uc5}mAK}xhQ_AZ& zaSJTYGv6UE6+Dfl=5oe29CXMvjUFx?l0J1o(`T%VIrKzHidN?Xtd<6)LE`n%JbOQg zCciNBrpptMsFSE6^X*d#Tt5h+4W5Fw^#eNS0Z53YeaibAQr_GaVZJsiop8GJVuXhS zSsbJW8u%EX*;T%|LqNQ7QF?%b6-C(1qW4PqREM0;s3Ru*aJGNoE)6UfHp>|2XB|}D z-~~ifo!FejYf>oiT+;}B85M`}$0P`f!HJM9Pq87;G zV?WMPf|(~#yl$wtB-8^@5DWF+EF)hQ6e~orr)-=lue}MeHg0E-UmOvhSIf=b({7j! zDbJWBaaP-EF2|%efjs;A`n)eIqv7Zqn^S`Bft1VKbDCVTh$jyute)bDyOdB@%O~P& z7F}-Vd(GP5b4pjo1mrXK+}P`nnh?Ye_4FDuw^@s7OdcOOF!~_grwt^kN`6U}kh-5@ z*&V*i@=@~#YGBB;?tQMP!OWQPN;kNzLq+se3pS@LWNO?bvM#Ae;7Y5aM#YVNoF&bZ z*A~_MzNwj6QnI9~l0~H)cHWqtZ|l{KkPG?nw>7?;WKHkloWvDAmOVCQZ(|5ZsssY@ zKcpSaVq`xR^J^RzU6*?;xqYZ45boa}T<~ocNIdHpjC*$IxY`&BGdzJtVVdbkA35Yh ziuC8q=4NLDue66dRu!T_Y!Y3kFg&qc()ZkXX@eZ4MX-4yq;|^ZYMbW7E!?iCYV1hR z$*KOn07-dE_UOxfhC?wqVO8s)WrIg9jcQ~Cn!Z=xnoUVYT;dWH37<9%?C}=FM|)umw?I)<^6pGaFSt4F6C zIsDszs_w2Z)j$dwI465}cqCHC1ePr9+3LZbs^;7d3En5up5M_CU~s-sh4 z%+AJR?m#=T@ja{7Ca{SSL<(aT4Y2i*UpKIpg?h!p@ztS39bpJ(#Yh!$m9CRFpp*x)2h%(jNU@6q-rBr$JyNjY^Cf zP8S%6&ACn1Rjx&U%|$!hI$nnlge*9-N{eXP}%F!4nHV#W@04WaK8X^WJq<)K{JQ6vs_&i3OZx= z-6sBCI+x3Q{3laZ2z$#KvdMzX_ROrJs`}$D`dL{R0j!?)7O_ZA`)j0*)5f8x66l=l zuQ4|MkFy!d4&>EkRlbX>{EntrFB1F__F&l=y-D?KrR>jky$T^JcJQTlMAN)~vUWhE%!b`Bc9=WV z1iXncUhV7dtEjXZc@y~^8%j>W=U(0Wlwl+=2DbKCfskb*Y~Vxi*l3#Jhh4%$Be3M` z;#@AbtNkvX_1R@;Z5#hWj(k2_a794x zpA1XFCE&W5hn*h`JeWLo52@dLx}mKvCrBPN{p$MZ00I0bki!rk}DLgph! zETi7$Y`N!m8Yow*m()-@yjXYBdcMgT?s06XwUiG_!B?^7rG~tv2>!6{-GT&3Dc_XX z8}Fzdka_#_G2I^etopA4cVJomdZag%^{=9tBf{XsST?p?qpou7S210I6u*x}+HVDP zbO>+;{(C_?7qCiydtONYeyU7IcizRAHeq76{gWft>AMG>em458Zhw7`WOKf0fhCfB@~%FYUY; z^*-IBfoyJ@kEzS!>fWP%WWx-F?TZ4NrQl};xZKHf;yF=)RqBQOPmqHP`&^(`mxifq zS?zzVfnZXb&zrd;KE)RqCd;(^m_BK4mV%$o+bL-Jiq&sbRVTft_lb7qK%MA6X6Umv z2sd{Or*^Scb#s{`lVMCm^mGKd*xJh*{Pl#cSwC`kqr(HwPs;iP2<V2?tuzkPL14wfR#K$le%)>>n&G za0RzG(UWp%XVq!&1eMA=*)`F$l?g7m8CzlmN16kuNF&~A7=bH>Wv#ooqoO|o;Kb-8| zr<-|7^^kpu%G=gR5B5FJl`~-HI)<|BpYitPaOjY-I^FNG4B~k)DXDS7Sn`8ewIS;w z<16K`U=P7RNL*k(xFBJx{I>1nfLB$qZ_x1%y<2^X7}Rw|BRX0eoV*Ie4Cf^P*{TLz z8$SvkL@Yfaz8bpO_2ruCNeNBOZL>>z#5y0baqe~=MxH@90;+23^_bQYQ$Lp6EbG#r zZZNj@Lq>L=FFx^Bp3ZXgtyBBK*08EZ2f@3{e5Eal@zO+M^hhrM^kB;SlUr^6@OC!! z-xXg?%FOYNwAmq^_BUH+mbLWI-$QfbiUsVJZGoYj+MyMCmW+J8-WgHo^yw=4fxfzT zYUoh-9zJ`-Fy$_9wr&dF)LM-_IUANZ|18Hm}I>*`sdat)t1EUwEZq` zt%|Q)ENW!GG(SifkSS{{F`abKDJ1tHKS(~^y8a2^?zpb1H5s0Ng>kIbot^e{?;&$L z#UgQ;O7~E^oA}sil=`(3Bm;f-6dKj8!ne%8>8V2Hm5V+ z6-BmMDq9;4EjZMeyvbd5z7e=AkQwV&{;=b*>$8K+Tv!e?yYS&hxCyekPPsYERy>!?#!srZEIJeNvHnL>k z_4Kx~zEAxA%n2r7Wsqse_c>)}c(aM}j{Y(3$2q&1+HM{-y5TUH>aG$Pr+pcDbzwq< zvH9TAp;8kcp1`!TOMh@a91rp}SZVFx&UmT7s@Trx-yxp%IO|kBhi_-C*G-fBDG6zr zfby=`Ma*c&YPi95{Bdzj&918v9bpyu`Pr2ZYzwvfU)bFc;gN|3w4e$Wnps{Xc;gfD z%WF*3FmI;0^Syjs5bi0hPEK^z_uakpxYgrQi@6T$;M65euC9vVOFCY~_SWyN{$1d{ zi4&VZd79zQe<3sR#~%s2T`TnPDyLq{P9O4c--QPQeuKOHb4%{JV+J0T-7Cwhw&tDM zhoT_JPEp(p_I<;sPLrHFDU@vwIs1fsM#*1Ke!4>bdSp@wZ*Q3qH6vBD{Hl8 zU8T^qh~1_&R6W?KtaYy1FYD<*=q*!3&mV2PRmKs4$a&VICI9i_H@G^ae}eWsw=U8C z1B^!mA|RkaY7{|4nxOP1O{4^*g_>Ze38*MYjeztfC830( zNRb*!XbB-oiVul=mGp7rd++&0!beDKu4 z9Xoa$*1xG^wqwTuIY@ecQ3)%np5>Yj;C-E;kvyI^Fq>lvrATk- zs92_I!@@&TQTd;T7`yh~+ws3W_XPL)>q5jNl8zahLsa;ypFax`H?G!GF{!Ff+apZ~ zDwFmx(1oNT-hg>~^5*UU)+k|7lpU6teYYdWYkF(76dlg(%`Jcg+CjqWQQm%sk5HXH zL?##oKUgwYqTr;|YtL$f>M`?jskZ2VyR`aQTL+s!Qt#{h34eBDa)0~(AA^-l@jt#s zC1Da5jUmmv^wUKM3rsk@v5@~t;lKsf5For7ImERLwEk@ddwxZU5=vO5nU zF%tHYRbD99H_V}rp7*vv6hxMhN5<2j(uhEEyB;iE$8H2f5@~6BVug)+>{jdV^Xn#Q zs;=4Qbts4?SR-6)GPKB_QiqyR_It8Z@X`PHJPwfON0ybT@*)Z0D@{I_EKMILr=5zA zc$;<}OxnZ!c?Wl!;-`j&>DWYbX>sCUf)bvES*Whlk}z&N@W1UMu-PAcxFvH?$nrvR z0D_r;uMd#U0qurFpK<~|yC=EVA>@a9`F6;creE4^tJMONhbC5)X|0&X+>hlAtnbrD z6dwPN$Kdy`9qqg-<*DvJd$Z~eo$2J{p49 zygoc#3gE>S2mv?u5>(6GFtzRUs@d*Q%L^& zm}`Qh*K^Qf!8;SuzPG9$^0{_VVu!#;=kd67$z8QRssiCRlYHL^UmsszB1nqmo%|huOk|)|EM4GL? z$#8MY-_I`akobe!|Fw`l{+;$S=lGCDfBBvrSf3U+S%6RLv$nm%yvdUP{Xws<@u?TS z@BXs}>}ItkF_5#~!g<0(P_&lWDNiG(*<%u%K{9)o)5(hBY#|67wm@PXm_16Hs2c3^sp9#l#uhDUbri#;T)WEL;n7UBoFcbz6>KlU>R4jARChBcJ~Pvt?8@ZlHSucp3Zr-RhpkN{&PO+%f3iX_|NmGfb@sY-_rit72U)}xPd9PZkRKoGcwzWR>4W}h8Khpj$ zac?B@FF)&fZKp}`coh?KsbaOm~Ox-8=+xFC3svV z$uKo=QhI?|I_~2sT0{f_P(Pk-{Uf(D6L-WYt{MoJGP~P(twpB&93qAo=t!SZr6Jfq z_RxmZ_v3EFWWNn%KQ^gX7c~iXNBghu368+qQ+}j35pZ|0qcwh3pccdF`rna_wCFFZ zLn4v0>$&@QP6vjsOr3=$S5A^}^YB-eLV6J-=~B;&=Sih^DEjhogj%(RQGU*ix z)e?9?^pKcmiBDEsX0?s1tSqG+c{zCY8?ST@N;8~t1ACt#26~mhKSlZI&bs%Hjq_t9 zbU(;H0j)me{1L$cv+iBo)zI;{5ONWuD08YM|Dayle6S(HJ6XfX{g5fXGN7`IL$!^k}vAaVB3Ay1cPadnYb(po;qZ^80Z5!1qOt+%0b-ctx zO&(GIP}b++XgL_ArZR4Iyzi_z%9Mr3^Rsr_et|sO!V{$Wf||MgU(Ty_^rLdWw=pepAXk)cxBGU$Zzv1|=cA8sxzO#2G?E0ifu`_<d%^s7iy zlZxQ4o6z{`U;w1O%GCiLytjCHV_i|9k<{qXkLS>8&lDS*kqOYpv;HLr6tB-M$;*z=-TvT zk9CDCRbA5aPGyS1Y*+}bBL-JK8SzD!ILcQO^Gb#fd9u>}rfa_Ql|hSf&{=e3sN2Z= zz2<9T=7sV@`O^N?l@_M94^Ag9lr3IXnrSkPe_OFnruu^m__(a?Xf%!o4aDZd@CJ2c z6LqtK@J`l};0xX=SPtQIq2FZUn%An2R9#|5NK_Cx<}Di<46h8)BM4#cHb^ns>UIGbpn zU^E#Dw(bq_=5*q!wb~p?j+poEs|@OgHV4u0M;84z;4SyjCed81Bmdlw4Y>S`(b>q# z^V5Y?mzFVU^EPDf4Ts4fVO^~Pi~BBVnBky>2`k@`x_Rnrt%@b<-{r~kjtG1Dx(n;e zKF;hSyfJ*PIGjm#JR7wULwwONB?}h!WU_5rf_xnf5^KxL8^Bq<=*>(MR}Y4_1jbjh z3XjC22}C;>czr3#5jT$`LwuGZ@DSFJXEKGEI-5?MN1^Z(n&`qi6NpbhWaEROUF5O% z$47pQb-@ygJleDcPb5EGw~wb<%=8{v;VhT<*gk`{Rb20cpR)k@dd*G7+M<8usQVLn zgI7pAb!g~{-=RZ?D1Ei?IeB~d7@>}iU#?@3P5`7nP~t zG2hY#K0MB6Y-WZjqxi~-n=cWY64p_)sHH}GWHFH3k^AZ|9bD*}wUaR900`uH4alXX4mj`D|da5M4?LSGIhdW=p@TZ3I z-uguVN`VwPfV1L1{eU%&kiQe^H+DI#p)6MeRYC^g8O{@1T}!!D{z5Fff9=VgQFGs^ z2;vB3yoKs`4GvWp zGS)n^s)c|*)EF_0XbxvD^{6nj;#zQ7!kwZITkt+;;Ul!Q#=`YKDs3)6V-XB&nzIv)VWihuKDFL?@W@cMWH10IT+iRNIl48+W z(QP{CHk-p&DuK3YvadO?Z+(i|N$7{-`w&)rS>UwBhZ>YAb=sqJ6`~p{bbE~ve~;Hd zGfdMiC7G9*23|Q`Y|xXEsSs4Yp#yondK2H!m-(~9gWd)j%ZmIg7wqzCKbH~rTs>8@ zf^f<)eGElzS}LKmMJR~CHHR!(M7K4#nxlz(V6SS*@FojE6$E{lJpzXo!MuO9@iF&6=S_o`n)n;5miQvKGJ7F) zND{FE&RQ6MxB520G(Kj&np$Gi;zPckZb|;BEa!rGL#$l@TdIelHn$mT-V=4v!hP;8 z1=RCGS{z13fEtM}ig)_qIxINzsUXm}{?mhfytBH)oikP9b=ous}l82&EMYSEvM(bgo`bg>%t|KFKxN^x%7C5*tf{6SuPzcvQGR5T z_^wYBKeOGgWCCS&F5Nm!Yk0lq#)_H{WsckOtACuUzM8PC0ui)9Zjna%<9?7 zjQp&5zTxAej^bX2HJ(qh7Q_4llA6h$U$#{(@kzm>m5!TQ<9tZr#f4#AmGMI#@H{c0kB4^L)GItHRXN8B@o09!{EfFaBNRVL z($?{ljie;@ZRWi^@}`c%`Do?oiyox@@<+E_DimKq^WhuI4_-nhQ%sio+gzK8F_GwL zU5ItKp?dYDrP}=^h9avYD_)R9Zf&Y13xQaP-HmouZ^?94=vg{+!Kj71=Sd%;^Z96r z7G5da3*t`Px-Ir$)qLjM>VV>qELv_N@AjS#Usgw0QP16sWX?dMJnSr&S)O0uvV^JLllXve+;xwXXCZt6l5?3Y-y&EGy{D=vq z)JNs%ouk=f9`yvu#}pDXGC4LzQnS)!@fOSw_KHzM5hm)x^s^!hWIfgK28Sl}A$f|G zb0gq>O(^L6iSwT8B=wV#Zeg-rGn^ZX8XlywS0Xw!qDsc4B9fz7*wnX|Pi5T}R*SMR zdc%;OW2x49_YYQz#=esiI*KG4Lp=}iUpQ0+YTb)H(r`Dc2`gB6>kVeNOrJ{KdV0{5 zgF)zFv+06L$ok=M`{UnkYiMVdOpBrUQny|wi$;j8&&&{`aIZ!OeR~vAED<;Z#=UQK zbn5wL=sBB&{GKf#^UvT5t5wY5Ln5;IoOu z{0j*V4l*kyN39)(Q^e$vJk047ESdaGux5;m7>CB%FQ~7Y^UPhJ$!=~NUsp9=VW!?j z>xVZeRGSry&eTrKlfoJ}(No^5@Rbgu&THI%$TEwcuTBvigW|bN@ed-8jBPz1HCuOf zh}sZraT)dBzAOSsZ@GVNp{pUQ7M169ITZRaqvgcMAn(lpL(vh%y^FMux{$%8;%MAn zkV3J9%3{)*L=LJYd(6H&d$ISLf!5K$v{s({YdRJT;!d?lDX z+pe?tcJtYCp(e+hg>~1@B-b=8+D7mE(Upi$`fy>P3CA;15IW-9MC&<0&)IargxbBO zzC%{93yGVlb~LJe@P)0=>n>(w-1`DL<0SW7QWz{fJ0etZ6MwWJ1*+ddqmN~(Z)**& zb?2`+lf;Ci`+PBrob8y-VY+Lt>KEL61C4q0LPOjbpmB`TVCeViRJW(psYruBqZHldJX@!)O;jRv!Ivb zN+?EyvdV=vD=>5jl9qHz=vE?DUv zZO4<7@89K&s={}sKN0&K}EH=f}YKeSD9eqeiZ!e4hizalTDQd(=A zD7Ta};`DRn<^%SHwJzLx#osXo#1~S4z{}eHc_SLv0KRbEY89iaaCzwc#=b&F9XH1` z@262s@&`XYFZkxO{{(rX5oP_odvQ?o9@r<$SJxXHp+&=tn!xgdZsN7c zcMEmfOSQp9!|*#oVHK#j#o?VFQ8mJBRfTyQy{ka@@^tiEQVevPew$?&_;as>XYy0f*yLcmm(FQ2RU%k)9#(SbM;wz)f>k`{0 zp=EErmj;`Gzp@n6#jw2R1g?M#8=8#eqw48&c96=dn8*4yNJVt~*V&FvC+4}1`_qw@v81U`?#D#$HGj@r zhEYh3=nYj_Fu*@kX#@jd-uH8&Eg|Pdlq2S|h4h;p?ZPHu`I)he-l|5v3K~=HD*|96 zu;!xI{*5UN(S1GJzMR#yZ*n+gsDU~$Odxz`7pKc>Nr@v7Qx830_(>L+%)pm9vIK-c zEw~G}I3>@&Y~uXwj;tkZew9z54w{HQqy?WWR&t1>g*Du<{V6O)haB>LlQ(l?UU6;! zT+*NY?Zsbl6C}Ov{yn(F*Fo-m#c+KNc>{J0e+N4HS3XLY^$aIdRS3TFP{#2_-JQpB zvqh7fc3t$AK#Fa)OHrMEoz-6F2~P%CjT=#;U>OnV8{OX!2altB3(4oTwrsP-e33$)rvxl+a7A2>3be z3pTYsb%=_`c#&u44#(^Fd2v=>%`b@xWJgRt^;LfBJ1NKnUEjRamzcQXIC$k2&IMX; zuy$hm_7?0j>jCEjVy?~}4gczQl3vpm$_Y%deb}H(t&9V{_|MH8@T%F=bt&K zCqWB-xJ&wob_KT*fFwAzegOP9D6pleI~Rihj`Z62@P>wvr);1|a0+U(HCR@llCEXn z7}C|mW(Wb*$}!K*iymE9xcA$?sN_wuq{o~<+TQ}V6iqAhS9JBeS!77IDh#R>M(ZOy z;Iik3-Q7rcBR~%Vu43;$gT{#7*k6#NW*Z3%!FWGYcl%8f6&lDiyzM-*6l~(WeBiV+ zFCRbh`MkO#>3d?L&Y?R>q9-PPAulOzwne$JxnEM*p_d(#X1!qB&^f}=_>uPRq z3+S;%ea7~I+7NOBI*gpbG+Rp@{1TDY^0RSkE_7@vHMyxFu(dCkeBxaUY%`r`w-|$a z@iJ=k^_IXd8GYXs|3tf`!~)U8+jb+UEQrSCvgK0hIJ?U2jTLI0X}dO$yq0xV3rQk0 zF4&gcVHzy)sf#~BuMb{2fxF*SOP}rR>@ZySR9{=XEo7c?sQ&2QCcjsf?hY+;NPT?a zrnZX`mVF5!TKlVR9kQ1k)Y(7;FIrAmLp;N4nnttoJw%X2b_*JJ+djNqU0UlYvF~5d zFge{3_to4f;lD!>ZSj=e+rmCup`L10!-i2&o4C^*#tu^#?IZL5tp&)(n~Yr^x}53S zcVq0TTjpq~O8(M0LIeRRW9^ls;fR~)ADz5p{I#Rq(eXeTJ~|Q#Gg*35olG0s4asU; z3XHFcw3k&_sTm%I_MsItaV=7r)ToW5%~b2!(dM^7#UBxkRAZ0MPq5?o&FlzD`Oerx z|DS4^TV-Q#P9gDk&t|L-p?V7d|87Rv@`XIU?2j$qj`69eCeYyLT@WFfDJK9hzr@PXk6V~ij@t{IMDc-u>yUI6T z{8fJCwq0Mk6>*UL8LF#0WngejSwZf&DE)Oywd@(JXar1uaimF>Pb~Iue3HhPQrdiH zgW&~9Q0&^dBVBQ+3w$lG#i-dkjy0uIG@LTxTyfADDf0eknd_@>8sS1Clusma`D2I% z4JPX~V_?P{Kfy_SB`@&eBy5%DSoJZJq4WVV(1@a3a^zSYoV!CT>$}~2J8je#FD`}VG} z9RM!iFN)|rhsJ7DiyZ=ru_%rRqI99~+<9v*gE8wN>R}1Vh1i0?GW{`ZAi-z_5JpUk zv?LF=)W?i^jpf$JYbG{06rdnNYohDsR46 zwT8W}cFPTxTY9g_a~8p{m-0LmPyZ-l&rx3LTGVrViS}xBTPijK#am)b+`1Qe0V|#} zO*k%iB!{WcfCvl?o#`b_ws>-aDauEh-Y8M$iD=HR3LHfO!9se$%-vnf|@-{Wk&G1=#BcM!LRL z_*DMKtT}B=xzU&xl6;w*1YSwC5=JXApRg+ZPKxRAaR+xjcPD=}tQ+M& zjtlRrKxCNv)Rcbusr(UO^&(QXwFEPtg6FGNXBI?egYAQ^nccXg1~tT8LSMUE+T_~Y zn;IE(LE5EB_Csw8lhOZ!Ia4baSkWR3@M+tGOx&m)pcH7@H))Ti)jfay+>STp3ZI&* z_>d?Ulk2q54x!y%L|j#Z$x_3)S8fAEiJ>_ln7m>Y1a_B|bAh#y;H#MpD~O^q4j~ouam#eNc4ksmwoe zVV@rXB?JxVL#|>iwrNvUThC88B?S#eQ;{0@H}arm#`~s}AQk(u5Lfr}vj;Z53O}%knRO#{@0?sgGJ}pENJ3os(QntN^~#rGf~gl!$O?!8D_Y$k zNp~epaJmktkS1y|ml2WdL%bt$8p#u{N$%`Rg!d$cmyU1bLt*I(&?Q!rZ#pPKov`B; z3tQcn3zrNERUB~7xC8B;{@|@2ap(R#;RoU)%V~v-95-b2w>dCcSBM1;Evd`cdCsWR zOt$Rz5jN7D6HL@vCtVXZ044VJC^c(`&e6WkQ`fgzYSlnVfgJk}B}=B^Vr7ZR3hI9s zG7vzrHa#j|SV;bWuO?A+u$zktj=?L90g6msF z)n7yp(Oty;dHb*03w~pUBmWw*Ng+Y`RF}wKD+}jO54JmNx~K0fysCp4E2ojU^I`Ib z2BDAbhNOjq%h1IE;=6?IoUwYRFq*)>;X1Y^V@B})5!?Vnpt78rTm45?pycN(77Cu>q#Wj)f};V?$rbZX?UN`C zec{b12Wd>N-C5c-Q`;0#N34aEA+C_50Jm-ai0Yy5LV0ZE=4d+Jyd2-4Vk@i7(g30!rL_VjR#{rW?i06rQxzBe#l;szEJgH$YwH1qN`LUAY(>h?^4#2CF# zY+@9m?`T<~wjAET8U3Nb1*a1~(%9?40w#5IsCsz0ow1s{jfpuaxI!MS&{s>?PDy4? zo4#Y2l0U+!j2XH@5SXig<;1wS5J%^u&`VZSTYOpJtL|p7OD{16E6eQ~ZZZ(B?g`^y zwS^Q1W*Jd22jnqRSV{cmKUUsEx}nuv-9v_Ng;~Jq7_9}H$SqfY&QDRcr4M`SmOqSD z0E~sVGEM3#wl^Bk3`*7SdZ-JDP1nFfTjiRr(*?zfX7~b@WBPCG-<`yS1H@3 zl&y48!o)q5)fc;{HdRRu4FR^ev4x<`Wj^Uin!JNacg$e~my?xM7FOMON~5qPRqe+5 z+K7yOC)~OeC{GSiw0M!i8nc_r%v>PSyGttS9WQU_<#i{#0y?$meH=lg-IqNYRw8vT z_PKq>U8d_D*r)gh#oK!kF2zU$R>ObvasnXG`#9QB17AMEhS)z7x6sL9jY^;49lUGX zrVC78*P^#1@gorSGp5<+{*N=|%@&~+kFyk>6jdcSLFl_Gb(Tl?%VXqZEvlc0q*F+D zM5RXbt}`cDk}l!!0<<#kIqD(qB$VLZ--BrU$BxDh-#7033Gx2MyFEFmckzQq`XW{N z3Sz7vOHpv?&`ov3_<|PGcfRu&vWc;%ka>DYdZy#Lt`gLT_i_ICNTm!WETfUM*NX3T z*-26Hm+PI?Ys1G)ZKZrX3lJyXF+EO;cfSd-bsD|2NVou0Zi+J#(Zgn9wv3qmO=)O7 zk=eEdXhZsg#eFQZ(Fp;eCclV>H>~Y3fCkHXMA}pR;rCZ~v@bXZRIO|e=s6DVf*)o- z{Sf>9bGz%bjV|%t)8+}Qy|Zpvf9x6zlXkMu4^1=E_L<`ABCnS-PrX(+Ke#zc@TCSM zV~ofWR3TG9x=|lr&1Y9z3J6H@3L!QwrgVKBNChF#OThQx(Wf0sziKN0#mu_{$c~ea z4c7|~ZkYLbG|2wE0xht&_#GC13o8kax%LsJ(8HL-=Iw3;LIs?f5N?UOp84bYU-(zu z_ZYnQ`!10Psk*2GPT$Y}IVzO67_^0)786eq)umH<6UP4**rc|UII1=cBS|gGS&=jw z;;EI7Gd?G0!fKi!|B>5x{DM*!FI&=P##+KUo7TEZfLcf?zV5DR)Y{X+!-~ZFM=uo@ zmUXS$^UtVty!frA*`ott0we71gB@2YPp-A?^;fQW2Wo4%*Qy&)`aRaF?-*ALz3=Rw ziRS#SN9@C>LgPLO_rC;VIO57>c#yS0(;DTCIxuzw$xW2yH4SSnAHaFHjJ5mrNRG+G z1-Zzg9RCtH$wuJ0b5JYI&|&+!5MWAnDS4-p)$X+I(c~7F1z$bu(qpE094^fu*i-#G zrJ4CV%?ueRpe-F(dEqRo%6-OP=daT{;Cmuh&vWmYMKDRk;od#a$&mHFTH!x?TMF>@ z&m6VOi5Wq^^#_3RP!Uib4ztu5|EG6DLkvQbE_=oJ0aD5BZK}dl@R26};h1yLfXVLw zldXJkS0h7zlg%FDwZS>6i?g>KdQ$g<&dj)BJGg?x{W$)hc)28DT z)Bv1P3;ae1z-V?ELws9UD0JY$8*~JHtyk2t+|KXV5$BzUk{<_8g+?j1Zhvmv!3E>C z1L%@J^Ew_%AG`!~gFHnvTWE_-@+MdmyPAV*qD_VSm~qM~DqJGXzQ|R|dbN~tM#Gz` ziHVNKKQdeP9U?*#R6}F{>nv}tPgnkTBb4Li{pFnv>B!@P~IN; z-`yDZ+l^uDkwuD~DL(#PyTcKJs{Z ztPTVm;d5X!|5G{66+YmC4fh#RjSUC|cSY>S%=sNlmb7qN$&d>TrPDEy6fF)NgXY@D zQ%67tOL(rsZy!ar?^N;Pv%2GW@O~NMfx=911Gk-DibB92nKQt{k^6W?iZBcept2f! zVPx}GrNMpfEH9Fp_;jIMv~7fdrRwQG{8;K9^MF6aKZISpH^7nULNrdv{zg2%Tm1+jQdZ8fcYmB7)s#V-S&0#4BPF%O&K?-{OL zi8+S+-P3CUl7ML3_M@shwi`*?+$mR9e{&MV}hY|PQ0O9}Q zdeF~mwsHP7tz|K4 zii)Y79<)O_sIZGzS3rU{@-*86Bb;8Tr2|>LpcjW59UVQLgWCQq?%9*rcR$0`8Gm=q zU}q~xFm5g(f_h)KL+QU_Qt-^}OhzwQ!m}r-^j!gYUvsD$zqhq3%@fB}+4qTk@Zm)v(Uy+?eZFcO<#(ZJ?cy1eha`XEOxOh!;I17tk$3h}YsB&{vh>dQX|J+S!RU0l()?sl(G z)uTv7JwyM5b2gC~u1zyI;1v94<$k1H-Hyi1(H^1Y!}5@6gG|N)Ansr^0*OahZFX~o z2u{jDRqK%^CkLy)@VFL$qy`2)%ZJN^%)PUm6lnhS+|{mYJXW)Lt6ibNAVvQ0r*kh+ zHf0;{)ffArYUKf*dJ0B}u6m}%EKPD)Ewh^P({8NOLN?gYXlS3evcvD|34eG#yx*w< z34McH+i=o>)cTa6XKcspOXjLvmR6~gw|vUV&}C&oV>aI~Nw!y}zbr0#R*h@L&E!^x z4Uq}W1PB;<|K8#LM7@IQMPmwq;?u&~oE>k5RjAkFPM)(2(pt^+W)0FtS|aIf5Q?qz ziG308A~O4P!sk(P6d_U81OEtE4}_B1{sl@0xlp9fdWKVfW`s++A8z?pG47vPtw)e3 zOAde7S#+*U?yGml@NDXNYZWQKKsYUXsLyJ6s(MMR z*lbmbe`t*OD8NCbwCjah&Tp?j4bUT$WQsg(t>~KpE0maIC93a@pkNV=t2tUhY6X+S zgvxjCWKNRIEL@JK@kKa_c#|K>N;%lnVgN*m@Zm-3E~CzVFWT>(tOHSs4z98B=`5Q1 z`0?q>0QQHf%9v1@E8&}^%x`*H$4+Ef^V-lDUq#uU!WWAQo+uc_6!!6z0Lm2AU~J>} zjrUVOjQ2>H;$QextY0w`UF*QsQO&dxOs91+{}K1% z)k3zWY?>X`0TT$SvV1gqrM5DF1LlZ&|5Slbi%h=Ibh3Px5lM zv@^#eYsKZpo(KXAp7tbJCK(<;7)x}zfd#WRIYjfW&KYAzqdE%uyvg7|%|y)k&4%T?tK{fU3mlz#Xx_)Ym?->!!%t%I<6&=7wM*6b6Cvy4zFER3I6EZv}Ul6 zMX=|vJ;1sk0Tu4~d+PK3@8cx`^+2|$#R#=gmod@HEg31BRH$Q;{kV1x>h5P0MvjV< zCDivFB$N`I%1e$TiwbpuEe{@W)^0v*Ypg48mdHO^NOmG0zSA$jt#8f0)7sH_-Gkt^ z&Fy7EPOvcs6l^fw+t%Fcj<_2*M{*bL!DF26s@f@#lYJ& zw=+SBD1}SX&$^3!*{A2$Ulz(CEOj7zazL^Tm18Gtnr>i|kEC`yIDv6f*aMQ%ZAA%Q zOCLX_iv@X@p3DJtyqL@I3i(5y`RMWei;oH+f-+W-Qvgo!Rn6cU!ly^e*sZF;=bt3m z6W(CniF*opxg1nKQgjBg(xu!bty^}nZ$8PZPpI2P*V~*_4dh}b=*>;f0IVR8!Id8)1*h}~^HC^)L2Xqcy6{i`4p z(xf=H#;*~nq9a$JrRjf3Lt4^hn2+sovPJl>sH300g@tbYati)AAXXd6fdjekRYbKF z_XBC4`RdOWH6>VJI{(IgcJ@wE0rVrH+)zt>f_1mJmQ}$$oMPhkj7%urS1Q%v}2nd?a>M)Yk}qj&x@X`b0R839(V*HBGM={T<>FTW@*{CBOAvBd8=DLd3tZ_Mc}y+nPj#7) zzDXUyuL4~259jY5RHn|cAweC>eQAiqW+yKizP3L{tVgxps(wY6-w zHT)b!UQUJ!QUtL!?!@)lz(B(I{dDr6?c1`^!BL?18sUx1YI3{_-oFmB82$p`qQZd zkL(6kjaA2pd!+IHJZS_3LOn$I=zwqscA-(+Gj6h7e@E$@F{F%bUxPJ~wRm&wM?uNC zE`idC$0e=OU=yh;%EUXhbIVA_3az9A*&~Yw@=C!TP4m_XkI00Ui61tcWk+-_xL)a( zQX$oQBNUr*iy!qH*#k^8sdodJYXDUqrOulhI(ai=jd2+p^>wyy<|Y{^k`W(N(i|5H zeE*ay??Hi*6x5(|;RY5pU=wUxTdvNFT8KRVu(}oG*fvk}nkeqCmh@Z)^DYvj=D|9U zTuh9(;e%FVNYx7uU2it*Ra|WF%Q*gxw)tu;filNLXA|#4n|_8llpOb{du=^pqteqQ z96bCF`45>h5lKK0bI9z?Dv=B3@=zOW!IapZ?$IJc1TaQ zG#<4S^{Bj)9{)~ZR~4qN+{auc;GEJ{l+*U0A8BRngt~NL zA%^lv@D`urUjU%|vJi4Z7ot`;Y+?WnUR{&QeI+RKHXo(!-bcIz-M1cmXi1<~pFY5I z@4Q0~@<$9o8}5A-e~b)v_w*%4g@CNXUa%d zvfrDr^WRzkI@qV}#rU7voX;UZ?FHQBBG=U#q>m<3Mp2Z63c?~h?NU>J7SSd+)a^3n z3dwq+s1LsDF6p2SBpTMD2 z3Z!_9R1WH-0CM4KUz_`Vl8Vt1zDQ2*!$;_Lz_%9&y_GwP*o^e_B>{9%VIQ%`sAq(3 zXK9+=c7gv=$AOXYBDu(8Wy+CTH(LJO;JoYxQp{kUlN)e@cg}SmXnn!7tW4T-DR#`J zA9*n0x%7}Qp=P^|WPKD_6hhv_`v&WFRw`>cB_&A6p=q;=pXc|KNYfg~;U*0u#+~Mw zCQB*nSC$h0-2ng%0dpH;kiu}#@=IqjAkvdP1YvTi!dJVvi`o4MQS0?_D ztod8pI?h(uIW&wL?N<6-${%oFC@{ND#YK!F#Np0M$j#X>tbcQ6PB>7QzD;o-X=HwU zQoe1Hcwf6*J~6jVGcmINB$hMTLO$js|H*6)2XX4(}LHEQmx(1J`=r>x_ae4q4p%<@<2CnlK(UJdx%NrWG(C1~qdLdNc8xyx*W;_^)?ge={UU_1nlx zI*e>DR%h}lJ$5|f0MM2!^{WgGfQ2COo8qO8BlB`TP5HPh6&@2yi`Z489({~ARpmoO z_M3x!5reOBmbOYEBMufRgjF(@M;gIH#;=wIbdxWJzG+Y1ILov9jOD?h#2g;F@yO&7# zWTituJG=&sOMjk;Tbn=3pKonyn|xo#JG1{}us0LxzJ3;60|AinJ)sw9yWok{Y%58# zr9fk}bgj3aBQaRb_UkRE2fhj;mkK>Qt&%jV+Ju44*gQ}@e_%prB=OZvDgMrlxM=6~q6)X|w(;Rjtp_^6igRuI9QU8aaZRk= z($x`DH|rPJ=@EX#WM1?9~t#P@YoT8uj*fNpwOY39?1vQFsZz##mKg$+^L((rL zLY_ADZ_zeDN?LL~F@5qx`02lkF93V_fZ6lIkBB($v(8m_Z;vV*Pr7zqTOu@BIP1Os zKI_d%?(W-k*Obfr1EDA&&lQ>I`V@Wg>|fyV({HkWJTl5msY;RJN4c@1Z}&$}ezYSb zRHZyAW(iwh=i`Q5clGang|l>UEXG`)BOeq>YF=-PYaTZu2b7CqHV(jc{i(F7{tCd- zk9Kbx@f(0VL0QpeGjuR0IHGJTAjkTo#EqVzqsVxq#rp%}y~YshG+tzvM&XmotcW5w z6pN53>6hN@w2r)R44Fs1^&BE@mL#z;F(?&{yZbO#yXXtNi{tI?FlDL(nPFtlQI(@Y zoq-Csa{KK>kB+8l&Ij>GUgYH&%^dGeB?K=yKodMp_+qpkuXX|%aevIk_`QW<>ip|! z1@S|QvKMel+5YT^GqhB>T*P3+`Jo!UcL&z%d9VQMUOS<~kNT-iH zB)DAeH<&vI0b=e(rElduL^dj!k-%2i^4#mS)>Em3Md7X$~{R6iaqMc z%WgiYn+z9oKVGNS>m*{YCVXqstV+m|pPKh1gDu=w{7JnuzG2IW<)Z}tshGdc^bI{p zYe;apHwiK~6*0Bd==n{IiM5qPKOUI9OitMau$4)Ug)KKF;D53O7%{(60@}yGoj|WS z|60FaV%QQASFjFFbX)H7u1o8(Abb4CnNrtu{(e^_Ao#Q z`nq&DSWgx-v90D!me)OEan7)`_K3f^VA4nH(|R)~0P{6^1_6mSa2Nak+aCJd;eLsC zO3&5+Nb{ed>ye$P>>`Cdm1GIg$*+H82S0zF2Y5+)o4-qgmmV=VqL}P4Pm$jX&DHm5TZ{QImo1 z_Q{}M=~deYXQm`4pLTgh|3Z4goVc$I-JCtM_YeC#?0S_WFI;>FK_}H(LRD$nvLTaJ zbOE2Bpb_A^0$jwSE+OrgdRIx6|u8!CCgtnq+>;|9iy4 z4&P0qv(B!IX^=WQt0XGVhf90M;M6zhgCsgPw zUEfSdS*l!n@2Bic<-78yX8H4_lLIaKQHxl2HXTXgTs-%HFB`Z(4&R;;MX!@ECbO^F z4VF!$P;Riz=LGQU)VA2-Q-8v8xe>7_7=ISE4>;i*S{s3y3_ zm`|uXdAYfrJ?F`HTSv?iB|LdSBZX6~JFR#Kk{7>fD+UT;Ix?;_C&utso=SdPVp*Z~ zM-|^iqyLAt_l{?~-}}eATV1MZ6;%|iSw++eEs9!2OHrftNT^-4I<)q#y=w0*QL)-u zB}i3jBt~lm5o!cUgzqQ4uIt?A+~-_9_wSG2Uwu62L-Ki#*LaTC=h)_IN{%csHE4b# z&p!}t|B~{oJdCz-o<~)4;auQ`;H~fLvuw_^E6a~MzOn0RB@8TEcc+OJ-^<|uLzj(pcc*H z#^clkjJ5(~sDh3F2lYY9OP}rAYGLbzNQ`-}_*u($83#!%-~a0=^Jb@=GN9|sJB2(4 zOWdy*$3;4wy9n@r%4j5!+bP1{ z_o^Pd9Bl45vz}=n1T=Gn5nCu|aq=Ae<3nMe*;h=z-SJ;7-L-Q+>p(2#s1z@O2zYcV=QV*b$a*(gwBnpkF z`p>J+41i{C=4d}T^Sc~QwEiPD+ETj;HZ{KCV}_Q1O(uRX`HQDYlK^=rv=$SxgK$%g z|HBsnTs7E#^w+#JYy&-QTfiZU;^!`oCOo~SG};y86)N@h`|rndy}JwKOJD{^ya42Z zw4$~Z)$Jk`2+Fd@x)!Vc49`*RT((2tf8vS&0|_v_#btkw8j6v>#V7~sRF>9cd@!i_ z@#b{BTkqXnU4ld7aI^u8k>4926QT`~{hSKvq@*2LA9N$^H%tgD-L9VA<4T0aNUN877Esm#(1`JoF_>%iC- zLfZ;+!(iYj8MtuMlI$FfU_Z|Rm`TOt;|?j1ST2bF9`coWa?6G0^YWDw?Q#3Ada>c949pLc3K^eGh+uKTPNAcn&KJ_h(QEkQ zZCN&1J=dldGrZJrg}k@5cE4^NLCKAm=-6L&u_a_~ZOH4HGHX^r4OL{I79}xLXaD~2 zy+F`P1%RnFZ5Wyq-0pNJFDN^KopVebdzd{amy8JwG3GlA&MI1 zG=0GiXed4m%IxE$c@$a_s{E4w9shLv^PMAl*ry43uiYigx|=U#DEJKr%<^(A(g`Sh z)Xpxh{pQZK_cLU|Kv#jue=ss?qFx0mD2j0tT(LFUFpY~7JFu~8jg=24_ydv1bEq-r zTe?_>SjCWQ8!(t56ax{SJNg({^VZe)?(M0hvUXV4gnPb~N;-e*T|}W{=*SgF z^wO!hoy^~iV`F^-aEPz*MX%{y$KUHA4hS9llQ(2JUo&>nYGdq1o;j+v_;1On8EHGJ z-UgT;a*h zdiWT7b<4=RK0|Ct1HVjXk9Nu0DUQt6!%8{HARPu_Vuu8Kk#$Q`KJ`J_XUi!<9z6aL zY!Ob#=*)B2+GsqMLm(Ta`Z?wc>m>n;&lYR#xJFT{TA(JToYXV@r~|dv&FlsH7T-cL zJ_D%pKr3{LH0jZn{yQk+V{EtLp4;}KZV+a|t()`XOkFm$oHE)C2EpHHFKMZ0%pcXH z7Lzli&DWRWxPoN^0woR6`~*6f)LVYv06o@RxD$>(o7Xoke2gGk)wcdLN+UbCKjm4E zfrvpz!qdM~8ual1eDj^e*D@?XkL_)4$~vCdKg^MiN@Bx3GgO5lG}D)x0rpSxD5QIw zt&TBi<+B~qFjE(oGfGtJ7sC|uIT+a5HIlOB! z`Nzg17I9;<-7hzLfZF>-asRQqRRJ}@g}hGb<3~!wU8WnC3qHV0)JF{qfCW`SC#^3< zAa^PEV`mAy%sW>~I_`IBBJj!D8$NsM_*-a0!tM{$(6cE)26rbeGS#+wv3ew-TBe+S zwkk<%T0{QtNN~H?z{$G2n#BpC5$Su}B>gcDNr2)R? z^xARn=}2>qykUo-7Z~4t9Ur5wY(8AsI zoos!nTprRvb#GMfdg#;gv`kECZRW{%9#v@8XhkvAco(r>guI#yKS<$+f9)15{Mzd1 zo2@U0jF^xJ0E6Bby;pZ+zQ7MYX{u8w|Bs(j=OwJQ2o0bYH0{t_$^%d9~DnY~N!B?~N z<+@yFV~VeL<*q@PFX{d)W2sT=5vgSX^$o%%SSW2%bvvObXBXa5dp23%gy8faVV?Zx zPxQYT;Ug%t-W%aO`H*f-w_9Btt9sfr$ZCTW*l~kBU3a;=UX%LMw=yE7Tr|)jV-|o? z)b&hxz>b6`MSbwH^Xe+lZ`$F^UkWV%h;SCxe-g{j?U3+{@!$aKbeh%yn_&ILB3aXc z@OSs$+YIFgY8wsSiysD_BsAk#hg)Hmmi%ngttk6MxPdA4c5!{Cd0Kc=b4saLAcYD7 zD177*Lw^2sYeYM`g6PCicY|MdID}u@+JW+U+bql0wu0X5N80dMGOCQXOEIhtmRLV% ztxV{6l0V1DkhvyT*e~8{Bi`fad^H;GQb{`V8*H+eofeITUnd3zq676MC&Kz04TTio zmsSI!B|%dQS!a_nr1a7Qy*EcwqlGYL+TBI{RgTYA7-1Dzo_-CkK2}EAc;C1FCWZrf z<%&)uKx;Qmw_PD(I-XE;c#p@)qcv1(xOiQ~y0-FuSaF3=bDf+9pWJ;Ixl;+#umw?7 z1esL=tRu`UFKHt{2(hiIr0VNyI3Wj!2$5YtJ#2aeaCgsH;Ok~CgR+ypc?j3lkUA>6 zK9C^+-w<=le+HnR)?RzNq>n7j318#GXriDMni}cPQV*CS`VmkU3Vehgliu(Wv|D5u zckrVzAmUD1((R241@DRj1R=DzKcDq%spLiSL~gA(>iofIf!45VMZWq6V+5AJa@Iwf zrOx6^sJEqS;@;Aqh>&b!k|6m~{fHVUUzA!+X3`p_q$%1~uCK@C(W~1=Yijt-quQ-8 z?O~X&6U+YTn7!ENB5QnWO(RJiAslTH{>k=^V_6kfg5K>bdv%ZnK-Bh_^q?w|)JhU> zK+?&CCb?qY(@u@eqorqLC|)5LLDHKVM*yfA-R}ra`CGu`gD1fI*cobuGz()(v^$&t zn6tqPk8l=YWiVYY(Zk&zWlnch-#%G~iZAX5{Ic6QGJsNgVIwy5<|WyEyA>dLCcPQH zR2<wi^G zl35ppRG@^uV2t3RD(D-?K2Y&Dyyeno0NA`uF#6H{P|p-l1~_*EVl3E7)_X5x zNpXd+MUI3rID=0Qn`(`n*dla~r>=~=0Mu&+>5436N}ViApUEg-3WuOh-R;bKX+&f1 z*MjHkH70Y3_+KRv-fxUn5+P9=PLmb!nO%K_AYZqBcA=bI?r3F4eZ!##yZqMT^^A`p zV4^_M*r@;TNQyZAuS^{nU)LdMg7%&Y*zOLY>4ZAm?=VDX&Y08p64aSy+xUj<@{e`#7NYe1&7K4*D|`mj0V2c#L+Jk z(|r;Z5~RLDu(UmKaQha1s17r@nkBdCORhL+?BqR;Iho(8B#VWBVD;wytJG!jT=>kSDAYur%CU%$YfS?1z;(wl z!GSs+r@HI|-^4>{NLuYXoP17nxsSF!njdeeiyVO1ow*lq^5iqgAm;%EKkuK6wLsib z#gF8{ozd>YRkeURg(ioZX|rG=mT^rr*W5^Py$PqTyJw#u%ts@PnqJP{%c}KPg(kp) zsKHM>!JMz+tcU+maC$oEVFB^CJ%IZNra2r9J_!nS2j->jY7E9K+PxQhc5U?Y7T@%{ z55X7l2}~?wHv$n_>)On)G5DgFpe6f-Mt*hS%$?7kz_6;=h|by3fR$*r85N@#(2#Ia{?}L1eZY~ z{6--3Yboy}hbD$$I@TFaQL`_7!vMf@ioZ$V_=Yfmqc?j~2n|iSGoz`u++ve}B<=M* z=#hm&;|O%h?`s91SzPk>&SC}VsUc%e)Hu8|0N-Jiz3;oIzls!a@vvwk1p76rC|L!Z zHjB9acnF|zJcbqISoS*Xd1NEbjjKnl2P@UKUdfdS3VEL&$uOP|Lh$5#mW|ly*-%@$ z<^+_a9WKj1BA#0z)j3VhP#x;phK=~uMGGKg zh}E#2yW*7f>vU(2egg~s6uS^pZZ^?MT>aLNAH6c*3m04V@XOp8&BVPT9-BT_Du*8K zNLKPSRUFy%{@W0K;50gsR?Z^Zt!UpN0Tqeak4MG00OixfCUBX%ZjRJlc0#gy2&!NM zm$h=f@RJ~pM$Lurzh?|5wE%mTheN|vW944Prq|PNliU1@;FHmiFs_Q5KjL=ob)kxZ zy7kdj(Hu#OBNuv=O<=3{HL{t@7coz9HIR+Z#On}>ZNhq3ab3nX>n(HPI&sn)X!4&G zYx`D92heFL9hC3WQ9OSSsETxAnZNQ|04N3IKKA@Uomu*OpS$G`#$;znN8fKAz5y{M^n_TxIw^1#*85Us`}~^|uJ4{!0yWS7FjS zzD6Qd&5kY4#P*!hDtKo#T}+#@Z^A%QXER6>zq=w5w9+W~jcOPMkkrl&Ricxl^J&RoIfumHlM^ z@?bRSY4NJzXksBT0ww8f+`|1Mv5#+J3kz~EHqFlTflO#*eHph|GVojS%c_v)s$D-S z7de+m9HRQcGVAl2(oM30jD?##szX2B-rDsqS*Xa)+a>u|b5W*;31V&0v0~g)^)1}# z%U=0#8I-Rf)JLCfl9{gDyC_U|M=kw!;I+?yeW?3eG~+<|7z9G4DHo zdI}hK`6f2a)kZpYk^6Gs``(jf_) zw1z|_6p03of&fh4+sS!SPK~qsIVU~47a$ePngfOuYMo^fee`5|!Y5nq>CboAwxBlC zhYz2`iyi}&=Hc&)(I~nlv}?jvL8aKyP|SC)uYjPe>o*0L<-0KeVrMr~c~e|5wmcHB zQi>;A8;=)Wb4uXMTK6^*+NkTr0c<7w7cA{OId0M|ZrR;_$BdE-k6O>8Bi@O?0O(yz zafPLkvzhPlV z@=YKCpax3DF{yi~m_`|++<%!Ryq$#30@IqOcOqp|(#l*4 zK`PM5nx5zyJwV}4?5^FSxj}UQgpmc=@$zD;0xHlsasB8w=l_7%Wj#YtF~__i%4lZ# z%umv%Z~%AHcYEr~oi5?uJrt0iW+i?xuQR+s{tz2T8e%ULz^vtIbP>&l!Ha9_*O&ff zK~jMN6R=&N(0)=b9N_vUMMOnqQ|0Zb4^2$m70H7!cHpyh123imAHM{QXWuPzI~9eSG%i1qmXvE4ZpCUw?TqjxJAB+|bQc_I#9LEc|~=Vt^y3e&msB^V%Cm z+wosSs^L1X9Nz66m1=#fBRVo}FXh9Dwcn%%+OJ-aC4O%8R=#_u9qhv6#Q0+j@Rsqr zf7THm&DMe-$y&^_#@N#B9moUM>>}^ zWBp)DXB05P(r!e9s|CLk<5g)SbI?rvD^yIEEB#HKjC4bI3AO=t0m0~Eo0FAGYigEOzUY0s;vG;BJ*w+Pd$o93ad6EU^p zu6L>k*;NVc4O~xNr>1c(O8{?Kv;3+xGl)(;M5fRBZ!rT-vk}$%o9t?ND+`%E7lBv1 z>Do$P07;c>kGj%GZTPb%-vHIX!Edj)C+WLaj{{_%I0w*@eE)E;!5(#qc9-tm@;e>O zPoo)wF}F>2JMNZ;GX3_nDh>S-JXW99W1k6%pJ@Yph=5B?oJLO599xn-B&Z<-c;|q< z%w04;Fa{Wt2E3Oev4Y_o({&md&6;rmR-((KjudV}) z9_>O#e00+bNdYKTnnUiX(;p7Gdz|wh3n|ZOAuk6Q{Y1~@y^Ll)E1C;`@+b|Q8i@}A zc+4)S^c>rNd%4aR$S?B9`t*p$Y3YCcjB{;gX0{LK!gpAK2qyaI{rCI7_N~qUpb^(d zdNF|LV*(9ehog3-R697Z5$DbUvGJ2ja4bUQ9LOALiV>dIRS^i{Q(5R=s|FGvTqJZ2>(^Y)$ivHNV z^S_?#-sHH-Gyi?SGaj^;8H8K%M3;!Eorlrft-q{Z2I+v+%W{NR@EskU!-?`{1RW~raBA(=UEz~-~EFeYr*>bgh0N~o|-MKlPZrM<#t?sQga zST~CXyyjXHTmM_9n34h@EPGQNRr4^WW?@^|Y=kR7k?Qx)Jm=o%eBe&tEi^M%T^!)8 z-d@e7(@Q_eW>S%ajOO4z_Xp9KU}9!*@;tZJS>%IF-Gn1ztydjV+_LM32I#FrXX+;( z1GI^O+@mrnTyz#8?D&wRggxIL5m%BMV-2}d16yNz4>*pzWCvDXv0{h%7?;ukj>-if ze&lqBR$Ma%MIOVPna+vfVEm;f{;0K-KyLcBAAfs*X-5~n7>aS3F!AYbsBAJs+IA1m z;14Hu&$C~>Y4ZtqCs4xCSz`{y%x?)Ut6KyYN{vJTVb#-cqNfErL1>uD;=nendI=aE zA30q*AV9sbLY|@ZeN(bEtPty>x`nJpXauE8O)-tbV#+<;&(5vdEbpiIH9c$@;F06C z8wv$%MM$Q(1g~s+oXJXh#pcs$DO{Em-dnu&w0%&BDIG+R2ZTN@qj=K?-E#3W3-XU1 zMJvOf;hq-T`sqEu5~eb&#I?8%N&SlFfrmfb!gJd2^}$zBuPWBo6DbUr+F$K;&7Y#+ zH_DspNqgFqR-h*F*8B%g$JIr%BLK4;%K??|;N(f>`yJ;nKThgle=_DCb*nRvq3Fw$ zyub32O$FM6M2HoKb8eTs6JfH|Q0$>Mj(m8nN>};QwJGU+umyT}Lvu;9*LS)>UXees za-%5I04CaImS&#pQS2IyF_`rUWrT5sM~w=WI_Fu16h}=p^9=YNG+G_LW z{PlEA>~(MEd2e*6+3rTt5WZ_8|6>%30E}Xsqd%2X8Go4eJ-lz~y&OE61bZ?yf0N|T ze>*U^>*r0)pVF75Np9icC8&+ILi7#z+v5;@P6*!eK&g&U$RX`P8eX+Oafi zfY_XQgeoo8_Hj(e9061>CC>>da@O9TzH*L1#!5F9$0d8oGhbULSDb54nX03cPL6Ih z7PNX7$Tb+}q?5&$8}I6+pHTJ0UA5TMpEZIsrues}Xe~W(i($eC@3Kt<3g*{+$}!T- zyf~VuJ)C6IP!W5e@s#Ze|117#UpUnHYM?41 z3|2r`}6X0P{NG`?(XMrMAMP{wDu^xI<%lJRKhbS%Ho;yYS0p_9@&&bzVsF zMn}6b;G_E|dl^?yn)KW5@X^u%dn&6pRqy{-?oGGWP_XGdnMZ@LeItq53bePwY8%0+ zhL$YpsO?(;^ih1sXAp1=*N`ajFVZ;2EgtA{k?m*Zn_v3_JY47C?f0ow5#}dBwG(0I z?0V&3d|q%9mjVAF^G?|cLnL4K_+aY<>c+=`63zfr-6mjl%}63boc;6g*Y`)l0K#JO z{Rr;aFk&6dn>sh7n`qY>aUB{AsL8j~fC;j0wShhKPu3gJeIZGw0!)l4B6!{ycBseJ zIKI8S{~*_t0E=Poj8jAghL@43%6{JrBojV8h6ersty%nEn}PvI+JUK16Gp%|+T zU(rZ^xrki&zu3=~88c<8yaqUs;9I4@s}BXUhq-ZX!(0!V=U35%*_Vhz1+4>%0g3)E z>jm}Fqh6Q4ke6fG?rGQSof|WXi&tZ$S<-cT0X6}@ z_AgxB2|ZK9Vg0t}Dz5utT%DFK?W%i3F{rpj8l7VEA- ziE`Zwa6(2n^Xx2<&V`qaCV7t`(8slry{Y5``8VuPq!L?#8n((8y1!6Yo((kvNIT5H zG`HLOav9KNl3dmkVbWn?CmSJ+8Lfk|P`_}Dcq|GIQ~GI7tpx!adi7G+1R%ue7!7Be zS>m-1C#@iD zuPbfO2IE;I_YH1YyM@jMtteD-dCWG0=q7UpLT58CM6Mmu; zM66`QRqfsWSAVMfX?zHo*B(3hrDguX6m-fVjVbNSx3ld^pOc0~aJe{fulcU4(p}W% z;NIjYH#`9Gg8xqc@j*#~)~sCJ3D>^%w=A95a8-&w&D%z^u{o^N^4#2)0U(1$onSip z%pi&FogW^WVNXBCI1jdzKb{TyRC+bp-eTB=U&M)VAGYTTH_?ndpMfRgXXD^X@5ME5H5*){kGTXl22euT3aZT!M@jnGG?G%XMJm^ciouF zDmALV2yTtx^9{(t^YE8Na9z}m`bOHoow9gra-*iAqN0)ZzB%QPvyD{BcGK(EM;n@( z$bhi27(#zd8=88GJo!wCrxs{h#hj3y*3kDNK9n z3bIMPUjqi?$gBxq7fzF8Oik0LMG1wXPr2^5(oc4l-@FSA&LR;uR}H4*~@2=ee|8A9}u4GEveT$8~Y09e=~trgG$N<{_O5jb~u%g78% z>GxW=_iqz6HeN#% zXL?TuAqU9ly`46Ks%)b8uB0WvGBqMF_cQEX%jQVp>y|BPZ^Uc<2Mx9T7Y+5T+3!kI zZYr#!`TcxU;=R3d-8qui$`%C!83!LZ2z&zIZCx52US1{s4-P7adc{7BDHk3;fq{HD zV!{9?3Dv$6k%*>041%3gCTzLY+I$G$Mm>F6%8+D`9y=z>bzIZ@+gTTr<5QZP>@l@Buz?f^QBEN%6Ejb`R#G7hdO$9S zt~biUlkfSL$BWfDZxHI7jSeLBLYxD%DP2Vd_ylhcC*X&=$(0rlT)Z?CGTS8e*%=u$ zyWa1-xX>2$;lT9+rw<(d&;NXQB7Q*M)Gz!YXGxS)TSKC6hE+7P?)z z=61!9_DyZR6uxJ;f`&zDsUznJd8=7rbnG6x4n1dG#$D88PhB3bhOjY&j=V{c#L4yQ zF}mn;O2prL*DtvHmSiwe2`4^uU9iB>B_0pa1JhSMwULj2hokh|JM2ERQf7W~c+61k zsqxX0C<}~2K1_1*^@x!#n&DBDWu6F^nkwB8)^#@JUy zo!2)7hR-imRVh4Z4a-D#vx$pV)7K%GX6tIb$NVXM2#GeK>I+{dwRA0~c09?u)?Com zfUU*&_l+P?5%0ygGF~P*eEQDg4T))|9@gY%>TB2&f4e2L?K;hJ_%aMu6!JP26WrX@ z9k~>=vNITg+kBeDC0OJo?A~@JA71OL5$ez+y>kCNbiAfOVm)mk9+9>@49gfbv7y$4 zH+%b&Zog)x@xC9n+8Yz;|^q5 zKhSjY`}zH#Lf~#nrCHM*qblrmyEFN|hKl8ow4o0v5R~)^ zAF5#{Z6{?oGj1E5!3}ogiHl9!IiX!K1RnxNR6aVbkPnJuoS1Ig`nYJgk)9yVN>_{O zE-u}=E1w^QF}haw47rY+%?~hX*a(_eQ};6q>OYYpD>~gkVDA|LA$RLYTgJNydvRNu zOLcsCYX0JQ}DIMm`n^1id=(Nu5tUaPy*EPA(aJr|q27$VlJv^u4uVF*@O zrj%+x9|UJSIiw?_5jEl?yw>L<>0qk(a3tmqFL~^vf47qP>JRy`kJ|pR_8-+Bn1pZ* zmc)Qzg!r8a{igQUXzR8|@)ziIF;@tiiwwKh6$?tCSMe(W%4F^frZ4HTn>i12kIuL5 z?vTyzOwQUzFfFd0lUb`eW5>t*z?z5H5ZD)vx(s`5EftFHVoZ<4O!{wVKcf;yq_fan zmhKUh=I>RNH@+TJhyHk%@B(qhk#+#AzE@X-3Y$?L(}|T^ghJCU2&%9vbYWtHJA$~l zi%Ozm-B5~;{G80c>=kX-aSqx@ODM0OkJmRuB^JpNIjphP*#%HpyZGeAEK-T>P4nU7 z@G_zw)&cWl^8|xdXFKNWmcK2ga+9wJGzE4xwrGM?AhyCqg_5UXqtZM@(6=P}4T1!A zfaKa$h)UYQ4|UqM?m|x6rCeP}St!E|vB-9H>gMl69r;aiI&kbw$iY}llBSb2fsGBS zBI!ON(?Wcz{YAk{gJx zMq*SN@=cQK4SFHZG~>GS&A4}Jo<$Ju&KUJoMIWaC0dS*HgY1$BU}ozK?=QMO*g|%N zTlOrKw1cqc*VDgaLU8wf?cUg%dfp9H23fC1w=tdTzy`*=GR%jMnEOG6)S(ysy|#fL zy{Z&VO22<;UB5bdOLjV(d!W3XezfEL!GBp6y7|8Pzq9~uOe6_&*&VyXJO{TVPjxKz0h7wB1Qh*pFR%m5Cvf zTHmeNu2OCuE04iH73GEXtYzbMMi>%qq(^B$0cPo#8N!n;AAVEu@pE)ij2hc_xJX-- z*wM?dgH>1%^PsuqrT<)F{LdGDVaIx)q(UL=bUxhfVf!eAxvI5NahNzGr~z$mHyB%S z@(T1eo@7z1OU{s3)Y) z9?d0kj5Qx_rFFyxn{k#{V3|%i4efq->|ajC|19pmlz3K$Xp0m1DsbSnvRTlPk_xV; z7io`$KmO(?w)&~!b2Rg%_O5)m^pt;sxgPt;Y_V~2azX<*;GDpVU?j}BN``Om_?Zw&I;4B3{_}d7UzMLSL znhLxGf0QM(Y-(fZ-Ut_)k)rR8<07#kMD4@m$)_y9QtYr&v(m|X=0gJePr*mB+JE-d zl==y9h?{P&&2(?JtOmrSpuI`!wrWmIKC4-$B-_Rzl+J{Gu^Sh{QR`1@c|Wj+T^P;ZAOi3pA_FG8=D(gC+R9!Ke?Ft;wtKZp)$P$H zH$SkaHs-gON(d}mmzoR)$>(OYw;q4qdHnSY|MnToFiOUUjrwVW`zOcn6o(N1tPz!c zVt)aw@N73U80|gR%M^>5_J4lM3E6GUcGxdeHUyvuJ07;%N8b9stk^rb)6da{Fn<%X zE;avQkq?H>4=t{(#)oKYBiPlDDG6^7dnfcw6`x4i>^?t&ravuWZH@(H(r&LzBrqiv z_!@8HF_TYc&O9T)Mt~bsaz@zU)xjwhIe?M1FpXsa10!NXng07x`|#ygp>4$mT&jH} z$NrxOeZ~sd6X3wJn#}LQMG&`~PIbEj+v?N0!ATx&Xg#W*&Mo=42>#>?6sgid;8@c9 z`2T4i{}oo<66DW?JcG9MoJ-SN*)TxyrU>B*(^$0xF{qPGaHLG1aUSWLA+`p4(4 z)4+$ls1o^nD*GXWP{+ytel{%^fOrYir8(A54X9iI+YH2s9W#zUFEYr>#mu(p*Qfmz zEq(>3-dj^fre-Y{u4o)O|M);yb=A%17AahR-va(4guHnJq!1-1_KS86ol}*=Tt=K? zu^952+)ZF3(ZlqoE1s>4s`&l6kz0cS&o&nr%$mHTXw?Y9pLE09N#Y25Eaua#hOh)3 z<8*}owF5P0ScTfz)?b|Y?+5EeSal_17o+Va3YCJ>>t)nu1mLH@^-c)Xhic-K$<1WpEq0kR$^v<6Ti~b*$8qsk;9eNq&6(+E-M}k^S`C^-v|y2nT1t)y=jxEL~OdT3!_pskKCk zm02Q->hXH%i-QBi_B&8-0&A3mBqs0G)svNePXmhFG6nbbnD_GFl@DQ^4;h03Kpb~` zDu;fY&faPa+k@AF+b~NQ__Op2Oa>F6ed8Uug6;`(B9gO1-g zOfepzYC#`e;6La&MouS>*fBJQr!cFAcm{;@xNK-L&X+EMh!em&^I!_ur*RMZjg5_m z-?&ekoB4GH7C+**5HET|PVRa(NzbeL^SoTnA`il!b)%EFv+t~#;%Nbm@O?0Q(uc>{ zd9M^MMq$Pno4iU;RR~#SVHDZpVC0y$tNya^7Q}RfIu05hdz2q2;Wc^V$>0@3*_D;a zNFNJxMyhhcx3z`5RjAu&H~fRZF5&RM7X=@@Ef3_wzr|v*6cvjaM6-q*RK~p4DmGrO z-D|wv`G!qEK%nE)XY9>^yo7X5N1tSG*YOf)(1pw|{hCdi>qxOCXP@o!6Y|#rDXS*Y zlmZuOP33Cf#+K&hOhZgF^e?~wXkETn`iM5GC@KoV%Ld+5`5WiMW2#oaG`(Oq{V6@s zB*#l0yxQUt<-Jg8-(PsOL5*IX-7>g$@#(0nZR^kNj_m&3J{xp{({RsJ*_6}`9^_&L z0Nd28$sJJ~?ykML=q(d;XvP`;THf^hJ$25{l0g=Z;U$F+jSBigJQz$_;(8gI{Ib1WnM@vO z%i>jctbNYHrlJ zGjXKoD-IFepMX<60gLG9=$h!ab<(k%Xl+)7Y~@sL;y~Z41t)FYic1ZQ;HNXaKzioX z?IY8#cK!`9`XEcoU~^d&^f^(e0|H5ojx{`{hCHa zG@4n}XW6VeQs@A(=tvl17f_=8p93v7Crs#a8HH;YY5S4R1|$N@5>~=&EllzGWSgDJwtI%9_|?;+Nx&FlX80 zyu@MC?Go-X$R2*Cq@h?eXjgw+im2*eTY`GSS3imaIy1Ig;%L`wi(wymN)T@dYg4Vb zUCl@X*p<<_B(M9Wm}@2!=B7&#(7m@cS22VWg}5@FEt`J898xOlWsCe`Y|l8iH+7=p zsN26bZ$N&10jAx0c>VRdne1w8~EfMEN`hc3J-r)>d|aHrZ91aiV^bf7>h`lX5i|nC!}3 z`|!{y%7F7Dt;nG(7up`(4IT2nJqL;0k&{TkOZs;AzEz+=$TpmDU3Hr5$l)K|_U$YJ z&J9q7vZCd&_~*T|v27VXSGfui%NwejA>W5WB4X&zo|I!-mv*0|-itwf5y!`gw|T3pe-3=^?;M_Y1E2TW+ba4}%2snER5j`fWAei>%F zk5t({Jca7seXPUJcVe#R5L{HzN84#=Z@~|6t`Nb<9V^@hQXr&xdUf`kwb2{;h?Z8O zPx?bm&R9(NsF}~c3$Qy@X8*i9RCenH#!b3^D=kmZFmT;7r+8p3-D=TULw=}iql?cj zT{SAnzx4wYj|qlJKAZA{`+*fK9EO33s;bebb%eXim1yc zPIryz4Et;p2S2&x2`L(zUOdiN&0rU7LOzS(#>*`tqX-88bQZ`(MMP}k95S!S0( z+I+iMUAr~*O@cLcZ`fL>%xK!Q&>mEo-&TLt(X~)0qNz<+we<^JFUvA*Y$XO0YZx!;W&f?*)Jkc3MYLM}1+-Tx^(p-4W zfM;U8)Hj21Xxx6vk4!~kb1ckpm}R3;FtH!Q>sA>y*xX80Kw@pVDhQHqe9K3hW8wDC zqN>ax>}(URsaeNvR&1aa(X6c3&q}!T%IbzNlL&AAV0}<~F_?dIi?s;~)Ug9-9k; zn$o)N?7TnyStlCfIByB6#dz}-;jo4H7(`|4$g&R9eY3dVhkyuZOyE^-;(^U!B?R6t z`unZ&mWD?1g_BO)XeH;kTdC>q*}Nc2b)b=5k<3>oLJyHE)e2@u?OQ#dV6!Pew-KINgdWsIFr6 zeZPJd$)!8t4$h1hkG?K4_1Cwk|(}ef@r5dg`c7OF-WI;T4v~(ysiS&$X!;pTh7{spfJ05TQm< zx2u7auYK^9!&2t3wu_9Sik9W*&JRnQq|j!Wt#hY34*gr331Xt*>GQ9@T~aKKxuET1 z#d|U8D}LH^V@6$h4&!H1-U!VH$#`#eahe;^U4~_j=W8}Kb*y_Yi8Ny%=_N7B4uI&)vR5V5qO zO2oT4bSDvIj?kOGH2a?Ntu<6+YW$<^Ur{eCyMtCucCs)hN+5!0;KF9;|6)trz{gF6 z#`FD-Wn$MfnCJWITmbYnLN`=4E8X3KsDJO<9d3Bb&UD1)$Kza{;I8r8g(mMR)(f=9 zc*w86=)qFbL@^_)4|!W7nuYZ>1C0f(Eszlwa$4&5YG%09wBK50f~Q}My4UEPLdRDP z39@Co>KpZTC{l#o!TVQqKQre5$J81-%taaRP>lOlQYF?4$*=YOq@F1%Duz!#7pYNx zr3;hQ>T1>Ai@~9*eC0Yrh|yKkIz|YpZNU8XG=|txFNc6uzpz)AW;mK!@FR|DjM3ve zS&YFD|A{*8D)Mdvu|t5%<*seNoO(J)J+pL=WvW+yZEVTm!YL+e_)J79(q}DuW(1cI zl^l>HJKeD2aZN~b$k%FeUl@n10}YYt7aGLwln+_7?Xcq#U|s<@pjB1lz zP?=@X36GY;SF$_jmI){BjoWbCU52oGX#sEMvz?u^;v>w+w;IF4bOxg?1RX#4@3d%j zBLHJ)S0sU&E3hR|Jx-K74`9w<#vMv{$9(ifzVlY5#gCM?1v?wU&~_S-tug5~$MYE? z$4e@nfo;q`>Rt*oc}AUXpXnMuyr*+bEe^By1+@#zS~b?(JV{zk;;s){xhE61U9c+> ztDy{L*9ryRZ^Pd@*W)v6_l@i|bTe!PPRtKfchXSe_PT7Kz^^>rKD8S#x?GB40m@h0 zL?-9g?o)NyRGS}D}_&h>7JuE)k1gt4rCs+fp5$4COs7AVs?i1(siQ+pZKUP= zz=)JX-mYkux*cRme*;R`pl~Qz(e+hY+nF(O&s_&a zLQ9lXGG+bd6ud-BRI*KL0QU;kf8#ta=W&Zm$Rsmxi*On62WOVkryPumemoS~&|F7C zocC3d4ANb*jSIDk#4M&ug4E`Gnw&U{5*>pw6>r-}br_4_Hne-o{B77QPG^`61?AE^ zlAhjzoMZnt3~AJchD7#IONCGK!AQ|u0lUL8QFm~glN-1z`Ec3ByY?5ET^LIU15sv} ziI!VFxt=~ZXkZ*WYVkIN1kiRP2-Wr5fdV_&99L;!v*fnpH^i%)jHDZc?)P7O@{J4| z{qp}9d(WsQv$pMj#*PJ)t~BWuiWEZ+BSkulAOcdN^cIkkASEy$(tGbnmtGT^gi$&H zLNAFBrH4?YLqhpqI5YQp=eeKtzW)z?a4pyJx{@<{pZh$1$FZSI9Fmu;WIB-L{7s6w z8t1MSpHJ-|jPyPl)6W(zfpkVWn;gJRAGQVFR8>@aV{U*69-v!&_fO&M)2TvvuX$aU z^mc!RlAJ%}{G}MWN%ic!o8DjI`P2Fs;%65FFf4~ayvdcZndryE#EBe3>UB0n-@M!W z!Hx}%wgpximD%cHWCQw!bcsahXA5|zrPcEC?)L$aWy z2$WZW$x`s1v2jM27UTiSD(dF#wd{EpfVL3Bgbbj+4<5c0HS4f(X0@LY^br|!sgj1t zxN-E zQNC+aR^cz>Dw({2)6r$qsXqzrMIa+gXO z*GhYRph;4{(eWErl$jC(j(wI&e^&^oWJ_hEk!nXGP;TLST1SbE#R6lSHEWD)FP&|@ zNek90QkYyHHQcB?(I7HXp;`8V>cjZX$J05bx)Z;sLD8rc+0P%G>gS0kF@_F4Az3A& zvBl~gS$qBqY!&oFeJWM-EmqR`Uz63@ocQr^sK(7cI2(L%4o9B%W|YD0mmExrQUu66 zNH>jiP>7Ir0XniJsd`^mW$vAodpeBm><5g}EE?D2%iGoOs4UUM5AEA!%3kvE#9gj% zrl`3GEhhIIx*Ox|G9s|-0^vGV#bXa$rCZB%lwRlxcI_&5ri}_}AhiYaj!S#@dlHGG zUcHue=m%x`iFPt*@9Ofd(s|jsBTIC=A!=^so~!P4K+@$eMJ>o zcGz-!G?Ztq6^~2nRy$T60Yw{9UrXaWt>_aI_^t2w<>LX+5sI~qw+HM3VP(|=*HnkwjCk`QDq<*TzqSEVq7PE z@x$jr;^0r(OiK2plS6{MKb~{Q^`1Qcu5$DvcF{es68kOi$Dqt)@R!K7U;j z4&G4rBRVtbinbtM)4&uGugaU+^=Xq^6T*a^*)je z_m*JUyV3Ff_K$NdRA;R=$uZk_lJ!b))94ekZ?GB~Eaope23 zt^NMS#3iBJ!QeyW)28Q;@aST{T>xYhCbgDf&p`v@=-YK5X=HF$=|Kv&nkwu0#W0J?8?c6MYMIY42iHKWcxG5MrVU}rw=dqHO5BE@Rb&-oT zzEETi8HRqzshjE;jxd0*e)1IU9A&Mbh}yJ?jk`;&|KAF0q)kB;s$e!}@pM<-<7m0V z%}W+TlQ<&H*hsjfYdmGbr&Kr1;^7)7{BR>mFf(={UlX{G%6P)n+#z%kUobK%;> zt(S?P4(QS<0B8;@JsZwh`D0&$FP>5oRV?XlkV#`r~lI`(-ocR2rmwG3qJ=?7Uj>ufGP?rHtyc}6aibna*^3W z|2(i}GJ9|PD)foM%RwF?qpu6om@*$D@1<)$f*UtE4;4OqBb)2Rv+F8+33(dyW&xM8 zmCuGFJm+f_%iPoRxndXIZGT)w`axzlHE8F6u$bUw!@q&2`l4P6?Dr7i^E>G$)SEiy zO!Svk&N0WXa~t?AIKMefy-AjURzjY8}UOx^5XCcsF*@% zr&^(2KZkj#8p{e<-oYCL3UhhLB8=*v%?7#|E`E^`mZCd;+R2}Tmxo-@BDnnWi`jic z9VjiL^KY?AjA_}uW2Zru4TA@}Hz$Ypu*Xz(&CvLr`2OU#Oy>DMvrYYP(z-HtlXsz4 zsd+2Vbxxm>I-Z#4b^YO7Hi@R^$oK8uC>?!*J956zeqH4J|5WY$bIwMBd!to%b@AJ7 zt}5Y-R~(fn8~ve9*z@x~qE7q`LsC?BLcCr5Ft^O(XD;=UF*vwdJT9<|Po`?~ATn3R z-9kcm3CL{+8k*6sfCg zV&Aok)!O&|mrRTv_WpXWM6fljY?HcBOnbHh~LGYBRP(^4Uo>N?f7k z?f9Z#k`ZkTlqstj(HiIb@k>JY^Vhs2w_4CWSo7dU$DCu|fJmBagVpKQUB)L*-x zz;z$f+HvUtc}>7piyQ&A+BaVl<-?bkIAY|yWebd0ZRD*ur`eFjxZIv=6@6n`upptq zUc>z!jj5v$>@2nJZI>tA_l>+4^UsAMcaxz>g5u3^tm^Mzf>Kd_YUKm435Z|wkzKB8 zMhrQ_TDk^AkH;$wls3QjGt009GvX84Fq+z`%#pAuU%}6YA_L0iR*aB$F5%$`-=4Qu zcZ4C5;0CC%N%*l8_c_#U2uiDCsY+zPSM|E!ObenA_pC0Jzvl`y@4$;zU`iGG3Fy6q z;^%y-6Z_eC8(eA>;G-!o*63tjI;*lsho@iW$f>>;?*<+6>X#gYCNjIGBghKoYyr1I zlRN!|vE-Q9B1zx^85>u4#b(T%^0m4(PdrFCf9*x(tAS+U?TDRgMbg$y8(-d}aa4{& zHhFD4_GD(aqZa_ck}-2&f?@V|JaRwaF`Iz~T<}09{2kkQbTuvO`E3^Hal6>brE~wY zk^z{e_8%SNHLxKuSX$QI8tOJ(+8Ljd%F&7#?Xg-2y9-Q?wl`C6O^yQb_hzqcPzjTK zUCH*t=~*oAC&v?6NoHq+;1b_PReTrKC%}$8c4(wO#R1>TBnO^%7gmMa;N!F@G_i zOHh;%s>6XPS5X&o9Rq9u4~#t?xR4Zkt4ny1a&Le9ak9yA8hbJ;d=hZRGLUQKDYfN1 zNPQTyDzq)drj>uL|6RWR)7t!(d{9opV;w~`X#Zp3)=tpI zC@7(^>X2=6<;eJ{C(u?vSwwx`j_^)1e%(Jk&WpDAK-2Im zATc*T$p>XkvdjBw5-2nK%l#6BeBfS3|558GK|s4Ylhu+kfJsZt7pv#i^;$&S2@af1sWj(M`E*`0<9E@M zfC2Qu>Ag^2m7%GW6Re+H?og}T2Vy)y*M}^nm8a(=9ch*Su)~;r2@jb*qtX;k}e0wQ-DWa6KV<_r;XZv7h zcS|0(dZk5^hr6bVN(TE-i?`2ox~Y#}_BtCviGyA4gSX1Q>B;vN3v#pfKJnmyUG8W( zCTfF_*D51j=qCv-q}kvY30B!(Zu1Uy-ZX*hf8ajaa9wW(&o$~GdH_6biM6^dZFCRkPzhX$gxKogZ|`e> zwt^|EV*A_=T_&G`h@!Z@O_QJ*D`LV)azam(A`3S$HrJ=j)@ySp&oz5(n30!$a{+EI z+uf5CNGU|)G`mJ-xm5` z3j3c$>$hx?sxs%8L6(zNGC(}pn=%{jetkZny~+Pvd){yVn@&q0h_6YcI5N}*nVt;m}fQ3ycucs*{&=`>x75U8g?4yE)TDzqD{3p?t#Z0ho-Y6H%1W zbmisV5z6t{wDVlk%Bl9!VHNi6x*msX*~$!+%BPD304)uy&rR+`-KX|*odVv!+;}1% z#nHjh104*&`L|OJ(0ehO>{D+65`pCiDTfRM)Svn@eboMiMQnsi3#oyh|IOCq3 z()k*5(Dd{aTW$OB_$dUv-j@lUT%NFduXT-S^+dJqX`6c#bVWX`W&4`4(`g{8VUv=& zHr$#2Sj#$|64AFfKb)r?e)6kd$baj({{>q7@@SCvr^YLAMtN0Zs%>F6{$lqc!v99R zx(C$WI?V_JPu5k&P<#U*>CRu*H5TDZ`DA`)R^ti1^8H4EdgF91WMd|-q1DC`X&X1Q zUCUkDuL`Zrdm3*m%H7f*;v95y<&CbSZvrC4w7SWoEB%}Uv+@6r3i;Lba0PwH?I63gNx6P@~b^?5%nq7$SMK@8S z)hO!B{fUUlMY#Q3O-OD^G!q+kI3$;+(Duc86jvm_c;qlC$-O z#TS-J$kv(z$Cp62uKoWiiTgjvx$^tgcU#jutwTuB5jSFRFWyBrx%@*7j=jFVuzP$# z*BB9TLFKH=U=1AITTFKzUce+j0f@mnXT%`?H+)cCX>x$&Q+i|Nz7)wq4~Olk2wJ`> zt$XU7;%eG{$)t z7r#_oK9>3w4OU`b6!?F?h5v(}+m$f`_;(cgFt2pCOMjnJ6-sK0SSS5m9IA6v`)lM2 zz?84yF&7fC-%Q};L$;idNq3RA75@IFQPhBMqC?j&f( zi)41vNnbqUKd(!qxb38TmizJFJ;c9@%hcj$N72+tzXKD~fi<2q^nw8vHvI%rhy4e~ zQx*v!69*E{NM(Q$2)X;Kt}*jB6f|IkT=0sa9mSUqnknyJ8wP3Fy6!PV##b(j`#v4% z3Czm$RoCIy(WOno`wQ~cG4!}5jV7_nrLANQT1ppgisx+ZJiOBdxCFbd6Om+ydGrfAXb0Q8S<+b;Lw*z+?&&cO8^m`cz^DqB!L!VY$LsJ6XA+k%Nq^ ztSI8qwqI`19G0lIm5`;R=Or3ymw`Wy>~W;(c%P?llMfn~ul*d@*fX*ut~~%efbGE6 zcLq-%H>S&jhX61->>+n#4)!=EM-*WZ<{vP`~& z5X#&%_sR)SfmL9rKwT8xjv_Vs+=AfDzu@Yy&|RU@tX(Wv7~{m`#k2{ds~T6no|D(y zNK>sO;P3zXui||aM3D+AJ=05V{$-EIUP{e5c=6QUxc;=p_-oVg;2ujX?%z@`8c!X~ zVEaDZo#Q7IO2xm2%OL@mrA6~1MTl1>W<_4f-nbvdcnS=@T94P9i4?*qn#DjCrBKOn z^zE{E>LazXX_{n8!)%fpmFHs5fklp*hDj)#vg_LG_E)U&Frf z!WBl8-47ovhO3ah^^YR2ZVuVB2?b6rEx(F>nzy)D#!g|Kbv6*iuZ4P8kBTK@R zza#uWe7looJSbD_Lim9$LvV?x!wA@5%v2>6_`WOK_)%14?<0F)yU|FQ{Ef69uubQw z5Ki-tBCnR-S;;%#fr0BUb% zQ1w;8#S1!dIFZ3ZEHqQI{&w`L-ZJyG#CZ71=u&i+-dodk8*8%$D|8DeGW|c=BF#^Z zHcKMOb3BAU_-sbD7YoF*C+}QVWs^lXt3jKt@3)aBN3Hzcf1+n)XCIzuJ%Q194hwY` zU?CLT#PT~D@DH?Y5P2Qko)-FIg%NI#xi!!rJi=taiR2ZDAK-IO@_C}RbrD#9mW5Bh z?c45j$>+R1qRQM7g7&1K)3U6A!}H4m8CykPlGOanD$HQuT3Q!;NX)>CCu)o z)_%cFm`0l8Ra9*{nDDALWsNd7Lz z@!1ZDKeJjah8JjU0OqI{&A(uz-`DZ+pnjLp48(I}j+}T;)8ZyixB%-%bgYboZrn?@ zV!^QW!5fOcGL4?00@dXXQlZY>e>F&vKG^WRWT-kbY86C&_B z^0d&hCfX_8z-e4)Ege~$P5LpnEzF}0CD{>5*8i5VT5ACaI72O~)0M8w))WoC#%7V@ z3T9DwIx^SSTkX46Iy$t5g3TM5=abx0|Ebqm{_1nZ<(BmiFEMl6XWn|kcIH-odSf(a z24MbGn^PwDBAtESnRzZSkQXIdi7jS`U45_34kjkPx@xU`&KC$nCV5F%KFBx6bPm zOmZx4_Fj%;nl7!1ds5X2LoCkvLP<a0bq@4~m&iMqwC2ZY zxiaVR;KOtFS)(t;FF_)DEw7;h9Ss7E9%8Yk2Oe+V#IQBr2Prw<1Le=;HXUtVJB_53 zFVW4u(QIpxjTh=OmfLIW#a3XFM6#OphE}$B6BDbkx+)eE$u^|&t*P0&Y|fspVZzP~ z;FpBe?FT-F^^vG;2utfut#M%OuKi+UQdfI@B+Rr0)tU)z5sfxzk&*uT zSaxN`#zEgR#bJEg1DTn#3*TtH#mGaL+> z+|v1)>{_(en|Y8TjliYZHSLw6*#evI7v7eKg}T7z=~eh@o9ozE=iyK{vb9W$(Yf%w zo(&cC20C-CRLD{NuXNi=LQust11mjzWm`0%l`M%YFG7?y)$@FKV3YtmJy~QsA4Mr(s-lFh~!}o^8c_S4}fYE_$h9BK`OMT~VBk{hV zWOC}_A7}b(X!IHD=#HzagqeC1l#+E&JM$mej4V3SbLpKv-f3Y8;`=G+Q9W= z_`;d-KA0Rg@~~=xw^%SAVs%o#kqLb>3S)EjxpT4^2JEWwKi8=$K_AhF$EKUV*e^KHecWjXR*GsJ!?DpK%S$MA zPP+|s9PVG0ivF|awcqc$nvY_AZ3Au?>1eL%5CT?xmyuuadz2Eu?C9tNxJ#*^juVLA zpDXdKU5m%@$qtF-2y!Eh%vtvL%VZZbN6n?(@@w_HXtRfPAcxt&7JM2zyIHgYbowr| zBO{ipaFcYUuu(p8{0{T*j;h{gU3L3#;3^E4CXBJ@dc^3W`3E>(Je$zf!^O8+C;my? z(kc~T>@8xH5oh>&qC%n6OZYewnx>`6dEWQLe`+Z_hI&Mj@wk7Zj8B@E;jjcnzxq(1 zV7t&S7~|P8+I3ckYAlQJu&z&_O`RQLT^V}5D24f1_hzK7N_@m*($14Y3>(XfcEgwQ zs}kz>x++IW@82wDq>_xmX{RvZjTQ(|&I2)ASpBmPcvM88uf%Nv= z9}pAIeS=g76Zt;I^;$GY1sb%M2u((4@6vnh(PfKYf9Ek(VK0 zKQZ}4pClXegu_?l>16pX-D+X+OKvWMr`)6MJeFDg?$v}6xnZZ@ij5Zz`7p%Ch?p=qS?tJN=!{_e^piD>iWTs;EZ3IFJ2>+}eEkf&{7w_~legxFCwb^aeice^~Rt=15AZ zY(4C39b{+MP*BM1=m29W{&OkL!5*?yzM2^b-zm_P4e@fQ{$lza87@8B^i;Q+CWbXl zi!|pvKq|iPGI(usc4A-!NxPdR~F+>?^k|F-ZffX29Js6iY*04h%n&m`jvI7cRafd zw=G_SFIyiwtu7w*FLuiY)kS=@aj6{SuZe^Ev-H7;1e$>Ib6NO4SkUN;phUjv`nPr1 z04geHVu>-Cok2NG_an1~V$`)MgE%KbyoK4~*^BuSW~4`@3oB zc|tV^G*I-NxK`1pJI;AgEgLhtrR?|{Gs5XdNvP1gz4{v`xJeTpcG}Y~8!F!jzbbAS z;I5W^$LFyZHC$!~M%}OUf$c|7XU~4?xr+UWN;KF*26Zd)DG@MdZq2D$C8Hjs^7)c2 z>mx_`x}s(p+DKOc=&HM# zezf`dCB$w$m>aFhYUlYUQtK#Ft;*KpsY5sepozqR!41^4O&p4y%$SKDqKoZuHFRvR ziaZTtkC)Ytk|UwWB+bZ{>5*0xQ-W0s84?R>%ztMk`y#lXlUCJ(Fa9$b@j z&@dR1m5^BQ!Z|f#pdPl81@vIfB=ts`%i81Z$miOEA>rEEh%KSkKviy$1;QPI+9_q- z(pqBep8L~jUaME?3`Bm&36LjmEyQIx!NQ8*LUu1=o6n(A|TL|syngnW&7 zAL+S$x+*lO-8vgFrxpLrQA!m$<|a-@*CgrtyepH?x^Pc7(|O~trHR1^Q(KxgCWt-S zzZ>tiaz#Wy*!Nm>m&XOJc-ICK4%2&{;KRP?+qWt;3+<1aU>Pqv4ScB81gY-jQ(KmF zS*rRlPk;rG9bs5Lzjv>;K4PPiXxJ<`UCp=8ApiNHnkG%Y{!WLBcF&Il!_yOtW%u7} zjx)*gXlDeBCf#!Xa;eT|wDwvLpaFI0ymMwbW3*Rr*uNc3l$)g?dbng)U1P5c#k|P= z=*w(+?J`K^q8&Xz3+U~N_I;`oceI&j0iGFUf3gC%)A%X`E%u!%5aa~LDLsL}DSg$V zTHs2PJKDAg-?{I0$fc%eiQtI9bo!QvnYJf*zIIX+E*U_?xyDXN?*tScSTJ#|)ponA zJf!oU%Dvj9Dp1%6F}ZquHw zISxfO-;obmbtfFFCz!lLlPe=&z54tH`s)u%jqB99dRg&q@?l-qR?rp0q;16=*Oj(l zzA4+O81HgyFR6ylH7tEiXgA6V zQwB|n^?YhUNakOwDQ+*J=FZi_8t0@SLA$k+6DOpt80M-^QIX364)L9_s0ECN*P%qt zeCCG=Uq%T%Lb5Zy1O`M@db9M^YT@$MNR-130~e>p3J=Oy_0he+pV68 zWCqa?rk`T?H1Lx^@jb8lb{x5F7KCBY6AQ8QKsg3>^D~i8LvscGgEhSU9N6#UlW0}F$d(Ad73I4%#_W?Ym z^kwT}tNhE@)0gAh9W?^jpY~nCTJvvH%(mf)H7DO&cT3^Q*UzRh=Ggku*VD}LD9VaD zrT5=E!d>Kj(Lbm)rx1IeF-LFxN5|LZ4H-{!77SYG%W4JJ+p0fT9q0k^Szl7QGnF;p zXhdJ?kGdSmPv0@eRSYF3%<>c#^`y*7=Gp_IzS8$|3_?AXqLn$~SCVuZgHxxD&P*mIei!}nyTRA{* zcgl?BWH~>Sw@t$FEa)H5wq&SN9*62AV_KHSss++*5Qos}yYObG=sJy};%H6P?EO%o ziG5lLIRm1v`Bcdg-((E)@}vVqVO?>K&@K#}`1vFy=+YVk{X!_oTc$8y0P05;(l4sl z46cmK&DJv**!U%E@*`$pW?!4vDlTbi_;8q-(44Rw`+QI&K0pCI))Eo(zbqR6Z7ics&HJW}E`O%I`I@(s({ z+Yu~m7v^YWuxyew1)bbLgY5!ZId@I*%*eG?<*uh}FKYHa5yGA{guOiG; z?LR;%zxER#;YAStUFH1w{cx=xw5`AaJl05M1?=QymNc0h3SjVsA!-g&LwQ6Ys7Y2F z&OD5JCWmMG8DLl&;o(JQcFwsMq5Rx_+dR;d*3U;N#o{dMK^_;1YvVg*r;DLZ+0hDC zx?kO;b8Mwu-j;8*+Q}ZOSak_hsb!f(eCJRA`%c!U=;<$Rt1wc^D{9~c;kSXwB^q8O zPo6{VVwckA69u=_&`|~(zfQ5D@ zNa}d}u71x!1z_!|HLS+sP}?K5H~SA!W@EKj8mNkJRbVG%qJIA+MBj+6RVg}RIy3X= znFFV<0Z{OCc#syUZ|RoM{=yXcez=aUZz^#8h1EFx4*y(jn;{sB(wCp;Xe#?k*4;0I zu27oLCE@uYl0fZ@7c?_W=~bxMt8fW z;cP^WnNhvwWyjVn`dF>1XVyCPIqNf>hM1pwOO#nZEbKtw#N`3lOg_TiPY))m6g*nL z-I$k-q8f8Z)^Pz(@Rzx9@1sGiCGm>LiD+&bj zNo&vR%W_f#PMC-_nu$s;vw~JI#F5gpmAGp!Yb4WD24zJK6dI1eTnPR38tu1SfSf{q zX+W+X&*B4;8Z7#)nky247%Q2gA=^fk=o$zfNEY0}VT4;X^(P`_I$8+@>jmljQ-n97 zN!m_kxzidFM4nmaoBZzE!$L4#evqW8<*`Uu)bf(B=?6fIO4x1{$X+{MTuWZgOr9wu z^ug;!(Bh3YfN&ZG+-q1k8rvhwBXSa@2V>efGiMqO9N0(lKGJFbUP1_VED- z)3wDe_c2B6pI?jD>ZLdwIQPG?>z_x37a1=ai2GZgJ87>~>EX@kW(#MnW0QNWI@=Me z;@1Yvg{Rd7dFz!mP4oiAl5XjyKeRaaHIM@4MRxooApH8fqSud8W=GDz2=yNE9N~D8 zf_#+wWgyL|V7~FTZ*GDBKe}Q1TU=nAou-WqU0CvO_7=u)muH=ge0G~O#9g-2brw5> z{CDU~(joILQ#iXCFdYhZ;qYX*{or`n*yJr!OO1uf2)x0t4`+ucwGW=$?orLEgra4W z>d!pm#&Ni}s%YWesW)@^@SFxO8}aHf)#Me2;%u@(vq+Xz_519%nOyl-;Q$Sr)yX{lgc0fHiVgiN6T8@N#^{29|o=+I%sb zVPXOu3jUllKE!w}Ri~4qT0hYmCb#z8OSC>HZmK;=m@!rGu{G3jB}?phYrwy8fX&Km zFP(35xH!|fpl?76C9EVwQh6`&xz-t+>;>uvuAxaL8~Q|#NcRFkth4Ft4lij4&C=Fr zlvjS#02cSboYOU9Jki0(J9})mqf60#j*OEST5>q$>w64c;tLJe4hBJP^h2VM2PPl` zqt$UajZ>>RrO3~}`-JOg5qeC$S*0X1mNO4Yx0{Vvybkb_pr=rZaQOQbolsNT2ViHJ zafP{yjfWEV+Rs&=ofeb<%n9$R1{i9*H#~ip9(x>pTrwOMr8V&uK7L#em{UNYzz~%8 zoOaX?tA**G8N3NFnefUM~Im9(HDyO#hf@R_=9dYAdUA9fA!S=k!KU$dii4HuZk;W zcl7iTU;Or8ez7?dUTgObWip~0?kKd=`yraE$2ua9tNxBcUPc2d7LZ@lM)J--y^Po! zGC{<|zX}*d9pvAu{+eI6Uhv8k3QU~jgf&*NZ*$=eZq3yT6ga@R*@~)FN@g`=;%4oX z;%fs>$TX+CktfUYzx$A>vw((8)_d+4h0q}*jt#V3)m+fK$!F- zqO^c8*O#45$A%e#kBZ4#uTwqF*KS#%yDvi@3LkpeJgP2c;u-FUnBBCkV6z|6#pN(b z>)n=@iauuGD04=mLdwRmuJ0S&P>*u)AE0AMiQ2qHGl)r9w2|BxBlY`>k*R<=hL_5Oy+G-HzIaYbHjyYj)_ExY(+3n~wtKGQwIwP%cO|_}etSEAw;z0s(Z`NX zHkpV#6y4h~r2FcyN>4U^O;{?OFPMB(Ej(5I+~=0DQ8sf;uY%zfX5rap;az0#f@H;P zePz~w8zLr>==5gf0t>ATB-=)$GUa?)duu4y;yVg zWWZWUYQPS=GEl^$D{m!O(pqVqKNmT<-8r3=NsWZXPX^64Ls_S6_JrvxD+JFULmgT2 zl*!oO_`&MxHN*Hl?tZ^)McJD)0On@M0I+!5@n{8CMYz59$x+7FTlrysCecoReA9jp zvmQM_1Xv2QZLn$7g(5h-wn=%(R=$!hA7wfWgp!x`P&>+=uB%K;0V{ zLuN!AE01%Os@gwuPoHT8Mp}(NGTghsKM*o0v=|do@zwJL#=kplOlBYUor`4fhdWgp zrF?*XLDl-sSiwl0=OOKg(s=zfy)ggh21boL3`OHKsKdOW5b@hVr`F$O%Qxmo-tGo# zd%~hk>?GlCHJKYzsy-!c(RHR9DOPjs1naMxg}qNzTLjp{uG``lM%s1-s8n(9+@&^@ zhiUG_gT}e^-ZNC_v7Wz#XYUJJe?TddF&PLp(wT7-=#_LMGYla6je+ZX#}1)?hnRdb z>}7arPqCHpuuu1UWVxm4MeMjq#RYid`kxfc)vWFRw8cfA95^DFu_5+RRY|e^i!vV< z)Sz_12tH({7JouU2fbV-0NEOx$aUy|b8N{81BFzG$5yk(0N=+6)_oo&m6$*Ub(Jzt z=dRnV&ZElARNmPk2F4Y!0gCgSQ76)DF!rq_M@E0H4{G_Y^w(LP!=e0KouZm6OX)iK z0^9wyH&X|+yxl)A`sf`V1<>N_PHMC$oZwLj!6o-=uX_dZ8I}feA-NCpTcnI>J#aCIr|!LH!p_s$8C<}f&I3+v9b5ix8n6p76R{+n>* zPGkbIqik}kAQkfXElT93Df*}c1+R{QRW`NB4Do$~l1j zq3L%%dKRHeSp>el`y;?!7w*lDZ`#Nw)HdixXh`gxTXY+`9alK_QARg?QWMeNTDeSM z1&l!wMF|TQ6`OM^U2dlP!xCU0hwPxAn^-8)L)&Fr!}k-VGrPWGsinTh*)CmD-B>}F z(WK_>`NX_Zm!W-;_ULL-{5pMqH=#(o~q;j7t2$9;J+13?$s&TKM#P)z4WAZrGtBk(O{EBtC+2@3OQT8tj zy^qotvAc{O8kT+Pjrmp<0^&|qz><(yE`vP&G++~hqi=JLjj95`P}8dbME4DRTbETZ zNWtu?W2U}rGfkJh$V+^Jh4M(A%I-Bk1+|PlK*iz_=Su^;G!b@j5kxi7oL1ij$nY}Z zNF^;wUJRhq`8LIYelS!9_dJRtvd>Uc^lXH{=MD!I+ImUzgA)!a@d4h`erKb3e`x0~ zt)pVk^n`r?cTLnY)Pa4sGbeobeW#RvBmXhm`b6@=+DDUz8h=+61ltl&B*q2&NbNcams zQ@HJr6%>a{b1?IbREFD+ynWf#^2%dmyuL7+fCY z4~SZlXM>&aF`I6uC&x2!pT|X(V0L;I`4|c~%3laS@#2hvC%pL0UQ8(s_2GOmRLZZ) z)z4k(wy<$>hYsMZDp7^H$QDRyyCz5B#kn1~l-lrDwjUQt`YIF+(UBdu0)2b)QOBq0 z=m>DpTa+GNjIU73A}p@BN!L8RHkrsEAd(7&^IE9Wj-Orxl6v}$7)#$$pMF;=yIIO< z{u|tVuzBwQaAx7T=Fb7nEZy0k&Me~rX2^wWq;}0_K7~d#2^5!?XF)##20?)91roO}{rC{M z%OOG`>;A3~#IPZC&jH1R(8pf>Ix^Wr0^x4C9;)U5KLw<^REvMnR!lz=q zLxBUcB8VPQ7q6p_G6CXYZYnX09zhtA&R6X>#lD@U$kSPF-H2yDk#O-#mNuwZ9C0|g zh$P@eNHY1h=;=0}E$sa4l(9U!qw>v>-fs17IF8Ny7-h(8Zv0(r(d^YL1oNLJwdl$7 z`yp~aCm?_0*Xd{B>i`5ixxO@cmh8=D_Cn3RblWN&6C9BZj>n;H>)Cp56RrXju*Epw z`&jZjS*mMo)seNUI`@Y-pN4%n>n+tN8zmfwJ)#^1n|OwedXGlaKac&w+UQ6-#M8_t zp4wL_UO^X@ySb`P1s$o?^Uz!t4_&T2wN=XVgZ&0MV#*~FHCA|R;i?*GpuYyZ^6F{@Rre#xwGTH#uF{D^_^Wm#kNakM}Um-Ww#nAp2 zU*%vA0-e*}>GVBLA4z6TUe*9UuSxprWpflB$5~_9M}sui%e>f2NgjWH@#l-Rs&1x@ zzjmBj$nm8%tvK_00fCR@92OPCI+8yIijInoCMLHY zSuvjX?L@x4&a9^xmdAEJBJ_J?Z1nO80=+&`9q#Ai*nC9ka-Xl@ZrUHJB(_~XRq9eX z4P`$%4&EWPDSG*AY!FX2Rdzf$OOF zz3y4vYGmyGN#ODX_r~t(=Z%s7q@-8G$I~rCbR9|L)%EG-@(Gl9*0_uCq2 zdQ!{r9BO&#Ep>7E@M+u@P0wIwh>WlJtOaB{*_wY_+u;)lCmFUZo;E0%H7t2JJeC@z zLv$1^EE<|z`wGhPRW91REq8l6wvaB28=*|EQu~mSeL3|1LP4 znkYr3iAsl{q5>kI;LwY7DFNvO5>P1t=|zwl=^_xMB=n&49_f%!1Ofp<=p}>%o}1Y- zd%O2J=RN0oKSjQnyR59W{%idTzFl-sDFYxnXl6AnL}ghO5HEed&_~{{yMK^%@ZX2d zTl1GMRVO8<9F!spA1XO&Di!*qBO4wQ=AOdoKvjei_yX#&Ju(?w^eB^l?< zG=T>d&QXd-f(H+OFz?1SwBUzipN7gWS5b8G)N_X=un)p(6vHCevl-+vB$0u`}~Z#pkvd%juii6&Rn z4LR5YHcSgNtp_QgLGkWO@uCfb#2Kh0I6) zv(`GGeyOzp32!ayUC@sgGj`lNhnd3(pbv4m397w_!M&!<+fV5H$%)(cpdl@LNPRYD zGu8QiYtRu}g`FGAT*4F9=tY1(8vJdJbWh!$&6T+?{@9=tGZ*R4{Apnc(4gWNS3a{> zrHy!3lwT#u*8?i6*;0{$cSBpwH(S1s(|I4q*sS&tpssiWV5-<`@r$+Ucq@e(!Sfn6 zdObZ)5BObc$`#Gejaw-U^WNeCEB%B>ihmEeGkxZNq=bCqI!dB|7*oPvQIBb?^~hUa z7puPZIRBL>3k*R;Vl(4E7TI4GNEQ~ydnr#HxB7lRuKbYb=sZn|wmu96K=%c_pI)g+ z0|<^V!6Tx+egNOv!@`vl46uMfyumTJWnvU>vnIItHzRGl6thBkRY({g=KLzs-sM}f zN_4fQ>P*O0!LL;g4}iwY>hkm35q3TaKQ@=bV;ACM`7`(Mz=KJB4Pp94+ytpi?cPz(dQR)-Y}X2bGqpE z%qyU@BUYLd*DZFM0hu#%cCES>#!^f zjRUR*kh9mnPy#-;wuV@+Rs(O?3MREn3Y9(T4J34^zJi{&6O_N!3_0oMHvTl1Z9KUv zVUamPk#I}!zt0{2&aHgA4S-J$4LcCqGqy=3Bv-milAq!Dul$#2Zv5Z;M8G~Ja$oQ4 zUwpqJ5x)kNel=2DIpl18@eUZ! z9WO3eg#S}6Uw_<6K4D8l|hndIj}IYo698vmEhG?;HA3C8DL- zcR;2uVn)4%q*PvoU44@IG4^_f6*YW1k9ap}pF=L<;0_Gp^MqKx=fAMDd765a`X2L9 zAxB)0G3_yq6uu56>@K#ia)?PtRQbFLIZEmUdwF_|GT)(&!&tOZ5!r;Vdhv3&=?y^xB!!{P=J89_z4IGZiEKHy#uGWrTz7!EI6im zi3A|#ANw*8Hsn?8!z|x_9GHt_N#njFcMZju0lutZm;BUDZgw2k^C~vAw^4});BV2@ z--pb*Lm$VfJz!)T`q-7ge^*WBf`!o+rT0Qjdd6AxJ^p4X$#Z`+=j9_aI#qg)kRu+K zyU~AyC1zAOhwM8WA>79&kXxwl(O3rQl_ldmE)$A;}329^OPJ1qWBBI zzTz?iG!9qx#He0>n_K)2$0M@<8UN+VHYXR-wlba}U-T!X_qtp*NxpVOwqE4>(QK)w zpL|}n0}9aJo&EQWsQWwhT7YjE*q#29LFrR_pqdSNdYQf832@R$edbfL{K~WYBzWzk z1tv2Tp98)u;4USbRrczsR@`K-J5{#XR%?EeKIN}|Fn+M6Lp^9k=xp+5mH}Ku0n22; zvk`fW5qB(%9>xW#fp27pp6WGI?r`8_Gbxq>ku8v0EDIAVn6+I*cbp>Ml-2%chee1&3d2537HF05y!TKB4{5lAP_T)ZuNg}~EMX2X!abd_bE*YVa$c$W1M?5hDU7%hsttdE3>1nxFKew$B<)5e@ zgq*9d3Ato(;+OjJZ58k-!rQBYu?R%J5rD0^o4Hg?8LGOo|L2Z%wzGU}ep*)1Z@;!K zD?Ryd_W+y!%{|}_>HnX5K+2ufilkrN0}Q37CBwaJt*>VF8_5qZSZ*P*Mm_(iicr>} zSNr`TpF%nN4pA**SHB6v`xvT>)(IT>(9Y*yvJ;Vek(`Nbo)g8&y^U{|sgcBGG1#AZ z;xB#as5ZR+*#T+ONU7OOjXY-lxArissRXd)$sk5pr%O(UY5?vkR8nz2;D#r`mT*Y= z^Ths~Y4)mHU2*_yQo=MMF&~{Cn6{~ZpPJ%>(Me|57(utDP{;4WCQtWq|8N!f{$Qp@ zR2SlRUS@7V6AWko!aBqYpzTiJ#rfwG`Jz1i2J5oT?LZpx)0F;`{$yu4v{v_9l5C?>`--_i9dhG1OBEzT$jyEjh_~i*jKJ~q z_vu`2{C1TClDWTFQJ14QGg_M>;NFS_uL)sba5Tu z-mPvG3I;T&pqEPbub0XV21@b*jHO?Mr~;q9A-x}IseSiPUR^{b1I^_5NqYc{yWg^2 z28@JVfPMJyiK)v0r>WGqGI)<0-Y3#jG@~-Vd-q zgvf>eG$t@pJy?{u0?{b3*qi%45pHEa-89|Brm-m$f{=X$A2@f_y`5dC(vOZ36|eco4_@PoH4X3z)E*W-I)12M_u0jW^7WSMm?w)sBc z=J%{beXpv0xr3T-CVxPyf7E|w<~v?!VIJrI3hqt&Oc{R^-q$=wD+$C*!XG(O9pk4S zF1=b$#v)3o9=jUuRVA4r6*wUT_jlyA<%F*L==9<`-Q0FJJ!g~L;xqa`sez0J@;RI$ml=Ii2ig`r7z&30^suFX95&#Y8YeEL9IRuD7EoD}w@ zrR63uR3p-#gA&NRTf=(e>#x-9Z|Fn$vS;rNo{I$zB#?ig5z8IA1KQ~u6Z^8FmWfj6 z%A#zk(VPe`(}F*#K!?_g?ELbj3)P20WjZQP&dH|nn5C~^T57)Ts)BF4CEw;I;yx^o z<%T*LI>+sa0XxEXF(%PaD?lV!AosPbe~P(9s^IL14{a&ru4f`TAYcp$)|_2Bz}B0IEFBb08<-*bAYkb*IT;=wZUy#pf+Wer`1%9U-7j z2<9zHOuC;rDfNKvT!0``rdxLZCI~HD3k3*5z!cPLKyResvML}i_Wp9VGUkvT1TOfC z9^_Q=CGgp8Aym6WcI+2W`dM6Nh}pIbB8nXbyl+4^MQC%Gmln1B>ihiWo#dy8zPoDk z>Vl}|m}}(#@`Gnwfk$|Ac(>RRw~e_80(*EGIDa^u^5B8K^g@;$t?%Njm$t)~fY}1} zWOBpiRjCwK6(}rrh-I(tOPKO!u}~&U<;lbaL?>5v4fO-??lJ$(yMMH5O`egZE2dbk z-`X>SlR~<05;t?nM#qRl32Ar0vPyd`!CFpjki&P+SJ6%MmFr2SgTVGrt$NmCh8J5} zfdD|xm<7KLsIytI)0l;MKTN0kA_<%)Ednq8yU?@#p)`o*%>rS@LlcG8_kf84QxuEI zoERAY#GdT|E+@rnEG9GgqfKj28`bJ=C_rE&tHf=oAcf@1C1Nxt9nxY~t`+aLIaNE& z!}NfRF!Al-T|w0R-c6;4nsGM!!oDjT4l1rW45rxMPT1g_uw5;6ne2w%^fy%AQ>*V# zoL&`Uj*zFE=q3xhtS`8H+^r)%&+m!Wp7W8oVtm1z8W{HXlED-znpZp zmlIBpMu4|c#IG$pZF3abfXGB17|rmfibXX-AzbNVS`G4MRI`Sq1B#}8I_;(ceY5PV z0)S(>a8|R;?ezSBHGE&}psseiD9lnR4sqGUZaJiB#NcDI)+vB5WVhMTE$4^sA5h`8 zXAlv2<1~9MV@f{X3bDCg3=*CcLlGVV$+}XYMU~1P@cKd!?uR%$>ICs?g z4f(xUV%lTdaSOY4jKV6x^Glgk6iBLQ#YF<&G~S`Nh>ZkE?4mt0dj@S$@*5@@r>VWg z0_!tA-zQq32yb)o=9evRw;V)?L~Mm(7{PeH)EbE`9Lp`nurLw}YVjLf7^y91Dz}Hg znfAOwX-2{J^gBHrmf7@$DMC~L@v@TC>rC3V=WYCts$}&dUQS|&&O#zYsy#_|v_MPt zj%5cYLw;RJ#Zv(XJ1F^lvLH@o$+mW1{KZgJQ2&C!x) zKUfrRoQNa3kI%na#&*;BQKAIpO@7(d#|xLCZ7sIcOY5ex>?c0ebguMq{l;yYM01}D zh}B5BHm^z5UY0HqFXeRgG`%JB6!V!%I68OgLgNqUCM5S>my<#Pq+!E|P)7y1IlMP9 zcYW2BFaBbm)o3QpU+Z1C*j@(-tG~y-wg~weKv7La8AvC+m*r&wMVD>?6|Gtp#Jz{dSG5_d_Vd_=;md_rz1gE@$3|epDw~ z22O)u!?ZS=sUIdkO1ptFc|0YGb18q+%KA#3fHCiVtgy^?JvAz}SIO+(tJ%@glDzcX zL5H-u`BTm@;O9AOJ%0Jn*3P7@Be!*h7QvV;NTL`pleZ7i_)$>YOgdGD3r;AAkY22T z2{iL!x!29bVT!GhWM6JLXn7`pM=7&0UAlV6JIuw4!rfXQZXQ6ld5ZFwZMkG|ZxXk! zPQ18xW$|VTjHVyQj@!@RvFyb~>^^hLsdK_|?rMw)%1ScW87T7T^tcxa|9*y6xF{qE zXyDW{oq0(U_PuJfq$Ln0!8EB|D16D62UaYAx|9mWb+84V74OI`9=6IU*{HpcP}5@E zJZ7~wn0}4LbktTP?T-m#rTfR+PL^Mdf;@^6qSsouX>(SDnLC@#-@z0uojNMZ1=+pF zJ>7EgA*@TSReuAQ>s=J}5&nnb+>g;hg^Ks$oV&cNcjkVJdRR20x!tu<@S&H;h`$Mf zrL~gwPP%|$dq649|wd6g7L zm9L?u%Ce+adX(+FB*SlrM#;sCYU3M?rf{>J_cy2II`~{)3C~7vsgz@5am)1=Ft7z} z%074NWY|4>;plFH$>YcY!Ij*lJmwhnVv!hqgB% zEFOHQM#9NblY^EVp0;>q!}pmFrRG0G&K9geF)lb(K`(2vw@%ps^Wr@l!1y>H49F#(~^Zwg!yUDkQ+0mP+ z#AYF>@<`)am*<1$uAgB~fq2%! zp^!c%JKbOTD6Kh9Z<0_rE@V*kK98u{?N?%KdeNApSf z>PI*d?f%6p`Q2I2!9l>_580C*#9`{qZlgEMFU30MnvI(C zInYWNf{d$jpUdx#9a*Z9c8(qx@)x_$6ZCO4O@-ISUx~U9plbRCs&QjQ+`i3p-OrlU zK=|B52jLRs#)>ya(g76qz8a~Gs~x}JbCw(B@_3Y4=?Q5#VB_wsdXwGWVNpg^vzfJ3 zm(dS3hq3x-=?L~p;iwyhze(bf4s|2#vv5R8a!KWf18z%^mJtcG=wIE&w>Ri`a1*7oEOVvYyX^Ko* z>{^XGm`%L-w$`a^sVal!l01;x7tnpfzR6jo>5<%l-I$bDG==MJA|;OEu7*Yv(++)> z>rSNps!=s%d~`~o0Lt7&ydt^)kGCuzY+`Qn9Ps*Q?hkY;;I+#~M@laCZlS6_@d~^qnP1;VTvflX z8yEa?*a1X} zM7ud?EwbjJVhU82fH5C@OP$m=JVc)ql(*YOTF(EFeUR3YH@~)6ml|4#1b!oMT!k@6 zQ4yzCq)cp~ewr=UG(pHGDAAUBGsITSyi6b2&4J&|L&jlrt!JQLL@QnT8MeHmS z1nr%ED#`Jt-xV!wKp7N9b}%~)j1ZYt>UK<>(dAO0*_pAcZz)Tna?t~5dZ3K8!kMk2 z&1bh>5HFIaGj-;U6s8QIRkNjHA`omE@+iq{v=W^T^aC>ce|T5p^2x)UGe4kyFFZYk zV{jc*f&JKnnjWnPzq*SjcgIp=3$#uL^!#2@5j{Wn-BZuN@cIrCvKGo@)E<0 zfXqwtH$44~WMW!4f%JAA1|uDolv|9TJIlw1&?vj&87|Lzx~uEyR^7k*w+C;Zm3p#^ z96WCJER&n2wZ+VLqBNQEL&&r@Vl9Jgm%7;tul0t7%haADm$MimqgZa_{@$BYQX%W- z>X*0_rYO(jvCqn2A!2@_w5qh2H^De#%V+pa(7fdwCf8%$^5yd#zQwzsoCv*@*{4<> zimo3?d7troH=XAtW=xSJGYx;kv})M0K9*1R5_fSz@7A}s-31A)B~C&f+hcL0jyp)_ zpxLKN-w}iYs)G9$;c&7s)UcTA8vJsxq0Pw?(TQ9jmpUnD3HGYQ0&i55L?liD>Ao3Z zszo&sSg%Bi%-2!_oT zDW+GfT_BVbk0XkY=nCFyQ4@Ymq+kqPLSV2z?bO{DggFFO*`k5s8C z=}-oYJha|eoQWQItj+oLN=_|j``OwnLMz3DjqECH;)5Pxhs~_C+S4~&^j$30x9Ps31^ZyhEwj{+4&BczS|NEm2MiI*Ih@zXlW+Hw0` zKuEQ8+2;XrzU)9B61SRHf8f=)#NrHZUQ-dvCqHyLZ@08Cj$=0;%`k(C>?%Drtr+CR zryL&#osN<_QMJ&Hbo6<9(W5A+`~4$}B0b(j_V79fQ)ni(VAx|#zdPTQ3n$Ly!2Ow1 z8wdJa5+%hGdPOWZ*$?fP0po~ioEuGdsGE>XF=`|2{h?9YcW+C$=5H(j@-fF|*27de ztPIp8hr7pX6m^b#CZQ~EqslDExpcsG)Y7)$hqDv6uRY5UHxejpB-cdxh(5QAO@-sT9s} zU3}-D!zEZDk=3L)%1sUoQ&<^+wKs+h9>rIK5|!ILP2k4)OMNjlNcwrY2~n1}cI?$C z-^I4wGj%4ze0iOBb-T(=TiLrWa&1L$dS(ZTcAajocss*MeKKQ!uW0>ROyp{7+80*P z@kVE8Vbvv^;MuloM{2Zj4n;H;Z_HCa>sz0|#pKgTMNY)-mPsFoLllu#llDuQKCIUB zaG=c$?r*AA1!u}ukPLxkRZrQi6!La|*7PtR0Om3EUC2p%u;8_^T)Tx(w`RVNcc|cT zGWPW*8CF8cy52I0I}GMZtwQ~e&Z>~mV)MMQ+>)LA#||t9O89>5v++%PIX@xmLsI8M-B`P zN1gL~;^_)`Uv-nBXP;-eB!}kzBnB~E@xtz`|IskdTKI{{)1>nQ)h%mCd>+^hzAjq1 z810$PGhgh`J@WNmLA?DBt;#9DWI2v-a->!Z;T^`zj{+;*uzzV9KhvlD9nx}< zqoC^@4=ohH{S`gx8@(+uXnQ~C_0S_Z-%{^$`!g%_v|D=t{v2~!N@ujR{Mp#^@}|oA zXTBPz2gWrkl&gZ(0aL?q6KXRy_8`PE#np)JBk^o+YOqsd_5G;Y!-|+08!&pJnl&8skuo9wbe+7=&CUg*8OPdHy? zzhI17$tgYu54n&-WI#edC}cA+Y`t=^0rtM+2SS$H)JSV6uHR*V$G6%@R$Jn(RnWF^ zOdM*vAL{13@hI-Ypq!|aqJLc#E{?6P8Y2jo6|qy)Eskt0Gsiyw=|z#yh3$5lc||*} zugJ|(!4#XVPZ7u+*WYAs)F2&3$6OMbi+Oc8B`fUen-dhVqvGv?^7bOLn~OfhY3NB0 zlTO^sz>vaBw$E$Ksp_UG^;u3u5zRLjuX?Vr>frgcL#p8bIY zqMAJ$FMT|1-KqqMWoRKSvb{$^-WVtPwW-}$F$ADa7(e$Zp~X87>tbOP*>Y~2*N22- z0|HnQUh$~ve)TOmUBpo{NqJPeZ$m|QWtiW`>g4_6t@`5q>yv9dqtlR^R;BrrjJ>FA zbh**M+$T-(>A?r*O>;@j?rPW7z$v@^_v8m=knndK9qPt~9Z$3Az+m`^JY!yGo;fBS z8wFyVq>oRYD)XlmyJkjEpi+^B7mIHvHxLCkN0Wvc6T4Z zftkTC^|1L8AjuUUpI(sOM2(BU*s~^fLRV~){ZbzKW>oj|>y(GOmi;Y5gjXm^p+)4D z@U%{W(jC}41rlX!L|0B7Xa#cIqNLd43{SL154voH4wIrn&R$Zv2@f&DAGvYQGqfL5 zUHU+#&b4OLMPnfX^Dg|$qKG)(XXfa;G z@fH)r$VX-^{YEBCvNa+#OkG$1r0eU{^vD&eOu$poc%%$Zo<6SKYjg)a4ddWlW6zodiidpq} z41})fGkM9&uEt$a;hD>$^^`9ulT|$Xl+$J>C+quZa7(Qyir-MSl)6Zamxzn4T2v3>RO*nkL z>hn{%9sAhnqK(7WwOm6;7%@M(J$IU6{f4#ppSZ)b%yxNFZ{(L>@}EvxBZ@D@44_lm zwF5kOqiT3g^#}{rJja!d4bqi1-=nu>Vl+;r#QwYgN@B7I#n%289?b?U>{P%UG_b8$}n)@D}H z>x-MtMco%!Tx)N7_!(i|HvPW)6mb`X{Cdm)&UJ3~UWck{N?23TqqXbA$-SS#1UHv^ z$l1IGQRJ}2kB(3i79m|EUme(@ddd^!eqc`6h7qd%bePf7k|gL=f~}K z@xjR{O-3j7I9-e zkz%u5ojF8cDdZlhXW2Mx*$R<&BH$eyV2^2SDT*AsC%k6Y%q&m)WrTz8vY+Wa@2b7s zJ1LA6-kWFOtXG6<32=J$tj!5>Mk&J6jFV`6yE-E(HL0e>nDcS-jkK(l{5H;|Em3tT z7;jC<%EB=W${!!TBC%dFmA9Z|Tp{bU6;KTyYSNLfcmj3W-{P`viR=-L+Lf00w~6m> z60g^8-P2C#bg^ombKZOKMldB92gcBQE%hWY)zqYAx2~4V+ForytwbScWQ| z^+>U@wB%^GeHiEIxY}7&@Rbi~UZLK(&vfH(fIZ2fcsSs55JVa-h8O4+2k%VyikD93 zvbI6??rG!wo?>hx;*#O-%C^;(nwxLB>Ac}h7(nY&5DX@5LQnMSf&4LZ%Zvw}m)APw zYepsC+FM5i&aSCUQ8vo}9fAc{`oeSQgnI@^=_cssMwTovK)x0U?$Gu__jaOFh5j7$ zT(`V(R(#-qYT45vYw7oq*W#yz`6oUVr)5X9hLW38o&Lqq6Q>>3MgD!Rx!DZluutJz z;tpzHy5tI`nQvua$SXWGk@jMkw`QHMDR4!BdTVd5SBp2iMe$XLfL_BMk%ola^qa?w z+R{!cJ!);3Sx~}1bvg6&h%`TH(6RymlJD=WFz})1y}b12{HQwGdMB_l!ail32hisX z?sX~6L&ij`(K(@Ysy_$n>3+%Ip_EJ2Eh0^fKCRyFPbU4CF(L6Ta^Q8FJX7 z$h-~Dmg-@wNoC8e-XFQJVE{->!t;>Wv!1*1En7fmUr4?xF^5@I;i`nvFp%MwiM7` z0JfLZTRbhbuIOE@(5D31+#(tr-^lf=F0<7=PR zUaPj&>ap$BG|3ZnryUY0nNHJTznnkbhD88}4^{h_i-@_4h()R;hiOmjz|d?bpV{Q$ z%}RC4E=0HX{}=(@VymlUKDmB>_~7#XU_DjuzAD&kw?j|W{*D!IEN=0>wEN2y%bI-9 z`FK?$O7<%erk)&@q3p8YA7~lB%bM5n$^6SBQcALn{?r_UkM!kw76eV>WTzJBOg(5{ zhBi1YL-VOR88%zoXt8UjFG65&#rssCfj6w&ejxF>^zdF)xl`SMu>X10;!V@(Y3kMK zWQnuG#E2t3MNK~;meJdx_kSIMZgU*vN5u@ZtjTw;$q#O|iq!(Q!=ymI1NiTzoCvON zkt_DvVN(N-%l;nuMGZ{d$QnkPT+8o{hKb~p2?YMt3K;XT&wKGIXGG%nD9>I)Z?jO+ zQoE$r#j{Z(LanV+1d5#ugnIX3RWon^0S+SRu>HwKg#Y?5A9UM}QgE<+owntFKw2gB z_rG4>RFjbfF$!&1N00yP6UVX2cjrB=*}PUELK5urp0Nag2d!6yGb*N@`z3#uY zUw?9{zH4lfxN@NBO<6Uk&^EAM>v2Kui<25oHPol7*OU*L06jAoN9yKhK}e-1h?7Xn z#(d+_3U+0jH@q%vf@s-Nfu;09!zJ8q2O~E=ZnTukK4$)$wePHx#F7_Iys?!-_(Dp0 z4LmV`S8>+VmyB9n?-WRLX85p6)B{uSKzdSm2RIIqP3O5WHrDb?dqG zAE%+eCZ7NKam)G)Z5F$qul|ZHGbI}5w;qQG1T+uG1fj6Rf%=p&&#lp#6-+0pD6|;1 zLZW6BCMBqX4;ID`o-U;w+1|dSM6g_~vg^QVz@Txv(cZ|$vcn6$6^rxR-$1~fp);H@ z1G!%IY{5Jg+{R5NdB?K59?_-V!lMgd@_^YfOPewGjG;mJrs*PK2jRIQFF6~ z;Gz>Z9$5q?B4H-}z{cQmB@RelQ4&mN!1C}C`qc^BP@e|Jlx(SZgC_ z2G0M17~!{hoXxSZuo1XGkJuKsU-d7Weq-U6(wx&yTdNz}M;9Ek4)v z#S-~>Bk$^B*;vZEA@6=k_y4??UmhuNyD!av=8aPgy!UQUdBd%6tF^2L_^ZG2;O}JF zJ zwHW&=bb|Qu!KwR`XeDOnA{3!f?xa`Y+&U=lRG_SjDZ?un)qHG7@{HQcV z-CE4}pLLSy45ZS+q#jd}jdrFt*0beqrfB=e4&;X1#k-&JvL{KaR*ZCKdAiH6Y=C1Aja4*>VL?%qvJ2Qh{<$K66GF-_9xK%HNiWad5aIGLxF9;g+C z2*l25HM+W-(@f}mT^bEgW;VRflo|yfY5~Ac>o>C-N_(ID&+uZOv_k#ljgz_?dLw+r zc(5HTI0LK^d`QT$RUVDu8`*@0Y~Xq$UOS6zkQPCodf+1q_?C@=;>i4t$r_jQHnyqQ z{5gv!eg%r?wZ^F`#^EwM-jJ8$ zqv4`+NxyW4Z%r)UWJ>{0C_-Y9S1Rhm5N}?p4lt?R+8KdW|MkEwbH>3xi>uhnuNc3q zsN4XM=tB9T%JwOfHD@EIJ6}WimT6rL0$%nr$G$MIM*`>HLzl*@G?G8PxDhD66QmvI z{qA~3A)!)r+}GOHpoBBPu!t~Ux&?VQ8OeIB2`-rr#y~GeasX$91B!FdC@)l~%b$J_ z)V!tu^>IB1Vw2r{0Z0JmXeHtFp+Gx4>R*s|u!|w>>=pR)^gPfa|4xMZiI2%7YXsko zrHxi9aRqViT<&{@pn(_h17$Y?e07Z2Wx?Y$r86)#j#n#ZnG|^ys**?c7SHuPizsqG zK!#VHch=z2wFv>0U&7f+f<}&e`hx0V0$ny>5raB>`n8^9zpcbTc0Ek`~$ zq$gI<6rWmCo2sAcdz+(Z`D#=d2o|J}DpZmmRUa+dEnvr!Ut52l7=3$mQG&&D^gd$5 z_g<-WdVV1=&8y8NF=8c)p-Z;dNGtitrnq#p^xIRo`mqOCToPes+Q22u9r zayS}UR-9V~ts84F!rFLoXRe?XU8nRb{=*pGyQe3UCF?6}Ri?%xJ-7|LD9euQ6P^>D zXZob;x%VBdm3F7*A2Sy**#&q{ac+*Rle0Ld66cim2Y_-X%xl>-<;!H(T4aCOzFe#>ZzL5cEq?~_4FS>=ydh)gUt0*4r? znGkT|nRDCCo_Em~iE3O}=zs0%!ZY;&gA;ZOUsen z8h<)4npAoNj0#s+dKBwv(`AG(Z{23x9Pz;E7LXkr02M`VtF|#=TUTVFGyz5L&-Q=lK^_2g-gZ78`fzVkf}omr7*`a@0>~ zZ1Bjuy;}lEKhulXxP4kCc4YihKcA+PB+jrkk!*1U;-Ez}yB1eX<4Y8ze&`k~#Z&OpnHBAFvg|L5A#sfKhP9_FRc)JW!Q7imGTZ8KLRjXnoL&l@T`uS}j^YmsZlDAV z2xddyfQD4PARO}*^S`(`p3k(4M$vQDTZnFeO8&c)Tj4*EZmm7KNXV!hznoxPISqfeSA#@$ zQxME&dU$6k~o0WFL6}0LQ;x_()KUTO^S?>#fl1s1{6bO`+_7l zKgiy8OHas0;aJ=`^E}^|GmmO3yw$ahy!P*|GS60$GVT#G9y)Ty{ScIz zc@PF!eJ9>3wDH=tR1ht>)%n%KPdW2 zAq0Gtp=(e!H}A&aBK5M-yRMfAwv1rFl!~Upg^$mnIc9Nyy^44}gA=NPhB5&9>aAi; z^CP8%yt*O6=eoG$5Bai*45gJv)9&z)GpD4a_E-~YL3X%`P%p_f$Zb@0H0SqV(6;-N zal<)JsXS97aZ@cM+DQZkqjpi}c3*Ogkat<3TWP`y^@S^YKBiYQpWevDz|ci2-Ib15 zZrg=`=3TMrvuPE@j{Zt*yF=1u9FWvmS1VFVswAwm+t_|95|U0D?lXS3H-jJZ*P&D#&Cty{_1dfhl>J{ zqWYNS%Nb)dcpcI{@3cAajA~Sz+Ims;Hx{5sktb|G&_C3|>Xn59;RX3!v0EsqTzZyue5&2dqJ)?TUk{SyeO1ppy^0GJsE zN>va5eh5A!tYjwSz<(FFi30LthQ?A$5Ig+gwc*GM85*7rMk2}BcTX5CQraZts{m11 zP_uB&S8n)j>1aM#X@9~QKB~0uWxh*j{3`Py4JV}rF11Wq0*r@KCi082>pT6cFy!KR z1lS{L%HQyMn7nXzgUB*7Aufv`NQ%kLWJVojXU~&b?6&2K1LcABoTTs_?>7EIvO5W@ zJ*GSJl^`5HbH@?h^85L*feIY*m9mi^u-ihpV8@6axpT_xAa?h<p^2pS}GT)O$0nHW<$HyRdLuWU2NdHmbg~5!DJS!D~xNiDQ(Q63v@zymWEAo>e!`1 z@t7W6g%bspxt)f*juT`Ev)Oa8DNFLkWk(d!4%Ylvg0_l(NQH%1jlDptf-}uLdT?_m%u(ZidLXm76@q4$$PF(L#-% zja$gu3y)28AtRp?NjFt)IKLuxO{ob6oL(!^(u~7cm67A-)gjVVE&BIBv8l_v3KbXW z?M{5m^Mf;I$%WuHCxZU0bh8EYzR`_>6@X@9m*!eqS^yjN%oHU&-u>vR-{uk93o&gc z)n3tCZAPmTj~lJZELefRTQesq|Leqg z-TX~9T8yf<@57WY>i1wEdQc$(Kw|@FUQVwiWcw=?VO4NtW4M4SS>XK&1=XcwVS{EN-q7 z+pw^>k<~e?@bVDAbhSiubbja`;7yTPTh6*yHAVa7KXRyFJ!6F17lK5SCd-k74U;F# zkDY#JI8^>9939W;$)7NaE_kF^Co|V9M72<4FVj2iF3bCzrRE1>TF;NLGeTR>f$Hv=J@)#~ z#VzbDk|#Mk=6v4zl2a&AK47C;ITF)~H92cY$KS#X6A`@1vClTlHdPiJm&##iIS1IK zJBS}SmKxsCyZSrMvkCjkV`no>TW#E!@!!;XkdgVq zJfbPo7rO<;_!%oRbNEcx&)1SYj>sihS5m~@2~O~O^sp%rL#iGr_^!ju_Nrj*rX1P$ zU1g@CtpY#&va-#R)I}$(%0=5S z7viGgIkswpBk`rhwP36pCWY^p8Q@D}pmCXd-nF<0^d&xdsNiz;2FD@V zlF%cRNTJGuu_Xg<;;!3^2wfhWCYZ7`-(9ou3}?c$5tg9B-NBwuo+^4xUZ1_<aX zpAItKc%o&Bk0(*OzQlXB3Ki*02*iWv*GmC{Nrb~Id9v?t$v^tvueR?DmyS40I0eO= zm##TCA$_o*Lj}|fi&BTN6CXR;7fLQD-EnNoL36L`T!vR`MEu511^kDE`}e)lycsKS$x`MA>-3|@enZ3?g9r+ztw;U__#Jc*})~_o5<@=;{dnS zHLxs*bwu}YjcCmZiNL~-GKL050&#eYVhytUT=T}ih9$^uw zersifLnw4=^}bC;o+58M(*QoEd#Lm18&>y{mkYCMJPJW?Y^*a)P;GOl?!j4H13UXr zb{&V=7qig{m+wf^Gd=BX0pWtmgr)no8lkoJ=TstKP0ntjQbmX%7ObFE^2c>6`IrJS zfXSDWb7d5tuleGwMnc`5`APV-uMsOg?w<2nh0 zv87Chp(Y8Lis;PLJIvW2X^aIY(V$pxIOLJ#1Dr_}AJ*3a@Y@(BIvp&%>iPXdO&d6t zfmZ1M?PDaHhxg-qMtH4!)0maJrmwkkP!T@y+trHj)GZd+hcfW2n@=_f_ku3$F}j@u zVWmFzvAkhI`tf$8dikuHnYG!y^jROrTO3`-|J9&{AFl3#H<|!O{{Lg_&EuhN+yDQo zRB|a=QI^SG*+RxXl8}Vr%D#l8F!r4pl_Wb!$X1pl`!Zu6WnX9P!;B^C*v3AXG5Ecw zuCBZL{@tI?=liDz5A%MXb1uhu9M9M5FtEkcGt!bExtKTHr$$N|k>}T-NZy-CGOhrB ztZ7wB7)t<*@^?&yeyi;^Vmf_%FavGl)l$_0ZR3bbIYwsd1vg@GAI?7F^b;lS&XsOW zo8DHs)K^1{elqPee_LB#?$1?ToZ0CS*O%`FSkmqup&|b&Qx|bekb$>A;-c@B#9oU% zXoYH`Ikc)b+l{+#pg>=nQfYs8;NhX-c>fmvX!bx{WVm`;l%V~uW#Ge?qgBg> z4JmF}%W{5ogs+5Fr9TCY6r1z`R)UZ@Ho|eOu(1c^j3*| z?b&P>mw9)eGukXS?fh`jI23iIVIC-?H*zB^%K_zYKKXg~V18Z4K|#%+sn|^RCs;h7 zbC*WlR-;Sgf46v4RmZ@=i3JwRC8;w^ad%_^n&$YdmSuv4Z_Tg_yZiZtBYk5|ON>d0 zL1M~DU5Dr74D{n!gXfA#`c7{zbc?AhnOH=}&#AObKAf`kVePqGx}Z}l|C)rbVQnmB z-<}+LmFLLpGfH1+=nl)L@qr`0Y@vJEEKu%T)*{Pal7PyKUX|d1cOW@1at&ae`18v}}!9k1)*sL5N$@IY6 z%ZXwN%18^ljX>LrsaMx|rzc4jz1R$*d*Or(9a0z!MOUFc(o_Z;?tke}VD>Qgnynkk z{xr7H5*t{Upt)Rm5a<$nJHF3paf)o`FICCXiD>H>MCLXq1cZ(oGwsQ^qwSiD!jrnh ziUH9_e|5&;=$|Hq;Rg$0 z_k7H|tSkN1IL~A9?JL(uF1zjwbY?}{RHE7cjnDd;0F?1XT)KQg{eX-BO;88bk%gc1 zUVQCnFmANcK0842l<4~&eH-fKWX=>XHh#j(ARsKZzc~f>hzU`Bw{5&b9&pcBt>~Ku z`_Kbc0A|5tv)2&WUaig18u=UYZ?j1DB(J%U3$N5QDzqa8}o3gWSUb2ntPK^=d;mZXY?# z{=R>9F}@~_3gRu)!>)+xk_@Ns$R06jdH5}9qoxXHYQ3f-CXt@+)fFa2&SMqps&^@! zLkKW`B~&cZTRq@s;dR^kZVgRjIb=Z2D`vj1lMauEMG zbx{^wc)*xYbidszUlhuVGiqWua2f50v2AF6xfQXjdF$Gt!o`^(^T0wm+p6)*2*qG+lR``n zYZk=xtoVAPXnyHnye|3<_EfxxTe0DIHxu|&b&4&wpiMuwTi*L@k_U$$#CuAAy4DxJ z(k+x#`)TUMXfH>W$3Sxi{=0WXaF_Ve3uXc)Z9a!Uj!j!E09N?xRTHRbOft9k=^tbIcX+Ibee@nP$b@9r!e z@m_juSCXmI| zb@QEpJ><)LuXEAF52$EHNxs1Wr;1Ats^+q)u8HE@(zDuDLKZ;2hRch(CaCJ|Os(_- zE{Q|=S^|zFa!->ULJyzTh>7A7gLC458n2Ae^}5@S!>SP>T;%8d@33OOJ8o9Z-tD0dxv|YA%Vqme#JI~o{v2?KKyykpWmq!Gw ztcS6v=rrqka*(rW{23x~^3%Jg)3`q`8h7-0!Y#YN z0G0r-wqK+nv=)MyS2MZN=N)04&K)wh=$hx@ONhq0@^ic`P^QhxCrQW%6id{Ag1wE& zl!Rn}46d#kfn?FI_RK7IEeLFt z1KX!ps?e}`xy@l&_3{|&2xXWE7R44QSvR|h_l4>da5IN|XIXgwz4>Oq5_3ALK&(qM z%f35Em!P~Gxu|Pb?HaijI%GBa%t@lQT47eag9AGaAr%v{Ng%s|z+vvn*k*IFc6FA|Ej=p^i zK)NxCwc6epHw{QXXZ}>SKjJ>u;hdAxh{WW7jtggAO>&;XHJD)QXY9-C z8+HaVf+q$M9hSnfist1;0m+z^U=YgtivMo@uE>EK$!eR`sg?~zo-~^Uo}gWrR?bKmhyeTdA`lXh`SE3`aKb}VPG^yb77IW@puls!B1XH zdz8{TVUAERM@dpCBp$u$-VuN?n*Q zaJQAgBxoi;VlbhfFfabJ)PnQtCT;F%$e2M+3U+{VpybVrQyS1P)g1>Hj(1_P&NVz` z48{4}i2M$cHuQb};Gh`l?a!SXwCBbWQR6F|8FyR9)Ap!Sv9@D3zpLq$m7M%3H)}sY z`%1yacudjdEFk?Q5VdScOP-zMsbjhdmG-UdEEHsM6teq)eW@l>SVDJ{s_rOyG4_*V z?5%XxYq97^f9zcEeyg~<*NjSsU1tVNt7cAp`b(BuP=`6?SR^NgIVBzfxh)^&=2zfB zh)hD6L`h;=Q1BUtk0_%dbNnq>Nol=FzF1`iuo%jb-vdQWthrSj`sA|m6@wvWX%6yk z>C*Zic@2Dhu9A7Mx^?m!4uee2PM#M+DH42VIi)v!w~LJLzGljooGG!6d;vB4gw$5x z2}Z4Y9`5tCi_}A{NQu?dKs5KmUxwk52Px?r1=dIsMWN~XhX5INo&FZ78=V%SDi=U^Zqt z-*GY^H5kKRE4R%vzGJTQcu|Ns&2Zi9#J|?aDY|MJKiO~vkcxq$d&hiG`+1)Y!{v+e zA)3aedPz%j;MqDAz{_Wr>C~X;c#R1kt`YODpcPoS$oGw4B!>gEbl;GtP_Y93G_Xeh zO|TMT#^(*LQQgT)ki4s)t__$E6!XP@qPZon1kQj4;R@=$i-u3Z>ayF-{8=p1mq#q;69D6+4sM}-x zE7;zyUCO6rFbscAlyZqr}R`TKSI?iX-osEs$e3_ zV+0t_0pi;FH28dZ!%|1U844hbmq(B({I>iDEv@tYB)>3?GvypgV>$5(PO>3)2u$ne<{LzMI8#(RnLXQz!8ovkI= z?ry~qjm_k?pJceC7cN@2E>xt0;?{ikPK#T)zTQD_MxPV@WM=ejA`agr>UveF2Rq=X zknbN@^zo5dZ6c&hrkv1yG_P6V^4(Aic4)F$AZ5lEQGp7*LP`lOzQ9;=X^e|mD=lx) zZnvxX(!Ou8k?eH#z<4g??N*OYi&KPAZeJ?F-vuha=dfXmQB_*c+*_Xv7Sl?4pp+>7 z!N#>EqSix6ih`@YkS;Q5YJG3`fni?L%Q=KB68uK#%gXmC1K+i;Ow=vheAQgv)zr^A zO~=fL#TIA-##lO+`$>A=)$!qLYz{*;yl@jIOplVWlIx?j8W&V(Z9j9w{wqGl+SRUE zAd%DBU;&jx>Uo!l*PFkU#3)s;;4e=al?9=QUo|y@*Hsphd=@Tq4w(N~BJXe|b-%=P#%;(7rDY)#*{{$g9H@|HY*L(K=a+M6un|da)ri@pH6)XWd_6Fbo zlGOnxU)5Iy`a%dd>O>bDcd*Lmt_pG{rAXb+CwD%nW^x_+rq$}CZ!p5(xF!7TdN8;< zg|{>2HwndTBAMz~;ZrHX3J4_pB}X1qCq{?_%R17yaX_6>cNP@@SS-wveCx1I_|0JTvO|vdJSXU@u7_Y|ugu)q)lan0q!x?&Y&{1JyEC{Hacrj+Zp?2L z2G&}PRh$_cSj>tHpBu2gfd*<5t*SMbIYReeaz9vUD*Fgx(*vA6!0;)t1P#VxC7BxAexC9=08Td=WJfwqRK@2`e{!l2J@`_Q5_{K1$Qpzr2LmA zS8?W!CKnkqIB*G0dnp(e)sQm2n-A#ZoPuKk#8z;f+ygX1omMXA?uy$CE95`$5LSuG zE>NP_vNWAq^tCj;eW@h6e=J7X@w36BHKPL#GsD#q#z*G6xTY^aFinSKMRHl+yVSA->T56g$`revJZ*EfFTx_pn%O63UeaeM zvYP**LqFx=UOD0G6@T2<%+2g#&Z*wL{AD32_;A8f<(!jq03ez$l;SI&3yWE!bTx|* zr)?LBKK(15X{`pEeba&w!w+f)o&tHrTX+F5vpqOqi-XdG^@U@|FTk&}9-m0p%GvZk zTL24icjIuYAp2XAd^Y5-Sxzm+>NJ|``R?-uJ8Ck1#bE+^A*v{UF+>BV}#- z`TIv?-{2@wmA4-1$s@9=B2tDgTCqbczGyi4qUegD!m>TJG?87uK$Wt?**EX0HJHd{ zx*V;2`1!*ok<=iaut9%;dt>t6KnqEWh?HaqhM9W@NS#F$IvgnzT^s%BJwpG zSH2ey^1l8!A0EOj%@X4_SM2&)kDvm=k4)c&4qYMEXg10Ry~#u}>6$p%u#tkwu9j}nf(hAzZHM6ylw=~B`l@fHW#Z9V?&_m8%N?{5C9QsG zdw*qhbBej%f9Ou-Obtuv#8_#X^%vY=ie*KK*p2yB}ju*rUi zoY=8kPLQ{HsBj|MAr@m(+J~NvRI{Ga*~i`=;lHNx3WPV0N5Pt3?kp2|2F`C36t1{w zd!?{1U@*#^C*6L(`O*kzj$=QFT8>;Yb5L}>9_ zos@#(Zcn|CH9*Mo=D>P$5w!^7rH8q1`K$@$|)^|J@*^)_r-WtHqxI_JqnMBn$zkM`qtd4#N34U9*v*nKQu-7~!%X0iD?M^cb%XrU*{>1_SSfBG8FcJ}&NEHyBUPJ)U zvqQr!sTt-$8vy+EYu5)VUDBvLv{eAW2;1WUO2D3!wzp(EvA?&gED)t~pa_T)s5>o6 zkR1gMIVK0{3x>$kXl52x1wn!TiRb=}jr|n)ypB4obn+h|!A_eF{0zX+mBo%X1T*IZ zs8_+-)=Z)U3_QhI>|QM_}~$QFLiNM zxN^aFHu-t~mU_UZI>2ZfnEUXX*7{1FsetT!54_Y_p>hD*>``A6@SF2_NF^3udZZp1 z(zdT7u`{^Q&8+Tr!K3)$-nzuQ4m;Gj+(Ohvb2u5G z-C2l7V*3Zt^n%R-pk2znulu~I|6Muq@2vathGyW>mNnD2E;W2I-~JFXZ-QFT?s$2m z{}Imm@A-DDfJUGn0tj?}$OsAq&@Y&YOS<@Cvgcq;nzH&+b{LqhZ*ZTUXTzGA z0j&RP_qo|`uYOuOZ~<4*GM~zGXpP4C}PbavXAemdD8@Q2zzXW9>6+G z5!6o}t7-EC1Q|7kh6YN-5(b^;e~)zj1^)j2;a^cd3GFS;2G)UtzqKFRO}}1KHN^xY zAqr^IiWOe>d+t$y9*rkHhR6dE^|G*F;06)_Xio?!(l~#PjyB)=kfGvXdQ?6x=zonFf_6x)|WT;2ISo$dy1vY>nTKcv^FX`Je z>7s1PJ?Gta0P7qXGXm)bkY6DdsosVo*eWvBvqB;%D1&|5^A#4>)#XEmJ%LGh)>tpH zzo5ee%ZPD~9^anbkQrPepOS~+z2T$*W%Bx-tsS}2YwB|6V}p9)`DIU{MOn5p%HFSE z=|q%mMA*i1_C|u!ZlnL;-Zz&jE@{0MH4q0eLwKXEc@nY(f;~R?XEsj(c|hPXWm22j zb*yJyzbrZ* zyyHWxkSlLn=f0bMGrJHHeg2Ko{Md89*83GMh1@4e^VwRkBww(Ne^To_1vMBo9lFKU z)4lO6HaDcUP}Jy1VX;)57cYlK-CyYES>E=OMG`8TAG^9Cxoh7Om2^U#6XY_+4_Hb+Pcmm(s-EaTvp-j2bV98PcRuFcGxy#w z>e%_zS-OheAc!OuYjZ*T*&ZDtpK95s{sa)5$+M&A9m2+sbm&A@ym@F{M|@$B3A6P0 zL6nH#UI~#hB{t?OPRooshHsGfRvTEwf|T~_StnPL;>}Me)zn?Up7LJ;6t*4g>J!y* zNxZG&87o{}_2rMdR*1v*z00jf)dtU_%EMKSJf{VEtjX~~V2e{m(;_y?{(|RTJ zCT4uBK69^+Oos@+pi#C*%qZsl!q>`K_b*{>^l)|;eAqYwr;jR{!5%C)nJ#7skzg~C z@Gh8t-EAm->%w~I8N(jf`Hl4EC`HgsyFkte>7DO!(O9^TYo5@!_0|=oF4NhA;25*U z)5I&ue&A;f#v{IRhULw3(f+AYqTLqr@ZRUATcaM}$ezNrsj09z=Ey$Mj;yAGxA(9O zXVDPJ-yU|Ox-=m}%yl1X?t|j;>OAW9&#vfT1*FY;*PoJcgtUOM%0GlIrYgZ%%o7wD z-!*hT#;Ot!U)IGM>wWTmzs0E;iRJ3F6<-+ftuo*KJ)vDqJq-wg}^FEq3D8kCR4 zN^C3uPU2$ttJ=Khd5{Ch+_*)_Pwq_5jGU66$Z~jf$#%&Y#ZoS^)$?16r z_q@pG<3+VP6TsE%U*I-cXmIDnn1Xl2JR>Q-rJ-O$^09?))eRZBu%^tB09P~smc6c&k%W?a%r@E>Y?C=L!}maUNIXMXO(OQtz#-5ivE3+ zGI0X;x2JYSbyF90O>i)+m;nW$sPPfLqUUq^JPkfob_+~#{jbb$j|d1+T@#gu)if)Q z*G0TZj`B#3*-Y-mDCUAfFN;{SA%!2m=He=wwDWZAyCuETQ_d0Fe=Pli=dCZ?Fr)gA zowVD6iBfcAlfOKlhE+>nNaUut%ChUl54~>Wv5f~;4hE%tM4f=fcZB4Z^Ih^wAxtTj zdqgm{d1$K*`o2_n&mM~)+ReD`El>2c*JFXl?MmM0z?VyVsx@+0K@Amjg6@LPE4f?5 z^be}qNiteUcuzXsnEj-xi}#MrJT`{{{Yd=!uN|%Zwwi#t7vQ6?B&TG(l?Ak;V~yR4 zo9_JqHOF@pRE;RA%* zs0H!>YX#f$lK8QW9~(6H&VoEZ^cao%n4{{JOyEljNc#hgcd~xe%@q10bifg1HdUZm zm*P}CU0#V|-gCL%@^pivcg1L4xVZRa0R`D4nK+hpQm(4`;M55fuW{EUD&d;*?wz{2 z3zYWlh@^GffWk-UM7N)GWguS4=vWwx za=*ddxLxhJ=t#}{EbwXA=*>rcEyjWiitF#yJ^P^cQGgF| z+qmI6!+q|qxv4jx=)USGWr#XlIca6Af|EFptoXE8wK-8`&@LZPZEdPoK1OP@Ck(Vz zdvc#QI&<>T->l_o&ZjcI5AVTmFKp#K2vqdZ;eDyYY|F1}1Fbf$GzIxtx3`1AS0Ty@ z57Ey>!qqj`{}D|D=)UO(+5|9k+s^7`R30?|_#ds;7sFZCDrnrmS~Ke=A0jJ17HVPo zntGgD8f{s64X~(Aixy%|xPjZL97Nv=efKa!GM;rjq(tUZS& zT`0)NBYm44O(m?JpE&~=ggEtw-E}D#>eO0?NeK{TtwxFvCDzu@YO)2h>7aLPdI{5q zh~Uj6f@X|~by?!}WaNvhPVCm|Gj8EqFn_H|sf}!|z$;=w`z9?l7vrx4FIJv}^TRYg zMdVzRbsG8L)ab>LJ(5e!PUxzAc%rUxJ7WLAcKV}?XwAm)^35qgE;JqdZA@)!ldT_+ zV;HTMGK*HZ(#uz*73_Mtp-&ILjT%tAoWfef#GWM)pYcx1S_PA6y!}el7NP+csu`=0 zU|ifWX!#_D;N;kzk9v7}bR{z4%?K(|Z@NQBFD=LAWTmdCuF`wk^h~jtVZjb4fD7{s zUx!T%2!hVNTh6Cm=>lj3A#pB}BAx3NnT4e5*jV~rPoYkAEEhB7!?MJba>X<5;G?+U zIOmD$khX-)-TQHp%}!`ZsN}W0IIx=#A@D9(vQqS@SI3fT zO@+k^4Rf`g@=83)Z>x*oS@@N?K`i$wr`P1Aqpu z%5R<95H;)0!7CS{SPF$Y?bwYAz+<0Rw&FfORg*EeG$mpd^Q~h+)xAS)q{K+|meGM= zp4^rwud&8bfs0uRSHq3cV(7vw`n||DQ1_IUgaQAfCuWv3fpoP;tIvFVgv~(wS2Yz; z^QeQz=0*fP2k)@{?f}62%XmqfB)!akfP{{>V6TfU>`QMHbmc2LwJZ^CZl`P#zPpq! zL?!Uflwz4%^N}K`PYDAuaTIat3$4a@*Er`gp2U2A9qa?)$&TnWR)bzAYpDQse%Tpy zqQbp(kBFH+P4i|krps2KnOQ?OrL)5c%;$C5qrP->iJ0G&lD#^7!&ICpalFxXMsr>E z4VuVNO3piyXXNjP$|x`h;8>MWMY%KNO}E~ei;CEtuv;=x7)1A(RcK=6n=2aMtUk37 zYEDH5LDWXLn39qaEpP)oWNq`?hT1-T<4DjUP7_hAu^MPQ4hsbipwzY+ai_npeZir? zoK^@mGBab%(OM}Rj2^t1(DgoTFZ1)eAkyvENs5ds3IUN{dfHX+IVaONYkdsHSoNcE zTw{M?MJ@{9aD4HU*y@E>7+8_V_` zTqt1iTQ9itI^Eaw(m22YZ+KnEgBl3YCshes4z&M5fQ`)~W72wM`k}5zlz!=$(6lTA z7PWL=@a_e36j>%y9G>+TR=nMUUi9#ZV0evS7X=A)@pqk$&Y?~g65 z?&4|jwCx+vhSFZ2>0`?1pmlMl$)m$+u8jA^MN7Lw!DcoEA`bJaqnGU`&+ZuqM=)+l zedHG8WtNjf$RwB2r%3Uye_@rfU*d%qD&_q`c=eA|+)bPJPfvNf$^bhoALE{}I%Tu*NE47Ma|nWTjsb*)@Xb?UmgE7u~z zX{T*Bkh?#Mgn=wF^48kI7*MnA%>=DCWvv8iPgP#HBDTaeZx<3@$m5ve7lq&^3^Mx_ z;HTFIrCRJc@f_;ocTJ7bR=s-c3RW%#P8x`&@u%6l#E^i~I=A>RepL%2i!6LkEo-qs zi*7EI2&f~#c}_)BX?ZgecUAq0DUJ4YGPgP~hp7R>MQ22JSz;tMFi=(m> z=;{2oMR(6*B8O!&*CwvyWkW$F#vU)23h^E!qj9Z`;gGrduWF7r%!yx_a3>LgTf!Xy z<&sLB{|KzQAJR}8h2o34_<`Zl)p|xu{nA3|qvJ=)g^Qu8{z=5w-2#yuzudW5pPWgq z)z&p3@Bi-3v^mSwI_~g59znWfuPoRqw`EE(+gIbfxqtZa%S}3oE<96++Wu^qdKr$Dp}xnU+aKqAJh1@a7|*C< z6V|N|9z@~S_pN%Jt&X!;Z>CEu`CvB>pPkMuBXy+@_$p)n zWwzZacw4R56yFP<@O}-LZo8|3B*LDET!?P$chsi%_6Kr0oO_&CSQSzG%B|WhysQTn z9j1!KF7)m&4__)GsTMVnE2=uH9t+t`RG z^V%(LgoR?T;kXp)jVQs$i00Bg3kzE*Z}o=8=7)MKbk-wlKUr@t%~Erk{#f$mACsRy zI5qXROSkaBD4Kdr=~v?IMj)^SpTXvBD~senXZ_)uYe|?F0{PG9JV_~}0ta(5Cqc=R zOd-Ivc6P>@yx!&PHMXQpGw-mAC66yl02TIS_iW^OW$jq}wAqc3qaEBe3_XJCRUxRP zx)`Ejei>XOfR34a@g&q1CX@nzwHoiRuar7SO{q2Ue<+`Q*>Og#N1Ara`CxG8`~9dZ zuv+)<9k)!WPWsBl?vroKw9&r;2!%U90P(8-RebYU$CKR>y)!^nX*J|N-FiCBLLMzS zxRYKx_53mW!RI;!E;OG~=m$R7ux+vWbe~mt>1Be*g0}~Pt=@l8q}Kg_uE-%{On;fUGUm8>t6baRxi#e&L8}& zC7#C5qAADOo4gtK-%SQFuYw@n&`Y^1D`0`LC~>wkZ~HC%pZHxAgl%$*nS<<=mc(&S zL1lMAAlG*LH? z#}>AhDyCY1MCmg@?8qpTvHuO*0xm2x2R2vr3euZ^-KwIfY)WtGZ`6DfS|V&dF^P_I zHK}`8cwO4g&l=?C;+-nKB zNK3-mQ6zsnH}BI6ex`U(FOv%wMMjlNppcaHlZP3$0%R~WhgY?w)pZy?S*2l{2L+8o1fxJ3Bcr=ex?zA#a_tEJk$dB-B-J?rX}oUKahdj9-Ad3 zTVns2ff~a}KUx9?tL#ueKchZD?mN8Ke!ra_mxNJeA~8UF3-2HZidfBFqyPbJ15eH4<~N5)>IiY3rPQrK!E2 zY~o2j38&^1QArH>LT?oEXo_r-F<7uKiw^5$W@lk3)Rp!)Z+bybKDue3Hb)3vHjuUK zXC~G{F^*V1gRHd&gSI&Krx#ol4eD(b4Q79Ah)@-R>H@GI((hLKXm(5vEvVJLr5J0M zZ}AJ3e%v@5-gn)6T1oh`_;W*h*PeE>7De6dqYfWlitNPr=dw-V=yMC1BfItQ3}G?Q z3a%;V^`OPqs`yus-I~RL`1MDCUA$uT>JhkYq>IM=) zv%$Ygb3=_Z3~=5OXb#guML$T(8{|PK0%^Z!%v)6D{;exDy{@0xGZc;hzOVLTwVS$^ z_Z-JY`S?B%5hl!mDbieHRV<s}VirP=ndq@A`I z&9Q?*yB4Vy4wjb=Bjob=TdxL9Eyd)(fRu4$l zzAH?HiOr=1e<=1(-(UBZiKWVfDf?O;gGH$7Rv&)}Aj?*|3SKPKnPbZ_vt_9xE_O6K zV#l-0H8Qu#4buGUL~hM&)ub$Wh9A{&5`Cwu$kI^stQ=s!0oQFa8sy6OvOB6t=O^Uq zCLK~Sgj~R8mhz5ERh22Zo&bEeyGt%^Jh3<{<{D~>aK{-6T}yHBnzrG6Y|CMnm|0#= z|I`+c(;${dTrN809{A|S3gve+yhEA0Il!X9Ip{=sg%l0cs?wA6u}~ke_?CX9FXKcj zIse@J!nlrk;*`BM*nl|+>EQ2(>Ef~8&EgRW3s)unrC2++()r#iHhgNH>Vm*rSq1jOV4;sS6+*kW)JgnbbH%pvj~LJ z*=*-um6UL9GXX8oJOX5@Vx8iql$XrQT;980Y7`hy&oLjEujwczs{1jKFPceJZ0w7! zIt&g4I#rfrmTxM=C+Ydax&j)zeF~dOyAHtO*~nvbty+E3q(?~9dQn3ORa$PNf%=aZ zs1Km81Sj+8tJu+9A*K)(F`=PN6?FK8(oC91cBG^AzWfng6UULj*PcKPgJq(lz2yhT z3P|t&PmZ-(B7CGZ0gB5*yHQ!?>kP%lyS-~|5Wjp?$4kLn!sGYSO5`*%YrQw zDy$YP4J*zj%>udql?tR8B3bg2LN$`fx`#JEM0l2N#g~Jw)X^$u?jJ=Bd>%;iO+`r8 ze_ZMp(6BT2M&GobkSqN|O&7lvn{jMbRdyNRwhLvZG!NAfix!&mi`%5p3qlw z^j$@QO_3#QNYQs2*5qk!o@ICz&X1ztUkNn`%ShM5m+aq2Gl*h~ij1V1N$5j(1=EEn zdFzDvpe|FNmF75SmD5(ylA7;tj_~j1a-kBB+Fhp8b;#JRG+UEaUIRy`@8Xm{twQRb zhH7Gcd{Yu`Wj9qSsw>Q466k|8bm(1ec8^w7xmsJ}6r5c7kZYxIO_-f6<#VNeHXQ{z z-(0d#{TW2o-{T>je7wX4`LoohTKiG$+VTLlUBjdhR&N_rXr8K?U7+J*F<(ls2R-7h z<1FuDF3J?|Yc2D-u|P{DoVSQA-BLV;6n6A*XytxXPGW>x`-kj*mXDPei(k!gnr}K! zOd`t-|CJd&H}%!$!?YkJi;*=otysJH!-DO!!M0w#UyG!gs8XdbyMY!ELO8(IjhY0u z(vziMg`2iVgbY(0F!sCFd22<5Q~k4DsnX=97!OhKfa0Ue$LyTx@d;iv;-cb)pi}Ws zF;Y)KpnO?RR&e|=dm@MGu3f6Kyu7+efa_ZSq>(?O*o3{o%CUuBevUpRW2AUzKpm1D zOj;zU&%UVq$5XTY2XgZu4=AWnjb5i+GCMugXsqJSII$papKiR7*yG7LT@;uUJ)T!k zaTZV+|M8Rw`axbj0dO#N?FNYNfg-x3PWBD*sPl%aiRf~#CzO3D@=z}+cXG_C1Flu}41z+OpbZoX|c75*6t-c0-J=rcwy%8_4 zHms19{AB#DX zX|X?p)0Hf55BP~g=jdNOkZ*i;#&^juP|GCB6A1{Cxyos*8DJSz0pIhj@Fm$rYp9$X zVyd`J@OBBoyw#Ymy+QjccUA_FS+Tp~Id{bPfJe2=H6-VPSX8iNo6ck9r?t_%e1{V; zIQhJ`liQ)fhKp$#xl+rvxpNn?(k(pHBlL)( zl#v~%R_HY1lx_S^bM8{q^Juz%thq}i&4Gi_oj)aa)YtXDICAg(=EyC;+~ZPyD=@+s z5T$K#$OP%ICji@?i0hjf$VP!=)S3$QQT;V1(xAiHN)D;aPm^&q1F3#& z--bY;hjg-=Qg*OX&8p2Chl&wJZ!h>oliE)zby33?Tj|})mad+_HulkD%$G#)bXIC7 zfP945@A-&pBEWHgG|@HTD}EjhX0&7pz`Q8mxOn_ dxSS7Xg6o>riI6rjL=I0=^{ zG5}rb96W_zCF^SW_PJen4Yh6yS%waRG=W&?zB<+ zK3~^v=0!-6?UtrDec;Ex(XU^2yTvy2Y6M@J!4h)ZFm_wQGh5oU)aE4oyH|<*ZOCfJ zY+-K74xm>!sBGJsFiOsdI(v*`iDCFOHfz(9<%qzhVct_g@xk_i@GFfO;`SuX6P3lU zlU1VPRFdUDl%ZLmsU5|o8;HgiatmL@TfoT=Z$tmEH2`jiigQ)2J~0JYg>%X3H9+Od z_zyNbJ#G4$5p0+CGf}Pq60~g1HQ0$vRR>ZX!?07|iuBg$-6!#E(eWp4PM5z-G{a>& zTD@oc+;T(Z%?O{LQ>+Svxt|b_q);ld@elrHDoh(!KV7^tW3|0ct2~0(!2t&BhzqC; z;uG>wkj{PhW*>b9^mAWy%>smOXl5IX&7KU7wEUX^m9_qx0Y%5)R>_zRQH+pS>Zo!i z(jHp?c)CJ7_(S+}pa%l?oNk1hNe=|SFpK>{yH9wgq!qi|h0W|gqTQk%;@F}Oq|SO3 z0UhLn~-%yeCmn(FzOAV1eUUijRw{X#cv%2jII0P@muWp((zwp z(esTTvX>BRsWcF00jyj^!%lwO#Xxd}2DNr30@ElvnokpH9+jb?KgbflDv7U|WIV3IwR)m}K`(@pa%sMpfJG(%@O%XTo+5kQ z^Q3stWzQ54b6B3xHp7n)ixn8#dJ=$$Ou?(d4J*A3Ez``GAW(?qWw+=1F2Uf*eXFU| zy~S-Y4S<_`%{m+O>r!#)*qxssJ$^wZ_jDyYA2xXjgI#_&ej4*Dhw~e&^-mD^>vvx* zf1*?}^mpBuhW-N>JGF8WzYX-8BFS<9jT*=^@qOA*kpHUkDgNO7-MNgY`n}!lzm1O% z0_m9#w;U(XhcTv}J^Smw|1Y1c*YdS+?0}V<8lSkkOWhl1UtS5GvQ6GIvrg+8T z3--_S9>*d9R*?u8AAeu?v1azEV=$|g6W**psLM}^(pr0!kMHca`QKK+P8hikknYO( z9qet>dD;P9%|B>H;P|#x+BLdcrZB=m(GfTR9qhEwrv?_?2z= zAHljGiy=Yc*#5fhK|g;PLyy*Ns1mtNryhX3JlA8JG=GwpOQT-nGq}M?bv+7vWstzoA3tr znrSd^TimI2%>(01B-SE8v1YwpXnrGu4UR|H zKfhsTLtq-`m-!o`1k!evjGu|v%hctTXmVi#vK0qugW?R(2V`q|0PsE2O`ZzIyqMa2 z{sa6Jf0izjp( zpbC`!jn{K^JG;2J3sBtf%7s004{#DD{)s8zLH+;LivFKfG2{h|D{!wu zS?{D%>VCLjYfYgl{`SPJ`s}u7)J)TjzvDNkz5OeYl>3htq#O+UrCG>F3Tdq#Hurs3 zI@k1!%2-qJ2mNaO*oE((7TWgdxsH7aE&zSHQr!Z6Pzpj?s0yI&l^5~>0oW77Ky)oA5$NW6F zHC)C89dg#KFXF2;5V zm;!+wcLFU>SX2Q|u@>P}K|9mb9N3?jM)qWX>T9n0KSzP~AWL*Vp8@uj%z+=G4F&W% zKJnLUc^kGBRW>oU>tb+*Zo_FLRc4UBWau? zZphQM!a1xVwnzJ=og zxQ_-T-$}awNMwh&g*z`OsnOQ&CyDIN;V8BoC>~n>)CIp4h+k2++uh&yhr4?m42iHZ zmLCtG2t)%DU%kMS zt{$0RB-)y+qDSm{8vJ%XgV}?!WfaNmDycPAsLeEL)zg^L58dud2x!=8OE_y|fhlIL zF7x`6Xd*ZZyh$?~JDvLC_ZPc*omfM@4l~UxV}JDDE$wxqGccLleFMNWC1xa zJ>S*s`O?o8CdrbNGV9NBhF(BJ7`FD=0*sht3JaVa?-cs6$lCW+O14NU3&yM&7(yV@ zuT`jaHeg|OEOw@h$1!?st=l+%pXp%S-a0QDFfj(nZ4dnZ2Wy$SDtl{nIMEQVpIttR z2&D6JUNpDgHOSTT+QmKh15AslNajbr|d{y z_a+zkxBEKc_r|N^3#u#>o**?BIxEM)IT3^LX~L|_X)L5V`LL|rTf=@m(@K|_?|-O$ z!Tge|U>m(Yv(+wE+)s6BL)41_IeCA}S zXvTOsh|zyMWGSqz*xA-)j!Up83bGIw$A-)j4R7KYX|H;JU^b~tjFoEx$qMlQ>S)Z6 zbuL#>Cza1YhVlJSDg?IRI94<7I8rfzI@nvO&dA_ZziX)b_55NDO4x;V-MC7MJO74SVx`P)gsF{gwq`1KViNY{ZV?*DY z*0Uk-Cb>&#t-%#cJ)(BDAlTxT5ihEp;Wb3mVMBL})&7gzZ06X8-FOjM*e80++u(6NQ7dbtRutGGSUjD|5p|2!$<4cf*yf~>D{8T!Qkv}fv!R*=0c^*1-gK4*?yc-wn()?-KA7$osHY%BZ=zj zVW(E zs*uo&QbLuUKthogN~obH1kTNV_I}^!5az&asi=F63`8R4_P@Kv~_l+_BYO zquA@QOEcM6sc^*p=iCPDhE0ZlKbn`-Bc@w^=tC7hH{!M3#k5iaqH$<*V*9*Q->I|2 zTh2Ub@1u+&Ekj*4?Dm@$%4fWLXK+?Kds3&ZLK!!iQb><^vNEx`upuKKtSyMS zd>l(zepX=K+=fV>I|;4I@esiDR`n-zN^c+W;Z_vLSxUqvB(#V+Z-9bzP*d6IlBiho zbe(G&sw2=U=f)VJQN0Xq7!9AW-@JV7^mSp|-Kl&%>w}h?%JosCx!7$Wkf7bnIu;1TM08hu(}kJjt)H#xh$*dT?tG6LXVXiq zvOvrkhDZU!ylic4CjuX~`kAjNh4_m%xi6*eZ}_D82e`YPPtfctDv?L7mzU)A5T05T zh4s>MO?r>^pzr5IdRHnJM|TZ9XLn&M#6UzBDClj~+L7B&IjmHsSIMgV0-8`D#1g$P}d_lqS;_;Go5soW1J9PnNBAl*5&Ke zNzIB1ou&5{#zOrM-!q9lVrcyc?XGC8HsSG%N||;e2eIrlwbZGxs-%~wBCmUn0D~4% zOjBrSi$RhoZ9Q38+43dFPVmN(EID!{wE-tE`v)RJYd=y>HZ&9FK6MAnjS5^dAX*xj zc1Lo-hcLGpg&mW(oC7S<+48!=5Fw>*ZtM|7am1_nMUjh;Y}xcyVO{%mG|!){j#q{y z8Zm}(NFmItSg)lmr2`E;9j%0^W8dGO6)9nnz%k~k4#L=oVXZAil{(Xo(=t(uEflha zOU3{>96sOQ@jiwIP4L+#L|<-pIu@4otCGyhU@%2VPBrA~i(RdV|abwS9ROkBirYIZr2? zZM5pi9Y8c%l}aKOWONAwr1Bdr4}JTd#6CL!g)cIJ79ZSD1P9~;5(}!HuM15S`@vV4 zGknwHMd>Blm&e&xbZtIGXb*GjS6(NYM?9VDPKI1qOZKYyMaMaFZCsno$YQ4T7UgM| zFANvK>oonJfh|LbjV-S>zQy-X<&yB8_r3GGA4iwXe_K{*@a6LMEt(K(9cT&R9seB~ zmO%Ki_Bil=3?d;*0Ed6$PX8C-sTl;E<}TCl%}Ru%FI) zc-c)|b*afheL}u1a*K>Fpp}YRhEEu60kWMDrj4w`tR(Wm{4M&_G4e!_KsE4S%3 zBl;0RN)jwMO z_uCsWqIF3d0xfJ9|gleg*l&c7(&l8TLoSJm6@kO?XHZS=7Y*|4pqMUWh_bg{#LDIqH z%X2CY{pt?gI;t=$e>V z(t4Dh*XJ4RyYWc#KEc~`{_C$=WDvD90i+^0fbKds^XT3-X)NnF{kGR=(? z8AKc{Kmd2*lUWj$skJW$0*pnvV=nZM???ru>L@{)xu4bwiPSf0zUVEIhK`hK%lhr` zefRUp8|C+TdA7mkp?TBeoSwE>CztXO%irLin5{SnIwmTcY7@|@Hr*(>5xP|>+qBpw zyGozDRy$<((TK=}u_0T0OWI`$d&~?xkq57JyFbf)E=U?ks zu=@GF1A|L6+!AF4(nuCXE7Lu0rVS1fU|HTvT55<}+&^`P2&b6MS~@&eU&Zi!6oa1p&x zqoP3|V1Rz}{s6z(4G48hBVfXUX1YF+9oKgH-HxrN9-fTy%hMm-P9tHl1cl9nRM0a) z4w#9;v6J|LrK!SaPZyfGTdAN5%kIMSx&xY<@1$+{RWY`HdC)t~@NyQ!w7q1VLxozT zkrVTH+5^eRwDh%06tvNvkAmwcp0`!+N~2IpTP1$uja1LYPy8J3(%K-!&GeVEgqye) z)pqYWt!6_nd@sw?daQjfATi7mN2dvy&s=kK_v+wxsmip5aDVea9 zcEx#8;>0(iYCaEp1o2ADwn09)BC;l$cmwx=Ac}iulot2vrx!-}iCasH@pTt2O42e- z;dp!KO5WOaQiT6N(s~dfjgu8=bv7-TSUoBV|KrevxOB>283ZJE{(#=N1jNYA&Onw(EgNzMr&A{P9ZAS5ES2`haXPcln^_K^!3}p2%A> zHCF$k4f*1!J)sbg^gZW@p3CljF{Y8;_n^Mn13Ir!Z$N}pw$ha?G%ubnXj?ly;Ec-G za4=}~Tus^w0|f2yLCfht0P4Pw+Ieq1yKlRp#_Qud5pRhFYpIPBjIo5{zaHldowhms zGlyG{I26L0Np%a^OI(TVZ8=J~#+VSfc|Wvi{Yk5}!P+smk7c*=mNp5nab|tc2`2Es z4)dkywu4=#Z0s}P2j_m7S1eb3na;+RoI+fBdJwN$lgceUmIGDd&EZ8)UUNly$ZZG9 z%5v<~h?ZRTms?u;p0f7cVgX{vfnB|r@xpG2dDlJRX(ZdhS-ZHb;4|YRk;9r8wPXQ3 z#U`$QSb)O4VYVf<=X^^9nhNb5oK5;++M_=6>~44ZafGR43Z}pP%)wWdto*HHAX8V> zb1u85%k64Mu_%-Ah>B!+ZEQ+jK6nKX7@nzXvDORK2OGr0r$fY3rU+8Ca*)=lhZzoR z1yp;82TSqSD3K->$^&iHmgAm2H*EH5`5!mmY~5US+>wy-@X^ZUHCzL?n0bPc%Jm)C z0*c^Xf?sclk^e3?zVH)2q}eG}V%WkLO|>26wA%_&Dk&*!^IG$~6d5vW<)5xnJ=7AI zf>K6in-eWI41(SI;)1|Kk3J(k%i-l3*>86x;1@upd0sxFC?0{ZO{c=J;i3h04~8u1 zBJne5VOsPpn%gwjG!9~>-ffi56x6W@`VXbDQe21~JW{-S_fbRK4d-pm%$DuJ zRpn-AAZGF$`RW3UZviPRH(ZfWNt-`Haz^N`v2!-|Mc@Ug30vKLP6mC(h1ZYzI+9|v zUFIcp^~%A(bt=S2l1GHnBcB*1eMK&K?~{9BZbbL{6R7RDX7T1z=H_pM zzhg6DC1Ha#0e24djQG89zXvTs?_zXsNQ+agrn2s|NEfrz-$YqK?nUd<7>|zk_25r& z6-n?GzfQS%7l2j)VTF80YPYxQO(_K4uj?hEKO5h@KB>zj^BGp9&^2i zct)R;`bPFU1$Ot$_h_>2xZ>fJEG<&kC+@6tgf3-0Wzlv8Jydqu@3^xys)9r4th0*0 zoHi@1F%#tc&GWwGsPQ~idaW$SS{6@9ai_u%zI)kRSe#orpF+T-cL>-T0Z^8C&uh|_vCRYAvL~@ zj*1Tmleek%QlW|)Rf$nlhSRKIYKEyo4{1i|>jbS&^^4d?82 zwYOM}&Ng>M=2fm?L*DWaDgw73bKy9w4eVi~2r1^7tA-|Z8(EH^9*D-Jd(hSWxAWxP zAGp?Zu68D8Q^`6j#z-?bT&gKn-?)VyiVG+7Qme~CDU*bU=swOuXlSL@;(I#FyAjS4 zm8VXsqw&uzC1tlJLX#b6w-rpP)pa^Tp^jZLT-^c%N{YJC+7=;>U4b|HsiAfp^T{Y> z7lK^Si#E3)uQur+qg=pB+HdhQsfg0^q{nz&pfxU$G1_yQQA}g?vEAX?Bu%cJtHOibk?wecfB4r3IO zr|mD?C;uK@9O56fg;^P`iv;{H&UPe7_ybc<5PvC6UI)(%K9Qv zEDCeSB$i`SY(zmLYD4PH3Qsu#l;8TTLZ`)=psje>1)Ak!%jBsCEvNP$-{?5cQ4r&+ z1sD^@qpu!SMQ9Wz$D zW-S!Tt%tEvaEpbe&?5Zw!5n1nwQdjq}p*(~IB_%vBzf*eL9Yw9^5*SO-V_*qCYBpKU9OnKzv^tL4@Np&q19 zoAwj%K;Q^Zib=Z|@dUMsZmEgcTuK>{l1W`TgLeJeKrSA>77moX@Hqy|ztny64$;COUu?YlVd$99dW*Q+q; zbJ_Z`%00qJbD6gGUu8wRciDpnJ9Djz}VA40Y6LdIgh+EUT`@w;o8pAETPFc zPLDI5R0113mqxW%S4lYSW(zM^RTHUJ22Zx1mTm<(6uy$k?&(H6cWJqi_9gpi%Y(5- zFLAyZ>ENPE%wHqqe#A(n*WYV^jag%yW1}UeCnn?+YwuAoW62zbG zc}43BeVoaEEI!id8`&|9WynD@w2vk5e5s_z$BiRZR%;QMaHxM}BmwQ_cdn?hXreoZ z$Zo~)gJbt3+9&dUZRBih6Q@g&_!Q&Q@Qf#h^84vWr5cN8=vJrA%8ZU_Gmm-!zJRu{ z3k#3mdL28aScGSavlSv-t`1=-)J+&9K6E!h5qu5%1&}Y%itPHTW4IRKl!#$GHPqp0 zC)lNQDqR4_;sOGLI=xRg&ZS)n(cdz#8OSVz-@@^Y)%$Ky4tkHfg-HDV-eEKgQAg$( z-8a;H#z!%foSNd?l_1Hqm=&4lj@uXqU_t2FS+JS1(JWU{KkM+3i4Oi^F1x*}@85Daz@^f-_9PmEeq)C6Dxz2qQl*q~#Y6 zJ+_M719*W{SSzK_kaYxHXyFbNQ9h6Z#nB6>tzUm`FAsW;*oJps_5hVQUKQ2?7=US! z0;Ox=5?%{e7$@~L5Ij(&M~>dQb`i0t^Yw+O)vcFy$IKPACz#fH7W_ZzHqF*;R=^O1 z_~Qe@E;EgV<}XcIK#F)#@mRC3HQ<&Cq*?-W=57p8pZ01$4DldA|)2^URfiqYiY`;ysISu4CL=db!oYd2ZjMyqtvBnlgPLFmT zRQmovQJ1L3wQ+%+-lDyb42kK*{{GgGQvUh8$#p29Xk<;u^CbG>P>wti_T^hy=yU{U zk?!*#garGOoEgW8H@w*wk2NG!Nt%d2Bs^sf;7gBYLia7Vtg0>?%a&$ujrlA`l_Ht1 zSC@&AIcV69^j>eRwNy{4`MYCfG&86<)4R@DY>@$^yZWMbkVJ^oe9R)umvxuh{5w>} zoM=Rtp&hh@c8k^qAj)(ipLOUnD&cPLbj-pALK28av$_H$0l~rxl@f^$@fY#A{qy}% z8xKSvF}o^m`5wQ7Y$q&pD481g2zV9yr-+ zSg7zWxPJ%gL&d-?{KDpS?KlFjMg0JO(dX&Pv2=!mL8GU_&`^=IyQyXmK)-d=UO2Zg#x;=K^dvHy(5{FS&Rgh2*^bsVY#1LmTK z-O$JH%fAb*cYSy>3J9#G!+^lb+*VKSc^V@^+2%EGd(OOWOlTfX&EHLHDAvQ$NA#EM z;2yK{D~UW-@Q+X6EMufLI>cbdkaQM&N7QbNjLnAjX`YiywhVfxjr||iT#lU z!0bjupZ&z#UiH39#4fZZusLrl3JM@m&8Fzl6Yutt5Z7A_*KfI46e<=pO`SkCY+RP!ED_oi zR8@pFkJA&-6+7@&#=Oku?es4TanyBOF703+vLT47R7?r@yXHf@L{;X8kH* zaHA-Kd2SU%jS! zP3Vu4X!OF)jXN{P#um1xLl@b~zL|SpsjiEf9Oh`bo5m)?_tpnbxR>SpQ6jio+ugbN zRYJ-e*x1vBv=9EJ2tj%t^fGM5Ong>m*hRqkD!Fn>v?+Sx2{Cp}6LYQg?b=ZV?ha8U z-ttAc>^8EMX+&I1We<4M{_f^dKR(WB(Xs9-SOnY0IuJEeq(CTZzS;ziM3WU0uB0LM zV+JL^r%^jdUFmFZsVkPNdJu4(1wd@T4`o=wb)4eh>73_lIbXJ4+Fm z^55=0rrq%4Zwk2=!ldYnEBfzfu2NIf|)lEjFHoo(-Uz%;{YsR(L)e-x*vFnqG zSdQ854g;d$a&v@-8k(O4Er2iv8Ka%+b?@{sy$*{jdlxICZwfO>^{C92y_(A-v5_!j z$s--{X`xIu@DXY9C(9@Yed56?ON-8bp$Zmk9g0p@wC(J zOv7*f%Xnq;U+6wB*N#y*+`&#Ra>jFu&j1jM`|m34gf|xYd8yBHI~LQCFm5!quZeO;wnOiPp#Zl08U|-^z-k@)p)pJ4cS8Sxn zYGQrdvs>3+EoTnRongX2sM}r_rmC)iQ23g63_+J7Ey*`1^uaRg+5T z5v2Qn8T4vhH!xX%HZSO{DuNlUnYRdJgwTI%ZwC)xH-uyZtemoHZmS-e_M&xo#V;j< z>7@@yutm+O2$kumcQlUZMFFWYiNkDyK}^gxm>OS6wBzqPS({pPu;S=f%-6^4yq`Pw zk;y0anbE+)Y~3C!c;y+1R1ipuE9P~CiSr?%cl8`K?bAA1HgZ~coI*H7->?n1lhiyEfBI(eMb(-PP|qeM+w@1jUCIaDat-Osh-y~b%}gM zq9r}dco#XRBeazylO0(Q5@ZzVQ+H_06+bh%i^619KwldX$9V$wl03?VIli$fDRza6 zwE;Se7H_%{^2B!deuzA_d$XlInTia!pC~t4?CUoUc6*p4hK@# z&z)4*%!0~Z`%@(4xW7}~Vv&N&=o_~)POWlr#H`)NjwvGY<>jBhd;(4o)ebCSBf|DO z-o^cwP<^Nai1yvl#POJE0(oc9MiH|W69yxAy+~3!SS`t(@7W76GmW%7R)B zsRU0h1IpHED}xBJv||ptXF_U_m1FBAK*M@5A^E7-MM~@J)M;sxgOgfr`KO%hIAlFCMg&vKKOTPlp0(^=k_hHPp2QwvOR4mk zLuTqipNp!)v4VX6_u38$e?d5}?AS{$ow8$|W#8bCtBjfj6^AXrgs|t z1@r6pO--F`!e&jYdoS+`ZXY9v>Vw)|#;OX*(E1??^034Dy1+%|{d;E00kM5m@52zW zz~>87gYJHp3+%)1GTmoh&U%_deN$lu%^olDiZeTh%0{Q3nkE&TKX|+MvDPjnUrjpm zw{N{r4LfKA?aM$7R~m}#;O5u-J}L0uv!h6qR9jNTW7XsDMP=EWo`9}qqcSd z+X-Ikf&5)N4{3>**PLpegs(}R?PNOk>{c?P=pm(kcVqk#{Vi&U&6pcRFxcn~kd9mt zJ4sfYwJ|y z=$}F??sOu}-XGZS83l+#LSF527IzKpm)sheFA>wZ)2rK1k~%L{T47`+8~jSHdw058 zvC_l9?UsV9Dx5QQJ@qXn&#^8_8^mWW1*g)3-UXT>Ck$uBwhxeNoq_Hf>w}f1N`Yhx zMY@YK#&0o-C%KZ_75l2LbfHLI~kTqh?v zIjssy08SzxG>kIhmd17r!3IK8zR#MmJ@vr7*{ug59X$5QbSYa1W(~88;<`bW%^{P# zRh~6${7r{8+?KKgDnFRvp>*<4`ocaOWU&P_$gn3M61)Gx1j*@TEZp6rIdMd4N%}u| zvc)_>eNqf+LvZ_P;JUdWhAXdYAD7bbQr1n!Q}3p?e$p;Fa~c;N6XMySxgFk&n}l-? zv7Q}zzKGgb=bWkpx@CX5^=(-_6Df!9cD`zxwavS2KL_r3!?0>_n zmhb>WC$&qtR4#L=0bbppyT>e)k>c zDgx}l)SJO{@B@&CrIW_1m{@u5zE|90tV}e9E(3bFgJZa7<8J&U-PB?!tM#C!;8Bq9 zzhh?q3tK$|Y%Lc!cZ%v6%(JNS#|L!*dn+SAD~RLvbX$VnJ^)8*AE=igD5biP-KH(9 zaNV{NfuTmc#rVrM_WMN+nv2ViEOv20TX4mg{sDqc<$iB~ozJhvTg_h)U6mhzpu&MZ z5moOQ=*tM5$i_nVCRn3W-RS$#Q*(MRGgpISwVKz|A6^De10vy zV+UJ1MNjU7E{ui^s5X^?>-XFfq4F7x8!>DoEaVf5FNySiYbTwuFF0`n@CDu5e4Jad z4b`c)P+=ohlu-L_T|Cs6p|YMeAqO=?IR1P+uvK<9Z;1)I4;?x1T2gy8p!%Vy#D$&? z@!#r1_hGxGim`WM)YBs~%8K#Q+8*y|(uI`BL*p9+>BVYaU zKGnZ@R!y{3)j{kiA{(pN(DtK>vh87hY0}j(OehC6FeG!4+x=Q?T&Dh}WJZ#3n-V-_zUwnw0aju zBu6pwy3K({I3$=`n$y?dLLUH_d%D`_O zy@!Z+Kkz&MQgzQ{p=<{MUJ9NH?30atwdKWmgYASn&Om)@{)dcy8gB{`-9xUrKD3Q0 z-6HwO{zr&9689HHja`9TeqBNX$SwedubE{4FZWO@S=-Y&Jpl&%Ae_5!-jadtUya)% zF)kynz>5Va`6Wd@YmfJeAzK*A#|GY}kZ)O1cC@nw|8FS&|6E?CW2z3oit&vYWvtDn z0ceWBJewdUDkdtuF7p=335>kL+5Y2QTQH9rc82UJ*xh6yJa9Fqr>(h_t9S`zVbK0MS<)AbC0b-7D~~ z*Su6|&9SJdPpaSRhQ2VMrRhiB(m=$F4g(ufpT{;^Htn8Fzzg$B0aKuHR~TdAY1B~8 zc{R+ANoJJ7fA|oQL4R*F{9U-?Xoc5kpc!H8@g{K5U{M5|=wB#%$a}UeV}RHP&M0jM z{{;;M)D2qqOax;e)N#1O`zOo4`TmPv2gXj2>vp?bq8~Xa$eC3%Pqf*I{QUczCEvCH zbn(0^j4Ec<7`>~ITpz6;1SBOPi=E7Sk+B5r>RU!e4lQ8T*F?7^1KjAsYyiO1jfk_s6=k zptExxgo@>h{bXDhpcKTpjmZ|vriiE1A{So^$OvOf^mz-XPEYAGoC&_(=oBa@aBDkwVx59FMs~F%)$DeK0&dv0t{u40pI>%HL+a0&1j|P zHvhB_^iIYtZ!bc7_V;~^6B1@jI_JzgMLKf!{{s70&u2ru*+ZA5N{ber5}Rk-w~9W; zymv7ZDLiDdp8%vLu&oTpAJ4%aeHxG9i;!x-osMxChpYr4uDI}7b6X!Bl|ok@?8%o~ zXz8>Z^$3$i3H^=l*TAkD0$oHJh0od1DB6&c5($_b`0C6XnL4S6KPGHg$15Z)j?2Q_ zfzzut{DRat=C-X~1L>?j$rg>2y;0It|JauK_HyHS!XX<&=0$r-y{_C`wcg=-(06C3 zkL)7}%4A|2-U%I7X*yL!%(RJhEY;{%mQ-Ob7f`q8>Bm2<8Mh*szX-1DR_yJL83)`0 ze(4sMt!40bQVcT)N=1RPWp~=vZjhv#{dc;i6dponCk;xx#=8@UKlfT%gjZ$C-K0*A zc}cMIQu2$cn>vf*EvmaOi>>-|WQw?(3#?TCMv4z(XS=WgC(o4`XzHFzTfySPS)IC0 zcr??>>Qq-5w|@pU8QDf#L+nwx4z;|J!5v64gbc;kx|ljfy8O*uGmDYM4Zhx1?TX=U*aU6YyLy#PvKt;c#(A- z=)KVas4^eD;DhkI!1p@-qFfd`%=dwgAAB08+;#8yDufLYYr0F!$gP&~Ha37r+flFEpNBTo`8U!6(o&q0u5$M&G*X9q2`Sr^wl>xAzl zDFTOtAt)sC6TQVXe`|9SxA1wK$N2Elc%-r6$xX{_Y+c#SS$B2B#5Cp;InQaty^y=8 z^w(xxJkj+LD5D0i>aczs8)Ul7s~{Dj5wb^2Xqy&Ah=>5gWz~8846@lx(llRlm(Ogz z{C7xRq;8lRs+4J9p`#!%GFH7`DXgl`XlY1%Ws&AfWa4tiQb<-{uU z3u?{A65U%~hQy5ciOQ7;$m~Be{YSCuuHJhf1_9!MasMtJ9v(T`b1Bi^XJ%caSX}&i z0b+cmm0+=N4;BMfWv{7~4lg7iB90DAYB(G#S)$H#EH5rP6_=1sbeN0_E13g$N7$<1t=>$X6QLZ0X6e7EOuoHD~b z%vYjJub7C3w2VEOGEj`6h=>&g1*KORL_JJfsoqeGqnz;_XOGZMELU>DPI#p0s^Dy# zQ~ObOA_qgVX6NdV9FF5Xxxnl0UYMsCM?^F?0|q`M3v~M7(N~gz=r9%{=QjZf*p;@Q zv&k{j*9iRy0QVCH9|_Lm>*!0`aYX)aZ9Sq+ubOgV2{&`9+uf+#^LC^_v(eh+vDz1- zO4iv5Lu7lm_oTb%D>GiM+BL7yO1tolm6UqliVMp}YGEJP1|fGLqB@3-zT>)%^RgGO z5Kj$r&PPtqnKv@E=c;CXiqAuz4Rw#QoTXS}#e(^oR0W0Xj|=Y%l=Cjk{#UtQvvK3WwonnD{mjsVBj-NL$j@sWIojImbk+r0rcjU;{MnCJ>+NI7}Vk z|J^I1K64-xRXdkeMN}=0BZj1%_dV!j{8fbnuJjhj%|EyCrY}>D?KF8ic4E!b#v{`h)7Q9q!3rJ3xNrGBVd5Uq>xp!QG(~V zP=5iP82u5vknN?IyThH@cVRKHe&Th}fNiMAprW{IPD{kLhcR@Hqe3k(OEH=1qjGXd zW0TK14LOjm@H&b(QmH@dIX8uUrkSI>^3{y3-~!rVvMJA0ZraFzn89-yuE z#-XvjIxYObLmk1#YhKX|^iAULJ9H$mNp94Qs_C10Qi=8_^9pu0<}jq(sM>1VgFU`R z5%snC-j%xTYRrr?8XxFbwgiRLpxSEvH+i{4<%O5myC@ZYS~B^on=N2y^Bs;up`h3W z&9Ot!KwJ(<1t}UPm98c}rS&Yuv)LJ9c0P$kcjypO=T6*POkoF1i!k@A?^wrj! z;13>rFBtlNbNaI2@F9MyF!`QlgSqgw4-%KuTB%;XB&od{oI>Lj5|)@`!b6x=@e3NiXwG)+GnjTS@uKsty1{|k&qa-dFVpiS(m40*;t@b z!k0&-c-}*$4)o<;j-SLU#1ehds#}gq_4iptK4EA}%P~Utr;%Eo*HB+;Xz~(6&lp*Q z*D8l#`CwX;NZGr%XFV=J$yhc1^eztQQ%&`^ntuPWU^Df2=UXX(^+u(L3?<#S21y{e zmT7;Y$0LW%ko^fMNrL@FSmn;N&k0Djq$Tq%<+uLigRxMl)|+6`cQ^FIarMAyWQy;p z5}q@HDwK|9vsW2!%Q$F%{sK|*M>WlP1D(!Zg5c2{VU6dfPFK0p!r%f;I!!M-hCKI- z9ZE`u4%0o=Z-I;MCOH^`LL~<3m)#BTs%-waQ%&{SlJ0uGZdOJ0eF@daWyZwYIVK zz7SLOdlw*c)STttsUBfYOd{5k{eFY>scGne;D8lygjn~sO}L-FtS7(>05=qn7b0g9 z>5`uazrjJ8(~Nu?<*Fe)!q@5``+?Qoxt6;!y@aLupGLx_@IEJf5}SNp7f`fS*0nSX zi_%cYLkxw-1-vU zr>R}}HJ??4L=BK^z%)!%NsW>D(9f1X1_?wCswTZ;i`o^I8X2J4wAf7iI3rjXaO(~Z zLM+-0-7p{yI^EB)GthV$v0?0tZipVAe!i|h0ehI*~0o3E>-JvRRm_?5EKadK=-J&Yc`( z3Avmk;@%VkjC0IS2Uy<{FLy2!%f+DQB5Em#aoZ#8=IgT$o>fQti-K1!+>vWxjhP=d zj!OA>@XddPLoC!{9^3+sQOk#2Yx!WH>EZbSX$||uTq$pzRsq%Hv8uiA*%EewNceV8 zwrjYifG1F_bXz<#cAAP|J7e5zeX_JmYeH9LaN_N84pME+N1d`a9835~QuPy0Zy>&b z#0bR8NuzPI;p~oM&n1MPgvNxsf-@bJy~SZ%DNoesVy>{R4*lo-5S*(Rhb~lQtYgq+lY0*T-GDBQDOa;7#HmEfH0Qy4{E1EY_mSp> z*!u5hx1}ZR(vq(}FV1a$$^Rui{a9K}?ZsJYU9mCRKU=G}uBN;B&$S2_#g7?^va1=h z_DcjRap7Y+E|`)xQK=Gu@!BzxdhObd74PU(qha zNPC&MjM;vSq2caeS*TIY>XfHs%xIfbhH8@VqVO z&Kjn155>m%!I$hhQc8Xu>YV>XTw3aF6OK)gjRPAD{V07Bp|H^UJ&|Qu&?$Q|;~R4w z|3jr6K5EjelJ%}?iWA#{!Plf`0j~bsA|^a@i8f&oc-)sypTFRczuo(EOu4qv)<7#t zQJwvDn=hH{<4@`cC3%&q@2ZKD`eNHYH>`TD)y;joy)||Gl)ac5-)_OC?hSN#5-gW? zeJ)}{V8K1TWp7e;S7tnHcK3xu2XRrrD{swkP8@w=a#v&tx4gUF0!tBsP-CoKxy7?_ zaDfY0S~Z`Elf|gj3$duUOm3do@XaGujk9(|rUG~Et76Ly#dnNyDarc@@Jmt;+t=>- znk-%qG+)%H4LcDdLnTfM;@F9OGUN0I>nhA~f6{cesw@SXWTZK=Moq+hc!|S6XNgaS zWU6{wyY!IuCOSWX3Ox59fhLmFjhHl9h}~X2!2por`T4i?sfq#d_Gx=LNS)2k8@1ZW zxLd$h?g1M#bGvZFX!NEGt_Y2LN624D+ZG|7-g7grkbKcXVCso`dwG7+E6bGJf%@&9 zCoTDO*A!Oo!BwqOzg@Cp6abV7Uzz^|lDD+DpI;2m5ebU01#9@whP1k?KPiFgRdxNzg zTrpc7q6h-LB2cZjy4S(8W;F_d%8$HhJtDtN8Tfe55d>(=2$#i~A6zY)RsBXT@BB+W zXmiI7+&=$`q8q?g5k7N_t?WaVZWOgkeR?fr--P!?+2=ftb(42^$oH(7b;ZCgBARlG z(2GxgQW@zPjU1S0VjAknw7Cv6HNoXStH4}fhNxy*%#e5b8JrVh{Fv;y8udar$*JFKuWY|b-uXmPz z?xC4lh9e%BpO+TI&_D$IdQctbfV?QClCMwuQizA<1q?-eF7BX*b+o&WXhPvAH}k#s zhhAI;+)=`jFyYrYvM^gjJ9#%n)7(R0z@k$drIS6*&l@rLTw(rg^Fy-7=&Evuim@~C zArpCP<~u6hJUUwTouo%tj%G(k)RF0m==6QfC|F;c+oSF8y3f21_jL_Van?*$WNx2r zqGwmGUzTpO-$i-Rq&mXF@Ot)p6_ZT(!;u9FJFji{pqZi_gN<^>IR*x}Ws8ONnU5>g zlVIU)#v}njC9N8lwjoA|pGYHML_V3)0t@6bhd55RerqxpNZu9yV4dPFag&hba z$vn_P10;vq);yCP4 zhdu;k6I97)91l<*;zs2T`$r=Ea;e@d7nC z6Gr}ah3BM4oy(x-p~*ptqVJQsF9|}#zc=tAjpvPtc}R$lAu>bhEujRqRHLG->=`Yh zwn~zlI!N}>7Zv}o9~@q_y_Iu#)qYje*#aScBf|IW&QaN?fi@Z#`Knm5(k-JErWz9D7VetM%K$X_Fi@20AxR3XuRU& zew%rYS{Zwt-cA;-UUPW4?tUv|?z-7Gj>qNt+>^XBgKg3`^(eRz@zUzdV_<~o4I$mw zl%Ez+vTfq87BPNrRUMQ}HLUmV|4qUdk#uYxT6UXer-07%27Qco1d=Mltqv7iI$f8; zH&bC-hR)2@gaz!*v8dm2!`x81IE)qX~NVlR4HWva7g4C2HkKCSk+JQpDf+ffv-0KHcj7w&zCNe2crk{jKCa|1x%t94S<7DqW?^CAyq2eVdVsMS`_dSZ z7|38<%ljI9;aH(Ag?8+RY@QW#^M^s_2hzzKhxF)!mDWYY3O4VaIaH5C*Bb27RJ!Kc z261on;ocv-tL>Kfi4OZ;F}>_XRXghM&HGPSUv!@jOkEpF;B;quhI8})?l%VSR0q6j z0QVc$LK*feC%Yq<5}V&LauEA^n*A=hnw9HF5j=YxjH#X>>+eAAUWLP!!SDv7g4qek z*!|*glkua-H`idda*%N$VA;e@!eg&|j@nQiBXW~)8P{HYxw+OJW@|{4!TzgCc9J@F zN>mN20XahX`PSUQW&$91P0QF#a%P>Fnq#p z=wBNIpB2QlN(!XU?XPoTjmeAKg;FbL!wI=nLK(+yL`6V!n`K%#!o2*Wsml$q3ZdvY zt_FSYlC$;;%-sU~@^XwSgXOC#UO=WtL|sWl>|$Jl`F7Ll4}^9-!gVw=$Xc;5ZNonw z*K+H#<_ULyL+>~ADDY#-N+PUm0Pi61Gj(7XewiZ<_x&Xo^@#$W~Ez7;>hoqF0MNJx&DSP6wWWGdwHX)gdJ}jvCd=0++ zioB1qbXbn7_Ii{9@l)ceBHk`wFw9VXan4?L^9&)jV=zc|>mwy?zURog28l?sKVV1jNXCd(KqYLWW{Iu!H?O_&+>xyy}hk#^GMfcGXv@8z+Jz zL*3NtgN9&FD_57weM<&`8Z-Atyg^nqlcSCsZMmxSE|SehZ7*ZrZZDP_o-C^NPr_4B z?RE&9)C^I-UO$@=5RA8Of&cQ@_j0{umQ5$o;tDr5@g<}Lztyg8ik zftzlh!+w>Qdkbk{r{GyMuw8Pu$2@~KrM~sHf!X7zmFz-cc zzEgX06I;C=!OD2Xd;wjgw%{5!y=%GOv;?gc6@QpwTv{h3yf1-!BrF1by(q>nk!lRp zu<;8lN{{DxgiumH9W)J1T$66uKmR4q9Q%ka5DmAU#{Jye;@~=^wv|6Ci#ljiFE>9~ zZLVUX{5(CuBlOCc(mC?m_aT)^7y0s2Zw2QJvn8y=a$O_V5a0MgO= z?!|J-O?jb+^fO0;?zC9zWiS(K27*F@1o=Ft#e0rN-sI%lk-KB$t?TsJAnj+I^4P0# z7dXC24IUDr*`-Bg$_=Qaf;K;!oRwY@3ujMz6eVsnItn1ess%9`pil_00{2KU=L=%< zSWkfJooeA0OQ>Z?(jAvaO}C>;Jq9?Mg^KA-D?*Ji334ohF3v}VIkUb>e4y}Xz(({_ zDZrf(tFpm8B5gb5IeQ5}NlcFreqKwpJma)iNdoPStlb?P2^?Wp1qvdk_wGRGJuh4; z!*NmLH!uoT@l6=f5L_%ZPJ*b!j26WliHT$b7l~-i2NG&eJq0^rI(P|JZ%;T>)r+Fz zrSgIwoks3iugwU3M9AYl%ad1dEs7%cA+ad$hh{SjM!X6A$YnS0w`W1)InIs5^@1%~Q3 zHOP#UZZFGq1+}@8sWbWfhc<7J#?yoFWF9c&7uWf@?!p6HtpCQKY=m56nynlE6IbX3 zA;F#G_A?-@7i>JB)}>TXTszR!hbPAprWM>2tGCUAqAHZ*q3HrgP26HPPm~G2+j}Y7t@rY14fKuugM%!Yl{)Cr)C%=i0$)M^c3rU}7T9>Y z`x-cFhz{rjGkWw!r5nk$oPCFXpO@6#Fg484%kA_-*=v9sujQ3fAb4ITk0<-#N1XXb_jgJ1TrOM zH!qwFZ$q+>$PSTVM)&q7r|-{oLP7DRfR?#B4jaW*a{M z+VOYwa{tBAU%Jo-9w@G>M*???A`(B(g!fTr^P)$3^QHjakCDkt#j;&|pFW*@)FZm@ zHUzMro`RH zroU7(cizZ(Ur97;8L=JAq#(BWGy14R5_>?+Z~1d9@zL%fGB$(1Gv_V zR2+^*tZUHfm)Lg!l$!^!`9i%o67Rv>`WrV_+CM;@7WjpmKeRj~&Byz1f}47R|2u9T z-24}AuKx=+$NzWSy!tn8?(#oz^X5ja=#khwrzn7+#=;v}Axkzq+2Gw%!_id1uLz)& z7<=WJMpK}y@^nBD#d6#QPN=&0?{L0A()5bJCtNgvtOa$Ayoecyq*&5GVP;bbki&pl!`||5>uFa& zoD7QSO8_-~&&CKU0!G>}m4f08K!mi|ti-zQH)c9TT3g#`?l6oUG}Y@wmJ^yuzWSy!zQNYyF` zql5$RhKHq|@4Uv+U&uE-mfy~`p!wUs5qRby`>8NerZ3Yb4xhhZ_yc~Nm^D7=iUn{k z0N1VdPVsX2Ws$yvp#O?R)SkS5`jdYL#MW~es%l=rebkinK1q(yQ)qt$;;pxY8ARht z5ZAhW=9azs;q1}s(WOA<4|f2ECNTyohj9q@+WyB!8Rxr@!{<%;r2mb{{YgatPlJVw zE|}>+?V`_>**N}^5D6)FDOFI|6L%Q@h0OnLC;t|x9WjMqVMpTFxyOjy*_b?FfWO5( zH70r?jEPDH&eG~yw~(hs9Ip%Rs@wEHV;5RQmjHIXMX_P5fze-j5+x%)aM(f@`or$m zQt^L}ODe}6X2Vi1F|3yY*l58?PAMy(zzv-M6 zw$R?2w1{kOm3UManc@BLN)T$M=FIQf z*OzHs?r^U=cEt9vuQJ?*C$GFFQF4JazyX{Zgfea)yYWxHyrG>s|GfA=`SPB>`SRl~ zBL1Y-sQxf@-3rJjzq>06TX#`O60(O#jZ_kABF6$y@#`q5M@JrTk5=Pp!BpZH(4s>s zrqmOt(4loh}GFBEX*ACXMstAwgov49JEKJP8OYz>N-zV&e-eTUkem zTe{j3=$i;X^B^CmYjMmEUVlOANo|s@%TA~#;RI5TFp0xR8H-F|qy(fWe6mWsspkUs zPBOf06S(LMdE}{tD=Dcl#`(Fq@3_?$7%C9coaF{n14pz#bL$HiX9d?+8e&o{R^i^B zGkoF73E9@QOA5Jpx_B;o_wcoXCZw%2$igHv9^9(;rL>yyQxQpv>%(->^FvhzjI~2x z+~56+T*VWw2?mX ziOyP4h~PbkEm!ry@_VK6?I~b>2M+Y6bC;(oQ0AagTh((DrhgsDcYMJ&0IA%h=fi8f z7B`)1$E*VvF7IsILJ#O3too{C#k;H;mN|6{DO3&I=mbq!`&}n8cs7-qD^|TpL>txf zo_zc6e)}%04MoDJL-|eM?V}2)q%p`wHJCNq{B?MumxH&C+ZrO05uvXBl}`!~o;(qr zrXQ$FJB|DaaLUhR4ZfZO@1B#Z78`sRJLj34`I}ImDZfLwX*R=5K>smMUr_;soi(u6 z7>RwRem3-~Pb(5jfYkjpep&u`6<6|C?xh!E8>Ly&5oceAc&~31NUscPwaWJGGH7X; z=tey!nKaS5p(8IF#*?u~K!>t+Wcl(y)ie0Q)4JG32Ek>79a5|md3>`jY_o0iD^&od zp6fOg<-JHA&vTX7%HSPv6nr8#cm}w(A?gt`1c|FBuHc)tc3F6Rv0SkzWEatPX!dh} z-^#c$$ll%!wihd-kCp3+#sMSFwSo0tSay8UZiD;bF@z{S{>7QbjRUSJJWM_3THiuZ zBszw$<6Mv+icKGFnC9MV3*FeV8BQg!y=V)H((i_sMk#V3^fDl*16Bow4m%)`t zhOWU;qG@66VwP^=u$FJ@5LV3k3oc_zoqS>+`&v*sLs*$oU{;xdoFbNP>ZEDn*MSi*C?*d&E)V)I0YWXHCN@gJzBSZ+x8wH z;kn8$iJV61$M&{}Pj326!dG4X^4STA=(m1Hcmtwsl3Z2{d#5@8Ke@T`tX_fTx`|e7 zZu9pmoEa-HPzjd6x35eFFe#NpbxqtqACdiwW54uzN5=5!n)kIUC+#(K7@FZBN^tlw zIL{FYsEN4iYMK87z-*pth`%aCxZ&D+`W|}8V}7e@oZsdj^9){``TXsYocn>7tB30{ z*S%*i&ZbVkh(1jmeoG6~aF#Y)6||f0s9Fmw=JBI9*ywI8xTs!mii~W{oN(DRD3z#f z2~4Lq6w17#QSoc0m@7!P#39-Lzui#HP38l zoF=+wgCket69*FkFFqsIUO?|V^^L2s?PnZV*}pilZ~A~M;K!%tlfsietSMEdvzv&7 zG4*LHUKpqQ8N&lw++KExEUmN#Do|(u2<`z_A57d(oCJ1v0(zNP!yV6x$C)H>i0*k9=(NMu;78CbAFpCr8cgZqrQI;9%8fFbtdkBBZ`lG z(Q9?RCOLIV*{Vc|Z?^K_5hD}u5$V6Zl*VtIZFXMLhT@lVLDa1jj@Kmsmzd!BlynN+ zg?QIZckY#Q4tQ(VVX3M`nGa6zQj$GJtm!EgP}I%X5Yj%crRV57Fz?q zY88V?TD@LcS1xm@n_6pdVU?_!49!Q;)uyZPPm9Q4Q?M{7ELfh|5bYKyJBjo5YOHAz z!6pK049>CAdjxD+`5SI`-htcqMECC}@$-t7wh{(6?(~(cYS?$JPpNaBHzh^_RdZJV zbWOPfG8Qy=Bq1({O<>skGVZm7Tt4UB%YtO|y*3O346ktr<4ZT4Uld7dgCcgR2e{;@|sfVLGVs5Q4^#Q5b;sKX%kr30r#SEBdoPJ#*`Y{yP-v}dkK z8PoX_rpPJ#+%72I>WLe?hJ4gybFVZ;4l*IIo|$pRaIEZJqPA^UEMc8m{KmtmA&pC6 z9&s;b;lYdgre;agN7B++%Gb541HGv9!G$9${xIs@Z}I45Z3+5r!($8)b7 zWDWI5iI4U~(P~u>WL+LTQS%-I&mGv^ulWYTSLZ%oKK%+2065E6h&^A+O)D|1tbgKZ z`Jq0pg%Qy?6W|Tn{k^lQlPS=U0(E69c<(#(qps)F{(XTRS9GIe%G5hO1h;G_s(#SE z@xynU_ToOu)F2ixfg8a`_w@9xm!4=H#@tG4V|H7Iamd3>><#AT$5SgnjQEXoFoZB^ zZ2peD$~+wSTKXIhe1M^cw14hCt|as{3u@s%YHF@kD+oV3k>H?F`xCpZXSz1D;J6RY zC!X=D;e*>{?3|bB4k7>5jeq!Ey5@NW=BG!7VIhZ+0Yw^H0bRDoQW*iKX2S6jNWxZ6 zhFs{bW?B3%GCpHMAW)Thji*(0wkT4{5!Oo794u0QAoVlE_B=j(Q@A4;(j*-(4*oJ7 z6%{W(!FwTAps?!-nFd?gx_5>Bt@UK;a&N8$W&3uBZN%ht3+F2s@^flx)Oh^K^3cGU z!VA<&rsbco^Ml%jjG%qnFqIX-tR`Kwk`}41m$BvwF{O4pEI-eU7Rk?jEUo?G+@Sb$@=|Q`> zzDtppq)_LVs$oi!2U7u`1;3>Z%Fp|MUwm9Ka^5+WUFNeC67{Jcy@3R#4=NrgxAJS+ zsLpL(zrCiI0Ju6X;^*KfFLOJhj~*0*-LFoZlt9@ zYsV}?ckU}Qbmsk|M~|mkhU9WgeHs~%QhnIN(R6q22Bee%`|=t$7Ut5sFTGA=eO1B6 z+Aend4D>p-0)oymq8L9|yEvb>@ZFbT^nbi4QwE2JJ8 zUbAalG2|n^63S!0;Ecr(VobyyBw&Xx1uM_7C6Li_fa$B42+IGmtssNYV)SkQly8^> zq2ln$%?4Ng*+I6$b_mC2}pMI$}$9-K@sZ0=!r*kkte7CpogO22Dp*?^d~sdL8=+$bpHuU%QGHq+? z44ncTHUZt$`R$43zbvy{5KCpT!vpC6%l<$LeH?e_zGCnb4HrpeR3x&arPFcvF_d5B zRip#4!-P2qTLAW%#Dto}Q}5%7;=2&gudVxRQy@RW)g$N6GV8=6O_wCH4^;*$7-n1C z$!qlff?4lHm|nTw5&M^y-Fx*jfP+8`;cIvh_n}&mhaU_9bVb0+m}ve>4v)99&iiA-?P4T=Ep7U9(`v`6I9B7xM!y9l;n7e95zSh~G z>pOt@GuvN)`Z@rp$LtFg(o9u4U^NU{GO?2pT>zXFJD_rtj^`+yfo+|eMsPho@8^2e z^e#p2oe}}FT`SiHWB@*0Hb)NwJAA+#6li5<*~<9H#q8m66>^@?#_U4Hl%*hgqI~2w zH1_*kh&rSGP~xLTn0+GVE5A%Un3FWe0#QKvpegSaeZt_=TPOT+l%}9a+XHJSkGwj~ zS2ZdwTf0(sv)0a|&rTrzcft<8lFbtj(*HC|4-;0J}WnEI4XyN#|ykLkm+A{_H2uVi`lH5 zKBtm}QV0lAX!$t(g3o=9bBOl&^jL1UNh>;65H`0F?{X(l_6{}{jbGY5;E#0~EQ{Q- z4nHvabIrMmKPfM$R62n)=IbNxYqnPC+L{Y<6SO(I?U&4FGn$YxA2DsVTANhfK_YK< zQ&op=WB19 zjro%zEfJ_^oO;PHuSQrVbjD|lXO=hmZ(jh2&@(*7EE}w27fX9yp}A%ixmT(qPup1n zIeP;vUbtfTR(#0{aO_y4AADK$GNLH9M$y<}rS3hNX9s70BUbExH6T_#XCwX;`p6NE zmq?W(N4eIssin1qSKt51FOn`FES_bNH4;0O$I4Gt<%B{nX+BcTc6i1W0l3HuWJWp+ zd;t@lXw96e|C{ex=h-=~^Hy&ajL1E*3uLSp)cUXG)_P35-f=J){_!IwaD66*2W)nw z(q-#`0qf6PFuHw+tVLE4iwYY85XW-Pzdhv-$}2pZ?o{^Q0b{@?K;Nu3c&o~SX1Hi7O7w}x1k^!`;!0r z3NG{g0&HH_=6xqqw9U8f&|r_`s{cX3v@`J^r8=MBC>rWZd+;#=WAtiZZ+7-cp=}!t zL_8JZ8hMFB!ODO4?semX$n3@UA@=Wud{N3NkhYGhC!op8cDc<$W!=)OfuQ%Q019J+ zFPavaiKa(-c0qhaZ*@rI5BWJR;1!wEZS;^~Pm-c2PY^4%Sm1XF}6rGV@B zv-hkeOLOE_MOFc$;kAlz_mt5zc_}6r)t>cnDv)@oqvug}%kLNUiWcUm zE|ytJ>ket0w-*p)S(8`s=|a7auRXTQTj!ubT6R%xm`m+8x@H*y#aEXGedP%_6VJ-o zz$R#U1OJwM4uV#a}S_@3@SC_wuSHw>$M)`hK zIx_sWQWo=rdp7znE$)kGt2e-rEH3e#s`k@J5R1SGKBs6*43fGrG^jC}$G0y<_#bpT zfm1_YeRWG$9ChzanV9i!gG3%g*q^EoxFZ@4ANN~TzB+KkaedkSEg?=754fZ^%=8ho zzzz-TCJkpa{nIa)L$6GnF6ko^R^s@QrPZ?F*|{&nIsok;07lQ9UP@negXc#0jb9I!R)qqlu$sRLOr#f=iAz2|D#`>!9((&L##I)ks$UWnkE8yzUV#9YvZL ze)sG>h>8ULOTzV}XQW|u86FI=2UBCUobWE*@l&{8XB#8R zb>uu^ILijj&TI&s%Hr`q=QyPn6s#ZS+XF0%wbNeMO>aFO2k?RyG3^iR8EEX(iXOn+ zuXA1yGntdSCpBdj1^Fmv&y}u#tmIUPc~;)` z)}v1HO|xI=;SF4(v$BalV3B2jif_8Wh-@`<%M$1zeC*VLDlF#9gFf?7h*KdHLV{(D%p(c)w)ZbA*-Aqup<^tJh{|kxt+irTz zIsJLK>)6lNBI`FEObA|SYYY!~*T4EcOJ;%b!NdhL)cv3S^I63*1)f73N>n4QKp%P{ z`U5ft)|bc{jgtl{sJorqnB(QMn31#o&M!CSMbO=FPzQt)A;%UbJ+5aAe|k%UDPFk3 zenE0XJPosP+hKvv3Z9BRH`oDG9Z{PXhpt(a2iL^$rE>MRynI;NwSO?NCIM4bbUu8j zZ)+l;f^z3jg+kYB$yTV&_7v<^LSnniY1QJQiJt}Fx={DjT&E}en3w=(Z*6SsC)JH!0AZ3 zsJFIWhv%ph5SSBsxdFvdf};{6A6^6~W=6e;TlX1XI%iT^Ll*4=92*8iWDE(7Y6Cf) zj%$0r3aQzO@M9z2s}CgH#$|B!TXwIielX8{a;npl0T5UPLFZx-M-%^o>Zb&rMgGT% z(CE}9xiwZWZ(*%D_-jc>cyZ*P-;7N{ek5sriu9)dTz&d*8n&uL2pe>W7e^Nou7<{X zXw;t3k2muFF?i!)VJUwVH+- z+V)lvszgPO0tZ0(%N=mq=w;t0EH&EX8o!%%b?<7n=eKez8ptR*PqYx7{&|13Zz%~{ zkx1#R9`yx;A}tcDCm~(}x?#8X-;0c!KA#YMZ@aVrQ7%tu!fGci`IGdP5AZ6I!0%=CDNYiph8$YQuzrL z?o%1z*aZm+DMzglNwUpOr{TKjTz|Rg@ARr<+Qf zR!4PF9k+KpuU8eaE+av`fD9GqPFd>191baStHOQueXEb>QrI&qfwYH)O|3y9tU|nR zP9hGjt_sb!%r9>Zqhjp=K=TLxs7Q;cp`GCT`RM3Q!)U(k^0HruJ&((_?Q?=4g+CeT z>h!@%H5cVF^ZlNoHugO)v{hMRnCIm}=Eg=C>+K3qrpW3AdR=Y$!NV0x*?L|q1|1JSpyBNcVlyf{P3Av=e`$0Z( z5KZUa8E1cgK`C_luexhaNRXA6(8IJoO)p^>=F;22t9YP-mPV&-#sW|WG(a^67lVNX z#7&y=oL%#;$8Mq_2{v@(h;D# z0qJk!pcF5$X|zmU#Y1fQm8a4BP-aI})Tqa*k8$rlVnFA*lh$XNzKP++$n#Al#s762 zUTy%4>8c9|RJ*5IVaqTGa4c{9D z9|uq01nsZs==leUZ_KiV6*6P^Q!gC$Yd+JLRCZQO_g zGOsCXuFf(MdL~!dy~n$Mdekk!24(TdNIsXYS^(4X`(cS+ty6o#8+_bfh*u+7+EqIqKrBJCB$5UF^IrI^y6e>-rI5 zGpUGrTXA>e3>_b%)`f2JvL>w(Q*<3Uh##$jj62nPJV>iM1UsTGob!E{4$Cdg8zd}1vpji0EXIW&=!{!w{- zp*+r_!YO1z%hrTOKBAyls+D}8Aa!`j;ZPq-dcv?vx(rj4Oz9sXqa*S4XPO#tE;wDa z3esKL)%McP4YHlOjdkq0yoF_WYszMX3M7=!v)48A4(ttqJL8I{q0q4Gn|c_t4T_5z zp3ji*eG=%w?x4n`c0~=xZw)Umn(rcG)Le|=QSS;4OiB0T0R?Nr(ZV-;=CNbVI zCpi!Uu;o~@aAqVzm&gIx)S-Q~m>Yt(&SvYUl&CkbC!?6XW^p#Sg(^}l(~Y*}749`k zHLhtS53flXRONk>x>b%#$iRCHt|`^?w>=IFd55bT;WDz=%=k&37BfmkwmKqB?s%E9 z?%g0gyq9u%%pwDqW;i8PJUr}lSMwI&Gk08+?vF&cqzA2Da%d%&i;EWU5HFae9!~t= z{^Kf68(>6b^p~yG*B&T>I@~9o| z=4*;h*!L2H<#2))z`0xSN!l9lXeogwszOp4!}|t@Y6Bkh)4>4Ap$A zEr@3$_*=#ip_e_$_%JIX*nUy^=6s*IGFGcH+%P{9Hhi6|3r)jQlZBZr(|;iEVsf}l zFk;Bl$WL->Cl)zZlrox%I~z>;A$Q5m9QEkO!1KjZ6XdnOGZ(h*S7Wm?A3-F(Bmy56lx1!L-2pq6o6)K1sSPM#!_1cu61yy zSHfEtgY80~Th*sl#31@7uJ)PEw47X8mvLSjzr^CK&jbc{I0Sjdc@3uX61qw^mI>&E z6;qy$`phx1Hdh$2G{+AYdL|LORVVP>_Pc3*-=0w;0OBqtLm z9T1abnOMv>`6ox2{#YxHv;Muo{E#OnGSWOx7D?M>WKp@LUF$YyYA$V_CNuhen&O%q z`?M@xu|6#Qbb?n*S~kt%i1}O+!LvvhX?nwxV0zc4=qNfYf4-`+X0f$i-QUQvRSr5%7ZGS*exfVXm+*P&c1;aZ<}l=1+W&P-64UvXqU=Bd z$Gp=27>mIF+(!!#^NyX%)TA}Eiv-BZhfWaj7@f{HQDL#Y) zZejiChBLWQk4rAfxpe;V0rS-7Fxva+i>rMJ+*ZUWwU!`_^kWfLcV2C;um^mDTJZcU zO5YCw9dqG!*XOvVI~paFx3H}3J2a$N(?fRd+hwA9$WIXDP%82)ng_OzFYl{LQ6r<~ zUWihXg`!s+hnLmGXZgkT9}XD_vQQLu{sNab%ZMpJ(CPz6z~vvp52LwWWZvGMwk*e> zK7hx~gw=N<%I%B3O;;biKQWj6-u(wJwUEOK*N&gywX4T@t(K;Q<1+Gbk2k%j<#%9= z=L=VeO(C1E;(JVvn&kAMqve&FAHH!v@mwWgJnFN|F<&T{II2tV?N0 zTu=3iw(+$IPG2dzNcC_VDT-FJUhnT`&ebGmb(y+fw9`Ih3)n>Ov}8v5G0btqKVTRF2ed*7%11A)}@#f8lrqwpf>;D_5`bV zX;UwA$+-23J=l>;I!whtbfj z-Nm2bLPV6o!6*sSxMau^UTM31doKL(uRq<2dqN3^(HmU?RAQvPy%pj{-#|%y?V^+SB!?>Y^L5 z%=FIKXpO-IHp&nyf35`106`|#msa^379s0`2y__{kCDezqPM^2nQz~98PO2p+3p3|0EwL$&@sx20-OhCO&;u34_vE_$2!>v zIn}ouMXY#z+j`&n04^@n=`%B79gmy|=R407XeRt1Ep4TlOe?@$$QLh`4%B;75^A4} zJtvNgcst=Tyop5O;+BcoaJuj4>_hfNIkJscc_1iliGpj;n*?4MeT^&y3W<2d?eB+c ztkmr4FSTaZ)KZ*$5*e>b2LnfIdx`V{T5E~Ysf>#)^aG=VGg?Zt9x87#u6wb98Ao1Q z=Gk7xkv1as{BQrJJbunyr0w4awVs*235At}Z`3b>eVDK)vj(es+rm^oKejree}o?F zrAvv>u)(cbHs63^nXgKt%dBD4)~`MxlqLJ=JRH;Dh|9nWbN&SM7j9;{Fp`-O;(8Rv zh9?4eNNs5T0wBS2G)l$VLOktdCs)%0zp8^c5POn54>9rsC7lJ2m?fKcaSp5^`Ozc( zW2w!kw50%|);vmSK|Ye2$Flun|AT+^c|bU1$?Ea3>>HS$$h7PlBjjrxIj`3l%~dW&lkoxFL&0|y3gmylb<*GFy-YJ5hj8k zFyp!Jj

    LD`&hc34_Y9o!_ymdher7egL}_wRWAFY7{;6`Hz47xhlB-Fd9vM_>J<~ z{&-!5ZBUVa3qiBN1_;pVB~P0vN%U)dK3iK)o5%VVBK$KxEn;-v^hXLR0<-6$(|1wl zi@VX;S5s6eZu9a9A^Fgi0Y&Mg-d1~8i=c-+yZ-ew{WXId9se-0U}8?J)r^_%lQTJ~ z`_FIQ{NKJgK9nHhKY7G=aahThvHti5RP%kpG3{8Vkw~?c)x&5pXF-X|&2KLc{_73^ zI_AOr&hmp>P8#HDJ?D2K5aBWoXk*%FoHw8gt?`l(O+8V`pc~LuoMD7aNlqm$iF|HQQV{f>vAp3`CiTt1@TbO5$n+10$xyoHhEunrG0tEVpdhp@rhqyYGtkWc!){m#cBVqHALC7rga6y@F&^_ zPkjIn9$PL5BRt$5*EK+xUh>91w$!m90CSEUXSa7tk1T5#mHl1AQxx< zk2dW5D0oZ(SWsca2>+2MMb8t@MxM5ZN|5A$5ePD?u?zaPCF-mKhu4fhne&-f9qUDG zw~oApYdC`h3*Wl~1D`Tbtk;LBt)=+*01N+#;QPj+`WX*C>6iqh5+`p!eOYnLOzi65 zNlxN}Fu^PTS10UDiK~gf#zF7zaWMOil}SALkFH4kXII#h4`>{%@V9y02LYR2Bi-op z8T-1Ad=m=9#G8E&o1AolFZnmy%6_3ts-*fA;uMAk7% zF4%4s1w!7AP=lZ_pkefg;xIWnYPgsm+b_8EqHwKyNy5Y>wuC}N*MsZ!2DP=I6}Nk! z3-F5+7ph-6>lAvvm>=;oDh_AGz~?Q3H!OXAH2qcUxi2rUx!Z;J zxAYD=q`sO6BPV~zU(i}2c&fvxh9?gY-+WJL>%`x@y9q*mS{Fv<)(N{Xo^49b;1(-~ zC)`CgB%d5eI6*0`R%fs$XwgydpCa1})sOOH^zG#ywPweZCH73q$5WDR^ly}*zy~&O zdm~DU5gHb#>Z=7sB(|1W zW*v4A$EdIxM}2V14kJm0@vH>@&q)w`2?%jH&1aiT3cVX8aUxx7xEykow5sCC!k?%6 zxFc~JKlT?u<5L#5TuM9yH;hX8B6j8@)Za3!#4y_v6}Ko%ivh~L6X9>0aPR7yHVQEG zqkhhpOC<5=l`+5MA4W~toK$i9oTWSl_T0#AXXVbd+f5D{D;gJ_>~l(wGX|sJgf0ca^Jga&D z)9#0sA3Y)0aVXUNjSIolA&4h;(4UE4QqZiHVfnPsSzTMZ-kIm(ESziG_R0y=egwBK zyj*O(rh=+cMBTl}|H+ZbCTh2t-6bV$qg-U>i-#W$AfNFJRppKbJd9Q}?MrC=&?ogB zYfXu{{5K0QT?WY=w^bUy0!N;LG;#bd!SwYPVDn8~=zchIfj(r<*850JE`^mO`lX%n z)2X>g(s!STZ5F>#=Uf9^NbL2Nx?UunsjK4uM`!VE?bI)Vs;)uF=}`MznimK zZ060+9Q-N$DZ$}fS!Z5bqA+4YRxxl{`g^Oyx=V+JBsf%0IfYOTgfHw+v>F6cF9;&X zK9}8Vfp#>D7(&yd0xiGWIgDlxwB)tDh{!oGdd?9{uW-oMFWZ{4xl&P3IH`lqS=tV; zna4w8rX%Tj&L*whw_(K#lC4%lESeOmQ#ApH}|tldV$@#Z~7#n<=9KF4KA(6hE~tln%*!q87H z_dT+NKBzp~n(dBopFizm^(m29wPE+-^5@U@?|p(FpFNM$I12;`W|ff1hfCZ4udwS5XM64Y-Ah}uMYR+~)v69u zkyE3ss=cK~DQbk;E2PVwtu02Wy+ad4(4o>=F@i{pRuHpF2uXzZr#;Vk&-0wV&+89Y zu1j*=anH~C-ami6PSHJed9|XRSAF$QY+=M$%G!$9o-Z_A-tM#&r5A5-^PJ$^@2<8j z2D2ejwA|6{i=iuno^C7rX9D!`D=q4WhnC=#3N7Ftps zsx#+qz4FbdNCOiw31?@6LSC1ru#2=S+QbKSqS9jy<;`Sk38Y=gVhpyxr9KBCPnX&< zE1O|CHs?aB!LhauwQkt^$T~?trcn~ayX`3z2r#i~MNaZ|1`+c>y0!(m| z=~a_XZ)1;Gog!F-w)jjh792AmUbvbS73|EnW*{?lt6y#f7#=vUY3ZO?#v^t*X6wbK zeuxk)&-#HAylS_ucH2Oq>&vl6!>=sklzq=s4?QeT!cV&BA!R&DZaW6>N2R%*4|!PW zy0c>l=o9leWgbh*pvCqZ>~e&oZ(sA#2S>fC(2l9u537A^?Y(h)qjk%+^Ux=snPv9f z;fLgF6ekns`mSN4lw~j$t5af}8Ff+cx`^aE_IR{0bXqQTh2NOP=#Enb&js#RQrha} zOEeF`$1mt*^aCVwW7caqsWL*RT9CH&<(6~pbz4!vEyz3+?h-OK;Y@vYs%4ay3PLh6 z%)2v&RpVZ4*95wIzJG?K2(~qxl318?39-iLr{?w-3=WZpgNn{&WQ2;2XfGHS7@tmQ z6CzR@_yb$o-85SIVjM`B{0A?A&!B^Q7^YLER^xft*%dE-Z$3va#bi;+HO`OIUP?|b z$)YY2XNE?&ubbcqgB}i`04uYJw72Z?zk!Z3SpZ61c4Q(PPkfmVqtjk0#rI)zB*}_R zO)2yd?DS=f{`+W6zUcQ4D`(SuhYt`cW8rRPIPdnG27FG9mV;Wf-Z!y3+m=IHG8(d4 zJ1<$;z;x}r3fi)G6->r9ezg7^xzeA1Z_$(pCEV-^S$S(=S0rASFW-4ws=2JDh;oo_ zV9YR`4RfWJdjD(lihCWK+-$NS?A&qP+2)4P(=%O2vC&CgT0JpIHQNenK@%J z+PX-)mua`3zhJ9a>|hkK{GJrQ{?HxTUa|yb+I|*v;OSazo*cLe-T6|lKq&S^v~jYj zX;I&rQsu2%bF2wTD-yO@!zkD){%u%$Xa9!c7nsH8{9qk7PIm7m+OvscW)s#08`_N0 z`4`Sw$m5by*lfn(N<;Rx}q_SiToA z7+Vbaf+{VlQuDQp?%!Pdqj7diY5VnujZ_NGL8%N0fuay(g%AOe-z~Xa2L?ax9M&E> z7V>Yf>X6;&Xf8)T$D>T7&)#mmOnsQC0&x<~oBm?JTu8}DxqXpdy4+DV-6oq8_H zEk3~xQCo^mnEmw5F@NvS(=|@P7>3(Z3u=GKTiVC>UNHiSej)pQZAV&TL%wtE`D%b|gJ7h-TVIq8F&{R6qcJ$H{y@*I3(N3D;wDciNq1Lc;5yH*r;<-{K*qKg;9LuQoS zs9W(v%>&x)KZu1s-3J~@eV$P;!N=?F3gge|1c~T;+2HU9pDLU{*9mSXtAJ+BS+u29 z$p-cJ^r6B`$C9zZqJ<}qIi@Cu3bK7AU`mq1+7+qVj&@lF%@xm3=_`*vrj$_TndnSa zuEBh5Tlba zTm=VJe6Z4Q?k-!eI1?;o6xYoE8N6am$c>YMT=oIwHV<+~hAPXr8xo_?TjnbcMDzk- z`R;m^5wKvyEbRngCC4HKmY@BG;eVBesxudh63)|@1GF+Sm zQOhhc2H6X0Ys|m!hG2ht1Ttb6hI`O}=chMCd;y12>$L zzUXAAn zWlc10$5Q6r?hCHAH=#j@Mo=x+L|Tzv>iC3l;2~i-mx-(g9fQJG`GK?|>$Ow^Yd#5x z;fg#$%xQkYcK-B=S`mBWL}GJFPgN=1JmE5=(am}@3RhR^8r0ls`by`9wf)_V#m)CN z8mGa-m1Wn5Ye!Mmm|v8rmD~owc{H`g7lL;PWx9t*pI_qJi1L1WY{?>FkT&Fem0xq}0NsoT zEjf)mWx6+{Fy)rw$GOLL!@NN!?Cc#tH{_Etx`9Wv{{n_HTfZ23A{TQ1n5x0Pb3OMH z_wat^uKj`>y7XiyZNethQC1&*0u`$6HfS~A(a&SQ*IAvd2bZlK&)m=s*%^xHL*^$- zSKaF|&;J!28v22gu zFj_vhcBHieC&tMb;8@Q^^+S3dfK0|q!vmjCM827CRT1xyLRk?|clP=X~V_D><)MsA)NDw6{Lg(|4LUUJR*=nspl7+zZ~eHO-J<7&Px zG)-~Sv_6+3;J3^`eRahK=~~PE4xbjO!#=Gh zD(T&oE+_ZWv=SeE5g-6hsLLCfio9veEbZ3Hl3?ojya?Q}|9x^041+>E1$c^?o;EEV z!a1Y|&rg}1x7#jTl|pDwt4OQA91EGMn@*gAKh#o)V)mYQdcc>_(~iW^GrUzoZs^=? z2xyeLe8$;MK<(SblCFF!)RGw8hFOPM8B|~Xa%p@6e-SdzXFEclOs|{G7nm_~8H3O} z-9P2Wgs!1X8T-^p{)b3Zv~y7yd9Hx8HyHvh;~ots z&wKV&EueairLRczPfeL;YuuGfT1=ov#2WY1#hyeu-8RMR9+^BseRk~f?jS=pWaLFi zGQ?1&=1U=e%yoyujOEC8cv63od>M|xgF#>R`av^RZqogO*mrF6|5Pmg5-={R z|K!DlnsY3*H=qDlfTS7WnkXr6!XR9F#+8u|skv2OwcgSsU&&iA@87dI#FXi#GOMCfp zd>U(XLE-<{l^;KewcF9B9A)jS0||jYVxhx)({4j zhoW?UbTOMtLdN;Jg2E$i87psS$d#iG24~p;7br+UJKtozUOy;!bnn5bP|WTL)qDRr z>;IY)KVQg&?wB&>{J*Ryc;Ax2oa|q-LL@Xc>B^sOK;j1;r#YfiC*`?Mox4G~+sIpX zE+liXDBI6(ET9P9<=}0>XF-!+Q61$`TKo-8UfAG(z_%lnM+V<6$+Wq*r3Xkx?Da^f2a)!Yo;mF1 z2drVyWu^Qy;Y$KGDz6wyO7He6Nlx$PU;zwfRkI&p|Ht7kemq)B56TLHoZM^*dOhxg zXdW7Eb8Eo{ytQ6>z%;G!VSO~xt*$AcAm2a>BbS=sibHa3qfpN^*Qf7Wi9j)3NtS#``YN#5Lf#x+* zIQ)in3dZ%vKbg(j-Dt#;Zk&#I7ISPh`V-HMmRHt2GKCDks5i=_U8Kj=@0c$buYYw$ zAydhakQ14U3-+?J#+jjVZB-Z>QxuZC_qa?DcBT?L`!IW}(%aM_)*&>-g^DLlK-7c(8LgjZ zT31|!zRZ^0?@vXP!a2J)-|ZO4K;MkidwuUrzZ^m6JhopSeCm<-8UMt-7$1XbO~@aX zGw}a&ss7rvdNP3(_N?M$c0b3~xx$mHftw#BOU!iT?J1WM?MRmyPwhCk0 zY)F6|dF-`y%#Kz2(WV%?47q?}M;6qMnBk~DKC(6*@<^$JJo-e>yKO27-ru&(#P(a_&hV`s{(qX{k@*={>4k+4!!ZBeP(;wjxy8rD zQp#bm>JV<}dymN7SzblDIn&w@bV)2W{?q~0XMX*fyX7ZV-%D`0ce8{3pSEVgfDr>i zL0Y4$1(hVcHxOxBAp%(#xue-_ovbdiKrb%x{L!qz5OfB&=EX&u%&Hx^JPb-|z zms|GCGqF-WiwnKYT=KKtoZx0Znz4n{ysO9EcI3ad{6zNR`5#ym;*)fp89C zV94IC|EojK+qI`LtAR9*$9h$xATx}McupTKaN2DQJ-Z1f`1<*c4%a%eBYAs|<;flB z(ZjeYioXRe?H`S2;^Wt(U5VGPdes^RHARxE1(sOt;&mg|a}Gg8U}Bx)H^AuU$w2=(8BooKoPcgwJCh^3cApnBuMP~BPVdq3t+Mn4 zADcT}R)x&+9BIp*bRs$o${>n}ZBh7z$jUvIUJZS^Cys_ zDhi(KopB?sjAGPRVqN?Q=lbdT;m)ZR;q}({iv+0nVe0yNmh~T2^6qNqmmY1`Tn}E! zzfQvs5a5;Eg(jgQUJkn%sM1w+(%KMsBk_$yh>?S#cSeukTbddd0^AT z)@n27_x111*BQz_6DsRPRgyzx+Cji%#0D=AQ&A&iA(^1t-!N4O^qZ?*IoVw>T`X!u z>+rlGgi`S1fyN)=0k>=Ur^DFDsD*-QE$t#Z5C6rNj1kxA?BnIHEwZPiAd1@_3#^}5 zE&T)}wmDFE*kw>PB(J#ZS!yKDg|P_|_gmdXDYriUhSE@1bx1!io6o^gqHa3ZLq01U z6&S7|8i&gU{HJUE>#rG-A#j zu<)N=ayPL#H#^tv>gj$Iqqs>`s>ci>jXxJE54D=~Qcrm8cDX*^BFu@bAUMb!_z>k* zCMjLIjkg2DcgE9LSxhU-ZwQ!;&7mE+Ln^1OYUd!g1CdFD&0O zab9-yE7XuLiy&;CddG4zf)wiM^8tmTJ)du=II(-6fE?I@J|^A_8P@7b z&FF5MY%96P6;)heq6e`niU)iriIWAj^5gli3^(b03RBb-tc&JFcBHnWUXq;duw0f= zRPo~4koA%=K4n>eN6Bz5>E(f68PoiWY+AxkUn?#fb>5u23i`qW0KQL4(zaX;?k7~G zuO2Tqa43!`m3!&==In(@UE{3=ini<3ES5u!!+cny1zVNSIX*3GzY2*UZ9*rVYeg_x zBoCD=IwjYA8naaJ`k^~Qqap}&Qjs)Otz|5w2?s5i z_0HVP$b)IYmlAVB>;m}P`T79oHg4*i2BhZeA~$ZW`S{&|kOBBjHl%DsSenzNl2sbA zxI*_n@n;@m$vqe&)*6`TC3JL7wc6O!?Kadf)$z~}S=NGS80#6|@9vaHH`njKU~e+Y zS0LGR4EaTAyT;}oS!+}mDT2_`mMGT;KCnH$o0B zSRKL~N!+A|ZW|SI*UU0YeIu8JX=*~53DvjS0eyR=$hG3oc@b78`hBG;9 z6n#ndN~P8`^Umr1WhRk<{#4w>e}4P00ke%Kc=WrY(5^L6j{3M_2<4!<)4V7VpMUlN z2KbhE-}O;HAPn`adu&&K-3&lDw=S-3a7`pN8A=BU8_P{k<+#YH^7E=yJiJi*qUEq* z%YgGNnigYsUnW5w=eSxwg|_;mcC!%mhSzv|e?W4JSA$B~DlQdijI4M# zlvH$WBo2U8j>*`C&BC&ha#c*-gYV(3p?y|;55HB$Vho_M6;Etvihmh&7Lp#qqOc`@Kq!YoYc?&X@t2rtsg=yM%TCw7uPs@CAbA5W$;T zoJg8(eBka(<`Om8P34B7hCWd>29r6nfJvM3i22_py($SZJc<>*%lR;&N^H5GlqZ%mr3mDP; zxtoIe#9JW18=H9@FRgu6jb@0okN&7EeaH?pCIGk@s!FeT#MKYXWs7)nDa#?#rNC7T29&6`YEM*OwH>sznS$OEpx!3cSLt!cv z-$A*gfZ&s8+7+*5TxXX93nCF0^l=`Rra9(3+cSQ5<{I}}VQYSI^r`IyWerRO zb7S+_2AjY?0O6CupSvt#m1Lw3hx&Rm+9BLQEbyfA{*G(ILe4Hjn5o*=@s?{?7^gaf zkvck?D3+z`&M?x%4SFbAnzYkjLw#3iWM~tII^<8>K$-P157}nZCmP&!jS2Hy$SJ8j z=iC8G-}qql_*q(Ug?+QAN3GB+(Ev@N8}zi=$mXfY?M_GQPB~;%zZPs#8&b9$UR-e# zXCiqv@ct7Ez1lMXfOkGi@CPC|?fC{n15pGz+Z)=-rOM=)n~a`MDpV5l{>*ZEd=QK5 zGsir(lRRz<0qo?~eW!%pRXf#q3X@!8x=PUoDG|!(SUqMGC4h#qGVm3p7Hit=S2Lc9 z>`JO=MV{Nz-y;oCOO;uxLr`aZ6tk?UYWD5OfGjjm34JV$AZnl^YHI+E{Hj5yEY~lZCYOnlu@UDu8Rp5OTmr6R z0oe(!N}+DwTt3mlnC{X&rPT%dOgJRw>j1~5=EQC@VD+MnM`mO-TumUCgYN8_={Fu8 zV16jlTJw5=Vx*Z{FCuVYj5^)>eDlj};Q4Adew#780E{SSy%_}(Ron%jN{?bAb;u~y zNy4@kle_g=;}Mmvrw%b`b%?JR-!hB-y5Ix++0&6koI=39M-@Yq76v=8+wi8?ze`ktA$aa#Flp=w1Rk*F(u$$_TUsR|auEk+ijkgwB0i#8U>{ zQf}^Z61vomimo|l5=bnB&TD$dzA=n~(=>_ndQ%CWgDs1@N{a|)RE)N*I zg>S><)UG8%sc0#1AFZOvAzlR1PHRv!=cD4MtydH6Uu123l2al7RwVtI%{k#x5bI~4 z4lzZMb6A=@8NLocXok+1AHe7|B#H@mnX*!G6Vco?sLuUhunZv=iyad zzCl9ep;Y!m#;RQJk3=M@Zq+G=GyP#afzYQP4zu6qbvyF@$+eteHbh*#D5>~l)bs9w z6-Ny=Me7-h;t-X1W%uBW7TQC>_80T^?`^iIHNz7?V5X8<^`$x1=ML@VO^ikR8+Xr_ zlt7mb+|X)slJI()-iSz3(@6<6#(DeJi7aO==!=R;&h2Q*?r%BymKr!wrdn#zHH0h& zY;({m@$GYh8M&76QkU_nAMZI=>9iee5u_yJ-V1{Qx1YVdWY8VGEz93_kk>b1WX6-5UCIt}N)2a=`_w%y_KEZ}HRZ z`+)vxCk1|ytAjg9H#(n(TBB+)O|H(e!haN^dcXtzhQz>Oj_f$Q`Jsz!NbRDg_-BaR zt#Uf3#x0s_=EUMswe|ps!aL&DE6?|drvLHjP3@Z6ip%a)ZBjf0$hdTKHaOTx z%&O(db;aiQ6S=^OP2;J7a|&PTFZ3p5u5Ue`J7|{f9fCMfLTd zzZj75Y<0Ozc6c#PO{VdUcz=7jo-G!)I_tXqHBwl5hqXjA`5PP9#3Ho61kqQv`Ygt_rux56&UUzM_kiTb{8Dvuye$h7SC}YgrhcnS zi{JXFG&N|eUax7|-HXwgSS2|yzb3Zir8~NwAEXRpBv1>!G;@nWsndQEFhJj=;wEXGsA$2imx#_E9l53lrW#NR3gGLFx>yIG zk^AnlREzBJm0@h|MlM4#4+W5(s80ahgkNWyJKpcz;%s1UPaX?eTD0t$?x+M`sa%m+ zQ~GuC?byy)s$`9KY@EtY_g^~RRzGZ!IVrX;73Co9P!!c7yuH7YZqb3%WOOCIhVM5xy&kGOZ8NSz-)VCuyrh%1hH|e1ndd{Z&gC7lLSb9jh^) z{MQFXxANWCk!vv473_Ueb|ekesgnD!)kWNwIPLNQ3*0k%%3fjMl`TFnN}xD}d{e&chZU<# z?TZXXOm!R`W?6f$H|Ez&)m%>mDXr_K+B4aMaw!IwiVCUJ!*85z4K|?IP@xdPMgxZd zYQgwsb>k}1FKXj?9ZlLdAN4;_i{h^84X*xYWn|1h&Qa<6O9BQ`U=x8Me@q_8OZz0HjO`Z&;3w0MZ z6>Q>nEa#|rMbvwRb95)Wvr|CX@LN;K06rht!?CrBgA=!mPfsd>rzd|Sn)jRmCXm57 zn{QVvBMIu|h2!t0u|NfW=E)X&cPIFndWktHNcx6$796&MyB4tb-siZgV|l1VooL|A zqV6^nyUrcy2LHvgVL=MAa|927%Yhk10{5@oVlM>ZSspr(_@4q!j>0$ZpKtOV@iDHt zyII&x)6J&KfBeGtRn-^06hUa<%L(1zc!Ir)ENv+{BHSj+HDdnyj2GOE{B*1xiONU}2Inb_&O3`$cNSscIe<=#c@t zRU^o`XhF#NkQsl`NW$hj(LB`XsHGouVK^43BspvUL7-(g9J_$Krq${MIFCNaJ8)HWt9IKHBJFCJhr0VUzwcpgT&saPj|CgK zDq#1suBy;eFF|jlo^u&c2SwIbz&Vy2J%2B`ukj&VXv|god`;YN99Fu|)MqLPuH|vn zmNQ2b*;%f_L4ty(z|QcE6)jr<_w{gC&AEj{d_GQoAO)YaYP^= zLWt0r`bX1q;aL}Pv?hNGQg&d-fRr#%gwu?+3O3j7=2n_T2wnVs`^-7fhQ&>!-h$L? z+h-7{o7(R%_Rs3P(ETprjtnj&ZH47V2DBN6uJ0D4CB}D~td8nK;wJA^#>Ve3SPw2wegpP+qcO?UYSLoH_M}J>0{&hT8H_UgYlj z{vusr=b%O$4GK|+qhd~dw7~ZbV~3* z2A#L&ef?UE20BvypH)|EJV4czl^#&wtTN&#z`s*=o%L@nRb`b|Q*#y@asYE%!CBHd zXyaS>=w4Q(9eV^k<@a{KG^)#byRkCur^F0p;}3!kekw^KS#t;7fqm#+FbzIwu~HjL zxxLeiZyaBhn3Z1$9w*&1u74BEK#BRb9{-0}Y;y!)X@JMGzZ+wQk&S){oE^*Kpg+BI z#~8b5wqO8$3(^(1a!y4P0Kes54joWmcR)2OusHE4BD(YkNagxhNQ_Tm0jm0qC^frfZrd$;pTbkA^7on02!-TJQL>%qML_$U9} z%OCUIsQ~X~4ZC(S&WFhkRDJ)-PlUZ^TMru`0#_vj9tEt(?#ye3=#s_j7b|K7Mn zU7@f{+W~h-&^|eCfi$LVj$wn>JsfDcsH43x;8z3&bo0#PMGK?k$IFrz@JU^Jt?6xV$^?WusGneOYRsmJ9-Q^#^hZQ3;}7?N2LSY-w4& ziU;ov0vs>p1C&BREIeal8l&c~LmI}Ey6GrTs$Lz9BtT#LUlp$6h7y-)y{kiebs|#{ z&CNb{AnKO0jlVe<|4P3AFRD9t6hd8~1(7)Qv%MWTk zsW^!FaqJ&c^6#zh+S_jnY%{L3D0m=9o9DUv@WlhYFXTKABu|;nJMEr2pavNh9?xU4 jA*F2fF&Y57-rg%b Note: The trace file is fairly large so it can take WPA some time to finish opening the file. + +## Analysis + +Now that our ETL file is open in WPA, we can analyze the results. First, we'll want to apply the +pre-made "profile" which will put WPA into a state conducive to analyzing rustc bootstrap. Download +the profile [here](https://github.com/wesleywiser/rustc-bootstrap-wpa-analysis/releases/download/1/rustc.generic.wpaProfile). +Select the "Profiles" menu at the top, then "apply" and then choose the downloaded profile. + +You should see something resembling the following: + +![WPA with profile applied](../img/wpa-initial-memory.png) + +Next, we will need to tell WPA to load and process debug symbols so that it can properly demangle +the Rust stack traces. To do this, click "Trace" and then choose "Load Symbols". This step can take +a while. + +Once WPA has loaded symbols for rustc, we can expand the rustc.exe node and begin drilling down +into the stack with the largest allocations. + +To do that, we'll expand the `[Root]` node in the "Commit Stack" column and continue expanding +until we find interesting stack frames. + +> Tip: After selecting the node you want to expand, press the right arrow key. This will expand the +node and put the selection on the next largest node in the expanded set. You can continue pressing +the right arrow key until you reach an interesting frame. + +![WPA with expanded stack](../img/wpa-stack.png) + +In this sample, you can see calls through codegen are allocating ~30gb of memory in total +throughout this profile. + +## Other Analysis Tabs + +The profile also includes a few other tabs which can be helpful: + +- System Configuration + - General information about the system the capture was recorded on. +- rustc Build Processes + - A flat list of relevant processes such as rustc.exe, cargo.exe, link.exe etc. + - Each process lists its command line arguments. + - Useful for figuring out what a specific rustc process was working on. +- rustc Build Process Tree + - Timeline showing when processes started and exited. +- rustc CPU Analysis + - Contains charts preconfigured to show hotspots in rustc. + - These charts are designed to support analyzing where rustc is spending its time. +- rustc Memory Analysis + - Contains charts preconfigured to show where rustc is allocating memory. From ddadc67423fcd691cc6f3f4e3313ca79761fa10e Mon Sep 17 00:00:00 2001 From: Chayim Refael Friedman Date: Tue, 9 Mar 2021 19:16:46 +0200 Subject: [PATCH 1437/1812] Fix typo: suceed -> succeed --- src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 352d826d3..7385cefb3 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -106,7 +106,7 @@ If we make no progress in an iteration, then we have reached a compilation error (e.g. an undefined macro). We attempt to recover from failures (unresolved macros or imports) for the sake of diagnostics. This allows compilation to continue past the first error, so that we can report more errors -at a time. Recovery can't cause compilation to suceed. We know that it will +at a time. Recovery can't cause compilation to succeed. We know that it will fail at this point. The recovery happens by expanding unresolved macros into [`ExprKind::Err`][err]. From 0b1bdbb183211bb5803ce2a26f4d9abd13d21ddb Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Tue, 9 Mar 2021 14:00:12 -0500 Subject: [PATCH 1438/1812] Update cmake version in prerequisites.md (#1077) LLVM requires at least cmake 3.13.4. https://www.llvm.org/docs/CMake.html --- src/building/prerequisites.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index ebbe13ce4..f7f47d40c 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -14,7 +14,7 @@ If building LLVM from source (the default), you'll need additional tools: * `g++` 5.1 or later, `clang++` 3.5 or later, or MSVC 2017 or later. * `ninja`, or GNU `make` 3.81 or later (ninja is recommended, especially on Windows) -* `cmake` 3.4.3 or later +* `cmake` 3.13.4 or later Otherwise, you'll need LLVM installed and `llvm-config` in your path. See [this section for more info][sysllvm]. From f83c57bee6b5ed467d1f35d6680982b5af6921f7 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 10 Mar 2021 11:56:51 -0300 Subject: [PATCH 1439/1812] Fix typos (#1079) --- src/borrow_check/region_inference/placeholders_and_universes.md | 2 +- src/contributing.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index 20775038b..e1c28ba4c 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -21,7 +21,7 @@ fn main() { ``` This program ought not to type-check: `foo` needs a static reference -for its argument, and `bar` wants to be given a function that that +for its argument, and `bar` wants to be given a function that accepts **any** reference (so it can call it with something on its stack, for example). But *how* do we reject it and *why*? diff --git a/src/contributing.md b/src/contributing.md index d0c77edf2..9db77fcb6 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -191,7 +191,7 @@ git subtree pull -P src/tools/clippy https://github.com/rust-lang/rust-clippy ma ``` takes all changes since the last `subtree pull` from the tool repo -repo and adds these commits to the rustc repo + a merge commit that moves the tool changes into +and adds these commits to the rustc repo + a merge commit that moves the tool changes into the specified directory in the rust repository. It is recommended that you always do a push first and get that merged to the tool master branch. From 912aa00c3bd16c7cf38fbfe03782201122791787 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Wed, 10 Mar 2021 12:04:40 -0300 Subject: [PATCH 1440/1812] Adjust a bit better P- label text --- src/contributing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 9db77fcb6..c4a3fe872 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -482,8 +482,8 @@ appropriate labels to issues that haven't been triaged yet: that this issue is specific to. * Orange, **P**-prefixed labels indicate a bug's **priority**. These labels - are only assigned during triage meetings, and replace the [I-prioritize][ipri] - label. + can be assigned by anyone that understand the issue and is able to + prioritize it, and replace the [I-prioritize][ipri] label. * The gray **proposed-final-comment-period** label marks bugs that are using the RFC signoff functionality of [rfcbot] and are currently awaiting From 674f73da63e127b143adbb613197f5630d68105d Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 11 Mar 2021 01:51:56 +0900 Subject: [PATCH 1441/1812] Switch from Travis to GHA (#1073) --- .github/workflows/ci.yml | 77 ++++++++++++++++++++++++++++++++++++++++ .travis.yml | 39 -------------------- ci/linkcheck.sh | 12 +++---- 3 files changed, 83 insertions(+), 45 deletions(-) create mode 100644 .github/workflows/ci.yml delete mode 100644 .travis.yml diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml new file mode 100644 index 000000000..c3307bb74 --- /dev/null +++ b/.github/workflows/ci.yml @@ -0,0 +1,77 @@ +name: CI + +on: + push: + branches: + - master + pull_request: + schedule: + # Run at 18:00 UTC every day + - cron: '0 18 * * *' + +jobs: + ci: + runs-on: ubuntu-latest + env: + MDBOOK_VERSION: 0.4.7 + MDBOOK_LINKCHECK_VERSION: 0.7.2 + MDBOOK_TOC_VERSION: 0.6.1 + DEPLOY_DIR: book/html + BASE_SHA: ${{ github.event.pull_request.base.sha }} + steps: + - uses: actions/checkout@v2 + with: + # linkcheck needs the base commit. + fetch-depth: 0 + + - name: Cache binaries + id: mdbook-cache + uses: actions/cache@v2 + with: + path: | + ~/.cargo/bin + key: ${{ runner.os }}-${{ env.MDBOOK_VERSION }}--${{ env.MDBOOK_LINKCHECK_VERSION }}--${{ env.MDBOOK_TOC_VERSION }} + + - name: Cache linkcheck + uses: actions/cache@v2 + with: + path: | + ~/book/linkcheck + key: ${{ runner.os }}-${{ hashFiles('./book/linkcheck') }} + + - name: Check line lengths + if: github.event_name != 'push' + run: | + shopt -s globstar + MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md + + - name: Install latest nightly Rust toolchain + if: steps.mdbook-cache.outputs.cache-hit != 'true' + uses: actions-rs/toolchain@v1 + with: + toolchain: nightly + override: true + + - name: Install Dependencies + if: steps.mdbook-cache.outputs.cache-hit != 'true' + run: | + cargo install mdbook --version ${{ env.MDBOOK_VERSION }} + cargo install mdbook-linkcheck --version ${{ env.MDBOOK_LINKCHECK_VERSION }} + cargo install mdbook-toc --version ${{ env.MDBOOK_TOC_VERSION }} + + - name: Check build + run: mdbook build + + - name: Deploy to gh-pages + if: github.event_name == 'push' && github.repository == 'rust-lang/rustc-dev-guide' + run: | + touch "${{ env.DEPLOY_DIR }}/.nojekyll" + cp CNAME "${{ env.DEPLOY_DIR }}" + cd "${{ env.DEPLOY_DIR }}" + rm -rf .git + git init + git config user.name "Deploy from CI" + git config user.email "" + git add . + git commit -m "Deploy ${GITHUB_SHA} to gh-pages" + git push --quiet -f "https://x-token:${{ secrets.GITHUB_TOKEN }}@github.com/${GITHUB_REPOSITORY}" HEAD:gh-pages diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index 1d6747258..000000000 --- a/.travis.yml +++ /dev/null @@ -1,39 +0,0 @@ -language: rust -dist: bionic -rust: -- nightly -cache: -- cargo -- directories: - - book/linkcheck/ -before_install: -- shopt -s globstar -- MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md -install: -- source ~/.cargo/env || true -- cargo install mdbook --version '^0.4.5' -- cargo install mdbook-linkcheck --version '^0.7.2' -- cargo install mdbook-toc --version '^0.6.1' -script: -- git checkout -b ci -- git rebase origin/master -- git log --oneline | head -n 10 -- mdbook build -notifications: - email: false -env: - global: - secure: YQX/AWq5KsvAFYqcCK6c1DmOZX9EMrecBM5qnc4uE2HvEBS+x0l8xatI2Nv8U9eiasZYfsqmHn0ANvxu6e4oqL15m4cVsdliCzdkrPsDapxTnwwJvMQg+yHZiEd5BPlaDQt/wYvP8QBXgQsXoAJKrfAS+BFsowBFHt/LOFOunbAQrtQZqwqrnI6+xh+2TRMckws/VcTLRqwl3pyEyfacJhbbv1V3gJh7Y17hELsgsP7+7cMXT0bK6dtf7a9vne9Hsm5fw7VeMKBn1/dJ82fyEK6HHjkjdw1/OoY35YVyNZ/9ZxP2u1ClEXzCRJQ2CvKr8Tuoh/AuoL0pwrfhOTaOuWU0QZT4QBqjTimsgBLqiJicMiSndgsXinLWvlDqrMS1XfleqCKqAQy9AJTCR1LnwR90/HRxfE5YDAL/mbc0Su4jj+l5Zv3UE8vUqFE34E/jzip17JkDT5aMkl4bgW65lqJE7SLWl7gXT7eYbPEtQZoucR1hkSsBu/4YTvcxSlD98spWZ68mWwYyjLJSQDES+GefUnHJ/RbBVl9pW+sL7jXJ+kZ/NBCtCIgrkGchudEMDEvS6rcOzwCejxqL1of0jYHGopkBXSVHOPneWIdNeKXwBZA9hp0yKh0sWwrKHrA3wYhS/kF9uO19l/RnSTXAfApYR/yJUbYliuMJYCgNeKE= -deploy: - provider: pages - skip-cleanup: true - github-token: $GITHUB_TOKEN - local-dir: book/html - fqdn: rustc-dev-guide.rust-lang.org - on: - branch: master - -# Only build master branch on push -branches: - only: - - master diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index d329a7164..3d70432f5 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -3,22 +3,22 @@ set -e set -o pipefail -# https://docs.travis-ci.com/user/environment-variables/#default-environment-variables -if [ "$TRAVIS_EVENT_TYPE" = "cron" ] ; then # running in cron job +# https://docs.github.com/en/actions/reference/environment-variables +if [ "$GITHUB_EVENT_NAME" = "schedule" ] ; then # running in scheduled job FLAGS="" echo "Doing full link check." set -x elif [ "$CI" = "true" ] ; then # running in PR CI build - if [ -z "$TRAVIS_COMMIT_RANGE" ]; then - echo "error: unexpected state: TRAVIS_COMMIT_RANGE must be non-empty in CI" + if [ -z "$BASE_SHA" ]; then + echo "error: unexpected state: BASE_SHA must be non-empty in CI" exit 1 fi - CHANGED_FILES=$(git diff --name-only $TRAVIS_COMMIT_RANGE | tr '\n' ' ') + CHANGED_FILES=$(git diff --name-only $BASE_SHA... | tr '\n' ' ') FLAGS="--no-cache -f $CHANGED_FILES" - echo "Checking files changed in $TRAVIS_COMMIT_RANGE: $CHANGED_FILES" + echo "Checking files changed since $BASE_SHA: $CHANGED_FILES" set -x else # running locally COMMIT_RANGE=master... From 4c8fdcf511f4aedcd16981ee936256d7ecc65a15 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Mon, 8 Mar 2021 23:32:09 +0100 Subject: [PATCH 1442/1812] Add stub about the THIR --- src/SUMMARY.md | 3 ++- src/mir/construction.md | 22 ++++------------------ src/thir.md | 39 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 45 insertions(+), 19 deletions(-) create mode 100644 src/thir.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 241178864..3f14c2642 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -84,8 +84,9 @@ - [The HIR (High-level IR)](./hir.md) - [Lowering AST to HIR](./lowering.md) - [Debugging](./hir-debugging.md) +- [The THIR (Typed High-level IR)](./thir.md) - [The MIR (Mid-level IR)](./mir/index.md) - - [THIR and MIR construction](./mir/construction.md) + - [MIR construction](./mir/construction.md) - [MIR visitor and traversal](./mir/visitor.md) - [MIR passes: getting the MIR for a function](./mir/passes.md) - [Identifiers in the Compiler](./identifiers.md) diff --git a/src/mir/construction.md b/src/mir/construction.md index d2c5a6f34..d9f99be03 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -1,4 +1,4 @@ -# THIR and MIR construction +# MIR construction @@ -13,23 +13,9 @@ list of items: * Drop code (the `Drop::drop` function is not called directly) * Drop implementations of types without an explicit `Drop` implementation -The lowering is triggered by calling the [`mir_built`] query. -There is an intermediate representation -between [HIR] and [MIR] called the [THIR] that is only used during lowering. -[THIR] means "Typed HIR" and used to be called "HAIR (High-level Abstract IR)". -The [THIR]'s most important feature is that the various adjustments (which happen -without explicit syntax) like coercions, autoderef, autoref and overloaded method -calls have become explicit casts, deref operations, reference expressions or -concrete function calls. - -The [THIR] is a shallow wrapper around [HIR], with datatypes that mirror the [HIR] datatypes. -For example, instead of `-x` being a `thir::ExprKind::Neg(thir::Expr)` -(a deep copy), it is a `thir::ExprKind::Neg(hir::Expr)` (a shallow copy). -This shallowness enables the [THIR] to represent all datatypes that [HIR] has, but -without having to create an in-memory copy of the entire [HIR]. -[MIR] lowering will first convert the topmost expression from -[HIR] to [THIR] (in [`rustc_mir_build::thir::cx::expr`]) and then process -the [THIR] expressions recursively. +The lowering is triggered by calling the [`mir_built`] query. The MIR builder does +not actually use the HIR but operates on the [THIR] instead, processing THIR +expressions recursively. The lowering creates local variables for every argument as specified in the signature. Next, it creates local variables for every binding specified (e.g. `(a, b): (i32, String)`) diff --git a/src/thir.md b/src/thir.md new file mode 100644 index 000000000..04bf635ce --- /dev/null +++ b/src/thir.md @@ -0,0 +1,39 @@ +# The THIR + + + +The THIR ("Typed High-Level Intermediate Representation"), previously HAIR for +"High-Level Abstract IR", is another IR used by rustc that is generated after +[type checking]. It is (as of March 2021) only used for +[MIR construction] and [exhaustiveness checking], but +[it may also soon be used for unsafety checking][thir-unsafeck] as a replacement +for the current MIR unsafety checker. + +[type checking]: ./type-checking.md +[MIR construction]: ./mir/construction.md +[exhaustiveness checking]: ./pat-exhaustive-checking.md +[thir-unsafeck]: https://github.com/rust-lang/compiler-team/issues/402 + +As the name might suggest, the THIR is a lowered version of the [HIR] where all +the types have been filled in, which is possible after type checking has completed. +But it has some other interesting features that distinguish it from HIR: +- like the MIR, the THIR only represents bodies, i.e. "executable code"; this includes + function bodies, but also `const` initializers, for example. Consequently, the THIR + has no representation for items like `struct`s or `trait`s. +- a body of THIR is only stored temporarily and is dropped as soon as it's no longer + needed, as opposed to being stored until the end of the compilation process (which + is what is done with the HIR). +- besides making the types of all nodes available, the THIR also has additional + desugaring compared to the HIR. For example, automatic references and dereferences + are made explicit, and method calls and overloaded operators are converted into + plain function calls. Destruction scopes are also made explicit. + +[HIR]: ./hir.md + +The THIR lives in [`rustc_mir_build::thir`][thir]. To construct a `thir::Expr`, +you can use the `build_thir` function, passing in the memory arena where the THIR +will be allocated. Dropping this arena will result in the THIR being destroyed: +this is useful to keep peak memory in check, as having a THIR representation of +all bodies of a crate in memory at the same time would be very heavy. + +[thir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/index.html From 872ba49f487760b90b17a082815690bf6c3407e6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Lanteri=20Thauvin?= Date: Tue, 9 Mar 2021 08:23:59 +0100 Subject: [PATCH 1443/1812] Apply suggestions from code review Co-authored-by: Camelid --- src/thir.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/src/thir.md b/src/thir.md index 04bf635ce..efbc52849 100644 --- a/src/thir.md +++ b/src/thir.md @@ -2,7 +2,7 @@ -The THIR ("Typed High-Level Intermediate Representation"), previously HAIR for +The THIR ("Typed High-Level Intermediate Representation"), previously called HAIR for "High-Level Abstract IR", is another IR used by rustc that is generated after [type checking]. It is (as of March 2021) only used for [MIR construction] and [exhaustiveness checking], but @@ -16,14 +16,17 @@ for the current MIR unsafety checker. As the name might suggest, the THIR is a lowered version of the [HIR] where all the types have been filled in, which is possible after type checking has completed. -But it has some other interesting features that distinguish it from HIR: -- like the MIR, the THIR only represents bodies, i.e. "executable code"; this includes +But it has some other interesting features that distinguish it from the HIR: + +- Like the MIR, the THIR only represents bodies, i.e. "executable code"; this includes function bodies, but also `const` initializers, for example. Consequently, the THIR has no representation for items like `struct`s or `trait`s. -- a body of THIR is only stored temporarily and is dropped as soon as it's no longer + +- Each body of THIR is only stored temporarily and is dropped as soon as it's no longer needed, as opposed to being stored until the end of the compilation process (which is what is done with the HIR). -- besides making the types of all nodes available, the THIR also has additional + +- Besides making the types of all nodes available, the THIR also has additional desugaring compared to the HIR. For example, automatic references and dereferences are made explicit, and method calls and overloaded operators are converted into plain function calls. Destruction scopes are also made explicit. @@ -32,8 +35,8 @@ But it has some other interesting features that distinguish it from HIR: The THIR lives in [`rustc_mir_build::thir`][thir]. To construct a `thir::Expr`, you can use the `build_thir` function, passing in the memory arena where the THIR -will be allocated. Dropping this arena will result in the THIR being destroyed: -this is useful to keep peak memory in check, as having a THIR representation of +will be allocated. Dropping this arena will result in the THIR being destroyed, +which is useful to keep peak memory in check. Having a THIR representation of all bodies of a crate in memory at the same time would be very heavy. [thir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/index.html From bfe8e98253d4f2c24d119b3812bf41f8513a0c3c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=A9o=20Lanteri=20Thauvin?= Date: Tue, 9 Mar 2021 11:44:02 +0100 Subject: [PATCH 1444/1812] Update lins --- src/thir.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/thir.md b/src/thir.md index efbc52849..b023eb2e2 100644 --- a/src/thir.md +++ b/src/thir.md @@ -33,10 +33,12 @@ But it has some other interesting features that distinguish it from the HIR: [HIR]: ./hir.md -The THIR lives in [`rustc_mir_build::thir`][thir]. To construct a `thir::Expr`, -you can use the `build_thir` function, passing in the memory arena where the THIR +The THIR lives in [`rustc_mir_build::thir`][thir-docs]. To construct a [`thir::Expr`], +you can use the [`build_thir`] function, passing in the memory arena where the THIR will be allocated. Dropping this arena will result in the THIR being destroyed, which is useful to keep peak memory in check. Having a THIR representation of all bodies of a crate in memory at the same time would be very heavy. -[thir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/index.html +[thir-docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/index.html +[`thir::Expr`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/struct.Expr.html +[`build_thir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/fn.build_thir.html From 3032f87519f96cdc48875e499dd26e6d168ac19b Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 11 Mar 2021 23:50:34 +0900 Subject: [PATCH 1445/1812] Check `BASE_SHA` only if it's a PR (#1083) --- ci/linkcheck.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index 3d70432f5..884823548 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -9,7 +9,7 @@ if [ "$GITHUB_EVENT_NAME" = "schedule" ] ; then # running in scheduled job echo "Doing full link check." set -x -elif [ "$CI" = "true" ] ; then # running in PR CI build +elif [ "$GITHUB_EVENT_NAME" = "pull_request" ] ; then # running in PR CI build if [ -z "$BASE_SHA" ]; then echo "error: unexpected state: BASE_SHA must be non-empty in CI" exit 1 From 0526ce3339be558310c5020ecc45072aa6f960ac Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 11 Mar 2021 14:55:41 -0300 Subject: [PATCH 1446/1812] Complete unfinished statement --- src/git.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/git.md b/src/git.md index d90619948..e533426cf 100644 --- a/src/git.md +++ b/src/git.md @@ -315,9 +315,8 @@ This is because, like any dependency, we want to be able to control which versio Submodules allow us to do just that: every submodule is "pinned" to a certain commit, which doesn't change unless modified manually. If you use `git checkout ` in the `miri` directory and go back to the `rust` directory, you can stage this -change like any -This is usually done by -the maintainers of the project, and looks like [this][miri-update]. +change like any other. This is usually done by the maintainers of the +project, and looks like [this][miri-update]. Git submodules take some time to get used to, so don't worry if it isn't perfectly clear yet. You will rarely have to use them directly and, again, you don't need From ff363172f92c126290bf2ebfec0987967f37b229 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 11 Mar 2021 15:05:02 -0300 Subject: [PATCH 1447/1812] I-nominated are nominated for discussion (#1080) * I-nominated are nominated for discussion * Generalize meeting expression Co-authored-by: Camelid Co-authored-by: Camelid --- src/contributing.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index c4a3fe872..abe1bb839 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -471,9 +471,10 @@ appropriate labels to issues that haven't been triaged yet: * Red, **I**-prefixed labels indicate the **importance** of the issue. The [I-nominated][inom] label indicates that an issue has been nominated for - prioritizing at the next triage meeting. Similarly, the [I-prioritize][ipri] - indicates that an issue has been requested to be prioritized by the - appropriate team. + discussion at the next meeting of the team tagged using a + **T**-prefixed label. Similarly, the [I-prioritize][ipri] indicates + that an issue has been requested to be prioritized by the appropriate + team. * The purple **metabug** label marks lists of bugs collected by other categories. From e72bf56a457055522423122b763da9ec46b040c0 Mon Sep 17 00:00:00 2001 From: Camelid Date: Thu, 11 Mar 2021 10:29:19 -0800 Subject: [PATCH 1448/1812] Fix double-word typos (#1084) Inspired by #1079. I used this command to find these typos: rg --multiline --pcre2 '\b([a-zA-Z]+) \1\b' src -tmd There were a couple false positives of the form "that that" meaning "that it" or "that this". --- src/borrow_check/region_inference/member_constraints.md | 2 +- src/borrow_check/region_inference/placeholders_and_universes.md | 2 +- src/mir/dataflow.md | 2 +- src/param_env.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 9e22aabc9..dfc4327e5 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -141,7 +141,7 @@ i.e., that `'0` must be *smaller* than. In our example, this would be examples, the chain may be more indirect. We can use upper bounds to rule out members in a very similar way to -lower lower bounds. If UB is some upper bound, then we know that `UB: +lower bounds. If UB is some upper bound, then we know that `UB: '0` must hold, so we can rule out any choice `'choice` where `UB: 'choice` does not hold. diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index e1c28ba4c..967aa0d33 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -75,7 +75,7 @@ index**. The idea of a "universe" is that it is a set of names that are in scope within some type or at some point. Universes are formed into a tree, where each child extends its parents with some new names. So the **root universe** conceptually contains global names, such as -the the lifetime `'static` or the type `i32`. In the compiler, we also +the lifetime `'static` or the type `i32`. In the compiler, we also put generic type parameters into this root universe (in this sense, there is not just one root universe, but one per item). So consider this function `bar`: diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index 9958f19b9..61277846b 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -147,7 +147,7 @@ when possible. Calling `iterate_to_fixpoint` on your `Engine` will return a `Results`, which contains the dataflow state at fixpoint upon entry of each block. Once you have -a `Results`, you can can inspect the dataflow state at fixpoint at any point in +a `Results`, you can inspect the dataflow state at fixpoint at any point in the CFG. If you only need the state at a few locations (e.g., each `Drop` terminator) use a [`ResultsCursor`]. If you need the state at *every* location, a [`ResultsVisitor`] will be more efficient. diff --git a/src/param_env.md b/src/param_env.md index 9050c5c79..08e19c339 100644 --- a/src/param_env.md +++ b/src/param_env.md @@ -1,6 +1,6 @@ # Parameter Environment -When working with associated and/or or generic items (types, constants, +When working with associated and/or generic items (types, constants, functions/methods) it is often relevant to have more information about the `Self` or generic parameters. Trait bounds and similar information is encoded in the [`ParamEnv`][pe]. Often this is not enough information to obtain things like the From 67ebd4b55dba44edfc351621cef6e5e758169c55 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 11 Mar 2021 18:36:25 -0300 Subject: [PATCH 1449/1812] Remove extra the (#1088) --- src/early-late-bound.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/early-late-bound.md b/src/early-late-bound.md index 973306b86..4178a4af0 100644 --- a/src/early-late-bound.md +++ b/src/early-late-bound.md @@ -64,7 +64,7 @@ trait Foo { Here, the type `(Self, T, U)` would be `($0, $1, $2)`, where `$N` means a [`ParamTy`] with the index of `N`. -In rustc, the [`Generics`] structure carries the this information. So the +In rustc, the [`Generics`] structure carries this information. So the [`Generics`] for `Bar` above would be just like for `U` and would indicate the 'parent' generics of `Foo`, which declares `Self` and `T`. You can read more in [this chapter](./generics.md). From 9a676ee3a4bc9d8d054efd1ff57fc15ce19c00bd Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Fri, 19 Mar 2021 20:11:43 -0300 Subject: [PATCH 1450/1812] Fix rust compiler meeting info (#1087) * Remove dead link * Make general text a bit better * Fix Zulip link * Improve description of what the compiler meeting is about --- src/compiler-team.md | 42 ++++++++++++++++++++++++------------------ 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/src/compiler-team.md b/src/compiler-team.md index ebb8cbc16..8cfcc5bb6 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -30,32 +30,38 @@ who are experts on each one. ## Rust compiler meeting The compiler team has a weekly meeting where we do triage and try to -generally stay on top of new bugs, regressions, and other things. -They are held on [Zulip][zulip]. It works roughly as follows: - -- **Review P-high bugs:** P-high bugs are those that are sufficiently - important for us to actively track progress. P-high bugs should - ideally always have an assignee. -- **Look over new regressions:** we then look for new cases where the - compiler broke previously working code in the wild. Regressions are - almost always marked as P-high; the major exception would be bug - fixes (though even there we often [aim to give warnings first][procedure]). -- **Check I-nominated issues:** These are issues where feedback from +generally stay on top of new bugs, regressions, and discuss important +things in general. +They are held on [Zulip][zulip-meetings]. It works roughly as follows: + +- **Announcements, MCPs/FCPs, and WG-check-ins:** We share some + announcements with the rest of the team about important things we want + everyone to be aware of. We also share the status of MCPs and FCPs and we + use the opportunity to have a couple of WGs giving us an update about + their work. +- **Check for beta and stable nominations:** These are nominations of things to + backport to beta and stable respectively. + We then look for new cases where the compiler broke previously working + code in the wild. Regressions are important issues to fix, so it's + likely that they are tagged as P-critical or P-high; the major + exception would be bug fixes (though even there we often [aim to give + warnings first][procedure]). +- **Review P-critical and P-high bugs:** P-critical and P-high bugs are + those that are sufficiently important for us to actively track + progress. P-critical and P-high bugs should ideally always have an + assignee. +- **Check S-waiting-on-team and I-nominated issues:** These are issues where feedback from the team is desired. -- **Check for beta nominations:** These are nominations of things to - backport to beta. -- **Possibly WG checking:** A WG may give an update at this point, if there is - time. +- **Look over the performance triage report:** We check for PRs that made the + performance worse and try to decide if it's worth reverting the performance regression or if + the regression can be addressed in a future PR. The meeting currently takes place on Thursdays at 10am Boston time (UTC-4 typically, but daylight savings time sometimes makes things complicated). -The meeting is held over a "chat medium", currently on [zulip]. -[etherpad]: https://public.etherpad-mozilla.org/p/rust-compiler-meeting [procedure]: ./bug-fix-procedure.md -[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler [zulip-help]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp [zulip-meetings]: https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings From fe0cf8215dd5e70a7e4273250c3f7dcd44b3f656 Mon Sep 17 00:00:00 2001 From: Undxxx <32825301+Undxxx@users.noreply.github.com> Date: Sun, 28 Mar 2021 18:15:09 +0800 Subject: [PATCH 1451/1812] Update rustc-driver-*.rs examples (#1095) --- examples/rustc-driver-example.rs | 8 ++++++-- examples/rustc-driver-getting-diagnostics.rs | 5 ++++- examples/rustc-driver-interacting-with-the-ast.rs | 11 +++++------ 3 files changed, 15 insertions(+), 9 deletions(-) diff --git a/examples/rustc-driver-example.rs b/examples/rustc-driver-example.rs index f01072b7b..51af6f5aa 100644 --- a/examples/rustc-driver-example.rs +++ b/examples/rustc-driver-example.rs @@ -3,6 +3,8 @@ // NOTE: For the example to compile, you will need to first run the following: // rustup component add rustc-dev +// version: 1.53.0-nightly (9b0edb7fd 2021-03-27) + extern crate rustc_error_codes; extern crate rustc_errors; extern crate rustc_hash; @@ -46,8 +48,9 @@ fn main() { diagnostic_output: rustc_session::DiagnosticOutput::Default, // Set to capture stderr output during compiler execution stderr: None, // Option>>> - crate_name: None, // Option lint_caps: FxHashMap::default(), // FxHashMap + // This is a callback from the driver that is called when [`ParseSess`] is created. + parse_sess_created: None, //Option> // This is a callback from the driver that is called when we're registering lints; // it is called during plugin registration when we have the LintStore in a non-shared state. // @@ -61,6 +64,7 @@ fn main() { override_queries: None, // Option, &mut ty::query::Providers<'_>)> // Registry of diagnostics codes. registry: registry::Registry::new(&rustc_error_codes::DIAGNOSTICS), + make_codegen_backend: None, }; rustc_interface::run_compiler(config, |compiler| { compiler.enter(|queries| { @@ -73,7 +77,7 @@ fn main() { match item.kind { rustc_hir::ItemKind::Static(_, _, _) | rustc_hir::ItemKind::Fn(_, _, _) => { let name = item.ident; - let ty = tcx.type_of(tcx.hir().local_def_id(item.hir_id)); + let ty = tcx.type_of(tcx.hir().local_def_id(item.hir_id())); println!("{:?}:\t{:?}", name, ty) } _ => (), diff --git a/examples/rustc-driver-getting-diagnostics.rs b/examples/rustc-driver-getting-diagnostics.rs index e1caab326..ee9a20c05 100644 --- a/examples/rustc-driver-getting-diagnostics.rs +++ b/examples/rustc-driver-getting-diagnostics.rs @@ -3,6 +3,8 @@ // NOTE: For the example to compile, you will need to first run the following: // rustup component add rustc-dev +// version: 1.53.0-nightly (9b0edb7fd 2021-03-27) + extern crate rustc_error_codes; extern crate rustc_errors; extern crate rustc_hash; @@ -68,11 +70,12 @@ fn main() { output_file: None, file_loader: None, stderr: None, - crate_name: None, lint_caps: rustc_hash::FxHashMap::default(), + parse_sess_created: None, register_lints: None, override_queries: None, registry: registry::Registry::new(&rustc_error_codes::DIAGNOSTICS), + make_codegen_backend: None, }; rustc_interface::run_compiler(config, |compiler| { compiler.enter(|queries| { diff --git a/examples/rustc-driver-interacting-with-the-ast.rs b/examples/rustc-driver-interacting-with-the-ast.rs index 8ee38206f..2c7533498 100644 --- a/examples/rustc-driver-interacting-with-the-ast.rs +++ b/examples/rustc-driver-interacting-with-the-ast.rs @@ -3,6 +3,8 @@ // NOTE: For the example to compile, you will need to first run the following: // rustup component add rustc-dev llvm-tools-preview +// version: 1.53.0-nightly (9b0edb7fd 2021-03-27) + extern crate rustc_ast_pretty; extern crate rustc_error_codes; extern crate rustc_errors; @@ -15,8 +17,6 @@ extern crate rustc_span; use rustc_ast_pretty::pprust::item_to_string; use rustc_errors::registry; use rustc_session::config; -use rustc_session::config::PpMode::PpmSource; -use rustc_session::config::PpSourceMode::PpmExpanded; use rustc_span::source_map; use std::path; use std::process; @@ -46,8 +46,8 @@ fn main() { output_file: None, file_loader: None, stderr: None, - crate_name: None, lint_caps: rustc_hash::FxHashMap::default(), + parse_sess_created: None, register_lints: None, override_queries: None, make_codegen_backend: None, @@ -57,8 +57,7 @@ fn main() { compiler.enter(|queries| { // TODO: add this to -Z unpretty let ast_krate = queries.parse().unwrap().take(); - let ast_krate_mod = ast_krate.module; - for item in ast_krate_mod.items { + for item in ast_krate.items { println!("{}", item_to_string(&item)); } @@ -75,7 +74,7 @@ fn main() { if let rustc_hir::StmtKind::Local(local) = block.stmts[0].kind { if let Some(expr) = local.init { let hir_id = expr.hir_id; // hir_id identifies the string "Hello, world!" - let def_id = tcx.hir().local_def_id(item.hir_id); // def_id identifies the main function + let def_id = tcx.hir().local_def_id(item.hir_id()); // def_id identifies the main function let ty = tcx.typeck(def_id).node_type(hir_id); println!("{:?}: {:?}", expr, ty); // prints expr(HirId { owner: DefIndex(3), local_id: 4 }: "Hello, world!"): &'static str } From 0687daac28939c476df51778f5a1d1aff1a3fddf Mon Sep 17 00:00:00 2001 From: JohnTitor Date: Sun, 28 Mar 2021 20:01:00 +0900 Subject: [PATCH 1452/1812] Add notes about nightly rustc version for the rustc-driver examples --- src/rustc-driver-getting-diagnostics.md | 11 +++++++---- src/rustc-driver-interacting-with-the-ast.md | 13 ++++++++----- 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/src/rustc-driver-getting-diagnostics.md b/src/rustc-driver-getting-diagnostics.md index 27ca2ca12..fa5ce0750 100644 --- a/src/rustc-driver-getting-diagnostics.md +++ b/src/rustc-driver-getting-diagnostics.md @@ -4,12 +4,15 @@ ## Getting diagnostics -To get diagnostics from the compiler, -configure `rustc_interface::Config` to output diagnostic to a buffer, -and run `TyCtxt.analysis`: +To get diagnostics from the compiler, +configure `rustc_interface::Config` to output diagnostic to a buffer, +and run `TyCtxt.analysis`. The following should be compiled +with `nightly-2021-03-28` (See [here][example] +for the complete example): + +[example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-getting-diagnostics.rs ```rust -// See https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-getting-diagnostics.rs for complete program. let buffer = sync::Arc::new(sync::Mutex::new(Vec::new())); let config = rustc_interface::Config { opts: config::Options { diff --git a/src/rustc-driver-interacting-with-the-ast.md b/src/rustc-driver-interacting-with-the-ast.md index 21d03bbb7..7cb53187b 100644 --- a/src/rustc-driver-interacting-with-the-ast.md +++ b/src/rustc-driver-interacting-with-the-ast.md @@ -4,10 +4,13 @@ ## Getting the type of an expression -To get the type of an expression, use the `global_ctxt` to get a `TyCtxt`: +To get the type of an expression, use the `global_ctxt` to get a `TyCtxt`. +The following should be compiled with `nightly-2021-03-28` +(see [here][example] for the complete example): + +[example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-interacting-with-the-ast.rs ```rust -// See https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-interacting-with-the-ast.rs for complete program. let config = rustc_interface::Config { input: config::Input::Str { name: source_map::FileName::Custom("main.rs".to_string()), @@ -21,9 +24,9 @@ rustc_interface::run_compiler(config, |compiler| { // Analyze the crate and inspect the types under the cursor. queries.global_ctxt().unwrap().take().enter(|tcx| { // Every compilation contains a single crate. - let krate = tcx.hir().krate(); + let hir_krate = tcx.hir().krate(); // Iterate over the top-level items in the crate, looking for the main function. - for (_, item) in &krate.items { + for (_, item) in &hir_krate.items { // Use pattern-matching to find a specific node inside the main function. if let rustc_hir::ItemKind::Fn(_, _, body_id) = item.kind { let expr = &tcx.hir().body(body_id).value; @@ -31,7 +34,7 @@ rustc_interface::run_compiler(config, |compiler| { if let rustc_hir::StmtKind::Local(local) = block.stmts[0].kind { if let Some(expr) = local.init { let hir_id = expr.hir_id; // hir_id identifies the string "Hello, world!" - let def_id = tcx.hir().local_def_id(item.hir_id); // def_id identifies the main function + let def_id = tcx.hir().local_def_id(item.hir_id()); // def_id identifies the main function let ty = tcx.typeck(def_id).node_type(hir_id); println!("{:?}: {:?}", expr, ty); // prints expr(HirId { owner: DefIndex(3), local_id: 4 }: "Hello, world!"): &'static str } From a05852eec085861bbd1bfe7e697d2c2ac6bb30ba Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 31 Mar 2021 12:25:14 -0400 Subject: [PATCH 1453/1812] Document test input normalization --- src/tests/adding.md | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 944b895b5..656d0095f 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -425,7 +425,7 @@ you can even run the resulting program. Just add one of the following - `// run-pass` – compilation should succeed and we should run the resulting binary -### Normalization +### Output Normalization The compiler output is normalized to eliminate output difference between platforms, mainly about filenames. @@ -500,3 +500,23 @@ Besides `normalize-stderr-32bit` and `-64bit`, one may use any target information or stage supported by [`ignore-X`](#ignoring-tests) here as well (e.g. `normalize-stderr-windows` or simply `normalize-stderr-test` for unconditional replacement). + +## Input Normalization + +Sometimes, you want to normalize the inputs to a test. For example, you may +want to pass `// compile-flags: --x=y.rs`, where y.rs is some file in the test +directory. In this case you can use input normalization. The following strings +are replaced in header inputs: + +- {{cwd}}: The directory where compiletest is run from. This may not be the + root of the checkout, so you should avoid using it where possible. + - Example: `/path/to/rust` +- {{src-base}}: The directory where the test is defined. This is equivalent to + `$DIR` for output normalization. + - Example: `/path/to/rust/src/test/ui/error-codes` +- {{build-base}}: The base directory where the test's output goes. This is + equivalent to `$TEST_BUILD_DIR` for output normalization. + - Example: `/path/to/rust/build/x86_64-unknown-linux-gnu/test/ui` + +See [`src/test/ui/commandline-argfile.rs`](https://github.com/rust-lang/rust/blob/a5029ac0ab372aec515db2e718da6d7787f3d122/src/test/ui/commandline-argfile.rs) +for an example of a test that uses input normalization. From dda441c42ef854cec55d030bc3c21b73613841e0 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 31 Mar 2021 15:04:46 -0400 Subject: [PATCH 1454/1812] Add back example of {{cwd}} (#1099) I force-pushed this in the last commit and accidentally deleted the github suggestion. --- src/tests/adding.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 656d0095f..8508c2f20 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -510,7 +510,7 @@ are replaced in header inputs: - {{cwd}}: The directory where compiletest is run from. This may not be the root of the checkout, so you should avoid using it where possible. - - Example: `/path/to/rust` + - Examples: `/path/to/rust`, `/path/to/build/root` - {{src-base}}: The directory where the test is defined. This is equivalent to `$DIR` for output normalization. - Example: `/path/to/rust/src/test/ui/error-codes` From 32c6d27b4b44f22abb5a573861a04aa6be34ad7d Mon Sep 17 00:00:00 2001 From: Camelid Date: Thu, 1 Apr 2021 10:24:44 -0700 Subject: [PATCH 1455/1812] Add quickstart for adding a new optimization (#1094) --- src/mir/optimizations.md | 49 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index 080c8fd3f..50e06960e 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -26,6 +26,55 @@ optimizes it, and returns the improved MIR. [defid]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html#def-id [steal]: https://rustc-dev-guide.rust-lang.org/mir/passes.html?highlight=steal#stealing +## Quickstart for adding a new optimization + +1. Make a Rust source file in `src/test/mir-opt` that shows the code you want to + optimize. This should be kept simple, so avoid `println!` or other formatting + code if it's not necessary for the optimization. The reason for this is that + `println!`, `format!`, etc. generate a lot of MIR that can make it harder to + understand what the optimization does to the test. + +2. Run `./x.py test --bless src/test/mir-opt/.rs` to generate a MIR + dump. Read [this README][mir-opt-test-readme] for instructions on how to dump + things. + +3. Commit the current working directory state. The reason you should commit the + test output before you implement the optimization is so that you (and your + reviewers) can see a before/after diff of what the optimization changed. + +4. Implement a new optimization in [`compiler/rustc_mir/src/transform`]. + The fastest and easiest way to do this is to + + 1. pick a small optimization (such as [`no_landing_pads`]) and copy it + to a new file, + 2. add your optimization to one of the lists in the + [`run_optimization_passes()`] function, + 3. and then start modifying the copied optimization. + +5. Rerun `./x.py test --bless src/test/mir-opt/.rs` to regenerate the + MIR dumps. Look at the diffs to see if they are what you expect. + +6. Run `./x.py test src/test/ui` to see if your optimization broke anything. + +7. If there are issues with your optimization, experiment with it a bit and + repeat steps 5 and 6. + +8. Commit and open a PR. You can do this at any point, even if things aren't + working yet, so that you can ask for feedback on the PR. Open a "WIP" PR + (just prefix your PR title with `[WIP]` or otherwise note that it is a + work in progress) in that case. + + Make sure to commit the blessed test output as well! It's necessary for CI to + pass and it's very helpful to reviewers. + +If you have any questions along the way, feel free to ask in +`#t-compiler/wg-mir-opt` on Zulip. + +[mir-opt-test-readme]: https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/README.md +[`compiler/rustc_mir/src/transform`]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir/src/transform +[`no_landing_pads`]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/transform/no_landing_pads.rs +[`run_optimization_passes()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.run_optimization_passes.html + ## Defining optimization passes The list of passes run and the order in which they are run is defined by the From dfe398bd5a39826dd200a0bb95ca668c27c98664 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 2 Apr 2021 18:12:42 +0900 Subject: [PATCH 1456/1812] Fix a link about Rustdoc internals --- src/rustdoc.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/rustdoc.md b/src/rustdoc.md index 33f2c5f35..b0c68aa9d 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -4,9 +4,10 @@ Rustdoc actually uses the rustc internals directly. It lives in-tree with the compiler and standard library. This chapter is about how it works. For information about Rustdoc's features and how to use them, see the [Rustdoc book](https://doc.rust-lang.org/nightly/rustdoc/). -For more details about how rustdoc works, see the ["Rustdoc internals" chapter]. +For more details about how rustdoc works, see the +["Rustdoc internals" chapter][Rustdoc internals]. -["Rustdoc internals" chapter]: ./rustdoc-internals.md +[Rustdoc internals]: ./rustdoc-internals.md Rustdoc is implemented entirely within the crate [`librustdoc`][rd]. It runs the compiler up to the point where we have an internal representation of a @@ -47,7 +48,7 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) bundle is meant to be used as though you would copy out the `doc` folder to a web server, since that's where the CSS/JS and landing page are. * Use `x.py test src/test/rustdoc*` to run the tests using a stage1 rustdoc. - * See [rustdoc internals] for more information about tests. + * See [Rustdoc internals] for more information about tests. * Most of the HTML printing code is in `html/format.rs` and `html/render.rs`. It's in a bunch of `fmt::Display` implementations and supplementary functions. From 8d6459ffffc4f58dc6f7040bcd5556a6c7ae5033 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 2 Apr 2021 05:15:48 +0900 Subject: [PATCH 1457/1812] Update the "LLVM updates" section --- src/backend/updating-llvm.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md index a9c3b45c4..9deff62dd 100644 --- a/src/backend/updating-llvm.md +++ b/src/backend/updating-llvm.md @@ -67,7 +67,7 @@ Example PRs look like: ## Feature updates > Note that this information is as of the time of this writing (December 2018). The process for updating LLVM changes with +2021-04 --> (April 2021). The process for updating LLVM changes with practically all LLVM updates, so this may be out of date! Unlike bugfixes, updating to pick up a new feature of LLVM typically requires a @@ -75,7 +75,7 @@ lot more work. This is where we can't reasonably cherry-pick commits backwards so we need to do a full update. There's a lot of stuff to do here, so let's go through each in detail. -1. Create a new branch in the rust-lang/llvm-project repository. This branch +1. Create a new branch in the [rust-lang/llvm-project repository]. This branch should be named `rustc/a.b-yyyy-mm-dd` where `a.b` is the current version number of LLVM in-tree at the time of the branch and the remaining part is today's date. Move this branch to the commit in LLVM that you'd like, which @@ -119,12 +119,12 @@ through each in detail. Ideally, build LLVM and test it on a few platforms: * Linux - * OSX + * macOS * Windows and afterwards run some docker containers that CI also does: - * `./src/ci/docker/run.sh wasm32-unknown` + * `./src/ci/docker/run.sh wasm32` * `./src/ci/docker/run.sh arm-android` * `./src/ci/docker/run.sh dist-various-1` * `./src/ci/docker/run.sh dist-various-2` @@ -136,15 +136,17 @@ through each in detail. `src/llvm-project` and will likely also change [`llvm-wrapper`] as well. For prior art, previous LLVM updates look like -[#55835](https://github.com/rust-lang/rust/pull/55835) -[#47828](https://github.com/rust-lang/rust/pull/47828) [#62474](https://github.com/rust-lang/rust/pull/62474) -[#62592](https://github.com/rust-lang/rust/pull/62592). Note that sometimes it's +[#62592](https://github.com/rust-lang/rust/pull/62592) +[#67759](https://github.com/rust-lang/rust/pull/67759) +[#73526](https://github.com/rust-lang/rust/pull/73526) +[#81451](https://github.com/rust-lang/rust/pull/81451). Note that sometimes it's easiest to land [`llvm-wrapper`] compatibility as a PR before actually updating `src/llvm-project`. This way while you're working through LLVM issues others interested in trying out the new LLVM can benefit from work you've done to update the C++ bindings. +[rust-lang/llvm-project repository]: https://github.com/rust-lang/llvm-project [`llvm-wrapper`]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_llvm/llvm-wrapper ### Caveats and gotchas @@ -155,10 +157,12 @@ keep in mind while going through them: * LLVM bugs are hard to find, don't hesitate to ask for help! Bisection is definitely your friend here (yes LLVM takes forever to build, yet bisection is still your friend) -* If you've got general questions, @alexcrichton can help you out. +* If you've got general questions, [wg-llvm] can help you out. * Creating branches is a privileged operation on GitHub, so you'll need someone with write access to create the branches for you most likely. +[wg-llvm]: https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm + ## New LLVM Release Updates Updating to a new release of LLVM is very similar to the "feature updates" From d1e2f3bf50c67ea77a144085c86285485e407153 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E4=BA=8C=E6=89=8B=E6=8E=89=E5=8C=85=E5=B7=A5=E7=A8=8B?= =?UTF-8?q?=E5=B8=88?= Date: Sun, 4 Apr 2021 00:41:35 +0800 Subject: [PATCH 1458/1812] Fix rustdocs test command typo (#1103) --- src/rustdoc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustdoc.md b/src/rustdoc.md index b0c68aa9d..88177ccba 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -47,7 +47,7 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * The completed docs will be available in `build/$TARGET/doc/std`, though the bundle is meant to be used as though you would copy out the `doc` folder to a web server, since that's where the CSS/JS and landing page are. -* Use `x.py test src/test/rustdoc*` to run the tests using a stage1 rustdoc. +* Use `./x.py test src/test/rustdoc*` to run the tests using a stage1 rustdoc. * See [Rustdoc internals] for more information about tests. * Most of the HTML printing code is in `html/format.rs` and `html/render.rs`. It's in a bunch of `fmt::Display` implementations and supplementary From 871a54568fa13f1273c28fbaa6cac6e3365c0956 Mon Sep 17 00:00:00 2001 From: AngelicosPhosphoros Date: Sun, 4 Apr 2021 03:13:03 +0300 Subject: [PATCH 1459/1812] Mention CI build of LLVM in build instruction --- src/building/how-to-build-and-run.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index a97568e6e..77f36cda8 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -33,6 +33,9 @@ settings (and possibly others, such as `llvm.ccache`): ```toml [llvm] +# Whether to use Rust CI built LLVM instead of locally building it. +download-ci-llvm = true + # Indicates whether the LLVM assertions are enabled or not assertions = true From 83b81fdd6964953ae9e3be4b9590409533a216ac Mon Sep 17 00:00:00 2001 From: Waffle Lapkin Date: Fri, 9 Apr 2021 00:21:22 +0300 Subject: [PATCH 1460/1812] fix typo --- src/generics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/generics.md b/src/generics.md index cdbf63b93..c7a0be093 100644 --- a/src/generics.md +++ b/src/generics.md @@ -7,7 +7,7 @@ that one type is equal to another type and want to swap one out for the other an for another type and so on until we eventually get some concrete types (or an error). In rustc this is done using the `SubstsRef` that we mentioned above (“substs” = “substitutions”). -Conceptually, you can think of `SubstsRef` of a list of types that are to be substituted for the +Conceptually, you can think of `SubstsRef` as a list of types that are to be substituted for the generic type parameters of the ADT. `SubstsRef` is a type alias of `List>` (see [`List` rustdocs][list]). From 2c2f61ae19b0152e819c637623c622d7428a73c3 Mon Sep 17 00:00:00 2001 From: Waffle Lapkin Date: Fri, 9 Apr 2021 13:30:04 +0300 Subject: [PATCH 1461/1812] fix typo (#1107) --- src/method-lookup.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index 5aafb6abf..433105563 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -100,7 +100,7 @@ that defines it with `&self` for the type `Rc` as well as a method on the type `Box` that defines `Foo` but with `&mut self`. Then we might have two candidates: ```text -&Rc> from the impl of `Foo` for `Rc` where `U=Box +&Rc> from the impl of `Foo` for `Rc` where `U=Box<[T; 3]> &mut Box<[T; 3]>> from the inherent impl on `Box` where `U=[T; 3]` ``` From 31e44f4116e91628a732cb78f20bb206af7585f9 Mon Sep 17 00:00:00 2001 From: Waffle Lapkin Date: Fri, 9 Apr 2021 17:27:03 +0300 Subject: [PATCH 1462/1812] Change wording a bit: `module` => `crate` It seems more correct --- src/method-lookup.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index 433105563..17116406c 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -73,7 +73,7 @@ nominal type `Foo` (e.g., a struct), any methods defined within an impl like `impl Foo` are inherent methods. Nothing needs to be imported to use an inherent method, they are associated with the type itself (note that inherent impls can only be defined in the same -module as the type itself). +crate as the type itself). FIXME: Inherent candidates are not always derived from impls. If you have a trait object, such as a value of type `Box`, then the @@ -90,7 +90,7 @@ TODO: Is this FIXME still accurate? the trait `ToString` imported, and I call `to_string()` on a value of type `T`, then we will go off to find out whether there is an impl of `ToString` for `T`. These kinds of method calls are called "extension -methods". They can be defined in any module, not only the one that +methods". They can be defined in any crate, not only the one that defined `T`. Furthermore, you must import the trait to call such a method. From a9bd2bbf31e4f92b5d3d8e80b22839d0cc7a2022 Mon Sep 17 00:00:00 2001 From: Camelid Date: Fri, 9 Apr 2021 14:25:18 -0700 Subject: [PATCH 1463/1812] Improve formatting and update info in "method lookup" section --- src/method-lookup.md | 33 ++++++++++++--------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index 17116406c..250eea034 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -6,18 +6,11 @@ file provides an overview of the process. More detailed notes are in the code itself, naturally. One way to think of method lookup is that we convert an expression of -the form: +the form `receiver.method(...)` into a more explicit [fully-qualified syntax][] +(formerly called [UFCS][]): -```rust,ignore -receiver.method(...) -``` - -into a more explicit [UFCS] form: - -```rust,ignore -Trait::method(ADJ(receiver), ...) // for a trait call -ReceiverType::method(ADJ(receiver), ...) // for an inherent method call -``` +- `Trait::method(ADJ(receiver), ...)` for a trait call +- `ReceiverType::method(ADJ(receiver), ...)` for an inherent method call Here `ADJ` is some kind of adjustment, which is typically a series of autoderefs and then possibly an autoref (e.g., `&**receiver`). However @@ -37,6 +30,7 @@ probe phase produces a "pick" (`probe::Pick`), which is designed to be cacheable across method-call sites. Therefore, it does not include inference variables or other information. +[fully-qualified syntax]: https://doc.rust-lang.org/nightly/book/ch19-03-advanced-traits.html#fully-qualified-syntax-for-disambiguation-calling-methods-with-the-same-name [UFCS]: https://github.com/rust-lang/rfcs/blob/master/text/0132-ufcs.md [probe]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/method/probe/ [confirm]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/method/confirm/ @@ -51,12 +45,10 @@ until it cannot be deref'd anymore, as well as applying an optional "unsize" step. So if the receiver has type `Rc>`, this might yield: -```rust,ignore -Rc> -Box<[T; 3]> -[T; 3] -[T] -``` +1. `Rc>` +2. `Box<[T; 3]>` +3. `[T; 3]` +4. `[T]` ### Candidate assembly @@ -99,10 +91,9 @@ So, let's continue our example. Imagine that we were calling a method that defines it with `&self` for the type `Rc` as well as a method on the type `Box` that defines `Foo` but with `&mut self`. Then we might have two candidates: -```text -&Rc> from the impl of `Foo` for `Rc` where `U=Box<[T; 3]> -&mut Box<[T; 3]>> from the inherent impl on `Box` where `U=[T; 3]` -``` + +- `&Rc>` from the impl of `Foo` for `Rc` where `U=Box<[T; 3]>` +- `&mut Box<[T; 3]>>` from the inherent impl on `Box` where `U=[T; 3]` ### Candidate search From 8cf042c6f506d91d04b643502e3c938935ff5d91 Mon Sep 17 00:00:00 2001 From: Smitty Date: Fri, 23 Apr 2021 16:14:57 -0400 Subject: [PATCH 1464/1812] Mention unpretty=mir-cfg for debugging MIR --- src/mir/debugging.md | 5 + src/mir/mir_cfg.svg | 270 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 275 insertions(+) create mode 100644 src/mir/mir_cfg.svg diff --git a/src/mir/debugging.md b/src/mir/debugging.md index c6734f8aa..b7182fa90 100644 --- a/src/mir/debugging.md +++ b/src/mir/debugging.md @@ -88,6 +88,11 @@ rustc.main.002-006.NoLandingPads.before.mir (Here, the `main-promoted[0]` files refer to the MIR for "promoted constants" that appeared within the `main` function.) +The `-Z unpretty=mir-cfg` flag can be used to create a graphviz MIR +control-flow diagram for the whole crate: + +![A control-flow diagram](mir_cfg.svg) + TODO: anything else? [dataflow state]: ./dataflow.html#graphviz-diagrams diff --git a/src/mir/mir_cfg.svg b/src/mir/mir_cfg.svg new file mode 100644 index 000000000..70705ec04 --- /dev/null +++ b/src/mir/mir_cfg.svg @@ -0,0 +1,270 @@ + + + + + + +__crate__ + + +cluster_Mir_0_4 + +fn main() -> () +let _1: i32; +let mut _2: i32; +let mut _3: bool; +let mut _4: i32; +let mut _5: i32; +debug x => _1; +debug y => _2; + + +cluster_Mir_0_3 + +fn incr() -> i32 +let mut _1: i32; +let mut _2: bool; +let mut _3: bool; +debug ret => _1; + + + +bb0__0_4 + + +0 + +StorageLive(_1) +_1 = const 5_i32 +StorageLive(_2) +_2 = const 3_i32 +StorageLive(_3) +StorageLive(_4) +_4 = _1 +_3 = Gt(move _4, const 3_i32) +StorageDead(_4) + +switchInt(move _3) + + + +bb1__0_4 + + +1 + +_2 = const 4_i32 +_0 = const () + +goto + + + +bb0__0_4->bb1__0_4 + + +otherwise + + + +bb2__0_4 + + +2 + +StorageLive(_5) + +_5 = incr() + + + +bb0__0_4->bb2__0_4 + + +false + + + +bb4__0_4 + + +4 + +StorageDead(_3) +StorageDead(_2) +StorageDead(_1) + +return + + + +bb1__0_4->bb4__0_4 + + + + + +bb3__0_4 + + +3 + +_2 = Add(_2, move _5) +StorageDead(_5) +_0 = const () + +goto + + + +bb2__0_4->bb3__0_4 + + +return + + + +bb3__0_4->bb4__0_4 + + + + + +bb0__0_3 + + +0 + +StorageLive(_1) +StorageLive(_2) +_2 = const true + +switchInt(move _2) + + + +bb1__0_3 + + +1 + +_1 = const 7_i32 + +goto + + + +bb0__0_3->bb1__0_3 + + +otherwise + + + +bb2__0_3 + + +2 + +StorageLive(_3) +_3 = const true + +switchInt(move _3) + + + +bb0__0_3->bb2__0_3 + + +false + + + +bb6__0_3 + + +6 + +StorageDead(_2) +_1 = Add(_1, const 1_i32) +_0 = _1 +StorageDead(_1) + +return + + + +bb1__0_3->bb6__0_3 + + + + + +bb3__0_3 + + +3 + +_1 = const 8_i32 + +goto + + + +bb2__0_3->bb3__0_3 + + +otherwise + + + +bb4__0_3 + + +4 + +_1 = const 9_i32 + +goto + + + +bb2__0_3->bb4__0_3 + + +false + + + +bb5__0_3 + + +5 + +StorageDead(_3) + +goto + + + +bb3__0_3->bb5__0_3 + + + + + +bb4__0_3->bb5__0_3 + + + + + +bb5__0_3->bb6__0_3 + + + + + From 2f5927a77eddfbca0388c6bebb4bc6343268be7a Mon Sep 17 00:00:00 2001 From: Nixon Enraght-Moony Date: Sat, 24 Apr 2021 02:53:30 +0100 Subject: [PATCH 1465/1812] Add Polymorphisation paper (#1093) --- src/appendix/bibliography.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index c8b4a23b3..0caed3faf 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -89,3 +89,4 @@ Rust, as well as publications about Rust. * [The Case for Writing a Kernel in Rust](https://www.tockos.org/assets/papers/rust-kernel-apsys2017.pdf) * [RustBelt: Securing the Foundations of the Rust Programming Language](https://plv.mpi-sws.org/rustbelt/popl18/) * [Oxide: The Essence of Rust](https://arxiv.org/abs/1903.00982). By Aaron Weiss, Olek Gierczak, Daniel Patterson, Nicholas D. Matsakis, and Amal Ahmed. +* [Polymorphisation: Improving Rust compilation times through intelligent monomorphisation](https://davidtw.co/media/masters_dissertation.pdf). David Wood's master's thesis. From 9b0135d30691fef7e24460f626caa992352e94b0 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Tue, 27 Apr 2021 00:34:50 +0200 Subject: [PATCH 1466/1812] more RA config suggestions (#1114) --- src/building/suggested.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 6e0f830c6..ebefd61c1 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -34,7 +34,9 @@ you can write: "rust-analyzer.rustfmt.overrideCommand": [ "./build/TARGET_TRIPLE/stage0/bin/rustfmt" ], - "editor.formatOnSave": true + "editor.formatOnSave": true, + "rust-analyzer.cargo.runBuildScripts": false, + "rust-analyzer.procMacro.enable": false } ``` From ccc286ba877a575eb9e64b14143b76f1e92de981 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 25 Apr 2021 11:24:16 -0400 Subject: [PATCH 1467/1812] Add sample nix shell This also suggests using `x.py setup` instead of copying config.toml. --- src/building/how-to-build-and-run.md | 19 +++----- src/building/suggested.md | 71 ++++++++++++++++++++++++++++ 2 files changed, 77 insertions(+), 13 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 77f36cda8..49c2e8b66 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -20,16 +20,10 @@ cd rust ## Create a `config.toml` -To start, copy [`config.toml.example`] to `config.toml`: +To start, run `x.py setup`. This will create a `config.toml` with reasonable defaults. -[`config.toml.example`]: https://github.com/rust-lang/rust/blob/master/config.toml.example - -```bash -cp config.toml.example config.toml -``` - -Then you will want to open up the file and change the following -settings (and possibly others, such as `llvm.ccache`): +You may also want to change some of the following settings (and possibly others, such as +`llvm.ccache`): ```toml [llvm] @@ -54,10 +48,9 @@ debug-logging = true incremental = true ``` -If you have already built `rustc`, then you may have to execute `rm -rf build` for subsequent -configuration changes to take effect. Note that `./x.py clean` will not cause a -rebuild of LLVM, so if your configuration change affects LLVM, you will need to -manually `rm -rf build/` before rebuilding. +If you have already built `rustc` and you change settings related to LLVM, then you may have to +execute `rm -rf build` for subsequent configuration changes to take effect. Note that `./x.py +clean` will not cause a rebuild of LLVM. ## What is `x.py`? diff --git a/src/building/suggested.md b/src/building/suggested.md index ebefd61c1..f27793140 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -203,3 +203,74 @@ git worktree add -b my-feature ../rust2 master You can then use that rust2 folder as a separate workspace for modifying and building `rustc`! + +## Using nix-shell + +If you're using nix, you can use the following nix-shell to work on Rust: + +```nix +{ pkgs ? import {} }: + +# This file contains a development shell for working on rustc. +let + # Build configuration for rust-lang/rust. Based on `config.toml.example` from + # `1bd30ce2aac40c7698aa4a1b9520aa649ff2d1c5`. + config = pkgs.writeText "rustc-config" '' + profile = "compiler" # you may want to choose a different profile, like `library` or `tools` + changelog-seen = 2 + + [build] + # The path to (or name of) the GDB executable to use. This is only used for + # executing the debuginfo test suite. + gdb = "${pkgs.gdb}/bin/gdb" + python = "${pkgs.python3Full}/bin/python" + + [rust] + debug = true + incremental = true + deny-warnings = false + + # Indicates whether some LLVM tools, like llvm-objdump, will be made available in the + # sysroot. + llvm-tools = true + + # Print backtrace on internal compiler errors during bootstrap + backtrace-on-ice = true + ''; + + ripgrepConfig = + let + # Files that are ignored by ripgrep when searching. + ignoreFile = pkgs.writeText "rustc-rgignore" '' + configure + config.toml.example + x.py + LICENSE-MIT + LICENSE-APACHE + COPYRIGHT + **/*.txt + **/*.toml + **/*.yml + **/*.nix + *.md + src/ci + src/etc/ + src/llvm-emscripten/ + src/llvm-project/ + src/rtstartup/ + src/rustllvm/ + src/stdsimd/ + src/tools/rls/rls-analysis/test_data/ + ''; + in + pkgs.writeText "rustc-ripgreprc" "--ignore-file=${ignoreFile}"; +in +pkgs.mkShell { + name = "rustc"; + nativeBuildInputs = with pkgs; [ + gcc9 binutils cmake ninja openssl pkgconfig python39 git curl cacert patchelf nix psutils + ]; + RIPGREP_CONFIG_PATH = ripgrepConfig; + RUST_BOOTSTRAP_CONFIG = config; +} +``` From e8129ee10539d431662da0ee4bce5dd758a8f23c Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 12 Mar 2021 08:21:10 +0900 Subject: [PATCH 1468/1812] Trigger GHA only on the original repo --- .github/workflows/ci.yml | 3 ++- .github/workflows/date-check.yml | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index c3307bb74..a2b9cc30d 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -11,6 +11,7 @@ on: jobs: ci: + if: github.repository == 'rust-lang/rustc-dev-guide' runs-on: ubuntu-latest env: MDBOOK_VERSION: 0.4.7 @@ -63,7 +64,7 @@ jobs: run: mdbook build - name: Deploy to gh-pages - if: github.event_name == 'push' && github.repository == 'rust-lang/rustc-dev-guide' + if: github.event_name == 'push' run: | touch "${{ env.DEPLOY_DIR }}/.nojekyll" cp CNAME "${{ env.DEPLOY_DIR }}" diff --git a/.github/workflows/date-check.yml b/.github/workflows/date-check.yml index 411117235..c787da071 100644 --- a/.github/workflows/date-check.yml +++ b/.github/workflows/date-check.yml @@ -10,6 +10,7 @@ on: jobs: date-check: + if: github.repository == 'rust-lang/rustc-dev-guide' runs-on: ubuntu-latest steps: From 6448a3ebddb439461efc39280fb40928dcaa5b0d Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 13 Mar 2021 06:11:30 +0900 Subject: [PATCH 1469/1812] Replace some Travis-related things completely --- README.md | 2 +- ci/linkcheck.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 459564364..99502bcc6 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -[![Travis CI badge](https://api.travis-ci.com/rust-lang/rustc-dev-guide.svg?branch=master)](https://travis-ci.com/github/rust-lang/rustc-dev-guide) +[![CI](https://github.com/rust-lang/rustc-dev-guide/actions/workflows/ci.yml/badge.svg)](https://github.com/rust-lang/rustc-dev-guide/actions/workflows/ci.yml) This is a collaborative effort to build a guide that explains how rustc diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index 884823548..f939a7bd8 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -28,4 +28,4 @@ else # running locally echo "Checking files changed in $COMMIT_RANGE: $CHANGED_FILES" fi -exec mdbook-linkcheck $FLAGS -- $TRAVIS_BUILD_DIR +exec mdbook-linkcheck $FLAGS -- $GITHUB_WORKSPACE From 0355e125bf923d8f6157122de74906b013f1bedc Mon Sep 17 00:00:00 2001 From: JohnTitor Date: Fri, 26 Mar 2021 09:58:24 +0900 Subject: [PATCH 1470/1812] Remove the possible unnecessary flag --- ci/linkcheck.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/linkcheck.sh b/ci/linkcheck.sh index f939a7bd8..5d49d1337 100755 --- a/ci/linkcheck.sh +++ b/ci/linkcheck.sh @@ -28,4 +28,4 @@ else # running locally echo "Checking files changed in $COMMIT_RANGE: $CHANGED_FILES" fi -exec mdbook-linkcheck $FLAGS -- $GITHUB_WORKSPACE +exec mdbook-linkcheck $FLAGS From e72b43a64925ce053dc7830e21c1a57ba00499bd Mon Sep 17 00:00:00 2001 From: Camelid Date: Tue, 27 Apr 2021 12:35:37 -0700 Subject: [PATCH 1471/1812] Suggest using `git range-diff` (#1092) I have found it to be very helpful when rebasing. --- src/git.md | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/src/git.md b/src/git.md index e533426cf..e1b0e0292 100644 --- a/src/git.md +++ b/src/git.md @@ -217,6 +217,7 @@ there are no glaring errors. Once you're all done fixing the conflicts, you need to stage the files that had conflicts in them via `git add`. Afterwards, run `git rebase --continue` to let Git know that you've resolved the conflicts and it should finish the rebase. + Once the rebase has succeeded, you'll want to update the associated branch on your fork with `git push --force-with-lease`. @@ -263,6 +264,65 @@ You also may want to squash just the last few commits together, possibly because they only represent "fixups" and not real changes. For example, `git rebase --interactive HEAD~2` will allow you to edit the two commits only. +### `git range-diff` + +After completing a rebase, and before pushing up your changes, you may want to +review the changes between your old branch and your new one. You can do that +with `git range-diff master @{upstream} HEAD`. + +The first argument to `range-diff`, `master` in this case, is the base revision +that you're comparing your old and new branch against. The second argument is +the old version of your branch; in this case, `@upstream` means the version that +you've pushed to GitHub, which is the same as what people will see in your pull +request. Finally, the third argument to `range-diff` is the *new* version of +your branch; in this case, it is `HEAD`, which is the commit that is currently +checked-out in your local repo. + +Note that you can also use the equivalent, abbreviated form `git range-diff +master @{u} HEAD`. + +Unlike in regular Git diffs, you'll see a `-` or `+` next to another `-` or `+` +in the range-diff output. The marker on the left indicates a change between the +old branch and the new branch, and the marker on the right indicates a change +you've committed. So, you can think of a range-diff as a "diff of diffs" since +it shows you the differences between your old diff and your new diff. + +Here's an example of `git range-diff` output (taken from [Git's +docs][range-diff-example-docs]): + +``` +-: ------- > 1: 0ddba11 Prepare for the inevitable! +1: c0debee = 2: cab005e Add a helpful message at the start +2: f00dbal ! 3: decafe1 Describe a bug + @@ -1,3 +1,3 @@ + Author: A U Thor + + -TODO: Describe a bug + +Describe a bug + @@ -324,5 +324,6 + This is expected. + + -+What is unexpected is that it will also crash. + ++Unexpectedly, it also crashes. This is a bug, and the jury is + ++still out there how to fix it best. See ticket #314 for details. + + Contact +3: bedead < -: ------- TO-UNDO +``` + +(Note that `git range-diff` output in your terminal will probably be easier to +read than in this example because it will have colors.) + +Another feature of `git range-diff` is that, unlike `git diff`, it will also +diff commit messages. This feature can be useful when amending several commit +messages so you can make sure you changed the right parts. + +`git range-diff` is a very useful command, but note that it can take some time +to get used to its output format. You may also find Git's documentation on the +command useful, especially their ["Examples" section][range-diff-example-docs]. + +[range-diff-example-docs]: https://git-scm.com/docs/git-range-diff#_examples + ## No-Merge Policy The rust-lang/rust repo uses what is known as a "rebase workflow." This means From b12bee89a0aae135dbe6f21bae5e2745756b4cb1 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Thu, 29 Apr 2021 16:40:25 -0400 Subject: [PATCH 1472/1812] Link to Zulip search for finding the most recent check-in (#1118) --- ci/check-in.sh | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/ci/check-in.sh b/ci/check-in.sh index 323b75d67..4477789c7 100755 --- a/ci/check-in.sh +++ b/ci/check-in.sh @@ -5,7 +5,10 @@ set -eu # This is not a very smart script if [ $# != 2 ]; then echo "usage: $0 " - if [ $# = 1 ] ; then + if [ $# = 0 ]; then + echo "help: you can find the last check-in at" \ + "https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/search/wg-rustc-dev-guide" + elif [ $# = 1 ] ; then echo "help: you can find the number of PRs merged at" \ "https://github.com/rust-lang/rustc-dev-guide/pulls?q=is%3Apr+is%3Amerged+updated%3A%3E$1" fi From 5b63bc2fb7f714f7510543af0c0c3235157bccaa Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 5 May 2021 13:53:42 +0200 Subject: [PATCH 1473/1812] add 'waiting-for-review' incantation to main contrib page (#1124) --- src/contributing.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index abe1bb839..02ae1159c 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -147,8 +147,12 @@ rebase when bringing the latest changes from the master branch to your feature branch. Also, please make sure that fixup commits are squashed into other related commits with meaningful commit messages. -If you encounter merge conflicts, your PR will get marked as `S-waiting-on-author`. -When you resolve them, you should use `@rustbot` to mark it as `S-waiting-on-review`. +If you encounter merge conflicts or when a reviewer asks you to perform some +changes, your PR will get marked as `S-waiting-on-author`. When you resolve +them, you should use `@rustbot` to mark it as `S-waiting-on-review`: + + @rustbot label -S-waiting-on-author +S-waiting-on-review + See [this chapter][labeling] for more details. GitHub allows [closing issues using keywords][closing-keywords]. This feature From 1e6c7fbda4c45e85adf63ff3f82fa9c870b1447f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E4=BA=8C=E6=89=8B=E6=8E=89=E5=8C=85=E5=B7=A5=E7=A8=8B?= =?UTF-8?q?=E5=B8=88?= Date: Mon, 10 May 2021 12:38:24 +0800 Subject: [PATCH 1474/1812] Unified CPU Requirements (#1126) --- src/building/prerequisites.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index f7f47d40c..be5d96ad9 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -47,7 +47,7 @@ These are not so much requirements as _recommendations_: * ~15GB of free disk space (~25GB or more if doing incremental builds). * \>= 8GB RAM -* \>= 4 cores +* \>= 2 cores * Internet access Beefier machines will lead to much faster builds. If your machine is not very From f58dfe98ad5ee7faa18bb73564533e247f979bc1 Mon Sep 17 00:00:00 2001 From: Smittyvb Date: Thu, 13 May 2021 14:51:43 -0400 Subject: [PATCH 1475/1812] Document -Zunpretty=thir-tree (#1128) * document -Zunpretty=thir-tree * Update position/wording --- src/thir.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/thir.md b/src/thir.md index b023eb2e2..0a0218c6b 100644 --- a/src/thir.md +++ b/src/thir.md @@ -39,6 +39,9 @@ will be allocated. Dropping this arena will result in the THIR being destroyed, which is useful to keep peak memory in check. Having a THIR representation of all bodies of a crate in memory at the same time would be very heavy. +You can get a debug representation of the THIR by passing the `-Zunpretty=thir-tree` flag +to `rustc`. + [thir-docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/index.html [`thir::Expr`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/struct.Expr.html [`build_thir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/fn.build_thir.html From c989a4db5b2c7996ed48c4b5ec4247be518703d6 Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Thu, 13 May 2021 19:19:43 -0700 Subject: [PATCH 1476/1812] Update coverage docs (#1122) --- src/llvm-coverage-instrumentation.md | 142 ++++++++++++++------------- 1 file changed, 72 insertions(+), 70 deletions(-) diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 8a044849f..728805387 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -28,11 +28,12 @@ them), and generate various reports for analysis, for example:
    Detailed instructions and examples are documented in the -[Rust Unstable Book (under _source-based-code-coverage_)][unstable-book-sbcc]. +[Rust Unstable Book (under +_compiler-flags/instrument-coverage_)][unstable-book-instrument-coverage]. [llvm-instrprof-increment]: https://llvm.org/docs/LangRef.html#llvm-instrprof-increment-intrinsic -[Coverage Map]: https://llvm.org/docs/CoverageMappingFormat.html -[unstable-book-sbcc]: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/source-based-code-coverage.html +[coverage map]: https://llvm.org/docs/CoverageMappingFormat.html +[unstable-book-instrument-coverage]: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/instrument-coverage.html ## Rust symbol mangling @@ -82,7 +83,7 @@ a span of code ([`CodeRegion`][code-region]). It counts the number of times a branch is executed, and also specifies the exact location of that code span in the Rust source code. -Note that many of these `Coverage` statements will *not* be converted into +Note that many of these `Coverage` statements will _not_ be converted into physical counters (or any other executable instructions) in the final binary. Some of them will be (see `CoverageKind::`[`Counter`][counter-coverage-kind]), but other counters can be computed on the fly, when generating a coverage @@ -111,7 +112,7 @@ fn some_func(flag: bool) { In this example, four contiguous code regions are counted while only incrementing two counters. -CFG analysis is used to not only determine *where* the branches are, for +CFG analysis is used to not only determine _where_ the branches are, for conditional expressions like `if`, `else`, `match`, and `loop`, but also to determine where expressions can be used in place of physical counters. @@ -150,40 +151,41 @@ MIR `Statement` into some backend-specific action or instruction. match statement.kind { ... mir::StatementKind::Coverage(box ref coverage) => { - self.codegen_coverage(&mut bx, coverage.clone()); + self.codegen_coverage(&mut bx, coverage.clone(), statement.source_info.scope); bx } ``` - `codegen_coverage()` handles each `CoverageKind` as follows: -* For all `CoverageKind`s, Coverage data (counter ID, expression equation +- For all `CoverageKind`s, Coverage data (counter ID, expression equation and ID, and code regions) are passed to the backend's `Builder`, to populate data structures that will be used to generate the crate's "Coverage Map". (See the [`FunctionCoverage`][function-coverage] `struct`.) -* For `CoverageKind::Counter`s, an instruction is injected in the backend +- For `CoverageKind::Counter`s, an instruction is injected in the backend IR to increment the physical counter, by calling the `BuilderMethod` [`instrprof_increment()`][instrprof-increment]. ```rust - pub fn codegen_coverage(&self, bx: &mut Bx, coverage: Coverage) { + pub fn codegen_coverage(&self, bx: &mut Bx, coverage: Coverage, scope: SourceScope) { + ... + let instance = ... // the scoped instance (current or inlined function) let Coverage { kind, code_region } = coverage; match kind { CoverageKind::Counter { function_source_hash, id } => { - if let Some(code_region) = code_region { - bx.add_coverage_counter(self.instance, id, code_region); - } + ... + bx.add_coverage_counter(instance, id, code_region); ... bx.instrprof_increment(fn_name, hash, num_counters, index); } CoverageKind::Expression { id, lhs, op, rhs } => { - bx.add_coverage_counter_expression(self.instance, id, lhs, op, rhs, code_region); + bx.add_coverage_counter_expression(instance, id, lhs, op, rhs, code_region); } CoverageKind::Unreachable => { - ... + bx.add_coverage_unreachable( + instance, + code_region.expect(... ``` -_code snippet trimmed for brevity_ > The function name `instrprof_increment()` is taken from the LLVM intrinsic call of the same name ([`llvm.instrprof.increment`][llvm-instrprof-increment]), @@ -221,7 +223,7 @@ properly-configured variables in LLVM IR, according to very specific details of the [_LLVM Coverage Mapping Format_][coverage-mapping-format] (Version 4).[^llvm-and-covmap-versions] -[^llvm-and-covmap-versions]: The Rust compiler (as of +[^llvm-and-covmap-versions]: The Rust compiler (as of January 2021) supports _LLVM Coverage Mapping Format_ Version 4 (the most up-to-date version of the format, at the time of this writing) for improved compatibility with other LLVM-based compilers (like _Clang_), and to take @@ -233,13 +235,16 @@ instrument-coverage` will generate an error message. ```rust pub fn finalize<'ll, 'tcx>(cx: &CodegenCx<'ll, 'tcx>) { + ... + if !tcx.sess.instrument_coverage_except_unused_functions() { + add_unused_functions(cx); + } + let mut function_coverage_map = match cx.coverage_context() { Some(ctx) => ctx.take_function_coverage_map(), None => return, }; ... - add_unreachable_coverage(tcx, &mut function_coverage_map); - let mut mapgen = CoverageMapGenerator::new(); for (instance, function_coverage) in function_coverage_map { @@ -250,56 +255,51 @@ pub fn finalize<'ll, 'tcx>(cx: &CodegenCx<'ll, 'tcx>) { ``` _code snippet trimmed for brevity_ -One notable step, performed by `mapgen::finalize()` before processing the -`Instance`s and their `FunctionCoverage`s, is the call to -[`add_unreachable_functions()`][add-unreachable-coverage]. +One notable first step performed by `mapgen::finalize()` is the call to +[`add_unused_functions()`][add-unused-functions]: -When finalizing the coverage map, `FunctionCoverage` only has the `CodeRegion`s and counters for -the functions that went through codegen; such as public functions and "used" functions -(functions referenced by other "used" or public items). Any other functions (considered unused -or "Unreachable") were still parsed and processed through the MIR stage. +When finalizing the coverage map, `FunctionCoverage` only has the `CodeRegion`s +and counters for the functions that went through codegen; such as public +functions and "used" functions (functions referenced by other "used" or public +items). Any other functions (considered unused) were still parsed and processed +through the MIR stage. -The set of unreachable functions is computed via the set difference of all MIR -`DefId`s (`tcx` query `mir_keys`) minus the codegenned `DefId`s -(`tcx` query `collect_and_partition_mono_items`). `add_unreachable_functions()` -computes the set of unreachable functions, queries the `tcx` for the -previously-computed `CodeRegions`, for each unreachable MIR, and adds those code -regions to one of the non-generic codegenned functions (non-generic avoids -potentially injecting the unreachable coverage multiple times for multiple -instantiations). +The set of unused functions is computed via the set difference of all MIR +`DefId`s (`tcx` query `mir_keys`) minus the codegenned `DefId`s (`tcx` query +`codegened_and_inlined_items`). `add_unused_functions()` computes the set of +unused functions, queries the `tcx` for the previously-computed `CodeRegions`, +for each unused MIR, synthesizes an LLVM function (with no internal statements, +since it will not be called), and adds a new `FunctionCoverage`, with +`Unreachable` code regions. [compile-codegen-unit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/base/fn.compile_codegen_unit.html [coverageinfo-finalize]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/context/struct.CodegenCx.html#method.coverageinfo_finalize [mapgen-finalize]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/coverageinfo/mapgen/fn.finalize.html [coverage-mapping-format]: https://llvm.org/docs/CoverageMappingFormat.html -[add-unreachable-coverage]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/coverageinfo/mapgen/fn.add_unreachable_coverage.html +[add-unused-functions]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/coverageinfo/mapgen/fn.add_unused_functions.html ## Testing LLVM Coverage Coverage instrumentation in the MIR is validated by a `mir-opt` test: [`instrument-coverage`][mir-opt-test]. -More complete testing of end-to-end coverage instrumentation and reports are done -in the `run-make-fulldeps` tests, with sample Rust programs (to be instrumented) -in the [`coverage`][coverage-test-samples] directory, and the actual tests and expected -results in [`coverage-reports`]. - -In addition to testing the final result, two intermediate results are also validated -to catch potential regression errors early: Minimum `CoverageSpan`s computed during -the `InstrumentCoverage` MIR pass are saved in `mir_dump` [Spanview][spanview-debugging] -files and compared to expected results in [`coverage-spanview`]. +More complete testing of end-to-end coverage instrumentation and reports are +done in the `run-make-fulldeps` tests, with sample Rust programs (to be +instrumented) in the [`coverage`][coverage-test-samples] directory, and the +actual tests and expected results in [`coverage-reports`]. -Finally, the [`coverage-llvmir`] test compares compiles a simple Rust program with -`-Z instrument-coverage` and compares the compiled program's LLVM IR to expected -LLVM IR instructions and structured data for a coverage-enabled program, including -various checks for Coverage Map-related metadata and the LLVM intrinsic calls to -increment the runtime counters. +Finally, the [`coverage-llvmir`] test compares compiles a simple Rust program +with `-Z instrument-coverage` and compares the compiled program's LLVM IR to +expected LLVM IR instructions and structured data for a coverage-enabled +program, including various checks for Coverage Map-related metadata and the LLVM +intrinsic calls to increment the runtime counters. Expected results for both the `mir-opt` tests and the `coverage*` tests under `run-make-fulldeps` can be refreshed by running: ```shell -$ ./x.py test src/test/ --blessed +$ ./x.py test mir-opt --blessed +$ ./x.py test src/test/run-make-fulldeps/coverage --blessed ``` [mir-opt-test]: https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/instrument_coverage.rs @@ -396,16 +396,18 @@ contrast with the [`SimplifyCfg`][simplify-cfg] MIR pass, this step does not alter the MIR itself, because the `CoverageGraph` aggressively simplifies the CFG, and ignores nodes that are not relevant to coverage. For example: - * The BCB CFG ignores (excludes) branches considered not relevant + - The BCB CFG ignores (excludes) branches considered not relevant to the current coverage solution. It excludes unwind-related code[^78544] that is injected by the Rust compiler but has no physical source code to count, which allows a `Call`-terminated BasicBlock to be merged with its successor, within a single BCB. - * A `Goto`-terminated `BasicBlock` can be merged with its successor - ***as long as*** it has the only incoming edge to the successor `BasicBlock`. - * Some BasicBlock terminators support Rust-specific concerns--like borrow-checking--that are - not relevant to coverage analysis. `FalseUnwind`, for example, can be treated the same as - a `Goto` (potentially merged with its successor into the same BCB). + - A `Goto`-terminated `BasicBlock` can be merged with its successor + **_as long as_** it has the only incoming edge to the successor + `BasicBlock`. + - Some BasicBlock terminators support Rust-specific concerns--like + borrow-checking--that are not relevant to coverage analysis. `FalseUnwind`, + for example, can be treated the same as a `Goto` (potentially merged with + its successor into the same BCB). [^78544]: (Note, however, that Issue [#78544][rust-lang/rust#78544] considers providing future support for coverage of programs that intentionally @@ -448,24 +450,24 @@ directional edges (the arrows) leading from each node to its `successors()`. The nodes contain information in sections: 1. The gray header has a label showing the BCB ID (or _index_ for looking up -its `BasicCoverageBlockData`). + its `BasicCoverageBlockData`). 2. The first content section shows the assigned `Counter` or `Expression` for -each contiguous section of code. (There may be more than one `Expression` -incremented by the same `Counter` for discontiguous sections of code representing -the same sequential actions.) Note the code is represented by the line and -column ranges (for example: `52:28-52:33`, representing the original source -line 52, for columns 28-33). These are followed by the MIR `Statement` or -`Terminator` represented by that source range. (How these coverage regions -are determined is discussed in the following section.) + each contiguous section of code. (There may be more than one `Expression` + incremented by the same `Counter` for discontiguous sections of code + representing the same sequential actions.) Note the code is represented by + the line and column ranges (for example: `52:28-52:33`, representing the + original source line 52, for columns 28-33). These are followed by the MIR + `Statement` or `Terminator` represented by that source range. (How these + coverage regions are determined is discussed in the following section.) 3. The final section(s) show the MIR `BasicBlock`s (by ID/index and its -`TerminatorKind`) contained in this BCB. The last BCB is separated out because -its `successors()` determine the edges leading out of the BCB, and into -the `leading_bb()` (first `BasicBlock`) of each successor BCB. + `TerminatorKind`) contained in this BCB. The last BCB is separated out + because its `successors()` determine the edges leading out of the BCB, and + into the `leading_bb()` (first `BasicBlock`) of each successor BCB. Note, to find the `BasicCoverageBlock` from a final BCB `Terminator`'s successor `BasicBlock`, there is an index and helper -function--[`bcb_from_bb()`][bcb-from-bb]--to look up a `BasicCoverageBlock` from _any_ -contained `BasicBlock`. +function--[`bcb_from_bb()`][bcb-from-bb]--to look up a `BasicCoverageBlock` from +*any* contained `BasicBlock`. [directed-graph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/graph/trait.DirectedGraph.html [graph-traits]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/graph/index.html#traits @@ -572,7 +574,7 @@ incoming edges. Given the following graph, for example, the count for In this situation, BCB node `B` may require an edge counter for its "edge from A", and that edge might be computed from an `Expression`, -`Counter(A) - Counter(C)`. But an expression for the BCB _node_ `B` +`Counter(A) - Counter(C)`. But an expression for the BCB _node_ `B` would be the sum of all incoming edges: ```text From 8faa1646f5c104c6fbeaaa1b860249d78ef666a0 Mon Sep 17 00:00:00 2001 From: Justus K Date: Tue, 18 May 2021 19:10:39 +0200 Subject: [PATCH 1477/1812] Remove `--stage 1` argument from `doc` invocations (#1125) --- src/rustdoc-internals.md | 2 +- src/rustdoc.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index b2dc2f7fd..7ae68cc21 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -245,7 +245,7 @@ server. To test these features locally, you can run a local HTTP server, like this: ```bash -$ ./x.py doc library/std --stage 1 +$ ./x.py doc library/std # The documentation has been generated into `build/[YOUR ARCH]/doc`. $ python3 -m http.server -d build/[YOUR ARCH]/doc ``` diff --git a/src/rustdoc.md b/src/rustdoc.md index 88177ccba..2123d2b74 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -42,7 +42,7 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1` previously, then after the previous build command, `cargo +local doc` will Just Work. -* Use `./x.py doc --stage 1 library/std` to use this rustdoc to generate the +* Use `./x.py doc library/std` to use this rustdoc to generate the standard library docs. * The completed docs will be available in `build/$TARGET/doc/std`, though the bundle is meant to be used as though you would copy out the `doc` folder to From 50de7f0682adc5d95ce858fe6318d19b4b951553 Mon Sep 17 00:00:00 2001 From: Caleb Cartwright Date: Thu, 20 May 2021 08:02:20 -0500 Subject: [PATCH 1478/1812] update rustfmt references to reflect change from submod to subtree (#1129) * update rustfmt references to reflect change to subtree * clarify broken toolstate hypothetical scenario --- src/contributing.md | 30 +++++++++++++++--------------- src/git.md | 5 ++--- 2 files changed, 17 insertions(+), 18 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 02ae1159c..c07987f30 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -169,7 +169,8 @@ the issue in question. As a developer to this repository, you don't have to treat the following external projects differently from other crates that are directly in this repo: -* Clippy +* [Clippy](https://github.com/rust-lang/rust-clippy) +* [rustfmt](https://github.com/rust-lang/rustfmt) They are just regular files and directories. This is in contrast to `submodule` dependencies (see below for those). Only tool authors will actually use any operations here. @@ -233,7 +234,6 @@ subtrees) actually needs to use `git subtree`. Currently building Rust will also build the following external projects: * [miri](https://github.com/rust-lang/miri) -* [rustfmt](https://github.com/rust-lang/rustfmt) * [rls](https://github.com/rust-lang/rls/) We allow breakage of these tools in the nightly channel. Maintainers of these @@ -261,7 +261,7 @@ before the PR is merged. Rust's build system builds a number of tools that make use of the internals of the compiler. This includes [RLS](https://github.com/rust-lang/rls) and -[rustfmt](https://github.com/rust-lang/rustfmt). If these tools +[miri](https://github.com/rust-lang/miri). If these tools break because of your changes, you may run into a sort of "chicken and egg" problem. These tools rely on the latest compiler to be built so you can't update them to reflect your changes to the compiler until those changes are merged into @@ -269,8 +269,8 @@ the compiler. At the same time, you can't get your changes merged into the compi because the rust-lang/rust build won't pass until those tools build and pass their tests. -That means that, in the default state, you can't update the compiler without first -fixing rustfmt, rls and the other tools that the compiler builds. +That would mean that, in the default state, you couldn't update the compiler without first +fixing miri, rls and the other tools that the compiler builds. Luckily, a feature was [added to Rust's build](https://github.com/rust-lang/rust/issues/45861) to make all of this easy to handle. The idea is that we allow these tools to be "broken", @@ -280,7 +280,7 @@ and the tools are working again, you go back in the compiler and update the tool so they can be distributed again. This should avoid a bunch of synchronization dances and is also much easier on contributors as -there's no need to block on rls/rustfmt/other tools changes going upstream. +there's no need to block on rls/miri/other tools changes going upstream. Here are those same steps in detail: @@ -290,8 +290,8 @@ Here are those same steps in detail: from resetting to the original branch after you make your changes. If you need to [update any submodules to their latest versions](#updating-submodules), see the section of this file about that for more information. -2. (optional) Run `./x.py test src/tools/rustfmt` (substituting the submodule - that broke for `rustfmt`). Fix any errors in the submodule (and possibly others). +2. (optional) Run `./x.py test src/tools/rls` (substituting the submodule + that broke for `rls`). Fix any errors in the submodule (and possibly others). 3. (optional) Make commits for your changes and send them to upstream repositories as a PR. 4. (optional) Maintainers of these submodules will **not** merge the PR. The PR can't be merged because CI will be broken. You'll want to write a message on the PR referencing @@ -303,16 +303,16 @@ Here are those same steps in detail: #### Updating submodules -These instructions are specific to updating `rustfmt`, however they may apply +These instructions are specific to updating `rls`, however they may apply to the other submodules as well. Please help by improving these instructions if you find any discrepancies or special cases that need to be addressed. -To update the `rustfmt` submodule, start by running the appropriate +To update the `rls` submodule, start by running the appropriate [`git submodule` command](https://git-scm.com/book/en/v2/Git-Tools-Submodules). For example, to update to the latest commit on the remote master branch, you may want to run: ``` -git submodule update --remote src/tools/rustfmt +git submodule update --remote src/tools/rls ``` If you run `./x.py build` now, and you are lucky, it may just work. If you see an error message about patches that did not resolve to any crates, you will need @@ -320,10 +320,10 @@ to complete a few more steps which are outlined with their rationale below. *(This error may change in the future to include more information.)* ``` -error: failed to resolve patches for `https://github.com/rust-lang/rustfmt` +error: failed to resolve patches for `https://github.com/rust-lang/rls` Caused by: - patch for `rustfmt-nightly` in `https://github.com/rust-lang/rustfmt` did not resolve to any crates + patch for `rls` in `https://github.com/rust-lang/rls` did not resolve to any crates failed to run: ~/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path ~/rust/src/bootstrap/Cargo.toml ``` @@ -354,14 +354,14 @@ reveals what the problem is: > crates.io, but it's important to keep this in mind! This says that when we updated the submodule, the version number in our -`src/tools/rustfmt/Cargo.toml` changed. The new version is different from +`src/tools/rls/Cargo.toml` changed. The new version is different from the version in `Cargo.lock`, so the build can no longer continue. To resolve this, we need to update `Cargo.lock`. Luckily, cargo provides a command to do this easily. ``` -$ cargo update -p rustfmt-nightly +$ cargo update -p rls ``` This should change the version listed in `Cargo.lock` to the new version you updated diff --git a/src/git.md b/src/git.md index e1b0e0292..e10f1d705 100644 --- a/src/git.md +++ b/src/git.md @@ -139,7 +139,6 @@ Changes not staged for commit: (use "git restore ..." to discard changes in working directory) modified: src/tools/cargo (new commits) modified: src/tools/rls (new commits) - modified: src/tools/rustfmt (new commits) no changes added to commit (use "git add" and/or "git commit -a") ``` @@ -347,9 +346,9 @@ you might want to get used to the main concepts of Git before reading this secti The `rust-lang/rust` repository uses [Git submodules] as a way to use other Rust projects from within the `rust` repo. Examples include Rust's fork of -`llvm-project` and many devtools such as `cargo`, `rust-analyzer` and `rustfmt`. +`llvm-project` and many devtools such as `cargo`, `rust-analyzer` and `rls`. -Those projects are developped and maintained in an separate Git (and GitHub) +Those projects are developed and maintained in an separate Git (and GitHub) repository, and they have their own Git history/commits, issue tracker and PRs. Submodules allow us to create some sort of embedded sub-repository inside the `rust` repository and use them like they were directories in the `rust` repository. From 12f9ede97705154ac848d2caf0409f72bf7c531f Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 25 May 2021 17:05:34 -0700 Subject: [PATCH 1479/1812] Describe the difference of rustc_lint vs rustc_lint_defs. --- src/diagnostics.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index f4e71bbdc..38683f98d 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -484,9 +484,13 @@ module. ### Declaring a lint The built-in compiler lints are defined in the [`rustc_lint`][builtin] -crate. +crate. Lints that need to be implemented in other crates are defined in +[`rustc_lint_defs`]. You should prefer to place lints in `rustc_lint` if +possible. One benefit is that it is close to the dependency root, so it can be +much faster to work on. [builtin]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/index.html +[`rustc_lint_defs`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/index.html Every lint is implemented via a `struct` that implements the `LintPass` `trait` (you also implement one of the more specific lint pass traits, either From 99e60b3302559e90adcd32f4055aab74a46963d5 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 12 May 2021 17:00:39 +0200 Subject: [PATCH 1480/1812] not all tools require waiting for a nightly release before they can be fixed --- src/contributing.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index c07987f30..20f76176b 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -272,12 +272,16 @@ tests. That would mean that, in the default state, you couldn't update the compiler without first fixing miri, rls and the other tools that the compiler builds. -Luckily, a feature was [added to Rust's build](https://github.com/rust-lang/rust/issues/45861) -to make all of this easy to handle. The idea is that we allow these tools to be "broken", -so that the rust-lang/rust build passes without trying to build them, then land the change -in the compiler, wait for a nightly, and go update the tools that you broke. Once you're done -and the tools are working again, you go back in the compiler and update the tools -so they can be distributed again. +Luckily, a feature was +[added to Rust's build](https://github.com/rust-lang/rust/issues/45861) to make +all of this easy to handle. The idea is that we allow these tools to be +"broken", so that the rust-lang/rust build passes without trying to build them, +then land the change in the compiler, and go update the tools that you +broke. Some tools will require waiting for a nightly release before this can +happen, while others use the builds uploaded after each bors merge and thus can +be updated immediately (check the tool's documentation for details). Once you're +done and the tools are working again, you go back in the compiler and update the +tools so they can be distributed again. This should avoid a bunch of synchronization dances and is also much easier on contributors as there's no need to block on rls/miri/other tools changes going upstream. From f6f83e2fae80060924dc79866bc261d4b00d0054 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 26 May 2021 12:22:20 +0200 Subject: [PATCH 1481/1812] improve section introduction --- src/contributing.md | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 20f76176b..cf049015d 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -258,19 +258,16 @@ before the PR is merged. #### Breaking Tools Built With The Compiler -Rust's build system builds a number of tools that make use of the -internals of the compiler. This includes -[RLS](https://github.com/rust-lang/rls) and -[miri](https://github.com/rust-lang/miri). If these tools -break because of your changes, you may run into a sort of "chicken and egg" -problem. These tools rely on the latest compiler to be built so you can't update -them to reflect your changes to the compiler until those changes are merged into -the compiler. At the same time, you can't get your changes merged into the compiler -because the rust-lang/rust build won't pass until those tools build and pass their -tests. - -That would mean that, in the default state, you couldn't update the compiler without first -fixing miri, rls and the other tools that the compiler builds. +Rust's build system builds a number of tools that make use of the internals of +the compiler and that are hosted in a separate repository, and included in Rust +via git submodules. This includes [RLS](https://github.com/rust-lang/rls) and +[Miri](https://github.com/rust-lang/Miri). If these tools break because of your +changes, you may run into a sort of "chicken and egg" problem. These tools rely +on the latest compiler to be built so you can't update them (in their own +repositories) to reflect your changes to the compiler until those changes are +merged into the compiler. At the same time, you can't get your changes merged +into the compiler because the rust-lang/rust build won't pass until those tools +build and pass their tests. Luckily, a feature was [added to Rust's build](https://github.com/rust-lang/rust/issues/45861) to make From 70e979a51916992dced99969af83b2c7700b8f82 Mon Sep 17 00:00:00 2001 From: Michael Woerister Date: Fri, 28 May 2021 17:23:27 +0200 Subject: [PATCH 1482/1812] Add more information about no_hash query modifier. (#1133) --- .../incremental-compilation-in-detail.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index f0c6dcacd..f81e02d28 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -433,6 +433,26 @@ respect to incremental compilation: the result of the query has changed. As a consequence anything depending on a `no_hash` query will always be re-executed. + Using `no_hash` for a query can make sense in two circumstances: + + - If the result of the query is very likely to change whenever one of its + inputs changes, e.g. a function like `|a, b, c| -> (a * b * c)`. In such + a case recomputing the query will always yield a red node if one of the + inputs is red so we can spare us the trouble and default to red immediately. + A counter example would be a function like `|a| -> (a == 42)` where the + result does not change for most changes of `a`. + + - If the result of a query is a big, monolithic collection (e.g. `index_hir`) + and there are "projection queries" reading from that collection + (e.g. `hir_owner`). In such a case the big collection will likely fulfill the + condition above (any changed input means recomputing the whole collection) + and the results of the projection queries will be hashed anyway. If we also + hashed the collection query it would mean that we effectively hash the same + data twice: once when hashing the collection and another time when hashing all + the projection query results. `no_hash` allows us to avoid that redundancy + and the projection queries act as a "firewall", shielding their dependents + from the unconditionally red `no_hash` node. + - `cache_on_disk_if` - This attribute is what determines which query results are persisted in the incremental compilation query result cache. The attribute takes an expression that allows per query invocation From 78204563e2c8e06b18fedf28d4443f67a69a7b28 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sat, 29 May 2021 21:21:49 +0200 Subject: [PATCH 1483/1812] explain Miri engine vs Miri-the-tool --- src/miri.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/miri.md b/src/miri.md index fd091d565..18cd6ed39 100644 --- a/src/miri.md +++ b/src/miri.md @@ -2,8 +2,13 @@ -Miri (**MIR** **I**nterpreter) is a virtual machine for executing MIR without +The Miri (**MIR** **I**nterpreter) engine is a virtual machine for executing MIR without compiling to machine code. It is usually invoked via `tcx.const_eval_*` functions. +In the following, we will refer to the Miri engine as just "Miri", but note that +there also is a stand-alone +[tool called "Miri"](https://github.com/rust-lang/miri/) that is based on the +engine (sometimes referred to as Miri-the-tool to disambiguate it from the +engine). If you start out with a constant: From c8da5bfd1c7c71d90ef1646f5e0a9f6609d5c78a Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 4 Jun 2021 16:08:56 +0900 Subject: [PATCH 1484/1812] Fix some links (#1137) * Fix some links * Address review comment --- src/appendix/bibliography.md | 2 +- src/compiler-team.md | 4 ++-- src/identifiers.md | 2 +- src/query.md | 4 ++-- src/thir.md | 6 +++--- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index 0caed3faf..27529314c 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -11,7 +11,7 @@ Rust, as well as publications about Rust. * [Making ad-hoc polymorphism less ad hoc](https://dl.acm.org/doi/10.1145/75277.75283) * [Macros that work together](https://www.cs.utah.edu/plt/publications/jfp12-draft-fcdf.pdf) * [Traits: composable units of behavior](http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf) -* [Alias burying](http://www.cs.uwm.edu/faculty/boyland/papers/unique-preprint.ps) - We tried something similar and abandoned it. +* [Alias burying](https://dl.acm.org/doi/10.1002/spe.370) - We tried something similar and abandoned it. * [External uniqueness is unique enough](http://www.cs.uu.nl/research/techreps/UU-CS-2002-048.html) * [Uniqueness and Reference Immutability for Safe Parallelism](https://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf) * [Region Based Memory Management](https://www.cs.ucla.edu/~palsberg/tba/papers/tofte-talpin-iandc97.pdf) diff --git a/src/compiler-team.md b/src/compiler-team.md index 8cfcc5bb6..aac263484 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -11,7 +11,7 @@ contributions to rustc and its design. Currently the compiler team chats in Zulip: -- Team chat occurs in the `t-compiler` stream on [the Zulip instance][zulip] +- Team chat occurs in the [`t-compiler`][zulip-t-compiler] stream on the Zulip instance - There are also a number of other associated Zulip streams, such as [`t-compiler/help`][zulip-help], where people can ask for help with rustc development, or [`t-compiler/meetings`][zulip-meetings], @@ -60,8 +60,8 @@ The meeting currently takes place on Thursdays at 10am Boston time (UTC-4 typically, but daylight savings time sometimes makes things complicated). - [procedure]: ./bug-fix-procedure.md +[zulip-t-compiler]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler [zulip-help]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp [zulip-meetings]: https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings diff --git a/src/identifiers.md b/src/identifiers.md index 37e6a1c92..50d0c76e2 100644 --- a/src/identifiers.md +++ b/src/identifiers.md @@ -53,7 +53,7 @@ See the [HIR chapter][hir-map] for more detailed information. [`LocalDefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.LocalDefId.html [`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html [`BodyId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.BodyId.html -[`CrateNum`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/enum.CrateNum.html +[`CrateNum`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.CrateNum.html [`DefIndex`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefIndex.html [`Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Body.html [Node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.Node.html diff --git a/src/query.md b/src/query.md index 294d61fb3..aa3a81328 100644 --- a/src/query.md +++ b/src/query.md @@ -155,10 +155,10 @@ providers**. Almost all **extern providers** wind up going through the from the crate metadata. But in some cases there are crates that provide queries for *both* local and external crates, in which case they define both a `provide` and a `provide_extern` function, through -[`provide_both`][ext_provide_both], that `rustc_driver` can invoke. +[`wasm_import_module_map`][wasm_import_module_map], that `rustc_driver` can invoke. [rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html -[ext_provide_both]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/attributes/fn.provide_both.html +[wasm_import_module_map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/back/symbol_export/fn.wasm_import_module_map.html ### Adding a new kind of query diff --git a/src/thir.md b/src/thir.md index 0a0218c6b..a1d389907 100644 --- a/src/thir.md +++ b/src/thir.md @@ -34,7 +34,7 @@ But it has some other interesting features that distinguish it from the HIR: [HIR]: ./hir.md The THIR lives in [`rustc_mir_build::thir`][thir-docs]. To construct a [`thir::Expr`], -you can use the [`build_thir`] function, passing in the memory arena where the THIR +you can use the [`thir_body`] function, passing in the memory arena where the THIR will be allocated. Dropping this arena will result in the THIR being destroyed, which is useful to keep peak memory in check. Having a THIR representation of all bodies of a crate in memory at the same time would be very heavy. @@ -43,5 +43,5 @@ You can get a debug representation of the THIR by passing the `-Zunpretty=thir-t to `rustc`. [thir-docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/index.html -[`thir::Expr`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/struct.Expr.html -[`build_thir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/fn.build_thir.html +[`thir::Expr`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/thir/struct.Expr.html +[`thir_body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.thir_body From 072657e0a526769822c9e64fec281a01b33678a2 Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 20 Jan 2021 08:17:29 -0800 Subject: [PATCH 1485/1812] Add a section on keeping things up to date in the git section --- src/about-this-guide.md | 4 ++-- src/contributing.md | 3 ++- src/git.md | 47 +++++++++++++++++++++++++++++++++++++---- 3 files changed, 47 insertions(+), 7 deletions(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index d12f5a7a3..0ba753a62 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -10,8 +10,8 @@ There are six parts to this guide: useful no matter how you are contributing, about building, debugging, profiling, etc. 2. [Contributing to `rustc`][p1-5]: Contains information that should be useful - no matter how you are contributing, about procedures for contribution, - stabilizing features, etc. + no matter how you are contributing, about procedures for contribution, using git + and Github, stabilizing features, etc. 2. [High-Level Compiler Architecture][p2]: Discusses the high-level architecture of the compiler and stages of the compile process. 3. [Source Code Representation][p3]: Describes the process of taking raw source code from the user and diff --git a/src/contributing.md b/src/contributing.md index cf049015d..d8f7a79a1 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -64,7 +64,8 @@ Pull requests (or PRs for short) are the primary mechanism we use to change Rust GitHub itself has some [great documentation][about-pull-requests] on using the Pull Request feature. We use the "fork and pull" model [described here][development-models], where contributors push changes to their personal fork and create pull requests to -bring those changes into the source repository. +bring those changes into the source repository. We have more info about how to use git +when contributing to Rust under [the git section](./git.md). [about-pull-requests]: https://help.github.com/articles/about-pull-requests/ [development-models]: https://help.github.com/articles/about-collaborative-development-models/ diff --git a/src/git.md b/src/git.md index e10f1d705..fb64b3bca 100644 --- a/src/git.md +++ b/src/git.md @@ -46,6 +46,10 @@ git remote add upstream git@github.com:rust-lang/rust.git if you're using SSH. +**NOTE:** This page is dedicated to workflows for `rust-lang/rust`, but will likely be +useful when contributing to other repositories in the Rust project. + + ## Standard Process Below is the normal procedure that you're likely to use for most minor changes @@ -53,7 +57,8 @@ and PRs: 1. Ensure that you're making your changes on top of master: `git checkout master`. - 2. Get the latest changes from the Rust repo: `git pull upstream master`. + 2. Get the latest changes from the Rust repo: `git pull upstream master --ff-only`. + (see [No-Merge Policy](#keeping-things-up-to-date) for more info about this). 3. Make a new branch for your change: `git checkout -b issue-12345-fix`. 4. Make some changes to the repo and test them. 5. Stage your changes via `git add src/changed/file.rs src/another/change.rs` @@ -62,8 +67,13 @@ and PRs: unintentionally commit changes that should not be committed, such as submodule updates. You can use `git status` to check if there are any files you forgot to stage. - 6. Push your changes to your fork: `git push --set-upstream origin issue-12345-fix`. - 7. [Open a PR][ghpullrequest] from your fork to rust-lang/rust's master branch. + 6. Push your changes to your fork: `git push --set-upstream origin issue-12345-fix` + (After adding commits, you can use `git push` and after rebasing or +pulling-and-rebasing, you can use `git push --force-with-lease`). + 7. If you end up needing to rebase and are hitting conflicts, see [Rebasing](#rebasing). + 8. If you want to track upstream while working on long-running feature/issue, see + [Keeping things up to date](#keeping-things-up-to-date). + 9. [Open a PR][ghpullrequest] from your fork to `rust-lang/rust`'s master branch. [ghpullrequest]: https://guides.github.com/activities/forking/#making-a-pull-request @@ -160,7 +170,7 @@ it's not anything you did wrong. There is a workaround at [#77620]. [#77620]: https://github.com/rust-lang/rust/issues/77620#issuecomment-705228229 -## Conflicts +## Rebasing and Conflicts When you edit your code locally, you are making changes to the version of rust-lang/rust that existed when you created your feature branch. As such, when @@ -236,6 +246,34 @@ The advice this gives is incorrect! Because of Rust's will not be allowed in the final PR, in addition to defeating the point of the rebase! Use `git push --force-with-lease` instead. +### Keeping things up to date + +The above section on [Rebasing](#rebasing) is a specific +guide on rebasing work and dealing with merge conflicts. +Here is some general advice about how to keep your local repo +up-to-date with upstream changes: + +Using `git pull upstream master` while on your local master branch regularly +will keep it up-to-date. You will also want to rebase your feature branches +up-to-date as well. After pulling, you can checkout the feature branches +and rebase them: + +``` +git checkout master +git pull upstream master --ff-only # to make certain there are no merge commits +git checkout feature_branch +git rebase master +git push --force-with-lease (set origin to be the same as local) +``` + +To avoid merges as per the [No-Merge Policy][#no-merge-policy], you may want to use +`git config pull.ff only` (this will apply the config to the local repo). +to avoid merge conflicts while pulling, without needing +`--ff-only` or `--rebase` while `git pull`ing + +You can also `git push --force-with-lease` from master to keep your origin's master in sync with +upstream. + ## Advanced Rebasing If your branch contains multiple consecutive rewrites of the same code, or if @@ -330,6 +368,7 @@ that merge commits in PRs are not accepted. As a result, if you are running course, this is not always true; if your merge will just be a fast-forward, like the merges that `git pull` usually performs, then no merge commit is created and you have nothing to worry about. Running `git config merge.ff only` +(this will apply the config to the local repo). once will ensure that all the merges you perform are of this type, so that you cannot make a mistake. From 8608047fb217985cd18bc0f045ab1117e7e7c492 Mon Sep 17 00:00:00 2001 From: Gus Wynn Date: Wed, 9 Jun 2021 08:23:36 -0700 Subject: [PATCH 1486/1812] move 7/8 to prose --- src/git.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/git.md b/src/git.md index fb64b3bca..361b65a81 100644 --- a/src/git.md +++ b/src/git.md @@ -70,13 +70,14 @@ and PRs: 6. Push your changes to your fork: `git push --set-upstream origin issue-12345-fix` (After adding commits, you can use `git push` and after rebasing or pulling-and-rebasing, you can use `git push --force-with-lease`). - 7. If you end up needing to rebase and are hitting conflicts, see [Rebasing](#rebasing). - 8. If you want to track upstream while working on long-running feature/issue, see - [Keeping things up to date](#keeping-things-up-to-date). - 9. [Open a PR][ghpullrequest] from your fork to `rust-lang/rust`'s master branch. + 7. [Open a PR][ghpullrequest] from your fork to `rust-lang/rust`'s master branch. [ghpullrequest]: https://guides.github.com/activities/forking/#making-a-pull-request +If you end up needing to rebase and are hitting conflicts, see [Rebasing](#rebasing). +If you want to track upstream while working on long-running feature/issue, see +[Keeping things up to date](#keeping-things-up-to-date). + If your reviewer requests changes, the procedure for those changes looks much the same, with some steps skipped: From 6e4f0cbe1b0b7ff85ef3b094731b2cd8517a7951 Mon Sep 17 00:00:00 2001 From: Jade Date: Sat, 12 Jun 2021 09:17:06 -0700 Subject: [PATCH 1487/1812] Add suggested settings note for coc (#1144) --- src/building/suggested.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/building/suggested.md b/src/building/suggested.md index f27793140..bb6badcd6 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -43,6 +43,11 @@ you can write: in your `.vscode/settings.json` file. This will ask `rust-analyzer` to use `x.py check` to check the sources, and the stage 0 rustfmt to format them. +If you're running `coc.nvim`, you can use `:CocLocalConfig` to create a +`.vim/coc-settings.json` and enter the same settings as above, but replacing +`editor.formatOnSave: true,` with +`"coc.preferences.formatOnSaveFiletypes": ["rust"],`. + If running `x.py check` on save is inconvenient, in VS Code you can use a [Build Task] instead: From c3ac40dc23f551b8e54f5a46a9973cc968e6e2cf Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Mon, 14 Jun 2021 15:35:38 -0300 Subject: [PATCH 1488/1812] We use HIR to do type inference, trait solving and type checking (#1139) * We use HIR to do type inference, trait solving and type checking * Update src/overview.md Co-authored-by: Yuki Okushi * Update src/overview.md Co-authored-by: Yuki Okushi * Update src/overview.md Co-authored-by: Noah Lev * Fix type checking brief explanation Co-authored-by: Yuki Okushi Co-authored-by: Noah Lev --- src/overview.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/src/overview.md b/src/overview.md index 1aa79e791..6c756e18f 100644 --- a/src/overview.md +++ b/src/overview.md @@ -68,10 +68,14 @@ we'll talk about that later. - We then take the AST and [convert it to High-Level Intermediate Representation (HIR)][hir]. This is a compiler-friendly representation of the AST. This involves a lot of desugaring of things like loops and `async fn`. -- We use the HIR to do [type inference]. This is the process of automatic - detection of the type of an expression. -- **TODO: Maybe some other things are done here? I think initial type checking - happens here? And trait solving?** +- We use the HIR to do [type inference] (the process of automatic + detection of the type of an expression), [trait solving] (the process + of pairing up an impl with each reference to a trait), and [type + checking] (the process of converting the types found in the HIR + (`hir::Ty`), which represent the syntactic things that the user wrote, + into the internal representation used by the compiler (`Ty<'tcx>`), + and using that information to verify the type safety, correctness and + coherence of the types used in the program). - The HIR is then [lowered to Mid-Level Intermediate Representation (MIR)][mir]. - Along the way, we construct the THIR, which is an even more desugared HIR. THIR is used for pattern and exhaustiveness checking. It is also more @@ -111,6 +115,8 @@ we'll talk about that later. [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html [type inference]: https://rustc-dev-guide.rust-lang.org/type-inference.html +[trait solving]: https://rustc-dev-guide.rust-lang.org/traits/resolution.html +[type checking]: https://rustc-dev-guide.rust-lang.org/type-checking.html [mir]: https://rustc-dev-guide.rust-lang.org/mir/index.html [borrow checking]: https://rustc-dev-guide.rust-lang.org/borrow_check.html [mir-opt]: https://rustc-dev-guide.rust-lang.org/mir/optimizations.html From 3a63b1296eab5455a4c0e8c2d16c741c3bd0cdf1 Mon Sep 17 00:00:00 2001 From: Jade Date: Mon, 14 Jun 2021 13:57:10 -0700 Subject: [PATCH 1489/1812] Change the feature used as an example of stabilizing lib features (#1143) --- src/stability.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/stability.md b/src/stability.md index cfb4efd89..d3221217a 100644 --- a/src/stability.md +++ b/src/stability.md @@ -85,7 +85,10 @@ To stabilize a feature, follow these steps: - Add the appropriate labels: `@rustbot modify labels: +T-libs`. - Link to the tracking issue and say "Closes #XXXXX". -You can see an example of stabilizing a feature at [#75132](https://github.com/rust-lang/rust/pull/75132). +You can see an example of stabilizing a feature with +[tracking issue #81656 with FCP](https://github.com/rust-lang/rust/issues/81656) +and the associated +[implementation PR #84642](https://github.com/rust-lang/rust/pull/84642). ## allow_internal_unstable From be1d3c4dd4e56708439c01f1d79fc474b01030a5 Mon Sep 17 00:00:00 2001 From: Oli Scherer Date: Tue, 15 Jun 2021 10:04:54 +0200 Subject: [PATCH 1490/1812] We stopped using allow_internal_unstable a while ago (#1142) Co-authored-by: Ralf Jung Co-authored-by: Yuki Okushi Co-authored-by: Noah Lev --- src/stability.md | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/src/stability.md b/src/stability.md index d3221217a..0f1aec17e 100644 --- a/src/stability.md +++ b/src/stability.md @@ -92,24 +92,32 @@ and the associated ## allow_internal_unstable -Macros, compiler desugarings and `const fn`s expose their bodies to the call +Macros and compiler desugarings expose their bodies to the call site. To work around not being able to use unstable things in the standard library's macros, there's the `#[allow_internal_unstable(feature1, feature2)]` -attribute that allows the given features to be used in stable macros or -`const fn`s. - -Note that `const fn`s are even more special in this regard. You can't just -allow any feature, the features need an implementation in -`qualify_min_const_fn.rs`. For example the `const_fn_union` feature gate allows -accessing fields of unions inside stable `const fn`s. The rules for when it's -ok to use such a feature gate are that behavior matches the runtime behavior of -the same code (see also [this blog post][blog]). This means that you may not -create a `const fn` that e.g. transmutes a memory address to an integer, +attribute that allows the given features to be used in stable macros. + +## rustc_allow_const_fn_unstable + +`const fn`, while not directly exposing their body to the world, are going to get +evaluated at compile time in stable crates. If their body does something const-unstable, +that could lock us into certain features indefinitely by accident. Thus no unstable const +features are allowed inside stable `const fn`. + +However, sometimes we do know that a feature will get +stabilized, just not when, or there is a stable (but e.g. runtime-slow) workaround, so we +could always fall back to some stable version if we scrapped the unstable feature. +In those cases, the rustc_allow_const_fn_unstable attribute can be used to allow some +unstable features in the body of a stable `const fn`. + +You also need to take care to uphold the `const fn` invariant that calling it at runtime and +compile-time needs to behave the same (see also [this blog post][blog]). This means that you +may not create a `const fn` that e.g. transmutes a memory address to an integer, because the addresses of things are nondeterministic and often unknown at compile-time. -Always ping @oli-obk, @RalfJung, and @Centril if you are adding more -`allow_internal_unstable` attributes to any `const fn` +Always ping @rust-lang/wg-const-eval if you are adding more +`rustc_allow_const_fn_unstable` attributes to any `const fn`. ## staged_api From a58da1ba0da5f8bc2ae20e6145469ace60f61544 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 18 Jun 2021 05:25:28 +0900 Subject: [PATCH 1491/1812] Document how to run unit tests (#1141) --- src/tests/running.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/tests/running.md b/src/tests/running.md index 874ef8274..34a44f9c2 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -92,6 +92,20 @@ tests for components you did not change at all. build; therefore, while the tests **usually** work fine with stage 1, there are some limitations. +## Run unit tests on the compiler/library + +You may want to run unit tests on a specific file with following: + +```bash +./x.py test compiler/rustc_data_structures/src/thin_vec/tests.rs +``` + +But unfortunately, it's impossible. You should invoke following instead: + +```bash +./x.py test compiler/rustc_data_structures/ --test-args thin_vec +``` + ## Running an individual test Another common thing that people want to do is to run an **individual From fe34beddb41dea5cb891032512a8d5b842b99696 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 22 Jun 2021 04:50:12 +0900 Subject: [PATCH 1492/1812] Update "Inference variables" section (#1145) --- src/type-inference.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/type-inference.md b/src/type-inference.md index 71c2b08b1..4be9211ee 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -71,8 +71,8 @@ inference works, or perhaps this blog post on [Unification in the Chalk project]: http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/ -All told, the inference context stores four kinds of inference variables -(as of January 2018): +All told, the inference context stores five kinds of inference variables +(as of June 2021): - Type variables, which come in three varieties: - General type variables (the most common). These can be unified with any @@ -82,6 +82,7 @@ All told, the inference context stores four kinds of inference variables - Float type variables, which can only be unified with a float type, and arise from a float literal expression like `22.0`. - Region variables, which represent lifetimes, and arise all over the place. +- Const variables, which represent constants. All the type variables work in much the same way: you can create a new type variable, and what you get is `Ty<'tcx>` representing an From 8fcb613cacf5b177c2237ee8ec883324c91e42cf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E4=BA=8C=E6=89=8B=E6=8E=89=E5=8C=85=E5=B7=A5=E7=A8=8B?= =?UTF-8?q?=E5=B8=88?= Date: Wed, 23 Jun 2021 14:14:09 +0800 Subject: [PATCH 1493/1812] Correct the wrong serial number (#1147) --- src/about-this-guide.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 0ba753a62..3f32659b7 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -4,31 +4,31 @@ This guide is meant to help document how rustc – the Rust compiler – works, as well as to help new contributors get involved in rustc development. -There are six parts to this guide: +There are seven parts to this guide: 1. [Building and debugging `rustc`][p1]: Contains information that should be useful no matter how you are contributing, about building, debugging, profiling, etc. -2. [Contributing to `rustc`][p1-5]: Contains information that should be useful +2. [Contributing to `rustc`][p2]: Contains information that should be useful no matter how you are contributing, about procedures for contribution, using git and Github, stabilizing features, etc. -2. [High-Level Compiler Architecture][p2]: Discusses the high-level +3. [High-Level Compiler Architecture][p3]: Discusses the high-level architecture of the compiler and stages of the compile process. -3. [Source Code Representation][p3]: Describes the process of taking raw source code from the user and +4. [Source Code Representation][p4]: Describes the process of taking raw source code from the user and transforming it into various forms that the compiler can work with easily. -4. [Analysis][p4]: discusses the analyses that the compiler uses to check various +5. [Analysis][p5]: discusses the analyses that the compiler uses to check various properties of the code and inform later stages of the compile process (e.g., type checking). -5. [From MIR to Binaries][p5]: How linked executable machine code is generated. -6. [Appendices][app] at the end with useful reference information. There are a +6. [From MIR to Binaries][p6]: How linked executable machine code is generated. +7. [Appendices][p7] at the end with useful reference information. There are a few of these with different information, including a glossary. [p1]: ./getting-started.md -[p1-5]: ./compiler-team.md -[p2]: ./part-2-intro.md -[p3]: ./part-3-intro.md -[p4]: ./part-4-intro.md -[p5]: ./part-5-intro.md -[app]: ./appendix/background.md +[p2]: ./contributing.md +[p3]: ./part-2-intro.md +[p4]: ./part-3-intro.md +[p5]: ./part-4-intro.md +[p6]: ./part-5-intro.md +[p7]: ./appendix/background.md ### Constant change From a1ed0ddbc445189ec05695c8bc47ef3d88ae9cb4 Mon Sep 17 00:00:00 2001 From: Smittyvb Date: Thu, 24 Jun 2021 00:57:37 -0400 Subject: [PATCH 1494/1812] Generate glossary table correctly (#1146) Co-authored-by: Yuki Okushi --- src/appendix/glossary.md | 179 ++++++++++++++++++++------------------- 1 file changed, 90 insertions(+), 89 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index eae5758f4..8e5d5b394 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -1,94 +1,95 @@ # Glossary -Term | Meaning ------------------------------------------------|-------- -arena/arena allocation | An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. -AST | The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. -binder | A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.md#free-vs-bound). -BodyId | An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). -bound variable | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.md#free-vs-bound) -codegen | The code to translate MIR into LLVM IR. -codegen unit | When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) -completeness | A technical term in type theory, it means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). -control-flow graph | A representation of the control-flow of a program; see [the background chapter for more](./background.md#cfg) -CTFE | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.md)) -cx | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. -ctxt | We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](#TyCtxt). See also [cx](#cx) or [tcx](#tcx). -DAG | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.md)) -data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.md#dataflow). -DeBruijn Index | A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) -DefId | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). -discriminant | The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). -double pointer | A pointer with additional metadata. See "fat pointer" for more. -drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. -DST | Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). -early-bound lifetime | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) -empty type | see "uninhabited type". -fat pointer | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". -free variable | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.md#free-vs-bound) -generics | The set of generic type parameters defined on a type or item. -HIR | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.md)) -HirId | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). -HIR map | The HIR map, accessible via `tcx.hir()`, allows you to quickly navigate the HIR and convert between various forms of identifiers. -ICE | Short for internal compiler error, this is when the compiler crashes. -ICH | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. -infcx | The type inference context (`InferCtxt`). (see `rustc_middle::infer`) -inference variable | When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. -intern | Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. -intrinsic | Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html)) -IR | Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. -IRLO | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). -item | A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. -lang item | Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) -late-bound lifetime | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) -local crate | The crate currently being compiled. This is in contrast to "upstream crates" which refer to dependencies of the local crate. -LTO | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. -[LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. -memoization | The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. -MIR | The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.md)) -miri | An interpreter for MIR used for constant evaluation. ([see more](../miri.md)) -monomorphization | The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). -normalize | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.md#normalizeprojection---type). -newtype | A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field. -NLL | Short for [non-lexical lifetimes](../borrow_check/region_inference.md), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. -node-id or NodeId | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). -obligation | Something that must be proven by the trait system. ([see more](../traits/resolution.md)) -placeholder | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. -point | Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. -polymorphize | An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) -projection | A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.md#trait-ref). -promoted constants | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.md#promoted) for more details. -provider | The function that executes a query. ([see more](../query.md)) -quantified | In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.md#quantified). -query | A sub-computation during compilation. Query results can be cached in the current session or to disk for incremental compilation. ([see more](../query.md)) -recovery | Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors). -region | Another term for "lifetime" often used in the literature and in the borrow checker. -rib | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.md)) -scrutinee

    • +pQ2X#Pd9AUzhbW%W7M1%gTy)`#e6{Iw94Iq)Y58!Bt>n9K zF=Omw>zC-$?Jw?`f30j&h~|Hr`lDss>ae*+c7OG1PjUN(BN%0J@L{K23hxBy^+rXB zTjaWSoPC@n=qnE@WK)^Nd+Gbg3gxER2ZywC!s$&I+1)#SZ8F`7QjOb5*JRvZJs5)m zTX0N6ac&D1wi+Q5o}0i6e`lCXDjH~Wh3KOSkwRrg`>FYMq}IU=Q-boll+v*11!V?m1Mbpo8|h;t%tE*&PZZ|hNQc= zz5{R8WqF^zyzQhgDf~N2=A=+)_ZuQt`Gu-AW$ft7gO=cqTne%#5dfvyf zp~H8ohDv9AiJ_K*`B2M|Uldb?w36|6kwS)BgIvI5Zkf$~$dkY%!KoBdd<>l4fozAc z5`51qar|bmso+O6WfS7psIl3&afbPN+P_<-nf)3`1AUMG0$(?|pT_h2-=1BdP@W)> z{7Xk}Lj`^0A>sv}8=8e}u1&;RF^8KISU8`rGj%oe?sxb=EGH7Nb5w>31Kg*P}@P$5*frL{yOahuz0F05wL=AEr4$qUM9wQF(U2x<{K%%@DUVD2Ru|t|f zlU=|*3XAaK-pudYNF1!Ode;~#V1vr=TSOdDT22HNp$@$jQ?1jf| z;T{T$;)s5)^(a7R)IiiT>$~JMomt**P)TDKa5Qz?YOwWvwSoBc1 zyzOQ^9)<2~3ZH;@vWa}0!%QE*{)o2u7gQoZ-lVQ1y{VszS3~*`GZpO9aWTY2WfZ3j z`?HAvxQVh%HnitM)p};CgF~5wIh}u%zsvvC{{C=(C9$yojbEQj)PsqnR5e*NG27Mv zTCN+gB)rf%f33n8ZdN7_I%kHCTzr;y)4x@tEI0YQfd@CueaZh%z*Mxi#KP=_{|oF{l4L3`q)vWX8l3jnWQE_s^WYua~y>D83E%lw;I|?6AMc}&V0v<(Bn>8mru+28O>r2SDw0h!r z*`kMWxzTHzhvmyfTklUM`aaHGdlIit&6pr4g7&k?yYdP7wNc>YB=f<>vK?%EeB*ghatX*WiT41XeM_Cw%roC`pYe~;X;L-F_QmSNo?P)j7UpHVp zr@uF~b%u z8=EUq6X4Mwl%LgY2y;VxHZLZ2L04yf1F+kS35Ijv#Cn$$Atbf%tVh+IMpMI*pG?sy zmvm+>)N~j*`bwjl;`?=&921F5aH(*I3E4|_-CIVNTlOm9-pQ!8+hE^&Q=G`5;Ii@y zZ0cpzZ`U(-tTPMnx5E+6XR!SyiWRy-2MRyN+#W* z>EZ22H|7hNW__behm9W|5E6Fog6(-29?I*ad6y=d0J9N`7+Y8oqAi*%;5k(+OoJ7h zoJJ`@G|^fur8|$|XhgR+0j;T(g2Y5%IqNvn6ER9FlsQ-?LS59`=3lK{;zJYPOXwr0^^l1oLLX3OHh zw!C2i?-KlpU+|5>!my|%XOWhwLufLpB_usSVGy?Rdi{#wI2|ceUEp|U_fhU;Y}pwa zPmy@1ep#1|CKdJok!4~+m9FTXUm?`=0V(uTf!I;<61Ih;sv_hy`1w1mn&1KUgD-)s zxCXe2449$?6|+W;Mb z;m2VYpQznbw9^auGpG1gvbW9d`R8~Mg-fb?c9@4dU|k8Sn(dPlqiv6qtOmUXK6bO9 z&US0P!4$8Wkw(Xx@|G6uDfQz=jOGsp<@v76bt&2gtF1}O_&#I(Udi_O>qn)}jQiB3 z4KJ*Di^aBq_40BJG%dY6;!FPvm5W@@eNkuhqPsu-`h+uFsxY(9T^Vg@)f^8HFTA0- zkkaSd>(r&|@CjFTQLu7y_Pqr^>CYE-Z6VD$C?5_6LZ+U-?|wX>`$nj;!H@2j|0OH9YwRq$#2+jJH5;*PnXf^E;A0Kb+YoXSHYEcsZSjL*~%N`*B6PkAcO5 zw6M#ePxlooJQqD}D>oI)SzT@Shx9v!1voeiLS20lvC|qC%<>-Ph6!VywFAhB4no%j zT)^oUE3KB!Y>}DQM5p#^bv{A>xn?@uIRReNQKqit8_&F*sl&j#pm*RiH}svV zxVj(;YbZuS3g3Ic8ST}I#C7cgsibu#U{-cM9bCgAHwAcTNmuYH1sAaM^g|oQ-hxv{ z$L>eR@q?zG9NK^Vf!=LzKp+_$Q%joAt&V9HqkO=qR@~ zqV#Z09DbI*=rEDLS)6TuD~8tdZ7S)jkTETizkAo41+cUboDk(nlB0g6GjYRpzk};B zf9+xhIdP=(( zI?CI3JPeBrJ17)CD2VfA$ZD~d*vLsFzql*U?d^04+fUrnE$#gmN(X?-%X@>ZH-;TFh0Fj&Si{De$S`D)`9xn{I$|30 zIk*>=3C`e~L4^*5h2Y}zFO&};A2)REs2XgGb`OL?9A8>kR~Q(d$|yvR!5CIL#}*z% zwEpU(z&NT)DFwBVj@al+bb?Kyh>_vyDnIB!3JnQjU#qVE7s&rh0=rAv_qS=)<4+5v z1DeivYPHXj9@NWURqS;A6RrHRe0D8WGo`TF@5iy;4?eB+6)!>G0rKS^C;g-{3JR`mJLC+ z+03gtl6je9NC0Sa~}X;HaUay=<}~{O zzW}yJdvs&$ol4g8)ivaVjx5KG_WT9y@jzeqf^ByO{kVwZc$9p)?qIyTH1af0Vg2~@ z$nJGK7#Ud=GvKWmQTjy2dl*=C3Cbl0jUeW>&Vg6B%T(htpI+V%PnAttEmq)Zw8e7D ze6DXigmL(oVF|A2Va^9(?wjlHr5BX5q1Apo+_O65Kx|=lTc5G7te$#H3l0oyT|(~h zjGa4%R$ltQCQ*1Q24`xAgVcwDFL5VqtF@gTzzusAoW-U#FP|`Lxb+H71T}>EA~T6r zE7OceI52)Ra!5m>p{ZWJwL&s$Kw_bk?h$pg{M+bOi-4;&mNC-Z)_Ng&PQe`azj})2 zhv}hX3y$dP%N$s$G*KVZf1RT`Kz2%VZl!K%f2BHrpJx!tHu2%xK z)zB#I& z?0ut6s_}&{$@HCkE5q(UB4_-2A~T2-iJQ>VJYK_ec-X}k&)Nel5k@F+991g@N?UV|dBPH{=5FUkDBJCG39hZw@# zK>@$Mj}B%W( z?wxUzFRi!}uo))P*!MfZ{1>a+ z#E&j7Isdg@Ms$!!_ZcyzZ-?qcgM30C7EHakw{ys{?MGVbFymrGl{ z_RRaKmBmsD1`hK%RU~(hAIfj?gba(VD%$hct9jKP)DRYi-ut!x9xbH16H=oNKAhNM zaYHm<(Ft7Z^;l>RP>h%(epL$LULxn+baj2UDK1iHH>}V+M1Qx8Z{!q`LqY@e86h;j z=s9Z5Qr~JZ4Y5mVU&d{WIDrxswY~tM>aS1<(cIQ4z};XWmo@+-|6%bcnZ|2xL7cRt zr1>Fl(z)@^%i5nmcT6Mg)@6Bw6AKxAkuhd1LQxhz_NUDC^Qp$SzN+)`BpuJyZsg3U z7%U1bS!39lZWeu+ch}Dwb}^m94VU0u!uN80&}%5Qrlo+PsK!kVi*w%PORuvcep-Kr zCtnbT2Sy&Iw*dMeA+;-XI=_8}tmAJqDgxe0QUGmYG_#Q2b+d1{eDXr~09FWIH z2Mw;bKzqiav3{pq{#pWl^R^ltzwMO6ptEL|`;|4-y}6$f1*L>f02dLJb}jWo%Qil+ z>ZwNCTT7{)%Nf(JVM%7U*w5iPynW!XJh6#(@li6<&~_R1aO67)I`F(LOsdNp2yNj+ zy&R{=#e5ax?AIgoiaOjhSOHzwc`B5u>(y7354i>3a7`=Tqx$ys5eXJ4_9GOVHAZ5t z>B)9)22p#cu|#b#wE}^VIJ^CQ4PSuAx53%?xqB zag5q=Cx%AkejS49yC+M`glzGezmYWLN#<8!@T`$HanG9^Ppy>##Be z-G28XgdL-O>-pRY4%bl(yddmy1hSbjfjMW-6QDHFp7FQxQ8U0ij=qCO9>pVISS|56Hug(Ji6ZJri(KTFRKfT$p3rXc1wK{M)nLI&d!5q_oBldlyz))xH&@|)x{CT4 z=8&MOg+uyX>BJW=vs+(U-aC^KQBP24Gcq~t>+x&xY4EcRz7|w5%TQmE4o+X6KSSn= znMRb%Ouae&7A_ zne)nXyrsk9m)(1-IX>f^X8Fm+{@N>;H?{~9TP9SMm+56iVNB}f7t{0&jTV=wZ|IzE zK)%pGPRHP$`LD_ifBH3km7N^8Q>f#e=e@<4r+}E14ktWY=Q6TRlnDC28aqAz+=H=Q}&-Tn^QjQv_Da^ydJcs(ypS~r)R z&0b%@hTa=ot^&EN)p=zjtvKC3N%08ibLL|7lTUfqx;0mhxe>Nm1Zy04N{A(9H$nHN z$%m{OGcBS3uGY+QzT9p%VmaL6GvRCNeaSgZyQ{M^;I)-cvrXIO8xu$}09X5cCmX@t zdp4`x!f0(H)lCI_TIS!x1)vp`w7y5zyyjQg=IqWI3rZtL=Xg(biSVSy zNP}}CP{n4T6_8}kfxkA4(?@%QmqoYv>E=$$BT_&sHc00qIyqG zR8e!;W*Rz1mpRezzMt!VVxE1@PBEu*B9v8W;;jd(5(33w^;lAEUckHU`-+yExrUM1@@zhi1aM4&A71fX<#1%`G9Q3Ti;BGgH8y-*I==s*ZY^$v!aIB$$ZKPChHM2 z&$wm`N*!U_*1Xb+HFnnIz0OJn>NDUM*r{}*%eenm3;$L57lk*oqpRg2HzM2m;!9&R zD^;=rCNm0cqlLckE`C;X>s|Vn)(G{wUC*m`)JrUTen#nGl!Dbl+UMjqgi{Z5bE+|m zC3}H~6$;OhjQKako=WyvO(scJt5*&C1~HyT98JP|#@&qP>yN0OXcfOVQNChmo3B?h zvNkjO-s`-rldo@}v`_(&?EROcGo|}eA(?i)+m-uEf2y$}hh&hnG_QX4G_(~LbpM4K z{w0*696>C)pCY%8K2$TF6knJA^3Mm;*t;n*A@u%jQ z@p=aB4Ibndq*~651TC3e+{Z~kp5$bi89OtdO6C`UoVl6yIR7`7&Kqe|Pv%iBYfdaJ zkBdhbO|k}%^|J20Q(37saK-L!1{sQ)E)oZ$`3=)OPfnj{1#neZyY&Y@Eb&R_jV5Ad zSk`6vSpJl4cWWp^vcJ_#HYCM8F@eti-Eyzi4sT6a3!-Fxsu*SZ$n$pAtPd?&kpW}u z?pdQKxxig)&rO(yJh8~wnx2%+{S!7ONMURi&gNkl($E1I1x{0N_e0B!{49xvtm;3z zsF|VsvYZ1soqZNpSLr5524d|3AX6YkYayh=h0#{l&N*u^lCpb0Z%k_S@^Yq2M(;if z&DlnX;t95p7f2QU>@t;KIl(uqufI_a{e|p;E3{_!)B;2HE(jFswCr?9YZb%97RkJJ zGXD)PTo(s;&q9agZmfKS#@9#8dA(5*DuDvRHA8l8{7bt=7WRSalxqB9)Un2NBz1Z1 zpRr{)x>^Pa5Sm305%|hmX7TuqMyhS$2B+K-;Kt|Hq9%Yo3-HJ=or>&L8mC@=itOb~ zgl;~R3ZUa}@VV>?<>*Z|mT3lMH0t@?{TqDH3!g^%)uzmlt3d z4)BjV%f9=!MDQ&ld}Ffrd)Xn+pE-VgogN)B`JwP-=ieD8^M$uw zz5j9MMRB`Yy425!*~c?0WI(n3$5Od>f8c__+2=T(kv29g;IO4Z;C$&)n1?K{<_BxC z`@Cq-wHJnK^_RqISM{1Zc7EClPQ9Fa;8s(!+<-j*I6Y8T{u`2XWXJ8JVjaA2uBn1v zm{9+LrICAZCLvhE$#162t+}*Ma(f2NfH&x~kSAG6+Z%joo(xQkufCS7R;XU=r9acX zb718Bc{@%{cSIiJb(0v|@9j5bC(ViS5oS!6KH;UTP=TE68BLdfA3eQ!#gyQ{!J;{n zb&`UQW?!604kma>xLH<`qk~XGrUl&le5MZyM~KoCvdxq@s>fBp8&#a=hSUyVstC@& za{agJ#aPUOF?UMOVK~cC16n}fU{!YoA=GG5fkr}u!(^}hEkafY=O_mcFBT8$#VxtUXu3@^159Ck9~XwH^v^>&p|B>bE^Edt zxYKq~u;Z6}vol)~n8&rJfS1f*G%=rSci+DkUf8V7i6z!GTw!4YM^!Z5sLqJ6( z)&~~%GO=}2GYOR1{A((RA4AAkn}8G_N#N6r=IY7gl-l0L^4ExIm`PS3xV+?lcBfIX zy6byz{1!xMBBnI)M)$%_r8bItr_IRHsaWtavm6QKvBSJwZ*o z{aWhdX2eF!?SsowSk~3CSarb~7{gt6z9Y8d{4(wSYx}q<4t5U16Ge#QMAt1NpBbQv zAU)jOm2!eRJ#4{K<5K?&Uxb7fXhqvAy*Deu4bn>_cI&Zar>385X%rUu^>~rvvjFSC z*r(Wn5>L=HbOFN~b9Vp1>TOzbXm{sy9$IN(0Iir-bH7#Mm5x#GWfGJP9xl@S{hU*F z{dhE)UoadYVOpRST1dI}yrh=K`o|k2pfiUFo*ZW8N_?I;GH$lnPL4-G^}K?5`Y32F zg18~A%x;eG^`g#uLoQ`Ch-H2;5aR4{^K`*i)GI`eYhG*FK7W_NCWa;ppB0C zY}7Qay5es1A4sJWHbZw_{oB#<4}RYtIg-^BlRJCZ@>YgmTlC4@tqSHdTMooXA&!SS z>a{gCD4e&5Ir}|RL3u0n+FwbJilUqXiuZ^)zWz+pCi#6TM=t5V29&nRk9ns%`6_P3 zv8F~-qTLKnc~vY-GN0sx>yXbI&v-9XP-Pf>t9^Bto*D$*=on+IjggKU7)_dm=7xaZ zRh6|3pK8glgwt|_C&in8xsWG*I(|}*xAt(Ut=C}cpt}I&)8-;OhprTR3}pGM)a9=H zHlaPL+=|#$iDwi9c{|-_=nVwb>*>9REDr+BKI7Yi8+T*OU*2HoPr9RV6?#28$rI(v zkmV-&PO?x@UH9Smdd1pV+L_iTi=XqXI~`mQ)pWxc-N}x@u%?t$utAgxMrau zXHAiA78bsk2uc~doh{6*HH&uzM?iBsv@}+QLD+fHr&pgT!x;Qx3!RNW4S%MDi;_(d zo%d{D``KE(d5RjK)5;|9h!cbg>L)%n>^D;syBqREP#f3hVesKyeb}b$)_j2)Xp5xX ztrz8VZWWJ${5BEz(&SZORT}OsL=I7mn=o5$@by@v(C^5DH}$~!``dg>H5E=7^$zWa zg<2WHx0g-e&E#87X_%o@wtS5lYA}n9<<| zOOs=#Hv{p4mYCR@q*-vg6qzChW~rO4le{Vm#$2aj$UIK*(5ZjVum9T(%KoEmQ=~?B zNHGZfUz8X*z1=6-yF2>p%(`NR-a%*e-m^HFAuT_Bjpx@Dv*%CYHb%Q9Wh~0Orwv6+ z{BSI#xg8;FO1p6gpBAVP_4d~79#w<9&i#!gD=JTZv#;(!0> z8`R28=yi)#s|g7>m$`VISfSCCXl87@<2R*u?70XHC+$@u?{u%7z~xv*^Y9 zUvkvZ4{ENEyl_UIF%J%>yEVH1xK?^Qo+IySta47Foo2KBnZp^S8=vXfGA%TDk7%R8 z7A><*EKAKbUSdnG`x)&Q@7yaC$K;dQ{EfliTa%i-#eaDZ@2HhMNU?A<^tAfeuKyTH z-j1bm11c>a7=|O$PgXXq;Cp}T-5q9-Ui2{4-e5Pedad*u*>icLW_tH^`K@=w zt1NvYg=$c#a&q*geOoMOCCRyPq7NPuY#uX~Vp0qjBRuAu{7H;#V>}c}jz33aXVK#c5R;o;bJS_|huYZwNrVV%<1Ta2C@QzZg<4Fl=Kvzhz2`5iqa;DkTEIpb{T0?;m0Q>u;H zuV+-ZbLxychW@5EZLD$J3w@@bTordv1iB42ASrlWev?bsR^&_mInElm{_w>zc!#X7 z;fjc<88FvJzQh2+co(GqY9C;_choEmSShdX}6jKiy>?NS&A zdH4|=;1}QP0ygfMFTlCc zYB6FrQVJ200ZgC8JAX$$FD-*drB@=rg#@XadXb123}9Hj!)k9D$~%BkDXy9ElpM+z zk%NHak#%%W$|jy-itPDq68h;q*l4qRu~)UmJDQEH(e0=Q4!c2Gf?3Hji=vX~K&%&W zOe#g^=U`K@$tdZb4bsXb&g1w4cDC~c3`zn@wK-q$FIY>}EhOU%PXJKCG#=(d4yVwI%4xtVZAAmIhEn?$r*P~&MK{6r?r{1!Fk$zm z6?d*ZXK)F=ZL|21uJ*sZ+i2seCjd3tkp4wc|EZXo0(rY^#eIeZo!3ifDL0%0{>=GJ z_3;a@i$x)hr|+vi6*Ou8k$A-U)pTQsfOd@1aHf=a_KYz!aVzJ z6B%1HEH@-&l2%>Cf9!C`Zl1#z{eua986mm8(Fe%WU(_FeWzy=_abpA*Y;gYXSrv+9 zqc3Bj)00tAb5o3DI8Kq_9hp3Gx4f(lfuqLr462vjWD>VPQbNS|h@ESJX?RWD&X23h zA&oT0yNmi^f@n+tm_{d@P;X+t;9`nyy8_$XD&8;1E^%YNbZ-p!(AsXSQ_bxua1~5T zM0>24+HoqzO~@g)J~8j65t0RkSL$Ei7s`o42ToaxH60T~V*Ko$6FR8H>aWJK>q(*_ zr*!t<_ig9psNH!AE)b7FVr&s6t(fUqmd0JLVoCCz3!z=0tbY4eL;u=_G;qCQwh#OT zxE;CLxMW)Pw!vtE+zBVp@0~`5{nrX6ny>UBDNsM9=gBu}X%RGBS2(tVlWxH3oq9PB zN<2&WID+RbjpCZ{^EiaKoJD5YvT0ml41W&Mxx{ohpav7E4vVZ7xVHsAk2*t7ABA|; z%Vb7|F!Gyod0CHPK*h{8J9@{e@>^Y+Xl-$T-wp|m#=A(_C`7Ec!=jc3Q_K5N@cEgW zn&p~;oL<;=9OJYHW@PJEUS9w+BP`Wy&^_dmEr?(J3|Jh;j|S$9Op!1g6vviF{L;fP zFafGX1HuCit&$gj8jX%@0Yx%Sbau67QT9ZHD0SvzF9h*zZ(d04ZX3D z<`KmgjqOzqed+ltaQf@3{6hvOnAQqLyv3Nar)+{_6EobKbeQqsKu@cYsWfVhB!L8<|h!lBU zLTWx?E1wX&KxdjH;`y|rd>g;f3!2+79t))87W$=sh|!$94LTnMmNiO`z^|E}q+zot z1-2zB=f?3#MH{9Zcp{v9hDOIaZ1H6X$8?^J7Wv*9ueb@6Ec{q(PD8n`Qr8sVA#6O7L|MS9Eu03YAF4 zL|7(VjLNW%I5yr4QG{`*bsf9{X(DmZM}93>N;wZ5yUsvXFBmW7)BNc?PL2M$FZpf3 zf0nV7Fa}wc-mN^x{~y%-1H#ZP`>wscPU!L~SxM}WFPyqau=ELROR^%YX(ll=|-et%FbZy+ss(T ztoQxg-{0^1J)Yn5d;XonIEG`c`?{|4eZJ0fOv2hBzSpB7yYz4WiV^Dc%=`KA&woR_ zBYp;QDHI_y8?hFvPc1mUr}2xH#UVM;Gjoa0UUS7S)lxDou%}kMZ;V@0J*Y;f>b6Ma zL`}j*ug}D1fo!Q-?wy%fX7^rbG>vtnD^uM=kVKOizp6%c z&(sbguQURxows&8o>5_3qZN!@?VyeWR|PQD0tU>x z?-&K_X=E39p6qp(wFmZ#wh|Gn3qpu{f++7dZ(;~7s1+0pU3_^6X)y+vs3KslZNeA< zk^=F`&js%=@%)GYJ}93Hm|!-oY5uzXP$pCmNy?9IN716RgA2N4z_e#9Zt@+|Mu@p? z&9nVcpVL}#w=ksrfA4>WhlQ9U7XMqJ$v$xOP1RbR{k?BCdO;o%_g{GZCkxf61<%oN3*`SE8L;?gyP9(@_Qo^eP{IWw-WLnZA!b_S{q`#k?}(06XbyujZ< z+IOnPWZNDa&0w2o+cUM2Hkv<=ETe{n%dA+i>9A?VCqAhoMjq%vdN2MZ_LrWoA%%lImACUFKcLV+Cem>P`u-()5hL zc4F3gw}DusZqK&|2Mr%SqF(|1O9mUY_y`j&@h0a;_#n0!>??!$mKV?7~!6lmhh4G|PzsX^H?e zk6$-|rf`+yx`Br>mD8Cf_|ymwh`y2sr}DN*MDB zW(Z-(+ieXwF>YM1?)mRTj#AYf@aSb1UdGMoy-A+aa95^VOY$fAL~|2}>B~U2&nCYE z#3L0!+ekHfK>}f7sib{77Cs7EL2naj(DDUIauc}QSnS@1g(+_&h^Lo8Be!c5j02u_ zH^(3rBe=}(CcZ1kYH&h>IfoI4=G(msZjyFF%VE+F3wU}UzGk=S&%AlqR8)xEB)0(V zE|X@{TI^8Mgu?ChCN0TrpoZ_}q{~-cjY^KEH7$iX0t3PpW-|luslf$W8b*mY9|H?` zxc9akcs4s@x-<#+E}WQ?;8{ov_^&2mW%`BIb-V^%=zo3zQ&F{Ci_1!5noy>yrJk~@w4dR<4{Rq#G10v%&-msRhV+q0_p;DkOx##6D#(Kf-Fc;B=-={-_(A+4!?D%MC?)|B8OV2QBP8yB6P>BQr z1G}Ro*yb;MKNz!OapiMJ9zx~BUhhzE|F=DoNTvX?DAZmbWW%O|>#PAv*9bR=va(P@ z1QhD%!i2`ajh#smM|gUpJwF$^g%@S@)y30Prg#*@N$kbq-P9~LTylVbmhaJ*&156TnF-#qqMM5Ra}NAPQ* zJiE&iuNY{{{#DJD!A;gqVOWKK1^a2IqqjZW>7IO;WOL^cE#vFJAgYJJbl^~XH2CcY z@oTP_#9e<9YnU;*kER87oGIqbXy)uSHYs?8><3~Iwnbe<+#yKgv8BZ4r<0ZJd{Dr+ zK;x>`r4N&5o^^Ku6O@QGMBXc*f1s}EoS0Y^i4NDdZ4kde`crXUN7e8|K1AJ+w)KXH zfTT~_`B)$hm>vB~Sj*6%ShSNT$;ICTTRR8=ITpvbpWu}XIP-ExB1JIe$lVb-g9$n} z8U0{lArj6H)hN!JfQC_xIOd2?L>Pjuw~XR+(Y2Nl+zAx#DP{Q!{fdzbxN^Lkp#nuB zfOns`;vc4gD_9BwCqV5)Fi^Avgdx3zC&5ZM)b$UcVmJ0Y_zHb)__Q@mfu4Se8yEAy;6T3UXmdr6H`F zK&e zkGPc<%#I*#Iq;K{1TmYght`7{^FF~#vw@G;;0)0t1@3C`->FlQOGU-|hNB(-HXMT6MWu#LZzP(=Qt1drTyG2EU ztYRk1#9XVFBwy84On#p(%ryyjJn}gfZ=9u$e5Uqs4PDb0?S{n$Rj2-`3VuGyhFJNst;1NYD2&rn+Y7)DVAEoGToyBf{{zqWq(>n8Vef*mzQh5n4sXhlv(L29?(|`9 z%aZNAEd@z84r@Kk+=ozYua57-Xa)ogVu;r;wg0_iO>A?Wn6Z%2O2VQW2w*sG^_TP3 zhz^)){ond0t+~D7B`=4%`Zb}X#`){Lg8#ewO@zj617epYr*{jEp^oPim@1GiZmD;z z#GYR6aeJ`s!P_T40+(pvPOrP-d!$W8@d?eB%j2f9F5k}y>-w=78sVnMi4CIs*mHSb z^+k%To72sNBTP=jk-)jD2X7Wqh8iEGyGLFzQQB>#T+}Grdh_`nAD?$f=ulawmf=TwE^}DeX=Pc}04`{j^l< zJyjz#at05hry#Ckv0Et`~J~(~=7z7#xx?JSp{pcZP z+Er5nI{+3H6(V^S96$fd(_7ZM^axlF?E|G4M4LBoWJRF*dI9W`Ex0<73(V<#D2C0V zG{T=G$c#5~E(sDdy8-xR(p>Us<6v>=2pL{`0o ztRQjl4|I&KwSg;G0DSjVBT_L5%p4d@-(y@O>U6FR7EnB<2;cy&>H&s={BnwcUm>3>HcH_XDa44Rd_>ng?S7jdnL_#O<<7#nupR*q>W?M8U^(-IPuDW7% zT;;OayREDHZq925!#>Crk)!REvUd-g!hL)#mLC*nTNeenQI`536in{xHRV@vC zZLQcN7l z5m!s1YbEy4^dEl7*8%O%FxxYnT2_-x=*e@xvlQ)k0xW6dGVZ)H3@yzA`tc9*}%P+O|>{zt(&QM$(@|BIS|gA1M}X_;O^Dj}Pu-%e6iK z%7>s>h#cfq&;>Yphu~=FBB&Olw0;h&pG<>(6F^)8EQuDt8;LYRn+E9jz1{rh=~1Uy zW(Ft&DuOONl4XkpGlQO@iqex#pvnOr zkifKqSy#PT_$aAi%x+$-b>3tS&OGYQbDO5E~C9s0-#}Dmc$#7&i zh!Wg^CRyca6;PL6(T?VR?jNAxc*Ne+Wat$hPEErbS$EB$Xa(HCcLB8Zf-orJ8dqfJ zdpwhH(XkjFmmkEclR97MgU_dMc;qc^*I^fUV8lbD9p_(u)~z6iR&Q%{-8WFXI_X-2 z-wZnAvQij<9G?sl=XG9V^|Qak!uO^; za({+Cxs~-X!`mfxBM|3A-Y$1dl3#AX^H|Mj;*0KXc*-}W$*5`{H(x(uES)$FTV2rT zuzXcoQos=vw}s=5nI08a^T1bjq`2AfHbfT zv!(t~r2}0&bo+UmtL-V;Sjo}pxuF>Hk$^_Mu*Y%O{%2YIgq^6;OJMq%&RZoTej5dr zK^J(*^5k}Ft^!i{nAn<#S?yifB`sA39KSKRO36o`Fk09qzYr-&7kbbC14mdl{|EpQ*t&0v@Rv6L$7&d zu%Ak+3vGA-9mNafGAq~HLDKDm5Q$A{tvXbn1A0-9PF4CjG2pN5y(4xgTnyTUgJVe*I#Y0f$Tr>eC2H5%ms`3b?lr9-7ZF4NR{(%t8}$%#@jmLDV!= zg4YZ^rfYE#{2D!0Lm3mg4OI5TEoHm6cnT0r5aU|3pjbpgH6A&L!u!v{W@=I$XBuxV z4;?lJHaMa{4vc96aN_m9;^4xxy{DQ>xEZDIkZ?(P6uJ=zq4s|7g9Qs}#~cn%C<;|{ zB5pI(Jf~XV-xU~Ws*Rd5#va7bY@7Y|_>Q+*I|-BhKl^6<9yCM|{{LH+8Xq^&@_$di z-F8-|`HpQL-)|}#3wIjed^Z1D=fG%I(3Ez39@nB`dxzD*T|XDAmcKZle0Rm*uTPid zDVexh`ru*=PgTiPovra~pTK=>vq=rx9ua2Vzu)eogR|S)jS2NPAN+S~$y`=uXUHbI z-h69x?6QvcakMZT7M5yIN(F zfA$#KCMq#vN_5mIBrmLDvv<74qr|;G?&~r&7Y0NyRrj|axgW?6`?JWVX59ky9nQ3s z>V0^#oyO+&aD7kPe)7iAfw={&AoujGX#oMQNzJM4_|FGfpFKnoqgL2ew;2IsVg?_1 zYWiygDGo=EYwKm)>GOhWMtJsSzaAQCL#`mQupvGIjK_*@(Q2_SxD659*@zQsg2 z1Cqssgjld5oOg|gSV6;=Q#}T3B^f4wNt=Y*QzBG{@e|7y9P2U%NR2KaUkxG|$XNtk zz+iz1?@08VMiJ0pEr}UY-2^st(?i9Ek!z$=YZVM~7-15)#?_!}5y|SvY~l-PWa5M{ z=FqgjfO80S4e? zp-5oN1rJ;lNK2jG5)BSIcvyc!sh|pzO^$lW_#0qTxIPd5h#~zc5b@oqS^bdj&CGk> zF<(uOiZ{qm_#}7y;r-Z`>|fMEAw#0EL4le3yaGXmsH>-unL@R{Vwbm+75apFqFrRP zs8!M~bIx#1e;YHIgi#*z>ANN(`@-b=zi(KAI~Oeui23}{`!A_+0xmmid>~KwwblNJ zZCx!gJ*l-DR4NR6s~=~%`BjKpc%smAthyAg?kT-kwA^opuCqSr6Y+d+;fQBVRz>ZM zhIYTSYif_=N~dUYDaT!HDVC<#Vf@uXgRi=c4WaRvOR}`Ff^Q+zWRxFQrb#Jh0!o#iPK)_z@|tU)>8 zpZJ#}cTT0rULWBxzIB38G?;pTKk=% zXDa?lhQkSpD#v@^?MatGeU`9>R0Tpv2OObW+!5801SA*GWf?G?Xh#;mz{%XQ_I`9b zRt-oVM785Ep8hM*KHZeMe(}a#RFwH z@zyI^5po04yLmd;1L80qxhI)N3KDkKKkv}Y?4v_52*?_Ag0!ujAILy9RX zcN^Y#To9C?7*FN`LeJ*sM2a8BMpr4+Ghkk$3xV(ZHAgxPx^nCeL6fCn$hK5?Lfm%w zr9-ui!TOw^dhiEjJwxIzW6E4zLGvYl-9uTCRs`e+>B{*<;RO=7vbc|ajWj~JC$++L z_(dKvEd9pfu>8t}_cWKr0)3$b8PBRy(5QA$UOfRgaQsv)M~7@CBNe(pMASJ1j8Be` zGhm8it$RZRRV$yDHMqqgk=4TewjRCYJoP4!Ewq9b%$t=F5R;f=O<@1sax7&(`nUaa zRBGq5#QFM2+TkEy&Ps)a!E#~q*cCq*h0L<^ta2F&f?q^oerweH*4IA#*=xup>3R2` zq0f)Lt#Z%MQQlA^Hw zVY*%y-kDU%lIU>k@<@G6#uqX8W@N#|136gYHQIpL+!a(zBe3+v~P~QY~@WAWp@8< zsp2=hd+LLArb}Z*MAU;j;zBKY@Zsqb8<=+FnScf^`wj2rM4D==qd`cu=Eh*9)c16 z1mwC%)7U&gjgV%!-V@MT>A=%TIr>Z--Ye;7K3>H@V&6uAiO|}15UzrOVEy!5pcq(dlCK+4C-3$)#KA7E-Ch$26Grc^L+{! zCbUL>0hR@MTFpeB&f z&1edx2%zBlp<<|NE7><6%2>(=QYxIF*+P)#&&cQ1=w-kZ z%6LAMi=SB&gYH7jkhB&p%$ohE1xZ1Npr)vqaLz92X6NwZFj)Q%$(}%@5V4|w{J#Ez)bHmNnri}l(R3z&~aDT0qqMT(Ae0NYu3Q zk!PDe<8)MwcF=0-jQ@9@pF_$xO)T(7xTV&p-_HKR+szh+zMPG%!A=zd_SPA8Ltfur zzt6dDEh>jfud)9m>*b7`QqKbBSaV1$alvkNjrY{+LN#v$WtQSusje}~Tsc|uu&dOU z7}RUUF_zz~s9Y-g>4BZxgSu>r2=X~I9dn_#Q2>$JZ9uK9X~~uPw^?W+u(@Fozebj+ zg-&EtZ~UDVU(u|bc(w7j0Q>xWzDC992|54iSg|>)0OwZ)k}FnD+3C6ebvzNdx3m8F zShmk>1$EapoW4(rz(#=zqV`9=dNO}S;IsD%4*n0T@B6`7a7xfo*UPsdp5XG@^9%9G_1RDL%-6<{)!l+u;_LW!OCHfw zJ^kUOZ`c{4pNPVVzd~1fQ(k8UM*J!|f?Bvy9N`|_lH;&P8ovfdg0FMjk+l4&0M#FOTKnr8OsSdRH(a;hJqdK=SQ4wHmiN0D0oWoyw1nl)Zp!%U30 z>B%E0LuM50ZRM8tWF-k#vwuqFZ4=2e!{@Pd)p{==g2eOw>AcN0K>596j_YLXRQL8g z&vjv_hc`H3x8oOA5s6_qBQ;qSG5^%BWfatN)d404?JJ@qwoE&tSCc zbSY@s$HrM17ETac=_ah1%0>~MX@$tvr)Q53-;X<`2|tgxddw1`d&l=r`hJikEX*SB zHY&5``inq~Z$${ZdGdiKn>JXI?Kb6}LrD{Q2(798(0hV2;K6mHP3ACB4A|Z?aTRjy zX{EvL_^>M;Zf;7DsYpbNgn`cm@HbEn!6x#LfgRF7B%zOi=FT{Y0Wp>wG)0RMTGuI0 zlZSk`D{0z=F}8)f<>eg2BtD7m*7!NB1HyB8UlR2z9P4fMd41V zoF>sV)6qB}VtC)JDIg3f2kC$sU!j_Kg#QI>xFbId!obHQG(VTi3gtBc81Ow)#BHqr zK!HT3a6U=e((;{}t1HK1FtBUlTL8P6epAlG@sjB|$EDc-+GLC7I4mv*OIciKyH zabMb5jZ;nf<3xwy5RCf)ku}Q46scZhD)vG#-=nf-h5iC#_lm!o$fMoBOiD$T8hTp9 z{&aevNKH;D-Vd|((P!bg|4>Wdgl^TANCljK`DE?HES$X_u;M$q_1_CmM$<{UKoY@ z1#$<`S!vOjj$-#QG0^ghgD?1#icqVc;MbbJm;WC_;lws4IM~rjK42-22-sG1YIqIv zo@C=f4X5S%a;z}GTv{&lyJm`S^TEGQINT)HiD%%IA=H%Np&Dvp*`qDKOiMst!?fb1 zHQawLbt~E#XLJgitRd$+Q)7mN?4EtojBEBjV&HEc{{Pges<{5X@6_qZv3&Ux`O^3-`0Ly1SMa4F^a9g+s7qgL z)B)3$HdnvRAx1GA;A5OB{=Lt8&dcE7-%y9U(s=z-%o~T+YQ$w0yhMxTFvU;2HL!|= zvHNSJHB2M2BS9ZFp8A!au(?lpgA16gKfoS9X5bb-w2-V&t0q<7^Ki*ULKst@X{lmhgQv$ zL3pT<%*-Ax(_cZK$G-0w#ygjBU0D$zam^W;w}#`wHC+!d$g~3N%6xH2b{UeBbcWfj zG)-la)tSiv?>c4^HEj(I=fmB?ixapN!aR}#{ctd&WkTpgE*sTF0QLGI*bXr&k7N#` ziXiFPvah@h4h_oZQF8Rb-*SIj5cY~Agj1&-fh%e7`%xV4p)pn)bZHpHq`U_?EeIA- z05(E2;b&kJw7snK6_ghZUwInQaA>JTYA@V(@P^AqdOzAEvkB&b(JSaD(3LJ9JB}%o z+Ci^y1_n8X>j)xw8P){u@)Tb%@$@va*N_x1g4|g^KFP?zhm%UOQmU8WDQ_@IZHoLP z4EpJVeZ#by-da~75{h^l*M|TW{NU4C_P7a6Lc*|#N$)sFw!^61Uzx)*1}0(QaG2RQ zh+=W={z4Ni%;JNP)V(tKm6IiV^Kv#KO+AzL4mmsAt$6#w{O72P+8JwMynRW@b%Te# zUTD?cguMo%Cs(5)M4GgG|JH4aS-0KHq+(BqksT5b-s64Acmas|h>MN^=tl@OB*u22zmv1Um zK2rb#O7=!p1lky~t+Rs5tm>9TjvAoe^KRjy;^0@)k>=NLl{0*Qht#^V! zZPVZ5p9FQK^p5t|WP6BoaQd%}j@A~9tjds?mjb305z=aj%LE8qn2ON4x6mJu|8K#) zK2+!lnA5iPR22E>0w;t$Dr=tcw37RGAqQW-C|*!C`_W~<7rwSIM&C%?`%u50MlGe* zXn7KXSSW%|!N9@9Yy?Raeu&P^@=f&cumy2E+Z(sd# zW5Rz`F7AfhjU69m>JFq_9lcdI?+q!8*-1t$+w8^|^gp~B=dI{ntk(9rzKbNm4L0l8 z3o20B)*MqSY_y5JF2U4y6E&vEOyAIVMQ5Km?e!0Mpd}!O0e)XRIE#)|zo<|(KA{*A zD6kpp-SENQ<=&Amv4ExL=?i5V;S%qecUdbFg<@F~@#a}w+cCx8`N zsz=}0&?ZY7t(Es!`TpDiT`NX`7r-W%&X~}-Ft_KH9INpHIB5R#JXCerk^l2N0T-EZ z2_Dm)_~j&{Qzs0!hj4FFb~(gP3AD-)Vyt*wNa}L;tzK&8P$xJY@X{Jw(=PLqjk;IXIpP7n`uvVLZhTWW!zw^=F^In?X5C9ZL61eS{uE z7>{Li6*LqyvWAdzAA%R6w-M~w#VZi_VReH>0$!d32L=)Ay+@nDyAUGlS{@X&QV@aW zmRxRy;KB|W;GLQ?)K?v5J?z~=ScVk2z)3kM9HP{;;b{N`M;FN;(M9wG!5)G0zeQwB z&eJ2nj1tdbP&FH_JYcx~@K~{6Z6f!aQ;$lfXszin|BSbRC^&BnB`pNsQU`nRnk~-3&>8yFt>=!79=%lFG`}X7}JO^>hzt0j#b*nQ_`qRR4eG z(}&LPeB9&7UtD8Sk>Xjc>VRd~lSLjWvXiXo7heaHYW#>e<|JuZLj1!Eem|f}N45-*iDTq_Lcl$d;x%0{fy$yniYn8E|G`fVb)Z4N3%dTh*q=;EiZI zqqXy(XvhT`fX;B8$&Rq8=}~qgOm)usT}=8KIO_%+a)f8mMQ|TbBvR5poJYT#-bi%5 z7|C?zc5!9!@Ai3c-ML7N20To7AWqMr04>`L8n_{_^B%TaPYeeqgp)NIc~lw zbXLj$_TTl02ueI>njS^MPXX9^m`oVMMZ+HpXzSaF0z)T4VV4OJj~qr}z)>7CLxN^{ z3l4yO-cD|VqIvuf7POi0oI>9>u zzjUzi21$q2(-_)=Ac>Z=^u|^#6j(0~yqOC0eo|A9=UU^SgF=;=GxvOM-5msFyX=i4kbCFZ zq%ku(ywbzJq-_Q9dJTFlMaYYq2-})I5N>S1Dti4UMY~x1{9j+$u_%i+jB{cB0o#nNlf)~g9$aO}6utZr_ zptl82Ev6AuqwBNvlFNHfPrNLhOAjpnT`?Z8RBW^{904!>hn&2%}c2l#u-qNIov~;$*^2a`Sp7l*SqaTBMBr?KDhZHKF&}#HQr{tRGd{dN>DqaR02M zuMLdWe(=0srI6G&w6oif>}hP|Q~>9F4X&QVHda@V@tZ$fvz(*#l@Gx&Zmf8pKbEF& zFeF9Vjas)AjhY=z*>py52EXI4t-dM5^4LBdN=cbp1c=v_J$a~@6twD1;d&9}k~Hf! zdR?|&OzD&Sud~15+25uSZ9nWPG|x;@D=E=7`7=xk4kbY_80^D?8yi1ejdiMin&UEy z(`X20gFvraPFjDR$JBGPMIOKy=erS?ab~OFm;PLB?=h|1+RklCM_%u{e0WE32lmu~ zbh-{{`w(qz|LYFJHOsyUN+~=!pYKy?eo?-mAZJI+vdf!7dk~Q^ zk$}?|x3YP78LxQmqyp+&%f5g`M7ig?IkSOlA@+^<6ROmsn%4JX;ovHfK$kmfIUAL! zkwV{T#Ifw^%pVq=T(9L1>$s2~e-Yr(b8Boh<0+K-Zbe|M*&+3gliM|;SCiOgWlSCsXjIXw%D8f?#&B(-x+rZz@;z><0e&;FtBF z=_tbFM=vM{!5uxT2vg2O?u>;cDkcSp(n?h|W!d-_iHt&MX3t zq-!A|C2lL8pWhI0BwB@-W19ZxOB|3vM07Y@=QNA$h-)|*K^S}l3-%lB7ufJr0Q z?4w@fpRM~wA9H-P=Is)GYJSi@d29!DV2fMwEUofp;Ii<-fZ|o@F_rGFw<4L(w>0a% zS05~LO*{PEEW_@r!3U#Ue`W9d&EYxs)OrV%=y|z^k3qd3R~!u1M)3Wv-LJMkYwTR< z=@fP8d=R9E&#v;s?^ORV`<{`ZJoc$R60_;{nH`!XKf7*TE-tv5T5^h^vgdw2kG*hV zx%jkaU+o!dNl87QXK%$%N4+<&=u7lwOkp4P%$^OB%q8G%0j|+^3J4@NrMmE%w@-Q$ zNohp3@%bdJxnerN-g&>65wWAJUXpOWk6xgfDo8NVMd-O}i z--oyVBKrs{8^&Zr9n}5)^ukn~+N7x1_`ZG0TLCEcJ0da{z>7Ri?@QEUccj-3$P)fsO( zHFV|f`&$4O96WwWEbs2?xHaOICOT1|DI!Pe?eV2=r5|Z|j{!wxHHb(1{({xrXKHol zyU{WJW1W|eS`QoLn5A#VzbM%d$f96)HxA|xy|*fS)hersMMB*jj)iRB>mDB7ot|9F z@G;s%C(ZDDl4#?)mmuGV_t@K{h%e$T7yEi8gR|lT@v3U;%i}X+rnm15_h=5dU08dV z$)?1;3tBU#_X}G3kE&lc*gp7<3-3S?`WU#5QHUt(eKl5wYG{R8yD-Us_oC8DSCzR` z@9U|{+WxuOrHX*K-@eY0D_IVtbfab*b|WLku2D=%um32YziY0WL7UJBnp52<#mkIaFwQ%C@Pszc%f414YPA2at1D> zUX;AFcTvLOb|d4bqQFvJ%(UDp$8#})s)GZY2IV2zruRw?RmH8f2r(0jH%wZ1mpzt#}*YIy3AM&Z|K zk}mbyBJS)5EPb$R!Qgu_7^yU>2W|*-7GBv7JzhcDkOq5ho~8YytKR@5!BJJLzG~&8 z^;*&aV3@bB3?EA;(Fcr2H#L2Wva>WxV99{A^Tz|5&fUGp-z*yZt8=r% zCFjk|>7?e2Hv^Cuudpynl z`vA08a9KLk_Mg{x(@XSc()yD-Bc<9ilfl~>;95oz(r+NVni8_f9Z*5SG?$fQ|II{)4~Sy8^Rl0dP59?0*v zvhnAjd$xb&%qT=-vD2@?A{ffIrb}DAK&#t^7z`V+v55W$T#C$|tZlk)j^IsT+3l5okHrHGEGC$RNmv`3a{rxk# zNq3~`?MCxY&mJJuUZuuL=goz4VBFjBd8IkeSY`H_2olkx@eILqor?+!QYMfs$snc~ znje?ACjN*vIg+MNq;AMDq@*IFt_-IF*zS7lG~eI5Hc7-e?wvY|$3YNOeR8YpwI|apvhS&uvl@Tu z;*5Ey^$33lENS-pMvlmL63zJ6w+!}GySWH|+hxr6`huu?G0R_cuNX`pYMGM>q2uOy z+K^o(J(Ox!w8+SSMs$zBb^WURgtQq}iGrHe&3EMm9%R(%PAuzN5$RycMwqoH?K;D zLwuJQS+v2&OiJ`O?NDR1_Vr ztafznn1uJ$BRA}APd5cCKKR^ntX4wQzUU*a=$1RT=wMLJw+zgA3N%-T))|NNj z7AKBO$^2t?5M)mkZ))@uRac)fH$T&x(SE+_QT>tzHQE@fb!$+brhl(VeTT}fxuNOW zL)(bRD?__Z?NfV|d?Q%KO)zH_Rp(~OoT|xg?=52e`6p{~&eP_`ebNK>x34J~M>5Yn zYJVNp!QYhJeV9FRRWO&TW?LXX5xnn<;$heGriA-{pLzNZrk^4$(Ib#YS{3_0gqppq z!bS``oIkot2p{)_a=`I%OFd#&RMfrxBk2jB_H7=x>F7q>y>#WvwP$a}l80}-{@bx@ z_D1+||5^R~zht#__oXt`s-&uiX%pDdQS%TWnW8?4A{D!`+sOU>$fKV_x)Q)DIE&J z=(DP1E30TBUdlxETm(jeU+UDBX5qq}P`x_dCT?_TfY^Zf(v!db{JS9>ai1(`th zp03M`B8$IsW)`_q^zJ~NaT}my8;gS0p!S$PZd=%`8J`qRla)6teBvtGMmU&!zWTMU z4}SD1c|XeCkSfI_1oBGb&2-wNmUJpi079o}@D+WEMNo zfjzZfED>4P!xW6v`67#D|8~9e=1{?+!c^ddFz$;NC%avLk|Smm?=uvSkOjqQ3_D&d(*Rj3bp9!&39aJF9R%ataw-oQoN_9@w(ausV>F&9H#>}rsj_{~7qc&UnC+?)#>w~C~(zbn*h*KTp zjURa$xtpSeX=I{02Oes`cF}yd6$f=XnVPk59WPAt%33RL{tnGj^3mN{P0-iO7LcDi ztz$Fzcl6fleU$H?3J`JiJolt{yAsNIJIVhkMmHVnD_b|`r510^=Btqi9hxE8$gAIP zJtc)R6&T7M33qDeNp7{with{DwO;9mOZtV{nU2EQ?b?;h&F&!ygHhhvDE1P~=*RFo z3F3DyD)xv}s`>~u_ zh_gsDpxJ4+ul}$OUh9x}wU{SF z?%4CPEBjC|pjRkp@UR8XpKM|zyDjPc=O6aMYu z&_=Nr-_mE?Dl4vZ8;-l*gzy?B7H0B?2-w1fRoCaWxHH1 z7SDUIEZ(!%gwxo@nR6B6< z1vZ9)_IjJRznPVtp4#D-nLwN_p`x21fX?!8q0M|v^4)8V6ZFy6c~;-BkL3-qi0FUA z=mwTM=d-GY@<8E~=ZZTA35R)dVf_HdM#t9u;@?%=1F`CX{7`-iz5p7Cuz#wVx2@+v zS;+w#QW+O!;KRx=^I_G=1+jM|$?N@QB9Rs*d|Mdyh3#lz& zV3D>B?vv5@x`%wr`dy0wu@fP9u_@KiH~YhPq2S3qU^mXTE|M@{)2R`sE-Y9}@%JZ!&~nwgsn7-}xA`$dADmHOY8y73<0~8aEere8 z!t#?_HBLfyR16o;R=$}B=bS_Sne4R;RL_l6H+GiSMtIHB>h8p&%jDC|f2#k?Z*xZH z_w)d`^56VQ`k{)m!OM(w#OG#Mipj4}aZ`9jCThXXsp>Nho3BqjR=h79cRu)`?`&ah zr=4wfLd~OVExLiq9rNtu;{=Lpil+45+oIBU16eFDW@uytg7FYr&|54t9!x-+mH8k2 z{+l9#7o9SJpGn&M7)Jsy;nKT@Er_xTu39YF+~{)VU}dIvjChMzDb?*D>LR(lkyAZZ z8LotD-YwP^LVN{b)f=_c!^q-{hKA*bfPft*-kY0$qQi=8oICgN(2KiJm6otI>+e%2Il6 z^ut5L3>0W7t$*Ze84ZAhtY!UTN`ao1v=)Jz*=&P9{W}CSn1)wg>wL@;5k}UVv$QE& zndW6je?J4Noj9Sa<}PYxNvOTzO(ps&6?Fj5yiTV z1|>rPa^ozlm+(qMx2^$|8%XK4;f=ImcHlUEZ>7KM!B(Zgd z+To0v3VfmfpP=klus7?x_OIHFJ$**f6jance(2<&+t0pfdVXfz{p&nhq#5T*Zyud~iPzLT4>@!-l7p&_-<9wcF$eHQw_`o$ z9xE#eNetcP-34coxDBYQKSrHTW(zt?w+uayLb+{izYnLL;aa!YK<-~3n6MnPyk7t6 zB*DZft@Ee$eeo4c`6=NaW(-B)4kw?mI8zZbT-&K8Zi%s!A_Tb_?!Ev01F7~?YgmAX zpr!x6?k@anelfOM4m>ku5KApL0oh|TXEEB8PoL5TI|67kE#+KCZU=oUVm+!E+4V_Rc&)h87w9!Q8dr&TD)Oyx)y`G^ zt%Cq4N|Azg#|RPq$9|-q7aFN6;K4!OlP@67r{oj2R-))D&cWfuSz9wEQg=5?^4-@Q z2@Bb}s?@9Uu)i0-yy|L}9!^trQ;-nwg)&$7TW)>WJuZp<5{j{I&Ou=@{6jTuEL%#% z7oKWc$$5e77O!j!4qOi3Eo)R2zp2i+?NH;0;(=G1<37h1 zt8A|FxHu>;%L-5QLH$ncKmGr2*}G@fto8%27W3Vt4418EQL}fT1zuWy+4S#7`0lcG zVnGozGKJG5|J&-#vAUt$Xc{kl>!Mvk4WzF(V)TP0hiRHYpFzZlOssSp!AEl*-Gz8U z;?bsk`lZq-YsSrHS2}zRnt`gSwN@rSK<&V+q4>*=3!=|!}>V0iuT`x zi9>c=?+Fz7-v*S*Rn^c(M<5voN`}PeZ>_mry~TDMHuc>=^5(q%8|ODF7WLI!@S^Kz zdo!dv)}Be1CEtpmt{`&```f8wx)=5& z?NRJ>Ld3P)^cNjZ5`|3QU;|6w)%IV=(!3gv4EV58I$P6!J8A=t*mpgAWA)N#`inV3 zH)CcIH_Z!$kFV6Et~O*$SK@gUYYbVu;zOI2q7MNf^u014At*u0L>_Vsya(MKgi6q| z^a?v0F7}G`bs_Pc6>YbOoK(e^Fo4%pv`-KtBguZvQV@V_ZhIikozS@I}5HI#SXDrBrq~6kQJG`tGs^DAA|FEB`J|dTYx1Z zi<89iE2 zS#mIv1mvApAAx6h&%Z9AHmu=)bKFSK)UDpqK44L3+ucC>FX;FsX525tw;XU1Ro%UC zcg`KF{!b_?>(Ryitxk@F!uZ&W#`1F;&5!qD`&{vX=}z39Q^?=nU#T%pSyEg(+>@Y6 zfwp(*Z`1Ez?y^wCc=~T@rdia=xgMq*I3X@?str&Mbw@$WMFSA*0RM`JXMI8`q{2}H zs?N(g4+FkQ;a4#iP3Lg}g<)%jHrXLB`*Xbc$#_1iCs~%7JurVIF7Cka@3=29P21QIgd$#-GlY~p3{ch&= z_4okb!0BA1Q~Tu94H?vnlI5h~N5NXX-tj!EaE(I@9bG78y3CDH70Mr@#3 zq=egecocN+BAt@7LEEuE=1j*qH_^dHTGHr!2Ky0~y*d~@IpBy-qPh^v(!)XvHI93EnOU#itUMNIsJ<1ccTp6^m7%M!tE_MsW4UXEQ6cE<|e8*54)p) z{vNe)t9Q6kZxypH0z&Jhvu%?og+OTls;B?k{E3kVT-3#k!Rpty$5ijVE_Xsi-FD=Q zGDzE%;;1L%E}LD3eqlD5(ksP&-C@GLP1lrye;PC_`iWV7b^hGpVbwzP?9d#wR9Ee7 z+GwYrChpUx=?fFA zQ8@g*ka4^{3Xf7_dKxpKl{~t4OC)cBomwql?=u_Q5=G3B_zSent4r=8jU7Z8iI4&e zw@su~85ftdA(%FPcaeOo#M({c@TzwogZP&pe0@ni^%FdO5l z?GJ6yRob1TR~j%@uwy-amXwN1+Z>U>Rg;|q>`Hs_Vva$cO)wGAO4|)4^>K8lh|H7s(7bnd9;CDT{iT1jv z<}rL_b?`@#cik!YzeOV}Zx-n|nv%GmsWAt=9Aaa^Ioqc8sOOk)&*t8#y$fcxU`P>E zc{lhauzb$mUks>7|G_qm^+g8pcK@L%C(RFx+pmFLYNvh|^5MZmzernIQudBP;r{~M zDz-h@w6^7=LKA#xTCdsqWF#J5-rVFLooS111l0ryU}feFn!7mL4@R2x-zYJ7_SJ=4 z$Rt>h2Uf1#OVLR-ZFE^m8pyIj(`fw?WVKU0F+w~@!r7$Qn|4Pu$M^Uog;~;QZpu`l zR;*wFvUKU03i^fNuS;qElSOpbN+Nh~!CUHYuEPd{ZWGQ=nafGSn^~$VknKH|5Bt=r zGo5wF+V8?hmGGp4fk-&yo;$u~4&pp^WkEQviflZy5fMZ-yoOb7JHh^-N#@BsHzi0S zCSw!m=bs1`2k@*YcHOPKq3cni+%i$>J-2aV0g3J@ChO~k0=yAAluj6x4$+aWswp{S zuCx>gYT0#qiEs2W_cmwrd7K{CP>%BJ5USw9>jg>|f8Z5rGrj9Pg0AM0+a zLx5gekvE$6L&=q6Whm)Q?3XbYn8Pz|I$h7#6_nc6KRoAPM%L_G}gKB^D zDD&IU6xABrr0Z-t80eZiD?y%n>5CP3BO;#TuN{Nbe-M7!I(-B0*p}+`*v;*%+lw*e z$W~o{(;O^e`PH>d<$Vtd%cxPhfx<8T%%xMo>WyBfF!Zq zaVP;6vblU5&Wzy(eQtKvaGoj<-vzO^irCaCe1e2>#{wFdj;t&6)ApN)BdgYPe` z(SjX-FF_0Gm6U|=QhOcfn~ns94nv8CIsI#WKN;lvp3{@XwI^9PCT=`OKgR@u;%k11k+mk*j;O8}ze^!}EaRT1}1uUI5 zeYprIo7@u>bcXbQlgaFNWH%KQHMIcdXaC^Ucw%-FhIEcTq;p>!8-c$><;t3sKr zG6`{AFl{Bu6`HNhOZ-EL<`zuAG_P@Ee~%7uj;;OT-nq6|8*BGY?3_1I>!=syI^CF? z=r)le{Zr}B$n@5&Kdh(uvdU5Y;!W!5=$+&2t$#tU*|u)+d)9n<0J@UB`>$AjkwiD3 z9}lOgf3hw(RV}?NKeBQ|J8eTe+PA1&;>6kF=p12?WOZjx#Q8vm>2e>mFUqR3B-`8W zm0fSU@8~Z=Xnurob*f$ZreGiKLhiMw{~P^$EBwz zGHm-;MQj)~F*Z{aOPzClKpFkq?4W6)Gk&TjCn2#Q6AqTLYe=+_fqpTd zDtR+Y;jSTU;r3acEF*8cfGOK4FSb?p6a5TnBVQ&R&5#DocRupzJXsG|^D#_c@PAe@ zF-a=6gxDlrCeX#}BNUHq-G+N&H%wx_GJcY(ttPAHv=~r+JB<7}@w_g4GtBjR!sXyp z$A99MQ0tpe2jXH_-{>QTqiS23Zizw6^xR)`lwfI%Bk;8Svb$wBn=(0&1xK51&23y# zpY%&I!pwWW2$IWG#kI)LL3S?n`5bTkS@WzwhzfNMHs>Z5AuV3!BrbeW^!!aamK-QH zgN7r8a7AG=_k`z9f`9sp3yvqs4+D%c%+C}r=#+^0=$=W_J_o<(!;%>S;s_*bLvu{a zXg@`F8>NLSQ}$T4Z_gzb514QzzZWHM0^_m7|u6S2iI@<)UDoV3zZm1WFl5{8k(t7DlgQM`+E9AiL|X z1-0I#gM=oa^*`gl?^Q?O=MPs&<*LW@B|f6yVP>atJA~3OQG8A$^`#IA1xz!i;8+<` z^GXgl{e7(vJ`GTS34v!P)ep*)g};X|ajRx}7gLJnmn? zcHoE1a@aI0S#nc8(y+n~Rz+oJgU zSz+4K<%JaQt~{1)cy)h{Zy7Mn#Ki4u1aQBU62)ZqmH!|2qR}JerY7pgE9Q$zK_o$w zPebeqRcN`t5b_7`^hs$>XQOT`3;y(-#v`FoJvS4Ks_3;GEA#HQ3NXk9pVbGB_hI<1 z5UcUtylJiQ{k~EAU*X{MYC|wY2~taesoQ9OXt0($ z9B&A9q}?BUXk+9XC*bT`CO@e!#aC+_)}+qs*!a_X`rPy+!!?W#xm;oG@(E0EWT=DQKO26^=BA!q`-(88o6^gmhh?k$`4pvtUh#t4oz{htvb?_2FH6lF zoN^SFDMq^}E~~AP9{r+^id?8CIu%OFqt4T-F8p(o9-GO%V_gULFsnlNcevfy3qxG$ zYrF><-A==s9%3`em`o9i-rDwSTNy9AoAb0=;X4_WF$d@WD{am%4rsIHzhypX>KvrC zYSpQkVdSpQ^k$(+g0QT8KKl?+Aekd!uw$fVo0_`1a<5km^ZsZXhc`x895);)_M%a- zM<8H5qp}S)FdI(>3VzATe zNPITE!F_+~_hQDdvSVFt5&eF-`JBzL^CRKgX8BAQiI%7GisKPx;! z@%9K`Dg`*Cq|$9EMt7<$BS9x6xeOxjk0qK5o7c)j${7h_bZudj3hkEBS{XJ$5(K4+ zd8L-MdrvmSVPnIN-BW4t7rdLNDq*kY4q%d-T*sI}eVn-D)M%j;GTswRw&mbwo{vBl72C2G~Iz{NP3C8Ag&A0U}h(O)dhV*SPi1F$miR@7Wm-dj8FZgQGSog{znTW2J#lkRW5>QA)J}S^0ug1C^?{fyAkH6AOnE>C=Ct zi+Q>(IWwDt)^Z00>Q@kC*R`U>_WTs+vz|nmKFWeBC)Bp8eT$CXY2rqtCgjC8f^0WK}0x3+! z-|X_mo}%Ym$4IS3RCyzq{t=k+L{W7Qp3D3UtlT=YI&Wi?yi-*z^7`wMVKAe}VUa}B!|x=>Bf!AImGn@^ z8k?V$M2)|kr?c7b2MgmL*LWSvT2=G*V4huoUxbv^mO1@#4uwcCp?B5s+Xx4cW75L> z;dx0z8F$G_xXB{w-$FKcn8F@J3HE&DimZJFNo|MH=Wl832k1x&_V1aDW`pmDCzraq z`d1rq@&W0xlDnGjoe!McHx0qA$lkc5bIoycobb6cHs5mz8w956J}#K!3)J#O!XEiD zeU?rU(P#A>Fyy^EQSUj|he9c%*3_gZyTd8L^H<>5jVIhD6?wXSF+2xm`=%Je8e*)F z=QdR_gFf(k0Vf)%b(4KcF*T?7daI68_o&dR?_l~JbETnQiGZpPsrJ0W{hf}&bykkn$!$U7`6ML`VcKfzNO&e=PLA=t-2l|j%!S|ZPmR)E zz?33LvdWr%%#EQh_6*YM>idH#k}o!}?O0{fy(KX{p@AKNQ{l!WhH4*+kvL^JN8 zo9<_jXA^RC9ii^7_Ba4U)*1*M;|Sx*dDeMw2F|nij$jTFVOGQuyvcy!{G)$)jmJza zz{7gQa3z;JDEsn-#!R5XG8V~}ri9S(0x1&QSTcJ)mEO}G;cBr`{Yg{-36eqqj+y1& z`7_Ful+NUWM6#oBFBfPz&pJ>9c+x@j{NMz(pOZDap+e0j5kDtyeio6(c$K^>3ciIqLmPf?zsz zvoIf9o$@=6z@1Wyvd@(We=!{J4wwF1rRf{2`cRfVdna5CW@GlE07HzjfTBzm!nYAl z5P>C8<71Z0n=pKN5f>GePHcrSQcaw6DaIl?ub5Qa+PDvVRRrG?rRH*oSDEq8WQ+(t zG_sA5FrIBnJyNK(=A)856EP(2`uO^+E|F+eOts#LDq>R;DT*2d?Q5~^eV;~}Lp56! zAG)v~Sl#U5O0V>qX1IQ<(Ib*spmhEqWku^(BMOao1!+&2vj@HimQ{f&k$ePP&~rS@ zpscBdZv03XOgX1O-CYAvi&T2Y@+bY^**6ko5Ulf(kM(415_I`yYb4U){P89C9-Psn z=hlW3A7GeMxDsq&5AL>tqd5fT?4PYs<#R}%*3?RS%t6&em$>t4&SQLVk3b9xd)e+- zb2Z$4+?NA5UaYYJSk4Q6+9JQ8-}JO&N_W(+VrwwSpDaK-dk!hCwr;a+f0}N04WKWd zver?~TX|xBRnIw_Q`fW3@vZz^vx9|GU_b9YD<~;;DReM;*EDr{fo=|S2dD&-g<>(y=JzQnTc4(&S&$Xn1}xs#kgZJ(g+VvlClH zzZ$aRmU5dZDb~6&Haz$1(sz7sw2ILGe-`lvh7e3 z9iB1|pT04_t$vkUWh|Z_oyBWD!ifMPj4@buWMGF1`~<-<|uG{4m$3r&d2fpWSt3EIWMaA^5BUYB~Fr z5k|>WpZassO6T31M_7ne`N{Ifa&}HL8!DG_+bY3Y*Jkq*0Y`9xU?**BO3xCP;h&h~ z+2LtiUE7)$6^&v%eP8a$adGME=^E_C=Wv=H93<(YdDvS&#ppyYRaWq$gFj{r(@RHn#TSyP!(9A9(O;6)Gj(0>=Kc~mywG`_Es z&Am+VaGz;7eHl*Ikv)Y+K8^|Sb=Eem80bU;p+c#|A?0>aXnDHb@q>_^o)PcZTGec6 zimT(*-sEh)Fs@bJNaMU2Wsf$s*|%B!&5L1f{0{FTDfliJxw~17JgELvbQt~vez~jE z#B(NVYa=UrvGa~LpKuo)Y`_xv-h)8Oaxr+~X$X=yP7|Ur& z^~Nohg6NbMApav=+B3`4Jw63o+M+eL4Wr?D)^}CSKx6Qhz{kzWBd=6N_JiF|Rfd4} z3)x!bPEcT`U*R2qmqDsY(;h66g3@yilxTwDHsw%X1MU808%8xj-HF|$TsUsTb^P@7pJKjDx zh=u>PN5#O#uq27o_P{qr@X0@b+VLI}0mpUD{g#+pt!K>uPKqZBuN(6EVEx0huUl~z zHjLol36O-2)Ka!3=)~)l?t?+P{ty)8&P!qrh%AA7a zIy*mw6KDK+Gg~2~{zaTfDPo2dc{Olgj)JR=Kl2?bkUY-GE}IFx@tr#W2lvEyZs3|9 zqOO1kN|H2H1>HJNqkZX%zVtx6S3ma~!V+SDz0BPGrFZ^XiY!nTlSX75;}(wJaP3d~ z$`vBKRE%$GkL%uJp%e&Kxdvl0P1DgGMB+2eZzWtsys=Kp?MP6N>`acUp%m)Ma4L~& z6J%$Pk-$`>VOzOAMb05{gG-kZE)uPn^b~^@t`ya$gZmfIN22njpxw8K!|XDQSI(yo z{$!c7Cj8YnO)(E8?GZ<&e+u^#!Hqe4pi#k`=Z9K>#@GUVu7aDfQ9Ozd-{C`+ll*Z< zrsHG=Cu1TPN3-}mAJmTuUh#UMO53BiRpr@n*YL!G#H>2+4j>IV5-`b6@3%|> zK#yhtP#Ur`6Oi1DXzPj4=is9|4@~5oYZJM^m9g8MZ? zzg>-4f4{s!nyqfmCX%jQEhfSHVPr=*LVNLJGaV zw}#Mqm!$G?pX+{FqPHxz;*cEh%=RQwjhd{|9@3dah61k#;cnSLuya`$urj*5y}m*D zW9s%@m%qFEcDoKv5xskL9TI&4G?jE*POliRKpEZu4^isylKTWq>$pdQ-H%VsQ)?9O z&Apd&#HREp!Gpxeq?nayH+hz%d!WaW5pB}_9+=?(Xz=V?(szzbXhvMfGf^aWrIz_b zy&QFfnyP6f5;JC>e!eh*dmX<(6;hURfPc_DVPye;Y-IwsNPIZE0T|IRGzZx4t)UJ; z39f$XUF(9`?@sR@0Oz0!_;x|`~JvgU8GY6qq>qloqt9W-!Qpq z9cCq=8`p}R0Z|%7V;|AblmYerxZ;_}1QEZ}vq?Tn6^BWnWqT}?tWiC=g&R$w`=ew$PvM~lE+77ceJ zn6oz;nDmXQo5e?eX~ARgWH+*H<_3oBvsd38mwjREtVg$wba;wvK%7EUf6`LkjPfN8wK`a%bmMd*Bo&` zmN)=cFnib*q@k)D23YFHjaY47j}y>gu-k=?Pnt;@2H z1RBlPJs3})@u}xwoa5Nja5SC2Wav>nBY~7AvdxzlCm!@_I-xEGVLz$H-J!Q~aCE!f zal2;HzRTURoxt){J*s*G#IZa2@Q^#T#cN=)8cc52>(I)+M{Y?x${nlFc_?)rT$6;6 zsB{%``?ia$YH6|pnKb12j`gYPSk675#Dy3+gPI$dmoLw=yEf+zxE8A@Na{ZWh&?H? zK%+7Ksv-dXj=Ceucl0l~?@~P#*Kn9M$0|8``4KIN&^!WVgiXrIf$Q!c=DA*9cDTty zwO+>NK?N%~nQ=$eTm`;^9<}qs`tRrV!Sn?e0?C95mTSmuIqI1rZ14wNsiX~%2vm$9 zfF2TLRya9+U|x-)&t%|K#lP4zvVRReP#&Tu`^_hT-c()g#wD?GHZRAy&Tj$bo;gb< z$L|(!7uTi;)IRost4O|sRDVd}I77O**+fVbRqc1v(9H^hj7!v3r&!z?r-zKX6_`s9G*V9Dq5O;upm@6#vaggQYe?|S_+&bbfF zf9pyj=bB1^UI9*$$ar(sb-Qa!eCQcJM$0)6{!^yNXSMtEids3vs|;08*m}EvO^C}F zqgRchlBxp#+ZE;18$7Sp2eXqiW%p`S%TU@xkY2v%r zU}Ib=&(EBA`)uoAUYo}}Uqpd9k)jDxkw@!*67hmIn2sO}VVQB*&12wv#LSE5)!%$y zaD{lIE7DgNNxwdLE7itTJa5fUrvbZls#iXK1*+uJ!h5jDS~BYOfNO%gWTQmwOoT?K z>GI)>_W8EP?_Y*0Ds9lU$#?0lzsSjalXJp-Y&+zWE}1DF*>BGa*^alh*zY+=#pR1C zQKcSXg`1Tr31P~eC!anTaF2Gna~oRznNb>NF(R58ILTP{?fi0m5RG(T!Q(_@Ns7c-XTU2A~f4*}h$) z+I#_F&%hEzvk~yrSq{Obh9{H_-yK}94SBAKm2!g!rH$OOn5^v^?NTC!b#)dVFR9dU zxyVP99iuot)&W93QD~HMp<1mFhIA~UI-n^~oyFgS>IceRu zVUA=CpYM*%Wl^aS`PN6t0O$1CPGF~pm#L`QFW)+&bR{KI{(y&n`2GZ+(RS`t zoouh2^v$;QN5}ZZSgFq++$xPQp2)lF2L$YiYgiNN)fL~}tE=S?TlO2jSj=cTjf5PS0L&?+ zzO5q8C}T{1p67`D))etI1=dCT>^-U)Xl5|>!s_?SFfzLF1^WB%B4s2OdRTWg#r!4I z@PS>tD}pv3d=;xYTr8T^POSc6nXY+5v0AER_%&{D&mShl zz^mi8myBStk0U8Wp^t+?IBm-zx+Ek6OSDNEk>p#N=6oacDXnzjtrw|0(0(aZt#&z7 z6!~V_(DQtZ7w0*?3a2RX)c)K3?9~kp4-bm1oQVZwhj?m;J-C*p^-Yl^E?TPTiW0_K z*(F2384=$&rOMD*9jIOXZ-{FOWoW-FIB2!5Aw^gb|B0N@?hx`1&nJyb(c-BAKmk zhIX+k@(S2ZQ{EHfTDLw@0B<9(&nevc69>$f)1( zr%^Ksm+<61I;D3o#X6Z>OZmvJ=K`C3LQWKJBDI6MAfLz0-vTSpj~uJVNYG7kckDU) zW*W56<9m1C+B$E*RO)Z)2MVtsaZhLea~C;5DQ4lid0-9O*@ynLUQ5Xxb&%wR`e@S< z`E{qLR(Nf&=xhnn-anI^m$};tbNzYq(9Y`B>N4a~AqgVdp%I0l?$U31&g{K*KKIP= zNDkSUK}I^c?%Q3n_oo%>%P#hZ%?~z7yBy|PZ4-)UleXqvm8{n_`>0jAE>dT}+geteFPsL_c$1|NeSD`T$Y$SF{D0E`gr9qI_>2DHRk5^DpAKl%?2&=&X3Q$Lr9ko zi|hDP9=U|RwZFIE#jB1JE9VBuZS|!EyHOk`f@-4e;teU(Y@8ECoUub>RKf}4vDa$d zP;nG3a!$(6jb7zf@4vk#qRj57$6Mi+UGo2Htv>`wQ-rjI&P$D2FVrw(QuBP2PUE#w z9IdM>(I~RLyF1^q@|8lkWc5{3&>s2h<%Jo$%k@W+_{bPb4W}~GCVzOCB;5P*;_l5S zozIXe2~<=p)zV1Fc0|~#Xq*=Y1{Zm87rzrUL_BkE#1Gn4UPIWJq7ZhI`ZlqViD!_9 z-GiR=Av)NW)xCIn-ETfem|%wGR_M-CY!QNf8tHLt1zOdLF`Aq3=8J}SZDlzmFrj8g z=~iIO))_^;nWfXp`!uNP;Sq9IKC+p)FZZnb(#}1a$0f$`F19CiNV zi$v?451N(91RX2in*kJguUlFH$|C!0i|pC4Vl=NPl#7|HX#1gW z=k_Sm{m6Wvn&RKXI_hz~eD$EF#$ovn#*LfEN%Ph-cEwsT-^~zmOQZ^6V6$eoWU#Lo z-5$H{e)h9PQsSpHk@L!}A!l#;2wpx_PH+x-@V<_3Yh=s9zy?kR;tbX?z#^t!4kmEc zx9d=c6Axv0f|wap=QEX_7M`%F?)$egI|WaMfb@Q_zI}i@?_wDFbd;KlmL$>7pZ#q# zCV9r1n{nWPz^9t#ZvVCuex_!`M|}DcTcjGlJpXLwqE2EXh=-E=b3clc`8Do(=Qk5y zsT$Kiw?tktWiy1o^?n9|;ndyo{Y+}lfg4m@7PsgeKvF!4;k&tZB!5Ffx+Hzh&nM}- zi6O5HJ`YFfVLhw;3N!zTsz9b@@#M7eb$hm<_z5yHAh-0%3q>}{8TQ7pty8a+!Z|k6Jl8@KpB@!Q~ zvj8jyOClF)Ky5#{RTsnG8b#Qh1M>aetouX4|I$%sFQHPT(O78dqU|~&3c8Vdd6;lt zR9X>>3xf6)!fKK<`ylr!MP`JZRg7+@wMrkHu)U>Od5>0bleJ*|jUk1*Ix2Nij`+xO zBDh7oL3(fE@rq`Ni~0;wcAKP}wPJ2GD@hLX?{%A+b8K+$=p~R1N&H@-x?aQsD4$`X zbm$mvKq{bV`H0H`3?p3w-Y_%)wjbvh=ble-;IvNJ$z$MJq_y1XYa8m z;yO(B4CNq54v*EL%Wh;9z`F;u*~wtMi8P2Ry*qy0JtfLKN92ydd%9^D zbv7XbhG6@8HTgaWt3ky{%PZ|tOh!bYnxxs!k zyS5g)LB=%a{a*=ftXE>2Kj#c-BClqD8Tr8stwWgOS(XR5Rb0#LBF;!I#r(Evv{Fwq zG71aZ%SZ@uhswFLv=|Pn;Y^Q@<_$kmo6&W4odH&P&A+psT=!x}+!tI&^P9gEEt;-x zWSQM7#0mKmGA~v~F!$$Pded+?%eM0B`1Sa%>DQtOitaX5jp#g$|EsN)O1V)|=f>tW zRT>s2ZFc8Zd$Rf1 z?O8T=<^N}Sa^0vhw|UkVpq&6ZbZqQAnFH zh*Jt33SjsQr%n}06{hdi=+oZSdDB>}KF$>97;=cAYhY*w7zWgIsX1(U+g{C z-gm6J*ZQor$ZZY0P!#DQL)T5rNOfYO@mEX>~)dOd`2^NBE+YQLH7J zNX+HDb@f!4ZOW*@#K1LN7wAgbaqH%Iotx=bgO}$mtSKdC#Z4d2#$y9rg)g!h&_Rvr zFl%Sc=9E!5O9d;rXAY~W_zyn`37t6H4IkGkY~7L7Zm9gb#@bg;g*31Z^bT>qNQ#1$ zsuo5fuCK(9i%o6^dYL@IQpIossUadqh*8e7QCYH|nlA~54S{+ss-oUbLNXtj8FD3` zHkB^NbZ=N4^Je-U|8#ctBWH*7H`c-^XhNl<9#r@-b$uFR&N#|aBpyG-vGA9K5Mj3T znXse6bV%FJG_vZ>BbRJ9d05RmY-#fo{aibq$$idwh2dTydE32p%~C7)o{?W3&;}si zYL$$wBV`SJ?dGRM$=zyIeZhIhWeztUMd`E7a9GraYMkw^yl%5kOA1PkBZ23eN@tQ& zrFMwl2cK>u8&ks_y8u5&k=GwQlDkhTdsD!t9p8z6+IDwts9r#}C(|u3IbbiX3x}MW zZh=CS=Q}DE0^XW;N5>ys?FBrlIHNGhRn?OhLiDXm)ScxKy9@W1RR<`kJDwuPTT&X( zZD8fFn3C_Mr~1j|JC!JbT}`(f@(y^+j#ao7dvWx5!TcoY#gCm}W+mC6#@%iEtyF(o z%yz1pPYYb3DNKK=nR3xu8g`-aiJi8_>6N!!Cq=Vphu&c@>VX;h`rcd1F3Pyo979ak zP2aK^+9Q(oNT`#xqgg>6KEntPHjk))m#&&{w6Ls1v|Y0f6}Tptxrob$9U z(!4Xyl;?Y22UT5>*^(9y6uk<4`!e*eanM}p*ji?+TZ1vMpv%!r?t;fh3oA~r0ve`RYIoH7Nwi8k68> zfyP%p8}8qKls&YQ*P@QO9jjf{YA)+{agIsyoyk4D3~3U-@j!sGHrBIMto($K9{`24i@b zz%t6l${rS1H&yQu6I49N;*O{ZWS(2-G z$j6;o8NzqQcoYN4W8CnvYDUYWkjE`Dgdjhok`mw=0f z4NIxNXd;}a*m@COk&}P7Cz`k*BNI<>*p0uuysx$kD*19&g*0 ztT|57k53i0vd`^3e{+6BUG>wt_*OtE+Lnf7A* z^8tZ^+0Jn12-<22}H+`^0&6fNd#K{`+n`lwVicuYw)#awIsF>erJK{qT^Wo@6?V9nH z8!T&S{0bW1GdUCTQg;>ysezWIfI`n#&@Qgnwi1$mN-i1W^r=#!AK zSI}dUv?iCLyqJY5x_eJ}*!c8z&&V1}cRLsv;K@Vv3CYn{eY^snV3u)ow*~H-v%IU6 zq|@*_7X#>^2`ep6Dq{>fGB*7 zM8n1HuaA?6u{Y9ot8ChC10j;HM8rX-aN z_<}!9?qYLr)jb`n06oz;FHM=PQI2<67i%Eb*lvzT1w3IehhLP5!g}?!bTh zd?J|8=5F}bO+!@8cw6zl__n92^{1=NYeVVR^l#jo&kn3_vf~Uh_jdmy?P9L{y;OsL zoff86rNl578~s9v`^#9}XSR?AleY%T>#Iw6n*(^Md5hzerfJ=dj>Nh1#NWdTF`QE` zicjqh^~Du4_2M37Tah*w=6*QYwN`dNDUT+mBSIQg99b($D9L61I6tGzXoz<$zrHQE z@A%MAf2uB`PL!Q6cLfcFi-bIRd$Lz>)}`t@Y`l5f9`M~>y$Ve9J_rS-8PlnN3xt7+H&Qz1RO%-}$PYi&x_f_S7!-YI zihfNLDP>pXt9)Xo+NQO$JtWS#_Lc8xOf{Rf-7&*$s+@Nk%E#>CV>^zj82RY-iK88> zyyhBi0gbnZR#&gP1s8sC^~88q7JtQJ52v|!z8TMq>qwWrCgbWFr z?3ekOsOZds?+jTkmU&nki0UA>w*8J)l7Bdo_}XVwrtt818$!T~{j_$XdF({4u=|)K zXLCm}vuOLtm=k(PSz6Ist|Z|)O(3oEtYFD2_T4CXr>v{?aFz37+E2pdO^b28lQp1y z#l-ij3TBT;sYa(iGk@>`>KQB?e^}FW0mag&0t5@lVpAc3dKVnJ!jFws${qacpG4WzlL7%&QZ0p$WUFYbl zrq2VTzB5ueb3AQ}0+W9HLhekrKxZwJB%fU6uLz)D-lHv=A6l@rF-ns-&xZ&Mors># zUYwoubfnxb*IwRSEyo2>a;1?5x)9v|;7ZdGHGC{@Tu0s_eQZ~)LdBZl`ZDzR7#g#S zn!K)`7930lBoy_K-M?_|IC9yt`8vx7S=w`SaQ>V-E3Zht8Wd-vGJMA>V#4OQr{=MZS>g;;uQ4nN-COe;~8 zGqA2)nly#890q9KFyQmu&0*b5uygddAzU;l_Q>vS!ofgKIZG?LpuDwVjF~oOT0Wg) zTS2e-wMA3uje}m^fwK5=PpbzHZVLFFEz(ws5UKuQ6!bC%Remk_q;CZy+ZLC>0+vD;WFRw3c&svZ0GduqSkSOcgC;gm>M~j&Qaniql8+?=3BxL+C1G{DDfOr)M!K zqW`E4R7QGL8&*#GC>;5R;iXT!Rw%B=C04O@Zq8)G&CCpdlO|9kQcb}SuD}4b4QAQ6 z{JqNPv+1YV!H@3mvW-{NNZz;+VX3H~a5kKcB-59vxUobTYy6OjGb>~2y5Ae8=npTs z$gN8rU{tEHnU!nglg*=fo)E)8&MyQ+E*=)SpVeQqWl8%PA_m|GA22Oa_+%lwX?*9c zj{_ewhsikqVC%PkWqQT~-jFyi^Eun%(sl4o!JCMUu^%OpCG5<4Ochcs*lADyX7QTy zS;tdC@{v^I?f#de_@Q?_LUrmws%fLcWS(6>(c0UU2goJy1TRipb?kPqWv@N_g*_=7eckz1J4AYOExFRHEO^G8bC2>{ zefDA%*O^hzq9i7~p%Wc0Xen6cQS6r~(JwxmU6Zu1{;VX;FD2x-7#5NE!Hc=ok$YG}rw?x6_3SEpT5{DB z+b(94npEK9ZPARcn5wrssO`jaK!}-4AHTTE_=QH$cxB;c*b+f=WZnA)eP^LB0`2l4 zKR)d))V~zNu4QrspJUzJr1IPL+dX;K?c{gveKr}}Zgks4hm+?#-F^78CQH0w$f6|B zT#a_t=Y?0t1}1C&_#8^$azVwpdprEc^flhF7~J)wKk>c)yad$017>n`cdvi^QojEq zGoDZgTZu%jjrbltN9dlk!~5P0U9#p>tqX=nq1}R}h(tb-Rxwi%#_*?dpi~bA(bs&6 z!bshFo^5I#p2ynO+Li#gU=$bN1-Gyhr7EA_JdsPn1*cE4x%=`Q>^G=@Ef)sh2)ofnySFk{ zImE?|!~pE>Vt9BX8inp?_X(p!CjN6t{;>vB0X~F)jM#EfUby~$Lkze^a25M)CypB7 zoz)tFT%i$p9ULhZ+!vkBj?7waXHd?hb}>`R>#6<>vM*=ne-bVKOkP^yS^2I=jW3wI z6nz`~axe->67A6s-wpS9f_Yc4gc(SYr1kSYn=yh*Iv3x#7T-DRcXY1&?fl>N=t0LkeEb~60kkN)#nQi#7J$9VOz7ZO(ps}%10 zG{M$mfgrq$HHrC;?MYR`_73-#i`et{(`EVZm%0k#os$K--1_>8OO@&OU@pcTtqt+C z`Lh(nZ%mm`3fsU2d_^Ef`wv6tm&@^=H;pfz0?YIN{vmJG+G|B>^$Pj&b1=I?f@`>h zx7f7{ZYjoc5rE-7U=N_^kA6x-*1uThe+)mB;8Kngqk_@%9pTj9tq+Q_fZ3< zN{^K|D>>O07J<%-?e7@Egy^Sz(OXyBQlPW4b1o@p12z8vzw>=H6Zs}xtE6RxS}Y1l z=YP%bZ|C0sG!Dr0ndBH`bZr(62* zrLhliO8e#5|Ldld6$3z&n#9PleEqf2TFMtJ@>JcZl`}S4ybc%#e+MYcC zxi$gHM$ZFy%^zRbu#bM;7kH&p*J0>(343DMWm5V|e8({`AL##*+B*dlsTvhyyT%?Z zm#bY^5V|l<9V+Dj5(dzqg#9z6f7<&0$8>)&<5Xd+nFL(VXYdA}o5VP`?h$((ZBlq0 zZrr&fO3U7_B$xQ|&mF~`z}QNm{`Y%&xEsavx+B8GP7e{}?P1jSxoS5{2H*4G(ah8e z+SA_-P)Q28@=>$2B7Mf%<^>di&EJg`6?jf|Uo{hV{aM28mt*|*n=c5iR+i;TT_1l>Bzfip6fjeB2Z~Yy znGOY)L3jE#0KO37qVl4Z!sHtmy;VtmL-ePS=W?|F%R!dPjnbmCD$Bn3N06h<1=L!4 z_(~jQ}tdy)1hbSut5^rK;2D>vIp#{kJ6ddwE;7 zeNnYPdJ{z4Y`+S-SejS_qkFp#lzE`C4qI*Y2CO<1k%xeBlm8>L_RtM$*4q}dfVRz}P8Dr-4S! zeLwg8X~ew(721XXOJ$$MclHBbC*_)DJQbU{srp(|h_d@5i?qqb=$PUeHt5q461oJKs9{RZsQ=6 z#r980{o@q>E<6A8fbs9ot^g#n?>mQw7vSi-pAh!;cTFM)K>!l+sg&3Kw+zES^>e^` ze|?yzJfIQp1#}qA-gfYHbz2*+g&g_tYQfw17rRpy zCWx?^Z;pir*5Z4^?K@3%1Zdy+`oQ0Oqc&iA<Xg$I(8+o0hP$FDsBXL7`$*Z#jxu z$mGouSpcXPOxU&T97FQoQv++p*ub%e5ND(mVoy)UP+R2Og9Iw4J(v%CiyJs3?e$KO zN}O*~?U=H=<*+q#Xc8L@zmWdI=(>uB{8n^THVp%oi z^TrCariw+jCSY;>6ZPd#kiLEgObb?A4jp@XCt6lR>XGerwIfDsEPQi#WUM*z;vuR5 zZ8+QWbg$$y{KWeU7zu!BAls^XYQoc4b&QS4^!jjLT+>v}lBieKN$c0| z!wb3cq_(JtXU&Ps+9vOD<>rS_5><28LPxm1J{yF#ULpQ|4kLO47aw-0SGIbstimH> zbjp}8^!@YAlPmSYY2~9gdPm|(#MGP@KD^)Tv!;UF#ZR0*Aj_V>)IC(zVc|u3skAN% zhakiBFQ@olb29e0NnCbw_e@<~ospB1v(?bZ#o4)7Lqp@3G7lETs{W8Z4b2;V_x9~) zK0fvEd#`SVN`>6{K6I-R_NMZC@j}(Z&?E-@Nf$-|x0jugVS-UK5g@qefPvFW$$;V! zx^Wm0B3ZqQ%VbPWk?=5`+$U{(@v+pv^^b<0GGUSzZZ30)+}kB3@$E<6pLxa7POX#i zVH@+2S`u8@F4~Fnrh@Iyi8vSek@(ApAEE~7<1fz=e}Ye_sh|0`Jk`RA7Y)i>@B zXfSEAAvJf(rb?~CmzI}>(_7oyy8+F*_6nReJTbv?a&j`Wu8{KR#t04k0h*?^AG-%j zHBt=26Zd*5l9VKpxJt3L`{Ujn@XRty~};QQEntGoi)%nnyvoiN*4%lkjexRYloN1y>NA%sxenqRxSZ# zBV9c#UL{dzzEbs?(`72Mk^Wpe;9W>s=LK)iavBy27Tuh}aD2WP9}u-c$TpkHu1d$ ztml!j@6Xe*3h#)G&`GMB6Yk=6FEjjN*Xahiqz1VL5Zl=C&$I5WTGz)88vv67&q zfX7qvIhmvf^!05|nN%AMNIUAe*PNq)XfsUSb&)C_qwQ%NDQwxhp!$5K3!LGNy7|%` z^FWgAu`;R4ieh&)ZB*3|G|~AQd%W@wsNdM_I@V7X*VEK5+H|k_ALki7zXvHOw;bcw z`aDeL@fGggm2kl>qG@#S{?_xxId|UvYZ+VOa$PT0?+VGT`l5X#_rXEM7; zy|s)|nh~n$(;g~0GUr;MPRA-m=|hBWRzHYjf|FxPq}=qRcHp_&IbwLjp13cSXLd$R zf3#UUfAykdWZehha-Ub4w4^^G3Ygc|h{+jB*_7H@KhTiFJ{d(UhqFzj#Zq2wUJ6Pd zj(c&Ttg-1igk3GJR?M^VQ&coDy}IG0O5?dcv>@iFwqQHBfmu(kzwV`q<3+v(tq^Rq>hg<1|n8ShVbKzByA;{3S+u?k^mKNgK^LyZAa}G?N4C8lf8e1&${66K( z`s}^$rH!VjeN(^6t#+Lr?h(-u1gakMkRj8+yx_UuAq^gE^3N=9pmiJwx}#xa5eI;{~V~Tz|U&U7%E2a-Co2o{qxBZW-12A}FAbi6y<6gOhUl ztJ7jjT65wH*{n5nastXvUrRLHFP2Q1&0d5LDajFh=F_~Rc%*r;d}}dZm=ogXnH0Hh zyf=@} zo7+Yarn%v@KjLU&0qG8QNf}q1Jx!L(y9E;5ibum z1~BfUfLb_JQhjxttfY5Rg&%g}=48L7k@t?pTidtMJJgd_G_N}k#3iY#IC+D zK6`~L8ZGz%XV=PmMV5VSy-{L)x7^4D?6z^*uohmsR!hcVJwAn+@gXEon9A4~y!+h9 zDY(9i`M*@7nDutT7wedN&uq&kfg5J|mmC%H$x$m*Jxb zR^LM_9wf~1ggOVhAQI=UC6I-wA5&^>-CaF7{6r8j2}?lDY-5kfX_(fW6l@&YRxn=w zwbl=60PIn^fk#|i{Wi)<2g><^wj(S*JahlO+}^v4Ec;PDwQD zfsAY+1N~3Gt+KSVG~#+239_qw6(w(-D6io06PTNC;#nPMZkT4#tF3Wzrt41a>%puZ;1-&9`C3_9;l-IH=D?hXbmysTZ0u6JpIoemd zRN>5Y&z>YqYN08>;#SH@>n>x|1dPEMWAW#YbXdI(NtlhZbmbNcFA8L;u+p*&AqHXR zTOmxu>Q(cN7Io}+>FPpv>-XMMXbp((mm-u>)$fK3iQ`%IYg(8+rdVa**c+3Dum8_V8;YIXp!*+A~r{c_{(d~p2$FDe* zEoEbtMJ~{wUmG(%+;g-f8|dBO>Gw7^HvRm9{QS=~HKVPAk|0~c1eu&h4buRTFfucD zV57@Y!b&|$FKE-GsU;nzs|aiP=H%B!11zo1_Pe4{mr9Y-+vuJwjmJCaSzSe>el$%bf z&>x6Zx2!ci>%~HJm{F5T`2EMrrtCs)^}K;-UwNhaGU+B2(e_N`8zOz*Dl=P^(AhqG zYf&yO(!N(k?NyDA)vP{B69n4$k8#Dz{?OIb;C;T9zM?R}O}BYh-u)8piIxvL4~JBV!W?hU&oZTf5Qpfx{@HF&MA`gy_U)`#a(@hY34K#82yy1 z0l{axAsa!v@Ot}=X5UZ1_9gizA;;~UapBY3Rz-^t*a}Ty);8pai!9^ux!-brF5c)T z_y0cMU7q>w(PODeFNvVHcWC9-I3F*Zflew}~ z(HCly!m0HOyBb^ro)Fb;_*2&tp@!r2XPQY{qgWT zL+?o_*_Pc5e-w3e;ISHYjm=w}a@RiLK3`iK+a7v1T*~Rg)N5semLOk0tJ)-=A%=D# zx1@p>r6+ul9MOz|PE`GS#S~j=1Yv)fi1b5cgC!+19ls6#xN|k|hQ>$t=lFQ>HjvQr zhIpJ2zS7*n5S42-O@BGAFan0xTbjy1+A~g6%B()y9OX1H=<$(hzFlp& zQnMY`p{woVb6J^6=+DBDbz>WBN`tzY$RI?|h!jk2=1nuJ2%ieuh9Ekn?ocyB-oFcEPw8QnI zG9*UYUa1RCI>>#u!(~%6MPtd3@s{2bcr`%?f^fJFY1(MH7$QmvxwAA zIl($sZoJ+$0cUrUly-+}Vr%}~6}NNi3dlUqk!=AFF;f(R^O+%!t^ysm9`(6K%S1b4 zK8m|(9eF?U%i^r-M#L^dl9yGpXO=nTj~8yp^Hj=|{<*_G4M}75FEMnq}rrbpqJOJh!>K zI+IG!+6^}3m9%kwd#hO73NT*uoh3pZ0X&)v$}4?xY^* z4$2GsX}KXa2`BJP^x8usCgUQE70ePVYYVqF#|$UKM&WPL6yuU7(eMT*F1M;SYD7;Us*Rmgv+@2=mDII7V@hPYalt--XD?hx>NxDzF`cVMMd zDXr@B)Y8`y6wE)1)!`IAWvy&B2_sk?f4(96Vgv!`?`*^^-1E)Rn=zAR{*IV=oJI&$OBtj#Fx7Z zDBGbAGBf?8UJUoYg8C#`#BQAPvgVKRHO#Xh5h_Ne;@?1zU|TucCP*u?ipZ@~XFo?pkcTf|aoX-V}iN z#`v$B&2*vO7;4&obJT+ZM+x$r(CQr(JMj`CMVM#h*KFEyqnQuj z@oE2r+!R2SIuqT?0ijznl^%ikJE_>JR?EjArHXSJpNnlGH$hr=E!HlAgp;t?e4lL5 zO11`ldB}uyZObZBUWdwwV9P)V| z7BUqSX_wO*xLMsCE`F>qc;qCo;To4t?)S8Ws}U}&+_GK~N?-dxV3geB#$oSfL$kz8 zKxursqw884MXVL6(AJ|DpK(wkuA}l5*Vi9tedamPs6ifXJf+$83OAFpL?^ZQcu)2> zD&$r+JNjwg_k~uCMT6H2X-%oC38^6ysT9Q`oSAohR>bR(G|2@}Br;oTMt#-Y>&5$| z8Bh3IYCXs%t%}R=cSe<@8-KBKAYkRT2Dmsml@FLTy1Kd|0KB7UE!=xwIg3Uoj@K&8 z$jK2gHrE{0v^YJ54diSB1uz;!-LCE`*W0$TG0o z@vGuDFWqEoF|bH0gZWn}u=D#Mp}xs6g*N1B5(iTwwNFum(78AB@yJnc4n}U&O6&CK z;-tJsHlKW{#;arhU8b0p-%ifrFG;K6(+um#Z_@M}m6LS9cwKdd2Gs z9X{RXU|Ay+!NE~-%Na`R3qNgNThu#!6aJOtutv51+y*n+W3zv#3z=uHfQGem{kcdMEHp+8h^p`gMiQ7&QE54r7zO1pju8VPv?Q&I9-y8b6i4# z9n8%~L=_$XL{?U|1VBHf5($ck==F=E46NXQcJF7Ii-{VEQ8Oj_ZnvQJlYuxvKvz!5 zA;GZV+rfLPvl(h8Xm)X)lmhrnmQcbo!DV6SCemqRCL6Gj9-77ab-9kN-y#CeFQpEK zKg{Iyo{09b45!)E9e!UsM*AH;7*b;HyA73EZ0L|&yA|O!Nq#ow;DYO-u&4F>!=1HV zJ$2;@9mF@ACZ~axo?a2Z{wqEPLx}0!!|XAbA2?y((@vq6!c{?qpp_bg@poxoVr}Tv zv>)MLbG@NlyLrBzk#6oREqpb-e3XdPx-Jo%k19%9f#xQ zn3!>9%Ls(q&oQ6MVDv84p6HKo0Y2*(=dOB7J|9cmpt5L%x4H zbABIxDE8aKxN)6HZM5&n)z#y?Wuj*?P4VtE>RHm|J;kduQEx_#UKc#s%E>Rk zj=DHyvI5D~7Wy(R8_d0;L8BWL0q=URX!^kZTqLakG){#2wCao7Bu1r4y|CK2FE*oD zZ(MmB^tSY{4c!abK@#2VL&cHymFic z!{erGPm^P|j!P%+MMLtd-o6j;nUwogMCMAsHwI#US1$fK?f5TWOjSOA{mK&0N}dxH z6Vn|;&~Pib$(J1D8X+T7*7g*EKv;|yfC4}@(_x{ZQ9oENvrZBo;LCG0uVA{RG##LQ{-M;!m~_8d_}SM_4rjw={8E_# zynQ;nx^^={1>7~E#j_bD;N-^vqZ?;iW4!u<7?XTIu}9~p+wsOJhG-l1MI}G15F93X z?lWuS(#bKKm&|_0ai8(ie&6xx(53a* zuCj34ffz9;YKCGuM*|63#U7F8wuJ;CF(V|uj1C%G-}r1Zem-q$Yb)aO=F_K7B{ond zPoPP0Ms>BYH9Rm7n?lebvD6VTDOKv3qm7}ickkXkGRHeTdLfl%n&^zu8&axlN>jfT zR=)>lTs_@BvB;Uk@F9A*lJPE#b1UqozUzCd6K~L>L=*ZS&qViWpT#?RDWj>rNm%*1 zCs{jj6@52yN>I9JHEJchbH7Rv=s`E=xFuBkcGhKuF(ne8-Pc@j{nPQrRen|TP@7#D z_qq%Jf_}@gXtl5Ivy!55>iuCyA8}%srjLu=UgY4(ElSso5ejgAbd*a0!l}$sMfqZcSEUw> zDY+jBxX*P_4Q!_rc|SrL2AWGYH_usJ96k#hd5Nxx7W#}Z=87whNVK0P0ztSZ14+(9 zGd$;d+FI#TecOpR(SGaoQkNJsZ) zC~0q5{>=6siWHP5JfF z3vi^1jq!ax4-r0u)?-_KIfUAXihr`~T#x!H!k>XN=SnTy=fuv+icj$a;o9_|2)a$Q zEIsFiJ|!JMw*?SNR|p6y0QOq%ZLl*%X`amvlj|B8GANQ8^DL}!hrlJ?rLkoEtXXnG zIKYytL zXT659P#&$XFO$V+pTofeb+MIVx74WUDk!}sGDA_Ak=?JPJnW=u@-;U^#=!?lM?VmBt-_2^4_i+$stqC*n88RH=$6FlEdX{&% z>9vr#It*_3wp0{trkD)OxtPyt+BNqE-o21uWT ze7D@3hxG0;%;J-yDOi+`Y&f`u($(d3p#dANiMO%67*f@@Dk}IsG^pPGwZBEE78?(i z1R98}6%N5Z2;Vz1@pTd(JpCfggx*yu$f<7FQzBfvhkb@^`m!BuUmEahFPl|3;E63= z)qTy3M@MWK5Soz^u>#xU6;YH?`bk0E@#NP_2ZV)MqyZSijz|CWvM$?aF|%qVB_)0^ zxj6kIM}1GTi+)_}w5SJH5c@CT0GA3$DED&sn&FWN6b@Ls6uh#2EPweeJi13^*Xe_f zmR%12<~NtIs#`vQ?J0dh@f!Eu7vJiZZd&t1mssw|L@+tVF2tR_?^}W zZg|EldGZ{n2AK?4A_{715rF$iTEKC3x{}$1@7Ij*=W7B80Y{d|=Uecgwh;23)(>RV z{&(25o&gTU>DN7+!^6W1WdKm&@20i(2eL!#7a$cZTVY}0FL7~z|B`hW24jnkj()u} z_e9ujLqlo+h{u%KL~q&d$DQ9v&WZSeXseTYCVv&h&Y8+~kU&R=ytNY5MX< z_JYqq5>3;{fatc^ei!%Oug(shOrX`oH%Z&quU}U>q!kqvNlPY~zIBg?dLlF_!rj4!b7Xa&tvpzcJy3mT> z=(D@K%hUqE3D$W99i~}CRFsrLIdn^8+CSa5a<>};$;h;(g18H+t99ua7#IZv#u}(4 zer@smbIX3x0RRlV931H8OD!!XpigeOVC`9=IHUraRZ*d3=rMoYs49~rzkj!JCq4jv+Ut}Hr`amQ(J$?vr1<^^ zIl=;jvzl`rGBOHZ72TTB9OM!d9H%l1|Mo|;d@=#EXQO%t#?8F=@b6f?>CtUEYx1RU zcE-J2H8@EH>zV4ZV9-85xFU%G7Jt|pU80XKH$VRlC|D)y{eg$r3UQwp)NPwjid=_J=#uH; zMBH+^UO>@hp~^+72q0v^gf0+OHvsTQLyqF2;^T4pXSxo5w)As2%|8 zZR-v+yO&<+PhyXYi|gl)j*99`D)m8JT)&^5ThTGgzL|3q{dXiC@PKp9(2#TF(`OrU zy7a3e1npbX)llq-&6)TIm9Hjwx`2p@vdDEyFRvPF;~o&7PNi`(7IS)ky(&T^3%xd1|(qEjRioZj2#>bbji7xnB=$`&t6Yf z*e7hl8{zBs^8hAYsbn%Nl9+!5<*3tltRKbR+zb^1O{sG7r9S%~g82TW@6A=rZ6iuI zL4^odNkS%3KI(Qa@S_a~jr7B!aGm z16k0Y>kft$0W95LIH~?r@KSJmnS+@ZEoKiv1N~gc)I^mJHn9MD1qiflx+lFH<|-~O zc6S@}<MC_U9J2-zg zf3K?2DNBg~QnEg%aAw<006I7B=q6WHQyi&!=>ZUTItwG3ex{(XXUE3PjhaG+6QEp^ zG0qbGe_`qVV_3JeFP)RB5{!&(Bcx@jQrrdtI~hBcQ{W0`B+L&yJ88Z%Y2PgIRvD_RqjN9M zZUUxNV6YzA=jBd#{m$RMfgXK2&c82To9a}TF6N%*<%5} zQ9$7Djo{NueFFC)Tpvn?Aced7`l3rpc!pjz0%>T^eSObAH!yPn*vP+r$Gsa^$%%=H zV*yozKUfytU7M%zPzmoKn;1#os=Gh1t#;AWzkhKcXG}KrH$>{+q{}#W=v7;n@}3Ja z`1gh|u=)Sr4rw{;ijJskfB(Su?AlMKOVyXIxuxx$u6}yyW_P}Lo_8|%9Q?wm!DqK# z!;RWBrq%Z~rk3|zJGJqWTV>YgOihcs1!>HMBKVr?20Xy#HE(nKo%`E&{H~b0XUF0@ zbIkO1y%qgEpV#%$3)u-zg@6D4W+{))j0?%2vR3VJ!#S2!uVz0Dm+tnNp1M={>Fn)K zJiL;oh=iJ)oWE`EyEg&f6k)YKwy*=X1Wezyygj?dA81L8%ykYuFnRK1V})WdH&;P@86N%K_3&_)G*w@-AQ_ zi?}`<_vzN_zmvv4FO#s8QVpjkF literal 0 HcmV?d00001 diff --git a/src/img/llvm-cov-show-01.png b/src/img/llvm-cov-show-01.png new file mode 100644 index 0000000000000000000000000000000000000000..35f04594347a398ca8321faf85fa018b192fa843 GIT binary patch literal 416748 zcma&N1ymeMw>FHs4DK*MAi)X2VFnEnG`J2B+}+(L5G)Yf-3jhakPsj^!Ciy9|C4jx zE9<}Kto8Nko~|kHs$ILDE%i}ZQ5qYA90Lvx4qH}6QUwkUwGR#sSp^LR7UPgAh6e|S zv1TbDp)4yQ0aSLfH?y=cg@cp%_$3KdEq;hNVCQ*KLOdV@O$NOkeF7cGZ~^zODi{B= zs5ts-WaQSGrl7JQC|V+s7Ll@pE3ye26qzLgV~)h+y>ezGG6nN7Dz%aOisx~L`&h~k zce|rSF7s^>cQ|0UL*F`<7IJ`moIF0>>IgJa$#B&VRWdsq%T;vSq2PmtmKK_*iPuwE z+cC<|KA!=rp4ralXM?v<14&Ns0r+@|+p^6mXpM9mM4GH|@BxAmyVyxXeFQ!vMyW`$ zfVFOP#f)_hf^^{_i!ZWi#b`7kQE*-H{FJiHa4#q%#|F0x>HK7j&=#N`;&?sQcvq_! z{K6q|O@@kQW-~~*^fqC0k?_DtfEnZSkomsB!%LP2XZ{k5%u;KWlMe9`{^0m?f4hUo5(qnteXn+N;RU?q@WSK5~UvQbN-I*h1MJTA#@rMec?PKltc1*o?dn09ILfNPtM5it0&XhK527~ zOk51El2OovLg-?YH^)ejJ;wSjHK#I}9#z}L8$MLX1Bi-?Gv36D81$u{GDWFw_HW$Z zjm$~1{Qkye|CZHJD!C^!3orYpTrEA3wdvqmx;91OTranx@*HL1Pky^R{$?zS#aF8Ip6Y5W5fRNxp0MSIq1<-g9za}_27IhOfR1{BHI030ZoK6O(B7|2o zRQa_U&SAJ!c2-XOPk~*GDfFfAyKLHB>r&_UxvM+|wL%RHX2tN4ko5N{T57<$1X#&W z{Ha)8y+Ol_e%WdYD?uhWnOPxm9dM=a<_~6Rfko}RD`N#l-|C_E&;2tyCT-7dc_Hf z_D;xK+USs1#JYvdh*7-PRCQO5d2dh&$??-^Pm0b>`}ykv>rUhDwHM#xIctV?x%Pv0 zn%VSN3+N!Y-v*llyF)5aDp)G1-&`TAFw3mPEY2)`+nB8`F;t^zhO44ohonBteA29S zWP6l7+1KU@(N=3gTu9tI)a}ca>*0GU{R}v&>QVNLbHUyg7k!Q;?j`)CH!TugY9L%t z4&>vqb~_1{D@tTs_bX#P!%w@`2dMkQm)8gGyD?MFSBg-)g=$l-BOo z7V3s;RW;hx`0>nI*!3*tHXk~7{^FlEnNwR3u2ZkYuF)Af z+28T&sXn*>amA>r7bIP};WH2wZ5wTnk)H8F@lsJ@RBBXqv^B#!ncIxi`OSF^X8*SZ z)2LylB&ABlO0HSsO8+M9=7QGg7VObC83S3GpsJOnu8fV2mG;@-wYbgGJn5>Uj+XI|A!2>cPB z)t&{PCa=WM-aMFe=jbe}lP%AK60P+~oSnRld`!OXkQ^mzz3AuRhZg5V1Eimc~Gw$u}Vd=?wJ115C$s#6Siv44Gln>1oRXxwX zQJr?3a0^=)emtov!8z>=Uju&wpPk)eX_NJ-&S}rhHj@? z9YUSS&%)n81^lL*(;!#x{n##5WoA<1JG9}@s!4>&s{&scTm_M2a3)^bc?V6=Y-9U`x)JB!+U4|@0>Rhji0spY^-kU2nhNetyV|vZJ{6jd_CH_zp1ME41?Z zvaAy6vDGoLvOUzKwBGLHHi#rVa&|D7$_;1~Rd_cVHGXVxCGjMtV%A_AWjk5{`+FOs z=jCT_E=4m4RVD}~94*K$GOhg5C03bf8@8Bj&^P#wyroaHOoZK9?`}W;XoPD&cGwQ_ zKDgfd&9ZoXE4>zTeTDklzMQ*+wW3GER1;JdU1InA@m6&Nz5+26wS$_F>NkkcaaTOb zSwW$~?Qll0NfE;5!hd>FLEj;rdQh={&G(Z6BPJ;CERVxa@viw^>!iA2%(_YFkznm0xu>Mj#@hKYh+C)6e#F6-c+C{ev`PVe>$W40 z$3E-ssD>fZlPGtqoke!r;%*L^$({|@Q_WPsyN@V?vrSYX}FMMyWTqisBWfaH4Ntv0$$Qx?`|VDi3&G3Gqw~YoC+@SoUO&6%;gy0;f3iVu zDL;)ny<^Xj?4{Kb+UFcy4&n|{4<~oQL_kN!j*c#L3Q9o2eIMY zzRA`0ub3{3|%bzv2<#;KD88kp7cL5%&Ib#loIH zW&VC6ehz~}h5f^aJs#Nz|CJlHFB|c{!pJb>4F@NtDj_Qid#f5dnVQ-;TiCli#R5OT zBG4UVw4LGLh#CGo@Uki|PGI%VS*mHdXer1G8r$2l8=2UDFlG0!b@)>coUn%=ENE-$ zVg&TCwXt&+^Z?QQl|v8~{u9kX2mC9Gi#3Q&OFr-(OI~-I0$lZxVyWvyT4(#cQWUAEg&Gk!O6wJ#l;58!RG8~=VIi+X6H=* zcP0N-kEE%yv6H2Pi>19C@K3!)AM9OSKy-9}8v5_+?|zzkSpH8-cFzC#EZ7Hf{7K<> z&Cbd3-*v-^3jc`}RJQamwb7Eaw1tfstPSvM0e*hrzY6@Hr2lF1@1p9?rcM&}wy=^e z;Qtx*{}le;iU0qCf3>OozuJ7m%k{t8{9j4`DJsnI=iC3+So}TEf5pN^8jK;#@!zus z#%Rbwm4i(rrKO~j8te@tvp*L?3GC<9-)~qLkv#3gJ&7Y6oG6^Eq?noq{O=6Z1j28` zVVIImQZ=80fd~jebngI?YJ_;muLJIW+=7T|NdeBpMDnE2AcQ+fy!WEA7@rwl4hhJF zUGH-gUn$yO%a7TN9sNFAadsf`U(_ z`u9`wOZN#;@di1D5cLkx%pd#sjdK6#4Vj|h#`2@p=@rPVl_zpr^V>OPmNJc*&3wrf zwV=(i=E<`7upg4gr(U7LvghTZC$NLe)?kj>CEabWbuwEV9D3|O-lA9tObk#yDzL(1 zgJbyKS$=d;Sr`N6z^>nw&ck#Kw$%zPi~9YsZe_Z_l&Si=TTKVH?(pZS@yrzNjFhgwZVBX=V-4FQZ8d&H|XSKy`GNd&f%h zCX0-{<()e+k7hsOerr-ajnm1GW;|G|x^Awu9%+V;gfF{{DUaa4uN+Ieo}9#8FFx{R zQP^$RME$A%AMad1Hjo-wQHs51r(5_q3cGD6n+AW4$nUI6*6MbYKGWd{TN&U^@DbE$ zx&nW>o4`=`0sBzfLum=4TJr-o{$MUrg#S(ad;#b#mkecZ(RE*Te>_ZGt$Ty)7d<%( zyBs#cY;;B$3LBUXYOG9}8G1Ueb9kt8`UYeD)G7W_M7K%fvBj>H=}xIVqSPwR$H}o! z$$Z*4z4Vxguxi$O zqN>~HD=VP_{@ylnQuybJ#b!-)ij&9^{Sswx{a5SB0P7lZbQ2JQ7?NYFrst)vsp8HX z^-yt7TReYRAOpHGKq;zs!t{p?kIx>;WD4z0Mya404)r4={S~kbW4+`qQ(R1#epJUU z_@9SWrYlnP9s0WQ(|j(m?Sk!{=iB;;{gAegTNfAe<7yo7LHr>HNu%X!3tJnPXB5^+ z*ZS-vi#(2jUhYQ*g}c8Pr>A@`S-yWuR}2s>^|Mek)NH~)?|T76cJv5bP$NDe&+5Fi z=TY|lWw-3zWm)uu9y*mUOwN))mnen6Bo`3mVMR%fu|6b#1MBG7e)$)xT`3R^AG>6^Ia zwU*rrbrEiw;en9*Oko5Sz;mfS$W<(qfR4A}_@@!_`-3#1wDdD0+k?`pFYg4;(}96% z^sqVOiAF;{-K0eAD0&gjqRa3vjApO}=`%aD*V$oaTffxwR)+R!b?upHlmDV7UBIdD zkm_l+vfb(`v2(hH%6lpr5mo)ygQuDR70$ztiMI$lbxZy?UsKB#k~ygbjFWS-dAbc(USv2tcLto8?!dkw#V;pown3?B8WLZfabct;?9w1J?RZFQKlVh z+G^-tQLF7}zRD>j1b;Sni5guK)JfX#v4T_~~G$=GO#SqPOck~;tu8$s5 z9{9Yy_oorge*&kHkPBp0>nG4A9eh#{Qls*%%*?6E0NUoXU*3^!2oAVH_udJb@XpP= z`n(ddFP)(k_BdB@4;R0)RfjF)vLG}qMw}kA6Tgx5zuu@Id|KOZZCY-jL@w9 zmTLLw;&UkCwRGnFu>0ZrB0?4m7`MLb!0+ps&ytL(ZjJevXn1JiPzY@(cAv@ zYB*OR+)+vF9?kRd;O=mH3GTX%@eX$^#RKUS@$NS0I*92Gf;2YcJWRs3BW)Hk*?*2U zKz+>YdRbfczN80ZOhZrC1E&XIieft9U|&Csx$E8G-CWVCx)T0ev>>S1_#W7QE|Yof z;kVY(eNH&(7iQjhh`PUcG3j%;@qaoFtJ1rj>SAsd)Z$4@y>2wqTewF z{|rB0JL`Pw%l(b?`eQzR^TS){Jk9UN?F}!MrFxc&{C;RDHG$Z# z`)zU`XlQm=D~ zwWTC_QM6D2N_tz(5~?3OsV80rr2lw+nD;L59^mk-?ww` zKsq_(dQoY7*8;s1e|?b37W7=LG6S7FEBI3;(u^Aj*S3h$v`~%2*fH<>AM;ifREjjG zXYh0aq`mhyB4dtfu(i=`eLej^t}VnQi@YYMUapsO0!Qn`=lnBy9D;0CR7~8tALwoe z??-hjj*?Hz``m&yjeJeMf4E$yVfo=T#$8g{upfxRF(%B#LD8z^ee1W}5`8?dy<^6z znZ>SEM!XlZ;pdhCrUnT9Hbm|8;(Ov&x}3G`zN;^;(Akffw(U%*OxzVCuxpi!WRw^y zJ7Cuk*%KpnSJcWTwz(G?;UW}$)goI&;c-}=nmKH{w&1K$a{rR;OxS=^%P=3TWQ>i0 zZtVZ_&vIKLxlh}@Wt=@f12i7;-8-drTpx1QlBf%cVcYADv8(L0qhy3#NakJ>{z5^D z%A8Cr1`B3{tblS#iM>!7OROcOn=8}%;bIk6#wI@O#feEfkrf(%%EDUOM`e%Jp|_IP z15(dj?c0h}-#ap>Um>?zHuf-QKYErGc6nEvfPzEmfV^^ovq8wmXjw z?eFj`OaZBmXm~|eHU!n#4lB*JMIM}^TDEp>EfbASrVTUBTb^Qv%(Oj00Uv%%k4#Kq zmca!rRct(~(HuO<^nwnn!_@qo9xf8cpel4<)ia_n2jN*PYLD$U`Y^0Aq)@vY^Z_`4BqgcF#X5Gvo{d zL=A(tBfb~yGfV)2dwa0vkAe(Ik4x%10W67@taC-?9KqVI=+!q+U2_PhSXqv%*$wLtj8^@m zId2mdTKl!+wRs#JYkbh^e>!ec{>1Z=rp2`W)cQO$ZLkz#|HX}aQtR$wRQ6ZHf{ zt)`*rF0E{uvyz1enPqLxS@O5Gj*?zhbqwM6=+K zJ1|#i@4qy_{AYPYGC~`v1@xl~yhC&+x!z7GC2`lJY5dRPSU_n@(zP}+$pssH_=W2A zHCET7<^ao}r5h{ZlwiuX9g}6h8{X@yf{x{hOcZQQV63|d0lvq^llTM73F{BR`dvnDonK@2zsW`U z?13(r>j01&K@J}}yIjvkx2OyeanA1%!qHk*ja*ztr~_q}o|VV`MpM*qN3WZl=ZT;flWQt02J zaOdx1!W6!>xGOwN;t_dgLf(3dl2j|C8u;`L_{lnZAJen4hyyiejK1R)Uc!$o;fQyg zhBobzu&YLZ=E8_*SFx8$te6N=DQKth-osHZ!lps^u4@(N@X@+4>MC<~;6XfN@@Af9 zhaZxon&4uy%xTWJ_j2uk}uSS=!+U zAtda;?O2uXQ<`~Vo>EqNnwu!Rc<3;1dVgPt?hQJ#as;Drd-w)XpRG43CH%2v2*ab( zFO*R0Uh>hMmlwAiysfx{3Ne>>6GQ`U@mHe{Vk@`~M++_pe!(0zX)2-(JLrjP8zMaj z5?W$SlYa9o)Hy0k?+MAVGCl~$RpV4v?Ti)MiKlPOi(5Q>yz}ytSm6NRz{WqxS5$~^ zin*%MU_PWEGjHti-cNtmgHK#5d^SC6r`3if?y>vI$OtXLVt|@OzBee--U%ckMv3VD z-A8yC5B0SSO0a2p!8Li^;VR#_cZ4k>q^8MSH`oKMx*;E&iI(ayg8nL zYz%HtvrN_L;ZDM^o)OymUUO01Y>D^@RPexuJI1FGCpi8 zc{e~R?@(2b64)HR9eBa1)!?vTxAEm+ucy9L^~;1Ml4Bc5=wl`wvSXX^1_bexG%j@i zfO9MSqIKKlF>}ekn|xX)3lS2;zkJ|!@T41$NVjncXgn~eTzT`=_rmyV^hv<|mwNCW z=+xjYg$^v#zsmsVN86eQR;nQGHaD!4+-Li)py@%l`m%N#DRoI>2MxI*ABzgvHd@xDfnG_y&Y6Ue_gvSIR z&Zn22RC7aRr8+G*460&RkK8sJ}R9r`R0; zdVv@;+#}eS0hx%2+b5eI0JLGnqT%I(%r45~PA;cvMyJ>oW(l{K_Jq4ypVxKqC`D2v z?K_VvQ3eg9QPsiG?lFK)y2dp2DL1E4DDisn(VguUzKGL*55h=r^L=1shREVN)@=}T zz7Mme*h4eCA;pdYmy1MK%p5z1nxJRi0I{^p4g0DO4Yt%b!cc8oLF#T+z1@K zuF+_lFNq$^9X?gKR}<^mHd!pvlp{ zcVC#JMxv8!?`mg;hB|f(-8U|oDdV1AEUN-3XUK$y>}DjLL@N!g0fRcxHzRmP@1yGg zfcbn`4&}Bn;Ci5s8Er(Lr*wNsb*7KvklTb%l(C)$nwLkzS_eILi3AF}&JH1i9Kann z@!X5XO96MPD_elnqoQT|ckx+TM(aJ!M%gl}@hodM~rVJW5YZvvGmy~4csF3xQ0 zOlp3z+b|PiCP^usQq;5NtVrp^r*je54#fn`Gu1;is4uIERnnUm1jX*gj0hpNCw+e< z1w$U!2VeKvT`b%z`Sx5;c%$GZ4j&vG5u4|*vRfZ5bjTLNciaTttY=2wAD7(u8RfAU zZb^z4PD%(P2$}!0LJ6kx>0^M>PqB*Qc7UzF5Rhvg5eYNWa;_r!G$V;O^s_*-ZibMg z6QUTQ!{G0hWFPQp?D$;lkC?Pvel{boZ6R2fg<5QmCc?1FW~&rfyb&Z~++z3$SRzu2~g`-JsvOQdQUG_3c_3$<@8d z{94e+$3iMi#iGy03}YQa<4jAP^ssBbv*;X|zUvGqd%ddp@=T&mjLZ(6Y?iFD5f}z9 zNaSj#V_gllSnxX2#9%$al2$|Dhz~Y#s8~mAO)4<=H}U?%**V6~6)I6NnQ|9Ty4;hmm2dfg0iz=7vxFwS65r zCNq?#gzC}1&Km>eboCY~nB-t;n7qjHM+T&u4cdx22h^)0oVE=%$I9B5WRy(=vR7dW z-#6;5^k6C1_;wxZP}S$J7d!Z2%i{B! zfRTfiF0Zk@>+=EEI&ACeWtvS3hZ z6^~)2El@kVZ9A|NM%OC8D^%OEua+xmWL`A*?iHN#fIYbl=$-s=K~v z@j*AW^WIzF!*A=ndu$$oIH%Z-eYPAA)q1WaI*d_`Y;7uQflLxw^e_0^YCoiy5Gs7C zJM8kl`kfb4d(qV}d{}jF%mto6J@uo^X^)&&hq5`n6WhW#w7mN@{&jOA@;djOAfNpL zJ>}Mb0f)W$g8c(s{wed}W3yBw+WhS(sc>aEAGg!w=#fu<95VIuRzuq;YK*#YB+%tI z*keu`W!Wyq#5`vViC=rnO?S(Niv8Dc*);n=)de7Yc2<%K)HR%c{l#Dowl@ir%~}|F zg+_-2ocGR42-a~TVUdcL-o53E{UBFvY`DJApfgr6!u;bILyrWXzuv4g!8HYMiE7D;5!07eKlpF6i5pm{+ZYNs5DIUh;CHoBjjN&&;N!dTDm7+25<@iae7y=3@l%8_Q=Y z#LeY9l`EI=%a7d+i@Xxj3tghfHWXvHmUBDTx>FiWRbJYpI~0}Aaq}DM85 zWj8Z}tS51PdZ@1;0^<6HIp+qX8XYm$xe|CYtvxzCQz(UFS;h1^iVQh>4XJ4Rhd1xz zlTKd3H&fFYtJvO>nP`8O9 z#v3BjYg}ES4#~5qe78BC*-u*7jCS!fsbkZR_cI&4nch^_ZG9EP1jemre1s{UX`Tfq?{ zn0bFrvx$%Wl@bvHh~JD%SNr*fL~avjL!x$0uTcJ-*u(dIQ^K=o@05%5v-1vcV_l$kE=af0WyIuhT>HhJq5gY~Za zthK&~e?lX_v|uMw#rkKJ)yL>^gh*bvqBt<>Z_qFsbXd$`9A)RB`1}X`H#Ao5pr*DM zVGkXKOSO$sGw&n+*{HNKutC!(;Y&F{IEi4}xY3GrmFK4CH5Zu}=N8bAvJlXgku(*s5JqGfA{ z9PgI=j-P#bO8*=G>!^x!r|Yf}eZGbZAJi_)Cno%UjAg;CZiT9a<|Wkcp}4SpI@R9JkX@su z`sQ1jLg%K&>%lelZ`9WV?-rtGs|Y(xwTwd$`rV9XEsmKy-gh_r7Rvr3!N|9^KjNtn zK#os%u|5C>0H2q~dTxIHo^_M@A}7`@CtUp~YNv?R7tky*6ufP^GNNX{aozd!BVwHf zh1swxC`op0$CB;t;^(@OFiH-}Y#mYW;=%eu@IXe=4*yJGY$6nfs|kK(N#1?_1e0cQ zj0*SPpFZ;+wm_{5QZq%gi#+(>O7ET2a#nRq9y8V0bB$HAHcpZfBAyl$5a%tNCnd5p0s}`vN31Ppcgv=lBiHQ!nv$3fopK=~CIc00q6~8)krM@}Vu;tZS3~C~D zImHR2JcTeyxWj0|9^}*#pSx{J<@cbNb+Uo0r2Shm?zE*S{4|s9o4n-vZbNtu2}K9A zCC<&>%&K#vdu_TP4;YqXrZOHz$$7wA>$3kzjdUhWp}~u&^IOob^FNy?P`$Hb(8&|$ zTf78iToNE~X!rri(bKoz>p9^u7kKnG#q?jKl1p?X;yzm5cCdB95C?NFEh0Rao7P4! zM9xQ8acZ5Y@6ZiEO+@p!Rxz zr;X|Dc2xQ4#xbz=QgO;3dT`vsV|8}-ww1tGKk>Q1xMus7iSHT1m&pgQZ65By@1w<_ zO)ms-0G^0FUDmKM;CrbDLKoa9UK2g?&mf)p&z5Cp3iU4NUeL2aSA5g}A`-YAq*bU! zTHX@U7EMZ$7NRC7`HICV{GH5SI2tFCGO8<$xA}tgRi$MG=hD43VJ8cAig6K7fL*s8<})tvleujSQSUaeR#5)l^-#&GA)9duv#-< zd(?K0v|1+WzUG;*O*M)@D2yQ9_G)XU=P0so!`KetYiMSmn1o*<6iEG-sH;`eeZS;= z{-k2S`YSt@u75Zd1umFBPkS!tMg=5uA_;f`;gt?9Ks@{@M5U09NU$U9#&g&Ozt{k#PJdn7|Z@6JBuXVZGX5ic3|Qj4Iky%Kv^ zS_;cyHa_QLUg+7E%OH&PN0;agJD%ZryB8Oj_NpN;PlXS8UJ6A%u{jnZGqmfi`^u*? zivokaH#Z!|97exm4y~o0-vz$L6BGVz%{lJp(zF&nJ@Cm%n^XZQC_aEJ* zba@0Cc@w)KOaxZ$*{kNfGG97+#0b{Bv!b=VT#**n83yw(Yilj3U%$v0&8rh!j#i5! zQZdn4X2EYSN*DB~IsYBw*1=0E_zjP8DTsd*KHo6lErH8xQrsRv*iPZWmr=F6o#S6D z#sGrr6*9TI6hy{yn(1v5?&F{WO@1s4*84%)waLq5;*E_IOWo^tENG!xSSu?vc=7j^ zakOE$b4>#-caF55UBB_V%<1SbO-R!kEB=anYO2ZiW~b>;H@8#8Bbre;?@{v-xJVsO zoTBj7Tl)GOfXZPrmTHhn>%cx|pI*@)yN83W_%E&&S9E|zAiKMN)YA!$QX)*l9RWzQ z$v|PiEJ?G@Dy}Tn5TxsC(m#5_mH;H#!fa9EpPkN!6S_f0I}?;6iPaJlp(%nDX(Z2zQY*Qg?H+@iT4F zo|RzT?=8pe-H_G$dKOdB>-gc)n%l{Ur_r#BkPF5>SHWguF4; zCOmHZ`^YBARY5*nTqz572%O zKn?#aI1)>RwUcxW>A3!op+&t;Dr&jHpe$lvnZ6AUhQ9tc-=@GRhFEs7#Uo;{iGQP2 zq?h&8JLDLq#&2ib4VS&deOstX(0YJvfvo+jgw{}8T}_N-h*95`lSoxbmMhLIZ(d;< zV>_68!S?O_7l>vt$w3~~ejf{zUhid3jqd$+&m^I6+ae>#9oY8!XHZ}g1M^h~19YXT zJrb}_v%RAq9y>||&R7k}jbVTugFR%39#>yZn$`L85#>I_i_@2i^+6mJYF}CB>rZJ$ z;<#I!is|?tK4RG)S-|uSQ@WMyo!^^Yn!SlE$Dw2-gYKQG5>XK+qt+r4)fONSj z4B#KioqlJ@s=de#xqi|1YSI`+%^#_a-B$=eE1O>9!gfmwwdY0#e*sqipoj0fB!m8+ zga>B;o=A|vnL@~n*0e}YY(~^Q-}qykz}GFQv_z)dZz&l2>+cv8S^&+ggD#{yX>I-s zwh;BaPj|&zOm4g*_FC730&scJqt+t&(j1Oy7r*XM|oeD!89TK=P-@ugf7qt=XbS~`joLCN&Uj6Q1Yxd#)LT#AHKW+C+R61 zC+&#$+L>PCMVhytwjqjoZU)I%IrS?Mx4)qYpG2ppz}yBlXmFJnG}kq@`NVLS`I!pI z@z(F?auHSJw!Gh`-2FgNaQ~+am9NY^GnH(9ozfklcFg2I!xB-16lox#n4X(|`{*|e zJgoKj5!b`(HMPoc%iGtyI!8*a%ailgrL|YdrSG{r*&=Ry_hN|l*O(#|QZ#8!;Hhci zDy|2y=dCZOl4f_6bOyo4#j#OgZNl=KsEv}yjy|!ib?=y_D|^s0Gc9fc{D&I-`7;~* zXzu9Yc2i)erJO^gC1{~fPATT(Ny-E+B(`z!sLJ5|rIpG^yXBj#;yHTcFBc*5(qPN4 zp|s{l!WqMaxj{T07*D#A_@bVyVwA4=hF2BDier~(B9UI>@)%LYNhv}6;vy1+cj2E@ zCakGxreL~My{+-i856KK#~66iRK)m3Z2*(t0H)tFC>tA6BB|ghA&+h79v*%63cGW> zjDr_)KM+0x7~~JZbH952YHI81ihca`kavvbEY6^?N|z&^=GPj*ZC&5Qey4gA_gYw|7T8`#f%yv@>z!?A*sIfU zXytJ#e;dYMqVWXNi`+&Dst?)f0Ojm6S73HE&*z4FN;!aZI}Gdk@6|D>gP*_IY5XzX zhoW)L01122bi6!TU<>8T_-oE$+%d65)QV<$^cQk~fq;CK`Qd3C`JP(hF+Ix(dJ33{ zpy|h0v>F^K5<^z#%D&ngkAbf+Tk3H7UNPU-krK-zf2I9mp>~%GD$;p_$wNwYwX7^Z z#(U(^NtaaOTgo$Cj{lh5@QzdY-SOTJfmY#%-FJ&I)h|75S6Zd?l@01aB}l}#I$kTP zHNilzth9nfWtF>iR=Rh@zRF=1e6YvMu68wYWJlTHf1$)!U$hW*s4h2vd|(e(;lygW zq*weo8#!2uxC&?|a@8$_dmCVFX_PDfw8-f5yHPMd2Rkj|5L_lgM~|Abun3tYu@EDt zEjp)kPfyJi$)_!E;juwo4zRWxj?J%v)e7`r z60O#FMdgE9l5AFt&s2>$;r7?>=6sD=7DAyb zlGmu$K*`1?)o>(x&72VPkT57Va{7?Gm~grGyPemy(@AoC{NA5ja24uy9yF-nx88!3 zajr2fVbplv7OEBL4y9|3nH~FNt4Qs+pjduw-ZXb{PTITewZRp&H8wj0PG!ol> zO|J+BJYsk9I~_}rIW-ulH0L*iFHMcH5DLAsRsUk98?!Di(okI_DHi1_OSCmI)C*yL zX{g?IzucAAe2MX*zK(HDiS^MhYUXOgs2WBC8;g`R9=@qZw6pCzSc36k@b3Io&eYf- zc6vO9&k~CbQGuS5d{5^O1FfTb1rf!~y6ysFPP!zWgnbOyit+#KZhJ)=%Pl61Ckey) z)eXqB_aui)$c{g3Z!Fx0{LRV7f3(YwN)%JO%Ss@R*))bSL0cEDQjZtf5{VCoJ=xx= z!i1D)sns=Pr7A7PUJLJO1-0LCG^LaD&^)D>gT>XcJ<7FlEQFvD9%`6DdQ}~!XX#M5 zL$`DaRm1CZv|E73squGfc|X*{$Q868M?BCFL9A82lUu>zzxKsI3|G7>8%IkDZQbb} zG6`^iICzFHcmdi^yCD&lZYi@I$c`M$mcu=5f6*00TWoRk{&C$0rlAnu@LM${b(mJi ztZK!fJkz0kpNJ(!89X`x9;f3?`za4o8)#auKo?(U%N zhtFlBPDjl!&>+L~)2h!URQVnfwkyAJDauDN9TC(-!jSmS4gsPwFJlW}MiGqA*&k;a z-oh~p+1gz8zHmODn+9tC8tNVuztUdW`_RXP=5YUsTu;@*UmFct0)6%q z%>tcTHOsf6#}JzH6Dv=p$hFguzAr&H$AW}=CG*2<#k2_~JIChU5d{E2>AEs=Ve`ED zm*2`fgtH5Peo0pWJ|&jewJENx*J(a0$zsq|m@42`f&}NQoOAu&RfVvx$uqGVPp(uY zT?aSfSYiD0D&9@gqz;m+Vd3+7R63wUF&9ty$U}lUz6-&_W`CY!O{Q^5XAH%-xF8QaI`7Ja_xOK~C zy>EenrT5Fy{4#eujGB8%hQH)XyOswMJAvdkgeBPLk6q>rhSX+)4MSz{s?W-dsX`?B zc`QX@hut`%8XPid!>!*^33Ly`)Z8`gFz+rK#7USprPHdEGHrkR;oo|q2Bj=EJ?l23 zf`M#(Gk?6(HOs?Cngd9yy0`tZpkD_$dt00>#mzU@U>6JvrLes(t`n^yH5HtNz5FY{ zR1KOFr8%by7MVepDa?b+AoHGrl~EUzjci-eWlZqI+5z5Hx7Qn7YhBIyS%KMhtYgyI zJ@53k&OBsuqJX6!rwzc8Wi6{Bd%pX9$ww`qc!qQoj zW596xB6SrG>8&ms8{J{gy^E2OvVB7;|P7U+(cvF*eX2mH4yV z&Y)EBV>WRZaM^s+V7ocm7F_DQECO>j-Pv~T>0yXHdFCb}CeLvs)Sj+*9aOZ!2bMA3o!#(G?P_UZe5*E8%p^M)At!I@ zv*GdXw79Ww0?a9~f^HB6Ux2|q&y{1on==*qZ2?xrpx$7J2x(V<@;$#jUL3qX1dog> zh^McKLCB2)w;zOxOVLd(kXN<`vn6>=(b==KaXH#|51d8Zb*QK}hPt5C-Js`B@IW^{ zI*h>1NR+kvT$inTM)Ng)bIc^1GB(n(uIQXeC2;K(<*J3neUK;vVmJKwT1z=@`W9*D*GLCZfAN9b{&P=8xH@B)!knK%ZJIq23t zBYXU}>t5g#C5!vvo9jY7K_3qyU!T&wIvk%P531XnVH*=PETq6SVfLTL(r=;y8BPF2 z|ID}G&`m@TnCPK26EyIVz9%u^{S6d4$uVuea0RZRNL*O~Nx;n8_7Av!o0IWr0WrW# znR~r(q#BmMYC&>*6`F3qzQ5Bz|1Vd~W`lp0C>-PoWXQxGGMfEMV8=o@Q4t{&x|Q~h z@-(DJ!ssvJ;gC;FCQKJ#We2zd?F9Soh^d+xK{Gl`apJrD`J(Rm@sFlGBf061dC_8>H@Z5EY+O0Z0B5rN8J!~t%jn${#5q?3eb z&{c1h7?M`60^+ocD|ycHB2qtoQ;G~pBHDQQ_4&l8{(g1sMw8HbRiW|g6@C#z5}bIU zh>&lJxJ#)%D$ZLQEXdkUhMIW$a(N;1cVoQnus8oqV6jVo#wv3O=;Z%DZV$j(G*Q3j z`{KEz`zA_Ctz>P~palg>1VA4ioo@_vol3oo-zo|)9! zuYkXB7=Wjn95)D$*;vPVBb6tM$fyepJ+_BdB#abh%^dsf&c%E+71BQ^smXPc1M#GP1 z8!yibz0P*q)pjFz8?p^5o~;(Nc!Ez61DP>s6~;SV$%rPc@edxL5Rt5O z8;(D(O*b}{_UstdtQXWKdrB1hp1SW9yB}^%R&?xDdhRV*orhC!dGRR0<@ZzWdgmkx zT6+xza7<^ZGtE~o>NjV_1Xd9zU`Oyjob6Ya*3M9jbTL2;N7%0qv&cJB57m-H_6w+8I8&_E z-U~S!oX1^<=l5DVNFrjQ>ZtEY9u? zI*|m|D~PIiAX*YLO4{H)c*S^kEEhj(<8zXO#?kesX#BP`_#`gO?DDI(sQxaR$b^!0=m59v zyBYn{yl=0jB|Bv<22VkOhXWu9}`QTeVp=KX2`mYl&wEM z81Jt8fLuun8%W@{_|A+v8fo)XzT329b{yQAWoz0h?uH zV>=dza_udTbixCXJM+o%CoXz1AGT z;F%sojk61Tn?4)>Bf1!V?D3&yqohk~wk2dRT_IxNovyL14&fZ!0Whcj`-8fx#SmnVv*^ZQx5rXFRWCXZ=N*8uD#{Nux2yF5k4i z7*&_#=oP0|^VAQ?js{%A8vv0d`70DH;j#5>DOc-Dx|4}J-LD7pV?^d7JrrCz*^6EA zTpLP>0+!?_Ac@@T8LUTq9`{X>@F<`W3XxT>Qio|ME7Faa`|};)_8{orTwfcd&YWewBuRn5VYoc0{@{3(TbsK)- z1=v<^M)irF$xv6E&E~W2s~cRn=;oig$-KsFry&+EAp(5Kf>l|Ck85=nzr9g<$EEwg z3^wK5&agcAic`)oyAhK-$mvC;os420ux8JC$&u63v+SUmD(=Zja>x$-sj>vwOOz7- z37sr`N;#BzcbAT-JC;`*upR6n6rcDb>1V8yopISB_qV4_>W`O_tZ1j6Mc+Lb>1BDt4%p4Xx15^E0kRye z)i0ZAFE0)o`PZp66k!x0La5SI|BGtcyIz3(Dk0i(uENdHE#!&#@f-b;Z1C>k#GB8O z2F=IIsf8(?ONlnx-!t(^D64u}}iy#YWAp#Dl-Y_Lb z&zr3-Ced_vy5--!uvxRDmVXf-t9*m`c6~dZ{p?hzH~q$J7?a3cg|Eo_mW)d%>-@#( z_MO8g`ccZa@(r35P1yc53!wb90)N&yuHfv&)99~`jps|F-9OXh2KRcT9pm5xs#y;{ zNUneL)6RYLdwu_&0bX)nXF&;%s)FQ}Cs;)-K z@Ak1z0$jf-LSws9d=K@cMai=_|EBPS**|Oug7m6Jbv;IG8wg0%;*a6SrD1UH= zm##^^(7*a9JbHB(8sEY>cDa^YIPj7^1$EDYw{9npMN3Y!dVk1pGaWUJbDc8b;bg_n zZI=4S4*r}dL(!hR>k9nwc^aYeDMf+hx#b`4?UQmaUX_*|HM<4o~hT~ zZwsVVx}Ke6F;`k*&h^NoY#325ZA;jB(R7}^;Qp9hp#r^P@S5-8q=(ulNIP4>>e1Pm z)}PgqDB*FJ3!MsE1&+)ASXrx37*UUE(y(#3#_8d+^ za1BeK<)sB}S`G<ShKmiXEH0#Gh1IY0Wqg?vqh6}RS3#PKU~Og7PtuNE{zrS62g=bl#cn0l+`1- zgkO!97vuDWvO%~s>PXM+;{ASapPy0WX!}~~-~9!TCCCsADL;mS=(|A2+HgTd4!(9Y zbfFJ8=PSKarF>OwT&n43yGZn#?16?*%)lkdA}PLAYWj-fCWt0sv|=uqVpN}CJb24y zzLIz`p`Y}M&Drwq9$bh2G#iNrG5s@s?Nq6?I@xiXR^R20ao}dqjqY*~D@J()8fiFD z7O9&rqG69{n8iD3{+#l!l6Jtb^o^lPRfcqa^h^uz@YV&T6i{iczZZlqBtZ-#k^=*$!4KSqv-&#r#+Zh=?)=UA; zp!N+~AwG#~yE~u=6bs)KG%aq=w`^vP_G2ViAuf6Rfa*eqWPbsBTxPm~ zFPiNGU#01F<>_P7MRB*xu9%eEU|gN7_3*&$m;m>LZQHw~vg_d9ALe6VU^C1ZOWyz* zhIe?oa>D$8hUo*7*9zSF5_DqSu^)RPxt5HJ#+KTczg87*iWO~w^wF1FF*@a+h+~jM z{`C1-Vb0Mx$y5%yIDraqC)R065WJQQF0X;z&RXuH48>s6zA{@)!4(8Slm@D7-RoQf zdYIl)@*5fhs$JuJstVQ1pP$v}-jvdg2V{q%aQPrUzZz@^EY9Q-_9eEeS_cq3wqh?j z>YsXnt+!(_5hR>ypdQfrD0B4?AUYLbq->!Mo)eM0?sd3jAAY%C=r7iD3s|AMEli5k ziv)WlH9Z$MA8d;h`Q^>eQ=(_hOfr>YQEE(5J|ptai+fshO?1zuQfS=&Yh=c&$!*s1m*)bJ#8jb)G}(QI^-=5K+DHJZ5+QgMlKP-W5x<4ZZ+oiV z>SIg1iQg*Wua+5V$>F*BxM!)y{~FKoKf<_gH)AY8-^3>cQ5|Ho?10QjHz?}F^MLv9 zj^oq@N=$?}t3M&-1>X&ln~qa;C3>^hq$M+VWNC4U-B2u_RN_VUY_8ABTZ)=;H{rQ) z#=P%jyyQT6%iyOe6F^1%+oG9LALjOrJMPRhvn`b9%I#nUCz#zZr$O9h;pJ{wZFM4w z=hE%|jWZi;)^}}~{OBwLwskG^D?S<66vPROhk&YAeP_&tM&`jUqBw?TUy^-zky#Oh zaJ=;{C8kVN!WP0Q@OLrX^+L&UmrZR^uRNcRyi;QkeU}So7i535r+bI+r*=t6pUsAE z;%2HQo{R4Y4h5-Q9tJ)3x*a=@=^4THKVFQ#TMKWkt!@2WtE;RaYovJSbU1uB+JijF z_=@oa^~{2Z_eB>9qM7x;jhVB<^~N?SN@&jVwKfn4f!FNd>NY=W=qEsYLhwy{h6@Z~ z_oqKHR%9I|;IllG5gjGi&1mu z%3G_wWkmK4=}5-QtP%!-xz~!wewy2;jAac;r3Mp7gw9R5sue(hBr%+A)ov%(&B}h2 zBAA=~K=*7Fa+MRM5?~m|f>*{+7f?pFvk?lvDTa_%Y5m39aD;%zm#Zql*GE?MmVJQ= z<-Jwi{>|;8PlfjjOz@8D)(a6QnQCG#~r!4?c)BLFpo2$nETqHWs@S8rPG%C>S~x z1DyScg2!mYcGxixumy>~-&u#kc)l_ub3sF#8f4^Uh|Il-h#ADS?p~hlS>c_x@Yf!u z1Xd+Mmitv?2&M%VD#kkav02)eE+Z-$JB8i{m`WQN zQAe0Iuxa{IFKu_R_&$!TWQq+l$gJAR!ZE0OvJ(y0K7IgsF$WMz-XfzQHSPnXkz@(7 z>t-m)E_U@gzYH`Mn)l6bT;T7I;y>08fcyfOYAaO3z-!7N8&mLc=@tl;evP2=`1RI( z<)^Hy%*%FT&qazibY$x@*Ul}X?=Dq~qw#&9p;bko*q;A_*CUHmmz@z?PIjf2g_xC0 zrYsppjz!OE=V(2W3nkpmX(_>mJOO3l&+nqVlS`ChQfE7IgMj$ayaD$hd3q=A5j0u> z)iuuw1@~A>8P@M>9d6MTcIbYLTI1m#~ccWS;?yyVi1@_jwMp zu5W=+b+Tt8KH;m^L5qAd&BhX_f`|DA!adrHVu{aWC)}?X?@*Hm1q2n@c=m0IpZ#fi z&R;y?cUa6K&Mq?T?&(G;8xvA;-4`%vYoPMx%Y~7POV-bqYv<~Sd0NdMX9LRKxUYE) z9JY&}a>R*zXC+~MdqZ*3Co36Gf3Ngf9mE+r+#`#c9(wZ+fj&$Y2K+?FF^+&7=x0UE z?sT@nSSw|}D~wp`3E=Ero-IqSf$b9+_nZx(O6J@C44aYWl(PC9Ci+XAC9Jf3yYX`B zP5$GpeY&CD*g#}i%&GvEVwu;9T{^I)$DY?M%}xT!kcsXlbVb5#?aAlK%O|&9AX6r{ zVpglNQk`1xx0WorS$fXF>o}|_bdmUjw4ckV`8mOhh81OD0X^A-HUE>SNRrxN`g7E~ zf}cqmz|Dywrsk7rwv!;)>pG;(zm42!IQ!N0xzjf5!{?Lzb*lWD<&rzoKK;S&?JYLO zOIz=Nx8P;4U@8sBZyI%=YUw6|)m*K+*jxBE|5jFB_JIYRfq1s5lI(Zy+t^C3*neFs!1Wa)in?-Q@5U5`C{CD<+F zYV$6-FNdN?tLq!eiT*jI&MZ z%^Oyf^!e}pr)U(3)i^k=4PHx$*32g)PZWvtZ2B@^dVy2bpNFexYIz$hn`KvAq8-)v zXP86u75~4f7BwQ9_(A`(x+{jvY4M@FrN!~1xVhasxD^A+K3J;X-G7S^)v?`K3yCL} zr}r@45w;tmmYrM@JUsn)d;Cp5u)sv_d=`|0Ds6vy*bi!nH(c~$7G|J(@6lw9o2E)U zkMQ0H2@jpaY5&H=sC`Twk1%574JZQT--^^u(>1HTtQ4;tFMz$@-Ccf!l2zi66Sc7e zoYz3qP*evXTq9wBrSt$D5<2 zSto#URP!vWTiBvl^rE)u%}|O)-4dN%aJ>uKlf0n=D!lbim|w_0Ut0MNY6P{TT{3ma zUYd;n1<^~`XG6J0I^m~JtSNBAU^kjF@4ZPDAebW}_*=I71>8yX`kcq4Tl@(~J2xPx zIY3rlYgS8qTIH#@^s=cMWnrfIX2XVaxSjC+-_LhEcDS(iKR+y#~E{F<#?_Wpw}LB z>l=DbR5`o%E&RHzSM*UZT4XYaJ@Y6ye8LrMbWp21S!@u9NrS=oWCMWqHXRGGt}W9dMfdVb>h4(IIHU;vS)ldh z^~vdW;}00!gbCDuVO6nPY?V zpH{E=KZn6N~}X`J>%?1zL`W7(>BmwX#t z>jW^913C?_vC7 z_r%fXG3!GIv5o&D7Wn56V`72m$V7p*kPW*-hloe;c_dMwCl_59r@|of#*Kcy`t+{v z1Cgro0k+%?*ET9hp-<$ZEC%%~~%tzwf0KE83{S*$&oq5J2*5Ld= zNf0SAZZt0&EKK-xw=?TmB?*_j@D^SbFIoVy`Gp51r>Ah_%$1`!&JK`j4FIg1sCZrz zW3z{esj@Ljoe&9Rb0K5h7>RJ}lCsBetE)EA^O7$9rfg7|lUy4E{mpZpQ|SuVL-;m| zo`BwyS?6b&AMHif_IiK^RRR}x=h#_B6X+nFZ|UbG+&4hZFBkA8b3DOf!sh3q(YNJ^oR(Z4k?Jz*zbOwTM^2c#Ke^QnCkpIwFdd&~7g_Fv-J8^>!UHVtA~D<@nc#5|Z)qQAon zxe@Y?BSmm?e&(wafbGh0o^K;rEVkl6wKJm^cLD2m1VF;t0>@N^eG($UIf4FnK+L5G z({rE}vPeFMKWyPT1boy3*TS#9B<7-slyMY+tSgBeM{t6KMH?YYlljybU?iU*(#Aat zO_0kir|z9^IgKMCXNY>7jpF;BIM_U6nyPV-3y#^EtW7fCX>osT4^~%rJT_KsLu8k` z=2s`z50l<>1^eRT8}lG*o&f??2akxJ@3_D+nEV-G&-}P!<6Y)we)85vg3zz*50bNS zZ_s8!Kgm^4sl8Chc9!(8Cvq9*jv54^D2+`$CC}LZ+)a~S3kvGV1^{%ac-NINP5k&+`Y+@>UqvPcj}fLLPwEnL^UYi6)i8#%-y`3d@zifJyEii)Wx zmY95#6-aGltntD_<5kWX@9#LKe9JHd!mDLfsOR9%j5vevo8HjC?y z<8JBX>ERwSZ!W>6n5P9>!ZM<(wplXW(hwniI^9^T&`5aryngU9T^|z0?E^wu#(~t` z_I8lVw#CsKtSWH{%gjiiD+yaMrMvTWhm0J8#FbzXp-tim>-Bz?oOF=y5Pf4xIOdXW z*#IQJSHm^i_sy>c?`cd=^kVgZAJY{sxMvBtJmSIB{Mc4m4 zp%gGM0!hFM^IZyyzd~JB5*NlJ0s_IFJXpC7RV?E`q}4&#c(*8)vdN2|2Lgy|6;ZOh z#_&zS0_zFVzbpOd;b0u)*B)$wIZnS98kyd}IItj7M0eBa73oKq-z&zWjM_+!>&kLL z5GcwgP+I=x%4F?f@r_V#^}lfokb<|Cg*MyS#>R2>7cu%p4Aim9q8V~vm1!gU2us=h zUajzVbRaCi6ubi7{9D^{4wN35eIA>QrDIbFO(-B~LM|p;tmCxtMX@8@%=Y75Z(QKGDPz<9VkxtnE{rmZAYUf}S zDpwj)ag3E%M&vxo2wm&V2(#m~zBdC2F!4Xv_T6d5vs!96-O>a(iJA6qU-4fTL39b^ zLFpy+t5}#j@c;5BVB;Q`ZF(SCFv0cz_78yK^#9=@%J^9G?a{i8=LbovU21nGGYKfU z6G+d^*-NAXXaudYK`2aQSRE_Ry`}kCb!hqv`D75#e{xA!6th9G{Z~PC+pr@0?07F1 z!yDT~kKX>{+dm2eyXUW$xiGNs?ag3=@2OUU&#~5gTcl=5^oG_FnO?1XzCo2!+Nv@r zd9}a2W)*DI+_;J#)5NcC`cDN|qt;_v2U7w9_!b@I$%YM0y3$Q2Icy5Vi$ezaVz2$D zZr@nr6TJRa^L`h)3{f$is`Fd}`hi+M2evaIGVPCAyi5*RM_k|$5P=8FZ2RdCjuH$$ z-KVgYT0sM@HIh2=1c!k9A)ua7)oU2#6QjifFfa&A7Fs{v3u}K6chg$ze5VcS7K?)I z0w*BT)9}*&_V0*+Z+%Txk7)vkYYq4@ zl`bIWD1=R$uJnft8+)sPi1)ox0(ft90E!dr;-6uTU9NVVH!_7x`0V{y0~h2@KeSom z`O3%p@jUiZx?`1&>i7Rx)5QG3F8Ktz0QyzV#rdhk&g`HIAa2C=WZBq2a@wk1X3WC) zB`iWig7JP}xM#`PWQynqGH*cvR(Skk#hB7QB@ihjzRMeg+z0v;xR;7zT#sva1+Ns@c$PFcCVgxS2W!M(b zr@5cjZ&W?>+D`eWus`a2r*uNf?B^6PRH!y43E8I8iabkjIRyiX33F`5%Dy-<&E9iR z&{u@-e0{rvRaZJAS$qJ}dp214QT;!&KQeK!m`&_mAOvP(pdpqYkaQ8X?rQ`0>_>{4 zZQ0{sQg%b!Zs+^M68rURGr|zrD|5()88F7TTED%h^LGAaR#E%<5%jv^A@gJ*hb6GU zBd`M6Jt=nwS9&w*-#c~2SX24SMg}4uYUC+lt+Kyx>IUl9OQfQ_9fhaIeD$`H9T(T_ zH&e41f%55Kj<(L4U&ZD+##F-Svm;yTe`mres0N6ZnhqxOB%|)nXAfvyY;{G|UmCyz}17_g}oRo6^i(_lFGfEd4&tz^d2TTy>r-!+~btN&? z(lJZ8?UEPta}_Exs|INmppzP^VAzbu?0R#YFW`sUSjG$8p|U=^b6*v&?Acvg1a=k3 znrLI*B!HVa0C}(pT>_7aDxJGNccG{u@jp8(WL)rNRD-i2t>@Q*be$ODIUXV4?^?hi zQAN&zQ#>t66{R3c|3ziztmTRzU!ampilpajZ_^Pk7}n?`XeyssV9nu__m2y?x^hl= ztgB|9vavB2j;Ha=MKg@?=+Pr*_#aZQ3<1W+Q$6F#LWoY0O)LDAR(o^7jylb z7{!K)W{}X?U+HZfXbtlZeiKX;DLl&783@U8e@rkJCqLH+iM;^eG6~no2P%7|{UAzW z%c&C(`b=)uI`${)y*;wJaj1+;mkO)q2(q|4oHs{`GY|!4)XW4E?&J2|Czq$wm#Y7E zvv4dZ-Y^HYrHAGWq{`9(z+0B<+H-f<7Lx9Pai4gKU42B|3xmZicg3sobRP8oN_jqN z8Baqz^{la9{|R1c2F!1!>8k5v^DDT7y`}_IJjn`C%1=Es3FcINW5(LU>;Ghj*kO;c z$9AUaBVo1#p_f5@102~FeG}Io!UV^{z$0S*D?l2c`A}maK(&4IKi}8Y?BTlH3uE%j zKKZ>mPmhBv&M=08vmdPSTO61-b1s0xO%rOh6HDKI)X7yS#D%y?d<$i9o?F;p@Zovi zJ*!E@NLn#E&|+Gv;Fc^1oG=puB&VOd`arski?P7BU z0NM*|auv8+OZz`(BR9*3wSbR>InMhBJ+WtxAW-VJs(s0wW+gF!esrJ7uB!dcc=W za9V8L!?;(VQSD;sI$?QNEOHP13vmproddw=XP-0Uy9#K}*uft{Rh`S47}5ST@@!I6 zJw^k&M9Mry%B=w%pA*1wIp|EC05!h_p9^5T z%s_jXE;Y7Ra6>s<^c>r{vJy5Xqxakn^1&NO_G9{c5z$|#{V#px6Q>DroTUYtyPRLa zv}PuXKx<%>(^=9T$Eck%B}3qk5lGzv%s3f|IDQWyAd4NM&Y+*1Ol4Q-`m_Z#SGixcjSv#foBrMKOw=rdV8qZ$|$J zd%wfudKe9*hj_bh zAJ#?~;q}lvl_xKju&KRIaAh5PagETRN#vP4d9@V!86iw=fJyJ6tk2QTEWvsUbZ%U6 ziyw#c#PRsoVh%u@Ry!)o-5&;l<%em-;9JLJ8Z0HYtolzCUBDBP4$44LsS4?{oz~D; z3g{x<3=D+70urLrFIg!X0_>ks|MCV6mfPu;+M{j&O7hKoekkz>q$`s6mqXCZ72-TS z0MaSb&~fcts8f4Z5HiyVB=<~rQr^xES$|JRbEw;G6H1aD{c&eH`SZkM;N4UU-oyCx zcf2ZM<%&XpD@f-Zx4uAHB(TMdmMya0>ck~^hc%Zk#EI(qrPseR5ZYcb4lTw)xaKt& z0hi`luM$(_E#_A5YH+=+$ds7^Pc@;}Z^6c|I@t)u!H9}UY*o()nFS8Mb$x#Dfi`xi zW})a~St12FC-S(v(8X<*d`d*3Hh zKxXq!^b$X*2h)>$GMANq>Wq7*`#)p#2Do2sh$rwaJ7zQhdQ;EhzpP;bjB;}HAnoD+?6VV_9%_#MHOEX)x>VHibt-HQQss8 z!jr(2|M{owRfgq~bo>ew{bd?O&EMh_Kij#eG!A5jv+S1>MMLu#pVly_Ak+3@Y0PTI zD;*uBH0Cq-T80oZMTn3MyRtW-n2PEpZx?VQGL`2a4OTju41ScoR(g%eXD5I~1U|uq z*dH${G)@}?BwI=tIl3NF{0h5;<;v{X?XeF&zrHC_2N#7IO@bH^Q6tOgf;d8OxN>^I zH$+n$Mc7LWSKbCz`LxOARWSAnJQI=(<2NP5jU^4t5>E7{VO)UVZ+A1@XeLSlJy1K) zZ)fSr9Yw!(eugf4LNTtjhIHwUG>024Tq*fOMf5$kw!c!sjkcJ4e?OAvu#ZYJ zEB7$;B0U=Ag(WxQk{mWPl&4P?i;KPd1c0;+^N`;+QBAPI!jEDry{K1Xffgt`F8zZ+ zT@zMrqS`|1Iy&I}Hb_&G(33l$gYWXo5Fu*3Uj*b)9SC)A1CCB27Rp!D<~18uf4f5I zkAwyAd3*x14}3z~DG3=LKscY?&W1Gr_(H}520YDN4JDojj(C9|*d%D6oxAP>^WgiF zBU5~SQnnB;ALTIRz@ogJfk2#nWID{jDda+(0J0NEC++8h7>{9^#v^8YCV8u#7D0~X zbEOiOw+aA0>S*!x55vH5<7%wDeINBq0I%rr^f}j8I)XU|@nrS@C;X-i+Bv>07C+ow z0tBqUl~<1X`TD)<+m_#JZ}eQJ>84{Amwaoc0S)_T@9M3>Py0n)+lSUV z_)B-5f)Z&1Xv{jL_J$Llza2>OE;EVVGhz0;c_xIUvNyxz z35QcBl*VzVC}O0~lN=kIaVthFkG___giwgKS$4jSjX)%}nZ`nHk=GI11W5?V4Q960q13%?Y$3Nhbtnt@kOHE|5#FOQ%R(S7|{>biF(pT8L;N0?!ZlU667T78a9j=Z8mEbP&^AqkxH%o8TZ%~CAj z)Bl*AZxr^CZ@)qq%$g!%|DLl=%&5Rf3^-CXt`ahRw8zHQoY{*GtRkkSd?WK3GV?xk zCNzLghwsxP?6grQSjwfTkZ2Kg z1hVr;PMK9rn=j!7X!g*9*z&Z zz6VjIO!o!SGbNVNuCsx`L)Yjhu3bLy-=!~3nWBCX7J&3)>j^>Pa?gC|T2gJ7xkfnR zLf1`3JysqH-4wZbw#CiXePg-G*DC**b8)>Bi^=|-X*k36tdNL zf5GzpTFa$jh3&1I4_|n^0nCe1-pgj6s^~KNaS`T0ggk5apM5>yfBAaQcELCy_jpCS zFrjeIUk+JemSax`u;Ov?Sm^umveH&y{W{KMQcH3qAaJHD40mNyz8B7i5_=V5w|yb-wgmvQ60>b2f{!#i%v zA3VHp}7snm?Z@Y`hQ z++BwNc1b3z0rZsM^wQuGv!WullEZ(ol*EULN;*QZ21EG{fBn3Uxd>fH50L;FNX*Ji zGC5mP>(U8G3?-UNZ_Q=!NNx4Cz+-3vt9~Pctm)-BgV)+UuQ^J26SZdSf|~P=#I4pH zrEyn+x!x5g8vG~pSB?6SJaxbOR37-*F7SuOXVteYp0mdxj}OKjC8ioslI9uF%Cm+< zMX!5qBA?DDV!sh^!(CE@@)5?4<|@pYqd?X@$;B=Q^@td7Ptt%YMY%4B zS5|;-F?M;cGGGmSIXO-MzER{3y{4W}^wVSyFc{?klqg4Dd!4Q~v%`*nGg%w-quB2` zpWg>=p#F~mHt-*ozZnl}waOy90<5bP@4w|B$@hxWtMEJbdSgOA{La_9oPpR7n0=YC z+JJ~j!OS@`Wv0fcV)(}yx`6X1z^pRQo;wRV_w35kv{p?=z$aQ!GL_|X0Ovd2o1XCx z85&+;qaq-k%?Fn%Cg%5pRL*X)4(uWY4h_dvwc&f?034!<-hhrW4NOZ_Tx);UlW(uP z>!yRxk*c8oTh-6@2q(E-l`M)!6x+`~p4w(1W&8+(QyQJ%H$0#w9y;mJT{C9Yj`6@Cw%_s$FaEM}LpP zSpVyr=$W%*eiE9SK{`gF=zW$bzt~Hsw=y^N^U*q_S4UP#pYkN0JZ5mJXvZT-SSa2 zQ#D{^QzX-L6_6+=(%#lsh3(HTc3DVc@8`jX6a&$W8VZ|2;py&aHjiq@LJSPXG>SC` zbkGfsUsDZo240Vt-$RYOiILwZzFBday8Tix#bfJxo#6KA)Wp~AW1lTw>uwQiKS9?e z@QsCCUhDbs-=D5X-Dl!>7eyo3R+&U4(U69xV}X!?K(4}J*ugKLP^|y+KRz}?%DfSE z+>FfvJoixXw(V`ZH&fU$KT$w*j6NB5-Q>2XsMG9 zK!$T{8OL?~UT{+-or@G@THj>ru@qn6);U#Xe5u}0uM}>8V$Yx528{18@XfvFV&!oA zsEop(<-|G@ZJ zPXhzLT5{X1!O`}rT6xI8eb1Gjpa*F9dwI57(D^*m<;bVo?x80Ky1`Wn8P4PRvZ(Q@ znq>T`8%{yfz$0;l)`PasT|cZ;7C3M+;wy$DB(I{}LuBY=n!G|F+bKV9tBe_}@5V6s z6?gamm)KbWYXhAn+`%FuzIch~yz8Vqt_d0jxG5W*UeR;VZs#^27iaL4b6Z2ATZoRb zHV%e<6F042P+3eg1$nWx;*alFGz?@tv+am5Gn@5Bo3a|8X+^y{Xhje%u)SB&UfKL&<=-*9=7~hBGH*EVcMcDKt!W*SK&fT$PMlIgB4Xz z;A@^OkyhT(fgT)(90gvHE6PKsPmnH2u`H%ScF7;Uy@_pbC1ABbOX4DrZl$bMHA&_(0qB^TE zKOk(-$F0kTlg@=PxF;Mc%G9U3weUYZUL3_|gmn&?fK>(eK>HhRG_hz~7#Ov}omfqLz zHmD+*9_W+Ief){Ey@5zBE!r}F$<$d-3Sp|dVLBK}=l29S!ky`jQ)BjerYwMn_Edp> zF!^aGDHh`6O)TK8eeW+)e6d7>aSbJv?*PUHS;D8+q5)fVKP{-;3csgf1SbaYUiLLk zfGVpG)=(WJMJ;fj>l7@!ZC4vf`@22B4JO|^$|ws;?@kM2yg#T~OxcBYvogBHJo`au zG)*o{r;6tiEZZdTFKo?QgjE=XLzRke7(vM=tE6=B0~5xo3W*4a->Q(#We$2vP2dIF z;>Wex@+aprQ?%EC7RU(#uDm9z9KFM}nDsj88jtN1gCRDycQp?rHp{+K525$03WBV! zY)!%d@sh&c-+BS)@);d{%XdZVRc+95*?^c=%nKE6CMJrB+)_?l_BUHsXI|6WIq|Im zfsboH=T{LknrruG${&xs%&ELgFtXc?>pp6J$qQ^U>ZK~Bg~ybqwd1*<*KeCfQ3fJS zkqdJ@)pm2@uDkc_Au_6F`czNm&@UZ;+uW>@CO~y!3rJ$^$IqN@!xi#Oo2jvxzr7}i zk!e16S-9^vK`bMxD%GUBY2 zSo*ilT)@O9-d6!C+{MA{XEeO`##0%#cgqUf%>2A5-Osd4$;3)sC5&K8fcdk(e8` zbI~%0gwB-;-bt{p7(Mg;9vXA+)`MX2gLv;~5yWM&%#r~hXuI6DCPt}nT(`bv8a?k- zh-!rCh3^$yqvD&tU?&ne`^sC>B zWaO>OU*eIjhXlJs-bC9HtF!B6;=O)b#?6U9X;PUd6%&d9o%`{7JDXJ73lepj5)qZ1 zysM)`?#e18b7l7PxuvP(-0hnZ(toYBjH%p#K=<-D<_PY&dPpY8=r=D8*BdkfHxuc% znOwi~r`(JtYZ!+aHG#mPFKffzHF7S5I0FrCPN4D7G(_Wleyhk$-zutzI^x|C=+;X^ z$NE9C-`_;aP3W+OP8eG*ro6ZF^WlRaUi>=&{I{YdA0-pUitdrV^zi^PJkrK467KN0 zfv0>xgNRvBU2nm%_as({@e2p8C!ftvm=e7PcTFb>vMXR?8LvQcwW~Be5NDz(;2Kvr zdwwmKfTnv98@f|K4MY5RfJEAM{UVJp<%$zN=0JvKA{v>|*PAmDh>s4~POGm<$b;uF zO{=4fPdF*3LBqds!MerUFHr#TTj>-F5gwx@SkZ$Oc%}2P429e;?Z8)LA?NUw@?36m z<+WI+`YvU^`6P+1eHL^>WXFF!uQY1&!J3Htm{pSf(qy>Y(3DHpZD$l}fMA+63Yd=# zZ|prNZ{aU~8=7}xXwNoSG_E2*RgL9~?H&g4gO{stl;TnpP1N@_%frnDWsQh?Qi@w% zo=A8~^!AhA(TBL5TDAn_Gq2dO3LZUb9%G_E`ucjhqRTh_x0Ct!qF+nj_$}-aAMS=- zROvUiq|CM^HhD;U(|H5MmS+mylF6`Y}meVr=7S!_H@J=F+tv#^jEz4z1h(lf>kcpKB# z`#wb&`W-KFnGeK?Ns!E0{?yQi|D?u-wX>_eUqD3=CU%TOkK10r4*K$1N~2!Y+Jdi% zbnyZ$!@FCZwi&|M*PlTwC&XN%00iC3WaICq$?b%sNj(r-Bscj)`|asCj!IMy^|xK; z*~dC*-z#)`M37F85ebpNzuSAe>?fk(p7N&5O>2@l@@E6bLc+pgbMYXhuU}Ms=Y80~ z;r)26xpio90{-=p@r-eEiFY#&75ByoojE-sWf{fCnyiwz9NJ)N&q#jrA+5|YqE8Qd zhtZ7U#m+zzvWeQQ=_;Pkf$3AVKNjIKkg_XS%xJ?a1BxP?h`LxC_lXL5l*fc!t{@rK zCe76eUovTiKJxU}BYp4(Zr)ObKM&J`ksO87ZOl8M^Py_eef-BA%ytU4g#n4q5>nZBCzVcw_Il>;T=Ox^l{^%iE#J z8%$$*AikQpece{&?>_n?%sc44PFBN;kc6d8OJaf~CiwuoBGUzfA?hrhv~&L)4KTk6 zP-F)GU#v}qjNxC)NHmfO*(E|ga=QBtv#Z{K!yH$9byk z$mi<8NV;n1S|~W-(j3?=67S#mfktS*hsyv z@?)@9fB)VJ8b{iC#GIT2}hbD+Rr_)Ke z=SiQHbn&b&0lYV~79Pcg&6OZF@vm6`;6tED62#qd=80E<0FwmDiMhHGI$+Q%2Ogc* zAV>GiOLvGlEI>bk2aDpX9cv%(x7zCEl-jjXfEy;aqW#Y@cs(|X+iO7ORPvO8 z;=kp~|GnZe-U=V(Nay-LtGTL69Y66=qtt&wGF<66jcis zx#E-?dR0o|ZfgrVdS)RlZuZS4XLD3rAeZl)Hv%=}SzN`s%tw;pu&+~~aJ;>RGbCzB z=?i$jIbf4mG)B(im^gy9@i_YdWOC;ug*zA9mlr+ftLpy0zJewWtx6DJsq%AN{yO)R zax=he=MFqEg^rlw-J|PvrO~PdW{$-cSRRjP=?i3O4QR?KIRz@<6n8xfD<9P;SUnAO z+ke5xr^e-I(DvLm36^*ZxaQq3m|nq|{DwpIVqADx+(dJY8)!*64ATQ4Z9?Dr!{F;M zyWI+jvE#Qm8^r!cK|ya73K~w<5JQ~`(avDpO%3phj8I_`!6c~)_oK3>VYd%ESfZ=I z5{#ryr+9Cz9)NNMvD`^r1VV5%urZ3gHBC@Sf5JlYAIJP3S4>7p9g~md@e##u~SZfD+J9B{7UQW zi)pm;z%;}Hmsd`pJVy;*7uEu3OFA#n_b!nQAxTDS2_F749HNIf z12bbA(kOGzq19r1g?%xd-l|L#nYtcpI@@>$;r4jy)gPZ>Wi}yxxn8$|{ZyC!! z1+9-Cn19YfoF~G!%K9Hr#Ak5BqdpB(j61APhJ}Xakj!DK0TaE89{&rn95krCEI178 zGf0NlKs%v^aT6$^{7>#Vz(6#`e#?KdKqoBOuZ#(g?!ubSAvg4r` z66UN*CDoI78{GH;-9lrBIDM<#tbncsV8HRPO3}!r?=oe#@9UL)^}%T#zsF)!+>V!B(%TDJh;o|~3tQeQp@8t8KQ(vfts3~c26biu*F!pIUt`~W?RJDk3IHVVf$GLU`sY7o zr%qx;cQF%uG9qCZ-e!{4E|0|B)gQpPmJC&p+6?dm+8MpS%g!K7FMq{1zQP|)pFE!2 z_5%oGOU#76hu-((H>W{)Yn(S&8S{uf1AOQ8PzLj}V6q1`+I3RL3uK4D9Xft^m1@Ki zF;MojU65$1x0`)lNbrr}YpAuPsj93~p@~XD;`gYY%vXwl1G^tauC#L`v+|*&#Ya#t z?{bmXf7iloR7A`8Pua$vA%I8$WmrNIaot>y#S-Go{gN{pbOgYRQ9UeZ=U7Z%+NpTV zv|hI6;bG&YZ!%l_Dr30L@i1y#E^qs>$E5I4Ul>vpENUkph%;~~ zBknmNI)gpcExdDv{IVfsH^J9~^4XKa9ohpGDD~01MtIvamQILRBv`cr?Hxjrj$Hx! z?7Tk}#be@F4584<2t>@=s?+P&#TD?KC-mo|_Q9wnXV5XV@BBMTbPnQwBbQ_j&|<|P zBTi0;j6a*t*S2A)5_%VcT$jRy&g~ng%Aj0*^@WU{6@NXumtWF(YxkQr3tEmY4J+2oV ztw9f!mo($jp=)j7_rS2I*l{bP>h4HPDW{e!+6y@TZyV_E7m&C8}JlfWU>XXru&9~gk$qh`ZKUE zb?r+=If2y|Ht_q%(blH%%P(~0dGHtz*!D(Wx&%&@O<9~(LcStmh{le!DOG| zUZZ@$jf}4RCnH^?POZzb2^70PgxTBY-OJR&7}4W=WBe=FH_bPs$pr)>uxzl~IF#V6 z0I=vJ`lA8E#@My{?hJ3aPfkz$4RXJ}S(DY>K9Cg+{S{gr?XnCMr(b7FAz17`M0Ey% zCH}>+897(xf7ngrB6Ri>j8@%6~O-6xQDg5d&v345d~(hO!@Kh1uw2@_a%A&nA$Q#0k> z2a7zv5s|zG>zN0DXg}z{@nL%=b`O7pRbD66A8hs6Y>+eqTVAjl~W;l7IfCKZWOuI6>$yR^I^>k54O9iP)3;$+uAI~c+{ z{cGggWd2R28CfGiVL8RLF6>jVdA?SDI^Pa*|sOzu16A&_=Zear)L zYqwI03c_}wgOK#QK0kB>m*mJ{2`BrJ50ZSnkGEpOA7n@d-bND1a_|dnYeqmQxy++{ zf%ts$N{U3+bDKsk{w4SjR@`dxvmhubyNKbTbQA;Lw>I$e%Y#1y)pDywGVIOE2;l|R z58)6eg_WKNwJ%%TKXtrJKV;HFVi22_dC3fe57}D}BpV002G$6Vy}3gny)~DBsQfUK zu7`y*EEi~0^={sV!RzBy>=+7fKnxM?1(0d<@rRxBU4kGU~)* z$^^ar`~g$QwjPuoFO{e2UMW2_q7+u>2lg||dv{{X;dgODiZ}|P8gY<(05%{CajECO zV~Q*imDrnT?R(lGjqqMa%xRFKwd&mwgmSml6@QK2?Vdr2R0g-!>ZxE1q|puUvd{O$ zy!+&dzbwjMjq8Yg8S5)B#W7UZd=maPupazQ?mha75DcF_Y4aGi2J4MisAp3$eHUMi zrj093K>Eu=ZBTwpw#x8e%3!!`X|nf$=56owptF9Qo$X^1F+X@ad#k2?7Nqjbj}=BS z{7S5{?z^HRAdqjxuPzK!|3?rWk1@V!?`m_Wyc6L5pOafb8p9hG16q0)*c)cis%*h%ud;aujvcjh7(B8- z>eddp1K~>0$9T|GfRg@b)P0GZDZM#eyglXL|Cnz~J5=91B7a?b_So^M{*0*o%E8Q^ zwz`ly=q&98xx?bO58;~lp+xbr5HY49D|$N2No1^?SiD=!9jz>QW5ZsORAynfaK)#t zi!d%mX^GZVI#fYG(}GIefv83kxpJjoOSA&~;ip(rA7{!5=_e<);26k?!cqLAL7VD& zSg*R#55UsAYsr~4nm$$lMGLX9NjTw(*_$wl*dI&9*_*aN;EO*dtv9(+$zHn8PM939=BYP2x>&!Do@{w6ztbNp*5{4EJ=0jyV>shdZD z&pVyJ9Ip&mAHnNRDiqH-js?Mx4PVNUnAniE@cxE}{oL{4 z`}wkUL^I=+|N3s-zq6YK2?Pu29MB3@tCgD#SQVp?qiG95_tT?wY^nq%o7}7xi!lxx zT(kMwC_P}+6mPqeNxiXZSuM?o2~kTsfi@x7qSMktV&^q-j}P@P+5u$N=|>AtagKz^ z5`$-;j{45-Ye;X%G1&8DV#y|&6uxr|4^C0Bdqs7`S_mLKv!>3zfo5fgz3qIZ&eSCf z!)3E80TpXj53~ExSLjp~!WA!M5r2iTPJ)U7jeiR{=d8K_pp}&iry2v%E04XLai>&q zQ0Ua^bl`4Vvi>U9krZJm{0s)T=0PkfiFWAM@ThWn3yedsi;MKug+I1Jq&&+iJ-7A8 zy@;bilxxV-YTAE$Y=6jO)agr-5hWwwU3#J2OsrbSy6AjnO6HRY*5RLi z0^GeeqwhXI<$7QhIa`H_7^Ff}vxgkubawLHe*`Z9oFaoi*BMfD+hNPsIgp9g`xyl} zbN-nRZjr--;8VpYsY_j=VV%vrPiG74L)1K2t{aSycNmT(qh)>SX_94jUQz4@kHOK& zE}Qd%$j*sV8q&8dbC^0>hFF#4c6mo3ne&(_ObNJy({bTkv_9|9=t7sW$W?i@m=F|L z9Q+;bJ|u!ppm2=k##K!LQZ)Bzd{7BlsX&HSUL9AM*SkE4xjOW9=^m6z!vvlXNUx&U zAmM<{l+_6-+A=o(+~eU2KAdi}df2~pBOW2*Ep!N2rOSF$VN*P-WR(8)edtX{_LlRm zbQC(R(8B&8JwoEEUJ9Vb*B69DSgmU@M7<7P;Qj&=4*LR*Uh1Wkcq`=l6ywC0!SO-j zzI2F=1-3;?BWdGSoQl>_w57K@7 zugy|%tCSttK14#SZfyyFbPC1-HGCIHoB`<&*1(GaV@a*90AzFAdyS#c?9hnbq2d$e zn>#_I^oK74z(Ai?LgOxXPec8q1S~o};FZSt-2*$_3uFU-o|gmWu#7IKzm;pWfCnhw zdxN+UXc!l(&=dO9$uF1>>ES?1`A+mfPMv4}QUAmLzO{vk+fjdI$2~mqxqzxv_F3<@X!l|ECNkv8Xm*1H2Ul={gS3pXiIf5q-F#qf7zBLSX&oDTU*IkAipF zq^&BPb$!4#r;Uaf511tBt3;JxtH1KS;t8heJ)*GN%49o%tmsPDft#6;DaE4)igxlR z90l_tL>m)&{-1+T_L7y@Km3TMLx3?Y$+MLF>q6=$J30f~KvQb$)RbgQxn@(0;y)s; zJLYHY9&Ht+y~=D{#E_g@F!O7Fj9VsW1R&?e0rr-2`hyoQfnGBL1BIWB2;$CZgNr2pR2>|Birn_C`r-sFzOO#T5s75)K9JD1lgiy=bO2vqg z+j;5pM=jPkYJ+M6t7?9hduBBwGaM1(?$>%_~Y)lD;w~GtKPnY+mn*~*SL$){?r)e#YLt*CtqjsS{vD$_d*XElwDgGVGDg$U-4J84P3&t z&6Q6}2Los@T-vb9l&*XXbIec@LNG(NeR_EQ)nO6BM;2BbzMPWE2wIp?aW3fiddS_! z)SI4@$iTts9p1DtC~KI{6((>t2yUtNx6Qh#Y@h;^wScbQuL&g5^{N+VML{Yf5|4m# zY>kaNBMfuoq**uvrrbJJp4uQ5g(aig<;kC1rL*QKD#1vv!etjphBTAcjEwUCCP#lwf>@`A31H=d ztXx@@Nf^SiEE4h?h-KS=AqkpW<&Sm-iWipKP-a}S7_wH4){7x+C9MjYMlv}fI-d=l zKAo(DU%$ly29_BHav2pTm3%{kw*u8N)sadTy**zQ^9DgRo!*h6|{*c!8BQCOyij!%iKRz7W?aXBnKCA~AMSngjCSA$w3>Nvwk3tMw^EJXdaH67>wD${IGz*4?+xNLUFqna7b9C|!RQn}s;=ca z8#T0ai?C2YY5iZW+#At9>m0SXK7TA+)~cYSj4{GX7crxH0Z1?g<%}igX-e85+pTaS zBWF<6WOGRR>9O{+nNV!e0}1M%#>W9AI9@R-bQf7Tf%`9jd#t7JupSRO{ri1vx@f`v zotO;I)+U?H*o?hZMZn-*1(=;F$|_BVwEry5&g!mmR09{(wMU;F~glAnDCSXqK(gh}Er6xfZ$+HZ5 zuNWSdsY3iQKx=J?1{Lx`O-&xw3PLPw)+Mv*{m@o{;w5BGcdtlv!q%pSBdj)+VdtO?WZo;{Q8L*s!VG^f_wCrO8;~#z z%T;8BAnBiS;t(_;r#OCzAShO_>@sCjWdYC~I|nOjyO|Ft-n@51uC>5OO&Zcb=JF%< zX6>HGF9&r+;wBgtRsz?C*LRtD+?(*X&^*32kL1-ix`DvJPXS{$wb>;~1@K$8hG>E}tu7@8C=%jvsu)GmQ!a?@Q zstdL%n@)_L1SeyRbFl%263VpMVs%4Y+7!K(05lzAVlj3I_i z_$3fdO==~b?+zJ5Si8OXSsSKI9cSun9D#DM2hhSZXk9APR@+>Ub1?Hxdn%7q4d#u@?EhV-A}rfl2Oa?@sDW5;1J-Sfpbq!JnRGEr1a zhA>bzZo#E{g|gtw6U-!~zd(+R*tGIi0I_7wJ(80LK;BIutoTkmfTZ$%&$(}neL?yz z@%s@V^JsAw==6JuQaB2`f%0{SqYCeEMs|R%wim++UkV8~=+kF82lse@{ zaTdPxH;-pe|5fEBM!{PV)Gm1d3jj~c7209W26IhxPb~q=2t|KLI1Vnx>RQvM|Ey+3 zS&y2!w7e!JiyBdz_^cVc7~EJWrhEy++{I(dNZ+EIt(LhSO;V)P2_`xuB(kQGFE)=X zE^vreWeOQ#ID(kOf*|pH%yL9v^+9BjRoc{<+BdVAhAo%Or#UM%CiYa6NNp016%0vu z=*ou_TOwCvloV)&d-0P&sFE()1?6QNeh1*vwmhrVHl}SbVYfnsZuM5g+ty($lokAWm!CQ7c%-Uu-qPAaX7qAUtry{-bpUS}N}$ zd)S*tUA#;*z}C#v2a#L;ga#Au>_;{FX)G>_YW}T(vF5o$o(2J$X8Vs6jztrM51AOXC@crfF!hFLoT-6xORfk9Yi7025KW#`E<>JI=fezL z1eJq?r9;gZ`tTLTQT99;aD{{-OOkIQA zHY36Wa;;J^`T+{rdr7)~7hc~h>XY^274Gy*rEz=RPDBy!ieK65eb9rhm#?Le=jetB z^ma!hjo0CvNeZOZ@s@bt2TwKXZ)EhE;X8)ck_VSTTs@#q%$kt4)YFv|;Td~x1*yb| z)z|H3Oq|n+=gu#s53^kINdO0mByhvng--%bN{zi6cgAO^0)c_*u2V%LlI`_|k(rE= zPPs7c081v}-5*!-zio%s4yZz`u!Wh=d|T(#2-0x#S$iuGw6q7p8D0YY_Ha)Un0v!n zLd=q_^i$6ikgtInAqqh{n3P>xy@NbRA+Kr=gz4)84b7Bj{W>PetZ<-y_S_(mzm zT1xNL%zycu|M>;HF`^(NQYF}HuOLo$i3-SHN`!d{!{xXB;dJVlk!d-e`VRHa=l!i& z!o1{!DSb_b|H0j+3cY;65+Co^q?7>r_OG&Qm^dN$RN5%->ubSfJtefJ>?MLNh*hNc zF#TP=l*fDq@ij)C=v1cQPz?i5;W+Cz?{ZZ?uOXvUkx=%OJCa{80Q>JevTyeQ4H{o) z;GBfR|K9okccH4YL0-w91FLh1Fex$@l&h2N&3KWczJCae&*j!tg+gGAd!B26byUyr zo6CQHApUcq{`39Cvn4=@kljSE74_eqp#T3D{PUpk;DgO3PFm9en8N?Hvi-l%7b>)1 zt9v-g3T*j22bos=+8Wr%FZzu82z-+#OEHz2z+(BozTm(8!4d~xHC8yoLea?Ilm|AJ<9M;wVw?JY;zK(yTZBWD|K3Ofx87extiA2r2x} zwX3Io4Cv!CK&cdIfeGiLd9c!DW@+=_Q6uFpH}IO87!+BJy>(0l6 z+^Rzk?uF6Fd_yyrhk_u)U>-oOMq9u1>>O`^;^>7R2poMEFty1tzG)i{6cp^<2z>XvQmT1@NEm& z-2A_hI>I|nK=O%veKZ%6=$QoykKYU^4|kAbCehbx@&Ef243eP=(Zb?oKBuUP5!1l? zsAI-{ajo7Z#^y8!&5-k5w-w*29~a;-D_@OdTq@|HPNM1en22fS(y|quDMps|^KK3@ z%GTCcZzd&@(9d<4qjPmGqkd+!gF-RccJ)n){MRSF#x1IHfh3dL)f%|`+XdOx zSVIA64zixe+EVHPF&6@xLIiFS*#go&=ZLLxmS=^x-oHbd>Z4T+vvyL9Z>u1$kg0=) z0B|o-Evny`Ktj33h@!5J<_|A7xtR|{qpyF+J#p1hz4_YBZeaGs9VkEzr1Ct)b-PO4 zo`Pl=cZlyY(OfLUf+W|#X*EAo$z%qQg%t#&oO7RfjFS-PG=Bvnwb4C5-yDeE^gg*& zpQ?&=zcvOCO&i5xU7co34v3f81IE$m^U}EAx?$(&>buo=fkDh{fn^X5$PF9C4I86`rF?-ZvHEN6UJR$7IR`-Ozm(1S&2~04=CtBd8fP%%Zd}pKl2=@rJ(qFQ1NV&h^l-ACR4ET$ zxGh@PsPeISUN6Suxp48HuI@nPW0t9R1Up zc(YMCz>Im!yKCoYg*0051BogCSmy9tkC`ud z8hd;b72s3lbJWh*mJ(`lfvFWNI~hwk7y@|uwr3!(#y7kG9D&rO eb{ffNh(JNO) zst_fft9K?VeSSb@CWLWl`1Z;6!)IaePj_biG{w*4-gE)-31mOjhBpH^pyGK0 zaIx-(2m^x>iZQqi(#)^bHR0gVaC9wfDtBkv-{I=Zn3w? z#i}@k1h6l~m05E!?Y`esnjJM9Bd>0&E4Pn(#hNVai~pV$K<y#dlc9ZFqtz#NAD(%boC3DYGZ3Jy*GcLGQ(#08>qIil3zp$m5HD%8Y|0gD zgLKhtJvi;zj=Uz|fp$p~S^6=Mk#@cMcqW_jnQ%AVsKA88p49#7_wK-mDerSH^Pxrv zPn?WR^T_?RFXzQ7VT-9c+S+}oQRaTmRFbp8H}xV^1G^1ybJav8K4pmAM&G>GUdfOr z4Ah;*eXy>sFRUaEWQ0s6o)_$()DoBd<7@_-V!ULOBug)B2TRL5$YEn1ZUZpdtb`b9 zIg+hv2Cs-x<65#(Gm>}fEi#v2fO8g#LOU`aFNJ)H0R7@@z?akUOHXm-rd#;X{WDZ zivwHbF`u5@H}*=^znzBbuXyK3{;j1qg3LlJs5b)~o+mIDw+K{NoHKiGBl`uAPt*w1 zjczpx;DI;-TmIN3C-Y1MXpcrIH)XZM(F22Jai@;3JOn1uJfvE_JWSvugtrr*ovT%8 z*83spp`cK>9HqiJM&haGskU^L(osYaQ;}*I6qpCn<1LNW7GEu9^e6f+} zkNP;w4zL9d9W8Ed z+SgCKHGG<$N{0#xvGWd^7gF%YxKluvS28n|f?xkCdEyT0@qnLvdLKhD4mbK%X2f(d zH+4~YDyKO$|J)zX!7JE)8Hq&H!=x<@$KnUi{M+iA22Zq){Ii!q_% z!rZqQhdj@Op6b!`r0RVG)F_K9d8tu(m{+f)gw<#gp0!dKJh#ySpkg>IyLw@2A4>8A znk$=U9b3Gej4ft6?oNZp&rNk$lPDY^xEVH6kxB~-Fq8H=i;I2`8?~p)9CImZC()+$ zY=fT~p{b^kj4XBE{DIqgJMRy%gq_ENQ$1TeRfhw>2q8d%PPI_2LqUNwxeNZj+Cm!& zdwL~<%AXW$P-1Ah`nM|A&v6%ad-E$uH|BD9nl~8ROL`vc1Wq#Sd(9i-?#qV)+<0iRupE_#x3!(k8)#hIh z;+zfP)?u^szk_@2dtpCbD0j<73tC~k1Q1!~X6|+#c%q>ABSE&B2 zAZydzB!7T97B7s9A1ssN3{Vs*w@yUI`!#Cr&&{j|fhzIBH(ZTqyh4=(_B1LESrIOt zrZOb{#8>+QOXQU(eBTwK5A|>8xc4Ha%@eYBr zcVLb#;~A!v@yGkg6BL@vzR&zP;=r0SWMBc#)40v;&>487YhGqi9&_am)R)`&A>mNZ zk?Z4G#+vb~$@kvcCp5eqoZ!sKUP}ChtDSa0OWl$qTHYc@3l>WnEEebx+w0^#0+@NR zbmJR|gQQ&|41>X2O=4d5o#R}~q~5q@I#QItH3o~<=dNL_PT%jtoKPb#ll|`GDp46! zdjZM~#=!y5-&{P>940LDN}p~rOY(?GQxK-iLunKK9DPPL**tTVx+GBd=FJWm{jn2<-g1@4Z zG|GYMu#TLH2xyskg10gb`Iz^6{K~lLso^_J-?M!pUjQ_#81pxAEZ%%~H-vv*e@ZNQ zJ^s$f-6{7rZQprB#kU!y5$F965yyF#eMgJTm^2rx{pKna#rX=)Z|wEzbbp)5;)WQ= zV+Z%ZoWQ9=s`uG!XwB!d0pr{642SAZMGRUVn+y!^>;iHbBOYlp8v;C`dc&_~pOv0V zTTg^KpaxZA9q`P~I^Rk#vGB4Tn{D*8Z1vc};B=K5q$;#~0LIt@X2R3Li3U3&y@4LZ zHt^KUgU^K<_+st=xJer>436;SdvbH1cnbD&q|&CQ{B6r-UH`BX@w-A>Y2_ zu+9CXH#$_NC5-@zTm7ioBys0ZO?oW=8|xci!Y(arI0U$*0Bo(6`f#U)O6h2?X{~cbyvf?yf%$>c14TTf5*{LB5QgXLrx2I6n(&vwXRrTKww^ zq^QAfhR=W{l(y@?Y~MHg=J%^lZto{{o})*GSnsKe|L?IzT_3K337HmiVI(vRbgAGT zSYqsNe=tYWY>}p0Jce@4*z3y0Du%lKT_dheZCMZS%d9#W79HhTYu+Lfm`7k(MygdO zX&f4j!3rg+{+vY|CJ-a8^O#4mOi8D&_{F+qy7B8fY*}^bcciFBpSnu$t<8q-gYWv2A&>SWW^@K_@{OgGzhvGF-n(pcmo0#$|cZ zCFptpBCeG~{d^F=PrE0CRR$#$R?2kpc-Ro=R3DD_WDO`U<4vtdK2Q#0$!PTu(l zSS`rRo_?y{ZJ71J&-}$BffwIomUWODvLc&yz>d2g+IsxuqcM*tq%XDcQSo@C?0b4l zmp!HpaorGVl!;9VFC6vDeqSQZG+*fYXC76CIHCNvt7i31l)~s{dBI0i_bhcyU$gBt zduUyl3n^l2bxbn{iHo>l*CKrMS6ktMqo__wjFQx`9D~bScvrb$D?@;)R^*R7!)jYj zdgGO756tza*9S4}G+j2EOV)8OKupB{@kF;UAiOi3z*Is&Qfz_?JwJT7nsQ_uJXzV9 zYj0Fup<-9b;;ndeN?d6hy1&kc)EcS){aWgM!!=+G^7XEm&JLpz{3FrlxIUlE*+&d~ zbSeqlmVH3BY!%Eg(QsP4)c=ltwCoo zD=UG?BDti9vMecl1ooPJ5QhMIu-6orTk(IQvtx?F19`(5HRH=MhWwJdSZyW(l+K;Z zOc)cg*F|4|MxwS{akTjRw$aQ556t&7^gb+m-2r9stq_&Ag)h{-s*%V-6PqNq2&XcT zDjR`sdgsA3kud@6O>6k+vPok?B1hybaE$TJ7cJ&PK6W>ZQp?n*G7iZy2H>hIl3}B zy-f32I)PqCRv>$ zUC{|P0_3lq0B_lfgv)O{s%vUhm@DUQpM}qZ+P@8iZb%fgd!}AG>rf?0nEE$S({0QM z-FN%g(dpromc3>cc2eCh2$^@?4FaNBb3H#T_^IO>;kkWWtxQ=WgpSl%?=PCiQh0EJ zKa8k4G`A1j-0pXHQnN zmg@_uaETuPtCOe0Pv4=Hkguv0R* zYq2?DAy4*knYT`wv0Qgt1pB;;XkK=mTMV>&l`F}@+0nP&($z^O=H$@jZ8zLf#U;0^ z5u+UsbFNHTT1Pu|d6tR^%92;Y_)@b*eoJhTefj(wwWn=nV&BCSClj@WlvcNs^ot$` z*}QV*qt2&w;w0&>TJM>QRjMl=7Dw&ij&lV%w7*5$9(464MnMk%L&Q1Sb+$&+P40#A zkkt;+6tZ?|x*&RC4`dhq!GCEc^7w@?H4}4xu!^}0LApW<0}FEo`D}&4)A?9Q|L)!w z4^;ASUw@uD<#!m2F{SU_b@uB?;aR>CpvKHb9@bvBBQPY!V9}EbN2$eQdeQB#4b;y;o9s%|GOys}@*n6* zb!vYxK9e>Wspyyu5m_t#v`$wH-g6dip=> zX{a6e9IVpy@Z^4e#{GXVTDi~lR%AO^$(T8>LEwY=D@b79aq3jCP?Lnld7l+$T>C-C$lE+RF?&*0=VArxyGKPu;eskZ z9&YMMmnFZTfaQ&+(YXoo#rWys>*n;_ut+*L%1O?#Z_h^y*$7(@Svru`Cu^rctk@rLCZ_g9i;5-mCG%#^C;GP}_KW5f>ELyb$6no0 z&jE51g|0S3%(iLWMa+h^0Tp#9{Q9`mqIu}(LoHKh!nWZOk+#|uCFrb?G^Hmxg-+7X8B+;}b}>vw|}g(nOg zY-FK}Jl&XEGZ)Hvhsoq_HkEy?{J(}OnB3S#X}w3jR~C->ihU8({wbDruEU*2$o(sRwq8Z!S^t*G5+LW?Q&(c~lFQ}2}~E#t}}&V0W4lkUO# z4tgJ&3po74%)TMJvpZqoQzyUUTpcz*X3#4A5O+V1ajIKiThW_+^j&&c49}8(ePQVr z>!UU2s}Neln+pWaAy3TjKq`>huC1mx`_tLZ-lvuYw-JYv9M$cKl5G9eb>5G8*1C=H&q<%5 z{B1wKCq~&|#G5AQo$kt|VJ8SxGT&f>(>3fZJEO$;%A9T}{K~M_^P) zxwz%ge|tG43L4l2Hl_>R3Vw%qJ%i%eOZ(BrC7~*#^r0^eqo;x+?ljs3gS<_Z@Pv@1 zw<0xLzgikN;KK+*mOHm|`rf8yc-n56dG_e(6$p1(=gC$uh)5q(xTl}~6R!2NnW6~4 zB2CaU%=d$yh`Mpr+7p8$^u`#tKrfwlmNb^{Vbikf5g`6b87&QqfA3g58Hg2(CRMAz z)c8f*P%T&5q}(`}=k%aWGr3bV{Bax7VGYQJzXh;s?BYf~d8M~X@T5H_ww((y#!@X1<=7laDi3mn$E;P5Ti>(AGDoWEg*H7rN zJf*MrVP880-M4ZG6Ql2qHoqto)~s;)zW&%9uKhOLhlnZcoc@RKS;lK}&pFNjA}Fzw z{e0an(gtYQ5q>Z^xJ;g-)u3(z{PvLyjS=2P_9hx7c_KWqp{&&=Y!_deaH{>D7F}41 zxXwMv=LbYgPkIF5JviGcc;BXXbjv*#2r1tWV{dcidU|GH(P!7gpvi9h6Tgv3A;xHv zpMf4LR${x|VDVo@m*b5s;`G*xxG5_Ez7@uhn4q9IJ3cJm7+9Our4EnhQxQ06I$V-ed09f}{ zELE~bIrHYvjGF{VTW)u~&|ZhOXJ zp5Ki*zim3P3*n}o1AAltZ>?9`77nR~bpy6?KmRVr)Sld7{8>E}Cax$6trG9;q`>0F zsE)XR65>!j}t481S7jJ!ms&S8cFq)2UukFf_9{`)PJ6^(m zG|3R}XU;L~{TeoH1pY?UcD-59loaXvSPP7vXs^mz{Bstoj0c>`%@k*MA@Y{wWYMHGbGx*t2$tyAxZ$8TCrRhe+&*&nCO+Vo4G47Vir zzIR_7UOZYLWemZuBzaYqXmz`M} z9IuVBK?XX~W;Yn=y?L*C`>pq;+5R-w=EHc+U;M45j3XHd8ZKE=#}Q@upk2r!tPS&; z7Sj)}U`6A_vEFpF8FBrzX_lXB$&itfc(R+4Q#;0O{P8uUWcIZ6+;ZKQKB~J;UfH=# zf<~3J?b0dmN}s6d23KYLmt6v-_n=D>>1ozXwHq(N%6V~PvRu@=yk<{=P|?1{w}Q_{ zs#4B@L;sg_%OACh8KX`~Qp7dskv`Ak4-(m|AL<>S@Qtz}zLimmcvUq%Mt{enatm}| zo|n~2_haH%e@QNB>pLsAXf31l$D|OwFXY6iy9c|~`Q1B5 zl7w9rW!Fx>0{C#&Nsja8dXDD){}~LMrcuTTCi?p?fttp7FAKw-c&+wRpbMrL_3^@;&N7Eet)qVY6>sU6I_CCF zl4RQ+!zc>)0;eLGSH}-fUl}O-7Nu1=VIBf*Yu48n!~1kn&uEiPaaIUW_}jdn8`K@L zt!P}Y9uciBtWZcDM1Owk@=1dOOx^6RcqRYEH2XxDKHq2S17Vu=mj-|Uy?zwR6ON%z zA@hDof@%mWNHmg>q68W0R!-qG8-DqA!cZokDC*qyzO;+npe%rYrO?g{5*c60OqE?U zPJl-|2&A>zDQCLS%?xBDdn^(t)P~tXlPte<10t@Q*4dhpPHut7M2z_RaX@YA+*YRN zI(emX9$hK#Bu%KuqkoXxb-KkKzG1x$=iXo+(XZ{@vg-lK99^H=|q%Mk>T zmqP{!PcR27yz>7NHVT5;&FyoCI;9D;d#xM*s~!+cSTm#NeehlRKGuMB;5|$WXNFoZ z9uu(^ZET=x5+2&Z9Cmw%CrxP!CLQYEXnlGLrs`Fl4(hIcBqe0IJJy$IyUlB#FNCZQ z6*x6d-u}wsX#5cn(|l`n;-tlpsb=|&U03_+@1-1sf0m&sk#HUja*udv_bo>S_XS-? zOyOWXoJf9n$E&&Z%7g6AT()N2hPgO zieK{v0yI3St&8Z9@bIU~$NaJY3Z)_?>i58N>_)-*n-O6?Y~ zb382i*iTye%-M!Y$7$NNjy|&CudqU`hJKfO-W$&DR`+cuq(hW*IjR%Id3>wL8hF{_ z% z^6kx<={DBe^y7ih9dF8M4^~*-M#N|u_Uv-DV5^m+&r!OJjYt)2j%JQU26cqKjvT@6 zk&?FloiCN+NPjycdBVf)A<%%^8vX1_!P4!oNn38z`PyviYrqcoX2-aIQ7~}xB$A1u zh8|N6QX`mjwp;Cb)VF?vA>P)ur5iex9qu;39tsmACj!q|yERmO?k5O2*Lz54^JsX< zwh#U`caY^o^gMoN;5ne%-2r8^jYyAiT?$%b_SY5!oYs@kwGfK8%D6S8H z1z2or^4;88Hof-Ch7nGGgT>WLt-`q5A#47h%?e_1BK^-&xMDoUXEgqdM2TaJ#s3wP z+}e^ssA(Zv2!@(?VK)Szyx1$+^ z2IZePN`$hQTxM*L_cF_*8BTrlSa1l2$Q4jCA*7XKVjlG`YrOs{g0V)Jw$vfY;P38cjn-~ zLtks*Ro)w8l8UNjBg{vx0p1Wu^ha$ayYM!~p=?gzahWfnetVr)}_V zx!RGSki_2tOtT3x(8~63MXP|%FEY%ns{OQeASc1$U7v@SwmKijScJdvk)ym@xg#55 zK<`p7!B`jE(K@$AP_x2h?vom~(3iqiIyYfqacOGRfs!fd$6}ek$e9f`*o@eYwO@n zWWY4vchls@61}fiz!}~@vsdW`3j+b5$1&?Cb5S*w)WB$n($c&=w(GllUhI@LCxs=lX81wVIec5&8Oy$2+woxR|(&af|~MNUH08l>ZIqHkfD% zRe^o42A5BshV`#bmvhneRLzwG9(bTtL3tVKfc=(5lhdHxDEnTxtITB$Xc2pi;;O!W zzP!JJdFF@kvD|y$@`YMQr%=^xo+#cX5WrX^L;1TdJ0AMg5C#LhGqgJ<+3T_-r3sKt zks-rk!zJ9k?cIwAhbv__l`cu2KGm!GMVWC{gnIM~5s7}it68&Iv_aNxO8vIJ20DaY zoR!UHmyB7J)yYu9^C1f%hbb%mpLvrMW&js;L;R5a-uhz7;}+Nv&9AlezG$7zDiGb+ zXvqyR%U}kZzn6`g?RK4EnhBWUWGhgMInk+6QHn|@)=b{5S|kaB1IL(UnYm10wm-wP z+{B@>)|7CT>jbpDZw6@$jD2@`DWe(4gaxhc|MYGj-!SxcA6Ns!J5IMfIcRqv3O-cT zd7Rd`$seE}&MuXaG49^@m~Q1fM?-CL{g6JuWS)Lfj|qokJ9S)jG*>j7&on7#9#=aM zOyle`_gi}VUYxHcu%uqrh$K#3DC$a*g=>IQY`jg})TF}^GT$-geEzJ4r{s(Bk|JgG zzEt;bSF%h3~J33|z0l&Tq?$jB0Yhp(r!uAQ{kw>z>mDi(HPnMOVDH z?(u68$(+i|bm}5&^F8?vXUz83x2o);qb}+n|3AjQ0<6lcYg-Yd6b>n!BHi63At0@Q zbO}gzr=+yf-J;UnARIacC8QgqLpuI_@SPdoZ|0ltzb>x1&Kx|P=h@F*Yp->$weI_- z_aD{Q=}E9jYS`22?_-}mbNZRfET?f{G{s)}?4L+bsld!u=+$!TBVC|H*@5Z;(Ttm7Y9~Yj$%TGq2a#6CxyyJQ)|PJPJE;D?dv3R>-cOiqhJU zRWeaZswsiHCHKtoKb;bWm@baBXl5@Qao&6z&>hbACr5x0=?o)6p<`t*xa%X|P4Xw#8yC z`{F7~t{kW-w1>I^mMO;?0~nQuEx+#42?NKAvF&dWIQxZEXl7-J6 z_6T(2?Y)Xc^@2Bjg{L!*=Lx#)icd#1txs3kh?p%i$1n*2JzDB931&}_?qoIFDn9Nq z;9MZ;WMVLB>=g6f_p;m^;V_PFs55hgHI`aVoVUNo%8RvBP3nkocsRL`U?5IDt}}Q~ zEX9==_l-1(tA#eL3fBg)gihL0fBpWC*zWQr$j@N`$%oynU3-wTD85lt>CveKyKm5@ z@^S|61A_*vN31Rj^XgHVVb)J>NQM;O7$Yr}9Wb5GfC{0)0@^@S%#%_SdE)`<3Hi!P zfG}u{j?3}T&M-^Qys#AXueopgHn%SU%EX8*2~wxoXDQYI$pa+aTgQll&xSYdUlu+Z zwI@IknXl(UJt#O*d@)Cehn%Kg-m{VmrXU}obw3;Qv}#5^Z8Bm|kO8nPLvl54>Oj$^%?_7{aU{~7kmK)}G`vQQUz#LgUCa9br3SEEHW#!y)LalYEpw8O|# z@=puSo8zT8%M_mm-(18^g~XsIC%pG>?h@4g)+SK|XTSO+x>BY6)B`y6{_kP9ybEm6 zVj?O=RKo>w(t7f^wRh3$Ynu;+`-rm_Gp>tg(ZeG1ZrEW9CLNBv)ih~3nP(VEcw?ajuh}-> z!%XX`9x9WWF6bb2hTuvi69>98EFB~t5knYtp2zUc`(q_hz%^tQnqn|BwXx&Wwib2` zelJ~=9_7LKVJ8$#e{{kl&=yT4*Hv_q%V6I_lOrzSHeNbNZYgQC2#Pt(gAUQwr9hFD zXC5_*Bz^JEIftaRb8dlQ>_~#U(NuAyr z-a63;!7WQZVY+{;l@n!IZeJ~)N--$ABuXK4cl7`?Fq%~L*GkG@^baJWL{k}0p>?ia zCNvz=c6xS|ryX5Hk>-H3>uYs$m9@kyR+Sgy=AesJr|RcVPeGT}N1d~-WN9t# zjkK3mc;AgIO7;QUX}haHaWqA8|IsAiq7Cl#cLK~qxjL2IL0jc99UJbHXmnDSooX7xs+5C^8~PRKc?Yp~hTfV@sR z=<5HVAzX&p0|Uk>KlMwKlW$w+|(660Eb&%&WMr z=K1;U4YLEr6m|_1v)hj)<@a1ANW3kcf3svM@qAJrzeyCJ)meKr)4o;$5ZjOJ~KDXwuo9(f6bQ^v%|Lv)WZ6la3$Pu!wioz-%9I zvT_?=YLhM(J`lWfaX;d!tS6f37uTz=9a5K=fW#BBhd8B>&Sm1Foq~+aL~1Yso8YXH zp!R49!BV?c4n6qm5&zzs5UUj;Ho2Qu5))tFs1IF3I;7oQ~B$NJ)IBR`6Pw z5m@ejQ$btpJ-Z^XF}TP#IKey6`R&xNS%+oDWN}(^){*&M+We#F%Tunj!JprS$}q3F z>?WPpC$|?ng&s}xzEUV&sVg25++4YOAsbEcoS`Yz(c6hnzrxWT9T^6M;P#I7humN4POaW*WDcRqDJmgSHW4s^1ZhZnYv-%U~WK zHJcBkU=>2c5l@z=*n9m9ZInoTn5|jE<}(8EHg)MmJ)j0OtajBH6~39?)Fm$1uvH6j zZ={M-Z|y{XD9=?S4`dc4P`}Tl3OrZ&_K@lrYNwS_9wACuGsTO7}zv>wD9Giq-nwA#LFt!#ZJ{MI-ipM4&2|zrnopWp9^Za!8g&`oxaEQ*zSZoZVU(d+_^tT2xu>$gp=TA^=zw4!} z3XTKmU16cS)gw#uMQ(ui#H3v8?IQAy@``YuIK^;xq-=wGYXg-smyOG02__3UqdCJs zIpqCJ&Xac@vlEiR-hH+S?677_A+7$f6#VOQhNpzAJ7qiJFBqWfP)j&5K3kV{`! z8S`-Q#rWz2575BulpIqZ{+_CdwN-$DzQ{v|vf^_BW>cZL+3TZH)lLKAZo7DSowR_H z{4VXY*=GC1fmc66lxE97AFW0gjrPr?7HquPLCfP6=zfWh0UfN)^7Q@X>MjefGk#5x z{A6P$Jt<4J5nYC})+vnLc`?ynKi_~OG1JIPQSN+^)>qUeH?eN-Kst7O($sI)k}sMBvIF6kp7C$!xr<@)?J!+wbiE>atq9vK7v)ht5Y zKRO^^_m;tYd6Ec&I33v&gT@!rFAg@yp`VD~+3S@$U!Bt9jEXgaMd_%|Mz0AtteB-( zQpk^YFd-a1Wfc3NvA`QjRA%|8dMoQ?7d@tUN*Pzx%i;bEss!3zG1kZ0$^*cEe3dvd z;;kR_<3t_P5Zi17R3}Ep^@b6=9n5+Ya8=D3s9`bap<%{FrGoO&mPkCfl?mp{$e|rk z^JX;s+*fRU)qu!3FXC)*WQMi>h*jAul+u1@M&FTb!vHFh^) zH+DcMJcLERmMccQy)T1koEulmxy0IYPxJ}dMuHiuq__tET@fCmdC^mb2Pv6_OV$&s z2(8p*IbqZBk0xceO~PHZu(U`K{pd6Xw;$l|yuw%6WNmf2>FgVhwWwjTG?O#46cgy* zr2t1`{4sNnwLTMIXAa`ifMqTkKi}kOilrPI&s-$fLa2H<*urXA!S*ku7*+-sURBgT za@JbU45`+Dx1(HvP zh6*%S3uvY|&(tRvW>?4|z2-ouluT9lvKM`|)SpQ3B-oxIt+VTGQopJ`T9~qK8syWo zm#lw@f~({3zQxI>>`0;S^tidPy)xw+=QRGig`kaUpMnNEOD`#xhe50X*WsBIY20H78y})$wGCa!%7NIm80JjNs7}yBX{(5iu4dii5u2zX^ zCMje|w15h$=CRdyXqFKI7+T%Au|`PiqLK9dOjet+4E? zg0;ZJwNMeS@yK>Dh2^+=3Gn`=Sms7jyhG_gTUbzD)@q#9N4;IWJwW1{ zA}$;9C(nYtUTMZb)KO(E&5jr6Q{NZuER|B`>N&$(P>lEFMVd#j#ax{5%1@F3{30IP zH(O>X^Fq8(A~>kYR1R5M^{OhCHK0~xxGW(JH-y}3RSLop74+o8OJ6xxB$l+qj9t9% zbFTBAr2xNh>)m5fds3cnvD83M)EuWP8!WCmA4_fbbjm_Ye=DNamQy0HVbA}{*LBHh zy0dk~^JT8mSP+*|j!~b&+pa!gFcLoJ;uZOK;ZadXuVaUG~(3t)7RVN;bojD&czDn|%! z@T2YpWZk`DK;2`&i@hO=q6vqI70FV5k)#L8BH0h}M5mL4Z0pXKJ}79tpZGO~4V%J# z$~abMsy6cZ7i9<;ybSrR?$?B`a2Y06?s$S(rGAH<_)#7xPpE1QoQeKj0|eQxfI5q^ z&?Q-6k;ta}7>r$>2ViNf&+~Z#5hEr~c?cH+{9TKZ0lmFkpR-N>8_TO?S~9%C$2wBpBsCKnZd<>2xD}43FG@! zj(t@2eZiw8aFrnIwMkMbQ*W>MbN+B?bQwv8o?*lo6~EA{tgSKr>O6EUO>A@(YKkj_CO4F&n6500b6D!sE$I4t*s`_}w^tOg*TYrii`c;c#;R^ zyjHSfX$Vx zjyw(mrAkCNGyj?>GhHMYJ(@de=9o+QXSzD7hv6btA&Y$lT!1{K0^VwrjZi`6H6nV^ zDGLo+W{K~<7`S{{BiMv4jIT&{U1(hK0ch(q-?ZiWM2_)iNHbK11U9pV$A*=*zsoe_ zii}{*G}K8rI5h9wUji=#5x0sKOY;k*?xGRl)$8h4BDqW#SKXaM0Vi0=B@Iyd-v zog&TNG+WcNn1bMJNo)}(i z`H{d9OoL^uVRs;8dG37!>H>pGkLaVpIb6Wsv2~9-MHDjd;To`GECEHQT(UIUE@htC zFf`kXz0O|1XtynA>^tAWT5t)Xj2~Xs4r@cAfNdU^TXN!Rn~vjl?a+4T)02B#EHOMy zhJYB-QMCA#AsCi(1-!L24}K*1xn$-s?1aKglWoHT9bkcgzD}wax>-1n!r?EFmh5v= zXD^4s|F}mV_+fIrrqmJMu@o#RQ6j-=x8rTgEOmqMT4f~-Pr!H(XR|7Q2ETtgdG_&B z5uMU!3zZr$r3NqlZuoIeJ=p+TfPyIAZKR0=D+-lta3`OK`Dc+9^wprI^Z>$$f{{o3 zjN95N62po@-SV39AJkg}tylK$HpzM~Dqm3@&w4j+f^50t!`v7)6jdn1_4Pv$I94hV zQGq;U!z^PVCfZ;^3axXn!ZQ5L=b41ae`<;6i0gGm5D&0Stf!a{On}HgS2voP;N&(K!Y*t1J?+ zz9Lhnkg2m!drmbqmfIHV>nlRgv)c^8oj;7?hr@>2cXH8_qvNrNya^3m23S!XU|-~= z*Jq1rr7W?T7Xz~EZ|x0XBJ~`vzUJ>*y>)&J2m9@TzZhyVKV9QpK+;)LCo*T$!@(9zAW)@i+!j z5d0co=P>9tY3+I+0$uYMz%VNXqr_Sj-Uc)c6wf}Y?g?@yE*@=78t*N%7gYmkDQP98 z=z7ws=ig>skyyu7CGnM)9^u(8!&;LJ?~kfHaEZw zX$QDY$K|IUfo-3B$ z)vXtaQl)^US{k&tX1O?C^ri5sNQU7lwF)EbVe-_7|7B?Z*{gHpyMVgvDIk<3iTu-ZFYbZT7gbu z9kjBMA6@V;s^ZnRo{c_FnDunw1JmFY@AZM1?H@lENOC|f#tdWI`JNz@T0VsaIH)6j z1{jUgqE`pLiS)rrf9}ivqyd|C7_ZO;h&JND9D6s|cf`V`PlQbdh(0_oOtMz5q72Nd z2f>d8wMnwy35oRDAMWEX3ydP$1yn((&{x83-pU+j9lNVuf!E0}^0ySw;b;eFfKUT* zgqNbkmjIWgGraL32?#fir&acJ>om$=ZhH;gl@tbjO1&h471>A&i5I$39O9^zDCes9pmFvSnZq46F;24Xy_im%8Y63Ux5IBSHtxulHi1UccWz8wHE^l?OhH zo)6*Ot3$(ljtVqxP)1$t1+B8=ICQEk^4kRB)d(TWyA@V|hzU@PXk9C5rX~w-t>x;J z8c3+Az9-wxTDto;ujV6h>st5=s{3S>Wd!||!VIXN3@XI1kl^ zC}vc7z|kVn2|HB(>qn6ZS!61p#Uk&p_4+$#%k2TwMzmnRV_rPqbn2mf-<7YFZ3G0n zxa6b965@#t-n9)S5FJktLC818xdr+@v~|2#cKb@-tJR~RMcQ$gS+?WSxyYtLWaxnH@L{uOkp zwxy7_^?Sus3c`Jd@qWEo^jd8KDcQEomU!SjTemlc<93u;=g12a7tJ$S5~$oSX70j) zOREt8yn)-c<+rQj7&Vi$i*CXM6JUI+_ZaWM{OBJ)w|s#}x(e_v%PlP_ue^bh6GB!^ zdS5XU(lU_F~<>$k2V5j2j$9F-!QNGA_TPv z15G+vwpdUW0wH7nwKZ>cDwi*eKaq@!kdXaln4a_@S^4TgAn65Z$Dw}rz3fDNK4y1p z&ch?C;hd1254*E@PYF%DtPURr%{Cr=mwgLv@T|EBJXK60Sc63msO!x^aoT#S&Bq2N zI=U=M+Cv}kn`_Oc0fL_;beJbt@&V>YBw`%(`=!()Z+@@rUEjN(SuYlVGElPA9Vjl2 z>Ua+|$bQJ2$UYLL^6gI6?lHTD++@EhZ!%svD0JTU^A0PK_eG@Ok@{HwOi7UWYw2r1 zuv*v3i(s3KUH!W&`{mQ`-R79N0-}tm*VRBs8>?QeVsBAzOqiAwWdwg0(aBBZAT!_RVC7um^mL?)Aezo-XXj5xiZ&A|-2Ite;;8 zYD@}b4v6@H749GpNNI!79i)J;qeu;9feFRxuYl=~!!-uZ7lTrgXT;@H`v>5vjsc_= zXT)|>GhXMG>);41pKkJWH~GrB$SVio_9`pY0fJn5(oTlKSbf_{k*EFhh~bmhKxc`s zbL-1@BE&1$7l=e40Sm)WzbpHjDMV?)olstaZ{QJcbuIpyA$kX&^Ht2(BJD|cX`!nV z!yE0r8XzCK$EM#3|K72APg-;;YVPkLNCpRzNKK%018``9OhFh!EP@HMT9f=vn>KC{ zhER@^WI=bQ5ZX=|S%?(+ZknJwpRJStOd;?lb_Q+L3MY|5jz3i2kMRU126drt3}wF7 zOLHK&*-%L^e~$I?b=o(O3DQ&uNQV;fv+4S4S|?MYRqZ6VtDj zgaj_apf@FA1mr5ywRPd?! zJz-9}agz977GCiT9t_?S!u&O~k2*qU2`{c6Z-pMlc3D0Nm?76^o11x;ifDuDX=+4& zdtko~A4N&{p%eF^3{hAeoQJigWE~PmubMx%Db4|-keN0F&A!o~WxD>cg{&-Ow!-Wk zfahJeE2V%$T^~9c;?A|*Arkj-jD?j0x5&-*6A1)c*aRu+{qLs$G_>X7^uQRY;>4*R=B;M)}V4-LJ_VF3}OwI4^ z?vI5|!K7hgiUS?UlZ|%+A9Jg`7X0~DWgk2OuNKdqC-GM6l!j zP0)t}g1%acUYp-NMUQ_AV3DFbvA5m?R~j!9OUGMZMP?Ntr41vj_7gtf_}lKdjY-1@ z2Z54@wRJ?2GE=A6_?26tE<}i<2;)^v;eJ=);T+n4k==7Kai_t=PcZG%4GGEtGBehg z4%B{RKo}YB{J)qQW4LF?b zR@Fl>Ne9SD0x&QC?zfhbZUqVewZnS%L{OHK{4rX%u}wWmQ^*U&Ko9%K1%#%#WxNcI zVX03r*1c9Cc&{51kGTt;RIX^^*q_HE%z-A{^55b#A4PhRn9MuU;LD^{qj+|-wZR93 zfOUWt?9#T>L(q23t>7J!P?|D+LMW^AbGGMz>0b&G9drJwQHXDU5x<=D7C80&5?F<%xH|=lXql zMv;Kt$}UNS* zfk2S=m>kdpp#Lnj_o7w740Qnz z{{4c;ZtKDU1SlGoC;*Zo za$rISKkrC|MT~+r1QY)X5e0HYn7M+q-_FBfd#Vg9H10SN!!l>KGPJd1CJ0 z{ogL*@9$rL=;k*-i zdDnFRhCen_FthKoPtUtIC(4btzE_sH9=xOl2jc9-3O5_jjyjP{Vx|1!pZ?=@)8GMA z(=aUt@b=_^hD33IDhQiRlo|IK_O8X^_<~Fk29Blla$8NQ!*H1AO7o5|n{T0Fv0stH zXEpGzx8@oE-lP_c!SpfxL&EUaa{wz5#SVu6JmhSXHZHTyrr0Ny_Yv4QIJM_W+_;P{ zmV&?R>Q=sb2BK=$xeseUs~pyqMHP7dSNINY5S`Bk3_9>Pu0y<$P&qJnDR%)+U@u@{ zPZ0-Vq%os~n&+5;_z&+~xRJH^ISZTTUfcASnZE7ki9w?0;!zEKHaZ8pHZ=R7-8vt75b1j=uv zsYl}-r-)D5aR6W%j}~Z@flMXF zEXBq4Uw5AGzEs8>{N8eJyzG1VRGA#3kA5drmXkT4)40rbQIb1_MYI7BdJjzH7p+Ex z{|7P?^N0}uf{_o=w@-m>Zx03(fm=3~YGI1sO(PO;v6+wvRC`3LLDlmI7r?*ooN9O! z8OZf~5NQrjEGn~@D8ocf`bZ`OsL~U;EMJ7Mw8HNJm9)M+cYuBIw0+E`CJL0j24v4m zFruC?Lhb>au}`WWC}1ZGaDA~z!lvM~fZ*3n!duLTi04fj)d2UY_#8eB)G6^nAZveW zHC^{)Fio(Rj;?{}w^Q@)ZbF3jk)om>&tr?=iITjh$vxl%NZC?_x9z)wc3lFJ&V*e&-&2sfvLJ<$!57a?&2MAtdMrnbGt?;`B6@Cm#Gu7LX?Ec^^c1*cZ$ zR|-(Kh?M<`hyL%6$nJ559{k?VjWJmOT&3o0jF)CpDhdOw(E%@2QID}AZ9Bj`*3%P9 zpPQdA4Q8dt!5pP%l{m_;!R{k|HG1|HG7f7Mad=`K{Yg zBAej4fW#?_*uQOD04HIGkuS{4WG0Yz19}vO4=4+}ku#Gefa_8f#=#HE4$9L% zka+=q#4cC~&>w-7D9Z&q`z9PxgqV;3-w{j*T#v0RMn}+Jkmuk1W)HQm9|Q{cA&v3D zQ0hCsU+9MTxV!|UI*1b%6B`3G1g2PLECHFVvP=dww9lykX*q%EDbsc;{p}{@64@j= zB8WGjq2hU+Os;t3|F-Hh-0=H4kl8xNPe5Zpl8g`Lwuaa}Kwx0!<|c&$^*&ptUZ1Y7 zhJ{k{t<5mpBU>`O0BPZONQBzrP*3UvY=Q8YZkk}JR@H4mB?$AehR-c&GAH;Uk^9D2 zo1i5>7ACjrWNYOA_f`1)9h7vD8Po-kFTL+e;_Q7wi!=vm*Z*(`scwe?{(Mm;Kz~gg z=HM0#q|zGY6?RkkoqGVPz6^32`_@);s10;u+%VE{`mLoRL_spRQ?zBE?LWQ^>mJMq zV(@(xgifLO`0bBxg?~%pFf(wf{fAWPcU$&Vri>c%I{_-YjDl{5HhPu+iGck=>4IUk z5~jK}iuXaT0ADp;=}S}w*erF51N3h5dgMd_HY;I;UP;t{+!PUlKoNvkd#?D4Df9*03Ap7DbIgEDE{l%6EVZ=(iHUo zMa1D!L#g+OTy8qR>@`8=vRwu)5uKP%62{m*17%3*{kPXfL>HK z00l>eXc6sSJq!3au5SYllw1dv$)mjodS<9@FDG#&Ai5Q%(T6|2^@5(-1EA1ni5UHb zXdxlq1Eg!P2J&t|wVk5>6@$kucrbxg91So|F+!jNfRlj|CdcT`cu27W)W*`s1gB_%cYOWPgkV9V zNG29Qdp=;boNoiJ%;I~bLQ|frI5;@nFcpt=X&FJ~2C{!$GLhOxQSp8}D~~)uCu)j6 zIP>L0^aq~4$}%|uPbgLUutx~&kJK$#FB7ct1x^zjq>+xH(0=ocvEq1u2-XjDD1c>L z2J-bb)7ch%>B72q@8Qk41ni>SW`6@*hFFLfO)xt;*hJ8f7U1xg0I8{cHiy*|5AS-; zyZ@gJhtcIOD)3AZ50{vtTn(Z?l>*9js4KEh+l4LYe)Ix6%I?YW?{pjSHMBZLs0mH!uMFK9&bhrV%_eeB=e7 zqZBRVd6wgFY1|vf+m@I7Zlyn&8U}vU`4F_4Sk#Q--eXr*N2@%MZB{hglMzJ55+&i|yC zZ%aT4lq!%RGN}j_nNMaH{t7J*1?9DyJZeE(1UuZG2e@^2B5pLiM~#}*R?6ispDtpX zJrxze%(L4G@pGvigo77>E2S(kXh*39wT4ueXCIU$K=ea}NaCWmxzLUD?|BC{7wn39 zDJIB*Vbye4#{(EBih*gWf_RN8h}bCs6sTznX_O!esG7C>u&ov`&6eSB9GnA!xd&KW*`#U-0{Wu9oYWUEdG4a<$aTr1i}&%5!MhAguR4^@Y!I8 zEBg5eTGV;Yfyvxh(4N)nwD3E4^0y}jp68N33@^~@*U7+!mUos#iG%2=>qD#kig1Y7sa6D09uXY0%mKG+@0pfAaX6vw0>fg`IzrF54y}3%czg^|;hWC%JA@s0M z#uB+p2Kt?($*q-91NZOFmWleWZuF1a13{lF2>_}N;NLts1ZMe=9Pb8_`E&XH`Gv1K za9AXtfMyNboxAs<0PMgE%2dlB9-kSxqb)6h%mDB(m|9y&4Ioy?QOcHF68rzku$N&e zyj?m1(*Kp~|GC>y-hofF%BjuZ{B^_7z?S;{=~2k%+D z^~3lJ7xML^C=uORsYJm^apwboTaK0JG_iFca2~-eYHoAO(DGTi>c}sv%@tvOE@sgy zjzXm0vL|DRKkVX#uFqqX4{3wrF->*A0{Os~$z_ls z>;YY<-i7v1ZB-zw8J(3y;Vk^4BTFKbh?U?9H099sk0e~%o$fD}*-{GGJ5Pd|5d#jr zHjW`0q)V{Yo0Qxam0yK}04nN=&t?=X zZVZ|_hQR{DkwGb>3jyi zq0Bnf4ao$xuq_MmW$ZWlO6vPOf0$>;vvJKaW#TxojXb9~-OS!^BPiPL=IsBxs|Y1{ zK0K*YwtP%kgk$XnLr0L(3u$uhcr;^fSy5n_EH#TgXx31Ag1>#|_+5nPTuSczz%g=t zWuU7@(tIA)gS2w$+Z^#t+RgZSPdORSV)WevKDrv&Ql#G-wyr#rFWBEe-0Spg;iKs- zmkpst*t_VV4r7Fw1m17(gTb~E=(J&govFv!7JnQ!Zk9tCzH&ef6krm!KbM2wmRTm7 zSyQuF&j>t`*v$dioP*ctDahE3z_0_G`;o6n|djY}_bdX`sC}7UXe|wYgy8M2rPpi9vM!15i z7Fg$L|4V6RXWcB!QTJsz_&pO2L0!3=58PAx6v2~%*p2tVVIHz{eWlgEgLhxwTAOKz z&AYlH`uez?KbX|_+AKy#CZ-q5J@v^?CswereH3Bm zX@l@3gSIFUCg04#r%SkJ+$amT^<=*A7Wtj%d3ybbr3kXn?qNcNtk5(@>Kf7SM%jP> zrDdKR<{*Muef_YYUnuKAI7$`uo-SCtWqT-7JS1&;9cclUiNo9QvtdIm36`zhL9Wi` zu%_q=hH=HMVG2_?3`*gCE~?6hQZN^pD>Wx|$sVC(9+p|q1bV|#r^_&*x*&T8%r%-R zJPsS9Pu-3-&9dT099<#M_htbr&6u%Cmlb7otn>wU4zOYIWUifFkWTv{?_|Mb8z!7< zogYu2A+cV_rs>PUC*6hb{@XYm!NW(e0& z7LI5HOdr~mvVF+ic!SJ^xaRb9BWa4k6FAKBL85HzM3eW8D?jaJG8q6EeCc2m3~u+K zA^{Bfks8!IEYPm9&_H$qcmmLBjsw_vEE452(TnS=o$Dn)Wy64R*9n$M5_Zn z*8{$nWgwns8@O@}6bvXpsevVE2@syYeO~yY_FSJ38``$EiwE27(APfN&s89iQb|Va zxY*F_5wLqxpA~s}eRzNulSy`^Tj=jWrsO-TOixx!8z9rAW#27%qCoQw0htM0x+sSZ z=-iA{bHlc?pb18N&lD&VM1$5lHlMat@2;}5ya&C^p${G$Jy?C%TBAJMiB}nn%M6F7 z4ZWwLqdBs=#uhdcl%zIPgR1c52|>Jv<NXSJ)^gv@uX9bq)I=OAw^su3_J3s zwPgaMr1urdf^j@rZ5tTofwZv1TxiqzYp+Efi z&lk;S^xAf2p!4-fy#9@E*hT_?Qj^!E8wlnK#XkbwMCDpLW7mZc>XgfTux-nmKouF` zz#JC`=Sd`qAbeX|n=%HJTskSO37DE=s{`B@QqWuS_*Bz-_cJ0a{yy$_01^by)KFaC z?6~n9Y@??kysNAgmZ0lGTUeB^s!L2%AQ*ERmLOzUAdee6*7==)ei$S0`?8n)1iY|5 zxBTpgx1ewNNdPq6dxzMd>j)I>$6~Soccg)CaG7I1M4JIqXxTYh^lZ zZ7H3OoCTK-#74o@f~M=bKO4pzeKUg!bgAyO9vnSyaeT@X9CTd6#~Y|$q|bxq?G^Yc z-7@4(aLBw*jaPx~>yr?B^e-nk>wIf3+`90U>($5RN+rhdbjl;r;(Jm&f)DB*kvtQVwB{^w3XtZ9lOL!5*3&SJc)+CAfLQ zxo+4)G&Sa?E%c>i&Z#C4;kKFc$8||sf*$jjV?xJp58wU#h$7Ys>x5Y2M0Bq_3r^bx z%>W*DBfb?zNx*KQeRpzOTGnvJK8zm_^()~x5+1~yClWKCyBRC3P&T=wf40#L=H67% z<}!7AP3pEqzC)a|Fa zUPQi{s3Fy&Cl)0djPqQ5cc>#IZG)fTilAj#o~|${m^?}IT8^o`nnoGO~*KAkO|EFvh?7M3l9WKWo`V>BP5QWXL0|ffvl2@L4X=uVmP@n37oT zJDI@bZV~drs|)<5@!}+#$F8-{A9xh|AYU;*zO-s>oY!igZaI{m=34ftU8M;-12#x=jR8BncoKFUT}fW=#YUABi8vC*6L!6{5fa&s}ruO>8W%96}FQIY_p zb}vFQM{XN}aAF^{QpL@&fs%Z6rc}tCG-6GoOtNj?Htn0k7WsC4f&4SbHNYE|BfT%O z`FnyrWkE3>JLa|3#giOHnb@un?H%lsd}>YSpMX3)E7MSJ z(JBuVs#Z~Ur%_kYcHX4&Yia#+xVz7~nsQdJ7?t$x0(9=g@((^d+S-*LF^vD=hk{W& zoog$FAW!EM)PZbUeqY=$3l1Ci>pR4PK7qkbbC05t_CXucOU&4n{EB9k;vkeo6UV(W zF=HKcL7iD@GN?(?An)#*+Aqb!R0Ub6IF>b!c-*(-1dnMPQ=)j{tf;EEr#!}W3!~xV zmxZ)I8OqOuHXYRwxm<3f6OEr(bZVg7NnLc(1ue)_r?)a!GcUnKf6e)@KzzA=Y+i*>wnF>?9YZ5 zh~lZb3Cyy%jNt%-dx=$L<#^}>cb!dX$1zp`I)Xvx;fL%f!`+-obP^vJcJR6&aYj>3 zI}C5>=W$e;IehmdN4W0LrL#wC+c9Djd&A4Y&@DmS3Q`Vj39f@=VrGG2V#maf$HoMA zzT39BU!lA0=tx3pUas>#Djr|eBb-HoRMESkpKJ;n*h-|C7s=8Ep4PE8oaFhu8#2v* z9T>vK-Bso)Tmw+tn$!-_y^86*)V=yB_p-~pdP{H0+2Ye%%O?*R(W_kG9`l~MhxZnH zE*zASxN8miLbfYQtjCkF#y-0fo(?j-mLJ}jBixYxY1pIhAAS+$;*##hang1j9=nUJ zcM{Pqum!PveQ%a}g@0z_{fD$ksd$#&6?fv<*_|H?CQ5n4B?pu6Pbc4V6pVSaij%Y* zY@;t(@`g)CGO2(o(f*ZK%T+_jf!|vLdqLM>+5`n^ovLI@- zCJze<_Z}%i{7%3$00S5^bCM>!{iWzu#IU#rfYhy)cYvBMGeDo-jp?{EQi*y1gY^!`d?#x=-{%f~)ZK@x z0pPmq_Qjj1j0=9Vj1NbYDEtC+l*e-nuMl<}nR=s7Z0k?LbWpVbq^z%_EVP0H)%}Ws zCVcxlVTo>Ts^`^4+;2C}$8Mlj`uy$6OnK%_CZtKNYjVkh2{Q-W zw=A|zl=H|)lm?{?u?1c$F%XLi^c=i4&z`E&IS5G?v5u#OkSJx68qts{$*&AYS(7Iv zl6$lj1(e|$WLw(O99YgzL}-pXJpvD)2Q@pQ1%w~HS$*91EJTU2b40#Y2hc2{n}>0* z(PgBRU*?vlnt7F{PnK*f;&0;Yl2jn<8O`E(?TBc)poPBnWWW*?c;!{Th;SRD@q?1n zUHm|nVl!fBJ_PGf5XqLM@5j1mjI|Eyv=Cx0^d~_a1}Cd7i`#uE&U$CpabCzF*~PgA z*G{Lub-c6EDx?}g21|atu5xD3`1UcjlMY?yrnOOU0lK=`@_oeF%oCDI#vlCn;cX2D zb!uNL+U`%16zmnO?m;*U3^_=~e)yI3502(9?)q4_s3Ppi&2D%Pn;c#Gtd2(d9(!$G z#4#|X#&*-zx!j-Si+n}YN^AOlH)1sM-kP7yyJN{1NGPP zC<{v6!=yLyb||b$b;L3fPRQ-#7PynkEK(20lSp>;t|P#TL~ z0I9_Ci**HWyH-5V2%KWqL+f_}ka)E`=1=2#OSi(vZV?K)Rb<5T+!LSB0VCY<#lm4W zw=fI<5zzoEP@+<3G!gJ!)-Q33zv_ZuNy)8 zs3w=y6b-Bwl1$66++@%xBJmQG$>q4LI~YRiEx%+*z@}1o_)Tw(gGN^SE^R|qqK3#a zvnsL(9hE9+O*Ll!v|D&^7-^9#$_KAV@kMewa1>3-cy>M+FlV8+wUy* z=<V#_wUKwaqyM)CDGOqoxZR?mr-=xRvLhx?tCqUbofgBu2#UuBriQ;a5+5bihI4E3&hXqQ>8EthfF z?yT_!k;rr%)L`y!QM=u1^!q~3Bn=sqJTu*;0yc7CfB&|4Ac4E)V)!ar;2VYdXoRU< z3zCp{t82isl?>ym!M`@KF95szmh1nX(^U`XTQWtwKp2(|fCv;ujB zL5<DXr0Rb!z3n@j(6ixqB7Nc9MwvFe>hA)fiv{U#=t*$F?MG&GM+k1TV%0jZr0 z-5-AXNqcB1d7-qkZ$qkd*Lm+?EpxT*6NZbXdfuP4YAj?U-C@u|7e8IZ3p~7195emu z>ztHMmbP{NrI$A@g6yg^E#$&%6Tgw$WA!tchhebSB+J8wX~oY%afOzekRa)>GR$ys zGM%w6oOUb(k{SANZby^g@EiOZdT`%0un1kr+qC5k8+=Nb>#TlNeu%Z)l7c|>3L){T zXjgkF_g7CRiUL^&((IV=m#uuF)5+_;1a%#rJhQ_g_WkZ;41*N9h0iy1OU8mpxoI<9IC0R)59Z{v5Y|~ePI4kZ;A&a>9xZFKtX*1Oh4AAW}cM>PPlg4BAt{TupsQ+l6HVqvwhhf>BWCjg16;JIGf(_qJ~uJ z3%Vc0fR2zY+XricpyRm&*3q-wc&uYGxw9IprV|a5Pv`Y7fxI+J0QqN!9t}Uc02N)w z(D{9ej4?79@gAw%SWB08R$mSA>L%$s2)y%oxcmksexPR+SOTLh&T21;d2CGbn5Eez z$wnzUv`0l>zE?q4NInia^%V~9PHg(aX4@LE3Bp6Cq#kS{gKPXUx>}1bpTCfH( za(HNDpx!gkbl#|0G`$>Ou#T<^x<7B8x?=H?z1cNDMk}MbW0IMX_0Ypp@HsCAx#q1l z?r)^A$!aZ~o(ufY-~~t)ne=I*Hf~m_9Gy5N^GHp&{QsltJ;15{|Ns9K*&HJ~onvNZ zkL>I{Q)GsaO|r>|V~^~aO=V=ygk$f$$*~F9oBvbq&*%63e7?Wm|GHc#7hcZm`Ff7W z<9@&0OJ&c3d1liH=}Q8J?hhLEr35Xq%$)dh7#~+Nrmyh9&R(C8dt8ftJ9&dx;0W|c zPZA-01(7Z2*z^)VEJoI%QcNt)y-kP3;=BG(n%X?UjfDOVe9~c6L)O@q$o4j3sG^N` z+Z^Ls$za=BuDxmJos?;h6xbmX9lvWHr!lV zU%(7v#)Fh<)iJSv+Gn?!7EqVi;B8Xudd$`n^j-ZZ99&1y{6?m@(&Tsb2(rT5JyGyx z?P03_KF~aAx&Ko~Jd=c$pzQ%0+N;|f)WJY95sN`+f+r9QfewNrfMImqO1!|3@8?(p zU4(Zn!OZY%WfbHduowueU0v<^B(&l$Ty3aG%qqt?Hu?(R`Ymg42Jc-0r!q-BOd8bP zQv<1viSPW|04DOpqV;wUiLRa{bo)%lvVn721PxpaAaNam7)T)67F4x9qdbsl-kXki zD71Xr&qTh~nz0;M_^Wom{JPqs3z3a1=nBTd(~8M@)~yx)GGe(0@#^;dcmXC^!fKv2vD7b>H9+ zQxgcG41J4uT^9N;(N&|@xF|#q%<@`<;uP3b)qLwAb1%@SamDPDsci}EcNfj?KRVLJ zOU9c1#eFOs6Mi_wJv!HT7Byfze|UJXyQUrQ=bC30@8j)tGdy%PSEylrJB5v6Bb+dotgerVk6N|JpXu=;Dmz0efEvl z$eCAAqLVdeiQK~_8t^?j4E^)G^A~xHY~3ia=-z>WoFhcmt*FMYMpfc4DU_0_PYTnm zkg3}joQu=D$)y+k*H_~XM2J1n`WG1}C1g9KE*EJL6%yGcjh@2DSNkL^s#o$?NxRCl zZ`~KhCK%HB5gpX(KXd3Q%8s!+6GYYR({{$}UoakL@ridzK?aUJM2Nr)cX=-)_&m(` z5c<-`Y`PP)4pPm@RyqD2#w+M)6h*Dv)AqYX~en&2nfQz0!6v;`UT`y{)4^`nlerd-}KXNKOO_ zpSvf1hNB#ffl1GnK*iyG-o&4C?t53aHaXkY2A~X30Lq^RgS4wM5(Fpf!mJd%bln55 zc}ht$Oy*Gap|@XNgdR~qJ{pnbku`GLl%qKu>TawE+FnkJsB!RQx=g-X!ruaSm*0|p zWavGeWYy5Cdk@}mXhAdc^CrTu18I5qn!kJtkVF5D7dU^T@7eN`^YC1J7yl(YssrOM zva1g>&LrHk2OsMayJsG&_ko#Qe@)T3*BoqQxY}%g5sdc?&h+@Cu6l@lpMI121!{{e zk#BYVbDi8fUJ0WNZI6XFOw+67dr%U-hxS!*MhK;Qxj!eX!jrQ((N>=&ja8tJd$P^7 zpu+SDa^kT&?d?>VwtX4M2nl~P$bn~NV$tBYi;-xEuMK314LeOoZucFE=R(JYte-|u zhJJQ^|yhrv>mai!WT*oTL!;_Z5!rCJ|*E8QdJ zzLJIq{$Z;T;$iF@%+Q;StTloG>Gc4-)^L}i)y6~@pUnOEb+LO1IVq2lZw*#?#v|Id zuVX`mcuUB+TlfP{+Y40Nm2?bVJiMeRA@dP1`O5A}y{Bx1)B1g>5hrvS@)#VhW_FL1 zKt&4ggi@mU`sQ6_-lDwr)9ITB9P}uwn6^3IR*M*Dh|*jw_got>j&P_<$lTt zYTv{Z(WEIFY;ZiRa813frF92_7KJPU;^KIl1)G#zNwDlzQIfauN9g-Ew7u`TLmxs+ z$)qf_#PduN>+waXhPcNL1+cL41ZXEj&WU=b zeXEf1c>+9z`reK!vho8vo!G6ZUc2?i@OF>W`*Lr*X;~-zTqmphX(_ISf~~|)Ki>Im z?m&##dMnk6kh~Dp-okSq%6n_DI4t@|vpP&EAW12_O7Tl3J+!A4en_z&(bS)qXf!H!~qlNA23(;m}sgGvZAOj(K6ZgI9I{_OpHs6W&I9Qov5eFK}z zY)Ye8|KSSj75-OIVT3+SOfuH$yKnkVAUapQJ1FFQ6?Rl;dnCy}CS;VBsw=|MVjr7d z382<~#6)f#rp$h;<_C35rDelnQS>UuQoLSN2 z-a?jiqpe32L7zA7{663Y+r2A;0VxQ+d&$h}suQn2=4R(IS;BupR`_V`JN~SdYF)D! zEn|d1QMNKSd~fV(K|%1}enDt8Di~Bgz<;#ti%xCdX(VS^zgEc^E-O4ZA4IUYyUSUqZC`2YW87%;71njmy%TmKdd_nOLdp~y~Pc?%bm*O*) zWA&{H&@a=@IFZB%n3n7D11_g;=QxO(@LzI`ncPqIuYeHoUh>PWVH~LXNSKb%sq8=O z>MaQfs`%B2G#KYlYN|$U{&s6r$8@jKen*w7$UDa;NoF^`y%-!a>|U3KD@1P>miWR7VTE|;}p z%or4*SJN@Kwp^Y){F>{=^vyhRK~Q}z%7@d1>Bs$>Y^x@jhh%TbUT^JuX_$kVvv^%1 zb>#e9pPGe;U`es8%s)?nf@kD$tB*Mi+%R`fKoH7)1~dpX)QO^5DQ4(ta@ z4DbZ$B)j}LHn?HF8!0ZE!bn;4g6ISW{`dKhvK!u3jra|uf5MIDLqjVr`403FUPw^s zL6NfG+q$u{C~=fL-s(Wwj@4By))&noWt?w8;2Op1fJZy8XQMK{@ngV@!F z+=hH;4pD@lZq?iq_QRJ8)hsxJP0i;t!VjF$n|bVix~T`11}(e;Vx*^|u74%Wu_C@$ zVuf*DJQ|_CZ1DW|c>=9jlBUO4$ijdTP$eVhv50aC0bd}L8LiD^0yGcadGBa*AoF-d z6EmUb6b=xK*#Rjcn|C6bRk_NgLBqStVo%`jDFOGNQ^LvCgenL~|0P928+3VG-P9+5 zGy`)@qxP_6<&9wxnHyAH@Gd7+W3SJmWLvsPbviXZ5u!CvsoEnl@Jy0;_yNLZh_!$* zNo2w9rJah_&at8vB%dbY*T4sn3J2!6gc=uuj4C?(&c0~dE)6;PB&)PiMX8e! zuGB-UwD`ez!gzh`WA|@pd5}_*Vo!Rq1U1plarr}O@oKcTV~WVnun|t%PMhF0s+C89 zG}UbEB8bMbWAAWAsWvUvezPBJvpK_(vvA&DkkR`7bRXVt4(d7yXYX~V&-l|$>M^m; z+AoNan9AB&=Cn;yl4n^s?OvyGl8F?k*sMv=9kzkAPlRH}1rXzF>+el+1C<_)(~D;| z=G;wFD=XyPs~Y-QlZ=~~xFJS`o+$#10hf~}d|EvTN)+W+pC@#(v3Cfv(Fh;w4`Uist)%T{5++WQF-q- z7unDsDQbyOTh)|+T^moAi=?XznoXaNX%vHx2+eR?sIpg{J!tw_zAPgltOzCl$6&za z+dz!SS58^QQBB8V!O5Nf^89NU>K?m(9eiUhtr!}SIiKOV-<4Ah3~)?Y4SO7x!*t|g z-VKz7JRymIsBw!ia=uU(oAf?NSrCvcY;{1u2^@hdsHVf8@9z#DLjMm|W{U81P3(pV zDALP`f?0}do6IHLGoIm_AA>YUPh z%z8q4CHqPbukjIaP<+hOB^Y7+%(ZG+6x%AC#nH=+r!L%SEzwYNevncRrYcelfT1O@8~QBzYt2U z?$r{37)ASN@YZKeLd?QXEScXlN%p!GwzqkcXc8c{cXvw7I}kl~VD_gP-44u}FO=_f z-aD3-)EfEV=XYw$WegUNmb=$1i(;QLrf>tZu3x+?LYYf>Y^A}*LV(Uw&|aX_uBI7! zqb~u*A{^(h`U5(DyNX8o@k~)6)mz|PL9S)?0zs}^&sNq>Z*BNwWebzQd%{rRw456aW$ILOi81%#B5%(&EJ+Zqc6VLr5f~EtBTNeMNas|@3Kaqjot?x z2mRwY{v=c)@7+++C-Jv%iF6LxGk|7jQSBU7r-gg0>3fQ^Z2pE-f70J^D=IjxXD|I6 z!lk7$R~!dh_rm^~ub2qM6Z4L9#z23TSqM>Pun@`LYq`6X1!@a;h2jpv^xnUzA?r3D z4PF@dzkIve+7k!0eZgw-veU{Fxfq_{azpF<^Kz&C(p`CH5VWAgz}N$I_VGtw^Gk>< z3EG;r^V8>DoM$p)tG3%w^WRbxAN~PtfYUiF$CSduw!w<*qoi-^Yn%u+O^I3CpRd`8 zo1w zb^Di*(DYRT97XjAarkIp{+{yd;XJv4YFSOW+#mrNoOMf)H3?1cNhJGAbs)C-0~=}7 z)SS(>^!&3kGP_{symdd+2efjJPb@~AW|-6^@OQer?Ns5AaX^Qit%m|c5VWvt#@k`` z*!i!myuANuPvg!lPXy3Ia_e{J06RVbU;)&}i}kmt{1WGZ{EKrJcSh_IS#Jhp{eCC1 zQGltW!d|;fxW++Yuz29jY` z@BjE}OGNk}wqV`Q^{D)^&LiT<*e?i-PE$-oFpj9K7q-(zOd_uC#O2icuYKroz)r+gk$dKEg3zWr4** z^{r%8JEI(;$^sQ*CN|%e?5im8jKtEgSW**I17#j03N?Hz!=R`e+93#8q#aV6t+LLE ze3;&7bE47kti(#psjBI-P5s?{N0A%;^cwUu^I5R9=4R7`puak`C~%NnBCX#T(mwJJ zq<-`A;@Dl-LcqyM^<_2zHbwc*Ki@9ZGqyjU*)O7>_??CJIbR0wT`F=kX4pq${CdbJ zF`HsHLqF-(Bh&fOLVQp>GTWM;WR2@lw((~eHqOb%GS-l(wMCs~Zj+QbIjo&pLPVqG zCzT|-4k0|hnv-;mK0BYG!_)*h%_bKjig%eV0s+P*-UAzw?o_yXVQxX*GTt3dZ}X1f z!x(+(WiSi(2Tmd$X?>UAylIOabedNu-y`XHa7s?`(1@5kEOzlhxAo0?|2!@5qp0S- zESdyBo6uD-K!)z1`WRStY74XavXL1y*Be*y7H>cu3UK zx}Qf*BFB&Po3gF!B8hQKTtcjsQTTrDqkp1|7P`%t1jTD&v?OEPa(|@n zQ(!C+%ke&`PJ#!Y+b$Blq4_2w-9N;T$mF*NnmXKO9oOPp=D9?9u-CgYxda_;;a`j| z`~+H#L&gen#8l=$gOeG~|5i^e8V7}FmC<`T4)Modq1(hc9E;s^#ptEQOqRCe)Y|e) zRT}@`MSbSHIIceJn3x8&;yasA#&zX&Mq*Q1ugl4)a4vhQ77^xO$_l&_SFM*SN;Pr0 z(1^#T8hO7wJydLeXEPqy9i@NWDw7{UpAF~G(1{EmJZyfNw5@?pR@9P;txm;yqL>Ol ztAL$Ot}2HbZtW3`N=oaOjJfuXwvjQfsmt$H3Sc7PDf|mG^NfWT#&t4J)^XicOE${1 zs~aUvI%<1Q@*d2?jt;4n$ni6`Q8NyGKXCUe$TqxE>(3(PNLHrRn{lLvFHy`_$mjR+ zJB0f~cU)8pm-#(i#37vTQ}dLu=L&PJmPZ8ZKAVF|1FFMmlU(c13$OaX@8Ty8Y$ob~ zl~o^YQiFDBJ;jpRh0wP|e+V_i_gz*=EeZ1x>}st-WK-2NG94BaSo|zbKkgrk>-%Ic zX0f(k42HppK8A`6qvSRDcBb`0t4uaYJTo#;CZp@xh0c8H42pN;QdEh2f8wt~Zq8V2 zPJH#|@SjzWQ0yiX@!F#A{P=bdTG7G(I%=gH8sV}3V`Qt4a-Z^tw0beJG3?Oo`Gke| zuPgTcc&Mm;EC0ebhKC#|T4v!LjPAd6^n2x~H-9H)K(8yQ&t6_l2f9#F{Q9}MIV{s! zQIxzxs)IM>UP9|bn=x~L&;5A|3huR9@#Oo8x}+0|*=|ek)ahBFo~XB8yPoMoh2TMo{LEO?eQkYHr)+5X*ysz*|HF!T^`d z;qr@n7&v8{XY4%DruCH4rRiwIU73rWRvsGxO3fYJV*CAlDWL%PkW1h-=`DcaIdL!%G}Bb(x@Tk=hgt`&Tdh zKfkv@jhBJo*A;JjX9v0{i6_op(kE`+qke0 zr^rr~Hrbd8UQ)ki`P>|{7dh0SizZw>e^GuiWJHO}WxW)&@sE)>O57Oo_@#s=z^-zE z^B7~?zYHVFf^GAj2gaAxmQh2|U+7Dy+EHA}228gfo-n}43XtqcX{4JU0{Uy@?v|eHZ=;8l`K{(vP zMA1Y#8UxdR-2$ii=UrPpI;Uh+cW+Tv6lC__r2HO{Oikr#Vs7k3Bhj%MsRL`fALxQ1!q#J%%oMi4w#x;r{ zt<_204ZjsKwB8k5+ts*e{Bl|GT`+^$)8;P5y5xN0%!Jx%LR=>pO@u+~5sWM;{qd@R zJ8EY2eRuYxbmI9Cu_aO~&{QFsv2HS+DZqIqokLL6=)Lvj9&`E-?XcYsn;ZgEPws_! zFHz>3p$j)Z>LC4si)r7G3i=9wAo zn3B5plR&A3o1fJk-DJmbX1J?qBc5rsjx2i7fsOxi7$a`}#n!>A5my!CMv1G}2+TuB zd24b0&V2h*hL^oMJ1^Q71!UTO7Cb26IOeYJ$XTEo6Ie6R&x&R8Ud-P*Hf&^!J@a0{ z+CgjF|L)4TC*B`wl@z(QD(0?w@GhL%|JdoCu}AFMT((L?X2&nu+YS_qLh~-dK(fzwwP#{v25P3r|MZqV%VF zxf=(C)ZEWhUV(t8`850u2e=W3u>WJ)1-ais5$FEGKDp^z{2?CzEYU=YoCl&)h}}(i zL3uA*{@qa9Kv~=Z(BUn}o{Gwk+25z&I6ErlHRc_%kDPc|8azxkMDl${W4^1~@{nBy zf81y5wOIM;`O9o|tobh2;ucnL5ZGF*N4dLzr9bXY^C6H=VnwV0^lLeeJQCL~P3w<| z+1pDD?>%?wwX?x4=|c5vI#>*Jc}nqR(PMhxPk2}$w3G3%P&l~+6)w5$Xj@_u_5EEZ z4_gNwQE{CxJ53(FO5E10fx)d5b?o0JowP4D{K^J+PFs%b^=H(6&_w3FHjog0wd?Fu zQixc2+W6@5gyYTWYq2?MBm=9bOJkOG)PQ>WVq@^yqwolh*OM7Uvws%wvRtE#iNB&G zN4Ta(KN*AyC`=g#1>Jw`Gst1BsNL^?=a5437d{E~!65zyO&61gP-|i#7d`i{)`6AX z6nIJcORJTWd8V>o7>$Ag4s{&y)n6lsH_^|iwG8j`LQg>1-3R7;RlKL`P+%(z90eXi zW;$kEq-&73Urq2D`zmVC_#%&tmc<9+?6{&IDd>DN>GbD ztIoz^t%8bbeI)1kEqSe4>B`vr1_Wz!|X-I?vx$8tL=0E^v7={QUGtNB!A5BU4A z%{T=~TB31H77LXTBSLr{|LEuA$14Ek<~PCUNfjnfLh9j~fw+Y_A(2z{RhN+Fk&S7}78zQ_fE> zuUx}-|A?=2h!>P0vB{s-E<;9cs*QB7!OAQ9S)gqU$}RtAj}Iuiz&s?t2}a%j?Kd_A z7wYwWF#5I``dac%Yh1E%9d|HsU{rVtP=dY+A%5=(0GZzBS(jYMsc7B%xlff`H#!nu z(E08w-_hhS3Sp^#Q3La1dO|G+A0flN6Rzhc6Wv^Zl6ZYb+ptxU&&+RWXsv@=B5jNk=xxiI(P7D#X!RTVMl*>0!}tRUargCDzU%AKAh>= z9pI2At1SDi5-T%)vrdx)4>29N3Ng6;Y_%)^HSpb6`fQi=f`8RlOjlxb5UsKC#ReBY z%zi5`M+o(4fB4%(WMR;_Li^VRo_R}0KrTuU!j-^(n`#|`%TrUqB$E*Sef;X{W3NK?4IE!;lHvtUII`Wo z@$p0s)E4gWcawM~4ZfpyBow?Oddx5cZpNnoBc9vF_Xku@OoTGT=eY;9aMHS${YUMJ zRFX{654+(*e{TyG{7xXX@;oE+WgzFM#cY_F_pC-v>C!=>w;`*7rwPuOv5OVy@%H}C z?GJ;R-F;$3e&(BA$*QiMeCH3YuO&YFpmS^DjaW9+RwLZ%wxH2@i$O3+H~3#B@(4F; z^2Rcn{}Y06mSS5cPr>_E>)*gI@biuE?*a|W2^{+HpG*JG_keFtv1l{0LaF~{T|+s+ zlM@6U#At*u{_QsaQsOPO>OXM>rb)o<&3ezw{&xHE-*5i~lz^Im%jK5o1n3?g47I4v zjEdJv|2JsDQT0QM%ntbh)_?sdwQ+FE5}dLAoYSd=+>`u*mZ)rRAj)sn~B6n>|-h-yFpj{$rF9X^|BIz!LBkDg$2HQeOmBe>gekR|oW z`#)bx@HrP0)Z*{C<~nSGfC?tS&5gP`o>A2WZcU1WW#0X$pMU^t3QpK6y_Ed6th{eW z|1@I%&oh%NbLT;YA!D(&^u)_yUadWvZ$;X7#+>VuD-Gc(Vw=irsu)b(ClhKcO)fpG z-m=-X+iG@gb6DoUYZdG10G<+(b?i$nyO}UxSKZp1){12TB@-0q zjzJd6EGhQGzqZ6tjD|096{-wU9~KJjJ+u+&itkaYH~Lv|O}uHSE?!#U?w0YiRJ6h` z_)vd}{jPjr#PevpdpE>awiVy=vy%Dx{>RAbXo?*a(VcfRfS>e}E0=Y{{ASv#(t0Kx z<9$}VphJ}%k0U=r_iOk`wRG4nA)84D!@Qx*q1RZ|&jlR^l~&J?nI_%=;nYt4wYTY( zq%n4UTj97W%Y6)+C3bMbRww{IfjAcy;5jL(O-*%020MbBB?VxiTmg~cs$YL}?4$^4EhSU+x!Du&{5US>*})f?8(YW>FCie7cWo0Ef1 zpuWsAP2h01Xi9sGPO)*!Nf1zB-TrwH%|Y(6+UhJ^MmEm5_C?Q_l8izZ!$lbeHq9<$ zFt&-su73{=p_^mhN$l7uqC80n(!nN@>wWWNv8k!dCU#k;zY=(h7ZQ1Dc}YX$zdtY0$s{|1KuFkc)1 zqHyvMS5Q~KiVAWc_Xpkwf`7aZaCBd#HkSGzVnje_r5~xJueOrbVHUbmpX=;f6_dTj zK--hFhUaJ`huQ(TEa0%-+)!1z6uTB&cm46XuYuvo$hKPqhb3JU_FY!ZGR32Z4+g2_ z;TELp2R_ly@0*?|TxUM0gW8_pi2*ByZnx)EVM5v#PoLF|!g95Dcb0?T8bLfE(1ep2 zTt!GN)q;J46B~R1RP?w2)OL+zNZ=ZHwlVAVss9&BvJ)U{2oXaEBqCM`Y_GKMJ_is& z&@?s!77zLsI5XVvHgqTI1-(kud$1DF9c^VR@Fsr`a^+DuLt>v{o%Kut0?Y0tIgrcv zob?!*wuh0gMhOFN$nclvEG}Z!{(i1x5C8sB-&2S<+IF|p3P1A?%?BmsTeVJvYleku z*|Oxy%WsMf=VR_fM?mp>8(p%Hm!x&!^S?ZZSTUDTz(h2qOoxRWa?1mb)xRci%A6JJ zL!Y*xr8relV4PMh(n50x5C&!%vLh5ey@OZbb16TXYDo}w_1k>a>cTRl!hj&B{%G zoiPkR)cy)SF!cZB`sQ~OD=hH+f4IK?qt?0zaaH;lAdShnNK!P*#+>@9XI+Ks0YYrz zE53XtqmE4UN*5i37TkRW2EZ(g5pFrwc!1b;OM@xR=kAuy4ZBW0$GRW`Uh$0-U`|lI zGDwa-ee+cH#>$Xz7+%VQwkJ#NMpr>3{f_xi{=b*gC@fz;0>ng#;V#xtVs<@%CGG*pozJEQ~5Ydo4$ic zNs!2+Dr&-n<{%mNcVhu3MLAr!hCvlP3Wef1S}B`%?up8?yyu+Ywf+!-S(#Rp;lsS~ z#u8`is?q@6=_iSm-urcm#xGwjrJeNkZ!X`Aq|x1%Fl!9-E&WsVwaA$2+m@De4Dd;% zx#J#U@mHxVaXf9VOlr^knmGpCpz&gb~x7tQVR{qrFV(N*@=CX$?12B zA)i}nUSpi!(BGBab;aqzm!#G!+7rjW)TQWOtmEr=$2|&Ra9^_-I%pc^-M^3Y_b4pf zg0^z|*CLJKifZZi8M)ty?*HIS4fVv7)T`bs(_8w$WBqx8&xs@(hLGKixV%twF8Q)$ z`lh^(Zh)a)WpMA=V@=0s(N64jwwua4#%{(O-u>mmE6s6-AyK4WTTGFZE9EvI^wq3~E&EZHXSyP=rBQe8UFD?B^ zH^)V2Sth^a%Z0fSS+>s6$S6Eu99Yk7M%PUjD;U_vNI{)As!WL2U(Iy&e85Abd6`1w z@O`dj%q zKlKyX2XYJH5ErO>Fgn;;lqaSq9bg)G{a@%EMNz zR%(!{es(-_GcfP=^Obt4j}KuzLp$MbLh-+t?_8?^~Np%*W4Ihe7!l;{#eBO$G_`bq#XKTb!wc^Xm@jV{FtgDfou1L=<`lzhxE}EkSB-&+;qkzu^ z#KDq|!P0=pC5~02=~GnmK9XOYq^O=DAlL1=0$kHa)jfBG{5&%LsTb`b>nZvE#nZx+ z>bsCP3(~?>q}KfM8%r+qmsritb$XJ%WIK!->lt*uRL8peQC#T3lq_zI6jBTst#sB` zv7VlX9k~w^PxDpe?+SjeUXIp!G$-aEPc@xNcYXC)g_Jq#-sPaDj5n*L$Re>@XND%- z4lSX#3l+N0{?CAeFT!+kLneHga6N-R@|7K{;&#p zw|JrAyJa!Lb}C(@uTyI&NMnY*l{9y9xu|a*y9uX8;U8S8w&hmq@}bL7_d3l>3A(*C z7CnuwVI874csgGfgGVJiHK}vAhX9${r{djtM}DSUX-XaOOSRI8j&92^_qREM-pl22 zpx_5Sn|O^9OG0lIrD9uVhpL!0MY<+8$FX5$YP?TB6sIff19QxsBTN<>ssL10> zwvJvg*~LqdF*>iLl%Rzj$5nBc1Zr$iVLtcz^egF5lxut<{*NL(RabqcpDs1i_8%{V z!(&UzM`4i2&y`|>qm&}5$xPdc4Ti@Kner=Z*E=eRM#r!4-#^;v^r>e=CG@;iANOV0+@;qi_|tgi2> zEv|iv$5hNq1im@)w1{jB!5izx&g8Lb8SY_Isn2zxx*my|Jg^_)_qc^)&e2;E_B2!` zEu3l^_!lr~v?bvu(VS({Ednqr9*rjn4oN|W4dRJo8Z_zBbk}9&AqG~{}1f^ zj|TDNe$k=!gnRH+p5i`9TM-R~;0Je==WfScC+PK11#6#T?s>whlUf=OZ_?tY%)Cb} z9k(zYR#RE6$?aqnDPJUI2-l4uoFK910$i{R-L=kA4*e&5_w}JKb1O>{jEHpAnfSFm z-7FWJc?Qp}uV_sg4pQ!JJJCIXsmv}YrfVWSFBIoS_+rOWAdh$~)HW=5xRX={63OoV zdkp+DB5WeXM~INqz3%|~gr@ILNspL)90Zvn$dLMy3Abq1)`bKV!*q-kvZu2Wz!oeRJu z%HrSym}q41kk|MlT15HacMi#)5Drul>br@iUYcxwL}3GwZ3Au?dlPh`(}4!Iu?qqQ zCZtFYWd~i3sbsSd-HxKeYrI1K=~o!oBao!IHa7N?#Cz>jyOKzQ=nI}_RLX6kNMSnN zoQDnJdYrUj3=|t8q5*64%FOhLq0~buycMHive&r2_M+k#zG`)F+4yk}vZfgGO>V7d z-Y7N**WnZ0jl>hQiKb58U`UXXfcmh9jc6y?Ir>OvVwAU9dgGhC**aqoR=r(e@oe_u zBEDvpLe0^ACEkrA=ixw>G-G zha3J>Dsl_I-M=kkOB$hzT2@ARR^~k zBfQZuKw#<*J2&Y!=AC=;9c0H8{qox|Tocnocl7V>r9nC7qDGh8d3FSA^uctad3nJ> zd?$R!^(PVJe-3g7vZ-LjTd42d?}ZM~Zs~4Oo&7MygQ-ltQV^=^i4!&Urng&_mD7JB zp9o%wj#sMtlM>X4wB~Z>d&o;Fe=|Q?grzYn7ruL~BGQ8}aRF7||1@e}zpbxCN3q+T z5P8VC^yzy?Ud7l-H|d_TgZ2B@tQOB2;DUsq4=3OUWuIbwk067s=l7}&u z@S*)vr3Wcogxp-J|6Gah7l^AIiJ1^=l(3`;aW3SG0nlG~Gs_Z( z`pVOXkc%zO{DrUX5mTjoW1{>^sTx{0AEv}|RTE;ommB2?JLOj&Ht7WHVUQ;?K(Z~g zX?strz;IEP6Mk_C&2dR+NWf~T3=}}n#giSX<3i%DXKiEBnHRr0WTUc@kJaAIyLj`olFlSP;OXp9e!ZbE(uo6 z>hv#@Dik>_`_N0Clf*a&a{wtz*+hoJk79(7Olo{-Us!fFDt|Z|i58iiLCkqakV6{O ztV|F?5GWvsG^h)mBXD{KDUbm}YfQA@Y`^KVwrpH#=MFqz`}^b2;*#6mC+r6yPQ_4`ZAFX+5IC z`&Pr64#uxWT21q%bByJ0?dVZ|0wh)#!;dzs<~J!e+HX-PerdSKWYJzXfoF8KQ|LuC@@ zPev87Ya{m$mL&D4o&Z<^G_&0{)NZS(PYE8BoY;ZMZdGY(FvY0+hAtY@^v=`=lG+6B z94Z@SC>;V;4Xv#ZA6q|o`6ON-S&Ei@+S9}Y>E|tKfYf5Hj1ft;-)3xT9;A}t;oN80 zJD6^Aw|=|rwrzNrSVa7(;WzLy_SWd@DLwW%kKMtHF-uY&qG z2Rb&ASjsRQ8rAcL-C)+5yiTTD$&6y(<;~TEWf^QvlNc7=iGCV2TloiwjxT#n6Fm5F zKO7YGkDYP`B)MiMbPPiiX{SaVy@ewlQ(|+we?nQ=tN(D)W3}+&8C;CrEi&{#wmuD) zMqYys*8g-2aOs!leQvyf3w5Bj>l0%_h-qK<&5hxH1?B%tM}J4ePlyE(YH~c}HpnfD zJ8{8%i!CT=K2v^yZ>eg*3dX>--V}gcP?v%NM&yndWlV>nC_|tWz}I`M3T259SrXb z1=H_R-~I<*d-C3e|D@rk&&kVQ))JNNyv$%=h=A20{u(nnD`Dt|3}xz9Qn?wSC2!So zrNyPq?`pw;r#^K4*<&}piKuHLU$l5&5$|1N(9mp#enH7w6W^csp%JXU4RAStcG1eq zp^)#anMSbx`fV*mG}ueu%Osz5@x5HClLnD5r<1x8_UB5R@@WY%r);2^M5#BikQZxL z+i+0&yGE_)qMPyzhCLCO%0dKYOB)MeJ7o$Qgw=*BdT3mR4$;#{tKNzflkSanH)xmg zSRihw81qxWaJW)24R55ubokbgX`h)3qC_Gp)0`*tUwF(k{@0fLb~{!9yQ{1Smoxw{ z#yA44)*yTrK-4p5nFLFRs_LY_dnuHG65@==e0(0KhCh(cM@D1R&lQr3Zx&pPX+aL5zv zXz72ZD;UH=X21JhK5uiwf{WQA1z|Od%1${3wD;h3UbO}$W=75-m=PA(67?P}-G#-y z%X_bp()dVmN0y0ZhYMyotTvt(3wsEC)X*D4X~)$VI*YFgYknu@NPWO8>VHa+JlID0 z8jt2~-$}nCuCg$ZtYUOP4MPpDFFFYAGnM+}oVea$Et)k$;kJDF$-H;9_ltGKn^etr zVxz-i)KnOH^R#w&3m1&~J<+pcgvgOx4!%%m)MV7u7@PqyBIj%)S{E5M#)jNeaD&|N zBM#*0S3aS;!E{rEy57|coGdsx+0L#y2Ar}Gx@h&+i2C>xIY%6xaqwsA_yh^qZ6ku{ z^`FFu>ODgPv(4AYg&3avHXD7(9l=1DGDS3GV%Jo+vC)UXY1wA@kpNw2SO%-ZB#xif zGq@8KrtU>&9#=d5^IgSd@|!|_SOj4Qa7~dt9H?H7(P@f*SM+-xY<2&8eF%~I%!Ijj zn{&1eEc66;iLrrtdZy9Rx{DeSkPLo111a$=;|TG`#TCN}Mf;CKAdDlo@g({VZ4cD1 z#m>4^X91RJ;mfxQbXvqnl%=ST(!s?ZpX0Ke3s6H!33UjbP!G>UE`p@T`7|(!)b9ym zr*b#<1QQ@vAZ7M{=Ov1JzHjJCgdNrBQ#EmQk{BSt7a=Kj<>uZ>%DMw5Y(DwCZX>U^ z8lDjBXAXZ7tkmYV`9N&LGPI`aKUei2{whyvG@~!HU3B%$$TGu*P$$%slnH%Jnh0tA zPC(=1nSdTIiepG@WgTAFZhp@Z4J@GHY@GuO^(-Q$iDB6}6+9C~m?d5Pz8cpjNWRU3 zSbPF8Rx+r&-o|-c{Q&oyo|S0+2J$sxW%$Ifn9*Tk*xFaF)f`C2!yLO4_ys@Cl1^l_ z<8rOaP0r|INDcK%DFNYZoHX`^iGb4;rrk0Igb&k-J$o7H>Ut2%&({1Ijr~*S)JO(M z`Kn}*ya9NPnb6WGJ|T2;*M5kegFUXifrZzNcDH%)0Lx+^sxsWXFZz)JN-MHTLt9sj za2y`sI^Ce+CCT(UVwAEHFN(9Kl477vxRI%Z@EH{ghD90e%e<*4^f%zoGPEP66?meT z@#vPWTE7%2HZS}A>;Lm%mxtf%Mf$uW)w7pCC1S{}TrKL@nKI9C=6+Lg+0!#M511fk z#1%lIBvfI`X*>_Iy&j1?m2EhLEPyQOa?^f_Cm6~BPAx7VA%0zSHv`<~{KH691MbOX zn*djX07@}x^A2uy$s~X-*_wZNRYy|0`Q_^@=t&WZfE7s87G#@0P<`qy z>HLQD*&A8}FD$E%B*;d|V|*IEg5hBE*6l^JkNFt7G$C^IL7#KKZ5qu)At$+SQ+z3& z=r?tYJ@*Kmg>l`I+bw`Je2Wu1!YXu&&BXn=L$8>3JaMUeAZ1JyGU+rKZr z3H0{mCvjxGY@(4OYI=K_w180My6Q{%615KJQ+(()dYVswu}9bV`|MEF{od{arEB7) znB2zr_Ciibn?)@F3@vu=$C$p_>X)8|5eR%c0}vbDEvlosnvt_x2&az5WgR z8pMmb1Dspna92sb7MpdxrcJI`-LZ?OJ9Q61-{@2=PerBi=#5dR2k}hwI_wZw3P|6~YZ=N*6p>2BL z*@A1s2E)Dvcj+>;A*C9zYd+1uq|jc6sjU(P)>Neb#6W#D)x${?Xc*4m;|a-TFp(K z&D;2n8S8T8sbg}O0SQg$zaFK(_tM}OG!I%3#g1&@E)Zm-EW3a9kri)kOfQTu_ROh_ z)wPMJqgMP!ZrrB61S)7CE7EcmQDo+QiA>06AHZga!ouiT>QKC5d7zw?#;^Q_|7$Xf2!t0&JI(oM#zv&XHt z`RtSU2v!fL-_7vo*?M=GL-0&+`9W)waE)VNd-@Fy- zF+F!0?hjq6vVH7|qtHxOXuTUmkI&;n@J&TLs_HYTTimsU1|L4`8oe+<%rQG-bW2un zOM8o|aNy|x&1q#NE=7_woGATGxM@hm!HL78*m9E3n0u^c@%t5{Ph~e7YD(fEPrzfy za86DX7EV{I%^|Hw)pcQ8M!r?*%KC|YtMMBns5yW{CMG6n`_y@c6l=fg;Qya#bgemm zmK^D}|9BH;?>0Nx_9sg#5yfHENZOpFfH71q_2!K7hQ{?jpyUyoKM?l+ zG4_>VQLSy;il87W11N~(P=a)abccYVbcwX&fJpZsgY=LBf|P^;(hbrL64Ed-#1PWm z-_4Ha+536_e82W_xQAJ@*1F@m&+7~oVS7F6ob;oR;IpT@Rp0h#TULe4oA+OwOocir zJ%b-wLfZ|)@woYay-~cfCAvjkFjELXoTDg?ZD}%>8w{a!Oq{b3Bfc}TgR_rfb@5=L z1kd-a{PA_WVij_jMW1Ycr|@Dj!G7pNAw?yn-=LQ45$^W;a$4nLqQ9zOO-zaGJ(5T8 zaBztSI%fT9x-UP-zkA4Ap(sKzsI`3zlkyfTs9)jN;Q8y-jC$#=xfs}Me_|)?bWLh7 zprFQx5eq2PwY%ZL&TKgZ)+`Qk2>I#PKL0LlZu#-cgMPxTjvY|9iXCNofaC1c zoyWg_#TljeT+{0YXWnU0ylmJ3!*TWR3-Lx&AEgbqJ1W6?c`cdo)(VLCx{TM&NGxGV zE@>jw$y|UptBIct7wG^yK9cGD%l6!DN?~3tmM};^PP8odb|O?&BXd=JoN5cIGFF;{{f6)W7A@r&N;<*6rCl1c2t2_p~QTE0o4S#}op zdq{s9LqV4iDog%M`59cW;gwjNBTdRFSzk2;A}osg4$V5GhbyBj7bm0mA@lYeMR1A# zd*9siA%-dI52GQFLQH~2Z|-vW^@oc`oq=mzia5EaV}FXeuWu0VMu&e&5Oa{ZlbX(Y@rZ z>mTS^mTy0CpSxlfM@Jrtu+2IAnts_D;dDnqaR2F4ASI;40H)8UVrS>*?N+x1RraC?D~h_Jy$gyAPVm2vRQj zZH8B3K0F1(1^$hF=+dRIYljc(HiYXNFrp{cp&Ta3bNYiVxLdrYJ*fZLMlHp00X8uZ z4=~?`(*=(8nCGg&j*X>zz_5Nz)1b_Z`Wy(*XlXtBl7+I=K`fNL3y9*4Pw57ThT)yG z#hVQvA#n=m9F=0*JTE{HvPPl$nPk<==5{y#vOZBdm89b*`6_=`~v|joyjG`tcj*QH` zf2^-qfQnpQRZopy=xVBuH&PypLrdW)#;_AzZSpXKMP~nMO&6r6HnlKxbdPJHBqXMC zB)8&`!gedp`f|uX_`F4yH#n-ICoYD~2do?7Q8qtb?O9k$fBVg}cM-1Nz&z@LO@Lr| z(l>=H*w=kv=4tbY;7i*a+=OCg-*2mo0@_#8Qqy5h0WWITZ~JM#xkTIl z1#%yEZodLavSz^1W53$n{NC~G=}Plh(5E>AwPKoQ*x+ycI-SH*H&Y}z9nB8}=7r_E zFkTjPxA*W+)LV|H2ky1=vw=cs6(X$6T8o~zPHb+tF!Y7wpj*ju06hnP-+YuVM#1ar zb+4+xnC^<-PPqiAg-%J2oaaJP$$~u@;?bTu2lfA2`TA4{D#pE{CX}br#%JPV?Ch0`JXh0w69pi1~Ld zz*`J66CYB^2xwj_hVLv^jJ*o^%9P*q@3A(;gkPx`@>?f%l`Z7^Nr-Z^98Js6%HkQ6 z?E3qikfRxt5%pdDAN$>Ov5`ZOM(4M7IPLpbFjL#SAD~wuSPBega(MG<`Cu22NH<`1 z-jt#6Rz%7mh$D7M72Va^=(AewNgJ<{zGpOlPt($T8l4gm<(~QRgo23P*d5XP7!A8i z!sIS5ez0K)?_T+?CkQ0=yRP;CmWISrc+nd z$xZ3|GTVY~1boclKFHw^NcPv-9XuE?Qx=!eqqf|#I*YIBu(#_}Ml>*5^@U?5RI-fj z+>6)RE@!q1Pi72ECXP?iq(T|-Cm#t3hCqV8?aNrJdutyGD&cAuEWmqlY~CtG^Rn&e zE_QtTs*4NT&T|fj*P55WXS7L22)nOLG~G(7FNWXN#zqiVlVW%TNz{l=i1PEJpo4*?GNgo4;r7FK`H{_Oo3FW&bEJKZOzEs(3Ck*Mmb~N#U3I&eBhU5T!^Q2)-hgB+Pi6i+i6e5ez=%z?KO6WheNd5m*s}3! z0^P1N=LUBPbGaiVJ!q;Ui?@@Z^0O}rvND%dpZ4>Lg9M$M0F2`2FE(3!R%bnZjhBg2 z9_p0bsk|l(-iX^fJWgxek8GUpZ3MLXA-W0Z!q@ag&HoqbYnDDDLQdY zqlbF8#x{=}v+Tb$VlaE9VFtpzvd9P&YxHjZAgroT04fI5NFWUpBiowJ)Oh`{m4xNM zn)z#%=pTUkABFy3t#t`D+)_QMT9T)EijP5pjQ~)g2D$BCw#>bNkHnj9wu)pulQ2G_ zev*E@cZ6uSsMme2U6PSB1RZ5~ zW}Yfd^sIK`iA_&A+3>x4E&9C5QzzW2oJMt@r>wb4(tB=(-l_`LT-DDd9VT@Sn6l|U z3UeXM$LOfvSR{7PQC*30>0=a4!kUTPRqihPl4&4S@bhNUZMim?;|PYrdi0}v>MwZY zrN*VFxCQ)WG52p&v9Um*>t&N4Fy;#0s7RJ0HVyvlS9GNnLP)V!eLi}e3zj7Osz-A- zw`mU&Wp?9m$2gnXq8!!jr91(3&kpFYm^H3t1&0aD2+OQA#*b0z_zTNh_mRPb!kIUR^V4tA6e>^HLOrLxm#AX9O98Z|JfL8wPOXuq$w-R>x>1-tt&m%^Se5OT#w=}SoopI6*X|DbS zy6_nHy_MMPM3VOZxlK;&*Ak#gfAHNpBvTGifz#D%1cqfVDrf}jzg-LPEMCTa*g;sw zO2dDQKbdNZ%Pe{SC3i?DJ-;&wm+_rM3G^l0wPa7*Y|oZOsX#zSu%K}bsCsbJA z(;MeyBme#MpA(J-TsR=&8eI!{ZNP&}cR7TBg1k20KTjeE!tbW``PI`Qic}%ISJF!Z z_J4O%Z zr5|Z_pdPjR=sW^KWnJ_GhP(0xEO8y~j90?u(qB`8fnW!EacW=DJfa?q$4S}$=e+u7 z6-r15E=9LrT{ix&xAH0D@^Q+q!mRCs?|%mM1oZNq{re4H{*qw=@C~a$`3p9G z|F%*s?Dg}B(Wx7QmG+3qEuRbP!rs!ie9TzXN_87ZuJ<#gntqaJ0j-UVQj_-hrbwf)dn~#bP0H#`%6{p)}TYt2O zU&XKKnL)b=P7F0ZAV>Gv-lcu5FyP?lXq37CXO!hb4pUjnLCSeI%-~fp!_<40g0V-n zgFz8u#~r;XqLY9QtMzOUMAuet266)k-eW-&FOmF4A?ql^V1_ON`ePQ7z|3|oHHAiN zE<5B`Tqnn(B=^(GI>LCJtrFrs?zB&tc0`6zlJi-65#nyvgrY2PS!9)EUGUFm<99l_ zT;o?w9X^))_B z^(-F#^;64e8svoM?A6N0VgcQK)4 z)qos%6RqD&)|*_Zjp zUIuh<89s__INvL@yKFcWgQ&o&nK}=x#K6}73?h=7SRg4WgrtheGlZ?&!K5uTw~`7Z zZ)eqjZq!sOsnPGnzP&d#%KRWw`Yqt0nY6l@GjK|YP=5R(Q?gW~U9;q>qmX|}>gqm2 z@(P!i2kYWttT-cMvvBvB;@0Pn=62CPr@?I4hWfG}j&GlKQji-f zkBO+)96O$Lbd@4)Zsd!xdBibEcS^ z@8RixQ!(Ri{VMCm?FaM6`)f(};})&pt`E2u?f;xSKbCOsN+P7;Mozta!76K(@WX8X zrjJ`vjJguyeMONUaP?zTKq-Nj%;o%JZs%aIJhs z#P}VQBo5Xm#Wn*o?+GDH#gWyA(Smyd99irq%3^g+i?PT+w^79Rrt|68?BhfTHS3&N zKqyy0+#z$ZTfpu69Y@7(b4hF!xjq08DoHs3?iVr(m;PFIAjLyDKLqEWlQJ?;qK2;J z;;7%J+UR^cK7T@=85(Xr09*y9yC~Fzq$r5R9)5g-3{dDtDv_E2bVsV>sHy%Cjqd`S z2&+MB-9q#Hhctn6<)4p=HRaFcRU!lWlm!}YmXdmLiperB%Kd#3J$mil-(CQyi~8ml z!v6P2!ikyHALvLY?@$M|>gHHlWMoapfpeT*x~-WNHY2XpuCL%clg{srsG?tm0G_TR zMB4_w*@+oiGAVb9v^h;ofua`3V0`kOE=PJoc~3kCt^5*B3kB68FVRCC!2|pg7p)Xc zz!8W>1#GjOnVgDFE7xaD#vi4OBthiqlIJ2LLAvgAesR~M|3Rofsbf#vgN84%g?!=w z3F|BrfVCzcK~?7)=OQHK3G#~8L9+Iv*zP0#gfn_d`XzGv+S&EWx$qpj1>Roe4;_GC z`5h+g=C3#xWOK;@dEJ4BV|J;WCx(F?` zK)aY+0B{?YY|Lo@B_~zb`Ssn@Hwgl%+-5f`2#Y?-nf50O4XstL7CaLpYRXjFJ+Ovw(i|+8-bAsuGt& z#7lQH{k2z4uwVg;H>Y51%;T<&diM}Q^fE3vG$lMNaG2Cj?jb2(<4X&~s0%Bv@_Lw< zc@j>$Tp@-UUU{zf#D<#oV#hu%`um9PLNh#4zh;1ZLUMH!+YoK|N^|4T<_A=_;v71dxDf+F+zZMz12qPiGZL16`_XUeSxR-k%4xm$aG0|61hbOaw;B>Gi9YuN21>5LxQ|0PKakT zPKAaZt8m(!msb+dr$(R^z9>Bil`6mQ6CoOaui*LlR69YGZA3;-V_ipv!0g$UHtp^c zx6kY)nX32mOqDSeS*n(qS$VA<~6=2#Z_LL!LWT6)-Mq zMO)ACD-7d4-%g-&^CdO6h>!K8VcfCTi0#n8-8-O*8@PS0=uf7P(legi#3ZZ3MMTa+ ztE>h;6U=wH>PQE6+J1ie@OXhzQB9Xq_F8DMr>JY2)xe(VY0#`#0d+h)Uay*w-PuiV z1xsv~%S8M(3*P(9&As`fe&qfJIx>L4YY;6u$B|$EOzJ3ORjSU*pxA;jwHoK~1h@2x zl$*7pL0qi09wB-sleLWkJ$XW1Ws$roR>-_JOWD_?=}$L1z2`*Paa@HcI!v5DsMl{q zxTPiOmwfwKxwvN1$<2M+;DtvAL9VlE+L`xnKfJNcQ+wD39(%1G%X^cVY=YXQH-{QL z=FS(~YB8(wl&I04quB_Sxn`f<_+TE>@C0bM(8;8ufq_GZ2`$Af6p2>1OJr4){f2m! z&9@D9vlG~3<&+Dy^PY>^`1<AuL)gC~Rna?=! zcNvPvcCcA>=N`@U(&}g)joXDdz;?MtV_OCQ01#WtS0H<~KIlA~q-x;ma=*|m zaO=3bG;sGL!&;&v&KD(>&&osxhCQI6Iuz;5^t&HRtunfC$K+B=BF)w}*t zJG4U27eS$zn*a%tXn(@z*m_S(un$KZ%=`=t;17q{+m1Yl9!)r5RSJc0-0TcYB{1o> zAN)Qa&Hqt#?b58)Wk^M!EN=-xNT;hqZFw(;DiosiaxDL^JxH4Fds{Q8OvQ`BDFmA3 znptNjJ6t#lGtb_2Cy6o7h)N--siXT)@ivYb3X*6=o02Ow z1XMZ<2-3HpB1P;V*;`QYl}&4y75;9E@xT#@qDOWm{ZVcv>bZWUWx-rAlV?)q!GxP| z4{9jLa?NaEZcfuF%Z3*_>T8MMjrL4Dcwb>uqfw(mCVUiY-i2U>8=YzlfX%o1ay=vDq`h^j-iL&Ve!maXi4plm1*jE`DgVDR*X zyD$_Zb&nHl-rJ}VI^A?0G})*aG@t2*`4jJik<2jn=wAr7>0}RW6|XmQeFefGu+)j_mF;9O>^9>>9kgMN}0i@kJ4LPpQ$0zT^)rZZ8{VyQ?T&3<6x(&^2xV- zauZKV)hKta_Nn|8S(LB*gy&`=+=yXJ5*~!)A8B?KS*`lfAg#ECJpGO=NhVx8rGEeA z#hVL#_B9pcjm%Iym{4R&WU6kHP($3tu^w_O3$JpUQb>QLonjdi_pLsZ_>5A;@(7kr^6YdR}r6ZjGOmsGZqpu+Rl-||Dx|LEW!cxwyfQ}^($M`&5N@_4~UZUcb^U`ln@Z!H|vfo++>(tf9FE&5bm5y+)$B94iGK2Gnm? z3928v-TSEMNf3M`7%3ySw4|pXN>d*F!z7?FjI2_Msg~SgL=!I9VxTa%vj1(|PfRsB z5)w2O_(?VT8bfV-SK)}*XNpTkQwr_kU6h^ZK8*%PBrKW#?e}Z?kdJ*Bjr9lN<76G7u|G@U%#0$dg&70qOu|C_*I{GR@bg?gHCYsPN4d#%Tr>s@r+JCxst(k zhT-g~n%_I70BrpI>#T_dC4sOtRSxbyjndjZ__#p~Hx(p^>sCHcQ{X%)bx}O~rs)eB zjNN;%5f_69d86`rDXG;BXKj=YQA!YG)Jg6EG^HXUnxA{cdtk4>T5S^1v2mCGl_=R< zYTS)8@6g=~7b4nE<9!q{du$AKsTqLOY?FE)a>1T9#>#?oN!16@1qT7tr@oJ5UNH`d z621Ko!f?y)HN?_gN4 z7Lw5p0Q!doQNGoF5p;vf^?PqhZ^QH}UDeVNphnrK&IlLo$_Ma3l+g?*-7vCwTXTEB zf&5K@=)|mLFr7Bpn0>=pdPyr8OM?4HaN@e##u!GdCc;(Se+&jNi7<)zUxz9M+@2(X ze$kyCo~%b_C#Z|JmtUWb5rH3Gs>T7)_k~h_n*!@D4d@t5V#R52ey9f_(eY?f7%>sr z5+%`bu1LbW_liB_BGS$Bd$I3(IL6nV_DbC#-U`(Shmbv|{=w#;~Y8=Zj} z(U>|NiS82WnZENp=Que*syI@U7%k$Vo|QCZqT?s@PH0I37Wy#~QdkzjFbQT?ze3g; z^J`Tr<~qJ272uV5bM}@{b+!Hn=kcBZeo>P~Vzg|Sj>=aPLjQUNr1cAfUsos_Z8~0W<{e6eTr+~EcWL@C> zsp0A2jQgxtgF-Utw`n;lK@wlyp0wdnece|n;2^~zG8sc7U{v=ofng7(TfA7k58h{Aupe)N6T(*6_&F5$u)!)iGX;JKI_Xm>9_wWH zy4}a62}EOF;Oy}H1Kpz`{g+neL5R?61z0Aa#YG1L{tXN`=u5=N19>3uz8s}=nSwn# zH9AF;u2Wwe%D=hpHXpTlgUz^)te@qtxo7P5-5yzay4`J{##Qk?lw6=MjPfymwK$L} z&^|xYkD?!1c_y(bA2ItEPIQCozd)wt6Kr53rCFSa41y5oalz0sE&yl(>S4yY1MND% zE=?ShYQ7O2tMCvuQ%gUeGMXnMK|)-iiT@sARl-2w$fG|`PmS$A8QoE%2)v^~SM8u$ zF>}sri??v8)qF7X!wW`vL`t7}#Jc37u5>a@S2mSlP8DNKbk|GccpO7)$2rqZI{Hnk zhxl_Tzwbj~V^2OU5Op?lU{kX>tMJg>ft9_lb0_35 zEl%j{Ef9{B#X!RcvoA{BV2+l?=d-xPML#JzJ>P=J%mcHHpao2X`6x+%@pJ}dFhf-2cBU6jLYBgejwi2L;Xhl!bd+x7tEQS? zrF*1suK#FboM)@1&7nhTaO3}Lrb$;DoHGWZ&e6lIydOHU)H)B z-`X@hvKKx#_S&<*tMHrd`L|&wIpn*_nVjaSj*1sP7atD#VyidTX={{SE1_Q)G8gR2 z8fxBnbS&RzwlIL{-jBBQDS;8-`AFA4^loODQg&sx- z4>pw8&}g1M!RBc|-g~wuSb!`uB>pGDo+tY$7jG*&#l7n`ut$D;ehR>w{S#Cm=I=x>o?DPb(GdH0?ZE zRW@pm)j@}8S6>7_iEZuSLPJV#Lnj9_Cjxc0hgx2aymHbVKeR5s z+bc|xC_TVv3O#^QmP(|!s&J9i<|-p4y3|5pewmX(h#N(-q@^XeTbZ>XyF>H$WNyP% zkn?;WRCPOEC}^vXAU&9a0X%UB$^##oxE*oXaisYCRyYBa=UIA%2RR z6tV3Y^X;u;?XQi7=V@_ArwRFdHZ0H*=)eajDdXBSGio~`lltBC)vqTH=@Yz80W0!# z!zzUlwaGB{H)>p;=f%&3w`6n`fK}tvIBT8v5XVe1${jm7l=CQt`yV6=eHd3 zXtJQ|oWqSJ-~y__iKYg^Y`(!oj3%lk9S?>Z_4H)2LL&N(Hj@N#e+XmH;FCP!g9HE7 z7}wgLA&~wr&To^3uLaTDrXaA;;y)upEPJ_BA>V|V7QBq%QcvC1+hBNCb3drG zL^B36t_dr{%YQ&HJsY-j?(dujGwl+`cOylFH7Ckd6P|TBJ@fjCxAl7B`Ft`uDX+*x zn!u#wL9Thvu_I^mM%iifSJ6ply*D6I zCz-b?4jb6-5N{ba9j~CYZDLHC^^r?Lbi@wc_uYT!SMi2qDq44vzj7UI{MF&5mfYW1b{qB8nA_C-0mNBV-R3R4p z7>%H#u#gRE()kcX`JYyHjLI2Wn^C4il?T?zTy2^jh?4+teR2hh0e%65)lb}^Hb)EF8oVQo7GwkJyx&$ z&laUYtjcwhHd+(zyVLDSxP50D)WllRGFEO7wWR7h?Kfw2^Pr?cHTU!%#j<6JdZGF2 zSeND7-Arw@k1Fo^lNn~_<8HCi-j#y9f(S`XG<`-sm6AGj8AL5y1lV?F<%o@#R44A= z70Pz?f;Kc zg`hn)e~6Fj@f^BxV~97;YqHENc++EL&LMx%WmF4k=X>0nwZr04*q=XY;aTFxx#s!~ zrI=(CI%xnD+GS&9v4P*h0cHKz2g~64h=@+jG>9&n9!0-ha;W)FM-enIXgIJ`6cG(z z7+h*5LnaW4RvoRfBs!TINx*~yBu|CBrTT}AszVxKy)$BUbofMw;K9&uTp9NYJH>8! zvA5knakoZXd3T2FYStD{T`!F<9%GW7(zm`>9YoG}-!cM9^L20(4NL6O`IU@ks0tv$ zpvb_#7sE$b?pt5T`XTZ>klT_n9PjNoyggdaCu(hTK6G>q3G1tVr0>Fg^yVb6m;#Cj85*BA#GKw$`prr=oMVXQ^tu z@=ex`LZE}x?XB#_(XuZW>^`kz3|rmzc$7e|aD%}E| zMtZ(KGQ9*-oOSc}#&xhJq@+&;8?D(4@SOW$*R*d-3_h8CO^ct-)5|Rxqqvz31{S>; zC=?x4w^YDRn&Y=JH(#X*P~`fD-N|RFztb?24GIl2L`{-(x=33 zdEyi3E=VI;?hW=fPNiB?cd z49@h@puqS!dOHz~OIGt_CYP3EbY_rP-IdZ$_4}B${8It+oeB=izV@r$J^_PjD}tNx zTc584gRAJ#PRdSDB90SHiEcPGZ_}4-(~U zRgp)nNyh!fJ+noLi~=)CN*v6oy~?`hkB+7(`gJ0^Z90BUF7Wv_3+0TQr~L+fg^4Fe zO^hucHa;9g(R*h29!4;>>@8lS4DvWT$xRZ$j3aW`ZbscOpV#|x_^aj&JpEvOwDaqGG2<^z138EzW?Z0srITO_QD}pjya(s$P83%&Y9NIi^->gXRt}U`E1bZX^Lcmw@L+Q&q znvswKU6W@O%V4+qtkK+hvP{%Q%d5_Om6YMpPEg>g7WPii{7UZ_QYNVqQ>EY+dV`c+ zaqfW+E4G9_O=Nx=<2vgWIbo327ida+0<#78v^A~zC~ug7isL)4C&G0dDg3I41H`X) zotl|cj6*_B@%yxOfv!@|tJMc|lXNmg$$3tNzI|M%XX9@Vxoe` z{uwPMO+1$5JG%8*S$n|gy`5f}6N7U>EQFw69+Nyb%3xF|tKXN0<(#AOnn6G0@D7PA z!ie4k5%wIxpJj+I=YEcQu^2Di-NV(dbYwCoY>CfXf5(RAKHcmoyTl!G+b+6~Q_2JP%$$C0Qh+0?X%IcvnX)*Y4obbL zY@aV_QL~9hG7s9)jMD#U_jQ2rs6@e|t!KD$8l3Phl=LDHTc5{GumiG)CnB^&@h%gt zC)bL**`IX+MSiKr64bl#!#_z4Pbn|=AhiU}#xN?;>O2w?r8=!bLwrkw7E%XQ?=}5N zG9aCv+UK-r5?D4UbwWkrjZzqTab%O8WZwpeNS}Wc7WE~WEAbHam%~UF$;;_0Lr2Q2 zMKYZPLr;M}fOBW57-nd7OXL0hsryi>E3YE{BA=)PNXRp`JnTl(;}0mfQst~mO4UUUfgD|NBAo(7%2Ygw>Fm!;fHo5=^$9Zvv)OWjx z^xi(rc+~bLMi7${V9r1XOmfQYR6c?uZNhK}2j)#YyY9lT_5|SNuZb|wiz=T#raW~-> z5GCi|vBM}(vDquHChs!xNsZZ{^Y=@`$91J^kyQr$ji={JMCQqJI;mS9-`>4>X#IuI z6LUBd8*N3@sK>%IS^(5u7tz&r<>TgAD`KFzXjjx)8y1JG_!lEJ6900)*(v?{hia|E z>7C#ah^HBz_PIEF7MGpusAP4J&MwWdkG}YRjiA!rbBr|(hEiAE0Ku?d-!s`COetJSbI;Y=a0X`_O8gila+Qgo1^o}-y$I4LkWGCI`t#Od zGJR&0$jBQeJ~^Rh7a=?x^6S%#hqICONNP-T9I@zigh%4b;@4F&l9k>VTy(P2OzP9p zcZNca&?kDGC5(|)__j9}Y`0z-ZZ&EDFn6tMpdyHUjUfHmE?b(tB$UM@Rh!7QdeUZ8 z^u{lasj1Tc#ja!2?&@j&=uE}f7e;DntfBZAGwwRX#>;2$%9+w8fve9iLXPEz9e&Oc zV7(0ttrd&^=C?9^3(p{RS9aN{C)4^UxW^4Lp<8;LOOyFNoi5XcHgkXU>K;uCvs!e6 zq8a4I^Ucs39J8*+>R5L|ie|~LH;Vg^SS#*T>z}^E@{~H=O_p<=@XQx*jy++^YPh<9 zR{uNp4f zt29=bUnBIooy+OP6bUJyQ2%n&GSPZ4%AF8xq#y+0sZY*yYAKWBw^apI0h!Y=PLpKB zq)#x)Uc)0AcMB3tzc%I&eZ}Idze?hgyYbC;YL7)|S1o;%kO$~^epg}d3NJ-_K- zrIx+wU1CznjG)8Jn=w};C#;ZL&iO%ACvDkc#%Shwp+>T7i{*BXx>PMFec`TUe`2JW zU}Q~jO{#~)HH6A6k}le_DbDBI;aI8H1SVCNgGms+n(Lp1^1Y5%StBUg;5LOgNv@T* zWP50Pb9<|D#Vyu^%sr%=2w{h7kFB!Q$bG;@Dq41)AwWgw-^RODrq6aH@&Hp-7ULoD zl)r&1CpDhFxEirhUH+z7-_d_qqrW6M_x65DLbezb8lK8;Le*#MImaGV?qC`OmaBHK z3iDu0mSwDcd{|+98XLogM1A&YtOI*pCp9dmy;%|NxZSVVz4a%4Di)CERD06*+feK{ zhQjl|G(lGzTOuB!fqO{V@)0i!ZN2`bUC2Khb8?r$%}}aA8JC0g>FJhWVqz1Ytya=Y z^5Yw)#Z8_WS<}Pse%A~xB{85GfGKD=cfYiWiyt%uo+Wm3VFK);7MGSo09*T7^r3Qp3?=(sT^-b0y4;DXxIyjd@MZI!mi~ZkK6-tr*!C^Uq=OZRd%ZzvAi4S?k_Jk@rkW@%BgI^fYvr2pHtgUCJ!6 z1eeRBPqlsb@#|UC-}Q4=z7CW1*LFQi)7Oe(!T)KmTt|bn=n&0B$)QW{7CESfL-H&& zJ;tAPNv^(it2$4OAsFAUtz>qLpeMZQ?U%@JLkrVHvh05_jOXR(zQ^6wUC3ag4BLY^ z25x%u^ilLmx3%3we<#itR8uF;GK34dS%-0?Ks~|7PrCP+>@_F~q$yM)mg zabrK>-oDJOEtfdgFP(ejjtd6#_6iKgoVh+tE@bMp0W|+_1r8(QSk&Zh~ zx$6a*QX-x%)e3x%&MphN0EtSsz+(y5Le_BG-y1jkdae<4##YhUdPjdkTB3RSYcA?D zMO1nfdxUBfj;33<#J8q@iSDDstHR(LT$y<(wlr&JMGzVP(2II~s8T9Pc0<7SeXE3> z$Fjs*qF);~K3kEFodxm5{D zFHDk@3c%W_UyT7Qc~Y15V1SdIkSOP)l@tcae#ZLyovF^4wn8WQ98NDg zk#;!5g6j-hR{PzNnH9X)QUzp6TPJ9W1ATG!Ed?ZO@Vd(T)#Bz8di8$57MR*3lXCqe zsFwI{R#rruIl++dz*yb;vBHr{%d8^&3u7ORUc}va`b3c@v{>3NF`=6de)Wy`V= zLaip+ccH4@Kf`s5NDJI~Nct_KQlR7on4x!vBl52qT5>h=QH{W7Wu^HbLWn&gv)A5u zB80vHGbf@JTW{Q~5-0IC=nI{;F5zCWi5)MEtpo7^y-o2hp0P>D9J&I6tx~dj)vP~3L2_;XVa~1a7Fb9k%p=q zX(DJJV;O$8r}CbQC;`;FW_Wqzerjn+XKqA1;EP`d08Vvtl*A5HfkcVU{Hn#oddq)f zq=Z;&aS-aqZ@&W5b$x6(5Pkm0(34@-BtmrY$F5v4FK{K@##|~KvOm5}G$|6e`y?mz z&7k7IxPY5m?^05~ z0Po)+h}zp#HVYucf77zRFkQT+wZ08gVe+E=a63v?5gQrIiB07A^!LT{EoqN-d>5a1 zS$Ptfx_5a5CTZkSMERUg4CpN162!LdIyPZ3(>JrAwOL0Wbcn~D9_I~#QN(Ps97mW*;|7c zjj}@oj*MwFBRpO?F>-EbAUWH{T$>Vp5h^;ue$d`GfDvjT!Qjm94} zS}P2Q(N>tklS;ROAqI6m z6HSa)N)L5m8&z$<0_&rt(z2=5ouX*mC)<6((#a0TS#cY`c)061!rBE<^7YXO#+Lvl zac`M3u=b;7^sXIE`?Pq)I8Q}oRj|j|hJB85?CGI7>r{_rTg$S(eHVE?<&()ie3h+{(IwQ+Omc=pzOeAmhpf5yE#fl1)b?&|_{-zpH{WF%=@uAdvALB_GQ5VS`5{|pzm~A; zgHSOCH;@iEu-JO($o z!hH$RiaETIsf6g;!(_Mh?*ZLmrPJ5ffB(Kqwb`UWeEI7iD4CM3RPl*NpZsq;>AXl+ z?7RbHb4yED=_H~v6XbqVGZW9hM_R?Uo@~F-ee#mfA+zT(syD$yFy&gY2rAc;5Zjwi6i)Zs5Zv>!}1?3#m6Xuk>x8+IweMEc{phu9Wmr#>XN0 zVJiHKDc50B>JHsEd&{j!+HH-7}0 zs2|&L-KbJfteuaLskqPDbcTR5bl_6_%A0N*Z3KAkwnGnCTK}G*K(NmP&b9)s8xNo} zzbJ=keu8~VQn)G4_%9kB^iqlG<+8&k#VMMu@cFf_HCQHcoO^g>BP#agXeui9?{an7 zM;owwE1+S45Yspr7K3;vq$C{NOAVYaLp}k4z+yy#O5Y|~P zDvQ61`HZJKTEOI9YryPvAT#BYeN(bp*TCB7qGwXiljvys1Eg&HvjmXfQk^>5YNH@|Y-6$Q>-6A!>Z;u|& z@jUlF_kI5)X1=la{`6YQ{_n#kQBQCpg|!zL&SJ3J!gAGuyb{M9R=R%z+4sn$86z|5 z`8Q`_h8Gf=dcL7*9scV+f6`nzBbS--Swi=3t4oDE4OGwX{TrT|fktNpbHBOcXPf~n5@Nf}2~;$HBZcNb7vcbq_u^}RRrZhO-5?6&L~qiyXRKl6l4-1>&GtZi zM;XWW38Y%Febk2`Pvetql8FrfF5~PZg#LbqeG$kzob^Le00UU&z_gkY>oSrd;zm({ zhMh6=AAIS)sQWkjG$H55+8QN}|J+Ol4r=)Qpn(MUM)uHN#nQJd0!49u{P||ihyL>B zLPH2Bt&GtggqM|tLW{4VKL4~@KmOXVQ;8KqH?e54AMklGT$@uc>DDcU^F|4~)tZL=UwYnkSj*f$kQmf{@2|o8tkW%jYOpj#T1^ zdHk6tp{$y0$>$RT-YYY&r(^ zd2D#omEs=fe)T%bF_T#sIiDbIS&CdPH&|GwOm*L__Se@F!F0DdCY zBV!P^Bl9z*0k>zD->Vuwf)V5oe^huJ?>t**3w~$egQn;OiWsLI(_^4a*8$>nN3%t8 zzz+8|J9H0FUe$09h>Rd-(1M)-J%7~ZRF&Nm?c|()<5vb6 zQboFi6@_j?FLPhoTZCPo>=tJ$3rdG2ooWQU1cB)T8r6d!P(S~(Q~;aYS1wik^3HRL zl#D2oB`;n6RpF}Q5}V!SE9o;+_i2URF#hD_P%x2{{H9}KXc&IP-JS#lo;s#}Gt)S} zco9g%=FsTnGP}>j2VF3{2h!0^BpXxU_o~;lnEL<$JvjqPLD|rq=52{F_J)&|H200% zXFy&nsXz=F^RfLqxi!LI@kGBJ50O_TCmJ%Kdj07+Now>{P^6^7-7JRgB{q?-T#7nR?!*wE2x~8(VA{ew z5cQ$C%;tYf<{|3RZ51>!Th*49psqBHu`fc`w(xt)X7Cb;CKO1nvK$4~)Sd$OLNzH* zAPMxW1%_F0pg`9K&hY~zopVJ<$~Sw!%ki;lc7dt(IT(a}NzP@epjLhzp)3s$w8@ix z4xdgA96`2T19)7;xcYpMGk@Y2>#Aa%`T%WL2wFk!R`UU?%-@m+NaIw3+}0v8>zq0Q zjUVKs5DbbwlBpdlQm?2}-!u~^%u%J2hu1xgycKBs0kB1MrYU-@w+4Rbun-EQZ5NN@mze3TKN&_YH2AB6k z@9P4_21*^k)K^%)dA1VhegY=x+n<nBKGN2ql25ZQ;&1H^6*E0O30bbPL!}*nI$+eM7fReXd0s!Et zkAP;h_76C6n&+P}dm{`U5>!f{vhWBYtsJq%(CA#b`*lenGg>SB$oz8-AE5U=$_-zB zit$IN1YI99g`9m1ByP9;frvatH*tt<;j$(g>UK1wQOny9!F(BB;)iG$r(5O+^cB1~ z6iQG3@%I4|!crMCkOgjwekTAAu>Q;oOm(ELV;92=5=yxy$PR#Tn}%0sW1uf@;4o9; z{2T~H+P4Pah9124hpg7^0rpn0?m$n$7a~7)ac+C$aSJwkH5$H1@uMLiL)FF#;K}b+ zkqFu!NXl>`^d(Viz-2)g=3?^eM!>L~6-exbV2KZ3ORkhxaee9n%?efnq?(*_IG;)s=G_;weqStbf5X4QO;klmcr2YECO%_Z13mI>WagAZEhi@r-VkZ6OHWzMP zg%NDPzI#%=DH5#=6W-`OZ2VNubjoS5N9D{K%Vc{~eWNMfjXMMBM|7MSpi_-LAJ@9rJOWQXO_rsIK(E=PWMmFG4w%B6k3-dgkJ0&HZ6bshOd1 zS)ov2W@GPAR6p^h-Hw~PDoS{g^lsm_8K)af#7Ndd;p$DvAGayj@mJ^?GUFcTG&G2S zL8iB&F@W}Xj>?;qV`nI!-~H;yL*Cpc!3CjD@v0(WHw4@Ng^-Qvt(;^*!&MZQuR=co zo}!jSwj$Xr`+$3=7!wTzzq~CL@Zixu>K*teP{Q$z2$ZOWwhiU`8!dV6Ai?4K0MAbh zxE|ILbL9%F7qE`In9{2=BgKT=3;iMDU|en*Y)PtRv}QcxbS(hn4t=!PVPbRo;I^)9 zg~q*+_0N|`?g0K7C-uC5uv?sO%ZD;GB=$h)b}dNs?^!+EFbPn{a+|3NIZSpoKGIqH zgxESJA}RLLBiXf!7TEy>K=Jr;kC4MQB{hm|EnH|su=DV8JTLu1P~7#cIyci#e(!4@ zZ1`onC%;^Wn%TQOAT(qM-Pxr#MYZCUm>lGVZn-fZzYQxTim7%_P7vo|#G}bjjTMTF zUaj)GFR?}mHJ(Ae+KYa0!}4mRoqnAu@lruArk8Mlz(JqJ43Cgs6K;r0t3L2k`Y8y{ z!PWos{3n?EV9~c3QHOCOw^pPIY;In<9ygB5 zR~>VAKf}J`M0qM=t(*Vi06g^6U*ccX7cCu|IJ~h(w8Ssa^hxPxh@2@kKoS(yoIDa22P@NF z|EZ0iD{OM5i)lQG?Rla1pwWfsgqIQu84Y%lXwR4F?_;7iKqk_mdO4%Fd` z7D9O^J8bb_!nS8Sms31VRjGi?Mch$RA!B zQnViq_|^O|L}kd>h*=orz&Ydb{@#&s{<{md!QHg`32r^wM#}Vxtj`+;cCDJXORs6Q zjK;el9;Y%@35OcOaf!o<>8?{>vB8;+EXp3=kqZh88V3YEzs%GvR7xUW7s;SGz#8xj za1K1gcSn5~8|lW=Hs`vCTh&43A>+0MNC%!Rbw=+1YhRcI89R*;bk;Y%Uf&^nm+J_0 z6mti8^qU6XNY8)@CiNHL>0A3CHm;Gz6EyYZn@5U4T}Mdc)3r&knF1**@ZBn^rY0{y*BAC&d zOf0ApjqFw zP`67%&unUSN46qR&>uu*Aw7ic)11ToyQVV3FoDUMsIK_{NP6nWU_mVACn~2>2V`&0 zt}PItaw!gS1=xRU8GkS}*qnN8J{Tc4`OOd3uy?v@Q_eN6+dH9eVWT?_U+h zKypU~(^-1zJI+!-dzoo&4qHxr;qrb8S{URe^S|H_I7p)FillWaQFoc-dBfK}abO}? zu+|MorZTYZ{DsrYg-9X5fJ|t4AK6pDgB&glMs)Aqb_Vn#=vvb9J77FvUGE%_E(@2p z5%ed{{lwyx*cSt0^IE{iEMsglEC6`4GSBk?de7pGiSe)GPQnD5f$7k@g7?T2&Gb(@ z2b*+yoaZg<-NdEnj+`KVxb(e~$fkwPb%Rx`H%hAJ!RzwJDba{yQY{rQ-UAg9e@G_I zU^d5u_vW%(72DjdF;f()u2H(Xo|%nY3Uh04`coFK%w6+fYQp1?X%KruPhpI+e1un1 zj{b4<^`k-Jx}E6C;vT1w)0R?~SM-*qw-6nlKdNKC^Za*kFt-`Di7UO6oAwt0#0SXaddE-#0y zKkxTHl8G9PI@03M zU%JA6w^6#yhuh(e9-RZ#!+pFcfiNBWuO}#?qY5cs;2gX6;k>?EBb;^;_QO=2oEZA- zVNkxUtYF3!SJI&a^Q{tJQ|FHdB*jUAeUe7mm=3e)>YrU(-!{1{bOSz7x0I)1PKF$tX>#YhJU*$e zUn;9FKlWH?fHX2KO{7p9n*p{-ixE`Uvp#n3LUTB%)gENP&iihD_Fv>5U6I2yiJl`c z*okrSR)Ih4b@fV!A4X^olM)s5P4_E4^eiU*gDB!JfT&oqr(TUc=mEN; z-6kJm3@x_Fd;iLknZIv~PiFe=0?E6W`!w`43nI;BDN7~lQWv}>aakYVmxlER9Gg1w zV>XG{>xO{zah_(2$9LdFKy?y_5o4v4GqgZ9wlZ3%e zBB5_vUvzei!34acI)O~nImUi`A5YX&&5Y&d8Q;i@Fd}`tmFWTEX%XgzTG;L#6(xdg z%#JNiwe}iG!Co@U#IaYCg& zd*=&0tB@UBWGy8^fLF7F)4Xmq~crE>AyUuUk~;8EUe8gg)nArO)(3^ zvG5+5bKbxT-r^rL$~9K_Q!BElQ6=gGzs=dg1daU0fdavEu@szfo0of+hck)d9<`Qq zqk^yMU-vu4zJ^%Pg;$lvR=Ra#I7H^_|FaFit{nfDaFl5E*p>EXg-aOpDIQ)t{nG9GAA6#Nr5TqT71*SA7GttG*qETQe?-uaQN($S+>0Ur-&|xnj5Y+m> zmrQM(J-2xSQlQ+P1$d>BraWxX7h5T4xZQCll8Z&!i4U+^K2^i_J`jqvA9nZx?Wr<4 zMNPS&^MkYJMPyy|l4y4A_7`DMmc%|CGk#@QK@3mI?;G@W7SwaAYQIxZQ9C{|7%sfH zz3av*&eOSi?+&5qH)?Bi1-QsJQ;H#V#uTehiBBV91^UbDL~5zKP$#}q@ zSW(zn$yfzQJd1|}Qiwr^ZoqkuGp)@OMK>G7L|R39-1e=$jwyQ`SjFqFVlJr{h#jub zN_0womB$^eFQ}8vDqw1Z8a6Yj2CT*mut95&UmUZGuS47Sy@*fbZ8z5Dg3nylAboqR zgvWshc*%C+<0Rq`jEMM5-OQexI;FGtVvpLPNz(sN5^Pnhb4`LL2YxK?TI@#TBTY;9BRG$kj8H z15Kj<=@2^M?Q(VVgnGE^CnACcV&9E@qeR)jy@-Rd^b3}hmnA^z-5)v9_B!^7 z(LW^A=ODP$#+}-o6xF^^ zMkfQB?}|i<(UlsTemAW38mp7eOv$vS-B6P*EsJEl6uPbJS9ePWx???3bRIJ+VT*Z+ z94~Pl!}-8Ym`_L-845l-!Q^8R-NvE>d%VS%t{mc zbi990_p+Rc-8)7uNym8sF;a=9SMSw0Kcbv=UK#l%EIL@ihqvm3bx_r0&WWOlY;yY_ zK$~%fRciY9i?*SJk_bb21(P*ZIHPxkRM3mJ1IJlHM;T(w&4lPA&?s{Z2Sd5pBg@8B zSdG)TA*HHH+laT#k5Cnv20oKj*him{;HKm+9_h9dfcU~+B* zW`%T+$!&6?iHCzC)Ph_`)}+!|k+f|i)i`om;uB9m1vSa#1kjizX_x`QMPs0p*Vm8a zY8)HGMQUTU%984TF0P?%BbUm$1~%r8P2qk6MK#C-Z!BdwI|?F>v*A4*5yhtTRhuTZ zZzhF|6@xGK`9y{j&Q@1UvqF%^gH>%N9=oAQy@0-cs7eTW>|EmIGtKVK375`1^PXs| zT}6^|YMpZd1~|_5$!54V5WIIZxj3P;30(j+&prn|6v>6%W=@hDBi|p25IoA(KbNiz z%y$dtk*4v$N#;y4$Z}J?B)Iy+SgS&eD%N~M`cmW5+$tAsoO2(0u5qZ96_1Yk0;U7c z>CjpcE&k(4i_u~BQdG#uegfBl?Yo&XiMenGQ@h@>?&xJyL@7FF#2AF#nw!&es3Z-X zbM%|K^>2x9*sY`r!Sst_$G>B<#+W4?s{VP&Qsc(35W z>?7;fGc;{Ij11901>>WUyhq_>=F-Gde_$OV2C9ZW?jBwYbC|`7Up@&gMWArCRDNI_ zxhUn#UB08B3dmy=ei-Rr@A?J<^b#ON0{{sITdfCDx+)bAr=3st$-z!Q5hINt$}*7- z64DxQ#LMvo4~iG;HmYM`W>r=wxS3K#OWUR^S-`(&lq_CZWfCFCmpbn_!jIKQLFO8T&O2Z3#Xzpy_PX;~3n2 z;D06%-fwYTib5)oSKF?LfRtHTlV7i@!qykI`X&PBzALHFo8X27TV|`ky8G|O@^$G= zgSE1o*DF4V65N32+fL=@o49(87=!htJ^Z>f-(@%|OufVP9sNCfCU#7kf$6e8hh*}P z!(3JB{%ma{*-URr7NHKSE>eXL9$B66R;1)cs%8#-WNKD}8HV|!&kMZ?u#L`r(&8>9 z;zMonICrrifsdXFb?D~27JbLmq0qY(w+w&XW`El%u_EmnZ?EIGTv^k3kcBB-ogsy1 zvXk5DY}}r9g~nS`JByl$vDQmV!!8Cg9Oqo;7TND-fpypg7{sUPj_`SVJ6!D1YHEFZ z)!P+0E}M(2bXoa|GSdQ=)7>6k1-&Vc-6le^h^6X?yc(GD-BwFUyzbXAx^cq<5)_Kp zUKw?n)ykX!3meq)%fceha~Tz?Uks#iDMqOUs1hd6uqxm8=$mrI-UT=&4nWVc6?0TO z2DDJOJb~;2zU7P$|27lG15?o5F$UA2{r&2-_%_An zu@Cq#0Wk}5GKpqRQwBgi-vd(#Iz^&`Y=>NcYP5LTaqaGd*VGql^7EjA(9fn#@-<2t zFWA6eo?yX$uv7Y%Cm4W6F|{$%+%}Gy!XJ-zR#uN09&YGpfg55s=F3iwG)U)lrjlT& z6)NAT4RFmTUop+awvLsv?O5v|pwRZ-f3@B9d+eO;r_M zaQYpK$Z#E0@3x<{o3v4j9GEYJazr{TmS|z_f5~SpUXs2q0`-m&wLZ*2WtgtJA+$tK zZx-z;g`mL>WPBPYhi;Cuis@~bZbfpkn*V< zjwdY_l8K(OhMh!WL-517F}QQSaK`?WLY>a(Tj#gxRwowaM2sW4+v@!lXQiLf4si2! zYpy##`wX8fz`si_KenStCpFEk8+9hvc~^bvFEdYcTq7Cefx}nj(T?8ozx#iHfSQ;J z&~Z{&5rNJs3n7b+$e0l;(^Y*7y#~aJt)7R=f#X=2$NLcI?9B*CFUgdT0FZw6*%-6~ zumS7q`eHkJ2mtRwpSMPGgoCB0gDtWDi~*%GUO*HG78;y(r#`7yN`Ac@t+eb<;Be!z z3i&9B4h@}j$&V&Wi!q>SBOC3`N%u7Q=0qeFdp80Z~QTMx9zLBjAh)PUC z^Gng6*1B}vOV_-&8Xd*3!#t`r#O}Etw zpK9G5!OONCjq=Wia(7l^_x3x}m!%F`4v4kGB-FB=GM)WV9yY`$H_4ea`^+nmrmC^E zu{T-1>OnT}$386^&(#XV-lG(^$=*+_Yab@)#F+Y!tjuJ4AQ6&a3W17IQg8eJaLGTM zBS#(`#~sXl0AJz(ZJdU89)Zk9ASADn4cZ0eJYyt-dhZ-jdOjUc4AKN%J+Je~pbne8 zjwAJXzu?g;5En_r?iDFu`4)oJ_BZX&ti*5kL)KVbi}Z_>BrR z9K;Auc#@&_-U=RxJp8VDDBgs~Of{J!)ZigCIVoNAlEYDcAB|?ViT3&(${Qay*6BUt^4_%hz4vY}$hJ9% z+HYqOd0qA-kdSad7>$Q+X2DJ7ygyW$owbQtTg7@0E#VR@WY7_y{_=*vDc_2NxyDb8 zTH@~CwJI+SI4QRp;lllvD3)C`ruV$hb>bTs+a8HJvVmE^-LfOs5tao_q$h6zsjxti z?)eJOfXJcg?PWN}vGK)6kcS5J|GkQQsC}TY&_?8wdz4$hzV;#8Hjn0;7WTJ`Nr}U| za({XXORDkQ?;ye{fGj``AcqD*fXGSm>~r#lw>{O>q7B3c&oGLl|7u{tbBX}X(&{(| zxnP;Ed0TY&Npyz!l(Xgc6X#vZPg$u%Qv_UIK^mL8gL3uIZJ#oRE`745SQx|c-NMYh zq-hhKUwxo;F60)zZoauVV&$}hY1)#lVDtEswsns~sR}`~B0>{$zb<o{E)ins5ZNzVuo;=RV#nEM}=S^ZB2c)G-hX2LAJ9qw_-T6FI3Zxc>e;;Hc_lB z1ThR>w0=6kwJ9zwx4O)7=#xQ`tqZGW@>#7!O?|pNpvuux)%6E-Hu%iw)a*VkjF$Ur z12w}PS3i$vM9ZFuv^&Xn4wd(er9xsE>rT4$KIT{t?4(w+p*3GD+Gw_OL)s(7 zz+;oCmwKdWf0jp=x~N z^ERq(6XSZP53=p0;O6>#ioD4LLIw5F2LY*ixirc-K#1meWdXQMk$Kf*jO9q{5DPqF z7XuSADWaIt=xJkZhjfBjeUVLW_!fkUzbba7Y?f6DA=(p&X}(XUoa7Z)4U*Xy+BV^b z>EhZ{q+br^Pg~vw`n=xn|Ja0BgmF%iJ)SdL=#gzyIw1qfIupTSbGorKc8uevmkST` zdQKjDF=K9LgG{O7)2RllK~g*x(5X1q68r72C&oh{Py@%R6o$4dGwP#!b}iBiRI1T+u`IC8C=Bl(hF=6(a?JVGLSO=!-Iim{CT%L#dW)P^uu zO1`w83H3|Jnj5+Z6i-lei0?+-ScP5JyRGUV%As+O-f6Ne?`%!FmSUFzCak?D7!;*n zG1;CTm?@z>=)S&vg0Hm5Anemw`QA8ilzp->9ERd{V}$_Ya|MfN`Mb=F0#OT4ZMYc& z0mvAc<_*nCV;97G%JkARk*D&VzIWz$8l7!=l)R(7t+21n*T1(_HgcU9{(3oWF0T;x z$3v5TuQrpAo3~0YJ?KwKDmR}RzVwPIaGJ+-ptV=6sz4-^Z`*0!45FHw<#?FZ*!Y>~ zuxiMLf7_8Lv=K%r{R(NT;`HG5~0ksmqlaUC7n#FC=3(u8k?`ElsfxnonBQ(QXIaDA3mlK z;I|n(Ix674{>ZB{l(joqGvLeCtIL-FR-8l~E0M_ZGEV2y8a*&EV*ZZO<{paC^|Rv6 zJFM15-_uv$M04cM8@=Y=_C|Z2xqBLF`_N-rg=-AuT|s!(t?-a2 zRcL5cwM<02ffnoH^2~*^iqefqI?*FnD(FyiU-ND|`Hi|oby_JA|B&h5GC___D2-Iz z5}Y4Yc+7$6Dm?lFD)3sbwEIsJ(QaiX+BS<5|PN94dMs@&aA z&Q2(=$`%(b9sE9N1f85d^0qxE4my{$JAaHq5I@$s5@){Gx=4ODH7JRcNN0^NU5I zum!5TO(Qd^pdFhKY5gAIg0pY39k3A?R6%M%`*9M4oNiE+6@@QM#6>#%sx+Al6p9}o z39;l9*V;Nr$=_85dtiO$iL3J6rnc3N=QwX(zgGEjGY?HmTab1>ZGg!~e{|J32D1Ao z-4Q0LG>eKt^n|2a>q9ed0v=6O633xk5Yn}lMnF27pq=(UX=|RX!_IQmq~M{1lc_IiAN^x+GUaL!$m&B%P&v; zX2P>|xG22y-W?vsl+*YOC0v$M_F%9W-Y8cuD&wK9VpSE9a*}c-31(_jU#SXRkbR-t zGHaXi`U6bBTG?;YlzJjfder8LfRUJ3(e>?DW;vcElAUkJQV1~!gKX^0Xd0s>mZa{B z7?YdQ-FAJbJr;kYUkiP84X{uJj^XDZ7v%XIg3bf9VUWT;x+ zPmqD?3PF!TO|^Yi+Y60xR5p0IbpF;h5hDUb+AAeq2D#5wX-xReM6qQWPQ|crzp~og zgU@n`I;#fpC(Fd%#eZgrb=5hk9Fj_HaNgaI&;qod&G9{rgvj0k0pC28!ts^Xbhz-PH93HzQLMq zRVhz#>cPe1^l0F=CUP>;yprPSc=u6IQx%QG3*yUyAa+$^1b&TEm@7*rhL9P-;g0R6 z%Q{1q=B6Rn%@qk|EiPxIZ<}pKRgHj+_DWNj1oz-HqEv`uh*gE8l@Q%J{B;*uLceq+ z^pt`3U|%L^m0+j>StQ!S7;(hY4g1Q_IUSLGdaob^{LtX zcm8h1qtvW)MSUI$STM2ihG*J{k%+^o0A{zn#MVl4^tZ5b4s1MvbGrmQ81CaZFDr`Y zYm$ltrRDLBkG(AY=<>y6(G4Ct2L;~vj-7CW9zw+W#KW4zFm$riUOdsLrT+9q-c9qh zo2{bEc^pm<`Z#`Lk=c!#&`?*_quw{twIaT~j(Bm)f>ZFSy1A( z3P*_;E}e{rjiUu;gDW(j)^#n<%RSCsX`b1H@_luzOQGRz-#}HI2+3f;E5TgvLQgRX z8#hhzy^C6Ml|QfOq1$_~N-6MXi)m7>Cdtk|p=QFnt)uKwCoLP<@pS%>*j5s3ikRH=qG*4vuVO4Z>|o?@c>UF$a* zm6U+FM$TCiEQoshxo5f3ws|bcy}$Kq-R{x=dwowv9ReNXLuCeI)-v%DjnHd?-a!Q6 z57j+h5rogsT&SZvHfoe&li^mJIibAmRYQjfw4kGnnmn^;@vBNMj*X7bB!?vEwELNk z;XuU{KJcuCtQQ2P+SpbMEnOp6@Y^BDYx;FT;B(fnK&)JgYQ0KG44oBZ33R+q+ZK2* zqcQW-9~r#|uE_KK%+Su4z@w0%AX|AC7nwLP2OqWNt+&H#{!M3+Mpn)}cGSDzl!=v! zUca_9d^uEb?Ts7_e#Ke2NBZHu4*A6+x>hTBj7?_~tVT*GU(c2r(!YXrRpBeA27bZGJ>th(zan66G6qedGH^52yzdZ;}r)3+~WhaFz`%IY}~)d z!(5AI$>NoM%Wf`0!QU=F)viy28ZPbx3z;PBgvD)2!|LZgyOo6z1fkC2e|9Y-oO$th zs+ZJu@y>bjch2OD>a-o6j?Bggw9uxMgo`6NwabZ03rE>g{#t|Cpl()MUHa9VUcskd zUCh{&u8AH_v0Q~(o38V-G&$u)UMSw~MZl z%Tp(N1Kz=od$3BU(eY-55xHp|ev$v}z6+2+4e#_B>nLd6w}OPa<)DY18V>;2ynD3B zaM{q2$}9FjNyFS|kAwNr$_Ce}wvQ@SU>_;&;=2`_8{N>OTklFFX9}FXchtV_kEG*z!&B+S^d`DbmK1 zPsJM_^6-*`KG0gBBVV6A$ZZ3Go(*RmXc*6ff5-8;I-hGr&RpA7kTB?liaLjZW+oLN*4Jq)bbm#H zZOX$1#-suO1u}2g84xw{2h+s#%4tHpbqC$|i~;Ea{*vmnS%OZsF~aj&c{U(LPKdt( zP54fa&Bqv~7>Et6MlA3VQy1@HMJ9iMTQltZbu(*%=v1y>eZwTY0effbuJ>{6-dbkl zXisOY4WMH<+HAIOsagQUw(%?*Ky!zrU;GM@HJ85v*v~FY24H~|qmS>EVS%15HVjl8 z>fh~t)4`SgqV@NV``6-wA2OWL1L&dN?PM0PU?Qf`hZBEAjJl15j*fu$ArQ<0Hc~kO zwQuZL#s?n^S5@I|D@hzcqsAU|_Ll26#*pvz1fVD=R{)(&jcz9B4~Iiy#DRU#68`ID zHU~5zC2#in?7YiVLegC(t&G7cQ9b&CgyXjYEOZPDps*z?MgX-VTqGogJCNPyv}Zoi zBqC`(m;3+N(1T{^0Tj@PiEc2!-+*t^N4Nmg;?2haHlr0(OdqM{gh2rN-&h&S3}9ca zq=FNbr+VJ5enWs}EDqY>4ikR@>jqOm!2t*M>5ZQbi{lnSBA}Vq4|NBOPQG1!eh*Hb zg|$?D9c%brv84ucm0^H^?ZpQQbi7HeKuD034`k_NaG`%4_WyXz`f^5~HV%3(-s9jC zo5^wnwdSCKSkGSnZTOa`a00=?=^h}ccN(|M4Cfj?2Ni)no*rm(CQq3r&=wC$jxYnS zlU-Wg`{ykV=3x|5^a6NzBC#D%MZ!Uj#}|=QsC@)9;UD+ni#!>y?@4*yFh#a#0PO}j zS0F&FaC@$Br~m(WoqvFqAFg0{KG@2>M|IKW82jLB1h7@>G&FS>ibomL_$PxQcCaV}2tleReSg|7969vDnvD;xDl0%Xbi?BYq9L(9r?RpW)N06?{HugafYL z27Mwc-$ElQ=(_g+2XMe^LvO)zxW0Y!^;V#$M)}V1v=6GwIOOP{=6H?9?YA!b zf0$$^Vqd6q&@RA6&jaO-&Kqn+U@7+&sjsT7q$p4?02R={HE_TW(M*qlO^wngC0MvR z_PHVz17NLDyJ3KPAWP6OPdalJ`3NY4TLD%(U7stX>zX|=DC=Km@F##4^3nW!C_e&U zU&c0_$rWJF3VgU%I1y)KjZ^>(w7WNt?<24qU-v8!(g^T~Wu?VhM z{nJAF=`CT&-#|}@-Uy5B=hyuf-2K|?gAdUI(4pR-QyAc|*lyNjl$=^Y4y{ZXg7^S@ zZYuzON5AvM{D$lrBX(XiS}Oz*p@e@!3d1?50+Q}Me|Ar(@Ubw4i?R%D)bx-QU7EgI5*G>!Q9GLN@%H+7&Wk!7n(K=7sco>vkWdBhfl<4n+5|w^UJK6 zs}U588WY@g7|m`uXNsAbS+(1NehH?}Nh@{f9j>HV97n8s|NU_=(Qk-C!3!x0e84wB zkDR6QMN#5uwMen8%*NP9jx;2FAJBg>6K@<6&`%r6qLu`?0!S;ehU5BOGlxJR>BUz4 z^;K~jq0;Bw0lG+$n4~9>cySKz;x$8FzXP4ncYB>>0WUEec(4E5__x9^jAm}$19)!h z0^)w5&3y0NcEFzl0p>Di4=|HkoEqPz+}=bU!(OrTtt8=Ciqi&}M8vJvLtPYDK%{FS z(GmdhD>j**)vRahcmt(IZCAicj%o$KY-uRN$WE`S%I!5xuMPjFi?C9!btOYAAnVwp z#$1~HS&k&+?tgt3H0bvUZheED03~f*!$|UQd!R6Y?36OTO@e*LRnw48^=*h%6%!kYj@VHy5O7d6*Ry=%-@@=(FXlnOH?l?$j~Ii8DU4kJeh7=@jXGn4n8p~S z5zHaCBHbYaHguq^8{cb9n%fLb@Dc!h=wGj_YkHaAmBGdXkqdjvkUX`1B<4r)4vOcW zi=2Op{ZanY@YIAi0Z|EHSY|oQdlPXo3o0k?Qn-v8JJ)?6TqtTddpd4Y)>qoBGWuQa zoDpwWgQ3kNd)CRr>9E6`r`1G+V1WRWvIkl14TwPe468C;6YR~|#2w}tUObf(831S6 z*EXDYbj@{t@t7Dh_G)b?GuF*jeFdrFGY;4$W9Q$R+=HC}=pkWy1Z4_C35Y8Kfq>5) zMy=EFg0n|#FR?q1Pr>jX36i^M@2ekv0FqOAr>9D2ZtMRvr0Kurz`A-B-};6pDUD|6 z8Tnq{7(Z?PLg_O8=2=7;Rfdb>=ZEtCn}xM(wL$<&caBrTCmpm}VR&$A|3FYxWWQ}M zX~2_lIn5~)EfpButxR7y4oim)2{5B&TLoI5exxqasJ`dBjpEZzBM-Q}HXnT{eRc!Z zcy+Ox#E^b#6>&H)(3{n<>1wK&maCpKT9GmajuJAiSW6SBlnO#hd(D&2oydubvef4T z?3yC$zB|o};l8tKo4e_+)OmQR>9#>A?`t=y>bXEPq$vNNi}+hSJ7|Y|Xo`c|u`!)s zuD2yY_u0hF^1GmC_^^v+2E>6mR0nhnd01!>#!IswX zzC271oG?!*pkjg}4%4r2u1?dh$k+pO5o#uJ305J6g|qm_dyqv)_vQ;k1O2?jm+57Apx$+yGV7F zY=$fGt3&a5p#B-s?-h~j+*_-YE|yf~>Hs2VeOJ!E5uVud*;bvTfQ9a-eS zAp7V69>;^n=`X+ScO6A_1?fKL%STi;-G?stX*4~M;aSA;1Rit;dmjV@Ke8DFi0ANM z8@OA|5E2+a15xB&Nu*akRb9$auElUWrge#lXs{V9>N4@$pqvA-#(!N#BMe$Fzu<7= zMn@#|-0*hL=8N;@R&%0B5C^vcFBU6{1e~Cfwp@8{#P|EoFw zA4_rJkKBxTFBiwQ+Ih}EO_DC9W#L8AE&$B(Rgimlu4Bge0C`NlJLyqm9+ z!Zft>E4=lcK%MS?U5ubeGH%8#Fq3_u<|M8d&D*1+mP6E%yk=ea(LCX^$YC#$_G6|a z{c#(E{ML(5Lj-N83)qeU;e37}s*&|1WXbUweraSs6jE zybC))%J&w7@xM`ZKKSfIj9 z`x(eK8A%#tVC*Acatf0m$7RGMHyOCN2@drS!+P2 zaQj&>lNg}o0E24w-OM?r%TvJAwt_=C$!=y=x=__{RA7H~aXfZtB1JdqL89+8)GKld zC^#vREcG?HcHJRl-{f8~^533$SPUuOD(wkC1|3NwtKwIu#h=xbWOr>^mN+{oh>Cg2 zKauFd0Qn&&4z-v_9k3Yl;B@ts_tG`1Bm##ah79A5PEwu9#Jsqk?k@oOWgO2u8i&)j zB(XrD;5Qra9}&tR4=AT9(d69^Dsx!`OdXt=#5Y)8&L-z0C&fnbauN%)W!NAdxLV!~Nx~{IqHy&}{ zo}ijQ)_S%;Xq7~CTM`FG(ghN<_)}?@9Q1Ii;YruUaEsv$MgPcWv~6^RLJ7z{`*(R; zf}Qpy^Bw@Q*NDA=I3l>yPn8=<;&~gd&Ks|UqxhE;YA)dC4dU$n8N8t^uc*G}Zh+G9Vgsb19=v!UgUx<>?f&z}X`cMDtA%l@vZ! z?%FQ*SO8A94#9~0L=5W2gC)qSgV|cA>QCG0e%%+Sle2P5_a{%VFfA%tCZy|t!0bl; z`yVwmbyZPfcEr<9&+S=COG(QVvZp)PX$~7acN_s|7Q#=ge(r@p-rwYfy(pkp*Klz(B^S7 z)VPP-mrZ|4fBmekiu+p6u}k?&4B2)P4Vfceq6acpwfHaw#L;JLw!bBbEdAOF{~5a= zH?$B8c?Fb-0#k4W?1?w=h2RR#;u_>XuOR#NLtY`4WiT?An>V38*Um<%2fSgX$t}_q z{U63~&@@y=^uCdA4lz94=_jw&YkY7f-73k9T3mI`5chk-aMR9pZKj*|E~}H#}76B;EA6> zr`|XL6-$gxC_D^fAL{L=A&PwBe@6cP+Yi18$lE8hxgfPdPS#JBTN#6v8$MEe<;pBS z^#(C&euo>fv~BixX#a9eO47+H7Y(HPCQ4n;m@XKm4zSkW@PXu+9?U9cIBLV7+dHfO;eoBGX2fDTRg2D<@iPT=WJH44WdZo{^g+bwq4qoz6Ww6*ub$ z>e6%Z&WdMXZ!EFrpZIRKQWCY?m_aFS+hKNy;`~>{4W2QMcJIYu{m^V~=iN%Lmf4(w z&H>i&tFoZbsY(@p9+{x3SEUP|396A@ePB_E#15h(VZ38{WjlpL(60opKzFYdkPW~E z3xF9jj+PbL$6kIu`0?+K!XPucdpyLa>+Z?@?LcP3G5_t3K;KE1<@AK6yvk3|!H?T@ zMC+BhY@euWFeI)a3N%Ft57+w7tQw-K#uEISS1dkrt? z3-4BGlQDkjo?pzj+V-hxUYv(cuB~p3a6+B zvuVcu#4SLWopdER?{uyJ@EwODkFCyW5m=QEvRc)WFPnhdp|}KvZ+~RY*bAZ-V^AUL zt_0yx(faV!uTBBUZdR-c7Bb5mvAXl>pJf!s_y&e-u+N8#mAbTSAdayiXwj!9h@gwe zci4glF8$9R){60Q(j;SND?tajP_?vcr5AA~IwtqJiKq4(_*@}Vn{H1tSr?0f0Aip> zC%$78gQHvs-)iC1_{pf>_c}+$cf5S(JHzv0d6yk2!?}Kr~1#7|LMU=2?a-lDK|L~lt(S=C&A4d!WYzs=xP zO+FkCsN|JrxAck@cm6sN>Ng8JedRybUa9$M5x2Ra^4+HlL|tXLN>-1kYfZp)ujWU! z5sq(-UwwC{+jnz0pyKb=x|GTw!jLeZwYH_cNAwL}xpzLPd9u4>J83`GwO5fAIPZ)v zKIut>F|AP&*Q_~Lrvhwjy*f#Wc4y^?%^XjwC;9vDllaWtumYnMFiTRzfWTrHhr>df zd$;gbvGh1#%my1n1sNt5UtOM$`AJ!-CiCQar-{2E>z@zhDT$GtojNTSTxK7Dzq=XH z7lg5IK6snLIO&eVv_pqKh{pMJz5+B36OyVyv5^+k9KgJ*{$I(J#4dC&4|an4J<~~J z+k!drF_=@bigCGb&MQSx@Xm0oSVEWVc~;C0?bnhNENx4=&g*F=Z)n5Tp1yT!sWB}c_(`zyq!$8dG2;)7#}Ga zMXqWSG~wmF*IDaeT$k_}lOVdzQKB%8zS#QHPB@Ex-{dNMC+*t92%k9f$!SB@;bZG< z+ykt>4Z$Z;#1W_8-5>kc{K4Q+^JQMO!hOr=|Izi{(QvhG{BJ~$UP6doBhh@4ZGzLWt;s5WROH2orUPGDe><%-Npzecp3^=d81qzpQ0hYwvyUd*9df z`F^gm@CY|0meR@Ueh0RZHG?dJ2qT-{B7O-Ky_=y`@|DRAm#NgX&njz7FIr!JyZ`0c z-NJp{D%esxE4%^bR_dyusY<9WPz~KYDNs{(t6>*>u;lU?BU4jWn!|(h)#n{<)}rh3 zucBo--EE!s?Xc~x%%LsnK-v~-WIqHdQEv;JhyyP~a*u%q4ox#O4GwxhKUyFe|l`^Iz$2DuTDXY)#pHPF10)O8u*g8qvF0j7|+B7?U_RF zx#$D*y?#0MzgyUkAMC*0k_4;g#3XrTU-uz4!W-3My6ip6KCtWt4Ts=mH*EZF>SoaJ z;REtZY}FfYRa`y%$_pVM`{lNcacec_8h*;L0_3x-h0~jdVdi_fQy$Wv<_E<@)(G!P zce=CLr^Kypdf(o{O9y5?3sGwo@8+c|eCscnSaR{=qxWn{_RQId58VuU>+j1x1HvH( zN0Y|J&7WTuxusV4(({9>tQx*#Zalm{k~T;sP&9ws*xw{LVwBdL$;BqITbkz3QfRd8pcQ=vfxD1qI#SuDr?b zE!KjFjjq>|X1sLpN4$~>?_L3IGy6YD;qS*$@M3!|Y%+!_pbGb<+S4vt3~$)>cvF-7x}1|A;M~k%J7)FV+AvcyHD3QD|9;QgG=d!* z)}+ceDxRBy4_(YZ^t{-iF^f@-)HO6LM;jL<9&H3 zfc8v@pKQRPLGj29^21k*&}8Nf6L7VfEvJ0qJ86=fvA4 zlhr>VvLbf!;!*x~7oSx}Zut%h`S4K)P%9wT{dla-d|Q^F1cnFJ2H@VvgzP&4kinP5XkmQvjf1s}&Dt zZ^nzn8w}RrF@0W=jiPp}>UAyQech|~Q^PL97DMk8CH{C1$J@ma#3R`~Q=pmOod36) zu`69cwjC%7%h=1FcRgO+0G16h%UPwHX}x> zhXxeDghaewWu-NyV+jy!wwwR90!uE)AF=h(aoG+Wd_GUd8tyji32NrE2GjTM8|kmM zggP!sJMUVadlBA}-LU!^Iw!^FXvWbyHA|0jU~O&ZvpB3p7K4=OyCR)Y*3}ct77ZNT zwt1P6!q)FRWS&eCNQtL|8$K5|h^oX3h<-Kum87UZWRzk-edsJI*4$bs@+XrP?@Ru7 zL!@Zj7vn+V_Z^;vKMnVT>VL*stWy{;k1+sqXFBXD|6UZhPMXsH))JJ9Z*Vy(Fljg! zl5bTBkxS5~(fH2qw#&PV-fz@vmC*XRu9FOD*;{n^{OplJu6^gjZO54yjUNS^ll1a| zckylWTp@MB2#o>QS8bEN=SEsSas68=!9U)iJc?Dwu-fep^=T@5`1P587u6@8Ydw6g z!CaX_BiFh>VY8H?xaM$rd0w$gC%B zsh?`mqgW!^lJ{G+Y4;nL@Xzw2nfhZiGn0@vTe(OLR2&FzIC4r=YVvH0nHb!7v*%z*2Kl&>&>XU1{NgD{NJrv(cU{?;PJtMh)3;SrA%w@w6PTm&P+e}xC-bJdd(UVK( zCVUouWtm4CUeQdp=n~~Q2@I;bRof6D@@b*?+t=u~x2uN1{%IB;l^p`v?+tWLVvoxR z5MDueBiY-0Nph12+7|6SI&>cHqZCARka1N*ISMAY(EI5r47558UB0!>XM%m}H z7Q&7-`EvZ{CsH0_ypeHJF)M4MjnqG#oE0Q5eIu?c=31_rWtZ3T$B3ZJ<&k4j*D1lZ z8cp6ed|-R!PG9=qz@Me|_^ZAh7b+JUG!h@wjjhd*;)|6iTij0vK~j|{bGSi%MF=9l zITNl@HFwyhMUqwYbV?a9ep1?Wzf(KwtM`&{u+DyVtNqFP72gtIjEUMRV!x!7W;VXF z9OjCK6;Dp=>Ru|1g9WxT2rtqd21gO+jDNXfx3Ab|;xHRB<~Idi;p!roC8TI;XRpU~ zo$C<9B)GYy#@K(DO%QpX=gJ;va?8zKGv+k`)7h1O*dhUi7i|c7gIVH5%<~eP5AG zjeXMaITPJ_MCG4Yf!JG0)|5#UFnWcTaDq*W^gy%$9VO)~2}IRM8coVut9DLeL3Gau z;FU`a-904nKz>%dNxeqPC2iWtc|WjuYs3Y&S_lcAjqshR%>S@eMyN;NIL|FT{`WNK z3pIHFRJ<$o=>?iI+?1Ss`jzV{#G&`Jp}Arc*BexSE;7DeY!rk{jf2(D8l@dS@lm8?$d0VO_CxydDfwR9uG_uJ?bQNuKDJ-(nV)DR4uIdYn z;pEIjbWp-i$(jLj8XV^Lu@Eu5M7NhSwy|@Qzt|Lib>e4E2 zueMX@B2o<%-*;^i)L=V-3lQu-=lh*IZ@|^wGi?EPKLkBD_j7X-i*}4!zUn{G=S?nj ziN{fV1KU}y1pWi&Lq$`PYht;Xe9*g}2c7hqpyy?eH&t^r>m-wZu6qjj4=QvsVjhiG zn+lL1VwMuvp|sPsC@&v=5(M3^MlYqnVn@@Pm0qcnljeRx)gZ(7*Dy{@p-y9nO96qL zg-)YSkW}#IWHlPG0vk2-F`xhV1_k|C&9HLb-uKmtO{m8g;ox=gRr}^fI_EXEP$yif z%K@IaHeKeE;2Nr)rC##t)ZHIhm6;3~%?-AX2+9)O56;9u)(iVD1p7=}CXwz3nm?mw zPIdAtKnEepK7XOn^{4NS?vLQ09(o-lgv8VlaUqVbBRs}ABn3jyVHHnxFkdH)B7P}< zaYI}TRZz^@@NNe=XX}=ROX)CmB6K%|ey2Mg3@P$RbAB%k$%;8ZJAV|8(gTnDjmk(} zG!A{oI0T0kEtd{U0iD7-`{gIVXqN|oDI=Scj!;2M#^C=+x*z})@d37jgkud9OSE^GOpv>JHTRZfn-V_Y$|T z++PEyNjMn*30-O2?{NkGCTCb0ejEOX`Cs_sl>e^3{BP%{nVETV_;_==JuYT=43~>f z(ksTj!B^TEBtfu^Gkn&GKR0y-MQ#KQmAScv+(Ekjh1PbDX7)E>AVs|G*)W!2D*qz# z;b?)jLo)e-4kX3)$1augdQ`Q^6d>TEdl?^Yr068OEtrza%zG04N_~M%i$|^RH|svj z;qg2B{z{+Z6Kq!*hH#R)f@`@LZwwP}cN8Htc?j|0Chpzfpl}p9nDW5xZ205Km{|Bv zViR_mE^4k_Jyc;AizD1PdrAmL^a zy*M&xUCi~6>lBIQA1XROSNx5LpsI&(eq;1 z7TP02ufao|pMO^7zSZ2d*^qs7O?s^*vVN6Oh0r;`b;(Jge4$2D(eK^e-snh)hd_US zM~?aWt^e72F|9@jnTWDh46HZ9?75~(N^j!%U&6D}%Q<{6HmH5D6klAvFSL6^77A5a zV(n91Asecv+3racu0|GH=YZ@V&Zq)j7F~-vRKs>~!#e)i=xVp!?u>4N=cLPLu355r z(RG~idiV1BdUQVs^74r~aA2fTVF^pEhyUS~bzP_l+&|fY0~b<#Yg|GHz4{{cy*?pA z@@dM2QQRk|mgIfg;+aH9F?I9x);5%`U*<|#l{k;U`Yt8mJr-x2W> z0Ky438u%?Bvl0~0IRaoOTFmumfZrowzJ7#PKLVVtpUQ*}`vRwkFSX8KfD{SMk~}_a zhyP{Fqc!%MLTqSV$_GNZ*(fP_`e0SuvPgVRO@h)>C#FgHA1=w zIvtJ8_2{Q-;AM*X2&`>j_k%wG12%*hLBDr2%v`%HD<6zr)sCy6EE;N38|7m}9-Ks} z=QIhrHb>x-eq7o)QgeykDi8_`9Wn zAXM1)4jxw20NbUIf!c{)AI4L4Uu;=(ZyS$=lQt!cpSl|>~6+@Bum1(klybj zH1too4DpQMC&ox|9BplmB665x2#jhytJ_DkZ$Jof~LVW*G3u!yKcDvVn7DYsOc@8g!zsUOhoh|)c zR};RG=JSH_!T!hOZUM@5ATJ5RGE)+sW^&3VnB2K(z8|}A?55O^b?Qh(?x8)k6j@#U zxI=*bT!?hrp{zXXV+q*@=>UXDXKVO4ee?9;$u(uV94RkP83b|}s1cA7PTpGk>pawz zxaR{9ApUU=+rZZEqoVPWrcd4ZS=zTkV{fgMVwIS(u%v#{u`lTY_BO>0ey2zZi6hB@ znS#{OQ&rvC+(2rABxh&j`|mNCF&$GOmG10L(c~9!)?+maUq$3>5ys>*_Pp{Bi4lu~ z&A~4#C2zGX^c6w5W*??ava%rjy5To=o@LC}N}>)+yy8M6Ng9s|bi98&?jCf8jWd99 zzkgWk$nR}?{fyif5nS+kqw-DL+hkq;vuM*B=@@-{B`R1GJCq+`Dv`yh7=?mUX9+HS z{bSw-?<;Mdbz>e@7z6ATpr)0}i`WOGeW}kF9VX58(??gwE04chCat1$R@Gz^dQbYi zBSqQz2%j?#K{&apEt>p{v|=}H|9+QaP}zB2!{4z?(IceonBzKW64V)1YC-eE=bz2@ zqu~5k&ODPb~{YL;=yLCy-Wx-3< z0lYzsQzwD0iXbq>a32kzgv7u+c}<^?TY~um>M0w~?B85vH`wx#Dt96EJTPDW6@l6R z-81|C4zS@}@B4>T334x9w73UU=4zA1j*@Ac3)+oN3ibTCp~zAydbu?iCzqzurpNjO zAj5dVX~!nyUD#3r_c%jxf-W_SY$zouOVJU+M}?Fzt^F?f?6BcvA%$0SrK@A>?gc8n zWR|q!lF6!9%)e8&hqMAAY79FZT6j`)1mO&^@>hS9=`>Q@je<`iqPbm#7NiHnxy1bt z*uNT8x$en6QbdHmY87fF!V(Yf{QKEV)%YZ05IW{skSTUAZ*a7aNa`JL1KQ@{4`=4l zaA89VcVS_$N_H|FKM$c!B7Ws_m-W2n)l-%MQtz|(0->Vu@|6OOsNb%p8TNmvHuRou z6K)C^8`FgzuV3LG3Mss~p^ICSW=(p?AzUtjEoYvi(fgyTR>Fk6ZsNDpQtTvtBC#kr zJ5T2~BxF%spzxDc=QxwCe-K+XSuoxbT%%rY1l55qc@*C7xU+rbHxt2Y=OM@mC_Dgr zp9T3L5|)G3^g2_0;fAm~zE&48;hsw%WKVVEd@+LaG#`?^W~guNukr*6DWAFH41UlS zX*FTlM2i}5^rE^zhkhd4BSh?&+kRl2-5xbE&&Uk3!i%B6BwP{V-JTrTg)Qs{C96ikYehjVqST1;)#=2Ua#uN- zzD_#%gLu9SPRtkg%mR14RrB-WokJd~NWUA0plb~aN>$2~(BEB&slvV@RD8t!xY2 zpQBRhILlUX7S<_fEM*AQwg;u-c`ZT|gZ`UoBITv6VzWvu?pm;9Fi`bM_ z%eyD#CiIHw^NKOtp?eur_Je~7bm^QeKMhPHdr76Li{9wVqk*6bN%i&hcD{QQ1-p{% z_9QIF1|{GF94~KOCyqBtNMJMxO_s^)O21r2DDVN{!nmUnwLU}-ds5S=Q|wU*5JNnA zc*PG52xNfj)dEox-sNrTs|c87A-k*yRB;PmY#yoKss7q?Zw(+az6?J3|7vf5Ei9UY z)VfJ6C7>beYEc3|oP`Gg78sjxx1E?Jv)3am9`R-YI5y;lEHF~0=&^*Gxky?dHewB* z#Rk+E*Jb11Pxr^cxRtt2;nHCEbBk(0l_4&(TMO38f^lvbT6OMI!H7f;)LMnFMGcO>e>aPL4^1hY zG@tI^cO4Wp+2h?DhZmMd3$BHB1`bexR#w>aF7lbIQ8MSg8Q<@*9u5<%m-E`D)N_BF zYFm98{m_cMm}#MMn7$R(4|o>8rx3<4_nqQIEYL_T^kiEJOILIT@&+gn(HJFn(<`I` zw$F;0-heT?CSQeyrQQ%>t19q|tp!yHly$W{P>(6})U9FKOwBur2)zH^wb*iUI>W?r ziPiZzSpz%vuH&VRKKs4A8#0sC6d8@YKKkMG>DeS`)A`qocDL=*`$S_>Pbdx8_XFOJ zGCvVFVm6tdxW2-?^$wgl9yGx&C)tz_0#8NdR;vb^qy|BTH`O||`~>9YrVWYphr94~ zq3UxhT@JcX@{sjagQ$fl+?>p_{7$Vs1!mQ6fODkn4E{V9PyW(;yZx!apMpGwtN^l3 zORJ5(0=!XuksxAI=j?mA}mK?r@%5_n~SJOEDe+B&_XWgr7juqGpgX3KHpt zzS@Lqx76ky`J2=*PR|c62U1t#d zM&~U7u82+F zHg8$G`n}fY?7yhWr==m(K-19H!`z03u}A726?e`*CQ#h5UG~N`&MYIg-vFG3rH(rU z^v(BZ$c3Zd6%rusT5j_Gmv$+^r#OnZ)O*4Vw$z>qQ3&+fW=(xi3a3a^n}3&hw^DfH zahv7>eZX*tB$7^f>Ky5_4zp8ANXc~=z@Zah|FOpku=%juSNX33luJ=me^Dd2 zKHK#+MA-*$oP`cX;?zwm*tS?^34a4UdIV6iA9sQudQq_>KvbN z(pz7jC1kQHGxtKuB;%T=h&T?J)GS=>Mw>#7D5Sg2dwOhu3%lBXz@6EDiFB_+bMW*` z8(J?$`mUpetm6k;c$xBAe}CrrCVEV@ax>WT$~vD`bZ1@|e>L7aAem;Ot^*5e(ED$N z%X%uAgwf>ZPJHC*di#CV)c1uf|J~hC8E!Yg?sk&}!WzKog&MQ&z{rc(QIZ&lZw0bH zRx(xP96Dbqp2BJ04p>badrz{QRR$rLiq7thtL(3eG&V)TV2wWI*t3`g;G3eh(fIFN zEL;V{n9?I{z3{h7D*>NO6gkfB7 zFrtclJ>nXQxrTlPpuT>`MNgm|Hk<@RClr+8E)b3J0QCV1LT@A*t^qwXWw#^qt6>_T zushb+n+!T0s+PAIOd2^8tq?UodZKpIUlZJJboDKJ1Jb6k4@I;}d zpWFuzjY%f;SaN}BgLvfIHpi#>Js7x`qr|lvdbF6pfp+WopHITS+95iivakPfsB+=O zJOG&i4%N{iLa-(EhT+pJl9!Fo&Gm=dwI5&_CV7KIKi?|%Y8m%q`}I25B<7Q$-OZ0e zQk9HnWn4JZbl`O~RE*mJ3PYXYMBxg$&O) zgtBr{K$grxC}n@5{50|^wW>ghZZ|U76z_}fEdKbLpri<>6+3Gq!vw3?$d-bo8hqe! zqE^<=%uRWr27vZZdMk$pWjwMSJ8EQ*RCKFTmC^j$@jsm^-Y4e9ZBi>F+iO2@6MOb# zZ91WcdvXPJS;`z;8ytmQIa2mVWeko7xbiF`h;4~}eghE+uGIUgiziue8*tTJyov>K zwHI!&PJ!}45l?lx9s_#U;PpZti$rF4Nr@F4V z;YN}7k3LL~DnpZxu6qK(oFQo{al~g(9=mH(a$23nH6bR~WH0u{&5GQy?R9I(T{EVQ71X||Es56!;|(nxhr?G^^Td}y?$iS>5a@2@^xZ5YnlYPA8f`e9xLwsQ_GmF)Izw59?~IwTM3G%<39h;{%-vQGDQG{ijleO*IY^Ml(V6>0lmqUwyU~Zmt)V5qMudDDa5@ z{cw#+d+>-|6ntDPA$U3X_dRc~L`T!5iFmG>%l|59K@rT@Cj?8?8eDN+;on65B+H^_ z+}3wg_w$92>bdb8=f0JMk18dpc)?4eI^uPN@=0wj8m{^~-wL_k zeGZ!3EcM+_o9?Rg(ejfRh)s0VJ=XjyC2!29K9CtGj5auYRwCYeR-ORX;81u*;KvWs9|E>d)PR0UrREb*-?Pt z8Vmj|d0E_jTe#6TWS!1{z^9&%vxr0UfBQ_b!9V*<`PYLF`P`9C%SO1dT3?GVpVN`n z2TtOUM>HjT`^dfz(ro_Q*COV0uagXb z>;Q{r|B1oE|GwuuEKs@~P4`jasMZWoRFZo(`9+rG$P%yJ)i-J1g@x6If9$?}7%jt} zN|!0HLV+;;Vie z`@i8v>QK-XN!wL#QW!2*bWLz;_TvGkB?-J_Z3X&j=-^e<9rf(l8LKCKjEZ zT__AoN|+!wt;6SzRmZnQyMq9&hbon9#H-IKGh&%lw6@G>Bv2&fQGUGG;h*Mkz1S2z z!m*u073(<%PQZ16i^)vkwfYfQOQqfGKEt0MBeMaMHicE(fAqfiuLPs%n~1w?{ajvB zPzjz#XakFljYr9URK)&?&Y~$w5BkW)u232x;9Cz~q-o?nn-Yc9iAZ49Bij0CY30v`L0R<#ZVPV3 zJu!qA_*TdFgIO!`9PO@xYl8d_1bRO7V=7% z6%i*7EEDni6aO(B&xAPxo~?Wa`)StPlL$YNU6-bx25SHe=FFw$_iyIB-|ArJ^Ov?N zogj+!OiOy|Fh`MFRIIq(`ZZ)MM=1C=DHwg^0Sr{Mb-UaeM_drTYA63Eb^gC+m5*Qaoyv2oH6FB?+4)Tdswhf) z0Co1rjywq$2zjxYqdA=lONNp2JpA1cbsm>xd*A;6P||PWyPjNojD5`An5;I>Aac@w z9^MKlRngZ^=e|CF_|sW7(AD;sH|R^K=*Wu3MT*>Z0cLT~U183uF=0=z>zff9$1Zj!EFH&O=jcijm2v1V`Et<^;VfN9o;AUM2-M(nJNe=ey$1-CPG1 zCuYWYie2bEWFf=Z|6uE|OIUHkTykF?)HM*8s`$8;QOon#|81$v_ZfSsGe-Zortrbn zuJ0dWWSZ=!-SIJuM&}bJRNr;3voSZDQd#c(9e$q`Lf8n`UTXa6I^Xv&o3lrpa1FLw z34hncEMMGn0DtuW;Dn1m9D_F!M1*G#7362pG3-g7r~&;aXAYhsi^g{Gt>wAidgaeQBVNYE z3|9`Y_gWW#P*ode7%=-+DCp3;`194jLB9Vz(_~>v5v>A3^y4Y_JxRWSw6mBsBnLY= zOXst-K4yA@RU)}OrcpoaoLWA!9y$aK2AS}wCom_Iu*QElnUjB<=wgNx*;!rkhNx!jEO&X=LYCOmed9QM5M@_tpz!ImO?MX z)W_KGgbFnsV*=UAV-jrYiNi}g(=%+ZSq&tvjrO?C zgc_7`c=h9QDy3U=k=h`YOt(?J(NNzwe+1ONGGrDu9V?TD zHr>@dhE^7$F6d$c_lqgG_^nbO3!tSKb~~^AFpBYpA+e0Va~?(TIz6N*(pfJ)$cW^G z7jswI1lZB9BV|7Av`@CU&Wyu;#-dKu0P?BuGHHLHi)?ZhyGbU?i*3|I>Xb_TW4liX ze2{R2i!>mflSlqH=J|oE9Y$~c=`pnJbY;3;zB<$W!fy1&GSNAmYGli;na{NN96yWS($fG0T9Ftvf0pOjH zFCQs!YKd7m>FCq_?Sk0E5Mt6TtQki;hTJ9rmIC zr0jor)PE#aK*y&t7K40Iqjk_!UX|Be^KQz5Z|cGs4Ep?Qa8BKPc`^SHcuXG&# z1{nkl2M8Zi%&VZl%*i%r*-(tK;|IvFb#Sed5rzC{EE~oR3>x7h$JU7ZF z-0Zzv64CH0Ld-oIHZ*-OHW0A5Qq%y9M(}6;u)!Fo$LXK;31R8d!1BW;Qp?%+@UbS>o97};XdGa z`6^8|+G50tx%rF3y83wSvLmy&f;t6o@#il}ulj`^djAb<1Z$itwk}o zOKJ^I%+TmhZ9o4^#=~ZQU7j@OtM>6qWn|{{KM+G$>mZySFR=Z>efs*k;cQF8>o^U5 z0n+Zj4*!%FGUx!rEHpPb?!VGSB5%reu38evxy`h0X!zXIAT6*H;2H%~j{B@j9pgD; z7v5Z0)pK8rszc72iqI9~MXz1O!F6Da0AN0ZIJLgg4U{pO%ya+JaoN-W%m9HumuR`< z5&0uvRH~sF+vCd*tySy+Kf;u%tOopivygjnV@eM-z%)5%KDEul7pPsE`-{_1nI(vM zOMoF#EN>$~5SQLS&$wBW4B)q(ml~=f3)+IWLjcnQM+IyHB)Wm*UUkD`Y#;+JtQXGq zhbeHM0st2}tE&OEb3n7f<$i+}{16IQt3uDhZiP5Ex22y4Qa&yf0kPz@IO%u)^*inm z0;cB)Q_R~dAvq!u47Q3Dv@Wq&FC;02`srGe3`_U}1v3zl^hr`T9I%2r`tX7pe3@xu z_`8%GUQd;4MfCN{Qm#vwO6RiP)G2)PI1XPJJG9Sgp~bUK65a=_;Kv(7WXB26KXmU2 zN42Dvh%1Ya=vc4veE5a;wtIb#LBRWc_y;z}ur)t6o_X$5roDnZ%Qc6!@Z|@~+n!FB zy8oKN(V_AHJK~(h65)~&&YP^&8pLvMvblp!A>ltCxExV&HMc-nv}x8xIepjJbyB_j;;p^=RFs=^urk9>WM4oR z%m}PJN&LYWvFR!Mg09%hkd%V@uN}(T%ySC$eE4TjYGCK@eI(zpwLQmO+QRT7f|qM> z!teF-W?qd(6S=-Q-%N-PVR(OLq+}(b$nzjMHbcNtf_{G~vLycu-)#Nv+ zdf$SLAgi%J|K1#QQI7Gg2~k%}=1K}-Q_p=XNU{DRbZNNcS~cdjgkzc=1PrKM1MD0@ zM%J;McQ?0-foz-yApV&b>#c+W9wXXYvB$S6Kw%h22mDA z9@XURfS$0MSfpP@Z@#~#h%_D_UFv`5gO0A~4xN48ENux>c}>oFGIW4WX28~WHV$x9 zSC%uC(lS>7Cjq|wK{@IWBg2+@;)V_7gUbx7qfd-T|D@v=C#HkV9e(5Y(OJzTJ%QTG zIX{l-E4r`c@{@~^b7aj=FDR0Em@J1ZwQoh~&Z3oVtf?$|gkzDVilw$MNi^k6nN~r+Z_0`*r)~Gw?(@Ck8 zc0G~Vdchr#&oE%L*_$c6>uN?=BYQeA`VaNLg7j8qUhZI&n1-`}<-K{(U}{wJ_Wr= zx-|^dzI2f?B`$&)AzKM1mtj-nuq&*0+#|0IR>k(MJ*8ya4;L2ktad9XST!NT^i6dF z>w%%Z+=G&p?oRFIW85YlOwj4+d5#>`48EtV;iIJA(H} zgQb!%1$m^nz+}4Gg_Nm#ROFjHN#>@{RdU&iK;ufq!ci3m1*(4IahRliftr3jI{z#- z3d(EKe$Ii~fP&XpWlBt*eixRWgzpfZPZlbg#KW1>P+v;9qmGh-c_w+UPvo1YnPt6> zf@v#0LHBK$Rm}mcVeaEBMh5$BvPE4R!$Ifg?hxH}0e07ohxu3D?Tj1Xf3IS}a+8@h7ccS(Nrm7LMR| zMbui6@oxISzTzZ!k;&W`vunBJvg(&Ai7Ngr?DdF3%v+5_Qw~@KvnuFN4`ZW{wu@%h z0rxl1Df7|ywUc9pmCXA=j|3H|T2&tG{H~F|j$6hOmZ1K`aq@YyB3%0p>LBXXVgV-*mQspQF`OgAYr!c%2 z9dORBh{K)mVItzMEIqNT8ho9kI)P%oetF5B$J1N9aZHEwz1{5jkh<5Wb%V3hugI~+IOrKed zv-2O+NB!I|bp7Gh&vxz}n8qK#+`K*&&tZxBaXOC)&v%3C+=d!`8=BJIJaZg89Oa`tt78 zv#!m>Eo4{cw#A&gPknO2nPZdI?kTYOt=bG7HmDuG=o^7L{LYyh;pl#Zv=ao7#$#q= z*cKIrwp}qM-JEn_Qlsa|eXcq}h14bz&n_tcp7MCf$# z9AAH)oWzV)5CFuJNzpOSRSH733vUQJUpeI>_m|I?o~z2fR-?WciN9zTu{H|A3#`73?24{@HJCXfiD zwWCvXjY@|8bpeokA?KT=do02dz@Lh1U3Qom&J=nK zh|jKEvi`zw^RHhSaj0Z;5sQ_yc@qm0*XEw!tSh(n2S=-C8ZT98$y&kOE-4n4W*|}@ z?sb@mXQ0AiElo$EZ$>S7&`xp#p@+6Ic_x=a`T-V4*tqF&uiXn&@VmxM9e6fXx9 zb7@pIPP2TicHd8&p(oou7KB_(r1@EgAwP1+qJ{FporA2T{lSU0!IdD1Cw(iiwjb5o zj?6V24wrFZrJ#j^^;K_ae8Df-i7ZJcN@@&88a?$Ckb_u4bZG3JU35oSN9@JRSF^B< zg0D~aHzM#ovDnyo-TJ?i8cN_OAmfTW7V`p0Jwv9XBp<)pd@?3?NZ)jp)v?H?bdzvT zSRlP=6iz_3rYJ@o z4t2pevj;g03G6H;-p>5FVXkd05RCY$NOpjE9oj3uIG!gckU3tHetV5Z)d;K z_I6vsUzVkGq1FQG0uO#^n;vv;eeva!BJcSxX3jKxCbm_2mDZ%sc35&1 zE%i!Ej(bRI@VnSKgEi5^2D0*!+S{}#LWS7t^=dT4E5_>Q({t^-@Y;BRBCEcQhq3sN zTmBCDw0ZGa?8+5|KT4{{^=C#h*~y99H5V8hifjDk%kr-qs#tgy5NktCtT*tyu~Yx? z>Ti!F^P~4qep__3ixbRN^)xiQWYcOHHrJ%J{xM(3x-5CclN=v^{tib(MmB!HP2PS_$GQ z`_@Q5_$8MX012rN9g6`UTx=~P4V1Qzp&wHYg;wADk*zP^jq)Wc%GKy}O4TACfN&%f zZlRUx3%?+0{f6UNi~pDs&L;gxaY$t{DnO2`2~?g^n-qN_@p0v)6(kT@LAoy%a2t1%a_!zEU(yQ zwyve~4j`^8p}1uM@39~s&T|X?&{LOS{Zw@NXWOzu3CM-M^CM*VO~?xDKsdx?>30ZI zfFD^bVERiRkzihe4lV~dM~vYQTZ3O5?5z!``w_8Fp+j%8|NsE2oe_rMq`#NiuKLRJFEckVPKs>U~b+N^&4+T~rJU za5e6d7V6+U0_2_loY|BHnc=;!?>GFUH6HeWfu82R3EeG$fezg1&dh=5;uW z(6N(e?ktOO-Wv6#Og-VIGb@|8Fq_lh5o9spf{^czwVvHh` zO2g)k6=_+aDA9!)E#*+|oj!wwURUt2dy_Y*(AAxnNnPCjknh!9XEd9b5>|7ev%3M& zWfyb-MejfIf520z;^xLd*imw=hZXJZyohlU6ika0*UL$!?P}!*emB^aj{E(aH>APk zU?mnA(Ul>1prTSgAjR)Eak0=3z3bWAPJoboC4`InATxV6)tF_Ij8+Z{@r0v{rD%EO zQB+`o={=$omwW45ffiXqTgs2*K>0l4BW$?TeGMNIE^fLuzu$A_h0mDyJUL;G2>U8H zLf%O>Lx+oa6S2dj3OrsMOwR&<3n}vC_Q|?^xDezeEI?hNs>3G0Ot!X4W1}3l3H&pj z@AYS7b(UX$d+W8@xCNe)_obl8$yd|+#|fY0+vn&F+0f${O%;@wnh9Thf8G;u`SL$k zb?or!`lzzlw z{Kh%hvuXE2u6OuZe|bbJ_G{NQg+?t%e4*Bx89t4j^*~9N*O*cmr1@X8-mD7>gY~_? zb?snGeXn0djblu=zxN3mxfgIF^U04Id#6gP97mqh8?_xhu1mIyZe^q9+LR$(KcYk1 z+aJ0yWsno>De}ov{V6z-#Mt(?!Ish@MW`dbGvaHTfDI@6g2%qFZo;-SB;G^7eVNnv z^aeFfX7l*TQj;&HZSsILZ;BROe|0Ar8ZOzi0msYXq~ekhJipI;F@_a&HK>99jO5i5 zSl7snj?$4|(?@5`ffL-Y5w~BucC&{KwLQ(pH<^q2tK?J4S%g>1=fhe@cVio=WZyq> zH@)|`Jc%`*>hjz5*GX;oU7YsF-ppL*1lXCu&l|KJ?mg0gw!mh`1@7E!_rDlC{jquH zV0CCH5DBFp{UyEfMlf}oIPRfjsCJ_@=0!2sv6ux@T#qH#XT?+H} z^nuQJD^#`^4sRsR*&iYkcjFvR@ICsyg}*oQ5Nu?cl#5Z~ZyWIM&;NA_=mWq%Sc~VD zWBnDE|6g8%G?Aw-SV_OBVEhc_|1WPrB4oP<78nih;s5&Y1!~%&f?23SIp$zPfL#Z0h@a%YLo(zh9q*f}?}neiw{yD4D9YepdG2b*424Y=U}I z$2fVBU+Gke&;^{oY4wdJh-!C+tUnS2<%+kofCv z|Lv>nM^ujI^p`-Rr*XH}L9y~@&J$8%e z;%z^Fl**<12&n3z9GtA>WdY{RJhkg6v;+`9AA=zo@sgr_*IP>_DvceMWc*Iy^t_S^ z$g4n?Loft`ppF@g1Tg*j)<%)zulwMLO3L-nMEZ1{2}rWfrvoMCt_6ufiaCq7Pd+<0 z8~k>Af4_Q0#OnQlKxq~z6qH^AGbBGCnwY@qomNtGGEWZHHsuPY$yaN<4ps}c!EOmi zdBgdrMD4j&FbdCsYR=YZelax@z9u9-P_C312^+>vJcG#Lz(XZO2HI6wCqTd~iSYeS z;~MRFo!vBJlvI)O&wKpq5dP1rCKoD4Hhr9tBAKD}MxKlGCy&XU z12h;!nn1gD*amoVZ*J%8G5_<$0Q*Lw0_jay1ybm>>-u%J*6*#pcawDIdBU*9t4zCM z9A?3>v_;1yHyN3>NHZL~y4<-+O-CV;D`UbR2E`!$@mg!GdaA|}dfKRnI9l*b2C;uH zM(NtT5l{`Sx!YSS2(ANXk2&A)?_=~o58~$^(bV!gF=4MBycQ_U^KX)$ePgDm1rC+A z#&=&F*t)K?$F_mb7TBXHqi?6V2ti(;Z_i&QxBebKz$qr!lUfBX2hH~Sbv5(J5iX^t zxkv0D52UQq^%s1>4MfFba%UNqx%_|}#z6!<2b%xFy>tP--zv<+Tydkfzen@7@gZgy zPruy+VBSE>ZYK^)T-es%?mqC*Z)Vtgp8bP~3q*aICL0FnX5b;96zZD`>j=S^&V?a_ z_j-blV<-d%LAQhL8giv!bKMk}GxBk63Q*j>AjTn1&~+c{82f#;1&7@I3fz4`9YeR2 z44DA`GRM`y3^SiMY0kSe`SjZ;owKsQyrI0=rT-No1Q8+FL_NCBnGFEd z4YiS6sV#SKN(YPLr8Dj1o3ns$DmJ&-3J5ixB@_q(>i=| zzIWL`p5QcLcH-7D=)lS(Y~@crwJyzh9CpfjCo`R0t0bLBU94k!={C*ey`YyU#N8yg z_Thx1CkerxY^*nbU0h=FAYekL68#KnX}#AO4kBdEJGPwvTJ7H+VR0h1C(v^s62%Wp zRuu$L3vFG1uz6{qIY*>it@J`53c~Ua0S7$>1XpDpP%Ec4s>R%m+|w4U!I!5}Y@HzDYF z0+u;$528YQNxD_DiK~j%>Ov2Ipz=_nB5lS#R?s<+$gV!Ko34914e3bZHMZx&I2p_k z90Gs+WR@YlQn#kZ9%z~O)Y{M9BvJo@j<&}qAXx!S$fQuiug8uEe+5Pmfa1Z3Ox}~w zby#I-kyCHOpMsSjHB91S`b(hVMjkoLhwCEkwQpVnItP=LJnjXHA#Z(s`%1UUBnYqF zxZQshXmP3{FYc zkD%}I?x($>EYU2cI5Ebz@kW~Im6ADkAsUL2+aUkTKKYkT_Jxlrt`)*)~ zQr>d;D<%BjaPa4QoDuijv*a3Vc=mOdyv7c=zF*|P(1>b^o32*~Qanu|5_;JR$nLoa~dgs_IpMQto;_cm~0Gl-MTc_fxvf68F1EE?ck~8HUd$5t=^s(3NyWW`<$y5eAX5BVlFDpmTwU`VAY~=f|!cX@kG$BVsi~bN0G(ojJV}3>r`J-4dv{GNy zGKD@U)ciIKoNzWl|35twh5Sxz7-+i^25nfi^+j5x>Z@Ro1CN^xJtNR>AL24zaBKQt!}ku4`t7<#Y~o|G5^(1)uz3b?=oBtIL>)0r^o+`NKDz zCKtel>W?+KZ+$KCzc_V2K2Ylno;UVCdG8CZ&*PQ;loIRllD`s^5h3!;ykO4Y5`)5b&Cs=#sPM7{%3Y5cW0)+;5>66e6Z-=_=l%MA9Nd26QY4? zc8Od-pDR;G!fuWYBiXPQ;6{84O((1vO5uJm5%H}yGGZd13y{xGxjBsThp)(-zzLpV zBjMn|332xUZbL9CNXvs~lvsaSHx99&8@ZmH`Dva%zI`47O$TOtj2dT$TSH*vooi@4xbX*b_1CX30o)=9QC*}4;D^{zVS?E$ zXiLHl{*uB!XGH&s%QcM<={ng-`eZRZEs-|Mkpi?O$?_U&-am%6|2E+C2_PSq%}p@z@N7F-^-#!EDOWU z=$}LEf3M@0+o9h9Z&{<^=l$1*{6Bxt{Qu*B(WJn_r4}3I0vRR39({Uwe*j^dvi(mt z5T`!nx?-`)0WjC*MxKjk2f$xsR<>V$EjMhQI0qr&V_0{T2%RufCSEos#?xxR4>>25hzF3*~XNfQ3|13I2e%7D1g1plgOK zokcY@`ROQ7*?hX6a|s47kheGl;}*)G24ueJ^yrPF0RgLx$|CrEIARn^*^=ZRHZDO1 zndBZsu`(NhOUS?eZ(L&9Mv)F@+Wzy)6hvCnnXO8F1fXt1(1QBaW;jdXVsk_k=L2jn%%cJD3Dmw5T_73{vG1F%a6Hj zPJjf?tEX+`x~lIp;w1?`fEA#tCb;d)%_2e}sCvrw7cd9j3c;+>Zqg86A?6I$sWh6c z1^&Y1&L2EKn*`!pwF3>aq2&+Hw1`1yY+liJ`t4KOTmzVDHgtY+@S|XK3s|cRkl05w zb(w;YWEBLR2#2I{@-txuy63rHN6bTlJy~lxDvhyWDMxdHE8w)hhhFP?oag#cxvZ}Z zeAr_UQ)z6Gb@hOmPJRosY zEzGoNa(VG%6l$Zz0BOiw&+Nrn7offP#Sj}7_mqGA`gXW#Z{M}IHj{I!ecXS@&;)L1 z7NGu&3BmHIa6>A%E9m2Br9dBly!6{{_vt!2l!(S`ahDRr@JH3-&l1Gl!g%&;AUD|a z)wD=Q7=r|^AaGA8;J6W{>w9we;>=Sx$xc?MvvOct&cP(c9^09QFrKL?bgW zsT`q&-5hX|phH-+5RNVct`lUAMf{XLZf*cfhs@AzaxI$zM8i8^G~y7@=CgDM((EyW zX-I4rKoKn3PFAUEdTD*qfnxu7k7Z@+;ZvHl=O2mAf~_U*K{QYz{~4yy z>_O#-0ip0P0I_V=HhX+y(?^=iQTKoj^~B+2(C$`Da063^n=WLu5Y;C#4b92urwatf zVJ`T%$!&9Rv_NhMJa=R!8S_5K0T?_aKFYnG?|)>@7->ek560(fGbk9=Ir1uC=^;qO3z>6Q55 z7qcyQ-Shmhg?B+Ha%fg$;1=FY2lH9S5b^c4=DJ?H4-6Xy;>$PlwqPjkJ*$RchHrkU z@$iPt)oKuC)`){aMfaeNeQ;1-_#0&KS6DCGc%97~dJdS?f~C3MFJCX%jTMG%QM7^U zk!6eObY=L?F(-n?Jv|4f#eTNQf343C8z1CK)5s5%D!@Uhpu3!Wp>P96XxnBk8 zyZ}P|BWj?qSGXiEh`}C_4wdP>eS#%(NprCs#Tgk-Co^Xf1U$wN*rYDH^4W-WyjQw4 zC5D@MzQu~hOj&kt|K0?+35LyhN$dsf5Gz-%+&_m)3DiM_q}>Q=ueSU*(CuW$Ct6yg zhUNrMy$KK>+xMHl@gBU}c6RGhZa|a-0dW7!+ZhN@YuTVsNrFHMX2fY`mc7I~482@y_ zU^bI*jY&uFC$FZ0$KU8h|2KsC6-fPj?a!7S!-gS(4H^k|AplGXz0g!}pvJA=-~tBz zsj>ELQJaauoJ_s;({HcP5Bwg9-F*mn8-wtT@h!9a=(XE>ARd@9!MD31-5j{|w0}4tTln_Z&5Gt>@An?K3KLk>VCcb6&p^~?P^EbD z$S=XzLk--#o(mwWFATELdOYM#$XxCekZqb#(bBA%wX@&cG(Q#Vg|+_p;UI?+4_eC)!52XIfIF}C-qyNAZTXgzc85Ls&Slv2Nn{xA zWA~-1AgAc!cqv{KOkvEK&p7*oi?L7xc+Q@N^htMiz~u=kNw|2Pq*pa!M7m18stQCg z->}*J4qnhyrE&Yc)*uywFVh9|w70{0_vL@u!UOq?MFjXDYmdsuGC*OOok;102-8YH z$nKsFcRg^k^jQH|`Rrh}xZu(_|KKT}=nTXw*Z&9<53bWI{AdIt%H+Dx$>5s3UmZ@= z;;;0aj`%&q6u7*>%*id$G6@GT5`Gnw*j)cuG)g8ypd6*@IZpt0-XhV|svjY}Mcj5Y zA282l+%`kon~)9C^V(Sjc~?y|o3d-4g1`{C0sNFWxy#1>lzPG};%?Q21@&C4pXV*t zRL~P~-ujZRl^Ax2qT#mYGvsfBagw^>q&u}>w00H(IPu<|X{>1kuH7uB0UW@R*sP!a zi3vF!=Nz1#w_QC&rEUqazW~FgP%Y_kE!ZvH?FG=mSH=hTRg8D1{6`0sAbUax485e5 z?-YCjl-Ya+li9Vt7pqI3m`51^$2l5fOksgYyHwelPHbe4c zhRG)D9ncMhP{a+qI6ERZOn-m(V*7(OWHN2K!KvtEvi;J+$aha(&}O1MSqs!P?%@&6 zcKDX`8ZxDU4D{6y0uK-Qf~e*of>TvT$)EA`-`{$ABxHGZM1R8&LZaf;vKiYC5r7-J z+Jn**!jXR$m-0CjGHh~H_K`;0tBqV|0832#YG zAm;q%V&%YGqsN{nRU_^^E&d2ez{T-D)V>_t?4=gQk~n(VW<0OxG# zWYm!ScXZ|S=M#hS6Blz-d4j(O4r~T!GQHvUp@HNJako}q!(DVl0*Pd96pV8BFJwF~uJN^m>w3a|r0Mk7!A-0)kcr`igF6GXkaa~Lz$Kou5*mY%ys!f9Wb{p0baVI{fm^OMw47i?=jD zdix3$2#OII3<6r`_Qr-;UmueTM#Sit&!9hJ^jys32>Q6^>jhs4WX>I3fR1dq|A6mq z2Sy!P^X7fpFc=`n@^4MoYj}A9Oim4ie_CfyDiDn%O##z*XCRe3BpYv)sCRUGnD3Sb z$P;HP4A(fNSa_1U@WH|t_Ws#x_n`!-a7PkQ2y`Dx29L&K&jNG!#YhQETx>l-SXWTD zQlXE}44{@uhf5|x#>se%vTwEn>r!TC>k9nrcaT1@#G!397~O*&SfQV+z3E4ASyozh z)P#Y3ak`EW@frlVm^XW91V25e!YLkU!vTP&q8ZksM2<1na{+KlG& zK5MLWXj~zkeh8WD@CrB`&nsVu^&?+ZM!4bn?Y^Cbju5;#U68!ixY#Y7l>n6K@%yJF zt6TN+B4Bv6?@NzkfXLg1U?)G2P&s7SaEBAKwX!W0A!0f z<%BC2eE97%=O<2Y{S!2}<_L_>8*b&YoT#Ya^~S#9UP`d1o_5Mt6tq1Rzq1Tra)KBc zMnQ1<>4hKw=VCwe@svFWb0mFMd#D_Qz%^B-GG`4I>xP3UEj(Pp=kPmW>sStbE)OAa z{sLeMqKL4~1TH+Y5{_!b)fJMiF)REOkv!QsW|%_Y>VF7O=!399(DR#7U3d!(4myks zv8ir%gPgUPgIm=r0fqcyO~BP90*AqMR;Quje-zrGS>VKNKf;F%bBcOk9{^CdqYKM# z0CmI83(QqPd*k;z=js=NQHj`A;q7-)?m{tTwi}kd2b;DpeMQs`X?=I0D2ZROI<^gB zazh+*T0uOp3N~Jd99wE|^wl|Uz)3W)rGA|)UzSc(G?wMf#11znM_NE8Jh27>6Z@*s zzc)y~!jO2`Fp_RT=+gpGe(f6*h@yFp26dMQpfR-HX0c~AWnD=N_Poc;=`IFVe|TZ> z4Sd+sXYYX1egptGK?GAm&|$7cn{o8ZHb8;Zx6*#}q;l)q#@pjQi`${aJXlXelsL7D zRZ;|^@GH&`)CmMWgP#a;iRS5o@#_(45#+p~a4Rdw`47zNTk z2O1{8_LYD#!|JTZJhvM^eAwat0?7a{vR5QAfj#m@@S9Ey0RMH)KVnS)84e~ENDOJ} zZX5y#()tkSw@<4!fGg|HoXMz$UzE*&gbAbbKQ7P(X#EfdAYcfAK(tzFQ4sg(+#iTA z&Iq<2hNp!S2ijhBzQOqU*PmX2AaZ*KfcdIWU6c=6ouhnUl)^Akdc%_Aw@L z5A}aMks`2LOdY`D{&y8ALDmaE{6@KOFFQguTW~UQ&Mx`f|NR}nYBfhuIg02nYi1Hl z>!yd#SvO0nsZXiute7?Tu(*Gb#n&*!x3QdOTlWK$je<~}8F%T#&(L^BXt}1(EKdTgOG5XevyBx~i_F5IPy>@O z@Xe4x1(u-uo)`v@2D(#YJn^Bblo_IPyD@nD_ z$tnK&;z3VU^98VBBdYIlIV??DiyxK95B6v552H~rBM-ECo-N(G^KrB)+-om)!jlF$Fr>=jcWVgE$(feH1)~H;-~?`?uoIlH3lb`vdn+HT5AX? zPt^FU%C5PNx}CW5LVm9P6Zpp44-~E&aZWZu=Q^q;_J<~3E44}4g_@oF-tZq?AfCte z>D@J6H+m{8bsXnWS7ZBq-Q7HPN5r>XeEPFpX!%}>=d)$qmsTjHa^W8kWS}-SUCF?O1w0nwfOk?hdL$U2s zB{elz&`uyH*WDvS$C;SRUkIR)ynVaeLRmdWNqDR1xBZay$MmJ&d41OEF<%|MWii^M>)PhG6TG7*CyyQH6P7sNd6@B+V9Xy#eX5_9Pinu?U)ft@ z-jUi^ky#EGJKC_@lj)FHqsH32O=2`d{Z?HPe;?+SkR9L_!^alcTdW$uta*Z|tpq&> z>;_Tbztv}l)N^iTfR_22Z!1MBTJ}{011^05SI-BG)I^j=SY|+$W+`a>k@;ZxnFct@ z6UmO_5*T#8RU6}_@h4#OD+x+xOF(XLcg*Vx0F@B9=@6)I(vTm4=a2zVR*a@Fn&&@R zHor|Yedaq5Et*_j9<}Rh0Lvx{cvaqTELU!MQ0@&#!;Tk!S@=A8EfA&a`A3_)z@;#6 zB^?E$8zcf#_*Xi#8)w=)-lZ?sKRWfvLjrDXpUB+WmH=F{M$h`O(3u}<(a&_wgO5$T zhBsd=%W*}}Jxr#jtyi<=9AON_id?GQXV~RsM@jWc>q#gfDTpvWNm#zGoPUma&X(qm zm&dogK)0e>V#jjr&F*6_4?h;0m?zE=Et7nw%DP`Co!@M>?ubP$-er25Y|)a`@PHq? z@9qXq5BwNy4`=zrp|n5Ha#`xC_H-_uDROfSy=6Of?eP(tBZK|vl}?jF1|~ojFqLRQ zt%Hw59dfl^6h8>kCT-Znsusi;xHNGf;HPT9`vileg8bvnU-Uk)^9wN4VHFH6;lDcW zm0@J^1@H(Jms4!8r@=kA;_ncP1NydOwswtWQ8BtF zr@W=#h7pz~eL7jWsf#@RJn8&?WnoKtNs>}3vK&(oj5Sa^;7mueLwHi6$R~pC#?HHg z@fHl1R--Q`OU2oKy_`0j_jvan5hrwQUyma*^WJBO3_(*64$Q}s(9g|!R_*EjpubVB zrJ7xx*9jX&DjI+=t(e*X50`Qnt0C>mw~6MAEFwFRJ_|k4u%51ay+>gA8qEoF7Qy^D znceZX9PP3KM7~upGKLTE1l8nAAH3Fk49fYB!8n*ZG|^u{kyyU;c!sY(aF}4yz$I3E z7f(^gfXihM;t9A9WMM1Y|Eg1oPVTVgqo-c+kO#J1m56-vIl(hIuZWsqQ z*lWf#c1H{x)cBERkj8rIc&^Rzn3@nr^A-Jd@i>y{E8Z)>cROYVs~Uojfh{$q6tPXe zTk-CEZhbG>#w2%_-sd-KPD>rwUxA-AADJfr*(T0`xkvyi>EQm#fL(X9>&87s<8xLz zU#nz(hdIg3x!+uyhf&~~;}A*xW!l)m7OFCQIF?NZzT;h(B+H2%yg|;#Oy!Reo2b?d>jK~9$4n|@yLxLORhv+~qbPbtA0b>02$^9q8 zpv?HQ_EEALGFVDa`%Y+AbF#v4C>RZ=TtA*xO0C|07Wv|Y;2t1Ku+Lo}rpY4^ZDke{ z0MR@K1RIqt1Q%%)z{$cOOjV=t*(gp^i>2JK>;!!fw|ek?1_MEi^t%YobY6f$p4^D4dje)C%hZ5z z?dZ7(igr3(KsRobK3*^wQ=4Pyktt;T2$AcoCF?Pj8@jVgsnT~sLqr}XNW?iLs&G6f z3qSJD_6)*kc-MBmuNuN01kvy%qPH8$Ea2S{K~eR<<9mnP)rdpJBa~i^W{@D=>peZy z=&+&+!O%UrANq~R1HrWOp-i){6GG4)wGpKbshEoAkM%ljerk=uu09%DV+(Y{c_Kmk^}6y@<>%f-Db&_&pO8r zbr#R12@0+%pD$ju_>A6xLA0l0&tDCQC-3oyp3Fi@=CcEaMs{wb`H@L?IwFtrR<|0E zN=B1wKrFUstJN(%<;qi6sKg0YFv{byqkUo9ty1e}&^c!du5*UG#hi%h(l@qD@eJQb zEKY94O&-QMTqGrhTu)V{ptx?^qrP%N+f7E1OOZa{;>ojz3zHUx`RArwqT?$%wndxv6iXghrtvs1?A`!#{6fkoZ!8*DRGW~UcX=b^4#iJME(LTNV5KD#*{)Z51u zao;+kow>fNew}sLBOFL#)7m``V8Lk{OAOe%V`%tsRCB_q&CEraVE^Vm2JWQu2v-|a zCgnJ=)Th4JG~_G{y(Mp;F_LT>t)DeLu2hDr;YUIb>2OlI+)P;5`BPt<=;?-!IhzwU z<|whxO#AfLS!f?agT*d+mjd3@Y_XJAUF`y&0rCbCkkVi89;Hz*1A18$AR2le zOxQgZO}!TkVDpX{*YP`VoQcr(9;QF-Bnp@9rQWXsb>Ncj(G4+o(8`bn$as$gEkNIb zx-eXc2KNhaOV`38eq~J9se%4C5C9K4(;47p@O}2wR6GaLy&|9*(kg9U&u=&MyELiN zxcDxCL2fYb>U`~<{qB6T$IiXpBK&OM{SSwF{xY6<&Ed8?EeCP)Q`=@Qvwt%Cm|_t_ zR`O+NcroFK>cl)cC_K5cUm@bRjz~FsjyzD)>qjWcPtdhR>A!tqfgsdRltbTkh=e5g z0}GY~vKo7d^mh;1P@S}^e;jg1X%_foX?y42axUT0&my;tmgJE4iInI@ZpTaEOZCCH z;_%nB7P%V-RhoEk-+lNQHWRK4g?VMaTPf%je7xOP>`V*0Oe71(Q@U6<-CFs&;ayi) z&jVYu49wT-J4x#&R4fm=0)<65u>v(r&u>pmtgw^AUhM9rG*NHFa&95xxWip9xw9W5 zcwg^|Ni%M^BIg~RNlZ1~`?!oMxR!c5SAJWLAbo=&hX1{+r7nHuZC%0*=yBwTaOcE| zsHB`#cj9nrWW;snT)}0eWi(625IXWzrrwriX!sb$C<-;{gdDYf&HIrn&r8RV9o#+_ zvU?G#c=@D|0Nu7o<%m6M zK&I98tTmf{FVJeKa`*6Tpf2Xq+DRAgv|{EaTW{9=)3HdTSc*%p6M~8D->yxD^{Qe6B;hfh-{LUaL& z!I z60guHvu@k@d^Dk<@u=W%r>++#O)T|xM(`C%4f9-6`43|%YlW_m7ar<78y#==T2bVd zK0dCFA)33q;_$SD6N^}7lRV~pzt|S&vS;V|Iy>564u0AKT8^3|b^UJ0(>rhlm1r;X3Z%ub^omJmvUIv?v`ID*sU=}%IxJZZQ_($s=_K8WC16PL_5L~abr|pZjD@pfx(*ic@^&1QImm?A{DrxK#nkk5Tt`}t z#mZ-Vhh6HFoH)=K;m1luDdjm=43fD@U8q4t)gt9@P-fn;1)>wI7lc%G;dT{I?2DhG zO{yJmp$_jk-w}QOocH(>4~KAN;-;dooid|T13kwBLx&E&0*cG?2NS^!q!^I2{C>E> z4nZy%<`+}sbTh}mWxB{_DC~I!pJEuFw_})YvMjFCF;djP)2e5!OR?s$EriUWjaoI_ zOh3GM%3W;+cZ~GCKDP37c^^vbK)9;j(Gzi`^E93B3NeK^nFwD)l~aeyDw3 zepu!snL>iqstm6c9iyL*@x$FTZ3+t4A+v&&OS>cX7XAmCxsV z4Hy-nRL^EoeaJ+SU6fa>)~>Z{2w_=n6k~V|`FK8$ermXQUZNj?1yfE=-2SQu>5U|^ zN+xFx@4DKqp5eA0NLyr|WTak|=~)-d&>OAE*>YUV8+h+<)W&&mkrU=xSXxcg{U$Fe zmc&Q`H9LPk!hbE_qhWqTKs*6l2)=W?@$<<}>3#Bjz4VnNTJFfDlTOJ!)2sWtTm(3# zr-|7f^<1W_ya(ra0{iTdXI*iGHC?dyCGXq$FVM-H(0n?)yyZAXw5*`ui_yQOdkg3S zPt~0o4FOA_%xepf(XD-=n9#^q;h>6K?-Fem8X`C>)};n&b*$Tif+IqrGmdg!Ljj{F zI+FIc7mN(NRPSmY!I~yB@+_dir;a5Ayl|WYP*a{>9C}M%v39PI#E0vNXz58eDPl>z-X$tQb{wMa z_$2I{qK^jVqI)58_|TH~oDFgYw^ktDodu=n9M?qqg0b(xVX;h+MT|IdJ%xbhVQe+Db zN|W=$7K*_f3?wW+%C;mIe%ljgu}J8{c3qBvLXL$+f|SWgACi|t=FNH8&xYHG31rwb zcKY1LB*@U6`sUdRo>I?`G_hVSRrV>iy=&*eEh0!nVJzDoqP-vWy35%Mk6&7?6PZfe zKV%YF*O7M|hzoEpNk-?sSWnr;y@g#t;6&SH^l0w34itOrZ9JE0>TPd`2&IYIE-Z8n zMQRE5MPLtJl~%uSh5bQa57X~q=k2zLf+KS80E`S$pF;0Qn}UJ@RAQlGXoW?82%$0j z)GfT=c2<8d$b^?%Q=KK`;_?U+SOdbu`x#>t0!M1u7P z2nWM9Z9|`nzR;s&A?oM2VN{srss)-^Y`7zt9?sBJy=KA*m+tMutAL`;K_SO(-i~oZ z-D3+#QZajR)A|!^ICtlYT3n^>SWF(vBju#+W#{n@_=;mlW#kAa#qv0B2|L@?dbETc zZ*oVA7~(H@@>o2_7tPwbi zl1Wk8$*#;SoGv9)PcOpf%AlbPz6iU@+vr3CSarC*G@ zqHG$QctwbR$=h*AEP5r;d-L}B49i~El?Zv8X`+sRu&<42(BhT$mp(n>Zb25+D`rhE zOyX7m8!(JlE}j3SiKA zR+4B7csm<#b@6zA`NJXP_938m*sNvOb)oKw1wA4k;gsW$JBN{UhR~xYT4(uI|KNBL zBlkIybf&H;x!kIUKe7+f>fuD&B7EB@H00?P{rIg^<9C?*J8@9HCYAeor<{4>P>^ z6N(EY@+XY@4^2pV+z78OEXEFBea}CV;Mg)DdwTXpT1MZn?xIP>j~d#vgbAA-o@+v5 zpd%@)5}Tayez4uH#2c>fP7*-F{F?mbSBG_}?NBVtN(gH(E=m27&xYf+PSm^%>T$1T z0p#qwScS)nbOTz1bK^LNeX)q~9@Rb|tkCv$abzqaOb9-Q^xZdjoYAJ%TVbE#iF_Q{ z)F8&d<}I##XI>0fF==0M4$u^#Zx_dT6dx}BOzJ@&l}9Az0E}pA9N2D_9R=2P+LRSO5VGgTn(5sR zAxG*MaA=y;Pk6C*l(*GJ3dDHvlHsy1=Lg_!5-XY`sK z^f#ftAJMN96pB)ke=n!`RL3K+*Vf}BG3e}tzGtibtSY39#!)I6iLH628ExmJYKQuG z66QcOMaOoz^zfd=^X632ZYSIkDes1&jy#cN7omGN-a0k`jkcQ}ytjK^ctsag6y@2i z@#;gV*EWxoS?7zlzh;!brH^Y_rOeq-aLL4@j1mu$*sd?&2>@1IIhkGQiae^+rqAuQ zq#{PRWN9DDar_%5^{3Vu&wF_zm#EO^1-`u$*j^=U zoO+*pnb>Kgzbi8=>^4RD!%zh(iGSymA*f$D{{@=U;O8$ziUdAu=Lf3ao=%7bi=kS= zzg7UYV$ii#M7zIv)GPI`nc}0<>wu>+!d9B!N!Xg2eJAJUX9VfOUUVx{s(YM~1Dl}z zL&Vcz2`l2{@4OfC#}M-6ih8or_YKV-uaO*AK88TXBkEPTV4A$kxD0wMBuLb6|_FW_1sMoU#{ zVF5Jiqwcy`uyuLJXC@Igd$AJE%&yxnt6XNCwEZ`8#g0^qZIwHREjQj8%YG=?w@%Xj z(nxCqQD#U*�)4WpX5|p~t6PK$a_(LhYyD!#cw6@`Xvi>-4^Rg0?Ie%1>!*{>Z;W z_?hIZ%6MPOPlDu5K?~T6B;j*`Y2n>>BQV;ho@1;HB>~e{(1Fz5TrI>MS>)W%>fs0X zzl|nEc|&sR{m6UH7m7D#oEv5IvV&x?t`9jR#JcjX=HKP44Ropwb$TExcGF=pjgR56 zO$hzw{(-Rb*~O28h>vaN;3)tQomIN9gDm=SvQbZQP$l8^p#>Nw1a36knNZJ=KGgAB!KAP;G2~cglk}sRl#rWrEO!;Y z;+UUkDeXYHBW+AIZs5gI+9$6K>WUPyl!$Mvge^LhFLb(XKF@`cNqMIn0F2KB(%WhiSJ>w8blhXlbrW< z-$1+da?>qmpxF~Y4gs9aWsAME|{4Xq>m;-nw z^a9FYH|j3OMNr(x`SH|)SpgecK+wNC=cOZvFl?IuoiCN&2=2tn44 zFQPoses$JvX95}e!3W={glsXXK_aYN9pPo@LlpSfFRD7M{r6s0YU2xQ5E&)ZR9GDz zb>r;Qx!Q(Mw@kd+4LK8w8kqQ&O+U{PUvTqf^Gz}m?a~jh%5@H}2Op#iO(U?Mha(Ld zye0EayEzVvlqi{e&lPF54ohpn=7%qIjVAfKDAJ?Lx`u>B75gJmNO3bfGJn*#tjler z@WV4opFi)mcfuh>=aziD;f%_bT6*!pD!}kNZ(oZsSTIA5 z<47`$!nI$bP(k??%_urpiG>~b8d^a_q<<;%#u6uEbsbS zY54?s1?2&07vDaL!n?kn)B$DB!?%l6V$Y0vPYo{Y(krc*XMWVu$L(;dtz0|1M=Bb8 zy@cR6+QVS2sH(?U`%0S^MR5X%>GR(UJ{npPchf|{jLoFIEy=5iL9uZGIlNKTu<|u{ zM_!p%*V5raA^mpWZ(RdTTvWJ+9_Z@0Q)$%tNSs*Y*b*3LF8_91#{ef9dgc`NE;ev6lSG)En2_K zPU;36G%iFqMm6S+L2e8JV^02(mWl7(s6^F=iJ^P#-eN9;%~9ticW_`#EYwoe^@pXL zAKeH#i(wo1_enQg3hR!DdnH!9p{chiq8#7yWqnB45F>j;lZ!;|ZBeusFE}LhQZ)S_ zZ$Qt5z=k-a@#EEGH0SDo-7DC)idY5h^{5DT7Wz;{iv6T*rNMtv<;9azOtm40lX2NXLE?^xV#57zr1m!VzDKcvH_7klKdhU_I9v`5sJ-@5 zF;?kVKtzl?a`UVp-mD2n%?D{5PnqA3ApDMoWz+ec8<9-q2K~fjX^s1X4dG_n1VDMx;zSJ*RXvtni7Ec=ZFmxMZP z#OQ50AWLxsU1fueekTG!MNfGqdlws)=er-Z;+@-{rdVijX=ZFE47 z0kUl>gl8)#kPeR7tBH{Ksjf($q(+wJpc51ZO~Qnn23Id)dLz-Rz!aFz2#%UN9BG+g zQ0LqJE%|mDvn!{WdQ%l@ZM{*z5J6d!_H`3$dS%@gV1~3&8LqCC-r%Um67~i-#@rn zFcokUHSx{8jMJ$3j%meHO;hquE(XyP45bmY>SP);A{$M|IAj4K!Ikiu!s)D2GV>B(f*!!zC=1yxOxOJT>4*aGY-1gLslM;x{= zroG#&q=+kMIX(rbfATkgN~Q@2kUXFVLrG)b2{@#qBKTz+dpaQzGQ!ezZ=zX$24T!2==q z4CRx<_ON{b$a!j4>J3fH)beg`8L!atj$BiGh=PNfIN*V;fah3**Bzz)sg_gBSSC6H zsIW|ZD2{Qp9u4*!by+=6dGDQKuuQ4}iRVxqVB|TaJoPJ7d^YNz^mU@M-d?-l0H;J4 z8Y2BAzS>}kKbrDKkN2U!D=ju>z}qXtF~xrrZQ8=16fsqh#2UkTmuXP0Zx0c9?7dJ( z+|E5~=l=ou;V&8hcWr?;ckl4hosnB3G4Z_f#?%sW9{9v}lh`}63vPvW>Bts&7Uc+< zm)~7yQ-M++IL3n(?-Hagi>7|5G`4a;X7*e1wlsU#2U;h;-pq6Ap>UtOy(Kz(Xy`F( z5up+xb7in{>B28`2#{i%)sZ}h9EeP0j_HB^>B!NJ*019908jJas%ii>tsi`hQ10+A zg`x?4P~*m1mA&)7A$G7BWe^PzjCfNh>U-=MVy$ShuIs<|o~-vKfn5Af?Xy?+c)V1= zd3Bn<;$caFLgsY{se~%a%^+_lNQRhhbA4gzcL~j+&HO0y+@af={YKxT9aXg9vuY!@ zP5L*eUBQQm@;U<>DoUu~w1Lo8>4g$Jm`M}#2%P!JUHW)|ue?Zrn=?gPX3;(;@gkL5>>NF7(ot$DkB~gKf=Yh4dqbdArU_YG z<@-r}Rqz5j&J%MON6jLwaA@`LydES#zcY6sjG*HJo1FmmkYq1ZWuIR4Wz3*FM6o3} z+~6=iGEhKr{RB@%N2K@X0WCyzn!%Hbm+Y<~TFE%c;reVb?H5)4Y-?KT&5K0aH95$n z7h9CTy~2zdP-@}Bf*OoW?qS02M9eAt3fJjG85!QMLkX|b~>6N)OB`|%CbgcY0$BUL0wDr9yENw>;B#G_fNrvg+P0hJi~avNdkd&4*RE?=5D*DL zLXh03NJ$DvhYBbm4bq^3lG5EOAZZZNp>zstIusBD1f&H7bR*r;{jJ;Qob#Ud`SkzB z_{SOJjN=jZzT>*qwbop7%}J1<{?wA9>GjRowitc)&kszvMobR%6<1FzaOfN+Yt*D> z9>30b|By-lyEe(gS2s;72`^h2u==|`dsCjT%Pq9I+}7ewk9KrW&?&u5V~lXh0U52!Y*8`uS(HEI2r^QzY}=D%zA z62}$<)^4u#QVzI3*f7P|z0#gdG-p^dYFwNzom7*ZVh@@Z3t_S>d@e&W6mgor=tnRA z7LPO&OgY6$$e*EZvQ@10o$h-W@}cWSm(h8%PD=jE4hO*okOo z=F8m(^tJ2>WBunqNG4$VYa}q(SE>xCA+<}uNmMd{A#P$C&M6CB(k{m(8*%!!g`pCq zjk)wa;+X&&z!$6aDuY6H<*Qx@z6>^_$1B??dSm^jXXnM^$FWAtRzyresnI4gv%U-@ z!|PuYvevEM&^vrN)aqQE)(kcIXuf{EqtBk6&p;cy%ChBYNYa%p{qOx_EuWrHy5xVT z_(|HtOHn-ko=Sj!=iI7GM2z-l+Ru^~$`u}x&DxomGof-^O4pKqRH@*so_M_D!LXIZ zw8%Rya$W!SGv8c~pujNx)M-N*A@>JP^?GEr*ibZsV7cbaFn-*#@{Eyk1#*i#Y!ND} zi|+GLGGig-DPHLiTDN8)*9JSb{_8qiAxVC@aIvI9HwV6JB@EW@iDKG-g}Aavn)%6@{!-0 z_`ob!44QSffDK9a+<;uhcB#LT!+$@{Ewvzz3+>*;nlG`qTv;i zG@192zio`uh>v^!$=AK2waem$ME(`G)D!q*_DDu#ACdEm`3by`iRl+QV`?|XvgCQd zN!QQX<8>{??_3*&wY$c%B3U+$A2^ZLoyC;tqdT#AF~QTKHJ10)%4RI@otrsv5(AP( z0>~J^sh)6+m=20^X6)~$03K3B&QP&aCI;Pc?Q|I6L2`7zWKmRU5$lQ&-+UEDL(qfF zuR{-3@|MPVBt>gd*9hm(%HyFf9@qK&02i6PuUzj@$fx>oew}sDzfyFtJ_EJH(%|)1 zB6krIIgH@pRd=ldeRI@R(QA#xAl_Cnnm6!jsaYVpX+{DDyss|UR=F(OfVZo`JY((P z!ML~N!TL-3*as7`H>#V%FElY=&dB5?UnOta_*^T%j7xg|MX{UOPyo|y6FG(SDI-tH z_^NYd=nAK`%KNk=8j00o(^>l0lr=Oyo874-!01xj4+2m>k4G@`^y%Jn^RJ^DMYpa> zbuxF&ncO>_Tr?*BisOuVpp3w$8|TC~&;7itQ?TVTCcyo&#>MsOPS+Dg^njbBym2T& zV!gV%ZtU`+{l--s#FSEK|Pdg09T+ zmHRuejoOY~*SdZCt}s!Tg$jQlvx^{Y`zcK(#7fXt>M6sw!!bz`u@zr8n1oZ;!F32Iw;JL@ zC$|H|RDXtYtg;HT|M?mT+TqD^QR6^tqWAu)oG2r^Zr*#ovs^Hu^?lT`Ip`N70F{6Q zwyS+>L9pJxZz|^>jeIgVOWg6f;?oAZOUr@fR_&7s67ltCJB^Ho-?qpqeA+q7-^iX2 zfns~n<@ILJ@-za_7cGs8;2TnAqN)FiE@LIKYk0ugy?7`?B-%$mum6#*0x= z?l!7kV~;T5!V)IZYu{%HgtxmJ%kLP`R&>M^p@tbLUi)io`L~;~x*EK9O4VQfLOlrL zYFean+|TuXcnhhXjIuN?N5?4|NoSP37=6-!Bd*lFC;IUP=`)AclA!Zb{vT=saG##} z=uzN8y#ILPn7&82(6ypD4wJ`9J$SrCVP{cs%lQSbuRz4yuwAA8 zNf%ny>bD#GeZ+gUbLUcS0JR-XD690oxJg)2anZ$MW1JHP7gN{Y<6{@JFzpMxU}p4p z?J>Q8iOZ+#L00LF2%okvPJ5z;7alBow5eV!OI~0o`TcC2=8_$8b@`$kN#b(&)HTv0 z#;4O(-1WF872|(kX6VDW{7O<>LZChLDP~dD0-u&_YzN>_z zHIf-LQ(_2(-ck=%$zwuFh4(ZBzs{Ulx($oB@r}ODl)>$Ys_z)G`(b$ZAGqSpvzlLP zZ1@-d7mbntWeb?Sy>vXa+G}q!L;4Y(bKUZC{n3~wC~@L(29~DJchB!Lz)Y#lW!tcM zP&GyS*&IG9@IOnjdVg2mC{f%;Rah|-t0L|Tor)e+oeQUf#e3q-a3{!N_gHBA_zsP+7N_l^o^%@o*mUNWbhwV*&E0aV`kV^VrI*BDb zC^lbDHDlsYaot%?hdYK}=q=@{+}#uS;Ye3q|4UYL?aiM>ubB6V+WYRV z+{m4wyPcS~6}hoRhS$W_WbQ}Bq8R8qHYFXcaW=bMME}ImJ=L=jj#ivlo(}gG=I9`^Di=nq!o^1gRdUi@r`oO!KESP&?f!;i`m@V^EU@^9#HnsUw;cw9 zUGEe)+<#Ey_-di=`G$pX_-U%oBL;eO(sbtsQe5&&Hpv+38l8WhTHxH17SKdEGI0>q z&l~P~MJg38!1my`Z}CxFHmL&}$uB6)&dI}K@FPHQpK@zbA zkWef{91$O5m*+6unE`4|={0v=DX#B!H0hQ;Fqx)`aDc&Op~&ENlE*MxP$$aQ^NO6( z;dL{hNOm{78Gp^WNimVa?26nzB24j-$^@1 zeWe|3Y+B9~1LiZX7!SWS9fzYdT~y9XX3ht$r%h)L#ua`VYFxwB2uiy{5xtl&vw3fM zTIM9716gD7*_-bOFHS_ALEVa}akY@rIeq1`emjN6enj-NWJS~X8A1(vBd+$&kyGhq z07(aMd%tC$R23|E&hxofsLeS+7G7&XO&^puJr!e zh?;PU-26)Q-TK6YK&E_NzLS?2{e|ub>K3Hp@_6uWsB4z-+J}(OLhIY8U3gGohs^BI zaIMpb%=8UmE?~-C7wj9wxgLlG*-MavEJe$+gMtM{_Hk@9-_z^S-Y+Sd(6^IrI`Yf~ z(}pp@N;`>}#bCXs8*h|WmMNRUK&$LC>4aZ;h**O1Su)F5%*(guviS`0on%I9M-f^qn&-z{j zei4<0??pbA`sR5Erk4IyX?}fXmS%M}G{l1Ssp5=2X zF2@_^Xd<=?<%<+6l-D;4_(7QvBJa8Ger?R9R@6>kugCNU-$^>p6*2EZ?h7O33RTbQ zSg$p{&aEkCJWR{L3nE~ly&^7IeTKvFHXsv?j7#lDH-{f3nY^LD<4Ue$%Sr7%yh+a0 zxz6+D?vL&8q(?SZDIfZE>^UzL)dwHVCHd6Kr-k-?H?1=GwT)iKoEtN#y29TRFil=7 zz54a>S)5ijdy<1NU0W_1CTYcb)vu!-k`|GV^pm6`Td8$0$%YJ{SFJCI#>mrX2aVu# ziQ5PVr+)9Qxcl_djYrXHVMp6%!9N>o2%87lv1ndf%KoppX; z64SCW#d-zFmoFVoPi~+u4*~tthV|zooSqhrcE>KeQ2oAk(QuP|(VYDk`M!Bb2aSTC zLb@?3or&l3_J+n&QCYt%G7QVe`ix5`gCD``X1YSx+4i}I_%$c|7qo@9Yu=n3_iGm; zp_axYUigfX-75B$YQQJksqH1xVdDN4$C|q$9{w=7X!&^-;n;HeNpG8Io;ew}Gvz4h z{Wgw5{!i%pJFvWYkGS8O<^iLibk%c71Th= zGzEJgla2AA3ehBW%V!S)@xr>OU@DE9fnqE(F;ex1Lp4hpq;3iyR5@S1>N0D-L z?Q?Ni0nKaWx~|`njDzlcl8##vK9%z+AY~=?@gt8hm4>Gy&tz&ciA+4%+GS6kh#Fxf zA!Q75_+Uob!)ql%4~Ra$uW_tD=1uhn1BbwJUON(@z-Oq{piOdSdXtNwZ<{af!+l(-2cA>a0t%PJvca!yRip?1sPb*9cyN~qTK(S%#ssOP;&E#@Io3xbj z!=7RI z1<4AT6=OzB&ZkBSNjn4cFGIf?5jq|_l=RrbV$pQkwA)uz!C~|Fzwy@iP1bekcR%k8 zei6OHbZ3E+EDU=y>nSsh2XXKhp0{_O@}^~F;h(-EheNAGL8?K@hP`~iC_Gr=a^DR8 zaWQl8nO^g&to2+T6?Iv1=yHfW?F#Zqc9Qh?C>2OigJQPdUPKvUPGnsdjPP}RN{26a z91Dk3>X@Ghs|wX|3_(|DgvIl$44IG_lNV}ZYNT0&*q2`?YU~u2H^xI7<3XiNmbB3|0n8d=9TS zJgY2f<(bBd;s)9+EW&;Hs9CS61jG+tsl&Fje5oj2cLPa-d)DZT-$cBTX>|+ zY4R{RI@OeI??Yj6g7{fdM!tJNv&q~pV{Vx{Q%(Ck5~rn7Z171*xmPC?rD~c;RGwNf zV6Bn~lUm_n#wM=aO8EQ#xvWDQygbTWZzE^r*)xU`?$y6xySFRwVs`}8Y9D z?EhRAK7|5&-P<2J+}QYi{O~*{BVG+pXy%s{S)CRCD9O27E-UoR28RFzA8{<`5;k0v z+Pf1?m#y{J9{ey@tXIChml?v- z(%r?r+Z_5f^;%#RG000g%z^*Qjtv`quB?U-O@z`t_s#{?`tywl29aH`p-$^9{fMFL^`w-d4tQf~0@_ zy+ztPWDXQjIkzr)k2e4rq2+j8Ej>uhf`MUmT!pCB<^O$=|9rE`d0b@Yn$U_m=W*&3 zH^H3n1JKH2U(GjN3ufj41R)+I+w=}V8`uV{ATAAL6dC^7)SB3cjJQ%PUwT3d$QpIJ zxC>L_{q+d``Sico@KsdpdAspW=69eKfd1#U90J` zBhb5TzZNo{HFHob-m&pq>^_mv4z3nh__`_QBqv2G^#m2P9 zaF>IT$3P^W_@yDdCe0Af+KmCi`<%U_)h-V$;frHU=2U4@*+IoL9+5c)iOb2JbZ*e_ z9dnzeuLkWsgEkE%L^@S{xKE?Kd;1;}Dv2UhGU^!Css=mJHCX5J3dW#lni2P%9R&34 zwusWvPppXlv{LtQEHtI`**ZW1$=xLql-n%;&#Ig66hs|@gx{9{TANpEs#@`rmicI{ z;hhZSWSc-b`x|11uyo7loxd2EQF9E-j{7~bZB?qU5k3Ae5ahK+VXgLv z-?BRU`>*fg^3x?JJpv?Z5k#sS9VL;Vq@f8B%nSNV%`CL zF3WTZ()xws_65+Fwqtqb|D7QCzB+vF>n47jCgBsv0oy}`LK*J11abc1Lx)*ZIIw>S z(i(ua)6$H-eJgW8Mn%tyX&O==r~vZ;9xQv%ea>>U3Jp830wt&4J`eKOU&AZ>CxF9Z zq}6^AdUfiF$w9uZiITX-;5%thDIOFCg_?*}&Jb7i0;Xz*x>n9cG;g zXO%OJE6OZEIw3qz6IN5rIi_X>IDV(Gkj1o%?as6WE5MmHCuS)!HUowT((AwfbL#we za8!AOYvCy62|D4|9haf8XsZTJIyArPn^#6<#MP1534Q#l^ZOy9Z%}qhmHi~+o zEjJj*x($<2?L-QjbnY{$T%<{KV*s=6%^MwAxF1VWfISwXHJTXh>pCjFxgZQ_0G%Ho zN+UpHx)06_jw0L(xHhaa3DfuUy0&QovGe;)&VrHDzh-eRqSRKaa< z@G~H`5?28Q`Aq9Xr-7%fCB#7pkwrXc%&MdV;|5Y7Kp(JJR=4)eEwvsQU~v0!da$!1 z`Qpw{y^qfxJRXc&!>VqJ)1X0&`mPf;CKWY03nymgOA{gFA?jii1lL1j4%td^OVSMx zPBXvUWJ#nrl}7u=_4NWt*Fx#_fAq>i?XIN_N~MdPro>^v|zG7NY_mphdI@33X@ zV)EM~lJJs`h;DkP_?CXmMX!AH0Q)HM{q{eG^-C(}k7F7GNy=$$D&D{42y+8O2PN;7OHn%uMi! zudATE;x(xR2juQqy|4tT(>w?$M+p&5+yMM)&$w;b-|5MJUr*M1Yyk;WQtm;NwxKxz z-?Uof&wUWNbu3wcaJLy#zt0>qG+GKRIa_qYekiB}%QlyNJaEKms>Ml;g{5-8$Ak`9 zDm2_L$t<7D;>}nqTo6W7L^+4O>w+p%NjvvigQXe=q7eHpGYrcpzYWI}r!n58Q zFm8&j1%*(XBn00Impt4~m>O&X)lz%&-h)sONGXP(v^!RsjMLQH!*h-lg<>%N{1jOd zS?^$!;UNgpIO@f89o%@jbSD1EAHF`a6j=}V&+BFhHX#F#NQA9v^JFw0hm-};4yc}F zeX@s8Y4xnp{g}y&dC0VH1$d|9_)d$w$#XtMFzpu{HqT7?+4w-<|jh`&w0g*TZJ%zkywKyre(mr z+ylMNMUYG8bl`hq;j<5JphfXERjo>cP~?mNgqROgR|6GxclTg28^rbPmW(P;oGy_0 zAt@r9LeT-I{ooRgJ-UTFkn6ae!qapf8~xg&1FF|*u9J}c>G7kH+>3&=D}xTSfSiGg z5*^P^6cj@nd*>a5qWd7B;1JB4ed08!@?yj1Vx*pP{~UcL2&R zWW5d#z9PRx4Crm>|08pxCGC1*3B#{~cbkcNr$Jc8zykv=9c3U)TIo19#HE0>iX`1N zZrt|R7yi})ShE7nQX66U_XVafVU8O45E&cp>w5N-dk-Wr%Eudxkv9;8-F6Nc=NUnC zcp;+=Ex*n^0#|ftDf2(&|8Ige#2W={8?9FWoicL1<63Letc)q2oGy@*e7)88bn_=Y_J(XTi!~C z;;?L~YJM0vCM$b`EbcGDl?`2V~{?o88t?ni_$Ro5H7B4A}anc75sECmx2C{rLk1u0 ze7^949$) zMIU&0>~RUJP8#1p-@8PCtFmeF0O1Y82C$@$GA@UmMvV=y2pW-m#(kCv)e`8m->W%` z2$>(OM)-v8S<1J-xVimphB#rk*_NaYp#c18?uP zluo=nPw_w!Tt2P9iC{GgV!@_xXIPPTdSWlC2W!%ZO4k8aT0;pZ4dN zP=?`;v2Y>xFg$ks4CFYtl;F@KS0iS6CmUMRUyaB`5BH}fN7R+YCj}GX{^eG{siGVP zpucV)Ng}LqEpigh5hRoSO)x|2r)c3eMfL1MYUC2ANMeTY(FYT)rS_k)Bo%?Meo;@L z=l6yu&X7J;mDQIITjcUtKO-Y85!35wKF2N(%_F347`Nh|JAEAqx4{EkDqe*QA zkVUw?=RqNLN;PQNw<$M~{vm**e8fgyL@{J6E`W0<cYP+^OX&7BG|g3@mjMog=n z5K{!ih_Wd#78ZoG92Ov0RHQFu02GwQk!MCpfT|^+J6(vMDHq|VLhlWZ5#vY1R_K1M zc5_J%TGC|jBS#84nB(KvN|S;C5UWwAK{Oohl^)SnS29%gUM}wPDarlHy8l=7{U<=C zXy8~VN$Jmawt%0YMeaJH$nUXSTh5AQ*DsHVP=8$&KUnY0S5B5F8?mYW&=UWDUurNt z=@Hz}B2qC*&-^%*U29oeQ}*GE-UYez#jYzT36D)H^C&&I%S5z2h0S?GS#+~{ zRL+-VjrmrmFYwIngWEw(d|2dc*3Oy;ar1~R$q7kmm2xHf=K8fWb$DNi=dd-cclD~)j}Ql0ai;o zZl8WDgy>Ow(2r%<+bHxgm^C#k@dY)m(N2;1JXf{;ItlR2`MOnMVfo9X$uff*0e7^< zS9frl8uzeA)e(23jCXJ2oOWQ}7^LWrtbtOWUX`z_=3>P7QJZJm56wqu;+*)Ni>!Hfl2D7Q!&rCD*K0>xP>aqb=v!fRfH_$|Y z0w*tOFWU82Y5g+lg+$wVH1?2i`AQ_V7eJP+{FSsWkXC;I_+zdLs9Da)N42>j#`Lt- zrK**YvznEXY*#J>`XRGZ;|EJFc8gn*``<~BUHPL3=c3FXPPrVp6xkC^h)M%uFZ5E4 zXBR|cBKqx#gIqvbO~hr%3Ls`jHbWKwh25p-qme|~eRJXLDf>}yd2t-!1uyhL$vaK> zmV*U}^U!Px55dwzS{Vc?Iu}4qRQ?-;-cne#J*KwZ{_FJBP;bY_QDj4p)*6mgbM?p5 z)fnW!1H6jwiU){1TF-n=&B)_zO`B3YCG^c#D18ss%lA0No42Sor^!i|N6H`4@pMv< zk_?hNYfm0No^Q?Y06V2kkY)S=9?DAGbTg(W`YW`%dA%SmS}mdnJIz!T;h6aCJJ!gR z3L_4hHz{M_pHHar}Pv$vh! z_jkJ9Za6WJnP4BB2xe`o53n)3xb&K=$gSJy@MGiu;4HHJesvFAHzp5v)@QvZ-oO^&dAOk-8njW$@x<^lTRkieZ3s9Dor6`BnX4 zwZgUowh{-ObulQco%=Plqhi&#PcDJ+LD`_8hvxQG>DaTg(tmoxswvHQO&h2K;6piU zQ0d$H(E~_j`UTFmm{>NME->=50u#nn>U5n^o9ac(A>zl0NOn;1KLnX*%XkgzN4r<0 zzACKfM8V3=Rf{n_?<-Y@&0W7=OnjE_jeavFC-+F{L}i}d_~7nXCpwFM0n&*p6IRHE zq?+1q0PjDK!SHPW?9KJ8-pVxV_QPWJ_9#Bk(3^&5YFgQfmXudoj?ZJef_41&!Tp%u zIl{h=zT3ceBpcjSBN%{XRH$G5<_SU2{C3tsHv-wv=lC5zF$`Yery0vaxT-!T`5d|p z7RKpYun1hjX}U&Sl`9WvwPtIvJ`U+eZDSa3*n|v9BFTWe0925>1lZIxt)FsaE%v&$ zaCD|!dvDY4*r@?nC}M8a7rhIIc$9OuMWenzYyUlkVvWhe3xiSC^}_;3a9SvG;|Fjv zvZ{k2igmF8Q7?k<|8BkYU;H=T!^HLVBO6+Tpu*1|V!(sLK zuXV%@VK6)WdNIOh|E^HB=Hy|dj%t!Ppx5=kj&p})$hs$oskg%fYA6NRh>B zVgzq@b@!j1!D`vS4?iW`K_l@DR4aNHp#qAShAf~!V_D)O1NSAF6IiPhtVHZAu;=Mc z!penI$>QogNRMqe5aBsXz)GSXs%~SCAo;LbDV0UKN!cq6r8hrHk`Ol{bb5hXKVG>Z z9lnC*l5$0oXZ5e)@2OXJzb?Qu*X2bL+<&s0|Gl|c1rXS*3-7Ipbx>~NCke0Jrrb{g zDYs}by!8Jo1~HT3HT5UCf_dhe?k%p%PX-%6qPdd)hh;&f8CS>+(R_$LzPd63m71@s zi%mhgIU_?~qqKJTun5*Sgx2!CzZ2GuTT)_1GE+#4=>LAvemQ5dda>-%Ibc;hT`X?r zik|b^$wwB5F(FU!2o7f}1U5x}{gdrDqMSZVsjdIr9Sl^=5l1`5NeNiXZF#I+4A=mD^V0ry zuj0emkO)~WScPtaY}zaAQH#A|Wkj;Oi$ zcY~Qn30MF%f|sa;q}y;8q<)p5yqE8HI`*=%76`U^v2TN;K@+<6;HqZ{i$#vie79FK zWJP!71rEXGyV8SHauM9iA3&2WXgN$W*TM%wsgZUUl5XcOCV`dAZ{&9jpUPb3`2Fpo zRCwUxRi(t@({#-sqL>N3jE)8D1kk0N8xT1u-xmWH;G@Dfu*NPz2EvkDpiyGy;^Zg> zZ%7BX63q!cNrA<`4wSh|+JYlim-k>4QPr%1Bq-+Wt28;RHNd%<78QeO&U>)4xYq{N_jj!?R1Lrx$U|y1X!6@6&eT3&A<|$yxA3?a_6CN(#(} z?jdGVqDmR3Ap_z|58E*9%Tg6i*WV)PMOrrqbIgb+89(wg6l(#G7yuzJmZE;wzcmB0 zlQ~`?8sz&(poK2j<;kjkGayVZTSIvh1NwDrll<9u>`E0&++$FGt)V{%8066OfH-S% zEx6Ly3~RKjk?ugdv-Hs^k&iS`qguRhy{);ZT;ne$+Msx>YD;a-<&PDoJT_Vol|=Xx zEMu*a?bnsA5L30;q*rcZ4Wq1P&kwekBXu)JKxz~i(G zNipF3v4VlU)eMer9?-UGKIk7!b*|W;KY~(q2o&`m5L|@;m>z-W#ZVz?woheUM3+gk z4fofAtJV-CuFGX6P{VvOr*sQE=eP(w!he4NFhf06 zbMKVQ95K{a!%tF85hBJ$${(Akf5pO+2xhqU{}(faUw+u|4B@4;$MfL)F1r5f{{bH9 z4OZ;`8)e)cD0cfmMt#{Vl$c(mFaHo!P|<*7Q&_6s2F}s%-`Zaf;IBKzrS<>)6Z!XV ztK5L_@TBja&cFZX|11d=GVG)Iv0BtfH|Vi*e6+uf|Ic?z*nCGij7pA;qF=!IAH z&xHMb5q)4UhY^@Dew+Q<@9M+z1DFMw3>z&#^p~MIF+t!m4`qD`G(^8#jJLXj@C=^x z0vqdD(8<5gD?bqcMSwZB20+MYm^WziT!*$Ye2ZfSy%=!haLxr&nT~vjydQ=s z211YvDv~z_!;_48hn!-F{I|iOT|Mj$HT;E&DK-F)iC*AN&lXdNdc1U=L$5S^sO0`g zFeS&=G#UX54VD5IXqpwl^w|5w5`TW=*fnK~t&hV++@`=AHWtx|6@;CfH&6$<{_y~V z#Fs%+BEyFQLhY?@fA{Ah?B4?;CNx+Qn+i<8VP*o*;G6hO;Mlwc-`RT!K<|@fko^Z- zb&^fd!fOK0HLHiU8(N;EfL+FK;<+JB>-(JvuEUD-kYFh6l;touBi+zgv#^#~S%Z<6 z);oYA+=X+A$sy(#eM|s?8I=Lx6dfOc z_3PdCbMU}iRBye;WTg77w=mYk*3TM%q|cfcSAcsk2v*4Jk?n&I6Cq>bn5+oK<3j8m zefI5sv004ICwMm!Unyltay>_^4s> z{pU)r$tdkA^DdG3OM8nCed7B)6(1kNHiOV#g2)1fV*oDbsv`Rc9)#v67+h20AA-TI zZF}pFST2+VXPo(*MQ&^o{v7&DZD%nM($?Cd1}^R@o*DkT74&Pv^<6^1Hy#6^SK11Z`Dxvz|u6 znB}B0BxAEL7ur4QL#K&Fy`4T3TD|t8ee#HX0jhMS)8xoy_H#X(JxsZcwTdVXe0+XB z@dNB3O9WF!R~I$JG4X%`g}Tx>j2w&r7@y^>&v|`(fi# z?9s%2eF6&Y!%*1#z?)t>aDdL?2#}nnrV3eKB@qSH)8f8AB0p%?$Tyv4W%YJlf7oH% zcrxe&wc|glT|fmvileZ3cFsrox)O_BCah^4SKc1WFudGvCMjI~^#w2@xMM4uGDgKZ zGDcIjg4$!OurVAl`K3=;6iW*acQki!ajuEze|;}l>H5<6#?&pKy?Rk2+n?f^)U1CL zx|zx#cVp#NIy@^XBhPLC8^p?qSrTmh6P<_63*wJRZxGBdp&7JtYoKYEG3CLEz9yAz z?$ymJF_-mP|Dgod$&M_?ZUm1sdP5KG&J0sF&8jwC%Y4me8VjogJ&yZ;bs^bgUznz^ zH{fInmreVL;7th>^rJQ4DKdAs2Q#ZISl+X*Zyf%PxTye^X486;Z_@{O9|%*S!kj&a z86H@2!lZ&XLGV_{;m)tJ9chaHXH6>l=~9wv=SYbAs?w|%-J>Pd=KKlhAa?><(FJ@v z^C4e04ajE6!^#K@jJ42nn(g_}m!V(wga$JtpPpwzPQqx{#9~*6I_+OQm+B zm+zB(yoi!m%rF-;{TAuE5pPf%oA1-KTXtuaAl`f4G2VM*-Sz80mzDMW658f#a`q!% z*NgPc$OcbmA~noC85GmZYr@e3ttsV)>haBw&F`-f2L+mcp`<=)H#$_KNV{{w0}hYL zA}Xu&9VliThoQN$SayxuGSa=rmd--Gar3&L!MwTP4 z-9@lS<$hP=#)c>yO zWI@KOc@wW``KkX{wVd>d266uZHRrdqEW90mO+pcgIGgI3WFUiUvU>iLZ3t+j3;_NU zDC|z1+UE(ry!E1h!dT7>>7;aMN$r<#NR)(~u(n#fWpjTcez5$>vYbF&`A%iC3m4XE z8A~}jtaI!mjm@sZ@aLETPqwkPU~Eil%5K58+jtSDoOX+~T%&_F^vi19bz^Q#RpJCl zxSL-iT$;VLR<-}dWO7p%WW2mXG^Vy ziW?{kLK###!Du|z6I!ALW`kp-VodaCS$^T& zAF`SI%II{7qkV^RgB(uuY({*QwYuKeY;gEn<*q_EPfiHXyKQ}DrDe+P&%-vkb$(PB z`}wTzt$hJMjElEo51|FqJX_f4rfzzRpvAIY(?hKVD0IS0hrno?D!|j0;7$!_FK8Xz z-RpPDop{{?LgX%;Gs~4=C8o2e>$(Iiw~@p>k!D>jF6MpWC~IQ7#MdI3o~pD37WJAk zSgQzV6=9#eOWW;~{#nN7(XQV5Bv_f2g2UMGhN0aD%CdvaoGtCLnTOsR{Mq*CO9zXy zo|-hSl%|_K=+ra^gI+UoQj#MrH2rXrBJ-f7cZTUCpH1rv<_sV9Ls97iMz8hf)q<^W zz$}&0#;2mwvukL@6Ja2Zjt5C;=tSs!n8 z95WoTvQH9|Uq9|R9h1BS$<>SqWWrNYSLp#peTU+kiF6qO~BGD5q5iTv-gJ?v9!k`-s1>rc_X+WoiehYHR z57n%h!|SyL^c?E~YVDW$wsyh4zzRxI-8Zwt`BtGjkszxw0=fnmvwrab1Y5M{ZS{3+ zd+P63etoMyhqJ)mcKu5I!*yk5VAxKF7pR-4UcTJFbA_rP9^oDRr}Xe!M|yJwf!sh4 zvLl&a|9lHwb}}eaa>dE~Q}M&-p*iBTz++)PZtq@MN_ip~!R$i%K#I~3zhNa#lceww zIg(e%)sK144{0geXio94=2!Pr2d1|_;~JQ9v2KuNt8PRQVy#AACqj6v!CbJR8~`p) zJ^DapWCg}u9OaB)O3r7nM_H;AUF6mLqr&k3B;-x@ZFxuepHLT2#1M2UCkXLQVvu&3 zy680IVYh@0&EvSMX3lMW6BYKuuD2*ONN%-$it63$BD6DUXyw+je`5FPY$7cJv}x zSR0yEELQ?e*Q)+tbFJ1?0!?x#b7GX7;~0)Iz=Z^++&}sMlk3n!<+5o7A`2;Pxaou*Zi0Jt;MpCX19RSv}r~$OhA7aDOf&rz$poL zHfh#f4EbLS@5f{tA4i*6ks@FpR85)?q7ZF~85sAgfR@G*$%HWOV+gZy_xX)aMOk=i}zX4PgWQ19nZ`)Mo&RVEh z>s&1^4a+vn`oxT?6Vu&EnPDb7iu)GZEmCEM9~3wpK5jEwp9JYvU5xVo>;SUUS(I3I zqf+yMRl&+S3=+pW%K|DGo@L2~F>qx&tI0fE*t?tct(w7RXCqe-X+_N2%mIhVKvKsr z`Hf;%NPa^sG`lkOjN#nbI_1+fB_`0qnbRAVm^V6GU;1!kaejRG@o1YQ-RO@rrMyPw zNyaIbau%Xu$XDk6!~6=6a?S5#Mlp=tzc)g|7Zg!0^U!e2X#H9-haWUALw-ai|AaQO5oZU-LnGcmhp~ao zFuw77b`^AVehPhjMVHKm;+h7BI$rOarby`{-LD}qT~b?@UIn+#Hh##1DzKFOIT>eL zNl=$FRIK4Qb2XvFL`pw93W#&7wi~8Zl*a~mSjwFQd!&>wko#c1$i`yS2d<@Rjt+V?X~`^?Hfe}O$s~lck0CS2Vcej z0#K4{T95YHJ|;Bc>-s`HyBSa_6Nn1S26M$fT*s4VTap=WWH%204f-AoUu>1!JGdz& zW|;%C&$2)u51&}9wi~Zp{5tnE->UXt&|#D#IIg=Dd~B*hQ1D=C)<%DX zd{}o{RBbSn&_&4e84w&Ie^KjL>HSu8f$E`;exj-HiK<`rSJ&I?DK-TG-xCrt${8Zd zqq*;O$_KfoSz2gpQ+5J6){1AB+=B}CVsh9C4s*_waJ#D%dI+R@42XZFQk`3mF?4V3 zA5h$oQe~TEl0h+;UBGFEDyr#L8#qr93k#&rs*NHm_oR)o9HFy0u)Ixy`w(QQHu%*Bq4B>#@_| zysujOe2_nd%*bI@vl%wwlO&&pgs!P?Oj*-G)RxnZfoQ){^V2sd{>@wy_E~?#%Zp!pd^nuvn+4&<+HMZD!stJ;vIx4qlWW+0YbJ<(!vfo4@k4UALR5!;6ij=wduy&3&$ zD}CiQnjZn$k%6wu!DyB+sS)CPHW(SSJeV2oXHl}37D`RbbcOzmKWH+xo#q--@K~tRM4Zu=>hM>*O>YB~#W^&9{zL0wtTc-D-f2zf`3+Qa6b1 zdQv5OX4gYJ?{ixH2gkEir6fapE~4u@QL3V;F^Bu#yxUKdmnPTk zwO&l*Z4Fb1(iM;L_j#6Shts5fl9vd8RMt8qT0_nx$m_KH-7=4DBTbFxVn}h{jNx^e z*@_L6n8C^3+%xAB@7gC*2&s3>X!tRS8*3Nc5}0X7qv;`#%3@u~S*|TIu&TY3{p}@* zBFpgv6DcvPay9fyjT5!wfY%%UDEC)OmZ&ErosCl0wx4NZ2{1+yKf-PGkWWWz9&1^S zU?5@NIG9XRxwLRI=MGpo?jO3ypcvB`Mg zYgqNHG8ns_po!)9Gn&kA6?89Wa|H^DnZ@Mn4YYoGwmKbZ^s+oU2?&gQYz+UtnEd%% z$Il{}FJ!QmS8&gyza9*!Ht8OZ!Cpp0&uJ6H1{=)1TqIyy79MGQGw@@HvKpA3=2*|< zyUIEd6I>87VqI>am8)W_dc^O=w=zSOLUrBqv%n}?2=dWEru3Uz?`=(OD_|_7{oaF> z`5T6ez4ai_ex zE6M7L-mJF9L;#>9FiA-?IBv8po@KnEDn~y_HCw=DQnliG9ZTfJv^8%XtZLWo1-bFb zI=s52Oh+%ZlScuL2R$LaPTxJm$1U%r)(<+}+Cx<=t*Qy!eb$~G+wrsbWKcvX_V)<9 z_bUf!mhIBgJo+QorNm;+H5%U3P*O^y8w8|8x|zg#-mbmY+RuL09?$rHe*NGO zhQyrr6=xjB@5JbaW(h4m__hXvWslZWT<#nYXO57GG=0!ZH=R!pmoMCVQSSaNle~PQ zV}R(6@F}TM;t!pt*Q{Yz+<9GZr{*H&nldays2kw$Xmov4b4HJ^R3e08I9jWA(I>BJ zx3YA*S8H@I*xiD53tbVe8e%DzJy@>0?z$*Ye^wDBN6gnRAqzVfS=e*#Vz(8sWmLA- z^mqc5u+75RG#+QZS~|^9TdI^zl`Rvi7v;(QI@vLgHuNAbs7OnkZ}1ct z<#XNkrY=fh;8+_5#mv~X{tdP0vRZEpn@-Mo!`Ca&%s6@ zMj7uro$Kw$Gqp0jC&4OPO`bMMipND(c=fb4w;~~0TY7KW`zvj%WQOzw93`y{Xz{3J zwodC~H5vp2QMZ{UWb3mmn%-nQJ)Ieu$);cHlX;vSZJqLQ-uYEPi z+#Bi1RU&GnsQ62r=(2_5uMx_htzTcETY0tjmwV7O^|wxGD$iXglQG!cF(XxW?}=S0 zge>ajVC8UO<#)n?r6>C7=ng^uR(EjbkJI;R6mm5=GE?5UKFsk|%xqejR38+m_swp# zV?=|)PXe!3ZyaNtEKqHzUCu*lw(RKasMg0$s^OEJVwr`pksljseP(t&$s!($$u zB@RSRgM?<~Qg=qDW&&v2e29*5{V3)x=`+K=5KF|aH-n;}O^Tcfi#pjj(cTVu!?I#0 zKbbJsF6R{Ug%2FUHU;pg-YuJD7#W~evMN)RZ1UR+qN{JCeIW z83AvKFcpto@24`IgP-FWC3})(bPQTfj+)ZS5Ki2u>V-cpq6TGBq{o*6S7e~49}!y8 zcyzPmNXfH-D#O52E`6 z2_}?1HY@L?FBp+dZZ&c~k3?JiyrGm%y~Jfvl1p+>C3mb!FrOD-=3aiNT?yB!sWO`2 zRI8D9B-8uB6!F-isS=GrWgV>$hK{5}s9FShI9|FqQ7JcU^Q4WmRf%V`*KJh)<~3L;o$f*%+CBmx-H5aPs|vTz3qr34 zmi25WO8Fy$K0R#uVuucOXyEGdRPe_?7L+}Si)r4Szlf4g?dsnk{iP;gn(|QX5o6@> zU|tcghfj%7NxZX&`h030Bvpx09O#+BkY!`$-&xh#C0t+Mx_AAD{wMA`a>?G4lO@}5J-%>+ z>rsVOZNmgRtfx+#?}ED*R#*Z z`nfchGN0T^;lgaf@e5wO+3bFJC|Pz|i(s^#k?@0II|W-=s&JHMaJR5|$w5|y&5e~9 zeOjWuA-gi6^pvB6?hWR(_jvkm84e5LW8SzUr2@}sT<^i3P2PygZC zbk5KBwrW4=pqn;_M9Jcom>PoyK3B!1$(=GEUuNTmPY&wOwM*I#Yr?s4cq~Tx*txSY zG7QqGoTj`sxrD9MNrcQ>Y(al-vnFajHy^;7n-B6t?utdS9p92J9-9j&`F{6uy+?Lf zjU^mL_Y~hYrmgQT?Z)H1T{_lm$k#lO_SX6M$ z=zTK+@SVQ;V5}RWr`)6Kzpv7`{31TP$Rk1!&d{>IzfH-j|4!yq1viEb4@N{L+|ea@ z+4kXXxV>&^?Knv$V1f*EtkvFW$zvMrQry!eIz2hH>*m-+lDb92D!dn=^0R)|8Sd{` z{8xv%L?=&dkG(nfj9eyO^)kD>;WkfS(1^7vWr$%^5P(mN>~Yqk`mHq zN%wi2c`Dn~HFHjTk1yM8-D2AGPFMz=j>U$fWYW1Bu3vh;;K&-ctMS>}m~9_#KXW{L zrDp9JNV1%=v=95)#=go~yPwS)WBQdA-O}Di%zvx@b^ZZaz5>Xm9NsFDXJ95RG zZhMsUT!z6Fm%ifbW2{C9Xmq79))kL+L3pV>ua*eWHE%1JUM<=hl_JmAmZ!@GiS*tn z?~uhG-kW4$$m6WO z%-)PFsV3sz_XK9c&17f43eX3uIX5(Xm$(j(3ou5CVfnFL<_@wvm9t5Ou*RZkUZ%1h z(@4*dfh3U=?aP3A?K)cK-p+0Aqd(-Q3LEf~}An@W(o6BVY=7GZd>C>|9iEvAkBz&0g= z(Q1=%u!+0ly_iNupf-nBBOA-6Ke7x5lk{X(guU{Tvd8FgjM^g&j5%fGF31=N>CES% zi(@u&{!nryCijo$b^@~HUm$9a~&v6_A2CCa8XDJg-2?-YdfE`LqE2vy(76f zrzkz;QUeP%<*+8Mi-&u>;$h_K_L_@iSF^2N`AFsq+sbVtD)$~KrY26BSInCYPEcp1 z`g?=gsUdpUhS2*JG?lh|Un0XvL}I?|(nr$d?(yk?n3A$AGSsAoYMyrPJ$KFJjIm~l zD|E;EVezBJ5$@zxPaEW@M(kJ3jkEX;D{5F?t5>+D)QtR8iICPg(xF{3%{gb1@->J7 zDW!JZZ@LfXbiz|ieN&BotR2sB+l!>NZzJS#ifr5AcEVT}FCM+XAsD@qPcAQlv5&|V zkc3Y)<$IXoRI0Pz0cbu$aj*GgbjvW)(bRHjL~1IkP@{-OHM{2cjic`I*w`JTZGQsl zCd*7us8^`sO%^VI2;%!hvR+Dq;63$X_K3wnCoy^KuE2@PM#d{j4%T0BpvGBzr5D!8 zJKB-5eXhm0H%Iw9-gFiMTTF59dLkk!=XiXezi%#c;aBSpUwqWW2IqjGvw~FQCFM;e z1|1Z)Y-DaKYNX6+HI*o@iVBr#YfqAWkOvPINlqY6jm(v68%aHt5HMn>`fw})qQfw7 zoY~hEHfDf{0b5?l&C0tj?HMkenggMY&Ydt_J&DhE`!DDLPet2fPj9bKoC8h5aV2^M zj%v=77mmyxdGpU-cg$V-GVda6e)(~uA2C83GFMfxq{5yngT{noxoJEf*cVrJsbTMD z25>!B5vz6ED%4C(<6JcLTRKP#x>CEq&|!W5rYuQcOMAIoE6P*wI35O%3Lx z-W*<>YriR!J)7?P4sa9wbkWu zT%;|x1vhvV+1$F`1=QfLN*_kEukA+hZae;Zmbjx&2ZUY;7=tx#5T8l#SH2f-YZ$<@ zQVEn1xxLNiISBHy1Yux>yaQo>pd`XYK*zKnXFqN`_()ni2)jVHZE|T}`$~~8@v|dc zqCEe7Lz}J9l;>l7d?AZMU8Jbp_O`hjI#9a8yWOs^$>ag2N|DCZ-oG07ILc{ap}Bdg z;SfKX7}=8iJkAhQ@u#WH4ssXD3Bnx6xR)2Ccq=DpBKtn@3+ zepK-W3ZtQ9a$g;Phk2KA7IZ&PMlWmvrmD4^3|tagl-SMFPDv3Ps`q&G6~BHou{#QW z$;RA*_EZpK(v4d&OFC6VtHK`N>K0%clG|6Kn0Y?sn>J;C8ynxx9vRNpyHj9h*4YQg zTzDi{+-gCzT0d=)M3rFFtOxz<^>XWp^f_fAq3X$yDp5;?s&Y%HHgpE~N-PVvvm1JIIWiClo&Aj@g2yJh)|vzl~p~+nEMj&|wMz2eu)hl|FJk|7Ogzv1io-TCxV=E3vWF*CDwOLN+G!Rhe2pF4?8 zQRsE4d>xSz*%9z!^UN&N-_IWb2C0G@&)g@Zye<-Y0`1v!zBD?LhqVhzgDuHv?lNeT zt!N%Rp$LsTiC>3dS`EK$a4u&?8}#34 zvT=K@>Px~AGHQ&rOQqc7by-yodKEHT4tX9F661@hy=%4%hgAa=WIVlZEfs&m!v3fR zk}4!T7)0$_6=d?>-MTW7Qi9l8WlMsQDW^(N1^LO&&v~*t3*g`#Moh20+{(&!eUXLUKytoGWC@t8DsjVGHr(OO5T+cWFZb`u8+18~fO+--D1bo$6~sM00RY-#tk zslQ|=lG2i9or^6;kplHp41K7st4;jK&0CJCz%>}>wxdx-TzT?v zxpI5(ghA{67HR?n?I*UVFBzpG9s=YHe*28WyLvdl95;zB+E({p*LV z=TgFzbEHzrlojOE`|tJh_T`;yIt-C(nd>7K#b*OAw|z_cN*<VGFaE;OWm;I@kO8CtCH1DTO0=Q5|OFh1Tx|Vh-m*qtH%P9avv#%$984;bD{*+Jf3f?4?2s!&Ycx;tMz%sBV{Kit3u=W9V1XT z^V!F(Ut(P-7(m=%1Tr19G2WV5iegJ0vyTy{$99eR-71f8(=ucopaUh7;ZuG|1}YEn zX30BgEVYASv3DnZkKN^VT`T8XQ=U>D&}?;$a>$4jnAyWIFP%y%UuZX3GKEFS5?OsQsHRre1E(0;yV@Bd#xfZL%JfhEgktE zWf5x)JEL(dPc%Y;1`3YKwKg^Ya*Zv{mA zT(``|X#17zh?r+ERK6v?h#x7;PEW@3Go!)ICHs_{epPAD^gt2c&kPJWJ*oD2y|ENg z%@IHG{8-uZRy^F=bn4tsB25Kveih~4?KL{+YsXiR%ajf23$SUWyPF!TI67r|M@U8C zhO9uEo!pmH(02|N476WV=xhrORM|X-H=V+oavn9f)7nyI5(^dk8go?tPo9#=*o?b8 zl{2Nyn^KW05!9s`x%zlQW={IdTRfuL_NC*{*}ttyTP)2}_mxmbO{v5{$L~3Sq--o4 zK8y(UyI+&5^Uz?@Id#kRHcLNL?t25zJL`Xn5QnM8zfoYn6z{ZK<)mtK$9xgDPh?wKq!#we)! ztOv@qtPUhiqIyKcdb~4_l4w6?>P(qwHsYrzfEpEBOyfy9C!RAo!!T{?d3U{-MeJt z@OWXi@mg&5k_x-zB!|o1TYi|kL?}7=#!`KBt+@BWbIw~&Jz?YKWToU;*6bzNuw-_o zMPxndH9cbUVMp?<&~k@!VEZBu;MZ;O*MhG6wH!fg@+x$>d8k%-II!qh=8c2T?R zrR{4EGe_D@SJjuF`Of>VST&RmA5|ZZIfG)WO?I_qNvR}CUSRPmB4g(-AFyAt(w%?D zO`D9*#`1_PMV;NjTq!Y~yx`bAl$~CsyHL4ZYZ$N4f=GvF**0doz5`GL+H*sT)nnj2 zR?KN5#6LZK5G}Nj;MMaW+SHp{`>q^iC}o)Z#c6kp1GiK+NPc|Q`3{SYeOeIBkr~7Wc|)=5 za$TW;cgnZHL+jyTTWG~&XC@U7t?*en5`KHOC8%|KIG|8S8Prsxm(@f9Zy~{sSt*5u=_T5)yD-xQU=>EFHP%A>4x(7xK z-Movg8-u6aL>F|$D22}f4TUemw2}3LUVn=En$8;Fa;JDxH3Zij!KxJOh2k zGx0h(xvqKmjDu!|DsFj8RSKTwI%>A;eKM?MIx_Xo)jf(TB^A1P^djYY!l2kftgyT` zuiB5Aypl;h!Pi1H-L{qFQk%aJ*E6~Ms$ubOrV?}ra|r$B>oY@Dr3*6TYsNFqegxo@ zeFlM&aOi^)^AzU8%hKx^w1dtUGL>DW_mge?qO_AZ;VbrxOL%lFb`xpSJ&+!k|{?Ug;r zmqQdOmfWQ=gs=-6ikl-#c}$;=^4NX+^nxax0Z8kba0gT zT%!HGjm}O^hf~T@u<0gidYYM^u3v7)YI&P^V0@YS;Gvhs#!>Gw>0*O z9std?x{aA*iWHvP?aW5#RZ@tCa=QT1JKO4E1GXY|quCxue??~<*hF*&h?n=kQEXxQ()*=Y2JS)%ZB2e+ zMAeq!45TTR+e>QNQevI1*Jiu|6zB55Hbd!Wzm zy?@!WgqKRdV;7bAK>og1^#fXWdz!zDX9?%<(|OlGM$f{Y@W})c9PQD$+M`j|k)50^ zpZphi*nL-DVESc5ol$5e?T^}KUQxjxEX#xm^#Ca06c$J3}1+qAc$7-xkELm z-g;D3-ekg9ue2>5R{QHBz`$}Rb_5@U+@cSwmh0$zA1W`~u)oWrTY_R3DcXUh<@GWs z3=z|9W$8lLfUdIF2#Z<5x`)ORjwllLl zFd6r9`rmIIgpL)}!Z5*d;-z9`yVPlkhnWEuw=_k4#25C*FMSHLL{H4~m*~-=eAt8n z=5!cib}2T%L{iCExE#Q5sSYlynbyP2SB_#d)L4z1Vg}(!c*-EI5G--s-*B7+zcYnH z@896Wht6OTlv(`{I(+%WD-3M8-fUvLb_!J)5gPwU*!4 z`fMtr^Qhy)bza+rhh>qF_UD41B&Clpa``_zpjYpg13n0b`jOTE!O|?WuE`XuN%O& z2A=a_kV!3+CV?iu6zpYl#S#Ew0pxV*FyhIALQo-)B-8<! z!2@aPrh(wM|6Hj5_Adac>YW^@xj@-_CI>MyZ!eGX0jBvn5S#=zJ8tOE3H93|9{TNH z!#Dor)cfPhNpHjJB>tws@Xz0vRPsBxBFeIID>KL1{v_B`OijH&a3c={mv16`sQS;d zmGJSCQOMKU2#x`*Z*PFA3BIQTOUt=bstOgJS^FyanBXLycMB6Lj=s4?Y@Cqr_43HDDEr0N7Dc0;J}8g!ozo;_T@hq@l13;EFQHnOYiLTfls54rRUdn(%Dw zS|k+(TFK08JSe{rTYgjTzi;wOu&|nJjC20&k^I|ZdMJm9r@Fg3ISK63xqY2?WluaLRMiq@I(@)BMhY@aV>$wX^4rp6nu=95C}Oxa0tyZwEST z%}2I>{|Hh^c#1Y-8vlh6pzQStI#J7@%PRmRldx{I;ztJvWLG@)XCo}&2(YPpIe+>L zfgifxrcXg~7?7A_TqzF_F2~F|g0=$?5cj!qG_h%(_U(T&#fz;Y2H~zap1*s8fB#DG z^vUqk8FvvadEP99c7>MXl}$&rGf;LaK&rR9BXD7_C?=pWOj*Yw48@M1#8?0?c|7=y zC{H$6e18wb_;a!MbHWBV=+wCK&+8Ok;lFV8Qq`&8(CH36FRbJAFF!_Fw4=e^8?Xuyg7tc0e>qR6E468r8xsNySRt7a_ePX30$C}+WCZ#w(L z=)XK(9ZUpli|hzhEeoDeF!-})&&FC_yxD~yr)S&3O2PA^xw|sHj8K(M6A5v}8G&eA zwa(p*@AU}nF2))%5U`(=_SUoHXx>OoVck>zX4~&)gjYV2u0j0Iue|TBC)5d|M#y%J zfa{QZBil2Vw}qz@Ec6!00N0Bifb1KA_k7WKhUBj!F#!kJC@;RU{FjX~hm(G04_b$o$_YI35$1(}tlSvdXYCefD5ASc2%R_+siKM*u2m?;=oRC=7Woi2&4f849|u z=Rf{ULQOb;YeTK>mf2rotN(F4ds1EHGX8pL)HvR4njPum$}M|kU6ZTqNkJ!3O(DLD zCF(!U$-&_1|Ccw0O{=t{6mGp|7sp^agbTRHbHKc@&Yz;H7GOtK!c+@(md2UCBSloY zJ96t-eWm*Ijrr>-{C-Okd~kn3?w7h#-|!47LRvu2oW2e7b@LJE4>FR$2XIY|FdUaA z_}@6N|L3b`v_^2>-nb;wIl#X-T1Kkk=>F@#K1XuJY5gwIlWK_Hoc~`oSs#}t1O#6> zDt^3o%u>Rxf~f)SRiJ|&zggq5TME1GdR*MOzwS%VX$b!~-w2xhGsFxYP=f8Ebo5Gl zD^tAr!F)SBsVBf`*{-pNFlz|%O7h+RhacE=UaNW9>Ljuv() zy*LP-I0Vyd0pB|)E#=>q(f@H}_~0G_XW4$eiDDF-*1eWaS*khaU*6Iq4Z7l9E|~lB zuVt5TfCM7(JZ4BK;eRZ}-yeEXapb%1KdXXB_Sa%sJa38uQ9FQE3?g*wBTFpD1un_* z{k6Zvh+%0{5XY+Q%{^|A8Oe}0W-z$Z8(>H(ccb`1IiABJ%C%h?rkQS8F;R1}!v z32wxWP%x^8=}EML}^@?0G-Aynn4)=fkct!=RyMAT+uMsSKJ%kz5;6I}X*Rdbw zUCpT+)WN9+amN%G5QEb64BtuAfATzCmBlKM_s0t;ro=?q2g5W4OPCh)k@gj^v3|@& zwC({ktR4bnids-OCGP4k0#Sb=o_~u!Xl) zC+iaJouyN9FIX+VXad991%yX26oyO*Wdpm^^0yqHgBJ~4?sevrOE@9KZgAjGb;lg~pMd@&5) za}EdI|9&^vv78y`-!wHt?DT$2ikx;H+K@knR)tOuH>Y5B$F5Wb8sZS!3<+6s8#*T7 zCtuWcUQFS7^y$U@hsX)5pOF%drzCq_V&zs3r6_v1s~+n3q-YP|ETk3LjnQGkz??vQ z4`p90b=UQ#CCf!fn2Ep(_DqpT=0&X=nz5zC{(?i7(5CDj#59yk?4?7GJw=;kYBoT4 z$xc8kBBY9pR%tNJ%2BlkS?ienxu?nxj^}BDJpu;2PW&3Si|(xGb8ug z!60yPK;7WA?X%!ph=Hd8SO{cjG|bWF(uQB3a2v6p85RpcE952jgtpI7##n$`tE~%*de!E_CFP8{q z+Bky;xDep`ulYJ203wtLW@GS<_lK?Z#vk8wh4^*-P(oT_eBgF$IXkKx8mgxa$S4JD zpAG??Y&1#lr}sZ>5alc1SaH|Ez00EwZ(VEH@lUlnJfzR@?3Y6|Z<&18i1GF3kUwi^ zTwfMF*_Y=B$jN(&uI!gamIqrM#SKOt+5q(bt zN#&0}Q+oeiEaXir9ik_PC7EZNTjBm_0F2%T4SSgOrVp@)_KtQLQu;XGpq^L1_wlK~ zc3{L@r|`RnYm?0cjL79N``}x1A83~EQJoKQy3oTWekkv8pfpwU1-t01QL$-t2?-Xg z3fnzkE}XCO9<{AzBlV9@BMZ~AteC}|WOPI?N}H&OyMk(yP|K>u&g2?M-{aPxecH5v zboV}hJyvG0ljWMY5I$Lo6V_fXR9rgi;U*{EOT7djoI7ouwQ|e&|7&%7ifvAIEp!MM&Fy3onaTvne*ss$Z%CFjc*d!+3w6 z|D_1UddF`@(H@j8`hfGMKA0jwwB4WdG}iHR3Q?SaQEk5u7)ENWwKy+Uvk>qq-6gtt ziBHAP69LIV0XOD^QM0+Qh$5g0gFArSTn zY7S26ZUG8ANOdk;Eto7)?Kf`|uoL^%k($49`RA*wcA48in{UFlmUOLrXgV z54Gp$;b*C{81C(PJ-^d3vrUk{|4Il^_AYAm}*W5PKjSC}_)A{GiNF!p58aayt zP@G;L+J0Z0j22i?w;wt$wL(>fe+x|gYMw0O)lOwalruR_H73;zIOf_mh^n>V9h}>@ zoF&rxlj76ZYqol(VD~IPWLTcfoZyn7ri#HLiIVe^e~J3}eo5?89!3Y)DW`zWCNGrS z*Bun_zb^)FF$(%`W;iw{xACNg%d95X;B>xKKV&L?iIw>I#~KKyks-hdCS~&8j`NA$ zDB~#`aP#6sn-@wIZ=3*^maKH_S^JP9CBDs-#*8{pxm_J#5qV6Xm!o2gvN-DZR&x@B7Q2@}7OzhW-6+FWq^d??D(+jqSXO2ACM8uU`I{G-C( zpWa%8e3K9v;r2c7QHltRDw%iQk`nl3zs9u%*ygi1Qf#;BFIR|epPvqGks&^ss@>SF zS#{%d_PK3BlF@<=TzWjU0)!so@-v3O@pv=Omifu`^leYirOx;3GcCSw7P4z{BFw9) zv!Z*q8|?w^n>FmN>azWYubMUSZh-9dCen4zESxmdUe^CrKkdY5#s*g(RXT$ zc7yE1C7Y$y`QYuwu-(mKA@P_u&a=92Hc937*tw61SLk=&Utfbj|7@-Qr&oK!>REH+ z2G*xTiocQ1@X8O&5DJl5=Qi5d-AckVG@5D*U9ip+4yYp!1`hF(P^QK>iA+Iv1mSIRmf z#$&X%kh_({j5l{*(e4=|ClUG}`ewozgWCN${OT4qPV)5i;M%oc^EzKH7>=!v#REJo z%k*F~q=ipUV~WqPd{$TuL3mq_*|anh8pioKM5)8#U{i_9iCXy^BhHXeAY5uvD3Th~N0W#yD= zx}GIW#T^q#RfE^!X50qN6FDI{(m+t5 zXWut}#cr*43H!z)@p5_?m{Wa;U%1=ZNMPtt{!>EPC&c@>70)5=yf?VH=mVjG=-uhG zFz-EReN2xZH*ywMk)akEm zH{$PX7GD+@vS4^~(avwVI3dP_KFQkdtJTYOQ+-snP&ul1$ffXdSC>~#wgv9KA;%PZ zr`59V#>G2}P4$cqeX8Loca8|L+SQ}9=R4kHsMhy71ku!oSCd50c( zol|jgSUY!{uDRyDx^KPoKcpF+mXZl-sOiQPMjyV%SV>H@?V5f?VlTsQ;qw=DaLeRM zys9&s;C6c_K`wMTL*4IIKH) z>}lxFDcs!)VUxf%`{3mB&MPM$B}q@(b3v+0B8RB72BrkmL&^055xpawbM>ChRBtc( z8iBP3*yImvRp$z<$~qibW&B2k*sM6tuArVC)&_VVT+3yvUaOaAO4{%yeuUaFnvq6d z*ShPsnY}jUSgxlbO&y0bxBuxv@%8Z97ujeb`(Hz2L-R(s>swBy)E`OP_GD#7SSIFI zK|OT6@16W6n&xc0ZgFr=i_m6Ah(=?xlIjy;`iYK7x_QgF8=`@zJT(pGKok=e*>2kX zLzjk?BdCH#Xrz4L1{+Q8+_CbiFbNy=fU;=g>=Cys$1OsktO zqG#8y5_0^5Id4y31QNdg%qu-tBobOkrqyRZM4N~dYlwX+(Y@mBc%Yik)me{IkZMC5 z$xzOCmHcM?OOmLKttlwsN@d?vH*7G)XZ77`u~m&0k@GH>{OE)pzwI|uI6ggses!&y z;E_?|V*vvrD5G>6F{;VLv=ysJlH<82s(3q+i%b6wyljOr5h4vg5S(ZHBbCHx#C(Vc zu+<9Q>ZxZZl7>n8!BmYSo8w0{Em4=uWab#uy%ggeUf{00+?-=m^|7eIV#qZp(A|Fd zDxnpOzE)MO9PwnTgExi>O(WijXue2p}D8%g%K>z;M`uCz{jTM-YP$0vGC@cn7M*{>`nq zbb&l-M@-_SmSTz2*Z6bsS=oisjby(dAShY`-T%Fw3t2K))8yE7+>e(POIdMkPJ};I zLrZ<1r)#qk%r{As&5dEBP9><^bOQzKLxjBSXjgcfi_G)wz zF0O>P;|&k5PWQRA7Sh4#x;y;244rh1%aCDMy!X|0Lr|v!56cUAiBIju#GRre7 zRDLff39DW`jpIYC(_EyKQ(n-lur) z?)*1h=$DCd0ov}pFQ^9#wRC3a^3Izj*-APwKk(A_ttBchLQ5+_gC zz+%-WFKiFMSuecbua+x_V^ep*6$CQgFxIK%!JW%Pm(S&@_?NVhw?50ExuJOS`*0!U z7a&DezAXu69e^~?KVuAZEw)^LaQWC|#7F>7se`?vk}yS3UR=v9yG5b-PW~4kf^>%C zSY@At4%4n|=FRNqML%y|Sw>?0Lv|=HRIIXyBOVx$-k>u-d+ySQ z;ih64tNU~#nGD-+%ATnExhyFkL`e9oU-U}np;&j?bgL4%xOvH#SyR1YYoM!l1IH%R zRiTZmY+l{xPNlIwQ)8JefjJ{n{nSqk@vgiL6Ix8s}!N{iN!w_ zit(bJGQ)PD|5lN+h$H%4Uy`9Y|!cw}^V`QF5|Or+{j{nK~t zwrqrlL!V8}A+zrmXnkBb@)AF=n;etQ3_~PK?>`Tp4s5!pw{WHB8N1WdW*LyC=UdC- zlfQP%xZXbQ0nN$lShAHdqPYh)*G%Xf8R?3>)Pg=Y;7v*~UfW8z*62c( zWw&|hdtFohT|O&o)!=2Y@LbC28=mLu+*G;zM}qo4Zjt5JV!;fJ8ljI9DYKZ#Uw*@E z=}eK*fRJ$#3ou!qcgA#oUX3QQgF znH;&SI5C~dnRT>*v)9!1mF>sqG_5hm<;H@&@3ql~vz#8dr82zjbadyoqvp zfZmAx-0vNZ6MOu-oKQ)PVMTwA();3yv$o&N068{`_x`DYk0zcE@6h#H?*<~{e0dD$ z2W1{M`zW3Kq8^IeeVWqR3Q8a1s;kDV0c@`3y!=fo!FUA6G(R)AD|MBA8M$%~mq=ftP&Z&ka^1qFp=yFY}x z_}bZ35WhIdg-KgMc1UBUOV01_R+Q|a#Cu%ien%sADFaSxcds1BIg+@Bddv$G-jwZ| znEFPC;gh144K=8!E3CCOoHMNpNxN9mcgVG3CPgMi86Ahd>jb=g<512vRTebQ>tejY z4r89QnjBtMh|2GN7LBNW7FR<*NJZLX%w=Hh$-Q9+s7*LBfDhQ|3%y!cdVJ%Ff!WgwXQ?8N{&waWa?zf+lq1p$sWUsym@w!qAx=C z`(T6)iz@SFA24r_&pc7ehaY9(!XP&n<36!CFZ@>8k(1l({!i!I1(;b*%@XWVU4ffz zgMt$RGJba+q|SVt-)4`s#0yxoCB>qvm3PNAr*t~+afpa0eF!LfJ~I^O z&EwkCI#t7DZ#DZmVsW9P=zN!$<0qdt!q?SQTZ_`pPd^$To_xd_zi-qcexuz<{L*`8!qIjJ#6GZTx&4kvAShhXO(wBf_^n_l4Q$CpZ>7S?V#+Tm7a?3 zKb)wQXFO@7{E%V5{$ZrF32y^M$SJ?^1ftT|>%K4g%WPE3@VwDjtLMHf<9ex*tvxnd z;BsTp!$sF9y$cVt@cViznJNO=8cllH42OKP>6%$pE!a>~Pr9193W)qY{gQRiO^rbw zzfaIJV$$b--=(K9-#&w3u53Z<(%L%NlZDyaL60)amejxHK;`RIzw4;*YgoK~_*$Fa zl^hepI&KnsxtL6|Uy-nRU6VDzR^Kr9w0I^5|JDvS*x|TL`_e!3Nkb7S%A{wM_5GX% zse!)KuQ{;Nes!p`u4AKwq-}|f{utT?&0LtTV!K*z*0ZsWcFhL1r7RsdQROyAl0+qt zdX+4*6?L4y!*ZQ7hanD?$8(b1PrmQ|EA%yeoa)W%L|BVM^8V(;Chla~8j3l#kSmH@D(Y^1kFV)S6v4S|5lJtlc3JzDaX{GIlk{DQKp`m_7o! zTj})mVzQ}j*QefFRacm`hu3!nmdQRx^w$2vo+&266n>9lI{rPJS;4U2bIAKM%OL-H zSN_UyYLQ8FU#g>i`XzRZGZwxzj`>yUtT8RhcX~fWy4kK?Q?tL_N3PX7KweC5a>;Xr zt`RaPstXY&Qk+S8FrmDAn|;=L*I(rhJJeM#H<~4;xFQ`OvBAr~Bhpv59)FCIF`GP% z!^LJFndi73pxkY;!;`;}v8N=Gl54zoB-r!Wyut1q7C9JluN8-nRZ4T>`CWKSSn zyt?xX%F1DlD-S}bkSgcnTk3cHT=455&N2AFXhUFJI#J?0ydR&Z*Hs&D7NuqDw}OC+ zKeJhQnk=UYQ)L%@73d}uyvwfd-{Ho0wFj^(G+8CA^lze{<_>$ihyciNRDXqhwh?Ad z|Cn>(`*rQd^lW0#o|C3R%m%lGLi7D6JCeYDd=h2CXn&Dhe#IYka>C_|?FU8itrKI? zUv_hRLv6vFoP*X{)ma&K!?SHmtd zP#{0+k6}9PuhJ7hE>n%>AumPXP-ct{tl~lxQ4fsv&;u&u(?B-2E_`7g%QSZ-TvHdR zWt5joX~vO7aCX%qCEvJvk}b$x>bY|prUze>Ecj$~y>5}Z;DNu>PsDME`*y)kqh$Z^ z>n|7XvML-KwuRou$z}rMZ|JF!*_w_xlwS|oa_)W4gYUyZLU9>&5pw0(9**AV+f>hK*lY@PB@4xQn}UKoj-3OVweR(JT$T4D zF+FSa_NyPxy7?9reWT#!Mf2GkqG&v==n(?(G1mGB719TK{lMF~nEz1nAzQ=wv3i1U zB5f^**i2cyrOMmsrvOx;LyToB<=z~*6ld?2W!r}`{zIgp<0Te+wed*&P7PO>PWk5Y zK@%>yzD=)*I6*s9C&$lSnYsnpBvXrf3umS^A>i6Kh9jX6aYKL6_OSzM8tF)BzbN=R zGyb9}BqKGd?L8)b`8DYe7uBmt_SVBlWtaC}sS-~!Tiaeke)v-*EYOaPoq88wNF1h1 z-_^or(LDRX#b5;9*($u8$D3b`X`Fiu4RxL3kKqP-1;VvHrlunpk9_0NR2-A~Y}BX@ zj!AW%p}&J~bTj#qjnEnTw~MF%jrHQADma@@##h}b@-y#Qe||ITtl2X#oWs~y5aXMC zyPVhW(bv{$63;zPWoelxv14RZ3y)~Q#-fw-u#;WQOsDTv?!X62UKU3e+NiuV!YftF zx^rkr#;l&#=w%7(L0$Q}W@iAsuDv<=cC$wn8M82&m+FYH=N@a^{@b2w=bb*^xHqwz z$!UysjX;^!<2OFbu^NUrMcpF0P@R1hyVhgz2-Jpy3JL*RNJsS-^psjRX}g{aT`3!S z9QdhBxK1rOywG3m?UdX18pXylTk`*KCyn4CcT&Xdw-P9AiOWv-CPpLcffk`%n%eZa zdjRF7j&9dNZHH5kR)gk590a`vu}L168w0yeTo7Jp4 z$Pu^sP_Ys@V-spnYpbuaFC-riKM=9(@5DAY&TC{vN181=kNzT{e{jkAi*Iq?os1w?)i%U<{9;p7XRoo{yQB5YQ`d!^LwTbo1 z6XNN(Y-txq=`xj_3#^KPCpx^0ycX!mLY(!-#e#SI;$cFmr>OTsY@{!;-fH@TSKP1H z@Jik7pZhjF*~TKtxlKKDmvD5imX{W8Aa(mS+}cCv+E6>5p^&-(J%#8Q?bn)*(FFw^ z-0gQ)X~^+9g@V_jo1-qJ_;A-*dDLa+Towvt`iH$U9{B01oS%X4&CZ*>cLT?=v7czC zA|o!R;MoQ`_&1e;49qS+sS+}e_t>6nyRmE?g(zT*J2cuClB;a`c;c)J845&9P*FO@vc&IEEGNovepVf(RpoX()$IK@Kl z$#w|%?f6E&T$RC%Dlb$^6g8`{AxL(J=3^an$!OFKL!N~1hRTpkC+{z{gmHLh#p6@m z7T36Hwz305ckli>&by2Aw#x_C1hv|j(Zo_NI3Y3>3H z(86z|j0cu?W+=liSNA})6X^wF_dEFP#c#X5j_q#VB%Y2$G5E*QHy#ZcSKkmRsusP< zlvU7sjeZ5K&}EfR)^!;7!0&mW>m{3su=1O#S1jTv_QY;d`LEG@C{SdY&Di>ih#VVnuXo%yKvJwfq0@>0CVbnir#+;*^6;8LvGSr=5p-6(1FrX zJ+%5LpFpAJQ_>JD=u5ev2FV-^HR_hZAm_A}Hwk=Jp591^449`-XG@_Dq?U3bH;vFV zWwtkivP%>yjO9~3DaWqtLwm>L{rP3CY#8v2eQ5wX-U}?$?V@b0vbp8c0r}9M9MPW|_}#hlmX7>=7joSBG%+Q# zWTVh7WB~S0e1n!ZuXDAW_#zYd=W)ekaORx@8|pczTf|D-JEls&$+J8=ly=YUt@ZmXdqyNy;%xC{yQxY z9Y+2%-Sg|q(}ZFz)ctK=K>uyMn3@`=6Rih@3n3w z@^=39oBXX@knC$hl6msgDo|mPP6`JdpDpS(xro7eB((AN9zIFa@L1M#>;A;q%)kbO zt+4uIM`TnpO1MOcn`mqDsYK|yieteMp>SGwlQQpj3MejPO4a`|9zuKo;xh)ClbGSweXB1#I}a=QRY+d z9K%pp*8ceZ`RjG9UzM>`>|f~jZ6>@;(&7(C2we&FSnc{hqm8|B_i!C_x&#>3uHpIzQ z;I_Q#3d=gWuXPK@eDMF~KlYYVMRK~%E9=~KYKoKU_85VfvOsYQxDRZ$zEw;SsN1ue zmlFzfn(n-D?Be0wKHI-%LFkOV?K>LnigMLUm^-*z=p&=K;2^i}e~b}pHn^*68HPvN zM3a*oDBh$kNA{l8y+?qbTz{iMETF*q#j#l!w&!6^>h-sJ>G-D}Svmmrm9Q)Q&Itqg z9`D($qjIN>2(z7l*8X9C@Tnbc{U%7LG}7m7iZNniPV)E0&R*a)1L{as%NTE`TmdCB z*RWX+-+!T@`EM#b9-=^!VJ*Xnh`xCY(qk@>`}G+f&vm3E_QTX6vyu4%(hkHgV;(iiti?0-OmrrEv(NM5+>D(Rxupb6QsWG zH1~BpGPc8~{S*ODqvx-oe(|w$@l;6DSwVUj%ZTagZgknzu>7o~F%4DRnY8P7!r6JK z8*m3z{D=aIKTY~ zWEHWS*P~pL^+^nxO5}n_ZkUF!Q`mlC!HYdN3bVz$qO>Yq7zRH>-4w)@KIR;BPe85V zFW9n%6q0NuRylv@@}@*zRcl;!w=GWR{Uk;m#StEn9eKW!)U~=sv4djJ>qBX?-ZdAg z=t;|0kM2@BTC7*WKpXSp)gZAsO{>%v-DTo8tS<`~b*s7J^|lYISMwexi`Lg`TQ|&O zmrn5E?eZE~%Q1iFUU0{_ODx|uGC5S9# zF!zEXhyAMzH{T3nxM4B9DgscB-^HvCZVd{{sApE=Xs5l4 za~jnjhM?cBx29(z1C1g%0X4Tdh$NRYyRs{_gWjn%P3M?@WlorXFR+@o5fTX%!R1H4f~ zJgp>FnTce!BPno0Wo^iQjJo9~jnJ=f)tV$4)QecL2VNtd)FM)+SX!k{{q+D>(BSFe zgnI8KnfL)WA+#uiXkdCqH*sFH$j2t^+))Kg4i9x`#fR6D+1=+xD@hXSYE**7Os3DkHIZU{LbS1@{H1~-xwLDvsR3YU6y6@y;rlSEF(fec$Y#gRGvU}yRjyb zmyBo=cshZ=QRtXB;SgIsb~Vw4jNo`t*aVBK?`y}|{r$+V0?(P@)q0jI2v^TGU9j&5x}LoY>wAa>{A&%_QTJZA_uRFD)v_YL>htHHk<#Mu z-+%B|J$xAc)HhKPIISmc#R0V77)PJ!@aMO<{0}WvacU%KWtlt20NpYe7^^2~E*Jf4 z^?$$L-(EPWl^lh}%^sP&cZ8I%m5pA+T1$N8<&n{b>aWIbX!tL(K;Ur7r2E4Bj0~7{ zPHuM;=YDN$f8O-J4B`KE(f0T65w2F%Qhmk#FPHE?UqFNsK4y=?75o25=>3JZ{_Xnz z_Q$fL$ST`A1fBnHkpF-G8{|9cQIG|2`rTE-|NIqm7AN5U1wrm=5U`c_zSYb`CR^08 ztU?t_f*e7#ARve7BH1qz>6dj88}gz)nK_^6`$lgDHTq4%;vG+-^K zUAy09+BFh^%#09W^SJ}D1aG?ms-G!@V~gMfl2MM!89(=}wjp=>gE#6yY%qvQP?nU%tSnY`j1uS z!)uI1S&=Woph%U^6R1eNXuwHBtN@&P5+Dp{zqXjK`DLPpi~n)IU1R ze_?a)N7`p3r#HsCea)?n>Y5!P!9xZ_esqW~Vhm<1CL=bvJ@&-;pM-lQg=cd^z9KO$ z?@oO@BP>nJX<-4)bi|N?#|Wd4xk|;Z<&R3RXufTIlqI89I`kB*^^M8VSAjb;2_q4N z<|}9N3u3RPLD*$85SZzxWM^S^@v>UZUZ6$7&m(tyHmN603>_2o>3q5GUU1oZAGk#{sAW#VNl8MCDUt0bJx;kP zRSg_Mt23l*L6xldb+m`mO@@5kGB6%$fuT|=b12no zXfoqZ@1;RvGb?y-wsU@7nh|n_nXt}|M*@RRkPxX}U-NZyUUC>(W$v!sfVsTWAEx*7 zBxCD~LN0gpP;CZBx03aWlZ=2qV*-6{HB`pLT-JwX7=_ihX=k%*7~${949@(1LKg!L zDR2)qb3L#KAzZ~=4IR)LMsmwe6HlqpCyqoM5A{NQRB2p)qBrmN)2YqpHTpp-E8#pi z$L)S2-AhMtuD?@ey4ZPBw4wPp4_gNe?rnq)puac)(q7Ge-9m`SyPYW!w zQNDrYiw^3`3^Yp?4=oA>$5M(LH%IQ$zNxKX_leavd$61X8JWxp=V6%C!tc8pc1kp_ zT)(DT@LIyKD&_S2GN%1COd!ZL+2k5dEf-1OniYPMzlRH5zYwrKhVH(Q@Hi>l6r1Bk z{<8d-ngkaQBFBF>saniM zJPT}@q?Zl&^96H>!RH^V{c8`rhf2anh~?tcrxCvTheBI1xl{s0j9DkfGXzy!7k`53 zW(=?eX@X#ilrK+jLF2x9^rkbLgve!8E?|_Ovj5E}*T2YSvr#t%?0VVU-{r!W3xqfI z)i9=kTY{mXt(xYC>0eEgcIm5n;IGJ*FV!uyA9sIQ3$CvT+Rz|uR-{= zY(lQgOSUnCW0{w+E@YgDRNM%^-Ze| zn|;zv`zwQ@&u?7iUC8Tyn_c*Oll5Pcdl?r7pp-Ro#?|HXG|o2kuob6Vz#>YIkhw=? z#0>z`Lf7=61OUG_ukmMP_qIrb3>~SV?v#@rMFGww0g)l~w7w!dx{UWLF zff&SiIQRzYDRY8I4QfM>rwj1&L&;u^3~pnBrB5?2jyaXN%V{VDCPg3ujF=pg7+a z>w6A;jq08AdWCuH2EfRd(4o1+@vT62Iu&ij_tLckG+Rthh$7a@ z+_S@1ID=b?ft)GjL@}Xvuj&X=4K8}z7%9BAsDwqV5~m;{JzQY1q=odI>*acrr$7Ey zi$3OLMVRc%crgUYh~lX98vsySao=F2`0GS464naXM8z{rrvt@_)4jFq%HD9i>trf4 ztZ`}Bh?5rIP zAV}kSI@4wiKp`+e5cxsj1HqQ{XUYn~m;t@9zXEI*z51%D0A zoL8vT4-(<-=&yJ77_;1)nJ(+T;`9;isp;Sv8>O9OXk$X=1d7Xd!i7sdGenEN?f049 zh60N)Fk_~%@-<6X>lWjDLldnlp;?66lSE6SD97HYxU%ItUx(|*Mn(W-qa^bQ40ydO z74N}>L}oijt^zXJQQL+`j6oqVF{${l$ADoti=Nj@hO=hAus28e%s=NFc(sf0;oOf- zRd?x`EJoaJXXww>%(%JE-f~~Eowqrun?CVjCT6A};gMH~1+MjUv=w?L?Ofaqv(oj^ zgo%ia`yxw6LcItVuv~Rdf);pg#jSm(YdI!K>_WQRd}FXiy?Qz7)nEg=pj87%QoO7F zU27v9(fJVBVsvY1fyIS*B2FgB*03MQX*)IVAeZW%gvj@NUbUs@Ydx%WV`=SreAUPj zr1PuyyZpl6t7FSiD-b4ibh^dk`2$o3L0yEZ(G}03`HB!jw}PMsL^x+xGZie&?Rq27 zodcuxi#kZ?e^&lwy(Qm(=)*p^)iS!XT6u%DtX8FYF>;Kq-Ga`7LTPhR=r7>ZvXP`v z;8Nh{9O46|8#`N3ycMae9tCwdnnBA{9!t|D*(-TCrhSh-2tqeUqgoWc3_vxOe7d}a zWe?f`YTnO2^e<3DEs`eSyY~H!Gjt`(y=~9rr+%^{)AT9ecXxJO>X%T*?(HN@JrXf4 z0madw(~0bIWB%_r>Z6To%EY3y26-E9+}sc|e;xfve--Eo26xLgdS4fKA2)^yeQMY& zD&h{-rye>nj*Wv$*}boIC9iDjPVFRagd@tb=4Icl`uIo49H9I{Wl&a)MvhQ^NQ$T89iJNthyRFT_^x%J?|b8@V2mSF3;y8Kvt_C!kM`K~0|5`*Mj#>S3*PCnAs}GUItQoljDBSCC6)CXCgflg<9?wE=%q``66HY z#T0#w$~GhG=00>+Mpp|)*R`Ud9jcJ=qkKa%1NW`6foR#`RwED=xWL8GD)Jx zV{J)2EIx}Y`t<^B5Q+`Ko<~MyLx9KRh@X9=Wn>%<*ZzTpgpwnSWG0ze%ajlfCjJ`hHOld_ zK=)H;q%S8$3s3R&=Up0F@9-Wr^p?X!M@lS-XIw`%i;LJ(XZm13$~VeeBsDmN31+sY zLKKIq*^y*2(p7u_Wh7m@yE@GOG@Cb~GUX3gDqD{}^y>Iwt7h*-xaiOam@|A8eR2s@ z)!l6vjS!1%_qLqUl{(Ny)q_{_8ub~5xQE^H#A&5;TJG}6@8 z+~}3@6$bgKb3v@K?E70}*Shp7k`XH)6(ey&1J6Cs-UX4fDzUxUS3+dppOPdynYk(- zYNIZmacd#PABOO~MAU=*O{d1Lb;y3!Q$O|Gdc2FJ;n9VJyPI?$yRAZha?I83Fq#%< zz)k;70#K4v^6Oo3$1;`n$1wSq)$U50WM%y|-N|zo-N}sN*T*Wi%G0tzw_w$QSwD`uX6#Nj;@BT_l;V#UK%}#!!{Cn-BcDv%FJx;)=k}N#rWLYGz9J|#Ic|nN@ml_)8BE~K#bSUxBSEAt&l0Lp z@Da^*I>qIh#`c7aB=3sv_kd%EaJ8H1EKE^K--G53&*ONM(gSiG2R41Ij~0yY#Qm+D zlO+@Z=Cvkv=1e%59DbpWigT;qv$Ja0j^H0#WHjbT?5<{BZEsGhYNZc04Q?e9um&j7 z@1;SZm)=?9e1Ss~P9U8{F70xZjPdkVBh|?;s#Ye8u$9u}yT91>3fSC3?=t^t6uuMU z`>sElV57c@LhJLr8lah`kx#ysNjPh!EjL@TZP$8xFyL8bGDoZG19!8-q8FX|7;U0I z;VjMvV#%v;wlPr$UsT_JPo*Gc{gH6PcjwuA8=rN z?(HwtaB}RoYmcq!B3;g-o$#EW5z<#0<_?X#DlF0Wa|wS;tKlx#V1b^WGt;ok_T!2c zc!B<);XYyB#!$8Yy^1POTQYcN`91JdH~;rv21wc9vl09 z7>%Q#re{6nw0myp7XEQOqv8zK9rrIrnxL-|5sd0TRy5b>-X^B<6%o8X-jC+wI&In$ zg?Q8Wdl@TP51l0S7^K|gSR6^MWRf!&c5V75NfRV1oRj%tqgbQqs?y&9^vATnDE!!) zOc~ZL6w19h#&V|@Z&HgSx60jwVtt*#hzU`JyzA_Et8E)*SyiiT9@{Oanvh?XbyopP zlR4mSe2sG2`o0<3GJs$k+|aTt0&UQvEIBtcw!*&YirFsEOqrw8gQENY+L#|RkUvXA zX;KbjHYo=rcz-m$KHY8ja;I#5)BT$8L_TmmJA&$XLtj99AM-uy1t+uQ>Y<(c@#azi zkM3aZ#TYO?IK^IEwmVatOTJ)2o!HZi!aLmGlpnYwnQ(x(jkUIdoj@WNhn$`eje7lM z-chliX%`p>Pd+@yoV}wS=i3?|eA>Lhq^GyJHiU^YLH924YO~%N^)0<#v-mNPqdsd8 zgip=clUYD47$_=iM(g(Ct{>N@_^>!Nb~i+mPwVnB)Qq43q3vkmyDuA5PQOjFccgl) zQcuQJa#K4c;d_k@0Xp6H>77lwH=-iD8n5IAP4|T^d2CvQ{N%G0d3Zs$zUNZc)=I`}~MCFmVWC+%KL3%(b6)9(VdW`U!Lo5E>jST&J9 zS=7KHos|x5&fV`xfhRdDL=0hmIx5D&zJ!35SQM>O1F0 zGH(=oHV@&f?h003?R2P|_12%en(_~bRvO`u&#~fF%Uk2tGW|KefXzmt(en%pjXu__ zvN=mTL6L%3qDHuajEcH9sqd-G*|@l;cfG$cVJ_RDg>?#6`Zz{Vo3rQ3N&!XA4PrjnN8dHYjl0uWbc#0Dh!@{JW=_rk8 ztzx1RCKwC{8Mo8t=qdastrn+p;x2`Dcx$eCe{Vwnyf{a+Zb>=qF~#J~bsy6vuhwUIupEE}G~jawc`0A=k{sR^0gf-Irsy z=asVr^L5ufj5dGVd*o3CWK(0y?tlolbH-iw0`EaTRwWK|7 z-@V|N_%|b-1m$l7E#KTSwD~)j_@4YrDHL2o7(VLKV$5dRcwbpyO?>aDCr#o*Zrkwy zr8C6p9GC=)wr6Gg4TZlsY##!}8#jn8^lVG49hhF@Vm|@H?nG;>LMNYj7%IwXKI8WZ zCV>Byy|vTPk|AG5I?S_7<4#I(TfA6??p8){E*b6 zoS_~j-f8W5vDV2GrzIghu{@MQFQR6=<2w9eSKGP)cLMsujGOseaI;ueFW-5iK!IryFJa$(EE~`wLGB; zbT7|{`Cb`gbzC>aCd{UO$-wXmMUhSs&$`r`H)7KGH0CtD?k9^-Cmpa)?95->P!?Fe z`Ox+(+BnDEaUw(i_#`e%tT*n^!A9ssxStFKE$7`>1I3Hx%F~}zTw|*_SzXDb**;rq zl*=p7Q7AP%M=qEd@xz1vu!ru)+e19}5O~#0aB+Gvo{o5&cq11mJU_MHD$|u#>nT`x3mDsxQ2ty+8s9WdB^v69 zN`-&Iak7npHGay}`o_+MxS-PNx9j5WEIeTXD;5VYIA1hw#BfG7JjenZO0q8eX~gX$ zrrF9?j3#CN4{zV5!G`{=Olps%(VmfxUD^eedaft*e%=7T2i0(swY36;LgRM{T1Sjc0vw;}@Hq6N50$;1%Bu1-NUv__Eo-e@ zP>pN->v_*vj*z^93>Lp!9w}-}x6f|s@qDZ8sISTBMUWpQ^FzFjU5p)795~(7yMjZU ziQGrvG1p&hS=s8arVCqROoX z#^|;&)3r302zUQAd{+C18?uV}{Hc$YPX?AAd3C+m(B;K*%u|oT($Bq%Tcr=%&JX4Y zPe>0cX^wa%HUo{}R4%N1kFSyo)4n@zzPYf&SWO8yb+K2I<2?`WKX$xX=`?42y+;R+ zkoouoprMjb9q_60^L`K3Ka?9^DET~5^r$r<%~)=#i<;d!I0_#}qJ#RSC8UGhv*E7i zq$Z!n-KvA_fu|iqD=LTGJI|TwBzN_8R-r+F&_j=-vQtEoF$G>$_8!GY;EUbcBC$1M zRSGXre>QSg6#aJ30ntW(z0cq-C&?2Y5^pw2i1r1LnxNq-3u-AmUP$g4b^5VN{NBTo zGN^{?$0FSSAeLE^;z_|;(*!GFm@Wb1@XL=V*UxQV)()7L=qRsI7Lz;JSX2Xw$D(ti z7W6NT@eiRDj@M6d%bzbK!N}Nx;sU&l{$e-C*0XByqnEC`S?V+IEL5I5X;af1ymCq1 zjdI%eEn#Lzy$xYv#bf~8P`(Ope;N7O8J`!H40}7O5;X_kb+1QkcJK$%)J7EsWpZ9D zYnJ(trztJiUy73_WG{jD>^SiJ;h~NbalTfScKg{gP&TurM|D=ci|cwa^JcbIW2=|G zNGyzGgE~)t=e@lDbXFLjY4wq*!EaV4NN_a`ZvuE@Gswx9)c8#JR zO0tSvDa-iPm7|QpC^^%|Co|Y_**7I9rxDiW&7$CwjqA7IlGYD5kUI6)tU523TcD#P!CH$@;H&&0z+fot{ z%KXlxWFaCVwW@E6XPp1DDv2j?zA`$GzX{oDoi!X+9qzS@rZjV47^jT;$DW#QTxmbm z<#)4FZmjRU?qAKr2m|t{{rnLu%kkDULBg`>+3}+oC#%}%O?(}xu#}!Mlo+wxu3m-H z()EO=Z>YX{u70A*3}XIRuMXx%Y4>cs*t*Kf^7n%3T`(D)Y*KI^4#B;-xEmy@%+ zGKR?d55$yNC&Vjastnpi*I=lBLDy!r^i4ewKB7PdRFyY@GO)m`<(>K95#7Fm*dZ}8 z_V?s85(A!<-r98~Z?m)9hWNdu3~Oz$QU-Ur3NMS%fH)PydUx>S^#J7vNw>%iaO3+CV4Jus^tM^?*$rI(V{v&ic5zTn}6+a~#0P zHIxqxgbF@t-+`$+(ZSvpXRTHPS|M9aN&1ItjG`zTukN%;vK!IF-WVC>EJlyB+F&IQ zk38aJPh11LM?!PfHI8+(h4)V)M^hZCjL=zfZq-O3w7Fy(#pv$1!gzXrXLyTx+G6R* zo&B+x8JN#Kdw7hbb1)V-TzrTno@yy57$guz$Q$Rvv?Win!LNzG5y)TEs6IaAyKW$H z2j$2T=jYVwLDRS)=3H;%Znd>e5cddieYnx?=WgX=7jOTrKBfL^UVfIuyN0?NiH)Ll zM5uAi?E3=H1BzL?*GH)TW_tEGjeLc8Z63vVZ*-0JlfjGUguTeK4^2z|tC$jJR~P7g1lYzpkDScBZJTn*al%po5=nk{hsptjDJ3V;AVV6`Dn>jb z53AI+TzE4fqH4dfQ@H*}>3Nq}_yPE)Uv4N$>^0$o&)9!u~zuvWmRyLZ=CWfCE$E|5Y z!F;5yv+Yj8on4qE#0P$#d2fN$`A-fW%h~4YM zLwK9wprOkD>N-i)RyJte;6~DXJBj^;Blg??$d%~z66LY;OD$sCW#7EWBsXZww`(ur zgwZ}lLLJ73Gsy|cm%PamYNg}u&_ zZJn<3ziL5iVtly2nm!%0)z^k!oxa9#=S<+I*3M=Zok}pOcQS1|bB_B;X>(EM*0Jt| zZ;kcul<0Q~nh!!B&F2_fTsX^Zh*pTbE%UPgv&}hA6;zY651i@b9FU=H>a61(*TGP7 z>Jm2QkoZ_Q7^vI*P}w;iawXs0!B>&|HjDko8*M_u)po{8LHHWGH?$eMc?Q|%sk)x$ z@W+>ko=7Vb^Hn^DS<3+AxDs`6eb1$!rncy#%(obTZHTOd58 zzPIuny?(h=OJmn$Xn@Y>Yc1&up2bv2_5O))D)y8RMypQCH{j9}Qvrjej@w+#N#*M$ zh0#n5og(XWHW6ZL8XiD=%HK68yZz-o-UTnrr81 z=AN_9&naJ%wmqny?UN^4ENR!#&dIAw52a9i(Dj^aLnq#Z@pI5loZnmXh>t)nZOn@( zm<##|lC(CnXqk%-d?xrig>Ue%7O;+pXHInUuYCd(BK@@y)}9xU^u^sRPiLz9>Ne+9 zqC4?tgpQn3{&!_>##W(}4IggHS!d{Sl)n2g0#mY6eV20M> z=@0_V>_NsC7xl4TBBv(iq$!6w1KmTcCsN#Ph5NCKX;rUZ5@fe6lzY~c2whPBSZ|tr zQRG464uzs#t4m!2kHkKZgPQbI>& zX!6u8ee9K|a(sax$10@{8twZWKCvFd3LU}#)qc>u)b{9g+&@&*uu~*C6-Y@zGjh~CA*d#*Mg82gY{s&P*(;9$ztmxl*1+G`G}pz zXqSOo=0E(3qrq)Eft7^X;q&UZpgT`#3c^dDF@Vk~b}Za$jD*S8Zf zFEC5KtD_x?JunSt4yT{hGOkGvy)5Sr_NlSv>EwYjOF_^%4GZR$@3tpNIbo3lrc*INov(6Cjw0yGDC`X@prE5i$w&%q5f(oM}V#20goa zl*wkEAT%qqW@fGQ5!b?uI@O0t$#y*ACpN3Z&*vp2+JnY{5N7v46pCb9xt!m8)4pJE z(bzU14tlXCt@}h%a~WZG>Nuzl?2KQ;4ltQ|ujBY*!Ph(pQM^-g%YVw+t_JSlr?dKl zKF%rlwt=WzO5pQo8lAMv@akx&l4zY+RvLffl~{P}w393ndrn_>lKRanf+=I20=fl< zj{0YXda-x3W-+78t0otn9??U68ekvg zRp>J0guMFh;goS=)hbpIE02{G*>TZL=bgFxLFd|untMu6==49@2+!fod1rN8LArM; zl;Gf}=+zlNUa(hayyzNzi>jAS)L_Z`>{g&vDYwz*O2U{2u@&TY`y5)>BzWje<1NQ# z04?AmT5Y`L(^JP$)G_wb3K-EfjBiK32@+rEJQXQ5+CP+_Tyr^c)nK(Rx+vBoRT1mD z1Uinq`*>lFFJ;JX6^ibZ5DXseqzznOIJ3I^qQEta*0d=C1Y+lH6#Z{YfU;YD@?7Mn zai;cLZS`79K9y(n)z5*Kn>@I}#emZh($ZT3&xQ&6}svdkJ% zhL~1We7WvE73A}w+eiBLyFWz{GB{+@@XBXFTeTmo`iUSrOOG}`(L?Dr$<$WvLP;cfq@h!M_Y2Q zbmr^eIgsr}J#h*5A_~1!7>Mu@t$CHCifQL&f=tnErbR^NcnNlT4D|CiJum|DFEOR9 z6d^;&Wu?WX0s(d%opn7XdtTXKV2C}m zu5ho7-p?XvwM(y=^2l_D&&RVVI*}8h)z)ol^gP#CSsvX<&$^oqgNg0E%_gx<;SQ^Y zZQ22l(O4kXR@U4nb{2vbE;t9&yp4}05#)(NahB8ds`&kQD|w})F6d@A>u&8?XuS4l zh&wFi zYT9~Rx^hW6QdfQyC;r^Za1M2$!{PeVKXdsL2%0^aJ~MhPY_FRh(SNnN8Wqm*)!g*? z_9US>gMYNZrx-gms=$3nh`yIxg%N!zeJiqAuvu^B<7?qD+#5wRYJ$V*{vHbwTyOdk zLEW%FL8P|d;gYsRU^uJcTae?|^x_=OpG#}Sd+Uxj-9ws}*vdv=f$bLL`4mgOPU;E$ zV620ldCY*jPdENA1qpK3jvW1^__@CVV8rR`c4ZbWQea+o)JWBIyhouy0w4{ytchLM z8Dp{`ubLYzo^AC5`E%cVwH5dV7A{<}_)Uw*Wz`D#K!2TL{Zf!@u>04g9YfZnX=z$p zDe9?tna-pQR8B-HWOt#2j((QQA?NvIxv>ExHucvGBMKpRKo^BCCI-~P>YUW z^!OB$N3g6kmTa)+?Mgx?#D*SH?Rc^jF8r33%0(*K@{V3XMxi&~_~5D1fPYeKjr@==9}nMLaml64n<`S>Tz#?Z98xVLuY7_QRvK)Qu zc4|Xh6{rN_DMosmSY_;$$g@c2x*gFen2tVmaLGE?ifxFLo3!?=)cvcU>gip|!e!4! z(Ft>K8+4VOEsi)&Os`poK+nes=15FGmWW>HPp(t}=g!vhyT zEmCe*--%1Yn>?ih^6WpnWuJ#_QT2+YUu>Ykj9nl{Ut&7r+{nr?W;GTzs+V8wce86f z(6v0hc|U6JG8wt?^0~0i^-JcA9e13g=r|?mJG)i2pR#x#m!oaJPbMwCG_+ovhP%J< z-SGD}_*YvQ52A-bSITbMJ4+vUlr*<6co>wt=XFuf;LEu4ZT#upzGUL2p1;Aq4v%J2FK{t6h!uIR z*b+aNJ*_)d`7|h6UQfvLjq8cG2W^#hZrClkmpc;qY<+pQTRs##>uU(nI2C{5YhzLR z8e_p$-POPQ@BEg#*j+GWX*E1_i{I`t*zh+zuVeeeP;VqTJjP*W6TwciBww#y;#3c% zMm9T*Zp^;PN7aUR6{vhVJX&IL%#%{fwo2FXf~``v78hS2H^5tKhF!p4UJ6+veBQqNiE+6VSiiQ|`^Y^S4!%$*uUneMjn0)EWRBbbGcp4WlGJg^e049PPxjZvZ z{Sg1L5pMdk?9clYCE%ZriMUeWYV~S_k69~tc6yb>*k1X&I!lBYQ5VUTDK3Jvg}kJ( zK%acN@mug$mw)hS)L2WvGlPSAspb_z5>_8t>fgc|4vSy81miTIy%KwN zv5r%&;i5xe-7gp9Kfl%Ynea4h0fJA@m70aL)PZIBT@R+tR4ri8J}m1(RWtHa5;78< z9dl~=7NBN-1{UPeajWr&sWS&qTZM06l^cP*@?l)*8n78~R9rL}*|`nJ!iwc;|Av-X z^TMAQhB@XM!j;$%a)umLz-m%d>(g-K|7|t;?vs}|O7Km=*njcWwX7n|GlU4`aHTM0 zGS(x6Jt65T-}NE=V|a)+^RRi`Mbii>T|IOve6M%j>uUeGul{;la7%@U>r^VebQffj zqNJhV5P)ai2|S|Djzyl?bijwaU;lgb7tH@C&X!-?yq@;2`jZ*CurDTrsHPu?4gR+~ z6EA$c^p-!2tCAmX=b52K{Bw>N)3V7i6Ca*V(@Yf?j3jRl{li=Ot;wsPhmSqF82L=* zZ)@>q-G9BqfBm8FBz$XP1WKa+AZP#ofB*OYSqugh+}(QCuTlT}6#w--{{3nq1aO~T z^w*B~2OZ}B`T>|(P@j)4spQF!NqyJa24XBy&^1Hh^r-VgCTd&e-?FXyiq!gSkS46v z_kX?WA1$N5Dx<%#DpoT|04)iW?>9YZ;GWO|m31PhS3ra&jVRKjx!wFg{zeLbVQ&xT z45CRxq;iPdtr^&uw7-lTc8&ob2PpxX>-3ZV86{ywrEPG8Fq~eDuK~86QcH+dYzCE? zu^SHroq4!JzCxTQ7*%L}8Lf77F|vK&ywxq-+bSsE*hX!L`EdeFC3QcL?)dGEP9R!U zv)$DWCMM`=D@iRL{(E)*k59}YibQ4j!p;;7^{RMnV$<%2;^zM;(*c^#XA=QQYa+fC%5{UI~BwGf)~Fe-TUu$Z#!UpYcchLgc)}u11cU z(!U&x`iUf^fF`~9%e(CI6qWwpaSEV9qUMhOca%XV^Geu_eU{`=989eRy)~0P&#?Y| z`}vPAZRCW%u_D&YBg}%=p|9~FjJsJffK=f9A@2avxz3r_mbVL?&U*jJt!eMN9;ohE z=MRAO9SGV?me|PzBnjr1H3}&)G@ry%-0>dccZL+hzBM#k5UwT~dvevy3* z@tMF?(=xaRA5;z*OSFeH!GQdTebWBCrr&Wy>Isf|NFqSC2Kvt>KE4Dy#1K(Z=--CH zzq^z_`)LI)UL#DE%~=IAL*^pj^1-#JDHse*@|PZM03%$o6dxox<1H{K9L_v3Eg^5f zf|%!u!$v9b@QoS@7)EM7HZ>|TP@kHzzjl-)#30EmP*-U5hZ>Dv!Tu|VVCh^3qH~O^ zfKTGE9>O0baEX?mgOc-7c+mlf1zsgx?G-0SJ8=EUaDcr~u@#2IYK%=WrY0vPT)JV&R6JGl5R{;u8DdBr%lsE_M=#8!nIZ@--$se437y^F{=lXAYh{M+~4_{U)+p%fQ>EzZ@QpM z!V^eQq=`jVtvFP1I9)$t8VjVE%j5E)42P`DIBunI{Qik#7>f?K!Ku6ZQ5-L$I=vA;9-v(nL%(Eh}t|Y<@8M$6GYQ0GDquLdY-v>yx z4Wmg=q^KtyJhVrjObg9)L`8))`J$_hK?64q7`6b42B!`d&wPFM8lZKQDRfD@^axBA zNow4-0;~>S`Mxqg??XOqqj3ATVE}v?%hM1*B!tL$ldoU5ul(>!3hcYx!elus1LD6a z=!uA<-`evRP&kJ#gL{mwh@QVoe(qY^qTCb8s`Fg(MVIkt39V|Mimz`I~*_tnO>vSL4?tOQ;2Bk{Uk4T-M zV(69q-lOlrF`byN3}>FY{(nuO(5Z4RXmk_5nTEo+}`H;*L2+x@0ED~rs1?Yanp5jl0!CcKrp282j3a8JfX$d3J5B%FHC}kpY3k6Ea4cV(RPxm1o37atX^x115u;*NJ`5w3p zc~Ud?nokXOgB^UPC|%MOIe~%nG(QlUhuL4@0%r0gCNh9$6~43~(rg{bd{|~&z4!hp4)%!TPgdMFJmtoYJAkZDo9>=~9O_fI=EX1k zt{Rk*QFPBPL-J{l*SGl^B?woc#+!R(l$Z{F1tyTxv&y1JTOH&; z{VYVa^N+3h--*^0?08)Mf*GEWEot_XkT}3X#JOew&zaN%K<7ug7AEKu`jN5?$PTLG zT&kUbh{`EVPq}yivs`0jlEF697GYfkHni=I?0#0YdhIz@=S4G>j(X6C_{o~>;cUtI zUfD-}jX%`ys%Dfq0bI>e>7gSY>Fq5;$|jV=j#vk<7mI8@e6Z>Ar^MqZgpBJc&>d}l zWZ0BqM1<&Hzy;-jkUmjO*)doAX(kqF`*)WZKZ%P|@EiXh4}KI!E4Y2WD?!}Cz0ZP? zfD;6laq4|g$5PtH67={VIi_Trgw)HjDW3int(}~j`z+SF$)1>&!WV?j@>#W`MI5c1 zms0ga@0J{50#gomIOC3((ddKvF`MN9ld^A2BOx5sieI>X`xuT89LC-tyonz`*Yyq2 zk=)+uFKR@)BSyre8wXzGc*$=0;JXej+O9yyY1dW^(+K{8#cc3vq&|D5ojomW&ae9o za8$ezNrFb;B!?K@(LCP-kK*BC{@09N-^f=^-QT_)InQ~}L(yC~26wPvn1Ey#rd;E4 zH|6yEV^+rgqAqy(-!D02BZjW!?BmX6K=+EZhuZ!+8BU*)v zJ70IBHTD644#omG$nkT*f{Hi{alz076gRG}3T8`N_@=RjBuW?`J?4x20+(_8D+UMO z6MRiK$|2z`x7;O45j!V0@H`w=uoQcL*0lMLW*6x0d7^ z?<9Zd8QBf;!+b{ig96jPVjkd}>?sfkJyXh zJiD_-D5ul!S-$PqJ85Dp26hweKGV^^%p@{u(Mv;8=u5+Kkf|p#>!m0L5kV~bVR%W>KF#o`>9()`W z^(^9brY{(%K9-+SlgkD&{u4+wq62D@+&O>8H~zD9>yyLx1cB9{z7=~Z zitOB{=o08muD!aNfGW;==sbD-YAmAqyTe?8euJ*N2&YEwy{_-zi=Zn5*YA27!z!#lhG}L~V~rDc_E~scNBX2s{T{3bBR)i+H$yb^nYPt?&`$ zAzQ-PDNAOx1#%-dLk-9Eg4k;lvs$0Bv1g$I=*UV(i3L0&$yf?;(VRAW7b%9;#Cipc z=F00m3V2j)*I^;)FhJgXAi!U6jX6I=(_xxu6$Y)+h{0!qPGw~+04&BjFBwGCu({*Y z18n9p$1`iRI`$&;C+Y`muKh2&Uj@k@1M0)Jrvnv5U$-F+DLTxE2emfg65_yJwH%^O zp*Lv+JVr_$m$7?A@F`0Re$MUPw-88BnwQ>Nt8xsh#hjLFP*1rp3kQ;~$<9{OPakG! zZrm}fSJdcbdb02n1@BOp#?pekU-IyrUuMT()p`tnzaFLTJnOuH^;4$s8#~!mHc~P? z@hJ@wZ%n{?b*@InlwME!b*6UTo@Cw||=?KF-2OX^ib!HO(95*UpM zIKg)|p}jwXbR2fikeL_HUX`xk`XL9p#(Z&@*F42$;wNaonCNQ~2JYDz=Jb(Uicq#YXM~f@zVjCoQcr7kJ6l(hJey*i$=i>U z6C8YH`_1-|z%c;r8t(epcU2%z^=NXhQI%M!89jn(E?CBK9B#Q7%!w_6S&VV5@of9%mR7s12IODtW)xZT7il5N~F~t zIL=`BD)GNRjCT-~gin-3J~)ivTe;2_W{6x>xvlHzzGxfq?WoUs+2&%}Zfeo%!Uy`b zKWC*J)GYRHDYMO@k+b1J3}|#=H+SDwhTW+dmAbX9kK*(`HxC~1;qWP3^kp{_S7f^! zS0&S@5+jj!iIJ}Vfx_zRx4Z{n2j#7T3tcq)mmh~-PwJFm#68z=Q@pT_UmH)+hbieE z!|CQDOJc)|E+V#0b(L1BSq(;Ic*5ES7%TLxN~lr_x;FKS0C(yxUL*YXBH&&B@h4C2 z=dZELVB2E~3lm8yuE%egxsmp5ay!A|cvVeHPw`rInUEjaAr=5doD#+5nsye7Rp(4V zJ3fKoGZIjnE&CGtc|lKVw1M*p+IjBBXFk{U8wlYbpI&|@j z3^d-PkM?aZbJt5p=dW0zf?c4|jJ3(`>+Qu9u0six@nEoKu>ESbeuPEyNHCo@k9M)Z zh~YZe1@MYKQhR=@1#6$5w&-zG$3C1(BR4-}#?@*JygF?*e7%C6>>r;FgDpy@-=ugk zwXg`1{Au4XR*5+C0*%~YRfUVK*P4a2e)r6U@wU_~U+zMVH*{1j2tdUoWStP27T3O5 zJ%N;WXQ!#1p^0dVlVNge0owx!VX)45ID2IeasLxNTT{nn%0*CV)Gl~hOZfDzC$)tO zTE!g$+?Sj`OSf{bV!(#$6XVo7D|3UkkX(x-tu>PrnD>9#uz5F4+^=xp!}fOM3ku&M z%;q4AKLvPgM6;kd+B>j9m2ku?=hHyY6*oE0J$E-;;>z&rFK=L%KRjiU;UZg+q^=n~ z{>l30vNL5ewWVl!x=H&5JB~iarBP;$t~obInJw@pNXPZOOFO@LPw|}swwr-J#@5ciIdFuP#^0Up>-`(V z{X*7@uUEkGHb1K|r~vdRSrqhV@`2u7t6yX(w4GGv$E{($zsH&hl(~^r&C}i$Lyjw& zoh)J01VvTqy5VRi0EU|(R7`wd7Wh@NM|5+*G`ylC&pgstML^oLEhV@c&=-}&Td{YJ zw2HJ<>QjU&NAI>|C+Qa|wGi(YiiAC0?{72N(K^Xl=4R~&0AXz6hc(FkfrgeOov;?00@tvITI3GYvYHWt6|`hkm5lrT zv{XBWQ$B8wN1|PyM^&H{HRS*X4YbId!}W8@5P=TJB8c z3_S{;e$6Y*W~2|kqp5QjW|n)(^K%o|STz~A)b+rXoPs^)ep5xgz`#C5#Zjx_dMeCa zBkYlj2Djn!c<2XE(RiO~)@AB zprXq`*4*LyIHjq*eqe;wUf$%+z_ca>tKUrLTE2;HLiMOg3_2*4Pxl=JS;QDa@fI zh{>v~LX5vqr`-(VMhwZmRp*-bnjI6i-M32Wuf<^)jd`D-VxgHeW;uSq`(t8^xJ*uJ zG_}BAol=@^fsP{*)Z#Jf2N$0vMLD%3DBR$GCw4_S>rCq<)`%p!+T-pJQ1v|AT~CeM zS-G-t)8K_L>g%|osTy+|Ri|~BX{yQ5jDypc4+sDr+2i`9t?6PrKHWRB=aKHG z{DDSiaT;o#(EGQkc@nC_^acTCKPQSl%+09Ef0gbJi{Ez>-#WmNgI$K5E~XH5>sb|^ zns|CQ$IHnrOGc`geM^6v+@z7FT@n+4nNpXCub9e@W;};6n}d{EpT{6=??N=2ezn}| z+Owmhn6dam&l>^kYH$~=xR_JB!;KBTT!+7_NtO0S4aXi-O5BsFe-qa}#&7-JeRo^2 z!@OqmJkxQS208B)xSG3&g4t)F+Ux+R9@$pqCz=g4KECy+Tuc1Y+H~3U>Pdp}Lofd5 zvR2yTl{5< zGl&J9Ox^qBM=XBLy-!@vrFBd+u{Y$bgALC;M^>JuJ5|9 zZZJnoQ}dg4v{12AWNi$t+j;hbQ&os4?3TvG9xY=i8mc|s#a~qR4C5vasO%E5Of;uw z!(p>Xy=kfwPueh+tvrA%3wt#IV05)-9R8HskS zmlWKPB@F4u97o=k2fZa%efFhs6-=swjgu5zZZlgqN~n}L+6V*u*-TLZy_omf!Pxl? zFahLWR7hjk!^nI8d3rrKRjXzVUzF^JE`?$fy5oiKtGL_-$EQD|N9phC$0sC)w$Q=V)Re9J+5)Wm}tfEK%iRHe*VhsyNMaPydufcN4!P zMAig*$XK7}x?{d4_d1kS*%%Kr3>^E@FTo1zCYlv^ zy)Wb{YlOt1lMksq(IO9d_Io}4RiKa@{FZUgYh!wA(>#3&T;UB7Vb{6(|14jAy&9as zL^2xh_-G}MS{m;lR#%3}5VVLdH-neYub)0mjx36A19a$)+Tvgj`1srj`_p?u?iDMI zoMa+#&~X|biS@G`D6Bn$*4h2^zkd4GL3zbdm}1J;P}!&?O!tb%F5V{l({IA2@50*O zKDoz>yz1giwBGmQ2fPixOZGjd`D4QUorI+{-OCl{qu1C`BUkxor2_lJyvw$ zK~@?b<)DB7iQn&S=XX9sLRRHM-m_iF?EF*62bX#cPbIN1ENtJeH>wx%9(rtZVcUsx z^&Ct)gn9X>%20muh*Y(#4`)m z0Kkw9rHbKl(*t`pwsePi1C1Qa>rR)A)x}hJ4K^E&i9^UY#(Kg6;Hys1A`ZsYhoEXP zc-%3y6I;mYmNv7(QTDv=fE(VQ?8vEgV+-8zTT8!n#2a*Ngk0;&+Z%$`}8OZwK5sQB<^ zTY;6~IG}Fln3)kq$;7;L#lZenMIS7~*61#@xi^duleWMPeaqCZy*teLiiO`SY*aKH za_KXb&Dt>uPjD`48ES}RIh%4vcecN}+}?E$;MA|{B1AjmWI_#q6fjL+{t|p~5}=@c zA84sKTI5Y7P;N}Bt4ou{T7}k6LSI`jV(l+68X&pp$nkT|%N9$S=#PS{`m*=DT$O-;+xC&iU60idU42xl^M74+W6y( z7fH&=9T1>sACJAL?&iSShe@qAtEAl4Rg9C)ko093R1<7PJJ$ws#d)2ed-U#GCuHW{zjD`9zCN@2-({7C;X?2{JZ|4dmGj#F;Kj%8Z@iy%CE9;i?Pp zw$Ps`tjAhDtE6d9?!Pw){mi;M$Elb4@!s?~wd4t-|v-Oa3Ye zEpn7EN$&n)UCK)gtC(T^(PXtO19iNPgdMD;^00yCRPQMh|NalCbeA<-VW=BChH~hg znW1DY2)w}yhw3`};wa|C2Dow9aB{4xP!c_5L}dbNLEJoNd_l{_#cr|#^(~Qz?5S6p z%NeZw+R~)fR$50REUwlqaU$%`T>%y%KW+mVKH*P=3u6oSckldv)XUG05M4C*k`A<9 z!NUT;FJ-!OV>A{Td%+88NF`aP%$4R@e9^JMpZWWLLuriDjYz7zbj zi+%G9&cEKX_b>;90pBdFa1Z4aq~-SdlV<>7s#Ok!rp8mNVl0b$6QSSm-kaws4;E4W1HXJkB)B zpw6e8k2ZkP1WFiiv$V4_U%nZ~XX&QpON#G)4{bkMd5&(|+Ygc6!sVQKSAJ8=mj!6_QlPvjkG+Ya z(aFC50(Q6Qs>I8N-_deI*M%g@&4IM2P39KY+180$;sdTLFe{J>_c`}&H3k0-R15T$ zM&K*^oC#kDpnGx&gq+PYQ=;6O4LRs~GRT)TI62NKv}Rp2=gg8Xb6A2}R-EyiO5JGk z2(wD_`k01_%a^1W^?84Em*p%qd!BLJK-25Rh{=VB$*Y>KLbSbDT`NcZj^I z-T6QF$;dM)CQ^fN(rdQZn|i@|MBW$_hqx^GR1G<|zI=j`It9XXd0581j~$4Apr7$~ zU_;}P-N^-UiE?uEBx$Zu%-VN`z69I;cyaCVsp|c--XAk3=BoPlSJ}KD^Y7tNjF+{^ zsa$;TSp$NUNx;HvE1?S2Y&5s8d<>FaFBaS8fQ`$n5z<}`NNyY=15f#jwlGjvwC7fW z3#61d7YimnlXTn3j)KJn`6%WXSnIGuNm50rr_WjniF^E8#yjDYsMDzy8J9dM3hL9- zi7ZXCHS)}I0SC<6u&_AN^A_Wt%xX16MR25$%zJzfFf0fdLLt_@z-x3 zd;*sqaL<)E1}Y`%G!TY%b@O19(QotIs2iZ_y6ShhFVMI>GuGJh{nNizywD=#`?HY8 zy6>QT&=F{bct9UM5A>CRo1~86fU=xc&xt@_I4vL5b4!&{-(Ir^Klf>VX$a zmdIKr+d33Je=!7QY%uoN(_@G42wEqIX!h$yY!QwC6TZ1LWL*QY@q2Jst&+n)a51m1YYtmo!#H<9TRiqBu%db6qId?iv z`jV`iduA=H-i>M}csQ@5sNYU{8hfj;L$i-j7l1uPzx8Ui)RXT@ipAO1zqX^{DF@pqGprHo{&;wLWCAOf< zYynAj6-clA+<^$`)oQtmz8w2@{^L>FY_Wj)7n{(9wLyRK-P{K%c{R8!&F#dsCw91z z`chHSr2TSYD>2Ezv5W;y6B*YcD9fPjWD>DY2NI;BP7z&jr`$tCM6j8kw)SN2@nK^$oUq24(N6#Taf0Rc`oCrdu*+n^n=(EZ3pM#c#Zt;q zA%xnwElVw&5Er4N)XA;cVom^g`mqQ-SmX3oCinsyo)={|9%N7#(hk-8q<X#Q=s{?95{cStTUATpgoQD-ZaciLxq>y}g z)L)-b{wmf6J#?_xyfVdCj7*2H-cH>IYb{_JB~iSuqeF^Z)|Q@XwNO{xGaQmu8o}}4 zV9@HDp6_7rHP#5P7&I*e$QQ%Az4VwEK_rcH)y_$&@I_3(+c5=0@HpylupmUUnKybH zJ$8umIt9m8)D~LO$EVmJ1k2S_N+Vxe6-kSbw>r53C?%~XK&ob0Il2xhqW9bB_^^Hz zL8!mGFT1#Mo*Xst(%-3)%KS?nvu73-2X+4V9MGLJ(N&NIs5wuAjk33Z%j$wA%JUs1 z%H&&P>qx3x=T!H?^q zf>s7!^(!t8VCJqF+j#}~GflN72PMWiXgWYYZwk>S7qA7*tkxRH&wElF=7$R6hWX*U zj-;7~_lkW!sb$P}MEGe^mqRcq%+)BlCwl;tZMW$S1Sr z{s9gJ`p5+@*@Ds(Cq4^fK;Muu5Fh54)Y(z$QUvfxed%&Pc*_XM&S}kKfXj!rW8K>8yO?kM(Z+&%R8#tQ)4A&KV z;l~WT^BIIC}x-bf53$9Xpze4?N>t|d0-DO z_~5v}z8yOMpB*OF5AJe9LhTE}9hhdn4|PpWq0M*)^u_bs@9Bs|us|+;gHs+}jhr~h zk@-92xL=<~eh407?K;=49iGO2{B?OD_|cogHiIeKz3spK1ABo7&8j_QzI)fd{nR!> zjQx5VepD!p)6jGKEub^V5oG|R$WUr|0t?U{F)&W~MC0@M+T(3DSam&-MTa zTlOB3X9|QS2U%-KiLBF6ltBGO)`}l8@t~ zB=#gLCkMXf(GeRhw7iIjraKF5l7%;+S*qr$$UaNI41nDv+;R(o6hIczgeM5NDZA#k zxs+Gd4sxt6M^Gzg2Xbk|l~Ac5{SCz#hz#Q2)>q~y!F4nPeq{^n#!S4U7^L~&$s%C( zhYf!ou|MMW{d624iGbqIWUM6-dvCZtJQZmV?7Q4CdCO%Q>miGO|DZ_*ApTOFm zI1+c#9esnW7$7xU@X#*QVgUyZ0B^Ei3hY~Yvg28Ge_e>y%qaqgy04l+d}U~7Kv!)+ zrcl(;SD@nOm*Ca{>&>skZ3?Y|mpf9w9uRJbguyJ*4g^r5_^8N5+@C0=|M3CReRjhp z;#|NbV@SK+U88R1{F~ZDTaqQj27+*=X;P{#4pMf$fNibV&L{oTN%2*u=ybZ$o!pF){jl8B$*xn$b|t^kU@RKr>Nbt8v0^c7x9s#A9H32JYgv@kCUl~ zVOh`zR0b}tnch9A-HN`>3A(Ozt-&?GRCp9rxX!t(S~G#CmBklF8rTQ?8-(P8-*pG^ zoipT8&nElu4@CFs5gO|5huz4o4VAZ-Ja=M#wm+56%_t?3{=W1KC=+nz1`_O)Rgq3p zf<>?nAS@4)A@k;3xo4Z@A#^zb6qPRw+hAV64(dFM^rs-{u25p?;=xF1ef)mNGvXSv zLyUL`Qfi)-YpXNqEiHj_)N?FPoo=MN$j)Lv*dzHGcWeQhZP(lZ1r{=6aZbD)_>pZ$ z1&%}*xFMH6yo=BplVFI?W_fsm_D@F^`EOBvl&?b2&hSBP;eZy@wnI~s3}m}Jt*`b(6=V57A=CfjN2G4dq>_Q%qt$X%&OEw_^tWN)S`NDgDG>9)hE=sUqj;dxn+BH z9!j{|c%0V5hpnQtuJ7*xI%*4}k;J=SGJu2op;QDN5PAZIH|^(hK=DaQ0eKbkqn&4m zTHYOfJF11a-<2a(y$2A&^wWxQKbX9|_S8Vv5OS&7+BiM&#$sEl25B5-zgAuJ+8_Xs zIWU3p9x##)JOFc%#_G|~^<25o&aWjCwN^LC$w9#%j>{^5r3Q$Nd5z6o=(j1E7e1j* zUbw`{yjzzJ-qlY^Z8zyZVe`NK^qu^b4_dQt4j~0d7WY(HEWb&3Y%g$SAHPm&=_ha- zpzQ?U$rOfqWE|h6K*QO30e^{N0E8j>oI0h&8rM*bYYU_I#)MJoFkgmJ^%WHo6#~qX z{&UYP2!%Ut@|66Ly#q65ae@2Rk#6T840fO4|RM%<|AJ>IFTJf^S@=D931!9yE1TFioxCPcliudjZ zvFRO=CU+K&7MxZmR6noppN})dzK6<+dBHfXqc2G`F}idVGSA2=1O75SGyqw^^b|Q@ zwBAn-^vGPFkz3Y2Nh9Z8rAJJ|p|V@l4?&0WH=HUi(Q%yz(B0-BV0B>6(H`AdnN1_mgMCf0BX67h!^T8NMC@kiTsi|D%KT7 zeF`T}e~I8T4T0q+M&(PDA47~EzJTLHcAdc=@?RUkB>nYwzQ)`rFX45V(_;ddFw_;g z^=~j}Wa_B;#8|z%&U>A~*Aj<_}wpObI7B4nF-go4n=4ar65RHO1pi6g-Q6(_sV+NB77C_BJjIu#Z!@9<7 zL93x3n6cl;h(?yy#a38O!gjO;8Leqc*S#zZuFpumH7k9V2K}j-Ks%5&pRF?uBSIR? z+fvjl-v2}k@w{bITJ+u2g*+8nyI}v|`6*qWJJrOXTO+^o#%~u98+$s^gRXk^_WOu6 zsOOoPqA)GUSYq8XXmGv-s!C0`x1ZnfGAGh~>Oebxe0B^+Z9wuRsYKMgM=#yDG@&lqf0fSq6De4kC;JI;<}) z@$>{_t^7Wy+S|ukle^O~yErH6(~#Eo)v@{3vyRKVy`h2qifKz34e8V=v`!Qz@2-Tn zmRIe2NMmbrqnnrHnkyyQ=lWM@k>LIF5Eo;JTl%YEkKKT_>-^|uhBO555I)l}|2c&6 z_+wG!j($O=XUdA>`Py1l@VhlBaEA{?3Uw%A37Z}ff-?gp(77q<`{EsuJ{ZU34|zH* zKMF&%RRzHktvkJ!CEH^W1jse8)1TCfH4D@Ve z*NqWvgq7)@f#%@Q0uysd@4@i%f0qXoBX%jwjPopeDOqZ(p3ur@J(b@%33EtcQ}$Is zdL0PSrT4?waBBK3-3*ap75l}6hM8xEq%rA6C28}=(dm+6fL(LzY7D#NpHR{^v^3Ln*x|99VL_6QzDl$6{ z&|_L}ObyxP68Eo=pJ#zaN&_L#(-E?*sP&;Spg)P*l9*wwa{)W0F{J;xzKuwgbyH+k zqRd_5|HcEA6*VMsq>5}OHMz{Gyh4QuYvyeW_uHZ4%fYmsc~cDFSF&b7CKEE*m;#kq zxrkfTFUD^5-4f)Ic4Us&4=F~V%+7(h2D$b`@I)v8e0I$)N4O9k52$$J02arQP9xa z{qt_c^ghuvm(X&<*ibB@`VjdHnzE}J`4(?O;~do4%YHZAQTZelsdtefZyd_6Uu^G^ z*UkrCWp6*m%o&jY7dk@yl2fi6cvkH$2qvs5bBytPi=@n|E%!xGUbvdTBJS#J@g38RCTLds&_6U1 z-&)TKhjLt^d37vOtV>8D{f-`VheQ<|@O1Oh`JvANuWLv4Cma-K-@jv_9yLJ@ICw;j zzEmvrY`CzUI;eOb&dmOzRYV$w=(Up#3Vc@2M)H}e>+q= zlT}M29XZL1usju?ItTckx<9k1htb$p0pKX*_5vv_RZ45r_)OydTO6X28+D+odJW8X zerW}#Qo{EStsUqfZY}A$nPgcNc{e zsNA0-4OW*$y@!WyjNo>nkfO@xpn1uFx%G>O8_eOG6@NPsQU;e3!PqStF{N8jv!Cm} z3?kGVz>G-dVVSco^oZm;lN%!thsX z&koA1hq_R)7-2!b@}XtSN2dpxJGbX{JKc2%Tgp)_d;4L!Ht%!5Dd8{m;ldi=+VHX> zY1&|Mv>5tBk=j-Wu(0TgAz7;k{Gj^C0n$J%p4xwq zS$~viwFz-+Qk`Wcw4cy$iSP}ejt8iM>4uw2&-M=p@i#%zm*E1(Wuv0jQE$N?A4?9Fiw02)7}s1Bp1+yf(F!< z03xy(2dr?X354w&Tzv+Bk(92{X+N}xOIBw7UaY-Z@mSbJpp~P%K0##?KI{(N_<*{x z!p+k=@_bP1UxE(gua@R-r?B>nxApB6h-NQ1&kEWQUqGW>9#bE=P=!d!0D3EPf>P%b zf=<9$u5~~8gJ#EcT9X86;<1hcA~E~_fn9-yJ>(o)8vG7z+PFX08-K@T0M_~l+piY2 zPf!G2uz=?1-kqwH?Z1V-3OY=~mcdU>=a5Ze0DY}hdS!-&*hE|J_MB5eBQ2I|L-3i zrGp<0$G^_nR+?~}zyf-U%t#w5Cn;qhU@sg`14IpwW7ge)6yjH$^t1lu*UHlX?C6m| zKOnT-NPo+y1UFnc7~WX~Z?OcNEF2)RC^$C@0xU2LC$fJF_*S?szj z`9R%(=wTxqq<5mw;Q?Y_9zeh&Aal%tqM^EC+>)RR33NZm)YbvT%C#K0x(4X?B*K$I zX`%-AD-}Wm)a)0NA>7tTd<5~K!4~X4?!v*nGl#Z7I=eFlV!(f(Vr*K0!TPG-&E3{Q zks*lPu$=mpLGpjsc=rZW`6e zDQKE`@%nWXNDd{)JK!iVP3*-eRNYc0{Clk{P zO4D*arOR4aM<9MZjCg}1yq=PKa=>E&XG#hzFG-8?RglhgsRP&CpYbnpVac=d7@}D? zq}vkFd^%~RB&E|M%_s%dO+*r>?gFwR+i`GS(Q1PWnf;mG8&QZMBTk)AC*BA2kIys< z&a|0E3yoapEBdc+t>tL_st<5nf%|x=N)K%4{|krt`(NoYx3y$nR)8Uv?wj`@q11Hi z@fVr%9+0B*c7s9ewj5*CJZX5YGH?5l!5qF>Xy{Ggtl6zCsj|}$*z9@s!>jbm8?ca7 zQPOySEIRjF!2Q2R4=YXcpTe&QfRL?=gS6HZWDC!hhClH`n1iCGLf-lB%iJupdZR}(f?}Dz#Wb{J6+LmuQFp~1k5~LOk>W( zR3pAccfT_?6`0v-u5PHd$G^tj^fAsn{4WWOF7`iRla+*m4xrzNRRGX}t!v>Wz;l%g zK@~oOfP$!?QW&ob6?1VsxAhA)xefe)htV%UvV;REc`v;-J@LHoJseq+J$v_&smMQ_ zh0^(rt9e4}OHh8dmXK1O`}^Ge;XqcOc%Fk@es)Ya1w?^J{8pTtgsNN(xMZSiz;evG z3xRpA^{|0;6o>IGg_kVLQb5@agKUf~M^$C!pblKiqAjKMJ{6;T^#BYh9NK**^a`uY zZqX~Tk<~`caU^9I*JaKE4hutt)NZf-rNX4)V8^CVRl&vo9wHFb{EIU!`1GH^L=O;R zsh~wI&liu1YsnEuYQhd6Lna!emZ4&N{`iO_E1V4C1e1dhB4L)q2%26C-DN;s=TmNM z$IySdmcD3c6p_dW&qIi{bu2>2CP_I#{`jHWa7K~w9}pW`i~}=ta>Q2z|G4>;%=x!2j$$s9fFOBO@86~fqTZ0e z@FwDff(&NbDp6zt(-h)03Da&!zA75U5N*J`)q_gFA+2(XQ5PU-6TVu2T29kyl<`^M zWM`fRsERy3!+*)FdCf^WUEmczs`o+f|;3cGQmv-Im+keS@wdo)|NxrS&J8)g*4m>PG0+p9uIQs^AWejH~ z-M?MY0^|@RCd7R8T86`o=slJY4S@{!c?8(PB;s)UdYGVlcZ7^Yot*@qhkQ&4x@*9`|}^h4RI*w;&tH-|K96*-dCIgh!yCJ+K)dtpzQsR8*&)+YG(S&>Ro&3-B5J4&_l1J)O#!E?=kb5#e3B|@jW zk?{o(E;ru|QmmV6&oca2?;9#$J8@eWadt5nM24q)AHE=l?-K!a(dWsKShBh}KD-nY zc=hU2M&*4@`iFMD)2z=yfKF8fOCHPvPRZHsh5m1Uh0hg^+8`dgjYr9e^Y;^V%1RM_ z5Ep1`9U(6EQw$O(9x}Zab0Z+da^S-XH|St^4p7>|d+6Fr_R8-)jJ}va7R~a6ZK-=k z+EPQcY+9Astj81&yl_AK#Md4#|iX7>b>}Xo6~RXUlqH$xOuL!mexMfzYDik zzyE^O%OfXdrrowWMRzR%4~IvrD5Er}jv?b+hy>-xgP4D9pP+ME7DallLmZd)`=doJ za}#?huoE-zXqzC;hgLX53g2x}N#ziCarf`8=MUAtlq__eKPD7AE@JJar1f2oL)Ym> zxl7)U2-xycQ80O4D(c;+NBS1fqoWp&X+sdYD?(xWQwH!qCx83f`hN_x{rMY}H-Yb< z`l?p?u>;ekh35YHRFRrx*wMfK zzH{hy8fY<@@WEME{;t9~{z9r!550@OKD0arQGiUw4p#jx7_li(!8X*?evtU*-2ob` zMp?!0)R-2?Ih-%IJa{Ns?bgi1A?#fS`|_gcvbm*#JOXCCdkw)XSeZyR`&g1~|Ib7IFNKG8`qOlk#6#bT9kQSW zsR=jyHQg4w873(46Qz=pib^5rC)n$_r+r#E=)BM%USyFTGtt~W&0yZgWA#k9uxGO; zXod9ZsW?HLy>%#|gIPVzhhI~WxBku&Mat~{4cuJWhpUE81m8J6h|d zee&pa9N6q|vah6wt+{l1EVBG7CSh&RH!PreYi#Lk>M8Yo!?BS!U1XC-hA*sUjT-2E z7x&xLl#_uYo$XxbnUe&)bQ>8$Q4V^54?U5#LBS z@9oS^BgT`?iQy}HBFp8xNdsb&X1ye%v0=If8ghA zquP>rrU0vF!}cFtwHc0WIZx*=`fv(Shs#O$R3ychOqSARO$PSx3Da8?kq9!hoo3wK zeZZq*F)mgE)#BKCoIKn?eb#& zmT*9e)o}gV^u|eZosJ5#o@CcAxepk)X7i#~kDQ&QBm5kkwRtY0skRn{s@< z_i0;)d0)|wMuLHE3r9Qkp6Kg3$32=|5VX!B2rdK@a199udJL5$n6vG_WI3~aoOd*5 zT5+jGrZ_16!yDmMHac-%)knW0_nfI0tRTcfEXEV69j*-1qAIPg{-|Myii0yHiN7t7G)RY|D zpJtsDa7lcaBHbyT2HH${Pg{!V{+hDlCxxWS(S1dsZzQ(psvGX?4cC5gOlnzsWVoA@ z>R=b8r0p(}t{L%?$Y2}6@rWPC<~K>YWOZ>Wj6{|WbU!Y#jUC?9tW9h69Vy&g4(fUT zJgkAmvyY-WfSzbpPv{FGaQqq2ILxrO4tXcr5@Lh2Lu$|ekATP;>MZaqdTu-h3u<*i zM{9sH`g|2E?GGphv?VeS%__xa-YY;x8WBhv=qKH;d#0M+d5ylt9H)^}_8Fw%c!Snt z#kF07xrux9XOuo=H6a5di0|7SA*?;R98FG%FrKzxj8^pS?<&FhN_)Xt=0R^BLdDbb zf^Y9|@^p>7VSDT6raEfuh!Td)T}P5TOwS}f3fpw-vm+53c#!+{TxPi818+j9#U@H6hRQE*TycG-G5 zYj!ZK;iGYJLzVRX5_j}^UL?ha$o>T};mt?_u2*Mk*d>?EY0y!TcoL$HZQaYY@dUmCj5QD>eQ_ZJ&_G$f z^$IDLVesZ0Q86utogX!bfOQR;`-xUnog5gwS_{nunN}mxOn?b)=2e16wb6wQexF3QQuoaaxOLYf1K6U2JlK0S+@Vq>6a8tlGHhuJ4P> zji1o=K^M>9A`4I44xbNBbr;iMzJ128;gvx3DN*0y2O_u`5!vf~^IV1Dgp$RNLnZ@m zC5uIWwFB(`zt7ZOzyt=E-;Rf><$orc1(v2B@t?J$0;-1x=GiV)Fm_>>MLTp-RtYLk zbtW%wz_2Y09MuA3bL>kYJQOQbEYlb7BTTgEN{h@UXt!Q zG!d&87MWkL0~wtU8eV`&m6Nq^s0qc@jb2YqE6oIOyaNOscM(eF^nKNUiKZy6&ZXLh zo*+4pq~|axXHB}+o?JcKG+YPB_)zXUm7D7hn}wfyY$lK?+3s1Tl-o_uMCPvJ@75qd zph?cbNCL=Fh3#^tUK&Z_Z{Tn0!>FY#UOBY`@!5?l(^+`m4NB>|Amy}}4>;zwtS$K6 zeUD}`uX>)QtUaw30p5yTCm|m3p@iM5c?Aj^B{5|;q9xrfOS0^0nKjlpQ`l>5UPW(1 z6+N%eWP7l?vTvXRKrmATejFb$ztHVg=--+o3p~suh?H#S*WIlBG2&+m^K3+f#8L?W z*9u+kCcr$!?MsK;G)P={KzwGHeR9}+p?QeXeDN{f32zrlD9s}XeOg;vl%E#GB`_y% zsXnSOE-Ra!F79)4>Xh$|d@1(6^Q!6e20pE-1p8+0W!}19*qT&MZ>Lk5weQp_RnIu5 zx$xFvkMiZxOhVF-DQCF4qqxJk^H2$&V`o#ha<_&~&aBHx^K-Gco}ZJA=(`v>ajcS5 zkb6(b8h6JT_h*R$Vq7-Th5URDAER9-2GuI9+CMtU#eT9htoP`<*S6R(VX8QsDmG2M zn5%{|EEv(y?aJEZvza!Z)9%Pyw|=@95SgT}8|I%U+$`!O!!c6uvFO8Q!;7I)XFLyR zdtPqTBCpb489x=%9?_HTT5nVK$u4|2*{Bfb*vJ;{rK$I>;rW(*XJbjclT0Mrs)*E* zT7TVsDGArT4_}vHXI#?mHM*oZv6Zn;R(3YdxE15u!sZ+E#e$Mz9Ju@Lo&MAiwUiu} zEI#|}@;H8B$?Xk+yLP5TUK5+|`f{hrQ3b zIV`@_4mK~Yd53I*`nF8gieykUcw4W1NA7~P*NiGv&*ItykK2lG4vZ1LVPKZGcSWYm zZy@aX1gN!ax*eCPbyjLI!dnElEkx5qI8|Nh26|9rsI3(gkU8I0gcxkjzf9BzB57(F z8D7$q1zW#IZ%r*DD`7C6!Fo74(8zic5w3J1-a?m~a&Ff%zM~dbKO3| zW8lTfYaP(vug&Q3AKmN@Ff{NW#|RF4P;!4l@jI411zSM8v)h%8fN@=J`kaWUJ3_ce z{x_-rO44UZWh!yY!A)6hge^;!F)cdD4Z^j{g$|(|u)@%B?1egEn84KHL{oH87STzv zGEb%zJtS1Gyz2?7bIqp_BTd|FUpv^jmDv*+&of6qlz8+WX|L| zk82u~oo`c?FVnET>M`r_$a3RS-+hm|p^&h%pT6XL=k^;BQKG%*D3fyoMebZcsNqQ= z=MPOD*XVQtB-uvhi)DC!T~UjZMlLV9L#c{1;;cK1taOZM! z%bmIzSB|Wj@;vdPI9W{L74>=QT~3egU*nfGyNO1a6%;u4Mmko`J?Y`86IDg6O?z3H zdA@O@;~q1#FstW#=gT3`Iyt(&X>5X zq@Jh>&l8Kc(QIl^Z{=0_7Am{qYZq=^(l3QH6f8qNQv?1zf+MT!oP7=JdG37}}4w&JXnlWOe6z)x&*bn^xEmV(TKcmz%yFVxMMx zGv9nkv1F0wMmiPIthK%x^Y6kJ9mPQ+CCR$^%LXJofQ9vO*?k$M%OXclJPu7$N#$~x zO;&eYn+om4-$>Momx zm%(J-R2I6HopW`=62?n^sQq&@YCzNd)^oaXF4yO8=j$@RxuAb}1XwpKuAM8m_ zC#IAC>e)bd_2yL!B4fi|jY_p8e}T8wF46ROGo^!SAX_g$MvRArG*d6yPJGjB?!UTT zhOL;daHIB&KgHCB3e?JfG|eyS{(^&sz#`vLn7Fs!k<|p6;0)dT+;?6Ki+K?`71;cW zIYe?9`Fgkn=I^F-Ux-|^wY+3W+@JI!@7&N$`>n>-M=RLP>-9xqG8Ne6>YhU_1h)38 zs^+e~Z+J2mTbEnkvM$S->#SW{dTqk1#(F?oPS?X@D?j?9B)k2`DEA9$f)$|-Id;xX zUVHl6PG3KKX#chT+#}&_Uxg!O$?H!SniLLD__u};zW#+*>QqXwgIYiT>cLkQ?kOQ* zJWic{l$AM!L=6f(OVMnM+ObXzuA`^axH%2^vz&Qng^mZ z$2hOH^@dUyDzCgsvJt-c#BM!rcwJ{j=nJjtv1Jo=sq(5C5Q*+$J1 zU_JC(boCkM0IEBO#x$4wC;BL^P8dm29dDqvh?9$)l9fd*tcy(rgme8IO-LUnYC>y@ zzYB>Y)l#B+%t=S^b@h4_s-XHNv6s!YsiB1ETG``t%(6DD?%+<}1amd5_rv(iRv{=C zqmIFN?B>{%=u!FAi_gS2?Z;aZ1B@~1x+R#$Yh?}5IVKx6EiKDxhT(($g$8Z(-_BfV zD@;1iES3jrt~-t5!x_%%9NvSeSOcD(yD`o>#WBGYan=M3pSU~f5r16AM=;EOv8JU- zm*ZKv=EJm~w0~9OE})ZBjHA2v2qqVpqv*w~hNO+5JOdBD%|6l-3-6mj18V{eza60g zs0)vduN?$LEGV)iU>%vXRHlPS2|_^w$E19FBJaZY2D}rvCTjW$_ZjuArKaz(+?bl5 zR+t#vL1cRyV#aEV5)@8CaTi!G4>>|Ik{r<^WIR>&?mJlX(#o?^Q4x| zYEy_Q&x-&RuVcO$6~u{2~d!g4HWmRS8^~DHf)84$|Ae|qH#%Ik@H^s$y)57^nQVCK@6a&uLrk;JS z?kNLJC9kELgnS=71NRqCrpw|Ng;>hk3UY1U=GARIX*UClNYGik)<2um#;mI8-WEu> zx$xe%US!=WVKQvMbm0E<#;$2Cl&|udGnQ~GbuyZwioUJq=&H2B#V*rgqcw-=!f9nn zJhinA%d?pYo2{$9n1Qh@#X*kgSoQB1Gp*so=jxH1ZUpTll5h?h>R!X1yCkbeoWFH` z92flf*3^3TnFJTF34XI=*6s0-k*mVq{szajmytddX5FW3ii4QVUOWj|X)|;edgDu3 zwdnA!!KO@Pnrob;%=J{;oOWMy!#nk!@w~{@8O^MUWzmFQ9j4-enOcn=cd<2PhzB{( z)D@eiBQF=@ReNj~tj0*&SHqLsxAIDisI2g+_;#M8*SH2r7rx?Y8N8uQeicc-=WOu7 zo@@5@v3Xlff*+$IJtf{YB+oqf{CH7qZn&{waHEIM+O-L0VCZ#^{*(FsBB|NvfBjO# zU8~z}`KC2WZ5;pdCL4_^ZFtg)m}o{Bilgg1dhb5Q@)%DS3^N0~)^5Uleq*wx=dUr%cGJ29(}BM)#4! zJH=3_A5ZRml*9b#7E9xqRjrq2X;cYhN%YCl=QOGBLrGTmbex4GW_2TuRgR4@-&kEB zswICZp5a7AnNEdnlB++LcJXcBp)(kY?%oClirKS~kpFQ%?DdPt6(w7=tBh!y^!{cBE6p|#X? zF#5J}$y;+X9w{f!;dr+uH<*-+%LGP$BllAMbLRZUjreFU`h~_z(b1$_EsX9yxv{2k zw<-u4y6~Ia>i$30-a0JGwfi1dLPBB)5s(-{8UYbOIt39Bq`L$J5u^uDkRGK4#Q>B} z1w~3qLQuL}x*L(M@1Aqcd*Xf1=XcH@zw5&5Ld2PQp69;zz4zK{uk}*sF3bRU8VK~m zRAU8DH%omIYlP|w-@R1rlOy%%cwGc)WCR8(>fEx>c;2=-+vsfsgyrBfmpSf*agQTE zzaDKcynI1Kv#XkrHd!iYoOa^qa_h!3%_wT(t7nk&+`9pXxN@uK%FU%dcd>UZ+uqk_ zI7~J^w4Xg%IPRm*vQEZ2i(A~0od1=Sg0gdX>TZhiEv6ub+H$_hGrieFkgZ0&%B5sQ zL^?Red)WJo#WYH$ES_~ekQ#X`YFcG9YuuGmp<8k=7oItjRl|Ko$UG0M1Gi{S?)+}rk-rnHbLW^6`3+v~Mf(~`X(loU6cIPk1W1vyC$F5o!&uFfnK zl-cz0_?eEd^lx%1oI&Rd{2WZG?V=|m`NX%;x<2)M!)W4)3c;@F;@u3L+hRv=Bt5zd z{TK|;r;`t-e?pR3y%s=0T=BqYx`NVRUtynd{QI^K2gCN7{7;z#?+TYkVmdvi`({m5 zeJ7K)0UGI^w3U;SYLH_Fdhd$NvEbFR)y0Io)-n#|osA^}N5)O^B}KM9V>0(hF$Rgu zpC7hwmevnF`*cq!W2wV!Z|N-jZj;Fujur>KYtTroV}Izt}zLaG57ycb25#s{?JDwALD^`syZL*$J#1?&u8N8GjH2o z%fC&^%n5#&Q6^<(6{%(qBYKZ9%qp&JdeIL!0!7FXrW17z`@=2T4ThPRgh^uf3(^)`9T zv`{zZDb!RQ%R$(w6GU}qRJh(~X|$}JCXc@(GM72Yn}bI_p?pcY*V#Zaft)z6v(%<` zU$;M_ozK8^O0L{nMkrdFyzurL&+%p3a^!5v=E{$);;YyuoJw!D7hmG;7js}a6%r+# zxMHBSuT?m%-L1I4E6^0^OEToWab|GY?%K8u|K1BK;;6$(0!Q5{;}l+6dAVlq@_mVp z+A~L&Q&xl41v3YKZa5F0LnR(ssPuV?kq9rF#QK%^8y?H}-||CsGk2gMw#?s8XBADq zw-fJxOw4?WzQ;JMA-s7*iffj3Q6@2Zq(Vo)`JSE7ghAVg@0*+w>~+41!^MIgz8La@ z#I;#=FUF<2wa53>e(r+`STw_5`f12J*iH|2a|}!fiGEIhs9bw@bGrBw3(%{wX$tLM z&?X)f&NVr`JxhY!`_A|du+)ibaC)LNDVDNg0U9k$&p)KK>oBm-!gT7+q&1sftyU4q z?>M`eO`PFv0b*h+I0x1a+5wuXRoM_3S<DD(d=;TQI6#H%A5sgz{h;%r2Oo5BlWuBI+|A9Wp1q)Gj{5(0w|w zM~=b^C3{|9b!m6xqE{9xp@UE!f2-n<#@lNWT5rg8?;Q4BQP^;VglPfW_(76l=*!e9 zzJ^WTid|#orp!CIxb8ljUuUDM9CjqWL(s)$_-2rU?mfY{_*^437n;n>Rrk$t23?1>h|P_78Yp%`q}qP!kG6PEAD5U6lO2mf9=u*t zvg!`m#PZth92!y0O`9tIYB!={`y>aM?lzQBN3D@p=JhmKuyfeV6crl>n@STAm)1Y7 zwbhw9o>Q#nQARQZ)Uf{1QX!|n3>ek~61;ol^6iUI&iaQ0MNe}RwJa*BUA(CyDvWm?`$m(8JqT21{;t+%Gu1> z9iM65^h`2q2wXr!-l-8yXbGwP@^a+yxFlNhyV@nhjc%TMK0}%@Lo6;e zDXx(Us`iW5ou!&PDk*Pq+IPfF6FS$nG}-x-%tb#PPa5MA=Nri1^VA-#{-*rN+-SI{ z=H$&}S|_K)<;F`1+Id*dZ@+%D7ea#f6_?l&RvIy0TL)W3thuHXiw{@#pJMdy_gvtve7(_ZR_gt(QA1ON$%^t%5K!-%ZhDfE}$JG@hSA3tl zjKC_(=^;2yVm>bKVGdETo1Z4m*f7&EKQ$p#ad>uW`;9Nd(f&IaG{f@Te0n6`x~Vbt zc5H~x?xZyD$;`}YT#2s~x-~-_b2j&e-8EmNkG6Tu$tv{e&gw^zAH4{@Ouy;~+H!GY ze~42fDKKJFrUllj>erPEKb^U7HDE>y%W3odE(`{hEJo$BIiP&M*^Td>)e^$i#%|7w z&Uhp1_o-L47ozd%SO;rd6zrpYUo6g%2_O=j#3LHa? z8N!blp+xnIZt%+Z`6?kq&|5oORt?4pAXOIuccC<;+c~>5K64o6&a370B)op|R~(R& z)SVv8DA*IweLL?OYB!Z_?NIa-c-Eh+SKPu67SmifTBYy*DpKd9_@)A^T>2Ki)p(5pQvrFv8}e}fcGw~>Ow^8LyEc;c)`ukRF2 z3Q2EjWS*v!$JyO&czO?M(!SB*UaQK)o>P6!gQ!fD*J$x$xQ9e{xr>qhqUujZ+DH3W zNc&{fe&$zKRovb2Ls2+NNwDl2EWD74ntVsa;H5azK(EWy)pgM{UF|B$o_5yg;{*qb+<^n#g`Ha7*1($HcA_L z^rwvYm^2N<4Vh0derG)Eoi{o-5z2$0pIT4nt<#yF&hW*i;Zf6_LvU_QSbncqBG9=u{4*pDqxSM( zOMj2s>kdXopo0AE0U$0VAtaRk4MK76LY}&|kP8VU-Y%P0A?-t$!YJ#Z?^Y|$NP70+ zsxyQ|#^-5^gr#aR8cImPyPqdCZ1M79WUdabvWm2$KrWq-YXPew{alN9UHt(j^s3ewPgdh{>4ZHFHlM^?_XH*n zI!AWBjiQG{0+h+Rxz?vA-kTK2;5vzY6s~+WuDxhwPDk2USn)9+On6B<4%M|}iDpF~ zr@F7n?rq*ne(4bzM<0x=RR3NO(6u^*tR=&dn9*C6@y^|_UZDLV^1}yS(1%Ry-X>B@ z$|t&df7rD#zo`y^h3Jk{daBqP=teqdc|j`c-E>Mof4>moeVh43T&DtESMtxL)e;p= ztOlCmhR1Ig7QbUTU$T7ekIHR}O)2~;64&FubNdU>Qkxx#oO9*a13fx7tO}71Qe_=Z zIDOu^*1nErLo$-9=Lsj?Ke6&5N1pu8m)|Y&uj}wS_ka(TCb65Ju>8myETfcQGEzJg zOlM!4RlEn`JbC5Vhm6Ws_d()gI$DvzsU}};?%}rAi;E^KH>`$x9Uu9ZFusV7BOw(r z5-T!qHjt;t$571?_-y%aEL(0OiV2((acbBRs)*4tk35nl`|=2~2RO_*0{BCaxAugt zsOgvoszmn54X>C{eZ-EqlFpy8<-*tN3}eg=67r8K=tVPH62x>tU!1MLrmaYK-cvr# zPw@w=4IV&FWz#p!+57!Pg1>O+f4KF=7!#HEM53PscV7-1JU>Qe$L03Q~NcS3Z_q;k||HKi+6Z!hV91eFM=Mb2{+~F4zsEEoxf2? z$Y6Ur@L20`fLY752W`?k=n4#iq?Z&Dr*iZp&gD?gjxaPmBAke#AMV6Xr7*l->tiqH z<9%Q$EGXvK?rC_xLeuyT@np$}y~g?8J5-a+dDruDU!N7!Y18ZrC7542GdM)&NZkHV`_;%{opkzg}sHhsa!d))ze9#(0xMVbszO+n@lP1=Xj{PTEP)Ly=^n8 zLPm-wqc=V_NaAJRPiN84!Jn8B5jfO7e5wB+(ViCV6ls)lZfSu4uAicJ1+ z9Hoc<`9cD5UrFXZjL39W`5u=%AFx!lP|-%MSC5%rHm|{HyLgvR{FYw6nN0e9-z>%x z_yOVd9@I4{miE2Cn_fc^(vusz&1|d(+t!OB1}u*p78uU3MHX0%fzg*w;@5%?Wp zp_Rp!)*CXz=}xyssC*{QVA)5$l~>?Fy?ep`sW|)8q04>RO+m(MQGq#fgz37lOh@B z_+K9x6*y+PtcULfd{1wcs&n8AFvA(g4_5Ep+4#U8fj8}->l>M7>T5F6XR=SiefN{7 z8XX=H(-PU^fu?6U;)h)u+FCTjlRQIxdgcBlhdeU$r?T%{*s89&*eBWReJ_9ut51^X zdxv+97adb-OuX;ht$;bjxS&aR}(Zx$rqUs`+yKlM@6{zkf;R;y9-w z8K#iS!8#~zn(?8LEf~lVmCvxfq}bmN!bk)9KgH#VQO|0}w5@3~++_EvAipQ9#|@Gp zVg!G&ZW#G|aQA?MaALjSdLgf{eLoU^z_B?($E*{1U*<%>xTwEkDev=F_g6S^orK9Q z#7LLm_~TE2`b8&0gNe8M>4~DVZ{tD)8}o4;d03`Apa~+7(_+Gyhg^}o;MysJ_dfSB z{=iVtK&5{59d!`*;e@Gol>|}kL~x-{IR_}!jdq!nOr`5aEhM43h~n4FB3F&D9|dQ> zmh!E{DDBc><2bm^oVExdWpq!bdpMb^U%=`(5+?I1j@OW_q$peiAPK~0@@TWTz4=Du7B6L(%W9up?-amRjRf`If5`P2v+bGk@#8&h9|*^P_b zPs9tqSk(2do#T7(jQm4=dZ@mM$&xw#goxHFxztwt_hyea89u(Y?I(SX`a=J{_C~`{ z^hry1%LAK!&xM!e-`paDoJa>pYUl6+Nn{)fSWcK3yAw|AT=X7Zh+6ZXVEmTO<+Bs; zJvoASva-SAk+|l;Rt%hdRNB#rI8M;9GaXRx3vL}~JEANwt z2NvB0Qrc%hLW~k1Mu#AN^SLL;{Z7FskZUKuwFvE4EkEIexw=ZiMgCK3AOh?bw3b53 z@cOFy4$zx7sVl9+h9Eb*2C`Dv+9On|?N?ZMd3oF2o8_@s5n&GvMXshk0YU#;gZ*1` zg}R?`olpXxY84}TI=Jt%$aqnlNSz`|wf5Cn%pCGzW#{Sn;~GSrMyx~x3ecEM@BG^u zs~XH5pyursrdw+KdMPnP?*PCTLtSitUQwj6&+asq zBitCtk38);+x#M>N_XvO4Kt+G1PsTwx&ag;j54+LuN=wkhe0L26tqs_zav#1fL=OI zhey~Si))<&7T1N-lMP$C;d_czQHPPXg$9L+1k9VUh$rux>Z0$GWD|(WNs! zwll;aUX`S&vYz!priA5+@nQ1=_rR{;kmR@^CM3Ia%S2ocMQ`cakDKz;cf#h0YlYD7 zy972N&^5%~@lI2u#qOUXy|W9XTan|=Pz`zA@;+i(>dltsP$6F` zOLi^Zf_S0!;z29vkLrn1yk(M0bK*{sdj%C$+nLVQb>f=pkva=)mzU03hNNKonf8?k z_v{^~nL6UT5c4?=4bQSCdfzMNLL`WXmDZ*+-sD~j6G&Y6diI+ArRh4cgsd&MVA0l? z2ZYa4dLvbACiH-6h z;dk!J?0HRnQuOV z_zEu2>7q#JMU?;rEc9UT%96$ROB$zU>bRTqd23F{>P_(-R*c3a@~16AFuW~V_7fgw zi093K&tT+&u?$eNLOO$rk1~Rb-l7%8tPS48uX9TgQu* zE3c#OojJtPpi6j*NSgwIoHOz~?}HTbB6Q#sU9+!(fvg0?N@f$V!7o6sI|g2^2@pjq zm~#`Q+=T;wv#kA&k;6W!z>=X&-SyJv{^hwbolNzQ*1NemR^|R8c4&baCjWB*isGUR zOdoH7haxVPaBC9~1Nnfl-pwpjXD3x#=<(%@t_c0%m?w!J-Ka#m+!(Z^S7-zpzK>&% zUi=!m$e`i8gw%a{;yvoE(S5-^oMstI+vNeOh%&>>n9>1dnof& z(v<$rc_9e}RbSmMMs3k@GvQ26>K|s}ODR91)Os!Lt1{(No+?sp`l2;6vP#MA_Fi#e z*Nl;G7VEXt`akYkI}yarL3D!vl@Zr|UGb>ea4655@ydtmh=$6HY_G{SYVj}UGJ`tp z9!H!q>=AWU+7Xv%+vKVU+JgfdXG%U#-*8Tzo=H|mQxpHHNHL-=-1AYqHGMh+U(Plv zN$zZU4<+XqKANsa3(uwAN1WS6Jg3z0UF;dPv7@gurWO?!pJtK|I**=gbQ%qzZcQpu z=F3X2%KkKFa+LS7X2|tncGJ2YZHq+(o>SgX0{a?WiTZL?$=*=L)1~dzws>bsPlA8RD~7mh zzvrePV;3X+?rhyjMh0ye9J^v+%A%lRzH%Q+flJnw_t%kEWyJB*;-BKldO%ggtV5fO zUB5wWM_Cu}#6prB9SJL+E^UaR&)U&JhHf4PSD#>b-ek$DCfh$F#8waorMx^cbkjb- z^ciINE-&Y_+GKKdHeZXf?pP<>tD%%uX4%VT_CC}c3x_Z?YZtkMY&em(tmH4!C|$Cl zM5Y8L?M@A$!y~g${d|1xkTI}TgG!jl~A_Ae%39HLbba|O@?kH zW$pRpiHNe5m1(WBb-vnXe6$ln-Buo#JtMn2MzU!m&SRXjY4O}&gz&zCQ@sR1z?_jz z+xcV0z!IA?6fA332U%*GYwz^kEgCzsNe>Wal6qp<3OG9`xCbT3P8HZ(ZygII&Cq zfOJq!pk#ZoI6gh%bTl$7hzXsNySuO}aOsf7qVaNoWNaROQ%? zSxG&jRpRTFo^yJ~d)XINLWHUuX=A=$M<{ABiJa=6IYZoJ(&qV}D)^Uj7(d{%05_VH z_L35eWT(^YhBG-}2WAM@y9UQS9YUH(ZFXxWPGg9Pb5{QO3e5qjb*r{OMXLoNgFX56P_Kmw?tHU2{HDhAU?LuSL&|8bQyFgQ+VMzRm zbgAR0q~ES_K^7MbJsrO z@lHsD=uN;)+r-_OD?P48&}CJ5w~t#M`zU2867|v7pWXhDc0Fz(YIp5wF>xPG{k@Rq z4$0@_p=4&d15+kQ3>n?nsBRZX-a2axK`=M1Y}ezTXL?mmLZF$LM~VGpfQsTWsLPjiG{wR`c)#AdD59!q^-kS)ap{cRk<}L>i=fv7 z{yTzPt64rY4?36go7t{M3Dl{Ys5nWES?z@;+-|AOp`oXKnJtxf8|SOt>90P_$=a#2 z_SAhmI9I!IlU`LU(Yg_hO;&8pQJK@Vb#%(>WZ}BTKV+hls{hc&wJ*1fZ!&@ZeZ|Tq z`;$@5(HPT;mHRC`RPm(Oy&>ACX5xD1vOav07m*ZKXeX#$l?>eGt|_YZ7RfB3YLnQB z8Ei9Lh)20mWoGw&Pmd^!ed$HBg||-Dm)p11e=2^>NS1p3_Om$&G@67(%Xle&pr2hl z%TasZG(DY7*59-NZ|X)jfBKcgo}34SvJWn3ZdOYmIGuyNHww8Gr{9R)=$m=Qw+bs^M!U{*4Z~T!1Ll%L&*9?_UqDk0f*wqQZC9gx3 zl?o!!PC`ZvWxm_)ly%?bBi>q}%|S!5%iIz8Tj#b5ugVDj=i*^ zpjaR~>g1{p@fycCYvJ8%LcG~W7KIgd*eFltT>eJcl3QWk=dP9Owd~D`_3e@||j77&0-{al2f5T7F^JOnH;M zPJpr-Pzmb~_;l(R%LA*?_pK3EJ-Tmv_F#k7pi%!D&0j-q z^a?So^7F zH)GAyyqmt%O+$J%g_Tb6ScRM{Pcs~34nX%e8dUshvwnc{Un+=Mw_ddQ122Q*1o;Ao z1I-@efN!OVAU$bufy3V)bwT8txcsj-CzeTCM%+pbms|F?=L?Ste8t!kFbWZl%`U(%~Pc6lH?C8G{*0wN&rW*CvjO=sY(> zNIhvh{&N|^8YKZ2Vne$9*?SqRd%^KS)2=&{33{^k#+IK8c#u5@Iea3}(PDIk;xZM} zLOFdR5}xQU3EGD!SRy=uEymHmB0JI~=hup}w|zFZU+r-xA3e^l8ootY=h8JW^ZpO` zM|yz*E@^KTEyVge(tVO#i3y9cPIK;7KG*Lbj}!BBl@qCS9{+JeoOw?YPLytSZ+!l9 ziujjD^QY7i^YgKOHfdP6l2ziOe_7st!0dne6u#th^Z$cnyrTmk-TIKG$u`2v)zuo_a4 zK4YIxz5pbu79$FC6P)a91{`Pds*aw3V-sfNkpnXpY(Mz%nzsVTaOltqJMaL1HxAyU z)nxlh7uYm$h8rb5&Aom&D!H-#>k<;KZr1WU54!ZLh?~VfrD44CL zKT+d@%qJiGN2&_k*6ZNuX3@W=1cS)ijlk)hve$+5hEppus(|jUHHfQyaGk#i-GE0U z?|`c1UzMy7dUfbh*B)jnt+T-9M#2av9$mYBy(uwm`9@K)6LsFtu(4Qi^I<6dqGX!-Tb1Q-?K@ zNG)DOBP4pH%C{=!!NJb@O|YTB+;I@{hy^@K4MveBUQB}|>r+FA(l0Ivrp&lbQWsT7 zV?M)lKCke1*BF+^q;w+cU_HSwb3u>lFEQ>9(DZlo^aMem^4N2Vy7BK1YKet!J)~4c zn3lP}9R?xjK{0Vq-VXxu#dX-PMp?`tCK?SQGgivm$|wvdmRr#J!(jTwRheOm>&=hW zMi@cuvl#|pyNYCR*FgaBG0lxDnoL|wXr#~1nz<*C-=;ur?*~`SwNN2CAzUXsdYdOI zW}uLWv4X3JYhdtJkve`-ex2&C8Oq=81t$uTbT~3bY6^Nu=1*UY##x6P;u}m*XV*SC z_jrvh542K1C+*tUl?eVhm>KU(YOBCm2V7)M)v(B(6Vi}wra-a_hhPQ~1H;fdCZJjB z_na_bM-;B|v-x{Y^c{PGLvOGXE>tWsWdfAc2zw4e_6?9#D| z3l}K%@-rAevcZ!tE|93vND-`uL4>TX3za(-o}j{zuo-R5fmTeebu%ZIo_zy0FZ0Z+ zWB8H_W6Gaxp%MG%}!>Q&&X~fPtNz^on(QJV|?bk3GLDvq13{&ta0m2Cx4uw{189Js!NARq*1wpf|)`ly>iH9=c zb>YZ}WsFEv79d+AS@cJeFOd$7{Dld^jwZn*RA7%44aQsGx#7*(`*)u{QV#5g*{u zT#-R}41o{9yz9^WuJ0R|#JeP(2ad8Bg=f=$oO%Dp4Q7R^mI;lKNchoj8EGqdRr=!> zMJZAzL-~&icIej_t>;)C{hOdU_l(~IbztJsBGf7}foKqL@I=7v2)w!EX>q3Ra0?NN z#Het;0M)7s*?{f=&fljeQO29ZzPJ7%OgOOIS}Kc^l~xg zh9oDjYMy}|WFv;XmEW^Q=Ln|;rt9m!t4Cb37s^*T7j~MMbPJLUbr@pVkyg+^kOp$j zs6fx3*tjKcTvsYBMsq1 z2mY60Nim#t5QG!czyiyH38U*E&16}s;o`5Y5 z$gjjQg&jlF^Sn*G)78$c2LFG~ZjfYHR}2uQ`DT8@V5zgW1BWU%Xt`w8GNX}4?Q*2w zW?%cR*ay&{{A#(+j(0+fYz(zvVVrd{4QFzeic1SWG_e;tu)Kj~x|eUaOM|>x(DRCB zPITF|;DUH)+hC3+NEh6>NJ-bA`!UykP~vV5p|XpfZHegwXuzC@jL5lY;}xLHiox^W z0E98sI0DrzZa63VU+e zC^v!5DbXJ#FYc7r3~;@92NUWXNPBLlT6}rz3>Z-p%n`X=d}nTS4)_Z0^;TeZ8BcMt zdNX&6@jqGs_KQMk$Q6Yk+i$E7omMd}ChU#D17}5#iReYUd7PF1RJZ-9KlSG|HlU1b zAe?{z7fj+r;sp|;&p!(e6(RjGMw(X8D{8gIH#V;Fd0;cpjEoiC!UOVJVmZWR>!+)f z4AnsIIE%iDUsws=fC*0!vUM~TPC_~Y172`8gV>Tr zGit(zVbR3uCSp7J3Ch47e*&Yp??Q~RZuMVu1hWaRVQ<$D{C#Txxw)Yp&{-K6y!^R5 zB)o7Es11+NG_uTV(44pi22u%gv~yD%z#*J#mB)`$WBKP0rNxZ-)F1@X1R3-tMf`!H z*|&bD+m;{^npeQTjDgD%tH5~rW1KJ*Y|`Xoe#d&p`tl)gV_?A;F+2hDRZgJyyFCkN z{!Bq{@|izOf#jqh8sd~J=ax9cDLMH%xA`InatrHms(YB73+eSIlXCC}N`(Ln&oI`% zgpc+e{)^9;d>don(|$0og+nz4}M0g)rw9%vZky{A)DCC$G;CJkk@m<*uHX47YSB*J*xt`f06OL zl8&Ins1dP%+*@QQu54EAIXYlvh|hx>e_}`oi#UA+k)=d2c*W=!npI=jNX}ur_1yYh zW27?UuHZV!@eJF-x}Z++0dt>LKjf#A@2-?t;?!sq-|ncPi7N$tLYia>k#l8`!u%R2 zp<-g4)59s7er7lY>9p!#r5^u3uVGeYq#`6DB%)ubCqTUS3C2x^j1jbcC9*(dBYooT zNqoy^k)SoHnRuJPo!UO|9*F;bq669Lj>}ymOPHn=)1yP2{mdYKIW{bK_+=?L{T+lV zxN$uC%ouZKlRDHU`l{LK8MfEn$}+>Mflc3-&7?>JuJSAC80%g5=T9il5(Tu1&+mg= z0u_8gE`Sx&*cJ|B9I1TZJpguYY8bO(jO}Hs7yi&1vTEr=Q>y*I2enTUmfp!M^dmF) zuj%XNn0`qJKFA>ydCOeqnNOd+(0vAcR-zfW#T`e=y>>xYyN{t5!c1=yM&YwQp^t#< z2te=?Avv<=0Z7n_=L!3x(*FCJ8u<;!xdK@Ujv>6LbFF`FTeeG}*31S$Q$#1yy&NE6%CqpatSp3Q~tRfk+|4u>^LuG8n`iBT;hXa#>xFx~v>9clRf&;#I70}rR`=eMzjn1;2G>U`# zyGvmNfUwRi%?$of8~r~=@W1~a!R2SfhYpy5S=T8)JO(sjk;m$YbBDrNtFJbvCunqb zc%+s5*}c>uL5tOzy1#ays2KQW3nVF(A&C~e^%|_CFt#Ezoy@$_9D!zYmkrfj^8}kf zfIb#*fLC8KH3=s)$OPn+aPB!ik6;3L_pJQIH~%72&n6eK#$AV0;~O~QT-pWyZYP}KNUJ3KMa;%L2YsVvz#Hzv$VjJw6$2PSQACm-#&Dqb z3&vlr;V+F=nZ7HXp`HD-xgbJ5GNMQR&)a}iZS47(x=Doqr+B8vt0NVLkodAeGTDk? zmbh7p5Qe~a;g{W*f0~j52{3dtT#YsaJ!)IcQ8!G~qod#kDKs{Ky<^~rzYbH%*rs<@ z0y2;*Y&FyQ_-2`YVAj|O`n#C6G?vCNbut?zpULpQI?p*3q4H=8>LnqUM*r8p)85^#(@$Z(aavI+b~q|IVBL_tf&!VuoG!v^7}Km;>!CZGMvt z>IOk3b6F)Eepa0FI_Oq%!3%zfKskXt$aR3~We2fC|3!vAMFs$ycu`WUii|jASi^lL z%DTv1&1URB<8A-f$3q7Iq$l#mYMPC*uHcD#>-V#`>+#+zdM^KbARztz|9N9r@o^xe zstkF`6zGn$HX6H_UO|6`netoU_4KJ8o@xyEVa>i7EXe-*E&5*>Sri?nAgg_v_RpE< ze+so*f`Bs)+{Y^M{ukH%>!bCXLcndOd&l$ipMvP`2R`x@tf96UiqGF;P7tJ$_1UE2lj+knSYtxUo?DFk=+*eS5b2|jRZUnDbA08`4 zSo$lVm98t|oMt0t{Hjvo% zWIxsX4E)0>$e>-H{iWmdU;E_uzha*26&X5)0mxhBPW|Y>SqG)DMlh|(sHhdRpEI}( zWw|R@b3a|E!uO-cD!EHpcb8UQxC$hXXe95W(l`8Qan96@&r3nU&Kv06BmTc=V%aZ< zwhZ(&)Nj6@#^_kUDXr&-L%NQPX0sT=c7Yx7=Vkr3-?PSGK)2crs>DK2TyFc!^91QL z*UnT52}eTv*M7vv6j0{kAh#e8Z_s^fa2_zlCtTXuI8=3T=UhDJl0q(aW1q$Z-D_So zKv2q)_;Bb>DUWCndPqVR&4Wgg$W#Cpp(ZegKFN10j6%v`SVV@V-UO^GZF_TH=!c1< zAsNVS40D%xtX^0n3L&PsC{KIYp4vlyIO<;n0pub9ohGp7E?cPF4r?I_Wko~EYm8x( zB#_q3K^4UW!rC28E53jbg-~*+e@=+ErLnwTY}<7;bP3TL9>RI?CP35N^91coP!RKfT*Ye0;AQ!KHVTM$2qW<$Ta*nA3-#-{da zi?&1w=K-rYE9$uW(7(A^j&dq^^h;ItGEfKltoV$=Z2x;E|JP6a?Ah-%<4@qbkob{J z%z*04PgDoc*A3r@!$c8IvPI?nU2;**HRX^s!hr2np+2J+nOhmiM8rtR<*WVskb*4U zsil0VhIkLJ(NG1u5yKfue$3G2VQ0C0ec+SzVsm$TXp6kHI)agrzDpB&s?9W@<0Pg2_ts6ug{WhhHc zwYIMDdCU5+j>UJCdv-Qq-U(wHk^Uv5&v9Zf_GgDGG6K{tBMgd?)ybt-{yF+YNmF5< z(4B%dNp4Vo@6AL+&?bvO)QAwM9sfcs_jU767~*;P6)4mVvJ`E`H6qs2%-u!o2`3b3 z(mIWx1cut>8T_#$0=|*cI}FtL?Tt);s}}%Ww;&Jp=WMQg=K34rNv?7P{@l~1$9r)X zaOo}B)Z(c%yU{ovZ7u(d89u}zXN^k1T?b+Qub>`~MJ63qkE*JNm_RD=GYTWyY)v5% zG>4mK6nK3!-#lP4EA%O~lowq$kyLba-im>|zTNMu{-ZuSaQ?J2*=7nKa**$X`24e|s7FBVZasQxp`#u|0$5A4tr5Lv8fyT({f%y!4qLdcYZ zrqc)1x`oX-bYy=kNqEHiXEHWVK%Ybz#lH!#mEMJae+mhN0lRs*jW^G2!imdS-7hfM z+W!R_jzhR=TpB2t#!R8uQiqPnOY;wTsdA#dH3-;=lXu|7xWE-8>V=?Vz9N2IcW{o;Jv+a@lG#~jacBjchDj$u(w7i)9(iW z&U%Air{q1fg>FYWA0uwg1xR|wu!Rz8h=ZoKyf&Y(hqG&N=92hjf7BT`h z{5%JAC^!eSNMAxDM}U~_30Ui0=bVY4$5X$X}m@kx+E4{P^+GJTx#8BY$GHy6Ae|5cHpo zpf8{ni0`V7kw7MiSz!=mI;yyL{oma2TV!9O{deX%QmmlS{*oZjerTijAxHp6V>%9e z%s6|1t7ptI!T7yD=3qZI9|;=`^DI^%FI;{gx8^#OBo~5Xk@i0H!Y3t+78m`9NAfTneJfGT+-$BF5-$27w(JE*m z_}n7D-XPJJaf8tqpIQ1o*frgJBkfm5INkgAk@T;RNB=6a0mdSqEI_Y8`d08jVhP5D z;pbvsTR{ofhY|Fi+lSfBR6vrwI;iSe_K;ml4D(xCn1?XlViSTqf`>!+j(!N?aL&B= zZb1qO4)HftnPE2S5y%Oo_^4Ouw?K~ME3xn}!epH1(Z5M@<}qtT5;8#<)DILBSYUhqa|ux=aP<)4Vf^D1 zO&swk@IIeQg}$R{CuX!vUbs94n#1$C+rRz3YZ*nr;gV9W*1wA$+P@4U;iv&ek*xKg z<}{xxOmq0_fLoX5I;4x_FoNVyIFKHtG~TP4s07eV^juvPoH6Urjhn<&`cUX!fpx z`AG3sSPz@dF#ePZvBXPq5PD~rRu%L}?hluo`RAi9l@Nn@>$wTVbl0N=)5}u|;{-)!7;E z*=%ON`gdTSu*0yPn#eeg4UH9;3JmJkH~(kEfwpG5_?HofLlAd}g6@#mVtoWXrrG52 z?DtglKgZao6JF?swrInDF8HP0$-Zv-i+pZ-A*jfJ8uQDXee)Zfr_f?!^9JeA^|jIy zb#wz9ckbb02nRrcu?;@JM0lvyS>+5;gP^tl&Di7nQ_j2?%`g(Vl5*#o5*T3Wze zu-^45$KB$dEKNnwtL4lxD9rZO?w$rLz6lhZSEm9(?(s0p(8&$U#I>tHa%}~~6u+jm zAE(^CJruzfTx_*FamHkq?M7m53h8t812)ok?}3YR4Hmu1%{TD)q@Pl!I^S_W&Exw4fB5K@MM|gqQ6a$%D1FKm>nQ7HB0EE$3E_Xs(AYCGA zW44VCYLoDN13*h#H~FFX)i1CPA1lX@qt%k29*%*A(vbelUwMCjTMR}?w_@mUU)m^u zBPS)pc~b(C=Xf;GM{YeP*GN?&qY-uGs7(tAc%Jt6|NqYgr}Q%n?=G#xa+C&lz5m5@ zJue43#HAN@4==u@X|g;4r~ZdjtsEUyfTmNW{jkQD9{!70g~!PWxRU;3v8@CE-V^j4 zhJiQeAigO6uWs#apphxE#I`JQV%TI~naZHlkW-_~x%O|;q%;f%jdP{n112WitxKIw z1CMS!cjNiL$r_UZP-F;Kznllj=wCR3m-~XtZfIk{kskv|>-+*dOI5qRcL~|rRuzBW zK=>W|`mN2?1f18li`~Oy{~UyVduq};m`C&UV=3RiSdPCzb381tGMdy~6#vZ``s?rL zW7vl}oimmHeH}=7taID+v3{d(WAc0lcn!CXnaW5Qo-ptJXlxS}B6Z^9d5mMh-tOEe zyX(I1c=MCeNlx9=sBR7u`A@w$$UDU+8g<$N2R8Xjr!>9CgjyLeu6xqQrZ zmaC%!)IjOj_r;1`*+V`YWbCP~zkXf3|IAH4E#^F_+9lpTip)#S?~az|PpzBe2u}TI z%qWQ|Rr#CMcZ~%u1yyiu!>YPSV$ZC~zDtib;pQbG^kD@(bjzQ6WydP`QCZeUB}qVfGdC_3VKrBBF#*IGV15o*6%he0y!^w~9| zHhFR-ZLH$v1C#o9!^t_q1{K(O+N(8s#0gF9?WA%IAB2QEDFk(bvl3s=iVO>C-I`Om za?lsOIxO|ch}vPiwB)1LWYrT!-|ra&W5P8;+Sji?O%6)Em4r1&Axv|7i~dMcnP|Vc zcy83;MvTAb#?HIh$MFg$JeE7@y{8LQ%ci)`1dV;P2%7f)aDHm3^GmY3neUxlHvQwF zllsNm4^_0P6gnOe=_o%Cb12z`aWUV&S$a`tFq;y0`ozApoLqJF>r-DnS+BPT%cFw& zX!p}{50}yG@!ohCQc*JBs+Kv&>zzIJ1TypE6{!@9pW)8~aGW{(Vn+5SvrLCp0s6`g?nfHjmz&CY z%iKEUHo30}o&S*fWV+iWK6{jtvaYu3Q%Cg)qj27m8T)UKZ=XR3g;ri^TDsg7>yKh% z9eBA``|d&K-1j^;`lIhtmpt>2qDL?A`Ro_`jQ5=qZs~NNRq9E8@w$4BI#6v9y*6gG zdYn>el+BEVBM_@`{;=W^5Uj75x(%cGWUogZ3XuNI-tUJyGj!>Llcc`?4)yfOJ`K;B zYNUb0VE*H7U325psor8`efg!5DRIgi#1M;FrP=lS8G9JmUb%91 zle!q!>5_6eN{x6lCeifms!>M#s+YGyU#V2%xlzaVYZa}Ms-F_{znQe`ir}Z($+^&l z)Tk;UxlS4)Le7@ZG-45tuZhs+l-qmIiA==?1h?dAW3wxgxJBJ#!-clQjqn(_3s+{D zw5v2v-7i)np*y;+Oxeutk!T`$1@Co}vT^yOuKs z~U3WWy-KEBYi`s(>twdEf@DfZ74RpCUn>?1|%53;NWH&A4 z0;LqGf8Ms1M@_xz+*8?A40_UWdED!NZpKM+{2*y%f{7$L4HDius=5v(zxv1gON?Dq z-+XhQ_ObK5z8HW8}B%m?=81AQK+YSkZMroCWJOI z-15E!qSEpooET09vIjGN5ia=4W&4eCej9)JIBn1$wP~R+wZAoc%TQ=}6&Jcf?z9(| zsjCD+v(~ooT_W%8;pdRPDxTK074S?-^i97el`qSw4F`yzw;(@B0>`j&Rzgpkm9PmF*n-2x30B0 z5s4S-EbcYNrgd?sE?`7ipmqmgoeZSF=>B5nPw*#6$I)KQuvyxTQh??09VUZiWP>tO z{GvP)#njkyiwH$!t>~=#f?ni^DyFq-PuE6cRjYjG530Oavf*-1S{-VHy1UBu1+7^` ziA89d>Mj)8zv;y=3i0A=+0xCF7AoC-Fd-wiVR^xJaGa52Q2N?$aar8L=%#iUR33Iu zi)mKJHrph>Q)p9FQ12cPAAI7gwn=;`cp%-cqfJxUS{-7Y9xVR`-0rlekmd^hazTDY$JI{P3q&TyRu0T(KXgX$;eKytIbTM^sZ=k~N z6tE=5mXpaW$x^%;c1hl_OMG~4$?xcex-yNO>HiU5){J>COb)1n)6+VK-?JmUhS}&4 zR^bLADT}U0WfDrdzYt{2dymrMC`X7EXWX&xA*+wt38(uPjq17!-I%I^Cm$HUGN_Kz zu83v^?}%z0TuFVlj@?4&sxg~bfL1-*oiV4<>=-tN@)o1q-sfI(WHP>{qAA_Huh91+ zTS{@OzG?S*MJRdq)w6l2Vaev4CBTYVYGCE2C)#lqLbW`a-_@ZGEL@WjrJ)D-H@M<3*DvYIMzXF`lz!G7t%p@(4p zKUXT{Lj+B+M|RQmKjP?{(EW5W5qSlii$gjTtoKa>jwMcZo_e_ss%zc6HcbwW1F5?> zLpI}2yCb3WwFlV=!6)y~Wq7Zpe3Eihi1IzBv=@JK+&+Y96Yd0U=9YVhEB-zdjhj+x zhsdQ?0K@^OrsMtJGCqCFB03soZ|GJOgTE}^=EvMOf@7%d7rQ017()V6x^4}zPf17) zy%xv=y}~)+$7#5mdD%i#n5t|{6BDP@s~U*Li4hC$tgHkvUx+&a^Qv&AF$(!W8NbmB`?-hkbFnCwoaR0d~NIVHj2<{1~HLC~9hS7q)mK^!wOQExV^dSdpoXWr9~iXC-^V<5r~ z?1n*Dhaa2e-t&AAvExO9*gYb|2fu2dd7xuIY8p;w!MsdVn~Q(kIqcedc((3fL^Zvx z{An$dl`q1es)^}kFHM1l^`Oa+lX>h3om=Iuzg({JHjCmq(SA=+s>S8H&sS&Cr7pi# z!7T~8z@6R~Ne<07aO<$mh?LtOs7YrZD(FhuBrN&UffCgOo*!h_kV4n2>KYuITfSp` z7uD`Y=eg)yXv2Avcy>JEDtCSug>KzvSJj&;D=Pa8m(*u?%Rb4(s_hv57;`hK8-{KV z99bc%J0AOaummAd`fiAD8O9S# zv#wBd<=Lva>Zvf8Cg|;RKa+L!AxrZr3aN+{w@*wcbebQs*V=q06}r8*lvH|Z)n^{W zgwFR{mg0>@)Wolc(80BZk;3 z3k#0j*(gpaUb5?W8nSP(aL5|ujR*w?If>-!!Z)XV-W?k{T)6oL2wY6u-Cys_)W{!R zRP-|R zzRSQ>jBydFm@@HgspDOH+|hPqu+ojbgeaY1i`X1!{n%SJdEUyThQ8_bW0@!vD8YS#Kq6Q4&m0Mgr?ukmj3MEUdPrnve0 z&_SKmiR39Om8-X<=uF7wOs|cRkQ*8_A+yVcV%5tj7o~Dq=cnhK=O02vHJiVQES^D^ zOit>XHRdz$W3e-02DL6Zi#<|SxK6|6JQ4TU*%MJab5Alx;Cl!4>*r=dTsF{SjV0?R)% zo2zyaS*+3ck}=fJa1zO5k^Ct;K;Xbj##+KkmA#!G;&3kV$<5lSbb@4b?=V;w`4~VY z!H~k5rrN#b0AIo1Z3;Wew!b|7hS5Hn?0VtwD$Wvi!Qb>I!Xn(A7cr9{H%I_IF6$=M zj?E*b+TVg=eTB$POK(t938AhE3x1>j#}nWd_#k{%qRIHx%(l3KYFy=gpSsiJ^(-y3%p@xY-(e#jiyw4r$#(~g zq?BS>QSAqa(;h4SY>E6d_$xE%6azw$KCv_K+l7FuR}<7Iy zPijO@Cf;s0LoxuHKLOKAxVxYZyS;MH8D<`^={+x`Ss1$EE&9<(QQ9TdY&XB{C7c(w zpCYKh%dwc(rH*Y1emj!vpwC5`s@4QdUJIU`2X76RA+$B#jfvMh+3VY*KW++MMQo1S zv$R*)!OP%Ws}C8@u4Y5g+KM|9bPc4IM+o{%mLMGZ@&ZyhJ!cY8$-Tv+ai=}4CHdo?Ho)GoAa zQ$}!&cny<3gB^=$D3KiXHz=UeIZvG94ulj8O4%>}vE}}BuDzhvrTUKln(bGv5K8_a zpRc+ryxR=fsgeq0K^#Zq2ew+R;wa%S-Mqx)RY|BBQ;B)cdg~bxFF4Bm{5G^~*FL|d zuU*u3Fe3}dwd)j#2&1KZZkY!q{lV{8u7jT5C!Dxka)Tfn5CB>xt}`SG4dDP-S{Yd! z4@EOcMm|S~P+%dHUZY|`b$ zNV3RyQP*~RkkyMfKF@t1WQt)N`FyXs4B5%$&R<}w#?QN3BEGu$UdezXy?f%V!X@`5 z|2rP1IYqEhX%pkyB8Q0Yi9Ot-jo6UB)$1n_yyl+64)>7EMW9wpCW}$vfCI66;UMT@ zf3d@ZzeW;v({XFqUELLsN#+7>8k!*Ke0bnl@8sfb4&J*ZqL3dJY$FzmYRVP*Rmf9qA6D1@S9~Vjq zf^mf>S&F1JeSdUmw+oFu*`(hyBWu8U-dEPGrFxUNt~yFXwTx-UZ~i#kl+toL%%=~o z85JVA7jUulLy{g zIS=-HXWs(Sv8#;~MGE$T#}Bg-Y}$KKB%D|)&qXK))oJ*a-)IUr80ytoHJ_;&4ps|P zpWHZWLH4CAog14w6O)z+*I7qCO>#9-x_WN5^;4jMndaHr8T(V6(8VR6zbyi(9xelA zO&XL!@-1GZCT|vvDzzLPh}+Naa@R>rM+Z2KZ9Q#czLp5o%q6&QV4RDzR5`SLymf8j zu$aMwYzVaq@jTG6a0C$q2~!lpS8$jnC}e*uca*vcys-_u-3^9KxI&%hF+l_3ItxSW zMVrste%zq0xKX@Q$(vmte^A^l8&{mDTC_u;bvNL&3Bfn+L>BieRs<>cs0g*&vjlbI z-(n)3wj%~r!SdZ18lgjO9g;5JB&|ryfZBW*xzef+ESU>D@NCG|42(T8?H4YT1xjoB zU|{CJ%>H5R6ex;(qhohQ1Ork0LZWm5Ek?XsKD)7v&=c1!m&iqCkGO;kgE3Xr zo&9Dkr2F>@;a!~3UccXsUAQG~T)%(+Pcm^dqQabpV`R3I( zf4xI`s9z~<1kbx6e6y{!V}Q0-sG<6l0B8UtQC!BF5+IQ6@f|O&T;DozWN1!&+}Uv& zJ1za|s-+LW3U!yq@YazimI2LO`pz=dP62csVt_X9p0)6F_Y*-uYkG`4nYOl+ch|Bj zIJ!Pq$o&9|-ef+oz$LmBd8&yM)Q`gdDlvStl{ zFS0ldnUoL-fds#s^(%B3a2R*LfKu`Qk=-FZ!tFRVs4<#YOkSYjA_Q0z_f&u-;K zyNW>A5JM6#10M!N31X(2=8QiZKP8&EtDQ1K-%nF%-@Sf@Ee~}CLL`wM^gK+(Jo?n& zJhNg5CDY_;vb(O6ADtE{(y&}MG*1;qow>#Ryc@5}YvF;F2u2-!lj6|wvDxP<(Z<0N z5)G-D^J)!xh|f+b0`(Oa$%)xK#3h8|!v7{j9v|Nf>WSR$KVPAshpC1PPuUlXe<^I%P}*2xtpC`vLuXtVSFFXge2K@DU)kg&K7wX z|M7O|KeGn@W^oep0Rmlv$gP(O{ZFuXH^UJ&Fk6AX4Nu>~Jz|^ok7EA+-0{MdGO0_cJQhv0>{4%a)pdZ+WhI2>#A9GKV z!N&(S1A}Qj$J6UU6GueA3fEzi0Vo( z|8`7@x|gJu8b=o?3eY8x+9VNh_ntrIdZ z>IKv`RHjc|4olDv{um?2fKM*E7|Q|8 z`C40Yp7M5j?-7f>IK>2+V}3A_nKV_)GaSq1F-fc#BeNZhwQnVq*?c~J+7=A~tM<6) zv-H1vniVXQ8S56i^+n5lK56h$KxWL!fa2@^oh79j0~l-W&e!IbP-3)(w8WR#IY+;e zcd;~-Y8LX`w_Y^RP>AkO{J%o@<)MJ{{4oTYW*2yOA!+Dsr46x)cDBFsjhoJ{Fp|NJ z4?Se({vFCHwwi{yXwOl)7rF6!6XK44`_ZjI^?{d-=3~2(IfM@*_?+qC0 zA51<%OSWSh90z{Em*cSTdhe=`iFN%Rf4T%xJb`P zm-@PJDtNUe;c#mXj%?ePlJg}wq7IiW^6mSR(L@k5LY;#0=gaFzHa~+tMrPQhEkFYd zFF?$j)kN_`T<~jSL)u7IXikzi{K-;z?R$@E-%6htx>+-?@pFa=$djkMshvzvv-ye7 zbQ=Pl*-ki7k@n6JKkXe1;ucvit~_Sa?kuhO31@!@(7cz1hs;D}xdq1PbidFjS;R-+ zPZa>%jswS`1G~15ALUZq+G!FiHNcnF{lO6L-nlH{sZ9MfnT$Z)D9+RL9&E!Xdl*K| zm&jX;OMS33O2%7j7HP8)(%;HrUe@R=M;P*&NbHrue`L^9Q-S$&i&?bHj@TVQU{Q`8 zNd)eTy6AebW}A#fV+C{#WF>$$uo7&k;-IC7J-y zdV3wkWdcY$x;nbYm@_3w2Fg`T6xHs>D!Xq59G6FE_LB1ptuL0d?bH_Vr(H%L(|cb2 z`3q@8I(*2esp@(8-Xu~7s^9eusDmHkaY4Q=RJN=>xO^d$BsqLs2|+#v5OhGA$N1Th z1D?mL*l4#9XF&K>Q&Z+T2hOA&3?ldam^5tTCFd%&#w)6^e4dALu!~`C{q} zn_}>IufIXn)%tY~?Wu%B=>E<)?byA)OM^%QUfeb)@-)VI{eWZ7S2Y!jg_v;vfjt^S z+Cr${w+2NTLiKQZZK9R%ybP0K%({SPsJ{kn$1yEDTSH%#MVQ7RZA7)*n4;YKSAiVTR3e0 zSa;ShL0ewX=WGq{${Xvp>6l)`V;5{M28!srsm`n&E6LP6Gkj8Age%oU_REdE(A)5y ztw85)yc@Jp8#Z6G(y;min})KT!V5JuE>6IzM$mYO}N~AMNga0 zM`CwW%Y_&wPIG(H0NZ%S4Xiyq46sx9j^2D3E`L0V4Ph~V>QEzJF$7cL5+E6Ji-TmM zCE0pOq_}ul$IxJvmew(Oeo2}^==hq94Y(bd%b4vCF{S_h^u4oQUhAXD>YISCg}x)0 zdm$qqH(U0`lt%ROhQFp*s>RrdAI+1dz}+%1D7oEG(lV{ICMf8Xs?Yj5>I^v^ev~gB zeoQH#!P&(Xq}1Sp9cP*~VDxu;HO^qpA8<7$?!V9}Jy%d%qjW*<0g`<%wrYN1nM6UI zEP{!-QQL@Z;`OjOHIKD6$DwE)L)Wf;*8mF zP*{&ec*qN1g!kLWt0q$0`{jM-Zif)iboK2WGO#ZXJ*b4~>~SKYT^tf*&W@v-qRQau z{#Ic)2Ce*CDSpZ%9nI-n3r?O08I%WM9<0;bpU9+!9A}uKuUzKe<~P@8;Z^~x+2(gk zz_xYbXuJ5-L|f&+f?(xVT4lP`60muA@I%9Odui}U5zhW0OiRx=T>ko(qK)DWwenF%JzK(N^o5%1*#`hOe_R6pk%He7C%?DLIO^3~5TDxG6k3Eu zQH!PAEm#m%61%%bv}k8?g;oBMBS+~A{stV2V(a1;cr`O7 z7i^m6x9@@jq9<&faOdRE#O->cwZK%(K$3EM?5C%*_@R(S^}_JgK$X?*am#=Zw<|x| zb#MjW^#Fbp#S!I~8Kjzw=&v(}A0YLEfeKH-JSKMdk4|hOPj*LsJfV%%ryeEKd&~}- zH{s#YZ|F3T{X1yQn~hk(0U@li#QPGJQ4V~Q-ojlohg4QRU+)qq)ADS zQWMzNSo@N`I**^tb9K73XZ&$c9TCu-#vR{x9obkg<4?T0hwKHtOFrNu`7A>50 z&;P{&DDkUVt{M8`Y_sE@?3FQ9L9wv%>uiw7@Y+Rowjth)17wUOl)+f^#`p`LHEO<1L`Q(BXA8JYz7HV z!AtX=;dLcdyk99=+JS4aiE9hz?MnQA>;`^8#_+Fw?u7s3>6*&S)J6&JtS%n_RbG9?alqB-VsQe)CKc-b!R8uX3D1B{Y54UdA;*q$AC*jCu5TuFb|?{ORRm)}ss6vCmQ>~Yg}!Zam2&zx7V{@xlII;Le- zlojmp*KW&qEn}Q*^U^$A!u_wl!8%^oRD~U<^3ToTuqu)MrSckNri2n>vG2DQ;(@yw zs#&$39|JpLuw$xjGDfD}b!+mg?OpeeEP&u4bP0?eNM(_{%Vt~@kRCtNSnfVNM-_ia z#{Hv&Pf}{-`B%auhrMRnVp*~vb|#kM$5=Ia{NB}m@jr?u1XBv1uFc;lPZYGK%2Svv z{5#q14rT)6u>&AqRSJDw%g6R@dV-9rr{+$djYH0`^J3&(SRwzi3hqBwI9Bsu?9JCoN=LfN=+YJ%P zUu5Df0qE^Iw~C+gl@V0WethJjv+Rq07U~i*HCXgh`sK|gVVD-U zMl@i*yrJ>J1byYm`wZ>Ujvp<7CEmyj0ZCX_K?l6Y>mbL}je3bI{m2}2hj$?2SM{yo zMwd361m`_=0at96vm{*6)9k&*#I+OJq0GUklHZmv)Qv5>If#*c|T`ZQR17e-0dS+dsL(h9*rqFkr zK$CfY7t`Yy-hl1yHn640{Qz! zH2P-crN#pbLkgb~E$L7t?YS1mD6tGg%U)Gu#tY6q5r@6AGJu^PHi!~9;pLgGTI&LN zFZTVwgGVASHTYPmymU%|Hk0E00swaXrl7N4_X4OZn=`421629yFddU>3^((xXWgUh z?ixN2C0Px9+zm7e64=sfcTKTz0^eP4@vK?>Z#iMdchy7&w+)2fj%l}oISmO}(>bck zJ6Yy;nM*DYZjHXeUHUP8*n!`R;o_8E8*uAZZ{dfo0stO;Sf9muo1wr&SW@} zc+;_DhlX8PAnp+7Z{35!ZOG9}ULw_DR4Ua;<{TqQDYx2u?~S?&Q8K9XwB~p028gUa zf4yQ@2d0{Ym=;BmTs{^x)lV->I&sqEk#{y^v>%t6zR(DvNue^B0xgu_EyErbP~6c- z4%4aaVvX>(Q`}7X%OYUYTK71_4Q{JTGHAffXs2d=xXcR)4 zMk-jW!Rq}TTKPt<=j>n0#Di1g#K)^$cG2pC2Jw4Zhl1O==+Aij6a>}OO&eVsH>CWo z5r6>=#UfkBXXS?qKur9)?m|eAHt|9z2_8OwqmDMK6m~c6i6PP9;R)RnuJR+J9>t|) z3;vg@6d@VHcP1}~Pn9bJwpMv4gV=QwxYZTbn4JnJP-M{n9>?wC-n!RAM;5uEEgTeb zxVh3U=1i-v^st$7G89g)>^4-ePyoo!0cW#U|K%jN1QN0-VaL7?%^Hb_o}p1aP2jZo z36IFS%(i+S{KMZfTw;qOnQNAfUZf$^_DR<*M9j!0oF;~}R;3P;JsPJvyXU^E4W{cT z))W^TG~2D&F2|aeKIX|+t_#dgoA|h18idd zbVfAt3*(b177-;SX74#P^OMP@yC&TVX zZ#V$-jLDL(6X_X>1Ww$?axnvafmWL z(Ko2m9^n16%RJZvb*1_V=Sf@rsESWg-LK{yfwLYRX4i@&YJ0Du+bErgs7Hsv&-(>X zj}Lx5yH?eqkYT67_F5E;ZSvdl^0DQ8?~t86lePlY+T6?!TAf~3IJQK8J+AhKj3ha^ zt%H8E)8YQ1p)H;=SRUo=DXafo@X7kf5Q$7As`ar5-F@$aX8bw3e zTE7aE4Hn{Y)2alUxZyLqygH5eZg!CnX%)^mmnr8}O6Ty`mWLpVyVHn+dHf<>_}2#4tQ_W$3a)vf+VfsPpV^HMzx%W!6jl}F&J=J;92UX zFT5M>k`d{aTksZ&SArLq*!z60m@s)cfk@byf!D@xY>F3+R~AaeB1a{4PbV8fFD1n8 z);pp1`bH&4z=ofT4C#~3W%Bm{aYdeQ7`V6PqI|Z_vO^jyCPxG`RK@8ma_pAQHF%29 zxC6D6`vfEPC%9=`g-;RRUSE@FIruo8CW6;I9oqP%qVvxPXa?_DJrdpz%?x6hUc9V) z-4F`{9oG*D7+usKrZtve(IC$Fb!(LWtd1PiMESPfbQcE}OReEVb};e#eBN)FO?Uli z@3TibeSz5Rd;i@?|5Ld@V8psq;aj}JG`r^WhX&S42?3|dKQBB)Eo+pk7$={a$?8q{ zM#`}NiO854s1u>FpMwk%od>!ldN|;$B;KuiRG9Y-Z^LqQQzQadyiX=(4)JLQPY7iO zC7YTzzAfKY5V{%`VeXy8z#{`_N@kV~cvRRxz} zk5NxYg?e5TOK%!)&XmwD3{uZRlbQAAL)D$EMR{dfUy$ix6yMK$+x;8Yl26%D<6cwy zQ+1RK&a<*X<+~bQ_T=59#}dJQU%PD5UCrPtOIq?lbd!2a2ahu3#lE!B+6oO8vH}k0 zmcDsC2krLW9OR-0oGPIeDglXLcJ3SzOZx}jA9=}p-cx|d{oC^X=fjv(>N}3q{K|P` zaVHvT7xnw8dN!`~+1=@yu4$D(mr?HgMOjNFR_;xfyFD6=VUm2h0xsh(-O%D6@ftRV z1~f7k@_FEywYXFhQ%rkTR40tj!mNT>K`Ckcf_RwE9mbnOw$(Uc+?bISihmQMDra3(9;GC zQt3RCWo|#fdHOHghQ5_#=w`>d_`HGQ-H@pFj9R%(io7@v^K!tojQ+*-d! zEbn^nR4oZJ^`R)#xN z-%kp;({{X>l1V!WVo9sWEiNefJUCf|Oxuz#fzOpTJ9yNOw~|{m!s)n^LzPRR`DaLA zk5!61H1}Es&gHBWF#dh0%GAo-Swt2(cRrI+6^0kTkIo+d({h+oQ$48GfIGv*Z_fHB z<^Ey}{mvi`t`7>0Ur)N=`aKJ-KAU5cUgD?n`*$O*%HDzZ>m(ZTF3Jc4TBdahN`c34 z83SU*!>S#F{!#O4OW|#8RT7M#t8-jllQ_mo^VXeG{bI0K<#;Go;1=@lpW3kJQt8Lo zYECZcU6;NkzZ2SV7nxK9SB<Pyv+=KPT;~WU?C7ct zU2k1WhQ!kv%|-1kkMa_QY4%ep#wT)0n=&Rgue{=5gEf$GUtS1ybOLIMNQu|YB?vOA5S23H6$cuT|_+u zJTx>Iw6}ae_VcOSTZmLP>Tf*2AD6JBIvuFKd?Lj%#L`Drrt~D5l}Y^DyY0|7Jub`* zhMrc&b{avKPe#LBUvH*6-8c@6v3GJblQJ2U{xy9dn}gmzDU zZ|TQx!=uCpn)Z~9Zn_qknU$W{@C`9k$$OK0D~$RqoPYqU+j{V)ONG}KQ1laN-JztO zXN*o#-ds$|eu1uY_&##Q*O7rZi*pFmkA|*@nIP&c`X#W_^3`VB47O-mY>aFyQl{_f zzJkj3EvDMd{sdu6Wll2v)o`Cf*Li`{3u@NIZn9hZ64{S4lfSU-z$2_pOf;=}rIi_K z4eKEkzGw6_2+g#LK6>{cXG&kbBE~+^Vmj_kqj=EkX0W{AEIKozl*l7OYBF28pVQ^V zHn(B#WbBl;X9SqRkBl#4QQ&L|`i$gro2Y7VvnYpudrB_IX)-Z%NwYOJkk3au#UGO5 zjoqA80gud7#aT(O#B#oSsE@bMKn)$LaZL0U{%XavpT5o$mC@P5X<2(v)^T*@(`$wI z9EtmIYy6)Oa9m3N4bvp@lj4Q0TWeV>l5>bf=getv%_90%r3_E@An23h_z#0m3=2Dq z3*Z%anjcX%8+%ZocI$RO8kReJYBo_%D#ig@RE%Carjdn`&Dv_e*aA0ux0rX4e7S_k zsPE=;+Mxtp$FBzsIlqZ|+?$LZ0VZ#=-xM|&RD^449cANi_bq1&^3)!NM^SFy>9=Qg z2)!V;&Jyu~@>hSS**R=hVMnvZX!HHcL&r|%`wgau=jlH}(Gs_qYm~g{(`kj|KHw@i zTF5mK?DAaBHl@kRlevWG#oQVxg=kQ#ATrGPN6sHPWv3We2j?OasC?I>1iEzcbTW^F z8u_p)<8^5VqLqj6HZxULe|nRo4Qrfu+&KIrYW^p*{FON5{-2)t8`5>`w&)~*4_(-y zwmnOxa#16*~#T~fbD%=LE=XsJ>%7s=038Zke zN2C~LbcBqk{QL!kiI5#&4)vZr(<8gfFOPwRCsDM6@@=A$IA2RaqJ&oK_ipY~aAGaT z&WWVb-SsKRZLeMYlsThKdHPCmhAIuzL4=qECENRnde;$QG}w7q=GNeqi-!UqP=v9;H)13dc8Ag@=#QUo|FF=26(yARdv ziFcq3uRm@!K{L-cRZOiCV55YB9K6Sv7fDvdL6E|SYcmTvSC^tZ7inno(M5xae_Tl~ zQRC`isM{R1jdL1phn~9esb3Uo(5xyd@}kzt7Oe6o3Mq~KEm+}?j`^g6p5W*HoRL3O z8aG_~H5;Q)O~G!?Uja7tDGN3F1zbZb*a^K}gXB-m)D{YOQGn@3 zyHU;Qd(O0?&N`EbQ~Rjff{%0sUd!_*VW-^|p59ED_d~8+gIzdPk>Gt(xJ-vc$-L7* z8RE`4zK%t4EGYAv#fEV77rG^o0Mh^cF@}%yEER0^>zyUL$jwgLpU@B!sGip%xYRSF zE=}n*3MU*mutVa_$85uASnd8b+ zeO236(hAx>@!`}qF;1oCu3_Qq-$RX@+&8ZcqWLZ3Lg39~)FyMla2TCXXal8c8tgf` zxQ#RKTBQ?3_*r_N4iXH=(6QVYJ~l89YL;6V`x$ULmh&wUmBNM7f)lWfY)i|z3xx&W zPw!4|ikb~{M$qq-c8! zW@#w5u8aJ;wQ7mbKZ^~29Lns|vMq$pAM#dhr#bP&BZEPW0f(A^knDt;X{kc~w@!h9FG9JS-{Z@Xq>tzco?Qusx%=TFA((M-C^t|5>3N=`c++B6;4>E7OM&K%- zTJC&uLGz*lIVunt(88c#KmE4SLsl$t(i!Q~FZ}}63qMyQ*M7lRaN-zrd06$^1`oYD zMOiCf>|aaE9Nv`65R9ZWU3?f3yWdh9MJXRJ^XX>WeLFKMqlmX?><8)M7r%Xb6)Uq? z_W?Q+Pl;xKR={#zuJZgOpG>q9cSW^_bS5a4jaeDI;>Nmu_$T#JT-W)}+P?4rc#{@U zAZ`BQ;hKy2eV9PgjGc^*usXu$Oy1`Zx}lbP`gO_*XnL}^p<@u(kjD3oYfYAO2_h`Y z>_^cY<}E#^zUJ7zw?I`Y%2oVou+t)#1JPW6U+#E`UTRhQd7r3bdn1NSb#l(maG{z} z`FvNoDi-)Dk|xU5P-zi{9YJPysiN3V)I_~XqsXLhMNFG}_iom#gDqHd?W6hWl#gZN zYHf#CmP6LZG!pCzd}Wd!zuHZd*ROr}Sl0!9ZqM-j$eX_NUi`26e^&Cl5zb0~tpzxS zgFA+!(*n8u+43sKohW;yI(1PZQ0)E*l|Ssbp?FE{5gIf?NoTUf0mGwBIC61YSgY`u zP(~p+f`aeB%`)xjPW9WgSV8hxsq1CyRtAvC33_i~8WA0w9Nk#wFO4P5`>VE&p+UXt z2L2!;RS>4a)+aSbEMrS@B$@|1)UcS?U2Ts`J$?7Tr)@33TmR~udxDlqUQ@lN8mcW^DM@d|rpIn!Cf$aT700}@7$@^pViSLB;9 z{+`p9@ZGr5X8KC+MO5b@0qKj(etMI~B2bXH4FvIUS9C0z;uErMW**dJTT>L@EDo~+ z%$L1+dnU75-EYh!Ev(WbmL7L+{PbOjtRvFD{P1_ZwG6wV;@dpe|+Rfs)U#{b3 z-?C8GqpAJu1(_c;jt+8SA<>;tBx*m2E1>@$+gT2g9&fBLCot*V9wYo(-nVk%y}MPl z5Fd82t>X0gyQ*wymtbC8yWnNJ2eHpC>ZdVcv;3tGK941hn+mYY<6r;94+CELJLrr| z>duG6e8{yel$*!!<_`9Al4dOYY7#K4Ub?Te9eqaoj1>RMZQS4?X@QO(H0{|V=!U02 zA6|`o)x81Hj6Y%umo7}n7JB=ohw0pQW3pD3|H)nWOp)NQLL`91i$mBRjIUSs} zVe}N`uMF`-^%te@xIxFQgOSasCn^X!u6Mq*S`LDI$|rqu)i+0porE4c8-A*s!S&V-OyR|QBCYhX^?jTNx3>e23hrL9TTyxU@Vn9;9wF&o+yW8TYNKNmm)rt z!6IrSB?JRC$-enUqBuIq158sE!NSd9n7!36-ZxB~67gESp--KwQb}C!Z98>gp-$(2 zn~vYJ=!O}B1a?1Vo%U4XkcQQgV5&{^)WgYXOPb)j`QOvc^*&V!CM40=KXo6n&dB;TE*w!VjkY17eH%a%e7fkN|3cQ6U zb@!#{5VL#X-n`|%07c|ZI+16SVy%pR5N&IKj zl)ON2Hk0H<`a5MJuD~tXN^KCs?d}{E_F~h6Kcw5?7Z)vg-GREn`~v%aP>V2?Hy8mq z3{?3un<)=83aIQb@FaRF1$%Vqr}N*^EN#5??HfoYco>o0L~WjNoZ-k5j{pe&q5pjv z{na>unEqlk9Vlc_L#qFCgm2KEZe330ef5zJ_3ofRzul3%^10jms}HIH}|R z;}!hxKmR{3^<5H}a1LOlq2B-B-+ZJ7jN{RR&=B|k9E|_}8*l}5;5bUbW2hwZ<`x~>G0QbF zfnFHxvo@s*jCEOAayXEi?Ywq?8b@UVP?7sWm)k>C0exTfZ{J7m{~7eRTlz9Ub5ea} z2;5E^fUf?w*-IG&^*X5AYy+Tz$p%~iI5GsdEW@oR*bMo!u0+zbP^+wfFH zIF09Jd>?NYLxCHpQ9r+VTjRUrk3t*v7#rjLlBKerE1`Fu@t7_~1otX4FU`Kb44{g- zzZKgWYQEk`TZX0Cho67=_#^lQ{woCR>~QL|ATJXQXzyjsvSu2=N?5jDtCR*3xjSlK zUT|N;ES!V0BN`cTnt!TKo^0C1MIV+nVd0oX8C0pPOwgSXiKda3>o{w?2McBJ4q0$psa zK&8n28Gr_Dy7JEQd${Ik$KVc)8?>NFJXn=37SX=Op_TP85fdc`$G3C@;0n8?10R9%n0d(9! zQD{=jkqe&C*8jyL$Y_3=ZXCYj)8^ZsXnyW@mCLBON(Dy8x;VvumX zEN*_d(P#h}EF7L@J$lyy!}iUC+-tAgB#L)ZA#>LSERDgfq2W1~Cw{+uwC~{8ph0-Q zb0_|IJ#;jd^}v(3y=(O7ISn9ey&AnAZ>E~tRDDn4AX%k8`!>tYS+^fb7c2Q4j$-`o z=d;!37Y zNVT){pN*971pbn5ppOUc&FBDC{Ij-3reB0akPe4?sIq`NZ&yp<}LX_Ved5@Je2W+j|H=k;-WwCTcng?ydj* zypxp9Nkxrz8n*p=QK!BNZ)HDAX@QSEq3CY{L+Xf+K1wkmM+K@QX>$a#Fh#!*$z`K4 z)H)=EfAk!l+_JSm!xOU+5O>p30Q$uzPP^vlF+sO^rqAPQ^1;AlV>VO|R;szA zZX0%+vm?URO8GJPT;{&RNsgk>wyC~(^1Y30!xOy6e}#HSf@zgJ=dI3jR_zv(V9@E~Z z1I!jzKocViwe`{3T_fc;8%xL@y&v zezD>M1KEbf1^x}>i9@##PTdsk>WZuc(jW0m$pWK8IA4lKF1^MGGG?b!fhI{7T#nuC z=rp4NVZ#K&qYB}<`+PE`JzqKK$z*VwqkVe`Zfb1)lZ@N~_v+F}w~U?5&3__Saw5(Z zfD%s%?hYZBrTXqby+^X##a_D2f3Q!`=cy&Wlewy~a zH8|--J+1(S)&>R0y`;vS03f-&M)NW1e6mpPO1ZiAXV@Yfd*$7fRn{{)^{zms?CcH8 zSWsZ};QQj|DpZD=z3f#s~kF6n?ljE+a$M$C>t>HhXiu`DYvp`N~ zWG-anqa^ODN`|2vT`3tKc|ftodX$xgEzg!@BEcaUVm~5Z(_qy+iIFr9`x}qh)Itnz zfN|jO>q>gl`~8UGAFt0u$B_?m+8t2(h|7zmMbm+LDdmZrQ}r!fHb~&@L5%NN4n$c^ zKx~rs@g%7^U6j0MB8qSJ_3eUvH|nw5mQtfLco9r2yW8SSX@#Mc4x+hDDE0nn_B0J* zRrkh-WM4>o81J9l7Y8PtaZ#9BE``vmX8*#=bf#%C3D^Q3F!cey1QGtyBUG=@VZzSE2$mkQW5Ngo62SHn&_6x>ggBjR zIs85$8p~ths^#G>%*7Sq??su0j79`WAyjqN0T&PRjLWjWXp5#aMmf1!a$^~y@Sgbe zwU_!?Mw!MH4jo0uS}*nkGETv|Yiz_Eu#2D6rBmr|3cmy^`d6E+rcM@WZG;~mLVr8_ zou6-OJ--K@E2Mi+o9%RBq-pAIJ>kL?BK9Kos`wbVuaA9L00-Glpqs=F3e-moAtbzP z1AxI~PVj)N_oK(*W~c0vQq#C%e>#@rkEw*KWsRrrWiCOh)7nnj0$sAUeFnyWWosCQ zX3~zqnd5{Kl7Eu2_1+EVy6C11zA2<%S7f`BN zXgx2YBm>M*SxG2)76IdXRu+@=x2V}66^suFx#lOD~2&Fz4bE~BI{#Tc%I zNG_VKtK4T9kFIcXax#ze(PO|fU4kOX455H6SXZTh174>J&BLk3`e@w) zWZ8YLB}^|8PqVZZ=T`gn$(C^A>bK9`0R&pcGK83$x%q0s0?6k$N(jH}I=d*E)A`cm zadk6Pfa#?&N6LgG6L!*k!gO-yi@Iz_|4mcLDrjlm8vYDyZF|AhDU=F=M>Sh3Y04F0F5NqU?bXxy{^VzO;%s7pkj$EOU3pKg}V7QX2T28Y3yT?!` z;7dKYy72%GzYZZ-vjO0DelU|R-^*;hEu&r*FBIa4EnqIgw-d1)TDX;uF)?@sHo(b< z(|8%~nGnbslfejH3SD{uQe_$O9NQ%j=U(@qY||%vO1$eE_D!dGHHg6^K~b$dlclQO zFwwm~_uXWGjkhh5`Y7gUG5Q{8wH*|PAmktE=37YgLAcWlH_C#MHew`9B9XtM`0_(8@YWvP~ zDH2=p*GVQir}YJ$lwQnUOf8&EOcwN{wQev|=vS*BEB*yWq~W7SW>A)MoKUi1Xei&BA=|cv8h9Ih2*cW-(oo2v z2g|!ok%+!E7@M_7h_*(tHHlPW&JLoD$63Xye0mbD@djEcfoz*~r2BCNIDa^gtV11> z!fpP(V3L@3xk&)2qxwMk`(+y$Z=WNa^lNc}j_)ZKUrO}ba#QEvz?>f$1M&Q^-rD3% zXW{P>Z(IU<20d5Y06e@|K3SlPb#TpFD%rb)uQ?#w%IIA5ytUN>Op`I4ueiZeBbp8+ z>n(paSXO|#)Q}Oez8|P6;&FG5ydK>27Mo%|IPQL+ay)3x}d4a#2R zkN1j`aQQ-_=+7qhe$$US?Mpe;b2nO_KSH%XxhuvvN>_iNrh- z>>8oSDEsv!85>4K?8qJ~87^8#VmH9*w?;IzL_@Di3-SK*C4v{oN1}X}eKUUmRN&YN zp~ml$fdP>l`QnibWC0kfz7(vxE0EjKsQ)T;3cY@8FFntam(NFB%+7Y6#b#Ii6m!Nh z->mFsmZ=@j&SCmKyuJQqHfG7VU(I28Zf+#hHi#lhQRlIj^j=e^HRYb$&I;ozM9N*S z8{*sRsGX{%z7&!ZARio-EEzGhoK`msy|#=|x7f;_3|;DMvTU&hl5{0M4e@S~$k!nA zEm$`kOiiI=6`n5(77B~M*vL~^^d4D;<3&vgGj*YooX@dUNirp`!fowF|g z+2nrKQ4;mzQnQOJBGg4Y%myn}x>wE(9j^Ol75^E|_n6CD6e=3^(Zl`G!|Ls_9M-C;?XT}r0qT+fYUZo>AZ@pu5rBvYLiRVN?pDgN zSWT_Dnc|$A75EQ){$1nw>7G|QkT9bU~}Og0!U4Z zrCPNkmco~B*~==15+8+lDD)Va*`HYe(?$Xxj@u6(6N^alJR|s!jiQH6w_}hHMXB*^ z<@HqKg0zPu!guhR2n;_*s^2xdk-O&^HU-)eOI}Ohse9I^d0xyqr9V?lg!O&H-^x=2 z*}%IVKt$#NFXOLzvPNAWbQnJtRdt=3pL0KFyIDuCbX_89zDTg9qm88ELkVkN$co(Zk}R!9=;H*=?5b7+Iv_FJ zKkNLE`c-|zouG`KH>2C$0=>djw$8YmifPSou1Ek}cC%eO&W}nKaaNxK)rp^5eS?5V z4=}Wn(ibmr!G~6T>-nCS8rz;;7E0BhRO;fs8LUJjvz`n^q^7u8dz9dZ z6&GgJP)0P2HvEV`;098wNZ%PTiFpQ7lGGc%C&>H#<0IAi#vFNdk;3SOaX5pItZT6T zEmSJBKV4%THLw~3p>L@G+L}i# zhZdf{Cb}Uz@M6k;K>z$2z-FeikG20+NtMWG&XANL_j#+jP)Rn#wKv?*p$gwEfSlK5 z5<}8RhjsC!;dZx(I1y}(i*YJ^F`;CbKz_*|h_jjs+J&D9ECbPV;33EHv12l9O?qm% z#;P0lJ%WQ%m+QYHd7n+J@>}FC$`DftcI2Q#>rmcoeSZXSC|q+Fz!n>7EegCYigZKC z?w|}*9mfEOgcX`{ZUGdwE9gw4FP`=i9YA}b&QDnyrd&0|BuOD8XbA^JZD&)|UtdQt zj>;1Ce6TPZ-`llL+{mo*PUtibwU%(%G!^>(Fz19#$>~pxE6vEs=s?lI`iIR;!Y|^1 zAR8;>o~{z_8H2wCLmX&&ZD3zNjsby88!idzx zjQ0J#w*jc;C{4!@#a0jzFGN2dlgAuce29G>))KP-v_woR^eoNStKPO)bYifrc^nf4 zU#6;kmrGE=ZDTJ$)tf+bPh%f?NiQH~l72FDCMcE*n2vMp_P9V&Z2WDyUk(Y03yQ#W zM1IIK@VI5Cpj#5{y>1KfJk(Mv+?|R@;cnnPxwS23Zg6n7Z3Yy^XeDzKnaO!t^ zHH=N1l0EoK9laFFN*$C~%bLQX86V|{E!K={QVupoww11aL;;d_N{8bK?W^$zyz8pi z=Xv2G1fy34$4kdj`5Nde?p=hY9Rg=i=fBld5a^1__;)qkrAI-f4T@S5#y3Bkw6`mu z?>rR++2?%J9XFQ=;NF@DUq%+OWQdzV3qzcBRU{9`5zRUCU{P`jbq6Q;9Qrx$t*D7- zrdWYD{+*RhvCbfG=6jJsthwYIf^Ff6z!)Ll=3l!!pT;}RdWSzz@1j6S?#L6w=CsVE zUOQzu*@nBfh(3sUp`pB60w`45kO9#To9&_VD3JA^_qTi9FcH8&-z(&e;k?^WT@mJ1 zLu4a!(H))svU%MO(x@M(857o)*~6#01uogO*tQiX*VOZQVQ_7qLN*$32IY}Yo=QYr zO!JH=Kb_Wbv#RC5GuCG`=;k32OUhS>HcW5y(6rUB732eZoB{U1B=Mg`k*c9Q`kR3~ z8EsA_7+E1$r(7SF*uylsjWWH}zY)4CjgpLrjYO-IQPfZNF_ab8SX$O{SHRvVu*b{H z@3i1E_#O}Tk0}tfOlCMomiLI4q_tg)7-){Ta^NzRN z?=q*V&v77eD)fO7FDhC_h5Qd5ah~_};yJ{s(u`gC#n!}D)gKEO{742%%>(=hglSIV zu{Hc@`hA<#L;3}y0!P6zzRc8nNSD&l!g}y6E$g4uUiA|;tiMgJVnGEtr8_i{1cjCG zK>bE#RfAW9rC0&buxaGT_#FJap|BmRZ$QigRfB5C#HI559gxk*-4Ny^q{7V_WNL0? z@@4+dZrb`HwxNe3IcwKNPtcZSivrlkEgP$?o*LcIw^6K@>>z;kv0WX*C+Uudu0)IrlZNbuNv*sf?%G16ZN= zy7BMTRqF7hzM)|*CA!0@<)1`b&etq^!gH+o15L{=^mL_z;_US(*~2P13Y;o85YE~+ zEih=Ej0?*4$*MDMZogm=%%A4Y323nM_6NYn)3Tu_6%o*AATcSLFO{@v`CTj*b^ot@ z*fUkt+6iv+D6ZN)t3IM=M8#yqtJZ$TuKmT;Cj4*J)C^!(&E~ZUCvf&S)m(<-0oW1g zuGFvE{Aa+u8RTfJv3_F~+SVXPE#?sxH&eihD$UawCE zZ!A^H5fZeXTJi1-tq-)5?#JDhnla_n-i42%8bv9^$&aJ@6y<5vLSPC83poh#uITeI zp0pS#8bp2cMpZg#R#s#VdxjSQ*4;u7M^odeN|dJyYoxgddcU01s8-)ZZcxiJN%Xps z#OF{{?iHgi(X7L#PJ73mMVoO4chve-a>#tF9P3W*Q|KSAE!E)z&}=lMQ>^ab^_e>R z4S|e*r(3_W-$t;OlTy7*iLHeG7!dD4JhiVpYKB|K$>9LNNbJG$PA$&rM++C+n(-( zu5^rR)?JO&_DvrjcIqUgbr~B}zRGh@nUylSz$J+=i$*Y`Ahi;j4h<;{4k*R++AB6sC*7V_SN!y?HUm+`5% zzt2dn{aFgrO43m>r!Gmtc`^`h5Q%w^vib2`+o{OO+@)c06U8=>dX7@&mTC{`FE|ur zr9kzmTyV0|rdO-yq|qMkKJwy~Q!NiH_xY;gxC)TRv8!FX{9R5SCCpbd?hg-@ZhEE= zsVUxI)_V`d4Ra^iqgJjBp4J-GbaQT(-rAq*YLZ8jl^V%x!)(+yPH|s1a^`Q>9ZG@S zEdDdmb%=yX2%X7hy+#4Cm zKP$%Ml|piHHiOFFv3&@(Wy`B2V-xgyzf88aNHGv2q^3o*Bmprk1uopnFAFxi zsRxl2B>6;Btg!*)cK^Pc8RFA9H*j*L!zJ>TG_nMGpscQ_x&bj+7-$3chN)*vNx7U!ip8Ubtemqd7^ zf4MspEQw6|KH)3|R!9u=d6filF=rAP+y^xdklgvb**r@kzVi8q!J9^C@&kf=OyG&hY!WL}rmK-yZWD)9I;FmY<*ltOvd z$1d9E+3t8S3cTt;m1#&T4>e1p67oTRN!=3Bm4=!<(9zhYd(}2ktiRbfRJHtJ*QHlb zV>rL)dz{Ag>Fo;j8CZW_J6%{!rLGqI@n;;UjBbU0Bx37^E9IQ)oaqSbNJ$4Oi$-ky zL*FsMK>~ojlJ1!2M%gy!gWPZ3d6d#@gw}y*^io)c5KK&Z;9KQcn8pn-mrB0yGoB-M zv-;d(ogCHIf2j{OnG)iOtt~KI%0)}z%1Ji07W>*S+w&T#5WatH?Xak0iyWli=tjkc zq#oy!Lw}94)xD3FQ8CF37B>yIsnKd;X!sb<&t=5tQMdc;#_|9g)nySKzTA!}Ou_=T z=hSaF%k)TK#%jHB_Zm4k%UGlg5rk+dB&TD?aje`>sz5^2CL1hUe3~mduw~BQVCiz1unZ#e`nE7m0Xq;Ax7Jscbv zP-QrehrlXR)p$~iGt6U{l&f!XRMqwUehdp2t(_&?m;+N`K%yQ}(J9K2#{b*<*{b5p zUMMxDj%_Ed?N6epGGJV@0s!=4y$o8>vs^{mJy%mjLVt{xMdO}QgcshP1pK^7`}gQp z-b()bA1?rJinn?wwmlZw{KvpNw*Qr4i8>)fY+Jr-~Q$h>(@I>LmUJ; z6b)}5jCL}ALTHUY;U@-tL-Z`rr()LJF1jfZ@hw6wOZ9R@3270u)X%TWyPl!>p|!aw z6^r^^oEuF^bkA#KCDQ;Il^c{~#jF9W*)VB}rjiyNT@%z<8uo8r%WMZ#0_^HHU{3($(|EnGRr(aoLALS1X`W&sm(2158Wal zoovmcqo@G>v5C1vR?ZZ<;ihHPV6HHOP0{vLEz`QB%W3CQ%Dwl+H!NvF*jt9UnIFe( zsO`rq?FT!Sy4^662-r*gNC~{&A>4zQJ0108T&dE+C|bq0&RVqkiHoGuHzi4Ba=LYL z6)xMJx}epiTveE_C{xU& z4IkyD1lCUieRMv2e%I#U7M(=Y7Fogw?<UgrUBIrSt6bf1H(%?Da(#stK+w3imKAnvgnDaxC(|-7!D2rI!yZ;WoMh zaIR6xMCy*BxLH1XT;6`z&z;H{8TV2!x|xO zuz4b9E1~cE>`><$AnKKnYQM!q#lqszjmsCRUltoaIr#;M!qingwbE%OWk?Rs`+IV4 z2mbP=>HxoXkbDL>DjK#Zu`B_Uo`A~hqOB;jOD$pr;72Czs;@pyI7MlfPv0WHU^EBY76~`di34xxg&7$ zzh3Dul*GP#8$!TJaoC^a`SI$zuG9!FkS;UhNb(hD(Opn>o*OWD&zZ}gzJU4$N;ox+w(dN3r0lenFCDhUp>xf=hIo4hu@*)va}Lb?*^N?*1KCK47e!Xo z0Rz^$BI|hCFP4I%cQ=U2R2}yApGTMDKo4W_&9AZqw|N_C*vsY#a}GFFkZp-Me{GJM zr`w3N37Pad*Ex5CGAZ;p4pr-^JASrshB;aAR9l@sGG^iu&2H+2j({=c}Ttjp~J`F?*d2y5y#HgLoP*dkH zA2Wdt|Mu9uo<ZqA^ves=n`m`{jLgj*a z-sV+JRU9aflt|FE8jqdN+&nuxGhcuz&e*kbuW*94;bSl90U&4}Y8}``=faL^3I+Bl zb~2vYxgv#9P6r=n9tpIeL}A>JTn6S;B9Tp8n~>L@Wq(6A|MuU>?Fbsevnb%p#NH;bq|GW1 z0T71d)KGoM)MQ|uBY;wv>G>7cRtao#oPE zi-L^vDR)2m(}{JbXvzlK@kSNwABT9>Ldqu;WsIlKr!X?+ zUw27`kr2N96o(rEC3ppX2sRPSX+zPXz%ZmALNbOP!%`tHF_j^IN*fOQ(E4|u7iP?Z zvqrE$XdB@Ir_$losmE24H2mX@;|?ih0Mai7Au+U#ytm0>|6mi6b?Lz%1Jg2Hs00(0 zjFu|(*josg1d^lG8ACPHhz7r%Pd!P(G}oeOQ6|!=onY*q;Jh*9;-I!FL~lt{nBQ^2 zU7X`<&YkmcVlAU*wTv5|Alk zStz6~4vQ`?UE;i9UVNy7@_f{V-A7@=Lv4V;+|vN6^+eM&^BrH?g+$NW9VLxw62nzA zthi!eUlxyl;D;cZ1tiw0@NIFJGpWtIoaY&`X~l}8d8TpiN5AEm}?R+(OVP>Ri_&0Y>}wLVxqB1Pl`;u#wR=^&cWO9QcOHtWFJ&tCok={Te;;+CIztKG0zx ziD!Uv;{3f$*u!*QTd~t@nwea9>t9~N2r0r8FMUni+n@6e-$rp?muW;}nhK@XSOk)q zaOZb7#tr#ftP^zbrJWPiR=hFF)LBli9VjK`w*G{MT9^T))9oW1xy(~R*Gk=8AV;<( zp+ALG6Nd6c3wPT<3M)AGjv~>~H z?v;X<;@LZ_Itm;&%By}ULi4FRg1fMOcfrf5s{6z_e<#sHc_j68iX-4}!2&0N18n3KcN^WrAx8(mh#fh|T9-&>g4n!HtXK$0CIc`-tv{!GC5jV7cm zjJKz3z*#BuG!@yFU;eO5UH&-}De6aIY5eAJ>ug|m)#q{6*P*VY)Yl%e+9-|nTugIO zPts~_eYdxwk-A)gOY9DSybfxn+W=Y}QQ4MmM zm-)CxfKuPrQ3-rMfC*TqS^*r)C3Y4;PbMLYz;sM>n(b&9`okfA(iS$=YHih2G||2J z(L@(cKUS;tx&1Q!9KB#<*U{g3GO?L!Rc+Ksmayb-iq6P2^`H8ZPlnq=z~LwkR5u(@ zfhJy!?v)ml-R^N_kd>XW_7=mM+p$kK{hZv zMmc%@#@<-2bHfTZD=@A+N)~y<+|LjC5&}=p{y* z??@#Kn`)rGqdYLhb+^ElF6_GfkMAGR?EX{RG616G!#R3^ps)2xGD(BHe#qrBUI6E@#r3Uw>Wx*4 zd0GL{n3DNL!Xzu836bK?5fm*Px}1hr)F2K}bdx7H4>VJE?3J3DU#wJGl;g(^Zcfq} z@wv>{OiKp#Z4J*Y6pw~xXX?$k1Hr1-<-nwIvkGR_WR>1G#HSdQfdjS<-B@U}ycc{) zkHnbq!SqsHNI?dsX0CL4bKJm!44h+%3YlKDbdFrbOb(-(om_Ht&?4$L^H`-oK;(x{ zK~hJl(~0NK4OX;GMT<2mLmH6A)O-ISgr~4|%7~dBf_0=`WvO}(A+DH;T}`^v!Ar{j zRC~Zat?Sns5uO>D#M3S6S1t%2%o=FERLN!vx;#DYXQ|`4z?FDiar<5cP$4T)Xn+sm z23xUk0n<~gAB$6YI~CyvYspj{lT&0qZ*Ia_S!GVmVo=X%<8a1pZ5tAAZnWOsm)L0w zr9bjMiW?5=XZ2|sXY)yB12On(2aB@Gj#D@c4uG<_9e`{XR>C~z{?c$c5LSN*zS-bz zxf!I=aAUcz(3KKD={W^a8q70xsK@2R9`8qYBo|rTR?-@$CMO&{&H*dqo$G}lA_68= zPTo#O0D-7TIm&uT1BE|%Q7h*1{nbUsKg2Q~gh7h(VIjDYRV9>P!Gt-3oHm0czqC!& z1S%gT>MYCBq3$R@)hxd$s>w=Zw8O!|dP+Nv8RJ_B|3H3nZ9`W}0M^=N==vRZw)iLF z0=KHMlR%4sfpy8mWdYc2v1dIkIC`(ENcc7lm+@JwN?E5bH zP57vNig8mX-}OvX#&_Bqm<^ZWvi&@-F?iBnieqTD;&40Ut7QW#evuaI>-NsFk!=(w6=`ibj(^|;ci-l>(x&SB zc&fVkJ23|smn}w_D*KsQWV7f22x04X_KN7u3FN>6Ko zD|lQ)HO{eCQ{x-8Ou%4mP>;=q52W%{jHCq%FT zi~k;EI;E-cE~ctj!10q7)MZqT3PB+*oaYXYde8X}(7W`W?raLy8A6uC@c;I^_r41SRErV8no$5O>ipbAN37v5QK`>@%H4C#yjr2ja z{MS;6C?NFsZTdg4U~BNr+|D}!7fX*NfNx0VREMY+LQUWp1a-qD96z1@;Mv4|_XEl} zNV{`APb8d61NH<$hfR&A`Fa@V)tBm)T#LGSL;8$!3iYQpgFUl1TJ;$Ac4o)@;CFtY z_%G+t&iK_BZ0$8ti7wse0`n8_RN4+O3U!jW4A3dl^amUjFlt!MM`k)gY{Wg@dVY4f z@n_x4g;sCJRA!6q+E0XXlAp>(Hhk*g*6!lH2@w9HuUh)ZT6Y;{Lo(K$V@$Uui7DEh zB51|MOw(OrMG*iuaSW=p+)f%fFjk1pHLhrxpvkpem))cQRJ~qzMWl-)HegO_B&Xm( z=6SuM9Ct$C5IcJ)xI56>2u{CeeK?E`y8^W_Ufg}r$pLhZ)AJ=vTC<*QI=ZII^D#c- zxq#UGe!*_oc$s{;Xux&Nw#Y1om!5Nrhlat6Oz`hKYJqXxo1&-wcXsVKM3iWR@_8`k;B`*q+7&C z{C<3WChr~KEmG=^RB*p2)G*<>1b%-~`2O>JMFitUbiGP}A;88YuiUck-ppZ6i|R2L zU^it{Rryk#LAqXs63|w7b#?yFfrn=D9MP!foNas=Wf}s*UVo&A>n*kvQuHaI(e^k1 zd{}!lkHlf$2q$QBm4VpI>{@*bK&Umj*{#Sd36N!hnCz0a03Y9%V0slDMOz`i-w$7h zr&NQQY*kbMxvJ(#jq(A6-aP3~ZL-sp{~A5c6swob!@=LWkp#hD29xazI^%F=8y~EA zPxgToAb|a#AYS9JEg9jNR} zDC?nBWMcWOBI|-o2#-?lt}}+E3Ig7m`4)GmUAKYRQ`R0$lx#pxThfr48K?8%*B@B&Hh@Xpfy1s~fri zC4X@ISMp;US`S<{ZP;e{tVwdst3m(N+6{`xh;XcjIMns-NAiEVpCB`0?(42uXEWe9 zveKB2@%#U?I#_}gpY#VaP%}Wf3(28SAA%Ng1APKdJ%-(vqz5nDv;c01t9@u zuqjHO!ps2BkAus}_?ANn64vT|Y{Y3HCKfDYA#eZE%UA~MtD>9;eV)j_CXEV@NM=2^ z8s+ITN$O4VPEEFNun;{ehOR z-Z{)m;-DJcLx%4QwdFCk3?mklDtP*2X@@sXC;@l`*N)^LI4mvlB6ij(5hDn09rkA` zG-}T+pkKDℑ`AIAN;u)0xH;&UFXyL8nSUNYRng2^Bzw)FQQI?p^^gINE?45WT*m zvnq5~YG1RH=3UwT=CXs05>5NU^4zOivAM2B+0clc1v`LBkFoj$+eTqI@V=rIk@&go zE41@|$lI;pxKCn@C{0D(p`S_0S9~wN&bi#S5}Ky4)`k-~CY?cx0Q#(O$-646X2A>= zi3d?ktTDP;nRCIyIvAy5L@)L1#r_+bef*lvDa4pvBwE=7P`^AG@*cSzxxM7R7}T>) z@s$Da`u&&00EDk3zXTv*`-V&&e8Y&^1j)4hD(ZBF;c`k&KsDZ!CM1JAWEP#XxG5;A zAi8a#QH!0*NWBP^r4>$eSTNW#)S!*)0#9(e%-a%inVyF=a(qmu=@ydnm&MQX$%mVz zYOIPP|9(6D$xh-fZtah%w*2@;-6|EqJf|CpyJ?a+ja&YKP=6e2*9XC3GwmD4#0Vs- zps+FjjtPN4E`iCC1w}9 z_L*h092bfdxrecaJH@Z9b>+?tbYAY2j?L9@p6w}XeM_t+2m>|5`nQvd?}AzjsR6qQq<03C(Mc&i6C&&R50@A}t z$G~hews0908a|L6azSqwp2-z%iol!wT&1D0uiD9BE@nay{z%}UJ}_!$-&L@BuZy!< z5Qu+sm2i*0#XSkOmCq=tHt5xL6KGj}chr|x_AlA#;M{OdG=)*gh@hVJ0Od}daEA$! z;x=E?tYn;Vq_kQK6S0OIRo+QzLsCwark-K&yrz71=Fr9~llmlhH@YQv$mXEv$5fb& zqDzKT1~=|I0LWOzyRe?dx3jrj1yo;b1r3~!tR~70^E`IWcQ8AaW~sz?gVu^8KDN6S zwAhjP#*99`D^AU4sgChf!@XnjAGuf8^#e%pNQ0wLP%$*&LKxr>hrOO=_+j#nJWm21 zFGgMeeAv5GkWD~L`adY`cRmE)I8glC%~3m$^zIM_KyD>wGpOo`@V%m2I#qdI_H!+a zzjT5cAbEc)P{UaX4XnU|WTsMtoDiNq3kcvF8|2sOHdD(B@eKXjB)U9*JI8vq4)CQF zbUFq&&=ewG41km>K1wF!H~~Gg1f@)nk!YSbfcJ`Y5FO<85L0AvZ_o#O(a|; zuuepQ`4mc1p&6!-@&md%JnF#iM2$D#VlmI$CLJiN88EL8_aZ>;?|T%+IY@_$PU&fN zWsG94N@UwLd{xiN&1Db+MaJ3lDfxXBi71*$l>JSyvXV9Kmo{zXxfx4lQ+FT^vtyD} z)yNXGZk=fEzx0@ft2fc;;>)$GhK3xVd2xAg!z0eIRe$E}Cy`6Cry#tMde7K8d=(Ta z9E)FtWjyQq{<$?NB!!KwL2YV$pOsRoACtF@kukE3wcmr~*@J!V6q*sqqPyM5Ni`Wjxml?bpIp2~lwX zQSE{fnW(3|Q9Tb%(M^f`wwchuc|zb?XPf16+3SJF?vq38L`Waa1#^>ED!@|$7sC1| zGXmYJ8D)XS~CvvUESy;b~)aOa!R>QCrEy3OJ9TF#hb%Xk2rq7Jru#O{I6tI5Lv?_gFgHw zFnO(-5C|}HtAN`bZaCrd)@@k$!JQ*zBmkQ)RjB53>UJ>eb9yc)rvCsX3q+)W2SE<} z%jtT6eOUY}f+2C(8=}vRyMoR(#va>Gb|7xvqa|$X{L}~yHjY`0Jof$+N+I>H|aECMbTK28hze&LH^q;$zFB!oW{Rr zSDi(+Kg8iZndfV}enxBg*8h2#FP&8>AN7Z@%ApsvjnL}No4&aOEQP+O%@Sd+FEty6 z>z<85kezqMwFaG(x9;k0R2PpdfK$&kS@F-rtx~e$r@kd&-z91OHf}LD^wEB9C6%O! zhQg)fbAZnmaXb;~3Azg_s7B6e%7q7$80chz9FyQITS70dp zVX)y?G34O}CyHCk@KA$%oZ<+Rd1brIHWcB|Z;E219p!tEM2lU%Nt{29ImHyN(+%%) zl3pIVMu@`JE`T9V@403PRfqeU?;DzmWnqdKP2<80NrWQlwM6ie)lauQSN{2$_tlk4^a@@*b;6+4yQcx}gpG2&l&dYt zBCjQ2+>vEltQR1jo$P3XYS5uH2eFC7m47z!`qGc#i9WmX$vo~aRqR!P+135b4HM1i zVPZU%zZ*Yv(v4xy;_JHGCYYwV(8sqjJA8Da8|>r0K>e%CrhnA*8~5ZM0+eEHEOq~W#z#M&b0!36n5m={cO@_yH`SMK=*_Du>zwIka>BRQjJrfgtn9x&ynVR$?$F}; zgj{}y_2K-XW*q+O^SYN^<|gI&wysr!T)}(hyDrO)0l!41N>Bpikqw}rHUiTFzV%0y z=e)zpn&0@Z7W34{K^l>BZ$thnfDPlfqdP@PG@b*{Ju=W)wBW2RBJkptPH%%OiYp{% zjH2aM74e|YXp8TF9x8r^I7=!VBY@1+Of@t2qO?`=HD>Lt5oU8RDI_qfTgUC7#z$k4 z9;ovzPi^mH6V^34%h#HeaPylxfhT!$>*v=~m=Q?f|3S#A`^;;p# zvgrTXmgoq8;M5Tt542yv9~!9Pt>EvJHMz`6MSUq|$`1e8W zxn}|;93@UxjVE0v_m7J7@3POd5w$#$oXL2${t<;0)l6wJ9Cs(3-^pEBXO^b@HJT84 z5Ce{s`zu+^_x8uFNCA(g0gr-S1gX;Z#H{@@Mc9_VE=b!3IpG-ZGd;dcf9gaF$1%PCjBT3E`|41s#@O-9qy#yP9Cw4T^C*sNl zyK%O`#ri-0`|+ul6?}AGaaD(>{>R1P-{b86B(dMV@1onTr14O_J%j zcm@|c?f%E!;}##`+y%4ckBPJHZL5YU0h`Kg6Zevv@WSOE3oPUq_{LUJjhByN1;?XR z$&WR^-it(;-KtN%7cN`Am~9DxWs-|VhlF{U{X@Lv6@|zpv}NAj;kfkPDwGA`xSzc@ zI|2*CpGbUiht#o#UZAt;JNIfEOM6A5V`#F*G{tTyMJBjUVk~c-a?I? zxiKXq;%~Xpj=YG^NvC`(AM(*6-9w3SW4GNDlY76>u`K=?1Kd8%v)AQJj;2=^qLVj$ zG@H!*<7QT^4RLFM#Kxy$D=BsA^Sq8;s=!BXEa%^G`nA*fo~|~f70X{OwCg^ zz-0$8BG7xrga2IY9`DBlYAYQ51a9wKLPR6MTd@pN-b1gICQO?7j^&#%yt@o(-%K=y zR2Q)yM>*4m+P`rmS$MtF4Q6CdOEJ&^|Y-mgh{6wXV7B89Gp)VX= zxehcWd>R8W{fg^w(+fAkC<2PQ7bfptX(fRjzh$mudlLjo`tc} zWA4|BS_NI}SKHVYm-d^ptJV zgvj+A!N00yVQ}?~S*HSSyP|oUbCW~?8>#PgpyLXN4S4V7k{TfoCVzDU2r5~3!+9nF zp?TVx$VdqjSV+Gtw0(j7(hJhqvP&lqb2_WZF6(T4@=4{(Si0sYz3M}E=*kcs*5>(r z{i9>SHu=1p5nj3cCXf3;P8+vc;(#4s+FWt$n@oE~?sQnGqyAN00ggDN8#2liX=UL6 zcmqSNBxCG6^%@(p&y$m;&Dng;l-MHezW3-+bznBF_#6WsRtiE0v>nmq%EH@{rNFR% zoIC+^dAqEAqA#N9VR}K`M$e{XwH>juS|QP?p)DVCj%3 zz)QLpuV_1x9}W+_c0$Wn6Q{dF5*tt3gp#?uqQ8+W$8At7#R$g^|G5e~ZlTqM38#Y8 zlyAE)>zqO`k+hw>7zh03OYv&eolkEUiPPO=Qclp*&-=ExQ7ubEK9x~M5^%ov7c{+k zsGWSDLrLl-XF^5JZY+6M;>muu=ejLJR2gj{i&RkES3SX~v1l zfa~DN@st}m^ruOR(0*MTg)#F92Px>s!HrtGrm36`UuhYw{ek_c)ylW-v|wsSNMpNi za$nw~lbBvgXyd8hAVPF1jQQ<8w13UHoU`(E2h63diKQ8< z*?qD}Bj1zRebtUQR+IZ4#u^SKU;gu@5ua;2Yno-V+x1m`I3}7TL;#a+WgI0dj0c=1 z)$OGw`3rlMLx4j>u4ig1d{ChLzF~1!UrD3AHHZKCLeC_rr{~2l$SPy!42aB3*m~C+M;$P z*pYa-ILlZzK*wo|g}yFANyV|mggwjGm4nVt}fC^kG|}qCBA4riz1ioF*HY< zlY%*{(?)fJe+sMyF0`bFyK!jcUNTey39CpWM3eHcEix0~``JAU7`xr^<(4jLGSkBQ zj#JTN+iauyaQE!f{bO1kH-?3iw!M`|wI#H&M!1gp7vT1VU}Ly9-E6&S$~}1WCp(M+ zJPX_d1SJn-sz0qLZ8xbG;`=cEgW<@J{*H%Y-3S|pqH`09GR!QD0! zSmrNfM0yI;6r7tCJwSMTRIOHN`WyDM2=M8rR)m#V-HVCfsH z42+2viN?2JAJentli>jTC07USzfH9M_d*ho1f+6jWk_0h z{FNVn3FELcwfXV91f}<}n?_p2%jr_uJ;T>$g902OHxuhakm0J%0{sNNd3l{EfrF}5 zqFqgiU(_wlc8Q$9I$lS2$G0&N_|U8-%QAd1^PNSunT?q14VUhAM#C*{Sf&bAnmn#!>kOj& zOh}0&rJdn5{+JBfWbi}b+qq<-%O~H)N@F5(ca^RPxBAtuJob#%SB0v5-tfKo z08p{jDgNjUQm-}Nsa+9QyG&RqS(4Qc7b_zoW6HFg3=ki6IC^{fI!0M(WZbV&rP~fS z;hDr8IbWE<$<=q~Tjxi6EN@M_FB4rgo9J|HZsl*=>Bk1S&5qjnC6-0K zE+eW@x1(hG`F>lx16(UjM~v;grG#`FSJRHuyJ_8;9z3%)sEk|{x?g{RkkdysUn2(h zDQ;dr`!=1-7M+z`vz>p|87@p-iz`JRJfKI!@O?SI*<_yKmK=gKb_nwEyU&wm*_uy1 zndxQkXs}JIv0@(nQP%x3rqxqsd%b%6D99R<%RRc$P^P!;M+MJip*0^<2(Gi~wUBZy z{wKar7LF3@y;{0E+hRZl_rJ*c>!_&z?+Y0HC`w5R2uKdyEge#VAl(fP-QA%ubhk*i zNOuh&IfOLQFw)I1bo0FZ{_g$bx%WTTg5`3-yw2HspL6!kC?3x>x($RNcEbR$9zP=Z zLhLg=DGV^&<_e{5rT7F6{pqXo8c#@2cK~yyS~)YR$AUVZh)WaP`)hWx=-(fT6gXAN ztdUS$3y#&*T*PjXZW|_3$Y@3V#!=kZoGWXA}TEU^;1P)+-h)K@7=uecr%s5?PhpxvkXwCGvwUJbMu$h#(s$SrT}lyc8W^0}#97n(Mcwry_Bs zdA`gVFC+)jv7~61Vx~c9clJB6fr8|VKD+)fl??twD^Z2T7kz;e*~5QK76)~mZ{~m? zjONH=NNk9gbCHY(?dfU(ee1K~X?Bof*G8Q~)Oy}h+e2GZz-F&52RzL75t5cehZx7R zu{yhCR_dK?^00u3U;4I>zg<015zX!2^r;X>)YLRIpm`cPOz&LP22}XW#v-}ahA=eZ z?&U3Qo-{4(Xl0&_o_&O;*DOeo-C2t|MV@=Vf8^fC%GhCfrPy^ncuclG-g9IMIEF9& zCZt|0ar6d|M<-)+1bfEL$FA;{_9#t2_A+R*Ch#?{#$QjDxcPj2L=g|u3t>vz5btn& z)#)iVo<^V%n2>WIJX9z(6}Yi@XJE;=UHx?)?CGAk-ajHMi25+0F_+tMF>H4I$wvAC zX7T3ILSweO#e3;buhMuYd7%GDZ$?kqjRQv%Qo?-OT*0LXONpfQ@H?w7+;eFqU61SD zqJAs+2zEEv-7H@>i~02reN*4}<2Q>>p->SDS>`!H z{~Au#)GouTfC=ioBYvm~kvGmG5G_*J4IXDcD1<>y5#N+Pga)J;$OjFuXFtal`e2(G zt|SvMw&0sugxo~niW7Kt9V%x+H^j$pY4p4b|CfZ}(KB~{bIjPQQ`OnL#cwgo{%{5N-ZyWoqkWE!c(HiAlP>Y+t;Pow965`d^^PM5T#UbXR$XnH#fAKG6|KeXb-bouG>eqw> z6ql|P?pu!l&(5Ggdm=F+qI$>9ZZ_J5vZa!FQ4;9G?sj+&75$8&S|*n|7Q)K0(bXUc z4J~2vsly11IypP;P;CAw)tl$FR7v(sW&DSyyvm!O5PX^!-deH@T2&0I0$9_Ffd^u` z+Z(u3I7NML@hOR3wpQ>4Yt=LxyXQFP2nLkto@xU&3*n(;p2h}2m-GC8ws$aGZhw!C zw>QdVerR_u@t#(W{eii1e(+|xvA^X~%*A&>uP0}#3xvh-beHy9`1VUGj`7pEVU9d<*F&P@xyCr z_M)9?ez3{HxPLxu`#;Bj?hq>^9RF64YFoY zr**&LC4@&9f35MKl-m;9xl>CrutO;9ow@5RZ!YVn@x8{1?5y9n)7QQK%Lb z)4trcLEW0FNh`pilf-b!v1H`8R180dETNb48?tx6y8fe}cFn_C=?8%HF8YU_Fn7yS zB(kBNOX?_C!=QyLrsS;iPLkZ#rCz{#$L#)n7OMz<^ zZ@z#i9wQc>tNWbA8*96)xi+uGS)g=w0((tL3slrCm+hxHzaLFUt`>@k(PL^!#%cW` z#Wu!2TPX~g$b^G(p2pnojyUkJ(?mhl9l=9G%C7}o@R)a^Kxl4m-Ti< zx!Lh^#eX-y=a-a|^4aD&NzeZ3{y5mtJ}Qjf*L2TnGyvtFT1=jQVl(64qWrwm`1wx7 z54sY_m}yCHS(UFrE~c^Ny`yMQgkuFeMc7lU=<{xnI$a>R#m<#;kXj;Dq@FD&O}jGh zeeD;8Cl#xkmpUD39rWgbwObhK`y$jVCiP&Pz?23?!2z$NHi)-?LsVMXQlQxQ-6msz zE0rDRf@)T|HC0sK|LW=uw5Ifs=AiC?4&QI}l=V{ZP8&9!%X&uEPU*WHp;3jAP%&s$ z&WRt`Fq^cn^(n0&?xv1AA1~8ag!B{eZ}anV?GFT&l7QWA`d)4%!MPqzY75|-cUT?# zjg?XnS7{uJv6N*VwkddW7=n*EjJ;I-EybA61QhVsy{my-n@tb41};y(hcP<~yFZH? zo>b$RYEs`9{T9wVpSZcJiYz@(6CIgRZRuSP-+AT^Z1ULrKBeR?s>P<2S?Qv*d1pB9 zfAXe-OEP6U)==dm?I9a1_S4+^iU z?_w@|SGIGt7OqB(=f(ytFsklvc>p7CeY7SZ6J-=drH8FCtd@(7o0zS?Qu1 zqp@nn@I~=&X>W^pK8tBb%D*>%o@z%Aown5I5!vHjxqJz#%9)l$`8Yf~_N~wYVY%ec z<%s5;JuFE!^k2d=R|RnvxT%^*w8nDrQgu#S#g?uH{IAhEUpS~7t5(eTHtwbvSFILB zPi)pk5xvf{zU*$D>`>EEEU5YS_v?;?zl~Vy@vF2$W7)0l z0ryrx_N_wm1*hiS#d{>pN?T;@bMrpNesN8@OEHiVU_1Ef@8|oak3i_r^R;S&hPZZz zr-eOVF_TcdYH-(v_^tS!*ijQE$XKU&JCN-GP0fJL#}7yI>@1&G5CYG7ZxqH>Xv zv%MM``4H$rUfV>)@U57EEJe@wY;Ilt@rXHY)0xbf97XnfLq=-Az>#?v&cy{{qLE0)rKsi_1fQB&4k7xSU-u3 z{u;;|6AExq?-QS!4@-m(di9G~p2=>$hQ_P5Dfe}N~S(6gAdZ?DE^_8ElNIu<9E+w%82{zTF(*ymQv=d<@)d%W=S~Nq6ey8w)j9h4 zENuJ%F=n5({VxWu>Gh%3IoRTTFfqZJO@_}un!5H?XBAx{U2iOn+|P6ln+|&U$=3%; z1v1lOh(Md!;mkc`|Lt~j@J5UR6P?KMY{Kq{U*a39oqLVXj8;=cqT*Qy zF>%RyNUYCikn8=Y7Va^b?YEYp_x3Br;0U))RH-u)TKJh$aR+su8a~KzSaP-XcKc|#azKlO`W2~4=WXxPZN<6#zv84L6S2`!|LdcU z1!bIRDloPXb8W-%aH#t@11>eAWB_2tK2c=MXWS^pm%aPo|TsPR#a<5 z(JqnB$yO>ELS+~yEwt)VK!O?C)@y|GL#O>J6P%>|n~Ndg@K8zfzuXV4RDu8rCOO8? z;j}-(X74-Iorv7A+zEgawuZI0V`T&&WvXeJOed=dyVjGihq3)=n5y>fOE|ai2er*t z9Zi`I1P{IntyZc55E)WEg(d-ofQb1*1l2&M}CQd9#=X z0>)_Gfwa>qJbXI%9M(XsR1m1|LhSIMHu&AH!OHhQFz`I06g^Ljvo0p;T|NPO#b^h* zpeObd= zj6J8I(dIz_emNWyEA0_*C?Qwf<=$XcFc+w?3i9BY5O$|gd}s8B-Qw?xPPfnr9;sbT z3f;~>O_xM1O!cWSJ*x{1v^sOGjTmpj@FV8`D^PUL;(4k`BxP7#{nLQpHZ!7Rzomfp zFazBy*VOhX$TwaYVEaq*?4^#iWRl7>*;(YkO_^1s(ug?jBA55Gb60n+fwP8mykiTG zIALIR?11TEQ()2zRhfo(FVy0CNLGmdc8ai`-PXSA=PXvq8)K;;i(mQhGUUvDi7vzxNX=NTFt{=hRRiKThkgxuZCmpZl^* zDWaZotXAq1a?N_jteYllJDnc7$(Wv1&9z*oH2!#7$HALl3zXg#>`A{g2n{3DO~D(a zVfSa#B+e;93boso{)wm57;lNo)uGcxrq)AOsoV~t8~XpsAn*{*cgbkDCo)B8VHCm7*D8 zAfKrzNF{XuX3_vb#OwVkCoC&KHhePvk4E)2?ZA~%=`nAUPmRe{K>Zw$l=Z}@C_~OM zhRaeKkvzyzKv%|hgAMSH1~xQfHxqt5*!5QdH-+mlJq1~-%SFDW5qov)XL4j1q?z&S zW=nLPR0V+(fjh;Sw|@=YAHf8@++Jd&Xf!v_Rw@Xl8mD#nu>AjpkmekreiUr0;Gxd~ zKB%Bk+Aa#u`z_L&@3}|mDt1J}$`J3z#Wsh)96T85fdVqCQJD{tZE5owBF_D8n#LqY zxGQsa?(7y1K^Q`CXM9#^XDvURF_oddC5O+L^)Cp}X`ieCRqdopm3&{9lY`U0)FioS z3nP0}~6t7^{9ZbSTam7W7`vik-!hI8tgZp`q^2MexO#+8f9 z;jOi($i2@@&#a_8wn8scpCOG$*mYaj)E>Wo71kakSoaLzuiPM}-~1UStQ3Iuk2(V3 zt^G~|i93P*e|~-U)ny*g&Kic|M&3QdpNPwX#F-+ zI0<*VHu&L9!y|y?l#=24*|}~Ou#(HRM=tHWLytwmD(Qd3_11Jl@bZ}Pv-_Lu-EJ2m za-)ceW@AZBDy7n;&RLDNMu{)o!D0W2Xv#zGH!0dVST2+sgPH_3ErRPosKg8LR15f!I?jQE!oE*fJ z7TWD|_}6W;q@Zz*qvn|?RXO%11D3tKO_x*yUs#8Do8oY@b7}*e8XPSOylwTHfViel zv%1Kb1KuUEqCFMYWTK-052|qM9y8XtGmH#~XBgYFXCHjb4*j}5Nfogl(P?2I|1S@7 z#S^{r(wjwNu@8wF#OQlZ6$kitQk@FsbT9YwbH`x z?=|oRj9=$wqOX=ZyWD(p1g;XKL*K_Z{ChQ2 zrBk0X-b|5uc#B>oZQJU=_EvO3;}WHwvpMVoor*Zkpk3eFR}Qo}uJ#ec4L9N8Go=!$@lG?*H-*>{yZ!)T((Yyh2KaF=4?3ML zg)KjAXhlIUkNqYIGCV5m-SJX3VdkcpxIu3?ZO^I?|HTiKR>Ag=3%OFf06!|)4C6)rNI&V%F0;`Qin zRG2+lTHPr*{GVCh?V4GMh-vI{#flqBFVN5N5A34H@N3iDo`xU}X_ec{lwCaHt}FPC z<_~A|B}AZSm1$8L@dK{^{v|Ux>(mS{>qY+v%>#X+xMGdUlEazF{oKa9c(P7d^7o@)yNpf1tW2!^|Q2b z<6LA6YU2UeF?%K73uCiiCd9dvBX#?WwMoN2{XehL%l;N!&X~|y_D5# z%A<08sK!8$Y3Ov1)p#p&$dR(j_h_AX$bNg9ncjRnnG2`9pgg-TR2tQ(ryTb;5 zB|bA}TQuNOk-RS#$#pjPEumO)k}m9RTJw7nRDpq^Z1qQh?}My)(G1GX$qf=xfB7rz zp)Q8;nUBK#x5L(XKfelI9lInAiRDZmm1&7MT*aym@40N)&bEO98sK&e2TwN71D% zzT7Lbkj6jp_H&Arn?0|Oa>ae$D>O8#8_&B7#bMB*)G!7J+K{@}A{fP~#FAe_@X~!I zvCmCQ|A?WdmIWm!XkgzS)>bBwt~TLUxJ|CIRt0au4OCS6?ru(IAc+ zKDhojHFhDt!gjCE5>i`221TGZ~HD#LHzW(=1Bh1x0k z6VQF9Ov2id^wV4s--S^;+SR9+^&g-HgZPZ7o{|H*3aN+#Klqr4dQ)V3+S@4y+SI*Ts{;D+Y>PVf2T&_|e-G!zH^D>w4@vwTrHV%j%o zXcj=F-!aG}N0qFPm}?Ez=GzHn^}l#{YRypT;5XzC@ED$V7aSvMF%>g=ii@Yau#*S_ z)HT*ux$nlfY+J^NA{x$Hx|G?q3aVWUSHz2ncQCm@j|BpjoQ3l*!`DQ0e()YYPu2|^ zG5mV)bGj6rk^rbMsu|w;(#!HQ60L!0vJcKH;<9t_8D0aqr@UUYoxLsVa(?-!3q@ga zHq_wV9`%CAT4nro{nE&_Ga>Qs<_hQ6%(C};E(%6chUkQ2xe5<7N5O1g`6Ts8f6S2@ z2)xso2&?yT;}d(c=BuAroKi;nbh`IM0**HIhnTqzD;f?HvS&`%@E0Sdjw%!*<|qsf z{QMEytS?}EE0nXj$lK8y%{Hj^RZC_-k!N4>!I$L%T-pF@`+Hi8^{vaC7@73Yl*z_E z*v>1 z(u>7z=9);II_GlY4CLRnsvId(?$TI2vATsZZP+j4 zfT|E5MZl8`1Bt~LNI`sIT!H+qj1*Y@=ZlxxdUGKSJfP`D`sge)1d(_c1ab}4=_FE0 zYV42Ht&$h>{iwV!9*ev4U0roA4#_6*-^*lO_gyS0F}&0KpVqEP;OHI|#TDQ{4C>QF zD#qc@nj_L|53SIAXI+Md3sLH40;PRB9C~FzK~;*D=KH*$c_Uxuo2U$HQ!Tl$$anM_ zs*vaM1>dNn##f>?9Y3FtU3yED5_t>I;1T{O=8OoC-vFLaiXuv(hTEgj4Q|MjV z^Klo$lGGRA6Vc}XGwdJxu`h_XBp4E!UTLuBoOVzI}>(l+;jc;DH zs=VUhJ)ClTF6KD1_>9wn1&eex|^OLCX_7&hn3je@|}m62a)qyt?Kcsix_ z&-K=Ry?JUF1C67^ur#&bb|xUwFMxOJoxc$qXSmj}4YE@&C{${4Jul;JnuS--+?+M- z-3YIy=8E2YulNB$8RL&JiM)`n9GtqouItLcJ>VK5hxyw#E=Z6%Gtg7}RF5bS2rE4t z_9NsMJo~o(_4$EWJQn{hnbTu#;mDzQD)xS1%kzZnyx7!U=vd~C#2fDQIeR)zT=-9=KjUr>*qyh&+uYLKMB)wp`PJ00NE}NnO8|@6LxT?95>s`cF(}?`-6`r))q1jnt^YVkL74>Fa%NJv zQ3=_GIWljn4!Q#pwW=N|rw2s0f*peZ7+>av7lMh!nouCm+?HKAd%$$0|3^sk4lI>* z#*_0o3s)#7M;zPUC<<>!1j&vdeT)tL4(h-2sLI1Yw&m!cOe#O^!&;x~6bzNuJ>-oN zO^v_TFz|B$zU`7NTz>d&$uOTy{m<~lqT$zB05P9ysi3>PtV%~-Ay*aep>k*?f_nfV z#&`(PzE85t%vxf;sl+9{FGPYuz;!AFZ5D3zo>6#nYE5w`Yp@}-+@ub%j|}*X8n?L& z1I*ul|33Rs;s80e`W@2{#h_(nztU$YNp{^d1;)(pyKo0mVjN?9A~l%?*6pXC-_#-0 z&rmnKI>Z`RA zAv%U10!HpWUU~;e;3Ou%2SYpK2YAW4Cv0z!lNyuB3W5$R;i@=RvQpEua9wL{uY!05 z=7QGd+#5GMv3mKxw{I?l`ed7N;od#AyH*l^z9j}s-YhN5LH@m=Y)84_S{;*(F=NIL zGt@5%F=7~_ifp8y2H?plU=k(Y^9uODE3&Zri=t=ZxD0)%snXPP9r8iniJPK&^}EF( zB|iY{Ulk)*-5SUY>}*l=B;3-)yf~1brr2oFpMJ6uI}*M+^`i>QhWQ7s;a$=hxh~KC zgtT0u&)!_C?@T}hbK-$Rx9^9fLj6T%U%vfhU7bxydZiw5l6-22H-%|O43*4Ck#`RX zH}PXkC~E*q(e?$^TpJ!wY)MeSgHP@VRU(4y?$KOtGUNnZ|3>Y8q*+q^Mu6kdxmV)q zy>v6jF{rJxdQjyTNDczL2_?Fd6F-TTW4>wgZ&CZ^GM0k>V%FTtp=tTQ1EvS4i}G#s zM>Bte!M@d=C_AOd9O{{l9L)~t4kg@{(^FI8#h1iU_{1zJ~+&B-qTe<9K(H3>pSSE{Ld3J zxBJSalV!~4@+)h!DK^|pxo>uI{D*dmb8h=wm|qv!m)m6|01`~+fv>8OOa$)-vkDri zAKn9Ivg)CL{zh>h^3*x>!g-Ih)a_}}I-`IgZBa+gM(5``h^bE`Sf@Kw{HM(QQPI=l z>Jrl-9R8-8FzkQm~T{UL{xF>Q1z?Prg#D@ z{(XRaHK8DNx7I*ppk66n!@61fbz_w1pM5}z0M5iacyuNpEhOVw{jhCJEqptp&be*O zh8E@A*Cu<;*{pbvSDR=#Zj8QLR<<}0WwhQ(P3u1-h53&w5TK;SziQ(JWWX8C%5r12Ee)uHyd*q4}LatZDarb(}HQf~4 zg@+1+UczPp+{vvofkOavuY8)m?hv0@HnL^-mHgRk(efWh;WaBHKw zQfB%&`c>&9rswDsX941zzbkUk<7LA;zE7YdXWBv6)+0qNS!2B2GD#Q~3hu3S5W!h< z-PA@}-2^a^&rmXFD=os8rQW${Od}xTy3+rLccNgmsh&jzd9MEcV{zoc$80cDQ)Bt2 z?d`wbLue*Tm@v6ov(G1ie%(HZ_tE9)5DsM-zg%5DP|>Zv^+7x(p(> zwS*+B4sNlk!Y~jV<1hi z9>`p6M8E?KZoG_ekE44eZ0zm|pi#HRTEIxo7tKR6m<83ZZ3XEIKs-aa<{g4wF zxJw&T?6EO5WYV^Lr)L|p63^DDi$Nu-vr$?|X98ZY6u_4uabwMM6fsJ)D2dnr`#Ds- zAK5==rZSoQ+ZdS3`j_21hjGH0rgbzZ7yPwC7NhNfroL50N!$k7ZWUEM7FA^?CRqPXjO3GxLN_A!I@y&KmW?>@uk&u-xX5{(-TO{9B6&K~`BdIk zVyUrEHHvN)VPq_Cwm(_MDT2?_5!o8dKU*^DbX?PxDT+@-M5{iio|sRkXhS=Iw{wS% zOLA))GOK-CQ36z%bEEIx95g?=+gEBm{1K<>Ndx0Os;gk1szp6pl$^Rr55D;Kn%V{R z{2)LURz7ETrO@g;ATL~c^vZos9A2Z_P^*$yO9kt6QmgH{JD`D_~u9XPiv_x z@WmaAN59aI$wn2#w2HiWbo3nQ)@+7d5upl)2c1MVKet{BjGsTBcls>54VpE}i=wuW zuor%luqQ*v{%;SdI#!mIVEt{%4m1^i)&?twE-P$xJmikO`f$8U%a&0?`d9AS?B0)&01%0Arl<=>f7dzSI3d zeLSj@L(JRW>T_@X%>WveoPq8yKcoERG8(+jbYB!A_9YI{@=TAP-9=p-g{g+JR3zDU zQ8f&B8uFj06-mGWII}*MwQrNVZ&Y8ex3T;C`w&Cym%0gTyW-hs8=w0$GzYU~n#kqK zRSU>Q%yq!p*em7&Ru{Eg-#z@}RG&pp1MQyY@*w+m54kzb^S?x`Wpu6Ac&HLHDR1Dor*5*!nCVYm`qS@Aq-bo!DW$HWqu z0bYm`R2^vhlCg&gSDW;+rf?l~kOkwv>?y5V{~AMEfAOt?ulA+VB?1>la~EF%jJvAg z`E@thKk?R;Iznn0@7&648c3S3 zLOzCB)tBz77^7~RsE-V;n^1ZwHNCQ>((`pgN!Ez()P3*59stopx)tTMn zmN1T$);CM~#yFdGf}f^@!V6w6nVWhWmpmMUx1MpZr zSLjVB=||tz%(SY4frd0~Id;*;sHo9VC$5t!)b}N<;TnYB$fP~Px$Y1?N0CGWefKP1 zgCGoL;Az7T@{Bi$rmwNt*SJ$ZZsp<@Eu@s@pt7g_UzY;Z5uEp4zVTidM4#GaoqK3f z)8(57)uGuEJ4>J<0=GTvZKYC{qDrM*zRW2v3{SRq-Lp0TVzzNwf1jP-8}hf!~+-{kqphKa5l<<=*t#&wSe@Q5oa$V@JnJeC@Ks zhg^anC};t$5E1AGcp8IW|NK(Yr)G$_9 z^bH5}AyS)62B?Nv-^HV-;-Fms&K#$qtK5$|Er74ZrY|NX1yqXnrIaZ|z%bWGI_n^X z8xgXsm+Ho6>YW@5(*U@fdO^>YbX7~Oxo&7>m>XK)BpU(#6C6sQ?tYa2zFR_xPaUiH zBzdXA(7ErgQ4tql#-M5~G#WH`vdQ$iaGU>s4uWVPdZaC85jiRGsP!Fc9z*VerOr(m>* z#f3|V{lXhgk0P81&6+nV<_?fhp68tAoA|k_rjGBJ;tx{bM|kTVcm52$9q$3T!)Ol0 z%~@QQOciefw*m`ENDwna$Z(cj%P zQC%g3eRcT(^;=NxN>Z=bf2fP2x$rW^e}IMOs=Pk5=sCCoCLZyb(FN*Cp7*=|=_pLH z3BFYjv$ zwgGh7T`$R;RGtkEW>&=qC3Ay?)-v%bVgOinDChRLSQJxjW4d^|wDM00z7Hmdtz?>t zPKi(VxFa-D$+iNnC{S$Pbh+;dRy!<0P$F=ShMNRBxZ(2EX!wytr)}}2pK`|Rht3?w zdi1>j4!Fq)Mw=2Du(6?*w3ImVZOz(jQS$5H1lB0;r$wgw>Ygg&g|ea&W&~x!jVwA* zBgqvjz_vseb^jZX1jiXSwO@U^E56E#mX&*LYC=lkU?`{26{$}>c|1t`Nv2eEa@^S{ z+fw6}W95U=Uo2oB(&L7i0^~3~H-rFWPJ;kC2Sp5_!gQghw3>1@5T)O19SXma#qOqD zUq-$jNm@U@aMmF`3Vymrj{=pCSq%0pw^bVNMVt{inl2=Q*%n2)&utAG~D@c zy*XlTeZtG5X0?viri;j-%g^(pP@IC6DZH1!W)B~7)g76s9C%dDTQYc<>--Rzu$JBc zeg2{f=|qOUu8qREd*9-hy-16veqYwO-n{D*qVhi)m;P;r{>Q??^(E(C!lT?}Awj9v zVS77Y4ww{_sOK=cJ7!G=keQY0xSqCb`c~x3N9h){{~qtDtW)GOjDhHGC7DxHX|vMX zQjvIVPRej(f#b25Epb*Li`EFN9O@4Bm;Z^4^^=q&%FB->ci>$PaOLDplj*Cj4Zfw- zPsiJ#ZO_*suikJgEMdaJ!k&Fv%FcM6nDx_pv@z)?MDSwoD`5*a$?Pgz29+8D{aYe3 z-Xi8PMET&{T)0V-%QsK+>G2r;IrJGFe*S4-9u053FXI%9W95$ zKjWSI$^pAV;rR**`^NEsIiT3u<&}OF-;qrtrAFzdcSz{oqrpCV;kW)_rxJ~-ROue| zaGO60^qwVHE2!iZfeq3T8cNyXCb%5YSSTV#AmzKv>nd1?U#H&Fs(tIT{C6HzG-Cz~ zJlI=6IY%ckj&N&N5jKGi$VN9An`pGe&^eWU%r{M&Qo1J|9=0C{B2s#hPoC z;>2I?;L@=U$Dzz}rnj*8Hw|U||CxqzxV=0oL-mQg;)>e(S*9?Me~Nr^ zjMMl&A(8i#u@e*2wgdN(Fw|s;%40BNCL{o4nZ$FFGXO^x$sD@OGfQQ06P+=-eEu@? zUZPai&%9pDV(^CsrP_8kyAC;?Ma)b}bWQ-+GlvjVjQQ@pqlxjD1vLCc*16wOk7-c-S2=yC0oE-H1{r~H^ zbAyz#Wu8-?@1=-$JhOSuWsl$Oiu+2OU3eLL8~}9~)$cl}CMNPJH?g&4^f+K1QFwCs zIC^2G3$0^Wye***52mVIi&xT{l-po7*8_%;wthKfR*CwpE73JcaV&h%{^pZpoMU!M zS6uIEO$OST@PxwXK@?^i+hElzN|?jXJLulVK2z)WKr{e|2BY~bb8)Q)EREq(%8hcx z<{qkSaYbA&O+R@MU*G%kl#NCc{`&6=MyV(qi{tX#3|i|=7c)^<-9;u(8S{*3@F2`j_`!_aCVOPcG9}-Q{l3<)Mhmij51gowv0;CPAyD z(m@;TU#THsBfQH6@0;P>E|vBVxeeGmw^^YwYkKf-^G|w1%~k!O2o^9m!vUv#yTXX- z#J@p{LU3CWpFXbx^`Y%1Z`c5#4f{r$hzlcI;Zv5rY zPzAkg1Pnn@BnZF4PgdH$P^@m1KK7Ql^4r+FD> z!=8(BhI2gG2viHub&VXT35NepEMs*FEKj{o>1B0zmn$6Ya(+W;Fvy!o1AEJ?;q^~k z{<>op2MqD)BCFDb=-N8vpl4`jlt=fHnFfi)u0~qva<@o+vzSQ{`;9`8gl$t0g5+}e z?#XSpGcs`a9c@bYk6b^^|0^|~=SHHL{?lL(c>_8Qi~iu+m>auqJj1~3Otl-&S!V4R z4{xmVRmZJ%$rZR=zT9tlR9t=WN4oF5#)mm}*#2&SJ@`=p{uNf!MPzn7?gkU>Jp2}N zLyJf`!GLPW@TasQ*^K3`Li*9RIUNgBY}VT!E4+F>+k=9^Si+}e0VYC=2gH%VCB?w$ z!cGKsRZI2Xu#HXg$L+i&=uxr2GO01u$F6MKXwMoSJJ_F)eC*r)G8HI`A!-{pxs<`s ztT@)A&wgfPAtQ7V>;xsae!oY%m;UWQMT;i8?y=+#@=$rNa(`xee^KL3W2dT+*G?)( zPNF>fODmeh6}(3F!R<83>-ukdflpEjiu3;4g_16+9<i`JshvpxPrfS)t+8B#`CAWQJtK`@)1+3bu!LKk}d7hbq$rvT(X&0hU9a|+`ox% zwQ#yz(H=^}>6asmRGhZBwh(ruh%@_Q-NS% zLBI|Vz=<3?V+PxynE9eb0wE`_9)4BDkN}y4#g_2ywt%PxP1N2~5vQTEz;xWR4?zj9 zv8tNdPIDxa|7tFXhCZ`6FveAgUT1dvNnhFg=SahSwCySF$O4T~nDI4iKTD)m3R2?% zsg8b0{|2+3rH3wN$RTHD@65xm{RlMX(RgPx7vhIH{dA^4!;Kl~veE8(gsRBscGPci zW0Z=w^Q~l6GDipX{5xUkV@d-}pU?+Ctm6Ga-od20l|Zy&ijKBJpuH0)h=BS=mNNst zvpS1;46;5{0!vMy#-Khwi>e7i(CR+Le)IpfpcaSY+KWU-+T1h(3;|O~Hvut|>gm!6 zoW5<$4d=l-_^6A5#w}XPBiYkK)iWGEt%7CITd}5i;?uzjJ^CaP@Cv$rbW zt9L6eKHH>9` z_0H}O*|Ap(xZTLSZP}tIr*d={I_nXkg80M9C{{;I7QBOhlF+7LmQ=F!<66|u<9fOFeSqr6BMjd@#Ec{ZYr;kuO)`eF9Wtb5(%RoYN` zfQ2U4Y0_Df{w%1ktUl5!!T01pvmO=AycxlS9TX=r!U*OKh5d=1mcObd#EN44dB1@* zF{&wt-BaI=B}AU1B4-t_01G_ayt9s@1Gh1JJrKRDP+$0g;WP3Eb$NyfX8-dhK%1)x z6@W&=NG!12_>=)U?jX9v>h@A8f>%yR=#+ALj-ncOr&UU1gCjPX5?tGHxZLn>SoA+m z4@l($YYA6fj=2Q~b~_mk3Qu2>((cFcVr%n)^q0rE&6U-Qn8KD9#tx*{k*iVlG3aY% z7`$}lk+A%7B=AGm*L@(%)va7x!S;2ZA88hS}+^`aZE>Bvl0Vl`Ccpm2-+gz7q zDhc7kVcNchkAeFX)jph40bJV?}Rl0-xexuTq*_j&|tj*BGu(lg%R(s3&=pWy~G2h z%dsDKNkTjanAM4|EHfvs+S&t(I#VX9umk9tDMY>Mg7=9VxPObUj!-xm|39p~by(D0 z*EXzxG9WR43P?FLf}~1^LpLH4QX(KA4FW^g07FPfsWgI!bk`69k_r-v)Qog@49&N> z-uwCP=ee)zc#ijv_a8mRW1L^?wbx$jTNkVwv+#Q#oD_44 zcvz5Tom(2O)Wn`!yqn=_J29naoO`R|=Q=tvTW*tPAbuoX$IGng_(yqbSe(R>*uOf^ zU*j{eE4Mb(bc5mc%*KqrPtT+TS=F+q_S`tFqKdDiJZi?dH!}RsJH@xtg01SeSqYeS zk{ferEp8MaW$dR>2-g(ybNWqq6HiWwTS9at>a|uW-&=k{UOt4-= z3EZACKYFLB&H$fE@b%YHp&SfeNJ5bS!3k2aKuLy~4^k4>7`7YEcj_E{KKV;EA)AYq zAF1-POWoSNOY&x6|Fq|%iFc6pt&U=5GUnkrM{uGQ*00}i-5)2sPf6e~~e;3^s$TRMH9 z#~D`o{YKA}PPGnSV=(yWJyQR;7=T<6KJd`(urue;cX_Jw*1Yv9yD0MJ{pyCV@kxu_ zx_enK@^*S1AaX2Rmj}#v1lnFnRqmts(Enl&^A4K~@Y_@r>E=W%#vLdr`eF0)R|vcJSCvIeM&kRXGt9D85-Ga=5c*0J zTHz@yDiG0;vCFcpf$ zYNAL~uyFgX6gAk??*ut_sngvZpGINENoi}^J%uez)(2a& zmB_U_l0s$jD7sW5oev_ei7{8}P-GLSZPdx%byITlMHi845_p9|rT3exCU9qmS~9e% zg?iPd_6TMNJxj>$CA^Qb%YiA+)cFZWF3a8~3^c{=B{Ym_HjT&8Hg@ha-9g6NFBq-S zM|wp=72)Va^C@0z3$kgIjo+aWcUn2*S> zXMvjCV=+NtxC}v2HXo}=lpS|^sqW9r>8FHI;DsGR*r_G(-Nq4|D-i4(v@w2@)Nw5`NJ)xIhojBsfdcdHOrRKke5tAjy-ko zyf=F@#~5jGQqcc%zn~t^dngO zmQwh$`uJkT*?faNypaqK1rH3hwB8XvOS`J^ddFQi=c^W*)@Rpdfz0%_~NzJfoipzl>?x8S} z6>NN_{)aagPl^TAqRDWabc!9cj@kihA$l!2U9R)NExhlypQ#kTaH@O?7P|$yNPxHE zS@5gbd*zpV4mFXp%hT5`2)RI^9bz82di>$h&HdNLVjz$@SY+9dKYf%YTVYP4tiI6L?yani6lp)5 zX35*bW*<(v2*oVs&ObG*M}d7-4{1spgKh%D{lbX<*J6tWw~R}X?1UkE>|{5!)4bk< ztByF$PHNUkI{L6C)X-1oniUv3)%MN3#2;)Uq!c`*_K;XdY3wBlV}1qc9Z)aOFGX*2 zHGbSE^Q>~nE26^#_Vf&*Bb&*ML{zaqwfXBJf4%O%w%CPz{l}-kI}n-XX36x`6uW87 zw^Z6U07sD^_!9EKA9LE$xbj+eo=M<|(!%{OMrh+te?2!96uf**8R2o>pMU?kir8tg}2UO1+UTm8TLtAzj=Krv1A<9oI0{r`M`|LuyGWuL*}Es!mu zC5Q2cx;>ySeY)##yjH{KmSi3++R=D^cI<%hTyVS4*3LICj0HEF zLs7e4zcK+-ux`4qR}N`70KrmaY8^xGJ%*FT4>1#WYbK_PYp02EgQ|QXO>cUs93?w|(SV}T>A1$u_s)1>MNSvSStWSk8 zk&&K!vyz&*n3;^RFRc0oU34V?LRg}>`4q>{g15HCb@Znd;jkaQkW8(cbBNDrKwGFX z#X37&yFtbA7<+!UV1k&sg4-W=wCenQ9QV+SJG6x$u*KM8a<1v{yJM)W<%Otma{W4x z`}l2)m|wN_gf5 z(UzWx=hsQEl_E0vtNsY;%z!l4K2Zi@OnLk5*^adu>^jg+6Tr1oY1S@%OzC^b!;9W* zbpX=bTt%E`KqGAu$Vg0sn`6Yy#%tDx+Y*?frmAxnN`WjEQ>Z&Y1uDQC(c1uXgm5W`#j`2OYRr=&g`jks1<9zt;2tBDDL z{y>9!Qq%uv$mswmbIj`kfYs75=<{hY!`G@zltCA?r|6q<2Ps zh}QQ5^RVmhj~EGI?3zh|5z{aSOnt8&cUV~mdh||iV8XaNi$WBqTQ1FeASCaVwHm=) zyy$m4j!hCP&WB5%ZN*Gp{Gr9bxc&{RMiS^J7vQn5JETdjetx>)Z#tIQ1eS+*MSQ)s zZEA|Q90&y0fyvY%i&Uz2t8{Yf%7@J^T;KoP$8Sq177gJiK#hweUJ@R3qno#3b-H@& zWdU5(A6*I)xt;#Fyys3qt?9`$b%>i2J#nU^|MB=2X7OUepdBQYhLcdgge$sWvxZ_i zWRqmH4``4LF!-Nrg)9V>)J0l`B+mj5qSxpmc;T%{WhD4|LLC0`UcQd zPdxtV*MQNe#sR~2idFN}213>Rc0eGsuizJh*J74KQPr=WNk{QeX*`;66VJKCDL72% zwt!kF2Ojd?#RT=Xuf8jWSQqf7%yX~hHj97_*(UG=g;wF{=CVT~$oQ-4W*}f}`u%ql zL`!%t(%gQHEwqb10}5~Co#rInCsh%zb{N#EcA|v(oGxVke(%lk`H!B0;pCb(D(wHk z1tutDIudP}o-XUmlCF-^bNQ#K{=&?<%pb#i#9|jI+w|7b*5ZQyEb;s8aI*B7!X<*YJ_M7A)Fq z$bDqEuD|KtNYj25R5`rh0Qe-v>;#>Oe6n3tFoKy{l=`J_{#wP&4ZP9&yDj+SuP($Ae#eDFbi1qJ!7(W!8meL(Fp9_kKF;jLhl`8~nzT`{v7+;*R$Eanp zXzMe|#%ydmWUCJ&fG)B)d7KOl`;*|vMC{w42?9%n7Krofj!olcpfcNvNaD5&`_|DC z`3bK}p4xa8g(r0VIr2a&({4ct27t_H6a2=@N05$Sx%sy~+ue`zcqV=odGP=I1Pn}= zW~8*l*gR0@^dDX^y9B`zXhQ~47eSrEtip#)=3lNwIQfFN)7-|}wN%k3W-C($%&8xC zU5xIX2%KK#lkGrV0Vn>UjDzmovEEcc&^xQB3F{^db=g~w(O}9(eF9zWu(9|R0gtD~blkE3Hm6)F)4?0U1UtP`g60jLQp1gBpUd8ZSqBr^4mn!of8W$vR|0`bZLbk)j{yWP?joKD$gL!6Fp-magRhC& z11HyD5qi5v+fskpGfY@Ch)}fsQ~d`?t6<2%APal z1voBCHxl(sob5QqF0-0FQh_Y{oNRSYM)EZ+o`EeHICos_pfoQs- z1L_=s6i=+7)0ZoR6d7_)zVJi7AW+Q-TA}5`7jeZ4`HpCYl?$28Rbg%-hf_3^AU6ZeXi#ExjlqN>ceKol3nT39pu``3E|BjvH>F&^!q#rmj;7nh| zmCoP1anBg7)j;peGW;1$^0*``dL)UtpU!|`I(nP1*c3f8$1wE{)=2D&1;;H@F_COP z^VAUn(-B2GV@>DF<}ZJm-P8$=zOodchttMoE$)l&d&%ubb9YlM=`F&2V{mh1<=4#$ zWuLy&N1Pq@y?XlIi_pgE=Z1oh{gLEHrb~KF8M|LSTRrxHcOq+;qwADp`6kd&lW{W3 zG07asGriqp?76pGJ-qbTy6t5_Q4($E59;By6wk2k4^aVONYy@D@5keyu7zbKdE&Y5 zi9INob}n$f>m9SVx9E{ieUxx#gvIIPrFIWC#OVMT9 zieyHrD2k?1!e6CRKzu(O<9rk-oG}@V|p{rB0LU44R!xF(H4dg8dUWK0p1b+Q4j7{Zg7=>_=2ya8_HaS^oOV#Fz4Q9%*Q*z;HvpMo}VS33s6p zX-D1Ts$Tp;oLF~Sj5y*!c>ym>L*GRrB?85een0)3SsQA8ZJm$RiU(RmBb(L2$L+Gg zWy)?Lwjp4ic?V8#echAe%Jwk`oBLZocPvbMN5Qfg3m$!(w0a<=nc9%}i7(dfDD92; zbXktwh%dti?J0MENGzLnG+RD}(gJ0?dhB*5gNMr1g5BrsGBd7I-UGy~6wtwLLvR&vS?F9Y(;WV(dv~-RuyUD@ zKGt>^A{sez4^GT9D0R9SCQbiCx+2CZ=IoM7gA!;JX+drf2m*;lQD&!~H=;i18oT{m zeXpdallZ5^)j=JV;nKquZEZ69FeW5He^!O>jr)38v0k$(jk8CAX1=Q=O|y&`OVs1H z$4PNOi*9HQ1cq6Q7ZSI2CQs&nXA9Dh^tg8GEBnWIz7Q}08dZ}OO2)%iFrDfE8q>v`kr*{jQ?{QN`0owuC}tG~o)YJ#!a7cOC`d-@{Dl8%N3@GmYe?UHP+E?H@)^Tmob7S~`eeJ;;UW(HEDbz&P}sAJAe&v@ z@H#`O_=B@Ms=U07yMtMbP05WasGZfJrnlA!WishuA~ToK{#AbxuhMe22Vkg6sJTje zrAoFX!&fv;f8m;dhHsAy`_H8Mahip#wVzk%^6U94!-wW8kH2*+3}Bs|HZvze@T!dYWMs>!_C zNB3bCOp?I722m5)8u}S*=rLsU!QaxTPZ2Gp?Cow2Ptc^S9BBc_g>m4>8U1c@8NE_^ zDskofpi^4qhDMlW%#Gsr1k*-pvvMGIrBp->={`pyxRLeEO#L14no^>O78P5qd-HQ| zb0yMiI0YYxJWk?AJl(QH*50=1b$~&sra7r#nwtm1vy6-dIgl1_B0<6_-xlvja!2si zjBF+L3EmY1rxeI%0!5hn3n6ol7Q;9Dpf36Z@)t7Y6n@jAEOE3J(yB*##$lMe*SWtn zn)}2RQBD|ncwP*nq!=PB7e%U$Qf=fUSA2bI4B8wOA2|H5o}?9FBBmVZoEJO|?K zYgrP#!yl9%p$ySvni5-b9>C~cggKUXvtMS)e%9p?g)W}XSNh`KEe}tmY|^=g(^n!I zjBd|T-m>njXjJ|ZOS*9nBHwqOSmMJbl+(-7{wQ|l?zMb+I^sVzs4!Z*?jRT6aJD4K zRcGYXoN=q|>q;I^WG%aLKB1#amo_uz&tcCNT8P>C9{ngI-(Dl1EQ*RfNvr%RD)V-$ zH`BEZ4zpBo7_zxzQ=T9QN*PyrCRY+be^qbnMohm5aEQ8npm&$?WjW;sr|4)u*CL#;SQ19ei?H9^%xX-FWyd@m`?>Cc-|wsB zk1-&S*ji_|hlHw2P#=ja-GMf7J-r9x9X~u9q>k@E9^*UT!G$f7_*9q=^wS=Xtv$YX zI7$$nzhErBRvAB2GL%i^EJ}@a+sxgV5$9#>SY1fDuBc=^&DdLK;NGBVv*2Yh(doud z$PP45VP35uE~JgOmc7IDNZk&dp7-qoM!m69TpvT)r08a z5mAFino(XaSrHUXYa$0Td$LypY>egmg?~P7clwX z(Y_y)mrG6t7?+l;uPT%J2MW_#FdkPd?2J}omb6WI609-Gwi9f_Jx zh8ghKeZt-Ro=$s8e-PU{>i(+$qxHn}Z zd!8y5`oR0jM5ZwYa$7vzYaQsdUbaM2Iu`c(rzLL5bq1WOpKbPxULKM4M(aIWdRz!{ zBLi_?;#j9tj+Yho!-N?93^D)Drd;A8#SaQcu55tCj8?a#Qn@#j#{yz6Ys34l~!i!0%_WgCTXi z^fry7Nf=)v$8XVlBb>Y{@8o6Tu|d->7q&*2n)~#u5^D`DS zuIYDs8VLT{s&jISyKK+1!zgr?B<5)v`gF{f(8lqE@zii7n|bHV#I~raT+43^ekszfaDzhPe(70f zq(WphLGl_vUu<9Gs+$|5UjXv$HrBV^wT1Dl8BhB7^g26ryqs= zluQref_cfLI_f6_molEJ=Mt)3W|g>4AVBW?`hAfH{^d1T@#9N>MwzEr8m9+6E#0gc z(_`M?KiFsF9r9~+dGj34W^QsDz|f+aoXGOsqOmp(JDvkYY0YR|f*3goY0^(Cs-7i>X0O|3u6~(;II?U}0+GsvkO#?* z+N<|}R@U6LAI7Scw5(h6y7zGed5AEYQEmmSA;5_(&^mShD6@&MElIlVHz$qr{_VP zI!<_4^=zcycilBnV_;XPpn2*ZQt2APO)u`ZYjW8t0JBX$6MG7C8QtqhP$Eo-loXy3 z;4?RpSg-mKRtSJegJ#*3NbO5gdr`Q%aJj%V4~&7{$kv`a_TjBh*fzl5ND~&}BfsxT za3o2=a5=!fEDVA1-EXhoxk{P!UgV^{De2?U_4R@rLQa*3Y$HEkc6+>A6jCbKk}0U~ zSs!7XmSa?Yy%WCta2QH)1kIjA-E)q~_{><4^%X@?x#;v4upC0KC;>smouDeC;;x2aeC{%r|h*boRBu| zbbxVEeYau~LHLfvyX_lPppEVv$*CT6BMx7CK;EMHE`W#s6RG8lY$;`Jufhvd7MYSI z%Ai$E_5NuXF1`Va<%)Y$OWCItM);Aem7Q{#dVoqRp?5Z-5vW6#Z~D#dz@4M*>gJLR zOcdGYIfE9OGP(zH=eu=aM1Ufr zr$y2}Gkb9M(CpbTQlw7%D^!Llvu$PDKF)T?a?Bu4dJEG#DjX79=d;i*6DbwCSuFI8 zU)KGWOF1RpO$rxXrAKhX$0l-3lCjNV^fj@=&PTByyXD7V3(tKyiJbewHt#NYa`j}X ziIRx2VuhNk_(Nm0KG9Gh$hTEs?L;1G5I>|hvnYH|be3T{UFFtW!MfQw%wxS~is>VR z&{v^8#dp-DD~{+epUHb|ZPh>=oFMRf>rps;M+WnsEK(s0@qXf|fUlgKWcfwM9!Jpb z8J^DGHv$o8Y5^`zON&u3U}DlEcEx(S0oK7XOr3YdECt05MC_7$-$NJ9WM*^MEBvCT zy(hw@SGcA zhLI0#87odB$i2?r_ye&0r458>T>VUilhbqth%db;CDYsVt2tpZP#ge8n%(}Ymi+`RV zTa^i}P{s2yF$*G|mooJ8ZPiEIKpy#Um!Ms`MnhU}g|KuAOi^2Y)RpQ~;T82qU)OGh zY|*^K9H=|YfVv35wgw9FRG~@j`t;Li@pTbJ4J8XuYH_EtuZ+V;%7FOw;F9&KA~h87 z@!4zl++Ajfzw|T&a8OS_mLQm6p0wLHS8@S~nAK@Mrewr0ZUXSa5c3aj-li$}v!wr| z67NQc+nq7O!%|owg+LOq^sS??Eb6QJkUd$ahwjeOvqxIPGfO<_>hE*HEQ|rnBt*XT z_D|Brlan=yY5Woq6n`ABpyjm(Fb%qv>x0VP!4(W#*kI_zmrOufx}OcEAjYi9|J zUk%7t2n4N;sG?}s4WCSn{$acsK4IRoO9w0du(Rm*Y0+!O7Z}fb^q}txA51p(eODB= zJA3Bdqo+E&7-~ASb$OUiy_~j6xF2tLr~q!lH7_E>ev-X?+?TKp<=#wpbgbk%Hj{vT zy4Y(Y)LL^j_zs0{#!QnzPpO5`oerT{D`}uQT|Rk)v7}QiyuQa3n=E*>@0dMFL|(T& z@3M;&8~mV%Wx(Q!SSg4CkG$=lWozbbkgrS&V1^}sEiAvt7;N8L6fKvK_IbQToa}ku z)rv#|I^XfF*HY5bh~E9zK^~E_y3@+qd(IIBeuQcyb;Dl<)CrZBSYGk-zgGx65 zs5=II79yGB7OThW|8_dk;K@TsxZ$bcJaQkDX!-0=j_g>3R~|B)Mt6kMJ669e=Y}sQ zxo>gVw~Dy#dsMy@k^@wN@cp^Fuc7_2A8V>V{P{u^v~c-h-0Lt#SU5#dszpYBnRr)$ zB6m|1l)QAbnU^^;+>v41Fn-`j)EDHsf-a&Oge^Oozp=k}ST?pJP&Cm4_SW+0oeMu$ zZ40gwZk25tQcb_1l-=(J0lTM-c#d6KE}7+LqI^A5-}?ye$ntkuYZKB0C30iY2PdC^ zF!{$`V7-bY?)<9}&7Lk8q7bN6)FsicBDekgU!sM2th`j_fdFHT% zTjTn=S2KIj-oEZij(uDu9ypyRPXQ1e9k9T7S)AnlXB7@G9cIe-KFlNpGCXBp@JCAy zB`m+c=U0);OX}5YOw$sC}*c#6OJGyFCB!2fjRFk%<=kWd`l>`5Do1A=a zo&~e~g)6d?dH0+pfedq|`L_Tl?3$xf#*oy+P^t5YwDMLKDfc~_qTXM|BkjVcg|P)< zq)AbcBAo+@Obqic3s+EN01=>?3bU14EMc9K`K>i$DvWt(!+uI_lfW-RF$(06%ZKU8 zzh4wb|FgV5{P5Xt=rj;3z5V%)(grAv%Rn)k76Tfk*t%EW-Ip z`IoD7Nc!C=#Xf2ES8<)`=nnQ!8F9!xdDIXtZv5>;EQH|OgK@hV1(2{RMAN_HV$1NH zf5#)Yqy>gdNxKw(9<+zk2PsPAY0pMzjDM*z+pL;>qk46YSH*;3Nv?|ml+UED(1>Qm z67nr26DA!TP=~@07IEehn(Lr$l&Pag!M72_+banx;le$RWS>S^mmW+8*dCp1Qn;rALbs<2RI(Y5 z@VUl`%JasNwMK^EFqzr&)?aAIdd>XUx4JTpO%$mqxi?%Ies~2|FAq?P>ndmzbYx^u zCnLM9bYV_0*_N|n*kTq`YAH#Ud+0|rXw^|v16=nt^8D1b<9TJ7zua?+*}K2!O6qpu z5T0pu7~P6PQOj|QOruy@Q{RdTyK+dhg@0z-vEV8wv-a?0OC`n4mY_9d>+7!per%C6MRn#+V*VW=;g$O@K?`}h$lKlKHLQFncIm-BjI#` zB%R#i?5Dpyz@8UF7sYCTS#7Gy8deg)tlzvvoV)#jC#~92SF`A4i z@eY~DyJZTKpYi(ag<6q9ooqqd%g{h-+2Q9CJ<^o>TujOF*!Q)xJ@nI2T+w37pLpzv z*S=8s3@USw5{UK-)U^;5^wM0K@}ddjXN2}wl(KA*mlK2XQYzaw{;%3u&2FFO>yb*? zL}u|5-hK%T@$GIzHahcu9i7{BGtv4_DGn2;wL{$CvZ_sHe#wa+GYr&Cey$l-h9PeB z>u-CSzYY8bjDgJYi>OS75Hg&L&*@Ep135vhV$18scM#YQCxeEO6q5Ej}N~ z^LEs2TtGY7ByUq^lq;KxK{ldSeGMIamz&SvQk$GMC5i$DJ6P&h`;X?L3xlvG3~b_P zC+bvCdPrpXR8Qb3K{gVVt42=@-EiKTO%&_$4pYoY0_EO*fhqaVoZKPLUf+0H?_jt= zN>Dk%es>VIRe8Znd%^*c;=(+_EwAydTR+$!>8e4aKT*X@&`BaENL5}GE2lE(N8 zNdiBEks)n)%kE2i7rC_@f2_S+NFWJIdDyJ%71bjnH1;=pmaphlqc1gu)@>oft|e_d z7wJ9B(Q~xkFp=s5Vb79QSyA-R@i-75*vVX>m-Kp-RU>J6-833{zDGOKgP-nB9ln3(BYk?wkcPPZ0Bp3${ph+nirO<*$e|XLD_cd` zjw0@5hI{k4m94(WXgy4+WlS5tRZd;vg%n`IMQ(8KJeOE|XU^hA8qxYi^c-v|T15c| z_;iBc(eSN?J4nPk(F~~=ljJS>ag>M5qX~3Y1ux@7i^~N;Ep$p> zQAq8KhDsksqri0uZGljB7W~PK5Pl&>RT7UedA8zuKMQ9`l7SKL>{=a z@>P9JI~~#Co?Cdz1nK@~hpX?l2gu3=O=#cRkMu8rzNL5exQNa|v|i|o@kS3swQ&hz zZe0IJW2x6y$*s}*huCRpLT*eUb9&de=-g=F8j5G404~qkhGX zs-z{h+bYA?y`@YT>*H$V+l&1xUs+c^O9X8Sb=u`@Wc~jgg-wbuTYRb2PFS0pxMK-6MG8{RC4}B-g;fD=uu=CWZ!ZZp!X3#(t8mK#sX?kn1J8^e+0Xgt;Ug5l>d@O;E;8a9nZpCa z+BnNai+^-J)EA|9Q0O-JW_%?epXQp;g&=XB-P0_goowBm0`6`F{0tJbh ztBRf`y0f=lgKlB{ojEj66NN}YiY2y0U*HEa_eXMiZ};R?+kVw6Y*9-b8Q&Fpfvi>N z__e|eyb+lI>&BHF+X+o`nc2p|a=`?9d6cXAps+T^+cvRDE#Vz}--QQD#?&M3i6$2n z{pBq{I>s@}(diKh#fiQke3mpKZA1Bff7>uJmS&A|dN**G&tF3N>B0Jvw{ED+-hgiT z(RNew5xsiRaqO;nRjbkRcb0ZbX>5c(+UmD{2e;?6tfAEi1O^3j1G95turSfk^4;^) ziYP??{^|s0+6v9}o>N{|>6r&rvL=tHv6iCJ8?V$Ddkz_WcL&Py9bf(h`FR9G!!A)s zAV&CaeWyxS-td)J934j5fzc`*?-mGV^0N{EdNOvaISf?rq`vJ398=-0rOL*a(=fDC zQce4C&uk>eq$Z|?Ex`Q9rfqFLYfgE-S%_&WF9ww~0Rzb`+~+50Yr9;xyo-aKt8N}C zs*4=?eE0IucLe65((sqLNMvjqbqy{+`+2GG?~V4o5m4sH0o3>ErLu1Tp%%@oqbafp zh85@EfUUDASkU~~_(-xsn98~k7DE&Fb7lxNoA9!+F3qFVZSAKDpc<0$aohi`$+U=K zaXfYjAZvzQ57|x5dhgbxrhulGIV%@ssY3ai1{N(+@GZ~WP!{svZ&Z1gF8U^*x=E$T zH&#jbkjqNHcPLmCNJP?^kR@z74Sj4XZ}+ZH8~yO)c3!w~I4a;rnHF-T@4?MN{jOa+ zr%>w=Q0HBdFu2~Quy_P|H`tN=X=b6csW@IY=LGeefCmyilg~3CQ%yuz(aBdsA?lRRg~-J3PF2ptX1;+VT@jk> z`8Q|ko%~7;NXJEDa57}r;Z7$1i9=5O=!pepOZdm35-&VB8IhR^HOP^9e0X75hYDng z?XaQVRK2FDiR7wZPkX-u&*yNolt+#wO_x1g+l(+>2%miTlaew6+Qf`ziV{UQbla|n zKOdi zb#!oL0Z7tB?9f{seNO>2qp4i!q>U6!jl`}-P znIgdKOXEvF!UEeH4Xa#cacfrf?C8WGx_r0eGhTtHTOg%%LpL8E;lF5@8b^o)U4`N7mWRmOqb?RSr+t5s318fo#O4*1P5mv)|{?#D;F}^?VKDn zhWwdj2iq{Hqnkzox*0S;3(k2Mot^CT^U1ro8X3S-%fw=6;Owg^3V9Q%<(+%ptIA^?`p6*YH z;&)$Udu)-}`WVm{GzmI@g=GS{AMv!y(qAd=H-GoDY%a<0YRSx7&V}@u(*&G)>r6&{ z)h6i#z&%=hKW51Fycvz1_Idn>lge41O4;W_RcE@C6~`|DpEf8y`Lf8E8s-q-IQJHI zPQ*}!2~MQqtEIBHFFlp7oAL~?{!VxNtTGJNHD+6~cJrxq*6`AsaUaa`pER%YQye)W zY?Jp_`ci(drP`ByzhyBL{hy&Pi|S^Lg<-Yyi?Z8S&2K@P5;nhWF)nx}-QWB6@~hap3t0?CXxiXt&dfk}6xjQv|$nISjX4k$| zmh3AuhYaSr#r__=BHOf%g#}k~=@X~76BjM3U$RrgR#0FBjn>M90OzgSa<{wd`Z?3B zKzk%nK6v&7*W(xHQducd*PyyjGgC z-+*K8D(nLwn*8d)q4=wZLk5V=Z(iSv())C+Fha^tpn_xA_mJi)dRb(6yS==ZyiMf`19Xz7m3Q-QnCuK91*-{rgDpB*%UHo{Ivt(beju`$+B{37``{`D#3(tyVWg!Hs? zIk+oD^;Yy0`>6~n`0#=wWCGw$=$O8CVP!ovNImT#A2f5WNyw;^T!wF&g35wDe%bMQ zLj#C1D~&a!pYXr<_BJ*>=s^i+63%62+}jpc%Atb)peni?KF)iuBQb_ynuWHc+dSE>B_RC!U04J<_$ErACBYDm|M)IZ${*cK$ zA@rO*w8csO&xaT(7f@<48BZ4edi`;2IQ#ogYhHzT|6a5IcC%-SfHlV09Ok`R7Un&d zs5b#@V{sq2Wk$!M`z3~uSiLoX&XVPw55)M*f`lQ?;r`b?+rK3m|Gvrpgu-`8E-dI< zQEBKuoV5S><^TDWd*Of!r=D%&M*DX{+yDMQ|KDG9_dcF^N0hTa;44i44$j;~7kT{! zldA|6;2ruUajPpU3 z0#nlZaz5WB)%DC^vRjqDwf3b_xiuS$NrnzfjGnV`4_}`E>XqXT^5Lg@HB*35;{iAk z{u6-za{W%)OE3=3-xQ0OA*}%f!+K!Ooxb}O8E$#0E-J31D^BVFlgjW0MDiE{ASeyj_|W{T*%@h$O^4cF|Di?YFXQPX|Kq!j=^I>psKg}iOeO+;3lT$0cZY61}~gJTBu)p zjuK|M>f2y=<`+!|;#YCZ;RCC2FER_dldWTLaNJ#N1*2UGkJ?{B0u zlc@Xk)K(OO18X^c!8aS;-10+k4AJvOyr7=nL+G=G%`Ld$7|=(&JFs=?KN5JWK`It6@EV%v`r&g#Z#UKBU(j~N7)G#$MZUaK5> z(QKb9NpSFDM=B?W2NwNhAN2S$ebxu`N&1~|KguTO3$U}i8!$HRhyrt)JY2|NT3!*J z31Ed(5B!}1c3C#F1PYjosZL3jk{`E{a!)vQ_vTvX{AuqX4v zby-tdi`n<;fay%jzJ@X(mCo%02!cttS+HmOHIroGt6CqeIfFZ=z&?`9M1!7zKc!5e zGMcw#c4O5ajI!EZ6Airx`c^&AL1jNZns(Ccb}qzbE~xcKy;=gz8bhDatJn8`#ojr7 zeh8R6VrO#v(2J;y(GQHzQQj*%oKFdx`L1fDRrN1A`~R%hwrIilc_7YR?QF?Lg2)G* zLeu$q=`Nj&-gb~cUKzO8MTEUA!~>(yLcF0OgGn6q`=7ZA17i@|c0B_d+y!_m(|OuZ z!CAoJbKopEk0XDLw)PC#ZkK4^`LPtUMk9Lyc8V+Vqp?}Y4LqU;Z6rdqpd@`8IjYE& zBTJkP068+22wk{{LOOTr)=L4n(Fe1YP??R}0eRGnrd=Rz5W@W|@w;E+EVeB>1gqH5 z_)H|p(!QhhvN5eGO=}c!$bw|SfG`05>D9XQRqZ#|5>I0pIdN5BIxj~h4zMZdG!!8o z9Wtk!fF`!GMK8xPaGCv88SvT}myXyZ+9+Blaki#EY&mU%IZ<1|WMZFOsNPvoE=6uY zT)%*RmqB%@LonQQDHs1D1LhIa0As&wVTll|;%s&#uS-svpuj(K)kEh9p07e9j> zLk$NOM(jGQ|3nfuLG=sZ-0<)Fw0M)U0k}lm&BN{FX8Nd4+fP3vHXW~4XhMk6^s4jM z6in_1vwC{@pUg0Y^&EtPV{a5c`!avW0SJ8(Xd51;M_M&iX2v6HQ$Jvn8`V%L54&sg zdXEw?e!YGGWg^H<)V&46Of&|4xGJF;c7mOzH@?Vf7QddUtroPuee2t6VGNB%A~i#(4%d6uy6Fh+ zzqsRto?i5~De!6;;T!P<@5@>*7+)9g^y*vmjnW?@{~ujn84&fmt*eMKh`|6;pQ@R|HW5BM;+ z7t%TMsgCc6<&sgAb#M%DjV%ks+D$omTVn5*?iL~SJP5I0{54rCv=h4n?kC3iFM0l_R- z@kX=YJSQ$T&#UEpF#kf4p)ba^CRc8;fq=wHCBPQT^BUdwJSLR;qh+L*CJwP!n z2o}X}Y2pkzVI-3;kWAbLv57#8;f=mxHfuUu4|&=S4n4Gy>^V`aVHgl04OEk$%t|f* zQr(%cxKeonBJe3l1UK}AEdWASQ%DfE3o5h_62SIS;vNfWe75}s075kAW;v^^Mj-SS zxW+bkv9jbP3WFrQ$CT%WmC5g4gB6?j`_{T@TovXfMTC-QTb|36f>$a$mv)5-^PQwV-%_#veiyB_)MJIQK*z5dC;uGCr_sA8{G2W@mxDVM zp`)+h9-DR{(5b|lj$e;ZOrPeGzjF3nHcXV zXuEQm5%QAGSOYg66+sUB(7e35`dsSe5xqXs{L^Yn11n#cvc;pEzCXvnq5Eiay(L#C zH}|XIoiD$QH~-#6i4dU%aKo^sAb)}~)kV-t;+dDRyZtbGRa`2tsqWd@qwc;hy3z_( zg*(_F@6?IgOY~9<^nfTe^`8Bo@#cBeQBRjMxy1zh6RbH=-7xNcs(6geMkUaJqU6$g zpAbG!pxyC8Ov1zJiUju@=_c6gk2vjY0h!rLBXZ9mG?7s0WNdPe+YnSgSaV%*aP~UzmcK91w$!Ae;g);T+sPJPYZ%VBOjLVE8PTFges#({gQH(~iXtxKv)s-$@m1 zygo9Vu0~I3p3aBIc`Rb+K{`HIWXyFX1?|Q~LESQRk*n4ZCZ!t!jX+ZiN>D`^X#p_{ zMx7f_1XKu==L)LQ^lC^*(fMdZI#A_Nd|)k4{S0tG&jOx2#yuEmB(9j*|F$p2ddyHq zsLxLkxSUlbvB1;h%A$nxb0eIzNLG7t8Y@{;;$E=V<)q%>soBqiSi z?rF(iT%c_;mNKoEvmoE>YY* znFzfxm#oD>NXi`F3N@lDfV+1g7^WsJ;nPW=CFg~uu1p>&By&Fq_T$|b10W(z+6sgX zS3scFsP{QgrqKQXxZU9o1qe^rzbgrEL|lHfoA{!XBlg8SXc~lo@I9IAISsuh+x_vN zA>NGEMMF#h@2)F3q8MV=xJcPA89n5u+FPMDu)p&U3&#K)u%PgLyNy+lI89`X5{G z;ro4c1GGAs6f2~I2*EVztMOag3 zP@;oM`pxHfAl2KfJ4UwuXPo~_`Sc?Edl_v(^&M#;H~=25?H0_!}r^F zrM!j(SeZSGRN+918~x|ju~Dd38v8CBg?ObUK_F6zAtzoo>TVPQfVI9+%$PoNQj|B% zQI>81^&cQ63l#LP^~IkMTXz(QN3Z*|=2`T331p(g@!y;+IX>=nRPwEG0MhbL9KO3W zS(;1GFL2@Rdx|pqjqeZb4Q8o29BVIC=dVDN3?0VOV3WXBS$ppJJ+b@>oKcifjWy4S zp@+uGU3gZJ_sca75P;*Iol6kF~=+tX%AdIuB5&m2V@{onP2vKP!cFcb@f*VLThZ_zL1{@rnlK^i3^Q`F2fkp6~h4sgcP} zf0IMYynBml`lRJfzu@J08mFnr;F`b?jC`qMxi>aPl2Vp{p3;oSR$U?`u!vbRp=eJa zLn@M-?7l%39!7ddke8PVT9LzY^!t6>c@hwl(<7iXMd#Pa2{Ac@HC63dEw2BrvE9f< zx%PDbsU$5KTJ?cgcJhKGz!`T=-XdCazkrrC)bQ`Pn+s|^4QvnV5}6*y4}HmiC=ClH{Ba?rA_dW+Az+xB&ks^eIwC(QWz;`mij zNjhq&)GucOSV><}i$8x(?;vuMIVUt%&0yJi+VUY#1nkdXwop(7je#iP zIB?LpciYR%Z}~0cWc%i4`lLVFrUPcK@{=Rh#W0eUW3Fzqzn4Jy1D624GVX+R zs12IwY)LZNdBvGPCMm>u?-{|v33YYewpu)|LVtt4Gd)&V33p~}wS4chrElHjo9bqP zG=k5|%3Is$STzjmv132n9A?~Zl|B2oJpPU~6gr8)cd+{D4VnW;5&TaTC>v@Bh`sOS44gtkoau=*(6!+cEJyOdixfgMHb!(E{i`VgJ~Kg_VS$1 zcl$bx1efv&yC&tI&;Gm}aO{#e1=_PI7AB*niFMmG2Ji2825eC=$eGe#;Wd@9%qUB? zph1NzX%@zQV&s+g=U?ung+dWYG;2B!T0L0cQZd6q>de4=NJ3>R1Hh!;fs+`bF%Sm| zmfbo|bUV+Ci-ULBNyX^keBOPdbGE(|XLqtXC>z@OFiP@*d{i@M1`QfGJ}1uaAjfbI z?-jK$N)%$I;RvH8v$K2fl5}q|b+O->aEN0rRy=lNhC-l%3pNwP0Za^$Wc=0TJ#>8! zHI%209R$qnu&lRgNbd&PEp^e-jtz#NLb`DFjEbaPcrNa%yA}_}fzcrVd)dj2eI4=x z2_>kd*G2nX|6lOx-%B=3vCKX&eY*mqpG_f!+s6wef;Au$%1~JG!hvA1#4jr8g`>st z;Bsh2RO>AOD@x!B4a0bgu1hp|#&8$hX9G(CQhmsN%Y4)|6g7?|_-XA{dEX2m{U1LT z>g_MWK@5zQsN#xe5~BccvxtQEy*|ENY!VcYNoJphr{fHS5u_%~c!M&LkF~&;#G1?*5r;YFP44S$7VKQXJmB z3mpM1xb!;?HwE3f=Lc4O%5dmpuIIbE%A`}zCsW_iL4L#6J9RZY`DuGy)A(bdNNc@z zOtQ(wK-1U=UCIcR=W4PkRal#|+O-XdX5vUDPhV1YpV4Hv^heM2Df^H28?yA{*Fib~ z#wRU=@Q@0DuYss&i=pBDeqnEtw;&JNj;Z@S1vLO#%fvVNO94Vczk@_qXn8|ZhD%Pf znO%*T>z7FU?>9aN{q+j}#AlpzaSZybmRmh=64hwPQeAs`Ir02`i~f+ve1(IMqY~$G z>rJ8AGoWlv9`35ti4ifW_>s}8l&e;%8zCEGkxkzg4lNB(-Mq}P_NgYC=7Xg8f+U5~ zXT&B^t4PeJGqP8(_}V`Z2Z1ASVhE{3MS<;a(-(olOVWA42TjVcCq*CG&gHBa(R90oP41`Z^nE78Dys}>d|Z$25^U{&ytQ~q zbphw$#!k5lfapw@d60Z6qi>(0=hvqB`4C>)oYCGX=~}krJ~64~J;b4F&Zuas9r`T7|`o~w5af5b6F^BD+G8eGk_%6;HyO{Psj<&6EKA(NZ|QzS>xtRQ}euQD^K z=k3|)!Qk#dZr=k7CQ1j@Xhg6Vt67wF)A5AO`AVYmE0(%kXD9dVDmBRpMr%X^t~$$+ z`mho)!i}AH`oM}LTKZRdE^%uH{ipJFvu*FuK`JlqDbk(mqWOE}ko~BI9z)_52+Rur znsrF9!8h1zmC))Zi%}3Qs6bvTl^`!6sSN^*Fl%pZe@WefJqYmtajU zRA%&;6X>b=K4uqHAxQnGIM_P$I`U2rZX|p@?JM3yi~wMxzW?%o<;2WnEGL0Mz#}4D zzCX4K*I}kUqd_>-A1c>VI#I1|zf;kn7I^{ms{ueVyl&ll7_?=t+X&=kr122Q{IT3~ zg*mcs-+es(rawhSkgzm(&VIJE=i~46cfOtb$E{YLsA5h6gLa9rn8|Hq3iKpvgJ2oy6**mMsByCE2LJ3J+;V6J zAnu!&5WWhKOZMhw6N7-vMWwk?5MDueO&(>;aXqf4=V)d~?OL@8uBMCg*i*8uNzsgN z@a&q*tXpx#aq0nyAQkMU?=W-AShtN7dX~#-hYad1j7QP=@^cm61N?cixPB+$CX{O2 z7@i2n<#ygTcyiqm#`VGNSa3fkTS(7fXM%^S{nm+ikC#Si0*osCW@jI}r zSR!T|A7UW$K0PqYF)yrW=__D# zCTlWv83Vkv?vqo%UIodR%(&*4DYBXunJA3`i1e}KE*RZu>qvk?ZGIdiu-*N40O=`? zPXc{MGA|$SzdXZxkd)W;MnBn?Cq5(7fVP>3C?z2>9iWN=n0X~DtN(M<4e5`v9&|-Ga!lgdqWUm7p?QD_1>-Gf-s5}aaJG`DSE5c28xVl= z#;&#pU{br}q9Zf7q$f3mQxpwCp|+pIx{@FB zc(N1Us%qrm$SXrdMLCpQ2}@WOwzgkK|A@d*AA{pe>vL z&hkYiLVRRdvKHI*$;2(ISkRa)rDn7y*JIE0wBt)fBI2JZ(4oVkF=O+NDlgTwsxn0r zzTt<$Aag65rs;$}^hv&aDnXr6GdLSe)0tAOH$u6qqHSh`lhUejq5A zU28-S>_&U^6;v0j8X_ZH{&iQ|uRH59Z@G(Shk5JbOG zAlI;)%9du8@%eRd%4xkC{Dm#tghb`TdE4b3;Ywv9etzYfQ}5fFPsSJrEHCo)2T5Xh z;sgv|KKWd93p|Fu^_q(sWddzk2=;$cg~cK>>F~L^_IJk&?H*4rfP&aH(A@8`@wo1h zSei3RwSw3vf$ATDc1!EKn46?l1tKqGCQ#lpH6ejlrCP4SyGd`?T>T{RX+RTFqPuK^#CK3qgncKZjKOCD-D4$feWpK;`c z{Zln|fDB9eELk~0kgjpr8W4TlU5|r+y(m7u1?T#EqzotbEwb{aBOs5hkxO@%k77Ek z4Mq>j!9ke!BsIW>8zE*6T}&wlL%B=?1xRfG<`Xu`ulPe~m6c+#GmD3T-@yZJ!e+Mv zwo$qoz$e=!KXcQ9$~+IcbIs%lpmwTPOhP_1V%n*ZXn{x-5)wEQdfC7^WLwESMOX)} z@a?Okj6s?Xjpa=AhB85OQ@W$;q{!rVE%Sw?eqPw$F%P!Ea{ZupIX&qCCB(JTSE#iB zH7GrEQ!UE7`vdKH37XH?Qwvl+OA&w8E!0MP*z4HeQSp(H>;9uD-vTElN-Mzoz6f@j ztlzZ;s-Y1FHn~C__=DR&R$^%z-z2eXDU}V56gu17gRua7}>r+o~em@Kp|#?@9qs z0oHLmSa%Ks5yf?`8si?F$*6fwe1RYlSJj@ zqvQqtZ)_9TY1NFGk;%*d(O8J6z=pvvZ#?j^a6=_yDSPn?q)4`Bfv!T2pRd0%3#VJc zYIm-Qy23+Fhyzw6FTjCr2Xy`tmo-(dC~w-AX=71!DV3U%9cPjtBlf=x0%>=c3)|ms zpXLsZK6<$H>((9zDMiTcB+PxuFG9zL-jPd27mGY%Rq0AS2VLbiLF`ZnMt+)DH7IUP4o5MtI_(`8zg4!-;yHlL)Ghi%uZEpE{-<|1<_Eku8&Z2*kPM2wDT+0Mo|_` zh7oa6QS~>7XXe0~K(D0=A-y4F|GYW&btR04e#jQ?bYP^)Y(7pb9c%Ui^G8C}$K2#D ze4U-#OJwS(qUR)iy34y2_dIH@j!nkxnO_2****=_cBtZL{8sM|AGcF82JrPXvS>Gi z;rKqr>H1B@;dOQ9%4D}U_+9-|waYrt28DDPWnddU?|8Aa2@Vk=^WwwnLRwZ>M8PEx z3=}HUHwQMKHtoJ8aND<9^rVyjZWKu7^o5DM=zgpTk;>?X+0NgOh*0Da5%t>*A&A`} z>kbmU1Q>NGl%c!Yjn-<)iO9gBG=ZiH>U=x3-xJd)f3fEx}AR*!ayJHtp zT{HRU^9QD~gG=Z9_ykEcWKv*?^YY+aE4JW~q9i{PD-5eH*r{TY36oRQo#`jm1aXIf z%Z-XE*Ju=t7^ySe^i(y?Zbe-(y4}Vhcor|XGLt=qVk+0_(klaL^lj}GWCH()K8t!i z=NTW0i&zfK7uHNRzZOem2!(zo-{Oum_Onn9htdm~gWw-JCMmfJo+yIPs?OFAGOS&I zpe|!P<;}qUaEU2S-VUQ{|Jd{2Nr=0UV&(-eK$zB1fRHgEnZUG$ue~3N9 zECI%-Mp8P>cr|QTD_V54f-UtVKENKUbfqmN0KKFujoX`Z>lmsD}TMNANO7}ZL%W3*D1Qd((j`Q_pu&a$rW@1xcgq6=O%W-7@M z3(S{q_^oD^^4k^4S6&_+^I4Hxg>0Q-L?C4yWT6l-gKsls2JOlN6BgTRV9mbJ%zcl< zlEq~V7Xt)_Lk1bEporY-Kc6$Ctnc-v(Hse$?5*fyUof>6316#O{*eDeLTft1uj9iT=R|F&!1Aw z<@Sv`rv2$>8%grZ`KP(6c>;I)ls?F{e!X|e5~yq>hrTp%sK;6l`vl@vI*^&@$28`4 zhNxVyK{3{J=_<$&G)ON!FwC%K)=8`LLUQiNC1ZFO-IV}+pQ+1j3KWrRt^_Jr&1y&? zla$E@1KRYG)t_j!T0%OxB&f!lv7tW}9T)rE6cidEFp91#z(ercCd9uV;K+aT(1`G_ z8<5!#xdDx-!@BTSwb|7|r-bNw+XQv`200bnq=ME&3zpj0zWJZf((s|;;=N8{(*e2M z{QbF>%GMw~l>E8J*i(#xVOW|W>2i}BAHF?uH?as|I zgA_ymQS*TB`mI#>#gap9A3>=vq6cgE>x@ zlX6FOQ>KF~tZ4*+dshaCLgjut&=r@WUm^3?&)XNN7oEcdF~0Yms122|P^PWwUq^e|jx0a#jl6^Ls0@;ommuipcy)eF+=sEqg9ZI$ zc3K@$cXVEisj(H1@Ejvh9ly&7j|n$*9+h)5NlO|WX3b_|ET~CBq656i_Q>-7B>3>XMO~3#pSaHuY zMMh1dqzui-rtjBDO~Ab2^!07QVB0m&^%)v9ll5_ieXa@$XQ;|FvHQzQWkVGJI$d{~ zlp_%K9?K&a`xxYb&{;wmBmOB$XemFUA8eMk%o&^z0HLS?X|C^lg(FB%a)_mq|1lHV z1b?TF8z3SNDeK-l+h5A5HDjL#wi26yyo9d|%%MjA)HUG@6KH?^(;K2dgzPrF`LR|i z$oWo>4kZS4M}r8p=Hq|98v;Gssu-G4)v|tEJ9ypKTnRACZEds$4%8HgPpVCQFEXB4 zDYzO0k4-*wFME#Tp^6XGH4tbSJMEp0o4-uM(1+k7hh>Ppcl6Mw?%*dsRP7&u?5kRF zGgkcbZl@qLIEXFL1`x7Q3+RQP#UQ|L3O%XxZ}r)~i^)C$p?oiY>u{F%?ABC8j_j^M zdjPkqd9lkU|L=e!UuB~XO8YP>YXjQ+-J)#u=D#lEzkg9=j1nl%$GH3-cl_4Sln z(8rzp_}72`B2J_`fm5+Y;9n|xBqy>ifK;*zY%!bu+b{nwy5xrh_~bc8Dl7kcCDb#4 zb>}>lUll@xqC@Os+H&yt^qqD)h1YqWR?(};iD#yeN*J5;YiF7HTjfE^-hJyommuo| z7iGLlhPoqGk@NXq{)i?vNR&@)9Jm4F2O5xKGaJwaI3U}#*u;sDNeu{aGLq~dubjAR z5VX3Ws&3#v_$*|_67oR<`P$3ne;+)){QPraww565M#`nyBQ`c!x;-7TN) zMc)HQC?ezGqusv6-E_$nx6TRwu9qdy9!@D@SjnA=|C~g@hN}4l3DcMkrEk+Iq;HuF zq&y~z>YivDiv&@< z9Zct?a%_MfufSnAM+Qj)HF_UXEUq+zjFf)Xr-qPCF8UzW0zQ$;h!-bYQ)9CrdOWM< z+SULSV3}kfwrQviv|IHcQU9kkXdXvI=NX@YuSSvxdAQ(jw_&h;0L_s62n`d`HSq?y zpP$`HcK!@|U(u*{CFIr3t16QbzCr2rq8OJfZC^TO{>XRNxDdUh&+$Fq=D?0>!IGz) zV4%$Tq-|C+`^&i|y_a_vBnrCgxhGcSWe@3Em(SrR6g1{3baoHdnU}A!;vCJcwyUeP zGql^qpgp_7FDZQ9n2H7y5WG%P5l?x6*-(P*lZ<=qcSgQLce*`kDaSJO1UM_g7c{y4 zvR+ai`6SSG07aL%Gg6u#Na4kcHwtVN)7R_L!Xc3E%8zCS;&fsH^s=`%*Rw!7oto5@ z#^*2tihxZo07}+^0Sf#KZp$adww`^T-nXIekj$S+StQY5BbTVTbq!D#w*fECsC)_+ z!#65`OBV5;E%@PGkCGy}*Dk=l9w2v;0FxF2ZKbqeR?x|@vjxo}v4*L95O%_W^)I-w zmC?1O?B$SHt~OaLgXA`w0c*j^L31( z0`4-`kX6@yt$BfI#G`DfS0|5{PaVAlmek_wT|$A8>f5iR{JrWaO)~=gk)brjYlxHc z=-lI3;;z+3Lr^46SsVQAjH-Ny!VI`HV(w=(U0l=UaD~y~n|6wug#b(v)v6}S%I*j< z67z`7?_eN9$!{=6rcz~e0C;vhQRe_e?LSq^kl`!j9m+%tGXI(6{Q zgGJWPrB1h}l>Qw`k!p;}JY%73+dQFMLi`~LI}c;uag2~Se+>-^#j65^uQRz-m#2MOS-Eejk5L5zpbCwfVQ^*NZnNA%qibt$6 zwB;k2(R+QnF=Pir_a3O&kUEi zcw)~2$D^c11l9ug0D4YHL>&&zpm6&<{-1jFRWwvhpy>eubgFP$nVnq0#Hlg&;Y?8* zz~w0MpKOfx$*1vt(@C8J=zcWA2T~*j;S5-8X?Q)>(N7hHw_J|shhR2JEr=v2!v#f| z*%kSRVbKwx#mCr=pdwJEius%qf+f zPj__|ZVK)OjOK9R!E}wnxWpQdO7zkHQlJboKq{GF>1f4KL0&-Y2Id{~a}VYZl!%*& zOVRZL-dGnl(H%~*Rt*LkS~CQ=4$EowL3;CI>p%W;W1&G#jsvTV`(S((TvIO!DQUB~tWyNZz8%L`lvR5SMdf)I$gCN#Hw;)f*++1boIbSZ*PiI#? z)r13@@RFY+HJ`L!K=v#A^+kv21T`QDie@==wuD)>zi&A<{1_I9>@I!RHV!gk%sGb# z>H~Rsvx~!IH%y@N0db;14#Hz=I2XPxwtBIf&vOULxZ&nIPu3>zi^jTUIWCHf7LR^O>8(tOdnR;oevVV3C`Wja;MA~RABDkr z=(L|6DX|^4-7K|4-}8aaD`PPqEm@r2S>hfNo_1y6`)+ifZ*5zzsv6r6Gw*npytL<7 zOBw4ztcKTnqp#t?_DTk=#)_LlTNCvnQ8xpjb=t|J$E7k)?-`HS+mxxpwszxuZqlST zxRd``e*y}j>QDZ5A5!?R$Op9mzmg5uaix`Qxw5g^H8yhhE74bnns`|9N0It~-SHid zUfRT3kmJl_{~Ii`S>T+Q9uyv;sO;GVLba#sV1xs4^1C5CU>g;9S|#;FF0&#~V6?^i z)+v9?j)c!Xw*h35)fM&ZEw&?BFXi(LCj+<(F~_P6BrfnHeMf16tU(VK{5sd2&M1q1 zrG+_m*w453Nb#~L@l1~euM;|@N!b*UAkbVwhF8KcglR9r8&K|(>-mLLb{W;gn4L9L zF)}Mg4OjL!`Yg+FZA@5Vbdx?X@sbAf1R;Ti?@ZTf8+t1pv9I90|62j8ri$@yhvYct0F#<0#sePQU3@ z;3ArbN*PzSSyyJ&2cuqoqOC+fSt5yCWIudd!%++Y}dNmeN(dZQ6^1s+A#j<<(qFms-w9mD5dD8dA8nt^sMi%E8fUZ!E%Yclfk?#~9)$W3>@a z6ZT50Ct5887s2F9#KMaoo$=DOStCCQVS%aas4%(j@K9 z_A4FwAg!}Ut=c!uF>}ti8*ijCIxElK+Kb!-l!x#>iYXtsK6ohJf2}9wDYFe@z!(yP zy9cewlaCA?3oN?wU?7LJ!4-qQq+@np5ljH z1blzU;m2LoBfMEg*uX9hlZN`ef()9UYu&iEDtuy#b&ie8DiSig+4$P+A2whe4A#-? zqmX^5=jC5mD-lbo;XHIZuJ=t7&sPVLn$nt&7i^QOg|H?d5lHBp3j=Q7U=Ld{wT_;YIk z4AtE5{(0yZ3LhY`V2qh{-9OAHhG8XN6v^>!_L}QV8?Ox2afqf#yx}y!l;zThU^0j~ zmyk6Kr-Tw06Uy)jek=EjyU!toahv3FV#IXJCx-PYhpvOcR_4e0(L`)*cMpz508akg z#k$8%JO_RB!HY+ezh7ybB(#Up(KcySIS|8ir96ihNEof-q+}F%rYBD`Oz1lpSjCb@ z>fv9sxb6S^%8&xo=<`SHpM#(3@N*SUjq&5po>G1p7RjUd+&e@Y{uocdG&r@!;`_CW zsF*JL2o?PWlV+N2?tR6bpRfUx`%9fG_GexN*;Ng>*dkx@ChcwZA}BjF8atj$LR__Q zo8-!jvtB10L5G%5f9G~$38m9TDa4nB;h3vexCBeeWtp{AB?zTDhYk3d6CG!H9o5k< zxv$bIuMOaBkRiU`X2Z{3;;yB^FE{S@k_;?WR`0n64w3Da3{_P}(swv&x|S%!UK}aj z9eF7H_TnwM0SxW3YIAr%E{Ko}R0cz17))V*X*35SMH1;cK+XK_v`_Db!@?iHjnm=e zg7si}2p7;p$437KUbtPLTWN5*xfyz_roG4;1wyxmbO3)o$2du(@(cWzH7(P=EPdn? zaF6CqKpfVy0_%~Ckv|!yiCix2USLv&7|*BH3V z3#hoLm^a4Dki4)9ZE9Cx@->AEv{z(qKlY<*uSIW!i?8-V^CtZ83P6$&cN}61>FkWwlk84|1^GVs$k|Z$jTb;To|nCVV~lXdSEPr_9_ZO5Z6E;^wU$p2(&pJf#H zOl|Z8ZD#3bgH_gAnT&;78rwF8Pi+DzlT!+diy0$DScZnDGG0#{A*OYgY0G!`3ITK% z`(^!+j|IGT$JX_N$#8iHKVd#fpqjA8c%{E0P-wYZY1BmN!Kp|JxM4>p+~4H14m2f7 z&&7#keEE1wzv3-|1(zh5rg~_D(fjQI;Y*=J%Y##lHZ$xUii_*OmanKX2@};z3T4pD7y&Qf9#6&AjK)?Rdfd*%8TH+XquTnC_N?4w-0B7ZnbIYZUa@m{bJqil% zk=;9}oJTy53uWuQ4(WhLpfRcPD+b;9yjSX<_k_%4>i|IbAZXBr`Wz5Z>ldK6cg*lO z2wn=KNmh*%@CEDsp2$`yZ1@f;v24&T176)d-(Ky?)N3P7ylFFIO9K?W)O)X~f|4?& z9iRsfWmCCK-jNKvfcM%4@yIbLB;K=DV*MQIE`zc_h>MV`+{KAg!;6CQLTNBA;49jy zo;TFypJ*!6!%W{?yLLMAoIf zjH7<)#trv+^qFU3qo!m{>Z$^2BV$e4NL0oxAHJR`%@Xl_9d|FwcI@`>M;`9bDLtg{ zSOpgiaVyRV)m?4BszBTi{C5~}(Hdl0XPa<&50e(7-&IQ!SAHm>rV^m!^j zF%i+7%#dS2l?@V>Y=a^Lxzkfgf~-PxqfsLmey($^I(iJ@J7NybIJb);ay+x8oaJH9 zyW9FjkuJ&tq-bsB$klnY-FN&2HOy{^+B>Scp24QHa?Ku(#T{ zXBt4bLZE@9e0p>N;%#OLweA(&vJypfpN2QY8W?3MOQbsR=Ax*~-Dz_^ohe>fiT~bx z&nNX#K!GWz7^0C(1A_^vZs4U{`acr+-ETSMFQKP#>|;gAj5-<`d`mOR_AqKm8V_A| zJ1Rkf=vcIH$a2^E>93q?vL7GphC>O6MS~1!7xLJa(rzzb@%|ux*uj>&ZfJjkT7-2E z7STmPBcEVW5TUYMkDME$fs3B}wkrx+Dn*r_=lFTyhtC$x*>=iDZ%yq=FTvns$)L}j zrc)W!ywO$Oe4%{5GM>n44&%9g$xx;1P{7x2GTE{lB@g>1n;l%QL(@OVu*l`pf7ZoG zL(?8RI%xx2OsN?P$S-U6e<6hJ8M&YKsyt+&Jwb^AGGmBp%6bef0d!kEmR0*VPqE+o z0{-|XF(xZ_Z#92+;~`+HUf=FqOR_%L_r&XC>!y#JO62}?WoswEQ=*V$qkIM=0!=P! zlnl>Pu3Yohk+_(y5p&w#F5+;JM4Ap*9jpOIPEjF+tCzVVOgCqK;wi9ar<1Vhi~OcI zpEXX@A-!~GEtmQ2b_~+R$3M9sf^DWN&Ewg$%buTueiNu;c7R?XQqJJ^Fhh7mSW^GB z0gP|R{+}1~=WXHegoOo{Y`(N#`BEvhzC}CfY(!h11FMo3`ry3D{A9v}Bt58d7h;*z zayIVrl5#uQd=pYSl5^W$T(F3I#0a`E%y+^KdmumYZH5+Hzd@L8svMH%^tk6tg%Mey z9W__qyFb>DsGYp&K38_H`TDsq21A z`hAR!+q@aZ$gU-{U3#YUAB>XS0DeEDvRwQNqhn@+T2Bh|0#>R9!0NqK?8dK}=r4BZ zAOy>!ssZFnFb+c3&EA7F+qL-XboN*wcOHKFYMd=-!uT?nUmVo43oHv#qQD=5@!V#n z)|G3xFb@RhaKkmbTNE;c;@iq=1g96<1F<7#*!o%k$S5@l+EhK``Mq$S=^hc?4|6@+9dT2j zrneeB#Wd$Ra=N!K(!Wc&V==$T?Z41w`XkOn1wDiw9m_DoT{MnII%E@0R&QlIr#_RJ zONwdN3_UtOq%Xkm?0m&N)+VGKT|w7T!9>3-uM(@Kar!~kEd{#Ea<`(Vpy$XqtZt@^U~v_w2oh!FI7*pE4@8BKMsTy? z%$^n?r5_<*2=+0Q=4y)+IFLC7M1cegiB*{oARqdutdEOaWP#?2K5I0^24sg6rgB@V zzBvPNP!c9re;ALjWo%nYuaJNzOYMU1(-~xVt|n0+x16r^7e6U3i)?z_2iC|jsm-e%UhU-L5xgB} zNEFJyo~M!Wgjd^^d_Q@o3?m+b2?qZX06irR{An)uhhD>d8#n(8R}9p2$mS%E`5AbY z)ccWNV3-FIV>cJI!ppD}M?MDbOUkha=Du{R&G!A4?gh*&?hJ(S#WYP6Y6Z4nM|A%x!yJcbYIRu*!uAj1g$RWy8WT;o*VGIJaN>rsmlW_ z)6lc&hU?2yX8>Bu%43cF5)XLvPjXT=TT)}dmPB780T|v*@H2&T5I~tb`Etn|3X62F z)7I6^7A3Wqe}SaunO^#gttMqqKztT6Bo7cVhXBYlVjxDvD0>>?(#U)KwwD)=dgiwl znslH1E=dH%YQ{)&N@{Avh?5QmtT{N>^^F{AoCby9qV9(nkGT{+H4K=ps;9s=(YkUO zDr?Oq9QYYm@9lMxi%i?oKI_NkOEyGz*;+&EKFIu}!IXgL^sG=BNlQ6BE(QI!?f59YTv${yETpZFn!2Fx=*b^98DQeB4)c2VclnY?I`fc9a96jQK28A zaqFyqnB$hSW;ElWpS|@M(8{Yxr5QLl?B&kyMsituD7?cx7L&F86USAa#=WSSJ7n>S z;yO1RyLVj=Xq2bvo5L;?)tcT)PS34sB)PO?!+HC3h9WY0K~L7?C^Jz_4)(OS%~2f3 zxOmW}zv@EUbr_NNj%$`eWW7cmZ`i(z$h7t!6=j>ksWsVaJ>XUyDYF#M zWQVwjX~%N3!-LcrVGV0WF(=tB*#y=vdmb>G>BV3vhX(K#U@F61is3SEKAr_~l}2$0 z5+%O6%xdk5rURc3M{)@_hGQ+qX3nXIkn)c(IyXV(e;%^bE3GSLn@A=O^ECK=$DQRh zDaQ%Ej?HJXx52ffS$b8spdWU6^rKz35?UPDcb*LYFtQPdD*dWnHMV>F$G8mGdR`#4 z-a2pR@_y~x!r0SEf`^oE*vV#jrq7_AgERMTqnzB-2b+ase47K$BWG9_*^I+}if>4x zqYAri4b)Tknr+|YYs{JvK3y8pZkn$1DJQ_dv8X47w#(F(IxMTVN76-k!?sCS9j+SG-egpKYMFS36HC?sEd4i_pOSI-_ zlDPyxw>RA}-|KPuZJoexS5F?7P^0gE$+Ecm=Lzdl4-@=tMm(K(<_h{gc!DEjb{#la zV`DwQgTD3}!Lsj==Evn$Zm8luTs)QHb|6V5t7l6ax=V zI&_jaN;tmv#FkF3*0QYu2hLk{aOq|5nG!}OSo=ks93R*6ot#nDB9F{yhxXURBEc6R z^?(S2A(h5$Na2JiQ1MV%)wA+s_I1on$usN>HRK%&vpC$@)CMJ*ZiSgab~w>P7Iln0 z%|-w)wNM%R2X!?zJhv>`^h=!$UBhVdK6J=`suQL|FOOsKapB%58^rNc0)QW@B z+v_@PZ_x`g4>I?Kc@%Fi?OvzHNEZ_$SYORxAgbE~#ud#QXhu@@&w#9bb81PjfJt&z z;B`kK57@c7_&OMW14|vKhDQN{S=xxe5;|LW=z0dY*x^rL;ET;&?sH|% zBX+sCvNuDv>l~hfh zH(dhOlf(%ah&buk?=UO=LoUNr4k5l5h+^(XK!4ghvtnTI<>1y5!4$gJo9a-!9RFI+ za&96A_By2nzlb7yUr4)b_DuxGGMOyg8a*mku%t@ZU@(C_$BADymrbqm#I-il#OBLZ zp&PJyT^;hR5E*ivJ4IFA*ShH`7m8< zw*f*zl^dpVk>=}d+kZT)qoz}Z>G#RU@~i%YZvpX}&H8Xw-7`Sfup}`>!4wIR8@z*D z0^6N`C@<#IWkap`zy_$z+z=TdWX!02T?{lBs1GFAQCkBaZ-@CkPXEQiD=N})druXeOTvX zsIS@k5>Ju7@Bk)V=BU*=uJ(^uPeirztel zk56v)Mpqs`oKCv`+O2L+8utOFVV9_p!afD1G!m1{sGj)Vl`ZYOtF)jE zR>um)$*h!_;R)O1Db5gGb;jP1N_wXsCmTR}et@X$mRN+T!t}e^mX|tRUB~eY(Ql|b zj+>X=WoDgwzO*QC{^`Gb=-Gv#g;U0s6NHbX-C2E${JH;Am6+*@R3;-Ux*gzmFQjZh zdYZ>`jcxZqi{648h;ecm@L}d%D6=+j70kY5EM5jdCDwuYJ4iA0OZCcj+qxBk8qmY3 z&D0JPH_hdE-`?DC>^B0gumL6>Ky%?AAr%xDRC#g>Cd_>Q1gyL9FON1S|M8G;#NVXO zUv&ur*~8iIvcy;W3O-P^@mp#@5d7AWpeiWe#F7PLT%OK~eutT+@1?gY0$ad)>Cf*04K zCAfwl#mU*c-~W?~_l$8a&Mg@vJK1}!^{i*j`I{az0#b9!6kGl)ckrjylnU)<$es4r z9#LwSTsn6?0}dYr#No}DRKizRun8`k59%(v3yVA+a!64AKfSwgfF5;P|fpQM^Bnlq%NNC(rIwrsRp z9($xu*7HIiIgkN=A&BG*X}#w~hEMsnqi9MpRLb2HShv!Badw7IE(m_E8DF9@GTJ|l zv=yQtUn>52CYiCvD`yJ<%s`N@awf&BWzYt1A*nmOZdpp59cZidm2D<3Ir4xlMuGEeYm z*$7HQiIYqhhFjh!DhLfhOD4l-+;@Fdae@m+fSNQu-gfh7hsK)K0A+jCgEiU#FN>7o zD;%9w-kWrw{%`!H2rW`@Im%}oKDKBNsyoSXq6ghCL#0ZR87}o<$jAAM)2uYOK>JSL z5)(G3x{)IErVi%?(kt;)Z-rywx&f7(jLSp>hRZOY^R9EzJ0-aQ+uYPDYhDS?hv~u- zzW^J9rPz5Gvt7=foY>D@@uUP$=xAKzn7xI>)4bE538slFYu(h-S}t$b5Hyf*9hpq0JtINJqED#=6HzC7OmxUpU@9*8#DtX zJ0&5l_W#}g15vEG#qJSGkEAfH{8OaK?4AgWKtM+HVYstqiyinx!!7g!ip$w}FF=U; z=B~Py2q~(8$9Alp=ojhmV7~NZR>&S$f^5H`sbe*-9w;c6e{8+OpRownOb`7@z${30gC!!W;ci?=#{gYz&YA(#^R)-y26x;R`QzA1zIw6U{rQz?K*8sUE}AauN6qqg zqBtYwr#fZd_1RLkzaDvS;NR3P5%Q{QP+ z7XJ|)Qd$fBTa5br{Uc_`x1R#?1GpL#*ZdsRRC6gMhQ?1sD}}TG)vo>xS>`pcSzR-9 zUwzUDco&-Qg>h{4FQ1A<0Ek-1Y9EaWxFMKxjk1h^Eo|O=ouC*K3v$QYB!1wbL`|lryiFH*9$C$bp(j%z zR7)9oqJ8#h72n924s6y#?k4xl{F}VR9)9SueSl&vv?r>FYSf7+Sq&SW;NypOVH>zKj@1|@CKzCh_4}d&N39n1FY@&| zMnL5K&Z8A@WURlKqVEAd3Pjo!KAsOi+lAXb01a$kulIBR5!p{kFaPk4A4>D#t5@Z+ z(Mgjm#L$fW#1QwZ9Y!M^83J`8rhi`QeJu|ZufG?M%vdY36#vV2(*cBgSwSiU7r+Oi zMU6d@0R)dvNC(2_j_+Ss1_Ny+Q&Z9Zz0k21;P1;Vc9snP;^PnpeyAqdT+GTST!$`M z>n>X0O~FwnGP_RyyjkA=uWyDEp)E}-lx3~@rYAl!q#%$S zce3l`EmuLD?9AOy&J3dnV0vA_(ASv$YSiM#(BQqv*MRI{7PqhiQM{=Z2@Xl89tiL( z<bg_nbsc0B4aW6gu3@5}i((5RRu6xpZ zth-#xca49|>+l}opAHyKdH{v_YeJlBeXZX9zVg){G2du2^ET++!2*F}?98|X;-UR< zjkk3V9xc*2^ls=&j+ig8u)RM^i|B9axjkFq50cqvGw~Mbgc=e*5KRuWTpd(?{&bCh zP2kaZ?FW~SBRB{ws$LMX1Gj@4+&mU@mvl@{zwdd>s^qH>%={arDV2?fU@i}q(BeP@ zIytB+HFds&Twietq{4&dp4lr`4uds9rAK#(M|9E;u9v}lYo@RnA$GOBD zZdvuY&`2-!IW*(FbI#6RBBw`m3g4yJR6|mkMhE!0*?-s!3uc-B9iFmc#qqT$5^VqY1m0VV{mML;*1Yej76p0i+)Zif#6#{d632TgjStYhNh zDHtvCi~(&x7?Ef2_k(KXu0Hft!&sip-cx3J=q0X>7)|E-Soz-7_fKybd-=*_I2>P< zRAJwi-cqq199Qy>5xVB(o?NEpUCQors!Wv0x@vQXfN*#H~j5rKcmyp{IjvHLb zYA)k|GRREy&mmO{Npr~-@^^G=qAPL}BHv+k4Au~A*-zo85Tv8g4wIcnXuYKg7Ux%# z+82}Kr5F~`KMGEcDj?HH)mp+)R+s=6C0WbR8HsY_05p%HGUEC+YhnvMVGco+i83J*V3@Q+QoR} zR4_pKx1I0q^pgPrt1$Rvlz4T#^d8-uNLYz zuGUq&mtRtxkcAE1WPGKA?nV7Lvu-YAk3y7EtozRAK0KeYRsX^&Lam+8-}2ByI&498 z34?RytrpCE=%>lkUYjh!botf|51e(qpyp>~ah#T}{*e)}vmR!3>j%V^#~Gw~SA&Z2 zKVF})lCkf6fAzir(3X&%Y)(^+K zf|bDTKpXV-x)o5}zT=IO2z)AI=Bciam?_obcxToh+oihA(=sEJg3)AVHs4z14oV`W2YZEn#Bqg`sin5E;H z{LPS$4R3D^lVI%fKl6WMB2mmoaXMHQN}_jfvR;G2#iT_)OcE&r3oBULtMU4Y9#3}1 zn?99*jYa0YzpJFT2=0MD9Zi|z4SnR+a)8IkcS1Qqm92L6zamD3(=eEMO9X_5=IC^Cd-ESMMsZ|C*?SpAMHl% z4W+ceogn~G1PordR)+W91u9;f5B5>kb>^5TLSFGp#>@X$U^Y<&S)KRc4b`T7vT19^ z*+A4p_i)C*{KT#k&~KAT+nbhZ2m%Hxhk7~QA;9Ew0~YF}R=_X9jpYp>!ug}y0Bx#a z9_zg%gXa;j)ROt{F7o^?9P=y5X@_gojE;i&VPt6fyvApIrA<=6^e=6;j4B+W=OxwX z?|BPqmtQasLHSY(WRa_;oG0vQ2)ffmX2o*9K(24jrdfeM!Q+wE;}^?%_tqD#&Is$! z#4B8R&d1{Iyc9N0?kM(JcNi=}k% z^KhGD$#AOJT>VHjv8c)C<>nuUazFdsmRScsv96E2G&h}K-7(G#cfifd9iAhj5q03; ze1Y`fvgRWuvRc7k;hrA+>wGC&)*wTGh}RzdlwnqO7X%xq-5$U|+H9wH(v0b1xL``& ze0z-j1;Cbl1x_Ho05%&lX_Xi%v5w3czJDw>OBJqnXO(^e{rin8y?=sJWbjY6>0~2A zl`^FCMej2{08Why>V~Nm+9GdDe6aNX?}{I)-x>&Th#IU0aO1L@6I|WVjMo7EUwyz7 z*+c9Gc)+x1t0@bH{Qhxo88iavy+5N!xC_+%0RhU$Jq=}^>8_W|!Q~ym!0kcYL+}AT zQ|ZlU3vg4hC{6%2q`xd3uxTFY8-N^Fcl#O}QpTbt*TiDeR*os1HoNoPqA}kP<}2!V zFxB((W_>A526_x=!$L|yc82&#^Jbp8Jg`DVkI|0=si#p?{r&@WBuNFai0e?l)clytx9m0By$R7>H~(es}Ax^X7k9)Or5*8 zCw!8^Vrf^m3p}uswV7$jE9CRNZ(<46pX~&+w@*sQy&Y`#K6o^~Y5fTI*fV|1(B2_% z-{Nl79j&?gh4`n706fY{Um@}Y z`QmZUH>}QTfdR!<#I&v?CETplm^P#4#72q$+<6|a$Y=~Hlak_T#&qs;0Es;7Ph#=P;R}ltEsoI0Sd=g!6!)`c}R3 ztIo&?x;NL7sK)N&29bRB{iU9XAXx%ms9OG$AkN_QmZBnSkx1n{?cc(QWI*>Nd=2^fUglx-Om9zdqlGEPZ zFn)$y6LoCDDO7C#qNlvO-Y0OG&Rj?6NJ1CZnglaY7y+80BoRIoKXp0q<2zH~dzFZt zIvMOp1`fsc?e2~h&DM|~6JlE30h~lZYih3;cl_GH?ri6u)CFuD*D@cByK`$gQw0)^ zQr1D|4_`MI(ZYP>;BPf2(A|BJ(Q3C?>W_N6=HSry$i4MpRPu(q*2Jc-kzq71gTa+c z+R^6%L??&iHli&Axt~+{1?L07@#zLex8|NDjKwR`3_pwO8}|Vm3T;v4&RVx)!PJFJ zP4-^>{xIa_sQhGvq!>`t+{x;>=fu1ux%O_$JL#D?w2Gi>1uY<6%kf%2mAv6)&Rfwf zZq?tamWD$gPQ_e9y)FoguNBm{csEG(n>#J~ktI#s9e=Wd>pR5gwS|}kH)r1#T!^X~ zCLjp~mgAkceUTM1rRtVh=E9Rrjao5F8ws!LeTR0c6Tv90WA6{x>zo7UWKLlCij?H} zk=W>MF=plC zeCU{wyWG0hmyZHlw}wTHQ4B2S1?08)&p-JesZ=RNO0gmQ)o72o4Y2J5*ehM52{snu zJ!x{+7i#8(Ai!*-{Tontf5hFM0J|5Zidaw3&z6%_irWQTI#)(T6rTdQQ{!IsLZ-(z zKo(ro;@?GQRX1RkZ8#Y{*#ZPUU+?3ZUh+&m9|?B=yAuhPZ-khC1K2w3Z(IO}^g^mi zpCgcLbqGwV4qC;4Qm+*VcFE7wn*g-skoR2omi_J5XlX!?7NX{jd#fwjmhuJ5+~M-U zf=cw*7AfYnJGrkPaz!?p$N!s&I^}AhQ^tCs*fw=oR_q#;TIf2J=uxWGBr;yAq50Tf zzjVOGZjkHOS~yxf*Yj?aj+1^#s5;ftc$7P6?Jd$2|DiQ_z=e@1HSg3ZZawvsOHAX@ zMdAwh#raDw`3Z5w$G=sNEWaZx67AP%#8M`N<*^xYCZzS=Vsw9|al}cai{aF9%uM*H z`Xks;KIF6nQyPFr2}_U!hh)qdPOKims39SJeLe!up?|3se|CPxT;Nx|(y?eswdyW; zK>8FEa4DixU$7MDDOmvp3rR=6|3P-*WvCL%xyJxD{l1Tlxix%xd35(Hr7nbA>3dL@ z^u$q9REoHasa@NRA2Wu0D>;Mj-q84KiQ4FPqmyS4-_`FgsT!C6j+^?<^A{l8{sx$< zYO}S7?yHT0#SR9f+la1y$7~!CWXz8mi7_MDRexA4@w2CS$s2y}D%3kDyJptqiL~`F zk4!l4Y5L_`_MB#=C=$H1NL`EEi`Ncp`S8YmlQPGq_=&Umi5u2&5 zJBoGFP(-hajH&5rt01PE-zW0o>=gTF>h&h&&r@arYMOZP=}u+(=8xnphEZkkEf0wU zBYoXF>qC|uA0~MM+N>a}NV`=ZI>Wd!woY`=ytUa2e_=i~@E@jwyT3nQJL{Ozk4k49 zaP;F1#;LniJ@TWsGd5h;=~LCQE9>jmU5?l*lAJC&!-oUmFx-d4y+@uw=S7fwlvfSC z1DS1^kfM~n7~)tIt0KAM=F1{fXRP-E5!55ljW(%>7Gu4vHu7oMOUzXAHBhUZMKX67 zmC-&49GgObeDZzU&NJ!G#!U&exf+JcJ@m?VZ<8iXZ9_HY{j#tUM3kvJ9TNE9WZWRn zP&&=&Iduia)KS+7ADQUVCw+OAxGO<&3L-P~pTfTsF0;GJdopeMq*(TvJ5mUR<8Jw^ z!?PXUdoR1XGjfbVpO3F_o)+Kx|E7L&1dOQ_Lk-vUW>P9o{w&2_FT|M7$Jh?`H<&7h zP$E&D3n^x=-dSyR4#d$%()=0m(TU*vswS7$O721Q5Kq&u6DPi{`#OkIH}XG#wkr%5 zYf17K`bzKVQiS{f%hTec<1Z)Qhqa_U&kq)6ff2m|fE}>yoX`%w)WIS!ykZdm!ywTI zM$>nnkERa-c5zq*NfF(#p~2qyDJ`2O?h>39ISRUnfb)ycnd5jsnA#e*WN0XKu&{B@Mk&? zAbevGghF_7Zmt3W9Z=KV_Hf#TS^SfLS=FzZ^pID3MFD%5-BpWkv|WBn`KF%g37>|d zjF?lDRDLob3@t_#z2$j;b+_#M-Ls!@GtbIyIwf~SxY-_VRGe!fN&sm-mYK$cS!Mt& zZDkCRK7{cr?|6y}bcNx74^)r(1hSM8kj$~u<~-Kj#=Ak#pkg3*o4l88jf`Fxfl4vH z5Wf=TBF4VKtrE<2VXl<-Vsg7L6-W+pF++K}_T45#t;}hrfep&&3&u%w#ySq`+L%?l z5{^FwPhOn3nS{_nz6wUw?cu;4KSF1Y=PP$IBagX55P#hXb0&Hu%yOnc22HsT)taB> zsEX@6SU<;qXZ;h;UoalG@|^OsRIT+xd7r$e(n-w>7Vm*pK#nev{-po#UBVJQJ*4FUxuU!T^zCgh;{v8zJmU z^L)iyB;bd~q{8+6;E8qFUBOe2PSo(eR55Q;CWHFa<$2}&+G^==^T`5j1?HoIu!=Cw zo5`mFMY1Qs*L{9kU(sl?G_ip~9DfDUW||L@53S86Et`-Qn;j%Q8NhO)pcSZ-bOR?QRCWoyywA$B4`b-Eu2|0lyz{;Jga-Fqymzjq;J+t>^IxkMW27wzn>EbDv+C zHYeXu>Hb-ZOZ=TOdjb#hyW7KYLR5~{tyu>|Kp$*&CpPG-VgJIF-r&e6ElBA@a>i2V|;7HLC>HOmXj^|wsP?Ot%C2wLJl8juRLrH$bK z)Y`f}tBeh-+4>TtbBfx;2yFZ<5Sj8hwv&a}i0j6UtH9*fN(I4B@|}|eZAubK5UC+| z(9pT+)w!gTm9hU1{Z_^K!VcTRn0FuWsT4i>`p&kpMEG+?b2HP-b`Rf#6*2{;?EmoQ zy-fx62(7scun*G%VsLCyE8*?13IYZ@Mj0v0g!YFn)uHpCjO?qnCzalF?w?$HT%l%D87S}@8oxLoF0>1ZlUM}X+dTkDo z=k0;%Xrxrpv;drMgoteE4-Z!m7InczW zX_mWGDZylU5|W{k0anaEjr5-+6T;M_RWszUkEMKyh<8Nk&WyP-lDm5{Ee+y1d)o`T zL}^g%LH<0F49pY<1$&;wQ?3#Rsb7=_PA{~FL{efuE344#40%1gwfiWrOqlU1_tsrW zV0;dHVWJc3PiG=*&F7mVrA8Um;6s{%zJj`~V6-Ud&e1VTl51vS>E05jO_HA`lssZP zkLT5Uhv2^c!W?a%HXh-x6b1^M55Pg`T6C~I4^?CRH>QzonuEn`;WzTTfTz7zbJ@*j zY>zAc?PP_p-*E@=wI?6Ej99CBE~Z0Y8b}3dqsOn3_XNKnz9iD2f562p zGJ;#aTMyrh7T$3)B0~QL;sttZGj>&+$HY5(or&FwIL)tK@3gboC&Lcg0?DCc7H83y zXVJ_pM&fyY;{qK&LMq$nR?nN7u4SUyyinrUY@+45og3QO;SH_C%W~cV?sw%R>wWSq z1?0|g=UfZDe{*cg%s>AzG&I2O_3fSa>rWNUaN$Te)1S@b$X}2?UeO#84!oH8;!MfI#CQVaFA@)$Y@xf3gf%AzLW%^9uMF zm-z>}^>iN!b>v@md)n4b$N&o)Z4H5@f9lv&BFX(B64Unj@+#X|Rg#K;L=)RK2#{g*7+$2MNgaB*yB3mY~dq@XP74PYN z;pv1v;r5L@$Lcr`hokaiVRsJiFM1n%H93ApPzw03Q+0wl9^l2@7fV8JcDG>AP%;)X zfzHr9UPYr~!(+8DsN8V{{_H)`FOERH?x9d3I)A7jxI%62{+b<~;LM6LFDxqsj1gpZ zDoL8R@#KXd1|}QsGpl*(I$tlwBpNG zPoDo7Syz{jjeTlOli(Z**5SUIy+gPAg7FpOPtUwp{dFPJ$CK0HuW^bu-LR5b?*ryp zkKr82lG?&{V#cbJqp<+YZlgE9Mv^&=p~|!{Yc(Pz@dVmGQJQY^>+c9EW?{zGVvL`= z9Q{2dH!lWiztCO}&l#!2ae6#y=4lMJi(q2cG`9hRyr7+;wzed(ax00sX$jM!9=+9o z&fh1pV>4*p>g}0$u@NdeI_>?p=j);~c8`C0bnM1NQNzx(@n?R{G6?TEN{J!5!kiDb zCdUXWJbDGGRQ0a5UrV+{dW|J_E&~E-5+Ps4+bEC|N94oYyvjBrA^Nj-L^el}0pjvr z4&U0cUd5oZP8t7HNdx@NoTtX}h%drsNaAyL1eM`of-pa>JecQzwU?is{CZv=;&-yR zB5FZmn&;a`Yp`7HVj%G)VCo}BouKCKuiDnn%%xGh!NPtv9vtkg_IbnUU(%Q`j3 zf6el7AkvRKJB2NO-JN_skDrG6yz;T&TBmco$+N7(UMR8^=~(|wob0r{m3%mQCGwu5 z1c{i9H1b&H4*$;taN&U0ONC+wWs2}Y2hJRkwU-M{R2r&m=6*xSgP-p(x=bDs0a3`y zbRJ1GZBjQM4pZ}x30@Jt{U;w4Nk-2`86=j=+v~}Cy$&JoPp>6HS+L4RK3LPYqi>({ zO&q=kaNV5*Xj->X`JI={iWBE(hy5RZ-ol%r=JoS3(V+C^4~UGU$~>8Ef8q4ayP%?qO;) zzH}`hLm6I{)a=ld%vQvQ15qJCLO`>PWq!rVSL#DZm+uJf)VAImK@8z3@W*X4 z<#c^HyOGnFv$bK2n-e@h#Z{%y%5{O18FNz-jsu=9tKX@57X({*UxBE8(VMb2r~Qh3 z;DL$!63uMt3nI!e%a63O%wQ%%e)dYZ+-=|#t z*sn6`fB5jF&ASjV|GY`8lGQU>B@8X@oT7zI{xDP&xF$AmKd`S@@0Y}YR))5 zVL%<+z@jImulhA)RP2fflHncpR^UJ;{pk#(O^}U|REM=DHs&SNa^SaZGIv;pTeX6k z6MaA5RVikSV*Y0=#wY6b=8J)Enp@a;jT89>Dv94rDIDMGDR`7cqGPOmAaVr2CS8nd z*tD7S%{o^}M&vJ-$v~?SO&iUfKAz^0aaM7jc51!Wy?gInI{Q=!LXGESQKOT+q}^Zi zk2XsG8t!*bJ3oEL`mFkOj0|BLwMCESyJgY(0s+#oX6D)H^Y(sKD|o*=)W9J<<%vB@wS;F zbRiMqD)-_5K)M#K=uAZYW7! z8~=GJZ~q8Yic@;OqWX-v zx`7YsCU~X;OJsyi^4xi+t?I0xP9GCtFtmFGA&+lHo&By|27%2pa8htC1x@xv-v<`e z8NQiUGgpTDdj_LAos-ut+TZ@#UDoDg)Lu2>P-SuTl&%z$tjt98wR3)+@vE9%ryvp^ zD=Cv1z>)R*PZT4=-N5VldpG zO7_WRR0jJ&l`Q#@n&Zh#YS(!&zr4%D?c1B^$<^IvY)oX`Ii@nal8vMWml`A~*_MT< z*6s7I%PJ;TA4<`XC4;=X{S@mNlk?&-8k<-Qw;^=9ryHi|Rq;`gn|}W!I(d4+F0T_0 z9wj|Hk+p)m?F7CUez&qO8%6rjT24vLc6c#d&fD?71JB^k{X6bcdI8R3Tg?i$?ozEK z_wa&jm6Wz70Z+ineOk2n;LCe+cX;vV3BZe#zF0GKOsZ)BxCo=wO2ONJcsRdk-!A6s z1)y=Ed-v-Y0a#AP&w$)dt>5pwbEEj2X7!zw84Ul&VfG25?(HMb<1!*i;RCu45IQR_ zduBPn!hsd`{ucQ>?9%!2wMu&b+T$xj%rz~pkjrh92cs-cwb~vybW}q%-U1Kq9cvo} zL8`C({p&KXZf5gG{%mytL-I!9C&5V&287cSRnf0@8yWY-w_1Y#XC#E=^LQB~eKhE-khrM7oiS=mE7vot311tMjlKOAdR^Ek~b%&X+Tszxr6O|3~Fpacgv+Q7A#jH`lf`(RWr{y;N} zx7wpyVi5lg=5GeVe_K%71D1mu#E#aILK%Oi3AS_y#*^|a z&udhxL-f}vG;U64yhl9Gk3@cV#vCapoAEXOx?j^A?Se|vf>>j8+}YQfEBZP(Z_7}g z{&9D`*qx&;q~{7^rg%c}XO!R9UbbU*?m*_DJk>%t}vD7>W7l`CtZwt(p01?38}NU;^`vqC)G`tC}ucE*t%T5HjS8T8%xm=(%1(hG@@+ z2vg-L(Owf}wMY6SqNw8}&BK7^)2|8$8=T}^@AtkqBV3Rjq}$6d4!iLj{2B7hFwZlWd=j2AODpLy7X zund!$hB;J^h$h;vK8VCGu8s+|Lm*mdB?;m84B#Is@z3fvQTLl}BbmXgAOfcSzvDYo zf}6H%O?5p4l^CK~xTuCjqrfSV0^*NgUsBC-kl~PYu?ow9uIfv}*9V<-Xj7x=aATdv zSY)VJ+lFp&Uuu+_mg@w;mRI=ogAHPtP(R^jJ+rsfuLZuJoXlp;{qg%}aT(h(K>Rk9 z71SXGc|ON({9w%Wcr%mc_*j9IM8R7*boQ-1ID)g1e~iek zj%J|auu79Mtay!WM^}Dsy{OaJII}x4s7A0duih_Rj5VJU>RULQ)KC?wZpS6XX6h?q z8tx~`xx6ituw2t^16T1of%kRB;uaDo+_Gu0(A?QtqXT4~j)}q!Eh#FtwdTX>v$+is zl=NWhCCU<^{HOf&NE-^DaO^cL31sZSuc^8acNVFEoyNjy9iXd3BC% zO%}G6mXwxuOc##s+Dd{fI2Z?P-QO!Lv&e3~ZIa@XoEKanQG)^GzfE3ilmJIQ?Z z{nfd*N23N=P|~5F<11(#yDVAArOnH~E-b2ZaKGA<_YV=%?g9omcymiR*ue_x1{Y0xpFw~JdW2hPF@gRFty$26Ul?GE!)0)bD%IZjvuj z4g0S@o*JR$dtv-K>w$6<1y?MeI>FouvkrrbQMi@I0~=+GBUTo+QBSdql6Rhj$hr^M zlu{o?9Q~HYLD5Y6c@TZ5!l1gd@(+y4N2m*CwWGv2{Iw+=t%5M%6bJ56@KKAq$6p(g zY3{Jt+xN%4Pn%QbfBHFA%~j;+sn4qMu{W<*@^rj{SeqGFToR^LjN!rW+NmMbhpk;I zo+L!XFb1>TCymlmW9&7zC`iG<&B!zSMZbe~@QWB#-BO?FksO~-WI02pSM;Hlwp5*& zSnXR{A92s0%%%~+Zq>~2cU{W+&l(KtN(kZ>FM=t=;MO?D6{{v~{5X|M7cIDs^jRT( zexr<`#Ct-oIHYo}JE(nYmv9=|TPjj={cxhO;K%y3cpN;pzT3+yut#69AKR6C1slo_ zIT6CTqhIR94Bl!`h<;#HM#R~}uJSc||1P^Gv7PI8tQb@FG|5?*P-e;P?c%~BrhA(? zf1UYNk7k!F+&Q!!PoP+CM@ukIgj_)>{v)9T8lun+HM7fvoWgN$tGj3=c~8l7dB$F@Is=kp%Hh3 zh3S#2B(715OEF+`IiWqor|iaCQu{>6_YWrtD8A4I*5ADERXqpNDOv#NrNA>^fU%R? zJed0f`~nS$_S&43$7x;u960CDeBEBL;Qtt16N8M`CLvwO%^tUaA2nYQJGLN!d;X~k z^C89*$s=C2P%(2HJJL8-EGn4R@2}f;O;L76S+a}AOZHh7INCd46)^)lLKrXAPG$S@ z<_-*9@EvKXV<%9TVZJI6^>WX=Xd?vO0Wo z9j55N)s%&l9Uwc%|nG%3jz&e0Isn3y zaqRU7Wk$5{asRd_kTw_~v|E(>{lbL|1HRLbi~SHIf!qInZZe!n<50>ixZ^&1z*Mn& z#)ijjj|>@i!Lh}U?T+&rq$8HN@nc)6nhI=%39M{DkNf+aJV2zITQN6xnT}R?vhKDk z^(_JS&vrokh+}4Aekz~I=IBmoQPVc?bf$U+?Mdk1{HlSJmB%PrA*d&=-TNAx31QP3 zcfB9(Jaa_(LvGqNWYUpwSUsN*opWbf36Uzg%4B!voK$#7i?x!t@ERrOUzZxx^z9hu zz=K5T5vJ^vQ=V-77BeUL_gT|fy)N!c@0&?c4v>!}VeH7TNi2W29Prpb|Et75x9PB!NkD{^dRguqOZr_=EBTifx*n+7kTRNr%;x}jijvAC9vZ0nA8*Y=EcVxfx z4(-Pr9}9_??S88sdFD~?hA38%Sll8&iHsBmeiTJ%ggeHZwm0ORDCMaHv=l04Lw4Ns zI#+t?Od1^7pW7$! zhhsm>8x(75xFL2xlhNJh^8^zNc)n-S$rB{a*K%vo4gFulx(o9UJI0_xNCl0^71vH~ zs{)lrse|jPYG0bBJN-zXy3M(%Q{>zi7kk1xS-%GoNf(M05FF!Bpx{uc|q)I3Z?2J@p-+eroOTxt4{mVlrj?k&U4| zAa%#_{kXnH#9>Gt#pf_nmg==0C#Mgjqn?b+xCNGbQ~KRFHX7`1rZaP+A(dPPS=bL5 zsI8-~&4-ej0kuCm;pEL3soEjd=8jDybyoEARorjl0t7|Y68ig$3l8;^nr5CCA5$gI zb9WZQcg>5%zR&x`QJ5uM9W6Dzc}*;_=qE8b7d>9YC4x(2au?D1nXd9iO(V@x^JKVp z7%@=U3 ziAy7OWXt*e&LiTLjor&|#(Z4Zt?h>`O8bquQ4VPvJ?9~tXr0tS9l%~NxPUrrsJ@+U z$Z(il%xM5qh@WO+_$|b@nY~==Y0l&u4+jP?T}l_TGQMikGge?m*SNccT?RBQE)U+? zEoRm3N#|OcBS#!qSXnc!4d5$(z-z7<9EUcY1!#_$3y2TNdu_df>`)XlP;Fezw##De zHagg{6!GW{6AQnjy|W21(dAm;Cl2Oi2)&;5pb2O~wG*K(-11ZG;uQ@=_aucnH=MGR ztZz_>Ey29zN_;HuB=pY)TvRbDBbvUDf6WUwV#@ipee!0ycCq`b(JZav`Evs4UeTMK z(wB*dQv$)>&d&V3qg{1Yx3QQ&OxDK$kZ&6=-joRfkA+K zi>1iQNx){C=GG|vi67N59xTFR^jySYyR+yHvT535wWdG1#Nhx#Lus%nZs(>#A}&ydaFBrc^h1;a@`VT2JDp{e0OO(7QX6y|X`1oxFFP*e~)o z0x0DznGL|v?R*cDT>v0nZz#@>hd5gA%_*zI1}pzzeCRW&h$X47;4@iFPrwM7Yo-B}=E!!;7LXY`as`&(YFPY#$ zc;m*dK9&%EO#YqvfqxCddonb~mCPE-8!^!MFP@Ofcrb@SUFOu@1s&Eb)&Zwj{*Vl= zmY|>giT)DJZd21G$6*a7ymJ0=x~Jn1y~5y`{p2Tyy^y;o5E^!nOiICufS&gju zxMJCu=6o<(&KP@LG7);8p+4-1qX;-69|d1<@S4`i9d~=qJzVA62M21?#3&A3`8-mq zp%LrjSuwO>0VsVoOh{Ybz!5&rj4V?|A{W(FW%jT%LTX_ETP*K`jRF9?L`442x z<>3p$G}|?Ph*Ch)@mY_^0aI9x@4~h&sm&H>7AbN5G%7UCs$$&!z5;i( z#zvad$M|J3w&$H1IER}vqd9Ku#T1Pr0uP1m6yX=44KrVriqVkoPc@q*vD(dGh?sEI zhjb?o4T;tV)@}W`e$D6bKY0%Ocfqfsalxnq&K~rKJl+Z-tt3)}uFwcbBp(4i(*4 z$Cps`NUuD>vB zzs*CJ6mPenNA63`3_QDj9S%Jg23m3tmqxq2va?>e#4P@usy~QSU{TffoJr&-Piv^C z7G73fjdInFN8t-J;`rxRvMDr*JLyB|3SwVb-_y*Q?aZ3pM z4f1J$kC`9LJ>{}d`@F^&a9)W_XUR`2{xyWKkmn?DdY%vfw-#bf0V-|o5pvnarNl4W z8ii7YMgwOGO?y+tkOd$)Y!S#h&6M4}&u~)HjoR%14mOqmjS^9i^%?-&Exlf&LcIc0 zcy8xZnD#}hR8+bBHYYv@lE#~o4LzB)ZvqoW0kgy&dj66uu4+U9E8Y4VKcKU!_WK^P z>Un-h(WKx91obTeu~MWx!)d%j^|nlM?!RA12n*4vi$8c&pZ-l2F)S~V0%kBUzg|@Y ziCm!iy|gd=56(~icAMTLtL;cHdmG;L7^sD8f$(v=_{%MIes2}-<`U0@=;#RjZmBNU z(z|%v0Hz~KG)w}vvzM&CosH ze)M?W^Sfw{sx+hjDwhGOy=hfikGN&+(}6c6U|Tn@OM zkBrI(;U(~k;rgZy@bS;#1o{^9mwJNw7O(4X_3ww5Z!RXop0noa_ljhW)I8*L)$zL%vyPdZTxti9La~fId@OSXS9R=a@lpf%?4GgR%LHE}t0DJH2x*@30<5 zOD8D+;@zeR=II|QyROuNYkxlN!pf9_02ugqsS9nnWNWQy6@oY^*X9xv^wIAPSxt5k zp4dbb-->>`lz{d80Upu;O@#2%p(Owp+j$DFl73io+jDOGxn~` zhUu4LD>K@%1nsjW!)W1o4e!{|F?)e@uF;`EpTJZQ1e7(^-De1pZTEM#`tp}ON8Tco zosr$OdYOmP4@|G=g9wv&SMd0euTk@JTb9+4N5&Z>jXdWbOGHW2z6g1A?85WDY}6ZW z&Bk%WnS~hHv>+`EY6jRCi1D-N&x_kBBxxRZz;5?P4Z;Y;kf`_-vT(|EK+Gr)s z(|gZ2?RdSuy!Yu&fVIx55a)b_IGS;{c)Otdq`OWw&q{l@$c>7N`k)4 z&(!7fBci)L$Io&$6IPD{H7X_a4$E7RC&sd7{3luEX=s+hQ4(SCKvcjuO@qs5Qe46}wdwxzJS7RzQ*EQFKlplkJ*~hf-SX z=SwKIc2(F=J7#V7Io-80IG!{Vn#mqCQGE-dHj#e$FJ59g4Hhh0&5_vE9#VrLmphiCLu!qJL0S`?b$5B} zov^S-0CSw)V@5or44ab8vze(7B)&q471;XkQ8BT4F$|iS4h$KEGQ-U-MG`9+@13r+ zXSsX`ySNCOWp=GN-CJsZOH9Xo{v?AC2+fYsT6(9gM|N^K>&umrx5Z$b5{L8r+X72L zNwx?1ik|aL@7@6)uILJp4b4OQK7vKXc`NHNup7|k?uVO$&5{#)oS1#bG32ta-GEHK z2&cove!EQek!51bzS}u2VOgqK7sG^i*;5YF!b5y zS-S5tg)e54o)j1#AV~1mc9&YG$bqJv``%Q(es@d{+mNjFZ*X%=lq;PwisSIH-Vl&SJ%2dl;s)}yD z?!1g2j#^@O@EFY{h(tpgP6|l zh``F;x^R3{1lmiD%D=LX4KYgc9D(9mIH(-1lZ{sOv%Y%l8GrZW=0mi2dB(dM)pwqC z4ue9XLz=_;MH?gK0StJ^=lK?thxM&voiR1%(JAqXZSXzcfW7MHPR;w@PHMH#vfN>^ znTKhc)OGD0W9%*v*$I++yJ*e!*^PzL+m{Vae&uO)BArf&Zc*hzEv%{742UyZjc zuy2p$EQA$Mh2gJ_yw9qhj+E7z`s}fyKH_wAyo*>%_FRP<7`xAqX^T%Y9jn(LsJ_ik zUcC@NA7uJgxy~NQe_vFC;j65=H?7CYouLslx>ZiCc@DTp_itBj01%h}Z<;NrSzqg^ zD!#tInaD(YwwFW@8%?d^j-+xHDI#i+7cN}a9DYvH>%gAG>|pF|Y{9orizem1qTxiH z9xtzVg-2^t43-}U?jkg(scOBDL=ir>xvZImj4jBP^6@a!^lHwQ;IvU*|$JN52YlZIRde)X`ep%*p z&ECk@<9LhMNPO*S!s}!y&RiYzg*)n!|CvtPl8iv zS34^Nr|9QZ@08hAl`H8jK7Mm+u=pFUTfmaf+m~V`DOx(?dEzibnh^<+XA95aJCZ@o z69T3J3aVq0`{+XUiVF$R#jncBk9}P9d)qV7_sa|;X$xXYs+e0C9xPQ>)>>l>W$rQ8 zj-TtZEDaI7v^SK6oQ8{IS`QZ+i4e5A>NT%lhQAw-rmdl9UfL>&Rgd56jmB$M`7GWOgfccze158|)i-_0_$mfU4dflG8OU|WvoZcv5J zsm|AREnljhv?(dqqH4d7w)e5NKd_cFC6RdKv2r<6S$n=>i9uUJvt~86TofsEM@38&td< zlRneS4ct6KkrpP4s^>F$vl+A{X}VYyeIW-;4v(){dOB1QE=_{r*ebiSuaPUXjg~?m zZt&;}T3F&7-m$84KTlt~nC8*iS$5FUuE1YC)*FC+nW;&+{6c1)pu#8c61t9hO?0X` zLqK0p(5I_#QHZf-cKd#YX5E|jZKDg%LCM-m1K~}r?!kC0|`^!7@dueoDKUe%2wi@|k z!L7rLoyyzMyLjb=8N)k%CKu!-)6s*?BU~K?fkpJ1;CIz6En=*8nU4u4U$8pb%KGNA z?`r@&{bZlpyG^&8!TD%VNFBXWx{RcmwpPyw8+da!iM*+?Ucqw&XDDEF`|IV~3!}RN z)B$}M`|gj%2H&TzT9@dLy3d#tFj>7%a(ba_S!YuH2-fJWWhI_!fz_r4E7U4uqhaS= zupBCIj&FwhO+-!SR=IE9_Z5%a+?!8}@OSU1e=l<59OW%15D&5-Ylf(SB+r@g@@KR` zS@g=h4ZK#vUnjjb+(1%t)D=TQ&psVLnWY4&#%@rWW1%Uh`+34 zWj!O+de*A$x>idNvrx>^z0mQk1w+lZX3A_`^~3y#jqIc?6604hWoh}oX8ZF9>y13N zknB&HJLd_?3i%ebi2LFnzB%;MYs|5B62TqQ;LKi3Q!Vq}s_h9`I`>(5@bf5d>x>yp z6B$u-%`*QQ>!&)k7zsvU=8-vt)XcgkAZKv7qNq7pzI1O$-m+RRQbLJ&KoLP%Tcl^( zytsR(d9hB7G;?z)c_%LV9@T57m3D&gHs#J;o*RR*ZfGB_k;QC;hvtL1kF;;4Xv%WJ zLR2zXD31eGvd-yyMP7f4jv`?n7|Ab>FK`WJUHtL}ZJAf=FQf7*RsB^a`t#!B47A?? zA}dE{y0a?r-K_~_i>ddC1w}e;d*o{d)6M3T zVuJEdy>ZFpPl?soxePck_`8)Ea2&p(4T|+9eSm=rsw!AEJr+0fn7;MPBr~F;<}rUU z@NbV#Vcn&bh6Uc=hjoW+eaoR(WZh=pxg$i;ljUWhQOme3sd8XC*wUN6KYPs013y*} zfQ#_l(;yFa-#AgCX;E@oA4U877K?}yClRe^3Aah{{y<9 z5VA9VNSG*$ldw5*#-CP?tJIm*2n)qOkf?Iz`!%#hJ@!aOPwGWkHdftV-6ovEo>sfy zb?5s9`n$2$pJ8yaupop}%5St?p(u*4*Hat2H@9aV>HO;0OX_;MXITMvv zv!3xvIIJBeCr_?n-+^^u2ASbbi=7e^B+}q{NhVgqlpTw>P2AXC*uer0RdA3o&xKD%Yd7CU$0`v*itv4F!$b>V5a_fTSqhuFk~-s_6;vT=0V z%o1DqwPM76_vbNNFFANNQTvBW-=6{4qZ@Rot~eC#tGzr;&%g*#0LxlE4GI)p#R9~y zsVeJuZzli>87+9$I znUs~~H?+y@R2cax zPr^Hjp6}S>B}tx~`u<&eSkE*hS>f7)xYIee8ZPANV%^fTKY7HNizs4DJYl%@MzDU_ zwtg*Z_$|Wo>>t;FfvbW8u5dB+%k4!1@PpQ5FF>auq|XWRbf*MT5_V4Zro5||1QZ-j zHy?e$l@|f6fMjk_#Z!7F%~tc#Ur$?xGQV-2V?wkf#3rJ za$t8<1v}PN-3LE#RB$*y5e+@%?{*fq`seTd<2qo0-(_&E73{Clk0n7BxjF(kGbn|K=3#kG(7a{TX@f2c&JNCLR>62BCw<@JvN7|lB%N3eU5jk8#PV`dH}vuDgvbdhBK0+ufQu7QBq&_t@^`yJ zj!6eS&eU+?;fLFrvAN2m+PresKvf`Ghmg?&U=aq09do1LobqEzGaWR3ptE8UV}A~7Q=AAKT+q<54|hpj(t`y zkCzYECa#vZz#31V_4>=B`|FRXdc;r)ztEep3j8{p2*|Is04LZp=Ny2Ejv6grrfjy- zFbOH6AhTu!wb1w;YU<|fOQ%FEAo3F$upTYF`aGG}R*$w^5<~MAtnvLR)=%>Qhpq&d z3kL%M8De~ZGjf3~qAu8e0h73~?_Djs!Q0{&%NAFw@! zg-L1^z)UVXUJb})b2Um?K3FHdUFZO$%o7lV$e_caQ`rrMG4fyfmakNOsWu@*2!N8S zCG8w}Q6LPGM0%XJ8`5=!x4vSQbgl!9mb$=5`iVOdjOnp)1=b*U?Ul3SohPcCLw0Uj z(}Jo={PK^RNdWt%vX{q02$5MgbX19GqL&ww0y$oqs;=PG;4Vw?~0|lL`QjA z38ooOAkvU*IEcEctOG>luOjam0&!oc!~x`M<)eq38rm%f((xpiht#^>&g}&MHx7emvi4 z%wrH#&Mr=*Nk-ro^quDe%+@XlV=7;{9(}psiVS8}!<8KsgDJed1F{N5U96M##ufpP zzghSj+iFKz1qEm8Yd&pU&0%_bu;aH9TI@EWu)ODJ9cOdM_T+^%4gby%`4C;l?S?4Z zvCk7%-_Hk3o|IBM?}dFqZpV_rz(IwF0M zL?OjSBq!{+R5d?hPsG64P4EqM?Yree&7+Q-%9N3lt2qZwTwNl6BuW1{vwyB-#d_R+ zKrqwW&G>6Exz2S7ZiZTZt?k~PP?z0W9WAqbxYU&_G-l2Xzn}JrM@F!hxC2JXp^z>sGosy=}Sk7h)DK65OwRO2zy__cUa+6z_M3 zR||E7Ur;qXj;%jxnsDlq6VsU2(zPkNNT-LPTs!e{?vy+1gYGXo1;8-uP+5g}e9wVPy)07e>fAq2$+| zPXm&YXdiLD=jL_0vw$w+meiz1KeUAF>KoW|dZ32l*C}Z*I9!qSyeOZre3RypVrKWb zjV7BW*|P{q%H*a#mfYGI)LOZk_n^kbM*y?y!_fvpx!Vozo-5JJY}c2c-Q>rXNk<1H z+1hHm6tA39i#cEJ(?4i0rqf%wIF%r=7U;jp7}FeHT$1Pb;Z};^Sok#wZ*r}RwiS%r zWf7zMo&+!Qwwi1BGQ?m+(#6kyk=OwC#1tDvBy!XZ9<{wv9uwYVUC1J^*SzlFOidLv zx-PkM%X09G5a{heF{~!JPTD(UacoW)(g&&EQMEli9q9|0Yq8^jk8i;#^l>Nj;!RL7 z_dQubO*L0@*6lTzvu_q=(9(9`_`6-Yjs?ZfJE=fOgY^(Du`BuL@S#O7i(}a3y56Uw z=W?`U8)Gys@rF?kv6#f^JkfvgLc(=PDfzKiPR7gB{GMKQ?aD^ykvQ_fo8R^-X(u~- zPd-20qsq(sHRQGc{SYt0ma zrSz!Wk9M`sfD)8+Hkg3Yk&J6${Wi!eJw}mm;Zk^RT~9Cf7Rerc;F#8)T?m4S*H$*0 z_-lQcR|9b;uO`2KHlZ>{IpRS3LH(}7NA{0etNrL?{3YXEm*9o5&#ZxxHdIPfopc4= zbTO-<+Q?ag0TLH)x+;zB;E+T5chn-`6bxO*cd$?o`{&q=M6NdJCtYD;EKM5SPmj;5cpRw&P=kzH*eu-3hd?X2+(WQOb-=j0}c7b_c+f=IX$)3>==!MRfRuDwp z<$c(QJCxlsXfF>zL$SIpn%9}#qFQco^SXa}Hm3JcR;nIM!g#{q@M*ORJB)VqRbKs= zLkP!5fl}aA*HvaS!9QR5hLD^~Hw$E)Q1WUA2wHPkCVUQA|z+@++Y?Z>Vg#2HqNb+MD&@;ldjx4w`6M(ZI+p@fdkz?zPq#_t$g2 z8u6ye3n~SQp+hwY_0j#AOMo-k8Uh|FfY7a&Ap3f6jxK!w={KZ34=rBFUQZeYV z2tJU@D5V7EQ)?M7=pfnTIZ!i~^nozW;OpsMB-qQPMCfBZT+T?tm;K0AfobM3G1k(?dJq?$! zRKJ#kv(Idtsl?&Ptx313bG){bf)x*&@GBfh6y%!@-cQUjh8H?xh?X*~=53MEFith^)shmCSFH6CfwJ9& zx%(#7A2qC!te6}NPHqI0cj@O-cV#R(ln+b=aXX`Q^FV=ML-Fu?)&36&)ev4k-j4zn z3{wsnm1!{IdnrMOrdMGZhvTi$;-rm6^}lDk|dM*P&2isRg~`=|4NC} zuEg6n+n9fpGBXsyMxW1S-Chw_&cY2lu1-NX)>)01t3692ZF@-+?s^SX8Ksdw z#qij&bUQHTKEr33C^;^`+8=RO*RQ>Jv98*_mZ=g)R9?fewZW$5-7hWru=HI%dwrO* z1n!lMqjhYQh!#+i+IfK(>OU~WnNxMy=G}p3&C!){LvwB!ooC<>Fa(F;-%&9TO1C3K zH3^Wm^~dE)V->ax)XAWQ*k)_Kr@(J_qbgUf$_<4yD|LVWsAHTyLJ)Zg^e;P>f1yjh znaiKD4vbBmnNz$RRJzh{ug0=#&mQcq(WLkMp%Cr)SPT^Z7ho=Qr~E7!iyAs_-Pj&G zR3>GaAr!Dth~v90z^E7lq_~o~Yc|*yVkMr2$FiIIzQWeCcE+D$K*I+X5Y{M3rzJl4 zomkne$|h|48^j5f6OZoe$=e6JGO?(63zxqN-#VexwU{wWQH*gL;aX8BI#SCdIqKxA zXo=!GuO51E6fv{yS;!%s)>mK7{iK!~7kQhTQ2JLVN+4cTKJ5uWsNg=w2iTjIdEVT- zy8xLP2N_C=x}$W_3FuoGhrGxZDr5D1M$TR0X2GuqgM$1WB`|JV0XXke4mIOTHectG z7gP={bkGp$9-ch-;=o6v0oGO)j@K1F!$pQ4UCN1mz_?JUVNh!#+(t@Uc+;;m&h<{m zEAOx--(-BYXxh4_jrz7u((tb_Fpm;;X`7Dd9UjuRjBf2=mA0eRBgmNarxwA@Bz2#> zlFQc7QcXD=(wo7}*r;1Es}H8$ZoSDb4nw$)7nHlf<%se%wv~KX3)|SoKE=?v6wH3q zYl_&lQco*-C9!{al}AQ21Q84f4AAp=;UZ${_PYrWtHD~aT>TG6IJ*edt|+=>JmP* zic(Aa1f3-n!0qauAsl*ucXCeB<9Kb8DTTe1mqg|zbw8_DQ z_5kqC!E3xH6V@4%I{GDMSMIe}cZ}j$bxj$@Ahxv`mx9*h3!|SK7~IwjL#n=57x4w> z5IivH6`YE<9j|aFcXefrVE8D&@p?(#J8q&`{G*OLSZe`gWiuB9hKQ`)n>Wx3+T0aY z?_LF*3yl{4)|4HwvELBWE+<9UmE}QYIXBikSUq|m&KA;kEq2p$#3OWo`4xMqQ^gpG zmU??y*vfJuK5R)`Rwd=0%VhVxdikuKM4`A^CiV~y?wDM~woe+O`AEen=_SGuRBw$}uq|OtRPI0%MZ0{` z*Be&s^roBB9_UNOfz(}>{rY{1&xe*_{U>tq#A7n*(Fc2TFD(zp-hFvP=_b;N=)4E? zaDtN?y)3&7vKCX;2L=+%dpt(qoC;wS#Af(?yQc##z8PiGm5x9DZFh`(@kl;z*9 zcx9D4gZ5awtR5dU&U*D_Kx^3HHQ8N>cY=lvVGq|H&ULfQ4(5pB<;PnJkcE0`>ZEYb zbkm)TFN~t|qb1WmnB-Z(IaE_RV*({^C{!F*UiV22K)1!vU`b}6S<;22;pR{Gyg%Q4 z>lE24baaFKjf2TeROHw`q;puZ+k%HHGe4HTC=sV#Cd`_|uhDWSIxb&Q(!O0YKG`l` z1Y6fo`Q$(w!wntBMD>^l>_t+br4J_^OEcOeEZT%ZyP~`(X+u!Ic#+=SEsfnF zx^84pKwI;qX;98OM?TNOo1tyVFg!)3ZMs4gN9H%dQ5bho$@2m7t-G zGr5dS;;=%-b7D832%nCdPTGi}@*es?jEL#4GDSH+LKfmJx+juC+}<|dRev`j8?RhY zr1i@HdZnyH(=JX=AR*wvAKd8w9v-Rb;0t7*S1iVX5i&%YF;ev3@tJ0}`91rY$=9fuekP-w47gkE?#*TYcAiABz#GymwzYho2wFn_ZE z=!=3?eKVA^8ts0NL?ET`19$ChX0rH$T>0Bw`#lE_jBUe!2-7(pd@{*Kj}_| z3<={d_b)=kA}zRb{^4vDJj?~~$t-$tJ}lZ7oET4=yn z4!ltwtmM8sse~lpF+T~DiT>aB`Ja5bUkrTOxkxF81gn==6s92g%no;2!61OD#JGCJ z|Fow!y4EtrmwZ)OU^ZBV8fR<=BSwL4=kW|GpQsP0Di9?@qzG>22^f@+pDFM>8XC_ogK?5@ERD(8Do z&U`G^z5i6W@D$yFfPhEo%$pjQiWygg_ngaFhc9bWg-k&ru_S|q<$?^Mv7=zM%Dq1N zMQs4Biqs2OZF(?7rG1)qso6{5KBHSCB?ykd`nO(Sq|i?W~@75G+%ZM zRi<(t2gF?;BYn+Ty#Ej4&d(q3C@{FYEA#0*A|5tT{y33*1m!C;gCZauh`1`Mfo|#a zbYFB`6czB1!f>C~1|-?Pz6j9~e57nFhcob&&eAS25R59 zgqSlxVdan|a{!u^DsJN(qQoQw5Z8$bH%;XqGM*u#UOw1aNw^Tp0R#Vkv4Kue3zJ5B zhhF(kX`@{*az8%2vUg+ey7O0tcB3J$o5fpoe7?bWNGh3Y&q0@1x76id5Xs-y`G7o- z*`n}BnWhCFYNeS(`&9Si3Z`uIDTu6qt@{m!(T2ur{o^WFT|^S$&7`zJ&A~+};U8u@ z5++pDb!TQflM*wrsl6_4d$6vcEuL?Q;i3qXPc|gDYs#X?%6} zkc!_4cOwF`#0r{#k;)YUea-lE>#MW}z~ro{0E|xhD2M`EqM{niEqYrCjgkgS`rct2 zz&mdC&=F#0Fs{erjqqkRF8lJ(Roh}b+?i8rY=7{ue3qnsP$JkiDM_%tB%%y7ZcuS` zZkQz_zPV>ez`6)1f`7M_oEYbsJW0QpStH!%;&cZ=v{ZRo4Kud(GuI(XkV+v4y2~j1Mr6^oHJG zx@v*v?yBB9a8!#vNpiyaNhz{uQR9LF^TLYn&WI`0pA{iU!h+1nN_LP-xE0o$KK4fl zRw42mlY6T7n&fR4FY!S)=2J7OLN8;9#P?<39p?SM763%G4pxEcv_J2r* z{_#)|y@3a)C9jpyveh{ew0ol^1iFG=$DX?Jl)yCm8P?-rqlhr%Q5dwzVYTO7fCGIM z7;k+5CER93ufiYeq#^*xE9L}HBi2fJ^{-I12*h@Z-_~`62x)`VKYS*{%1!!!Nm^nG zRu;Wni*Vkl8;3${+p4N$@9QfBId&xS6t0U2dd9{#*wF=1d=5+d^?@Xs>H%Hve^X&E zNGQo>s|#c1C(10J76r6+&fLG!l%2O}IM}6zeub5mcZ5gewU3=7-cu@k| zQXf_bGZY{}`fj{R!Fp&4VhXZHbC(tmDI7*Y+58f;Iv74dW~&WC_S%KPTCL zzW8w*S*0frhS0kLVF0%MhMis0d3CI@IN_grpLsn$33*51OI<4#ii&`51*_f2WU*3K zuEj?G@$2KF;BQ*S%)=-x8PGkIkt&n?x18qBT!U883e#B)h6YL%==La3G9)$L6a&zR zv{wdk#wRU$VFx~d#bsq^X9zmPo3S~DbPLyQOKDO{0ZDl`L+}$s5qWg1FZmOa8{z~* zcF$0x{5I7b;R^XR_G!gTYY7Df0m7~MaS?&vCEDvBNE->LCWI!QE;C-eQQZx1nHxjB zf8b8WPvOq72N{Iiz4QxA3-`15E&1 zE=Twr;`jR(^U!0oOl+XMO96<jk9}reD&wHG=&O**^GP zx^le%3#IU2j@pR6ahEmqvTqq8X6`{fr|GD7nkhzFwSLKzY5K;zaWm01+6bNJ00<^v z?EOg#{6ktRDn|-PsLH!G!4q8Y)a09{;gCjwagfIMsCa3j+La7?Ayvfm5|zMA4BHU! zD(57eWQTX;9A91VJ*GN!>gHMLyJ9LpP8)+&&U)382Ni?3aZtc zGKIHWfgXu+#dH)1!R}^xA*ac8{aww#{Jj)Qpf~BZ7pJ;rTqUm!ymQH~X?*3V-Rh-% z2f9jE-vmhyn>;NKnrk6dae9+D&hh=5@B(QFpJ#x`UxNB4ksVL4MSfgD>_ zROIX9)8il+NZU{5+3=kD942VP-kq>F^Joeo6jH@!&TsKF6*W-%H!{*#eEk*#JD<-{P*T^ z-s_t9yR~C>dR60%5GX&~;RGp#64+(_ROnb0>ZFxD4D9KbvOUEAmvsy9LtQz7ce92u zsfn!&Ub1BMpoxO?)gMHMPSQ`JBl`6%<*%UhN1kkDiC{~I^C5A0&3n`Dx2Ex7p>Xew z*d{vlN`rjBSxo42I2C0jN}V}4oJ!!#Ti5vlGynvh>(R$+Pn?82cbtGS=8Kjq7V2G) z)G5D6()BqQ`UxIV4xevIj>)(_p5*<^q7FybCQsP)At}cZC6}X%;C9-9RP_I_4JBZ) zl$${Db61eFdYQ}hzd4JV4^8`R(QHYxHbC`|w*+vpuY^LE|Fj0O8c}`j3(lu;TQKsP zR#2UHSSFNK56@)ejM?fQqil={Ydyb4cG^9&x*>mI?}JJ(6eUo}d5rW!@esg8QlGs=r+6A`k_*G*fy`4Iqq+L=#$~S+ZGo?M z6jV|kx-Tc%GR643ohiQJJPsrMM06L%`S?oU@1lb)9VAuUm}#GQjB#3rPh|I^Y2vqM zgj8DnJNq-7z6(y&aXPv*p3BAVb0Utj_knL<)K|U^^8$E>;|-7*u|!M8gCMP9=IV~$ zowyrziRU@%dJ>+2B(=M-laRve>mR9{`<0ZussI}9WQ-dqx(#z1Z(Kio;J?>(|FLk! zDPoW4^V?NXw3DOdlILl2ZHuRTlG?<1y3|$BSyZG|Rzs+g<98hFap})J6ofYVSKl4- zPExQmsUUZFdwd^ww8YIv=_l&!=e-J8 zej!e14^hVjBarXb{MTZO=+D9YS?)`L=P1doObH@d|1AQf*hBIEA1Fw?_b8Cc0ppl|;HRR1z9QVfTHIY3qhX;<1A zHXapyB5dc6RC5dgAPXJ81m)&j7t!5ja1aZ^a&~_QqK~?5^+--ctLt5S+FG{lbGR}G zCMR_n_=1*dKN$7%9sHvvPM>c+hhvB{D7e>mz}>6&3$PwLM~}C z_w~u@fVzGd67a+`04${V<5&yi!;Omhu*oEfP-=QPv6LT_mV3QKo9C!A#xSONZuCZi z)o!$Ixy|fRFm3WpR+8Uk-*K@2;M)y?&WkF{7`+vWu-#9{F))+X^#{PMl6-G~qH(IZ zX_s+SA(5}A^}I^~fCSlcHl&%~XzQKkiknRUm+YCza2^S8rLP7!m;*8fZ-cwp9+(~_ z1$RgLUM-=RBPQ*iOTWAAb1S!6JDI-P`B}yCo^*~NVa3!T#fxT{cGEjDuZd)j3EJmg zKdrHgqb7NH?l%W&SsYaF#6LNNdiX+CARkhoY1aAn8fdH9bsal+Z1y*1&Nq~$DSd;E zj949qV9Rlha67g!AfsBasajy#?Um(J4Zk12LKB96QsH~ZTcIoSPAY+q+>e&}^aDwk znLFqhZ5zBA;yqOhfSgeN4XaLNz?v-ADU`!&Ns{BHenETLQ~)&;BT8RgUsA?2S^4?y z_OlT}nV|ZQKKd~kK1Kzlf?AB}t>oN8;q@Xr0z5q%x$~4JmK-3%HzOhX-L3jTx7zfK z`9Hl#c%%-h6E*Iei3*!wfxv-DF^*%rFVGX)fb7~C6l>0&D`o1)aU}c^Fo^*#>VAdc zr!!gd=LJ?P(*)K(oYn>Y$oRRq{%&H!e7KmZOxFh*r-qaE=MES({D)RiXCd=SVMMvAMGbbGI3(r6aPvc@*T)32a5c{8TO~N zdhL|iF=RwyH8I>+O#lT~)3h#>4I}JgxNPeGR_WU(<+M*@!#h%>0~PH~qVatCuhCCt zl%$5@ZQ0idl(+E|UYS!nV4+@+SpF`L?tqYH$0dys2$4QL5Q(G<8j5_DdSUzd2T8Rt zv~*bJiO8+z9$AO}X-wl(@pA~?Vg-@TJ!WE@ez>J8`K2elOw6$v1Go|lv?R)`rJ!kmt z{sP4Qu9?WE1IVvs{1rGYF0xezHy>(oxI(l8noy4LzTCXw<-S<-#QM1KqC_AYQ0Cy1 zv;FR23_uUVdGjk*Z49qM{#9y!w|sMad`v$Naqw3sxp~e9{5lv8Lci<238^)$$18hQ z>d_}QjX}g^HKk;QnYh=0{JZ1z4SK%g?lm*kixP&d{W%AzmNBWU#=os+QtO%`GSOzOxkqI$yGJ3D_@*7Y$(IPL031Jd81G~h*Ef?hHGu%pNV7|T3gcXD7^(I+ne z=g_U1_MyGH1n2^UFX9+@dEhRN7aK_qfnDBsKp({XknZ|vKTlUoJe!&p4Uyuk5o1C@&)x&C+sRq4DmXahK3mm~pKdA75kzd`yU^9R&( z1Lhe-XekPX`@MQb3^{WF4LGl9XJTX9SuiaYjBDq;!J$k0U0+Y}>hb3% z5$`+2-mnM{O9atG8AkB|G2Ox|ihsnr{@ii_(8=osL@T!=UJsgSW*|Bxct5W!WTm)3 zlZ$cGM`K@jgLzXpX|-(kv_4Sidwm0?@yy9m{R!Jue*C_9Xo|eZXcrJ#CWk4yH`z|s zjOaQKsM>(C_#(l7p~$&12H_KuG}05YzUB|zfbJpp%8c7@0tX0eGE)E2Bhn)Ob{BLm zk*}Uv0zUd}Ne*pSZGfuwW8HXK1eL(x3UKO{Zxz6J2U4w*DydD5{~Z; z<}z1^)&Jd_#*IGJ!u(1=mWxjXmGOb0F_0<~h(hx&S#u@hup$ByO{#Xk@#y^Cs15b@!gq%QwjiGgi9@4 zwcH6`i}?B|wt#A1pyMV@yv|`esn|Ff(-3+Dc%4zwAw%wcb$5*Qk!&;Z;B?$X1m128 z35fCfmzRy<$Il*wu={jwHC$j7w}{HVk=O8KjY^p&-t~RyX zYFYONfe&GeP}Pn;NDU1*%&b#@&TMt4{>1ruybkgZcuSqX9E1|tZ&et#_1UC!{eXdk zWeE3y8YFXfvX&6_^#C-}RO|*lT>@bwv90YNK#@-Tg}or05-8A0ssY*K&*#op3C5}W zuiU5kembe&$1F^^APijaT)A%?@!}$z8fEoenBqiADm33eS_LzzgCd2FxB8%*G>Ds;d81-yFLn(8 z(3Mg3u&W`CvXCasiiTDa5bVU55e``pk0m${U8~$ zIg^|fMhuwSUO5sV1XY(&Bjox;E5e__91iu0p94l+I=OnBs*96KQlrCAD*=ztt-)ORbEIPkS42pADD8SED1D^J-)Xeiy znmEdP>9#U`-5KgPuIWc;2JbCxi}=xb^K+ zFKBiIq6v_)dfCKv-k>{T)UJD;B%1b#6U=`M#s6);Gaz!w{P=;NWI-mj%I0-h#ZF_A zI>zUg>8^i>$|tZXbYOQYEQdN<X}b>sTm! zzBZ4!AL8I(vYhql^&M_UycFcI3qq}GI}=$s>$GG~3#5586*I+=%` zaervs{@f7%u*v(e{P^jE+Qar=(1~Ap_J7rb%esQ97DrR6KUvV-Au4HH7kw~PAHJjS zvu`r=q46z)vU^m$6(BUlCZ)j)93ZumaJL0V-#&D9N3()9i$ycy__Z=o#~va8uY}6{ z&;|!xA=NP2Kklq<*0o;k*}d;bh=t-d!2SI;2k`k{Mcb*;Zf7N(B>hx}-Jlj4P=`}Z z!zfr7?G77&F#lw?)RZ4Ica8(N;bJ5D8%{Q(N{aeVv@+s4gKzE9_<_)D|T{*TZa4O)R`!}%Ap&Gh}}0N_Zya!6U% zz6JW#+M%+~#|a5?f-5m4XA^H2J?l%{c~fRF(AMhg1CZec+TEnEa#hLTb;xu1PQVhI z%mu(9MPL|K7-NyYz94*)F$n#oaa|b*UOvZ%{Qx_q~&==HFI`uxskWlM1eyzv01E{wgp>VIK!rgEPEZFUV_Cg_JikoH+Ivv(S zII39qOvzr1x~;*cPRX2<^@ouhKRis{CxtE%>iY-L?H8I*QvaYbowv*NvgDS zVaqY|(7LXcPvVCQ?F@g)*RP*6PhSPS#*`V+AH2a$S53H#vEvi)-m;y%T&YCV;e-=W;ulmwE-uIsJ~lHa&$ zqbgf}rR@LX&|xKkDm{SfuYUI%JNS*P)&t0DZ`uV;0u6%<3iUWb4o5EH>aLE!?f3;>I_701pHyMXMKUnjk7 z%mWgabh=E}Ld8Tl?n=;{c-~R34dei^Kbv6FOy%kX<>EkJW_ zK3WidZvwZLB_p!la7Dm%8z_Bs2iVSv1n^j)OH4G^ni+-hmam z%IR63uN%6%&P>X`x%K|#w+XILLUjz{#=QJEKH}e3;pUKx5kpzqADFnv%J#2100e4v z=jvQ9`}G?~s(Bwk*3=R6sNCrmotL`yf7+9O^9WP>!Tyt#t9-r>#HhpuLborA)g*H} z#i^14)ag3qYy2#vQ2>OK7FP_#2Y>QAto{$j>Yr2;kRbqM>2&wz zZAPf_ShUr`LLH3ll)-1gUxPcdQ2y>or20S_+?f?Yz_3@?Pf1h&|AcD5$Mc%w|NY_=KY;sc$-acRg)YsIZdN4l5zuax=4(UHbdmmdmJCg+FuATjN zSdT;-^6*{-3Llx!cCuk0UV@y;9?6h2QUUG0yt5UcJraaGT?V%pSg8DbPc~B^Qbo+u z7n}>Lpc|9${}p!a;ZUz#+o@Dr88myNFxu3Pmp0ObVw`d;sZ`1#qBk_;Y@EhWnj|v2 z*yMaFJ4Q}54pH0mI^+d!MVTV_nGmnXA~8^d|;nr zUc|Aj?CXCG(9?j|nNcEz15Z|4<7_w1hlU5dK&Zk41HV(AgfG-NkKn76jq^%~ZDO9yxw zCh5*Yfe-gK{l^8h-os=dsLBU}CO;j%jU`K@^Ug!KZcp4H``&5Au8qo`Gd~2!R1IA4 zI$G+W^kL-xc%VuXg{fdkUcLLWbT#-=FkKuZQZ%SA$be z6+4GA3p{$(CE|H%HUqD8joC9kcz@`jRqCGJNo=b!jN zm3}7UmvS0!W}U2B?YgqtaNwD(e?L!#N>)al2OY<3Shqik)#BgHfv(et6_1n)!%b?^ zEVZPoixEw{)};Tx>7R&RvZEdve*LbNS;%$YB5Q=SJvShKDH)Mm0|?hwc)Qq+g!BKV zf94qJ(}I-JmM42vB|k$uScW)9OE`am$NsU*I)!~M!Le}K9uV~2>WfpEtLfR_Bf0pn z6`AWj%m4Ca+qypbTl|`LSHh&Ut6$oB`+X-PqwlCI zkGggmB24b14@j?Yi`gsn8|gak3LWX1^{Ulw>)$U$6fJnr90e6^3#2^l6+5Uu8+8~XFam-iTYL~+?xJE*v!{k9 zdtc;+5wFfb!cBVg=vqda=Hx}%5=L;OIqBz_YZ0TZPrCoGQ{B)S*gp|D3<3(;##JNb zOV;QWNn)*S+(Qj${3n?{_%XFbNm)5nWgFqf^7@h&bMQ^AO!qSzg$gqcl$mX~?76(s zPB(F1XBGUQ8ESJpHe5((2P#Tnix0$ULbx2UA$;vz=<>A3hP;0Gm&Y})bSv3wFp$(< zlx#USP+bw&@~smXmd!A6WbF)iw5f6V*}q_58kVd&mJIvwAU4Z;AAxeUXdq6-gT`(gax7QhN(b02eJlV11s!dwWOCOSwu)0N*wzeIxgRj>F1imKE2KE4YuhO}po_ABwka>Qh7d+T1-lvKa6|HL^z**A$k)jh@XLmtY+x@DWO;+2}9IisjMH^d7TTK-kg|{-KX%I)TlWVw zyK<1zsC5=@2M{POS+BFB;~1x=re7tD+*k6bzrLmE9msZAR|iayI$i*a=5x`M!A`2< zc~kf7S<%gr7OAc`j1ta7;DJymxvnSbV86UHe07WFx?X6Lr4FV10_6-qx)NH4pzM;Q zTRGr&e4__caY3}Lu2#ov>u3s&N0cChBZ*UkgR)1jU||L~m*AIO`0jNq1CGrF9c$rv zr0PW?S)})3Z4j1L<(1M|*3l6kFJ@mGRKn~&nOk*YWA3OBYsmHi`y@0MND#_X?WpSk zYELs$Q$12X_kFAbX4VbYP%NCl)vb$CM6=B|+rn};5rt-n@ z1nOg!L-i5uW^i@(spKQh^7G&P{QUBPwwwEcS_RC2#yg&ZJ`4Uym;rHXu^_LINw#2Y zvPr2!b$P1C#f!;nE_X986rD2#u|d+5&+Wyr(>NC6F0=0s5g;WWYm#mDMC^Oc-2Cq0 z;c=rGMsM>$rk)V%-(C<^!7#bI3pw)jT@3k^)$KKwm@(g%(0rW`Eij_6a14Ez%0KtN5@1lph)`p%9P<$Jmuw?gQFn`&XZsozWX*iy6 zck*-2#A8leD4TfLM;gD9@z!%=WiAC0hpW#Fxo+aDY!eBEuVPd*_AezK7jt!g2x^OS z{l9JU?c5KLdu&3UAOj?;n*t>zaDj;?NQ4}|@cgW~taE*M63j(dz_a}5g~F^>8galPM6&uxk}lG5W!zhG3P-pu^jr`T?!6IZ+-bV{tu`6aF592E;IW|H|{9t z1~iXf#%GAYT@AT?HYoX%Vf@489b=TYFl%JQtr{i)u^)@=wJgldUv@^wO-#}uJcl{x z`j5ru7ZzHAi?vO5#vxVXV$*0enjb&`Va4PAt zovA<8fovT7Mh8%~*0!}@1F(ZK{EnQ0sozK>6X7|((bg8Y{$&)d`^w#D(|h`~d%c4d zYK@vzljJM{IfKSkxOO+>`;e#>pM*|O#0W|3$2i2?P_vb@T&xm(i6n}yr-v?0rgE|Z z-v?(0Z7gGD^usA9dERuc%F}Lx9SjDJH&d%yIWFvr&MJQLLuDG~`9t2Du2V38x$x@X zxlG(yaNtiRSJ86{ty28M_MZn4uL-LFwT%L`SJ4ng3=MhmqQ0GQ_PE1|yzup%aAM@i zF1umi8m0guV-Db{zvIg6Ww_mPdhktu001zTk9iMFoKza|7h*kX`7<&m`BUGy)%A$Q zrITgy&sCe2!hqf({6aO~05lPgFqzCT`Q5HnyQ2F6)zGl8veIef^;I^11|@Ia#Hng)v&Jn?r`F-Q zgWp8a_wU~)B_$1S#z^1i@1;^gA`A_dEZZg;GtjX6(xwy&!R=(&Bm|gJ$YQ~-AXEPU zh}GegS(9ODeqo3xB`Cy_#@oWvHltnLLPZ$EI0>lc_Lls}f`Kt}Xp0ws4s0Pi98UZ{ z7X|dU@p~Eul?&^V7~R8hfn?w*=V35{$bIOO(V)fG*)hMuBCZ+P*2A8R{)9M`cnFdB z+fVP0O7OMi11cDlyzT5qg;Q`PA#Er`l(0Iq`gu){|EVSdJ0*T_@90!fQPBeHn;E1Y z3D&8a%B>Z{tTL6`%x+~18yj?wm4!tT_;b_bh18$;u3bP#0-l&Ctu1cE_t^RSrx5c6 z2q8*UxF7$+BcZs!P(`3ZJJlY;-=F^e_Q2u!BiV*(%u)5890B;VFg;^JHo6x5Uo6o3 A5C8xG literal 0 HcmV?d00001 diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md new file mode 100644 index 000000000..31d4e0d43 --- /dev/null +++ b/src/llvm-coverage-instrumentation.md @@ -0,0 +1,627 @@ +# LLVM Source-Based Code Coverage + +`rustc` supports detailed source-based code and test coverage analysis +with a command line option (`-Z instrument-coverage`) that instruments Rust +libraries and binaries with additional instructions and data, at compile time. + +The coverage instrumentation injects calls to the LLVM intrinsic instruction +[`llvm.instrprof.increment`][llvm-instrprof-increment] at code branches +(based on a MIR-based control flow analysis), and LLVM converts these to +instructions that increment static counters, when executed. The LLVM coverage +instrumentation also requires a [Coverage Map] that encodes source metadata, +mapping counter IDs--directly and indirectly--to the file locations (with +start and end line and column). + +Rust libraries, with or without coverage instrumentation, can be linked into +instrumented binaries. When the program is executed and cleanly terminates, +LLVM libraries write the final counter values to a file (`default.profraw` or +a custom file set through environment variable `LLVM_PROFILE_FILE`). + +Developers use existing LLVM coverage analysis tools to decode `.profraw` +files, with corresponding Coverage Maps (from matching binaries that produced +them), and generate various reports for analysis, for example: + +Screenshot of sample `llvm-cov show` result, for function add_quoted_string +
    + +Detailed instructions and examples are documented in the +[Rust Unstable Book (under _source-based-code-coverage_)][unstable-book-sbcc]. + +[llvm-instrprof-increment]: https://llvm.org/docs/LangRef.html#llvm-instrprof-increment-intrinsic +[Coverage Map]: https://llvm.org/docs/CoverageMappingFormat.html +[unstable-book-sbcc]: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/source-based-code-coverage.html + +### Rust symbol mangling + +`-Z instrument-coverage` automatically enables Rust symbol mangling `v0` (as +if the user specified `-Z symbol-mangling-version=v0` option when invoking +`rustc`) to ensure consistent and reversible name mangling. This has two +important benefits: + +1. LLVM coverage tools can analyze coverage over multiple runs, including some + changes to source code; so mangled names must be consistent across compilations. +2. LLVM coverage reports can report coverage by function, and even separates + out the coverage counts of each unique instantiation of a generic function, + if invoked with multiple type substitution variations. + +## Components of LLVM Coverage Instrumentation in `rustc` + +### LLVM Runtime Dependency + +Coverage data is only generated by running the executable Rust program. `rustc` +statically links coverage-instrumented binaries with LLVM runtime code +([compiler-rt][compiler-rt-profile]) that implements program hooks +(such as an `exit` hook) to write the counter values to the `.profraw` file. + +In the `rustc` source tree, `library/profiler_builtins` bundles the LLVM +`compiler-rt` code into a Rust library crate. (When building `rustc`, the +`profiler_builtins` library is only included when `profiler = true` is set +in `rustc`'s `config.toml`.) + +When compiling with `-Z instrument-coverage`, +[`CrateLoader::postprocess()`][crate-loader-postprocess] dynamically loads the +`profiler_builtins` library by calling `inject_profiler_runtime()`. + +[compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/master/compiler-rt/lib/profile +[crate-loader-postprocess]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/creader/struct.CrateLoader.html#method.postprocess + +### MIR Pass: `InstrumentCoverage` + +Coverage instrumentation is performed on the MIR with a [MIR pass][mir-passes] +called [`InstrumentCoverage`][mir-instrument-coverage]. This MIR pass analyzes +the control flow graph (CFG)--represented by MIR `BasicBlock`s--to identify +code branches, and injects additional [`Coverage`][coverage-statement] +statements into the `BasicBlock`s. + +A MIR `Coverage` statement is a virtual instruction that indicates a counter +should be incremented when its adjacent statemeents are executed, to count +a span of code ([`CodeRegion`][code-region]). It counts the number of times a +branch is executed, and also specifies the exact location of that code span in +the Rust source code. + +Note that many of these `Coverage` statements will *not* be converted into +physical counters (or any other executable instructions) in the final binary. +Some of them will be (see `CoverageKind::`[`Counter`][counter-coverage-kind]), +but other counters can be computed on the fly, when generating a coverage +report, by mapping a `CodeRegion` to a +`CoverageKind`::[`Expression`][expression-coverage-kind]. + +As an example: + +```rust +fn some_func(flag: bool) { + // increment Counter(1) + ... + if flag { + // increment Counter(2) + ... + } else { + // count = Expression(1) = Counter(1) - Counter(2) + ... + } + // count = Expression(2) = Counter(1) + Zero + // or, alternatively, Expression(2) = Counter(2) + Expression(1) + ... +} +``` + +In this example, four contiguous code regions are counted while only +incrementing two counters. + +CFG analysis is used to not only determine *where* the branches are, for +conditional expressions like `if`, `else`, `match`, and `loop`, but also to +determine where expressions can be used in place of physical counters. + +The advantages of optimizing coverage through expressions are more pronounced +with loops. Loops generally include at least one conditional branch that +determines when to break out of a loop (a `while` condition, or an `if` or +`match` with a `break`). In MIR, this is typically lowered to a `SwitchInt`, +with one branch to stay in the loop, and another branch to break out of the +loop. The branch that breaks out will almost always execute less often, +so `InstrumentCoverage` chooses to add a `Counter` to that branch, and an +`Expression(continue) = Counter(loop) - Counter(break)` to the branch that +continues. + +The `InstrumentCoverage` MIR pass is documented in +[more detail below][instrument-coverage-pass-details]. + +[mir-passes]: mir/passes.md +[mir-instrument-coverage]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir/src/transform/coverage +[code-region]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/coverage/struct.CodeRegion.html +[counter-coverage-kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/coverage/enum.CoverageKind.html#variant.Counter +[expression-coverage-kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/coverage/enum.CoverageKind.html#variant.Expression +[coverage-statement]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.StatementKind.html#variant.Coverage +[instrument-coverage-pass-details]: #implementation-details-of-the-instrumentcoverage-mir-pass + +### Counter Injection and Coverage Map Pre-staging + +When the compiler enters [the Codegen phase][backend-lowering-mir], with a +coverage-enabled MIR, [`codegen_statement()`][codegen-statement] converts each +MIR `Statement` into some backend-specific action or instruction. +`codegen_statement()` forwards `Coverage` statements to +[`codegen_coverage()`][codegen-coverage]: + +```rust + pub fn codegen_statement(&mut self, mut bx: Bx, statement: &mir::Statement<'tcx>) -> Bx { + ... + match statement.kind { + ... + mir::StatementKind::Coverage(box ref coverage) => { + self.codegen_coverage(&mut bx, coverage.clone()); + bx + } +``` + + +`codegen_coverage()` handles each `CoverageKind` as follows: + +* For all `CoverageKind`s, Coverage data (counter ID, expression equation + and ID, and code regions) are passed to the backend's `Builder`, to + populate data structures that will be used to generate the crate's + "Coverage Map". (See the [`FunctionCoverage`][function-coverage] `struct`.) +* For `CoverageKind::Counter`s, an instruction is injected in the backend + IR to increment the physical counter, by calling the `BuilderMethod` + [`instrprof_increment()`][instrprof-increment]. + +```rust + pub fn codegen_coverage(&self, bx: &mut Bx, coverage: Coverage) { + let Coverage { kind, code_region } = coverage; + match kind { + CoverageKind::Counter { function_source_hash, id } => { + if let Some(code_region) = code_region { + bx.add_coverage_counter(self.instance, id, code_region); + } + ... + bx.instrprof_increment(fn_name, hash, num_counters, index); + } + CoverageKind::Expression { id, lhs, op, rhs } => { + bx.add_coverage_counter_expression(self.instance, id, lhs, op, rhs, code_region); + } + CoverageKind::Unreachable => { + ... +``` +_[code snippet trimmed for brevity]_ + +> The function name `instrprof_increment()` is taken from the LLVM intrinsic +call of the same name ([`llvm.instrprof.increment`][llvm-instrprof-increment]), +and uses the same arguments and types; but note that, up to and through this +stage (even though modeled after LLVM's implementation for code coverage +instrumentation), the data and instructions are not strictly LLVM-specific. +> +> But since LLVM is the only Rust-supported backend with the tooling to +process this form of coverage instrumentation, the backend for `Coverage` +statements is only implemented for LLVM, at this time. + +[backend-lowering-mir]: backend/lowering-mir.md +[codegen-statement]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#method.codegen_statement +[codegen-coverage]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#method.codegen_coverage +[function-coverage]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/coverageinfo/map/struct.FunctionCoverage.html +[instrprof-increment]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.BuilderMethods.html#tymethod.instrprof_increment + +### Coverage Map Generation + +With the instructions to increment counters now implemented in LLVM IR, +the last remaining step is to inject the LLVM IR variables that hold the +static data for the coverage map. + +`rustc_codegen_llvm`'s [`compile_codegen_unit()`][compile-codegen-unit] calls +[`coverageinfo_finalze()`][coverageinfo-finalize], +which delegates its implementation to the +[`rustc_codegen_llvm::coverageinfo::mapgen`][mapgen-finalize] module. + +For each function `Instance` (code-generated from MIR, including multiple +instances of the same MIR for generic functions that have different type +substitution combinations), `mapgen`'s `finalize()` method queries the +`Instance`-associated `FunctionCoverage` for its `Counter`s, `Expression`s, +and `CodeRegion`s; and calls LLVM codegen APIs to generate +properly-configured variables in LLVM IR, according to very specific +details of the [_LLVM Coverage Mapping Format_][coverage-mapping-format] +(Version 4).[^llvm-and-covmap-versions] + +[^llvm-and-covmap-versions]: The Rust compiler currently supports +_LLVM Coverage Mapping Format_ Version 4 (the most up-to-date version +of the format, at the time of this writing) for improved compatibility +with other LLVM-based compilers (like _Clang_), and to take advantage +of some format optimizations. Version 4 was introduced in _LLVM 11_, +which is currently the default LLVM version for Rust. Note that the +Rust compiler optionally supports some earlier LLVM versions, +prior to _LLVM 11_. If `rustc` is configured to use an incompatible +version of LLVM, compiling with `-Z instrument-coverage` will +generate an error message. + +```rust +pub fn finalize<'ll, 'tcx>(cx: &CodegenCx<'ll, 'tcx>) { + let mut function_coverage_map = match cx.coverage_context() { + Some(ctx) => ctx.take_function_coverage_map(), + None => return, + }; + ... + add_unreachable_coverage(tcx, &mut function_coverage_map); + + let mut mapgen = CoverageMapGenerator::new(); + + for (instance, function_coverage) in function_coverage_map { + ... + let coverage_mapping_buffer = llvm::build_byte_buffer(|coverage_mapping_buffer| { + mapgen.write_coverage_mapping(expressions, counter_regions, coverage_mapping_buffer); + }); +``` +_[code snippet trimmed for brevity]_ + +One noteable step, performed by `mapgen::finalize()` before processing the +`Instance`s and their `FunctionCoverage`s, is the call to +[`add_unreachable_functions()`][add-unreachable-coverage]. + +When finalizing the coverage map, `FunctionCoverage` only has the `CodeRegion`s and counters for +the functions that went through codegen; such as public functions and "used" functions +(functions referenced by other "used" or public items). Any other functions (considered unused +or "Unreachable") were still parsed and processed through the MIR stage. + +The set of unreachable functions is computed via the set difference of all MIR +`DefId`s (`tcx` query `mir_keys`) minus the codegenned `DefId`s +(`tcx` query `collect_and_partition_mono_items`). `add_unreachable_functions()` +computes the set of unreachable functions, queries the `tcx` for the +previously-computed `CodeRegions`, for each unreachabe MIR, and adds those code +regions to one of the non-generic codegenned functions (non-generic avoids +potentially injecting the unreachable coverage multiple times for multiple +instantiations). + +[compile-codegen-unit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/base/fn.compile_codegen_unit.html +[coverageinfo-finalize]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/context/struct.CodegenCx.html#method.coverageinfo_finalize +[mapgen-finalize]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/coverageinfo/mapgen/fn.finalize.html +[coverage-mapping-format]: https://llvm.org/docs/CoverageMappingFormat.html +[add-unreachable-coverage]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/coverageinfo/mapgen/fn.add_unreachable_coverage.html + +## Testing LLVM Coverage + +Coverage instrumentation in the MIR is validated by a `mir-opt` test: +[`instrument-coverage`][mir-opt-test]. + +More complete testing of end-to-end coverage instrumentation and reports are done +in the `run-make-fulldeps` tests, with sample Rust programs (to be instrumented) +in the [`coverage`][coverage-test-samples] directory, and the actual tests and expected +results in [`coverage-reports`]. + +In addition to testing the final result, two intermediate results are also validated +to catch potential regression errors early: Minimum `CoverageSpan`s computed during +the `InstrumentCoverage` MIR pass are saved in `mir_dump` [Spanview][spanview-debugging] +files and compared to expected results in [`coverage-spanview`]. + +Finally, the [`coverage-llvmir`] test compares compiles a simple Rust program with +`-Z instrument-coverage` and compares the compiled program's LLVM IR to expected +LLVM IR instructions and structured data for a coverage-enabled program, including +various checks for Coverage Map-related metadata and the LLVM intrinsic calls to +increment the runtime counters. + +Expected results for both the `mir-opt` tests and the `coverage*` tests under +`run-make-fulldeps` can be refreshed by running: + +```shell +$ ./x.py test src/test/ --blessed +``` + +[mir-opt-test]: https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/instrument_coverage.rs +[coverage-test-samples]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/coverage +[`coverage-reports`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/coverage-reports +[`coverage-spanview`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/coverage-spanview +[spanview-debugging]: compiler-debugging.md#viewing-spanview-output +[`coverage-llvmir`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/coverage-llvmir + +## Implementation Details of the `InstrumentCoverage` MIR Pass + +The bulk of the implementation of the `InstrumentCoverage` MIR pass is performed +by the [`Instrumentor`][instrumentor]. For each MIR (each non-const, non-inlined +function, generic, or closure), the `Instrumentor`'s constructor prepares a +[`CoverageGraph`][coverage-graph] and then executes +[`inject_counters()`][inject-counters]. + +```rust + Instrumentor::new(&self.name(), tcx, mir_body).inject_counters(); +``` + +The `CoverageGraph` is a coverage-specific simplification of the MIR control +flow graph (CFG). Its nodes are [`BasicCoverageBlock`s][bcb], which +encompass one or more sequentially-executed MIR `BasicBlock`s +(with no internal branching), plus a `CoverageKind` counter (to +be added, via coverage analysis), and an optional set of additional counters +to count incoming edges (if there are more than one). + +The `Instrumentor`'s `inject_counters()` uses the `CoverageGraph` to +compute the best places to inject coverage counters, as MIR `Statement`s, +with the following steps: + +1. Depending on the debugging configurations in `rustc`'s, `config.toml`, + and `rustc` command line flags, various debugging features may be enabled + to enhance `debug!()` messages in logs, and to generate various "dump" files, + to help developers understand the MIR transformation process for coverage. + Most of the debugging features are implemented in the [`debug`][debug] + sub-module. +2. [`generate_coverage_spans()`][generate-coverage-spans] computes the minimum set of distinct, + non-branching code regions, from the MIR. These `CoverageSpan`s + represent a span of code that must be counted. +3. [`make_bcb_counters()`][make-bcb-counters] generates `CoverageKind::Counter`s and + `CoverageKind::Expression`s for each `CoverageSpan`, plus additional + `intermediate_expressions`[^intermediate-expressions], not associated with any `CodeRegion`, but + are required to compute a final `Expression` value for a `CodeRegion`. +4. Inject the new counters into the MIR, as new `StatementKind::Coverage` + statements. This is done by three distinct functions: + - `inject_coverage_span_counters()` + - `inject_indirect_counters()` + - `inject_intermediate_expression()`, called for each intermediate expression + returned from `make_bcb_counters()` + +[^intermediate-expressions]: Intermediate expressions are sometimes required +because `Expression`s are limited to binary additions or subtractions. For +example, `A + (B - C)` might represent an `Expression` count computed from three +other counters, `A`, `B`, and `C`, but computing that value requires an +intermediate expression for `B - C`. + +[instrumentor]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/struct.Instrumentor.html +[coverage-graph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.CoverageGraph.html +[inject-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/struct.Instrumentor.html#method.inject_counters +[bcb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.BasicCoverageBlock.html +[debug]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/debug +[generate-coverage-spans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/spans/struct.CoverageSpans.html#method.generate_coverage_spans +[make-bcb-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/counters/struct.BcbCounters.html#method.make_bcb_counters + +### The `CoverageGraph` + +The [`CoverageGraph`][coverage-graph] is derived from the MIR (`mir::Body`). + +```rust + let basic_coverage_blocks = CoverageGraph::from_mir(mir_body); +``` + +Like `mir::Body`, the `CoverageGraph` is also a +[`DirectedGraph`][directed-graph]. Both graphs represent the function's +fundamental control flow, with many of the same +[`graph trait`][graph-traits]s, supporting `start_node()`, `num_nodes()`, +`successors()`, `predecessors()`, and `is_dominated_by()`. + +For anyone that knows how to work with the [MIR, as a CFG][mir-dev-guide], the +`CoverageGraph` will be familiar, and can be used in much the same way. +The nodes of the `CoverageGraph` are `BasicCoverageBlock`s (BCBs), which +index into an `IndexVec` of `BasicCoverageBlockData`. This is analagous +to the MIR CFG of `BasicBlock`s that index `BasicBlockData`. + +Each `BasicCoverageBlockData` captures one or more MIR `BasicBlock`s, +exclusively, and represents the maximal-length sequence of `BasicBlocks` +without conditional branches. + +[`compute_basic_coverage_blocks()`][compute-basic-coverage-blocks] builds the +`CoverageGraph` as a coverage-specific simplification of the MIR CFG. In +contrast with the [`SimplifyCfg`][simplify-cfg] MIR pass, this step does +not alter the MIR itself, because the `CoverageGraph` aggressively simplifies +the CFG, and ignores nodes that are not relevant to coverage. For example: + + * The BCB CFG ignores (excludes) branches considered not relevant + to the current coverage solution. It excludes unwind-related code[^78544] + that is injected by the Rust compiler but has no physical source + code to count, which allows a `Call`-terminated BasicBlock + to be merged with its successor, within a single BCB. + * A `Goto`-terminated `BasicBlock` can be merged with its successor + ***as long as*** it has the only incoming edge to the successor `BasicBlock`. + * Some BasicBlock terminators support Rust-specific concerns--like borrow-checking--that are + not relevant to coverage analysis. `FalseUnwind`, for example, can be treated the same as + a `Goto` (potentially merged with its successor into the same BCB). + +[^78544]: (Note, however, that Issue [#78544][rust-lang/rust#78544] considers +providing future support for coverage of programs that intentionally +`panic`, as an option, with some non-trivial cost.) + +The BCB CFG is critical to simplifying the coverage analysis by ensuring graph path-based +queries (`is_dominated_by()`, `predecessors`, `successors`, etc.) have branch (control flow) +significance. + +To visualize the `CoverageGraph`, you can generate a _graphviz_ `*.dot` +file with the following `rustc` flags:[^graphviz-dark-mode] + +[^graphviz-dark-mode]: This image also applies `-Z graphviz-dark-mode`, to +produce a Graphviz document with "dark mode" styling. If you use a dark mode or +theme in your development environment, you will probably want to use this +option so you can review the graphviz output without straining your vision. + +```shell +$ rustc -Z instrument-coverage -Z dump-mir=InstrumentCoverage \ + -Z dump-mir-graphviz some_rust_source.rs +``` + +The `-Z dump-mir` flag requests [MIR debugging +output][mir-debugging] (generating `*.mir` files, by default). +`-Z dump-mir-graphviz` additionally generates `*.dot` files. +`-Z dump-mir=InstrumentCoverage` restricts these files to the +`InstrumentCoverage` pass. All files are written to the `./mir_dump/` +directory, by default. + +Files with names ending in `.-------.InstrumentCoverage.0.dot` contain the +_graphviz_ representations of a `CoverageGraph` (one for each MIR, that is, +for each function and closure): + +cropped image of a sample CoverageGraph in graphviz format +
    + +This image shows each `BasicCoverageBlock` as a rectangular _node_, with +directional edges (the arrows) leading from each node to its `successors()`. +The nodes contain information in sections: + +1. The gray header has a label showing the BCB ID (or _index_ for looking up +its `BasicCoverageBlockData`). +2. The first content section shows the assigned `Counter` or `Expression` for +each contiguous section of code. (There may be more than one `Expression` +incremented by the same `Counter` for discontigous sections of code representing +the same sequential actions.) Note the code is represented by the line and +column ranges (for example: `52:28-52:33`, representing the original source +line 52, for columns 28-33). These are followed by the MIR `Statement` or +`Terminator` represented by that source range. (How these coverage regions +are determined is discussed in the following section.) +3. The final section(s) show the MIR `BasicBlock`s (by ID/index and its +`TerminatorKind`) contained in this BCB. The last BCB is separated out because +its `successors()` determine the edges leading out of the BCB, and into +the `leading_bb()` (first `BasicBlock`) of each successor BCB. + +Note, to find the `BasicCoverageBlock` from a final BCB `Terminator`'s +successor `BasicBlock`, there is an index and helper +function--[`bcb_from_bb()`][bcb-from-bb]--to look up a `BasicCoverageBlock` from _any_ +contained `BasicBlock`. + +[directed-graph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/graph/trait.DirectedGraph.html +[graph-traits]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/graph/index.html#traits +[mir-dev-guide]: mir/index.md +[compute-basic-coverage-blocks]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.CoverageGraph.html#method.compute_basic_coverage_blocks +[simplify-cfg]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/simplify/struct.SimplifyCfg.html +[rust-lang/rust#78544]: https://github.com/rust-lang/rust/issues/78544 +[mir-debugging]: mir/debugging.md +[bcb-from-bb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.CoverageGraph.html#method.bcb_from_bb + +### `CoverageSpans` + +The `struct` [`CoverageSpans`][coverage-spans] builds and refines a final set of +[`CoverageSpan`][coverage-span]s, each representing the largest contiguous `Span` +of source within a single BCB. By definition--since each `Span` falls within a +BCB, the `Span` is also non-branching; so if any code in that `Span` has executed, +all code in the `Span` will have executed, the same number of times. + +[`CoverageSpans::generate_coverage_spans()`][generate-coverage-spans] constructs +an initial set of `CoverageSpan`s from the `Span`s associated with each MIR +`Statement` and `Terminator`. + +The final stage of `generate_coverage_spans()` is handled by +[`to_refined_spans()`][to-refined-spans], which iterates through the `CoverageSpan`s, +merges and de-duplicates them, and returns an optimial, minimal set of `CoverageSpan`s +that can be used to assign coverage `Counter`s or `Expression`s, one-for-one. + +An visual, interactive representation of the final `CoverageSpan`s can be +generated with the following `rustc` flags: + +```shell +$ rustc -Zinstrument-coverage -Zdump-mir=InstrumentCoverage \ + -Zdump-mir-spanview some_rust_source.rs +``` + +These flags request Spanview output for the `InstrumentCoverage` pass, and the +resulting files (one for each MIR, that is, for each function or closure) can be +found in the `mir_dump` directory (by default), with the extension: +`.-------.InstrumentCoverage.0.html`. + +cropped image of a sample Spanview in a browser +
    + +The image above shows one such example. The orange and blue backgrounds +highlight alternating `CoverageSpan`s from the refined set. Hovering over a +line expands the output on that line to show the MIR `BasicBlock` IDs covered +by each `CoverageSpan`. While hovering, the `CoverageSpan` under the pointer +also has a _tooltip_ block of text, showing even more detail, including the +MIR `Statement`s and `Terminator`s contributing to the `CoverageSpan`, and +their individual `Span`s (which should be encapsulated within the code region +of the refined `CoverageSpan`) + +[coverage-spans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/spans/struct.CoverageSpans.html +[coverage-span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/spans/struct.CoverageSpan.html +[to-refined-spans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/spans/struct.CoverageSpans.html#method.to_refined_spans + +### `make_bcb_counters()` + +[`make_bcb_counters()`][make-bcb-counters] traverses the `CoverageGraph` and adds a +`Counter` or `Expression` to every BCB. It uses _Control Flow Analysis_ +to determine where an `Expression` can be used in place of a `Counter`. +`Expressions` have no runtime overhead, so if a viable expression (adding or +subtracting two other counters or expressions) can compute the same result as +an embedded counter, an `Expression` is preferred. + +[`TraverseCoverageGraphWithLoops`][traverse-coverage-graph-with-loops] +provides a traversal order that ensures all `BasicCoverageBlock` nodes in a +loop are visited before visiting any node outside that loop. The traversal +state includes a `context_stack`, with the current loop's context information +(if in a loop), as well as context for nested loops. + +Within loops, nodes with multiple outgoing edges (generally speaking, these +are BCBs terminated in a `SwitchInt`) can be optimized when at least one +branch exits the loop and at least one branch stays within the loop. (For an +`if` or `while`, there are only two branches, but a `match` may have more.) + +A branch that does not exit the loop should be counted by `Expression`, if +possible. Note that some situations require assigning counters to BCBs before +they are visited by traversal, so the `counter_kind` (`CoverageKind` for +a `Counter` or `Expression`) may have already been assigned, in which case +one of the other branches should get the `Expression`. + +For a node with more than two branches (such as for more than two +`match` patterns), only one branch can be optimized by `Expression`. All +others require a `Counter` (unless its BCB `counter_kind` was previously +assigned). + +A branch expression is derived from the equation: + +```text +Counter(branching_node) = SUM(Counter(branches)) +``` + +It's important to +be aware that the `branches` in this equation are the outgoing _edges_ +from the `branching_node`, but a `branch`'s target node may have other +incoming edges. Given the following graph, for example, the count for +`B` is the sum of its two incoming edges: + +Example graph with multiple incoming edges to a branch node +
    + +In this situation, BCB node `B` may require an edge counter for its +"edge from A", and that edge might be computed from an `Expression`, +`Counter(A) - Counter(C)`. But an expression for the BCB _node_ `B` +would be the sum of all incoming edges: + +```text +Expression((Counter(A) - Counter(C)) + SUM(Counter(remaining_edges))) +``` + +Note that this is only one possible configuration. The actual choice +of `Counter` vs. `Expression` also depends on the order of counter +assignments, and whether a BCB or incoming edge counter already has +its `Counter` or `Expression`. + +[bcb-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/counters/struct.BcbCounters.html +[traverse-coverage-graph-with-loops]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.TraverseCoverageGraphWithLoops.html + +### Injecting counters into a MIR `BasicBlock` + +With the refined `CoverageSpan`s, and after all `Counter`s and `Expression`s are +created, the final step is to inject the `StatementKind::Coverage` statements +into the MIR. There are three distinct sources, handled by the following +functions: + +- [`inject_coverage_span_counters()`][inject-coverage-span-counters] injects the + counter from each `CoverageSpan`'s BCB. +- [`inject_indirect_counters()`][inject-indirect-counters] injects counters + for any BCB not assigned to a `CoverageSpan`, and for all edge counters. + These counters don't have `CoverageSpan`s. +- [`inject_intermediate_expression()`][inject-intermediate-expression] injects + the intermediate expressions returned from `make_bcb_counters()`. These + counters aren't associated with any BCB, edge, or `CoverageSpan`. + +These three functions inject the `Coverage` statements into the MIR. +`Counter`s and `Expression`s with `CoverageSpan`s add `Coverage` statements +to a corresponding `BasicBlock`, with a `CodeRegion` computed from the +refined `Span` and current `SourceMap`. + +All other `Coverage` statements have a `CodeRegion` of `None`, but they +still must be injected because they contribute to other `Expression`s. + +Finally, edge's with a `CoverageKind::Counter` require a new `BasicBlock`, +so the counter is only incremented when traversing the branch edge. + +[inject-coverage-span-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/struct.Instrumentor.html#method.inject_coverage_span_counters +[inject-indirect-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/struct.Instrumentor.html#method.inject_indirect_counters +[inject-intermediate-expression]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/fn.inject_intermediate_expression.html + +### Additional Debugging Support + +See the +[crate documentation for `rustc_mir::transform::coverage::debug`][coverage-debugging] +for a detailed description of the debug output, logging, and configuration options +available to developers working on the `InstrumentCoverage` pass. + +[coverage-debugging]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/debug/index.html diff --git a/src/profile-guided-optimization.md b/src/profile-guided-optimization.md index 03198fb1a..3597ee268 100644 --- a/src/profile-guided-optimization.md +++ b/src/profile-guided-optimization.md @@ -29,7 +29,8 @@ LLVM actually [supports multiple forms][clang-pgo] of PGO: - GCOV-based profiling, where code coverage infrastructure is used to collect profiling information. - Front-end based instrumentation, where the compiler front-end (e.g. Clang) - inserts instrumentation intrinsics into the LLVM IR it generates. + inserts instrumentation intrinsics into the LLVM IR it generates (but see the + [^note-instrument-coverage]"Note"). - IR-level instrumentation, where LLVM inserts the instrumentation intrinsics itself during optimization passes. @@ -44,6 +45,11 @@ optimized. Instrumentation-based PGO has two components: a compile-time component and run-time component, and one needs to understand the overall workflow to see how they interact. +[^note-instrument-coverage]: Note: `rustc` now supports front-end-based coverage +instrumentation, via the experimental option +[`-Z instrument-coverage`](../llvm-coverage-instrumentation), but using these +coverage results for PGO has not been attempted at this time. + ### Overall Workflow Generating a PGO-optimized program involves the following four steps: From 113585642433470838310b04f8a513fb03f60436 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 7 Dec 2020 11:56:25 -0800 Subject: [PATCH 1371/1812] Add a section on identifiers in the MIR (#951) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Add a section on identifiers in the MIR * Better wording * Use loose lists; fix typo; fix link * Update info * Note how you can retrieve the associated data Suggested by @LeSeulArtichaut. * Update src/identifiers.md Co-authored-by: Léo Lanteri Thauvin * Add TODO for `Promoted` re `GlobalId` Co-authored-by: Oli Scherer Co-authored-by: Léo Lanteri Thauvin --- src/identifiers.md | 49 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 47 insertions(+), 2 deletions(-) diff --git a/src/identifiers.md b/src/identifiers.md index f485132c6..3923c9332 100644 --- a/src/identifiers.md +++ b/src/identifiers.md @@ -12,7 +12,7 @@ A [`NodeId`] is an identifier number that uniquely identifies an AST node within a crate. Every node in the AST has its own [`NodeId`], including top-level items such as structs, but also individual statements and expressions. -However, because they are absolute within in a crate, adding or removing a single +However, because they are absolute within a crate, adding or removing a single node in the AST causes all the subsequent [`NodeId`]s to change. This renders [`NodeId`]s pretty much useless for incremental compilation, where you want as few things as possible to change. @@ -31,14 +31,17 @@ The HIR uses a bunch of different identifiers that coexist and serve different p the crate the definition comes from, and a [`DefIndex`] which identifies the definition within the crate. Unlike [`NodeId`]s, there isn't a [`DefId`] for every expression, which makes them more stable across compilations. + - A [`LocalDefId`] is basically a [`DefId`] that is known to come from the current crate. This allows us to drop the [`CrateNum`] part, and use the type system to ensure that only local definitions are passed to functions that expect a local definition. + - A [`HirId`] uniquely identifies a node in the HIR of the current crate. It is composed of two parts: an `owner` and a `local_id` that is unique within the `owner`. This combination makes for more stable values which are helpful for incremental compilation. Unlike [`DefId`]s, a [`HirId`] can refer to [fine-grained entities][Node] like expressions, but stays local to the current crate. + - A [`BodyId`] identifies a HIR [`Body`] in the current crate. It is currenty only a wrapper around a [`HirId`]. For more info about HIR bodies, please refer to the [HIR chapter][hir-bodies]. @@ -60,4 +63,46 @@ See the [HIR chapter][hir-map] for more detailed information. ## In the MIR -**TODO** +- [`BasicBlock`] identifies a *basic block*. It points to an instance of + [`BasicBlockData`], which can be retrieved by indexing into + [`Body::basic_blocks()`] (note that you must call a function; the field is + private). + +- [`Local`] identifies a local variable in a function. Its associated data is in + [`LocalDecl`], which can be retrieved by indexing into [`Body.local_decls`]. + +- [`Field`] identifies a struct's, union's, or enum variant's field. It is used + as a "projection" in [`Place`]. + +- [`SourceScope`] identifies a name scope in the original source code. Used for + diagnostics and for debuginfo in debuggers. It points to an instance of + [`SourceScopeData`], which can be retrieved by indexing into + [`Body.source_scopes`]. + +- [`Promoted`] identifies a promoted constant within another item (related to + const evaluation). Note: it is unique only locally within the item, so it + should be associated with a `DefId`. + [`GlobalId`] will give you a more specific identifier (TODO). + +- [`GlobalId`] identifies a global variable: a `const`, a `static`, a `const fn` + where all arguments are [zero-sized types], or a promoted constant. + +- [`Location`] represents the location in the MIR of a statement or terminator. + It identifies the block (using [`BasicBlock`]) and the index of the statement + or terminator in the block. + +[`BasicBlock`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.BasicBlock.html +[`BasicBlockData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.BasicBlockData.html +[`Body::basic_blocks()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#method.basic_blocks +[`Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Local.html +[`LocalDecl`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.LocalDecl.html +[`Body.local_decls`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.local_decls +[`Field`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Field.html +[`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html +[`SourceScope`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.SourceScope.html +[`SourceScopeData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.SourceScopeData.html +[`Body.source_scopes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.source_scopes +[`Promoted`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Promoted.html +[`GlobalId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.GlobalId.html +[`Location`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Location.html +[zero-sized types]: https://doc.rust-lang.org/nomicon/exotic-sizes.html#zero-sized-types-zsts From a6a9c67616c8145f04a5f6bd1006ab807926cd56 Mon Sep 17 00:00:00 2001 From: Nixon Enraght-Moony Date: Thu, 10 Dec 2020 19:46:35 +0000 Subject: [PATCH 1372/1812] All links to rustdoc-internals.md --- src/rustdoc-internals.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index 1f7f10045..895263b53 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -213,3 +213,13 @@ $ python3 -m http.server -d build/[YOUR ARCH]/doc Now you can browse your documentation just like you would if it was hosted on the internet. For example, the url for `std` will be `/std/". + +## See also + +- The [`rustdoc` api docs] +- [An overview of `rustdoc`](./rustdoc.md) +- [The rustdoc user guide] + +[`rustdoc` api docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/ +[The rustdoc user guide]: https://doc.rust-lang.org/nightly/rustdoc/ + From 1838d293f7b85fad2a14d0739643f95f8ef56b50 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 12 Dec 2020 05:57:33 +0900 Subject: [PATCH 1373/1812] Fix some link failures and typos --- src/llvm-coverage-instrumentation.md | 18 +++++++++--------- src/profile-guided-optimization.md | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 31d4e0d43..6550fb66c 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -75,7 +75,7 @@ code branches, and injects additional [`Coverage`][coverage-statement] statements into the `BasicBlock`s. A MIR `Coverage` statement is a virtual instruction that indicates a counter -should be incremented when its adjacent statemeents are executed, to count +should be incremented when its adjacent statements are executed, to count a span of code ([`CodeRegion`][code-region]). It counts the number of times a branch is executed, and also specifies the exact location of that code span in the Rust source code. @@ -181,7 +181,7 @@ MIR `Statement` into some backend-specific action or instruction. CoverageKind::Unreachable => { ... ``` -_[code snippet trimmed for brevity]_ +_code snippet trimmed for brevity_ > The function name `instrprof_increment()` is taken from the LLVM intrinsic call of the same name ([`llvm.instrprof.increment`][llvm-instrprof-increment]), @@ -206,7 +206,7 @@ the last remaining step is to inject the LLVM IR variables that hold the static data for the coverage map. `rustc_codegen_llvm`'s [`compile_codegen_unit()`][compile-codegen-unit] calls -[`coverageinfo_finalze()`][coverageinfo-finalize], +[`coverageinfo_finalize()`][coverageinfo-finalize], which delegates its implementation to the [`rustc_codegen_llvm::coverageinfo::mapgen`][mapgen-finalize] module. @@ -247,9 +247,9 @@ pub fn finalize<'ll, 'tcx>(cx: &CodegenCx<'ll, 'tcx>) { mapgen.write_coverage_mapping(expressions, counter_regions, coverage_mapping_buffer); }); ``` -_[code snippet trimmed for brevity]_ +_code snippet trimmed for brevity_ -One noteable step, performed by `mapgen::finalize()` before processing the +One notable step, performed by `mapgen::finalize()` before processing the `Instance`s and their `FunctionCoverage`s, is the call to [`add_unreachable_functions()`][add-unreachable-coverage]. @@ -262,7 +262,7 @@ The set of unreachable functions is computed via the set difference of all MIR `DefId`s (`tcx` query `mir_keys`) minus the codegenned `DefId`s (`tcx` query `collect_and_partition_mono_items`). `add_unreachable_functions()` computes the set of unreachable functions, queries the `tcx` for the -previously-computed `CodeRegions`, for each unreachabe MIR, and adds those code +previously-computed `CodeRegions`, for each unreachable MIR, and adds those code regions to one of the non-generic codegenned functions (non-generic avoids potentially injecting the unreachable coverage multiple times for multiple instantiations). @@ -382,7 +382,7 @@ fundamental control flow, with many of the same For anyone that knows how to work with the [MIR, as a CFG][mir-dev-guide], the `CoverageGraph` will be familiar, and can be used in much the same way. The nodes of the `CoverageGraph` are `BasicCoverageBlock`s (BCBs), which -index into an `IndexVec` of `BasicCoverageBlockData`. This is analagous +index into an `IndexVec` of `BasicCoverageBlockData`. This is analogous to the MIR CFG of `BasicBlock`s that index `BasicBlockData`. Each `BasicCoverageBlockData` captures one or more MIR `BasicBlock`s, @@ -450,7 +450,7 @@ The nodes contain information in sections: its `BasicCoverageBlockData`). 2. The first content section shows the assigned `Counter` or `Expression` for each contiguous section of code. (There may be more than one `Expression` -incremented by the same `Counter` for discontigous sections of code representing +incremented by the same `Counter` for discontiguous sections of code representing the same sequential actions.) Note the code is represented by the line and column ranges (for example: `52:28-52:33`, representing the original source line 52, for columns 28-33). These are followed by the MIR `Statement` or @@ -489,7 +489,7 @@ an initial set of `CoverageSpan`s from the `Span`s associated with each MIR The final stage of `generate_coverage_spans()` is handled by [`to_refined_spans()`][to-refined-spans], which iterates through the `CoverageSpan`s, -merges and de-duplicates them, and returns an optimial, minimal set of `CoverageSpan`s +merges and de-duplicates them, and returns an optimal, minimal set of `CoverageSpan`s that can be used to assign coverage `Counter`s or `Expression`s, one-for-one. An visual, interactive representation of the final `CoverageSpan`s can be diff --git a/src/profile-guided-optimization.md b/src/profile-guided-optimization.md index 3597ee268..016397e20 100644 --- a/src/profile-guided-optimization.md +++ b/src/profile-guided-optimization.md @@ -47,7 +47,7 @@ workflow to see how they interact. [^note-instrument-coverage]: Note: `rustc` now supports front-end-based coverage instrumentation, via the experimental option -[`-Z instrument-coverage`](../llvm-coverage-instrumentation), but using these +[`-Z instrument-coverage`](./llvm-coverage-instrumentation.md), but using these coverage results for PGO has not been attempted at this time. ### Overall Workflow From 3eb86119dc6da20be861a99ac7858504e7586587 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 13 Dec 2020 00:06:30 +0900 Subject: [PATCH 1374/1812] Document `error-pattern` header (#989) * Document `error-pattern` header * Address some reviews --- src/tests/adding.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index acdc2fd25..9c0da6663 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -207,6 +207,9 @@ source. * `needs-sanitizer-{address,leak,memory,thread}` - indicates that test requires a target with a support for AddressSanitizer, LeakSanitizer, MemorySanitizer or ThreadSanitizer respectively. +* `error-pattern` checks the diagnostics just like the `ERROR` annotation + without specifying error line. This is useful when the error doesn't give + any span. [`header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs [bless]: ./running.md#editing-and-updating-the-reference-files @@ -291,6 +294,36 @@ fn main() { //~| ERROR this pattern has 1 field, but the corresponding tuple struct has 3 fields [E0023] ``` +#### When error line cannot be specified + +Let's think about this test: + +```rust,ignore +fn main() { + let a: *const [_] = &[1, 2, 3]; + unsafe { + let _b = (*a)[3]; + } +} +``` + +We want to ensure this shows "index out of bounds" but we cannot use the `ERROR` annotation +since the error doesn't have any span. Then it's time to use the `error-pattern`: + +```rust,ignore +// error-pattern: index out of bounds +fn main() { + let a: *const [_] = &[1, 2, 3]; + unsafe { + let _b = (*a)[3]; + } +} +``` + +But for strict testing, try to use the `ERROR` annotation as much as possible. + +#### Error levels + The error levels that you can have are: 1. `ERROR` From a17b8655408d5241e6857397952a1844704eefef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1aki=20Garay?= Date: Sun, 27 Dec 2020 16:50:53 -0300 Subject: [PATCH 1375/1812] [Fixes #778] Added and reorganized lecture links (#993) * Added and reorganized lecture links * Addressed comments * Addressed comments --- src/appendix/compiler-lecture.md | 67 +++++++++++++++++++++----------- 1 file changed, 44 insertions(+), 23 deletions(-) diff --git a/src/appendix/compiler-lecture.md b/src/appendix/compiler-lecture.md index bbeb52aa3..dabd2f087 100644 --- a/src/appendix/compiler-lecture.md +++ b/src/appendix/compiler-lecture.md @@ -2,26 +2,47 @@ These are videos where various experts explain different parts of the compiler: -- [Tom Tromey discusses debugging support in rustc](https://www.youtube.com/watch?v=elBxMRSNYr4) -- [How Salsa Works (2019.01)](https://www.youtube.com/watch?v=_muY4HjSqVw) -- [Salsa In More Depth (2019.01)](https://www.youtube.com/watch?v=i_IhACacPRY) -- [RLS 2.0, Salsa, and Name Resolution](https://www.youtube.com/watch?v=Xr-rBqLr-G4) -- [Cranelift](https://www.youtube.com/watch?v=9OIA7DTFQWU) -- [Rust analyzer guide](https://www.youtube.com/watch?v=ANKBNiSWyfc) -- [Rust analyzer syntax trees](https://www.youtube.com/watch?v=DGAuLWdCCAI) -- [rust-analyzer type-checker overview by flodiebold](https://www.youtube.com/watch?v=Lmp3P9WNL8o) -- [oli-obk on miri and constant evaluation](https://www.youtube.com/watch?v=5Pm2C1YXrvM) -- [Polonius-rustc walkthrough](https://www.youtube.com/watch?v=i5KdU0ieb_A) -- [rustc-chalk integration overview](https://www.youtube.com/watch?v=MBWtbDifPeU) -- [Coherence in Chalk by Sunjay Varma - Bay Area Rust Meetup](https://www.youtube.com/watch?v=rZqS4bLPL24) -- [How the chalk-engine crate works](https://www.youtube.com/watch?v=Ny2928cGDoM) -- [How the chalk-engine crate works 2](https://www.youtube.com/watch?v=hmV66tB79LM) -- [RFC #2229 Disjoint Field Capture plan](https://www.youtube.com/watch?v=UTXOptVMuIc) -- [closures and upvar capture](https://www.youtube.com/watch?v=fMopdkn5-Xw) -- [blitzerr closure upvar tys](https://www.youtube.com/watch?v=pLmVhSB-z4s) -- [Convert Closure Upvar Representation to Tuples with blitzerr](https://www.youtube.com/watch?v=2QCuNtISoYc) -- [async-await implementation plans](https://www.youtube.com/watch?v=xe2_whJWBC0) -- [async-await region inferencer](https://www.youtube.com/watch?v=hlOxfkUDLPQ) -- [Universes and Lifetimes](https://www.youtube.com/watch?v=iV1Z0xYXkck) -- [Representing types in rustc](https://www.youtube.com/watch?v=c01TsOsr3-c) -- [Polonius WG: Initialization and move tracking](https://www.youtube.com/watch?v=ilv9V-328HI) +## General +- [January 2019: Tom Tromey discusses debugging support in rustc](https://www.youtube.com/watch?v=elBxMRSNYr4) +- [June 2019: Responsive compilers - Nicholas Matsakis - PLISS 2019](https://www.youtube.com/watch?v=N6b44kMS6OM) +- [June 2019: Things I Learned (TIL) - Nicholas Matsakis - PLISS 2019](https://www.youtube.com/watch?v=LIYkT3p5gTs) + +## Rust Analyzer +- [January 2019: How Salsa Works](https://www.youtube.com/watch?v=_muY4HjSqVw) +- [January 2019: Salsa In More Depth](https://www.youtube.com/watch?v=i_IhACacPRY) +- [January 2019: Rust analyzer guide](https://www.youtube.com/watch?v=ANKBNiSWyfc) +- [February 2019: Rust analyzer syntax trees](https://www.youtube.com/watch?v=DGAuLWdCCAI) +- [March 2019: rust-analyzer type-checker overview by flodiebold](https://www.youtube.com/watch?v=Lmp3P9WNL8o) +- [March 2019: RLS 2.0, Salsa, and Name Resolution](https://www.youtube.com/watch?v=Xr-rBqLr-G4) + +## Type System +- [July 2015: Felix Klock - Rust: A type system you didn't know you wanted - Curry On](https://www.youtube.com/watch?v=Q7lQCgnNWU0) +- [November 2016: Felix Klock - Subtyping in Rust and Clarke's Third Law](https://www.youtube.com/watch?v=fI4RG_uq-WU) +- [February 2019: Universes and Lifetimes](https://www.youtube.com/watch?v=iV1Z0xYXkck) +- [April 2019: Representing types in rustc](https://www.youtube.com/watch?v=c01TsOsr3-c) +- [March 2019: RFC #2229 Disjoint Field Capture plan](https://www.youtube.com/watch?v=UTXOptVMuIc) + +## Closures +- [October 2018: closures and upvar capture](https://www.youtube.com/watch?v=fMopdkn5-Xw) +- [October 2018: blitzerr closure upvar tys](https://www.youtube.com/watch?v=pLmVhSB-z4s) +- [January 2019: Convert Closure Upvar Representation to Tuples with blitzerr](https://www.youtube.com/watch?v=2QCuNtISoYc) + +## Chalk +- [July 2018: Coherence in Chalk by Sunjay Varma - Bay Area Rust Meetup](https://www.youtube.com/watch?v=rZqS4bLPL24) +- [March 2019: rustc-chalk integration overview](https://www.youtube.com/watch?v=MBWtbDifPeU) +- [April 2019: How the chalk-engine crate works](https://www.youtube.com/watch?v=Ny2928cGDoM) +- [May 2019: How the chalk-engine crate works 2](https://www.youtube.com/watch?v=hmV66tB79LM) + +## Polonius +- [March 2019: Polonius-rustc walkthrough](https://www.youtube.com/watch?v=i5KdU0ieb_A) +- [May 2019: Polonius WG: Initialization and move tracking](https://www.youtube.com/watch?v=ilv9V-328HI) + +## Miri +- [March 2019: oli-obk on miri and constant evaluation](https://www.youtube.com/watch?v=5Pm2C1YXrvM) + +## Async +- [February 2019: async-await implementation plans](https://www.youtube.com/watch?v=xe2_whJWBC0) +- [April 2019: async-await region inferencer](https://www.youtube.com/watch?v=hlOxfkUDLPQ) + +## Code Generation +- [January 2019: Cranelift](https://www.youtube.com/watch?v=9OIA7DTFQWU) From a436d3aedfdd595257fa994e7b974437f6fa3236 Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Mon, 28 Dec 2020 14:05:06 -0500 Subject: [PATCH 1376/1812] Update glossary.md (#994) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Update glossary.md - Added additional information to some of the definitions. - Made term capitalization consistent so that only terms which refer to acronyms or concrete types are capitalized. Please let me know if that isn't desirable for some reason. * Update src/appendix/glossary.md Co-authored-by: Joshua Nelson * Update src/appendix/glossary.md Co-authored-by: Léo Lanteri Thauvin * Update src/appendix/glossary.md Co-authored-by: Joshua Nelson Co-authored-by: Léo Lanteri Thauvin --- src/appendix/glossary.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 8ecd4f615..eae5758f4 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -18,21 +18,21 @@ Term | Meaning data-flow analysis | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.md#dataflow). DeBruijn Index | A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) DefId | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). -Discriminant | The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). -Double pointer | A pointer with additional metadata. See "fat pointer" for more. +discriminant | The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). +double pointer | A pointer with additional metadata. See "fat pointer" for more. drop glue | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. DST | Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). early-bound lifetime | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) empty type | see "uninhabited type". -Fat pointer | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". +fat pointer | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". free variable | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.md#free-vs-bound) generics | The set of generic type parameters defined on a type or item. HIR | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.md)) HirId | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). -HIR Map | The HIR map, accessible via tcx.hir, allows you to quickly navigate the HIR and convert between various forms of identifiers. +HIR map | The HIR map, accessible via `tcx.hir()`, allows you to quickly navigate the HIR and convert between various forms of identifiers. ICE | Short for internal compiler error, this is when the compiler crashes. ICH | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. -infcx | The inference context (see `rustc_middle::infer`) +infcx | The type inference context (`InferCtxt`). (see `rustc_middle::infer`) inference variable | When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. intern | Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. intrinsic | Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html)) @@ -41,7 +41,7 @@ Term | Meaning item | A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. lang item | Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) late-bound lifetime | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) -local crate | The crate currently being compiled. +local crate | The crate currently being compiled. This is in contrast to "upstream crates" which refer to dependencies of the local crate. LTO | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. [LLVM] | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. memoization | The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. @@ -50,7 +50,7 @@ Term | Meaning monomorphization | The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). normalize | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.md#normalizeprojection---type). newtype | A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. -Niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field. +niche | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field. NLL | Short for [non-lexical lifetimes](../borrow_check/region_inference.md), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. node-id or NodeId | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). obligation | Something that must be proven by the trait system. ([see more](../traits/resolution.md)) @@ -61,7 +61,7 @@ Term | Meaning promoted constants | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.md#promoted) for more details. provider | The function that executes a query. ([see more](../query.md)) quantified | In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.md#quantified). -query | Perhaps some sub-computation during compilation. ([see more](../query.md)) +query | A sub-computation during compilation. Query results can be cached in the current session or to disk for incremental compilation. ([see more](../query.md)) recovery | Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors). region | Another term for "lifetime" often used in the literature and in the borrow checker. rib | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.md)) @@ -73,21 +73,21 @@ Term | Meaning span | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. substs | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). sysroot | The directory for build artifacts that are loaded by the compiler at runtime. ([see more](../building/bootstrapping.html#what-is-a-sysroot)) -Tag | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). -tcx | The "typing context", main data structure of the compiler. ([see more](../ty.md)) -`'tcx` | The lifetime of the allocation arena. ([see more](../ty.md)) +tag | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). +tcx | The "typing context" (`TyCtxt`), main data structure of the compiler. ([see more](../ty.md)) +`'tcx` | The lifetime of the allocation arenas used by `TyCtxt`. Most data interned during a compilation session will use this lifetime with the exception of HIR data which uses the `'hir` lifetime. ([see more](../ty.md)) token | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.md)). [TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. trait reference | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.md#trait-ref)) -trans | The code to translate MIR into LLVM IR. Renamed to codegen. -ty | The internal representation of a type. ([see more](../ty.md)) -TyCtxt | The data structure often referred to as [tcx](#tcx) in code +trans | Short for "translation", the code to translate MIR into LLVM IR. Renamed to codegen. +`Ty` | The internal representation of a type. ([see more](../ty.md)) +TyCtxt | The data structure often referred to as [tcx](#tcx) in code which provides access to session data and the query system. UFCS | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.md)) uninhabited type | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". upvar | A variable captured by a closure from outside the closure. variance | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.md#variance) for a more general explanation. See the [variance chapter](../variance.md) for an explanation of how type checking handles variance. -Variant index | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). -Wide pointer | A pointer with additional metadata. See "fat pointer" for more. +variant index | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). +wide pointer | A pointer with additional metadata. See "fat pointer" for more. ZST | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. [LLVM]: https://llvm.org/ From 320df682bd2d3a6c0bf9902822e915ac1c5c2b16 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1aki=20Garay?= Date: Mon, 28 Dec 2020 19:34:51 -0300 Subject: [PATCH 1377/1812] rustc invocation standarized (#992) * rustc invocation standarized * Addressed comments * Addressed comments * Addressed comments * Updated command output --- src/backend/debugging.md | 22 +++++++-------- src/closure.md | 6 ++--- src/compiler-debugging.md | 40 +++++++++++++++------------- src/diagnostics.md | 2 +- src/hir-debugging.md | 2 +- src/hir.md | 4 +-- src/llvm-coverage-instrumentation.md | 6 ++--- src/mir/dataflow.md | 4 +-- src/mir/debugging.md | 22 +++++++-------- src/notification-groups/llvm.md | 4 +-- src/overview.md | 10 +++---- src/profile-guided-optimization.md | 4 +-- src/profiling.md | 32 +++++++++++----------- src/profiling/with_perf.md | 2 +- src/sanitizers.md | 4 +-- src/stability.md | 8 +++--- src/tests/adding.md | 2 +- 17 files changed, 89 insertions(+), 85 deletions(-) diff --git a/src/backend/debugging.md b/src/backend/debugging.md index f8ea4f5ed..7577a0e13 100644 --- a/src/backend/debugging.md +++ b/src/backend/debugging.md @@ -103,27 +103,27 @@ specifically the `#t-compiler/wg-llvm` stream. ### Compiler options to know and love -The `-Chelp` and `-Zhelp` compiler switches will list out a variety +The `-C help` and `-Z help` compiler switches will list out a variety of interesting options you may find useful. Here are a few of the most common that pertain to LLVM development (some of them are employed in the tutorial above): - The `--emit llvm-ir` option emits a `.ll` file with LLVM IR in textual format - The `--emit llvm-bc` option emits in bytecode format (`.bc`) -- Passing `-Cllvm-args=` allows passing pretty much all the +- Passing `-C llvm-args=` allows passing pretty much all the options that tools like llc and opt would accept; - e.g. `-Cllvm-args=-print-before-all` to print IR before every LLVM + e.g. `-C llvm-args=-print-before-all` to print IR before every LLVM pass. -- The `-Cno-prepopulate-passes` will avoid pre-populate the LLVM pass +- The `-C no-prepopulate-passes` will avoid pre-populate the LLVM pass manager with a list of passes. This will allow you to view the LLVM IR that rustc generates, not the LLVM IR after optimizations. -- The `-Cpasses=val` option allows you to supply a space separated list of extra LLVM passes to run -- The `-Csave-temps` option saves all temporary output files during compilation -- The `-Zprint-llvm-passes` option will print out LLVM optimization passes being run -- The `-Ztime-llvm-passes` option measures the time of each LLVM pass -- The `-Zverify-llvm-ir` option will verify the LLVM IR for correctness -- The `-Zno-parallel-llvm` will disable parallel compilation of distinct compilation units -- The `-Zllvm-time-trace` option will output a Chrome profiler compatible JSON file +- The `-C passes=val` option allows you to supply a space separated list of extra LLVM passes to run +- The `-C save-temps` option saves all temporary output files during compilation +- The `-Z print-llvm-passes` option will print out LLVM optimization passes being run +- The `-Z time-llvm-passes` option measures the time of each LLVM pass +- The `-Z verify-llvm-ir` option will verify the LLVM IR for correctness +- The `-Z no-parallel-llvm` will disable parallel compilation of distinct compilation units +- The `-Z llvm-time-trace` option will output a Chrome profiler compatible JSON file which contains details and timings for LLVM passes. ### Filing LLVM bug reports diff --git a/src/closure.md b/src/closure.md index 3b535040e..3330bf1b4 100644 --- a/src/closure.md +++ b/src/closure.md @@ -32,10 +32,10 @@ fn main() { ``` Let's say the above is the content of a file called `immut.rs`. If we compile -`immut.rs` using the following command. The [`-Zdump-mir=all`][dump-mir] flag will cause +`immut.rs` using the following command. The [`-Z dump-mir=all`][dump-mir] flag will cause `rustc` to generate and dump the [MIR][mir] to a directory called `mir_dump`. ```console -> rustc +stage1 immut.rs -Zdump-mir=all +> rustc +stage1 immut.rs -Z dump-mir=all ``` [mir]: ./mir/index.md @@ -146,7 +146,7 @@ codebase. For closures specifically, set the `RUST_LOG` env variable as below an output in a file: ```console -> RUST_LOG=rustc_typeck::check::upvar rustc +stage1 -Zdump-mir=all \ +> RUST_LOG=rustc_typeck::check::upvar rustc +stage1 -Z dump-mir=all \ <.rs file to compile> 2> ``` diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 4b241d8ea..e5b93a66f 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -82,28 +82,31 @@ For example: ```bash $ cat error.rs +``` + +```rust fn main() { 1 + (); } ``` ```bash -$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc error.rs -error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied +$ rustc +stage1 error.rs +error[E0277]: cannot add `()` to `{integer}` --> error.rs:2:7 | -2 | 1 + (); - | ^ no implementation for `{integer} + ()` +2 | 1 + (); + | ^ no implementation for `{integer} + ()` | - = help: the trait `std::ops::Add<()>` is not implemented for `{integer}` + = help: the trait `Add<()>` is not implemented for `{integer}` error: aborting due to previous error +``` + +Now, where does the error above come from? -$ # Now, where does the error above come from? -$ RUST_BACKTRACE=1 \ - ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc \ - error.rs \ - -Z treat-err-as-bug +```bash +$ RUST_BACKTRACE=1 rustc +stage1 error.rs -Z treat-err-as-bug error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied --> error.rs:2:7 | @@ -140,9 +143,10 @@ stack backtrace: (~~~ IRRELEVANT PART OF BACKTRACE REMOVED BY ME ~~~) 36: rustc_driver::run_compiler at /home/user/rust/compiler/rustc_driver/src/lib.rs:253 -$ # Cool, now I have a backtrace for the error ``` +Cool, now I have a backtrace for the error! + ## Getting logging output [getting-logging-output]: #getting-logging-output @@ -180,16 +184,16 @@ So to put it together. ```bash # This puts the output of all debug calls in `rustc_middle/src/traits` into # standard error, which might fill your console backscroll. -$ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs +$ RUSTC_LOG=rustc_middle::traits rustc +stage1 my-file.rs # This puts the output of all debug calls in `rustc_middle/src/traits` in # `traits-log`, so you can then see it with a text editor. -$ RUSTC_LOG=rustc_middle::traits rustc +local my-file.rs 2>traits-log +$ RUSTC_LOG=rustc_middle::traits rustc +stage1 my-file.rs 2>traits-log # Not recommended. This will show the output of all `debug!` calls # in the Rust compiler, and there are a *lot* of them, so it will be # hard to find anything. -$ RUSTC_LOG=debug rustc +local my-file.rs 2>all-log +$ RUSTC_LOG=debug rustc +stage1 my-file.rs 2>all-log # This will show the output of all `info!` calls in `rustc_trans`. # @@ -198,13 +202,13 @@ $ RUSTC_LOG=debug rustc +local my-file.rs 2>all-log # which function triggers an LLVM assertion, and this is an `info!` # log rather than a `debug!` log so it will work on the official # compilers. -$ RUSTC_LOG=rustc_trans=info rustc +local my-file.rs +$ RUSTC_LOG=rustc_trans=info rustc +stage1 my-file.rs # This will show the output of all `info!` calls made by rustdoc or any rustc library it calls. -$ RUSTDOC_LOG=info rustdoc +local my-file.rs +$ RUSTDOC_LOG=info rustdoc +stage1 my-file.rs # This will only show `debug!` calls made by rustdoc directly, not any `rustc*` crate. -$ RUSTDOC_LOG=rustdoc rustdoc +local my-file.rs +$ RUSTDOC_LOG=rustdoc rustdoc +stage1 my-file.rs ``` ### How to keep or remove `debug!` and `trace!` calls from the resulting binary @@ -271,7 +275,7 @@ In addition to [graphviz output](#formatting-graphviz-output-dot-files), MIR deb flags include an option to generate a MIR representation called `Spanview` that uses HTML to highlight code regions in the original source code and display compiler metadata associated with each region. -[`-Zdump-mir-spanview`](./mir/debugging.md), for example, highlights spans +[`-Z dump-mir-spanview`](./mir/debugging.md), for example, highlights spans associated with each MIR `Statement`, `Terminator`, and/or `BasicBlock`. These `.html` files use CSS features to dynamically expand spans obscured by diff --git a/src/diagnostics.md b/src/diagnostics.md index fce79d725..e3a60447b 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -263,7 +263,7 @@ There are two main ways to find where a given error is emitted: the error emitting code is removed from the code where the error is constructed behind a relatively deep call-stack. Even then, it is a good way to get your bearings. -- Invoking `rustc` with the nightly-only flag `-Ztreat-err-as-bug=1`, which +- Invoking `rustc` with the nightly-only flag `-Z treat-err-as-bug=1`, which will treat the first error being emitted as an Internal Compiler Error, which allows you to use the environment variable `RUST_BACKTRACE=full` to get a stack trace at the point the error has been emitted. Change the `1` to diff --git a/src/hir-debugging.md b/src/hir-debugging.md index bb7f541fd..519ff2667 100644 --- a/src/hir-debugging.md +++ b/src/hir-debugging.md @@ -1,6 +1,6 @@ # HIR Debugging -The `-Zunpretty=hir-tree` flag will dump out the HIR. +The `-Z unpretty=hir-tree` flag will dump out the HIR. If you are trying to correlate `NodeId`s or `DefId`s with source code, the `--pretty expanded,identified` flag may be useful. diff --git a/src/hir.md b/src/hir.md index a88ba9066..014136bde 100644 --- a/src/hir.md +++ b/src/hir.md @@ -12,10 +12,10 @@ the HIR. This makes HIR more amenable to analysis than a normal AST. This chapter covers the main concepts of the HIR. You can view the HIR representation of your code by passing the -`-Zunpretty=hir-tree` flag to rustc: +`-Z unpretty=hir-tree` flag to rustc: ```bash -cargo rustc -- -Zunpretty=hir-tree +cargo rustc -- -Z unpretty=hir-tree ``` ### Out-of-band storage and the `Crate` type diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 6550fb66c..1cc6a2717 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -308,7 +308,7 @@ $ ./x.py test src/test/ --blessed [spanview-debugging]: compiler-debugging.md#viewing-spanview-output [`coverage-llvmir`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/coverage-llvmir -## Implementation Details of the `InstrumentCoverage` MIR Pass +## Implementation Details of the `InstrumentCoverage` MIR Pass The bulk of the implementation of the `InstrumentCoverage` MIR pass is performed by the [`Instrumentor`][instrumentor]. For each MIR (each non-const, non-inlined @@ -496,8 +496,8 @@ An visual, interactive representation of the final `CoverageSpan`s can be generated with the following `rustc` flags: ```shell -$ rustc -Zinstrument-coverage -Zdump-mir=InstrumentCoverage \ - -Zdump-mir-spanview some_rust_source.rs +$ rustc -Z instrument-coverage -Z dump-mir=InstrumentCoverage \ + -Z dump-mir-spanview some_rust_source.rs ``` These flags request Spanview output for the `InstrumentCoverage` pass, and the diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index b5cbd4686..e3413c5e9 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -201,8 +201,8 @@ for (bb, block) in body.basic_blocks().iter_enumerated() { ### Graphviz Diagrams When the results of a dataflow analysis are not what you expect, it often helps -to visualize them. This can be done with the `-Zdump-mir` flags described in -[Debugging MIR]. Start with `-Zdump-mir=F -Zdump-mir-dataflow`, where `F` is +to visualize them. This can be done with the `-Z dump-mir` flags described in +[Debugging MIR]. Start with `-Z dump-mir=F -Z dump-mir-dataflow`, where `F` is either "all" or the name of the MIR body you are interested in. These `.dot` files will be saved in your `mir_dump` directory and will have the diff --git a/src/mir/debugging.md b/src/mir/debugging.md index 3a47a575d..c6734f8aa 100644 --- a/src/mir/debugging.md +++ b/src/mir/debugging.md @@ -1,26 +1,26 @@ # MIR Debugging -The `-Zdump-mir` flag can be used to dump a text representation of the MIR. -The following optional flags, used in combination with `-Zdump-mir`, enable +The `-Z dump-mir` flag can be used to dump a text representation of the MIR. +The following optional flags, used in combination with `-Z dump-mir`, enable additional output formats, including: -* `-Zdump-mir-graphviz` - dumps a `.dot` file that represents MIR as a +* `-Z dump-mir-graphviz` - dumps a `.dot` file that represents MIR as a control-flow graph -* `-Zdump-mir-dataflow` - dumps a `.dot` file showing the [dataflow state] at +* `-Z dump-mir-dataflow` - dumps a `.dot` file showing the [dataflow state] at each point in the control-flow graph -* `-Zdump-mir-spanview` - dumps an `.html` file that highlights the source +* `-Z dump-mir-spanview` - dumps an `.html` file that highlights the source spans associated with MIR elements (including mouse-over actions to reveal elements obscured by overlaps, and tooltips to view the MIR statements). This flag takes an optional value: `statement` (the default), `terminator`, or `block`, to generate span highlights with different levels of granulatity. -`-Zdump-mir=F` is a handy compiler options that will let you view the MIR for -each function at each stage of compilation. `-Zdump-mir` takes a **filter** `F` +`-Z dump-mir=F` is a handy compiler options that will let you view the MIR for +each function at each stage of compilation. `-Z dump-mir` takes a **filter** `F` which allows you to control which functions and which passes you are interesting in. For example: ```bash -> rustc -Zdump-mir=foo ... +> rustc -Z dump-mir=foo ... ``` This will dump the MIR for any function whose name contains `foo`; it @@ -34,7 +34,7 @@ fn main() { println!("Hello, world!"); } ^D -> rustc -Zdump-mir=main foo.rs +> rustc -Z dump-mir=main foo.rs > ls mir_dump/* | wc -l 161 ``` @@ -56,7 +56,7 @@ will select for things that reference *both* `main` and the pass `CleanEndRegions`: ```bash -> rustc -Zdump-mir='main & CleanEndRegions' foo.rs +> rustc -Z dump-mir='main & CleanEndRegions' foo.rs > ls mir_dump rustc.main.000-000.CleanEndRegions.after.mir rustc.main.000-000.CleanEndRegions.before.mir ``` @@ -67,7 +67,7 @@ NoLandingPads` will select *either* `main` and `CleanEndRegions` *or* `main` and `NoLandingPads`: ```bash -> rustc -Zdump-mir='main & CleanEndRegions | main & NoLandingPads' foo.rs +> rustc -Z dump-mir='main & CleanEndRegions | main & NoLandingPads' foo.rs > ls mir_dump rustc.main-promoted[0].002-000.NoLandingPads.after.mir rustc.main-promoted[0].002-000.NoLandingPads.before.mir diff --git a/src/notification-groups/llvm.md b/src/notification-groups/llvm.md index f1f2097e5..69edd8b54 100644 --- a/src/notification-groups/llvm.md +++ b/src/notification-groups/llvm.md @@ -22,8 +22,8 @@ The ["Debugging LLVM"][d] section of the rustc-dev-guide gives a step-by-step process for how to help debug bugs caused by LLVM. In particular, it discusses how to emit LLVM IR, run the LLVM IR optimization pipelines, and so forth. You may also find -it useful to look at the various codegen options listed under `-Chelp` -and the internal options under `-Zhelp` -- there are a number that +it useful to look at the various codegen options listed under `-C help` +and the internal options under `-Z help` -- there are a number that pertain to LLVM (just search for LLVM). [d]: ../backend/debugging.md diff --git a/src/overview.md b/src/overview.md index 82f2289e4..8f1a55d10 100644 --- a/src/overview.md +++ b/src/overview.md @@ -32,10 +32,10 @@ we'll talk about that later. - The token stream passes through a higher-level lexer located in [`rustc_parse`] to prepare for the next stage of the compile process. The [`StringReader`] struct is used at this stage to perform a set of validations - and turn strings into interned symbols (_interning_ is discussed later). - [String interning] is a way of storing only one immutable + and turn strings into interned symbols (_interning_ is discussed later). + [String interning] is a way of storing only one immutable copy of each distinct string value. - + - The lexer has a small interface and doesn't depend directly on the diagnostic infrastructure in `rustc`. Instead it provides diagnostics as plain data which are emitted in `rustc_parse::lexer::mod` as real diagnostics. @@ -330,7 +330,7 @@ For more details on bootstrapping, see - Does LLVM ever do optimizations in debug builds? - How do I explore phases of the compile process in my own sources (lexer, - parser, HIR, etc)? - e.g., `cargo rustc -- -Zunpretty=hir-tree` allows you to + parser, HIR, etc)? - e.g., `cargo rustc -- -Z unpretty=hir-tree` allows you to view HIR representation - What is the main source entry point for `X`? - Where do phases diverge for cross-compilation to machine code across @@ -363,7 +363,7 @@ For more details on bootstrapping, see - Guide: [Identifiers in the HIR](https://rustc-dev-guide.rust-lang.org/hir.html#identifiers-in-the-hir) - Guide: [The HIR Map](https://rustc-dev-guide.rust-lang.org/hir.html#the-hir-map) - Guide: [Lowering AST to HIR](https://rustc-dev-guide.rust-lang.org/lowering.html) - - How to view HIR representation for your code `cargo rustc -- -Zunpretty=hir-tree` + - How to view HIR representation for your code `cargo rustc -- -Z unpretty=hir-tree` - Rustc HIR definition: [`rustc_hir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html) - Main entry point: **TODO** - Late linting: **TODO** diff --git a/src/profile-guided-optimization.md b/src/profile-guided-optimization.md index 016397e20..09587e6bf 100644 --- a/src/profile-guided-optimization.md +++ b/src/profile-guided-optimization.md @@ -54,11 +54,11 @@ coverage results for PGO has not been attempted at this time. Generating a PGO-optimized program involves the following four steps: -1. Compile the program with instrumentation enabled (e.g. `rustc -Cprofile-generate main.rs`) +1. Compile the program with instrumentation enabled (e.g. `rustc -C profile-generate main.rs`) 2. Run the instrumented program (e.g. `./main`) which generates a `default-.profraw` file 3. Convert the `.profraw` file into a `.profdata` file using LLVM's `llvm-profdata` tool. 4. Compile the program again, this time making use of the profiling data - (e.g. `rustc -Cprofile-use=merged.profdata main.rs`) + (e.g. `rustc -C profile-use=merged.profdata main.rs`) ### Compile-Time Aspects diff --git a/src/profiling.md b/src/profiling.md index e8139dd25..a1f1a4b77 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -1,29 +1,29 @@ # Profiling the compiler -This section talks about how to profile the compiler and find out where it spends its time. +This section talks about how to profile the compiler and find out where it spends its time. Depending on what you're trying to measure, there are several different approaches: - If you want to see if a PR improves or regresses compiler performance: - The [rustc-perf](https://github.com/rust-lang/rustc-perf) project makes this easy and can be triggered to run on a PR via the `@rustc-perf` bot. - + - If you want a medium-to-high level overview of where `rustc` is spending its time: - - The `-Zself-profile` flag and [measureme](https://github.com/rust-lang/measureme) tools offer a query-based approach to profiling. + - The `-Z self-profile` flag and [measureme](https://github.com/rust-lang/measureme) tools offer a query-based approach to profiling. See [their docs](https://github.com/rust-lang/measureme/blob/master/summarize/Readme.md) for more information. - + - If you want function level performance data or even just more details than the above approaches: - - Consider using a native code profiler such as [perf](profiling/with_perf.html) - - or [tracy](https://github.com/nagisa/rust_tracy_client) for a nanosecond-precision, + - Consider using a native code profiler such as [perf](profiling/with_perf.html) + - or [tracy](https://github.com/nagisa/rust_tracy_client) for a nanosecond-precision, full-featured graphical interface. -- If you want a nice visual representation of the compile times of your crate graph, - you can use [cargo's `-Ztimings` flag](https://doc.rust-lang.org/cargo/reference/unstable.html#timings), - eg. `cargo -Ztimings build`. - You can use this flag on the compiler itself with `CARGOFLAGS="-Ztimings" ./x.py build` - +- If you want a nice visual representation of the compile times of your crate graph, + you can use [cargo's `-Z timings` flag](https://doc.rust-lang.org/cargo/reference/unstable.html#timings), + eg. `cargo -Z timings build`. + You can use this flag on the compiler itself with `CARGOFLAGS="-Z timings" ./x.py build` + ## Optimizing rustc's bootstrap times with `cargo-llvm-lines` -Using [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines) you can count the +Using [cargo-llvm-lines](https://github.com/dtolnay/cargo-llvm-lines) you can count the number of lines of LLVM IR across all instantiations of a generic function. Since most of the time compiling rustc is spent in LLVM, the idea is that by reducing the amount of code passed to LLVM, compiling rustc gets faster. @@ -67,12 +67,12 @@ Example output: 49714 (0.4%) 14 (0.0%) rustc_mir::dataflow::framework::graphviz::BlockFormatter    ::write_node_label ``` -Since this doesn't seem to work with incremental compilation or `x.py check`, +Since this doesn't seem to work with incremental compilation or `x.py check`, you will be compiling rustc _a lot_. I recommend changing a few settings in `config.toml` to make it bearable: ``` [rust] -# A debug build takes _a third_ as long on my machine, +# A debug build takes _a third_ as long on my machine, # but compiling more than stage0 rustc becomes unbearably slow. optimize = false @@ -88,7 +88,7 @@ codegen-units = 0 # num_cpus The llvm-lines output is affected by several options. `optimize = false` increases it from 2.1GB to 3.5GB and `codegen-units = 0` to 4.1GB. -MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Zmir-opt-level=1"`, -level 0 adds 0.3GB and level 2 removes 0.2GB. +MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Z mir-opt-level=1"`, +level 0 adds 0.3GB and level 2 removes 0.2GB. Inlining currently only happens in LLVM, but this might change in the future. diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 5945f0b02..b383ec542 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -150,7 +150,7 @@ the `cargo rustc` command, like so: ```bash touch src/lib.rs -CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib -- -Zborrowck=mir +CARGO_INCREMENTAL=0 perf record -F99 --call-graph dwarf cargo rustc --profile check --lib -- -Z borrowck=mir ``` [pf]: https://github.com/nikomatsakis/perf-focus diff --git a/src/sanitizers.md b/src/sanitizers.md index 5e1f396f5..4a43698ca 100644 --- a/src/sanitizers.md +++ b/src/sanitizers.md @@ -11,7 +11,7 @@ The rustc compiler contains support for following sanitizers: ## How to use the sanitizers? -To enable a sanitizer compile with `-Zsanitizer=...` option, where value is one +To enable a sanitizer compile with `-Z sanitizer=...` option, where value is one of `address`, `leak`, `memory` or `thread`. For more details how to use sanitizers please refer to [the unstable book](https://doc.rust-lang.org/unstable-book/). @@ -49,7 +49,7 @@ libraries. Highlight of the most important aspects of the implementation: * When producing an executable, the sanitizer specific runtime library is [linked in][sanitizer-link]. The libraries are searched for in target libdir relative to default system root, so that this process is not affected - by sysroot overrides used for example by cargo `-Zbuild-std` functionality. + by sysroot overrides used for example by cargo `-Z build-std` functionality. [compiler-rt]: https://github.com/llvm/llvm-project/tree/master/compiler-rt [sanitizer-build]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/bootstrap/native.rs#L566-L624 diff --git a/src/stability.md b/src/stability.md index 1cbbcb849..c9e7056d6 100644 --- a/src/stability.md +++ b/src/stability.md @@ -129,9 +129,9 @@ default `allow`, but most of the standard library raises it to a warning with [`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute -## -Zforce-unstable-if-unmarked +## -Z force-unstable-if-unmarked -The `-Zforce-unstable-if-unmarked` flag has a variety of purposes to help +The `-Z force-unstable-if-unmarked` flag has a variety of purposes to help enforce that the correct crates are marked as unstable. It was introduced primarily to allow rustc and the standard library to link to arbitrary crates on crates.io which do not themselves use `staged_api`. `rustc` also relies on @@ -152,9 +152,9 @@ This flag has the following effects: attribute to use other unstable crates. However, that would make it impossible for a crate from crates.io to access its own dependencies since that crate won't have a `feature(rustc_private)` attribute, but *everything* - is compiled with `-Zforce-unstable-if-unmarked`. + is compiled with `-Z force-unstable-if-unmarked`. -Code which does not use `-Zforce-unstable-if-unmarked` should include the +Code which does not use `-Z force-unstable-if-unmarked` should include the `#![feature(rustc_private)]` crate attribute to access these force-unstable crates. This is needed for things that link `rustc`, such as `miri`, `rls`, or `clippy`. diff --git a/src/tests/adding.md b/src/tests/adding.md index 9c0da6663..65f0896e8 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -109,7 +109,7 @@ to specify a custom flag to give to rustc when the test is compiled: ```rust,ignore // Test the behavior of `0 - 1` when overflow checks are disabled. -// compile-flags: -Coverflow-checks=off +// compile-flags: -C overflow-checks=off fn main() { let x = 0 - 1; From e7da4fd7692f67596a5d5ceb10b86e3c5709d74f Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 29 Dec 2020 15:08:55 -0500 Subject: [PATCH 1378/1812] Fix broken link in the contributing guide (#996) --- src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index fb65a8eae..bc846f9c7 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -5,7 +5,7 @@ contribute, and we appreciate all of them. * [Feature Requests](#feature-requests) * [Bug Reports](#bug-reports) -* [The Build System](#the-build-system) +* [The Build System](./building/how-to-build-and-run.md) * [Pull Requests](#pull-requests) * [Writing Documentation](#writing-documentation) * [Issue Triage](#issue-triage) From f2e7d46f28d4e05467391b38bd6b47d9398fefd8 Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 30 Dec 2020 16:08:00 -0800 Subject: [PATCH 1379/1812] Update logging section and explain `RUSTC_LOG_COLOR` (#997) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Update logging section and explain `RUSTC_LOG_COLOR` * Small fixes Co-authored-by: Léo Lanteri Thauvin * Mention that prefixes of paths work as log filters * `=debug` matches `debug!` *and higher* * Note that `MIRI_LOG_COLOR` only applies to logs from Miri Co-authored-by: Léo Lanteri Thauvin --- src/compiler-debugging.md | 92 ++++++++++++++++++++++++++++----------- 1 file changed, 66 insertions(+), 26 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index e5b93a66f..0510e6bca 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -150,67 +150,107 @@ Cool, now I have a backtrace for the error! ## Getting logging output [getting-logging-output]: #getting-logging-output -These crates are used in compiler for logging: +The compiler uses the [`tracing`] crate for logging. -* [log] -* [env-logger] +[`tracing`]: https://docs.rs/tracing -[log]: https://docs.rs/log/0.4.6/log/index.html -[env-logger]: https://docs.rs/env_logger - -The compiler has a lot of `debug!` calls, which print out logging information +The compiler has a lot of [`debug!`] calls, which print out logging information at many points. These are very useful to at least narrow down the location of a bug if not to find it entirely, or just to orient yourself as to why the compiler is doing a particular thing. -To see the logs, you need to set the `RUSTC_LOG` environment variable to -your log filter, e.g. to get the logs for a specific module, you can run the -compiler as `RUSTC_LOG=module::path rustc my-file.rs`. All `debug!` output will -then appear in standard error. +[`debug!`]: https://docs.rs/tracing/0.1/tracing/macro.debug.html + +To see the logs, you need to set the `RUSTC_LOG` environment variable to your +log filter. Your log filter can be just `debug` to get all `debug!` output and +higher (e.g., it will also include `info!`), or `path::to::module` to get *all* +output (which will include `trace!`) from a particular module, or +`path::to::module=debug` to get `debug!` output and higher from a particular +module. + +For example, to get the `debug!` output and higher for a specific module, you +can run the compiler with `RUSTC_LOG=path::to::module=debug rustc my-file.rs`. +All `debug!` output will then appear in standard error. -If you are developing rustdoc, use `RUSTDOC_LOG` instead. +Note that you can use a partial path and the filter will still work. For +example, if you want to see `info!` output from only +`rustdoc::passes::collect_intra_doc_links`, you could use +`RUSTDOC_LOG=rustdoc::passes::collect_intra_doc_links=info` *or* you could use +`RUSTDOC_LOG=rustdoc::passes::collect_intra=info`. -See the [env-logger] doc for more info on the full syntax. (Note: unlike the -compiler, the env-logger crate and its examples use the `RUST_LOG` env -variable.) +If you are developing rustdoc, use `RUSTDOC_LOG` instead. If you are developing +Miri, use `MIRI_LOG` instead. You get the idea :) + +See the [`tracing`] crate's docs, and specifically the docs for [`debug!`] to +see the full syntax you can use. See the [env-logger] doc for more info on the +full syntax. (Note: unlike the compiler, the [`tracing`] crate and its examples +use the `RUST_LOG` environment variable. rustc, rustdoc, and other tools set +custom environment variables.) **Note that unless you use a very strict filter, the logger will emit a lot of output, so use the most specific module(s) you can (comma-separated if multiple)**. It's typically a good idea to pipe standard error to a file and look at the log output with a text editor. -So to put it together. +So, to put it together: ```bash # This puts the output of all debug calls in `rustc_middle/src/traits` into # standard error, which might fill your console backscroll. -$ RUSTC_LOG=rustc_middle::traits rustc +stage1 my-file.rs +$ RUSTC_LOG=rustc_middle::traits=debug rustc +stage1 my-file.rs # This puts the output of all debug calls in `rustc_middle/src/traits` in # `traits-log`, so you can then see it with a text editor. -$ RUSTC_LOG=rustc_middle::traits rustc +stage1 my-file.rs 2>traits-log +$ RUSTC_LOG=rustc_middle::traits=debug rustc +stage1 my-file.rs 2>traits-log -# Not recommended. This will show the output of all `debug!` calls +# Not recommended! This will show the output of all `debug!` calls # in the Rust compiler, and there are a *lot* of them, so it will be # hard to find anything. $ RUSTC_LOG=debug rustc +stage1 my-file.rs 2>all-log -# This will show the output of all `info!` calls in `rustc_trans`. +# This will show the output of all `info!` calls in `rustc_codegen_ssa`. # -# There's an `info!` statement in `trans_instance` that outputs -# every function that is translated. This is useful to find out +# There's an `info!` statement in `codegen_instance` that outputs +# every function that is codegen'd. This is useful to find out # which function triggers an LLVM assertion, and this is an `info!` # log rather than a `debug!` log so it will work on the official # compilers. -$ RUSTC_LOG=rustc_trans=info rustc +stage1 my-file.rs +$ RUSTC_LOG=rustc_codegen_ssa=info rustc +stage1 my-file.rs -# This will show the output of all `info!` calls made by rustdoc or any rustc library it calls. +# This will show the output of all `info!` calls made by rustdoc +# or any rustc library it calls. $ RUSTDOC_LOG=info rustdoc +stage1 my-file.rs -# This will only show `debug!` calls made by rustdoc directly, not any `rustc*` crate. -$ RUSTDOC_LOG=rustdoc rustdoc +stage1 my-file.rs +# This will only show `debug!` calls made by rustdoc directly, +# not any `rustc*` crate. +$ RUSTDOC_LOG=rustdoc=debug rustdoc +stage1 my-file.rs ``` +### Log colors + +By default, rustc (and other tools, like rustdoc and Miri) will be smart about +when to use ANSI colors in the log output. If they are outputting to a terminal, +they will use colors, and if they are outputting to a file or being piped +somewhere else, they will not. However, it's hard to read log output in your +terminal unless you have a very strict filter, so you may want to pipe the +output to a pager like `less`. But then there won't be any colors, which makes +it hard to pick out what you're looking for! + +You can override whether to have colors in log output with the `RUSTC_LOG_COLOR` +environment variable (or `RUSTDOC_LOG_COLOR` for rustdoc, or `MIRI_LOG_COLOR` +for Miri, etc.). There are three options: `auto` (the default), `always`, and +`never`. So, if you want to enable colors when piping to `less`, use something +similar to this command: + +```bash +# The `-R` switch tells less to print ANSI colors without escaping them. +$ RUSTC_LOG=debug RUSTC_LOG_COLOR=always rustc +stage1 ... | less -R +``` + +Note that `MIRI_LOG_COLOR` will only color logs that come from Miri, not logs +from rustc functions that Miri calls. Use `RUSTC_LOG_COLOR` to color logs from +rustc. + ### How to keep or remove `debug!` and `trace!` calls from the resulting binary While calls to `error!`, `warn!` and `info!` are included in every build of the compiler, From 148742b6cefa5d4382b3c81e824e3ffed5a92c23 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Thu, 31 Dec 2020 09:13:49 +0900 Subject: [PATCH 1380/1812] Fix broken link for `BoundRegion` (#998) --- src/early-late-bound.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/early-late-bound.md b/src/early-late-bound.md index a703cbab5..973306b86 100644 --- a/src/early-late-bound.md +++ b/src/early-late-bound.md @@ -89,7 +89,7 @@ Moreover, a reference to a late-bound lifetime is written `^0.a`: - The `0` is the index; it identifies that this lifetime is bound in the innermost binder (the `for`). - The `a` is the "name"; late-bound lifetimes in rustc are identified by a - "name" -- the [`BoundRegion`] struct. This struct can contain a + "name" -- the [`BoundRegionKind`] enum. This enum can contain a [`DefId`][defid] or it might have various "anonymous" numbered names. The latter arise from types like `fn(&u32, &u32)`, which are equivalent to something like `for<'a, 'b> fn(&'a u32, &'b u32)`, but the names of those @@ -103,5 +103,5 @@ anonymous regions like in `fn(&u32)`, we just create a fresh index and don't hav to update the binder. [`Binder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Binder.html -[`BoundRegion`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BoundRegion.html +[`BoundRegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BoundRegionKind.html [defid]: ./hir.html#identifiers-in-the-hir From 541976f658d14b1fc2377d1fddc4e09569fe3e87 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Fri, 1 Jan 2021 15:59:23 -0500 Subject: [PATCH 1381/1812] Clarify that `check` uses a different stage than `build` (#999) --- src/building/bootstrapping.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 1d420a978..3e5cabbe8 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -62,6 +62,7 @@ the `stage1` compiler: `x.py build library/std`. `x.py` tries to be helpful and pick the stage you most likely meant for each subcommand. These defaults are as follows: +- `check`: `--stage 0` - `doc`: `--stage 0` - `build`: `--stage 1` - `test`: `--stage 1` @@ -69,10 +70,13 @@ These defaults are as follows: - `install`: `--stage 2` - `bench`: `--stage 2` -You can always override the stage by passing `--stage N` explicitly. +You can always override the stage by passing `--stage N` explicitly, except for `check`, +which is [hard-coded to stage 0][stage1-check]. For more information about stages, [see below](#understanding-stages-of-bootstrap). +[stage1-check]: https://github.com/rust-lang/rust/issues/46955 + ## Complications of bootstrapping Since the build system uses the current beta compiler to build the stage-1 From 64c4632faffba14c66e1777f625ab46eca97575f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lauren=C8=9Biu=20Nicola?= Date: Sat, 2 Jan 2021 14:54:22 +0200 Subject: [PATCH 1382/1812] Fix typo (reflex -> reflect) --- src/macro-expansion.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/macro-expansion.md b/src/macro-expansion.md index a02b854af..40342a703 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -240,7 +240,7 @@ This struct also has hygiene information attached to it, as we will see later. Because macros invocations and definitions can be nested, the syntax context of a node must be a hierarchy. For example, if we expand a macro and there is another macro invocation or definition in the generated output, then the syntax -context should reflex the nesting. +context should reflect the nesting. However, it turns out that there are actually a few types of context we may want to track for different purposes. Thus, there are not just one but _three_ From de3bdce4b800c1d9a3b086e1b00fa1e3108f94df Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 3 Jan 2021 16:24:53 -0800 Subject: [PATCH 1383/1812] Tweak wording around provider purity --- src/queries/query-evaluation-model-in-detail.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 2d4214ef3..8f38853c4 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -38,10 +38,10 @@ corresponding result. However, we have to apply some restrictions in order for this to be sound: - The key and result must be immutable values. - - The provider function must be a pure function, that is, for the same key it - must always yield the same result. + - The provider function must be a pure function in the sense that for the same + key it must always yield the same result. - The only parameters a provider function takes are the key and a reference to - the "query context" (which provides access to rest of the "database"). + the "query context" (which provides access to the rest of the "database"). The database is built up lazily by invoking queries. The query providers will invoke other queries, for which the result is either already cached or computed From a0819a6d98737398d61d45460ad3f912d7a82d0d Mon Sep 17 00:00:00 2001 From: Sebastian Widua Date: Mon, 4 Jan 2021 11:36:03 +0100 Subject: [PATCH 1384/1812] Fix some typos --- src/compiler-debugging.md | 2 +- src/tests/intro.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 0510e6bca..b1addb249 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -324,7 +324,7 @@ reveal the actual MIR elements, as text. To view these files, simply use a modern browser, or a CSS-capable HTML preview feature in a modern IDE. (The default HTML preview pane in *VS Code* is known to -work, for instance. +work, for instance.) ## Narrowing (Bisecting) Regressions diff --git a/src/tests/intro.md b/src/tests/intro.md index 3be9219f6..51c0e2d6e 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -70,7 +70,7 @@ including: is correct. The formatting check is also automatically run by the Tidy tool mentioned above. - Example: `./x.py fmt --check` checks formatting an exits with an error if + Example: `./x.py fmt --check` checks formatting and exits with an error if formatting is needed. Example: `./x.py fmt` runs rustfmt on the codebase. From 11b83ebb5a35e3a490172903161dc99f55941024 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Mon, 4 Jan 2021 13:55:24 +0100 Subject: [PATCH 1385/1812] Add link to rust-analyzer docs on getting started page --- src/getting-started.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index da444cdbb..8b2fc48f8 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -181,7 +181,7 @@ should still read the rest of the section: | Command | When to use it | | --- | --- | -| `x.py check` | Quick check to see if things compile; rust-analyzer can run this automatically for you | +| `x.py check` | Quick check to see if things compile; [rust-analyzer can run this automatically for you][rust-analyzer] | | `x.py build --stage 0 [library/std]` | Build only the standard library, without building the compiler | | `x.py build library/std` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough | | `x.py build --keep-stage 1 library/std` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | @@ -230,6 +230,7 @@ test are mostly for the frontend of the compiler, so if you are working on LLVM or codegen, this shortcut will _not_ test your changes. You can read more about the different test suites [in this chapter][testing]. +[rust-analyzer]: ./building/suggested.html#configuring-rust-analyzer-for-rustc [uitests]: ./tests/adding.html#ui [testing]: https://rustc-dev-guide.rust-lang.org/tests/intro.html From f08a6b3b83c3d8117f07080c27d76f1058d961be Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Mon, 4 Jan 2021 07:41:42 -0800 Subject: [PATCH 1386/1812] Update mdbook --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index f503eeefa..1e5d86993 100644 --- a/.travis.yml +++ b/.travis.yml @@ -11,7 +11,7 @@ before_install: - MAX_LINE_LENGTH=100 bash ci/check_line_lengths.sh src/**/*.md install: - source ~/.cargo/env || true -- cargo install mdbook --version '^0.4.3' +- cargo install mdbook --version '^0.4.5' - cargo install mdbook-linkcheck --version '^0.7.2' script: - git checkout -b ci From 49f1ed8d778351991bd5f7f4a10896aceff09337 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 5 Jan 2021 10:03:54 +0900 Subject: [PATCH 1387/1812] Fix "Potential incomplete link" error on compiler-debugging.md --- src/compiler-debugging.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index b1addb249..918761971 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -182,11 +182,13 @@ If you are developing rustdoc, use `RUSTDOC_LOG` instead. If you are developing Miri, use `MIRI_LOG` instead. You get the idea :) See the [`tracing`] crate's docs, and specifically the docs for [`debug!`] to -see the full syntax you can use. See the [env-logger] doc for more info on the +see the full syntax you can use. See the [`env_logger`] doc for more info on the full syntax. (Note: unlike the compiler, the [`tracing`] crate and its examples use the `RUST_LOG` environment variable. rustc, rustdoc, and other tools set custom environment variables.) +[`env_logger`]: https://docs.rs/env_logger + **Note that unless you use a very strict filter, the logger will emit a lot of output, so use the most specific module(s) you can (comma-separated if multiple)**. It's typically a good idea to pipe standard error to a file and From 92e47a05592a045247241d420ef21bcab1a5dd70 Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 4 Jan 2021 19:28:18 -0800 Subject: [PATCH 1388/1812] Remove old sentence that should have been removed It was mistakenly not removed in #997. --- src/compiler-debugging.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 918761971..df2d011de 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -182,12 +182,9 @@ If you are developing rustdoc, use `RUSTDOC_LOG` instead. If you are developing Miri, use `MIRI_LOG` instead. You get the idea :) See the [`tracing`] crate's docs, and specifically the docs for [`debug!`] to -see the full syntax you can use. See the [`env_logger`] doc for more info on the -full syntax. (Note: unlike the compiler, the [`tracing`] crate and its examples -use the `RUST_LOG` environment variable. rustc, rustdoc, and other tools set -custom environment variables.) - -[`env_logger`]: https://docs.rs/env_logger +see the full syntax you can use. (Note: unlike the compiler, the [`tracing`] +crate and its examples use the `RUST_LOG` environment variable. rustc, rustdoc, +and other tools set custom environment variables.) **Note that unless you use a very strict filter, the logger will emit a lot of output, so use the most specific module(s) you can (comma-separated if From 468faaea875d9127d06930c836b7ac7a90fda234 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Mon, 4 Jan 2021 16:47:55 +0100 Subject: [PATCH 1389/1812] Make instructions for configuring compiler for debug more explicit --- src/compiler-debugging.md | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index df2d011de..a9856349c 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -7,6 +7,21 @@ advice about specific parts of the compiler (e.g. the [Queries Debugging and Testing chapter](./incrcomp-debugging.html) or the [LLVM Debugging chapter](./backend/debugging.md)). +## Configuring the compiler + +By default, rustc is built without most debug information. To enable debug info, +set `debug = true` in your config.toml. + +Setting `debug = true` turns on many different debug options (e.g., `debug-assertions`, +`debug-logging`, etc.) which can be individually tweaked if you want to, but many people +simply set `debug = true`. Check out the comments in `config.toml.example` for more info. + +In some cases, just setting these options will not trigger a rebuild, +so if you changed it and you already have a compiler built, you might +want to call `x.py clean` to force a rebuild. + +You will need to rebuild the compiler once you've changed any configuration options. + ## `-Z` flags The compiler has a bunch of `-Z` flags. These are unstable flags that are only @@ -25,8 +40,8 @@ normal Rust programs. IIRC backtraces **don't work** on MinGW, sorry. If you have trouble or the backtraces are full of `unknown`, you might want to find some way to use Linux, Mac, or MSVC on Windows. -In the default configuration, you don't have line numbers enabled, so the -backtrace looks like this: +In the default configuration (without `debug` set to `true`), you don't have line numbers +enabled, so the backtrace looks like this: ```text stack backtrace: @@ -45,10 +60,9 @@ stack backtrace: 37: rustc_driver::run_compiler ``` -If you want line numbers for the stack trace, you can enable `debug = true` in -your config.toml and rebuild the compiler (`debuginfo-level = 1` will also add -line numbers, but `debug = true` gives full debuginfo). Then the backtrace will -look like this: +If you set `debug = true`, you will get line numbers for the stack trace. +`debuginfo-level = 1` will also add line numbers, but `debug = true` gives +full debug info. Then the backtrace will look like this: ```text stack backtrace: @@ -260,10 +274,6 @@ if you run the compiler with `RUSTC_LOG=rustc rustc some.rs` and only see `INFO` logs, make sure that `debug-logging=true` is turned on in your config.toml. -In some cases, just setting it will not trigger a rebuild, -so if you changed it and you already have a compiler built, you might -want to call `x.py clean` to force one. - ### Logging etiquette and conventions Because calls to `debug!` are removed by default, in most cases, don't worry From df8df90fe9aa1e2db70216ad51fd300ec883b786 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Mon, 4 Jan 2021 17:25:39 +0100 Subject: [PATCH 1390/1812] Update src/compiler-debugging.md Co-authored-by: Joshua Nelson --- src/compiler-debugging.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index a9856349c..13cb3cf74 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -60,9 +60,7 @@ stack backtrace: 37: rustc_driver::run_compiler ``` -If you set `debug = true`, you will get line numbers for the stack trace. -`debuginfo-level = 1` will also add line numbers, but `debug = true` gives -full debug info. Then the backtrace will look like this: +If you set `debug = true`, you will get line numbers for the stack trace. Then the backtrace will look like this: ```text stack backtrace: From a62429b367dbf1c2463c7dc5a1f259519bb6f40a Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Tue, 5 Jan 2021 09:54:03 +0100 Subject: [PATCH 1391/1812] Remove backticks and comment about possible bug --- src/compiler-debugging.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 13cb3cf74..2fb2e603f 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -14,11 +14,7 @@ set `debug = true` in your config.toml. Setting `debug = true` turns on many different debug options (e.g., `debug-assertions`, `debug-logging`, etc.) which can be individually tweaked if you want to, but many people -simply set `debug = true`. Check out the comments in `config.toml.example` for more info. - -In some cases, just setting these options will not trigger a rebuild, -so if you changed it and you already have a compiler built, you might -want to call `x.py clean` to force a rebuild. +simply set `debug = true`. Check out the comments in config.toml.example for more info. You will need to rebuild the compiler once you've changed any configuration options. From ed721052a6de51073b5bae6d735e8475882e8abc Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Tue, 5 Jan 2021 09:55:39 +0100 Subject: [PATCH 1392/1812] Break up long line --- src/compiler-debugging.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 2fb2e603f..a04ef0ea9 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -56,7 +56,8 @@ stack backtrace: 37: rustc_driver::run_compiler ``` -If you set `debug = true`, you will get line numbers for the stack trace. Then the backtrace will look like this: +If you set `debug = true`, you will get line numbers for the stack trace. +Then the backtrace will look like this: ```text stack backtrace: From ba9259eaafffa1a88c96ee4082270e07d16be1f0 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 9 Jan 2021 17:18:57 -0800 Subject: [PATCH 1393/1812] Fix typo (#1016) "currenty"! --- src/identifiers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/identifiers.md b/src/identifiers.md index 3923c9332..d04509b68 100644 --- a/src/identifiers.md +++ b/src/identifiers.md @@ -42,7 +42,7 @@ The HIR uses a bunch of different identifiers that coexist and serve different p Unlike [`DefId`]s, a [`HirId`] can refer to [fine-grained entities][Node] like expressions, but stays local to the current crate. -- A [`BodyId`] identifies a HIR [`Body`] in the current crate. It is currenty only +- A [`BodyId`] identifies a HIR [`Body`] in the current crate. It is currently only a wrapper around a [`HirId`]. For more info about HIR bodies, please refer to the [HIR chapter][hir-bodies]. From d87e197f263a54e37381c274c9f5c29de3fbfc76 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 9 Jan 2021 17:10:18 -0800 Subject: [PATCH 1394/1812] Point to `HirId` instead of `NodeId` --- src/identifiers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/identifiers.md b/src/identifiers.md index d04509b68..37e6a1c92 100644 --- a/src/identifiers.md +++ b/src/identifiers.md @@ -29,7 +29,7 @@ The HIR uses a bunch of different identifiers that coexist and serve different p - A [`DefId`], as the name suggests, identifies a particular definition, or top-level item, in a given crate. It is composed of two parts: a [`CrateNum`] which identifies the crate the definition comes from, and a [`DefIndex`] which identifies the definition - within the crate. Unlike [`NodeId`]s, there isn't a [`DefId`] for every expression, which + within the crate. Unlike [`HirId`]s, there isn't a [`DefId`] for every expression, which makes them more stable across compilations. - A [`LocalDefId`] is basically a [`DefId`] that is known to come from the current crate. From e7ac2ff724ae63c42ced14b8d8ef8cec3d67924b Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 10 Jan 2021 13:19:39 -0800 Subject: [PATCH 1395/1812] Update 'Workspace structure' section (#1017) * Update description of `src/` * Note that `library/` also contains the Rust runtime --- src/compiler-src.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index b26ede579..bcf169a13 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -15,18 +15,24 @@ look at the structure of the contents of the rust-lang/rust repo. The `rust-lang/rust` repository consists of a single large cargo workspace containing the compiler, the standard libraries (`core`, `alloc`, `std`, -`proc_macro`, etc), and `rustdoc`, along with the build system and bunch of +`proc_macro`, etc), and `rustdoc`, along with the build system and a bunch of tools and submodules for building a full Rust distribution. As of this writing, this structure is gradually undergoing some transformation to make it a bit less monolithic and more approachable, especially to newcomers. -The repository consists of a `src` directory, under which there live many -crates, which are the source for the compiler, build system, tools, etc. This -directory is currently being broken up to be less monolithic. There is also a -`library/` directory, where the standard libraries (`core`, `alloc`, `std`, -`proc_macro`, etc) live. +The repository consists of three main directories: + +- `compiler/` contains the source code for `rustc`. It consists of many crates + that together make up the compiler. + +- `library/` contains the standard libraries (`core`, `alloc`, `std`, + `proc_macro`, `test`), as well as the Rust runtime (`backtrace`, `rtstartup`, + `lang_start`). + +- `src/` contains the source code for rustdoc, clippy, cargo, the build system, + language docs, etc. ## Standard library From 0a5bb7f5e6567f26042de1bfe1e4f42e0e6f76d3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1aki=20Garay?= Date: Sun, 10 Jan 2021 19:23:22 -0300 Subject: [PATCH 1396/1812] Add context to dated information (#1013) * Fixes #924 Add context to dated information * Fixes #924 Addressed comments and some uses of 'currently' * Update src/contributing.md Co-authored-by: Joshua Nelson * Update src/salsa.md Co-authored-by: Joshua Nelson * Fixes #924 Addressed comments * Fixes #924 Fixed line lengths. Co-authored-by: Joshua Nelson --- src/SUMMARY.md | 1 - src/about-this-guide.md | 25 ++++++++++++++--- src/backend/backend-agnostic.md | 5 ++-- .../region_inference/member_constraints.md | 5 ++-- src/contributing.md | 27 +++++++++++++++---- src/debugging-support-in-rustc.md | 2 -- src/diagnostics.md | 2 +- src/diagnostics/lintstore.md | 8 +++--- src/git.md | 8 +++--- src/llvm-coverage-instrumentation.md | 2 +- src/miri.md | 2 +- src/opaque-types-type-alias-impl-trait.md | 2 +- src/overview.md | 12 --------- src/parallel-rustc.md | 7 ++--- src/profiling.md | 2 +- .../incremental-compilation-in-detail.md | 2 +- src/queries/profiling.md | 10 +++---- .../query-evaluation-model-in-detail.md | 10 +++---- src/query.md | 2 +- src/salsa.md | 6 +++-- src/tests/intro.md | 2 +- src/the-parser.md | 4 +-- src/traits/chalk.md | 6 ++--- src/traits/lowering-module.md | 3 --- src/traits/resolution.md | 2 +- 25 files changed, 90 insertions(+), 67 deletions(-) delete mode 100644 src/traits/lowering-module.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 9a695c94d..392b3814e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -107,7 +107,6 @@ - [Lowering to logic](./traits/lowering-to-logic.md) - [Goals and clauses](./traits/goals-and-clauses.md) - [Canonical queries](./traits/canonical-queries.md) - - [Lowering module in rustc](./traits/lowering-module.md) - [Type checking](./type-checking.md) - [Method Lookup](./method-lookup.md) - [Variance](./variance.md) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 77dbf2699..740a8c7bc 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -30,10 +30,27 @@ There are six parts to this guide: [p5]: ./part-5-intro.md [app]: ./appendix/background.md -The Guide itself is of course open-source as well, and the sources can -be found at the [GitHub repository]. If you find any mistakes in the -guide, please file an issue about it, or even better, open a PR -with a correction! +### Constant change + +Keep in mind that `rustc` is a real production-quality product, being worked upon continuously by a +sizeable set of contributors. +As such, it has its fair share of codebase churn and technical debt. +In addition, many of the ideas discussed throughout this guide are idealized designs that are not +fully realized yet. +All this makes keeping this guide completely up to date on everything very hard! + +The Guide itself is of course open-source as well, and the sources can be found at the +[GitHub repository]. +If you find any mistakes in the guide, please file an issue about it, or even better, open a PR with +a correction! + +If you do contribute to the guide, please see the corresponding +[subsection on writing documentation in this guide]. + +[subsection on writing documentation in this guide]: contributing.md#contributing-to-rustc-dev-guide. + +> “‘All conditioned things are impermanent’ — when one sees this with wisdom, one turns away from +> suffering.” _The Dhammapada, verse 277_ ## Other places to find information diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md index e1eeb9a7f..e02bbfe52 100644 --- a/src/backend/backend-agnostic.md +++ b/src/backend/backend-agnostic.md @@ -1,8 +1,7 @@ # Backend Agnostic Codegen -In the future, it would be nice to allow other codegen backends (e.g. -[Cranelift]). To this end, `rustc_codegen_ssa` provides an -abstract interface for all backends to implement. +As of January 2021, `rustc_codegen_ssa` provides an abstract interface for all backends to +implement, to allow other codegen backends (e.g. [Cranelift]). [Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/HEAD/cranelift diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 0435ff8c8..4aa63a13c 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -92,8 +92,9 @@ member constraints come in. ## Choices are always lifetime parameters At present, the "choice" regions from a member constraint are always -lifetime parameters from the current function. This falls out from the -placement of impl Trait, though in the future it may not be the case. +lifetime parameters from the current function. As of January 2021, +this falls out from the placement of impl Trait, though in the future +it may not be the case. We take some advantage of this fact, as it simplifies the current code. In particular, we don't have to consider a case like `'0 member of ['1, 'static]`, in which the value of both `'0` and `'1` are being diff --git a/src/contributing.md b/src/contributing.md index bc846f9c7..cc1605d1a 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -401,11 +401,28 @@ You can also use `rustdoc` directly to check small fixes. For example, `rustdoc src/doc/reference.md` will render reference to `doc/reference.html`. The CSS might be messed up, but you can verify that the HTML is right. -Additionally, contributions to the [rustc-dev-guide][rdg] are always welcome. -Contributions can be made directly at [the rust-lang/rustc-dev-guide -repo][rdgrepo]. The issue tracker in that repo is also a great way to find -things that need doing. There are issues for beginners and advanced compiler -devs alike! +### Contributing to rustc-dev-guide + +Contributions to the [rustc-dev-guide][rdg] are always welcome, and can be made directly at +[the rust-lang/rustc-dev-guide repo][rdgrepo]. +The issue tracker in that repo is also a great way to find things that need doing. +There are issues for beginners and advanced compiler devs alike! + +Just a few things to keep in mind: + +- Please limit line length to 100 characters. This is enforced by CI, and you can run the checks + locally with `ci/check_line_lengths.sh`. +- When contributing text to the guide, please contextualize the information with some time period + and/or a reason so that the reader knows how much to trust or mistrust the information. + Aim to provide a reasonable amount of context, possibly including but not limited to: + - A reason for why the data may be out of date other than "change", as change is a constant across + the project. + - A date the comment was added, e.g. instead of writing _"Currently, ..."_ consider writing + _"As of January 2021, ..."_. + Try to format the date as ` ` to ease search. + - A link to a relevant WG, tracking issue, `rustc` rustdoc page, or similar, that may provide + further explanation for the change process or a way to verify that the information is not + outdated. [rdg]: https://rustc-dev-guide.rust-lang.org/ [rdgrepo]: https://github.com/rust-lang/rustc-dev-guide diff --git a/src/debugging-support-in-rustc.md b/src/debugging-support-in-rustc.md index 912ceffae..5422e18dc 100644 --- a/src/debugging-support-in-rustc.md +++ b/src/debugging-support-in-rustc.md @@ -93,8 +93,6 @@ document so there is no duplication etc.? ### LLDB -We have our own fork of LLDB - [https://github.com/rust-lang/lldb] - Fork of LLVM project - [https://github.com/rust-lang/llvm-project] LLDB currently only works on macOS because of a dependency issue. This issue was easier to diff --git a/src/diagnostics.md b/src/diagnostics.md index e3a60447b..c88074748 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -594,7 +594,7 @@ declare_lint! { If you need a combination of options that's not supported by the `declare_lint!` macro, you can always define your own static with a type of -`&Lint` but this is currently linted against in the compiler tree. +`&Lint` but this is (as of January 2021) linted against in the compiler tree. #### Guidelines for creating a future incompatibility lint diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index 8f0c21ab3..e088185a7 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -15,9 +15,11 @@ Unfortunately, a lot of the documentation we have refers to both of these as jus First, we have the lint declarations themselves: this is where the name and default lint level and other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which -boils down to a static with type `&rustc_session::lint::Lint`. We lint against direct declarations -without the use of the macro today (though this may change in the future, as the macro is somewhat -unwieldy to add new fields to, like all macros by example). +boils down to a static with type `&rustc_session::lint::Lint`. + +As of January 2021, we lint against direct declarations without the use of the macro today +(although this may change in the future, as the macro is somewhat unwieldy to add new fields to, +like all macros by example). Lint declarations don't carry any "state" - they are merely global identifers and descriptions of lints. We assert at runtime that they are not registered twice (by lint name). diff --git a/src/git.md b/src/git.md index d1e6b8c41..8775b70e6 100644 --- a/src/git.md +++ b/src/git.md @@ -145,8 +145,10 @@ no changes added to commit (use "git add" and/or "git commit -a") These changes are not changes to files: they are changes to submodules (more on this [later](#git-submodules)). To get rid of those, run `git submodule update` (or run any `x.py` command, which will automatically update the submodules). -Note that there is currently a bug if you use worktrees, submodules, and x.py in a commit hook. +Note that there is (as of January 2021) a bug if you use worktrees, submodules, and x.py in a commit +hook. If you run into an error like: + ``` error: failed to read `/home/joshua/rustc-worktree/src/tools/miri/cargo-miri/Cargo.toml` @@ -202,7 +204,7 @@ rebase. The section between `<<<<<<< HEAD` and `=======` has the code from master, while the other side has your version of the code. You'll need to decide how to deal with the conflict. You may want to keep your changes, keep the changes on master, or combine the two. - + Generally, resolving the conflict consists of two steps: First, fix the particular conflict. Edit the file to make the changes you want and remove the `<<<<<<<`, `=======` and `>>>>>>>` lines in the process. Second, check the @@ -311,7 +313,7 @@ This is because, like any dependency, we want to be able to control which versio Submodules allow us to do just that: every submodule is "pinned" to a certain commit, which doesn't change unless modified manually. If you use `git checkout ` in the `miri` directory and go back to the `rust` directory, you can stage this -change like any +change like any This is usually done by the maintainers of the project, and looks like [this][miri-update]. diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 1cc6a2717..23117f527 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -219,7 +219,7 @@ properly-configured variables in LLVM IR, according to very specific details of the [_LLVM Coverage Mapping Format_][coverage-mapping-format] (Version 4).[^llvm-and-covmap-versions] -[^llvm-and-covmap-versions]: The Rust compiler currently supports +[^llvm-and-covmap-versions]: The Rust compiler (as of January 2021) supports _LLVM Coverage Mapping Format_ Version 4 (the most up-to-date version of the format, at the time of this writing) for improved compatibility with other LLVM-based compilers (like _Clang_), and to take advantage diff --git a/src/miri.md b/src/miri.md index af2a92802..71a7e6cde 100644 --- a/src/miri.md +++ b/src/miri.md @@ -191,7 +191,7 @@ concrete integer. However, a variable of pointer or reference *type*, such as `*const T` or `&T`, does not have to have a pointer *value*: it could be obtaining by casting or -transmuting an integer to a pointer (currently that is hard to do in const eval, +transmuting an integer to a pointer (as of January 2021 that is hard to do in const eval, but eventually `transmute` will be stable as a `const fn`). And similarly, when casting or transmuting a reference to some actual allocation to an integer, we end up with a pointer *value* (`Scalar::Ptr`) at integer *type* (`usize`). This diff --git a/src/opaque-types-type-alias-impl-trait.md b/src/opaque-types-type-alias-impl-trait.md index e78d3c75d..e95291fef 100644 --- a/src/opaque-types-type-alias-impl-trait.md +++ b/src/opaque-types-type-alias-impl-trait.md @@ -14,7 +14,7 @@ This declares an opaque type named `Foo`, of which the only information is that it implements `Bar`. Therefore, any of `Bar`'s interface can be used on a `Foo`, but nothing else (regardless of whether it implements any other traits). -Since there needs to be a concrete background type, you can currently +Since there needs to be a concrete background type, you can (as of January 2021) express that type by using the opaque type in a "defining use site". ```rust,ignore diff --git a/src/overview.md b/src/overview.md index 8f1a55d10..4fe40c42f 100644 --- a/src/overview.md +++ b/src/overview.md @@ -15,7 +15,6 @@ So first, let's look at what the compiler does to your code. For now, we will avoid mentioning how the compiler implements these steps except as needed; we'll talk about that later. - - The compile process begins when a user writes a Rust source program in text and invokes the `rustc` compiler on it. The work that the compiler needs to perform is defined by command-line options. For example, it is possible to @@ -159,17 +158,6 @@ satisfy/optimize for. For example, So, as you read through the rest of the guide, keep these things in mind. They will often inform decisions that we make. -### Constant change - -Keep in mind that `rustc` is a real production-quality product. -As such, it has its fair share of codebase churn and technical debt. A lot of -the designs discussed throughout this guide are idealized designs that are not -fully realized yet. And things keep changing so that it is hard to keep this -guide completely up to date on everything! - -The compiler definitely has rough edges, but because of its design it is able -to keep up with the requirements above. - ### Intermediate representations As with most compilers, `rustc` uses some intermediate representations (IRs) to diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 0405a947a..cb36fef6f 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -1,9 +1,10 @@ # Parallel Compilation Most of the compiler is not parallel. This represents an opportunity for -improving compiler performance. Much effort has been put into parallelizing -`rustc`, but it is still pretty early days for this work. There is a lot of -design and correctness work that needs to be done. +improving compiler performance. + +As of January 2021, work on explicitly parallelizing the compiler has stalled. +There is a lot of design and correctness work that needs to be done. One can try out the current parallel compiler work by enabling it in the `config.toml`. diff --git a/src/profiling.md b/src/profiling.md index a1f1a4b77..902281f18 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -90,5 +90,5 @@ The llvm-lines output is affected by several options. MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Z mir-opt-level=1"`, level 0 adds 0.3GB and level 2 removes 0.2GB. -Inlining currently only happens in LLVM, but this might change in the future. +As of January 2021, inlining currently only happens in LLVM but this might change in the future. diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index bea9a886f..c00ed042e 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -207,7 +207,7 @@ This comes with a whole new set of implementation challenges: Fixed-sized, plain-old-data is preferred to complex things that need to run through an expensive (de-)serialization step. -The following sections describe how the compiler currently solves these issues. +The following sections describe how the compiler solves these issues. ### A Question Of Stability: Bridging The Gap Between Compilation Sessions diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 7e0b68686..f124d453a 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -2,7 +2,7 @@ In an effort to support _incremental compilation_, the latest design of the Rust compiler consists of a _query-based_ model. -The details of this model are (currently) outside the scope of this document, +The details of this model are outside the scope of this document, however, we explain [some background of this model](#background), in an effort to explain how we profile its performance. We intend this profiling effort to address [issue 42678](https://github.com/rust-lang/rust/issues/42678). @@ -50,7 +50,7 @@ This command will generate the following files: - This additional flag will add all timed passes to the output files mentioned above, in step 2. As described below, these passes appear visually distinct - from the queries in the HTML output (they currently appear as green boxes, via + from the queries in the HTML output (they appear as green boxes, via CSS). ### 4. Inspect the output @@ -86,8 +86,8 @@ The trace of the queries has a formal structure; see We style this formal structure as follows: - **Timed passes:** Green boxes, when present (via `-Z time-passes`), represent - _timed passes_ in the compiler. In future versions, these passes may be - replaced by queries, explained below. + _timed passes_ in the compiler. As of January 2021 these passes are not queries, but may be + replaced by queries in future versions. - **Labels:** Some green and red boxes are labeled with text. Where they are present, the labels give the following information: - The [query's _provider_](#queries), sans its _key_ and its _result_, which @@ -111,7 +111,7 @@ Heuristics-based CSS Classes: - `important` -- Trace nodes are `important` if they have an extent of 6 (or more), _or_ they have a duration fraction of one percent (or more). These - numbers are simple heuristics (currently hard-coded, but easy to modify). + numbers are simple heuristics (hard-coded, but easy to modify). Important nodes are styled with textual labels, and highlighted borders (light red, and bolded). diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 8f38853c4..54f750bbd 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -75,11 +75,11 @@ When the query context is created, it is still empty: No queries have been executed, no results are cached. But the context already provides access to "input" data, i.e. pieces of immutable data that were computed before the context was created and that queries can access to do their computations. -Currently this input data consists mainly of the HIR map, upstream crate -metadata, and the command-line -options the compiler was invoked with. In the future, inputs will just consist -of command-line options and a list of source files -- the HIR map will itself -be provided by a query which processes these source files. + +As of January 2021, this input data consists mainly of the HIR map, upstream crate metadata, and the +command-line options the compiler was invoked with; but in the future inputs will just consist of +command-line options and a list of source files -- the HIR map will itself be provided by a query +which processes these source files. Without inputs, queries would live in a void without anything to compute their result from (remember, query providers only have access to other queries and diff --git a/src/query.md b/src/query.md index 77d3b50e5..eb0bbe78e 100644 --- a/src/query.md +++ b/src/query.md @@ -1,7 +1,7 @@ # Queries: demand-driven compilation As described in [the high-level overview of the compiler][hl], the -Rust compiler is currently transitioning from a traditional "pass-based" +Rust compiler is still (as of January 2021) transitioning from a traditional "pass-based" setup to a "demand-driven" system. **The Compiler Query System is the key to our new demand-driven organization.** The idea is pretty simple. You have various queries that compute things about the input diff --git a/src/salsa.md b/src/salsa.md index 567f1b153..36aeb18bf 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -7,8 +7,10 @@ want to watch [Salsa In More Depth](https://www.youtube.com/watch?v=i_IhACacPRY), also by Niko Matsakis. -> Salsa is not used directly in rustc, but it is used extensively for -> rust-analyzer and may be integrated into the compiler in the future. +> As of January 2021, although Salsa is inspired by (among other things) rustc's query system, +> it is not used directly in rustc. +> It _is_ used in chalk and extensively in `rust-analyzer`, but there are no medium or long-term +> concrete plans to integrate it into the compiler. ## What is Salsa? diff --git a/src/tests/intro.md b/src/tests/intro.md index 51c0e2d6e..04deb427a 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -123,7 +123,7 @@ essence, it runs `./x.py test` after building for each of them. The integration bot [bors] is used for coordinating merges to the master branch. When a PR is approved, it goes into a [queue] where merges are tested -one at a time on a wide set of platforms using GitHub Actions (currently over +one at a time on a wide set of platforms using GitHub Actions (as of January 2021 over 50 different configurations). Due to the limit on the number of parallel jobs, we run CI under the [rust-lang-ci] organization except for PRs. Most platforms only run the build steps, some run a restricted set of tests, diff --git a/src/the-parser.md b/src/the-parser.md index d3e48a17e..915e4bb9a 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -1,7 +1,7 @@ # Lexing and Parsing -> The parser and lexer are currently undergoing a lot of refactoring, so parts -> of this chapter may be out of date. +As of January 2021, the lexer and parser are undergoing refactoring to allow +extracting them into libraries. The very first thing the compiler does is take the program (in Unicode characters) and turn it into something the compiler can work with more diff --git a/src/traits/chalk.md b/src/traits/chalk.md index 659f69637..540077cf0 100644 --- a/src/traits/chalk.md +++ b/src/traits/chalk.md @@ -1,9 +1,9 @@ # Chalk-based trait solving -[Chalk][chalk] is an experimental trait solver for rust that is currently +[Chalk][chalk] is an experimental trait solver for rust that is (as of January 2021) under development by the [Traits Working Group][wg]. Its goal is to enable a lot of trait system features and bug fixes that are -currently hard to implement (e.g. GATs or specialization). if you +hard to implement (e.g. GATs or specialization). If you would like to help in hacking on the new solver, you will find instructions for getting involved in the [Traits Working Group tracking issue][wg]. @@ -28,7 +28,7 @@ You can read more about chalk itself in the [Chalk book](https://rust-lang.github.io/chalk/book/) section. ## Ongoing work -The design of the new-style trait solving currently happens in two places: +The design of the new-style trait solving happens in two places: **chalk**. The [chalk][chalk] repository is where we experiment with new ideas and designs for the trait system. diff --git a/src/traits/lowering-module.md b/src/traits/lowering-module.md deleted file mode 100644 index 8795cb79c..000000000 --- a/src/traits/lowering-module.md +++ /dev/null @@ -1,3 +0,0 @@ -# The lowering module in rustc - -This work is ongoing. This section will be filled in once some of it has landed in `rustc`. diff --git a/src/traits/resolution.md b/src/traits/resolution.md index 236ca966d..3041b85d8 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -118,7 +118,7 @@ the obligation contains unbound inference variables. The subroutines that decide whether a particular impl/where-clause/etc applies to a particular obligation are collectively referred to as the -process of _matching_. At the moment, this amounts to +process of _matching_. As of January 2021, this amounts to unifying the `Self` types, but in the future we may also recursively consider some of the nested obligations, in the case of an impl. From 3e731b79346d43dde4dc8f08e2e8e4f12c890b72 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 12 Jan 2021 07:55:13 +0900 Subject: [PATCH 1397/1812] Add a note about UI test entry limitation (#1019) --- src/tests/adding.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index 65f0896e8..774ccc3ef 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -66,6 +66,8 @@ directory that helps identify what piece of code is being tested here If you've tried and cannot find a more relevant place, the test may be added to `src/test/ui/issues/`. Still, **do include the issue number somewhere**. +But please avoid putting your test there as possible since that +directory has too many tests and it causes poor semantic organization. When writing a new feature, **create a subdirectory to store your tests**. For example, if you are implementing RFC 1234 ("Widgets"), @@ -391,6 +393,21 @@ and so forth. [hw-main]: https://github.com/rust-lang/rust/blob/master/src/test/ui/hello_world/main.rs [hw]: https://github.com/rust-lang/rust/blob/master/src/test/ui/hello_world/ +We now have a ton of UI tests and some directories have too many entries. +This is a problem because it isn't editor/IDE friendly and GitHub UI won't +show more than 1000 entries. To resolve it and organize semantic structure, +we have a tidy check to ensure the number of entries is less than 1000. +However, since `src/test/ui` (UI test root directory) and +`src/test/ui/issues` directories have more than 1000 entries, +we set a different limit for each directories. So, please +avoid putting a new test there and try to find a more relevant place. +For example, if your test is related to closures, you should put it in +`src/test/ui/closures`. If you're not sure where is the best place, +it's still okay to add to `src/test/ui/issues/`. When you reach the limit, +you could increase it by tweaking [here][ui test tidy]. + +[ui test tidy]: https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/ui_tests.rs + ### Tests that do not result in compile errors By default, a UI test is expected **not to compile** (in which case, From 7ea20079df652971caac761ec8ed7e88c4eb2e72 Mon Sep 17 00:00:00 2001 From: saki-osive <62865682+saki-osive@users.noreply.github.com> Date: Fri, 15 Jan 2021 03:40:08 +0530 Subject: [PATCH 1398/1812] Corrected MIR file path and fixed a typo (#1020) --- README.md | 2 +- src/part-5-intro.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 5448ca9bb..c8507374e 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ for the docs you're looking for instead of reading them top to bottom. ### Contributing to the guide -The guide is useful today, but it has a lot of work still go. +The guide is useful today, but it has a lot of work still to go. If you'd like to help improve the guide, we'd love to have you! You can find plenty of issues on the [issue diff --git a/src/part-5-intro.md b/src/part-5-intro.md index 82663b562..78e6fa2e9 100644 --- a/src/part-5-intro.md +++ b/src/part-5-intro.md @@ -9,7 +9,7 @@ and transform it into [MIR]. We have also shown how the compiler does various analyses on the code to detect things like type or lifetime errors. Now, we will finally take the MIR and produce some executable machine code. -[MIR]: ./mir/index.html +[MIR]: ./mir/index.md > NOTE: This part of a compiler is often called the _backend_ the term is a bit > overloaded because in the compiler source, it usually refers to the "codegen From c87ef623510dbe01d2f4e4c062409a49a13e96f6 Mon Sep 17 00:00:00 2001 From: saki-osive Date: Sat, 16 Jan 2021 17:08:11 +0530 Subject: [PATCH 1399/1812] Fixed a grammatical error in hardawre requirements section --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 8b2fc48f8..a460bff01 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -70,7 +70,7 @@ recommend trying to build on a Raspberry Pi :P clearing incremental caches. More space is better, the compiler is a bit of a hog; it's a problem we are aware of. - Recommended >=8GB RAM. -- Recommended >=2 cores; more cores really helps. +- Recommended >=2 cores; having more cores really helps. - You will need an internet connection to build; the bootstrapping process involves updating git submodules and downloading a beta compiler. It doesn't need to be super fast, but that can help. From 93fcae632219907fafc0ce99f75c0aae7578c3f6 Mon Sep 17 00:00:00 2001 From: ashosive Date: Sat, 16 Jan 2021 22:26:14 +0530 Subject: [PATCH 1400/1812] improved the readablity of a line --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index a460bff01..d70c3776e 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -50,7 +50,7 @@ and a bunch of tools (e.g. `rustdoc`, the bootstrapping infrastructure, etc). There are also a bunch of submodules for things like LLVM, `clippy`, `miri`, etc. You don't need to clone these immediately, but the build tool will -automatically clone and sync them (more later). +automatically clone and sync them (more on this later). [**Take a look at the "Suggested Workflows" chapter for some helpful advice.**][suggested] From 176bbba4bfb11bee5e55ce6def7121ce1046e821 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sat, 16 Jan 2021 11:22:56 -0500 Subject: [PATCH 1401/1812] Note that `--check` now allows using any stage --- src/building/bootstrapping.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 3e5cabbe8..e132d6941 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -70,13 +70,10 @@ These defaults are as follows: - `install`: `--stage 2` - `bench`: `--stage 2` -You can always override the stage by passing `--stage N` explicitly, except for `check`, -which is [hard-coded to stage 0][stage1-check]. +You can always override the stage by passing `--stage N` explicitly. For more information about stages, [see below](#understanding-stages-of-bootstrap). -[stage1-check]: https://github.com/rust-lang/rust/issues/46955 - ## Complications of bootstrapping Since the build system uses the current beta compiler to build the stage-1 From a090b28d8e3100dfd9e008be4e2a2bbe22f1d9f4 Mon Sep 17 00:00:00 2001 From: Martin Geisler Date: Sun, 17 Jan 2021 15:50:04 +0100 Subject: [PATCH 1402/1812] Fix typo (#1027) --- src/rustdoc-internals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index 895263b53..f739ff82a 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -162,7 +162,7 @@ documentation in `test.rs`, but instead of going through the full clean and render process, it runs a much simpler crate walk to grab *just* the hand-written documentation. Combined with the aforementioned "`find_testable_code`" in `html/markdown.rs`, it builds up a collection of -tests to run before handing them off to the test test runner. One notable +tests to run before handing them off to the test runner. One notable location in `test.rs` is the function `make_test`, which is where hand-written doctests get transformed into something that can be executed. From bd8e94a001837b6dee0c36d3020f0ad55ea0eea6 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 19 Jan 2021 14:47:45 -0500 Subject: [PATCH 1403/1812] Link to `feature_err` in stability section (#1022) --- src/implementing_new_features.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 3a65f15e7..03da87620 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -138,7 +138,8 @@ a new unstable feature: If the feature gate is not set, you should either maintain the pre-feature behavior or raise an error, depending on - what makes sense. + what makes sense. Errors should generally use [`rustc_session::parse::feature_err`]. + For an example of adding an error, see [#81015]. For features introducing new syntax, pre-expansion gating should be used instead. To do so, extend the [`GatedSpans`] struct, add spans to it during parsing, @@ -160,6 +161,8 @@ a new unstable feature: implemented a feature in Rust! [`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.GatedSpans.html +[#81015]: https://github.com/rust-lang/rust/pull/81015 +[`rustc_session::parse::feature_err`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/fn.feature_err.html [`rustc_ast_passes::feature_gate::check_crate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_passes/feature_gate/fn.check_crate.html [value the stability of Rust]: https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md [stability in code]: #stability-in-code From bee2fd52ced1f142f6d4136fe0a96b97e5a49e48 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?I=C3=B1aki=20Garay?= Date: Wed, 20 Jan 2021 14:33:11 -0300 Subject: [PATCH 1404/1812] Add mdbook-toc, markers, and documentation (#1028) * Add mdbook-toc to travis, book.toml and documentation * Add toc markers * Whitespace cleanup and some punctuation * Addressed comments --- .travis.yml | 1 + README.md | 9 +++- book.toml | 4 ++ src/about-this-guide.md | 2 +- src/backend/backend-agnostic.md | 2 + src/backend/implicit-caller-location.md | 46 ++++++++++--------- src/backend/monomorph.md | 8 ++-- src/backend/updating-llvm.md | 2 + .../moves_and_initialization/move_paths.md | 14 +++--- src/borrow_check/region_inference.md | 2 + .../constraint_propagation.md | 2 + .../region_inference/lifetime_parameters.md | 2 + .../region_inference/member_constraints.md | 2 + .../placeholders_and_universes.md | 2 + src/bug-fix-procedure.md | 3 ++ src/building/bootstrapping.md | 2 + src/compiler-debugging.md | 16 ++++--- src/compiler-src.md | 4 +- src/contributing.md | 12 ++--- src/debugging-support-in-rustc.md | 2 + src/diagnostics.md | 2 + src/getting-started.md | 2 + src/git.md | 2 + src/hir.md | 10 ++-- src/llvm-coverage-instrumentation.md | 4 +- src/macro-expansion.md | 2 + src/mir/construction.md | 2 + src/mir/dataflow.md | 2 + src/mir/index.md | 4 +- src/miri.md | 2 + src/name-resolution.md | 2 + src/overview.md | 2 + src/panic-implementation.md | 14 +++--- src/profile-guided-optimization.md | 2 + .../incremental-compilation-in-detail.md | 2 + src/queries/incremental-compilation.md | 2 + src/queries/profiling.md | 3 ++ .../query-evaluation-model-in-detail.md | 4 +- src/rustdoc-internals.md | 2 + src/salsa.md | 2 + src/stability.md | 2 + src/stabilization_guide.md | 7 +-- src/test-implementation.md | 16 +++++-- src/tests/adding.md | 2 + src/tests/intro.md | 2 + src/tests/running.md | 2 + src/traits/goals-and-clauses.md | 4 +- src/traits/lowering-to-logic.md | 2 + src/traits/resolution.md | 2 + src/ty.md | 4 +- src/type-inference.md | 2 + src/variance.md | 2 + src/walkthrough.md | 2 + 53 files changed, 177 insertions(+), 76 deletions(-) diff --git a/.travis.yml b/.travis.yml index 1e5d86993..1d6747258 100644 --- a/.travis.yml +++ b/.travis.yml @@ -13,6 +13,7 @@ install: - source ~/.cargo/env || true - cargo install mdbook --version '^0.4.5' - cargo install mdbook-linkcheck --version '^0.7.2' +- cargo install mdbook-toc --version '^0.6.1' script: - git checkout -b ci - git rebase origin/master diff --git a/README.md b/README.md index c8507374e..459564364 100644 --- a/README.md +++ b/README.md @@ -40,7 +40,7 @@ rustdocs][rustdocs]. To build a local static HTML site, install [`mdbook`](https://github.com/rust-lang/mdBook) with: ``` -> cargo install mdbook mdbook-linkcheck +> cargo install mdbook mdbook-linkcheck mdbook-toc ``` and execute the following command in the root of the repository: @@ -56,6 +56,11 @@ The build files are found in the `book` directory. We use `mdbook-linkcheck` to validate URLs included in our documentation. `linkcheck` will be run automatically when you build with the instructions in the section above. +### Table of Contents + +We use `mdbook-toc` to auto-generate TOCs for long sections. You can invoke the preprocessor by +including the `` marker at the place where you want the TOC. + ### Pre-commit script We also test that line lengths are less than 100 columns. To test this locally, @@ -95,7 +100,7 @@ but we leave these instructions for when we do it again in the future. 7. Click on the log and Ctrl-f to get a search box in the log -8. Search for rustc-dev-guide. This gets you to the place where the links are checked. It is usually ~11K lines into the log +8. Search for rustc-dev-guide. This gets you to the place where the links are checked. It is usually ~11K lines into the log. 9. Look at the links in the log near that point in the log diff --git a/book.toml b/book.toml index af9cd167f..bad4fe1aa 100644 --- a/book.toml +++ b/book.toml @@ -6,6 +6,10 @@ description = "A guide to developing rustc" [build] create-missing = false +[preprocessor.toc] +command = "mdbook-toc" +renderer = ["html"] + [output.html] git-repository-url = "https://github.com/rust-lang/rustc-dev-guide" diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 740a8c7bc..d12f5a7a3 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -47,7 +47,7 @@ a correction! If you do contribute to the guide, please see the corresponding [subsection on writing documentation in this guide]. -[subsection on writing documentation in this guide]: contributing.md#contributing-to-rustc-dev-guide. +[subsection on writing documentation in this guide]: contributing.md#contributing-to-rustc-dev-guide > “‘All conditioned things are impermanent’ — when one sees this with wisdom, one turns away from > suffering.” _The Dhammapada, verse 277_ diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md index e02bbfe52..52532c258 100644 --- a/src/backend/backend-agnostic.md +++ b/src/backend/backend-agnostic.md @@ -1,5 +1,7 @@ # Backend Agnostic Codegen + + As of January 2021, `rustc_codegen_ssa` provides an abstract interface for all backends to implement, to allow other codegen backends (e.g. [Cranelift]). diff --git a/src/backend/implicit-caller-location.md b/src/backend/implicit-caller-location.md index a621b57b1..02eea5bab 100644 --- a/src/backend/implicit-caller-location.md +++ b/src/backend/implicit-caller-location.md @@ -1,9 +1,11 @@ # Implicit Caller Location + + Approved in [RFC 2091], this feature enables the accurate reporting of caller location during panics -initiated from functions like `Option::unwrap`, `Result::expect`, and `Index::index`. This feature -adds the [`#[track_caller]`][attr-reference] attribute for functions, the -[`caller_location`][intrinsic] intrinsic, and the stabilization-friendly +initiated from functions like `Option::unwrap`, `Result::expect`, and `Index::index`. This feature +adds the [`#[track_caller]`][attr-reference] attribute for functions, the +[`caller_location`][intrinsic] intrinsic, and the stabilization-friendly [`core::panic::Location::caller`][wrapper] wrapper. ## Motivating Example @@ -28,25 +30,25 @@ note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. As of 1.42, we get a much more helpful message: ``` -$ rustc +1.42.0 example.rs; example.exe +$ rustc +1.42.0 example.rs; example.exe thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` These error messages are achieved through a combination of changes to `panic!` internals to make use -of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard +of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information. ## Reading Caller Location Previously, `panic!` made use of the `file!()`, `line!()`, and `column!()` macros to construct a [`Location`] pointing to where the panic occurred. These macros couldn't be given an overridden -location, so functions which intentionally invoked `panic!` couldn't provide their own location, +location, so functions which intentionally invoked `panic!` couldn't provide their own location, hiding the actual source of error. -Internally, `panic!()` now calls [`core::panic::Location::caller()`][wrapper] to find out where it -was expanded. This function is itself annotated with `#[track_caller]` and wraps the -[`caller_location`][intrinsic] compiler intrinsic implemented by rustc. This intrinsic is easiest +Internally, `panic!()` now calls [`core::panic::Location::caller()`][wrapper] to find out where it +was expanded. This function is itself annotated with `#[track_caller]` and wraps the +[`caller_location`][intrinsic] compiler intrinsic implemented by rustc. This intrinsic is easiest explained in terms of how it works in a `const` context. ## Caller Location in `const` @@ -56,20 +58,20 @@ to find the right location and allocating a const value to return. ### Finding the right `Location` -In a const context we "walk up the stack" from where the intrinsic is invoked, stopping when we +In a const context we "walk up the stack" from where the intrinsic is invoked, stopping when we reach the first function call in the stack which does *not* have the attribute. This walk is in [`InterpCx::find_closest_untracked_caller_location()`][const-find-closest]. -Starting at the bottom, we iterate up over stack [`Frame`][const-frame]s in the +Starting at the bottom, we iterate up over stack [`Frame`][const-frame]s in the [`InterpCx::stack`][const-stack], calling -[`InstanceDef::requires_caller_location`][requires-location] on the +[`InstanceDef::requires_caller_location`][requires-location] on the [`Instance`s from each `Frame`][frame-instance]. We stop once we find one that returns `false` and return the span of the *previous* frame which was the "topmost" tracked function. ### Allocating a static `Location` -Once we have a `Span`, we need to allocate static memory for the `Location`, which is performed by -the [`TyCtxt::const_caller_location()`][const-location-query] query. Internally this calls +Once we have a `Span`, we need to allocate static memory for the `Location`, which is performed by +the [`TyCtxt::const_caller_location()`][const-location-query] query. Internally this calls [`InterpCx::alloc_caller_location()`][alloc-location] and results in a unique [memory kind][location-memory-kind] (`MemoryKind::CallerLocation`). The SSA codegen backend is able to emit code for these same values, and we use this code there as well. @@ -78,14 +80,14 @@ Once our `Location` has been allocated in static memory, our intrinsic returns a ## Generating code for `#[track_caller]` callees -To generate efficient code for a tracked function and its callers, we need to provide the same +To generate efficient code for a tracked function and its callers, we need to provide the same behavior from the intrinsic's point of view without having a stack to walk up at runtime. We invert the approach: as we grow the stack down we pass an additional argument to calls of tracked functions rather than walking up the stack when the intrinsic is called. That additional argument can be returned wherever the caller location is queried. The argument we append is of type `&'static core::panic::Location<'static>`. A reference was chosen -to avoid unnecessary copying because a pointer is a third the size of +to avoid unnecessary copying because a pointer is a third the size of `std::mem::size_of::() == 24` at time of writing. When generating a call to a function which is tracked, we pass the location argument the value of @@ -151,12 +153,12 @@ probably the best we can do without modifying fully-stabilized type signatures. > *Note:* We always emit a [`ReifyShim`] when taking a pointer to a tracked function. While the > constraint here is imposed by codegen contexts, we don't know during MIR construction of the shim -> whether we'll be called in a const context (safe to ignore shim) or in a codegen context (unsafe +> whether we'll be called in a const context (safe to ignore shim) or in a codegen context (unsafe > to ignore shim). Even if we did know, the results from const and codegen contexts must agree. ## The Attribute -The `#[track_caller]` attribute is checked alongside other codegen attributes to ensure the +The `#[track_caller]` attribute is checked alongside other codegen attributes to ensure the function: * has the `"Rust"` ABI (as opposed to e.g., `"C"`) @@ -171,7 +173,7 @@ used in both const and codegen contexts to ensure correct propagation. When applied to trait method implementations, the attribute works as it does for regular functions. -When applied to a trait method prototype, the attribute applies to all implementations of the +When applied to a trait method prototype, the attribute applies to all implementations of the method. When applied to a default trait method implementation, the attribute takes effect on that implementation *and* any overrides. @@ -203,14 +205,14 @@ trait TrackedFourWays { assert_tracked!(); } - /// Overrides of this implementation are tracked (it is too). + /// Overrides of this implementation are tracked (it is too). #[track_caller] fn default_tracked_to_override() { assert_tracked!(); } } -/// This impl uses the default impl for `default_tracked` and provides its own for +/// This impl uses the default impl for `default_tracked` and provides its own for /// `default_tracked_to_override`. impl TrackedFourWays for () { fn blanket_tracked() { @@ -253,7 +255,7 @@ up on the tracking issue. During the course of implementing that, it was also di implementation was possible without modifying the number of arguments in a function's MIR, which would simplify later stages and unlock use in traits. -Because the RFC's implementation strategy could not readily support traits, the semantics were not +Because the RFC's implementation strategy could not readily support traits, the semantics were not originally specified. They have since been implemented following the path which seemed most correct to the author and reviewers. diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index e678b4f76..0457c1841 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -1,5 +1,7 @@ # Monomorphization + + As you probably know, rust has a very expressive type system that has extensive support for generic types. But of course, assembly is not generic, so we need to figure out the concrete types of all the generics before the code can @@ -57,12 +59,12 @@ units](../appendix/glossary.md#codegen-unit). ## Codegen Unit (CGU) partitioning -For better incremental build times, the CGU partitioner creates two CGU for each source level -modules. One is for "stable" i.e. non-generic code and the other is more volatile code i.e. +For better incremental build times, the CGU partitioner creates two CGU for each source level +modules. One is for "stable" i.e. non-generic code and the other is more volatile code i.e. monoporphized/specialized instances. For depenencies, consider Crate A and Crate B, such that Crate B depends on Crate A. -The following table lists different scenarios for a function in Crate A that might be used by one +The following table lists different scenarios for a function in Crate A that might be used by one or more modules in Crate B. | Crate A function | Behavior | diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md index 015514bab..df91c8d01 100644 --- a/src/backend/updating-llvm.md +++ b/src/backend/updating-llvm.md @@ -1,5 +1,7 @@ # Updating LLVM + + The Rust compiler uses LLVM as its primary codegen backend today, and naturally we want to at least occasionally update this dependency! Currently we do not have a strict policy about when to update LLVM or what it can be updated to, but diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index 2c7c73038..e38b923cf 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -1,5 +1,7 @@ # Move paths + + In reality, it's not enough to track initialization at the granularity of local variables. Rust also allows us to do moves and initialization at the field granularity: @@ -7,11 +9,11 @@ at the field granularity: ```rust,ignore fn foo() { let a: (Vec, Vec) = (vec![22], vec![44]); - + // a.0 and a.1 are both initialized - + let b = a.0; // moves a.0 - + // a.0 is not initialized, but a.1 still is let c = a.0; // ERROR @@ -73,7 +75,7 @@ there is no need for a [`MovePathIndex`]. Some examples: there would be no move-path for `foo[1]`. - You cannot move from inside of a borrowed reference, so if we have e.g. `foo: &String`, there would be no move-path for `*foo`. - + These rules are enforced by the [`move_path_for`] function, which converts a [`Place`] into a [`MovePathIndex`] -- in error cases like those just discussed, the function returns an `Err`. This in turn @@ -102,7 +104,7 @@ of [`MoveData`]. There are two different methods: [`LookupResult`] indicating the closest path it was able to find that exists (e.g., for `foo[1]`, it might return just the path for `foo`). - + [`find`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find [`find_local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find_local [`mir::Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Local.html @@ -120,7 +122,7 @@ just over the paths that are **actually referenced** in the source, not all **possible** paths that could have been referenced). These references are used for example in the [`find_in_move_path_or_its_descendants`] function, which determines -whether a move-path (e.g., `a.b`) or any child of that move-path +whether a move-path (e.g., `a.b`) or any child of that move-path (e.g.,`a.b.c`) matches a given predicate. [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index d8cfab00c..e14bc4157 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -1,5 +1,7 @@ # Region inference (NLL) + + The MIR-based region checking code is located in [the `rustc_mir::borrow_check` module][nll]. diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index 1389628c8..f0a7f7353 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -1,5 +1,7 @@ # Constraint propagation + + The main work of the region inference is **constraint propagation**, which is done in the [`propagate_constraints`] function. There are three sorts of constraints that are used in NLL, and we'll explain how diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index 9d6b229ef..c65b8ce5a 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -1,5 +1,7 @@ # Universal regions + + "Universal regions" is the name that the code uses to refer to "named lifetimes" -- e.g., lifetime parameters and `'static`. The name derives from the fact that such lifetimes are "universally quantified" diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index 4aa63a13c..fd65acf1a 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -1,5 +1,7 @@ # Member constraints + + A member constraint `'m member of ['c_1..'c_N]` expresses that the region `'m` must be *equal* to some **choice regions** `'c_i` (for some `i`). These constraints cannot be expressed by users, but they diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index 169f1b486..20775038b 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -1,5 +1,7 @@ # Placeholders and universes + + From time to time we have to reason about regions that we can't concretely know. For example, consider this program: diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md index 69732b627..66b200f9e 100644 --- a/src/bug-fix-procedure.md +++ b/src/bug-fix-procedure.md @@ -1,4 +1,7 @@ # Rustc Bug Fix Procedure + + + This page defines the best practices procedure for making bug fixes or soundness corrections in the compiler that can cause existing code to stop compiling. This text is based on diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index e132d6941..9da24e4c6 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -1,5 +1,7 @@ # Bootstrapping the Compiler + + This subchapter is about the bootstrapping process. ## What is bootstrapping? How does it work? diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index a04ef0ea9..ecb9e30c2 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -1,6 +1,8 @@ # Debugging the compiler [debugging]: #debugging + + This chapter contains a few tips to debug the compiler. These tips aim to be useful no matter what you are working on. Some of the other chapters have advice about specific parts of the compiler (e.g. the [Queries Debugging and @@ -9,14 +11,14 @@ chapter](./backend/debugging.md)). ## Configuring the compiler -By default, rustc is built without most debug information. To enable debug info, -set `debug = true` in your config.toml. +By default, rustc is built without most debug information. To enable debug info, +set `debug = true` in your config.toml. -Setting `debug = true` turns on many different debug options (e.g., `debug-assertions`, -`debug-logging`, etc.) which can be individually tweaked if you want to, but many people +Setting `debug = true` turns on many different debug options (e.g., `debug-assertions`, +`debug-logging`, etc.) which can be individually tweaked if you want to, but many people simply set `debug = true`. Check out the comments in config.toml.example for more info. -You will need to rebuild the compiler once you've changed any configuration options. +You will need to rebuild the compiler once you've changed any configuration options. ## `-Z` flags @@ -36,7 +38,7 @@ normal Rust programs. IIRC backtraces **don't work** on MinGW, sorry. If you have trouble or the backtraces are full of `unknown`, you might want to find some way to use Linux, Mac, or MSVC on Windows. -In the default configuration (without `debug` set to `true`), you don't have line numbers +In the default configuration (without `debug` set to `true`), you don't have line numbers enabled, so the backtrace looks like this: ```text @@ -56,7 +58,7 @@ stack backtrace: 37: rustc_driver::run_compiler ``` -If you set `debug = true`, you will get line numbers for the stack trace. +If you set `debug = true`, you will get line numbers for the stack trace. Then the backtrace will look like this: ```text diff --git a/src/compiler-src.md b/src/compiler-src.md index bcf169a13..5965fd374 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -1,11 +1,13 @@ # High-level overview of the compiler source + + > **NOTE**: The structure of the repository is going through a lot of > transitions. In particular, we want to get to a point eventually where the > top-level directory has separate directories for the compiler, build-system, > std libs, etc, rather than one huge `src/` directory. > -> As of this writing, the std libs have been moved to `library/` and the crates +> As of January 2021, the std libs have been moved to `library/` and the crates > that make up the `rustc` compiler itself have been moved to `compiler/` Now that we have [seen what the compiler does](./overview.md), let's take a diff --git a/src/contributing.md b/src/contributing.md index cc1605d1a..83d5e95cb 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -3,14 +3,7 @@ Thank you for your interest in contributing to Rust! There are many ways to contribute, and we appreciate all of them. -* [Feature Requests](#feature-requests) -* [Bug Reports](#bug-reports) -* [The Build System](./building/how-to-build-and-run.md) -* [Pull Requests](#pull-requests) -* [Writing Documentation](#writing-documentation) -* [Issue Triage](#issue-triage) -* [Out-of-tree Contributions](#out-of-tree-contributions) -* [Helpful Links and Information](#helpful-links-and-information) + If you have questions, please make a post on [internals.rust-lang.org][internals] or hop on the [Rust Discord server][rust-discord] or [Rust Zulip server][rust-zulip]. @@ -423,6 +416,9 @@ Just a few things to keep in mind: - A link to a relevant WG, tracking issue, `rustc` rustdoc page, or similar, that may provide further explanation for the change process or a way to verify that the information is not outdated. +- If a text grows rather long (more than a few page scrolls) or complicated (more than four + subsections) it might benefit from having a Table of Contents at the beginning, which you can + auto-generate by including the `` marker. [rdg]: https://rustc-dev-guide.rust-lang.org/ [rdgrepo]: https://github.com/rust-lang/rustc-dev-guide diff --git a/src/debugging-support-in-rustc.md b/src/debugging-support-in-rustc.md index 5422e18dc..559031148 100644 --- a/src/debugging-support-in-rustc.md +++ b/src/debugging-support-in-rustc.md @@ -1,5 +1,7 @@ # Debugging support in the Rust compiler + + This document explains the state of debugging tools support in the Rust compiler (rustc). The document gives an overview of debugging tools like GDB, LLDB etc. and infrastructure around Rust compiler to debug Rust code. If you want to learn how to debug the Rust compiler diff --git a/src/diagnostics.md b/src/diagnostics.md index c88074748..f59844d4c 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -1,5 +1,7 @@ # Errors and Lints + + A lot of effort has been put into making `rustc` have great error messages. This chapter is about how to emit compile errors and lints from the compiler. diff --git a/src/getting-started.md b/src/getting-started.md index d70c3776e..0fc5cd8e8 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -1,5 +1,7 @@ # Getting Started + + This documentation is _not_ intended to be comprehensive; it is meant to be a quick guide for the most useful things. For more information, [see this chapter on how to build and run the compiler](./building/how-to-build-and-run.md). diff --git a/src/git.md b/src/git.md index 8775b70e6..611c47124 100644 --- a/src/git.md +++ b/src/git.md @@ -1,5 +1,7 @@ # Using Git + + The Rust project uses [Git] to manage its source code. In order to contribute, you'll need some familiarity with its features so that your changes can be incorporated into the compiler. diff --git a/src/hir.md b/src/hir.md index 014136bde..51e18973b 100644 --- a/src/hir.md +++ b/src/hir.md @@ -1,5 +1,7 @@ # The HIR + + The HIR – "High-Level Intermediate Representation" – is the primary IR used in most of rustc. It is a compiler-friendly representation of the abstract syntax tree (AST) that is generated after parsing, macro expansion, and name @@ -18,7 +20,7 @@ You can view the HIR representation of your code by passing the cargo rustc -- -Z unpretty=hir-tree ``` -### Out-of-band storage and the `Crate` type +## Out-of-band storage and the `Crate` type The top-level data-structure in the HIR is the [`Crate`], which stores the contents of the crate currently being compiled (we only ever @@ -66,7 +68,7 @@ the compiler a chance to observe that you accessed the data for -### Identifiers in the HIR +## Identifiers in the HIR There are a bunch of different identifiers to refer to other nodes or definitions in the HIR. In short: @@ -81,7 +83,7 @@ For more detailed information, check out the [chapter on identifiers][ids]. [`HirId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir_id/struct.HirId.html [ids]: ./identifiers.md#in-the-hir -### The HIR Map +## The HIR Map Most of the time when you are working with the HIR, you will do so via the **HIR Map**, accessible in the tcx via [`tcx.hir()`] (and defined in @@ -124,7 +126,7 @@ calls like [`tcx.hir().get_parent_node(n)`][get_parent_node]. [get_parent_node]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.get_parent_node -### HIR Bodies +## HIR Bodies A [`rustc_hir::Body`] represents some kind of executable code, such as the body of a function/closure or the definition of a constant. Bodies are diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 23117f527..88831f69d 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -1,5 +1,7 @@ # LLVM Source-Based Code Coverage + + `rustc` supports detailed source-based code and test coverage analysis with a command line option (`-Z instrument-coverage`) that instruments Rust libraries and binaries with additional instructions and data, at compile time. @@ -32,7 +34,7 @@ Detailed instructions and examples are documented in the [Coverage Map]: https://llvm.org/docs/CoverageMappingFormat.html [unstable-book-sbcc]: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/source-based-code-coverage.html -### Rust symbol mangling +## Rust symbol mangling `-Z instrument-coverage` automatically enables Rust symbol mangling `v0` (as if the user specified `-Z symbol-mangling-version=v0` option when invoking diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 40342a703..352d826d3 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -1,5 +1,7 @@ # Macro expansion + + > `rustc_ast`, `rustc_expand`, and `rustc_builtin_macros` are all undergoing > refactoring, so some of the links in this chapter may be broken. diff --git a/src/mir/construction.md b/src/mir/construction.md index 010305556..d2c5a6f34 100644 --- a/src/mir/construction.md +++ b/src/mir/construction.md @@ -1,5 +1,7 @@ # THIR and MIR construction + + The lowering of [HIR] to [MIR] occurs for the following (probably incomplete) list of items: diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index e3413c5e9..9958f19b9 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -1,5 +1,7 @@ # Dataflow Analysis + + If you work on the MIR, you will frequently come across various flavors of [dataflow analysis][wiki]. `rustc` uses dataflow to find uninitialized variables, determine what variables are live across a generator `yield` diff --git a/src/mir/index.md b/src/mir/index.md index 55a4a4349..5d1376975 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -1,5 +1,7 @@ # The MIR (Mid-level IR) + + MIR is Rust's _Mid-level Intermediate Representation_. It is constructed from [HIR](../hir.html). MIR was introduced in [RFC 1211]. It is a radically simplified form of Rust that is used for @@ -228,7 +230,7 @@ but [you can read about those below](#promoted)). - **Statements** are represented by the type [`Statement`]. - **Terminators** are represented by the [`Terminator`]. - **Locals** are represented by a [newtype'd] index type [`Local`]. - The data for a local variable is found in the + The data for a local variable is found in the [`Body::local_decls`][localdecls] vector). There is also a special constant [`RETURN_PLACE`] identifying the special "local" representing the return value. - **Places** are identified by the enum [`Place`]. There are a few diff --git a/src/miri.md b/src/miri.md index 71a7e6cde..d0766a07b 100644 --- a/src/miri.md +++ b/src/miri.md @@ -1,5 +1,7 @@ # Miri + + Miri (**MIR** **I**nterpreter) is a virtual machine for executing MIR without compiling to machine code. It is usually invoked via `tcx.const_eval_*` functions. diff --git a/src/name-resolution.md b/src/name-resolution.md index 3785e3aa7..2eb76384c 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -1,5 +1,7 @@ # Name resolution + + In the previous chapters, we saw how the AST is built with all macros expanded. We saw how doing that requires doing some name resolution to resolve imports and macro names. In this chapter, we show how this is actually done and more. diff --git a/src/overview.md b/src/overview.md index 4fe40c42f..5a63d6066 100644 --- a/src/overview.md +++ b/src/overview.md @@ -1,5 +1,7 @@ # Overview of the Compiler + + This chapter is about the overall process of compiling a program -- how everything fits together. diff --git a/src/panic-implementation.md b/src/panic-implementation.md index 7c10ae215..66e61548e 100644 --- a/src/panic-implementation.md +++ b/src/panic-implementation.md @@ -1,13 +1,15 @@ -### Panicking in rust ### +# Panicking in rust -#### Step 1: Invocation of the `panic!` macro. + + +## Step 1: Invocation of the `panic!` macro. There are actually two panic macros - one defined in `core`, and one defined in `std`. This is due to the fact that code in `core` can panic. `core` is built before `std`, but we want panics to use the same machinery at runtime, whether they originate in `core` or `std`. -##### core definition of panic! +### core definition of panic! The `core` `panic!` macro eventually makes the following call (in `library/core/src/panicking.rs`): @@ -57,7 +59,7 @@ Rust source). Thus, control flow will pass from core to std at runtime. This allows panics from `core` to go through the same infrastructure that other panics use (panic hooks, unwinding, etc) -##### std implementation of panic! +### std implementation of panic! This is where the actual panic-related logic begins. In `library/std/src/panicking.rs`, control passes to `rust_panic_with_hook`. This method is responsible @@ -83,7 +85,7 @@ is suitable for passing across an FFI boundary. Finally, we call `__rust_start_panic` with this `usize`. We have now entered the panic runtime. -#### Step 2: The panic runtime +## Step 2: The panic runtime Rust provides two panic runtimes: `panic_abort` and `panic_unwind`. The user chooses between them at build time via their `Cargo.toml` @@ -91,7 +93,7 @@ between them at build time via their `Cargo.toml` `panic_abort` is extremely simple: its implementation of `__rust_start_panic` just aborts, as you would expect. -`panic_unwind` is the more interesting case. +`panic_unwind` is the more interesting case. In its implementation of `__rust_start_panic`, we take the `usize`, convert it back to a `*mut &mut dyn BoxMeUp`, dereference it, and call `box_me_up` diff --git a/src/profile-guided-optimization.md b/src/profile-guided-optimization.md index 09587e6bf..145bb053c 100644 --- a/src/profile-guided-optimization.md +++ b/src/profile-guided-optimization.md @@ -1,5 +1,7 @@ # Profile Guided Optimization + + `rustc` supports doing profile-guided optimization (PGO). This chapter describes what PGO is and how the support for it is implemented in `rustc`. diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index c00ed042e..f0c6dcacd 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -1,5 +1,7 @@ # Incremental Compilation In Detail + + The incremental compilation scheme is, in essence, a surprisingly simple extension to the overall query system. It relies on the fact that: diff --git a/src/queries/incremental-compilation.md b/src/queries/incremental-compilation.md index 5ff189f96..abef144d7 100644 --- a/src/queries/incremental-compilation.md +++ b/src/queries/incremental-compilation.md @@ -1,5 +1,7 @@ # Incremental compilation + + The incremental compilation scheme is, in essence, a surprisingly simple extension to the overall query system. We'll start by describing a slightly simplified variant of the real thing – the "basic algorithm" – diff --git a/src/queries/profiling.md b/src/queries/profiling.md index f124d453a..8cd4c07d8 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -1,4 +1,7 @@ # Profiling Queries + + + In an effort to support _incremental compilation_, the latest design of the Rust compiler consists of a _query-based_ model. diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 54f750bbd..51501d3d5 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -1,7 +1,7 @@ - - # The Query Evaluation Model in Detail + + This chapter provides a deeper dive into the abstract model queries are built on. It does not go into implementation details but tries to explain the underlying logic. The examples here, therefore, have been stripped down and diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index f739ff82a..288d762b8 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -1,5 +1,7 @@ # Rustdoc internals + + This page describes rustdoc's passes and modes. For an overview of rustdoc, see [`rustdoc`](./rustdoc.md). diff --git a/src/salsa.md b/src/salsa.md index 36aeb18bf..38db066c5 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -1,5 +1,7 @@ # How Salsa works + + This chapter is based on the explanation given by Niko Matsakis in this [video](https://www.youtube.com/watch?v=_muY4HjSqVw) about [Salsa](https://github.com/salsa-rs/salsa). To find out more you may diff --git a/src/stability.md b/src/stability.md index c9e7056d6..69e434c07 100644 --- a/src/stability.md +++ b/src/stability.md @@ -1,5 +1,7 @@ # Stability attributes + + This section is about the stability attributes and schemes that allow stable APIs to use unstable APIs internally in the rustc standard library. diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 2cdb0037b..f4f58c392 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -2,12 +2,9 @@ Once an unstable feature has been well-tested with no outstanding concern, anyone may push for its stabilization. It involves the -following steps. +following steps: -- Documentation PRs -- Write a stabilization report -- FCP -- Stabilization PR + ## Documentation PRs diff --git a/src/test-implementation.md b/src/test-implementation.md index 230e2fe36..1a9283b59 100644 --- a/src/test-implementation.md +++ b/src/test-implementation.md @@ -1,4 +1,7 @@ -### The `#[test]` attribute +# The `#[test]` attribute + + + Today, rust programmers rely on a built in attribute called `#[test]`. All you have to do is mark a function as a test and include some asserts like so: @@ -35,7 +38,7 @@ What exactly is `rustc --test` doing? [`rustc_ast` crate][rustc_ast]. Essentially, it's a fancy macro, that rewrites the crate in 3 steps: -#### Step 1: Re-Exporting +## Step 1: Re-Exporting As mentioned earlier, tests can exist inside private modules, so we need a way of exposing them to the main function, without breaking any existing @@ -77,7 +80,8 @@ hand-written one, it will not share a Symbol. This technique prevents name collision during code generation and is the foundation of Rust's macro hygiene. -#### Step 2: Harness Generation +## Step 2: Harness Generation + Now that our tests are accessible from the root of our crate, we need to do something with them. `rustc_ast` generates a module like so: @@ -99,7 +103,8 @@ called [`test`][test] that is part of Rust core, that implements all of the runtime for testing. `test`'s interface is unstable, so the only stable way to interact with it is through the `#[test]` macro. -#### Step 3: Test Object Generation +## Step 3: Test Object Generation + If you've written tests in Rust before, you may be familiar with some of the optional attributes available on test functions. For example, a test can be annotated with `#[should_panic]` if we expect the test to cause a panic. It @@ -137,7 +142,8 @@ self::test::TestDescAndFn{ Once we've constructed an array of these test objects, they're passed to the test runner via the harness generated in step 2. -### Inspecting the generated code +## Inspecting the generated code + On nightly rust, there's an unstable flag called `unpretty` that you can use to print out the module source after macro expansion: diff --git a/src/tests/adding.md b/src/tests/adding.md index 774ccc3ef..868bad2d7 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -1,5 +1,7 @@ # Adding new tests + + **In general, we expect every PR that fixes a bug in rustc to come accompanied by a regression test of some kind.** This test should fail in master but pass after the PR. These tests are really useful for diff --git a/src/tests/intro.md b/src/tests/intro.md index 04deb427a..cab06df55 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -1,5 +1,7 @@ # The compiler testing framework + + The Rust project runs a wide variety of different tests, orchestrated by the build system (`x.py test`). The main test harness for testing the compiler itself is a tool called compiletest (located in the diff --git a/src/tests/running.md b/src/tests/running.md index 4fe61f30a..842a73c07 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -1,5 +1,7 @@ # Running tests + + You can run the tests using `x.py`. The most basic command – which you will almost never want to use! – is as follows: diff --git a/src/traits/goals-and-clauses.md b/src/traits/goals-and-clauses.md index 9aaab96fa..4315b3e0f 100644 --- a/src/traits/goals-and-clauses.md +++ b/src/traits/goals-and-clauses.md @@ -1,5 +1,7 @@ # Goals and clauses + + In logic programming terms, a **goal** is something that you must prove and a **clause** is something that you know is true. As described in the [lowering to logic](./lowering-to-logic.html) @@ -196,7 +198,7 @@ it is okay to assume `FromEnv(T: Clone)` in the `loud_clone` example is that we _also_ verify `WellFormed(T: Clone)` for each call site of `loud_clone`. Similarly, it is okay to assume `FromEnv(HashSet)` in the `loud_insert` example because we will verify `WellFormed(HashSet)` for each call site of -`loud_insert`. +`loud_insert`. #### Outlives(Type: Region), Outlives(Region: Region) e.g. `Outlives(&'a str: 'b)`, `Outlives('a: 'static)` diff --git a/src/traits/lowering-to-logic.md b/src/traits/lowering-to-logic.md index cc8b3bf80..1248d4346 100644 --- a/src/traits/lowering-to-logic.md +++ b/src/traits/lowering-to-logic.md @@ -1,5 +1,7 @@ # Lowering to logic + + The key observation here is that the Rust trait system is basically a kind of logic, and it can be mapped onto standard logical inference rules. We can then look for solutions to those inference rules in a diff --git a/src/traits/resolution.md b/src/traits/resolution.md index 3041b85d8..863631320 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -1,5 +1,7 @@ # Trait resolution (old-style) + + This chapter describes the general process of _trait resolution_ and points out some non-obvious things. diff --git a/src/ty.md b/src/ty.md index 49f6405fa..9ee2ccfe2 100644 --- a/src/ty.md +++ b/src/ty.md @@ -1,5 +1,7 @@ # The `ty` module: representing types + + The `ty` module defines how the Rust compiler represents types internally. It also defines the *typing context* (`tcx` or `TyCtxt`), which is the central data structure in the compiler. @@ -189,7 +191,7 @@ There are many variants on the `TyKind` enum, which you can see by looking at it - [**Array**][kindarray] Corresponds to `[T; n]`. - [**RawPtr**][kindrawptr] Corresponds to `*mut T` or `*const T`. - [**Ref**][kindref] `Ref` stands for safe references, `&'a mut T` or `&'a T`. `Ref` has some - associated parts, like `Ty<'tcx>` which is the type that the reference references. + associated parts, like `Ty<'tcx>` which is the type that the reference references. `Region<'tcx>` is the lifetime or region of the reference and `Mutability` if the reference is mutable or not. - [**Param**][kindparam] Represents a type parameter (e.g. the `T` in `Vec`). diff --git a/src/type-inference.md b/src/type-inference.md index 9c548364d..9d23b6278 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -1,5 +1,7 @@ # Type inference + + Type inference is the process of automatic detection of the type of an expression. diff --git a/src/variance.md b/src/variance.md index af23330e8..c03de7a20 100644 --- a/src/variance.md +++ b/src/variance.md @@ -1,5 +1,7 @@ # Variance of type and lifetime parameters + + For a more general background on variance, see the [background] appendix. [background]: ./appendix/background.html diff --git a/src/walkthrough.md b/src/walkthrough.md index 8a41b3dd8..b0d040942 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -1,5 +1,7 @@ # Walkthrough: a typical contribution + + There are _a lot_ of ways to contribute to the rust compiler, including fixing bugs, improving performance, helping design features, providing feedback on existing features, etc. This chapter does not claim to scratch the surface. From 4e48f42e057a5e0736d256f02433e90acfb5fff5 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Wed, 20 Jan 2021 10:46:13 -0500 Subject: [PATCH 1405/1812] Remove "Skipping LLVM build" section `download-ci-llvm` is available and enabled by default for all tier 1 platforms, so there is no need to change it. Using system LLVM over CI llvm is still supported, but is not recommended. Building LLVM from source is still supported. This also notes that you need to explicitly disable downloading LLVM when updating the submodule. --- src/backend/updating-llvm.md | 9 +++++++++ src/building/suggested.md | 34 ---------------------------------- 2 files changed, 9 insertions(+), 34 deletions(-) diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md index df91c8d01..77b2fdea7 100644 --- a/src/backend/updating-llvm.md +++ b/src/backend/updating-llvm.md @@ -102,6 +102,15 @@ through each in detail. LLVM bindings. Note that you should use `#ifdef` and such to ensure that the bindings still compile on older LLVM versions. + Note that `profile = "compiler"` and other defaults set by `x.py setup` + download LLVM from CI instead of building it from source. You should + disable this temporarily to make sure your changes are being used, by setting + ```toml + [llvm] + download-ci-llvm = false + ``` + in config.toml + 4. Test for regressions across other platforms. LLVM often has at least one bug for non-tier-1 architectures, so it's good to do some more testing before sending this to bors! If you're low on resources you can send the PR as-is diff --git a/src/building/suggested.md b/src/building/suggested.md index 58996e639..6e0f830c6 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -201,37 +201,3 @@ git worktree add -b my-feature ../rust2 master You can then use that rust2 folder as a separate workspace for modifying and building `rustc`! - -## Skipping LLVM Build - -By default, LLVM is built from source, and that takes significant amount of -time. One way to avoid that is to add this to `config.toml`: - -```toml -[llvm] -download-ci-llvm = true -``` - -Downloading LLVM from CI is still experimental though, and might not be -available on all platforms. Otherwise, we'd make it a default! - -Another alternative is to use LLVM already installed on your computer. This is -specified in the `target` section of `config.toml`: - -```toml -[target.x86_64-unknown-linux-gnu] -llvm-config = "/path/to/llvm/llvm-7.0.1/bin/llvm-config" -``` - -We have observed the following paths before, which may be different from your system: - -- `/usr/bin/llvm-config-8` -- `/usr/lib/llvm-8/bin/llvm-config` - -Note that you need to have the LLVM `FileCheck` tool installed, which is used -for codegen tests. This tool is normally built with LLVM, but if you use your -own preinstalled LLVM, you will need to provide `FileCheck` in some other way. -On Debian-based systems, you can install the `llvm-N-tools` package (where `N` -is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify -the path to `FileCheck` with the `llvm-filecheck` config item in `config.toml` -or you can disable codegen test with the `codegen-tests` item in `config.toml`. From d88726cd196970f36baba5fd419bc021fd3f768a Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 20 Jan 2021 17:42:24 -0800 Subject: [PATCH 1406/1812] Add missing period --- src/backend/updating-llvm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md index 77b2fdea7..896a0f494 100644 --- a/src/backend/updating-llvm.md +++ b/src/backend/updating-llvm.md @@ -109,7 +109,7 @@ through each in detail. [llvm] download-ci-llvm = false ``` - in config.toml + in config.toml. 4. Test for regressions across other platforms. LLVM often has at least one bug for non-tier-1 architectures, so it's good to do some more testing before From 697dba3bb731e38983db774587b547e14b230865 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Fri, 22 Jan 2021 05:49:52 -0500 Subject: [PATCH 1407/1812] Add link to promotion.md (#1033) * Add link to promotion.md * Improve link text Co-authored-by: Camelid Co-authored-by: Camelid --- src/mir/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/index.md b/src/mir/index.md index 5d1376975..306d2abfd 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -254,7 +254,7 @@ but [you can read about those below](#promoted)). ### Promoted constants -*to be written* +See the const-eval WG's [docs on promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md). [mir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html From 93a25a9fb783e7cfe89c18ba41981dd406fa3a75 Mon Sep 17 00:00:00 2001 From: LeSeulArtichaut Date: Sun, 24 Jan 2021 11:15:39 +0100 Subject: [PATCH 1408/1812] Update links to `librustc_llvm` and `rustllvm` --- src/backend/updating-llvm.md | 12 +++++++----- src/compiler-src.md | 11 +++++------ 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md index 896a0f494..a769b428d 100644 --- a/src/backend/updating-llvm.md +++ b/src/backend/updating-llvm.md @@ -98,9 +98,9 @@ through each in detail. * `./x.py build src/tools/lld` - same for LLD * `./x.py build` - build the rest of rustc - You'll likely need to update `src/rustllvm/*.cpp` to compile with updated - LLVM bindings. Note that you should use `#ifdef` and such to ensure that the - bindings still compile on older LLVM versions. + You'll likely need to update [`llvm-wrapper/*.cpp`][`llvm-wrapper`] to compile + with updated LLVM bindings. Note that you should use `#ifdef` and such to ensure + that the bindings still compile on older LLVM versions. Note that `profile = "compiler"` and other defaults set by `x.py setup` download LLVM from CI instead of building it from source. You should @@ -133,18 +133,20 @@ through each in detail. 5. Prepare a PR to `rust-lang/rust`. Work with maintainers of `rust-lang/llvm-project` to get your commit in a branch of that repository, and then you can send a PR to `rust-lang/rust`. You'll change at least - `src/llvm-project` and will likely also change `src/rustllvm/*` as well. + `src/llvm-project` and will likely also change [`llvm-wrapper`] as well. For prior art, previous LLVM updates look like [#55835](https://github.com/rust-lang/rust/pull/55835) [#47828](https://github.com/rust-lang/rust/pull/47828) [#62474](https://github.com/rust-lang/rust/pull/62474) [#62592](https://github.com/rust-lang/rust/pull/62592). Note that sometimes it's -easiest to land `src/rustllvm/*` compatibility as a PR before actually updating +easiest to land [`llvm-wrapper`] compatibility as a PR before actually updating `src/llvm-project`. This way while you're working through LLVM issues others interested in trying out the new LLVM can benefit from work you've done to update the C++ bindings. +[`llvm-wrapper`]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_llvm/llvm-wrapper + ### Caveats and gotchas Ideally the above instructions are pretty smooth, but here's some caveats to diff --git a/src/compiler-src.md b/src/compiler-src.md index 5965fd374..9880f9153 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -87,16 +87,15 @@ You can see the exact dependencies by reading the `Cargo.toml` for the various crates, just like a normal Rust crate. One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM. -During bootstrapping, LLVM is built and the [`src/librustc_llvm`] and -[`src/rustllvm`] crates contain rust wrappers around LLVM (which is written in -C++), so that the compiler can interface with it. +During bootstrapping, LLVM is built and the [`compiler/rustc_llvm`] crate +contains rust wrappers around LLVM (which is written in C++), so that the +compiler can interface with it. Most of this book is about the compiler, so we won't have any further explanation of these crates here. -[`src/llvm-project`]: https://github.com/rust-lang/rust/tree/master/src -[`src/librustc_llvm`]: https://github.com/rust-lang/rust/tree/master/src -[`src/rustllvm`]: https://github.com/rust-lang/rust/tree/master/src +[`src/llvm-project`]: https://github.com/rust-lang/rust/tree/master/src/ +[`compiler/rustc_llvm`]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_llvm ### Big picture From de386fd48ac8910f27820a402ad913871198b57e Mon Sep 17 00:00:00 2001 From: Henry Boisdequin Date: Sat, 30 Jan 2021 14:07:02 +0530 Subject: [PATCH 1409/1812] put `x.py` in ticks --- src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 9da24e4c6..5437a460a 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -107,7 +107,7 @@ However, most of the code lives in `src/bootstrap`. `bootstrap` has a difficult problem: it is written in Rust, but yet it is run before the rust compiler is built! To work around this, there are two components of bootstrap: the main one written in rust, and `bootstrap.py`. -`bootstrap.py` is what gets run by x.py. It takes care of downloading the +`bootstrap.py` is what gets run by `x.py`. It takes care of downloading the `stage0` compiler, which will then build the bootstrap binary written in Rust. From 85c995de1b29f942a85b10dd5175412cc5d32c42 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sat, 30 Jan 2021 03:12:01 -0800 Subject: [PATCH 1410/1812] Update test suite descriptions. (#1042) --- src/tests/intro.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index cab06df55..55be23cd6 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -29,10 +29,6 @@ details. - [`ui`](./adding.html#ui) – tests that check the exact stdout/stderr from compilation and/or running the test - `run-pass-valgrind` – tests that ought to run with valgrind -- `run-fail` – tests that are expected to compile but then panic - during execution -- `compile-fail` – tests that are expected to fail compilation. -- `parse-fail` – tests that are expected to fail to parse - `pretty` – tests targeting the Rust "pretty printer", which generates valid Rust code from the AST - `debuginfo` – tests that run in gdb or lldb and query the debug info @@ -40,6 +36,8 @@ details. code to make sure that the optimizations we want are taking effect. See [LLVM docs](https://llvm.org/docs/CommandGuide/FileCheck.html) for how to write such tests. +- `codegen-units` – tests for the [monomorphization](../backend/monomorph.md) + collector and CGU partitioning - `assembly` – similar to `codegen` tests, but verifies assembly output to make sure LLVM target backend can handle provided code. - `mir-opt` – tests that check parts of the generated MIR to make @@ -52,6 +50,9 @@ details. ultimate in flexibility but quite annoying to write. - `rustdoc` – tests for rustdoc, making sure that the generated files contain the expected documentation. +- `rustfix` – tests for applying [diagnostic + suggestions](../diagnostics.md#suggestions) with the + [`rustfix`](https://github.com/rust-lang/rustfix/) crate - `*-fulldeps` – same as above, but indicates that the test depends on things other than `std` (and hence those things must be built) From bd008cc786779c95f7ac54988ad6e035e38b1114 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 1 Feb 2021 13:31:00 -0500 Subject: [PATCH 1411/1812] Document how to stabilize a library feature (#1036) * Move 'force-unstable-if-unmarked' to the bootstrapping chapter * Document how to stabilize a library feature Note that features can't be stabilized until they go through FCP and that FCP happens on the tracking issue, not the PR. * Fix wrong glob By default `**` behaves the same as two `*` side by side, i.e. it only globs file paths, not directories. `shopt -s globstar` needs to be set for it to mean a directory. I didn't notice this before now because `globstar` is set by default in interactive mode, but not otherwise. --- ci/check_line_lengths.sh | 1 + src/building/bootstrapping.md | 30 +++++++++++++++++++ src/stability.md | 55 ++++++++++++----------------------- src/stabilization_guide.md | 5 ++++ 4 files changed, 55 insertions(+), 36 deletions(-) diff --git a/ci/check_line_lengths.sh b/ci/check_line_lengths.sh index 8ecb8a309..31cda5c65 100755 --- a/ci/check_line_lengths.sh +++ b/ci/check_line_lengths.sh @@ -10,6 +10,7 @@ if [ "$MAX_LINE_LENGTH" == "" ]; then fi if [ "$1" == "" ]; then + shopt -s globstar files=( src/**/*.md ) else files=( "$@" ) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 5437a460a..68c4b1ad0 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -313,12 +313,42 @@ of the public API of the standard library, but are used to implement it. `rustlib` is part of the search path for linkers, but `lib` will never be part of the search path. +#### -Z force-unstable-if-unmarked + Since `rustlib` is part of the search path, it means we have to be careful about which crates are included in it. In particular, all crates except for the standard library are built with the flag `-Z force-unstable-if-unmarked`, which means that you have to use `#![feature(rustc_private)]` in order to load it (as opposed to the standard library, which is always available). +The `-Z force-unstable-if-unmarked` flag has a variety of purposes to help +enforce that the correct crates are marked as unstable. It was introduced +primarily to allow rustc and the standard library to link to arbitrary crates +on crates.io which do not themselves use `staged_api`. `rustc` also relies on +this flag to mark all of its crates as unstable with the `rustc_private` +feature so that each crate does not need to be carefully marked with +`unstable`. + +This flag is automatically applied to all of `rustc` and the standard library +by the bootstrap scripts. This is needed because the compiler and all of its +dependencies are shipped in the sysroot to all users. + +This flag has the following effects: + +- Marks the crate as "unstable" with the `rustc_private` feature if it is not + itself marked as stable or unstable. +- Allows these crates to access other forced-unstable crates without any need + for attributes. Normally a crate would need a `#![feature(rustc_private)]` + attribute to use other unstable crates. However, that would make it + impossible for a crate from crates.io to access its own dependencies since + that crate won't have a `feature(rustc_private)` attribute, but *everything* + is compiled with `-Z force-unstable-if-unmarked`. + +Code which does not use `-Z force-unstable-if-unmarked` should include the +`#![feature(rustc_private)]` crate attribute to access these force-unstable +crates. This is needed for things that link `rustc`, such as `miri`, `rls`, or +`clippy`. + You can find more discussion about sysroots in: - The [rustdoc PR] explaining why it uses `extern crate` for dependencies loaded from sysroot - [Discussions about sysroot on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/deps.20in.20sysroot/) diff --git a/src/stability.md b/src/stability.md index 69e434c07..cfb4efd89 100644 --- a/src/stability.md +++ b/src/stability.md @@ -44,12 +44,8 @@ prevents breaking dependencies by leveraging Cargo's lint capping. [rustc bug]: https://github.com/rust-lang/rust/issues/15702 ## stable - The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly -marks an item as stabilized. To do this, follow the instructions in -[Stabilizing Features](./stabilization_guide.md). - -Note that stable functions may use unstable things in their body. +marks an item as stabilized. Note that stable functions may use unstable things in their body. ## rustc_const_unstable @@ -72,6 +68,24 @@ even on an `unstable` function, if that function is called from another Furthermore this attribute is needed to mark an intrinsic as callable from `rustc_const_stable` functions. +## Stabilizing a library feature + +To stabilize a feature, follow these steps: + +0. Ask a **@T-libs** member to start an FCP on the tracking issue and wait for + the FCP to complete (with `disposition-merge`). +1. Change `#[unstable(...)]` to `#[stable(since = "version")]`. + `version` should be the *current nightly*, i.e. stable+2. You can see which version is + the current nightly [on Forge](https://forge.rust-lang.org/#current-release-versions). +2. Remove `#![feature(...)]` from any test or doc-test for this API. If the feature is used in the + compiler or tools, remove it from there as well. +3. If applicable, change `#[rustc_const_unstable(...)]` to + `#[rustc_const_stable(since = "version")]`. +4. Open a PR against `rust-lang/rust`. + - Add the appropriate labels: `@rustbot modify labels: +T-libs`. + - Link to the tracking issue and say "Closes #XXXXX". + +You can see an example of stabilizing a feature at [#75132](https://github.com/rust-lang/rust/pull/75132). ## allow_internal_unstable @@ -130,35 +144,4 @@ default `allow`, but most of the standard library raises it to a warning with `#![warn(deprecated_in_future)]`. [`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute - -## -Z force-unstable-if-unmarked - -The `-Z force-unstable-if-unmarked` flag has a variety of purposes to help -enforce that the correct crates are marked as unstable. It was introduced -primarily to allow rustc and the standard library to link to arbitrary crates -on crates.io which do not themselves use `staged_api`. `rustc` also relies on -this flag to mark all of its crates as unstable with the `rustc_private` -feature so that each crate does not need to be carefully marked with -`unstable`. - -This flag is automatically applied to all of `rustc` and the standard library -by the bootstrap scripts. This is needed because the compiler and all of its -dependencies are shipped in the sysroot to all users. - -This flag has the following effects: - -- Marks the crate as "unstable" with the `rustc_private` feature if it is not - itself marked as stable or unstable. -- Allows these crates to access other forced-unstable crates without any need - for attributes. Normally a crate would need a `#![feature(rustc_private)]` - attribute to use other unstable crates. However, that would make it - impossible for a crate from crates.io to access its own dependencies since - that crate won't have a `feature(rustc_private)` attribute, but *everything* - is compiled with `-Z force-unstable-if-unmarked`. - -Code which does not use `-Z force-unstable-if-unmarked` should include the -`#![feature(rustc_private)]` crate attribute to access these force-unstable -crates. This is needed for things that link `rustc`, such as `miri`, `rls`, or -`clippy`. - [blog]: https://www.ralfj.de/blog/2018/07/19/const.html diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index f4f58c392..a6203a3c6 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -1,5 +1,10 @@ # Request for stabilization +**NOTE**: this page is about stabilizing language features. +For stabilizing *library* features, see [Stabilizing a library feature]. + +[Stabilizing a library feature]: ./stability.md#stabilizing-a-library-feature + Once an unstable feature has been well-tested with no outstanding concern, anyone may push for its stabilization. It involves the following steps: From 5118b6b8651683beab1621cadb2c91a004cb7a61 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 23 Jan 2021 13:38:22 -0800 Subject: [PATCH 1412/1812] Implement date-checker This tool looks for HTML comments like `` in each Markdown source file and compiles a list of dates that are older than six months. It then opens an issue with that list, with checkboxes for each file and date. Note that it will only open an issue if there was at least one date older than six months; it does nothing if the list is empty. This tool is automatically run monthly in a GitHub Actions workflow. I have tested the tool on a private repo and confirmed that it works. --- .github/workflows/date-check.yml | 44 ++++++ .gitignore | 4 +- ci/date-check/Cargo.lock | 147 +++++++++++++++++++ ci/date-check/Cargo.toml | 12 ++ ci/date-check/src/main.rs | 236 +++++++++++++++++++++++++++++++ 5 files changed, 442 insertions(+), 1 deletion(-) create mode 100644 .github/workflows/date-check.yml create mode 100644 ci/date-check/Cargo.lock create mode 100644 ci/date-check/Cargo.toml create mode 100644 ci/date-check/src/main.rs diff --git a/.github/workflows/date-check.yml b/.github/workflows/date-check.yml new file mode 100644 index 000000000..411117235 --- /dev/null +++ b/.github/workflows/date-check.yml @@ -0,0 +1,44 @@ +name: Date-Check + +on: + schedule: + # Run at noon UTC every 1st of the month + - cron: '00 12 01 * *' + + # Allow manually starting the workflow + workflow_dispatch: + +jobs: + date-check: + runs-on: ubuntu-latest + + steps: + - name: Checkout repo + uses: actions/checkout@v2 + + - name: Run `date-check` + working-directory: ci/date-check + run: | + cargo run -- ../../src/ > ../../date-check-output.txt + + - name: Open issue + uses: actions/github-script@v3 + with: + github-token: ${{secrets.GITHUB_TOKEN}} + script: | + const fs = require('fs'); + + const rawText = fs.readFileSync('date-check-output.txt', { encoding: 'utf8' }); + const title = rawText.split('\n')[0]; + if (title != 'empty') { + const body = rawText.split('\n').slice(1).join('\n'); + github.issues.create({ + owner: context.repo.owner, + repo: context.repo.repo, + title, + body, + }); + console.log('Opened issue.'); + } else { + console.log('No dates to triage.'); + } diff --git a/.gitignore b/.gitignore index b8cb34883..2901de5ed 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,6 @@ book -# prevent accidentally changes +# prevent accidental changes book.toml + +ci/date-check/target/ diff --git a/ci/date-check/Cargo.lock b/ci/date-check/Cargo.lock new file mode 100644 index 000000000..296a132d4 --- /dev/null +++ b/ci/date-check/Cargo.lock @@ -0,0 +1,147 @@ +# This file is automatically @generated by Cargo. +# It is not intended for manual editing. +[[package]] +name = "aho-corasick" +version = "0.7.15" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "7404febffaa47dac81aa44dba71523c9d069b1bdc50a77db41195149e17f68e5" +dependencies = [ + "memchr", +] + +[[package]] +name = "autocfg" +version = "1.0.1" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "cdb031dd78e28731d87d56cc8ffef4a8f36ca26c38fe2de700543e627f8a464a" + +[[package]] +name = "chrono" +version = "0.4.19" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "670ad68c9088c2a963aaa298cb369688cf3f9465ce5e2d4ca10e6e0098a1ce73" +dependencies = [ + "libc", + "num-integer", + "num-traits", + "time", + "winapi", +] + +[[package]] +name = "date-check" +version = "0.1.0" +dependencies = [ + "chrono", + "glob", + "regex", +] + +[[package]] +name = "glob" +version = "0.3.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "9b919933a397b79c37e33b77bb2aa3dc8eb6e165ad809e58ff75bc7db2e34574" + +[[package]] +name = "lazy_static" +version = "1.4.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "e2abad23fbc42b3700f2f279844dc832adb2b2eb069b2df918f455c4e18cc646" + +[[package]] +name = "libc" +version = "0.2.82" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "89203f3fba0a3795506acaad8ebce3c80c0af93f994d5a1d7a0b1eeb23271929" + +[[package]] +name = "memchr" +version = "2.3.4" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "0ee1c47aaa256ecabcaea351eae4a9b01ef39ed810004e298d2511ed284b1525" + +[[package]] +name = "num-integer" +version = "0.1.44" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "d2cc698a63b549a70bc047073d2949cce27cd1c7b0a4a862d08a8031bc2801db" +dependencies = [ + "autocfg", + "num-traits", +] + +[[package]] +name = "num-traits" +version = "0.2.14" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "9a64b1ec5cda2586e284722486d802acf1f7dbdc623e2bfc57e65ca1cd099290" +dependencies = [ + "autocfg", +] + +[[package]] +name = "regex" +version = "1.4.3" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "d9251239e129e16308e70d853559389de218ac275b515068abc96829d05b948a" +dependencies = [ + "aho-corasick", + "memchr", + "regex-syntax", + "thread_local", +] + +[[package]] +name = "regex-syntax" +version = "0.6.22" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "b5eb417147ba9860a96cfe72a0b93bf88fee1744b5636ec99ab20c1aa9376581" + +[[package]] +name = "thread_local" +version = "1.1.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "bb9bc092d0d51e76b2b19d9d85534ffc9ec2db959a2523cdae0697e2972cd447" +dependencies = [ + "lazy_static", +] + +[[package]] +name = "time" +version = "0.1.44" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "6db9e6914ab8b1ae1c260a4ae7a49b6c5611b40328a735b21862567685e73255" +dependencies = [ + "libc", + "wasi", + "winapi", +] + +[[package]] +name = "wasi" +version = "0.10.0+wasi-snapshot-preview1" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "1a143597ca7c7793eff794def352d41792a93c481eb1042423ff7ff72ba2c31f" + +[[package]] +name = "winapi" +version = "0.3.9" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "5c839a674fcd7a98952e593242ea400abe93992746761e38641405d28b00f419" +dependencies = [ + "winapi-i686-pc-windows-gnu", + "winapi-x86_64-pc-windows-gnu", +] + +[[package]] +name = "winapi-i686-pc-windows-gnu" +version = "0.4.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "ac3b87c63620426dd9b991e5ce0329eff545bccbbb34f3be09ff6fb6ab51b7b6" + +[[package]] +name = "winapi-x86_64-pc-windows-gnu" +version = "0.4.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f" diff --git a/ci/date-check/Cargo.toml b/ci/date-check/Cargo.toml new file mode 100644 index 000000000..95251fb12 --- /dev/null +++ b/ci/date-check/Cargo.toml @@ -0,0 +1,12 @@ +[package] +name = "date-check" +version = "0.1.0" +authors = ["Camelid "] +edition = "2018" + +# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html + +[dependencies] +glob = "0.3" +regex = "1" +chrono = "0.4" diff --git a/ci/date-check/src/main.rs b/ci/date-check/src/main.rs new file mode 100644 index 000000000..d78b430b5 --- /dev/null +++ b/ci/date-check/src/main.rs @@ -0,0 +1,236 @@ +use std::{ + collections::BTreeMap, + convert::TryInto as _, + env, fmt, fs, + path::{Path, PathBuf}, +}; + +use chrono::{Datelike as _, TimeZone as _, Utc}; +use glob::glob; +use regex::Regex; + +#[derive(Debug, Copy, Clone, PartialEq, Eq)] +struct Date { + year: u32, + month: u32, +} + +impl Date { + fn months_since(self, other: Date) -> Option { + let self_chrono = Utc.ymd(self.year.try_into().unwrap(), self.month, 1); + let other_chrono = Utc.ymd(other.year.try_into().unwrap(), other.month, 1); + let duration_since = self_chrono.signed_duration_since(other_chrono); + let months_since = duration_since.num_days() / 30; + if months_since < 0 { + None + } else { + Some(months_since.try_into().unwrap()) + } + } +} + +impl fmt::Display for Date { + fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { + write!(f, "{:04}-{:02}", self.year, self.month) + } +} + +fn make_date_regex() -> Regex { + Regex::new( + r"(?x) # insignificant whitespace mode + ", + ) + .unwrap() +} + +fn collect_dates_from_file(date_regex: &Regex, text: &str) -> Vec<(usize, Date)> { + let mut line = 1; + let mut end_of_last_cap = 0; + date_regex + .captures_iter(&text) + .map(|cap| { + ( + cap.get(0).unwrap().range(), + Date { + year: cap["y"].parse().unwrap(), + month: cap["m"].parse().unwrap(), + }, + ) + }) + .map(|(byte_range, date)| { + line += text[end_of_last_cap..byte_range.end] + .chars() + .filter(|c| *c == '\n') + .count(); + end_of_last_cap = byte_range.end; + (line, date) + }) + .collect() +} + +fn collect_dates(paths: impl Iterator) -> BTreeMap> { + let date_regex = make_date_regex(); + let mut data = BTreeMap::new(); + for path in paths { + let text = fs::read_to_string(&path).unwrap(); + let dates = collect_dates_from_file(&date_regex, &text); + if !dates.is_empty() { + data.insert(path, dates); + } + } + data +} + +fn filter_dates( + current_month: Date, + min_months_since: u32, + dates_by_file: impl Iterator)>, +) -> impl Iterator)> { + dates_by_file + .map(move |(path, dates)| { + ( + path, + dates + .into_iter() + .filter(|(_, date)| { + current_month + .months_since(*date) + .expect("found date that is after current month") + >= min_months_since + }) + .collect::>(), + ) + }) + .filter(|(_, dates)| !dates.is_empty()) +} + +fn main() { + let root_dir = env::args() + .nth(1) + .expect("expect root Markdown directory as CLI argument"); + let root_dir_path = Path::new(&root_dir); + let glob_pat = format!("{}/**/*.md", root_dir); + let today_chrono = Utc::today(); + let current_month = Date { + year: today_chrono.year_ce().1, + month: today_chrono.month(), + }; + + let dates_by_file = collect_dates(glob(&glob_pat).unwrap().map(Result::unwrap)); + let dates_by_file: BTreeMap<_, _> = + filter_dates(current_month, 6, dates_by_file.into_iter()).collect(); + + if dates_by_file.is_empty() { + println!("empty"); + } else { + println!("Date Reference Triage for {}", current_month); + println!("## Procedure"); + println!(); + println!( + "Each of these dates should be checked to see if the docs they annotate are \ + up-to-date. Each date should be updated (in the Markdown file where it appears) to \ + use the current month ({current_month}), or removed if the docs it annotates are not \ + expected to fall out of date quickly.", + current_month = current_month + ); + println!(); + println!( + "Please check off each date once a PR to update it (and, if applicable, its \ + surrounding docs) has been merged. Please also mention that you are working on a \ + particular set of dates so duplicate work is avoided." + ); + println!(); + println!("Finally, once all the dates have been updated, please close this issue."); + println!(); + println!("## Dates"); + println!(); + + for (path, dates) in dates_by_file { + println!( + "- [ ] {}", + path.strip_prefix(&root_dir_path).unwrap().display() + ); + for (line, date) in dates { + println!(" - [ ] line {}: {}", line, date); + } + } + println!(); + } +} + +#[cfg(test)] +mod tests { + use super::*; + + #[test] + fn test_months_since() { + let date1 = Date { + year: 2020, + month: 3, + }; + let date2 = Date { + year: 2021, + month: 1, + }; + assert_eq!(date2.months_since(date1), Some(10)); + } + + #[test] + fn test_date_regex() { + let regex = make_date_regex(); + assert!(regex.is_match("foo bar")); + } + + #[test] + fn test_collect_dates_from_file() { + let text = "Test1\n\nTest2\nFoo\nTest3\nTest4\nFooBar\n\nTest5\nTest6\nTest7\n\nTest8 + "; + assert_eq!( + collect_dates_from_file(&make_date_regex(), text), + vec![ + ( + 2, + Date { + year: 2021, + month: 1, + } + ), + ( + 4, + Date { + year: 2021, + month: 2, + } + ), + ( + 7, + Date { + year: 2021, + month: 3, + } + ), + ( + 8, + Date { + year: 2021, + month: 4, + } + ), + ( + 14, + Date { + year: 2021, + month: 5, + } + ), + ] + ); + } +} From 5e57035110863f2868f552d6ae3deae3d309374b Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 20 Jan 2021 16:42:10 -0800 Subject: [PATCH 1413/1812] Add lots of date-check annotations Also added dates for things that previously said "as of now" or "as of this writing" and cleaned up a couple of things along the way. --- src/backend/backend-agnostic.md | 5 +++-- .../region_inference/member_constraints.md | 16 +++++++--------- src/compiler-src.md | 11 ++++++----- src/contributing.md | 6 +++++- src/diagnostics.md | 6 +++--- src/diagnostics/lintstore.md | 7 ++++--- src/git.md | 12 ++++++------ src/llvm-coverage-instrumentation.md | 19 +++++++++---------- src/miri.md | 13 +++++++------ src/opaque-types-type-alias-impl-trait.md | 5 +++-- src/overview.md | 12 ++++++------ src/parallel-rustc.md | 11 ++++++----- src/profiling.md | 8 ++++---- src/queries/profiling.md | 4 ++-- .../query-evaluation-model-in-detail.md | 9 +++++---- src/query.md | 17 ++++++++--------- src/rustdoc-internals.md | 2 +- src/salsa.md | 8 ++++---- src/tests/adding.md | 14 +++++++------- src/tests/intro.md | 14 +++++++------- src/the-parser.md | 4 ++-- src/traits/chalk.md | 13 ++++++------- src/traits/resolution.md | 10 +++++----- src/type-inference.md | 4 ++-- 24 files changed, 118 insertions(+), 112 deletions(-) diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md index 52532c258..f61bf62b3 100644 --- a/src/backend/backend-agnostic.md +++ b/src/backend/backend-agnostic.md @@ -2,8 +2,9 @@ -As of January 2021, `rustc_codegen_ssa` provides an abstract interface for all backends to -implement, to allow other codegen backends (e.g. [Cranelift]). +As of January 2021 , `rustc_codegen_ssa` provides an +abstract interface for all backends to implement, to allow other codegen +backends (e.g. [Cranelift]). [Cranelift]: https://github.com/bytecodealliance/wasmtime/tree/HEAD/cranelift diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index fd65acf1a..f64e39461 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -93,15 +93,13 @@ member constraints come in. ## Choices are always lifetime parameters -At present, the "choice" regions from a member constraint are always -lifetime parameters from the current function. As of January 2021, -this falls out from the placement of impl Trait, though in the future -it may not be the case. -We take some advantage of this fact, as it simplifies the current -code. In particular, we don't have to consider a case like `'0 member -of ['1, 'static]`, in which the value of both `'0` and `'1` are being -inferred and hence changing. See [rust-lang/rust#61773][#61773] for more -information. +At present, the "choice" regions from a member constraint are always lifetime +parameters from the current function. As of January 2021 , +this falls out from the placement of impl Trait, though in the future it may not +be the case. We take some advantage of this fact, as it simplifies the current +code. In particular, we don't have to consider a case like `'0 member of ['1, +'static]`, in which the value of both `'0` and `'1` are being inferred and hence +changing. See [rust-lang/rust#61773][#61773] for more information. [#61773]: https://github.com/rust-lang/rust/issues/61773 diff --git a/src/compiler-src.md b/src/compiler-src.md index 9880f9153..96e91fd73 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -7,8 +7,9 @@ > top-level directory has separate directories for the compiler, build-system, > std libs, etc, rather than one huge `src/` directory. > -> As of January 2021, the std libs have been moved to `library/` and the crates -> that make up the `rustc` compiler itself have been moved to `compiler/` +> As of January 2021 , the standard libraries have been +> moved to `library/` and the crates that make up the `rustc` compiler itself +> have been moved to `compiler/`. Now that we have [seen what the compiler does](./overview.md), let's take a look at the structure of the contents of the rust-lang/rust repo. @@ -20,9 +21,9 @@ containing the compiler, the standard libraries (`core`, `alloc`, `std`, `proc_macro`, etc), and `rustdoc`, along with the build system and a bunch of tools and submodules for building a full Rust distribution. -As of this writing, this structure is gradually undergoing some transformation -to make it a bit less monolithic and more approachable, especially to -newcomers. +As of August 2020 , this structure is gradually undergoing +some transformation to make it a bit less monolithic and more approachable, +especially to newcomers. The repository consists of three main directories: diff --git a/src/contributing.md b/src/contributing.md index 83d5e95cb..fbcd2001a 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -410,9 +410,13 @@ Just a few things to keep in mind: Aim to provide a reasonable amount of context, possibly including but not limited to: - A reason for why the data may be out of date other than "change", as change is a constant across the project. - - A date the comment was added, e.g. instead of writing _"Currently, ..."_ consider writing + - The date the comment was added, e.g. instead of writing _"Currently, ..."_ + or _"As of now, ..."_, consider writing _"As of January 2021, ..."_. Try to format the date as ` ` to ease search. + - Additionally, include a machine-readable comment of the form `` (if the current month is January 2021). We have an automated + tool that uses these (in `ci/date-check`). - A link to a relevant WG, tracking issue, `rustc` rustdoc page, or similar, that may provide further explanation for the change process or a way to verify that the information is not outdated. diff --git a/src/diagnostics.md b/src/diagnostics.md index f59844d4c..6a447c00d 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -594,9 +594,9 @@ declare_lint! { } ``` -If you need a combination of options that's not supported by the -`declare_lint!` macro, you can always define your own static with a type of -`&Lint` but this is (as of January 2021) linted against in the compiler tree. +If you need a combination of options that's not supported by the `declare_lint!` +macro, you can always define your own static with a type of `&Lint` but this is +(as of January 2021 ) linted against in the compiler tree. #### Guidelines for creating a future incompatibility lint diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index e088185a7..d6fdd1e34 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -17,9 +17,10 @@ First, we have the lint declarations themselves: this is where the name and defa other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which boils down to a static with type `&rustc_session::lint::Lint`. -As of January 2021, we lint against direct declarations without the use of the macro today -(although this may change in the future, as the macro is somewhat unwieldy to add new fields to, -like all macros by example). +As of January 2021 , we lint against direct declarations +without the use of the macro today (although this may change in the future, as +the macro is somewhat unwieldy to add new fields to, like all macros by +example). Lint declarations don't carry any "state" - they are merely global identifers and descriptions of lints. We assert at runtime that they are not registered twice (by lint name). diff --git a/src/git.md b/src/git.md index 611c47124..69cdba839 100644 --- a/src/git.md +++ b/src/git.md @@ -144,12 +144,12 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ``` -These changes are not changes to files: they are changes to submodules -(more on this [later](#git-submodules)). To get rid of those, run `git submodule update` (or run any -`x.py` command, which will automatically update the submodules). -Note that there is (as of January 2021) a bug if you use worktrees, submodules, and x.py in a commit -hook. -If you run into an error like: +These changes are not changes to files: they are changes to submodules (more on +this [later](#git-submodules)). To get rid of those, run `git submodule update` +(or run any `x.py` command, which will automatically update the submodules). +Note that there is (as of January 2021 ) a bug if you use +worktrees, submodules, and x.py in a commit hook. If you run into an error +like: ``` error: failed to read `/home/joshua/rustc-worktree/src/tools/miri/cargo-miri/Cargo.toml` diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 88831f69d..9a78935e4 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -221,16 +221,15 @@ properly-configured variables in LLVM IR, according to very specific details of the [_LLVM Coverage Mapping Format_][coverage-mapping-format] (Version 4).[^llvm-and-covmap-versions] -[^llvm-and-covmap-versions]: The Rust compiler (as of January 2021) supports -_LLVM Coverage Mapping Format_ Version 4 (the most up-to-date version -of the format, at the time of this writing) for improved compatibility -with other LLVM-based compilers (like _Clang_), and to take advantage -of some format optimizations. Version 4 was introduced in _LLVM 11_, -which is currently the default LLVM version for Rust. Note that the -Rust compiler optionally supports some earlier LLVM versions, -prior to _LLVM 11_. If `rustc` is configured to use an incompatible -version of LLVM, compiling with `-Z instrument-coverage` will -generate an error message. +[^llvm-and-covmap-versions]: The Rust compiler (as of January 2021 ) supports _LLVM Coverage Mapping Format_ Version 4 (the most +up-to-date version of the format, at the time of this writing) for improved +compatibility with other LLVM-based compilers (like _Clang_), and to take +advantage of some format optimizations. Version 4 was introduced in _LLVM 11_, +which is currently the default LLVM version for Rust. Note that the Rust +compiler optionally supports some earlier LLVM versions, prior to _LLVM 11_. If +`rustc` is configured to use an incompatible version of LLVM, compiling with `-Z +instrument-coverage` will generate an error message. ```rust pub fn finalize<'ll, 'tcx>(cx: &CodegenCx<'ll, 'tcx>) { diff --git a/src/miri.md b/src/miri.md index d0766a07b..54f96391a 100644 --- a/src/miri.md +++ b/src/miri.md @@ -193,12 +193,13 @@ concrete integer. However, a variable of pointer or reference *type*, such as `*const T` or `&T`, does not have to have a pointer *value*: it could be obtaining by casting or -transmuting an integer to a pointer (as of January 2021 that is hard to do in const eval, -but eventually `transmute` will be stable as a `const fn`). And similarly, when -casting or transmuting a reference to some actual allocation to an integer, we -end up with a pointer *value* (`Scalar::Ptr`) at integer *type* (`usize`). This -is a problem because we cannot meaningfully perform integer operations such as -division on pointer values. +transmuting an integer to a pointer (as of January 2021 +that is hard to do in const eval, but eventually `transmute` will be stable as a +`const fn`). And similarly, when casting or transmuting a reference to some +actual allocation to an integer, we end up with a pointer *value* +(`Scalar::Ptr`) at integer *type* (`usize`). This is a problem because we +cannot meaningfully perform integer operations such as division on pointer +values. ## Interpretation diff --git a/src/opaque-types-type-alias-impl-trait.md b/src/opaque-types-type-alias-impl-trait.md index e95291fef..53522114d 100644 --- a/src/opaque-types-type-alias-impl-trait.md +++ b/src/opaque-types-type-alias-impl-trait.md @@ -14,8 +14,9 @@ This declares an opaque type named `Foo`, of which the only information is that it implements `Bar`. Therefore, any of `Bar`'s interface can be used on a `Foo`, but nothing else (regardless of whether it implements any other traits). -Since there needs to be a concrete background type, you can (as of January 2021) -express that type by using the opaque type in a "defining use site". +Since there needs to be a concrete background type, you can (as of January 2021 +) express that type by using the opaque type in a +"defining use site". ```rust,ignore struct Struct; diff --git a/src/overview.md b/src/overview.md index 5a63d6066..45ae0ab2e 100644 --- a/src/overview.md +++ b/src/overview.md @@ -247,12 +247,12 @@ to remain to ensure that unreachable functions still have their errors emitted. [passes]: https://github.com/rust-lang/rust/blob/45ebd5808afd3df7ba842797c0fcd4447ddf30fb/src/librustc_interface/passes.rs#L824 Moreover, the compiler wasn't originally built to use a query system; the query -system has been retrofitted into the compiler, so parts of it are not -query-fied yet. Also, LLVM isn't our code, so that isn't querified -either. The plan is to eventually query-fy all of the steps listed in the -previous section, but as of this writing, only the steps between HIR and -LLVM-IR are query-fied. That is, lexing and parsing are done all at once for -the whole program. +system has been retrofitted into the compiler, so parts of it are not query-fied +yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to +eventually query-fy all of the steps listed in the previous section, but as of +April 2020 , only the steps between HIR and LLVM-IR are +query-fied. That is, lexing and parsing are done all at once for the whole +program. One other thing to mention here is the all-important "typing context", [`TyCtxt`], which is a giant struct that is at the center of all things. diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index cb36fef6f..6f7f6f54b 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -3,8 +3,9 @@ Most of the compiler is not parallel. This represents an opportunity for improving compiler performance. -As of January 2021, work on explicitly parallelizing the compiler has stalled. -There is a lot of design and correctness work that needs to be done. +As of January 2021 , work on explicitly parallelizing the +compiler has stalled. There is a lot of design and correctness work that needs +to be done. One can try out the current parallel compiler work by enabling it in the `config.toml`. @@ -21,9 +22,9 @@ There are a few basic ideas in this effort: [`rayon`]: https://crates.io/crates/rayon -As of this writing, much of this effort is on hold due to lack of manpower. We -have a working prototype with promising performance gains in many cases. -However, there are two blockers: +As of May 2020 , much of this effort is on hold due to +lack of manpower. We have a working prototype with promising performance gains +in many cases. However, there are two blockers: - It's not clear what invariants need to be upheld that might not hold in the face of concurrency. An auditing effort was underway, but seems to have diff --git a/src/profiling.md b/src/profiling.md index 902281f18..aa8bf27a2 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -88,7 +88,7 @@ codegen-units = 0 # num_cpus The llvm-lines output is affected by several options. `optimize = false` increases it from 2.1GB to 3.5GB and `codegen-units = 0` to 4.1GB. -MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Z mir-opt-level=1"`, -level 0 adds 0.3GB and level 2 removes 0.2GB. -As of January 2021, inlining currently only happens in LLVM but this might change in the future. - +MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Z +mir-opt-level=1"`, level 0 adds 0.3GB and level 2 removes 0.2GB. As of January +2021 , inlining currently only happens in LLVM but this +might change in the future. diff --git a/src/queries/profiling.md b/src/queries/profiling.md index 8cd4c07d8..d903eabff 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -89,8 +89,8 @@ The trace of the queries has a formal structure; see We style this formal structure as follows: - **Timed passes:** Green boxes, when present (via `-Z time-passes`), represent - _timed passes_ in the compiler. As of January 2021 these passes are not queries, but may be - replaced by queries in future versions. + _timed passes_ in the compiler. As of January 2021 + these passes are not queries, but may be replaced by queries in future versions. - **Labels:** Some green and red boxes are labeled with text. Where they are present, the labels give the following information: - The [query's _provider_](#queries), sans its _key_ and its _result_, which diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 51501d3d5..eb6659420 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -76,10 +76,11 @@ executed, no results are cached. But the context already provides access to "input" data, i.e. pieces of immutable data that were computed before the context was created and that queries can access to do their computations. -As of January 2021, this input data consists mainly of the HIR map, upstream crate metadata, and the -command-line options the compiler was invoked with; but in the future inputs will just consist of -command-line options and a list of source files -- the HIR map will itself be provided by a query -which processes these source files. +As of January 2021 , this input data consists mainly of +the HIR map, upstream crate metadata, and the command-line options the compiler +was invoked with; but in the future inputs will just consist of command-line +options and a list of source files -- the HIR map will itself be provided by a +query which processes these source files. Without inputs, queries would live in a void without anything to compute their result from (remember, query providers only have access to other queries and diff --git a/src/query.md b/src/query.md index eb0bbe78e..b03aaa8b4 100644 --- a/src/query.md +++ b/src/query.md @@ -1,16 +1,15 @@ # Queries: demand-driven compilation -As described in [the high-level overview of the compiler][hl], the -Rust compiler is still (as of January 2021) transitioning from a traditional "pass-based" -setup to a "demand-driven" system. **The Compiler Query System is the -key to our new demand-driven organization.** The idea is pretty -simple. You have various queries that compute things about the input -– for example, there is a query called `type_of(def_id)` that, given -the [def-id] of some item, will compute the type of that item and return -it to you. +As described in [the high-level overview of the compiler][hl], the Rust compiler +is still (as of January 2021 ) transitioning from a +traditional "pass-based" setup to a "demand-driven" system. **The Compiler Query +System is the key to our new demand-driven organization.** The idea is pretty +simple. You have various queries that compute things about the input – for +example, there is a query called `type_of(def_id)` that, given the [def-id] of +some item, will compute the type of that item and return it to you. [def-id]: appendix/glossary.md#def-id -[hl]: compiler-src.html +[hl]: ./compiler-src.md Query execution is **memoized** – so the first time you invoke a query, it will go do the computation, but the next time, the result is diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index 288d762b8..7460c012c 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -66,7 +66,7 @@ these passes, please let us know!) [44136]: https://github.com/rust-lang/rust/issues/44136 -Here is current (as of this writing) list of passes: +Here is the list of passes as of March 2018 : - `propagate-doc-cfg` - propagates `#[doc(cfg(...))]` to child items. - `collapse-docs` concatenates all document attributes into one document diff --git a/src/salsa.md b/src/salsa.md index 38db066c5..67d813b28 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -9,10 +9,10 @@ want to watch [Salsa In More Depth](https://www.youtube.com/watch?v=i_IhACacPRY), also by Niko Matsakis. -> As of January 2021, although Salsa is inspired by (among other things) rustc's query system, -> it is not used directly in rustc. -> It _is_ used in chalk and extensively in `rust-analyzer`, but there are no medium or long-term -> concrete plans to integrate it into the compiler. +> As of January 2021 , although Salsa is inspired by +> (among other things) rustc's query system, it is not used directly in rustc. +> It _is_ used in chalk and extensively in `rust-analyzer`, but there are no +> medium or long-term concrete plans to integrate it into the compiler. ## What is Salsa? diff --git a/src/tests/adding.md b/src/tests/adding.md index 868bad2d7..c19271d2c 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -333,17 +333,17 @@ The error levels that you can have are: 1. `ERROR` 2. `WARNING` 3. `NOTE` -4. `HELP` and `SUGGESTION`* +4. `HELP` and `SUGGESTION`[^sugg-placement] -\* **Note**: `SUGGESTION` must follow immediately after `HELP`. +[^sugg-placement]: **Note**: `SUGGESTION` must follow immediately after `HELP`. ## Revisions -Certain classes of tests support "revisions" (as of the time of this -writing, this includes compile-fail, run-fail, and -incremental, though incremental tests are somewhat -different). Revisions allow a single test file to be used for multiple -tests. This is done by adding a special header at the top of the file: +Certain classes of tests support "revisions" (as of February 2018 , this includes compile-fail, run-fail, and incremental, though +incremental tests are somewhat different). Revisions allow a single test file to +be used for multiple tests. This is done by adding a special header at the top +of the file: ```rust // revisions: foo bar baz diff --git a/src/tests/intro.md b/src/tests/intro.md index 55be23cd6..6b2f9452f 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -124,13 +124,13 @@ launch a build that will run all tests on some configurations (x86_64-gnu-llvm-8 linux. x86_64-gnu-tools linux, mingw-check linux). In essence, it runs `./x.py test` after building for each of them. -The integration bot [bors] is used for coordinating merges to the master -branch. When a PR is approved, it goes into a [queue] where merges are tested -one at a time on a wide set of platforms using GitHub Actions (as of January 2021 over -50 different configurations). Due to the limit on the number of parallel jobs, -we run CI under the [rust-lang-ci] organization except for PRs. -Most platforms only run the build steps, some run a restricted set of tests, -only a subset run the full suite of tests (see Rust's [platform tiers]). +The integration bot [bors] is used for coordinating merges to the master branch. +When a PR is approved, it goes into a [queue] where merges are tested one at a +time on a wide set of platforms using GitHub Actions (as of January 2021 , over 50 different configurations). Due to the limit on the +number of parallel jobs, we run CI under the [rust-lang-ci] organization except +for PRs. Most platforms only run the build steps, some run a restricted set of +tests, only a subset run the full suite of tests (see Rust's [platform tiers]). [GitHub Actions]: https://github.com/rust-lang/rust/actions [rust-lang-ci]: https://github.com/rust-lang-ci/rust/actions diff --git a/src/the-parser.md b/src/the-parser.md index 915e4bb9a..9c3433884 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -1,7 +1,7 @@ # Lexing and Parsing -As of January 2021, the lexer and parser are undergoing refactoring to allow -extracting them into libraries. +As of January 2021 , the lexer and parser are undergoing +refactoring to allow extracting them into libraries. The very first thing the compiler does is take the program (in Unicode characters) and turn it into something the compiler can work with more diff --git a/src/traits/chalk.md b/src/traits/chalk.md index 540077cf0..8b2e20304 100644 --- a/src/traits/chalk.md +++ b/src/traits/chalk.md @@ -1,12 +1,11 @@ # Chalk-based trait solving -[Chalk][chalk] is an experimental trait solver for rust that is (as of January 2021) -under development by the [Traits Working Group][wg]. Its goal is -to enable a lot of trait system features and bug fixes that are -hard to implement (e.g. GATs or specialization). If you -would like to help in hacking on the new solver, you will find -instructions for getting involved in the -[Traits Working Group tracking issue][wg]. +[Chalk][chalk] is an experimental trait solver for Rust that is (as of January +2021 ) under development by the [Traits Working +Group][wg]. Its goal is to enable a lot of trait system features and bug fixes +that are hard to implement (e.g. GATs or specialization). If you would like to +help in hacking on the new solver, you will find instructions for getting +involved in the [Traits Working Group tracking issue][wg]. [wg]: https://github.com/rust-lang/rust/issues/48416 diff --git a/src/traits/resolution.md b/src/traits/resolution.md index 863631320..f2ffdcc97 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -118,11 +118,11 @@ candidate that is definitively applicable. In some cases, we may not know whether an impl/where-clause applies or not – this occurs when the obligation contains unbound inference variables. -The subroutines that decide whether a particular impl/where-clause/etc -applies to a particular obligation are collectively referred to as the -process of _matching_. As of January 2021, this amounts to -unifying the `Self` types, but in the future we may also recursively -consider some of the nested obligations, in the case of an impl. +The subroutines that decide whether a particular impl/where-clause/etc applies +to a particular obligation are collectively referred to as the process of +_matching_. As of January 2021 , this amounts to unifying +the `Self` types, but in the future we may also recursively consider some of the +nested obligations, in the case of an impl. **TODO**: what does "unifying the `Self` types" mean? The `Self` of the obligation with that of an impl? diff --git a/src/type-inference.md b/src/type-inference.md index 9d23b6278..6496b48ff 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -71,8 +71,8 @@ inference works, or perhaps this blog post on [Unification in the Chalk project]: http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/ -All told, the inference context stores four kinds of inference variables as of -this writing: +All told, the inference context stores four kinds of inference variables (as of +January 2018 ): - Type variables, which come in three varieties: - General type variables (the most common). These can be unified with any From be872c1ce3dfb0d23143b87e62d3492edce9d051 Mon Sep 17 00:00:00 2001 From: Santiago Pastorino Date: Thu, 4 Feb 2021 10:35:34 -0300 Subject: [PATCH 1414/1812] Make check-in.sh output in way that suggest to add only the most relevant info --- ci/check-in.sh | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/ci/check-in.sh b/ci/check-in.sh index ef61b6871..323b75d67 100755 --- a/ci/check-in.sh +++ b/ci/check-in.sh @@ -24,15 +24,11 @@ show_pulls() { jq -r '.[] | { title, number, html_url, user: .user.login } | "- " + .title + " [#" + (.number | tostring) + "](" + .html_url + ")"' } -echo "### Authors" -jq -r '{ login: .[].user.login } | "- **@" + .login + "**"' < pulls.json \ - | sort -u -echo -echo "### Changes" +echo "### Most notable changes" echo show_pulls < pulls.json echo -echo "### Changes in progress" +echo "### Most notable WIPs" echo # If there are more than 30 PRs open at a time, you'll need to set `per_page`. # For now this seems unlikely. From 95c3930c67504118b076361ed2fee73f89d0e72a Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 4 Feb 2021 08:34:52 -0800 Subject: [PATCH 1415/1812] Add chapter on libs and metadata. (#1044) --- src/SUMMARY.md | 1 + src/backend/libs-and-metadata.md | 192 +++++++++++++++++++++++++++++++ 2 files changed, 193 insertions(+) create mode 100644 src/backend/libs-and-metadata.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 392b3814e..02e8e3843 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -145,6 +145,7 @@ - [Debugging LLVM](./backend/debugging.md) - [Backend Agnostic Codegen](./backend/backend-agnostic.md) - [Implicit Caller Location](./backend/implicit-caller-location.md) +- [Libraries and Metadata](./backend/libs-and-metadata.md) - [Profile-guided Optimization](./profile-guided-optimization.md) - [LLVM Source-Based Code Coverage](./llvm-coverage-instrumentation.md) - [Sanitizers Support](./sanitizers.md) diff --git a/src/backend/libs-and-metadata.md b/src/backend/libs-and-metadata.md new file mode 100644 index 000000000..91d8cb3aa --- /dev/null +++ b/src/backend/libs-and-metadata.md @@ -0,0 +1,192 @@ +# Libraries and Metadata + +When the compiler sees a reference to an external crate, it needs to load some +information about that crate. This chapter gives an overview of that process, +and the supported file formats for crate libraries. + +## Libraries + +A crate dependency can be loaded from an `rlib`, `dylib`, or `rmeta` file. A +key point of these file formats is that they contain `rustc`-specific +[*metadata*](#metadata). This metadata allows the compiler to discover enough +information about the external crate to understand the items it contains, +which macros it exports, and *much* more. + +### rlib + +An `rlib` is an [archive file], which is similar to a tar file. This file +format is specific to `rustc`, and may change over time. This file contains: + +* Object code, which is the result of code generation. This is used during + regular linking. There is a separate `.o` file for each [codegen unit]. The + codegen step can be skipped with the [`-C + linker-plugin-lto`][linker-plugin-lto] CLI option, which means each `.o` + file will only contain LLVM bitcode. +* [LLVM bitcode], which is a binary representation of LLVM's intermediate + representation, which is embedded as a section in the `.o` files. This can + be used for [Link Time Optimization] (LTO). This can be removed with the + [`-C embed-bitcode=no`][embed-bitcode] CLI option to improve compile times + and reduce disk space if LTO is not needed. +* `rustc` [metadata], in a file named `lib.rmeta`. +* A symbol table, which is generally a list of symbols with offsets to the + object file that contain that symbol. This is pretty standard for archive + files. + +[archive file]: https://en.wikipedia.org/wiki/Ar_(Unix) +[LLVM bitcode]: https://llvm.org/docs/BitCodeFormat.html +[Link Time Optimization]: https://llvm.org/docs/LinkTimeOptimization.html +[codegen unit]: ../backend/codegen.md +[embed-bitcode]: https://doc.rust-lang.org/rustc/codegen-options/index.html#embed-bitcode +[linker-plugin-lto]: https://doc.rust-lang.org/rustc/codegen-options/index.html#linker-plugin-lto + +### dylib + +A `dylib` is a platform-specific shared library. It includes the `rustc` +[metadata] in a special link section called `.rustc` in a compressed format. + +### rmeta + +An `rmeta` file is custom binary format that contains the [metadata] for the +crate. This file can be used for fast "checks" of a project by skipping all +code generation (as is done with `cargo check`), collecting enough information +for documentation (as is done with `cargo doc`), or for +[pipelining](#pipelining). This file is created if the +[`--emit=metadata`][emit] CLI option is used. + +`rmeta` files do not support linking, since they do not contain compiled +object files. + +[emit]: https://doc.rust-lang.org/rustc/command-line-arguments.html#option-emit + +## Metadata + +The metadata contains a wide swath of different elements. This guide will not +go into detail of every field it contains. You are encouraged to browse the +[`CrateRoot`] definition to get a sense of the different elements it contains. +Everything about metadata encoding and decoding is in the [`rustc_metadata`] +package. + +Here are a few highlights of things it contains: + +* The version of the `rustc` compiler. The compiler will refuse to load files + from any other version. +* The [Strict Version Hash](#strict-version-hash) (SVH). This helps ensure the + correct dependency is loaded. +* The [Crate Disambiguator](#crate-disambiguator). This is a hash used + to disambiguate between different crates of the same name. +* Information about all the source files in the library. This can be used for + a variety of things, such as diagnostics pointing to sources in a + dependency. +* Information about exported macros, traits, types, and items. Generally, + anything that's needed to be known when a path references something inside a + crate dependency. +* Encoded [MIR]. This is optional, and only encoded if needed for code + generation. `cargo check` skips this for performance reasons. + +[`CrateRoot`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/struct.CrateRoot.html +[`rustc_metadata`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html +[MIR]: ../mir/index.md + +### Strict Version Hash + +The Strict Version Hash ([SVH], also known as the "crate hash") is a 64-bit +hash that is used to ensure that the correct crate dependencies are loaded. It +is possible for a directory to contain multiple copies of the same dependency +built with different settings, or built from different sources. The crate +loader will skip any crates that have the wrong SVH. + +The SVH is also used for the [incremental compilation] session filename, +though that usage is mostly historic. + +The hash includes a variety of elements: + +* Hashes of the HIR nodes. +* All of the upstream crate hashes. +* All of the source filenames. +* Hashes of certain command-line flags (like `-C metadata` via the [Crate + Disambiguator](#crate-disambiguator), and all CLI options marked with + `[TRACKED]`). + +See [`finalize_and_compute_crate_hash`] for where the hash is actually +computed. + +[SVH]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/svh/struct.Svh.html +[incremental compilation]: ../queries/incremental-compilation.md +[`finalize_and_compute_crate_hash`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/collector/struct.NodeCollector.html#method.finalize_and_compute_crate_hash + +### Crate Disambiguator + +The [`CrateDisambiguator`] is a 128-bit hash used to distinguish between +different crates of the same name. It is a hash of all the [`-C metadata`] CLI +options computed in [`compute_crate_disambiguator`]. It is used in a variety +of places, such as symbol name mangling, crate loading, and much more. + +By default, all Rust symbols are mangled and incorporate the disambiguator +hash. This allows multiple versions of the same crate to be included together. +Cargo automatically generates `-C metadata` hashes based on a variety of +factors, like the package version, source, and the target kind (a lib and bin +can have the same crate name, so they need to be disambiguated). + +[`CrateDisambiguator`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/crate_disambiguator/struct.CrateDisambiguator.html +[`compute_crate_disambiguator`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/util/fn.compute_crate_disambiguator.html +[`-C metadata`]: https://doc.rust-lang.org/rustc/codegen-options/index.html#metadata + +## Crate loading + +Crate loading can have quite a few subtle complexities. During [name +resolution], when an external crate is referenced (via an `extern crate` or +path), the resolver uses the [`CrateLoader`] which is responsible for finding +the crate libraries and loading the [metadata] for them. After the dependency +is loaded, the `CrateLoader` will provide the information the resolver needs +to perform its job (such as expanding macros, resolving paths, etc.). + +To load each external crate, the `CrateLoader` uses a [`CrateLocator`] to +actually find the correct files for one specific crate. There is some great +documentation in the [`locator`] module that goes into detail on how loading +works, and I strongly suggest reading it to get the full picture. + +The location of a dependency can come from several different places. Direct +dependencies are usually passed with `--extern` flags, and the loader can look +at those directly. Direct dependencies often have references to their own +dependencies, which need to be loaded, too. These are usually found by +scanning the directories passed with the `-L` flag for any file whose metadata +contains a matching crate name and [SVH](#strict-version-hash). The loader +will also look at the [sysroot] to find dependencies. + +As crates are loaded, they are kept in the [`CStore`] with the crate metadata +wrapped in the [`CrateMetadata`] struct. After resolution and expansion, the +`CStore` will make its way into the [`GlobalCtxt`] for the rest of +compilation. + +[name resolution]: ../name-resolution.md +[`CrateLoader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/creader/struct.CrateLoader.html +[`CrateLocator`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/locator/struct.CrateLocator.html +[`locator`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/locator/index.html +[`CStore`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/creader/struct.CStore.html +[`CrateMetadata`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/decoder/struct.CrateMetadata.html +[`GlobalCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.GlobalCtxt.html +[sysroot]: ../building/bootstrapping.md#what-is-a-sysroot + +## Pipelining + +One trick to improve compile times is to start building a crate as soon as the +metadata for its dependencies is available. For a library, there is no need to +wait for the code generation of dependencies to finish. Cargo implements this +technique by telling `rustc` to emit an [`rmeta`](#rmeta) file for each +dependency as well as an [`rlib`](#rlib). As early as it can, `rustc` will +save the `rmeta` file to disk before it continues to the code generation +phase. The compiler sends a JSON message to let the build tool know that it +can start building the next crate if possible. + +The [crate loading](#crate-loading) system is smart enough to know when it +sees an `rmeta` file to use that if the `rlib` is not there (or has only been +partially written). + +This pipelining isn't possible for binaries, because the linking phase will +require the code generation of all its dependencies. In the future, it may be +possible to further improve this scenario by splitting linking into a separate +command (see [#64191]). + +[#64191]: https://github.com/rust-lang/rust/issues/64191 + +[metadata]: #metadata From 219813a75c77a3f9076e05aae1772e24c0e796df Mon Sep 17 00:00:00 2001 From: Yusuke Tanaka Date: Mon, 8 Feb 2021 01:15:54 +0900 Subject: [PATCH 1416/1812] Fix typo in Bug Fix Procedure (#1050) --- src/bug-fix-procedure.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md index 66b200f9e..8702f8aa9 100644 --- a/src/bug-fix-procedure.md +++ b/src/bug-fix-procedure.md @@ -252,12 +252,12 @@ declare_lint! { This `declare_lint!` macro creates the relevant data structures. Remove it. You will also find that there is a mention of `OVERLAPPING_INHERENT_IMPLS` later in -the file as [part of a `lint_array!`][lintarraysource]; remove it too, +the file as [part of a `lint_array!`][lintarraysource]; remove it too. [lintarraysource]: https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L252-L290 -Next, you see see [a reference to `OVERLAPPING_INHERENT_IMPLS` in -`rustc_lint/src/lib.rs`][futuresource]. This defining the lint as a "future +Next, you see [a reference to `OVERLAPPING_INHERENT_IMPLS` in +`rustc_lint/src/lib.rs`][futuresource]. This is defining the lint as a "future compatibility lint": ```rust From f525bc8071feb8c07972e3e999586f60ba7d7fa3 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 7 Feb 2021 19:07:48 -0800 Subject: [PATCH 1417/1812] Fix typo --- src/compiler-debugging.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index ecb9e30c2..34f5e760f 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -34,7 +34,7 @@ could be useful for debugging. When you have an ICE (panic in the compiler), you can set `RUST_BACKTRACE=1` to get the stack trace of the `panic!` like in -normal Rust programs. IIRC backtraces **don't work** on MinGW, +normal Rust programs. IIRC backtraces **don't work** on MinGW, sorry. If you have trouble or the backtraces are full of `unknown`, you might want to find some way to use Linux, Mac, or MSVC on Windows. @@ -82,7 +82,7 @@ stack backtrace: If you want to get a backtrace to the point where the compiler emits an error message, you can pass the `-Z treat-err-as-bug=n`, which will make -the compiler panic on the `nth` error on `delay_span_bug.` If you leave +the compiler panic on the `nth` error on `delay_span_bug`. If you leave off `=n`, the compiler will assume `1` for `n` and thus panic on the first error it encounters. From 3708c8227a613b9245b2275e588004e029da4868 Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Mon, 15 Feb 2021 00:50:08 -0800 Subject: [PATCH 1418/1812] Add Oxide paper to bibliography --- src/appendix/bibliography.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/bibliography.md b/src/appendix/bibliography.md index b5defaefd..c8b4a23b3 100644 --- a/src/appendix/bibliography.md +++ b/src/appendix/bibliography.md @@ -88,3 +88,4 @@ Rust, as well as publications about Rust. * [Writing parsers like it is 2017](http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf) Pierre Chifflier and Geoffroy Couprie for the Langsec Workshop * [The Case for Writing a Kernel in Rust](https://www.tockos.org/assets/papers/rust-kernel-apsys2017.pdf) * [RustBelt: Securing the Foundations of the Rust Programming Language](https://plv.mpi-sws.org/rustbelt/popl18/) +* [Oxide: The Essence of Rust](https://arxiv.org/abs/1903.00982). By Aaron Weiss, Olek Gierczak, Daniel Patterson, Nicholas D. Matsakis, and Amal Ahmed. From 5b2ef08416c1b279035f85042709c266d4c378ee Mon Sep 17 00:00:00 2001 From: bstrie <865233+bstrie@users.noreply.github.com> Date: Wed, 17 Feb 2021 17:10:04 -0500 Subject: [PATCH 1419/1812] Update running.md --- src/tests/running.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index 842a73c07..874ef8274 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -36,10 +36,10 @@ modifying rustc to see if things are generally working correctly would be the following: ```bash -./x.py test src/test/{ui,compile-fail} +./x.py test src/test/ui ``` -This will run the `ui` and `compile-fail` test suites. Of course, the choice +This will run the `ui` test suite. Of course, the choice of test suites is somewhat arbitrary, and may not suit the task you are doing. For example, if you are hacking on debuginfo, you may be better off with the debuginfo test suite: From 42a531c1eb308b97e86d963e5ed32308feef38b0 Mon Sep 17 00:00:00 2001 From: dmezh <54985569+dmezh@users.noreply.github.com> Date: Thu, 18 Feb 2021 13:37:43 -0500 Subject: [PATCH 1420/1812] Fix typo (#1063) --- src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 68c4b1ad0..61537dbf8 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -269,7 +269,7 @@ that use diagnostic items. This happens very rarely. ### What is a 'sysroot'? -When you build a project with cargo, the build artifacts for dependendencies +When you build a project with cargo, the build artifacts for dependencies are normally stored in `target/debug/deps`. This only contains dependencies cargo knows about; in particular, it doesn't have the standard library. Where do `std` or `proc_macro` come from? It comes from the **sysroot**, the root From fba44ed2fae70453845b48c994c24a0264ba88c1 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 20 Feb 2021 10:01:54 +0900 Subject: [PATCH 1421/1812] Point to main branch on llvm-project's links --- src/llvm-coverage-instrumentation.md | 2 +- src/profile-guided-optimization.md | 2 +- src/sanitizers.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 9a78935e4..132de7173 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -65,7 +65,7 @@ When compiling with `-Z instrument-coverage`, [`CrateLoader::postprocess()`][crate-loader-postprocess] dynamically loads the `profiler_builtins` library by calling `inject_profiler_runtime()`. -[compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/master/compiler-rt/lib/profile +[compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/profile [crate-loader-postprocess]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/creader/struct.CrateLoader.html#method.postprocess ### MIR Pass: `InstrumentCoverage` diff --git a/src/profile-guided-optimization.md b/src/profile-guided-optimization.md index 145bb053c..bf7615878 100644 --- a/src/profile-guided-optimization.md +++ b/src/profile-guided-optimization.md @@ -122,7 +122,7 @@ basically packs the C code from `compiler-rt` into a Rust crate. In order for `profiler_builtins` to be built, `profiler = true` must be set in `rustc`'s `config.toml`. -[compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/master/compiler-rt/lib/profile +[compiler-rt-profile]: https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/profile ## Testing PGO diff --git a/src/sanitizers.md b/src/sanitizers.md index 4a43698ca..ce0714034 100644 --- a/src/sanitizers.md +++ b/src/sanitizers.md @@ -51,7 +51,7 @@ libraries. Highlight of the most important aspects of the implementation: relative to default system root, so that this process is not affected by sysroot overrides used for example by cargo `-Z build-std` functionality. -[compiler-rt]: https://github.com/llvm/llvm-project/tree/master/compiler-rt +[compiler-rt]: https://github.com/llvm/llvm-project/tree/main/compiler-rt [sanitizer-build]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/bootstrap/native.rs#L566-L624 [sanitizer-copy]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/bootstrap/compile.rs#L270-L304 [sanitizer-attribute]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/librustc_codegen_llvm/attributes.rs#L49-L72 From f5eea60da72d70f6eca5d23c0f38772add28048c Mon Sep 17 00:00:00 2001 From: r00ster Date: Sat, 20 Feb 2021 13:58:22 +0100 Subject: [PATCH 1422/1812] Make "URL" show up (#1065) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Make "URL" show up * Use `` Co-authored-by: Léo Lanteri Thauvin --- src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/git.md b/src/git.md index 69cdba839..d23cd3f0d 100644 --- a/src/git.md +++ b/src/git.md @@ -101,7 +101,7 @@ If you renamed your fork, you can change the URL like this: git remote set-url personal ``` -where the is your new fork. +where the `` is your new fork. ### I see 'Untracked Files: src/stdarch'? From 5297659bb16940faa1ce787f22ac3556fdca64d3 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 20 Feb 2021 19:24:01 -0800 Subject: [PATCH 1423/1812] Fix date-check comment formatting (#1066) I realized that the format I had been previously using for date-checks (as of January 2021 ) left a space before the closing parenthesis in the rendered output, which looks weird. I could fix this by removing the space between `2021` and ` January 2021) --- src/diagnostics.md | 2 +- src/git.md | 2 +- src/llvm-coverage-instrumentation.md | 4 ++-- src/opaque-types-type-alias-impl-trait.md | 4 ++-- src/query.md | 2 +- src/traits/chalk.md | 4 ++-- src/type-inference.md | 2 +- 7 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 6a447c00d..f4e71bbdc 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -596,7 +596,7 @@ declare_lint! { If you need a combination of options that's not supported by the `declare_lint!` macro, you can always define your own static with a type of `&Lint` but this is -(as of January 2021 ) linted against in the compiler tree. +(as of January 2021) linted against in the compiler tree. #### Guidelines for creating a future incompatibility lint diff --git a/src/git.md b/src/git.md index d23cd3f0d..d90619948 100644 --- a/src/git.md +++ b/src/git.md @@ -147,7 +147,7 @@ no changes added to commit (use "git add" and/or "git commit -a") These changes are not changes to files: they are changes to submodules (more on this [later](#git-submodules)). To get rid of those, run `git submodule update` (or run any `x.py` command, which will automatically update the submodules). -Note that there is (as of January 2021 ) a bug if you use +Note that there is (as of January 2021) a bug if you use worktrees, submodules, and x.py in a commit hook. If you run into an error like: diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 132de7173..8a044849f 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -221,8 +221,8 @@ properly-configured variables in LLVM IR, according to very specific details of the [_LLVM Coverage Mapping Format_][coverage-mapping-format] (Version 4).[^llvm-and-covmap-versions] -[^llvm-and-covmap-versions]: The Rust compiler (as of January 2021 ) supports _LLVM Coverage Mapping Format_ Version 4 (the most +[^llvm-and-covmap-versions]: The Rust compiler (as of +January 2021) supports _LLVM Coverage Mapping Format_ Version 4 (the most up-to-date version of the format, at the time of this writing) for improved compatibility with other LLVM-based compilers (like _Clang_), and to take advantage of some format optimizations. Version 4 was introduced in _LLVM 11_, diff --git a/src/opaque-types-type-alias-impl-trait.md b/src/opaque-types-type-alias-impl-trait.md index 53522114d..2be072dd2 100644 --- a/src/opaque-types-type-alias-impl-trait.md +++ b/src/opaque-types-type-alias-impl-trait.md @@ -14,8 +14,8 @@ This declares an opaque type named `Foo`, of which the only information is that it implements `Bar`. Therefore, any of `Bar`'s interface can be used on a `Foo`, but nothing else (regardless of whether it implements any other traits). -Since there needs to be a concrete background type, you can (as of January 2021 -) express that type by using the opaque type in a +Since there needs to be a concrete background type, you can (as of January 2021) express that type by using the opaque type in a "defining use site". ```rust,ignore diff --git a/src/query.md b/src/query.md index b03aaa8b4..9f56283db 100644 --- a/src/query.md +++ b/src/query.md @@ -1,7 +1,7 @@ # Queries: demand-driven compilation As described in [the high-level overview of the compiler][hl], the Rust compiler -is still (as of January 2021 ) transitioning from a +is still (as of January 2021) transitioning from a traditional "pass-based" setup to a "demand-driven" system. **The Compiler Query System is the key to our new demand-driven organization.** The idea is pretty simple. You have various queries that compute things about the input – for diff --git a/src/traits/chalk.md b/src/traits/chalk.md index 8b2e20304..24f2d749a 100644 --- a/src/traits/chalk.md +++ b/src/traits/chalk.md @@ -1,7 +1,7 @@ # Chalk-based trait solving -[Chalk][chalk] is an experimental trait solver for Rust that is (as of January -2021 ) under development by the [Traits Working +[Chalk][chalk] is an experimental trait solver for Rust that is (as of January 2021) under development by the [Traits Working Group][wg]. Its goal is to enable a lot of trait system features and bug fixes that are hard to implement (e.g. GATs or specialization). If you would like to help in hacking on the new solver, you will find instructions for getting diff --git a/src/type-inference.md b/src/type-inference.md index 6496b48ff..7674fdf5a 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -72,7 +72,7 @@ inference works, or perhaps this blog post on [Unification in the Chalk project]: http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/ All told, the inference context stores four kinds of inference variables (as of -January 2018 ): + January 2018): - Type variables, which come in three varieties: - General type variables (the most common). These can be unified with any From c4c0f33a1d1bfad621b15b9dd797d0ed25d70ac1 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 20 Feb 2021 19:27:24 -0800 Subject: [PATCH 1424/1812] Update docs from date triage for 2021-02 (#1048) The biggest change was updating the list of rustdoc passes. Several new ones have been added since that documentation was written, so I added those, and I also sorted the list so it is roughly alphabetical (except for the part for the `strip-*` passes, which I left in the same order since one of the list items has two passes so there's no "correct" order). --- src/compiler-src.md | 4 --- src/overview.md | 6 ++-- src/parallel-rustc.md | 6 ++-- src/rustdoc-internals.md | 60 ++++++++++++++++++++++++++++++++-------- src/tests/adding.md | 4 +-- 5 files changed, 56 insertions(+), 24 deletions(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index 96e91fd73..c4f415441 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -21,10 +21,6 @@ containing the compiler, the standard libraries (`core`, `alloc`, `std`, `proc_macro`, etc), and `rustdoc`, along with the build system and a bunch of tools and submodules for building a full Rust distribution. -As of August 2020 , this structure is gradually undergoing -some transformation to make it a bit less monolithic and more approachable, -especially to newcomers. - The repository consists of three main directories: - `compiler/` contains the source code for `rustc`. It consists of many crates diff --git a/src/overview.md b/src/overview.md index 45ae0ab2e..c34d01dfd 100644 --- a/src/overview.md +++ b/src/overview.md @@ -250,9 +250,9 @@ Moreover, the compiler wasn't originally built to use a query system; the query system has been retrofitted into the compiler, so parts of it are not query-fied yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to eventually query-fy all of the steps listed in the previous section, but as of -April 2020 , only the steps between HIR and LLVM-IR are -query-fied. That is, lexing and parsing are done all at once for the whole -program. +February 2021 , only the steps between HIR and LLVM IR are +query-fied. That is, lexing, parsing, name resolution, and macro expansion are +done all at once for the whole program. One other thing to mention here is the all-important "typing context", [`TyCtxt`], which is a giant struct that is at the center of all things. diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 6f7f6f54b..c47a46e78 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -22,9 +22,9 @@ There are a few basic ideas in this effort: [`rayon`]: https://crates.io/crates/rayon -As of May 2020 , much of this effort is on hold due to -lack of manpower. We have a working prototype with promising performance gains -in many cases. However, there are two blockers: +As of February 2021 , much of this effort is on hold due +to lack of manpower. We have a working prototype with promising performance +gains in many cases. However, there are two blockers: - It's not clear what invariants need to be upheld that might not hold in the face of concurrency. An auditing effort was underway, but seems to have diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index 7460c012c..f7799f967 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -51,14 +51,14 @@ which describe the publicly-documentable items in the target crate. ### Hot potato Before moving on to the next major step, a few important "passes" occur over -the documentation. These do things like combine the separate "attributes" into +the documentation. These do things like combine the separate "attributes" into a single string and strip leading whitespace to make the document easier on the markdown parser, or drop items that are not public or deliberately hidden with `#[doc(hidden)]`. These are all implemented in the `passes/` directory, one file per pass. By default, all of these passes are run on a crate, but the ones regarding dropping private/hidden items can be bypassed by passing `--document-private-items` to rustdoc. Note that unlike the previous set of AST -transformations, the passes happen on the _cleaned_ crate. +transformations, the passes are run on the _cleaned_ crate. (Strictly speaking, you can fine-tune the passes run and even add your own, but [we're trying to deprecate that][44136]. If you need finer-grain control over @@ -66,29 +66,66 @@ these passes, please let us know!) [44136]: https://github.com/rust-lang/rust/issues/44136 -Here is the list of passes as of March 2018 : +Here is the list of passes as of February 2021 : + +- `calculate-doc-coverage` calculates information used for the `--show-coverage` + flag. + +- `check-code-block-syntax` validates syntax inside Rust code blocks + (`` ```rust ``) + +- `check-invalid-html-tags` detects invalid HTML (like an unclosed ``) + in doc comments. + +- `check-non-autolinks` detects links that could or should be written using + angle brackets (the code behind the nightly-only + `non_autolinks` lint). -- `propagate-doc-cfg` - propagates `#[doc(cfg(...))]` to child items. - `collapse-docs` concatenates all document attributes into one document attribute. This is necessary because each line of a doc comment is given as a separate doc attribute, and this will combine them into a single string with line breaks between each attribute. -- `unindent-comments` removes excess indentation on comments in order for - markdown to like it. This is necessary because the convention for writing - documentation is to provide a space between the `///` or `//!` marker and the - text, and stripping that leading space will make the text easier to parse by - the Markdown parser. (In the past, the markdown parser used was not - Commonmark- compliant, which caused annoyances with extra whitespace but this - seems to be less of an issue today.) + +- `collect-intra-doc-links` resolves [intra-doc links](https://doc.rust-lang.org/rustdoc/linking-to-items-by-name.html). + +- `collect-trait-impls` collects trait impls for each item in the crate. For + example, if we define a struct that implements a trait, this pass will note + that the struct implements that trait. + +- `doc-test-lints` runs various lints on the doctests. + +- `propagate-doc-cfg` propagates `#[doc(cfg(...))]` to child items. + - `strip-priv-imports` strips all private import statements (`use`, `extern crate`) from a crate. This is necessary because rustdoc will handle *public* imports by either inlining the item's documentation to the module or creating a "Reexports" section with the import in it. The pass ensures that all of these imports are actually relevant to documentation. + - `strip-hidden` and `strip-private` strip all `doc(hidden)` and private items from the output. `strip-private` implies `strip-priv-imports`. Basically, the goal is to remove items that are not relevant for public documentation. +- `unindent-comments` removes excess indentation on comments in order for the + Markdown to be parsed correctly. This is necessary because the convention for + writing documentation is to provide a space between the `///` or `//!` marker + and the doc text, but Markdown is whitespace-sensitive. For example, a block + of text with four-space indentation is parsed as a code block, so if we didn't + unindent comments, these list items + + ```rust,ignore + /// A list: + /// + /// - Foo + /// - Bar + ``` + + would be parsed as if they were in a code block, which is likely not what the + user intended. + +There is also a `stripper` module in `passes/`, but it is a collection of +utility functions for the `strip-*` passes and is not a pass itself. + ## From clean to crate This is where the "second phase" in rustdoc begins. This phase primarily lives @@ -224,4 +261,3 @@ on the internet. For example, the url for `std` will be `/std/". [`rustdoc` api docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/ [The rustdoc user guide]: https://doc.rust-lang.org/nightly/rustdoc/ - diff --git a/src/tests/adding.md b/src/tests/adding.md index c19271d2c..465317672 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -339,8 +339,8 @@ The error levels that you can have are: ## Revisions -Certain classes of tests support "revisions" (as of February 2018 , this includes compile-fail, run-fail, and incremental, though +Certain classes of tests support "revisions" (as of February 2021 , this includes compile-fail, run-fail, and incremental, though incremental tests are somewhat different). Revisions allow a single test file to be used for multiple tests. This is done by adding a special header at the top of the file: From c0e7305d33498a7afb48008772f767bf3a75877d Mon Sep 17 00:00:00 2001 From: Hirochika Matsumoto Date: Sun, 21 Feb 2021 17:51:34 +0900 Subject: [PATCH 1425/1812] Fix broken links in query.md (#1068) --- src/query.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/query.md b/src/query.md index 9f56283db..294d61fb3 100644 --- a/src/query.md +++ b/src/query.md @@ -223,7 +223,7 @@ Let's go over them one by one: - **Query modifiers:** various flags and options that customize how the query is processed (mostly with respect to [incremental compilation][incrcomp]). -[Key]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/keys/trait.Key.html +[Key]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_query_impl/keys/trait.Key.html [incrcomp]: queries/incremental-compilation-in-detail.html#query-modifiers So, to add a query: @@ -262,7 +262,7 @@ Implementing this trait is optional if the query key is `DefId`, but if you *don't* implement it, you get a pretty generic error ("processing `foo`..."). You can put new impls into the `config` module. They look something like this: -[QueryConfig]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/trait.QueryConfig.html +[QueryConfig]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_query_system/query/config/trait.QueryConfig.html [QueryDescription]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_query_system/query/config/trait.QueryDescription.html ```rust,ignore From 9214d4a8c39a348fc3df056a93f425d72661de8c Mon Sep 17 00:00:00 2001 From: Camelid Date: Mon, 22 Feb 2021 01:22:23 -0800 Subject: [PATCH 1426/1812] Fix formatting of more date references (#1067) --- src/backend/backend-agnostic.md | 2 +- .../region_inference/member_constraints.md | 4 ++-- src/compiler-src.md | 2 +- src/contributing.md | 11 +++++++++++ src/diagnostics/lintstore.md | 2 +- src/miri.md | 2 +- src/overview.md | 8 ++++---- src/parallel-rustc.md | 4 ++-- src/profiling.md | 6 +++--- src/queries/profiling.md | 2 +- src/queries/query-evaluation-model-in-detail.md | 2 +- src/rustdoc-internals.md | 2 +- src/salsa.md | 2 +- src/tests/adding.md | 4 ++-- src/tests/intro.md | 4 ++-- src/the-parser.md | 2 +- src/traits/resolution.md | 2 +- src/type-inference.md | 4 ++-- 18 files changed, 38 insertions(+), 27 deletions(-) diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md index f61bf62b3..3299e2cc7 100644 --- a/src/backend/backend-agnostic.md +++ b/src/backend/backend-agnostic.md @@ -2,7 +2,7 @@ -As of January 2021 , `rustc_codegen_ssa` provides an +As of January 2021, `rustc_codegen_ssa` provides an abstract interface for all backends to implement, to allow other codegen backends (e.g. [Cranelift]). diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index f64e39461..9e22aabc9 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -94,9 +94,9 @@ member constraints come in. ## Choices are always lifetime parameters At present, the "choice" regions from a member constraint are always lifetime -parameters from the current function. As of January 2021 , +parameters from the current function. As of January 2021, this falls out from the placement of impl Trait, though in the future it may not -be the case. We take some advantage of this fact, as it simplifies the current +be the case. We take some advantage of this fact, as it simplifies the current code. In particular, we don't have to consider a case like `'0 member of ['1, 'static]`, in which the value of both `'0` and `'1` are being inferred and hence changing. See [rust-lang/rust#61773][#61773] for more information. diff --git a/src/compiler-src.md b/src/compiler-src.md index c4f415441..61af38652 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -7,7 +7,7 @@ > top-level directory has separate directories for the compiler, build-system, > std libs, etc, rather than one huge `src/` directory. > -> As of January 2021 , the standard libraries have been +> As of January 2021, the standard libraries have been > moved to `library/` and the crates that make up the `rustc` compiler itself > have been moved to `compiler/`. diff --git a/src/contributing.md b/src/contributing.md index fbcd2001a..4a1994986 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -405,27 +405,38 @@ Just a few things to keep in mind: - Please limit line length to 100 characters. This is enforced by CI, and you can run the checks locally with `ci/check_line_lengths.sh`. + - When contributing text to the guide, please contextualize the information with some time period and/or a reason so that the reader knows how much to trust or mistrust the information. Aim to provide a reasonable amount of context, possibly including but not limited to: + - A reason for why the data may be out of date other than "change", as change is a constant across the project. + - The date the comment was added, e.g. instead of writing _"Currently, ..."_ or _"As of now, ..."_, consider writing _"As of January 2021, ..."_. Try to format the date as ` ` to ease search. + - Additionally, include a machine-readable comment of the form `` (if the current month is January 2021). We have an automated tool that uses these (in `ci/date-check`). + + So, for the month of January 2021, the comment would look like: `As of January 2021`. Make sure to put the comment *between* `as of` + and `January 2021`; see [PR #1066][rdg#1066] for the rationale. + - A link to a relevant WG, tracking issue, `rustc` rustdoc page, or similar, that may provide further explanation for the change process or a way to verify that the information is not outdated. + - If a text grows rather long (more than a few page scrolls) or complicated (more than four subsections) it might benefit from having a Table of Contents at the beginning, which you can auto-generate by including the `` marker. [rdg]: https://rustc-dev-guide.rust-lang.org/ [rdgrepo]: https://github.com/rust-lang/rustc-dev-guide +[rdg#1066]: https://github.com/rust-lang/rustc-dev-guide/pull/1066 ## Issue Triage diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index d6fdd1e34..6a59cf264 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -17,7 +17,7 @@ First, we have the lint declarations themselves: this is where the name and defa other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which boils down to a static with type `&rustc_session::lint::Lint`. -As of January 2021 , we lint against direct declarations +As of January 2021, we lint against direct declarations without the use of the macro today (although this may change in the future, as the macro is somewhat unwieldy to add new fields to, like all macros by example). diff --git a/src/miri.md b/src/miri.md index 54f96391a..fd091d565 100644 --- a/src/miri.md +++ b/src/miri.md @@ -193,7 +193,7 @@ concrete integer. However, a variable of pointer or reference *type*, such as `*const T` or `&T`, does not have to have a pointer *value*: it could be obtaining by casting or -transmuting an integer to a pointer (as of January 2021 +transmuting an integer to a pointer (as of January 2021 that is hard to do in const eval, but eventually `transmute` will be stable as a `const fn`). And similarly, when casting or transmuting a reference to some actual allocation to an integer, we end up with a pointer *value* diff --git a/src/overview.md b/src/overview.md index c34d01dfd..1aa79e791 100644 --- a/src/overview.md +++ b/src/overview.md @@ -249,10 +249,10 @@ to remain to ensure that unreachable functions still have their errors emitted. Moreover, the compiler wasn't originally built to use a query system; the query system has been retrofitted into the compiler, so parts of it are not query-fied yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to -eventually query-fy all of the steps listed in the previous section, but as of -February 2021 , only the steps between HIR and LLVM IR are -query-fied. That is, lexing, parsing, name resolution, and macro expansion are -done all at once for the whole program. +eventually query-fy all of the steps listed in the previous section, +but as of February 2021, only the steps between HIR and +LLVM IR are query-fied. That is, lexing, parsing, name resolution, and macro +expansion are done all at once for the whole program. One other thing to mention here is the all-important "typing context", [`TyCtxt`], which is a giant struct that is at the center of all things. diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index c47a46e78..8be19e8dc 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -3,7 +3,7 @@ Most of the compiler is not parallel. This represents an opportunity for improving compiler performance. -As of January 2021 , work on explicitly parallelizing the +As of January 2021, work on explicitly parallelizing the compiler has stalled. There is a lot of design and correctness work that needs to be done. @@ -22,7 +22,7 @@ There are a few basic ideas in this effort: [`rayon`]: https://crates.io/crates/rayon -As of February 2021 , much of this effort is on hold due +As of February 2021, much of this effort is on hold due to lack of manpower. We have a working prototype with promising performance gains in many cases. However, there are two blockers: diff --git a/src/profiling.md b/src/profiling.md index aa8bf27a2..429376167 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -89,6 +89,6 @@ The llvm-lines output is affected by several options. `optimize = false` increases it from 2.1GB to 3.5GB and `codegen-units = 0` to 4.1GB. MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Z -mir-opt-level=1"`, level 0 adds 0.3GB and level 2 removes 0.2GB. As of January -2021 , inlining currently only happens in LLVM but this -might change in the future. +mir-opt-level=1"`, level 0 adds 0.3GB and level 2 removes 0.2GB. +As of January 2021, inlining currently only happens in +LLVM but this might change in the future. diff --git a/src/queries/profiling.md b/src/queries/profiling.md index d903eabff..1160ba818 100644 --- a/src/queries/profiling.md +++ b/src/queries/profiling.md @@ -89,7 +89,7 @@ The trace of the queries has a formal structure; see We style this formal structure as follows: - **Timed passes:** Green boxes, when present (via `-Z time-passes`), represent - _timed passes_ in the compiler. As of January 2021 + _timed passes_ in the compiler. As of January 2021 these passes are not queries, but may be replaced by queries in future versions. - **Labels:** Some green and red boxes are labeled with text. Where they are present, the labels give the following information: diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index eb6659420..4c2427e3c 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -76,7 +76,7 @@ executed, no results are cached. But the context already provides access to "input" data, i.e. pieces of immutable data that were computed before the context was created and that queries can access to do their computations. -As of January 2021 , this input data consists mainly of +As of January 2021, this input data consists mainly of the HIR map, upstream crate metadata, and the command-line options the compiler was invoked with; but in the future inputs will just consist of command-line options and a list of source files -- the HIR map will itself be provided by a diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index f7799f967..3e950a0eb 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -66,7 +66,7 @@ these passes, please let us know!) [44136]: https://github.com/rust-lang/rust/issues/44136 -Here is the list of passes as of February 2021 : +Here is the list of passes as of February 2021: - `calculate-doc-coverage` calculates information used for the `--show-coverage` flag. diff --git a/src/salsa.md b/src/salsa.md index 67d813b28..bfe753824 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -9,7 +9,7 @@ want to watch [Salsa In More Depth](https://www.youtube.com/watch?v=i_IhACacPRY), also by Niko Matsakis. -> As of January 2021 , although Salsa is inspired by +> As of January 2021, although Salsa is inspired by > (among other things) rustc's query system, it is not used directly in rustc. > It _is_ used in chalk and extensively in `rust-analyzer`, but there are no > medium or long-term concrete plans to integrate it into the compiler. diff --git a/src/tests/adding.md b/src/tests/adding.md index 465317672..944b895b5 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -339,8 +339,8 @@ The error levels that you can have are: ## Revisions -Certain classes of tests support "revisions" (as of February 2021 , this includes compile-fail, run-fail, and incremental, though +Certain classes of tests support "revisions" (as of +February 2021, this includes compile-fail, run-fail, and incremental, though incremental tests are somewhat different). Revisions allow a single test file to be used for multiple tests. This is done by adding a special header at the top of the file: diff --git a/src/tests/intro.md b/src/tests/intro.md index 6b2f9452f..641913345 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -126,8 +126,8 @@ essence, it runs `./x.py test` after building for each of them. The integration bot [bors] is used for coordinating merges to the master branch. When a PR is approved, it goes into a [queue] where merges are tested one at a -time on a wide set of platforms using GitHub Actions (as of January 2021 , over 50 different configurations). Due to the limit on the +time on a wide set of platforms using GitHub Actions (as of January 2021, over 50 different configurations). Due to the limit on the number of parallel jobs, we run CI under the [rust-lang-ci] organization except for PRs. Most platforms only run the build steps, some run a restricted set of tests, only a subset run the full suite of tests (see Rust's [platform tiers]). diff --git a/src/the-parser.md b/src/the-parser.md index 9c3433884..ff43220c1 100644 --- a/src/the-parser.md +++ b/src/the-parser.md @@ -1,6 +1,6 @@ # Lexing and Parsing -As of January 2021 , the lexer and parser are undergoing +As of January 2021, the lexer and parser are undergoing refactoring to allow extracting them into libraries. The very first thing the compiler does is take the program (in Unicode diff --git a/src/traits/resolution.md b/src/traits/resolution.md index f2ffdcc97..70b53e910 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -120,7 +120,7 @@ the obligation contains unbound inference variables. The subroutines that decide whether a particular impl/where-clause/etc applies to a particular obligation are collectively referred to as the process of -_matching_. As of January 2021 , this amounts to unifying +_matching_. As of January 2021, this amounts to unifying the `Self` types, but in the future we may also recursively consider some of the nested obligations, in the case of an impl. diff --git a/src/type-inference.md b/src/type-inference.md index 7674fdf5a..71c2b08b1 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -71,8 +71,8 @@ inference works, or perhaps this blog post on [Unification in the Chalk project]: http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/ -All told, the inference context stores four kinds of inference variables (as of - January 2018): +All told, the inference context stores four kinds of inference variables +(as of January 2018): - Type variables, which come in three varieties: - General type variables (the most common). These can be unified with any From 033a1ea771cda73d14f1652bb1e96553f503b27d Mon Sep 17 00:00:00 2001 From: Daniel Santos Date: Wed, 24 Feb 2021 20:46:27 -0500 Subject: [PATCH 1427/1812] Fixes typo in getting started guide --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index 0fc5cd8e8..99511e8ea 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -282,7 +282,7 @@ commit, as this reduces conflicts later. The pinned version is built under `build//stage0/bin/rustfmt`, so if you want, you can use it for a single file or for format-on-save in your editor, which can be faster than `./x.py fmt`. -On last thing: you can use `RUSTC_LOG=XXX` to get debug logging. [Read more +One last thing: you can use `RUSTC_LOG=XXX` to get debug logging. [Read more here][logging]. Notice the `C` in `RUSTC_LOG`. Other than that, it uses normal [`env_logger`][envlog] syntax. From 07b5693a90ff790b00635a2db020bb13f908c61a Mon Sep 17 00:00:00 2001 From: Camelid Date: Wed, 27 Jan 2021 17:49:24 -0800 Subject: [PATCH 1428/1812] Update some out-of-date information --- src/appendix/humorust.md | 2 +- src/backend/updating-llvm.md | 6 +++--- src/building/new-target.md | 10 ++-------- src/getting-started.md | 18 +++++++++++------- src/traits/chalk.md | 2 +- 5 files changed, 18 insertions(+), 20 deletions(-) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index 3bbedf5bb..1171161bd 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -10,4 +10,4 @@ enlightening? - [Rust Koans](https://users.rust-lang.org/t/rust-koans/2408) - [`break rust;`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0ab2bd6a9d722e0f05a95e2a5dcf89cc) - [The Nomicon Intro](https://doc.rust-lang.org/stable/nomicon/) -- [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20(was.3A.20design.20meeting.202.2E.2E.2E/near/189906455 ) +- [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20\(was.3A.20design.20meeting.202.2E.2E.2E/near/189906455) diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md index a769b428d..3e08b3f69 100644 --- a/src/backend/updating-llvm.md +++ b/src/backend/updating-llvm.md @@ -66,9 +66,9 @@ Example PRs look like: ## Feature updates -> Note that this is all information as applies to the current day in age. This -> process for updating LLVM changes with practically all LLVM updates, so this -> may be out of date! +> Note that this information is as of the time of this writing (December 2018 +> . The process for updating LLVM changes with practically +> all LLVM updates, so this may be out of date! Unlike bugfixes, updating to pick up a new feature of LLVM typically requires a lot more work. This is where we can't reasonably cherry-pick commits backwards diff --git a/src/building/new-target.md b/src/building/new-target.md index 4873e6652..305aa4de7 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -8,7 +8,7 @@ relevant to your desired goal. For very new targets, you may need to use a different fork of LLVM than what is currently shipped with Rust. In that case, navigate to -the `src/llvm_project` git submodule (you might need to run `x.py +the `src/llvm-project` git submodule (you might need to run `x.py check` at least once so the submodule is updated), check out the appropriate commit for your fork, then commit that new submodule reference in the main Rust repository. @@ -16,7 +16,7 @@ reference in the main Rust repository. An example would be: ``` -cd src/llvm_project +cd src/llvm-project git remote add my-target-llvm some-llvm-repository git checkout my-target-llvm/my-branch cd .. @@ -24,12 +24,6 @@ git add llvm_target git commit -m 'Use my custom LLVM' ``` -If you have a local LLVM checkout that is already built, you *may* be -able to configure Rust to treat your build as the [system -LLVM][sysllvm] to avoid redundant builds. - -[sysllvm]: ./suggested.md#skipping-llvm-build - ## Creating a target specification You should start with a target JSON file. You can see the specification diff --git a/src/getting-started.md b/src/getting-started.md index 99511e8ea..eed8855c7 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -79,7 +79,7 @@ recommend trying to build on a Raspberry Pi :P Building the compiler takes more than half an hour on my moderately powerful laptop. The first time you build the compiler, LLVM will also be built unless -you use your system's LLVM ([see below][configsec]). +you use CI-built LLVM ([see below][configsec]). [configsec]: #configuring-the-compiler @@ -123,17 +123,17 @@ The compiler has a configuration file which contains a ton of settings. We will provide some recommendations here that should work for most, but [check out this chapter for more info][config]. -[config]: ./building/how-to-build-and-run.html#create-a-configtoml +[config]: ./building/how-to-build-and-run.md#create-a-configtoml In the top level of the repo: -```sh +```console $ x.py setup ``` This will walk you through an interactive setup for x.py that looks like this: -``` +```console $ x.py setup Welcome to the Rust project! What do you want to do with x.py? a) Contribute to the standard library @@ -150,11 +150,15 @@ To get started, try one of the following commands: For more suggestions, see https://rustc-dev-guide.rust-lang.org/building/suggested.html ``` -You may also want to set up [system LLVM][sysllvm] to avoid building LLVM from source. +Note that by default, `x.py setup` will use CI-built LLVM if available for your +platform so that you don't need to build LLVM in addition to building the +compiler. In some circumstances, such as when updating the version of LLVM used +by `rustc`, you may want to temporarily disable this feature. See the ["Updating +LLVM"] for more. -[sysllvm]: ./building/suggested.html#skipping-llvm-build +["Updating LLVM"]: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html?highlight=download-ci-llvm#feature-updates -### `./x.py` Intro +### x.py Intro `rustc` is a _bootstrapping_ compiler, which means that it is written in Rust and thus needs to be compiled by itself. So where do you diff --git a/src/traits/chalk.md b/src/traits/chalk.md index 24f2d749a..db3c19a38 100644 --- a/src/traits/chalk.md +++ b/src/traits/chalk.md @@ -34,7 +34,7 @@ and designs for the trait system. **rustc**. Once we are happy with the logical rules, we proceed to implementing them in rustc. We map our struct, trait, and impl declarations -into logical inference rules in the [lowering module in rustc](./lowering-module.md). +into logical inference rules in the lowering module in rustc. [chalk]: https://github.com/rust-lang/chalk [rustc_traits]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_traits From ca851c6b709ce8e3323a3a134d0e6998c2e07f84 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 20 Feb 2021 16:07:36 -0800 Subject: [PATCH 1429/1812] Restore instructions for using system LLVM They were removed in #1030, but are still useful. --- src/building/new-target.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/src/building/new-target.md b/src/building/new-target.md index 305aa4de7..7701fdbac 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -24,6 +24,34 @@ git add llvm_target git commit -m 'Use my custom LLVM' ``` +### Using pre-built LLVM + +If you have a local LLVM checkout that is already built, you may be +able to configure Rust to treat your build as the [system LLVM][sysllvm] +to avoid redundant builds. + +You can tell Rust to use a pre-built version of LLVM using the `target` section +of `config.toml`: + +```toml +[target.x86_64-unknown-linux-gnu] +llvm-config = "/path/to/llvm/llvm-7.0.1/bin/llvm-config" +``` + +If you are attempting to use a system LLVM, we have observed the following paths +before, though they may be different from your system: + +- `/usr/bin/llvm-config-8` +- `/usr/lib/llvm-8/bin/llvm-config` + +Note that you need to have the LLVM `FileCheck` tool installed, which is used +for codegen tests. This tool is normally built with LLVM, but if you use your +own preinstalled LLVM, you will need to provide `FileCheck` in some other way. +On Debian-based systems, you can install the `llvm-N-tools` package (where `N` +is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify +the path to `FileCheck` with the `llvm-filecheck` config item in `config.toml` +or you can disable codegen test with the `codegen-tests` item in `config.toml`. + ## Creating a target specification You should start with a target JSON file. You can see the specification From b932cf20cfb11c4d92f5991bdb5a14a28b22fd30 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sat, 20 Feb 2021 16:12:08 -0800 Subject: [PATCH 1430/1812] Fix typos --- src/backend/updating-llvm.md | 6 +++--- src/getting-started.md | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md index 3e08b3f69..a9c3b45c4 100644 --- a/src/backend/updating-llvm.md +++ b/src/backend/updating-llvm.md @@ -66,9 +66,9 @@ Example PRs look like: ## Feature updates -> Note that this information is as of the time of this writing (December 2018 -> . The process for updating LLVM changes with practically -> all LLVM updates, so this may be out of date! +> Note that this information is as of the time of this writing (December 2018). The process for updating LLVM changes with +practically all LLVM updates, so this may be out of date! Unlike bugfixes, updating to pick up a new feature of LLVM typically requires a lot more work. This is where we can't reasonably cherry-pick commits backwards diff --git a/src/getting-started.md b/src/getting-started.md index eed8855c7..a1bf0d50d 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -154,9 +154,9 @@ Note that by default, `x.py setup` will use CI-built LLVM if available for your platform so that you don't need to build LLVM in addition to building the compiler. In some circumstances, such as when updating the version of LLVM used by `rustc`, you may want to temporarily disable this feature. See the ["Updating -LLVM"] for more. +LLVM" section] for more. -["Updating LLVM"]: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html?highlight=download-ci-llvm#feature-updates +["Updating LLVM" section]: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html?highlight=download-ci-llvm#feature-updates ### x.py Intro From 761f92f3908bf9a61b2930d81e71878ba4ff13c7 Mon Sep 17 00:00:00 2001 From: Camelid Date: Fri, 26 Feb 2021 11:57:54 -0800 Subject: [PATCH 1431/1812] Remove some unrelated changes --- src/getting-started.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/getting-started.md b/src/getting-started.md index a1bf0d50d..14795e083 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -127,13 +127,13 @@ this chapter for more info][config]. In the top level of the repo: -```console +```sh $ x.py setup ``` This will walk you through an interactive setup for x.py that looks like this: -```console +``` $ x.py setup Welcome to the Rust project! What do you want to do with x.py? a) Contribute to the standard library From 1f68820307c1b9f02a8ff2281b85c31d4f120241 Mon Sep 17 00:00:00 2001 From: Camelid Date: Fri, 26 Feb 2021 12:00:24 -0800 Subject: [PATCH 1432/1812] Document how to enable CI LLVM without using `x.py setup` --- src/getting-started.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/getting-started.md b/src/getting-started.md index 14795e083..18e429e5e 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -156,6 +156,14 @@ compiler. In some circumstances, such as when updating the version of LLVM used by `rustc`, you may want to temporarily disable this feature. See the ["Updating LLVM" section] for more. +If you want to download LLVM from CI without running `x.py setup`, you can set +the `download-ci-llvm` option to `true` in your `config.toml`: + +```toml +[llvm] +download-ci-llvm = true +``` + ["Updating LLVM" section]: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html?highlight=download-ci-llvm#feature-updates ### x.py Intro From 3cdb245b435e4cca64642806b82e596605bbe856 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sun, 28 Feb 2021 16:19:09 +0900 Subject: [PATCH 1433/1812] Fix broken links --- src/appendix/humorust.md | 2 +- src/closure.md | 2 +- src/contributing.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index 1171161bd..a7ba61769 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -10,4 +10,4 @@ enlightening? - [Rust Koans](https://users.rust-lang.org/t/rust-koans/2408) - [`break rust;`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0ab2bd6a9d722e0f05a95e2a5dcf89cc) - [The Nomicon Intro](https://doc.rust-lang.org/stable/nomicon/) -- [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20\(was.3A.20design.20meeting.202.2E.2E.2E/near/189906455) +- [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20%28was.3A.20design.20meeting.202.2E.2E.2E/near/189906455) diff --git a/src/closure.md b/src/closure.md index 3330bf1b4..93683383f 100644 --- a/src/closure.md +++ b/src/closure.md @@ -118,7 +118,7 @@ the *free variables* meaning they are not bound to the context of the closure. [`compiler/rustc_middle/src/ty/query/mod.rs`][upvars] defines a query called *upv.rs_mentioned* for this purpose. -[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/query/queries/struct.upvars_mentioned.html +[upvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_query_impl/queries/struct.upvars_mentioned.html Other than lazy invocation, one other thing that distinguishes a closure from a normal function is that it can use the upvars. It borrows these upvars from its surrounding diff --git a/src/contributing.md b/src/contributing.md index 4a1994986..d0c77edf2 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -565,7 +565,7 @@ are: [rif]: http://internals.rust-lang.org [rr]: https://doc.rust-lang.org/book/README.html [rustforge]: https://forge.rust-lang.org/ -[tlgba]: http://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/ +[tlgba]: https://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/ [ro]: https://www.rustaceans.org/ [rctd]: https://rustc-dev-guide.rust-lang.org/tests/intro.html [cheatsheet]: https://bors.rust-lang.org/ From c431f8c29a41413dddcb3bfa0d71c9cabe366317 Mon Sep 17 00:00:00 2001 From: Camelid Date: Sun, 28 Feb 2021 11:21:01 -0800 Subject: [PATCH 1434/1812] Cleanup rustdoc chapters a bit * Rename "The walking tour of rustdoc" to "Rustdoc overview", which I think is a more accurate name * Use same name in sidebar TOC as in chapter text * Make links between the two chapters prominent * Convert a few `.html` links to `.md` Probably we should just merge the chapters, but leaving that for later. --- src/SUMMARY.md | 4 ++-- src/rustdoc-internals.md | 2 +- src/rustdoc.md | 15 ++++++--------- 3 files changed, 9 insertions(+), 12 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 02e8e3843..056ff050f 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -13,7 +13,7 @@ - [Suggested Workflows](./building/suggested.md) - [Distribution artifacts](./building/build-install-distribution-artifacts.md) - [Documenting Compiler](./building/compiler-documenting.md) - - [Rustdoc](./rustdoc.md) + - [Rustdoc overview](./rustdoc.md) - [ctags](./building/ctags.md) - [Adding a new target](./building/new-target.md) - [The compiler testing framework](./tests/intro.md) @@ -63,7 +63,7 @@ - [Memory Management in Rustc](./memory.md) - [Serialization in Rustc](./serialization.md) - [Parallel Compilation](./parallel-rustc.md) -- [Rustdoc](./rustdoc-internals.md) +- [Rustdoc internals](./rustdoc-internals.md) # Source Code Representation diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index 3e950a0eb..b2dc2f7fd 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -3,7 +3,7 @@ This page describes rustdoc's passes and modes. For an overview of rustdoc, -see [`rustdoc`](./rustdoc.md). +see the ["Rustdoc overview" chapter](./rustdoc.md). ## From crate to clean diff --git a/src/rustdoc.md b/src/rustdoc.md index c087689d9..33f2c5f35 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -1,17 +1,20 @@ -# The walking tour of rustdoc +# Rustdoc overview Rustdoc actually uses the rustc internals directly. It lives in-tree with the compiler and standard library. This chapter is about how it works. For information about Rustdoc's features and how to use them, see the [Rustdoc book](https://doc.rust-lang.org/nightly/rustdoc/). +For more details about how rustdoc works, see the ["Rustdoc internals" chapter]. + +["Rustdoc internals" chapter]: ./rustdoc-internals.md Rustdoc is implemented entirely within the crate [`librustdoc`][rd]. It runs the compiler up to the point where we have an internal representation of a crate (HIR) and the ability to run some queries about the types of items. [HIR] and [queries] are discussed in the linked chapters. -[HIR]: ./hir.html -[queries]: ./query.html +[HIR]: ./hir.md +[queries]: ./query.md [rd]: https://github.com/rust-lang/rust/tree/master/src/librustdoc `librustdoc` performs two major steps after that to render a set of @@ -59,9 +62,3 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * Tests on search index generation are located in `src/test/rustdoc-js`, as a series of JavaScript files that encode queries on the standard library search index and expected results. - -## See also - -For more details about how rustdoc works, see the page on [rustdoc internals]. - -[rustdoc internals]: ./rustdoc-internals.md From 8bb61fe105f783df518527dee9f9d635aac84fa8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomasz=20Mi=C4=85sko?= Date: Fri, 5 Mar 2021 00:00:00 +0000 Subject: [PATCH 1435/1812] Use more accurate estimate of generated LLVM IR with llvm-lines The `--emit=llvm-ir` emits an optimized LLVM IR. For optimized builds it will be highly inaccurate estimate of the amount IR generated initially. While the inaccuracy can be somewhat reduce after disabling the optimization, that in turn has other unintended consequences, since opt-level controls the emission of lifetime markers, sharing of generics between crates, instantiation of inline functions, etc. Use `-Csave-temps` and `no-opt` bitcode as a basis for more accurate estimate of initial work handed of to the LLVM. --- src/profiling.md | 68 +++++++++++++++++++++++++++++------------------- 1 file changed, 41 insertions(+), 27 deletions(-) diff --git a/src/profiling.md b/src/profiling.md index 429376167..155dda97d 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -28,6 +28,12 @@ number of lines of LLVM IR across all instantiations of a generic function. Since most of the time compiling rustc is spent in LLVM, the idea is that by reducing the amount of code passed to LLVM, compiling rustc gets faster. +To use `cargo-llvm-lines` together with somewhat custom rustc build process, you can use +`-C save-temps` to obtain required LLVM IR. The option preserves temporary work products +created during compilation. Among those is LLVM IR that represents an input to the +optimization pipeline; ideal for our purposes. It is stored in files with `*.no-opt.bc` +extension in LLVM bitcode format. + Example usage: ``` cargo install cargo-llvm-lines @@ -35,36 +41,44 @@ cargo install cargo-llvm-lines # Do a clean before every run, to not mix in the results from previous runs. ./x.py clean -RUSTFLAGS="--emit=llvm-ir" ./x.py build --stage 0 compiler/rustc - -# Single crate, eg. rustc_middle -cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/rustc_middle-a539a639bdab6513.ll > llvm-lines-middle.txt -# Specify all crates of the compiler. (Relies on the glob support of your shell.) -cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/debug/deps/*.ll > llvm-lines.txt +env RUSTFLAGS=-Csave-temps ./x.py build --stage 0 compiler/rustc + +# Single crate, e.g., rustc_middle. (Relies on the glob support of your shell.) +# Convert unoptimized LLVM bitcode into a human readable LLVM assembly accepted by cargo-llvm-lines. +for f in build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/rustc_middle-*.no-opt.bc; do + ./build/x86_64-unknown-linux-gnu/llvm/bin/llvm-dis "$f" +done +cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/rustc_middle-*.ll > llvm-lines-middle.txt + +# Specify all crates of the compiler. +for f in build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/*.no-opt.bc; do + ./build/x86_64-unknown-linux-gnu/llvm/bin/llvm-dis "$f" +done +cargo llvm-lines --files ./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/*.ll > llvm-lines.txt ``` -Example output: +Example output for the compiler: ``` - Lines Copies Function name - ----- ------ ------------- - 11802479 (100%) 52848 (100%) (TOTAL) - 1663902 (14.1%) 400 (0.8%) rustc_query_system::query::plumbing::get_query_impl::{{closure}} - 683526 (5.8%) 10579 (20.0%) core::ptr::drop_in_place - 568523 (4.8%) 528 (1.0%) rustc_query_system::query::plumbing::get_query_impl - 472715 (4.0%) 1134 (2.1%) hashbrown::raw::RawTable::reserve_rehash - 306782 (2.6%) 1320 (2.5%) rustc_middle::ty::query::plumbing::::start_query::{{closure}}::{{closure}}::{{closure}} - 212800 (1.8%) 514 (1.0%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl - 194813 (1.7%) 124 (0.2%) rustc_query_system::query::plumbing::force_query_impl - 158488 (1.3%) 1 (0.0%) rustc_middle::ty::query::::alloc_self_profile_query_strings - 119768 (1.0%) 418 (0.8%) core::ops::function::FnOnce::call_once - 119644 (1.0%) 1 (0.0%) rustc_target::spec::load_specific - 104153 (0.9%) 7 (0.0%) rustc_middle::ty::context::_DERIVE_rustc_serialize_Decodable_D_FOR_TypeckResults:: for rustc_middle::ty::context::TypeckResults>::decode::{{closure}} - 81173 (0.7%) 1 (0.0%) rustc_middle::ty::query::stats::query_stats - 80306 (0.7%) 2029 (3.8%) core::ops::function::FnOnce::call_once{{vtable.shim}} - 78019 (0.7%) 1611 (3.0%) stacker::grow::{{closure}} - 69720 (0.6%) 3286 (6.2%) <&T as core::fmt::Debug>::fmt - 56327 (0.5%) 186 (0.4%) rustc_query_system::query::plumbing::incremental_verify_ich - 49714 (0.4%) 14 (0.0%) rustc_mir::dataflow::framework::graphviz::BlockFormatter::write_node_label + Lines Copies Function name + ----- ------ ------------- + 45207720 (100%) 1583774 (100%) (TOTAL) + 2102350 (4.7%) 146650 (9.3%) core::ptr::drop_in_place + 615080 (1.4%) 8392 (0.5%) std::thread::local::LocalKey::try_with + 594296 (1.3%) 1780 (0.1%) hashbrown::raw::RawTable::rehash_in_place + 592071 (1.3%) 9691 (0.6%) core::option::Option::map + 528172 (1.2%) 5741 (0.4%) core::alloc::layout::Layout::array + 466854 (1.0%) 8863 (0.6%) core::ptr::swap_nonoverlapping_one + 412736 (0.9%) 1780 (0.1%) hashbrown::raw::RawTable::resize + 367776 (0.8%) 2554 (0.2%) alloc::raw_vec::RawVec::grow_amortized + 367507 (0.8%) 643 (0.0%) rustc_query_system::dep_graph::graph::DepGraph::with_task_impl + 355882 (0.8%) 6332 (0.4%) alloc::alloc::box_free + 354556 (0.8%) 14213 (0.9%) core::ptr::write + 354361 (0.8%) 3590 (0.2%) core::iter::traits::iterator::Iterator::fold + 347761 (0.8%) 3873 (0.2%) rustc_middle::ty::context::tls::set_tlv + 337534 (0.7%) 2377 (0.2%) alloc::raw_vec::RawVec::allocate_in + 331690 (0.7%) 3192 (0.2%) hashbrown::raw::RawTable::find + 328756 (0.7%) 3978 (0.3%) rustc_middle::ty::context::tls::with_context_opt + 326903 (0.7%) 642 (0.0%) rustc_query_system::query::plumbing::try_execute_query ``` Since this doesn't seem to work with incremental compilation or `x.py check`, From 91f8f334f42e687dd60e61cec9417178b26a0e09 Mon Sep 17 00:00:00 2001 From: Wesley Wiser Date: Mon, 8 Mar 2021 14:42:56 -0500 Subject: [PATCH 1436/1812] Add article on using WPA to profile rustc memory usage on Windows (#1074) Document how to use WPA to profile rustc and what the normal workflow should be for investigating bootstrap memory usage issues. Co-authored-by: Ryan Levick --- src/SUMMARY.md | 1 + src/img/wpa-initial-memory.png | Bin 0 -> 312637 bytes src/img/wpa-stack.png | Bin 0 -> 145576 bytes src/profiling.md | 4 ++ src/profiling/wpa_profiling.md | 108 +++++++++++++++++++++++++++++++++ 5 files changed, 113 insertions(+) create mode 100644 src/img/wpa-initial-memory.png create mode 100644 src/img/wpa-stack.png create mode 100644 src/profiling/wpa_profiling.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 056ff050f..241178864 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -23,6 +23,7 @@ - [Debugging the Compiler](./compiler-debugging.md) - [Profiling the compiler](./profiling.md) - [with the linux perf tool](./profiling/with_perf.md) + - [with Windows Performance Analyzer](./profiling/wpa_profiling.md) - [crates.io Dependencies](./crates-io.md) diff --git a/src/img/wpa-initial-memory.png b/src/img/wpa-initial-memory.png new file mode 100644 index 0000000000000000000000000000000000000000..b6020667ef00ff3a1efbf7007e6df8344baaa5cd GIT binary patch literal 312637 zcmdSAby!qu_%;ekBVE$nASoS6hqSbUv~+iafOK~YNK2Q*&<)ZJ14wr_%o&Wmw{G|O ze&_qn`Qywr7uPJ-thL_v$@_VpdjjQU#gP#35Fj8RkR&BU6d@oG#~~nK0dNn%|AFYM zAp`$~v{e)rg7`E@un9hZGI}oa90H;&9Pvg68Ug~8BPsIyrIXf9Dy*Bb=)zse{s+yw z&!0X+VFQ5$b_NED>B|{JSK1q5VeaYy?G7G~*!X$N31 z1$WcfcIUvah}PpVnxWs*5=+B`qGU+&Fh z#z*lsfjS|z(D@8{W6;w7cvUxs{*>qO(l8P+!{$lL2jqPU$LpITe8BA)Jrhd5CB@#P z_7dQaigFGKxwI5;KQE^5`|R0JISPxY{h6<1Uh`N_fXDS6EY#Yq+ya-q$82UaubGfJ~&$yrVp#qa3~cH zj0z9DcZ7evA_y;7ecncYB^Bnk--_Wn@Nd`ekc8d_7>}2C#NPG^s4rZO#=b83Xy+za zce`2_x!-SgIuT3k0yNW z*3>%+#1e;Cfw7q_7~riBNrTVnLsozgf)sT4T{zteP?pc&1z2af?YG8?0U+Twh_cKq znP^2Is^v`tRmIPq)eT>%>FeDpDYm2(ucd9tfQiFf#XSSEp{6HSCr{F~1n7ls-7d!k zYY2$T&x$`L1I^3tgtD+KMQ&~v1cP`4cNVIx^{(ePV;Rp)Qq^4ThxGSD-*7m2b0C01 zJ!DI3t{+mo-16aDKS_F*$%~FXr}jVuW*UonDiF!z4YCV{!7Fs!0n>;?HOam6K7A}39)KB@JRu6Amqm_icy;~hW7qQcrSw)d! zTEMTnvGcXxXGd5BSX-V;m%1)=4rr+Kl1=Bn+I%EGsKSe6voZKE-RH#8GdEgZDpPqz zvP5#NUT<|1<=rCTX6)=k^u0&Y`u5?3KEw&a5i%Ru>O3!C8?pEYyB9HIwy8?P(_+gd z&S+PN*fU1zlxhwc$Gl|P=Gw5P7ey!1N_!P+J$?)mUR5*>Bxv32Ra$e0%zjHjB=kIY%ViLHT z3*sC(22NS@X;|Ks^DgPsc_y24`b^VyQyXAPKouNga4psII?zz#igY&1uuc=EItqHP z3%=1u%|%14a6fox+dWnHu5_lT0!N6*JLf5FZ*+Z#t{u^q^RUCT1NO8(*Y<%{tJ!PR ze=VO-d*Kv_DvPUvUqP{>-|TsO_#qyA z{Z#<0U`2`NE+GbQu?%5cZI;JKi&0zyQ3$BBfk_(i^9z&`&@-xf3#ifhnI!9W#g&LV zX0`<87>xL2{c>KsKIBvsEvS%e^+uOR$nJRenmCXVB77oK#6BjT`aERK?2WTkJWKyz z=;foZ#dr~-R_@JGt+qd{J+)yMY*kT@IFHtg$elm~!pWUsX=xXi+3LWMqyy#sc;L=Z z)=@L5oGhLSsjBF>zbE(wbTay<_D#kM(b1{@mVfO)?7tF z0vo?!rXJey3L<^JncfaDd?Y-2-Ry9W5q#e+h!p=3SojGkneD~S-YP|y$cQ_^tLHJ_ z;J`l>|6sXq`wqXA7O=YplVAx4w%LMMhNrG;vuxNmM$7${VxgePMYMGL_gW*ApUg@m zbFK!QwqmCZVEP%@+#D_gw+m!|Nh}~FK;hP0UKQ};>3g*FX>(Pyp0N4ZrlL%{qJUuZ z5xw$YR4f_0U&)XB*=D(B4VFj>1<|!tng953|_eH61Id8g0KOMBWuuYCpHi zzky1cT7+Fgt(A09jZ6&{Z1yxEIDH?X_31<&gJ(LXl89xwf^TwXijc^ZhH!i7L;H3D zQLQ~+;>%}+>J}>G@%8)#dGPRiiL~5vx)1Q9+_0hWGANc66eAtXsC3*VMBN~ck^wQK z!+%$;;q#xIT-dWlafKIKjvp4ow+PS}%s~zcJ?eRj@=wu$ zKR&zHl&Ol(&wweP(m?{rAhEhcDZ$|6qLF#cRfj?s?f7{&dy5hD z7&UIi=B-p#X|Jf~`P8sGvHUg;chk2kfey$7Rjw}W!vXr_@83OPuxD0(T}h?09Y%#< zL19R-T~h7}?Zd}}-2sP*chgMpfFrXJMh&y`U3oM{&jS_zcPR>Z)iJ8uN_&wWDxXz# z8TIr|WfRR0Y+!QI2;MdIacOv-L~xGDDg@ePy?WcgXT`|UmVodykOu=3TQ6qA7}_Rw zcxYoLieiXXbI7E)xUnmPlsZ~qTV|t-g$#QoMx%?=WIBRR>^Gr7KpZp&tOMUAzq#dH zrLRefK59F;1j;3NFk0-y`}%v%M!1QUTu}W@Gx0Ie+u6^x7W{??zH%`_NDe@nKnfy)-PsuG-SonxzrNu;~Ku=8a8ogoGekIF166hn<7Q~cwq>cq8d zUJ1x#UX{X-8QhNxIdfUl^)Gc*&>z%%?7kg_J0}mcN6cWK2F{qFH2e8|Jr9 z5dAKm2;`=QJpec5w8hF7b#bsQ*~DrNXdSgx)&awl&+O+Cn6z=PHv8O59JU>DlndwQ z#V2JaJu8-8_$s-Y@@sVO0j&2jq&St~2O~Xvl?6B~o1`cWDM_tNVHnR)+Ad!Rl*)rZ zxoy$2BhSKYVOY27;NRj)gD|o86}sT)NQqx&u)`3^v`(Z7SS}<)RzKg+lR$}Un;^OH z=62#N3w`Mgo$#JY>^LMX2ig5N&hv~Sb=<{$^975o6nY6Mt9^XP1}0kO$yWV8*o7&Vj6 z^bTqqw@&GvhT65xSWRWDYCTBvOTztKOsJSme7gW{gU1&AQKiw4AerT5kZkJpd~LpV z_~U^aPIrNzu%?lv9BFf{7kiw=E+n9VRjO<4V)xZIyIlyb7nV0Q@>QB;JD*JB2|I6< z>zW%b>0%RN-!&K0e$YPkdiPnqhg!pe;}l3&J*I}|wEAYMiz?DWD2dbx!52cNb^LX6 zv`VSSh(KlX>E>W`n5r*0TrJMGv&v)5jPbVS4IHRzpmJAc27U@bUU~3SJ~9fj!=BHC z=8IM^7&()JoJ^5A7BUS~49r3+_eKTL*jjhk%Cs=21{456^%H^`);*G|Nt^O;?|QKO7t( zsUEKtz7(3>t}!&O(lq4Yv^Xn&{vv(v@x%THgqn&z3jG+;kK z93j7Gv|vltE4aW5q{3X)B`-A(8L5eaMsL;4DCj$gNZdcEMf*%4fvobK9mx0jZc zJblB7hObrPc=#qYJX`={%Cl{+q_<{=`(%PnwDFh@X!X>xiH?%bdvtEcKVAY?4KYU$ zPcbp0N&#PzF&nZ}f>X9Mqo}R62|yY^MwgM`aH=GZSCYE)5^4G0?)#gdON1_dVaD zT6`RnHsy_P#=fFtOkasC)FT7uw)DHSAT}5Kg71=*o==(j1j2_ty0A24Y!Kj%yt4EU zyJ`Ssc%JRt>cl_Uuku_H+FrBd^w{gS{bGj4TcW;|!(n;WMI_I0nbFS&<5aI&U7XoIs@xsZ9kK zSR?N*DUkt=IY?@I!#l5;mJ+!u=gdgOH|#O>ESw%1zjRCR=zoN4xXx;VM-3=OBlL-+ z847etsb;O(jFH%sq~gv@oTJHvMz$c9Dx0Yx#?~z+t&J56H<1*B`J%VVIuRO%pP|C5 z_mu77?-CmkopVA&9;WIN_III!(?bgE35rGlTUpt7fA)4XdJ``HVPU3q`nl(7I=`#O zP~B)fQ+54N!RBn}R^y>rD291*{|j|Rerto(_SC9ckl}0-PkLJ3xiRw{KKN0bNd2B) zS1*1q1R=a$i5=V}udzklu~|=W9%2CS(9hKY-o#z3paH~491RZsYrbRPSbl@$UBbdX zvB%zSqy1U##7v6Dwr|!K59iMU=Rh~ByfZz&eboDo&s;;Z$G^7Ltpo)wbEj&B=iW(U z7N`0yTFcd4mLP!~?}a zuWp8UyVrHY=d^Yr1vx|VPWS5LMS1RpN!;%&>~#tAy9y(6;m$7qwW#mk!nm;f{p;V3 z;RyfhL~269HzqC z$G`sdYUl%f`siLmy&G(7Ok63)tIe^y<7;fRC&6ovh;{i48GP-PuFH(0tFculJOH#d z%E+Hihgr9izKl9YBcL%_CPFHd8c1CdOg4B3AKTx`*SB7O70)#0wsgJBTyoG8Mk zqH{^T{O>Xw0%G%cR_RpQ^ZaA#V7x=G5l%iCBt-~RG*z~aSoeF7p`)kC zzWfFtS%oGp8UHJwEJU<9Af|#v3~03=s(?k-?>6c@59r9$t?Lm3A@M4F4JuW2y=&6kQVgx+1SL6KshsuWw>gvBAtI6J;Fu15 zTSFeGa|^2*1{5kXgzcZ=%b{<`-xFgkQ2|_e41S=}ZU4pQR?c2Zv!@>9pNyA8@8-Z_ zMm2ckiHbC@ZOu~kAvQdfjD+wA-`mz@fPxo@$~}aXOm?*8J#NDK{ zH%H@wQ4r{z3|yX>NG0Z&&OQ)#$ve#itWR_Fmnm#Mf&A;tSJ=L)WZlg?(x32JdGIGO zLBOTUy>LC=s~iPL^R8a+9hk#n+=Kb_2w){>4%J}$nYP}5@ z0++p8M^mMYDN9UPB>p^BJ0O6m-<-tXAi-3vA)|Mws_+pgbSzG62P0QBc%D2`{7D9+ zj?IzNE@8#Zz-Cp41Y(Z|{GZ#N`8=Gc3|Bcu|jUmfNC$il|sQed}U80;w0yp(CS z#~p>9Nm#0%#dBxMQcd=?4u*2`LE-VyC@T?|Q3da6M<_z#NBy%e&jXALNV-kHrc%JN zb@0@oJ%wwjdhu{c>kqB{zKQTt!J9D{xQhTR!2z(n}otZm`9K$V-{0M|p6;IO@ zCF$>MN)R1F#JDx@L_|{X^dT~0EJEvB082^jGe#p1ye^5h6fTdx&`m)8^NIIg>vYOW z7yrFuh?sN%$!mS5nakW8Lp)$t{r=;rESJ7DB;Lxx8au@@Y0bUm)%cn@(fc?7cG`Yp zq2y=^3T0ING0!ZrS6B;o_$Ia1bDWr2B*$+jV8%K1e7WsJAcCteP4bq+dUP@MADDNW z=@JG6Ee9^i8-<*)fm{Mn=j}rRw&6VXGxj)_?b~M+1b0OgFGBABj z$TpChUlYEgS@(MTeHas8y~i3k@y-Ps6ZO5}T`B>lK9B zd^w7|!tij2(3sU2&mSQ{&WC397wANmOO zdXdMYgH3QNBeKB!46m-Lc!7EGy_yLC_w&AeZu0`i%Z9VCSF$os)6(!pJ+oZRADx2% z#P2UFaED;EvhQ?c@O{7>s=MvRIqw>F8vj<$G;HHsA@WRzb0zq>8tj;gh zhHm6$-h~~kj(m{6du7Dx9sVx&(|(?>O#)IjBToEdVwKErS)fjyXv{WpJviti4etp>}Y4W5iy z?E-#(B81~?1dQL!sBpoO)j9=UWZjeDf*3 zgq(8UPTkDNLIZlFfN`GU0hh**^>ofbO8^UEtIs4>e4lb~sQ)HlSm^NL9uWWbdiD$` zcxncY_g2&ctBj7j+IAr7{2GweOXs6d2F25!z1ed{H!rB*RyN1sc(qlpb2+pP3@e23 z$MzR^g4xiwZ984V{ssag{w`(&Oh}GE3Ck$mDhuEHaMLDWx>}jxS$p$s8@HSdFFdF* z?Yp|q5;AT%#i$gSbzur^1>}9sHlg6z7Ev*?kka9NcyP*F#HMr}1%$rZoiT6EeAzt5 zku)!6zfy{f$6=QDjs|+Ec{`|ZwO@ri`Rzi=f_8!#!ySH)cbf@+Bkyl}10OaIbbz6b z`;Y(_f6Pf%aBjAgJ*3;wyl4jdC}@pyuA9s+JzMb@34S)3LSuN10$vgeN*&zmE`0zy z9gIO#sRPdQlXk)+$~dP+vl8P$t75b@0#wu@_eOIJluuai497-o0QrB=w@I=#3QM<2 zvZR^w%1W=SigDKWIRTPvZ#Xf86N?OVwfZP~dG>Q+BPO6sgtcplk+ zBzhDb9P2W8D7XSw3xbiW{{yNuySYlQ+z%hholLm`R4O%j?t|L$l|c#I%lRv1a`&>i zp1rf#Z6@|`yLA*UcUhC&S#>eTE1eE5T?XnUxr zUCB{5dHDM+f{@3Bu%H_wC+)%5f%g>%Njn;{>OovJUNLmaQX;U>f5OwxT-*dGcLxAD z-;kQ)?&5w8g#e%4g%SpA>@3InQZ)Us_M9E(aK7?o&yN_YaExRugy$ikz5?$9?sQV~ zbGe=sy{|2Mzo%So%8V-%GVTky-S;GWB1bYv_tvHZtDk0h?t#rxD>ND*<{we(=Hb9Z zCH=tY;9P9y0<%4M5nn!mw%6JNjKXLLCv%UQ_r?Ro&hkZmB&ComO9_mTgJecBIn>2l zC5RQC#XrqrN4|E^8-ujs9O^7)l0A(|VvgKhH>&Ap_uR}k-NAu&hPe<9?eajQ*F8Jp z<>6zz7fBKR+0H}Ff39(k$OPSGfkLNyw#JsLa=f?Kl}bB@91inB4<#PogTJgg4ZvMYPKL|Sj7QsMxSshfvE{p#mEk>;0 zryf+AM@IxfAj5^~8WK1kA?!b`t30(sJ$$1F<%Sa#%1@@{!m>U5pY!o& zAJMcw|G4kVcFTVCz`wrxi+x&=|Koe*S2%`j+&}JkZP^3~;naK%mwS*QM+$coHAOu| zi;5|)oBk&Enf$Xrcc0V;&mk$#;2jX4pkt<}Ik)PW7UC~Pegv9~sBr*ua?cXLn}o*9 z2L$8Q-*yfsevOUdL!$m)xA<}YpXT`txp^CBZC{S^Jh^Udv7@BJIxnGT7mNqK_(!Z# zyd&8#LBZREdNpqg|jy);q%seDY^e zVgsQCVAhu2-8#OspqKyP5Pz|fn)}Jk`t?hF)SvqYODV$nf@tY2s6YsnLi)dM`Qv#% ztL|<{s0+W#u0rY>MglD5Ye zapB%SYGyBjXUyML?Bbe;J@;N%K!2n0rJ>D*B?*nA>E^;QHIuu;U0X>*<#GG9MsyLz z|E^eCZd%Kae83a1G!oN@x3o(Z#jpD=NAFq8FP8c*Gzldr*~zXOcv9ZTXQQp zNpVGL=QD?FuyWc9HYbgK^$Qa-8lvcXe1`(@(?J9l?zcf0&wN%j$iM>X=5q_T5tFKfpn}A>n`*zHvr@U`9=TN6I0G-FA&W|DzZ4(&y4| z`Vh!<<8-2Ft2ckzYpIbM z=00&=A7!m~Vnc&z&V98Ic&w@|=xn%f13f%EygO56`jwiF&ZIknl-FTb;B2j<%@SnW zvuCTJsU&@#2E3ZN^rar$<#9S1&$8U(we~o@I}U>m_$x3~?{-6vv>VI*rPKe|6ec9Z zqjoBt_k#P75HPyY%6u#*>ZrQ~sCp0G_X7M>6or?*5{N zeVuXP?}cXQwCix9vu7UB;NNmqntF41IP@adJe74Qw5i74b8+2m38o&@=0CaWiHV8X z*m%3tWISrvpTKf22=~24{@exa^6NRDU8Ab%kFr`EBR0w9C%@}8o2qyY6@$9D~|-;E%dI(W%F zaPLRBqWfWmkqWN*voaA(>0}8#!soyup6A!22v51;DHQ~RzDyR>yyEh-TIz!B>Z4pz zgu6>-=JmEYJGM;N7pX|@Ph?wsZWHJM64K6(5M6UET6Z|&cD%A&@%YkiPx~ajb*EM( z3_dX3V~UZhVuA>t)p*lu7*S}bHk(j`Lmknvv2k_7_1>l%_vOQ<(pud|KMwS_b9XId zTjsI?(N}X)sTZ{CkE?Ji);TSQ%Prf{#Q|X3KYv4o(&1^l zsx25ifqMqj_iLfdSOiFlf5i89R-);(wce5Ig%_Rv3dsC~H_g^gwEk76T!$@VI-IrG zm>xy!oN)5WFHJ_%j%sTtU#>)eya5w~H(Pnuf}+TId&5EDHsFOufdN|;IEuiA0p=?l ziNBeJ#nDJ~yuj!JO6;d<0{3vim54L6c1Vf?E7_=1X~bGbk5sO<-Th14mJRGfrf~Bl#Q7?CEBE;JbsHVRQ)-}o z)x8L=qTjq@q5KegT#3)gz!w)|b_g6g)HD+#G7=dOTRH>wPv3M_#=^RyB=_8M9!JM% zH(mwC%ck&QVDP?sR~5WPEa>{RsH&^d>|^UHK)rT*cl`RxK5u5NxqnwESrj2RxYmn& zQw&ay-xJRNrfGlAJ4u=6FPwF#0FnFYANJx-QfXRQ+KQONZ2ho5cT2j6Gk1j$kN|pn z!ITyq9|#x{CJ+*F$XJAZS3u+-1h^i#gL&euNGVpB#;f2)kKGsHFMj(Xn`zkofP-9g z$6h*W+`q|a3&p-O{|WA?F-z}tt_WX6g;j{EQkl^@oP{ah{C2)24f26_;q2HF<7bXvVXi+|fR{6QaK~S3X7c^ez$-1qHvr9>@y4D`>ar&$#@Y#IRY6md!Gb?%-$jj=m*+CtZ;mfpXR?D z4@7qyG>M#l52FxRCE5v|4KA#eunTV!dMq8eBvV?2^i7Cv^ZU%~xiI_7@ozy|{T8tzkx%oM)5G>r8^{hjiRu5y1$Y&d=7mu6igUNWc=8K(()cW(|Vu_2L3Z_mOi4Cx+9+afcTwTRttd}%- z9QDsRA7^D{%~qLG&vBa1h=__J;j-#?eVXqAezv>V^?WkzE^CUfc8~vFAMm%LiE>nW zTK!K=lnj5y2jws821oc`j&+aqSsIvz`M+DNGa7hi$4oYM4{|M0x>Qdx29oH>XyE!+ zxW8UJomT>xogMksSv8jM~;PPgFCswr<+ivk9uX1HVE+mr4v0POy=}T zUXrEXGi!p5XDoNPQTH>AoD;YGE5XnmC2M!)PotvY)Bzvc#9Z(~JG98v-7bu#>)R+U zy|WMH>-+b$ou;d1B+L_GyEi1Fz^%Zw8J(sS2FIlYrVqUvrn&DO(wsnxn|-k1X$icR z9>6AdzkM+>Fl+*&g>6pro}u8p3&i3F08f*?;q!w#T8MHuFdzpz_8E%B-_`_{A~f;; z&=7B&Eq^ggvor?(bIQ-(InyLet&PauXqhngp;QpSuV7#TGz0@eXSp^~+AaZ%=inR( z@V>+Ei2WdS4tz_6b*P31U=g+MnUeq^eJO$lb0f(Gw>p(GhFJqbp(j0~d*bD+FA3QS zC_60ctwXuU1m1!|!97FDOUsb{7dG@=SHglr5?zv6r+tbnV=WR@8sfd`d5XlL(aIxQ zBC(m1veu~$C)0;DPj=@Tji%m5^1Ge~?vB@shZ89%D1b3$a9G$L+H5o?`hc9q#Z?a* z7Cjpxxi7xA}z!`7LLEf$nKA)CushoHKl{CpiI!&MC0; zFn%m4m(9!TEa~K7|2j|t0Zf5&()B-mxyw42iO#LanKf6t4&-tl08SmDEd(gF*9TiB3kZf)EiKVW_A+USWEzuVT0_gBk(UK^L~GeW)2kif7o zSxL$1#(h*;3LcNMMz9Zm;&&RpYR8k&)CQFAw_i$*8unP=N2N|06&?i}Sus5d9@aKC@V}(G^W+qEaT9XShG}TeQTz^}EzCnT$ew668z5 z91WBQA)Pl}5I-WP6~4od69JDykg+aV*gj_YJp}{2uX2T<)Txl&XLzd>+L_@TA$Rx| zV#cSHYyLV5Nx9^9xzY!B_F2&zJJLCc>p?oTW(=!FLI} zeDD}3w(bP3mhXioSPRZ6O5OQ|oHQZncsetyGjbs*mC+U>uNnU#L>p8O!31G3Z13_k zwy$)|Vv&BJPd*X<%=+ALJ2A{}Zu+(&961{Pk*@jzoy-%PgQrYghmKCp3BII8HYPqv zyq@pgw(}}iYEM7^9%?=lK(R$bl}BfHLVfzObZ}gl;G|9v;N5>|X;bJb4h9=jeCm(( zrR{$3LgjllnELAmJcUJesXlj!T303zVNSH~Ki9#=rF~cdkbqCr5#@ihFpLh4ADTuX zum@0&z1He<)|ZLO-<--57I!n@47$&x^SRyO?{Sg7{fMz;K$<5P*5d^d)3*v`5)-;x zpqcb(dw?m9OxvS+Vclace6&uluEvKPU^1AZYQp`cAkroGt6gU&Px-ZngfdIMc+&Ig zwIXwkq4h#$3s&9~X7**!B~eg!@!}4HNpGoIh&q{Ny0P@xlov1JvBznX2D!!VyNvi}nNAEfmN*NKL_A27Iojnm$6| zi5yYWp6BsaNia8>3+ZEl{poTI%2TvcwBBD>Rsa4^oo%lC6wi1PF8~Hct6giBJnyhH z!zS@@tzUof%aT#ZURl!ZIYjdoO{{*|rRj2rtu447eX<))ti#E(z4E)fy4;QCiR(4L!>0oTh_ya#pW>tG&uAl6_P?dn{e+nz@TRlBlYzbl6zU(;AuW8G9KdBU=_2eAM$oa`CO7(=7szl9Jit*fIO*X``Uf}! z7w!LsgZdDR^R6DVk%+KzDYNzmD}~~~ImhLjt=sif*!75S<6S!RXRXyu4r$+1{KYeR zlZk(T$<_Djijx6~i0_tztHCIarzTT%Lk$lf!^XQ-2{uPrUX-J+J!`0z$& z>o57|s=I(ZXejb^KNXQR%|a&}S+8l)TCg<%7Y!kf>F1a|^YOi!f#)ML{VAG;UmpGv z43oOG@N4&yLqJTWZ4Cmf^>e<|j|87Sh+ZXx`VyKvo)Y?(G=%19btqPdw>py^IbVOQ z`TUTwy0QadK>gl4@9|R!Jg=Wmst~;Ml?~6&%w^g;z)Lw#kMD%$Y93C~`SlC>(NOWq zbZpW*_$rcbK43})`FsyEj)5L-TDNt8BG5q^-u*mA^|ggpXnF`=0}KJUcl=97>WBuC zfeW&q6AD~W0R&?SvPMiVR=#yepM!Lfi0(V2iC8zB@?j%`82jlBCy8fjN%$X`FD+RQ zcIj_T#=}AM+Gn>VB6U6Baw_T7W!e-lH%1VW<@R(wl@?aDiF(IeX(KiX)>#_DG{S=vu$0-v`7q8yC@NGrNnA_v$)>9sKfc`3&pLn!@jF~$7`}InVCoO z8!X18tX$@+Wt-$EFXO)jn|p0qDu0@zT^53A))V>AuGp8cI)O|$N3p;!k^7NSY4C-` z3wo!b>mE_MXq$TL8Tld>PFk?eyLrxqG!In#76E8YsD>MhC0^xDym^5ltl>k#uz)&| zPWlOpXJ~{PS4i@d>#-(pvt4;GRcHy5^$v(WBo*uGe&9iQWNyL!mXVl9S~u+>?IBSL zE9))$Wm&On{)^t-PGjM+&J~e+^z%z`z4E#UJEa-?>j)K4s~J@Qh^hiy(EAYhb$RMt z?u{b^+crTO0GkT5qYHpxc$89tJI{JEs3u3ZhhZ4z?rs^16=x##_sV9N`02!l0*cp^ zXVt{E{9zyCbhG?bVHG1RAxEs!Wp+s6YQ8eduS=)NrFK+QNhzNjhc;2Km!&MBUw`6g z&O)C@e&Dt0h*8RMRJxftIo1DU>{4E~uREtxF~;oV+3ZGk_iiw>bQOClJNmZToUp*- zFJ+rOwrD>cMiXnRQE|1PEdS+`5F3M&!t7V*rw9kZ6wtMrQewOE+XAV>d8ctNj^w9< z6aqGM9VpI)O{+QvFg{ZT}FaGJwmdX}$v?c=dYwuUY;tpB+58n<^+&P>* zfs=)C*b$3>>Gj5@MP9LHo%0wYny-uOYt*$+1nVWje$TIZu^0hN{IN2}N#gY-OXhpo zCTHs2FZecFp z=(aCfk1#Vu&bO0ZSV>5IUCXEyj|NsTJBGeF0{qC$c<>`_$nL}Nufc&m37Y!#F%oGr zxJ##febKrpoS&bM>#`K%pGa_*+>daF4`&mje21^H+@-DO7F&QhL?uItmby-zNh1)AFjXPpCJC zUKx3u;4ubhH1ovLO_w#O8GE}Q;yKH_eZQb4+pS0gY2xUDZM8bVlP2P2kQcMSbYj^B1+7=PrW0d_g3VD3*^$NDuudcrVkepN`bLM+njJ}sKsdhAF{jiEk zw#KAxiEG%OTD4ry8B>bRB}1RAd-~K&!}hCuz#0PTi^5nRugw*Gn~d{_vF|tKM*DZt zOkHSnjRq*dt@zR)y#LXLwSFm+wspqJxa^=!=?Csh%WjVy?(ihAX z=D%^H-wt5uZK0}q_>qu4)`US0<8${@^la$-64e~Rp!4OYLP!j+F|tDpy^>z;3z-(2 ze~L+bs9IpYOItM8B9kHaa&a_6f06GuCpVa3z@XK3zM4Mfk&dUh*v=F$C%Q=-!41`5 zA|9e?bj`_uF{RI9=kR}y*#FW3Htlud*C?A&DcdQcj!gaD@xL4u%OS}1S=Py3Y#d%u zamdKjV;Dwer8+_<2ZJ!_UK#oU9ak*Z3`g@v9jp%2RPwJK{((}hbD^vW)#wsWI{St? zvvev)5I1Vaiq<5?y?fYJ+G&kfNe`>nAXZ_1Q}Gr+;n8D5csAn;bDDm3-3qfIhtJ29 zG)4iK`Rq2uq(mJal~6%CVnjTmvIbCW+1OG5f}HNO=I~(+Cgv|9#KmvFE|#!~=@6n@ znj*_vEMi4t+?(AmBQ-0Gp=46zkv4Ge$u$4#*nnsuC`6$paKBtxtWgqq#fPV3i z58KjO)Sk*V{m2+5SR7pv@(&dh^;TM)Jwtt3{ zvaR46`!!?3k3Bg^C_*B5TRbw7)=PWZ-$}>7Rc7HeGM6>wFTn0n#Qp&qTP^vS{q$de zO=Yz+Rd-XC+UmV(F$WRWM7Pguvzqo6?jcqV!4=9FTfDzf$b0I@1#+f$n)4G^=z)d)!1Tb6(hA0_^0#=h~$rTi$$PM z6}(oDyH^N5t{h;v2;Rk2(tYwO-D4W>w0faI4|h zMruA`7B`54PJ+`+9VYEI{#%s@z96yJTX&QOnn{oFNQ!yP;axcNHnx>F6Vcxu!W3jp z)yHWhLYjcC-e!NSZi+pyv%w!16RPqe>NzG;O@6KL0ER}dN9HddQ&!uHO~MhYxAK?@ zsbAHglGa6GP?g0K;>l9L>w`7qEjeCP6C>402~}ve;w`oRa!@3%)5hW&5zH1(i$nIK zt#Dr`?s-oSZu4=)DM&mv(!*q)LpGadH2Iu-7EgCTcGcc2>~RRq$gWkd1F5dCc;pV2!Qu2kogB6Qnm@RNLtY?D-d!mVK1qEjDmTzHd5V*e#oD)Gy`{Dlb3-EjqxIF4R!#Tn z4&Slk;Iyz<7n)KFCA%xFPY#7+!m@dSfv0(-`e|I>*l~8=?RHk=Y*L+iCB~xeFJ$lI=6yw47n(T@s zM1iK*TsWpL#EigW;s)@cyV*3x#)ZxIB|WU-Mj0z}4y~L4m0jduhpCy?da}|VcnbHG z=HXV4Iih&SZc{Hx-R|1DDKYQ<2L$w=yb_&bFl~=BZ{|F0OEt6Cu_z`qHQVZ|v}%?} zkD*7R$xG?i$HMMT9uneG(D->X6U9aWvR@d+_&>&O<-v6(mWkN}vZHCF#u2Yb{79dZ zqbdeB$f)XMkSa{x*fI2~vh<@Wm9}||jtV64DQR;(00LtZa+N1<++o!k%u1yYRo0l^ zj9a+IY4N{|E(Gga0j7XL2FILdCV=fzP zWZz3*O)Mf%sLAP~_~7Ac`(w@|mAcSza-Sq|b2^=;(KM7A@8aUIFX%%@hhed}unLt? zV$B}JRqBcs2KcodX%yx_4u_kByv#@TTeS_Zsvs$in~9h+R?zHD|06>7x*uQz)1|@+ zZXqra*TB$8S68>&=*Sy1$+8ONoA~Mw$ROj6<3mED?>FixtfOsRkf-fb0J-H@B%7*K z6icI>G4fE_HJ>;4skg}1IQsIoHqO&BO{OI2!)%ee>L~)O4%|RZN)*|BIij#%4Z&{( zpumESsBP9eql%wD+nR41+}LVdH#aq<&rZ_VQMd;k6gl$zla8{9O_irR`_-G3vFukU z@n1AbKEhr(OD<8o*zeC@r9Ck*VBTV8NW~Q%_=mSA?8O$am1uFDCaFE~)+l@8i!@SJ@q^;3${2A&Q^s>9)xzDeXlsd*1T>-OSHXW}Y@J*Q z*q8=@62pd(WH=-B#}FArxL-=+y*XNsu|DC0t_q6H*H5bKGd`(hi}Tckc_{k64NO+u zl1n9J3~R}KE=gTQU8{W5l% za<=UdOS#~w2@u>OiP1|Be80&2gXx870g{pR_h7`|kT!r2@&i-8z|(Dae!_B*&lxQv zC0j9ZS)J^4soLFodoz?EsRhK(;`o0#8*WB|0<`)=gDZ!>XPeznTY4ro zP~27$I)7@bZ)qnCtc-b%7OH}Ov_=Bg+i>&=WT;2Ix~*|WU^Ax)tNydu=)waY^|wH3 z1`^)9>qh<=?Ejvo{s&jU8z08Q4+-PGQ2p8Z=RswSix)KD1TRV5>)*0jK1Dn}J)Xtz zB|pH=?+33910Np|gaq|GQ5F0%?9vi5$^*ePD0SE$P0(-a+FSxYthLp7C`elVjj#4U z;w>z~cxmgj1%X#^xZe0<^!^T_q7Kz2Vw4gVnYQoG8Kfz0CiXTlN`MmQ6{fja!VeB* zZ#|g4XhCq#p^HS?-QN69n#8X&=-;GvalG&gqYg}tmj5#v6B(%W=C~@n z#LYU@^K2PRiM(&Q5OP+@s1kfCGz-73E%+KWJya-TWs>$#dc1cbeWWoi7Ni z%WoA@aL7y+|AX~=X6K7=I;9KQ^e>L!iE|IHT+Vd}0q${)^}TT;B!gMUB*))i@~_0k z-zad0>-^t&kiW@4((@aB2+cBC(E8Z1xGK)1-Q?zQUHOd&C7?J0CW1X`bm(olF(&}` zS$tZl{ttPTmD&lbx$|=>86vkjeL@xUTnT{C??hG1W>4Er6c7t_69ojsPJv^Gu%8n0`Q5U!=^}tO;uyRUiy+HmTyT5*M`|OjL zTP_?#Dd`#fca8)}GAba6tsfnC-I}Wgi$?a>* zq6qBu>{czkYiHA_Q$D74xY2A9#M-YHrw_=$&j7u1I5Fku0WZ~=@!4s$@};3Xf7~W=Fu@=OI z{GcB6(RO`s^U5+PuHZmEQg^jrVt2;#g9=uW!%h(0Ep__-1TVs5!8F4bcY#U{F|AsG z<3~pFWEICe<;_oP!KX*~Ma~cRk7F6Nt|r{<*9RvHMkdqZlP5m|+-@iu`RrtZw$(l# zj4A}5*ueGjKpz0X9KQnP!YJabInOrFF(Gin;rDk;fc@3&zS6|rV-}l}(k1Iew4PED zgZVN<(8!T+o%9VFS1ONvukl?nYU#D5mdj?&n;XvXSeoeCEvs(qluh@-3pYn)JexOV z3bE>pLG;VVmw1L1AVaftvZfE#S>hZ$>#jU5v0BM#*psBW^6XDS?vlNcBs-~R!Ok%M z47@}zO{k;2{q0?HDh`;E|F3s%MN(|J-a)Ct*N@bp>2)-0WVrsJNn9+}iE+feq9Zq) z)2Da&;6}@;s*JlUR}**&Wl1kjCX50g1)B%IOZ&(Fi?6qiin86_$4wLwP(YCG?v|GB zE(t-TBu7FTM(OVE4k_toM5Mc$5tspK8FGl3-^2T!^Eu}|-?e@$T?_wEhv(V%zW2WN zbzOTG;`wJSzlc>dtA6|Bci`zKlE!^;k5iXHExs8|MTg7Z%)Ln74)g98#cpr1`ph&2yMhcD{E;H zO*kYZCGZgEIOk||F@XA9AD@@R7uZUCG<8KZ1{Ji{SC9sutM~MtS)66$UJFtieM}{X zEl}*9II~=CGMIJ-M>NQ9uw^eIadMzTwHx1mjgAquZmH8na6;dLy=!-=E+f;#_9G_m zr3r7`5I1%%ZUq^hLp@p9Z#JM2{5gV_<&eRn`}-cg8e4|vs5qa_)9Ce@06o(;>0V}w zzvm~<>!ML_nw|H8g-{H4e+CbZa9EpEd6yq{eKC)Encq`B=jN!f4f0VqVGB;+62N=7 zv!UqguC7F-JhSIALzuO@|gB1Eugzb8e2?fvzi*u z4F*uVqOrkff^+CI`YPe;^XrHBdXTE1hvU~raqbsBNTm~UNihz?{k&22xYqtJBCsD= z(nhQBp*a{_6?U9miq~|Bc)_+H$|2wWcJI@sezeHU8^^@Tum-u=(- z{|>cYWC2m zea#k+liX={Yr1$d$n}Hmn@+u~dFH1E9>G7AQ5o(;F)?(i4ShS`q8%%R<1tuK881i` z<2Nl8yQKNACIfvLOGd5Le{)mRbX%=G4m{Dx zbjOPxC$_HWnwhV<-ha9P-#0W$_|wkMr)iyQusOpwRyyCt&0*)xqt^~wo@-|=5K*ms zdz61rFr&RI4fTH?4yHq!@$qIS-uRR~(YDP7uw3v-1C@+V+5?-V5^%m#u&-_SGot1qhGt1^G0cUEfJ$P;6yW0KvNL%fqQ!!Ryvwg)<C?EdH7f-ZcF|!vJ7oQ|~S;RX(Wi%SbtJtoDRbvq_eH>zMx<;KtAY0kq z2OZ}oh%eVTSrTBBs&$oJ7j^lcjguy?(HmSMc+gvuv_a*^MJ&^<{{MW=F*f6|%}!GZ zM28-Br)x2^ON~*K{I&o!Zrw-%L`YX@dp?1DQY)ck;JNxkoGr_@*j9tPiG?RO20on1NA4soK1f; z9yQ>z*9|>0*0LQ~JBnGp!(O)u8K~NV`T*26<)PMwwx8+%JeD0StrhJn_XON|c9bSN z;uwqW1>Qv=jJ$z%u|6hh>Yo2}CX#nYq8Cc7`%P+Z@xj&?!Qna@h<~`)au3>s4){0G z>lphFb)|~Ya=bquSNfsUa;j1HvI7^iDQty|p1kV_ofE>$+SW}Vki~ITW_!O$jf86u zVF)B{DV&EC9&dc!Co&nmwY&F^E7?=-1Sz--cKK~kUISPA9^<2N{s>}J3;Q9KP|_TbKa7|c4*=?v0hByDHMPIvl_Xv(5C$k!1@+DeS8B7~3&Y`{gzBH) zoQyoFz0)JEp0K$6ZYK(Zs0^N${J>r}F}Nr`_`!W6IMue&)j8Do>%5uETdCYHUN(43 zGrN}d$Gt1iJZokm$s9auGNFy-v|Cgbpq3}S;Dpx7 zkpO4T6E4%0mU!r6f1V=yb7-WEbh7X8%L1RRprI9Iq)!oELjP8z*Lxn?n9lfMeY*P% z9(IlZ*?lA_^3$qgg&V#2!7;yrz@XUA;t2tJG4)v9?epKMALmA+jD<9!pNW1XCR|Cn zW@LAjmYuWxBO&S%4TFT>bC@uKkMQVCT+u2skAeEnO!{)yIe?+E9)Zn>dRt6(lj3z5 zE^Vm$hsCIJRa-Zk7~%o_N^836c@CYIV9fqGvhbBZ5X1Bb;I`k;ji~8 z2LZD(qfUG1DcMACr77a@4mldTY)1lys7Zj*(N~8@M$%y`9t)M9sVc9grd$iAK&~CO zTgAk@aGq!l%^uRL*3;=(+H9VR;G9vuYW53|+ZS<7Pv$y=6>-M+GA&Y|nWFx!LJH0b zfej1wf$<4>b|IJ{$li$oO-;*Vq>sCx;uiWKfi+8PYmT4O>p@Pxi=b`3{Jns)s`f}TnkS2dk}uqIfgWFS6)#wI26ZYH3` zu7PC0VB9XgK5|G-Z_@54{xIZvq{D6H@|M55?6%|pBm<*{^GrRp`pw@&P0P+hIj9rH zN>PQLkp-pn;|Skfhm#<^yZtGLvq{yyd6u95pBJ2pwz^8weUyf_T4}9@plmjhISJWs ze%`)fldH`wzDpRX)+s&v0)if?;t$;4$|UidKfoI|s4}2Fzmhk}4I952HE|$0kt#|TOT{v}<+Jr)b?r(9ZK{wUpptmEH^k^Y6EIRads0H9&L82Wri=X1q*U@v;%nfTyLHo=t&t)i z$}OCetxQ+h$+TY6c(?^w!)~duah;Z4RIa6BO1LfBhiYtRzNVc+*_NIBcH%oo)qP8n zu6i6lk~D>nlBFF*YJ>epH}Sr`e_j|$ zL37hVh17bbn762lIY6<$7tEb2j4o&El(I!YgOIERVqTctB;SHn@v zv+qK}OH3h1SeqqQ$|EF%1XFIKgduiUtNx8s{#|5fSzk z^iiXW1W4k1sP;ZO^23y>&V>)I*yYb+-Z@6L1xhiG;N&O&Xjz=wO3_w}{<22u)yrr< z;DS*cD38v`KTKY1mK8m-+R(eKC)K*>3PI0&ZAJ&*Rty!(BJ4K4v8W76Fmiw8&`-#H z-x^_xFi0#eit;$VdY=Ii_TJxW*!A~S!X|c+lKNrOTVviAO(x`wfGPSZa4B1jq$g3M zRd)r*3(PNVa0@47?kT*HyAd>qOZz<^0yzpTO3Tqg<|OiyVO7@OW#C)1cM@@GJ zo^`bwxVG`$3mwPCHHQNl`Gehj*CJ8n{HbH;pXbTHy_w8@O^KTZm}C^Pbc1O|ARtKW~eN9;4YsfKO@7b{OP*)KqjnfB$}1fB={OTABXbNgKG0}rRnxSo6J$kQSX z9c;Qge5F$>`=uI$QOWD}Fhgcf<^aNNEE!GGaPabtp-(>z*ngI!EwRm^^AGU*dQJbJ zKh9L5%OVqFH$kg_BBW`h{_rwduK|!~_V@P# zdhtWQbLE1Yxo{9N{5r*luqY2GNGc6KWgV@0A7+VqBFd{f*FzrE1wMF`meyvGZ+^Ky z55Bx;iMbyNloEg~LoE&OM7FZcBj^nhxO?6Py84R$UE&cHKsqgMDA7L7u4eNy;xKOaGEp6Amx97w z?PgY;)NK!C4bQ#&uTu%n+`ft|zPfLP8>6`_5R%WjymJh%<~8wB)!kXzc;AP8L>b%z z?p{qR5)bKp-n99uI`n;Y*`WUW`Q}R7)Mwt3Grqp^%0Yx^)g7RZMEbnIXsn{5Ab{x+ z17=LudC7G}FN=}188D!;m}*-h|8fn$zTp7q)E}dUxX;In%9xQCKNPXQ#Ns@Cya%aS zE|^hz8iQ5#zKPDaQy}bwqwGQ3mEAIifMap^=Dh)ncQsDU?uzVZ&&}n}{)~x&8)(=etR$ZJ3mkBF8W$Z_X)=t{aF%@hZax}aVt=egE zu=vrU<>Os_oG;!uh05;=ldN@#8~MB!PUFdiHD?t^Q!9=cEULEdJn<6k;@BQf%;OH> z7)#2;r`PM$nKy#=Md|xRo)ZA zhB*IdzdjfkF$cL=n;U~(URPRzoH`m0eoW(=ig4!V>kf@|w(Qxjhb{mFZZ?yegJdJe zGRle9tnNCkt~NaC%1z`zA3w1v2xijFW5}_QDnTXG->D+s0(&7RRpRanjmbFvFWet8yo++D_!*V(vs^rfZ_l= zK;S)==&>ut>|_$8j=EX^gGXY~Rvi+@@|3==mnYl1b1Uf6T!UJ_8!w)h>|wgg^iu^} zxf@&J3_1S}U5`yH)A1BJ1KF=U>1lRj^p^x=NLd}6QM;08uuOM-F!3q$)n;`vd)0=ztKAj87V?T^1<04`>sk(mT-0PlPw(KcoDqKjB6d{kR3eq!Z6C_^ak1<4ahFv|+8SAhtgYty1TDFTRf*_s8Wy{s|VYDA~xr7 z+9R-`fB0 zSD7BP(7AHXBe83|ku59`>^0-;DSEOzz^r_?_XFI7gpSo)Lr4U@p13|^qpuD-S}WUR zzLM?RIJgI5=FN>Xwutqz2zZVakPjm|rkdsYGUt_vmBAt4YW7Sg%#iP6(nM%6+R5Ech2XR7ax-MTkG8As1)@W zSvtdMlS_ONBC!#qY;wZ|?vlE8&~CR__yP{6k_e(;9Vq|rf|ZI1^Z~#jxV5+F9mH$w z58?fd4uB5yiub*_Ik0nOu|%B`kp^4|4D^OCkRadyDgtJQPM$l7NV|X|Xe3ZatQ&O- z_fh0a|D}f7>IT`^Kv2nq07d~c!>szX@=Fg+uQLE#!m1yf@ClGy0Y<(0Vi~b4c+dRN z!4Z5CzDEhon&vyRl~;EHZcQY{%e6hyROx=0(nu@?+w`n6yii`2 zz2OswQld>t-`i8}YYHn9O>>U&pld$v8lZm6*e%T=>|bD@M~Yi?qf+FU(^vO#oH^L_ zISA>A@T?-MPXRC2?{bNUqy9Z4!%j<8OXHn-W`;?JRfEzo@p$FvV2LaFbH?YysEndA zM)@9bFsIm!(P1e+Zx{O(XE#DjDE920q?ykDp?6Y$ps%X4Y*(*kt4^*3uU89Qj3zof z*$S5rECs_F+WOZ=tF+%kuZ!WD^3o&)4XDW9^O3z9?VQc$?XMOp*4yN#oE+-E^%~y3fMD4GU}$CDvPof1@Ycy6K4_qvoE_K!}X19Z?eUN(mpE7UJt3&WD`WE@hM6w%|QS^R@|wdyBE`?3q=!`RNudKOEi zftR8w^puqgZHa+d{(TjAae?_lY1~U5frN*ipg)P0{5ifR7mgI*Odx~{jU$F5FQDDm zD_S6S3Ge-GP_wwu=|H*k`RxTqN>sg1Qj?<-mul*F`N_BWMi3^5&ttUm{^|qVXv{}H zPwRyizsJYlG5KM{a!^puf|JR0ndcJag(*WPWck?Lr1oZ+vprDz;z&zTg!72yzfsl4 zgQSQnP&DU~cNwseD1wmVI<>}nESp|AIa30h?X#&C0Ze9Xbt4Gb|JC#Vgtze?LWohD z=fG(?BlT8N1+0?;4eHc*qk(Nxu>QCNM)g~ykH>D7%{d)t`kIxCKV?KuaNl^HkP*BF zWNUCSv?_oG`-!6nbE(XRrowG7)(Jc(6fz6Axur zngo)JN_yE%XclEUEA4vU91tHHLHw>qW|rzV-@ReoUaj1kk0h;@zQ0Hu!S$-9 zaq!js9IQ&+W!&iB9x(1Vh(gYx&RBYQz06lEMba2?QT;A9JVy4cCx_*7b~D;mSOeR0 z#^r;tFt{15aCODH@QeV_mv2Sq% zf6cPbbxBdzAZzXB+JXvjAun0x43oJrm?!;e`CdcFB*QqU8e%Wll=%rvl4St z8{)ZOZRpuco+P7>{ony>t^6Jft?R=zJ4(Mgdaqrhq1DS%Q`4Jo9^2~jF*kokVp1C4 z<{#!8`XztR-I)obr38x#TIxdX0!5XILF?hD$RQp6SsV1G%B3lrRL!q@Xv@K~-0$Y{ z7LPEG5o?629wnwfwLzU>or`M(zIEuDZ33_Bq7S1Xf8xDSPC58v%8$!U(Syu^|DEk~ zMQPU{3$FGH*%1y)^@=JAue#?O?B;+mqY3!t69PG3V-6U$Onk+|$NyKY6*lCing(I` zhL-aiAV6j&C!fIq_@ovOCHK`g=jKpwGoc?SxBv%M`N%r!vG}}B0H3&yeV0tf$O!DZ z5V~<%Y?R(2Vq17tsKE6XHd%fn=*>|?j%HGA2Y=PwZN&osiuJ=B;j=Z+b|;wS&oM~l z7(1k`p+7Ui{Dqt6L%@CvV0^%GZY5W`S6={;8ek$dQ)IdF)Zn9YC)&y=;N-Ee-(1?>}w5;*q^&q zWSVy94`P^isX9ig>MR^;wRLNBV6AHPna7E}CJn>Ob+5!pnjLiakHXhXw`-6yP51A} ztI8zE;KRC07}lU+D%AV#WXM|5NGkB@>a?IWRo25Xk@)J+XIX?capkO{Z;GbEqg69= z>9yV}EPA}D6kd~}hzRVvI#Pcu<~uepF~^crdmh#B^^CPrcxmt?o6Mobuy70`g^z;v zb?0x?ohEl*ipUz~kp@FwxLtfzEv-;M{0QM*s2g2DX0DLUW)Hn{ccjb75D&)ri2>`r zRKy+c#&>jt)?V6!dT{|S18N_?IHI$klp;?pBR{-uU7KzSC}H!yKI$9zcZ|Xg*Wd#~ z$SFq-HsQ-DQ~p~dw%A8^N%7q1d?Jx(`_%9Q)g+k3sElc>LZMUWuyP-GLv&xRnfe-lWmZ3+8{8pRvSild;JQ_`MOKXX z5ZJ+?38Z2(M_U4i_H>rF)D9>nuFq2Bj!@zZ8b-UaB)SV`pK zU<|Mk6Y`c+8cJpdel6we?gHgXsA0YRzpZjr>V5$zhhzXoPhTI_Mr2o>bO;c_Ti3|r zG#^yd2822XpvkzvvAiC_5%0JX&i590A0a`Tk&d524ri5U)okG!7p`Vf!wKT1amjV3 zf?!FF%@=a$DC8ouyyOKa^9tJNT{T!~xfG>-Gb*f_zj~cKHTg8#y)&t^Lh!Reo{PlH z%M6J+hfJ*>pPOndi3?^5b3{_62Op0gJ}N)&v8nVKv}KQ*G%jzz?M*_n?83b$EcK$O z4T=P6UhL@qe5ul!GDd)1mlGE?EeQqDQt1~%lbmqUPM~eGG zgg>}5KarLG$2Iq0;CR`ebh4q?dQYy|udPyry4D$w?EI=+t(PdMPT#Afbbg*$J@w@3 zE#{lE-F|nE&B{g9mbj4h{Zk{&?>052?x*W`Ekr%Mq*-!Uj?Rp)ZAN)`Bh><)XPH@( zL@`@79PqWKbT?~NeZZ4b*uX69@m?k6;t*=D&T^JPJs`iDoYxOIxPnbHLRHi+tKLql zU*V$M2O|#)^1;Yo-ISfkIEdTMMhml@t?VpCYl|L~7%*2>F=@X7qLMYIRswYtQ&Sze zKU1#X<^K?kNP#SWntKa`$cLtbj@eExHMEHjS72_k$S@C$lg?Qp-3evCj0pAa_z zcf8@9f3~k~*d%y@UW3aINuxPde8p=WmH-vAqLuU0rEP(N~fr3bXos(+vs2Q7u(@9*{dWJab~ zphvDuTW}~;3t0fp!%@s6U_j<<_@kY$(on=PV~R+E+L>I4-3YLTEcOiMfk7~_orqul zV0BO-=sDws2_<_YuJMoS@E>x30Ow==ES-W}WO|FPTS5&n&?HZmD;QSxA z+f)S3^b#G_yf3`mL3^Oo(qP|~QUP7ycl1PvROib;Du*0rFEfUGTipG12e^CZuhSfw z-ogWwx?jI{FS{?ZQzBiI6EtbuL{eI!XctwMz$j@`HACWSQww!soJ5o+Y%C}xe-e)> zr_BkC6X+PS*7Yi>2y^@DN&cH^rmijhW}2ZwH1oK9;m0A zWGq??rYQ@v?aeX=vfRb}oJ*e_@{uE~{S1ub1|Evpx(-TF_$eGA4oS{ObUvcJqOf;y zkdP2T;+huZ`j|Y!H4t!=gq%0G_qyxJOJv115O6@2jLz!dIYwpBm!%-K#?(1W$IiDT z&_aGcT-m9P0Y)s}7-zz_HEj0C52KrP`HSjneL1caQTP8jNt7N2^ICTW7cjR$!|a!4 zcW<=I^{dak&;+-Wc*9n6M7u6<#nptdB9)8Jz$l5eUdetO%^~GGhspD1dsC~{bh8R`M;xUh$8s12K(5iS*TQ53T zfmc(O(3eS8FdDq@ldVt@rq}y!y34LkN!|E?2xX|~Sidyk?q_ai2Q!6u^)DRepFA2n z5;~{%sT7qzz~(r@#VKS@$ZqNi*%f>-k5+bYlSy0Y^II$tGv!tlx}WsmRZ->N?Zh(i z^JkBJ_EV%y-u1d}-+y=f>!fNdz)-mm$d0E;)nTdy=fhkRQ#J{M=v@L5E%(^s@5hHJ zKB^8b{T3!{xCV`+y2AMD)W~=n;uHK5+Vhz4TBV>&x;?K2bLag2oLuwl!xTf8X~qV_ z>u(-q7rTMi+}B+pP+3{9_O1{|35ztk{CT+*01u3boyQ8%+>W_?LsX~l{m2)}7;~d| zWx1T+!D@1K{Us#g=-@GTH=Z8l4H4$N-$9DyBMF!~0Lu`3^ajrcT<#-5*)KZ_FOsWA-(IDG3;Ho5&}YoWqQcyRq^f_3lV0Ri?H zI7%2IyWf||s+{1eheI0aGq%+1W3PkLSR~s&|JG%(Ox&YUAyZ1&%Kv5K`k>aBCM4RB zg2&t;(x5h?S_>&-AACoE%NMWkZs~@mmwtJ@r&Y&QN+vkyqOCY9y<4NIEIBRr>10`v zzV=({!LL(l3y@V&zk3=-tVI~H6gQX+H8p`ddA0M?5v=Q3uuIX>2ASK=>aiaErg4Vc zd2ARQ+@4q)@N^=0P;r1~3kq#$J%V#Y3K2wvXT^z9x8ae7`e~ESt1a76E}YR4Z5tYR z*mso=N$>U#bdO3w$g~6?Ut+SeY7M6;Tq=OD8{p3_*vy!|fuMF-kLECu-WOo>)%Fc8 zxYGlfqO7B)yLlt1n$DLuwQ;=SceUT~C}zU8PAZIa?E1hR=}}?=YdaM<8rULzDg zv;qmL1yb$Wy;~M>tp<=`Ve*W~yIz3V)3d}aO9+&c)OV37mluyE-W2`Si_*w8q>w?jkKwW=)PqNj!#S zVU7Y?O3tPI(C+SC!8fztj?!C>XUi%qC#fLH76>r^j~l_J6*r@l?E9c$b1SVg(;Eo% zCi?9&k#h-SSGb+&&#@)VuTmrL)paM*|H<;B7|*44I!eF;h)Lf*ERn`JEcM2aG`O+f zpg5_i%>WlP}{@559GxynSnS$P(8Cl^fS8HEyj$$uW;C;F__V* zA9fz)I(&50uIucKs4%G0t1=z{-l`(NCVCoy^EU4={D~Ib8#{{E&YK&QnqyJM$~ZB; zzte=qu0XBshd8$~g*Cun73d)Z9&%YP2M#9G#Vvlf#q_@yevP@vu<=2Wr_f+mt?^K- z`0%%t6&h)w)BYF~B*U_w8YAgHFG zK)q0ZZESGvYyQD}HvY9SFw+9QSXh)^TK@>-`oZN0U?Q1+eUKn|Abf(Jya*2sy=745 zW@uhcIXOBKKyeky2z3=E072g8^vpNLcI>2XpXXf-`yYs)Og}g>lvKoF(f<=K5eUFUvA46dsTTs{S$%iOXra4=m!Z9Kt4c6fqLjwJuTjji~Ok?!G1i$O5w|!) z_J8-E|Nb6s#;#x>=<~BwaSD%@Gv0b<*wfID$(@<;0#sGx)=~L7?6NzVy#1nq=?NyU z=izDx2+(r3k?C~*%x|VK*!=WI?>8!g)TTL4Jc*QFsG^!N;v(A~qEL+>?8rp~25v&~ zk`u>8-vGoDg0Phh35y|G(X>yNfQVR2xWn2I2q3^LkDHr2`fm#EKf)AXyuxSr`_Z-d`CUzSjtmlXPHi2pm=w!G z((I&o*Db2i40J=v(OM>FPyl$h7QLyqkXF=hMKkchMbWAP#&&t_y8w&29VphG+@7+3 zKbil0Gd@zWcMAOo$QX`99_a%V!a?9a0HhQ997li-#1gRNUf70UA_ka*3_a(;8-leK z-}-=m(=50!@=e^2!VJLG5ekem(5Q2XBk9MVGoKg~SyWnGIm5dz7%D;?Y^YlQcYzPp z&@W)^krz5~7(g&(<@P$gS8_V(w~5A!=36^AH2-XWN;?24u=E{<8@#9sP3R4q6! zt6g;Zr0>CoWXwk1rs#eb((JaNd9;Y}%Vrf1MT%S$%1Tcr*)46pcM19(tH3%DL25OO z$=MV&JEFd&>h!%dfD)A1xg4>qk=gdfFj?6uVZuB0#dol@pKCm2?jPu9;|G9m?*DuR zW|6@m%q_oY(8D>Q-BGUqfcAOQ6$|G%&DFJ_fOe4TaKx{R`>8_RHuO&^DH__b`bfL{ zZzvvb<}hjL2$+0}<^xCWD!(!AtBi+v5(axqN2^%BBLJ(No{W@Cl-^GzASGr%W0OO8 zF!oOtblMnSiBD3p2^PjzFn-yTaVZ@aa`NVT^sdnP=QST9$#RMnXWQEItfGV=@!-Yu zEUv`E?PWN#7H0xvR+we6T7+(PTxC~6Cne;SyE{oh95vz20qh|IJi%$OGt}_3}2adbcmcwM+6zla1P-I)(GXW=jE=-zZY}{$&`x zB4ZJ$FAP7iL^d0r8XkEfI>`KHRLqySoO>8ZZ_GNS8Zt7#+oK}7`~R-kG7Gr^0mlWf z(f_M`!g)!IfZkfP1KNRnTZz}fu7F$pja8N6IlGR~0C*#G@iARr@SXtI4Vi7F1q0X3 zvsLk@m3rqU9<1LDm~{DCB+OdxYiH5h617SM%mgnSAKkRIo z#QNUEU4L@jiLUYqe45RQNWWg5*i!5RzLdqTKBhKS(VP#(Y->n`> zJ7UU!BW}O)zxN9KClFuH4`_}-S~^s)9NSv{&T&O{ZBG5-z}lly4VWQus?iUBF5y)1 zr*kUbjj;$l+I#w_gm^9bq~ARZPsAJS4UNQ6+5cfh?377Ed}cBa=a&LQ()Hz%*4e1F z0>n1ye9=+%_!Dg!Fb)d++8&vmek(U8c!zjcnxWYHyy6_{0li4Ef50bqYSzzV$Ilv2qTKyQooP1qyMrY&2G-l?5h-$Oj7P<8 zk}h7&^dC4SaYS+}^zih4Q@)|f3Gs6?6o?U;=pJU>9aVXk5(bPg(8>H%5y1}+AvG~d z9d52KPZqa3DZxTW`??1MiuYoK{tSC401uv^5WSfJ>I5uIVLtsVaK|Ko()!0N@Oce8 zwoJ-@Uc}$uSr9MmLXc-4ebRooU;6uvB@(%zRRL>bM?fV;ip56wXh81WssAgUw&>-2&&;*X2z}Sa^7N zSlI1n2V@BUdzPv8KK=tdzhx?>|SNv@*t-n@<> zZcC3psK0xBU!?U>kGWbsS6vbl+hw8Cn$FP+c%$XUgjS6Zn-X+KWMS$X`Je*3 z{j^f^Mh2rC*wp4sqg$>Q^j|-B{}-Q{{O4D7ihq7z2+GRJU7+Uw^c~u?t>HWU#>OTP zd+u)=PadoI+}!*=&f%*%7o4AA6V!ojMcr6NK5L|*waK!JT<&oc2H#Aa1%>RSu32SF zo(+C&`Jx>3Y#LU&fq&ud)LfDb*J;kf$9p359xu!DIFm#8UJ<20A(=!Qo`JwG_bt5} z2?5VUL>&i;VNiN&MM&52NcQkjm+anc@GR@xUhu{iP3Yi3kW%coHo{l&pa8>1_udeP zUY|XTwk!E|f#D$B6=0N0`)l*SXX8ibP>YSL59=Z#?YYPx9Q7wkGT-~E3v#uBeURd3tQx^X2! zDW&|UUz%~R>!`G|vG8E1;@cYC(dlQQx0`7+1~K`(yv(+u%}nJaTanyvZnD>(Ea115-bTEd<})#cXyVSX~%=Y%o*j>-lAmD#A_ul}0eI z-CU*BXhUwe+~JwvL7(2HqI-0$GhRnE)wXW=JNoJ(_kp@J*A$D*yt9l7PYrBe3>=Ct zw|djh8F4@{XRN$$=-efX`j^*dYsp${nQw;Ww7)r^Fx{EK0!sgq0R&UlxJ(Ydxwn_9 z$<(^ASz6UFvjTc#&Jc z@b)Lb!73)D zY8pbgdP5Syeo8*Sl?5ix@>lm_-izI3)(M9Tt#m4AGdIj;WX{`IQ2JAr1-*RAuE{{R zQY05U$pq&>Y%5Z4^U=+W<`#W1h|^MZLhwC*BfvPB6-(89Z5}(;D^U3quR;%LBtjXG zW?06mEMKpOSyCD_YV#qi$ocfaP4fhw*?1j3ET&j6sk6}b1s;q)Ofov0<`exVi!9M6 zm~(@&n1@=UY+JKno@U0e5N7AW4Z;b>Lg9~N%Ubts1Z2J_{J5%#l-myMRQY;69O3P? zI#}Lsje171FDZDB(9sh<-R4q$ZThgx2V^hqba6mtSm*8b0yWB_r)0ZuSIC*t^Zxz6 z_A@zZ{ZDE3JQ5x3)5$4}1U3&fAl}{bQ_+AV9?td9hgt{2qVvPkK`CH(K)|BIL__0$ z1rooy9s+ex4Gt(%NAEwYZk^Gle9bf=KBBYPB)(2iSroue2BgDgPXZrlh0m#7!h-`57OH zXy;L3M`2ufb8GY#kkyQ#Jl7cMC#7F#$G(9hEn@-P@x6OZGkL%Kp3BF&gsxL5agpwC?;kW*29PC9`!_kU{Qd%w>is>1 zt+R+98J$ThAlzbvHV(Zn7!j{cQsM46`SV!58C{pIKTt%bDUF@hT-D~6C-3dOy5s)K zL&%|&GsG{bjKmTU}d{rdGn=k|;?3jvI+TOBeq;a}zK?M&%!ahL@s z4q$jnf&Xds8IMD!*(m9~VL?F+$xD#<&0d7vT;~li+emeDJw*B}lfN3)RD#u%BBN-*w1(6r zd}`?%jj@YLrFB&F69|#YD8D^VA-+^UhqbeJq>TGYGNs)|3LHJ!%L0ubm{a`{cd~xJ zQxD6ETB;$0QwIAzc~Efwuydu*5R_b>Ej_ML&<~)bj_ppcXbrWmR&{F&(=tkgOq^v2 z!EzsYr_>!qjurT@cvKD)SQ^bE-`G}0&%eUkuYa0Mu^;efYs&5hSy4GH39MVbRLsIX zRp8U+eJPI;a1PS3?|b~w=#e0cjn7l&JQH|GAXATX=46!fYo~;^ZkU45Z{X+Bxc+k2 zxm*FR#kd|i_p+r>ZWv6vEVw={hVb|P2)}nAuw>i-oaK_T?Kj_n~_-)onohrC@Jx(&K zgc}FK9n8tP%j7F$b3J}fKqkC254(tJOM_MaGGRx`=3rgy;jA!YNb*}@%}P0OKDk`N z{<WUJNkfVD>CmlyG1jfh9+40^3N5OraSVriHcNUF#eQks#8sxnXZ5VP z4YB?WZlig6qfhKh3URV1YK|1Y8ER5natVLztJq9z6Yx&hc$v@mkXAv0+=gqXIg-my zCct$%;d%cTnz)y_mMZtk)EAf2=e!VV(k|)Cbd#E~W(cZjDy+$0LRxmG_R|Vmp=aN> zhGa*6b3X=SEJomj6-U*JiYDllKK)s#eU%vf!F@YBk)#;Ifa~7!Y*$ox?{4U;hOht= zd#lDQ%x>aJvYy!Z(oZJ}PlvwDdTnj?Z^1cJgrCc|_x97v*7hx5K!q&HF#LtwuPHJk zFF@^Nf`9iyzcvG}Kp5C01eBDVw>PZocVJ}qtW%84wD?aJ;1DrkHS)p)aZ?5Z*1Y#c z;6MG#KrQIWB=~rsBnNH8&A0da2kJv(`a1%5oVvwVX2W3ZJRc;n^-WhgI+)l!Q+hVy z+b^!;DDyr~Z#g1B9xHvDzHQm&NZJ3>*PH&mTtid_DF<&7uPa8OufOIMq+qO(k!%;;D^q0}p|9WM8T>7zhEr+qtfX6l zm6oc{*{?-{KVnfsSgZT78hItRNOJmMskKs!Oky%rh!5dGr{{#P{8ppA6*G{qF#Dc_ zn|?mQ-V71)*)(&R^qiVZh}AjtmEf_E`D|Tto)u_vUTFJiSInXqdFm%A;O!P-c)kwE zWa5u2osOa>W9Iul@J4Ob=H-XsXZ2tQ_QS&Rs1 zhy$=pD%(QWLbt8@*%%lXf4~3pUyV49I?f;xTYREP8J1#A3tyH{M~8rohjO-MpZ#?D zDjC*1wyY>CmlXGBM(knnG{E{Ujo$$uQ!O$6UcvWSV*u#vZrAVn=d#_hMRjy^R8%5E z(81wId!}%#5MswxdzbFiBDr}d9dGP}bx2+?DSd{KayhL2nFU}mdwbSClZAS+MoEGC znVYU&*?#keL3rge3~Dv^njXUareR9$hVcC8?>P#n3bKKY=b6&J_K2EkhQv)C6Zivm z{uubf14g-L8*4d5+4TgrU(#hAn8?e_w4THe)|;@L7vRV~nM8<$cu~Z(3!gcC$a;_# zg|QIKuyMjTWBX;)>|04;lF^m!AKYn`-%r&qW#VW8w%Ko}HKsWV1#DetBPr7Y1dl$j ztmQnxrcWgE0E`PainT*Z+-S)k5;M3L0>@%h8_1e(qFiI9nMji*6-sD)b-r!#KUrC} zrD#y!Rv7t}9qdLIQYJ|ld8g^q#{#Vaf@ua0rJQ6c>&IS>+w}U>&mp53aWmvN!eH=-UFd3;>)!QRP@~&m|<&oLr z4VBbqOOvm!ZU6c>u>qQg9YW(G_LFbhIrV;yk0E>oy)wo?jhctUo^L)zvLs7(bTC4- z5-H3iX>YzjDKoef2-;Q#DU&{CE0FcuJU+--QEAspBm6s%bBxS7UKN@ZiI3>Iq!%83s)u?N&qnwJe~ z9AzG(4(#yL1OI}^co~rhWvS@AoF36P`uWpgvpL@Vqd!c$aqLUz=;2HwAH*A7uUSKr zF1&MdmWvUuVRTA!U%ap0o6}U*;z~-3fwucgV=oh;KcpI&x6vWq*wjC6QVa55ELl$8 zI8+f+ZxKQAN;tR0Mf*QZ2q_b&$;CFYVP~AAEuviv!Ruojj?$1HJXXS07b}y#<>1Ezj&qg7y^>_boKe_JU5HEw!eG@ z=5cfhr`VW{w*U>?Kb{*WoNQjcW8K`|AJ$T`A0I_=?lL1?-C2~Yk)BbiP1Q5-!q#OG ze{15XIXDmmYO z3)hF|3xobn_%FFvZ%gkIJcn5^DoDpVkq+sCZ9K73bs+YShLGFQW;OEMKT)u)CL16x4>;eDQ?MHqHhI{fjzOLnv81BL(2&=& z^LmD1ovEM8T&{kVAhJujGD=3P(CO!B7)^MCQ-o5m5F!1KeJy79aJUrn3wAf$?YImD z;U|c~L@scQqsR+>tS$#~Sn1E_B8=hsu}`-H^_k2+#f7gdTd?h@W03S{qR4aEr(NP{ zqCDN7z?U6^&S;J4-aj;yaHgDO25=y0Wm&xNy_B^oQl%gRqH~Lj8|`n<+gJL_D(LF3 z(eIpA+y6(`dq*|7cUzR zE#ed!LkxQi*=v6~Mx2kTyww5Qpe{UqVRHjBGpkSd%~kzJVCLKv9Kc{CVl=4J^&W2E@kS(>D@L!{I6aB~i2H>2q)v#-;Wa z`H2ElDuy7J!vCv>&iO=ki>{f7MhFSm5Ti)Rfo#I<0&@P5Ge(a!Rlx_-M9 zPR5;|LMv8l!o{zV{JmFGaoEdG-fk_v5s4LVi#xf;_$%ekQlIqBfdTgsk#ogd@gED4 zyFULPipOubaxPote?kKuX2~^mhx3J8ys&)ld|m({A<2jtyK~@uPEx*k{d)U}oSE9` zvaKy-3&G~ON!)B!_v7@;um0et{gq8qv9Kz8cs@I&>P(|Bc}r(kff-zy@I&vNpUb#wo0l$pdif{K@t0+f{2ki; zZUgS$m%holNc!Dp6+Wyq_?^3~y*cklF2Hl<2I@bSoqUIk^_?$=(z|-TZ11-Kid^2= z>MmVIcZJ1l$iSdm%gnh#gEqpcqnmn5P0~5Qn3{%-)Q#ho4}QG!>kp+AfobvsIA(3z z`dF}aGB~8JFsaT(00^l4nblhw-!dXPQ{ys$(_-G#-(pqa`_e}OzEmkj%KHK{hTF{4 zftHeGr)$?oMtEoa#(!onMXAVzyXGCf}r(bRxVJy&VgDD{U<%O81lBu0%3bD->CFtoV+^Z<@%K zLMRVU92ECmAJq5JrzjyTnYmRebv8Ryulq+$vd^Bb*u`!lTU)&dzEg66)iRK0TUtvV ziCU#ng_?D#S@D{T-Zk|`v0XZ_O>9Y5^7W*G8=Szb7cStIVak`I9)1}f70I$5+ST%O zWvMck$)7bzCoV{|zYbRG>4x6(P_N}!?(}P3GN4D3{iST~a zq8LbO5~Nw-RVyxbF*q_jTYy_rJMb;(A``wTj&ttr5C<{`7D#3r&Hgvh7Ze&muZ7#NUJOn^@M4gWky z_l>t@p9<*zslH#2AAJ~m5Pqb6tn`t8lTOO5AAHTs* zq&y}4xKJn4Iy=g7y``;`bKsnp10AXr-tjGK?4pHkNYUA75~VniT~Re`chvW(ra?TX zOz>#qHlJWmyxy98&@OtRL$gcodG4NlB0TA7R0B-@XWC(Py_L+@?l_FWe%2AOw@5iMim&EB{=`inD^88F^XpJZDShdu2*(nTNM|H zLQ49W9AA;5L)JDEesx_`3iMQZz5k|kqC4IO?X^+y7`qDMKHT}lwq(m8({T2QrQ?gn zwHPSgkGPD>D`E6jKB3K#uej*>eB$QzI*X6lzR%%Y;Oo;Se_r?4qWzrBrPN)w4B=k&ukR)j5%tLBD0q7gPE_*t>|MY4@xvbC^L;E(r zI%xI7W?xJ+_eO%NQlslkQ<`D%lsUYvUy6Jayf(C`ZUe3eTx5<-?ia(p@}YYfz8Vl2US1n^!QiIhIAzuCM&n zpB-Kt5*ABz{T9@9A_Y`_;I7>frX@p16qN@aM>wREF@$VqIq7j$V^vGWcS_@xRN88v z7BM^p$EipnXlv;FrGeq|ThWr*8Sog|ucpEqeX-C=_-7*wI~Mkw>(}nC7dIGb2-MH8 zucOQ0Rr>tu$LAP_BU29~eB)cvNWzwRcmRIG2&|&gV7X=fGVR6};dsvd$#v8P16U2l7i6<`Cn&=>|u`5e}m-Iz%@kU(JG&^k*tH^_r#2q#^=H zs2S`s2NFNsnMEDWCrjL>eKDCnG1(aDV$gZMp4!&-A1 z=ziotcY5)n?gV~;L;_+t$)ZeKo>c8;@25EKp;Gdf5 z`4G!#<)#1SF8-Nf`ES<9dHTowAoHY~gt|iSykoVBT5s`m?-|WU(LVhB%we(u9m7<+iIwo>%!mPfLH*WOR@x)*(_K;#9t`2Qj1bcO{(q~Vv z9U8v9Q>3`-IqN{m1+PlC`iIc415qF^6~F$U-M(!)Bc9f@GzE3x$@^K-ZBL9RM@zE1 zH3!S4?L8OF{plOnkAI~e+?^<9AwO7KXmhwaq!s#=@cBn|LQs|7h#r7-CR?R)iash* zS+*g3Mm#aWb~jO*!t+(~C+~^C{OMw@(xzBb$>N|A#|UlHpW(6!=R^4Ht_2f`yn;MpnHB-Wea*Z2DyAL=Z`-R?ja>~+ zvs!q|PTfzpTS(R4s$b77sdJRzsEar{DAv01==9x*zKVsL_gf^Geiv{3E9-=ckoUoV zhfo=2A>>%_*~1W*_L%bzJA>0`@YQR1*1w8A_D}S~!8Ll7hkIs&>t}v*CQ`832d(IK zekM}r5xJBzmIrh69h$Mjn+?V%5O|f7L(cZI&w`xnu!LBErRCZJ8;>ozv2!)w;28+) z*)L+yDS(x80G)p%zZTdnNmOLHDcXzKid< z@W4#%0X3S81`=$?gI}=m!qA+f-t|A2xU_-_$5LhEHQ^tLbKlI4EuL~rLGCIzTMQYR z6bBL~OCOgb^#n|-joq{nUJ}yoQza%dRSX-6?o##VzrPC1Guy6lS)7~VIT^1jxZ47% zkWu`in^hWd8D6SVr%^Ocao}VED72YwbEM2Adc8pI7p}$VSOk&{%MG6xlQZ0Ry)7H8 z>tli_ICiV~ru3W{QL1x9v%I%dN6m*BOVWU|={Y%gIR~&4YcS z$!5vispRH*=8kK;S&VL&A9nd_U!eB6Al+iTzLT7)&FUjW%w|a{j>mjAR5y#;;3lNS zVg2Mfe_})EVtfKWF0^!VOrVHK)pAicYGC|iI@}&RE8@%~;@l5aI)q?YS{n=?rd(7Gf z=P?5*FM0eM6}eLYWC8oy#0SUcYzZrY59;~?do)>i6jx6RwHY)rV6`U;W3f6jvo*Xvx zCLF$IE%(DnT7@FY?{Jy0Dl4j1)Vn6b#KLP5)VKJAK|>|?LH)1&haXsVA@{?K7g)qn zW+gTsI(TCKh$5&pY!xLlK+PZSlNfV&8odGeQQg?;-U7{>iy%-@SqMBzF*7r{P5?Tmlgd< znw;E0pG`I(Vurl;n@YZaQn>`f8hs`VAM21HYYQir7OBg;ZO8fHL=hU|ko&XCl!V;jpL{6gs^Lrxk1)P~~Deeqh;@hwN*4LUX2 z&VCe$$F?vqB8u8|6RLPtqdoS)5V*?Qbc};r^4$Mc_qw4i9QLi`QS}zn{MgMk zp7ZQrCn^>o0>Kwwl3BgB9{PFZq9rfwI34aZea$t*$FGUrpGW>+5Hi6!?W$PeMrM@R zNJz9Y-Fa(16_a7GCa?JANqJcOMw~~E@%~t+b{7W|K($_LDtk$>p3HvzEELncbTz4Ykj>GbA!pZd^#Fp9(=#kA=M6 ztfeR-(Jf&s>)fVnD1;HhCFI$ZZpHqqv~}(q<*M1n`94KiFR#e(WLa;vyHD6yQJ%F6 zQe|AzUu}0quVfEa)vu4C1WZI;`GU9hx=vM*CP@N1!iY>;H_K?0M!X2~*^h!8os+Hg zK$**dA{=vsQsMX;90(iG?)D5KLw>e-o%UY4s0>h*HM*7$=sL3q_NWx_7p88Rw+{Dj z4BZfUNg1N`Gq4&1q^td6vskpW%H3G91&lXN{GyNO%d12o#oqFJ(M^n@${*6Rlr4CyK_oLoB+oZ!Iftewz4qb(ioF!+y{@KlU> zQ|H`8ZQcaYebZyfxmXq7FAooYEh9Pj^$}q^z5ZSJjTajYAx=QE`@Y41nmP$q@MhOe z4v#3J$Y)!QkB?3akp95$nAw2|ua>{`_0CpgAh(5zO{T}YH^jAbrr*COdgsF_3!3M; zTq|bTeHY&OW&cwgn#&ORPcvK%@xMI81xNPtqRI8^FTcJxU-@%|`OC$~jI&h>cQY8> zIYBz$w~E%X*BQedyPnA2Aqi6(Rd=UO_@#3+WMTKK_+2z#xxN_NamY$4P|w+foVpG%S22#7--raqQZ0Q;n7GQ z;k3wW94k|Nf=aI=c}|w;L_`*pC%T%}4^NilT&u*vy&Ir_vVCubFsJCRQ%*-nYhsNY zuS8Je^HU>rdT$}P&r*SyK1*c-0r$3A^a$L7jik*KPxYwFh5t6DEsb#M+^Ki%sS1 zo|`$OU#9?8z2EsG^Wk+T5xq@AUwbM?%B&pwWQF%!NjW3$IRHpWir-An!BVnnwlt)L z%*1O3MpsSBht~~*&6n7Yro-LCGTnyax?K(EfcvH4PV<=uG3Mg*sWrn@Z&Eu_FZrFrvD3KA}ov(El;lL_wtk_4`i0|)w z7Tl01hkw&=j~poLj1$Gawwn?k;*fQ3ssJpB6>I=1dFQ|{s_ma@q`E#t-H3KeHEifU zD&ZU|pLaqVHJGVlf%ZiqI%RS?72~d9Q;}LGoMK-M!(YmjEticw?MFVS`thqO&|y~H zAoyEHJ-E4A414rC8tFR(^;SXlH(nKsQk&TA$~O_f^{9hQuN} zeIHnAP+Fh|l|QAWL~XK!D>eVvcZq`Aj5;mB_K$P)`E?)!%ow{Cu*k7Sy!!pYD+*{r~ARJ`Egh_waUM_5Nn;tdETT zJ=vv(QW=XlU&*5I2hIP2U)x#aukm+wCZ<%Oh7iZL4=)EcOfshy*QXMziPkFX(Y`s* z*|Az&ZLfHF8B)1|)EH%hp`nSv>NYmE)uYot26}qxb8X93-u7$;#tL&8<$IqKzb964 zD)$#ir767GHQ$`pSNv!9XXoLIRX5VijH_xszbvhkDsOwx?6q{6AJL@@EOc0ZI@C{c zzg1J^5r1*d1~b07y`;hm+3H%XM$vxNxHzN-C|gy72J-!z;i}DLo-m#zB{gNcfQ7Xf z6Prp(=h5~Vx#(f|`lQ6!&l*r5Pqtcf|ABx3zf1)O{>%7U?^QmVDysJ2FBAx7!RJJz z)DffsVaR7ma?tzfN9fVM4=w`6mU88%jdC$6b$bg6V4Y{;5LZm{)u&9Xakj6V4?ePO zqO3RarxJB@j9rMe1b1!;6Y7gT0WiI&awr}hk+?f+Q?jn#^xJVtIe-Y5$ z|Ak(bMIQqp$BZ#md)T^Cs%VrHj>NA>fAbY<9X3z58Yj1|B}?AS2Y3DYi^Vk)ly^61 z$;attmd*KF?R@H&c|KODf~>GTiLx7?Xp6%oFo>5!K?zj`5(3!6rL3|+&!1Kc60)b~ zI`1_1lv!3)HBi?PwqNO@c035x>oYLmq50`j-b1HMfv#FN*1x_wcg$-7;qSe z*J($GpP&fSx6-tLT`{TbFFtX0L!|D(lO=Qk)FT&?cbCPm3*_^N1p?F`&OY zDAU@`qWa57MP*H`Q@%~gfQ*f40dB)(qk(tl*-Ws3rh%IhWu38ZphOjfPsQ;=&CNUl zHy6i@%2II@tCcMVKKNv1YlCn6o>)1+-4tS7?#^jpJZFMB!ZoJ>rOUomnoq?KaR@%E z=brj(iHUyL#YTmA;?`OO$(6Vu_0n`H-e5b!Z6q`OK5XZC$wHTGn;)J?$c9$lqf4@lH6-G%R$Dt2d3%r@tK;tJ_Ee@n9Be6|mH zLJqeHCu}tk5_3=1`jZfeo}vEu{XFor=R7><5Xn*w5}$88$)m4E?Vlc|_4UygkKmAA zC%80DxvE)z+RkC$NlQhpV(?05uvS~oAguAVliz&zdw%+sYv*Hkq1}TIJqQWUUp2W5 zf2s7iG2^ZKTn~y2wXyOW|IRPukUo^#0>ph$DbEnB&Z}`;-R&%7*I_%S2MVuz-`%d( z=W2ly2AiZ7rxV$wohj!mH9~c+qT9sAdXDoDHcuHc*Z5VdyaZsGT<>z2+CZ;Kf+~mY z^%O7mMbLu2DJ;M9IV{Sgh{|0dARjs|pkL(XxI&w?~dOX?k z!4^BKg?pT<;)+c^-uBH$QBxmeO>UZH?W~ zD$4}0!d%J&H;JKVlfWuCPwY-vP9vK`I^Mgb%*3&)`C}G~l+pq7vf#Pq6^GRk%T_1% zop(t_@G9G|T&oXPBzgcAH4YQ#EeEqfE~#MB`!tamF}x&TeAh{2zsk1RdouZOTgOxk ziuA>0%fvc+akjXd_b;Z!rWiU8bLU9AO;r@pXH;ROT}*$ps>hmDziRfJS$#M_sLqlJ zKZQ4>XeQ`qqTKh#8|Ya_ZXrEsgDbJ7p13A=ukqp{5!pd~a}?n8bjniB)2i8{r`y32 zNDc*!Y^Mf#S7CO$Nqi#7th^Q|((}bC1*6NnI+!4ztsg2La8FCb_HJ=RbVN7zb4;@b z4t{YngA8j7upN)VZp!7Mk2X9k_wRXGAi^laQksdLSfoF7xNQzZ#_yeBTG+m2*LE|} zRL;&?$!An$6#jVdv$HT?f@N=!MitBTH0^sYpDVmn&=OBdwGs{pjQwP&os?^xr_F!o zeR7-*d-t-WLwBo9+(Ri2a^{($i$u?QfNy`*a4DH!ZcsOa^T1DIzyrC}4fL`8u?Bg{ z*1510i+~N?ss{vG*G}^LxZeA#zmk@|7_mtvkC3c5VG9|?nKpN=M09nO!|$F3^x=LK zUJTZx=85#SWOLcx6db&k;JjmyN_y@b<0m}AhHvuQcMqBFnyejUZpr}OD^AJkp%>?7 z#5c&TJKET6A1)4n8L!kO!V)nouPLvnRw4zO@lYX8-Y7p8>be#VThjx$G!%f4+S)LYVk{CF4Dg0lc!r?wYL3qoWWZ zLz9$S9H5-Mg3rJK{JpLc4giBC!M(+8GPPaj$!=~09bgBpmAfV_<(1V3kM;$l{GP{? zx0+lc^=i}9{m#U+OozMQ8EMcb{-O?YWZr1T1gS4SKW(f|2yv~fm-<&rzDrH7^i)TX z!C>K=D+B=!y@4?TFXdK^Co=!c_;FBc$9MTC_Vi$Q73HrxZ6*AQL-+|)&w5(Ai~VH* ze#>RRtcpbEopISwJBtH30%`RizTYC?0d-9!7M;tYx^hmDa_ym=P+_Q(G|9yUgaRrL zF51NMLVvY2WUpjyaB-rE#drDx^{TMJpin}tpT|fqd2uG;xjCiC9S7gKKX<>K>+HWbLT?*r-fX9V50j`O4z1t>oE<8jvT(J|Rye5$Jsb%zePKk1;T zv--l#dhxaAiaudeDHnNiG8MjFA)uwk0q?hAT0X#(<=P{E(Q0p4xaBrdO{I(&9b1F6 z)I{Ma7&mi?@FU1(t#l8W8my{CqioSJ$_s9Wz4>{ga&psgahS>^P;D#cHU%V1{a9Qy zJeoAV)>L5m3AL~tG(A1-dAiDaL7JIi*ylYieQ%WRuX>JU@BbXi3$vGZ)G} zJ9v6l6c=kmNO9#WeR91U&KEyR^AisWA{!igDF$y6$Nq(|8;bc^Z+Y4+8Zbb-X<4xL zoyACifoh=uF6@y{`Ml6V5aX@!aCh%Tn}cb4Sm1E>YQqpXqtd!@?_5ZVNjxjqZuZ^4 z(eXR85x8{1Hp`m&VF0z}Ou0TZ(@DsCbO@QkW?qbD;ZQ(-(91m!2;*0kCgNF#ujdSj zGRBkqU0bJFHBaIpfPJ@3z)?NOiYhTqaD!PCW$|KM4wJ5L&hM_O?(oTO_<7P z($Q2<=dv26BDRNipiOd~n}KkTT9;6m@~`RqKV&p78#}J0sVJRwtWKHj>&c@WbiKw$ zcRKA5hLJWpYhbnRoeN77VqppTjftl_qc?%p3J778?}4OSWkU4`QQGjNc=_c%vQI%r zgO_R^-iXIY*Tp|()<%Ept#heXsXRYBRAnL0}B6~D-W!Rz?f|%poVep zM|zJ(Wx&?C{Yq^~TR9R{TWSprIonkunobh9LD^3YgZsO0Pj%oMye(FH7xVaicRH!< z#r&kYTIIHk;rUxWG@q$I>r#}u)2cGVJKAOKi?OSh%1fe}Ik}>(U%vDK+EhoVw!!Zm z#5yR}!VCYZ*ybSd$P0AeJwA9p4l8$`uQ2F}N9i7=1AInx8vT$IMX5xx2ycx)2W5FI z$NDmL>GC{A?yG?Fd>h?V_@^wUgtJ`PU(*Yxa!jFteSx8Oavt4n>*sO*A z;nV9s3ecz}Dsdyzp$@b=06GQOsuc^BeU!G5l^F?)n z1)~IK`ofVX{Dk!e)XokKb{;^s7rU}$ zJUZ=ufF4Ad-uwNYbxO#~%iFQ4;`)McQX%sFY4N$XcHH=nwvfHMFac}2|6v{$4F5Kd zBp~mZMs}T>r^WTHbW~Qz>wNF@$ccq$)}+{Y!3wqFa(2A;_g`9;0{6_bnl!w*9Z@}l zp<0cIq6hA6XS5Gq6j4^|)=7y(cF?$Iu#LWi80^rf=hE@esi#wM-(aokQI_)7KD~g+!YoWfmxYP{5O5S%-lt7e(4DYHo(F+Wk`?w;a&HEornA01irKz;>oGAy7 z=J7?0@b4pGlVsdjJ0X#&=^JL3m|yA^eQ|_)Bb=`W588(C-rFzjGslUIRg`?gvkm4N zu>Cb8q)ZLF$2lGD;gNTl8#6bd+A{NMMgqaB;`cTh*q0?OP(Jh5%lB^ChwYPpl*AG= zBpxUo5;2?cs!j?<$S~#dZU|f_bKT4_ttg>`N=GW1Gt@n|1A9Sh0nR&WeF1@clz*kf zP#}rUROvpl%;uz-3&Pc+n0hO1YQoh+ZYkTJtf_S;y}Gg0f3#{Iik&#pW0X{UOwhhO z=?e=L1|K!7=jX3C3-ld1PunFO8das~wz#NLUX)c~P9I(bIA7x8k@qb+`--`k$g|-z z^s8H8PrIr)DAsF{jM6FBZvx!v+Lh6ky+vSk3`GALd>H%1A>C>DMTDM?KJ?(!eF2dZ z$2M~R8$zdsUe03AY>Ttm`6*B@EZ{}8WGNZ34dLl#XyS38V9SqDF4x-96xV3^sxIS4 z#(B_y2))~f&3O{=*2nv`lgpEP)n`vvTWL#svYX{}f!_T4C#3IhvR@T=53_zG$UQz9 zJ4jH16wzE{?>{YDPpQ_pY+V$8FRbls8U0a8Gb){nJ!BvKH5q><#&}ugBiCU4mfOqe zVT?-8;2alwV0~P`4q_jKg6_v#Rg`$*XNIH8HPVLJa}*|@p+`3MH$1|pwKTPo8bS#$ ziJIoU*Q+2KW_@f6m0m&F@6))x06Jy$Oq`NF@(4ua`x}+>|^O}&dbUyn2Z6yOuhvBPibw!-k&Ehzvgzy3~ zTGxhJ4QB5Yhsw*04clvPG+&um4C?4^=@zf^AL5#nSr^$pkQ>k|<{srj*5x?Q6BM&9 zswUD5rCfFi!DANmK&pbO&)OO&>xf=Zp%_Q@=I9T@F6 zQ82BcFGNN&3Ti-vs5PDC1+>Kq>W+v?Ddo9^i+c4oIbwI7VY3gAc>evS5z$SkWaV*^ zovpLz!Jt=144LQjS&M081}5nz)P}uHKz={&>}a)ZX>&T(D(>0E?r5MTm#i|-@pXHa zc_|cF;^A>-Um(Tg9EO+=9TGmS&Qx`7T#c)4)8U3N?8emb~sVVp9z@ z4#^LH>{Z=Y5~NcrDxpF3Rh)zjKFoWVgL(iy%tTJbu`q|rog=BqI&azqL>l}WmVW|2WaG}rYJ1W zPEByuF46ig>&okNSYE+v$Rsp*?jS62p9#fI2A);VqH4Qwx}3)8lY}QB_?-0=VYH*J z=dzyPSNtqK5Jo%Avl^oxVBD}aAX2U8zk?q-<3s(AS(H!@#}l2C+{Ox`s(Z(h9Ry7L zXoE>)SH5UD6lys4Q-*MPM)D7W8PPw7b6avZ;H zohoM+_;ra!)VaNLU-tI=6Y+}cl_yV4=+eLHs#ztZWUg{O6ms-z zjrjiaD+S6TKmiVOH$3#rHd=G<0i@U2_XHj4CqUN?-8XzO_u4&*VNp)0pckm`m)hXE z>o<~Qx=9wi9kCZ(&<1@V1$#vY%vI)$rxV1xE}TaOSxtd8Ctq$l;2uvvPs^h!Py53V z`yb=2k4XnlM8ea6ebb~Lkcer1b5X`y%gs(f%U@mZgu{C)T~x!r82PNW?j;$88jSc3 z*=N#u&RG5HfSUgY$cVvxoX*sdv4wVgVr#e$sdJuOe;&(s<+4-Xl6X=4*SO7a3E)AK zC#-6lWGimz(Ij{Xd96Mjd)AtX6$B*hPxn4ZYCJkH0aieUS8LdZ=a{H!pzq>uxJ%xP z+S5sxE0nzopq=ZS!+C}yWP>kj!^f199-Ga?-A_*#@H@Ao%rO?WqkB+ZV;V7Vi;0cw zIre~lQ*meG@twIx=`-{GEp+d_IkHYPw_pM3f91%VyZZa>HwPMZAm+;s5=*dd_?i+B zUAT)I3O{}a===Et-u)!@(iOGPnzCSkoZPvME}8~(H~*)hJK<(G201+(&ov;9t~ zB_pBO;S?Kw$bf9`oDq*SMy#`!FaxuxJx6LsR1`2i_?FU|P26dlbqcwSmKgLcmtcFA zU1gS52KHF`ST}yh5&i3L1!LeY+ced{hLjlqK;b~(C_D?vJ4lq>d^}M=a8p$&s*Pv) zon!^9dj7nkzp(aeoB&dNP@%66j0fnJ`LD5}g0{OlfRakLZp=N}=!}$tmzM8(AL%wW z75=1B3$9L4H>O}bMzN4M18bqPtUSJ%zW3C~Up0RuEy2C~UIl$bt;$2(g(K(3#Cq|+ z4nyBQdP8IQ%DU|R#fX=sp1>?vqxPZ;HXE}f3L6IR}jya#Q)99x;;q-)&>YPY~AUE!2v!qkq9<2&z4n zG^+Q;F*BDac5h1Pf#ht-3JT~c{}XX0O8uKXQ=x&}gB;leKa~c5mzc3n{+4nN9}8qD zS$SRc&k(h3f%FT=^;DuxcRdnvCW#cD{Wnd~;k%&%-^tnL<>1y&lQunR7XBxP`bB6lZ#R+CuED zBn~A}hx7V<=l%94m);Sh0^0H6Y9R;iWLe+l#r>u^k@-+`){x10W<8ni;d%5v?OVC9 z|Ke0_%9(Sy%byd8LvGTTB>+gAp8zp^8l$jdeb^LS9z=PF0GVdUv?TnIe*6bud9YL8XqG$G4pBg(uvbFG`D4JX8x; z_DA2UmzNHE>e#(kUA|^y^l&-hH=@zg8$zRR9df=nKc5#6pZ*K3yihQ(QGJ~vjSDvQ zwBwTriMyNwzvGX7?4?a|9u4Fu8F3XJzxMkus`C7IqA-G&UK^rlQlT^rk*lsFG=>ZJ za}eJ6ae|ZoCnb(0{3F4)GzK5~!+#iX7cTJk%zwNh>gP8iMMQLZU4eU zPFa9a80t;c1XmKj&A$2N`hSELDzE(8+5amC>mFuZOr@YQ->j z!S5+?E5AlaxarU4vui~s(CzEdC&EH*w}*xAvu`T2Q~q`KqIPEd=>%i(pjI5L z=Ik?o)^1K`Xq6y<;ZG7198~@!?{7Q3yEn(GLE1q>S2J^$eICs5E%o*`CDolU>EmHt zYS6X6dDS4ci~pj&Vy^x>Bkh<7QPAhl$dk#V1H5yCi*3kYq=CW4rFr?&$>TGVx5ulbA?uL47%#JpIEBHA zE;{E-D_q%*u$Ibeo#2LhVS5v^7i;|wWoz5- zoqP`{iD>%M&gbBVPYEE)#xmK{VX1~kTF0408-s-IsdHcsPTCaBomkY00PLJ5$A~p+movb0h3WtOJ5tw&N`63biY%b36222mLAZTYDs9?%gc2ZsD^-Itz_129Y zb{_k*dMgRLVmH_QcO44!@0)bq-yJEqLSZZ%)KTCJI_i|vs6Ti<{G)aZtk$R?JP@s3&!5?ASr(~(Chl7)O_iX zb7$=y(~D*AM-8{bFU~*tud?qWg(>B>bz#Y|US>@|?|W|~H(&5u`-^?zX$< z@vWsG@Sjj7^IxHCRwbNrWOo?tKnI#(S&*%mo4f$DII<}d_!@e?UPH}hj{g9C^>8AA zaxR4FqRRsc%~gj_yCqF$Syj>pTbS)M2xm&@duBPaP5^uj5nacVas>A@Hdk9rQ@}JS zzpf*0i#cRCkxRwDu1mRiV^_f-LHj@rj<^2)`zn zUtuz?s%mZuLGZBUUwMx2-PwkNH8ER9{l3%(Y<{(OJH5NItj)6SpyNL)GJTzeIETkx*9 z8EyV4H)t5|l>P*P=aX+#R8le2fV zfYXFw-I+rrnRFe47_JT9r^noU+_f?{KulR|?y8Wm)L`do|77NyFlQ*daa7FJ)=rxK zy@r0YQBSq)PeP-|X_c0cTQ;r2i$1ZmWi>2G512hcNj|CIcCa!mmggsq?+r}G@%O-{ zBdnfy8q|K+8c~FqMVE{eHTYje-AGmtte32nw#pQz07FRS;SJ7S06PwU7Z}Y4_JPdPhz)dbE0y4IYP*mfr+YJ2CO{_VpoN(lC^7>GL_E z77?|E%^#^F6saTF9X5@~8bF`x+}hawLJEP%&eA&M0|y*H&Bw-Ah02-YhA`gg8nEn` zJ0R&Dxlyg&^Mq!m9-(JP#fALtshrfY{w~P2e^s>4N@aoqtZSw6#>r#T@kWQVq5jmh(WMEt+#1`k@w*eljiW)( zZ{Y3~iR#?(DtT;Maw@0djQ?fH1uT|=LYv`Kz$MKiZd>Io&SF@le!Gs;_4H`ICjzq= zuB>`Uq0!)T>czT2^*ePEae6{mrStMUnPu&O?F1o5zTgfB8y#94z4l3FdMkkH(S@yM zaa&n-9~2=&!5VyPuMkCU5F=-RxqXfM%#Opb++KgW%U~VONltB2xd{R4%dmy5hiwrv zW`=<%4cR~qKVwHeBG6Ra5@w(AEQVaWHxpu|R<>fk+XcNkRR4tGY>VTxu)XGwfqso3 z;w{wo)3vW#M|D<)f@}b3l;Y=~wJ?vqPbrIHI#)47bKpShAVf+q;W-TW-A&ZtI-(O# zPECJNNU|7Hsea|4r!DumdA0BE7KLqaQ0k}}h?5Fyix^UDag(}HNoDlQl2JLIIGe#4 z4R>zXeu)yR^W8}iBW}mmujWlC8W#tC{z;Lk$Dip}1x`xvHH89)h`$JtP2K^y zN+Q9_$T0o7FM9Lu0H8$btJ;JxWC@N%Qcu;rk`k7dE%MUoPYo4{? zftns3Ag_X7d5o2kGTMk=+A8W~b(Paxtz1{?0X^S>rIJgu#Pd7&vDJP1fKUcpQ6@`hHfURyvg=i_AEV3!pO`3U~E>NRHe#&{Vu&pZp&l4#J<{Ldq1dobJ znk2dKC`M&N^}M02%h|9PGd2(DP$_mv_$ZsjE!F8uyKXST5+x^oMbWbvr|fjN{rIq_ z!(fcA^mAmVox0$u5o(V_`JRP`E!52w$Y{Ea$ElmYn?t>TrUKvJB_NmlV_oen5&CZC225(gj553=xWePA4uqO0xL2Y@* zUiG=gEULH=M`3L~EB6SWw&yaKuN!i-6yuF;XUoQwQ}{;6}&UpZG=2N8wwqCjj=5eOGp4&kTFBu(7o z3}=(O?kx){%+UD=ID0ZM6=ozH6{)lpaDBZo_t4(VByqs3VO-z60#n2j>iE4@@@XRX z6081D{nczY6#ybBcsO;1;tb%18W;KVd91MzN=rH|(=qa#x9sbL7Gblx@a}j0By~_A zQWc~3Y0~NCaO2>(7V~gb&I{$0Q6c74qM?hyLZ+J={P=iCWLnr^#+s{9a*lR@Xytqv z`{fCND7?sxQ2-^MZf7}15&Z-$xS&b*h%#HP&f{A=X8K_@cJULFLQgi;-==`{8-#Gu zLUSAFtfU{z;A?<7vGmK?fcjjoG=;SApeHpbtehfCMwAn`7W+dLj3km8s`b4nndV3l z@3M%hJ#UsC4NQOng!Rk7TSnB|g6fPiCZJM>`G6?nC9x%9+|?)p0~j3C*fYOY^Px>5 znWZb5y^mEJ*$OP`nJKchQE-;+0%p|NBy5SBEtQ20+ErpQ>c>fI#x@7`bH0JFTpl4- z#+o{pWvdNabNPeCL4|1lzw~8)xDolEDH)B!h-u$hYfoZ52=iRPm;msH;|(e1&^pvB z;K@MUlx;fH*tS{6|7Cw8gV~Vhjbn){U&m|!?%TQF^<>h^zFW%(d!RJrO3{Yh-e3Bd zeVwgU`h9@sX(v&g6Ee(*Z5$j4*(116}c`2`OXfEf)^q_t4U0_CFvR@wS6HYQ%o zU=OogXFok@#jG|XRKBVgXq6%BAO0M@my6pWq<sE)HcLfX@U&;5Jq@IjRO}pvy(RVlT&R{@QVDqH?w24`>*oJD8(8Iv6#N=OL z{_i>RT^eo_$oy&GW~-tqsXB(fgC6vy*45?E_xmUDxb?arx0$UoQx<@mvl73OO-1j3Yre9>Xr3(_tN?{piyy*V(6a^ zZLToQVIrmYkfcy&byArTf+-AdN|ILPXSDg~e`B%T;a)`hC=4s|lt79JNW9A*Ff8u( z^~qLX7Dqb)g-$O)0_O-XOX@`uDZtd6LFHdlKNNf&sB4PNq;I0L@>SyxD2uZSU2PJd z#B|0VEQ-ZOJ-IVStGyT4f3F-}dYq?0Ue@&Xixww^$!a?6J5?5_Zw%aM4qgqA;Lj10 zg!gaq-bTANW5&gQxEA}T1{z9$1n2IKjb7Dk`BHGwkM2mv$}1f(fUg!V2ik@hN*xgi zcd|G{94>qMGfns`f?H>%loODJNr&=@R`}(i~g$+vo^J@14p0yQeP|grzN7H(Q%e}ucp}u<} zJAo>a6VrD(?uWEKCH_35m;0!hq4jDjz;2avLxQ@}(v#$lBSdvAO}m;U`xz$t-Z>s3 z)qFjO#k#05sTPyc4i0_&412&)=R|9ds8R|oPlFEJ81(igZeMiFAW>Dka@r0@5*b!ypVXbiazpEKoRe zsrljrd+_`lY3~M{%V~vTK-sv=6 z?Ekbo-{BwgQt8ddgx_EO6%s(qVF@A2Hg+*Qtq$VjEDB0#=yxyjIQ2Y7pH%sm9*a1Z z9~~J9H!ywj5Eu6dXdh|`g!0}NoXaXHjUx6}j58&#QT|Ic^a7N>2j=RRg`Uq3e5S;L zF=@LWHX9%BUkFbNkp7@uw&>d%iqFa`J8bAdO5;IOrCHDe*U1-Tb+PWs zvf{poTyWeE^&k;8ST@q?9;{^`T6DFo7YQ9hE|uLic*(rvft@;PE@q7FT$+6gR4&@Ckv`TBrTIDKFFY5u7}%M``2SRX65WW^@U z?cBy#da9>of?_ zARaQR3-f~%)=_Tj1XwGhp`Z?&HmEAy2`+Jb5wBCg#X870L+6|HYAAf>K>?1j)^esv zZ{HBZBjX^5MT!XQ3vvlA+s7yuv#wLkryYqd=ljo(ezkS%7ZR@9!cS?+(Jpq$oAyIn&Q%emUxjJ9 zvL9{~E7nu?_0;gd#c9^j5083h;Pq4dst1`XyG&&ZwY8+#r{mNSw!MyV6>%Qvb^W}K`i*`x3LUxtzA}T<{(aW z>{fo(a*`bVKv&M2%dFg7I$B!ze6#mTe{y;mfw*Ol^D1fifXQF9cQt&9v+ElSa1Am( z_2+BPSTA5p-W;Lx;rwDTjwLS7NFT>@;H^b2zV!_YJ_z{sCQ+H^uC>@{Fg5(cHXpr8 z#QpfJ8&kv7{l8f7Q6KbSlhV@GJvGLM_c)&LWt1fpQNk?U5f`Iv8k}^E4Q?0B4Y_OG zEqU3@DfM5SN_G@>+iY_1*jVKRavR?s&bu#{z!rVDqYarfd99c9PABW2V`j%1NraCa zDt^%EOPkqSJIl?K1o<)RenR8>O;)45?isLV}thIEv9DMIB4(@a-S$S-8M7_mbL33rj+!jf> zLTBA1;Bqp9SX>dk-_f6~1+GR=NO40bI2&6?-J0wiJuiKXFNznM+#}0vbs^Rk(9q#< zcdI(m>bKccbZPJcxW1ZRO`qEfwO@=)5AQyqu0=|HN@{{V`O@vWT^m10Dx~^NibKJ( zXreXv&?25hO@gN5sj8LnSdFO@jvk&vP@bH*T(#puZw+OegS?7XH2g`YC2hx=XdFfJ|xPUrtYB+l|dFMw*GPogs#axcR_h@vD%+z6ie7_XD|iJ2Ugp}1T@+Lx~BXpfZx(b7Ie+H5%z zdIkaO(~S}~1S%VZm^;}coZDu@Oj}j=vN;KTfwG9{V_^X1y`p6my`o7MYTp{i4TY}e z&%wX+mIor%*sAuik{Jx-aEKV55i7av5ljkbkX(J*PCPFnO)08%$y)nb?8(qzwKMh2 z|3~g(Y=$|B_6aTH`{T?5-95<&l<~)bUAS8?Xsw2VXg4AseW^ypuYb>jCNT@4|4_#^2cDo^QVN7#f4M0$=k-I@sh3 zXRzH7b(LAGY-bF2tR-yYAHDAg_>kRI0gK~TSZWXMDw3n9~^w*mIX12#ME1fiXm@v zwU00(C;V_#D#MfX4m>hgHU&1(F&`V$l~?_(6u`5?%P3L1w54GOT{*j@wV-4U;*$E+ zU@Pt)P{)(;Qe4Q`H`~){NL-aQNY$1jdp`mXJR&R%gu_?-q@bytCoU~VPP`7Dn1A?h z`Mg#}*TJ8i<`q$1#6609kpL($di0Rc2W%_=Q2Ow#AY1h^^Ur{B=)5yP~~(v1UcL z{jagi!KkdQ^0-$78yxYEKAK1pglFm<#s$Ru4q~iKR5NF*3M`J};d3?q5zVM3)!pcT zVZYZwTsbhyHn(?yORbtBY1GG#wSAK6SQPkDio^9M>AjX;J;)}^|oMzn=mYQcNaqK^7__Yn1(M?h36)IRi)pzvqvxG0GOVG2UK(XNNC! zvW#805~SV9l#?wmB#7v_lQk-SMJK~({Z-?xL22?&Z8|-?Gk!A)8nuY6keB8s-Y-a+ z%zqwCm`9m+=~HWK?FmPDSFH zNOO=VXmx<7K|J5?AN=!H;JRjvkLmDuc5Z0Xd zCeS&Y2KZZE(hLRqmIHj*p||C8{$Q_h1Z!W(*x7tzf{S%*L~IOjmHN0jL^BMnWLzco z+mDbsi*p0;TA)X$GTkI)?wR;yghyjBC0m5{g1+5oc<_bDX?*Y3O;!6(1f}a>v)KES zRThUNav{N8vJx)ub!Ou$^k(CLt>bwFR26@Lwes<^Y&{zeU}nhWGlD4dYF#cvbW(AO z5Oh>24koiI*x6$Fa;wBw(T7J6eg_lBUq%cwh#HrC-)ZN*Xe;&p$#iOlIC%DUll~{6 z9Wnl}rzvGYscL#xh_i~MkL+V6Tq_+-08t-^*%?f*)G#859|#>MhBxe?_sf9ERmF7H}Ar^BNva8>h%T!&0z%h28Vg>0*LhQERt{vC#CGaVAl$Q$KHHDqPt-sd9A){fte2IOZEEtq(-iDK84R=OH)Nf z#ng2DV@K#9GRC(-{F+}f$!WnGL|q4Gozk^7vobOlhk6EG>@m4z4LpetNhj)%ONV9i zZ+D9z_BpM86DsTLQ}JHSHMrO+YyBO9`;Ng4Oe4>Q&Nc9E$Q`=8Ww`9JSTI1N98#jO z(}zVy+5~z$FIrT$@`f?<&)sjqzl7@wz`w{@cMs$M80!tJh1$GRM5t09?6Mi`yH0YY zcP7G{CL&VR4Vg|qSTjHVLE}1%0y-6PkmfQ|X+A-nypGWyu8V?bPyksU1 zMeNNu?5?0%!Dn=NhN?1Q?^kw95(=>iq`!|eP>jTW$zj$Sv-|kl@R^-sB{0WZ&q)b{&c;JTT2~dG}CN;V=%k_o8v(0Jg{Dh zHM3SKY^sfy(|pbhxbweqaP5pbt_VGDz2NY2Z9SQ@*F$#~sXqip5fchFN3n$FZVWy2 zX)4r*TH8n*_Bw?tO;&MAr#oF8ho8s%Rvo)ulGW|3;|fuC(mp-Q$6p9%ZTX5n-((l< zb*yYhT7xoVlVn~c1^I}@O}jVz!I#tp7xwgfty9Fui9z!cTf9aTX}gP7--P7{_7W_+ zyOuj-lcU})E*O{-5~0IC>D*N3Ym1p-VK1awUDQ)IG?Tv%kOmjTc86>P11< zU7(=pH$-k;o)%78QBfFZDv>WoMY_P52V)_o=;9gCg9(!syy<#Lp~9X z)$DOXiO~DiA=AnQRm?tBR5{t(r*F?HR>X|&RoZFPrzaZPau&^7(2I=5QXM8G8}Sqr zc^s$=hq=G>xXM?f=aeZXjb<@vlbO~^t@ATxn4Rlm%S|Lx*DBUZ&R;iPhI9U6c?+d; z`*C#|G8-$N>te2W9Q??T@)ySUI?2kSt(ua=ZN45Q@0blDfww=Z49c$FSh?#G8V~nH zF@&rxH{?ur_pJ%Q96OoDR?$&TE%l>#ZVzV;p}5#)p8>lXjwuemh==@fjUIZUi!+7> z;X!m83;)VVSE1=7quH>d$CsfyWExL5A9GERD?yh#cV6E5ov?5x-1Om$d7HtZKJ1AB zSK-LwHmLyOB-|6DxxUQ|Pc)bLzH&B3#!9tqeprg-$vs8ib4^x*ngfRKlJH8$#8X{3 z(<^6Y5~AX_9;|Hsq=qZ7>3QKuZHj5E@jVK0iBOw+vTN+0zJ%6~c=OBS9B^^Fzq?GU z2|&T^5X)D`%i*-tt&ecq`9<8IIZ4TvUvbd#+HXGvh3XXjPCEl>wOOKs3}JbGqD` z=V|@s@?2I@Qu1O4BQG}>4G=NU$3tc=Eo#cge(=8a%}CD2D%vM^ym|umaj6sFa4xjj ziaP@?9>qQZW7&}w%?7x(C^(cP9b0Xot#Ih+WD%?@5Nx~*6FL|ezYZbq45vQ@5$O#> znW9iOCP$e!o(pWu^P6Resdvg$l6KNcOqUT;`1L;9#5u>s72=L?iJ8IleP!+@7KJfT zd|b-@S%g|Iog;&#MjzI~`2}!CYOm>uk)2vb1Ql`5cAjCO0aOgmv-kC*BAKlfFF6(! zn3@U2ib`6QxnX;h9-+lIo1TC&nc-}NDi!-|30|G%63zYU8F9{cqJB71#de8v>w!gQ%kh;>dMtM%R` zGw#M!i+)qgi74M$gzoU`JSQ(F*=<^{ru_@H7kI_i^K24$-VLNb{Hol-$a= zMe97Yl3ziHn?Hj8N<}9qx#g_azTLpsvY7_wDu%> z@!9NU&YX6v?6TgPW29p7!;_=qpagiij5Atk>TQ?M-?MF~#S`rx({#RcFz0Rhq#RkEG;?%x`dzETLaNE(2SaLu9Vc%r z7xm6^Zdu0$ZU~oZsJ<8u(xh9AEy{%oZ7HhiFVHr;BdAx-%tOW48Nos$A}D6D{XwYa zmb%=cc5xg=ip%*P_FJ3!{$u6pwGKkr)LQ+Bt>!jLtikLoT>u%yAPA9PvUyNaYx_`5 z%M?aalsuJ8Jk=YI6y!rzzNMdbj!2BTfrubep&{)i3B5zb<`2@h25MgyCe8%oPJq!0 zY%^=1Hqu441=vWtdl3-#eGs9^DE3AT&m6KsUNs?YaW^mOFbc;pf65OJ%zC9=)>!Pi zw|9&C)zQxkKRktALmilKuHG4Jr&G98yff71XO_7Hq0P6#a<2_BJ#=ny>#SXUVObhS z0skaCZeI0UZ!lqEWU-tz{aso=aakE1D9dt?t*h495@7b>(sAI>CCdx13y_ToPvw8D z)tM|h#mTWJE|bGtvu>OzLWaeDgs&jj^UA_?2uBYaZa5@OOug}atrL~JFT^UybpfVp zGEiT@?_a7rksK>sB($-e(QKms^t?lAm6x0a44M-4uPZptJh2}a!?qin- zy50KLMjPp{-cP}H$)(fdB|kfkS6{8W9*a`BjO#o0eashkDRkheHgWp=zNOL!7nMOP zy&?ZgfW{G%z5iZW$X+qpamj=IssN4luqQI=4JNhw&e{G{%XKjjfB*6aI>z{w6G`m; zn%q<^t$afrtgbcs)qdQ@4=Z}~oxjl6ef@e5E6AS;cL60bGeQ8jgm*>!L?%F$MZYXI z)9$X|yZ888ROTTm(>GS(KO*s9eU zqtTV@vmq?T@DfXhe6BOUZ-1L5ywI`pZ;V-s=e}#WQUx-WbdBF`v9v2Aw$eF491OrrWTf%u-2GU|(xJkx;jFXO4rldWxKFW33^H!H z;OgNGNmJSQsm$+5CaS1!96Vvx=M}a`FC#jaiTz@}Uq1KBKuX!L=q{Y481-iga?KA8 zmr1kTEU@#`UOTIYBQ|h5j|_cl3e^On`Cko@nPnoopzVxmvKWxUy6&!@7Wwsvv;*0Col=MfIDsx%?(Z(jmG9|n9j`1B=kc4J30_2KV-dc7@0RHp_7yVX|&dDs$)!0G5K6i&o>VU=ykCYWx`GRh7--sR4SM!9^66@M_yzlm6O*+ zaTwi!g?GvsBd3{5ihn4HsAmefID3+aPQGtUDG5$Dy_K@ZVE1H9R-jyOD7;E`P9Y0( zYr~hb+NpyXIHTfneg}`Zb*vX)lP%QuBrT)lUf}FW7-uG-+Va8Xf@u#kZ?G2*zkjfo zle05aRMdY19zJCP+6T##-V)lF3F%oTb10{SS*}5_Ax2#L6w~hn@b`Cb5$%q(p+hfJ zZr>sr^*onFrIdp{6`RFIH6!SQmg}D05XGKH*E%Xia^{RU`E_&u*wG5O%mW+BcFiBt zf{Og$W*y)E$78?SN=9;pJcNk~2?6vvWW(t1i=kI%P z$;NH4-s0^=jVWO`35muyMqH9tu@SzFoQs2HbPfmff+{CQt^TP@#LzdG8dQjKW|(EQ zXk9dAC$zj6NS)Kl=NjD-zs8IIleFO~phNbsT>mo5Voog5!AVEnA*QQwM5}5p=Gk;a zS9kHc6vuOO6+@lZwfl9V3sknkv%Rv5d7gV<6^ML;6LRPdt6pX)EppyK^yS$!%%o3Q zcs39FO8!by>J<;G*)!rSTUSf)KgTpoiQtd$HRJ#r2G=U4%h-kkBI{L3%^N(OzE{JY zeLcPg5&^V_RCo{0)Sp{x&?>3QibBgoQUYO}U5Ws1`^gIld?zW`W4A%y#U)aHdw>Ym zO^)Sy6AWTx^MAwjOPV{YVqBTf^pGdlheEwW^?dKW*a?ghr#IbRdRCT!nb}Mh zBJubeA=puRkjY8i`qmzmFV6m<7ZV0B6*$)!k1ZhBC;&6 z_kqUCLkqebFz*d(R3TQcpM4qzP?H<~S}k8xS%e{-8s?UL{0LK_LB{1Sxpf<$ilD7S zqgMH%mW>$-BtFs|I^9(Nf&vAs{2*#q>+Z=$*;03h{9W@N%0!6mp5%3)lK6 z3%mlL4@tVPd#RG=m`EYJwfHa^_`O2Yul}fG}&ODivt6hbBT}t(Rlds@pRpJa_tu?MI?sagllArbWq||8&h~Fa{i#q8$|B& zI=;U3q`Uz<+EuoM!wy|z7nlUkG+sEB16!O!5r&CwFsbXyY2%2*7R?`~zgDYP;z3uA zSe}juBF~5;Ra?-1K2n%EreFYx0>@V*-~OnbDQ+QFihRc4jrn2^_s3mp zogZ81xZrmQjgtQfnR(lCGxUBmnlV>@d-F{i3JYGU*&3}@`aI_QXgS*;a)a^R=&Zr( zA(v<`HS-*`U&URw`<1 z@lUa^ykt%lc!?vjwF-QJj(jP=)CaVs>enEfhyMJ%2FCSoVZN9}IlGnVHoQ zAEVl}sb%t5J~}1_1sSB%_(@|6v#EYAhnW^Bs&bz+}l?G8PH*Znx<{p8_3!VZ8E^w}k1R}~?a!%8oKmm(D zB`#oRs-Tbw8~iEpK5Z>L2YhDF7~y}m=J~~ix3@QZT;(R3226VE(T>7e0>TlyG=(!R zdxYlSp5A=?Y>0>L#CC*^Yw(|S6xMsq-BKyYmx0E>TsW25Xr!kGcCkxqSnAzCQxmQ)_h0_6<3=7t&;TNzuT zV}<|xO-PXuw+(PGudgfp50EE6xBVY@B3=d@Vh>7)HEGDD3B!ousH zzwJb%y0KmMY1snOy{;rUNJF!`V{up&W_01V-4v@vA$+q1PFx#>$le2w`0gd`8*G@m zQe;o`W%o~PXN@rtQj7uD(b3UDw1M$)@#~$Cro``r_~}2`EP+MWq4|SQ2lq8S<0Dnr zYYv6O>aSzp3c?fnmGp+da!MW4+vfznTD@BL<#e?o8HKlKDU>#pzM4B`4iUzsxbg8i z$xjs5G_D9NUbwbW@IzJ6yv+LE{0Q+Qw|xeaBR@vh;5l!-3%*x1(1HJDn^ZM4_8s|7 z4{@#|tr8NO5KEfHil_X4Yfqb@sEaQ{V3pl$vEw(DgUIf^y};buq9V;kr>p*uylBoM zB@ZpP&9!Lys>VjULlZ>wUTJst8n0krYQg_tyZ_oVJwIQbEQS#v`+Kb4Sgq1Vze1T` zJTYP8)HNc0=jW0#+3_Igm4LIG7+cmzl}A=>UMCE+kG8kUORsl&7CM77*8>?> zweXrZvC2G5Lxdp>xPhAAfzJ|jg1~1#gkyH;D`OfcFxM|o9uW}T_DkZ5H*Q@8joeE&tL{1U!1}&icOV#{ ziO}#QRzyupH`x)pzQOhf)_<8uFO;JRe{;wbNQx|443C9~faNqd{k7EKgTLQC3D!S> zQsiNBdq|>x6#qXNZ}zvkB+v@Di9JqF`N6bz9~ic?qn#5%l}fz*2LfMr%|4(M6SsIB zGZOfMP)we(2wkIdD}$SGDAG(gY>=!?N$*ucL{9**L;!;>)b5em0u^z=mnU$0^`yhM z#%5s=HkJ!LmV30}78%j);wJELJ@MuDMPmEQ^+X}Wn1PxlS+7WvN4c!6A~%Q8NPGw4 z-`{u(-rW6f^#I39vddpM_CE+|gTY&1JU-ggfL_oyHopBIJ|nOt|CsjDUh+91kSL+H zNMIFA3?L!8{$tK%i>yx&4;w6ou)a_1k}SAKnd*M=O<-cco1JA?P;vHMXB6>7)|wS< zV%dk-NQ2VYhjl!J!{m=M!tcDVYHznP;*~u0BGPuZdsN_HyD>p$7UuQ>_8Uk>PSsgh zg$3T&*S3BXUnX;-N?bC*J<3&lAtqukTxebz+xdu@wZL%zRVee1b>cr??;ni&;xv%b z7WI)V%#wg;E~^9)a-AD7=kiZh-9JfSfW(s^X$0Lco_{jVGV(E%Lu+GB)9fRP^Wr~J^_b0w&$G2;4 zOOlg5tjU0DddeY*%!9@F6ZLP)0&?-%+uK30K3J#!>*Gfh&>atCk{XMOecUG;4%p-L z7;SWNJ~CCmmV>83xzHiA$|Du3Tr7rV0FQ6gGJ;F;sZo zUM|;FKmJ~%eEC&JZXJn?@+7eU#ZR`^nz$gc-eB`Ei~>=lwvesx*PlU*q>q7x|alBaV;+?09R~}iOyQBbaAVgo1E2;h|T=lXP_eP zqy>GvYp=9+_cq>pOmP@jU!@sQDAT^LP1xe_kA)##`&+Ue2q4KKD&}ok#@t){62s8Ony%AvQHRk#u;E>H4KyI7>SP+mVe`S{*Lf2|8Ou-g;x_O zqo=c^?B4YAT_+pfntkrE*ey>JmM13k5Y_9#n)c;yVFf*E%McSHkPhxZbqoACLa4+=D@ zrno*UVwEja9h=>uw2zd3O_;gK`2GDTos$% zB1lm4k(DJspD!%_!zKKgF7q8P4LZZgmzS48nx&|ysH=b=Ik^{;k^aKHV6zj^q^5|1 zGHm=6TlEXa1>%v}q;qm1UT|Pm`&n#*UrakjqcSB{Cq z`bE$XqnlIH*|`Rra%Z+G=}#NR@f3uoH5o77>-XE^WcO-SL(29lAooar4VH<;_2G!L zvn%7n7us2_f@g!+JdB!=OnV9aN_Ucau1?;1{xLp#s>uH3x>N$wq`)> zW)vupegpgb=MCR1&`{9V8%=@MAHHA84KU{;1R*nX5u--sfPMkI6_My{^NVfH^u1nE zJHbdYv)1SHkVl|i|9K;})_+XlhWnfV!~oCUhB6Dh2Qaj1um@;GC?mZS2S+NPUX-U^ z1Dp%ADvbzx@X!aWDzO&5mUtFf4ix#|o#pY#1Cnfe#x-pI#TLe6mBX0IX znu4iHipSiT{MB}QcVi=1_E!pt$0;YIA=)oI5-07UcBU(Jy&8H6A9S=18*GlBH~;YT zKk!8ExkE#of~SssD7$y62h!Ao?4fG<3Z=GY_9Kza^pqcyHXao)>bUN=et%fzrsijX zb5Y;9qZtVOe7DHB{Nv^2S>JZWO2MZ4^L)Pe4`+v6?|F{5n~JpZ5;!eP`}HFfM}{US z1^4c>>8SQg^Vb}_zCWEN42`y^ueNzoaDL%1I2ZgiUa^Tbtl`PaQ;49>V2xe0_E|eC z!#N_zHJ_Vrk?8k> zPpi?7KM4LRs;SeX;H7CAa&Sn&=4D(7@A*~cGH!O@&r6ajYFIJi_4v4h5fadM(D(d7 zTG{2Li-y!``<>nLp^O5R7S{z_9Im8`!*NbqT!;ScBssJK_MD6ZpoX;Va}FKLYt=hi0b@x-M1-v{{h83E7^`N8>lZPD z8rKVNjAw+uPB^827jqu>T2M341!gQzXpKaDDT==C^;OwG*udJ2-pf4_#d;gd;dt@5 zCJg9R37oXR`A;cb4=Ru+W{6uG$&C|i1k{VaUH)IQ=HF#CgUe(VbRKfCz&JNNPFh*2 z`ILHR0?uu<M1Sdb+eTA|1li9Ir%78T@Tt$mFu;C|c2=h3|(R z0UPaahIk9+A1a+D_XdQ6jtQ65F`rji~OlF$A&zVJ1-POVFU z_HgU25=AW%xU0?e=ajfbfBhL{U15?=s`8UlSG5Rm#4wvs&TphlZlT8(qnVdu; zUlawy5sQQKs1S(73_|})lY!N!b7cs)T&uJ37Qf1a;$z~4O>Tqrs;Z_;^n{}2F4B*9 z)F*vqVHz(_22Pu!u^0X7`wRnc0G)ZogAhz@L{yrWRXBIGYEdOV9EEKjd$pL z)p3z+SD&A-3LCy$$j)Z|-m4qsTf3$05ZrI_IMn4r*8WtUpKIKyk9DO&Csv6+>n7H$ z7FhI$b}gsOV1&vd2tqZx@2m?xdy?@yUI|znV5Nd8^|#&TVYA;!OvvUm))MH=%@zq?JuXR0I{Egh|43i%b;LSY_xZm)lL+qmJ z=r}}xw-r@3nRk}QXygRZU)LH!lSR0yeo8#eYt>!yR)m_0S^%;5a&yYz@@!eDD~8;s zeHPvCkl|o!H`UKDY9rs~f#W!ltz76pFY!p8=D_jqs>$+0-nl`S$_Y6E?u^(o-Eomg zQCkb?`_fD``4yBJK}iBbl=kQzhjEnYF3VVpjH&{#%j07Zl;`7uzJjS8HC|>KSGdHL zeV6ArIT6d$yhUCQgY=VLuS8HXp1aG%cwXw24Qto;PwYjV^Fg2a8-m&oE~jcOKcUHU zZS}Zbq^uv?dYt#*)b4@oDa6*=(FeCMOniZ&m3B)0@=#2UhpL-71qGQwiCt!*%E38S z%X@`Zt%sq(L{FPsHo^o26UuBBOG>;&ThF*R9-JefA(zvoDwgi4@jSVXJAq|^ipTRJpR z^rVKEu<^@aJkip6-TOL?*P~cr9^WDTSmZY%NJf{dcZ7bH{=Q&g*FFp07ho8EQ=29C zec2lWM#liN{Ce;I=Yd}>Pq=gr1_VtrxIKLgbcB-hNVx%;t>kSO=Zo}(^|@}}{+Rph zkUZtQYp_55S{=9nq_zI{4t+BtWRLUKk?FCs8k5dTkD3r@WE(p1E3<|eF6Mjj@p>hn z)|Xk>IQk|ySZ3Sp&I~@DF|sXlFUyREa6e)92=PMnzYOA>W>CcwU}!NIYNr(GU|fwZ z)-bGh8c$fmnZJCwARq7c>yxTjY6@J0n&|;?0*k6!;-)8}$BdG_X=d7Ohh5xv2WW2jGx{5{|Qxeyxjq(rZSA?Ek=-_UiJJmMj)h-6ew1%eJHZ{J^_Cw|lmHe0j3Z9X-y~Z5#(#4fM8q#(1b6*Ws-m z)9LWfBZldw4wAKKG}HN48F5t9v#sw}_kaxDpx&-$60F7<0R&p#}(lq@S6Zq-RG*XI=Q zM{{L=l1hy-nDTk+7TC0=rk__uZ>m>%5j!cy&q2NGezk9CueA^sE4WR>`~2gZCT@OC zs>6*Y%ebXe9~XG(@}eboRr?UU`gjGEdX<=M9WPdIe_W@6q-1)5K|C8DE4hmI;BY-_ zZWR{EeRy)>v~pHW^VETvz+>KGl&y9?y}{{XJ)q)_{8Qtgo++;kDLnRPRxWZ2J3a`J zQ**+){jG}*TMPOgkMn}jWqlh=d2NObLGBhP1mV9uXSsTlk!+E8E<0YRHO=KJ!XDog zAwADdR20!`LFYj^4CowvKxKYHUj#N8q3qFL^PKr8I?SSDr5_H!#A8G(qz@3LinXV5 zdW(*~pCH-FfsC|O^0iktZMxmx9u#m{K0bZW9lU(3V)T$yPUFEbQR$YMth0iI`1cUJ zyE}`^s1tWlE$}TXjHHW2_kt1M5)FINlU8&UIZUfXzAi2-DN+-osV@oi39zQEkep50 zpP}^H!5{NxLYP!Awxb`f@H%b=R#xn2)c6Y^br>i>H+W z<+#y7@tlBiVR`viB#VfYfebeRCmH2o9yFC-cjc^irry>wJLi2s)EQq74$TU)%xphj zNpMgJSMl*!8H)DA>vKd$lRWZ4zs`@teJ!i+OQS*1M~oq%q3aG#i1|{VhCC**(mq)4 z+#>;x`yMu$bOjzsTCXC4QV)BI}_Pw$*j3dOVd$%o*wH**HE*I zbq7~C?o4BqVXYa)`QhUG;%+yJtysgo;Q6ri}W5cz>q` z4K%A%08Rdri?>=12I>TN&g(J9ObB?008gUNG(x2$J7{=~ej124OpGd zi_a|IkGo30y%8!{dV|KBqDCmT{n#|k72Q+K>v4A2OZq=ttzmFlo@K66kIiC)dv~&FRi%71!7_+)gsw)Lu6zGyQBcKLZ!9 zS1v$POZd$}*5{GC*i9?Uwv5`JTI?Rswy|{naDCu#FvwsBS$jY9~h zHCNM^E8R974oOn?^v`^hwkqIlvmH9A58Per!mlqHAoXy4RL-7tdY1URqbjNKzy(IK z>k`x=Kj&Xm-^yV$Fr1LTmef|hcMPrSS6aGj=6tHyhSTodpS$9hno^Q1q^rCSiGrgwz5OQUMzgCd<**gS$s&zR(s6TH*o8|3*hpC|QY2xIEb0 zQh31xn0!q}ZYTBsAtV2jS2qwE(Ug;z`+|Dc8aY z4UHXDN*%O?u(hh_ATg*!1dybYA0NKZ&<6=3P-dWpqi_hRd85K(aHqztQ%2-lCA;B1 zKrDxT3iKd#0hTidIH?uMjvXaw*eDGn#kX56Ttf4y?rYclKrPT+`dL{C@UbT zNg;8r^J`{)q$jsKcq_(&jAQ-I4wCIi?NAkj91{zJ#5V*YWFdxkPLGDxHjn(bil zBJHpMGZ(wAEf}qVC}EWW3F+kFUShyC<3#W(r4Z;F00Rw@MFIW{-ajDofvH97I!!e9 zUw(##gF{(SG5ycy14{P3>nK|^E)eak^$q(P!apn~3&oZVu7le?AI{wv5c>no@;YAn zj$&fR+0Syb1Frea8-4xEoZHTaYoZpPY5`C!)Ul9gX$W#(04`f_2PwO=&*uysDXj*e zm~jd^fP+H70X6NeLT&?auwtLs(U$;z=7_$gq{;zAc9UB8#_Dg4opLx&T=5~1JsPC+awfK18hgnJ(2&L99~AG^M+L0 z9T^=+o&9bQyvQDVpMBtB>m$aV)Px^+jv}%_*T@GCYSKPX>#R#RaLOAf*E#obu^U#w+j$(BqW@F6Se+}iha@rt#`Uyb>8A=j1NsnPzR!& zznr<&5jj{tKVAOOq}^PU__T;f-eLw=_1sx)`S;5Ai7b;4kG;tELlaO zkgh*?iV;%J1k~WHef`&L@ahDpZQ(lZdwEee@A2KOzjh3e(_HVan$nOAX*B8XuU_^Dj{S@2#j@uk}-f%(BPv}xAG)k=94 zz~rT)yhYnJ620q*fa|jFhhC`*ef7&>$C>EEwZi>332`^lGaEkadPFJP{5yvNag$b5U^-87qZ&+}eW_Ea=zCw#n zEBl(Vy1c|^)>m((E3wcHSdRQJmlHMq;Q>TQl3};NivBl9 z+f(X#xdPdclXKMAHCVzE59E*l*#@RIP;G!2pd1{GU9Jk?1%d}qdabLpT^d^f0xEY6 zNq&js)DN1=*x*&1PYf)XgLNWg?P2({DSXLMZIxGc&?4E?LfWVPVr_Dl*)*U1FbF zk4AdRHpYaM_|Eoy#sfS}RtPh~?<-`Yf1QwT;vn#C0*N{o9%&g?dmt{q;6#J z?}Gw*taI5~0#3g69b!~@q`|8QddNmlemdE?p8}IEFDY0aQU4a0|9M2*n2A7v(J&1A zv)|Wm2t4+^45jSJR~w?qd2KlA#Oc>z?D+eBUk zwRv1?A`cjfeG59H0s4~=3(~EJ!AhXm03!nwJj6OCL4?P8{vSm^=Z!Wro|16+TmCmk ze6&G^Bs;e7b#`Ks7*^yf595deSS1ys(RQV``KHU;nU{z{#*CAZdWXy`^6uMj^q3W& zjQYL=i&b(5TMXBl@Ozf+?1i*+7V7I3@>hOrFx^dy)nr+pi66GaB1uT%{QdRiPY-HO zUrdfx$EGB`e_oM4&Zc=?WLqw^9_yJpcN-*5Z}gr`UbnnW~*4X zVa1#_Qa4s61}D92OqhmOu(}f@dofX}*C_)8L&URrNn-T~9j7#}^Ve;xxfm-ADL_N$ELzUS^&bf)Re@9TJYI#gxmzbq&(Z0DUDg#U?ZB zm?R96f->>pil0J&Esy%bup96U074YZ{j=HdwL#HY`t4UJ*Iu3it(-ys*3|tkp5|9V zuK{$eNVFjLs6TtPe;erU{*;_ZB#?i8-YVX6zr^3ID0)6tpGduTUn328+)tsu#bsnU z9N;JQaFZO3yGy5k!zfTSZ4TqPNpqw6@-pI_-L=3t&3iB9f`U?ZS~l|TFw9K`iWmyv zFvBh|1`xsk{W&`m&@pFm=N$99|IQNNg21Jiiu+N#py45AT^2gMZWwS4E&hed1k^D{ z_T(6%6U*)i8wDir!XJ2k;4i_5vRSue&Q8#`o`^s;@nzI|dCs99BM9|5Xq}yhZRlJL zPWt^>V^Ht3g0nFe6ntF2M^i=hQpyF&)ms5G9sF`QIu4tHKI`Z7?$(&x0bTGx!KR(zl#IQzORM*#cN2D zBB6}CnQPz6fcOAYKswO-0AL->IaYnsAg=7*Tg{Q2aJnv+6>^4C>zgm7*YGu6MT(JS?b#$TIOs9R7zq`wA`Ex)-P7w?F?oAR#L9 zU;?=buD? zECLXC1!2+oWduun!yOsVgK(OlTQuOyK7GLm#MoD1#{mL?QSM*b+g?fl{BFHq7=-r> z3(LLh*hEG4;-BsxQfDts_i%RLA)y8i`vK&n=hRfuH z7=t`s;*A8&nbBI0gTFQNn;nveKvX~_`yfdHCu?M6Y}_PkTQP)Tco9|@;&UALA*hPr z#fYZs59)Z7O(9x$Ugri)h`E#|=H8*r#SLdjpluLH0=JhM*apHZG$DhkIRB_KC`v%M zyaHJvh-PWx4}vf##Q@pSOPT%~nxVY?&JQvi+l|RxAeSLk9SZuu@ zIIgXs8bjuLC@J56n0vZJdahd2{kUIAJ8x+KovZO4mL%>(i3GO-9ZuxbjTJ zMtuQ@MKGGNo`@D?oE zld|_$6q0&uez>UB`G@L3NYmZhkmLY`QZJtl11&AsSiOiq0;KBJ?3{1QD?rpw3r(So zCaZo)H1TsYFtC{>(7%nZu}97qGG&;S60R_CwMlZ|FepUq7*Mf0{^ag|$$|r`2v-m# zV^O0UtgPI?e0)4zJ5QJVppy;z_|cQ+Bt=wIGfrR<} zwhf>xg?5CzV?EK?f&PICE!Y;?^Lw*so}{2+zy2P+y22PX@j#fDvhOJQHGC4iiBx1R zwFZXE!B~J5(AC{@glu0%V8}II#GoyZ;JZD|U7kGd6%qQBr#d>RfUx=~GK30MfA$IO z9P|6jje82ec6)*D2f%>D3$u51{E&f{6KL8w6o5AI7qfip$!l&0LSi2Jcs7r(c$Gk% zK&r+)kPiRB#n8^|D8{m-AX6B|B!D}u>#b$&U2DRcQrXGlFAtxL{XwibI)G7DR{qEh z=Cv7#K$Cb~xoQq=pec4WBh-(2pALIR+{1_0aMT&wPyR;mM|W+Qk(Z>11jG3O_B2Us zN^^9A24^{tkKz}@VKk<-BnQm&m?=&Fj3(5I*C8#!s!UsHXJRD`Klt$gnY(8Tj16K0 z$muEgmcd`wk6`RDfxi1l{448026@5gB$~_XbY9TY=O!X-l%b0NE0 z2un(?V&rqsd?yfuCu?bM_7bW5tDDp1)M+!>8I$Gg-9B6?d~!MkmuKQab_ec{PV(?5 z9I8)KhrTOt!=bv-1|=gd4~Pi#1kfF)dBS>eP$9c9kZhTc0l_*9Yd}}G{h1X+L1`%PX8WOzMhNBU5FXjS5h2aU&N<0$%&gIO2@dV`-rt8t z^Y1?{5;0rd6?T<`cJjl1xd0tDo1sFB54)qD;kStF6mi-dIhT=7Kus7rj5dNU6>?la zws1Y6DMASSwQ9`t>qt;UW4Hk{+5{y|2waDR*T4B~d{2GeLLl$^OP|AUq|(7eCb;Cv z|Jg6~?%lh{NQNy_pA5ktSw4-O<34|cf`TIP8?;J{-1+?!GSI1X)|rDWok7_MPdOS* zI7fC0zq|o+&^p+0xuY?uy%#xH!aSLFM;runN7rDt5V)AIEh5E9TVCz6RA|DkE4z@J zc5>^cH3pU80kTn0c!V^{kdkr;k`(m}f3c5PLGu1;=u%PVI&xNo>|&9Fka~)25F$46 z@bY?nf7=nw*(VC=O+_PE3ve9>y5|G01)-(lA6%}9ny05gtG)mN?$hl3=&!hnHAYYs zhf$)C@BeFa^qE$yv=lKxh)%cl6ptr^dQlo-dQjA z7}zyvb78O0iYr&j-6YlCPWv3gSsjW9B&2kNUkpk#2(o{9^UB$nQ>*2Eq8IM46Y zoSrXF_Ur{^5-{q&_T3?SzS7+A``3V@mtP1ih*ZJIL`=WCQ#tPz7~}w-s^ChGGPvoHFPK|-U(9S@mIQN zSCZu7KKRmDR$?DwCmPJc*tw6h=07}e*^O$OW9|PU;TXs(zLixz)qm{Tq#a~o*dFtQA5_0X7`NpgPh++{@69oTwLVsfc>c|$&AL>ZT`BbuXUW9qW&j$wwy8R0 zi8~F#t@0-jEM2eCt{jix&1UAN%4?L;kGsb#&}i8`+SH$h1< zMb%u+IQV<&zq{g9puH2ZuPKr59ZLij5Q4uHPwYH!^Dr(3aXML%Xp+D1(8_$`@7WDkLV+@7<^K-qD6tCTDin+fI%Ks8><6(;OXT%LfBO{z#!?taH zM-+Dv9D>)iZSJqlEI|q9NXl~1W}0D&ps_NL=9_++{pwueIfla$$%?l<&0$r7w~e&h z>GOf(HfH>cAyZOW^F50O&z|Lmc0@S*DByi7`mw9MRniaElLq21z;8tgK9vYG7;Ubq zvrz<#fE+aQ7sCcA;&BYyO8hs3=ZN~dda^Fp;eS>LcN2hUxgs%R|V3lN_<4rbeR2UsL7{UI3 zlqsZVhzeWHm*WF{j<;&fBcTm-&mMW_F!*G@iWGkqnTCSSoPHRJ4UxPgSxEF zOJ2f&GtHFX&CzGRR9$HvBH>p?_$yrlH-@ie?aCM~EVWM%y9vf7UB`Jfi`I<%n|mrxnKV;9_4H zc)q?{F{oX#jX{oaRGy-b#x(NqhG*dUXOwLOjFJ(4wjj`Ab}EpeD}Vd{_MSwi`T^N`LOP7Xc^ZlF0`zWec69;P@LV3D~uvt~_#U zF3>omZ#*IS`ljoFl9Ceu{J|;>?eOxUc*__;MK+%yvjI;@mrWDEn!JdasMh3 zYYUItg*Yyq?7dT-Vb0CP_c8|c-`2tdt_x8 z;J-akrG_B+wh1UPXx|pKI6080_T*jD4X_aaenI$Mfc-Kz`cD3#5`gI7ZdprqD>^V; zaBdx@$!2G`hYe#&_cEolrG*cA(R7K44bTaub@ybIXQc^S&f#@-D#Y*`1|?LV{l2gq ze#x|`v{Gwvm&Fm$5lSA(l@*0>ufeIE;+(VW1HEu}P3KFT{Rr326W-yI-HJ1T7BKZL)~ zIvw5h1V$`@T+-)FivR+@MFM~(Md)Fq-Ue=z0vbbp;4t(WeK$8S=ppGI01%Dtc{IQ+ zB-GujEViyha$C47_ay&_QKXK3pIiCGkzz=)nZ`=zc09)I+UF%L9mS>4IXQT|?fci` zXUhxHA~oCOQr|7mrD`KkA@LP*(q;V`T3R57IKpq>m6zwJprCO5I*sE5CkID8Mfx?S zhe1?$uQ_y|sb?7r+!7~0o7U5t<4!-0qPNH= z6)VWx(-q7qK7D+8xV+~1wKhRQfCU}a&7;TQHvP=ZmE4J`g2|pUlEFG{4QK)B{2V#k z-lEXMAvyQrf=cluw)=~6>i!p|uI83AvDM53M&Bl6m*?RVI^ZdUTaSO(@efW}wJ=+j zl;qDY3?0q&|Lil~7PT|iliaJ3^f-9HjDhOASO0ld)*KTURSan4iT+|a)b6)z+=hS4 zWm679^Z&0B;-mzr28lw$_pSeUimhTOzekQ3_G>ZL2cW@?T;~t9!!f%4unxM_p@S7I zt1uZNm+EabHy*yu6=k!*rdW6Ql)Y}m$42ox<`~Pk#M)2igN3UOQ=+M;R796#F!aN{ zeF6%24YLqV+x5!?pV!}JbOENpH<_LTpU!I9I zS`F>bI)M2iU7@+ncoE-~Wll1}UWq-eF@s%YXulL<)W{w+uq5$_y@F6}X?J8Lv$u)4 zM~4Ni6zo&KU2E(0po8c`yIw=4ju3LP-WuYLvW7i1L3edGFb-~Q@y0|MeDz0=!w zxPL#~?Md1h7z53QHBKwEpEXEEK{*SndDerS0veABH^6^PJKl6Fc1hix)e`KB-qM+IloS1=5(KRk8!o+SmCtyKIys8rmzB= zXAW;8#PucE(kSj54ZEDdvY()WHoutZ4-!K??&yjDJ=dfls;ZY(JEmiTs|XzYxlk{x zSqfp!fqN;LXioL= z$}=*0b^5dwm4qrs2Yucr`5lJXM>AZeF^9Rl$~;rix)#@%qWL-^hu$3Iw@|EZ0LvLlrJL zXC-Wk4MYny*s?5MyOst;z{Hqx=r_&dQVpUcTqC=yc`uTWr2+T?(CR>I{4bk2 z@jK!AuTA||P#EV;^tVaDl_ni(n1%mD#0>?we5I3HG<-C@_Tw(YY5#p8DwS&H&o%gHe|B6+{Tqqv1U$n z0xso0-k0%b=iY3nWsaoxz5ig?{@Orv_Bw8-(6dL4tq2>KC*kk!uXTo`fb)0xYRZje zPg7KtEmW2`u_=**F1Pao7!ek^Pf0UR6xNCU4pLF}601e3$k;%svM}A~gtB`_T{bcI zPjX8TG7)GS>i0O!0Za*uM)Sm63HnE2?Afg*<)Ew8<+O6e2F0ve7O@c=*e0|<-+B~K z`&8ypAw-2f6Qzs1{Bt4Lg~I}N4YUQy(;n6(?6U$~Se0R>@#m^D!JIfCW#j%q*f?t_ zrOcr%n2OmLV0y%O@R{1Rx7RL?Mv8btw@6^x+f4bkb~9^ z-%~R%-UfJmx$#X?j>gf%1FiY$(BG4=``41kjPGv_=O~3;&sVEpZhpaXz$=1jSnAws5?$A^eX;X?7FojGPm{{SaUK;9kY z*)JH}p)iOsU;y7X0R}0>(ckVOEY&npl?p5p%AFHnCxFi_)Q2Lje}FkoCm=T0v;3{f zfB_iD1fHZAdM6^`!LB8Z5U50CPbY=I^6Apt>oU-A*iotpHuU7AxeG+7prOrF?WdG)x>~uLNnvzWT(6t$>!#ym5Fdw7+EcRtc$Y&L*lZX zLpKnEtajB)aYEBEZwJwz<93rO$x~tb5x#Kj#a7bbImw_17%1zLMYnGbO-Dy(!CK5F z5s1HQEN~<mkX&Yuk`V8`sU)zq?B?MNwUFG zeKmU=+dOIW&RQ)dE3SqEcw2F6EDAZmlRc_vt0{aEwBsv-zBIV|F9i_8udq?z=U(yS?pzKOlr>W z^zO}(%ca)skNSOi~~r==x^*vA!I3dGLFuaoZU5Hb&)$z9s8 zYeBP{K{@Zh4*Ct>?9m@X#r&-m_dhHvj~B(CY^_sxJV8RBLlFBl8~do<4c!gpHG_n! z?Q7M5v$!iYg{%MnWVQ;sF61$_wa^0RrTdHPDkY%l;CjZ~9UkclL!s=RJ%SC*?5FMH)&B8g zZobIm!X`2L`fPcJVaaH}Y_foZZ_amU+b$-!jVZCGl-8vzZU|b*%J{pNJ4y!5PfRmQ)&-LudTHFZC+gNUcE%p4#4}}8y;tx#h^|YZu$6x*^G32`JN&CydOs3Y7JAIF> z;PO)$a%UBHe2$UiELV8GCJl5Ok}_A6K#OrhJVX#7QFAi`7t48=IbEDX*G_Kyu-SOb=Y1u8+n z`qcP*=e|TrT9@CE%1ld3yYK2Q_>Mb%wM~tUnW|HajE}P;1jAiOJYbSbKbC1T9tosF zfjTu124`|%AM)$j0G)3GsuP}H)cDj24#qhrHf^B0?_T_TQOJuuI@7Ck7EKw1P&8U)oF?&c&! zh5$e1Yc2hakWeCS{Z}z2+nMAE@PKdl5mHg^C;GSU=h-6H!Eam-h3$<7znUjwzt$TI zAQgI~YYcweZ?H*DFpUMlzY4$cuYz+C*2lHwxr6dQf`TUBH>G^cAb_k29uQayFA-ROHv22FR2la6{=3_kQv6UZAJA zss21_b9m^;o1yUm2#U1NTX_N1XXxTdU#TUDdt>L@2mJZ9Gv?KIKCAD_Vp&bwwz;E5 zWanPDO#`Uc12_hgULd#1=KP(0{v|j7rvCvH4dGu`I|V_PJUA>zV2eSP5}Vx%pSYWx zHSGBG9egPAW9`2==?kRs02h#r$loN(Rm}g7iC)0XY?jSyTw4dWl*H$jz9Z#^Dq1p2 z{)fe+ohPo$HSKv|YYQWCU=G{epXAyl$~^!ER{HZ%g8YPBq(OQJ5_-z;K)Qb}y??CR z(-y}dH??_#t+>wH3h9F%3c2J@7I9I4CL`s zD6r(MvZoNXe|nmgiRs$rqzM`Q6-1o9bwTVR{d<5+>ve5407-N(=N^-%LRb(5hL(K=N{CSLBRNr^(y6vSIV{#nxY#2g zl&f2y4|)QM)>*5<+Rxz|6`B_&>o8-PhOBF^O~r19UrVtn#;`Kw?Z-F)?` z`%h@|c2??^dPoM@v1^qxDRySxK9aM-l~>fp7ZQ&R(@Jw|Ahdt7D-V@Aebvgc(dweNWNAkyr6KI@?Ld6^&Sl48Lz4SS@{1&x;(4dW}0%eZA-h*GnHa{&{$ zmlzErNdKD9*c(9gH~AZ|b8`q#N(R)e9W``*Ikb(1U?$LZEmz<#by zgUG7RuZcB#2>a!O@Vl#tgFh41vu7mKYdJ9`0&WmNITB_nUY ziPyaW<&DnXg%^7qkv#X;lQ;pLvR-8ZTOOh*P(K^~Jk4K)9hmC|ZtJYTlu$ai)QMR% zOGVut%=!f$R<0k!wC_gzCLV&sJ2vfM3FPfierVv`Jl1p{;$X9O%GEvK+FhWuxT!?kq~Bii$nP1~6H*wN zI#QSs_+f~X|k`2gEIu>gp;4Ffj2#_%A1e!SeLQAOl~~vUz-d( z8PVZbx|7QovfW`AGw_iF$$opTU{|Zo&?@e(()f zLa7E})ako48}kG%QKfdWMiUk53dIY|XM({t6rAGL>S=Q90y*J$z=QbU>6ktt>sb6u zvMy=aH~RjPzz(VR4}|GdtB}i1MtPTJ(K3%|qD-2Sf+9LPI?{ag8W*mMED+3bqjPYY)4IyLKhV>$@&ES!FhElewPnmF_QG-e~@{0`xe82a^5Cq{*mw)F!E4Vi5s&Q(!ivmLUv*6-JCpTUw zTCxcbhd-IiEdOUkE~z5|b&^eN!*C)(*CbJ#dvY0l>c9J;W`By?O&r!y*6q3F+g`Bj zXQOFknSV}{w@WteHVNdTKbt#zpBqHD*j$#j!)pFjN8DF%U&C)x82RXL zdAQHD|0wTnO#4vuE2==T>;KXca>nS=v@u>QDt}Gylp2E%@+}d_O65dzqH?m*{jWZK!tK=XB+0$JZs0LB@JNw@xF63X0M5@%+a`Qbl zSsFA^i**FzY?24=ta!oBZWOtTEmZcr1yF7Q{!qdxE=XSpBi<%wAc=4!b zxNy6$tD)RpDhVhOC5BhQ^dv7$f|A z&521t<$fg_b-f#(@FbU#BU>i1eImT2HEc|5|i~apP&=n{^>Uldk85 zlzm{xao-k_QL5(3m+{X8Rhp%ha_;rNnd?+aH)JqsjBEI6gia+Vh*IfM62l3l%Us;3 zF<+uWcJo`=gsEYCPt1q`-=G{@jmNfMvzN|&M=6K(# ziecbPM1;kv$4j3}I$~yGD~zs^()AfW$tJUwvBVADZ_|%Hf_&m0bZ00(+;MqvZ;bU_ zozq3M7xkDXUX9#3cj>wLkR;Ufy*0?&E1*DZAeO1A>#pB+|fhJgG4Pd-}0(+{|NJJicF4_b7I5W`JUC zj8PAD5+*o(z;rAGX{O}KRuOK!qMH*tm(lKb#HHcu>2tUi3vrD8>;OjFzKK44VKF*- zyn2v$(%N71M|Jl<1PVj~)^H5F<7j!lh40h4JY}Lf?{Lj6w=Q_b%e6(fc$XY@J)1bv z+%P?Vo@*h(Ie2e(IkD#XH+@4UW8$Nxr+!+pF zpLt7GHg89%`fQy#j2`~+b0|?seDOQJ#zF6gr%u-3$P{lTo|IqR_e6DrSo6k^m3U9B zgljL>q$#L;X?Js};1XW9OauzOpa|9j8u80*D;t^nN!3-Efw=`p9f z+AOqAb@G`i@w(2LbZj?SEB@dU^Mv>*NE|JRJ9M$lzLx7-pwC^Vb4&bZ3r%f>^|<58!L=CPgo$ECO=;lJl{^+`S%-gghf}3_cvTj&9f+H%Z+CeL>2th zLH1Lgmet)=8BTh!+%03xIo6X2m*T$(>HRc5g;x-I25LG;#1#hLkA4D9lKWOYPxM?hLf+IOP;q`yFYq^Q+fb%bYum$dIQfdBU5xr zyjg3$}HGO!~mAhQHsG?(hi>6C^q2$xMxr~vaoRIIwcPhC2D@z-$Xi zsvKi6_*6_M$_qy*w7Em^N9_zSvt21o{}B@4om z8vK>GLJc2b(FX=~fs58ga1uKuWQKRy&TDuOX;uwVi5NU@(!!FQkG!f67d@%Lf1axE!3|8UntITdevFt>Cmz zhu0Xjw5iivr@jOK_4SQ_=j!9cngFB8h@6QXIjDJu=q?E+r#feNGSdjWT;dI|z6&di zQiwmYTt5-(1%E|cf5k$7=yoeUzRqznSrMM-<$$cf7`+Jtc%{m|ce8dkNN2mjIiY+j%T+_1 z5(+hkF~w_LJ=SW>s+3XzAC~IhSz}2V;E$XJF=}say|WsWk1$8|O@yl7_O7tG`L~^Y zPcs|tv=&`moF1{h?raK1UYN|Gk!{%ukIN#Qg?JgnFXd>$?HC7t%3IP1=l<=zGk6NIDZh6obgM?y2$2uN^QC=X;RV`t3gb$9q>g3 z5;rJOVz07mEm-#z4U0E87**xoRk8QEloPiHY^=iQeV+C+B31B~Tdl81lXqkn9JF#} z;j-&`XH>aNp-w$HLIA({G&_bJz5h7Fx09m#`}6g)htgvtQsP;EY*LaZ&l%3#nn^Cw zMAbiLK3_QOF_S#)uy)+idCv3MCA6z-cKOZYTOYEVsK6Nl#=RL7Qx3xQk5;(-7BeC~ zU8A}986x%Y8xdjiv0CP}XB9W+M5(=R&e{n!^JDc7%ZfyEVjlxvO^(mzI-+f!l5+}{ zdg{iKZnHIYM(~VH@Thf@Bcdts1n{7W8e+K)#6+jIj04WkI5f#!Ls9{Pn01>Ov>W)F zOSMis4;qYP-@!8*|L9Su8tzRAlO#FJU@~2Pe8#I#CIy!7}C=Hs~3x@1jZctwDC!(b+2Qd3@sH?Y?>_449a%>ju{s2BUd|EiR zjIaWWfo|VSC%x}r3f$u^=em}PY{82)OMkGP)aF@z06}dj!nqNgkOXPd9z{zC%Mgnp zaPtWkd`LM`g;C)-1^(D+Ig0Yq8brS|CtDMgZMMn6*E%J!elXnB!NTMHiaj~;xA^O1 zf5$Uz?CS}zjau`Lr2E?*bUI&&UXDd6NOaqRmoe^f|yG+``yJ6G)r?(^ea zbvU#VFUmG<7;{^EkXn#uWkh6w=b}t=RpZ4X!B|tcjYqF(3OK=&5gwLEb*7CwXSLWxuxK2ZY#&@v@F{PP*g42ci%naiT<5IryX za=)8F?(Mn3y(W^EyTjBorw9#C|J`?V(qS#JEquN6CQppX*?v9?WA)URF%G3!tn-J^ z+7XOJVYMuY`6Fyo+#;!TKL0yJIHs&Nvk$fiVBZ_IUDhoS@7u9Mpb%a-Icx=|dNQ=a z;L9)upaMzq%LRs8{nMyj@ZBEVO3Gf(?i>(yCfO5?JG;{2=4RPwQ(QrzAELVUr}e4 zh&Fw-XDkZu2ng0}3ai_@bAK;Db(vHTRJzhsk?U=53++Ca^;8=X*UuF6HgtRv70E5CASZ?PH}Rq_P9x!-?wi=740`eFmt= zrbnd@cN(y|aJ5H@L7@@E^v5Er3)3U#?0OIBS@y1ug4;vl{_Q4td|&8o%eAsAUX@8L z)Odk$5%su4(VPd3s3YNy?*^MPdmSn%`;~OzRt;KXx>w7Ln=c+y@*~bI>Av}|)rEzH zwYI8lekj0ZCJ7V_A#$bEG!;ETrxm#Qu{>G;g{`>5N{#u zUf})bbjS1iZygQPF0D$npuOna6wN}n`=%qlydK5rtyEhU1Zl7D| zbCP9z{o3|Uj_7`_FfWPsihe*BwcG_SsNHs@@!Z)Ar-f1#x}N!n;c5IW>Ux{^Y8$U^ zN=!ZbpnJnr+8xe9+h%&j^cD9ky5YuG2ACvpDC{LZ;{Dj2ycL*+^`&heHTLZ-JB#U8 z`o_8Dj6$}_n){GjXD)=R8axS_7MS*a5*vR&IEdnb%OW^e*>b{B%>hjPr+rKvbDww) z0<8bu5fCE=K?p7sq+hsO*J`H3v*R}))6#!Y7*xvl5%JtDk759KA3l$6#wU|48YP!~ zum9AMk3q@hp{$mB$41aDwH`rH`LYvg6ABY*VkPa4>V6T<9bofu#{~=QWAcppE_d(u zU)=3fV3!g7!7abg--kEGIiBZxT-z5dNuCgaD!2Nj7DlC@VcffZ!K@M^JI>OZV`r7Q z`u2P6NcgW6T;mLpPgH%td2DRksS7|?;lgXF??O&Dwr?Al|8DDj)TrB-31KGyJI#+` zR-&JJD)cy#_S`z8I?rXQ?Eh|POoVR*`$p|rq802`D zIQrX4f>wtxc6F?VPkyefp;JWvNwFpwbyDuqjOpgV?D!W0wlYjAyp?M-`^Ys;Vy(%3 zAFFsqq_o%E3Iyts zy{0$&zHEn9NR1{54aVRLzo}?tTZY}6?#xr`rkk`P@0^0tYw&rTZ5LhDw@Zx1RJa}k z-F11QdM>+PxRK5haXqT;<6Y+Vg2BOe$tfOjzq5p-+ifwRQfbyei_bY-=V4)@TO#`V z{afCJs=OhlWnBZ+((KXl;j!mOI8(BZywTo02p1vlepEV>$5`cSuT^X?#0eEfi4QZu-jA};m}6t38oeX>8LsM;tIyp zZiumh4;ybSV^|$JmEgy&tYQTd9L~Z*rG~MH6&$<=Je$yoyU*d~3$M+D45qqzIF2WS z&1%5I^wVqeYMGDc^3tW1ltKv0vtr~==TBH?%3*Sb)CF?WxX!qiedgtDQ=t@`bRANn-|M+d^ah-A3rYy()RdjC3 zU^)h$p8n2D-G*Wdid5EsQ*>cp9>h!-^7yIzTeX~M#^fCt%m~(v#630YYC^S^6N3m2M;}xxip)JWpOZkgt=z~RL#K6u#$s8T%Jb^bbPeBxvfl@Ea@?(T%Imp z(T!jf@T$stGd0Oj6D1YRG59`7xP4~vD!iX2Z|nu${Lyoe6}_Q*^e52}i5A*>k-`{Z zZ$RGZjz7j1W5UOD&($jPBMs>Q=4k*6eW>I{O_G0FTjs5Nn-$pT5LQ&USku;4n6Eck zxscYH>0;ZFReLi!vpC^J0;h4X7)Bz9yNPse}FgsZQam=_9#-WFE8}+%XvXa;HX{w8)3}X>eC9 zV?JJPKGC%2mFj@ILwKMe%omv(B^jqpmA;7;9usi{JW4M|vuV0V_W|y9hJU0*S_X28 z(;F7J_0(|g8SdGpTnTF>5wNTfD^0T=$e~Z?FS+En?>sbnK!3{s7Q{DddWW_6SUOgJ zUY$-c42UoI@W$c6t?oJW;BBT|?&;-&T|l3jxec>f>VsXl3Gg&yqyg?k7v9m0%9OMn zO$=|9aAAL5PAK<`n_=L+PBwB&#K`5HNJ+o|1X=U#b4-dr!kfgfbk3divslQ!OmVU1U}-{1$G=9f1p zd)Vy+v*WRl8b`Oey(WIJSk#EQ)I&7Sg{)#lY4m_oWAvq^mw1;cf75MLrazh~!vSXh z*B-83y=rEbwrTgrLDoF+QgZAK?qx@I&jyiRZ_=bq^6i7Kr*oK~@(`%HD0jcGc73J5 znVR_^tOdDRSZNSH^|PUWOs%)=K7j`pH{R`cAR)=CXObx%K_agk#3fX&AkNV`#lH=m@VA<`MAJBj&0Y2`4bHg_LoNhU+406 zYRTSZn6fvp=10xdm={s&z)|0x9Y9M*&!NM+bNc<6FAsu$h#)xLYi5_&T>#v|YUkwG zx*|Tkz_nN6y6KPp0MQSw2*Ut48UG6}L6$Q1joEGHYW)if{&V_?#`6mvH*Zu>xv;=S zT0fAvT>(6K@Z!gjINuU2_k5)Ta7WC5H7a2p06>6n)}J-E;;`1Z)JE^6u3#0mun7-yFhuoG_FbrmwCK&9jsTT67*a998GsXsWT zXocbUM!$tArBMiEB)-4Q8>K0{;RHfbGK>T|#ehFmResao09(vn{_nH9hp|?by1I8( z5XPTA^JSi#g{mr?sBVGlT9^)N1w_!#-ucOA;DzcbNSyo}=FmAORz_Ol zZ-=qW@@_xWUgW%F&9;|SLc6fF#Z?c}llyI5bQK_E#4@fMr$^(jmo66LPqJS_Nb1s9 z>g^?NkmIv9H((&q;9ovQa;K-}P~+_s9tYQLbuRjzB!pyeU$J3TY|}g>9+tSxoS2T9 zi)Ec$QZQ44z)jmTGE_!)+*`tHIF0U<6;sJa|7d%Ukr&k?ss)U<;q#=L-`TWTW#=BT z5KF^hlV<~kqCEnb_4yyxrzZ#vm*-{N!fuuPc3-7AtJLX~TvW=GpSMs+Um!kcALjPz zKsL@QY+B*P{3n&FN2lcnZw`YfA(RO%nUeLmG{n1&-40cfS-9c z2Z+S_n^R%TQ7_44uqd9D%eFLq#d;t5_^jWtt_0YY#8(|$X|4u7>YG$5#rR%vIPs6Q zAN!rZoxWhsxl`WAMpZ?o?`OmAO+))KUMrb&z@8Q+Asc3~+K=Lt?72{?5pcmJ;H-gf zpbL*C zh$cPJKNYT-1CwuRhgr#!0u&EOZDprBSd_g7XobCGEsvJy4CHw=`_#+U7A+(9_vOu7 zNkLFlBLDO!u&1` z4nu{O)}I zeeQvU>JOaBc|BT1P-tBYePcYtIl1V8RCi!<>AOsITexvT_cxS_bi*zd#xX)iPz&33 zm9||^SrJU*0tbRopFz*vRNDLeJmXCG`(@Eq5~Wx*o;`JELmHBCNMtNC-kyK8xbZSc zen9eoCZJnz%09`dn$aaH2#+Mpt#|dE|3_aQR`zGl@12?*_4KV?1%S8+g_==o#m2hW zcxu7T!#ThbkyW;=J}9_sSGX^q9l#ineBfAiP_R(a+^X^+k!<%ko(_>Rru=>YnD;|7r+ z>A0LYyPbCddWCevcS&98weIr6x=dqk^S>9&-9p2rpZVusE{S|_<-T8jGoGbG5I+}q ziwP<#*!BlkHjj*_oRDxM^&02F4I))6J7D~8Tv+{>b7}{$^-v9axBOU56@qzQ7DEn) zDCcU^l^={3#8Q1bRr=%(;S9xX{Jp@zexD5=$j!V>0h_XjN=hHQ0s zaMVKmpw3M4Chrr3V+DNgcVZ)|@;GpjW@Yy$fFgRc{w@?9k6e z9@+OBYfa}lv(aq}ZW{Y$e1O|#f$sUZLm@gDru5um^Cn_He zF839d1w^UIA2lFesdr~E#cFm-6wJ|CJe}S&9F;&PA7rfO_GvoCp~aIY{+!j+H@Jos z@-thv+TJ|Yb1#mY>Qr3P%Z+`um0OIK4$!?*raRc@pCraL;@!gw`#Vv9DGWwdC2a(YCpf* zaeHWINRQdupZ=-?F$>SHPK<$b@C^udn`M+cs=k0d}}$H|87-Jei!Xe3Lm6d zK!qJ!VH7n!Xd~+9G=#a`X)_SH)0EoN2~a$fE@g0k;XD|suE(!)6Jc8nN7)EW$`2RD+o-93 zbX(V@3u9GgWg?}OUn8=IzPjr(m)|Tuwgcd&Kdkdg?dUronbmeh8T>oaeBXUQ| zGOPhKq*8Us^8S8V67{8+SQ z&G38)PyQpKf)K7|&+xHFES!qvNsBD!=WC<~4nSGdh#~t7 zrc#7ZWD7HetRed{n99B<`#RZXgdxUY#w_nK)OmGX@B6&Zb3gYzAD?Q>zxn@<dIwNBgw;vkAM%+oe&vizB!R;j>=I(f^@ zLftKAbiaDUJ^<$}18_pr&xpKAg10$ z!b3gM5_xCn1w6nZRASU$eBmyu!C-3w&Sq!U8dWDLbiq_|z8k;`8B-BZb1J?I9F_u5 z>p(g903#PrYCbcAv$UZda}5ux4eK{|*uzl(^%(%H41g-mE7KBC;>At*A94(U#=t7j z-^-^U=qtc-rvW4MJedOaC@a=h{D|-FKXI$y3!O>8vNYff4kwx-gCRsnicAHQt~`N;H&-H8(E2zrHg|=n_~P)O?i)*7g)g*cR?B!Y9p@(DWa2 zOZC8OtF}h_L~`e8N6ftee$1F-ka)SH+Sj`D)DF7)P>j<;R%z?k4T|23g-ya})P zOBZ}eNjNTNFX$5;Q0r-KKI2xXIDnm)#L^?Wa;p}^YjOS6v7CoMRHr9txOE0vRDF@* zzGy%5C6gmpTB`boLGjCY{V^~S5%byF7uj9xrN5FlCmXQunGDO%F)QM^c2A_*{A=0W&>*u2|w zWwym%bf{DL>6ITG|7hHQGfyDMLIfkD1BX=-efk}ZE%)p`1|mtPO&|6h@UcobZ65^( zR-94GwItrzH|t*Q7Aqz2mVFwP$-nIn5Xb~PnYPod4wk(8`|AYkaS&(+rnNr^@|w_w zF4(q!GozlPT6nKj5E$*V^a7yo~)A-#%e2l=$Hlw$qXKVf4R#*#3jQ-(*nNH7U)_IFJiehEziXXtEN7_7rsUK`hUrYVkEe5S5=ne4q#7 z_kplfU>*RfUVi2UX?h)ae57oZHqOC=L!Lj$rz^h<2)&v9eCIdiQ&vHe%Y|#D25fao z6*uQ-EIaDm*z+2j!22vp0wD=D3+Pp=#5Mu2CB?MGhF`Mzuv)F@(U;E-5y!8FHhujR zu!-_*DdPdj1nn3t`cQm2`^>Z&xrjRaK?{WS^)+@t|J^=e%&Fse5FM=)OQ%OZ=Qi9PR=UP>nns6hpi{^c z4277#avYiaXi!B6IIFBgI99&JbXrHoxi%osSO$YgewafW3ANp}vx)#LqB@7q)?+zn za@DP9)a1d4^YGItGFApwLE?s#1TH=rM#afq4Mlmmo>z~WxXSYuY^^0!S|SU0v@e4` znV*${B&+aPNgU`645@0ig9&)vS$fm3$w^mhUZU@0?O47@ViL0h?3U+0<|^TTB|ZWo zF$OOalMPE^s|ZL|uTC!w##43Lz`dsm>X4V_Au^6R{*<}cb6CZ13B8V5uF<)W zjb_a0xYe)HTg!Azi37X+>^0Y3XLpwRlMAtB6at#sR;v|k_JgR5q-Li3e_O3Yx-OI# z$lA^cB|~xOdy2JZp+C6CP}X-q6iP6f5j=4_#9s6S_I_AuRTe!Rf4P+zt3_t!BevIO z!8CLef{Up#kuI8t7h!x&h5l4Kt z*MjNqee-tZoORTt+Mz z@+1zvpJ&tE59DjMY#&;<#WAmH1;$)~t*;PuTHd$DNlcUzP#~w|bunotzwd3@yVIk| zJr9L?W`l3{wlkN+nGe@~jyb$L!ZvK6b<8DrV7%_Z?k^7(txCMldVShq7bKkTr+s>`Soiy9Tn%{;e7tR5uP0sTqKU7BNoAJo_o+xq!hgi|GQ7PQ5jASZ zn3qAS;@88XNYc;fC<~qZH^21W+LhOu>FOwET1v`9iv^>gzwCJjl0m}KiLf5tM-Hcv zT>(DdWE6uFXU1W>Efy&zPqwc9J^e_%l~deKo%INXbr;IFiETcDw-h^T0iUX}sFyYu z0M@`-29z3b(WLU2OJ0_u#^ZtU(1CHio~_~rBP0j{4PzmXVh5&vp|PD0-B)8+j)$Z2 z5`ZZ~!BY!3`7@`_I?d{SICp6=B=;KymYR-&&&*mdsbAkIt9hIHQ>KzxZN>}|{?Y?o zcXqlpI63fP$6&jW|FaJq+lpgZA;7SrM(Hr9vG%Zoz*}k~ZuuVm zxXV&7x0IhwSE$x*n&{XCMWp)0@8-LC|7VCJ3jw;zIX|uHC^eTaAdkh4x)uk4e8{Vx z7bhCT@0*l5Ovprk*sWHXoSlT_Fy-JmUL7xGA8t&9`Itnl`Na0gOOlM1->cxhj<#jY{M7c zZ4(1z8Yjx4=vL0W$pdAZ6g}Q1zpJn=bn9x?OxKY((dyqn=CtYmBqsyCot38l9?v>^ zi=q0FE2RnN0#YXJW&LSufW8sVbwk2Nhr_*93|{`qtn_85PESvlO-8C$lXGCf=4)Fsbu#N}4*F?fEhJ|!aQ;siae$X&QoGT4>YuffbFu9-H_&}T z*qyev2o%!~3p8Bktm7As4W^hfM>d0AL<)>LZ1>z?h+TYgH@#`PL5Quea?yz$5E^L-h5X z-u4!{Nitl4qj}KBh{Z?M@Gt)}Vhc!tUrC|gZ(Z-+X82?Y0wltrot;x!nv~gWd*?eQ zPk{xx!Ba903q{_Hw$Fs$J37Tb-A}V3ldp3TFxjNZ<8iE0>AGn7yuC z-Nz{0-sJ_-mVb{(a1fgR1z2~ybC)&Cp=sQ9uN!$Fx-;!Q zkK<9dlxqnVTLjNbAMO^5M@SmrnJ^)Lu5K{?!Fzy`fF7lM+7Ep|hvIln2_uw44QXxs z`ahbujV56;&!M9ZA{&y);l;omL~G0m_4!A8!C%&&W}gh)vEJuRlrUj^#07pgp@!Ue z2O+Tz!|(%JC8&v5puiq1UBCP=AX2bycO%Z1Z~~YR>}P-mz+v<0b#0O+hXcJ;8s=$` zCr4j*ez_o(Kw9L)Xgh0d~UPxy{`D+bzU zwzT7hf7bLSz?gkO{B$jCuMs&7k_*!QFnL=sHjVu7}#a^M&tJ!f_iKev|$pn+s zw2~=2Cwy0Zf^%m{X)nC=Td7Nq8<>oz7NHyaLB>g-FNp@!!Xh5#ptIDOt+rXF5K=&b zFbN3)eDF1ifwIZ>Q_M>Bn^xGCJUJMY1ji=a7KO-GTxFT(?9nKh#s?b5#*gy$(KMvvT#sG5r~oqeyeS|9 zXkh^3NempCr+GNfwUv%C`(LPJH{oix{tGz?|*Ac zz5O~srZA;<@0W5o{+tIt6r3>(X%A%S+np>jqjo18W?Dy8nniA!1oh|`=dbI1c_Z!{?dNz zY$ND%J&IURD1OPa&wFDJ|LgJtFyFs9bRZFr-on@Tj8vEo$zERr;>3ov%de8KKCZ;x z3+J3(ZtQYk8*Yo{BnZMsw@DlcHm5ZStZYsH-R+EV;~P$k=fRpW8$?XUoZ;d8kZ}4dE%6R*zHnz z8K=Qzd;%?BC zIf#?6tj_=d`~Q@OL)!945fO2Xb>%~{lq20w&N38YM-DIZ z)nkX~>#MN}MO74h z7$1#tHn@nM_)2=~EI2-8lp1yCfyKKzM6Uj2gSvMFl?q-`ETO}HMQUKb(y)F`%v-+t zRKm5}1Z&1=QAs?w7PWD$+;P&@2uh0%m%n~(4k;JaK%2TxI#70GC^o(Q*DcGyElHQL zH^@yQ(=c(Rkx=E*XKzun#KpPt+cy1Y7eqpo387vl#j=QFQ4-?cNNdb}(IW@H?0eu_ zA==cw%M*EManDg3t?e-Tamvzb8_0G8E#2%w1;r6g@XIPGSAk~mB2_@PUlt(crBq)NuK zGs~vSy+he+UM9=U^Y2E7F0T$Ve3mc)#cp!^r5MCLfo=^#?X{vQpK*BREcJ=4s+liMh&bf|d5jL%#4b z@^FunN#izci_!K_6&TJ6WZHJ9A#glL zo>Z9iie&A@@r8gZyAdW0D4B4p~TbH(?aN z^%BP`uv4SXF}8^@E^_ilmDcTF*P{2Yn0nR^y?=XPXK|n5?NX0L-%QR0pH_=3rKAYT zUYU%cCU|jRe22tb`KXiGY5z#L9QrkX8oZ+}ER`nTgGu@jn|{m^@iG8@tOK8C- z)QM|0`UGxqb;Z>Erp#dW_<-Bz9-sVaqTW8ag_)8#zTNO*1!<$+Wc`kF zMs1mVP~uS~BB-*gRmQ;Qt*T_LA#+M2D73?P@^IyiiWG}7W5ed$?Lulrpwpe_1y2! z3?hj)kGm|Yy_qYaIcnUv-a&Nb1d^ymFxhKJaUZsLA(S!ej8K^?NBQMFTRK&)})`abW| z{_sHbQPXcRnlRs3pVh=l9Pf ze4EbRt4W~7TB>@n;Z3yf^21;Yp)XHi+gUaY_Qc!s1|{ciWg_r(gpQKaa~54wR=y1X z^VgQY&ZkaSR&tO~Ev_Yq^GvZw$oR0+O?N=jYXKS}A>6^!v}6^=UI#b9;!^tW%Ce6jd0GPh9(m^cw<7r&E9&M4}XLW6`scz zsvIaDQSKZ%RxR&AeKcD-v9ck_q`xaAl{W3ajxlAC$+GFCL87PiEjV8{@hu>bvgybX zzNlD17Gq=_(mV63g}@ri7n$$N!*yrs^hn-jZ)(OpP2Xe<-FRA6uYR6IZRkO)?-2I2 zdUBA&Ldlw((!#qD<}a>Th?qkiBslL)mdd?(8h$?f8Vw;f4JglrB~f zS!B^x&l44Q@pkAf;_*Y>HE%tOZyV(PNP5nddDlx$NL(vH(PW&tR8(Fe%6+y|thYW3 z==>1YRmw^Vu~zF#`(`}LcU}Vp&aX5>hTwTNg3sdItGzp>oNhiiCljvK;gM`zP^vVt z*TG;f*?QIV?`AEnrg`62Mn`JeXA4z^zpe{l1ZzJIJ;^2%XdhBI;%NQNZ9swUY75zp z+Z1VsB4&qteB|2mzP@GIX2-jUr-`o9B`5icZgl8HsTB3mSuF7xr7+cQ^-M+(Fg4$LDRPM4 zX__xt%bP}pPNxFtU^w*V*Y$iusG$)~$nyN|WHazci$6-d?{yxJ9k=H0Hn&!R^AUhP zE)A9EbyXfU$e4Jvw@yw7cEhU0&_gkU5bXVGaCsE4L*NMKGD>hdJ>AC3-2LXT3y0ZJ zumVRD9eMlEx%4v?Ttm)#Jv+$hCxiJwVw1o*1@Yh7eG&PLx?)N*D8e+hfi=Is-GCaR zzna@B{!Pr}sjR2TPokx~1xn#Ga)Kh6lzcwx1vs6|?=%RPsmo*Ulswn%4gY^tdRa=e zD>h7(GtSSUFDHp{E_6=kP@ht>WqTm20Q)1qJ%@VF4S^#$$u=+_U1k~Ka~huOYy=cX zx4C$(GltX2b++VSx1N&4(Hhj=-1boOv*SBvlSDmZYxg6Zd@G1EA4M~Ql!(%t-Nc7z zO|$JDchX^p(d|3QrtU((GCf^bHy>GM3FC}%4#hT*gL)C%fKyfmFMOlCt>Fl2=lW5i ziQEH-@^&g=T$SZm5P}&;<|HDNOZ}e316@vjziNuj3AF@f&k6k1?xfM1o!OU}TRdFb zI57s}fmOoi6iU}mP6LpE&{YM#xDaz{TA^>Jg}sM7rvld;Y8NolsE6~Z=FIjXzk|!p zq1+NkpTUuXriCg<&XqV5-aI5QgEv&W2S>M$pVjPm7X^4IV24;bT`ogm!$vz+6Ppg2 zxZ=s_&XtRZN!a<28GkT)^m(b~BHIZ?q}1I{kH9<=cMlIy!;dEu+B6enG;%Tu?oha+ zKLv|Cnka;TLLrbkq<7kX>L_+(2D?yyJ>7%zZ?0mo`jM4y7}45F!g$_^0flwgDIs97 zVgxhKskb8LXL1g9j~Oa(bnf@Ka9>=n3MQ7TCy{t1mv2w7_vaAj3=^LMSfoQi?Yp7q zHbTWJa3_MjeK;3V+j@>M2M!Iz+Alh1+lGP*Y)TpxZ$ua|CBJcY*TgNGz8rZu*WSQX z5tchyUO#+JKhp##_?XMg<=4C~O-J-|ID2e@JI?eyo3q&`CoU@hJ2P&dp|OzA-h+BR z5cw8*L&d&ZG;|J?`bNZcx_o5k=bo^)^K~|#{1B+uvG%VlOM~@hV$L1_?hG*w3!D_w zVq@T){-*k-AxdiHwSd5pjr(qRLEupKC@H)S1B>a-CKR{gbfe*^^6}VmfM2U^r4xigH#%_q3Y7~B=xEHmT4KqvqekG6HuF>!kpg*8U{77Mw97EB3GO|hSeCra zQAuRVn}1!kMFEUM{8NGQfRf*TUeir~f;)S@bb}7Oo6ob+>E_bEU(4D(mFNtRBiRlb zT>bNUN#V|gs%RfM%CcTJBAkB!Hd`K{Ua*c!HyHFO`scrFIS&%x9+sQRBNn5F;_Jt`Fz!%+p;BO`Ue5~ z0|%w2BdNjjDlT^WWNsl9#%(*Yu4&Lmr>a_Wa(M|x;E7sU2n?3d4WbO;JXexOpB_?| z-?4c8#62l8lB7Awr9SY}^_wiibKnOHPdLX(@hcU2gJDyLp5=Kvf0w>cn$@c^OC zez=d~Uh?a)D$^G^^dBysviat^o#Sb_wnU)VnI(wD6+)sobH*UgUEql|9!5ox>kfyF z#xI(oitQ9GF#->V>Efz^=n;PP+du;N-rNXg_2*d4jK=x=TAhPhsS>EYCl2ZSLi8j~ zL9-s#InRv?e3%?pZcLrnb$XXuiq$@|8(^24Z0=;f{zcVbmlIu8nQ3XEOggS_)R&a_ zIUqqTf)VW)aL_i1iHA8iCf-~ATMN@srQc0mNY}ck$&D;7=iOK!OAZ=%uo`%5>)!Xj zzx5)=@y=8-phx@ z=xT*gRcsyJjidF#v#knt1hQ(#%zd!kH5AyR6V@S{)eI-kO{(eT_J^7IK8-f@-4*Z7 zqqN=9S@*@ey*KeNIF+1k!%*$c^Cvf3&{VKOI_4fu`bD}7{HrD}MzLjL97W6i>3c`t zw9?Mm1uPPmJllR~=m#aCXMzoF#deQT;?&B{f5N8+(oWNbhTWBn=v{L54HdBXeQ*A%?3d$XG1!YPJ0fn&+-liMvRRc6h7t7rFrmc^<)A6>2ROcZFg_A-a1X7CyO!PE|c|0gsH z8hV|R8aKhcnI25jogzV&WOZ_jn*F-IRoN)kCt>4#>2*~v#Lb3OBNy!J9FpW0_u9RUqTH9wIWm8IBLm#zpMP$3uXiN_8U+G}m2 zHF9Vv$-k=i7Q1)jmiDHQseMYzXg-R`4~_U38OnYtDqP_C$=0wC3HMVVFu#FSZKmaU z+*u)~&zDVL#j4j#`po+9gD0;8$neYiw7FvaK>Qbus5&PD20lJpi==8|Ud1r2xk0DN zIBMfz)k{_6XZz2DKMeNILK59p6@QRUrA|*ixD{mk|(HR2y zYg^k&jfS!d_-0{gvzfd;@mao%w24{46ZPfT#AK(Fv$=CuN!Roae^80XYWtO_+j-6D z{4fk%aeJ4+X9|J>Yj^**9FduhW&-l9;Hc(!Pk?n_v1W^q(lVZqN4}6kTA#g3WwfR8 zGk%`ZYNNj|4wEtzXjwEYNKBwSconWhQQ`c`IzX*NenSQx{)Q`UFSAZ^ zBot+%J0Wi~P)2}iO_6&tB+~AcRxz^ozS!$et}xzY)vNFSgH<{BK2xrw^fzSU({ogv ztBtSG7H4vgDRY4U;h&NI?wiLc3CtB70|EI0Nlttf8zfsjI&_giZEwnT8!KCac#Xir zEte~ny=Kh)^|Tpyuh^9(P;dNtR$S&qH+1-cDBC1#@`u~xZp8fh=oICGy|%7a-b+ft z2*!&aWGz(f-u)Q+I(p41C!y71WpV*Nu1{eXKs^CSNk`o&SBp^-?6!3VXDh5>_XJeM z2~~a~z}n<9kDEf+Jqs5*KeY%XmOI-FG z(W~Ej!FA4h*%HI#C^AymPx+w!LhA+U(zV?v?p%r!KUvcJwCzVb&1Fo^xj?a0)plIs z!)761C-s?mxvhe=568zf35Z>KfvtcquXVjR49L5O;%U!NH9wyP$h#+5OYb$-hfH1m5IMA*}^EnXr0nb?~N`zpOtR#>Q_O5B(l)4Pply#@e}`r z9*R$t;EEWsM+&(mnyHTV-ZLKj+FNYNtLr*lRR}ZJ=jgZ}%PSbfJR%+6)$Jit*BSOX z-=j^U5M2kiRbclEpj=t+F_@`-7e@~!Eu?L7%gtY^&tWp+;}JKhj-49SVY?@or&3qr zjcPbQ3wnA?`5Ie7<(K7JbB%Ph7-|VUq{kLU@Jahd{ z35U!q0>vX>{_2OjF&;MR8{@zu%3x-^!w(rq4n=JT804s&?N5)yH`6(b*+*@=e)rQthQmhLAyu zSsnVu;(DM6>6Eay+uQTN$ol_n|&ab40cdKM%K1cn4lQ2QfNIUhOTpAw4i4)r(QD^+>&V|0)3lcFZEJknL z>RY=7>+~G#>9`k`3mOrqrL~t8b?gpwy@u|HsB~^shVoFN@=zm~*qGEzFqgPdAiKc~ z4i~Rk>(UV~x0+Oj(#FgT{KzeWE0XY}F3$vBHegTYizRrB2UjJHoeG)h1e=$FX4(zO z4S6k$BBp-^W%3cKKd(T-^Ci%T`DYWptgMq(WN-xY7pZfRrzB~KO8iBB{2b~z{OOPcI zNv`m?55*wgH<{0SY-jBL8MpD>R?j-Kz0e)f5piW-6nQn@Q@FLc7igbX6Yij?I&Ro{ zH0shcOsy4_9CRO~LzmntXIQ!B9mbB1IizRsnfx{Y1}O<5RXdU!i^7sC4 zX|VgA-jh*-w_6${cdBtX66yV3O?%}%b&aMVDs2JB>`-#%=fX3SSKjja&3f;sy4V&V zCUc(0qFjFn>tD9lt(7j@a}H(JE2CI=cDlOVbCoxVWR&Z%Kh~GCz3;>yr*q_J@-N-6 zpT?nI-I@e^*OboTgns2QWnGGd?mL4~`Yi8H-*MxVrS*f7bM_3o`}`+Blt;Q-#wiD< z=9AUTtxEn;wQ{xB*ohf#Z#h5w=6?Hu3{`}b!NBUb6MGA9ye^02KbC>!q-2t_rWqI` zhT2zQ>A3Nd9tiphUfvgFpT+-~BnbV{A56M2uv1&^PP@RYw}?}8Ie&t`OQv(|!th77 zVV`?@-dBC%ZBXwtU;n&wP#bSYhP%yb0*eJC%ueP063$evdC!oUeBcoldJJI}VwspS zs%SHV*hby0yEbM?XAp+V8rk_~A;#-m4I%zMM>hpU9aRO?^H8O!zJ!`4i>rG9j*?4M zVzfIkd&}^#0zGa;{Gs{MSMx*HirdGCkigeFb{H?y^DWfo7p208LwNDwfce1=8Yl52k^x zle(rIrhacM6MH;^FiFX9=idlM7ZF4{yFhIVn$#zvtpv^14JP(1_>6a6peD648`5XX z4Y7Gc*xMEU{B5xBRE`X&INHL&)(Erb*nYI%8`}fg&+TXW3n%P-?%KCXmKLGkkma71 zy!V(}7M#CQFvTM$Y(u%FJ^N_z@VC;|-QO?sBrgkCX>4=a=J;iL-M#%VLH%mmem`b- z>6cy6wRob!&J@riC}-G1cQ;1qUvJU!oY_J_=$$E2s(6p>|`&y6|35D>9nrE%v( zloxe)>%KGpZAyC%$9ARy}y0ctR>(w@*7`hK383NSO2JBGx zDC1wpV5rkz?w0KO#h|)$ut!r{p&Y;%qodUJ^@Rn-_wSZ^y;?6Y1_Z9XWW=msgK_y~ zHIWyzs*+xZ<7+K?6j8Nyp%2vW-v=>mxKQ4q1Y4#J=?-R($+*yS!SPj7_i#dSGc^ew zUX_oFI;7YCpqSiJHR01FiB3|GEZCD`InuK3{$ZqIVM^3Mux%tu1$)Xv5$9_#5>!K~ zB@1v<`?YOjI*#m5)b^y@64f4bY%6@cPM($b#T(PVA`awE%;y%5mU9^PUKjPVpa?hW zL}V+-88iv5BMJ>{tD*mwaUkSdtW2(x37camQOFoa?d*65DAj=C%!ddOa8 zHaJ}#WQJ_6uCa|-4G#T=Mi|xH%kfz5%GYdi)Kv|(-w#@nAk@DWTTb;pK%~e{3JX*DL zSnF-84;Fnt@!3-Nm1cw28&|tZ)d!`>2|q_aFY^fTugE;x&l6!1cLNoypAaF?0#F@qT`|o>vTG`%rl#*Y#%*MXw;^NTdKeQ(_3PRtv5}$ z*G5=OQLN?ij33otp>k?#AFyD5u=LRs(Me93DdxkZg;;mZ7_OkbH5r^zVI0 z?XUdZgZ3 zy}=1;^}d`tTD@@I9o4x)zpY$w2pN&TEZv!{{FXk7sHIC4(A0;%<8N>$p(68Pvj)}t z*WhfXunzWOL_c{Cj~-4i7s)W~y$FXs_WGd5ePn*#bQa29H8q-U6mB$08ULhU;;UE` zk?R}rc0s^6j54+)=L>e9n`hy!>;c=x*hp#j(E(fHuvEKlX*08jDCQ@LNze6pJwiG& z`M4yjA9J1jw|vTD0ks3}RcvaS3|kNi1sqV=n*YXn1$xV%={G#P*}8C!)`nPEQ2hD% zlpa3f@nf&NW^vA$CJuav^uxv7q@68MgT~pm-zW9(MCo2Fp@zZJ#eY8#g>XW5cJnoh zEgqSS=y2(%6Ct@KvD=p%OF?}#PVA_Y_zQl&qsluTK^h34BorW_^a>k=L@2uyy zmd@M0h!fyyb0)xs9Lat&9odyY*^4uUvKTj(;&lsXX)){GSLWwYr1otN^vHBxc*mIM z@JMm5!mGcdM~w2m3c17o{=S_2Sy!v>M}Tz z>y>K4w8t@BA66Q4mtDS(xGlrj>qsZaPrYReKpMuw=pL(fo2V4Dg2(jrU`^u)NA}pV zu@g64Yv9{B{+EFJqRbo3bX$fUDJExuIIQO_Cxd*s=ATbo^O>MHwNmyblDjf~)-;)N zucfFAYcqx=kz;!)h0QuF^>K(=9ydjiHhxVe-B}m9N6+Ym&%@2L&qcf}onjZvA!X0= zz3204&-kKc>nK&8!G7Zvu5X)ue8ZR5$m?oQ5>$v3;pqH>p{67_=)s$mLR_wVWGl>W<3 zki?x=M&BE_Sh`weSIo?(51}R7X$+cIo1PhO4b(QZ8hbapQvJvj@Y)fdrqpWZIX)_W z?Sdd4K2`W@p8XS1ulJFhVlzo3kYCj;Ck5TEF)&fuZ8qlgo8(1)^E$OLfF&t(wyY2rrm~*)B*k0@$en_o}GNN`>l3F}#!0@&^@S zd`0+MQ}_L8{;AiEBC?^b>j_W3^zl1LQOX?W`HYT1u&!wpdj5IN5?9Dx>OR9nPQMxB z1?^mAkqc{A5zWKFGDrL9OWA>o(THBd&;%ru>ORqxf*N+n9h6*U%XgtKK(a+KI^$FK zH7|mZ*2*2nZCCW&O%!=0;-_wPnG0E2(~pz8-xb0$;LcDBY1H80HQc|VGIScGo&U4@V0dGLPNT*SU9eayhJ;Z(@YggAdGxktXxhq zfd)9Oe81e##h}c1A0b5eRLL71uQG#fUs~V^oi6NYqFI;w=OR{rTrRNdS?MRg1aLuC zQBC^v&c^cI#R@5dD+gX8+D%qHT2(txWM0|%c}(xnPNQ~;c$vA}{JO(XD5qCxlK4Rn zuD+<^iU!)B>P{H@%Ww}{=ZG;wX=dx45%EYbz%#1$LUwQeNK1y(7(6J68F*M6a8(Yz;yv;A~glPv&4+^?+r=g=-gP z8)ezfXkB6pk2pD474XBaY1*rk?bKb=_Nwg}_nH@ah~9c{Xz976uaigZJU%^MiE%@9 zUqV{9dy?Lnh3XTg3QJ5(OA+&5UFE+VH@$%(0Ki#SnN#QWzkrnUAt5(^nOSSQE|jx^OXA@tkLu>faqEZJ zlw{{u6jO5_Z(A^q#xB-Qibup*mzcO7BGqR#S@2!_8WD#pdj+OM z$jVlreCz~Nw8M1AJ&5r4EvG?5a8W4j{Gays(WuCOg_~Gtw>giJaK^X%24TqK?F}MZS?LVCuaJSC2`$jvTgv-~hxwUPlVDQPWZG5jfgzt;abk?m+3r

    | A scrutinee is the expression that is matched on in `match` expressions and similar pattern matching constructs. For example, in `match x { A => 1, B => 2 }`, the expression `x` is the scrutinee. -sess | The compiler session, which stores global data used throughout compilation -side tables | Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. -sigil | Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. -soundness | A technical term in type theory. Roughly, if a type system is sound, then a program that type-checks is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). -span | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. -substs | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). -sysroot | The directory for build artifacts that are loaded by the compiler at runtime. ([see more](../building/bootstrapping.html#what-is-a-sysroot)) -tag | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). -tcx | The "typing context" (`TyCtxt`), main data structure of the compiler. ([see more](../ty.md)) -`'tcx` | The lifetime of the allocation arenas used by `TyCtxt`. Most data interned during a compilation session will use this lifetime with the exception of HIR data which uses the `'hir` lifetime. ([see more](../ty.md)) -token | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.md)). -[TLS] | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. -trait reference | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.md#trait-ref)) -trans | Short for "translation", the code to translate MIR into LLVM IR. Renamed to codegen. -`Ty` | The internal representation of a type. ([see more](../ty.md)) -TyCtxt | The data structure often referred to as [tcx](#tcx) in code which provides access to session data and the query system. -UFCS | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.md)) -uninhabited type | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". -upvar | A variable captured by a closure from outside the closure. -variance | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.md#variance) for a more general explanation. See the [variance chapter](../variance.md) for an explanation of how type checking handles variance. -variant index | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). -wide pointer | A pointer with additional metadata. See "fat pointer" for more. -ZST | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. + +Term | Meaning +------------------------------------------------------|-------- +arena/arena allocation   | An _arena_ is a large memory buffer from which other memory allocations are made. This style of allocation is called _arena allocation_. See [this chapter](../memory.md) for more info. +AST   | The abstract syntax tree produced by the `rustc_ast` crate; reflects user syntax very closely. +binder   | A "binder" is a place where a variable or type is declared; for example, the `` is a binder for the generic type parameter `T` in `fn foo(..)`, and \|`a`\|` ...` is a binder for the parameter `a`. See [the background chapter for more](./background.md#free-vs-bound). +BodyId   | An identifier that refers to a specific body (definition of a function or constant) in the crate. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). +bound variable   | A "bound variable" is one that is declared within an expression/term. For example, the variable `a` is bound within the closure expression \|`a`\|` a * 2`. See [the background chapter for more](./background.md#free-vs-bound) +codegen   | The code to translate MIR into LLVM IR. +codegen unit   | When we produce LLVM IR, we group the Rust code into a number of codegen units (sometimes abbreviated as CGUs). Each of these units is processed by LLVM independently from one another, enabling parallelism. They are also the unit of incremental re-use. ([see more](../backend/codegen.md)) +completeness   | A technical term in type theory, it means that every type-safe program also type-checks. Having both soundness and completeness is very hard, and usually soundness is more important. (see "soundness"). +control-flow graph   | A representation of the control-flow of a program; see [the background chapter for more](./background.md#cfg) +CTFE   | Short for Compile-Time Function Evaluation, this is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.md)) +cx   | We tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc. +ctxt   | We also use "ctxt" as an abbreviation for context, e.g. [`TyCtxt`](#TyCtxt). See also [cx](#cx) or [tcx](#tcx). +DAG   | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.md)) +data-flow analysis   | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.md#dataflow). +DeBruijn Index   | A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) +DefId   | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). +discriminant   | The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). +double pointer   | A pointer with additional metadata. See "fat pointer" for more. +drop glue   | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. +DST   | Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`). +early-bound lifetime   | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) +empty type   | see "uninhabited type". +fat pointer   | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers". +free variable   | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.md#free-vs-bound) +generics   | The set of generic type parameters defined on a type or item. +HIR   | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.md)) +HirId   | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). +HIR map   | The HIR map, accessible via `tcx.hir()`, allows you to quickly navigate the HIR and convert between various forms of identifiers. +ICE   | Short for internal compiler error, this is when the compiler crashes. +ICH   | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. +infcx   | The type inference context (`InferCtxt`). (see `rustc_middle::infer`) +inference variable   | When doing type or region inference, an "inference variable" is a kind of special type/region that represents what you are trying to infer. Think of X in algebra. For example, if we are trying to infer the type of a variable in a program, we create an inference variable to represent that unknown type. +intern   | Interning refers to storing certain frequently-used constant data, such as strings, and then referring to the data by an identifier (e.g. a `Symbol`) rather than the data itself, to reduce memory usage and number of allocations. See [this chapter](../memory.md) for more info. +intrinsic   | Intrinsics are special functions that are implemented in the compiler itself but exposed (often unstably) to users. They do magical and dangerous things. (See [`std::intrinsics`](https://doc.rust-lang.org/std/intrinsics/index.html)) +IR   | Short for Intermediate Representation, a general term in compilers. During compilation, the code is transformed from raw source (ASCII text) to various IRs. In Rust, these are primarily HIR, MIR, and LLVM IR. Each IR is well-suited for some set of computations. For example, MIR is well-suited for the borrow checker, and LLVM IR is well-suited for codegen because LLVM accepts it. +IRLO   | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org). +item   | A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type. +lang item   | Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html)) +late-bound lifetime   | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions)) +local crate   | The crate currently being compiled. This is in contrast to "upstream crates" which refer to dependencies of the local crate. +LTO   | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto]. +[LLVM]   | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports. +memoization   | The process of storing the results of (pure) computations (such as pure function calls) to avoid having to repeat them in the future. This is typically a trade-off between execution speed and memory usage. +MIR   | The Mid-level IR that is created after type-checking for use by borrowck and codegen. ([see more](../mir/index.md)) +miri   | An interpreter for MIR used for constant evaluation. ([see more](../miri.md)) +monomorphization   | The process of taking generic implementations of types and functions and instantiating them with concrete types. For example, in the code we might have `Vec`, but in the final executable, we will have a copy of the `Vec` code for every concrete type used in the program (e.g. a copy for `Vec`, a copy for `Vec`, etc). +normalize   | A general term for converting to a more canonical form, but in the case of rustc typically refers to [associated type normalization](../traits/goals-and-clauses.md#normalizeprojection---type). +newtype   | A wrapper around some other type (e.g., `struct Foo(T)` is a "newtype" for `T`). This is commonly used in Rust to give a stronger type for indices. +niche   | Invalid bit patterns for a type *that can be used* for layout optimizations. Some types cannot have certain bit patterns. For example, the `NonZero*` integers or the reference `&T` cannot be represented by a 0 bitstring. This means the compiler can perform layout optimizations by taking advantage of the invalid "niche value". An example application for this is the [*Discriminant elision on `Option`-like enums*](https://rust-lang.github.io/unsafe-code-guidelines/layout/enums.html#discriminant-elision-on-option-like-enums), which allows using a type's niche as the ["tag"](#tag) for an `enum` without requiring a separate field. +NLL   | Short for [non-lexical lifetimes](../borrow_check/region_inference.md), this is an extension to Rust's borrowing system to make it be based on the control-flow graph. +node-id or NodeId   | An index identifying a particular node in the AST or HIR; gradually being phased out and replaced with `HirId`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). +obligation   | Something that must be proven by the trait system. ([see more](../traits/resolution.md)) +placeholder   | **NOTE: skolemization is deprecated by placeholder** a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on placeholder and universes](../borrow_check/region_inference/placeholders_and_universes.md) for more details. +point   | Used in the NLL analysis to refer to some particular location in the MIR; typically used to refer to a node in the control-flow graph. +polymorphize   | An optimization that avoids unnecessary monomorphisation. ([see more](../backend/monomorph.md#polymorphization)) +projection   | A general term for a "relative path", e.g. `x.f` is a "field projection", and `T::Item` is an ["associated type projection"](../traits/goals-and-clauses.md#trait-ref). +promoted constants   | Constants extracted from a function and lifted to static scope; see [this section](../mir/index.md#promoted) for more details. +provider   | The function that executes a query. ([see more](../query.md)) +quantified   | In math or logic, existential and universal quantification are used to ask questions like "is there any type T for which is true?" or "is this true for all types T?"; see [the background chapter for more](./background.md#quantified). +query   | A sub-computation during compilation. Query results can be cached in the current session or to disk for incremental compilation. ([see more](../query.md)) +recovery   | Recovery refers to handling invalid syntax during parsing (e.g. a missing comma) and continuing to parse the AST. This avoid showing spurious errors to the user (e.g. showing 'missing field' errors when the struct definition contains errors). +region   | Another term for "lifetime" often used in the literature and in the borrow checker. +rib   | A data structure in the name resolver that keeps track of a single scope for names. ([see more](../name-resolution.md)) +scrutinee
      | A scrutinee is the expression that is matched on in `match` expressions and similar pattern matching constructs. For example, in `match x { A => 1, B => 2 }`, the expression `x` is the scrutinee. +sess   | The compiler session, which stores global data used throughout compilation +side tables   | Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. +sigil   | Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. +soundness   | A technical term in type theory. Roughly, if a type system is sound, then a program that type-checks is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). +span   | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. +substs   | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). +sysroot   | The directory for build artifacts that are loaded by the compiler at runtime. ([see more](../building/bootstrapping.html#what-is-a-sysroot)) +tag   | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). +tcx   | The "typing context" (`TyCtxt`), main data structure of the compiler. ([see more](../ty.md)) +`'tcx`   | The lifetime of the allocation arenas used by `TyCtxt`. Most data interned during a compilation session will use this lifetime with the exception of HIR data which uses the `'hir` lifetime. ([see more](../ty.md)) +token   | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.md)). +[TLS]   | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. +trait reference   | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.md#trait-ref)) +trans   | Short for "translation", the code to translate MIR into LLVM IR. Renamed to codegen. +`Ty`   | The internal representation of a type. ([see more](../ty.md)) +TyCtxt   | The data structure often referred to as [tcx](#tcx) in code which provides access to session data and the query system. +UFCS   | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.md)) +uninhabited type   | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". +upvar   | A variable captured by a closure from outside the closure. +variance   | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.md#variance) for a more general explanation. See the [variance chapter](../variance.md) for an explanation of how type checking handles variance. +variant index   | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). +wide pointer   | A pointer with additional metadata. See "fat pointer" for more. +ZST   | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. [LLVM]: https://llvm.org/ [lto]: https://llvm.org/docs/LinkTimeOptimization.html From 48d01f867d4dcf7a0852412c6fe26997fe5a0831 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jes=C3=BAs=20Hern=C3=A1ndez?= Date: Thu, 24 Jun 2021 18:50:50 +0200 Subject: [PATCH 1495/1812] Remove requests or suggestions about rebase and fixup contradictory to rust-highfive bot comment (#1111) --- src/contributing.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index d8f7a79a1..9df9b6dfc 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -145,8 +145,7 @@ CI will also run tidy and will fail if tidy fails. Rust follows a _no merge-commit policy_, meaning, when you encounter merge conflicts you are expected to always rebase instead of merging. E.g. always use rebase when bringing the latest changes from the master branch to your feature -branch. Also, please make sure that fixup commits are squashed into other -related commits with meaningful commit messages. +branch. If you encounter merge conflicts or when a reviewer asks you to perform some changes, your PR will get marked as `S-waiting-on-author`. When you resolve From c319110e8de2c4b46c62bb4e8c9c1c755348e825 Mon Sep 17 00:00:00 2001 From: Smittyvb Date: Tue, 29 Jun 2021 12:41:13 -0400 Subject: [PATCH 1496/1812] Document how to mark features as incomplete (#1151) * Document how to mark features as incomplete This was changed in https://github.com/rust-lang/rust/pull/86446 so that incompleteness is included in the delcaration. * Footerify link --- src/feature-gates.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/feature-gates.md b/src/feature-gates.md index db6c72ff8..229281f2f 100644 --- a/src/feature-gates.md +++ b/src/feature-gates.md @@ -27,6 +27,14 @@ For example: (active, non_ascii_idents, "1.0.0", Some(55467), None), ``` +Features can be marked as incomplete, and trigger the warn-by-default [`incomplete_features` lint] +by setting their type to `incomplete`: + +```rust,ignore +/// Allows unsized rvalues at arguments and parameters. +(incomplete, unsized_locals, "1.30.0", Some(48055), None), +``` + When added, the current version should be the one for the current nightly. Once the feature is moved to `accepted.rs`, the version is changed to that nightly version. @@ -99,4 +107,5 @@ updating the declaration! ["Stability in code"]: ./implementing_new_features.md#stability-in-code +[`incomplete_features` lint]: https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#incomplete-features ["Updating the feature-gate listing"]: ./stabilization_guide.md#updating-the-feature-gate-listing From 84779866ff9ca7f7469b0390e6b83eaee45778dc Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Thu, 1 Jul 2021 04:19:06 -0700 Subject: [PATCH 1497/1812] Links from rustc-dev-guide to std-dev-guide (#1152) --- README.md | 3 +++ src/about-this-guide.md | 2 ++ 2 files changed, 5 insertions(+) diff --git a/README.md b/README.md index 99502bcc6..006ea3231 100644 --- a/README.md +++ b/README.md @@ -14,6 +14,9 @@ for the docs you're looking for instead of reading them top to bottom. [rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc +For documentation on developing the standard library, see +[`std-dev-guide`](https://std-dev-guide.rust-lang.org/). + ### Contributing to the guide The guide is useful today, but it has a lot of work still to go. diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 3f32659b7..3fa397ae4 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -60,8 +60,10 @@ You might also find the following sites useful: - [Forge] -- contains documentation about rust infrastructure, team procedures, and more - [compiler-team] -- the home-base for the rust compiler team, with description of the team procedures, active working groups, and the team calendar. +- [std-dev-guide] -- a similar guide for developing the standard library. [GitHub repository]: https://github.com/rust-lang/rustc-dev-guide/ [rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ [Forge]: https://forge.rust-lang.org/ [compiler-team]: https://github.com/rust-lang/compiler-team/ +[std-dev-guide]: https://std-dev-guide.rust-lang.org/ From ea66b238e47f4ffc6f5c35a9ce4d3f231be22eee Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Fri, 2 Jul 2021 10:43:12 +0200 Subject: [PATCH 1498/1812] Create issues for many TODOs (#1163) * Create issues for many TODOs * Update src/crates-io.md Co-authored-by: Joshua Nelson * Update src/backend/inline-asm.md Co-authored-by: Yuki Okushi Co-authored-by: Joshua Nelson Co-authored-by: Yuki Okushi --- src/ast-validation.md | 2 +- src/backend/inline-asm.md | 5 +++-- src/crates-io.md | 4 +++- src/debugging-support-in-rustc.md | 3 +-- src/feature-gate-ck.md | 2 +- src/hir-debugging.md | 2 +- src/identifiers.md | 2 +- src/macro-expansion.md | 4 ++-- src/name-resolution.md | 2 +- src/type-checking.md | 2 +- 10 files changed, 15 insertions(+), 13 deletions(-) diff --git a/src/ast-validation.md b/src/ast-validation.md index 64e35bb93..ff549ca62 100644 --- a/src/ast-validation.md +++ b/src/ast-validation.md @@ -3,4 +3,4 @@ AST validation is the process of checking various correctness properties about the AST after macro expansion. -**TODO**: write this chapter. +**TODO**: write this chapter. [#656](https://github.com/rust-lang/rustc-dev-guide/issues/656) diff --git a/src/backend/inline-asm.md b/src/backend/inline-asm.md index 0cae01ef3..f1a64b5ee 100644 --- a/src/backend/inline-asm.md +++ b/src/backend/inline-asm.md @@ -1,4 +1,5 @@ # Inline Assembly -**TODO: You can find more info in -https://github.com/rust-lang/rust/pull/69171#issue-375572066** +**TODO**: You can find more info +[here](https://github.com/rust-lang/rust/pull/69171#issue-375572066) +[#1162](https://github.com/rust-lang/rustc-dev-guide/issues/1162) diff --git a/src/crates-io.md b/src/crates-io.md index 6fbabdc91..bc59bfeed 100644 --- a/src/crates-io.md +++ b/src/crates-io.md @@ -12,7 +12,9 @@ reasons: - The dependency may have transitive dependencies that have one of the above problems. -TODO: what is the vetting process? +As of July 2021, there is no official policy for vetting +new dependencies to the compiler. Generally, new dependencies are not added +to the compiler unless there is a good reason to do so. ## Permitted dependencies diff --git a/src/debugging-support-in-rustc.md b/src/debugging-support-in-rustc.md index 559031148..9d455084d 100644 --- a/src/debugging-support-in-rustc.md +++ b/src/debugging-support-in-rustc.md @@ -314,8 +314,7 @@ Clang always embeds an MD5 checksum, though this does not appear in documentatio * New demangler in `libiberty` (gcc source tree). * New demangler in LLVM or LLDB. -**TODO**: Check the location of the demangler source. -[Question on Github](https://github.com/rust-lang/rustc-dev-guide/pull/316#discussion_r283062536). +**TODO**: Check the location of the demangler source. [#1157](https://github.com/rust-lang/rustc-dev-guide/issues/1157) #### Reuse Rust compiler for expressions diff --git a/src/feature-gate-ck.md b/src/feature-gate-ck.md index 3b3a07a31..c17747a11 100644 --- a/src/feature-gate-ck.md +++ b/src/feature-gate-ck.md @@ -1,3 +1,3 @@ # Feature Gate Checking -**TODO**: this chapter +**TODO**: this chapter [#1158](https://github.com/rust-lang/rustc-dev-guide/issues/1158) diff --git a/src/hir-debugging.md b/src/hir-debugging.md index 519ff2667..8788ad4de 100644 --- a/src/hir-debugging.md +++ b/src/hir-debugging.md @@ -5,4 +5,4 @@ The `-Z unpretty=hir-tree` flag will dump out the HIR. If you are trying to correlate `NodeId`s or `DefId`s with source code, the `--pretty expanded,identified` flag may be useful. -TODO: anything else? +TODO: anything else? [#1159](https://github.com/rust-lang/rustc-dev-guide/issues/1159) diff --git a/src/identifiers.md b/src/identifiers.md index 50d0c76e2..18a3efefc 100644 --- a/src/identifiers.md +++ b/src/identifiers.md @@ -82,7 +82,7 @@ See the [HIR chapter][hir-map] for more detailed information. - [`Promoted`] identifies a promoted constant within another item (related to const evaluation). Note: it is unique only locally within the item, so it should be associated with a `DefId`. - [`GlobalId`] will give you a more specific identifier (TODO). + [`GlobalId`] will give you a more specific identifier. - [`GlobalId`] identifies a global variable: a `const`, a `static`, a `const fn` where all arguments are [zero-sized types], or a promoted constant. diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 7385cefb3..ce8285283 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -608,10 +608,10 @@ Because the Rust ABI is unstable, we use the C ABI for this conversion. [pm]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/proc_macro/index.html [pms]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/proc_macro_server/index.html -TODO: more here. +TODO: more here. [#1160](https://github.com/rust-lang/rustc-dev-guide/issues/1160) ### Custom Derive Custom derives are a special type of proc macro. -TODO: more? +TODO: more? [#1160](https://github.com/rust-lang/rustc-dev-guide/issues/1160) diff --git a/src/name-resolution.md b/src/name-resolution.md index 2eb76384c..1cef7d08f 100644 --- a/src/name-resolution.md +++ b/src/name-resolution.md @@ -164,7 +164,7 @@ To tell the difference between speculative loads and loads initiated by the user, resolve passes around a `record_used` parameter, which is `false` when the load is speculative. -## TODO: +## TODO: [#16](https://github.com/rust-lang/rustc-dev-guide/issues/16) This is a result of the first pass of learning the code. It is definitely incomplete and not detailed enough. It also might be inaccurate in places. diff --git a/src/type-checking.md b/src/type-checking.md index 797cd9487..cd58faf22 100644 --- a/src/type-checking.md +++ b/src/type-checking.md @@ -41,4 +41,4 @@ For more details, see the [`collect`][collect] module. [queries]: ./query.md [collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/collect/ -**TODO**: actually talk about type checking... +**TODO**: actually talk about type checking... [#1161](https://github.com/rust-lang/rustc-dev-guide/issues/1161) From 442ba10f1ee778ae60284f0244ad1217ef0ca202 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Fri, 2 Jul 2021 10:43:34 +0200 Subject: [PATCH 1499/1812] Update around half of the January 2021 date references (#1155) --- src/compiler-src.md | 9 --------- src/diagnostics/lintstore.md | 2 +- src/git.md | 7 ++++--- src/miri.md | 7 +++---- src/parallel-rustc.md | 2 +- src/query.md | 2 +- src/salsa.md | 2 +- 7 files changed, 11 insertions(+), 20 deletions(-) diff --git a/src/compiler-src.md b/src/compiler-src.md index 61af38652..b621dde7c 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -2,15 +2,6 @@ -> **NOTE**: The structure of the repository is going through a lot of -> transitions. In particular, we want to get to a point eventually where the -> top-level directory has separate directories for the compiler, build-system, -> std libs, etc, rather than one huge `src/` directory. -> -> As of January 2021, the standard libraries have been -> moved to `library/` and the crates that make up the `rustc` compiler itself -> have been moved to `compiler/`. - Now that we have [seen what the compiler does](./overview.md), let's take a look at the structure of the contents of the rust-lang/rust repo. diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index 6a59cf264..b45e60558 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -17,7 +17,7 @@ First, we have the lint declarations themselves: this is where the name and defa other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which boils down to a static with type `&rustc_session::lint::Lint`. -As of January 2021, we lint against direct declarations +As of July 2021, we lint against direct declarations without the use of the macro today (although this may change in the future, as the macro is somewhat unwieldy to add new fields to, like all macros by example). diff --git a/src/git.md b/src/git.md index 361b65a81..1c311982c 100644 --- a/src/git.md +++ b/src/git.md @@ -157,7 +157,7 @@ no changes added to commit (use "git add" and/or "git commit -a") These changes are not changes to files: they are changes to submodules (more on this [later](#git-submodules)). To get rid of those, run `git submodule update` (or run any `x.py` command, which will automatically update the submodules). -Note that there is (as of January 2021) a bug if you use +Note that there is (as of July 2021) a [bug][#77620] if you use worktrees, submodules, and x.py in a commit hook. If you run into an error like: @@ -167,9 +167,10 @@ error: failed to read `/home/joshua/rustc-worktree/src/tools/miri/cargo-miri/Car Caused by: No such file or directory (os error 2) ``` -it's not anything you did wrong. There is a workaround at [#77620]. +it's not anything you did wrong. There is a workaround in [the issue][#77620-workaround]. -[#77620]: https://github.com/rust-lang/rust/issues/77620#issuecomment-705228229 +[#77620]: https://github.com/rust-lang/rust/issues/77620 +[#77620-workaround]: https://github.com/rust-lang/rust/issues/77620#issuecomment-705228229 ## Rebasing and Conflicts diff --git a/src/miri.md b/src/miri.md index 18cd6ed39..c19ba6401 100644 --- a/src/miri.md +++ b/src/miri.md @@ -197,10 +197,9 @@ Miri's virtual memory. This is in contrast to `Scalar::Raw`, which is just some concrete integer. However, a variable of pointer or reference *type*, such as `*const T` or `&T`, -does not have to have a pointer *value*: it could be obtaining by casting or -transmuting an integer to a pointer (as of January 2021 -that is hard to do in const eval, but eventually `transmute` will be stable as a -`const fn`). And similarly, when casting or transmuting a reference to some +does not have to have a pointer *value*: it could be obtained by casting or +transmuting an integer to a pointer. +And similarly, when casting or transmuting a reference to some actual allocation to an integer, we end up with a pointer *value* (`Scalar::Ptr`) at integer *type* (`usize`). This is a problem because we cannot meaningfully perform integer operations such as division on pointer diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 8be19e8dc..eec8219a5 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -3,7 +3,7 @@ Most of the compiler is not parallel. This represents an opportunity for improving compiler performance. -As of January 2021, work on explicitly parallelizing the +As of July 2021, work on explicitly parallelizing the compiler has stalled. There is a lot of design and correctness work that needs to be done. diff --git a/src/query.md b/src/query.md index aa3a81328..20e547b1e 100644 --- a/src/query.md +++ b/src/query.md @@ -1,7 +1,7 @@ # Queries: demand-driven compilation As described in [the high-level overview of the compiler][hl], the Rust compiler -is still (as of January 2021) transitioning from a +is still (as of July 2021) transitioning from a traditional "pass-based" setup to a "demand-driven" system. **The Compiler Query System is the key to our new demand-driven organization.** The idea is pretty simple. You have various queries that compute things about the input – for diff --git a/src/salsa.md b/src/salsa.md index bfe753824..9bf93727a 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -9,7 +9,7 @@ want to watch [Salsa In More Depth](https://www.youtube.com/watch?v=i_IhACacPRY), also by Niko Matsakis. -> As of January 2021, although Salsa is inspired by +> As of July 2021, although Salsa is inspired by > (among other things) rustc's query system, it is not used directly in rustc. > It _is_ used in chalk and extensively in `rust-analyzer`, but there are no > medium or long-term concrete plans to integrate it into the compiler. From a4e29c5cb5b3dbb7fec4040a13fe0fab196461b9 Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Thu, 1 Jul 2021 13:56:19 +0200 Subject: [PATCH 1500/1812] Update section of lint store --- src/diagnostics/lintstore.md | 61 ++++++++++++++++++++---------------- 1 file changed, 34 insertions(+), 27 deletions(-) diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index b45e60558..ed2100eb7 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -3,7 +3,7 @@ This page documents some of the machinery around lint registration and how we run lints in the compiler. -The `LintStore` is the central piece of infrastructure, around which everything +The [`LintStore`] is the central piece of infrastructure, around which everything rotates. It's not available during the early parts of compilation (i.e., before TyCtxt) in most code, as we need to fill it in with all of the lints, which can only happen after plugin registration. @@ -19,8 +19,7 @@ boils down to a static with type `&rustc_session::lint::Lint`. As of July 2021, we lint against direct declarations without the use of the macro today (although this may change in the future, as -the macro is somewhat unwieldy to add new fields to, like all macros by -example). +the macro is somewhat unwieldy to add new fields to, like all macros). Lint declarations don't carry any "state" - they are merely global identifers and descriptions of lints. We assert at runtime that they are not registered twice (by lint name). @@ -34,44 +33,55 @@ lint, and frequently lints are emitted as part of other work (e.g., type checkin ### High-level overview -The lint store is created and all lints are registered during plugin registration, in -[`rustc_interface::register_plugins`]. There are three 'sources' of lint: the internal lints, plugin -lints, and `rustc_interface::Config` [`register_lints`]. All are registered here, in -`register_plugins`. +In [`rustc_interface::register_plugins`] the [`LintStore`] is created and all lints are registered. +There are four 'sources' of lints: +* internal lints: lints only used by the rustc codebase +* builtin lints: lints built into the compiler and not provided by some outside source +* plugin lints: lints created by plugins through the plugin system. +* `rustc_interface::Config`[`register_lints`]: lints passed into the compiler during construction + +Lints are registered via the [`LintStore::register_lint`] function. This should +happen just once for any lint, or an ICE will occur. Once the registration is complete, we "freeze" the lint store by placing it in an `Lrc`. Later in the driver, it's passed into the `GlobalCtxt` constructor where it lives in an immutable form from then on. -Lints are registered via the [`LintStore::register_lint`] function. This should -happen just once for any lint, or an ICE will occur. - Lint passes are registered separately into one of the categories (pre-expansion, early, late, late module). Passes are registered as a closure -- i.e., `impl Fn() -> Box`, where `dyn X` is either an early or late lint pass trait object. When we run the lint passes, we run the closure and then invoke the lint -pass methods, which take `&mut self` -- lint passes can keep track of state +pass methods. The lint pass methods take `&mut self` so they can keep track of state internally. #### Internal lints -Note, these include both rustc-internal lints, and the traditional lints, like, for example the dead -code lint. +These are lints used just by the compiler or plugins like `clippy`. They can be found in +`rustc_lint::internal`. + +An example of such a lint is the check that lint passes are implemented using the `declare_lint_pass!` +macro and not by hand. This is accomplished with the `LINT_PASS_IMPL_WITHOUT_MACRO` lint. + +Registration of these lints happens in the [`rustc_lint::register_internals`] function which is +called when constructing a new lint store inside [`rustc_lint::new_lint_store`]. + +### Builtin Lints These are primarily described in two places: `rustc_session::lint::builtin` and -`rustc_lint::builtin`. The first provides the definitions for the lints themselves, -and the latter provides the lint pass definitions (and implementations). +`rustc_lint::builtin`. Often the first provides the definitions for the lints themselves, +and the latter provides the lint pass definitions (and implementations), but this is not always +true. -The internal lint registration happens in the [`rustc_lint::register_builtins`] function, along with -the [`rustc_lint::register_internals`] function. More generally, the LintStore "constructor" -function which is *the* way to get a `LintStore` in the compiler (you should not construct it -directly) is [`rustc_lint::new_lint_store`]; it calls the registration functions. +The builtin lint registration happens in the [`rustc_lint::register_builtins`] function. Just like +with internal lints, this happens inside of [`rustc_lint::new_lint_store`]. #### Plugin lints This is one of the primary use cases remaining for plugins/drivers. Plugins are given access to the -mutable `LintStore` during registration to call any functions they need on the `LintStore`, just -like rustc code. Plugins are intended to declare lints with the `plugin` field set to true (e.g., by +mutable `LintStore` during registration (which happens inside of [`rustc_interface::register_plugins`]) +and they can call any functions they need on the `LintStore`, just like rustc code. + +Plugins are intended to declare lints with the `plugin` field set to true (e.g., by way of the [`declare_tool_lint!`] macro), but this is purely for diagnostics and help text; otherwise plugin lints are mostly just as first class as rustc builtin lints. @@ -86,18 +96,15 @@ within the callback they add. The best way for drivers to get access to this is Within the compiler, for performance reasons, we usually do not register dozens of lint passes. Instead, we have a single lint pass of each variety -(e.g. `BuiltinCombinedModuleLateLintPass`) which will internally call all of the +(e.g., `BuiltinCombinedModuleLateLintPass`) which will internally call all of the individual lint passes; this is because then we get the benefits of static over dynamic dispatch for each of the (often empty) trait methods. -Ideally, we'd not have to do this, since it certainly adds to the complexity of +Ideally, we'd not have to do this, since it adds to the complexity of understanding the code. However, with the current type-erased lint store approach, it is beneficial to do so for performance reasons. -New lints being added likely want to join one of the existing declarations like -`late_lint_mod_passes` in `rustc_lint/src/lib.rs`, which would then -auto-propagate into the other. - +[`LintStore`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html [`LintStore::register_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html#method.register_lints [`rustc_interface::register_plugins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.register_plugins.html [`rustc_lint::register_builtins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_builtins.html From 9636fa92ab407cb92adca21262efb8112beeef4f Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Thu, 1 Jul 2021 14:35:24 +0200 Subject: [PATCH 1501/1812] Update information on lints particularly on future-incompatible --- src/diagnostics.md | 60 +++++++++++++++++++++++++++++----------------- 1 file changed, 38 insertions(+), 22 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 38683f98d..f2e6f0a67 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -493,10 +493,11 @@ much faster to work on. [`rustc_lint_defs`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/index.html Every lint is implemented via a `struct` that implements the `LintPass` `trait` -(you also implement one of the more specific lint pass traits, either -`EarlyLintPass` or `LateLintPass`). The trait implementation allows you to -check certain syntactic constructs as the linter walks the source code. You can -then choose to emit lints in a very similar way to compile errors. +(you can also implement one of the more specific lint pass traits, either +`EarlyLintPass` or `LateLintPass` depending on when is best for your lint to run). +The trait implementation allows you to check certain syntactic constructs +as the linter walks the AST. You can then choose to emit lints in a +very similar way to compile errors. You also declare the metadata of a particular lint via the `declare_lint!` macro. This includes the name, the default level, a short description, and some @@ -566,7 +567,7 @@ impl EarlyLintPass for WhileTrue { } ``` -### Edition-gated Lints +### Edition-gated lints Sometimes we want to change the behavior of a lint in a new edition. To do this, we just add the transition to our invocation of `declare_lint!`: @@ -583,6 +584,18 @@ declare_lint! { This makes the `ANONYMOUS_PARAMETERS` lint allow-by-default in the 2015 edition but warn-by-default in the 2018 edition. +### Future-incompatible lints + +Future-incompatible lints are for signalling to the user that code they have +written may not compile in the future. In general, future-incompatible code +exists for two reasons: +* the user has written unsound code that the compiler mistakenly accepted. While +it is within Rust's backwards compatibility guarantees to fix the soundness hole +(breaking the user's code), the lint is there to warn the user that this will happen +in some upcoming version *regardless of which edition they are on*. +* the user has written code that will either no longer compiler *or* will change +meaning in an upcoming edition. + A future-incompatible lint should be declared with the `@future_incompatible` additional "field": @@ -593,31 +606,26 @@ declare_lint! { "detects anonymous parameters", @future_incompatible = FutureIncompatibleInfo { reference: "issue #41686 ", - edition: Some(Edition::Edition2018), + reason: FutureIncompatibilityReason::EditionError(Edition::Edition2018), }; } ``` -If you need a combination of options that's not supported by the `declare_lint!` -macro, you can always define your own static with a type of `&Lint` but this is -(as of January 2021) linted against in the compiler tree. +Notice the `reason` field which describes why the future-incompatible change is happening. +This will change the diagnostic message the user receives as well as determine which +lint groups the lint is added to. - -#### Guidelines for creating a future incompatibility lint - -- Create a lint defaulting to warn as normal, with ideally the same error - message you would normally give. -- Add a suitable reference, typically an RFC or tracking issue. Go ahead - and include the full URL, sort items in ascending order of issue numbers. -- Later, change lint to error. -- Eventually, remove lint. +If you need a combination of options that's not supported by the +`declare_lint!` macro, you can always change the `declare_lint!` macro +to support this. ### Renaming or removing a lint -A lint can be renamed or removed, which will trigger a warning if a user tries +If it is determined that a lint is either improperly named or no longer needed, +the lint must be registered for renaming or removal, which will trigger a warning if a user tries to use the old lint name. To declare a rename/remove, add a line with [`store.register_renamed`] or [`store.register_removed`] to the code of the -[`register_builtins`] function. +[`rustc_lint::register_builtins`] function. ```rust,ignore store.register_renamed("single_use_lifetime", "single_use_lifetimes"); @@ -625,7 +633,7 @@ store.register_renamed("single_use_lifetime", "single_use_lifetimes"); [`store.register_renamed`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html#method.register_renamed [`store.register_removed`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/struct.LintStore.html#method.register_removed -[`register_builtins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_builtins.html +[`rustc_lint::register_builtins`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/fn.register_builtins.html ### Lint Groups @@ -649,6 +657,14 @@ This defines the `nonstandard_style` group which turns on the listed lints. A user can turn on these lints with a `!#[warn(nonstandard_style)]` attribute in the source code, or by passing `-W nonstandard-style` on the command line. +Some lint groups are created automatically in `LintStore::register_lints`. For instance, +any lint declared with `FutureIncompatibleInfo` where the reason is +`FutureIncompatibilityReason::FutureReleaseError` (the default when +`@future_incompatible` is used in `declare_lint!`), will be added to +the `future_incompatible` lint group. Editions also have their own lint groups +(e.g., `rust_2021_compatibility`) automatically generated for any lints signaling +future-incompatible code that will break in the specified edition. + ### Linting early in the compiler On occasion, you may need to define a lint that runs before the linting system @@ -682,7 +698,7 @@ then dumped into the `Session::buffered_lints` used by the rest of the compiler. The compiler accepts an `--error-format json` flag to output diagnostics as JSON objects (for the benefit of tools such as `cargo -fix` or the RLS). It looks like this— +fix` or the RLS). It looks like this: ```console $ rustc json_error_demo.rs --error-format json From c3c110f1078210bd38ce5b508c3846804f1f93ca Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Thu, 1 Jul 2021 17:05:19 +0200 Subject: [PATCH 1502/1812] Fix line lens --- src/diagnostics/lintstore.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index ed2100eb7..d2796c070 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -59,8 +59,9 @@ internally. These are lints used just by the compiler or plugins like `clippy`. They can be found in `rustc_lint::internal`. -An example of such a lint is the check that lint passes are implemented using the `declare_lint_pass!` -macro and not by hand. This is accomplished with the `LINT_PASS_IMPL_WITHOUT_MACRO` lint. +An example of such a lint is the check that lint passes are implemented using the +`declare_lint_pass!` macro and not by hand. This is accomplished with the +`LINT_PASS_IMPL_WITHOUT_MACRO` lint. Registration of these lints happens in the [`rustc_lint::register_internals`] function which is called when constructing a new lint store inside [`rustc_lint::new_lint_store`]. @@ -77,9 +78,10 @@ with internal lints, this happens inside of [`rustc_lint::new_lint_store`]. #### Plugin lints -This is one of the primary use cases remaining for plugins/drivers. Plugins are given access to the -mutable `LintStore` during registration (which happens inside of [`rustc_interface::register_plugins`]) -and they can call any functions they need on the `LintStore`, just like rustc code. +This is one of the primary use cases remaining for plugins/drivers. Plugins are given access +to the mutable `LintStore` during registration (which happens inside of +[`rustc_interface::register_plugins`]) and they can call any functions they need on +the `LintStore`, just like rustc code. Plugins are intended to declare lints with the `plugin` field set to true (e.g., by way of the [`declare_tool_lint!`] macro), but this is purely for diagnostics and help text; From 1a51a21243ab2424abe0ebed63516d3b3692cf1e Mon Sep 17 00:00:00 2001 From: Ryan Levick Date: Sun, 4 Jul 2021 20:03:29 +0200 Subject: [PATCH 1503/1812] More specifics on what future-incompatible lints are used for --- src/diagnostics.md | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index f2e6f0a67..385d7db60 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -586,15 +586,21 @@ but warn-by-default in the 2018 edition. ### Future-incompatible lints -Future-incompatible lints are for signalling to the user that code they have +The use of the term `future-incompatible` within the compiler has a slightly +broader meaning than what rustc exposes to users of the compiler. + +Inside rustc, future-incompatible lints are for signalling to the user that code they have written may not compile in the future. In general, future-incompatible code exists for two reasons: * the user has written unsound code that the compiler mistakenly accepted. While it is within Rust's backwards compatibility guarantees to fix the soundness hole (breaking the user's code), the lint is there to warn the user that this will happen -in some upcoming version *regardless of which edition they are on*. +in some upcoming version of rustc *regardless of which edition the code uses*. This is the +meaning that rustc exclusively exposes to users as "future incompatible". * the user has written code that will either no longer compiler *or* will change -meaning in an upcoming edition. +meaning in an upcoming *edition*. These are often called "edition lints" and can be +typically seen in the various "edition compatibility" lint groups (e.g., `rust_2021_compatibility`) +that are used to lint against code that will break if the user updates the crate's edition. A future-incompatible lint should be declared with the `@future_incompatible` additional "field": @@ -611,9 +617,17 @@ declare_lint! { } ``` -Notice the `reason` field which describes why the future-incompatible change is happening. +Notice the `reason` field which describes why the future incompatible change is happening. This will change the diagnostic message the user receives as well as determine which -lint groups the lint is added to. +lint groups the lint is added to. In the example above, the lint is an "edition lint" +(since it's "reason" is `EditionError`) signifying to the user that the use of anonymous +parameters will no longer compile in Rust 2018 and beyond. + +Inside [LintStore::register_lints][fi-lint-groupings], lints with `future_incompatible` +fields get placed into either edition-based lint groups (if their `reason` is tied to +an edition) or into the `future_incompatibility` lint group. + +[fi-lint-groupings]: https://github.com/rust-lang/rust/blob/51fd129ac12d5bfeca7d216c47b0e337bf13e0c2/compiler/rustc_lint/src/context.rs#L212-L237 If you need a combination of options that's not supported by the `declare_lint!` macro, you can always change the `declare_lint!` macro From 33c1eff45e8c63b6a2dab740d2b89320937713f0 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Mon, 5 Jul 2021 02:34:33 -0400 Subject: [PATCH 1504/1812] Document lang items (#1119) * Document lang items * Apply suggestions from code review Co-authored-by: Camelid * Add an example of retrieving lang items * Add two missing words * Fix line lengths Co-authored-by: Mikail Bagishov Co-authored-by: Camelid --- src/SUMMARY.md | 1 + src/lang-items.md | 67 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+) create mode 100644 src/lang-items.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 3f14c2642..5fa267601 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -81,6 +81,7 @@ - [Panic Implementation](./panic-implementation.md) - [AST Validation](./ast-validation.md) - [Feature Gate Checking](./feature-gate-ck.md) + - [Lang Items](./lang-items.md) - [The HIR (High-level IR)](./hir.md) - [Lowering AST to HIR](./lowering.md) - [Debugging](./hir-debugging.md) diff --git a/src/lang-items.md b/src/lang-items.md new file mode 100644 index 000000000..c5774c43b --- /dev/null +++ b/src/lang-items.md @@ -0,0 +1,67 @@ +# Lang items + +The compiler has certain pluggable operations; that is, functionality that isn't hard-coded into +the language, but is implemented in libraries, with a special marker to tell the compiler it +exists. The marker is the attribute `#[lang = "..."]`, and there are various different values of +`...`, i.e. various different 'lang items'. + +Many such lang items can be implemented only in one sensible way, such as `add` (`trait +core::ops::Add`) or `future_trait` (`trait core::future::Future`). Others can be overriden to +achieve some specific goals; for example, you can control your binary's entrypoint. + +Features provided by lang items include: + +- overloadable operators via traits: the traits corresponding to the + `==`, `<`, dereference (`*`), `+`, etc. operators are all + marked with lang items; those specific four are `eq`, `ord`, + `deref`, and `add` respectively. +- panicking and stack unwinding; the `eh_personality`, `panic` and + `panic_bounds_checks` lang items. +- the traits in `std::marker` used to indicate properties of types used by the compiler; + lang items `send`, `sync` and `copy`. +- the special marker types used for variance indicators found in + `core::marker`; lang item `phantom_data`. + +Lang items are loaded lazily by the compiler; e.g. if one never uses `Box` +then there is no need to define functions for `exchange_malloc` and +`box_free`. `rustc` will emit an error when an item is needed but not found +in the current crate or any that it depends on. + +Most lang items are defined by the `core` library, but if you're trying to build an +executable with `#![no_std]`, you'll still need to define a few lang items that are +usually provided by `std`. + +## Retrieving a language item + +You can retrieve lang items by calling [`tcx.lang_items()`]. + +Here's a small example of retrieving the `trait Sized {}` language item: + +```rust +// Note that in case of `#![no_core]`, the trait is not available. +if let Some(sized_trait_def_id) = tcx.lang_items().sized_trait() { + // do something with `sized_trait_def_id` +} +``` + +Note that `sized_trait()` returns an `Option`, not the `DefId` itself. +That's because language items are defined in the standard libray, so if someone compiles with +`#![no_core]` (or for some lang items, `#![no_std]`), the lang item may not be present. +You can either: + +- Give a hard error if the lang item is necessary to continue (don't panic, since this can happen in + user code). +- Proceed with limited functionality, by just omitting whatever you were going to do with the + `DefId`. + +[`tcx.lang_items()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.lang_items + +## List of all language items + +You can find language items in the following places: +- An exhaustive reference in the compiler documentation: [`rustc_hir::LangItem`] +- An auto-generated list with source locations by using ripgrep: `rg '#\[.*lang =' library/` + +Note that language items are explicitly unstable and may change in any new release. + +[`rustc_hir::LangItem`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/lang_items/enum.LangItem.html From 60e282559104035985331645907c3d9f842312c5 Mon Sep 17 00:00:00 2001 From: Yoh Deadfall Date: Mon, 5 Jul 2021 18:18:21 +0300 Subject: [PATCH 1505/1812] Fixed typos in inline code --- src/stability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/stability.md b/src/stability.md index 0f1aec17e..7eff3e88b 100644 --- a/src/stability.md +++ b/src/stability.md @@ -44,7 +44,7 @@ prevents breaking dependencies by leveraging Cargo's lint capping. [rustc bug]: https://github.com/rust-lang/rust/issues/15702 ## stable -The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly +The `#[stable(feature = "foo", since = "1.420.69")]` attribute explicitly marks an item as stabilized. Note that stable functions may use unstable things in their body. ## rustc_const_unstable @@ -60,7 +60,7 @@ there's no way to add `const` to functions in `extern` blocks for now. ## rustc_const_stable -The `#[rustc_const_stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks +The `#[rustc_const_stable(feature = "foo", since = "1.420.69")]` attribute explicitly marks a `const fn` as having its constness be `stable`. This attribute can make sense even on an `unstable` function, if that function is called from another `rustc_const_stable` function. From 1b56b094728188d1970ef94e727b6c384ac98b7c Mon Sep 17 00:00:00 2001 From: Eric Holk Date: Wed, 7 Jul 2021 16:27:47 -0700 Subject: [PATCH 1506/1812] Minor capitalization fix (#1170) --- src/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/walkthrough.md b/src/walkthrough.md index b0d040942..5841afe4f 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -188,7 +188,7 @@ don't request anyone; the bot will assign someone automatically. The reviewer may request changes before they approve your PR. Feel free to ask questions or discuss things you don't understand or disagree with. However, -recognize that the PR won't be merged unless someone on the rust team approves +recognize that the PR won't be merged unless someone on the Rust team approves it. When your reviewer approves the PR, it will go into a queue for yet another bot From 93422c21baca585dc88357ec886a48f6ddc7d665 Mon Sep 17 00:00:00 2001 From: bjorn3 Date: Sun, 30 May 2021 21:02:22 +0200 Subject: [PATCH 1507/1812] Update for merge of CrateDisambiguator into StableCrateId --- src/backend/libs-and-metadata.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/src/backend/libs-and-metadata.md b/src/backend/libs-and-metadata.md index 91d8cb3aa..d2cf8b692 100644 --- a/src/backend/libs-and-metadata.md +++ b/src/backend/libs-and-metadata.md @@ -72,8 +72,8 @@ Here are a few highlights of things it contains: from any other version. * The [Strict Version Hash](#strict-version-hash) (SVH). This helps ensure the correct dependency is loaded. -* The [Crate Disambiguator](#crate-disambiguator). This is a hash used - to disambiguate between different crates of the same name. +* The [Stable Crate Id](#stable-crate-id). This is a hash used + to identify crates. * Information about all the source files in the library. This can be used for a variety of things, such as diagnostics pointing to sources in a dependency. @@ -114,21 +114,22 @@ computed. [incremental compilation]: ../queries/incremental-compilation.md [`finalize_and_compute_crate_hash`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/collector/struct.NodeCollector.html#method.finalize_and_compute_crate_hash -### Crate Disambiguator +### Stable Crate Id -The [`CrateDisambiguator`] is a 128-bit hash used to distinguish between -different crates of the same name. It is a hash of all the [`-C metadata`] CLI -options computed in [`compute_crate_disambiguator`]. It is used in a variety -of places, such as symbol name mangling, crate loading, and much more. +The [`StableCrateId`] is a 64-bit hash used to identify different crates with +potentially the same name. It is a hash of the crate name and all the +[`-C metadata`] CLI options computed in [`StableCrateId::new`]. It is +used in a variety of places, such as symbol name mangling, crate loading, and +much more. -By default, all Rust symbols are mangled and incorporate the disambiguator -hash. This allows multiple versions of the same crate to be included together. -Cargo automatically generates `-C metadata` hashes based on a variety of -factors, like the package version, source, and the target kind (a lib and bin -can have the same crate name, so they need to be disambiguated). +By default, all Rust symbols are mangled and incorporate the stable crate id. +This allows multiple versions of the same crate to be included together. Cargo +automatically generates `-C metadata` hashes based on a variety of factors, +like the package version, source, and the target kind (a lib and test can have +the same crate name, so they need to be disambiguated). -[`CrateDisambiguator`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/crate_disambiguator/struct.CrateDisambiguator.html -[`compute_crate_disambiguator`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/util/fn.compute_crate_disambiguator.html +[`StableCrateId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/def_id/struct.StableCrateId.html +[`StableCrateId::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/def_id/struct.StableCrateId.html#method.new [`-C metadata`]: https://doc.rust-lang.org/rustc/codegen-options/index.html#metadata ## Crate loading From f2c4bba539ed9686f63b82d203f1837479f99ef8 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Tue, 20 Jul 2021 17:39:41 -0700 Subject: [PATCH 1508/1812] Link directly to stabilization report comments (#1173) Previously, readers had to scroll through tons of comments to find the report. --- src/stabilization_guide.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index a6203a3c6..60d333a37 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -58,18 +58,24 @@ The report should contain: and describe the feature's behavior on encountering edge cases. - Links to the documentations (the PRs we have made in the previous steps). -- Any other relevant information(Examples of such reports can - be found in rust-lang/rust#44494 and rust-lang/rust#28237). +- Any other relevant information. - The resolutions of any unresolved questions if the stabilization is for an RFC. +Examples of stabilization reports can be found in +[rust-lang/rust#44494][report1] and [rust-lang/rust#28237][report2] (these links +will bring you directly to the comment containing the stabilization report). + +[report1]: https://github.com/rust-lang/rust/issues/44494#issuecomment-360191474 +[report2]: https://github.com/rust-lang/rust/issues/28237#issuecomment-363374130 + ## FCP If any member of the team responsible for tracking this feature agrees with stabilizing this feature, they will start the FCP (final-comment-period) process by commenting -```bash +```text @rfcbot fcp merge ``` From 09343d6f921d2a07c66f8c41ec3d65bf1fa52556 Mon Sep 17 00:00:00 2001 From: Ben Reeves Date: Sun, 25 Jul 2021 17:37:28 -0500 Subject: [PATCH 1509/1812] Fix typo in building/bootstrapping.md (#1175) --- src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 61537dbf8..876c565ab 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -34,7 +34,7 @@ Compiling `rustc` is done in stages: - **Stage 1:** the code in your clone (for new version) is then compiled with the stage0 compiler to produce the stage1 compiler. However, it was built with an older compiler (stage0), so to - optimize the stage1 compiler we go to next the stage. + optimize the stage1 compiler we go to the next stage. - In theory, the stage1 compiler is functionally identical to the stage2 compiler, but in practice there are subtle differences. In particular, the stage1 compiler itself was built by stage0 and From f09467282841c136b9c1f05bc5ca4595dee73b3a Mon Sep 17 00:00:00 2001 From: Dave Date: Wed, 28 Jul 2021 18:05:43 +0430 Subject: [PATCH 1510/1812] git.md: Fix No-Merge Policy link --- src/git.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/git.md b/src/git.md index 1c311982c..72d287151 100644 --- a/src/git.md +++ b/src/git.md @@ -268,7 +268,7 @@ git rebase master git push --force-with-lease (set origin to be the same as local) ``` -To avoid merges as per the [No-Merge Policy][#no-merge-policy], you may want to use +To avoid merges as per the [No-Merge Policy](#no-merge-policy), you may want to use `git config pull.ff only` (this will apply the config to the local repo). to avoid merge conflicts while pulling, without needing `--ff-only` or `--rebase` while `git pull`ing From d111b3ea7ea22877d08db81fbc0c4a5b3024fec1 Mon Sep 17 00:00:00 2001 From: the8472 Date: Thu, 29 Jul 2021 06:05:19 +0200 Subject: [PATCH 1511/1812] Add S-Inactive PRs as another source of things contributors could work on (#1177) --- src/compiler-team.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/compiler-team.md b/src/compiler-team.md index aac263484..abdeac3d2 100644 --- a/src/compiler-team.md +++ b/src/compiler-team.md @@ -80,6 +80,12 @@ group. One good way to find bugs is to look for or [E-mentor](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-mentor). +You can also dig through the graveyard of PRs that were +[closed due to inactivity](https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3AS-inactive), +some of them may contain work that is still useful - refer to the +associated issues, if any - and only needs some finishing touches +for which the original author didn't have time. + ### r+ rights Once you have made a number of individual PRs to rustc, we will often From 809f4d1d3334b538cb1cd65e847a13faa77cee43 Mon Sep 17 00:00:00 2001 From: Yoh Deadfall Date: Thu, 5 Aug 2021 14:41:16 +0300 Subject: [PATCH 1512/1812] Fixed team responsible for stabilization (#1181) --- src/stability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/stability.md b/src/stability.md index 7eff3e88b..51d849200 100644 --- a/src/stability.md +++ b/src/stability.md @@ -72,7 +72,7 @@ Furthermore this attribute is needed to mark an intrinsic as callable from To stabilize a feature, follow these steps: -0. Ask a **@T-libs** member to start an FCP on the tracking issue and wait for +0. Ask a **@T-libs-api** member to start an FCP on the tracking issue and wait for the FCP to complete (with `disposition-merge`). 1. Change `#[unstable(...)]` to `#[stable(since = "version")]`. `version` should be the *current nightly*, i.e. stable+2. You can see which version is @@ -82,7 +82,7 @@ To stabilize a feature, follow these steps: 3. If applicable, change `#[rustc_const_unstable(...)]` to `#[rustc_const_stable(since = "version")]`. 4. Open a PR against `rust-lang/rust`. - - Add the appropriate labels: `@rustbot modify labels: +T-libs`. + - Add the appropriate labels: `@rustbot modify labels: +T-libs-api`. - Link to the tracking issue and say "Closes #XXXXX". You can see an example of stabilizing a feature with From e218184b6884f0dcee14e043c83e7c7ff4c0fb6b Mon Sep 17 00:00:00 2001 From: Bryan Cantrill Date: Sat, 7 Aug 2021 01:12:22 -0700 Subject: [PATCH 1513/1812] Add description of -opt-bisect-limit LLVM option (#1182) --- src/backend/debugging.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/backend/debugging.md b/src/backend/debugging.md index 7577a0e13..673660167 100644 --- a/src/backend/debugging.md +++ b/src/backend/debugging.md @@ -56,6 +56,17 @@ different stages during compilation, which is sometimes useful. One just needs to convert the bitcode files to `.ll` files using `llvm-dis` which should be in the target local compilation of rustc. +If you are seeing incorrect behavior due to an optimization pass, a very handy +LLVM option is `-opt-bisect-limit`, which takes an integer denoting the index +value of the highest pass to run. Index values for taken passes are stable +from run to run; by coupling this with software that automates bisecting the +search space based on the resulting program, an errant pass can be quickly +determined. When an `-opt-bisect-limit` is specified, all runs are displayed +to standard error, along with their index and output indicating if the +pass was run or skipped. Setting the limit to an index of -1 (e.g., +`RUSTFLAGS="-C llvm-args=-opt-bisect-limit=-1"`) will show all passes and +their corresponding index values. + If you want to play with the optimization pipeline, you can use the `opt` tool from `./build//llvm/bin/` with the LLVM IR emitted by rustc. Note that rustc emits different IR depending on whether `-O` is enabled, even @@ -125,6 +136,8 @@ tutorial above): - The `-Z no-parallel-llvm` will disable parallel compilation of distinct compilation units - The `-Z llvm-time-trace` option will output a Chrome profiler compatible JSON file which contains details and timings for LLVM passes. +- The `-C llvm-args=-opt-bisect-limit=` option allows for bisecting LLVM + optimizations. ### Filing LLVM bug reports From c4644b427cbdaafc7a87be0ccdf5d8aaa07ac35f Mon Sep 17 00:00:00 2001 From: Rahul Butani Date: Tue, 10 Aug 2021 04:41:44 -0700 Subject: [PATCH 1514/1812] Remove a dead link in `new-target.md` + other nits (#1186) --- src/building/new-target.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/building/new-target.md b/src/building/new-target.md index 7701fdbac..968754138 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -20,15 +20,15 @@ cd src/llvm-project git remote add my-target-llvm some-llvm-repository git checkout my-target-llvm/my-branch cd .. -git add llvm_target +git add llvm-project git commit -m 'Use my custom LLVM' ``` ### Using pre-built LLVM If you have a local LLVM checkout that is already built, you may be -able to configure Rust to treat your build as the [system LLVM][sysllvm] -to avoid redundant builds. +able to configure Rust to treat your build as the system LLVM to avoid +redundant builds. You can tell Rust to use a pre-built version of LLVM using the `target` section of `config.toml`: @@ -74,7 +74,7 @@ You will need to add a line to the big table inside of the will then add a corresponding file for your new target containing a `target` function. -Look for existing targets to use as examples +Look for existing targets to use as examples. ## Patching crates @@ -125,8 +125,10 @@ compiler, you can use it instead of the JSON file for both arguments. ## Promoting a target from tier 2 (target) to tier 2 (host) There are two levels of tier 2 targets: -a) Targets that are only cross-compiled (`rustup target add`) -b) Targets that have a native toolchain (`rustup toolchain install`) + a) Targets that are only cross-compiled (`rustup target add`) + b) Targets that [have a native toolchain][tier2-native] (`rustup toolchain install`) + +[tier2-native]: https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-2-with-host-tools For an example of promoting a target from cross-compiled to native, see [#75914](https://github.com/rust-lang/rust/pull/75914). From 1d9af90889cbd7073e45e76cc3ed93738d72c89f Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Thu, 5 Aug 2021 08:54:28 +0200 Subject: [PATCH 1515/1812] allow to quickly edit a page directly on github --- book.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/book.toml b/book.toml index bad4fe1aa..fb09c804e 100644 --- a/book.toml +++ b/book.toml @@ -12,6 +12,7 @@ renderer = ["html"] [output.html] git-repository-url = "https://github.com/rust-lang/rustc-dev-guide" +edit-url-template = "https://github.com/rust-lang/rustc-dev-guide/tree/master/{path}?mode=edit" [output.html.fold] enable = true From 74b138e1f0681ddbc876f49077c5b14aca5abd8f Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Mon, 16 Aug 2021 03:33:24 +0200 Subject: [PATCH 1516/1812] update mdbook version to latest v0.4.7 didn't have the feature to allow this See https://github.com/rust-lang/rustc-dev-guide/pull/1180#issuecomment-899128718 --- .github/workflows/ci.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index a2b9cc30d..fed51378c 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -14,7 +14,7 @@ jobs: if: github.repository == 'rust-lang/rustc-dev-guide' runs-on: ubuntu-latest env: - MDBOOK_VERSION: 0.4.7 + MDBOOK_VERSION: 0.4.12 MDBOOK_LINKCHECK_VERSION: 0.7.2 MDBOOK_TOC_VERSION: 0.6.1 DEPLOY_DIR: book/html From 9a6bd9fc982441b27f855c7311888eb00a09274c Mon Sep 17 00:00:00 2001 From: Smitty Date: Wed, 4 Aug 2021 19:11:38 -0400 Subject: [PATCH 1517/1812] Remove docs for old -Z profile-queries flag --- src/SUMMARY.md | 1 - src/queries/profiling.md | 346 --------------------------------------- src/query.md | 21 ++- 3 files changed, 20 insertions(+), 348 deletions(-) delete mode 100644 src/queries/profiling.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 5fa267601..cb3b4b404 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -59,7 +59,6 @@ - [Incremental compilation](./queries/incremental-compilation.md) - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md) - [Debugging and Testing](./incrcomp-debugging.md) - - [Profiling Queries](./queries/profiling.md) - [Salsa](./salsa.md) - [Memory Management in Rustc](./memory.md) - [Serialization in Rustc](./serialization.md) diff --git a/src/queries/profiling.md b/src/queries/profiling.md deleted file mode 100644 index 1160ba818..000000000 --- a/src/queries/profiling.md +++ /dev/null @@ -1,346 +0,0 @@ -# Profiling Queries - - - -In an effort to support _incremental compilation_, the latest design of the Rust -compiler consists of a _query-based_ model. - -The details of this model are outside the scope of this document, -however, we explain [some background of this model](#background), in an effort -to explain how we profile its performance. We intend this profiling effort to -address [issue 42678](https://github.com/rust-lang/rust/issues/42678). - -## Quick Start - -### 0. Enable debug assertions - -``` -./configure --enable-debug-assertions -``` - -### 1. Compile `rustc` - -Compile the compiler, up to at least stage 1: - -``` -./x.py build library/std -``` - -### 2. Run `rustc`, with flags - -Run the compiler on a source file, supplying two additional debugging flags with -`-Z`: - -``` -rustc -Z profile-queries -Z incremental=cache foo.rs -``` - -Regarding the two additional parameters: - -- `-Z profile-queries` tells the compiler to run a separate thread that profiles - the queries made by the main compiler thread(s). -- `-Z incremental=cache` tells the compiler to "cache" various files that - describe the compilation dependencies, in the subdirectory `cache`. - -This command will generate the following files: - -- `profile_queries.html` consists of an HTML-based representation of the - [trace of queries](#trace-of-queries). -- `profile_queries.counts.txt` consists of a histogram, where each histogram - "bucket" is a query provider. - -### 3. Run `rustc`, with `-Z time-passes`: - -- This additional flag will add all timed passes to the output files mentioned - above, in step 2. As described below, these passes appear visually distinct - from the queries in the HTML output (they appear as green boxes, via - CSS). - -### 4. Inspect the output - -- 4(a). Open the HTML file (`profile_queries.html`) with a browser. See - [this section](#interpret-the-html-output) for an explanation of this file. -- 4(b). Open the data file (`profile_queries.counts.txt`) with a text editor, or - spreadsheet. See [this section](#interpret-the-data-output) for an explanation - of this file. - -## Interpret the HTML Output - -### Example 0 - -The following image gives some example output, from tracing the queries of -`hello_world.rs` (a single `main` function, that prints `"hello world"` via the -macro `println!`). This image only shows a short prefix of the total output; the -_actual_ output is much longer. - -[![Example HTML output](./example-0.png)][profile-example-html] -[View full HTML output][profile-example-html]. Note; it could take up -to a second to properly render depending on your browser. - -Here is the corresponding [text output](./example-0.counts.txt). - -[profile-example-html]: ./example-0.html - -### Example 0 explanation - -The trace of the queries has a formal structure; see -[Trace of Queries](#trace-of-queries) for details. - -We style this formal structure as follows: - -- **Timed passes:** Green boxes, when present (via `-Z time-passes`), represent - _timed passes_ in the compiler. As of January 2021 - these passes are not queries, but may be replaced by queries in future versions. -- **Labels:** Some green and red boxes are labeled with text. Where they are - present, the labels give the following information: - - The [query's _provider_](#queries), sans its _key_ and its _result_, which - are often too long to include in these labels. - - The _duration_ of the provider, as a fraction of the total time (for the - entire trace). This fraction includes the query's entire extent (that is, - the sum total of all of its sub-queries). -- **Query hits:** Blue dots represent query hits. They consist of leaves in the - trace's tree. (CSS class: `hit`). -- **Query misses:** Red boxes represent query misses. They consist of internal - nodes in the trace's tree. (CSS class: `miss`). -- **Nesting structure:** Many red boxes contain _nested boxes and dots_. This - nesting structure reflects that some providers _depend on_ results from other - providers, which consist of their nested children. -- Some red boxes are _labeled_ with text, and have highlighted borders (light - red, and bolded). (See [heuristics](#heuristics) for details). - -## Heuristics - -Heuristics-based CSS Classes: - -- `important` -- Trace nodes are `important` if they have an extent of 6 (or - more), _or_ they have a duration fraction of one percent (or more). These - numbers are simple heuristics (hard-coded, but easy to modify). - Important nodes are styled with textual labels, and highlighted borders (light - red, and bolded). - -- `frac-50`, `-40`, ... -- Trace nodes whose total duration (self and children) - take a large fraction of the total duration, at or above 50%, 40%, and so on. - We style nodes these with larger font and padding. - -## Interpret the Data Output - -The file `profile_queries.counts.txt` contains a table of information about the -queries, organized around their providers. - -For each provider (or timed pass, when `-Z time-passes` is present), we produce: - -- A total **count** --- the total number of times this provider was queried - -- A total **duration** --- the total number of seconds spent running this - provider, _including_ all providers it may depend on. To get a sense of this - dependency structure, and inspect a more fine-grained view of these durations, - see [this section](#interpret-the-html-output). - -These rows are **sorted by total duration**, in descending order. - -### Counts: Example 0 - -The following example `profile_queries.counts.txt` file results from running on -a hello world program (a single main function that uses `println` to print -`"hello world"`). - -As explained above, the columns consist of `provider/pass`, `count`, `duration`: - -``` -translation,1,0.891 -symbol_name,2658,0.733 -def_symbol_name,2556,0.268 -item_attrs,5566,0.162 -type_of,6922,0.117 -generics_of,8020,0.084 -serialize dep graph,1,0.079 -relevant_trait_impls_for,50,0.063 -def_span,24875,0.061 -expansion,1,0.059 -const checking,1,0.055 -adt_def,1141,0.048 -trait_impls_of,32,0.045 -is_copy_raw,47,0.045 -is_foreign_item,2638,0.042 -fn_sig,2172,0.033 -adt_dtorck_constraint,2,0.023 -impl_trait_ref,2434,0.023 -typeck_tables_of,29,0.022 -item-bodies checking,1,0.017 -typeck_item_bodies,1,0.017 -is_default_impl,2320,0.017 -borrow checking,1,0.014 -borrowck,4,0.014 -mir_validated,4,0.013 -adt_destructor,10,0.012 -layout_raw,258,0.010 -load_dep_graph,1,0.007 -item-types checking,1,0.005 -mir_const,2,0.005 -name resolution,1,0.004 -is_object_safe,35,0.003 -is_sized_raw,89,0.003 -parsing,1,0.003 -is_freeze_raw,11,0.001 -privacy checking,1,0.001 -privacy_access_levels,5,0.001 -resolving dependency formats,1,0.001 -adt_sized_constraint,9,0.001 -wf checking,1,0.001 -liveness checking,1,0.001 -compute_incremental_hashes_map,1,0.001 -match checking,1,0.001 -type collecting,1,0.001 -param_env,31,0.000 -effect checking,1,0.000 -trait_def,140,0.000 -lowering ast -> hir,1,0.000 -predicates_of,70,0.000 -extern_crate,319,0.000 -lifetime resolution,1,0.000 -is_const_fn,6,0.000 -intrinsic checking,1,0.000 -translation item collection,1,0.000 -impl_polarity,15,0.000 -creating allocators,1,0.000 -language item collection,1,0.000 -crate injection,1,0.000 -early lint checks,1,0.000 -indexing hir,1,0.000 -maybe creating a macro crate,1,0.000 -coherence checking,1,0.000 -optimized_mir,6,0.000 -is_panic_runtime,33,0.000 -associated_item_def_ids,7,0.000 -needs_drop_raw,10,0.000 -lint checking,1,0.000 -complete gated feature checking,1,0.000 -stability index,1,0.000 -region_maps,11,0.000 -super_predicates_of,8,0.000 -coherent_trait,2,0.000 -AST validation,1,0.000 -loop checking,1,0.000 -static item recursion checking,1,0.000 -variances_of,11,0.000 -associated_item,5,0.000 -plugin loading,1,0.000 -looking for plugin registrar,1,0.000 -stability checking,1,0.000 -describe_def,15,0.000 -variance testing,1,0.000 -codegen unit partitioning,1,0.000 -looking for entry point,1,0.000 -checking for inline asm in case the target doesn't support it,1,0.000 -inherent_impls,1,0.000 -crate_inherent_impls,1,0.000 -trait_of_item,7,0.000 -crate_inherent_impls_overlap_check,1,0.000 -attribute checking,1,0.000 -internalize symbols,1,0.000 -impl wf inference,1,0.000 -death checking,1,0.000 -reachability checking,1,0.000 -reachable_set,1,0.000 -is_exported_symbol,3,0.000 -is_mir_available,2,0.000 -unused lib feature checking,1,0.000 -maybe building test harness,1,0.000 -recursion limit,1,0.000 -write allocator module,1,0.000 -assert dep graph,1,0.000 -plugin registration,1,0.000 -write metadata,1,0.000 -``` - -# Background - -We give some background about the query model of the Rust compiler. - -## Def IDs - -In the query model, many queries have a key that consists of a Def ID. The Rust -compiler uses Def IDs to distinguish definitions in the input Rust program. - -From the compiler source code (`compiler/rustc_span/src/def_id.rs`): - -``` -/// A DefId identifies a particular *definition*, by combining a crate -/// index and a def index. -#[derive(Clone, Eq, Ord, PartialOrd, PartialEq, RustcEncodable, RustcDecodable, Hash, Copy)] -pub struct DefId { - pub krate: CrateNum, - pub index: DefIndex, -} -``` - -## Queries - -A query relates a _key_ to a _result_, either by invoking a _provider_ that -computes this result, or by reusing a cached result that was provided earlier. -We explain each term in more detail: - -- Query **Provider**: Each kind of query has a pre-defined _provider_, which - refers to the compiler behavior that provides an answer to the query. These - providers may nest; see [trace of queries](#trace-of-queries) for more - information about this nesting structure. - _Example providers:_ - - `typeck` -- Typecheck a Def ID; produce "tables" of type - information. - - `borrowck` -- Borrow-check a Def ID. - - `optimized_mir` -- Generate an optimized MIR for a Def ID; produce MIR. - - For more examples, see [Example 0](#counts-example-0). -- Query **Key**: The input/arguments to the provider. Often, this consists of a - particular [Def ID](#def-ids). -- Query **Result**: The output of the provider. - -## Trace of Queries - -Formally, a _trace_ of the queries consists of a _tree_, where sub-trees -represent sub-traces. In particular, the nesting structure of the trace of -queries describes how the queries depend on one another. - -Even more precisely, this tree represents a directed acyclic graph (DAG), where -shared sub-graphs consist of tree nodes that occur multiple times in the tree, -first as "cache misses" and later as "cache hits". - -**Cache hits and misses.** The trace is a tree with the following possible tree -nodes: - -- Query, with cache **miss**: The query's result is **unknown**, and its - provider runs to compute it. In this case, the dynamic extent of the query's - trace consists of the traced behavior of its provider. -- Query, with cache **hit**: The query's result is **known**, and is reused; its - provider does not rerun. These nodes are leaves in the trace, since they have - no dynamic extent. These leaves also represent where the tree, represented as - a DAG, would _share_ a sub-graph (namely, the sub-graph of the query that was - reused from the cache). - -**Tree node metrics.** To help determine how to style this tree, we define the -following tree node metrics: - -- **Depth**: The number of **ancestors** of the node in its path from the tree - root. -- **Extent**: The number of **immediate children** of the node. - -Intuitively, a dependency tree is "good" for incremental caching when the depth -and extent of each node is relatively small. It is pathological when either of -these metrics grows too large. For instance, a tree node whose extent consists -of 1M immediate children means that if and when this node is re-computed, all 1M -children must be re-queried, at the very least (some may also require -recomputation, too). - -## External Links - -Related design ideas, and tracking issues: - -- Design document: - [On-demand Rustc incremental design doc](https://github.com/nikomatsakis/rustc-on-demand-incremental-design-doc/blob/master/0000-rustc-on-demand-and-incremental.md) -- Tracking Issue: - ["Red/Green" dependency tracking in compiler](https://github.com/rust-lang/rust/issues/42293) - -More discussion and issues: - -- [GitHub issue #42633](https://github.com/rust-lang/rust/issues/42633) -- [Incremental Compilation Beta](https://internals.rust-lang.org/t/incremental-compilation-beta/4721) -- [Incremental Compilation Announcement](https://blog.rust-lang.org/2016/09/08/incremental.html) diff --git a/src/query.md b/src/query.md index 20e547b1e..24b0454b9 100644 --- a/src/query.md +++ b/src/query.md @@ -41,6 +41,8 @@ The [Incremental Compilation in Detail][query-model] chapter gives a more in-depth description of what queries are and how they work. If you intend to write a query of your own, this is a good read. +[query-model]: queries/incremental-compilation-in-detail.md + ### Invoking queries To invoke a query is simple. The tcx ("type context") offers a method @@ -288,4 +290,21 @@ rustc_queries! { `rustc_queries` macro will generate an appropriate `impl` automatically. -[query-model]: queries/incremental-compilation-in-detail.md +## External Links + +Related design ideas, and tracking issues: + +- Design document: [On-demand Rustc incremental design doc] +- Tracking Issue: ["Red/Green" dependency tracking in compiler] + +More discussion and issues: + +- [GitHub issue #42633] +- [Incremental Compilation Beta] +- [Incremental Compilation Announcement] + +[On-demand Rustc incremental design doc]: https://github.com/nikomatsakis/rustc-on-demand-incremental-design-doc/blob/master/0000-rustc-on-demand-and-incremental.md +["Red/Green" dependency tracking in compiler]: https://github.com/rust-lang/rust/issues/42293 +[GitHub issue #42633]: https://github.com/rust-lang/rust/issues/42633 +[Incremental Compilation Beta]: https://internals.rust-lang.org/t/incremental-compilation-beta/4721 +[Incremental Compilation Announcement]: https://blog.rust-lang.org/2016/09/08/incremental.html From 77a9813ae0f3f56010043abe0c2015b8673b266e Mon Sep 17 00:00:00 2001 From: Smittyvb Date: Sat, 21 Aug 2021 19:55:56 -0400 Subject: [PATCH 1518/1812] Expand THIR section with more details (#1183) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Expand THIR section with more details * Remove incorrect reference to `HirId`s Co-authored-by: Léo Lanteri Thauvin --- src/thir.md | 190 ++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 183 insertions(+), 7 deletions(-) diff --git a/src/thir.md b/src/thir.md index a1d389907..95009e552 100644 --- a/src/thir.md +++ b/src/thir.md @@ -4,10 +4,11 @@ The THIR ("Typed High-Level Intermediate Representation"), previously called HAIR for "High-Level Abstract IR", is another IR used by rustc that is generated after -[type checking]. It is (as of March 2021) only used for -[MIR construction] and [exhaustiveness checking], but -[it may also soon be used for unsafety checking][thir-unsafeck] as a replacement -for the current MIR unsafety checker. +[type checking]. It is (as of August 2021) only used for +[MIR construction] and [exhaustiveness checking]. There is also +[an experimental unsafety checker][thir-unsafeck] that operates on the THIR as a replacement for +the current MIR unsafety checker, and can be used instead of the MIR unsafety checker by passing +the `-Z thir-unsafeck` flag to `rustc`. [type checking]: ./type-checking.md [MIR construction]: ./mir/construction.md @@ -19,8 +20,8 @@ the types have been filled in, which is possible after type checking has complet But it has some other interesting features that distinguish it from the HIR: - Like the MIR, the THIR only represents bodies, i.e. "executable code"; this includes - function bodies, but also `const` initializers, for example. Consequently, the THIR - has no representation for items like `struct`s or `trait`s. + function bodies, but also `const` initializers, for example. Specifically, all [body owners] have + THIR created. Consequently, the THIR has no representation for items like `struct`s or `trait`s. - Each body of THIR is only stored temporarily and is dropped as soon as it's no longer needed, as opposed to being stored until the end of the compilation process (which @@ -31,7 +32,13 @@ But it has some other interesting features that distinguish it from the HIR: are made explicit, and method calls and overloaded operators are converted into plain function calls. Destruction scopes are also made explicit. +- Statements, expressions, and match arms are stored separately. For example, statements in the + `stmts` array reference expressions by their index (represented as a [`ExprId`]) in the `exprs` + array. + [HIR]: ./hir.md +[`ExprId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/thir/struct.ExprId.html +[body owners]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/enum.BodyOwnerKind.html The THIR lives in [`rustc_mir_build::thir`][thir-docs]. To construct a [`thir::Expr`], you can use the [`thir_body`] function, passing in the memory arena where the THIR @@ -40,7 +47,176 @@ which is useful to keep peak memory in check. Having a THIR representation of all bodies of a crate in memory at the same time would be very heavy. You can get a debug representation of the THIR by passing the `-Zunpretty=thir-tree` flag -to `rustc`. +to `rustc`. Here is how a function with just the statement `let x = 1 + 2;` gets represented in +THIR: +```rust +Thir { + // no match arms + arms: [], + exprs: [ + // expression 0, a literal with a value of 1 + Expr { + ty: i32, + temp_lifetime: Some(Node(6)), + span: oneplustwo.rs:2:13: 2:14 (#0), + kind: Literal { + literal: Const { + ty: i32, + val: Value(Scalar(0x00000001)), + }, + user_ty: None, + const_id: None, + }, + }, + // expression 1, scope surronding literal 1 + Expr { + ty: i32, + temp_lifetime: Some(Node(6)), + span: oneplustwo.rs:2:13: 2:14 (#0), + kind: Scope { + region_scope: Node(1), + lint_level: Explicit(HirId { + owner: DefId(0:3 ~ oneplustwo[6ccc]::main), + local_id: 1, + }), + // reference to expression 0 above + value: e0, + }, + }, + // expression 2, literal 2 + Expr { + ty: i32, + temp_lifetime: Some(Node(6)), + span: oneplustwo.rs:2:17: 2:18 (#0), + kind: Literal { + literal: Const { + ty: i32, + val: Value(Scalar(0x00000002)), + }, + user_ty: None, + const_id: None, + }, + }, + // expression 3, scope surrounding literal 2 + Expr { + ty: i32, + temp_lifetime: Some(Node(6)), + span: oneplustwo.rs:2:17: 2:18 (#0), + kind: Scope { + region_scope: Node(2), + lint_level: Explicit(HirId { + owner: DefId(0:3 ~ oneplustwo[6ccc]::main), + local_id: 2, + }), + // reference to expression 2 above + value: e2, + }, + }, + // expression 4, represents 1 + 2 + Expr { + ty: i32, + temp_lifetime: Some(Node(6)), + span: oneplustwo.rs:2:13: 2:18 (#0), + kind: Binary { + op: Add, + // references to scopes surronding literals above + lhs: e1, + rhs: e3, + }, + }, + // expression 5, scope surronding expression 4 + Expr { + ty: i32, + temp_lifetime: Some(Node(6)), + span: oneplustwo.rs:2:13: 2:18 (#0), + kind: Scope { + region_scope: Node(3), + lint_level: Explicit(HirId { + owner: DefId(0:3 ~ oneplustwo[6ccc]::main), + local_id: 3, + }), + value: e4, + }, + }, + // expression 6, block around statement + Expr { + ty: (), + temp_lifetime: Some(Node(8)), + span: oneplustwo.rs:1:11: 3:2 (#0), + kind: Block { + body: Block { + targeted_by_break: false, + region_scope: Node(7), + opt_destruction_scope: None, + span: oneplustwo.rs:1:11: 3:2 (#0), + // reference to statement 0 below + stmts: [ s0 ], + expr: None, + safety_mode: Safe, + }, + }, + }, + // expression 7, scope around block in expression 6 + Expr { + ty: (), + temp_lifetime: Some( + Node(8), + ), + span: oneplustwo.rs:1:11: 3:2 (#0), + kind: Scope { + region_scope: Node(8), + lint_level: Explicit(HirId { + owner: DefId(0:3 ~ oneplustwo[6ccc]::main), + local_id: 8, + }), + value: e6, + }, + }, + // destruction scope around expression 7 + Expr { + ty: (), + temp_lifetime: Some(Node(8)), + span: oneplustwo.rs:1:11: 3:2 (#0), + kind: Scope { + region_scope: Destruction(8), + lint_level: Inherited, + value: e7, + }, + }, + ], + stmts: [ + // let statement + Stmt { + kind: Let { + remainder_scope: Remainder { block: 7, first_statement_index: 0}, + init_scope: Node(6), + pattern: Pat { + ty: i32, + span: oneplustwo.rs:2:9: 2:10 (#0), + kind: Binding { + mutability: Not, + name: "x", + mode: ByValue, + var: HirId { + owner: DefId(0:3 ~ oneplustwo[6ccc]::main), + local_id: 5, + }, + ty: i32, + subpattern: None, + is_primary: true, + }, + }, + initializer: Some(e5), + lint_level: Explicit(HirId { + owner: DefId(0:3 ~ oneplustwo[6ccc]::main), + local_id: 4, + }), + }, + opt_destruction_scope: Some(Destruction(6)), + }, + ], +} +``` [thir-docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/index.html [`thir::Expr`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/thir/struct.Expr.html From cf0e151b7925a40f13fbc6573c6f97d5f94c7c17 Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Sun, 22 Aug 2021 16:47:02 +0200 Subject: [PATCH 1519/1812] =?UTF-8?q?Fix=20typo=20=E2=80=9Ca=20Rc=E2=80=9D?= =?UTF-8?q?=20=E2=86=92=20=E2=80=9Can=20Rc=E2=80=9D=20(#1191)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/query.md b/src/query.md index 24b0454b9..719568791 100644 --- a/src/query.md +++ b/src/query.md @@ -60,7 +60,7 @@ method. The answer is that, for each query, the compiler maintains a cache – if your query has already been executed, then, the answer is simple: we clone the return value out of the cache and return it (therefore, you should try to ensure that the return types of queries -are cheaply cloneable; insert a `Rc` if necessary). +are cheaply cloneable; insert an `Rc` if necessary). #### Providers From e1dde3c2a5aff04e02ec32fc7fde972da5c4f8ec Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 26 Aug 2021 16:34:43 -0700 Subject: [PATCH 1520/1812] date-check: Recognize capitalized 'Date' as well Now, if people use 'Date' instead of 'date', it won't be ignored. --- ci/date-check/src/main.rs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/ci/date-check/src/main.rs b/ci/date-check/src/main.rs index d78b430b5..bbea2bf38 100644 --- a/ci/date-check/src/main.rs +++ b/ci/date-check/src/main.rs @@ -39,7 +39,7 @@ fn make_date_regex() -> Regex { Regex::new( r"(?x) # insignificant whitespace mode bar")); } + #[test] + fn test_date_regex_capitalized() { + let regex = make_date_regex(); + assert!(regex.is_match("foo bar")); + } + #[test] fn test_collect_dates_from_file() { let text = "Test1\n\nTest2\nFoo February 2021: flag. - `check-code-block-syntax` validates syntax inside Rust code blocks - (`` ```rust ``) + (```rust) - `check-invalid-html-tags` detects invalid HTML (like an unclosed ``) in doc comments. From 7f8f19fd97abf571107b002c17cff3133b7993e9 Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Sat, 28 Aug 2021 09:35:36 +0200 Subject: [PATCH 1522/1812] Fix warning "Renderer command uses a path relative to the renderer output directory ..." (#1194) --- book.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book.toml b/book.toml index fb09c804e..f53ed45f6 100644 --- a/book.toml +++ b/book.toml @@ -19,7 +19,7 @@ enable = true level = 0 [output.linkcheck] -command = "../../ci/linkcheck.sh" +command = "ci/linkcheck.sh" follow-web-links = true exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il", "www\\.amazon\\.com", "www\\.rustaceans\\.org", "play\\.rust-lang\\.org" ] cache-timeout = 86400 From 2f447292ffd9079331802a6ce26edaf48760cfbc Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Sat, 28 Aug 2021 13:26:16 +0200 Subject: [PATCH 1523/1812] Trailing date comments in a line inside of a paragraph caused beginning of a new paragraph. (#1196) This PR fixes the 2 occurrences of that. (I'm not sure if there's an underlying issue with mdbook or if this is working as intended.) --- src/rustdoc-internals.md | 4 ++-- src/tests/adding.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index 2e06d5b1f..a74078951 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -78,8 +78,8 @@ Here is the list of passes as of February 2021: in doc comments. - `check-non-autolinks` detects links that could or should be written using - angle brackets (the code behind the nightly-only - `non_autolinks` lint). + angle brackets (the code behind the nightly-only `non_autolinks` + lint). - `collapse-docs` concatenates all document attributes into one document attribute. This is necessary because each line of a doc comment is given as a diff --git a/src/tests/adding.md b/src/tests/adding.md index 8508c2f20..d9b063d5c 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -339,8 +339,8 @@ The error levels that you can have are: ## Revisions -Certain classes of tests support "revisions" (as of -February 2021, this includes compile-fail, run-fail, and incremental, though +Certain classes of tests support "revisions" (as of February 2021, +this includes compile-fail, run-fail, and incremental, though incremental tests are somewhat different). Revisions allow a single test file to be used for multiple tests. This is done by adding a special header at the top of the file: From fa6a787cfdfe200149e111fa995fd1ced685ac2d Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sat, 28 Aug 2021 15:07:20 -0700 Subject: [PATCH 1524/1812] Fix typo, clarify backtick wording, and use inline code --- src/diagnostics.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 385d7db60..ca2ba13ca 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -38,7 +38,7 @@ LL | more code - Primary and secondary spans underlying the users' code. These spans can optionally contain one or more labels. - Primary spans should have enough text to describe the problem in such a - way that if it where the only thing being displayed (for example, in an + way that if it were the only thing being displayed (for example, in an IDE) it would still make sense. Because it is "spatially aware" (it points at the code), it can generally be more succinct than the error message. @@ -61,7 +61,7 @@ error: the fobrulator needs to be krontrificated ``` When code or an identifier must appear in a message or label, it should be -surrounded with single acute accents \`. +surrounded with backticks: `` `foo.bar` ``. ### Error explanations @@ -449,8 +449,8 @@ The possible values of [`Applicability`][appl] are: - `MachineApplicable`: Can be applied mechanically. - `HasPlaceholders`: Cannot be applied mechanically because it has placeholder - text in the suggestions. For example, "Try adding a type: \`let x: - \\`". + text in the suggestions. For example: ``try adding a type: `let x: + ` ``. - `MaybeIncorrect`: Cannot be applied mechanically because the suggestion may or may not be a good one. - `Unspecified`: Cannot be applied mechanically because we don't know which From 9be3fafda6c536d0ed1547ee1fb736b9b2419ce4 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Tue, 31 Aug 2021 12:13:18 -0500 Subject: [PATCH 1525/1812] Add rustc-source to suggested rust-analyzer config (#1189) This allows loading the sources for crates loaded from the sysroot. --- src/building/suggested.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/building/suggested.md b/src/building/suggested.md index bb6badcd6..e544a68b8 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -36,6 +36,7 @@ you can write: ], "editor.formatOnSave": true, "rust-analyzer.cargo.runBuildScripts": false, + "rust-analyzer.rustcSource": "./Cargo.toml", "rust-analyzer.procMacro.enable": false } ``` From 95f1acf9a39d6f402f654e917e2c1dfdb779c5fc Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Tue, 31 Aug 2021 10:31:06 -0700 Subject: [PATCH 1526/1812] Add link to `Span` --- src/appendix/glossary.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 8e5d5b394..6b3ec4196 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -71,7 +71,7 @@ Term | Meaning side tables   | Because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node. sigil   | Like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references. soundness   | A technical term in type theory. Roughly, if a type system is sound, then a program that type-checks is type-safe. That is, one can never (in safe rust) force a value into a variable of the wrong type. (see "completeness"). -span   | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more. +span   | A location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the [`Span`] datatype for more. substs   | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). sysroot   | The directory for build artifacts that are loaded by the compiler at runtime. ([see more](../building/bootstrapping.html#what-is-a-sysroot)) tag   | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). @@ -93,5 +93,6 @@ Term | Meaning [LLVM]: https://llvm.org/ [lto]: https://llvm.org/docs/LinkTimeOptimization.html +[`Span`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html [thinlto]: https://clang.llvm.org/docs/ThinLTO.html [TLS]: https://llvm.org/docs/LangRef.html#thread-local-storage-models From 139b8fb11ba251731e9d9f65901f3a04051a049b Mon Sep 17 00:00:00 2001 From: Fridtjof Stoldt Date: Wed, 1 Sep 2021 20:26:58 +0200 Subject: [PATCH 1527/1812] Documenting diagnostic items with their usage and naming conventions (#1192) * Documenting diagnostic items with their usage and naming conventions * Fixed typos in diagnostic items documentation Co-authored-by: Camelid Co-authored-by: Camelid --- src/SUMMARY.md | 1 + src/diagnostics/diagnostic-items.md | 146 ++++++++++++++++++++++++++++ 2 files changed, 147 insertions(+) create mode 100644 src/diagnostics/diagnostic-items.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index cb3b4b404..33dbbf7e2 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -132,6 +132,7 @@ - [Creating Errors With SessionDiagnostic](./diagnostics/sessiondiagnostic.md) - [`LintStore`](./diagnostics/lintstore.md) - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) + - [Diagnostic Items](./diagnostics/diagnostic-items.md) # MIR to Binaries diff --git a/src/diagnostics/diagnostic-items.md b/src/diagnostics/diagnostic-items.md new file mode 100644 index 000000000..efaa01cf3 --- /dev/null +++ b/src/diagnostics/diagnostic-items.md @@ -0,0 +1,146 @@ +# Diagnostic Items + +## Background + +While writing lints it's common to check for specific types, traits and functions. This raises +the question on how to check for these. Types can be checked by their complete type path. +However, this requires hard coding paths and can lead to misclassifications in some edge cases. +To counteract this, rustc has introduced diagnostic items that are used to identify types via +[`Symbol`]s. + +## How To Find Diagnostic Items + +Diagnostic items are added to items inside `rustc`/`std`/`core` with the `rustc_diagnostic_item` +attribute. The item for a specific type can be found by opening the source code in the +documentation and looking for this attribute. Note that it's often added with the `cfg_attr` +attribute to avoid compilation errors during tests. A definition often looks like this: + +```rs +// This is the diagnostic item for this type vvvvvvv +#[cfg_attr(not(test), rustc_diagnostic_item = "Penguin")] +struct Penguin; +``` + +Diagnostic items are usually only added to traits, types and standalone functions. If the goal +is to check for an associated type or method, please use the diagnostic item of the item and +reference [*Using Diagnostic Items*](#using-diagnostic-items). + +## How To Add Diagnostic Items + +A new diagnostic item can be added with these two steps: + +1. Find the target item inside the rust repo. Now add the diagnostic item as a string via the + `rustc_diagnostic_item` attribute. This can sometimes cause compilation errors while running + tests. These errors can be avoided by using the `cfg_attr` attribute with the `not(test)` + condition (it's fine adding then for all `rustc_diagnostic_item` attributes as a preventive + manner). At the end, it should look like this: + + ```rs + // This will be the new diagnostic item vvv + #[cfg_attr(not(test), rustc_diagnostic_item = "Cat")] + struct Cat; + ``` + + For the naming conventions of diagnostic items, please refer to + [*Naming Conventions*](#naming-conventions). + +2. As of August 2021 diagnostic items in code are accessed via symbols in + [`rustc_span::symbol::sym`]. To add your newly created diagnostic item simply open the + module file and add the name (In this case `Cat`) at the correct point in the list. + +Now you can create a pull request with your changes. :tada: (Note that when using diagnostic +items in other projects like Clippy, it might take some time until the repos get synchronized.) + +## Naming Conventions + +Diagnostic items don't have a set in stone naming convention yet. These are some guidelines that +should be used for the future, but might differ from existing names: + +* Types, traits and enums are named using UpperCamelCase (Examples: `Iterator`, `HashMap`, ...) +* For type names that are used multiple times like `Writer` it's good to choose a more precise + name, maybe by adding the module to it. (Example: `IoWriter`) +* Associated items should not get their own diagnostic items, but instead be accessed indirectly + by the diagnostic item of the type they're originating from. +* Freestanding functions like `std::mem::swap()` should be named using `snake_case` with one + important (export) module as a prefix (Example: `mem_swap`, `cmp_max`) +* Modules should usually not have a diagnostic item attached to them. Diagnostic items were + added to avoid the usage of paths, using them on modules would therefore most likely to be + counterproductive. + +## How To Use Diagnostic Items + +In rustc, diagnostic items are looked up via [`Symbol`]s from inside the +[`rustc_span::symbol::sym`] module. These can then be mapped to [`DefId`]s using +[`TyCtxt::get_diagnostic_item()`] or checked if they match a [`DefId`] using +[`TyCtxt::is_diagnostic_item()`]. When mapping from a diagnostic item to a [`DefId`] the method +will return a `Option`. This can be `None` if either the symbol isn't a diagnostic item +or the type is not registered, for instance when compiling with `#[no_std]`. All following +examples are based on [`DefId`]s and their usage. + +### Check For A Type + +```rust +use rustc_span::symbol::sym; + +/// This example checks if the given type (`ty`) has the type `HashMap` using +/// `TyCtxt::is_diagnostic_item()` +fn example_1(cx: &LateContext<'_>, ty: Ty<'_>) -> bool { + match ty.kind() { + ty::Adt(adt, _) => cx.tcx.is_diagnostic_item(sym::HashMap, adt.did), + _ => false, + } +} +``` + +### Check For A Trait Implementation + +```rust +/// This example checks if a given [`DefId`] from a method is part of a trait +/// implementation defined by a diagnostic item. +fn is_diag_trait_item( + cx: &LateContext<'_>, + def_id: DefId, + diag_item: Symbol +) -> bool { + if let Some(trait_did) = cx.tcx.trait_of_item(def_id) { + return cx.tcx.is_diagnostic_item(diag_item, trait_did); + } + false +} +``` + +### Associated Types + +Associated types of diagnostic items can be accessed indirectly by first getting the [`DefId`] +of the trait and then calling [`TyCtxt::associated_items()`]. This returns an [`AssocItems`] +object which can be used for further checks. Checkout +[`clippy_utils::ty::get_iterator_item_ty()`] for an example usage of this. + +### Usage In Clippy + +Clippy tries to use diagnostic items where possible and has developed some wrapper and utility +functions. Please also refer to its documentation when using diagnostic items in Clippy. (See +[*Common tools for writing lints*][clippy-Common-tools-for-writing-lints].) + +## Related Issues + +This lists some related issues. These are probably only interesting to people who really want to +take a deep dive into the topic :) + +* [rust#60966]: The Rust PR that introduced diagnostic items +* [rust-clippy#5393]: Clippy's tracking issue for moving away from hard coded paths to + diagnostic item + + + +[`rustc_span::symbol::sym`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/sym/index.html +[`Symbol`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html +[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html +[`TyCtxt::get_diagnostic_item()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.get_diagnostic_item +[`TyCtxt::is_diagnostic_item()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.is_diagnostic_item +[`TyCtxt::associated_items()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.associated_items +[`AssocItems`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/assoc/struct.AssocItems.html +[`clippy_utils::ty::get_iterator_item_ty()`]: https://github.com/rust-lang/rust-clippy/blob/305177342fbc622c0b3cb148467bab4b9524c934/clippy_utils/src/ty.rs#L55-L72 +[clippy-Common-tools-for-writing-lints]: https://github.com/rust-lang/rust-clippy/blob/master/doc/common_tools_writing_lints.md +[rust#60966]: https://github.com/rust-lang/rust/pull/60966 +[rust-clippy#5393]: https://github.com/rust-lang/rust-clippy/issues/5393 From 30826ca7d8da49fe323c71f1e3c65b4b270f792d Mon Sep 17 00:00:00 2001 From: Dezhi Wu Date: Sun, 5 Sep 2021 20:40:35 +0800 Subject: [PATCH 1528/1812] Fix a typo (#1200) --- src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 6c756e18f..cabd4fc7d 100644 --- a/src/overview.md +++ b/src/overview.md @@ -44,7 +44,7 @@ we'll talk about that later. - The parser [translates the token stream from the lexer into an Abstract Syntax Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax analysis. The crate entry points for the parser are the `Parser::parse_crate_mod()` and - `Parser::parse_mod()` methods found in `rustc_parse::parser::item`. The external + `Parser::parse_mod()` methods found in `rustc_parse::parser::Parser`. The external module parsing entry point is `rustc_expand::module::parse_external_mod`. And the macro parser entry point is [`Parser::parse_nonterminal()`][parse_nonterminal]. - Parsing is performed with a set of `Parser` utility methods including `fn bump`, From a5dea10a466ead10d2f00cbb6056379b57d49b80 Mon Sep 17 00:00:00 2001 From: sjud <64875465+sjud@users.noreply.github.com> Date: Sun, 5 Sep 2021 13:04:00 -0400 Subject: [PATCH 1529/1812] Spelling change intermidiate to intermediate Very importent change. --- src/salsa.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/salsa.md b/src/salsa.md index 9bf93727a..a6a6b9706 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -44,7 +44,7 @@ something that the library produces, but, for each derived value there's a "pure" function that computes the derived value. For example, there might be a function `ast(x: Path) -> AST`. The produced -`AST` isn't a final value, it's an intermidiate value that the library would +`AST` isn't a final value, it's an intermediate value that the library would use for the computation. This means that when you try to compute with the library, Salsa is going to @@ -126,7 +126,7 @@ Example input query group: ```rust,ignore /// This attribute will process this tree, produce this tree as output, and produce -/// a bunch of intermidiate stuff that Salsa also uses. One of these things is a +/// a bunch of intermediate stuff that Salsa also uses. One of these things is a /// "StorageStruct", whose name we have specified in the attribute. /// /// This query group is a bunch of **input** queries, that do not rely on any From 71d88b345f313f071361bf2c8dc74b30af1c7a15 Mon Sep 17 00:00:00 2001 From: Dezhi Wu Date: Tue, 7 Sep 2021 05:34:16 +0800 Subject: [PATCH 1530/1812] Add links to overview.md (#1202) --- src/overview.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/src/overview.md b/src/overview.md index cabd4fc7d..2e4c69550 100644 --- a/src/overview.md +++ b/src/overview.md @@ -43,16 +43,17 @@ we'll talk about that later. - The lexer preserves full fidelity information for both IDEs and proc macros. - The parser [translates the token stream from the lexer into an Abstract Syntax Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax - analysis. The crate entry points for the parser are the `Parser::parse_crate_mod()` and - `Parser::parse_mod()` methods found in `rustc_parse::parser::Parser`. The external - module parsing entry point is `rustc_expand::module::parse_external_mod`. And - the macro parser entry point is [`Parser::parse_nonterminal()`][parse_nonterminal]. + analysis. The crate entry points for the parser are the + [`Parser::parse_crate_mod()`][parse_crate_mod] and [`Parser::parse_mod()`][parse_mod] + methods found in [`rustc_parse::parser::Parser`]. The external module parsing + entry point is [`rustc_expand::module::parse_external_mod`][parse_external_mod]. + And the macro parser entry point is [`Parser::parse_nonterminal()`][parse_nonterminal]. - Parsing is performed with a set of `Parser` utility methods including `fn bump`, `fn check`, `fn eat`, `fn expect`, `fn look_ahead`. - Parsing is organized by the semantic construct that is being parsed. Separate - `parse_*` methods can be found in `rustc_parse` `parser` directory. The source - file name follows the construct name. For example, the following files are found - in the parser: + `parse_*` methods can be found in [`rustc_parse` `parser`][rustc_parse_parser_dir] + directory. The source file name follows the construct name. For example, the + following files are found in the parser: - `expr.rs` - `pat.rs` - `ty.rs` @@ -123,6 +124,11 @@ we'll talk about that later. [`simplify_try`]: https://github.com/rust-lang/rust/pull/66282 [codegen]: https://rustc-dev-guide.rust-lang.org/backend/codegen.html [parse_nonterminal]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html#method.parse_nonterminal +[parse_crate_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html#method.parse_crate_mod +[parse_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html#method.parse_mod +[`rustc_parse::parser::Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html +[parse_external_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/module/fn.parse_external_mod.html +[rustc_parse_parser_dir]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_parse/src/parser ## How it does it From 0fe44f730b5c5917354ad36777fbfbb473427d8a Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 13:11:09 -0700 Subject: [PATCH 1531/1812] Docs: consolidated parallelism information --- src/overview.md | 7 +-- src/parallel-rustc.md | 61 ++++++++++++++----- .../query-evaluation-model-in-detail.md | 26 -------- 3 files changed, 47 insertions(+), 47 deletions(-) diff --git a/src/overview.md b/src/overview.md index 2e4c69550..26b291d35 100644 --- a/src/overview.md +++ b/src/overview.md @@ -297,12 +297,7 @@ Compiler performance is a problem that we would like to improve on (and are always working on). One aspect of that is parallelizing `rustc` itself. -Currently, there is only one part of rustc that is already parallel: codegen. -During monomorphization, the compiler will split up all the code to be -generated into smaller chunks called _codegen units_. These are then generated -by independent instances of LLVM. Since they are independent, we can run them -in parallel. At the end, the linker is run to combine all the codegen units -together into one binary. +Currently, there is only one part of rustc that is parallel by default: codegen. However, the rest of the compiler is still not yet parallel. There have been lots of efforts spent on this, but it is generally a hard problem. The current diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index eec8219a5..243dca98e 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -1,24 +1,54 @@ # Parallel Compilation -Most of the compiler is not parallel. This represents an opportunity for -improving compiler performance. +As of September 2021, The only stage of the compiler +that is already parallel is codegen. The nightly compiler implements query evaluation, +but there is a lot of correctness work that needs to be done. The lack of parallelism at other stages +also represents an opportunity for improving compiler performance. One can try out the current +parallel compiler work by enabling it in the `config.toml`. -As of July 2021, work on explicitly parallelizing the -compiler has stalled. There is a lot of design and correctness work that needs -to be done. +These next few sections describe where and how parallelism is currently used, +and the current status of making parallel compilation the default in `rustc`. + +The underlying thread-safe data-structures used in the parallel compiler +can be found in `rustc_data_structures/sync.rs`. Some of these data structures +use the `parking_lot` API. + +## Code Gen + +During [monomorphization][monomorphization] the compiler splits up all the code to +be generated into smaller chunks called _codegen units_. These are then generated by +independent instances of LLVM running in parallel. At the end, the linker +is run to combine all the codegen units together into one binary. + +## Query System -One can try out the current parallel compiler work by enabling it in the -`config.toml`. +The query model has some properties that make it actually feasible to evaluate +multiple queries in parallel without too much of an effort: -There are a few basic ideas in this effort: +- All data a query provider can access is accessed via the query context, so + the query context can take care of synchronizing access. +- Query results are required to be immutable so they can safely be used by + different threads concurrently. -- There are a lot of loops in the compiler that just iterate over all items in - a crate. These can possibly be parallelized. -- We can use (a custom fork of) [`rayon`] to run tasks in parallel. The custom - fork allows the execution of DAGs of tasks, not just trees. -- There are currently a lot of global data structures that need to be made - thread-safe. A key strategy here has been converting interior-mutable - data-structures (e.g. `Cell`) into their thread-safe siblings (e.g. `Mutex`). + +When a query `foo` is evaluated, the cache table for `foo` is locked. + +- If there already is a result, we can clone it, release the lock and + we are done. +- If there is no cache entry and no other active query invocation computing the + same result, we mark the key as being "in progress", release the lock and + start evaluating. +- If there *is* another query invocation for the same key in progress, we + release the lock, and just block the thread until the other invocation has + computed the result we are waiting for. This cannot deadlock because, as + mentioned before, query invocations form a DAG. Some thread will always make + progress. + +## Current Status + +As of July 2021, work on explicitly parallelizing the +compiler has stalled. There is a lot of design and correctness work that needs +to be done. [`rayon`]: https://crates.io/crates/rayon @@ -45,3 +75,4 @@ are a bit out of date): [imlist]: https://github.com/nikomatsakis/rustc-parallelization/blob/master/interior-mutability-list.md [irlo1]: https://internals.rust-lang.org/t/help-test-parallel-rustc/11503 [tracking]: https://github.com/rust-lang/rust/issues/48685 +[monomorphization]:https://rustc-dev-guide.rust-lang.org/backend/monomorph.html diff --git a/src/queries/query-evaluation-model-in-detail.md b/src/queries/query-evaluation-model-in-detail.md index 4c2427e3c..b84a5dac4 100644 --- a/src/queries/query-evaluation-model-in-detail.md +++ b/src/queries/query-evaluation-model-in-detail.md @@ -211,29 +211,3 @@ much of a maintenance burden. To summarize: "Steal queries" break some of the rules in a controlled way. There are checks in place that make sure that nothing can go silently wrong. - - -## Parallel Query Execution - -The query model has some properties that make it actually feasible to evaluate -multiple queries in parallel without too much of an effort: - -- All data a query provider can access is accessed via the query context, so - the query context can take care of synchronizing access. -- Query results are required to be immutable so they can safely be used by - different threads concurrently. - -The nightly compiler already implements parallel query evaluation as follows: - -When a query `foo` is evaluated, the cache table for `foo` is locked. - -- If there already is a result, we can clone it, release the lock and - we are done. -- If there is no cache entry and no other active query invocation computing the - same result, we mark the key as being "in progress", release the lock and - start evaluating. -- If there *is* another query invocation for the same key in progress, we - release the lock, and just block the thread until the other invocation has - computed the result we are waiting for. This cannot deadlock because, as - mentioned before, query invocations form a DAG. Some thread will always make - progress. From 78afd53e8a0770c4f35031cd20ebd7ae00fdb17f Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 13:18:17 -0700 Subject: [PATCH 1532/1812] Docs: delete redundant use of correctness --- src/parallel-rustc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 243dca98e..7f20078b9 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -2,7 +2,7 @@ As of September 2021, The only stage of the compiler that is already parallel is codegen. The nightly compiler implements query evaluation, -but there is a lot of correctness work that needs to be done. The lack of parallelism at other stages +but there is still a lot of work to be done. The lack of parallelism at other stages also represents an opportunity for improving compiler performance. One can try out the current parallel compiler work by enabling it in the `config.toml`. From c31ec83e91217d707a744f56db1478ee31e469c8 Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 13:42:56 -0700 Subject: [PATCH 1533/1812] Docs: added section discussing core ideas --- src/parallel-rustc.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 7f20078b9..a29e4f974 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -48,7 +48,22 @@ When a query `foo` is evaluated, the cache table for `foo` is locked. As of July 2021, work on explicitly parallelizing the compiler has stalled. There is a lot of design and correctness work that needs -to be done. +to be done. + +These are the basic ideas in the effort to make `rustc` parallel: + +- All data a query provider can access is accessed via the query context, so + the query context can take care of synchronizing access. +- Query results are required to be immutable so they can safely be used by + different threads concurrently. + +- There are a lot of loops in the compiler that just iterate over all items in + a crate. These can possibly be parallelized. +- We can use (a custom fork of) [`rayon`] to run tasks in parallel. The custom + fork allows the execution of DAGs of tasks, not just trees. +- There are currently a lot of global data structures that need to be made + thread-safe. A key strategy here has been converting interior-mutable + data-structures (e.g. `Cell`) into their thread-safe siblings (e.g. `Mutex`). [`rayon`]: https://crates.io/crates/rayon From 1df026246a83b47c19615db038193e1a6271be6f Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 13:45:44 -0700 Subject: [PATCH 1534/1812] Docs: deleted copy --- src/parallel-rustc.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index a29e4f974..67f349ac3 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -30,7 +30,6 @@ multiple queries in parallel without too much of an effort: - Query results are required to be immutable so they can safely be used by different threads concurrently. - When a query `foo` is evaluated, the cache table for `foo` is locked. - If there already is a result, we can clone it, release the lock and @@ -52,11 +51,6 @@ to be done. These are the basic ideas in the effort to make `rustc` parallel: -- All data a query provider can access is accessed via the query context, so - the query context can take care of synchronizing access. -- Query results are required to be immutable so they can safely be used by - different threads concurrently. - - There are a lot of loops in the compiler that just iterate over all items in a crate. These can possibly be parallelized. - We can use (a custom fork of) [`rayon`] to run tasks in parallel. The custom From 0eb2c70cf5fb0c5f79b6b1292fb6feaf438932e7 Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Mon, 6 Sep 2021 16:08:07 -0700 Subject: [PATCH 1535/1812] Docs: made suggested fix --- src/parallel-rustc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 67f349ac3..d1eff7ad7 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -13,7 +13,7 @@ The underlying thread-safe data-structures used in the parallel compiler can be found in `rustc_data_structures/sync.rs`. Some of these data structures use the `parking_lot` API. -## Code Gen +## Codegen During [monomorphization][monomorphization] the compiler splits up all the code to be generated into smaller chunks called _codegen units_. These are then generated by From 0cc70fcaf16fb7282e311e25e7b2070d299f8d4e Mon Sep 17 00:00:00 2001 From: Timothy Maloney Date: Tue, 7 Sep 2021 08:52:52 -0700 Subject: [PATCH 1536/1812] Docs: added section on rustdoc --- src/parallel-rustc.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index d1eff7ad7..38230377b 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -43,6 +43,12 @@ When a query `foo` is evaluated, the cache table for `foo` is locked. mentioned before, query invocations form a DAG. Some thread will always make progress. +## Rustdoc + +As of September 2021, there are still a number of steps +to complete before rustdoc rendering can be made parallel. More details on +this issue can be found [here][parallel-rustdoc]. + ## Current Status As of July 2021, work on explicitly parallelizing the @@ -85,3 +91,4 @@ are a bit out of date): [irlo1]: https://internals.rust-lang.org/t/help-test-parallel-rustc/11503 [tracking]: https://github.com/rust-lang/rust/issues/48685 [monomorphization]:https://rustc-dev-guide.rust-lang.org/backend/monomorph.html +[parallel-rustdoc]:https://github.com/rust-lang/rust/issues/82741 From 9a42b37519250d7c1da5a6b5582316a9e7d89e36 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Wed, 8 Sep 2021 10:17:39 -0700 Subject: [PATCH 1537/1812] Clarify paragraph in "Keeping things up to date" --- src/git.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/git.md b/src/git.md index 72d287151..ac03a3c0f 100644 --- a/src/git.md +++ b/src/git.md @@ -269,9 +269,9 @@ git push --force-with-lease (set origin to be the same as local) ``` To avoid merges as per the [No-Merge Policy](#no-merge-policy), you may want to use -`git config pull.ff only` (this will apply the config to the local repo). -to avoid merge conflicts while pulling, without needing -`--ff-only` or `--rebase` while `git pull`ing +`git config pull.ff only` (this will apply the config only to the local repo) +to ensure that Git doesn't create merge commits when `git pull`ing, without +needing to pass `--ff-only` or `--rebase` every time. You can also `git push --force-with-lease` from master to keep your origin's master in sync with upstream. From 5b607d9862df60a2dd6b4cea52f595717b113cd5 Mon Sep 17 00:00:00 2001 From: Andrey Cherkashin <148123+andoriyu@users.noreply.github.com> Date: Mon, 26 Apr 2021 14:28:27 -0700 Subject: [PATCH 1538/1812] Delete ctags.md --- src/building/ctags.md | 26 -------------------------- 1 file changed, 26 deletions(-) delete mode 100644 src/building/ctags.md diff --git a/src/building/ctags.md b/src/building/ctags.md deleted file mode 100644 index 9b6331457..000000000 --- a/src/building/ctags.md +++ /dev/null @@ -1,26 +0,0 @@ -# ctags - -One of the challenges with rustc is that the RLS can't handle it, since it's a -bootstrapping compiler. This makes code navigation difficult. One solution is to -use `ctags`. - -`ctags` has a long history and several variants. Exuberant Ctags seems to be -quite commonly distributed but it does not have out-of-box Rust support. Some -distributions seem to use [Universal Ctags][utags], which is a maintained fork -and does have built-in Rust support. - -The following script can be used to set up Exuberant Ctags: -[https://github.com/nikomatsakis/rust-etags][etags]. - -`ctags` integrates into emacs and vim quite easily. The following can then be -used to build and generate tags: - -```console -$ rust-ctags src/lib* && ./x.py build -``` - -This allows you to do "jump-to-def" with whatever functions were around when -you last built, which is ridiculously useful. - -[etags]: https://github.com/nikomatsakis/rust-etags -[utags]: https://github.com/universal-ctags/ctags From fb62bc398fb155a701fb968e7a9b3c0771369d52 Mon Sep 17 00:00:00 2001 From: Andrey Cherkashin <148123+andoriyu@users.noreply.github.com> Date: Mon, 26 Apr 2021 14:30:54 -0700 Subject: [PATCH 1539/1812] Move ctag section to "Suggested Workflow" --- src/building/suggested.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/src/building/suggested.md b/src/building/suggested.md index e544a68b8..c05015851 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -71,6 +71,34 @@ Task] instead: [Build Task]: https://code.visualstudio.com/docs/editor/tasks + +## Configuring `ctags` + +One of the challenges with rustc is that the RLS can't handle it, since it's a +bootstrapping compiler. This makes code navigation difficult. One solution is to +use `ctags`. + +`ctags` has a long history and several variants. Exuberant Ctags seems to be +quite commonly distributed but it does not have out-of-box Rust support. Some +distributions seem to use [Universal Ctags][utags], which is a maintained fork +and does have built-in Rust support. + +The following script can be used to set up Exuberant Ctags: +[https://github.com/nikomatsakis/rust-etags][etags]. + +`ctags` integrates into emacs and vim quite easily. The following can then be +used to build and generate tags: + +```console +$ rust-ctags src/lib* && ./x.py build +``` + +This allows you to do "jump-to-def" with whatever functions were around when +you last built, which is ridiculously useful. + +[etags]: https://github.com/nikomatsakis/rust-etags +[utags]: https://github.com/universal-ctags/ctags + ## Check, check, and check again When doing simple refactorings, it can be useful to run `./x.py check` From d1f77858e71031b5c89fd842559a8f495e8e64cd Mon Sep 17 00:00:00 2001 From: Andrey Cherkashin <148123+andoriyu@users.noreply.github.com> Date: Mon, 26 Apr 2021 14:35:50 -0700 Subject: [PATCH 1540/1812] Update SUMMARY.md --- src/SUMMARY.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 33dbbf7e2..c69ad73a5 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -14,7 +14,6 @@ - [Distribution artifacts](./building/build-install-distribution-artifacts.md) - [Documenting Compiler](./building/compiler-documenting.md) - [Rustdoc overview](./rustdoc.md) - - [ctags](./building/ctags.md) - [Adding a new target](./building/new-target.md) - [The compiler testing framework](./tests/intro.md) - [Running tests](./tests/running.md) From 8f98dac74d4f9a98aa03dfc4adcf66d14c155dde Mon Sep 17 00:00:00 2001 From: Andrey Cherkashin <148123+andoriyu@users.noreply.github.com> Date: Mon, 26 Apr 2021 14:37:25 -0700 Subject: [PATCH 1541/1812] Update suggested.md --- src/building/suggested.md | 1 - 1 file changed, 1 deletion(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index c05015851..ac8127a42 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -71,7 +71,6 @@ Task] instead: [Build Task]: https://code.visualstudio.com/docs/editor/tasks - ## Configuring `ctags` One of the challenges with rustc is that the RLS can't handle it, since it's a From 295922ec9350ced84bfad7164564e7e0c1d96573 Mon Sep 17 00:00:00 2001 From: Andrey Cherkashin <148123+andoriyu@users.noreply.github.com> Date: Wed, 8 Sep 2021 12:39:24 -0700 Subject: [PATCH 1542/1812] remove ctag section --- src/building/suggested.md | 27 --------------------------- 1 file changed, 27 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index ac8127a42..e544a68b8 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -71,33 +71,6 @@ Task] instead: [Build Task]: https://code.visualstudio.com/docs/editor/tasks -## Configuring `ctags` - -One of the challenges with rustc is that the RLS can't handle it, since it's a -bootstrapping compiler. This makes code navigation difficult. One solution is to -use `ctags`. - -`ctags` has a long history and several variants. Exuberant Ctags seems to be -quite commonly distributed but it does not have out-of-box Rust support. Some -distributions seem to use [Universal Ctags][utags], which is a maintained fork -and does have built-in Rust support. - -The following script can be used to set up Exuberant Ctags: -[https://github.com/nikomatsakis/rust-etags][etags]. - -`ctags` integrates into emacs and vim quite easily. The following can then be -used to build and generate tags: - -```console -$ rust-ctags src/lib* && ./x.py build -``` - -This allows you to do "jump-to-def" with whatever functions were around when -you last built, which is ridiculously useful. - -[etags]: https://github.com/nikomatsakis/rust-etags -[utags]: https://github.com/universal-ctags/ctags - ## Check, check, and check again When doing simple refactorings, it can be useful to run `./x.py check` From 9198465b6ca8bed669df0cbb67c0e6d0b140803c Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sun, 12 Sep 2021 09:12:40 -0700 Subject: [PATCH 1543/1812] Clarify difference of a help vs note diagnostic. --- src/diagnostics.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index ca2ba13ca..e35bde093 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -222,9 +222,13 @@ Guidelines for different diagnostic levels: The error or warning portion should *not* suggest how to fix the problem, only the "help" sub-diagnostic should. -- `note`: emitted to identify additional circumstances and parts of the code - that caused the warning or error. For example, the borrow checker will note - any previous conflicting borrows. +- `note`: emitted to given more context and identify additional circumstances + and parts of the code that caused the warning or error. For example, the + borrow checker will note any previous conflicting borrows. + + `help` vs `note`: `help` should be used to show changes the user can + possibly make to fix the problem. `note` should be used for everything else, + such as other context, information and facts, online resources to read, etc. Not to be confused with *lint levels*, whose guidelines are: From 8c39edb660e75a6b3edbecfe054d1426d8b8f4ba Mon Sep 17 00:00:00 2001 From: Sl1mb0 Date: Thu, 16 Sep 2021 18:58:07 -0700 Subject: [PATCH 1544/1812] Parallel codegen (#1206) * Described underlying data structures in parallel code generation and crates they are used in * Added links * replace crate information with description of types --- src/parallel-rustc.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 38230377b..2ee302d24 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -10,15 +10,24 @@ These next few sections describe where and how parallelism is currently used, and the current status of making parallel compilation the default in `rustc`. The underlying thread-safe data-structures used in the parallel compiler -can be found in `rustc_data_structures/sync.rs`. Some of these data structures -use the `parking_lot` API. +can be found in the `rustc_data_structures::sync` module. Some of these data structures +use the `parking_lot` crate as well. ## Codegen +There are two underlying thread safe data structures used in code generation: + +- `Lrc` + - Which is an [`Arc`][Arc] if `parallel_compiler` is true, and a [`Rc`][Rc] + if it is not. +- `MetadataRef` -> [`OwningRef, [u8]>`][OwningRef] + - This data structure is specific to `rustc`. + During [monomorphization][monomorphization] the compiler splits up all the code to be generated into smaller chunks called _codegen units_. These are then generated by independent instances of LLVM running in parallel. At the end, the linker -is run to combine all the codegen units together into one binary. +is run to combine all the codegen units together into one binary. This process +occurs in the `rustc_codegen_ssa::base` module. ## Query System @@ -92,3 +101,6 @@ are a bit out of date): [tracking]: https://github.com/rust-lang/rust/issues/48685 [monomorphization]:https://rustc-dev-guide.rust-lang.org/backend/monomorph.html [parallel-rustdoc]:https://github.com/rust-lang/rust/issues/82741 +[Arc]:https://doc.rust-lang.org/std/sync/struct.Arc.html +[Rc]:https://doc.rust-lang.org/std/rc/struct.Rc.html +[OwningRef]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/owning_ref/index.html From 09bf2bd2df3f5c36da9e6ed0a273aa5c21b50d28 Mon Sep 17 00:00:00 2001 From: lcnr Date: Fri, 17 Sep 2021 21:50:26 +0200 Subject: [PATCH 1545/1812] `ty::Unevaluated`: dealing with unused substs (#1190) * unused ct substs * q * q * Update src/constants.md Co-authored-by: Niko Matsakis --- src/constants.md | 65 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 src/constants.md diff --git a/src/constants.md b/src/constants.md new file mode 100644 index 000000000..9e63a58cd --- /dev/null +++ b/src/constants.md @@ -0,0 +1,65 @@ +# Constants in the type system + +Constants used in the type system are represented as [`ty::Const`]. +The variants of their [`ty::ConstKind`] mostly mirror the variants of [`ty::TyKind`] +with the two *additional* variants being `ConstKind::Value` and `ConstKind::Unevaluated`. + + +## Unevaluated constants + +*This section talks about what's happening with `feature(const_generics)` enabled. +On stable we do not yet supply any generic parameters to anonymous constants, +avoiding most of the issues mentioned here.* + +Unless a constant is either a simple literal, e.g. `[u8; 3]` or `foo::<{ 'c' }>()`, +or a generic parameter, e.g. `[u8; N]`, converting a constant to its [`ty::Const`] representation +returns an unevaluated constant. Even fully concrete constants which do not depend on a +generic parameter are not evaluated right away. + +We do not eagerly evaluate constant as they can be used in the `where`-clauses of their +parent item, for example: + +```rust +#[feature(const_generics, const_evaluatable_checked)] +fn foo() +where + [u8; ::ASSOC + 1]: SomeOtherTrait, +{} +``` + +The constant `::ASSOC + 1` depends on the `T: Trait` bound of +its parents caller bounds, but is also part of another bound itself. +If we were to eagerly evaluate this constant while computing its parents bounds +this would cause a query cycle. + +### Generic arguments of anonymous constants + +Anonymous constants inherit the generic parameters of their parent, which is +why the array length in `foo() -> [u8; N + 1]` can use `N`. + +Without any manual adjustments, this causes us to include parameters even if +the constant doesn't use them in any way. This can cause +[some interesting errors](pcg-unused-substs) and breaks some already stable code. + +To deal with this, we intend to look at the generic parameters explicitly mentioned +by the constants and then search the predicates of its parents to figure out which +of the other generic parameters are reachable by our constant. + +**TODO**: Expand this section once the parameter filtering is implemented. + +As constants can be part of their parents `where`-clauses, we mention unevaluated +constants in their parents predicates. It is therefore necessary to mention unevaluated +constants before we have computed the generic parameters +available to these constants. + +To do this unevaluated constants start out with [`substs_`] being `None` while assuming +that their generic arguments could be arbitrary generic parameters. +When first accessing the generic arguments of an unevaluated constants, we then replace +`substs_` with the actual default arguments of a constants, which are the generic parameters +of their parent we assume to be used by this constant. + +[`ty::Const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Const.html +[`ty::ConstKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.ConstKind.html +[`ty::TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html +[pcg-unused-substs]: https://github.com/rust-lang/project-const-generics/blob/master/design-docs/anon-const-substs.md#unused-substs +[`substs_`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/consts/kind/struct.Unevaluated.html#structfield.substs_ \ No newline at end of file From 60ef9da723b703d37c4da78b260f557bbc4f248e Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Fri, 17 Sep 2021 21:48:36 +0200 Subject: [PATCH 1546/1812] Suggests `--edition=2018` argument when using stage0/bin/rustfmt directly --- src/building/suggested.md | 5 +++-- src/getting-started.md | 2 ++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index e544a68b8..eed267f98 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -22,7 +22,7 @@ You can also install the hook as a step of running `x.py setup`! a file. By default, `rust-analyzer` runs the `cargo check` and `rustfmt` commands, but you can override these commands to use more adapted versions of these tools when hacking on `rustc`. For example, for Visual Studio Code, -you can write: +you can write: ```JSON { @@ -32,7 +32,8 @@ you can write: "--json-output" ], "rust-analyzer.rustfmt.overrideCommand": [ - "./build/TARGET_TRIPLE/stage0/bin/rustfmt" + "./build/TARGET_TRIPLE/stage0/bin/rustfmt", + "--edition=2018" ], "editor.formatOnSave": true, "rust-analyzer.cargo.runBuildScripts": false, diff --git a/src/getting-started.md b/src/getting-started.md index 18e429e5e..14225c504 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -293,6 +293,8 @@ format-on-save turned on. It's a good habit to run `./x.py fmt` before every commit, as this reduces conflicts later. The pinned version is built under `build//stage0/bin/rustfmt`, so if you want, you can use it for a single file or for format-on-save in your editor, which can be faster than `./x.py fmt`. +You'll have to pass the `--edition=2018` argument +yourself when calling `rustfmt` directly. One last thing: you can use `RUSTC_LOG=XXX` to get debug logging. [Read more here][logging]. Notice the `C` in `RUSTC_LOG`. Other than that, it uses normal From 56f6bdbb7045e4d619e39001bd0ba9da716c18df Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Fri, 17 Sep 2021 23:33:54 +0200 Subject: [PATCH 1547/1812] Make indentation consistent in example vscode config file --- src/building/suggested.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index eed267f98..f1665efdc 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -32,8 +32,8 @@ you can write: -As of January 2021, `rustc_codegen_ssa` provides an +As of October 2021, `rustc_codegen_ssa` provides an abstract interface for all backends to implement, to allow other codegen backends (e.g. [Cranelift]). diff --git a/src/contributing.md b/src/contributing.md index 9df9b6dfc..aca5b142e 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -424,12 +424,12 @@ Just a few things to keep in mind: Try to format the date as ` ` to ease search. - Additionally, include a machine-readable comment of the form `` (if the current month is January 2021). We have an automated + 2021-10 -->` (if the current month is October 2021). We have an automated tool that uses these (in `ci/date-check`). So, for the month of January 2021, the comment would look like: `As of January 2021`. Make sure to put the comment *between* `as of` - and `January 2021`; see [PR #1066][rdg#1066] for the rationale. + date: 2021-10 --> October 2021`. Make sure to put the comment *between* `as of` + and `October 2021`; see [PR #1066][rdg#1066] for the rationale. - A link to a relevant WG, tracking issue, `rustc` rustdoc page, or similar, that may provide further explanation for the change process or a way to verify that the information is not diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index a74078951..112a5dcab 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -71,29 +71,25 @@ Here is the list of passes as of February 2021: - `calculate-doc-coverage` calculates information used for the `--show-coverage` flag. +- `check-bare-urls` detects links that are not linkified, e.g., in Markdown such as + `Go to https://example.com/.` It suggests wrapping the link with angle brackets: + `Go to .` to linkify it. This is the code behind the + `rustdoc::bare_urls` lint. + - `check-code-block-syntax` validates syntax inside Rust code blocks (```rust) +- `check-doc-test-visibility` runs doctest visibility–related lints. + - `check-invalid-html-tags` detects invalid HTML (like an unclosed ``) in doc comments. -- `check-non-autolinks` detects links that could or should be written using - angle brackets (the code behind the nightly-only `non_autolinks` - lint). - -- `collapse-docs` concatenates all document attributes into one document - attribute. This is necessary because each line of a doc comment is given as a - separate doc attribute, and this will combine them into a single string with - line breaks between each attribute. - - `collect-intra-doc-links` resolves [intra-doc links](https://doc.rust-lang.org/rustdoc/linking-to-items-by-name.html). - `collect-trait-impls` collects trait impls for each item in the crate. For example, if we define a struct that implements a trait, this pass will note that the struct implements that trait. -- `doc-test-lints` runs various lints on the doctests. - - `propagate-doc-cfg` propagates `#[doc(cfg(...))]` to child items. - `strip-priv-imports` strips all private import statements (`use`, `extern From b71e9792c7f2316b4bfb2c0bbb5e8a042063bb11 Mon Sep 17 00:00:00 2001 From: Janggun Lee Date: Wed, 6 Oct 2021 21:07:51 +0900 Subject: [PATCH 1552/1812] Update links to `rustc_mir` in Two Phase Borrows (#1226) https://github.com/rust-lang/rust/pull/80522 split the `rustc_mir` crates into 5 crates, effectively invalidating all the direct links to `rustc_mir` in the docs. I found this while looking at the Two Phase Borrows doc, which is why I am giving out this PR to fix this. --- src/borrow_check/two_phase_borrows.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/borrow_check/two_phase_borrows.md b/src/borrow_check/two_phase_borrows.md index a5e26c6a8..bcd487821 100644 --- a/src/borrow_check/two_phase_borrows.md +++ b/src/borrow_check/two_phase_borrows.md @@ -77,7 +77,7 @@ borrow. [converted]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/thir/cx/expr/trait.ToBorrowKind.html#method.to_borrow_kind [`BorrowKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.BorrowKind.html [`GatherBorrows`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/visit/trait.Visitor.html#method.visit_local -[`BorrowData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/borrow_set/struct.BorrowData.html +[`BorrowData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/borrow_set/struct.BorrowData.html ## Checking two-phase borrows @@ -95,6 +95,6 @@ following exceptions: by using the [`Dominators`] for the MIR graph. 4. After the activation point, the two-phase borrow acts as a mutable borrow. -[check]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/struct.MirBorrowckCtxt.html#method.check_activations +[check]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/struct.MirBorrowckCtxt.html#method.check_activations [`Dominators`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/graph/dominators/struct.Dominators.html -[`is_active`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/path_utils/fn.is_active.html +[`is_active`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/path_utils/fn.is_active.html From 67faab2aa2cde94855db51f698d8c328fcb04c8e Mon Sep 17 00:00:00 2001 From: Eric Holk Date: Thu, 7 Oct 2021 10:23:23 -0700 Subject: [PATCH 1553/1812] Fix accidental HTML tag The markdown parser was interpreting the `` in `adjust_upvar_borrow_kind_for_` as an HTML tag that was hidden in the rendered text. This minor edit fixes that. --- src/closure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/closure.md b/src/closure.md index 1d7f4bccd..20dccc8ab 100644 --- a/src/closure.md +++ b/src/closure.md @@ -199,7 +199,7 @@ Mutability and Type and is defined in comments, "`cmt` is a complete categorization of a value indicating where it originated and how it is located, as well as the mutability of the memory in which the value is stored". Based on the callback (consume, borrow etc.), we -will call the relevant *adjust_upvar_borrow_kind_for_* and pass the +will call the relevant *adjust_upvar_borrow_kind_for_\* and pass the `cmt` along. Once the borrow type is adjusted, we store it in the table, which basically says what borrows were made for each closure. From 0cff8fbeeca493347f1883d9134ea28a0cba0658 Mon Sep 17 00:00:00 2001 From: Eric Holk Date: Thu, 7 Oct 2021 15:13:58 -0700 Subject: [PATCH 1554/1812] Update src/closure.md Co-authored-by: Joshua Nelson --- src/closure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/closure.md b/src/closure.md index 20dccc8ab..a38e93241 100644 --- a/src/closure.md +++ b/src/closure.md @@ -199,7 +199,7 @@ Mutability and Type and is defined in comments, "`cmt` is a complete categorization of a value indicating where it originated and how it is located, as well as the mutability of the memory in which the value is stored". Based on the callback (consume, borrow etc.), we -will call the relevant *adjust_upvar_borrow_kind_for_\* and pass the +will call the relevant `adjust_upvar_borrow_kind_for_` and pass the `cmt` along. Once the borrow type is adjusted, we store it in the table, which basically says what borrows were made for each closure. From 013c8892dde5fa713d8d6feee93efbcb85868f75 Mon Sep 17 00:00:00 2001 From: Oli Scherer Date: Tue, 5 Oct 2021 09:57:35 +0000 Subject: [PATCH 1555/1812] Move log/tracing instructions to its own file --- src/SUMMARY.md | 1 + src/compiler-debugging.md | 135 +------------------------------------- src/getting-started.md | 4 +- src/tracing.md | 133 +++++++++++++++++++++++++++++++++++++ 4 files changed, 137 insertions(+), 136 deletions(-) create mode 100644 src/tracing.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 5e59cf651..b7b6d8bd1 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -20,6 +20,7 @@ - [Adding new tests](./tests/adding.md) - [Using `compiletest` commands to control test execution](./compiletest.md) - [Debugging the Compiler](./compiler-debugging.md) + - [Using the tracing/logging instrumentation](./tracing.md) - [Profiling the compiler](./profiling.md) - [with the linux perf tool](./profiling/with_perf.md) - [with Windows Performance Analyzer](./profiling/wpa_profiling.md) diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index 34f5e760f..8f46e896e 100644 --- a/src/compiler-debugging.md +++ b/src/compiler-debugging.md @@ -159,145 +159,12 @@ stack backtrace: Cool, now I have a backtrace for the error! ## Getting logging output -[getting-logging-output]: #getting-logging-output The compiler uses the [`tracing`] crate for logging. [`tracing`]: https://docs.rs/tracing -The compiler has a lot of [`debug!`] calls, which print out logging information -at many points. These are very useful to at least narrow down the location of -a bug if not to find it entirely, or just to orient yourself as to why the -compiler is doing a particular thing. - -[`debug!`]: https://docs.rs/tracing/0.1/tracing/macro.debug.html - -To see the logs, you need to set the `RUSTC_LOG` environment variable to your -log filter. Your log filter can be just `debug` to get all `debug!` output and -higher (e.g., it will also include `info!`), or `path::to::module` to get *all* -output (which will include `trace!`) from a particular module, or -`path::to::module=debug` to get `debug!` output and higher from a particular -module. - -For example, to get the `debug!` output and higher for a specific module, you -can run the compiler with `RUSTC_LOG=path::to::module=debug rustc my-file.rs`. -All `debug!` output will then appear in standard error. - -Note that you can use a partial path and the filter will still work. For -example, if you want to see `info!` output from only -`rustdoc::passes::collect_intra_doc_links`, you could use -`RUSTDOC_LOG=rustdoc::passes::collect_intra_doc_links=info` *or* you could use -`RUSTDOC_LOG=rustdoc::passes::collect_intra=info`. - -If you are developing rustdoc, use `RUSTDOC_LOG` instead. If you are developing -Miri, use `MIRI_LOG` instead. You get the idea :) - -See the [`tracing`] crate's docs, and specifically the docs for [`debug!`] to -see the full syntax you can use. (Note: unlike the compiler, the [`tracing`] -crate and its examples use the `RUST_LOG` environment variable. rustc, rustdoc, -and other tools set custom environment variables.) - -**Note that unless you use a very strict filter, the logger will emit a lot of -output, so use the most specific module(s) you can (comma-separated if -multiple)**. It's typically a good idea to pipe standard error to a file and -look at the log output with a text editor. - -So, to put it together: - -```bash -# This puts the output of all debug calls in `rustc_middle/src/traits` into -# standard error, which might fill your console backscroll. -$ RUSTC_LOG=rustc_middle::traits=debug rustc +stage1 my-file.rs - -# This puts the output of all debug calls in `rustc_middle/src/traits` in -# `traits-log`, so you can then see it with a text editor. -$ RUSTC_LOG=rustc_middle::traits=debug rustc +stage1 my-file.rs 2>traits-log - -# Not recommended! This will show the output of all `debug!` calls -# in the Rust compiler, and there are a *lot* of them, so it will be -# hard to find anything. -$ RUSTC_LOG=debug rustc +stage1 my-file.rs 2>all-log - -# This will show the output of all `info!` calls in `rustc_codegen_ssa`. -# -# There's an `info!` statement in `codegen_instance` that outputs -# every function that is codegen'd. This is useful to find out -# which function triggers an LLVM assertion, and this is an `info!` -# log rather than a `debug!` log so it will work on the official -# compilers. -$ RUSTC_LOG=rustc_codegen_ssa=info rustc +stage1 my-file.rs - -# This will show the output of all `info!` calls made by rustdoc -# or any rustc library it calls. -$ RUSTDOC_LOG=info rustdoc +stage1 my-file.rs - -# This will only show `debug!` calls made by rustdoc directly, -# not any `rustc*` crate. -$ RUSTDOC_LOG=rustdoc=debug rustdoc +stage1 my-file.rs -``` - -### Log colors - -By default, rustc (and other tools, like rustdoc and Miri) will be smart about -when to use ANSI colors in the log output. If they are outputting to a terminal, -they will use colors, and if they are outputting to a file or being piped -somewhere else, they will not. However, it's hard to read log output in your -terminal unless you have a very strict filter, so you may want to pipe the -output to a pager like `less`. But then there won't be any colors, which makes -it hard to pick out what you're looking for! - -You can override whether to have colors in log output with the `RUSTC_LOG_COLOR` -environment variable (or `RUSTDOC_LOG_COLOR` for rustdoc, or `MIRI_LOG_COLOR` -for Miri, etc.). There are three options: `auto` (the default), `always`, and -`never`. So, if you want to enable colors when piping to `less`, use something -similar to this command: - -```bash -# The `-R` switch tells less to print ANSI colors without escaping them. -$ RUSTC_LOG=debug RUSTC_LOG_COLOR=always rustc +stage1 ... | less -R -``` - -Note that `MIRI_LOG_COLOR` will only color logs that come from Miri, not logs -from rustc functions that Miri calls. Use `RUSTC_LOG_COLOR` to color logs from -rustc. - -### How to keep or remove `debug!` and `trace!` calls from the resulting binary - -While calls to `error!`, `warn!` and `info!` are included in every build of the compiler, -calls to `debug!` and `trace!` are only included in the program if -`debug-logging=true` is turned on in config.toml (it is -turned off by default), so if you don't see `DEBUG` logs, especially -if you run the compiler with `RUSTC_LOG=rustc rustc some.rs` and only see -`INFO` logs, make sure that `debug-logging=true` is turned on in your -config.toml. - -### Logging etiquette and conventions - -Because calls to `debug!` are removed by default, in most cases, don't worry -about adding "unnecessary" calls to `debug!` and leaving them in code you -commit - they won't slow down the performance of what we ship, and if they -helped you pinning down a bug, they will probably help someone else with a -different one. - -A loosely followed convention is to use `debug!("foo(...)")` at the _start_ of -a function `foo` and `debug!("foo: ...")` _within_ the function. Another -loosely followed convention is to use the `{:?}` format specifier for debug -logs. - -One thing to be **careful** of is **expensive** operations in logs. - -If in the module `rustc::foo` you have a statement - -```Rust -debug!("{:?}", random_operation(tcx)); -``` - -Then if someone runs a debug `rustc` with `RUSTC_LOG=rustc::bar`, then -`random_operation()` will run. - -This means that you should not put anything too expensive or likely to crash -there - that would annoy anyone who wants to use logging for their own module. -No-one will know it until someone tries to use logging to find *another* bug. +For details see [the guide section on tracing](./tracing.md) ## Formatting Graphviz output (.dot files) [formatting-graphviz-output]: #formatting-graphviz-output diff --git a/src/getting-started.md b/src/getting-started.md index 14225c504..4d77b03db 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -298,10 +298,10 @@ yourself when calling `rustfmt` directly. One last thing: you can use `RUSTC_LOG=XXX` to get debug logging. [Read more here][logging]. Notice the `C` in `RUSTC_LOG`. Other than that, it uses normal -[`env_logger`][envlog] syntax. +[`env_logger`][envlog] or `tracing` syntax. [envlog]: https://crates.io/crates/env_logger -[logging]: ./compiler-debugging.html#getting-logging-output +[logging]: ./tracing.md ### Building and Testing `std`/`core`/`alloc`/`test`/`proc_macro`/etc. diff --git a/src/tracing.md b/src/tracing.md new file mode 100644 index 000000000..a676aaad0 --- /dev/null +++ b/src/tracing.md @@ -0,0 +1,133 @@ +The compiler has a lot of [`debug!`] calls, which print out logging information +at many points. These are very useful to at least narrow down the location of +a bug if not to find it entirely, or just to orient yourself as to why the +compiler is doing a particular thing. + +[`debug!`]: https://docs.rs/tracing/0.1/tracing/macro.debug.html + +To see the logs, you need to set the `RUSTC_LOG` environment variable to your +log filter. Your log filter can be just `debug` to get all `debug!` output and +higher (e.g., it will also include `info!`), or `path::to::module` to get *all* +output (which will include `trace!`) from a particular module, or +`path::to::module=debug` to get `debug!` output and higher from a particular +module. + +For example, to get the `debug!` output and higher for a specific module, you +can run the compiler with `RUSTC_LOG=path::to::module=debug rustc my-file.rs`. +All `debug!` output will then appear in standard error. + +Note that you can use a partial path and the filter will still work. For +example, if you want to see `info!` output from only +`rustdoc::passes::collect_intra_doc_links`, you could use +`RUSTDOC_LOG=rustdoc::passes::collect_intra_doc_links=info` *or* you could use +`RUSTDOC_LOG=rustdoc::passes::collect_intra=info`. + +If you are developing rustdoc, use `RUSTDOC_LOG` instead. If you are developing +Miri, use `MIRI_LOG` instead. You get the idea :) + +See the [`tracing`] crate's docs, and specifically the docs for [`debug!`] to +see the full syntax you can use. (Note: unlike the compiler, the [`tracing`] +crate and its examples use the `RUST_LOG` environment variable. rustc, rustdoc, +and other tools set custom environment variables.) + +**Note that unless you use a very strict filter, the logger will emit a lot of +output, so use the most specific module(s) you can (comma-separated if +multiple)**. It's typically a good idea to pipe standard error to a file and +look at the log output with a text editor. + +So, to put it together: + +```bash +# This puts the output of all debug calls in `rustc_middle/src/traits` into +# standard error, which might fill your console backscroll. +$ RUSTC_LOG=rustc_middle::traits=debug rustc +stage1 my-file.rs + +# This puts the output of all debug calls in `rustc_middle/src/traits` in +# `traits-log`, so you can then see it with a text editor. +$ RUSTC_LOG=rustc_middle::traits=debug rustc +stage1 my-file.rs 2>traits-log + +# Not recommended! This will show the output of all `debug!` calls +# in the Rust compiler, and there are a *lot* of them, so it will be +# hard to find anything. +$ RUSTC_LOG=debug rustc +stage1 my-file.rs 2>all-log + +# This will show the output of all `info!` calls in `rustc_codegen_ssa`. +# +# There's an `info!` statement in `codegen_instance` that outputs +# every function that is codegen'd. This is useful to find out +# which function triggers an LLVM assertion, and this is an `info!` +# log rather than a `debug!` log so it will work on the official +# compilers. +$ RUSTC_LOG=rustc_codegen_ssa=info rustc +stage1 my-file.rs + +# This will show the output of all `info!` calls made by rustdoc +# or any rustc library it calls. +$ RUSTDOC_LOG=info rustdoc +stage1 my-file.rs + +# This will only show `debug!` calls made by rustdoc directly, +# not any `rustc*` crate. +$ RUSTDOC_LOG=rustdoc=debug rustdoc +stage1 my-file.rs +``` + +### Log colors + +By default, rustc (and other tools, like rustdoc and Miri) will be smart about +when to use ANSI colors in the log output. If they are outputting to a terminal, +they will use colors, and if they are outputting to a file or being piped +somewhere else, they will not. However, it's hard to read log output in your +terminal unless you have a very strict filter, so you may want to pipe the +output to a pager like `less`. But then there won't be any colors, which makes +it hard to pick out what you're looking for! + +You can override whether to have colors in log output with the `RUSTC_LOG_COLOR` +environment variable (or `RUSTDOC_LOG_COLOR` for rustdoc, or `MIRI_LOG_COLOR` +for Miri, etc.). There are three options: `auto` (the default), `always`, and +`never`. So, if you want to enable colors when piping to `less`, use something +similar to this command: + +```bash +# The `-R` switch tells less to print ANSI colors without escaping them. +$ RUSTC_LOG=debug RUSTC_LOG_COLOR=always rustc +stage1 ... | less -R +``` + +Note that `MIRI_LOG_COLOR` will only color logs that come from Miri, not logs +from rustc functions that Miri calls. Use `RUSTC_LOG_COLOR` to color logs from +rustc. + +### How to keep or remove `debug!` and `trace!` calls from the resulting binary + +While calls to `error!`, `warn!` and `info!` are included in every build of the compiler, +calls to `debug!` and `trace!` are only included in the program if +`debug-logging=true` is turned on in config.toml (it is +turned off by default), so if you don't see `DEBUG` logs, especially +if you run the compiler with `RUSTC_LOG=rustc rustc some.rs` and only see +`INFO` logs, make sure that `debug-logging=true` is turned on in your +config.toml. + +### Logging etiquette and conventions + +Because calls to `debug!` are removed by default, in most cases, don't worry +about adding "unnecessary" calls to `debug!` and leaving them in code you +commit - they won't slow down the performance of what we ship, and if they +helped you pinning down a bug, they will probably help someone else with a +different one. + +A loosely followed convention is to use `debug!("foo(...)")` at the _start_ of +a function `foo` and `debug!("foo: ...")` _within_ the function. Another +loosely followed convention is to use the `{:?}` format specifier for debug +logs. + +One thing to be **careful** of is **expensive** operations in logs. + +If in the module `rustc::foo` you have a statement + +```Rust +debug!("{:?}", random_operation(tcx)); +``` + +Then if someone runs a debug `rustc` with `RUSTC_LOG=rustc::bar`, then +`random_operation()` will run. + +This means that you should not put anything too expensive or likely to crash +there - that would annoy anyone who wants to use logging for their own module. +No-one will know it until someone tries to use logging to find *another* bug. \ No newline at end of file From dc16b5293beb80ac845bc2672a97298e1233d7fb Mon Sep 17 00:00:00 2001 From: Oli Scherer Date: Tue, 5 Oct 2021 09:59:34 +0000 Subject: [PATCH 1556/1812] Document tracing awesomeness --- src/tracing.md | 83 +++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 72 insertions(+), 11 deletions(-) diff --git a/src/tracing.md b/src/tracing.md index a676aaad0..88c288685 100644 --- a/src/tracing.md +++ b/src/tracing.md @@ -1,4 +1,8 @@ -The compiler has a lot of [`debug!`] calls, which print out logging information +# Using tracing to debug the compiler + + + +The compiler has a lot of [`debug!`] (or `trace!`) calls, which print out logging information at many points. These are very useful to at least narrow down the location of a bug if not to find it entirely, or just to orient yourself as to why the compiler is doing a particular thing. @@ -6,7 +10,62 @@ compiler is doing a particular thing. [`debug!`]: https://docs.rs/tracing/0.1/tracing/macro.debug.html To see the logs, you need to set the `RUSTC_LOG` environment variable to your -log filter. Your log filter can be just `debug` to get all `debug!` output and +log filter. + +## Function level filters + +Lots of functions in rustc are annotated with + +``` +#[instrument(level = "debug", skip(self))] +fn foo(&self, bar: Type) {} +``` + +which allows you to use + +``` +RUSTC_LOG=[foo] +``` + +to do the following all at once + +* log all function calls to `foo` +* log the arguments (except for those in the `skip` list) +* log everything (from anywhere else in the compiler) until the function returns + +### I don't want everything + +Depending on the scope of the function, you may not want to log everything in its body. +As an example: the `do_mir_borrowck` function will dump hundreds of lines even for trivial +code being borrowchecked. + +Since you can combine all filters, you can add a crate/module path, e.g. + +``` +RUSTC_LOG=rustc_borrowck[do_mir_borrowck] +``` + +### I don't want all calls + +If you are compiling libcore, you likely don't want *all* borrowck dumps, but only one +for a specific function. You can filter function calls by their arguments by regexing them. + +``` +RUSTC_LOG=[do_mir_borrowck{id=\.\*from_utf8_unchecked\.\*}] +``` + +will only give you the logs of borrowchecking `from_utf8_unchecked`. Note that you will +still get a short message per ignored `do_mir_borrowck`, but none of the things inside those +calls. This helps you in looking through the calls that are happening and helps you adjust +your regex if you mistyped it. + +## Broad module level filters + +You can also use filters similar to the `log` crate's filters, which will enable +everything within a specific module. This is often too verbose and too unstructured, +so it is recommended to use function level filters. + +Your log filter can be just `debug` to get all `debug!` output and higher (e.g., it will also include `info!`), or `path::to::module` to get *all* output (which will include `trace!`) from a particular module, or `path::to::module=debug` to get `debug!` output and higher from a particular @@ -69,7 +128,7 @@ $ RUSTDOC_LOG=info rustdoc +stage1 my-file.rs $ RUSTDOC_LOG=rustdoc=debug rustdoc +stage1 my-file.rs ``` -### Log colors +## Log colors By default, rustc (and other tools, like rustdoc and Miri) will be smart about when to use ANSI colors in the log output. If they are outputting to a terminal, @@ -94,7 +153,7 @@ Note that `MIRI_LOG_COLOR` will only color logs that come from Miri, not logs from rustc functions that Miri calls. Use `RUSTC_LOG_COLOR` to color logs from rustc. -### How to keep or remove `debug!` and `trace!` calls from the resulting binary +## How to keep or remove `debug!` and `trace!` calls from the resulting binary While calls to `error!`, `warn!` and `info!` are included in every build of the compiler, calls to `debug!` and `trace!` are only included in the program if @@ -104,7 +163,7 @@ if you run the compiler with `RUSTC_LOG=rustc rustc some.rs` and only see `INFO` logs, make sure that `debug-logging=true` is turned on in your config.toml. -### Logging etiquette and conventions +## Logging etiquette and conventions Because calls to `debug!` are removed by default, in most cases, don't worry about adding "unnecessary" calls to `debug!` and leaving them in code you @@ -112,17 +171,19 @@ commit - they won't slow down the performance of what we ship, and if they helped you pinning down a bug, they will probably help someone else with a different one. -A loosely followed convention is to use `debug!("foo(...)")` at the _start_ of -a function `foo` and `debug!("foo: ...")` _within_ the function. Another -loosely followed convention is to use the `{:?}` format specifier for debug -logs. +It may be preferrable to use `trace!` over `debug!` for very noisy logs. + +A loosely followed convention is to use `#[instrument(level = "debug")]` in +favour of `debug!("foo(...)")` at the start of a function `foo`. +Within functions, prefer `debug!(?variable.field)` over `debug!("xyz = {:?}", variable.field)` +and `debug!(bar = ?var.method(arg))` over `debug!("bar = {:?}", var.method(arg))`. One thing to be **careful** of is **expensive** operations in logs. If in the module `rustc::foo` you have a statement ```Rust -debug!("{:?}", random_operation(tcx)); +debug!(x = ?random_operation(tcx)); ``` Then if someone runs a debug `rustc` with `RUSTC_LOG=rustc::bar`, then @@ -130,4 +191,4 @@ Then if someone runs a debug `rustc` with `RUSTC_LOG=rustc::bar`, then This means that you should not put anything too expensive or likely to crash there - that would annoy anyone who wants to use logging for their own module. -No-one will know it until someone tries to use logging to find *another* bug. \ No newline at end of file +No-one will know it until someone tries to use logging to find *another* bug. From 72906c9bed33d7e45f10f065c87e1eb39b69922c Mon Sep 17 00:00:00 2001 From: Oli Scherer Date: Tue, 5 Oct 2021 10:15:26 +0000 Subject: [PATCH 1557/1812] Address review comments --- src/tracing.md | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/src/tracing.md b/src/tracing.md index 88c288685..422d94c53 100644 --- a/src/tracing.md +++ b/src/tracing.md @@ -10,7 +10,8 @@ compiler is doing a particular thing. [`debug!`]: https://docs.rs/tracing/0.1/tracing/macro.debug.html To see the logs, you need to set the `RUSTC_LOG` environment variable to your -log filter. +log filter. The full syntax of the log filters can be found in the [rustdoc +of `tracing-subscriber`](https://docs.rs/tracing-subscriber/0.2.24/tracing_subscriber/filter/struct.EnvFilter.html#directives). ## Function level filters @@ -166,17 +167,23 @@ config.toml. ## Logging etiquette and conventions Because calls to `debug!` are removed by default, in most cases, don't worry -about adding "unnecessary" calls to `debug!` and leaving them in code you -commit - they won't slow down the performance of what we ship, and if they -helped you pinning down a bug, they will probably help someone else with a -different one. +about the performance of adding "unnecessary" calls to `debug!` and leaving them in code you +commit - they won't slow down the performance of what we ship. + +That said, there can also be excessive tracing calls, especially +when they are redundant with other calls nearby or in functions called from +here. There is no perfect balance to hit here, and is left to the reviewer's +discretion to decide whether to let you leave `debug!` statements in or whether to ask +you to remove them before merging. It may be preferrable to use `trace!` over `debug!` for very noisy logs. -A loosely followed convention is to use `#[instrument(level = "debug")]` in -favour of `debug!("foo(...)")` at the start of a function `foo`. +A loosely followed convention is to use `#[instrument(level = "debug")]` +([also see the attribute's documentation](https://docs.rs/tracing-attributes/0.1.17/tracing_attributes/attr.instrument.html)) +in favour of `debug!("foo(...)")` at the start of a function `foo`. Within functions, prefer `debug!(?variable.field)` over `debug!("xyz = {:?}", variable.field)` and `debug!(bar = ?var.method(arg))` over `debug!("bar = {:?}", var.method(arg))`. +The documentation for this syntax can be found [here](https://docs.rs/tracing/0.1.28/tracing/#recording-fields). One thing to be **careful** of is **expensive** operations in logs. @@ -186,9 +193,12 @@ If in the module `rustc::foo` you have a statement debug!(x = ?random_operation(tcx)); ``` -Then if someone runs a debug `rustc` with `RUSTC_LOG=rustc::bar`, then -`random_operation()` will run. +Then if someone runs a debug `rustc` with `RUSTC_LOG=rustc::foo`, then +`random_operation()` will run. `RUSTC_LOG` filters that do not enable this +debug statement will not execute `random_operation`. This means that you should not put anything too expensive or likely to crash -there - that would annoy anyone who wants to use logging for their own module. +there - that would annoy anyone who wants to use logging for that module. No-one will know it until someone tries to use logging to find *another* bug. + +[`tracing`]: https://docs.rs/tracing \ No newline at end of file From cec5879a864169d5aa29072c7351d1b98c68c51b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomasz=20Mi=C4=85sko?= Date: Sun, 19 Sep 2021 00:00:00 +0000 Subject: [PATCH 1558/1812] Mention needs-sanitizer-hwaddress directive --- src/tests/adding.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index d9b063d5c..d1b19516f 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -208,9 +208,10 @@ source. `profiler = true` in rustc's `config.toml`. * `needs-sanitizer-support` - a sanitizer runtime is required, i.e., `sanitizers = true` in rustc's `config.toml`. -* `needs-sanitizer-{address,leak,memory,thread}` - indicates that test - requires a target with a support for AddressSanitizer, LeakSanitizer, - MemorySanitizer or ThreadSanitizer respectively. +* `needs-sanitizer-{address,hwaddress,leak,memory,thread}` - indicates that + test requires a target with a support for AddressSanitizer, hardware-assisted + AddressSanitizer, LeakSanitizer, MemorySanitizer or ThreadSanitizer + respectively. * `error-pattern` checks the diagnostics just like the `ERROR` annotation without specifying error line. This is useful when the error doesn't give any span. From afbcc3efa9648a79c546de76b686911cd1e01c93 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomasz=20Mi=C4=85sko?= Date: Mon, 27 Sep 2021 00:00:00 +0000 Subject: [PATCH 1559/1812] Update sanitizer documentation --- src/sanitizers.md | 72 +++++++++++++++++++++++++++++++++++++---------- 1 file changed, 57 insertions(+), 15 deletions(-) diff --git a/src/sanitizers.md b/src/sanitizers.md index ce0714034..49183d6d5 100644 --- a/src/sanitizers.md +++ b/src/sanitizers.md @@ -5,6 +5,8 @@ The rustc compiler contains support for following sanitizers: * [AddressSanitizer][clang-asan] a faster memory error detector. Can detect out-of-bounds access to heap, stack, and globals, use after free, use after return, double free, invalid free, memory leaks. +* [Hardware-assisted AddressSanitizer][clang-hwasan] a tool similar to + AddressSanitizer but based on partial hardware assistance. * [LeakSanitizer][clang-lsan] a run-time memory leak detector. * [MemorySanitizer][clang-msan] a detector of uninitialized reads. * [ThreadSanitizer][clang-tsan] a fast data race detector. @@ -12,8 +14,9 @@ The rustc compiler contains support for following sanitizers: ## How to use the sanitizers? To enable a sanitizer compile with `-Z sanitizer=...` option, where value is one -of `address`, `leak`, `memory` or `thread`. For more details how to use -sanitizers please refer to [the unstable book](https://doc.rust-lang.org/unstable-book/). +of `address`, `hwaddress`, `leak`, `memory` or `thread`. For more details on how +to use sanitizers please refer to the sanitizer flag in [the unstable +book](https://doc.rust-lang.org/unstable-book/). ## How are sanitizers implemented in rustc? @@ -22,7 +25,8 @@ an integration point for LLVM compile time instrumentation passes and runtime libraries. Highlight of the most important aspects of the implementation: * The sanitizer runtime libraries are part of the [compiler-rt] project, and - [will be built on supported targets][sanitizer-build] when enabled in `config.toml`: + [will be built][sanitizer-build] on [supported targets][sanitizer-targets] + when enabled in `config.toml`: ```toml [build] @@ -33,9 +37,9 @@ libraries. Highlight of the most important aspects of the implementation: * During LLVM code generation, the functions intended for instrumentation are [marked][sanitizer-attribute] with appropriate LLVM attribute: - `SanitizeAddress`, `SanitizeMemory`, or `SanitizeThread`. By default all - functions are instrumented, but this behaviour can be changed with - `#[no_sanitize(...)]`. + `SanitizeAddress`, `SanitizeHWAddress`, `SanitizeMemory`, or + `SanitizeThread`. By default all functions are instrumented, but this + behaviour can be changed with `#[no_sanitize(...)]`. * The decision whether to perform instrumentation or not is possible only at a function granularity. In the cases were those decision differ between @@ -47,28 +51,66 @@ libraries. Highlight of the most important aspects of the implementation: passes are invoked after optimization passes. * When producing an executable, the sanitizer specific runtime library is - [linked in][sanitizer-link]. The libraries are searched for in target libdir - relative to default system root, so that this process is not affected - by sysroot overrides used for example by cargo `-Z build-std` functionality. + [linked in][sanitizer-link]. The libraries are searched for in the target + libdir. First relative to the overridden system root and subsequently + relative to the default system root. Fall-back to the default system root + ensures that sanitizer runtimes remain available when using sysroot overrides + constructed by cargo `-Z build-std` or xargo. [compiler-rt]: https://github.com/llvm/llvm-project/tree/main/compiler-rt -[sanitizer-build]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/bootstrap/native.rs#L566-L624 -[sanitizer-copy]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/bootstrap/compile.rs#L270-L304 -[sanitizer-attribute]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/librustc_codegen_llvm/attributes.rs#L49-L72 -[inline-mir]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/librustc_mir/transform/inline.rs#L232-L252 +[sanitizer-build]: https://github.com/rust-lang/rust/blob/1.55.0/src/bootstrap/native.rs#L700-L765 +[sanitizer-targets]: https://github.com/rust-lang/rust/blob/1.55.0/src/bootstrap/native.rs#L806-L820 +[sanitizer-copy]: https://github.com/rust-lang/rust/blob/1.55.0/src/bootstrap/compile.rs#L376-L407 +[sanitizer-attribute]: https://github.com/rust-lang/rust/blob/1.55.0/compiler/rustc_codegen_llvm/src/attributes.rs#L42-L58 +[inline-mir]: https://github.com/rust-lang/rust/blob/1.55.0/compiler/rustc_mir/src/transform/inline.rs#L314-L316 [inline-llvm]: https://github.com/rust-lang/llvm-project/blob/9330ec5a4c1df5fc1fa62f993ed6a04da68cb040/llvm/include/llvm/IR/Attributes.td#L225-L241 -[sanitizer-pass]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/librustc_codegen_llvm/back/write.rs#L454-L475 -[sanitizer-link]: https://github.com/rust-lang/rust/blob/a29424a2265411dda7d7446516ac5fd7499e2b55/src/librustc_codegen_ssa/back/link.rs#L748-L787 +[sanitizer-pass]: https://github.com/rust-lang/rust/blob/1.55.0/compiler/rustc_codegen_llvm/src/back/write.rs#L660-L678 +[sanitizer-link]: https://github.com/rust-lang/rust/blob/1.55.0/compiler/rustc_codegen_ssa/src/back/link.rs#L1053-L1089 + +## Testing sanitizers + +Sanitizers are validated by code generation tests in +[`src/test/codegen/sanitize*.rs`][test-cg] and end-to-end functional tests in +[`src/test/ui/sanitize/`][test-ui] directory. + +Testing sanitizer functionality requires the sanitizer runtimes (built when +`sanitizer = true` in `config.toml`) and target providing support for particular +sanitizer. When sanitizer is unsupported on given target, sanitizers tests will +be ignored. This behaviour is controlled by compiletest `needs-sanitizer-*` +directives. + +[test-cg]: https://github.com/rust-lang/rust/tree/master/src/test/codegen +[test-ui]: https://github.com/rust-lang/rust/tree/master/src/test/ui/sanitize + +## Enabling sanitizer on a new target + +To enable a sanitizer on a new target which is already supported by LLVM: + +1. Include the sanitizer in the list of `supported_sanitizers` in [the target + definition][target-definition]. `rustc --target .. -Zsanitizer=..` should now + recognize sanitizer as supported. +2. [Build the runtime for the target and include it in the libdir.][sanitizer-targets] +3. [Teach compiletest that your target now supports the sanitizer.][compiletest-definition] + Tests marked with `needs-sanitizer-*` should now run on the target. +4. Run tests `./x.py test --force-rerun src/test/ui/sanitize/` to verify. +5. [--enable-sanitizers in the CI configuration][ci-configuration] to build and + distribute the sanitizer runtime as part of the release process. + +[target-definition]: https://github.com/rust-lang/rust/blob/1.55.0/compiler/rustc_target/src/spec/x86_64_unknown_linux_gnu.rs#L10-L11 +[compiletest-definition]: https://github.com/rust-lang/rust/blob/1.55.0/src/tools/compiletest/src/util.rs#L87-L116 +[ci-configuration]: https://github.com/rust-lang/rust/blob/1.55.0/src/ci/docker/host-x86_64/dist-x86_64-linux/Dockerfile#L94 ## Additional Information * [Sanitizers project page](https://github.com/google/sanitizers/wiki/) * [AddressSanitizer in Clang][clang-asan] +* [Hardware-assisted AddressSanitizer][clang-hwasan] * [LeakSanitizer in Clang][clang-lsan] * [MemorySanitizer in Clang][clang-msan] * [ThreadSanitizer in Clang][clang-tsan] [clang-asan]: https://clang.llvm.org/docs/AddressSanitizer.html +[clang-hwasan]: https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html [clang-lsan]: https://clang.llvm.org/docs/LeakSanitizer.html [clang-msan]: https://clang.llvm.org/docs/MemorySanitizer.html [clang-tsan]: https://clang.llvm.org/docs/ThreadSanitizer.html From ceec906a313d3e4ece33bc7e5a0b32de2de43c7d Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sun, 19 Sep 2021 11:19:51 -0700 Subject: [PATCH 1560/1812] Recommend `rustfmt --edition=2021` --- src/building/suggested.md | 2 +- src/getting-started.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index f1665efdc..24e25f5d0 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -33,7 +33,7 @@ you can write: `--edition=2018` argument +You'll have to pass the `--edition=2021` argument yourself when calling `rustfmt` directly. One last thing: you can use `RUSTC_LOG=XXX` to get debug logging. [Read more From fba15a46ca8efa97e8a955794724ac7ce27805b8 Mon Sep 17 00:00:00 2001 From: Yusuke Abe Date: Tue, 12 Oct 2021 08:52:21 +0900 Subject: [PATCH 1561/1812] Update some docs from 2021-10 date triage (#1230) --- src/backend/updating-llvm.md | 2 +- src/borrow_check/region_inference/member_constraints.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md index 9deff62dd..1a6fa033a 100644 --- a/src/backend/updating-llvm.md +++ b/src/backend/updating-llvm.md @@ -67,7 +67,7 @@ Example PRs look like: ## Feature updates > Note that this information is as of the time of this writing (April 2021). The process for updating LLVM changes with +2021-10 --> (October 2021). The process for updating LLVM changes with practically all LLVM updates, so this may be out of date! Unlike bugfixes, updating to pick up a new feature of LLVM typically requires a diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md index dfc4327e5..c7c107e1e 100644 --- a/src/borrow_check/region_inference/member_constraints.md +++ b/src/borrow_check/region_inference/member_constraints.md @@ -94,7 +94,7 @@ member constraints come in. ## Choices are always lifetime parameters At present, the "choice" regions from a member constraint are always lifetime -parameters from the current function. As of January 2021, +parameters from the current function. As of October 2021, this falls out from the placement of impl Trait, though in the future it may not be the case. We take some advantage of this fact, as it simplifies the current code. In particular, we don't have to consider a case like `'0 member of ['1, From 4ff071741ab35a38ad464cc2c0e1a92c66aadae8 Mon Sep 17 00:00:00 2001 From: Joshua Nelson Date: Sun, 17 Oct 2021 13:17:19 -0400 Subject: [PATCH 1562/1812] Remove docs on Assemble step (#1233) --- src/building/bootstrapping.md | 23 ++++------------------- 1 file changed, 4 insertions(+), 19 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 876c565ab..26527ec9c 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -149,20 +149,6 @@ Build artifacts include, but are not limited to: [rlib]: ../serialization.md -#### Assembling the compiler - -There is a separate step between building the compiler and making it possible -to run. This step is called _assembling_ or _uplifting_ the compiler. It copies -all the necessary build artifacts from `build/stageN-sysroot` to -`build/stage(N+1)`, which allows you to use `build/stage(N+1)` as a [toolchain] -with `rustup toolchain link`. - -There is [no way to trigger this step on its own][#73519], but `x.py` will -perform it automatically any time you build with stage N+1. - -[toolchain]: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#creating-a-rustup-toolchain -[#73519]: https://github.com/rust-lang/rust/issues/73519 - #### Examples - `x.py build --stage 0` means to build with the beta `rustc`. @@ -183,11 +169,10 @@ perform it automatically any time you build with stage N+1. - `x.py test --stage 0 compiler/rustc` builds the compiler but runs no tests: it's running `cargo test -p rustc`, but cargo doesn't understand Rust's tests. You shouldn't need to use this, use `test` instead (without arguments). -- `x.py build --stage 0 compiler/rustc` builds the compiler, but does - not [assemble] it. Use `x.py build library/std` instead, which puts the - compiler in `stage1/rustc`. - -[assemble]: #assembling-the-compiler +- `x.py build --stage 0 compiler/rustc` builds the compiler, but does not build + libstd or even libcore. Most of the time, you'll want `x.py build + library/std` instead, which allows compiling programs without needing to define + lang items. ### Building vs. Running From 87968b466f48d44ebbaf6cc31fcf753cf160e8a6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9my=20Rakic?= Date: Thu, 21 Oct 2021 18:00:27 +0200 Subject: [PATCH 1563/1812] Describe how to trigger perf runs (#1237) --- src/profiling.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/profiling.md b/src/profiling.md index ca0fee6d5..4851e3ee9 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -5,7 +5,10 @@ This section talks about how to profile the compiler and find out where it spend Depending on what you're trying to measure, there are several different approaches: - If you want to see if a PR improves or regresses compiler performance: - - The [rustc-perf](https://github.com/rust-lang/rustc-perf) project makes this easy and can be triggered to run on a PR via the `@rustc-perf` bot. + - The [rustc-perf](https://github.com/rust-lang/rustc-perf) project makes this easy and can be triggered to run on a PR via the `@rust-timer` bot. + The `@bors try @rust-timer queue` command, in a comment on the PR, will queue a try build and a + benchmarking run. + Note: you need `try` privileges to be able to do this. More details are available in the [perf collector documentation](https://github.com/rust-lang/rustc-perf/blob/master/collector/README.md). - If you want a medium-to-high level overview of where `rustc` is spending its time: - The `-Z self-profile` flag and [measureme](https://github.com/rust-lang/measureme) tools offer a query-based approach to profiling. From f68aff5d181f7b721119a13210950940b21ce12d Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 21 Oct 2021 12:52:19 -0700 Subject: [PATCH 1564/1812] Switch date-check to Rust 2021 No migrations were necessary. --- ci/date-check/Cargo.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/date-check/Cargo.toml b/ci/date-check/Cargo.toml index 95251fb12..884f485fa 100644 --- a/ci/date-check/Cargo.toml +++ b/ci/date-check/Cargo.toml @@ -2,7 +2,7 @@ name = "date-check" version = "0.1.0" authors = ["Camelid "] -edition = "2018" +edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html From b06008731af0f7d07cd0614e820c8276dfed1c18 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 21 Oct 2021 12:53:03 -0700 Subject: [PATCH 1565/1812] Update author field --- ci/date-check/Cargo.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ci/date-check/Cargo.toml b/ci/date-check/Cargo.toml index 884f485fa..472529511 100644 --- a/ci/date-check/Cargo.toml +++ b/ci/date-check/Cargo.toml @@ -1,7 +1,7 @@ [package] name = "date-check" version = "0.1.0" -authors = ["Camelid "] +authors = ["Noah Lev "] edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html From 68dbb4501dcd3a86e7495b406b9ddf7905ddbe61 Mon Sep 17 00:00:00 2001 From: Ramon de C Valle Date: Thu, 14 Oct 2021 15:52:44 -0700 Subject: [PATCH 1566/1812] Add documentation for LLVM CFI support This commit adds initial documentation for LLVM Control Flow Integrity (CFI) support to the Rust compiler (see rust-lang/rust#89652 and rust-lang/rust#89653). --- src/sanitizers.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/src/sanitizers.md b/src/sanitizers.md index 49183d6d5..a088d62ed 100644 --- a/src/sanitizers.md +++ b/src/sanitizers.md @@ -5,6 +5,8 @@ The rustc compiler contains support for following sanitizers: * [AddressSanitizer][clang-asan] a faster memory error detector. Can detect out-of-bounds access to heap, stack, and globals, use after free, use after return, double free, invalid free, memory leaks. +* [ControlFlowIntegrity][clang-cfi] LLVM Control Flow Integrity (CFI) provides + forward-edge control flow protection. * [Hardware-assisted AddressSanitizer][clang-hwasan] a tool similar to AddressSanitizer but based on partial hardware assistance. * [LeakSanitizer][clang-lsan] a run-time memory leak detector. @@ -14,15 +16,16 @@ The rustc compiler contains support for following sanitizers: ## How to use the sanitizers? To enable a sanitizer compile with `-Z sanitizer=...` option, where value is one -of `address`, `hwaddress`, `leak`, `memory` or `thread`. For more details on how -to use sanitizers please refer to the sanitizer flag in [the unstable +of `address`, `cfi`, `hwaddress`, `leak`, `memory` or `thread`. For more details +on how to use sanitizers please refer to the sanitizer flag in [the unstable book](https://doc.rust-lang.org/unstable-book/). ## How are sanitizers implemented in rustc? -The implementation of sanitizers relies almost entirely on LLVM. The rustc is -an integration point for LLVM compile time instrumentation passes and runtime -libraries. Highlight of the most important aspects of the implementation: +The implementation of sanitizers (except CFI) relies almost entirely on LLVM. +The rustc is an integration point for LLVM compile time instrumentation passes +and runtime libraries. Highlight of the most important aspects of the +implementation: * The sanitizer runtime libraries are part of the [compiler-rt] project, and [will be built][sanitizer-build] on [supported targets][sanitizer-targets] @@ -104,12 +107,14 @@ To enable a sanitizer on a new target which is already supported by LLVM: * [Sanitizers project page](https://github.com/google/sanitizers/wiki/) * [AddressSanitizer in Clang][clang-asan] +* [ControlFlowIntegrity in Clang][clang-cfi] * [Hardware-assisted AddressSanitizer][clang-hwasan] * [LeakSanitizer in Clang][clang-lsan] * [MemorySanitizer in Clang][clang-msan] * [ThreadSanitizer in Clang][clang-tsan] [clang-asan]: https://clang.llvm.org/docs/AddressSanitizer.html +[clang-cfi]: https://clang.llvm.org/docs/ControlFlowIntegrity.html [clang-hwasan]: https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html [clang-lsan]: https://clang.llvm.org/docs/LeakSanitizer.html [clang-msan]: https://clang.llvm.org/docs/MemorySanitizer.html From ddaebd85aaa3d73b47b50b701fb2819377b47242 Mon Sep 17 00:00:00 2001 From: Janggun Lee Date: Fri, 29 Oct 2021 00:58:26 +0900 Subject: [PATCH 1567/1812] Fix `rustc_mir` related links (#1228) Co-authored-by: Yuki Okushi Co-authored-by: nhamovitz <18648574+nhamovitz@users.noreply.github.com> --- src/backend/implicit-caller-location.md | 12 +++--- src/backend/monomorph.md | 10 ++--- src/borrow_check.md | 8 ++-- .../moves_and_initialization/move_paths.md | 28 ++++++------- .../constraint_propagation.md | 16 ++++---- .../region_inference/lifetime_parameters.md | 12 +++--- src/borrow_check/type_check.md | 2 +- src/const-eval.md | 4 +- src/llvm-coverage-instrumentation.md | 40 +++++++++---------- src/mir/dataflow.md | 22 +++++----- src/mir/debugging.md | 2 +- src/mir/index.md | 8 +++- src/mir/optimizations.md | 21 +++++----- src/mir/passes.md | 7 ++-- src/mir/visitor.md | 3 +- src/miri.md | 14 +++---- src/overview.md | 10 ++--- src/profiling/with_perf.md | 18 ++++----- 18 files changed, 122 insertions(+), 115 deletions(-) diff --git a/src/backend/implicit-caller-location.md b/src/backend/implicit-caller-location.md index 02eea5bab..21554f5a4 100644 --- a/src/backend/implicit-caller-location.md +++ b/src/backend/implicit-caller-location.md @@ -269,13 +269,13 @@ to the author and reviewers. [attrs-flags]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/middle/codegen_fn_attrs/struct.CodegenFnAttrFlags.html#associatedconstant.TRACK_CALLER [`ReifyShim`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.InstanceDef.html#variant.ReifyShim [`Location`]: https://doc.rust-lang.org/core/panic/struct.Location.html -[const-find-closest]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#method.find_closest_untracked_caller_location +[const-find-closest]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/struct.InterpCx.html#method.find_closest_untracked_caller_location [requires-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.InstanceDef.html#method.requires_caller_location -[alloc-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#method.alloc_caller_location +[alloc-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/struct.InterpCx.html#method.alloc_caller_location [fcx-location]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#structfield.caller_location [const-location-query]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.const_caller_location -[location-memory-kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.MemoryKind.html#variant.CallerLocation -[const-frame]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Frame.html -[const-stack]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#structfield.stack +[location-memory-kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/enum.MemoryKind.html#variant.CallerLocation +[const-frame]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/struct.Frame.html +[const-stack]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/struct.InterpCx.html#structfield.stack [fcx-get]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/struct.FunctionCx.html#method.get_caller_location -[frame-instance]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Frame.html#structfield.instance +[frame-instance]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/struct.Frame.html#structfield.instance diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index 0457c1841..0dc805431 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -49,7 +49,7 @@ for them. Collector will also add things like statics to that list. See [the collector rustdocs][collect] for more info. -[collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/collector/index.html +[collect]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_monomorphize/collector/index.html The monomorphization collector is run just before MIR lowering and codegen. [`rustc_codegen_ssa::base::codegen_crate`][codegen1] calls the @@ -76,9 +76,9 @@ or more modules in Crate B. For more details about the partitioner read the module level [documentation]. -[mono]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/partitioning/fn.collect_and_partition_mono_items.html +[mono]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_monomorphize/partitioning/fn.collect_and_partition_mono_items.html [codegen1]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html -[documentation]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/partitioning/index.html +[documentation]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_monomorphize/partitioning/index.html ## Polymorphization @@ -90,7 +90,7 @@ In addition to MIR optimizations, rustc attempts to determine when fewer copies of functions are necessary and avoid making those copies - known as "polymorphization". When a function-like item is found during monomorphization collection, the -[`rustc_mir::monomorphize::polymorphize::unused_generic_params`][polymorph] +[`rustc_mir_monomorphize::polymorphize::unused_generic_params`][polymorph] query is invoked, which traverses the MIR of the item to determine on which generic parameters the item might not need duplicated. @@ -149,7 +149,7 @@ More details on polymorphization are available in the implementation. [miropt]: ../mir/optimizations.md -[polymorph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/monomorphize/polymorphize/fn.unused_generic_params.html +[polymorph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_monomorphize/polymorphize/fn.unused_generic_params.html [inst]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html [inst_polymorph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.polymorphize [thesis]: https://davidtw.co/media/masters_dissertation.pdf diff --git a/src/borrow_check.md b/src/borrow_check.md index 7e076edf3..8e2bb752a 100644 --- a/src/borrow_check.md +++ b/src/borrow_check.md @@ -27,11 +27,11 @@ HIR. Doing borrow checking on MIR has several advantages: ### Major phases of the borrow checker The borrow checker source is found in -[the `rustc_mir::borrow_check` module][b_c]. The main entry point is +[the `rustc_borrow_ck` crate][b_c]. The main entry point is the [`mir_borrowck`] query. -[b_c]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html -[`mir_borrowck`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/fn.mir_borrowck.html +[b_c]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/index.html +[`mir_borrowck`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/fn.mir_borrowck.html - We first create a **local copy** of the MIR. In the coming steps, we will modify this copy in place to modify the types and things to @@ -56,4 +56,4 @@ the [`mir_borrowck`] query. require an error to be reported. Doing this check requires the results of all the previous analyses. -[`replace_regions_in_mir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.replace_regions_in_mir.html +[`replace_regions_in_mir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/nll/fn.replace_regions_in_mir.html diff --git a/src/borrow_check/moves_and_initialization/move_paths.md b/src/borrow_check/moves_and_initialization/move_paths.md index e38b923cf..4afec42f8 100644 --- a/src/borrow_check/moves_and_initialization/move_paths.md +++ b/src/borrow_check/moves_and_initialization/move_paths.md @@ -29,7 +29,7 @@ paths roughly correspond to the concept of a [`Place`] from MIR, but they are indexed in ways that enable us to do move analysis more efficiently. -[`MovePath`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePath.html +[`MovePath`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MovePath.html [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html ## Move path indices @@ -45,9 +45,9 @@ access the [`MovePath::place`] field like so: move_data.move_paths[mpi].place ``` -[move_paths]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#structfield.move_paths -[`MovePath::place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePath.html#structfield.place -[`MovePathIndex`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathIndex.html +[move_paths]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MoveData.html#structfield.move_paths +[`MovePath::place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MovePath.html#structfield.place +[`MovePathIndex`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MovePathIndex.html ## Building move paths @@ -60,8 +60,8 @@ corresponding [`MovePathIndex`]. It also records when/where that particular move path is moved/initialized, but we'll get to that in a later section. -[`Gatherer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/builder/struct.Gatherer.html -[`MoveData::gather_moves`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#method.gather_moves +[`Gatherer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/builder/struct.Gatherer.html +[`MoveData::gather_moves`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MoveData.html#method.gather_moves ### Illegal move paths @@ -82,7 +82,7 @@ those just discussed, the function returns an `Err`. This in turn means we don't have to bother tracking whether those places are initialized (which lowers overhead). -[`move_path_for`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/builder/struct.Gatherer.html#method.move_path_for +[`move_path_for`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/builder/struct.Gatherer.html#method.move_path_for ## Looking up a move-path @@ -90,9 +90,9 @@ If you have a [`Place`] and you would like to convert it to a [`MovePathIndex`], can do that using the [`MovePathLookup`] structure found in the [`rev_lookup`] field of [`MoveData`]. There are two different methods: -[`MoveData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html -[`MovePathLookup`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html -[`rev_lookup`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#structfield.rev_lookup +[`MoveData`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MoveData.html +[`MovePathLookup`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MovePathLookup.html +[`rev_lookup`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MoveData.html#structfield.rev_lookup - [`find_local`], which takes a [`mir::Local`] representing a local variable. This is the easier method, because we **always** create a @@ -105,10 +105,10 @@ of [`MoveData`]. There are two different methods: that exists (e.g., for `foo[1]`, it might return just the path for `foo`). -[`find`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find -[`find_local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find_local +[`find`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MovePathLookup.html#method.find +[`find_local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MovePathLookup.html#method.find_local [`mir::Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Local.html -[`LookupResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/enum.LookupResult.html +[`LookupResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/enum.LookupResult.html ## Cross-references @@ -126,4 +126,4 @@ whether a move-path (e.g., `a.b`) or any child of that move-path (e.g.,`a.b.c`) matches a given predicate. [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html -[`find_in_move_path_or_its_descendants`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MoveData.html#method.find_in_move_path_or_its_descendants +[`find_in_move_path_or_its_descendants`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/move_paths/struct.MoveData.html#method.find_in_move_path_or_its_descendants diff --git a/src/borrow_check/region_inference/constraint_propagation.md b/src/borrow_check/region_inference/constraint_propagation.md index f0a7f7353..4c30d25e0 100644 --- a/src/borrow_check/region_inference/constraint_propagation.md +++ b/src/borrow_check/region_inference/constraint_propagation.md @@ -12,7 +12,7 @@ on one at a time (each of them is fairly independent from the others): - outlives constraints (`R1: R2`), which arise from subtyping; - [member constraints][m_c] (`member R_m of [R_c...]`), which arise from impl Trait. -[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints +[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints [m_c]: ./member_constraints.md In this chapter, we'll explain the "heart" of constraint propagation, @@ -70,8 +70,8 @@ though; instead, we store a (sparse) bitset per region variable (of type [`LivenessValues`]). This way we only need a single bit for each liveness constraint. -[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints -[`LivenessValues`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/values/struct.LivenessValues.html +[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints +[`LivenessValues`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/values/struct.LivenessValues.html One thing that is worth mentioning: All lifetime parameters are always considered to be live over the entire function body. This is because @@ -114,9 +114,9 @@ induces an edge `'a -> 'b`. This conversion happens in the [`RegionInferenceContext::new`] function that creates the inference context. -[`OutlivesConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/constraints/struct.OutlivesConstraintSet.html -[graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/constraints/struct.OutlivesConstraintSet.html#method.graph -[`RegionInferenceContext::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.new +[`OutlivesConstraintSet`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/constraints/struct.OutlivesConstraintSet.html +[graph-fn]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/constraints/struct.OutlivesConstraintSet.html#method.graph +[`RegionInferenceContext::new`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.new When using a graph representation, we can detect regions that must be equal by looking for cycles. That is, if you have a constraint like @@ -148,8 +148,8 @@ of fields are defined in terms of SCCs. For example, the of a specific region `'a` then, we first figure out the SCC that the region is a part of, and then find the value of that SCC. -[`constraint_sccs`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.constraint_sccs -[`scc_values`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.scc_values +[`constraint_sccs`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#structfield.constraint_sccs +[`scc_values`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#structfield.scc_values When we compute SCCs, we not only figure out which regions are a member of each SCC, we also figure out the edges between them. So for example diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index c65b8ce5a..369ce2d3d 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -31,9 +31,9 @@ relationships to one another. So if you have e.g. `where 'a: 'b`, then the [`UniversalRegionRelations`] struct would track that `'a: 'b` is known to hold (which could be tested with the [`outlives`] function. -[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/universal_regions/struct.UniversalRegions.html -[`UniversalRegionRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/type_check/free_region_relations/struct.UniversalRegionRelations.html -[`outlives`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/type_check/free_region_relations/struct.UniversalRegionRelations.html#method.outlives +[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/universal_regions/struct.UniversalRegions.html +[`UniversalRegionRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/type_check/free_region_relations/struct.UniversalRegionRelations.html +[`outlives`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/type_check/free_region_relations/struct.UniversalRegionRelations.html#method.outlives ## Everything is a region variable @@ -58,7 +58,7 @@ type). These subdivisions are not important for the topics discussed here, but become important when we consider [closure constraint propagation](./closure_constraints.html), so we discuss them there. -[`RegionClassification`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/universal_regions/enum.RegionClassification.html#variant.Local +[`RegionClassification`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/universal_regions/enum.RegionClassification.html#variant.Local ## Universal lifetimes as the elements of a region's value @@ -88,7 +88,7 @@ liveness constraint (i.e., `'a` must extend until the end of itself). In the code, these liveness constraints are setup in [`init_free_and_bound_regions`]. -[`init_free_and_bound_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.init_free_and_bound_regions +[`init_free_and_bound_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/region_infer/struct.RegionInferenceContext.html#method.init_free_and_bound_regions ## Propagating outlives constraints for universal regions @@ -124,4 +124,4 @@ not, as in our example, that is an error. This check is done in the universal regions, inspects their final value, and tests against the declared [`UniversalRegionRelations`]. -[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions +[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions diff --git a/src/borrow_check/type_check.md b/src/borrow_check/type_check.md index 0db895619..1485f2ae8 100644 --- a/src/borrow_check/type_check.md +++ b/src/borrow_check/type_check.md @@ -1,7 +1,7 @@ # The MIR type-check A key component of the borrow check is the -[MIR type-check](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/type_check/index.html). +[MIR type-check](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/type_check/index.html). This check walks the MIR and does a complete "type check" -- the same kind you might find in any other language. In the process of doing this type-check, we also uncover the region constraints that apply to diff --git a/src/const-eval.md b/src/const-eval.md index d21d0ea58..5a11f8cdd 100644 --- a/src/const-eval.md +++ b/src/const-eval.md @@ -35,11 +35,11 @@ Other constants get represented as [`ConstValue::Scalar`] or [`ConstValue::Slice`] if possible. This means that the `const_eval_*` functions cannot be used to create miri-pointers to the evaluated constant. If you need the value of a constant inside Miri, you need to directly work with -[`eval_const_to_op`]. +[`const_to_op`]. [`GlobalId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.GlobalId.html [`ConstValue::Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.Scalar [`ConstValue::Slice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.Slice [`ConstValue::ByRef`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/value/enum.ConstValue.html#variant.ByRef [`EvalToConstValueResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/error/type.EvalToConstValueResult.html -[`eval_const_to_op`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.InterpCx.html#method.eval_const_to_op +[`const_to_op`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/struct.InterpCx.html#method.const_to_op diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 7d3c0fe36..3dd565b59 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -130,7 +130,7 @@ The `InstrumentCoverage` MIR pass is documented in [more detail below][instrument-coverage-pass-details]. [mir-passes]: mir/passes.md -[mir-instrument-coverage]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir/src/transform/coverage +[mir-instrument-coverage]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir_transform/src/coverage [code-region]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/coverage/struct.CodeRegion.html [counter-coverage-kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/coverage/enum.CoverageKind.html#variant.Counter [expression-coverage-kind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/coverage/enum.CoverageKind.html#variant.Expression @@ -358,13 +358,13 @@ example, `A + (B - C)` might represent an `Expression` count computed from three other counters, `A`, `B`, and `C`, but computing that value requires an intermediate expression for `B - C`. -[instrumentor]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/struct.Instrumentor.html -[coverage-graph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.CoverageGraph.html -[inject-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/struct.Instrumentor.html#method.inject_counters -[bcb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.BasicCoverageBlock.html -[debug]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/debug -[generate-coverage-spans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/spans/struct.CoverageSpans.html#method.generate_coverage_spans -[make-bcb-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/counters/struct.BcbCounters.html#method.make_bcb_counters +[instrumentor]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/struct.Instrumentor.html +[coverage-graph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/graph/struct.CoverageGraph.html +[inject-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/struct.Instrumentor.html#method.inject_counters +[bcb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/graph/struct.BasicCoverageBlock.html +[debug]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/debug +[generate-coverage-spans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/spans/struct.CoverageSpans.html#method.generate_coverage_spans +[make-bcb-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/counters/struct.BcbCounters.html#method.make_bcb_counters ### The `CoverageGraph` @@ -472,11 +472,11 @@ function--[`bcb_from_bb()`][bcb-from-bb]--to look up a `BasicCoverageBlock` from [directed-graph]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/graph/trait.DirectedGraph.html [graph-traits]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/graph/index.html#traits [mir-dev-guide]: mir/index.md -[compute-basic-coverage-blocks]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.CoverageGraph.html#method.compute_basic_coverage_blocks -[simplify-cfg]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/simplify/struct.SimplifyCfg.html +[compute-basic-coverage-blocks]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/graph/struct.CoverageGraph.html#method.compute_basic_coverage_blocks +[simplify-cfg]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/simplify/struct.SimplifyCfg.html [rust-lang/rust#78544]: https://github.com/rust-lang/rust/issues/78544 [mir-debugging]: mir/debugging.md -[bcb-from-bb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.CoverageGraph.html#method.bcb_from_bb +[bcb-from-bb]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/graph/struct.CoverageGraph.html#method.bcb_from_bb ### `CoverageSpans` @@ -521,9 +521,9 @@ MIR `Statement`s and `Terminator`s contributing to the `CoverageSpan`, and their individual `Span`s (which should be encapsulated within the code region of the refined `CoverageSpan`) -[coverage-spans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/spans/struct.CoverageSpans.html -[coverage-span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/spans/struct.CoverageSpan.html -[to-refined-spans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/spans/struct.CoverageSpans.html#method.to_refined_spans +[coverage-spans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/spans/struct.CoverageSpans.html +[coverage-span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/spans/struct.CoverageSpan.html +[to-refined-spans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/spans/struct.CoverageSpans.html#method.to_refined_spans ### `make_bcb_counters()` @@ -586,8 +586,8 @@ of `Counter` vs. `Expression` also depends on the order of counter assignments, and whether a BCB or incoming edge counter already has its `Counter` or `Expression`. -[bcb-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/counters/struct.BcbCounters.html -[traverse-coverage-graph-with-loops]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/graph/struct.TraverseCoverageGraphWithLoops.html +[bcb-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/counters/struct.BcbCounters.html +[traverse-coverage-graph-with-loops]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/graph/struct.TraverseCoverageGraphWithLoops.html ### Injecting counters into a MIR `BasicBlock` @@ -616,9 +616,9 @@ still must be injected because they contribute to other `Expression`s. Finally, edge's with a `CoverageKind::Counter` require a new `BasicBlock`, so the counter is only incremented when traversing the branch edge. -[inject-coverage-span-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/struct.Instrumentor.html#method.inject_coverage_span_counters -[inject-indirect-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/struct.Instrumentor.html#method.inject_indirect_counters -[inject-intermediate-expression]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/fn.inject_intermediate_expression.html +[inject-coverage-span-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/struct.Instrumentor.html#method.inject_coverage_span_counters +[inject-indirect-counters]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/struct.Instrumentor.html#method.inject_indirect_counters +[inject-intermediate-expression]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/fn.inject_intermediate_expression.html ### Additional Debugging Support @@ -627,4 +627,4 @@ See the for a detailed description of the debug output, logging, and configuration options available to developers working on the `InstrumentCoverage` pass. -[coverage-debugging]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/coverage/debug/index.html +[coverage-debugging]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/debug/index.html diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index 61277846b..0e626d97c 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -218,17 +218,17 @@ the example below: ["gen-kill" problems]: https://en.wikipedia.org/wiki/Data-flow_analysis#Bit_vector_problems [*Static Program Analysis*]: https://cs.au.dk/~amoeller/spa/ [Debugging MIR]: ./debugging.html -[`AnalysisDomain`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.AnalysisDomain.html -[`Analysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.Analysis.html -[`Engine`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/struct.Engine.html -[`GenKillAnalysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.GenKillAnalysis.html -[`JoinSemiLattice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/lattice/trait.JoinSemiLattice.html -[`NAME`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.AnalysisDomain.html#associatedconstant.NAME -[`ResultsCursor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/struct.ResultsCursor.html -[`ResultsVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.ResultsVisitor.html -[`apply_call_return_effect`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.Analysis.html#tymethod.apply_call_return_effect -[`into_engine`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/trait.Analysis.html#method.into_engine -[`lattice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/lattice/index.html +[`AnalysisDomain`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/trait.AnalysisDomain.html +[`Analysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/trait.Analysis.html +[`Engine`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/struct.Engine.html +[`GenKillAnalysis`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/trait.GenKillAnalysis.html +[`JoinSemiLattice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/lattice/trait.JoinSemiLattice.html +[`NAME`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/trait.AnalysisDomain.html#associatedconstant.NAME +[`ResultsCursor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/struct.ResultsCursor.html +[`ResultsVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/trait.ResultsVisitor.html +[`apply_call_return_effect`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/trait.Analysis.html#tymethod.apply_call_return_effect +[`into_engine`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/trait.Analysis.html#method.into_engine +[`lattice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/lattice/index.html [goethe]: https://www.youtube.com/watch?v=NVBQSR_HdL0&list=PL_sGR8T76Y58l3Gck3ZwIIHLWEmXrOLV_&index=2 [lattice]: https://en.wikipedia.org/wiki/Lattice_(order) [wiki]: https://en.wikipedia.org/wiki/Data-flow_analysis#Basic_principles diff --git a/src/mir/debugging.md b/src/mir/debugging.md index b7182fa90..84030b139 100644 --- a/src/mir/debugging.md +++ b/src/mir/debugging.md @@ -60,7 +60,7 @@ will select for things that reference *both* `main` and the pass > ls mir_dump rustc.main.000-000.CleanEndRegions.after.mir rustc.main.000-000.CleanEndRegions.before.mir ``` - + Filters can also have `|` parts to combine multiple sets of `&`-filters. For example `main & CleanEndRegions | main & NoLandingPads` will select *either* `main` and `CleanEndRegions` *or* diff --git a/src/mir/index.md b/src/mir/index.md index 306d2abfd..d3bceae47 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -18,7 +18,9 @@ graphs and desugaring), you may enjoy the ## Introduction to MIR MIR is defined in the [`compiler/rustc_middle/src/mir/`][mir] module, but much of the code -that manipulates it is found in [`compiler/rustc_mir`][mirmanip]. +that manipulates it is found in [`compiler/rustc_mir_build`][mirmanip_build], +[`compiler/rustc_mir_transform`][mirmanip_transform], and +[`compiler/rustc_mir_dataflow`][mirmanip_dataflow]. [RFC 1211]: https://rust-lang.github.io/rfcs/1211-mir.html @@ -258,7 +260,9 @@ See the const-eval WG's [docs on promotion](https://github.com/rust-lang/const-e [mir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html -[mirmanip]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html +[mirmanip_build]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/index.html +[mirmanip_transform]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/index.html +[mirmanip_dataflow]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/index.html [`Body`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html [newtype'd]: ../appendix/glossary.html#newtype [basicblocks]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.basic_blocks diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index 50e06960e..9ecf4e0d3 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -21,7 +21,7 @@ for a given [`DefId`][defid]. This query makes sure that the borrow checker has run and that some validation has occurred. Then, it [steals][steal] the MIR, optimizes it, and returns the improved MIR. -[optmir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html +[optmir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/fn.optimized_mir.html [query]: https://rustc-dev-guide.rust-lang.org/query.html [defid]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html#def-id [steal]: https://rustc-dev-guide.rust-lang.org/mir/passes.html?highlight=steal#stealing @@ -42,7 +42,7 @@ optimizes it, and returns the improved MIR. test output before you implement the optimization is so that you (and your reviewers) can see a before/after diff of what the optimization changed. -4. Implement a new optimization in [`compiler/rustc_mir/src/transform`]. +4. Implement a new optimization in [`compiler/rustc_mir_transform/src`]. The fastest and easiest way to do this is to 1. pick a small optimization (such as [`no_landing_pads`]) and copy it @@ -71,9 +71,10 @@ If you have any questions along the way, feel free to ask in `#t-compiler/wg-mir-opt` on Zulip. [mir-opt-test-readme]: https://github.com/rust-lang/rust/blob/master/src/test/mir-opt/README.md -[`compiler/rustc_mir/src/transform`]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir/src/transform -[`no_landing_pads`]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/transform/no_landing_pads.rs -[`run_optimization_passes()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.run_optimization_passes.html +[`compiler/rustc_mir_transform/src`]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir_transform/src + +[`no_landing_pads`]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_transform/src/no_landing_pads.rs +[`run_optimization_passes()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/fn.run_optimization_passes.html ## Defining optimization passes @@ -81,11 +82,11 @@ The list of passes run and the order in which they are run is defined by the [`run_optimization_passes`][rop] function. It contains an array of passes to run. Each pass in the array is a struct that implements the [`MirPass`] trait. The array is an array of `&dyn MirPass` trait objects. Typically, a pass is -implemented in its own submodule of the [`rustc_mir::transform`][trans] module. +implemented in its own module of the [`rustc_mir_transform`][trans] crate. -[rop]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.run_optimization_passes.html -[`MirPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/trait.MirPass.html -[trans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html +[rop]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/fn.run_optimization_passes.html +[`MirPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/trait.MirPass.html +[trans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/index.html Some examples of passes are: - `CleanupNonCodegenStatements`: remove some of the info that is only needed for @@ -94,7 +95,7 @@ Some examples of passes are: You can see the ["Implementors" section of the `MirPass` rustdocs][impl] for more examples. -[impl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/trait.MirPass.html#implementors +[impl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/trait.MirPass.html#implementors [constprop]: https://en.wikipedia.org/wiki/Constant_folding#Constant_propagation ## MIR optimization levels diff --git a/src/mir/passes.md b/src/mir/passes.md index b847584b1..5528b7762 100644 --- a/src/mir/passes.md +++ b/src/mir/passes.md @@ -27,7 +27,7 @@ where we want to access the MIR for type checking or other purposes: A `MirPass` is some bit of code that processes the MIR, typically – but not always – transforming it along the way somehow. For example, it might perform an optimization. The `MirPass` trait itself is found -in [the `rustc_mir::transform` module][mirtransform], and it +in [the `rustc_mir_transform` crate][mirtransform], and it basically consists of one method, `run_pass`, that simply gets an `&mut Mir` (along with the tcx and some information about where it came from). The MIR is therefore modified in place (which helps to @@ -96,6 +96,7 @@ This mechanism is a bit dodgy. There is a discussion of more elegant alternatives in [rust-lang/rust#41710]. [rust-lang/rust#41710]: https://github.com/rust-lang/rust/issues/41710 -[mirtransform]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/ -[`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/no_landing_pads/struct.NoLandingPads.html +[mirtransform]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/ + +[`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/no_landing_pads/struct.NoLandingPads.html [MIR visitor]: ./visitor.html diff --git a/src/mir/visitor.md b/src/mir/visitor.md index c80462b95..5c21d5304 100644 --- a/src/mir/visitor.md +++ b/src/mir/visitor.md @@ -41,7 +41,8 @@ A very simple example of a visitor can be found in [`NoLandingPads`]. That visitor doesn't even require any state: it just visits all terminators and removes their `unwind` successors. -[`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/no_landing_pads/struct.NoLandingPads.html + +[`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/no_landing_pads/struct.NoLandingPads.html ## Traversal diff --git a/src/miri.md b/src/miri.md index c19ba6401..50bbb4b56 100644 --- a/src/miri.md +++ b/src/miri.md @@ -100,11 +100,11 @@ further queries need to be executed in order to get at something as simple as a Future evaluations of the same constants will not actually invoke Miri, but just use the cached result. -[`Operand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.Operand.html -[`Immediate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/enum.Immediate.html +[`Operand`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/enum.Operand.html +[`Immediate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/enum.Immediate.html [`ConstValue`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.ConstValue.html [`Scalar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.Scalar.html -[`op_to_const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/eval_queries/fn.op_to_const.html +[`op_to_const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/const_eval/eval_queries/fn.op_to_const.html ## Datastructures @@ -183,7 +183,7 @@ needed to support circular statics, where we need to have a `Pointer` to a `static` for which we cannot yet have an `Allocation` as we do not know the bytes of its value. -[`Memory`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Memory.html +[`Memory`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/interpret/struct.Memory.html [`Allocation`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.Allocation.html [`Pointer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/struct.Pointer.html [`GlobalAlloc`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/interpret/enum.GlobalAlloc.html @@ -209,7 +209,7 @@ values. Although the main entry point to constant evaluation is the `tcx.const_eval_*` functions, there are additional functions in -[rustc_mir/src/const_eval.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/const_eval/index.html) +[rustc_const_eval/src/const_eval](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_const_eval/index.html) that allow accessing the fields of a `ConstValue` (`ByRef` or otherwise). You should never have to access an `Allocation` directly except for translating it to the compilation target (at the moment just LLVM). @@ -220,7 +220,7 @@ function with no arguments, except that constants do not allow local (named) variables at the time of writing this guide. A stack frame is defined by the `Frame` type in -[rustc_mir/src/interpret/eval_context.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/interpret/eval_context.rs) +[rustc_const_eval/src/interpret/eval_context.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_const_eval/src/interpret/eval_context.rs) and contains all the local variables memory (`None` at the start of evaluation). Each frame refers to the evaluation of either the root constant or subsequent calls to `const fn`. The @@ -232,7 +232,7 @@ The frames are just a `Vec`, there's no way to actually refer to a memory that can be referred to are `Allocation`s. Miri now calls the `step` method (in -[rustc_mir/src/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir/src/interpret/step.rs) +[rustc_const_eval/src/interpret/step.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_const_eval/src/interpret/step.rs) ) until it either returns an error or has no further statements to execute. Each statement will now initialize or modify the locals or the virtual memory referred to by a local. This might require evaluating other constants or diff --git a/src/overview.md b/src/overview.md index 26b291d35..bf64d0e56 100644 --- a/src/overview.md +++ b/src/overview.md @@ -373,15 +373,15 @@ For more details on bootstrapping, see - The Mid Level Intermediate Representation (MIR) - Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html) - Definition: [`rustc_middle/src/mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html) - - Definition of source that manipulates the MIR: [`rustc_mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/index.html) + - Definition of sources that manipulates the MIR: [`rustc_mir_build`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/index.html), [`rustc_mir_dataflow`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/index.html), [`rustc_mir_transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/index.html) - The Borrow Checker - Guide: [MIR Borrow Check](https://rustc-dev-guide.rust-lang.org/borrow_check.html) - - Definition: [`rustc_mir/borrow_check`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html) - - Main entry point: [`mir_borrowck` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/fn.mir_borrowck.html) + - Definition: [`rustc_borrowck`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/index.html) + - Main entry point: [`mir_borrowck` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/fn.mir_borrowck.html) - MIR Optimizations - Guide: [MIR Optimizations](https://rustc-dev-guide.rust-lang.org/mir/optimizations.html) - - Definition: [`rustc_mir/transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/index.html) - - Main entry point: [`optimized_mir` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/fn.optimized_mir.html) + - Definition: [`rustc_mir_transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/index.html) + - Main entry point: [`optimized_mir` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/fn.optimized_mir.html) - Code Generation - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/backend/codegen.html) - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index b383ec542..85f6601ad 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -268,14 +268,14 @@ Percentage : 43% Tree | matched `{do_mir_borrowck}` (43% total, 0% self) -: | rustc_mir::borrow_check::nll::compute_regions (20% total, 0% self) -: : | rustc_mir::borrow_check::nll::type_check::type_check_internal (13% total, 0% self) +: | rustc_borrowck::nll::compute_regions (20% total, 0% self) +: : | rustc_borrowck::nll::type_check::type_check_internal (13% total, 0% self) : : : | core::ops::function::FnOnce::call_once (5% total, 0% self) -: : : : | rustc_mir::borrow_check::nll::type_check::liveness::generate (5% total, 3% self) -: : : | as rustc::mir::visit::Visitor<'tcx>>::visit_mir (3% total, 0% self) +: : : : | rustc_borrowck::nll::type_check::liveness::generate (5% total, 3% self) +: : : | as rustc::mir::visit::Visitor<'tcx>>::visit_mir (3% total, 0% self) : | rustc::mir::visit::Visitor::visit_mir (8% total, 6% self) -: | as rustc_mir::dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (5% total, 0% self) -: | rustc_mir::dataflow::do_dataflow (3% total, 0% self) +: | as rustc_mir_dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (5% total, 0% self) +: | rustc_mir_dataflow::do_dataflow (3% total, 0% self) ``` What happens with `--tree-callees` is that @@ -319,10 +319,10 @@ Percentage : 100% Tree | matched `{do_mir_borrowck}` (100% total, 0% self) -: | rustc_mir::borrow_check::nll::compute_regions (47% total, 0% self) [...] +: | rustc_borrowck::nll::compute_regions (47% total, 0% self) [...] : | rustc::mir::visit::Visitor::visit_mir (19% total, 15% self) [...] -: | as rustc_mir::dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (13% total, 0% self) [...] -: | rustc_mir::dataflow::do_dataflow (8% total, 1% self) [...] +: | as rustc_mir_dataflow::DataflowResultsConsumer<'cx, 'tcx>>::visit_statement_entry (13% total, 0% self) [...] +: | rustc_mir_dataflow::do_dataflow (8% total, 1% self) [...] ``` Here you see that `compute_regions` came up as "47% total" — that From f3fb373be96d76b054cf434070392df83dca62bd Mon Sep 17 00:00:00 2001 From: pierwill Date: Thu, 28 Oct 2021 11:41:04 -0500 Subject: [PATCH 1568/1812] Edit "About this guide" for semantic line feeds This is work toward #1241. --- src/about-this-guide.md | 60 +++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 29 deletions(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index 3fa397ae4..f4c5c81d1 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -1,26 +1,27 @@ # About this guide -This guide is meant to help document how rustc – the Rust compiler – -works, as well as to help new contributors get involved in rustc -development. +This guide is meant to help document how rustc – the Rust compiler – works, +as well as to help new contributors get involved in rustc development. There are seven parts to this guide: -1. [Building and debugging `rustc`][p1]: Contains information that should be - useful no matter how you are contributing, about building, debugging, - profiling, etc. -2. [Contributing to `rustc`][p2]: Contains information that should be useful - no matter how you are contributing, about procedures for contribution, using git - and Github, stabilizing features, etc. -3. [High-Level Compiler Architecture][p3]: Discusses the high-level - architecture of the compiler and stages of the compile process. -4. [Source Code Representation][p4]: Describes the process of taking raw source code from the user and - transforming it into various forms that the compiler can work with easily. -5. [Analysis][p5]: discusses the analyses that the compiler uses to check various - properties of the code and inform later stages of the compile process (e.g., type checking). +1. [Building and debugging `rustc`][p1]: + Contains information that should be useful no matter how you are contributing, + about building, debugging, profiling, etc. +2. [Contributing to `rustc`][p2]: + Contains information that should be useful no matter how you are contributing, + about procedures for contribution, using git and Github, stabilizing features, etc. +3. [High-Level Compiler Architecture][p3]: + Discusses the high-level architecture of the compiler and stages of the compile process. +4. [Source Code Representation][p4]: + Describes the process of taking raw source code from the user + and transforming it into various forms that the compiler can work with easily. +5. [Analysis][p5]: + discusses the analyses that the compiler uses to check various properties of the code + and inform later stages of the compile process (e.g., type checking). 6. [From MIR to Binaries][p6]: How linked executable machine code is generated. -7. [Appendices][p7] at the end with useful reference information. There are a - few of these with different information, including a glossary. +7. [Appendices][p7] at the end with useful reference information. + There are a few of these with different information, including a glossary. [p1]: ./getting-started.md [p2]: ./contributing.md @@ -32,25 +33,26 @@ There are seven parts to this guide: ### Constant change -Keep in mind that `rustc` is a real production-quality product, being worked upon continuously by a -sizeable set of contributors. +Keep in mind that `rustc` is a real production-quality product, +being worked upon continuously by a sizeable set of contributors. As such, it has its fair share of codebase churn and technical debt. -In addition, many of the ideas discussed throughout this guide are idealized designs that are not -fully realized yet. +In addition, many of the ideas discussed throughout this guide are idealized designs +that are not fully realized yet. All this makes keeping this guide completely up to date on everything very hard! -The Guide itself is of course open-source as well, and the sources can be found at the -[GitHub repository]. -If you find any mistakes in the guide, please file an issue about it, or even better, open a PR with -a correction! +The Guide itself is of course open-source as well, +and the sources can be found at the [GitHub repository]. +If you find any mistakes in the guide, please file an issue about it. +even better, open a PR with a correction! -If you do contribute to the guide, please see the corresponding -[subsection on writing documentation in this guide]. +If you do contribute to the guide, +please see the corresponding [subsection on writing documentation in this guide]. [subsection on writing documentation in this guide]: contributing.md#contributing-to-rustc-dev-guide -> “‘All conditioned things are impermanent’ — when one sees this with wisdom, one turns away from -> suffering.” _The Dhammapada, verse 277_ +> “‘All conditioned things are impermanent’ — +> when one sees this with wisdom, one turns away from suffering.” +> _The Dhammapada, verse 277_ ## Other places to find information From 70966e597f7c6525f7a66dffa04b60f699209715 Mon Sep 17 00:00:00 2001 From: xFrednet Date: Thu, 28 Oct 2021 18:30:49 +0200 Subject: [PATCH 1569/1812] Some minor adjustments to the diagnostic documentation --- src/diagnostics.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index e35bde093..20dbefd7b 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -26,10 +26,12 @@ LL | more code | ^^^^ ``` -- Description (`error`, `warning`, etc.). +- Level (`error`, `warning`, etc.). It indicates the severity of the message. + (See [diagnostic levels](#diagnostic-levels)) - Code (for example, for "mismatched types", it is `E0308`). It helps users get more information about the current error through an extended - description of the problem in the error code index. + description of the problem in the error code index. Diagnostics created + by lints don't have a code in the emitted message. - Message. It is the main description of the problem. It should be general and able to stand on its own, so that it can make sense even in isolation. - Diagnostic window. This contains several things: @@ -61,7 +63,11 @@ error: the fobrulator needs to be krontrificated ``` When code or an identifier must appear in a message or label, it should be -surrounded with backticks: `` `foo.bar` ``. +surrounded with backticks: + +```txt +error: the identifier `foo.bar` is invalid +``` ### Error explanations From 0f69d33e166236aa7daaf4fac8867b4eac23c79d Mon Sep 17 00:00:00 2001 From: pierwill Date: Sat, 23 Oct 2021 23:15:54 -0500 Subject: [PATCH 1570/1812] Edit introduction to bootstrapping Use paragraphs instead of bullet-points. Edits throughout for clarity. Use semantic line breaks in edited sections. Co-authored-by: Joshua Nelson --- src/building/bootstrapping.md | 115 ++++++++++++++++++---------------- 1 file changed, 61 insertions(+), 54 deletions(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 26527ec9c..b6f9db74c 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -2,11 +2,8 @@ -This subchapter is about the bootstrapping process. -## What is bootstrapping? How does it work? - -[Bootstrapping] is the process of using a compiler to compile itself. +[*Bootstrapping*] is the process of using a compiler to compile itself. More accurately, it means using an older compiler to compile a newer version of the same compiler. @@ -21,45 +18,53 @@ rustc, then uses it to compile the new compiler. ## Stages of bootstrapping -Compiling `rustc` is done in stages: - -- **Stage 0:** the stage0 compiler is usually (you can configure `x.py` to use - something else) the current _beta_ `rustc` compiler and its associated dynamic - libraries (which `x.py` will download for you). This stage0 compiler is then - used only to compile `rustbuild`, `std`, and `rustc`. When compiling - `rustc`, this stage0 compiler uses the freshly compiled `std`. - There are two concepts at play here: a compiler (with its set of dependencies) - and its 'target' or 'object' libraries (`std` and `rustc`). - Both are staged, but in a staggered manner. -- **Stage 1:** the code in your clone (for new version) is then - compiled with the stage0 compiler to produce the stage1 compiler. - However, it was built with an older compiler (stage0), so to - optimize the stage1 compiler we go to the next stage. - - In theory, the stage1 compiler is functionally identical to the - stage2 compiler, but in practice there are subtle differences. In - particular, the stage1 compiler itself was built by stage0 and - hence not by the source in your working directory: this means that - the symbol names used in the compiler source may not match the - symbol names that would have been made by the stage1 compiler. This is - important when using dynamic linking and the lack of ABI compatibility - between versions. This primarily manifests when tests try to link with any - of the `rustc_*` crates or use the (now deprecated) plugin infrastructure. - These tests are marked with `ignore-stage1`. -- **Stage 2:** we rebuild our stage1 compiler with itself to produce - the stage2 compiler (i.e. it builds itself) to have all the _latest - optimizations_. (By default, we copy the stage1 libraries for use by - the stage2 compiler, since they ought to be identical.) -- _(Optional)_ **Stage 3**: to sanity check our new compiler, we - can build the libraries with the stage2 compiler. The result ought - to be identical to before, unless something has broken. - -The `stage2` compiler is the one distributed with `rustup` and all other -install methods. However, it takes a very long time to build because one must -first build the new compiler with an older compiler and then use that to -build the new compiler with itself. For development, you usually only want -the `stage1` compiler: `x.py build library/std`. - -### Default stages +Compiling `rustc` is done in stages. + +### Stage 0 + +The stage0 compiler is usually the current _beta_ `rustc` compiler +and its associated dynamic libraries, +which `x.py` will download for you. +(You can also configure `x.py` to use something else.) + +The stage0 compiler is then used only to compile `rustbuild`, `std`, and `rustc`. +When compiling `rustc`, the stage0 compiler uses the freshly compiled `std`. +There are two concepts at play here: +a compiler (with its set of dependencies) +and its 'target' or 'object' libraries (`std` and `rustc`). +Both are staged, but in a staggered manner. + +### Stage 1 + +The rustc source code is then compiled with the stage0 compiler to produce the stage1 compiler. + +### Stage 2 + +We then rebuild our stage1 compiler with itself to produce the stage2 compiler. + +In theory, the stage1 compiler is functionally identical to the stage2 compiler, +but in practice there are subtle differences. +In particular, the stage1 compiler itself was built by stage0 +and hence not by the source in your working directory. +This means that the symbol names used in the compiler source +may not match the symbol names that would have been made by the stage1 compiler, +which can cause problems for dynamic libraries and tests. + +The `stage2` compiler is the one distributed with `rustup` and all other install methods. +However, it takes a very long time to build +because one must first build the new compiler with an older compiler +and then use that to build the new compiler with itself. +For development, you usually only want the `stage1` compiler, +which you can build with `x.py build library/std`. +See [Building the Compiler](/building/how-to-build-and-run.html#building-the-compiler). + +### Stage 3 + +Stage 3 is optional. To sanity check our new compiler, we +can build the libraries with the stage2 compiler. The result ought +to be identical to before, unless something has broken. + +### Building the stages `x.py` tries to be helpful and pick the stage you most likely meant for each subcommand. These defaults are as follows: @@ -132,9 +137,10 @@ contribution [here][bootstrap-build]. This is a detailed look into the separate bootstrap stages. The convention `x.py` uses is that: + - A `--stage N` flag means to run the stage N compiler (`stageN/rustc`). - A "stage N artifact" is a build artifact that is _produced_ by the stage N compiler. -- The "stage (N+1) compiler" is assembled from "stage N artifacts". This +- The stage N+1 compiler is assembled from stage N *artifacts*. This process is called _uplifting_. #### Build artifacts @@ -174,11 +180,10 @@ Build artifacts include, but are not limited to: library/std` instead, which allows compiling programs without needing to define lang items. -### Building vs. Running - +### Building vs. running Note that `build --stage N compiler/rustc` **does not** build the stage N compiler: -instead it builds the stage _N+1_ compiler _using_ the stage N compiler. +instead it builds the stage N+1 compiler _using_ the stage N compiler. In short, _stage 0 uses the stage0 compiler to create stage0 artifacts which will later be uplifted to be the stage1 compiler_. @@ -186,8 +191,8 @@ will later be uplifted to be the stage1 compiler_. In each stage, two major steps are performed: 1. `std` is compiled by the stage N compiler. -2. That `std` is linked to programs built by the stage N compiler, including - the stage N artifacts (stage (N+1) compiler). +2. That `std` is linked to programs built by the stage N compiler, + including the stage N artifacts (stage N+1 compiler). This is somewhat intuitive if one thinks of the stage N artifacts as "just" another program we are building with the stage N compiler: @@ -202,8 +207,6 @@ Keep in mind this diagram is a simplification, i.e. `rustdoc` can be built at different stages, the process is a bit different when passing flags such as `--keep-stage`, or if there are non-host targets. -The stage 2 compiler is what is shipped to end-users. - ### Stages and `std` Note that there are two `std` libraries in play here: @@ -226,10 +229,12 @@ recompiling that `std`. `--keep-stage` simply assumes the previous compile is fine and copies those artifacts into the appropriate place, skipping the cargo invocation. -### Cross-compiling +### Cross-compiling rustc + +*Cross-compiling* is the process of compiling code that will run on another archicture. +For instance, you might want to build an ARM version of rustc using an x86 machine. +Building stage2 `std` is different when you are cross-compiling. -Building stage2 `std` is different depending on whether you are cross-compiling or not -(see in the table how stage2 only builds non-host `std` targets). This is because `x.py` uses a trick: if `HOST` and `TARGET` are the same, it will reuse stage1 `std` for stage2! This is sound because stage1 `std` was compiled with the stage1 compiler, i.e. a compiler using the source code @@ -239,6 +244,8 @@ to the `std` that `stage2/rustc` would compile. However, when cross-compiling, stage1 `std` will only run on the host. So the stage2 compiler has to recompile `std` for the target. +(See in the table how stage2 only builds non-host `std` targets). + ### Why does only libstd use `cfg(bootstrap)`? The `rustc` generated by the stage0 compiler is linked to the freshly-built From 292072d8e26b8e26c5a048939ff21d3707e869c7 Mon Sep 17 00:00:00 2001 From: Caleb Cartwright Date: Mon, 1 Nov 2021 21:31:19 -0500 Subject: [PATCH 1571/1812] enhance subtree docs, link to clippy docs --- src/contributing.md | 42 +++++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 19 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index aca5b142e..91817904d 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -172,32 +172,34 @@ differently from other crates that are directly in this repo: * [Clippy](https://github.com/rust-lang/rust-clippy) * [rustfmt](https://github.com/rust-lang/rustfmt) -They are just regular files and directories. This is in contrast to `submodule` dependencies -(see below for those). Only tool authors will actually use any operations here. +In contrast to `submodule` dependencies +(see below for those), the `subtree` dependencies are just regular files and directories which can +be updated in tree. However, enhancements, bug fixes, etc. specific to these tools should be filed +against the tools directly in their respective upstream repositories. #### Synchronizing a subtree -There are two synchronization directions: `subtree push` and `subtree pull`. +Periodically the changes made to subtree based dependencies need to be synchronized between this +repository and the upstream tool repositories. -``` -git subtree push -P src/tools/clippy git@github.com:your-github-name/rust-clippy sync-from-rust -``` - -takes all the changes that -happened to the copy in this repo and creates commits on the remote repo that match the local -changes. Every local commit that touched the subtree causes a commit on the remote repo, but is -modified to move the files from the specified directory to the tool repo root. +Subtree synchronizations are typically handled by the respective tool maintainers. Other users +are welcome to submit synchronization PRs, however, in order to do so you you will need to modify +your local git installation and follow a very precise set of instructions. +These instructions are documented, along with several useful tips and tricks, in the +[syncing subtree changes][clippy-sync-docs] section in Clippy's Contributing guide. +The instructions are applicable for use with any subtree based tool, just be sure to +use the correct corresponding subtree directory and remote repository. -Make sure to not pick the `master` branch on the tool repo, so you can open a normal PR to the tool -to merge that subrepo push. +The synchronization process goes in two directions: `subtree push` and `subtree pull`. -``` -git subtree pull -P src/tools/clippy https://github.com/rust-lang/rust-clippy master -``` +A `subtree push` takes all the changes that happened to the copy in this repo and creates commits +on the remote repo that match the local changes. Every local +commit that touched the subtree causes a commit on the remote repo, but +is modified to move the files from the specified directory to the tool repo root. -takes all changes since the last `subtree pull` from the tool repo -and adds these commits to the rustc repo + a merge commit that moves the tool changes into -the specified directory in the rust repository. +A `subtree pull` takes all changes since the last `subtree pull` +from the tool repo and adds these commits to the rustc repo along with a merge commit that moves +the tool changes into the specified directory in the rust repository. It is recommended that you always do a push first and get that merged to the tool master branch. Then, when you do a pull, the merge works without conflicts. @@ -212,6 +214,8 @@ Luckily you can just abort this without any consequences by throwing away either in rustc or the pushed branch on the remote and try again. It is usually fairly obvious that this is happening because you suddenly get thousands of commits that want to be synchronized. +[clippy-sync-docs]: https://github.com/rust-lang/rust-clippy/blob/master/CONTRIBUTING.md#syncing-changes-between-clippy-and-rust-langrust + #### Creating a new subtree dependency If you want to create a new subtree dependency from an existing repository, call (from this From dac568c95c78121b5c74d8d7984d241c0c55e426 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Wed, 3 Nov 2021 12:22:15 -0700 Subject: [PATCH 1572/1812] Ensure date-check cron job is using latest stable Rust This should prevent future failures like this one [1]. [1]: https://github.com/rust-lang/rustc-dev-guide/runs/4067460927?check_suite_focus=true --- .github/workflows/date-check.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.github/workflows/date-check.yml b/.github/workflows/date-check.yml index c787da071..b808876a4 100644 --- a/.github/workflows/date-check.yml +++ b/.github/workflows/date-check.yml @@ -17,6 +17,10 @@ jobs: - name: Checkout repo uses: actions/checkout@v2 + - name: Ensure Rust is up-to-date + run: | + rustup update stable + - name: Run `date-check` working-directory: ci/date-check run: | From f146da3734af4624bebfd982b64d125bd750d150 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Wed, 3 Nov 2021 12:24:50 -0700 Subject: [PATCH 1573/1812] Update some date-check comments I removed one of them because it doesn't seem necessary. --- src/overview.md | 2 +- src/rustdoc-internals.md | 2 +- src/tests/intro.md | 3 +-- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/src/overview.md b/src/overview.md index bf64d0e56..5c0732f37 100644 --- a/src/overview.md +++ b/src/overview.md @@ -262,7 +262,7 @@ Moreover, the compiler wasn't originally built to use a query system; the query system has been retrofitted into the compiler, so parts of it are not query-fied yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to eventually query-fy all of the steps listed in the previous section, -but as of February 2021, only the steps between HIR and +but as of February 2021, only the steps between HIR and LLVM IR are query-fied. That is, lexing, parsing, name resolution, and macro expansion are done all at once for the whole program. diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index 112a5dcab..0d7459b1d 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -66,7 +66,7 @@ these passes, please let us know!) [44136]: https://github.com/rust-lang/rust/issues/44136 -Here is the list of passes as of February 2021: +Here is the list of passes as of October 2021: - `calculate-doc-coverage` calculates information used for the `--show-coverage` flag. diff --git a/src/tests/intro.md b/src/tests/intro.md index 641913345..3f8ec97ee 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -126,8 +126,7 @@ essence, it runs `./x.py test` after building for each of them. The integration bot [bors] is used for coordinating merges to the master branch. When a PR is approved, it goes into a [queue] where merges are tested one at a -time on a wide set of platforms using GitHub Actions (as of January 2021, over 50 different configurations). Due to the limit on the +time on a wide set of platforms using GitHub Actions. Due to the limit on the number of parallel jobs, we run CI under the [rust-lang-ci] organization except for PRs. Most platforms only run the build steps, some run a restricted set of tests, only a subset run the full suite of tests (see Rust's [platform tiers]). From 2ad51b6d750ab0e78a6e055e13b94a5ad3a1dea7 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 4 Nov 2021 09:30:35 -0700 Subject: [PATCH 1574/1812] Fix date Co-authored-by: Yuki Okushi --- src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index 5c0732f37..5c88722ef 100644 --- a/src/overview.md +++ b/src/overview.md @@ -262,7 +262,7 @@ Moreover, the compiler wasn't originally built to use a query system; the query system has been retrofitted into the compiler, so parts of it are not query-fied yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to eventually query-fy all of the steps listed in the previous section, -but as of February 2021, only the steps between HIR and +but as of November 2021, only the steps between HIR and LLVM IR are query-fied. That is, lexing, parsing, name resolution, and macro expansion are done all at once for the whole program. From a034fad8041a779528e9ab20137ebfb12566f6b8 Mon Sep 17 00:00:00 2001 From: Dmitry Savintsev Date: Thu, 4 Nov 2021 18:50:37 +0100 Subject: [PATCH 1575/1812] tiny capitalization fix --- src/about-this-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index f4c5c81d1..e015302c0 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -43,7 +43,7 @@ All this makes keeping this guide completely up to date on everything very hard! The Guide itself is of course open-source as well, and the sources can be found at the [GitHub repository]. If you find any mistakes in the guide, please file an issue about it. -even better, open a PR with a correction! +Even better, open a PR with a correction! If you do contribute to the guide, please see the corresponding [subsection on writing documentation in this guide]. From 8a8452cfccd36d46160706ce04bf94ef315e9c61 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Wed, 3 Nov 2021 17:36:35 -0700 Subject: [PATCH 1576/1812] Remove some legacy test suites. --- src/compiletest.md | 6 +++--- src/tests/adding.md | 1 - 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/src/compiletest.md b/src/compiletest.md index 2e0bcec53..b85aa09c2 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -16,9 +16,9 @@ and more. If you are unfamiliar with the compiler testing framework, see [this chapter](./tests/intro.md) for additional background. The tests themselves are typically (but not always) organized into -"suites" – for example, `run-fail`, a folder holding tests that should compile -successfully, but return a failure (non-zero status) at runtime, `compile-fail`, -a folder holding tests that should fail to compile, and many more. The various +"suites" – for example, `incremental`, a folder holding tests that check +incremental compilation behavior, `codegen`, +a folder holding tests that check code generation, and many more. The various suites are defined in [`src/tools/compiletest/src/common.rs`] in the `pub enum Mode` declaration. And a good introduction to the different suites of compiler tests along with details about them can be found in diff --git a/src/tests/adding.md b/src/tests/adding.md index d1b19516f..34bd6f20e 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -43,7 +43,6 @@ rough heuristics: message is not relevant to the test. These should have an [error number] (`E0XXX`) in the code block to make sure it's the correct error. - For most other things, [a `ui` (or `ui-fulldeps`) test](#ui) is to be preferred: - - [`ui`](#ui) tests subsume both `run-pass`, `compile-fail`, and `parse-fail` tests - in the case of warnings or errors, `ui` tests capture the full output, which makes it easier to review but also helps prevent "hidden" regressions in the output From ffcc6297c6ef3daa380061db9cad8ce5bc681ddd Mon Sep 17 00:00:00 2001 From: asquared31415 <34665709+asquared31415@users.noreply.github.com> Date: Sat, 6 Nov 2021 05:32:55 -0400 Subject: [PATCH 1577/1812] Add note to emphasize replacing TARGET_TRIPLE (#1250) --- src/building/suggested.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 24e25f5d0..284317af7 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -32,7 +32,7 @@ you can write: -[*Bootstrapping*] is the process of using a compiler to compile itself. +[*Bootstrapping*][boot] is the process of using a compiler to compile itself. More accurately, it means using an older compiler to compile a newer version of the same compiler. @@ -101,7 +101,7 @@ _break the stability guarantees_ of rust: Allow using `#![feature(...)]` with a compiler that's not nightly. This should never be used except when bootstrapping the compiler. -[Bootstrapping]: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) +[boot]: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) [intrinsics]: ../appendix/glossary.md#intrinsic [ocaml-compiler]: https://github.com/rust-lang/rust/tree/ef75860a0a72f79f97216f8aaa5b388d98da6480/src/boot From f1297f556013d1e8bdeb7f3868827ef624b4f340 Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Sun, 14 Nov 2021 14:12:13 +1100 Subject: [PATCH 1580/1812] Fix compare-mode documentation --- src/tests/running.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/tests/running.md b/src/tests/running.md index 34a44f9c2..ca5b7f3ac 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -186,8 +186,17 @@ To run the UI test suite in NLL mode, one would use the following: ./x.py test src/test/ui --compare-mode=nll ``` -Other examples of compare-modes are "noopt", "migrate", and -[revisions](./adding.html#revisions). +The possible compare modes are: + +* nll - currently nll is implemented in migrate mode, this option runs with true nll. +* polonius +* chalk +* split-dwarf +* split-dwarf-single + +Note that compare modes are seperate to [revisions](./adding.html#revisions). +All revisions are tested when running `./x.py test src/test/ui`, +however compare-modes must be manually run individually via the `--compare-mode` flag. ## Running tests manually From 0fc1fa9f1eb4e3dee1e4f6e5639e6e450dfdfb9c Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Tue, 16 Nov 2021 00:37:13 +1100 Subject: [PATCH 1581/1812] Spelling fixes --- src/appendix/glossary.md | 2 +- src/backend/monomorph.md | 2 +- src/diagnostics/lintstore.md | 2 +- src/early-late-bound.md | 2 +- src/git.md | 2 +- src/llvm-coverage-instrumentation.md | 2 +- src/macro-expansion.md | 2 +- src/mir/debugging.md | 2 +- src/mir/index.md | 2 +- src/miri.md | 2 +- src/profiling/with_perf.md | 2 +- src/tests/running.md | 2 +- src/tracing.md | 4 ++-- src/ty.md | 2 +- 14 files changed, 15 insertions(+), 15 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 6b3ec4196..4eba27fce 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -87,7 +87,7 @@ Term | Meaning uninhabited type   | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". upvar   | A variable captured by a closure from outside the closure. variance   | Determines how changes to a generic type/lifetime parameter affect subtyping; for example, if `T` is a subtype of `U`, then `Vec` is a subtype `Vec` because `Vec` is *covariant* in its generic parameter. See [the background chapter](./background.md#variance) for a more general explanation. See the [variance chapter](../variance.md) for an explanation of how type checking handles variance. -variant index   | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discrimiant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). +variant index   | In an enum, identifies a variant by assigning them indices starting at 0. This is purely internal and not to be confused with the ["discriminant"](#discriminant) which can be overwritten by the user (e.g. `enum Bool { True = 42, False = 0 }`). wide pointer   | A pointer with additional metadata. See "fat pointer" for more. ZST   | Zero-Sized Type. A type whose values have size 0 bytes. Since `2^0 = 1`, such types can have exactly one value. For example, `()` (unit) is a ZST. `struct Foo;` is also a ZST. The compiler can do some nice optimizations around ZSTs. diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index 0dc805431..a2918b608 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -71,7 +71,7 @@ or more modules in Crate B. | - | - | | Non-generic function | Crate A function doesn't appear in any codegen units of Crate B | | Non-generic `#[inline]` function | Crate A function appears with in a single CGU of Crate B, and exists even after post-inlining stage| -| Generic function | Regardless of inlining, all monoporphized (specialized) functions
    from Crate A appear within a single codegen unit for Crate B.
    The codegen unit exists even after the post inlining stage.| +| Generic function | Regardless of inlining, all monomorphized (specialized) functions
    from Crate A appear within a single codegen unit for Crate B.
    The codegen unit exists even after the post inlining stage.| | Generic `#[inline]` function | - same - | For more details about the partitioner read the module level [documentation]. diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index d2796c070..b544d2b6d 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -21,7 +21,7 @@ As of July 2021, we lint against direct declarations without the use of the macro today (although this may change in the future, as the macro is somewhat unwieldy to add new fields to, like all macros). -Lint declarations don't carry any "state" - they are merely global identifers and descriptions of +Lint declarations don't carry any "state" - they are merely global identifiers and descriptions of lints. We assert at runtime that they are not registered twice (by lint name). Lint passes are the meat of any lint. Notably, there is not a one-to-one relationship between diff --git a/src/early-late-bound.md b/src/early-late-bound.md index 4178a4af0..29b2136b4 100644 --- a/src/early-late-bound.md +++ b/src/early-late-bound.md @@ -24,7 +24,7 @@ of type `for fn(T)`, we would need a single function pointer that can be used for a parameter of any type, but in Rust we generate customized code for each parameter type. -One consequence of this asymmetry is a weird split in how we represesent some +One consequence of this asymmetry is a weird split in how we represent some generic types: _early-_ and _late-_ bound parameters. Basically, if we cannot represent a type (e.g. a universally quantified type), we have to bind it _early_ so that the unrepresentable type is never around. diff --git a/src/git.md b/src/git.md index ac03a3c0f..40f846d6a 100644 --- a/src/git.md +++ b/src/git.md @@ -408,7 +408,7 @@ nothing to commit, working tree clean ``` As far as git is concerned, you are no longer in the `rust` repo, but in the `miri` repo. -You will notice that we are in "detatched HEAD" state, i.e. not on a branch but on a +You will notice that we are in "detached HEAD" state, i.e. not on a branch but on a particular commit. This is because, like any dependency, we want to be able to control which version to use. diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 3dd565b59..4a0f53bfa 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -453,7 +453,7 @@ The nodes contain information in sections: its `BasicCoverageBlockData`). 2. The first content section shows the assigned `Counter` or `Expression` for each contiguous section of code. (There may be more than one `Expression` - incremented by the same `Counter` for discontiguous sections of code + incremented by the same `Counter` for noncontiguous sections of code representing the same sequential actions.) Note the code is represented by the line and column ranges (for example: `52:28-52:33`, representing the original source line 52, for columns 28-33). These are followed by the MIR diff --git a/src/macro-expansion.md b/src/macro-expansion.md index ce8285283..2f42ad9b9 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -585,7 +585,7 @@ syntactic sugar and are allowed to be in namespaces. ## Procedural Macros -Precedural macros are also expanded during parsing, as mentioned above. +Procedural macros are also expanded during parsing, as mentioned above. However, they use a rather different mechanism. Rather than having a parser in the compiler, procedural macros are implemented as custom, third-party crates. The compiler will compile the proc macro crate and specially annotated diff --git a/src/mir/debugging.md b/src/mir/debugging.md index 84030b139..3da17785b 100644 --- a/src/mir/debugging.md +++ b/src/mir/debugging.md @@ -12,7 +12,7 @@ control-flow graph spans associated with MIR elements (including mouse-over actions to reveal elements obscured by overlaps, and tooltips to view the MIR statements). This flag takes an optional value: `statement` (the default), `terminator`, or -`block`, to generate span highlights with different levels of granulatity. +`block`, to generate span highlights with different levels of granularity. `-Z dump-mir=F` is a handy compiler options that will let you view the MIR for each function at each stage of compilation. `-Z dump-mir` takes a **filter** `F` diff --git a/src/mir/index.md b/src/mir/index.md index d3bceae47..0c00928c0 100644 --- a/src/mir/index.md +++ b/src/mir/index.md @@ -54,7 +54,7 @@ This section introduces the key concepts of MIR, summarized here: - **Operands:** the arguments to an rvalue, which can either be a constant (like `22`) or a place (like `_1`). -You can get a feeling for how MIR is structed by translating simple +You can get a feeling for how MIR is constructed by translating simple programs into MIR and reading the pretty printed output. In fact, the playground makes this easy, since it supplies a MIR button that will show you the MIR for your program. Try putting this program into play diff --git a/src/miri.md b/src/miri.md index 50bbb4b56..dd54f6548 100644 --- a/src/miri.md +++ b/src/miri.md @@ -119,7 +119,7 @@ allocation. These allocations can be accessed via the methods on see [the next section](#memory) for more on that. If you are expecting a numeric result, you can use `eval_usize` (panics on -anything that can't be representad as a `u64`) or `try_eval_usize` which results +anything that can't be represented as a `u64`) or `try_eval_usize` which results in an `Option` yielding the `Scalar` if possible. ## Memory diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index 85f6601ad..af30b4732 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -253,7 +253,7 @@ the regular expression matched. ### Example: Where does MIR borrowck spend its time? -Often we want to do a more "explorational" queries. Like, we know that +Often we want to do more "explorational" queries. Like, we know that MIR borrowck is 29% of the time, but where does that time get spent? For that, the `--tree-callees` option is often the best tool. You usually also want to give `--tree-min-percent` or diff --git a/src/tests/running.md b/src/tests/running.md index ca5b7f3ac..19925fe27 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -194,7 +194,7 @@ The possible compare modes are: * split-dwarf * split-dwarf-single -Note that compare modes are seperate to [revisions](./adding.html#revisions). +Note that compare modes are separate to [revisions](./adding.html#revisions). All revisions are tested when running `./x.py test src/test/ui`, however compare-modes must be manually run individually via the `--compare-mode` flag. diff --git a/src/tracing.md b/src/tracing.md index 422d94c53..63d68e541 100644 --- a/src/tracing.md +++ b/src/tracing.md @@ -176,7 +176,7 @@ here. There is no perfect balance to hit here, and is left to the reviewer's discretion to decide whether to let you leave `debug!` statements in or whether to ask you to remove them before merging. -It may be preferrable to use `trace!` over `debug!` for very noisy logs. +It may be preferable to use `trace!` over `debug!` for very noisy logs. A loosely followed convention is to use `#[instrument(level = "debug")]` ([also see the attribute's documentation](https://docs.rs/tracing-attributes/0.1.17/tracing_attributes/attr.instrument.html)) @@ -201,4 +201,4 @@ This means that you should not put anything too expensive or likely to crash there - that would annoy anyone who wants to use logging for that module. No-one will know it until someone tries to use logging to find *another* bug. -[`tracing`]: https://docs.rs/tracing \ No newline at end of file +[`tracing`]: https://docs.rs/tracing diff --git a/src/ty.md b/src/ty.md index 9ee2ccfe2..87d653a74 100644 --- a/src/ty.md +++ b/src/ty.md @@ -312,7 +312,7 @@ delaying a redundant span bug. Recall that we represent a generic struct with `(AdtDef, substs)`. So why bother with this scheme? -Well, the alternate way we could have choosen to represent types would be to always create a new, +Well, the alternate way we could have chosen to represent types would be to always create a new, fully-substituted form of the `AdtDef` where all the types are already substituted. This seems like less of a hassle. However, the `(AdtDef, substs)` scheme has some advantages over this. From 24132faa13b824f4e6a3eb0108aa14c9067ca0f3 Mon Sep 17 00:00:00 2001 From: Ken Matsui <26405363+ken-matsui@users.noreply.github.com> Date: Tue, 16 Nov 2021 07:44:50 +0900 Subject: [PATCH 1582/1812] Unify `x.py` usage (#1258) --- src/backend/updating-llvm.md | 2 +- src/building/bootstrapping.md | 20 ++++++------ .../build-install-distribution-artifacts.md | 2 +- src/building/compiler-documenting.md | 2 +- src/building/how-to-build-and-run.md | 2 +- src/building/new-target.md | 2 +- src/building/suggested.md | 8 ++--- src/contributing.md | 32 +++++++++---------- src/getting-started.md | 32 +++++++++---------- src/git.md | 2 +- src/profiling.md | 4 +-- src/tests/intro.md | 2 +- src/tests/running.md | 2 +- 13 files changed, 56 insertions(+), 56 deletions(-) diff --git a/src/backend/updating-llvm.md b/src/backend/updating-llvm.md index 1a6fa033a..0de0767b6 100644 --- a/src/backend/updating-llvm.md +++ b/src/backend/updating-llvm.md @@ -102,7 +102,7 @@ through each in detail. with updated LLVM bindings. Note that you should use `#ifdef` and such to ensure that the bindings still compile on older LLVM versions. - Note that `profile = "compiler"` and other defaults set by `x.py setup` + Note that `profile = "compiler"` and other defaults set by `./x.py setup` download LLVM from CI instead of building it from source. You should disable this temporarily to make sure your changes are being used, by setting ```toml diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index e4dcc5ab2..fc1ad6c00 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -55,7 +55,7 @@ However, it takes a very long time to build because one must first build the new compiler with an older compiler and then use that to build the new compiler with itself. For development, you usually only want the `stage1` compiler, -which you can build with `x.py build library/std`. +which you can build with `./x.py build library/std`. See [Building the Compiler](/building/how-to-build-and-run.html#building-the-compiler). ### Stage 3 @@ -157,26 +157,26 @@ Build artifacts include, but are not limited to: #### Examples -- `x.py build --stage 0` means to build with the beta `rustc`. -- `x.py doc --stage 0` means to document using the beta `rustdoc`. -- `x.py test --stage 0 library/std` means to run tests on the standard library +- `./x.py build --stage 0` means to build with the beta `rustc`. +- `./x.py doc --stage 0` means to document using the beta `rustdoc`. +- `./x.py test --stage 0 library/std` means to run tests on the standard library without building `rustc` from source ('build with stage 0, then test the artifacts'). If you're working on the standard library, this is normally the test command you want. -- `x.py test src/test/ui` means to build the stage 1 compiler and run +- `./x.py test src/test/ui` means to build the stage 1 compiler and run `compiletest` on it. If you're working on the compiler, this is normally the test command you want. #### Examples of what *not* to do -- `x.py test --stage 0 src/test/ui` is not meaningful: it runs tests on the +- `./x.py test --stage 0 src/test/ui` is not meaningful: it runs tests on the _beta_ compiler and doesn't build `rustc` from source. Use `test src/test/ui` instead, which builds stage 1 from source. -- `x.py test --stage 0 compiler/rustc` builds the compiler but runs no tests: +- `./x.py test --stage 0 compiler/rustc` builds the compiler but runs no tests: it's running `cargo test -p rustc`, but cargo doesn't understand Rust's tests. You shouldn't need to use this, use `test` instead (without arguments). -- `x.py build --stage 0 compiler/rustc` builds the compiler, but does not build - libstd or even libcore. Most of the time, you'll want `x.py build +- `./x.py build --stage 0 compiler/rustc` builds the compiler, but does not build + libstd or even libcore. Most of the time, you'll want `./x.py build library/std` instead, which allows compiling programs without needing to define lang items. @@ -348,7 +348,7 @@ You can find more discussion about sysroots in: [rustdoc PR]: https://github.com/rust-lang/rust/pull/76728 -### Directories and artifacts generated by x.py +### Directories and artifacts generated by `x.py` The following tables indicate the outputs of various stage actions: diff --git a/src/building/build-install-distribution-artifacts.md b/src/building/build-install-distribution-artifacts.md index 7430ffb9b..4ec3f958a 100644 --- a/src/building/build-install-distribution-artifacts.md +++ b/src/building/build-install-distribution-artifacts.md @@ -18,7 +18,7 @@ test that it works on your target system. You’ll want to run this command: Note: If you are testing out a modification to a compiler, you might want to use it to compile some project. - Usually, you do not want to use ./x.py install for testing. + Usually, you do not want to use `./x.py install` for testing. Rather, you should create a toolchain as discussed in [here][create-rustup-toolchain]. diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md index af3cd7ce2..0efe2fce6 100644 --- a/src/building/compiler-documenting.md +++ b/src/building/compiler-documenting.md @@ -4,7 +4,7 @@ You might want to build documentation of the various components available like the standard library. There’s two ways to go about this. You can run rustdoc directly on the file to make sure the HTML is correct, which is fast. Alternatively, you can build the documentation -as part of the build process through x.py. Both are viable methods +as part of the build process through `x.py`. Both are viable methods since documentation is more about the content. ## Document everything diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 49c2e8b66..981bb6e50 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -20,7 +20,7 @@ cd rust ## Create a `config.toml` -To start, run `x.py setup`. This will create a `config.toml` with reasonable defaults. +To start, run `./x.py setup`. This will create a `config.toml` with reasonable defaults. You may also want to change some of the following settings (and possibly others, such as `llvm.ccache`): diff --git a/src/building/new-target.md b/src/building/new-target.md index 968754138..b5fc2cb0a 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -8,7 +8,7 @@ relevant to your desired goal. For very new targets, you may need to use a different fork of LLVM than what is currently shipped with Rust. In that case, navigate to -the `src/llvm-project` git submodule (you might need to run `x.py +the `src/llvm-project` git submodule (you might need to run `./x.py check` at least once so the submodule is updated), check out the appropriate commit for your fork, then commit that new submodule reference in the main Rust repository. diff --git a/src/building/suggested.md b/src/building/suggested.md index 284317af7..bae98aa04 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -8,13 +8,13 @@ to make your life easier. CI will automatically fail your build if it doesn't pass `tidy`, our internal tool for ensuring code quality. If you'd like, you can install a [Git hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) -that will automatically run `x.py test tidy --bless` on each commit, to ensure +that will automatically run `./x.py test tidy --bless` on each commit, to ensure your code is up to par. If you decide later that this behavior is undesirable, you can delete the `pre-commit` file in `.git/hooks`. A prebuilt git hook lives at [`src/etc/pre-commit.sh`](https://github.com/rust-lang/rust/blob/master/src/etc/pre-commit.sh) which can be copied into your `.git/hooks` folder as `pre-commit` (without the `.sh` extension!). -You can also install the hook as a step of running `x.py setup`! +You can also install the hook as a step of running `./x.py setup`! ## Configuring `rust-analyzer` for `rustc` @@ -43,7 +43,7 @@ you can write: July 2021) a [bug][#77620] if you use -worktrees, submodules, and x.py in a commit hook. If you run into an error +worktrees, submodules, and `x.py` in a commit hook. If you run into an error like: ``` diff --git a/src/profiling.md b/src/profiling.md index 4851e3ee9..fd7014224 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -44,7 +44,7 @@ extension in LLVM bitcode format. Example usage: ``` cargo install cargo-llvm-lines -# On a normal crate you could now run `cargo llvm-lines`, but x.py isn't normal :P +# On a normal crate you could now run `cargo llvm-lines`, but `x.py` isn't normal :P # Do a clean before every run, to not mix in the results from previous runs. ./x.py clean @@ -88,7 +88,7 @@ Example output for the compiler: 326903 (0.7%) 642 (0.0%) rustc_query_system::query::plumbing::try_execute_query ``` -Since this doesn't seem to work with incremental compilation or `x.py check`, +Since this doesn't seem to work with incremental compilation or `./x.py check`, you will be compiling rustc _a lot_. I recommend changing a few settings in `config.toml` to make it bearable: ``` diff --git a/src/tests/intro.md b/src/tests/intro.md index 3f8ec97ee..25c1d059c 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -3,7 +3,7 @@ The Rust project runs a wide variety of different tests, orchestrated by -the build system (`x.py test`). The main test harness for testing the +the build system (`./x.py test`). The main test harness for testing the compiler itself is a tool called compiletest (located in the [`src/tools/compiletest`] directory). This section gives a brief overview of how the testing framework is setup, and then gets into some diff --git a/src/tests/running.md b/src/tests/running.md index 19925fe27..2e1ce0a91 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -49,7 +49,7 @@ with the debuginfo test suite: ``` If you only need to test a specific subdirectory of tests for any -given test suite, you can pass that directory to `x.py test`: +given test suite, you can pass that directory to `./x.py test`: ```bash ./x.py test src/test/ui/const-generics From 766f9d7b10383b6af37bb24683dad2e86bb8a72f Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 16 Nov 2021 22:43:17 +0900 Subject: [PATCH 1583/1812] Fix broken links related to `rustc_borrowck` (#1259) * Fix broken links in region_inference.md * Fix broken links in lifetime_parameters.md --- src/borrow_check/region_inference.md | 32 +++++++++---------- .../region_inference/lifetime_parameters.md | 12 +++---- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index e14bc4157..cfb32bf07 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -5,7 +5,7 @@ The MIR-based region checking code is located in [the `rustc_mir::borrow_check` module][nll]. -[nll]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/index.html +[nll]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/index.html The MIR-based region analysis consists of two major functions: @@ -38,10 +38,10 @@ The MIR-based region analysis consists of two major functions: [cp]: ./region_inference/constraint_propagation.md [fvb]: ../appendix/background.md#free-vs-bound -[`replace_regions_in_mir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.replace_regions_in_mir.html -[`compute_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/nll/fn.compute_regions.html -[`RegionInferenceContext`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html -[`solve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.solve +[`replace_regions_in_mir`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/nll/fn.replace_regions_in_mir.html +[`compute_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/nll/fn.compute_regions.html +[`RegionInferenceContext`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html +[`solve`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.solve [NLL RFC]: https://rust-lang.github.io/rfcs/2094-nll.html [MIR type checker]: ./type_check.md @@ -68,7 +68,7 @@ the moment. TODO: write about _how_ these regions are computed. -[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/universal_regions/struct.UniversalRegions.html +[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/universal_regions/struct.UniversalRegions.html @@ -115,7 +115,7 @@ common sorts of constraints are: 2. Liveness constraints. Each region needs to be live at points where it can be used. These constraints are collected by [`generate_constraints`]. -[`generate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/constraint_generation/fn.generate_constraints.html +[`generate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/constraint_generation/fn.generate_constraints.html ## Inference Overview @@ -219,13 +219,13 @@ Here are some of the fields of the struct: - [`closure_bounds_mapping`]: used for propagating region constraints from closures back out to the creator of the closure. -[`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.constraints -[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints +[`constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#structfield.constraints +[`liveness_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#structfield.liveness_constraints [`location`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Location.html -[`universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_regions -[`universal_region_relations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.universal_region_relations -[`type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.type_tests -[`closure_bounds_mapping`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#structfield.closure_bounds_mapping +[`universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#structfield.universal_regions +[`universal_region_relations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#structfield.universal_region_relations +[`type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#structfield.type_tests +[`closure_bounds_mapping`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#structfield.closure_bounds_mapping TODO: should we discuss any of the others fields? What about the SCCs? @@ -234,6 +234,6 @@ inference. This is done by calling the [`solve`] method on the context. This is where we call [`propagate_constraints`] and then check the resulting type tests and universal regions, as discussed above. -[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints -[`check_type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.check_type_tests -[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/borrow_check/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions +[`propagate_constraints`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.propagate_constraints +[`check_type_tests`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.check_type_tests +[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index 369ce2d3d..2dbbc0c1e 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -31,9 +31,9 @@ relationships to one another. So if you have e.g. `where 'a: 'b`, then the [`UniversalRegionRelations`] struct would track that `'a: 'b` is known to hold (which could be tested with the [`outlives`] function. -[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/universal_regions/struct.UniversalRegions.html -[`UniversalRegionRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/type_check/free_region_relations/struct.UniversalRegionRelations.html -[`outlives`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/type_check/free_region_relations/struct.UniversalRegionRelations.html#method.outlives +[`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/universal_regions/struct.UniversalRegions.html +[`UniversalRegionRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/type_check/free_region_relations/struct.UniversalRegionRelations.html +[`outlives`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/type_check/free_region_relations/struct.UniversalRegionRelations.html#method.outlives ## Everything is a region variable @@ -58,7 +58,7 @@ type). These subdivisions are not important for the topics discussed here, but become important when we consider [closure constraint propagation](./closure_constraints.html), so we discuss them there. -[`RegionClassification`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/universal_regions/enum.RegionClassification.html#variant.Local +[`RegionClassification`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/universal_regions/enum.RegionClassification.html#variant.Local ## Universal lifetimes as the elements of a region's value @@ -88,7 +88,7 @@ liveness constraint (i.e., `'a` must extend until the end of itself). In the code, these liveness constraints are setup in [`init_free_and_bound_regions`]. -[`init_free_and_bound_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/region_infer/struct.RegionInferenceContext.html#method.init_free_and_bound_regions +[`init_free_and_bound_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.init_free_and_bound_regions ## Propagating outlives constraints for universal regions @@ -124,4 +124,4 @@ not, as in our example, that is an error. This check is done in the universal regions, inspects their final value, and tests against the declared [`UniversalRegionRelations`]. -[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_borrowck/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions +[`check_universal_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/region_infer/struct.RegionInferenceContext.html#method.check_universal_regions From 5fbfe9363d8b1bc3ae7d0e66306fdae99040524f Mon Sep 17 00:00:00 2001 From: Ken Matsui <26405363+ken-matsui@users.noreply.github.com> Date: Tue, 16 Nov 2021 22:45:40 +0900 Subject: [PATCH 1584/1812] Fix an invalid link on Diagnostic Items (#1261) --- src/diagnostics/diagnostic-items.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/diagnostics/diagnostic-items.md b/src/diagnostics/diagnostic-items.md index efaa01cf3..93a0194d9 100644 --- a/src/diagnostics/diagnostic-items.md +++ b/src/diagnostics/diagnostic-items.md @@ -23,7 +23,7 @@ struct Penguin; Diagnostic items are usually only added to traits, types and standalone functions. If the goal is to check for an associated type or method, please use the diagnostic item of the item and -reference [*Using Diagnostic Items*](#using-diagnostic-items). +reference [*How To Use Diagnostic Items*](#how-to-use-diagnostic-items). ## How To Add Diagnostic Items From a2fc9635029c04e692474965a6606f8e286d539a Mon Sep 17 00:00:00 2001 From: Dylan MacKenzie Date: Thu, 18 Nov 2021 10:31:13 -0800 Subject: [PATCH 1585/1812] Describe drop elaboration (#1240) --- src/SUMMARY.md | 1 + src/mir/drop-elaboration.md | 195 ++++++++++++++++++++++++++++++++++++ 2 files changed, 196 insertions(+) create mode 100644 src/mir/drop-elaboration.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b7b6d8bd1..411387ab6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -116,6 +116,7 @@ - [Opaque Types](./opaque-types-type-alias-impl-trait.md) - [Pattern and Exhaustiveness Checking](./pat-exhaustive-checking.md) - [MIR dataflow](./mir/dataflow.md) +- [Drop elaboration](./mir/drop-elaboration.md) - [The borrow checker](./borrow_check.md) - [Tracking moves and initialization](./borrow_check/moves_and_initialization.md) - [Move paths](./borrow_check/moves_and_initialization/move_paths.md) diff --git a/src/mir/drop-elaboration.md b/src/mir/drop-elaboration.md new file mode 100644 index 000000000..20b92cc45 --- /dev/null +++ b/src/mir/drop-elaboration.md @@ -0,0 +1,195 @@ +# Drop elaboration + + + +## Dynamic drops + +According to the [reference][reference-drop]: + +> When an initialized variable or temporary goes out of scope, its destructor +> is run, or it is dropped. Assignment also runs the destructor of its +> left-hand operand, if it's initialized. If a variable has been partially +> initialized, only its initialized fields are dropped. + +When building the MIR, the `Drop` and `DropAndReplace` terminators represent +places where drops may occur. However, in this phase, the presence of these +terminators does not guarantee that a destructor will run. That's because the +target of a drop may be uninitialized (usually because it has been moved from) +before the terminator is reached. In general, we cannot know at compile-time whether a +variable is initialized. + +```rust +let mut y = vec![]; + +{ + let x = vec![1, 2, 3]; + if std::process::id() % 2 == 0 { + y = x; // conditionally move `x` into `y` + } +} // `x` goes out of scope here. Should it be dropped? +``` + +In these cases, we need to keep track of whether a variable is initialized +*dynamically*. The rules are laid out in detail in [RFC 320: Non-zeroing +dynamic drops][RFC 320]. + +## Drop obligations + +From the RFC: + +> When a local variable becomes initialized, it establishes a set of "drop +> obligations": a set of structural paths (e.g. a local `a`, or a path to a +> field `b.f.y`) that need to be dropped. +> +> The drop obligations for a local variable x of struct-type `T` are computed +> from analyzing the structure of `T`. If `T` itself implements `Drop`, then `x` is a +> drop obligation. If `T` does not implement `Drop`, then the set of drop +> obligations is the union of the drop obligations of the fields of `T`. + +When a structural path is moved from (and thus becomes uninitialized), any drop +obligations for that path or its descendants (`path.f`, `path.f.g.h`, etc.) are +released. Types with `Drop` implementations do not permit moves from individual +fields, so there is no need to track initializedness through them. + +When a local variable goes out of scope (`Drop`), or when a structural path is +overwritten via assignment (`DropAndReplace`), we check for any drop +obligations for that variable or path. Unless that obligation has been +released by this point, its associated `Drop` implementation will be called. +For `enum` types, only fields corresponding to the "active" variant need to be +dropped. When processing drop obligations for such types, we first check the +discriminant to determine the active variant. All drop obligations for variants +besides the active one are ignored. + +Here are a few interesting types to help illustrate these rules: + +```rust +struct NoDrop(u8); // No `Drop` impl. No fields with `Drop` impls. + +struct NeedsDrop(Vec); // No `Drop` impl but has fields with `Drop` impls. + +struct ThinVec(*const u8); // Custom `Drop` impl. Individual fields cannot be moved from. + +impl Drop for ThinVec { + fn drop(&mut self) { /* ... */ } +} + +enum MaybeDrop { + Yes(NeedsDrop), + No(NoDrop), +} +``` + +## Drop elaboration + +One valid model for these rules is to keep a boolean flag (a "drop flag") for +every structural path that is used at any point in the function. This flag is +set when its path is initialized and is cleared when the path is moved from. +When a `Drop` occurs, we check the flags for every obligation associated with +the target of the `Drop` and call the associated `Drop` impl for those that are +still applicable. + +This process—transforming the newly built MIR with its imprecise `Drop` and +`DropAndReplace` terminators into one with drop flags—is known as drop +elaboration. When a MIR statement causes a variable to become initialized (or +uninitialized), drop elaboration inserts code that sets (or clears) the drop +flag for that variable. It wraps `Drop` terminators in conditionals that check +the newly inserted drop flags. + +Drop elaboration also splits `DropAndReplace` terminators into a `Drop` of the +target and a write of the newly dropped place. This is somewhat unrelated to what +we've discussed above. + +Once this is complete, `Drop` terminators in the MIR correspond to a call to +the "drop glue" or "drop shim" for the type of the dropped place. The drop +glue for a type calls the `Drop` impl for that type (if one exists), and then +recursively calls the drop glue for all fields of that type. + +## Drop elaboration in `rustc` + +The approach described above is more expensive than necessary. One can imagine +a few optimizations: + +- Only paths that are the target of a `Drop` (or have the target as a prefix) + need drop flags. +- Some variables are known to initialized (or uninitialized) when they are + dropped. These do not need drop flags. +- If a set of paths are only dropped or moved from via a shared prefix, those + paths can share a single drop flag. + +A subset of these are implemented in `rustc`. + +In the compiler, drop elaboration is split across several modules. The pass +itself is defined [here][drops-transform], but the [main logic][drops] is +defined elsewhere since it is also used to build [drop shims][drops-shim]. + +Drop elaboration designates each `Drop` in the newly built MIR as one of four +kinds: + +- `Static`, the target is always initialized. +- `Dead`, the target is always **un**initialized. +- `Conditional`, the target is either wholly initialized or wholly + uninitialized. It is not partly initialized. +- `Open`, the target may be partly initialized. + +For this, it uses a pair of dataflow analyses, `MaybeInitializedPlaces` and +`MaybeUninitializedPlaces`. If a place is in one but not the other, then the +initializedness of the target is known at compile-time (`Dead` or `Static`). +In this case, drop elaboration does not add a flag for the target. It simply +removes (`Dead`) or preserves (`Static`) the `Drop` terminator. + +For `Conditional` drops, we know that the initializedness of the variable as a +whole is the same as the initializedness of its fields. Therefore, once we +generate a drop flag for the target of that drop, it's safe to call the drop +glue for that target. + +### `Open` drops + +`Open` drops are the most complex, since we need to break down a single `Drop` +terminator into several different ones, one for each field of the target whose +type has drop glue (`Ty::needs_drop`). We cannot call the drop glue for the +target itself because that requires all fields of the target to be initialized. +Remember, variables whose type has a custom `Drop` impl do not allow `Open` +drops because their fields cannot be moved from. + +This is accomplished by recursively categorizing each field as `Dead`, +`Static`, `Conditional` or `Open`. Fields whose type does not have drop glue +are automatically `Dead` and need not be considered during the recursion. When +we reach a field whose kind is not `Open`, we handle it as we did above. If the +field is also `Open`, the recursion continues. + +It's worth noting how we handle `Open` drops of enums. Inside drop elaboration, +each variant of the enum is treated like a field, with the invariant that only +one of those "variant fields" can be initialized at any given time. In the +general case, we do not know which variant is the active one, so we will have +to call the drop glue for the enum (which checks the discriminant) or check the +discriminant ourselves as part of an elaborated `Open` drop. However, in +certain cases (within a `match` arm, for example) we do know which variant of +an enum is active. This information is encoded in the `MaybeInitializedPlaces` +and `MaybeUninitializedPlaces` dataflow analyses by marking all places +corresponding to inactive variants as uninitialized. + +### Cleanup paths + +TODO: Discuss drop elaboration and unwinding. + +## Aside: drop elaboration and const-eval + +In Rust, functions that are eligible for evaluation at compile-time must be +marked explicitly using the `const` keyword. This includes implementations of +the `Drop` trait, which may or may not be `const`. Code that is eligible for +compile-time evaluation may only call `const` functions, so any calls to +non-const `Drop` implementations in such code must be forbidden. + +A call to a `Drop` impl is encoded as a `Drop` terminator in the MIR. However, +as we discussed above, a `Drop` terminator in newly built MIR does not +necessarily result in a call to `Drop::drop`. The drop target may be +uninitialized at that point. This means that checking for non-const `Drop`s on +the newly built MIR can result in spurious errors. Instead, we wait until after +drop elaboration runs, which eliminates `Dead` drops (ones where the target is +known to be uninitialized) to run these checks. + +[RFC 320]: https://rust-lang.github.io/rfcs/0320-nonzeroing-dynamic-drop.html +[reference-drop]: https://doc.rust-lang.org/reference/destructors.html +[drops]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_dataflow/src/elaborate_drops.rs +[drops-shim]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_transform/src/shim.rs +[drops-transform]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_dataflow/src/elaborate_drops.rs From 6a27fc22f101d832afe21625b6181461b30d9340 Mon Sep 17 00:00:00 2001 From: Simon Perriard Date: Wed, 24 Nov 2021 10:03:36 +0100 Subject: [PATCH 1586/1812] make it compile with 1.56.0 --- examples/rustc-driver-example.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/rustc-driver-example.rs b/examples/rustc-driver-example.rs index 51af6f5aa..29fa24784 100644 --- a/examples/rustc-driver-example.rs +++ b/examples/rustc-driver-example.rs @@ -73,7 +73,7 @@ fn main() { println!("{:#?}", parse); // Analyze the program and inspect the types of definitions. queries.global_ctxt().unwrap().take().enter(|tcx| { - for (_, item) in &tcx.hir().krate().items { + for item in tcx.hir().items() { match item.kind { rustc_hir::ItemKind::Static(_, _, _) | rustc_hir::ItemKind::Fn(_, _, _) => { let name = item.ident; From 1f0c4f08f133a000dfe279168a162209f8f79533 Mon Sep 17 00:00:00 2001 From: Simon Perriard Date: Wed, 24 Nov 2021 10:07:12 +0100 Subject: [PATCH 1587/1812] make it compile with 1.56.0 --- examples/rustc-driver-interacting-with-the-ast.rs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/examples/rustc-driver-interacting-with-the-ast.rs b/examples/rustc-driver-interacting-with-the-ast.rs index 2c7533498..cbf48c9ce 100644 --- a/examples/rustc-driver-interacting-with-the-ast.rs +++ b/examples/rustc-driver-interacting-with-the-ast.rs @@ -64,9 +64,9 @@ fn main() { // Analyze the crate and inspect the types under the cursor. queries.global_ctxt().unwrap().take().enter(|tcx| { // Every compilation contains a single crate. - let hir_krate = tcx.hir().krate(); + let hir_krate = tcx.hir(); // Iterate over the top-level items in the crate, looking for the main function. - for (_, item) in &hir_krate.items { + for item in hir_krate.items() { // Use pattern-matching to find a specific node inside the main function. if let rustc_hir::ItemKind::Fn(_, _, body_id) = item.kind { let expr = &tcx.hir().body(body_id).value; From 94e9e679ebb05ae0511fd4579ada3613aa604f79 Mon Sep 17 00:00:00 2001 From: Simon Perriard Date: Wed, 24 Nov 2021 10:19:29 +0100 Subject: [PATCH 1588/1812] make it compile with 1.56.0 no warning --- examples/rustc-driver-getting-diagnostics.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/rustc-driver-getting-diagnostics.rs b/examples/rustc-driver-getting-diagnostics.rs index ee9a20c05..d1b42658e 100644 --- a/examples/rustc-driver-getting-diagnostics.rs +++ b/examples/rustc-driver-getting-diagnostics.rs @@ -81,7 +81,7 @@ fn main() { compiler.enter(|queries| { queries.global_ctxt().unwrap().take().enter(|tcx| { // Run the analysis phase on the local crate to trigger the type error. - tcx.analysis(rustc_hir::def_id::LOCAL_CRATE); + let _ = tcx.analysis(()); }); }); }); From 285b3e4410078108b6bf7011c932ba267efa29d4 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 4 Nov 2021 11:09:14 -0700 Subject: [PATCH 1589/1812] Document more compiletest headers. --- src/tests/adding.md | 48 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index 34bd6f20e..3d67a5390 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -214,9 +214,57 @@ source. * `error-pattern` checks the diagnostics just like the `ERROR` annotation without specifying error line. This is useful when the error doesn't give any span. +* `incremental` runs the test with the `-C incremental` flag and an empty + incremental directory. This should be avoided when possible; you should use + an *incremental mode* test instead. Incremental mode tests support running + the compiler multiple times and verifying that it can load the generated + incremental cache. This flag is for specialized circumstances, like checking + the interaction of codegen unit partitioning with generating an incremental + cache. +* `aux-build` is used to compile additional crates to link. Just pass it the + name of the source file. The source file should be in a directory called + `auxiliary` beside the test file. The aux crate will be built as a dylib if + possible (unless on a platform that does not support them, or + `no-prefer-dynamic` is specified in the aux file). The `-L` flag is used to + find the extern crates. +* `aux-crate` is very similar to `aux-build`, however it uses the `--extern` + flag to link to the extern crate. That allows you to specify the additional + syntax of the `--extern` flag, such as renaming a dependency. For example, + `// aux-crate:foo=bar.rs` will compile `auxiliary/bar.rs` and add make it + available under then name `foo` within the test. This is similar to how + Cargo does dependency renaming. +* `no-prefer-dynamic` will force an auxiliary crate to be built as an rlib + instead of a dylib. When specified in a test, it will remove the use of `-C + prefer-dynamic`. This can be useful in a variety of circumstances. For + example, it can prevent a proc-macro from being built with the wrong crate + type. Or if your test is specifically targeting behavior of other crate + types, it can be used to prevent building with the wrong crate type. +* `force-host` will force the test to build for the host platform instead of + the target. This is useful primarily for auxiliary proc-macros, which need + to be loaded by the host compiler. +* `pretty-mode` for pretty-print tests specifies the mode it should run in. + The default is `normal` if not specified. +* `pretty-compare-only` causes a pretty test to only compare the + pretty-printed output. It will not try to compile the expanded output to + typecheck it. This is needed for a pretty-mode that does not expand to valid + rust, or for other situations where the expanded output cannot be compiled. +* `pretty-expanded` allows a pretty test to also run with + `-Zunpretty=expanded` as a final step, and will also try to compile the + resulting output (without codegen). This is needed because not all code can + be compiled after being expanded. Pretty tests should specify this if they + can. More history about this may be found in [#23616]. +* `pp-exact` is used to ensure a pretty-print test results in specific output. + If specified without a value, then it means the pretty-print output should + match the original source. If specified with a value, as in `// + pp-exact:foo.pp`, will ensure that that pretty-printed output matches the + contents of the given file. Otherwise, if `pp-exact` is not specified, then + the pretty-printed output will be pretty-printed one more time, and the + output of the two pretty-printing rounds will be compared to ensure that the + pretty-printed output converges to a steady state. [`header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs [bless]: ./running.md#editing-and-updating-the-reference-files +[#23616]: https://github.com/rust-lang/rust/issues/23616#issuecomment-484999901 From 9660c153fed4051fac353bf6e6822af80ccdccf5 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 4 Nov 2021 20:31:39 -0700 Subject: [PATCH 1590/1812] Apply suggestions from pierwill Co-authored-by: pierwill <19642016+pierwill@users.noreply.github.com> --- src/tests/adding.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index 3d67a5390..7e8ff9e98 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -242,14 +242,14 @@ source. * `force-host` will force the test to build for the host platform instead of the target. This is useful primarily for auxiliary proc-macros, which need to be loaded by the host compiler. -* `pretty-mode` for pretty-print tests specifies the mode it should run in. +* `pretty-mode` specifies the mode pretty-print tests should run in. The default is `normal` if not specified. * `pretty-compare-only` causes a pretty test to only compare the pretty-printed output. It will not try to compile the expanded output to typecheck it. This is needed for a pretty-mode that does not expand to valid - rust, or for other situations where the expanded output cannot be compiled. + Rust, or for other situations where the expanded output cannot be compiled. * `pretty-expanded` allows a pretty test to also run with - `-Zunpretty=expanded` as a final step, and will also try to compile the + `-Zunpretty=expanded` as a final step. It will also try to compile the resulting output (without codegen). This is needed because not all code can be compiled after being expanded. Pretty tests should specify this if they can. More history about this may be found in [#23616]. From aaf6ccc951c801338af2aff6ac3bffafd2db613f Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 5 Nov 2021 07:15:03 -0700 Subject: [PATCH 1591/1812] Document rustfix-only-machine-applicable --- src/tests/adding.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/tests/adding.md b/src/tests/adding.md index 7e8ff9e98..f99363a35 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -169,6 +169,11 @@ source. source is compiled, and this compilation is required to succeed. The `.fixed` file can also be generated automatically with the `--bless` option, described in [this section][bless]. +* `rustfix-only-machine-applicable` is equivalent to `run-rustfix` except it + will only apply [`MachineApplicable`](../diagnostics.md#suggestions) + suggestions. `run-rustfix` will apply *all* suggestions. This should be used + if there is a mixture of different suggestion levels, and some of the + non-machine-applicable ones do not apply cleanly. * `min-gdb-version` specifies the minimum gdb version required for this test; see also `ignore-gdb-version` * `min-lldb-version` specifies the minimum lldb version required for From 8a817bc6ca7769f7c362e4f368f05d9ff7c9d107 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 19 Nov 2021 13:54:01 -0800 Subject: [PATCH 1592/1812] Update for review comments. --- src/tests/adding.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/tests/adding.md b/src/tests/adding.md index f99363a35..d7ad2871d 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -232,10 +232,10 @@ source. possible (unless on a platform that does not support them, or `no-prefer-dynamic` is specified in the aux file). The `-L` flag is used to find the extern crates. -* `aux-crate` is very similar to `aux-build`, however it uses the `--extern` +* `aux-crate` is very similar to `aux-build`; however, it uses the `--extern` flag to link to the extern crate. That allows you to specify the additional syntax of the `--extern` flag, such as renaming a dependency. For example, - `// aux-crate:foo=bar.rs` will compile `auxiliary/bar.rs` and add make it + `// aux-crate:foo=bar.rs` will compile `auxiliary/bar.rs` and make it available under then name `foo` within the test. This is similar to how Cargo does dependency renaming. * `no-prefer-dynamic` will force an auxiliary crate to be built as an rlib @@ -257,11 +257,16 @@ source. `-Zunpretty=expanded` as a final step. It will also try to compile the resulting output (without codegen). This is needed because not all code can be compiled after being expanded. Pretty tests should specify this if they - can. More history about this may be found in [#23616]. + can. An example where this cannot be used is if the test includes + `println!`. That macro expands to reference private internal functions of + the standard library that cannot be called directly without the + `fmt_internals` feature gate. + + More history about this may be found in [#23616]. * `pp-exact` is used to ensure a pretty-print test results in specific output. If specified without a value, then it means the pretty-print output should match the original source. If specified with a value, as in `// - pp-exact:foo.pp`, will ensure that that pretty-printed output matches the + pp-exact:foo.pp`, it will ensure that the pretty-printed output matches the contents of the given file. Otherwise, if `pp-exact` is not specified, then the pretty-printed output will be pretty-printed one more time, and the output of the two pretty-printing rounds will be compared to ensure that the From c4776cb94ad4c37bbc2d9ae5672095d1b547cc23 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 16 Nov 2021 08:36:33 +0900 Subject: [PATCH 1593/1812] Fix some links --- src/backend/libs-and-metadata.md | 5 ++--- src/building/bootstrapping.md | 2 +- src/constants.md | 2 +- 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/backend/libs-and-metadata.md b/src/backend/libs-and-metadata.md index d2cf8b692..5e005c965 100644 --- a/src/backend/libs-and-metadata.md +++ b/src/backend/libs-and-metadata.md @@ -107,12 +107,11 @@ The hash includes a variety of elements: Disambiguator](#crate-disambiguator), and all CLI options marked with `[TRACKED]`). -See [`finalize_and_compute_crate_hash`] for where the hash is actually -computed. +See [`compute_hir_hash`] for where the hash is actually computed. [SVH]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/svh/struct.Svh.html [incremental compilation]: ../queries/incremental-compilation.md -[`finalize_and_compute_crate_hash`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/collector/struct.NodeCollector.html#method.finalize_and_compute_crate_hash +[`compute_hir_hash`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_lowering/struct.LoweringContext.html#method.compute_hir_hash ### Stable Crate Id diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index fc1ad6c00..460776e51 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -56,7 +56,7 @@ because one must first build the new compiler with an older compiler and then use that to build the new compiler with itself. For development, you usually only want the `stage1` compiler, which you can build with `./x.py build library/std`. -See [Building the Compiler](/building/how-to-build-and-run.html#building-the-compiler). +See [Building the Compiler](./how-to-build-and-run.html#building-the-compiler). ### Stage 3 diff --git a/src/constants.md b/src/constants.md index 137351c22..30c0da736 100644 --- a/src/constants.md +++ b/src/constants.md @@ -39,7 +39,7 @@ why the array length in `foo() -> [u8; N + 1]` can use `N`. Without any manual adjustments, this causes us to include parameters even if the constant doesn't use them in any way. This can cause -[some interesting errors](pcg-unused-substs) and breaks some already stable code. +[some interesting errors][pcg-unused-substs] and breaks some already stable code. To deal with this, we intend to look at the generic parameters explicitly mentioned by the constants and then search the predicates of its parents to figure out which From 2cee5a9be85bd192603e2bd25e26ed40e7aeff28 Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Sat, 27 Nov 2021 16:28:44 +1100 Subject: [PATCH 1594/1812] Improve 'Running tests manually' section --- src/building/how-to-build-and-run.md | 5 +++++ src/tests/running.md | 6 ++++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 981bb6e50..ae3aabf12 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -212,6 +212,11 @@ host: x86_64-unknown-linux-gnu release: 1.48.0-dev LLVM version: 11.0 ``` + +The rustup toolchain points to the specified toolchain compiled in your `build` directory, +so the rustup toolchain will be updated whenever `x.py build` or `x.py test` are run for +that toolchain/stage. + ## Other `x.py` commands Here are a few other useful `x.py` commands. We'll cover some of them in detail diff --git a/src/tests/running.md b/src/tests/running.md index 2e1ce0a91..c91a27bf2 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -200,8 +200,10 @@ however compare-modes must be manually run individually via the `--compare-mode` ## Running tests manually -Sometimes it's easier and faster to just run the test by hand. Most tests are -just `rs` files, so you can do something like +Sometimes it's easier and faster to just run the test by hand. +Most tests are just `rs` files, so after +[creating a rustup toolchain](/building/how-to-build-and-run.html#creating-a-rustup-toolchain), +you can do something like: ```bash rustc +stage1 src/test/ui/issue-1234.rs From a374e7d8bb6b79de45b92295d06b4ac0ef35bc09 Mon Sep 17 00:00:00 2001 From: Rich Kadel Date: Fri, 3 Dec 2021 09:26:47 -0800 Subject: [PATCH 1595/1812] Update LLVM coverage mapping format version supported by rustc (#1267) rust-lang/rust#91207 updates the coverage mapping format to Version 5 or 6, depending on the built-in version of LLVM (12 or 13, respectively). This change updates the dev guide to match the recent changes. --- src/llvm-coverage-instrumentation.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 4a0f53bfa..cb3be57ac 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -221,17 +221,15 @@ substitution combinations), `mapgen`'s `finalize()` method queries the and `CodeRegion`s; and calls LLVM codegen APIs to generate properly-configured variables in LLVM IR, according to very specific details of the [_LLVM Coverage Mapping Format_][coverage-mapping-format] -(Version 4).[^llvm-and-covmap-versions] - -[^llvm-and-covmap-versions]: The Rust compiler (as of -January 2021) supports _LLVM Coverage Mapping Format_ Version 4 (the most -up-to-date version of the format, at the time of this writing) for improved -compatibility with other LLVM-based compilers (like _Clang_), and to take -advantage of some format optimizations. Version 4 was introduced in _LLVM 11_, -which is currently the default LLVM version for Rust. Note that the Rust -compiler optionally supports some earlier LLVM versions, prior to _LLVM 11_. If -`rustc` is configured to use an incompatible version of LLVM, compiling with `-Z -instrument-coverage` will generate an error message. +(Version 6).[^llvm-and-covmap-versions] + +[^llvm-and-covmap-versions]: The Rust compiler (as of +December 2021) supports _LLVM Coverage Mapping Format_ Version 5 or 6. Version 5 +was introduced in _LLVM 12_, which is (as of this writing) the minimum LLVM +version supported by the current version of Rust. Version 6 was introduced in +_LLVM 13_, which is currently the default LLVM version for Rust. The Rust +compiler will automatically use the most up-to-date coverage mapping format +version that is compatible with the compiler's built-in version of LLVM. ```rust pub fn finalize<'ll, 'tcx>(cx: &CodegenCx<'ll, 'tcx>) { From 3df5cc9fe52ac4607816dde091ed2bc7158b5878 Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Sun, 5 Dec 2021 20:58:33 +1100 Subject: [PATCH 1596/1812] Improve documentation on r? --- src/contributing.md | 17 ++++++++++++++++- src/getting-started.md | 12 ++++++------ src/walkthrough.md | 2 +- 3 files changed, 23 insertions(+), 8 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 6be8802c7..9c22fab9a 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -70,9 +70,11 @@ when contributing to Rust under [the git section](./git.md). [about-pull-requests]: https://help.github.com/articles/about-pull-requests/ [development-models]: https://help.github.com/articles/about-collaborative-development-models/ +### r? + All pull requests are reviewed by another person. We have a bot, [@rust-highfive][rust-highfive], that will automatically assign a random person -to review your request. +to review your request based on which files you changed. If you want to request that a specific person reviews your pull request, you can add an `r?` to the pull request description. For example, @@ -84,6 +86,17 @@ make a documentation change, add to the end of the pull request description, and [@rust-highfive][rust-highfive] will assign [@steveklabnik][steveklabnik] instead of a random person. This is entirely optional. +You can also assign a random reviewer from a specific team by writing `r? rust-lang/groupname`. +So if you were making a diagnostics change, then you could get a reviewer from the diagnostics +team by adding: + + r? rust-lang/diagnostics + +For a full list of possible `groupname` check the `groups` section at the +[rust highfive config file](https://github.com/rust-lang/highfive/blob/master/highfive/configs/rust-lang/rust.json). + +### CI + In addition to being reviewed by a human, pull requests are automatically tested thanks to continuous integration (CI). Basically, every time you open and update a pull request, CI builds the compiler and tests it against the @@ -100,6 +113,8 @@ computational resources each time you push a change. It is also perfectly fine productivity. In particular, we don't recommend running the full `./x.py test` suite locally, since it takes a very long time to execute. +### r+ + After someone has reviewed your pull request, they will leave an annotation on the pull request with an `r+`. It will look something like this: diff --git a/src/getting-started.md b/src/getting-started.md index f8273d631..c150849f8 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -387,7 +387,6 @@ incredibly helpful: [wd]: ./contributing.md#writing-documentation [wg]: https://rust-lang.github.io/compiler-team/working-groups/ - ## Contributor Procedures There are some official procedures to know about. This is a tour of the @@ -396,11 +395,12 @@ highlights, but there are a lot more details, which we will link to below. ### Code Review When you open a PR on the `rust-lang/rust` repo, a bot called `@rust-highfive` will -automatically assign a reviewer to the PR. The reviewer is the person that will -approve the PR to be tested and merged. If you want a specific reviewer (e.g. a -team member you've been working with), you can specifically request them by -writing `r? @user` (e.g. `r? @eddyb`) in either the original post or a followup -comment (you can see [this comment][r?] for example). +automatically assign a reviewer to the PR based on which files you changed. +The reviewer is the person that will approve the PR to be tested and merged. +If you want a specific reviewer (e.g. a team member you've been working with), +you can specifically request them by writing `r? @user` (e.g. `r? @eddyb`) in +either the original post or a followup comment +(you can see [this comment][r?] for example). Please note that the reviewers are humans, who for the most part work on `rustc` in their free time. This means that they can take some time to respond and review diff --git a/src/walkthrough.md b/src/walkthrough.md index 5841afe4f..8f5dc525e 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -184,7 +184,7 @@ When you open a PR on the [rust-lang/rust], a bot will assign your PR to a review. If there is a particular rust team member you are working with, you can request that reviewer by leaving a comment on the thread with `r? @reviewer-github-id` (e.g. `r? @eddyb`). If you don't know who to request, -don't request anyone; the bot will assign someone automatically. +don't request anyone; the bot will assign someone automatically based on which files you changed. The reviewer may request changes before they approve your PR. Feel free to ask questions or discuss things you don't understand or disagree with. However, From 0c0e4f2e447057f283226304c5a85bfb5f747af2 Mon Sep 17 00:00:00 2001 From: Lucas Kent Date: Tue, 7 Dec 2021 13:15:13 +1100 Subject: [PATCH 1597/1812] Update src/getting-started.md Co-authored-by: Joshua Nelson --- src/getting-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/getting-started.md b/src/getting-started.md index c150849f8..a2f507e76 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -398,7 +398,7 @@ When you open a PR on the `rust-lang/rust` repo, a bot called `@rust-highfive` w automatically assign a reviewer to the PR based on which files you changed. The reviewer is the person that will approve the PR to be tested and merged. If you want a specific reviewer (e.g. a team member you've been working with), -you can specifically request them by writing `r? @user` (e.g. `r? @eddyb`) in +you can specifically request them by writing `r? @user` (e.g. `r? @jyn514`) in either the original post or a followup comment (you can see [this comment][r?] for example). From 6c1f5c780b3ac6ec3404cf49991dfc9a9bdb6103 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sat, 4 Dec 2021 17:59:42 -0800 Subject: [PATCH 1598/1812] Fix some broken links --- src/mir/optimizations.md | 4 ++-- src/profiling.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index 9ecf4e0d3..add22c6fc 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -85,7 +85,7 @@ The array is an array of `&dyn MirPass` trait objects. Typically, a pass is implemented in its own module of the [`rustc_mir_transform`][trans] crate. [rop]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/fn.run_optimization_passes.html -[`MirPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/trait.MirPass.html +[`MirPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/trait.MirPass.html [trans]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/index.html Some examples of passes are: @@ -95,7 +95,7 @@ Some examples of passes are: You can see the ["Implementors" section of the `MirPass` rustdocs][impl] for more examples. -[impl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/trait.MirPass.html#implementors +[impl]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/trait.MirPass.html#implementors [constprop]: https://en.wikipedia.org/wiki/Constant_folding#Constant_propagation ## MIR optimization levels diff --git a/src/profiling.md b/src/profiling.md index fd7014224..8db30b253 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -12,7 +12,7 @@ Depending on what you're trying to measure, there are several different approach - If you want a medium-to-high level overview of where `rustc` is spending its time: - The `-Z self-profile` flag and [measureme](https://github.com/rust-lang/measureme) tools offer a query-based approach to profiling. - See [their docs](https://github.com/rust-lang/measureme/blob/master/summarize/Readme.md) for more information. + See [their docs](https://github.com/rust-lang/measureme/blob/master/summarize/README.md) for more information. - If you want function level performance data or even just more details than the above approaches: - Consider using a native code profiler such as [perf](profiling/with_perf.html) From b6cf9a7e882d7a858f331d9bc24e4ad3b6a0cb7b Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sat, 4 Dec 2021 18:22:01 -0800 Subject: [PATCH 1599/1812] Update HIR chapter to use `HirId` instead of `NodeId` `NodeId`s are no longer used in the HIR. See #50928 for more information. --- src/hir.md | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/src/hir.md b/src/hir.md index 51e18973b..8316f7ce3 100644 --- a/src/hir.md +++ b/src/hir.md @@ -96,21 +96,16 @@ with a HIR node. [HIR map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html [number of methods]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#methods -For example, if you have a [`DefId`], and you would like to convert it -to a [`NodeId`], you can use -[`tcx.hir().as_local_node_id(def_id)`][as_local_node_id]. This returns -an `Option` – this will be `None` if the def-id refers to -something outside of the current crate (since then it has no HIR -node), but otherwise returns `Some(n)` where `n` is the node-id of the -definition. +For example, if you have a [`LocalDefId`], and you would like to convert it +to a [`HirId`], you can use [`tcx.hir().local_def_id_to_hir_id(def_id)`][local_def_id_to_hir_id]. +You need a `LocalDefId`, rather than a `DefId`, since only local items have HIR nodes. -[`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html -[as_local_node_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.as_local_node_id +[local_def_id_to_hir_id]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.local_def_id_to_hir_id Similarly, you can use [`tcx.hir().find(n)`][find] to lookup the node for a -[`NodeId`]. This returns a `Option>`, where [`Node`] is an enum -defined in the map; by matching on this you can find out what sort of -node the node-id referred to and also get a pointer to the data +[`HirId`]. This returns a `Option>`, where [`Node`] is an enum +defined in the map. By matching on this, you can find out what sort of +node the `HirId` referred to and also get a pointer to the data itself. Often, you know what sort of node `n` is – e.g. if you know that `n` must be some HIR expression, you can do [`tcx.hir().expect_expr(n)`][expect_expr], which will extract and return the From f9db2f4478f96af4600a48445256f704955f57da Mon Sep 17 00:00:00 2001 From: Jacob Hoffman-Andrews Date: Sat, 4 Dec 2021 23:28:05 -0800 Subject: [PATCH 1600/1812] Update rustdoc internals Use current paths when discussing source files. Update cheat sheet section with download-rustc. Add "use cases" section. --- src/rustdoc.md | 131 +++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 121 insertions(+), 10 deletions(-) diff --git a/src/rustdoc.md b/src/rustdoc.md index 2123d2b74..66cb496dc 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -36,30 +36,141 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) ## Cheat sheet +* Run `./x.py setup tools` before getting started. This will configure `x.py` + with nice settings for developing rustdoc and other tools, including + downloading a copy of rustc rather than building it. * Use `./x.py build` to make a usable rustdoc you can run on other projects. * Add `library/test` to be able to use `rustdoc --test`. - * If you've used `rustup toolchain link local /path/to/build/$TARGET/stage1` - previously, then after the previous build command, `cargo +local doc` will - Just Work. + * Run `rustup toolchain link stage2 build/$TARGET/stage2` to add a + custom toolchain called `stage2` to your rustup environment. After + running that, `cargo +stage2 doc` in any directory will build with + your locally-compiled rustdoc. * Use `./x.py doc library/std` to use this rustdoc to generate the standard library docs. - * The completed docs will be available in `build/$TARGET/doc/std`, though the - bundle is meant to be used as though you would copy out the `doc` folder to - a web server, since that's where the CSS/JS and landing page are. + * The completed docs will be available in `build/$TARGET/doc/std`. + * If you want to copy those docs to a webserver, copy all of + `build/$TARGET/doc`, since that's where the CSS, JS, fonts, and landing + page are. * Use `./x.py test src/test/rustdoc*` to run the tests using a stage1 rustdoc. * See [Rustdoc internals] for more information about tests. -* Most of the HTML printing code is in `html/format.rs` and `html/render.rs`. + +## Code structure + +* All paths in this section are relative to `src/librustdoc` in the rust-lang/rust repository. +* Most of the HTML printing code is in `html/format.rs` and `html/render/mod.rs`. It's in a bunch of `fmt::Display` implementations and supplementary functions. * The types that got `Display` impls above are defined in `clean/mod.rs`, right next to the custom `Clean` trait used to process them out of the rustc HIR. -* The bits specific to using rustdoc as a test harness are in `test.rs`. +* The bits specific to using rustdoc as a test harness are in + `doctest.rs`. * The Markdown renderer is loaded up in `html/markdown.rs`, including functions for extracting doctests from a given block of Markdown. -* The tests on rustdoc *output* are located in `src/test/rustdoc`, where +* The tests on the structure of rustdoc HTML output are located in `src/test/rustdoc`, where they're handled by the test runner of rustbuild and the supplementary script `src/etc/htmldocck.py`. -* Tests on search index generation are located in `src/test/rustdoc-js`, as a + +## Tests + +* All paths in this section are relative to `src/test` in the rust-lang/rust repository. +* Tests on search index generation are located in `rustdoc-js`, as a series of JavaScript files that encode queries on the standard library search index and expected results. +* Tests on the "UI" of rustdoc (the terminal output it produces when run) are in + `rustdoc-ui` +* Tests on the "GUI" of rustdoc (the HTML, JS, and CSS as rendered in a browser) + are in `rustdoc-gui`. These use a [NodeJS tool called + browser-UI-test](https://github.com/GuillaumeGomez/browser-UI-test/) that uses + puppeteer to run tests in a headless browser and check rendering and + interactivity. + +## Constraints + +We try to make rustdoc work reasonably well with JavaScript disabled, and when +browsing local files. We support +[these browsers](https://rust-lang.github.io/rfcs/1985-tiered-browser-support.html#supported-browsers). + +Supporting local files (`file:///` URLs) brings some surprising restrictions. +Certain browser features that require secure origins, like `localStorage` and +Service Workers, don't work reliably. We can still use such features but we +should make sure pages are still usable without them. + +## Multiple runs, same output directory + +Rustdoc can be run multiple times for varying inputs, with its output set to the +same directory. That's how cargo produces documentation for dependencies of the +current crate. It can also be done manually if a user wants a big +documentation bundle with all of the docs they care about. + +HTML is generated independently for each crate, but there is some cross-crate +information that we update as we add crates to the output directory: + + - `crates.js` holds a list of all crates in the output directory. + - `search-index.js` holds a list of all searchable items. + - For each trait, there is a file under `implementors/.../trait.TraitName.js` + containing a list of implementors of that trait. The implementors may be in + different crates than the trait, and the JS file is updated as we discover + new ones. + +## Use cases + +There are a few major use cases for rustdoc that you should keep in mind when +working on it: + +### Standard library docs + +These are published at as part of the Rust release +process. Stable releases are also uploaded to specific versioned URLs like +. Beta and nightly docs are published to + and . +The docs are uploaded with the [promote-release +tool](https://github.com/rust-lang/promote-release) and served from S3 with +CloudFront. + +The standard library docs contain five crates: alloc, core, proc_macro, std, and +test. + +### docs.rs + +When crates are published to crates.io, docs.rs automatically builds +and publishes their documentation, for instance at +. It always builds with the current nightly +rustdoc, so any changes you land in rustdoc are "insta-stable" in that they will +have an immediate public effect on docs.rs. Old documentation is not rebuilt, so +you will see some variation in UI when browsing old releases in docs.rs. Crate +authors can request rebuilds, which will be run with the latest rustdoc. + +Docs.rs performs some transformations on rustdoc's output in order to save +storage and display a navigation bar at the top. In particular, certain static +files (like main.js and rustdoc.css may be shared across multiple invocations +of the same version of rustdoc. Others, like crates.js and sidebar-items.js, are +different for different invocations. Still others, like fonts, will never +change. These categories are distinguished using the `SharedResource` enum in +`src/librustdoc/html/render/write_shared.rs` + +Documentation on docs.rs is always generated for a single crate at a time, so +the search and sidebar functionality don't include dependencies of the current +crate. + +### Locally generated docs + +Crate authors can run `cargo doc --open` in crates they have checked +out locally to see the docs. This is useful to check that the docs they +are writing are useful and display correctly. It can also be useful for +people to view documentation on crates they aren't authors of, but want to +use. In both cases, people may use `--document-private-items` Cargo flag to +see private methods, fields, and so on, which are normally not displayed. + +By default `cargo doc` will generate documentation for a crate and all of its +dependencies. That can result in a very large documentation bundle, with a large +(and slow) search corpus. The Cargo flag `--no-deps` inhibits that behavior and +generates docs for just the crate. + +### Self-hosted project docs + +Some projects like to host their own documentation. For example: +. This is easy to do by locally generating docs, and +simply copying them to a web server. Rustdoc's HTML output can be extensively +customized by flags. Users can add a theme, set the default theme, and inject +arbitrary HTML. See `rustdoc --help` for details. From 5dd756bceba73578b5344caf20ae61773bf0b17c Mon Sep 17 00:00:00 2001 From: Badel2 <2badel2@gmail.com> Date: Mon, 13 Dec 2021 07:16:30 +0100 Subject: [PATCH 1601/1812] Fix some broken links (#1274) --- src/profiling.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/profiling.md b/src/profiling.md index 8db30b253..ae76d977f 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -15,7 +15,7 @@ Depending on what you're trying to measure, there are several different approach See [their docs](https://github.com/rust-lang/measureme/blob/master/summarize/README.md) for more information. - If you want function level performance data or even just more details than the above approaches: - - Consider using a native code profiler such as [perf](profiling/with_perf.html) + - Consider using a native code profiler such as [perf](profiling/with_perf.md) - or [tracy](https://github.com/nagisa/rust_tracy_client) for a nanosecond-precision, full-featured graphical interface. @@ -26,7 +26,7 @@ Depending on what you're trying to measure, there are several different approach - If you want to profile memory usage, you can use various tools depending on what operating system you are using. - - For Windows, read our [WPA guide](profiling/wpa_profiling.html). + - For Windows, read our [WPA guide](profiling/wpa_profiling.md). ## Optimizing rustc's bootstrap times with `cargo-llvm-lines` From 35dce028e79ed9ad49be59242ad01963e927605c Mon Sep 17 00:00:00 2001 From: Maxwell Elliot Heiber Date: Wed, 15 Dec 2021 15:36:10 +0000 Subject: [PATCH 1602/1812] Update humor docs for special-casing ferris emoji update for: https://github.com/rust-lang/rust/pull/91476/files --- src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index a7ba61769..c502527d5 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -11,3 +11,4 @@ enlightening? - [`break rust;`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0ab2bd6a9d722e0f05a95e2a5dcf89cc) - [The Nomicon Intro](https://doc.rust-lang.org/stable/nomicon/) - [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20%28was.3A.20design.20meeting.202.2E.2E.2E/near/189906455) +- [try using their name "ferris" instead](https://github.com/rust-lang/rust/pull/91476) From 7340eb8704d65f0d7863545a50418cfba5b532ca Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Wed, 15 Dec 2021 10:58:41 -0800 Subject: [PATCH 1603/1812] Move date-check comment to fix Markdown syntax The inline code wasn't being rendered correctly. --- src/rustdoc-internals.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index 0d7459b1d..ccf0fcc5f 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -73,8 +73,8 @@ Here is the list of passes as of October 2021: - `check-bare-urls` detects links that are not linkified, e.g., in Markdown such as `Go to https://example.com/.` It suggests wrapping the link with angle brackets: - `Go to .` to linkify it. This is the code behind the - `rustdoc::bare_urls` lint. + `Go to .` to linkify it. This is the code behind the `rustdoc::bare_urls` lint. - `check-code-block-syntax` validates syntax inside Rust code blocks (```rust) From 9bf0028b557798ddd07a6f652e4d0c635d3d6620 Mon Sep 17 00:00:00 2001 From: Wang Qilin Date: Mon, 20 Dec 2021 20:53:57 +0800 Subject: [PATCH 1604/1812] remove rustfix item in test intro (#1277) --- src/tests/intro.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/tests/intro.md b/src/tests/intro.md index 25c1d059c..d92f042e4 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -50,9 +50,6 @@ details. ultimate in flexibility but quite annoying to write. - `rustdoc` – tests for rustdoc, making sure that the generated files contain the expected documentation. -- `rustfix` – tests for applying [diagnostic - suggestions](../diagnostics.md#suggestions) with the - [`rustfix`](https://github.com/rust-lang/rustfix/) crate - `*-fulldeps` – same as above, but indicates that the test depends on things other than `std` (and hence those things must be built) From a11e5f4e1541d29f322397287ffe21816690a48a Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Sat, 25 Dec 2021 02:52:31 +1100 Subject: [PATCH 1605/1812] Streamline "Getting Started" (#1279) * Move `x.py` intro section before first use, and shorten it. * Improve `x.py setup` docs. In "Getting Started", strip it back to the bare minimum. Some of this is moved into the later section. In the later section, add notable details like config.toml.example how and `profile` works. Also make the config.toml example more concise. * Move details about the repository. Less detail in "Getting Started", more in the later sections. * Move details about the prereqs. Less detail in "Getting Started", more in the later sections. --- src/building/how-to-build-and-run.md | 56 +++++++---- src/building/prerequisites.md | 35 +++++-- src/getting-started.md | 136 +++++---------------------- 3 files changed, 89 insertions(+), 138 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index ae3aabf12..4fe1da6d0 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -11,6 +11,12 @@ see [the next page](./prerequisites.md). ## Get the source code +The main repository is [`rust-lang/rust`][repo]. This contains the compiler, +the standard library (including `core`, `alloc`, `test`, `proc_macro`, etc), +and a bunch of tools (e.g. `rustdoc`, the bootstrapping infrastructure, etc). + +[repo]: https://github.com/rust-lang/rust + The very first step to work on `rustc` is to clone the repository: ```bash @@ -18,36 +24,50 @@ git clone https://github.com/rust-lang/rust.git cd rust ``` +There are also submodules for things like LLVM, `clippy`, `miri`, etc. The +build tool will automatically clone and sync these for you. But if you want to, +you can do the following: + +```sh +# first time +git submodule update --init --recursive + +# subsequent times (to pull new commits) +git submodule update +``` + ## Create a `config.toml` -To start, run `./x.py setup`. This will create a `config.toml` with reasonable defaults. +To start, run `./x.py setup`. This will do some initialization and create a +`config.toml` for you with reasonable defaults. These defaults are specified +indirectly via the `profile` setting, which points to one of the TOML files in +`src/bootstrap/defaults.` + +Alternatively, you can write `config.toml` by hand. See `config.toml.example` +for all the available settings and explanations of them. The following settings +are of particular interest, and `config.toml.example` has full explanations. -You may also want to change some of the following settings (and possibly others, such as +You may want to change some of the following settings (and possibly others, such as `llvm.ccache`): ```toml [llvm] # Whether to use Rust CI built LLVM instead of locally building it. -download-ci-llvm = true - -# Indicates whether the LLVM assertions are enabled or not -assertions = true +download-ci-llvm = true # Download a pre-built LLVM? +assertions = true # LLVM assertions on? +ccache = "/path/to/ccache" # Use ccache when building LLVM? [rust] -# Whether or not to leave debug! and trace! calls in the rust binary. -# Overrides the `debug-assertions` option, if defined. -# -# Defaults to rust.debug-assertions value -# -# If you see a message from `tracing` saying -# `max_level_info` is enabled and means logging won't be shown, -# set this value to `true`. -debug-logging = true - -# Whether to always use incremental compilation when building rustc -incremental = true +debug-logging = true # Leave debug! and trace! calls in rustc? +incremental = true # Build rustc with incremental compilation? ``` +If you set `download-ci-llvm = true`, in some circumstances, such as when +updating the version of LLVM used by `rustc`, you may want to temporarily +disable this feature. See the ["Updating LLVM" section] for more. + +["Updating LLVM" section]: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html?highlight=download-ci-llvm#feature-updates + If you have already built `rustc` and you change settings related to LLVM, then you may have to execute `rm -rf build` for subsequent configuration changes to take effect. Note that `./x.py clean` will not cause a rebuild of LLVM. diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index be5d96ad9..ec2e8a860 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -43,17 +43,40 @@ see [the `rust-lang/rust` README](https://github.com/rust-lang/rust#building-on- ## Hardware -These are not so much requirements as _recommendations_: - -* ~15GB of free disk space (~25GB or more if doing incremental builds). -* \>= 8GB RAM -* \>= 2 cores -* Internet access +You will need an internet connection to build. The bootstrapping process +involves updating git submodules and downloading a beta compiler. It doesn't +need to be super fast, but that can help. + +There are no strict hardware requirements, but building the compiler is +computationally expensive, so a beefier machine will help, and I wouldn't +recommend trying to build on a Raspberry Pi! We recommend the following. +* 30GB+ of free disk space. Otherwise, you will have to keep + clearing incremental caches. More space is better, the compiler is a bit of a + hog; it's a problem we are aware of. +* 8GB+ RAM +* 2+ cores. Having more cores really helps. 10 or 20 or more is not too many! Beefier machines will lead to much faster builds. If your machine is not very powerful, a common strategy is to only use `./x.py check` on your local machine and let the CI build test your changes when you push to a PR branch. +Building the compiler takes more than half an hour on my moderately powerful +laptop. The first time you build the compiler, LLVM will also be built unless +you use CI-built LLVM ([see here][config]). + +Like `cargo`, the build system will use as many cores as possible. Sometimes +this can cause you to run low on memory. You can use `-j` to adjust the number +concurrent jobs. If a full build takes more than ~45 minutes to an hour, you +are probably spending most of the time swapping memory in and out; try using +`-j1`. + +If you don't have too much free disk space, you may want to turn off +incremental compilation ([see here][config]). This will make compilation take +longer (especially after a rebase), but will save a ton of space from the +incremental caches. + +[config]: ./how-to-build-and-run.md#create-a-configtoml + ## `rustc` and toolchain installation Follow the installation given in the [Rust book][install] to install a working diff --git a/src/getting-started.md b/src/getting-started.md index a2f507e76..40e68cf0e 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -44,59 +44,24 @@ just create noise, so we ask that you be mindful of the fact that the ## Cloning and Building -The main repository is [`rust-lang/rust`][repo]. This contains the compiler, -the standard library (including `core`, `alloc`, `test`, `proc_macro`, etc), -and a bunch of tools (e.g. `rustdoc`, the bootstrapping infrastructure, etc). - -[repo]: https://github.com/rust-lang/rust - -There are also a bunch of submodules for things like LLVM, `clippy`, `miri`, -etc. You don't need to clone these immediately, but the build tool will -automatically clone and sync them (more on this later). - -[**Take a look at the "Suggested Workflows" chapter for some helpful -advice.**][suggested] - -[suggested]: ./building/suggested.md - ### System Requirements -[**See this chapter for detailed software requirements.**](./building/prerequisites.md) -Most notably, you will need Python 2 or 3 to run `x.py`. - -There are no hard hardware requirements, but building the compiler is -computationally expensive, so a beefier machine will help, and I wouldn't -recommend trying to build on a Raspberry Pi :P +Internet access is required. -- Recommended >=30GB of free disk space; otherwise, you will have to keep - clearing incremental caches. More space is better, the compiler is a bit of a - hog; it's a problem we are aware of. -- Recommended >=8GB RAM. -- Recommended >=2 cores; having more cores really helps. -- You will need an internet connection to build; the bootstrapping process - involves updating git submodules and downloading a beta compiler. It doesn't - need to be super fast, but that can help. +The most notable software requirement is that you will need Python 2 or 3, but +there are various others. -Building the compiler takes more than half an hour on my moderately powerful -laptop. The first time you build the compiler, LLVM will also be built unless -you use CI-built LLVM ([see below][configsec]). +The following hardware is recommended. +* 30GB+ of free disk space. +* 8GB+ RAM +* 2+ cores -[configsec]: #configuring-the-compiler +More powerful machines will lead to much faster builds. There are various +strategies to work around lesser hardware in the following chapters. -Like `cargo`, the build system will use as many cores as possible. Sometimes -this can cause you to run low on memory. You can use `-j` to adjust the number -concurrent jobs. If a full build takes more than ~45 minutes to an hour, -you are probably spending most of the time swapping memory in and out; -try using `-j1`. +See [this chapter][prereqs] for more details about software and hardware prerequisites. -On a slow machine, the build times for rustc are very painful. Consider using -`./x.py check` instead of a full build and letting the automated tests run -when you push to GitHub. - -If you don't have too much free disk space, you may want to turn off -incremental compilation ([see below][configsec]). This will make -compilation take longer (especially after a rebase), -but will save a ton of space from the incremental caches. +[prereqs]: ./building/prerequisites.md ### Cloning @@ -104,89 +69,32 @@ You can just do a normal git clone: ```sh git clone https://github.com/rust-lang/rust.git +cd rust ``` -You don't need to clone the submodules at this time. But if you want to, you -can do the following: +### `x.py` Intro -```sh -# first time -git submodule update --init --recursive +`rustc` is a [bootstrapping] compiler, which makes it more complex than a +typical Rust program. As a result, you cannot use Cargo to build it. Instead +you must use the special tool `x.py`. It is used for the things Cargo is +normally used for: building, testing, creating releases, formatting, etc. -# subsequent times (to pull new commits) -git submodule update -``` +[bootstrapping]: ./building/bootstrapping.md ### Configuring the Compiler -The compiler has a configuration file which contains a ton of settings. We will -provide some recommendations here that should work for most, but [check out -this chapter for more info][config]. - -[config]: ./building/how-to-build-and-run.md#create-a-configtoml - In the top level of the repo: ```sh $ ./x.py setup ``` -This will walk you through an interactive setup for `x.py` that looks like this: - -``` -$ ./x.py setup -Welcome to the Rust project! What do you want to do with x.py? -a) Contribute to the standard library -b) Contribute to the compiler -c) Contribute to the compiler, and also modify LLVM or codegen -d) Install Rust from source -Please choose one (a/b/c/d): a -`x.py` will now use the configuration at /home/joshua/rustc2/src/bootstrap/defaults/config.toml.library -To get started, try one of the following commands: -- `x.py check` -- `x.py build` -- `x.py test library/std` -- `x.py doc` -For more suggestions, see https://rustc-dev-guide.rust-lang.org/building/suggested.html -``` - -Note that by default, `./x.py setup` will use CI-built LLVM if available for your -platform so that you don't need to build LLVM in addition to building the -compiler. In some circumstances, such as when updating the version of LLVM used -by `rustc`, you may want to temporarily disable this feature. See the ["Updating -LLVM" section] for more. +This will do some initialization and walk you through an interactive setup to +create `config.toml`, the primary configuration file. -If you want to download LLVM from CI without running `./x.py setup`, you can set -the `download-ci-llvm` option to `true` in your `config.toml`: +See [this chapter][config] for more info about configuration. -```toml -[llvm] -download-ci-llvm = true -``` - -["Updating LLVM" section]: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html?highlight=download-ci-llvm#feature-updates - -### `x.py` Intro - -`rustc` is a _bootstrapping_ compiler, which means that it is written in Rust -and thus needs to be compiled by itself. So where do you -get the original compiler from? We use the current beta compiler -to build a new compiler. Then, we use that compiler to build itself. Thus, -`rustc` has a 2-stage build. You can read more about bootstrapping -[here][boot], but you don't need to know much more to contribute. - -[boot]: ./building/bootstrapping.md - -We have a special tool `x.py` that drives this process. It is used for -building the compiler, the standard libraries, and `rustdoc`. It is also used -for driving CI and building the final release artifacts. - -Unfortunately, a proper 2-stage build takes a long time depending on your -hardware, but it is the only correct way to build everything (e.g. it's what -the CI and release processes use). **However, in most cases, you can get by -without a full 2-stage build**. In the following section, we give instructions -for how to do "the correct thing", but then we also give various tips to speed -things up. +[config]: ./building/how-to-build-and-run.md#create-a-configtoml ### Building and Testing `rustc` From f6a190e709fda2ec06ec18b4cc56076cf262c512 Mon Sep 17 00:00:00 2001 From: Ben Reeves Date: Mon, 27 Dec 2021 10:28:15 -0600 Subject: [PATCH 1606/1812] Fix link in contributing.md (#1280) --- src/contributing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 9c22fab9a..8f6d1d6d8 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -397,9 +397,9 @@ in the same way as other pull requests. [`src/doc`]: https://github.com/rust-lang/rust/tree/master/src/doc [`lib.rs`]: https://github.com/rust-lang/rust/blob/master/library/std/src/lib.rs#L1 -To find documentation-related issues, sort by the [T-doc label][tdoc]. +To find documentation-related issues, sort by the [A-docs label][adocs]. -[tdoc]: https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3Aissue%20label%3AT-doc +[adocs]: https://github.com/rust-lang/rust/issues?q=is%3Aopen%20is%3Aissue%20label%3AA-docs You can find documentation style guidelines in [RFC 1574][rfc1574]. From 875464457c4104686faf667f47848aa7b0f0a744 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Tue, 28 Dec 2021 20:17:49 -0800 Subject: [PATCH 1607/1812] Update link to moved section (#1282) The section was removed in #1030 and re-added in a different place in 2d42cf7. --- src/building/prerequisites.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index ec2e8a860..cfe4c7738 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -19,7 +19,7 @@ If building LLVM from source (the default), you'll need additional tools: Otherwise, you'll need LLVM installed and `llvm-config` in your path. See [this section for more info][sysllvm]. -[sysllvm]: ./suggested.md#skipping-llvm-build +[sysllvm]: ./new-target.md#using-pre-built-llvm ### Windows From a992723654ce1179f317490d8d40297755a6c3a6 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Wed, 5 Jan 2022 13:59:15 +1100 Subject: [PATCH 1608/1812] Streamline "Getting Started" some more. This is a follow-up to #1279. The "Getting Started" chapter is, TBH, pretty bad when it comes to the stuff about building and testing. It has far too much detail and lots of repetition, which would be overwhelming to a newcomer. This commit removes most of it, leaving behind just quick mentions of the most common `x.py` commands: `check`, `build`, `test`, `fmt`, with links to the appropriate chapters for details. There were a few interesting details that weren't covered elsewhere, so I moved those into other chapters. --- src/building/how-to-build-and-run.md | 23 ++-- src/conventions.md | 22 ++-- src/getting-started.md | 174 +++------------------------ src/rustdoc.md | 10 +- src/tests/running.md | 11 ++ 5 files changed, 58 insertions(+), 182 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 4fe1da6d0..339662780 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -125,8 +125,8 @@ Options: -h, --help print this help message ``` -For hacking, often building the stage 1 compiler is enough, but for -final testing and release, the stage 2 compiler is used. +For hacking, often building the stage 1 compiler is enough, which saves a lot +of time. But for final testing and release, the stage 2 compiler is used. `./x.py check` is really fast to build the rust compiler. It is, in particular, very useful when you're doing some kind of @@ -168,7 +168,7 @@ there is a (hacky) workaround. See [the section on "recommended workflows"](./suggested.md) below. Note that this whole command just gives you a subset of the full `rustc` -build. The **full** `rustc` build (what you get if you say `./x.py build +build. The **full** `rustc` build (what you get with `./x.py build --stage 2 compiler/rustc`) has quite a few more steps: - Build `rustc` with the stage1 compiler. @@ -176,20 +176,16 @@ build. The **full** `rustc` build (what you get if you say `./x.py build - Build `std` with stage2 compiler. - Build `librustdoc` and a bunch of other things with the stage2 compiler. - +You almost never need to do this. ## Build specific components -- Build only the core library +If you are working on the standard library, you probably don't need to build +the compiler unless you are planning to use a recently added nightly feature. +Instead, you can just build stage 0, which uses the current beta compiler. ```bash -./x.py build --stage 0 library/core -``` - -- Build only the core and `proc_macro` libraries - -```bash -./x.py build --stage 0 library/core library/proc_macro +./x.py build --stage 0 library/std ``` Sometimes you might just want to test if the part you’re working on can @@ -245,7 +241,8 @@ in other sections: - Building things: - `./x.py build` – builds everything using the stage 1 compiler, not just up to `std` - - `./x.py build --stage 2` – builds the stage2 compiler + - `./x.py build --stage 2` – builds the stage2 compiler, along with `std` and + `rustdoc` (which doesn't take too long) - Running tests (see the [section on running tests](../tests/running.html) for more details): - `./x.py test library/std` – runs the `#[test]` tests from `std` diff --git a/src/conventions.md b/src/conventions.md index 582de0364..0b0a951c3 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -8,17 +8,25 @@ chapter covers [formatting](#formatting), [coding for correctness](#cc), # Formatting and the tidy script rustc is moving towards the [Rust standard coding style][fmt]. -This is enforced by the "tidy" script and can be mostly -automated using `./x.py fmt`. -As the output of [rustfmt] is not completely stable, -formatting this repository using `cargo fmt` is not recommended. +However, for now we don't use stable `rustfmt`; we use a pinned version with a +special config, so this may result in different style from normal [`rustfmt`]. +Therefore, formatting this repository using `cargo fmt` is not recommended. -The tidy script runs automatically when you do `./x.py test` and can be run -in isolation with `./x.py test tidy`. +Instead, formatting should be done using `./x.py fmt`. It's a good habit to run +`./x.py fmt` before every commit, as this reduces conflicts later. + +Formatting is checked by the "tidy" script. It runs automatically when you do +`./x.py test` and can be run in isolation with `./x.py test tidy`. `./x.py fmt +--check` also works. + +If you want to use format-on-save in your editor, the pinned version of +`rustfmt` is built under `build//stage0/bin/rustfmt`. You'll have to +pass the `--edition=2021` argument yourself when calling +`rustfmt` directly. [fmt]: https://github.com/rust-dev-tools/fmt-rfcs -[rustfmt]:https://github.com/rust-lang/rustfmt +[`rustfmt`]:https://github.com/rust-lang/rustfmt diff --git a/src/getting-started.md b/src/getting-started.md index 40e68cf0e..2b780ac4b 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -96,174 +96,28 @@ See [this chapter][config] for more info about configuration. [config]: ./building/how-to-build-and-run.md#create-a-configtoml -### Building and Testing `rustc` +### Common `x.py` commands -Here is a summary of the different commands for reference, but you probably -should still read the rest of the section: +Here are the basic invocations of the `x.py` commands most commonly used when +working on `rustc`, `std`, `rustdoc`, and other tools. | Command | When to use it | | --- | --- | -| `./x.py check` | Quick check to see if things compile; [rust-analyzer can run this automatically for you][rust-analyzer] | -| `./x.py build --stage 0 [library/std]` | Build only the standard library, without building the compiler | -| `./x.py build library/std` | Build just the 1st stage of the compiler, along with the standard library; this is faster than building stage 2 and usually good enough | -| `./x.py build --keep-stage 1 library/std` | Build the 1st stage of the compiler and skips rebuilding the standard library; this is useful after you've done an ordinary stage1 build to skip compilation time, but it can cause weird problems. (Just do a regular build to resolve.) | -| `./x.py test [--keep-stage 1]` | Run the test suite using the stage1 compiler | -| `./x.py test --bless [--keep-stage 1]` | Run the test suite using the stage1 compiler _and_ update expected test output. | -| `./x.py build --stage 2 compiler/rustc` | Do a full 2-stage build. You almost never want to do this. | -| `./x.py test --stage 2` | Do a full 2-stage build and run all tests. You almost never want to do this. | - -To do a full 2-stage build of the whole compiler, you should run this (after -updating `config.toml` as mentioned above): +| `./x.py check` | Quick check to see if most things compile; [rust-analyzer can run this automatically for you][rust-analyzer] | +| `./x.py build` | Builds `rustc`, `std`, and `rustdoc` | +| `./x.py test` | Runs all tests | +| `./x.py fmt` | Formats all code | -```sh -./x.py build --stage 2 compiler/rustc -``` - -In the process, this will also necessarily build the standard libraries, and it -will build `rustdoc` (which doesn't take too long). - -To build and test everything: - -```sh -./x.py test -``` - -For most contributions, you only need to build stage 1, which saves a lot of time: - -```sh -# Build the compiler (stage 1) -./x.py build library/std - -# Subsequent builds -./x.py build --keep-stage 1 library/std -``` - -This will take a while, especially the first time. Be wary of accidentally -touching or formatting the compiler, as `x.py` will try to recompile it. - -**NOTE**: The `--keep-stage 1` will _assume_ that the stage 0 standard library -does not need to be rebuilt, which is usually true, which will save some time. -However, if you are changing certain parts of the compiler, this may lead to -weird errors. Feel free to ask on [zulip][z] if you are running into issues. - -This runs a ton of tests and takes a long time to complete. If you are -working on `rustc`, you can usually get by with only the [UI tests][uitests]. These -test are mostly for the frontend of the compiler, so if you are working on LLVM -or codegen, this shortcut will _not_ test your changes. You can read more about the -different test suites [in this chapter][testing]. +As written, these commands are reasonable starting points. However, there are +additional options and arguments for each of them that are worth learning for +serious development work. In particular, `./x.py build` and `./x.py test` +provide many ways to compile or test a subset of the code, which can save a lot +of time. [rust-analyzer]: ./building/suggested.html#configuring-rust-analyzer-for-rustc -[uitests]: ./tests/adding.html#ui -[testing]: https://rustc-dev-guide.rust-lang.org/tests/intro.html - -```sh -# First build -./x.py test src/test/ui - -# Subsequent builds -./x.py test src/test/ui --keep-stage 1 -``` - -If your changes impact test output, you can use `--bless` to automatically -update the `.stderr` files of the affected tests: - -```sh -./x.py test src/test/ui --keep-stage 1 --bless -``` - -While working on the compiler, it can be helpful to see if the code just -compiles (similar to `cargo check`) without actually building it. You can do -this with: - -```sh -./x.py check -``` - -This command is really fast (relative to the other commands). It usually -completes in a couple of minutes on my laptop. **A common workflow when working -on the compiler is to make changes and repeatedly check with `./x.py check`. -Then, run the tests as shown above when you think things should work.** - -Finally, the CI ensures that the codebase is using consistent style. To format -the code: - -```sh -# Actually format -./x.py fmt -# Just check formatting, exit with error -./x.py fmt --check -``` - -*Note*: we don't use stable `rustfmt`; we use a pinned version with a special -config, so this may result in different style from normal `rustfmt` if you have -format-on-save turned on. It's a good habit to run `./x.py fmt` before every -commit, as this reduces conflicts later. The pinned version is built under -`build//stage0/bin/rustfmt`, so if you want, you can use it for a -single file or for format-on-save in your editor, which can be faster than `./x.py fmt`. -You'll have to pass the `--edition=2021` argument -yourself when calling `rustfmt` directly. - -One last thing: you can use `RUSTC_LOG=XXX` to get debug logging. [Read more -here][logging]. Notice the `C` in `RUSTC_LOG`. Other than that, it uses normal -[`env_logger`][envlog] or `tracing` syntax. - -[envlog]: https://crates.io/crates/env_logger -[logging]: ./tracing.md - -### Building and Testing `std`/`core`/`alloc`/`test`/`proc_macro`/etc. - -As before, technically the proper way to build one of these libraries is to use -the stage-2 compiler, which of course requires a 2-stage build, described above -(`./x.py build`). - -In practice, though, you don't need to build the compiler unless you are -planning to use a recently added nightly feature. Instead, you can just build -stage 0, which uses the current beta compiler. - -```sh -./x.py build --stage 0 -``` - -```sh -./x.py test --stage 0 library/std -``` - -(The same works for `library/alloc`, `library/core`, etc.) - -### Building and Testing `rustdoc` - -`rustdoc` uses `rustc` internals (and, of course, the standard library), so you -will have to build the compiler and `std` once before you can build `rustdoc`. -As before, you can use `./x.py build` to do this. The first time you build, -the stage-1 compiler will also be built. - -```sh -# First build -./x.py build - -# Subsequent builds -./x.py build --keep-stage 1 -``` - -As with the compiler, you can do a fast check build: - -```sh -./x.py check -``` - -Rustdoc has two types of tests: content tests and UI tests. - -```sh -# Content tests -./x.py test src/test/rustdoc - -# UI tests -./x.py test src/test/rustdoc-ui - -# Both at once -./x.py test src/test/rustdoc src/test/rustdoc-ui -``` +See the chapters on [building](./building/how-to-build-and-run.md) and +[testing](./tests/intro.md) for more details. ### Contributing code to other Rust projects diff --git a/src/rustdoc.md b/src/rustdoc.md index 66cb496dc..6c30a556c 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -1,6 +1,9 @@ # Rustdoc overview -Rustdoc actually uses the rustc internals directly. It lives in-tree with the +`rustdoc` uses `rustc` internals (and, of course, the standard library), so you +will have to build the compiler and `std` once before you can build `rustdoc`. + +`rustdoc` lives in-tree with the compiler and standard library. This chapter is about how it works. For information about Rustdoc's features and how to use them, see the [Rustdoc book](https://doc.rust-lang.org/nightly/rustdoc/). @@ -39,9 +42,11 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * Run `./x.py setup tools` before getting started. This will configure `x.py` with nice settings for developing rustdoc and other tools, including downloading a copy of rustc rather than building it. +* Use `./x.py check` to quickly check for compile errors. * Use `./x.py build` to make a usable rustdoc you can run on other projects. * Add `library/test` to be able to use `rustdoc --test`. + * Add `--keep-stage 1` on subsequent runs to avoid rebuilding some things. * Run `rustup toolchain link stage2 build/$TARGET/stage2` to add a custom toolchain called `stage2` to your rustup environment. After running that, `cargo +stage2 doc` in any directory will build with @@ -52,7 +57,8 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * If you want to copy those docs to a webserver, copy all of `build/$TARGET/doc`, since that's where the CSS, JS, fonts, and landing page are. -* Use `./x.py test src/test/rustdoc*` to run the tests using a stage1 rustdoc. +* Use `./x.py test src/test/rustdoc*` to run the tests using a stage1 + rustdoc. * See [Rustdoc internals] for more information about tests. ## Code structure diff --git a/src/tests/running.md b/src/tests/running.md index c91a27bf2..a204fcab0 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -36,7 +36,11 @@ modifying rustc to see if things are generally working correctly would be the following: ```bash +# First build ./x.py test src/test/ui + +# Subsequent builds (optional, but can save time) +./x.py test src/test/ui --keep-stage 1 ``` This will run the `ui` test suite. Of course, the choice @@ -92,6 +96,13 @@ tests for components you did not change at all. build; therefore, while the tests **usually** work fine with stage 1, there are some limitations. +### Run all tests using a stage 2 compiler + +```bash +./x.py test --stage 2 +``` +You almost never need to do this. + ## Run unit tests on the compiler/library You may want to run unit tests on a specific file with following: From acc6718c515b38c2583d3503ab71a107277c5136 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Thu, 6 Jan 2022 11:39:57 +1100 Subject: [PATCH 1609/1812] Address review comments in #1286. --- src/conventions.md | 5 ++--- src/getting-started.md | 4 ++-- src/rustdoc.md | 1 - src/tests/running.md | 4 ---- 4 files changed, 4 insertions(+), 10 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index 0b0a951c3..16828c496 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -16,9 +16,8 @@ Therefore, formatting this repository using `cargo fmt` is not recommended. Instead, formatting should be done using `./x.py fmt`. It's a good habit to run `./x.py fmt` before every commit, as this reduces conflicts later. -Formatting is checked by the "tidy" script. It runs automatically when you do -`./x.py test` and can be run in isolation with `./x.py test tidy`. `./x.py fmt ---check` also works. +Formatting is checked by the `tidy` script. It runs automatically when you do +`./x.py test` and can be run in isolation with `./x.py fmt --check`. If you want to use format-on-save in your editor, the pinned version of `rustfmt` is built under `build//stage0/bin/rustfmt`. You'll have to diff --git a/src/getting-started.md b/src/getting-started.md index 2b780ac4b..a5e67456e 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -116,8 +116,8 @@ of time. [rust-analyzer]: ./building/suggested.html#configuring-rust-analyzer-for-rustc -See the chapters on [building](./building/how-to-build-and-run.md) and -[testing](./tests/intro.md) for more details. +See the chapters on [building](./building/how-to-build-and-run.md), +[testing](./tests/intro.md), and [rustdoc](./rustdoc.md) for more details. ### Contributing code to other Rust projects diff --git a/src/rustdoc.md b/src/rustdoc.md index 6c30a556c..d6063de73 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -46,7 +46,6 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * Use `./x.py build` to make a usable rustdoc you can run on other projects. * Add `library/test` to be able to use `rustdoc --test`. - * Add `--keep-stage 1` on subsequent runs to avoid rebuilding some things. * Run `rustup toolchain link stage2 build/$TARGET/stage2` to add a custom toolchain called `stage2` to your rustup environment. After running that, `cargo +stage2 doc` in any directory will build with diff --git a/src/tests/running.md b/src/tests/running.md index a204fcab0..ba87c5f9a 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -36,11 +36,7 @@ modifying rustc to see if things are generally working correctly would be the following: ```bash -# First build ./x.py test src/test/ui - -# Subsequent builds (optional, but can save time) -./x.py test src/test/ui --keep-stage 1 ``` This will run the `ui` test suite. Of course, the choice From 18b93ae2eee0f825a82d4313d8f7825d0fa030d9 Mon Sep 17 00:00:00 2001 From: Nicholas Nethercote Date: Thu, 6 Jan 2022 12:52:38 +1100 Subject: [PATCH 1610/1812] Address more review comments in #1286. --- src/building/how-to-build-and-run.md | 2 +- src/rustdoc.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 339662780..cd4891358 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -182,7 +182,7 @@ You almost never need to do this. If you are working on the standard library, you probably don't need to build the compiler unless you are planning to use a recently added nightly feature. -Instead, you can just build stage 0, which uses the current beta compiler. +Instead, you can just build using the bootstrap compiler. ```bash ./x.py build --stage 0 library/std diff --git a/src/rustdoc.md b/src/rustdoc.md index d6063de73..7d07c0414 100644 --- a/src/rustdoc.md +++ b/src/rustdoc.md @@ -42,7 +42,7 @@ does is call the `main()` that's in this crate's `lib.rs`, though.) * Run `./x.py setup tools` before getting started. This will configure `x.py` with nice settings for developing rustdoc and other tools, including downloading a copy of rustc rather than building it. -* Use `./x.py check` to quickly check for compile errors. +* Use `./x.py check src/tools/rustdoc` to quickly check for compile errors. * Use `./x.py build` to make a usable rustdoc you can run on other projects. * Add `library/test` to be able to use `rustdoc --test`. From a10c5befc191fb827280c6edb75d86b36c8dfb5e Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Tue, 18 Jan 2022 06:09:16 -0800 Subject: [PATCH 1611/1812] Clean up section about FCPs (#1287) * I've never heard the term "pFCP" used before, so spell it out as "proposed final comment period" * Fix some unclear things (like implying that you need `r+` rights to start an FCP) * Improve the chapter's title, and make it consistent with its TOC entry * Make some other assorted minor cleanups and improvements --- src/implementing_new_features.md | 43 +++++++++++++++----------------- 1 file changed, 20 insertions(+), 23 deletions(-) diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 03da87620..73a3543cd 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -1,43 +1,42 @@ -# Implement New Feature +# Implementing new features When you want to implement a new significant feature in the compiler, you need to go through this process to make sure everything goes smoothly. -## The @rfcbot (p)FCP process +## The @rfcbot FCP process When the change is small and uncontroversial, then it can be done -with just writing a PR and getting r+ from someone who knows that +with just writing a PR and getting an r+ from someone who knows that part of the code. However, if the change is potentially controversial, it would be a bad idea to push it without consensus from the rest of the team (both in the "distributed system" sense to make sure you don't break anything you don't know about, and in the social sense to avoid PR fights). -If such a change seems to be too small to require a full formal RFC -process (e.g. a big refactoring of the code, or a -"technically-breaking" change, or a "big bugfix" that basically -amounts to a small feature) but is still too controversial or -big to get by with a single r+, you can start a pFCP (or, if you -don't have r+ rights, ask someone who has them to start one - and -unless they have a concern themselves, they should). pFCP stands for -"proposed final comment period". - -Again, the pFCP process is only needed if you need consensus - if you -don't think anyone would have a problem with your change, it's ok to +If such a change seems to be too small to require a full formal RFC process +(e.g., a small standard library addition, a big refactoring of the code, a +"technically-breaking" change, or a "big bugfix" that basically amounts to a +small feature) but is still too controversial or big to get by with a single r+, +you can propose a final comment period (FCP). Or, if you're not on the relevant +team (and thus don't have @rfcbot permissions), ask someone who is to start one; +unless they have a concern themselves, they should. + +Again, the FCP process is only needed if you need consensus – if you +don't think anyone would have a problem with your change, it's OK to get by with only an r+. For example, it is OK to add or modify -unstable command-line flags or attributes without a pFCP for +unstable command-line flags or attributes without an FCP for compiler development or standard library use, as long as you don't expect them to be in wide use in the nightly ecosystem. -You don't need to have the implementation fully ready for r+ to ask -for a pFCP, but it is generally a good idea to have at least a proof +You don't need to have the implementation fully ready for r+ to propose an FCP, +but it is generally a good idea to have at least a proof of concept so that people can see what you are talking about. -When a pFCP is started, it requires all members of the team to sign off -the FCP. After they all do so, there's a 10 day long "final comment -period" where everybody can comment, and if no new concerns are raised, -the PR/issue gets FCP approval. +When an FCP is proposed, it requires all members of the team to sign off the +FCP. After they all do so, there's a 10-day-long "final comment period" (hence +the name) where everybody can comment, and if no concerns are raised, the +PR/issue gets FCP approval. ## The logistics of writing features @@ -79,7 +78,6 @@ feature can be changed, or the feature might be completely rewritten or removed. Features are not supposed to gain tenure by being unstable and unchanged for a year. - ### Tracking Issues To keep track of the status of an unstable feature, the @@ -111,7 +109,6 @@ for stabilization in a checklist, e.g., - [ ] Stabilize the feature. ([See instructions on rustc-dev-guide.](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr)) ``` - ## Stability in code The below steps needs to be followed in order to implement From 60bc9abf7205873dd0f9cdfac36d6adeed2e70ac Mon Sep 17 00:00:00 2001 From: Georgiy Komarov Date: Tue, 18 Jan 2022 17:09:37 +0300 Subject: [PATCH 1612/1812] Spelling: Rename `rust` to `Rust` (#1288) --- src/about-this-guide.md | 4 ++-- src/backend/codegen.md | 2 +- src/backend/monomorph.md | 4 ++-- src/building/bootstrapping.md | 2 +- src/building/compiler-documenting.md | 2 +- src/building/how-to-build-and-run.md | 6 +++--- src/building/suggested.md | 2 +- src/compiler-src.md | 4 ++-- src/compiletest.md | 2 +- src/contributing.md | 2 +- src/crates-io.md | 2 +- src/diagnostics/diagnostic-items.md | 2 +- src/macro-expansion.md | 2 +- src/overview.md | 4 ++-- src/test-implementation.md | 2 +- src/tests/intro.md | 4 ++-- src/tests/running.md | 2 +- src/ty.md | 2 +- src/walkthrough.md | 20 ++++++++++---------- 19 files changed, 35 insertions(+), 35 deletions(-) diff --git a/src/about-this-guide.md b/src/about-this-guide.md index e015302c0..b2c71866c 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -59,8 +59,8 @@ please see the corresponding [subsection on writing documentation in this guide] You might also find the following sites useful: - [rustc API docs] -- rustdoc documentation for the compiler -- [Forge] -- contains documentation about rust infrastructure, team procedures, and more -- [compiler-team] -- the home-base for the rust compiler team, with description +- [Forge] -- contains documentation about Rust infrastructure, team procedures, and more +- [compiler-team] -- the home-base for the Rust compiler team, with description of the team procedures, active working groups, and the team calendar. - [std-dev-guide] -- a similar guide for developing the standard library. diff --git a/src/backend/codegen.md b/src/backend/codegen.md index 8e18ca242..1a6c2fa76 100644 --- a/src/backend/codegen.md +++ b/src/backend/codegen.md @@ -3,7 +3,7 @@ Code generation or "codegen" is the part of the compiler that actually generates an executable binary. Usually, rustc uses LLVM for code generation; there is also support for [Cranelift]. The key is that rustc doesn't implement -codegen itself. It's worth noting, though, that in the rust source code, many +codegen itself. It's worth noting, though, that in the Rust source code, many parts of the backend have `codegen` in their names (there are no hard boundaries). diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index a2918b608..7111c634a 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -2,7 +2,7 @@ -As you probably know, rust has a very expressive type system that has extensive +As you probably know, Rust has a very expressive type system that has extensive support for generic types. But of course, assembly is not generic, so we need to figure out the concrete types of all the generics before the code can execute. @@ -23,7 +23,7 @@ The result is fast programs, but it comes at the cost of compile time (creating all those copies can take a while) and binary size (all those copies might take a lot of space). -Monomorphization is the first step in the backend of the rust compiler. +Monomorphization is the first step in the backend of the Rust compiler. ## Collection diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 460776e51..48f501a02 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -110,7 +110,7 @@ bootstrapping the compiler. When you use the bootstrap system, you'll call it through `x.py`. However, most of the code lives in `src/bootstrap`. `bootstrap` has a difficult problem: it is written in Rust, but yet it is run -before the rust compiler is built! To work around this, there are two +before the Rust compiler is built! To work around this, there are two components of bootstrap: the main one written in rust, and `bootstrap.py`. `bootstrap.py` is what gets run by `x.py`. It takes care of downloading the `stage0` compiler, which will then build the bootstrap binary written in diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md index 0efe2fce6..f921cd089 100644 --- a/src/building/compiler-documenting.md +++ b/src/building/compiler-documenting.md @@ -50,6 +50,6 @@ documentation for internal compiler items will also be built. ### Compiler Documentation -The documentation for the rust components are found at [rustc doc]. +The documentation for the Rust components are found at [rustc doc]. [rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index cd4891358..93ebb487e 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -120,7 +120,7 @@ Options: --on-fail CMD command to run on failure --stage N stage to build --keep-stage N stage to keep without recompiling - --src DIR path to the root of the rust checkout + --src DIR path to the root of the Rust checkout -j, --jobs JOBS number of jobs to run in parallel -h, --help print this help message ``` @@ -128,7 +128,7 @@ Options: For hacking, often building the stage 1 compiler is enough, which saves a lot of time. But for final testing and release, the stage 2 compiler is used. -`./x.py check` is really fast to build the rust compiler. +`./x.py check` is really fast to build the Rust compiler. It is, in particular, very useful when you're doing some kind of "type-based refactoring", like renaming a method, or changing the signature of some function. @@ -150,7 +150,7 @@ What this command does is the following: - Build `std` using the stage1 compiler (cannot use incremental) This final product (stage1 compiler + libs built using that compiler) -is what you need to build other rust programs (unless you use `#![no_std]` or +is what you need to build other Rust programs (unless you use `#![no_std]` or `#![no_core]`). The command includes the `-i` switch which enables incremental compilation. diff --git a/src/building/suggested.md b/src/building/suggested.md index bae98aa04..14e0410de 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -199,7 +199,7 @@ do not get shared. They will still be cloned multiple times. [worktrees]: https://git-scm.com/docs/git-worktree -Given you are inside the root directory for your rust repository, you can +Given you are inside the root directory for your Rust repository, you can create a "linked working tree" in a new "rust2" directory by running the following command: diff --git a/src/compiler-src.md b/src/compiler-src.md index b621dde7c..94add9aac 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -76,7 +76,7 @@ crates, just like a normal Rust crate. One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM. During bootstrapping, LLVM is built and the [`compiler/rustc_llvm`] crate -contains rust wrappers around LLVM (which is written in C++), so that the +contains Rust wrappers around LLVM (which is written in C++), so that the compiler can interface with it. Most of this book is about the compiler, so we won't have any further @@ -183,7 +183,7 @@ from `src/tools/`, such as [`tidy`] or [`compiletest`]. ## Other There are a lot of other things in the `rust-lang/rust` repo that are related -to building a full rust distribution. Most of the time you don't need to worry +to building a full Rust distribution. Most of the time you don't need to worry about them. These include: diff --git a/src/compiletest.md b/src/compiletest.md index b85aa09c2..2d34ea04f 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -178,7 +178,7 @@ function found in the `TestCx` implementation block, located in } fn check_correct_failure_status(&self, proc_res: &ProcRes) { -- // The value the rust runtime returns on failure +- // The value the Rust runtime returns on failure - const RUST_ERR: i32 = 101; - if proc_res.status.code() != Some(RUST_ERR) { + let expected_status = Some(self.props.failure_status); diff --git a/src/contributing.md b/src/contributing.md index 8f6d1d6d8..2d6511321 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -214,7 +214,7 @@ is modified to move the files from the specified directory to the tool repo root A `subtree pull` takes all changes since the last `subtree pull` from the tool repo and adds these commits to the rustc repo along with a merge commit that moves -the tool changes into the specified directory in the rust repository. +the tool changes into the specified directory in the Rust repository. It is recommended that you always do a push first and get that merged to the tool master branch. Then, when you do a pull, the merge works without conflicts. diff --git a/src/crates-io.md b/src/crates-io.md index bc59bfeed..62143defa 100644 --- a/src/crates-io.md +++ b/src/crates-io.md @@ -1,6 +1,6 @@ # crates.io Dependencies -The rust compiler supports building with some dependencies from `crates.io`. +The Rust compiler supports building with some dependencies from `crates.io`. For example, `log` and `env_logger` come from `crates.io`. In general, you should avoid adding dependencies to the compiler for several diff --git a/src/diagnostics/diagnostic-items.md b/src/diagnostics/diagnostic-items.md index 93a0194d9..b5cba717f 100644 --- a/src/diagnostics/diagnostic-items.md +++ b/src/diagnostics/diagnostic-items.md @@ -29,7 +29,7 @@ reference [*How To Use Diagnostic Items*](#how-to-use-diagnostic-items). A new diagnostic item can be added with these two steps: -1. Find the target item inside the rust repo. Now add the diagnostic item as a string via the +1. Find the target item inside the Rust repo. Now add the diagnostic item as a string via the `rustc_diagnostic_item` attribute. This can sometimes cause compilation errors while running tests. These errors can be avoided by using the `cfg_attr` attribute with the `not(test)` condition (it's fine adding then for all `rustc_diagnostic_item` attributes as a preventive diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 2f42ad9b9..e3b5a27e6 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -216,7 +216,7 @@ handle names defined _within a macro_. In particular, a hygienic macro system prevents errors due to names introduced within a macro. Rust macros are hygienic in that they do not allow one to write the sorts of bugs above. -At a high level, hygiene within the rust compiler is accomplished by keeping +At a high level, hygiene within the Rust compiler is accomplished by keeping track of the context where a name is introduced and used. We can then disambiguate names based on that context. Future iterations of the macro system will allow greater control to the macro author to use that context. For example, diff --git a/src/overview.md b/src/overview.md index 5c88722ef..02e56ca03 100644 --- a/src/overview.md +++ b/src/overview.md @@ -5,7 +5,7 @@ This chapter is about the overall process of compiling a program -- how everything fits together. -The rust compiler is special in two ways: it does things to your code that +The Rust compiler is special in two ways: it does things to your code that other compilers don't do (e.g. borrow checking) and it has a lot of unconventional implementation choices (e.g. queries). We will talk about these in turn in this chapter, and in the rest of the guide, we will look at all the @@ -225,7 +225,7 @@ interned. ### Queries -The first big implementation choice is the _query_ system. The rust compiler +The first big implementation choice is the _query_ system. The Rust compiler uses a query system which is unlike most textbook compilers, which are organized as a series of passes over the code that execute sequentially. The compiler does this to make incremental compilation possible -- that is, if the diff --git a/src/test-implementation.md b/src/test-implementation.md index 1a9283b59..09a66cdc9 100644 --- a/src/test-implementation.md +++ b/src/test-implementation.md @@ -2,7 +2,7 @@ -Today, rust programmers rely on a built in attribute called `#[test]`. All +Today, Rust programmers rely on a built in attribute called `#[test]`. All you have to do is mark a function as a test and include some asserts like so: ```rust,ignore diff --git a/src/tests/intro.md b/src/tests/intro.md index d92f042e4..efce3a658 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -149,7 +149,7 @@ start a bash shell in the container, run `src/ci/docker/run.sh --dev ` where `` is one of the directory names in `src/ci/docker` (for example `x86_64-gnu` is a fairly standard Ubuntu environment). -The docker script will mount your local rust source tree in read-only mode, +The docker script will mount your local Rust source tree in read-only mode, and an `obj` directory in read-write mode. All of the compiler artifacts will be stored in the `obj` directory. The shell will start out in the `obj` directory. From there, you can run `../src/ci/run.sh` which will run the build @@ -301,7 +301,7 @@ or could cause breakage. If you are unsure, feel free to ask your PR's reviewer. ### Requesting Crater Runs -The rust team maintains a few machines that can be used for running crater runs +The Rust team maintains a few machines that can be used for running crater runs on the changes introduced by a PR. If your PR needs a crater run, leave a comment for the triage team in the PR thread. Please inform the team whether you require a "check-only" crater run, a "build only" crater run, or a diff --git a/src/tests/running.md b/src/tests/running.md index ba87c5f9a..cd8f12ba1 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -124,7 +124,7 @@ may invoke `x.py` with the `--test-args` option: ./x.py test src/test/ui --test-args issue-1234 ``` -Under the hood, the test runner invokes the standard rust test runner +Under the hood, the test runner invokes the standard Rust test runner (the same one you get with `#[test]`), so this command would wind up filtering for tests that include "issue-1234" in the name. (Thus `--test-args` is a good way to run a collection of related tests.) diff --git a/src/ty.md b/src/ty.md index 87d653a74..95141b6f2 100644 --- a/src/ty.md +++ b/src/ty.md @@ -40,7 +40,7 @@ different [`Span`s][span] (locations). [span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html **Example: `fn foo(x: &u32) -> &u32`** In addition, HIR might have information left out. This type -`&u32` is incomplete, since in the full rust type there is actually a lifetime, but we didn’t need +`&u32` is incomplete, since in the full Rust type there is actually a lifetime, but we didn’t need to write those lifetimes. There are also some elision rules that insert information. The result may look like `fn foo<'a>(x: &'a u32) -> &'a u32`. diff --git a/src/walkthrough.md b/src/walkthrough.md index 8f5dc525e..84cb1296f 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -2,7 +2,7 @@ -There are _a lot_ of ways to contribute to the rust compiler, including fixing +There are _a lot_ of ways to contribute to the Rust compiler, including fixing bugs, improving performance, helping design features, providing feedback on existing features, etc. This chapter does not claim to scratch the surface. Instead, it walks through the design and implementation of a new feature. Not @@ -38,7 +38,7 @@ fn main() { So basically, the `$(pat)?` matcher in the macro means "this pattern can occur 0 or 1 times", similar to other regex syntaxes. -There were a number of steps to go from an idea to stable rust feature. Here is +There were a number of steps to go from an idea to stable Rust feature. Here is a quick list. We will go through each of these in order below. As I mentioned before, not all of these are needed for every type of contribution. @@ -55,9 +55,9 @@ before, not all of these are needed for every type of contribution. feature on the nightly compiler and in `std`, there may be additional feedback about design choice that might be adjusted. This particular feature went [through][impl2] a [number][impl3] of [iterations][impl4]. -- **Stabilization** When your feature has baked enough, a rust team member may +- **Stabilization** When your feature has baked enough, a Rust team member may [propose to stabilize it][merge]. If there is consensus, this is done. -- **Relax** Your feature is now a stable rust feature! +- **Relax** Your feature is now a stable Rust feature! [prerfc]: https://internals.rust-lang.org/t/pre-rfc-at-most-one-repetition-macro-patterns/6557 [rfc]: https://github.com/rust-lang/rfcs/pull/2298 @@ -70,7 +70,7 @@ before, not all of these are needed for every type of contribution. ## Pre-RFC and RFC > NOTE: In general, if you are not proposing a _new_ feature or substantial -> change to rust or the ecosystem, you don't need to follow the RFC process. +> change to Rust or the ecosystem, you don't need to follow the RFC process. > Instead, you can just jump to [implementation](#impl). > > You can find the official guidelines for when to open an RFC [here][rfcwhen]. @@ -79,7 +79,7 @@ before, not all of these are needed for every type of contribution. An RFC is a document that describes the feature or change you are proposing in detail. Anyone can write an RFC; the process is the same for everyone, -including rust team members. +including Rust team members. To open an RFC, open a PR on the [rust-lang/rfcs](https://github.com/rust-lang/rfcs) repo on GitHub. You can @@ -122,7 +122,7 @@ itself to reflect the course of the discussion (e.g. new alternatives or prior work may be added or you may decide to change parts of the proposal itself). In the end, when the discussion seems to reach a consensus and die down a bit, -a rust team member may propose to move to "final comment period" (FCP) with one +a Rust team member may propose to move to "final comment period" (FCP) with one of three possible dispositions. This means that they want the other members of the appropriate teams to review and comment on the RFC. More discussion may ensue, which may result in more changes or unresolved questions being added. At @@ -137,7 +137,7 @@ disposition is adopted. Here are the three possible dispositions: This is not a reflection on you, but rather a community decision that rust will go a different direction. - _Postpone_: there is interest in going this direction but not at the moment. - This happens most often because the appropriate rust team doesn't have the + This happens most often because the appropriate Rust team doesn't have the bandwidth to shepherd the feature through the process to stabilization. Often this is the case when the feature doesn't fit into the team's roadmap. Postponed ideas may be revisited later. @@ -181,7 +181,7 @@ gate is removed when the feature is stabilized. make your changes/improvements. When you open a PR on the [rust-lang/rust], a bot will assign your PR to a -review. If there is a particular rust team member you are working with, you can +review. If there is a particular Rust team member you are working with, you can request that reviewer by leaving a comment on the thread with `r? @reviewer-github-id` (e.g. `r? @eddyb`). If you don't know who to request, don't request anyone; the bot will assign someone automatically based on which files you changed. @@ -224,7 +224,7 @@ be proposed and unresolved questions may become resolved. Updates/changes go through the same process for implementing any other changes, as described above (i.e. submit a PR, go through review, wait for `@bors`, etc). -Some changes may be major enough to require an FCP and some review by rust team +Some changes may be major enough to require an FCP and some review by Rust team members. For the `?` macro feature, we went through a few different iterations after the From 4d46bd0c95667baf2dc7d546ac3667b833a15d47 Mon Sep 17 00:00:00 2001 From: Amanieu d'Antras Date: Tue, 18 Jan 2022 14:12:06 +0000 Subject: [PATCH 1613/1812] Add inline assembly internals (#1266) --- src/SUMMARY.md | 1 + src/asm.md | 367 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 368 insertions(+) create mode 100644 src/asm.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 411387ab6..fa044bce5 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -91,6 +91,7 @@ - [MIR passes: getting the MIR for a function](./mir/passes.md) - [Identifiers in the Compiler](./identifiers.md) - [Closure expansion](./closure.md) +- [Inline assembly](./asm.md) # Analysis diff --git a/src/asm.md b/src/asm.md new file mode 100644 index 000000000..2c177164e --- /dev/null +++ b/src/asm.md @@ -0,0 +1,367 @@ +# Inline assembly + + + +## Overview + +Inline assembly in rustc mostly revolves around taking an `asm!` macro invocation and plumbing it +through all of the compiler layers down to LLVM codegen. Throughout the various stages, an +`InlineAsm` generally consists of 3 components: + +- The template string, which is stored as an array of `InlineAsmTemplatePiece`. Each piece +represents either a literal or a placeholder for an operand (just like format strings). +```rust +pub enum InlineAsmTemplatePiece { + String(String), + Placeholder { operand_idx: usize, modifier: Option, span: Span }, +} +``` + +- The list of operands to the `asm!` (`in`, `[late]out`, `in[late]out`, `sym`, `const`). These are +represented differently at each stage of lowering, but follow a common pattern: + - `in`, `out` and `inout` all have an associated register class (`reg`) or explicit register +(`"eax"`). + - `inout` has 2 forms: one with a single expression that is both read from and written to, and +one with two separate expressions for the input and output parts. + - `out` and `inout` have a `late` flag (`lateout` / `inlateout`) to indicate that the register +allocator is allowed to reuse an input register for this output. + - `out` and the split variant of `inout` allow `_` to be specified for an output, which means +that the output is discarded. This is used to allocate scratch registers for assembly code. + - `const` refers to an anonymous constants and generally works like an inline const. + - `sym` is a bit special since it only accepts a path expression, which must point to a `static` +or a `fn`. + +- The options set at the end of the `asm!` macro. The only ones that are of particular interest to +rustc are `NORETURN` which makes `asm!` return `!` instead of `()`, and `RAW` which disables format +string parsing. The remaining options are mostly passed through to LLVM with little processing. +```rust +bitflags::bitflags! { + pub struct InlineAsmOptions: u16 { + const PURE = 1 << 0; + const NOMEM = 1 << 1; + const READONLY = 1 << 2; + const PRESERVES_FLAGS = 1 << 3; + const NORETURN = 1 << 4; + const NOSTACK = 1 << 5; + const ATT_SYNTAX = 1 << 6; + const RAW = 1 << 7; + const MAY_UNWIND = 1 << 8; + } +} +``` + +## AST + +`InlineAsm` is represented as an expression in the AST: + +```rust +pub struct InlineAsm { + pub template: Vec, + pub template_strs: Box<[(Symbol, Option, Span)]>, + pub operands: Vec<(InlineAsmOperand, Span)>, + pub clobber_abi: Option<(Symbol, Span)>, + pub options: InlineAsmOptions, + pub line_spans: Vec, +} + +pub enum InlineAsmRegOrRegClass { + Reg(Symbol), + RegClass(Symbol), +} + +pub enum InlineAsmOperand { + In { + reg: InlineAsmRegOrRegClass, + expr: P, + }, + Out { + reg: InlineAsmRegOrRegClass, + late: bool, + expr: Option>, + }, + InOut { + reg: InlineAsmRegOrRegClass, + late: bool, + expr: P, + }, + SplitInOut { + reg: InlineAsmRegOrRegClass, + late: bool, + in_expr: P, + out_expr: Option>, + }, + Const { + anon_const: AnonConst, + }, + Sym { + expr: P, + }, +} +``` + +The `asm!` macro is implemented in `rustc_builtin_macros` and outputs an `InlineAsm` AST node. The +template string is parsed using `fmt_macros`, positional and named operands are resolved to +explicit operand indicies. Since target information is not available to macro invocations, +validation of the registers and register classes is deferred to AST lowering. + +## HIR + +`InlineAsm` is represented as an expression in the HIR: + +```rust +pub struct InlineAsm<'hir> { + pub template: &'hir [InlineAsmTemplatePiece], + pub template_strs: &'hir [(Symbol, Option, Span)], + pub operands: &'hir [(InlineAsmOperand<'hir>, Span)], + pub options: InlineAsmOptions, + pub line_spans: &'hir [Span], +} + +pub enum InlineAsmRegOrRegClass { + Reg(InlineAsmReg), + RegClass(InlineAsmRegClass), +} + +pub enum InlineAsmOperand<'hir> { + In { + reg: InlineAsmRegOrRegClass, + expr: Expr<'hir>, + }, + Out { + reg: InlineAsmRegOrRegClass, + late: bool, + expr: Option>, + }, + InOut { + reg: InlineAsmRegOrRegClass, + late: bool, + expr: Expr<'hir>, + }, + SplitInOut { + reg: InlineAsmRegOrRegClass, + late: bool, + in_expr: Expr<'hir>, + out_expr: Option>, + }, + Const { + anon_const: AnonConst, + }, + Sym { + expr: Expr<'hir>, + }, +} +``` + +AST lowering is where `InlineAsmRegOrRegClass` is converted from `Symbol`s to an actual register or +register class. If any modifiers are specified for a template string placeholder, these are +validated against the set allowed for that operand type. Finally, explicit registers for inputs and +outputs are checked for conflicts (same register used for different operands). + +## Type checking + +Each register class has a whitelist of types that it may be used with. After the types of all +operands have been determined, the `intrinsicck` pass will check that these types are in the +whitelist. It also checks that split `inout` operands have compatible types and that `const` +operands are integers or floats. Suggestions are emitted where needed if a template modifier should +be used for an operand based on the type that was passed into it. + +## THIR + +`InlineAsm` is represented as an expression in the THIR: + +```rust +crate enum ExprKind<'tcx> { + // [..] + InlineAsm { + template: &'tcx [InlineAsmTemplatePiece], + operands: Box<[InlineAsmOperand<'tcx>]>, + options: InlineAsmOptions, + line_spans: &'tcx [Span], + }, +} +crate enum InlineAsmOperand<'tcx> { + In { + reg: InlineAsmRegOrRegClass, + expr: ExprId, + }, + Out { + reg: InlineAsmRegOrRegClass, + late: bool, + expr: Option, + }, + InOut { + reg: InlineAsmRegOrRegClass, + late: bool, + expr: ExprId, + }, + SplitInOut { + reg: InlineAsmRegOrRegClass, + late: bool, + in_expr: ExprId, + out_expr: Option, + }, + Const { + value: &'tcx Const<'tcx>, + span: Span, + }, + SymFn { + expr: ExprId, + }, + SymStatic { + def_id: DefId, + }, +} +``` + +The only significant change compared to HIR is that `Sym` has been lowered to either a `SymFn` +whose `expr` is a `Literal` ZST of the `fn`, or a `SymStatic` which points to the `DefId` of a +`static`. + +## MIR + +`InlineAsm` is represented as a `Terminator` in the MIR: + +```rust +pub enum TerminatorKind<'tcx> { + // [..] + + /// Block ends with an inline assembly block. This is a terminator since + /// inline assembly is allowed to diverge. + InlineAsm { + /// The template for the inline assembly, with placeholders. + template: &'tcx [InlineAsmTemplatePiece], + + /// The operands for the inline assembly, as `Operand`s or `Place`s. + operands: Vec>, + + /// Miscellaneous options for the inline assembly. + options: InlineAsmOptions, + + /// Source spans for each line of the inline assembly code. These are + /// used to map assembler errors back to the line in the source code. + line_spans: &'tcx [Span], + + /// Destination block after the inline assembly returns, unless it is + /// diverging (InlineAsmOptions::NORETURN). + destination: Option, + }, +} + +pub enum InlineAsmOperand<'tcx> { + In { + reg: InlineAsmRegOrRegClass, + value: Operand<'tcx>, + }, + Out { + reg: InlineAsmRegOrRegClass, + late: bool, + place: Option>, + }, + InOut { + reg: InlineAsmRegOrRegClass, + late: bool, + in_value: Operand<'tcx>, + out_place: Option>, + }, + Const { + value: Box>, + }, + SymFn { + value: Box>, + }, + SymStatic { + def_id: DefId, + }, +} +``` + +As part of HAIR lowering, `InOut` and `SplitInOut` operands are lowered to a split form with a +separate `in_value` and `out_place`. + +Semantically, the `InlineAsm` terminator is similar to the `Call` terminator except that it has +multiple output places where a `Call` only has a single return place output. + +## Codegen + +Operands are lowered one more time before being passed to LLVM codegen: + +```rust +pub enum InlineAsmOperandRef<'tcx, B: BackendTypes + ?Sized> { + In { + reg: InlineAsmRegOrRegClass, + value: OperandRef<'tcx, B::Value>, + }, + Out { + reg: InlineAsmRegOrRegClass, + late: bool, + place: Option>, + }, + InOut { + reg: InlineAsmRegOrRegClass, + late: bool, + in_value: OperandRef<'tcx, B::Value>, + out_place: Option>, + }, + Const { + string: String, + }, + SymFn { + instance: Instance<'tcx>, + }, + SymStatic { + def_id: DefId, + }, +} +``` + +The operands are lowered to LLVM operands and constraint codes as follow: +- `out` and the output part of `inout` operands are added first, as required by LLVM. Late output +operands have a `=` prefix added to their constraint code, non-late output operands have a `=&` +prefix added to their constraint code. +- `in` operands are added normally. +- `inout` operands are tied to the matching output operand. +- `sym` operands are passed as function pointers or pointers, using the `"s"` constraint. +- `const` operands are formatted to a string and directly inserted in the template string. + +The template string is converted to LLVM form: +- `$` characters are escaped as `$$`. +- `const` operands are converted to strings and inserted directly. +- Placeholders are formatted as `${X:M}` where `X` is the operand index and `M` is the modifier +character. Modifiers are converted from the Rust form to the LLVM form. + +The various options are converted to clobber constraints or LLVM attributes, refer to the +[RFC](https://github.com/Amanieu/rfcs/blob/inline-asm/text/0000-inline-asm.md#mapping-to-llvm-ir) +for more details. + +Note that LLVM is sometimes rather picky about what types it accepts for certain constraint codes +so we sometimes need to insert conversions to/from a supported type. See the target-specific +ISelLowering.cpp files in LLVM for details of what types are supported for each register class. + +## Adding support for new architectures + +Adding inline assembly support to an architecture is mostly a matter of defining the registers and +register classes for that architecture. All the definitions for register classes are located in +`compiler/rustc_target/asm/`. + +Additionally you will need to implement lowering of these register classes to LLVM constraint codes +in `compiler/rustc_codegen_llvm/asm.rs`. + +When adding a new architecture, make sure to cross-reference with the LLVM source code: +- LLVM has restrictions on which types can be used with a particular constraint code. Refer to the +`getRegForInlineAsmConstraint` function in `lib/Target/${ARCH}/${ARCH}ISelLowering.cpp`. +- LLVM reserves certain registers for its internal use, which causes them to not be saved/restored +properly around inline assembly blocks. These registers are listed in the `getReservedRegs` +function in `lib/Target/${ARCH}/${ARCH}RegisterInfo.cpp`. Any "conditionally" reserved register +such as the frame/base pointer must always be treated as reserved for Rust purposes because we +can't know ahead of time whether a function will require a frame/base pointer. + +## Tests + +Various tests for inline assembly are available: + +- `src/test/assembly/asm` +- `src/test/ui/asm` +- `src/test/codegen/asm-*` + +Every architecture supported by inline assembly must have exhaustive tests in +`src/test/assembly/asm` which test all combinations of register classes and types. From 78dd6a4684cf8d6b72275fab6d0429ea40b66338 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 18 Jan 2022 09:44:26 -0800 Subject: [PATCH 1614/1812] Reorganize and expand the testing chapters. (#1281) * Reorganize and expand the testing chapters. * Update tests chapters for review comments. * Fix typo. --- book.toml | 3 + src/SUMMARY.md | 10 +- src/compiletest.md | 223 ------------- src/profiling.md | 7 +- src/tests/adding.md | 663 ++++++++------------------------------- src/tests/ci.md | 73 +++++ src/tests/compiletest.md | 526 +++++++++++++++++++++++++++++++ src/tests/crater.md | 45 +++ src/tests/docker.md | 52 +++ src/tests/headers.md | 403 ++++++++++++++++++++++++ src/tests/intro.md | 464 ++++++++------------------- src/tests/perf.md | 50 +++ src/tests/running.md | 136 +++++++- src/tests/ui.md | 500 +++++++++++++++++++++++++++++ 14 files changed, 2055 insertions(+), 1100 deletions(-) delete mode 100644 src/compiletest.md create mode 100644 src/tests/ci.md create mode 100644 src/tests/compiletest.md create mode 100644 src/tests/crater.md create mode 100644 src/tests/docker.md create mode 100644 src/tests/headers.md create mode 100644 src/tests/perf.md create mode 100644 src/tests/ui.md diff --git a/book.toml b/book.toml index f53ed45f6..336e5a369 100644 --- a/book.toml +++ b/book.toml @@ -24,3 +24,6 @@ follow-web-links = true exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il", "www\\.amazon\\.com", "www\\.rustaceans\\.org", "play\\.rust-lang\\.org" ] cache-timeout = 86400 warning-policy = "error" + +[output.html.redirect] +"/compiletest.html" = "tests/compiletest.html" diff --git a/src/SUMMARY.md b/src/SUMMARY.md index fa044bce5..3189b9364 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -15,10 +15,16 @@ - [Documenting Compiler](./building/compiler-documenting.md) - [Rustdoc overview](./rustdoc.md) - [Adding a new target](./building/new-target.md) -- [The compiler testing framework](./tests/intro.md) +- [Testing the compiler](./tests/intro.md) - [Running tests](./tests/running.md) + - [Testing with Docker](./tests/docker.md) + - [Testing with CI](./tests/ci.md) - [Adding new tests](./tests/adding.md) - - [Using `compiletest` commands to control test execution](./compiletest.md) + - [Compiletest](./tests/compiletest.md) + - [UI tests](./tests/ui.md) + - [Test headers](./tests/headers.md) + - [Performance testing](./tests/perf.md) + - [Crater](./tests/crater.md) - [Debugging the Compiler](./compiler-debugging.md) - [Using the tracing/logging instrumentation](./tracing.md) - [Profiling the compiler](./profiling.md) diff --git a/src/compiletest.md b/src/compiletest.md deleted file mode 100644 index 2d34ea04f..000000000 --- a/src/compiletest.md +++ /dev/null @@ -1,223 +0,0 @@ -# Using `compiletest` commands to control test execution - -## Introduction - -`compiletest` is the main test harness of the Rust test suite. It allows -test authors to organize large numbers of tests (the Rust compiler has many -thousands), efficient test execution (parallel execution is supported), and -allows the test author to configure behavior and expected results of both -individual and groups of tests. - -`compiletest` tests may check test code for success, for runtime failure, or for -compile-time failure. Tests are typically organized as a Rust source file with -annotations in comments before and/or within the test code, which serve to -direct `compiletest` on if or how to run the test, what behavior to expect, -and more. If you are unfamiliar with the compiler testing framework, -see [this chapter](./tests/intro.md) for additional background. - -The tests themselves are typically (but not always) organized into -"suites" – for example, `incremental`, a folder holding tests that check -incremental compilation behavior, `codegen`, -a folder holding tests that check code generation, and many more. The various -suites are defined in [`src/tools/compiletest/src/common.rs`] in the -`pub enum Mode` declaration. And a good introduction to the different -suites of compiler tests along with details about them can be found in -[Adding new tests](./tests/adding.md). - -## Adding a new test file - -Briefly, simply create your new test in the appropriate location under -[`src/test`]. No registration of test files is necessary as `compiletest` -will scan the [`src/test`] subfolder recursively, and will execute any -Rust source files it finds as tests. -See [Adding new tests](./tests/adding.md) for a complete guide on how to add -new tests. - -## Header Commands - -Source file annotations which appear in comments near the top of the source -file *before* any test code are known as header commands. These commands can -instruct `compiletest` to ignore this test, set expectations on whether it is -expected to succeed at compiling, or what the test's return code is expected to -be. Header commands and inline `//~ ERROR` commands are described more fully -[here](./tests/adding.md#header-commands-configuring-rustc). - -### Adding a new header command - -Header commands are defined in the `TestProps` struct in -[`src/tools/compiletest/src/header.rs`]. At a high level, there are -dozens of test properties defined here, all set to default values in the -`TestProp` struct's `impl` block. Any test can override this default value by -specifying the property in question as header command as a comment (`//`) in -the test source file, before any source code. - -#### Using a header command - -Here is an example, specifying the `must-compile-successfully` header command, -which takes no arguments, followed by the `failure-status` header command, -which takes a single argument (which, in this case is a value of 1). -`failure-status` is instructing `compiletest` to expect a failure status of 1 -(rather than the current Rust default of 101). The header command and -the argument list (if present) are typically separated by a colon: - -```rust,ignore -// must-compile-successfully -// failure-status: 1 - -#![feature(termination_trait)] - -use std::io::{Error, ErrorKind}; - -fn main() -> Result<(), Box> { - Err(Box::new(Error::new(ErrorKind::Other, "returned Box from main()"))) -} -``` - -#### Adding a new header command property - -One would add a new header command if there is a need to define some test -property or behavior on an individual, test-by-test basis. A header command -property serves as the header command's backing store (holds the command's -current value) at runtime. - -To add a new header command property: - - 1. Look for the `pub struct TestProps` declaration in - [`src/tools/compiletest/src/header.rs`] and add the new public property to - the end of the declaration. - 2. Look for the `impl TestProps` implementation block immediately following - the struct declaration and initialize the new property to its default - value. - -#### Adding a new header command parser - -When `compiletest` encounters a test file, it parses the file a line at a time -by calling every parser defined in the `Config` struct's implementation block, -also in [`src/tools/compiletest/src/header.rs`][] (note that the `Config` -struct's declaration block is found in [`src/tools/compiletest/src/common.rs`]). -`TestProps`'s `load_from()` method will try passing the current line of text to -each parser, which, in turn typically checks to see if the line begins with a -particular commented (`//`) header command such as `// must-compile-successfully` -or `// failure-status`. Whitespace after the comment marker is optional. - -Parsers will override a given header command property's default value merely by -being specified in the test file as a header command or by having a parameter -value specified in the test file, depending on the header command. - -Parsers defined in `impl Config` are typically named `parse_` -(note kebab-case `` transformed to snake-case -``). `impl Config` also defines several 'low-level' parsers -which make it simple to parse common patterns like simple presence or not -(`parse_name_directive()`), header-command:parameter(s) -(`parse_name_value_directive()`), optional parsing only if a particular `cfg` -attribute is defined (`has_cfg_prefix()`) and many more. The low-level parsers -are found near the end of the `impl Config` block; be sure to look through them -and their associated parsers immediately above to see how they are used to -avoid writing additional parsing code unnecessarily. - -As a concrete example, here is the implementation for the -`parse_failure_status()` parser, in [`src/tools/compiletest/src/header.rs`]: - -```diff -@@ -232,6 +232,7 @@ pub struct TestProps { - // customized normalization rules - pub normalize_stdout: Vec<(String, String)>, - pub normalize_stderr: Vec<(String, String)>, -+ pub failure_status: i32, - } - - impl TestProps { -@@ -260,6 +261,7 @@ impl TestProps { - run_pass: false, - normalize_stdout: vec![], - normalize_stderr: vec![], -+ failure_status: 101, - } - } - -@@ -383,6 +385,10 @@ impl TestProps { - if let Some(rule) = config.parse_custom_normalization(ln, "normalize-stderr") { - self.normalize_stderr.push(rule); - } -+ -+ if let Some(code) = config.parse_failure_status(ln) { -+ self.failure_status = code; -+ } - }); - - for key in &["RUST_TEST_NOCAPTURE", "RUST_TEST_THREADS"] { -@@ -488,6 +494,13 @@ impl Config { - self.parse_name_directive(line, "pretty-compare-only") - } - -+ fn parse_failure_status(&self, line: &str) -> Option { -+ match self.parse_name_value_directive(line, "failure-status") { -+ Some(code) => code.trim().parse::().ok(), -+ _ => None, -+ } -+ } -``` - -## Implementing the behavior change - -When a test invokes a particular header command, it is expected that some -behavior will change as a result. What behavior, obviously, will depend on the -purpose of the header command. In the case of `failure-status`, the behavior -that changes is that `compiletest` expects the failure code defined by the -header command invoked in the test, rather than the default value. - -Although specific to `failure-status` (as every header command will have a -different implementation in order to invoke behavior change) perhaps it is -helpful to see the behavior change implementation of one case, simply as an -example. To implement `failure-status`, the `check_correct_failure_status()` -function found in the `TestCx` implementation block, located in -[`src/tools/compiletest/src/runtest.rs`], was modified as per below: - -```diff -@@ -295,11 +295,14 @@ impl<'test> TestCx<'test> { - } - - fn check_correct_failure_status(&self, proc_res: &ProcRes) { -- // The value the Rust runtime returns on failure -- const RUST_ERR: i32 = 101; -- if proc_res.status.code() != Some(RUST_ERR) { -+ let expected_status = Some(self.props.failure_status); -+ let received_status = proc_res.status.code(); -+ -+ if expected_status != received_status { - self.fatal_proc_rec( -- &format!("failure produced the wrong error: {}", proc_res.status), -+ &format!("Error: expected failure status ({:?}) but received status {:?}.", -+ expected_status, -+ received_status), - proc_res, - ); - } -@@ -320,7 +323,6 @@ impl<'test> TestCx<'test> { - ); - - let proc_res = self.exec_compiled_test(); -- - if !proc_res.status.success() { - self.fatal_proc_rec("test run failed!", &proc_res); - } -@@ -499,7 +501,6 @@ impl<'test> TestCx<'test> { - expected, - actual - ); -- panic!(); - } - } -``` -Note the use of `self.props.failure_status` to access the header command -property. In tests which do not specify the failure status header command, -`self.props.failure_status` will evaluate to the default value of 101 at the -time of this writing. But for a test which specifies a header command of, for -example, `// failure-status: 1`, `self.props.failure_status` will evaluate to -1, as `parse_failure_status()` will have overridden the `TestProps` default -value, for that test specifically. - -[`src/test`]: https://github.com/rust-lang/rust/tree/master/src/test -[`src/tools/compiletest/src/header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs -[`src/tools/compiletest/src/common.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs -[`src/tools/compiletest/src/runtest.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs diff --git a/src/profiling.md b/src/profiling.md index ae76d977f..0d333f7be 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -4,11 +4,8 @@ This section talks about how to profile the compiler and find out where it spend Depending on what you're trying to measure, there are several different approaches: -- If you want to see if a PR improves or regresses compiler performance: - - The [rustc-perf](https://github.com/rust-lang/rustc-perf) project makes this easy and can be triggered to run on a PR via the `@rust-timer` bot. - The `@bors try @rust-timer queue` command, in a comment on the PR, will queue a try build and a - benchmarking run. - Note: you need `try` privileges to be able to do this. More details are available in the [perf collector documentation](https://github.com/rust-lang/rustc-perf/blob/master/collector/README.md). +- If you want to see if a PR improves or regresses compiler performance, + see the [rustc-perf chapter](tests/perf.md) for requesting a benchmarking run. - If you want a medium-to-high level overview of where `rustc` is spending its time: - The `-Z self-profile` flag and [measureme](https://github.com/rust-lang/measureme) tools offer a query-based approach to profiling. diff --git a/src/tests/adding.md b/src/tests/adding.md index d7ad2871d..2fb1e0b65 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -7,574 +7,189 @@ accompanied by a regression test of some kind.** This test should fail in master but pass after the PR. These tests are really useful for preventing us from repeating the mistakes of the past. -To add a new test, the first thing you generally do is to create a -file, typically a Rust source file. Test files have a particular -structure: - -- They should have some kind of - [comment explaining what the test is about](#explanatory_comment); -- next, they can have one or more [header commands](#header_commands), which - are special comments that the test interpreter knows how to interpret. -- finally, they have the Rust source. This may have various [error - annotations](#error_annotations) which indicate expected compilation errors or - warnings. - -Depending on the test suite, there may be some other details to be aware of: - - For [the `ui` test suite](#ui), you need to generate reference output files. - -## What kind of test should I add? - -It can be difficult to know what kind of test to use. Here are some -rough heuristics: - -- Some tests have specialized needs: - - need to run gdb or lldb? use the `debuginfo` test suite - - need to inspect LLVM IR or MIR IR? use the `codegen` or `mir-opt` test - suites - - need to run rustdoc? Prefer a `rustdoc` or `rustdoc-ui` test. - Occasionally you'll need `rustdoc-js` as well. - - need to inspect the resulting binary in some way? Then use `run-make` -- Library tests should go in `library/${crate}/tests` (where `${crate}` is - usually `core`, `alloc`, or `std`). Library tests include: - - tests that an API behaves properly, including accepting various types or - having some runtime behavior - - tests where any compiler warnings are not relevant to the test - - tests that a use of an API gives a compile error, where the exact error - message is not relevant to the test. These should have an - [error number] (`E0XXX`) in the code block to make sure it's the correct error. -- For most other things, [a `ui` (or `ui-fulldeps`) test](#ui) is to be preferred: - - in the case of warnings or errors, `ui` tests capture the full output, - which makes it easier to review but also helps prevent "hidden" regressions - in the output - -[error number]: https://doc.rust-lang.org/rustdoc/unstable-features.html#error-numbers-for-compile-fail-doctests - -## Naming your test - -We have not traditionally had a lot of structure in the names of -tests. Moreover, for a long time, the rustc test runner did not -support subdirectories (it now does), so test suites like -[`src/test/ui`] have a huge mess of files in them. This is not -considered an ideal setup. - +The first thing to decide is which kind of test to add. +This will depend on the nature of the change and what you want to exercise. +Here are some rough guidelines: + +- The majority of compiler tests are done with [compiletest]. + - The majority of compiletest tests are [UI](ui.md) tests in the [`src/test/ui`] directory. +- Changes to the standard library are usually tested within the standard library itself. + - The majority of standard library tests are written as doctests, + which illustrate and exercise typical API behavior. + - Additional [unit tests](intro.md#package-tests) should go in + `library/${crate}/tests` (where `${crate}` is usually `core`, `alloc`, or `std`). +- If the code is part of an isolated system, and you are not testing compiler output, + consider using a [unit or integration test](intro.md#package-tests). +- Need to run rustdoc? Prefer a `rustdoc` or `rustdoc-ui` test. + Occasionally you'll need `rustdoc-js` as well. +- Other compiletest test suites are generally used for special purposes: + - Need to run gdb or lldb? Use the `debuginfo` test suite. + - Need to inspect LLVM IR or MIR IR? Use the `codegen` or `mir-opt` test suites. + - Need to inspect the resulting binary in some way? + Then use `run-make`. + - Check out the [compiletest] chapter for more specialized test suites. + +[compiletest]: compiletest.md [`src/test/ui`]: https://github.com/rust-lang/rust/tree/master/src/test/ui/ -For regression tests – basically, some random snippet of code that -came in from the internet – we often name the test after the issue -plus a short description. Ideally, the test should be added to a -directory that helps identify what piece of code is being tested here -(e.g., `src/test/ui/borrowck/issue-54597-reject-move-out-of-borrow-via-pat.rs`) -If you've tried and cannot find a more relevant place, -the test may be added to `src/test/ui/issues/`. -Still, **do include the issue number somewhere**. -But please avoid putting your test there as possible since that -directory has too many tests and it causes poor semantic organization. - -When writing a new feature, **create a subdirectory to store your -tests**. For example, if you are implementing RFC 1234 ("Widgets"), -then it might make sense to put the tests in a directory like -`src/test/ui/rfc1234-widgets/`. - -In other cases, there may already be a suitable directory. (The proper -directory structure to use is actually an area of active debate.) - - - -## Comment explaining what the test is about - -When you create a test file, **include a comment summarizing the point -of the test at the start of the file**. This should highlight which -parts of the test are more important, and what the bug was that the -test is fixing. Citing an issue number is often very helpful. - -This comment doesn't have to be super extensive. Just something like -"Regression test for #18060: match arms were matching in the wrong -order." might already be enough. +## UI test walkthrough -These comments are very useful to others later on when your test -breaks, since they often can highlight what the problem is. They are -also useful if for some reason the tests need to be refactored, since -they let others know which parts of the test were important (often a -test must be rewritten because it no longer tests what is was meant to -test, and then it's useful to know what it *was* meant to test -exactly). +The following is a basic guide for creating a [UI test](ui.md), which is one +of the most common compiler tests. +For this tutorial, we'll be adding a test for an async error message. -     +### Step 1. Add a test file -## Header commands: configuring rustc +The first step is to create a Rust source file somewhere in the +[`src/test/ui`] tree. +When creating a test, do your best to find a good location and name (see [Test +organization](ui.md#test-organization) for more). +Since naming is the hardest part of development, everything should be downhill +from here! -Header commands are special comments that the test runner knows how to -interpret. They must appear before the Rust source in the test. They -are normally put after the short comment that explains the point of -this test. For example, this test uses the `// compile-flags` command -to specify a custom flag to give to rustc when the test is compiled: +Let's place our async test at `src/test/ui/async-await/await-without-async.rs`: ```rust,ignore -// Test the behavior of `0 - 1` when overflow checks are disabled. +// Check what happens when using await in a non-async fn. +// edition:2018 -// compile-flags: -C overflow-checks=off +async fn foo() {} -fn main() { - let x = 0 - 1; - ... +fn bar() { + foo().await } -``` -### Ignoring tests - -These are used to ignore the test in some situations, which means the test won't -be compiled or run. - -* `ignore-X` where `X` is a target detail or stage will ignore the - test accordingly (see below) -* `only-X` is like `ignore-X`, but will *only* run the test on that - target or stage -* `ignore-pretty` will not compile the pretty-printed test (this is - done to test the pretty-printer, but might not always work) -* `ignore-test` always ignores the test -* `ignore-lldb` and `ignore-gdb` will skip a debuginfo test on that - debugger. -* `ignore-gdb-version` can be used to ignore the test when certain gdb - versions are used - -Some examples of `X` in `ignore-X`: - -* Architecture: `aarch64`, `arm`, `asmjs`, `mips`, `wasm32`, `x86_64`, - `x86`, ... -* OS: `android`, `emscripten`, `freebsd`, `ios`, `linux`, `macos`, - `windows`, ... -* Environment (fourth word of the target triple): `gnu`, `msvc`, - `musl`. -* Pointer width: `32bit`, `64bit`. -* Stage: `stage0`, `stage1`, `stage2`. -* When cross compiling: `cross-compile` -* When remote testing is used: `remote` -* When debug-assertions are enabled: `debug` -* When particular debuggers are being tested: `cdb`, `gdb`, `lldb` -* Specific compare modes: `compare-mode-nll`, `compare-mode-polonius` - -### Other Header Commands - -Here is a list of other header commands. This list is not -exhaustive. Header commands can generally be found by browsing the -`TestProps` structure found in [`header.rs`] from the compiletest -source. - -* `run-rustfix` for UI tests, indicates that the test produces - structured suggestions. The test writer should create a `.fixed` - file, which contains the source with the suggestions applied. - When the test is run, compiletest first checks that the correct - lint/warning is generated. Then, it applies the suggestion and - compares against `.fixed` (they must match). Finally, the fixed - source is compiled, and this compilation is required to succeed. - The `.fixed` file can also be generated automatically with the - `--bless` option, described in [this section][bless]. -* `rustfix-only-machine-applicable` is equivalent to `run-rustfix` except it - will only apply [`MachineApplicable`](../diagnostics.md#suggestions) - suggestions. `run-rustfix` will apply *all* suggestions. This should be used - if there is a mixture of different suggestion levels, and some of the - non-machine-applicable ones do not apply cleanly. -* `min-gdb-version` specifies the minimum gdb version required for - this test; see also `ignore-gdb-version` -* `min-lldb-version` specifies the minimum lldb version required for - this test -* `rust-lldb` causes the lldb part of the test to only be run if the - lldb in use contains the Rust plugin -* `no-system-llvm` causes the test to be ignored if the system llvm is used -* `min-llvm-version` specifies the minimum llvm version required for - this test -* `min-system-llvm-version` specifies the minimum system llvm version - required for this test; the test is ignored if the system llvm is in - use and it doesn't meet the minimum version. This is useful when an - llvm feature has been backported to rust-llvm -* `ignore-llvm-version` can be used to skip the test when certain LLVM - versions are used. This takes one or two arguments; the first - argument is the first version to ignore. If no second argument is - given, all subsequent versions are ignored; otherwise, the second - argument is the last version to ignore. -* `build-pass` for UI tests, indicates that the test is supposed to - successfully compile and link, as opposed to the default where the test is - supposed to error out. -* `compile-flags` passes extra command-line args to the compiler, - e.g. `compile-flags -g` which forces debuginfo to be enabled. -* `edition` controls the edition the test should be compiled with - (defaults to 2015). Example usage: `// edition:2018`. -* `should-fail` indicates that the test should fail; used for "meta - testing", where we test the compiletest program itself to check that - it will generate errors in appropriate scenarios. This header is - ignored for pretty-printer tests. -* `gate-test-X` where `X` is a feature marks the test as "gate test" - for feature X. Such tests are supposed to ensure that the compiler - errors when usage of a gated feature is attempted without the proper - `#![feature(X)]` tag. Each unstable lang feature is required to - have a gate test. -* `needs-profiler-support` - a profiler runtime is required, i.e., - `profiler = true` in rustc's `config.toml`. -* `needs-sanitizer-support` - a sanitizer runtime is required, i.e., - `sanitizers = true` in rustc's `config.toml`. -* `needs-sanitizer-{address,hwaddress,leak,memory,thread}` - indicates that - test requires a target with a support for AddressSanitizer, hardware-assisted - AddressSanitizer, LeakSanitizer, MemorySanitizer or ThreadSanitizer - respectively. -* `error-pattern` checks the diagnostics just like the `ERROR` annotation - without specifying error line. This is useful when the error doesn't give - any span. -* `incremental` runs the test with the `-C incremental` flag and an empty - incremental directory. This should be avoided when possible; you should use - an *incremental mode* test instead. Incremental mode tests support running - the compiler multiple times and verifying that it can load the generated - incremental cache. This flag is for specialized circumstances, like checking - the interaction of codegen unit partitioning with generating an incremental - cache. -* `aux-build` is used to compile additional crates to link. Just pass it the - name of the source file. The source file should be in a directory called - `auxiliary` beside the test file. The aux crate will be built as a dylib if - possible (unless on a platform that does not support them, or - `no-prefer-dynamic` is specified in the aux file). The `-L` flag is used to - find the extern crates. -* `aux-crate` is very similar to `aux-build`; however, it uses the `--extern` - flag to link to the extern crate. That allows you to specify the additional - syntax of the `--extern` flag, such as renaming a dependency. For example, - `// aux-crate:foo=bar.rs` will compile `auxiliary/bar.rs` and make it - available under then name `foo` within the test. This is similar to how - Cargo does dependency renaming. -* `no-prefer-dynamic` will force an auxiliary crate to be built as an rlib - instead of a dylib. When specified in a test, it will remove the use of `-C - prefer-dynamic`. This can be useful in a variety of circumstances. For - example, it can prevent a proc-macro from being built with the wrong crate - type. Or if your test is specifically targeting behavior of other crate - types, it can be used to prevent building with the wrong crate type. -* `force-host` will force the test to build for the host platform instead of - the target. This is useful primarily for auxiliary proc-macros, which need - to be loaded by the host compiler. -* `pretty-mode` specifies the mode pretty-print tests should run in. - The default is `normal` if not specified. -* `pretty-compare-only` causes a pretty test to only compare the - pretty-printed output. It will not try to compile the expanded output to - typecheck it. This is needed for a pretty-mode that does not expand to valid - Rust, or for other situations where the expanded output cannot be compiled. -* `pretty-expanded` allows a pretty test to also run with - `-Zunpretty=expanded` as a final step. It will also try to compile the - resulting output (without codegen). This is needed because not all code can - be compiled after being expanded. Pretty tests should specify this if they - can. An example where this cannot be used is if the test includes - `println!`. That macro expands to reference private internal functions of - the standard library that cannot be called directly without the - `fmt_internals` feature gate. - - More history about this may be found in [#23616]. -* `pp-exact` is used to ensure a pretty-print test results in specific output. - If specified without a value, then it means the pretty-print output should - match the original source. If specified with a value, as in `// - pp-exact:foo.pp`, it will ensure that the pretty-printed output matches the - contents of the given file. Otherwise, if `pp-exact` is not specified, then - the pretty-printed output will be pretty-printed one more time, and the - output of the two pretty-printing rounds will be compared to ensure that the - pretty-printed output converges to a steady state. - -[`header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs -[bless]: ./running.md#editing-and-updating-the-reference-files -[#23616]: https://github.com/rust-lang/rust/issues/23616#issuecomment-484999901 - - - -## Error annotations - -Error annotations specify the errors that the compiler is expected to -emit. They are "attached" to the line in source where the error is -located. Error annotations are considered during tidy lints of line -length and should be formatted according to tidy requirements. You may -use an error message prefix sub-string if necessary to meet line length -requirements. Make sure that the text is long enough for the error -message to be self-documenting. - -The error annotation definition and source line definition association -is defined with the following set of idioms: - -* `~`: Associates the following error level and message with the - current line -* `~|`: Associates the following error level and message with the same - line as the previous comment -* `~^`: Associates the following error level and message with the - previous error annotation line. Each caret (`^`) that you add adds - a line to this, so `~^^^` is three lines above the error annotation - line. - -### Error annotation examples - -Here are examples of error annotations on different lines of UI test -source. - -#### Positioned on error line - -Use the `//~ ERROR` idiom: - -```rust,ignore -fn main() { - let x = (1, 2, 3); - match x { - (_a, _x @ ..) => {} //~ ERROR `_x @` is not allowed in a tuple - _ => {} - } -} +fn main() {} ``` -#### Positioned below error line - -Use the `//~^` idiom with number of carets in the string to indicate the -number of lines above. In the example below, the error line is four -lines above the error annotation line so four carets are included in -the annotation. - -```rust,ignore -fn main() { - let x = (1, 2, 3); - match x { - (_a, _x @ ..) => {} // <- the error is on this line - _ => {} - } -} -//~^^^^ ERROR `_x @` is not allowed in a tuple +A few things to notice about our test: + +* The top should start with a short comment that [explains what the test is + for](#explanatory_comment). +* The `// edition:2018` comment is called a [header](headers.md) which provides + instructions to compiletest on how to build the test. + Here we need to set the edition for `async` to work (the default is 2015). +* Following that is the source of the test. + Try to keep it succinct and to the point. + This may require some effort if you are trying to minimize an example from a + bug report. +* We end this test with an empty `fn main` function. + This is because the default for UI tests is a `bin` crate-type, + and we don't want the "main not found" error in our test. + Alternatively, you could add `#![crate_type="lib"]`. + +### Step 2. Generate the expected output + +The next step is to create the expected output from the compiler. +This can be done with the `--bless` option: + +```sh +./x.py test src/test/ui/async-await/await-without-async.rs --bless ``` -#### Use same error line as defined on error annotation line above +This will build the compiler (if it hasn't already been built), compile the +test, and place the output of the compiler in a file called +`src/test/ui/async-await/await-without-async.stderr`. -Use the `//~|` idiom to define the same error line as -the error annotation line above: +However, this step will fail! +You should see an error message, something like this: -```rust,ignore -struct Binder(i32, i32, i32); - -fn main() { - let x = Binder(1, 2, 3); - match x { - Binder(_a, _x @ ..) => {} // <- the error is on this line - _ => {} - } -} -//~^^^^ ERROR `_x @` is not allowed in a tuple struct -//~| ERROR this pattern has 1 field, but the corresponding tuple struct has 3 fields [E0023] -``` +> error: /rust/src/test/ui/async-await/await-without-async.rs:7: unexpected +> error: '7:10: 7:16: `await` is only allowed inside `async` functions and +> blocks [E0728]' -#### When error line cannot be specified +### Step 3. Add error annotations -Let's think about this test: +Every error needs to be annotated with a comment in the source with the text +of the error. +In this case, we can add the following comment to our test file: ```rust,ignore -fn main() { - let a: *const [_] = &[1, 2, 3]; - unsafe { - let _b = (*a)[3]; - } +fn bar() { + foo().await +//~^ ERROR `await` is only allowed inside `async` functions and blocks } ``` -We want to ensure this shows "index out of bounds" but we cannot use the `ERROR` annotation -since the error doesn't have any span. Then it's time to use the `error-pattern`: +The `//~^` squiggle caret comment tells compiletest that the error belongs to +the previous line (more on this in the [Error +annotations](ui.md#error-annotations) section). -```rust,ignore -// error-pattern: index out of bounds -fn main() { - let a: *const [_] = &[1, 2, 3]; - unsafe { - let _b = (*a)[3]; - } -} -``` +Save that, and run the test again: -But for strict testing, try to use the `ERROR` annotation as much as possible. +```sh +./x.py test src/test/ui/async-await/await-without-async.rs +``` -#### Error levels +It should now pass, yay! -The error levels that you can have are: +### Step 4. Review the output -1. `ERROR` -2. `WARNING` -3. `NOTE` -4. `HELP` and `SUGGESTION`[^sugg-placement] +Somewhat hand-in-hand with the previous step, you should inspect the `.stderr` +file that was created to see if it looks like how you expect. +If you are adding a new diagnostic message, now would be a good time to +also consider how readable the message looks overall, particularly for +people new to Rust. -[^sugg-placement]: **Note**: `SUGGESTION` must follow immediately after `HELP`. +Our example `src/test/ui/async-await/await-without-async.stderr` file should +look like this: -## Revisions +```text +error[E0728]: `await` is only allowed inside `async` functions and blocks + --> $DIR/await-without-async.rs:7:10 + | +LL | fn bar() { + | --- this is not `async` +LL | foo().await + | ^^^^^^ only allowed inside `async` functions and blocks -Certain classes of tests support "revisions" (as of February 2021, -this includes compile-fail, run-fail, and incremental, though -incremental tests are somewhat different). Revisions allow a single test file to -be used for multiple tests. This is done by adding a special header at the top -of the file: +error: aborting due to previous error -```rust -// revisions: foo bar baz +For more information about this error, try `rustc --explain E0728`. ``` -This will result in the test being compiled (and tested) three times, -once with `--cfg foo`, once with `--cfg bar`, and once with `--cfg -baz`. You can therefore use `#[cfg(foo)]` etc within the test to tweak -each of these results. - -You can also customize headers and expected error messages to a particular -revision. To do this, add `[foo]` (or `bar`, `baz`, etc) after the `//` -comment, like so: +You may notice some things look a little different than the regular +compiler output. +The `$DIR` removes the path information which will differ between systems. +The `LL` values replace the line numbers. +That helps avoid small changes in the source from triggering large diffs. +See the [Normalization](ui.md#normalization) section for more. -```rust -// A flag to pass in only for cfg `foo`: -//[foo]compile-flags: -Z verbose +Around this stage, you may need to iterate over the last few steps a few times +to tweak your test, re-bless the test, and re-review the output. -#[cfg(foo)] -fn test_foo() { - let x: usize = 32_u32; //[foo]~ ERROR mismatched types -} -``` - -Note that not all headers have meaning when customized to a revision. -For example, the `ignore-test` header (and all "ignore" headers) -currently only apply to the test as a whole, not to particular -revisions. The only headers that are intended to really work when -customized to a revision are error patterns and compiler flags. - - - -## Guide to the UI tests - -The UI tests are intended to capture the compiler's complete output, -so that we can test all aspects of the presentation. They work by -compiling a file (e.g., [`ui/hello_world/main.rs`][hw-main]), -capturing the output, and then applying some normalization (see -below). This normalized result is then compared against reference -files named `ui/hello_world/main.stderr` and -`ui/hello_world/main.stdout`. If either of those files doesn't exist, -the output must be empty (that is actually the case for -[this particular test][hw]). If the test run fails, we will print out -the current output, but it is also saved in -`build//test/ui/hello_world/main.stdout` (this path is -printed as part of the test failure message), so you can run `diff` -and so forth. - -[hw-main]: https://github.com/rust-lang/rust/blob/master/src/test/ui/hello_world/main.rs -[hw]: https://github.com/rust-lang/rust/blob/master/src/test/ui/hello_world/ - -We now have a ton of UI tests and some directories have too many entries. -This is a problem because it isn't editor/IDE friendly and GitHub UI won't -show more than 1000 entries. To resolve it and organize semantic structure, -we have a tidy check to ensure the number of entries is less than 1000. -However, since `src/test/ui` (UI test root directory) and -`src/test/ui/issues` directories have more than 1000 entries, -we set a different limit for each directories. So, please -avoid putting a new test there and try to find a more relevant place. -For example, if your test is related to closures, you should put it in -`src/test/ui/closures`. If you're not sure where is the best place, -it's still okay to add to `src/test/ui/issues/`. When you reach the limit, -you could increase it by tweaking [here][ui test tidy]. - -[ui test tidy]: https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/ui_tests.rs - -### Tests that do not result in compile errors - -By default, a UI test is expected **not to compile** (in which case, -it should contain at least one `//~ ERROR` annotation). However, you -can also make UI tests where compilation is expected to succeed, and -you can even run the resulting program. Just add one of the following -[header commands](#header_commands): - -- `// check-pass` - compilation should succeed but skip codegen - (which is expensive and isn't supposed to fail in most cases) -- `// build-pass` – compilation and linking should succeed but do - not run the resulting binary -- `// run-pass` – compilation should succeed and we should run the - resulting binary - -### Output Normalization - -The compiler output is normalized to eliminate output difference between -platforms, mainly about filenames. - -The following strings replace their corresponding values: - -- `$DIR`: The directory where the test is defined. - - Example: `/path/to/rust/src/test/ui/error-codes` -- `$SRC_DIR`: The root source directory. - - Example: `/path/to/rust/src` -- `$TEST_BUILD_DIR`: The base directory where the test's output goes. - - Example: `/path/to/rust/build/x86_64-unknown-linux-gnu/test/ui` - -Additionally, the following changes are made: - -- Line and column numbers for paths in `$SRC_DIR` are replaced with `LL:CC`. - For example, `/path/to/rust/library/core/src/clone.rs:122:8` is replaced with - `$SRC_DIR/core/src/clone.rs:LL:COL`. - - Note: The line and column numbers for `-->` lines pointing to the test are - *not* normalized, and left as-is. This ensures that the compiler continues - to point to the correct location, and keeps the stderr files readable. - Ideally all line/column information would be retained, but small changes to - the source causes large diffs, and more frequent merge conflicts and test - errors. See also `-Z ui-testing` below which applies additional line number - normalization. -- `\t` is replaced with an actual tab character. -- Error line annotations like `// ~ERROR some message` are removed. -- Backslashes (`\`) are converted to forward slashes (`/`) within paths (using - a heuristic). This helps normalize differences with Windows-style paths. -- CRLF newlines are converted to LF. - -Additionally, the compiler is run with the `-Z ui-testing` flag which causes -the compiler itself to apply some changes to the diagnostic output to make it -more suitable for UI testing. For example, it will anonymize line numbers in -the output (line numbers prefixing each source line are replaced with `LL`). -In extremely rare situations, this mode can be disabled with the header -command `// compile-flags: -Z ui-testing=no`. - -Sometimes these built-in normalizations are not enough. In such cases, you -may provide custom normalization rules using the header commands, e.g. - -```rust -// normalize-stdout-test: "foo" -> "bar" -// normalize-stderr-32bit: "fn\(\) \(32 bits\)" -> "fn\(\) \($$PTR bits\)" -// normalize-stderr-64bit: "fn\(\) \(64 bits\)" -> "fn\(\) \($$PTR bits\)" -``` +### Step 5. Check other tests -This tells the test, on 32-bit platforms, whenever the compiler writes -`fn() (32 bits)` to stderr, it should be normalized to read `fn() ($PTR bits)` -instead. Similar for 64-bit. The replacement is performed by regexes using -default regex flavor provided by `regex` crate. +Sometimes when adding or changing a diagnostic message, this will affect +other tests in the test suite. +The final step before posting a PR is to check if you have affected anything else. +Running the UI suite is usually a good start: -The corresponding reference file will use the normalized output to test both -32-bit and 64-bit platforms: - -```text -... - | - = note: source type: fn() ($PTR bits) - = note: target type: u16 (16 bits) -... +```sh +./x.py test src/test/ui ``` -Please see [`ui/transmute/main.rs`][mrs] and [`main.stderr`][] for a -concrete usage example. +If other tests start failing, you may need to investigate what has changed +and if the new output makes sense. +You may also need to re-bless the output with the `--bless` flag. -[mrs]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.rs -[`main.stderr`]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.stderr - -Besides `normalize-stderr-32bit` and `-64bit`, one may use any target -information or stage supported by [`ignore-X`](#ignoring-tests) here as well (e.g. -`normalize-stderr-windows` or simply `normalize-stderr-test` for unconditional -replacement). + -## Input Normalization +## Comment explaining what the test is about -Sometimes, you want to normalize the inputs to a test. For example, you may -want to pass `// compile-flags: --x=y.rs`, where y.rs is some file in the test -directory. In this case you can use input normalization. The following strings -are replaced in header inputs: +The first comment of a test file should **summarize the point +of the test**, and highlight what is important about it. +If there is an issue number associated with the test, include +the issue number. -- {{cwd}}: The directory where compiletest is run from. This may not be the - root of the checkout, so you should avoid using it where possible. - - Examples: `/path/to/rust`, `/path/to/build/root` -- {{src-base}}: The directory where the test is defined. This is equivalent to - `$DIR` for output normalization. - - Example: `/path/to/rust/src/test/ui/error-codes` -- {{build-base}}: The base directory where the test's output goes. This is - equivalent to `$TEST_BUILD_DIR` for output normalization. - - Example: `/path/to/rust/build/x86_64-unknown-linux-gnu/test/ui` +This comment doesn't have to be super extensive. Just something like +"Regression test for #18060: match arms were matching in the wrong +order." might already be enough. -See [`src/test/ui/commandline-argfile.rs`](https://github.com/rust-lang/rust/blob/a5029ac0ab372aec515db2e718da6d7787f3d122/src/test/ui/commandline-argfile.rs) -for an example of a test that uses input normalization. +These comments are very useful to others later on when your test +breaks, since they often can highlight what the problem is. They are +also useful if for some reason the tests need to be refactored, since +they let others know which parts of the test were important (often a +test must be rewritten because it no longer tests what is was meant to +test, and then it's useful to know what it *was* meant to test +exactly). diff --git a/src/tests/ci.md b/src/tests/ci.md new file mode 100644 index 000000000..21f834130 --- /dev/null +++ b/src/tests/ci.md @@ -0,0 +1,73 @@ +# Testing with CI + +## Testing infrastructure + +When a Pull Request is opened on GitHub, [GitHub Actions] will automatically +launch a build that will run all tests on some configurations +(x86_64-gnu-llvm-12 linux. x86_64-gnu-tools linux, mingw-check linux). +In essence, each runs `./x.py test` with various different options. + +The integration bot [bors] is used for coordinating merges to the master branch. +When a PR is approved, it goes into a [queue] where merges are tested one at a +time on a wide set of platforms using GitHub Actions. Due to the limit on the +number of parallel jobs, we run CI under the [rust-lang-ci] organization except +for PRs. +Most platforms only run the build steps, some run a restricted set of tests, +only a subset run the full suite of tests (see Rust's [platform tiers]). + +If everything passes, then all of the distribution artifacts that were +generated during the CI run are published. + +[GitHub Actions]: https://github.com/rust-lang/rust/actions +[rust-lang-ci]: https://github.com/rust-lang-ci/rust/actions +[bors]: https://github.com/servo/homu +[queue]: https://bors.rust-lang.org/queue/rust +[platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support + +## Using CI to test + +In some cases, a PR may run into problems with running tests on a particular +platform or configuration. +If you can't run those tests locally, don't hesitate to use CI resources to +try out a fix. + +As mentioned above, opening or updating a PR will only run on a small subset +of configurations. +Only when a PR is approved will it go through the full set of test configurations. +However, you can try one of those configurations in your PR before it is approved. +For example, if a Windows build fails, but you don't have access to a Windows +machine, you can try running the Windows job that failed on CI within your PR +after pushing a possible fix. + +To do this, you'll need to edit [`src/ci/github-actions/ci.yml`]. +The `jobs` section defines the jobs that will run. +The `jobs.pr` section defines everything that will run in a push to a PR. +The `jobs.auto` section defines the full set of tests that are run after a PR is approved. +You can copy one of the definitions from the `auto` section up to the `pr` section. + +For example, the `x86_64-msvc-1` and `x86_64-msvc-2` jobs are responsible for +running the 64-bit MSVC tests. +You can copy those up to the `jobs.pr.strategy.matrix.include` section with +the other jobs. + +The comment at the top of `ci.yml` will tell you to run this command: + +```sh +./x.py run src/tools/expand-yaml-anchors +```` + +This will generate the true [`.github/workflows/ci.yml`] which is what GitHub +Actions uses. + +Then, you can commit those two files and push to GitHub. +GitHub Actions should launch the tests. + +After you have finished, don't forget to remove any changes you have made to `ci.yml`. + +Although you are welcome to use CI, just be conscientious that this is a shared +resource with limited concurrency. +Try not to enable too many jobs at once (one or two should be sufficient in +most cases). + +[`src/ci/github-actions/ci.yml`]: https://github.com/rust-lang/rust/blob/master/src/ci/github-actions/ci.yml +[`.github/workflows/ci.yml`]: https://github.com/rust-lang/rust/blob/master/.github/workflows/ci.yml#L1 diff --git a/src/tests/compiletest.md b/src/tests/compiletest.md new file mode 100644 index 000000000..b54bdfcfd --- /dev/null +++ b/src/tests/compiletest.md @@ -0,0 +1,526 @@ +# Compiletest + + + +## Introduction + +`compiletest` is the main test harness of the Rust test suite. +It allows test authors to organize large numbers of tests +(the Rust compiler has many thousands), +efficient test execution (parallel execution is supported), +and allows the test author to configure behavior and expected results of both +individual and groups of tests. + +`compiletest` may check test code for success, for runtime failure, +or for compile-time failure. +Tests are typically organized as a Rust source file with annotations in +comments before and/or within the test code. +These comments serve to direct `compiletest` on if or how to run the test, +what behavior to expect, and more. +See [header commands](headers.md) and the test suite documentation below +for more details on these annotations. + +See the [Adding new tests](adding.md) chapter for a tutorial on creating a new +test, and the [Running tests](running.md) chapter on how to run the test +suite. + +## Test suites + +All of the tests are in the [`src/test`] directory. +The tests are organized into "suites", with each suite in a separate subdirectory. +Each test suite behaves a little differently, with different compiler behavior +and different checks for correctness. +For example, the [`src/test/incremental`] directory contains tests for +incremental compilation. +The various suites are defined in [`src/tools/compiletest/src/common.rs`] in +the `pub enum Mode` declaration. + +The following test suites are available, with links for more information: + +- [`ui`](ui.md) — tests that check the stdout/stderr from the compilation + and/or running the resulting executable +- `ui-fulldeps` — `ui` tests which require a linkable build of `rustc` (such + as using `extern crate rustc_span;` or used as a plugin) +- [`pretty`](#pretty-printer-tests) — tests for pretty printing +- [`incremental`](#incremental-tests) — tests incremental compilation behavior +- [`debuginfo`](#debuginfo-tests) — tests for debuginfo generation running debuggers +- [`codegen`](#codegen-tests) — tests for code generation +- [`codegen-units`](#codegen-units-tests) — tests for codegen unit partitioning +- [`assembly`](#assembly-tests) — verifies assembly output +- [`mir-opt`](#mir-opt-tests) — tests for MIR generation +- [`run-make`](#run-make-tests) — general purpose tests using a Makefile +- `run-make-fulldeps` — `run-make` tests which require a linkable build of `rustc`, + or the rust demangler +- [`run-pass-valgrind`](#valgrind-tests) — tests run with Valgrind +- Rustdoc tests: + - `rustdoc` — tests for rustdoc, making sure that the generated files + contain the expected documentation. + - `rustdoc-gui` — TODO + - `rustdoc-js` — TODO + - `rustdoc-js-std` — TODO + - `rustdoc-json` — TODO + - `rustdoc-ui` — TODO + +[`src/test`]: https://github.com/rust-lang/rust/blob/master/src/test +[`src/tools/compiletest/src/common.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs + +### Pretty-printer tests + +The tests in [`src/test/pretty`] exercise the "pretty-printing" functionality of `rustc`. +The `-Z unpretty` CLI option for `rustc` causes it to translate the input source +into various different formats, such as the Rust source after macro expansion. + +The pretty-printer tests have several [header commands](headers.md) described below. +These commands can significantly change the behavior of the test, but the +default behavior without any commands is to: + +1. Run `rustc -Zunpretty=normal` on the source file +2. Run `rustc -Zunpretty=normal` on the output of the previous step +3. The output of the previous two steps should be the same. +4. Run `rustc -Zno-codegen` on the output to make sure that it can type check + (this is similar to running `cargo check`) + +If any of the commands above fail, then the test fails. + +The header commands for pretty-printing tests are: + +* `pretty-mode` specifies the mode pretty-print tests should run in + (that is, the argument to `-Zunpretty`). + The default is `normal` if not specified. +* `pretty-compare-only` causes a pretty test to only compare the pretty-printed output + (stopping after step 3 from above). + It will not try to compile the expanded output to type check it. + This is needed for a pretty-mode that does not expand to valid + Rust, or for other situations where the expanded output cannot be compiled. +* `pretty-expanded` allows a pretty test to also check that the expanded + output can be type checked. + That is, after the steps above, it does two more steps: + + > 5. Run `rustc -Zunpretty=expanded` on the original source + > 6. Run `rustc -Zno-codegen` on the expanded output to make sure that it can type check + + This is needed because not all code can be compiled after being expanded. + Pretty tests should specify this if they can. + An example where this cannot be used is if the test includes `println!`. + That macro expands to reference private internal functions of the standard + library that cannot be called directly without the `fmt_internals` feature + gate. + + More history about this may be found in + [#23616](https://github.com/rust-lang/rust/issues/23616#issuecomment-484999901). +* `pp-exact` is used to ensure a pretty-print test results in specific output. + If specified without a value, then it means the pretty-print output should + match the original source. + If specified with a value, as in `// pp-exact:foo.pp`, + it will ensure that the pretty-printed output matches the contents of the given file. + Otherwise, if `pp-exact` is not specified, then the pretty-printed output + will be pretty-printed one more time, and the output of the two + pretty-printing rounds will be compared to ensure that the pretty-printed + output converges to a steady state. + +[`src/test/pretty`]: https://github.com/rust-lang/rust/tree/master/src/test/pretty + +### Incremental tests + +The tests in [`src/test/incremental`] exercise incremental compilation. +They use [revision headers](#revisions) to tell compiletest to run the +compiler in a series of steps. +Compiletest starts with an empty directory with the `-C incremental` flag, and +then runs the compiler for each revision, reusing the incremental results from +previous steps. +The revisions should start with: + +* `rpass` — the test should compile and run successfully +* `rfail` — the test should compile successfully, but the executable should fail to run +* `cfail` — the test should fail to compile + +To make the revisions unique, you should add a suffix like `rpass1` and `rpass2`. + +To simulate changing the source, compiletest also passes a `--cfg` flag with +the current revision name. +For example, this will run twice, simulating changing a function: + +```rust,ignore +// revisions: rpass1 rpass2 + +#[cfg(rpass1)] +fn foo() { + println!("one"); +} + +#[cfg(rpass2)] +fn foo() { + println!("two"); +} + +fn main() { foo(); } +``` + +`cfail` tests support the `forbid-output` header to specify that a certain +substring must not appear anywhere in the compiler output. +This can be useful to ensure certain errors do not appear, but this can be +fragile as error messages change over time, and a test may no longer be +checking the right thing but will still pass. + +`cfail` tests support the `should-ice` header to specify that a test should +cause an Internal Compiler Error (ICE). +This is a highly specialized header to check that the incremental cache +continues to work after an ICE. + +[`src/test/incremental`]: https://github.com/rust-lang/rust/tree/master/src/test/incremental + + +### Debuginfo tests + +The tests in [`src/test/debuginfo`] test debuginfo generation. +They build a program, launch a debugger, and issue commands to the debugger. +A single test can work with cdb, gdb, and lldb. + +Most tests should have the `// compile-flags: -g` header or something similar +to generate the appropriate debuginfo. + +To set a breakpoint on a line, add a `// #break` comment on the line. + +The debuginfo tests consist of a series of debugger commands along with +"check" lines which specify output that is expected from the debugger. + +The commands are comments of the form `// $DEBUGGER-command:$COMMAND` where +`$DEBUGGER` is the debugger being used and `$COMMAND` is the debugger command +to execute. +The debugger values can be: + +* `cdb` +* `gdb` +* `gdbg` — GDB without Rust support (versions older than 7.11) +* `gdbr` — GDB with Rust support +* `lldb` +* `lldbg` — LLDB without Rust support +* `lldbr` — LLDB with Rust support (this no longer exists) + +The command to check the output are of the form `// $DEBUGGER-check:$OUTPUT` +where `$OUTPUT` is the output to expect. + +For example, the following will build the test, start the debugger, set a +breakpoint, launch the program, inspect a value, and check what the debugger +prints: + +```rust,ignore +// compile-flags: -g + +// lldb-command: run +// lldb-command: print foo +// lldb-check: $0 = 123 + +fn main() { + let foo = 123; + b(); // #break +} + +fn b() {} +``` + +The following [header commands](headers.md) are available to disable a +test based on the debugger currently being used: + +* `min-cdb-version: 10.0.18317.1001` — ignores the test if the version of cdb + is below the given version +* `min-gdb-version: 8.2` — ignores the test if the version of gdb is below the + given version +* `ignore-gdb-version: 9.2` — ignores the test if the version of gdb is equal + to the given version +* `ignore-gdb-version: 7.11.90 - 8.0.9` — ignores the test if the version of + gdb is in a range (inclusive) +* `min-lldb-version: 310` — ignores the test if the version of lldb is below + the given version +* `rust-lldb` — ignores the test if lldb is not contain the Rust plugin. + NOTE: The "Rust" version of LLDB doesn't exist anymore, so this will always be ignored. + This should probably be removed. + +[`src/test/debuginfo`]: https://github.com/rust-lang/rust/tree/master/src/test/debuginfo + + +### Codegen tests + +The tests in [`src/test/codegen`] test LLVM code generation. +They compile the test with the `--emit=llvm-ir` flag to emit LLVM IR. +They then run the LLVM [FileCheck] tool. +The test is annotated with various `// CHECK` comments to check the generated code. +See the FileCheck documentation for a tutorial and more information. + +See also the [assembly tests](#assembly-tests) for a similar set of tests. + +[`src/test/codegen`]: https://github.com/rust-lang/rust/tree/master/src/test/codegen +[FileCheck]: https://llvm.org/docs/CommandGuide/FileCheck.html + + +### Assembly tests + +The tests in [`src/test/assembly`] test LLVM assembly output. +They compile the test with the `--emit=asm` flag to emit a `.s` file with the +assembly output. +They then run the LLVM [FileCheck] tool. + +Each test should be annotated with the `// assembly-output:` header +with a value of either `emit-asm` or `ptx-linker` to indicate +the type of assembly output. + +Then, they should be annotated with various `// CHECK` comments to check the +assembly output. +See the FileCheck documentation for a tutorial and more information. + +See also the [codegen tests](#codegen-tests) for a similar set of tests. + +[`src/test/assembly`]: https://github.com/rust-lang/rust/tree/master/src/test/assembly + + +### Codegen-units tests + +The tests in [`src/test/codegen-units`] test the +[monomorphization](../backend/monomorph.md) collector and CGU partitioning. + +These tests work by running `rustc` with a flag to print the result of the +monomorphization collection pass, and then special annotations in the file are +used to compare against that. + +Each test should be annotated with the `// compile-flags:-Zprint-mono-items=VAL` +header with the appropriate VAL to instruct `rustc` to print the +monomorphization information. + +Then, the test should be annotated with comments of the form `//~ MONO_ITEM name` +where `name` is the monomorphized string printed by rustc like `fn ::foo`. + +To check for CGU partitioning, a comment of the form `//~ MONO_ITEM name @@ cgu` +where `cgu` is a space separated list of the CGU names and the linkage +information in brackets. +For example: `//~ MONO_ITEM static function::FOO @@ statics[Internal]` + +[`src/test/codegen-units`]: https://github.com/rust-lang/rust/tree/master/src/test/codegen-units + + +### Mir-opt tests + +The tests in [`src/test/mir-opt`] check parts of the generated MIR to make +sure it is generated correctly and is doing the expected optimizations. +Check out the [MIR Optimizations](../mir/optimizations.md) chapter for more. + +Compiletest will build the test with several flags to dump the MIR output and +set a baseline for optimizations: + +* `-Copt-level=1` +* `-Zdump-mir=all` +* `-Zmir-opt-level=4` +* `-Zvalidate-mir` +* `-Zdump-mir-exclude-pass-number` + +The test should be annotated with `// EMIT_MIR` comments that specify files that +will contain the expected MIR output. +You can use `x.py test --bless` to create the initial expected files. + +There are several forms the `EMIT_MIR` comment can take: + +* `// EMIT_MIR $MIR_PATH.mir` — This will check that the given filename + matches the exact output from the MIR dump. + For example, `my_test.main.SimplifyCfg-elaborate-drops.after.mir` will load + that file from the test directory, and compare it against the dump from + rustc. + + Checking the "after" file (which is after optimization) is useful if you are + interested in the final state after an optimization. + Some rare cases may want to use the "before" file for completeness. + +* `// EMIT_MIR $MIR_PATH.diff` — where `$MIR_PATH` is the filename of the MIR + dump, such as `my_test_name.my_function.EarlyOtherwiseBranch`. + Compiletest will diff the `.before.mir` and `.after.mir` files, and compare + the diff output to the expected `.diff` file from the `EMIT_MIR` comment. + + This is useful if you want to see how an optimization changes the MIR. + +* `// EMIT_MIR $MIR_PATH.dot` or `$MIR_PATH.html` — These are special cases + for other MIR outputs (via `-Z dump-mir-graphviz` and `-Z dump-mir-spanview`) + that will check that the output matches the given file. + +By default 32 bit and 64 bit targets use the same dump files, which can be +problematic in the presence of pointers in constants or other bit width +dependent things. In that case you can add `// EMIT_MIR_FOR_EACH_BIT_WIDTH` to +your test, causing separate files to be generated for 32bit and 64bit systems. + +[`src/test/mir-opt`]: https://github.com/rust-lang/rust/tree/master/src/test/mir-opt + + +### Run-make tests + +The tests in [`src/test/run-make`] are general-purpose tests using Makefiles +which provide the ultimate in flexibility. +These should be used as a last resort. +If possible, you should use one of the other test suites. +If there is some minor feature missing which you need for your test, +consider extending compiletest to add a header command for what you need. +However, sometimes just running a bunch of commands is really what you +need, `run-make` is here to the rescue! + +Each test should be in a separate directory with a `Makefile` indicating the +commands to run. +There is a [`tools.mk`] Makefile which you can include which provides a bunch of +utilities to make it easier to run commands and compare outputs. +Take a look at some of the other tests for some examples on how to get started. + +[`tools.mk`]: https://github.com/rust-lang/rust/blob/master/src/test/run-make-fulldeps/tools.mk +[`src/test/run-make`]: https://github.com/rust-lang/rust/tree/master/src/test/run-make + + +### Valgrind tests + +The tests in [`src/test/run-pass-valgrind`] are for use with [Valgrind]. +These are currently vestigial, as Valgrind is no longer used in CI. +These may be removed in the future. + +[Valgrind]: https://valgrind.org/ +[`src/test/run-pass-valgrind`]: https://github.com/rust-lang/rust/tree/master/src/test/run-pass-valgrind + + +## Building auxiliary crates + +It is common that some tests require additional auxiliary crates to be compiled. +There are two [headers](headers.md) to assist with that: + +* `aux-build` +* `aux-crate` + +`aux-build` will build a separate crate from the named source file. +The source file should be in a directory called `auxiliary` beside the test file. + +```rust,ignore +// aux-build: my-helper.rs + +extern crate my_helper; +// ... You can use my_helper. +``` + +The aux crate will be built as a dylib if possible (unless on a platform that +does not support them, or the `no-prefer-dynamic` header is specified in the +aux file). +The `-L` flag is used to find the extern crates. + +`aux-crate` is very similar to `aux-build`; however, it uses the `--extern` +flag to link to the extern crate. +That allows you to specify the additional syntax of the `--extern` flag, such +as renaming a dependency. +For example, `// aux-crate:foo=bar.rs` will compile `auxiliary/bar.rs` and +make it available under then name `foo` within the test. +This is similar to how Cargo does dependency renaming. + +### Auxiliary proc-macro + +If you want a proc-macro dependency, then there currently is some ceremony +needed. +Place the proc-macro itself in a file like `auxiliary/my-proc-macro.rs` +with the following structure: + +```rust,ignore +// force-host +// no-prefer-dynamic + +#![crate_type = "proc-macro"] + +extern crate proc_macro; +use proc_macro::TokenStream; + +#[proc_macro] +pub fn foo(input: TokenStream) -> TokenStream { + "".parse().unwrap() +} +``` + +The `force-host` is needed because proc-macros are loaded in the host +compiler, and `no-prefer-dynamic` is needed to tell compiletest to not use +`prefer-dynamic` which is not compatible with proc-macros. +The `#![crate_type]` attribute is needed to specify the correct crate-type. + +Then in your test, you can build with with `aux-build`: + +```rust,ignore +// aux-build: my-proc-macro.rs + +extern crate my_proc_macro; + +fn main() { + my_proc_macro::foo!(); +} +``` + + +## Revisions + +Certain classes of tests support "revisions" (as of February 2021, +this includes compile-fail, run-fail, and incremental, though +incremental tests are somewhat different). +Revisions allow a single test file to be used for multiple tests. +This is done by adding a special header at the top of the file: + +```rust,ignore +// revisions: foo bar baz +``` + +This will result in the test being compiled (and tested) three times, +once with `--cfg foo`, once with `--cfg bar`, and once with `--cfg +baz`. +You can therefore use `#[cfg(foo)]` etc within the test to tweak +each of these results. + +You can also customize headers and expected error messages to a particular +revision. To do this, add `[foo]` (or `bar`, `baz`, etc) after the `//` +comment, like so: + +```rust,ignore +// A flag to pass in only for cfg `foo`: +//[foo]compile-flags: -Z verbose + +#[cfg(foo)] +fn test_foo() { + let x: usize = 32_u32; //[foo]~ ERROR mismatched types +} +``` + +Note that not all headers have meaning when customized to a revision. +For example, the `ignore-test` header (and all "ignore" headers) +currently only apply to the test as a whole, not to particular +revisions. The only headers that are intended to really work when +customized to a revision are error patterns and compiler flags. + + +## Compare modes + +Compiletest can be run in different modes, called *compare modes*, which can +be used to compare the behavior of all tests with different compiler flags +enabled. +This can help highlight what differences might appear with certain flags, and +check for any problems that might arise. + +To run the tests in a different mode, you need to pass the `--compare-mode` +CLI flag: + +```bash +./x.py test src/test/ui --compare-mode=nll +``` + +The possible compare modes are: + +* `nll` — Runs in the "true" NLL mode with `-Zborrowck=mir`. + See [UI compare modes](ui.md#compare-modes) for more. +* `polonius` — Runs with Polonius with `-Zpolonius -Zborrowck=mir`, and reuses + the `nll` stderr files. +* `chalk` — Runs with Chalk with `-Zchalk`. +* `split-dwarf` — Runs with unpacked split-DWARF with `-Csplit-debuginfo=unpacked`. +* `split-dwarf-single` — Runs with packed split-DWARF with `-Csplit-debuginfo=packed`. + +In CI, compare modes are only used in one Linux builder, and only with the +following settings: + +* `src/test/ui`: Uses `nll` mode. +* `src/test/debuginfo`: Uses `split-dwarf` mode. + This helps ensure that none of the debuginfo tests are affected when + enabling split-DWARF. + +Note that compare modes are separate to [revisions](#revisions). +All revisions are tested when running `./x.py test src/test/ui`, however +compare-modes must be manually run individually via the `--compare-mode` flag. diff --git a/src/tests/crater.md b/src/tests/crater.md new file mode 100644 index 000000000..9a7ff3871 --- /dev/null +++ b/src/tests/crater.md @@ -0,0 +1,45 @@ +# Crater + +[Crater](https://github.com/rust-lang/crater) is a tool for compiling +and running tests for _every_ crate on [crates.io](https://crates.io) (and a +few on GitHub). It is mainly used for checking the extent of breakage when +implementing potentially breaking changes and ensuring lack of breakage by +running beta vs stable compiler versions. + +## When to run Crater + +You should request a crater run if your PR makes large changes to the compiler +or could cause breakage. If you are unsure, feel free to ask your PR's reviewer. + +## Requesting Crater Runs + +The rust team maintains a few machines that can be used for running crater runs +on the changes introduced by a PR. If your PR needs a crater run, leave a +comment for the triage team in the PR thread. Please inform the team whether +you require a "check-only" crater run, a "build only" crater run, or a +"build-and-test" crater run. The difference is primarily in time; the +conservative (if you're not sure) option is to go for the build-and-test run. +If making changes that will only have an effect at compile-time (e.g., +implementing a new trait) then you only need a check run. + +Your PR will be enqueued by the triage team and the results will be posted when +they are ready. Check runs will take around ~3-4 days, with the other two +taking 5-6 days on average. + +While crater is really useful, it is also important to be aware of a few +caveats: + +- Not all code is on crates.io! There is a lot of code in repos on GitHub and + elsewhere. Also, companies may not wish to publish their code. Thus, a + successful crater run is not a magically green light that there will be no + breakage; you still need to be careful. + +- Crater only runs Linux builds on x86_64. Thus, other architectures and + platforms are not tested. Critically, this includes Windows. + +- Many crates are not tested. This could be for a lot of reasons, including + that the crate doesn't compile any more (e.g. used old nightly features), + has broken or flaky tests, requires network access, or other reasons. + +- Before crater can be run, `@bors try` needs to succeed in building artifacts. + This means that if your code doesn't compile, you cannot run crater. diff --git a/src/tests/docker.md b/src/tests/docker.md new file mode 100644 index 000000000..29837dfea --- /dev/null +++ b/src/tests/docker.md @@ -0,0 +1,52 @@ +# Testing with Docker + +The Rust tree includes [Docker] image definitions for the platforms used on +GitHub Actions in [`src/ci/docker`]. +The script [`src/ci/docker/run.sh`] is used to build the Docker image, run it, +build Rust within the image, and run the tests. + +You can run these images on your local development machine. This can be +helpful to test environments different from your local system. First you will +need to install Docker on a Linux, Windows, or macOS system (typically Linux +will be much faster than Windows or macOS because the later use virtual +machines to emulate a Linux environment). To enter interactive mode which will +start a bash shell in the container, run `src/ci/docker/run.sh --dev ` +where `` is one of the directory names in `src/ci/docker` (for example +`x86_64-gnu` is a fairly standard Ubuntu environment). + +The docker script will mount your local Rust source tree in read-only mode, +and an `obj` directory in read-write mode. All of the compiler artifacts will +be stored in the `obj` directory. The shell will start out in the `obj` +directory. From there, you can run `../src/ci/run.sh` which will run the build +as defined by the image. + +Alternatively, you can run individual commands to do specific tasks. For +example, you can run `python3 ../x.py test src/test/ui` to just run UI tests. +Note that there is some configuration in the [`src/ci/run.sh`] script that you +may need to recreate. Particularly, set `submodules = false` in your +`config.toml` so that it doesn't attempt to modify the read-only directory. + +Some additional notes about using the Docker images: + +- Some of the std tests require IPv6 support. Docker on Linux seems to have it + disabled by default. Run the commands in [`enable-docker-ipv6.sh`] to enable + IPv6 before creating the container. This only needs to be done once. +- The container will be deleted automatically when you exit the shell, however + the build artifacts persist in the `obj` directory. If you are switching + between different Docker images, the artifacts from previous environments + stored in the `obj` directory may confuse the build system. Sometimes you + will need to delete parts or all of the `obj` directory before building + inside the container. +- The container is bare-bones, with only a minimal set of packages. You may + want to install some things like `apt install less vim`. +- You can open multiple shells in the container. First you need the container + name (a short hash), which is displayed in the shell prompt, or you can run + `docker container ls` outside of the container to list the available + containers. With the container name, run `docker exec -it + /bin/bash` where `` is the container name like `4ba195e95cef`. + +[Docker]: https://www.docker.com/ +[`src/ci/docker`]: https://github.com/rust-lang/rust/tree/master/src/ci/docker +[`src/ci/docker/run.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/docker/run.sh +[`src/ci/run.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/run.sh +[`enable-docker-ipv6.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/scripts/enable-docker-ipv6.sh diff --git a/src/tests/headers.md b/src/tests/headers.md new file mode 100644 index 000000000..adc5fa6c9 --- /dev/null +++ b/src/tests/headers.md @@ -0,0 +1,403 @@ +# Test headers + + + +Header commands are special comments that tell compiletest how to build and +interpret a test. +They must appear before the Rust source in the test. +They may also appear in Makefiles for [run-make tests](compiletest.md#run-make-tests). + +They are normally put after the short comment that explains the point of this test. +For example, this test uses the `// compile-flags` command to specify a custom +flag to give to rustc when the test is compiled: + +```rust,ignore +// Test the behavior of `0 - 1` when overflow checks are disabled. + +// compile-flags: -C overflow-checks=off + +fn main() { + let x = 0 - 1; + ... +} +``` + +Header commands can be standalone (like `// run-pass`) or take a value (like +`// compile-flags: -C overflow-checks=off`). + +## Header commands + +The following is a list of header commands. +Commands are linked to sections the describe the command in more detail if available. +This list may not be exhaustive. +Header commands can generally be found by browsing the `TestProps` structure +found in [`header.rs`] from the compiletest source. + +[`header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs + +* [Controlling pass/fail expectations](ui.md#controlling-passfail-expectations) + * `check-pass` — building (no codegen) should pass + * `build-pass` — building should pass + * `run-pass` — running the test should pass + * `check-fail` — building (no codegen) should fail (the default if no header) + * `build-fail` — building should fail + * `run-fail` — running should fail + * `ignore-pass` — ignores the `--pass` flag + * `check-run-results` — checks run-pass/fail-pass output +* [UI](ui.md) headers + * [`normalize-X`](ui.md#normalization) — normalize compiler output + * [`run-rustfix`](ui.md#rustfix-tests) — checks diagnostic suggestions + * [`rustfix-only-machine-applicable`](ui.md#rustfix-tests) — checks only + machine applicable suggestions + * [`stderr-per-bitwidth`](ui.md#output-comparison) — separate output per bit width + * [`dont-check-compiler-stderr`](ui.md#output-comparison) — don't validate stderr + * [`dont-check-compiler-stdout`](ui.md#output-comparison) — don't validate stdout +* [Building auxiliary crates](compiletest.md#building-auxiliary-crates) + * `aux-build` + * `aux-crate` +* [Pretty-printer](compiletest.md#pretty-printer-tests) headers + * `pretty-compare-only` + * `pretty-expanded` + * `pretty-mode` + * `pp-exact` +* [Ignoring tests](#ignoring-tests) + * `ignore-X` + * `only-X` + * `needs-X` + * `no-system-llvm` + * `min-llvm-versionX` + * `min-system-llvm-version` + * `ignore-llvm-version` + * `ignore-llvm-version` +* [Environment variable headers](#environment-variable-headers) + * `rustc-env` + * `exec-env` + * `unset-rustc-env` +* [Miscellaneous headers](#miscellaneous-headers) + * `compile-flags` — adds compiler flags + * `run-flags` — adds flags to executable tests + * `edition` — sets the edition + * `failure-status` — expected exit code + * `should-fail` — testing compiletest itself + * `gate-test-X` — feature gate testing + * [`error-pattern`](ui.md#error-pattern) — errors not on a line + * `incremental` — incremental tests not in the incremental test-suite + * `no-prefer-dynamic` — don't use `-C prefer-dynamic`, don't build as a dylib + * `force-host` — build only for the host target + * [`revisions`](compiletest.md#revisions) — compile multiple times + * [`forbid-output`](compiletest.md#incremental-tests) — incremental cfail rejects output pattern + * [`should-ice`](compiletest.md#incremental-tests) — incremental cfail should ICE +* [Assembly](compiletest.md#assembly-tests) headers + * `assembly-output` — the type of assembly output to check + + +### Ignoring tests + +These header commands are used to ignore the test in some situations, +which means the test won't be compiled or run. + +* `ignore-X` where `X` is a target detail or stage will ignore the + test accordingly (see below) +* `only-X` is like `ignore-X`, but will *only* run the test on that + target or stage +* `ignore-test` always ignores the test. + This can be used to temporarily disable a test if it is currently not working, + but you want to keep it in tree to re-enable it later. + +Some examples of `X` in `ignore-X` or `only-X`: + +* A full target triple: `aarch64-apple-ios` +* Architecture: `aarch64`, `arm`, `asmjs`, `mips`, `wasm32`, `x86_64`, + `x86`, ... +* OS: `android`, `emscripten`, `freebsd`, `ios`, `linux`, `macos`, + `windows`, ... +* Environment (fourth word of the target triple): `gnu`, `msvc`, + `musl` +* WASM: `wasm32-bare` matches `wasm32-unknown-unknown`. + `emscripten` also matches that target as well as the emscripten targets. +* Pointer width: `32bit`, `64bit` +* Endianness: `endian-big` +* Stage: `stage0`, `stage1`, `stage2` +* Channel: `stable`, `beta` +* When cross compiling: `cross-compile` +* When [remote testing] is used: `remote` +* When debug-assertions are enabled: `debug` +* When particular debuggers are being tested: `cdb`, `gdb`, `lldb` +* Specific [compare modes]: `compare-mode-nll`, `compare-mode-polonius`, + `compare-mode-chalk`, `compare-mode-split-dwarf`, + `compare-mode-split-dwarf-single` + +The following header commands will check rustc build settings and target settings: + +* `needs-asm-support` — ignores if it is running on a target that doesn't have + stable support for `asm!` +* `needs-profiler-support` — ignores if profiler support was not enabled for + the target (`profiler = true` in rustc's `config.toml`) +* `needs-sanitizer-support` — ignores if the sanitizer support was not enabled + for the target (`sanitizers = true` in rustc's `config.toml`) +* `needs-sanitizer-{address,hwaddress,leak,memory,thread}` — ignores + if the corresponding sanitizer is not enabled for the target + (AddressSanitizer, hardware-assisted AddressSanitizer, LeakSanitizer, + MemorySanitizer or ThreadSanitizer respectively) +* `needs-run-enabled` — ignores if it is a test that gets executed, and + running has been disabled. Running tests can be disabled with the `x.py test + --run=never` flag, or running on fuchsia. +* `needs-unwind` — ignores if the target does not support unwinding +* `needs-rust-lld` — ignores if the rust lld support is not enabled + (`rust.lld = true` in `config.toml`) + +The following header commands will check LLVM support: + +* `no-system-llvm` — ignores if the system llvm is used +* `min-llvm-version: 13.0` — ignored if the LLVM version is less than the given value +* `min-system-llvm-version: 12.0` — ignored if using a system LLVM and its + version is less than the given value +* `ignore-llvm-version: 9.0` — ignores a specific LLVM version +* `ignore-llvm-version: 7.0 - 9.9.9` — ignores LLVM versions in a range (inclusive) +* `needs-llvm-components: powerpc` — ignores if the specific LLVM component was not built. + Note: The test will fail on CI if the component does not exist. +* `needs-matching-clang` — ignores if the version of clang does not match the + LLVM version of rustc. + These tests are always ignored unless a special environment variable is set + (which is only done in one CI job). + +See also [Debuginfo tests](compiletest.md#debuginfo-tests) for headers for +ignoring debuggers. + +[remote testing]: running.md#running-tests-on-a-remote-machine +[compare modes]: ui.md#compare-modes + +### Environment variable headers + +The following headers affect environment variables. + +* `rustc-env` is an environment variable to set when running `rustc` of the + form `KEY=VALUE`. +* `exec-env` is an environment variable to set when executing a test of the + form `KEY=VALUE`. +* `unset-rustc-env` specifies an environment variable to unset when running + `rustc`. + +### Miscellaneous headers + +The following headers are generally available, and not specific to particular +test suites. + +* `compile-flags` passes extra command-line args to the compiler, + e.g. `compile-flags -g` which forces debuginfo to be enabled. +* `run-flags` passes extra args to the test if the test is to be executed. +* `edition` controls the edition the test should be compiled with + (defaults to 2015). Example usage: `// edition:2018`. +* `failure-status` specifies the numeric exit code that should be expected for + tests that expect an error. + If this is not set, the default is 1. +* `should-fail` indicates that the test should fail; used for "meta + testing", where we test the compiletest program itself to check that + it will generate errors in appropriate scenarios. This header is + ignored for pretty-printer tests. +* `gate-test-X` where `X` is a feature marks the test as "gate test" + for feature X. + Such tests are supposed to ensure that the compiler errors when usage of a + gated feature is attempted without the proper `#![feature(X)]` tag. + Each unstable lang feature is required to have a gate test. + This header is actually checked by [tidy](intro.md#tidy), it is not checked + by compiletest. +* `error-pattern` checks the diagnostics just like the `ERROR` annotation + without specifying error line. This is useful when the error doesn't give + any span. See [`error-pattern`](ui.md#error-pattern). +* `incremental` runs the test with the `-C incremental` flag and an empty + incremental directory. This should be avoided when possible; you should use + an *incremental mode* test instead. Incremental mode tests support running + the compiler multiple times and verifying that it can load the generated + incremental cache. This flag is for specialized circumstances, like checking + the interaction of codegen unit partitioning with generating an incremental + cache. +* `no-prefer-dynamic` will force an auxiliary crate to be built as an rlib + instead of a dylib. When specified in a test, it will remove the use of `-C + prefer-dynamic`. This can be useful in a variety of circumstances. For + example, it can prevent a proc-macro from being built with the wrong crate + type. Or if your test is specifically targeting behavior of other crate + types, it can be used to prevent building with the wrong crate type. +* `force-host` will force the test to build for the host platform instead of + the target. This is useful primarily for auxiliary proc-macros, which need + to be loaded by the host compiler. + + +## Substitutions + +Headers values support substituting a few variables which will be replaced +with their corresponding value. +For example, if you need to pass a compiler flag with a path to a specific +file, something like the following could work: + +```rust,ignore +// compile-flags: --remap-path-prefix={{src-base}}=/the/src +``` + +Where the sentinel `{{src-base}}` will be replaced with the appropriate path +described below: + +- `{{cwd}}`: The directory where compiletest is run from. This may not be the + root of the checkout, so you should avoid using it where possible. + - Examples: `/path/to/rust`, `/path/to/build/root` +- `{{src-base}}`: The directory where the test is defined. This is equivalent to + `$DIR` for [output normalization]. + - Example: `/path/to/rust/src/test/ui/error-codes` +- `{{build-base}}`: The base directory where the test's output goes. This is + equivalent to `$TEST_BUILD_DIR` for [output normalization]. + - Example: `/path/to/rust/build/x86_64-unknown-linux-gnu/test/ui` + +See [`src/test/ui/commandline-argfile.rs`](https://github.com/rust-lang/rust/blob/a5029ac0ab372aec515db2e718da6d7787f3d122/src/test/ui/commandline-argfile.rs) +for an example of a test that uses this substitution. + +[output normalization]: ui.md#normalization + + +## Adding a new header command + +One would add a new header command if there is a need to define some test +property or behavior on an individual, test-by-test basis. +A header command property serves as the header command's backing store (holds +the command's current value) at runtime. + +To add a new header command property: + + 1. Look for the `pub struct TestProps` declaration in + [`src/tools/compiletest/src/header.rs`] and add the new public property to + the end of the declaration. + 2. Look for the `impl TestProps` implementation block immediately following + the struct declaration and initialize the new property to its default + value. + +### Adding a new header command parser + +When `compiletest` encounters a test file, it parses the file a line at a time +by calling every parser defined in the `Config` struct's implementation block, +also in [`src/tools/compiletest/src/header.rs`] (note that the `Config` +struct's declaration block is found in [`src/tools/compiletest/src/common.rs`]). +`TestProps`'s `load_from()` method will try passing the current line of text to +each parser, which, in turn typically checks to see if the line begins with a +particular commented (`//`) header command such as `// must-compile-successfully` +or `// failure-status`. Whitespace after the comment marker is optional. + +Parsers will override a given header command property's default value merely by +being specified in the test file as a header command or by having a parameter +value specified in the test file, depending on the header command. + +Parsers defined in `impl Config` are typically named `parse_` +(note kebab-case `` transformed to snake-case +``). `impl Config` also defines several 'low-level' parsers +which make it simple to parse common patterns like simple presence or not +(`parse_name_directive()`), header-command:parameter(s) +(`parse_name_value_directive()`), optional parsing only if a particular `cfg` +attribute is defined (`has_cfg_prefix()`) and many more. The low-level parsers +are found near the end of the `impl Config` block; be sure to look through them +and their associated parsers immediately above to see how they are used to +avoid writing additional parsing code unnecessarily. + +As a concrete example, here is the implementation for the +`parse_failure_status()` parser, in [`src/tools/compiletest/src/header.rs`]: + +```diff +@@ -232,6 +232,7 @@ pub struct TestProps { + // customized normalization rules + pub normalize_stdout: Vec<(String, String)>, + pub normalize_stderr: Vec<(String, String)>, ++ pub failure_status: i32, + } + + impl TestProps { +@@ -260,6 +261,7 @@ impl TestProps { + run_pass: false, + normalize_stdout: vec![], + normalize_stderr: vec![], ++ failure_status: 101, + } + } + +@@ -383,6 +385,10 @@ impl TestProps { + if let Some(rule) = config.parse_custom_normalization(ln, "normalize-stderr") { + self.normalize_stderr.push(rule); + } ++ ++ if let Some(code) = config.parse_failure_status(ln) { ++ self.failure_status = code; ++ } + }); + + for key in &["RUST_TEST_NOCAPTURE", "RUST_TEST_THREADS"] { +@@ -488,6 +494,13 @@ impl Config { + self.parse_name_directive(line, "pretty-compare-only") + } + ++ fn parse_failure_status(&self, line: &str) -> Option { ++ match self.parse_name_value_directive(line, "failure-status") { ++ Some(code) => code.trim().parse::().ok(), ++ _ => None, ++ } ++ } +``` + +### Implementing the behavior change + +When a test invokes a particular header command, it is expected that some +behavior will change as a result. What behavior, obviously, will depend on the +purpose of the header command. In the case of `failure-status`, the behavior +that changes is that `compiletest` expects the failure code defined by the +header command invoked in the test, rather than the default value. + +Although specific to `failure-status` (as every header command will have a +different implementation in order to invoke behavior change) perhaps it is +helpful to see the behavior change implementation of one case, simply as an +example. To implement `failure-status`, the `check_correct_failure_status()` +function found in the `TestCx` implementation block, located in +[`src/tools/compiletest/src/runtest.rs`], was modified as per below: + +```diff +@@ -295,11 +295,14 @@ impl<'test> TestCx<'test> { + } + + fn check_correct_failure_status(&self, proc_res: &ProcRes) { +- // The value the Rust runtime returns on failure +- const RUST_ERR: i32 = 101; +- if proc_res.status.code() != Some(RUST_ERR) { ++ let expected_status = Some(self.props.failure_status); ++ let received_status = proc_res.status.code(); ++ ++ if expected_status != received_status { + self.fatal_proc_rec( +- &format!("failure produced the wrong error: {}", proc_res.status), ++ &format!("Error: expected failure status ({:?}) but received status {:?}.", ++ expected_status, ++ received_status), + proc_res, + ); + } +@@ -320,7 +323,6 @@ impl<'test> TestCx<'test> { + ); + + let proc_res = self.exec_compiled_test(); +- + if !proc_res.status.success() { + self.fatal_proc_rec("test run failed!", &proc_res); + } +@@ -499,7 +501,6 @@ impl<'test> TestCx<'test> { + expected, + actual + ); +- panic!(); + } + } +``` + +Note the use of `self.props.failure_status` to access the header command +property. In tests which do not specify the failure status header command, +`self.props.failure_status` will evaluate to the default value of 101 at the +time of this writing. But for a test which specifies a header command of, for +example, `// failure-status: 1`, `self.props.failure_status` will evaluate to +1, as `parse_failure_status()` will have overridden the `TestProps` default +value, for that test specifically. + +[`src/tools/compiletest/src/header.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/header.rs +[`src/tools/compiletest/src/common.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs +[`src/tools/compiletest/src/runtest.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/runtest.rs diff --git a/src/tests/intro.md b/src/tests/intro.md index efce3a658..65facccba 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -1,350 +1,154 @@ -# The compiler testing framework +# Testing the compiler The Rust project runs a wide variety of different tests, orchestrated by -the build system (`./x.py test`). The main test harness for testing the -compiler itself is a tool called compiletest (located in the -[`src/tools/compiletest`] directory). This section gives a brief -overview of how the testing framework is setup, and then gets into some -of the details on [how to run tests](./running.html) as well as [how to -add new tests](./adding.html). +the build system (`./x.py test`). +This section gives a brief overview of the different testing tools. +Subsequent chapters dive into [running tests](running.md) and [adding new tests](adding.md). -[`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest +## Kinds of tests -## Compiletest test suites +There are several kinds of tests to exercise things in the Rust distribution. +Almost all of them are driven by `./x.py test`, with some exceptions noted below. -The compiletest tests are located in the tree in the [`src/test`] -directory. Immediately within you will see a series of subdirectories -(e.g. `ui`, `run-make`, and so forth). Each of those directories is -called a **test suite** – they house a group of tests that are run in -a distinct mode. +### Compiletest +The main test harness for testing the compiler itself is a tool called [compiletest]. +It supports running different styles of tests, called *test suites*. +The tests are all located in the [`src/test`] directory. +The [Compiletest chapter][compiletest] goes into detail on how to use this tool. + +> Example: `./x.py test src/test/ui` + +[compiletest]: compiletest.md [`src/test`]: https://github.com/rust-lang/rust/tree/master/src/test -Here is a brief summary of the test suites and what they mean. In some -cases, the test suites are linked to parts of the manual that give more -details. - -- [`ui`](./adding.html#ui) – tests that check the exact - stdout/stderr from compilation and/or running the test -- `run-pass-valgrind` – tests that ought to run with valgrind -- `pretty` – tests targeting the Rust "pretty printer", which - generates valid Rust code from the AST -- `debuginfo` – tests that run in gdb or lldb and query the debug info -- `codegen` – tests that compile and then test the generated LLVM - code to make sure that the optimizations we want are taking effect. - See [LLVM docs](https://llvm.org/docs/CommandGuide/FileCheck.html) for how to - write such tests. -- `codegen-units` – tests for the [monomorphization](../backend/monomorph.md) - collector and CGU partitioning -- `assembly` – similar to `codegen` tests, but verifies assembly output - to make sure LLVM target backend can handle provided code. -- `mir-opt` – tests that check parts of the generated MIR to make - sure we are building things correctly or doing the optimizations we - expect. -- `incremental` – tests for incremental compilation, checking that - when certain modifications are performed, we are able to reuse the - results from previous compilations. -- `run-make` – tests that basically just execute a `Makefile`; the - ultimate in flexibility but quite annoying to write. -- `rustdoc` – tests for rustdoc, making sure that the generated files - contain the expected documentation. -- `*-fulldeps` – same as above, but indicates that the test depends - on things other than `std` (and hence those things must be built) - -## Other Tests - -The Rust build system handles running tests for various other things, -including: - -- **Tidy** – This is a custom tool used for validating source code - style and formatting conventions, such as rejecting long lines. - There is more information in the - [section on coding conventions](../conventions.html#formatting). - - Example: `./x.py test tidy` - -- **Formatting** – Rustfmt is integrated with the build system to enforce - uniform style across the compiler. In the CI, we check that the formatting - is correct. The formatting check is also automatically run by the Tidy tool - mentioned above. - - Example: `./x.py fmt --check` checks formatting and exits with an error if - formatting is needed. - - Example: `./x.py fmt` runs rustfmt on the codebase. - - Example: `./x.py test tidy --bless` does formatting before doing - other tidy checks. - -- **Unit tests** – The Rust standard library and many of the Rust packages - include typical Rust `#[test]` unittests. Under the hood, `x.py` will run - `cargo test` on each package to run all the tests. - - Example: `./x.py test library/std` - -- **Doc tests** – Example code embedded within Rust documentation is executed - via `rustdoc --test`. Examples: - - `./x.py test src/doc` – Runs `rustdoc --test` for all documentation in - `src/doc`. - - `./x.py test --doc library/std` – Runs `rustdoc --test` on the standard - library. - -- **Link checker** – A small tool for verifying `href` links within - documentation. - - Example: `./x.py test src/tools/linkchecker` - -- **Dist check** – This verifies that the source distribution tarball created - by the build system will unpack, build, and run all tests. - - Example: `./x.py test distcheck` - -- **Tool tests** – Packages that are included with Rust have all of their - tests run as well (typically by running `cargo test` within their - directory). This includes things such as cargo, clippy, rustfmt, rls, miri, - bootstrap (testing the Rust build system itself), etc. - -- **Cargo test** – This is a small tool which runs `cargo test` on a few - significant projects (such as `servo`, `ripgrep`, `tokei`, etc.) just to - ensure there aren't any significant regressions. - - Example: `./x.py test src/tools/cargotest` - -## Testing infrastructure - -When a Pull Request is opened on Github, [GitHub Actions] will automatically -launch a build that will run all tests on some configurations -(x86_64-gnu-llvm-8 linux. x86_64-gnu-tools linux, mingw-check linux). In -essence, it runs `./x.py test` after building for each of them. - -The integration bot [bors] is used for coordinating merges to the master branch. -When a PR is approved, it goes into a [queue] where merges are tested one at a -time on a wide set of platforms using GitHub Actions. Due to the limit on the -number of parallel jobs, we run CI under the [rust-lang-ci] organization except -for PRs. Most platforms only run the build steps, some run a restricted set of -tests, only a subset run the full suite of tests (see Rust's [platform tiers]). - -[GitHub Actions]: https://github.com/rust-lang/rust/actions -[rust-lang-ci]: https://github.com/rust-lang-ci/rust/actions -[bors]: https://github.com/servo/homu -[queue]: https://bors.rust-lang.org/queue/rust -[platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support - -## Testing with Docker images - -The Rust tree includes [Docker] image definitions for the platforms used on -GitHub Actions in [`src/ci/docker`]. The script [`src/ci/docker/run.sh`] is used to build -the Docker image, run it, build Rust within the image, and run the tests. - -You can run these images on your local development machine. This can be -helpful to test environments different from your local system. First you will -need to install Docker on a Linux, Windows, or macOS system (typically Linux -will be much faster than Windows or macOS because the later use virtual -machines to emulate a Linux environment). To enter interactive mode which will -start a bash shell in the container, run `src/ci/docker/run.sh --dev ` -where `` is one of the directory names in `src/ci/docker` (for example -`x86_64-gnu` is a fairly standard Ubuntu environment). - -The docker script will mount your local Rust source tree in read-only mode, -and an `obj` directory in read-write mode. All of the compiler artifacts will -be stored in the `obj` directory. The shell will start out in the `obj` -directory. From there, you can run `../src/ci/run.sh` which will run the build -as defined by the image. - -Alternatively, you can run individual commands to do specific tasks. For -example, you can run `python3 ../x.py test src/test/ui` to just run UI tests. -Note that there is some configuration in the [`src/ci/run.sh`] script that you -may need to recreate. Particularly, set `submodules = false` in your -`config.toml` so that it doesn't attempt to modify the read-only directory. - -Some additional notes about using the Docker images: - -- Some of the std tests require IPv6 support. Docker on Linux seems to have it - disabled by default. Run the commands in [`enable-docker-ipv6.sh`] to enable - IPv6 before creating the container. This only needs to be done once. -- The container will be deleted automatically when you exit the shell, however - the build artifacts persist in the `obj` directory. If you are switching - between different Docker images, the artifacts from previous environments - stored in the `obj` directory may confuse the build system. Sometimes you - will need to delete parts or all of the `obj` directory before building - inside the container. -- The container is bare-bones, with only a minimal set of packages. You may - want to install some things like `apt install less vim`. -- You can open multiple shells in the container. First you need the container - name (a short hash), which is displayed in the shell prompt, or you can run - `docker container ls` outside of the container to list the available - containers. With the container name, run `docker exec -it - /bin/bash` where `` is the container name like `4ba195e95cef`. - -[Docker]: https://www.docker.com/ -[`src/ci/docker`]: https://github.com/rust-lang/rust/tree/master/src/ci/docker -[`src/ci/docker/run.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/docker/run.sh -[`src/ci/run.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/run.sh -[`enable-docker-ipv6.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/scripts/enable-docker-ipv6.sh - -## Running tests on a remote machine - -Tests may be run on a remote machine (e.g. to test builds for a different -architecture). This is done using `remote-test-client` on the build machine -to send test programs to `remote-test-server` running on the remote machine. -`remote-test-server` executes the test programs and sends the results back to -the build machine. `remote-test-server` provides *unauthenticated remote code -execution* so be careful where it is used. - -To do this, first build `remote-test-server` for the remote -machine, e.g. for RISC-V -```sh -./x.py build src/tools/remote-test-server --target riscv64gc-unknown-linux-gnu -``` +### Package tests -The binary will be created at -`./build/$HOST_ARCH/stage2-tools/$TARGET_ARCH/release/remote-test-server`. Copy -this over to the remote machine. +The standard library and many of the compiler packages include typical Rust `#[test]` +unit tests, integration tests, and documentation tests. +You can pass a path to `x.py` to almost any package in the `library` or `compiler` directory, +and `x.py` will essentially run `cargo test` on that package. -On the remote machine, run the `remote-test-server` with the `remote` argument -(and optionally `-v` for verbose output). Output should look like this: -```sh -$ ./remote-test-server -v remote -starting test server -listening on 0.0.0.0:12345! -``` +Examples: -You can test if the `remote-test-server` is working by connecting to it and -sending `ping\n`. It should reply `pong`: -```sh -$ nc $REMOTE_IP 12345 -ping -pong -``` +| Command | Description | +|---------|-------------| +| `./x.py test library/std` | Runs tests on `std` | +| `./x.py test library/core` | Runs tests on `core` | +| `./x.py test compiler/rustc_data_structures` | Runs tests on `rustc_data_structures` | -To run tests using the remote runner, set the `TEST_DEVICE_ADDR` environment -variable then use `x.py` as usual. For example, to run `ui` tests for a RISC-V -machine with the IP address `1.2.3.4` use -```sh -export TEST_DEVICE_ADDR="1.2.3.4:12345" -./x.py test src/test/ui --target riscv64gc-unknown-linux-gnu -``` +The standard library relies very heavily on documentation tests to cover its functionality. +However, unit tests and integration tests can also be used as needed. +Almost all of the compiler packages have doctests disabled. -If `remote-test-server` was run with the verbose flag, output on the test machine -may look something like -``` -[...] -run "/tmp/work/test1007/a" -run "/tmp/work/test1008/a" -run "/tmp/work/test1009/a" -run "/tmp/work/test1010/a" -run "/tmp/work/test1011/a" -run "/tmp/work/test1012/a" -run "/tmp/work/test1013/a" -run "/tmp/work/test1014/a" -run "/tmp/work/test1015/a" -run "/tmp/work/test1016/a" -run "/tmp/work/test1017/a" -run "/tmp/work/test1018/a" -[...] +The standard library and compiler always place all unit tests in a separate `tests` file +(this is enforced in [tidy][tidy-unit-tests]). +This approach ensures that when the test file is changed, the crate does not need to be recompiled. +For example: + +```rust,ignore +#[cfg(test)] +mod tests; ``` -Tests are built on the machine running `x.py` not on the remote machine. Tests -which fail to build unexpectedly (or `ui` tests producing incorrect build -output) may fail without ever running on the remote machine. - -## Testing on emulators - -Some platforms are tested via an emulator for architectures that aren't -readily available. For architectures where the standard library is well -supported and the host operating system supports TCP/IP networking, see the -above instructions for testing on a remote machine (in this case the -remote machine is emulated). - -There is also a set of tools for orchestrating running the -tests within the emulator. Platforms such as `arm-android` and -`arm-unknown-linux-gnueabihf` are set up to automatically run the tests under -emulation on GitHub Actions. The following will take a look at how a target's tests -are run under emulation. - -The Docker image for [armhf-gnu] includes [QEMU] to emulate the ARM CPU -architecture. Included in the Rust tree are the tools [remote-test-client] -and [remote-test-server] which are programs for sending test programs and -libraries to the emulator, and running the tests within the emulator, and -reading the results. The Docker image is set up to launch -`remote-test-server` and the build tools use `remote-test-client` to -communicate with the server to coordinate running tests (see -[src/bootstrap/test.rs]). - -> TODO: -> Is there any support for using an iOS emulator? -> -> It's also unclear to me how the wasm or asm.js tests are run. - -[armhf-gnu]: https://github.com/rust-lang/rust/tree/master/src/ci/docker/host-x86_64/armhf-gnu/Dockerfile -[QEMU]: https://www.qemu.org/ -[remote-test-client]: https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-client -[remote-test-server]: https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-server -[src/bootstrap/test.rs]: https://github.com/rust-lang/rust/tree/master/src/bootstrap/test.rs - -## Crater - -[Crater](https://github.com/rust-lang/crater) is a tool for compiling -and running tests for _every_ crate on [crates.io](https://crates.io) (and a -few on GitHub). It is mainly used for checking for extent of breakage when -implementing potentially breaking changes and ensuring lack of breakage by -running beta vs stable compiler versions. - -### When to run Crater - -You should request a crater run if your PR makes large changes to the compiler -or could cause breakage. If you are unsure, feel free to ask your PR's reviewer. - -### Requesting Crater Runs - -The Rust team maintains a few machines that can be used for running crater runs -on the changes introduced by a PR. If your PR needs a crater run, leave a -comment for the triage team in the PR thread. Please inform the team whether -you require a "check-only" crater run, a "build only" crater run, or a -"build-and-test" crater run. The difference is primarily in time; the -conservative (if you're not sure) option is to go for the build-and-test run. -If making changes that will only have an effect at compile-time (e.g., -implementing a new trait) then you only need a check run. - -Your PR will be enqueued by the triage team and the results will be posted when -they are ready. Check runs will take around ~3-4 days, with the other two -taking 5-6 days on average. - -While crater is really useful, it is also important to be aware of a few -caveats: - -- Not all code is on crates.io! There is a lot of code in repos on GitHub and - elsewhere. Also, companies may not wish to publish their code. Thus, a - successful crater run is not a magically green light that there will be no - breakage; you still need to be careful. - -- Crater only runs Linux builds on x86_64. Thus, other architectures and - platforms are not tested. Critically, this includes Windows. - -- Many crates are not tested. This could be for a lot of reasons, including - that the crate doesn't compile any more (e.g. used old nightly features), - has broken or flaky tests, requires network access, or other reasons. - -- Before crater can be run, `@bors try` needs to succeed in building artifacts. - This means that if your code doesn't compile, you cannot run crater. - -## Perf runs - -A lot of work is put into improving the performance of the compiler and -preventing performance regressions. A "perf run" is used to compare the -performance of the compiler in different configurations for a large collection -of popular crates. Different configurations include "fresh builds", builds -with incremental compilation, etc. - -The result of a perf run is a comparison between two versions of the -compiler (by their commit hashes). - -You should request a perf run if your PR may affect performance, especially -if it can affect performance adversely. +If it wasn't done this way, and the tests were placed in the same file as the source, +then changing or adding a test would cause the crate you are working on to be recompiled. +If you were working on something like `core`, +then that would require recompiling the entire standard library, and the entirety of `rustc`. + +`./x.py test` includes some CLI options for controlling the behavior with these tests: + +* `--doc` — Only runs documentation tests in the package. +* `--no-doc` — Run all tests *except* documentation tests. + +[tidy-unit-tests]: https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/unit_tests.rs + +### Tidy + +Tidy is a custom tool used for validating source code style and formatting conventions, +such as rejecting long lines. +There is more information in the [section on coding conventions](../conventions.md#formatting). + +> Example: `./x.py test tidy` + +### Formatting + +Rustfmt is integrated with the build system to enforce uniform style across the compiler. +The formatting check is automatically run by the Tidy tool mentioned above. + +Examples: + +| Command | Description | +|---------|-------------| +| `./x.py fmt --check` | Checks formatting and exits with an error if formatting is needed. | +| `./x.py fmt` | Runs rustfmt across the entire codebase. | +| `./x.py test tidy --bless` | First runs rustfmt to format the codebase, then runs tidy checks. | + +### Book documentation tests + +All of the books that are published have their own tests, +primarily for validating that the Rust code examples pass. +Under the hood, these are essentially using `rustdoc --test` on the markdown files. +The tests can be run by passing a path to a book to `./x.py test`. + +> Example: `./x.py test src/doc/book` + +### Documentation link checker + +Links across all documentation is validated with a link checker tool. + +> Example: `./x.py test src/tools/linkchecker` + +This requires building all of the documentation, which might take a while. + +### Dist check + +`distcheck` verifies that the source distribution tarball created by the build system +will unpack, build, and run all tests. + +> Example: `./x.py test distcheck` + +### Tool tests + +Packages that are included with Rust have all of their tests run as well. +This includes things such as cargo, clippy, rustfmt, rls, miri, bootstrap +(testing the Rust build system itself), etc. + +Most of the tools are located in the [`src/tools`] directory. +To run the tool's tests, just pass its path to `./x.py test`. + +> Example: `./x.py test src/tools/cargo` + +Usually these tools involve running `cargo test` within the tool's directory. + +In CI, some tools are allowed to fail. +Failures send notifications to the corresponding teams, and is tracked on the [toolstate website]. +More information can be found in the [toolstate documentation]. + +[`src/tools`]: https://github.com/rust-lang/rust/tree/master/src/tools/ +[toolstate documentation]: https://forge.rust-lang.org/infra/toolstate.html +[toolstate website]: https://rust-lang-nursery.github.io/rust-toolstate/ + +### Cargo test + +`cargotest` is a small tool which runs `cargo test` on a few sample projects +(such as `servo`, `ripgrep`, `tokei`, etc.). +This ensures there aren't any significant regressions. + +> Example: `./x.py test src/tools/cargotest` + +### Crater + +Crater is a tool which runs tests on many thousands of public projects. +This tool has its own separate infrastructure for running. +See the [Crater chapter](crater.md) for more details. + +### Performance testing + +A separate infrastructure is used for testing and tracking performance of the compiler. +See the [Performance testing chapter](perf.md) for more details. ## Further reading diff --git a/src/tests/perf.md b/src/tests/perf.md new file mode 100644 index 000000000..ac65faff1 --- /dev/null +++ b/src/tests/perf.md @@ -0,0 +1,50 @@ +# Performance testing + +## rustc-perf + +A lot of work is put into improving the performance of the compiler and +preventing performance regressions. +The [rustc-perf](https://github.com/rust-lang/rustc-perf) project provides +several services for testing and tracking performance. +It provides hosted infrastructure for running benchmarks as a service. +At this time, only `x86_64-unknown-linux-gnu` builds are tracked. + +A "perf run" is used to compare the performance of the compiler in different +configurations for a large collection of popular crates. +Different configurations include "fresh builds", builds with incremental compilation, etc. + +The result of a perf run is a comparison between two versions of the compiler +(by their commit hashes). + +### Automatic perf runs + +After every PR is merged, a suite of benchmarks are run against the compiler. +The results are tracked over time on the website. +Any changes are noted in a comment on the PR. + +### Manual perf runs + +Additionally, performance tests can be ran before a PR is merged on an as-needed basis. +You should request a perf run if your PR may affect performance, especially if +it can affect performance adversely. + +To evaluate the performance impact of a PR, write this comment on the PR: + +`@bors try @rust-timer queue` + +> **Note**: Only users authorized to do perf runs are allowed to post this comment. +> Teams that are allowed to use it are tracked in the [Teams +> repository](https://github.com/rust-lang/team) with the `perf = true` value +> in the `[permissions]` section (and bors permissions are also required). +> If you are not on one of those teams, feel free to ask for someone to post +> it for you (either on Zulip or ask the assigned reviewer). + +This will first tell bors to do a "try" build which do a full release build +for `x86_64-unknown-linux-gnu`. +After the build finishes, it will place it in the queue to run the performance +suite against it. +After the performance tests finish, the bot will post a comment on the PR with +a summary and a link to a full report. + +More details are available in the [perf collector +documentation](https://github.com/rust-lang/rustc-perf/blob/master/collector/README.md). diff --git a/src/tests/running.md b/src/tests/running.md index cd8f12ba1..2e823c0ed 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -18,8 +18,9 @@ I think is done, but rarely otherwise. -nmatsakis) The test results are cached and previously successful tests are `ignored` during testing. The stdout/stderr contents as well as a timestamp file for every test can be found under `build/ARCH/test/`. -To force-rerun a test (e.g. in case the test runner fails to notice -a change) you can simply remove the timestamp file. +To force-rerun a test (e.g. in case the test runner fails to notice a change) +you can simply remove the timestamp file, or use the `--force-rerun` CLI +option. Note that some tests require a Python-enabled gdb. You can test if your gdb install supports Python by using the `python` command from @@ -143,6 +144,18 @@ to automatically adjust the `.stderr`, `.stdout` or `.fixed` files of all tests. Of course you can also target just specific tests with the `--test-args your_test_name` flag, just like when running the tests. +## Configuring test running + +There are a few options for running tests: + +* `config.toml` has the `rust.verbose-tests` option. + If `false`, each test will print a single dot (the default). + If `true`, the name of every test will be printed. + This is equivalent to the `--quiet` option in the [Rust test + harness](https://doc.rust-lang.org/rustc/tests/) +* The environment variable `RUST_TEST_THREADS` can be set to the number of + concurrent threads to use for testing. + ## Passing `--pass $mode` Pass UI tests now have three modes, `check-pass`, `build-pass` and @@ -156,9 +169,8 @@ exists in the test file. For example, you can run all the tests in ``` By passing `--pass $mode`, you can reduce the testing time. For each -mode, please see [here][mode]. - -[mode]: ./adding.md#tests-that-do-not-result-in-compile-errors +mode, please see [Controlling pass/fail +expectations](ui.md#controlling-passfail-expectations). ## Using incremental compilation @@ -193,17 +205,7 @@ To run the UI test suite in NLL mode, one would use the following: ./x.py test src/test/ui --compare-mode=nll ``` -The possible compare modes are: - -* nll - currently nll is implemented in migrate mode, this option runs with true nll. -* polonius -* chalk -* split-dwarf -* split-dwarf-single - -Note that compare modes are separate to [revisions](./adding.html#revisions). -All revisions are tested when running `./x.py test src/test/ui`, -however compare-modes must be manually run individually via the `--compare-mode` flag. +See [Compare modes](compiletest.md#compare-modes) for more details. ## Running tests manually @@ -219,3 +221,105 @@ rustc +stage1 src/test/ui/issue-1234.rs This is much faster, but doesn't always work. For example, some tests include directives that specify specific compiler flags, or which rely on other crates, and they may not run the same without those options. + + +## Running tests on a remote machine + +Tests may be run on a remote machine (e.g. to test builds for a different +architecture). This is done using `remote-test-client` on the build machine +to send test programs to `remote-test-server` running on the remote machine. +`remote-test-server` executes the test programs and sends the results back to +the build machine. `remote-test-server` provides *unauthenticated remote code +execution* so be careful where it is used. + +To do this, first build `remote-test-server` for the remote +machine, e.g. for RISC-V +```sh +./x.py build src/tools/remote-test-server --target riscv64gc-unknown-linux-gnu +``` + +The binary will be created at +`./build/$HOST_ARCH/stage2-tools/$TARGET_ARCH/release/remote-test-server`. Copy +this over to the remote machine. + +On the remote machine, run the `remote-test-server` with the `remote` argument +(and optionally `-v` for verbose output). Output should look like this: +```sh +$ ./remote-test-server -v remote +starting test server +listening on 0.0.0.0:12345! +``` + +You can test if the `remote-test-server` is working by connecting to it and +sending `ping\n`. It should reply `pong`: +```sh +$ nc $REMOTE_IP 12345 +ping +pong +``` + +To run tests using the remote runner, set the `TEST_DEVICE_ADDR` environment +variable then use `x.py` as usual. For example, to run `ui` tests for a RISC-V +machine with the IP address `1.2.3.4` use +```sh +export TEST_DEVICE_ADDR="1.2.3.4:12345" +./x.py test src/test/ui --target riscv64gc-unknown-linux-gnu +``` + +If `remote-test-server` was run with the verbose flag, output on the test machine +may look something like +``` +[...] +run "/tmp/work/test1007/a" +run "/tmp/work/test1008/a" +run "/tmp/work/test1009/a" +run "/tmp/work/test1010/a" +run "/tmp/work/test1011/a" +run "/tmp/work/test1012/a" +run "/tmp/work/test1013/a" +run "/tmp/work/test1014/a" +run "/tmp/work/test1015/a" +run "/tmp/work/test1016/a" +run "/tmp/work/test1017/a" +run "/tmp/work/test1018/a" +[...] +``` + +Tests are built on the machine running `x.py` not on the remote machine. Tests +which fail to build unexpectedly (or `ui` tests producing incorrect build +output) may fail without ever running on the remote machine. + +## Testing on emulators + +Some platforms are tested via an emulator for architectures that aren't +readily available. For architectures where the standard library is well +supported and the host operating system supports TCP/IP networking, see the +above instructions for testing on a remote machine (in this case the +remote machine is emulated). + +There is also a set of tools for orchestrating running the +tests within the emulator. Platforms such as `arm-android` and +`arm-unknown-linux-gnueabihf` are set up to automatically run the tests under +emulation on GitHub Actions. The following will take a look at how a target's tests +are run under emulation. + +The Docker image for [armhf-gnu] includes [QEMU] to emulate the ARM CPU +architecture. Included in the Rust tree are the tools [remote-test-client] +and [remote-test-server] which are programs for sending test programs and +libraries to the emulator, and running the tests within the emulator, and +reading the results. The Docker image is set up to launch +`remote-test-server` and the build tools use `remote-test-client` to +communicate with the server to coordinate running tests (see +[src/bootstrap/test.rs]). + +> TODO: +> Is there any support for using an iOS emulator? +> +> It's also unclear to me how the wasm or asm.js tests are run. + +[armhf-gnu]: https://github.com/rust-lang/rust/tree/master/src/ci/docker/host-x86_64/armhf-gnu/Dockerfile +[QEMU]: https://www.qemu.org/ +[remote-test-client]: https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-client +[remote-test-server]: https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-server +[src/bootstrap/test.rs]: https://github.com/rust-lang/rust/tree/master/src/bootstrap/test.rs + diff --git a/src/tests/ui.md b/src/tests/ui.md new file mode 100644 index 000000000..a8e8d3b72 --- /dev/null +++ b/src/tests/ui.md @@ -0,0 +1,500 @@ +# UI tests + + + +UI tests are a particular [test suite](compiletest.md#test-suites) of compiletest. + +## Introduction + +The tests in [`src/test/ui`] are a collection of general-purpose tests which +primarily focus on validating the console output of the compiler, but can be +used for many other purposes. +For example, tests can also be configured to [run the resulting +program](#controlling-passfail-expectations) to verify its behavior. + +[`src/test/ui`]: https://github.com/rust-lang/rust/blob/master/src/test/ui + +## General structure of a test + +A test consists of a Rust source file located anywhere in the `src/test/ui` directory. +For example, [`src/test/ui/hello.rs`] is a basic hello-world test. + +Compiletest will use `rustc` to compile the test, and compare the output +against the expected output which is stored in a `.stdout` or `.stderr` file +located next to the test. +See [Output comparison](#output-comparison) for more. + +Additionally, errors and warnings should be annotated with comments within +the source file. +See [Error annotations](#error-annotations) for more. + +[Headers](headers.md) in the form of comments at the top of the file control +how the test is compiled and what the expected behavior is. + +Tests are expected to fail to compile, since most tests are testing compiler +errors. +You can change that behavior with a header, see [Controlling pass/fail +expectations](#controlling-passfail-expectations). + +By default, a test is built as an executable binary. +If you need a different crate type, you can use the `#![crate_type]` attribute +to set it as needed. + +[`src/test/ui/hello.rs`]: https://github.com/rust-lang/rust/blob/master/src/test/ui/hello.rs + +## Output comparison + +UI tests store the expected output from the compiler in `.stderr` and +`.stdout` files next to the test. +You normally generate these files with the `--bless` CLI option, and then +inspect them manually to verify they contain what you expect. + +The output is normalized to ignore unwanted differences, see the +[Normalization](#normalization) section. +If the file is missing, then compiletest expects the corresponding output to +be empty. + +There can be multiple stdout/stderr files. +The general form is: + +*test-name*`.`*revision*`.`*compare_mode*`.`*extension* + +* *revision* is the [revision](#cfg-revisions) name. + This is not included when not using revisions. +* *compare_mode* is the [compare mode](#compare-modes). + This will only be checked when the given compare mode is active. + If the file does not exist, then compiletest will check for a file without + the compare mode. +* *extension* is the kind of output being checked: + * `stderr` — compiler stderr + * `stdout` — compiler stdout + * `run.stderr` — stderr when running the test + * `run.stdout` — stdout when running the test + * `64bit.stderr` — compiler stderr with `stderr-per-bitwidth` header on a 64-bit target + * `32bit.stderr` — compiler stderr with `stderr-per-bitwidth` header on a 32-bit target + +A simple example would be `foo.stderr` next to a `foo.rs` test. +A more complex example would be `foo.my-revision.nll.stderr`. + +There are several [headers](headers.md) which will change how compiletest will +check for output files: + +* `stderr-per-bitwidth` — checks separate output files based on the target + pointer width. Consider using the `normalize-stderr` header instead (see + [Normalization](#normalization)). +* `dont-check-compiler-stderr` — Ignores stderr from the compiler. +* `dont-check-compiler-stdout` — Ignores stdout from the compiler. + +UI tests run with with `-Zdeduplicate-diagnostics=no` flag which disables +rustc's built-in diagnostic deduplication mechanism. +This means you may see some duplicate messages in the output. +This helps illuminate situations where duplicate diagnostics are being +generated. + +### Normalization + +The compiler output is normalized to eliminate output difference between +platforms, mainly about filenames. + +Compiletest makes the following replacements on the compiler output: + +- The directory where the test is defined is replaced with `$DIR`. + Example: `/path/to/rust/src/test/ui/error-codes` +- The directory to the standard library source is replaced with `$SRC_DIR`. + Example: `/path/to/rust/library` +- Line and column numbers for paths in `$SRC_DIR` are replaced with `LL:COL`. + This helps ensure that changes to the layout of the standard library do not + cause widespread changes to the `.stderr` files. + Example: `$SRC_DIR/alloc/src/sync.rs:53:46` +- The base directory where the test's output goes is replaced with `$TEST_BUILD_DIR`. + This only comes up in a few rare circumstances. + Example: `/path/to/rust/build/x86_64-unknown-linux-gnu/test/ui` +- Tabs are replaced with `\t`. +- Backslashes (`\`) are converted to forward slashes (`/`) within paths (using + a heuristic). This helps normalize differences with Windows-style paths. +- CRLF newlines are converted to LF. +- Error line annotations like `//~ ERROR some message` are removed. +- Various v0 and legacy symbol hashes are replaced with placeholders like + `[HASH]` or ``. + +Additionally, the compiler is run with the `-Z ui-testing` flag which causes +the compiler itself to apply some changes to the diagnostic output to make it +more suitable for UI testing. +For example, it will anonymize line numbers in the output (line numbers +prefixing each source line are replaced with `LL`). +In extremely rare situations, this mode can be disabled with the header +command `// compile-flags: -Z ui-testing=no`. + +Note: The line and column numbers for `-->` lines pointing to the test are +*not* normalized, and left as-is. This ensures that the compiler continues +to point to the correct location, and keeps the stderr files readable. +Ideally all line/column information would be retained, but small changes to +the source causes large diffs, and more frequent merge conflicts and test +errors. + +Sometimes these built-in normalizations are not enough. In such cases, you +may provide custom normalization rules using the header commands, e.g. + +```rust,ignore +// normalize-stdout-test: "foo" -> "bar" +// normalize-stderr-32bit: "fn\(\) \(32 bits\)" -> "fn\(\) \($$PTR bits\)" +// normalize-stderr-64bit: "fn\(\) \(64 bits\)" -> "fn\(\) \($$PTR bits\)" +``` + +This tells the test, on 32-bit platforms, whenever the compiler writes +`fn() (32 bits)` to stderr, it should be normalized to read `fn() ($PTR bits)` +instead. Similar for 64-bit. The replacement is performed by regexes using +default regex flavor provided by `regex` crate. + +The corresponding reference file will use the normalized output to test both +32-bit and 64-bit platforms: + +```text +... + | + = note: source type: fn() ($PTR bits) + = note: target type: u16 (16 bits) +... +``` + +Please see [`ui/transmute/main.rs`][mrs] and [`main.stderr`] for a +concrete usage example. + +[mrs]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.rs +[`main.stderr`]: https://github.com/rust-lang/rust/blob/master/src/test/ui/transmute/main.stderr + +Besides `normalize-stderr-32bit` and `-64bit`, one may use any target +information or stage supported by [`ignore-X`](headers.md#ignoring-tests) +here as well (e.g. `normalize-stderr-windows` or simply +`normalize-stderr-test` for unconditional replacement). + + +## Error annotations + +Error annotations specify the errors that the compiler is expected to emit. +They are "attached" to the line in source where the error is located. + +```rust,ignore +fn main() { + boom //~ ERROR cannot find value `boom` in this scope [E0425] +} +``` + +Although UI tests have a `.stderr` file which contains the entire compiler output, +UI tests require that errors are also annotated within the source. +This redundancy helps avoid mistakes since the `.stderr` files are usually +auto-generated. +It also helps to directly see where the error spans are expected to point to +by looking at one file instead of having to compare the `.stderr` file with +the source. +Finally, they ensure that no additional unexpected errors are generated. + +They have several forms, but generally are a comment with the diagnostic +level (such as `ERROR`) and a substring of the expected error output. +You don't have to write out the entire message, just make sure to include the +important part of the message to make it self-documenting. + +The error annotation needs to match with the line of the diagnostic. +There are several ways to match the message with the line (see the examples below): + +* `~`: Associates the error level and message with the current line +* `~^`: Associates the error level and message with the previous error + annotation line. + Each caret (`^`) that you add adds a line to this, so `~^^^` is three lines + above the error annotation line. +* `~|`: Associates the error level and message with the same line as the + previous comment. + This is more convenient than using multiple carets when there are multiple + messages associated with the same line. + +### Error annotation examples + +Here are examples of error annotations on different lines of UI test +source. + +#### Positioned on error line + +Use the `//~ ERROR` idiom: + +```rust,ignore +fn main() { + let x = (1, 2, 3); + match x { + (_a, _x @ ..) => {} //~ ERROR `_x @` is not allowed in a tuple + _ => {} + } +} +``` + +#### Positioned below error line + +Use the `//~^` idiom with number of carets in the string to indicate the +number of lines above. +In the example below, the error line is four lines above the error annotation +line so four carets are included in the annotation. + +```rust,ignore +fn main() { + let x = (1, 2, 3); + match x { + (_a, _x @ ..) => {} // <- the error is on this line + _ => {} + } +} +//~^^^^ ERROR `_x @` is not allowed in a tuple +``` + +#### Use same error line as defined on error annotation line above + +Use the `//~|` idiom to define the same error line as the error annotation +line above: + +```rust,ignore +struct Binder(i32, i32, i32); + +fn main() { + let x = Binder(1, 2, 3); + match x { + Binder(_a, _x @ ..) => {} // <- the error is on this line + _ => {} + } +} +//~^^^^ ERROR `_x @` is not allowed in a tuple struct +//~| ERROR this pattern has 1 field, but the corresponding tuple struct has 3 fields [E0023] +``` + +### `error-pattern` + +The `error-pattern` [header](headers.md) can be used for +messages that don't have a specific span. + +Let's think about this test: + +```rust,ignore +fn main() { + let a: *const [_] = &[1, 2, 3]; + unsafe { + let _b = (*a)[3]; + } +} +``` + +We want to ensure this shows "index out of bounds" but we cannot use the +`ERROR` annotation since the error doesn't have any span. +Then it's time to use the `error-pattern` header: + +```rust,ignore +// error-pattern: index out of bounds +fn main() { + let a: *const [_] = &[1, 2, 3]; + unsafe { + let _b = (*a)[3]; + } +} +``` + +But for strict testing, try to use the `ERROR` annotation as much as possible. + +### Error levels + +The error levels that you can have are: + +1. `ERROR` +2. `WARN` or `WARNING` +3. `NOTE` +4. `HELP` and `SUGGESTION` + +You are allowed to not include a level, but you should include it at least for +the primary message. + +The `SUGGESTION` level is used for specifying what the expected replacement +text should be for a diagnostic suggestion. + +UI tests use the `-A unused` flag by default to ignore all unused warnings, as +unused warnings are usually not the focus of a test. +However, simple code samples often have unused warnings. +If the test is specifically testing an unused warning, just add the +appropriate `#![warn(unused)]` attribute as needed. + +### cfg revisions + +When using [revisions](compiletest.md#revisions), different messages can be +conditionally checked based on the current revision. +This is done by placing the revision cfg name in brackets like this: + +```rust,ignore +// edition:2018 +// revisions: mir thir +// [thir]compile-flags: -Z thir-unsafeck + +async unsafe fn f() {} + +async fn g() { + f(); //~ ERROR call to unsafe function is unsafe +} + +fn main() { + f(); //[mir]~ ERROR call to unsafe function is unsafe +} +``` + +In this example, the second error message is only emitted in the `mir` revision. +The `thir` revision only emits the first error. + +If the cfg causes the compiler to emit different output, then a test can have +multiple `.stderr` files for the different outputs. +In the example above, there would be a `.mir.stderr` and `.thir.stderr` file +with the different outputs of the different revisions. + + +## Controlling pass/fail expectations + +By default, a UI test is expected to **generate a compile error** because most +of the tests are checking for invalid input and error diagnostics. +However, you can also make UI tests where compilation is expected to succeed, +and you can even run the resulting program. +Just add one of the following [header commands](headers.md): + +* Pass headers: + * `// check-pass` — compilation should succeed but skip codegen + (which is expensive and isn't supposed to fail in most cases). + * `// build-pass` — compilation and linking should succeed but do + not run the resulting binary. + * `// run-pass` — compilation should succeed and running the resulting + binary should also succeed. +* Fail headers: + * `// check-fail` — compilation should fail (the codegen phase is skipped). + This is the default for UI tests. + * `// build-fail` — compilation should fail during the codegen phase. + This will run `rustc` twice, once to verify that it compiles successfully + without the codegen phase, then a second time the full compile should + fail. + * `// run-fail` — compilation should succeed, but running the resulting + binary should fail. + +For `run-pass` and `run-fail` tests, by default the output of the program +itself is not checked. +If you want to check the output of running the program, include the +`check-run-results` header. +This will check for a `.run.stderr` and `.run.stdout` files to compare +against the actual output of the program. + +Tests with the `*-pass` headers can be overridden with the `--pass` +command-line option: + +```sh +./x.py test src/test/ui --pass check +``` + +The `--pass` option only affects UI tests. +Using `--pass check` can run the UI test suite much faster (roughly twice as +fast on my system), though obviously not exercising as much. + +The `ignore-pass` header can be used to ignore the `--pass` CLI flag if the +test won't work properly with that override. + + +## Test organization + +When deciding where to place a test file, please try to find a subdirectory +that best matches what you are trying to exercise. +Do your best to keep things organized. +Admittedly it can be difficult as some tests can overlap different categories, +and the existing layout may not fit well. + +For regression tests – basically, some random snippet of code that came in +from the internet – we often name the test after the issue plus a short +description. +Ideally, the test should be added to a directory that helps identify what +piece of code is being tested here (e.g., +`src/test/ui/borrowck/issue-54597-reject-move-out-of-borrow-via-pat.rs`) + +When writing a new feature, **create a subdirectory to store your tests**. +For example, if you are implementing RFC 1234 ("Widgets"), then it might make +sense to put the tests in a directory like `src/test/ui/rfc1234-widgets/`. + +In other cases, there may already be a suitable directory. (The proper +directory structure to use is actually an area of active debate.) + +Over time, the [`src/test/ui`] directory has grown very fast. +There is a check in [tidy](intro.md#tidy) that will ensure none of the +subdirectories has more than 1000 entries. +Having too many files causes problems because it isn't editor/IDE friendly and +the GitHub UI won't show more than 1000 entries. +However, since `src/test/ui` (UI test root directory) and `src/test/ui/issues` +directories have more than 1000 entries, we set a different limit for those +directories. +So, please avoid putting a new test there and try to find a more relevant +place. + +For example, if your test is related to closures, you should put it in +`src/test/ui/closures`. +If you're not sure where is the best place, it's still okay to add to +`src/test/ui/issues/`. +When you reach the limit, you could increase it by tweaking [here][ui test +tidy]. + +[ui test tidy]: https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/ui_tests.rs + + +## Rustfix tests + +UI tests can validate that diagnostic suggestions apply correctly +and that the resulting changes compile correctly. +This can be done with the `run-rustfix` header: + +```rust,ignore +// run-rustfix +// check-pass +#![crate_type = "lib"] + +pub struct not_camel_case {} +//~^ WARN `not_camel_case` should have an upper camel case name +//~| HELP convert the identifier to upper camel case +//~| SUGGESTION NotCamelCase +``` + +Rustfix tests should have a file with the `.fixed` extension which contains +the source file after the suggestion has been applied. + +When the test is run, compiletest first checks that the correct +lint/warning is generated. +Then, it applies the suggestion and compares against `.fixed` (they must match). +Finally, the fixed source is compiled, and this compilation is required to succeed. + +Usually when creating a rustfix test you will generate the `.fixed` file +automatically with the `x.py test --bless` option. + +The `run-rustfix` header will cause *all* suggestions to be applied, even +if they are not [`MachineApplicable`](../diagnostics.md#suggestions). +If this is a problem, then you can instead use the `rustfix-only-machine-applicable` +header. +This should be used if there is a mixture of different suggestion levels, and +some of the non-machine-applicable ones do not apply cleanly. + + +## Compare modes + +[Compare modes](compiletest.md#compare-modes) can be used to run all tests +with different flags from what they are normally compiled with. +In some cases, this might result in different output from the compiler. +To support this, different output files can be saved which contain the +output based on the compare mode. + +For example, when in "non-lexical lifetimes" (NLL) mode a test `foo.rs` will +first look for expected output in `foo.nll.stderr`, falling back to the usual +`foo.stderr` if not found. +This is useful as "true" NLL mode can sometimes result in different +diagnostics and behavior compared to the "migrate mode" NLL (which is the +current default). +This can help track which tests have differences between the modes, and to +visually inspect those diagnostic differences. + +If in the rare case you encounter a test that has different behavior, you can +run something like the following to generate the alternate stderr file: + +```sh +./x.py test src/test/ui --compare-mode=nll --bless +``` + +Currently, only `nll` mode is checked in CI for UI tests. From 341abec62a6c34ba59c90fad8989232dcc6bf3b4 Mon Sep 17 00:00:00 2001 From: Ivor Wanders Date: Thu, 20 Jan 2022 18:17:31 -0500 Subject: [PATCH 1615/1812] Clarify that r? works in comments. --- src/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/contributing.md b/src/contributing.md index 2d6511321..0c6b15da3 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -77,7 +77,7 @@ All pull requests are reviewed by another person. We have a bot, to review your request based on which files you changed. If you want to request that a specific person reviews your pull request, you -can add an `r?` to the pull request description. For example, +can add an `r?` to the pull request description or in a comment. For example, [Steve][steveklabnik] usually reviews documentation changes. So if you were to make a documentation change, add From 8763adb62c712df69b1d39ea3e692b6d696cc4d9 Mon Sep 17 00:00:00 2001 From: "Felix S. Klock II" Date: Wed, 26 Jan 2022 14:44:32 -0500 Subject: [PATCH 1616/1812] git.md: Expanded a note to try to stress what you need to do if you're playing games with submodules. (I overlooked this when cherry-picking an LLVM commit today, and wasted some time wondering why I wasn't seeing any effect in my resulting `rustc` build...) --- src/git.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/git.md b/src/git.md index e9588fd59..6af774ca8 100644 --- a/src/git.md +++ b/src/git.md @@ -415,8 +415,13 @@ This is because, like any dependency, we want to be able to control which versio Submodules allow us to do just that: every submodule is "pinned" to a certain commit, which doesn't change unless modified manually. If you use `git checkout ` in the `miri` directory and go back to the `rust` directory, you can stage this -change like any other. This is usually done by the maintainers of the -project, and looks like [this][miri-update]. +change like any other, e.g. by running `git add src/tools/miri`. (Note that if +you *don't* stage the change to commit, then you run the risk that running +`x.py` will just undo your change by switching back to the previous commit when +it automatically "updates" the submodules.) + +This version selection is usually done by the maintainers of the project, and +looks like [this][miri-update]. Git submodules take some time to get used to, so don't worry if it isn't perfectly clear yet. You will rarely have to use them directly and, again, you don't need From dc47b51114466cbf1ed9d8bad95d5982806837a4 Mon Sep 17 00:00:00 2001 From: Manish Goregaokar Date: Fri, 4 Feb 2022 22:03:17 -0800 Subject: [PATCH 1617/1812] mention test folders for cfg(bootstrap) (#1294) --- src/stabilization_guide.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 60d333a37..850168705 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -132,7 +132,8 @@ writing, the next stable release (i.e. what is currently beta) was Next search for the feature string (in this case, `pub_restricted`) in the codebase to find where it appears. Change uses of -`#![feature(XXX)]` from the `std` and any rustc crates to be +`#![feature(XXX)]` from the `std` and any rustc crates (this includes test folders +under `library/` and `compiler/` but not the toplevel `test/` one) to be `#![cfg_attr(bootstrap, feature(XXX))]`. This includes the feature-gate only for stage0, which is built using the current beta (this is needed because the feature is still unstable in the current beta). From d1822b999879e8c31818a063de737f8d059059bd Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 11 Feb 2022 05:34:23 +0900 Subject: [PATCH 1618/1812] Triage some date references (#1293) --- src/crates-io.md | 4 ++-- src/diagnostics/diagnostic-items.md | 2 +- src/diagnostics/lintstore.md | 10 +++++----- src/git.md | 4 ++-- src/tests/compiletest.md | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/crates-io.md b/src/crates-io.md index 62143defa..896f2697c 100644 --- a/src/crates-io.md +++ b/src/crates-io.md @@ -12,8 +12,8 @@ reasons: - The dependency may have transitive dependencies that have one of the above problems. -As of July 2021, there is no official policy for vetting -new dependencies to the compiler. Generally, new dependencies are not added +As of February 2022, there is no official policy for vetting +new dependencies to the compiler. Generally, new dependencies are not added to the compiler unless there is a good reason to do so. ## Permitted dependencies diff --git a/src/diagnostics/diagnostic-items.md b/src/diagnostics/diagnostic-items.md index b5cba717f..61e3c3aec 100644 --- a/src/diagnostics/diagnostic-items.md +++ b/src/diagnostics/diagnostic-items.md @@ -44,7 +44,7 @@ A new diagnostic item can be added with these two steps: For the naming conventions of diagnostic items, please refer to [*Naming Conventions*](#naming-conventions). -2. As of August 2021 diagnostic items in code are accessed via symbols in +2. As of February 2022, diagnostic items in code are accessed via symbols in [`rustc_span::symbol::sym`]. To add your newly created diagnostic item simply open the module file and add the name (In this case `Cat`) at the correct point in the list. diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index b544d2b6d..489771dac 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -17,7 +17,7 @@ First, we have the lint declarations themselves: this is where the name and defa other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which boils down to a static with type `&rustc_session::lint::Lint`. -As of July 2021, we lint against direct declarations +As of February 2022, we lint against direct declarations without the use of the macro today (although this may change in the future, as the macro is somewhat unwieldy to add new fields to, like all macros). @@ -56,11 +56,11 @@ internally. #### Internal lints -These are lints used just by the compiler or plugins like `clippy`. They can be found in +These are lints used just by the compiler or plugins like `clippy`. They can be found in `rustc_lint::internal`. -An example of such a lint is the check that lint passes are implemented using the -`declare_lint_pass!` macro and not by hand. This is accomplished with the +An example of such a lint is the check that lint passes are implemented using the +`declare_lint_pass!` macro and not by hand. This is accomplished with the `LINT_PASS_IMPL_WITHOUT_MACRO` lint. Registration of these lints happens in the [`rustc_lint::register_internals`] function which is @@ -81,7 +81,7 @@ with internal lints, this happens inside of [`rustc_lint::new_lint_store`]. This is one of the primary use cases remaining for plugins/drivers. Plugins are given access to the mutable `LintStore` during registration (which happens inside of [`rustc_interface::register_plugins`]) and they can call any functions they need on -the `LintStore`, just like rustc code. +the `LintStore`, just like rustc code. Plugins are intended to declare lints with the `plugin` field set to true (e.g., by way of the [`declare_tool_lint!`] macro), but this is purely for diagnostics and help text; diff --git a/src/git.md b/src/git.md index 6af774ca8..d5c37f82d 100644 --- a/src/git.md +++ b/src/git.md @@ -157,8 +157,8 @@ no changes added to commit (use "git add" and/or "git commit -a") These changes are not changes to files: they are changes to submodules (more on this [later](#git-submodules)). To get rid of those, run `git submodule update` (or run any `x.py` command, which will automatically update the submodules). -Note that there is (as of July 2021) a [bug][#77620] if you use -worktrees, submodules, and `x.py` in a commit hook. If you run into an error +Note that there is (as of February 2022) a [bug][#77620] if you use +worktrees, submodules, and `x.py` in a commit hook. If you run into an error like: ``` diff --git a/src/tests/compiletest.md b/src/tests/compiletest.md index b54bdfcfd..503b95f19 100644 --- a/src/tests/compiletest.md +++ b/src/tests/compiletest.md @@ -451,8 +451,8 @@ fn main() { ## Revisions -Certain classes of tests support "revisions" (as of February 2021, -this includes compile-fail, run-fail, and incremental, though +Certain classes of tests support "revisions" (as of February 2022, +this includes UI, assembly, codegen, incremental, and rustdoc UI tests, though incremental tests are somewhat different). Revisions allow a single test file to be used for multiple tests. This is done by adding a special header at the top of the file: From 62f58394ba7b203f55ac35ddcc4c0b79578f5706 Mon Sep 17 00:00:00 2001 From: Raoul Strackx <56830709+raoulstrackx@users.noreply.github.com> Date: Fri, 11 Feb 2022 14:42:50 +0100 Subject: [PATCH 1619/1812] Correction, building stage3 compiler (#1298) --- src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 93ebb487e..3fd4ef191 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -241,7 +241,7 @@ in other sections: - Building things: - `./x.py build` – builds everything using the stage 1 compiler, not just up to `std` - - `./x.py build --stage 2` – builds the stage2 compiler, along with `std` and + - `./x.py build --stage 2` – builds everything with the stage 2 compiler including `rustdoc` (which doesn't take too long) - Running tests (see the [section on running tests](../tests/running.html) for more details): From 5e38eb64bf18b37be93077a2020105b710f5cd71 Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Thu, 17 Feb 2022 14:46:20 -0600 Subject: [PATCH 1620/1812] Link to The Rust Performance Book (#1300) --- src/getting-started.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/getting-started.md b/src/getting-started.md index a5e67456e..b4dc11a68 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -299,7 +299,11 @@ benchmarks on a compiler with your changes. The numbers are reported [here][perf], and you can see a comparison of your changes against the latest master. +For an introduction to the performance of Rust code in general +which would also be useful in rustc development, see [The Rust Performance Book]. + [perf]: https://perf.rust-lang.org +[The Rust Performance Book]: https://nnethercote.github.io/perf-book/ ## Other Resources From cb3fb942e3c357ef2f901a1963efde8a4e54776c Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Thu, 17 Feb 2022 15:12:43 -0600 Subject: [PATCH 1621/1812] Edit "Queries" chapter (#1301) Makes various edits for clarity, style, readability, and formatting. Co-authored-by: Noah Lev --- src/query.md | 85 +++++++++++++++++++++++++++------------------------- 1 file changed, 45 insertions(+), 40 deletions(-) diff --git a/src/query.md b/src/query.md index 719568791..9c8cbd9b9 100644 --- a/src/query.md +++ b/src/query.md @@ -1,30 +1,34 @@ # Queries: demand-driven compilation + + As described in [the high-level overview of the compiler][hl], the Rust compiler is still (as of July 2021) transitioning from a -traditional "pass-based" setup to a "demand-driven" system. **The Compiler Query -System is the key to our new demand-driven organization.** The idea is pretty -simple. You have various queries that compute things about the input – for -example, there is a query called `type_of(def_id)` that, given the [def-id] of +traditional "pass-based" setup to a "demand-driven" system. The compiler query +system is the key to rustc's demand-driven organization. +The idea is pretty simple. Instead of entirely independent passes +(parsing, type-checking, etc.), a set of function-like *queries* +compute information about the input source. For example, +there is a query called `type_of` that, given the [`DefId`] of some item, will compute the type of that item and return it to you. -[def-id]: appendix/glossary.md#def-id +[`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/def_id/struct.DefId.html [hl]: ./compiler-src.md -Query execution is **memoized** – so the first time you invoke a +Query execution is *memoized*. The first time you invoke a query, it will go do the computation, but the next time, the result is returned from a hashtable. Moreover, query execution fits nicely into -**incremental computation**; the idea is roughly that, when you do a -query, the result **may** be returned to you by loading stored data -from disk (but that's a separate topic we won't discuss further here). +*incremental computation*; the idea is roughly that, when you invoke a +query, the result *may* be returned to you by loading stored data +from disk.[^incr-comp-detail] -The overall vision is that, eventually, the entire compiler -control-flow will be query driven. There will effectively be one -top-level query ("compile") that will run compilation on a crate; this +Eventually, we want the entire compiler +control-flow to be query driven. There will effectively be one +top-level query (`compile`) that will run compilation on a crate; this will in turn demand information about that crate, starting from the *end*. For example: -- This "compile" query might demand to get a list of codegen-units +- The `compile` query might demand to get a list of codegen-units (i.e. modules that need to be compiled by LLVM). - But computing the list of codegen-units would invoke some subquery that returns the list of all modules defined in the Rust source. @@ -32,27 +36,25 @@ will in turn demand information about that crate, starting from the - This keeps going further and further back until we wind up doing the actual parsing. -However, that vision is not fully realized. Still, big chunks of the -compiler (for example, generating MIR) work exactly like this. - -### Incremental Compilation in Detail +Although this vision is not fully realized, large sections of the +compiler (for example, generating [MIR](./mir/)) currently work exactly like this. -The [Incremental Compilation in Detail][query-model] chapter gives a more +[^incr-comp-detail]: The ["Incremental Compilation in Detail](queries/incremental-compilation-in-detail.md) chapter gives a more in-depth description of what queries are and how they work. If you intend to write a query of your own, this is a good read. -[query-model]: queries/incremental-compilation-in-detail.md - ### Invoking queries -To invoke a query is simple. The tcx ("type context") offers a method -for each defined query. So, for example, to invoke the `type_of` +Invoking a query is simple. The [`TyCtxt`] ("type context") struct offers a method +for each defined query. For example, to invoke the `type_of` query, you would just do this: ```rust,ignore let ty = tcx.type_of(some_def_id); ``` +[`TyTcx`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html + ### How the compiler executes a query So you may be wondering what happens when you invoke a query @@ -162,13 +164,13 @@ they define both a `provide` and a `provide_extern` function, through [rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html [wasm_import_module_map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/back/symbol_export/fn.wasm_import_module_map.html -### Adding a new kind of query +### Adding a new query -So suppose you want to add a new kind of query, how do you do so? -Well, defining a query takes place in two steps: +How do you add a new query? +Defining a query takes place in two steps: -1. first, you have to specify the query name and arguments; and then, -2. you have to supply query providers where needed. +1. Specify the query name and its arguments. +2. Supply query providers where needed. To specify the query name and arguments, you simply add an entry to the big macro invocation in @@ -190,21 +192,22 @@ rustc_queries! { ``` Queries are grouped into categories (`Other`, `Codegen`, `TypeChecking`, etc.). -Each group contains one or more queries. Each query definition is broken up like -this: +Each group contains one or more queries. + +A query definition has the following form: ```rust,ignore query type_of(key: DefId) -> Ty<'tcx> { ... } -^^ ^^^^^^^ ^^^^^ ^^^^^^^^ ^^^ +^^^^^ ^^^^^^^ ^^^^^ ^^^^^^^^ ^^^ | | | | | | | | | query modifiers -| | | result type of query +| | | result type | | query key type | name of query query keyword ``` -Let's go over them one by one: +Let's go over these elements one by one: - **Query keyword:** indicates a start of a query definition. - **Name of query:** the name of the query method @@ -217,11 +220,7 @@ Let's go over them one by one: - **Result type of query:** the type produced by this query. This type should (a) not use `RefCell` or other interior mutability and (b) be cheaply cloneable. Interning or using `Rc` or `Arc` is recommended for - non-trivial data types. - - The one exception to those rules is the `ty::steal::Steal` type, - which is used to cheaply modify MIR in place. See the definition - of `Steal` for more details. New uses of `Steal` should **not** be - added without alerting `@rust-lang/compiler`. + non-trivial data types.[^steal] - **Query modifiers:** various flags and options that customize how the query is processed (mostly with respect to [incremental compilation][incrcomp]). @@ -234,11 +233,16 @@ So, to add a query: - Link the provider by modifying the appropriate `provide` method; or add a new one if needed and ensure that `rustc_driver` is invoking it. +[^steal]: The one exception to those rules is the `ty::steal::Steal` type, +which is used to cheaply modify MIR in place. See the definition +of `Steal` for more details. New uses of `Steal` should **not** be +added without alerting `@rust-lang/compiler`. + #### Query structs and descriptions -For each kind, the `rustc_queries` macro will generate a "query struct" -named after the query. This struct is a kind of a place-holder -describing the query. Each such struct implements the +For each query, the `rustc_queries` macro will generate a "query struct" +named after the query. This struct is a kind of placeholder +describing the query. Each query struct implements the [`self::config::QueryConfig`][QueryConfig] trait, which has associated types for the key/value of that particular query. Basically the code generated looks something like this: @@ -308,3 +312,4 @@ More discussion and issues: [GitHub issue #42633]: https://github.com/rust-lang/rust/issues/42633 [Incremental Compilation Beta]: https://internals.rust-lang.org/t/incremental-compilation-beta/4721 [Incremental Compilation Announcement]: https://blog.rust-lang.org/2016/09/08/incremental.html + From 2c9be18076432d9faaf8334146201b1117eb0b8d Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Thu, 17 Feb 2022 15:18:10 -0600 Subject: [PATCH 1622/1812] Fix link --- src/query.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/query.md b/src/query.md index 9c8cbd9b9..ff2796a2d 100644 --- a/src/query.md +++ b/src/query.md @@ -53,7 +53,7 @@ query, you would just do this: let ty = tcx.type_of(some_def_id); ``` -[`TyTcx`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html +[`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html ### How the compiler executes a query From 1fa751d36e3a8da6f91a1b6e70d088698f7e99b5 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Thu, 17 Feb 2022 13:48:36 -0800 Subject: [PATCH 1623/1812] Fix heading levels in the query chapter (#1305) This should fix the incorrect TOC rendering in #1303. --- src/query.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/query.md b/src/query.md index ff2796a2d..6e02bfc7b 100644 --- a/src/query.md +++ b/src/query.md @@ -43,7 +43,7 @@ compiler (for example, generating [MIR](./mir/)) currently work exactly like thi in-depth description of what queries are and how they work. If you intend to write a query of your own, this is a good read. -### Invoking queries +## Invoking queries Invoking a query is simple. The [`TyCtxt`] ("type context") struct offers a method for each defined query. For example, to invoke the `type_of` @@ -55,7 +55,7 @@ let ty = tcx.type_of(some_def_id); [`TyCtxt`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html -### How the compiler executes a query +## How the compiler executes a query So you may be wondering what happens when you invoke a query method. The answer is that, for each query, the compiler maintains a @@ -64,7 +64,7 @@ simple: we clone the return value out of the cache and return it (therefore, you should try to ensure that the return types of queries are cheaply cloneable; insert an `Rc` if necessary). -#### Providers +### Providers If, however, the query is *not* in the cache, then the compiler will try to find a suitable **provider**. A provider is a function that has @@ -97,7 +97,7 @@ fn provider<'tcx>( Providers take two arguments: the `tcx` and the query key. They return the result of the query. -#### How providers are setup +### How providers are setup When the tcx is created, it is given the providers by its creator using the [`Providers`][providers_struct] struct. This struct is generated by @@ -164,7 +164,7 @@ they define both a `provide` and a `provide_extern` function, through [rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html [wasm_import_module_map]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/back/symbol_export/fn.wasm_import_module_map.html -### Adding a new query +## Adding a new query How do you add a new query? Defining a query takes place in two steps: @@ -238,7 +238,7 @@ which is used to cheaply modify MIR in place. See the definition of `Steal` for more details. New uses of `Steal` should **not** be added without alerting `@rust-lang/compiler`. -#### Query structs and descriptions +### Query structs and descriptions For each query, the `rustc_queries` macro will generate a "query struct" named after the query. This struct is a kind of placeholder @@ -294,7 +294,7 @@ rustc_queries! { `rustc_queries` macro will generate an appropriate `impl` automatically. -## External Links +## External links Related design ideas, and tracking issues: From 68c76494094f564b10e1ad1585ba1d1824340ea8 Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Thu, 17 Feb 2022 16:09:04 -0600 Subject: [PATCH 1624/1812] Edit glossary (#1302) Add back-ticks to a few terms that appear in code. Clarify that `tcx` is a standard. --- src/appendix/glossary.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/appendix/glossary.md b/src/appendix/glossary.md index 4eba27fce..375db493c 100644 --- a/src/appendix/glossary.md +++ b/src/appendix/glossary.md @@ -18,7 +18,7 @@ Term | Meaning DAG   | A directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.md)) data-flow analysis   | A static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.md#dataflow). DeBruijn Index   | A technique for describing which binder a variable is bound by using only integers. It has the benefit that it is invariant under variable renaming. ([see more](./background.md#what-is-a-debruijn-index)) -DefId   | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). +`DefId`   | An index identifying a definition (see `rustc_middle/src/hir/def_id.rs`). Uniquely identifies a `DefPath`. See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). discriminant   | The underlying value associated with an enum variant or generator state to indicate it as "active" (but not to be confused with its ["variant index"](#variant-idx)). At runtime, the discriminant of the active variant is encoded in the [tag](#tag). double pointer   | A pointer with additional metadata. See "fat pointer" for more. drop glue   | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types. @@ -29,7 +29,7 @@ Term | Meaning free variable   | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.md#free-vs-bound) generics   | The set of generic type parameters defined on a type or item. HIR   | The High-level IR, created by lowering and desugaring the AST. ([see more](../hir.md)) -HirId   | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). +`HirId`   | Identifies a particular node in the HIR by combining a def-id with an "intra-definition offset". See [the HIR chapter for more](../hir.md#identifiers-in-the-hir). HIR map   | The HIR map, accessible via `tcx.hir()`, allows you to quickly navigate the HIR and convert between various forms of identifiers. ICE   | Short for internal compiler error, this is when the compiler crashes. ICH   | Short for incremental compilation hash, these are used as fingerprints for things such as HIR and crate metadata, to check if changes have been made. This is useful in incremental compilation to see if part of a crate has changed and should be recompiled. @@ -75,14 +75,14 @@ Term | Meaning substs   | The substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap`). sysroot   | The directory for build artifacts that are loaded by the compiler at runtime. ([see more](../building/bootstrapping.html#what-is-a-sysroot)) tag   | The "tag" of an enum/generator encodes the [discriminant](#discriminant) of the active variant/state. Tags can either be "direct" (simply storing the discriminant in a field) or use a ["niche"](#niche). -tcx   | The "typing context" (`TyCtxt`), main data structure of the compiler. ([see more](../ty.md)) +`tcx`   | Standard variable name for the "typing context" (`TyCtxt`), main data structure of the compiler. ([see more](../ty.md)) `'tcx`   | The lifetime of the allocation arenas used by `TyCtxt`. Most data interned during a compilation session will use this lifetime with the exception of HIR data which uses the `'hir` lifetime. ([see more](../ty.md)) token   | The smallest unit of parsing. Tokens are produced after lexing ([see more](../the-parser.md)). [TLS]   | Thread-Local Storage. Variables may be defined so that each thread has its own copy (rather than all threads sharing the variable). This has some interactions with LLVM. Not all platforms support TLS. trait reference   | The name of a trait along with a suitable set of input type/lifetimes. ([see more](../traits/goals-and-clauses.md#trait-ref)) trans   | Short for "translation", the code to translate MIR into LLVM IR. Renamed to codegen. `Ty`   | The internal representation of a type. ([see more](../ty.md)) -TyCtxt   | The data structure often referred to as [tcx](#tcx) in code which provides access to session data and the query system. +`TyCtxt`   | The data structure often referred to as [`tcx`](#tcx) in code which provides access to session data and the query system. UFCS   | Short for Universal Function Call Syntax, this is an unambiguous syntax for calling a method. ([see more](../type-checking.md)) uninhabited type   | A type which has _no_ values. This is not the same as a ZST, which has exactly 1 value. An example of an uninhabited type is `enum Foo {}`, which has no variants, and so, can never be created. The compiler can treat code that deals with uninhabited types as dead code, since there is no such value to be manipulated. `!` (the never type) is an uninhabited type. Uninhabited types are also called "empty types". upvar   | A variable captured by a closure from outside the closure. From 5483b27923c8acee6536498bb425bb7702740bd4 Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Sun, 20 Feb 2022 14:14:58 -0600 Subject: [PATCH 1625/1812] Fix `Ty` link (#1308) --- src/appendix/code-index.md | 2 +- src/overview.md | 2 +- src/ty.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/appendix/code-index.md b/src/appendix/code-index.md index 68d12be37..f645c0118 100644 --- a/src/appendix/code-index.md +++ b/src/appendix/code-index.md @@ -28,7 +28,7 @@ Item | Kind | Short description | Chapter | `rustc_ast::token_stream::TokenStream` | struct | An abstract sequence of tokens, organized into `TokenTree`s | [The parser], [Macro expansion] | [compiler/rustc_ast/src/tokenstream.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/tokenstream/struct.TokenStream.html) `TraitDef` | struct | This struct contains a trait's definition with type information | [The `ty` modules] | [compiler/rustc_middle/src/ty/trait_def.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/trait_def/struct.TraitDef.html) `TraitRef` | struct | The combination of a trait and its input types (e.g. `P0: Trait`) | [Trait Solving: Goals and Clauses] | [compiler/rustc_middle/src/ty/sty.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TraitRef.html) -`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [compiler/rustc_middle/src/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html) +`Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [compiler/rustc_middle/src/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Ty.html) `TyCtxt<'tcx>` | struct | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [compiler/rustc_middle/src/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html) [The HIR]: ../hir.html diff --git a/src/overview.md b/src/overview.md index 02e56ca03..c77fd6cf6 100644 --- a/src/overview.md +++ b/src/overview.md @@ -289,7 +289,7 @@ on [`ty::Ty`][ty], but for now, we just want to mention that it exists and is th Also note that the `rustc_middle::ty` module defines the `TyCtxt` struct we mentioned before. -[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html +[ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Ty.html ### Parallelism diff --git a/src/ty.md b/src/ty.md index 95141b6f2..5749cdcd3 100644 --- a/src/ty.md +++ b/src/ty.md @@ -16,7 +16,7 @@ The specific `Ty` we are referring to is [`rustc_middle::ty::Ty`][ty_ty] (and no [`rustc_hir::Ty`][hir_ty]). The distinction is important, so we will discuss it first before going into the details of `ty::Ty`. -[ty_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.Ty.html +[ty_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Ty.html [hir_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.Ty.html ## `rustc_hir::Ty` vs `ty::Ty` From eefbde504ffeef42ea174ba90d0cdc68082bffea Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sun, 20 Feb 2022 07:00:41 -0800 Subject: [PATCH 1626/1812] symbol-mangling-version has been stabilized --- src/llvm-coverage-instrumentation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index cb3be57ac..3337f6ad8 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -38,7 +38,7 @@ _compiler-flags/instrument-coverage_)][unstable-book-instrument-coverage]. ## Rust symbol mangling `-Z instrument-coverage` automatically enables Rust symbol mangling `v0` (as -if the user specified `-Z symbol-mangling-version=v0` option when invoking +if the user specified `-C symbol-mangling-version=v0` option when invoking `rustc`) to ensure consistent and reversible name mangling. This has two important benefits: From d335c9c2bb651abee7fa310f8017f6d07e15d0f9 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sun, 20 Feb 2022 07:09:56 -0800 Subject: [PATCH 1627/1812] instrument-coverage has been stabilized. --- src/llvm-coverage-instrumentation.md | 17 ++++++++--------- src/profile-guided-optimization.md | 2 +- 2 files changed, 9 insertions(+), 10 deletions(-) diff --git a/src/llvm-coverage-instrumentation.md b/src/llvm-coverage-instrumentation.md index 3337f6ad8..ea4bdfca6 100644 --- a/src/llvm-coverage-instrumentation.md +++ b/src/llvm-coverage-instrumentation.md @@ -3,7 +3,7 @@ `rustc` supports detailed source-based code and test coverage analysis -with a command line option (`-Z instrument-coverage`) that instruments Rust +with a command line option (`-C instrument-coverage`) that instruments Rust libraries and binaries with additional instructions and data, at compile time. The coverage instrumentation injects calls to the LLVM intrinsic instruction @@ -28,16 +28,15 @@ them), and generate various reports for analysis, for example:
    Detailed instructions and examples are documented in the -[Rust Unstable Book (under -_compiler-flags/instrument-coverage_)][unstable-book-instrument-coverage]. +[Rustc Book][rustc-book-instrument-coverage]. [llvm-instrprof-increment]: https://llvm.org/docs/LangRef.html#llvm-instrprof-increment-intrinsic [coverage map]: https://llvm.org/docs/CoverageMappingFormat.html -[unstable-book-instrument-coverage]: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/instrument-coverage.html +[rustc-book-instrument-coverage]: https://doc.rust-lang.org/nightly/rustc/instrument-coverage.html ## Rust symbol mangling -`-Z instrument-coverage` automatically enables Rust symbol mangling `v0` (as +`-C instrument-coverage` automatically enables Rust symbol mangling `v0` (as if the user specified `-C symbol-mangling-version=v0` option when invoking `rustc`) to ensure consistent and reversible name mangling. This has two important benefits: @@ -62,7 +61,7 @@ In the `rustc` source tree, `library/profiler_builtins` bundles the LLVM `profiler_builtins` library is only included when `profiler = true` is set in `rustc`'s `config.toml`.) -When compiling with `-Z instrument-coverage`, +When compiling with `-C instrument-coverage`, [`CrateLoader::postprocess()`][crate-loader-postprocess] dynamically loads the `profiler_builtins` library by calling `inject_profiler_runtime()`. @@ -287,7 +286,7 @@ instrumented) in the [`coverage`][coverage-test-samples] directory, and the actual tests and expected results in [`coverage-reports`]. Finally, the [`coverage-llvmir`] test compares compiles a simple Rust program -with `-Z instrument-coverage` and compares the compiled program's LLVM IR to +with `-C instrument-coverage` and compares the compiled program's LLVM IR to expected LLVM IR instructions and structured data for a coverage-enabled program, including various checks for Coverage Map-related metadata and the LLVM intrinsic calls to increment the runtime counters. @@ -424,7 +423,7 @@ theme in your development environment, you will probably want to use this option so you can review the graphviz output without straining your vision. ```shell -$ rustc -Z instrument-coverage -Z dump-mir=InstrumentCoverage \ +$ rustc -C instrument-coverage -Z dump-mir=InstrumentCoverage \ -Z dump-mir-graphviz some_rust_source.rs ``` @@ -497,7 +496,7 @@ An visual, interactive representation of the final `CoverageSpan`s can be generated with the following `rustc` flags: ```shell -$ rustc -Z instrument-coverage -Z dump-mir=InstrumentCoverage \ +$ rustc -C instrument-coverage -Z dump-mir=InstrumentCoverage \ -Z dump-mir-spanview some_rust_source.rs ``` diff --git a/src/profile-guided-optimization.md b/src/profile-guided-optimization.md index bf7615878..db2624e92 100644 --- a/src/profile-guided-optimization.md +++ b/src/profile-guided-optimization.md @@ -49,7 +49,7 @@ workflow to see how they interact. [^note-instrument-coverage]: Note: `rustc` now supports front-end-based coverage instrumentation, via the experimental option -[`-Z instrument-coverage`](./llvm-coverage-instrumentation.md), but using these +[`-C instrument-coverage`](./llvm-coverage-instrumentation.md), but using these coverage results for PGO has not been attempted at this time. ### Overall Workflow From e798dc49d7a487c6c2986cd5feeda0a1af499146 Mon Sep 17 00:00:00 2001 From: Samuel Moelius <35515885+smoelius@users.noreply.github.com> Date: Tue, 22 Feb 2022 19:22:28 -0500 Subject: [PATCH 1628/1812] Typo (#1313) --- src/mir/dataflow.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index 0e626d97c..6fe8d6aa5 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -80,8 +80,8 @@ possible effects for each statement and terminator, the "before" effect and the unprefixed (or "primary") effect. The "before" effects are applied immediately before the unprefixed effect **regardless of the direction of the analysis**. In other words, a backward analysis will apply the "before" effect and then the -the "primary" effect when computing the transfer function for a basic block, -just like a forward analysis. +"primary" effect when computing the transfer function for a basic block, just +like a forward analysis. The vast majority of analyses should use only the unprefixed effects: Having multiple effects for each statement makes it difficult for consumers to know From 9e2cdee5b3ed319636d4d3c679f9ffc5f87718cb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?T=C3=A9o=20Bouvard?= Date: Thu, 24 Feb 2022 20:27:21 +0100 Subject: [PATCH 1629/1812] Fix typo (#1315) --- src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 48f501a02..b6ba3000e 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -218,7 +218,7 @@ Stage N `std` is pretty much necessary for any useful work with the stage N comp Without it, you can only compile programs with `#![no_core]` -- not terribly useful! The reason these need to be different is because they aren't necessarily ABI-compatible: -there could be a new layout optimizations, changes to MIR, or other changes +there could be new layout optimizations, changes to MIR, or other changes to Rust metadata on nightly that aren't present in beta. This is also where `--keep-stage 1 library/std` comes into play. Since most From 24e474c276b0fc1ce3a6addb85dc74725ccd389d Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Thu, 24 Feb 2022 20:40:58 -0800 Subject: [PATCH 1630/1812] Add known-bug header. (#1311) --- src/tests/headers.md | 2 ++ src/tests/ui.md | 15 +++++++++++++++ 2 files changed, 17 insertions(+) diff --git a/src/tests/headers.md b/src/tests/headers.md index adc5fa6c9..bdbe0a14e 100644 --- a/src/tests/headers.md +++ b/src/tests/headers.md @@ -87,6 +87,8 @@ found in [`header.rs`] from the compiletest source. * [`revisions`](compiletest.md#revisions) — compile multiple times * [`forbid-output`](compiletest.md#incremental-tests) — incremental cfail rejects output pattern * [`should-ice`](compiletest.md#incremental-tests) — incremental cfail should ICE + * [`known-bug`](ui.md#known-bugs) — indicates that the test is + for a known bug that has not yet been fixed * [Assembly](compiletest.md#assembly-tests) headers * `assembly-output` — the type of assembly output to check diff --git a/src/tests/ui.md b/src/tests/ui.md index a8e8d3b72..c1c105141 100644 --- a/src/tests/ui.md +++ b/src/tests/ui.md @@ -394,6 +394,21 @@ The `ignore-pass` header can be used to ignore the `--pass` CLI flag if the test won't work properly with that override. +## Known bugs + +The `known-bug` header may be used for tests that demonstrate a known bug that +has not yet been fixed. +Adding tests for known bugs is helpful for several reasons, including: + +1. Maintaining a functional test that can be conveniently reused when the bug is fixed. +2. Providing a sentinel that will fail if the bug is incidentally fixed. + This can alert the developer so they know that the associated issue has + been fixed and can possibly be closed. + +Do not include [error annotations](#error-annotations) in a test with `known-bug`. +The test should still include other normal headers and stdout/stderr files. + + ## Test organization When deciding where to place a test file, please try to find a subdirectory From 7d8eb8760448b713dfc453a4d29a4de41f64f18f Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Sun, 27 Feb 2022 20:26:00 -0800 Subject: [PATCH 1631/1812] cargo timings has been stabilized (#1319) Co-authored-by: pierwill <19642016+pierwill@users.noreply.github.com> --- src/profiling.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/profiling.md b/src/profiling.md index 0d333f7be..711248f19 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -17,9 +17,9 @@ Depending on what you're trying to measure, there are several different approach full-featured graphical interface. - If you want a nice visual representation of the compile times of your crate graph, - you can use [cargo's `-Z timings` flag](https://doc.rust-lang.org/cargo/reference/unstable.html#timings), - eg. `cargo -Z timings build`. - You can use this flag on the compiler itself with `CARGOFLAGS="-Z timings" ./x.py build` + you can use [cargo's `--timings` flag](https://doc.rust-lang.org/nightly/cargo/reference/timings.html), + e.g. `cargo build --timings`. + You can use this flag on the compiler itself with `CARGOFLAGS="--timings" ./x.py build` - If you want to profile memory usage, you can use various tools depending on what operating system you are using. From 32f2a5b4e7545318846185198542230170dd8a42 Mon Sep 17 00:00:00 2001 From: James Cole <44881720+jamescoleuk@users.noreply.github.com> Date: Tue, 1 Mar 2022 16:45:24 +0000 Subject: [PATCH 1632/1812] Add architecture suggestion for Apple silicon (#1320) --- src/building/how-to-build-and-run.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 3fd4ef191..dd997c814 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -211,7 +211,7 @@ rustup toolchain link stage2 build//stage2 The `` would typically be one of the following: - Linux: `x86_64-unknown-linux-gnu` -- Mac: `x86_64-apple-darwin` +- Mac: `x86_64-apple-darwin` or `aarch64-apple-darwin` - Windows: `x86_64-pc-windows-msvc` Now you can run the `rustc` you built with. If you run with `-vV`, you From eb90c9c25a523c305e30d5fdae75efa1ee110e72 Mon Sep 17 00:00:00 2001 From: Chayim Refael Friedman Date: Wed, 2 Mar 2022 04:27:13 +0200 Subject: [PATCH 1633/1812] Fix incorrectly escaped backtick --- src/diagnostics.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 20dbefd7b..3671a0ecc 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -459,8 +459,8 @@ The possible values of [`Applicability`][appl] are: - `MachineApplicable`: Can be applied mechanically. - `HasPlaceholders`: Cannot be applied mechanically because it has placeholder - text in the suggestions. For example: ``try adding a type: `let x: - ` ``. + text in the suggestions. For example: ```try adding a type: `let x: + ` ```. - `MaybeIncorrect`: Cannot be applied mechanically because the suggestion may or may not be a good one. - `Unspecified`: Cannot be applied mechanically because we don't know which From 4b8d9398890e7135e874a9bdd15895fcd57bbd72 Mon Sep 17 00:00:00 2001 From: Guillaume Gomez Date: Wed, 9 Mar 2022 14:36:37 +0100 Subject: [PATCH 1634/1812] Add missing rustdoc tests explanations --- src/tests/compiletest.md | 13 +++++++------ src/tests/intro.md | 2 ++ 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/src/tests/compiletest.md b/src/tests/compiletest.md index 503b95f19..7e147c9ce 100644 --- a/src/tests/compiletest.md +++ b/src/tests/compiletest.md @@ -52,14 +52,15 @@ The following test suites are available, with links for more information: - `run-make-fulldeps` — `run-make` tests which require a linkable build of `rustc`, or the rust demangler - [`run-pass-valgrind`](#valgrind-tests) — tests run with Valgrind -- Rustdoc tests: +- [Rustdoc tests](../rustdoc.md#tests): - `rustdoc` — tests for rustdoc, making sure that the generated files contain the expected documentation. - - `rustdoc-gui` — TODO - - `rustdoc-js` — TODO - - `rustdoc-js-std` — TODO - - `rustdoc-json` — TODO - - `rustdoc-ui` — TODO + - `rustdoc-gui` — tests for rustdoc's GUI using a web browser. + - `rustdoc-js` — tests to ensure the rustdoc search is working as expected. + - `rustdoc-js-std` — tests to ensure the rustdoc search is working as expected + (run specifically on the std docs). + - `rustdoc-json` — tests on the JSON output of rustdoc. + - `rustdoc-ui` — tests on the terminal output of rustdoc. [`src/test`]: https://github.com/rust-lang/rust/blob/master/src/test [`src/tools/compiletest/src/common.rs`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs diff --git a/src/tests/intro.md b/src/tests/intro.md index 65facccba..92f6cb664 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -101,6 +101,8 @@ Links across all documentation is validated with a link checker tool. > Example: `./x.py test src/tools/linkchecker` +> Example: `./x.py test linkchecker` + This requires building all of the documentation, which might take a while. ### Dist check From 0e4b961a9c708647bca231430ce1b199993e0196 Mon Sep 17 00:00:00 2001 From: skippy10110 Date: Sat, 12 Mar 2022 19:04:16 -0400 Subject: [PATCH 1635/1812] update winget install instructions to ensure proper packages are installed (-e for --exact, and full package names to ensure arbitrary packages from the msstore source aren't installed) fixes #1324 --- src/building/prerequisites.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/prerequisites.md b/src/building/prerequisites.md index cfe4c7738..a5ab23d91 100644 --- a/src/building/prerequisites.md +++ b/src/building/prerequisites.md @@ -31,8 +31,8 @@ on Windows. Run the following in a terminal: ```powershell -winget install python -winget install cmake +winget install -e Python.Python.3 +winget install -e Kitware.CMake ``` If any of those is installed already, winget will detect it. From 155126b1d2e2cb01ddb1d7ba9489b90d7cd173ad Mon Sep 17 00:00:00 2001 From: lcnr Date: Tue, 22 Mar 2022 14:34:21 +0100 Subject: [PATCH 1636/1812] update section for type system constants (#1329) * update section for type system constants * Update src/constants.md --- src/constants.md | 49 ++++++++++++++++++++++++++++-------------------- 1 file changed, 29 insertions(+), 20 deletions(-) diff --git a/src/constants.md b/src/constants.md index 30c0da736..0b3becec3 100644 --- a/src/constants.md +++ b/src/constants.md @@ -16,6 +16,33 @@ or a generic parameter, e.g. `[u8; N]`, converting a constant to its [`ty::Const returns an unevaluated constant. Even fully concrete constants which do not depend on generic parameters are not evaluated right away. +Anonymous constants are typechecked separately from their containing item, e.g. +```rust +fn foo() -> [u8; N + 1] { + [0; N + 1] +} +``` +is treated as +```rust +const ANON_CONST_1 = N + 1; +const ANON_CONST_2 = N + 1; +fn foo() -> [u8; ANON_CONST_1::] { + [0; ANON_CONST_2::] +} +``` + +### Unifying constants + +For the compiler, `ANON_CONST_1` and `ANON_CONST_2` are completely different, so +we have to somehow look into unevaluated constants to check whether they should +unify. + +For this we use [InferCtxt::try_unify_abstract_consts](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.try_unify_abstract_consts). +This builds a custom AST for the two inputs from their THIR. This is then used for +the actual comparison. + +### Lazy normalization for constants + We do not eagerly evaluate constant as they can be used in the `where`-clauses of their parent item, for example: @@ -32,7 +59,7 @@ its parents caller bounds, but is also part of another bound itself. If we were to eagerly evaluate this constant while computing its parents bounds this would cause a query cycle. -### Generic arguments of anonymous constants +### Unused generic arguments of anonymous constants Anonymous constants inherit the generic parameters of their parent, which is why the array length in `foo() -> [u8; N + 1]` can use `N`. @@ -41,25 +68,7 @@ Without any manual adjustments, this causes us to include parameters even if the constant doesn't use them in any way. This can cause [some interesting errors][pcg-unused-substs] and breaks some already stable code. -To deal with this, we intend to look at the generic parameters explicitly mentioned -by the constants and then search the predicates of its parents to figure out which -of the other generic parameters are reachable by our constant. - -**TODO**: Expand this section once the parameter filtering is implemented. - -As constants can be part of their parents `where`-clauses, we mention unevaluated -constants in their parents predicates. It is therefore necessary to mention unevaluated -constants before we have computed the generic parameters -available to these constants. - -To do this unevaluated constants start out with [`substs_`] being `None` while assuming -that their generic arguments could be arbitrary generic parameters. -When first accessing the generic arguments of an unevaluated constants, we then replace -`substs_` with the actual default arguments of a constants, which are the generic parameters -of their parent we assume to be used by this constant. - [`ty::Const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Const.html [`ty::ConstKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.ConstKind.html [`ty::TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html -[pcg-unused-substs]: https://github.com/rust-lang/project-const-generics/blob/master/design-docs/anon-const-substs.md#unused-substs -[`substs_`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/consts/kind/struct.Unevaluated.html#structfield.substs_ \ No newline at end of file +[pcg-unused-substs]: https://github.com/rust-lang/project-const-generics/blob/master/design-docs/anon-const-substs.md#unused-substs \ No newline at end of file From 127abaa937d1e27aaed28ba5f8be74ce4167b4d0 Mon Sep 17 00:00:00 2001 From: xFrednet Date: Fri, 1 Apr 2022 19:55:51 +0200 Subject: [PATCH 1637/1812] Add example how lints can be feature gated --- src/diagnostics.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/diagnostics.md b/src/diagnostics.md index 3671a0ecc..b67520428 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -594,6 +594,20 @@ declare_lint! { This makes the `ANONYMOUS_PARAMETERS` lint allow-by-default in the 2015 edition but warn-by-default in the 2018 edition. +### Feature-gated lints + +Lints belonging to a feature should only be usable if the feature is enabled in the +crate. To support this, lint declarations can contain a feature gate like so: + +```rust,ignore +declare_lint! { + pub SOME_LINT_NAME, + Warn, + "a new and useful, but feature gated lint", + @feature_gate = sym::feature_name; +} +``` + ### Future-incompatible lints The use of the term `future-incompatible` within the compiler has a slightly From f5f6b4f2be9c8169688bd38c5488ba477d3f2b8d Mon Sep 17 00:00:00 2001 From: Hongbo <12580159+ya0guang@users.noreply.github.com> Date: Tue, 5 Apr 2022 18:47:46 -0400 Subject: [PATCH 1638/1812] Update miri.md: correct a minor typo (#1334) --- src/miri.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/miri.md b/src/miri.md index dd54f6548..c5de358d2 100644 --- a/src/miri.md +++ b/src/miri.md @@ -88,7 +88,7 @@ evaluation. `_0` always refers to that location directly. After the evaluation is done, the return value is converted from [`Operand`] to [`ConstValue`] by [`op_to_const`]: the former representation is geared towards -what is needed *during* cost evaluation, while [`ConstValue`] is shaped by the +what is needed *during* const evaluation, while [`ConstValue`] is shaped by the needs of the remaining parts of the compiler that consume the results of const evaluation. As part of this conversion, for types with scalar values, even if the resulting [`Operand`] is `Indirect`, it will return an immediate From 664d3c70c0cc662ca91120ff0096713a912d0af1 Mon Sep 17 00:00:00 2001 From: Noah Lev Date: Sat, 9 Apr 2022 01:31:23 -0700 Subject: [PATCH 1639/1812] r-a: Use `python3 x.py` instead of `./x.py` (#1335) --- src/building/suggested.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 14e0410de..a6ff65db3 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -22,12 +22,13 @@ You can also install the hook as a step of running `./x.py setup`! a file. By default, `rust-analyzer` runs the `cargo check` and `rustfmt` commands, but you can override these commands to use more adapted versions of these tools when hacking on `rustc`. For example, for Visual Studio Code, -you can write: +you can write: ```JSON { "rust-analyzer.checkOnSave.overrideCommand": [ - "./x.py", + "python3", + "x.py", "check", "--json-output" ], From fbda644df8aab03ecfa102cb7416c215df1edf3a Mon Sep 17 00:00:00 2001 From: Ujjawal Date: Mon, 11 Apr 2022 19:18:30 +0530 Subject: [PATCH 1640/1812] Update examples with 1.61.0-nightly (latest version) (#1330) Co-authored-by: Ujjawal Kumar --- examples/rustc-driver-example.rs | 7 +++---- examples/rustc-driver-getting-diagnostics.rs | 6 +++--- examples/rustc-driver-interacting-with-the-ast.rs | 6 +++--- 3 files changed, 9 insertions(+), 10 deletions(-) diff --git a/examples/rustc-driver-example.rs b/examples/rustc-driver-example.rs index 29fa24784..7177a2868 100644 --- a/examples/rustc-driver-example.rs +++ b/examples/rustc-driver-example.rs @@ -3,7 +3,7 @@ // NOTE: For the example to compile, you will need to first run the following: // rustup component add rustc-dev -// version: 1.53.0-nightly (9b0edb7fd 2021-03-27) +// version: 1.61.0-nightly (68369a041 2022-02-22) extern crate rustc_error_codes; extern crate rustc_errors; @@ -15,7 +15,7 @@ extern crate rustc_span; use rustc_errors::registry; use rustc_hash::{FxHashMap, FxHashSet}; -use rustc_session::config; +use rustc_session::config::{self, CheckCfg}; use rustc_span::source_map; use std::path; use std::process; @@ -36,6 +36,7 @@ fn main() { }, // cfg! configuration in addition to the default ones crate_cfg: FxHashSet::default(), // FxHashSet<(String, Option)> + crate_check_cfg: CheckCfg::default(), // CheckCfg input: config::Input::Str { name: source_map::FileName::Custom("main.rs".to_string()), input: "static HELLO: &str = \"Hello, world!\"; fn main() { println!(\"{}\", HELLO); }" @@ -46,8 +47,6 @@ fn main() { output_file: None, // Option file_loader: None, // Option> diagnostic_output: rustc_session::DiagnosticOutput::Default, - // Set to capture stderr output during compiler execution - stderr: None, // Option>>> lint_caps: FxHashMap::default(), // FxHashMap // This is a callback from the driver that is called when [`ParseSess`] is created. parse_sess_created: None, //Option> diff --git a/examples/rustc-driver-getting-diagnostics.rs b/examples/rustc-driver-getting-diagnostics.rs index d1b42658e..c25695dd0 100644 --- a/examples/rustc-driver-getting-diagnostics.rs +++ b/examples/rustc-driver-getting-diagnostics.rs @@ -3,7 +3,7 @@ // NOTE: For the example to compile, you will need to first run the following: // rustup component add rustc-dev -// version: 1.53.0-nightly (9b0edb7fd 2021-03-27) +// version: 1.61.0-nightly (68369a041 2022-02-22) extern crate rustc_error_codes; extern crate rustc_errors; @@ -14,7 +14,7 @@ extern crate rustc_session; extern crate rustc_span; use rustc_errors::registry; -use rustc_session::config; +use rustc_session::config::{self, CheckCfg}; use rustc_span::source_map; use std::io; use std::path; @@ -65,11 +65,11 @@ fn main() { buffer.clone(), ))), crate_cfg: rustc_hash::FxHashSet::default(), + crate_check_cfg: CheckCfg::default(), input_path: None, output_dir: None, output_file: None, file_loader: None, - stderr: None, lint_caps: rustc_hash::FxHashMap::default(), parse_sess_created: None, register_lints: None, diff --git a/examples/rustc-driver-interacting-with-the-ast.rs b/examples/rustc-driver-interacting-with-the-ast.rs index cbf48c9ce..c942ac324 100644 --- a/examples/rustc-driver-interacting-with-the-ast.rs +++ b/examples/rustc-driver-interacting-with-the-ast.rs @@ -3,7 +3,7 @@ // NOTE: For the example to compile, you will need to first run the following: // rustup component add rustc-dev llvm-tools-preview -// version: 1.53.0-nightly (9b0edb7fd 2021-03-27) +// version: 1.61.0-nightly (68369a041 2022-02-22) extern crate rustc_ast_pretty; extern crate rustc_error_codes; @@ -16,7 +16,7 @@ extern crate rustc_span; use rustc_ast_pretty::pprust::item_to_string; use rustc_errors::registry; -use rustc_session::config; +use rustc_session::config::{self, CheckCfg}; use rustc_span::source_map; use std::path; use std::process; @@ -41,11 +41,11 @@ fn main() { }, diagnostic_output: rustc_session::DiagnosticOutput::Default, crate_cfg: rustc_hash::FxHashSet::default(), + crate_check_cfg: CheckCfg::default(), input_path: None, output_dir: None, output_file: None, file_loader: None, - stderr: None, lint_caps: rustc_hash::FxHashMap::default(), parse_sess_created: None, register_lints: None, From 885d32992889ed70e44626a6e92895aae395d5a6 Mon Sep 17 00:00:00 2001 From: Ivor Wanders Date: Mon, 11 Apr 2022 09:51:22 -0400 Subject: [PATCH 1641/1812] Consolidate crates.io convention section (#1326) --- src/conventions.md | 6 ++---- src/crates-io.md | 2 +- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/src/conventions.md b/src/conventions.md index 16828c496..1dac0e0ec 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -101,10 +101,7 @@ if foo { # Using crates from crates.io -It is allowed to use crates from crates.io, though external -dependencies should not be added gratuitously. All such crates must -have a suitably permissive license. There is an automatic check which -inspects the Cargo metadata to ensure this. +See the [crates.io dependencies][crates] section. @@ -152,3 +149,4 @@ to the compiler. crate-related, often the spelling is changed to `krate`. [tcx]: ./ty.md +[crates]: ./crates-io.md diff --git a/src/crates-io.md b/src/crates-io.md index 896f2697c..8c8fd0c38 100644 --- a/src/crates-io.md +++ b/src/crates-io.md @@ -21,4 +21,4 @@ to the compiler unless there is a good reason to do so. The `tidy` tool has [a list of crates that are allowed]. To add a dependency that is not already in the compiler, you will need to add it to the list. -[a list of crates that are allowed]: https://github.com/rust-lang/rust/blob/19ecce332e56941ea0dd2a805270faa102acdb14/src/tools/tidy/src/deps.rs#L59 +[a list of crates that are allowed]: https://github.com/rust-lang/rust/blob/9d1b2106e23b1abd32fce1f17267604a5102f57a/src/tools/tidy/src/deps.rs#L73 From eeb5a83c15b6ae60df3e4f19207376b22c6fbc4c Mon Sep 17 00:00:00 2001 From: Matthew Woodcraft Date: Mon, 11 Apr 2022 15:29:48 +0100 Subject: [PATCH 1642/1812] method-lookup.md improvements (#1296) --- src/method-lookup.md | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/src/method-lookup.md b/src/method-lookup.md index 250eea034..8eb8ec5ce 100644 --- a/src/method-lookup.md +++ b/src/method-lookup.md @@ -79,33 +79,34 @@ behavior should be reconsidered in light of where clauses. TODO: Is this FIXME still accurate? **Extension candidates** are derived from imported traits. If I have -the trait `ToString` imported, and I call `to_string()` on a value of -type `T`, then we will go off to find out whether there is an impl of -`ToString` for `T`. These kinds of method calls are called "extension -methods". They can be defined in any crate, not only the one that -defined `T`. Furthermore, you must import the trait to call such a -method. +the trait `ToString` imported, and I call `to_string()` as a method, +then we will list the `to_string()` definition in each impl of +`ToString` as a candidate. These kinds of method calls are called +"extension methods". So, let's continue our example. Imagine that we were calling a method `foo` with the receiver `Rc>` and there is a trait `Foo` that defines it with `&self` for the type `Rc` as well as a method -on the type `Box` that defines `Foo` but with `&mut self`. Then we +on the type `Box` that defines `foo` but with `&mut self`. Then we might have two candidates: -- `&Rc>` from the impl of `Foo` for `Rc` where `U=Box<[T; 3]>` -- `&mut Box<[T; 3]>>` from the inherent impl on `Box` where `U=[T; 3]` +- `&Rc` as an extension candidate +- `&mut Box` as an inherent candidate ### Candidate search Finally, to actually pick the method, we will search down the steps, trying to match the receiver type against the candidate types. At each step, we also consider an auto-ref and auto-mut-ref to see whether -that makes any of the candidates match. We pick the first step where -we find a match. +that makes any of the candidates match. For each resulting receiver +type, we consider inherent candidates before extension candidates. +If there are multiple matching candidates in a group, we report an +error, except that multiple impls of the same trait are treated as a +single match. Otherwise we pick the first match we find. In the case of our example, the first step is `Rc>`, which does not itself match any candidate. But when we autoref it, we -get the type `&Rc>` which does match. We would then +get the type `&Rc>` which matches `&Rc`. We would then recursively consider all where-clauses that appear on the impl: if those match (or we cannot rule out that they do), then this is the method we would pick. Otherwise, we would continue down the series of From d9bfa3788c3ef77360c263b6f6a8de2879835a49 Mon Sep 17 00:00:00 2001 From: David Wood Date: Thu, 14 Apr 2022 13:57:32 +0800 Subject: [PATCH 1643/1812] sessiondiagnostic: translation (#1333) --- src/diagnostics/sessiondiagnostic.md | 252 +++++++++++++++++++-------- 1 file changed, 181 insertions(+), 71 deletions(-) diff --git a/src/diagnostics/sessiondiagnostic.md b/src/diagnostics/sessiondiagnostic.md index 4583e6d3d..e82d5629d 100644 --- a/src/diagnostics/sessiondiagnostic.md +++ b/src/diagnostics/sessiondiagnostic.md @@ -1,97 +1,207 @@ -# Creating Errors With SessionDiagnostic +# Creating translatable errors using `SessionDiagnostic` +The `SessionDiagnostic` derive macro is the recommended way to create +diagnostics. Diagnostics created with the derive macro can be translated into +different languages and each have a slug that uniquely identifies the +diagnostic. -The SessionDiagnostic derive macro gives an alternate way to the DiagnosticBuilder API for defining -and emitting errors. It allows a struct to be annotated with information which allows it to be -transformed and emitted as a Diagnostic. +Instead of using the `DiagnosticBuilder` API to create and emit diagnostics, +the `SessionDiagnostic` derive macro is applied to structs. -As an example, we'll take a look at how the "field already declared" diagnostic is actually defined -in the compiler (see the definition -[here](https://github.com/rust-lang/rust/blob/75042566d1c90d912f22e4db43b6d3af98447986/compiler/rustc_typeck/src/errors.rs#L65-L74) -and usage -[here](https://github.com/rust-lang/rust/blob/75042566d1c90d912f22e4db43b6d3af98447986/compiler/rustc_typeck/src/collect.rs#L863-L867)): +The [definition][defn] of the "field already declared" diagnostic is shown +below. ```rust,ignore #[derive(SessionDiagnostic)] -#[error = "E0124"] +#[error(code = "E0124", slug = "typeck-field-already-declared")] pub struct FieldAlreadyDeclared { pub field_name: Ident, - #[message = "field `{field_name}` is already declared"] - #[label = "field already declared"] + #[primary_span] + #[label] pub span: Span, - #[label = "`{field_name}` first declared here"] + #[label = "previous-decl-label"] pub prev_span: Span, } -// ... -tcx.sess.emit_err(FieldAlreadyDeclared { - field_name: f.ident, - span: f.span, - prev_span, -}); ``` -We see that using `SessionDiagnostic` is relatively straight forward. The `#[error = "..."]` -attribute is used to supply the error code for the diagnostic. We then annotate fields in the -struct with various information on how to convert an instance of the struct into a rendered -diagnostic. The attributes above produce code which is roughly equivalent to the following (in -pseudo-Rust): +Every `SessionDiagnostic` has to have one attribute applied to the struct +itself: either `#[error(..)]` for defining errors, or `#[warning(..)]` for +defining warnings. + +If an error has an error code (e.g. "E0624"), then that can be specified using +the `code` sub-attribute. Specifying a `code` isn't mandatory, but if you are +porting a diagnostic that uses `DiagnosticBuilder` to use `SessionDiagnostic` +then you should keep the code if there was one. + +Both `#[error(..)]` and `#[warning(..)]` must set a value for the `slug` +sub-attribute. `slug` uniquely identifies the diagnostic and is also how the +compiler knows what error message to emit (in the default locale of the +compiler, or in the locale requested by the user). + +rustc uses [Fluent](https://projectfluent.org) to handle the intricacies of +translation. Each diagnostic's `slug` is actually an identifier for a *Fluent +message*. Let's take a look at what the Fluent message for the "field already +declared" diagnostic looks like: + +```fluent +typeck-field-already-declared = + field `{$field_name}` is already declared + .label = field already declared + .previous-decl-label = `{$field_name}` first declared here +``` + +`typeck-field-already-declared` is the `slug` from our example and is followed +by the diagnostic message. + +Fluent is built around the idea of "asymmetric localization", which aims to +decouple the expressiveness of translations from the grammar of the source +language (English in rustc's case). Prior to translation, rustc's diagnostics +relied heavily on interpolation to build the messages shown to the users. +Interpolated strings are hard to translate because writing a natural-sounding +translation might require more, less, or just different interpolation than the +English string, all of which would require changes to the compiler's source +code to support. + +As the compiler team gain more experience creating `SessionDiagnostic` structs +that have all of the information necessary to be translated into different +languages, this page will be updated with more guidance. For now, the [Project +Fluent](https://projectfluent.org) documentation has excellent examples of +translating messages into different locales and the information that needs to +be provided by the code to do so. + +When adding or changing a diagnostic, you don't need to worry about the +translations, only updating the original English message. All of rustc's +English Fluent messages can be found in +`/compiler/rustc_error_messages/locales/en-US/diagnostics.ftl`. + +Every field of the `SessionDiagnostic` which does not have an annotation is +available in Fluent messages as a variable, like `field_name` in the example +above. + +Using the `#[primary_span]` attribute on a field (that has type `Span`) +indicates the primary span of the diagnostic which will have the main message +of the diagnostic. + +Diagnostics are more than just their primary message, they often include +labels, notes, help messages and suggestions, all of which can also be +specified on a `SessionDiagnostic`. + +`#[label]`, `#[help]` and `#[note]` can all be applied to fields which have the +type `Span`. Applying any of these attributes will create the corresponding +sub-diagnostic with that `Span`. These attributes will look for their +diagnostic message in a Fluent attribute attached to the primary Fluent +message. In our example, `#[label]` will look for +`typeck-field-already-declared.label` (which has the message "field already +declared"). If there is more than one sub-diagnostic of the same type, then +these attributes can also take a value that is the attribute name to look for +(e.g. `previous-decl-label` in our example). + +`#[help]` and `#[note]` can also be applied to the struct itself, in which case +they work exactly like when applied to fields except the sub-diagnostic won't +have a `Span`. + +Any attribute can also be applied to an `Option` and will only emit a +sub-diagnostic if the option is `Some(..)`. + +Suggestions can be emitted using one of four field attributes: + +- `#[suggestion(message = "...", code = "...")]` +- `#[suggestion_hidden(message = "...", code = "...")]` +- `#[suggestion_short(message = "...", code = "...")]` +- `#[suggestion_verbose(message = "...", code = "...")]` + +Suggestions must be applied on either a `Span` field or a +`(Span, MachineApplicability)` field. Similarly to other field attributes, +`message` specifies the Fluent attribute with the message and defaults to +`.suggestion`. `code` specifies the code that should be suggested as a +replacement and is a format string (e.g. `{field_name}` would be replaced by +the value of the `field_name` field of the struct), not a Fluent identifier. + +In the end, the `SessionDiagnostic` derive will generate an implementation of +`SessionDiagnostic` that looks like the following: ```rust,ignore impl SessionDiagnostic for FieldAlreadyDeclared { fn into_diagnostic(self, sess: &'_ rustc_session::Session) -> DiagnosticBuilder<'_> { - let mut diag = sess.struct_err_with_code("", rustc_errors::DiagnosticId::Error("E0124")); + let mut diag = sess.struct_err_with_code( + rustc_errors::DiagnosticMessage::fluent("typeck-field-already-declared"), + rustc_errors::DiagnosticId::Error("E0124") + ); diag.set_span(self.span); - diag.set_primary_message(format!("field `{field_name}` is already declared", field_name = self.field_name)); - diag.span_label(self.span, "field already declared"); - diag.span_label(self.prev_span, format!("`{field_name}` first declared here", field_name = self.field_name)); + diag.span_label( + self.span, + rustc_errors::DiagnosticMessage::fluent_attr("typeck-field-already-declared", "label") + ); + diag.span_label( + self.prev_span, + rustc_errors::DiagnosticMessage::fluent_attr("typeck-field-already-declared", "previous-decl-label") + ); diag } } ``` -The generated code draws attention to a number of features. First, we see that within the strings -passed to each attribute, field names can be referenced without needing to be passed -explicitly into the format string -- in this example here, `#[message = "field {field_name} is -already declared"]` produces a call to `format!` with the appropriate arguments to format -`self.field_name` into the string. This applies to strings passed to all attributes. - -We also see that labelling `Span` fields in the struct produces calls which pass that `Span` to the -produced diagnostic. In the example above, we see that putting the `#[message = "..."]` attribute -on a `Span` leads to the primary span of the diagnostic being set to that `Span`, while applying the -`#[label = "..."]` attribute on a Span will simply set the span for that label. -Each attribute has different requirements for what they can be applied on, differing on position -(on the struct, or on a specific field), type (if it's applied on a field), and whether or not the -attribute is optional. - -## Attributes Listing - -Below is a listing of all the currently-available attributes that `#[derive(SessionDiagnostic)]` -understands: - -Attribute | Applied to | Mandatory | Behaviour -:-------------- | :-------------------- |:--------- | :--------- -`#[code = "..."]` | Struct | Yes | Sets the Diagnostic's error code -`#[message = "..."]` | Struct / `Span` fields | Yes | Sets the Diagnostic's primary message. If on `Span` field, also sets the Diagnostic's span. -`#[label = "..."]` | `Span` fields | No | Equivalent to calling `span_label` with that Span and message. -`#[suggestion(message = "..." , code = "..."]` | `(Span, MachineApplicability)` or `Span` fields | No | Equivalent to calling `span_suggestion`. Note `code` is optional. -`#[suggestion_short(message = "..." , code = "..."]` | `(Span, MachineApplicability)` or `Span` fields | No | Equivalent to calling `span_suggestion_short`. Note `code` is optional. -`#[suggestion_hidden(message = "..." , code = "..."]` | `(Span, MachineApplicability)` or `Span` fields | No | Equivalent to calling `span_suggestion_hidden`. Note `code` is optional. -`#[suggestion_verbose(message = "..." , code = "..."]` | `(Span, MachineApplicability)` or `Span` fields | No | Equivalent to calling `span_suggestion_verbose`. Note `code` is optional. +Now that we've defined our diagnostic, how do we [use it][use]? It's quite +straightforward, just create an instance of the struct and pass it to +`emit_err` (or `emit_warning`): +```rust,ignore +tcx.sess.emit_err(FieldAlreadyDeclared { + field_name: f.ident, + span: f.span, + prev_span, +}); +``` -## Optional Diagnostic Attributes +## Reference +`#[derive(SessionDiagnostic)]` supports the following attributes: -There may be some cases where you want one of the decoration attributes to be applied optionally; -for example, if a suggestion can only be generated sometimes. In this case, simply wrap the field's -type in an `Option`. At runtime, if the field is set to `None`, the attribute for that field won't -be used in creating the diagnostic. For example: +- `#[error(code = "...", slug = "...")]` or `#[warning(code = "...", slug = "...")]` + - _Applied to struct._ + - _Mandatory_ + - Defines the struct to be representing an error or a warning. + - `code = "..."` + - _Optional_ + - Specifies the error code. + - `slug = "..."` + - _Mandatory_ + - Uniquely identifies the diagnostic and corresponds to its Fluent message, + mandatory. +- `#[note]` or `#[note = "..."]` + - _Applied to struct or `Span` fields._ + - _Optional_ + - Adds a note sub-diagnostic. + - Value is the Fluent attribute (relative to the Fluent message specified by + `slug`) for the note's message + - Defaults to `note`. + - If applied to a `Span` field, creates a spanned note. +- `#[help]` or `#[help = "..."]` + - _Applied to struct or `Span` fields._ + - _Optional_ + - Adds a help sub-diagnostic. + - Value is the Fluent attribute (relative to the Fluent message specified by + `slug`) for the help's message + - Defaults to `help`. + - If applied to a `Span` field, creates a spanned help. +- `#[label]` or `#[label = "..."]` + - _Applied to `Span` fields._ + - _Optional_ + - Adds a label sub-diagnostic. + - Value is the Fluent attribute (relative to the Fluent message specified by + `slug`) for the label's message + - Defaults to `label`. +- `#[suggestion{,_hidden,_short,_verbose}(message = "...", code = "...")]` + - _Applied to `(Span, MachineApplicability)` or `Span` fields._ + - _Optional_ + - Adds a suggestion sub-diagnostic. + - `message = "..."` + - _Mandatory_ + - Value is the Fluent attribute (relative to the Fluent message specified + by `slug`) for the suggestion's message + - Defaults to `suggestion`. + - `code = "..."` + - _Optional_ + - Value is a format string indicating the code to be suggested as a + replacement. -```rust,ignored -#[derive(SessionDiagnostic)] -#[code = "E0123"] -struct SomeKindOfError { - ... - #[suggestion(message = "informative error message")] - opt_sugg: Option<(Span, Applicability)> - ... -} -``` +[defn]: https://github.com/rust-lang/rust/blob/bbe9d27b8ff36da56638aa43d6d0cdfdf89a4e57/compiler/rustc_typeck/src/errors.rs#L65-L74 +[use]: https://github.com/rust-lang/rust/blob/eb82facb1626166188d49599a3313fc95201f556/compiler/rustc_typeck/src/collect.rs#L981-L985 From e58b4c04cb99bed785edfd0d99479c57e994d859 Mon Sep 17 00:00:00 2001 From: Eric Holk Date: Thu, 14 Apr 2022 03:44:36 -0700 Subject: [PATCH 1644/1812] Minor type fix (#1337) --- src/borrow_check/region_inference/placeholders_and_universes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md index 967aa0d33..91c8c4526 100644 --- a/src/borrow_check/region_inference/placeholders_and_universes.md +++ b/src/borrow_check/region_inference/placeholders_and_universes.md @@ -122,7 +122,7 @@ Now let's extend `bar` a bit by adding one more variable, `y`: ```rust,ignore fn bar<'a, T>(t: &'a T) { let x: for<'b> fn(&'b u32) = ...; - let y: for<'c> fn(&'b u32) = ...; + let y: for<'c> fn(&'c u32) = ...; } ``` From aa31b101615d0dfbb9ec00f15c301a32d263b95b Mon Sep 17 00:00:00 2001 From: Frank Steffahn Date: Thu, 14 Apr 2022 12:46:54 +0200 Subject: [PATCH 1645/1812] Fix typo serious->series (#1336) --- src/traits/caching.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/traits/caching.md b/src/traits/caching.md index c963aafc4..54bd0704a 100644 --- a/src/traits/caching.md +++ b/src/traits/caching.md @@ -53,7 +53,7 @@ where clauses that are in scope. The determination of which cache to use is done by the method `pick_candidate_cache` in `select.rs`. At the moment, we use a very simple, conservative rule: if there are any where-clauses in scope, then we use the local cache. We used to try -and draw finer-grained distinctions, but that led to a serious of +and draw finer-grained distinctions, but that led to a series of annoying and weird bugs like [#22019] and [#18290]. This simple rule seems to be pretty clearly safe and also still retains a very high hit rate (~95% when compiling rustc). From c190ae37e1299559499c65d6ea67c29f186adb12 Mon Sep 17 00:00:00 2001 From: scottmcm Date: Thu, 14 Apr 2022 11:10:34 +0000 Subject: [PATCH 1646/1812] Send people doing *library* stabilizations over to the std-dev-guide (#1317) Co-authored-by: pierwill <19642016+pierwill@users.noreply.github.com> --- src/stabilization_guide.md | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md index 850168705..454cd0f27 100644 --- a/src/stabilization_guide.md +++ b/src/stabilization_guide.md @@ -84,6 +84,9 @@ decision is to stabilize, we proceed to do the actual code modification. ## Stabilization PR +*This is for stabilizing language features. If you are stabilizing a library +feature, see [the stabilization chapter of the std dev guide][std-guide-stabilization] instead.* + Once we have decided to stabilize a feature, we need to have a PR that actually makes that stabilization happen. These kinds of PRs are a great way to get involved in Rust, as they take @@ -96,6 +99,24 @@ require steps beyond what this guide talks about. Note: Before we stabilize any feature, it's the rule that it should appear in the documentation. +### Determining the stabilization version + +The version in which the feature will be stabilized *must* match +the value of [the `src/version` file in `master`][src-version] when the PR is merged. + +It's worth checking [the version schedule on the Forge][forge-versions] to see whether +changes are coming soon. You'll usually use the version labelled "Nightly". +"Nightly" is two versions higher than the current stable release, +since what's currently in beta will be the next stable release, +and any changes you're making now will be in the one after that. + +No PR is merged instantly, so you'll want to be careful around release time. +The version bump happens [the Friday before][forge-release-process] the stable release, +not the same time as the release. So if you're opening a PR shortly before then, +be prepared to update the version, or consider just opening it for one version +higher than the current nightly, with a note saying not to merge until +after the upcoming version bump. + ### Updating the feature-gate listing There is a central listing of feature-gates in @@ -119,14 +140,7 @@ When it is done, it should look like: // note that we changed this ``` -Note that, the version number is updated to be the version number -of the stable release where this feature will appear. This can be -found by consulting [the forge](https://forge.rust-lang.org/), which will guide -you the next stable release number. You want to add 1 to that, -because the code that lands today will become go into beta on that -date, and then become stable after that. So, at the time of this -writing, the next stable release (i.e. what is currently beta) was -1.30.0, hence I wrote 1.31.0 above. +(The version here is the one discussed in the previous section.) ### Removing existing uses of the feature-gate @@ -184,6 +198,10 @@ if something { /* XXX */ } ``` [rust-lang/rust#32409]: https://github.com/rust-lang/rust/issues/32409 +[std-guide-stabilization]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html +[src-version]: https://github.com/rust-lang/rust/blob/master/src/version +[forge-versions]: https://forge.rust-lang.org/#current-release-versions +[forge-release-process]: https://forge.rust-lang.org/release/process.html [`compiler/rustc_feature`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/index.html [The Reference]: https://github.com/rust-lang/reference [The Book]: https://github.com/rust-lang/book From a8add664d4b20c48762c23a03e1cb803d62aa369 Mon Sep 17 00:00:00 2001 From: Felix S Klock II Date: Thu, 14 Apr 2022 07:17:36 -0400 Subject: [PATCH 1647/1812] Extend debugging llvm section (#1290) --- src/backend/debugging.md | 111 +++++++++++++++++++++++++++++++++------ 1 file changed, 94 insertions(+), 17 deletions(-) diff --git a/src/backend/debugging.md b/src/backend/debugging.md index 673660167..791a61fbe 100644 --- a/src/backend/debugging.md +++ b/src/backend/debugging.md @@ -11,6 +11,8 @@ project on its own that probably needs to have its own debugging document (not that I could find one). But here are some tips that are important in a rustc context: +### Minimize the example + As a general rule, compilers generate lots of information from analyzing code. Thus, a useful first step is usually to find a minimal example. One way to do this is to @@ -24,6 +26,13 @@ everything relevant to the new crate 3. further minimize the issue by making the code shorter (there are tools that help with this like `creduce`) +For more discussion on methodology for steps 2 and 3 above, there is an +[epic blog post][mcve-blog] from pnkfelix specifically about Rust program minimization. + +[mcve-blog]: https://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/ + +### Enable LLVM internal checks + The official compilers (including nightlies) have LLVM assertions disabled, which means that LLVM assertion failures can show up as compiler crashes (not ICEs but "real" crashes) and other sorts of weird behavior. If you are @@ -34,12 +43,29 @@ anything turns up. The rustc build process builds the LLVM tools into `./build//llvm/bin`. They can be called directly. +These tools include: + * [`llc`], which compiles bitcode (`.bc` files) to executable code; this can be used to + replicate LLVM backend bugs. + * [`opt`], a bitcode transformer that runs LLVM optimization passes. + * [`bugpoint`], which reduces large test cases to small, useful ones. + * and many others, some of which are referenced in the text below. + +[`llc`]: https://llvm.org/docs/CommandGuide/llc.html +[`opt`]: https://llvm.org/docs/CommandGuide/opt.html +[`bugpoint`]: https://llvm.org/docs/Bugpoint.html + +By default, the Rust build system does not check for changes to the LLVM source code or +its build configuration settings. So, if you need to rebuild the LLVM that is linked +into `rustc`, first delete the file `llvm-finished-building`, which should be located +in `build//llvm/`. The default rustc compilation pipeline has multiple codegen units, which is hard to replicate manually and means that LLVM is called multiple times in parallel. If you can get away with it (i.e. if it doesn't make your bug disappear), passing `-C codegen-units=1` to rustc will make debugging easier. +### Get your hands on raw LLVM input + For rustc to generate LLVM IR, you need to pass the `--emit=llvm-ir` flag. If you are building via cargo, use the `RUSTFLAGS` environment variable (e.g. `RUSTFLAGS='--emit=llvm-ir'`). This causes rustc to spit out LLVM IR into the @@ -52,24 +78,22 @@ other useful options. Also, debug info in LLVM IR can clutter the output a lot: `RUSTFLAGS="-C debuginfo=0"` is really useful. `RUSTFLAGS="-C save-temps"` outputs LLVM bitcode (not the same as IR) at -different stages during compilation, which is sometimes useful. One just needs -to convert the bitcode files to `.ll` files using `llvm-dis` which should be in -the target local compilation of rustc. +different stages during compilation, which is sometimes useful. The output LLVM +bitcode will be in `.bc` files in the compiler's output directory, set via the +`--out-dir DIR` argument to `rustc`. -If you are seeing incorrect behavior due to an optimization pass, a very handy -LLVM option is `-opt-bisect-limit`, which takes an integer denoting the index -value of the highest pass to run. Index values for taken passes are stable -from run to run; by coupling this with software that automates bisecting the -search space based on the resulting program, an errant pass can be quickly -determined. When an `-opt-bisect-limit` is specified, all runs are displayed -to standard error, along with their index and output indicating if the -pass was run or skipped. Setting the limit to an index of -1 (e.g., -`RUSTFLAGS="-C llvm-args=-opt-bisect-limit=-1"`) will show all passes and -their corresponding index values. + * If you are hitting an assertion failure or segmentation fault from the LLVM + backend when invoking `rustc` itself, it is a good idea to try passing each + of these `.bc` files to the `llc` command, and see if you get the same + failure. (LLVM developers often prefer a bug reduced to a `.bc` file over one + that uses a Rust crate for its minimized reproduction.) -If you want to play with the optimization pipeline, you can use the `opt` tool -from `./build//llvm/bin/` with the LLVM IR emitted by rustc. Note -that rustc emits different IR depending on whether `-O` is enabled, even + * To get human readable versions of the LLVM bitcode, one just needs to convert + the bitcode (`.bc`) files to `.ll` files using `llvm-dis`, which should be in + the target local compilation of rustc. + + +Note that rustc emits different IR depending on whether `-O` is enabled, even without LLVM's optimizations, so if you want to play with the IR rustc emits, you should: @@ -93,6 +117,18 @@ to some file. Also, if you are using neither `-filter-print-funcs` nor `-C codegen-units=1`, then, because the multiple codegen units run in parallel, the printouts will mix together and you won't be able to read anything. + * One caveat to the aforementioned methodology: the `-print` family of options + to LLVM only prints the IR unit that the pass runs on (e.g., just a + function), and does not include any referenced declarations, globals, + metadata, etc. This means you cannot in general feed the output of `-print` + into `llc` to reproduce a given problem. + + * Within LLVM itself, calling `F.getParent()->dump()` at the beginning of + `SafeStackLegacyPass::runOnFunction` will dump the whole module, which + may provide better basis for reproduction. (However, you + should be able to get that same dump from the `.bc` files dumped by + `-C save-temps`.) + If you want just the IR for a specific function (say, you want to see why it causes an assertion or doesn't optimize correctly), you can use `llvm-extract`, e.g. @@ -105,6 +141,45 @@ $ ./build/$TRIPLE/llvm/bin/llvm-extract \ > extracted.ll ``` +### Investigate LLVM optimization passes + +If you are seeing incorrect behavior due to an optimization pass, a very handy +LLVM option is `-opt-bisect-limit`, which takes an integer denoting the index +value of the highest pass to run. Index values for taken passes are stable +from run to run; by coupling this with software that automates bisecting the +search space based on the resulting program, an errant pass can be quickly +determined. When an `-opt-bisect-limit` is specified, all runs are displayed +to standard error, along with their index and output indicating if the +pass was run or skipped. Setting the limit to an index of -1 (e.g., +`RUSTFLAGS="-C llvm-args=-opt-bisect-limit=-1"`) will show all passes and +their corresponding index values. + +If you want to play with the optimization pipeline, you can use the [`opt`] tool +from `./build//llvm/bin/` with the LLVM IR emitted by rustc. + +When investigating the implementation of LLVM itself, you should be +aware of its [internal debug infrastructure][llvm-debug]. +This is provided in LLVM Debug builds, which you enable for rustc +LLVM builds by changing this setting in the config.toml: +``` +[llvm] +# Indicates whether the LLVM assertions are enabled or not +assertions = true + +# Indicates whether the LLVM build is a Release or Debug build +optimize = false +``` +The quick summary is: + * Setting `assertions=true` enables coarse-grain debug messaging. + * beyond that, setting `optimize=false` enables fine-grain debug messaging. + * `LLVM_DEBUG(dbgs() << msg)` in LLVM is like `debug!(msg)` in `rustc`. + * The `-debug` option turns on all messaging; it is like setting the + environment variable `RUSTC_LOG=debug` in `rustc`. + * The `-debug-only=,` variant is more selective; it is like + setting the environment variable `RUSTC_LOG=path1,path2` in `rustc`. + +[llvm-debug]: https://llvm.org/docs/ProgrammersManual.html#the-llvm-debug-macro-and-debug-option + ### Getting help and asking questions If you have some questions, head over to the [rust-lang Zulip] and @@ -164,7 +239,9 @@ create a minimal working example with Godbolt. Go to optimizations transform it. 5. Once you have a godbolt link demonstrating the issue, it is pretty easy to - fill in an LLVM bug. Just visit [bugs.llvm.org](https://bugs.llvm.org/). + fill in an LLVM bug. Just visit their [github issues page][llvm-issues]. + +[llvm-issues]: https://github.com/llvm/llvm-project/issues ### Porting bug fixes from LLVM From 043e60f4f191651e9f8bf52fa32df14defbb23d9 Mon Sep 17 00:00:00 2001 From: printfn Date: Wed, 20 Apr 2022 11:57:49 +0200 Subject: [PATCH 1648/1812] Fix a small typo (#1343) --- src/part-5-intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/part-5-intro.md b/src/part-5-intro.md index 78e6fa2e9..4b7c25797 100644 --- a/src/part-5-intro.md +++ b/src/part-5-intro.md @@ -11,7 +11,7 @@ will finally take the MIR and produce some executable machine code. [MIR]: ./mir/index.md -> NOTE: This part of a compiler is often called the _backend_ the term is a bit +> NOTE: This part of a compiler is often called the _backend_. The term is a bit > overloaded because in the compiler source, it usually refers to the "codegen > backend" (i.e. LLVM or Cranelift). Usually, when you see the word "backend" > in this part, we are referring to the "codegen backend". From e827b0aaa1a3d3b53fbe5e25e443dcf62f252cd3 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Fri, 15 Apr 2022 16:57:37 +0900 Subject: [PATCH 1649/1812] Update some date refs --- src/contributing.md | 8 ++++---- src/conventions.md | 2 +- src/salsa.md | 2 +- src/thir.md | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 0c6b15da3..3fe0948cc 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -443,12 +443,12 @@ Just a few things to keep in mind: Try to format the date as ` ` to ease search. - Additionally, include a machine-readable comment of the form `` (if the current month is October 2021). We have an automated + 2022-04 -->` (if the current month is April 2022). We have an automated tool that uses these (in `ci/date-check`). - So, for the month of January 2021, the comment would look like: `As of October 2021`. Make sure to put the comment *between* `as of` - and `October 2021`; see [PR #1066][rdg#1066] for the rationale. + So, for the month of April 2022, the comment would look like: `As of April 2022`. Make sure to put the comment *between* `as of` + and `April 2022`; see [PR #1066][rdg#1066] for the rationale. - A link to a relevant WG, tracking issue, `rustc` rustdoc page, or similar, that may provide further explanation for the change process or a way to verify that the information is not diff --git a/src/conventions.md b/src/conventions.md index 1dac0e0ec..15d125377 100644 --- a/src/conventions.md +++ b/src/conventions.md @@ -21,7 +21,7 @@ Formatting is checked by the `tidy` script. It runs automatically when you do If you want to use format-on-save in your editor, the pinned version of `rustfmt` is built under `build//stage0/bin/rustfmt`. You'll have to -pass the `--edition=2021` argument yourself when calling +pass the `--edition=2021` argument yourself when calling `rustfmt` directly. [fmt]: https://github.com/rust-dev-tools/fmt-rfcs diff --git a/src/salsa.md b/src/salsa.md index a6a6b9706..d9190f646 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -9,7 +9,7 @@ want to watch [Salsa In More Depth](https://www.youtube.com/watch?v=i_IhACacPRY), also by Niko Matsakis. -> As of July 2021, although Salsa is inspired by +> As of April 2022, although Salsa is inspired by > (among other things) rustc's query system, it is not used directly in rustc. > It _is_ used in chalk and extensively in `rust-analyzer`, but there are no > medium or long-term concrete plans to integrate it into the compiler. diff --git a/src/thir.md b/src/thir.md index 95009e552..4f8e6512c 100644 --- a/src/thir.md +++ b/src/thir.md @@ -4,7 +4,7 @@ The THIR ("Typed High-Level Intermediate Representation"), previously called HAIR for "High-Level Abstract IR", is another IR used by rustc that is generated after -[type checking]. It is (as of August 2021) only used for +[type checking]. It is (as of April 2022) only used for [MIR construction] and [exhaustiveness checking]. There is also [an experimental unsafety checker][thir-unsafeck] that operates on the THIR as a replacement for the current MIR unsafety checker, and can be used instead of the MIR unsafety checker by passing From 9ec019011f03a09cbf295e1374ebf544d2fa4707 Mon Sep 17 00:00:00 2001 From: pierwill <19642016+pierwill@users.noreply.github.com> Date: Mon, 2 May 2022 15:10:45 -0500 Subject: [PATCH 1650/1812] Edit "What the compiler does to your code" (#1306) * Edit overview.md * Fix lexer crate * Edit wording Co-authored-by: pierwill --- src/overview.md | 216 +++++++++++++++++++++++++++--------------------- 1 file changed, 124 insertions(+), 92 deletions(-) diff --git a/src/overview.md b/src/overview.md index c77fd6cf6..e7ea11e37 100644 --- a/src/overview.md +++ b/src/overview.md @@ -17,94 +17,122 @@ So first, let's look at what the compiler does to your code. For now, we will avoid mentioning how the compiler implements these steps except as needed; we'll talk about that later. -- The compile process begins when a user writes a Rust source program in text - and invokes the `rustc` compiler on it. The work that the compiler needs to - perform is defined by command-line options. For example, it is possible to - enable nightly features (`-Z` flags), perform `check`-only builds, or emit - LLVM-IR rather than executable machine code. The `rustc` executable call may - be indirect through the use of `cargo`. -- Command line argument parsing occurs in the [`rustc_driver`]. This crate - defines the compile configuration that is requested by the user and passes it - to the rest of the compilation process as a [`rustc_interface::Config`]. -- The raw Rust source text is analyzed by a low-level lexer located in - [`rustc_lexer`]. At this stage, the source text is turned into a stream of - atomic source code units known as _tokens_. The lexer supports the - Unicode character encoding. -- The token stream passes through a higher-level lexer located in - [`rustc_parse`] to prepare for the next stage of the compile process. The - [`StringReader`] struct is used at this stage to perform a set of validations - and turn strings into interned symbols (_interning_ is discussed later). - [String interning] is a way of storing only one immutable - copy of each distinct string value. - -- The lexer has a small interface and doesn't depend directly on the - diagnostic infrastructure in `rustc`. Instead it provides diagnostics as plain - data which are emitted in `rustc_parse::lexer::mod` as real diagnostics. -- The lexer preserves full fidelity information for both IDEs and proc macros. -- The parser [translates the token stream from the lexer into an Abstract Syntax - Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax - analysis. The crate entry points for the parser are the - [`Parser::parse_crate_mod()`][parse_crate_mod] and [`Parser::parse_mod()`][parse_mod] - methods found in [`rustc_parse::parser::Parser`]. The external module parsing - entry point is [`rustc_expand::module::parse_external_mod`][parse_external_mod]. - And the macro parser entry point is [`Parser::parse_nonterminal()`][parse_nonterminal]. -- Parsing is performed with a set of `Parser` utility methods including `fn bump`, - `fn check`, `fn eat`, `fn expect`, `fn look_ahead`. -- Parsing is organized by the semantic construct that is being parsed. Separate - `parse_*` methods can be found in [`rustc_parse` `parser`][rustc_parse_parser_dir] - directory. The source file name follows the construct name. For example, the - following files are found in the parser: - - `expr.rs` - - `pat.rs` - - `ty.rs` - - `stmt.rs` -- This naming scheme is used across many compiler stages. You will find - either a file or directory with the same name across the parsing, lowering, - type checking, THIR lowering, and MIR building sources. -- Macro expansion, AST validation, name resolution, and early linting takes place - during this stage of the compile process. -- The parser uses the standard `DiagnosticBuilder` API for error handling, but we - try to recover, parsing a superset of Rust's grammar, while also emitting an error. -- `rustc_ast::ast::{Crate, Mod, Expr, Pat, ...}` AST nodes are returned from the parser. -- We then take the AST and [convert it to High-Level Intermediate - Representation (HIR)][hir]. This is a compiler-friendly representation of the - AST. This involves a lot of desugaring of things like loops and `async fn`. -- We use the HIR to do [type inference] (the process of automatic - detection of the type of an expression), [trait solving] (the process - of pairing up an impl with each reference to a trait), and [type - checking] (the process of converting the types found in the HIR - (`hir::Ty`), which represent the syntactic things that the user wrote, - into the internal representation used by the compiler (`Ty<'tcx>`), - and using that information to verify the type safety, correctness and - coherence of the types used in the program). -- The HIR is then [lowered to Mid-Level Intermediate Representation (MIR)][mir]. - - Along the way, we construct the THIR, which is an even more desugared HIR. - THIR is used for pattern and exhaustiveness checking. It is also more - convenient to convert into MIR than HIR is. -- The MIR is used for [borrow checking]. -- We (want to) do [many optimizations on the MIR][mir-opt] because it is still - generic and that improves the code we generate later, improving compilation - speed too. - - MIR is a higher level (and generic) representation, so it is easier to do - some optimizations at MIR level than at LLVM-IR level. For example LLVM - doesn't seem to be able to optimize the pattern the [`simplify_try`] mir - opt looks for. -- Rust code is _monomorphized_, which means making copies of all the generic - code with the type parameters replaced by concrete types. To do - this, we need to collect a list of what concrete types to generate code for. - This is called _monomorphization collection_. -- We then begin what is vaguely called _code generation_ or _codegen_. - - The [code generation stage (codegen)][codegen] is when higher level - representations of source are turned into an executable binary. `rustc` - uses LLVM for code generation. The first step is to convert the MIR - to LLVM Intermediate Representation (LLVM IR). This is where the MIR - is actually monomorphized, according to the list we created in the - previous step. - - The LLVM IR is passed to LLVM, which does a lot more optimizations on it. - It then emits machine code. It is basically assembly code with additional - low-level types and annotations added. (e.g. an ELF object or wasm). - - The different libraries/binaries are linked together to produce the final - binary. +### Invocation + +Compilation begins when a user writes a Rust source program in text +and invokes the `rustc` compiler on it. The work that the compiler needs to +perform is defined by command-line options. For example, it is possible to +enable nightly features (`-Z` flags), perform `check`-only builds, or emit +LLVM-IR rather than executable machine code. The `rustc` executable call may +be indirect through the use of `cargo`. + +Command line argument parsing occurs in the [`rustc_driver`]. This crate +defines the compile configuration that is requested by the user and passes it +to the rest of the compilation process as a [`rustc_interface::Config`]. + +### Lexing and parsing + +The raw Rust source text is analyzed by a low-level *lexer* located in +[`rustc_lexer`]. At this stage, the source text is turned into a stream of +atomic source code units known as _tokens_. The lexer supports the +Unicode character encoding. + +The token stream passes through a higher-level lexer located in +[`rustc_parse`] to prepare for the next stage of the compile process. The +[`StringReader`] struct is used at this stage to perform a set of validations +and turn strings into interned symbols (_interning_ is discussed later). +[String interning] is a way of storing only one immutable +copy of each distinct string value. + +The lexer has a small interface and doesn't depend directly on the +diagnostic infrastructure in `rustc`. Instead it provides diagnostics as plain +data which are emitted in `rustc_parse::lexer` as real diagnostics. +The lexer preserves full fidelity information for both IDEs and proc macros. + +The *parser* [translates the token stream from the lexer into an Abstract Syntax +Tree (AST)][parser]. It uses a recursive descent (top-down) approach to syntax +analysis. The crate entry points for the parser are the +[`Parser::parse_crate_mod()`][parse_crate_mod] and [`Parser::parse_mod()`][parse_mod] +methods found in [`rustc_parse::parser::Parser`]. The external module parsing +entry point is [`rustc_expand::module::parse_external_mod`][parse_external_mod]. +And the macro parser entry point is [`Parser::parse_nonterminal()`][parse_nonterminal]. + +Parsing is performed with a set of `Parser` utility methods including `bump`, +`check`, `eat`, `expect`, `look_ahead`. + +Parsing is organized by semantic construct. Separate +`parse_*` methods can be found in the [`rustc_parse`][rustc_parse_parser_dir] +directory. The source file name follows the construct name. For example, the +following files are found in the parser: + +- `expr.rs` +- `pat.rs` +- `ty.rs` +- `stmt.rs` + +This naming scheme is used across many compiler stages. You will find +either a file or directory with the same name across the parsing, lowering, +type checking, THIR lowering, and MIR building sources. + +Macro expansion, AST validation, name resolution, and early linting also take place +during this stage. + +The parser uses the standard `DiagnosticBuilder` API for error handling, but we +try to recover, parsing a superset of Rust's grammar, while also emitting an error. +`rustc_ast::ast::{Crate, Mod, Expr, Pat, ...}` AST nodes are returned from the parser. + +### HIR lowering + +We next take the AST and convert it to [High-Level Intermediate +Representation (HIR)][hir], a more compiler-friendly representation of the +AST. This process called "lowering". It involves a lot of desugaring of things +like loops and `async fn`. + +We then use the HIR to do [*type inference*] (the process of automatic +detection of the type of an expression), [*trait solving*] (the process +of pairing up an impl with each reference to a trait), and [*type +checking*]. Type checking is the process of converting the types found in the HIR +([`hir::Ty`]), which represent what the user wrote, +into the internal representation used by the compiler ([`Ty<'tcx>`]). +That information is usedto verify the type safety, correctness and +coherence of the types used in the program. + +### MIR lowering + +The HIR is then [lowered to Mid-level Intermediate Representation (MIR)][mir], +which is used for [borrow checking]. + +Along the way, we also construct the THIR, which is an even more desugared HIR. +THIR is used for pattern and exhaustiveness checking. It is also more +convenient to convert into MIR than HIR is. + +We do [many optimizations on the MIR][mir-opt] because it is still +generic and that improves the code we generate later, improving compilation +speed too. +MIR is a higher level (and generic) representation, so it is easier to do +some optimizations at MIR level than at LLVM-IR level. For example LLVM +doesn't seem to be able to optimize the pattern the [`simplify_try`] mir +opt looks for. + +Rust code is _monomorphized_, which means making copies of all the generic +code with the type parameters replaced by concrete types. To do +this, we need to collect a list of what concrete types to generate code for. +This is called _monomorphization collection_ and it happens at the MIR level. + +### Code generation + +We then begin what is vaguely called _code generation_ or _codegen_. +The [code generation stage][codegen] is when higher level +representations of source are turned into an executable binary. `rustc` +uses LLVM for code generation. The first step is to convert the MIR +to LLVM Intermediate Representation (LLVM IR). This is where the MIR +is actually monomorphized, according to the list we created in the +previous step. +The LLVM IR is passed to LLVM, which does a lot more optimizations on it. +It then emits machine code. It is basically assembly code with additional +low-level types and annotations added (e.g. an ELF object or WASM). +The different libraries/binaries are then linked together to produce the final +binary. [String interning]: https://en.wikipedia.org/wiki/String_interning [`rustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html @@ -115,9 +143,9 @@ we'll talk about that later. [`rustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html -[type inference]: https://rustc-dev-guide.rust-lang.org/type-inference.html -[trait solving]: https://rustc-dev-guide.rust-lang.org/traits/resolution.html -[type checking]: https://rustc-dev-guide.rust-lang.org/type-checking.html +[*type inference*]: https://rustc-dev-guide.rust-lang.org/type-inference.html +[*trait solving*]: https://rustc-dev-guide.rust-lang.org/traits/resolution.html +[*type checking*]: https://rustc-dev-guide.rust-lang.org/type-checking.html [mir]: https://rustc-dev-guide.rust-lang.org/mir/index.html [borrow checking]: https://rustc-dev-guide.rust-lang.org/borrow_check.html [mir-opt]: https://rustc-dev-guide.rust-lang.org/mir/optimizations.html @@ -129,6 +157,8 @@ we'll talk about that later. [`rustc_parse::parser::Parser`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html [parse_external_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/module/fn.parse_external_mod.html [rustc_parse_parser_dir]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_parse/src/parser +[`hir::Ty`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.Ty.html +[`Ty<'tcx>`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Ty.html ## How it does it @@ -323,6 +353,7 @@ For more details on bootstrapping, see [_bootstrapping_]: https://en.wikipedia.org/wiki/Bootstrapping_(compilers) [rustc-bootstrap]: building/bootstrapping.md + + # References - Command line parsing From acb1fcb780eea723625a014ff50afe3c71d6f0d6 Mon Sep 17 00:00:00 2001 From: Who? Me?! Date: Tue, 3 May 2022 09:28:26 -0500 Subject: [PATCH 1651/1812] Document ErrorGuaranteed (#1316) * document ErrorGuaranteed * Fix typos Co-authored-by: pierwill <19642016+pierwill@users.noreply.github.com> * Clarify Niko comment Co-authored-by: Niko Matsakis Co-authored-by: pierwill <19642016+pierwill@users.noreply.github.com> Co-authored-by: Niko Matsakis --- src/SUMMARY.md | 1 + src/diagnostics/error-guaranteed.md | 37 +++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+) create mode 100644 src/diagnostics/error-guaranteed.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 3189b9364..e74ef5e4e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -142,6 +142,7 @@ - [`LintStore`](./diagnostics/lintstore.md) - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) - [Diagnostic Items](./diagnostics/diagnostic-items.md) + - [`ErrorGuaranteed`](./diagnostics/error-guaranteed.md) # MIR to Binaries diff --git a/src/diagnostics/error-guaranteed.md b/src/diagnostics/error-guaranteed.md new file mode 100644 index 000000000..5a9b7f335 --- /dev/null +++ b/src/diagnostics/error-guaranteed.md @@ -0,0 +1,37 @@ +# `ErrorGuaranteed` + +The previous sections have been about the error message that a user of the +compiler sees. But emitting an error can also have a second important side +effect within the compiler source code: it generates an +[`ErrorGuaranteed`][errorguar]. + +`ErrorGuaranteed` is a zero-sized type that is unconstructable outside of the +[`rustc_errors`][rerrors] crate. It is generated whenever an error is reported +to the user, so that if your compiler code ever encounters a value of type +`ErrorGuaranteed`, the compilation is _statically guaranteed to fail_. This is +useful for avoiding unsoundness bugs because you can statically check that an +error code path leads to a failure. + +There are some important considerations about the usage of `ErrorGuaranteed`: + +* It does _not_ convey information about the _kind_ of error. For example, the + error may be due (indirectly) to a `delay_span_bug` or other compiler error. + Thus, you should not rely on + `ErrorGuaranteed` when deciding whether to emit an error, or what kind of error + to emit. + +* `ErrorGuaranteed` should not be used to indicate that a compilation _will + emit_ an error in the future. It should be used to indicate that an error + _has already been_ emitted -- that is, the [`emit()`][emit] function has + already been called. For example, if we detect that a future part of the + compiler will error, we _cannot_ use `ErrorGuaranteed` unless we first emit + an error ourselves. + +Thankfully, in most cases, it should be statically impossible to abuse +`ErrorGuaranteed`. + + +[errorguar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.ErrorGuaranteed.html +[rerrors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html +[dsp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Handler.html#method.delay_span_bug +[emit]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/diagnostic_builder/struct.DiagnosticBuilder.html#method.emit From 2de8cb5dab720e2f401b8898c169f846d392afff Mon Sep 17 00:00:00 2001 From: Ali MJ Al-Nasrawy Date: Sat, 7 May 2022 03:58:20 +0300 Subject: [PATCH 1652/1812] correct type of SubstsRef (#1347) --- src/generics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/generics.md b/src/generics.md index c7a0be093..13549b2fb 100644 --- a/src/generics.md +++ b/src/generics.md @@ -10,7 +10,7 @@ In rustc this is done using the `SubstsRef` that we mentioned above (“substs Conceptually, you can think of `SubstsRef` as a list of types that are to be substituted for the generic type parameters of the ADT. -`SubstsRef` is a type alias of `List>` (see [`List` rustdocs][list]). +`SubstsRef` is a type alias of `&'tcx List>` (see [`List` rustdocs][list]). [`GenericArg`] is essentially a space-efficient wrapper around [`GenericArgKind`], which is an enum indicating what kind of generic the type parameter is (type, lifetime, or const). Thus, `SubstsRef` is conceptually like a `&'tcx [GenericArgKind<'tcx>]` slice (but it is actually a `List`). From a9d0e35c848407d9eeb24aa6d017b5373657ed33 Mon Sep 17 00:00:00 2001 From: Yutaro Ohno Date: Mon, 9 May 2022 09:17:51 +0900 Subject: [PATCH 1653/1812] Fix format (#1349) --- src/building/bootstrapping.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index b6ba3000e..c61afbcd9 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -359,7 +359,7 @@ The following tables indicate the outputs of various stage actions: | `stage0` builds `test`/`std` | `build/HOST/stage0-std/TARGET` | | copy `stage0-std` (HOST only) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | | `stage0` builds `rustc` with `stage0-sysroot` | `build/HOST/stage0-rustc/HOST` | -| copy `stage0-rustc (except executable)` | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | +| copy `stage0-rustc` (except executable) | `build/HOST/stage0-sysroot/lib/rustlib/HOST` | | build `llvm` | `build/HOST/llvm` | | `stage0` builds `codegen` with `stage0-sysroot` | `build/HOST/stage0-codegen/HOST` | | `stage0` builds `rustdoc`, `clippy`, `miri`, with `stage0-sysroot` | `build/HOST/stage0-tools/HOST` | From e4ce969beae7870653b549ace671c624df31f53c Mon Sep 17 00:00:00 2001 From: lcnr Date: Mon, 9 May 2022 02:19:43 +0200 Subject: [PATCH 1654/1812] mention `WithOptConstParam` (#1346) --- src/constants.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/constants.md b/src/constants.md index 0b3becec3..4f1027b98 100644 --- a/src/constants.md +++ b/src/constants.md @@ -4,6 +4,14 @@ Constants used in the type system are represented as [`ty::Const`]. The variants of their [`ty::ConstKind`] mostly mirror the variants of [`ty::TyKind`] with the two *additional* variants being `ConstKind::Value` and `ConstKind::Unevaluated`. +## `WithOptConstParam` and dealing with the query system + +To typecheck constants used in the type system, we have to know their expected type. +For const arguments in type dependent paths, e.g. `x.foo::<{ 3 + 4 }>()`, we don't know +the expected type for `{ 3 + 4 }` until we are typechecking the containing function. + +As we may however have to evaluate that constant during this typecheck, we would get a cycle error. +For more details, you can look at [this document](https://hackmd.io/@rust-const-generics/Bk5GHW-Iq). ## Unevaluated constants From 425fa202c849de5031207c10c13c358eba465dac Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 9 May 2022 22:47:50 +0900 Subject: [PATCH 1655/1812] Update date references on parallel-rustc (#1348) --- src/parallel-rustc.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 2ee302d24..1714a56ca 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -1,15 +1,15 @@ # Parallel Compilation -As of September 2021, The only stage of the compiler +As of May 2022, The only stage of the compiler that is already parallel is codegen. The nightly compiler implements query evaluation, -but there is still a lot of work to be done. The lack of parallelism at other stages -also represents an opportunity for improving compiler performance. One can try out the current +but there is still a lot of work to be done. The lack of parallelism at other stages +also represents an opportunity for improving compiler performance. One can try out the current parallel compiler work by enabling it in the `config.toml`. -These next few sections describe where and how parallelism is currently used, +These next few sections describe where and how parallelism is currently used, and the current status of making parallel compilation the default in `rustc`. -The underlying thread-safe data-structures used in the parallel compiler +The underlying thread-safe data-structures used in the parallel compiler can be found in the `rustc_data_structures::sync` module. Some of these data structures use the `parking_lot` crate as well. @@ -23,9 +23,9 @@ There are two underlying thread safe data structures used in code generation: - `MetadataRef` -> [`OwningRef, [u8]>`][OwningRef] - This data structure is specific to `rustc`. -During [monomorphization][monomorphization] the compiler splits up all the code to -be generated into smaller chunks called _codegen units_. These are then generated by -independent instances of LLVM running in parallel. At the end, the linker +During [monomorphization][monomorphization] the compiler splits up all the code to +be generated into smaller chunks called _codegen units_. These are then generated by +independent instances of LLVM running in parallel. At the end, the linker is run to combine all the codegen units together into one binary. This process occurs in the `rustc_codegen_ssa::base` module. @@ -49,20 +49,20 @@ When a query `foo` is evaluated, the cache table for `foo` is locked. - If there *is* another query invocation for the same key in progress, we release the lock, and just block the thread until the other invocation has computed the result we are waiting for. This cannot deadlock because, as - mentioned before, query invocations form a DAG. Some thread will always make + mentioned before, query invocations form a DAG. Some threads will always make progress. ## Rustdoc -As of September 2021, there are still a number of steps +As of May 2022, there are still a number of steps to complete before rustdoc rendering can be made parallel. More details on this issue can be found [here][parallel-rustdoc]. ## Current Status -As of July 2021, work on explicitly parallelizing the +As of May 2022, work on explicitly parallelizing the compiler has stalled. There is a lot of design and correctness work that needs -to be done. +to be done. These are the basic ideas in the effort to make `rustc` parallel: @@ -76,7 +76,7 @@ These are the basic ideas in the effort to make `rustc` parallel: [`rayon`]: https://crates.io/crates/rayon -As of February 2021, much of this effort is on hold due +As of May 2022, much of this effort is on hold due to lack of manpower. We have a working prototype with promising performance gains in many cases. However, there are two blockers: From 0c02acdb6f48f03907a02ea8e537c3272b4fde9f Mon Sep 17 00:00:00 2001 From: Soroush Zare Date: Tue, 10 May 2022 17:15:31 +0430 Subject: [PATCH 1656/1812] Update overview.md (#1351) Fix minor typo --- src/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/overview.md b/src/overview.md index e7ea11e37..a3c2258e8 100644 --- a/src/overview.md +++ b/src/overview.md @@ -94,7 +94,7 @@ of pairing up an impl with each reference to a trait), and [*type checking*]. Type checking is the process of converting the types found in the HIR ([`hir::Ty`]), which represent what the user wrote, into the internal representation used by the compiler ([`Ty<'tcx>`]). -That information is usedto verify the type safety, correctness and +That information is used to verify the type safety, correctness and coherence of the types used in the program. ### MIR lowering From 687f6036caf1a36ad9d970c8d2986889f2cd06c4 Mon Sep 17 00:00:00 2001 From: Jacob Pratt Date: Thu, 12 May 2022 00:53:26 -0400 Subject: [PATCH 1657/1812] Update docs for deprecated attribute (#1338) --- src/stability.md | 33 +++++++++++++++------------------ 1 file changed, 15 insertions(+), 18 deletions(-) diff --git a/src/stability.md b/src/stability.md index 51d849200..3469ce2ba 100644 --- a/src/stability.md +++ b/src/stability.md @@ -121,24 +121,21 @@ Always ping @rust-lang/wg-const-eval if you are adding more ## staged_api -Any crate that uses the `stable`, `unstable`, or `rustc_deprecated` attributes -must include the `#![feature(staged_api)]` attribute on the crate. +Any crate that uses the `stable` or `unstable` attributes must include the +`#![feature(staged_api)]` attribute on the crate. -## rustc_deprecated +## deprecated -The deprecation system shares the same infrastructure as the stable/unstable -attributes. The `rustc_deprecated` attribute is similar to the [`deprecated` -attribute]. It was previously called `deprecated`, but was split off when -`deprecated` was stabilized. The `deprecated` attribute cannot be used in a -`staged_api` crate, `rustc_deprecated` must be used instead. The deprecated -item must also have a `stable` or `unstable` attribute. +Deprecations in the standard library are nearly identical to deprecations in +user code. When `#[deprecated]` is used on an item, it must also have a `stable` +or `unstable `attribute. -`rustc_deprecated` has the following form: +`deprecated` has the following form: ```rust,ignore -#[rustc_deprecated( +#[deprecated( since = "1.38.0", - reason = "explanation for deprecation", + note = "explanation for deprecation", suggestion = "other_function" )] ``` @@ -146,13 +143,13 @@ item must also have a `stable` or `unstable` attribute. The `suggestion` field is optional. If given, it should be a string that can be used as a machine-applicable suggestion to correct the warning. This is typically used when the identifier is renamed, but no other significant changes -are necessary. +are necessary. When the `suggestion` field is used, you need to have +`#![feature(deprecated_suggestion)]` at the crate root. -Another difference from the `deprecated` attribute is that the `since` field is -actually checked against the current version of `rustc`. If `since` is in a -future version, then the `deprecated_in_future` lint is triggered which is -default `allow`, but most of the standard library raises it to a warning with +Another difference from user code is that the `since` field is actually checked +against the current version of `rustc`. If `since` is in a future version, then +the `deprecated_in_future` lint is triggered which is default `allow`, but most +of the standard library raises it to a warning with `#![warn(deprecated_in_future)]`. -[`deprecated` attribute]: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute [blog]: https://www.ralfj.de/blog/2018/07/19/const.html From 77f7fa259fb563818bb3b23c82e1fb26c8ab4b8d Mon Sep 17 00:00:00 2001 From: Waffle Maybe Date: Thu, 12 May 2022 08:56:14 +0400 Subject: [PATCH 1658/1812] Fix configuration names for vscode/r-a (#1352) --- src/building/suggested.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index a6ff65db3..f54ee15f8 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -37,8 +37,8 @@ you can write: Now that we have [seen what the compiler does](./overview.md), let's take a -look at the structure of the contents of the rust-lang/rust repo. +look at the structure of the [`rust-lang/rust`] repository, where the rustc +source code lives. + +[`rust-lang/rust`]: https://github.com/rust-lang/rust + +> You may find it helpful to read the ["Overview of the compiler"](./overview.md) +> chapter, which introduces how the compiler works, before this one. ## Workspace structure @@ -16,29 +22,17 @@ The repository consists of three main directories: - `compiler/` contains the source code for `rustc`. It consists of many crates that together make up the compiler. - + - `library/` contains the standard libraries (`core`, `alloc`, `std`, `proc_macro`, `test`), as well as the Rust runtime (`backtrace`, `rtstartup`, `lang_start`). - + - `src/` contains the source code for rustdoc, clippy, cargo, the build system, - language docs, etc. - -## Standard library - -The standard library crates are all in `library/`. They have intuitive names -like `std`, `core`, `alloc`, etc. There is also `proc_macro`, `test`, and -other runtime libraries. - -This code is fairly similar to most other Rust crates except that it must be -built in a special way because it can use unstable features. + compiler tests, language docs, etc. ## Compiler -> You may find it helpful to read [The Overview Chapter](./overview.md) first, -> which gives an overview of how the compiler works. The crates mentioned in -> this section implement the compiler, and are underneath `compiler/` - +The compiler is implemented in the various `compiler/` crates. The `compiler/` crates all have names starting with `rustc_*`. These are a collection of around 50 interdependent crates ranging in size from tiny to huge. There is also the `rustc` crate which is the actual binary (i.e. the @@ -87,7 +81,7 @@ explanation of these crates here. ### Big picture -The dependency structure is influenced strongly by two main factors: +The dependency structure is influenced by two main factors: 1. Organization. The compiler is a _huge_ codebase; it would be an impossibly large crate. In part, the dependency structure reflects the code structure @@ -101,12 +95,11 @@ At the very bottom of the dependency tree are a handful of crates that are used by the whole compiler (e.g. [`rustc_span`]). The very early parts of the compilation process (e.g. parsing and the AST) depend on only these. -Pretty soon after the AST is constructed, the compiler's [query system][query] -gets set up. The query system is set up in a clever way using function +After the AST is constructed and other early analysis is done, the compiler's [query system][query] +gets set up. The query system is set up in a clever way using function pointers. This allows us to break dependencies between crates, allowing more parallel compilation. - -However, since the query system is defined in [`rustc_middle`], nearly all +The query system is defined in [`rustc_middle`], so nearly all subsequent parts of the compiler depend on this crate. It is a really large crate, leading to long compile times. Some efforts have been made to move stuff out of it with limited success. Another unfortunate side effect is that sometimes @@ -116,7 +109,7 @@ linting functionality is scattered across earlier parts of the crate, [`rustc_lint`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/index.html -More generally, in an ideal world, it seems like there would be fewer, more +Ideally there would be fewer, more cohesive crates, with incremental and parallel compilation making sure compile times stay reasonable. However, our incremental and parallel compilation haven't gotten good enough for that yet, so breaking things into separate crates has @@ -180,6 +173,15 @@ from `src/tools/`, such as [`tidy`] or [`compiletest`]. [bootstch]: ./building/bootstrapping.md +## Standard library + +The standard library crates are all in `library/`. They have intuitive names +like `std`, `core`, `alloc`, etc. There is also `proc_macro`, `test`, and +other runtime libraries. + +This code is fairly similar to most other Rust crates except that it must be +built in a special way because it can use unstable features. + ## Other There are a lot of other things in the `rust-lang/rust` repo that are related From b389adccc14319041be7ade3ad81f36876bf0fb9 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 16 May 2022 23:36:40 +0900 Subject: [PATCH 1661/1812] Replace a broken YouTube link (#1295) --- src/mir/dataflow.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index 6fe8d6aa5..7fe807d37 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -17,8 +17,10 @@ some basic terminology, such as "transfer function", "fixpoint" and "lattice". If you're unfamiliar with these terms, or if you want a quick refresher, [*Static Program Analysis*] by Anders Møller and Michael I. Schwartzbach is an excellent, freely available textbook. For those who prefer audiovisual -learning, the Goethe University Frankfurt has published a series of short -[lectures on YouTube][goethe] in English that are very approachable. +learning, we previously recommended a series of short lectures +by the Goethe University Frankfurt on YouTube, but it has been deleted for some reasons. +See [this PR][pr-1295] for the context and [this comment][pr-1295-comment] +for the alternative lectures. ## Defining a Dataflow Analysis @@ -229,6 +231,7 @@ the example below: [`apply_call_return_effect`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/trait.Analysis.html#tymethod.apply_call_return_effect [`into_engine`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/trait.Analysis.html#method.into_engine [`lattice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/lattice/index.html -[goethe]: https://www.youtube.com/watch?v=NVBQSR_HdL0&list=PL_sGR8T76Y58l3Gck3ZwIIHLWEmXrOLV_&index=2 +[pr-1295]: https://github.com/rust-lang/rustc-dev-guide/pull/1295 +[pr-1295-comment]: https://github.com/rust-lang/rustc-dev-guide/pull/1295#issuecomment-1118131294 [lattice]: https://en.wikipedia.org/wiki/Lattice_(order) [wiki]: https://en.wikipedia.org/wiki/Data-flow_analysis#Basic_principles From 0b2c9db969cbb750e5253d6e5b94db10be515e49 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 17 May 2022 07:54:45 +0900 Subject: [PATCH 1662/1812] Update some links and docs (#1340) --- src/borrow_check/region_inference.md | 7 +++---- src/building/suggested.md | 8 ++++---- src/contributing.md | 6 +++--- src/git.md | 2 +- src/macro-expansion.md | 24 +++++++++++++----------- src/query.md | 2 +- src/tests/running.md | 2 +- 7 files changed, 26 insertions(+), 25 deletions(-) diff --git a/src/borrow_check/region_inference.md b/src/borrow_check/region_inference.md index cfb32bf07..330c079b9 100644 --- a/src/borrow_check/region_inference.md +++ b/src/borrow_check/region_inference.md @@ -78,13 +78,12 @@ The value of a region can be thought of as a **set**. This set contains all points in the MIR where the region is valid along with any regions that are outlived by this region (e.g. if `'a: 'b`, then `end('b)` is in the set for `'a`); we call the domain of this set a `RegionElement`. In the code, the value -for all regions is maintained in [the -`rustc_mir::borrow_check::nll::region_infer` module][ri]. For each region we -maintain a set storing what elements are present in its value (to make this +for all regions is maintained in [the `rustc_borrowck::region_infer` module][ri]. +For each region we maintain a set storing what elements are present in its value (to make this efficient, we give each kind of element an index, the `RegionElementIndex`, and use sparse bitsets). -[ri]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_mir/src/borrow_check/region_infer/ +[ri]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_borrowck/src/region_infer The kinds of region elements are as follows: diff --git a/src/building/suggested.md b/src/building/suggested.md index f54ee15f8..196ff5fe8 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -3,16 +3,16 @@ The full bootstrapping process takes quite a while. Here are some suggestions to make your life easier. -## Installing a pre-commit hook +## Installing a pre-push hook CI will automatically fail your build if it doesn't pass `tidy`, our internal tool for ensuring code quality. If you'd like, you can install a [Git hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) -that will automatically run `./x.py test tidy --bless` on each commit, to ensure +that will automatically run `./x.py test tidy --bless` on each push, to ensure your code is up to par. If you decide later that this behavior is -undesirable, you can delete the `pre-commit` file in `.git/hooks`. +undesirable, you can delete the `pre-push` file in `.git/hooks`. -A prebuilt git hook lives at [`src/etc/pre-commit.sh`](https://github.com/rust-lang/rust/blob/master/src/etc/pre-commit.sh) which can be copied into your `.git/hooks` folder as `pre-commit` (without the `.sh` extension!). +A prebuilt git hook lives at [`src/etc/pre-push.sh`](https://github.com/rust-lang/rust/blob/master/src/etc/pre-push.sh) which can be copied into your `.git/hooks` folder as `pre-push` (without the `.sh` extension!). You can also install the hook as a step of running `./x.py setup`! diff --git a/src/contributing.md b/src/contributing.md index 3fe0948cc..48d8b2d15 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -67,8 +67,8 @@ where contributors push changes to their personal fork and create pull requests bring those changes into the source repository. We have more info about how to use git when contributing to Rust under [the git section](./git.md). -[about-pull-requests]: https://help.github.com/articles/about-pull-requests/ -[development-models]: https://help.github.com/articles/about-collaborative-development-models/ +[about-pull-requests]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests +[development-models]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model ### r? @@ -177,7 +177,7 @@ particularly during rebasing, citing the issue number in the commit can "spam" the issue in question. [labeling]: ./rustbot.md#issue-relabeling -[closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords +[closing-keywords]: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue ### External Dependencies (subtree) diff --git a/src/git.md b/src/git.md index d5c37f82d..e55dbf858 100644 --- a/src/git.md +++ b/src/git.md @@ -18,7 +18,7 @@ more in depth [book from Git]. [book from Git]: https://git-scm.com/book/en/v2/ [atlassian-git]: https://www.atlassian.com/git/tutorials/what-is-version-control -[documentation]: https://docs.github.com/en/github/getting-started-with-github/set-up-git +[documentation]: https://docs.github.com/en/get-started/quickstart/set-up-git [guides]: https://guides.github.com/introduction/git-handbook/ ## Prerequisites diff --git a/src/macro-expansion.md b/src/macro-expansion.md index e3b5a27e6..840bfabe8 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -227,7 +227,7 @@ only within the macro (i.e. it should not be visible outside the macro). [code_dir]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_expand/src/mbe [code_mp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser [code_mr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_rules -[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/fn.parse_tt.html +[code_parse_int]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/struct.TtParser.html#method.parse_tt [parsing]: ./the-parser.html The context is attached to AST nodes. All AST nodes generated by macros have @@ -503,9 +503,10 @@ The interface of the macro parser is as follows (this is slightly simplified): ```rust,ignore fn parse_tt( - parser: &mut Cow, - ms: &[TokenTree], -) -> NamedParseResult + &mut self, + parser: &mut Cow<'_, Parser<'_>>, + matcher: &[MatcherLoc] +) -> ParseResult ``` We use these items in macro parser: @@ -515,20 +516,20 @@ We use these items in macro parser: ask the MBE parser to parse. We will consume the raw stream of tokens and output a binding of metavariables to corresponding token trees. The parsing session can be used to report parser errors. -- `ms` a _matcher_. This is a sequence of token trees that we want to match - the token stream against. +- `matcher` is a sequence of `MatcherLoc`s that we want to match + the token stream against. They're converted from token trees before matching. In the analogy of a regex parser, the token stream is the input and we are matching it -against the pattern `ms`. Using our examples, the token stream could be the stream of -tokens containing the inside of the example invocation `print foo`, while `ms` +against the pattern `matcher`. Using our examples, the token stream could be the stream of +tokens containing the inside of the example invocation `print foo`, while `matcher` might be the sequence of token (trees) `print $mvar:ident`. -The output of the parser is a `NamedParseResult`, which indicates which of +The output of the parser is a [`ParseResult`], which indicates which of three cases has occurred: -- Success: the token stream matches the given matcher `ms`, and we have produced a binding +- Success: the token stream matches the given `matcher`, and we have produced a binding from metavariables to the corresponding token trees. -- Failure: the token stream does not match `ms`. This results in an error message such as +- Failure: the token stream does not match `matcher`. This results in an error message such as "No rule expected token _blah_". - Error: some fatal error has occurred _in the parser_. For example, this happens if there are more than one pattern match, since that indicates @@ -607,6 +608,7 @@ Because the Rust ABI is unstable, we use the C ABI for this conversion. [stablets]: https://doc.rust-lang.org/proc_macro/struct.TokenStream.html [pm]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/proc_macro/index.html [pms]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/proc_macro_server/index.html +[`ParseResult`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/mbe/macro_parser/enum.ParseResult.html TODO: more here. [#1160](https://github.com/rust-lang/rustc-dev-guide/issues/1160) diff --git a/src/query.md b/src/query.md index 6e02bfc7b..95e570dfc 100644 --- a/src/query.md +++ b/src/query.md @@ -37,7 +37,7 @@ will in turn demand information about that crate, starting from the actual parsing. Although this vision is not fully realized, large sections of the -compiler (for example, generating [MIR](./mir/)) currently work exactly like this. +compiler (for example, generating [MIR](./mir/index.md)) currently work exactly like this. [^incr-comp-detail]: The ["Incremental Compilation in Detail](queries/incremental-compilation-in-detail.md) chapter gives a more in-depth description of what queries are and how they work. diff --git a/src/tests/running.md b/src/tests/running.md index 2e823c0ed..6e15cb191 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -211,7 +211,7 @@ See [Compare modes](compiletest.md#compare-modes) for more details. Sometimes it's easier and faster to just run the test by hand. Most tests are just `rs` files, so after -[creating a rustup toolchain](/building/how-to-build-and-run.html#creating-a-rustup-toolchain), +[creating a rustup toolchain](../building/how-to-build-and-run.md#creating-a-rustup-toolchain), you can do something like: ```bash From 12a2e08f727086871eb0ca9b3af7d8cb2024c3e5 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 20 May 2022 14:37:01 +0200 Subject: [PATCH 1663/1812] make sentence more simple (#1353) --- src/mir/dataflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md index 7fe807d37..ce4a86a23 100644 --- a/src/mir/dataflow.md +++ b/src/mir/dataflow.md @@ -18,7 +18,7 @@ If you're unfamiliar with these terms, or if you want a quick refresher, [*Static Program Analysis*] by Anders Møller and Michael I. Schwartzbach is an excellent, freely available textbook. For those who prefer audiovisual learning, we previously recommended a series of short lectures -by the Goethe University Frankfurt on YouTube, but it has been deleted for some reasons. +by the Goethe University Frankfurt on YouTube, but it has since been deleted. See [this PR][pr-1295] for the context and [this comment][pr-1295-comment] for the alternative lectures. From 0cd9842821d4efa83b29bb1fde2c668963d8a2e6 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Fri, 20 May 2022 20:53:51 -0700 Subject: [PATCH 1664/1812] Add note about patching dependencies and warnings. (#1354) --- src/building/new-target.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/building/new-target.md b/src/building/new-target.md index b5fc2cb0a..f216ed0b7 100644 --- a/src/building/new-target.md +++ b/src/building/new-target.md @@ -104,6 +104,12 @@ index be15e50e2bc..4fb1248ba99 100644 After this, run `cargo update -p libc` to update the lockfiles. +Beware that if you patch to a local `path` dependency, this will enable +warnings for that dependency. Some dependencies are not warning-free, and due +to the `deny-warnings` setting in `config.toml`, the build may suddenly start +to fail. To work around the warnings, you may want to disable `deny-warnings` +in the config, or modify the dependency to remove the warnings. + [`libc`]: https://crates.io/crates/libc [`cc`]: https://crates.io/crates/cc [patch]: https://doc.rust-lang.org/stable/cargo/reference/overriding-dependencies.html#the-patch-section From 2ba653e32e822f9541b3d54c3f8e4d4f710aec58 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Wed, 25 May 2022 08:01:26 +0900 Subject: [PATCH 1665/1812] Exclude `tomlee.co` from link-checking (#1356) https://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/ returns 404 on CI even though it's not actually 404. So, that doesn't return any useful result, let's ignore it. Also, formatted the exclude list for readability. --- book.toml | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/book.toml b/book.toml index 336e5a369..8b9f57594 100644 --- a/book.toml +++ b/book.toml @@ -21,7 +21,18 @@ level = 0 [output.linkcheck] command = "ci/linkcheck.sh" follow-web-links = true -exclude = [ "crates\\.io", "gcc\\.godbolt\\.org", "youtube\\.com", "youtu\\.be", "dl\\.acm\\.org", "cs\\.bgu\\.ac\\.il", "www\\.amazon\\.com", "www\\.rustaceans\\.org", "play\\.rust-lang\\.org" ] +exclude = [ + "crates\\.io", + "gcc\\.godbolt\\.org", + "youtube\\.com", + "youtu\\.be", + "dl\\.acm\\.org", + "cs\\.bgu\\.ac\\.il", + "www\\.amazon\\.com", + "www\\.rustaceans\\.org", + "play\\.rust-lang\\.org", + "tomlee\\.co" +] cache-timeout = 86400 warning-policy = "error" From 5e268730e02ab8fcbf82a5d3a899c56e2ad9b72a Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Tue, 24 May 2022 18:49:07 +0900 Subject: [PATCH 1666/1812] Fix some wording on the "Incremental Compilation In Detail" page --- src/queries/incremental-compilation-in-detail.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/queries/incremental-compilation-in-detail.md b/src/queries/incremental-compilation-in-detail.md index f81e02d28..dc196e490 100644 --- a/src/queries/incremental-compilation-in-detail.md +++ b/src/queries/incremental-compilation-in-detail.md @@ -58,7 +58,7 @@ The story is a bit different for `type_check_item(foo)`: We again walk the edges and already know that `type_of(foo)` is fine. Then we get to `type_of(bar)` which we have not checked yet, so we walk the edges of `type_of(bar)` and encounter `Hir(bar)` which *has* changed. Consequently -the result of `type_of(bar)` might yield a different same result than what we +the result of `type_of(bar)` might yield a different result than what we have in the cache and, transitively, the result of `type_check_item(foo)` might have changed too. We thus re-run `type_check_item(foo)`, which in turn will re-run `type_of(bar)`, which will yield an up-to-date result @@ -329,7 +329,7 @@ up its dependencies (i.e. also dep-nodes in the previous graph) and continue wit the rest of the try-mark-green algorithm. The next interesting thing happens when we successfully marked the node as green. At that point we copy the node and the edges to its dependencies from the old graph into the new graph. We -have to do this because the new dep-graph cannot not acquire the +have to do this because the new dep-graph cannot acquire the node and edges via the regular dependency tracking. The tracking system can only record edges while actually running a query -- but running the query, although we have the result already cached, is exactly what we want to avoid. From 554c00e4805df7f7bffac7db408437d62d6dfb9a Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 21 May 2022 17:05:08 +0900 Subject: [PATCH 1667/1812] Cleanup rustdoc-internals --- src/rustdoc-internals.md | 33 ++++++++------------------------- 1 file changed, 8 insertions(+), 25 deletions(-) diff --git a/src/rustdoc-internals.md b/src/rustdoc-internals.md index ccf0fcc5f..1050c259b 100644 --- a/src/rustdoc-internals.md +++ b/src/rustdoc-internals.md @@ -32,7 +32,7 @@ is the `impl Clean for visit_ast::RustdocVisitor`, which is called by `run_core` above. You see, I actually lied a little earlier: There's another AST transformation -that happens before the events in `clean/mod.rs`. In `visit_ast.rs` is the +that happens before the events in `clean/mod.rs`. In `visit_ast.rs` is the type `RustdocVisitor`, which *actually* crawls a `rustc_hir::Crate` to get the first intermediate representation, defined in `doctree.rs`. This pass is mainly to get a few intermediate wrappers around the HIR types and to process visibility @@ -52,10 +52,10 @@ which describe the publicly-documentable items in the target crate. Before moving on to the next major step, a few important "passes" occur over the documentation. These do things like combine the separate "attributes" into -a single string and strip leading whitespace to make the document easier on the -markdown parser, or drop items that are not public or deliberately hidden with -`#[doc(hidden)]`. These are all implemented in the `passes/` directory, one -file per pass. By default, all of these passes are run on a crate, but the ones +a single string to make the document easier on the markdown parser, +or drop items that are not public or deliberately hidden with `#[doc(hidden)]`. +These are all implemented in the `passes/` directory, one file per pass. +By default, all of these passes are run on a crate, but the ones regarding dropping private/hidden items can be bypassed by passing `--document-private-items` to rustdoc. Note that unlike the previous set of AST transformations, the passes are run on the _cleaned_ crate. @@ -66,7 +66,7 @@ these passes, please let us know!) [44136]: https://github.com/rust-lang/rust/issues/44136 -Here is the list of passes as of October 2021: +Here is the list of passes as of May 2022: - `calculate-doc-coverage` calculates information used for the `--show-coverage` flag. @@ -74,7 +74,7 @@ Here is the list of passes as of October 2021: - `check-bare-urls` detects links that are not linkified, e.g., in Markdown such as `Go to https://example.com/.` It suggests wrapping the link with angle brackets: `Go to .` to linkify it. This is the code behind the `rustdoc::bare_urls` lint. + date: 2022-05 --> `rustdoc::bare_urls` lint. - `check-code-block-syntax` validates syntax inside Rust code blocks (```rust) @@ -84,7 +84,7 @@ Here is the list of passes as of October 2021: - `check-invalid-html-tags` detects invalid HTML (like an unclosed ``) in doc comments. -- `collect-intra-doc-links` resolves [intra-doc links](https://doc.rust-lang.org/rustdoc/linking-to-items-by-name.html). +- `collect-intra-doc-links` resolves [intra-doc links](https://doc.rust-lang.org/nightly/rustdoc/write-documentation/linking-to-items-by-name.html). - `collect-trait-impls` collects trait impls for each item in the crate. For example, if we define a struct that implements a trait, this pass will note @@ -102,23 +102,6 @@ Here is the list of passes as of October 2021: from the output. `strip-private` implies `strip-priv-imports`. Basically, the goal is to remove items that are not relevant for public documentation. -- `unindent-comments` removes excess indentation on comments in order for the - Markdown to be parsed correctly. This is necessary because the convention for - writing documentation is to provide a space between the `///` or `//!` marker - and the doc text, but Markdown is whitespace-sensitive. For example, a block - of text with four-space indentation is parsed as a code block, so if we didn't - unindent comments, these list items - - ```rust,ignore - /// A list: - /// - /// - Foo - /// - Bar - ``` - - would be parsed as if they were in a code block, which is likely not what the - user intended. - There is also a `stripper` module in `passes/`, but it is a collection of utility functions for the `strip-*` passes and is not a pass itself. From 669262932aaa08e518785935901c62c019d93100 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Sat, 28 May 2022 12:24:55 +0900 Subject: [PATCH 1668/1812] Triage some date references related to traits --- src/traits/chalk.md | 11 ++++++----- src/traits/resolution.md | 2 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/src/traits/chalk.md b/src/traits/chalk.md index db3c19a38..d4045c460 100644 --- a/src/traits/chalk.md +++ b/src/traits/chalk.md @@ -1,13 +1,14 @@ # Chalk-based trait solving [Chalk][chalk] is an experimental trait solver for Rust that is (as of January 2021) under development by the [Traits Working -Group][wg]. Its goal is to enable a lot of trait system features and bug fixes +date: 2022-05 --> May 2022) under development by the [Types team]. +Its goal is to enable a lot of trait system features and bug fixes that are hard to implement (e.g. GATs or specialization). If you would like to -help in hacking on the new solver, you will find instructions for getting -involved in the [Traits Working Group tracking issue][wg]. +help in hacking on the new solver, drop by on the rust-lang Zulip in the [`#t-types`] +stream and say hello! -[wg]: https://github.com/rust-lang/rust/issues/48416 +[Types team]: https://github.com/rust-lang/types-team +[`#t-types`]: https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types The new-style trait solver is based on the work done in [chalk][chalk]. Chalk recasts Rust's trait system explicitly in terms of logic programming. It does diff --git a/src/traits/resolution.md b/src/traits/resolution.md index 70b53e910..c22ee6de6 100644 --- a/src/traits/resolution.md +++ b/src/traits/resolution.md @@ -120,7 +120,7 @@ the obligation contains unbound inference variables. The subroutines that decide whether a particular impl/where-clause/etc applies to a particular obligation are collectively referred to as the process of -_matching_. As of January 2021, this amounts to unifying +_matching_. As of May 2022, this amounts to unifying the `Self` types, but in the future we may also recursively consider some of the nested obligations, in the case of an impl. From a206009f26e664f549a3b6f90dde2f3ce5ffe543 Mon Sep 17 00:00:00 2001 From: Yuki Okushi Date: Mon, 2 May 2022 08:19:20 +0900 Subject: [PATCH 1669/1812] Update rustc-driver related examples --- examples/rustc-driver-example.rs | 7 ++++--- examples/rustc-driver-getting-diagnostics.rs | 4 ++-- examples/rustc-driver-interacting-with-the-ast.rs | 9 +++++---- src/rustc-driver-getting-diagnostics.md | 4 ++-- src/rustc-driver-interacting-with-the-ast.md | 9 +++++---- src/rustc-driver.md | 2 +- 6 files changed, 19 insertions(+), 16 deletions(-) diff --git a/examples/rustc-driver-example.rs b/examples/rustc-driver-example.rs index 7177a2868..8a5d880fa 100644 --- a/examples/rustc-driver-example.rs +++ b/examples/rustc-driver-example.rs @@ -1,9 +1,9 @@ #![feature(rustc_private)] // NOTE: For the example to compile, you will need to first run the following: -// rustup component add rustc-dev +// rustup component add rustc-dev llvm-tools-preview -// version: 1.61.0-nightly (68369a041 2022-02-22) +// version: 1.62.0-nightly (7c4b47696 2022-04-30) extern crate rustc_error_codes; extern crate rustc_errors; @@ -72,7 +72,8 @@ fn main() { println!("{:#?}", parse); // Analyze the program and inspect the types of definitions. queries.global_ctxt().unwrap().take().enter(|tcx| { - for item in tcx.hir().items() { + for id in tcx.hir().items() { + let item = tcx.hir().item(id); match item.kind { rustc_hir::ItemKind::Static(_, _, _) | rustc_hir::ItemKind::Fn(_, _, _) => { let name = item.ident; diff --git a/examples/rustc-driver-getting-diagnostics.rs b/examples/rustc-driver-getting-diagnostics.rs index c25695dd0..3bb0d5450 100644 --- a/examples/rustc-driver-getting-diagnostics.rs +++ b/examples/rustc-driver-getting-diagnostics.rs @@ -1,9 +1,9 @@ #![feature(rustc_private)] // NOTE: For the example to compile, you will need to first run the following: -// rustup component add rustc-dev +// rustup component add rustc-dev llvm-tools-preview -// version: 1.61.0-nightly (68369a041 2022-02-22) +// version: 1.62.0-nightly (7c4b47696 2022-04-30) extern crate rustc_error_codes; extern crate rustc_errors; diff --git a/examples/rustc-driver-interacting-with-the-ast.rs b/examples/rustc-driver-interacting-with-the-ast.rs index c942ac324..a0110f82d 100644 --- a/examples/rustc-driver-interacting-with-the-ast.rs +++ b/examples/rustc-driver-interacting-with-the-ast.rs @@ -1,9 +1,9 @@ #![feature(rustc_private)] // NOTE: For the example to compile, you will need to first run the following: -// rustup component add rustc-dev llvm-tools-preview +// rustup component add rustc-dev llvm-tools-preview -// version: 1.61.0-nightly (68369a041 2022-02-22) +// version: 1.62.0-nightly (7c4b47696 2022-04-30) extern crate rustc_ast_pretty; extern crate rustc_error_codes; @@ -66,7 +66,8 @@ fn main() { // Every compilation contains a single crate. let hir_krate = tcx.hir(); // Iterate over the top-level items in the crate, looking for the main function. - for item in hir_krate.items() { + for id in hir_krate.items() { + let item = hir_krate.item(id); // Use pattern-matching to find a specific node inside the main function. if let rustc_hir::ItemKind::Fn(_, _, body_id) = item.kind { let expr = &tcx.hir().body(body_id).value; @@ -76,7 +77,7 @@ fn main() { let hir_id = expr.hir_id; // hir_id identifies the string "Hello, world!" let def_id = tcx.hir().local_def_id(item.hir_id()); // def_id identifies the main function let ty = tcx.typeck(def_id).node_type(hir_id); - println!("{:?}: {:?}", expr, ty); // prints expr(HirId { owner: DefIndex(3), local_id: 4 }: "Hello, world!"): &'static str + println!("{:?}: {:?}", expr, ty); } } } diff --git a/src/rustc-driver-getting-diagnostics.md b/src/rustc-driver-getting-diagnostics.md index fa5ce0750..b3f18a67e 100644 --- a/src/rustc-driver-getting-diagnostics.md +++ b/src/rustc-driver-getting-diagnostics.md @@ -7,7 +7,7 @@ To get diagnostics from the compiler, configure `rustc_interface::Config` to output diagnostic to a buffer, and run `TyCtxt.analysis`. The following should be compiled -with `nightly-2021-03-28` (See [here][example] +with `nightly-2021-04-30` (See [here][example] for the complete example): [example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-getting-diagnostics.rs @@ -35,7 +35,7 @@ rustc_interface::run_compiler(config, |compiler| { compiler.enter(|queries| { queries.global_ctxt().unwrap().take().enter(|tcx| { // Run the analysis phase on the local crate to trigger the type error. - tcx.analysis(rustc_hir::def_id::LOCAL_CRATE); + let _ = tcx.analysis(()); }); }); }); diff --git a/src/rustc-driver-interacting-with-the-ast.md b/src/rustc-driver-interacting-with-the-ast.md index 7cb53187b..1ec9c1c32 100644 --- a/src/rustc-driver-interacting-with-the-ast.md +++ b/src/rustc-driver-interacting-with-the-ast.md @@ -5,7 +5,7 @@ ## Getting the type of an expression To get the type of an expression, use the `global_ctxt` to get a `TyCtxt`. -The following should be compiled with `nightly-2021-03-28` +The following should be compiled with `nightly-2022-04-30` (see [here][example] for the complete example): [example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-interacting-with-the-ast.rs @@ -24,9 +24,10 @@ rustc_interface::run_compiler(config, |compiler| { // Analyze the crate and inspect the types under the cursor. queries.global_ctxt().unwrap().take().enter(|tcx| { // Every compilation contains a single crate. - let hir_krate = tcx.hir().krate(); + let hir_krate = tcx.hir(); // Iterate over the top-level items in the crate, looking for the main function. - for (_, item) in &hir_krate.items { + for id in hir_krate.items() { + let item = hir_krate.item(id); // Use pattern-matching to find a specific node inside the main function. if let rustc_hir::ItemKind::Fn(_, _, body_id) = item.kind { let expr = &tcx.hir().body(body_id).value; @@ -36,7 +37,7 @@ rustc_interface::run_compiler(config, |compiler| { let hir_id = expr.hir_id; // hir_id identifies the string "Hello, world!" let def_id = tcx.hir().local_def_id(item.hir_id()); // def_id identifies the main function let ty = tcx.typeck(def_id).node_type(hir_id); - println!("{:?}: {:?}", expr, ty); // prints expr(HirId { owner: DefIndex(3), local_id: 4 }: "Hello, world!"): &'static str + println!("{:?}: {:?}", expr, ty); } } } diff --git a/src/rustc-driver.md b/src/rustc-driver.md index 2cffba42c..7250c852c 100644 --- a/src/rustc-driver.md +++ b/src/rustc-driver.md @@ -7,7 +7,7 @@ using the interface defined in the [`rustc_interface`] crate. The `rustc_interface` crate provides external users with an (unstable) API for running code at particular times during the compilation process, allowing third parties to effectively use `rustc`'s internals as a library for -analysing a crate or emulating the compiler in-process (e.g. the RLS or rustdoc). +analyzing a crate or emulating the compiler in-process (e.g. the RLS or rustdoc). For those using `rustc` as a library, the [`rustc_interface::run_compiler()`][i_rc] function is the main entrypoint to the compiler. It takes a configuration for the compiler From 4d43651c90ac1b9ba3f02def89b331171954485b Mon Sep 17 00:00:00 2001 From: Andrew Dona-Couch -- GitHub drop ICE Date: Mon, 6 Jun 2022 19:37:50 -0400 Subject: [PATCH 1670/1812] Clarify cargo fallback behavior for rustup link (#1273) --- src/building/how-to-build-and-run.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index dd997c814..9ef43e341 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -233,6 +233,12 @@ The rustup toolchain points to the specified toolchain compiled in your `build` so the rustup toolchain will be updated whenever `x.py build` or `x.py test` are run for that toolchain/stage. +**Note:** the toolchain we've built does not include `cargo`. In this case, `rustup` will +fall back to using `cargo` from the installed `nightly`, `beta`, or `stable` toolchain +(in that order). If you need to use unstable `cargo` flags, be sure to run +`rustup install nightly` if you haven't already. See the +[rustup documentation on custom toolchains](https://rust-lang.github.io/rustup/concepts/toolchains.html#custom-toolchains). + ## Other `x.py` commands Here are a few other useful `x.py` commands. We'll cover some of them in detail From 72a3895d6107fedf3c41152a9ce79d250eaa2e2b Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 7 Jun 2022 08:40:42 +0900 Subject: [PATCH 1671/1812] Bump regex from 1.4.3 to 1.5.5 in /ci/date-check (#1364) Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- ci/date-check/Cargo.lock | 34 ++++++++++------------------------ 1 file changed, 10 insertions(+), 24 deletions(-) diff --git a/ci/date-check/Cargo.lock b/ci/date-check/Cargo.lock index 296a132d4..00fa3def8 100644 --- a/ci/date-check/Cargo.lock +++ b/ci/date-check/Cargo.lock @@ -1,10 +1,12 @@ # This file is automatically @generated by Cargo. # It is not intended for manual editing. +version = 3 + [[package]] name = "aho-corasick" -version = "0.7.15" +version = "0.7.18" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "7404febffaa47dac81aa44dba71523c9d069b1bdc50a77db41195149e17f68e5" +checksum = "1e37cfd5e7657ada45f742d6e99ca5788580b5c529dc78faf11ece6dc702656f" dependencies = [ "memchr", ] @@ -43,12 +45,6 @@ version = "0.3.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "9b919933a397b79c37e33b77bb2aa3dc8eb6e165ad809e58ff75bc7db2e34574" -[[package]] -name = "lazy_static" -version = "1.4.0" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "e2abad23fbc42b3700f2f279844dc832adb2b2eb069b2df918f455c4e18cc646" - [[package]] name = "libc" version = "0.2.82" @@ -57,9 +53,9 @@ checksum = "89203f3fba0a3795506acaad8ebce3c80c0af93f994d5a1d7a0b1eeb23271929" [[package]] name = "memchr" -version = "2.3.4" +version = "2.5.0" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "0ee1c47aaa256ecabcaea351eae4a9b01ef39ed810004e298d2511ed284b1525" +checksum = "2dffe52ecf27772e601905b7522cb4ef790d2cc203488bbd0e2fe85fcb74566d" [[package]] name = "num-integer" @@ -82,30 +78,20 @@ dependencies = [ [[package]] name = "regex" -version = "1.4.3" +version = "1.5.5" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "d9251239e129e16308e70d853559389de218ac275b515068abc96829d05b948a" +checksum = "1a11647b6b25ff05a515cb92c365cec08801e83423a235b51e231e1808747286" dependencies = [ "aho-corasick", "memchr", "regex-syntax", - "thread_local", ] [[package]] name = "regex-syntax" -version = "0.6.22" +version = "0.6.26" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "b5eb417147ba9860a96cfe72a0b93bf88fee1744b5636ec99ab20c1aa9376581" - -[[package]] -name = "thread_local" -version = "1.1.0" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "bb9bc092d0d51e76b2b19d9d85534ffc9ec2db959a2523cdae0697e2972cd447" -dependencies = [ - "lazy_static", -] +checksum = "49b3de9ec5dc0a3417da371aab17d729997c15010e7fd24ff707773a33bddb64" [[package]] name = "time" From 438364838ad8b715abba3deb757ee9e9ece94a4e Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 7 Jun 2022 01:42:07 +0200 Subject: [PATCH 1672/1812] improve rustc_interface examples a little (#1362) --- examples/rustc-driver-example.rs | 25 +++++++++++-------- examples/rustc-driver-getting-diagnostics.rs | 11 +++++--- .../rustc-driver-interacting-with-the-ast.rs | 16 +++++++----- src/rustc-driver-getting-diagnostics.md | 2 +- src/rustc-driver-interacting-with-the-ast.md | 2 +- 5 files changed, 35 insertions(+), 21 deletions(-) diff --git a/examples/rustc-driver-example.rs b/examples/rustc-driver-example.rs index 8a5d880fa..4203fe96a 100644 --- a/examples/rustc-driver-example.rs +++ b/examples/rustc-driver-example.rs @@ -13,13 +13,12 @@ extern crate rustc_interface; extern crate rustc_session; extern crate rustc_span; +use std::{path, process, str}; + use rustc_errors::registry; use rustc_hash::{FxHashMap, FxHashSet}; use rustc_session::config::{self, CheckCfg}; use rustc_span::source_map; -use std::path; -use std::process; -use std::str; fn main() { let out = process::Command::new("rustc") @@ -38,9 +37,14 @@ fn main() { crate_cfg: FxHashSet::default(), // FxHashSet<(String, Option)> crate_check_cfg: CheckCfg::default(), // CheckCfg input: config::Input::Str { - name: source_map::FileName::Custom("main.rs".to_string()), - input: "static HELLO: &str = \"Hello, world!\"; fn main() { println!(\"{}\", HELLO); }" - .to_string(), + name: source_map::FileName::Custom("main.rs".into()), + input: r#" +static HELLO: &str = "Hello, world!"; +fn main() { + println!("{HELLO}"); +} +"# + .into(), }, input_path: None, // Option output_dir: None, // Option @@ -69,16 +73,17 @@ fn main() { compiler.enter(|queries| { // Parse the program and print the syntax tree. let parse = queries.parse().unwrap().take(); - println!("{:#?}", parse); + println!("{parse:?}"); // Analyze the program and inspect the types of definitions. queries.global_ctxt().unwrap().take().enter(|tcx| { for id in tcx.hir().items() { - let item = tcx.hir().item(id); + let hir = tcx.hir(); + let item = hir.item(id); match item.kind { rustc_hir::ItemKind::Static(_, _, _) | rustc_hir::ItemKind::Fn(_, _, _) => { let name = item.ident; - let ty = tcx.type_of(tcx.hir().local_def_id(item.hir_id())); - println!("{:?}:\t{:?}", name, ty) + let ty = tcx.type_of(hir.local_def_id(item.hir_id())); + println!("{name:?}:\t{ty:?}") } _ => (), } diff --git a/examples/rustc-driver-getting-diagnostics.rs b/examples/rustc-driver-getting-diagnostics.rs index 3bb0d5450..1d3a4034e 100644 --- a/examples/rustc-driver-getting-diagnostics.rs +++ b/examples/rustc-driver-getting-diagnostics.rs @@ -57,8 +57,13 @@ fn main() { }, // This program contains a type error. input: config::Input::Str { - name: source_map::FileName::Custom("main.rs".to_string()), - input: "fn main() { let x: &str = 1; }".to_string(), + name: source_map::FileName::Custom("main.rs".into()), + input: " +fn main() { + let x: &str = 1; +} +" + .into(), }, // Redirect the diagnostic output of the compiler to a buffer. diagnostic_output: rustc_session::DiagnosticOutput::Raw(Box::from(DiagnosticSink( @@ -87,5 +92,5 @@ fn main() { }); // Read buffered diagnostics. let diagnostics = String::from_utf8(buffer.lock().unwrap().clone()).unwrap(); - println!("{}", diagnostics); + println!("{diagnostics}"); } diff --git a/examples/rustc-driver-interacting-with-the-ast.rs b/examples/rustc-driver-interacting-with-the-ast.rs index a0110f82d..231994a97 100644 --- a/examples/rustc-driver-interacting-with-the-ast.rs +++ b/examples/rustc-driver-interacting-with-the-ast.rs @@ -14,13 +14,12 @@ extern crate rustc_interface; extern crate rustc_session; extern crate rustc_span; +use std::{path, process, str}; + use rustc_ast_pretty::pprust::item_to_string; use rustc_errors::registry; use rustc_session::config::{self, CheckCfg}; use rustc_span::source_map; -use std::path; -use std::process; -use std::str; fn main() { let out = process::Command::new("rustc") @@ -36,8 +35,13 @@ fn main() { }, input: config::Input::Str { name: source_map::FileName::Custom("main.rs".to_string()), - input: "fn main() { let message = \"Hello, world!\"; println!(\"{}\", message); }" - .to_string(), + input: r#" +fn main() { + let message = "Hello, World!"; + println!("{message}"); +} +"# + .to_string(), }, diagnostic_output: rustc_session::DiagnosticOutput::Default, crate_cfg: rustc_hash::FxHashSet::default(), @@ -77,7 +81,7 @@ fn main() { let hir_id = expr.hir_id; // hir_id identifies the string "Hello, world!" let def_id = tcx.hir().local_def_id(item.hir_id()); // def_id identifies the main function let ty = tcx.typeck(def_id).node_type(hir_id); - println!("{:?}: {:?}", expr, ty); + println!("{expr:#?}: {ty:?}"); } } } diff --git a/src/rustc-driver-getting-diagnostics.md b/src/rustc-driver-getting-diagnostics.md index b3f18a67e..a7251c2f0 100644 --- a/src/rustc-driver-getting-diagnostics.md +++ b/src/rustc-driver-getting-diagnostics.md @@ -7,7 +7,7 @@ To get diagnostics from the compiler, configure `rustc_interface::Config` to output diagnostic to a buffer, and run `TyCtxt.analysis`. The following should be compiled -with `nightly-2021-04-30` (See [here][example] +with `nightly-2022-06-05` (See [here][example] for the complete example): [example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-getting-diagnostics.rs diff --git a/src/rustc-driver-interacting-with-the-ast.md b/src/rustc-driver-interacting-with-the-ast.md index 1ec9c1c32..86732de18 100644 --- a/src/rustc-driver-interacting-with-the-ast.md +++ b/src/rustc-driver-interacting-with-the-ast.md @@ -5,7 +5,7 @@ ## Getting the type of an expression To get the type of an expression, use the `global_ctxt` to get a `TyCtxt`. -The following should be compiled with `nightly-2022-04-30` +The following should be compiled with `nightly-2022-06-05` (see [here][example] for the complete example): [example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-interacting-with-the-ast.rs From 6e4d6435db89bcc027b1bba9742e4f59666f5412 Mon Sep 17 00:00:00 2001 From: Jonas Schievink Date: Wed, 8 Jun 2022 01:06:32 +0200 Subject: [PATCH 1673/1812] Make build scripts and proc macros work with the suggested rust-analyzer config (#1365) --- src/building/suggested.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 196ff5fe8..6c0b7135e 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -37,9 +37,16 @@ you can write: February 2022, diagnostic items in code are accessed via symbols in - [`rustc_span::symbol::sym`]. To add your newly created diagnostic item simply open the - module file and add the name (In this case `Cat`) at the correct point in the list. - -Now you can create a pull request with your changes. :tada: (Note that when using diagnostic -items in other projects like Clippy, it might take some time until the repos get synchronized.) - -## Naming Conventions - -Diagnostic items don't have a set in stone naming convention yet. These are some guidelines that -should be used for the future, but might differ from existing names: - -* Types, traits and enums are named using UpperCamelCase (Examples: `Iterator`, `HashMap`, ...) -* For type names that are used multiple times like `Writer` it's good to choose a more precise - name, maybe by adding the module to it. (Example: `IoWriter`) -* Associated items should not get their own diagnostic items, but instead be accessed indirectly - by the diagnostic item of the type they're originating from. -* Freestanding functions like `std::mem::swap()` should be named using `snake_case` with one - important (export) module as a prefix (Example: `mem_swap`, `cmp_max`) -* Modules should usually not have a diagnostic item attached to them. Diagnostic items were - added to avoid the usage of paths, using them on modules would therefore most likely to be - counterproductive. - -## How To Use Diagnostic Items - +2. As of February 2022, diagnostic items in code are + accessed via symbols in [`rustc_span::symbol::sym`]. To add your newly + created diagnostic item simply open the module file and add the name (In + this case `Cat`) at the correct point in the list. + +Now you can create a pull request with your changes. :tada: (Note that when +using diagnostic items in other projects like Clippy, it might take some time +until the repos get synchronized.) + +## Naming conventions +Diagnostic items don't have a set in stone naming convention yet. These are +some guidelines that should be used for the future, but might differ from +existing names: + +* Types, traits and enums are named using UpperCamelCase (Examples: `Iterator`, +* `HashMap`, ...) +* For type names that are used multiple times like `Writer` it's good to choose + a more precise name, maybe by adding the module to it. (Example: `IoWriter`) +* Associated items should not get their own diagnostic items, but instead be + accessed indirectly by the diagnostic item of the type they're originating + from. +* Freestanding functions like `std::mem::swap()` should be named using + `snake_case` with one important (export) module as a prefix (Example: + `mem_swap`, `cmp_max`) +* Modules should usually not have a diagnostic item attached to them. + Diagnostic items were added to avoid the usage of paths, using them on + modules would therefore most likely to be counterproductive. + +## Using diagnostic items In rustc, diagnostic items are looked up via [`Symbol`]s from inside the -[`rustc_span::symbol::sym`] module. These can then be mapped to [`DefId`]s using -[`TyCtxt::get_diagnostic_item()`] or checked if they match a [`DefId`] using -[`TyCtxt::is_diagnostic_item()`]. When mapping from a diagnostic item to a [`DefId`] the method -will return a `Option`. This can be `None` if either the symbol isn't a diagnostic item -or the type is not registered, for instance when compiling with `#[no_std]`. All following -examples are based on [`DefId`]s and their usage. - -### Check For A Type - +[`rustc_span::symbol::sym`] module. These can then be mapped to [`DefId`]s +using [`TyCtxt::get_diagnostic_item()`] or checked if they match a [`DefId`] +using [`TyCtxt::is_diagnostic_item()`]. When mapping from a diagnostic item to +a [`DefId`] the method will return a `Option`. This can be `None` if +either the symbol isn't a diagnostic item or the type is not registered, for +instance when compiling with `#[no_std]`. All following examples are based on +[`DefId`]s and their usage. + +### Example: Checking for a type ```rust use rustc_span::symbol::sym; @@ -92,8 +95,7 @@ fn example_1(cx: &LateContext<'_>, ty: Ty<'_>) -> bool { } ``` -### Check For A Trait Implementation - +### Example: Checking for a trait implementation ```rust /// This example checks if a given [`DefId`] from a method is part of a trait /// implementation defined by a diagnostic item. @@ -110,24 +112,23 @@ fn is_diag_trait_item( ``` ### Associated Types - -Associated types of diagnostic items can be accessed indirectly by first getting the [`DefId`] -of the trait and then calling [`TyCtxt::associated_items()`]. This returns an [`AssocItems`] -object which can be used for further checks. Checkout +Associated types of diagnostic items can be accessed indirectly by first +getting the [`DefId`] of the trait and then calling +[`TyCtxt::associated_items()`]. This returns an [`AssocItems`] object which can +be used for further checks. Checkout [`clippy_utils::ty::get_iterator_item_ty()`] for an example usage of this. -### Usage In Clippy - -Clippy tries to use diagnostic items where possible and has developed some wrapper and utility -functions. Please also refer to its documentation when using diagnostic items in Clippy. (See -[*Common tools for writing lints*][clippy-Common-tools-for-writing-lints].) - -## Related Issues +### Usage in Clippy +Clippy tries to use diagnostic items where possible and has developed some +wrapper and utility functions. Please also refer to its documentation when +using diagnostic items in Clippy. (See [*Common tools for writing +lints*][clippy-Common-tools-for-writing-lints].) -This lists some related issues. These are probably only interesting to people who really want to -take a deep dive into the topic :) +## Related issues +This lists some related issues. These are probably only interesting to people +who really want to take a deep dive into the topic :) -* [rust#60966]: The Rust PR that introduced diagnostic items +* [rust#60966]: The Rust PR that introduced diagnostic items * [rust-clippy#5393]: Clippy's tracking issue for moving away from hard coded paths to diagnostic item diff --git a/src/diagnostics/error-guaranteed.md b/src/diagnostics/error-guaranteed.md index 5a9b7f335..d92ba62ab 100644 --- a/src/diagnostics/error-guaranteed.md +++ b/src/diagnostics/error-guaranteed.md @@ -1,5 +1,4 @@ # `ErrorGuaranteed` - The previous sections have been about the error message that a user of the compiler sees. But emitting an error can also have a second important side effect within the compiler source code: it generates an @@ -19,7 +18,6 @@ There are some important considerations about the usage of `ErrorGuaranteed`: Thus, you should not rely on `ErrorGuaranteed` when deciding whether to emit an error, or what kind of error to emit. - * `ErrorGuaranteed` should not be used to indicate that a compilation _will emit_ an error in the future. It should be used to indicate that an error _has already been_ emitted -- that is, the [`emit()`][emit] function has @@ -30,7 +28,6 @@ There are some important considerations about the usage of `ErrorGuaranteed`: Thankfully, in most cases, it should be statically impossible to abuse `ErrorGuaranteed`. - [errorguar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.ErrorGuaranteed.html [rerrors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html [dsp]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.Handler.html#method.delay_span_bug diff --git a/src/diagnostics/lintstore.md b/src/diagnostics/lintstore.md index 489771dac..39007f8d1 100644 --- a/src/diagnostics/lintstore.md +++ b/src/diagnostics/lintstore.md @@ -1,104 +1,110 @@ # Lints - This page documents some of the machinery around lint registration and how we run lints in the compiler. -The [`LintStore`] is the central piece of infrastructure, around which everything -rotates. It's not available during the early parts of compilation (i.e., before -TyCtxt) in most code, as we need to fill it in with all of the lints, which can only happen after -plugin registration. +The [`LintStore`] is the central piece of infrastructure, around which +everything rotates. It's not available during the early parts of compilation +(i.e., before TyCtxt) in most code, as we need to fill it in with all of the +lints, which can only happen after plugin registration. ## Lints vs. lint passes +There are two parts to the linting mechanism within the compiler: lints and +lint passes. Unfortunately, a lot of the documentation we have refers to both +of these as just "lints." -There are two parts to the linting mechanism within the compiler: lints and lint passes. -Unfortunately, a lot of the documentation we have refers to both of these as just "lints." - -First, we have the lint declarations themselves: this is where the name and default lint level and -other metadata come from. These are normally defined by way of the [`declare_lint!`] macro, which -boils down to a static with type `&rustc_session::lint::Lint`. +First, we have the lint declarations themselves: this is where the name and +default lint level and other metadata come from. These are normally defined by +way of the [`declare_lint!`] macro, which boils down to a static with type +`&rustc_session::lint::Lint`. As of February 2022, we lint against direct declarations without the use of the macro today (although this may change in the future, as the macro is somewhat unwieldy to add new fields to, like all macros). -Lint declarations don't carry any "state" - they are merely global identifiers and descriptions of -lints. We assert at runtime that they are not registered twice (by lint name). +Lint declarations don't carry any "state" - they are merely global identifiers +and descriptions of lints. We assert at runtime that they are not registered +twice (by lint name). -Lint passes are the meat of any lint. Notably, there is not a one-to-one relationship between -lints and lint passes; a lint might not have any lint pass that emits it, it could have many, or -just one -- the compiler doesn't track whether a pass is in any way associated with a particular -lint, and frequently lints are emitted as part of other work (e.g., type checking, etc.). +Lint passes are the meat of any lint. Notably, there is not a one-to-one +relationship between lints and lint passes; a lint might not have any lint pass +that emits it, it could have many, or just one -- the compiler doesn't track +whether a pass is in any way associated with a particular lint, and frequently +lints are emitted as part of other work (e.g., type checking, etc.). ## Registration ### High-level overview +In [`rustc_interface::register_plugins`] the [`LintStore`] is created and all +lints are registered. + +There are four 'sources' of lints: -In [`rustc_interface::register_plugins`] the [`LintStore`] is created and all lints are registered. -There are four 'sources' of lints: * internal lints: lints only used by the rustc codebase -* builtin lints: lints built into the compiler and not provided by some outside source +* builtin lints: lints built into the compiler and not provided by some outside + source * plugin lints: lints created by plugins through the plugin system. -* `rustc_interface::Config`[`register_lints`]: lints passed into the compiler during construction +* `rustc_interface::Config`[`register_lints`]: lints passed into the compiler + during construction Lints are registered via the [`LintStore::register_lint`] function. This should happen just once for any lint, or an ICE will occur. -Once the registration is complete, we "freeze" the lint store by placing it in an `Lrc`. Later in -the driver, it's passed into the `GlobalCtxt` constructor where it lives in an immutable form from -then on. +Once the registration is complete, we "freeze" the lint store by placing it in +an `Lrc`. Later in the driver, it's passed into the `GlobalCtxt` constructor +where it lives in an immutable form from then on. -Lint passes are registered separately into one of the categories (pre-expansion, -early, late, late module). Passes are registered as a closure -- i.e., `impl -Fn() -> Box`, where `dyn X` is either an early or late lint pass trait -object. When we run the lint passes, we run the closure and then invoke the lint -pass methods. The lint pass methods take `&mut self` so they can keep track of state -internally. +Lint passes are registered separately into one of the categories +(pre-expansion, early, late, late module). Passes are registered as a closure +-- i.e., `impl Fn() -> Box`, where `dyn X` is either an early or late +lint pass trait object. When we run the lint passes, we run the closure and +then invoke the lint pass methods. The lint pass methods take `&mut self` so +they can keep track of state internally. #### Internal lints +These are lints used just by the compiler or plugins like `clippy`. They can be +found in `rustc_lint::internal`. -These are lints used just by the compiler or plugins like `clippy`. They can be found in -`rustc_lint::internal`. - -An example of such a lint is the check that lint passes are implemented using the -`declare_lint_pass!` macro and not by hand. This is accomplished with the +An example of such a lint is the check that lint passes are implemented using +the `declare_lint_pass!` macro and not by hand. This is accomplished with the `LINT_PASS_IMPL_WITHOUT_MACRO` lint. -Registration of these lints happens in the [`rustc_lint::register_internals`] function which is -called when constructing a new lint store inside [`rustc_lint::new_lint_store`]. +Registration of these lints happens in the [`rustc_lint::register_internals`] +function which is called when constructing a new lint store inside +[`rustc_lint::new_lint_store`]. ### Builtin Lints - These are primarily described in two places: `rustc_session::lint::builtin` and -`rustc_lint::builtin`. Often the first provides the definitions for the lints themselves, -and the latter provides the lint pass definitions (and implementations), but this is not always -true. +`rustc_lint::builtin`. Often the first provides the definitions for the lints +themselves, and the latter provides the lint pass definitions (and +implementations), but this is not always true. -The builtin lint registration happens in the [`rustc_lint::register_builtins`] function. Just like -with internal lints, this happens inside of [`rustc_lint::new_lint_store`]. +The builtin lint registration happens in the [`rustc_lint::register_builtins`] +function. Just like with internal lints, this happens inside of +[`rustc_lint::new_lint_store`]. #### Plugin lints +This is one of the primary use cases remaining for plugins/drivers. Plugins are +given access to the mutable `LintStore` during registration (which happens +inside of [`rustc_interface::register_plugins`]) and they can call any +functions they need on the `LintStore`, just like rustc code. -This is one of the primary use cases remaining for plugins/drivers. Plugins are given access -to the mutable `LintStore` during registration (which happens inside of -[`rustc_interface::register_plugins`]) and they can call any functions they need on -the `LintStore`, just like rustc code. - -Plugins are intended to declare lints with the `plugin` field set to true (e.g., by -way of the [`declare_tool_lint!`] macro), but this is purely for diagnostics and help text; -otherwise plugin lints are mostly just as first class as rustc builtin lints. +Plugins are intended to declare lints with the `plugin` field set to true +(e.g., by way of the [`declare_tool_lint!`] macro), but this is purely for +diagnostics and help text; otherwise plugin lints are mostly just as first +class as rustc builtin lints. #### Driver lints - -These are the lints provided by drivers via the `rustc_interface::Config` [`register_lints`] field, -which is a callback. Drivers should, if finding it already set, call the function currently set -within the callback they add. The best way for drivers to get access to this is by overriding the -`Callbacks::config` function which gives them direct access to the `Config` structure. +These are the lints provided by drivers via the `rustc_interface::Config` +[`register_lints`] field, which is a callback. Drivers should, if finding it +already set, call the function currently set within the callback they add. The +best way for drivers to get access to this is by overriding the +`Callbacks::config` function which gives them direct access to the `Config` +structure. ## Compiler lint passes are combined into one pass - Within the compiler, for performance reasons, we usually do not register dozens -of lint passes. Instead, we have a single lint pass of each variety -(e.g., `BuiltinCombinedModuleLateLintPass`) which will internally call all of the +of lint passes. Instead, we have a single lint pass of each variety (e.g., +`BuiltinCombinedModuleLateLintPass`) which will internally call all of the individual lint passes; this is because then we get the benefits of static over dynamic dispatch for each of the (often empty) trait methods. From c4d5a6994542218c152a22ecf4528f4e27bdde3b Mon Sep 17 00:00:00 2001 From: David Wood Date: Mon, 6 Jun 2022 14:07:55 +0100 Subject: [PATCH 1679/1812] diagnostics: add translation documentation - Add documentation on translation infrastructure and use of `SessionSubdiagnostic`. - Update diagnostic examples on other pages to be translatable since this is preferred. Signed-off-by: David Wood --- book.toml | 1 + src/SUMMARY.md | 7 +- src/diagnostics.md | 90 ++++--- src/diagnostics/diagnostic-items.md | 2 +- src/diagnostics/diagnostic-structs.md | 359 ++++++++++++++++++++++++++ src/diagnostics/sessiondiagnostic.md | 207 --------------- src/diagnostics/translation.md | 239 +++++++++++++++++ 7 files changed, 659 insertions(+), 246 deletions(-) create mode 100644 src/diagnostics/diagnostic-structs.md delete mode 100644 src/diagnostics/sessiondiagnostic.md create mode 100644 src/diagnostics/translation.md diff --git a/book.toml b/book.toml index 8b9f57594..c4450cf0c 100644 --- a/book.toml +++ b/book.toml @@ -38,3 +38,4 @@ warning-policy = "error" [output.html.redirect] "/compiletest.html" = "tests/compiletest.html" +"/diagnostics/sessiondiagnostic.html" = "diagnostics/diagnostic-structs.html" diff --git a/src/SUMMARY.md b/src/SUMMARY.md index e74ef5e4e..302976296 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -138,10 +138,11 @@ - [Two-phase-borrows](./borrow_check/two_phase_borrows.md) - [Parameter Environments](./param_env.md) - [Errors and Lints](diagnostics.md) - - [Creating Errors With SessionDiagnostic](./diagnostics/sessiondiagnostic.md) + - [Diagnostic and subdiagnostic structs](./diagnostics/diagnostic-structs.md) + - [Translation](./diagnostics/translation.md) - [`LintStore`](./diagnostics/lintstore.md) - - [Diagnostic Codes](./diagnostics/diagnostic-codes.md) - - [Diagnostic Items](./diagnostics/diagnostic-items.md) + - [Diagnostic codes](./diagnostics/diagnostic-codes.md) + - [Diagnostic items](./diagnostics/diagnostic-items.md) - [`ErrorGuaranteed`](./diagnostics/error-guaranteed.md) # MIR to Binaries diff --git a/src/diagnostics.md b/src/diagnostics.md index b67520428..7ef33d38e 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -139,10 +139,11 @@ use an error-level lint instead of a fixed error. flag. That said, don't make it so terse that it's hard to understand. - The word "illegal" is illegal. Prefer "invalid" or a more specific word instead. -- Errors should document the span of code where they occur – the - [`rustc_errors::diagnostic_builder::DiagnosticBuilder`][diagbuild] `span_*` - methods allow to easily do this. Also `note` other spans that have - contributed to the error if the span isn't too large. +- Errors should document the span of code where they occur (use + [`rustc_errors::diagnostic_builder::DiagnosticBuilder`][diagbuild]'s + `span_*` methods or a diagnostic struct's `#[primary_span]` to easily do + this). Also `note` other spans that have contributed to the error if the span + isn't too large. - When emitting a message with span, try to reduce the span to the smallest amount possible that still signifies the issue - Try not to emit multiple error messages for the same error. This may require @@ -312,6 +313,15 @@ reporting errors. [errors]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/index.html +Diagnostics can be implemented as types which implement the `SessionDiagnostic` +trait. This is preferred for new diagnostics as it enforces a separation +between diagnostic emitting logic and the main code paths. For less-complex +diagnostics, the `SessionDiagnostic` trait can be derived -- see [Diagnostic +structs][diagnostic-structs]. Within the trait implementation, the APIs +described below can be used as normal. + +[diagnostic-structs]: ./diagnostics/diagnostic-structs.md + [`Session`][session] and [`ParseSess`][parsesses] have methods (or fields with methods) that allow reporting errors. These methods usually have names like `span_err` or `struct_span_err` or `span_warn`, etc... @@ -327,6 +337,12 @@ directly and ones that allow finer control over what to emit. For example, [`struct_span_err`][strspanerr] instead returns a [`DiagnosticBuilder`][diagbuild]. +Most of these methods will accept strings, but it is recommended that typed +identifiers for translatable diagnostics be used for new diagnostics (see +[Translation][translation]). + +[translation]: ./diagnostics/translation.md + `DiagnosticBuilder` allows you to add related notes and suggestions to an error before emitting it by calling the [`emit`][emit] method. (Failing to either emit or [cancel][cancel] a `DiagnosticBuilder` will result in an ICE.) See the @@ -340,30 +356,30 @@ emit or [cancel][cancel] a `DiagnosticBuilder` will result in an ICE.) See the ```rust,ignore // Get a DiagnosticBuilder. This does _not_ emit an error yet. -let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); +let mut err = sess.struct_span_err(sp, fluent::example::example_error); // In some cases, you might need to check if `sp` is generated by a macro to // avoid printing weird errors about macro-generated code. if let Ok(snippet) = sess.source_map().span_to_snippet(sp) { // Use the snippet to generate a suggested fix - err.span_suggestion(suggestion_sp, "try using a qux here", format!("qux {}", snippet)); + err.span_suggestion(suggestion_sp, fluent::example::try_qux_suggestion, format!("qux {}", snippet)); } else { // If we weren't able to generate a snippet, then emit a "help" message // instead of a concrete "suggestion". In practice this is unlikely to be // reached. - err.span_help(suggestion_sp, "you could use a qux here instead"); + err.span_help(suggestion_sp, fluent::example::qux_suggestion); } // emit the error err.emit(); ``` -Alternatively, for less-complex diagnostics, the `SessionDiagnostic` derive -macro can be used -- see [Creating Errors With SessionDiagnostic][sessiondiagnostic]. - -[sessiondiagnostic]: ./diagnostics/sessiondiagnostic.md - +```fluent +example-example-error = oh no! this is an error! + .try-qux-suggestion = try using a qux here + .qux-suggestion = you could use a qux here instead +``` ## Suggestions @@ -405,17 +421,17 @@ apply them) For example, to make our `qux` suggestion machine-applicable, we would do: ```rust,ignore -let mut err = sess.struct_span_err(sp, "oh no! this is an error!"); +let mut err = sess.struct_span_err(sp, fluent::example::message); if let Ok(snippet) = sess.source_map().span_to_snippet(sp) { err.span_suggestion( suggestion_sp, - "try using a qux here", + fluent::example::try_qux_suggestion, format!("qux {}", snippet), Applicability::MachineApplicable, ); } else { - err.span_help(suggestion_sp, "you could use a qux here instead"); + err.span_help(suggestion_sp, fluent::example::qux_suggestion); } err.emit(); @@ -504,9 +520,9 @@ much faster to work on. Every lint is implemented via a `struct` that implements the `LintPass` `trait` (you can also implement one of the more specific lint pass traits, either -`EarlyLintPass` or `LateLintPass` depending on when is best for your lint to run). -The trait implementation allows you to check certain syntactic constructs -as the linter walks the AST. You can then choose to emit lints in a +`EarlyLintPass` or `LateLintPass` depending on when is best for your lint to run). +The trait implementation allows you to check certain syntactic constructs +as the linter walks the AST. You can then choose to emit lints in a very similar way to compile errors. You also declare the metadata of a particular lint via the `declare_lint!` @@ -557,13 +573,12 @@ impl EarlyLintPass for WhileTrue { if let ast::ExprKind::Lit(ref lit) = pierce_parens(cond).kind { if let ast::LitKind::Bool(true) = lit.kind { if !lit.span.from_expansion() { - let msg = "denote infinite loops with `loop { ... }`"; let condition_span = cx.sess.source_map().guess_head_span(e.span); cx.struct_span_lint(WHILE_TRUE, condition_span, |lint| { - lint.build(msg) + lint.build(fluent::example::use_loop) .span_suggestion_short( condition_span, - "use `loop`", + fluent::example::suggestion, "loop".to_owned(), Applicability::MachineApplicable, ) @@ -577,6 +592,11 @@ impl EarlyLintPass for WhileTrue { } ``` +```fluent +example-use-loop = denote infinite loops with `loop {"{"} ... {"}"}` + .suggestion = use `loop` +``` + ### Edition-gated lints Sometimes we want to change the behavior of a lint in a new edition. To do this, @@ -613,15 +633,15 @@ declare_lint! { The use of the term `future-incompatible` within the compiler has a slightly broader meaning than what rustc exposes to users of the compiler. -Inside rustc, future-incompatible lints are for signalling to the user that code they have +Inside rustc, future-incompatible lints are for signalling to the user that code they have written may not compile in the future. In general, future-incompatible code exists for two reasons: -* the user has written unsound code that the compiler mistakenly accepted. While -it is within Rust's backwards compatibility guarantees to fix the soundness hole -(breaking the user's code), the lint is there to warn the user that this will happen -in some upcoming version of rustc *regardless of which edition the code uses*. This is the +* the user has written unsound code that the compiler mistakenly accepted. While +it is within Rust's backwards compatibility guarantees to fix the soundness hole +(breaking the user's code), the lint is there to warn the user that this will happen +in some upcoming version of rustc *regardless of which edition the code uses*. This is the meaning that rustc exclusively exposes to users as "future incompatible". -* the user has written code that will either no longer compiler *or* will change +* the user has written code that will either no longer compiler *or* will change meaning in an upcoming *edition*. These are often called "edition lints" and can be typically seen in the various "edition compatibility" lint groups (e.g., `rust_2021_compatibility`) that are used to lint against code that will break if the user updates the crate's edition. @@ -644,11 +664,11 @@ declare_lint! { Notice the `reason` field which describes why the future incompatible change is happening. This will change the diagnostic message the user receives as well as determine which lint groups the lint is added to. In the example above, the lint is an "edition lint" -(since it's "reason" is `EditionError`) signifying to the user that the use of anonymous +(since it's "reason" is `EditionError`) signifying to the user that the use of anonymous parameters will no longer compile in Rust 2018 and beyond. -Inside [LintStore::register_lints][fi-lint-groupings], lints with `future_incompatible` -fields get placed into either edition-based lint groups (if their `reason` is tied to +Inside [LintStore::register_lints][fi-lint-groupings], lints with `future_incompatible` +fields get placed into either edition-based lint groups (if their `reason` is tied to an edition) or into the `future_incompatibility` lint group. [fi-lint-groupings]: https://github.com/rust-lang/rust/blob/51fd129ac12d5bfeca7d216c47b0e337bf13e0c2/compiler/rustc_lint/src/context.rs#L212-L237 @@ -659,7 +679,7 @@ to support this. ### Renaming or removing a lint -If it is determined that a lint is either improperly named or no longer needed, +If it is determined that a lint is either improperly named or no longer needed, the lint must be registered for renaming or removal, which will trigger a warning if a user tries to use the old lint name. To declare a rename/remove, add a line with [`store.register_renamed`] or [`store.register_removed`] to the code of the @@ -695,11 +715,11 @@ This defines the `nonstandard_style` group which turns on the listed lints. A user can turn on these lints with a `!#[warn(nonstandard_style)]` attribute in the source code, or by passing `-W nonstandard-style` on the command line. -Some lint groups are created automatically in `LintStore::register_lints`. For instance, -any lint declared with `FutureIncompatibleInfo` where the reason is -`FutureIncompatibilityReason::FutureReleaseError` (the default when +Some lint groups are created automatically in `LintStore::register_lints`. For instance, +any lint declared with `FutureIncompatibleInfo` where the reason is +`FutureIncompatibilityReason::FutureReleaseError` (the default when `@future_incompatible` is used in `declare_lint!`), will be added to -the `future_incompatible` lint group. Editions also have their own lint groups +the `future_incompatible` lint group. Editions also have their own lint groups (e.g., `rust_2021_compatibility`) automatically generated for any lints signaling future-incompatible code that will break in the specified edition. diff --git a/src/diagnostics/diagnostic-items.md b/src/diagnostics/diagnostic-items.md index af11eb9ea..0031ba284 100644 --- a/src/diagnostics/diagnostic-items.md +++ b/src/diagnostics/diagnostic-items.md @@ -76,7 +76,7 @@ In rustc, diagnostic items are looked up via [`Symbol`]s from inside the [`rustc_span::symbol::sym`] module. These can then be mapped to [`DefId`]s using [`TyCtxt::get_diagnostic_item()`] or checked if they match a [`DefId`] using [`TyCtxt::is_diagnostic_item()`]. When mapping from a diagnostic item to -a [`DefId`] the method will return a `Option`. This can be `None` if +a [`DefId`], the method will return a `Option`. This can be `None` if either the symbol isn't a diagnostic item or the type is not registered, for instance when compiling with `#[no_std]`. All following examples are based on [`DefId`]s and their usage. diff --git a/src/diagnostics/diagnostic-structs.md b/src/diagnostics/diagnostic-structs.md new file mode 100644 index 000000000..cab9b0c2f --- /dev/null +++ b/src/diagnostics/diagnostic-structs.md @@ -0,0 +1,359 @@ +# Diagnostic and subdiagnostic structs +rustc has two diagnostic derives that can be used to create simple diagnostics, +which are recommended to be used when they are applicable: +`#[derive(SessionDiagnostic)]` and `#[derive(SessionSubdiagnostic)]`. + +Diagnostics created with the derive macros can be translated into different +languages and each has a slug that uniquely identifies the diagnostic. + +## `#[derive(SessionDiagnostic)]` +Instead of using the `DiagnosticBuilder` API to create and emit diagnostics, +the `SessionDiagnostic` derive can be used. `#[derive(SessionDiagnostic)]` is +only applicable for simple diagnostics that don't require much logic in +deciding whether or not to add additional subdiagnostics. + +Consider the [definition][defn] of the "field already declared" diagnostic +shown below: + +```rust,ignore +#[derive(SessionDiagnostic)] +#[error(code = "E0124", slug = "typeck-field-already-declared")] +pub struct FieldAlreadyDeclared { + pub field_name: Ident, + #[primary_span] + #[label] + pub span: Span, + #[label = "previous-decl-label"] + pub prev_span: Span, +} +``` + +`SessionDiagnostic` can only be applied to structs. Every `SessionDiagnostic` +has to have one attribute applied to the struct itself: either `#[error(..)]` +for defining errors, or `#[warning(..)]` for defining warnings. + +If an error has an error code (e.g. "E0624"), then that can be specified using +the `code` sub-attribute. Specifying a `code` isn't mandatory, but if you are +porting a diagnostic that uses `DiagnosticBuilder` to use `SessionDiagnostic` +then you should keep the code if there was one. + +Both `#[error(..)]` and `#[warning(..)]` must set a value for the `slug` +sub-attribute. `slug` uniquely identifies the diagnostic and is also how the +compiler knows what error message to emit (in the default locale of the +compiler, or in the locale requested by the user). See [translation +documentation](./translation.md) to learn more about how translatable error +messages are written. + +In our example, the Fluent message for the "field already declared" diagnostic +looks like this: + +```fluent +typeck-field-already-declared = + field `{$field_name}` is already declared + .label = field already declared + .previous-decl-label = `{$field_name}` first declared here +``` + +`typeck-field-already-declared` is the `slug` from our example and is followed +by the diagnostic message. + +Every field of the `SessionDiagnostic` which does not have an annotation is +available in Fluent messages as a variable, like `field_name` in the example +above. Fields can be annotated `#[skip_arg]` if this is undesired. + +Using the `#[primary_span]` attribute on a field (that has type `Span`) +indicates the primary span of the diagnostic which will have the main message +of the diagnostic. + +Diagnostics are more than just their primary message, they often include +labels, notes, help messages and suggestions, all of which can also be +specified on a `SessionDiagnostic`. + +`#[label]`, `#[help]` and `#[note]` can all be applied to fields which have the +type `Span`. Applying any of these attributes will create the corresponding +subdiagnostic with that `Span`. These attributes will look for their +diagnostic message in a Fluent attribute attached to the primary Fluent +message. In our example, `#[label]` will look for +`typeck-field-already-declared.label` (which has the message "field already +declared"). If there is more than one subdiagnostic of the same type, then +these attributes can also take a value that is the attribute name to look for +(e.g. `previous-decl-label` in our example). + +Other types have special behavior when used in a `SessionDiagnostic` derive: + +- Any attribute applied to an `Option` and will only emit a + subdiagnostic if the option is `Some(..)`. +- Any attribute applied to a `Vec` will be repeated for each element of the + vector. + +`#[help]` and `#[note]` can also be applied to the struct itself, in which case +they work exactly like when applied to fields except the subdiagnostic won't +have a `Span`. These attributes can also be applied to fields of type `()` for +the same effect, which when combined with the `Option` type can be used to +represent optional `#[note]`/`#[help]` subdiagnostics. + +Suggestions can be emitted using one of four field attributes: + +- `#[suggestion(message = "...", code = "...", applicability = "...")]` +- `#[suggestion_hidden(message = "...", code = "...", applicability = "...")]` +- `#[suggestion_short(message = "...", code = "...", applicability = "...")]` +- `#[suggestion_verbose(message = "...", code = "...", applicability = "...")]` + +Suggestions must be applied on either a `Span` field or a `(Span, +MachineApplicability)` field. Similarly to other field attributes, `message` +specifies the Fluent attribute with the message and defaults to `.suggestion`. +`code` specifies the code that should be suggested as a replacement and is a +format string (e.g. `{field_name}` would be replaced by the value of the +`field_name` field of the struct), not a Fluent identifier. `applicability` can +be used to specify the applicability in the attribute, it cannot be used when +the field's type contains an `Applicability`. + +In the end, the `SessionDiagnostic` derive will generate an implementation of +`SessionDiagnostic` that looks like the following: + +```rust,ignore +impl SessionDiagnostic for FieldAlreadyDeclared { + fn into_diagnostic(self, sess: &'_ rustc_session::Session) -> DiagnosticBuilder<'_> { + let mut diag = sess.struct_err_with_code( + rustc_errors::DiagnosticMessage::fluent("typeck-field-already-declared"), + rustc_errors::DiagnosticId::Error("E0124") + ); + diag.set_span(self.span); + diag.span_label( + self.span, + rustc_errors::DiagnosticMessage::fluent_attr("typeck-field-already-declared", "label") + ); + diag.span_label( + self.prev_span, + rustc_errors::DiagnosticMessage::fluent_attr("typeck-field-already-declared", "previous-decl-label") + ); + diag + } +} +``` + +Now that we've defined our diagnostic, how do we [use it][use]? It's quite +straightforward, just create an instance of the struct and pass it to +`emit_err` (or `emit_warning`): + +```rust,ignore +tcx.sess.emit_err(FieldAlreadyDeclared { + field_name: f.ident, + span: f.span, + prev_span, +}); +``` + +### Reference +`#[derive(SessionDiagnostic)]` supports the following attributes: + +- `#[error(code = "...", slug = "...")]` or `#[warning(code = "...", slug = "...")]` + - _Applied to struct._ + - _Mandatory_ + - Defines the struct to be representing an error or a warning. + - `code = "..."` (_Optional_) + - Specifies the error code. + - `slug = "..."` (_Mandatory_) + - Uniquely identifies the diagnostic and corresponds to its Fluent message, + mandatory. +- `#[note]` or `#[note = "..."]` (_Optional_) + - _Applied to struct or `Span`/`()` fields._ + - Adds a note subdiagnostic. + - Value is the Fluent attribute (relative to the Fluent message specified by + `slug`) for the note's message + - Defaults to `note`. + - If applied to a `Span` field, creates a spanned note. +- `#[help]` or `#[help = "..."]` (_Optional_) + - _Applied to struct or `Span`/`()` fields._ + - Adds a help subdiagnostic. + - Value is the Fluent attribute (relative to the Fluent message specified by + `slug`) for the help's message. + - Defaults to `help`. + - If applied to a `Span` field, creates a spanned help. +- `#[label]` or `#[label = "..."]` (_Optional_) + - _Applied to `Span` fields._ + - Adds a label subdiagnostic. + - Value is the Fluent attribute (relative to the Fluent message specified by + `slug`) for the label's message. + - Defaults to `label`. +- `#[suggestion{,_hidden,_short,_verbose}(message = "...", code = "...", applicability = "...")]` + (_Optional_) + - _Applied to `(Span, MachineApplicability)` or `Span` fields._ + - Adds a suggestion subdiagnostic. + - `message = "..."` (_Mandatory_) + - Value is the Fluent attribute (relative to the Fluent message specified + by `slug`) for the suggestion's message. + - Defaults to `suggestion`. + - `code = "..."` (_Mandatory_) + - Value is a format string indicating the code to be suggested as a + replacement. + - `applicability = "..."` (_Optional_) + - String which must be one of `machine-applicable`, `maybe-incorrect`, + `has-placeholders` or `unspecified`. +- `#[subdiagnostic]` + - _Applied to a type that implements `AddToDiagnostic` (from + `#[derive(SessionSubdiagnostic)]`)._ + - Adds the subdiagnostic represented by the subdiagnostic struct. +- `#[primary_span]` (_Optional_) + - _Applied to `Span` fields._ + - Indicates the primary span of the diagnostic. +- `#[skip_arg]` (_Optional_) + - _Applied to any field._ + - Prevents the field from being provided as a diagnostic argument. + +## `#[derive(SessionSubdiagnostic)]` +It is common in the compiler to write a function that conditionally adds a +specific subdiagnostic to an error if it is applicable. Oftentimes these +subdiagnostics could be represented using a diagnostic struct even if the +overall diagnostic could not. In this circumstance, the `SessionSubdiagnostic` +derive can be used to represent a partial diagnostic (e.g a note, label, help or +suggestion) as a struct. + +Consider the [definition][subdiag_defn] of the "expected return type" label +shown below: + +```rust +#[derive(SessionSubdiagnostic)] +pub enum ExpectedReturnTypeLabel<'tcx> { + #[label(slug = "typeck-expected-default-return-type")] + Unit { + #[primary_span] + span: Span, + }, + #[label(slug = "typeck-expected-return-type")] + Other { + #[primary_span] + span: Span, + expected: Ty<'tcx>, + }, +} +``` + +Unlike `SessionDiagnostic`, `SessionSubdiagnostic` can be applied to structs or +enums. Attributes that are placed on the type for structs are placed on each +variants for enums (or vice versa). Each `SessionSubdiagnostic` should have one +attribute applied to the struct or each variant, one of: + +- `#[label(..)]` for defining a label +- `#[note(..)]` for defining a note +- `#[help(..)]` for defining a help +- `#[suggestion{,_hidden,_short,_verbose}(..)]` for defining a suggestion + +All of the above must have a value set for the `slug` sub-attribute. `slug` +uniquely identifies the diagnostic and is also how the compiler knows what +error message to emit (in the default locale of the compiler, or in the locale +requested by the user). See [translation documentation](./translation.md) to +learn more about how translatable error messages are written. + +In our example, the Fluent message for the "expected return type" label +looks like this: + +```fluent +typeck-expected-default-return-type = expected `()` because of default return type + +typeck-expected-return-type = expected `{$expected}` because of return type +``` + +Using the `#[primary_span]` attribute on a field (with type `Span`) will denote +the primary span of the subdiagnostic. A primary span is only necessary for a +label or suggestion, which can not be spanless. + +Every field of the type/variant which does not have an annotation is available +in Fluent messages as a variable. Fields can be annotated `#[skip_arg]` if this +is undesired. + +Like `SessionDiagnostic`, `SessionSubdiagnostic` supports `Option` and +`Vec` fields. + +Suggestions can be emitted using one of four attributes on the type/variant: + +- `#[suggestion(message = "...", code = "...", applicability = "...")]` +- `#[suggestion_hidden(message = "...", code = "...", applicability = "...")]` +- `#[suggestion_short(message = "...", code = "...", applicability = "...")]` +- `#[suggestion_verbose(message = "...", code = "...", applicability = "...")]` + +Suggestions require `#[primary_span]` be set on a field and can have the +following sub-attributes: + +- `message` specifies the Fluent attribute with the message and defaults to + `.suggestion`. +- `code` specifies the code that should be suggested as a replacement and is a + format string (e.g. `{field_name}` would be replaced by the value of the + `field_name` field of the struct), not a Fluent identifier. +- `applicability` can be used to specify the applicability in the attribute, it + cannot be used when the field's type contains an `Applicability`. + +Applicabilities can also be specified as a field (of type `Applicability`) +using the `#[applicability]` attribute. + +In the end, the `SessionSubdiagnostic` derive will generate an implementation +of `SessionSubdiagnostic` that looks like the following: + +```rust +impl<'tcx> AddToDiagnostic for ExpectedReturnTypeLabel<'tcx> { + fn add_to_diagnostic(self, diag: &mut rustc_errors::Diagnostic) { + use rustc_errors::{Applicability, IntoDiagnosticArg}; + match self { + ExpectedReturnTypeLabel::Unit { span } => { + diag.span_label(span, DiagnosticMessage::fluent("typeck-expected-default-return-type")) + } + ExpectedReturnTypeLabel::Other { span, expected } => { + diag.set_arg("expected", expected); + diag.span_label(span, DiagnosticMessage::fluent("typeck-expected-return-type")) + } + + } + } +} +``` + +Once defined, a subdiagnostic can be used by passing it to the `subdiagnostic` +function ([example][subdiag_use_1] and [example][subdiag_use_2]) on a +diagnostic or by assigning it to a `#[subdiagnostic]`-annotated field of a +diagnostic struct. + +### Reference +`#[derive(SessionSubdiagnostic)]` supports the following attributes: + +- `#[label(slug = "...")]`, `#[help(slug = "...")]` or `#[note(slug = "...")]` + - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._ + - _Mandatory_ + - Defines the type to be representing a label, help or note. + - `slug = "..."` (_Mandatory_) + - Uniquely identifies the diagnostic and corresponds to its Fluent message, + mandatory. +- `#[suggestion{,_hidden,_short,_verbose}(message = "...", code = "...", applicability = "...")]` + - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._ + - _Mandatory_ + - Defines the type to be representing a suggestion. + - `message = "..."` (_Mandatory_) + - Value is the Fluent attribute (relative to the Fluent message specified + by `slug`) for the suggestion's message. + - Defaults to `suggestion`. + - `code = "..."` (_Mandatory_) + - Value is a format string indicating the code to be suggested as a + replacement. + - `applicability = "..."` (_Optional_) + - _Mutually exclusive with `#[applicability]` on a field._ + - Value is the applicability of the suggestion. + - String which must be one of: + - `machine-applicable` + - `maybe-incorrect` + - `has-placeholders` + - `unspecified` +- `#[primary_span]` (_Mandatory_ for labels and suggestions; _optional_ otherwise) + - _Applied to `Span` fields._ + - Indicates the primary span of the subdiagnostic. +- `#[applicability]` (_Optional_; only applicable to suggestions) + - _Applied to `Applicability` fields._ + - Indicates the applicability of the suggestion. +- `#[skip_arg]` (_Optional_) + - _Applied to any field._ + - Prevents the field from being provided as a diagnostic argument. + +[defn]: https://github.com/rust-lang/rust/blob/bbe9d27b8ff36da56638aa43d6d0cdfdf89a4e57/compiler/rustc_typeck/src/errors.rs#L65-L74 +[use]: https://github.com/rust-lang/rust/blob/eb82facb1626166188d49599a3313fc95201f556/compiler/rustc_typeck/src/collect.rs#L981-L985 + +[subdiag_defn]: https://github.com/rust-lang/rust/blob/e70c60d34b9783a2fd3171d88d248c2e0ec8ecdd/compiler/rustc_typeck/src/errors.rs#L220-L233 +[subdiag_use_1]: https://github.com/rust-lang/rust/blob/e70c60d34b9783a2fd3171d88d248c2e0ec8ecdd/compiler/rustc_typeck/src/check/fn_ctxt/suggestions.rs#L556-L560 +[subdiag_use_2]: https://github.com/rust-lang/rust/blob/e70c60d34b9783a2fd3171d88d248c2e0ec8ecdd/compiler/rustc_typeck/src/check/fn_ctxt/suggestions.rs#L575-L579 diff --git a/src/diagnostics/sessiondiagnostic.md b/src/diagnostics/sessiondiagnostic.md deleted file mode 100644 index e82d5629d..000000000 --- a/src/diagnostics/sessiondiagnostic.md +++ /dev/null @@ -1,207 +0,0 @@ -# Creating translatable errors using `SessionDiagnostic` -The `SessionDiagnostic` derive macro is the recommended way to create -diagnostics. Diagnostics created with the derive macro can be translated into -different languages and each have a slug that uniquely identifies the -diagnostic. - -Instead of using the `DiagnosticBuilder` API to create and emit diagnostics, -the `SessionDiagnostic` derive macro is applied to structs. - -The [definition][defn] of the "field already declared" diagnostic is shown -below. - -```rust,ignore -#[derive(SessionDiagnostic)] -#[error(code = "E0124", slug = "typeck-field-already-declared")] -pub struct FieldAlreadyDeclared { - pub field_name: Ident, - #[primary_span] - #[label] - pub span: Span, - #[label = "previous-decl-label"] - pub prev_span: Span, -} -``` - -Every `SessionDiagnostic` has to have one attribute applied to the struct -itself: either `#[error(..)]` for defining errors, or `#[warning(..)]` for -defining warnings. - -If an error has an error code (e.g. "E0624"), then that can be specified using -the `code` sub-attribute. Specifying a `code` isn't mandatory, but if you are -porting a diagnostic that uses `DiagnosticBuilder` to use `SessionDiagnostic` -then you should keep the code if there was one. - -Both `#[error(..)]` and `#[warning(..)]` must set a value for the `slug` -sub-attribute. `slug` uniquely identifies the diagnostic and is also how the -compiler knows what error message to emit (in the default locale of the -compiler, or in the locale requested by the user). - -rustc uses [Fluent](https://projectfluent.org) to handle the intricacies of -translation. Each diagnostic's `slug` is actually an identifier for a *Fluent -message*. Let's take a look at what the Fluent message for the "field already -declared" diagnostic looks like: - -```fluent -typeck-field-already-declared = - field `{$field_name}` is already declared - .label = field already declared - .previous-decl-label = `{$field_name}` first declared here -``` - -`typeck-field-already-declared` is the `slug` from our example and is followed -by the diagnostic message. - -Fluent is built around the idea of "asymmetric localization", which aims to -decouple the expressiveness of translations from the grammar of the source -language (English in rustc's case). Prior to translation, rustc's diagnostics -relied heavily on interpolation to build the messages shown to the users. -Interpolated strings are hard to translate because writing a natural-sounding -translation might require more, less, or just different interpolation than the -English string, all of which would require changes to the compiler's source -code to support. - -As the compiler team gain more experience creating `SessionDiagnostic` structs -that have all of the information necessary to be translated into different -languages, this page will be updated with more guidance. For now, the [Project -Fluent](https://projectfluent.org) documentation has excellent examples of -translating messages into different locales and the information that needs to -be provided by the code to do so. - -When adding or changing a diagnostic, you don't need to worry about the -translations, only updating the original English message. All of rustc's -English Fluent messages can be found in -`/compiler/rustc_error_messages/locales/en-US/diagnostics.ftl`. - -Every field of the `SessionDiagnostic` which does not have an annotation is -available in Fluent messages as a variable, like `field_name` in the example -above. - -Using the `#[primary_span]` attribute on a field (that has type `Span`) -indicates the primary span of the diagnostic which will have the main message -of the diagnostic. - -Diagnostics are more than just their primary message, they often include -labels, notes, help messages and suggestions, all of which can also be -specified on a `SessionDiagnostic`. - -`#[label]`, `#[help]` and `#[note]` can all be applied to fields which have the -type `Span`. Applying any of these attributes will create the corresponding -sub-diagnostic with that `Span`. These attributes will look for their -diagnostic message in a Fluent attribute attached to the primary Fluent -message. In our example, `#[label]` will look for -`typeck-field-already-declared.label` (which has the message "field already -declared"). If there is more than one sub-diagnostic of the same type, then -these attributes can also take a value that is the attribute name to look for -(e.g. `previous-decl-label` in our example). - -`#[help]` and `#[note]` can also be applied to the struct itself, in which case -they work exactly like when applied to fields except the sub-diagnostic won't -have a `Span`. - -Any attribute can also be applied to an `Option` and will only emit a -sub-diagnostic if the option is `Some(..)`. - -Suggestions can be emitted using one of four field attributes: - -- `#[suggestion(message = "...", code = "...")]` -- `#[suggestion_hidden(message = "...", code = "...")]` -- `#[suggestion_short(message = "...", code = "...")]` -- `#[suggestion_verbose(message = "...", code = "...")]` - -Suggestions must be applied on either a `Span` field or a -`(Span, MachineApplicability)` field. Similarly to other field attributes, -`message` specifies the Fluent attribute with the message and defaults to -`.suggestion`. `code` specifies the code that should be suggested as a -replacement and is a format string (e.g. `{field_name}` would be replaced by -the value of the `field_name` field of the struct), not a Fluent identifier. - -In the end, the `SessionDiagnostic` derive will generate an implementation of -`SessionDiagnostic` that looks like the following: - -```rust,ignore -impl SessionDiagnostic for FieldAlreadyDeclared { - fn into_diagnostic(self, sess: &'_ rustc_session::Session) -> DiagnosticBuilder<'_> { - let mut diag = sess.struct_err_with_code( - rustc_errors::DiagnosticMessage::fluent("typeck-field-already-declared"), - rustc_errors::DiagnosticId::Error("E0124") - ); - diag.set_span(self.span); - diag.span_label( - self.span, - rustc_errors::DiagnosticMessage::fluent_attr("typeck-field-already-declared", "label") - ); - diag.span_label( - self.prev_span, - rustc_errors::DiagnosticMessage::fluent_attr("typeck-field-already-declared", "previous-decl-label") - ); - diag - } -} -``` - -Now that we've defined our diagnostic, how do we [use it][use]? It's quite -straightforward, just create an instance of the struct and pass it to -`emit_err` (or `emit_warning`): - -```rust,ignore -tcx.sess.emit_err(FieldAlreadyDeclared { - field_name: f.ident, - span: f.span, - prev_span, -}); -``` - -## Reference -`#[derive(SessionDiagnostic)]` supports the following attributes: - -- `#[error(code = "...", slug = "...")]` or `#[warning(code = "...", slug = "...")]` - - _Applied to struct._ - - _Mandatory_ - - Defines the struct to be representing an error or a warning. - - `code = "..."` - - _Optional_ - - Specifies the error code. - - `slug = "..."` - - _Mandatory_ - - Uniquely identifies the diagnostic and corresponds to its Fluent message, - mandatory. -- `#[note]` or `#[note = "..."]` - - _Applied to struct or `Span` fields._ - - _Optional_ - - Adds a note sub-diagnostic. - - Value is the Fluent attribute (relative to the Fluent message specified by - `slug`) for the note's message - - Defaults to `note`. - - If applied to a `Span` field, creates a spanned note. -- `#[help]` or `#[help = "..."]` - - _Applied to struct or `Span` fields._ - - _Optional_ - - Adds a help sub-diagnostic. - - Value is the Fluent attribute (relative to the Fluent message specified by - `slug`) for the help's message - - Defaults to `help`. - - If applied to a `Span` field, creates a spanned help. -- `#[label]` or `#[label = "..."]` - - _Applied to `Span` fields._ - - _Optional_ - - Adds a label sub-diagnostic. - - Value is the Fluent attribute (relative to the Fluent message specified by - `slug`) for the label's message - - Defaults to `label`. -- `#[suggestion{,_hidden,_short,_verbose}(message = "...", code = "...")]` - - _Applied to `(Span, MachineApplicability)` or `Span` fields._ - - _Optional_ - - Adds a suggestion sub-diagnostic. - - `message = "..."` - - _Mandatory_ - - Value is the Fluent attribute (relative to the Fluent message specified - by `slug`) for the suggestion's message - - Defaults to `suggestion`. - - `code = "..."` - - _Optional_ - - Value is a format string indicating the code to be suggested as a - replacement. - -[defn]: https://github.com/rust-lang/rust/blob/bbe9d27b8ff36da56638aa43d6d0cdfdf89a4e57/compiler/rustc_typeck/src/errors.rs#L65-L74 -[use]: https://github.com/rust-lang/rust/blob/eb82facb1626166188d49599a3313fc95201f556/compiler/rustc_typeck/src/collect.rs#L981-L985 diff --git a/src/diagnostics/translation.md b/src/diagnostics/translation.md new file mode 100644 index 000000000..5c078ffb3 --- /dev/null +++ b/src/diagnostics/translation.md @@ -0,0 +1,239 @@ +# Translation +rustc's diagnostic infrastructure supports translatable diagnostics using +[Fluent]. + +## Writing translatable diagnostics +There are two ways of writing translatable diagnostics: + +1. For simple diagnostics, using a diagnostic (or subdiagnostic) derive + ("simple" diagnostics being those that don't require a lot of logic in + deciding to emit subdiagnostics and can therefore be represented as + diagnostic structs). See [the diagnostic and subdiagnostic structs + documentation](./diagnostic-structs.md). +2. Using typed identifiers with `DiagnosticBuilder` APIs (in + `SessionDiagnostic` implementations). + +When adding or changing a translatable diagnostic, you don't need to worry +about the translations, only updating the original English message. Currently, +each crate which defines translatable diagnostics has its own Fluent resource, +such as `parser.ftl` or `typeck.ftl`. + +## Fluent +Fluent is built around the idea of "asymmetric localization", which aims to +decouple the expressiveness of translations from the grammar of the source +language (English in rustc's case). Prior to translation, rustc's diagnostics +relied heavily on interpolation to build the messages shown to the users. +Interpolated strings are hard to translate because writing a natural-sounding +translation might require more, less, or just different interpolation than the +English string, all of which would require changes to the compiler's source +code to support. + +Diagnostic messages are defined in Fluent resources. A combined set of Fluent +resources for a given locale (e.g. `en-US`) is known as Fluent bundle. + +```fluent +typeck-address-of-temporary-taken = cannot take address of a temporary +``` + +In the above example, `typeck-address-of-temporary-taken` is the identifier for +a Fluent message and corresponds to the diagnostic message in English. Other +Fluent resources can be written which would correspond to a message in another +language. Each diagnostic therefore has at least one Fluent message. + +```fluent +typeck-address-of-temporary-taken = cannot take address of a temporary + .label = temporary value +``` + +By convention, diagnostic messages for subdiagnostics are specified as +"attributes" on Fluent messages (additional related messages, denoted by the +`.` syntax). In the above example, `label` is an attribute of +`typeck-address-of-temporary-taken` which corresponds to the message for the +label added to this diagnostic. + +Diagnostic messages often interpolate additional context into the message shown +to the user, such as the name of a type or of a variable. Additional context to +Fluent messages is provided as an "argument" to the diagnostic. + +```fluent +typeck-struct-expr-non-exhaustive = + cannot create non-exhaustive {$what} using struct expression +``` + +In the above example, the Fluent message refers to an argument named `what` +which is expected to exist (how arguments are provided to diagnostics is +discussed in detail later). + +You can consult the [Fluent] documentation for other usage examples of Fluent +and its syntax. + +### Guidelines for writing translatable messages +For a message to be translatable into different languages, all of the +information required by any language must be provided to the diagnostic as an +argument (not just the information required in the English message). + +As the compiler team gain more experience writing diagnostics that have all of +the information necessary to be translated into different languages, this page +will be updated with more guidance. For now, the [Fluent] documentation has +excellent examples of translating messages into different locales and the +information that needs to be provided by the code to do so. + +### Compile-time validation and typed identifiers +rustc's Fluent resources for the default locale (`en-US`) are in the +[`compiler/rustc_error_messages/locales/en-US`] directory. Currently, each crate +which defines translatable diagnostics has its own Fluent resource, such as +`parser.ftl` or `typeck.ftl`. + +rustc's `fluent_messages` macro performs compile-time validation of Fluent +resources and generates code to make it easier to refer to Fluent messages in +diagnostics. + +Compile-time validation of Fluent resources will emit any parsing errors +from Fluent resources while building the compiler, preventing invalid Fluent +resources from causing panics in the compiler. Compile-time validation also +emits an error if multiple Fluent messages have the same identifier. + +In `rustc_error_messages`, `fluent_messages` also generates a constant for each +Fluent message which can be used to refer to messages when emitting +diagnostics and guarantee that the message exists. + +```rust +fluent_messages! { + typeck => "../locales/en-US/typeck.ftl", +} +``` + +For example, given the following Fluent... + +```fluent +typeck-field-multiply-specified-in-initializer = + field `{$ident}` specified more than once + .label = used more than once + .label-previous-use = first use of `{$ident}` +``` + +...then the `fluent_messages` macro will generate: + +```rust +pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ + include_str!("../locales/en-US/typeck.ftl"), +]; + +mod fluent_generated { + mod typeck { + pub const field_multiply_specified_in_initializer: DiagnosticMessage = + DiagnosticMessage::new("typeck-field-multiply-specified-in-initializer"); + pub const label: SubdiagnosticMessage = + SubdiagnosticMessage::attr("label"); + pub const label_previous_use: SubdiagnosticMessage = + SubdiagnosticMessage::attr("previous-use-label"); + } +} +``` + +`rustc_error_messages::fluent_generated` is re-exported and primarily used as +`rustc_errors::fluent`. + +```rust +use rustc_errors::fluent; +let mut err = sess.struct_span_err(span, fluent::typeck::field_multiply_specified_in_initializer); +err.span_label(span, fluent::typeck::label); +err.span_label(previous_use_span, fluent::typeck::previous_use_label); +err.emit(); +``` + +When emitting a diagnostic, these constants can be used like shown above. + +## Internals +Various parts of rustc's diagnostic internals are modified in order to support +translation. + +### Messages +All of rustc's traditional diagnostic APIs (e.g. `struct_span_err` or `note`) +take any message that can be converted into a `DiagnosticMessage` (or +`SubdiagnosticMessage`). + +[`rustc_error_messages::DiagnosticMessage`] can represent legacy non-translatable +diagnostic messages and translatable messages. Non-translatable messages are +just `String`s. Translatable messages are just a `&'static str` with the +identifier of the Fluent message (sometimes with an additional `&'static str` +with an attribute). + +`DiagnosticMessage` never needs to be interacted with directly: +`DiagnosticMessage` constants are created for each diagnostic message in a +Fluent resource (described in more detail below), or `DiagnosticMessage`s will +either be created in the macro-generated code of a diagnostic derive. + +`rustc_error_messages::SubdiagnosticMessage` is similar, it can correspond to a +legacy non-translatable diagnostic message or the name of an attribute to a +Fluent message. Translatable `SubdiagnosticMessage`s must be combined with a +`DiagnosticMessage` (using `DiagnosticMessage::with_subdiagnostic_message`) to +be emitted (an attribute name on its own is meaningless without a corresponding +message identifier, which is what `DiagnosticMessage` provides). + +Both `DiagnosticMessage` and `SubdiagnosticMessage` implement `Into` for any +type that can be converted into a string, and converts these into +non-translatable diagnostics - this keeps all existing diagnostic calls +working. + +### Arguments +Additional context for Fluent messages which are interpolated into message +contents needs to be provided to translatable diagnostics. + +Diagnostics have a `set_arg` function that can be used to provide this +additional context to a diagnostic. + +Arguments have both a name (e.g. "what" in the earlier example) and a value. +Argument values are represented using the `DiagnosticArgValue` type, which is +just a string or a number. rustc types can implement `IntoDiagnosticArg` with +conversion into a string or a number, common types like `Ty<'tcx>` already +have such implementations. + +`set_arg` calls are handled transparently by diagnostic derives but need to be +added manually when using diagnostic builder APIs. + +### Loading +rustc makes a distinction between the "fallback bundle" for `en-US` that is used +by default and when another locale is missing a message; and the primary fluent +bundle which is requested by the user. + +Diagnostic emitters implement the `Emitter` trait which has two functions for +accessing the fallback and primary fluent bundles (`fallback_fluent_bundle` and +`fluent_bundle` respectively). + +`Emitter` also has member functions with default implementations for performing +translation of a `DiagnosticMessage` using the results of +`fallback_fluent_bundle` and `fluent_bundle`. + +All of the emitters in rustc load the fallback Fluent bundle lazily, only +reading Fluent resources and parsing them when an error message is first being +translated (for performance reasons - it doesn't make sense to do this if no +error is being emitted). `rustc_error_messages::fallback_fluent_bundle` returns +a `std::lazy::Lazy` which is provided to emitters and evaluated +in the first call to `Emitter::fallback_fluent_bundle`. + +The primary Fluent bundle (for the user's desired locale) is expected to be +returned by `Emitter::fluent_bundle`. This bundle is used preferentially when +translating messages, the fallback bundle is only used if the primary bundle is +missing a message or not provided. + +As of June 2022, there are no locale bundles +distributed with the compiler, but mechanisms are implemented for loading +bundles. + +- `-Ztranslate-additional-ftl` can be used to load a specific resource as the + primary bundle for testing purposes. +- `-Ztranslate-lang` can be provided a language identifier (something like + `en-US`) and will load any Fluent resources found in + `$sysroot/share/locale/$locale/` directory (both the user provided + sysroot and any sysroot candidates). + +Primary bundles are not currently loaded lazily and if requested will be loaded +at the start of compilation regardless of whether an error occurs. Lazily +loading primary bundles is possible if it can be assumed that loading a bundle +won't fail. Bundle loading can fail if a requested locale is missing, Fluent +files are malformed, or a message is duplicated in multiple resources. + +[Fluent]: https://projectfluent.org +[`compiler/rustc_error_messages/locales/en-US`]: https://github.com/rust-lang/rust/tree/master/compiler/rustc_error_messages/locales/en-US +[`rustc_error_messages::DiagnosticMessage`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_messages/enum.DiagnosticMessage.html From cddd59fff853b9e4d7c556d34168635be304978a Mon Sep 17 00:00:00 2001 From: Edwin Date: Sat, 18 Jun 2022 04:31:49 +0100 Subject: [PATCH 1680/1812] Add an "is" and rearange "We next" to "Next, we" (#1369) --- src/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/overview.md b/src/overview.md index a3c2258e8..ea4b3ca04 100644 --- a/src/overview.md +++ b/src/overview.md @@ -83,9 +83,9 @@ try to recover, parsing a superset of Rust's grammar, while also emitting an err ### HIR lowering -We next take the AST and convert it to [High-Level Intermediate +Next, we take the AST and convert it to [High-Level Intermediate Representation (HIR)][hir], a more compiler-friendly representation of the -AST. This process called "lowering". It involves a lot of desugaring of things +AST. This process is called "lowering". It involves a lot of desugaring of things like loops and `async fn`. We then use the HIR to do [*type inference*] (the process of automatic From bda3e0b23c0fb7b882622f0bc4bec76ea629f4b2 Mon Sep 17 00:00:00 2001 From: Omer Tuchfeld Date: Sat, 18 Jun 2022 12:42:08 +0200 Subject: [PATCH 1681/1812] Fix small `src/diagnostics.md` typo (#1370) --- src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 7ef33d38e..dbf5cf99e 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -888,7 +888,7 @@ For example, the `Iterator` trait can be annotated in the following way: #[rustc_on_unimplemented( on( _Self="&str", - note="call `.chars()` or `.as_bytes()` on `{Self}" + note="call `.chars()` or `.as_bytes()` on `{Self}`" ), message="`{Self}` is not an iterator", label="`{Self}` is not an iterator", From 12a613eddbfd67a4c1e70cbca6d3c9f65df59907 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 21 Jun 2022 06:26:19 +0200 Subject: [PATCH 1682/1812] make clear that other versions can work (#1373) --- src/rustc-driver-getting-diagnostics.md | 2 +- src/rustc-driver-interacting-with-the-ast.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rustc-driver-getting-diagnostics.md b/src/rustc-driver-getting-diagnostics.md index a7251c2f0..327415e5a 100644 --- a/src/rustc-driver-getting-diagnostics.md +++ b/src/rustc-driver-getting-diagnostics.md @@ -6,7 +6,7 @@ To get diagnostics from the compiler, configure `rustc_interface::Config` to output diagnostic to a buffer, -and run `TyCtxt.analysis`. The following should be compiled +and run `TyCtxt.analysis`. The following was tested with `nightly-2022-06-05` (See [here][example] for the complete example): diff --git a/src/rustc-driver-interacting-with-the-ast.md b/src/rustc-driver-interacting-with-the-ast.md index 86732de18..d70264fe4 100644 --- a/src/rustc-driver-interacting-with-the-ast.md +++ b/src/rustc-driver-interacting-with-the-ast.md @@ -5,7 +5,7 @@ ## Getting the type of an expression To get the type of an expression, use the `global_ctxt` to get a `TyCtxt`. -The following should be compiled with `nightly-2022-06-05` +The following was tested with `nightly-2022-06-05` (see [here][example] for the complete example): [example]: https://github.com/rust-lang/rustc-dev-guide/blob/master/examples/rustc-driver-interacting-with-the-ast.rs From a3d2f904814d8d2a7780f41db0d0ad9e264ca6b0 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 21 Jun 2022 11:45:30 +0200 Subject: [PATCH 1683/1812] small improves (#1371) Co-authored-by: Yuki Okushi --- src/diagnostics.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index dbf5cf99e..0f0bfd895 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -273,19 +273,20 @@ There are two main ways to find where a given error is emitted: - `grep` for either a sub-part of the error message/label or error code. This usually works well and is straightforward, but there are some cases where - the error emitting code is removed from the code where the error is + the code emitting the error is removed from the code where the error is constructed behind a relatively deep call-stack. Even then, it is a good way to get your bearings. -- Invoking `rustc` with the nightly-only flag `-Z treat-err-as-bug=1`, which +- Invoking `rustc` with the nightly-only flag `-Z treat-err-as-bug=1` will treat the first error being emitted as an Internal Compiler Error, which - allows you to use the environment variable `RUST_BACKTRACE=full` to get a + allows you to get a stack trace at the point the error has been emitted. Change the `1` to - something else if you whish to trigger on a later error. Some limitations - with this approach is that some calls get elided from the stack trace because - they get inlined in the compiled `rustc`, and the same problem we faced with - the prior approach, where the _construction_ of the error is far away from - where it is _emitted_. In some cases we buffer multiple errors in order to - emit them in order. + something else if you wish to trigger on a later error. + + There are limitations with this approach: + - Some calls get elided from the stack trace because they get inlined in the compiled `rustc`. + - The _construction_ of the error is far away from where it is _emitted_, + a problem similar to the one we faced with the `grep` approach. + In some cases, we buffer multiple errors in order to emit them in order. The regular development practices apply: judicious use of `debug!()` statements and use of a debugger to trigger break points in order to figure out in what From 048d925f0a955aac601c4160c0e7f05771bcf63b Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 21 Jun 2022 15:25:34 +0200 Subject: [PATCH 1684/1812] not obvious what Ex is, so rather get rid (#1372) --- src/SUMMARY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 302976296..e25eb284e 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -76,8 +76,8 @@ - [Prologue](./part-3-intro.md) - [Command-line arguments](./cli.md) - [The Rustc Driver and Interface](./rustc-driver.md) - - [Ex: Type checking through `rustc_interface`](./rustc-driver-interacting-with-the-ast.md) - - [Ex: Getting diagnostics through `rustc_interface`](./rustc-driver-getting-diagnostics.md) + - [Example: Type checking](./rustc-driver-interacting-with-the-ast.md) + - [Example: Getting diagnostics](./rustc-driver-getting-diagnostics.md) - [Syntax and the AST](./syntax-intro.md) - [Lexing and Parsing](./the-parser.md) - [Macro expansion](./macro-expansion.md) From 4505f706b1e5f20aade72677873b0daa5b5c0b69 Mon Sep 17 00:00:00 2001 From: Alcaro Date: Sun, 26 Jun 2022 14:02:21 +0200 Subject: [PATCH 1685/1812] humorust: Forbid pineapple on pizza (#1374) --- src/appendix/humorust.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/appendix/humorust.md b/src/appendix/humorust.md index c502527d5..bc8255439 100644 --- a/src/appendix/humorust.md +++ b/src/appendix/humorust.md @@ -12,3 +12,4 @@ enlightening? - [The Nomicon Intro](https://doc.rust-lang.org/stable/nomicon/) - [`rustc-ty` renaming punfest](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rustc-ty.20naming.20bikeshed.20.2F.20punfest.20%28was.3A.20design.20meeting.202.2E.2E.2E/near/189906455) - [try using their name "ferris" instead](https://github.com/rust-lang/rust/pull/91476) +- [Forbid pineapple on pizza](https://github.com/rust-lang/rust/pull/70645) From 03fafb5d85bb9dc619adcb19fdfd597e5af5f64d Mon Sep 17 00:00:00 2001 From: EdwinRy Date: Mon, 27 Jun 2022 01:29:25 +0100 Subject: [PATCH 1686/1812] Few readability fixes --- src/salsa.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/salsa.md b/src/salsa.md index d9190f646..e0303127e 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -60,7 +60,7 @@ is going to be checked, which could be costly. Salsa only needs to check each downstream computation until it finds one that isn't changed. At that point, it won't check other derived computations since they wouldn't need to change. -It's is helpful to think about this as a graph with nodes. Each derived value +It's helpful to think about this as a graph with nodes. Each derived value has a dependency on other values, which could themselves be either base or derived. Base values don't have a dependency. @@ -71,12 +71,12 @@ J <- B <--+ ``` When an input `I` changes, the derived value `A` could change. The derived -value `B` , which does not depend on `I`, `A`, or any value derived from `A` or +value `B`, which does not depend on `I`, `A`, or any value derived from `A` or `I`, is not subject to change. Therefore, Salsa can reuse the computation done for `B` in the past, without having to compute it again. The computation could also terminate early. Keeping the same graph as before, -say that input `I` has changed in some way (and input `J` hasn't) but, when +say that input `I` has changed in some way (and input `J` hasn't), but when computing `A` again, it's found that `A` hasn't changed from the previous computation. This leads to an "early termination", because there's no need to check if `C` needs to change, since both `C` direct inputs, `A` and `B`, From 11b40654fd3ab0002e2d079f08d644c2e43041d6 Mon Sep 17 00:00:00 2001 From: David Wood Date: Tue, 28 Jun 2022 17:17:15 +0100 Subject: [PATCH 1687/1812] diagnostics: structs with new slug syntax (#1377) Update the documentation for diagnostic structs to use the new typed identifier syntax for referring to slugs. Signed-off-by: David Wood --- src/diagnostics/diagnostic-structs.md | 58 +++++++++++++++++---------- 1 file changed, 37 insertions(+), 21 deletions(-) diff --git a/src/diagnostics/diagnostic-structs.md b/src/diagnostics/diagnostic-structs.md index cab9b0c2f..f28350e03 100644 --- a/src/diagnostics/diagnostic-structs.md +++ b/src/diagnostics/diagnostic-structs.md @@ -17,7 +17,7 @@ shown below: ```rust,ignore #[derive(SessionDiagnostic)] -#[error(code = "E0124", slug = "typeck-field-already-declared")] +#[error(typeck::field_already_declared, code = "E0124")] pub struct FieldAlreadyDeclared { pub field_name: Ident, #[primary_span] @@ -37,12 +37,13 @@ the `code` sub-attribute. Specifying a `code` isn't mandatory, but if you are porting a diagnostic that uses `DiagnosticBuilder` to use `SessionDiagnostic` then you should keep the code if there was one. -Both `#[error(..)]` and `#[warning(..)]` must set a value for the `slug` -sub-attribute. `slug` uniquely identifies the diagnostic and is also how the -compiler knows what error message to emit (in the default locale of the -compiler, or in the locale requested by the user). See [translation -documentation](./translation.md) to learn more about how translatable error -messages are written. +Both `#[error(..)]` and `#[warning(..)]` must provide a slug as the first +positional argument (a path to an item in `rustc_errors::fluent::*`). A slug +uniquely identifies the diagnostic and is also how the compiler knows what +error message to emit (in the default locale of the compiler, or in the locale +requested by the user). See [translation documentation](./translation.md) to +learn more about how translatable error messages are written and how slug +items are generated. In our example, the Fluent message for the "field already declared" diagnostic looks like this: @@ -54,7 +55,7 @@ typeck-field-already-declared = .previous-decl-label = `{$field_name}` first declared here ``` -`typeck-field-already-declared` is the `slug` from our example and is followed +`typeck-field-already-declared` is the slug from our example and is followed by the diagnostic message. Every field of the `SessionDiagnostic` which does not have an annotation is @@ -147,15 +148,22 @@ tcx.sess.emit_err(FieldAlreadyDeclared { ### Reference `#[derive(SessionDiagnostic)]` supports the following attributes: -- `#[error(code = "...", slug = "...")]` or `#[warning(code = "...", slug = "...")]` +- `#[error(slug, code = "...")]` or `#[warning(slug, code = "...")]` - _Applied to struct._ - _Mandatory_ - Defines the struct to be representing an error or a warning. - - `code = "..."` (_Optional_) - - Specifies the error code. - - `slug = "..."` (_Mandatory_) + - Slug (_Mandatory_) - Uniquely identifies the diagnostic and corresponds to its Fluent message, mandatory. + - A path to an item in `rustc_errors::fluent`. Always in a module starting + with a Fluent resource name (which is typically the name of the crate + that the diagnostic is from), e.g. + `rustc_errors::fluent::typeck::field_already_declared` + (`rustc_errors::fluent` is implicit in the attribute, so just + `typeck::field_already_declared`). + - See [translation documentation](./translation.md). + - `code = "..."` (_Optional_) + - Specifies the error code. - `#[note]` or `#[note = "..."]` (_Optional_) - _Applied to struct or `Span`/`()` fields._ - Adds a note subdiagnostic. @@ -215,12 +223,12 @@ shown below: ```rust #[derive(SessionSubdiagnostic)] pub enum ExpectedReturnTypeLabel<'tcx> { - #[label(slug = "typeck-expected-default-return-type")] + #[label(typeck::expected_default_return_type)] Unit { #[primary_span] span: Span, }, - #[label(slug = "typeck-expected-return-type")] + #[label(typeck::expected_return_type)] Other { #[primary_span] span: Span, @@ -239,11 +247,12 @@ attribute applied to the struct or each variant, one of: - `#[help(..)]` for defining a help - `#[suggestion{,_hidden,_short,_verbose}(..)]` for defining a suggestion -All of the above must have a value set for the `slug` sub-attribute. `slug` -uniquely identifies the diagnostic and is also how the compiler knows what -error message to emit (in the default locale of the compiler, or in the locale -requested by the user). See [translation documentation](./translation.md) to -learn more about how translatable error messages are written. +All of the above must provide a slug as the first positional argument (a path +to an item in `rustc_errors::fluent::*`). A slug uniquely identifies the +diagnostic and is also how the compiler knows what error message to emit (in +the default locale of the compiler, or in the locale requested by the user). +See [translation documentation](./translation.md) to learn more about how +translatable error messages are written and how slug items are generated. In our example, the Fluent message for the "expected return type" label looks like this: @@ -315,13 +324,20 @@ diagnostic struct. ### Reference `#[derive(SessionSubdiagnostic)]` supports the following attributes: -- `#[label(slug = "...")]`, `#[help(slug = "...")]` or `#[note(slug = "...")]` +- `#[label(slug)]`, `#[help(slug)]` or `#[note(slug)]` - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._ - _Mandatory_ - Defines the type to be representing a label, help or note. - - `slug = "..."` (_Mandatory_) + - Slug (_Mandatory_) - Uniquely identifies the diagnostic and corresponds to its Fluent message, mandatory. + - A path to an item in `rustc_errors::fluent`. Always in a module starting + with a Fluent resource name (which is typically the name of the crate + that the diagnostic is from), e.g. + `rustc_errors::fluent::typeck::field_already_declared` + (`rustc_errors::fluent` is implicit in the attribute, so just + `typeck::field_already_declared`). + - See [translation documentation](./translation.md). - `#[suggestion{,_hidden,_short,_verbose}(message = "...", code = "...", applicability = "...")]` - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._ - _Mandatory_ From f423a3ad9571a6dbebc7e65849ef5c08672cf295 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Fri, 1 Jul 2022 11:35:13 -0400 Subject: [PATCH 1688/1812] leave formatOnSave to the user (#1380) --- src/building/suggested.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 6c0b7135e..df79aed79 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -36,7 +36,7 @@ you can write: This document explains the state of debugging tools support in the Rust compiler (rustc). -The document gives an overview of debugging tools like GDB, LLDB etc. and infrastructure -around Rust compiler to debug Rust code. If you want to learn how to debug the Rust compiler -itself, then you must see [Debugging the Compiler] page. +It gives an overview of GDB, LLDB, +as well as infrastructure around Rust compiler to debug Rust code. +If you want to learn how to debug the Rust compiler itself, +see [Debugging the Compiler]. -The material is gathered from YouTube video [Tom Tromey discusses debugging support in rustc]. +The material is gathered from the video, +[Tom Tromey discusses debugging support in rustc]. ## Preliminaries @@ -44,17 +46,15 @@ You can also invent your own tags and attributes. ### GDB -We have our own fork of GDB - [https://github.com/rust-dev-tools/gdb] - #### Rust expression parser -To be able to show debug output we need an expression parser. -This (GDB) expression parser is written in [Bison] and is only a subset of Rust expressions. -This means that this parser can parse only a subset of Rust expressions. -GDB parser was written from scratch and has no relation to any other parser. -For example, this parser is not related to Rustc's parser. +To be able to show debug output, we need an expression parser. +This (GDB) expression parser is written in [Bison], +and can parse only a subset of Rust expressions. +GDB parser was written from scratch and has no relation to any other parser, +including that of rustc. -GDB has Rust like value and type output. It can print values and types in a way +GDB has Rust-like value and type output. It can print values and types in a way that look like Rust syntax in the output. Or when you print a type as [ptype] in GDB, it also looks like Rust source code. Checkout the documentation in the [manual for GDB/Rust]. @@ -64,17 +64,19 @@ Expression parser has a couple of extensions in it to facilitate features that y with Rust. Some limitations are listed in the [manual for GDB/Rust]. There is some special code in the DWARF reader in GDB to support the extensions. -A couple of examples of DWARF reader support needed are as follows - +A couple of examples of DWARF reader support needed are as follows: -1. Enum: Needed for support for enum types. The Rustc writes the information about enum into -DWARF and GDB reads the DWARF to understand where is the tag field or is there a tag -field or is the tag slot shared with non-zero optimization etc. +1. Enum: Needed for support for enum types. + The Rust compiler writes the information about enum into DWARF, + and GDB reads the DWARF to understand where is the tag field, + or if there is a tag field, + or if the tag slot is shared with non-zero optimization etc. 2. Dissect trait objects: DWARF extension where the trait object's description in the DWARF -also points to a stub description of the corresponding vtable which in turn points to the -concrete type for which this trait object exists. This means that you can do a `print *object` -for that trait object, and GDB will understand how to find the correct type of the payload in -the trait object. + also points to a stub description of the corresponding vtable which in turn points to the + concrete type for which this trait object exists. This means that you can do a `print *object` + for that trait object, and GDB will understand how to find the correct type of the payload in + the trait object. **TODO**: Figure out if the following should be mentioned in the GDB-Rust document rather than this guide page so there is no duplication. This is regarding the following comments: @@ -89,49 +91,28 @@ implements the gdb @ extension. > @tromey do you think we should mention this part in the GDB-Rust document rather than this document so there is no duplication etc.? -#### Developer notes - -* This work is now upstream. Bugs can be reported in [GDB Bugzilla]. - ### LLDB -Fork of LLVM project - [https://github.com/rust-lang/llvm-project] - -LLDB currently only works on macOS because of a dependency issue. This issue was easier to -solve for macOS as compared to Linux. However, Tom has a possible solution which can enable -us to ship LLDB everywhere. - #### Rust expression parser This expression parser is written in C++. It is a type of [Recursive Descent parser]. -Implements slightly less of the Rust language than GDB. LLDB has Rust like value and type output. - -#### Parser extensions - -There is some special code in the DWARF reader in LLDB to support the extensions. -A couple of examples of DWARF reader support needed are as follows - - -1. Enum: Needed for support for enum types. The Rustc writes the information about -enum into DWARF and LLDB reads the DWARF to understand where is the tag field or -is there a tag field or is the tag slot shared with non-zero optimization etc. -In other words, it has enum support as well. +It implements slightly less of the Rust language than GDB. +LLDB has Rust-like value and type output. #### Developer notes -* None of the LLDB work is upstream. This [rust-lang/lldb wiki page] explains a few details. -* The reason for forking LLDB is that LLDB recently removed all the other language plugins -due to lack of maintenance. * LLDB has a plugin architecture but that does not work for language support. -* LLDB is available via Rust build (`rustup`). * GDB generally works better on Linux. -## DWARF and Rustc +## DWARF and `rustc` [DWARF] is the standard way compilers generate debugging information that debuggers read. -It is _the_ debugging format on macOS and Linux. It is a multi-language, extensible format -and is mostly good enough for Rust's purposes. Hence, the current implementation reuses DWARF's -concepts. This is true even if some of the concepts in DWARF do not align with Rust -semantically because generally there can be some kind of mapping between the two. +It is _the_ debugging format on macOS and Linux. +It is a multi-language and extensible format, +and is mostly good enough for Rust's purposes. +Hence, the current implementation reuses DWARF's concepts. +This is true even if some of the concepts in DWARF do not align with Rust semantically because, +generally, there can be some kind of mapping between the two. We have some DWARF extensions that the Rust compiler emits and the debuggers understand that are _not_ in the DWARF standard. @@ -169,26 +150,6 @@ This section is from the talk about certain aspects of development. ## What is missing -### Shipping GDB in Rustup - -Tracking issue: [https://github.com/rust-lang/rust/issues/34457] - -Shipping GDB requires change to Rustup delivery system. To manage Rustup build size and -times we need to build GDB separately, on its own and somehow provide the artifacts produced -to be included in the final build. However, if we can ship GDB with rustup, it will simplify -the development process by having compiler emit new debug info which can be readily consumed. - -Main issue in achieving this is setting up dependencies. One such dependency is Python. That -is why we have our own fork of GDB because one of the drivers is patched on Rust's side to -check the correct version of Python (Python 2.7 in this case. *Note: Python3 is not chosen -for this purpose because Python's stable ABI is limited and is not sufficient for GDB's needs. -See [https://docs.python.org/3/c-api/stable.html]*). - -This is to keep updates to debugger as fast as possible as we make changes to the debugging symbols. -In essence, to ship the debugger as soon as new debugging info is added. GDB only releases -every six months or so. However, the changes that are -not related to Rust itself should ideally be first merged to upstream eventually. - ### Code signing for LLDB debug server on macOS According to Wikipedia, [System Integrity Protection] is @@ -235,7 +196,7 @@ This is why we need to change LLVM first because that is emitted first and not D This is a kind of metadata that you construct and hand-off to LLVM. For the Rustc/LLVM hand-off some LLVM DI builder methods are called to construct representation of a type. -The steps of this process are as follows - +The steps of this process are as follows: 1. LLVM needs changing. @@ -329,9 +290,11 @@ debugger because the debugger alone has access to the memory. Both GDB (gcc) and have this feature. LLDB uses Clang to compile code to JIT and GDB can do the same with GCC. Both debuggers expression evaluation implement both a superset and a subset of Rust. -They implement just the expression language but they also add some extensions like GDB has -convenience variables. Therefore, if you are taking this route then you not only need -to do this bridge but may have to add some mode to let the compiler understand some extensions. +They implement just the expression language, +but they also add some extensions like GDB has convenience variables. +Therefore, if you are taking this route, +then you not only need to do this bridge, +but may have to add some mode to let the compiler understand some extensions. [Tom Tromey discusses debugging support in rustc]: https://www.youtube.com/watch?v=elBxMRSNYr4 [Debugging the Compiler]: compiler-debugging.md From 7a9901194752a0e9bf3da6cc2cff0a4383c877b1 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Thu, 14 Jul 2022 22:41:12 +0200 Subject: [PATCH 1700/1812] update date reference on MIR inliner cc #1379 --- src/profiling.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/profiling.md b/src/profiling.md index 711248f19..e4148e68e 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -108,5 +108,6 @@ The llvm-lines output is affected by several options. MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Z mir-opt-level=1"`, level 0 adds 0.3GB and level 2 removes 0.2GB. -As of January 2021, inlining currently only happens in -LLVM but this might change in the future. +As of July 2022, +inlining currently only happens in LLVM, +but this might change in the future. From 0eb86d9bfea727bde77b6fb2a0261510f7b82983 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Fri, 15 Jul 2022 00:44:47 +0200 Subject: [PATCH 1701/1812] address review comment https://github.com/rust-lang/rustc-dev-guide/pull/1392#discussion_r921560851 --- src/profiling.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/profiling.md b/src/profiling.md index e4148e68e..ada497d88 100644 --- a/src/profiling.md +++ b/src/profiling.md @@ -109,5 +109,5 @@ The llvm-lines output is affected by several options. MIR optimizations have little impact. Compared to the default `RUSTFLAGS="-Z mir-opt-level=1"`, level 0 adds 0.3GB and level 2 removes 0.2GB. As of July 2022, -inlining currently only happens in LLVM, -but this might change in the future. +inlining happens in LLVM and GCC codegen backends, +missing only in the Cranelift one. From 2e754ba3d75e883299782e7b7215c866364ecd55 Mon Sep 17 00:00:00 2001 From: 5225225 <5225225@mailbox.org> Date: Sat, 16 Jul 2022 11:27:44 +0100 Subject: [PATCH 1702/1812] Rename debugging_opts to unstable_opts, use link --- src/mir/optimizations.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index add22c6fc..f81f18864 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -107,9 +107,10 @@ the pass. To enable working with slow or otherwise experimental optimization pas you can specify the `-Z mir-opt-level` debug flag. You can find the definitions of the levels in the [compiler MCP]. If you are developing a MIR pass and want to query whether your optimization pass should run, you can check the -current level using `tcx.sess.opts.debugging_opts.mir_opt_level`. +current level using [`tcx.sess.opts.unstable_opts.mir_opt_level`][mir_opt_level]. [compiler MCP]: https://github.com/rust-lang/compiler-team/issues/319 +[mir_opt_level]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/config/struct.UnstableOptions.html#structfield.mir_opt_level ## Optimization fuel From 8bbee4f5a3a930778451e3481072b64f7843f731 Mon Sep 17 00:00:00 2001 From: davidrusu Date: Sat, 16 Jul 2022 10:18:19 -0400 Subject: [PATCH 1703/1812] typo: monomorph docs --- src/backend/monomorph.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index 7111c634a..fe61bcb8a 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -61,7 +61,7 @@ units](../appendix/glossary.md#codegen-unit). For better incremental build times, the CGU partitioner creates two CGU for each source level modules. One is for "stable" i.e. non-generic code and the other is more volatile code i.e. -monoporphized/specialized instances. +monomorphized/specialized instances. For depenencies, consider Crate A and Crate B, such that Crate B depends on Crate A. The following table lists different scenarios for a function in Crate A that might be used by one From 56eb8b69b5136e4dbf3c86c11e843555ba99485f Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 16 Jul 2022 23:45:36 +0200 Subject: [PATCH 1704/1812] fix some typos (#1398) --- src/asm.md | 2 +- src/backend/monomorph.md | 2 +- src/building/bootstrapping.md | 2 +- src/lang-items.md | 4 ++-- src/salsa.md | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/asm.md b/src/asm.md index 2c177164e..cd5430ffd 100644 --- a/src/asm.md +++ b/src/asm.md @@ -101,7 +101,7 @@ pub enum InlineAsmOperand { The `asm!` macro is implemented in `rustc_builtin_macros` and outputs an `InlineAsm` AST node. The template string is parsed using `fmt_macros`, positional and named operands are resolved to -explicit operand indicies. Since target information is not available to macro invocations, +explicit operand indices. Since target information is not available to macro invocations, validation of the registers and register classes is deferred to AST lowering. ## HIR diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index fe61bcb8a..416151ca9 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -63,7 +63,7 @@ For better incremental build times, the CGU partitioner creates two CGU for each modules. One is for "stable" i.e. non-generic code and the other is more volatile code i.e. monomorphized/specialized instances. -For depenencies, consider Crate A and Crate B, such that Crate B depends on Crate A. +For dependencies, consider Crate A and Crate B, such that Crate B depends on Crate A. The following table lists different scenarios for a function in Crate A that might be used by one or more modules in Crate B. diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 31f9b61d6..fd54de20c 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -231,7 +231,7 @@ artifacts into the appropriate place, skipping the cargo invocation. ### Cross-compiling rustc -*Cross-compiling* is the process of compiling code that will run on another archicture. +*Cross-compiling* is the process of compiling code that will run on another architecture. For instance, you might want to build an ARM version of rustc using an x86 machine. Building stage2 `std` is different when you are cross-compiling. diff --git a/src/lang-items.md b/src/lang-items.md index c5774c43b..867c42144 100644 --- a/src/lang-items.md +++ b/src/lang-items.md @@ -6,7 +6,7 @@ exists. The marker is the attribute `#[lang = "..."]`, and there are various dif `...`, i.e. various different 'lang items'. Many such lang items can be implemented only in one sensible way, such as `add` (`trait -core::ops::Add`) or `future_trait` (`trait core::future::Future`). Others can be overriden to +core::ops::Add`) or `future_trait` (`trait core::future::Future`). Others can be overridden to achieve some specific goals; for example, you can control your binary's entrypoint. Features provided by lang items include: @@ -45,7 +45,7 @@ if let Some(sized_trait_def_id) = tcx.lang_items().sized_trait() { ``` Note that `sized_trait()` returns an `Option`, not the `DefId` itself. -That's because language items are defined in the standard libray, so if someone compiles with +That's because language items are defined in the standard library, so if someone compiles with `#![no_core]` (or for some lang items, `#![no_std]`), the lang item may not be present. You can either: diff --git a/src/salsa.md b/src/salsa.md index e0303127e..afa01eda2 100644 --- a/src/salsa.md +++ b/src/salsa.md @@ -196,7 +196,7 @@ struct MyDatabase { runtime : salsa::Runtime, } ///And this trait has to be implemented -impl salsa::Databse for MyDatabase { +impl salsa::Database for MyDatabase { fn salsa_runtime(&self) -> &salsa::Runtime { &self.runtime } From ade9352771074ef49bd80aa43abbdc5c41f182b6 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 16 Jul 2022 12:38:55 +0200 Subject: [PATCH 1705/1812] use relative links Used the following command, followed by some manual tweaking: sd 'https://rustc-dev-guide.rust-lang.org/(.+).html' '$1.md' (fd) --- src/building/how-to-build-and-run.md | 2 +- src/contributing.md | 4 +-- src/implementing_new_features.md | 4 +-- src/macro-expansion.md | 2 +- src/mir/optimizations.md | 10 +++--- src/overview.md | 50 ++++++++++++++-------------- src/parallel-rustc.md | 14 ++++---- 7 files changed, 43 insertions(+), 43 deletions(-) diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 39715bcd2..25344fb21 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -66,7 +66,7 @@ If you set `download-ci-llvm = true`, in some circumstances, such as when updating the version of LLVM used by `rustc`, you may want to temporarily disable this feature. See the ["Updating LLVM" section] for more. -["Updating LLVM" section]: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html?highlight=download-ci-llvm#feature-updates +["Updating LLVM" section]: /backend/updating-llvm.md#feature-updates If you have already built `rustc` and you change settings related to LLVM, then you may have to execute `rm -rf build` for subsequent configuration changes to take effect. Note that `./x.py diff --git a/src/contributing.md b/src/contributing.md index 7eeb0240b..fed14afbd 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -583,7 +583,7 @@ are: page! * Don't be afraid to ask! The Rust community is friendly and helpful. -[rustc dev guide]: https://rustc-dev-guide.rust-lang.org/about-this-guide.html +[rustc dev guide]: about-this-guide.md [gdfrustc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ [gsearchdocs]: https://www.google.com/search?q=site:doc.rust-lang.org+your+query+here [stddocs]: https://doc.rust-lang.org/std @@ -592,5 +592,5 @@ are: [rustforge]: https://forge.rust-lang.org/ [tlgba]: https://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/ [ro]: https://www.rustaceans.org/ -[rctd]: https://rustc-dev-guide.rust-lang.org/tests/intro.html +[rctd]: tests/intro.md [cheatsheet]: https://bors.rust-lang.org/ diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md index 73a3543cd..ef6ae6179 100644 --- a/src/implementing_new_features.md +++ b/src/implementing_new_features.md @@ -105,8 +105,8 @@ for stabilization in a checklist, e.g., - [ ] Implement the RFC. (CC @rust-lang/compiler -- can anyone write up mentoring instructions?) -- [ ] Adjust the documentation. ([See instructions on rustc-dev-guide.](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs)) -- [ ] Stabilize the feature. ([See instructions on rustc-dev-guide.](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr)) +- [ ] Adjust the documentation. ([See instructions on rustc-dev-guide.](stabilization_guide.md#documentation-prs)) +- [ ] Stabilize the feature. ([See instructions on rustc-dev-guide.](stabilization_guide.md#stabilization-pr)) ``` ## Stability in code diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 840bfabe8..9b0f353d1 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -88,7 +88,7 @@ iteration, this represents a compile error. Here is the [algorithm][original]: 0. Put the macro back in the queue 1. Continue to next iteration... -[defpath]: https://rustc-dev-guide.rust-lang.org/hir.html?highlight=def,path#identifiers-in-the-hir +[defpath]: hir.md#identifiers-in-the-hir [`NodeId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/node_id/struct.NodeId.html [`InvocationCollector`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/expand/struct.InvocationCollector.html [`DefId`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/def_id/struct.DefId.html diff --git a/src/mir/optimizations.md b/src/mir/optimizations.md index f81f18864..aa0a62fb0 100644 --- a/src/mir/optimizations.md +++ b/src/mir/optimizations.md @@ -8,8 +8,8 @@ to do, so compilation is faster. Note that since MIR is generic (not effective; we can optimize the generic version, so all of the monomorphizations are cheaper! -[mir]: https://rustc-dev-guide.rust-lang.org/mir/index.html -[monomorph]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html#mono +[mir]: /mir/index.md +[monomorph]: /appendix/glossary.md#mono MIR optimizations run after borrow checking. We run a series of optimization passes over the MIR to improve it. Some passes are required to run on all code, @@ -22,9 +22,9 @@ run and that some validation has occurred. Then, it [steals][steal] the MIR, optimizes it, and returns the improved MIR. [optmir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/fn.optimized_mir.html -[query]: https://rustc-dev-guide.rust-lang.org/query.html -[defid]: https://rustc-dev-guide.rust-lang.org/appendix/glossary.html#def-id -[steal]: https://rustc-dev-guide.rust-lang.org/mir/passes.html?highlight=steal#stealing +[query]: /query.md +[defid]: /appendix/glossary.md#def-id +[steal]: /mir/passes.md#stealing ## Quickstart for adding a new optimization diff --git a/src/overview.md b/src/overview.md index 09d87223d..de6c88e7e 100644 --- a/src/overview.md +++ b/src/overview.md @@ -136,21 +136,21 @@ binary. [String interning]: https://en.wikipedia.org/wiki/String_interning [`rustc_lexer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html -[`rustc_driver`]: https://rustc-dev-guide.rust-lang.org/rustc-driver.html +[`rustc_driver`]: rustc-driver.md [`rustc_interface::Config`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/interface/struct.Config.html -[lex]: https://rustc-dev-guide.rust-lang.org/the-parser.html +[lex]: the-parser.md [`StringReader`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/lexer/struct.StringReader.html [`rustc_parse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [parser]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html [hir]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html -[*type inference*]: https://rustc-dev-guide.rust-lang.org/type-inference.html -[*trait solving*]: https://rustc-dev-guide.rust-lang.org/traits/resolution.html -[*type checking*]: https://rustc-dev-guide.rust-lang.org/type-checking.html -[mir]: https://rustc-dev-guide.rust-lang.org/mir/index.html -[borrow checking]: https://rustc-dev-guide.rust-lang.org/borrow_check.html -[mir-opt]: https://rustc-dev-guide.rust-lang.org/mir/optimizations.html +[*type inference*]: type-inference.md +[*trait solving*]: traits/resolution.md +[*type checking*]: type-checking.md +[mir]: mir/index.md +[borrow checking]: borrow_check.md +[mir-opt]: mir/optimizations.md [`simplify_try`]: https://github.com/rust-lang/rust/pull/66282 -[codegen]: https://rustc-dev-guide.rust-lang.org/backend/codegen.html +[codegen]: backend/codegen.md [parse_nonterminal]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html#method.parse_nonterminal [parse_crate_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html#method.parse_crate_mod [parse_mod]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html#method.parse_mod @@ -364,21 +364,21 @@ For more details on bootstrapping, see - Where do phases diverge for cross-compilation to machine code across different platforms? --> - + # References - Command line parsing - - Guide: [The Rustc Driver and Interface](https://rustc-dev-guide.rust-lang.org/rustc-driver.html) + - Guide: [The Rustc Driver and Interface](rustc-driver.md) - Driver definition: [`rustc_driver`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_driver/) - Main entry point: [`rustc_session::config::build_session_options`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/config/fn.build_session_options.html) - Lexical Analysis: Lex the user program to a stream of tokens - - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) + - Guide: [Lexing and Parsing](the-parser.md) - Lexer definition: [`rustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html) - Main entry point: [`rustc_lexer::first_token`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/fn.first_token.html) - Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST) - - Guide: [Lexing and Parsing](https://rustc-dev-guide.rust-lang.org/the-parser.html) - - Guide: [Macro Expansion](https://rustc-dev-guide.rust-lang.org/macro-expansion.html) - - Guide: [Name Resolution](https://rustc-dev-guide.rust-lang.org/name-resolution.html) + - Guide: [Lexing and Parsing](the-parser.md) + - Guide: [Macro Expansion](macro-expansion.md) + - Guide: [Name Resolution](name-resolution.md) - Parser definition: [`rustc_parse`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html) - Main entry points: - [Entry point for first file in crate](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/passes/fn.parse.html) @@ -388,34 +388,34 @@ For more details on bootstrapping, see - Feature gating: **TODO** - Early linting: **TODO** - The High Level Intermediate Representation (HIR) - - Guide: [The HIR](https://rustc-dev-guide.rust-lang.org/hir.html) - - Guide: [Identifiers in the HIR](https://rustc-dev-guide.rust-lang.org/hir.html#identifiers-in-the-hir) - - Guide: [The HIR Map](https://rustc-dev-guide.rust-lang.org/hir.html#the-hir-map) - - Guide: [Lowering AST to HIR](https://rustc-dev-guide.rust-lang.org/lowering.html) + - Guide: [The HIR](hir.md) + - Guide: [Identifiers in the HIR](hir.md#identifiers-in-the-hir) + - Guide: [The HIR Map](hir.md#the-hir-map) + - Guide: [Lowering AST to HIR](lowering.md) - How to view HIR representation for your code `cargo rustc -- -Z unpretty=hir-tree` - Rustc HIR definition: [`rustc_hir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html) - Main entry point: **TODO** - Late linting: **TODO** - Type Inference - - Guide: [Type Inference](https://rustc-dev-guide.rust-lang.org/type-inference.html) - - Guide: [The ty Module: Representing Types](https://rustc-dev-guide.rust-lang.org/ty.html) (semantics) + - Guide: [Type Inference](type-inference.md) + - Guide: [The ty Module: Representing Types](ty.md) (semantics) - Main entry point (type inference): [`InferCtxtBuilder::enter`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxtBuilder.html#method.enter) - Main entry point (type checking bodies): [the `typeck` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.typeck) - These two functions can't be decoupled. - The Mid Level Intermediate Representation (MIR) - - Guide: [The MIR (Mid level IR)](https://rustc-dev-guide.rust-lang.org/mir/index.html) + - Guide: [The MIR (Mid level IR)](mir/index.md) - Definition: [`rustc_middle/src/mir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/index.html) - Definition of sources that manipulates the MIR: [`rustc_mir_build`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_build/index.html), [`rustc_mir_dataflow`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_dataflow/index.html), [`rustc_mir_transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/index.html) - The Borrow Checker - - Guide: [MIR Borrow Check](https://rustc-dev-guide.rust-lang.org/borrow_check.html) + - Guide: [MIR Borrow Check](borrow_check.md) - Definition: [`rustc_borrowck`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/index.html) - Main entry point: [`mir_borrowck` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/fn.mir_borrowck.html) - MIR Optimizations - - Guide: [MIR Optimizations](https://rustc-dev-guide.rust-lang.org/mir/optimizations.html) + - Guide: [MIR Optimizations](mir/optimizations.md) - Definition: [`rustc_mir_transform`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/index.html) - Main entry point: [`optimized_mir` query](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/fn.optimized_mir.html) - Code Generation - - Guide: [Code Generation](https://rustc-dev-guide.rust-lang.org/backend/codegen.html) + - Guide: [Code Generation](backend/codegen.md) - Generating Machine Code from LLVM IR with LLVM - **TODO: reference?** - Main entry point: [`rustc_codegen_ssa::base::codegen_crate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/base/fn.codegen_crate.html) - This monomorphizes and produces LLVM IR for one codegen unit. It then diff --git a/src/parallel-rustc.md b/src/parallel-rustc.md index 1714a56ca..4aa13d781 100644 --- a/src/parallel-rustc.md +++ b/src/parallel-rustc.md @@ -29,7 +29,7 @@ independent instances of LLVM running in parallel. At the end, the linker is run to combine all the codegen units together into one binary. This process occurs in the `rustc_codegen_ssa::base` module. -## Query System +## Query System The query model has some properties that make it actually feasible to evaluate multiple queries in parallel without too much of an effort: @@ -54,7 +54,7 @@ When a query `foo` is evaluated, the cache table for `foo` is locked. ## Rustdoc -As of May 2022, there are still a number of steps +As of May 2022, there are still a number of steps to complete before rustdoc rendering can be made parallel. More details on this issue can be found [here][parallel-rustdoc]. @@ -99,8 +99,8 @@ are a bit out of date): [imlist]: https://github.com/nikomatsakis/rustc-parallelization/blob/master/interior-mutability-list.md [irlo1]: https://internals.rust-lang.org/t/help-test-parallel-rustc/11503 [tracking]: https://github.com/rust-lang/rust/issues/48685 -[monomorphization]:https://rustc-dev-guide.rust-lang.org/backend/monomorph.html -[parallel-rustdoc]:https://github.com/rust-lang/rust/issues/82741 -[Arc]:https://doc.rust-lang.org/std/sync/struct.Arc.html -[Rc]:https://doc.rust-lang.org/std/rc/struct.Rc.html -[OwningRef]:https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/owning_ref/index.html +[monomorphization]: backend/monomorph.md +[parallel-rustdoc]: https://github.com/rust-lang/rust/issues/82741 +[Arc]: https://doc.rust-lang.org/std/sync/struct.Arc.html +[Rc]: https://doc.rust-lang.org/std/rc/struct.Rc.html +[OwningRef]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/owning_ref/index.html From e764363e7f83689574c41054cb4614128e6fb5c8 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 7 Feb 2022 17:06:06 -0500 Subject: [PATCH 1706/1812] add mdbook-mermaid --- .github/workflows/ci.yml | 4 +++- book.toml | 4 ++++ mermaid-init.js | 1 + mermaid.min.js | 4 ++++ 4 files changed, 12 insertions(+), 1 deletion(-) create mode 100644 mermaid-init.js create mode 100644 mermaid.min.js diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index fed51378c..c571d408d 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -16,6 +16,7 @@ jobs: env: MDBOOK_VERSION: 0.4.12 MDBOOK_LINKCHECK_VERSION: 0.7.2 + MDBOOK_MERMAID_VERSION: 0.10.0 MDBOOK_TOC_VERSION: 0.6.1 DEPLOY_DIR: book/html BASE_SHA: ${{ github.event.pull_request.base.sha }} @@ -31,7 +32,7 @@ jobs: with: path: | ~/.cargo/bin - key: ${{ runner.os }}-${{ env.MDBOOK_VERSION }}--${{ env.MDBOOK_LINKCHECK_VERSION }}--${{ env.MDBOOK_TOC_VERSION }} + key: ${{ runner.os }}-${{ env.MDBOOK_VERSION }}--${{ env.MDBOOK_LINKCHECK_VERSION }}--${{ env.MDBOOK_TOC_VERSION }}--${{ env.MDBOOK_MERMAID_VERSION }} - name: Cache linkcheck uses: actions/cache@v2 @@ -59,6 +60,7 @@ jobs: cargo install mdbook --version ${{ env.MDBOOK_VERSION }} cargo install mdbook-linkcheck --version ${{ env.MDBOOK_LINKCHECK_VERSION }} cargo install mdbook-toc --version ${{ env.MDBOOK_TOC_VERSION }} + cargo install mdbook-mermaid --version ${{ env.MDBOOK_MERMAID_VERSION }} - name: Check build run: mdbook build diff --git a/book.toml b/book.toml index c4450cf0c..51dc8ecb0 100644 --- a/book.toml +++ b/book.toml @@ -10,9 +10,13 @@ create-missing = false command = "mdbook-toc" renderer = ["html"] +[preprocessor.mermaid] +command = "mdbook-mermaid" + [output.html] git-repository-url = "https://github.com/rust-lang/rustc-dev-guide" edit-url-template = "https://github.com/rust-lang/rustc-dev-guide/tree/master/{path}?mode=edit" +additional-js = ["mermaid.min.js", "mermaid-init.js"] [output.html.fold] enable = true diff --git a/mermaid-init.js b/mermaid-init.js new file mode 100644 index 000000000..313a6e8bc --- /dev/null +++ b/mermaid-init.js @@ -0,0 +1 @@ +mermaid.initialize({startOnLoad:true}); diff --git a/mermaid.min.js b/mermaid.min.js new file mode 100644 index 000000000..d45942f36 --- /dev/null +++ b/mermaid.min.js @@ -0,0 +1,4 @@ +/* MIT Licensed. Copyright (c) 2014 - 2021 Knut Sveidqvist */ +/*! For license information please see https://github.com/mermaid-js/mermaid/blob/8.13.10/LICENSE */ +!function(t,e){"object"==typeof exports&&"object"==typeof module?module.exports=e():"function"==typeof define&&define.amd?define([],e):"object"==typeof exports?exports.mermaid=e():t.mermaid=e()}("undefined"!=typeof self?self:this,(function(){return(()=>{var t={1362:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[1,6],n=[1,7],r=[1,8],i=[1,9],a=[1,12],o=[1,11],s=[1,15,24],c=[1,19],u=[1,31],l=[1,34],h=[1,32],f=[1,33],d=[1,35],p=[1,36],y=[1,37],g=[1,38],m=[1,41],v=[1,42],b=[1,43],_=[1,44],x=[15,24],w=[1,56],k=[1,57],T=[1,58],E=[1,59],C=[1,60],S=[1,61],A=[15,24,31,38,39,47,50,51,52,53,54,55,60,62],M=[15,24,29,31,38,39,43,47,50,51,52,53,54,55,60,62,77,78,79,80],N=[7,8,9,10,15,18,22,24],D=[47,77,78,79,80],O=[47,54,55,77,78,79,80],B=[47,50,51,52,53,77,78,79,80],L=[15,24,31],I=[1,93],R={trace:function(){},yy:{},symbols_:{error:2,start:3,mermaidDoc:4,direction:5,directive:6,direction_tb:7,direction_bt:8,direction_rl:9,direction_lr:10,graphConfig:11,openDirective:12,typeDirective:13,closeDirective:14,NEWLINE:15,":":16,argDirective:17,open_directive:18,type_directive:19,arg_directive:20,close_directive:21,CLASS_DIAGRAM:22,statements:23,EOF:24,statement:25,className:26,alphaNumToken:27,classLiteralName:28,GENERICTYPE:29,relationStatement:30,LABEL:31,classStatement:32,methodStatement:33,annotationStatement:34,clickStatement:35,cssClassStatement:36,CLASS:37,STYLE_SEPARATOR:38,STRUCT_START:39,members:40,STRUCT_STOP:41,ANNOTATION_START:42,ANNOTATION_END:43,MEMBER:44,SEPARATOR:45,relation:46,STR:47,relationType:48,lineType:49,AGGREGATION:50,EXTENSION:51,COMPOSITION:52,DEPENDENCY:53,LINE:54,DOTTED_LINE:55,CALLBACK:56,LINK:57,LINK_TARGET:58,CLICK:59,CALLBACK_NAME:60,CALLBACK_ARGS:61,HREF:62,CSSCLASS:63,commentToken:64,textToken:65,graphCodeTokens:66,textNoTagsToken:67,TAGSTART:68,TAGEND:69,"==":70,"--":71,PCT:72,DEFAULT:73,SPACE:74,MINUS:75,keywords:76,UNICODE_TEXT:77,NUM:78,ALPHA:79,BQUOTE_STR:80,$accept:0,$end:1},terminals_:{2:"error",7:"direction_tb",8:"direction_bt",9:"direction_rl",10:"direction_lr",15:"NEWLINE",16:":",18:"open_directive",19:"type_directive",20:"arg_directive",21:"close_directive",22:"CLASS_DIAGRAM",24:"EOF",29:"GENERICTYPE",31:"LABEL",37:"CLASS",38:"STYLE_SEPARATOR",39:"STRUCT_START",41:"STRUCT_STOP",42:"ANNOTATION_START",43:"ANNOTATION_END",44:"MEMBER",45:"SEPARATOR",47:"STR",50:"AGGREGATION",51:"EXTENSION",52:"COMPOSITION",53:"DEPENDENCY",54:"LINE",55:"DOTTED_LINE",56:"CALLBACK",57:"LINK",58:"LINK_TARGET",59:"CLICK",60:"CALLBACK_NAME",61:"CALLBACK_ARGS",62:"HREF",63:"CSSCLASS",66:"graphCodeTokens",68:"TAGSTART",69:"TAGEND",70:"==",71:"--",72:"PCT",73:"DEFAULT",74:"SPACE",75:"MINUS",76:"keywords",77:"UNICODE_TEXT",78:"NUM",79:"ALPHA",80:"BQUOTE_STR"},productions_:[0,[3,1],[3,1],[3,2],[5,1],[5,1],[5,1],[5,1],[4,1],[6,4],[6,6],[12,1],[13,1],[17,1],[14,1],[11,4],[23,1],[23,2],[23,3],[26,1],[26,1],[26,2],[26,2],[26,2],[25,1],[25,2],[25,1],[25,1],[25,1],[25,1],[25,1],[25,1],[25,1],[32,2],[32,4],[32,5],[32,7],[34,4],[40,1],[40,2],[33,1],[33,2],[33,1],[33,1],[30,3],[30,4],[30,4],[30,5],[46,3],[46,2],[46,2],[46,1],[48,1],[48,1],[48,1],[48,1],[49,1],[49,1],[35,3],[35,4],[35,3],[35,4],[35,4],[35,5],[35,3],[35,4],[35,4],[35,5],[35,3],[35,4],[35,4],[35,5],[36,3],[64,1],[64,1],[65,1],[65,1],[65,1],[65,1],[65,1],[65,1],[65,1],[67,1],[67,1],[67,1],[67,1],[27,1],[27,1],[27,1],[28,1]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 4:r.setDirection("TB");break;case 5:r.setDirection("BT");break;case 6:r.setDirection("RL");break;case 7:r.setDirection("LR");break;case 11:r.parseDirective("%%{","open_directive");break;case 12:r.parseDirective(a[s],"type_directive");break;case 13:a[s]=a[s].trim().replace(/'/g,'"'),r.parseDirective(a[s],"arg_directive");break;case 14:r.parseDirective("}%%","close_directive","class");break;case 19:case 20:this.$=a[s];break;case 21:this.$=a[s-1]+a[s];break;case 22:case 23:this.$=a[s-1]+"~"+a[s];break;case 24:r.addRelation(a[s]);break;case 25:a[s-1].title=r.cleanupLabel(a[s]),r.addRelation(a[s-1]);break;case 33:r.addClass(a[s]);break;case 34:r.addClass(a[s-2]),r.setCssClass(a[s-2],a[s]);break;case 35:r.addClass(a[s-3]),r.addMembers(a[s-3],a[s-1]);break;case 36:r.addClass(a[s-5]),r.setCssClass(a[s-5],a[s-3]),r.addMembers(a[s-5],a[s-1]);break;case 37:r.addAnnotation(a[s],a[s-2]);break;case 38:this.$=[a[s]];break;case 39:a[s].push(a[s-1]),this.$=a[s];break;case 40:case 42:case 43:break;case 41:r.addMember(a[s-1],r.cleanupLabel(a[s]));break;case 44:this.$={id1:a[s-2],id2:a[s],relation:a[s-1],relationTitle1:"none",relationTitle2:"none"};break;case 45:this.$={id1:a[s-3],id2:a[s],relation:a[s-1],relationTitle1:a[s-2],relationTitle2:"none"};break;case 46:this.$={id1:a[s-3],id2:a[s],relation:a[s-2],relationTitle1:"none",relationTitle2:a[s-1]};break;case 47:this.$={id1:a[s-4],id2:a[s],relation:a[s-2],relationTitle1:a[s-3],relationTitle2:a[s-1]};break;case 48:this.$={type1:a[s-2],type2:a[s],lineType:a[s-1]};break;case 49:this.$={type1:"none",type2:a[s],lineType:a[s-1]};break;case 50:this.$={type1:a[s-1],type2:"none",lineType:a[s]};break;case 51:this.$={type1:"none",type2:"none",lineType:a[s]};break;case 52:this.$=r.relationType.AGGREGATION;break;case 53:this.$=r.relationType.EXTENSION;break;case 54:this.$=r.relationType.COMPOSITION;break;case 55:this.$=r.relationType.DEPENDENCY;break;case 56:this.$=r.lineType.LINE;break;case 57:this.$=r.lineType.DOTTED_LINE;break;case 58:case 64:this.$=a[s-2],r.setClickEvent(a[s-1],a[s]);break;case 59:case 65:this.$=a[s-3],r.setClickEvent(a[s-2],a[s-1]),r.setTooltip(a[s-2],a[s]);break;case 60:case 68:this.$=a[s-2],r.setLink(a[s-1],a[s]);break;case 61:case 69:this.$=a[s-3],r.setLink(a[s-2],a[s-1],a[s]);break;case 62:case 70:this.$=a[s-3],r.setLink(a[s-2],a[s-1]),r.setTooltip(a[s-2],a[s]);break;case 63:case 71:this.$=a[s-4],r.setLink(a[s-3],a[s-2],a[s]),r.setTooltip(a[s-3],a[s-1]);break;case 66:this.$=a[s-3],r.setClickEvent(a[s-2],a[s-1],a[s]);break;case 67:this.$=a[s-4],r.setClickEvent(a[s-3],a[s-2],a[s-1]),r.setTooltip(a[s-3],a[s]);break;case 72:r.setCssClass(a[s-1],a[s])}},table:[{3:1,4:2,5:3,6:4,7:e,8:n,9:r,10:i,11:5,12:10,18:a,22:o},{1:[3]},{1:[2,1]},{1:[2,2]},{3:13,4:2,5:3,6:4,7:e,8:n,9:r,10:i,11:5,12:10,18:a,22:o},{1:[2,8]},t(s,[2,4]),t(s,[2,5]),t(s,[2,6]),t(s,[2,7]),{13:14,19:[1,15]},{15:[1,16]},{19:[2,11]},{1:[2,3]},{14:17,16:[1,18],21:c},t([16,21],[2,12]),{5:29,6:28,7:e,8:n,9:r,10:i,12:10,18:a,23:20,25:21,26:30,27:39,28:40,30:22,32:23,33:24,34:25,35:26,36:27,37:u,42:l,44:h,45:f,56:d,57:p,59:y,63:g,77:m,78:v,79:b,80:_},{15:[1,45]},{17:46,20:[1,47]},{15:[2,14]},{24:[1,48]},{15:[1,49],24:[2,16]},t(x,[2,24],{31:[1,50]}),t(x,[2,26]),t(x,[2,27]),t(x,[2,28]),t(x,[2,29]),t(x,[2,30]),t(x,[2,31]),t(x,[2,32]),t(x,[2,40],{46:51,48:54,49:55,31:[1,53],47:[1,52],50:w,51:k,52:T,53:E,54:C,55:S}),{26:62,27:39,28:40,77:m,78:v,79:b,80:_},t(x,[2,42]),t(x,[2,43]),{27:63,77:m,78:v,79:b},{26:64,27:39,28:40,77:m,78:v,79:b,80:_},{26:65,27:39,28:40,77:m,78:v,79:b,80:_},{26:66,27:39,28:40,77:m,78:v,79:b,80:_},{47:[1,67]},t(A,[2,19],{27:39,28:40,26:68,29:[1,69],77:m,78:v,79:b,80:_}),t(A,[2,20],{29:[1,70]}),t(M,[2,86]),t(M,[2,87]),t(M,[2,88]),t([15,24,29,31,38,39,47,50,51,52,53,54,55,60,62],[2,89]),t(N,[2,9]),{14:71,21:c},{21:[2,13]},{1:[2,15]},{5:29,6:28,7:e,8:n,9:r,10:i,12:10,18:a,23:72,24:[2,17],25:21,26:30,27:39,28:40,30:22,32:23,33:24,34:25,35:26,36:27,37:u,42:l,44:h,45:f,56:d,57:p,59:y,63:g,77:m,78:v,79:b,80:_},t(x,[2,25]),{26:73,27:39,28:40,47:[1,74],77:m,78:v,79:b,80:_},{46:75,48:54,49:55,50:w,51:k,52:T,53:E,54:C,55:S},t(x,[2,41]),{49:76,54:C,55:S},t(D,[2,51],{48:77,50:w,51:k,52:T,53:E}),t(O,[2,52]),t(O,[2,53]),t(O,[2,54]),t(O,[2,55]),t(B,[2,56]),t(B,[2,57]),t(x,[2,33],{38:[1,78],39:[1,79]}),{43:[1,80]},{47:[1,81]},{47:[1,82]},{60:[1,83],62:[1,84]},{27:85,77:m,78:v,79:b},t(A,[2,21]),t(A,[2,22]),t(A,[2,23]),{15:[1,86]},{24:[2,18]},t(L,[2,44]),{26:87,27:39,28:40,77:m,78:v,79:b,80:_},{26:88,27:39,28:40,47:[1,89],77:m,78:v,79:b,80:_},t(D,[2,50],{48:90,50:w,51:k,52:T,53:E}),t(D,[2,49]),{27:91,77:m,78:v,79:b},{40:92,44:I},{26:94,27:39,28:40,77:m,78:v,79:b,80:_},t(x,[2,58],{47:[1,95]}),t(x,[2,60],{47:[1,97],58:[1,96]}),t(x,[2,64],{47:[1,98],61:[1,99]}),t(x,[2,68],{47:[1,101],58:[1,100]}),t(x,[2,72]),t(N,[2,10]),t(L,[2,46]),t(L,[2,45]),{26:102,27:39,28:40,77:m,78:v,79:b,80:_},t(D,[2,48]),t(x,[2,34],{39:[1,103]}),{41:[1,104]},{40:105,41:[2,38],44:I},t(x,[2,37]),t(x,[2,59]),t(x,[2,61]),t(x,[2,62],{58:[1,106]}),t(x,[2,65]),t(x,[2,66],{47:[1,107]}),t(x,[2,69]),t(x,[2,70],{58:[1,108]}),t(L,[2,47]),{40:109,44:I},t(x,[2,35]),{41:[2,39]},t(x,[2,63]),t(x,[2,67]),t(x,[2,71]),{41:[1,110]},t(x,[2,36])],defaultActions:{2:[2,1],3:[2,2],5:[2,8],12:[2,11],13:[2,3],19:[2,14],47:[2,13],48:[2,15],72:[2,18],105:[2,39]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},F={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{},performAction:function(t,e,n,r){switch(n){case 0:return this.begin("open_directive"),18;case 1:return 7;case 2:return 8;case 3:return 9;case 4:return 10;case 5:return this.begin("type_directive"),19;case 6:return this.popState(),this.begin("arg_directive"),16;case 7:return this.popState(),this.popState(),21;case 8:return 20;case 9:case 10:case 12:case 19:break;case 11:return 15;case 13:case 14:return 22;case 15:return this.begin("struct"),39;case 16:return"EOF_IN_STRUCT";case 17:return"OPEN_IN_STRUCT";case 18:return this.popState(),41;case 20:return"MEMBER";case 21:return 37;case 22:return 63;case 23:return 56;case 24:return 57;case 25:return 59;case 26:return 42;case 27:return 43;case 28:this.begin("generic");break;case 29:case 32:case 35:case 38:case 41:case 44:this.popState();break;case 30:return"GENERICTYPE";case 31:this.begin("string");break;case 33:return"STR";case 34:this.begin("bqstring");break;case 36:return"BQUOTE_STR";case 37:this.begin("href");break;case 39:return 62;case 40:this.begin("callback_name");break;case 42:this.popState(),this.begin("callback_args");break;case 43:return 60;case 45:return 61;case 46:case 47:case 48:case 49:return 58;case 50:case 51:return 51;case 52:case 53:return 53;case 54:return 52;case 55:return 50;case 56:return 54;case 57:return 55;case 58:return 31;case 59:return 38;case 60:return 75;case 61:return"DOT";case 62:return"PLUS";case 63:return 72;case 64:case 65:return"EQUALS";case 66:return 79;case 67:return"PUNCTUATION";case 68:return 78;case 69:return 77;case 70:return 74;case 71:return 24}},rules:[/^(?:%%\{)/,/^(?:.*direction\s+TB[^\n]*)/,/^(?:.*direction\s+BT[^\n]*)/,/^(?:.*direction\s+RL[^\n]*)/,/^(?:.*direction\s+LR[^\n]*)/,/^(?:((?:(?!\}%%)[^:.])*))/,/^(?::)/,/^(?:\}%%)/,/^(?:((?:(?!\}%%).|\n)*))/,/^(?:%%(?!\{)*[^\n]*(\r?\n?)+)/,/^(?:%%[^\n]*(\r?\n)*)/,/^(?:\s*(\r?\n)+)/,/^(?:\s+)/,/^(?:classDiagram-v2\b)/,/^(?:classDiagram\b)/,/^(?:[{])/,/^(?:$)/,/^(?:[{])/,/^(?:[}])/,/^(?:[\n])/,/^(?:[^{}\n]*)/,/^(?:class\b)/,/^(?:cssClass\b)/,/^(?:callback\b)/,/^(?:link\b)/,/^(?:click\b)/,/^(?:<<)/,/^(?:>>)/,/^(?:[~])/,/^(?:[~])/,/^(?:[^~]*)/,/^(?:["])/,/^(?:["])/,/^(?:[^"]*)/,/^(?:[`])/,/^(?:[`])/,/^(?:[^`]+)/,/^(?:href[\s]+["])/,/^(?:["])/,/^(?:[^"]*)/,/^(?:call[\s]+)/,/^(?:\([\s]*\))/,/^(?:\()/,/^(?:[^(]*)/,/^(?:\))/,/^(?:[^)]*)/,/^(?:_self\b)/,/^(?:_blank\b)/,/^(?:_parent\b)/,/^(?:_top\b)/,/^(?:\s*<\|)/,/^(?:\s*\|>)/,/^(?:\s*>)/,/^(?:\s*<)/,/^(?:\s*\*)/,/^(?:\s*o\b)/,/^(?:--)/,/^(?:\.\.)/,/^(?::{1}[^:\n;]+)/,/^(?::{3})/,/^(?:-)/,/^(?:\.)/,/^(?:\+)/,/^(?:%)/,/^(?:=)/,/^(?:=)/,/^(?:\w+)/,/^(?:[!"#$%&'*+,-.`?\\/])/,/^(?:[0-9]+)/,/^(?:[\u00AA\u00B5\u00BA\u00C0-\u00D6\u00D8-\u00F6]|[\u00F8-\u02C1\u02C6-\u02D1\u02E0-\u02E4\u02EC\u02EE\u0370-\u0374\u0376\u0377]|[\u037A-\u037D\u0386\u0388-\u038A\u038C\u038E-\u03A1\u03A3-\u03F5]|[\u03F7-\u0481\u048A-\u0527\u0531-\u0556\u0559\u0561-\u0587\u05D0-\u05EA]|[\u05F0-\u05F2\u0620-\u064A\u066E\u066F\u0671-\u06D3\u06D5\u06E5\u06E6\u06EE]|[\u06EF\u06FA-\u06FC\u06FF\u0710\u0712-\u072F\u074D-\u07A5\u07B1\u07CA-\u07EA]|[\u07F4\u07F5\u07FA\u0800-\u0815\u081A\u0824\u0828\u0840-\u0858\u08A0]|[\u08A2-\u08AC\u0904-\u0939\u093D\u0950\u0958-\u0961\u0971-\u0977]|[\u0979-\u097F\u0985-\u098C\u098F\u0990\u0993-\u09A8\u09AA-\u09B0\u09B2]|[\u09B6-\u09B9\u09BD\u09CE\u09DC\u09DD\u09DF-\u09E1\u09F0\u09F1\u0A05-\u0A0A]|[\u0A0F\u0A10\u0A13-\u0A28\u0A2A-\u0A30\u0A32\u0A33\u0A35\u0A36\u0A38\u0A39]|[\u0A59-\u0A5C\u0A5E\u0A72-\u0A74\u0A85-\u0A8D\u0A8F-\u0A91\u0A93-\u0AA8]|[\u0AAA-\u0AB0\u0AB2\u0AB3\u0AB5-\u0AB9\u0ABD\u0AD0\u0AE0\u0AE1\u0B05-\u0B0C]|[\u0B0F\u0B10\u0B13-\u0B28\u0B2A-\u0B30\u0B32\u0B33\u0B35-\u0B39\u0B3D\u0B5C]|[\u0B5D\u0B5F-\u0B61\u0B71\u0B83\u0B85-\u0B8A\u0B8E-\u0B90\u0B92-\u0B95\u0B99]|[\u0B9A\u0B9C\u0B9E\u0B9F\u0BA3\u0BA4\u0BA8-\u0BAA\u0BAE-\u0BB9\u0BD0]|[\u0C05-\u0C0C\u0C0E-\u0C10\u0C12-\u0C28\u0C2A-\u0C33\u0C35-\u0C39\u0C3D]|[\u0C58\u0C59\u0C60\u0C61\u0C85-\u0C8C\u0C8E-\u0C90\u0C92-\u0CA8\u0CAA-\u0CB3]|[\u0CB5-\u0CB9\u0CBD\u0CDE\u0CE0\u0CE1\u0CF1\u0CF2\u0D05-\u0D0C\u0D0E-\u0D10]|[\u0D12-\u0D3A\u0D3D\u0D4E\u0D60\u0D61\u0D7A-\u0D7F\u0D85-\u0D96\u0D9A-\u0DB1]|[\u0DB3-\u0DBB\u0DBD\u0DC0-\u0DC6\u0E01-\u0E30\u0E32\u0E33\u0E40-\u0E46\u0E81]|[\u0E82\u0E84\u0E87\u0E88\u0E8A\u0E8D\u0E94-\u0E97\u0E99-\u0E9F\u0EA1-\u0EA3]|[\u0EA5\u0EA7\u0EAA\u0EAB\u0EAD-\u0EB0\u0EB2\u0EB3\u0EBD\u0EC0-\u0EC4\u0EC6]|[\u0EDC-\u0EDF\u0F00\u0F40-\u0F47\u0F49-\u0F6C\u0F88-\u0F8C\u1000-\u102A]|[\u103F\u1050-\u1055\u105A-\u105D\u1061\u1065\u1066\u106E-\u1070\u1075-\u1081]|[\u108E\u10A0-\u10C5\u10C7\u10CD\u10D0-\u10FA\u10FC-\u1248\u124A-\u124D]|[\u1250-\u1256\u1258\u125A-\u125D\u1260-\u1288\u128A-\u128D\u1290-\u12B0]|[\u12B2-\u12B5\u12B8-\u12BE\u12C0\u12C2-\u12C5\u12C8-\u12D6\u12D8-\u1310]|[\u1312-\u1315\u1318-\u135A\u1380-\u138F\u13A0-\u13F4\u1401-\u166C]|[\u166F-\u167F\u1681-\u169A\u16A0-\u16EA\u1700-\u170C\u170E-\u1711]|[\u1720-\u1731\u1740-\u1751\u1760-\u176C\u176E-\u1770\u1780-\u17B3\u17D7]|[\u17DC\u1820-\u1877\u1880-\u18A8\u18AA\u18B0-\u18F5\u1900-\u191C]|[\u1950-\u196D\u1970-\u1974\u1980-\u19AB\u19C1-\u19C7\u1A00-\u1A16]|[\u1A20-\u1A54\u1AA7\u1B05-\u1B33\u1B45-\u1B4B\u1B83-\u1BA0\u1BAE\u1BAF]|[\u1BBA-\u1BE5\u1C00-\u1C23\u1C4D-\u1C4F\u1C5A-\u1C7D\u1CE9-\u1CEC]|[\u1CEE-\u1CF1\u1CF5\u1CF6\u1D00-\u1DBF\u1E00-\u1F15\u1F18-\u1F1D]|[\u1F20-\u1F45\u1F48-\u1F4D\u1F50-\u1F57\u1F59\u1F5B\u1F5D\u1F5F-\u1F7D]|[\u1F80-\u1FB4\u1FB6-\u1FBC\u1FBE\u1FC2-\u1FC4\u1FC6-\u1FCC\u1FD0-\u1FD3]|[\u1FD6-\u1FDB\u1FE0-\u1FEC\u1FF2-\u1FF4\u1FF6-\u1FFC\u2071\u207F]|[\u2090-\u209C\u2102\u2107\u210A-\u2113\u2115\u2119-\u211D\u2124\u2126\u2128]|[\u212A-\u212D\u212F-\u2139\u213C-\u213F\u2145-\u2149\u214E\u2183\u2184]|[\u2C00-\u2C2E\u2C30-\u2C5E\u2C60-\u2CE4\u2CEB-\u2CEE\u2CF2\u2CF3]|[\u2D00-\u2D25\u2D27\u2D2D\u2D30-\u2D67\u2D6F\u2D80-\u2D96\u2DA0-\u2DA6]|[\u2DA8-\u2DAE\u2DB0-\u2DB6\u2DB8-\u2DBE\u2DC0-\u2DC6\u2DC8-\u2DCE]|[\u2DD0-\u2DD6\u2DD8-\u2DDE\u2E2F\u3005\u3006\u3031-\u3035\u303B\u303C]|[\u3041-\u3096\u309D-\u309F\u30A1-\u30FA\u30FC-\u30FF\u3105-\u312D]|[\u3131-\u318E\u31A0-\u31BA\u31F0-\u31FF\u3400-\u4DB5\u4E00-\u9FCC]|[\uA000-\uA48C\uA4D0-\uA4FD\uA500-\uA60C\uA610-\uA61F\uA62A\uA62B]|[\uA640-\uA66E\uA67F-\uA697\uA6A0-\uA6E5\uA717-\uA71F\uA722-\uA788]|[\uA78B-\uA78E\uA790-\uA793\uA7A0-\uA7AA\uA7F8-\uA801\uA803-\uA805]|[\uA807-\uA80A\uA80C-\uA822\uA840-\uA873\uA882-\uA8B3\uA8F2-\uA8F7\uA8FB]|[\uA90A-\uA925\uA930-\uA946\uA960-\uA97C\uA984-\uA9B2\uA9CF\uAA00-\uAA28]|[\uAA40-\uAA42\uAA44-\uAA4B\uAA60-\uAA76\uAA7A\uAA80-\uAAAF\uAAB1\uAAB5]|[\uAAB6\uAAB9-\uAABD\uAAC0\uAAC2\uAADB-\uAADD\uAAE0-\uAAEA\uAAF2-\uAAF4]|[\uAB01-\uAB06\uAB09-\uAB0E\uAB11-\uAB16\uAB20-\uAB26\uAB28-\uAB2E]|[\uABC0-\uABE2\uAC00-\uD7A3\uD7B0-\uD7C6\uD7CB-\uD7FB\uF900-\uFA6D]|[\uFA70-\uFAD9\uFB00-\uFB06\uFB13-\uFB17\uFB1D\uFB1F-\uFB28\uFB2A-\uFB36]|[\uFB38-\uFB3C\uFB3E\uFB40\uFB41\uFB43\uFB44\uFB46-\uFBB1\uFBD3-\uFD3D]|[\uFD50-\uFD8F\uFD92-\uFDC7\uFDF0-\uFDFB\uFE70-\uFE74\uFE76-\uFEFC]|[\uFF21-\uFF3A\uFF41-\uFF5A\uFF66-\uFFBE\uFFC2-\uFFC7\uFFCA-\uFFCF]|[\uFFD2-\uFFD7\uFFDA-\uFFDC])/,/^(?:\s)/,/^(?:$)/],conditions:{arg_directive:{rules:[7,8],inclusive:!1},type_directive:{rules:[6,7],inclusive:!1},open_directive:{rules:[5],inclusive:!1},callback_args:{rules:[44,45],inclusive:!1},callback_name:{rules:[41,42,43],inclusive:!1},href:{rules:[38,39],inclusive:!1},struct:{rules:[16,17,18,19,20],inclusive:!1},generic:{rules:[29,30],inclusive:!1},bqstring:{rules:[35,36],inclusive:!1},string:{rules:[32,33],inclusive:!1},INITIAL:{rules:[0,1,2,3,4,9,10,11,12,13,14,15,21,22,23,24,25,26,27,28,31,34,37,40,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71],inclusive:!0}}};function P(){this.yy={}}return R.lexer=F,P.prototype=R,R.Parser=P,new P}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(8218).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},5890:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[1,2],n=[1,5],r=[6,9,11,23,41],i=[1,17],a=[1,20],o=[1,25],s=[1,26],c=[1,27],u=[1,28],l=[1,37],h=[23,38,39],f=[4,6,9,11,23,41],d=[34,35,36,37],p=[22,29],y=[1,55],g={trace:function(){},yy:{},symbols_:{error:2,start:3,ER_DIAGRAM:4,document:5,EOF:6,directive:7,line:8,SPACE:9,statement:10,NEWLINE:11,openDirective:12,typeDirective:13,closeDirective:14,":":15,argDirective:16,entityName:17,relSpec:18,role:19,BLOCK_START:20,attributes:21,BLOCK_STOP:22,ALPHANUM:23,attribute:24,attributeType:25,attributeName:26,attributeKeyType:27,attributeComment:28,ATTRIBUTE_WORD:29,ATTRIBUTE_KEY:30,COMMENT:31,cardinality:32,relType:33,ZERO_OR_ONE:34,ZERO_OR_MORE:35,ONE_OR_MORE:36,ONLY_ONE:37,NON_IDENTIFYING:38,IDENTIFYING:39,WORD:40,open_directive:41,type_directive:42,arg_directive:43,close_directive:44,$accept:0,$end:1},terminals_:{2:"error",4:"ER_DIAGRAM",6:"EOF",9:"SPACE",11:"NEWLINE",15:":",20:"BLOCK_START",22:"BLOCK_STOP",23:"ALPHANUM",29:"ATTRIBUTE_WORD",30:"ATTRIBUTE_KEY",31:"COMMENT",34:"ZERO_OR_ONE",35:"ZERO_OR_MORE",36:"ONE_OR_MORE",37:"ONLY_ONE",38:"NON_IDENTIFYING",39:"IDENTIFYING",40:"WORD",41:"open_directive",42:"type_directive",43:"arg_directive",44:"close_directive"},productions_:[0,[3,3],[3,2],[5,0],[5,2],[8,2],[8,1],[8,1],[8,1],[7,4],[7,6],[10,1],[10,5],[10,4],[10,3],[10,1],[17,1],[21,1],[21,2],[24,2],[24,3],[24,3],[24,4],[25,1],[26,1],[27,1],[28,1],[18,3],[32,1],[32,1],[32,1],[32,1],[33,1],[33,1],[19,1],[19,1],[12,1],[13,1],[16,1],[14,1]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 1:break;case 3:case 7:case 8:this.$=[];break;case 4:a[s-1].push(a[s]),this.$=a[s-1];break;case 5:case 6:case 16:case 23:case 24:case 25:case 35:this.$=a[s];break;case 12:r.addEntity(a[s-4]),r.addEntity(a[s-2]),r.addRelationship(a[s-4],a[s],a[s-2],a[s-3]);break;case 13:r.addEntity(a[s-3]),r.addAttributes(a[s-3],a[s-1]);break;case 14:r.addEntity(a[s-2]);break;case 15:r.addEntity(a[s]);break;case 17:this.$=[a[s]];break;case 18:a[s].push(a[s-1]),this.$=a[s];break;case 19:this.$={attributeType:a[s-1],attributeName:a[s]};break;case 20:this.$={attributeType:a[s-2],attributeName:a[s-1],attributeKeyType:a[s]};break;case 21:this.$={attributeType:a[s-2],attributeName:a[s-1],attributeComment:a[s]};break;case 22:this.$={attributeType:a[s-3],attributeName:a[s-2],attributeKeyType:a[s-1],attributeComment:a[s]};break;case 26:case 34:this.$=a[s].replace(/"/g,"");break;case 27:this.$={cardA:a[s],relType:a[s-1],cardB:a[s-2]};break;case 28:this.$=r.Cardinality.ZERO_OR_ONE;break;case 29:this.$=r.Cardinality.ZERO_OR_MORE;break;case 30:this.$=r.Cardinality.ONE_OR_MORE;break;case 31:this.$=r.Cardinality.ONLY_ONE;break;case 32:this.$=r.Identification.NON_IDENTIFYING;break;case 33:this.$=r.Identification.IDENTIFYING;break;case 36:r.parseDirective("%%{","open_directive");break;case 37:r.parseDirective(a[s],"type_directive");break;case 38:a[s]=a[s].trim().replace(/'/g,'"'),r.parseDirective(a[s],"arg_directive");break;case 39:r.parseDirective("}%%","close_directive","er")}},table:[{3:1,4:e,7:3,12:4,41:n},{1:[3]},t(r,[2,3],{5:6}),{3:7,4:e,7:3,12:4,41:n},{13:8,42:[1,9]},{42:[2,36]},{6:[1,10],7:15,8:11,9:[1,12],10:13,11:[1,14],12:4,17:16,23:i,41:n},{1:[2,2]},{14:18,15:[1,19],44:a},t([15,44],[2,37]),t(r,[2,8],{1:[2,1]}),t(r,[2,4]),{7:15,10:21,12:4,17:16,23:i,41:n},t(r,[2,6]),t(r,[2,7]),t(r,[2,11]),t(r,[2,15],{18:22,32:24,20:[1,23],34:o,35:s,36:c,37:u}),t([6,9,11,15,20,23,34,35,36,37,41],[2,16]),{11:[1,29]},{16:30,43:[1,31]},{11:[2,39]},t(r,[2,5]),{17:32,23:i},{21:33,22:[1,34],24:35,25:36,29:l},{33:38,38:[1,39],39:[1,40]},t(h,[2,28]),t(h,[2,29]),t(h,[2,30]),t(h,[2,31]),t(f,[2,9]),{14:41,44:a},{44:[2,38]},{15:[1,42]},{22:[1,43]},t(r,[2,14]),{21:44,22:[2,17],24:35,25:36,29:l},{26:45,29:[1,46]},{29:[2,23]},{32:47,34:o,35:s,36:c,37:u},t(d,[2,32]),t(d,[2,33]),{11:[1,48]},{19:49,23:[1,51],40:[1,50]},t(r,[2,13]),{22:[2,18]},t(p,[2,19],{27:52,28:53,30:[1,54],31:y}),t([22,29,30,31],[2,24]),{23:[2,27]},t(f,[2,10]),t(r,[2,12]),t(r,[2,34]),t(r,[2,35]),t(p,[2,20],{28:56,31:y}),t(p,[2,21]),t([22,29,31],[2,25]),t(p,[2,26]),t(p,[2,22])],defaultActions:{5:[2,36],7:[2,2],20:[2,39],31:[2,38],37:[2,23],44:[2,18],47:[2,27]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},m={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{"case-insensitive":!0},performAction:function(t,e,n,r){switch(n){case 0:return this.begin("open_directive"),41;case 1:return this.begin("type_directive"),42;case 2:return this.popState(),this.begin("arg_directive"),15;case 3:return this.popState(),this.popState(),44;case 4:return 43;case 5:case 6:case 8:case 13:case 17:break;case 7:return 11;case 9:return 9;case 10:return 40;case 11:return 4;case 12:return this.begin("block"),20;case 14:return 30;case 15:return 29;case 16:return 31;case 18:return this.popState(),22;case 19:case 32:return e.yytext[0];case 20:case 24:return 34;case 21:case 25:return 35;case 22:case 26:return 36;case 23:return 37;case 27:case 29:case 30:return 38;case 28:return 39;case 31:return 23;case 33:return 6}},rules:[/^(?:%%\{)/i,/^(?:((?:(?!\}%%)[^:.])*))/i,/^(?::)/i,/^(?:\}%%)/i,/^(?:((?:(?!\}%%).|\n)*))/i,/^(?:%(?!\{)[^\n]*)/i,/^(?:[^\}]%%[^\n]*)/i,/^(?:[\n]+)/i,/^(?:\s+)/i,/^(?:[\s]+)/i,/^(?:"[^"]*")/i,/^(?:erDiagram\b)/i,/^(?:\{)/i,/^(?:\s+)/i,/^(?:(?:PK)|(?:FK))/i,/^(?:[A-Za-z][A-Za-z0-9\-_]*)/i,/^(?:"[^"]*")/i,/^(?:[\n]+)/i,/^(?:\})/i,/^(?:.)/i,/^(?:\|o\b)/i,/^(?:\}o\b)/i,/^(?:\}\|)/i,/^(?:\|\|)/i,/^(?:o\|)/i,/^(?:o\{)/i,/^(?:\|\{)/i,/^(?:\.\.)/i,/^(?:--)/i,/^(?:\.-)/i,/^(?:-\.)/i,/^(?:[A-Za-z][A-Za-z0-9\-_]*)/i,/^(?:.)/i,/^(?:$)/i],conditions:{open_directive:{rules:[1],inclusive:!1},type_directive:{rules:[2,3],inclusive:!1},arg_directive:{rules:[3,4],inclusive:!1},block:{rules:[13,14,15,16,17,18,19],inclusive:!1},INITIAL:{rules:[0,5,6,7,8,9,10,11,12,20,21,22,23,24,25,26,27,28,29,30,31,32,33],inclusive:!0}}};function v(){this.yy={}}return g.lexer=m,v.prototype=g,g.Parser=v,new v}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(8009).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},3602:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[1,9],n=[1,7],r=[1,6],i=[1,8],a=[1,20,21,22,23,38,47,59,60,79,80,81,82,83,84,88,98,99,102,104,105,111,112,113,114,115,116,117,118,119,120],o=[2,10],s=[1,20],c=[1,21],u=[1,22],l=[1,23],h=[1,30],f=[1,59],d=[1,45],p=[1,49],y=[1,33],g=[1,34],m=[1,35],v=[1,36],b=[1,37],_=[1,53],x=[1,60],w=[1,48],k=[1,50],T=[1,52],E=[1,56],C=[1,57],S=[1,38],A=[1,39],M=[1,40],N=[1,41],D=[1,58],O=[1,47],B=[1,51],L=[1,54],I=[1,55],R=[1,46],F=[1,63],P=[1,68],j=[1,20,21,22,23,38,42,47,59,60,79,80,81,82,83,84,88,98,99,102,104,105,111,112,113,114,115,116,117,118,119,120],Y=[1,72],z=[1,71],U=[1,73],q=[20,21,23,74,75],H=[1,94],$=[1,99],W=[1,102],V=[1,103],G=[1,96],X=[1,101],Z=[1,104],Q=[1,97],K=[1,109],J=[1,108],tt=[1,98],et=[1,100],nt=[1,105],rt=[1,106],it=[1,107],at=[1,110],ot=[20,21,22,23,74,75],st=[20,21,22,23,48,74,75],ct=[20,21,22,23,40,47,48,50,52,54,56,58,59,60,62,64,66,67,69,74,75,84,88,98,99,102,104,105,115,116,117,118,119,120],ut=[20,21,23],lt=[20,21,23,47,59,60,74,75,84,88,98,99,102,104,105,115,116,117,118,119,120],ht=[1,12,20,21,22,23,24,38,42,47,59,60,79,80,81,82,83,84,88,98,99,102,104,105,111,112,113,114,115,116,117,118,119,120],ft=[47,59,60,84,88,98,99,102,104,105,115,116,117,118,119,120],dt=[1,143],pt=[1,151],yt=[1,152],gt=[1,153],mt=[1,154],vt=[1,138],bt=[1,139],_t=[1,135],xt=[1,146],wt=[1,147],kt=[1,148],Tt=[1,149],Et=[1,150],Ct=[1,155],St=[1,156],At=[1,141],Mt=[1,144],Nt=[1,140],Dt=[1,137],Ot=[20,21,22,23,38,42,47,59,60,79,80,81,82,83,84,88,98,99,102,104,105,111,112,113,114,115,116,117,118,119,120],Bt=[1,159],Lt=[20,21,22,23,26,47,59,60,84,98,99,102,104,105,115,116,117,118,119,120],It=[20,21,22,23,24,26,38,40,41,42,47,51,53,55,57,59,60,61,63,65,66,68,70,74,75,79,80,81,82,83,84,85,88,98,99,102,104,105,106,107,115,116,117,118,119,120],Rt=[12,21,22,24],Ft=[22,99],Pt=[1,242],jt=[1,237],Yt=[1,238],zt=[1,246],Ut=[1,243],qt=[1,240],Ht=[1,239],$t=[1,241],Wt=[1,244],Vt=[1,245],Gt=[1,247],Xt=[1,265],Zt=[20,21,23,99],Qt=[20,21,22,23,59,60,79,95,98,99,102,103,104,105,106],Kt={trace:function(){},yy:{},symbols_:{error:2,start:3,mermaidDoc:4,directive:5,openDirective:6,typeDirective:7,closeDirective:8,separator:9,":":10,argDirective:11,open_directive:12,type_directive:13,arg_directive:14,close_directive:15,graphConfig:16,document:17,line:18,statement:19,SEMI:20,NEWLINE:21,SPACE:22,EOF:23,GRAPH:24,NODIR:25,DIR:26,FirstStmtSeperator:27,ending:28,endToken:29,spaceList:30,spaceListNewline:31,verticeStatement:32,styleStatement:33,linkStyleStatement:34,classDefStatement:35,classStatement:36,clickStatement:37,subgraph:38,text:39,SQS:40,SQE:41,end:42,direction:43,link:44,node:45,vertex:46,AMP:47,STYLE_SEPARATOR:48,idString:49,PS:50,PE:51,"(-":52,"-)":53,STADIUMSTART:54,STADIUMEND:55,SUBROUTINESTART:56,SUBROUTINEEND:57,VERTEX_WITH_PROPS_START:58,ALPHA:59,COLON:60,PIPE:61,CYLINDERSTART:62,CYLINDEREND:63,DIAMOND_START:64,DIAMOND_STOP:65,TAGEND:66,TRAPSTART:67,TRAPEND:68,INVTRAPSTART:69,INVTRAPEND:70,linkStatement:71,arrowText:72,TESTSTR:73,START_LINK:74,LINK:75,textToken:76,STR:77,keywords:78,STYLE:79,LINKSTYLE:80,CLASSDEF:81,CLASS:82,CLICK:83,DOWN:84,UP:85,textNoTags:86,textNoTagsToken:87,DEFAULT:88,stylesOpt:89,alphaNum:90,CALLBACKNAME:91,CALLBACKARGS:92,HREF:93,LINK_TARGET:94,HEX:95,numList:96,INTERPOLATE:97,NUM:98,COMMA:99,style:100,styleComponent:101,MINUS:102,UNIT:103,BRKT:104,DOT:105,PCT:106,TAGSTART:107,alphaNumToken:108,idStringToken:109,alphaNumStatement:110,direction_tb:111,direction_bt:112,direction_rl:113,direction_lr:114,PUNCTUATION:115,UNICODE_TEXT:116,PLUS:117,EQUALS:118,MULT:119,UNDERSCORE:120,graphCodeTokens:121,ARROW_CROSS:122,ARROW_POINT:123,ARROW_CIRCLE:124,ARROW_OPEN:125,QUOTE:126,$accept:0,$end:1},terminals_:{2:"error",10:":",12:"open_directive",13:"type_directive",14:"arg_directive",15:"close_directive",20:"SEMI",21:"NEWLINE",22:"SPACE",23:"EOF",24:"GRAPH",25:"NODIR",26:"DIR",38:"subgraph",40:"SQS",41:"SQE",42:"end",47:"AMP",48:"STYLE_SEPARATOR",50:"PS",51:"PE",52:"(-",53:"-)",54:"STADIUMSTART",55:"STADIUMEND",56:"SUBROUTINESTART",57:"SUBROUTINEEND",58:"VERTEX_WITH_PROPS_START",59:"ALPHA",60:"COLON",61:"PIPE",62:"CYLINDERSTART",63:"CYLINDEREND",64:"DIAMOND_START",65:"DIAMOND_STOP",66:"TAGEND",67:"TRAPSTART",68:"TRAPEND",69:"INVTRAPSTART",70:"INVTRAPEND",73:"TESTSTR",74:"START_LINK",75:"LINK",77:"STR",79:"STYLE",80:"LINKSTYLE",81:"CLASSDEF",82:"CLASS",83:"CLICK",84:"DOWN",85:"UP",88:"DEFAULT",91:"CALLBACKNAME",92:"CALLBACKARGS",93:"HREF",94:"LINK_TARGET",95:"HEX",97:"INTERPOLATE",98:"NUM",99:"COMMA",102:"MINUS",103:"UNIT",104:"BRKT",105:"DOT",106:"PCT",107:"TAGSTART",111:"direction_tb",112:"direction_bt",113:"direction_rl",114:"direction_lr",115:"PUNCTUATION",116:"UNICODE_TEXT",117:"PLUS",118:"EQUALS",119:"MULT",120:"UNDERSCORE",122:"ARROW_CROSS",123:"ARROW_POINT",124:"ARROW_CIRCLE",125:"ARROW_OPEN",126:"QUOTE"},productions_:[0,[3,1],[3,2],[5,4],[5,6],[6,1],[7,1],[11,1],[8,1],[4,2],[17,0],[17,2],[18,1],[18,1],[18,1],[18,1],[18,1],[16,2],[16,2],[16,2],[16,3],[28,2],[28,1],[29,1],[29,1],[29,1],[27,1],[27,1],[27,2],[31,2],[31,2],[31,1],[31,1],[30,2],[30,1],[19,2],[19,2],[19,2],[19,2],[19,2],[19,2],[19,9],[19,6],[19,4],[19,1],[9,1],[9,1],[9,1],[32,3],[32,4],[32,2],[32,1],[45,1],[45,5],[45,3],[46,4],[46,6],[46,4],[46,4],[46,4],[46,8],[46,4],[46,4],[46,4],[46,6],[46,4],[46,4],[46,4],[46,4],[46,4],[46,1],[44,2],[44,3],[44,3],[44,1],[44,3],[71,1],[72,3],[39,1],[39,2],[39,1],[78,1],[78,1],[78,1],[78,1],[78,1],[78,1],[78,1],[78,1],[78,1],[78,1],[78,1],[86,1],[86,2],[35,5],[35,5],[36,5],[37,2],[37,4],[37,3],[37,5],[37,2],[37,4],[37,4],[37,6],[37,2],[37,4],[37,2],[37,4],[37,4],[37,6],[33,5],[33,5],[34,5],[34,5],[34,9],[34,9],[34,7],[34,7],[96,1],[96,3],[89,1],[89,3],[100,1],[100,2],[101,1],[101,1],[101,1],[101,1],[101,1],[101,1],[101,1],[101,1],[101,1],[101,1],[101,1],[76,1],[76,1],[76,1],[76,1],[76,1],[76,1],[87,1],[87,1],[87,1],[87,1],[49,1],[49,2],[90,1],[90,2],[110,1],[110,1],[110,1],[110,1],[43,1],[43,1],[43,1],[43,1],[108,1],[108,1],[108,1],[108,1],[108,1],[108,1],[108,1],[108,1],[108,1],[108,1],[108,1],[108,1],[108,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[109,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1],[121,1]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 5:r.parseDirective("%%{","open_directive");break;case 6:r.parseDirective(a[s],"type_directive");break;case 7:a[s]=a[s].trim().replace(/'/g,'"'),r.parseDirective(a[s],"arg_directive");break;case 8:r.parseDirective("}%%","close_directive","flowchart");break;case 10:case 36:case 37:case 38:case 39:case 40:this.$=[];break;case 11:a[s]!==[]&&a[s-1].push(a[s]),this.$=a[s-1];break;case 12:case 78:case 80:case 92:case 148:case 150:case 151:case 74:case 146:this.$=a[s];break;case 19:r.setDirection("TB"),this.$="TB";break;case 20:r.setDirection(a[s-1]),this.$=a[s-1];break;case 35:this.$=a[s-1].nodes;break;case 41:this.$=r.addSubGraph(a[s-6],a[s-1],a[s-4]);break;case 42:this.$=r.addSubGraph(a[s-3],a[s-1],a[s-3]);break;case 43:this.$=r.addSubGraph(void 0,a[s-1],void 0);break;case 48:r.addLink(a[s-2].stmt,a[s],a[s-1]),this.$={stmt:a[s],nodes:a[s].concat(a[s-2].nodes)};break;case 49:r.addLink(a[s-3].stmt,a[s-1],a[s-2]),this.$={stmt:a[s-1],nodes:a[s-1].concat(a[s-3].nodes)};break;case 50:this.$={stmt:a[s-1],nodes:a[s-1]};break;case 51:this.$={stmt:a[s],nodes:a[s]};break;case 52:case 119:case 121:this.$=[a[s]];break;case 53:this.$=a[s-4].concat(a[s]);break;case 54:this.$=[a[s-2]],r.setClass(a[s-2],a[s]);break;case 55:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"square");break;case 56:this.$=a[s-5],r.addVertex(a[s-5],a[s-2],"circle");break;case 57:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"ellipse");break;case 58:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"stadium");break;case 59:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"subroutine");break;case 60:this.$=a[s-7],r.addVertex(a[s-7],a[s-1],"rect",void 0,void 0,void 0,Object.fromEntries([[a[s-5],a[s-3]]]));break;case 61:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"cylinder");break;case 62:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"round");break;case 63:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"diamond");break;case 64:this.$=a[s-5],r.addVertex(a[s-5],a[s-2],"hexagon");break;case 65:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"odd");break;case 66:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"trapezoid");break;case 67:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"inv_trapezoid");break;case 68:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"lean_right");break;case 69:this.$=a[s-3],r.addVertex(a[s-3],a[s-1],"lean_left");break;case 70:this.$=a[s],r.addVertex(a[s]);break;case 71:a[s-1].text=a[s],this.$=a[s-1];break;case 72:case 73:a[s-2].text=a[s-1],this.$=a[s-2];break;case 75:var c=r.destructLink(a[s],a[s-2]);this.$={type:c.type,stroke:c.stroke,length:c.length,text:a[s-1]};break;case 76:c=r.destructLink(a[s]),this.$={type:c.type,stroke:c.stroke,length:c.length};break;case 77:this.$=a[s-1];break;case 79:case 93:case 149:case 147:this.$=a[s-1]+""+a[s];break;case 94:case 95:this.$=a[s-4],r.addClass(a[s-2],a[s]);break;case 96:this.$=a[s-4],r.setClass(a[s-2],a[s]);break;case 97:case 105:this.$=a[s-1],r.setClickEvent(a[s-1],a[s]);break;case 98:case 106:this.$=a[s-3],r.setClickEvent(a[s-3],a[s-2]),r.setTooltip(a[s-3],a[s]);break;case 99:this.$=a[s-2],r.setClickEvent(a[s-2],a[s-1],a[s]);break;case 100:this.$=a[s-4],r.setClickEvent(a[s-4],a[s-3],a[s-2]),r.setTooltip(a[s-4],a[s]);break;case 101:case 107:this.$=a[s-1],r.setLink(a[s-1],a[s]);break;case 102:case 108:this.$=a[s-3],r.setLink(a[s-3],a[s-2]),r.setTooltip(a[s-3],a[s]);break;case 103:case 109:this.$=a[s-3],r.setLink(a[s-3],a[s-2],a[s]);break;case 104:case 110:this.$=a[s-5],r.setLink(a[s-5],a[s-4],a[s]),r.setTooltip(a[s-5],a[s-2]);break;case 111:this.$=a[s-4],r.addVertex(a[s-2],void 0,void 0,a[s]);break;case 112:case 114:this.$=a[s-4],r.updateLink(a[s-2],a[s]);break;case 113:this.$=a[s-4],r.updateLink([a[s-2]],a[s]);break;case 115:this.$=a[s-8],r.updateLinkInterpolate([a[s-6]],a[s-2]),r.updateLink([a[s-6]],a[s]);break;case 116:this.$=a[s-8],r.updateLinkInterpolate(a[s-6],a[s-2]),r.updateLink(a[s-6],a[s]);break;case 117:this.$=a[s-6],r.updateLinkInterpolate([a[s-4]],a[s]);break;case 118:this.$=a[s-6],r.updateLinkInterpolate(a[s-4],a[s]);break;case 120:case 122:a[s-2].push(a[s]),this.$=a[s-2];break;case 124:this.$=a[s-1]+a[s];break;case 152:this.$="v";break;case 153:this.$="-";break;case 154:this.$={stmt:"dir",value:"TB"};break;case 155:this.$={stmt:"dir",value:"BT"};break;case 156:this.$={stmt:"dir",value:"RL"};break;case 157:this.$={stmt:"dir",value:"LR"}}},table:[{3:1,4:2,5:3,6:5,12:e,16:4,21:n,22:r,24:i},{1:[3]},{1:[2,1]},{3:10,4:2,5:3,6:5,12:e,16:4,21:n,22:r,24:i},t(a,o,{17:11}),{7:12,13:[1,13]},{16:14,21:n,22:r,24:i},{16:15,21:n,22:r,24:i},{25:[1,16],26:[1,17]},{13:[2,5]},{1:[2,2]},{1:[2,9],18:18,19:19,20:s,21:c,22:u,23:l,32:24,33:25,34:26,35:27,36:28,37:29,38:h,43:31,45:32,46:42,47:f,49:43,59:d,60:p,79:y,80:g,81:m,82:v,83:b,84:_,88:x,98:w,99:k,102:T,104:E,105:C,109:44,111:S,112:A,113:M,114:N,115:D,116:O,117:B,118:L,119:I,120:R},{8:61,10:[1,62],15:F},t([10,15],[2,6]),t(a,[2,17]),t(a,[2,18]),t(a,[2,19]),{20:[1,65],21:[1,66],22:P,27:64,30:67},t(j,[2,11]),t(j,[2,12]),t(j,[2,13]),t(j,[2,14]),t(j,[2,15]),t(j,[2,16]),{9:69,20:Y,21:z,23:U,44:70,71:74,74:[1,75],75:[1,76]},{9:77,20:Y,21:z,23:U},{9:78,20:Y,21:z,23:U},{9:79,20:Y,21:z,23:U},{9:80,20:Y,21:z,23:U},{9:81,20:Y,21:z,23:U},{9:83,20:Y,21:z,22:[1,82],23:U},t(j,[2,44]),t(q,[2,51],{30:84,22:P}),{22:[1,85]},{22:[1,86]},{22:[1,87]},{22:[1,88]},{26:H,47:$,59:W,60:V,77:[1,92],84:G,90:91,91:[1,89],93:[1,90],98:X,99:Z,102:Q,104:K,105:J,108:95,110:93,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(j,[2,154]),t(j,[2,155]),t(j,[2,156]),t(j,[2,157]),t(ot,[2,52],{48:[1,111]}),t(st,[2,70],{109:123,40:[1,112],47:f,50:[1,113],52:[1,114],54:[1,115],56:[1,116],58:[1,117],59:d,60:p,62:[1,118],64:[1,119],66:[1,120],67:[1,121],69:[1,122],84:_,88:x,98:w,99:k,102:T,104:E,105:C,115:D,116:O,117:B,118:L,119:I,120:R}),t(ct,[2,146]),t(ct,[2,171]),t(ct,[2,172]),t(ct,[2,173]),t(ct,[2,174]),t(ct,[2,175]),t(ct,[2,176]),t(ct,[2,177]),t(ct,[2,178]),t(ct,[2,179]),t(ct,[2,180]),t(ct,[2,181]),t(ct,[2,182]),t(ct,[2,183]),t(ct,[2,184]),t(ct,[2,185]),t(ct,[2,186]),{9:124,20:Y,21:z,23:U},{11:125,14:[1,126]},t(ut,[2,8]),t(a,[2,20]),t(a,[2,26]),t(a,[2,27]),{21:[1,127]},t(lt,[2,34],{30:128,22:P}),t(j,[2,35]),{45:129,46:42,47:f,49:43,59:d,60:p,84:_,88:x,98:w,99:k,102:T,104:E,105:C,109:44,115:D,116:O,117:B,118:L,119:I,120:R},t(ht,[2,45]),t(ht,[2,46]),t(ht,[2,47]),t(ft,[2,74],{72:130,61:[1,132],73:[1,131]}),{22:dt,24:pt,26:yt,38:gt,39:133,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},t([47,59,60,61,73,84,88,98,99,102,104,105,115,116,117,118,119,120],[2,76]),t(j,[2,36]),t(j,[2,37]),t(j,[2,38]),t(j,[2,39]),t(j,[2,40]),{22:dt,24:pt,26:yt,38:gt,39:157,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(Ot,o,{17:158}),t(q,[2,50],{47:Bt}),{26:H,47:$,59:W,60:V,84:G,90:160,95:[1,161],98:X,99:Z,102:Q,104:K,105:J,108:95,110:93,115:tt,116:et,117:nt,118:rt,119:it,120:at},{88:[1,162],96:163,98:[1,164]},{26:H,47:$,59:W,60:V,84:G,88:[1,165],90:166,98:X,99:Z,102:Q,104:K,105:J,108:95,110:93,115:tt,116:et,117:nt,118:rt,119:it,120:at},{26:H,47:$,59:W,60:V,84:G,90:167,98:X,99:Z,102:Q,104:K,105:J,108:95,110:93,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(ut,[2,97],{22:[1,168],92:[1,169]}),t(ut,[2,101],{22:[1,170]}),t(ut,[2,105],{108:95,110:172,22:[1,171],26:H,47:$,59:W,60:V,84:G,98:X,99:Z,102:Q,104:K,105:J,115:tt,116:et,117:nt,118:rt,119:it,120:at}),t(ut,[2,107],{22:[1,173]}),t(Lt,[2,148]),t(Lt,[2,150]),t(Lt,[2,151]),t(Lt,[2,152]),t(Lt,[2,153]),t(It,[2,158]),t(It,[2,159]),t(It,[2,160]),t(It,[2,161]),t(It,[2,162]),t(It,[2,163]),t(It,[2,164]),t(It,[2,165]),t(It,[2,166]),t(It,[2,167]),t(It,[2,168]),t(It,[2,169]),t(It,[2,170]),{47:f,49:174,59:d,60:p,84:_,88:x,98:w,99:k,102:T,104:E,105:C,109:44,115:D,116:O,117:B,118:L,119:I,120:R},{22:dt,24:pt,26:yt,38:gt,39:175,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:177,42:mt,47:$,50:[1,176],59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:178,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:179,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:180,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{59:[1,181]},{22:dt,24:pt,26:yt,38:gt,39:182,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:183,42:mt,47:$,59:W,60:V,64:[1,184],66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:185,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:186,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:187,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(ct,[2,147]),t(Rt,[2,3]),{8:188,15:F},{15:[2,7]},t(a,[2,28]),t(lt,[2,33]),t(q,[2,48],{30:189,22:P}),t(ft,[2,71],{22:[1,190]}),{22:[1,191]},{22:dt,24:pt,26:yt,38:gt,39:192,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,59:W,60:V,66:vt,74:bt,75:[1,193],76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(It,[2,78]),t(It,[2,80]),t(It,[2,136]),t(It,[2,137]),t(It,[2,138]),t(It,[2,139]),t(It,[2,140]),t(It,[2,141]),t(It,[2,142]),t(It,[2,143]),t(It,[2,144]),t(It,[2,145]),t(It,[2,81]),t(It,[2,82]),t(It,[2,83]),t(It,[2,84]),t(It,[2,85]),t(It,[2,86]),t(It,[2,87]),t(It,[2,88]),t(It,[2,89]),t(It,[2,90]),t(It,[2,91]),{9:196,20:Y,21:z,22:dt,23:U,24:pt,26:yt,38:gt,40:[1,195],42:mt,47:$,59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{18:18,19:19,20:s,21:c,22:u,23:l,32:24,33:25,34:26,35:27,36:28,37:29,38:h,42:[1,197],43:31,45:32,46:42,47:f,49:43,59:d,60:p,79:y,80:g,81:m,82:v,83:b,84:_,88:x,98:w,99:k,102:T,104:E,105:C,109:44,111:S,112:A,113:M,114:N,115:D,116:O,117:B,118:L,119:I,120:R},{22:P,30:198},{22:[1,199],26:H,47:$,59:W,60:V,84:G,98:X,99:Z,102:Q,104:K,105:J,108:95,110:172,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:[1,200]},{22:[1,201]},{22:[1,202],99:[1,203]},t(Ft,[2,119]),{22:[1,204]},{22:[1,205],26:H,47:$,59:W,60:V,84:G,98:X,99:Z,102:Q,104:K,105:J,108:95,110:172,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:[1,206],26:H,47:$,59:W,60:V,84:G,98:X,99:Z,102:Q,104:K,105:J,108:95,110:172,115:tt,116:et,117:nt,118:rt,119:it,120:at},{77:[1,207]},t(ut,[2,99],{22:[1,208]}),{77:[1,209],94:[1,210]},{77:[1,211]},t(Lt,[2,149]),{77:[1,212],94:[1,213]},t(ot,[2,54],{109:123,47:f,59:d,60:p,84:_,88:x,98:w,99:k,102:T,104:E,105:C,115:D,116:O,117:B,118:L,119:I,120:R}),{22:dt,24:pt,26:yt,38:gt,41:[1,214],42:mt,47:$,59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:215,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,51:[1,216],59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,53:[1,217],59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,55:[1,218],59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,57:[1,219],59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{60:[1,220]},{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,59:W,60:V,63:[1,221],66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,59:W,60:V,65:[1,222],66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,39:223,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,41:[1,224],42:mt,47:$,59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,59:W,60:V,66:vt,68:[1,225],70:[1,226],74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,59:W,60:V,66:vt,68:[1,228],70:[1,227],74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{9:229,20:Y,21:z,23:U},t(q,[2,49],{47:Bt}),t(ft,[2,73]),t(ft,[2,72]),{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,59:W,60:V,61:[1,230],66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(ft,[2,75]),t(It,[2,79]),{22:dt,24:pt,26:yt,38:gt,39:231,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(Ot,o,{17:232}),t(j,[2,43]),{46:233,47:f,49:43,59:d,60:p,84:_,88:x,98:w,99:k,102:T,104:E,105:C,109:44,115:D,116:O,117:B,118:L,119:I,120:R},{22:Pt,59:jt,60:Yt,79:zt,89:234,95:Ut,98:qt,100:235,101:236,102:Ht,103:$t,104:Wt,105:Vt,106:Gt},{22:Pt,59:jt,60:Yt,79:zt,89:248,95:Ut,98:qt,100:235,101:236,102:Ht,103:$t,104:Wt,105:Vt,106:Gt},{22:Pt,59:jt,60:Yt,79:zt,89:249,95:Ut,97:[1,250],98:qt,100:235,101:236,102:Ht,103:$t,104:Wt,105:Vt,106:Gt},{22:Pt,59:jt,60:Yt,79:zt,89:251,95:Ut,97:[1,252],98:qt,100:235,101:236,102:Ht,103:$t,104:Wt,105:Vt,106:Gt},{98:[1,253]},{22:Pt,59:jt,60:Yt,79:zt,89:254,95:Ut,98:qt,100:235,101:236,102:Ht,103:$t,104:Wt,105:Vt,106:Gt},{22:Pt,59:jt,60:Yt,79:zt,89:255,95:Ut,98:qt,100:235,101:236,102:Ht,103:$t,104:Wt,105:Vt,106:Gt},{26:H,47:$,59:W,60:V,84:G,90:256,98:X,99:Z,102:Q,104:K,105:J,108:95,110:93,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(ut,[2,98]),{77:[1,257]},t(ut,[2,102],{22:[1,258]}),t(ut,[2,103]),t(ut,[2,106]),t(ut,[2,108],{22:[1,259]}),t(ut,[2,109]),t(st,[2,55]),{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,51:[1,260],59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(st,[2,62]),t(st,[2,57]),t(st,[2,58]),t(st,[2,59]),{59:[1,261]},t(st,[2,61]),t(st,[2,63]),{22:dt,24:pt,26:yt,38:gt,42:mt,47:$,59:W,60:V,65:[1,262],66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(st,[2,65]),t(st,[2,66]),t(st,[2,68]),t(st,[2,67]),t(st,[2,69]),t(Rt,[2,4]),t([22,47,59,60,84,88,98,99,102,104,105,115,116,117,118,119,120],[2,77]),{22:dt,24:pt,26:yt,38:gt,41:[1,263],42:mt,47:$,59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{18:18,19:19,20:s,21:c,22:u,23:l,32:24,33:25,34:26,35:27,36:28,37:29,38:h,42:[1,264],43:31,45:32,46:42,47:f,49:43,59:d,60:p,79:y,80:g,81:m,82:v,83:b,84:_,88:x,98:w,99:k,102:T,104:E,105:C,109:44,111:S,112:A,113:M,114:N,115:D,116:O,117:B,118:L,119:I,120:R},t(ot,[2,53]),t(ut,[2,111],{99:Xt}),t(Zt,[2,121],{101:266,22:Pt,59:jt,60:Yt,79:zt,95:Ut,98:qt,102:Ht,103:$t,104:Wt,105:Vt,106:Gt}),t(Qt,[2,123]),t(Qt,[2,125]),t(Qt,[2,126]),t(Qt,[2,127]),t(Qt,[2,128]),t(Qt,[2,129]),t(Qt,[2,130]),t(Qt,[2,131]),t(Qt,[2,132]),t(Qt,[2,133]),t(Qt,[2,134]),t(Qt,[2,135]),t(ut,[2,112],{99:Xt}),t(ut,[2,113],{99:Xt}),{22:[1,267]},t(ut,[2,114],{99:Xt}),{22:[1,268]},t(Ft,[2,120]),t(ut,[2,94],{99:Xt}),t(ut,[2,95],{99:Xt}),t(ut,[2,96],{108:95,110:172,26:H,47:$,59:W,60:V,84:G,98:X,99:Z,102:Q,104:K,105:J,115:tt,116:et,117:nt,118:rt,119:it,120:at}),t(ut,[2,100]),{94:[1,269]},{94:[1,270]},{51:[1,271]},{61:[1,272]},{65:[1,273]},{9:274,20:Y,21:z,23:U},t(j,[2,42]),{22:Pt,59:jt,60:Yt,79:zt,95:Ut,98:qt,100:275,101:236,102:Ht,103:$t,104:Wt,105:Vt,106:Gt},t(Qt,[2,124]),{26:H,47:$,59:W,60:V,84:G,90:276,98:X,99:Z,102:Q,104:K,105:J,108:95,110:93,115:tt,116:et,117:nt,118:rt,119:it,120:at},{26:H,47:$,59:W,60:V,84:G,90:277,98:X,99:Z,102:Q,104:K,105:J,108:95,110:93,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(ut,[2,104]),t(ut,[2,110]),t(st,[2,56]),{22:dt,24:pt,26:yt,38:gt,39:278,42:mt,47:$,59:W,60:V,66:vt,74:bt,76:134,77:_t,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},t(st,[2,64]),t(Ot,o,{17:279}),t(Zt,[2,122],{101:266,22:Pt,59:jt,60:Yt,79:zt,95:Ut,98:qt,102:Ht,103:$t,104:Wt,105:Vt,106:Gt}),t(ut,[2,117],{108:95,110:172,22:[1,280],26:H,47:$,59:W,60:V,84:G,98:X,99:Z,102:Q,104:K,105:J,115:tt,116:et,117:nt,118:rt,119:it,120:at}),t(ut,[2,118],{108:95,110:172,22:[1,281],26:H,47:$,59:W,60:V,84:G,98:X,99:Z,102:Q,104:K,105:J,115:tt,116:et,117:nt,118:rt,119:it,120:at}),{22:dt,24:pt,26:yt,38:gt,41:[1,282],42:mt,47:$,59:W,60:V,66:vt,74:bt,76:194,78:145,79:xt,80:wt,81:kt,82:Tt,83:Et,84:Ct,85:St,87:136,88:At,98:X,99:Z,102:Mt,104:K,105:J,106:Nt,107:Dt,108:142,115:tt,116:et,117:nt,118:rt,119:it,120:at},{18:18,19:19,20:s,21:c,22:u,23:l,32:24,33:25,34:26,35:27,36:28,37:29,38:h,42:[1,283],43:31,45:32,46:42,47:f,49:43,59:d,60:p,79:y,80:g,81:m,82:v,83:b,84:_,88:x,98:w,99:k,102:T,104:E,105:C,109:44,111:S,112:A,113:M,114:N,115:D,116:O,117:B,118:L,119:I,120:R},{22:Pt,59:jt,60:Yt,79:zt,89:284,95:Ut,98:qt,100:235,101:236,102:Ht,103:$t,104:Wt,105:Vt,106:Gt},{22:Pt,59:jt,60:Yt,79:zt,89:285,95:Ut,98:qt,100:235,101:236,102:Ht,103:$t,104:Wt,105:Vt,106:Gt},t(st,[2,60]),t(j,[2,41]),t(ut,[2,115],{99:Xt}),t(ut,[2,116],{99:Xt})],defaultActions:{2:[2,1],9:[2,5],10:[2,2],126:[2,7]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},Jt={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{},performAction:function(t,e,n,r){switch(n){case 0:return this.begin("open_directive"),12;case 1:return this.begin("type_directive"),13;case 2:return this.popState(),this.begin("arg_directive"),10;case 3:return this.popState(),this.popState(),15;case 4:return 14;case 5:case 6:break;case 7:this.begin("string");break;case 8:case 17:case 20:case 23:case 26:this.popState();break;case 9:return"STR";case 10:return 79;case 11:return 88;case 12:return 80;case 13:return 97;case 14:return 81;case 15:return 82;case 16:this.begin("href");break;case 18:return 93;case 19:this.begin("callbackname");break;case 21:this.popState(),this.begin("callbackargs");break;case 22:return 91;case 24:return 92;case 25:this.begin("click");break;case 27:return 83;case 28:case 29:return t.lex.firstGraph()&&this.begin("dir"),24;case 30:return 38;case 31:return 42;case 32:case 33:case 34:case 35:return 94;case 36:return this.popState(),25;case 37:case 38:case 39:case 40:case 41:case 42:case 43:case 44:case 45:case 46:return this.popState(),26;case 47:return 111;case 48:return 112;case 49:return 113;case 50:return 114;case 51:return 98;case 52:return 104;case 53:return 48;case 54:return 60;case 55:return 47;case 56:return 20;case 57:return 99;case 58:return 119;case 59:case 60:case 61:return 75;case 62:case 63:case 64:return 74;case 65:return 52;case 66:return 53;case 67:return 54;case 68:return 55;case 69:return 56;case 70:return 57;case 71:return 58;case 72:return 62;case 73:return 63;case 74:return 102;case 75:return 105;case 76:return 120;case 77:return 117;case 78:return 106;case 79:case 80:return 118;case 81:return 107;case 82:return 66;case 83:return 85;case 84:return"SEP";case 85:return 84;case 86:return 59;case 87:return 68;case 88:return 67;case 89:return 70;case 90:return 69;case 91:return 115;case 92:return 116;case 93:return 61;case 94:return 50;case 95:return 51;case 96:return 40;case 97:return 41;case 98:return 64;case 99:return 65;case 100:return 126;case 101:return 21;case 102:return 22;case 103:return 23}},rules:[/^(?:%%\{)/,/^(?:((?:(?!\}%%)[^:.])*))/,/^(?::)/,/^(?:\}%%)/,/^(?:((?:(?!\}%%).|\n)*))/,/^(?:%%(?!\{)[^\n]*)/,/^(?:[^\}]%%[^\n]*)/,/^(?:["])/,/^(?:["])/,/^(?:[^"]*)/,/^(?:style\b)/,/^(?:default\b)/,/^(?:linkStyle\b)/,/^(?:interpolate\b)/,/^(?:classDef\b)/,/^(?:class\b)/,/^(?:href[\s]+["])/,/^(?:["])/,/^(?:[^"]*)/,/^(?:call[\s]+)/,/^(?:\([\s]*\))/,/^(?:\()/,/^(?:[^(]*)/,/^(?:\))/,/^(?:[^)]*)/,/^(?:click[\s]+)/,/^(?:[\s\n])/,/^(?:[^\s\n]*)/,/^(?:graph\b)/,/^(?:flowchart\b)/,/^(?:subgraph\b)/,/^(?:end\b\s*)/,/^(?:_self\b)/,/^(?:_blank\b)/,/^(?:_parent\b)/,/^(?:_top\b)/,/^(?:(\r?\n)*\s*\n)/,/^(?:\s*LR\b)/,/^(?:\s*RL\b)/,/^(?:\s*TB\b)/,/^(?:\s*BT\b)/,/^(?:\s*TD\b)/,/^(?:\s*BR\b)/,/^(?:\s*<)/,/^(?:\s*>)/,/^(?:\s*\^)/,/^(?:\s*v\b)/,/^(?:.*direction\s+TB[^\n]*)/,/^(?:.*direction\s+BT[^\n]*)/,/^(?:.*direction\s+RL[^\n]*)/,/^(?:.*direction\s+LR[^\n]*)/,/^(?:[0-9]+)/,/^(?:#)/,/^(?::::)/,/^(?::)/,/^(?:&)/,/^(?:;)/,/^(?:,)/,/^(?:\*)/,/^(?:\s*[xo<]?--+[-xo>]\s*)/,/^(?:\s*[xo<]?==+[=xo>]\s*)/,/^(?:\s*[xo<]?-?\.+-[xo>]?\s*)/,/^(?:\s*[xo<]?--\s*)/,/^(?:\s*[xo<]?==\s*)/,/^(?:\s*[xo<]?-\.\s*)/,/^(?:\(-)/,/^(?:-\))/,/^(?:\(\[)/,/^(?:\]\))/,/^(?:\[\[)/,/^(?:\]\])/,/^(?:\[\|)/,/^(?:\[\()/,/^(?:\)\])/,/^(?:-)/,/^(?:\.)/,/^(?:[\_])/,/^(?:\+)/,/^(?:%)/,/^(?:=)/,/^(?:=)/,/^(?:<)/,/^(?:>)/,/^(?:\^)/,/^(?:\\\|)/,/^(?:v\b)/,/^(?:[A-Za-z]+)/,/^(?:\\\])/,/^(?:\[\/)/,/^(?:\/\])/,/^(?:\[\\)/,/^(?:[!"#$%&'*+,-.`?\\_/])/,/^(?:[\u00AA\u00B5\u00BA\u00C0-\u00D6\u00D8-\u00F6]|[\u00F8-\u02C1\u02C6-\u02D1\u02E0-\u02E4\u02EC\u02EE\u0370-\u0374\u0376\u0377]|[\u037A-\u037D\u0386\u0388-\u038A\u038C\u038E-\u03A1\u03A3-\u03F5]|[\u03F7-\u0481\u048A-\u0527\u0531-\u0556\u0559\u0561-\u0587\u05D0-\u05EA]|[\u05F0-\u05F2\u0620-\u064A\u066E\u066F\u0671-\u06D3\u06D5\u06E5\u06E6\u06EE]|[\u06EF\u06FA-\u06FC\u06FF\u0710\u0712-\u072F\u074D-\u07A5\u07B1\u07CA-\u07EA]|[\u07F4\u07F5\u07FA\u0800-\u0815\u081A\u0824\u0828\u0840-\u0858\u08A0]|[\u08A2-\u08AC\u0904-\u0939\u093D\u0950\u0958-\u0961\u0971-\u0977]|[\u0979-\u097F\u0985-\u098C\u098F\u0990\u0993-\u09A8\u09AA-\u09B0\u09B2]|[\u09B6-\u09B9\u09BD\u09CE\u09DC\u09DD\u09DF-\u09E1\u09F0\u09F1\u0A05-\u0A0A]|[\u0A0F\u0A10\u0A13-\u0A28\u0A2A-\u0A30\u0A32\u0A33\u0A35\u0A36\u0A38\u0A39]|[\u0A59-\u0A5C\u0A5E\u0A72-\u0A74\u0A85-\u0A8D\u0A8F-\u0A91\u0A93-\u0AA8]|[\u0AAA-\u0AB0\u0AB2\u0AB3\u0AB5-\u0AB9\u0ABD\u0AD0\u0AE0\u0AE1\u0B05-\u0B0C]|[\u0B0F\u0B10\u0B13-\u0B28\u0B2A-\u0B30\u0B32\u0B33\u0B35-\u0B39\u0B3D\u0B5C]|[\u0B5D\u0B5F-\u0B61\u0B71\u0B83\u0B85-\u0B8A\u0B8E-\u0B90\u0B92-\u0B95\u0B99]|[\u0B9A\u0B9C\u0B9E\u0B9F\u0BA3\u0BA4\u0BA8-\u0BAA\u0BAE-\u0BB9\u0BD0]|[\u0C05-\u0C0C\u0C0E-\u0C10\u0C12-\u0C28\u0C2A-\u0C33\u0C35-\u0C39\u0C3D]|[\u0C58\u0C59\u0C60\u0C61\u0C85-\u0C8C\u0C8E-\u0C90\u0C92-\u0CA8\u0CAA-\u0CB3]|[\u0CB5-\u0CB9\u0CBD\u0CDE\u0CE0\u0CE1\u0CF1\u0CF2\u0D05-\u0D0C\u0D0E-\u0D10]|[\u0D12-\u0D3A\u0D3D\u0D4E\u0D60\u0D61\u0D7A-\u0D7F\u0D85-\u0D96\u0D9A-\u0DB1]|[\u0DB3-\u0DBB\u0DBD\u0DC0-\u0DC6\u0E01-\u0E30\u0E32\u0E33\u0E40-\u0E46\u0E81]|[\u0E82\u0E84\u0E87\u0E88\u0E8A\u0E8D\u0E94-\u0E97\u0E99-\u0E9F\u0EA1-\u0EA3]|[\u0EA5\u0EA7\u0EAA\u0EAB\u0EAD-\u0EB0\u0EB2\u0EB3\u0EBD\u0EC0-\u0EC4\u0EC6]|[\u0EDC-\u0EDF\u0F00\u0F40-\u0F47\u0F49-\u0F6C\u0F88-\u0F8C\u1000-\u102A]|[\u103F\u1050-\u1055\u105A-\u105D\u1061\u1065\u1066\u106E-\u1070\u1075-\u1081]|[\u108E\u10A0-\u10C5\u10C7\u10CD\u10D0-\u10FA\u10FC-\u1248\u124A-\u124D]|[\u1250-\u1256\u1258\u125A-\u125D\u1260-\u1288\u128A-\u128D\u1290-\u12B0]|[\u12B2-\u12B5\u12B8-\u12BE\u12C0\u12C2-\u12C5\u12C8-\u12D6\u12D8-\u1310]|[\u1312-\u1315\u1318-\u135A\u1380-\u138F\u13A0-\u13F4\u1401-\u166C]|[\u166F-\u167F\u1681-\u169A\u16A0-\u16EA\u1700-\u170C\u170E-\u1711]|[\u1720-\u1731\u1740-\u1751\u1760-\u176C\u176E-\u1770\u1780-\u17B3\u17D7]|[\u17DC\u1820-\u1877\u1880-\u18A8\u18AA\u18B0-\u18F5\u1900-\u191C]|[\u1950-\u196D\u1970-\u1974\u1980-\u19AB\u19C1-\u19C7\u1A00-\u1A16]|[\u1A20-\u1A54\u1AA7\u1B05-\u1B33\u1B45-\u1B4B\u1B83-\u1BA0\u1BAE\u1BAF]|[\u1BBA-\u1BE5\u1C00-\u1C23\u1C4D-\u1C4F\u1C5A-\u1C7D\u1CE9-\u1CEC]|[\u1CEE-\u1CF1\u1CF5\u1CF6\u1D00-\u1DBF\u1E00-\u1F15\u1F18-\u1F1D]|[\u1F20-\u1F45\u1F48-\u1F4D\u1F50-\u1F57\u1F59\u1F5B\u1F5D\u1F5F-\u1F7D]|[\u1F80-\u1FB4\u1FB6-\u1FBC\u1FBE\u1FC2-\u1FC4\u1FC6-\u1FCC\u1FD0-\u1FD3]|[\u1FD6-\u1FDB\u1FE0-\u1FEC\u1FF2-\u1FF4\u1FF6-\u1FFC\u2071\u207F]|[\u2090-\u209C\u2102\u2107\u210A-\u2113\u2115\u2119-\u211D\u2124\u2126\u2128]|[\u212A-\u212D\u212F-\u2139\u213C-\u213F\u2145-\u2149\u214E\u2183\u2184]|[\u2C00-\u2C2E\u2C30-\u2C5E\u2C60-\u2CE4\u2CEB-\u2CEE\u2CF2\u2CF3]|[\u2D00-\u2D25\u2D27\u2D2D\u2D30-\u2D67\u2D6F\u2D80-\u2D96\u2DA0-\u2DA6]|[\u2DA8-\u2DAE\u2DB0-\u2DB6\u2DB8-\u2DBE\u2DC0-\u2DC6\u2DC8-\u2DCE]|[\u2DD0-\u2DD6\u2DD8-\u2DDE\u2E2F\u3005\u3006\u3031-\u3035\u303B\u303C]|[\u3041-\u3096\u309D-\u309F\u30A1-\u30FA\u30FC-\u30FF\u3105-\u312D]|[\u3131-\u318E\u31A0-\u31BA\u31F0-\u31FF\u3400-\u4DB5\u4E00-\u9FCC]|[\uA000-\uA48C\uA4D0-\uA4FD\uA500-\uA60C\uA610-\uA61F\uA62A\uA62B]|[\uA640-\uA66E\uA67F-\uA697\uA6A0-\uA6E5\uA717-\uA71F\uA722-\uA788]|[\uA78B-\uA78E\uA790-\uA793\uA7A0-\uA7AA\uA7F8-\uA801\uA803-\uA805]|[\uA807-\uA80A\uA80C-\uA822\uA840-\uA873\uA882-\uA8B3\uA8F2-\uA8F7\uA8FB]|[\uA90A-\uA925\uA930-\uA946\uA960-\uA97C\uA984-\uA9B2\uA9CF\uAA00-\uAA28]|[\uAA40-\uAA42\uAA44-\uAA4B\uAA60-\uAA76\uAA7A\uAA80-\uAAAF\uAAB1\uAAB5]|[\uAAB6\uAAB9-\uAABD\uAAC0\uAAC2\uAADB-\uAADD\uAAE0-\uAAEA\uAAF2-\uAAF4]|[\uAB01-\uAB06\uAB09-\uAB0E\uAB11-\uAB16\uAB20-\uAB26\uAB28-\uAB2E]|[\uABC0-\uABE2\uAC00-\uD7A3\uD7B0-\uD7C6\uD7CB-\uD7FB\uF900-\uFA6D]|[\uFA70-\uFAD9\uFB00-\uFB06\uFB13-\uFB17\uFB1D\uFB1F-\uFB28\uFB2A-\uFB36]|[\uFB38-\uFB3C\uFB3E\uFB40\uFB41\uFB43\uFB44\uFB46-\uFBB1\uFBD3-\uFD3D]|[\uFD50-\uFD8F\uFD92-\uFDC7\uFDF0-\uFDFB\uFE70-\uFE74\uFE76-\uFEFC]|[\uFF21-\uFF3A\uFF41-\uFF5A\uFF66-\uFFBE\uFFC2-\uFFC7\uFFCA-\uFFCF]|[\uFFD2-\uFFD7\uFFDA-\uFFDC])/,/^(?:\|)/,/^(?:\()/,/^(?:\))/,/^(?:\[)/,/^(?:\])/,/^(?:\{)/,/^(?:\})/,/^(?:")/,/^(?:(\r?\n)+)/,/^(?:\s)/,/^(?:$)/],conditions:{close_directive:{rules:[],inclusive:!1},arg_directive:{rules:[3,4],inclusive:!1},type_directive:{rules:[2,3],inclusive:!1},open_directive:{rules:[1],inclusive:!1},callbackargs:{rules:[23,24],inclusive:!1},callbackname:{rules:[20,21,22],inclusive:!1},href:{rules:[17,18],inclusive:!1},click:{rules:[26,27],inclusive:!1},vertex:{rules:[],inclusive:!1},dir:{rules:[36,37,38,39,40,41,42,43,44,45,46],inclusive:!1},string:{rules:[8,9],inclusive:!1},INITIAL:{rules:[0,5,6,7,10,11,12,13,14,15,16,19,25,28,29,30,31,32,33,34,35,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103],inclusive:!0}}};function te(){this.yy={}}return Kt.lexer=Jt,te.prototype=Kt,Kt.Parser=te,new te}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(5354).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},9959:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[1,3],n=[1,5],r=[7,9,11,12,13,14,15,16,17,18,19,20,22,29,34],i=[1,15],a=[1,16],o=[1,17],s=[1,18],c=[1,19],u=[1,20],l=[1,21],h=[1,22],f=[1,23],d=[1,25],p=[1,27],y=[1,30],g=[5,7,9,11,12,13,14,15,16,17,18,19,20,22,29,34],m={trace:function(){},yy:{},symbols_:{error:2,start:3,directive:4,gantt:5,document:6,EOF:7,line:8,SPACE:9,statement:10,NL:11,dateFormat:12,inclusiveEndDates:13,topAxis:14,axisFormat:15,excludes:16,includes:17,todayMarker:18,title:19,section:20,clickStatement:21,taskTxt:22,taskData:23,openDirective:24,typeDirective:25,closeDirective:26,":":27,argDirective:28,click:29,callbackname:30,callbackargs:31,href:32,clickStatementDebug:33,open_directive:34,type_directive:35,arg_directive:36,close_directive:37,$accept:0,$end:1},terminals_:{2:"error",5:"gantt",7:"EOF",9:"SPACE",11:"NL",12:"dateFormat",13:"inclusiveEndDates",14:"topAxis",15:"axisFormat",16:"excludes",17:"includes",18:"todayMarker",19:"title",20:"section",22:"taskTxt",23:"taskData",27:":",29:"click",30:"callbackname",31:"callbackargs",32:"href",34:"open_directive",35:"type_directive",36:"arg_directive",37:"close_directive"},productions_:[0,[3,2],[3,3],[6,0],[6,2],[8,2],[8,1],[8,1],[8,1],[10,1],[10,1],[10,1],[10,1],[10,1],[10,1],[10,1],[10,1],[10,1],[10,1],[10,2],[10,1],[4,4],[4,6],[21,2],[21,3],[21,3],[21,4],[21,3],[21,4],[21,2],[33,2],[33,3],[33,3],[33,4],[33,3],[33,4],[33,2],[24,1],[25,1],[28,1],[26,1]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 2:return a[s-1];case 3:case 7:case 8:this.$=[];break;case 4:a[s-1].push(a[s]),this.$=a[s-1];break;case 5:case 6:this.$=a[s];break;case 9:r.setDateFormat(a[s].substr(11)),this.$=a[s].substr(11);break;case 10:r.enableInclusiveEndDates(),this.$=a[s].substr(18);break;case 11:r.TopAxis(),this.$=a[s].substr(8);break;case 12:r.setAxisFormat(a[s].substr(11)),this.$=a[s].substr(11);break;case 13:r.setExcludes(a[s].substr(9)),this.$=a[s].substr(9);break;case 14:r.setIncludes(a[s].substr(9)),this.$=a[s].substr(9);break;case 15:r.setTodayMarker(a[s].substr(12)),this.$=a[s].substr(12);break;case 16:r.setTitle(a[s].substr(6)),this.$=a[s].substr(6);break;case 17:r.addSection(a[s].substr(8)),this.$=a[s].substr(8);break;case 19:r.addTask(a[s-1],a[s]),this.$="task";break;case 23:this.$=a[s-1],r.setClickEvent(a[s-1],a[s],null);break;case 24:this.$=a[s-2],r.setClickEvent(a[s-2],a[s-1],a[s]);break;case 25:this.$=a[s-2],r.setClickEvent(a[s-2],a[s-1],null),r.setLink(a[s-2],a[s]);break;case 26:this.$=a[s-3],r.setClickEvent(a[s-3],a[s-2],a[s-1]),r.setLink(a[s-3],a[s]);break;case 27:this.$=a[s-2],r.setClickEvent(a[s-2],a[s],null),r.setLink(a[s-2],a[s-1]);break;case 28:this.$=a[s-3],r.setClickEvent(a[s-3],a[s-1],a[s]),r.setLink(a[s-3],a[s-2]);break;case 29:this.$=a[s-1],r.setLink(a[s-1],a[s]);break;case 30:case 36:this.$=a[s-1]+" "+a[s];break;case 31:case 32:case 34:this.$=a[s-2]+" "+a[s-1]+" "+a[s];break;case 33:case 35:this.$=a[s-3]+" "+a[s-2]+" "+a[s-1]+" "+a[s];break;case 37:r.parseDirective("%%{","open_directive");break;case 38:r.parseDirective(a[s],"type_directive");break;case 39:a[s]=a[s].trim().replace(/'/g,'"'),r.parseDirective(a[s],"arg_directive");break;case 40:r.parseDirective("}%%","close_directive","gantt")}},table:[{3:1,4:2,5:e,24:4,34:n},{1:[3]},{3:6,4:2,5:e,24:4,34:n},t(r,[2,3],{6:7}),{25:8,35:[1,9]},{35:[2,37]},{1:[2,1]},{4:26,7:[1,10],8:11,9:[1,12],10:13,11:[1,14],12:i,13:a,14:o,15:s,16:c,17:u,18:l,19:h,20:f,21:24,22:d,24:4,29:p,34:n},{26:28,27:[1,29],37:y},t([27,37],[2,38]),t(r,[2,8],{1:[2,2]}),t(r,[2,4]),{4:26,10:31,12:i,13:a,14:o,15:s,16:c,17:u,18:l,19:h,20:f,21:24,22:d,24:4,29:p,34:n},t(r,[2,6]),t(r,[2,7]),t(r,[2,9]),t(r,[2,10]),t(r,[2,11]),t(r,[2,12]),t(r,[2,13]),t(r,[2,14]),t(r,[2,15]),t(r,[2,16]),t(r,[2,17]),t(r,[2,18]),{23:[1,32]},t(r,[2,20]),{30:[1,33],32:[1,34]},{11:[1,35]},{28:36,36:[1,37]},{11:[2,40]},t(r,[2,5]),t(r,[2,19]),t(r,[2,23],{31:[1,38],32:[1,39]}),t(r,[2,29],{30:[1,40]}),t(g,[2,21]),{26:41,37:y},{37:[2,39]},t(r,[2,24],{32:[1,42]}),t(r,[2,25]),t(r,[2,27],{31:[1,43]}),{11:[1,44]},t(r,[2,26]),t(r,[2,28]),t(g,[2,22])],defaultActions:{5:[2,37],6:[2,1],30:[2,40],37:[2,39]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},v={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{"case-insensitive":!0},performAction:function(t,e,n,r){switch(n){case 0:return this.begin("open_directive"),34;case 1:return this.begin("type_directive"),35;case 2:return this.popState(),this.begin("arg_directive"),27;case 3:return this.popState(),this.popState(),37;case 4:return 36;case 5:case 6:case 7:case 9:case 10:case 11:break;case 8:return 11;case 12:this.begin("href");break;case 13:case 16:case 19:case 22:this.popState();break;case 14:return 32;case 15:this.begin("callbackname");break;case 17:this.popState(),this.begin("callbackargs");break;case 18:return 30;case 20:return 31;case 21:this.begin("click");break;case 23:return 29;case 24:return 5;case 25:return 12;case 26:return 13;case 27:return 14;case 28:return 15;case 29:return 17;case 30:return 16;case 31:return 18;case 32:return"date";case 33:return 19;case 34:return 20;case 35:return 22;case 36:return 23;case 37:return 27;case 38:return 7;case 39:return"INVALID"}},rules:[/^(?:%%\{)/i,/^(?:((?:(?!\}%%)[^:.])*))/i,/^(?::)/i,/^(?:\}%%)/i,/^(?:((?:(?!\}%%).|\n)*))/i,/^(?:%%(?!\{)*[^\n]*)/i,/^(?:[^\}]%%*[^\n]*)/i,/^(?:%%*[^\n]*[\n]*)/i,/^(?:[\n]+)/i,/^(?:\s+)/i,/^(?:#[^\n]*)/i,/^(?:%[^\n]*)/i,/^(?:href[\s]+["])/i,/^(?:["])/i,/^(?:[^"]*)/i,/^(?:call[\s]+)/i,/^(?:\([\s]*\))/i,/^(?:\()/i,/^(?:[^(]*)/i,/^(?:\))/i,/^(?:[^)]*)/i,/^(?:click[\s]+)/i,/^(?:[\s\n])/i,/^(?:[^\s\n]*)/i,/^(?:gantt\b)/i,/^(?:dateFormat\s[^#\n;]+)/i,/^(?:inclusiveEndDates\b)/i,/^(?:topAxis\b)/i,/^(?:axisFormat\s[^#\n;]+)/i,/^(?:includes\s[^#\n;]+)/i,/^(?:excludes\s[^#\n;]+)/i,/^(?:todayMarker\s[^\n;]+)/i,/^(?:\d\d\d\d-\d\d-\d\d\b)/i,/^(?:title\s[^#\n;]+)/i,/^(?:section\s[^#:\n;]+)/i,/^(?:[^#:\n;]+)/i,/^(?::[^#\n;]+)/i,/^(?::)/i,/^(?:$)/i,/^(?:.)/i],conditions:{close_directive:{rules:[],inclusive:!1},arg_directive:{rules:[3,4],inclusive:!1},type_directive:{rules:[2,3],inclusive:!1},open_directive:{rules:[1],inclusive:!1},callbackargs:{rules:[19,20],inclusive:!1},callbackname:{rules:[16,17,18],inclusive:!1},href:{rules:[13,14],inclusive:!1},click:{rules:[22,23],inclusive:!1},INITIAL:{rules:[0,5,6,7,8,9,10,11,12,15,21,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],inclusive:!0}}};function b(){this.yy={}}return m.lexer=v,b.prototype=m,m.Parser=b,new b}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(6878).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},2553:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[2,3],n=[1,7],r=[7,12,15,17,19,20,21],i=[7,11,12,15,17,19,20,21],a=[2,20],o=[1,32],s={trace:function(){},yy:{},symbols_:{error:2,start:3,GG:4,":":5,document:6,EOF:7,DIR:8,options:9,body:10,OPT:11,NL:12,line:13,statement:14,COMMIT:15,commit_arg:16,BRANCH:17,ID:18,CHECKOUT:19,MERGE:20,RESET:21,reset_arg:22,STR:23,HEAD:24,reset_parents:25,CARET:26,$accept:0,$end:1},terminals_:{2:"error",4:"GG",5:":",7:"EOF",8:"DIR",11:"OPT",12:"NL",15:"COMMIT",17:"BRANCH",18:"ID",19:"CHECKOUT",20:"MERGE",21:"RESET",23:"STR",24:"HEAD",26:"CARET"},productions_:[0,[3,4],[3,5],[6,0],[6,2],[9,2],[9,1],[10,0],[10,2],[13,2],[13,1],[14,2],[14,2],[14,2],[14,2],[14,2],[16,0],[16,1],[22,2],[22,2],[25,0],[25,2]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 1:return a[s-1];case 2:return r.setDirection(a[s-3]),a[s-1];case 4:r.setOptions(a[s-1]),this.$=a[s];break;case 5:a[s-1]+=a[s],this.$=a[s-1];break;case 7:this.$=[];break;case 8:a[s-1].push(a[s]),this.$=a[s-1];break;case 9:this.$=a[s-1];break;case 11:r.commit(a[s]);break;case 12:r.branch(a[s]);break;case 13:r.checkout(a[s]);break;case 14:r.merge(a[s]);break;case 15:r.reset(a[s]);break;case 16:this.$="";break;case 17:this.$=a[s];break;case 18:this.$=a[s-1]+":"+a[s];break;case 19:this.$=a[s-1]+":"+r.count,r.count=0;break;case 20:r.count=0;break;case 21:r.count+=1}},table:[{3:1,4:[1,2]},{1:[3]},{5:[1,3],8:[1,4]},{6:5,7:e,9:6,12:n},{5:[1,8]},{7:[1,9]},t(r,[2,7],{10:10,11:[1,11]}),t(i,[2,6]),{6:12,7:e,9:6,12:n},{1:[2,1]},{7:[2,4],12:[1,15],13:13,14:14,15:[1,16],17:[1,17],19:[1,18],20:[1,19],21:[1,20]},t(i,[2,5]),{7:[1,21]},t(r,[2,8]),{12:[1,22]},t(r,[2,10]),{12:[2,16],16:23,23:[1,24]},{18:[1,25]},{18:[1,26]},{18:[1,27]},{18:[1,30],22:28,24:[1,29]},{1:[2,2]},t(r,[2,9]),{12:[2,11]},{12:[2,17]},{12:[2,12]},{12:[2,13]},{12:[2,14]},{12:[2,15]},{12:a,25:31,26:o},{12:a,25:33,26:o},{12:[2,18]},{12:a,25:34,26:o},{12:[2,19]},{12:[2,21]}],defaultActions:{9:[2,1],21:[2,2],23:[2,11],24:[2,17],25:[2,12],26:[2,13],27:[2,14],28:[2,15],31:[2,18],33:[2,19],34:[2,21]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},c={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{"case-insensitive":!0},performAction:function(t,e,n,r){switch(n){case 0:return 12;case 1:case 2:case 3:break;case 4:return 4;case 5:return 15;case 6:return 17;case 7:return 20;case 8:return 21;case 9:return 19;case 10:case 11:return 8;case 12:return 5;case 13:return 26;case 14:this.begin("options");break;case 15:case 18:this.popState();break;case 16:return 11;case 17:this.begin("string");break;case 19:return 23;case 20:return 18;case 21:return 7}},rules:[/^(?:(\r?\n)+)/i,/^(?:\s+)/i,/^(?:#[^\n]*)/i,/^(?:%[^\n]*)/i,/^(?:gitGraph\b)/i,/^(?:commit\b)/i,/^(?:branch\b)/i,/^(?:merge\b)/i,/^(?:reset\b)/i,/^(?:checkout\b)/i,/^(?:LR\b)/i,/^(?:BT\b)/i,/^(?::)/i,/^(?:\^)/i,/^(?:options\r?\n)/i,/^(?:end\r?\n)/i,/^(?:[^\n]+\r?\n)/i,/^(?:["])/i,/^(?:["])/i,/^(?:[^"]*)/i,/^(?:[a-zA-Z][-_\.a-zA-Z0-9]*[-_a-zA-Z0-9])/i,/^(?:$)/i],conditions:{options:{rules:[15,16],inclusive:!1},string:{rules:[18,19],inclusive:!1},INITIAL:{rules:[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,17,20,21],inclusive:!0}}};function u(){this.yy={}}return s.lexer=c,u.prototype=s,s.Parser=u,new u}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(8183).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},6765:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[6,9,10],n={trace:function(){},yy:{},symbols_:{error:2,start:3,info:4,document:5,EOF:6,line:7,statement:8,NL:9,showInfo:10,$accept:0,$end:1},terminals_:{2:"error",4:"info",6:"EOF",9:"NL",10:"showInfo"},productions_:[0,[3,3],[5,0],[5,2],[7,1],[7,1],[8,1]],performAction:function(t,e,n,r,i,a,o){switch(a.length,i){case 1:return r;case 4:break;case 6:r.setInfo(!0)}},table:[{3:1,4:[1,2]},{1:[3]},t(e,[2,2],{5:3}),{6:[1,4],7:5,8:6,9:[1,7],10:[1,8]},{1:[2,1]},t(e,[2,3]),t(e,[2,4]),t(e,[2,5]),t(e,[2,6])],defaultActions:{4:[2,1]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},r={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{"case-insensitive":!0},performAction:function(t,e,n,r){switch(n){case 0:return 4;case 1:return 9;case 2:return"space";case 3:return 10;case 4:return 6;case 5:return"TXT"}},rules:[/^(?:info\b)/i,/^(?:[\s\n\r]+)/i,/^(?:[\s]+)/i,/^(?:showInfo\b)/i,/^(?:$)/i,/^(?:.)/i],conditions:{INITIAL:{rules:[0,1,2,3,4,5],inclusive:!0}}};function i(){this.yy={}}return n.lexer=r,i.prototype=n,n.Parser=i,new i}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(1428).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},7062:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[1,4],n=[1,5],r=[1,6],i=[1,7],a=[1,9],o=[1,11,13,20,21,22,23],s=[2,5],c=[1,6,11,13,20,21,22,23],u=[20,21,22],l=[2,8],h=[1,18],f=[1,19],d=[1,24],p=[6,20,21,22,23],y={trace:function(){},yy:{},symbols_:{error:2,start:3,eol:4,directive:5,PIE:6,document:7,showData:8,line:9,statement:10,txt:11,value:12,title:13,title_value:14,openDirective:15,typeDirective:16,closeDirective:17,":":18,argDirective:19,NEWLINE:20,";":21,EOF:22,open_directive:23,type_directive:24,arg_directive:25,close_directive:26,$accept:0,$end:1},terminals_:{2:"error",6:"PIE",8:"showData",11:"txt",12:"value",13:"title",14:"title_value",18:":",20:"NEWLINE",21:";",22:"EOF",23:"open_directive",24:"type_directive",25:"arg_directive",26:"close_directive"},productions_:[0,[3,2],[3,2],[3,2],[3,3],[7,0],[7,2],[9,2],[10,0],[10,2],[10,2],[10,1],[5,3],[5,5],[4,1],[4,1],[4,1],[15,1],[16,1],[19,1],[17,1]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 4:r.setShowData(!0);break;case 7:this.$=a[s-1];break;case 9:r.addSection(a[s-1],r.cleanupValue(a[s]));break;case 10:this.$=a[s].trim(),r.setTitle(this.$);break;case 17:r.parseDirective("%%{","open_directive");break;case 18:r.parseDirective(a[s],"type_directive");break;case 19:a[s]=a[s].trim().replace(/'/g,'"'),r.parseDirective(a[s],"arg_directive");break;case 20:r.parseDirective("}%%","close_directive","pie")}},table:[{3:1,4:2,5:3,6:e,15:8,20:n,21:r,22:i,23:a},{1:[3]},{3:10,4:2,5:3,6:e,15:8,20:n,21:r,22:i,23:a},{3:11,4:2,5:3,6:e,15:8,20:n,21:r,22:i,23:a},t(o,s,{7:12,8:[1,13]}),t(c,[2,14]),t(c,[2,15]),t(c,[2,16]),{16:14,24:[1,15]},{24:[2,17]},{1:[2,1]},{1:[2,2]},t(u,l,{15:8,9:16,10:17,5:20,1:[2,3],11:h,13:f,23:a}),t(o,s,{7:21}),{17:22,18:[1,23],26:d},t([18,26],[2,18]),t(o,[2,6]),{4:25,20:n,21:r,22:i},{12:[1,26]},{14:[1,27]},t(u,[2,11]),t(u,l,{15:8,9:16,10:17,5:20,1:[2,4],11:h,13:f,23:a}),t(p,[2,12]),{19:28,25:[1,29]},t(p,[2,20]),t(o,[2,7]),t(u,[2,9]),t(u,[2,10]),{17:30,26:d},{26:[2,19]},t(p,[2,13])],defaultActions:{9:[2,17],10:[2,1],11:[2,2],29:[2,19]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},g={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{"case-insensitive":!0},performAction:function(t,e,n,r){switch(n){case 0:return this.begin("open_directive"),23;case 1:return this.begin("type_directive"),24;case 2:return this.popState(),this.begin("arg_directive"),18;case 3:return this.popState(),this.popState(),26;case 4:return 25;case 5:case 6:case 8:case 9:break;case 7:return 20;case 10:return this.begin("title"),13;case 11:return this.popState(),"title_value";case 12:this.begin("string");break;case 13:this.popState();break;case 14:return"txt";case 15:return 6;case 16:return 8;case 17:return"value";case 18:return 22}},rules:[/^(?:%%\{)/i,/^(?:((?:(?!\}%%)[^:.])*))/i,/^(?::)/i,/^(?:\}%%)/i,/^(?:((?:(?!\}%%).|\n)*))/i,/^(?:%%(?!\{)[^\n]*)/i,/^(?:[^\}]%%[^\n]*)/i,/^(?:[\n\r]+)/i,/^(?:%%[^\n]*)/i,/^(?:[\s]+)/i,/^(?:title\b)/i,/^(?:(?!\n||)*[^\n]*)/i,/^(?:["])/i,/^(?:["])/i,/^(?:[^"]*)/i,/^(?:pie\b)/i,/^(?:showData\b)/i,/^(?::[\s]*[\d]+(?:\.[\d]+)?)/i,/^(?:$)/i],conditions:{close_directive:{rules:[],inclusive:!1},arg_directive:{rules:[3,4],inclusive:!1},type_directive:{rules:[2,3],inclusive:!1},open_directive:{rules:[1],inclusive:!1},title:{rules:[11],inclusive:!1},string:{rules:[13,14],inclusive:!1},INITIAL:{rules:[0,5,6,7,8,9,10,12,15,16,17,18],inclusive:!0}}};function m(){this.yy={}}return y.lexer=g,m.prototype=y,y.Parser=m,new m}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(4551).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},3176:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[1,3],n=[1,5],r=[1,17],i=[2,10],a=[1,21],o=[1,22],s=[1,23],c=[1,24],u=[1,25],l=[1,26],h=[1,19],f=[1,27],d=[1,28],p=[1,31],y=[66,67],g=[5,8,14,35,36,37,38,39,40,48,55,57,66,67],m=[5,6,8,14,35,36,37,38,39,40,48,66,67],v=[1,51],b=[1,52],_=[1,53],x=[1,54],w=[1,55],k=[1,56],T=[1,57],E=[57,58],C=[1,69],S=[1,65],A=[1,66],M=[1,67],N=[1,68],D=[1,70],O=[1,74],B=[1,75],L=[1,72],I=[1,73],R=[5,8,14,35,36,37,38,39,40,48,66,67],F={trace:function(){},yy:{},symbols_:{error:2,start:3,directive:4,NEWLINE:5,RD:6,diagram:7,EOF:8,openDirective:9,typeDirective:10,closeDirective:11,":":12,argDirective:13,open_directive:14,type_directive:15,arg_directive:16,close_directive:17,requirementDef:18,elementDef:19,relationshipDef:20,requirementType:21,requirementName:22,STRUCT_START:23,requirementBody:24,ID:25,COLONSEP:26,id:27,TEXT:28,text:29,RISK:30,riskLevel:31,VERIFYMTHD:32,verifyType:33,STRUCT_STOP:34,REQUIREMENT:35,FUNCTIONAL_REQUIREMENT:36,INTERFACE_REQUIREMENT:37,PERFORMANCE_REQUIREMENT:38,PHYSICAL_REQUIREMENT:39,DESIGN_CONSTRAINT:40,LOW_RISK:41,MED_RISK:42,HIGH_RISK:43,VERIFY_ANALYSIS:44,VERIFY_DEMONSTRATION:45,VERIFY_INSPECTION:46,VERIFY_TEST:47,ELEMENT:48,elementName:49,elementBody:50,TYPE:51,type:52,DOCREF:53,ref:54,END_ARROW_L:55,relationship:56,LINE:57,END_ARROW_R:58,CONTAINS:59,COPIES:60,DERIVES:61,SATISFIES:62,VERIFIES:63,REFINES:64,TRACES:65,unqString:66,qString:67,$accept:0,$end:1},terminals_:{2:"error",5:"NEWLINE",6:"RD",8:"EOF",12:":",14:"open_directive",15:"type_directive",16:"arg_directive",17:"close_directive",23:"STRUCT_START",25:"ID",26:"COLONSEP",28:"TEXT",30:"RISK",32:"VERIFYMTHD",34:"STRUCT_STOP",35:"REQUIREMENT",36:"FUNCTIONAL_REQUIREMENT",37:"INTERFACE_REQUIREMENT",38:"PERFORMANCE_REQUIREMENT",39:"PHYSICAL_REQUIREMENT",40:"DESIGN_CONSTRAINT",41:"LOW_RISK",42:"MED_RISK",43:"HIGH_RISK",44:"VERIFY_ANALYSIS",45:"VERIFY_DEMONSTRATION",46:"VERIFY_INSPECTION",47:"VERIFY_TEST",48:"ELEMENT",51:"TYPE",53:"DOCREF",55:"END_ARROW_L",57:"LINE",58:"END_ARROW_R",59:"CONTAINS",60:"COPIES",61:"DERIVES",62:"SATISFIES",63:"VERIFIES",64:"REFINES",65:"TRACES",66:"unqString",67:"qString"},productions_:[0,[3,3],[3,2],[3,4],[4,3],[4,5],[9,1],[10,1],[13,1],[11,1],[7,0],[7,2],[7,2],[7,2],[7,2],[7,2],[18,5],[24,5],[24,5],[24,5],[24,5],[24,2],[24,1],[21,1],[21,1],[21,1],[21,1],[21,1],[21,1],[31,1],[31,1],[31,1],[33,1],[33,1],[33,1],[33,1],[19,5],[50,5],[50,5],[50,2],[50,1],[20,5],[20,5],[56,1],[56,1],[56,1],[56,1],[56,1],[56,1],[56,1],[22,1],[22,1],[27,1],[27,1],[29,1],[29,1],[49,1],[49,1],[52,1],[52,1],[54,1],[54,1]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 6:r.parseDirective("%%{","open_directive");break;case 7:r.parseDirective(a[s],"type_directive");break;case 8:a[s]=a[s].trim().replace(/'/g,'"'),r.parseDirective(a[s],"arg_directive");break;case 9:r.parseDirective("}%%","close_directive","pie");break;case 10:this.$=[];break;case 16:r.addRequirement(a[s-3],a[s-4]);break;case 17:r.setNewReqId(a[s-2]);break;case 18:r.setNewReqText(a[s-2]);break;case 19:r.setNewReqRisk(a[s-2]);break;case 20:r.setNewReqVerifyMethod(a[s-2]);break;case 23:this.$=r.RequirementType.REQUIREMENT;break;case 24:this.$=r.RequirementType.FUNCTIONAL_REQUIREMENT;break;case 25:this.$=r.RequirementType.INTERFACE_REQUIREMENT;break;case 26:this.$=r.RequirementType.PERFORMANCE_REQUIREMENT;break;case 27:this.$=r.RequirementType.PHYSICAL_REQUIREMENT;break;case 28:this.$=r.RequirementType.DESIGN_CONSTRAINT;break;case 29:this.$=r.RiskLevel.LOW_RISK;break;case 30:this.$=r.RiskLevel.MED_RISK;break;case 31:this.$=r.RiskLevel.HIGH_RISK;break;case 32:this.$=r.VerifyType.VERIFY_ANALYSIS;break;case 33:this.$=r.VerifyType.VERIFY_DEMONSTRATION;break;case 34:this.$=r.VerifyType.VERIFY_INSPECTION;break;case 35:this.$=r.VerifyType.VERIFY_TEST;break;case 36:r.addElement(a[s-3]);break;case 37:r.setNewElementType(a[s-2]);break;case 38:r.setNewElementDocRef(a[s-2]);break;case 41:r.addRelationship(a[s-2],a[s],a[s-4]);break;case 42:r.addRelationship(a[s-2],a[s-4],a[s]);break;case 43:this.$=r.Relationships.CONTAINS;break;case 44:this.$=r.Relationships.COPIES;break;case 45:this.$=r.Relationships.DERIVES;break;case 46:this.$=r.Relationships.SATISFIES;break;case 47:this.$=r.Relationships.VERIFIES;break;case 48:this.$=r.Relationships.REFINES;break;case 49:this.$=r.Relationships.TRACES}},table:[{3:1,4:2,6:e,9:4,14:n},{1:[3]},{3:7,4:2,5:[1,6],6:e,9:4,14:n},{5:[1,8]},{10:9,15:[1,10]},{15:[2,6]},{3:11,4:2,6:e,9:4,14:n},{1:[2,2]},{4:16,5:r,7:12,8:i,9:4,14:n,18:13,19:14,20:15,21:18,27:20,35:a,36:o,37:s,38:c,39:u,40:l,48:h,66:f,67:d},{11:29,12:[1,30],17:p},t([12,17],[2,7]),{1:[2,1]},{8:[1,32]},{4:16,5:r,7:33,8:i,9:4,14:n,18:13,19:14,20:15,21:18,27:20,35:a,36:o,37:s,38:c,39:u,40:l,48:h,66:f,67:d},{4:16,5:r,7:34,8:i,9:4,14:n,18:13,19:14,20:15,21:18,27:20,35:a,36:o,37:s,38:c,39:u,40:l,48:h,66:f,67:d},{4:16,5:r,7:35,8:i,9:4,14:n,18:13,19:14,20:15,21:18,27:20,35:a,36:o,37:s,38:c,39:u,40:l,48:h,66:f,67:d},{4:16,5:r,7:36,8:i,9:4,14:n,18:13,19:14,20:15,21:18,27:20,35:a,36:o,37:s,38:c,39:u,40:l,48:h,66:f,67:d},{4:16,5:r,7:37,8:i,9:4,14:n,18:13,19:14,20:15,21:18,27:20,35:a,36:o,37:s,38:c,39:u,40:l,48:h,66:f,67:d},{22:38,66:[1,39],67:[1,40]},{49:41,66:[1,42],67:[1,43]},{55:[1,44],57:[1,45]},t(y,[2,23]),t(y,[2,24]),t(y,[2,25]),t(y,[2,26]),t(y,[2,27]),t(y,[2,28]),t(g,[2,52]),t(g,[2,53]),t(m,[2,4]),{13:46,16:[1,47]},t(m,[2,9]),{1:[2,3]},{8:[2,11]},{8:[2,12]},{8:[2,13]},{8:[2,14]},{8:[2,15]},{23:[1,48]},{23:[2,50]},{23:[2,51]},{23:[1,49]},{23:[2,56]},{23:[2,57]},{56:50,59:v,60:b,61:_,62:x,63:w,64:k,65:T},{56:58,59:v,60:b,61:_,62:x,63:w,64:k,65:T},{11:59,17:p},{17:[2,8]},{5:[1,60]},{5:[1,61]},{57:[1,62]},t(E,[2,43]),t(E,[2,44]),t(E,[2,45]),t(E,[2,46]),t(E,[2,47]),t(E,[2,48]),t(E,[2,49]),{58:[1,63]},t(m,[2,5]),{5:C,24:64,25:S,28:A,30:M,32:N,34:D},{5:O,34:B,50:71,51:L,53:I},{27:76,66:f,67:d},{27:77,66:f,67:d},t(R,[2,16]),{26:[1,78]},{26:[1,79]},{26:[1,80]},{26:[1,81]},{5:C,24:82,25:S,28:A,30:M,32:N,34:D},t(R,[2,22]),t(R,[2,36]),{26:[1,83]},{26:[1,84]},{5:O,34:B,50:85,51:L,53:I},t(R,[2,40]),t(R,[2,41]),t(R,[2,42]),{27:86,66:f,67:d},{29:87,66:[1,88],67:[1,89]},{31:90,41:[1,91],42:[1,92],43:[1,93]},{33:94,44:[1,95],45:[1,96],46:[1,97],47:[1,98]},t(R,[2,21]),{52:99,66:[1,100],67:[1,101]},{54:102,66:[1,103],67:[1,104]},t(R,[2,39]),{5:[1,105]},{5:[1,106]},{5:[2,54]},{5:[2,55]},{5:[1,107]},{5:[2,29]},{5:[2,30]},{5:[2,31]},{5:[1,108]},{5:[2,32]},{5:[2,33]},{5:[2,34]},{5:[2,35]},{5:[1,109]},{5:[2,58]},{5:[2,59]},{5:[1,110]},{5:[2,60]},{5:[2,61]},{5:C,24:111,25:S,28:A,30:M,32:N,34:D},{5:C,24:112,25:S,28:A,30:M,32:N,34:D},{5:C,24:113,25:S,28:A,30:M,32:N,34:D},{5:C,24:114,25:S,28:A,30:M,32:N,34:D},{5:O,34:B,50:115,51:L,53:I},{5:O,34:B,50:116,51:L,53:I},t(R,[2,17]),t(R,[2,18]),t(R,[2,19]),t(R,[2,20]),t(R,[2,37]),t(R,[2,38])],defaultActions:{5:[2,6],7:[2,2],11:[2,1],32:[2,3],33:[2,11],34:[2,12],35:[2,13],36:[2,14],37:[2,15],39:[2,50],40:[2,51],42:[2,56],43:[2,57],47:[2,8],88:[2,54],89:[2,55],91:[2,29],92:[2,30],93:[2,31],95:[2,32],96:[2,33],97:[2,34],98:[2,35],100:[2,58],101:[2,59],103:[2,60],104:[2,61]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},P={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{"case-insensitive":!0},performAction:function(t,e,n,r){switch(n){case 0:return this.begin("open_directive"),14;case 1:return this.begin("type_directive"),15;case 2:return this.popState(),this.begin("arg_directive"),12;case 3:return this.popState(),this.popState(),17;case 4:return 16;case 5:return 5;case 6:case 7:case 8:break;case 9:return 8;case 10:return 6;case 11:return 23;case 12:return 34;case 13:return 26;case 14:return 25;case 15:return 28;case 16:return 30;case 17:return 32;case 18:return 35;case 19:return 36;case 20:return 37;case 21:return 38;case 22:return 39;case 23:return 40;case 24:return 41;case 25:return 42;case 26:return 43;case 27:return 44;case 28:return 45;case 29:return 46;case 30:return 47;case 31:return 48;case 32:return 59;case 33:return 60;case 34:return 61;case 35:return 62;case 36:return 63;case 37:return 64;case 38:return 65;case 39:return 51;case 40:return 53;case 41:return 55;case 42:return 58;case 43:return 57;case 44:this.begin("string");break;case 45:this.popState();break;case 46:return"qString";case 47:return e.yytext=e.yytext.trim(),66}},rules:[/^(?:%%\{)/i,/^(?:((?:(?!\}%%)[^:.])*))/i,/^(?::)/i,/^(?:\}%%)/i,/^(?:((?:(?!\}%%).|\n)*))/i,/^(?:(\r?\n)+)/i,/^(?:\s+)/i,/^(?:#[^\n]*)/i,/^(?:%[^\n]*)/i,/^(?:$)/i,/^(?:requirementDiagram\b)/i,/^(?:\{)/i,/^(?:\})/i,/^(?::)/i,/^(?:id\b)/i,/^(?:text\b)/i,/^(?:risk\b)/i,/^(?:verifyMethod\b)/i,/^(?:requirement\b)/i,/^(?:functionalRequirement\b)/i,/^(?:interfaceRequirement\b)/i,/^(?:performanceRequirement\b)/i,/^(?:physicalRequirement\b)/i,/^(?:designConstraint\b)/i,/^(?:low\b)/i,/^(?:medium\b)/i,/^(?:high\b)/i,/^(?:analysis\b)/i,/^(?:demonstration\b)/i,/^(?:inspection\b)/i,/^(?:test\b)/i,/^(?:element\b)/i,/^(?:contains\b)/i,/^(?:copies\b)/i,/^(?:derives\b)/i,/^(?:satisfies\b)/i,/^(?:verifies\b)/i,/^(?:refines\b)/i,/^(?:traces\b)/i,/^(?:type\b)/i,/^(?:docref\b)/i,/^(?:<-)/i,/^(?:->)/i,/^(?:-)/i,/^(?:["])/i,/^(?:["])/i,/^(?:[^"]*)/i,/^(?:[\w][^\r\n\{\<\>\-\=]*)/i],conditions:{close_directive:{rules:[],inclusive:!1},arg_directive:{rules:[3,4],inclusive:!1},type_directive:{rules:[2,3],inclusive:!1},open_directive:{rules:[1],inclusive:!1},unqString:{rules:[],inclusive:!1},token:{rules:[],inclusive:!1},string:{rules:[45,46],inclusive:!1},INITIAL:{rules:[0,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,47],inclusive:!0}}};function j(){this.yy={}}return F.lexer=P,j.prototype=F,F.Parser=j,new j}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(8800).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},6876:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[1,2],n=[1,3],r=[1,5],i=[1,7],a=[2,5],o=[1,15],s=[1,17],c=[1,18],u=[1,19],l=[1,21],h=[1,22],f=[1,23],d=[1,29],p=[1,30],y=[1,31],g=[1,32],m=[1,33],v=[1,34],b=[1,37],_=[1,38],x=[1,39],w=[1,40],k=[1,41],T=[1,42],E=[1,45],C=[1,4,5,16,20,22,23,24,30,32,33,34,35,36,38,40,41,42,46,47,48,49,57,67],S=[1,58],A=[4,5,16,20,22,23,24,30,32,33,34,35,36,38,42,46,47,48,49,57,67],M=[4,5,16,20,22,23,24,30,32,33,34,35,36,38,41,42,46,47,48,49,57,67],N=[4,5,16,20,22,23,24,30,32,33,34,35,36,38,40,42,46,47,48,49,57,67],D=[55,56,57],O=[1,4,5,7,16,20,22,23,24,30,32,33,34,35,36,38,40,41,42,46,47,48,49,57,67],B={trace:function(){},yy:{},symbols_:{error:2,start:3,SPACE:4,NEWLINE:5,directive:6,SD:7,document:8,line:9,statement:10,openDirective:11,typeDirective:12,closeDirective:13,":":14,argDirective:15,participant:16,actor:17,AS:18,restOfLine:19,participant_actor:20,signal:21,autonumber:22,activate:23,deactivate:24,note_statement:25,links_statement:26,link_statement:27,properties_statement:28,details_statement:29,title:30,text2:31,loop:32,end:33,rect:34,opt:35,alt:36,else_sections:37,par:38,par_sections:39,and:40,else:41,note:42,placement:43,over:44,actor_pair:45,links:46,link:47,properties:48,details:49,spaceList:50,",":51,left_of:52,right_of:53,signaltype:54,"+":55,"-":56,ACTOR:57,SOLID_OPEN_ARROW:58,DOTTED_OPEN_ARROW:59,SOLID_ARROW:60,DOTTED_ARROW:61,SOLID_CROSS:62,DOTTED_CROSS:63,SOLID_POINT:64,DOTTED_POINT:65,TXT:66,open_directive:67,type_directive:68,arg_directive:69,close_directive:70,$accept:0,$end:1},terminals_:{2:"error",4:"SPACE",5:"NEWLINE",7:"SD",14:":",16:"participant",18:"AS",19:"restOfLine",20:"participant_actor",22:"autonumber",23:"activate",24:"deactivate",30:"title",32:"loop",33:"end",34:"rect",35:"opt",36:"alt",38:"par",40:"and",41:"else",42:"note",44:"over",46:"links",47:"link",48:"properties",49:"details",51:",",52:"left_of",53:"right_of",55:"+",56:"-",57:"ACTOR",58:"SOLID_OPEN_ARROW",59:"DOTTED_OPEN_ARROW",60:"SOLID_ARROW",61:"DOTTED_ARROW",62:"SOLID_CROSS",63:"DOTTED_CROSS",64:"SOLID_POINT",65:"DOTTED_POINT",66:"TXT",67:"open_directive",68:"type_directive",69:"arg_directive",70:"close_directive"},productions_:[0,[3,2],[3,2],[3,2],[3,2],[8,0],[8,2],[9,2],[9,1],[9,1],[6,4],[6,6],[10,5],[10,3],[10,5],[10,3],[10,2],[10,1],[10,3],[10,3],[10,2],[10,2],[10,2],[10,2],[10,2],[10,3],[10,4],[10,4],[10,4],[10,4],[10,4],[10,1],[39,1],[39,4],[37,1],[37,4],[25,4],[25,4],[26,3],[27,3],[28,3],[29,3],[50,2],[50,1],[45,3],[45,1],[43,1],[43,1],[21,5],[21,5],[21,4],[17,1],[54,1],[54,1],[54,1],[54,1],[54,1],[54,1],[54,1],[54,1],[31,1],[11,1],[12,1],[15,1],[13,1]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 4:return r.apply(a[s]),a[s];case 5:case 9:this.$=[];break;case 6:a[s-1].push(a[s]),this.$=a[s-1];break;case 7:case 8:case 45:this.$=a[s];break;case 12:a[s-3].type="addParticipant",a[s-3].description=r.parseMessage(a[s-1]),this.$=a[s-3];break;case 13:a[s-1].type="addParticipant",this.$=a[s-1];break;case 14:a[s-3].type="addActor",a[s-3].description=r.parseMessage(a[s-1]),this.$=a[s-3];break;case 15:a[s-1].type="addActor",this.$=a[s-1];break;case 17:r.enableSequenceNumbers();break;case 18:this.$={type:"activeStart",signalType:r.LINETYPE.ACTIVE_START,actor:a[s-1]};break;case 19:this.$={type:"activeEnd",signalType:r.LINETYPE.ACTIVE_END,actor:a[s-1]};break;case 25:this.$=[{type:"setTitle",text:a[s-1]}];break;case 26:a[s-1].unshift({type:"loopStart",loopText:r.parseMessage(a[s-2]),signalType:r.LINETYPE.LOOP_START}),a[s-1].push({type:"loopEnd",loopText:a[s-2],signalType:r.LINETYPE.LOOP_END}),this.$=a[s-1];break;case 27:a[s-1].unshift({type:"rectStart",color:r.parseMessage(a[s-2]),signalType:r.LINETYPE.RECT_START}),a[s-1].push({type:"rectEnd",color:r.parseMessage(a[s-2]),signalType:r.LINETYPE.RECT_END}),this.$=a[s-1];break;case 28:a[s-1].unshift({type:"optStart",optText:r.parseMessage(a[s-2]),signalType:r.LINETYPE.OPT_START}),a[s-1].push({type:"optEnd",optText:r.parseMessage(a[s-2]),signalType:r.LINETYPE.OPT_END}),this.$=a[s-1];break;case 29:a[s-1].unshift({type:"altStart",altText:r.parseMessage(a[s-2]),signalType:r.LINETYPE.ALT_START}),a[s-1].push({type:"altEnd",signalType:r.LINETYPE.ALT_END}),this.$=a[s-1];break;case 30:a[s-1].unshift({type:"parStart",parText:r.parseMessage(a[s-2]),signalType:r.LINETYPE.PAR_START}),a[s-1].push({type:"parEnd",signalType:r.LINETYPE.PAR_END}),this.$=a[s-1];break;case 33:this.$=a[s-3].concat([{type:"and",parText:r.parseMessage(a[s-1]),signalType:r.LINETYPE.PAR_AND},a[s]]);break;case 35:this.$=a[s-3].concat([{type:"else",altText:r.parseMessage(a[s-1]),signalType:r.LINETYPE.ALT_ELSE},a[s]]);break;case 36:this.$=[a[s-1],{type:"addNote",placement:a[s-2],actor:a[s-1].actor,text:a[s]}];break;case 37:a[s-2]=[].concat(a[s-1],a[s-1]).slice(0,2),a[s-2][0]=a[s-2][0].actor,a[s-2][1]=a[s-2][1].actor,this.$=[a[s-1],{type:"addNote",placement:r.PLACEMENT.OVER,actor:a[s-2].slice(0,2),text:a[s]}];break;case 38:this.$=[a[s-1],{type:"addLinks",actor:a[s-1].actor,text:a[s]}];break;case 39:this.$=[a[s-1],{type:"addALink",actor:a[s-1].actor,text:a[s]}];break;case 40:this.$=[a[s-1],{type:"addProperties",actor:a[s-1].actor,text:a[s]}];break;case 41:this.$=[a[s-1],{type:"addDetails",actor:a[s-1].actor,text:a[s]}];break;case 44:this.$=[a[s-2],a[s]];break;case 46:this.$=r.PLACEMENT.LEFTOF;break;case 47:this.$=r.PLACEMENT.RIGHTOF;break;case 48:this.$=[a[s-4],a[s-1],{type:"addMessage",from:a[s-4].actor,to:a[s-1].actor,signalType:a[s-3],msg:a[s]},{type:"activeStart",signalType:r.LINETYPE.ACTIVE_START,actor:a[s-1]}];break;case 49:this.$=[a[s-4],a[s-1],{type:"addMessage",from:a[s-4].actor,to:a[s-1].actor,signalType:a[s-3],msg:a[s]},{type:"activeEnd",signalType:r.LINETYPE.ACTIVE_END,actor:a[s-4]}];break;case 50:this.$=[a[s-3],a[s-1],{type:"addMessage",from:a[s-3].actor,to:a[s-1].actor,signalType:a[s-2],msg:a[s]}];break;case 51:this.$={type:"addParticipant",actor:a[s]};break;case 52:this.$=r.LINETYPE.SOLID_OPEN;break;case 53:this.$=r.LINETYPE.DOTTED_OPEN;break;case 54:this.$=r.LINETYPE.SOLID;break;case 55:this.$=r.LINETYPE.DOTTED;break;case 56:this.$=r.LINETYPE.SOLID_CROSS;break;case 57:this.$=r.LINETYPE.DOTTED_CROSS;break;case 58:this.$=r.LINETYPE.SOLID_POINT;break;case 59:this.$=r.LINETYPE.DOTTED_POINT;break;case 60:this.$=r.parseMessage(a[s].trim().substring(1));break;case 61:r.parseDirective("%%{","open_directive");break;case 62:r.parseDirective(a[s],"type_directive");break;case 63:a[s]=a[s].trim().replace(/'/g,'"'),r.parseDirective(a[s],"arg_directive");break;case 64:r.parseDirective("}%%","close_directive","sequence")}},table:[{3:1,4:e,5:n,6:4,7:r,11:6,67:i},{1:[3]},{3:8,4:e,5:n,6:4,7:r,11:6,67:i},{3:9,4:e,5:n,6:4,7:r,11:6,67:i},{3:10,4:e,5:n,6:4,7:r,11:6,67:i},t([1,4,5,16,20,22,23,24,30,32,34,35,36,38,42,46,47,48,49,57,67],a,{8:11}),{12:12,68:[1,13]},{68:[2,61]},{1:[2,1]},{1:[2,2]},{1:[2,3]},{1:[2,4],4:o,5:s,6:35,9:14,10:16,11:6,16:c,17:36,20:u,21:20,22:l,23:h,24:f,25:24,26:25,27:26,28:27,29:28,30:d,32:p,34:y,35:g,36:m,38:v,42:b,46:_,47:x,48:w,49:k,57:T,67:i},{13:43,14:[1,44],70:E},t([14,70],[2,62]),t(C,[2,6]),{6:35,10:46,11:6,16:c,17:36,20:u,21:20,22:l,23:h,24:f,25:24,26:25,27:26,28:27,29:28,30:d,32:p,34:y,35:g,36:m,38:v,42:b,46:_,47:x,48:w,49:k,57:T,67:i},t(C,[2,8]),t(C,[2,9]),{17:47,57:T},{17:48,57:T},{5:[1,49]},t(C,[2,17]),{17:50,57:T},{17:51,57:T},{5:[1,52]},{5:[1,53]},{5:[1,54]},{5:[1,55]},{5:[1,56]},{31:57,66:S},{19:[1,59]},{19:[1,60]},{19:[1,61]},{19:[1,62]},{19:[1,63]},t(C,[2,31]),{54:64,58:[1,65],59:[1,66],60:[1,67],61:[1,68],62:[1,69],63:[1,70],64:[1,71],65:[1,72]},{43:73,44:[1,74],52:[1,75],53:[1,76]},{17:77,57:T},{17:78,57:T},{17:79,57:T},{17:80,57:T},t([5,18,51,58,59,60,61,62,63,64,65,66],[2,51]),{5:[1,81]},{15:82,69:[1,83]},{5:[2,64]},t(C,[2,7]),{5:[1,85],18:[1,84]},{5:[1,87],18:[1,86]},t(C,[2,16]),{5:[1,88]},{5:[1,89]},t(C,[2,20]),t(C,[2,21]),t(C,[2,22]),t(C,[2,23]),t(C,[2,24]),{5:[1,90]},{5:[2,60]},t(A,a,{8:91}),t(A,a,{8:92}),t(A,a,{8:93}),t(M,a,{37:94,8:95}),t(N,a,{39:96,8:97}),{17:100,55:[1,98],56:[1,99],57:T},t(D,[2,52]),t(D,[2,53]),t(D,[2,54]),t(D,[2,55]),t(D,[2,56]),t(D,[2,57]),t(D,[2,58]),t(D,[2,59]),{17:101,57:T},{17:103,45:102,57:T},{57:[2,46]},{57:[2,47]},{31:104,66:S},{31:105,66:S},{31:106,66:S},{31:107,66:S},t(O,[2,10]),{13:108,70:E},{70:[2,63]},{19:[1,109]},t(C,[2,13]),{19:[1,110]},t(C,[2,15]),t(C,[2,18]),t(C,[2,19]),t(C,[2,25]),{4:o,5:s,6:35,9:14,10:16,11:6,16:c,17:36,20:u,21:20,22:l,23:h,24:f,25:24,26:25,27:26,28:27,29:28,30:d,32:p,33:[1,111],34:y,35:g,36:m,38:v,42:b,46:_,47:x,48:w,49:k,57:T,67:i},{4:o,5:s,6:35,9:14,10:16,11:6,16:c,17:36,20:u,21:20,22:l,23:h,24:f,25:24,26:25,27:26,28:27,29:28,30:d,32:p,33:[1,112],34:y,35:g,36:m,38:v,42:b,46:_,47:x,48:w,49:k,57:T,67:i},{4:o,5:s,6:35,9:14,10:16,11:6,16:c,17:36,20:u,21:20,22:l,23:h,24:f,25:24,26:25,27:26,28:27,29:28,30:d,32:p,33:[1,113],34:y,35:g,36:m,38:v,42:b,46:_,47:x,48:w,49:k,57:T,67:i},{33:[1,114]},{4:o,5:s,6:35,9:14,10:16,11:6,16:c,17:36,20:u,21:20,22:l,23:h,24:f,25:24,26:25,27:26,28:27,29:28,30:d,32:p,33:[2,34],34:y,35:g,36:m,38:v,41:[1,115],42:b,46:_,47:x,48:w,49:k,57:T,67:i},{33:[1,116]},{4:o,5:s,6:35,9:14,10:16,11:6,16:c,17:36,20:u,21:20,22:l,23:h,24:f,25:24,26:25,27:26,28:27,29:28,30:d,32:p,33:[2,32],34:y,35:g,36:m,38:v,40:[1,117],42:b,46:_,47:x,48:w,49:k,57:T,67:i},{17:118,57:T},{17:119,57:T},{31:120,66:S},{31:121,66:S},{31:122,66:S},{51:[1,123],66:[2,45]},{5:[2,38]},{5:[2,39]},{5:[2,40]},{5:[2,41]},{5:[1,124]},{5:[1,125]},{5:[1,126]},t(C,[2,26]),t(C,[2,27]),t(C,[2,28]),t(C,[2,29]),{19:[1,127]},t(C,[2,30]),{19:[1,128]},{31:129,66:S},{31:130,66:S},{5:[2,50]},{5:[2,36]},{5:[2,37]},{17:131,57:T},t(O,[2,11]),t(C,[2,12]),t(C,[2,14]),t(M,a,{8:95,37:132}),t(N,a,{8:97,39:133}),{5:[2,48]},{5:[2,49]},{66:[2,44]},{33:[2,35]},{33:[2,33]}],defaultActions:{7:[2,61],8:[2,1],9:[2,2],10:[2,3],45:[2,64],58:[2,60],75:[2,46],76:[2,47],83:[2,63],104:[2,38],105:[2,39],106:[2,40],107:[2,41],120:[2,50],121:[2,36],122:[2,37],129:[2,48],130:[2,49],131:[2,44],132:[2,35],133:[2,33]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},L={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{"case-insensitive":!0},performAction:function(t,e,n,r){switch(n){case 0:return this.begin("open_directive"),67;case 1:return this.begin("type_directive"),68;case 2:return this.popState(),this.begin("arg_directive"),14;case 3:return this.popState(),this.popState(),70;case 4:return 69;case 5:case 39:case 52:return 5;case 6:case 7:case 8:case 9:case 10:break;case 11:return this.begin("ID"),16;case 12:return this.begin("ID"),20;case 13:return e.yytext=e.yytext.trim(),this.begin("ALIAS"),57;case 14:return this.popState(),this.popState(),this.begin("LINE"),18;case 15:return this.popState(),this.popState(),5;case 16:return this.begin("LINE"),32;case 17:return this.begin("LINE"),34;case 18:return this.begin("LINE"),35;case 19:return this.begin("LINE"),36;case 20:return this.begin("LINE"),41;case 21:return this.begin("LINE"),38;case 22:return this.begin("LINE"),40;case 23:return this.popState(),19;case 24:return 33;case 25:return 52;case 26:return 53;case 27:return 46;case 28:return 47;case 29:return 48;case 30:return 49;case 31:return 44;case 32:return 42;case 33:return this.begin("ID"),23;case 34:return this.begin("ID"),24;case 35:return 30;case 36:return 7;case 37:return 22;case 38:return 51;case 40:return e.yytext=e.yytext.trim(),57;case 41:return 60;case 42:return 61;case 43:return 58;case 44:return 59;case 45:return 62;case 46:return 63;case 47:return 64;case 48:return 65;case 49:return 66;case 50:return 55;case 51:return 56;case 53:return"INVALID"}},rules:[/^(?:%%\{)/i,/^(?:((?:(?!\}%%)[^:.])*))/i,/^(?::)/i,/^(?:\}%%)/i,/^(?:((?:(?!\}%%).|\n)*))/i,/^(?:[\n]+)/i,/^(?:\s+)/i,/^(?:((?!\n)\s)+)/i,/^(?:#[^\n]*)/i,/^(?:%(?!\{)[^\n]*)/i,/^(?:[^\}]%%[^\n]*)/i,/^(?:participant\b)/i,/^(?:actor\b)/i,/^(?:[^\->:\n,;]+?(?=((?!\n)\s)+as(?!\n)\s|[#\n;]|$))/i,/^(?:as\b)/i,/^(?:(?:))/i,/^(?:loop\b)/i,/^(?:rect\b)/i,/^(?:opt\b)/i,/^(?:alt\b)/i,/^(?:else\b)/i,/^(?:par\b)/i,/^(?:and\b)/i,/^(?:(?:[:]?(?:no)?wrap)?[^#\n;]*)/i,/^(?:end\b)/i,/^(?:left of\b)/i,/^(?:right of\b)/i,/^(?:links\b)/i,/^(?:link\b)/i,/^(?:properties\b)/i,/^(?:details\b)/i,/^(?:over\b)/i,/^(?:note\b)/i,/^(?:activate\b)/i,/^(?:deactivate\b)/i,/^(?:title\b)/i,/^(?:sequenceDiagram\b)/i,/^(?:autonumber\b)/i,/^(?:,)/i,/^(?:;)/i,/^(?:[^\+\->:\n,;]+((?!(-x|--x|-\)|--\)))[\-]*[^\+\->:\n,;]+)*)/i,/^(?:->>)/i,/^(?:-->>)/i,/^(?:->)/i,/^(?:-->)/i,/^(?:-[x])/i,/^(?:--[x])/i,/^(?:-[\)])/i,/^(?:--[\)])/i,/^(?::(?:(?:no)?wrap)?[^#\n;]+)/i,/^(?:\+)/i,/^(?:-)/i,/^(?:$)/i,/^(?:.)/i],conditions:{open_directive:{rules:[1,8],inclusive:!1},type_directive:{rules:[2,3,8],inclusive:!1},arg_directive:{rules:[3,4,8],inclusive:!1},ID:{rules:[7,8,13],inclusive:!1},ALIAS:{rules:[7,8,14,15],inclusive:!1},LINE:{rules:[7,8,23],inclusive:!1},INITIAL:{rules:[0,5,6,8,9,10,11,12,16,17,18,19,20,21,22,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53],inclusive:!0}}};function I(){this.yy={}}return B.lexer=L,I.prototype=B,B.Parser=I,new I}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(1993).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},3584:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[1,2],n=[1,3],r=[1,5],i=[1,7],a=[2,5],o=[1,15],s=[1,17],c=[1,19],u=[1,20],l=[1,21],h=[1,22],f=[1,30],d=[1,23],p=[1,24],y=[1,25],g=[1,26],m=[1,27],v=[1,32],b=[1,33],_=[1,34],x=[1,35],w=[1,31],k=[1,38],T=[1,4,5,14,15,17,19,20,22,23,24,25,26,27,36,37,38,39,42,45],E=[1,4,5,12,13,14,15,17,19,20,22,23,24,25,26,27,36,37,38,39,42,45],C=[1,4,5,7,14,15,17,19,20,22,23,24,25,26,27,36,37,38,39,42,45],S=[4,5,14,15,17,19,20,22,23,24,25,26,27,36,37,38,39,42,45],A={trace:function(){},yy:{},symbols_:{error:2,start:3,SPACE:4,NL:5,directive:6,SD:7,document:8,line:9,statement:10,idStatement:11,DESCR:12,"--\x3e":13,HIDE_EMPTY:14,scale:15,WIDTH:16,COMPOSIT_STATE:17,STRUCT_START:18,STRUCT_STOP:19,STATE_DESCR:20,AS:21,ID:22,FORK:23,JOIN:24,CHOICE:25,CONCURRENT:26,note:27,notePosition:28,NOTE_TEXT:29,direction:30,openDirective:31,typeDirective:32,closeDirective:33,":":34,argDirective:35,direction_tb:36,direction_bt:37,direction_rl:38,direction_lr:39,eol:40,";":41,EDGE_STATE:42,left_of:43,right_of:44,open_directive:45,type_directive:46,arg_directive:47,close_directive:48,$accept:0,$end:1},terminals_:{2:"error",4:"SPACE",5:"NL",7:"SD",12:"DESCR",13:"--\x3e",14:"HIDE_EMPTY",15:"scale",16:"WIDTH",17:"COMPOSIT_STATE",18:"STRUCT_START",19:"STRUCT_STOP",20:"STATE_DESCR",21:"AS",22:"ID",23:"FORK",24:"JOIN",25:"CHOICE",26:"CONCURRENT",27:"note",29:"NOTE_TEXT",34:":",36:"direction_tb",37:"direction_bt",38:"direction_rl",39:"direction_lr",41:";",42:"EDGE_STATE",43:"left_of",44:"right_of",45:"open_directive",46:"type_directive",47:"arg_directive",48:"close_directive"},productions_:[0,[3,2],[3,2],[3,2],[3,2],[8,0],[8,2],[9,2],[9,1],[9,1],[10,1],[10,2],[10,3],[10,4],[10,1],[10,2],[10,1],[10,4],[10,3],[10,6],[10,1],[10,1],[10,1],[10,1],[10,4],[10,4],[10,1],[10,1],[6,3],[6,5],[30,1],[30,1],[30,1],[30,1],[40,1],[40,1],[11,1],[11,1],[28,1],[28,1],[31,1],[32,1],[35,1],[33,1]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 4:return r.setRootDoc(a[s]),a[s];case 5:this.$=[];break;case 6:"nl"!=a[s]&&(a[s-1].push(a[s]),this.$=a[s-1]);break;case 7:case 8:case 36:case 37:this.$=a[s];break;case 9:this.$="nl";break;case 10:this.$={stmt:"state",id:a[s],type:"default",description:""};break;case 11:this.$={stmt:"state",id:a[s-1],type:"default",description:r.trimColon(a[s])};break;case 12:this.$={stmt:"relation",state1:{stmt:"state",id:a[s-2],type:"default",description:""},state2:{stmt:"state",id:a[s],type:"default",description:""}};break;case 13:this.$={stmt:"relation",state1:{stmt:"state",id:a[s-3],type:"default",description:""},state2:{stmt:"state",id:a[s-1],type:"default",description:""},description:a[s].substr(1).trim()};break;case 17:this.$={stmt:"state",id:a[s-3],type:"default",description:"",doc:a[s-1]};break;case 18:var c=a[s],u=a[s-2].trim();if(a[s].match(":")){var l=a[s].split(":");c=l[0],u=[u,l[1]]}this.$={stmt:"state",id:c,type:"default",description:u};break;case 19:this.$={stmt:"state",id:a[s-3],type:"default",description:a[s-5],doc:a[s-1]};break;case 20:this.$={stmt:"state",id:a[s],type:"fork"};break;case 21:this.$={stmt:"state",id:a[s],type:"join"};break;case 22:this.$={stmt:"state",id:a[s],type:"choice"};break;case 23:this.$={stmt:"state",id:r.getDividerId(),type:"divider"};break;case 24:this.$={stmt:"state",id:a[s-1].trim(),note:{position:a[s-2].trim(),text:a[s].trim()}};break;case 30:r.setDirection("TB"),this.$={stmt:"dir",value:"TB"};break;case 31:r.setDirection("BT"),this.$={stmt:"dir",value:"BT"};break;case 32:r.setDirection("RL"),this.$={stmt:"dir",value:"RL"};break;case 33:r.setDirection("LR"),this.$={stmt:"dir",value:"LR"};break;case 40:r.parseDirective("%%{","open_directive");break;case 41:r.parseDirective(a[s],"type_directive");break;case 42:a[s]=a[s].trim().replace(/'/g,'"'),r.parseDirective(a[s],"arg_directive");break;case 43:r.parseDirective("}%%","close_directive","state")}},table:[{3:1,4:e,5:n,6:4,7:r,31:6,45:i},{1:[3]},{3:8,4:e,5:n,6:4,7:r,31:6,45:i},{3:9,4:e,5:n,6:4,7:r,31:6,45:i},{3:10,4:e,5:n,6:4,7:r,31:6,45:i},t([1,4,5,14,15,17,20,22,23,24,25,26,27,36,37,38,39,42,45],a,{8:11}),{32:12,46:[1,13]},{46:[2,40]},{1:[2,1]},{1:[2,2]},{1:[2,3]},{1:[2,4],4:o,5:s,6:28,9:14,10:16,11:18,14:c,15:u,17:l,20:h,22:f,23:d,24:p,25:y,26:g,27:m,30:29,31:6,36:v,37:b,38:_,39:x,42:w,45:i},{33:36,34:[1,37],48:k},t([34,48],[2,41]),t(T,[2,6]),{6:28,10:39,11:18,14:c,15:u,17:l,20:h,22:f,23:d,24:p,25:y,26:g,27:m,30:29,31:6,36:v,37:b,38:_,39:x,42:w,45:i},t(T,[2,8]),t(T,[2,9]),t(T,[2,10],{12:[1,40],13:[1,41]}),t(T,[2,14]),{16:[1,42]},t(T,[2,16],{18:[1,43]}),{21:[1,44]},t(T,[2,20]),t(T,[2,21]),t(T,[2,22]),t(T,[2,23]),{28:45,29:[1,46],43:[1,47],44:[1,48]},t(T,[2,26]),t(T,[2,27]),t(E,[2,36]),t(E,[2,37]),t(T,[2,30]),t(T,[2,31]),t(T,[2,32]),t(T,[2,33]),t(C,[2,28]),{35:49,47:[1,50]},t(C,[2,43]),t(T,[2,7]),t(T,[2,11]),{11:51,22:f,42:w},t(T,[2,15]),t(S,a,{8:52}),{22:[1,53]},{22:[1,54]},{21:[1,55]},{22:[2,38]},{22:[2,39]},{33:56,48:k},{48:[2,42]},t(T,[2,12],{12:[1,57]}),{4:o,5:s,6:28,9:14,10:16,11:18,14:c,15:u,17:l,19:[1,58],20:h,22:f,23:d,24:p,25:y,26:g,27:m,30:29,31:6,36:v,37:b,38:_,39:x,42:w,45:i},t(T,[2,18],{18:[1,59]}),{29:[1,60]},{22:[1,61]},t(C,[2,29]),t(T,[2,13]),t(T,[2,17]),t(S,a,{8:62}),t(T,[2,24]),t(T,[2,25]),{4:o,5:s,6:28,9:14,10:16,11:18,14:c,15:u,17:l,19:[1,63],20:h,22:f,23:d,24:p,25:y,26:g,27:m,30:29,31:6,36:v,37:b,38:_,39:x,42:w,45:i},t(T,[2,19])],defaultActions:{7:[2,40],8:[2,1],9:[2,2],10:[2,3],47:[2,38],48:[2,39],50:[2,42]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},M={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{"case-insensitive":!0},performAction:function(t,e,n,r){switch(n){case 0:case 26:return 36;case 1:case 27:return 37;case 2:case 28:return 38;case 3:case 29:return 39;case 4:return this.begin("open_directive"),45;case 5:return this.begin("type_directive"),46;case 6:return this.popState(),this.begin("arg_directive"),34;case 7:return this.popState(),this.popState(),48;case 8:return 47;case 9:case 10:case 12:case 13:case 14:case 15:case 39:case 45:break;case 11:case 59:return 5;case 16:return this.pushState("SCALE"),15;case 17:return 16;case 18:case 33:case 36:this.popState();break;case 19:this.pushState("STATE");break;case 20:case 23:return this.popState(),e.yytext=e.yytext.slice(0,-8).trim(),23;case 21:case 24:return this.popState(),e.yytext=e.yytext.slice(0,-8).trim(),24;case 22:case 25:return this.popState(),e.yytext=e.yytext.slice(0,-10).trim(),25;case 30:this.begin("STATE_STRING");break;case 31:return this.popState(),this.pushState("STATE_ID"),"AS";case 32:case 47:return this.popState(),"ID";case 34:return"STATE_DESCR";case 35:return 17;case 37:return this.popState(),this.pushState("struct"),18;case 38:return this.popState(),19;case 40:return this.begin("NOTE"),27;case 41:return this.popState(),this.pushState("NOTE_ID"),43;case 42:return this.popState(),this.pushState("NOTE_ID"),44;case 43:this.popState(),this.pushState("FLOATING_NOTE");break;case 44:return this.popState(),this.pushState("FLOATING_NOTE_ID"),"AS";case 46:return"NOTE_TEXT";case 48:return this.popState(),this.pushState("NOTE_TEXT"),22;case 49:return this.popState(),e.yytext=e.yytext.substr(2).trim(),29;case 50:return this.popState(),e.yytext=e.yytext.slice(0,-8).trim(),29;case 51:case 52:return 7;case 53:return 14;case 54:return 42;case 55:return 22;case 56:return e.yytext=e.yytext.trim(),12;case 57:return 13;case 58:return 26;case 60:return"INVALID"}},rules:[/^(?:.*direction\s+TB[^\n]*)/i,/^(?:.*direction\s+BT[^\n]*)/i,/^(?:.*direction\s+RL[^\n]*)/i,/^(?:.*direction\s+LR[^\n]*)/i,/^(?:%%\{)/i,/^(?:((?:(?!\}%%)[^:.])*))/i,/^(?::)/i,/^(?:\}%%)/i,/^(?:((?:(?!\}%%).|\n)*))/i,/^(?:%%(?!\{)[^\n]*)/i,/^(?:[^\}]%%[^\n]*)/i,/^(?:[\n]+)/i,/^(?:[\s]+)/i,/^(?:((?!\n)\s)+)/i,/^(?:#[^\n]*)/i,/^(?:%[^\n]*)/i,/^(?:scale\s+)/i,/^(?:\d+)/i,/^(?:\s+width\b)/i,/^(?:state\s+)/i,/^(?:.*<>)/i,/^(?:.*<>)/i,/^(?:.*<>)/i,/^(?:.*\[\[fork\]\])/i,/^(?:.*\[\[join\]\])/i,/^(?:.*\[\[choice\]\])/i,/^(?:.*direction\s+TB[^\n]*)/i,/^(?:.*direction\s+BT[^\n]*)/i,/^(?:.*direction\s+RL[^\n]*)/i,/^(?:.*direction\s+LR[^\n]*)/i,/^(?:["])/i,/^(?:\s*as\s+)/i,/^(?:[^\n\{]*)/i,/^(?:["])/i,/^(?:[^"]*)/i,/^(?:[^\n\s\{]+)/i,/^(?:\n)/i,/^(?:\{)/i,/^(?:\})/i,/^(?:[\n])/i,/^(?:note\s+)/i,/^(?:left of\b)/i,/^(?:right of\b)/i,/^(?:")/i,/^(?:\s*as\s*)/i,/^(?:["])/i,/^(?:[^"]*)/i,/^(?:[^\n]*)/i,/^(?:\s*[^:\n\s\-]+)/i,/^(?:\s*:[^:\n;]+)/i,/^(?:[\s\S]*?end note\b)/i,/^(?:stateDiagram\s+)/i,/^(?:stateDiagram-v2\s+)/i,/^(?:hide empty description\b)/i,/^(?:\[\*\])/i,/^(?:[^:\n\s\-\{]+)/i,/^(?:\s*:[^:\n;]+)/i,/^(?:-->)/i,/^(?:--)/i,/^(?:$)/i,/^(?:.)/i],conditions:{LINE:{rules:[13,14],inclusive:!1},close_directive:{rules:[13,14],inclusive:!1},arg_directive:{rules:[7,8,13,14],inclusive:!1},type_directive:{rules:[6,7,13,14],inclusive:!1},open_directive:{rules:[5,13,14],inclusive:!1},struct:{rules:[13,14,19,26,27,28,29,38,39,40,54,55,56,57,58],inclusive:!1},FLOATING_NOTE_ID:{rules:[47],inclusive:!1},FLOATING_NOTE:{rules:[44,45,46],inclusive:!1},NOTE_TEXT:{rules:[49,50],inclusive:!1},NOTE_ID:{rules:[48],inclusive:!1},NOTE:{rules:[41,42,43],inclusive:!1},SCALE:{rules:[17,18],inclusive:!1},ALIAS:{rules:[],inclusive:!1},STATE_ID:{rules:[32],inclusive:!1},STATE_STRING:{rules:[33,34],inclusive:!1},FORK_STATE:{rules:[],inclusive:!1},STATE:{rules:[13,14,20,21,22,23,24,25,30,31,35,36,37],inclusive:!1},ID:{rules:[13,14],inclusive:!1},INITIAL:{rules:[0,1,2,3,4,9,10,11,12,14,15,16,19,37,40,51,52,53,54,55,56,57,59,60],inclusive:!0}}};function N(){this.yy={}}return A.lexer=M,N.prototype=A,A.Parser=N,new N}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(3069).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},9763:(t,e,n)=>{t=n.nmd(t);var r=function(){var t=function(t,e,n,r){for(n=n||{},r=t.length;r--;n[t[r]]=e);return n},e=[1,2],n=[1,5],r=[6,9,11,17,18,19,21],i=[1,15],a=[1,16],o=[1,17],s=[1,21],c=[4,6,9,11,17,18,19,21],u={trace:function(){},yy:{},symbols_:{error:2,start:3,journey:4,document:5,EOF:6,directive:7,line:8,SPACE:9,statement:10,NEWLINE:11,openDirective:12,typeDirective:13,closeDirective:14,":":15,argDirective:16,title:17,section:18,taskName:19,taskData:20,open_directive:21,type_directive:22,arg_directive:23,close_directive:24,$accept:0,$end:1},terminals_:{2:"error",4:"journey",6:"EOF",9:"SPACE",11:"NEWLINE",15:":",17:"title",18:"section",19:"taskName",20:"taskData",21:"open_directive",22:"type_directive",23:"arg_directive",24:"close_directive"},productions_:[0,[3,3],[3,2],[5,0],[5,2],[8,2],[8,1],[8,1],[8,1],[7,4],[7,6],[10,1],[10,1],[10,2],[10,1],[12,1],[13,1],[16,1],[14,1]],performAction:function(t,e,n,r,i,a,o){var s=a.length-1;switch(i){case 1:return a[s-1];case 3:case 7:case 8:this.$=[];break;case 4:a[s-1].push(a[s]),this.$=a[s-1];break;case 5:case 6:this.$=a[s];break;case 11:r.setTitle(a[s].substr(6)),this.$=a[s].substr(6);break;case 12:r.addSection(a[s].substr(8)),this.$=a[s].substr(8);break;case 13:r.addTask(a[s-1],a[s]),this.$="task";break;case 15:r.parseDirective("%%{","open_directive");break;case 16:r.parseDirective(a[s],"type_directive");break;case 17:a[s]=a[s].trim().replace(/'/g,'"'),r.parseDirective(a[s],"arg_directive");break;case 18:r.parseDirective("}%%","close_directive","journey")}},table:[{3:1,4:e,7:3,12:4,21:n},{1:[3]},t(r,[2,3],{5:6}),{3:7,4:e,7:3,12:4,21:n},{13:8,22:[1,9]},{22:[2,15]},{6:[1,10],7:18,8:11,9:[1,12],10:13,11:[1,14],12:4,17:i,18:a,19:o,21:n},{1:[2,2]},{14:19,15:[1,20],24:s},t([15,24],[2,16]),t(r,[2,8],{1:[2,1]}),t(r,[2,4]),{7:18,10:22,12:4,17:i,18:a,19:o,21:n},t(r,[2,6]),t(r,[2,7]),t(r,[2,11]),t(r,[2,12]),{20:[1,23]},t(r,[2,14]),{11:[1,24]},{16:25,23:[1,26]},{11:[2,18]},t(r,[2,5]),t(r,[2,13]),t(c,[2,9]),{14:27,24:s},{24:[2,17]},{11:[1,28]},t(c,[2,10])],defaultActions:{5:[2,15],7:[2,2],21:[2,18],26:[2,17]},parseError:function(t,e){if(!e.recoverable){var n=new Error(t);throw n.hash=e,n}this.trace(t)},parse:function(t){var e=this,n=[0],r=[],i=[null],a=[],o=this.table,s="",c=0,u=0,l=0,h=2,f=1,d=a.slice.call(arguments,1),p=Object.create(this.lexer),y={yy:{}};for(var g in this.yy)Object.prototype.hasOwnProperty.call(this.yy,g)&&(y.yy[g]=this.yy[g]);p.setInput(t,y.yy),y.yy.lexer=p,y.yy.parser=this,void 0===p.yylloc&&(p.yylloc={});var m=p.yylloc;a.push(m);var v=p.options&&p.options.ranges;function b(){var t;return"number"!=typeof(t=r.pop()||p.lex()||f)&&(t instanceof Array&&(t=(r=t).pop()),t=e.symbols_[t]||t),t}"function"==typeof y.yy.parseError?this.parseError=y.yy.parseError:this.parseError=Object.getPrototypeOf(this).parseError;for(var _,x,w,k,T,E,C,S,A,M={};;){if(w=n[n.length-1],this.defaultActions[w]?k=this.defaultActions[w]:(null==_&&(_=b()),k=o[w]&&o[w][_]),void 0===k||!k.length||!k[0]){var N="";for(E in A=[],o[w])this.terminals_[E]&&E>h&&A.push("'"+this.terminals_[E]+"'");N=p.showPosition?"Parse error on line "+(c+1)+":\n"+p.showPosition()+"\nExpecting "+A.join(", ")+", got '"+(this.terminals_[_]||_)+"'":"Parse error on line "+(c+1)+": Unexpected "+(_==f?"end of input":"'"+(this.terminals_[_]||_)+"'"),this.parseError(N,{text:p.match,token:this.terminals_[_]||_,line:p.yylineno,loc:m,expected:A})}if(k[0]instanceof Array&&k.length>1)throw new Error("Parse Error: multiple actions possible at state: "+w+", token: "+_);switch(k[0]){case 1:n.push(_),i.push(p.yytext),a.push(p.yylloc),n.push(k[1]),_=null,x?(_=x,x=null):(u=p.yyleng,s=p.yytext,c=p.yylineno,m=p.yylloc,l>0&&l--);break;case 2:if(C=this.productions_[k[1]][1],M.$=i[i.length-C],M._$={first_line:a[a.length-(C||1)].first_line,last_line:a[a.length-1].last_line,first_column:a[a.length-(C||1)].first_column,last_column:a[a.length-1].last_column},v&&(M._$.range=[a[a.length-(C||1)].range[0],a[a.length-1].range[1]]),void 0!==(T=this.performAction.apply(M,[s,u,c,y.yy,k[1],i,a].concat(d))))return T;C&&(n=n.slice(0,-1*C*2),i=i.slice(0,-1*C),a=a.slice(0,-1*C)),n.push(this.productions_[k[1]][0]),i.push(M.$),a.push(M._$),S=o[n[n.length-2]][n[n.length-1]],n.push(S);break;case 3:return!0}}return!0}},l={EOF:1,parseError:function(t,e){if(!this.yy.parser)throw new Error(t);this.yy.parser.parseError(t,e)},setInput:function(t,e){return this.yy=e||this.yy||{},this._input=t,this._more=this._backtrack=this.done=!1,this.yylineno=this.yyleng=0,this.yytext=this.matched=this.match="",this.conditionStack=["INITIAL"],this.yylloc={first_line:1,first_column:0,last_line:1,last_column:0},this.options.ranges&&(this.yylloc.range=[0,0]),this.offset=0,this},input:function(){var t=this._input[0];return this.yytext+=t,this.yyleng++,this.offset++,this.match+=t,this.matched+=t,t.match(/(?:\r\n?|\n).*/g)?(this.yylineno++,this.yylloc.last_line++):this.yylloc.last_column++,this.options.ranges&&this.yylloc.range[1]++,this._input=this._input.slice(1),t},unput:function(t){var e=t.length,n=t.split(/(?:\r\n?|\n)/g);this._input=t+this._input,this.yytext=this.yytext.substr(0,this.yytext.length-e),this.offset-=e;var r=this.match.split(/(?:\r\n?|\n)/g);this.match=this.match.substr(0,this.match.length-1),this.matched=this.matched.substr(0,this.matched.length-1),n.length-1&&(this.yylineno-=n.length-1);var i=this.yylloc.range;return this.yylloc={first_line:this.yylloc.first_line,last_line:this.yylineno+1,first_column:this.yylloc.first_column,last_column:n?(n.length===r.length?this.yylloc.first_column:0)+r[r.length-n.length].length-n[0].length:this.yylloc.first_column-e},this.options.ranges&&(this.yylloc.range=[i[0],i[0]+this.yyleng-e]),this.yyleng=this.yytext.length,this},more:function(){return this._more=!0,this},reject:function(){return this.options.backtrack_lexer?(this._backtrack=!0,this):this.parseError("Lexical error on line "+(this.yylineno+1)+". You can only invoke reject() in the lexer when the lexer is of the backtracking persuasion (options.backtrack_lexer = true).\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},less:function(t){this.unput(this.match.slice(t))},pastInput:function(){var t=this.matched.substr(0,this.matched.length-this.match.length);return(t.length>20?"...":"")+t.substr(-20).replace(/\n/g,"")},upcomingInput:function(){var t=this.match;return t.length<20&&(t+=this._input.substr(0,20-t.length)),(t.substr(0,20)+(t.length>20?"...":"")).replace(/\n/g,"")},showPosition:function(){var t=this.pastInput(),e=new Array(t.length+1).join("-");return t+this.upcomingInput()+"\n"+e+"^"},test_match:function(t,e){var n,r,i;if(this.options.backtrack_lexer&&(i={yylineno:this.yylineno,yylloc:{first_line:this.yylloc.first_line,last_line:this.last_line,first_column:this.yylloc.first_column,last_column:this.yylloc.last_column},yytext:this.yytext,match:this.match,matches:this.matches,matched:this.matched,yyleng:this.yyleng,offset:this.offset,_more:this._more,_input:this._input,yy:this.yy,conditionStack:this.conditionStack.slice(0),done:this.done},this.options.ranges&&(i.yylloc.range=this.yylloc.range.slice(0))),(r=t[0].match(/(?:\r\n?|\n).*/g))&&(this.yylineno+=r.length),this.yylloc={first_line:this.yylloc.last_line,last_line:this.yylineno+1,first_column:this.yylloc.last_column,last_column:r?r[r.length-1].length-r[r.length-1].match(/\r?\n?/)[0].length:this.yylloc.last_column+t[0].length},this.yytext+=t[0],this.match+=t[0],this.matches=t,this.yyleng=this.yytext.length,this.options.ranges&&(this.yylloc.range=[this.offset,this.offset+=this.yyleng]),this._more=!1,this._backtrack=!1,this._input=this._input.slice(t[0].length),this.matched+=t[0],n=this.performAction.call(this,this.yy,this,e,this.conditionStack[this.conditionStack.length-1]),this.done&&this._input&&(this.done=!1),n)return n;if(this._backtrack){for(var a in i)this[a]=i[a];return!1}return!1},next:function(){if(this.done)return this.EOF;var t,e,n,r;this._input||(this.done=!0),this._more||(this.yytext="",this.match="");for(var i=this._currentRules(),a=0;ae[0].length)){if(e=n,r=a,this.options.backtrack_lexer){if(!1!==(t=this.test_match(n,i[a])))return t;if(this._backtrack){e=!1;continue}return!1}if(!this.options.flex)break}return e?!1!==(t=this.test_match(e,i[r]))&&t:""===this._input?this.EOF:this.parseError("Lexical error on line "+(this.yylineno+1)+". Unrecognized text.\n"+this.showPosition(),{text:"",token:null,line:this.yylineno})},lex:function(){return this.next()||this.lex()},begin:function(t){this.conditionStack.push(t)},popState:function(){return this.conditionStack.length-1>0?this.conditionStack.pop():this.conditionStack[0]},_currentRules:function(){return this.conditionStack.length&&this.conditionStack[this.conditionStack.length-1]?this.conditions[this.conditionStack[this.conditionStack.length-1]].rules:this.conditions.INITIAL.rules},topState:function(t){return(t=this.conditionStack.length-1-Math.abs(t||0))>=0?this.conditionStack[t]:"INITIAL"},pushState:function(t){this.begin(t)},stateStackSize:function(){return this.conditionStack.length},options:{"case-insensitive":!0},performAction:function(t,e,n,r){switch(n){case 0:return this.begin("open_directive"),21;case 1:return this.begin("type_directive"),22;case 2:return this.popState(),this.begin("arg_directive"),15;case 3:return this.popState(),this.popState(),24;case 4:return 23;case 5:case 6:case 8:case 9:break;case 7:return 11;case 10:return 4;case 11:return 17;case 12:return 18;case 13:return 19;case 14:return 20;case 15:return 15;case 16:return 6;case 17:return"INVALID"}},rules:[/^(?:%%\{)/i,/^(?:((?:(?!\}%%)[^:.])*))/i,/^(?::)/i,/^(?:\}%%)/i,/^(?:((?:(?!\}%%).|\n)*))/i,/^(?:%(?!\{)[^\n]*)/i,/^(?:[^\}]%%[^\n]*)/i,/^(?:[\n]+)/i,/^(?:\s+)/i,/^(?:#[^\n]*)/i,/^(?:journey\b)/i,/^(?:title\s[^#\n;]+)/i,/^(?:section\s[^#:\n;]+)/i,/^(?:[^#:\n;]+)/i,/^(?::[^#\n;]+)/i,/^(?::)/i,/^(?:$)/i,/^(?:.)/i],conditions:{open_directive:{rules:[1],inclusive:!1},type_directive:{rules:[2,3],inclusive:!1},arg_directive:{rules:[3,4],inclusive:!1},INITIAL:{rules:[0,5,6,7,8,9,10,11,12,13,14,15,16,17],inclusive:!0}}};function h(){this.yy={}}return u.lexer=l,h.prototype=u,u.Parser=h,new h}();e.parser=r,e.Parser=r.Parser,e.parse=function(){return r.parse.apply(r,arguments)},e.main=function(t){t[1]||(console.log("Usage: "+t[0]+" FILE"),process.exit(1));var r=n(9143).readFileSync(n(6470).normalize(t[1]),"utf8");return e.parser.parse(r)},n.c[n.s]===t&&e.main(process.argv.slice(1))},9609:t=>{"use strict";var e=/^(%20|\s)*(javascript|data)/im,n=/[^\x20-\x7E]/gim,r=/^([^:]+):/gm,i=[".","/"];t.exports={sanitizeUrl:function(t){if(!t)return"about:blank";var a,o,s=t.replace(n,"").trim();return function(t){return i.indexOf(t[0])>-1}(s)?s:(o=s.match(r))?(a=o[0],e.test(a)?"about:blank":s):"about:blank"}}},3841:t=>{t.exports=function(t,e){return t.intersect(e)}},7458:(t,e,n)=>{"use strict";n.d(e,{default:()=>hC});var r=n(1941),i=n.n(r),a={debug:1,info:2,warn:3,error:4,fatal:5},o={debug:function(){},info:function(){},warn:function(){},error:function(){},fatal:function(){}},s=function(){var t=arguments.length>0&&void 0!==arguments[0]?arguments[0]:"fatal";isNaN(t)&&(t=t.toLowerCase(),void 0!==a[t]&&(t=a[t])),o.trace=function(){},o.debug=function(){},o.info=function(){},o.warn=function(){},o.error=function(){},o.fatal=function(){},t<=a.fatal&&(o.fatal=console.error?console.error.bind(console,c("FATAL"),"color: orange"):console.log.bind(console,"",c("FATAL"))),t<=a.error&&(o.error=console.error?console.error.bind(console,c("ERROR"),"color: orange"):console.log.bind(console,"",c("ERROR"))),t<=a.warn&&(o.warn=console.warn?console.warn.bind(console,c("WARN"),"color: orange"):console.log.bind(console,"",c("WARN"))),t<=a.info&&(o.info=console.info?console.info.bind(console,c("INFO"),"color: lightblue"):console.log.bind(console,"",c("INFO"))),t<=a.debug&&(o.debug=console.debug?console.debug.bind(console,c("DEBUG"),"color: lightgreen"):console.log.bind(console,"",c("DEBUG")))},c=function(t){var e=i()().format("ss.SSS");return"%c".concat(e," : ").concat(t," : ")};function u(t,e){let n;if(void 0===e)for(const e of t)null!=e&&(n=e)&&(n=e);else{let r=-1;for(let i of t)null!=(i=e(i,++r,t))&&(n=i)&&(n=i)}return n}function l(t,e){let n;if(void 0===e)for(const e of t)null!=e&&(n>e||void 0===n&&e>=e)&&(n=e);else{let r=-1;for(let i of t)null!=(i=e(i,++r,t))&&(n>i||void 0===n&&i>=i)&&(n=i)}return n}function h(t){return t}var f=1e-6;function d(t){return"translate("+t+",0)"}function p(t){return"translate(0,"+t+")"}function y(t){return e=>+t(e)}function g(t,e){return e=Math.max(0,t.bandwidth()-2*e)/2,t.round()&&(e=Math.round(e)),n=>+t(n)+e}function m(){return!this.__axis}function v(t,e){var n=[],r=null,i=null,a=6,o=6,s=3,c="undefined"!=typeof window&&window.devicePixelRatio>1?0:.5,u=1===t||4===t?-1:1,l=4===t||2===t?"x":"y",v=1===t||3===t?d:p;function b(d){var p=null==r?e.ticks?e.ticks.apply(e,n):e.domain():r,b=null==i?e.tickFormat?e.tickFormat.apply(e,n):h:i,_=Math.max(a,0)+s,x=e.range(),w=+x[0]+c,k=+x[x.length-1]+c,T=(e.bandwidth?g:y)(e.copy(),c),E=d.selection?d.selection():d,C=E.selectAll(".domain").data([null]),S=E.selectAll(".tick").data(p,e).order(),A=S.exit(),M=S.enter().append("g").attr("class","tick"),N=S.select("line"),D=S.select("text");C=C.merge(C.enter().insert("path",".tick").attr("class","domain").attr("stroke","currentColor")),S=S.merge(M),N=N.merge(M.append("line").attr("stroke","currentColor").attr(l+"2",u*a)),D=D.merge(M.append("text").attr("fill","currentColor").attr(l,u*_).attr("dy",1===t?"0em":3===t?"0.71em":"0.32em")),d!==E&&(C=C.transition(d),S=S.transition(d),N=N.transition(d),D=D.transition(d),A=A.transition(d).attr("opacity",f).attr("transform",(function(t){return isFinite(t=T(t))?v(t+c):this.getAttribute("transform")})),M.attr("opacity",f).attr("transform",(function(t){var e=this.parentNode.__axis;return v((e&&isFinite(e=e(t))?e:T(t))+c)}))),A.remove(),C.attr("d",4===t||2===t?o?"M"+u*o+","+w+"H"+c+"V"+k+"H"+u*o:"M"+c+","+w+"V"+k:o?"M"+w+","+u*o+"V"+c+"H"+k+"V"+u*o:"M"+w+","+c+"H"+k),S.attr("opacity",1).attr("transform",(function(t){return v(T(t)+c)})),N.attr(l+"2",u*a),D.attr(l,u*_).text(b),E.filter(m).attr("fill","none").attr("font-size",10).attr("font-family","sans-serif").attr("text-anchor",2===t?"start":4===t?"end":"middle"),E.each((function(){this.__axis=T}))}return b.scale=function(t){return arguments.length?(e=t,b):e},b.ticks=function(){return n=Array.from(arguments),b},b.tickArguments=function(t){return arguments.length?(n=null==t?[]:Array.from(t),b):n.slice()},b.tickValues=function(t){return arguments.length?(r=null==t?null:Array.from(t),b):r&&r.slice()},b.tickFormat=function(t){return arguments.length?(i=t,b):i},b.tickSize=function(t){return arguments.length?(a=o=+t,b):a},b.tickSizeInner=function(t){return arguments.length?(a=+t,b):a},b.tickSizeOuter=function(t){return arguments.length?(o=+t,b):o},b.tickPadding=function(t){return arguments.length?(s=+t,b):s},b.offset=function(t){return arguments.length?(c=+t,b):c},b}function b(){}function _(t){return null==t?b:function(){return this.querySelector(t)}}function x(t){return null==t?[]:Array.isArray(t)?t:Array.from(t)}function w(){return[]}function k(t){return null==t?w:function(){return this.querySelectorAll(t)}}function T(t){return function(){return this.matches(t)}}function E(t){return function(e){return e.matches(t)}}var C=Array.prototype.find;function S(){return this.firstElementChild}var A=Array.prototype.filter;function M(){return Array.from(this.children)}function N(t){return new Array(t.length)}function D(t,e){this.ownerDocument=t.ownerDocument,this.namespaceURI=t.namespaceURI,this._next=null,this._parent=t,this.__data__=e}function O(t){return function(){return t}}function B(t,e,n,r,i,a){for(var o,s=0,c=e.length,u=a.length;se?1:t>=e?0:NaN}D.prototype={constructor:D,appendChild:function(t){return this._parent.insertBefore(t,this._next)},insertBefore:function(t,e){return this._parent.insertBefore(t,e)},querySelector:function(t){return this._parent.querySelector(t)},querySelectorAll:function(t){return this._parent.querySelectorAll(t)}};var P="http://www.w3.org/1999/xhtml";const j={svg:"http://www.w3.org/2000/svg",xhtml:P,xlink:"http://www.w3.org/1999/xlink",xml:"http://www.w3.org/XML/1998/namespace",xmlns:"http://www.w3.org/2000/xmlns/"};function Y(t){var e=t+="",n=e.indexOf(":");return n>=0&&"xmlns"!==(e=t.slice(0,n))&&(t=t.slice(n+1)),j.hasOwnProperty(e)?{space:j[e],local:t}:t}function z(t){return function(){this.removeAttribute(t)}}function U(t){return function(){this.removeAttributeNS(t.space,t.local)}}function q(t,e){return function(){this.setAttribute(t,e)}}function H(t,e){return function(){this.setAttributeNS(t.space,t.local,e)}}function $(t,e){return function(){var n=e.apply(this,arguments);null==n?this.removeAttribute(t):this.setAttribute(t,n)}}function W(t,e){return function(){var n=e.apply(this,arguments);null==n?this.removeAttributeNS(t.space,t.local):this.setAttributeNS(t.space,t.local,n)}}function V(t){return t.ownerDocument&&t.ownerDocument.defaultView||t.document&&t||t.defaultView}function G(t){return function(){this.style.removeProperty(t)}}function X(t,e,n){return function(){this.style.setProperty(t,e,n)}}function Z(t,e,n){return function(){var r=e.apply(this,arguments);null==r?this.style.removeProperty(t):this.style.setProperty(t,r,n)}}function Q(t,e){return t.style.getPropertyValue(e)||V(t).getComputedStyle(t,null).getPropertyValue(e)}function K(t){return function(){delete this[t]}}function J(t,e){return function(){this[t]=e}}function tt(t,e){return function(){var n=e.apply(this,arguments);null==n?delete this[t]:this[t]=n}}function et(t){return t.trim().split(/^|\s+/)}function nt(t){return t.classList||new rt(t)}function rt(t){this._node=t,this._names=et(t.getAttribute("class")||"")}function it(t,e){for(var n=nt(t),r=-1,i=e.length;++r=0&&(e=t.slice(n+1),t=t.slice(0,n)),{type:t,name:e}}))}function Et(t){return function(){var e=this.__on;if(e){for(var n,r=0,i=-1,a=e.length;r=0&&(this._names.splice(e,1),this._node.setAttribute("class",this._names.join(" ")))},contains:function(t){return this._names.indexOf(t)>=0}};var Nt=[null];function Dt(t,e){this._groups=t,this._parents=e}function Ot(){return new Dt([[document.documentElement]],Nt)}Dt.prototype=Ot.prototype={constructor:Dt,select:function(t){"function"!=typeof t&&(t=_(t));for(var e=this._groups,n=e.length,r=new Array(n),i=0;i=x&&(x=_+1);!(b=g[x])&&++x=0;)(r=i[a])&&(o&&4^r.compareDocumentPosition(o)&&o.parentNode.insertBefore(r,o),o=r);return this},sort:function(t){function e(e,n){return e&&n?t(e.__data__,n.__data__):!e-!n}t||(t=F);for(var n=this._groups,r=n.length,i=new Array(r),a=0;a1?this.each((null==e?G:"function"==typeof e?Z:X)(t,e,null==n?"":n)):Q(this.node(),t)},property:function(t,e){return arguments.length>1?this.each((null==e?K:"function"==typeof e?tt:J)(t,e)):this.node()[t]},classed:function(t,e){var n=et(t+"");if(arguments.length<2){for(var r=nt(this.node()),i=-1,a=n.length;++i{}};function It(){for(var t,e=0,n=arguments.length,r={};e=0&&(n=t.slice(r+1),t=t.slice(0,r)),t&&!e.hasOwnProperty(t))throw new Error("unknown type: "+t);return{type:t,name:n}}))}function Pt(t,e){for(var n,r=0,i=t.length;r0)for(var n,r,i=new Array(n),a=0;a=0&&e._call.call(void 0,t),e=e._next;--qt}()}finally{qt=0,function(){for(var t,e,n=zt,r=1/0;n;)n._call?(r>n._time&&(r=n._time),t=n,n=n._next):(e=n._next,n._next=null,n=t?t._next=e:zt=e);Ut=t,re(r)}(),Vt=0}}function ne(){var t=Xt.now(),e=t-Wt;e>1e3&&(Gt-=e,Wt=t)}function re(t){qt||(Ht&&(Ht=clearTimeout(Ht)),t-Vt>24?(t<1/0&&(Ht=setTimeout(ee,t-Xt.now()-Gt)),$t&&($t=clearInterval($t))):($t||(Wt=Xt.now(),$t=setInterval(ne,1e3)),qt=1,Zt(ee)))}function ie(t,e,n){var r=new Jt;return e=null==e?0:+e,r.restart((n=>{r.stop(),t(n+e)}),e,n),r}Jt.prototype=te.prototype={constructor:Jt,restart:function(t,e,n){if("function"!=typeof t)throw new TypeError("callback is not a function");n=(null==n?Qt():+n)+(null==e?0:+e),this._next||Ut===this||(Ut?Ut._next=this:zt=this,Ut=this),this._call=t,this._time=n,re()},stop:function(){this._call&&(this._call=null,this._time=1/0,re())}};var ae=Yt("start","end","cancel","interrupt"),oe=[];function se(t,e,n,r,i,a){var o=t.__transition;if(o){if(n in o)return}else t.__transition={};!function(t,e,n){var r,i=t.__transition;function a(c){var u,l,h,f;if(1!==n.state)return s();for(u in i)if((f=i[u]).name===n.name){if(3===f.state)return ie(a);4===f.state?(f.state=6,f.timer.stop(),f.on.call("interrupt",t,t.__data__,f.index,f.group),delete i[u]):+u0)throw new Error("too late; already scheduled");return n}function ue(t,e){var n=le(t,e);if(n.state>3)throw new Error("too late; already running");return n}function le(t,e){var n=t.__transition;if(!n||!(n=n[e]))throw new Error("transition not found");return n}function he(t,e){return t=+t,e=+e,function(n){return t*(1-n)+e*n}}var fe,de=180/Math.PI,pe={translateX:0,translateY:0,rotate:0,skewX:0,scaleX:1,scaleY:1};function ye(t,e,n,r,i,a){var o,s,c;return(o=Math.sqrt(t*t+e*e))&&(t/=o,e/=o),(c=t*n+e*r)&&(n-=t*c,r-=e*c),(s=Math.sqrt(n*n+r*r))&&(n/=s,r/=s,c/=s),t*r180?e+=360:e-t>180&&(t+=360),a.push({i:n.push(i(n)+"rotate(",null,r)-2,x:he(t,e)})):e&&n.push(i(n)+"rotate("+e+r)}(a.rotate,o.rotate,s,c),function(t,e,n,a){t!==e?a.push({i:n.push(i(n)+"skewX(",null,r)-2,x:he(t,e)}):e&&n.push(i(n)+"skewX("+e+r)}(a.skewX,o.skewX,s,c),function(t,e,n,r,a,o){if(t!==n||e!==r){var s=a.push(i(a)+"scale(",null,",",null,")");o.push({i:s-4,x:he(t,n)},{i:s-2,x:he(e,r)})}else 1===n&&1===r||a.push(i(a)+"scale("+n+","+r+")")}(a.scaleX,a.scaleY,o.scaleX,o.scaleY,s,c),a=o=null,function(t){for(var e,n=-1,r=c.length;++n>8&15|e>>4&240,e>>4&15|240&e,(15&e)<<4|15&e,1):8===n?Ue(e>>24&255,e>>16&255,e>>8&255,(255&e)/255):4===n?Ue(e>>12&15|e>>8&240,e>>8&15|e>>4&240,e>>4&15|240&e,((15&e)<<4|15&e)/255):null):(e=De.exec(t))?new $e(e[1],e[2],e[3],1):(e=Oe.exec(t))?new $e(255*e[1]/100,255*e[2]/100,255*e[3]/100,1):(e=Be.exec(t))?Ue(e[1],e[2],e[3],e[4]):(e=Le.exec(t))?Ue(255*e[1]/100,255*e[2]/100,255*e[3]/100,e[4]):(e=Ie.exec(t))?Xe(e[1],e[2]/100,e[3]/100,1):(e=Re.exec(t))?Xe(e[1],e[2]/100,e[3]/100,e[4]):Fe.hasOwnProperty(t)?ze(Fe[t]):"transparent"===t?new $e(NaN,NaN,NaN,0):null}function ze(t){return new $e(t>>16&255,t>>8&255,255&t,1)}function Ue(t,e,n,r){return r<=0&&(t=e=n=NaN),new $e(t,e,n,r)}function qe(t){return t instanceof Te||(t=Ye(t)),t?new $e((t=t.rgb()).r,t.g,t.b,t.opacity):new $e}function He(t,e,n,r){return 1===arguments.length?qe(t):new $e(t,e,n,null==r?1:r)}function $e(t,e,n,r){this.r=+t,this.g=+e,this.b=+n,this.opacity=+r}function We(){return"#"+Ge(this.r)+Ge(this.g)+Ge(this.b)}function Ve(){var t=this.opacity;return(1===(t=isNaN(t)?1:Math.max(0,Math.min(1,t)))?"rgb(":"rgba(")+Math.max(0,Math.min(255,Math.round(this.r)||0))+", "+Math.max(0,Math.min(255,Math.round(this.g)||0))+", "+Math.max(0,Math.min(255,Math.round(this.b)||0))+(1===t?")":", "+t+")")}function Ge(t){return((t=Math.max(0,Math.min(255,Math.round(t)||0)))<16?"0":"")+t.toString(16)}function Xe(t,e,n,r){return r<=0?t=e=n=NaN:n<=0||n>=1?t=e=NaN:e<=0&&(t=NaN),new Qe(t,e,n,r)}function Ze(t){if(t instanceof Qe)return new Qe(t.h,t.s,t.l,t.opacity);if(t instanceof Te||(t=Ye(t)),!t)return new Qe;if(t instanceof Qe)return t;var e=(t=t.rgb()).r/255,n=t.g/255,r=t.b/255,i=Math.min(e,n,r),a=Math.max(e,n,r),o=NaN,s=a-i,c=(a+i)/2;return s?(o=e===a?(n-r)/s+6*(n0&&c<1?0:o,new Qe(o,s,c,t.opacity)}function Qe(t,e,n,r){this.h=+t,this.s=+e,this.l=+n,this.opacity=+r}function Ke(t,e,n){return 255*(t<60?e+(n-e)*t/60:t<180?n:t<240?e+(n-e)*(240-t)/60:e)}function Je(t,e,n,r,i){var a=t*t,o=a*t;return((1-3*t+3*a-o)*e+(4-6*a+3*o)*n+(1+3*t+3*a-3*o)*r+o*i)/6}we(Te,Ye,{copy:function(t){return Object.assign(new this.constructor,this,t)},displayable:function(){return this.rgb().displayable()},hex:Pe,formatHex:Pe,formatHsl:function(){return Ze(this).formatHsl()},formatRgb:je,toString:je}),we($e,He,ke(Te,{brighter:function(t){return t=null==t?Ce:Math.pow(Ce,t),new $e(this.r*t,this.g*t,this.b*t,this.opacity)},darker:function(t){return t=null==t?Ee:Math.pow(Ee,t),new $e(this.r*t,this.g*t,this.b*t,this.opacity)},rgb:function(){return this},displayable:function(){return-.5<=this.r&&this.r<255.5&&-.5<=this.g&&this.g<255.5&&-.5<=this.b&&this.b<255.5&&0<=this.opacity&&this.opacity<=1},hex:We,formatHex:We,formatRgb:Ve,toString:Ve})),we(Qe,(function(t,e,n,r){return 1===arguments.length?Ze(t):new Qe(t,e,n,null==r?1:r)}),ke(Te,{brighter:function(t){return t=null==t?Ce:Math.pow(Ce,t),new Qe(this.h,this.s,this.l*t,this.opacity)},darker:function(t){return t=null==t?Ee:Math.pow(Ee,t),new Qe(this.h,this.s,this.l*t,this.opacity)},rgb:function(){var t=this.h%360+360*(this.h<0),e=isNaN(t)||isNaN(this.s)?0:this.s,n=this.l,r=n+(n<.5?n:1-n)*e,i=2*n-r;return new $e(Ke(t>=240?t-240:t+120,i,r),Ke(t,i,r),Ke(t<120?t+240:t-120,i,r),this.opacity)},displayable:function(){return(0<=this.s&&this.s<=1||isNaN(this.s))&&0<=this.l&&this.l<=1&&0<=this.opacity&&this.opacity<=1},formatHsl:function(){var t=this.opacity;return(1===(t=isNaN(t)?1:Math.max(0,Math.min(1,t)))?"hsl(":"hsla(")+(this.h||0)+", "+100*(this.s||0)+"%, "+100*(this.l||0)+"%"+(1===t?")":", "+t+")")}}));const tn=t=>()=>t;function en(t,e){var n=e-t;return n?function(t,e){return function(n){return t+n*e}}(t,n):tn(isNaN(t)?e:t)}const nn=function t(e){var n=function(t){return 1==(t=+t)?en:function(e,n){return n-e?function(t,e,n){return t=Math.pow(t,n),e=Math.pow(e,n)-t,n=1/n,function(r){return Math.pow(t+r*e,n)}}(e,n,t):tn(isNaN(e)?n:e)}}(e);function r(t,e){var r=n((t=He(t)).r,(e=He(e)).r),i=n(t.g,e.g),a=n(t.b,e.b),o=en(t.opacity,e.opacity);return function(e){return t.r=r(e),t.g=i(e),t.b=a(e),t.opacity=o(e),t+""}}return r.gamma=t,r}(1);function rn(t){return function(e){var n,r,i=e.length,a=new Array(i),o=new Array(i),s=new Array(i);for(n=0;n=1?(n=1,e-1):Math.floor(n*e),i=t[r],a=t[r+1],o=r>0?t[r-1]:2*i-a,s=ra&&(i=e.slice(a,i),s[o]?s[o]+=i:s[++o]=i),(n=n[0])===(r=r[0])?s[o]?s[o]+=r:s[++o]=r:(s[++o]=null,c.push({i:o,x:he(n,r)})),a=on.lastIndex;return a=0&&(t=t.slice(0,e)),!t||"start"===t}))}(e)?ce:ue;return function(){var o=a(this,t),s=o.on;s!==r&&(i=(r=s).copy()).on(e,n),o.on=i}}var En=Bt.prototype.constructor;function Cn(t){return function(){this.style.removeProperty(t)}}function Sn(t,e,n){return function(r){this.style.setProperty(t,e.call(this,r),n)}}function An(t,e,n){var r,i;function a(){var a=e.apply(this,arguments);return a!==i&&(r=(i=a)&&Sn(t,a,n)),r}return a._value=e,a}function Mn(t){return function(e){this.textContent=t.call(this,e)}}function Nn(t){var e,n;function r(){var r=t.apply(this,arguments);return r!==n&&(e=(n=r)&&Mn(r)),e}return r._value=t,r}var Dn=0;function On(t,e,n,r){this._groups=t,this._parents=e,this._name=n,this._id=r}function Bn(){return++Dn}var Ln=Bt.prototype;On.prototype=function(t){return Bt().transition(t)}.prototype={constructor:On,select:function(t){var e=this._name,n=this._id;"function"!=typeof t&&(t=_(t));for(var r=this._groups,i=r.length,a=new Array(i),o=0;o2&&n.state<5,n.state=6,n.timer.stop(),n.on.call(r?"interrupt":"cancel",t,t.__data__,n.index,n.group),delete a[i]):o=!1;o&&delete t.__transition}}(this,t)}))},Bt.prototype.transition=function(t){var e,n;t instanceof On?(e=t._id,t=t._name):(e=Bn(),(n=In).time=Qt(),t=null==t?null:t+"");for(var r=this._groups,i=r.length,a=0;a>8&15|e>>4&240,e>>4&15|240&e,(15&e)<<4|15&e,1):8===n?sr(e>>24&255,e>>16&255,e>>8&255,(255&e)/255):4===n?sr(e>>12&15|e>>8&240,e>>8&15|e>>4&240,e>>4&15|240&e,((15&e)<<4|15&e)/255):null):(e=Zn.exec(t))?new lr(e[1],e[2],e[3],1):(e=Qn.exec(t))?new lr(255*e[1]/100,255*e[2]/100,255*e[3]/100,1):(e=Kn.exec(t))?sr(e[1],e[2],e[3],e[4]):(e=Jn.exec(t))?sr(255*e[1]/100,255*e[2]/100,255*e[3]/100,e[4]):(e=tr.exec(t))?pr(e[1],e[2]/100,e[3]/100,1):(e=er.exec(t))?pr(e[1],e[2]/100,e[3]/100,e[4]):nr.hasOwnProperty(t)?or(nr[t]):"transparent"===t?new lr(NaN,NaN,NaN,0):null}function or(t){return new lr(t>>16&255,t>>8&255,255&t,1)}function sr(t,e,n,r){return r<=0&&(t=e=n=NaN),new lr(t,e,n,r)}function cr(t){return t instanceof qn||(t=ar(t)),t?new lr((t=t.rgb()).r,t.g,t.b,t.opacity):new lr}function ur(t,e,n,r){return 1===arguments.length?cr(t):new lr(t,e,n,null==r?1:r)}function lr(t,e,n,r){this.r=+t,this.g=+e,this.b=+n,this.opacity=+r}function hr(){return"#"+dr(this.r)+dr(this.g)+dr(this.b)}function fr(){var t=this.opacity;return(1===(t=isNaN(t)?1:Math.max(0,Math.min(1,t)))?"rgb(":"rgba(")+Math.max(0,Math.min(255,Math.round(this.r)||0))+", "+Math.max(0,Math.min(255,Math.round(this.g)||0))+", "+Math.max(0,Math.min(255,Math.round(this.b)||0))+(1===t?")":", "+t+")")}function dr(t){return((t=Math.max(0,Math.min(255,Math.round(t)||0)))<16?"0":"")+t.toString(16)}function pr(t,e,n,r){return r<=0?t=e=n=NaN:n<=0||n>=1?t=e=NaN:e<=0&&(t=NaN),new gr(t,e,n,r)}function yr(t){if(t instanceof gr)return new gr(t.h,t.s,t.l,t.opacity);if(t instanceof qn||(t=ar(t)),!t)return new gr;if(t instanceof gr)return t;var e=(t=t.rgb()).r/255,n=t.g/255,r=t.b/255,i=Math.min(e,n,r),a=Math.max(e,n,r),o=NaN,s=a-i,c=(a+i)/2;return s?(o=e===a?(n-r)/s+6*(n0&&c<1?0:o,new gr(o,s,c,t.opacity)}function gr(t,e,n,r){this.h=+t,this.s=+e,this.l=+n,this.opacity=+r}function mr(t,e,n){return 255*(t<60?e+(n-e)*t/60:t<180?n:t<240?e+(n-e)*(240-t)/60:e)}zn(qn,ar,{copy:function(t){return Object.assign(new this.constructor,this,t)},displayable:function(){return this.rgb().displayable()},hex:rr,formatHex:rr,formatHsl:function(){return yr(this).formatHsl()},formatRgb:ir,toString:ir}),zn(lr,ur,Un(qn,{brighter:function(t){return t=null==t?$n:Math.pow($n,t),new lr(this.r*t,this.g*t,this.b*t,this.opacity)},darker:function(t){return t=null==t?Hn:Math.pow(Hn,t),new lr(this.r*t,this.g*t,this.b*t,this.opacity)},rgb:function(){return this},displayable:function(){return-.5<=this.r&&this.r<255.5&&-.5<=this.g&&this.g<255.5&&-.5<=this.b&&this.b<255.5&&0<=this.opacity&&this.opacity<=1},hex:hr,formatHex:hr,formatRgb:fr,toString:fr})),zn(gr,(function(t,e,n,r){return 1===arguments.length?yr(t):new gr(t,e,n,null==r?1:r)}),Un(qn,{brighter:function(t){return t=null==t?$n:Math.pow($n,t),new gr(this.h,this.s,this.l*t,this.opacity)},darker:function(t){return t=null==t?Hn:Math.pow(Hn,t),new gr(this.h,this.s,this.l*t,this.opacity)},rgb:function(){var t=this.h%360+360*(this.h<0),e=isNaN(t)||isNaN(this.s)?0:this.s,n=this.l,r=n+(n<.5?n:1-n)*e,i=2*n-r;return new lr(mr(t>=240?t-240:t+120,i,r),mr(t,i,r),mr(t<120?t+240:t-120,i,r),this.opacity)},displayable:function(){return(0<=this.s&&this.s<=1||isNaN(this.s))&&0<=this.l&&this.l<=1&&0<=this.opacity&&this.opacity<=1},formatHsl:function(){var t=this.opacity;return(1===(t=isNaN(t)?1:Math.max(0,Math.min(1,t)))?"hsl(":"hsla(")+(this.h||0)+", "+100*(this.s||0)+"%, "+100*(this.l||0)+"%"+(1===t?")":", "+t+")")}}));const vr=Math.PI/180,br=180/Math.PI,_r=.96422,xr=.82521,wr=4/29,kr=6/29,Tr=3*kr*kr;function Er(t){if(t instanceof Cr)return new Cr(t.l,t.a,t.b,t.opacity);if(t instanceof Br)return Lr(t);t instanceof lr||(t=cr(t));var e,n,r=Nr(t.r),i=Nr(t.g),a=Nr(t.b),o=Sr((.2225045*r+.7168786*i+.0606169*a)/1);return r===i&&i===a?e=n=o:(e=Sr((.4360747*r+.3850649*i+.1430804*a)/_r),n=Sr((.0139322*r+.0971045*i+.7141733*a)/xr)),new Cr(116*o-16,500*(e-o),200*(o-n),t.opacity)}function Cr(t,e,n,r){this.l=+t,this.a=+e,this.b=+n,this.opacity=+r}function Sr(t){return t>.008856451679035631?Math.pow(t,1/3):t/Tr+wr}function Ar(t){return t>kr?t*t*t:Tr*(t-wr)}function Mr(t){return 255*(t<=.0031308?12.92*t:1.055*Math.pow(t,1/2.4)-.055)}function Nr(t){return(t/=255)<=.04045?t/12.92:Math.pow((t+.055)/1.055,2.4)}function Dr(t){if(t instanceof Br)return new Br(t.h,t.c,t.l,t.opacity);if(t instanceof Cr||(t=Er(t)),0===t.a&&0===t.b)return new Br(NaN,0()=>t;function Rr(t,e){return function(n){return t+n*e}}function Fr(t,e){var n=e-t;return n?Rr(t,n):Ir(isNaN(t)?e:t)}function Pr(t){return function(e,n){var r=t((e=Or(e)).h,(n=Or(n)).h),i=Fr(e.c,n.c),a=Fr(e.l,n.l),o=Fr(e.opacity,n.opacity);return function(t){return e.h=r(t),e.c=i(t),e.l=a(t),e.opacity=o(t),e+""}}}const jr=Pr((function(t,e){var n=e-t;return n?Rr(t,n>180||n<-180?n-360*Math.round(n/360):n):Ir(isNaN(t)?e:t)}));Pr(Fr);var Yr=Math.sqrt(50),zr=Math.sqrt(10),Ur=Math.sqrt(2);function qr(t,e,n){var r=(e-t)/Math.max(0,n),i=Math.floor(Math.log(r)/Math.LN10),a=r/Math.pow(10,i);return i>=0?(a>=Yr?10:a>=zr?5:a>=Ur?2:1)*Math.pow(10,i):-Math.pow(10,-i)/(a>=Yr?10:a>=zr?5:a>=Ur?2:1)}function Hr(t,e,n){var r=Math.abs(e-t)/Math.max(0,n),i=Math.pow(10,Math.floor(Math.log(r)/Math.LN10)),a=r/i;return a>=Yr?i*=10:a>=zr?i*=5:a>=Ur&&(i*=2),ee?1:t>=e?0:NaN}function Wr(t){let e=t,n=t,r=t;function i(t,e,i=0,a=t.length){if(i>>1;r(t[n],e)<0?i=n+1:a=n}while(it(e)-n,n=$r,r=(e,n)=>$r(t(e),n)),{left:i,center:function(t,n,r=0,a=t.length){const o=i(t,n,r,a-1);return o>r&&e(t[o-1],n)>-e(t[o],n)?o-1:o},right:function(t,e,i=0,a=t.length){if(i>>1;r(t[n],e)<=0?i=n+1:a=n}while(i>8&15|e>>4&240,e>>4&15|240&e,(15&e)<<4|15&e,1):8===n?gi(e>>24&255,e>>16&255,e>>8&255,(255&e)/255):4===n?gi(e>>12&15|e>>8&240,e>>8&15|e>>4&240,e>>4&15|240&e,((15&e)<<4|15&e)/255):null):(e=ai.exec(t))?new bi(e[1],e[2],e[3],1):(e=oi.exec(t))?new bi(255*e[1]/100,255*e[2]/100,255*e[3]/100,1):(e=si.exec(t))?gi(e[1],e[2],e[3],e[4]):(e=ci.exec(t))?gi(255*e[1]/100,255*e[2]/100,255*e[3]/100,e[4]):(e=ui.exec(t))?ki(e[1],e[2]/100,e[3]/100,1):(e=li.exec(t))?ki(e[1],e[2]/100,e[3]/100,e[4]):hi.hasOwnProperty(t)?yi(hi[t]):"transparent"===t?new bi(NaN,NaN,NaN,0):null}function yi(t){return new bi(t>>16&255,t>>8&255,255&t,1)}function gi(t,e,n,r){return r<=0&&(t=e=n=NaN),new bi(t,e,n,r)}function mi(t){return t instanceof Kr||(t=pi(t)),t?new bi((t=t.rgb()).r,t.g,t.b,t.opacity):new bi}function vi(t,e,n,r){return 1===arguments.length?mi(t):new bi(t,e,n,null==r?1:r)}function bi(t,e,n,r){this.r=+t,this.g=+e,this.b=+n,this.opacity=+r}function _i(){return"#"+wi(this.r)+wi(this.g)+wi(this.b)}function xi(){var t=this.opacity;return(1===(t=isNaN(t)?1:Math.max(0,Math.min(1,t)))?"rgb(":"rgba(")+Math.max(0,Math.min(255,Math.round(this.r)||0))+", "+Math.max(0,Math.min(255,Math.round(this.g)||0))+", "+Math.max(0,Math.min(255,Math.round(this.b)||0))+(1===t?")":", "+t+")")}function wi(t){return((t=Math.max(0,Math.min(255,Math.round(t)||0)))<16?"0":"")+t.toString(16)}function ki(t,e,n,r){return r<=0?t=e=n=NaN:n<=0||n>=1?t=e=NaN:e<=0&&(t=NaN),new Ei(t,e,n,r)}function Ti(t){if(t instanceof Ei)return new Ei(t.h,t.s,t.l,t.opacity);if(t instanceof Kr||(t=pi(t)),!t)return new Ei;if(t instanceof Ei)return t;var e=(t=t.rgb()).r/255,n=t.g/255,r=t.b/255,i=Math.min(e,n,r),a=Math.max(e,n,r),o=NaN,s=a-i,c=(a+i)/2;return s?(o=e===a?(n-r)/s+6*(n0&&c<1?0:o,new Ei(o,s,c,t.opacity)}function Ei(t,e,n,r){this.h=+t,this.s=+e,this.l=+n,this.opacity=+r}function Ci(t,e,n){return 255*(t<60?e+(n-e)*t/60:t<180?n:t<240?e+(n-e)*(240-t)/60:e)}function Si(t,e,n,r,i){var a=t*t,o=a*t;return((1-3*t+3*a-o)*e+(4-6*a+3*o)*n+(1+3*t+3*a-3*o)*r+o*i)/6}Zr(Kr,pi,{copy:function(t){return Object.assign(new this.constructor,this,t)},displayable:function(){return this.rgb().displayable()},hex:fi,formatHex:fi,formatHsl:function(){return Ti(this).formatHsl()},formatRgb:di,toString:di}),Zr(bi,vi,Qr(Kr,{brighter:function(t){return t=null==t?ti:Math.pow(ti,t),new bi(this.r*t,this.g*t,this.b*t,this.opacity)},darker:function(t){return t=null==t?Jr:Math.pow(Jr,t),new bi(this.r*t,this.g*t,this.b*t,this.opacity)},rgb:function(){return this},displayable:function(){return-.5<=this.r&&this.r<255.5&&-.5<=this.g&&this.g<255.5&&-.5<=this.b&&this.b<255.5&&0<=this.opacity&&this.opacity<=1},hex:_i,formatHex:_i,formatRgb:xi,toString:xi})),Zr(Ei,(function(t,e,n,r){return 1===arguments.length?Ti(t):new Ei(t,e,n,null==r?1:r)}),Qr(Kr,{brighter:function(t){return t=null==t?ti:Math.pow(ti,t),new Ei(this.h,this.s,this.l*t,this.opacity)},darker:function(t){return t=null==t?Jr:Math.pow(Jr,t),new Ei(this.h,this.s,this.l*t,this.opacity)},rgb:function(){var t=this.h%360+360*(this.h<0),e=isNaN(t)||isNaN(this.s)?0:this.s,n=this.l,r=n+(n<.5?n:1-n)*e,i=2*n-r;return new bi(Ci(t>=240?t-240:t+120,i,r),Ci(t,i,r),Ci(t<120?t+240:t-120,i,r),this.opacity)},displayable:function(){return(0<=this.s&&this.s<=1||isNaN(this.s))&&0<=this.l&&this.l<=1&&0<=this.opacity&&this.opacity<=1},formatHsl:function(){var t=this.opacity;return(1===(t=isNaN(t)?1:Math.max(0,Math.min(1,t)))?"hsl(":"hsla(")+(this.h||0)+", "+100*(this.s||0)+"%, "+100*(this.l||0)+"%"+(1===t?")":", "+t+")")}}));const Ai=t=>()=>t;function Mi(t,e){var n=e-t;return n?function(t,e){return function(n){return t+n*e}}(t,n):Ai(isNaN(t)?e:t)}const Ni=function t(e){var n=function(t){return 1==(t=+t)?Mi:function(e,n){return n-e?function(t,e,n){return t=Math.pow(t,n),e=Math.pow(e,n)-t,n=1/n,function(r){return Math.pow(t+r*e,n)}}(e,n,t):Ai(isNaN(e)?n:e)}}(e);function r(t,e){var r=n((t=vi(t)).r,(e=vi(e)).r),i=n(t.g,e.g),a=n(t.b,e.b),o=Mi(t.opacity,e.opacity);return function(e){return t.r=r(e),t.g=i(e),t.b=a(e),t.opacity=o(e),t+""}}return r.gamma=t,r}(1);function Di(t){return function(e){var n,r,i=e.length,a=new Array(i),o=new Array(i),s=new Array(i);for(n=0;n=1?(n=1,e-1):Math.floor(n*e),i=t[r],a=t[r+1],o=r>0?t[r-1]:2*i-a,s=ra&&(i=e.slice(a,i),s[o]?s[o]+=i:s[++o]=i),(n=n[0])===(r=r[0])?s[o]?s[o]+=r:s[++o]=r:(s[++o]=null,c.push({i:o,x:Li(n,r)})),a=Fi.lastIndex;return ae&&(n=t,t=e,e=n),u=function(n){return Math.max(t,Math.min(e,n))}),r=c>2?Vi:Wi,i=a=null,h}function h(e){return null==e||isNaN(e=+e)?n:(i||(i=r(o.map(t),s,c)))(t(u(e)))}return h.invert=function(n){return u(e((a||(a=r(s,o.map(t),Li)))(n)))},h.domain=function(t){return arguments.length?(o=Array.from(t,Ui),l()):o.slice()},h.range=function(t){return arguments.length?(s=Array.from(t),l()):s.slice()},h.rangeRound=function(t){return s=Array.from(t),c=zi,l()},h.clamp=function(t){return arguments.length?(u=!!t||Hi,l()):u!==Hi},h.interpolate=function(t){return arguments.length?(c=t,l()):c},h.unknown=function(t){return arguments.length?(n=t,h):n},function(n,r){return t=n,e=r,l()}}()(Hi,Hi)}function Zi(t,e){switch(arguments.length){case 0:break;case 1:this.range(t);break;default:this.range(e).domain(t)}return this}var Qi,Ki=/^(?:(.)?([<>=^]))?([+\-( ])?([$#])?(0)?(\d+)?(,)?(\.\d+)?(~)?([a-z%])?$/i;function Ji(t){if(!(e=Ki.exec(t)))throw new Error("invalid format: "+t);var e;return new ta({fill:e[1],align:e[2],sign:e[3],symbol:e[4],zero:e[5],width:e[6],comma:e[7],precision:e[8]&&e[8].slice(1),trim:e[9],type:e[10]})}function ta(t){this.fill=void 0===t.fill?" ":t.fill+"",this.align=void 0===t.align?">":t.align+"",this.sign=void 0===t.sign?"-":t.sign+"",this.symbol=void 0===t.symbol?"":t.symbol+"",this.zero=!!t.zero,this.width=void 0===t.width?void 0:+t.width,this.comma=!!t.comma,this.precision=void 0===t.precision?void 0:+t.precision,this.trim=!!t.trim,this.type=void 0===t.type?"":t.type+""}function ea(t,e){if((n=(t=e?t.toExponential(e-1):t.toExponential()).indexOf("e"))<0)return null;var n,r=t.slice(0,n);return[r.length>1?r[0]+r.slice(2):r,+t.slice(n+1)]}function na(t){return(t=ea(Math.abs(t)))?t[1]:NaN}function ra(t,e){var n=ea(t,e);if(!n)return t+"";var r=n[0],i=n[1];return i<0?"0."+new Array(-i).join("0")+r:r.length>i+1?r.slice(0,i+1)+"."+r.slice(i+1):r+new Array(i-r.length+2).join("0")}Ji.prototype=ta.prototype,ta.prototype.toString=function(){return this.fill+this.align+this.sign+this.symbol+(this.zero?"0":"")+(void 0===this.width?"":Math.max(1,0|this.width))+(this.comma?",":"")+(void 0===this.precision?"":"."+Math.max(0,0|this.precision))+(this.trim?"~":"")+this.type};const ia={"%":(t,e)=>(100*t).toFixed(e),b:t=>Math.round(t).toString(2),c:t=>t+"",d:function(t){return Math.abs(t=Math.round(t))>=1e21?t.toLocaleString("en").replace(/,/g,""):t.toString(10)},e:(t,e)=>t.toExponential(e),f:(t,e)=>t.toFixed(e),g:(t,e)=>t.toPrecision(e),o:t=>Math.round(t).toString(8),p:(t,e)=>ra(100*t,e),r:ra,s:function(t,e){var n=ea(t,e);if(!n)return t+"";var r=n[0],i=n[1],a=i-(Qi=3*Math.max(-8,Math.min(8,Math.floor(i/3))))+1,o=r.length;return a===o?r:a>o?r+new Array(a-o+1).join("0"):a>0?r.slice(0,a)+"."+r.slice(a):"0."+new Array(1-a).join("0")+ea(t,Math.max(0,e+a-1))[0]},X:t=>Math.round(t).toString(16).toUpperCase(),x:t=>Math.round(t).toString(16)};function aa(t){return t}var oa,sa,ca,ua=Array.prototype.map,la=["y","z","a","f","p","n","µ","m","","k","M","G","T","P","E","Z","Y"];function ha(t){var e=t.domain;return t.ticks=function(t){var n=e();return function(t,e,n){var r,i,a,o,s=-1;if(n=+n,(t=+t)==(e=+e)&&n>0)return[t];if((r=e0){let n=Math.round(t/o),r=Math.round(e/o);for(n*oe&&--r,a=new Array(i=r-n+1);++se&&--r,a=new Array(i=r-n+1);++s0;){if((i=qr(c,u,n))===r)return a[o]=c,a[s]=u,e(a);if(i>0)c=Math.floor(c/i)*i,u=Math.ceil(u/i)*i;else{if(!(i<0))break;c=Math.ceil(c*i)/i,u=Math.floor(u*i)/i}r=i}return t},t}function fa(){var t=Xi();return t.copy=function(){return Gi(t,fa())},Zi.apply(t,arguments),ha(t)}oa=function(t){var e,n,r=void 0===t.grouping||void 0===t.thousands?aa:(e=ua.call(t.grouping,Number),n=t.thousands+"",function(t,r){for(var i=t.length,a=[],o=0,s=e[0],c=0;i>0&&s>0&&(c+s+1>r&&(s=Math.max(1,r-c)),a.push(t.substring(i-=s,i+s)),!((c+=s+1)>r));)s=e[o=(o+1)%e.length];return a.reverse().join(n)}),i=void 0===t.currency?"":t.currency[0]+"",a=void 0===t.currency?"":t.currency[1]+"",o=void 0===t.decimal?".":t.decimal+"",s=void 0===t.numerals?aa:function(t){return function(e){return e.replace(/[0-9]/g,(function(e){return t[+e]}))}}(ua.call(t.numerals,String)),c=void 0===t.percent?"%":t.percent+"",u=void 0===t.minus?"−":t.minus+"",l=void 0===t.nan?"NaN":t.nan+"";function h(t){var e=(t=Ji(t)).fill,n=t.align,h=t.sign,f=t.symbol,d=t.zero,p=t.width,y=t.comma,g=t.precision,m=t.trim,v=t.type;"n"===v?(y=!0,v="g"):ia[v]||(void 0===g&&(g=12),m=!0,v="g"),(d||"0"===e&&"="===n)&&(d=!0,e="0",n="=");var b="$"===f?i:"#"===f&&/[boxX]/.test(v)?"0"+v.toLowerCase():"",_="$"===f?a:/[%p]/.test(v)?c:"",x=ia[v],w=/[defgprs%]/.test(v);function k(t){var i,a,c,f=b,k=_;if("c"===v)k=x(t)+k,t="";else{var T=(t=+t)<0||1/t<0;if(t=isNaN(t)?l:x(Math.abs(t),g),m&&(t=function(t){t:for(var e,n=t.length,r=1,i=-1;r0&&(i=0)}return i>0?t.slice(0,i)+t.slice(e+1):t}(t)),T&&0==+t&&"+"!==h&&(T=!1),f=(T?"("===h?h:u:"-"===h||"("===h?"":h)+f,k=("s"===v?la[8+Qi/3]:"")+k+(T&&"("===h?")":""),w)for(i=-1,a=t.length;++i(c=t.charCodeAt(i))||c>57){k=(46===c?o+t.slice(i+1):t.slice(i))+k,t=t.slice(0,i);break}}y&&!d&&(t=r(t,1/0));var E=f.length+t.length+k.length,C=E>1)+f+t+k+C.slice(E);break;default:t=C+f+t+k}return s(t)}return g=void 0===g?6:/[gprs]/.test(v)?Math.max(1,Math.min(21,g)):Math.max(0,Math.min(20,g)),k.toString=function(){return t+""},k}return{format:h,formatPrefix:function(t,e){var n=h(((t=Ji(t)).type="f",t)),r=3*Math.max(-8,Math.min(8,Math.floor(na(e)/3))),i=Math.pow(10,-r),a=la[8+r/3];return function(t){return n(i*t)+a}}}}({thousands:",",grouping:[3],currency:["$",""]}),sa=oa.format,ca=oa.formatPrefix;class da extends Map{constructor(t,e=ya){if(super(),Object.defineProperties(this,{_intern:{value:new Map},_key:{value:e}}),null!=t)for(const[e,n]of t)this.set(e,n)}get(t){return super.get(pa(this,t))}has(t){return super.has(pa(this,t))}set(t,e){return super.set(function({_intern:t,_key:e},n){const r=e(n);return t.has(r)?t.get(r):(t.set(r,n),n)}(this,t),e)}delete(t){return super.delete(function({_intern:t,_key:e},n){const r=e(n);return t.has(r)&&(n=t.get(r),t.delete(r)),n}(this,t))}}function pa({_intern:t,_key:e},n){const r=e(n);return t.has(r)?t.get(r):n}function ya(t){return null!==t&&"object"==typeof t?t.valueOf():t}Set;const ga=Symbol("implicit");function ma(){var t=new da,e=[],n=[],r=ga;function i(i){let a=t.get(i);if(void 0===a){if(r!==ga)return r;t.set(i,a=e.push(i)-1)}return n[a%n.length]}return i.domain=function(n){if(!arguments.length)return e.slice();e=[],t=new da;for(const r of n)t.has(r)||t.set(r,e.push(r)-1);return i},i.range=function(t){return arguments.length?(n=Array.from(t),i):n.slice()},i.unknown=function(t){return arguments.length?(r=t,i):r},i.copy=function(){return ma(e,n).unknown(r)},Zi.apply(i,arguments),i}const va=1e3,ba=6e4,_a=36e5,xa=864e5,wa=6048e5,ka=31536e6;var Ta=new Date,Ea=new Date;function Ca(t,e,n,r){function i(e){return t(e=0===arguments.length?new Date:new Date(+e)),e}return i.floor=function(e){return t(e=new Date(+e)),e},i.ceil=function(n){return t(n=new Date(n-1)),e(n,1),t(n),n},i.round=function(t){var e=i(t),n=i.ceil(t);return t-e0))return s;do{s.push(o=new Date(+n)),e(n,a),t(n)}while(o=e)for(;t(e),!n(e);)e.setTime(e-1)}),(function(t,r){if(t>=t)if(r<0)for(;++r<=0;)for(;e(t,-1),!n(t););else for(;--r>=0;)for(;e(t,1),!n(t););}))},n&&(i.count=function(e,r){return Ta.setTime(+e),Ea.setTime(+r),t(Ta),t(Ea),Math.floor(n(Ta,Ea))},i.every=function(t){return t=Math.floor(t),isFinite(t)&&t>0?t>1?i.filter(r?function(e){return r(e)%t==0}:function(e){return i.count(0,e)%t==0}):i:null}),i}var Sa=Ca((function(){}),(function(t,e){t.setTime(+t+e)}),(function(t,e){return e-t}));Sa.every=function(t){return t=Math.floor(t),isFinite(t)&&t>0?t>1?Ca((function(e){e.setTime(Math.floor(e/t)*t)}),(function(e,n){e.setTime(+e+n*t)}),(function(e,n){return(n-e)/t})):Sa:null};const Aa=Sa;Sa.range;var Ma=Ca((function(t){t.setTime(t-t.getMilliseconds())}),(function(t,e){t.setTime(+t+e*va)}),(function(t,e){return(e-t)/va}),(function(t){return t.getUTCSeconds()}));const Na=Ma;Ma.range;var Da=Ca((function(t){t.setTime(t-t.getMilliseconds()-t.getSeconds()*va)}),(function(t,e){t.setTime(+t+e*ba)}),(function(t,e){return(e-t)/ba}),(function(t){return t.getMinutes()}));const Oa=Da;Da.range;var Ba=Ca((function(t){t.setTime(t-t.getMilliseconds()-t.getSeconds()*va-t.getMinutes()*ba)}),(function(t,e){t.setTime(+t+e*_a)}),(function(t,e){return(e-t)/_a}),(function(t){return t.getHours()}));const La=Ba;Ba.range;var Ia=Ca((t=>t.setHours(0,0,0,0)),((t,e)=>t.setDate(t.getDate()+e)),((t,e)=>(e-t-(e.getTimezoneOffset()-t.getTimezoneOffset())*ba)/xa),(t=>t.getDate()-1));const Ra=Ia;function Fa(t){return Ca((function(e){e.setDate(e.getDate()-(e.getDay()+7-t)%7),e.setHours(0,0,0,0)}),(function(t,e){t.setDate(t.getDate()+7*e)}),(function(t,e){return(e-t-(e.getTimezoneOffset()-t.getTimezoneOffset())*ba)/wa}))}Ia.range;var Pa=Fa(0),ja=Fa(1),Ya=Fa(2),za=Fa(3),Ua=Fa(4),qa=Fa(5),Ha=Fa(6),$a=(Pa.range,ja.range,Ya.range,za.range,Ua.range,qa.range,Ha.range,Ca((function(t){t.setDate(1),t.setHours(0,0,0,0)}),(function(t,e){t.setMonth(t.getMonth()+e)}),(function(t,e){return e.getMonth()-t.getMonth()+12*(e.getFullYear()-t.getFullYear())}),(function(t){return t.getMonth()})));const Wa=$a;$a.range;var Va=Ca((function(t){t.setMonth(0,1),t.setHours(0,0,0,0)}),(function(t,e){t.setFullYear(t.getFullYear()+e)}),(function(t,e){return e.getFullYear()-t.getFullYear()}),(function(t){return t.getFullYear()}));Va.every=function(t){return isFinite(t=Math.floor(t))&&t>0?Ca((function(e){e.setFullYear(Math.floor(e.getFullYear()/t)*t),e.setMonth(0,1),e.setHours(0,0,0,0)}),(function(e,n){e.setFullYear(e.getFullYear()+n*t)})):null};const Ga=Va;Va.range;var Xa=Ca((function(t){t.setUTCSeconds(0,0)}),(function(t,e){t.setTime(+t+e*ba)}),(function(t,e){return(e-t)/ba}),(function(t){return t.getUTCMinutes()}));const Za=Xa;Xa.range;var Qa=Ca((function(t){t.setUTCMinutes(0,0,0)}),(function(t,e){t.setTime(+t+e*_a)}),(function(t,e){return(e-t)/_a}),(function(t){return t.getUTCHours()}));const Ka=Qa;Qa.range;var Ja=Ca((function(t){t.setUTCHours(0,0,0,0)}),(function(t,e){t.setUTCDate(t.getUTCDate()+e)}),(function(t,e){return(e-t)/xa}),(function(t){return t.getUTCDate()-1}));const to=Ja;function eo(t){return Ca((function(e){e.setUTCDate(e.getUTCDate()-(e.getUTCDay()+7-t)%7),e.setUTCHours(0,0,0,0)}),(function(t,e){t.setUTCDate(t.getUTCDate()+7*e)}),(function(t,e){return(e-t)/wa}))}Ja.range;var no=eo(0),ro=eo(1),io=eo(2),ao=eo(3),oo=eo(4),so=eo(5),co=eo(6),uo=(no.range,ro.range,io.range,ao.range,oo.range,so.range,co.range,Ca((function(t){t.setUTCDate(1),t.setUTCHours(0,0,0,0)}),(function(t,e){t.setUTCMonth(t.getUTCMonth()+e)}),(function(t,e){return e.getUTCMonth()-t.getUTCMonth()+12*(e.getUTCFullYear()-t.getUTCFullYear())}),(function(t){return t.getUTCMonth()})));const lo=uo;uo.range;var ho=Ca((function(t){t.setUTCMonth(0,1),t.setUTCHours(0,0,0,0)}),(function(t,e){t.setUTCFullYear(t.getUTCFullYear()+e)}),(function(t,e){return e.getUTCFullYear()-t.getUTCFullYear()}),(function(t){return t.getUTCFullYear()}));ho.every=function(t){return isFinite(t=Math.floor(t))&&t>0?Ca((function(e){e.setUTCFullYear(Math.floor(e.getUTCFullYear()/t)*t),e.setUTCMonth(0,1),e.setUTCHours(0,0,0,0)}),(function(e,n){e.setUTCFullYear(e.getUTCFullYear()+n*t)})):null};const fo=ho;function po(t,e,n,r,i,a){const o=[[Na,1,va],[Na,5,5e3],[Na,15,15e3],[Na,30,3e4],[a,1,ba],[a,5,3e5],[a,15,9e5],[a,30,18e5],[i,1,_a],[i,3,108e5],[i,6,216e5],[i,12,432e5],[r,1,xa],[r,2,1728e5],[n,1,wa],[e,1,2592e6],[e,3,7776e6],[t,1,ka]];function s(e,n,r){const i=Math.abs(n-e)/r,a=Wr((([,,t])=>t)).right(o,i);if(a===o.length)return t.every(Hr(e/ka,n/ka,r));if(0===a)return Aa.every(Math.max(Hr(e,n,r),1));const[s,c]=o[i/o[a-1][2][t.toLowerCase(),e])))}function Oo(t,e,n){var r=Eo.exec(e.slice(n,n+1));return r?(t.w=+r[0],n+r[0].length):-1}function Bo(t,e,n){var r=Eo.exec(e.slice(n,n+1));return r?(t.u=+r[0],n+r[0].length):-1}function Lo(t,e,n){var r=Eo.exec(e.slice(n,n+2));return r?(t.U=+r[0],n+r[0].length):-1}function Io(t,e,n){var r=Eo.exec(e.slice(n,n+2));return r?(t.V=+r[0],n+r[0].length):-1}function Ro(t,e,n){var r=Eo.exec(e.slice(n,n+2));return r?(t.W=+r[0],n+r[0].length):-1}function Fo(t,e,n){var r=Eo.exec(e.slice(n,n+4));return r?(t.y=+r[0],n+r[0].length):-1}function Po(t,e,n){var r=Eo.exec(e.slice(n,n+2));return r?(t.y=+r[0]+(+r[0]>68?1900:2e3),n+r[0].length):-1}function jo(t,e,n){var r=/^(Z)|([+-]\d\d)(?::?(\d\d))?/.exec(e.slice(n,n+6));return r?(t.Z=r[1]?0:-(r[2]+(r[3]||"00")),n+r[0].length):-1}function Yo(t,e,n){var r=Eo.exec(e.slice(n,n+1));return r?(t.q=3*r[0]-3,n+r[0].length):-1}function zo(t,e,n){var r=Eo.exec(e.slice(n,n+2));return r?(t.m=r[0]-1,n+r[0].length):-1}function Uo(t,e,n){var r=Eo.exec(e.slice(n,n+2));return r?(t.d=+r[0],n+r[0].length):-1}function qo(t,e,n){var r=Eo.exec(e.slice(n,n+3));return r?(t.m=0,t.d=+r[0],n+r[0].length):-1}function Ho(t,e,n){var r=Eo.exec(e.slice(n,n+2));return r?(t.H=+r[0],n+r[0].length):-1}function $o(t,e,n){var r=Eo.exec(e.slice(n,n+2));return r?(t.M=+r[0],n+r[0].length):-1}function Wo(t,e,n){var r=Eo.exec(e.slice(n,n+2));return r?(t.S=+r[0],n+r[0].length):-1}function Vo(t,e,n){var r=Eo.exec(e.slice(n,n+3));return r?(t.L=+r[0],n+r[0].length):-1}function Go(t,e,n){var r=Eo.exec(e.slice(n,n+6));return r?(t.L=Math.floor(r[0]/1e3),n+r[0].length):-1}function Xo(t,e,n){var r=Co.exec(e.slice(n,n+1));return r?n+r[0].length:-1}function Zo(t,e,n){var r=Eo.exec(e.slice(n));return r?(t.Q=+r[0],n+r[0].length):-1}function Qo(t,e,n){var r=Eo.exec(e.slice(n));return r?(t.s=+r[0],n+r[0].length):-1}function Ko(t,e){return Ao(t.getDate(),e,2)}function Jo(t,e){return Ao(t.getHours(),e,2)}function ts(t,e){return Ao(t.getHours()%12||12,e,2)}function es(t,e){return Ao(1+Ra.count(Ga(t),t),e,3)}function ns(t,e){return Ao(t.getMilliseconds(),e,3)}function rs(t,e){return ns(t,e)+"000"}function is(t,e){return Ao(t.getMonth()+1,e,2)}function as(t,e){return Ao(t.getMinutes(),e,2)}function os(t,e){return Ao(t.getSeconds(),e,2)}function ss(t){var e=t.getDay();return 0===e?7:e}function cs(t,e){return Ao(Pa.count(Ga(t)-1,t),e,2)}function us(t){var e=t.getDay();return e>=4||0===e?Ua(t):Ua.ceil(t)}function ls(t,e){return t=us(t),Ao(Ua.count(Ga(t),t)+(4===Ga(t).getDay()),e,2)}function hs(t){return t.getDay()}function fs(t,e){return Ao(ja.count(Ga(t)-1,t),e,2)}function ds(t,e){return Ao(t.getFullYear()%100,e,2)}function ps(t,e){return Ao((t=us(t)).getFullYear()%100,e,2)}function ys(t,e){return Ao(t.getFullYear()%1e4,e,4)}function gs(t,e){var n=t.getDay();return Ao((t=n>=4||0===n?Ua(t):Ua.ceil(t)).getFullYear()%1e4,e,4)}function ms(t){var e=t.getTimezoneOffset();return(e>0?"-":(e*=-1,"+"))+Ao(e/60|0,"0",2)+Ao(e%60,"0",2)}function vs(t,e){return Ao(t.getUTCDate(),e,2)}function bs(t,e){return Ao(t.getUTCHours(),e,2)}function _s(t,e){return Ao(t.getUTCHours()%12||12,e,2)}function xs(t,e){return Ao(1+to.count(fo(t),t),e,3)}function ws(t,e){return Ao(t.getUTCMilliseconds(),e,3)}function ks(t,e){return ws(t,e)+"000"}function Ts(t,e){return Ao(t.getUTCMonth()+1,e,2)}function Es(t,e){return Ao(t.getUTCMinutes(),e,2)}function Cs(t,e){return Ao(t.getUTCSeconds(),e,2)}function Ss(t){var e=t.getUTCDay();return 0===e?7:e}function As(t,e){return Ao(no.count(fo(t)-1,t),e,2)}function Ms(t){var e=t.getUTCDay();return e>=4||0===e?oo(t):oo.ceil(t)}function Ns(t,e){return t=Ms(t),Ao(oo.count(fo(t),t)+(4===fo(t).getUTCDay()),e,2)}function Ds(t){return t.getUTCDay()}function Os(t,e){return Ao(ro.count(fo(t)-1,t),e,2)}function Bs(t,e){return Ao(t.getUTCFullYear()%100,e,2)}function Ls(t,e){return Ao((t=Ms(t)).getUTCFullYear()%100,e,2)}function Is(t,e){return Ao(t.getUTCFullYear()%1e4,e,4)}function Rs(t,e){var n=t.getUTCDay();return Ao((t=n>=4||0===n?oo(t):oo.ceil(t)).getUTCFullYear()%1e4,e,4)}function Fs(){return"+0000"}function Ps(){return"%"}function js(t){return+t}function Ys(t){return Math.floor(+t/1e3)}function zs(t){return new Date(t)}function Us(t){return t instanceof Date?+t:+new Date(+t)}function qs(t,e,n,r,i,a,o,s,c,u){var l=Xi(),h=l.invert,f=l.domain,d=u(".%L"),p=u(":%S"),y=u("%I:%M"),g=u("%I %p"),m=u("%a %d"),v=u("%b %d"),b=u("%B"),_=u("%Y");function x(t){return(c(t)=12)]},q:function(t){return 1+~~(t.getMonth()/3)},Q:js,s:Ys,S:os,u:ss,U:cs,V:ls,w:hs,W:fs,x:null,X:null,y:ds,Y:ys,Z:ms,"%":Ps},_={a:function(t){return o[t.getUTCDay()]},A:function(t){return a[t.getUTCDay()]},b:function(t){return c[t.getUTCMonth()]},B:function(t){return s[t.getUTCMonth()]},c:null,d:vs,e:vs,f:ks,g:Ls,G:Rs,H:bs,I:_s,j:xs,L:ws,m:Ts,M:Es,p:function(t){return i[+(t.getUTCHours()>=12)]},q:function(t){return 1+~~(t.getUTCMonth()/3)},Q:js,s:Ys,S:Cs,u:Ss,U:As,V:Ns,w:Ds,W:Os,x:null,X:null,y:Bs,Y:Is,Z:Fs,"%":Ps},x={a:function(t,e,n){var r=d.exec(e.slice(n));return r?(t.w=p.get(r[0].toLowerCase()),n+r[0].length):-1},A:function(t,e,n){var r=h.exec(e.slice(n));return r?(t.w=f.get(r[0].toLowerCase()),n+r[0].length):-1},b:function(t,e,n){var r=m.exec(e.slice(n));return r?(t.m=v.get(r[0].toLowerCase()),n+r[0].length):-1},B:function(t,e,n){var r=y.exec(e.slice(n));return r?(t.m=g.get(r[0].toLowerCase()),n+r[0].length):-1},c:function(t,n,r){return T(t,e,n,r)},d:Uo,e:Uo,f:Go,g:Po,G:Fo,H:Ho,I:Ho,j:qo,L:Vo,m:zo,M:$o,p:function(t,e,n){var r=u.exec(e.slice(n));return r?(t.p=l.get(r[0].toLowerCase()),n+r[0].length):-1},q:Yo,Q:Zo,s:Qo,S:Wo,u:Bo,U:Lo,V:Io,w:Oo,W:Ro,x:function(t,e,r){return T(t,n,e,r)},X:function(t,e,n){return T(t,r,e,n)},y:Po,Y:Fo,Z:jo,"%":Xo};function w(t,e){return function(n){var r,i,a,o=[],s=-1,c=0,u=t.length;for(n instanceof Date||(n=new Date(+n));++s53)return null;"w"in a||(a.w=1),"Z"in a?(i=(r=_o(xo(a.y,0,1))).getUTCDay(),r=i>4||0===i?ro.ceil(r):ro(r),r=to.offset(r,7*(a.V-1)),a.y=r.getUTCFullYear(),a.m=r.getUTCMonth(),a.d=r.getUTCDate()+(a.w+6)%7):(i=(r=bo(xo(a.y,0,1))).getDay(),r=i>4||0===i?ja.ceil(r):ja(r),r=Ra.offset(r,7*(a.V-1)),a.y=r.getFullYear(),a.m=r.getMonth(),a.d=r.getDate()+(a.w+6)%7)}else("W"in a||"U"in a)&&("w"in a||(a.w="u"in a?a.u%7:"W"in a?1:0),i="Z"in a?_o(xo(a.y,0,1)).getUTCDay():bo(xo(a.y,0,1)).getDay(),a.m=0,a.d="W"in a?(a.w+6)%7+7*a.W-(i+5)%7:a.w+7*a.U-(i+6)%7);return"Z"in a?(a.H+=a.Z/100|0,a.M+=a.Z%100,_o(a)):bo(a)}}function T(t,e,n,r){for(var i,a,o=0,s=e.length,c=n.length;o=c)return-1;if(37===(i=e.charCodeAt(o++))){if(i=e.charAt(o++),!(a=x[i in To?e.charAt(o++):i])||(r=a(t,n,r))<0)return-1}else if(i!=n.charCodeAt(r++))return-1}return r}return b.x=w(n,b),b.X=w(r,b),b.c=w(e,b),_.x=w(n,_),_.X=w(r,_),_.c=w(e,_),{format:function(t){var e=w(t+="",b);return e.toString=function(){return t},e},parse:function(t){var e=k(t+="",!1);return e.toString=function(){return t},e},utcFormat:function(t){var e=w(t+="",_);return e.toString=function(){return t},e},utcParse:function(t){var e=k(t+="",!0);return e.toString=function(){return t},e}}}({dateTime:"%x, %X",date:"%-m/%-d/%Y",time:"%-I:%M:%S %p",periods:["AM","PM"],days:["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],shortDays:["Sun","Mon","Tue","Wed","Thu","Fri","Sat"],months:["January","February","March","April","May","June","July","August","September","October","November","December"],shortMonths:["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"]}),ko=wo.format,wo.parse,wo.utcFormat,wo.utcParse;var Qs=Array.prototype.find;function Ks(){return this.firstElementChild}var Js=Array.prototype.filter;function tc(){return Array.from(this.children)}function ec(t){return new Array(t.length)}function nc(t,e){this.ownerDocument=t.ownerDocument,this.namespaceURI=t.namespaceURI,this._next=null,this._parent=t,this.__data__=e}function rc(t){return function(){return t}}function ic(t,e,n,r,i,a){for(var o,s=0,c=e.length,u=a.length;se?1:t>=e?0:NaN}nc.prototype={constructor:nc,appendChild:function(t){return this._parent.insertBefore(t,this._next)},insertBefore:function(t,e){return this._parent.insertBefore(t,e)},querySelector:function(t){return this._parent.querySelector(t)},querySelectorAll:function(t){return this._parent.querySelectorAll(t)}};var uc="http://www.w3.org/1999/xhtml";const lc={svg:"http://www.w3.org/2000/svg",xhtml:uc,xlink:"http://www.w3.org/1999/xlink",xml:"http://www.w3.org/XML/1998/namespace",xmlns:"http://www.w3.org/2000/xmlns/"};function hc(t){var e=t+="",n=e.indexOf(":");return n>=0&&"xmlns"!==(e=t.slice(0,n))&&(t=t.slice(n+1)),lc.hasOwnProperty(e)?{space:lc[e],local:t}:t}function fc(t){return function(){this.removeAttribute(t)}}function dc(t){return function(){this.removeAttributeNS(t.space,t.local)}}function pc(t,e){return function(){this.setAttribute(t,e)}}function yc(t,e){return function(){this.setAttributeNS(t.space,t.local,e)}}function gc(t,e){return function(){var n=e.apply(this,arguments);null==n?this.removeAttribute(t):this.setAttribute(t,n)}}function mc(t,e){return function(){var n=e.apply(this,arguments);null==n?this.removeAttributeNS(t.space,t.local):this.setAttributeNS(t.space,t.local,n)}}function vc(t){return t.ownerDocument&&t.ownerDocument.defaultView||t.document&&t||t.defaultView}function bc(t){return function(){this.style.removeProperty(t)}}function _c(t,e,n){return function(){this.style.setProperty(t,e,n)}}function xc(t,e,n){return function(){var r=e.apply(this,arguments);null==r?this.style.removeProperty(t):this.style.setProperty(t,r,n)}}function wc(t,e){return t.style.getPropertyValue(e)||vc(t).getComputedStyle(t,null).getPropertyValue(e)}function kc(t){return function(){delete this[t]}}function Tc(t,e){return function(){this[t]=e}}function Ec(t,e){return function(){var n=e.apply(this,arguments);null==n?delete this[t]:this[t]=n}}function Cc(t){return t.trim().split(/^|\s+/)}function Sc(t){return t.classList||new Ac(t)}function Ac(t){this._node=t,this._names=Cc(t.getAttribute("class")||"")}function Mc(t,e){for(var n=Sc(t),r=-1,i=e.length;++r=0&&(e=t.slice(n+1),t=t.slice(0,n)),{type:t,name:e}}))}function Zc(t){return function(){var e=this.__on;if(e){for(var n,r=0,i=-1,a=e.length;r=0&&(this._names.splice(e,1),this._node.setAttribute("class",this._names.join(" ")))},contains:function(t){return this._names.indexOf(t)>=0}};var eu=[null];function nu(t,e){this._groups=t,this._parents=e}function ru(){return new nu([[document.documentElement]],eu)}nu.prototype=ru.prototype={constructor:nu,select:function(t){"function"!=typeof t&&(t=$s(t));for(var e=this._groups,n=e.length,r=new Array(n),i=0;i=x&&(x=_+1);!(b=g[x])&&++x=0;)(r=i[a])&&(o&&4^r.compareDocumentPosition(o)&&o.parentNode.insertBefore(r,o),o=r);return this},sort:function(t){function e(e,n){return e&&n?t(e.__data__,n.__data__):!e-!n}t||(t=cc);for(var n=this._groups,r=n.length,i=new Array(r),a=0;a1?this.each((null==e?bc:"function"==typeof e?xc:_c)(t,e,null==n?"":n)):wc(this.node(),t)},property:function(t,e){return arguments.length>1?this.each((null==e?kc:"function"==typeof e?Ec:Tc)(t,e)):this.node()[t]},classed:function(t,e){var n=Cc(t+"");if(arguments.length<2){for(var r=Sc(this.node()),i=-1,a=n.length;++iuu)if(Math.abs(l*s-c*u)>uu&&i){var f=n-a,d=r-o,p=s*s+c*c,y=f*f+d*d,g=Math.sqrt(p),m=Math.sqrt(h),v=i*Math.tan((su-Math.acos((p+h-y)/(2*g*m)))/2),b=v/m,_=v/g;Math.abs(b-1)>uu&&(this._+="L"+(t+b*u)+","+(e+b*l)),this._+="A"+i+","+i+",0,0,"+ +(l*f>u*d)+","+(this._x1=t+_*s)+","+(this._y1=e+_*c)}else this._+="L"+(this._x1=t)+","+(this._y1=e)},arc:function(t,e,n,r,i,a){t=+t,e=+e,a=!!a;var o=(n=+n)*Math.cos(r),s=n*Math.sin(r),c=t+o,u=e+s,l=1^a,h=a?r-i:i-r;if(n<0)throw new Error("negative radius: "+n);null===this._x1?this._+="M"+c+","+u:(Math.abs(this._x1-c)>uu||Math.abs(this._y1-u)>uu)&&(this._+="L"+c+","+u),n&&(h<0&&(h=h%cu+cu),h>lu?this._+="A"+n+","+n+",0,1,"+l+","+(t-o)+","+(e-s)+"A"+n+","+n+",0,1,"+l+","+(this._x1=c)+","+(this._y1=u):h>uu&&(this._+="A"+n+","+n+",0,"+ +(h>=su)+","+l+","+(this._x1=t+n*Math.cos(i))+","+(this._y1=e+n*Math.sin(i))))},rect:function(t,e,n,r){this._+="M"+(this._x0=this._x1=+t)+","+(this._y0=this._y1=+e)+"h"+ +n+"v"+ +r+"h"+-n+"Z"},toString:function(){return this._}};const du=fu;function pu(t){return function(){return t}}var yu=Math.abs,gu=Math.atan2,mu=Math.cos,vu=Math.max,bu=Math.min,_u=Math.sin,xu=Math.sqrt,wu=1e-12,ku=Math.PI,Tu=ku/2,Eu=2*ku;function Cu(t){return t>1?0:t<-1?ku:Math.acos(t)}function Su(t){return t>=1?Tu:t<=-1?-Tu:Math.asin(t)}function Au(t){return t.innerRadius}function Mu(t){return t.outerRadius}function Nu(t){return t.startAngle}function Du(t){return t.endAngle}function Ou(t){return t&&t.padAngle}function Bu(t,e,n,r,i,a,o,s){var c=n-t,u=r-e,l=o-i,h=s-a,f=h*c-l*u;if(!(f*fN*N+D*D&&(T=C,E=S),{cx:T,cy:E,x01:-l,y01:-h,x11:T*(i/x-1),y11:E*(i/x-1)}}function Iu(){var t=Au,e=Mu,n=pu(0),r=null,i=Nu,a=Du,o=Ou,s=null;function c(){var c,u,l=+t.apply(this,arguments),h=+e.apply(this,arguments),f=i.apply(this,arguments)-Tu,d=a.apply(this,arguments)-Tu,p=yu(d-f),y=d>f;if(s||(s=c=du()),hwu)if(p>Eu-wu)s.moveTo(h*mu(f),h*_u(f)),s.arc(0,0,h,f,d,!y),l>wu&&(s.moveTo(l*mu(d),l*_u(d)),s.arc(0,0,l,d,f,y));else{var g,m,v=f,b=d,_=f,x=d,w=p,k=p,T=o.apply(this,arguments)/2,E=T>wu&&(r?+r.apply(this,arguments):xu(l*l+h*h)),C=bu(yu(h-l)/2,+n.apply(this,arguments)),S=C,A=C;if(E>wu){var M=Su(E/l*_u(T)),N=Su(E/h*_u(T));(w-=2*M)>wu?(_+=M*=y?1:-1,x-=M):(w=0,_=x=(f+d)/2),(k-=2*N)>wu?(v+=N*=y?1:-1,b-=N):(k=0,v=b=(f+d)/2)}var D=h*mu(v),O=h*_u(v),B=l*mu(x),L=l*_u(x);if(C>wu){var I,R=h*mu(b),F=h*_u(b),P=l*mu(_),j=l*_u(_);if(pwu?A>wu?(g=Lu(P,j,D,O,h,A,y),m=Lu(R,F,B,L,h,A,y),s.moveTo(g.cx+g.x01,g.cy+g.y01),Awu&&w>wu?S>wu?(g=Lu(B,L,R,F,l,-S,y),m=Lu(D,O,P,j,l,-S,y),s.lineTo(g.cx+g.x01,g.cy+g.y01),St?1:e>=t?0:NaN}function qu(t){return t}function Hu(){}function $u(t,e,n){t._context.bezierCurveTo((2*t._x0+t._x1)/3,(2*t._y0+t._y1)/3,(t._x0+2*t._x1)/3,(t._y0+2*t._y1)/3,(t._x0+4*t._x1+e)/6,(t._y0+4*t._y1+n)/6)}function Wu(t){this._context=t}function Vu(t){return new Wu(t)}function Gu(t){this._context=t}function Xu(t){this._context=t}function Zu(t){this._context=t}function Qu(t){return t<0?-1:1}function Ku(t,e,n){var r=t._x1-t._x0,i=e-t._x1,a=(t._y1-t._y0)/(r||i<0&&-0),o=(n-t._y1)/(i||r<0&&-0),s=(a*i+o*r)/(r+i);return(Qu(a)+Qu(o))*Math.min(Math.abs(a),Math.abs(o),.5*Math.abs(s))||0}function Ju(t,e){var n=t._x1-t._x0;return n?(3*(t._y1-t._y0)/n-e)/2:e}function tl(t,e,n){var r=t._x0,i=t._y0,a=t._x1,o=t._y1,s=(a-r)/3;t._context.bezierCurveTo(r+s,i+s*e,a-s,o-s*n,a,o)}function el(t){this._context=t}function nl(t){this._context=new rl(t)}function rl(t){this._context=t}function il(t){this._context=t}function al(t){var e,n,r=t.length-1,i=new Array(r),a=new Array(r),o=new Array(r);for(i[0]=0,a[0]=2,o[0]=t[0]+2*t[1],e=1;e=0;--e)i[e]=(o[e]-i[e+1])/a[e];for(a[r-1]=(t[r]+i[r-1])/2,e=0;e=0&&(this._t=1-this._t,this._line=1-this._line)},point:function(t,e){switch(t=+t,e=+e,this._point){case 0:this._point=1,this._line?this._context.lineTo(t,e):this._context.moveTo(t,e);break;case 1:this._point=2;default:if(this._t<=0)this._context.lineTo(this._x,e),this._context.lineTo(t,e);else{var n=this._x*(1-this._t)+t*this._t;this._context.lineTo(n,this._y),this._context.lineTo(n,e)}}this._x=t,this._y=e}};var sl=new Date,cl=new Date;function ul(t,e,n,r){function i(e){return t(e=0===arguments.length?new Date:new Date(+e)),e}return i.floor=function(e){return t(e=new Date(+e)),e},i.ceil=function(n){return t(n=new Date(n-1)),e(n,1),t(n),n},i.round=function(t){var e=i(t),n=i.ceil(t);return t-e0))return s;do{s.push(o=new Date(+n)),e(n,a),t(n)}while(o=e)for(;t(e),!n(e);)e.setTime(e-1)}),(function(t,r){if(t>=t)if(r<0)for(;++r<=0;)for(;e(t,-1),!n(t););else for(;--r>=0;)for(;e(t,1),!n(t););}))},n&&(i.count=function(e,r){return sl.setTime(+e),cl.setTime(+r),t(sl),t(cl),Math.floor(n(sl,cl))},i.every=function(t){return t=Math.floor(t),isFinite(t)&&t>0?t>1?i.filter(r?function(e){return r(e)%t==0}:function(e){return i.count(0,e)%t==0}):i:null}),i}const ll=864e5,hl=6048e5;function fl(t){return ul((function(e){e.setUTCDate(e.getUTCDate()-(e.getUTCDay()+7-t)%7),e.setUTCHours(0,0,0,0)}),(function(t,e){t.setUTCDate(t.getUTCDate()+7*e)}),(function(t,e){return(e-t)/hl}))}var dl=fl(0),pl=fl(1),yl=fl(2),gl=fl(3),ml=fl(4),vl=fl(5),bl=fl(6),_l=(dl.range,pl.range,yl.range,gl.range,ml.range,vl.range,bl.range,ul((function(t){t.setUTCHours(0,0,0,0)}),(function(t,e){t.setUTCDate(t.getUTCDate()+e)}),(function(t,e){return(e-t)/ll}),(function(t){return t.getUTCDate()-1})));const xl=_l;function wl(t){return ul((function(e){e.setDate(e.getDate()-(e.getDay()+7-t)%7),e.setHours(0,0,0,0)}),(function(t,e){t.setDate(t.getDate()+7*e)}),(function(t,e){return(e-t-6e4*(e.getTimezoneOffset()-t.getTimezoneOffset()))/hl}))}_l.range;var kl=wl(0),Tl=wl(1),El=wl(2),Cl=wl(3),Sl=wl(4),Al=wl(5),Ml=wl(6),Nl=(kl.range,Tl.range,El.range,Cl.range,Sl.range,Al.range,Ml.range,ul((t=>t.setHours(0,0,0,0)),((t,e)=>t.setDate(t.getDate()+e)),((t,e)=>(e-t-6e4*(e.getTimezoneOffset()-t.getTimezoneOffset()))/ll),(t=>t.getDate()-1)));const Dl=Nl;Nl.range;var Ol=ul((function(t){t.setMonth(0,1),t.setHours(0,0,0,0)}),(function(t,e){t.setFullYear(t.getFullYear()+e)}),(function(t,e){return e.getFullYear()-t.getFullYear()}),(function(t){return t.getFullYear()}));Ol.every=function(t){return isFinite(t=Math.floor(t))&&t>0?ul((function(e){e.setFullYear(Math.floor(e.getFullYear()/t)*t),e.setMonth(0,1),e.setHours(0,0,0,0)}),(function(e,n){e.setFullYear(e.getFullYear()+n*t)})):null};const Bl=Ol;Ol.range;var Ll=ul((function(t){t.setUTCMonth(0,1),t.setUTCHours(0,0,0,0)}),(function(t,e){t.setUTCFullYear(t.getUTCFullYear()+e)}),(function(t,e){return e.getUTCFullYear()-t.getUTCFullYear()}),(function(t){return t.getUTCFullYear()}));Ll.every=function(t){return isFinite(t=Math.floor(t))&&t>0?ul((function(e){e.setUTCFullYear(Math.floor(e.getUTCFullYear()/t)*t),e.setUTCMonth(0,1),e.setUTCHours(0,0,0,0)}),(function(e,n){e.setUTCFullYear(e.getUTCFullYear()+n*t)})):null};const Il=Ll;function Rl(t){if(0<=t.y&&t.y<100){var e=new Date(-1,t.m,t.d,t.H,t.M,t.S,t.L);return e.setFullYear(t.y),e}return new Date(t.y,t.m,t.d,t.H,t.M,t.S,t.L)}function Fl(t){if(0<=t.y&&t.y<100){var e=new Date(Date.UTC(-1,t.m,t.d,t.H,t.M,t.S,t.L));return e.setUTCFullYear(t.y),e}return new Date(Date.UTC(t.y,t.m,t.d,t.H,t.M,t.S,t.L))}function Pl(t,e,n){return{y:t,m:e,d:n,H:0,M:0,S:0,L:0}}Ll.range;var jl,Yl,zl={"-":"",_:" ",0:"0"},Ul=/^\s*\d+/,ql=/^%/,Hl=/[\\^$*+?|[\]().{}]/g;function $l(t,e,n){var r=t<0?"-":"",i=(r?-t:t)+"",a=i.length;return r+(a[t.toLowerCase(),e])))}function Xl(t,e,n){var r=Ul.exec(e.slice(n,n+1));return r?(t.w=+r[0],n+r[0].length):-1}function Zl(t,e,n){var r=Ul.exec(e.slice(n,n+1));return r?(t.u=+r[0],n+r[0].length):-1}function Ql(t,e,n){var r=Ul.exec(e.slice(n,n+2));return r?(t.U=+r[0],n+r[0].length):-1}function Kl(t,e,n){var r=Ul.exec(e.slice(n,n+2));return r?(t.V=+r[0],n+r[0].length):-1}function Jl(t,e,n){var r=Ul.exec(e.slice(n,n+2));return r?(t.W=+r[0],n+r[0].length):-1}function th(t,e,n){var r=Ul.exec(e.slice(n,n+4));return r?(t.y=+r[0],n+r[0].length):-1}function eh(t,e,n){var r=Ul.exec(e.slice(n,n+2));return r?(t.y=+r[0]+(+r[0]>68?1900:2e3),n+r[0].length):-1}function nh(t,e,n){var r=/^(Z)|([+-]\d\d)(?::?(\d\d))?/.exec(e.slice(n,n+6));return r?(t.Z=r[1]?0:-(r[2]+(r[3]||"00")),n+r[0].length):-1}function rh(t,e,n){var r=Ul.exec(e.slice(n,n+1));return r?(t.q=3*r[0]-3,n+r[0].length):-1}function ih(t,e,n){var r=Ul.exec(e.slice(n,n+2));return r?(t.m=r[0]-1,n+r[0].length):-1}function ah(t,e,n){var r=Ul.exec(e.slice(n,n+2));return r?(t.d=+r[0],n+r[0].length):-1}function oh(t,e,n){var r=Ul.exec(e.slice(n,n+3));return r?(t.m=0,t.d=+r[0],n+r[0].length):-1}function sh(t,e,n){var r=Ul.exec(e.slice(n,n+2));return r?(t.H=+r[0],n+r[0].length):-1}function ch(t,e,n){var r=Ul.exec(e.slice(n,n+2));return r?(t.M=+r[0],n+r[0].length):-1}function uh(t,e,n){var r=Ul.exec(e.slice(n,n+2));return r?(t.S=+r[0],n+r[0].length):-1}function lh(t,e,n){var r=Ul.exec(e.slice(n,n+3));return r?(t.L=+r[0],n+r[0].length):-1}function hh(t,e,n){var r=Ul.exec(e.slice(n,n+6));return r?(t.L=Math.floor(r[0]/1e3),n+r[0].length):-1}function fh(t,e,n){var r=ql.exec(e.slice(n,n+1));return r?n+r[0].length:-1}function dh(t,e,n){var r=Ul.exec(e.slice(n));return r?(t.Q=+r[0],n+r[0].length):-1}function ph(t,e,n){var r=Ul.exec(e.slice(n));return r?(t.s=+r[0],n+r[0].length):-1}function yh(t,e){return $l(t.getDate(),e,2)}function gh(t,e){return $l(t.getHours(),e,2)}function mh(t,e){return $l(t.getHours()%12||12,e,2)}function vh(t,e){return $l(1+Dl.count(Bl(t),t),e,3)}function bh(t,e){return $l(t.getMilliseconds(),e,3)}function _h(t,e){return bh(t,e)+"000"}function xh(t,e){return $l(t.getMonth()+1,e,2)}function wh(t,e){return $l(t.getMinutes(),e,2)}function kh(t,e){return $l(t.getSeconds(),e,2)}function Th(t){var e=t.getDay();return 0===e?7:e}function Eh(t,e){return $l(kl.count(Bl(t)-1,t),e,2)}function Ch(t){var e=t.getDay();return e>=4||0===e?Sl(t):Sl.ceil(t)}function Sh(t,e){return t=Ch(t),$l(Sl.count(Bl(t),t)+(4===Bl(t).getDay()),e,2)}function Ah(t){return t.getDay()}function Mh(t,e){return $l(Tl.count(Bl(t)-1,t),e,2)}function Nh(t,e){return $l(t.getFullYear()%100,e,2)}function Dh(t,e){return $l((t=Ch(t)).getFullYear()%100,e,2)}function Oh(t,e){return $l(t.getFullYear()%1e4,e,4)}function Bh(t,e){var n=t.getDay();return $l((t=n>=4||0===n?Sl(t):Sl.ceil(t)).getFullYear()%1e4,e,4)}function Lh(t){var e=t.getTimezoneOffset();return(e>0?"-":(e*=-1,"+"))+$l(e/60|0,"0",2)+$l(e%60,"0",2)}function Ih(t,e){return $l(t.getUTCDate(),e,2)}function Rh(t,e){return $l(t.getUTCHours(),e,2)}function Fh(t,e){return $l(t.getUTCHours()%12||12,e,2)}function Ph(t,e){return $l(1+xl.count(Il(t),t),e,3)}function jh(t,e){return $l(t.getUTCMilliseconds(),e,3)}function Yh(t,e){return jh(t,e)+"000"}function zh(t,e){return $l(t.getUTCMonth()+1,e,2)}function Uh(t,e){return $l(t.getUTCMinutes(),e,2)}function qh(t,e){return $l(t.getUTCSeconds(),e,2)}function Hh(t){var e=t.getUTCDay();return 0===e?7:e}function $h(t,e){return $l(dl.count(Il(t)-1,t),e,2)}function Wh(t){var e=t.getUTCDay();return e>=4||0===e?ml(t):ml.ceil(t)}function Vh(t,e){return t=Wh(t),$l(ml.count(Il(t),t)+(4===Il(t).getUTCDay()),e,2)}function Gh(t){return t.getUTCDay()}function Xh(t,e){return $l(pl.count(Il(t)-1,t),e,2)}function Zh(t,e){return $l(t.getUTCFullYear()%100,e,2)}function Qh(t,e){return $l((t=Wh(t)).getUTCFullYear()%100,e,2)}function Kh(t,e){return $l(t.getUTCFullYear()%1e4,e,4)}function Jh(t,e){var n=t.getUTCDay();return $l((t=n>=4||0===n?ml(t):ml.ceil(t)).getUTCFullYear()%1e4,e,4)}function tf(){return"+0000"}function ef(){return"%"}function nf(t){return+t}function rf(t){return Math.floor(+t/1e3)}jl=function(t){var e=t.dateTime,n=t.date,r=t.time,i=t.periods,a=t.days,o=t.shortDays,s=t.months,c=t.shortMonths,u=Vl(i),l=Gl(i),h=Vl(a),f=Gl(a),d=Vl(o),p=Gl(o),y=Vl(s),g=Gl(s),m=Vl(c),v=Gl(c),b={a:function(t){return o[t.getDay()]},A:function(t){return a[t.getDay()]},b:function(t){return c[t.getMonth()]},B:function(t){return s[t.getMonth()]},c:null,d:yh,e:yh,f:_h,g:Dh,G:Bh,H:gh,I:mh,j:vh,L:bh,m:xh,M:wh,p:function(t){return i[+(t.getHours()>=12)]},q:function(t){return 1+~~(t.getMonth()/3)},Q:nf,s:rf,S:kh,u:Th,U:Eh,V:Sh,w:Ah,W:Mh,x:null,X:null,y:Nh,Y:Oh,Z:Lh,"%":ef},_={a:function(t){return o[t.getUTCDay()]},A:function(t){return a[t.getUTCDay()]},b:function(t){return c[t.getUTCMonth()]},B:function(t){return s[t.getUTCMonth()]},c:null,d:Ih,e:Ih,f:Yh,g:Qh,G:Jh,H:Rh,I:Fh,j:Ph,L:jh,m:zh,M:Uh,p:function(t){return i[+(t.getUTCHours()>=12)]},q:function(t){return 1+~~(t.getUTCMonth()/3)},Q:nf,s:rf,S:qh,u:Hh,U:$h,V:Vh,w:Gh,W:Xh,x:null,X:null,y:Zh,Y:Kh,Z:tf,"%":ef},x={a:function(t,e,n){var r=d.exec(e.slice(n));return r?(t.w=p.get(r[0].toLowerCase()),n+r[0].length):-1},A:function(t,e,n){var r=h.exec(e.slice(n));return r?(t.w=f.get(r[0].toLowerCase()),n+r[0].length):-1},b:function(t,e,n){var r=m.exec(e.slice(n));return r?(t.m=v.get(r[0].toLowerCase()),n+r[0].length):-1},B:function(t,e,n){var r=y.exec(e.slice(n));return r?(t.m=g.get(r[0].toLowerCase()),n+r[0].length):-1},c:function(t,n,r){return T(t,e,n,r)},d:ah,e:ah,f:hh,g:eh,G:th,H:sh,I:sh,j:oh,L:lh,m:ih,M:ch,p:function(t,e,n){var r=u.exec(e.slice(n));return r?(t.p=l.get(r[0].toLowerCase()),n+r[0].length):-1},q:rh,Q:dh,s:ph,S:uh,u:Zl,U:Ql,V:Kl,w:Xl,W:Jl,x:function(t,e,r){return T(t,n,e,r)},X:function(t,e,n){return T(t,r,e,n)},y:eh,Y:th,Z:nh,"%":fh};function w(t,e){return function(n){var r,i,a,o=[],s=-1,c=0,u=t.length;for(n instanceof Date||(n=new Date(+n));++s53)return null;"w"in a||(a.w=1),"Z"in a?(i=(r=Fl(Pl(a.y,0,1))).getUTCDay(),r=i>4||0===i?pl.ceil(r):pl(r),r=xl.offset(r,7*(a.V-1)),a.y=r.getUTCFullYear(),a.m=r.getUTCMonth(),a.d=r.getUTCDate()+(a.w+6)%7):(i=(r=Rl(Pl(a.y,0,1))).getDay(),r=i>4||0===i?Tl.ceil(r):Tl(r),r=Dl.offset(r,7*(a.V-1)),a.y=r.getFullYear(),a.m=r.getMonth(),a.d=r.getDate()+(a.w+6)%7)}else("W"in a||"U"in a)&&("w"in a||(a.w="u"in a?a.u%7:"W"in a?1:0),i="Z"in a?Fl(Pl(a.y,0,1)).getUTCDay():Rl(Pl(a.y,0,1)).getDay(),a.m=0,a.d="W"in a?(a.w+6)%7+7*a.W-(i+5)%7:a.w+7*a.U-(i+6)%7);return"Z"in a?(a.H+=a.Z/100|0,a.M+=a.Z%100,Fl(a)):Rl(a)}}function T(t,e,n,r){for(var i,a,o=0,s=e.length,c=n.length;o=c)return-1;if(37===(i=e.charCodeAt(o++))){if(i=e.charAt(o++),!(a=x[i in zl?e.charAt(o++):i])||(r=a(t,n,r))<0)return-1}else if(i!=n.charCodeAt(r++))return-1}return r}return b.x=w(n,b),b.X=w(r,b),b.c=w(e,b),_.x=w(n,_),_.X=w(r,_),_.c=w(e,_),{format:function(t){var e=w(t+="",b);return e.toString=function(){return t},e},parse:function(t){var e=k(t+="",!1);return e.toString=function(){return t},e},utcFormat:function(t){var e=w(t+="",_);return e.toString=function(){return t},e},utcParse:function(t){var e=k(t+="",!0);return e.toString=function(){return t},e}}}({dateTime:"%x, %X",date:"%-m/%-d/%Y",time:"%-I:%M:%S %p",periods:["AM","PM"],days:["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],shortDays:["Sun","Mon","Tue","Wed","Thu","Fri","Sat"],months:["January","February","March","April","May","June","July","August","September","October","November","December"],shortMonths:["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"]}),Yl=jl.format,jl.parse,jl.utcFormat,jl.utcParse;var af={value:()=>{}};function of(){for(var t,e=0,n=arguments.length,r={};e=0&&(n=t.slice(r+1),t=t.slice(0,r)),t&&!e.hasOwnProperty(t))throw new Error("unknown type: "+t);return{type:t,name:n}}))}function uf(t,e){for(var n,r=0,i=t.length;r0)for(var n,r,i=new Array(n),a=0;a=0&&e._call.call(void 0,t),e=e._next;--pf}()}finally{pf=0,function(){for(var t,e,n=ff,r=1/0;n;)n._call?(r>n._time&&(r=n._time),t=n,n=n._next):(e=n._next,n._next=null,n=t?t._next=e:ff=e);df=t,Af(r)}(),vf=0}}function Sf(){var t=_f.now(),e=t-mf;e>1e3&&(bf-=e,mf=t)}function Af(t){pf||(yf&&(yf=clearTimeout(yf)),t-vf>24?(t<1/0&&(yf=setTimeout(Cf,t-_f.now()-bf)),gf&&(gf=clearInterval(gf))):(gf||(mf=_f.now(),gf=setInterval(Sf,1e3)),pf=1,xf(Cf)))}function Mf(t,e,n){var r=new Tf;return e=null==e?0:+e,r.restart((n=>{r.stop(),t(n+e)}),e,n),r}Tf.prototype=Ef.prototype={constructor:Tf,restart:function(t,e,n){if("function"!=typeof t)throw new TypeError("callback is not a function");n=(null==n?wf():+n)+(null==e?0:+e),this._next||df===this||(df?df._next=this:ff=this,df=this),this._call=t,this._time=n,Af()},stop:function(){this._call&&(this._call=null,this._time=1/0,Af())}};var Nf=hf("start","end","cancel","interrupt"),Df=[];function Of(t,e,n,r,i,a){var o=t.__transition;if(o){if(n in o)return}else t.__transition={};!function(t,e,n){var r,i=t.__transition;function a(c){var u,l,h,f;if(1!==n.state)return s();for(u in i)if((f=i[u]).name===n.name){if(3===f.state)return Mf(a);4===f.state?(f.state=6,f.timer.stop(),f.on.call("interrupt",t,t.__data__,f.index,f.group),delete i[u]):+u0)throw new Error("too late; already scheduled");return n}function Lf(t,e){var n=If(t,e);if(n.state>3)throw new Error("too late; already running");return n}function If(t,e){var n=t.__transition;if(!n||!(n=n[e]))throw new Error("transition not found");return n}function Rf(t,e){return t=+t,e=+e,function(n){return t*(1-n)+e*n}}var Ff,Pf=180/Math.PI,jf={translateX:0,translateY:0,rotate:0,skewX:0,scaleX:1,scaleY:1};function Yf(t,e,n,r,i,a){var o,s,c;return(o=Math.sqrt(t*t+e*e))&&(t/=o,e/=o),(c=t*n+e*r)&&(n-=t*c,r-=e*c),(s=Math.sqrt(n*n+r*r))&&(n/=s,r/=s,c/=s),t*r180?e+=360:e-t>180&&(t+=360),a.push({i:n.push(i(n)+"rotate(",null,r)-2,x:Rf(t,e)})):e&&n.push(i(n)+"rotate("+e+r)}(a.rotate,o.rotate,s,c),function(t,e,n,a){t!==e?a.push({i:n.push(i(n)+"skewX(",null,r)-2,x:Rf(t,e)}):e&&n.push(i(n)+"skewX("+e+r)}(a.skewX,o.skewX,s,c),function(t,e,n,r,a,o){if(t!==n||e!==r){var s=a.push(i(a)+"scale(",null,",",null,")");o.push({i:s-4,x:Rf(t,n)},{i:s-2,x:Rf(e,r)})}else 1===n&&1===r||a.push(i(a)+"scale("+n+","+r+")")}(a.scaleX,a.scaleY,o.scaleX,o.scaleY,s,c),a=o=null,function(t){for(var e,n=-1,r=c.length;++n=1?(n=1,e-1):Math.floor(n*e),i=t[r],a=t[r+1],o=r>0?t[r-1]:2*i-a,s=ra&&(i=e.slice(a,i),s[o]?s[o]+=i:s[++o]=i),(n=n[0])===(r=r[0])?s[o]?s[o]+=r:s[++o]=r:(s[++o]=null,c.push({i:o,x:Rf(n,r)})),a=Qf.lastIndex;return a=0&&(t=t.slice(0,e)),!t||"start"===t}))}(e)?Bf:Lf;return function(){var o=a(this,t),s=o.on;s!==r&&(i=(r=s).copy()).on(e,n),o.on=i}}var gd=iu.prototype.constructor;function md(t){return function(){this.style.removeProperty(t)}}function vd(t,e,n){return function(r){this.style.setProperty(t,e.call(this,r),n)}}function bd(t,e,n){var r,i;function a(){var a=e.apply(this,arguments);return a!==i&&(r=(i=a)&&vd(t,a,n)),r}return a._value=e,a}function _d(t){return function(e){this.textContent=t.call(this,e)}}function xd(t){var e,n;function r(){var r=t.apply(this,arguments);return r!==n&&(e=(n=r)&&_d(r)),e}return r._value=t,r}var wd=0;function kd(t,e,n,r){this._groups=t,this._parents=e,this._name=n,this._id=r}function Td(){return++wd}var Ed=iu.prototype;kd.prototype=function(t){return iu().transition(t)}.prototype={constructor:kd,select:function(t){var e=this._name,n=this._id;"function"!=typeof t&&(t=$s(t));for(var r=this._groups,i=r.length,a=new Array(i),o=0;o2&&n.state<5,n.state=6,n.timer.stop(),n.on.call(r?"interrupt":"cancel",t,t.__data__,n.index,n.group),delete a[i]):o=!1;o&&delete t.__transition}}(this,t)}))},iu.prototype.transition=function(t){var e,n;t instanceof kd?(e=t._id,t=t._name):(e=Td(),(n=Cd).time=wf(),t=null==t?null:t+"");for(var r=this._groups,i=r.length,a=0;ae?1:t>=e?0:NaN}Yd.prototype={constructor:Yd,appendChild:function(t){return this._parent.insertBefore(t,this._next)},insertBefore:function(t,e){return this._parent.insertBefore(t,e)},querySelector:function(t){return this._parent.querySelector(t)},querySelectorAll:function(t){return this._parent.querySelectorAll(t)}};var Vd="http://www.w3.org/1999/xhtml";const Gd={svg:"http://www.w3.org/2000/svg",xhtml:Vd,xlink:"http://www.w3.org/1999/xlink",xml:"http://www.w3.org/XML/1998/namespace",xmlns:"http://www.w3.org/2000/xmlns/"};function Xd(t){var e=t+="",n=e.indexOf(":");return n>=0&&"xmlns"!==(e=t.slice(0,n))&&(t=t.slice(n+1)),Gd.hasOwnProperty(e)?{space:Gd[e],local:t}:t}function Zd(t){return function(){this.removeAttribute(t)}}function Qd(t){return function(){this.removeAttributeNS(t.space,t.local)}}function Kd(t,e){return function(){this.setAttribute(t,e)}}function Jd(t,e){return function(){this.setAttributeNS(t.space,t.local,e)}}function tp(t,e){return function(){var n=e.apply(this,arguments);null==n?this.removeAttribute(t):this.setAttribute(t,n)}}function ep(t,e){return function(){var n=e.apply(this,arguments);null==n?this.removeAttributeNS(t.space,t.local):this.setAttributeNS(t.space,t.local,n)}}function np(t){return t.ownerDocument&&t.ownerDocument.defaultView||t.document&&t||t.defaultView}function rp(t){return function(){this.style.removeProperty(t)}}function ip(t,e,n){return function(){this.style.setProperty(t,e,n)}}function ap(t,e,n){return function(){var r=e.apply(this,arguments);null==r?this.style.removeProperty(t):this.style.setProperty(t,r,n)}}function op(t,e){return t.style.getPropertyValue(e)||np(t).getComputedStyle(t,null).getPropertyValue(e)}function sp(t){return function(){delete this[t]}}function cp(t,e){return function(){this[t]=e}}function up(t,e){return function(){var n=e.apply(this,arguments);null==n?delete this[t]:this[t]=n}}function lp(t){return t.trim().split(/^|\s+/)}function hp(t){return t.classList||new fp(t)}function fp(t){this._node=t,this._names=lp(t.getAttribute("class")||"")}function dp(t,e){for(var n=hp(t),r=-1,i=e.length;++r=0&&(e=t.slice(n+1),t=t.slice(0,n)),{type:t,name:e}}))}function Lp(t){return function(){var e=this.__on;if(e){for(var n,r=0,i=-1,a=e.length;r=0&&(this._names.splice(e,1),this._node.setAttribute("class",this._names.join(" ")))},contains:function(t){return this._names.indexOf(t)>=0}};var jp=[null];function Yp(t,e){this._groups=t,this._parents=e}function zp(){return new Yp([[document.documentElement]],jp)}Yp.prototype=zp.prototype={constructor:Yp,select:function(t){"function"!=typeof t&&(t=Md(t));for(var e=this._groups,n=e.length,r=new Array(n),i=0;i=x&&(x=_+1);!(b=g[x])&&++x=0;)(r=i[a])&&(o&&4^r.compareDocumentPosition(o)&&o.parentNode.insertBefore(r,o),o=r);return this},sort:function(t){function e(e,n){return e&&n?t(e.__data__,n.__data__):!e-!n}t||(t=Wd);for(var n=this._groups,r=n.length,i=new Array(r),a=0;a1?this.each((null==e?rp:"function"==typeof e?ap:ip)(t,e,null==n?"":n)):op(this.node(),t)},property:function(t,e){return arguments.length>1?this.each((null==e?sp:"function"==typeof e?up:cp)(t,e)):this.node()[t]},classed:function(t,e){var n=lp(t+"");if(arguments.length<2){for(var r=hp(this.node()),i=-1,a=n.length;++i{}};function Hp(){for(var t,e=0,n=arguments.length,r={};e=0&&(n=t.slice(r+1),t=t.slice(0,r)),t&&!e.hasOwnProperty(t))throw new Error("unknown type: "+t);return{type:t,name:n}}))}function Vp(t,e){for(var n,r=0,i=t.length;r0)for(var n,r,i=new Array(n),a=0;a=0&&e._call.call(void 0,t),e=e._next;--Kp}()}finally{Kp=0,function(){for(var t,e,n=Zp,r=1/0;n;)n._call?(r>n._time&&(r=n._time),t=n,n=n._next):(e=n._next,n._next=null,n=t?t._next=e:Zp=e);Qp=t,fy(r)}(),ny=0}}function hy(){var t=iy.now(),e=t-ey;e>1e3&&(ry-=e,ey=t)}function fy(t){Kp||(Jp&&(Jp=clearTimeout(Jp)),t-ny>24?(t<1/0&&(Jp=setTimeout(ly,t-iy.now()-ry)),ty&&(ty=clearInterval(ty))):(ty||(ey=iy.now(),ty=setInterval(hy,1e3)),Kp=1,ay(ly)))}function dy(t,e,n){var r=new cy;return e=null==e?0:+e,r.restart((n=>{r.stop(),t(n+e)}),e,n),r}cy.prototype=uy.prototype={constructor:cy,restart:function(t,e,n){if("function"!=typeof t)throw new TypeError("callback is not a function");n=(null==n?oy():+n)+(null==e?0:+e),this._next||Qp===this||(Qp?Qp._next=this:Zp=this,Qp=this),this._call=t,this._time=n,fy()},stop:function(){this._call&&(this._call=null,this._time=1/0,fy())}};var py=Xp("start","end","cancel","interrupt"),yy=[];function gy(t,e,n,r,i,a){var o=t.__transition;if(o){if(n in o)return}else t.__transition={};!function(t,e,n){var r,i=t.__transition;function a(c){var u,l,h,f;if(1!==n.state)return s();for(u in i)if((f=i[u]).name===n.name){if(3===f.state)return dy(a);4===f.state?(f.state=6,f.timer.stop(),f.on.call("interrupt",t,t.__data__,f.index,f.group),delete i[u]):+u0)throw new Error("too late; already scheduled");return n}function vy(t,e){var n=by(t,e);if(n.state>3)throw new Error("too late; already running");return n}function by(t,e){var n=t.__transition;if(!n||!(n=n[e]))throw new Error("transition not found");return n}function _y(t,e){return t=+t,e=+e,function(n){return t*(1-n)+e*n}}var xy,wy=180/Math.PI,ky={translateX:0,translateY:0,rotate:0,skewX:0,scaleX:1,scaleY:1};function Ty(t,e,n,r,i,a){var o,s,c;return(o=Math.sqrt(t*t+e*e))&&(t/=o,e/=o),(c=t*n+e*r)&&(n-=t*c,r-=e*c),(s=Math.sqrt(n*n+r*r))&&(n/=s,r/=s,c/=s),t*r180?e+=360:e-t>180&&(t+=360),a.push({i:n.push(i(n)+"rotate(",null,r)-2,x:_y(t,e)})):e&&n.push(i(n)+"rotate("+e+r)}(a.rotate,o.rotate,s,c),function(t,e,n,a){t!==e?a.push({i:n.push(i(n)+"skewX(",null,r)-2,x:_y(t,e)}):e&&n.push(i(n)+"skewX("+e+r)}(a.skewX,o.skewX,s,c),function(t,e,n,r,a,o){if(t!==n||e!==r){var s=a.push(i(a)+"scale(",null,",",null,")");o.push({i:s-4,x:_y(t,n)},{i:s-2,x:_y(e,r)})}else 1===n&&1===r||a.push(i(a)+"scale("+n+","+r+")")}(a.scaleX,a.scaleY,o.scaleX,o.scaleY,s,c),a=o=null,function(t){for(var e,n=-1,r=c.length;++n>8&15|e>>4&240,e>>4&15|240&e,(15&e)<<4|15&e,1):8===n?Qy(e>>24&255,e>>16&255,e>>8&255,(255&e)/255):4===n?Qy(e>>12&15|e>>8&240,e>>8&15|e>>4&240,e>>4&15|240&e,((15&e)<<4|15&e)/255):null):(e=Yy.exec(t))?new tg(e[1],e[2],e[3],1):(e=zy.exec(t))?new tg(255*e[1]/100,255*e[2]/100,255*e[3]/100,1):(e=Uy.exec(t))?Qy(e[1],e[2],e[3],e[4]):(e=qy.exec(t))?Qy(255*e[1]/100,255*e[2]/100,255*e[3]/100,e[4]):(e=Hy.exec(t))?ig(e[1],e[2]/100,e[3]/100,1):(e=$y.exec(t))?ig(e[1],e[2]/100,e[3]/100,e[4]):Wy.hasOwnProperty(t)?Zy(Wy[t]):"transparent"===t?new tg(NaN,NaN,NaN,0):null}function Zy(t){return new tg(t>>16&255,t>>8&255,255&t,1)}function Qy(t,e,n,r){return r<=0&&(t=e=n=NaN),new tg(t,e,n,r)}function Ky(t){return t instanceof By||(t=Xy(t)),t?new tg((t=t.rgb()).r,t.g,t.b,t.opacity):new tg}function Jy(t,e,n,r){return 1===arguments.length?Ky(t):new tg(t,e,n,null==r?1:r)}function tg(t,e,n,r){this.r=+t,this.g=+e,this.b=+n,this.opacity=+r}function eg(){return"#"+rg(this.r)+rg(this.g)+rg(this.b)}function ng(){var t=this.opacity;return(1===(t=isNaN(t)?1:Math.max(0,Math.min(1,t)))?"rgb(":"rgba(")+Math.max(0,Math.min(255,Math.round(this.r)||0))+", "+Math.max(0,Math.min(255,Math.round(this.g)||0))+", "+Math.max(0,Math.min(255,Math.round(this.b)||0))+(1===t?")":", "+t+")")}function rg(t){return((t=Math.max(0,Math.min(255,Math.round(t)||0)))<16?"0":"")+t.toString(16)}function ig(t,e,n,r){return r<=0?t=e=n=NaN:n<=0||n>=1?t=e=NaN:e<=0&&(t=NaN),new og(t,e,n,r)}function ag(t){if(t instanceof og)return new og(t.h,t.s,t.l,t.opacity);if(t instanceof By||(t=Xy(t)),!t)return new og;if(t instanceof og)return t;var e=(t=t.rgb()).r/255,n=t.g/255,r=t.b/255,i=Math.min(e,n,r),a=Math.max(e,n,r),o=NaN,s=a-i,c=(a+i)/2;return s?(o=e===a?(n-r)/s+6*(n0&&c<1?0:o,new og(o,s,c,t.opacity)}function og(t,e,n,r){this.h=+t,this.s=+e,this.l=+n,this.opacity=+r}function sg(t,e,n){return 255*(t<60?e+(n-e)*t/60:t<180?n:t<240?e+(n-e)*(240-t)/60:e)}function cg(t,e,n,r,i){var a=t*t,o=a*t;return((1-3*t+3*a-o)*e+(4-6*a+3*o)*n+(1+3*t+3*a-3*o)*r+o*i)/6}Dy(By,Xy,{copy:function(t){return Object.assign(new this.constructor,this,t)},displayable:function(){return this.rgb().displayable()},hex:Vy,formatHex:Vy,formatHsl:function(){return ag(this).formatHsl()},formatRgb:Gy,toString:Gy}),Dy(tg,Jy,Oy(By,{brighter:function(t){return t=null==t?Iy:Math.pow(Iy,t),new tg(this.r*t,this.g*t,this.b*t,this.opacity)},darker:function(t){return t=null==t?Ly:Math.pow(Ly,t),new tg(this.r*t,this.g*t,this.b*t,this.opacity)},rgb:function(){return this},displayable:function(){return-.5<=this.r&&this.r<255.5&&-.5<=this.g&&this.g<255.5&&-.5<=this.b&&this.b<255.5&&0<=this.opacity&&this.opacity<=1},hex:eg,formatHex:eg,formatRgb:ng,toString:ng})),Dy(og,(function(t,e,n,r){return 1===arguments.length?ag(t):new og(t,e,n,null==r?1:r)}),Oy(By,{brighter:function(t){return t=null==t?Iy:Math.pow(Iy,t),new og(this.h,this.s,this.l*t,this.opacity)},darker:function(t){return t=null==t?Ly:Math.pow(Ly,t),new og(this.h,this.s,this.l*t,this.opacity)},rgb:function(){var t=this.h%360+360*(this.h<0),e=isNaN(t)||isNaN(this.s)?0:this.s,n=this.l,r=n+(n<.5?n:1-n)*e,i=2*n-r;return new tg(sg(t>=240?t-240:t+120,i,r),sg(t,i,r),sg(t<120?t+240:t-120,i,r),this.opacity)},displayable:function(){return(0<=this.s&&this.s<=1||isNaN(this.s))&&0<=this.l&&this.l<=1&&0<=this.opacity&&this.opacity<=1},formatHsl:function(){var t=this.opacity;return(1===(t=isNaN(t)?1:Math.max(0,Math.min(1,t)))?"hsl(":"hsla(")+(this.h||0)+", "+100*(this.s||0)+"%, "+100*(this.l||0)+"%"+(1===t?")":", "+t+")")}}));const ug=t=>()=>t;function lg(t,e){var n=e-t;return n?function(t,e){return function(n){return t+n*e}}(t,n):ug(isNaN(t)?e:t)}const hg=function t(e){var n=function(t){return 1==(t=+t)?lg:function(e,n){return n-e?function(t,e,n){return t=Math.pow(t,n),e=Math.pow(e,n)-t,n=1/n,function(r){return Math.pow(t+r*e,n)}}(e,n,t):ug(isNaN(e)?n:e)}}(e);function r(t,e){var r=n((t=Jy(t)).r,(e=Jy(e)).r),i=n(t.g,e.g),a=n(t.b,e.b),o=lg(t.opacity,e.opacity);return function(e){return t.r=r(e),t.g=i(e),t.b=a(e),t.opacity=o(e),t+""}}return r.gamma=t,r}(1);function fg(t){return function(e){var n,r,i=e.length,a=new Array(i),o=new Array(i),s=new Array(i);for(n=0;n=1?(n=1,e-1):Math.floor(n*e),i=t[r],a=t[r+1],o=r>0?t[r-1]:2*i-a,s=ra&&(i=e.slice(a,i),s[o]?s[o]+=i:s[++o]=i),(n=n[0])===(r=r[0])?s[o]?s[o]+=r:s[++o]=r:(s[++o]=null,c.push({i:o,x:_y(n,r)})),a=pg.lastIndex;return a=0&&(t=t.slice(0,e)),!t||"start"===t}))}(e)?my:vy;return function(){var o=a(this,t),s=o.on;s!==r&&(i=(r=s).copy()).on(e,n),o.on=i}}var Bg=Up.prototype.constructor;function Lg(t){return function(){this.style.removeProperty(t)}}function Ig(t,e,n){return function(r){this.style.setProperty(t,e.call(this,r),n)}}function Rg(t,e,n){var r,i;function a(){var a=e.apply(this,arguments);return a!==i&&(r=(i=a)&&Ig(t,a,n)),r}return a._value=e,a}function Fg(t){return function(e){this.textContent=t.call(this,e)}}function Pg(t){var e,n;function r(){var r=t.apply(this,arguments);return r!==n&&(e=(n=r)&&Fg(r)),e}return r._value=t,r}var jg=0;function Yg(t,e,n,r){this._groups=t,this._parents=e,this._name=n,this._id=r}function zg(){return++jg}var Ug=Up.prototype;Yg.prototype=function(t){return Up().transition(t)}.prototype={constructor:Yg,select:function(t){var e=this._name,n=this._id;"function"!=typeof t&&(t=Md(t));for(var r=this._groups,i=r.length,a=new Array(i),o=0;o2&&n.state<5,n.state=6,n.timer.stop(),n.on.call(r?"interrupt":"cancel",t,t.__data__,n.index,n.group),delete a[i]):o=!1;o&&delete t.__transition}}(this,t)}))},Up.prototype.transition=function(t){var e,n;t instanceof Yg?(e=t._id,t=t._name):(e=zg(),(n=qg).time=oy(),t=null==t?null:t+"");for(var r=this._groups,i=r.length,a=0;a0?tm(fm,--lm):0,cm--,10===hm&&(cm=1,sm--),hm}function ym(){return hm=lm2||bm(hm)>3?"":" "}function wm(t,e){for(;--e&&ym()&&!(hm<48||hm>102||hm>57&&hm<65||hm>70&&hm<97););return vm(t,mm()+(e<6&&32==gm()&&32==ym()))}function km(t){for(;ym();)switch(hm){case t:return lm;case 34:case 39:34!==t&&39!==t&&km(hm);break;case 40:41===t&&km(t);break;case 92:ym()}return lm}function Tm(t,e){for(;ym()&&t+hm!==57&&(t+hm!==84||47!==gm()););return"/*"+vm(e,lm-1)+"*"+Zg(47===t?t:ym())}function Em(t){for(;!bm(gm());)ym();return vm(t,lm)}function Cm(t){return function(t){return fm="",t}(Sm("",null,null,null,[""],t=function(t){return sm=cm=1,um=nm(fm=t),lm=0,[]}(t),0,[0],t))}function Sm(t,e,n,r,i,a,o,s,c){for(var u=0,l=0,h=o,f=0,d=0,p=0,y=1,g=1,m=1,v=0,b="",_=i,x=a,w=r,k=b;g;)switch(p=v,v=ym()){case 40:if(108!=p&&58==k.charCodeAt(h-1)){-1!=Jg(k+=Kg(_m(v),"&","&\f"),"&\f")&&(m=-1);break}case 34:case 39:case 91:k+=_m(v);break;case 9:case 10:case 13:case 32:k+=xm(p);break;case 92:k+=wm(mm()-1,7);continue;case 47:switch(gm()){case 42:case 47:im(Mm(Tm(ym(),mm()),e,n),c);break;default:k+="/"}break;case 123*y:s[u++]=nm(k)*m;case 125*y:case 59:case 0:switch(v){case 0:case 125:g=0;case 59+l:d>0&&nm(k)-h&&im(d>32?Nm(k+";",r,n,h-1):Nm(Kg(k," ","")+";",r,n,h-2),c);break;case 59:k+=";";default:if(im(w=Am(k,e,n,u,l,i,s,b,_=[],x=[],h),a),123===v)if(0===l)Sm(k,e,w,w,_,a,h,s,x);else switch(f){case 100:case 109:case 115:Sm(t,w,w,r&&im(Am(t,w,w,0,0,i,s,b,i,_=[],h),x),i,x,h,s,r?_:x);break;default:Sm(k,w,w,w,[""],x,0,s,x)}}u=l=d=0,y=m=1,b=k="",h=o;break;case 58:h=1+nm(k),d=p;default:if(y<1)if(123==v)--y;else if(125==v&&0==y++&&125==pm())continue;switch(k+=Zg(v),v*y){case 38:m=l>0?1:(k+="\f",-1);break;case 44:s[u++]=(nm(k)-1)*m,m=1;break;case 64:45===gm()&&(k+=_m(ym())),f=gm(),l=h=nm(b=k+=Em(mm())),v++;break;case 45:45===p&&2==nm(k)&&(y=0)}}return a}function Am(t,e,n,r,i,a,o,s,c,u,l){for(var h=i-1,f=0===i?a:[""],d=rm(f),p=0,y=0,g=0;p0?f[m]+" "+v:Kg(v,/&\f/g,f[m])))&&(c[g++]=b);return dm(t,e,n,0===i?Vg:s,c,u,l)}function Mm(t,e,n){return dm(t,e,n,Wg,Zg(hm),em(t,2,-2),0)}function Nm(t,e,n,r){return dm(t,e,n,Gg,em(t,0,r),em(t,r+1,-1),r)}const Dm="8.13.10";var Om=n(9609),Bm=n(7856),Lm=n.n(Bm),Im=function(t){var e=t.replace(/\\u[\dA-F]{4}/gi,(function(t){return String.fromCharCode(parseInt(t.replace(/\\u/g,""),16))}));return e=(e=(e=e.replace(/\\x([0-9a-f]{2})/gi,(function(t,e){return String.fromCharCode(parseInt(e,16))}))).replace(/\\[\d\d\d]{3}/gi,(function(t){return String.fromCharCode(parseInt(t.replace(/\\/g,""),8))}))).replace(/\\[\d\d\d]{2}/gi,(function(t){return String.fromCharCode(parseInt(t.replace(/\\/g,""),8))}))},Rm=function(t){for(var e="",n=0;n>=0;){if(!((n=t.indexOf("=0)){e+=t,n=-1;break}e+=t.substr(0,n),(n=(t=t.substr(n+1)).indexOf("<\/script>"))>=0&&(n+=9,t=t.substr(n))}var r=Im(e);return(r=(r=(r=r.replace(/script>/gi,"#")).replace(/javascript:/gi,"#")).replace(/onerror=/gi,"onerror:")).replace(/